Skip to content

Latest commit

 

History

History
247 lines (224 loc) · 21.3 KB

uml.md

File metadata and controls

247 lines (224 loc) · 21.3 KB

Концептуальная модель UML

  1. Строительные блоки языка
  2. правила, определяющих их сочетания, и
  3. некоторых общих для всего языка механизмов.

Строительные блоки UML

Словарь UML включает три вида строительных блоков:

  1. Сущности.
  2. Связи.
  3. Диаграммы.

Сущности (things) – это абстракции, которые являются основными элементами модели, связи (relationships) соединяют их между собой, а диаграммы (diagrams)
группируют представляющие интерес наборы сущностей. Есть четыре вида сущностей UML:

  1. Структурные.
  2. Поведенческие.
  3. Группирующие.
  4. Аннотирующие.

Структурные сущности – «имена существительные» в моделях UML. Это в основном статические части модели, представляющие либо концептуальные, либо физические элементы. В совокупнос- ти структурные сущности называются классификаторами (clas- sifiers).

1. Структурные сущности

Класс (class) – это описание набора объектов с одинаковыми атрибутами, операциями, связями и семантикой. Класс реализует один или несколько интерфейсов. Графически класс изображается в виде прямоугольника, обычно включающего имя, атрибуты и операции

Интерфейс (interface) – это набор операций, который специфи- цирует сервис (набор услуг) класса или компонента. Таким образом, интерфейс описывает видимое извне поведение элемента. Может представлять полное поведение класса или компонента либо только часть такого поведения. Определяет набор спецификаций операций (то есть их сигнатуру), но никогда не определяет детали их реализа- ции. Объявление интерфейса изображается как класс с ключевым словом «interface» над его именем; атрибуты несущественны, за ис- ключением иногда показываемых констант. Интерфейс, однако, ред- ко существует сам по себе. Интерфейс, представляемый классом для внешнего мира, изображается в виде маленького круга, соединенно- го линией с рамкой класса. Интерфейс, запрашиваемый классом от некоторого другого класса, представлен маленьким полукругом, соединенным с рамкой класса линией.

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

Вариант использования (use case) – это описание последователь- ности действий, выполняемых системой и приносящих значимый ре- зультат конкретному действующему лицу (actor) . Варианты использо- вания применяются для структурирования поведенческих сущностей модели. Реализуются посредством коопераций. Графически вариант использования представлен эллипсом, нарисованным сплошной лини- ей (обычно он включает в себя только имя)

Оставшиеся три сущности – активные классы, компоненты и узлы (nodes) – все подобны классам; это говорит о том, что они также описывают наборы сущностей, разделяющих одни и те же атрибуты, операции, связи и семантику. Однако эти три понятия в достаточной степени различаются и необходимы для моделиро- вания определенных аспектов объектно-ориентированных систем, поэтому нуждаются в специальном рассмотрении. Активный класс – это класс, объекты которого являются вла- дельцами одного или нескольких процессов или потоков (threads) и, таким образом, могут инициировать управляющие воздействия. Активный класс во всем подобен простому классу, за исключени- ем того, что его объекты представляют собой элементы, поведе- ние которых осуществляется параллельно с поведением других элементов. Изображается как класс с двойными боковыми линия- ми; обычно включает в себя имя, атрибуты и операции.

Компонент – это модульная часть системы, которая скрывает свою реализацию за набором внешних интерфейсов. Компонен- ты системы, разделяющие общие интерфейсы, могут замещать друг друга, сохраняя при этом одинаковое логическое поведе- ние. Реализация компонента может быть выражена объединени- ем частей и коннекторов; при этом части могут включать в себя более мелкие компоненты. Графически компонент представлен как класс со специальной пиктограммой в правом верхнем углу.

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

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

###Поведенческие сущности – динамические части моделей UML. Это «глаголы» моделей, представляющие поведение во времени и пространстве. Всего существует три основных вида поведенчес- ких сущностей. Первый из них – взаимодействие (interaction) – представляет собой поведение, которое заключается в обмене сообщениями меж- ду наборами объектов или ролей в определенном контексте для до- стижения некоторой цели. Поведение совокупности объектов или индивидуальная операция могут быть выражены взаимодействи- ем. Взаимодействие включает множество других элементов – таких как сообщения, действия (actions) и коннекторы (соединения меж- ду объектами). Сообщение изображается в виде линии со стрелкой, почти всегда сопровождаемой именем операции.

Вторая из поведенческих сущностей – автомат (state machine) – представляет собой поведение, характеризуемое последовательностью состояний объекта, в которых он оказывается на протяжении своегожизненного цикла в ответ на события, вместе с его реакцией на эти события. Поведение индивидуального класса или кооперации клас- сов может быть описано в терминах автомата. Автомат включает в себя множество других элементов: состояния, переходы (из одного состояния в другое), события (сущности, которые инициируют пере- ходы), а также действия (реакции на переходы). Графически состоя- ние представлено прямоугольником с закругленными углами, обычно с указанием имени и подсостояний, если таковые есть.

Третья из поведенческих сущностей – деятельность (activity) – специфицирует последовательность шагов процесса вычислений. Во взаимодействии внимание сосредоточено на наборе взаимо- действующих объектов, в автомате – на жизненном цикле одного объекта; для деятельности же в центре внимания – последователь- ность шагов безотносительно к объектам, выполняющим каждый шаг. Отдельный шаг деятельности называется действием (action). Изображается оно в виде прямоугольника с закругленными угла- ми, включающего имя, которое отражает его назначение. Состояния и действия различаются по контекстам.

Группирующие сущности – организационная часть моделей UML.

Это «ящики», по которым можно разложить модель. Главная из группирующих сущностей – пакет. Пакет (package) – это механизм общего назначения для органи- зации проектных решений, который упорядочивает конструкции ре- ализации. Структурные сущности, поведенческие сущности и даже другие группирующие сущности могут быть помещены в пакет. В от- личие от компонентов (существующих только во время исполнения), пакеты полностью концептуальны, то есть существуют лишь на этапе разработки. Пакет изображается в виде папки с закладкой, обычно только с указанием имени, но иногда и содержимого Пакеты – основная группирующая сущность, с помощью ко- торой вы можете организовать UML-модель. Существуют и такие вариации, как каркасы (frameworks), модели, подсистемы (разно- видность пакетов). Аннотирующие сущности – это поясняющие части UML-моде- лей, иными словами, комментарии, которые вы можете применить для описания, выделения и пояснения любого элемента модели. Главная из аннотирующих сущностей – примечание (note). Это простой символ, служащий для описания ограничений и коммента- риев, относящихся к элементу либо набору элементов. Графически представлен прямоугольником с загнутым углом; внутри помеща- ется текстовый или графический комментарий.

###Существует четыре типа связей в UML:

  1. Зависимость.
  2. Ассоциация.
  3. Обобщение.
  4. Реализация.

Эти связи представляют собой базовые строительные блоки для описания отношений в UML, используемые для разработки хорошо согласованных моделей. Первая из них – зависимость (dependency) – семантически представляет собой связь между двумя элементами модели, в ко- торой изменение одного элемента (независимого) может привести к изменению семантики другого элемента (зависимого). Графичес- ки представлена пунктирной линией, иногда со стрелкой; может быть снабжена меткой --------------------->

Вторая, ассоциация (association) , – это структурная связь меж- ду классами, которая описывает набор связей, существующих меж- ду объектами – экземплярами классов. Агрегация (aggregation) – особая разновидность ассоциации, представляющая структурную связь целого с его частями. Изображается сплошной линией, иног- да со стрелкой; иногда снабжена меткой и часто содержит другие пометки, такие как мощность и конечные имена

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

Четвертая – реализация (realization) – это семантическая связь между классификаторами, когда один из них специфицирует со- глашение, которого второй обязан придерживаться. Вы встретите связи реализации в двух случаях: между интерфейсами и классами или компонентами, которые реализуют эти интерфейсы, а также между вариантами использования и реализующими их коопераци- ями. Связь реализации в графическом исполнении – гибрид связей обобщения и зависимости.

Эти четыре элемента представляют основные сущности отно- шений, которые могут быть включены в UML-модели. Есть так- же различные их вариации: уточнение (refinements), след (trace), включение (include) и расширение (extend).

##Диаграммы UML. Диаграмма – это графическое представле- ние набора элементов, чаще всего изображенного в виде связного графа вершин (сущностей) и путей (связей). Вы рисуете диаграм- мы для визуализации системы с различных точек зрения, поэтому отдельная диаграмма – это проекция системы. Для всех систем, кроме самых тривиальных, диаграмма представляет собой ограни- ченный взгляд на элементы, составляющие систему. Один и тот же элемент может появляться либо во всех диаграммах, либо в неко- торых (наиболее частый случай), либо вообще ни в одной (очень редкий случай). Теоретически диаграмма может включать в себя любую комбинацию сущностей и связей. На практике, однако, исполь зуется лишь небольшое число общих комбинаций, состо- ящих из пяти наиболее часто применяемых представлений архи- тектуры программных систем. По этой причине UML включает 13 видов диаграмм:

  1. Диаграмма классов.
  2. Диаграмма объектов.
  3. Диаграмма компонентов.
  4. Диаграмма составной структуры.
  5. Диаграмма вариантов использования.
  6. Диаграмма последовательности.
  7. Диаграмма коммуникации.
  8. Диаграмма состояний.
  9. Диаграмма деятельности.
  10. Диаграмма размещения.
  11. Диаграмма пакетов.
  12. Временная диаграмма.
  13. Диаграмма обзора взаимодействий.