Разработка объектно-ориентированной модели информационной подсистемы для дилерского пункта продажи автомобилей
Рисунок 6.15 — Создание компонента Task Specification на диаграмме компонентов Для обеспечения связи между компонентами, воспользуемся инструментом Dependency. Проведем связь от компонента Package Body «Order» к Package Specification «Order», от Package Body «TransactionManager» к Package Specification «TransactionManager», от Package Body «DataBase» к Package Specification «DataBase». Затем… Читать ещё >
Разработка объектно-ориентированной модели информационной подсистемы для дилерского пункта продажи автомобилей (реферат, курсовая, диплом, контрольная)
МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ ГОУ ВПО СЕВЕРО-КАВКАЗСКИЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ Факультет информационных технологий и телекоммуникаций Кафедра прикладной информатики ПОЯСНИТЕЛЬНАЯ ЗАПИСКА К КУРСОВОМУ ПРОЕКТУ НА ТЕМУ:
Разработка объектно-ориентированной модели информационной подсистемы для дилерского пункта продажи автомобилей Автор курсового проекта Сергиенко Е.А.
Специальность: 80 801 «Прикладная информатика в экономике»
Руководитель проекта к.т.н., доцент В. Ф. Ляхов Ставрополь, 2011
ВВЕДЕНИЕ
Необходимость решения вопроса автоматизации фирмы с помощью ЭВМ, привела к созданию информационной системы. Её разработка позволит улучшить качество обслуживания клиентов, автоматизировать продажу автомобилей, что приведет к привлечению клиентов и увеличению прибыли
Цель курсового проекта — разработать объектно-ориентированную подсистему складского учета для фирмы «КавказЮгАвто», на основе, которой в дальнейшем будет создана полнофункциональная информационная подсистема. Пояснительная записка состоит из введения, восьми разделов, заключения, библиографического списка литературы и приложения.
В первом разделе приводится краткая характеристика предметной области, характеристика предприятия. Отмечаются недостатки существующей технологии и способы их устранения. Также в этой главе описывается цель и назначение автоматизированного варианта решения задачи, ее экономическая сущность.
Во втором разделе приводится описание процесса создание диаграммы вариантов использования. Описывается обоснование выбора действующих лиц, функций разрабатываемой подсистемы.
В третьем разделе приводится процесс создания диаграммы последовательности.
В четвертом разделе описывается процесс создание диаграммы сотрудничества.
В пятом разделе рассматривается процесс создания диаграммы классов, процесс добавления деталей к описаниям операций и определения атрибутов класса. Также рассматривается процесс добавления связей между классами.
В шестом разделе рассматривается процесс создания диаграммы состояний для классов и диаграммы компонентов.
В седьмом разделе приводится процесс создания диаграммы размещения.
Кроме того можно будет ознакомиться с кодом программного продукта на языке C++, сгенерированного Rational Rose. Библиографический список содержит 10 литературных источников.
1 КРАТКАЯ ХАРАКТЕРИСТИКА ПРЕДМЕТНОЙ ОБЛАСТИ Фирма «КавказЮгАвто» занимается продажей автомобилей зарубежного производства, их дальнейшее сервисное обслуживание. В фирме можно приобрести модели автомобилей известных марок, таких, как «Audi», «Honda», «Skoda», так как дилерский пункт взаимодействует со многими официальными представителями производителей автомобилей, а так же можно сделать заказ на конкретную модель с понравившейся комплектацией. Для реализации этой функции и других, будет создана информационная система, позволяющая удовлетворять требования клиентов. Эти требования и пути их решения представлены в таблице 1.1.
Таблица 1.1 — Проблемные ситуации и пути их решения
Проблемная ситуация | Пути решения | |
У клиента отсутствует денежная сумма для покупки автомобиля | Возможность предоставления кредита | |
У фирмы нет в наличии нужной марки автомобиля | Заказа у официальных представителей данной марки | |
Клиенту по нраву марка автомобиля, но не устраивает комплектация | Изменение комплектации автомобиля в соответствии с требованиями | |
Автомобиль вышел из строя не по вине клиента за короткий срок | Предоставление сервисного обслуживания | |
Выводы
1. При проектировании информационной системы, следует учитывать проблемные ситуации, с которыми столкнется дилерский пункт, и пути их решения.
2. Следует учесть возможность добавления путей решения для непредвиденных ситуаций.
2 СОЗДАНИЕ ДИАГРАММЫ ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ Создание диаграммы производится вызовом контекстного меню на Use Case View и выбором меню New-> Use Case Diagram. Перейдя на созданную диаграмму нужно расположить необходимые элементы — актеров и вариантов использования. Для расположения актера щелкнем на его изображение и поместим на диаграмму и назовем его клиентом — «Client» (рисунок 2.1).
Рисунок 2.1 — Расположение актера на диаграмме вариантов использования Аналогичным образом расположим актеров дилерский пункт «DealerOffice» и кредитную систему «CreditSystem».
Для расположения вариантов использования щелкнем на соответствующем изображении на панели инструментов и поместим на диаграмму, назвав «Оформить заказ» — «MakeOrder» (рисунок 2.2). Добавим следующие варианты использования: осуществить покупку — «MakePurchase», получение информации о платеже — «GetPaymentInformation», осуществить платеж «MakePayment», оформить заказ — «MakeOrder», получение информации об автомобиле — «GetCarInformation», обслуживание автомобиля — «ServiceCar».
Рисунок 2.2 — Расположение варианта использования на диаграмме вариантов использования Для обеспечения связи между актерами и вариантами использования воспользуемся инструментом Unidirectional Assotiation — однонаправленной ассоциацией. Создадим связь от актера Client к варианту использования «MakePurchase». Щелкнем на изображение соответствующего инструмента, затем на актере и, зажав левую кнопку мыши, проведем связь до варианта использования (рисунок 2.3).
Аналогичным образом добавим связи от «Client» — «MakePayment», «MakeOrder», от варианта использования «MakePurchase» к «MakePayment», от «Make Payment» к актеру «CreditSystem», от «CreditSystem» к «GetPaymentInformation», от «GetPaymentInformation» к актеру «DealerOffice», от «DealerOffice» к вариантам использования «GetCarInformation» и «ServiceCar», а от данных элементам к актеру «Client».
Созданная диаграмма показана на рисунке 2.4.
Рисунок 2.3 — Создание однонаправленной связи на диаграмме вариантов использования Рисунок 2.4 — Диаграмма прецедентов информационной системы дилерского пункта продажи автомобилей «КавказЮгАвто»
Наиболее важным для реализации информационной подсистемы вариантом использования является «MakeOrder» — оформление покупателем заказа на автомобиль. Дальнейшее рассмотрение процесса проектирование мы будем производить на примере именно этого варианта использования. Сценарий варианта использования «MakeOrder» указан в таблице 2.1.
Таблица 2.1 — Сценарий варианта использования «MakeOrder»
Главный раздел | Типичный ход событий | Исключения | Примечания | |
Имя: MakeOrder Актер: Client Вариант использования служит для оформления клиентом заказа на автомобиль | 1. Ввод клиентом названия и варианта комплектации автомобиля. 2. Проверка полей заказа. 3. Проверка наличия автомобиля в базе данных 4.Вывод информации клиенту о вариантах комплектации автомобиля. 5. Выбор и подтверждение варианта комплектации. 6. Подтверждение клиентом заказа. 7. Выполнение транзакций. 8. Уведомление клиента о цене автомобиля. 9.Подтверждение пользователем заказа автомобиля. | Отсутствие необходимой модели автомобиля | Следует уведомить клиента о отсутствии модели автомобиля и отменить заказ | |
Клиент не согласен оплатить предъявленную сумму заказа | Выполнение транзакций не производится, заказ следует отменить | |||
Выводы
1. Построенная диаграмма вариантов использования документирует все варианты использования, входящие в информационную систему, действующих лиц и связи между ними.
2. По данной диаграмме можно судить о структуре предприятия.
3 СОЗДАНИЕ ДИАГРАММЫ ПОСЛЕДОВАТЕЛЬНОСТИ За базовый вариант использования примем оформить заказ, т. к это основной вариант использования, с которым будет работать клиент. Создадим на основе него диаграмму последовательности. Перенесем актера «Client» на созданную диаграмму, т.к. он инициирует базовый вариант использования. Создадим объекты (Object) «Заказ», «Менеджер транзакций» и «База данных автомобилей», поместив их по прядку перечисления выберем классы для этих объектов. Чтобы это сделать, требуется выделить нужный, вызвать контекстное меню и выбрать Open specification, затем в поле Class для объекта «Заказ № 1» выберем класс «Заказ», для «Менеджера транзакций» — «Менеджер транзакций», для «База данных автомобилей» — «База данных» (рисунок 3.1).
Рисунок 3.1 — Расположение объектов на диаграмме последовательности Создадим последовательность сообщений объекта (Object Message) от «Client» к «Заказ № 1». Выберем соответствующий инструмент и проведем линию от «Client» к «Заказ № 1» (рисунок 3.2). Аналогично создадим другие сообщения объектов. От объекта «Менеджер транзакций» к «Заказ № 1» — номер заказа (сообщение № 2). Т. е. при вводе клиентом марки автомобиля менеджером транзакций будет присваиваться номер заказа.
Рисунок 3.2 — Создание сообщения объекта После этого пользователь подтверждает заказ — создаем сообщение от «Client» к объекту «Заказ» (сообщение № 3). Данный объект совершает запрос на проверку заказа к «Менеджеру транзакций» (сообщение № 4). Он проверяет корректность заполнения полей. Данное сообщение будет типа Сообщение себе — Message to Self (сообщение № 5). После этого «Менеджер транзакций» совершает запрос в базу данных на заказ автомобиля (сообщение № 6)."База данных" проверяет наличие модели автомобиля — выбираем тип сообщения Message to Self (сообщение № 7). «База данных» передает сообщение «Менеджеру транзакций» о вариантах комплектации автомобиля (сообщение № 8), который затем передает их объекту «Заказ № 1» (сообщение № 9), а он, в свою очередь «Client» (сообщение № 10). Далее «Client» подтверждает комплектацию, сообщение приходит к объекту «Заказ № 1» (сообщение № 11), затем к «Менеджеру транзакций» (сообщение № 12), потом к базе данных (сообщение № 13). «База данных» производит заказ автомобиля (сообщение № 14) и передает цену заказа «Менеджеру транзакций» (сообщение № 15), он, в свою очередь сообщает данные о цене объекту «Заказ № 1» (сообщение № 16), а этот объект — «Client» (сообщение № 17).
Для актера «Client» все исходящие сообщения будут асинхронны. Для этого вызовем Open specification, зайдем на вкладку Detail и выберем Asynchronous (рисунок 3.3).
Рисунок 3.3 — Создание асинхронных сообщений Данные сообщения будут под номерами 1,3,11,18. Далее «Client» подтверждает заказ (сообщение № 18). Созданная диаграмма изображена на рисунке 3.4.
Рисунок 3.4 — Диаграмма последовательности информационной системы дилерского пункта продажи автомобилей «КавказЮгАвто»
Создадим альтернативный поток событий, который возникает, когда в базе данных отсутствует введенная клиентом марка автомобиля (рисунок 3.5).
Рисунок 3.5 — Диаграмма последовательности, альтернативный поток событий — отсутствует введенная марка автомобиля
Если клиент некорректно ввел данные, происходит другой альтернативный поток событий (рисунок 3.6).
Рисунок 3.6 — Диаграмма последовательности, альтернативный поток событий — неправильно заполнены поля При отмене клиентом заказа происходит следующий альтернативный поток событий (рисунок 3.7).
Рисунок 3.7 — Альтернативный поток событий — отмена заказа Выводы
1. По построенным диаграммам виден поток событий во времени.
2. Данная диаграмма отражает поток событий в рамках выбранного базового варианта использования.
4 СОЗДАНИЕ ДИАГРАММЫ СОТРУДНИЧЕСТВА Основываясь на выборе базового варианта использования и на диаграмме последовательности, создадим диаграмму сотрудничества. Вызовем контекстное меню на Use Case View и выберем New->Collaboration Diagram.
Переместим на неё актера «Client» и 3 объекта — «Заказ № 1», «Менеджер транзакций», «База данных автомобилей». Затем свяжем их с помощью объектной ссылки (Object Link). После этого следует создать связывающие сообщения (Link Message) и обратные связывающие сообщения (Reverse Link Message). Данные действия изображены на рисунке 4.1.
Рисунок 4.1 — Создание связей с помощью ссылок и сообщений на диаграмме сотрудничества Затем подпишем ссылки и сообщения (рисунок 4.2).
Рисунок 4.2 — Подписи ссылок и сообщений на диаграмме сотрудничества Так же можно создать данную диаграмму автоматически. Для этого откроем диаграмму последовательностей и нажмем на клавиатуре «F5». Данная диаграмма построится автоматически (рисунок 4.3).
Рисунок 4.3 — Диаграмма сотрудничества информационной системы дилерского пункта продажи автомобилей «КавказЮгАвто»
Вывод
1. Построив диаграмму сотрудничества, очевидно, что по ней легче понять связи между объектами, однако труднее понять временную последовательность событий.
5 СОЗДАНИЕ ДИАГРАММЫ КЛАССОВ Создадим диаграмму классов, вызвав контекстное меню на Local View и выбрав New -> Class Diagram. Перенесем на нее созданные ранее классы «Order», «TransactionManager» и «DataBase». Для обеспечения связи между ними воспользуемся инструментом Unidirectional Association. Выбрав соответствующий инструмент, проведем связь от «Order» к «TransactionManager», от
«TransactionManager» к DataBase (рисунок 5.1).
Рисунок 5.1 — Создание ассоциаций между классами на диаграмме классов Теперь добавим атрибуты в классы. Для этого вызовем контекстное меню на классе «Order» выберем команду New Attribute (рисунок 16)
Рисунок 5.2 — Создание нового атрибута на диаграмме классов Назовем созданный атрибут number. Указание типа атрибута производится через двоеточие — number: int. Выполнив команду New Attribute, создадим следующие атрибуты:
1. summ: double — отвечает за сумму автомобиля.
2. model_auto:string — хранится информация о марке автомобиля.
3. DateOrder: Date — дата покупки.
Создадим аналогичным способом атрибуты для класса «TransactionManager»:
1. Id: int — идентификатор действия.
2. number: int — номер заказа.
Аттрибуты для «DataBase»:
1. CarModel: String — модель автомобиля.
2. Summ: double — сумма автомобиля.
3. IdCar — идентификатор автомобиля.
4. YearCreate: Date — дата создания автомобиля.
5. Engine: String — информация о двигателе.
6. ColorCar: String — цвет автомобиля.
7. CountryCreate: String — страна-производитель.
8. Wheels_disks:String — информация о колесах и дисках.
Созданные атрибуты показаны на рисунке 5.3.
Рисунок 5.3 -Атрибуты классов на диаграмме классов Для создания операций в классе Order выполним команду New Operation в контекстном меню (рисунок 5.4).
Рисунок 5.4 — Команда создания новой операции на диаграмме классов Назовем созданную операцию GetSumm. Передаваемые параметры указываются в скобках, а тип возвращаемого значения через двоеточие — GetSumm (sum: double): double. Аналогично создадим следующие операции для «Order»:
1. GetSumm (): double — получить цену заказанного автомобиля.
2. SetModelAuto () — установить выбранную модель автомобиля.
3. AcceptOrder () — подтверждение заказа.
4. CancelOrder () — отменить заказ.
5. GetCharacteristics () — получить варианты комплектации автомобиля.
6. AcceptCharacteristics () — подтверждение вариантов комплектации автомобиля.
7. EnterModel (): string — ввод марки автомобиля.
8. GetNumber (): int — получить номер заказа.
9. CheckOrder () — запрос на проверку заказа.
10. OutputVariantsOrder () — вывод возможной комплектации пользователю.
11. SetVariantsOrder () — установить выбранный вариант комплектации пользователем.
Для класса «TransactionManager» операции будут следующими:
1. SetNumber ():int — установка номера заказа.
2. CheckAll () — проверить заполнение полей ввода.
3. QuerryToDB_car () — запрос автомобиля в БД.
4. GetCharacteristicsFromDB () — получить характеристики из БД.
5. SetCharacteristicsToOrder () — отправить характеристики в окно заказа.
6. GetSummFromDB (): Double — установленная сумма в БД.
7. SetSummToOrder (): Double — выбранная сумма в БД.
8. GetClientCharacteristicsFromOrder () — получить комплектацию автомобиля, выбранную клиентом.
9. SetClientsCharacteristicsToDB () — установить комплектацию автомобиля, выбранную клиентом для отправки в БД.
10. QuerryCheck () — запрос на проверку заказа из формы заказа.
В «DataBase» создадим текущие операции:
1. CheckModel ():bool — проверка наличия модели автомобиля.
2. QuerryCar () — проверка наличия автомобиля.
3. SetCharacteristics () — установить комплектацию автомобиля.
4. GetCharacteristics () — получить установленную клиентом комплектацию автомобиля.
5. SetOrder () — принять заказ.
6. SetSumm ():double — установить сумму автомобиля.
Так же следует ввести операции для работы с базой данных:
1. AddItem () — добавить запись в БД.
2. DeleteItem () — удалить запись в БД.
3. Update () — обновить БД.
4. AddOrder () — добавить заказ.
5. DeleteOrder () — удалить заказ.
Созданные операции и готовая диаграмма изображена на рисунке 5.5.
Рисунок 5.5 — Диаграмма классов информационной системы дилерского пункта продажи автомобилей «КавказЮгАвто»
Выводы
1. Построенная диаграмма классов наглядно показывает структуры классов, их операции и атрибуты.
2. Диаграмма позволяет судить о взаимосвязи классов.
6 СОЗДАНИЕ ДИАГРАММ СОСТОЯНИЙ ДЛЯ КЛАССОВ И ДИАГРАММЫ КОМПОНЕНТОВ Построим диаграмму состояния для класса Order. Создадим её, вызвав контекстное меню на Logical View и выбрав New -> Statechart Diagram. Перенесем с панели инструментов начальное и конечное состояние — соответственно Start State и End State (рисунок 20).
Рисунок 6.1 — Расположение начального и конечного состояния класса на диаграмме состояний Для расположения состояния выберем соответствующий инструмент State и поместим его на диаграмму, назвав «Запуск». Этим же образом создадим состояния «Ожидание активности» пользователя и «Выполнение команды». Далее создадим действия, инициируемые данным состоянием, вызвав контекстное меню и выбрав команду Open specification состояния «Запуск». Затем перейдем на вкладку Actions (рисунок 6.1).
подсистема диаграмма программный код Рисунок 6.1 — Вкладка Actions класса Order
Создадим новое действие, вызвав контекстное меню в таблице и выбрав команду Insert. По умолчанию в нее добавится действие, происходящее при входе данное состояние — Entry. Для редактирования данного действия требуется произвести двойной щелчок по нему. Появится форма редактирования, показанная на рисунке 6.2. В поле Name напишем «Инициализация компонентов» — т. е. при вхождении в данное состояние первым делом будут инициализироваться компоненты класса.
Рисунок 6.2 — Форма редактирования действия состояния Аналогично создадим следующие действия состояния класса:
1. Entry — соединение с менеджером транзакций.
2. Do — соединение с БД.
3. Exit — Переход к ожиданию действий клиента.
После этого введем действия состояния «Ожидание активности пользователя»:
1. Entry — инициализация событий.
2. Do — ожидание событий пользователя.
3. Exit — переход к выполнению команд.
Затем создадим действия для состояния «Выполнение команд»:
1. Entry — загрузка команд.
2. Do — выполнение команды пользователя.
3. Exit — сохранение значений полей.
4. Exit — завершение работы.
Для связи состояний используется инструмент State Transition. Соединим с помощью его состояния по порядку, указанному на рисунке 6.3.
Рисунок 6.3 — Создание переходов состояний на диаграмме состояний Созданная диаграмма показана на рисунке 6.4.
Рисунок 6.4 — Диаграмма состояний класса «Order» на диаграмме состояний После создания новой создания диаграммы состояний класса «TransactionManager» выполним аналогичные действия, перенеся начальное и конечное состояние и добавив следующие состояния и действия:
Состояние «Загрузка» (рисунок 6.5):
1. Entry — соединение с БД.
2. Do — загрузка команд.
3. Exit — переход к обработке данных.
Рисунок 6.5 — Состояние загрузка класса «TransactionManager» и действия этого состояния на диаграмме состояний Состояние «Обработка данных» (рисунок 6.6):
1. Entry — обработка поступивших данных.
2. Do — создание выходной обработанной информации.
3. Exit — сохранение всех данных.
Рисунок 6.6 — Состояние обработка данных класса TransactionManager и его действия на диаграмме состояний Затем воспользуемся инструментом State Transition и Transition to Self (рисунок 6.7).
Рисунок 6.7 — Создание переходов состояний класса TransactionManager на диаграмме состояний После завершения данной диаграммы создадим новую диаграмму состояний класса «DataBase», проделав указанные выше действия создания новой диаграммы. Перенесем на нее начальное и конечное действие. Затем выберем инструмент State и создадим два состояния: «Инициализация» и «Обработка запросов».
Создадим действия для состояния «Инициализация» методом, указанным выше:
1. Entry — создание подключения.
2. Do — загрузка запросов БД.
3. Exit — переход к обработке запросов.
Данное состояние показано на рисунке6.
Рисунок 6.8 — Состояние инициализация класса «DataBase» на диаграмме состояний
Перейдем к созданию действий для состояния Обработка запросов:
1. Entry — обработка запроса.
2. Do — создание выходных данных.
3. Exit — закрытие соединения с БД.
Текущее состояние изображено на рисунке 6.9.
Рисунок 6.9 — Состояние обработка запросов класса «DataBase» на диаграмме состояний Завершив создание состояний, перейдем к расположению переходов. Выбрав инструменты, расположим состояния переходов, как показано на рисунке 6.10.
Рисунок 6.10 — Создание переходов состояний класса DataBase на диаграмме состояний Построенные диаграммы классов «TransactionManager» и «DataBase» показаны соответственно на рисунках 6.11 и 6.12.
Рисунок 6.11 — Диаграмма состояния класса «TransactionManager»
Рисунок 6.12 — Диаграмма состояния класса «DataBase»
Теперь приступим к созданию диаграммы компонентов.
Вызовем контекстное меню в браузере на Component View и выполним команду New-> Component Diagram. Появится новая диаграмма компонентов. Откроем ее, сделав двойной щелчок. Для добавления компонентов воспользуемся панелью инструментов. Выберем инструмент Package Specification и щелкнем на диаграмме. Появится соответствующий компонент, который переименуем в «Order». Добавим данным инструментом еще два компонента, дав им имена"TransactionManager" и «DataBase» (рисунок 6.13).
Рисунок 6.13 — Создание компонентов Package Specification на диаграмме компонентов Затем выберем инструмент Package Body и щелкнем три раза на диаграмме компонентов. Появившимся компонентам присвоим имена «Order»,
«TransactionManager» и «DataBase» (рисунок 6.14)
Рисунок 6.14 — Создание компонентов Package Body на диаграмме компонентов Теперь выберем инструмент Task Specification и щелкнем на диаграмме. Дадим появившемуся компоненту имя DealerCar. exe (рисунок 6.15).
Рисунок 6.15 — Создание компонента Task Specification на диаграмме компонентов Для обеспечения связи между компонентами, воспользуемся инструментом Dependency. Проведем связь от компонента Package Body «Order» к Package Specification «Order», от Package Body «TransactionManager» к Package Specification «TransactionManager», от Package Body «DataBase» к Package Specification «DataBase». Затем соединим Package Specification «Order» с Package Specification «TransactionManager», а Package Specification «TransactionManager» с Package Specification «DataBase». После этого останется соединить Package Specification «Order» и Task Specification DealerCar. exe (рисунок 6.16).
Рисунок 6.16 — Создание связей с помощью инструмента Dependency на диаграмме компонентов В результате получилась готовая диаграмма компонентов (рисунок 6.16).
Рисунок 6.16 — Диаграмма компонентов информационной системы дилерского пункта продажи автомобилей «КавказЮгАвто»
Выводы
1. Данная диаграмма позволяет видеть поведения классов «DataBase», «TransactionManager» и «Order».
2. Диаграмма дает возможность просмотра действия каждого состояния класса.
3. Диаграмма компонентов позволяет представить модель на физическом уровне.
7 ПОСТРОЕНИЕ ДИАГРАММЫ РАЗМЕЩЕНИЯ Пустая диаграмма размещения уже присутствует в модели информационной системы и называется Deployment View. Откроем ее, дважды щелкнув на ней в браузере. Теперь следует разместить элементы. Для этого выберем инструмент Processor и поместим его на диаграмму, назвав «DataBaseServer» — Сервер базы данных. Аналогично разместим следующие элементы инструментом Processor:
«DealerCarServer», «Terminal№ 1», «Terminal№ 2», «Terminal№ 3». Затем, выбрав инструмент Device, поместим его на диаграмму и назовем «Printer» (рисунок 33).
Рисунок 33 — Расположение процессоров и устройства на диаграмме размещения После размещения процессоров и устройств, приступим к созданию процессов. Для начала создадим процесс для процессора «DataBaseServer». Вызвав на нем контекстное меню, выберем команду Open specification и перейдем на вкладку Detail. В таблице Processes снова вызовем контекстное меню и щелкнем на Insert. Назовем его «Oracle Server». Сохраним, нажав на форме кнопку OK. Проделаем те же действия на процессоре «DealerCarServer», назвав процесс «DealerCarServer.exe», и на терминалах, назвав процессы «DealerCarClient.exe». Для отображения процесса на диаграмме, вызовем контекстное меню на каждом процессоре и выберем команду Show Processes. После этих действий процессы появится на диаграмме рядом с процессорами (рисунок 34).
Рисунок 34 — Отображение процессов на диаграмме размещения Создадим связи между процессорами и устройством. Для этого следует выбрать инструмент Connection. Соединим с помощью него «DataBaseServer» и «DealerCarServer», «DealerCarServer» и терминалы. От устройства «Printer» проведем связь к «DealerCarServer» (рисунок 35).
Рисунок 35 — Создание связей между процессорами и устройством Готовая диаграмма размещения представлена на рисунке 37.
Рисунок 37 — Диаграмма размещения информационной системы дилерского пункта продажи автомобилей «КавказЮгАвто»
Выводы
1. Диаграмма позволяет рассмотреть аппаратную часть программы.
2. Возможность просмотреть процессы для каждого устройства.
8 ГЕНЕРАЦИЯ ПРОГРАМНОГО КОДА C++
Для генерации кода вначале в настройках компонентов поставим язык C++, вызвав контекстное меню на компоненте и в поле Language выбрав C++ (рисунок 38). Проделаем данное действие для всех компонентов.
Рисунок 38 — Форма с выбором языка генерации кода Затем соединим необходимые компоненты «DataBase» и «DataBase» (Package Body и Package Specification) с соответствующим классом как показано на рисунке 39. Если все сделано правильно, в скобках после имени класса появятся имена компонентов.
Рисунок 39 — Соединение компонентов с соответствующими классами По аналогии соединим компоненты «TransactionManager» (Package Body и Package Specification) c классом «TransactionManager», а «Order» (Package Body и Package Specification) с классом «Order». Затем на диаграмме компонентов выделим все элементы, вызовим контекстное меню и выполним команду Tools -> C++ -> Code generation. Появится форма С++, где можно наблюдать генерацию кода (рисунок 40).
Рисунок 40 — Форма генерации кода По умолчанию файлы с генерируемым кодом появятся в папке source в C: Program FilesRationalRoseC++.
Выводы
1. Код созданных ранее классов можно сгенерировать на желаемом языке.
2. Сгенерировав код в дальнейшем можно приступить к его редактированию.
ЗАКЛЮЧЕНИЕ
В курсовом проекте была разработана объектно-ориентированная подсистема предприятия на графическом языке моделирования UML. Разработанная модель UML отвечает всем канонам объектно ориентированного подхода, и требованиям, предъявляемым к подсистеме со стороны предприятия.
Разработанная объектно-ориентированная модель информационной подсистемы содержит одну диаграмму прецедентов, четыре диаграммы последовательности (одну для основного потока, и три для альтернативных), одну диаграмму классов, компонентов, сотрудничества, и три диаграммы состояний. Диаграмма классов содержит три класса: «Order», «TransactionManager» и «DataBase». В курсовом проекте сгенерирован программный код для языка С++. Программный код сгенерирован Rational Rose для всех классов информационной подсистемы. Всего сгенерировано 6 файлов — три заголовочных: DataBase. h (размер 9,13 Кб), Order. h (размер 8,53 Кб), TransactionManager. h (размер 6,53 Кб) и три файлов ресурсов: DataBase. cpp (размер 4,53 Кб), Order. cpp (размер 4,33 Кб), TransactionManager. cpp (размер 5,40 Кб). Данные файлы с кодом будут предоставлены на компакт диске, прилагаемому к курсовому проекту.
Объектно-ориентированная модель информационной подсистемы, разработанная в рамках курсового проекта, представляет собой серверную часть, и не имеет клиентской части. Данная подсистема имеет большие перспективы развития, и одновременно является неполноценной т.к. содержит только клиентскую часть.
Разработка серверной части позволит создать полноценную информационную подсистему, и перейти к процессу написания самой подсистемы, и её внедрения на предприятии.
БИБЛИОГРАФИЧЕСКИЙ СПИСОК
1. Петров, А. И. Информационные системы [Текст] / А. И. Петров. — М.: Горячая линия — Телеком, 2000. — 300с, ил.
2. Буч, Г. Язык UML для пользователя: Пер. с англ [Текст] / Г. Буч, Л — Рамбо, А. Джекобсон. — М.: ДМК, 2000. — 432 с, ил. (Серия «для программистов»).
3. Боггс, У. UML и Rational Rose: Пер. с англ [Текст] / У. Боггс, М. Боггс. — М.: Издательство «Лори», 2000. — 581 с.
4. Архангельский, А. Я. Программирование в Delphi 7 [Текст] / А. Я. Архангельский. — М.: ООО «Бином-Пресс», 2003. — 1152 с.
5. Хоффман, Л. Современные методы защиты информации [Текст] /: пер. с англ. Л. Хоффман. — М: Сов. радио, 1980.
6. Буч, Г. Язык UML для пользователя: Пер. с англ [Текст] / Г. Буч, Д. Рамбо, А. Джекобсон. — М: ДМК, 2000. — 432 с, ил. (Серия «для программистов»).
7. Боггс, У. UML и Rational Rose: Пер. с англ [Текст] / У. Боггс, М. Боггс. — М.: Издательство «Лори», 2000. — 581 с.
8. Буч, Г., Рамбо Д., Джекобсон A. UML [Текст] /: специальный справ-очник. — СПб.: Питер, 2002. — 432 с, ил.
9. Ларман, К. применение UML и шаблонов проектирования [Текст] /: Пер. с англ. К. Ларман — М.: Издательский дом «Вильяме», 2001. — 496 с, ил.
10. Петров, В. A. CASE — новые технологии в информатизации общества [Текст] / В. А. Петров. — Ред. журн. «Проблемы информатизации». — Москва, 2003, 27 с. — Деп. во ВИ11ИТИ 27.09.03, № 6953-В85.
ПРИЛОЖЕНИЕ, А Сгенерированный Rational Rose листинг кода приложения на языке C++
Source File: DataBase. cpp
//## begin module%1.7%.codegen_version preserve=yes
// Read the documentation to learn more about C++ code generator
// versioning.
//## end module%1.7%.codegen_version
//## begin module%4DFA3BB901D4.cm preserve=no
// %X% %Q% %Z% %W%
//## end module%4DFA3BB901D4.cm
//## begin module%4DFA3BB901D4.cp preserve=no
//## end module%4DFA3BB901D4.cp
//## Module: DataBase%4DFA3BB901D4; Package body
//## Subsystem:
//## Source file: C: Program FilesRationalRoseC++sourceDataBase.cpp
//## begin module%4DFA3BB901D4.additionalIncludes preserve=no
//## end module%4DFA3BB901D4.additionalIncludes
//## begin module%4DFA3BB901D4.includes preserve=yes
//## end module%4DFA3BB901D4.includes
// DataBase
#include «DataBase.h»
//## begin module%4DFA3BB901D4.declarations preserve=no
//## end module%4DFA3BB901D4.declarations
//## begin module%4DFA3BB901D4.additionalDeclarations preserve=yes
//## end module%4DFA3BB901D4.additionalDeclarations
// Class DataBase
DataBase:DataBase ()
//## begin DataBase: DataBase%4DE35177030D_const.hasinit preserve=no
//## end DataBase: DataBase%4DE35177030D_const.hasinit
//## begin DataBase: DataBase%4DE35177030D_const.initialization preserve=yes
//## end DataBase: DataBase%4DE35177030D_const.initialization
{
//## begin DataBase: DataBase%4DE35177030D_const.body preserve=yes
//## end DataBase: DataBase%4DE35177030D_const.body
}
DataBase:DataBase (const DataBase &right)
//## begin DataBase: DataBase%4DE35177030D_copy.hasinit preserve=no
//## end DataBase: DataBase%4DE35177030D_copy.hasinit
//## begin DataBase: DataBase%4DE35177030D_copy.initialization preserve=yes
//## end DataBase: DataBase%4DE35177030D_copy.initialization
{
//## begin DataBase: DataBase%4DE35177030D_copy.body preserve=yes
//## end DataBase: DataBase%4DE35177030D_copy.body
}
DataBase:~DataBase ()
{
//## begin DataBase:~DataBase%4DE35177030D_dest.body preserve=yes
//## end DataBase:~DataBase%4DE35177030D_dest.body
}
DataBase & DataBase: operator=(const DataBase &right)
{
//## begin DataBase: operator=%4DE35177030D_assign.body preserve=yes
//## end DataBase: operator=%4DE35177030D_assign.body
}
int DataBase: operator==(const DataBase &right) const
{
//## begin DataBase: operator==%4DE35177030D_eq.body preserve=yes
//## end DataBase: operator==%4DE35177030D_eq.body
}
int DataBase: operator≠(const DataBase &right) const
{
//## begin DataBase: operator≠%4DE35177030D_neq.body preserve=yes
//## end DataBase: operator≠%4DE35177030D_neq.body
}
//## Other Operations (implementation)
void DataBase: QuerryCar ()
{
//## begin DataBase: QuerryCar%4E01BA43031C.body preserve=yes
//## end DataBase: QuerryCar%4E01BA43031C.body
}
bool DataBase: CheckModel ()
{
//## begin DataBase: CheckModel%4DE35C5F032C.body preserve=yes
//## end DataBase: CheckModel%4DE35C5F032C.body
}
void DataBase: SetCharacteristicsToMenTr ()
{
//## begin DataBase: SetCharacteristicsToMenTr%4DE9F9D701D4.body preserve=yes
//## end DataBase: SetCharacteristicsToMenTr%4DE9F9D701D4.body
}
void DataBase: GetClientCharacteristics ()
{
//## begin DataBase: GetClientCharacteristics%4DE9F9CE0271.body preserve=yes
//## end DataBase: GetClientCharacteristics%4DE9F9CE0271.body
}
void DataBase: SetOrder ()
{
//## begin DataBase: SetOrder%4DE35D1D0167.body preserve=yes
//## end DataBase: SetOrder%4DE35D1D0167.body
}
double DataBase: SetSumm ()
{
//## begin DataBase: SetSumm%4DE35C940109.body preserve=yes
//## end DataBase: SetSumm%4DE35C940109.body
}
void DataBase: AddItem ()
{
//## begin DataBase: AddItem%4DE9F4E1002E.body preserve=yes
//## end DataBase: AddItem%4DE9F4E1002E.body
}
void DataBase: DeleteItem ()
{
//## begin DataBase: DeleteItem%4DE9F4F2002E.body preserve=yes
//## end DataBase: DeleteItem%4DE9F4F2002E.body
}
void DataBase: Update ()
{
//## begin DataBase: Update%4DE9F51C01F4.body preserve=yes
//## end DataBase: Update%4DE9F51C01F4.body
}
void DataBase: AddOrder ()
{
//## begin DataBase: AddOrder%4DEA43F20128.body preserve=yes
//## end DataBase: AddOrder%4DEA43F20128.body
}
void DataBase: DeleteOrder ()
{
//## begin DataBase: DeleteOrder%4DEA43FE02AF.body preserve=yes
//## end DataBase: DeleteOrder%4DEA43FE02AF.body
}
// Additional Declarations
//## begin DataBase%4DE35177030D.declarations preserve=yes
//## end DataBase%4DE35177030D.declarations
//## begin module%4DFA3BB901D4.epilog preserve=yes
//## end module%4DFA3BB901D4.epilog