Диаграммы rose о автосервисе

3.3 Создание диаграммы сотрудничества

 

Диаграммы сотрудничества (Collaboration diagram) – второй тип диаграмм взаимодействия. Collaboration diagram называет диаграммой объектов [1, 2]. Действительно, эта диаграмма отличается от предыдущей тем, что она не акцентирует внимание на последовательности передачи сообщений, она отражает наличие взаимосвязей вообще, то есть на этой диаграмме отражается наличие сообщений от клиентов к серверам. Так как временная шкала не участвует в демонстрации сообщений, то эта диаграмма получается компактней и как нельзя лучше подходит для того, чтобы окинуть одним взглядом взаимодействие всех объектов.

Однако необходимо понимать, что  диаграмма показывает взаимодействие между объектами, а не классами, то есть является мгновенным снимком объектов системы в некотором состоянии. Ведь объекты, в отличие от созданных на этапе проектирования классов, создаются и уничтожаются на всем протяжении работы программы. И в каждый момент имеется конкретная группа объектов, с которыми осуществляется работа. В связи с этим появляются такие понятия, как время жизни и область видимости объектов, которые будут рассмотрены далее.

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

Так как диаграммы сотрудничества схожи с диаграммами последовательностей, то согласно созданной выше диаграмме последовательности для варианта использования "Заказ", была создана диаграмма сотрудничества для варианта использования "Заказ" (рисунок 4.1).

 

Рисунок 4.1 – Диаграмма сотрудничества для варианта использования "Заказ"

 

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

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

3.4 Создание диаграммы классов

 

Диаграммы классов (Class diagram) позволяет создавать логическое представление системы, на основе которого создается исходный код описанных классов [1, 2]. Значки диаграммы позволяют отображать сложную иерархию систем, взаимосвязи классов (Classes) и интерфейсов (Interfaces). Данный тип диаграмм противоположен по содержанию диаграмме Collaboration, на котором отображаются объекты системы. Rational Rose позволяет создавать классы при помощи данного типа диаграмм в различных нотациях:

• в нотации, предложенной Г. Бучем;
• в нотации ОМТ;
• в нотации Unified (унифицированной нотации).

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

Обычно для описания системы  создают несколько диаграмм классов.

На одних показывают некоторое  подмножество классов и отношения между классами подмножества.

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

Третьи соответствуют только пакетам  классов и отношениям между ними. По умолчанию существует одна диаграмма классов, называемая Главной (Main) и располагающаяся непосредственно под "Логическим представлением" в браузере. На этой диаграмме показывают пакеты классов модели. Внутри каждого пакета также имеется "Главная диаграмма", включающая в себя все классы этого пакета (рисунок 5.1).

 

Рисунок 5.1 – Главная  диаграмма классов

 

После создания главой диаграммы классов  создается диаграмма классов  для варианта использования "Заказ" (рисунок 5.2).

 

Рисунок 5.2 – Диаграмма классов  для варианта использования "Заказ"

 

К классам на диаграмме добавлены  стереотипы. Стереотип "entity" указан для класса "Form_Zakaz", стереотип "boundary" для классов "Form_klient" и "Form_Ysluga" , стереотип "control" – для классов "Print_date" и "Work_BD".

Соответствующие классы объединены в пакеты:

1. "Date" – классы " Form_Zakaz " " Form_klient ", " Form_Ysluga ";
2. "BD" – класс " Work_BD ";
3. "Print" – класс " Print_date "

Для каждого пакета создана диаграмма  классов. Диаграмма классов для  пакета "Date" представлена на рисунке 5.3.

 

Рисунок 5.3 – Диаграмма классов  пакета "Date"

 

Диаграмма классов для пакета "BD" представлена на рисунке 5.4.

 

Рисунок 5.4 – Диаграмма классов  пакета "BD"

 

Диаграмма классов для пакета "Print_date" показана на рисунке 5.5.

 

Рисунок 5.5 – Диаграмма классов пакета "Print_date"

 

Выводы

1. Созданы три пакета "Date", "Print_date" и "BD".
2. Классы, реализующие варианта использования "Заказ", были помещены в указанные пакеты.
3. Создана главная диаграмма классов и три диаграммы классов для соответствующих пакетов.
4. Соответствующие классы объединены в пакеты:

• "Date" – классы"Form_Zakaz "," Form_klient","Form_Ysluga";

• " BD " – классы " Work_BD ";
• "Print" – класс "Print_date".

 

3.5 Добавление деталей к описаниям операции и определение атрибутов классов. Добавление связей между классами

 

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

В данном разделе показывается, как  к описаниям операций добавить детали, включая параметры, типы возвращаемых значений, определить атрибуты классов, а также добавить связи между классами на диаграмме классов. Для каждого класса на диаграмме классов для варианта использования "Заказ" добавлены описания операций, то есть, указаны типы значений и атрибуты функций.

 

Рисунок 6.1 – Диаграмма классов со связями и атрибутами

 

Выводы

1. Произведено добавление атрибутов и типов значений.
2. Созданы связи между классами.
3. Для каждого класса на диаграмме классов для сценария "Заказ клиента" добавлены описания операций, то есть, указаны типы значений и атрибуты функций.

3.6 Создание диаграммы состояний для классов и диаграммы компонентов

 

Диаграммы состояний  определяют все возможные состояния, в которых может находиться конкретный объект, а также процесс смены состояний объекта в результате наступления некоторых событий. Существует много форм диаграмм состояний, незначительно отличающихся друг от друга семантикой.

На диаграмме имеются два  специальных состояния – начальное (start) и конечное (stop). Процессы, происходящие в тот момент, когда объект находится в определенном состоянии, называются действиями (actions) [1, 2].

С состоянием можно связывать следующие  данные: деятельность, входное действие, выходное действие и событие.

Входное действие (entry action) – это поведение, которое выполняется, когда объект переходит в данное состояние. Входное действие также показывают внутри состояния, его обозначению предшествуют слово entry (вход) и двоеточие.

Выходное действие (exit action) подобно входному действию. Однако оно осуществляется как составная часть процесса выхода из данного состояния. Как и входное, выходное действие является непрерываемым. Выходное действие изображают внутри состояния, его описанию предшествуют слово exit (выход) и двоеточие.

Переходом (transition) называется перемещение объекта из одного состояния в другое. На диаграмме все переходы изображают в виде стрелки, начинающейся на первоначальном состоянии и заканчивающейся последующим.

У перехода существует несколько спецификаций. Они включают события, аргументы, ограждающие условия, действия и посылаемые события.

Событие (event) – это то, что вызывает переход из одного состояния в другое. Событие размещают на диаграмме вдоль линии перехода.

На диаграмме для отображения  события можно использовать как  имя операции, так и обычную фразу. У событий могут быть аргументы. Большинство переходов должны иметь события, так как именно они, прежде всего, заставляют переход осуществиться. Тем не менее, бывают и автоматические переходы, не имеющие событий.

Действие (action), как уже говорилось, является непрерываемым поведением, осуществляющимся как часть перехода. Входные и выходные действия показывают внутри состояний, поскольку они определяют, что происходит, когда объект входит или выходит из состояния. Диаграммы состояний не надо создавать для каждого класса, они применяются только в сложных случаях.

В данном курсовом проекте диаграмма  состояний создается для класса "Work_BD". Она представлена на рисунке 7.1.

 

Рисунок 7.1 – Диаграмма состояний для класса "Work_BD"

 

На данной диаграмме расположены  начальное и конечное состояние, состояния "Cancel" (Отменен), "Filled" (Выполнен), "Insert_zakaz" (Ввод данных), "Initialization" (Инициализация), "Save" (Сохранен).

Для каждого из состояний созданы  следующие действия:

1. "Initialization" – действие "Create new ID" (создание идентификатора).
2. "Cancel" – действие "Cancel_vvod" (откат транзакции записи).
3. "Filled" – действие "Record_date" (занесение данных в БД).
4. "Save" – действие "Save_data" (сохранение данных в БД).

Рассмотрим создание диаграммы  компонентов. Диаграммы компонентов показывают, как выглядит модель на физическом уровне. На них изображены компоненты программного обеспечения и связи между ними. При этом на такой диаграмме выделяют два типа компонентов: исполняемые компоненты и библиотеки кода [1, 2].

Каждый класс модели (или подсистема) преобразуется в компонент исходного кода. После создания они сразу добавляются к диаграмме компонентов.

У системы может быть несколько  диаграмм компонентов в зависимости от числа подсистем или исполняемых файлов. Каждая подсистема является пакетом компонентов. В общем случае пакеты – это совокупности компонентов.

Диаграммы компонентов применяются  теми участниками проекта, кто отвечает за компиляцию системы. Из нее видно, в каком порядке надо компилировать компоненты, а также какие исполняемые компоненты будут созданы системой. На такой диаграмме показано соответствие классов реализованным компонентам. Она нужна там, где начинается генерация кода.

Диаграмма компонентов, созданная в курсовом проекте, представлена на рисунке 7.2.

 

Рисунок 7.2 – Диаграмма компонентов

 

Для каждого класса создана  спецификация пакета и тело пакета. Они соединяются с помощью  связей Dependency.

 

3.7 Создание диаграммы размещения

 

Этот вид диаграмм предназначен для анализа аппаратной части системы, то есть "железа", а не программ. В прямом переводе с английского Deployment означает "развертывание", но термин "топология" точнее отражает сущность этого типа диаграмм [1, 2]. Иногда диаграммы топологии называют диаграммами размещения.

Для каждой модели создается только одна такая диаграмма, отображающая процессоры (Processor), устройства (Device) и их соединения. Построенная диаграмма размещения показана на рисунке 8.1.

 

Рисунок 8.1 – Диаграмма  размещения

 

Как видно на рисунке 8.1, информационная подсистема "Автосервис" содержит два сервера (сервер приложений и сервер БД) , две клиентские рабочие станции и сетевой принтер.

 

 

 

 

 

 

 

 

 

 

 

Заключение

 

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

В ходе проектирования было выполнено  построение всех диаграмм, предусмотренных  заданием на проектирование, а именно:

• диаграммы вариантов использования;
• диаграммы классов;
• диаграммы поведения;
• диаграммы взаимодействия;
• диаграммы последовательности и кооперативной диаграммы;
• диаграммы состояний;
• диаграммы деятельностей;
• диаграммы реализации;
• диаграммы компонентов;
• диаграммы размещения.

Все диаграммы в данном курсовом проекте разработаны с помощью системы моделирования Rational Rose 2006 Enterprise v.7

 

Список использованной литературы