Построение UML-диаграмм

 Наследование (inheritance) – это отношение типа «общее-частное». Позволяет определить такое отношение между классами, когда один класс обладает поведением и структурой ряда других классов. При создании производного класса на основе базового (одного или нескольких) возникает иерархия наследования. Реализация принципов наследования является ключевой предпосылкой возможности повторного использования кода, поскольку это основной инструмент достижения полиморфизма.

 

Порядок построения диаграммы классов.

1. Создаём новую  диаграмму с именем «Сущности».

2. Анализируем предметную область

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

системе товар  является товаром, пока он не покинет склад), ещё характеризуется количеством. Аналогично следует рассуждать и при рассмотрении отношения Товара и Заказа, Товара и Накладной. В связи с тем, что Заказ и Накладная в сущности являются документами и имеют сходные атрибуты, они были объединены с помощью общего класса- предка Документ.

3. Строим диаграмму классов. Диаграмма имеет следующий вид:

 

 

 

 

 

 

 

 

 

 

ВЫВОД: Диаграмма классов  (Static Structure diagram) — статическая структурная диаграмма, описывающая структуру системы, демонстрирующая классы системы, их атрибуты, методы и зависимости между классами.

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

• Для моделирования данных. Анализ предметной области позволяет выявить основные характерные для нее сущности и связи между ними. Это удобно моделируется с помощью диаграмм классов. Эти диаграммы являются основой для построения концептуальной схемы базы данных.
• Для представления архитектуры программной системы. Можно выделить архитектурно значимые классы и показать их на диаграммах, описывающих архитектуру программной системы.
• Для моделирования навигации экранов. На таких диаграммах показываются пограничные классы и их логическая взаимосвязь. Информационные поля моделируются как атрибуты классов, а управляющие кнопки – как операции и отношения.
• Для моделирования логики программных компонент (будет описано в последующих статьях).
• Для моделирования логики обработки данных.

 

 

 

 

 

 

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

Диаграмма обзора взаимодействия (Interaction overview diagram) — разновидность диаграммы деятельности, включающая фрагменты диаграммы последовательности и конструкции потока управления.

Этот тип диаграмм включает в себя диаграммы Sequence diagram (диаграммы последовательностей действий) и Collaboration diagram (диаграммы сотрудничества). Эти диаграммы позволяют с разных точек зрения рассмотреть взаимодействие объектов в создаваемой системе

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

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

Реализацию прецедента «Оформление заказа», Построим для данной реализации диаграмму последовательностей

 

Порядок построения диаграммы последовательностей (Sequence Diagram)

1. Создаем диаграмму последовательностей с именем «Создание нового заказа», которая будет описывать сценарий размещения нового заказа.

2. На диаграмме отразим взаимодействие объектов классов: «Менеджер», «Списковая форма товаров на складе», «Списковая форма заказов», «Форма редактирования заказов», «Заказ», «Позиция Заказов».

3. Диаграмма имеет следующий вид:

 

ВЫВОД: Диаграмма взаимодействий (Interaction diagram) описывает взаимодействия, состоящие из множества объектов и отношений между ними, включая сообщения, которыми они обмениваются. 

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

 

Диаграммы сотрудничества (Collaboration diagram)

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

Создадим реализацию прецедента «Оформление накладных» - построим - диаграмму кооперации для сценария «Печать накладной».

Построение диаграммы сотрудничества (Collaboration Diagram).

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

2. Размещаем следующие элементы:

 

 

 

 

 

 

 

 

 

Диаграммы  состояний (Statechart Diagram)

Диаграмма состояний  определяет последовательность состояний объекта, вызванных последовательностью событий.

Порядок построения диаграмм

1. Создаем диаграмму состояний для объектов класса «Заказ».

2. Из спецификации  прецедентов следует, что заказ может быть в трех состояниях:

• «Новый»;

• «Оплаченный»;

• «Отмененный».

В состояние  «Новый» заказ попадает сразу  после своего создания и находится  в нем до момента перевода его  менеджером в состояние «Оплаченный». Событием к переходу является поступление денег в кассу. Условие перехода – оплата должна производиться не позднее 10 дней со дня оформления заказа. В случае если оплата не производится в течение отведенных 10 дней или производится позже, заказ переходит в состояние «Отмененный».

3. Диаграмма состояний для объектов класса «Заказ» имеет вид:

 

 

1. Создаем диаграмму состояний для объектов класса «Накладная».

2. Рассмотрим построение диаграммы состояний для товарно-транспортной

накладной. Все  вновь созданные накладные попадают в состояние «Новая». После печати накладной она переходит в состояние «Выписанная». В этот момент электронная накладная становится доступной кладовщику на складе, и он начинает сборку заказа. По окончании сборки кладовщик переводит накладную в состояние «Готовая». Если по каким-то причинам на складе не оказалось нужного товара (брак в партии, просрочка поставщика и т.п.), что делает невозможным сборку заказа, накладная переходит в состояние «Приостановленная». После того как товар отгружен клиенту, накладная переходит в состояние «Отгруженная».

3. Диаграмма состояний для объектов класса «Накладная» имеет вид:

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Диаграмма развёртывания (Deployment diagram)

 

Диагра́мма  развёртывания( Deployment diagram) является физической диаграммой в языке UML. Она отображает физические взаимосвязи между программными и аппаратным компонентами проектируемой системы (физическое  развертывание  артефактов  на узлах).

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

Существует  два типа узлов:

1. Узел устройства
2. Узел среды выполнения

Узлы устройств — это физические вычислительные ресурсы со своей памятью и сервисами для выполнения программного обеспечения, такие как обычные ПК, мобильные телефоны. Узел среды выполнения — это программный вычислительный ресурс, который работает внутри внешнего узла и который предоставляет собой сервис, выполняющий другие исполняемые программные элементы.

 

Порядок создания диаграммы (Deployment diagram).

1. Создаем диаграмму развёртывания.

2. Расположим элементы как показано на рисунке:

 

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

Диаграмма развертывания предназначена для визуализации элементов и компонентов программы, существующих лишь на этапе ее исполнения (runtime) и представления общей конфигурации и топологии распределенной программной системы в UML .

 

 

 

Диаграммы видов деятельности (Activity Diagram)

 

 

Диаграмма видов  деятельности, как и диаграмма  состояний, отражает

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

 

Порядок построения диаграммы видов деятельности

1. Создаем диаграмму видов деятельности

2. В этом бизнес-процессе  участвуют четыре объекта: клиент, менеджер,

бухгалтер и  кладовщик. Создайте дорожки (swimlanes) для каждого из объектов. Каждая из дорожек ответственна за выполнение определенных действий тем объектом, с которым она проассоциирована.

3. Далее необходимо  расположить на диаграмме все  деятельности/действия,

которые выполняются  тем или иным объектом.

4. Результат:  диаграмма представленная на  рисунке: