Помощь в написании студенческих работ
Антистрессовый сервис

Разработка объектно-ориентированной модели информационной подсистемы для дилерского пункта продажи автомобилей

КурсоваяПомощь в написанииУзнать стоимостьмоей работы

Рисунок 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

Показать весь текст
Заполнить форму текущей работой