Рациональный унифицированный процесс. Анализ и проектирование. Стадия анализа. Модель анализа прецедентов.

Рациональный унифицированный процесс

Рациональный унифицированный процесс разработки программного обеспечения (RUP – Rational Unified Process) является частным случаем унифицированного процесса (UP – Unified Process). В основу рационального унифицированного процесса положена итеративная разработка программного обеспечения. В рамках RUP разработка выполняется в виде нескольких краткосрочных итераций продолжительностью от 2 до 6 недель. Итерация по существу является мини–проектом фиксированной длительности, в результате которой расширяется и дополняется функциональность разрабатываемой системы. Поэтому унифицированный процесс разработки иногда называют итеративной и инкрементальной разработкой.

Анализ и проектирование

Этап анализа предполагает подробное исследование бизнес–процессов (функций, определенных на предыдущем этапе) и информации, необходимой для их выполнения (сущностей, их атрибутов и связей (отношений)). Этот этап дает информационную модель, а следующий за ним этап проектирования — модель данных.

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

Аналитики собирают и фиксируют информацию в двух взаимосвязанных формах:

• функции — информация о событиях и процессах, которые происходят в бизнесе;

• сущности — информация о вещах, которые имеют значение для организации и о которых что–либо известно.

Ранее двумя классическими результатами анализа были: иерархия функций, которая разбивает процесс обработки на компоненты («что делается и из чего это состоит»), и модель «сущность–связь» (Entry Relationship model, ER–модель), которая описывает сущности, их атрибуты и связи (отношения) между ними. Эти результаты являются необходимыми, но не достаточными. К достаточным результатам следует отнести диаграммы потоков данных и диаграммы жизненных циклов сущностей, которые описывают динамику системы. В настоящее время существует способ формализации проекта — Unified Modelling Language (UML), позволяющий формально описать различные стороны жизнедеятельности разрабатываемого проекта. Существует достаточно большое количество ПО, реализующего UML, например Rational Rose, Microsoft Visio. О UML мы расскажем в отдельной части данной статьи.

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

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

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

Задачами проектирования являются:

• рассмотрение результатов анализа и проверка их полноты;

• семинары с заказчиком;

• определение критических участков проекта и оценка ограничений проекта;

• определение архитектуры системы;

• принятие решения об использовании продуктов сторонних разработчиков, а также о способах интеграции и механизмах обмена информации с этими продуктами;

• проектирование хранилища данных: модель базы данных, бета–версия базы данных;

• проектирование процессов и кода: окончательный выбор средств разработки, определение интерфейсов программ, отображение функций системы на ее модули и определение спецификаций модулей;

• определение требований к процессу тестирования;

• определение требований безопасности системы.