Разработка объектно-ориентированной модели информационной подсистемы для дилерского пункта продажи автомобилей
МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ
ГОУ ВПО СЕВЕРО-КАВКАЗСКИЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ
Факультет информационных технологий и телекоммуникаций
Кафедра прикладной информатики
ПОЯСНИТЕЛЬНАЯ ЗАПИСКА
К КУРСОВОМУ ПРОЕКТУ НА ТЕМУ:
Разработка объектно-ориентированной модели информационной
подсистемы для дилерского пункта продажи автомобилей
Автор курсового проекта
Сергиенко Е.А.
Специальность: 080801 «Прикладная информатика в экономике»
Руководитель проекта
к.т.н. ,доцент В. Ф. Ляхов
Ставрополь, 2011
ВВЕДЕНИЕ
Необходимость решения вопроса автоматизации фирмы с помощью ЭВМ, привела
к созданию информационной системы. Её разработка позволит улучшить качество
обслуживания клиентов, автоматизировать продажу автомобилей, что приведет к привлечению
клиентов и увеличению прибыли
Цель курсового проекта - разработать объектно-ориентированную подсистему
складского учета для фирмы «КавказЮгАвто», на основе, которой в дальнейшем
будет создана полнофункциональная информационная подсистема. Пояснительная
записка состоит из введения, восьми разделов, заключения, библиографического
списка литературы и приложения.
В первом разделе приводится краткая характеристика предметной области,
характеристика предприятия. Отмечаются недостатки существующей технологии и
способы их устранения. Также в этой главе описывается цель и назначение
автоматизированного варианта решения задачи, ее экономическая сущность.
Во втором разделе приводится описание процесса создание диаграммы
вариантов использования. Описывается обоснование выбора действующих лиц,
функций разрабатываемой подсистемы.
В третьем разделе приводится процесс создания диаграммы
последовательности.
В четвертом разделе описывается процесс создание диаграммы
сотрудничества.
В пятом разделе рассматривается процесс создания диаграммы классов,
процесс добавления деталей к описаниям операций и определения атрибутов класса.
Также рассматривается процесс добавления связей между классами.
В шестом разделе рассматривается процесс создания диаграммы состояний для
классов и диаграммы компонентов.
В седьмом разделе приводится процесс создания диаграммы размещения.
Кроме того можно будет ознакомиться с кодом программного продукта на
языке C++, сгенерированного Rational Rose. Библиографический список содержит 10
литературных источников.
1 КРАТКАЯ ХАРАКТЕРИСТИКА ПРЕДМЕТНОЙ ОБЛАСТИ
Фирма «КавказЮгАвто» занимается продажей автомобилей зарубежного
производства, их дальнейшее сервисное обслуживание. В фирме можно приобрести
модели автомобилей известных марок, таких, как «Audi», «Honda»,
«Skoda», так как дилерский пункт
взаимодействует со многими официальными представителями производителей
автомобилей, а так же можно сделать заказ на конкретную модель с понравившейся
комплектацией. Для реализации этой функции и других, будет создана
информационная система, позволяющая удовлетворять требования клиентов. Эти
требования и пути их решения представлены в таблице 1.1.
Таблица 1.1 - Проблемные ситуации и пути их решения
Проблемная
ситуация
|
Пути решения
|
У клиента отсутствует денежная
сумма для покупки автомобиля
|
Возможность предоставления
кредита
|
У фирмы нет в наличии
нужной марки автомобиля
|
Заказа у официальных
представителей данной марки
|
Клиенту по нраву марка
автомобиля, но не устраивает комплектация
|
Изменение комплектации автомобиля
в соответствии с требованиями
|
Автомобиль вышел из строя
не по вине клиента за короткий срок
|
Предоставление сервисного
обслуживания
|
Выводы
1. При проектировании информационной системы, следует учитывать
проблемные ситуации, с которыми столкнется дилерский пункт, и пути их решения.
. Следует учесть возможность добавления путей решения для непредвиденных
ситуаций.
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.Подтверждение пользователем заказа автомобиля.
|
Отсутствие необходимой
модели автомобиля
|
Следует уведомить клиента о
отсутствии модели автомобиля и отменить заказ
|
|
|
Клиент не согласен оплатить
предъявленную сумму заказа
|
Выполнение транзакций не
производится, заказ следует отменить
|
Выводы
. Построенная диаграмма вариантов использования документирует все
варианты использования, входящие в информационную систему, действующих лиц и
связи между ними.
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 - Альтернативный поток событий - отмена заказа
Выводы
. По построенным диаграммам виден поток событий во времени.
. Данная диаграмма отражает поток событий в рамках выбранного базового
варианта использования.
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 - Диаграмма сотрудничества информационной системы дилерского
пункта продажи автомобилей «КавказЮгАвто»
Вывод
. Построив диаграмму сотрудничества, очевидно, что по ней легче понять
связи между объектами, однако труднее понять временную последовательность
событий.
СОЗДАНИЕ ДИАГРАММЫ КЛАССОВ
Создадим диаграмму классов, вызвав контекстное меню на 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 - получить цену заказанного
автомобиля.
. AcceptOrder() - подтверждение
заказа.
. CancelOrder() - отменить
заказ.
. GetCharacteristics() - получить варианты комплектации
автомобиля.
. AcceptCharacteristics() - подтверждение вариантов комплектации
автомобиля.
. EnterModel() : string - ввод марки автомобиля.
. GetNumber() : int - получить номер заказа.
. CheckOrder() - запрос на проверку заказа.
. OutputVariantsOrder() - вывод возможной комплектации
пользователю.
. SetVariantsOrder() - установить выбранный вариант комплектации
пользователем.
Для класса «TransactionManager»
операции будут следующими:
1. SetNumber():int - установка номера заказа.
. CheckAll() -
проверить заполнение полей ввода.
. QuerryToDB_car() - запрос автомобиля в БД.
. GetCharacteristicsFromDB() - получить характеристики из БД.
. SetCharacteristicsToOrder() - отправить характеристики в окно
заказа.
. GetSummFromDB() : Double - установленная сумма в БД.
. SetSummToOrder() : Double - выбранная сумма в БД.
. GetClientCharacteristicsFromOrder() - получить комплектацию
автомобиля, выбранную клиентом.
. SetClientsCharacteristicsToDB() - установить комплектацию
автомобиля, выбранную клиентом для отправки в БД.
. QuerryCheck() -
запрос на проверку заказа из формы заказа.
В «DataBase» создадим текущие операции:
1. CheckModel():bool - проверка наличия модели автомобиля.
. QuerryCar() - проверка наличия автомобиля.
. SetCharacteristics() - установить комплектацию автомобиля.
. GetCharacteristics() - получить установленную клиентом
комплектацию автомобиля.
. SetOrder() - принять заказ.
. SetSumm():double - установить сумму автомобиля.
Так же следует ввести операции для работы с базой данных:
. AddItem() -
добавить запись в БД.
. DeleteItem() -
удалить запись в БД.
. Update() - обновить
БД.
. AddOrder() -
добавить заказ.
. DeleteOrder() - удалить
заказ.
Созданные операции и готовая диаграмма изображена на рисунке 5.5.
Рисунок 5.5 - Диаграмма классов информационной системы дилерского пункта
продажи автомобилей «КавказЮгАвто»
Выводы
. Построенная диаграмма классов наглядно показывает структуры классов, их
операции и атрибуты.
. Диаграмма позволяет судить о взаимосвязи классов.
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):
. Do - загрузка команд.
3. Exit - переход к обработке данных.
Рисунок 6.5 - Состояние загрузка класса «TransactionManager»
и действия этого состояния на диаграмме состояний
Состояние «Обработка данных» (рисунок 6.6):
1. Entry - обработка поступивших данных.
. 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 - Диаграмма компонентов информационной системы дилерского
пункта продажи автомобилей «КавказЮгАвто»
Выводы
. Данная диаграмма позволяет видеть поведения классов «DataBase», «TransactionManager» и «Order».
. Диаграмма дает возможность просмотра действия каждого состояния класса.
. Диаграмма компонентов позволяет представить модель на физическом
уровне.
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
Files\Rational\Rose\C++.
Выводы
. Код созданных ранее классов можно сгенерировать на желаемом языке.
. Сгенерировав код в дальнейшем можно приступить к его редактированию.
ЗАКЛЮЧЕНИЕ
В курсовом проекте была разработана объектно-ориентированная подсистема
предприятия на графическом языке моделирования 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 с, ил. (Серия «для программистов»).
. Боггс,
У. UML и Rational Rose: Пер. с англ [Текст] / У. Боггс, М. Боггс. - М.:
Издательство «Лори», 2000. - 581 с.
. Архангельский,
А. Я. Программирование в Delphi 7 [Текст] / А. Я. Архангельский. - М.: ООО
«Бином-Пресс», 2003. - 1152 с.
. Хоффман,
Л. Современные методы защиты информации [Текст] / : пер. с англ. Л. Хоффман. -
М: Сов. радио, 1980.
. Буч,
Г. Язык UML для пользователя: Пер. с англ [Текст] / Г. Буч, Д. Рамбо, А.
Джекобсон. - М: ДМК, 2000. - 432 с, ил. (Серия «для программистов»).
. Боггс,
У. UML и Rational Rose: Пер. с англ [Текст] / У. Боггс, М. Боггс. - М.:
Издательство «Лори», 2000. - 581 с.
. Буч,
Г., Рамбо Д., Джекобсон A. UML [Текст] / : специальный справ-очник. - СПб.:
Питер, 2002. - 432 с, ил.
. Ларман,
К. применение UML и шаблонов проектирования [Текст] /: Пер. с англ. К. Ларман -
М.: Издательский дом «Вильяме», 2001. - 496 с, ил.
.
Петров, В. 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: <Top Level>
//## Source file: C:\Program
Files\Rational\Rose\C++\source\DataBase.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()
//## 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(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
}::~DataBase()
{
//## begin
DataBase::~DataBase%4DE35177030D_dest.body preserve=yes
//## end
DataBase::~DataBase%4DE35177030D_dest.body
}& DataBase::operator=(const
DataBase &right)
{
//## begin DataBase::operator=%4DE35177030D_assign.body
preserve=yes
//## end
DataBase::operator=%4DE35177030D_assign.body
}DataBase::operator==(const DataBase
&right) const
{
//## begin
DataBase::operator==%4DE35177030D_eq.body preserve=yes
//## end DataBase::operator==%4DE35177030D_eq.body
}DataBase::operator!=(const DataBase
&right) const
{
//## begin
DataBase::operator!=%4DE35177030D_neq.body preserve=yes
//## end
DataBase::operator!=%4DE35177030D_neq.body
}
//## Other Operations
(implementation)DataBase::QuerryCar ()
{
//## begin
DataBase::QuerryCar%4E01BA43031C.body preserve=yes
//## end
DataBase::QuerryCar%4E01BA43031C.body
}DataBase::CheckModel ()
{
//## begin
DataBase::CheckModel%4DE35C5F032C.body preserve=yes
//## end
DataBase::CheckModel%4DE35C5F032C.body
}DataBase::SetCharacteristicsToMenTr
()
{
//## begin
DataBase::SetCharacteristicsToMenTr%4DE9F9D701D4.body preserve=yes
//## end
DataBase::SetCharacteristicsToMenTr%4DE9F9D701D4.body
}DataBase::GetClientCharacteristics
()
{
//## begin DataBase::GetClientCharacteristics%4DE9F9CE0271.body
preserve=yes
//## end
DataBase::GetClientCharacteristics%4DE9F9CE0271.body
}DataBase::SetOrder ()
{
//## begin
DataBase::SetOrder%4DE35D1D0167.body preserve=yes
//## end
DataBase::SetOrder%4DE35D1D0167.body
}DataBase::SetSumm ()
{
//## begin
DataBase::SetSumm%4DE35C940109.body preserve=yes
//## end
DataBase::SetSumm%4DE35C940109.body
}DataBase::AddItem ()
{
//## begin
DataBase::AddItem%4DE9F4E1002E.body preserve=yes
//## end
DataBase::AddItem%4DE9F4E1002E.body
}DataBase::DeleteItem ()
{
//## begin
DataBase::DeleteItem%4DE9F4F2002E.body preserve=yes
//## end
DataBase::DeleteItem%4DE9F4F2002E.body
}DataBase::Update ()
{
//## begin
DataBase::Update%4DE9F51C01F4.body preserve=yes
//## end
DataBase::Update%4DE9F51C01F4.body
}DataBase::AddOrder ()
{
//## begin
DataBase::AddOrder%4DEA43F20128.body preserve=yes
//## end
DataBase::AddOrder%4DEA43F20128.body
}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