Методологии проектирования программных систем

Чтобы устранить двусмысленность в терминологии, встречающуюся в литературе, разграничим понятия метод и методология в технологии проектирования программных систем. Приведем определения, данные Бучем Г. [16], и будем далее их придерживаться. Метод — это последовательный процесс создания моделей, которые описывают вполне определенными средствами различные стороны разрабатываемой программной системы. Методология — это совокупность методов, применяемых в жизненном цикле разработки программного обеспечения и объединенных одним общим философским подходом. Все известные методологии проектирования программных систем можно разделить на три большие группы [16]:

· структурные методологии, ориентированные на первоочередное проектирование функций системы (процедурно-ориентированные);

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

· объектно-ориентированные методологии.

Методология Йордона является примером структурного подхода, ориентированного на первоочередное проектирование функций [19, 39, 167]. По оценкам [42] эта методология является наиболее часто используемой (36,5% проектов). В соответствии с этой методологией весь проект разделяется на следующие четыре фазы.

1. На фазе анализа строится модель среды. Построение модели среды включает: анализ поведения системы (определение назначения системы, построение начальной контекстной диаграммы потоков данных (DFD) и формирование матрицы списка событий (ELM - Event List Matrix), построение контекстных диаграмм); анализ данных (определение состава потоков данных и построение диаграмм структур данных (DSD - Data Structure Diagram), конструирование глобальной модели данных в виде ER-диаграммы). Между различными типами диаграмм существуют следующие взаимосвязи: ELM-DFD (события - входные потоки, реакции - выходные потоки); DFD-DSD (потоки данных - структуры данных верхнего уровня); DFD-ERD (накопители данных - ER-диаграммы); DSD-ERD (структуры данных нижнего уровня - атрибуты сущностей).

2. На фазе проектирования архитектуры строится предметная модель. Процесс построения предметной модели включает в себя следующие действия: детальное описание функционирования системы; дальнейший анализ используемых данных и построение логической модели данных для последующего проектирования базы данных; определение структуры пользовательского интерфейса, спецификация форм и порядка их появления; уточнение диаграмм потоков данных и списка событий, выделение среди процессов нижнего уровня интерактивных и неинтерактивных, определение для них мини-спецификаций. Результаты проектирования архитектуры: модель процессов (диаграммы архитектуры системы (SAD - System Architecture Diagram) и мини-спецификации на структурированном языке); модель данных (ERD и подсхемы ERD); модель пользовательского интерфейса (классификация процессов на интерактивные и неинтерактивные функции, диаграмма последовательности форм (FSD - Form Sequence Diagram), показывающая, какие формы появляются в приложении и в каком порядке. На FSD фиксируются набор и структура вызовов экранных форм.

3. На фазе детального проектирования строится модульная модель. Под модульной моделью понимается реальная модель проектируемой прикладной системы. Процесс ее построения включает: уточнение модели базы данных для последующей генерации SQL-предложений, определяющих структуру целевой БД; уточнение структуры пользовательского интерфейса; построение структурных схем, отражающих логику работы пользовательского интерфейса и модель бизнес-логики (SCD - Structure Charts Diagram), и привязка их к формам. Результатами детального проектирования являются: модель процессов (структурные схемы интерактивных и неинтерактивных функций); модель данных (определение в ERD всех необходимых параметров для приложений); модель пользовательского интерфейса (диаграмма последовательности форм (FSD), показывающая, какие формы появляются в приложении и в каком порядке, взаимосвязь между каждой формой и определенной структурной схемой, между каждой формой и одной или более сущностью в ERD).

4. На фазе реализации строится модель реализации системы. Процесс ее построения включает в себя: генерацию SQL-предложений, определяющих структуру целевой БД (таблицы, индексы, ограничения целостности); уточнение структурных схем (SCD) и диаграмм последовательности форм (FSD) с последующей генерацией кода приложений. На основе анализа потоков данных и взаимодействия процессов с хранилищами данных осуществляется окончательное выделение подсистем. При выделении подсистем необходимо руководствоваться принципами функциональной связанности и минимизации информационной зависимости. Необходимо учитывать, что на основании таких элементов подсистемы, как процессы и данные, на этапе разработки должно быть создано приложение, способное функционировать самостоятельно. Разработаны модификации этой методологии совместно с другими авторами – методологии Йордона/ДеМарко, Йордона/Константайна, Коада/Йордона.

Методология Гейна и Сарсона очень близка к методологии Йордона [23, 128]. В работе [42] утверждается, что она применяется в 20,2% случаев. Главной отличительной чертой этой методологии является наличие этапа моделирования данных, определяющего содержимое хранилищ данных в диаграммах потоков данных в третьей нормальной форме. Этот этап включает:

· построение списка элементов данных, располагающихся в каждом хранилище данных;

· анализ отношений между данными и построение соответствующей диаграммы связей между элементами данных;

· представление всей информации по модели в виде связанных нормализованных таблиц.

Методология SSADM (Structured Systems Analysis and Design Method) - национальный стандарт Великобритании для разработки информационных систем, принятый в 1993 г. [42, 118]. Она является методологией, ориентированной на первоочередное проектирование функций. Ее достоинством является наличие взаимосогласованных методик, регламентирующих начальные этапы разработки системы, центральным из которых является этап итеративного определения требований. В то же время SSADM не распространяется на этапы, связанные с реализацией, внедрением и сопровождением системы, отсылая разработчика к другим общедоступным методологиям, рекомендуемым британским государственным агентством по информатике и вычислительной технике. В SSADM применяется нисходящий подход к построению интегрированных функциональных, информационных и событийных моделей. При моделировании функций используются классические DFD с мини спецификациями на структурированном естественном языке. Моделирование данных осуществляется с использованием нотации LDS (Logical Data Structure), являющейся диалектом ER-модели. Для событийного моделирования используются диаграммы истории жизни сущностей ELN (Entity Life History), поддерживающие индикаторы состояний, события с привязанными к ним действиями, возможность задавать последовательные, параллельные и итеративные конструкции, а также конструкции выбора. Согласно SSADM определение системных требований включает шесть основных этапов.

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

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

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

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

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

6. Физическое проектирование: разработка физической информационной модели; разработка спецификаций к программным компонентам; оптимизация информационной модели; уточнение спецификаций к программным компонентам; оформление документации.

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

Структурное проектирование Джексона является классическим примером методологии, ориентированной на первоочередное проектирование данных [42, 118]. Его базовая процедура проектирования предназначена для «простых» программ («сложная» программа разбивается на «простые» традиционными методами) и включает следующие четыре этапа.

1. Этап проектирования данных. Построение системной сетевой диаграммы, демонстрирующей все хранилища, источники и стоки данных в программе. Представление каждой входной и выходной структуры данных древовидной структурной диаграммой.

2. Этап проектирования программ. Формирование структуры программы комбинированием структур данных. Идентификация всех связей между компонентами структур данных. Верификация полученной структуры программы.

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

4. Этап проектирования текстов. Трансляция построенной модели программы в текстовый вид с добавлением ряда логических условий для управления выполнением циклов и выбором данных.

Методология DSSD (Data-Structured Systems Development), предложенная Варнье-Орром, является другим примером подхода ориентированного на данные [42, 118]. Эта методология использует теорию множеств для описания проекта ПО и ориентирована на разработку систем со структурными данными. Так же, как и в математике, множество определяется перечислением его элементов. Подобно методологии Джексона, структура программы строится на базе структур данных, а главным отличием является то, что в методологии Джексона необходимо объединять все входные и выходные структуры данных для продуцирования структуры программы, а в DSSD входные данные и структура программы продуцируются из выходных структур. Таким образом, главная аксиома DSSD утверждает, что выходные структуры данных полно и точно определяют входные структуры, которые, в свою очередь, определяют и логику их обработки. Основные этапы методологии DSSD изображены на рис. 2.12 с помощью диаграммы Варнье-Орра.

При построении модели в DSSD используются диаграммы сущностей (диалект DFD) для определения системного контекста и диаграммы Варнье-Орра в качестве основного средства моделирования системы. Базовым элементом диаграммы Варнье-Орра является множественная скобка. Детализация элементов данных производится слева направо, предполагаемая последовательность действий осуществляется слева направо и сверху вниз. Такая нотация удобна для представления композиции структур, определения структур данных, спецификации форматов файлов. Она может быть использована для иллюстрирования структуры программы и иерархии модулей (заменой структур данных на модули или файлы, а на нижних уровнях – на подпрограммы, DO-циклы, условные и другие операторы), являясь в этом случае неким аналогом визуального языка проектирования.

IE-методология Мартина предоставляет собой общую стратегию разработки информационных систем, фокусирующую внимание на стратегическом планировании и бизнес-процессах [42, 118, 162, 163]. В то же время она является и инженерным подходом к разработке ПО, так как обеспечивает нисходящую пошаговую процедуру построения информационной системы. Основные этапы методологии Мартина приведены на рис. 2.13.

Методология Мартина базируется на двух концепциях:

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

· первоначальной направленности на моделирование данных, а затем на функциональное моделирование. Рассмотрим ее основные этапы.

1. Этап стратегического информационного планирования начинается с построения стратегического плана для бизнес-системы, включающего цели и стратегии их достижения. Далее строится модель предметной области, отражающая существующую специфику и определяющая основные бизнес-процессы и организационную структуру бизнес-системы, а также определяется порядок разработки информационной системы. При моделировании используются диаграммы декомпозиции (иерархические древовидные структурные диаграммы) и диаграммы «сущность-связь» для представления основных бизнес-процессов и структур данных, соответственно.

2. На этапе анализа бизнес-процессов основные бизнес-процессы, разработанные на предыдущем этапе, используются для разбиения общей задачи на частные. Основное внимание в такой ситуации уделяется определению информационной и функциональной модели для частных задач. При этом диаграммы «сущность-связь» трансформируются в нормализованную модель данных, а диаграммы декомпозиции распределяются по подзадачам. Для представления процессов служат DFD-диаграммы зависимости данных (диалект DFD) и диаграммы декомпозиции, а для соотнесения данных и процессов, в которых эти данные используются, применяются матрицы «сущность/процесс».

3. На этапе логического проектирования базой являются процессы, разработанные на этапе анализа. Используя методики нисходящей функциональной декомпозиции, проектируются спецификации обработки процессов и их логические структуры данных. При этом используются диаграммы структуры данных (диалект ERD), определяющие типы сущностей, их атрибуты и связи, диаграммы декомпозиции и диаграммы деятельности (вид мини спецификации), детализирующие логику процессов. Для согласования требований пользователя создаются прототипы пользовательских интерфейсов с помощью схем экранов/отчетов.

4. На этапе физического проектирования и реализации производится преобразование логической модели системы в физическую и ее реализация.

Рассмотрим методологии объектно-ориентированного анализа и проектирования. Объектно-ориентированный анализ (OOA) — это методология, при которой требования к системе воспринимаются с точки зрения классов и объектов, выявленных в предметной области [16]. Объектно-ориентированное проектирование (OOD) — это методология проектирования, соединяющая в себе процесс объектной декомпозиции и приемы представления логической и физической, а также статической и динамической моделей проектируемой системы. Объектно-ориентированное программирование (OOP) — это методология программирования, основанная на представлении программы в виде совокупности объектов, каждый из которых является экземпляром определенного класса, а классы образуют иерархию наследования. В этом определении можно выделить три части:

· объектно-ориентированное программирование использует в качестве базовых элементов объекты,а не алгоритмы (иерархия «быть частью»);

· каждый объект является экземпляромкакого-либо определенного класса;

· классы организованы иерархически.

Программа будет объектно-ориентированной только при соблюдении всех трех указанных требований. В частности, программирование, не основанное на иерархических отношениях, не относится к ООР, а называется программированием на основе абстрактных типов данных. Объектными принято называть языки, которые поддерживают абстракции данных и классы. Объектно-ориентированными являются те объектные языки, которые поддерживают наследование и полиморфизм. Унифицированный язык моделирования (UML – Unified Modeling Language) является языком, использующим графическую нотацию и предназначенный для спецификации, визуализации, конструирования и документирования систем программного обеспечения на основе объектно-ориентированных методов и компонентного подхода [64]. Язык UML был создан в компании Rational Software Corporation совместными усилиями Буча Г., Якобсона И., Рамбо Дж. [17, 135, 160, 164,]. Использование универсальногоязыка моделирования UML предусматривает построение следующих основных типов диаграмм:

· диаграммы вариантов использования;

· диаграммы классов;

· диаграммы состояний;

· три диаграммы поведения (две последние из них также называют диаграммами взаимодействия): диаграммы деятельности; диаграммы последовательности; диаграммы кооперации;

· две диаграммы реализации: диаграммы компонентов; диаграммы развертывания.

Методология проектирования ПО на базе языка UML была названа авторами – рациональный унифицированный процесс проектирования [17, 135, 147, 160]. Процессом называется частично упорядоченное множество шагов, направленных на достижение некоторой цели. Рациональный унифицированный процесс итеративен. В центре разработки в рамках этого процесса лежит архитектура. Основное внимание уделяется раннему определению архитектуры программного комплекса и формулированию основных ее особенностей. Фаза - это промежуток времени между двумя важными опорными точками процесса, в которых должны быть достигнуты четко определенные цели и принято решение о переходе к следующей фазе. Внутри каждой фазы происходит несколько итераций. Итерация представляет полный цикл разработки, от выработки требований во время анализа до реализации и тестирования. Все фазы и итерации подразумевают определенные затраты усилий на снижение рисков. В конце каждой фазы находится четко определенная опорная точка, где оценивается, в какой мере достигнуты намеченные цели и не следует ли внести в процесс изменения, прежде чем двигаться дальше. Рациональный унифицированный процесс состоит из следующих четырех фаз.

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

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

3. Построение. В фазе построения постепенно и итеративно разрабатывается продукт, готовый к внедрению. На этом этапе описываются оставшиеся требования и критерии приемки, проект «обрастает плотью», завершается разработка и тестирование программного комплекса. На этой фазе продолжается итеративная работа с диаграммами классов и диаграммами деятельности. А также строятся диаграммы, которые определяют взаимодействие: диаграммы последовательности; диаграммы кооперации. В случае сложного поведения системы разрабатываются диаграммы состояний.

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

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

Методология Шлеер-Меллора использует три группы средств для создания модели предметной области [128].

1. Информационное моделирование — для определения отношений между данными (информацией). При этом используется один тип диаграмм - диаграммы классов.

2. Моделирование состояний — для определения, зависящего от времени поведения системы. Используются диаграммы состояний.

3. Моделирование процессов — для определения функций, которые система должна выполнить. Используются: диаграммы деятельности; диаграммы последовательности.

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

· переход - описывает каждый переход для всех моделей состояний программе;

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

· активный экземпляр - это абстрактный класс, из которого все экземпляры, имеющие модель состояний, наследуют их текущее состояние;

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

Методология Буча Г. базируется на сочетании микропроцесса и макропроцесс разработки [16]. Микропроцесс объектно-ориентированной разработки приводится в движение потоком сценариев и продуктов архитектурного анализа (макропроцесс); микропроцесс представляет ежедневную деятельность команды разработчиков и состоит из четырех шагов:

· идентификация классов и объектов на данном уровне абстракции; основными видами деятельности являются открытие и изобретение;

· выявление семантики классов и объектов; основными видами деятельности здесь являются раскадровка сценариев, проектирование изолированных классов и поиск шаблонов;

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

· реализация классов и объектов; основное действие — выбор структур данных и алгоритмов.

Макропроцесс объектно-ориентированной разработки управляет микропроцессом, определяет измеримые характеристики проекта и помогает контролировать риск. Макропроцесс состоит из пяти шагов.

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

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

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

4. Эволюция. Последовательное приближение системы к желаемому результату. Основные действия — применение микропроцесса и управление изменениями.

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

Далее рассмотрим промышленные методологии проектирования нескольких фирм разработчиков программного обеспечения.

Методология DATARUN является распространенной в мире электронной методологией [19]. В соответствии с этой методологией ЖЦ ПО разбивается на стадии, которые связаны с результатами выполнения основных процессов, определяемых стандартом ISO/EEC 12207. Методология DATARUN опирается на две модели или на два представления: модель организации и модель системы управления. Основной принцип DATARUN заключается в том, что первичные данные, если они должным образом организованы в модель данных, становятся основой для проектирования архитектуры системы. Архитектура системы будет более стабильной, если она основана на первичных данных, тесно связанных с основными деловыми операциями, определяющими природу бизнеса, а не на традиционной функциональной модели. Методология преследует две цели:

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

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

В процессе проектирования системы используется CASE-средство Silverrun, которое обеспечивает автоматизацию проведения проектных работ и последовательное построение следующего комплекса моделей:

· Business Process Model (BPM) - модель бизнес-процессов;

· Primary Data Structure (PDS) - структура первичных данных;

· Conceptual Data Model (CDM) - концептуальная модель данных;

· System Process Model (SPM) - модель процессов системы;

· Information System Architecture (ISA) - архитектура системы;

· Application Data Model (ADM) - модель данных приложения;

· Interface Presentation Model (IPM) - модель представления интерфейса;

· Interface Specification Model (ISM) - модель спецификации интерфейса.

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

1. Создаваемая система должна основываться на функциях, выполняемых организацией. Поэтому первая создаваемая модель - это модель бизнес-процессов, построение которой осуществляется в модуле Silverrun BPM (Business Process Modeler). Для этой модели используется специальная нотация. В процессе анализа и спецификации бизнес-функций выявляются основные информационные объекты, которые документируются как структуры данных, связанные с потоками и хранилищами модели. В процессе обследования работы организации выявляются и документируются структуры первичных данных. Эти структуры заносятся в репозитарий модуля ВРМ при описании циркулирующих в организации документов, сообщений, данных. В модели бизнес-процессов первичные структуры данных связаны с потоками и хранилищами информации.

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

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

4. Перед разработкой приложений должна быть спроектирована структура базы данных. Методология DATARUN предполагает использование базы данных, основанной на реляционной модели. Концептуальная модель данных после нормализации переносится в модуль реляционного моделирования Silverrun RDM с помощью специального моста ERX<—>RDM. После преобразования ERX в RDM получается модель реляционной базы данных. Эта модель детализируется в модуле Silverrun RDM определением физической реализации (типов данных СУБД, ключей, индексов, триггеров, ограничений ссылочной целостности).

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

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

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

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

Методология фирмы ORACLE обеспечивает поддержку полного ЖЦ ПО для систем, использующих СУБД ORACLE, и базируется на интегрированном CASE-средстве Designer/2000 [67] в совокупности со средствами разработки приложений Developer/2000. Базовая методология фирмы ORACLE (CASE*Method) – это структурная методология проектирования систем, охватывающая полностью все этапы ЖЦ ПО [19]. Методология состоит из следующих этапов.

1. На этапе планирования определяются цели создания системы, приоритеты и ограничения, разрабатывается системная архитектура и составляется план разработки системы. В процессе анализа строятся модель информационных потребностей (диаграмма «сущность-связь»), диаграмма функциональной иерархии (на основе функциональной декомпозиции системы), матрица перекрестных ссылок и диаграмма потоков данных. Версия Designer/2000 для объектно-реляционной СУБД ORACLE8 содержит также расширение в виде средств объектного моделирования, базирующихся на стандарте UML.

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

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

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

Средство Designer/2000 обеспечивает графический интерфейс при разработке различных моделей (диаграмм) предметной области. В процессе построения моделей информация о них заносится в репозитарий, физическая среда хранения репозитария - база данных ORACLE.. В состав Designer/2000 входят следующие компоненты:

· Repository Administrator - средства управления репозитарием;

· Repository Object Navigator - средство доступа к репозитарию, обеспечивающее многооконный объектно-ориентированный интерфейс доступа;

· Process Modeler - средство анализа и моделирования деловой деятельности, основывающееся на концепциях реинжиниринга бизнес-процессов (BPR) и глобальной системы управления качеством (TQM);

· Systems Modeler - набор средств построения функциональных и информационных моделей проектируемой системы, включающий средства для построения диаграмм «сущность-связь», диаграмм функциональных иерархий, диаграмм потоков данных и средство анализа и модификации связей объектов репозитария;

· Systems Designer - набор средств проектирования, включающий средство построения структуры реляционной базы данных, а также средства построения диаграмм, отображающих взаимодействие с данными, иерархию, структуру и логику приложений, реализуемую хранимыми процедурами на языке PL/SQL;

· Server Generator - генератор описаний объектов БД ORACLE (таблиц, индексов, ключей, последовательностей и т.д.);

· Forms Generator - генератор приложений для ORACLE Forms. Генерируемые приложения включают в себя различные экранные формы, средства контроля данных, проверки ограничений целостности и автоматические подсказки. Дальнейшая работа с приложением выполняется в среде Developer/2000;

· Repository Reports - генератор стандартных отчетов, интегрированный с ORACLE Reports и позволяющий русифицировать отчеты, а также изменять структурное представление информации.

Методология фирмы Microsoft названа авторами моделью процессов Microsoft Solution Framework(MSF)и представляет собой технологический подход, базирующийся на наборе моделей, правил и спецификаций, применяемых при создании и распространении программных продуктов [128]. Модель процессов MSF возникла на основе используемого в компании Microsoft подхода к разработке ПО. В результате своего развития она объединила ряд наиболее эффективных принципов других известных моделей.

Тремя особенностями MSF являются:

· Подход, основанный на фазах и вехах.Вехи используются как опорные точки для планирования и мониторинга хода проекта. Главные вехи - это моменты ЖЦ проекта, когда полученные на той или иной фазе результаты синхронизируются членами проектной группы друг с другом и с ожиданиями заказчика. В этот момент заказчиком, заинтересованными сторонами и проектной группой производится формальный анализ достигнутого прогресса и достигается согласие продолжать далее работу над проектом.

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

· Интегрированный подход к созданию и внедрению решений.Модель процессов MSF содержит весь ЖЦ создания решения, включая его внедрение.

Рассмотрим фазы модели процессов Microsoft Solution Framework.

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

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

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

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

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

Был проведен анализ работ ряда авторов [1, 5, 33, 65, 70, 71, 94, 137-139, 142, 143, 152, 156, 157], посвященных вопросам разработки моделей, методов и средств проектирования автоматизированных систем управления различными объектами. Проведенный анализ показал, что большинство предлагаемых авторами моделей, методов и средств проектирования разработано для конкретной предметной области и вряд ли может быть использовано для решения поставленной задачи. Впрочем, результаты настоящего исследования также применимы лишь для четко ограниченного класса типовых объектов.