Введение в диаграммы UML
В прошлый раз мы рассмотрели связи ассоциации и обобщения на диаграмме классов. Теперь разберём ещё две связи:
агрегацию и
зависимость.
Связи на диаграмме классов
Агрегация означает, что один класс состоит из множества экземпляров другого. Например, «Заказ» состоит из множества «Строк заказа». Обозначается стрелкой с ромбом на конце.
• Если ромб светлый (агрегация), жизненный цикл составного объекта и частей независим. При удалении заказа строки могут сохраниться, чтобы использовать их в новых заказах.
• Если ромб затемнённый (
композиция), объекты имеют одинаковый жизненный цикл. Уничтожение заказа должно приводить к удалению его строк.
Зависимость показывает, что один объект использует другой как аргумент. Например, «Строка заказа» зависит от «Товара»: информация в строке определяется спецификацией товара.
Для связи
ассоциация можно задавать дополнительную информацию: направление навигации, метки ролей, множественность. Направление навигации подсказывает, как интерпретировать диаграмму. Если стрелка направлена от «Клиента» к «Заказу», мы говорим: «Клиент может создавать заказы». Множественность уточняет: каждый клиент — единственный источник заказов, но может иметь их много.
Связь
обобщение позволяет строить деревья классов (наследование). На примере связи между «Компанией» и «Отделами» важно различать агрегацию и композицию: если при ликвидации компании отделы должны исчезнуть, нужна композиция, а не агрегация.
Прецеденты (Use Cases)
Второй элемент, описывающий статику бизнес-объекта, —
прецедент (use case, вариант использования). Это группа действий, которую видит внешний наблюдатель при обращении к системе. Прецеденты порождаются
действующими лицами (акторами). Например, клиент вызывает прецедент «Обработка заказов», поставщик — «Получение товаров». На диаграммах прецеденты изображают овалами.
Между прецедентами возможны два основных вида связей:
•
Расширение: стандартный прецедент дополняется специфическим поведением при определённых условиях. Например, «Сформировать заказ» может расширяться прецедентом «Повторить строки предыдущего заказа» — так не нужно заполнять всё вручную.
•
Использование: общий блок действий выносится в отдельный прецедент, на который ссылаются другие. Например, «Рассчитать стоимость» используется в «Оценке риска сделки» и «Согласовании цены», чтобы не описывать расчёт многократно.
Изредка между прецедентами задают отношение обобщения (родитель-потомок), но на практике оно применяется нечасто.
Описание динамики системы
Статику (классы и прецеденты) дополняет динамика — взаимодействие объектов. Любое поведение в объектном моделировании — это обмен сообщениями. Сообщением может быть не только передача данных, но и физическое перемещение предмета, запускающее действие. Взаимодействия рассматривают в трёх контекстах:
• между классами (универсальное представление ИС);
• между операциями внутри прецедента;
• между подсистемами.
В зависимости от того, на чём мы акцентируем внимание, выбирается тип диаграммы.
Диаграмма последовательности описывает порядок передачи сообщений во времени. На ней изображаются объекты с линиями жизни и стрелками вызовов. Пример обработки заказа: в цикле вводятся строки, для каждой проверяется наличие товара на складе (обращение к функции объекта «Товар»). Если товара нет — генерируется сообщение «повторный заказ» и обработка прекращается. Если все строки проверены и товар в наличии — формируется поставка. Маркер итерации указывает цикл, а самоделегирование — вызов внутренней функции объекта.
Кооперативная диаграмма фокусируется на группе объектов, участвующих в деятельности. Сообщения нумеруются, чтобы показать последовательность, но главное — увидеть состав участников прецедента. Те же объекты, что и на диаграмме последовательности, можно представить в виде кооперации, получая другой ракурс для анализа.
Диаграмма состояний показывает, как один объект меняет свои состояния под воздействием событий. Событием может быть сообщение от другого объекта, истечение времени или внешнее изменение. Анализ состояний объекта «Заказ» помогает выявить скрытые атрибуты, например атрибут
«состояние заказа». Он не очевиден из бланка заказа, но необходим, так как от состояния (проверка строк, ожидание, формирование поставки) зависит допустимость операций. Диаграмма состояний задаёт переходы: начальное состояние → действие «проверить строку» → проверка всех строк → если всё есть на складе → формирование поставки → выполнено; если чего-то нет → ожидание. Это позволяет ввести атрибут, принимающий значения «Проверка», «Ожидание», «Формирование поставки».
Диаграмма деятельности описывает поток операций, исполняющих прецедент. Она хорошо воспринимается и заказчиком, и разработчиком. Состоит из начального и конечного узлов, овалов действий, стрелок переходов, логических ветвлений (условия в квадратных скобках) и
линеек синхронизации. Линейки синхронизации обозначают логическое «И»: все входящие ветки должны завершиться перед продолжением. Ими также удобно обозначать циклы, возвращая поток к маркеру множественного исполнения. Диаграмма деятельности напоминает IDEF3 и блок-схемы алгоритмов, что облегчает согласование модели с неспециалистами.
Диаграмма размещения отображает распределение подсистем по техническим средствам (серверам, базам данных), описывая монтажную архитектуру системы.
Все перечисленные диаграммы применимы как к бизнес-системе, так и к информационной системе. Для описания бизнес-деятельности наиболее удобна диаграмма деятельности. Для проектирования информационной системы — диаграммы последовательности, поскольку в ИС сообщения — это передача структурированной информации.
Пример: автоматизация склада
Рассмотрим проектирование системы с использованием UML на примере автоматизации получения товара на склад.
Шаг 1. Действующие лица и прецеденты. Выявляем акторов и их прецеденты. Внешнее действующее лицо «Поставщик» порождает прецедент «Получение товара». Пока модель фиксирует лишь сам факт групповой деятельности.
Шаг 2. Диаграмма деятельности. Описываем исполнение прецедента с помощью
плавательных дорожек. Дорожки могут отражать подразделения, исполнителей или документы. Каждое действие можно пометить как подлежащее автоматизации. Последовательность:
• Бухгалтерия выписывает доверенность на основе заявки отдела снабжения. Документы: заявка, бланк доверенности. Действие автоматизируемо.
• Снабженец с доверенностью едет к поставщику и получает товар. Появляются накладная и счёт-фактура. Процедура не автоматизируется.
• Снабженец передаёт товар на склад с дефектацией (проверка количества и качества). Не автоматизируется.
• При успешной приёмке выписывается
приёмный акт в двух экземплярах. Это действие можно автоматизировать. Наличие двух экземпляров, идущих разными путями, указывает на потенциальные скрытые атрибуты состояния акта.
• Регистрация товара в картотеке склада — автоматизируемая операция.
• Один экземпляр акта передаётся снабженцу, второй — в бухгалтерию. Передачу в бухгалтерию можно автоматизировать с помощью внутренней сети.
• Учёт приёмного акта в бухгалтерии — учётная процедура, поддающаяся автоматизации.
Шаг 3. Функции кладовщика. В рамках автоматизируемого склада кладовщик выполняет:
• Оформление приёмного акта (на основе накладной);
• Регистрация товара в картотеке (использует карточки товаров);
• Передача акта в бухгалтерию.
На этой стадии фиксируются действия и документы, подлежащие автоматизации.
Шаг 4. Диаграмма классов бизнес-объектов. Начинаем описывать информационные блоки, например
приёмный акт. Он представляется как композиция из:
•
Заголовка (номер, дата, вид операции, склад и т.д.). Кратность 1:1 — в одном акте один заголовок.
•
Блока подписей (сведения о недостаче или браке, подписи сдал/принял). Тоже 1:1.
• Множества
строк приёмного акта с наименованием, номенклатурным номером, количеством. Связь «один-ко-многим»: один акт содержит много строк, строка принадлежит только одному акту.
Разделение заголовка и подписей на разные объекты оправдано смысловым различием: заголовок идентифицирует документ, а подписи фиксируют участников работы. При моделировании бизнес-процессов не обязательно добиваться программной строгости.
Важное ограничение
Не пытайтесь переносить принципы объектно-ориентированного программирования на анализ бизнес-процессов. На этапе анализа излишняя детализация диаграмм классов со всеми атрибутами, методами и ограничениями затормаживает проект. Достаточно описать структуру информации, чтобы понять, где она будет использоваться и в каких подсистемах. Попытка сгенерировать готовый код сразу из таких моделей, скорее всего, приведёт к катастрофе. Детальное описание классов уместно позже — при проектировании отдельных программных модулей, где можно применять строгие нотации и генерацию кода. На стадии бизнес-анализа главное — построить адекватную и понятную заказчику модель.
Краткие итоги
Моделирование начинается с фиксации статической картины: какие классы объектов существуют в системе и какие укрупнённые группы действий (прецеденты) инициируют внешние акторы. Агрегация и композиция задают правила сосуществования объектов, что прямо влияет на решения о сохранении или удалении данных при реорганизации процессов. Выявление прецедентов и связей между ними (расширение, использование) позволяет избежать дублирования описаний и выделить переиспользуемые функциональные блоки.
После определения статики внимание переносится на динамику. Диаграммы последовательности и кооперации дают два взаимодополняющих взгляда на взаимодействие объектов: первый фокусируется на хронологии сообщений, второй — на составе участников. Диаграмма состояний отдельного объекта раскрывает скрытую логику его жизненного цикла, заставляя явно ввести атрибуты, не видные из первичных документов, но критичные для допустимости операций. Диаграмма деятельности, благодаря наглядности и сходству с блок-схемами, становится главным средством коммуникации с заказчиком и инструментом первичного членения процесса на автоматизируемые и неавтоматизируемые шаги.
Практическая ценность представленной методологии раскрывается в сквозном примере автоматизации склада. Логика проектирования выстраивается от простого к сложному: сначала фиксируется прецедент «Получение товара», затем он детализируется дорожками деятельности с точным указанием документооборота и точек входа автоматизации, после чего уточняются функции конкретного исполнителя (кладовщика). Лишь после этого наступает черёд структурного описания ключевых бизнес-объектов, таких как приёмный акт, с выделением его составных частей и множественности связей. Такой порядок гарантирует, что структуры данных вырастают из реальных операций, а не из умозрительных схем.
Принципиально важным является разграничение уровней детализации. Попытка на фазе бизнес-анализа довести диаграмму классов до точности программного кода блокирует проект, уводя в бесконечную проработку нюансов. Модель на данном этапе должна давать целостное понимание информационных потоков и логики процессов, достаточное для принятия архитектурных решений и согласования с заинтересованными сторонами. Детальная проработка методов и атрибутов переносится на стадию проектирования конкретных программных модулей, где она становится уместной и продуктивной.
1. Агрегация предполагает независимый жизненный цикл частей и целого, композиция — одинаковый; выбор влияет на правила удаления объектов в системе.
2. Связь «зависимость» фиксирует, что один класс использует другой в качестве аргумента или источника данных для своих методов.
3. Направление навигации в ассоциации служит подсказкой для интерпретации диаграммы и не меняет структурных характеристик связи.
4. Прецеденты (use cases) описывают наблюдаемые извне группы действий, порождаемые внешними действующими лицами.
5. Связь «расширение» позволяет добавить специфическое поведение к базовому прецеденту при выполнении условий, а «использование» выносит повторяющийся блок действий.
6. Диаграмма последовательности ориентирована на временной порядок обмена сообщениями между объектами при реализации прецедента.
7. Кооперативная диаграмма раскрывает статический состав объектов, участвующих во взаимодействии, акцентируя структуру кооперации.
8. Диаграмма состояний помогает выявить скрытые атрибуты объекта, определяющие допустимость операций в разных фазах его жизненного цикла.
9. Диаграмма деятельности с плавательными дорожками наглядна для заказчика и позволяет разграничить автоматизируемые и ручные операции.
10. При моделировании бизнес-процессов не следует стремиться к детализации диаграмм классов, пригодной для кодогенерации — это останавливает проект.
11. Цепочка проектирования: акторы и прецеденты → диаграмма деятельности → функции исполнителя → структура бизнес-объектов.
12. Для бизнес-моделирования главный инструмент — диаграмма деятельности; для проектирования ИС — диаграмма последовательности.
1. Чем отличается агрегация от композиции с точки зрения жизненного цикла объектов?
2. Какую информацию о связи ассоциации можно дополнительно указать на диаграмме классов?
3. Для чего в диаграмме прецедентов используется связь «расширение»? Приведите пример.
4. В чём различие фокуса внимания диаграммы последовательности и кооперативной диаграммы?
5. Какую практическую задачу решает построение диаграммы состояний объекта «Заказ»?
6. Из каких основных элементов состоит диаграмма деятельности и что обозначают линейки синхронизации?
7. Каким образом на диаграмме деятельности можно указать цикл без лишних стрелок?
8. Почему диаграмма деятельности считается удобной для согласования с заказчиком?
9. В какой последовательности выполняются шаги при проектировании системы автоматизации склада в рассмотренном примере?
10. Для чего на диаграмме классов приёмного акта заголовок и блок подписей выделены в отдельные объекты?
11. Почему на этапе бизнес-анализа не следует детализировать диаграмму классов до уровня программной реализации?
12. Какие типы диаграмм наиболее подходят для описания бизнес-процессов и для проектирования работы информационной системы соответственно?
