Индустриальное проектирование

Технология RUP

 

Технология RUP (Rational Unified Process) разработана компанией Rational Software. Она ориентирована на использование универсального языка объектно-ориентированного моделирования UML, явля­ющегося фактическим стандартом в данной области (см. главу 3).

Общий вид процесса представляет RUP в двух измерениях:

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

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

Динамический аспект

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

· начальная стадия (inception);

· стадия уточнения (elaboration);

· стадия конструирования (construction);

· стадия ввода в действие (transition).

Каждая стадия завершается в четко определенной контрольной точке (milestone). В этот момент времени должны достигаться важные результаты и приниматься критически важные решения о дальнейшей разработке.

Первыми двумя стадиями являются начальная стадия проекта и уточнение.

Начальная стадия. Она может принимать множество разных форм. Для крупных проектов начальная стадия может вылиться во всестороннее изучение всех возможностей реализации проекта, которое займет месяцы. Во время начальной стадии вырабатывается бизнес-план проекта — определяется, сколько приблизительно он будет стоить и какой доход принесет. Устанавливаются также границы проекта, и выполняется некоторый начальный анализ для оценки размеров проекта.

Для того чтобы проделать такую работу, необходимо идентифицировать все внешние сущности (действующие лица), с которыми система будет взаимодействовать, и определить в самом общем виде природу этого взаимодействия. Это подразумевает идентификацию всех вариантов использования (use case, см. главу 3) и описание наиболее важных из них. Бизнес-план включает критерии успеха, оценку риска, оценку необходимых ресурсов и общий план по стадиям, включающий даты основных контрольных точек.

Результатами начальной стадии являются:

· общее описание системы (основные требования к проекту, его характеристики и ограничения);

· начальная диаграмма вариантов использования (степень готовности - 10 - 20%);

· начальный проектный глоссарий (словарь терминов);

· начальный бизнес-план;

· план проекта, отражающий стадии и итерации;

· один прототип или несколько.

Стадия уточнения. На этой стадии выявляются более детальные требования к системе, выполняются высокоуровневый анализ пред метной области и проектирование для построения базовой архитектуры системы, создается план конструирования и устраняются наиболее рискованные элементы проекта.

Результатами стадии уточнения являются:

диаграмма вариантов использования (завершенная по крайней мере на 80%), определяющих требования к системе;

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

описание базовой архитектуры будущей системы;

работающий прототип;

уточненный бизнес-план;

план разработки всего проекта, отражающий итерации и критерии оценки для каждой итерации.

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

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

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

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

Стадия уточнения занимает около пятой части общей продолжительности проекта. Основными признаками завершения этой стадии являются два события:

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

идентифицированы все наиболее серьезные риски, и степень понимания наиболее важных из них такова, что известно, как справиться с ними.

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

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

Стадия конструирования. RUP представляет собой итеративный и пошаговый процесс разработки, в котором программное обеспечение разрабатывается и реализуется по частям. На стадии конструирования построение системы выполняется путем серии итераций. Каждая итерация является своего рода мини-проектом. На каждой итерации для конкретных вариантов использования выполняются анализ, проектирование, кодирование, тестирование и интеграция. Итерация завершается демонстрацией результатов пользователям и выполнением системных тестов в целях контроля корректности реализации вариантов использования.

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

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

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

Главная особенность итеративной разработки заключается в том, что она жестко ограничена временными рамками, и сдвигать сроки недопустимо. Исключением может быть перенос реализации каких-либо вариантов использования на более позднюю итерацию по со­глашению с заказчиком. Смысл таких ограничений — поддерживать строгую дисциплину разработки и не допускать переноса сроков.

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

Помимо конструирования итерации могут присутствовать во всех стадиях, однако при этом конструирование является ключевой стадией.

Результатом стадии конструирования является продукт, готовый к передаче конечным пользователям. Как минимум, он содержит следующее:

ПО, интегрированное на требуемых платформах;

руководства пользователя;

описание текущей реализации.

Стадия ввода в действие. Назначение этой стадии — передача готового продукта в распоряжение пользователей. Данная стадия включает:

бета-тестирование, позволяющее убедиться, что новая система соответствует ожиданиям пользователей;

параллельное функционирование с существующей (legacy) системой, которая подлежит постепенной замене;

конвертирование баз данных;

оптимизацию производительности;

обучение пользователей и специалистов службы сопровождения.

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

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

На стадии ввода в действие продукт не дополняется никакой новой функциональностью (кроме самой минимальной и абсолютно необходимой). Здесь только вылавливаются ошибки. Хорошим примером для стадии ввода в действие может служить период времени между выпуском бета-версии и окончательной версии продукта.

Статический аспект

Статический аспект RUP характеризуют четыре основных элемента:

исполнители;

действия;

результаты деятельности;

рабочие процессы.

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

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

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

В рамках RUP определены шесть основных процессов:

построение бизнес-моделей;

определение требований;

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

реализация;

тестирование;

развертывание

и три вспомогательных процесса:

управление конфигурацией;

управление проектом;

создание инфраструктуры (environment).

RUP как продукт входит в состав комплекса Rational Suite, при­чем каждый из перечисленных выше процессов поддерживается определенным инструментальным средством комплекса RUP состоит из базы знаний и руководства в твердой копии.

База знаний включает следующие компоненты:

руководства для всех участников проектной команды, охватывающие весь жизненный цикл ПО. Руководства представлены в двух видах — для осмысления процесса на верхнем уровне и в виде подробных наставлений по повседневной деятельности;

наставления по использованию инструментальных средств, входящих в состав Rational Suite;

примеры и шаблоны проектных решений для Rational Rose;

шаблоны проектной документации для SoDa;

шаблоны в формате Microsoft Word, предназначенные для поддержки документации по всем процессам и действиям жизненного цикла ПО;

планы в формате Microsoft Project, отражающие итерационный характер разработки ПО.

Адаптация RUP к потребностям конкретной организации или проекта обеспечивается с помощью специального набора инструментов и шаблонов Development Kit. База знаний имеет формат гипертекста (HTML - HyperText Markup Language — стандартный язык для создания страниц Интернет). Доступ к ней может осуществляться с помощью Microsoft Internet Explorer или Netscape Navigator. Такой формат допускает как индивидуальное, так и коллективное использование базы знаний в сети Интранет.

Методология DATARUN

 

Одной из наиболее распространенных индустриальных технологий является методология DATARUN. В соответствии с методологией DATARUN ЖЦ ПО разбивается на стадии, которые связываются с результатами выполнения основных процессов, определяемых стандартом ISO 12207. Каждую стадию кроме ее результатов должен завершать план работ на следующую стадию.

Стадия формирования требований и планирования включает в себя действия по определению начальных оценок объема и стоимости проекта. Должны быть сформулированы требования и экономическое обоснование для разработки ИС, функциональные модели (модели бизнес-процессов организации) и исходная концептуальная модель данных, которые дают основу для оценки технической реализуемости проекта. Основными результатами этой стадии должны быть модели деятельности организации (исходные модели процессов и данных организации), требования к системе, включая требования по сопряжению с существующими ИС, исходный бизнес-план.

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

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

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

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

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

Методология DATARUN опирается на две модели или на два представления:

· модель организации;

· модель ИС.

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

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

Любая ИС представляет собой набор модулей, исполняемых процессорами и взаимодействующих с базами данных. Базы данных и процессоры могут располагаться централизованно или быть распределенными. События в системе могут инициироваться внешними сущностями, такими как клиенты у банкоматов или временные события (конец месяца или квартала). Все транзакции осуществляются через объекты или модули интерфейса, которые взаимодействуют с одной или более базами данных.

Подход DATARUN преследует две цели:

· определить стабильную структуру, на основе которой будет строиться ИС. Такой структурой является модель данных, полученная из первичных данных, представляющих фундаментальные процессы организации;

· спроектировать ИС на основании модели данных.

Объекты, формируемые на основании модели данных, являются объектами базы данных, обычно размещаемыми на серверах в среде клиент/сервер. Объекты интерфейса, определенные в архитектуре компьютерной системы, обычно размещаются на клиентской части. Модель данных, являющаяся основой для спецификации совместно используемых объектов базы данных и различных объектов интерфейса, обеспечивает сопровождаемость ИС.

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

Модели, создаваемые с помощью подхода DATARUN

- BPM (B usiness P rocess M odel) - модель бизнес-процессов.

- PDS (P rimary D ata S tructure) - структура первичных данных.

- CDM (C onceptual D ata M odel) - концептуальная модель данных.

- SPM (S ystem P rocess M odel) - модель процессов системы

- ISA (I nformation S ystem A rchitecture) - архитектура информационной системы.

- ADM (A pplication D ata M odel) - модель данных приложения.

- IPM (I nterface P resentation M odel) - модель представления интерфейса.

- ISM (I nterface S pecification M odel) - модель спецификации интерфейса.

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

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

На основе структур первичных данных создается концептуальная модель данных (ER-модель). От структур первичных данных концептуальная модель отличается удалением избыточности, стандартизацией наименований понятий и нормализацией. Эти операции в модуле ERX выполняются при помощи встроенной экспертной системы. Цель концептуальной модели данных – описать используемую информацию без деталей возможной реализации в базе данных, но в хорошо структурированном нормализованном виде.

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

Перед разработкой приложений должна быть спроектирована структура корпоративной базы данных. DATARUN предполагает использование базы данных, основанной на реляционной модели. После преобразования форматов получается модель реляционной базы данных. Эта модель детализируется определением физической реализации (типов данных СУБД, ключей, индексов, триггеров, ограничений ссылочной целостности). Правила обработки данных можно задавать как непосредственно на языке программирования СУБД, так и в декларативной форме, не привязанной к реализации.

С помощью модели системных процессов детально документируется поведение каждого приложения. В модуле BPM создается модель системных процессов, определяющая, каким образом реализуются бизнес-процессы. Эта модель создается отдельно для каждого приложения и тесно связана с моделью данных приложения.

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

Модель представления интерфейса - это описание внешнего вида интерфейса, как его видит конечный пользователь системы. Это может быть как документ, показывающий внешний вид экрана или структуру отчета, так и сам экран (отчет), созданный с помощью одного из средств визуальной разработки приложений - так называемых языков четвертого поколения (4GL - Fourth Generation Languages). Так как большинство языков 4GL позволяют быстро создавать работающие прототипы приложений, пользователь имеет возможность увидеть работающий прототип системы на ранних стадиях проектирования.

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

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

 

5.2

(Приводится необходимая теоретическая информация, структурированная по разделам и темам (даже при отсутствии лекционных занятий), объёмом не менее………….страниц.)