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

Какова будет статическая структура системы?

На этот вопрос вам помогут ответить сразу несколько типов моделей:

  • Диаграммы классов (Class diagrams) необходимы для представления статической структуры модели системы в терминологии классов объектно-ориентированного программирования. Отражает объекты и подсистемы, а также взаимосвязи между отдельными сущностями предметной области.
  • Диаграммы объектов (Object diagrams) показывают множество объектов, их состояния и отношения между ними в данный момент состояния системы.
  • Диаграммы компонентов (Component diagrams) отражает разбиение программной системы на структурные компоненты и связи (зависимости) между компонентами
  • Диаграммы развертывания (Deployment diagrams) показывает топологию системы и распределение компонентов системы по ее узлам, а также соединения — маршруты передачи информации между аппаратными узлами.

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

Каково будет поведение вашей системы?

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

  • Диаграмма деятельности (Activity diagram) предназначена для моделирования процесса выполнения операций, а также отображения потоки данных между ними, а также возможные их синхронизации друг с другом.
  • Диаграмма состояний (State diagram) необходима для иллюстрирования возможных состояний отдельных компонентов или системы в целом, переходы между ними в ответ на какие-либо события и выполняемые при этом действия.
  • Диаграмма вариантов использования (Use case diagram) описывают функциональное назначение системы, контекст и концепцию системы.

Как будет происходить взаимодействие с системой?

Ответом на этот вопрос послужат:

  • Диаграмма коммуникации или взаимодействия (Communication diagram /collaboration diagram) отражает взаимодействия между частями структуры или ролями кооперации. В отличие от диаграммы последовательности на диаграмме коммуникации явно указываются отношения между элементами (объектами), а время как отдельное измерение не используется.
  • Диаграмма последовательности (Sequence diagram) представляет взаимодействия объектов, упорядоченные по времени их проявления

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

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