Выбор инструмента проектирования (UML) / Хабр

Выбор инструмента проектирования (UML) / Хабр Аналитика

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

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

  • фигуры;
  • линии;
  • значки;
  • надписи.

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

Введение

Я — системный аналитик, и моя работа заключается в том, чтобы проектировать автоматизированные информационные системы. Впрочем, нет, она заключается в том, чтобы писать и писать документы. Третий раз слово «писать» повторять не буду — все-таки, не «Илиада».

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

Уверен, многие слышали о PlantUML, по крайней пере, на GitHub у него стоит больше тысячи звезд. Смысл этого инструмента исключительно прост, он всего лишь позволяет задавать диаграммы (по большей части в нотации UML) в виде текста, описывающего элементы и связи между ними. Графический вид создается автоматически. Далее приведен пример диаграммы деятельности.

start
:Вывалить мысли
в текст;
if (Бред?) then (Возможно)
    :Дать посмотреть коллеге;
    if (Сойдет?) then (Да)
    else (Нет)
        :Помедитировать над текстом;
    endif
    :Разместить на //Хабре//;
else (Точно)
    stop
endif
stop

Выбор инструмента проектирования (UML) / Хабр

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

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

Что такое uml-диаграммы?

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

Почему plantuml

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

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

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

Тем не менее для меня эти критерии являются точкой отсчета, от которого начинаешь придумывать диаграмму. Дальше…​ как сложится.

Очень долгое время золотым сечением для себя я считал использование Microsoft Visio и рисовал там диаграммы, стараясь быть разумно близким к UML. При этом использовался стандартный набор компонентов, поскольку он дает больше свободы, чем специализированный stencil для UML. Также некоторые диаграммы для показа на проекторе рисовались в Microsoft PowerPoint.

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

Также пробовал специализированные инструменты бизнес-моделирования: Rational Rose, Aris, Enterpise Architect (Sparx Systems), — в наибольшей степени Rational Rose. Проблема в том, что конечный результат моей работы — это документы. И в этом смысле, если что-то серьезное меняется в требованиях, все равно необходимо вручную проходить по всем проекту и заново вставлять диаграммы в нужные места текста. Что-то придумывать, возможно, автоматизировать в этой части мне показалось слишком сложным и не стоящим усилий.

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

  1. Раз диаграммы создаются в виде текста, значит в любом текстовом редакторе (мне нравятся Atom и Notepad ) можно найти требуемый текст в наборе файлов и даже заменить его. Рефакторинг проекта вполне удобен. Также текстовый формат дает возможность легко организовывать групповую работу и осуществлять отслеживание изменений в системе контроля версий.

  2. В PlantUML создавать диаграммы быстрее, чем в любых визуальных редакторах (по крайней мере, для меня). На этот счет есть и другие мнения, например, здесь говорится, что создание диаграммы в PlantUML дольше, чем, скажем в Enterpise Architect (Sparx Systems). Думаю, это скорее вопрос вкуса и привычки.

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

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

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

    И тем не менее PlantUML — это UML, т.е. общепринятая нотация, стандарт, а значит для документации, особенно в государственных проектах, очень подходит.

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

  5. Диаграммы PlantUML можно генерировать автоматически. Пример такого использования приведен в здесь.

    Мы используем PlantUML для автоматической генерации схемы базы данных. Функция такой генерации встроена в используемый нами инструмент управления структурой баз данных  — 2bass. Таким образом, при сборке документации диаграмма классов со структурой БД находится всегда в актуальном состоянии. На следующем рисунке показан кусок описания структуры базы данных и автоматически созданная диаграмма.

    Выбор инструмента проектирования (UML) / Хабр

Aggregation (aggregate association)

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

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

ниже нарисован сценарий, который должерн быть вам довольно знакомым:

Один экземпляр Customer наследует один экземпляр ShoppingCart, в роли currentCart. Однако, Customerполучает существующий объкт ShoppingCart, создавая тем самым зависимость экзепляра ShoppingCart от экземпляра Customer.

давайте рассмотрим код:

1. class Customer
2. {
3. private $_cart;
4.
5. publicfunction __construct(ShoppingCart $cart)
6. {
7. $this->_cart = $cart;
8. }
9. }
10.
11. class ShoppingCart
12. {
13.
14. }

* This source code was highlighted with Source Code Highlighter.

Assocations

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

Так же здесь могут быть разные отношения между сущностями:

0..1 ноль или один

1 только один

0..* ноль или много

1..* один или много

n Только n (где n > 1)

0..n ноль к n (где n > 1)

1…n один к n (где n > 1)

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

Association class:

Класс ассоциаций, или drop class это класс который показывает специфическую ассоциацию:

пунктирная линия в примере показывает нам что сущность Customer относиться к сущности ShoppingCart и при этом существует сущность WishList, те отношение между Customer и ShoppingCart зависит от существования WishList.

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

По традиции, конечно пример кода:

1. class Customer
2. {
3. publicfunction checkoutCart(ShoppingCart $cart)
4. {
5. $cart->getItems();
6. //.
7. return $items;
8.
9. }
10. }
11.
12. class ShoppingCart
13. {
14. publicfunction getItems()
15. {
16. //.
17. }
18. }
19.
20. class WhishList
21. {
22. publicfunction makeCheckOutList(Customer $customer, ShoppingCart $cart)
23. {
24. $this->updateWhishList(
25. $customer->checkoutCart($cart)
26. );
27. //.
28. }
29. }

* This source code was highlighted with Source Code Highlighter.

Bi-directional naviageble association

Bi-directional подразумевает что оба класса осведомлены о свой зависимости к другому классу. Давайте рассмотрим диаграмму

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

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

1. class Customer
2. {
3. publicfunction getCheckOutDetails(ShoppingCart $cart)
4. {
5. $this->checkCredit(
6. $cart->getAmount()
7. );
8. //.
9. }
10. }
11.
12. class ShoppingCart
13. {
14. publicfunction checkOutUsingCustomer(Customer $customer)
15. {
16. $customer->getCheckOutDetails($this);
17. //.
18. }
19. }

* This source code was highlighted with Source Code Highlighter.

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

Composite aggregagtion (composition)

В композитивном агрегированнии сам объкт это композиция частей других объектов чей жизненый цикл зависит от жизни самой композиции.Здесь должна быть строгая связь, в которой целое это композиция его частей:1. У машины есть колёса, но 4 колеса не состовляют машину2. Mysql Кластер это композиции mysql серверов, но сам по себе mysql сервер не представляет кластер.

как видно из 2-го примера — у нас должна быть довольно строгая связь. Пользуясь этой связью давай приведем еще один пример:США это композиция ее штатов:Возможно все штаты америки не равны США, но здесь мы имеем строгую связь которую требует Composite Aggregation:

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

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

давайте рассмотрим пример на нашей коммерческой системе:в ней мы решили что ShopppingCart не может сущестовать без Customer (без этого наша система теряет смысл)Мы так же решили что ShoppingCart это пуп вселенной, по крайней мере для нас, поэтому нам нужно постараться определить остальные объкты через связь с покупательской тележкой:

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

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

и пример кода

1. //Uni-directional
2. class Customer
3. {
4. private $_cart;
5.
6. publicfunction __construct()
7. {
8. $this->_cart = new ShoppingCart();
9. }
10. }
11.
12. class ShoppingCart
13. {
14. private $_items = array();
15.
16. publicfunction getItems()
17. {
18. return $this->_items;
19. }
20. }
21. //Bi-directional
22. class Customer
23. {
24. private $_cart;
25.
26. publicfunction __construct()
27. {
28. $this->_cart = new ShoppingCart();
29. }
30.
31. publicfunction getCart()
32. {
33. return $this->_cart;
34. }
35.
36. publicfunction checkOutCart()
37. {
38. $this->getCart()->getCheckOutDetails($this);
39. }
40.
41. publicfunction getCustomerDetails()
42. {
43. //.
44. }
45. }
46. class ShoppingCart
47. {
48. publicfunction getCheckOutDetails(Customer $customer)
49. {
50. $customer->getCustomerDetails();
51. //.
52. }
53. }

* This source code was highlighted with Source Code Highlighter.

Generalizations

Generalizations — представление кода «как он есть», это связи с которыми вы уже должны были подружиться,( за время програмирования =):интерфейсы и наследование, я просто приведу вам небольшой пример натации обоих:

асбтракный класс ProductList наследуеться от интерфейса ItemList, ShoppingCart расширяет функциональность ProductList

Uni-direction navigable association

в Uni-direction отношении только один класс осведомлён о существовании другого

Выбор инструмента проектирования (UML) / Хабр
В этом примере, класс ShoppingCart ничего не знает об классе Customer, но! Customer осведомлен о ShoppingCart и в этом проявляется их отношение. Отметьте что мы оставили множественное значение, подчеркивая что класс Customer знает об множестве ShoppingCart, в то время как само множество ShoppingCart ничего не знает об классе Customer.Для общности картины, отношение Customer to ShoppingCart может быть диагонально перевернуто, и тогда мы получим вот такую схему:
Выбор инструмента проектирования (UML) / Хабр

сейчас единственный класс ShoppingCart относиться ко множеству Customer, без их «виденья». Думаю этот пример Uni-directional должен быть вам знакомым

дайте рассмотрим сам код:

1. class Customer
2. {
3. publicfunction getCreditDetails($purchaseAmount)
4. {
5. $this->checkCredit($purchaseAmount);
6. //.
7.
8. }
9. }
10.
11. class ShoppingCart
12. {
13. publicfunction checkOutUsingCustomer(Customer $customer)
14. {
15. $customer->getCheckOutDetails($this->getAmount());
16. //.
17. }
18. }

* This source code was highlighted with Source Code Highlighter.

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

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

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

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

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

Где создавать диаграммы?

Для начала хотелось бы упомянуть PlantUML Web Server — часть проекта PlantUML, на котором диаграммы можно создавать онлайн и делиться ими с коллегами. Это очень удобная возможность, но, конечно же, не при создании диаграмм для проектной документации.

Часто PlantUML используется в вики-движках. Здесь редактирование происходит стандартным образом: пишется текст, сохраняется, и на странице мы получаем картинку. Но все-таки, в большинстве случаев удобно, чтобы на диаграмме сразу отображался результат: например, в левом окне пишется спецификация диаграммы, в правом — отображается ее внешний вид. Готовый текст уже можно вставить в wiki.

На сайте PlantUML приведено много редакторов. Подозреваю, что среди них больше половины не пригодны для работы. Мне больше всего нравится создавать PlantUML-диаграммы с помощью plug-in’а PlantUML Preview в редакторе Atom. На самом деле таких plugin’ов несколько.

Выбор инструмента проектирования (UML) / Хабр

Т.е. каждой диаграмме всегда соответствует два файла, один текстовый (с текстовым описанием диаграммы), а другой — графический (картинка с диаграммой).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Использование иконок

PlantUML поддерживает несколько способов использования иконок. Все они обладают определенными ограничениями.

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

Обратите внимание, что спрайты в PlantUML являются растровыми изображениями, т.е. у них есть ограничения по масштабированию. В данной конкретной библиотеке разрешение иконок составляет 48 на 48 точек. При использовании такого изображения для печати нежелательно масштабировать его до размеров более 5 миллиметров (что примерно соответствует разрешению 250 dpi).

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

Использование кавычек

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

PlantUML поддерживает много способов использования кавычек. Но в результате поисков я нашел только один, который работает всегда, старый добрый лом: для открывающих русских кавычек — <U 00AB>, для закрывающих — <U 00BB>, для универсальных — <U 0022>.

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

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

Мне помогают не запутаться два простых правила.

  1. Вводите все элементы через ключевые слова (не использовать упрощенный синтаксис). Если элемент позволяет, задавать для него алиас.

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

Многострочный текст и wiki-разметка

PlantUML содержит неплохие средства для форматирования текста в элементах.

При генерации элемента диаграммы PlantUML исходит из размера текста. Т.е. не текст перетекает в зависимости от размера элемента, а размер элемента подстраивается под текст.

Самый простой вариант создания большого текста — использование символа «n». В этом случае можно также использовать символы форматирования текста (жирный, курсив и т.п.)

component "**Компонент 1** n Не входит ни в один пакет n //**Экспонирует**// n* //Интерфейс// 1 n* //Интерфейс 2//" as c1

Выбор инструмента проектирования (UML) / Хабр

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

component c1 [
    **Компонент 1**
    ====
    Не входит ни в один пакет
    ..//**Экспонирует**//..
    * //Интерфейс// 1
    * //Интерфейс 2//
]
note left
    Тот же текст в примечании
    ....
    **Компонент 1**
    ====
    Не входит ни в один пакет
    ..//**Экспонирует**//..
    * //Интерфейс// 1
    * //Интерфейс 2//
end note

Выбор инструмента проектирования (UML) / Хабр

Как мы видим, при использовании такого синтаксиса появляется возможность добавлять разделительные линии. Обратите внимание, здесь добавлено примечание, отображающее тот же текст, что и компонент. При этом в примечании список отображается, как список, а в компоненте, как текст через символ «*».

Отношения

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


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

Associations
Bi-directional asociation (standart association)
Uni-directional association
Associationo class (drop class)
Aggregation
Regular aggregation
Composition (composite aggregation)
Generalizations
Dependencies

Подготовка диаграмм для печати

Для качественной печати на лазерном принтере необходимо указать параметр skinparam dpi 300. Разрешение в 300 dpi обеспечивает качественный рисунок для печати на лазерном принтере. В противном случае картинки создаются с экранным разрешением и выглядят растрированными.

В PlantUML есть также возможность использовать svg (векторный формат). Но данный формат поддерживается гораздо меньше, чем png, и проблем с ним гораздо больше. Я использовал svg, если необходимо было немного довести картинку до ума векторным редактором (например, с использованием Inkscape). Но это, конечно же, крайне редкий вариант использования PlantUML.

Для убирания теней, которые обычно тоже портят печатный вид, используется параметр skinparam shadowing false.

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

skinparam component {
  borderColor black
  backgroundColor white
  ArrowColor black
}

Перечень большинства параметров приведен здесь. Если хочется изучить все параметры, можно воспользоваться командой java -jar plantuml.jar -language.

Практика применения uml для проектирования бизнес процессов и информационных систем

Управление проектомБесплатно (free)

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

17.06.2021   
40912   
raiml   
37    

Представление классов

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

Названия абстрактных классов будет выделено курсивом

Интерфейсы представлены идентично по отношению к классам за исключением того что в название будет добавлено ключевое слово< >

ПакетыПакет это сущность которая представляет собой группу классов и интерфейсов. В основах UML пакет представлен в след виде:

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

Представление различных типов видимости данных в UML public# protected— private~ package

UML не ограничена только виденьем членов класса — сам класс может иметь своё виденье тоже. Если вы хотите посмотреть «на всю картину» вам нужно использовать пакетную диаграмму.

Советы по использованию plantuml

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

Dependencies:

Dependencies показывать что изменение в одной структуре может потребовать изменение в другой, во многих случаях другие типы зависимостей уже подразумивают какую-либо зависимость, но есть вы хотите описать зависимости более детально — вы можете использовать dependency, что бы описать связь между эллементами. Это подразумевает что зависимость слабая и не пригодна для использования в associative relation.

давайте посмотрим след диаграмму:

Customer зависит от WishList тк он содержит желаемые предметы покупки. Пунктирная линия показывать что getWishList это статическая операция.Customer зависит от работы ф-ции getWishList.

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

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

Заключение

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

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

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

06.02.2021

Используемые в статье картинки взяты из открытых источников и используются как иллюстрации.

Дополнительный анализ:  ABC-анализ продаж в ресторане: как правильно?, Менеджмент на
Оцените статью
Аналитик-эксперт
Добавить комментарий

Adblock
detector