Анализ и моделирование на UML 1 page

1. Назначение UML

2. Модель и ее элементы – сущности и отношения

3. Модели и их представления – использования, поведения и структуры

4. Общие свойства модели

5. Иерархия диаграмм в UML 1 и UML2

6. Диаграммы использования, реализация вариантов использования

7. Моделирование структуры на UML

8. Диаграмма классов. Классы и отношения

9. Диаграммы реализации: узлы, компоненты и интерфейсы

10. Моделирование поведения на UML

11. Диаграммы состояний

12. Диаграммы деятельности

13. Диаграмма последовательности

14. Влияние UML на процесс разработки

1. Назначение UML

Определение OMG(Object Management Group)

"The Unified Modeling Language (UML) is a graphical language for visualizing, specifying, constructing, and documenting the artifacts of a software-intensive system. The UML offers a standard way to write a system's blueprints, including conceptual things such as business processes and system functions as well as concrete things such as programming language statements, database schemas, and reusable software components."-

Язык графического описания для объектного моделирования систем (Википедия)

В UML используются следующие виды диаграмм (для исключения неоднозначности приведены также обозначения на английском языке):

Structure Diagrams:

Class diagram

Component diagram

Composite structure diagram

Collaboration (UML2.0)

Deployment diagram

Object diagram

Package diagram

Profile diagram (UML2.2)

Behavior Diagrams:

Activity diagram

State Machine diagram

Use case diagram

Interaction Diagrams:

Communication diagram (UML2.0) / Collaboration (UML1.x)

Interaction overview diagram (UML2.0)

Sequence diagram

Timingdiagram (UML2.0)

Структурные диаграммы:

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

Диаграмма компонентов

Диаграмма композитной/составной структуры

Диаграмма кооперации (UML2.0)

Диаграмма развёртывания

Диаграмма объектов

Диаграмма пакетов

Диаграмма профилей (UML2.2)

Диаграммы поведения:

Диаграмма деятельности

Диаграмма состояний

Диаграмма вариантов использования

Диаграммы взаимодействия:

Диаграмма коммуникации (UML2.0) / Диаграмма кооперации (UML1.x)

Диаграмма обзора взаимодействия (UML2.0)

Диаграмма последовательности

Диаграмма синхронизации (UML2.0)

2. Модель и ее элементы – сущности

(Туривный С.)

Для удобства обзора сущности в UML можно подразделить на четыре группы:

структурные;

поведенческие;

группирующие;

аннотационные.

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

Объект (object) 1 ‒ сущность, обладающая уникальностью и инкапсулирующая в себе состояние и поведение.

Класс (class) 2 ‒ описание множества объектов с общими атрибутами, определяющими состояние, и операциями, определяющими поведение.

Интерфейс (interface) 3 ‒ именованное множество операций, определяющее набор услуг, которые могут быть запрошены потребителем и предоставлены поставщиком услуг.

Кооперация (collaboration) 4 ‒ совокупность объектов, которые взаимодействуют для достижения некоторой цели.

Действующее лицо (actor) 5 ‒ сущность, находящаяся вне моделируемой системы и непосредственно взаимодействующая с ней.

Компонент∇ (component) 6 ‒ модульная часть системы с четко определенным набором требуемых и предоставляемых интерфейсов.

Артефакт (artifact) 7 ‒ элемент информации, который используется или порождается в процессе разработки программного обеспечения. Другими словами, артефакт ‒ это физическая единица реализации, получаемая из элемента модели (например, класса или компонента).

Узел (node) 8 ‒ вычислительный ресурс, на котором размещаются и при необходимости выполняются артефакты.

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

Состояние (state) 1 ‒ период в жизненном цикле объекта, находясь в котором объект удовлетворяет некоторому условию и осуществляет собственную деятельность или ожидает наступления некоторого события.

Деятельность (activity) 2 можно считать частным случаем состояния, который характеризуется продолжительными (по времени) не атомарными вычислениями.

Действие (action) 3 ‒ примитивное атомарное вычисление.

Это только надводная часть айсберга поведенческих сущностей: состояния бывают самые разные (см.раздел 4.2). Кроме того, при моделировании поведения используется еще ряд вспомогательных сущностей, которые здесь не перечислены, потому что сосуществуют только вместе с указанными основными.

Несколько особняком стоит сущность ‒ вариант использования.

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

Группирующая сущность в UML одна ‒ пакет ‒ зато универсальная.

Пакет (package) 1 ‒ группа элементов модели (в том числе пакетов).

Аннотационная сущность тоже одна ‒ комментарий.

Комментарий (comment) 2 ‒ произвольное по формату и содержанию описание одного или нескольких элементов модели.

(http://book.uml3.ru/sec_1_4)

3. Модель и ее элементы – отношения

(Туривный С.)

В UML используются четыре основных типа отношений:

зависимость (dependency);

ассоциация (association);

обобщение (generalization);

реализация (realization).

Зависимость ‒ это наиболее общий тип отношения между двумя сущностями.

Отношение зависимости указывает на то, что изменение независимой сущности каким-то образом влияет на зависимую сущность.

Графически отношение зависимости изображается в виде пунктирной линии со стрелкой 1, направленной от зависимой сущности 2 к независимой 3, как показано на следующем рисунке. Как правило, семантика конкретной зависимости уточняется в модели с помощью дополнительной информации. Например, зависимость со стереотипом «use» означает, что зависимая сущность использует (скажем, вызывает операцию) независимую сущность.

Ассоциация ‒ это наиболее часто используемый тип отношения между сущностями.

Отношение ассоциации имеет место, если одна сущность непосредственно связана с другой (или с другими ‒ ассоциация может быть не только бинарной).

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

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

Графически обобщение изображается в виде линии с треугольной незакрашенной стрелкой на конце 1, направленной от частного 2 (подкласса) к общему 3 (суперклассу), как показано на следующем рисунке.

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

Отношение реализации указывает, что одна сущность является реализацией другой.

Например, класс является реализацией интерфейса. Графически реализация изображается в виде пунктирной линии с треугольной незакрашенной стрелкой на конце 1, направленной от реализующей сущности 2 к реализуемой 3, как показано на следующем рисунке.

(http://book.uml3.ru/sec_1_4)

4. Модели и их представления – использования, поведения и структуры

(Туривный С.)

Идея состоит в том, что абстрактный граф модели, состоящий из множества разнотипных сущностей и отношений, не подлежит конструированию или изучению в целом. Каждый раз для визуализации, изменения или иных манипуляций из этого общего графа вычленяются только сущности и отношения, релевантные для определенного аспекта моделируемой системы, а все остальные игнорируются. Такой вид с определенной точки зрения, можно сказать, проекцию модели, мы называем представлением(view). Можно сказать, что представление ‒ это средство логического структурирования модели.

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

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

Концептуальная модель (conceptual model). На диаграммы такой модели будут смотреть, их будут обдумывать, но с самой моделью ничего делать не будут. Это не означает, что модель не нужна ‒ это означает, что модель используется только для управления мыслительным процессом, для понимания. Поэтому мы называем такие модели концептуальными (также применются терминымодель анализа (analysis model) или аналитическая модель). Такой тип использования моделей один из самых важных, например, потому что так используются модели, которые получаются в результате анализа предметной области. Концептуальные модели довольно стабильны: если не меняется предметная область, то нет нужды менять и модель. Главное требования к модели предметной области: концептуальная целостность (consistency).

Модель проектирования (design model). Модель проектирования представляет собой высокоуровневое (на уровне подсистем) и низкоуровневое (на уровне классов, если речь идет об использовании объектно-ориентированного подхода) описание программной системы. Модель проектирования предназначена для того, чтобы, руководствуясь ею, разработать программный код приложения. Как правило, архитектура (высокоуровневое описание) и код разрабатываются итеративно, и разработчикам в процессе разработки необходимо модифицировать модель проектирования, чтобы она соответствовала принимаемым решениям. Главное требование к модели проектирования: понятность (usability). Действительно, разработчики должны полностью понимать модель, чтобы вести разработку.

Модель реализации (implementation model). Модель реализации предназначена для автоматического преобразования, возможно многократного, в существенно другой вид, например, в исполнимый код. Такое предназначение требует указания необходимых деталей реализации в модели, поскольку "от себя" компьютер их добавить не сможет. Главное требование к моделям реализации: полнота(completeness).

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

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

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

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

(http://book.uml3.ru/sec_1_7)

5. Общие свойства модели и механизмы расширения – стереотипы, помеченные значения, ограничения

(Туривный С.)

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

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

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

В настоящем разделе описываются все стандартные элементы подобного рода.

Стереотипы

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

Примечание: Некоторые из элементов, представленных в таблице, являются, строго говоря, не стереотипами, а стандартными ключевыми словами. Различие между ними довольно тонкое. В метамодели UML некоторые элементы, например trace, имеют очевидную семантику, то есть являются явной частью метамодели, а не настоящими стереотипами. С точки зрения разработчика, однако, они все равно изображаются в нотации стереотипов. Такие элементы определены как стандартные ключевые слова, чтобы можно было зарезервировать их использование в согласии с метамоделъю UML. В таблице ключевые слова выделены курсивом.

Обычно стереотипный элемент изображается следующим образом: имя стереотипа размещается над именем элемента и заключается в двойные кавычки, например "trace". Co стереотипом может быть ассоциирована пиктограмма, используемая как альтернативная форма визуализации данного элемента. Хотя в самом UML такие пиктограммы ни для одного стереотипа не заданы, в таблице все же приводятся некоторые общепринятые изображения.

Стереотип/ ключевое слово

Символ, к которому он применим

Назначение

actor

Класс (class)

Определяет связанное множество ролей, которые играет пользователь прецедента при взаимодействии с ним

access

Зависимость (dependency)

Сообщает, что открытое содержание целевого пакета доступно в пространстве имен исходного пакета

association

Концевая точка связи (link end)

Указывает, что соответствующий объект видим ассоциацией

become

Сообщение (message)

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

bind

Зависимость (dependency)

Исходный класс инстанцирует целевой шаблон с данными фактическими параметрами

call

Зависимость (dependency)

Исходная операция вызывает целевую

copy

Сообщение (message)

Целевой объект - это точная, но независимая копия исходного

create

Событие (event), сообщение (message)

Целевой объект создан в результате события или сообщения

derive

Зависимость (dependency)

Исходный объект может быть вычислен по целевому

destroy

Событие (event), сообщение (message)

Целевой объект уничтожен в результате события или сообщения

document

Компонент (component)

Компонент представляет документ

enumeration

Класс (class)

Определяет перечислимый тип, включая его возможные значения как набор идентификаторов

exception

Класс (class)

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

executable

Компонент (component)

Описывает компонент, который может быть выполнен в узле

extend

Зависимость (dependency)

Целевой вариант использования расширяет поведение исходного в данной точке расширения

facade

Пакет (package)

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

file

Компонент (component)

Компонент, который представляет документ, содержащий исходный код или данные

framework

Пакет (package)

Пакет, состоящий в основном из образцов (паттернов)

friend

Зависимость (dependency)

Исходный класс имеет специальные права видимости в целевом

global

Концевая точка связи (link end)

Соответствующий объект видим, поскольку принадлежит объемлющей области действия

import

Зависимость (dependency)

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

implementation

Обобщение (generalization)

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

implementationClass

Класс (class)

Реализация класса на некотором языке программирования

include

Зависимость (dependency)

Исходный прецедент явно включает поведение другого прецедента в точке, определяемой исходным

instanceOf

Зависимость (dependency)

Исходный объект является экземпляром целевого классификатора

instantiate

Зависимость (dependency)

Операции над исходным классом создают экземпляры целевого класса

interface

Класс (class)

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

invariant

Ограничение (constraint)

Ограничение, которое всегда должно выполняться для ассоциированного элемента

library

Компонент (component)

Статическая или динамическая объектная библиотека

local

Концевая точка связи (link end)

Соответствующий объект видим, так как находится в локальной области действия

metaclass

Классификатор (classifier)

Классификатор, все объекты которого являются классами

model

Пакет (package)

Описывает семантически замкнутую абстракцию системы

parameter

Концевая точка связи (link end)

Соответствующий объект видим, так как является параметром

postcondition

Ограничение (constraint)

Ограничение, которое должно выполняться после выполнения операции

powertype

Класс (class)

Классификатор, все объекты которого являются потомками данного родителя

Зависимость (dependency)

Говорит, что целевой классификатор связан с исходным отношением powertype

precondition

Ограничение (constraint)

Ограничение, которое должно выполняться перед выполнением операции

process

Класс (class)

Классификатор, экземпляр которого представляет ресурсоемкий поток управления

refine

Зависимость (dependency)

Говорит, что исходный объект является более детальной абстракцией, чем целевой

requirement

Комментарий (comment)

Описывает желаемое свойство или поведение системы

responsibility

Комментарий (comment)

Описывает контракт или обязательство класса

send

Зависимость (dependency)

Исходная операция посылает целевое событие

signal

Класс (class)

Асинхронный стимул, который передается одним экземпляром другому

stereotype

Класс (class)

Классификатор - это стереотип, который может быть применен к другим элементам

stub

Пакет (package)

Пакет выступает в роли заместителя для открытого содержимого другого пакета

subsystem

Пакет (package)

Описывает группирование элементов, ряд которых составляет спецификацию поведения других элементов

system

Пакет (package)

Описывает пакет, представляющий всю моделируемую систему

table

Компонент (component)

Компонент, представляющий таблицу базы данных

thread

Класс (class)

Классификатор, экземпляр которого представляет облегченный поток управления

trace

Зависимость (dependency)

Целевой элемент - это исторический предок исходного

type

Класс (class)

Абстрактный класс, который используется только для спецификации структуры и поведения (но не реализации) множества объектов

use

Зависимость (dependency)

Семантика исходного элемента зависит от семантики открытого содержания целевого элемента

utility

Класс (class)

Определяет класс, для которого область действия всех атрибутов и операций - класс

Помеченные значения

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

В большинстве случаев помеченное значение изображается посредством размещения метки и значения под именем элемента, к которому оно присоединено. При этом все сочетание заключается в фигурные скобки, например {location = client }. Если значение метки представляет собой длинный текст, то помеченное значение можно поместить в дополнительный раздел классификатора.

Помеченное значение

Символы, к которым оно применимо

Назначение

documentation

Все элементы

Содержит комментарий, описание или пояснение к тому элементу, к которому присоединено

location

Большинство элементов

Определяет узел или компонент, которому принадлежит элемент

persistence

Класс (class), ассоциация (association) атрибут (attribute)

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

semantics

Класс (class), операция (operation)

Описывает назначение класса или операции

Ограничения

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

В большинстве случаев ограничение размещается рядом с элементом и заключается в фигурные скобки, например {complete}. Можно изображать ограничение и по-другому - помещая в примечание, соединенное с элементом зависимостью.

Ограничение

Символ, к которому оно применимо

Назначение (о чем говорит данное ограничение)

complete

Обобщение (generalization)

В модели специфицированы все потомки в данном обобщении (хотя некоторые могут быть скрыты на диаграммах), и дополнительных потомков определять не разрешается

destroyed

Экземпляр (instance), связь (link)

Экземпляр или связь уничтожаются до завершения выполнения объемлющего взаимодействия

disjoint

Обобщение (generalization)

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

implicit

Ассоциация (association)

Отношение является не явно выраженным, а концептуальным

incomplete

Обобщение (generalization)

Специфицированы не все потомки в обобщении (учитывая и скрытых). Разрешается определять дополнительных потомков

new

Экземпляр (instance), связь (link)

Экземпляр или связь создаются в процессе выполнения объемлющего взаимодействия

or

Ассоциация (association)

Из множества ассоциаций ровно одна является явно выраженной для каждого ассоциированного объекта

overlapping

Обобщение (generalization)

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

transient

Экземпляр (instance), связь (link)

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

(http://dit.isuct.ru/ivt/books/CASE/case11/prB.htm)

6. Иерархия диаграмм в UML 1 и UML 2

(Туривный С.)

В UML 1∇ всего определено 9 канонических типов диаграмм. Ниже перечислены их названия, принятые в этой книге (в других источниках есть отличия).

Диаграмма использования∇ (Use Case diagram)

Диаграмма классов (Class diagram)

Диаграмма объектов (Object diagram)

Диаграмма состояний (State chart diagram)

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

Диаграмма последовательности (Sequence diagram)

Диаграмма кооперации (Collaboration diagram)

Диаграмма компонентов (Component diagram)

Диаграмма размещения∇∇ (Deployment diagram)

В UML 2∇ внесены значительные коррективы как в список канонических диаграмм, а именно их число увеличилось до 13, так и в список доступных конструкций языка, что значительно расширило область его применения. Кроме этого две диаграммы были переименованы: диаграмма кооперации была переименована в диаграмму коммуникации∇∇, а диаграмма состояний в диаграмму автомата∇∇∇.

Список новых диаграмм и их названий, принятых в этой книге, приведен ниже.

Диаграмма внутренней структуры (Composite Structure diagram)

Диаграмма пакетов (Package diagram)

Диаграммаавтомата (State machine diagram)

Диаграммакоммуникации (Communication diagram)

Обзорнаядиаграммавзаимодействия (Interaction Overview diagram)

Диаграмма синхронизации (Timing diagram)

(http://book.uml3.ru/sec_1_4)

7. Диаграммы use case (вариантов использования)

(Туривный С.)

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

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

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