д.т.н. Ойхман Е.Г., к.т.н. Новоженов Ю.В.
1. В настоящее время в мире имеется значительный спрос на разработку программных систем со сложным графическим интерфейсом, ориентированных на Web, легко адаптируемых к частым изменениям требований. Для таких целей целесообразно использовать ОО подход в сочетании с приемами и методами, применяемыми в технологии RAD. Поэтому традиционные ОО методологии нуждаются в изменениях и дополнениях в соответствии принципами RAD (привлечение экспертов заказчика к разработке, итеративность разработки, небольшие группы разработчиков). ОО подход в свою очередь влияет на RAD технологию, привнося в нее концепции наследования, инкапсуляции, повторного использования, аппарат описания функционирования системы на основе use case моделей.
ОО технологии основываются на вполне сложившейся языковой и инструментальной базе. Ее составляют принятый в качестве стандарта представления ОО моделей язык UML и поддерживающие его CASE средства, среди которых наибольшее распространение получило семейство Rational Rose. Свойства UML и Rational Rose позволяют успешно применять их в RAD технологиях. В то же время особенности RAD практически не учитываются в ОО методиках. Так, например, ОО итеративная методология RUP связана с выпуском документации значительного объема, что неприемлемо в RAD. Таким образом, те ОО методологии, которые используются в RAD технологии, должны быть дополнены с учетом особенностей RAD подхода.
Началу разработки системы предшествует выработка соглашения между заказчиком и разработчиком о проводимых работах. Это требуется для достижения взаимопонимания о характере предстоящих работ и определения типа проекта (перевод ППО на другую платформу, разработка нового ППО, разработка новой или унаследованной системы и т. д.). В зависимости от типа проекта действия, выполняемые на отдельных этапах разработки могут существенно отличаться, но практически всегда в основе разработки лежит подход, основанный на моделях.
2. Этапы разработки в технологии ОО RAD показаны на слайдах. Предлагаются два правила, относящиеся ко всем этапам разработки.
Правило 1.Распространение принципов RAD на все стадии разработки.
Правило 2.Преемственность моделей, создаваемых на разных этапах разработки (бизнес-модель, модель требований, модель анализа и дизайна).
Первое правило означает, что уже на самых начальных стадиях (например, обследование организации, выработка требований к системе) активно привлекаются представители заказчика в качестве экспертов и для осуществления контроля. Только в этом случае разработчик может быть уверен, что он будет делать именно то, что требуется заказчику.
Второе правило говорит о том, что уже на ранних стадиях создаются ОО модели, которые впоследствии будут развиваться. При этом ОО методология должна включать правила преемственности моделей.
3. Разработка спецификации начинается с обследования организации.
Правило 3. Целью ОО обследования является функциональное моделирование организации.
Построение функциональной модели организации начинается с определения основных видов деятельности организации которые показываются в модели в виде пакетов.
Правило 4. Основных видов деятельности не должно быть много.
Работы, составляющие основные виды деятельности, и бизнес актеры показываются на use case диаграммах. Детализация работ показывается с помощью технологических сценариев. На них могут присутствовать объекты.- исполнители - сотрудники организации или имеющиеся в ней программные системы, задействованные в той или иной работе.
4. Следующим этапом разработки спецификации является определение требований к ППО. Функциональные требования представляются в виде use case модели. Это дает возможность:
На use case диаграммах показываются актеры и варианты использования программной системы. При переходе от бизнес-модели к модели требований могут быть использованы определенные формальные правила. Так, например, основные виды деятельности в модели требований могут быть представлены как пакеты вариантов использования, а актеры программной системы формируются из бизнес-актеров и исполнителей. Как и для бизнес-модели детализация вариантов использования может быть выполнена с помощью диаграмм последовательностей.
Спецификация требований представляет собой текстовый документ, который:
5. Архитектурный анализ и дизайн позволяет определить нефункциональные требования к системе. Разные типы проектов требуют разработки различных архитектур. Следует отметить, что из основных архитектур, всегда проектируется только архитектура ППО. Мы считаем, что если помимо архитектур ППО и интеграции требуется разработка еще хотя бы одной архитектуры, то это проект информационной системы.
При проектировании архитектуры ППО. используется модель требований. Выделение компонент выполняется на основе обобщения и перегруппировки вариантов использования.
6. Анализ и дизайн представляет собой процесс построения диаграмм, описывающих программную систему с разных сторон. Для этой цели используются диаграммы, показанные на слайде. Основой ОО анализа и дизайна являются созданные ранее модель требований и архитектура ППО.
Особенности выполнения анализа и дизайна в технологии OO RAD сформулированы в следующем правиле.
Правило 5. Анализ и дизайн распределен по всем стадиям разработки.
После формирования очередного прототипа системы выполняется дополнение и уточнение модели на основе реинжиниринга. Это позволяет:
7. ППО создается как развиваемая последовательность прототипов. Действия на стадии кодирования преследуют следующие цели:
В связи с тем, что сейчас имеются достаточно развитые среды поддержки визуального программирования, мы считаем, что для прототипирования не требуется применения специальных языков, что можно выразить следующим правилом.
Правило 6. Прототипирование осуществляется на языке реализации.
В большинстве случаев создаются 3 прототипа. Первый реализует пользовательский интерфейс, второй - основную функциональность, третий - полную функциональность. Каждый прототип предъявляется заказчику, замечания которого учитываются в следующем прототипе.
Правило 7. После формирования каждого прототипа выполняется дополнение и уточнение модели анализа и дизайна на основе реинжиниринга.
8. В первом прототипе полностью реализуется пользовательский интерфейс, но отсутствует функциональность. Это позволяет быстро предъявить интерфейс заказчику, который может оценить его и дать свои замечания. После учета этих замечаний согласованный интерфейс утверждается заказчиком. Параллельно с программированием в рамках первого прототипа начинается визуальное моделирование, результатом которого является модель анализа и дизайна, которая будет уточняться и дополняться по результатам прототипирования. После формирования прототипа 1 выполняется реинжиниринг классов пользовательского интерфейса и включение их в модель анализа и дизайна.
Во втором прототипе выполняется кодирование классов, реализующих основные системные функции. Учитываются замечания заказчика по прототипу 1. Выполняется дополнение и уточнение модели анализа и дизайна на основе реинжиниринга программного кода.
Во третьем прототипе реализуется полная системная функциональность. Учитываются замечания заказчика по прототипу 2. Выполняется дополнение и уточнение модели анализа и дизайна на основе реинжиниринга.
По завершении прототипирования создается версия системы, в состав которой помимо текстов программ включается рабочая документация, модели и другие документы по согласованию с заказчиком.
9. Ни одна даже самая современная технология проектирования ППО не гарантирует успешного выполнения проектов, если она не основывается на четкой организации и оптимизации процессов жизненного цикла. Этой цели служит система конфигурационного управления, которая применяется на всех этапах жизненного цикла.
СКУ разрабатывается как типичная ИС с прохождением всех этапов - от обследования организации до выпуска документации.