Как делать юмл диаграмму юзед кейс

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

Диаграмма вариантов использования — один из доступных видов диаграмм, поддерживаемых Flexberry Designer.

Основные элементы диаграммы — участник (actor) и прецедент (вариант).

Участник — это множество логически связанных ролей, исполняемых при взаимодействии с прецедентами или сущностями (система, подсистема или класс). Участником может быть человек или другая система, подсистема или класс, которые представляют нечто вне сущности. Графически участник изображается “человечком”.

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

Основные элементы диаграммы вариантов использования

На диаграмме вариантов использования можно отобразить следующие элементы нотации UML, доступные в панели элементов:

Элемент/Нотация	Предназначение
	Участник (Actor)
	Вариант (Use case)
	Граница (Boundary
	Ненаправленная ассоциация (Undirected communication association)
	Направленная ассоциация (Directed communication association)
	Обобщение (Generalization)
	Зависимость (Dependency)
	Точка изгиба связей (Point)
	Комментарий (Note)
	Коннектор комментария (Note connector)

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

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

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

Достоинства модели вариантов использования заключаются в том, что она:

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

Основные элементы диаграмм вариантов использования

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

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

Между активным субъектом и вариантом использования устанавливаются связь ассоциация ( association relationship ), которая выполняет коммуникативную функцию, сообщая о взаимодействии субъекта с системой в рамках определенного варианта использования. Направление связи указывает, кто (субъект или система) является инициатором взаимодействия.
Помимо связей между субъектом и вариантом использования, связи могут устанавливаться и между вариантами использования. Связи бывают двух типов — включающими ( inclusive ) и расширяющими ( extensive ).

Порядок построения Usecase Diagram

1. Создать usecase диаграмму с именем «Основная функциональность»
2. Проанализировать, какие активные субъекты должны взаимодействовать с будущей системой.
3. Создать actor’ов. (Например, Менеджер, Бухгалтер и Кладовщик).
4. Создать прецеденты. Например,
   • Оформление заказа.
   • Оформление счёта.
   • Оформление накладной.
   • Выдача товара.
5. Для пояснения можно использовать комментарии.
6. Расставить связи, обозначающие зависимость (необходимо продумать, какие прецеденты находятся в отношении зависимости).
7. Результатом является подобная диаграмма:

Перейти

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

UML для бизнес-моделирования: зачем нужны диаграммы процессов

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

Для чего используется UML?

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

• Проектирование. UML-диаграммы помогут при моделировании архитектуры больших проектов, в которой можно собрать как крупные, так и более мелкие детали и нарисовать каркас (схему) приложения. По нему впоследствии будет строиться код.
• Реверс-инжиниринг — создание UML-модели из существующего кода приложения, обратное построение. Может применяться, например, на проектах поддержки, где есть написанный код, но документация неполная или отсутствует.
• Из моделей можно извлекать текстовую информацию и генерировать относительно удобочитаемые тексты — документировать. Текст и графика будут дополнять друг друга.

Нотация UML для описания логики проекта

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

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

Часто используемые программы для создания диаграмм

• Diagrams.net — удобный сервис для создания блок-схем, UML-диаграмм, моделей бизнес-процессов онлайн. Совместим с большинством популярных инструментов, включая Google Docs, Git, Dropbox, OneDrive и другие.

• Dbdiagram.io — приложение для построения диаграмм связей для баз данных. Хороший инструмент для разработчиков и аналитиков.

• Google Drawings — бесплатный инструмент для создания блок-схем и диаграмм в составе Google Drive (менее удобный по сравнению с diagrams.net);
• xmind.net — программа для построения интеллектуальных карт (mind map), логических схем, сложных структур, проведения брейнсторма и не только.

Виды UML-диаграмм

В языке UML есть 12 типов диаграмм:

• 4 типа диаграмм представляют статическую структуру приложения;
• 5 типов представляют поведенческие аспекты системы;
• 3 представляют физические аспекты функционирования системы (диаграммы реализации).

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

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

Диаграмма прецедентов — Use-case diagram

Диаграмма прецедентов использует 2 основных элемента:

1) Actor (участник) — множество логически связанных ролей, исполняемых при взаимодействии с прецедентами или сущностями (система, подсистема или класс). Участником может быть человек, роль человека в системе или другая система, подсистема или класс, которые представляют нечто вне сущности.

2) Use case (прецедент) — описание отдельного аспекта поведения системы с точки зрения пользователя. Прецедент не показывает, «как» достигается некоторый результат, а только «что» именно выполняется.

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

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

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

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

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

Диаграмма активностей — Activity diagram

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

Диаграмма активностей для сайта магазина максимально доступно объясняет, какие есть интеграции в системе. Актер (в нашем случае — покупатель), зашедший на сайт, делает заказ. Далее у нас происходит разветвление: проверяем, является ли пользователь оптовиком (Да/Нет). Если он не зарегистрирован в системе и не оптовик, заказ отправляется в retailCRM. Если пользователь зарегистрирован, его заказ попадает в Navision. При этом между retailCRM и Navision происходит синхронизация остатка и статусов.

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

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

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

Диаграмма развертывания — Deployment Diagram

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

Заключение

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

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

Остались вопросы, хотите обсудить с нами ваш проект или заказать разработку? Пишите!

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

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

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

Сегодня мы разберемся с тем, как использовать диаграмму вариантов использования UML (англ. «Unified Modeling Language») – стандартизированный язык моделирования при проектировании программ.

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

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

• Что будет делать приложение?
• Кто будет пользоваться этим приложением?

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

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

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

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

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

В этой системе можно выделить следующие группы пользователей:

• Обучающиеся
• Преподаватели
• Классные руководители
• Заместители директора

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

Каждая из групп пользователей может пользоваться нашей системой по-своему.

• Смотреть расписание
• Просматривать свои оценки

• Размещать материалы для уроков
• Выставлять оценки в электронный журнал

Классные руководители могут делать все то же самое, что и преподаватели плюс:

• Составлять расписание родительских собраний

Заместители директора могут:

• Составлять расписание
• Публиковать посты с важной информацией

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

• Отправлять сообщения

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

А почему мы описываем так мало возможностей?

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

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

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

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

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

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

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

Так же изобразим актёров для оставшихся групп пользователей:

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

В терминологии UML, этот эллипс называется вариантом использования (англ. «use-case»). В общем случае, вариант использования – набор действий, который может быть использован актёром для взаимодействия с системой.

Связи между элементами

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

Отношение ассоциации

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

Мы соединили актеров с вариантом использования с помощью сплошной линии без стрелки. Такая линия называется отношением ассоциации.

Отношение ассоциации предназначено только для соединения актёров и вариантов использования. Нет никакого смысла соединять отношением ассоциации двух актёров или два варианта использования.

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

Почему отношение ассоциации называется так и не иначе?

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

Добавим еще вариантов использования и соединим их с соответствующими актёрами:

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

Отношение обобщения

Заметим, что в нашей системе группы пользователей «Преподаватель» и «Классный руководитель» обладают схожими возможностями. Чтобы изобразить это на диаграмме, мы можем пойти одним из трёх путей:

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

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

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

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

Ниже представлены несколько примеров использования отношения обобщения.

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

Вернёмся к нашему основному примеру. Изобразим отношение обобщения от актёра «Кл. руководитель» к актёру «Преподаватель».

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

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

Изобразим это на диаграмме. Для этого создадим два варианта использования «Узнать среднюю оценку за некоторый период времени» и «Узнать среднюю оценку по предмету» и соединим их с вариантом использования «Узнать свои оценки» отношением обобщения.

Присоединим это к основной диаграмме:

Отношение включения

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

1. Расписание занятий
2. Расписание мероприятий
3. Расписание каникул

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

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

Когда мы используем отношение включения, мы подразумеваем, что составные варианты использования ОБЯЗАТЕЛЬНО входят в состав общего варианта использования.

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

Снова вернёмся к нашему основному примеру.

Как итог, наша диаграмма принимает следующий вид:

В целом, на этом можно остановиться. Хоть наш пример и демонстрационный, он немного отражает функциональность реального приложения. Тем не менее, остался еще один элемент, который мы не рассмотрели.

Отношение расширения

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

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

Зачем над пунктирными линиями добавлять надписи “include” и “extend”?

В UML пунктирная линия с V-образной стрелкой, в общем случае, называется отношением зависимости. Для диаграммы вариантов использования выделяют различные виды зависимостей: отношение включения и отношение расширения. Чтобы их различать, над стрелками пунктирной линией пишут “include” и “extend” соответственно.

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

Два нижних варианта использования описывают возможные «расширения» для базового варианта использования. Исходя из этого примера, мы можем сделать важное замечание.

Можно сказать, что отношение расширения — это выборочное отношение включения. Если отношение включения обозначает, что элемент обязательно включается в состав другого элемента, то в случае отношения расширения это включение необязательно.

Понимание этого критически важно для грамотного использования этого вида отношений.

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

Как итог, получим такую диаграмму:

Вот и всё. Я постарался рассказать вам про все моменты построения диаграммы вариантов использования при проектировании программных систем. В следующем вашем проекте обязательно попробуйте построить данную диаграмму на стадии проектирования. Ваши усилия обязательно окупятся!

Что делать, если я путаюсь в направлении стрелок?

При построении диаграмм UML часто возникает путаница, в какую сторону направлена та или иная стрелка. Это пройдёт после небольшой практики. Общая рекомендация к запоминанию правильного направления стрелок на диаграмме вариантов использования: стрелка обычно направлена от «зависимого» объекта к «независимому» (от специального к общему). Например:

Тем не менее, в любом правиле есть исключение. Этим исключением является отношение расширение:

1. Диаграммы очень просто изменять. Не нужно пугаться того, что требования к программе могут измениться или что вы что-то забыли отобразить на диаграмме. Вы можете добавить элементы к диаграмме, когда вам угодно.
2. Не нужно засорять диаграмму слишком мелкими действиями. Объедините все общие действия в одну группу под общим названием, чтобы было просто читать диаграмму.
3. Старайтесь не допускать пересечений соединительных линий. Это может затруднить чтение диаграммы для вас и для ваших коллег.
4. Не дублируйте варианты использования на диаграмме. Если приходится дублировать варианты использования, то элементы диаграммы надо постараться расставить по-другому.
5. Пользуйтесь специальными компьютерными программами для построения диаграмм. Это существенно упростит весь процесс моделирования.

• проектирование
• моделирование
• Диаграммы вариантов использования
• для начинающих
• uml-проектирование
• uml
• uml activity diagram

• Проектирование и рефакторинг
• UML Design