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

Разработка объектно-ориентированной подсистемы складского учета для фирмы "КавказЮгАвто". Краткая характеристика предметной области. Построение диаграмм размещения, прецедентов, последовательности, компонентов и классов. Генерация программного кода C++.

Рубрика Программирование, компьютеры и кибернетика
Вид курсовая работа
Язык русский
Дата добавления 26.06.2011
Размер файла 6,6 M

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

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

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

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ

ГОУ ВПО СЕВЕРО-КАВКАЗСКИЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ

Факультет информационных технологий и телекоммуникаций

Кафедра прикладной информатики

ПОЯСНИТЕЛЬНАЯ ЗАПИСКА

К КУРСОВОМУ ПРОЕКТУ НА ТЕМУ:

Разработка объектно-ориентированной модели информационной

подсистемы для дилерского пункта продажи автомобилей

Автор курсового проекта

Сергиенко Е.А.

Специальность: 080801 «Прикладная информатика в экономике»

Руководитель проекта

к.т.н. ,доцент В. Ф. Ляхов

Ставрополь, 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 Files\Rational\Rose\C++.

Выводы

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: <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::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

Размещено на Allbest.ru


Подобные документы

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.