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

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

Описание примера. В качестве примера рассмотрим "Телефонную службу приема заявок". Заказчиком данной системы является компания, владеющая сетью продуктовых магазинов. Эта компания, кроме обычной розничной торговли и оптовых поставок продуктов отдельным столовым и ресторанам, хочет предоставлять еще и сервис по обслуживанию клиентов по телефонным заявкам. Клиент регистрируется в компании, а потом по телефону, в удобное для себя время, делает заказ товаров, которые к нему привозят домой, и он расплачивается. Для этого компания хочет организовать у себя локальный телефонный центр, состоящий из офисной многоканальной АТС, штата операторов и соответствующего программного обеспечения. При этом в компании уже есть информационная система по обработке заявок от постоянных мелкооптовых клиентов, и заказываемая система должна быть с ней проинтегрирована.

Работа с требованиями. Случаи или варианты использования (use cases) были предложены в конце 90-х годов Айвером Якобсоном, одним из главных авторов языка UML, как диаграммный подход для извлечения и первичной формализации требований к системам. Выше уже говорилось о сложности по формированию единой и связной картины требований к ПО. Необходимо извлечь требования из всех возможных источников, формализовать в некотором виде и обсудить. Этот процесс – извлечение, формализация, обсуждение – итеративен, то есть все делается не за один присест. Более того, сам способ формализации должен быть удобен для обсуждения, и в первую очередь, с потенциальными пользователями системы, которые могут быть совершенно не компетентны в IT. Их комментарии, одобрения и несогласия часто являются основой итеративного извлечения требований к системе. Кроме того, этот способ работы с информацией должен вести к созданию моделей, удобных в дальнейшей реализации системы. Другими словами, ясно формулировать исходные задачи для разработки. То есть способ формализации должен быть прост, понятен и обладать достаточной строгостью. Этим требованиям удовлетворяют диаграммы случаев использования, являющиеся на сегодняшний день составной частью стандарта UML.

Пример диаграммы случаев использования представлен на рис. 8.1.

Рис. 8.1. Пример диаграммы случаев использования

Итак, все начинается с точной идентификации пользователей будущей системы. Это – основа хороших требований и хорошей системы, ведь основная задача системы – удовлетворять потребности будущих пользователей. Для этого нужно их знать в лицо….. В нашем случае пользователями системы являются оператор, менеджер и представители технической поддержки и администрирования. Система должна также поддерживать внешний интерфейс с системой обработки заявок. Это — четвертый пользователь. Еще одним пользователем системы является Петров А.Б. — директор департамента сбыта товаров, который хочет периодически отслеживать деятельность телефонной службы приема заявок. Для него создано специальное пользовательское место с экранными формами статистики.

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

• типовых пользователей ("Менеджер", "Оператор", "Техническая поддержка") — работников компании, сгруппированных по исполняемым обязанностям;
• другие системы, взаимодействующие с данной ("Система обработки заявок");
• выделенного пользователя ("Петров А.Б.").

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

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

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

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

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

Случаи использования, соответствующие актерам "Техническая поддержка и администрирование" и "Служба обработки заявок" несколько не вписываются в представленное выше определение. Прежде всего, сами эти актеры не являются пользователями ПО, участвующими в основном бизнес-процессе обработки телефонных заявок. "Техническая поддержка и администрирование" занята поддержкой ПО и оборудования системы обслуживания телефонных заявок, а также ее администрированием (добавлением новых пользователей, назначением им соответствующих прав и пр.). "Служба обработки заявок" является уже существующей в компании информационной системой, имеющей базу данных и ряд сервисов по обработке заявок. Идентификация этих актеров и соответствующих им случаев использования важна с точки зрения определения требований к системе. Для представителей службы технической поддержки необходим специальный удобный интерфейс с набором соответствующих функций. А все поступившие по телефону заявки должны попасть в единую базу данных заявок и пройти единый цикл обработки. Упущение этих факторов может привести к серьезным недочетам и проблемам. Кроме того, они ни откуда не следуют напрямую и поэтому нуждаются в особых начальных вершинах в дереве требований – то есть мы решили, что целесообразно поместить их на главную диаграмму случаев использования.

Отметим еще одну интересную деталь. Клиент магазина не является пользователем данного ПО. Он оказывается бизнес-пользователем всей системы в целом (включая соответствующий бизнес-процесс и оборудование). На рис. 8.2 представлена бизнес-диаграмма случаев использования.

Рис. 8.2. Пример диаграммы бизнес-случаев использования

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

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

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

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

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

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