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

   

Рисунок 9 — Оптимизированная схема работы Авиакассы

 

Изменится и процесс консультации клиентов по телефону (Рисунок10). Теперь на звонки клиентов будет отвечать оператор, а кассир будет заниматься своей основной работой–продажей и оформлением билетов.

 

Рисунок 10 — Оптимизированный процесс консультации по телефону

 

В соответствии с оптимизацией структуры меняются бизнес процессы «Обслуживание клиента в кассе» (Рисунок 11).

Рисунок 11 — Оптимизированный бизнес-процесс

«Обслуживание клиентов Авиакассы»

В соответствии со всеми изменениями у нас появляется новый бизнес процесс «Обслуживание клиентов у оператора» (Рисунок 12).

Рисунок 12 — Новый бизнес-процесс «Обслуживание клиентов у

 оператора»

 

 

 

 

 

Глава 3. Проектирование информационной системы на языке UML

 

Целью данной работы является освоение технологии проектирования информационных систем с позиции объектно-ориентированного проектирования на основе языка UML.

 Последовательность работ следующая, строятся диаграммы логического проектирования, не имеющие прямого отношения к языку программирования. Это диаграммы концептуального моделирования.

1. Диаграмма прецедентов

Use case diagram (диаграммы прецедентов) - этот вид диаграмм позволяет создать список операций, которые выполняет система. Каждая такая диаграмма – это описание сценария поведения, которому следуют действующие лица (Actors).

 

 Данный тип диаграмм используется при описании бизнес процессов предметной области, определении требований к будущей программной системе. Отражает объекты как системы, так и предметной области и задачи, ими выполняемые. Окончательный вид диаграммы показан на рисунке 13. На диаграмме находятся Use Case (Вариант использования), Actor (Действующее лицо). Так же были добавлены ассоциации и описания ко всем элементам диаграммы.

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

Рисунок 13 — Диаграмма прецедентов

 

2. Диаграммы последовательности

Sequence diagram (диаграммы последовательностей действий). Данный тип диаграмм позволяет отразить последовательность передачи сообщений между объектами. Этот тип диаграммы не акцентирует внимание на конкретном взаимодействии, главный акцент уделяется последовательности приема/передачи сообщений. Окончательный вид диаграммы показан на рисунке 14. Диаграмма содержит действующие лица и объекты, так же добавлены такие объекты, как Object Message (Новое сообщение между объектами) и Message to Self  (Рефлексивное сообщение самому себе).

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

 

Рисунок 14 — Диаграмма последовательности

 

На рисунке 15 отображена последовательность действий оператора при проведении консультации и брони билета по запросу клиента.

Рисунок 15 — Диаграмма последовательности оператора Call-центра

3. Кооперативная диаграмма

Collaboration diagram (диаграммы сотрудничества). Этот тип диаграмм позволяет описать взаимодействия объектов, абстрагируясь от последовательности передачи сообщений. На этом типе диаграмм в компактном виде отражаются все принимаемые и передаваемые сообщения конкретного объекта и типы этих сообщений.  По причине того, что диаграммы Sequence и Collaboration являются разными взглядами на одни и те же процессы, Rational Rose позволяет создавать из Sequence диаграммы диаграмму Collaboration и наоборот, а также производит автоматическую синхронизацию этих диаграмм. Окончательный вид диаграммы показан на рисунке 16. Диаграмма содержит Link To Self (Связь объекта самого с собой), Object Link (Связь между объектами), объекты и Link Message (сообщение, передаваеме между двумя объектами или объектом самому себе).

Рисунок 16 — Кооперативная диаграмма

 

На рисунке 16 и рисунке 18 изображены диаграммы аналогичные диаграммам последовательности действий.

Рисунок 18 — Кооперативная диаграмма с введением Call-центра

 

4. Диаграмма Состояний для класса Кассир

Каждый объект системы, обладающий определенным поведением, может находится в определенных состояниях, переходить из состояния в состояние, совершая определенные действия в процессе реализации сценария поведения объекта. Поведение большинства объектов реальных систем можно представить с точки зрения теории конечных автоматов, то есть поведение объекта отражается в его состояниях, и данный тип диаграмм позволяет отразить это графически. Для этого используется два вида диаграмм: Statechart diagram (диаграмма состояний) и Activity diagram (диаграмма активности) [7].

Диаграмма состояний предназначена для отображения состояний объектов системы, имеющих сложную модель поведения. Конечный вид диаграммы представлен на рисунке 19. Диаграмма содержит в себе state (суперсостояние), состояния, state transition (переходы), начальное (Start state) и конечное состояние (End State).

Рисунок 19 — Диаграмма состояний

 

5. Диаграмма активности для варианта использования «Продажа билетов»

Activity diagram (диаграммы активности). Это дальнейшее развитие диаграммы состояний. Фактически данный тип диаграмм может использоваться и для отражения состояний моделируемого объекта, однако, основное назначение Activity diagram в том, чтобы отражать бизнес-процессы объекта. Этот тип диаграмм позволяет показать не только последовательность процессов, но и ветвление и даже синхронизацию процессов [7]. Окончательный вид диаграммы показан на рисунке 20. На диаграмме присутствуют дорожки (Swimlane), объекты состояния(Activity), начальное (Start state) и конечное состояние (End State).

Рисунок 20 — Диаграмма активности

 

6. Пакеты и классы

Class diagram (диаграммы классов). Этот тип диаграмм позволяет создавать логическое представление системы, на основе которого создается исходный код описанных классов [7].

Значки диаграммы позволяют отображать сложную иерархию систем, взаимосвязи классов (Classes) и интерфейсов (Interfaces). Данный тип диаграмм противоположен по содержанию диаграмме Collaboration, на котором отображаются объекты системы. В данной работе были созданы пакеты, и объедиены в них классы (Рисунок 21).

Рисунок 21 — Расположение пакетов и классов в браузере

7. Диаграмма классов

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

В лабораторной работе 8 происходит описание связей между классами и добавляются ассоциации, далее выбирается множественность связей. В лабораторной работе 9 происходит изменение стереотипов классов. Стереотип позволяет указывать дополнительные особенности для разрабатываемо модели. Понятие стереотипа для этих элементов из уже заданных и представляет собой дополнительную классификацию элементов. В данной работе используется 4 вида стереотипов: Исполнитель (Actor), граница(boundary), сущность(entity) и управление (control). Окончательный вид диаграммы представлен на рисунке 22.

Рисунок 22 — Диаграмма классов

8. Диаграмма компонентов

Component diagram (диаграммы компонентов). Этот тип диаграмм предназначен для распределения классов и объектов по компонентам при физическом проектировании системы. Часто данный тип диаграмм называют диаграммами модулей [7]. Диаграмма компонентов представлена на рисунке 23.

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

Рисунок 23 — Диаграмма компонентов системы

 

 

 

 

 

 

 

 

 

 

 

ЗАКЛЮЧЕНИЕ

 

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

Была выполнена основная цель – разработка и внедрение информационной системы Авиакассы и была произведена её оптимизация путем добавления дополнительного отдела Call-центр, позволяющей повысить эффективность работы организации.

Далее была построена модель Авиакассы на языке UML.

В результате разработки системы, построения модели организации и оптимизации информационной системы Авиакассы, были решены основные структурные проблемы предприятия.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

СПИСОК ЛИТЕРАТУРЫ

 

 

1. Боггс У. Боггс М. UML и Rational Rose [Текст]: учеб. Пособие/У.Боггс, М. Боггс:Лори, 2004, - 510с.
2. Кватрани, Т. Rational Rose 2000 и UML [Текст]: учеб. Пособие/ Т. Кватрани: ДМК Пресс, 2001, - 176с.
3. Ларман, К. Применение UML и шаблонов проектирования [Текст]: учеб. Пособие/ К. Ларман: Вильямс, 2002. – 624с.
4. Рамбо Дж., Блаха М.. UML 2.0. Объектно-ориентированное моделирование и разработка. [Текст]: учеб. Пособие/ Дж. Рамбо, М. Блаха: Питер, 2004. – 544с.
5. Трофимов, С. А. - CASE-технологии. Практическая работа в Rational Rose [Текст]/ С. А. Трофимов: Бином-Пресс, 2002. – 288с.
6. Статья С. А. Трофимов UML диаграммы в Rational Rose [Электронный ресурс]. - http://www.caseclub.ru/articles/rose2.html

 

 

 

Благовещенск 2014