Interaction overview diagram (Диаграмма обзора взаимодействия)

Interaction overview diagram – диаграмма, которая предназначена для представления взаимодействия только в контексте потока управления в некоторой агрегированной форме. Диаграммы обзора взаимодействия, вместо узлов действий и объектов диаграмм деятельности, имеют фреймы, каждый из которых может соответствовать взаимодействию или использованию взаимодействия. Альтернативные комбинированные фрагменты представляются узлом решения и соответствующим узлом слияния. Параллельные комбинированные фрагменты представляются узлом разделения и соответствующим узлом соединения. Комбинированные фрагменты типа Цикл представляются простыми циклами. Ветвление и слияния ветвлений на диаграммах обзора взаимодействия должны быть должным образом вложенными. Диаграммы обзора взаимодействия заключаются во фрейм, аналогично другим видам диаграмм взаимодействия с тегом sd и ref.

Для создания диаграммы взаимодействия были использованы теги (ref и sd), созданные в Sequence diagram. Если при проверке наличия деталей выясняется, что у нас есть детали, то переходим к конечному этапу – «произвести ремонт». А если деталей нет, тогда переходим к этапу заказа и получения деталей.

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

Диаграмма классов, Class diagram — статическая структурная диаграмма, описывающая структуру системы, она демонстрирует классы системы, их атрибуты, методы и зависимости между классами.

Существуют разные точки зрения на построение диаграмм классов в зависимости от целей их применения:

• концептуальная точка зрения - диаграмма классов описывает модель предметной области, в ней присутствуют только классы прикладных объектов;

• точка зрения спецификации - диаграмма классов применяется при проектировании информационных систем;

• точка зрения реализации - диаграмма классов содержит классы, используемые непосредственно в программном коде (при использовании объектно-ориентированных языков программирования).

Каждый класс имеет свое название и свои атрибуты и операции, которые впоследствии будут реализованы в программном коде. Если операция имеет какой-либо тип, например, +Записать информацию в БД(Num: int:Zakaz: stirng; Zakazchik: string; Status: boolean): boolean, то в таком случае в программном коде данная операция будет представлена в виде функции указанного типа с параметрами, которые находятся в круглых скобках. Класс «Номер заказа» имеет стереотип «entity» (сущность).

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

Для более наглядного и понятного взаимодействия классов между собой, нужно объединить классы в пакеты. Таким образом, мы сгруппируем все наши классы в модули. И при кодогенерации каждый пакет выведется в отдельный модуль, согласно той группировке, которую мы произвели. Диаграммы пакетов служат, в первую очередь, для организации элементов в группы по какому-либо признаку с целью упрощения структуры и организации работы с моделью нашей системы.

На данном этапе мы разделил классы на три пакета: «Сущность», «Управление», «Реализация». Каждый пакет непосредственно взаимодействует с другим, так пакет «Сущность» порождает связь с пакетом «Управление», а пакет «Управление в свою очередь» порождает связь с пакетом «Реализация». Классы, находящиеся в пакетах, могут так же между собой взаимодействовать, это наглядно показано на рисунке. Деление на пакеты было произведено по функциональному принципу. В пакет «Сущность» мы поместили 2 класса: «Заявка», «Номер заявки» - так как именно эти классы порождают наш бизнес-процесс и отражают его сущность. В пакет «Управление» мы поместили 3 класса: «Управляющий заказами», «Финансовый директор», «Бухгалтерия», так как эти классы осуществляют управление бизнес-процессом. И, наконец, пакет «Реализация», в него вошли 3 класса: «БД», «Механик», «Поставщик», так как именно в этих классах происходит реализация бизнес-процесса.