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

Введение

В инженерии программного обеспечения диаграммы вариантов использования помогают визуализировать взаимодействия между пользователями (актерами) и системой для фиксации ее функциональных требований. По мере масштабирования систем диаграммы вариантов использования могут стать неуправляемыми, заполненными повторяющимися или сложными поведениями, которые затрудняют понимание основной функциональности системы. Отношениевключения в 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, позволяя повторно использовать и модульно организовывать общие, обязательные поведения. Извлекая общую функциональность в включаемые случаи использования, разработчики могут создавать более чистые, поддерживаемые диаграммы, которые легче понять и обновить. Приведенные примеры — от онлайн-покупок до управления больницей — демонстрируют универсальность связей включения в различных областях. Используя этот механизм, команды могут моделировать сложные системы с большей ясностью и эффективностью, в конечном итоге повышая качество своих проектов программного обеспечения.

Справочник

• Документирование деталей случаев использования в Visual Paradigm
  Руководство по редактированию и просмотру деталей случаев использования в Visual Paradigm.
• Как нарисовать диаграмму случаев использования? – Visual Paradigm
  Пошаговые инструкции по созданию диаграмм случаев использования UML с помощью Visual Paradigm.
• Что такое диаграмма случаев использования? – Visual Paradigm
  Обзор диаграмм случаев использования и их роли в моделировании поведения системы.
• Диаграмма случаев использования в Visual Paradigm
  Подробное объяснение элементов диаграммы случаев использования и способов документирования событий случаев использования.
• Руководство по нотациям диаграммы случаев использования – Visual Paradigm
  Полное руководство по нотациям диаграмм случаев использования UML, поддерживаемым в Visual Paradigm.
• Полное руководство по созданию диаграмм случаев использования с помощью Visual Paradigm
  Подробное руководство по определению участников, определению случаев использования и моделированию отношений в Visual Paradigm.
• Описание случаев использования в Visual Paradigm для UML – Angelfire
  Объясняет описание случаев использования, планирование, детализацию и генерацию документации в Visual Paradigm.
• Раскрытие модели случаев использования: соединение текстовых деталей и визуального понимания
  Обсуждает, как объединить текстовые детали случаев использования с визуальными диаграммами в Visual Paradigm.
• Диаграмма случаев использования – средство моделирования UML – Visual Paradigm
  Официальная страница Visual Paradigm, демонстрирующая функции диаграммы случаев использования и поддержку нотаций.