Модель UML (UML model) ‒ это совокупность конечного множества конструкций языка, главные из которых ‒ это сущности и отношения между ними.
Сами сущности и отношения модели являются экземплярами метаклассов метамодели.
Рассматривая модель UML с наиболее общих позиций, можно сказать, что это граф (точнее, нагруженный мульти-псевдо-гипер-орграф), в котором вершины и ребра нагружены дополнительной информацией и могут иметь сложную внутреннюю структуру. Вершины этого графа называются сущностями, а ребра ‒ отношениями . Остальная часть раздела содержит беглый (предварительный), но полный обзор имеющихся типов сущностей и отношений. К счастью, их не слишком много. В последующих главах книги все сущности и отношения рассматриваются еще раз, более детально и с примерами.
Для удобства обзора сущности в UML можно подразделить на четыре группы:
Структурные сущности, как нетрудно догадаться, предназначены для описания структуры. Обычно к структурным сущностям относят следующие.
Объект (object) 1 ‒ сущность, обладающая уникальностью и инкапсулирующая в себе состояние и поведение.
Класс (class) 2 ‒ описание множества объектов с общими атрибутами, определяющими состояние, и операциями, определяющими поведение.
Интерфейс (interface) 3 ‒ именованное множество операций, определяющее набор услуг, которые могут быть запрошены потребителем и предоставлены поставщиком услуг.
Кооперация (collaboration) 4 ‒ совокупность объектов, которые взаимодействуют для достижения некоторой цели.
Действующее лицо (actor) 5 ‒ сущность, находящаяся вне моделируемой системы и непосредственно взаимодействующая с ней.
∇ Подобная взаимосвязь безусловно существует, что выражается на рис. Иерархия типов диаграмм для UML 1 в виде отношения зависимости со стереотипом «refine» .
∇∇ В UML 1 возникала невольная ассоциация между диаграммой кооперации и одноименной сущностью, что было не совсем верно и порой вводило в заблуждение.
∇∇∇ В UML 2 синтаксическая и смысловая нагрузка диаграммы состояний настолько изменилась, что название уже не отражало содержания.
Список новых диаграмм и их названий, принятых в этой книге, приведен ниже.
На рис. Иерархия типов диаграмм для UML 2 (часть 1 и 2) приведена диаграмма классов, отражающая взаимосвязь диаграмм в UML 2.
Далее в этой главе мы очень бегло опишем все тринадцать канонических диаграмм, с тем, чтобы иметь определенный контекст и словарный запас для последующего изложения. Детали изложены в остальных главах книги.
Но прежде чем перейти к следующему разделу, сделаем одно небольшое отступление относительно того, как стандарт требует оформлять диаграммы. Общий шаблон представления диаграммы приведен ниже.
Основных элементов оформления два: наружная рамка и ярлычок с названием диаграммы. Если с рамкой все просто ‒ это прямоугольник, ограничивающий область в котором должны находиться элементы диаграммы, то название диаграммы записывается в специальном формате, приведенном на рис. Нотация для диаграмм .
Указанная сложная форма ярлычка поддерживается не всеми инструментами. Впрочем, это не обязательно, поскольку семантика первична, а нотация вторична. Далее мы везде используем в качестве ярлычка диаграммы прямоугольник, и это не должно вызывать недоразумений.
Возможные теги (типы) для диаграмм приведены в следующей таблице. Теги, предлагаемые стандартом, записаны во второй столбец. Однако, как показала практика, предлагаемые стандартом правила не всегда удобны и логически обоснованы, поэтому третий столбец таблицы содержит разумную на наш взгляд альтернативу.
Табл. Типы и теги диаграмм
| Название диаграммы | Тег (стандартный) | Тег (предлагаемый) |
|---|---|---|
| Диаграмма использования | use case или uc | use case |
| Диаграмма классов | class | class |
| Диаграмма автомата | state machine или stm | state machine |
| Диаграмма деятельности | activity или act | activity |
| Диаграмма последовательности | interaction или sd | sd |
| Диаграмма коммуникации | interaction или sd | comm |
| Диаграмма компонентов | component или cmp | component |
| Диаграмма размещения | не определен | deployment |
| Диаграмма объектов | не определен | object |
| Диаграмма внутренней структуры | class | class или component |
| Обзорная диаграмма взаимодействия | interaction или sd | interaction |
| Диаграмма синхронизации | interaction или sd | timing |
| Диаграмма пакетов | package или pkg | package |
В настоящее время язык UML - это стандартная нотация визуального моделирования программных систем, принятая консорциумом Object Managing Group (OMG) осенью 1997 г., которая поддерживается многими объектно-ориентированными CASE-продуктами.
Стандарт UML предлагает следующий набор диаграмм для моделирования:
· диаграмма вариантов использования (use case diagram) – для моделирования бизнес-процессов организации или предприятия и определения требований к создаваемой информационной системе;
· диаграмма классов (class diagram) – для моделирования статической структуры классов системы и связей между ними;
· диаграмма поведения системы (behavior diagrams);
· диаграмма взаимодействия (interaction diagrams);
· диаграмма последовательности (sequence diagrams) – для моделирования процесса обмена сообщениями между объектами в рамках одного варианта использования;
· диаграмма кооперации (collaboration diagram) – для моделирования процесса обмена сообщениями между объектами в рамках одного варианта использования;
· диаграмма состояний (statechart diagram) – для моделирования поведения объектов системы при переходе из одного состояния в другое;
· диаграмма видов деятельности (activity diagram) – для моделирования поведения системы в рамках различных вариантов использования, или моделирования деятельностей;
· диаграмма реализации (implementation diagrams):
· диаграмма компонентов (component diagrams) – для моделирования иерархии компонентов (подсистем) информационной системы;
· диаграмма развертывания (deployment diagram) – для моделирования физической архитектуры спроектированной информационной системы.
На рис. 1.1 представлена интегрированная модель информационной системы, включающая основные диаграммы, которые должны быть разработаны в данном курсовом проекте.
Рис. 1. Интегрированная модель информационной системы в нотации языка UML
4.2. Диаграмма вариантов использования
Вариант использования представляет собой последовательность действий, выполняемых системой в ответ на событие, инициируемое некоторым внешним объектом (актером). Вариант использования описывает типичное взаимодействие между пользователем и системой. В простейшем случае вариант использования определяется в процессе обсуждения с пользователем тех функций, которые он хотел бы реализоватьв данной информационной системе. На языке UML вариант использования изображают следующим образом:
Рис.2. Вариант использования
Актер (actor) – это роль, которую пользователь играет по отношению к системе. Актеры представляют собой роли, а не конкретных людей или наименования работ. Несмотря на то, что на диаграммах вариантов использования они изображаются в виде стилизованных человеческих фигурок, актер может также быть внешней информационной системой, которой необходима некоторая информация от данной системы. Показывать на диаграмме актеров следует только в том случае, когда им действительно необходимы некоторые варианты использования. На языке UML актеры представляют в виде фигур:
Рис.3. Действующее лицо (актер)
Актеры делятся на три основных типа:
· пользователи;
· системы;
· другие системы, взаимодействующие с данной;
Время становится актером, если от него зависит запуск каких-либо событий в системе.
4.2.1. Связи между вариантами использования и актерами
В языке UML на диаграммах вариантов использования поддерживается несколько типов связей между элементами диаграммы:
· коммуникация (communication),
· включение (include),
· расширение (extend),
· обобщение (generalization).
Связь коммуникации – это связь между вариантом использования и актером. На языке UML связи коммуникации показывают с помощью однонаправленной ассоциации (сплошной линии).
Рис.4. Пример связи коммуникации
Связь включения применяется в тех ситуациях, когда имеется какой-либо фрагмент поведения системы, который повторяется более чем в одном варианте использования. С помощью таких связей обычно моделируют многократно используемую функцию.
Связь расширения применяется при описании изменений в нормальном поведении системы. Она позволяет одному варианту использования при необходимости использовать функциональные возможности другого варианта использования.
Рис.5. Пример связи включения и расширения
Связь обобщения показывает, что у нескольких актеров или классов имеются общие свойства.
Рис.6. Пример связи обобщения
4.3.
Диаграммы взаимодействия (interaction diagrams) описывают поведение взаимодействующих групп объектов. Как правило, диаграмма взаимодействия охватывает поведение объектов в рамках только одного варианта использования. На такой диаграмме отображается ряд объектов и те сообщения, которыми они обмениваются между собой.
Сообщение (message) – это средство, с помощью которого объект-отправитель запрашивает у объекта получателя выполнение одной из его операций.
Информационное (informative) сообщение – это сообщение, снабжающее объект-получатель некоторой информацией для обновления его состояния.
Сообщение-запрос (interrogative) – это сообщение, запрашивающее выдачу некоторой информации об объекте-получателе.
Императивное (imperative) сообщение – это сообщение, запрашивающее у объекта-получателя выполнение некоторых действий.
Существует два вида диаграмм взаимодействия: диаграммы последовательности (sequence diagrams) и диаграммы кооперац (collaboration diagrams).
4.3.1. Диаграмма последовательности (sequence diagrams)
Диаграмма последовательности отражает поток событий, происходящих в рамках одного варианта использования.
Все действующие лица (актеры, классы или объекты), участвующие в данном сценарии (варианте использования), показываются в верхней части диаграммы. Стрелки соответствуют сообщениям, передаваемым между актером и объектом или между объектами для выполнения требуемых функций.
На диаграмме последовательности объект изображается в виде прямоугольника, от которого вниз проведена пунктирная вертикальная линия. Эта линия называется линией жизни (lifeline) объекта . Она представляет собой фрагмент жизненного цикла объекта в процессе взаимодействия.
Каждое сообщение представляется в виде стрелки между линиями жизни двух объектов. Сообщения появляются в том порядке, как они показаны на странице сверху вниз. Каждое сообщение помечается как минимум именем сообщения. При желании можно добавить также аргументы и некоторую управляющую информацию. Можно показать самоделегирование (self-delegation) – сообщение, которое объект посылает самому себе, при этом стрелка сообщения указывает на ту же самую линию жизни.
Рис. 7. Пример диаграммы последовательности
4.3.2. Диаграмма кооперации (collaboration diagram)
Диаграммы кооперации отображают поток событий в рамках конкретного сценария (варианта использования). Сообщения упорядочены по времени, хотя диаграммы кооперации больше внимания заостряют на связях между объектами. На диаграмме кооперации представлена вся та информация, которая есть и на диаграмме последовательности, но диаграмма кооперации по-другому описывает поток событий. Из нее легче понять связи, существующие между объектами.
На диаграмме кооперации так же, как и на диаграмме последовательности, стрелки обозначают сообщения, обмен которыми осуществляется в рамках данного варианта использования. Их временная последовательность указывается путем нумерации сообщений.
Рис. 8. Пример диаграммы кооперации
4.4. Диаграмма классов
4.4.1. Общие сведения
Диаграмма классов определяет типы классов системы и различного рода статические связи, которые существуют между ними. На диаграммах классов изображаются также атрибуты классов, операции классов и ограничения, которые накладываются на связи между классами.
Диаграмма классов в языке UML - это граф, узлами которого являются элементы статической структуры проекта (классы, интерфейсы), а дугами - отношения между узлами (ассоциации, наследование, зависимости).
На диаграмме классов изображаются следующие элементы:
· Пакет (package) - набор элементов модели, логически связанных между собой;
· Класс (class) - описание общих свойств группы сходных объектов;
· Интерфейс (interface) - абстрактный класс, задающий набор операций, которые объект произвольного класса, связанного с данным интерфейсом, предоставляет другим объектам.
4.4.2. Класс
Класс - это группа сущностей (объектов), обладающих сходными свойствами, а именно, данными и поведением. Отдельный представитель некоторого класса называется объектом класса или просто объектом.
Под поведением объекта в UML понимаются любые правила взаимодействия объекта с внешним миром и с данными самого объекта.
На диаграммах класс изображается в виде прямоугольника со сплошной границей, разделенного горизонтальными линиями на 3 секции:
Верхняя секция (секция имени) содержит имя класса и другие общие свойства (в частности, стереотип).
В средней секции содержится список атрибутов
В нижней - список операций класса, отражающих его поведение (действия, выполняемые классом).
Любая из секций атрибутов и операций может не изображаться (а также обе сразу). Для отсутствующей секции не нужно рисовать разделительную линию и как-либо указывать на наличие или отсутствие элементов в ней.
На усмотрение конкретной реализации могут быть введены дополнительные секции, например, исключения (Exceptions).
Рис. 9. Пример диаграммы классов
4.4.2.1.Стереотипы классов
Стереотипы классов – это механизм, позволяющий разделять классы на категории.
В языке UML определены три основных стереотипа классов:
Boundary (граница);
Entity (сущность);
Control (управление).
4.4.2.2.Граничные классы
Граничными классами (boundary classes) называются такие классы, которые расположены на границе системы и всей окружающей среды. Это экранные формы, отчеты, интерфейсы с аппаратурой (такой как принтеры или сканеры) и интерфейсы с другими системами.
Чтобы найти граничные классы, надо исследовать диаграммы вариантов использования. Каждому взаимодействию между действующим лицом и вариантом использования должен соответствовать, по крайней мере, один граничный класс. Именно такой класс позволяет действующему лицу взаимодействовать с системой.
4.4.2.3.Классы-сущности
Классы-сущности (entity classes) содержат хранимую информацию. Они имеют наибольшее значение для пользователя, и потому в их названиях часто используют термины из предметной области. Обычно для каждого класса-сущности создают таблицу в базе данных.
4.4.2.4.Управляющие классы
Управляющие классы (control classes) отвечают за координацию действий других классов. Обычно у каждого варианта использования имеется один управляющий класс, контролирующий последовательность событий этого варианта использования. Управляющий класс отвечает за координацию, но сам не несет в себе никакой функциональности, так как остальные классы не посылают ему большого количества сообщений. Вместо этого он сам посылает множество сообщений. Управляющий класс просто делегирует ответственность другим классам, по этой причине его часто называют классом-менеджером.
В системе могут быть и другие управляющие классы, общие для нескольких вариантов использования. Например, может быть класс SecurityManager (менеджер безопасности), отвечающий за контроль событий, связанных с безопасностью. Класс TransactionManager (менеджер транзакций) занимается координацией сообщений, относящихся к транзакциям с базой данных. Могут быть и другие менеджеры для работы с другими элементами функционирования системы, такими как разделение ресурсов, распределенная обработка данных или обработка ошибок.
Помимо упомянутых выше стереотипов можно создавать и свои собственные.
4.4.2.5.Атрибуты
Атрибут – это элемент информации, связанный с классом. Атрибуты хранят инкапсулированные данные класса.
Так как атрибуты содержатся внутри класса, они скрыты от других классов. В связи с этим может понадобиться указать, какие классы имеют право читать и изменять атрибуты. Это свойство называется видимостью атрибута (attribute visibility).
У атрибута можно определить четыре возможных значения этого параметра:
Public (общий, открытый). Это значение видимости предполагает, что атрибут будет виден всеми остальными классами. Любой класс может просмотреть или изменить значение атрибута. В соответствии с нотацией UML общему атрибуту предшествует знак « + ».
Private (закрытый, секретный). Соответствующий атрибут не виден никаким другим классом. Закрытый атрибут обозначается знаком « – » в соответствии с нотацией UML.
Protected (защищенный). Такой атрибут доступен только самому классу и его потомкам. Нотация UML для защищенного атрибута – это знак « # ».
Package or Implementation (пакетный). Предполагает, что данный атрибут является общим, но только в пределах его пакета. Этот тип видимости не обозначается никаким специальным значком.
С помощью закрытости или защищенности удается избежать ситуации, когда значение атрибута изменяется всеми классами системы. Вместо этого логика изменения атрибута будет заключена в том же классе, что и сам этот атрибут. Задаваемые параметры видимости повлияют на генерируемый код.
4.4.2.6.Операции
Операции реализуют связанное с классом поведение. Операция включает три части – имя, параметры и тип возвращаемого значения.
Параметры – это аргументы, получаемые операцией «на входе». Тип возвращаемого значения относится к результату действия операции.
На диаграмме классов можно показывать как имена операций, так и имена операций вместе с их параметрами и типом возвращаемого значения. Чтобы уменьшить загруженность диаграммы, полезно бывает на некоторых из них показывать только имена операций, а на других их полную сигнатуру.
В языке UML операции имеют следующую нотацию:
Имя Операции (аргумент: тип данных аргумента, аргумент2:тип данных аргумента2,...): тип возвращаемого значения
Следует рассмотреть четыре различных типа операций:
Операции реализации;
Операции управления;
Операции доступа;
Вспомогательные операции.
Операции реализации
Операции реализации (implementor operations) реализуют некоторые бизнес-функции. Такие операции можно найти, исследуя диаграммы взаимодействия. Диаграммы этого типа фокусируются на бизнес-функциях, и каждое сообщение диаграммы, скорее всего, можно соотнести с операцией реализации.
Каждая операция реализации должна быть легко прослеживаема до соответствующего требования. Это достигается на различных этапах моделирования. Операция выводится из сообщения на диаграмме взаимодействия, сообщения исходят из подробного описания потока событий, который создается на основе варианта использования, а последний – на основе требований. Возможность проследить всю эту цепочку позволяет гарантировать, что каждое требование будет реализовано в коде, а каждый фрагмент кода реализует какое-то требование.
Операции управления
Операции управления (manager operations) управляют созданием и уничтожением объектов. В эту категорию попадают конструкторы и деструкторы классов.
Операции доступа
Атрибуты обычно бывают закрытыми или защищенными. Тем не менее, другие классы иногда должны просматривать или изменять их значения. Для этого существуют операции доступа (access operations). Такой подход дает возможность безопасно инкапсулировать атрибуты внутри класса, защитив их от других классов, но все же позволяет осуществить к ним контролируемый доступ. Создание операций Get и Set (получения и изменения значения) для каждого атрибута класса является стандартом.
Вспомогательные операции
Вспомогательными (helper operations) называются такие операции класса, которые необходимы ему для выполнения его ответственностей, но о которых другие классы не должны ничего знать. Это закрытые и защищенные операции класса.
Чтобы идентифицировать операции, выполните следующие действия:
1. Изучите диаграммы последовательности и кооперативные диаграммы. Большая часть сообщений на этих диаграммах является операциями реализации. Рефлексивные сообщения будут вспомогательными операциями.
2. Рассмотрите управляющие операции. Может потребоваться добавить конструкторы и деструкторы.
3. Рассмотрите операции доступа. Для каждого атрибута класса, с которым должны будут работать другие классы, надо создать операции Get и Set.
4.4.2.7.Связи
Связь представляет собой семантическую взаимосвязь между классами. Она дает классу возможность узнавать об атрибутах, операциях и связях другого класса. Иными словами, чтобы один класс мог послать сообщение другому на диаграмме последовательности или кооперативной диаграмме, между ними должна существовать связь.
Существуют четыре типа связей, которые могут быть установлены между классами: ассоциации, зависимости, агрегации и обобщения.
Связь ассоциация
Ассоциация (association) – это семантическая связь между классами. Их рисуют на диаграмме классов в виде обыкновенной линии.
Рис. 10. Связь ассоциация
Ассоциации могут быть двунаправленными, как в примере, или однонаправленными. На языке UML двунаправленные ассоциации рисуют в виде простой линии без стрелок или со стрелками с обеих ее сторон. На однонаправленной ассоциации изображают только одну стрелку, показывающую ее направление.
Направление ассоциации можно определить, изучая диаграммы последовательности и кооперативные диаграммы. Если все сообщения на них отправляются только одним классом и принимаются только другим классом, но не наоборот, между этими классами имеет место однонаправленная связь. Если хотя бы одно сообщение отправляется в обратную сторону, ассоциация должна быть двунаправленной.
Ассоциации могут быть рефлексивными. Рефлексивная ассоциация предполагает, что один экземпляр класса взаимодействует с другими экземплярами этого же класса.
Связь зависимость
Связи зависимости (dependency) также отражают связь между классами, но они всегда однонаправлены и показывают, что один класс зависит от определений, сделанных в другом. Например, класс A использует методы класса B. Тогда при изменении класса B необходимо произвести соответствующие изменения в классе A.
Зависимость изображается пунктирной линией, проведенной между двумя элементами диаграммы, и считается, что элемент, привязанный к концу стрелки, зависит от элемента, привязанного к началу этой стрелки.
Рис. 11. Связь зависимость
При генерации кода для этих классов к ним не будут добавляться новые атрибуты. Однако, будут созданы специфические для языка операторы, необходимые для поддержки связи.
Связь агрегация
Агрегации (aggregations) представляют собой более тесную форму ассоциации. Агрегация – это связь между целым и его частью. Например, у вас может быть класс Автомобиль, а также классы Двигатель, Покрышки и классы для других частей автомобиля. В результате объект класса Автомобиль будет состоять из объекта класса Двигатель, четырех объектов Покрышек и т. д. Агрегации визуализируют в виде линии с ромбиком у класса, являющегося целым:
Рис. 11. Связь агрегация
В дополнение к простой агрегации UML вводит более сильную разновидность агрегации, называемую композицией. Согласно композиции, объект-часть может принадлежать только единственному целому, и, кроме того, как правило, жизненный цикл частей совпадает с циклом целого: они живут и умирают вместе с ним. Любое удаление целого распространяется на его части.
Такое каскадное удаление нередко рассматривается как часть определения агрегации, однако оно всегда подразумевается в том случае, когда множественность роли составляет 1..1; например, если необходимо удалить Клиента, то это удаление должно распространиться и на Заказы (и, в свою очередь, на Строки заказа).
Я думаю, каждый слышал в детстве такую поговорку как "Семь раз отмерь, один раз отрежь ". В программировании так же. Лучше всегда обдумать реализацию до того, как вы потратите время на её исполнение. Часто приходится при реализации создавать классы, придумывать их взаимодействие. И часто визуальное представление этого может помочь решить задачу наиболее правильным образом. В этом нам и помогает UML .Если посмотреть картинки в поисковых системах, то станет понятно, что UML – это что-то про схемы, стрелочки и квадратики. Что важно, что UML переводится как Unified Modeling Language . Важно тут слово Unified. То есть наши картинки поймём не только мы, но и остальные, кто знает UML. Получается это такой международный язык рисования схем.
Как гласит Википедия
UML - это язык графического описания для объектного моделирования в области разработки программного обеспечения, моделирования бизнес-процессов, системного проектирования и отображения организационных структур.Самое интересное, о чём не все задумываются или догадываются, UML имеет спецификации. Причём даже есть спецификация UML2. Подробнее со спецификацией можно ознакомиться на сайте Object Management Group . Собственно, эта группа и занимается разработкой спецификаций UML. Интересно и то, что UML не ограничивается описанием структуры классов. Существует множество типов UML диаграмм. Краткое описание типов UML диаграмм можно увидеть в той же Википедии: UML - диаграммы или в видео Тимура Батыршинова Обзор UML диаграмм . UML так же широко применяется при описании различных процессов, например здесь: Единый вход с использованием JWT . Возвращаясь к использованию UML диаграмм классов, стоит отметить книгу Head First: Паттерны проектирования , в которой паттерны иллюстрируются теми самыми UML диаграммами. Выходит, что UML действительно используется. И выходит, что знание и понимание его применения довольно полезный навык.
Но что, если хочется самому нарисовать, да ещё и нет Ultimate версии Idea? Если мы используем IntelliJ Idea Community Edition, то у нас нет другого выбора. Для этого нужно понять, как такая UML схема устроена. Для начала нам понадобится установить Graphviz . Это набор утилит для визуализации графов. Его использует плагин, который мы будем применять. После установки необходимо добавить каталог bin из каталога установленного Graphviz в переменную среды окружения PATH . После этого в IntelliJ Idea в меню выбрать File -> Settings. В окне "Settings" выбрать категорию "Plugins", нажать кнопку "Browse repositories" и установить плагин PlantUML integration . Чем так хорош этот PlantUML ? Он использует для описания UML язык описания графов под названием "dot " и это позволяет ему быть более универсальным, т.к. данный язык используется не только PlantUML. Более того, всё что мы ниже сделаем мы можем выполнить не только в IDE, но и в онлайн сервисе planttext.com . После установки плагина PlantUML у нас появится возможность через "File" -> "New" создавать UML диаграммы. Давайте выполним создание диаграммы типа "UML class". В ходе этого автоматически генерируется шаблон с примером. Удалим его содержимое и создадим своё, вооружившись статьёй с Хабра: Отношения классов - от UML к коду . А чтобы понять, как это изобразить в тексте, возьмём мануал по PlantUML: plantuml class-diagram . В нём в самом начале представлена табличка с тем, как нужно описывать связи:
Про сами же связи можем ещё подсматривать сюда: "Отношения между классами в UML. Примеры ". На основе этих материалов приступим к созданию нашей UML диаграммы. Добавим следующее содержимое, описывающее два класса: @startuml class ArrayList { } class LinkedList { } @enduml Чтобы увидеть результат в Idea, выберем "View" -> "Tool Windows" -> "PlantUML". Мы получим просто два квадрата, обозначающие классы. Как мы знаем, оба эти класса реализуют интерфейс List. Данное отношение классов так и называют - реализация (realization). Для изображения такой связи используют стрелку с пунктирной линией. Изобразим её: interface List List < | . . ArrayList List < | . . LinkedList List - один из дочерних классов Collection . То есть он наследуется от Collection. Эта связь называется обобщением (generalization). Выглядит как стрелка с обычной непрерывной линией. Изобразим её: interface Collection Collection < | -- List Для следующего типа связи добавим в описание класса ArrayList запись о package private массиве элементов: ~ Object elementData Теперь мы хотим показать, что ArrayList содержит какие-то объекты. В данном случае будет тип связи - агрегация (aggregation). Агрегатом в данном случае является ArrayList , т.к. он содержит другие объекты. Агрегацию мы выбираем потому, что объекты в списке могут жить и без списка: они не являются его неотъемлемыми частями. Их время жизни не привязано к времени жизни списка. Агрегат с латинского переводится как "собранный", то есть что-то, составленное из чего-то. Например, в жизни, есть насосный агрегат, который состоит из насоса и двигателя. Сам агрегат можно разобрать, оставив что-то из его составных частей. Например, чтоб продать или поставить в другой агрегат. Так и в списке. И выражается это в виде пустого ромбика у агрегата и непрерывной линии. Изобразим это следующим образом: class Object { } ArrayList o- Object Теперь мы хотим показать, что в отличие от ArrayList , класс LinkedList содержит в себе Node - контейнеры, ссылающиеся на хранимые данные. В данном случае Node являются частью самого LinkedList и не могут жить отдельно. Node не является непосредственнохранимым содержимым, а только содержит ссылку на него. Например, когда мы добавляем в LinkedList какую-нибудь строку, мы добавляем новый Node , который содержит ссылку на эту строку, а также ссылку на предыдущий и следующий Node . Такой тип связи называется композицией (Composition). Для отображения у композита (того, кто состоит из частей) рисуется закрашенный робмик, к нему ведёт непрерывная линия. Запишем теперь это в виде текстового отображения связи: class Node { } LinkedList * -- Node И теперь необходимо научиться отображать ещё один важный тип связи - зависимость (dependency relationship). Он используется тогда, когда один класс использует другой, при этом класс не содержит в себе используемый класс и не является его наследником. Например, LinkedList и ArrayList умеют создавать ListIterator . Отобразим это в виде стрелок с пунктирной линией: class ListIterator ListIterator < . . . ArrayList : create ListIterator < . . . LinkedList : create Выглядеть после всего это будет следующим образом:
Детализировать можно настолько, насколько это необходимо. Все обозначения указаны тут: "PlantUML - Диаграмма классов ". Кроме того, в рисовании такой схемы нет ничего сверхъестественного, и при работе над своими задачами её можно быстро рисовать от руки. Это позволит развить навыки продумывания архитектуры приложения и поможет выявить недостатки структуры классов на раннем этапе, а не когда вы уже потратите день на реализацию неправильной модели. Мне кажется, это неплохая причина для того, чтобы попробовать?)
Так как Maven не является целью данной статьи, ответы на свои вопросы по Maven можно найти в Maven Users Centre . В сгенерированном проекте откроем на редактирование файл описания проекта, pom.xml . В него скопируем содержимое из описания uml-java-docklet installing . Используемый в описании артефакт не удалось найти в репозитории Maven Central. Но у меня заработало с этим: https://mvnrepository.com/artifact/com.chfourie/uml-java-doclet/1.0.0 . То есть надо в том описании просто заменить groupId с "info.leadinglight " на "com.chfourie " и поставить версию "1.0.0 ". После этого можем выполнить в каталоге, где находится файл pom.xml эти комманды: mvn clean install и mvn javadoc:javadoc . Теперь, если открыть сгенерированную документацию (explorer target\site\apidocs\index.html), мы увидим UML схемы. Кстати, имплементация тут уже отображается верно)
Все диаграммы UML можно условно разбить на две группы, первая из которых ‒ общие диаграммы. Общие диаграммы практически не зависят от предмета моделирования и могут применяться в любом программном проекте без оглядки на предметную область, область решений и т.д.
Диаграмма использования (use case diagram) ‒ это наиболее общее представление функционального назначения системы.
Диаграмма использования призвана ответить на главный вопрос моделирования: что делает система во внешнем мире?
На диаграмме использования применяются два типа основных сущностей: варианты использования 1 и действующие лица 2 , между которыми устанавливаются следующие основные типы отношений:
На диаграмме использования, как и на любой другой, могут присутствовать комментарии 7 . Более того, это настоятельно рекомендуется делать для улучшения читаемости диаграмм.
Основные элементы нотации, применяемые на диаграмме использования, показаны ниже. Детальное описание приведено в разделе 2.2 .
Диаграмма классов (class diagram) ‒ основной способ описания структуры системы.
Это не удивительно, поскольку UML в первую очередь объектно-ориентированный язык, и классы являются основным (если не единственным) "строительным материалом".
На диаграмме классов применяется один основной тип сущностей: классы 1 (включая многочисленные частные случаи классов: интерфейсы, примитивные типы, классы-ассоциации и многие другие), между которыми устанавливаются следующие основные типы отношений:
Некоторые элементы нотации, применяемые на диаграмме классов, показаны ниже. Детальное описание приведено в главе 3 .
Диаграмма автомата (state machine diagram) ‒ это один из способов детального описания поведения в UML на основе явного выделения состояний и описания переходов между состояниями.
В сущности, диаграммы автомата, как это следует из названия, представляют собой граф переходов состояний (см. главу 4), нагруженный множеством дополнительных деталей и подробностей.
На диаграмме автомата применяют один основной тип сущностей ‒ состояния 1 , и один тип отношений ‒ переходы 2 , но и для тех и для других определено множество разновидностей, специальных случаев и дополнительных обозначений. Перечислять их все во вступительном обзоре не имеет смысла.
Детальное описание всех вариаций диаграмм автомата приведено в разделе 4.2 , а на следующем рисунке показаны только основные элементы нотации, применяемые на диаграмме автомата.
Диаграмма деятельности (activity diagram) ‒ способ описания поведения на основе указания потоков управления и потоков данных.
Диаграмма деятельности ‒ еще один способ описания поведения, который визуально напоминает старую добрую блок-схему алгоритма. Однако за счет модернизированных обозначений, согласованных с объектно-ориентированным подходом, а главное, за счет новой семантической составляющей (свободная интерпретация сетей Петри), диаграмма деятельности UML является мощным средством для описания поведения системы.
На диаграмме деятельности применяют один основной тип сущностей ‒ действие 1 , и один тип отношений ‒ переходы 2 (передачи управления и данных). Также используются такие конструкции как развилки, слияния, соединения, ветвления 3 , которые похожи на сущности, но таковыми на самом деле не являются, а представляют собой графический способ изображения некоторых частных случаев многоместных отношений. Семантика элементов диаграмм деятельности подробно разобрана в главе 4 . Основные элементы нотации, применяемые на диаграмме деятельности, показаны ниже.
Диаграмма последовательности (sequence diagram) ‒ это способ описания поведения системы на основе указания последовательности передаваемых сообщений.
Фактически, диаграмма последовательности ‒ это запись протокола конкретного сеанса работы системы (или фрагмента такого протокола). В объектно-ориентированном программировании самым существенным во время выполнения является пересылка сообщений между взаимодействующими объектами. Именно последовательность посылок сообщений отображается на данной диаграмме, отсюда и название.
На диаграмме последовательности применяют один основной тип сущностей ‒ экземпляры взаимодействующих классификаторов 1 (в основном классов, компонентов и действующих лиц), и один тип отношений ‒ связи 2 , по которым происходит обмен сообщениями 3 . Предусмотрено несколько способов посылки сообщений, которые в графической нотации различаются видом стрелки, соответствующей отношению.
Важным аспектом диаграммы последовательности является явное отображение течения времени. В отличие от других типов диаграмм, кроме разве что диаграмм синхронизации, на диаграмме последовательности имеет значение не только наличие графических связей между элементами, но и взаимное расположение элементов на диаграмме. А именно, считается, что имеется (невидимая) ось времени, по умолчанию направленная сверху вниз, и то сообщение, которое отправлено позже, нарисовано ниже.
Ось времени может быть направлена горизонтально, в этом случае считается, что время течет слева направо.
На следующем рисунке показаны основные элементы нотации, применяемые на диаграмме последовательности. Для обозначения самих взаимодействующих объектов применяется стандартная нотация ‒ прямоугольник с именем экземпляра классификатора. Пунктирная линия, выходящая из него, называется линией жизни (lifeline) 4 . Это не обозначение отношения в модели, а графический комментарий, призванный направить взгляд читателя диаграммы в правильном направлении. Фигуры в виде узких полосок, наложенных на линию жизни, также не являются изображениями моделируемых сущностей. Это графический комментарий, показывающий отрезки времени, в течении которых объект владеет потоком управления (execution occurrence) 5 или другими словами имеет место активация (activation) объекта. Составные шаги взаимодействия(combined fragment) 6 позволяют на диаграмме последовательности, отражать и алгоритмические аспекты протокола взаимодействия. Прочие детали нотации диаграммы последовательностей см. в главе 4 .
Диаграмма коммуникации (communication diagram) ‒ способ описания поведения, семантически эквивалентный диаграмме последовательности.
Фактически, это такое же описание последовательности обмена сообщениями взаимодействующих экземпляров классификаторов, только выраженное другими графическими средствами. Более того, большинство инструментов умеет автоматически преобразовывать диаграммы последовательности в диаграммы коммуникации и обратно.
Таким образом, на диаграмме коммуникации также как и на диаграмме последовательности применяют один основной тип сущностей ‒ экземпляры взаимодействующих классификаторов 1 и один тип отношений ‒ связи 2 . Однако здесь акцент делается не на времени, а на структуре связей между конкретными экземплярами.
На рисунке показаны основные элементы нотации, применяемые на диаграмме коммуникации. Для обозначения самих взаимодействующих объектов применяется стандартная нотация ‒ прямоугольник с именем экземпляра классификатора. Взаимное положение элементов на диаграмме кооперации не имеет значения ‒ важны только связи (чаще всего экземпляры ассоциаций), вдоль которых передаются сообщения 3 . Для отображения упорядоченности сообщений во времени применяется иерархическая десятичная нумерация.
Диаграмма компонентов (component diagram) ‒ показывает взаимосвязи между модулями (логическими или физическими), из которых состоит моделируемая система.
Основной тип сущностей на диаграмме компонентов ‒ это сами компоненты 1 , а также интерфейсы 2 , посредством которых указывается взаимосвязь между компонентами. На диаграмме компонентов применяются следующие отношения:
На рисунке показаны основные элементы нотации, применяемые на диаграмме компонентов. Детальное описание приведено в главе 3 .
Диаграмма размещения (deployment diagram) наряду с отображением состава и связей элементов системы показывает, как они физически размещены на вычислительных ресурсах во время выполнения.
Таким образом, на диаграмме размещения, по сравнению с диаграммой компонентов, добавляется два типа сущностей: артефакт 1 , который является реализацией компонента 2 и узел 3 (может быть как классификатор, описывающий тип узла, так и конкретный экземпляр), а также отношение ассоциации между узлами 4 , показывающее, что узлы физически связаны во время выполнения.
На рисунке показаны основные элементы нотации, применяемые на диаграмме размещения. Для того чтобы показать, что одна сущность является частью другой, применяется либо отношение зависимости «deploy» 5 , либо фигура одной сущности помещается внутрь фигуры другой сущности 6 . Детальное описание диаграммы приведено в главе 3 .
UML-диаграмма - это специализированный язык графического описания, предназначенный для объектного моделирования в сфере разработки различного программного обеспечения. Данный язык имеет широкий профиль и представляет собой открытый стандарт, в котором используются различные графические обозначения, чтобы создать абстрактную модель системы. UML создавался для того, чтобы обеспечить определение, визуализацию, документирование, а также проектирование всевозможных программных систем. Стоит отметить, что сама по себе UML-диаграмма не представляет собой язык программирования, но при этом предусматривается возможность генерации на ее основе отдельного кода.
Применение UML не заканчивается на моделировании всевозможного ПО. Также данный язык активно сегодня используется для моделирования различных бизнес-процессов, ведения системного проектирования, а также отображения организационных структур.
С помощью UML разработчики программного обеспечения могут обеспечить полное соглашение в используемых графических обозначениях, чтобы представить общие понятия, такие как: компонент, обобщение, класс, поведение и агрегация. За счет этого достигается большая степень концентрации на архитектуре и проектировании.
Также стоит отметить, что есть несколько видов таких диаграмм.
Диаграмма классов UML представляет собой статическую структурную диаграмму, предназначенную для описания структуры системы, а также демонстрации атрибутов, методов и зависимостей между несколькими различными классами.
Стоит отметить тот факт, что есть несколько точек зрения на построение таких диаграмм в зависимости от того, каким образом они будут использоваться:
Диаграмма компонентов UML представляет собой полностью статическую структурную диаграмму. Предназначается она для того, чтобы продемонстрировать разбиение определенной программной системы на разнообразные структурные компоненты, а также связи между ними. Диаграмма компонентов UML в качестве таковых может использовать всевозможные модели, библиотеки, файлы, пакеты, исполняемые файлы и еще множество других элементов.
UML диаграмма композитной/составной структуры также является статической структурной диаграммой, но используется она для того, чтобы показать внутреннюю структуру классов. По возможности данная диаграмма может продемонстрировать также взаимодействие элементов, находящихся во внутренней структуре класса.
Подвидом их является UML-диаграмма кооперации, которая используется для демонстрации ролей, а также взаимодействия различных классов в границах кооперации. Они являются достаточно удобными в том случае, если нужно моделировать шаблоны проектирования.
Стоит отметить, что одновременно могут использоваться виды диаграмм UML классов и композитной структуры.
Данная диаграмма используется для того, чтобы моделировать работающие узлы, а также всевозможные артефакты, которые на них были развернуты. В UML 2 на различных узлах осуществляется разворачивание артефактов, в то время как в первой версии разворачивались исключительно компоненты. Таким образом, диаграмма развертывания UML используется преимущественно ко второй версии.
Между артефактом и тем компонентом, который он реализует, формируется зависимость манифестации.
Данный вид позволяет увидеть полноценный или же частичный снимок создаваемой системы в определенный момент времени. На ней полностью отображаются все экземпляры классов конкретной системы с указанием текущих значений их параметров, а также связей между ними.
Эта диаграмма носит структурный характер, и основным ее содержанием являются всевозможные пакеты, а также отношения между ними. В данном случае нет никакого жесткого разделения между несколькими структурными диаграммами, вследствие чего их использование чаще всего встречается исключительно для удобства, и никакого семантического значения в себе не несет. Стоит отметить, что различные элементы могут предоставлять другие UML диаграммы (примеры: пакеты и сами диаграммы пакетов).
Их использование осуществляется для того, чтобы обеспечить организацию нескольких элементов в группы по определенному признаку, чтобы упростить структуру, а также организовать работу с моделью данной системы.
Диаграмма деятельности UML отображает разложение определенной деятельности на несколько составных частей. В данном случае понятием «деятельность» называется спецификация определенного исполняемого поведения в виде параллельного, а также координированного последовательного выполнения различных подчиненных элементов - вложенных типов деятельности и различных действий, объединенных потоками, идущими от выходов определенного узла к входам другого.
Диаграмма деятельности UML достаточно часто используются для того, чтобы моделировать различные бизнес-процессы, параллельные и последовательные вычисления. Помимо всего прочего ими моделируются всевозможные технологические процедуры.
Этот вид называется и несколько иначе - диаграмма состояний UML. Имеет представленный конечный автомат с простыми и композитными состояниями, а также переходами.
Конечный автомат представляет собой спецификацию последовательности различных состояний, через которые проходит определенный объект, или же взаимодействие в ответ на некоторые события своей жизни, а также ответные действия объекта на такие события. Конечный автомат, который использует диаграмма состояний UML, закрепляется за исходным элементом и используется для того, чтобы определить поведение его экземпляров.
В качестве аналогов таких диаграмм могут использоваться так называемые дракон-схемы.
Диаграмма вариантов использования UML отображает на себе все отношения, которые возникают между актерами, а также различными вариантами использования. Главная ее задача - осуществлять собой полноценное средство, при помощи которого заказчик, конечный пользователь или же какой-нибудь разработчик сможет совместно обсуждать поведение и функциональность определенной системы.
Если диаграмма вариантов использования UML используется в процессе моделирования системы, то аналитик собирается:
Если разрабатывается в UML диаграмма использования, процедура начинается с текстового описания, которое получается при работе с заказчиком. При этом стоит отметить тот факт, что различные нефункциональные требования в процессе составления модели прецедентов полностью опускаются, и для них уже будет формироваться отдельный документ.
Диаграмма коммуникации точно так же, как и диаграмма последовательности UML, является транзитивной, то есть выражает в себе взаимодействие, но при этом демонстрирует его разными способами, и при необходимости с нужной степенью точности можно преобразовать одну в другую.
Диаграмма коммуникации отображает в себе взаимодействия, которые происходят между различными элементами композитной структуры, а также ролями кооперации. Главным отличием ее от диаграммы последовательности является то, что на ней достаточно явно указываются отношения между несколькими элементами, а время не используется в качестве отдельного измерения.
Данный тип отличается абсолютно свободным форматом упорядочивания нескольких объектов и связей точно так же, как это осуществляется в диаграмме объектов. Если есть необходимость в том, чтобы поддерживать порядок сообщений при этом свободном формате, осуществляется их хронологическая нумерация. Чтение данной диаграммы начинается с изначального сообщения 1.0, и впоследствии продолжается по тому направлению, по которому осуществляется передача сообщений от одного объекта к другому.
В большинстве своем такие диаграммы демонстрируют точно такую же информацию, которую предоставляет нам диаграмма последовательности, однако из-за того, что здесь используется другой способ представления информации, определенные вещи на одной диаграмме становится гораздо проще определить, чем на другой. Также стоит отметить, что диаграмма коммуникаций более наглядно показывает, с какими элементами вступает во взаимодействие каждый отдельный элемент, в то время как диаграмма последовательности более ясно показывает, в каком порядке осуществляются взаимодействия.
Диаграмма последовательности UML демонстрирует взаимодействия между несколькими объектами, которые упорядочиваются в соответствии с временем их проявления. На такой диаграмме отображается упорядоченное во времени взаимодействие между несколькими объектами. В частности, на ней отображаются все объекты, которые принимают участие во взаимодействии, а также полная последовательность обмениваемых ими сообщений.
Главными элементами в данном случае выступают обозначения различных объектов, а также вертикальные линии, отображающие течение времени и прямоугольники, предоставляющие деятельность определенного объекта или же выполнение им какой-либо функции.
Данный тип диаграмм позволяет продемонстрировать взаимодействия между несколькими объектами, абстрагируясь от последовательности трансляции сообщений. Данный тип диаграмм в компактном виде отображает в себе абсолютно все передаваемые и принимаемые сообщения определенного объекта, а также форматы этих сообщений.
По причине того, что диаграммы последовательности и коммуникации представляют собой просто-напросто разный взгляд на одни и те же процедуры, Rational Rose предоставляет возможность создавать из диаграммы последовательности коммуникационную или же наоборот, а также осуществляет полностью автоматическую их синхронизацию.
Это диаграммы языка UML, которые относятся к разновидности диаграмм деятельности и включают в себя одновременно элементы Sequence и конструкции потока управления.
Стоит отметить тот факт, что данный формат объединяет в себе Collaboration и Sequence diagram, которые предоставляют возможность с разных точек зрения рассматривать взаимодействие между несколькими объектами в формируемой системе.
Представляет собой альтернативный вариант диаграммы последовательности, который явным образом демонстрирует изменение состояния на линии жизни с определенной шкалой времени. Может быть достаточно полезной в различных приложениях реального времени.
Стоит отметить несколько преимуществ, которыми отличается UML диаграмма пользования и другие:
Несмотря на то что построение UML-диаграмм отличается массой своих плюсов, довольно часто их и критикуют за следующие недостатки:
Таким образом, использование данного языка является актуальным далеко не во всех ситуациях.
