Средства программной инженерии

12.4. Средства унифицированного процесса RUP

RUP (Rational Unified Process) - это процесс моделирования и построения ПС из объектов с применением языка UML. Он включает теоретические и прикладные аспекты представления и толкования создаваемых моделей для проектируемой из объектов предметной области [12.10, 12.11].

Теоретический аспект процесса моделирования моделей ПС поддерживается методами и понятиями формальных теорий. Формализация моделей в RUP обеспечивается средствами UML и дает возможность строго описывать требования и преобразовывать их к готовому продукту.

Основу процесса моделирования составляют прецеденты - варианты использования для определения требований к системе и взаимодействия объектов. Главный элемент проектирования - модель вариантов использования, на основе которой разрабатываются модели анализа, проектирования и реализации системы. Каждая модель анализирует соответствие модели вариантов использования, в которую входят входные данные для поиска и спецификации классов, для подбора и спецификации тестов, а также планирования итераций разработки и интеграции ПС. В процессе моделирования создаются следующие модели:

• модели вариантов использования, отражающие взаимодействие между пользователями и ПС;
• модель анализа, обеспечивающая спецификацию требований к системе и описание вариантов использования как кооперации между концептуальными классификаторами;
• модель проектирования, обеспечивающая создание статической структуры и интерфейсов системы, а также реализацию вариантов использования в виде набора коопераций между подсистемами, классами и интерфейсами;
• модель реализации, включающая компоненты системы в исходном виде на ЯП;- модель тестирования;
• модель размещения компонентов и их выполнение в операционной среде компьютеров.

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

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

Рис. 12.1. Связь моделей в системе RUP

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

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

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

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

Пример. Пусть uc - вариант использования ( uс - use case ), операция которого выполняется над учетной записью и имеет следующее определение:

uc.operations = <op1>,
op1.name = запрос и обновление учетной записи,
op1.method.body = {< проверка идентификации пользователя, наличия сервиса, 
                     запроса о долгах, 
                     обновление учетной записи >, 
                   < проверка идентификации пользователя на отклонение учетной записи >, 
                   < проверка идентификации пользователя на наличие сервиса и 
                     отклонение учетной записи>, 
                   < проверка идентификации пользователя и 
                     проверка наличия сервиса или запроса о долгах, 
                     на оплату, обновление учетной записи >}.

Тело метода - процедура реализации операций в виде последовательности действий op.method.body. Между именами действий варианта использования и именами действий в кооперации устанавливается отображение, что обеспечивает гибкость в процессе разработки и модификации имен действий. Между кооперацией и вариантом использования создается отношение реализации.

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

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

С практической точки зрения RUP представляется упорядоченным набором шагов и этапов ЖЦ, которые выполняются итеративно. Этот процесс является управляемым как в смысле задания требований, так и реализации функциональных возможностей ПрО с заданным уровнем качества и гарантированными затратами согласно графика работ. Оценка качества всех шагов и действий процесса базируется на определенных критериях.

Шаги при выполнении RUP управляются прецедентами, т.е. технологическим маршрутом делового моделирования и требований к испытанию. Экземпляр прецедента - это последовательность действий, выполняемых системой с наблюдаемым результатом для конкретного субъекта. Функциональные возможности системы определяются набором прецедентов, каждый из которых представляет некоторый поток событий. Описание прецедента определяет то, что произойдет в системе, когда прецедент будет выполнен. Каждый прецедент ориентирован на задачу, которую он должен выполнить. Набор прецедентов устанавливает все возможные пути (маршруты) выполнения системы. Прецеденты используются в следующих основных этапах процесса RUP: формирование требований, анализ, проектирование, реализация и испытание.

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

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

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

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

Этап проектирования служит для уточнения классов и описания их относительно четырех уровней: пользовательского интерфейса, бизнесрешений, уровня доступа и уровня данных. Создаваемая проектная модель системы состоит из структуры подсистем, их распределения между уровнями, интерфейсов классов и объектов, связей классов с узлами развертывания (модель развертывания).

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

RUP, как методология разработки размещена в Web-базе знаний поисковой системы. В ней представлены регламентированные этапы разработки ПО, документы и инструментальные средства для обеспечения каждого этапа ЖЦ.