Лекция 8: Диаграммные техники в работе со знаниями

Метод случаи использования:

Случаи или варианты использования (usecases) были предложены в конце 90-х годов Айвером Якобсоном, одним из главных авторов языка UML, как диаграммный подход для извлечения и первичной формализации требований к системам.

Необходимо извлечь требования из всех возможных источников, формализовать в некотором виде и обсудить. Этот процесс – извлечение, формализация, обсуждение – итеративен, то есть все делается не за один присест. Более того, сам способ формализации должен быть удобен для обсуждения, и в первую очередь, с потенциальными пользователями системы, которые могут быть совершенно не компетентны в IT. Их комментарии, одобрения и несогласия часто являются основой итеративного извлечения требований к системе. Кроме того, этот способ работы с информацией должен вести к созданию моделей, удобных в дальнейшей реализации системы. Другими словами, ясно формулировать исходные задачи для разработки. То есть способ формализации должен быть прост, понятен и обладать достаточной строгостью. Этим требованиям удовлетворяют диаграммы случаев использования, являющиеся на сегодняшний день составной частью стандарта UML.

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

- типовых пользователей — работников компании, сгруппированных по исполняемым обязанностям;

- другие системы, взаимодействующие с данной;

- выделенного пользователя.

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

2. После идентификации пользователей происходит определение случаев использования ими системы.

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

Итак, случай использования (usecase) — это независимая часть функциональности системы, обладающая результирующей ценностью для ее пользователей.

"Независимость" означает, что если случай использования всегда исполняется вместе снекоторым другим, то, по всей видимости, один из них нужно включить в другой.

"Результирующая ценность" случая использования для актера системы подразумевает, что он, данный случай использования, должен приносить актеру некоторый законченный и ценный с точки зрения его бизнеса результат. Будучи реализован системой, этот случай использования действительно делает бизнес актера эффективнее, производительнее. Тем самым разработка системы фокусируется на бизнес-целях, а незначительные случаи использования игнорируются, что важно для компактности модели. Ведь строится не абстрактная модель функций системы, а набор самых важных (для заказчика и пользователей) сервисов, чтобы каждый из них правильно понять и не один не упустить.

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

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

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

Случаи использования в управлении разработкой.

Диаграммы случаев использования могут быть полезны при выявлении первичной формализации требований. Но они могут оказаться полезными и после того, как этот процесс завершен. Результирующие диаграммы случаев использования можно применять при управлении разработкой. Менеджер проекта может отслеживать прогресс проекта по тому, сколько реализовано функциональности, необходимой пользователю. Разработчики могут иметь диаграммы случаев использования где-то перед глазами, чтобы не забывать об основной цели разработки. Эти же диаграммы могут использоваться в рабочих встречах по проекту.

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