1. Введение в разработку управляемую вариантами использования

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

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

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

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

Модель проектирования имеет следующие свойства:

• Модель проектирования имеет иерархическую структуру. Она также содержит отношения, наложенные поверх иерархии. Отношения — ассоциации, обобщения и зависимости (приложение А) — часто используются в UML.

• Реализации вариантов использования в модели проектирования — это стереотипы кооперации. Кооперация описывает, как классификаторы используются в каком-либо виде деятельности, например реализации варианта использования.

• Модель проектирования является чертежом реализации. Существует прямое отображение подсистем модели проектирования в элементы модели реализации.

Разработчики создают модель анализа, используя модель вариантов использования в качестве исходных данных. Каждый вариант использования из модели вариантов использования превращается в реализацию варианта использования модели анализа. Дуализм вариантов использования/реализаций вариантов использования позволяет соблюсти полное подобие между определением требований и анализом. Прорабатывая варианты использования один за другим, разработчики идентифицируют классы, участвующие в реализации вариантов использования. Вариант использования Получить наличные, например, превращается в классы анализа Получение, Банковский счет, Устройство выдачи и еще несколько классов, которые мы пока идентифицировать не будем. Разработчики выделяют ответственности конкретных классов в ответственностях определенных в вариантах использования. В нашем примере класс Банковский счет будет нести ответственность за выполнение операции «Списать деньги со счета». Таким образом, мы можем убедиться в том, что получили набор классов, совместно реализующих варианты использования и действительно необходимых.

Затем разработчики проектируют классы и реализации вариантов использования для того, чтобы лучше понять, какие продукты и технологии следует использовать для построения системы (брокеры объектных запросов, библиотеки для создания графического интерфейса пользователя, СУБД). Классы проектирования собираются в подсистемы, и между этими подсистемами определяются интерфейсы. Разработчики также создают модель развертывания, которая определяет физическое распределение частей системы по узлам — отдельным компьютерам сети — и проверяют, могут ли варианты использования быть реализованы в виде компонентов, выполняемых на этих узлах. Далее, разработчики реализуют спроектированные классы в виде набора файлов с исходным текстом компонентов, из которых, если их скомпилировать и скомпоновать, можно получить исполняемый код — DLL, JavaBeans или ActiveX. Варианты использования помогают разработчикам определить порядок создания компонентов и включения их в систему.

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