UML для разработчиков / Хабр

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

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

 Термин Изображение Описание
 Найденное сообщение Найденное сообщение диаграммы последовательности UML У первого сообщения нет участника, пославшего его, поскольку оно приходит из неизвестного источника. Оно называется найденным сообщением (found message).
 Сообщение Сообщение диаграммы последовательности UML Команда, отправляемая другому участнику. Может содержать только передаваемые данные.
 Линия жизни Линия жизни диаграммы последовательности UML Каждая линия жизни имеет полосу активности, которая показывает интервал активности участника при взаимодействии. Она соответству ет времени нахождения в стеке одного из методов участника. В языке UML полосы активности не обязательны, но я считаю их исключительно удобными при пояснении поведения.
 Участник Участник диаграммы последовательности UML В большинстве случаев можно считать участников диаграммы взаимодействия объектами, как это и было в действительности в UML 1. Но в UML 2 их роль значительно сложнее. Поэтому здесь употребляется термин участники (participants), который формально не входит в спецификацию UML.
 Самовызов Самовызов диаграммы последовательности UML Участник отправляет сообщение (команду) самому себе.
 Возврат Возврат диаграммы последовательности UML Передача управления обратно участнику, который до этого инициировал сообщение.
 Активация Активация - диаграмма последовательности UML На изображении это — белый вертикальный прямоугольник. Момент, когда участник начинает действовать в ответ на принятое сообщение.
 Создание Создание - диаграмма последовательности UML В случае создания участника надо нарисовать стрелку сообщения, на правленную к прямоугольнику участника. Если применяется конст руктор, то имя сообщения не обязательно, но можно маркировать его словом «new» в любом случае. Если участник выполняет что- нибудь непосредственно после создания, например команду запроса, то надо
начать активацию сразу после прямоугольника участника.
 Самоудаление Самоудаление - диаграмма последовательности UML Удаление участника обозначается большим крестом (X). X в конце линии жизни показывает, что участник удаля ет сам себя.
 Удаление из другого объекта Удаление из другого объекта - диаграмма последовательности UML Удаление участника обозначается большим крестом (X). Стрелка сооб щения, идущая в X, означает, что один участник явным образом уда ляет другого.
 Фреймы взаимодействия Фреймы взаимодействия - диаграмма последовательности UML 

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

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

Диаграмма последова тельности применяется для визуализации процесса взаимодействия объектов, а не как средство моделирования алгоритма управления.
Как было сказано, существуют дополнительные обозначения. И для циклов, и для условий используются фреймы взаимодействий (inter action frames), представляющие собой средство разметки диаграммы взаимодействия.

Похожее:  Авторизация в PhoneGap приложении через Facebook, Vkontakte и Habrahabr / Хабр

Crc-карточки

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

, придуманные Уордом Каннингемом (Ward Cunningham) в конце 80-х годов, выдержали проверку временем и стали высокоэффективным инструментом решения этой задачи (рис. 4.6). И хотя они не входят в состав UML, все же являются очень популярными среди высококвалифицированных разработчиков в области объектных технологий.

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

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

Вторая буква «С» (в CRC) означает взаимодействие (collaboration): другие классы, с которыми должен работать рассматриваемый класс. Это дает вам некоторое представление о связях между классами, но все еще на высоком уровне.

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

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

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

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

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

Важно

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

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

  • Если вы используете специальный инструмент, (как я), вам необходимо включить блок легенды. Сами по себе стрелки и цвет непонятны — легенда объясняет всё это.

  • Очень распространенный вопрос, когда используешь облака, включать ли вы управляемые сервисы, такие как очереди сообщений? Я обычно отвечаю: «Нет». Это усложняет диаграмму, делает её нечитабельной. Если некоторые сервисы обмениваются данными через очередь сообщений, отобразите её с помощью стрелки отдельного типа.

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

Илья, архитектор предприятия.

Детализация


Последние две диаграммы, которые очень полезны (внимательный читатель конечно заметил, что всего видов диаграмм уже не 2-3): Sequence diagram (Диаграмма последовательности) и Class Diagram (Диаграмма классов, но вовсе не для классов).

Иногда взаимодействие клиента и сервера многоступенчатое, с использованием третьих ресурсов. Например, авторизация с Oauth2: текстовое описание этого процесса весьма затруднительно для понимания. Здесь нам поможет Sequence diagram:

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

Когда вы углубитесь в изучение Sequence diagram вы обнаружите, что она позволяет отобразить циклы и ветвления, но не злоупотребляйте ими: не нужно на одной диаграмме рисовать ветки «Если пользователь выбрал локальную авторизацию, то» и «Если выбрал авторизацию FB, то», вместо этого нарисуйте две схемы под каждый вариант. Условия, особенно вложенные, на Sequence diagram очень сильно снижают читаемость схемы.

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

Но практическое применение у Class Diagram все же осталось — проектирование баз данных:

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

Не пытайтесь рисовать это в Visio, Enterprise Architect или аналогах. Для проектирования баз данных есть много специализированных инструментов, которые заточены под конкретные СУБД, пользуйтесь ими.

На этом все. Из всех диаграмм в UML и Archimate на практике более чем достаточно перечисленных. Сколько диаграмм каждого вида нужно для проекта? Рисовать ли их под каждый процесс и подсистему? Главное правило — диаграмма сопровождает текстовое описание, она нужна только там, где текста недостаточно, т.е. там, где команда вас не понимает.

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

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

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

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

Диаграмма последовательности: циклы, условия и тому подобное

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

Как было сказано, существуют дополнительные обозначения. И для циклов, и для условий используются фреймы взаимодействий (inter action frames), представляющие собой средство разметки диаграммы взаимодействия. На рис. 4.4 показан простой алгоритм, основанный на следующем псевдокоде.foreach (lineitem)if (product.value > $10K)careful.dispatchelseregular.dispatchend ifend forif (needsConfirmation) messenger.confirmend procedure

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

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

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

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

Есть несколько разных вещей, которые необходимо отобразить.

  • Вычислительные ресурсы. Это могут быть виртуальные машины, докеры, кластеры Kubernetes и облачные функции. Мобильные устройства и настольные компьютеры также можно рассматривать как вычислительные ресурсы.

  • Хранилища. Постоянные хранилища данных, такие как реляционные базы данных и базы данных nosql, хранилища двоичных файлов, таких как изображения, музыка и видео, хранилища больших данных и так далее.

  • Ресурсы обмена сообщениями. Установки Kafka / RabbitMQ, Google Cloud pub / sub, AWS SQS и другие.

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

  • Зоны доступности. Вы можете думать о них как о центрах обработки данных.

  • Узлы инфраструктуры. DNS-серверы, балансировщики нагрузки, брандмауэры, сети CDN

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

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

Диаграмма размещения компонентов системы

Рис. 2.4 Диаграмма размещения компонентов системы

На диаграмме размещения обозначены компоненты входящие в сервер машину FreeBSD для того чтобы система могла работать:

Фаервол ipfw служит для того чтобы открыть или перенаправить порты для работы системы.

Web – интерфейс обладающий элементами ввода данных и вывода сообщений.

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

Модуль Cron создает правила для работы пользователя, определяет время и закрывает рабочую сессию.

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

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

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

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

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

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

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

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

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

Контекстная диаграмма

Веб-сайт, посвященный модели С4 (Context, Container, Component and Code), довольно хорошо объясняет свои диаграммы, я же поделюсь своим представлением, как эта модель работает.

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

Моделирование взаимодействий

Взаимодействие между объектами в системе представляются диаграммами взаимодействия (interaction diagrams).

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

Диаграммы взаимодействия подразделяются на два основных типа диаграмм: диаграммы последовательности (sequence diagrams) и кооперативные диаграммы (collaboration diagrams). Эти диаграммы позволяют с разных точек зрения рассмотреть взаимодействие объектов в создаваемой системе.

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

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

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

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

Авторизация

Диаграмма последовательности для основного потока прецедента «Авторизация»

Рисунок 14. Диаграмма последовательности для основного потока прецедента «Авторизация»

Диаграмма кооперации для основного потока прецедента «Авторизация»

Рисунок 15. Диаграмма кооперации для основного потока прецедента «Авторизация»

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

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

Если же пароль и логин не соответствуют, то отображается сообщение об ошибке на форме авторизации, что показано на Рис. 16 и 17.

Диаграмма последовательности для альтернативного потока прецедента «Авторизация»

Рисунок 16. Диаграмма последовательности для альтернативного потока прецедента «Авторизация»

Диаграмма кооперации для альтернативного потока прецедента «Авторизация»

Рисунок 17. Диаграмма кооперации для альтернативного потока прецедента «Авторизация»

Восстановление пароля

Диаграмма последовательности для основного потока прецедента «Восстановление пароля»

Рисунок 18. Диаграмма последовательности для основного потока прецедента «Восстановление пароля»

Диаграмма кооперации для основного потока прецедента «Восстановление пароля»

Рисунок 19. Диаграмма кооперации для основного потока прецедента «Восстановление пароля»

Для этого прецедента тоже были добавлены 2 класса. Управляющий класс Восстановление и пограничный класс Форма восстановления.

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

Далее, если все данные введены правильно, класс Восстановление отправляет классу Пользователь сообщение, чтобы он проверил наличие введенного логина. В противном случае, отображается сообщение об ошибке, как показано на Рис. 20 Класс Пользователь проверяет наличие принятого логина в базе и, если он найден, отправляет классу Восстановление номер телефона, к которому он привязан. Если же нет, то отображается сообщение об ошибке (см. Рис. 22 и 23).

Диаграмма последовательности для первого альтернативного потока прецедента «Восстановление пароля»

Рисунок 20. Диаграмма последовательности для первого альтернативного потока прецедента «Восстановление пароля»

Диаграмма кооперации для первого альтернативного потока прецедента «Восстановление пароля»

Рисунок 21. Диаграмма кооперации для первого альтернативного потока прецедента «Восстановление пароля»

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

Диаграмма последовательности для второго альтернативного потока прецедента «Восстановление пароля»

Рисунок 22. Диаграмма последовательности для второго альтернативного потока прецедента «Восстановление пароля»

Диаграмма кооперации для второго альтернативного потока прецедента «Восстановление пароля»

Рисунок 23. Диаграмма кооперации для второго альтернативного потока прецедента «Восстановление пароля»

Диаграмма последовательности для третьего альтернативного потока прецедента «Восстановление пароля»

Рисунок 24. Диаграмма последовательности для третьего альтернативного потока прецедента «Восстановление пароля»

Диаграмма кооперации для третьего альтернативного потока прецедента «Восстановление пароля»

Рисунок 25. Диаграмма кооперации для третьего альтернативного потока прецедента «Восстановление пароля»

Диаграмма последовательности для четвертого альтернативного потока прецедента «Восстановление пароля»

Рисунок 26. Диаграмма последовательности для четвертого альтернативного потока прецедента «Восстановление пароля»

Диаграмма кооперации для четвертого альтернативного потока прецедента «Восстановление пароля»

Рисунок 27. Диаграмма кооперации для четвертого альтернативного потока прецедента «Восстановление пароля»

Так же пользователь может на любом из шагов отменить восстановление пароля (см. Рис. 28-31).

Диаграмма последовательности для прецедента «Восстановление пароля» при отмене на этапе ввода логина и пароля

Рисунок 28. Диаграмма последовательности для прецедента «Восстановление пароля» при отмене на этапе ввода логина и пароля

Диаграмма кооперации для прецедента «Восстановление пароля» при отмене на этапе ввода логина и пароля

Рисунок 29. Диаграмма кооперации для прецедента «Восстановление пароля» при отмене на этапе ввода логина и пароля

Диаграмма последовательности для прецедента «Восстановление пароля» при отмене на этапе ввода кода восстановления

Рисунок 30. Диаграмма последовательности для прецедента «Восстановление пароля» при отмене на этапе ввода кода восстановления

Диаграмма последовательности для прецедента «Восстановление пароля» при отмене на этапе ввода кода восстановления

Рисунок 31. Диаграмма последовательности для прецедента «Восстановление пароля» при отмене на этапе ввода кода восстановления

Поиск ресурсов

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

Возможно так же, что будет введен критерий, которому нет соответствий в базе. Тогда на Форме поиска будет отображено сообщение о том, что поиск не дал результатов (см. Рис 34 и 35).

Диаграмма последовательности для основного потока прецедента «Поиск ресурсов»

Рисунок 32. Диаграмма последовательности для основного потока прецедента «Поиск ресурсов»

Диаграмма кооперации для основного потока прецедента «Поиск ресурсов»

Рисунок 33. Диаграмма кооперации для основного потока прецедента «Поиск ресурсов»

Диаграмма последовательности для альтернативного потока прецедента «Поиск ресурсов»

Рисунок 34. Диаграмма последовательности для альтернативного потока прецедента «Поиск ресурсов»

Диаграмма последовательности для альтернативного потока прецедента «Поиск ресурсов»

Рисунок 35. Диаграмма последовательности для альтернативного потока прецедента «Поиск ресурсов»

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

Диаграмма последовательности для прецедента «Поиск ресурсов» при условии уточнения запроса

Рисунок 36. Диаграмма последовательности для прецедента «Поиск ресурсов» при условии уточнения запроса

Диаграмма кооперации для прецедента «Поиск ресурсов» при условии уточнения запроса

Рисунок 37. Диаграмма кооперации для прецедента «Поиск ресурсов» при условии уточнения запроса

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

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

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

Диаграммы взаимодействий для сортировки по релевантности и по дате обновления представлены на Рис. 38-39 и 40-41 соответственно.

Диаграмма последовательности для прецедента «Поиск ресурсов» при условии сортировки по релевантности

Рисунок 38. Диаграмма последовательности для прецедента «Поиск ресурсов» при условии сортировки по релевантности

Диаграмма кооперации для прецедента «Поиск ресурсов» при условии сортировки по релевантности

Рисунок 39 . Диаграмма кооперации для прецедента «Поиск ресурсов» при условии сортировки по релевантности

Диаграмма последовательности для прецедента «Поиск ресурсов» при условии сортировки по дате обновления

Рисунок 40. Диаграмма последовательности для прецедента «Поиск ресурсов» при условии сортировки по дате обновления

Диаграмма кооперации для прецедента «Поиск ресурсов» при условии сортировки по дате обновления

Рисунок 41. Диаграмма кооперации для прецедента «Поиск ресурсов» при условии сортировки по дате обновления

Просмотр информации о пользователях

Так как в проектируемой системе два типа пользователя с различными правами (пользователь может просматривать и редактировать только свою личную информацию, а администратор может просматривать учетные записи всех пользователей без возможности редактирования, но может их блокировать), то для каждого из них была создана отдельная форма просмотра, пользовательская и администраторская. Для пользователя имеет место добавить форму редактирования личных данных, а так же управляющие классы Редактирование личных данных и Управление просмотром. А для администратора создается Управляющий класс Блокировка. Так же целесообразно ввести форму выбора действия для исключения возможных «случайных» блокировок пользователей.

Диаграмма последовательности для основного потока прецедента «Просмотр информации о пользователях» для обычного пользователя

Рисунок 42. Диаграмма последовательности для основного потока прецедента «Просмотр информации о пользователях» для обычного пользователя

Диаграмма кооперации для основного потока прецедента «Просмотр информации о пользователях» для обычного пользователя

Рисунок 43. Диаграмма кооперации для основного потока прецедента «Просмотр информации о пользователях» для обычного пользователя

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

Если при вводе изменений, какие-то поля остались незаполненными, система класс Редактирование личных данных отображает сообщение об ошибке на форму редактирования личных данных (см. Рис. 44-45).

Диаграмма последовательности для альтернативного потока прецедента «Просмотр информации о пользователях» для обычного пользователя

Рисунок 44. Диаграмма последовательности для альтернативного потока прецедента «Просмотр информации о пользователях» для обычного пользователя

Диаграмма кооперации для альтернативного потока прецедента «Просмотр информации о пользователях» для обычного пользователя

Рисунок 45. Диаграмма кооперации для альтернативного потока прецедента «Просмотр информации о пользователях» для обычного пользователя

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

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

Если все-таки блокировка подтверждена, то с формы просмотра данных пользователя к классу Блокировка передается логин блокируемого и его e-mail. Пользователю с этим логином блокируется доступ к просмотру ресурсов с присвоением атрибуту Блокировка класса Пользователь значения 1(«заблокирован»), а на e-mail отправляется информация о том, что его владелец заблокирован. После выполнения указанных действий отображается Администраторская форма просмотра.

Как было сказано ранее, администратор может так же отменить блокировку. Если это произошло, то без внесения каких-либо изменений отображается форма просмотра данных пользователя.

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

Диаграмма последовательности для основного потока прецедента «Просмотр информации о пользователях» для администратора

Рисунок 46. Диаграмма последовательности для основного потока прецедента «Просмотр информации о пользователях» для администратора

Диаграмма кооперации для основного потока прецедента «Просмотр информации о пользователях» для администратора

Рисунок 47. Диаграмма кооперации для основного потока прецедента «Просмотр информации о пользователях» для администратора

Диаграмма последовательности для основного потока прецедента «Просмотр информации о пользователях» для администратора с блокировкой

Рисунок 48. Диаграмма последовательности для основного потока прецедента «Просмотр информации о пользователях» для администратора с блокировкой

Диаграмма кооперации для основного потока прецедента «Просмотр информации о пользователях» для администратора с блокировкой

Рисунок 49. Диаграмма кооперации для основного потока прецедента «Просмотр информации о пользователях» для администратора с блокировкой

Диаграмма последовательности для основного потока прецедента «Просмотр информации о пользователях» для администратора с отменой блокировки

Рисунок 50. Диаграмма последовательности для основного потока прецедента «Просмотр информации о пользователях» для администратора с отменой блокировки

Диаграмма кооперации для основного потока прецедента «Просмотр информации о пользователях» для администратора с отменой блокировки

Рисунок 51. Диаграмма кооперации для основного потока прецедента «Просмотр информации о пользователях» для администратора с отменой блокировки

Просмотр ресурсов

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

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

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

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

При выборе продолжения, вызывается функция CRUD ресурсов (о ней будет рассказано позже), которая принимает информацию, необходимую для удаления ресурса (Код ресурса), и отправляет ее классу Ресурс для выполнения операции.

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

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

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

Диаграмма последовательности для основного потока прецедента «Просмотр ресурсов» для обычного пользователя

Рисунок 52 . Диаграмма последовательности для основного потока прецедента «Просмотр ресурсов» для обычного пользователя

Диаграмма кооперации для основного потока прецедента «Просмотр ресурсов» для обычного пользователя

Рисунок 53. Диаграмма кооперации для основного потока прецедента «Просмотр ресурсов» для обычного пользователя

Диаграмма последовательности для основного потока прецедента «Просмотр ресурсов» для администратора

Рисунок 54 . Диаграмма последовательности для основного потока прецедента «Просмотр ресурсов» для администратора

Диаграмма кооперации для основного потока прецедента «Просмотр ресурсов» для администратора

Рисунок 55. Диаграмма кооперации для основного потока прецедента «Просмотр ресурсов» для администратора

Диаграмма последовательности для основного потока прецедента «Просмотр ресурсов» для администратора с удалением

Рисунок 56. Диаграмма последовательности для основного потока прецедента «Просмотр ресурсов» для администратора с удалением

Диаграмма кооперации для основного потока прецедента «Просмотр ресурсов» для администратора с удалением

Рисунок 57. Диаграмма кооперации для основного потока прецедента «Просмотр ресурсов» для администратора с удалением

Диаграмма последовательности для основного потока прецедента «Просмотр ресурсов» для администратора с отменой удаления

Рисунок 58. Диаграмма последовательности для основного потока прецедента «Просмотр ресурсов» для администратора с отменой удаления

Диаграмма кооперации для основного потока прецедента «Просмотр ресурсов» для администратора с отменой удаления

Рисунок 59. Диаграмма кооперации для основного потока прецедента «Просмотр ресурсов» для администратора с отменой удаления

Регистрация

Регистрация инициируется пользователем с формы авторизации. Отображается форма регистрации, в которую пользователь должен ввести свои данные. После того как все поля заполнены, активируется кнопка регистрация. Пользователь запускает регистрацию. Управление переходит к управляющему классу Регистрация, созданному специально для данного прецедента. Этот класс проверяет корректность ввода данных и, если все нормально, проверяет номер телефона, введенный пользователем на повторение с помощью класса Пользователь. Если номер не повторяется, то класс Пользователь разрешает регистрацию новой учетной записи классу Регистрация. Тот в свою очередь генерирует и отправляет на указанный телефон код активации и отображает форму активации. В нее вводится код активации. После заполнения поля, на форме активируется кнопка «Активировать». Пользователь активирует учетную запись. С формы активации к классу Регистрация передается введенный код активации и ,если он совпадает с сгенерированным, отправляет введенные пользователем данные при регистрации классу Пользователь, для создания нового объекта класса. После того, как новая запись сохранена, отображается форма авторизации. На каждом из этих этапов (создание и активация учетной записи) регистрация может быть отменена. В любом случае после отмены отображается форма авторизации.

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

Диаграмма последовательности для основного потока прецедента «Регистрация»

Рисунок 60. Диаграмма последовательности для основного потока прецедента «Регистрация»

Диаграмма кооперации для основного потока прецедента «Регистрация»

Рисунок 61. Диаграмма кооперации для основного потока прецедента «Регистрация»

Диаграмма последовательности для первого альтернативного потока прецедента «Регистрация»

Рисунок 62. Диаграмма последовательности для первого альтернативного потока прецедента «Регистрация»

Диаграмма кооперации для первого альтернативного потока прецедента «Регистрация»

Рисунок 63. Диаграмма кооперации для первого альтернативного потока прецедента «Регистрация»

Диаграмма последовательности для второго альтернативного потока прецедента «Регистрация»

Рисунок 64. Диаграмма последовательности для второго альтернативного потока прецедента «Регистрация»

Диаграмма кооперации для второго альтернативного потока прецедента «Регистрация»

Рисунок 65. Диаграмма кооперации для второго альтернативного потока прецедента «Регистрация»

Диаграмма последовательности для третьего альтернативного потока прецедента «Регистрация»

Рисунок 66. Диаграмма последовательности для третьего альтернативного потока прецедента «Регистрация»

Диаграмма кооперации для третьего альтернативного потока прецедента «Регистрация»

Рисунок 67. Диаграмма кооперации для третьего альтернативного потока прецедента «Регистрация»

Диаграмма последовательности для четвертого альтернативного потока прецедента «Регистрация»

Рисунок 68. Диаграмма последовательности для четвертого альтернативного потока прецедента «Регистрация»

Диаграмма кооперации для четвертого альтернативного потока прецедента «Регистрация»

Рисунок 69. Диаграмма кооперации для четвертого альтернативного потока прецедента «Регистрация»

Диаграмма последовательности для основного потока прецедента «Регистрация» с отменой на стадии создания учетной записи

Рисунок 70. Диаграмма последовательности для основного потока прецедента «Регистрация» с отменой на стадии создания учетной записи

Диаграмма кооперации для основного потока прецедента «Регистрация» с отменой на стадии создания учетной записи

Рисунок 71. Диаграмма кооперации для основного потока прецедента «Регистрация» с отменой на стадии создания учетной записи

Диаграмма последовательности для основного потока прецедента «Регистрация» с отменой на стадии активации

Рисунок 72. Диаграмма последовательности для основного потока прецедента «Регистрация» с отменой на стадии активации

Диаграмма кооперации для основного потока прецедента «Регистрация» с отменой на стадии активации

Рисунок 73. Диаграмма кооперации для основного потока прецедента «Регистрация» с отменой на стадии активации

CRUD ресурсов

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

Добавление ресурса.

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

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

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

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

Если же пользователь выбрал отмену сохранения ресурса, то после формы выбора действия отображается форма просмотра ресурсов добавленных пользователем.

Диаграмма последовательности для основного потока прецедента «CRUD ресурсов» при добавлении нового ресурса

Рисунок 74. Диаграмма последовательности для основного потока прецедента «CRUD ресурсов» при добавлении нового ресурса

Диаграмма кооперации для основного потока прецедента «CRUD ресурсов» при добавлении нового ресурса

Рисунок 75. Диаграмма кооперации для основного потока прецедента «CRUD ресурсов» при добавлении нового ресурса

Диаграмма последовательности для основного потока прецедента «CRUD ресурсов» при отмене сохранения нового ресурса

Рисунок 76. Диаграмма последовательности для основного потока прецедента «CRUD ресурсов» при отмене сохранения нового ресурса

Диаграмма кооперации для основного потока прецедента «CRUD ресурсов» при отмене сохранения нового ресурса

Рисунок 77. Диаграмма кооперации для основного потока прецедента «CRUD ресурсов» при отмене сохранения нового ресурса

Диаграмма последовательности для основного потока прецедента «CRUD ресурсов» при добавлении нового раздела

Рисунок 78. Диаграмма последовательности для основного потока прецедента «CRUD ресурсов» при добавлении нового раздела

Диаграмма кооперации для основного потока прецедента «CRUD ресурсов» при добавлении нового раздела

Рисунок 79. Диаграмма кооперации для основного потока прецедента «CRUD ресурсов» при добавлении нового раздела

Изменение информации о ресурсе

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

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

Диаграмма последовательности для основного потока прецедента «CRUD ресурсов» при изменении ресурса

Рисунок 80. Диаграмма последовательности для основного потока прецедента «CRUD ресурсов» при изменении ресурса

Диаграмма кооперации для основного потока прецедента «CRUD ресурсов» при изменении ресурса

Рисунок 81. Диаграмма кооперации для основного потока прецедента «CRUD ресурсов» при изменении ресурса

Диаграмма последовательности для основного потока прецедента «CRUD ресурсов» при отмене изменения ресурса

Рисунок 82. Диаграмма последовательности для основного потока прецедента «CRUD ресурсов» при отмене изменения ресурса

Диаграмма кооперации для основного потока прецедента «CRUD ресурсов» при отмене изменения ресурса

Рисунок 83. Диаграмма кооперации для основного потока прецедента «CRUD ресурсов» при отмене изменения ресурса

Удаление ресурса

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

Если же пользователь выбрал отмену удаления, то система отображает обратно форму просмотра ресурсов добавленных пользователем.

Диаграмма последовательности для основного потока прецедента «CRUD ресурсов» при удалении ресурса

Рисунок 84. Диаграмма последовательности для основного потока прецедента «CRUD ресурсов» при удалении ресурса

Диаграмма кооперации для основного потока прецедента «CRUD ресурсов» при удалении ресурса

Рисунок 85. Диаграмма кооперации для основного потока прецедента «CRUD ресурсов» при удалении ресурса

Диаграмма последовательности для основного потока прецедента «CRUD ресурсов» при отмене удаления ресурса

Рисунок 86. Диаграмма последовательности для основного потока прецедента «CRUD ресурсов» при отмене удаления ресурса

Диаграмма кооперации для основного потока прецедента «CRUD ресурсов» при отмене удаления ресурса

Рисунок 87. Диаграмма кооперации для основного потока прецедента «CRUD ресурсов» при отмене удаления ресурса

Выход из системы

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

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

Если же была выбрана отмена, то система возвращается на главную форму.

Диаграммы последовательности и кооперации для данного прецедента представлены на рисунках 88-91.

Диаграмма последовательности для основного потока прецедента «Выход из системы»

Рисунок 88. Диаграмма последовательности для основного потока прецедента «Выход из системы»

Диаграмма кооперации для основного потока прецедента «Выход из системы»

Рисунок 89. Диаграмма кооперации для основного потока прецедента «Выход из системы»

Диаграмма последовательности для основного потока прецедента «Выход из системы» при отмене выхода

Рисунок 90. Диаграмма последовательности для основного потока прецедента «Выход из системы» при отмене выхода

Диаграмма кооперации для основного потока прецедента «Выход из системы» при отмене выхода

Рисунок 91. Диаграмма кооперации для основного потока прецедента «Выход из системы» при отмене выхода

Последовательное получение доступа и проверка авторизации

Диаграмма последовательности получения доступа и проверки данных авторизации

Рис. 2.3 Диаграмма последовательности получения доступа и проверки данных авторизации

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

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

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

Для того чтобы начать обсуждение метода «Диаграмма последовательности» UML (ЮМЛ), рассмотрим простой сценарий.

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

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

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

Однако диаграмма не все показывает так хорошо. Последовательность сообщений getQuantity, getProduct, getPricingDetails и calculateBasePrice должна быть реализована для каждой строки заказа, тогда как метод calculateDiscounts вызывается лишь однажды.

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

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

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

Проектирование архитектуры

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

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

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

Для каждой подсистемы потребуется Архитектурная схема, как ее правильно нарисовать? В UML для этого нет подходящих диаграмм, давайте посмотрим на Archimate:

Даже без знания нотации схема, в целом, читаема. Помните, что 90% участников вашей команды не знают ни UML, ни тем более Archimate, и никогда не выучат эти нотации, поэтому делайте упор на надписи. Тем не менее, пара слов о кубиках и стрелочках:

Полную спецификацию Archimate вы найдете без труда.

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

На схеме используется всего два вида стрелок: Flow (Поток) и Access (Вызов, Доступ). Поток показывает направление передачи данных, а Вызов — кто к кому обращается. Следует правильно понимать стрелку Поток:

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

Создание и удаление участников

В диаграммах последовательности для создания и удаления участников применяются некоторые дополнительные обозначения (рис. 4.3).

В случае создания участника надо нарисовать стрелку сообщения, направленную к прямоугольнику участника. Если применяется конструктор, то имя сообщения не обязательно, но обычно маркируем его словом «new» в любом случае. Если участник выполняет что -нибудь непосредственно после создания, например команду запроса, то надоначать активацию сразу после прямоугольника участника.

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

Техническое задание

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

Самая простая диаграмма — Use Case (Варианты использования):

На диаграмме указаны виды пользователей и перечислены функции или группы функций, которые с ними связаны. Синим цветом выделен элемент, которого в UML нет, но его часто не хватает: Requirement — Требование (из нотации Archimate), уточнение функций.

Вы спросите — и какой в этом смысл? Ведь перечень функций можно указать просто текстом, одним компактным списком! И будете правы, но есть нюансы.

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

Почему мы смешали на одной диаграмме UML и Archimate? Не нужно строго следовать нотациям, вам с этим не экзамены сдавать в университете, а с командой общаться, для которой вы это все и готовите.

Почему для связи элементов мы использовали линии, а не стрелки? Потому что никто не помнит, как выглядят стрелки «Обобщение» и «Расширение», и что они вообще такое. Чем проще вы нарисуете, тем больше людей поймет диаграмму без вашего участия.

Второй вид диаграмм, который вы можете встретить в техническом задании, это Activity diagram:

Здесь для разработчика все очевидно, кроме одного: почему AI делает вызовы Студента? Не делает. Эту диаграмму рисуют аналитики, а не программисты, они не знают где клиент, а где сервер, и их не интересуют потоки данных. На Activity diagram вы видите последовательность действий и не более того. Как же из этого сделать код? Переходим к этапу проектирования.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *