Опубликовано вUnified Modeling Language Use Case Modeling

Упрощение крупных диаграмм вариантов использования с помощью отношений включения

Введение

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

Что такое отношение включения?

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

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

Преимущества отношений включения

Отношения включения предлагают несколько преимуществ при моделировании крупных и сложных систем:

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

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

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

  4. Улучшенная ясность и поддерживаемость: За счет разделения обязанностей базовый вариант использования фокусируется на своем уникальном поведении, а включенные варианты использования отвечают за повторно используемые последовательности, упрощая обновления.

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

Примеры отношений включения

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

Пример 1: Система электронной коммерции

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

  • Базовые варианты использования: «Покупка продукта», «Бронирование предмета», «Подарок предмета»

  • Включённый вариант использования: «Аутентификация пользователя»

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

  • Пунктирная стрелка от «Покупка продукта» к «Аутентификация пользователя» с обозначением «включает».

  • Подобные стрелки от «Бронирование предмета» и «Подарок предмета» к «Аутентификация пользователя».

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

Пример 2: Банковская система

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

  • Базовые варианты использования: «Снять наличные», «Положить деньги», «Перевести средства»

  • Включённый вариант использования: «Проверка счета»

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

Пример 3: Система управления библиотекой

В системе библиотеки пользователи могут «Взять книгу», «Вернуть книгу» или «Забронировать книгу». Каждое из этих действий требует проверки доступности книги.

  • Базовые варианты использования: «Взять книгу», «Вернуть книгу», «Забронировать книгу»

  • Включённый вариант использования: «Проверка доступности книги»

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

Пример 4: Система управления больницей

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

  • Базовые варианты использования: «Запланировать приём», «Отменить приём», «Перепланировать приём»

  • Включённый вариант использования: «Проверка личности пациента»

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

Пример 5: Платформа электронного обучения

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

  • Базовые варианты использования: «Пройти тест», «Сдать задание», «Посмотреть оценки»

  • Включённый вариант использования: «Войти»

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

Визуальное представление в UML

В диаграммах вариантов использования UML отношение include изображается следующим образом:

  • Стрелка пунктирная стрелка с открытым наконечником указывает от базового варианта использования к включённому варианту использования.

  • Стрелка помечена стереотипом«include».

Например, в примере онлайн-покупок:

  • Покупка товара → «include» → Аутентификация пользователя

  • Диаграмма ясно показывает, что «Аутентификация пользователя» является обязательной частью процесса «Покупка товара».

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

Сравнение с отношениями extend

Следует отметить различие междуinclude и extend отношениями, чтобы избежать путаницы:

  • Include: Включённый вариант использования являетсявсегда выполняется как часть базового варианта использования (обязательно).

  • Расширить: расширяющий вариант использования — этонеобязательный и выполняется только при определенных условиях.

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

Лучшие практики использования связей включения

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

  1. Определите общие поведения: Ищите последовательности действий, повторяющиеся в нескольких вариантах использования, например, аутентификацию, проверку или логирование.

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

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

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

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

Обзор преимуществ

В следующей таблице приведены основные преимущества связей включения:

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

Объяснение

Повторное использование общего поведения

Извлекает общую функциональность для предотвращения дублирования между вариантами использования

Упрощение сложных вариантов использования

Разбивает крупные варианты использования на более мелкие, управляемые части

Обязательное выполнение

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

Модульность и ясность

Разделяет обязанности, улучшая читаемость и поддерживаемость

Структурированное моделирование

Похоже на вызов подпрограмм, поддерживает иерархический дизайн

Заключение

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

Справочник