Средства унифицированного процесса RUP
RUP (Rational Unified Process) – это процесс моделирования и построения ПС из объектов с применением языка UML. Он включает теоретический и прикладной аспекты представления и толкования создаваемых моделей для проектируемой предметной области [12, 13].
Теоретический аспект процесса моделирования моделей ПС поддерживается методами и понятиями формальных теорий. Формализация моделей в RUP обеспечивается средствами UML и дает возможность строго описывать требования и преобразовывать их к готовому продукту.
Основу процесса моделирования составляют прецеденты – варианты использования для определения требований к системе. Главный элемент проектирования – модель вариантов использования, на основе которой разрабатываются модели анализа, проектирования и реализации системы. Каждая модель анализируется на соответствие модели вариантов использования, в которую входят входные данные для поиска и спецификации классов и подсистем, для подбора и спецификации тестов, а также при планировании итераций разработки и интеграции ПС. В процессе моделирования создаются следующие модели:
– вариантов использования, отражающих взаимодействие между пользователями и ПС;
анализа, обеспечивающего спецификации требований к системе и описание вариантов использования как кооперации между концептуальными классификаторами;
– проектирования, ориентированного на создание статической структуры и интерфейсов системы, реализацию вариантов использования в виде набора коопераций между подсистемами, классами и интерфейсами;
– реализации, включающей компоненты системы в исходном виде на ЯП;
– тестирования;
– размещения компонентов и выполнение в операционной среде компьютеров.
Эти модели представляются разными видами диаграмм, например, в модели вариантов использования диаграммы use–case, в моделях анализа – диаграммы классов, коопераций и состояний. Данные модели – взаимосвязанные, семантически пересекаются и определяют систему как единое целое.
Например, вариант использования в соответствующей модели может иметь отношение зависимости к кооперации в модели проектирования, задающей реализацию. Модели, определенные на каждой итерации процесса RUP, уточняются или расширяют модели предыдущих итераций процесса
Типы моделей и их связи показаны на рис.11.1, каждая из моделей задается соответствующими диаграммами. Например, модель анализа состоит из диаграмм классов, состояний и кооперации.
Артефакты одной модели связаны между собой и должны быть совместимы друг с другом. Отношения между моделями являются не полностью формальными, поскольку части моделей специфицированы на языке метамодели, а другие описаны только неформально, на естественном языке. Спецификации диаграмм UML является также полуформальними.
 |
 |
|||||
 |
|||||
 |
|||||
проектирования
Модель
Модель
Рис.11. 1. Связь моделей в системе RUP
Основу модели анализа составляет диаграмма варианта использования, которая включает в себя диаграммы классов, взаимодействия, задающие возможные сценарии вариантов использования в терминах взаимодействия объектов на этапе анализа.
Варианты использования специфицируют тип отношений между действующим лицом (актером), пользователем и системой. На высоком уровне абстракции они представляются упорядоченной последовательностью действий или альтернатив.
Вариант использования в UML – это разновидность классификатора, операциями которого являются сообщения, получаемые экземплярами конкретного варианта использования. Методы задают реализацию операций в терминах последовательностей действий, выполняемых экземплярами варианта использования. Пример.
Пусть uc – вариант использования (uс – use case), операция которого выполняется над учетной записью и имеет следующее определение:
uc.operations = <op1>
op1.name = запрос и обновление учетной записи
op1.method.body = {< проверка идентификации пользователя, наличия сервиса,
запроса о долгах, обновление учетной записи >,
< проверка идентификации пользователя, отклонение учетной записи >,
< проверка идентификации пользователя, наличия сервиса, отклонение учетной записи >,
< проверка идентификации пользователя, проверка наличия сервиса, запроса о долгах,
запроса на оплату, обновление учетной записи >}
Тело метода – процедура, специфицирующая реализацию операций в виде последовательности действий op.method.body или op.action Sequence. Между именами действий варианта использования и именами действий в кооперации устанавливается отображение, что обеспечивает гибкость в процессе разработки и модификацию имен действий. Между кооперацией и вариантом использования uc создается отношение реализации.
Вариант использования реализуется кооперацией, если роли классификаторов в ней взаимодействуют для обеспечения поведения.
Если кооперация имеет более сложное поведение, чем специфицированное вариантом использования, то этот вариант использования – частичная спецификация поведения кооперации. Варианты использования специфицируют действия, видимые за пределами системы, но не специфицируют внутренних действий (создание и удаление экземпляров классификаторов, взаимодействие между экземплярами классификаторов и т.д.).
Определение расширения включает как условие расширения, так и ссылку на точку расширения в целевом варианте использования, которая является позицией внутри варианта использования. Как только экземпляр варианта использования достигает точки расширения, на которую ссылается это отношение, проверяется его условие. Если условие выполняется, последовательность, удовлетворяющая условиям в экземпляре варианта использования, расширяется таким образом, чтобы включить в себя последовательность расширяемого варианта использования.
С практической точки зрения RUP представляется упорядоченным набором шагов и этапов ЖЦ, которые выполняются итеративно. Этот процесс является управляемым, как в смысле задания требований, так и реализации функциональных возможностей ПрО с заданным уровнем качества и гарантированными затратами согласно графика работ. Оценка качества всех шагов и действий участников процесса базируется на определенных критериях.
Шаги при выполнении RUP управляются прецедентами, т.е. технологическим маршрутом от делового моделирования и требований до испытаний. Экземпляр прецедента – это последовательность действий, выполняемых системой с наблюдаемым результатом для конкретного субъекта. Функциональные возможности системы определяются набором прецедентов, каждый из которых представляет некоторый поток событий. Описание прецедента определяет то, что произойдет в системе, когда прецедент будет выполнен. Каждый прецедент ориентирован на задачу, которую он должен выполнить. Набор прецедентов устанавливает все возможные пути (маршруты) выполнения системы.
Прецеденты играют роль в каждом из пяти основных работ процесса: формирование требований, анализ, проектирование, реализация и испытание.
RUP содержит пять основных этапов, выполняемых на всех фазах процесса разработки ПС. Завершение этих этапов называется итерацией, при которой заканчивается выпуском промежуточного продукта. На каждой итерации цикл повторяется, начиная со сбора и уточнения требований.
Этап формирования требования. На этом этапе проводится сбор функциональных, технических и прикладных требований к проекту. На основе требований заказчика и пользователей система описывается так, чтобы достичь понимания между ними и проектной группой. Информация собирается с учетом особенностей существующих систем и документов, подготовленных заказчиком, и включает:
– модель ПрО;
– модель схем использования с описанием функциональных и общих требований в форме результатов опрашивания, наборов диаграмм и детального описания каждой схемы;
– дизайн и прототип интерфейса пользователя для каждого актера;
– список требований, которые не относятся к конкретным схемам использования.
Этап анализа.
Сформулированные требования уточняются и отображаются в модели сценариев использования. Кроме того, создается аналитическая модель системы, которая включает формализмы для анализа внутренней структуры системы, определения классов и превращения этой модели в проектные концепции и схемы их реализация.
Этап проектирования служит для уточнения классов и описания их относительно четырех уровней: пользовательского интерфейса, бизнесов–решений, уровня доступа и уровня данных. Создаваемая проектная модель системы состоит из структуры подсистем, их распределения между уровнями, интерфейсов классов и объектов, связей классов с узлами развертывания (модель развертывания).
На этапе реализации выполняется построение прототипа из компонентов; создания тестов по схемам использования; тестирование и интеграция компонентов; проверка архитектуры; переход к следующей итерации.При каждой итерации тестовая модель уточняется путем исключения неактуальных тестов, создания схемы регрессионного тестирования и добавления тестов для собираемых компонентов. Каждый тест создается с помощью вариантов использования и реализует конкретный метод проверки функций системы на входных данных.
RUP – методология оформлена и размещена в Web базе знаний поисковой системы. В ней регламентированы этапы разработки ПО, документы и инструментальные средства для обеспечения каждого этапа ЖЦ.
