Уточняем описание функций системы с помощью диаграммы Sequence (продолжение "Белки")
В данной статье рассмотрим, как можно детализировать (уточнить) описание автоматизируемой функции с помощью UML Sequence Diagram — диаграммы последовательности.
В данном примере я использую среду Enterprise Architect от австралийской компании Sparx Systems [1].
Полную спецификацию UML см. здесь [2].
Для начала поясню, что мы будем детализировать.
В 1-ой части статьи "От моделирования процессов к проектированию автоматизированной системы" мы моделировали процессы «сказочной» предметной области — строчки про белку из "Сказки о царе Салтане" А.С.Пушкина. И начали мы с диаграммы Activity. Потом во 2-ой части мы разработали функциональную модель с помощью диаграммы Use-case, на Рисунке 1 представлен фрагмент.
Рисунок 1. Связь требования и функции
Теперь мы хотим уточнить информацию о выполнении данной автоматизируемой функции:
- с какими компонентами интерфейса будет взаимодействовать наш пользователь;
- какие управляющие компоненты нам понадобятся;
- что мы будем хранить;
- какими сообщениями будут обмениваться пользователь и компоненты системы для выполнения функции.
Основными элементами диаграммы Sequence являются взаимодействующие объекты с различными стереотипами и связи между ними — взаимодействующие объекты обмениваются между собой некоторой информацией (Рисунок 2).
Рисунок 2. Основные элементы Sequence диаграммы
Объекты расположены в горизонтальной последовательности, между ними передаются сообщения. Ось времени ориентирована сверху вниз.
Элемент Actor может использоваться для представления пользователя, инициирующего поток событий.
Каждый объект имеет пунктирную линию, называемую "линией жизни", где этот элемент существует и потенциально принимает участие во взаимодействиях. Фокус управления обозначается прямоугольником на линии жизни объекта.
Сообщения, которыми обмениваются объекты, могут быть нескольких типов, сообщения также могут быть настроены для отражения операций и свойств исходного и целевого элементов.
Стереотипные элементы, такие как границы (Boundary), элементы управления (Control) и сущности (Entity), могут использоваться для моделирования пользовательского интерфейса (GUI), контроллеров и элементов базы данных, соответственно.
Повторяющийся поток обмена сообщениями может быть обозначен как фрагмент с типом "loop".
Итак, мы планируем уточнить описание функции "Добавить в ведомость информацию о новом орехе".
Договоримся о следующих дополнительных обобщениях и допущениях.
- Орех, ядро и скорлупки — это все материальные ценности соответствующих типов (Рисунок 3).
Рисунок 3. Уточнение диаграммы классов - В ведомость наш пользователь будет вносить информацию о любых материальных ценностях.
- Уточним название ведомости — "Ведомость учета мат.ценностей".
- Допустим, что наш пользователь, работая с GUI "Ведомость учета мат.ценностей", может добавить новую мат.ценность через GUI "Карточка учета мат.ценности".
- В зависимости от типа мат.ценности меняется структура данных и GUI.
- При заполнении полей карточки учета мат.ценности происходит проверка корректности введенных данных.
Диаграмма, построенная с учетом этих допущений, приведена на Рисунке 4.
Рисунок 4. Уточнение описания функции "Добавить в ведомость информацию о новом орехе"
О применении других видов диаграмм UML можно почитать здесь:
- От моделирования процессов к проектированию автоматизированной системы (Часть 1);
- От моделирования процессов к проектированию автоматизированной системы (Часть 2);
- Два подхода к структурированию диаграммы Activity.
- Сайт Sparx Systems. [Электронный ресурс] Режим доступа: Интернет: https://sparxsystems.com
- OMG Unified Modeling Language (OMG UML) Specification. Version 2.5.1. [Электронный ресурс] Режим доступа: Интернет: https://www.omg.org/spec/UML/2.5.1/PDF
mmMike
Гальванизация трупа?
UML был очень моден. Очень моден и его продвигали так же как сейчас DevOps, Docker и функциональное программирование, как универсальные таблетки/кнопки "счастье".
Но как то не прижился (в части генерация кода, диаграммы классов и пр.).
Ну разве что временные диаграммы вещь полезная, поскольку интуитивно понятная всеми.
Ну не стало все остальное универсальным языком (эсперанто, по аналогии). Его мало кто знал и во время расцвета UML, а сейчас и подавно.
Я понял, что что то не так, когда в учебнике UML (Rational Rose кажется) увидел конкретный такой пример использования. Дословно не помню, но что то типа:
Мол жила семейная пара со своим мелким бизнесом, и что то у них он плохо шел.
вот купили они ПО для UML (Rational Rose) нарисовали диаграммы и пр. (пример довольно примитивной диаграммы с "человечками" и стрелочками) и как у них бизнес рванул..
Разводка от производителей ПО для UML, все это по большей части.
questor
И что по-вашему заменило UML? Или один король умер, но нового да здравствует короля не нашлось?
mmMike
Описании ПО (классы и взаимодействие и пр.) — ничего взамен. Хотя бы потому, что программисту проще понять по исходникам с комментариями как работает, чем по UML описанию (языка которого мало кто сейчас знает).
В описании бизнес процессов…
Когда разговариваешь с заказчиками, у них у всех свой язык и пытаться заставить их изучить специальный искусственный язык типа UML… Это даже не смешно.
Скорее приходится находить взаимопонимание в рамках того языка (в том числе и графического/визуaльного) и терминологии, что принята у конкретного заказчика.
А он нужен? новый король.
Откуда такая уверенность, что сама концепция искусственного языка типа UML это то что нужно людям (судьба эксперанто..)?
c0va23
В статье как раз и предполагается, что UML один из возможных инструментов:
Да, UML не стал то самой серебряной пулей. Но всё же это не плохой инструмент для коммуникации внутри команды разработки и между командами. И так же UML хорошо подходит для документации и/или передачи знаний.
У нас UML тоже не является одним из основных инструментов. Но всё же периодически (2-3 раза в год) при проектировании некоторый задач он помогает.
krasni Автор
Что касается моды на UML и «происков» производителей ПО — это все, конечно, верно.
Но… Страсти по UML давно улеглись, появилось много инструментов бесплатных или весьма бюджетных (не сравнить с Rational Rose не только по цене, но и по юзабилити), а еще и с открытым кодом имеются. Универсальность UML немного пугает в начале, но если перефразировать принцип Парето «20% усилий дают 80% результата, а остальные 80% усилий — лишь 20% результата» в «20% диаграмм используется в 80% случаев», то жизнь становится легче:) И что плохого в том, что есть достаточно четкие правила использования моделирующих элементов каждой диаграммы, у диаграмм есть специализация? А если что-то хочется изменить или дополнить — пишите соглашение по моделированию, — вот и все!
Ну, а на счет «бизнес рванул» — все возможно…
Возможно, систематизировали люди информацию, проанализировали, нашли узкие места, что-то поменяли, вот бизнес и рванул, а UML действительно помог. Хотя пример в книжке — это еще и
разводкамаркетинговый ход от производителей ПО для UML, как Вы верно заметили:)