Автоматизированная информационная система автосалона

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

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

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

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

1.7 Вывод по главе  1

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

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

2.1 Требования, предъявляемые  к информационной  системе

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

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

ü  Минимальная избыточность. Данные, хранимые в БД, могут содержать как "полезную", так и "вредную" избыточность. Последняя всегда имеет место при отсутствии концептуального представления данных, когда каждый пользователь создает для своих приложений отдельный набор данных. В этом случае, если нескольким пользователям требуются одни и те же данные, то они должны быть повторены в каждом наборе. Такая избыточность является неконтролируемой, поскольку, о ее существовании пользователи могут и не подозревать. Интеграция пользовательских представлений в единое концептуальное представление, как правило, устраняет эту избыточность данных. К "полезной" избыточности можно отнести периодические копии данных, хранящихся в БД. Эта избыточность легко контролируется. Более того, она является необходимой, например, для восстановления данных, разрушенных при случайных сбоях и непредвиденных ситуациях.

Таким образом, требование минимальной избыточности следует понимать как устранение "вредной"" (неконтролируемой) и сведение к минимуму "полезной" (контролируемой) избыточности данных;

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

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

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

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

ü  Производительность. Характеризуется временем ответа на запросы пользователей.

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

2.2 Проектирование базы  данных в Rational Rose Data Modeler  

При создании программных  систем процесс создания структуры  данных (модели) является одним из важнейших  этапов. Однако до недавнего времени  аналитики-проектировщики, работающие с Rational Rose, должны были обращаться к  другим CASE-средствам для автоматизации  этого процесса, например, к ERwin компании PLATINUM. С появлением подключаемого  модуля (Add-In) под названием Data Modeler у  разработчиков появилась возможность  не отказываться от своего любимого инструмента  и использовать Rational Rose не только для  создания логического представления  системы, но и для моделирования  физического представления данных.

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

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

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

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

Подводя итог, к  основным особенностям Data Modeler стоит  отнести:

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

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

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

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

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

2.3 Проектирование логической  модели базы данных

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

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

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

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

Рис. 2.2. Таблица  «СТО». 

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

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

В таблице «клиенты»  содержатся данные о клиентах компании, без разделения на клиентов СТО и  клиентов отдела продаж автомобилей Lada.

В этой таблице  хранятся данные о ФИО клиента, его  контактном телефоне, адрес места  проживания, серия и номер паспорта, а так же номер водительского  удостоверения.

Рис. 2.4. Таблица  «Новые автомобили».

В данной таблице  отображаются сведения о новых автомобилях  приобретаемых компанией «Питер-Лада». Таблица содержит данные о модели автомобиля, его цвете, VIN – номере, комплектации и статус, в котором  находится автомобиль. Если в статусе  стоит Spb, значит автомобиль находится  в наличии, и стоит на складе автосалона. Так же в статусе могут стоять следующие данные:

Таб. 2.2 Статусы  новых автомобилей

*Покраска автомобилей  в определенный цвет производится  строго по графику, например  в цвет 606 - «Млечный путь» 11-12 числа  каждого месяца, а цвет 105 – «Франкония»  только 1-го числа. 

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

Таблица «Заказы» определяет заказ клиента на конкретный автомобиль. В таблице отображаются данные о номере заказа, модели выбранного автомобиля, дате сборки , дате оформления договора с клиентом, ФИО менеджера  составившего договор, данные об оставленной  клиентом предоплате. Отдельное внимание стоит уделить графе «автомобиль  в зачет». Если клиент сдает свой старый автомобиль по программе утилизации, то в графе ставится значение «Да», и клиенту предоставляется скидка в 50 000 рублей, в противном случае ставится значение «Нет» и скидка не предоставляется.

Рис.2.6. Таблица  «Утилизация».

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

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

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

Рис. 2.8. Таблица  «Дополнительное оборудование». 

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

Рис. 2.9. Таблица  «Диски».

Содержит информацию о радиусе и фирме-производителе  оригинальных дисков.

Рис. 2.10. Таблица  «Мультимедиа»

Данная таблица  отображает сведения о фирме мультимедийной системы, сведения о ее размерах (1-2 din), а так же информацию о ее основных функциях.

Для создания физической модели базы данных, из меню на пакете Моя модель выполняем команду  Þ Data Modeler/Transform to Data Model.

В открывшемся  окне в списке Target Database указать DB_0 и  закрыть окно кнопкой ОК. В результате в логическом представлении в  пакете Schemas появится пакет «Schema» S_0, в которую войдут все таблицы  имеющие стереотип Сущность (entity). После чего из меню на пакете «Schema» S_0 выполняем команду Þ Data Modeler/New/Data Model Diagram. В пакете «Schema» S_0 появится новая диаграмма NewDiagram (диаграмма  «сущность – связь»). Затем открываем  эту диаграмму и наносим на нее все классы – таблицы, находящиеся  в пакете «Schema» S_0.