Размещено на http://www.allbest.ru/

Автоматизированная информационная система учета автотранспорта

Содержание

• Введение
• 1.1 Описание деятельности фирмы
• 1.2 Оценка функций учета в автосалоне Aurore Auto
• 2. Проектирование информационной системы
• 2.1 Подходы к проектированию ИС
• 2.2 Унифицированный язык моделирования UML
• 2.3 CASE средство Rational Rose
• 2.4 Диаграмма вариантов использования
• 2.5 Диаграммы состояний
• 2.6 Диаграмма деятельности
• 2.7 Диаграммы взаимодействия
• 3. Проектирование БД.
• 3.1 Требования, предъявляемые к базе данных
• 3.2 Rational Rose Data Modeler средство проектирования БД
• 3.3 Создание логической модели
• 3.4 Выбор инструментального средства построения системы учета
• 4. Реализация ИС учета автомобилей для автосалона
• 5. Расчет экономической эффективности проекта
• 5.1 План маркетинга
• 5.1.1 Описание характеристик товара/услуги
• 5.2.1 Цели, задачи и методы оценки инвестиций
• 5.2.2 Выбор и описание разрабатываемого и альтернативного вариантов
• 5.2.3 Расчёт вложений на этапе разработки и отладки основного варианта
• 5.2.4 Расчёт вложений на этапе разработки и отладки альтернативного варианта
• 5.2.5 Расчёт вложений по годам этапа эксплуатации
• 5.2.6 Итоговые показатели технико-экономической эффективности
• 5.2.7 Вывод
• 6. Безопасность и санитарно-гигиенические условия труда на рабочем месте пользователя ПЭВМ
• 6.1 Характеристика санитарно-гигиенических условий труда
• 6.1.1 Микроклимат
• 6.1.2 Вредные вещества и пыль
• 6.1.3 Уровень ионизации воздуха
• 6.1.4 Требования к уровню вибрации
• 6.1.5 Требования к уровню шума
• 6.1.6 Излучения
• 6.1.7 Нормы на освещение рабочего места
• 6.2 Вентиляция
• 6.3 Расчет осветительной установки
• 6.4 Режим труда
• 6.5 Характеристика электрооборудования
• 6.5.1 Электрическая безопасность
• 6.5.2 Оценка необходимости применения защитных устройств
• 6.5.3 Пожарная безопасность
• 6.6 Выводы
• Заключение
• Приложение 1. Код программы
• Список использованной литературы

Введение

Современные информационные технологии применяются уже практически во всех сферах деятельности человека. Можно сказать, что в настоящий момент, эффективное развитие любого общества немыслимо без систем управления, построенных на комплексных системах обработки информации, на современных информационных технологиях.

Наибольшая актуальность и практическая потребность в разработке методов применения электронной информации в экономике, наблюдается на уровне различных фирм, так как предприятия выступают как основной субъект хозяйственной деятельности в экономике. Этот факт подтверждается постоянно растущим интересом со стороны менеджеров крупных и средних компаний к внедрению автоматизированных компьютерных систем учета и поддержки принятия решений.

Интерес к автоматизированным системам учета вызван качественно новыми технологическими возможностями обработки управленческой информации, которые имеют прямое приложение для задач повышения экономической эффективности работы, повышение конкурентоспособности и рентабельности рынка, за счет использования информационных методов, позволяющих рационализировать управление ресурсами.

Компания «Aurore Auto», официальный дилер Nissan, одна из наиболее динамично развивающихся компаний на автомобильном рынке Санкт- Петербурга, о чем свидетельствует растущее число клиентов, большинство из которых становится постоянными. На сегодняшний день компания представляет жителям Санкт- Петербурга наивысшие стандарты качества. Компания оказывает услуги в сферах продаж автомобилей, сервисного обслуживания, кредитования, страхования и лизинга.

В автосалоне компании представлен полный модельный ряд Nissan и некоторые модели других производителей.

В специализированном центре оказываются услуги по гарантийному и послегарантийному ремонту, диагностические и восстановительные работы любой сложности, кузовной ремонт.

На складе компании в наличии широкий выбор оригинальных запасных частей, еще больше запчастей доступно под заказ.

Автосалон динамично развивается, соответственно возрастает необходимость ведения более точного учета автомобилей, а так же возможности получения оперативной информации о состоянии различных бизнес-процессов, происходящих в компании.

В данный момент в отделе компаунда (склада автомобилей) учет частично автоматизирован, за счет использования MS Excel, однако данная автоматизация обрывочна и уже не справляется с возложенными на нее задачами. На хранение, обработку и своевременное редактирование и обновление данных уходит значительное количество времени и трудовых ресурсов.

В настоящей работе будет решаться задача построения информационной системы, посредством которой можно было бы оперативно вносить, удалять и корректировать сведения об автомобилях, проходящих через компаунд, а так же получать резюмирующие сведения, для нужд менеджмента компании.

Актуальность данной работы объясняется тем, что единая информационная среда, в которой могли бы работать сотрудники отдела продаж и компаунда, повысила бы эффективность их труда, сократила бы издержки компании. Помимо снижения трудозатрат, внедряемая система автоматизации, позволила бы получать руководству компании более точные сведения о ее функционировании, что позволило бы принимать более взвешенные решения о дальнейшем развитии компании.

Предполагается создание информационной системы учета на базе таких средства как PHP и MySQL и разработка соответствующего интерфейса для пользователя высокого уровня подготовки.

Итак, целью настоящей дипломной работы является построение автоматизированной системы для решения учетных задач, возникающих в автосалоне «Aurore Auto».

Для достижения поставленной цели необходимо решить ряд задач:

· Рассмотреть теоретический аспект внедрения систем автоматизации

· Проанализировать существующие методы автоматизации

· Формализовать деятельность автосалона «Aurore Auto», выделив необходимые к отслеживанию процессы

· Выбрать необходимую среду реализации ПО.

· Разработать действующее ПО, решающее поставленные задачи

· Проанализировать экономическую эффективность внедрения средства автоматизации.

1. Проектирование системы учета для автосалона

1.1 Описание деятельности фирмы

Компания «Aurore Auto» осуществляет продажу и сервисное гарантийное обслуживание автомобилей различных марок, в основном автомобилей марки Nissan. Точно так же она осуществляет ремонт автомобилей с закончившимся сроком гарантии и продажей различных запчастей и аксессуаров.

Автосалон компании представляет из себя выставочный зал, склад, ангар для проведения работ, другие рабочие помещения, стоянку автомобилей.

Структура ООО «Aurore Auto» определяется структурой управления и структурой своих функциональных подразделений.

Главой является генеральный директор. Он руководит производственной и коммерческой деятельностью фирмы в целом. Занимается закупкой товаров, работой с поставщиками, решает стратегические задачи. Дает распоряжения и контролирует работу управляющего топ-менеджера - руководителя отдела продаж (РОП).

Основная задача руководителя отдела продаж: управление коммерческой деятельностью автосалона, направленной на удовлетворение нужд потребителей и получение прибыли за счет стабильного функционирования, поддержания деловой репутации в соответствии с предоставленными полномочиями и выделенными ресурсами. Назначение на должность руководителя отдела продаж и освобождение от неё производится приказом ген.директора фирмы. В своей деятельности РОП руководствуется должностной инструкцией и Уставом предприятия ООО «Aurore Auto».

Руководитель отдела продаж должен знать:

· законодательные и нормативные правовые акты.

· теорию и практику работы с персоналом.

· структуру управления магазином.

· условия поставки, хранения товаров.

· действующие цены на товар.

· правила и нормы охраны труда, техники безопасности, противопожарной защиты.

Цель работы - достижение максимальных продаж при высоком уровне обслуживания и полном удовлетворении потребностей клиента в товарах и услугах компании за счет слаженной работы всего персонала магазина.

Должностные обязанности РОП:

· осуществляет управление деятельностью работы магазина.

· решает организационно-технические, экономические, кадровые проблемы.

· осуществляет расстановку кадров, мотивацию их развития, оценку и стимулирования качества труда.

· осуществляет анализ спроса на продукцию.

· обеспечивает рост прибыльности, конкурентоспособности и качества товаров и услуг.

· периодически предоставляет директору компании отчеты о деятельности автосалона

Основная задача администратора: обеспечение бесперебойной работы магазина. Подчиняется и получает приказы и рабочие распоряжения от руководителя отдела продаж магазина. В своей работе администратор руководствуется правилами торговли, законом «о защите прав потребителей», правилами работы на кассе, правилами работы с кредитными картами, правилами внутреннего трудового распорядка магазина, технологией продаж.

Администратор должен знать:

· правила работы магазина, организации торгового процесса.

· права и обязанности работников торгового зала.

· виды выполняемых ремонтных работ, цены

· виды автомобилей, ассортимент запчастей и аксессуаров, размещение, свойства, цены товаров.

· правила обслуживания покупателей.

· порядок учета товаров, проведение инвентаризации.

· правила и нормы охраны труда, техники безопасности, противопожарной защиты.

Должностные обязанности администратора:

· соблюдать правила внутреннего трудового распорядка

· находится на рабочем месте находиться в чистой форменной одежде.

· составлять и контролировать график работы персонала магазина (технического отдела и торгового зала).

· ежедневно вести табель учета рабочего времени.

· осуществлять первичное обучение продавцов в период стажировки.

· координировать работу персонала магазина при его: открытии-закрытии, проведении инвентаризации, приемке нового товара.

· координировать работу технического отдела (ремонтной мастерской)

· выполнять по необходимости обязанности менеджера по продажам.

· обеспечивать контроль за оформлением торгового зала, помещения в целом.

Основная задача менеджера: достижение максимальных продаж при высочайшем уровне обслуживания. Менеджер согласует свою деятельность по всем вопросам с администратором. Цели- наиболее полное удовлетворение потребностей клиента в товарах и услугах при выполнении плана продаж. Качественное обслуживание согласно стандартам компании и правилам торговли, формирование и поддержание имиджа автосалона.

Менеджер должен знать ассортимент автомобилей, дополнительных товаров, характеристики каждого вида товара, приемы подбора товара, основные формы и способы представления товара в торговом зале, правила обмена товаров, гарантийные сроки, а так же: перечень видов технических ремонтных работ, цены, сроки выполнения.

Должностные обязанности менеджера:

· Передавать сотрудникам технического отдела заказ-наряд по ремонту автомобиля.

· Следить за презентацией.

· За наличием ценников.

· Проверять товар перед началом и окончанием смены.

· Информировать заказчиков о завершении сервисных работ по их автомобилям

· Менеджер по продажам должен уметь вежливо и корректно вести беседу с покупателями.

Основная задача кассира- качественное и безошибочное обслуживание покупателей, контроль за сохранностью денежных средств. В своей деятельности кассир руководствуется- должностной инструкцией, правилами торговли, правилами работы на кассе, правилами внутреннего распорядка магазина.

Должностные обязанности кассира:

· Обеспечить тщательный уход и бережное обращение с ККМ.

· Осуществлять операции ввода сумм в соответствии с руководством по эксплуатации на данный тип ККМ.

· Для каждого покупателя определить общую сумму покупки по показанию индикатора кассовой машины.

· Получить от покупателя деньги за товары согласно стоимости приобретаемого товара.

· В случае возврата денег кассир действует в соответствии с указаниями администратора магазина.

· В случае обмена товара на аналогичный обязан заполнить справку об обмене товара.

· В конце рабочего дня кассир обязан сдать торговую выручку администратору магазина.

Описанный тип структуры является линейным.

Всего, в автосалоне «Aurore Auto» работает более 70 человек линейного персонала и 5 управленцев. Средний возраст сотрудников - 32 года. При отборе претендентов, а занимается этим непосредственно начальство автосалона, прежде всего, обращается внимание на предыдущий опыт работы, желательно, чтобы претендент уже работал в подобных торговых предприятиях.

Компания активно поддерживает и развивает систему нематериального вознаграждения. Под нематериальным вознаграждением понимаются все формы признания заслуг и поощрения, ценность которых для работника не определяется и не исчерпывается их непосредственным денежным эквивалентом. Нематериальное вознаграждение, используемое в рассматриваемой компании включает корпоративные награды (знаки отличия, призы за победу в конкурсах «Лучший по профессии»).

Размещено на http://www.allbest.ru/

Рис 1.1. Структура управления сети автосалонов «Aurore Auto»

1.2 Оценка функций учета в автосалоне Aurore Auto

автоматизированный информационный система учет автотранспорт

Основные функции автосалона «Aurore Auto» заключаются в продаже автомобилей, продаже запчастей к автомобилям, выполнение диагностики автомобилей и ремонтных работы по автомобилям.

До сих пор автоматизация деятельности отдела компаунда заключалась в использовании MS Excel

В настоящий момент учет авто в типовом автосалоне «Aurore Auto» ведется следующим образом:

Все счета в процессе работы заполняются в текстовом редакторе на основе типовых бланков.

Стоимость запчастей, предпродажной подготовки и т.д., а также предположительное время доставки определяется, на основе ряда программных продуктов от производителей автомобилей той или иной марки.

В конце рабочего сотрудники отдела сводят всю информацию по продажам текущего дня и по осуществленным заказам на технические работы в сводную таблицу Excel

Выполнение ремонтных и диагностических работ связано с ведением заказ-нарядов, определением стоимости работ, исходя из времени и количества работников, участвующих в починке, а так же количеству израсходованных запчастей.

Каждый администратор в MS Excel ведет учет текущих ремонтных работ, а так же учет рабочего времени сотрудников технического отдела, эти работы осуществляющих. Ему ежедневно предоставляется сводная отчетность в виде таблицы MS Excel, состоящей из четырех листов.

На первом листе представлена информация о продажах, т.е. о проданных автомобилях и комплектующих. Второй лист представляет собой сводную информацию о принятых заказах на ремонтные работы. Третий лист предоставляет сводную информацию о выработке сотрудников технического отдела по типам работ, в зависимости от их категории сложности. На четвертом листе- итоговые показатели по текущему месяцу с учетом прошедших суток.

Администратор на основе поступающей ему отчетности производит итоговую отчетность, строит диаграммы показателей работы автосалона.

Основные проблемы существующего учета: отсутствие оперативности в обновлении данных, дублирование данных и вызванная этим постоянная необходимость перепроверки всей отчетности. Из-за отсутствия унификации, данная автоматизация хотя и помогала справиться с необходимым учетом, отнимает слишком много рабочего времени администраторов, менеджеров отдела продаж и компаунда.

Очевидно, что для успешного функционирования предприятия автосалону требуется построение более эффективной схемы автоматизации учета, которая позволила бы вести учет продаж автомобилей, комплектующих и осуществленных работ, печать счетов.

Исходя из вышесказанного требуется разработать базу данных, где была бы собрана и структурирована информация обо всех значимых бизнес-процессах отдела компаунда, хранились бы справочники фирм-производителей автомобилей относительно стоимости и вида комплектующих, на основе данных поставщиков имелась бы информация относительно видов и цены деталей, запчастей, учитывалось бы выполнение заказа-нарядов.

Для топ-менеджмента компании необходимо иметь возможность получать данные о выручке и других статистических показателях работы автосалона. Соответственно требуется разграничение прав пользователей к базе сотрудников автосалона.

Система управления должна позволять осуществлять независимую работу многих пользователей структурного подразделения с базой данных, внесение в нее изменений, получение оперативных отчетов.

2. Проектирование информационной системы

2.1 Подходы к проектированию ИС

Проблема сложности является главной проблемой, которую приходится решать при создании больших и сложных ИС. Ни один разработчик не в состоянии понять всю систему в целом. На сегодняшний момент существует два подхода к разработке ИС, которые обусловлены разными принципами декомпозиции системы:

Функционально модульный или структурный - в основу положен принцип функциональной декомпозиции, в котором система описывается в терминах иерархии ее функций и передачи информации между отдельными функциональными элементами

Объектно-ориентированный подход - использует объектную декомпозицию. Система описывается в терминах объектов и связей между ними, а поведение системы в терминах обмена между ними.

Появление первых ЭВМ ознаменовало новый этап в развитии техники вычислений. Появились специальные языки программирования, позволяющие преобразовывать отдельные вычислительные операции в программный код. Со временем разработка больших программ превратилась в серьезную проблему, и потребовало разбиение на более мелкие фрагменты. Основой для такого разбиения стала процедурная декомпозиция, при которой отдельные части программ или модули представляли собой совокупность процедур для решения некоторой совокупности задач.

Появилась методология структурного программирования. Основой данной методологии является процедурная декомпозиция программной системы и организация отдельных модулей в виде совокупности выполняемых процедур.

Во второй половине 80х годов появилось методология объектно-ориентированного программирования

Главный недостаток структурного подхода заключается в том, что процессы и данные существуют отдельно друг от друга, причем проектирование ведется от процессов к данным. Таким образом, помимо функциональной декомпозиции, существует также структура данных, находящаяся на втором плане.

В объектно-ориентированном подходе основная категория объектной модели - класс - объединяет в себе как данные, так и операции. Данные по сравнению с процессами являются более стабильной и относительно редко изменяющейся частью системы. Один из основоположников объектно-ориентированного подхода сформулировал преимущества следующим образом:

“Объектно-ориентированные системы более открыты и легче поддаются внесению изменений, поскольку их конструкция базируется на устойчивых формах. Это дает возможность системе развиваться постепенно и не приводит к полной ее переработке даже в случае существенных изменений исходных требований”.

Тем не менее, структурный подход по-прежнему сохраняет свою значимость и достаточно широко используется на практике. Довольно часто при проектировании ИС используются оба подхода. В частности возможно использование структурного анализа как основы для объектно-ориентированного проектирования. При этом структурный анализ следуют прекращать, как только диаграммы начнут отражать не только деятельность предприятия, но и саму систему.

В первом разделе дипломного проекта использовалась методология структурного подхода для описания бизнес процессов предприятия.

2.2 Унифицированный язык моделирования UML

В настоящее время унифицированный язык моделирования UML является визуальным языком моделирования, который позволяет системным архитекторам представить свое видение системы в стандартной и легкой для понимания форме. Кроме того, UML представляет эффективный механизм совместного использования проектных решений и взаимодействия разработчиков друг с другом.

Сформировать видение системы - чрезвычайно важный момент. До появления языка UML процесс разработки зачастую основывался на сделанных наугад предположениях. Системный аналитик должен был оценить потребности клиентов, сформулировать задачу в понятной для специалиста форме, передать результаты своего анализа программисту и надеяться, что конечный программный продукт будет представлять собой именно ту систему, которая нужна клиенту.

Поскольку процесс разработки системы во многом зависит от человеческой деятельности, то на любой стадии могут возникать ошибки. Аналитик может неправильно понять клиента и создать непонятный для него документ. Результаты работы аналитика могут оказаться неочевидными для программистов, которые создадут сложную в использовании программу, не позволяющую клиенту решить исходную задачу.

В настоящее время ключевым моментом процесса разработки является хорошо продуманный план. Клиент должен разобраться в том, что собирается делать группа разработчиков, и должен иметь возможность внести поправки, если его задачи решаются не в полном объеме.

Окружающий мир становится все более сложным. Поэтому отражающие его компьютерные системы также усложняются. Зачастую они состоят из большого числа программных аппаратных компонентов, взаимодействующих друг с другом на больших расстояниях и связанных с базами данных, в которых содержится огромное количество информации.

Ключевым аспектом процесса проектирования является его правильная организация, когда аналитики, клиенты, программисты и другие специалисты, участвующие в разработке системы, способны понять друг друга и придти к общему мнению. Язык UML и обеспечивает такую возможность.

Еще одной отличительной чертой процесса разработки современных систем является дефицит времени для выполнения работ. Если предельные сроки сдачи подсистем нагромождаются друг на друга, то обеспечение непрерывности процесса разработки становится жизненно важной необходимостью.

Потребность в качестве процесса разработки обуславливает необходимость создания стандартных условных обозначений. Язык UML представляет собой именно такую систему обозначений.

Авторами UML являются Гради Буч (Grady Booch), Джеймс Румбах (James Rumbaugh) и Айвар Якобсон (Ivar Jacobson). Известные как «три товарища», в 80-х - начале 90-х годов они работали в разных организациях и независимо друг от друга продумывали методологии объектно-ориентированного анализа и проектирования, которые имели явные преимущества перед всеми остальными известными методами. В середине 90-х годов они стали заимствовать идеи друг у друга и поэтому решили объединить свои усилия.

В 1994 году Румбаха пригласили в компанию Rational Software Corporation, где в это же время уже работал Буч. Через год к ним присоединился Якобсон.

Предварительные версии UML начали использоваться в области создания программного обеспечения, а на основании отзывов потребителей производились существенные доработки. Многие корпорации ощутили, что язык UML может оказаться полезным для достижения их стратегических целей. Это привело к возникновению консорциума UML, в который вошли такие компании, как DEC, Hewlett-Packard, Intellicorp, Microsoft, Oracle, Texas Instruments, Rational и другие. В 1997 году консорциум выработал первую версию UML и представил ее на рассмотрение группе OMG (Object Management Group), откликнувшись на ее запрос о подаче предложений по стандартному языку моделирования.

После расширения консорциума вышла версия 1.1 языка UML, которую группа OMG приняла в конце 1997 года. После этого OMG приступила к сопровождению UML и выпустила в 1998 году две его новые версии. Язык UML стал стандартом де-факто в области разработки программного обеспечения. В настоящее время этот язык продолжает активно развиваться

Язык UML предназначен для решения следующих задач:

· Предоставить пользователю легко воспринимаемый язык визуального моделирования, специально предназначенный для разработки и документирования моделей сложных систем самого различного целевого назначения.

· Снабдить исходные понятия языка UML возможностью расширения и специализации для более точного представления моделей системы в ООАП (объектно-ориентированный анализ и проектирование) конкретной предметной области.

· Ни одна из конструкций языка UML не должна зависеть от особенностей ее реализации в известных языках программирования.

· Поощрять развитие рынка объектных инструментальных средств.

· Способность совершенствоваться.

· Интегрировать в себя новейшие и наилучшие достижения практики

В рамках языка UML все представления о модели сложной системы фиксируются в виде специальных графических конструкций, получивших название диаграмм. В терминах языка UML определены следующие виды диаграмм:

· Диаграмма вариантов или прецедентов использования (use case diagram)

· Диаграмма классов (class diagram)

· Диаграммы поведения (behavior diagrams)

· Диаграмма состояний (statechart diagram)

· Диаграмма деятельности (activity diagram)

· Диаграммы взаимодействия (interaction diagrams)

· Диаграмма последовательности (sequence diagram)

· Диаграмма кооперации (collaboration diagram)

· Диаграммы реализации (implementation diagrams)

· Диаграмма компонентов (component diagram)

· Диаграмма развертывания (deployment diagram)

Перечень этих диаграмм и их названия являются каноническими в том смысле, что представляют неотъемлемую часть графической нотации языка UML. Каждая из этих диаграмм детализирует и конкретизирует различные представления о модели сложной системы в терминах языка UML.

Также стоит добавить, что не всегда обязательно строить абсолютно все диаграммы, разработчик сам решает - устраивает ли его данный уровень детализации, нужно ли рассмотреть систему или ее часть с «другого вида», достаточно ли подробно рассмотрены самые «сложные и скользкие моменты». Т.е. инструменты, поддерживающие UML и предназначенные для моделирования программного обеспечения, позволяют еще на этапе разработки проверить архитектурные решения, полноту модели, ее корректность, для того, чтобы, в том числе, уменьшить риск «провала» проекта. Опишем некоторые из графических диаграмм построенных при разработке нашей системы.

2.3 CASE средство Rational Rose

Rational Rose - мощное CASE-средство для проектирования программных систем любой сложности. Одним из достоинств этого программного продукта будет возможность использования диаграмм на языке UML. Можно сказать, что Rational Rose является графическим редактором UML диаграмм

CASE-средство Rational Rose со времени своего появления претерпело серьезную эволюцию и превратилось в современное и мощное средство анализа, моделирования и разработки программных систем. Именно в Rational Rose 98/2000 язык UML стал базовой технологией визуализации и разработки программ, что определило популярность и стратегическую перспективность этого инструментария.

В рамках Rational Rose существуют различные программные инструментарии, отличающиеся между собой диапазоном реализованных возможностей.

То, что пакет позволяет создавать сложные программные системы от замысла до создания исходного кода, привлекает не только проектировщиков, но программистов - разработчиков. В сочетании со средствами документирования он дает полное представление о проекте. Выделим следующие преимущества от применения этого пакета:

· сокращение время разработки;

· уменьшение ручного труда, увеличение продуктивности;

· улучшение потребительских качеств создаваемых программ;

· способность вести большие проекты или группу проектов;

· позволяет быть языком общения между различными разработчиками.

В виду того, что разрабатываемая система представляет собой создание БД, то не стоят задачи полной разработки автоматизации процесса моделирования, т.е. написание кодов программ при помощи Rational Rose. Решение поставленных задач позволяют не пользоваться этим на данной точке проектирования, но в свою очередь является полезной стартовой площадкой для возможного дальнейшего использования, данного разработанного проекта, для внедрения в состав какого-либо другого программного продукта. Построенные модели помогают точнее понять задачи, которые должна выполнять система и являются понятным средством общения с заказчиком или в дальнейшей работе с другими разработчиками. Рассмотрим сначала функциональную модель нашей системы. Наша система имеет ряд пользователей, объединенных определенными задачами, что позволяет нам разделить систему на несколько подсистем и описать их по отдельности не создавая большого объема и избыточности. Рассмотрим некоторые из диаграмм, которые активно помогли мне в определении большинства тех вещей, которые будет выполнять данная информационная система.

2.4. Диаграмма вариантов использования

Разработка данной диаграммы преследует следующие цели:

· Определить общие границы и контекст моделируемой предметной области на начальных этапах проектирования системы

· Сформулировать общие требования к функциональному поведению проектируемой системы.

· Разработать исходную концептуальную модель системы для ее последующей детализации в форме логических и физических моделей.

· Подготовить исходную документацию для взаимодействия разработчиков системы с ее заказчиками и пользователями.

Суть данной диаграммы состоит в следующем: проектируемая система представляется в виде множества сущностей или актеров, взаимодействующих с системой с помощью так называемых вариантов использования. При этом актером или действующим лицом называется любая сущность, взаимодействующая с системой извне. Это может быть человек, техническое устройство, программа или любая другая система, которая может служить источником воздействия на моделируемую систему так, как определит сам разработчик. В свою очередь вариант использования служит для описания сервисов, которые система предоставляет актеру. При этом ничего не говорится о том, каким образом будет реализовано взаимодействие актеров с системой.

Средства Rational Rose позволяют для описания функциональной системы воспользоваться графическим редактором для построения Use Case диаграмм (сценариев). Опишем основные элементы см. таблице 1.

Таб.1 Условные обозначения диаграммы вариантов использования

Условное обозначение	Описание условного обозначения
	Actor-актер системы, т.е. любое действующее лицо, которое представляет собой любую внешнюю по отношению к моделируемой системе сущность, которая взаимодействует с системой и использует ее функциональные возможности для достижения определенных целей. В системе актерами являются «директор», «Менеджер по продажам», «руководитель отдела продаж» и «клиент».
	Use case -стандартное обозначение варианта (прецедента) использования, описывающий типичное взаимодействие между пользователем и системой
	связь, называемая коммуникацией (communication). Устанавливает, какую конкретную роль играет актер при взаимодействии с экземпляром варианта использования
	связь включения (include) между двумя вариантами использования, которая указывает, что некоторое заданное поведение для одного варианта использования включается в качестве составного компонента в последовательности поведения другого варианта использования
	связь расширение (extend)отмечает тот факт, что один из вариантов использования может присоединять к своему поведению некоторое дополнительное поведение, определенное для другого варианта использования

В результате использования этих обозначения построена следующая обобщенная диаграмма вариантов использования для действующих лиц:

Размещено на http://www.allbest.ru/

Рис. 2.1 Диаграмма прецедентов

2.5. Диаграммы состояний

Диаграммы состояний определяют все возможные состояния, в которых может находиться конкретный объект, а также процесс смены состояний объекта в результате наступления некоторого события. Существует много форм диаграмм состояний, незначительно отличающихся друг от друга семантикой.

Таб 2.1. Условные обозначения диаграммы состояний

Условное обозначение	Описание условного обозначения
	начальное состояние, не содержит никаких внутренних действий, в этом состоянии находится объект по умолчанию в начальный момент времени
	конечное состояние, которое также не содержит никаких внутренних действий. В этом состоянии будет находиться по умолчанию после завершения работы в конечный момент времени. Оно служит для указания графической области, в которой завершается процесс изменения состояния
	Состояние
	Переходом (transition) называется перемещение объекта из одного состояния в другое
	Рефлекторный переход

На диаграмме состояний может быть одно и только одно начальное состояние. В то же время может быть столько конечных состояний, сколько вам нужно, или их может не быть вообще. Когда объект находится в каком-то конкретном состоянии, могут выполняться различные процессы.

Процессы, происходящие в этот момент, когда объект находится в определенном состоянии, называются действиями (actions).

С состоянием можно связывать следующие данные: деятельность, входное действие, выходное действие и событие.

Деятельность (activity) - это поведение, реализуемое объектом, пока он находится в данном состоянии. Деятельность изображают внутри самого состояния; ее обозначению должно предшествовать слово do (делать) и двоеточие.

Входное действие (entry action) - это поведение, которое выполняется, когда объект переходит в данное состояние. Входное действие также показывают внутри состояния, его обозначению предшествуют слово entry (вход) и двоеточие.

Выходное действие (exit action) подобно входному. Однако оно осуществляется как составная часть процесса выхода из данного состояния. Выходное действие изображают внутри состояния, его описанию предшествуют слово exit (выход) и двоеточие.

Переходом (transition) называется перемещение объекта из одного состояния в другое. На диаграмме все переходы изображают в виде стрелки, начинающейся на первоначальном состоянии и заканчивающейся последующим.

Переходы могут быть рефлексивными. Объект может перейти в то же состояние, в котором он в настоящий момент находится. Рефлексивные переходы изображают в виде стрелки, начинающейся и завершающейся на одном и том же состоянии.

2.6 Диаграмма деятельности

Диаграммы активности (деятельности) частный случай диаграмм состояний. Каждое состояние есть выполнение некоторой операции и переход в следующее состояние. Диаграммы деятельности особенно полезны в описании поведения, включающего большое количество параллельных процессов. Самым большим достоинством диаграмм деятельностей является поддержка параллелизма. Благодаря этому они являются мощным средством моделирования потоков работ и, по существу, параллельного программирования. Самый большой их недостаток заключается в том, что связи между действиями и объектами просматриваются не слишком четко.

Рассмотрим пример диаграммы состояний автомобиля:



Рис 2.2. Диаграмма состояний автомобиля

Средства Rational Rose позволяют для описания функциональной системы воспользоваться графическим редактором для построения Activity диаграмм (деятельности).

Таб 2.2. Условные обозначения диаграммы деятельности

Условное обозначение	Описание условного обозначения
	начальное состояние, не содержит никаких внутренних действий, в этом состоянии находится объект по умолчанию в начальный момент времени
	конечное состояние, которое также не содержит никаких внутренних действий. В этом состоянии будет находиться по умолчанию после завершения работы в конечный момент времени. Оно служит для указания графической области, в которой завершается процесс изменения состояния
	состояние действий с некоторым входным действием и, по крайней мере, одним выходящим из состояния перехода. Внутри этой фигурки записывается выражение действий, которое должно быть уникальным в пределах одной диаграммы деятельности
	ветвление, применяемое в случаях, когда последовательно выполняемая деятельность должна разделиться на альтернативные ветви в зависимости от значения некоторого промежуточного результата. В этот ромб может входить только одна стрелка от того состояния, после выполнения которого, поток управления должен быть продолжен по одной из взаимно исключающих ветвей. Выходящих стрелок может быть две или более, но для каждой из них явно указывается соответствующее условие
	переход, т. е. отношение между двумя последовательными состояниями, которое указывает на факт смены одного состояния другим
	распараллеливание вычислений. Может иметь один входящий переход и несколько выходящих, либо несколько входящих и один выходящий

Диаграммы деятельностей предпочтительнее использовать в следующих ситуациях:

· анализ варианта использования. На этой стадии нас не интересует связь между действиями и объектами, а нужно только понять, какие действия должны иметь место и каковы зависимости в поведении системы. Связывание методов и объектов выполняется позднее с помощью диаграмм взаимодействия;

· анализ потоков работ (workflow) в различных вариантах использования. Когда варианты использования взаимодействуют друг с другом, диаграммы деятельностей являются мощным средством представления и анализа их поведения.

Рассмотрим диаграмму активности «заказ автомобиля»:

Рис.2.3. Диаграмма активности «заказ автомобиля»

2.7 Диаграммы взаимодействия

Диаграммы взаимодействия (interaction diagrams) описывают поведение взаимодействующих групп объектов. Каждая диаграмма описывает поведение объектов в рамках только одного прецедента. На диаграмме изображаются объекты и те сообщения, которыми они обмениваются между собой. Определяют три типа сообщений:

информационные (informative) - сообщения, снабжающие объект-получатель информацией для обновления его состояния;

сообщения - запросы (interrogative) - сообщения, запрашивающие выдачу информации об объекте-получателе;

императивные (imperative) - сообщения, запрашивающие у объекта-получателя выполнение действия.

Существует два вида диаграмм взаимодействия:

I. последовательности (sequence diagrams);

II. кооперативные (collaboration diagrams).

На диаграмме последовательности объект изображается в виде прямоугольника на вершине пунктирной вертикальной линии. Эта вертикальная линия называется линией жизни (lifeline) объекта. Она представляет собой фрагмент жизненного цикла объекта в процессе взаимодействия.

Каждое сообщение изображается в виде стрелки между линиями жизни двух объектов. Сообщения появляются в том порядке, как они показаны на странице, сверху вниз. Каждое сообщение помечается как минимум именем сообщения; при желании можно добавить также аргументы и некоторую управляющую информацию и, кроме того, показать самоделегирование (self-delegation) -сообщение, которое объект посылает самому себе, при этом стрелка сообщения указывает на ту же самую линию жизни.

Размещено на http://www.allbest.ru/

Рис.2.4. Диаграмма последовательности «заказ дополнительного оборудования»

Вторым видом диаграммы взаимодействия является кооперативная диаграмма. Подобно диаграммам последовательности, кооперативные диаграммы отображают поток событий через конкретный сценарий варианта использования. Диаграммы последовательности упорядочены по времени, а кооперативные диаграммы заостряют внимание на связях между объектами.



Рис.2.5. Диаграмма кооперации «заказ дополнительного оборудования»

Как видно из рисунка, здесь представлена вся та информация, которая была и на диаграмме последовательности, но кооперативная диаграмма по-другому описывает поток событий. Из нее легче понять связи между объектами, однако труднее уяснить последовательность событий.

По этой причине часто для какого-либо сценария создают диаграммы обоих типов. Хотя они служат одной и той же цели и содержат одну и ту же информацию, но представляют ее с разных точек зрения.

На кооперативной диаграмме, так же как и на диаграмме последовательности, стрелки обозначают сообщения, обмен которыми осуществляется в рамках данного варианта использования.

3. Проектирование БД

3.1 Требования, предъявляемые к базе данных

1) Минимальная избыточность. Данные, хранимые в памяти ЭВМ, могут содержать как полезную, так и вредную избыточность. Вредная избыточность всегда имеет место, когда каждый пользователь вынужден создавать для своих приложений отдельный набор данных. Если нескольким пользователям требовались бы одни и те же данные, то они повторялись бы в каждом наборе. Такую избыточность часто называют неконтролируемой, поскольку об её существовании отдельные пользователи могут и не подозревать. К полезной избыточности можно отнести периодические копии данных хранящихся в базе данных. Эта избыточность легко контролируется. Более того, она является необходимой, например, для восстановления данных, разрушенных при случайных сбоях в работе ЭВМ. Таким образом, требование минимальной избыточности следует понимать как устранение вредной (неконтролируемой) и сведение к минимуму полезной (контролируемой) избыточности.

2) Целостность данных. Целостность данных состоит в поддержании правильности данных. Обеспечивается восстановлением данных после разрушения в результате случайных сбоев в работе ЭВМ, а также устранения противоречивости данных, которое заключается в появлении различных экземпляров для одних и тех же атрибутов. Противоречивость может появиться при обновлении избыточных данных в том случае, если обновление будет выполнено только на части данных.

3) Безопасность и секретность. Обеспечивает защиту данных от аппаратных и программных сбоев, от катастрофических и криминальных ситуаций, а также от некомпетентного доступа к ним.

4) Независимость данных. Обеспечивает возможность изменения структуры базы данных без изменения прикладных программ пользователей. Понимается в двух аспектах, а именно, как логическая и физическая независимость.

Логическая независимость предлагает возможность изменения логической структуры баз данных, не затрагивая прикладных программ.

Физическая независимость подразумевает такую же возможность физической структуры баз данных, включая как способы размещения данных на физических носителях, так и методы доступа к данным (то есть операции поиска, чтения и записи данных в память ЭВМ). Обеспечение независимости данных представляет собой основную цель, преследуемую при создании базы данных.

5) Производительность. Характеризуется временем ответа информационной системы, использующей базы данных, на запросы пользователей. При этом запросы на данные должны удовлетворяться с такой скоростью, какая требуется для использования данных.

6) Гибкость и способность к расширению. Понимается как способность базы данных к наращиванию данных, а также увеличению количества возможных приложений и расширению функций в пределах каждого приложения.

3.2 Rational Rose Data Modeler средство проектирования БД

Авторы Data Modeler прежде всего ориентировались на создание инструмента проектирования физической модели данных. При этом не произошло отказа от UML как от средства моделирования данных, а некоторым образом были смещены акценты: теперь UML предполагается использовать для построения логической модели. По сути, логическая модель - это та же объектная модель, состоящая из объектов - сущностей. Переход от логической модели к физической и наоборот в части моделирования данных обеспечивается Rational Rose автоматически. Для этого введено соответствие элемент моделей

Таблица3.1. Соответствие элементов логической и физической модели

Логическая модель	Физическая модель
Class (Класс)	Table (Таблица)
Operation (Операция)	Constraint (Ограничение)
Attribute (Атрибут)	Column (Колонка)
Package (Пакет)	Scheme (Схема)
Component (Компонент)	Database (База данных)
Association (Ассоциация)	Relationship (Связь)
Нет	Trigger (Тригер)
Нет	Index (Индекс)

Таким образом, концептуально модуль Data Modeler не является заменой UML в некотором его подмножестве, а всего лишь дает приверженцам объектных технологий мощное средство эффективного построения физических схем БД.

Перечень основных возможностей Data Modeler включает в себя:

Data Modeler поддерживает большинство возможностей структурных CASE-средств в плане физического моделирования данных;

Data Modeler обеспечивает генерацию эффективной физической структуры БД, поддерживающей механизмы обеспечения ссылочной целостности;

Data Modeler тесно интегрирован с Rational Rose, а диаграмма Data Model естественным образом вписывается в общую технологию разработки ПО с использованием линейки продуктов фирмы Rational Software Corporation;

Можно отказаться от интеграции Rational Rose с другими средствами генерации физических моделей.

Обеспечивается концептуальное соответствие моделирования данных и объектных моделей, что позволяет более эффективно

3.3 Создание логической модели

Основные компоненты диаграммы Data Modeler - это сущности, атрибуты и связи. Каждая сущность является множеством подобных индивидуальных объектов, называемых экземплярами. Каждый экземпляр индивидуален и должен отличаться ото всех остальных экземпляров. Атрибут выражает определенное свойство объекта. На физическом уровне сущности соответствует таблица, экземпляру сущности - строка в таблице, а атрибуту - колонка таблицы.

Работа Data Modeler основана на известном механизме отображения объектной модели в реляционную. Результатом являются построение диаграммы «сущность - связь» и последующая генерация описания базы данных на SQL.

Диаграмма классов (class diagram) служит для представления статической структуры модели системы в терминологии классов объектно-ориентированного программирования. Диаграмма классов может отражать, в частности, различные взаимосвязи между отдельными сущностями предметной области, такими как объекты и подсистемы, а также описывает их внутреннюю структуру и типы отношений. На данной диаграмме не указывается информация о временных аспектах функционирования системы. С этой точки зрения диаграмма классов является дальнейшим развитием концептуальной модели проектируемой системы.



Рис 3.1. Диаграмма классов

Рассмотрим подробнее сущности таблиц диаграммы классов:

Таблица «клиенты» описывает данные, относящиеся к клиентам компании, т.к. ФИО, телефон и адрес:

Рис 3.2. таблица «клиенты»

Таблица «заказы» определяет заказ клиента на автомобиль и/или комплектующие для автомобиля.

В таблице содержатся сведения о номере заказа, дате поставки, дате сборки и фактической дате оформления заказа. Так же в таблице содержится информация о внесенной предоплате. Заказ считается полностью оплаченным, когда предоплата равна сумме стоимости автомобиля и всех комплектущих.

Рис 3.3. Таблица «Заказы»

Таблица запчасти/комплектующие описывает возможные комплектующие, которые можно заказать. Комплектующие характеризуются ценой, принадлежностью к конкретной модели автомобилей и иногда цветом. Цветовой характеристикой обладают комплектующие, участвующие в отделке салона.

Рис 3.4. таблица «Комплектуещие»

Таблица «Цвета» содержит цвета, в которые может быть окрашен автомобиль:

Рис 3.5. таблица «Цвета»

В таблице «Салон» хранятся данные о типе салона автомобиля- кожаный, тканевый или велюровый салон:

Рис 3.6. таблица «Салон»

Таблица «Трансмиссия» содержит тип коробки передач автомобиля: механическая КП, автоматическая КП, вариатор:

Рис 3.7 таблица «Трансмиссия»

В таблице «Двигатели» описываются типы двигателей и их объемы, которые возможно установить на авто.

Рис 3.8. таблица «Двигатели»

Таблица «пользователи» содержит сведения о пользователях создаваемой автоматизированной системы с указанием уровня доступа каждого.

Рис 3.9. таблица «Пользователи»

Таблица автомобилей описывает конкретные автомобили, которые имеются в автосалоне. Также здесь содержатся VIN авто, данные о предоплате и статус о территории нахождения авто (статус ведется от его поставки в порт и до продажи автомобиля)

Рис 3.10. таблица «Автомобили»

Каждому автомобилю соответствует конкретная модель.

Рис 3.11. таблица «Модели»

Таблица моделей описывает модели автомобилей различных марок. Для каждой модели установлена базовая цена в стандартной поставки. Она так же присутствует в таблице модели. Это цена берется по умолчанию при формировании заказа с автомобилем этой модели. Потом к цене за автомобиль в заказе прибавляются цены на комплектующие. Каждой модели соответствует конкретная марка производителя, список которых содержится в таблице brand.

Рис 3.12. Таблица «Бренды»

Создание схемы данных

Из к.з. меню на созданном пакете выполнить команду Data Modeler/Transform to Data Model.

В открывшемся окне в списке Target Database указать DB_0 и закрыть окно кнопкой ОК. В результате в логическом представлении в пакете Schemas появится пакет «Schema» S_0, в который войдут две таблицы Устройство для чтения карточек и Счет.

Из к.з. меню на пакете «Schema» S_0 выполнить команду Data Modeler/New/Data Model Diagram. В пакете «Schema» S_0 появится новая диаграмма NewDiagram (диаграмма «сущность - связь»).

Нанести на нее все классы-таблицы, находящиеся в пакете «Schema» S_0.

Рис 3.13. Физическая модель (Модель данных)

3.4 Выбор инструментального средства построения системы учета

В настоящее время используется большое количество различных достаточно мощных программных пакетов и сред, облегчающих работу пользователей по созданию БД и обработке данных в них. Наиболее совершенные из них имеют, как правило, удобный “дружественный” интерфейс для работы пользователя с пакетом в диалоговом режиме, простые и богатые по своим функциональным возможностям непроцедурные языки запросов, а также мощные средства автоматизации программирования (генераторы отчетов, экранных форм, меню, прикладных программ), позволяющие неквалифицированным пользователям создавать простые приложения без программирования, а квалифицированным пользователям значительно ускорять процесс создания сложных приложений.

Для создания баз данных используется архитектура клиент-сервер.

В качестве базы данных используется MySQL 5.0.

В качестве сервера используется Apache2.

Для создания графического интерфейса используются PHP и HTML.

В архитектуре клиент-сервер все задачи, связанные с доступом к данным, выполняются на центральном сервере. Особенностью архитектуры клиент-сервер является то, что один процесс может запросить информацию у другого процесса. В этой архитектуре вычислительная нагрузка распределена между клиентами и сервером. Под клиентом понимается программное обеспечение, которое с одной стороны взаимодействует с сервером баз данных, а с другой - с пользователем через графический интерфейс. При использовании этого типа архитектуры приложение выполняет все задачи, связанные с интерфейсом пользователя, логикой работы программы и проверкой целостности данных. Сервер отвечает за логику работы программы и проверку целостности данных.