Опубликован: 24.09.2008 | Уровень: специалист | Доступ: платный | ВУЗ: Московский физико-технический институт
Лекция 13:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Александр Медов
Александр Медов

Здравствуйте,при покупке печатной формы сертификата,будут ли выданы обе печатные сторны?

Александр Медов
Александр Медов

Здравствуйте, прошел курс МБА Управление ИТ-проектами и направил документы на получение диплома почтой. Подскажите, сроки получения оного в бумажной форме?

:

Татьяна Невокшонова
Татьяна Невокшонова
Россия
Кристина Языкова
Кристина Языкова
Россия, Москва, 1171, 2012