Основные диаграммы языка UML. Инструменты для рисования UML-диаграмм Диаграмма в uml является графическим

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

Коммерческие продукты

Microsoft Visio

Тип: коммерческое ПО

Популярный программный продукт от компании Microsoft, который позволяет рисовать богатые диаграммы, в том числе UML:

Начиная с 2010 версии появилась возможность публиковать диаграммы в вебе (SharePoint + Visio Services):

Visio Viewer - бесплатная программа, которая позволяет просматривать созданные ранее Visio диаграммы. Загрузить можно по %D1%81%D1%81%D1%8B%D0%BB%D0%BA%D0%B5%20.

%0A

Microsoft%20Visual%20Studio%202010

%0A

%D0%A2%D0%B8%D0%BF:%20%D0%BA%D0%BE%D0%BC%D0%BC%D0%B5%D1%80%D1%87%D0%B5%D1%81%D0%BA%D0%BE%D0%B5%20%D0%9F%D0%9E%20(%D0%B5%D1%81%D1%82%D1%8C%20%D0%B1%D0%B5%D1%81%D0%BF%D0%BB%D0%B0%D1%82%D0%BD%D0%B0%D1%8F%20Express%20%D0%B2%D0%B5%D1%80%D1%81%D0%B8%D1%8F).

%0A

%D0%92%20%D0%BF%D0%BE%D1%81%D0%BB%D0%B5%D0%B4%D0%BD%D0%B5%D0%B9%20%D0%B2%D0%B5%D1%80%D1%81%D0%B8%D0%B8%20Microsoft%20Visual%20Studio%202010%20%D0%BF%D0%BE%D1%8F%D0%B2%D0%B8%D0%BB%D1%81%D1%8F%20%D0%BD%D0%BE%D0%B2%D1%8B%D0%B9%20%D1%82%D0%B8%D0%BF%20%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B0%20-%20Modelling,%20%D0%BA%D0%BE%D1%82%D0%BE%D1%80%D1%8B%D0%B9%20%D0%BF%D0%BE%D0%B7%D0%B2%D0%BE%D0%BB%D1%8F%D0%B5%D1%82%20%D1%80%D0%B8%D1%81%D0%BE%D0%B2%D0%B0%D1%82%D1%8C%20%D1%80%D0%B0%D0%B7%D0%BB%D0%B8%D1%87%D0%BD%D1%8B%D0%B5%20UML%20%D0%B4%D0%B8%D0%B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B0%20%D0%B8%20%D0%BF%D1%80%D0%BE%D0%B2%D0%B5%D1%80%D1%8F%D1%82%D1%8C%20%D0%BD%D0%B0%D0%BF%D0%B8%D1%81%D0%B0%D0%BD%D0%BD%D1%8B%D0%B5%20%D1%80%D0%B5%D1%88%D0%B5%D0%BD%D0%B8%D1%8F%20%D0%BD%D0%B0%20%D1%81%D0%BE%D0%BE%D1%82%D0%B2%D0%B5%D1%82%D1%81%D1%82%D0%B2%D0%B8%D0%B5%20%D1%81%20%D0%BD%D0%B5%D0%BE%D0%B1%D1%85%D0%BE%D0%B4%D0%B8%D0%BC%D0%BE%20%D0%B0%D1%80%D1%85%D0%B8%D1%82%D0%B5%D0%BA%D1%82%D1%83%D1%80%D0%BE%D0%B9.

%0A

%D0%9F%D0%BE%D0%B7%D0%B2%D0%BE%D0%BB%D1%8F%D0%B5%D1%82%20%D0%B3%D0%B5%D0%BD%D0%B5%D1%80%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D1%82%D1%8C%20Sequence%20Diagram%20%D0%BD%D0%B0%20%D0%BE%D1%81%D0%BD%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B8%20%D0%BA%D0%BE%D0%B4%D0%B0,%20%D0%B2%D0%B8%D0%B7%D1%83%D0%B0%D0%BB%D0%B8%D0%B7%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D1%82%D1%8C%20%D1%81%D0%B2%D1%8F%D0%B7%D0%B8%20%D0%B2%20%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B5%20%D0%BC%D0%B5%D0%B6%D0%B4%D1%83%20%D0%BA%D0%BE%D0%BC%D0%BF%D0%BE%D0%BD%D0%B5%D0%BD%D1%82%D0%B0%D0%BC%D0%B8,%20%D1%81%D0%B1%D0%BE%D1%80%D0%BA%D0%B0%D0%BC%D0%B8%20%D0%B8%20%D1%81%D1%81%D1%8B%D0%BB%D0%BA%D0%B0%D0%BC%D0%B8%20%D0%B8%20%D1%82.%D0%B4.

%0A

%D0%9F%D1%80%D0%B8%D0%BC%D0%B5%D1%80%20Use%20case%20%D0%B4%D0%B8%D0%B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D1%8B,%20%D0%BD%D0%B0%D1%80%D0%B8%D1%81%D0%BE%D0%B2%D0%B0%D0%BD%D0%BD%D0%BE%D0%B9%20%D0%B2%20Visual%20Studio%202010:

%0A%0A

%D0%9A%D1%80%D0%BE%D0%BC%D0%B5%20%D1%82%D0%BE%D0%B3%D0%BE,%20%D0%B4%D0%BE%D1%81%D1%82%D1%83%D0%BF%D0%B5%D0%BD%20Visualization%20and%20Modeling%20Feature%20Pack%20(%D0%B4%D0%BB%D1%8F%20%D0%BF%D0%BE%D0%B4%D0%BF%D0%B8%D1%81%D1%87%D0%B8%D0%BA%D0%BE%D0%B2%20MSDN),%20%D0%BA%D0%BE%D1%82%D0%BE%D1%80%D1%8B%D0%B9%20%D0%BF%D0%BE%D0%B7%D0%B2%D0%BE%D0%BB%D1%8F%D0%B5%D1%82:

%0A

• %D0%B3%D0%B5%D0%BD%D0%B5%D1%80%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D1%82%D1%8C%20%D0%BA%D0%BE%D0%B4%20%D0%BD%D0%B0%20%D0%B1%D0%B0%D0%B7%D0%B5%20UML%20%D0%B4%D0%B8%D0%B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%20%D0%BA%D0%BB%D0%B0%D1%81%D1%81%D0%BE%D0%B2
%0A
• %D1%81%D0%BE%D0%B7%D0%B4%D0%B0%D0%B2%D0%B0%D1%82%D1%8C%20UML%20%D0%B4%D0%B8%D0%B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D1%8B%20%D0%B8%D0%B7%20%D0%BA%D0%BE%D0%B4%D0%B0
%0A
• %D0%B8%D0%BC%D0%BF%D0%BE%D1%80%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D1%82%D1%8C%20UML%20%D0%B4%D0%B8%D0%B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D1%8B%20%D0%BA%D0%BB%D0%B0%D1%81%D1%81%D0%BE%D0%B2,%20%D0%B4%D0%B8%D0%B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D1%8B%20%D0%BF%D0%BE%D1%81%D0%BB%D0%B5%D0%B4%D0%BE%D0%B2%D0%B0%D1%82%D0%B5%D0%BB%D1%8C%D0%BD%D0%BE%D1%81%D1%82%D0%B5%D0%B9,%20%D0%B4%D0%B8%D0%B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D1%8B%20%D0%B2%D0%B0%D1%80%D0%B8%D0%B0%D0%BD%D1%82%D0%BE%D0%B2%20%D0%B8%D1%81%D0%BF%D0%BE%D0%BB%D1%8C%D0%B7%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F%20%D1%81%20XMI%202.1
%0A
• %D1%81%D0%BE%D0%B7%D0%B4%D0%B0%D0%B2%D0%B0%D1%82%D1%8C%20%D0%B4%D0%B8%D0%B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D1%8B%20%D0%B7%D0%B0%D0%B2%D0%B8%D1%81%D0%B8%D0%BC%D0%BE%D1%81%D1%82%D0%B5%D0%B9%20%D0%B4%D0%BB%D1%8F%20ASP.NET,%20C%20%D0%B8%20C++%20%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%BE%D0%B2
%0A
• %D1%81%D0%BE%D0%B7%D0%B4%D0%B0%D0%B2%D0%B0%D1%82%D1%8C%20%D0%B8%20%D0%BF%D1%80%D0%BE%D0%B2%D0%B5%D1%80%D1%8F%D1%82%D1%8C%20layer%20diagrams%20%D0%B4%D0%BB%D1%8F%20C%20%D0%B8%20C++%20%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%BE%D0%B2
%0A
• %D0%BF%D0%B8%D1%81%D0%B0%D1%82%D1%8C%20%D1%81%D0%BE%D0%B1%D1%81%D1%82%D0%B2%D0%B5%D0%BD%D0%BD%D1%8B%D0%B5%20%D0%BF%D1%80%D0%BE%D0%B2%D0%B5%D1%80%D0%BA%D0%B8%20%D0%B4%D0%BB%D1%8F%20layer%20diagrams
%0A

%D0%A1%D0%BA%D0%B0%D1%87%D0%B0%D1%82%D1%8C%20Visualization%20and%20Modeling%20Feature%20Pack%20%D0%BC%D0%BE%D0%B6%D0%BD%D0%BE%20%D0%BF%D0%BE%20%D1%81%D1%81%D1%8B%D0%BB%D0%BA%D0%B5:%20http://msdn.microsoft.com/ru-ru/vstudio/ff655021%28en-us%29.aspx .

IBM Rational Rose

Возможности:

• Use case diagram (диаграммы прецедентов);
• Deployment diagram (диаграммы топологии);
• Statechart diagram (диаграммы состояний);
• Activity diagram (диаграммы активности);
• Interaction diagram (диаграммы взаимодействия);
• Sequence diagram (диаграммы последовательностей действий);
• Collaboration diagram (диаграммы сотрудничества);
• Class diagram (диаграммы классов);
• Component diagram (диаграммы компонент).

Скриншоты:

Open source программы

StarUML

Возможности:

• поддержка UML 2.0
• MDA (Model Driven Architecture)
• Plug-in Architecture (писать можно на COM совместимых языках: C++, Delphi, C#, VB, ...)

StarUML написана, в основном, на Delphi, но дописывать компоненты можно и на других языках, например C/C++, Java, Visual Basic, Delphi, JScript, VBScript, C#, VB.NET. Ниже показано несколько скриншотов.

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

Use case диаграмма:

ArgoUML

Поддерживаемые диаграммы:

• Class
• State
• Use case
• Activity
• Collaboration
• Deployment
• Sequence

Возможности:

• Поддержка девяти UML 1.4 диаграмм
• Платформонезависимая (Java 5+)
• Стандартная метамодель UML 1.4
• Поддержка XMI
• Экспорт в GIF, PNG, PS, EPS, PGML и SVG
• Языки: EN, EN-GB, DE, ES, IT, RU, FR, NB, PT, ZH
• Поддержка OCL
• Forward, Reverse Engineering

Скриншот:

Я думаю, каждый слышал в детстве такую поговорку как "Семь раз отмерь, один раз отрежь ". В программировании так же. Лучше всегда обдумать реализацию до того, как вы потратите время на её исполнение. Часто приходится при реализации создавать классы, придумывать их взаимодействие. И часто визуальное представление этого может помочь решить задачу наиболее правильным образом. В этом нам и помогает UML .

Что такое 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 действительно используется. И выходит, что знание и понимание его применения довольно полезный навык.

Применение

Разберём, как с этим самым UML можно работать из IDE. В качестве IDE возьмём IntelliJ Idea . Если использовать IntelliJ Idea Ultimate , то у нас "из коробки" будет установлен плагин "UML Support ". Он позволяет автоматически генерировать красивые диаграммы классов. Например, через Ctrl+N или пункт меню "Navigate" -> "Class" перейдём в класс ArrayList . Теперь, через контекстное меню по имени класса выберем "Diagram" -> "Show diagram popup". В результате мы получим красивую диаграмму:

Но что, если хочется самому нарисовать, да ещё и нет 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 - Диаграмма классов ". Кроме того, в рисовании такой схемы нет ничего сверхъестественного, и при работе над своими задачами её можно быстро рисовать от руки. Это позволит развить навыки продумывания архитектуры приложения и поможет выявить недостатки структуры классов на раннем этапе, а не когда вы уже потратите день на реализацию неправильной модели. Мне кажется, это неплохая причина для того, чтобы попробовать?)

Автоматизация

Есть различные способы автоматической генерации PlantUML диаграмм. Например, в Idea есть плагин SketchIT , но рисует он их не совсем правильно. Скажем, неправильно рисуется имплементация интерфейсов (отображается как наследование). Также в интернете есть примеры того, как это встроить в жизненный цикл сборки вашего проекта. Допустим, для Maven есть пример использования uml-java-docklet . Для того, чтобы показать как это, воспользуемся Maven Archetype для быстрого создания Maven проекта. Выполним команду: mvn archetype:generate На вопросе выбора фильтра (Choose a number or apply filter ) оставляем default, просто нажав Enter. Это всегда будет "maven-archetype-quickstart ". Выбираем самую последнюю версию. Далее отвечаем на вопросы и завершаем создание проекта:

Так как 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 позволяет визуализировать структуру вашего приложения. Кроме того, UML не ограничивается только этим. При помощи UML можно описывать различные процессы внутри вашей компании или описывать бизнес-процесс, в рамках которого работает функция, которую вы пишите. На сколько UML полезен лично для вас - решать вам, но найти время и ознакомиться более подробным будет в любом случае полезно. #Viacheslav English version of this post: UML diagram Java on CodeGym

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

План действий

В разделе «Описание» изучите основной набор символов диаграммы состояний, необходимый для того, чтобы уметь читать диаграммы.

После ознакомления с другими разделами («Пример», «Применение») вы можете попробовать свои силы в самостоятельном составлении диаграмм состояний.

Замечания (описание)

Здесь представлен основной набор символов диаграммы состояний , необходимый для того, чтобы суметь прочитать диаграмму. После ознакомления с другими разделами («Пример», «Применение») вы сможете составлять диаграммы состояний самостоятельно!

Термин	Изображение	Описание
Начальное псевдосостояние (initial pseudostate)		Начальное состояние системы
Переход		Переход (transition) означает перемещение из одного состояния в другое.
Состояние		Обозначает выполняемые системой действия (могут включать возможные варианты), приводящие к наблюдаемым актёрами результатам.
Состояние активности (activity state)		Сложный шаг в прецеденте можно представить другим прецедентом. В терминах языка UML мы говорим, что первый прецедент включает (includes) второй.
Конечное состояние		Позволяет обозначить границы систем или подсистем.
Внутренние активности (internal activities)		Случай когда состояния могут реагировать на события без совершения перехода, и в этом случае событие, защита и активность размещаются внутри прямоугольника состояния.
Входная активность		Входная активность выполняется всякий раз, когда вы входите в состояние
Выходная активность		Выходная активность – выполняется всякий раз, когда вы покидаете состояние.
Суперсостояние		Часто бывает, что несколько состояний имеют общие переходы и внутренние активности. В таких случаях можно их превратить в подсостояния (substates), а общее поведение перенести в суперсостояние (superstate).
Параллельные состояния		Состояния могут быть разбиты на несколько параллельных состояний, запускаемых одновременно.

Как применять технику креативности

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

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

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

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

Как научиться

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

Как и многие другие языки он использует для описания набор знаков. Смысл этих знаков вы найдете в таблице в разделе «Замечания (описание)». Каждый знак имеет свое наименование (термин) и написание. Также каждый термин снабжен кратким пояснением, чтобы быстро уяснить его основную суть.

Далее мы бы рекомендовали перейти в раздел «Примеры» диаграмм состояний , чтобы попробовать свои силы в чтении разных диаграмм. Затем стоит изучить раздел «Применение», так как, хотя и количество типов диаграмм в UML невелико, максимум преимуществ от их использования вы сможете получить только если будете применять соответствующие диаграммы по назначению.

Пример использования

Диаграмма состояний (state machine diagrams) – это известная технология описания поведения системы. В том или ином виде диаграмма состояний существует с 1960 года, и на заре объектно-ориентированного программирования они применялись для представления поведения системы. В объектно-ориентированных подходах вы рисуете диаграмму состояний единственного класса, чтобы показать поведение одного объекта в течение его жизни.

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

На рис. 10.1 показана диаграмма состояний класса контроллера, который управляет моей необычной системой безопасности. Диаграмма состояния начинается с состояния создаваемого объекта контроллера: состояния Wait (Ожидание) . На диаграмме это обозначено с помощью начального псевдосостояния (initial pseudostate) , которое не является состоянием, но имеет стрелку, указывающую на начальное состояние.
На диаграмме показано, что контроллер может находиться в одном из трех состояний: Wait (Ожидание), Lock (Замок) и Open (Открыт) . На диаграмме также представлены правила, согласно которым контроллер переходит из одного состояния в другое. Эти правила представлены в виде переходов – линий, связывающих состояния.

Переход (transition) означает перемещение из одного состояния в другое. Каждый переход имеет свою метку, которая состоит из трех частей:
триггер-идентификатор [защита]/активность (trigger-signature /activity) . Все они не обязательны. Как правило, триггер-идентификатор – это единственное событие, которое может вызвать изменение состояния.

Защита, если она указана, представляет собой логическое условие, которое должно быть выполнено, чтобы переход имел место. Активность – это некоторое поведение системы во время перехода. Это может быть любое поведенческое выражение. Полная форма триггера-идентификатора может включать несколько событий и параметров. Переход из состояния Wait (рис. 10.1) в другое состояние можно прочесть как «В состоянии Wait , если свеча удалена, вы видите замок и переходите в состояние Lock ».

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

Когда в определенном состоянии происходит событие, то из этого состояния можно совершить только один переход, например в состоянии Lock (рис. 10.1) защиты должны быть взаимно исключающими. Если событие происходит, а разрешенных переходов нет – например закрытие сейфа в состоянии Wait или удаление свечи при открытой двери, – событие игнорируется.

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

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

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

Внутренние активности в диаграмме состояний

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

На рис. 10.2 представлено состояние с внутренними активностями символов и событиями системы помощи, которые вы можете наблюдать в текстовых полях редактора UI . Внутренняя активность подобна самопереходу (self-transition) – переходу, который возвращает в то же самое состояние. Синтаксис внутренних активностей построен по той же логической схеме события, защиты и процедуры.

На рис. 10.2 показаны также специальные активности: входная и выходная активности . Входная активность выполняется всякий раз, когда вы входите в состояние; выходная активность – всякий раз, когда вы покидаете состояние. Однако внутренние активности не инициируют входную и выходную активности ; в этом состоит различие между внутренними активностями и самопереходами .

Состояния активности в диаграмме состояний

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

Состояние Searching (Поиск) на рис. 10.3 является таким состоянием активности (activity state) : ведущаяся активность обозначается символом do/ ; отсюда термин do-activity (проявлять активность) . После того как поиск завершен, выполняются переходы без активности, например показ нового оборудования (Display New Hardware) . Если в процессе активности происходит событие отмены (cancel ), то do-активность просто прерывается и мы возвращаемся в состояние Update Hardware Window (Обновление окна оборудования).

И do-активности, и обычные активности представляют проявление некоторого поведения. Решающее различие между ними заключается в том, что обычные активности происходят «мгновенно» и не могут быть прерваны обычными событиями, тогда как do-активности могут выполняться в течение некоторого ограниченного времени и могут прерываться, как показано на рис. 10.3. Мгновенность для разных систем трактуется по-разному; для систем реального времени это может занимать несколько машинных инструкций, а для настольного программного обеспечения может составить несколько секунд.

В UML 1 обычные активности обозначались термином action (действие), а термин activity (активность) применялся только для do-активностей .

Суперсостояния

Часто бывает, что несколько состояний имеют общие переходы и внутренние активности. В таких случаях можно их превратить в подсостояния (substates), а общее поведение перенести в суперсостояние (superstate), как показано на рис. 10.4. Без суперсостояния пришлось бы рисовать переход cancel (отмена) для всех трех состояний внутри состояния Enter Connection Details (Ввод подробностей соединения) .

Параллельные состояния

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

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

Рис. 10.5 включает также состояние предыстории (history pseudostate). Это означает, что когда включены часы, опция радио/CD переходит в состояние, в котором находились часы, когда они были выключены. Стрелка, выходящая из предыстории, показывает, какое состояние существовало изначально, когда отсутствовала предыстория.

Реализация диаграмм состояний

Диаграмму состояний можно реализовать тремя основными способами: с помощью вложенного оператора switch, паттерна State и таблицы состояний. Самый прямой подход в работе с диаграммами состояний – это вложенный оператор switch, такой как на рис. 10.6.

Хотя этот способ и прямой, но очень длинный даже для этого простого случая. Кроме того, при данном подходе очень легко потерять контроль, поэтому не рекомендуем применять его даже в элементарных ситуациях.
Паттерн «Состояние» (State pattern) представляет иерархию классов состояний для обработки поведения состояний. Каждое состояние на диаграмме состояний имеет свой подкласс состояния. Контроллер имеет методы для каждого события, которые просто перенаправляют к классу состояния. Диаграмма состояний, показанная на рис. 10.1, могла бы быть реализована с помощью классов, представленных на рис. 10.7.

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

Так, диаграмма на рис. 10.1 может быть представлена в виде табл. 10.1.
Затем мы строим интерпретатор, который использует таблицу состояний во время выполнения программы, или генератор кода, который порождает классы на основе этой таблицы.

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

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

Подписывайтесь на новости сайта, форму подписки вы можете найти в правой колонке сайта.

Если вы хотите научиться работать на фрилансе профессионально, приглашаем на курс « ».

        Унифицированный язык моделирования (Unified Modeling Language - UML) это язык для специфицирования, визуализации, конструирования и документирования программных систем, а так же бизнес моделей и прочих не программных систем. UML представляет собой объединение инженерных приемов, которые ранее успешно использовались при моделировании больших и сложных систем

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

        UML предоставляет выразительные средства для создания визуальных моделей, которые:

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

        Унифицированный Язык Моделирования (UML):

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

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

Диаграммы UML

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

• Use case diagram (диаграммы прецедентов);
• Deployment diagram (диаграммы топологии);
• Statechart diagram (диаграммы состояний);
• Interaction diagram (диаграммы взаимодействия); Activity diagram (диаграммы активности);
• Sequence diagram (диаграммы последовательностей действий);
• Collaboration diagram (диаграммы сотрудничества);
• Class diagram (диаграммы классов);
• Component diagram (диаграммы компонент);
• Behavior diagrams (диаграммы поведения);
• Activity diagram (диаграмма деятельности);
• Implementation diagrams(диаграммы реализации);

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

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

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

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

        При графическом изображении диаграмм рекомендуется придерживаться следующих правил:

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

Сущности в UML

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

       Структурные сущности - это имена существительные в моделях на языке UML. Как правило, они представляют статические части модели, соответствующие концептуальным или физическим элементам системы. Примерами структурных сущностей являются "класс", "интерфейс", "кооперация", "прецедент", "компонент", "узел", "актер".

        Поведенческие сущности являются динамическими составляющими модели UML. Это глаголы, которые описывают поведение модели во времени и в пространстве. Существует два основных типа поведенческих сущностей:

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

        Группирующие сущности являются организующими частями модели UML. Это блоки, на которые можно разложить модель. Такая первичная сущность имеется в единственном экземпляре - это пакет.

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

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

Отношения в UML

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

        Зависимость (dependency) - это семантическое отношение между двумя сущностями, при котором изменение одной из них, независимой, может повлиять на семантику другой, зависимой.

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

        Обобщение (generalization) - это отношение, при котором объект специализированного элемента (потомок) может быть подставлен вместо объекта обобщенного элемента (предка). При этом, в соответствии с принципами объектно-ориентированного программирования, потомок (child) наследует структуру и поведение своего предка (parent).

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

• между интерфейсами и реализующими их классами или компонентами;
• между прецедентами и реализующими их кооперациями.

Общие механизмы UML

        Для точного описания системы в UML используются, так называемые, общие механизмы:

• спецификации (specifications);
• дополнения (adornments);
• деления (common divisions);
• расширения (extensibility mechanisms).

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

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

        При моделировании объектно-ориентированных систем существует определенное деление представляемых сущностей.

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

        Во-вторых, существует деление на интерфейс и его реализацию. Интерфейс декларирует обязательства, а реализация представляет конкретное воплощение этих обязательств и обеспечивает точное следование объявленной семантике. В связи с этим, почти все конструкции UML характеризуются двойственностью "интерфейс/реализация". Например, прецеденты реализуются кооперациями, а операции - методами.

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

        Механизмы расширения UML включают:

• стереотипы (stereotype) - расширяют словарь UML, позволяя на основе существующих элементов языка создавать новые, ориентированные для решения конкретной проблемы;
• помеченные значения (tagged value) - расширяют свойства основных конструкций UML, позволяя включать дополнительную информацию в спецификацию элемента;
• ограничения (constraints) - расширяют семантику конструкций UML, позволяя создавать новые и отменять существующие правила.

        Совместно эти три механизма расширения языка позволяют модифицировать его в соответствии с потребностями проекта или особенностями технологии разработки.

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

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

Рисунок - 1. Диаграмма вариантов использования

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

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

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

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

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

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

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

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

        Центральное место в объектно-ориентированном программировании занимает разработка логической модели системы в виде диаграммы классов. Диаграмма классов (class diagram) служит для представления статической структуры модели системы в терминологии классов объектно-ориентированного программирования. Диаграмма классов может отражать, в частности, различные взаимосвязи между отдельными сущностями предметной области, такими как объекты и подсистемы, а также описывать их внутреннюю структуру и типы отношений.

Рисунок - 2. Диаграмма классов

        Значки диаграммы позволяют отображать сложную иерархию систем, взаимосвязи классов (Classes) и интерфейсов (Interfaces). Данный тип диаграмм противоположен по содержанию диаграмме Collaboration, на котором отображаются объекты системы. Rational Rose позволяет создавать классы при помощи данного типа диаграмм в различных нотациях. похожего на облако. Таким образом класс - это лишь шаблон, по которому в дальнейшем будет создан конкретный объект.

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

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

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

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

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

Рисунок - 2. Диаграмма состояний

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

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

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

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

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

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

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

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

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

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

        Фактически данный тип диаграмм может использоваться и для отражения состояний моделируемого объекта, однако, основное назначение Activity diagram в том, чтобы отражать бизнес-процессы объекта. Этот тип диаграмм позволяет показать не только последовательность процессов, но и ветвление и даже синхронизацию процессов.

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

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

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

        В контексте языка UML деятельность (activity) представляет собой совокупность отдельных вычислений, выполняемых автоматом, приводящих к некоторому результату или действию (action). На диаграмме деятельности отображается логика и последовательность переходов от одной деятельности к другой, а внимание аналитика фокусируется на результатах. Результат деятельности может привести к изменению состояния системы или возвращению некоторого значения.

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

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

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

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

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

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

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

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

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

Рисунок - 3. Диаграмма кооперации

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

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

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

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

        Кооперация может быть представлена на двух уровнях:

• уровне спецификации - показывает роли классификаторов и роли ассоциаций в рассматриваемом взаимодействии;
• уровне примеров - указывает экземпляры и связи, образующие отдельные роли в кооперации.

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

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

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

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

        Этот тип диаграмм предназначен для распределения классов и объектов по компонентам при физическом проектировании системы. Часто данный тип диаграмм называют диаграммами модулей.

Рисунок - 4. Диаграмма компонентов

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

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

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

• визуализации общей структуры исходного кода программной системы;
• спецификации исполняемого варианта программной системы;
• обеспечения многократного использования отдельных фрагментов программного кода;
• представления концептуальной и физической схем баз данных.

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

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

Диаграмма развертывания (deployment diagram)

        Этот вид диаграмм предназначен для анализа аппаратной части системы, то есть "железа", а не программ. В прямом переводе с английского Deployment означает "развертывание", но термин "топология" точнее отражает сущность этого типа диаграмм.

Рисунок - 5. Диаграмма развертывания

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

        Для представления общей конфигурации и топологии распределенной программной системы в UML предназначены диаграммы развертывания.

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

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

        При разработке диаграммы развертывания преследуют следующие цели:

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

        Диаграммы развертывания разрабатываются совместно системными аналитиками, сетевыми инженерами и системотехниками.

Особенности рабочего интерфейса Rational Rose

        В CASE-средстве Rational Rose реализованы общепринятые стандарты на рабочий интерфейс программы, подобно известным средам визуального программирования. После установки Rational Rose на компьютер пользователя, что практически не вызывает трудностей даже у начинающих, запуск этой программы в среде MS Windows 95/98 приводит к появлению на экране рабочего интерфейса (рис. 6).

Рисунок - 6. Общий вид рабочего интерфейса программы Rational Rose

        Рабочий интерфейс Rational Rose состоит из различных элементов, основными из которых являются:

• Главное меню программы
• Окно диаграммы
• Окно документации
• Окно браузера
• Окно журнала

Рассмотрим кратко назначение и основные функции каждого из этих элементов.

Главное меню программы

Главное меню программы выполнено в общепринятом стандарте и имеет следующий вид (рис. 7).

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

Рисунок - 7. Внешний вид главного меню программы

Стандартная панель инструментов

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

Рисунок - 8. Внешний вид стандартной панели инструментов

Пользователь может настроить внешний вид этой панели по своему усмотрению. Для этого необходимо выбрать пункт меню Tools -> Options (Инструменты -> Параметры) и открыть вкладку Toolbars (Панели инструментов). Этим способом можно показать или скрыть различные кнопки инструментов, а также изменить их размер.

Окно браузера

Окно браузера по умолчанию располагается в левой части рабочего интерфейса под стандартной панелью инструментов (рис. 9).

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

Рисунок - 9. Внешний вид браузера

Специальная панель инструментов

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

Рисунок - 10. Внешний вид специальной панели инструментов для диаграммы классов

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

Окно диаграммы

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

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

Рисунок - 11. Внешний вид окна диаграмм с различными видами представлений модели

Окно документации

Окно документации по умолчанию может не присутствовать на экране. В этом случае оно может быть активизировано через пункт меню View -> Documentation (Вид->Документация), после чего появится ниже браузера (рис. 12).

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

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

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

Рисунок - 12. Внешний вид окна документации

Окно журнала

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

Окно журнала всегда присутствует на рабочем интерфейсе в области окна диаграммы (рис. 13). Однако оно может быть закрыто другими окнами с диаграммами или быть свернутым. Активизировать окно журнала можно через меню Window->Log (Окно->Журнал). В этом случае оно изображается поверх других окон в правой области рабочего интерфейса. Полностью удалить это окно нельзя, его можно только минимизировать.

Рисунок - 13. Внешний вид окна журнала

Заключение

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

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

В этой статье рассказывается о новой эпохе разработки ПО, о ее влиянии на новые требования, выдвигаемые к языку UML, и об оптимальных методах их выполнения.
  7. "Моделирование данных в Rational Rose" Сергей Трофимов Описывается моделирование физического представления данных с использованием Rational Rose
  8. Язык UML . Общее представление о языке UML: структуры, графические элементы и диаграммы языка.
  9. Практический UML . Этот документ является переводом документа "Practical UML. A Hands-On Introduction for Developers". Практическое введение для разработчиков
  10. "Стандартный язык объектно-ориентированного моделирования UML" Вендров Александр Михайлович . История создания UML
  11. UML – унифицированный язык моделирования . Данный материал содержит начальные сведения о методах описания программных систем и нотациях, используемых в UML
  12. Язык UML. Руководство пользователя. Авторы: Грейди Буч, Джеймс Рамбо, Айвар Джекобсон
  13. "UML диаграммы в Rational Rose" Сергей Трофимов
  14. "Анализ и проектирование. Визуальное моделирование (UML) Rational Rose" Константин Домолего
  15. Библиотека Геннадия Верникова. Полные описания стандартов проектирования и моделирования.
  16. "Пример описания предметной области с использованием UML при разработке программных систем" Е.Б. Золотухина, Р.В. Алфимов. В статье на конкретном примере демонстрируется возможный подход к моделированию предметной области, основанный на применении Унифицированного Языка Моделирования (Unified Modeling Language) (UML)

       

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

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

В заметке используется материалы из книжек: Иванов Д. Ю., Новиков Ф. А. Унифицированный язык моделирования UML и Леоненков. Самоучитель по UML .

Для начала определимся с редактором. Под Linux я перепробовал разные UML-редакторы, больше всего мне понравился UMLet , хоть он и написан на Java но шевелится весьма проворно и большинство заготовок сущностей в нем есть. Еще есть ArgoUML кроссплатформенный UML-редактор, написан тоже на Java, функционально-богат но подтормаживает больше.

Я остановился на UMLet , установим его под Arch Linux и Ubuntu :

# под Arch Linux yaourt -S umlet # под Ubuntu sudo apt-get install umlet

В UML все сущности можно разбить на такие типы:

• структурные;
• поведенческие;
• группирующие;
• аннотационные;

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

Зависимость (dependency) - указывает на то, что изменение независимой сущности каким-то образом влияет на зависимую сущность. Графически отношение зависимости изображается в виде пунктирной линии со стрелкой, направленной от зависимой сущности к независимой.

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

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

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

В UML 2 определено 13 типов диаграмм. По стандартам каждая диаграмма должна иметь рамку с прямоугольником (правый нижний угол скошенный) в левом верхнем углу, в котором указывается идентификатор диаграммы (тег) и название.

Диаграммы для изображения структуры системы :

• Диаграмма компонентов (component diagram, тег component );
• Диаграмма размещения (deployment diagram, тег deployment );
• Диаграмма классов (class diagram, тег class );
• Диаграмма объектов (object diagram, тег object );
• Диаграмма структуры внутренней (composite structure diagram, тег class );

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

• Диаграмма синхронизации (interaction diagram, тег timing );
• Диаграмма деятельности (activity diagram, тег activity );
• Диаграмма последовательности (sequence diagram, тег sd );
• Диаграмма коммуникации (communication diagram, тег comm );
• Диаграмма автомата (state machine diagram, тег state machine );
• Обзорная диаграмма взаимодействия (interaction overview diagram, тег interaction );

Особняком стоят диаграммы:

• Диаграмма использования(use case diagram, тег use case);
• Диаграмма пакетов (package diagram, тег package );

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

Диаграмма использования (use case diagram) - это наиболее общее представление функционального назначения системы.

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

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

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

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

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

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

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

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

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

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

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

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

Диаграмма классов (class diagram) - основной способ описания статической структуры системы.

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

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

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

Над стрелкой могут находится специальные ключевые слова (стереотипы):

• "access" - служит для обозначения доступности открытых атрибутов и операций класса-источника для классов-клиентов;
• "bind" - класс-клиент может использовать некоторый шаблон для своей последующей параметризации;
• "derive" - атрибуты класса-клиента могут быть вычислены по атрибутам класса-источника;
• "import" - открытые атрибуты и операции класса-источника становятся частью класса-клиента, как если бы они были объявлены непосредственно в нем;
• "refine" - указывает, что класс-клиент служит уточнением класса-источника в силу причин исторического характера, когда появляется дополнительная информация в ходе работы над проектом.

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

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

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

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

Диаграмма автомата

Диаграмма автомата (state machine diagram) или диаграмма состояний в UML 1 (state chart diagram) - это один из способов детального описания поведения в UML. В сущности, диаграммы автомата, как это следует из названия, представляют собой граф состояний и переходов конечного автомата нагруженный множеством дополнительных деталей и подробностей.

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

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

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

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

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

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

Диаграмма деятельности (activity diagram) - еще один способ описания поведения, который визуально напоминает старую добрую блок-схему алгоритма. Используется для моделирования процесса выполнения операций.

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

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

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

Диаграмма последовательности (sequence diagram) - это способ описания поведения системы "на примерах".

Фактически, диаграмма последовательности - это запись протокола конкретного сеанса работы системы (или фрагмента такого протокола). В объектно-ориентированном программировании самым существенным во время выполнения является пересылка сообщений между взаимодействующими объектами. Именно последовательность посылок сообщений отображается на данной диаграмме, отсюда и название.

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

Возможные виды сообщений (изображение взято у larin.in):

Диаграмма коммуникации

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

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

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

Диаграмма компонентов (component diagram) - показывает взаимосвязи между модулями (логическими или физическими), из которых состоит моделируемая система.

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

• реализации между компонентами и интерфейсами (компонент реализует интерфейс);
• зависимости между компонентами и интерфейсами (компонент использует интерфейс);

Диаграмма размещения

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

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

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

Диаграмма объектов (object diagram) - является экземпляром диаграммы классов.

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

Диаграмма внутренней структуры (composite structure diagram) используется для более подробного представления структурных классификаторов, прежде всего классов и компонентов.

Структурный классификатор изображается в виде прямоугольника, в верхней части которого находится имя классификатора. Внутри находятся части (parts). Частей может быть несколько. Части могут взаимодействовать друг с другом. Это обозначается с помощью соединителей (connectors) различных видов. Место на внешней границе части, к которому присоединяется соединитель, называется портом (port). Порты располагаются также на внешней границе структурного классификатора.

Обзорная диаграмма взаимодействия (interaction overview diagram) является разновидностью диаграммы деятельности с расширенным синтаксисом: в качестве элементов обзорной диаграммы взаимодействия могут выступать ссылки на взаимодействия (interaction use), определяемые диаграммами последовательности.

Диаграмма синхронизации

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

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

Диаграмма пакетов (package diagram) - единственное средство, позволяющее управлять сложностью самой модели.

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

Модель сущность-связь (ER-модель)

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

Модель сущность-связь (ER-модель) - модель данных, позволяющая описывать концептуальные схемы предметной области. ER-модель используется при высокоуровневом (концептуальном) проектировании баз данных. С её помощью можно выделить ключевые сущности и обозначить связи, которые могут устанавливаться между этими сущностями. wikipedia

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

Основные понятия:

Сущность (entity) - это объект, который может быть идентифицирован неким способом, отличающим его от других объектов, например, КЛИЕНТ 777 . Сущность фактически представляет из себя множество атрибутов.

Набор сущностей (entity set) - множество сущностей одного типа (обладающих одинаковыми свойствами).

Связь (relationship) - это ассоциация, установленная между несколькими сущностями.

Домен (domain) - множество значений (область определения) атрибута.

Существует три типа бинарных связей:

• один к одному - одиночный экземпляр сущности одного класса связан с одиночным экземпляром сущности другого класса, напимер, НАЧАЛЬНИК - ОТДЕЛ;
• 1 к N или один ко многим - одиночный экземпляр сущности одного класса связан со многими экземплярами сущности другого класса, например, ОТДЕЛ - СОТРУДНИК;
• N к M или многие ко многим - многие экземпляры сущности одного класса связаны со многими экземплярами сущности другого класса, например, СОТРУДНИК - ПРОЕКТ;
Словарь основных понятий по UML

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

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

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

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

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

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

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

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

Поведенческие сущности предназначены для описания поведения. Основных поведенческих сущностей всего две: состояние и действие.

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

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

Автомат является пакетом, в котором определено множество понятий, необходимых для представления поведения моделируемой сущности в виде дискретного пространства с конечным числом состояний и переходов.

Классификатор (classifier) - это дескриптор множества однотипных объектов.

Дополнительное чтиво

• Фаулер М. UML. Основы, 3-е издание
• Буч Г., Рамбо Д., Якобсон И. Язык UML. Руководство пользователя