Объектно-ориентированных методологий разработки программных систем

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

Методология OMT (Object Modeling Technique), которая была подробно рассмотрена в разделах 2 и 3, поддерживает две первые стадии жизненного цикла программных систем. Это не единственная объектно-ориентированная методология разработки программных систем. Она была выбрана для демонстрации объектно-ориентированного подхода, потому что является одной из наиболее продвинутых и популярных объектно-ориентированных методологий. Более того, графический язык (система обозначений для диаграмм) методологии OMT получил достаточно широкое распространение и используется в некоторых других объектно-ориентированных методологиях, а также в большинстве публикаций по объектно-ориентированным методологиям.

В этом разделе мы рассмотрим другие объектно-ориентированные методологии разработки программных систем. Они будут сравниваться с методологией OMT. В последнее время интерес к объектно-ориентиро-ванным методологиям разработки программных систем продолжает возрастать: много публикаций в журналах, докладов на конференциях и т.д. Программное обеспечение объектно-ориентированных методологий стало настолько популярным, что все интересные инструментальные и CASE-системы давно исчезли из public domain и распространяются только как коммерческие системы. Наиболее известной такой системой является система Paradigm+, которая поддерживает восемь объектно-ориентированных методологий, в том числе методологию OMT.

В этом разделе будут рассмотрены следующие объектно-ориентиро-ванные методологии анализа и разработки программных систем: OMT (Object Modeling Technique), SA/SD (Structured Analysis/Structured Design), JSD (Jackson Structured Development), OSA (Object-Oriented System Analysis), Проклос (Проектирование в кластерной среде).

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

 

Методология OMT (Object Modeling Technique), достаточно подробно рассмотренная в разделах 2 и 3, поддерживает две первые стадии разработки программных систем. Эта методология опирается на программный продукт OMTTool, который позволяет разрабатывать модели проектируемой программной системы в интерактивном режиме с использованием многооконного графического редактора и интерпретатора наборов диаграмм, составляемых при анализе требований к системе и её проектировании с использованием методологии OMT. Таким образом, как только получен достаточно полный набор диаграмм проектируемой программной системы, его можно проинтерпретировать и предварительно оценить различные свойства будущей реализации системы. В настоящее время OMTTool входит в состав системы Paradigm+.

4.2. Методология SA/SD

 

Методология SA/SD (Structured Analysis/Structured Design) содержит несколько вариантов систем обозначений для формальной спецификации программных систем. На этапе анализа требований и предварительного проектирования для логического описания проектируемой системы используются спецификации (формальные описания) процессов, словарь данных, диаграммы потоков данных, диаграммы состояний и диаграммы зависимостей объектов.

Диаграммы потоков данных (они подробно рассмотрены в п. 2.5.1), составляющие основу методологии SA/SD, моделируют преобразования данных при их прохождении через систему. Методология SA/SD состоит в последовательном рассмотрении процессов, входящих в состав ДПД, с представлением каждого процесса через ДПД, содержащую в своём составе более простые процессы. Эта процедура представления более сложных процессов через ДПД начинается с ДПД всей системы и заканчивается, когда все полученные ДПД содержат достаточно элементарные процессы. Для каждого процесса самого нижнего уровня составляется спецификация; спецификация описывается с помощью псевдокода, таблиц принятия решений и т.п.

Детали, не учтённые в наборе ДПД, содержатся в словаре данных, который определяет потоки и хранилища данных, а также семантику различных имён.

Набор диаграмм состояния процессов играет ту же роль, что и динамическая модель в методологии OMT.

Диаграммы зависимостей объектов отражают зависимости между хранилищами данных. Эти диаграммы аналогичны объектной модели методологии OMT.

Так, в методологии SA/SD организован этап структурного анализа (SA). После структурного анализа начинается этап структурного конструирования (SD), в процессе которого разрабатываются и уточняются более тонкие детали проектируемой системы.

Таким образом, мы видим, что у методологий SA/SD и OMT много общего: обе методологии используют похожие конструкции для моделирования и поддерживают три взаимно-ортогональных представления проектируемой системы. Методологии SA/SD и OMT можно рассматривать как два способа использования инструментального средства – OMTTool.

Но в методологии SA/SD ведущей является функциональная модель (набор ДПД), на втором месте по важности стоит динамическая модель и на последнем месте – объектная модель. Таким образом, в методологии SA/SD проектируемая система описывается с помощью процедур (процессов), что несколько противоречит объектно-ориентированному подходу. Методология OMT гораздо ближе к нему: в ней моделирование концентрируется вокруг объектной модели, т.е. вокруг объектов, из которых строится проектируемая система.

Процедурная ориентированность методологии SA/SD является её недостатком: системы, спроектированные по этой методологии, имеют менее чёткую структуру, так как разбиение процесса на подпроцессы во многом произвольно, зависит от реализации и плохо отражает структуру проектируемой системы.

В то же время методология SA/SD является одним из первых хорошо продуманных формальных подходов к разработке программных систем.

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

 

Методология JSD (Jackson Structured Development) предлагает свой стиль разработки программных систем; он отличается от стиля, принятого в методологиях SA/SD или OMT. Методология JSD, разработанная Майклом Джексоном в середине 80-х годов, особенно популярна в Европе. В методологии JSD не делается различий между этапом анализа требований к системе и этапом её разработки; оба этапа объединяются в один общий этап разработки спецификаций проектируемой системы. На этом этапе решается вопрос «что должно быть сделано»; вопрос «как это должно быть сделано» решается на следующем этапе – реализации системы. Методология JSD часто применяется для проектирования систем реального времени.

Как и другие методологии, методология JSD использует систему графических обозначений, хотя эта методология и менее ориентирована на графику, чем методологии SA/SD и OMT.

Разработка модели JSD начинается с изучения объектов реального мира. Целью системы является обеспечение требуемой функциональности, но Джексон понимает, что сначала следует убедиться, что эта функциональность согласуется с реальным миром. Модель JSD описывает реальный мир в терминах сущностей (объектов), действий и порядка выполнения действий. Разработка системы по методологии JSD включает следующие шесть фаз:

­ разработка действий и объектов;

­ разработка структуры объектов;

­ разработка исходной модели;

­ разработка функций;

­ разработка временных ограничений;

­ реализация системы.

На фазе разработки действий и объектов разработчик, руководствуясь внешними требованиями к проектируемой системе, составляет перечень сущностей (объектов) и действий реального мира, связанных с этой системой. Так, например, проектируя систему управления двумя лифтами в шестиэтажном доме, можно выделить два объекта «лифт» и «кнопка» и три действия – «нажатие кнопки», «лифт приходит на этаж n» и «лифт покидает этаж n». И объекты, и действия взяты из реального мира, а не искусственно введены в рассмотрение проектировщиком. Все действия являются атомарными (неразложимыми на поддействия) и происходят в фиксированные моменты времени.

На фазе разработки структуры объектов действия каждого объекта частично упорядочиваются во времени. Так, в рассматриваемом примере действия «лифт приходит на этаж n» и «лифт покидает этаж n» должны чередоваться: два действия «лифт приходит на этаж n» не могут идти одно за другим.

Фаза разработки исходной модели связывает реальный мир с абстрактной моделью, устанавливая соответствие между вектором состояния и потоком данных. Вектор состояния обеспечивает «развязку» по управлению; так, в примере с лифтами первая же нажатая кнопка вверх установит значение переключателя (флажка) «вверх», после чего лифт не будет реагировать на дальнейшие нажатия кнопок вверх, так что нажатие кнопки вверх один или пять раз приведёт к одинаковому результату. Аналогично, поток данных позволяет обеспечить «развязку» по данным: примером может служить буфер файла.

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

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

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

Методология JSD может быть названа объектно-ориентированной с большой натяжкой: в ней почти не рассматривается структура объектов, мало внимания уделяется их атрибутам. Некоторые действия в смысле методологии JSD являются, по существу, зависимостями между объектами в смысле методологии OMT.

Тем не менее, методология JSD может успешно применяться для проектирования и реализации следующих типов прикладных программных систем:

- Параллельные асинхронные программные системы, в которых процессы могут взаимно синхронизировать друг друга.

- Программные системы реального времени; методология JSD ориентирована именно на такие системы.

- Программные системы для параллельных компьютеров; парадигма, принятая в методологии JSD может здесь оказаться полезной.

- Методология JSD плохо приспособлена для решения следующих проблем:

- Высокоуровневый анализ: методология JSD не обеспечивает широкого понимания проблемы; она неэффективна для абстракции и упрощения проблем.

- Разработка баз данных: это слишком сложная проблема для методологии JSD.

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

 

Методология OSA (Object-Oriented System Analysis) обеспечивает объектно-ориентированный анализ программных систем и не содержит возможностей, связанных с поддержкой этапа разработки.

Методологии объектно-ориентированного анализа нередко критикуются за то, что они являются больше реализационно-ориентированными, чем проблемно-ориентированными, обеспечивая больше предварительную разработку, чем анализ требований к системе. Действительно, все рассмотренные методологии (такие как OMT, SA/SD, JSD) поддерживают прежде всего предварительную разработку программных систем, а не анализ требований к ним. Это следует из таблиц 4.1 и 4.2, в которых рассмотрены возможности различных методологий, поддерживающие процесс анализа (табл. 4.1) и процесс разработки (табл. 4.2).

Методология OSA сосредоточена только на проблемах анализа, предлагая ряд интересных соображений, связанных с объектно-ориен-тированным анализом систем, и специально исключая из рассмотрения особенности, характерные для разработки. Предлагая удобные и тонкие методы анализа систем, методология OSA обеспечивает интерпретацию моделей на компьютере на самых ранних этапах анализа системы: OSA реализована в системе программирования C++ на рабочей станции Hewlett-Packard 700 под управлением ОС HP-UX 9.01.

Таблица 4.1