Как описать программную систему в UML-диаграммах: от Use Case до состояний + краткий ликбез по ООП

автор
Как описать программную систему в UML-диаграммах: от Use Case до состояний + краткий ликбез по ООП

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

Границы системы, акторы и варианты использования: что такое диаграмма Use Case

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

В качестве иллюстративного примера рассмотрим систему онлайн-оплаты учебного курса. Пользователем этой системы является клиент. В терминологии UML он будет называться актор – сущность за пределами системы, которая взаимодействует с ней. На UML-диаграмме Use Case он изображается в виде человечка. Актору «Клиент» доступен основной вариант использования – «Оплатить договор» (на проведение обучающего курса по бизнес-анализу).  Расширением этого варианта использования является «Оплатить со скидкой по промокоду», который уменьшает сумму платежа. Этот вариант использования является опциональным и расширяет основной, поэтому он будет связан с основным через связь extend, которая выглядит как пунктирная стрелочка с соответствующей надписью.

UML use case diagram example, обучение UML, пример UML диаграммы вариантов использования, обучение UML, курсы по UML, тренинг по UML
Пример UML-диаграммы вариантов использования (Use Case)

Далее следует детализировать, как именно выполняется процесс оплаты, раскрыв прецедент со схемы Use Case на UML-диаграмме последовательности. Однако, чтобы сделать это с привязкой к внутренним сущностям нашей программной системы, классам, следует сперва описать их на UML-диаграмме классов. Как это сделать, мы рассмотрим далее.

Ликбез по ООП или как построить UML-диаграмму классов

UML соответствует объектно-ориентированной парадигме программирования (ООП), ключевым понятием которой является класс. Класс – это абстракция сущностей с одинаковыми свойствами (атрибутами, полями) и поведением (методами, функциями). Классы могут быть связаны друг с другом через наследование и ассоциации. При наследовании класс-потомки имеют (наследуют) атрибуты и методы класса-родителя, а также свои собственные. А конкретные значения этих атрибутов задаются в реализации классов в виде их отдельных экземпляров, называемых объектами. Например, ООО «Рога и Копыта» и Иванов Иван Иваныч – это конкретные реализации классов «Юрлицо» и «Физлицо» соответственно. В частности, у объекта класса Физлицо есть поля с паспортными данными (ФИО и № паспорта), а у юрлица обязательно должны быть название и ИНН. При этом оба этих класса наследуют от родителя (Класс «Клиент») общие для них атрибуты (тип, номер телефона, email и адрес).

Ассоциация означает логическую связь между объектами разных классов. Например, договор на обучение связан с курсом. Поскольку в договоре нужно обязательно указать курс, эти классы будут связаны не простой ассоциацией, а ее более сложным вариантом – агрегацией. В этом случае у класса, который является целым, появится значок в виде незакрашенного ромбика. Если связь между объектами разных классов настолько сильная, что при уничтожении целого, уничтожаются и его части, ромбик будет закрашенным. Такая связь называется композицией и является самым сильным вариантом ассоциации. Можно также указать кратность связи, к примеру, в 1-м договоре на обучение могут быть указаны сразу несколько курсов. При этом над концами связи отобразятся мультипликаторы, обозначающие ее кратность.

Таким образом, в нашей системе интернет-оплаты договора с применением промокода по конкретному курсу будут следующие классы:

  • Клиент – абстрактный класс-родитель для классов «Юрлицо» и «Физлицо»;
  • Физлицо;
  • Юрлицо;
  • Договор;
  • Курс;
  • Промокод;
  • Платеж.

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

UML class diagram example, обучение UML, пример UML диаграммы классов, обучение UML, курсы по UML, тренинг по UML
Пример UML-диаграммы классов

Теперь, имея диаграмму классов, которая на концептуальном уровне описывает доменную область проектируемой системы, можно показать, как объекты разных классов взаимодействуют друг с другом на UML-диаграмме последовательности (Sequence).

UML sequence diagram, проектирование UML, курсы по UML, тренинг по UML, как построить UML-диаграмму последовательности пример
Пример UML диаграммы последовательности

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

А в заключение покажем, как выглядит жизненный цикл объектов класса «Промокод» с помощью UML-диаграммы состояний (StateChart или State Machine). На мой взгляд, из всех UML-диаграмм она самая простая и понятная без дополнительных объяснений. Начиная со стартового события, объект последовательно проходит разные стадии жизненного цикла, меняя свое состояние в зависимости от некоторых условий.

UML state diagram, проектирование UML, курсы по UML, тренинг по UML, как построить UML-диаграмму состояний пример
Пример UML-диаграммы состояний

Проверить свои знания UML вы можете прямо на нашем сайте, выполнив бесплатный интерактивный тест. А научиться самостоятельно разрабатывать эти и другие UML-диаграммы вам поможет специализированный курс «UML для бизнес-аналитиков». Только практика на реальных примерах. После 8-часового интенсива вы сможете дополнять текстовые схемы представления требований User Story и Use Case UML-диаграммами вариантов использования и детализировать их далее в диаграммы деятельности, последовательности и состояний, чтобы наглядно объяснить разработчикам, что именно должна делать программная система.

 

Комментировать