Разработка программного обеспечения часто останавливается не из-за кода, а из-за коммуникации. Заинтересованные стороны описывают, что им нужно, на естественном языке, а разработчики переводят это в логику и структуру. Этот разрыв в переводе часто приводит к несоответствию. Надежный способ преодолеть этот разрыв — это унифицированный язык моделирования (UML). В частности, диаграмма случаев использования служит критически важным инструментом для визуального фиксирования функциональных требований.
Это руководство сопровождает вас через процесс преобразования необработанных требований в структурированные случаи использования UML. Вы узнаете, как определять участников, задавать границы системы и моделировать взаимодействия, не полагаясь на конкретные инструменты. Основное внимание уделяется концептуальному рабочему процессу и логике моделирования.
🧠 Понимание основ: инженерия требований
Прежде чем начертить одну линию, вы должны понять входные данные. Требования — это конкретные условия или возможности, которые система должна удовлетворять. В контексте UML мы в первую очередь фокусируемся на функциональных требованиях — что делает система, хотя нефункциональные ограничения влияют на проектирование.
Функциональные и нефункциональные требования
Крайне важно различать эти две категории на ранних этапах процесса.
- Функциональные требования: Они описывают конкретные поведения или функции. Примеры: «Система должна позволять пользователям сбрасывать пароли» или «Система должна рассчитывать налог на основе местоположения». Эти требования напрямую соответствуют случаям использования.
- Нефункциональные требования: Они описывают качества системы, такие как производительность, безопасность или надежность. Примеры: «Система должна отвечать в течение 2 секунд» или «Данные должны быть зашифрованы». Хотя эти требования напрямую не становятся случаями использования, они ограничивают способ реализации случаев использования.
При сборе требований проводите интервью с заинтересованными сторонами и изучайте документацию. Ищите глаголы и существительные. Глаголы часто указывают на действия (случаи использования), а существительные — на сущности (участников или данные).
🎭 Определение концепции случая использования
Случай использования представляет конкретную цель, которую пользователь или внешняя система достигает, взаимодействуя с программным обеспечением. Это не список шагов, а повествование о ценности. Один случай использования может включать множество шагов, но он представляет собой одну целостную цель.
Ключевые компоненты случая использования
Чтобы эффективно моделировать это, вам нужно понять основные элементы:
- Участник: Сущность, взаимодействующая с системой. Участники могут быть человеко-пользователями, другими программными системами или аппаратными устройствами.
- Граница системы: Прямоугольник, определяющий, что находится внутри системы, а что снаружи. Все, что взаимодействует с системой, но не находится внутри границы, является участником.
- Случай использования: Овал или скруглённый прямоугольник, представляющий функциональность.
- Ассоциация: Линия, соединяющая участника с случаем использования, указывающая на коммуникацию.
🚀 Пошаговый рабочий процесс моделирования
Создание модели случая использования — это систематический процесс. Следуйте этим шагам, чтобы обеспечить точность и полноту.
Шаг 1: Определите границу системы
Начните с определения охвата. Что входит в систему, а что внешнее? Нарисуйте большой прямоугольник, чтобы обозначить эту границу. Все, что приносит ценность участнику, должно находиться внутри этого прямоугольника. Все, что находится снаружи, — это ресурс или участник.
Шаг 2: Определите участников
Проанализируйте свои требования на предмет ролей. Кто выполняет работу? Создайте список различных ролей.
- Основные участники: Те, кто инициирует использование случая для достижения собственной цели (например, клиент, размещающий заказ).
- Второстепенные участники: Те, кто предоставляет услуги системе (например, платёжный шлюз).
Совет: Если два пользователя выполняют одинаковые действия и требуют одинаковых разрешений, объедините их в одну роль участника под названием «Пользователь» или «Администратор». Это сохранит диаграмму в порядке.
Шаг 3: Определение случаев использования
Ищите глаголы в своих требованиях. «Рассчитать», «Зарегистрировать», «Утвердить», «Создать». Каждое уникальное действие часто соответствует случаю использования. Назовите случай использования глагольной фразой.
- Пример: Вместо «Вход» используйте «Аутентификация пользователя». Вместо «Отчёт» используйте «Создание отчёта по продажам».
Шаг 4: Определение связей
Соедините участников с случаями использования. Если участник взаимодействует с случаем использования, проведите линию. Если несколько участников взаимодействуют с одним и тем же случаем использования, соедините всех их. Это визуализирует, кто что делает.
Шаг 5: Уточнение с помощью связей
Не все взаимодействия являются простыми ассоциациями. Вам может потребоваться показать, как случаи использования связаны между собой, используя специфические связи, такие какВключает и Расширяет.
| Тип связи | Символ | Значение | Пример |
|---|---|---|---|
| Включает | Стрелка с «включает» | Базовый случай использованиядолжениспользовать включённое поведение. | «Создать заказ» включает «Проверить корзину». |
| Расширяет | Стрелка с «расширяет» | Базовый случай использования можетиспользовать расширенное поведение при определенных условиях. | «Просмотр заказа» расширяется до «Показать ошибку», если данные отсутствуют. |
| Обобщение | Стрелка с треугольником | Наследование поведения между участниками или случаями использования. | «Админ» — это обобщение «Пользователь». |
📝 Подробный пример: Оформление заказа в электронной коммерции
Чтобы проиллюстрировать этот рабочий процесс, рассмотрим требование интернет-магазина: «Пользователи должны иметь возможность приобретать товары с помощью кредитной карты. Система должна проверять наличие товара на складе перед списанием средств. Если товара мало, пользователю необходимо сообщить об этом. Если товара нет, покупка невозможна.»
Вот как вы переводите этот текст в модель.
1. Извлечение участников
- Покупатель: Инициирует покупку.
- Система учета запасов: Внешняя система, подтверждающая уровень запасов.
2. Извлечение случаев использования
- Начать покупку: Основная цель.
- Проверить наличие на складе: Необходимо для каждой покупки.
- Обработать оплату: Основная транзакция.
- Уведомить о низком уровне запасов: Необязательное уведомление.
3. Определение связей
- Начать покупку включает Проверить наличие на складе (обязательный шаг).
- Начать покупку включает Обработать оплату (обязательный шаг).
- Уведомить о низком уровне запасов расширяет Начать покупку (условный).
Эта структура гарантирует, что логика рабочего процесса будет зафиксирована до написания какого-либо кода.
⚠️ Распространённые ошибки, которые следует избегать
Начинающие часто испытывают трудности с уровнем абстракции. Вот наиболее распространённые ошибки, которые снижают ценность вашей модели.
1. Моделирование задач вместо целей
Кейс использования должен представлять цель. «Нажать кнопку» — это задача, а не кейс использования. «Обновить профиль» — это цель. Если вы моделируете задачи, ваш диаграмма превращается в руководство пользователя, а не в спецификацию системы.
2. Смешивание уровней детализации
Не помещайте высокие бизнес-цели и низкие технические шаги в одну и ту же диаграмму. Если «Поиск продукта» — это кейс использования, внутренние шаги запроса базы данных не входят в эту диаграмму. Сохраняйте единообразие охвата.
3. Пренебрежение границей системы
Убедитесь, что актёры находятся за пределами рамки. Распространённая ошибка — рисование актёра внутри границы системы. Если актёр является частью логики системы, он не является актёром, а компонентом.
4. Чрезмерное использование включения и расширения
Эти отношения добавляют сложность. Используйте их только тогда, когда поведение действительно совместно используется или условно. Чрезмерное использование делает диаграмму трудной для чтения. Часто достаточно простой ассоциации или хорошо написанного описания кейса использования.
🔗 Следуемость: Связь требований с кейсами использования
Как только ваша диаграмма будет завершена, вы должны убедиться, что каждое требование имеет своё место. Это называется следуемостью. Это позволяет проверить, что ничего не было упущено на этапе анализа.
Создайте таблицу сопоставления, чтобы связать идентификаторы ваших требований с именами кейсов использования.
| Идентификатор требования | Текст требования | Сопоставленный кейс использования | Статус |
|---|---|---|---|
| ТР-001 | Система должна позволять пользователям регистрироваться. | Зарегистрировать пользователя | Сопоставлено |
| ТР-002 | Система должна проверять формат электронной почты. | Регистрация пользователя (включено) | Сопоставлено |
| ТРЕБ-003 | Система должна отправлять приветственное письмо. | Отправить приветственное письмо | Требуется сопоставление |
Если требование не имеет сопоставленного варианта использования, у вас есть пробел. Если вариант использования не имеет сопоставленного требования, возможно, произошло расширение области. Проверьте эти пробелы перед переходом к проектированию.
🛠️ Техники проверки
Как вы узнаете, что модель правильная? Используйте обходы и техники проверки.
1. Обходы с заинтересованными сторонами
Сядьте с владельцами бизнеса и пройдитесь по диаграмме. Попросите их описать сценарий. «Как я куплю рубашку?» Если они описывают процесс, которого нет на диаграмме, добавьте его. Если они описывают то, что там быть не должно, уберите это.
2. Проверки согласованности
Обеспечьте согласованность между диаграммами. Если ваша диаграмма вариантов использования показывает «Администратора» как участника, ваша диаграмма классов должна отражать эту роль. Если ваша диаграмма последовательности показывает другой поток, приведите их в соответствие. UML — это язык; все диаграммы должны использовать один и тот же синтаксис.
3. Проверка полноты
Убедитесь, что у всех участников есть хотя бы один вариант использования. Участник без соединений, как правило, ошибка. Убедитесь, что у всех вариантов использования есть хотя бы один участник. Вариант использования без участника — это функция без пользователя.
📈 Расширение рабочего процесса: от статического к динамическому
Диаграммы вариантов использования статичны. Они показывают структуру, а не поведение во времени. Чтобы полностью определить рабочий процесс, в конечном итоге вам понадобятся диаграммы последовательности или диаграммы деятельности. Однако диаграмма вариантов использования — это отправная точка.
Для каждого варианта использования на вашей диаграмме вы в конечном итоге должны написатьСпецификацию варианта использования. Этот документ описывает последовательность событий.
- Предусловия: Что должно быть верно до начала варианта использования? (например, пользователь авторизован).
- Основной поток: Путь успеха. Последовательность шагов, если всё идёт правильно.
- Альтернативные потоки: Что происходит, если что-то пойдёт не так? (например, неправильный пароль).
- Постусловия: Что верно после завершения варианта использования? (например, заказ создан).
Эта спецификация заполняет пробел между визуальной диаграммой и фактической логикой кода.
🎯 Рекомендуемые практики для начинающих
Чтобы сохранить ясность и авторитет в ваших моделях, придерживайтесь этих руководящих принципов.
- Держите всё просто:Диаграмма с 50 и более случаями использования, скорее всего, слишком большая. Разбейте её на части. Система с множеством функций может потребовать нескольких диаграмм (например, «Панель администратора» против «Портал клиента»).
- Используйте понятные имена:Используйте глаголы. Избегайте существительных. «Вход» лучше, чем «Экран входа». «Рассчитать налог» лучше, чем «Расчёт налога».
- Стандартизируйте нотацию:Придерживайтесь стандартных символов UML. Не изобретайте собственные формы. Это гарантирует, что любой, знакомый с UML, сможет прочитать вашу работу.
- Итерируйте:Ваша первая диаграмма не будет идеальной. Ожидайте, что вы будете её пересматривать по мере того, как будете лучше понимать требования. Модели — это живые документы.
🤝 Сотрудничество и обратная связь
Моделирование — это социальная деятельность. Делитесь своими черновиками как можно раньше. Не ждите конца, чтобы показать свою работу. Когда заинтересованные стороны видят свои требования визуализированными, они часто сразу осознают недопонимание. Это экономит значительное время и затраты на более поздних этапах разработки.
Поощряйте вопросы. Если заинтересованный участник выглядит озадаченным стрелкой связи, объясните её. Если он предлагает нового участника, добавьте его. Диаграмма принадлежит команде проекта, а не только аналитику.
📌 Краткое резюме ключевых выводов
Преобразование требований в случаи использования требует дисциплины и внимания к деталям. Следуя структурированному рабочему процессу, вы гарантируете, что разрабатываемое программное обеспечение соответствует потребностям пользователей.
- Определите участников:Кто взаимодействует с системой?
- Определите цели:Что каждый участник хочет достичь?
- Соотнесите связи:Как участники и случаи использования связаны между собой?
- Проверьте:Убедитесь, что все требования учтены.
- Итерируйте:Уточняйте модель по мере роста понимания.
Освоение этого рабочего процесса не происходит за один день, но постоянная практика формирует компетентность. Сосредоточьтесь на логике и ценности, которую вы предоставляете, и диаграммы сами по себе станут более ясными и эффективными инструментами коммуникации.
