Большаков Олег
Некоторое время назад компания Microfocus предложила подход к выявлению требований к программному обеспечению, который соответствует принципам таких методологий как RUP и MSF, однако реализован довольно интересно. В данных методологиях (как и во многих других) большая часть пользовательских требований выявлялась на стадии моделирования. Сначала рекомендуется выявить всех заинтересованных лиц ( актеров или actors ), затем - определить их действия ( варианты использования или прецеденты или use cases ), а при необходимости - описать сценарии этих действий на соответствующих диаграммах. Эти варианты использования, по сути, и будут являться требованиями к системе.
Как правило, для моделирования поведения пользователей системы используется язык моделирования UML, диаграммы вариантов использования, диаграммы активности, диаграммы последовательности и взаимодействия, и диаграммы состояний.
Наиболее популярные инструменты для UML моделирования -
И хотя у языка UML относительно невысокий "порог вхождения", многие аналитики не используют его при работе с требованиями. Причин этому множество: кто-то считает визуальное моделирование недостаточно эффективным, кто-то путается в диаграммах и назначениях элементов, кого-то не устраивает наглядность представления информации, или наоборот - чрезмерность графических образов, и т.д. и т.п. Как же нам совместить эффективность метода с относительной сложностью использования визуального моделирования? Ответом на этот вопрос и будет использование уже упомянутого нами "интересного" подхода компании Microfocus и программного инструмента CaliberRDM, с помощью которого он реализован.
Справедливости ради нужно заметить, что CaliberRDM - это не концептуально новая разработка, а успешное развитие продукта Caliber DefineIT, ранее разработанного компанией Borland. После покупки Borland и всей линейки их продуктов по управлению жизненным циклом ПО, компания Microfocus оставила от Caliber DefineIT только первоначальную концепцию, при этом существенно расширив ее. Caliber DefineIT был реализован на технологии Eclipse, а проекты хранились в виде упорядоченной структуры файлов и каталогов. В отличие от DefineIT, CaliberRDM полностью реализован по web-технологии как RIA-приложение (Rich Internet Application) с использованием технологии Adobe Flash, а все проекты хранятся на сервере, в базе данных Microsoft SQL Server.
Каким же образом CaliberRDM позволяет выявлять требования? Как и в UML, CaliberRDM оперирует такими понятиями как Актеры и Варианты использования, однако реализуется это не в виде диаграмм сценариев использования, а в виде перечней в определенных категориях. Причем описание вариантов использования все же моделируется визуально, однако более упрощенно, чем в UML. Упрощение достигается благодаря ограниченному набору используемых элементов, подобных UML (так как мы применяем здесь визуальное моделирование в контексте выявления требований, а не описания поведения и архитектуры всей системы в целом). Описывая поведение пользователей при работе с системой, мы можем выявить функциональные требования к системе, а также уточнить пользовательские требования. Также выявлению требований способствуют и дополнительные категории, введенные в CaliberRDM - это структуры данных, визуальные интерфейсы системы и шаблоны интерфейсов, а также симуляции, позволяющие продемонстрировать заказчику начальные прототипы системы.
Давайте рассмотрим, как все это реализовано в CaliberRDM.
После авторизации в системе пользователь попадает на стартовую страницу, где можно создать новый проект или выбрать существующий (рис.1).
Рис.1. Стартовая страница CaliberRDM
После выбора или создания проекта пользователь попадает на главную страницу CaliberRDM (рис.2), где в левой части представлено дерево проекта, а в правой - рабочая область, содержимое которой зависит от выбранного в дереве элемента проекта. В дереве представлено две корневых категории: Requirements (требования) и Visualizations (визуализации).
Рис.2. Главная страница CaliberRDM
Требования - это корневая категория, в которой можно сформировать структуру требований. Можно создавать папки (Folder), требования (Requirement), а также дочерние требования. Виды требований, например, бизнес-требования, пользовательские требования, функциональные требования и т.д., можно представлять в виде папок. В данной статье мы не будем останавливаться на работе с требованиями, эти вопросы мы рассмотрим в одной из следующих статей, посвященных CaliberRDM.
Визуализации - это набор следующих фиксированных категорий, которые используются для моделирования поведения системы:
- Scenarios (сценарии),
- Simulations (симуляции),
- Data (данные),
- Images (изображения),
- Templates (шаблоны) и
- Actors (пользователи системы).
Рассмотрим эти категории более подробно.
Actors (Актеры)
Актеры - это роли, которые играют пользователи по отношению к системе (рис.3). Актерами обычно являются пользователи, но также ими могут быть внешние системы, подсистемы или время. Актеры в CaliberRDM аналогичны актерам в UML. Согласно методикам RUP, MSF, а также многим другим, выявление актеров - первый шаг при работе с требованиями.
Рис.3. Актеры
Scenarios (сценарии)
Сценарии - это блок-схемы, которые используются для визуального представления, понимания и проверки последовательности бизнес-процессов. Сценарии CaliberRDM аналогичны сценариям вариантов использования в UML и представляются в виде диаграмм, похожих на диаграммы активности UML (рис.4). Сценарии отражают набор функций системы, а также то, как Актеры будут взаимодействовать с системой для реализации бизнес-задач. По сути, сценарии обеспечивают контекст требований. Также сценарии будут использоваться разработчиками при проектировании решения. Как правило, сценарий использования соответствует одному или нескольким требованиям.
Рис.4. Сценарии
Simulations (симуляции)
Симуляции - это интерактивные прототипы приложений, которые доступны для просмотра посредством веб-браузера (рис.5). Симуляции включают экраны приложений, веб-страницы, конфигурируемые данные, а также элементы пользовательского интерфейса, которые позволяют моделировать взаимодействие пользователя с приложением.
Симуляции позволяют на первых стадиях разработки решения продемонстрировать заказчику и заинтересованным лицам прототипы системы.
Демонстрация подобных прототипов позволяет:
- Получить подтверждение того, что разработчики двигаются в правильном направлении (в случае одобрения заказчиком представленного прототипа), или выявить ошибки и замечания.
- Убедиться в правильности (или ошибочности) выбранной концепции интерфейса.
- Выявить новые, а также уточнить ранее выявленные пользовательские требования к системе.
- Улучшить понимания заказчиком будущей реализации решения, а также своих истинных потребностей в автоматизации (часто бывает, что заказчики на первых стадиях разработки сами не знают, что хотят, а понимание приходит много позже).
Рис.5а. Последовательность шагов симуляции
Рис.5б. Интерфейс одного из шагов симуляции
Data (данные)
Данные - это структуры бизнес-сущностей (рис.6). Можно указывать атрибуты и типы атрибутов (текст, целое число, дробное число, булево значение, дата и время). Также можно заполнять сущности конкретными данными (например, если в системе должен быть справочник с предопределенными значениями).
Рис.6а. Перечень сущностей
Рис.6б. Данные
Images (изображения)
Изображения в CaliberRDM - это коллекция файлов с изображениями (jpg, gif, png), которые можно использовать в других категориях проекта (в симуляциях, сценариях и др.) (рис.7).
Рис.7. Изображения
Templates (шаблоны)
Шаблоны - предопределенные фрагменты интерфейса, которые можно использовать в симуляциях (рис.8). Шаблоны очень удобно использовать для веб-приложений, в которых обычно "шапка" страничек практически неизменна, а также для приложений с множеством вспомогательных окон или панелей.
Рис.8. Шаблоны
Почему в CaliberRDM нет диаграмм состояний, диаграмм последовательности и взаимодействия, и диаграмм классов, которые используются в визуальном моделировании? Дело в том, что CaliberRDM ориентирован на выявление требований к системе посредством моделирования ее поведения в рамках действий пользователя с системой, а не на моделирование архитектуры системы в целом. Мы должны четко понимать, что для полноценного проектирования системы нам нужно использовать именно UML, а вот для выявления требований и начального прототипирования системы - очень удобно использовать CaliberRDM, инструмент интуитивно понятный, не перегруженный UML-нотацией, и в тоже время в достаточной мере соблюдающий общепринятые принципы моделирования.