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

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

Методология OMT (Object Modeling Technique) поддерживает две первые стадии ЖЦ ПС. Это не единственная ОО методология разработки ПС. Она была выбрана для демонстрации ОО подхода, потому что является одной из наиболее продвинутых и популярных ОО методологий. Более того, графический язык (система обозначений для диаграмм) методологии 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) поддерживает две первые стадии разработки ПС. Эта методология опирается на программный продукт OMTTool, который позволяет разрабатывать модели проектируемой ПС в интерактивном режиме с использованием многооконного графического редактора и интерпретатора наборов диаграмм, составляемых при анализе требований к системе и ее проектировании с использованием методологии OMT. Таким образом, как только получен достаточно полный набор диаграмм проектируемой ПС, его можно проинтерпретировать и предварительно оценить различные свойства будущей реализации системы. В настоящее время OMTTool входит в состав системы Paradigm+.

Методология 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).

Таблица 4.1. Аналитические возможности сравниваемых методологий ООА

Возможность	OSA	OMT	SA/SD	JSD
Объекты: должны иметь индивидуальное и независимое состояние и поведение	+	+	+	+
Классы объектов: должны определять свойства своих членов и должны иметь место в памяти	+	+	+	+
Множества связей: множества соединений объектов	+	+	+	+
Реляционные классы объектов: рассматривают связи как объекты	+	+	-	+
Полностью интегрированные подмодели: допускают произвольную интеграцию подмоделей анализа; знак "-" в таблице означает, что подмодели, представленные, например, блок-схемами, не могут комбинироваться с другими видами подмоделей (например, моделями поведения)	+	-	-	+
Агрегация: часто используемый механизм абстракции, который представляет взаимосвязи между системами и их частями	+	+	+	+
Обобщение/наследование: механизм абстракции: если A есть специализация B, то свойства A подразумевают свойства B	+	+	-	+
Полномасштабные ограничения мощности связей: допускают мощности связей, являющихся произвольными множествами неотрицательных целых чисел (не только 1-1, 1-M, M-1, M-M)	+	-	-	-
Синонимы и омонимы: допускают несколько имен для одной конструкции и многократное использование одного имени для различных конструкций; полезно при интеграции моделей	+	-	-	-
Полная система триггеров: допускаются только условия, только события, или комбинации условий и событий	+	+	-	-
Действия: описывают поведение, которое завершается	+	+	+	+
Недетерминированное поведение: описание поведения, которое при отсутствии внешних воздействий может и не завершиться	+	+	-	-
Межобъектный параллелизм: более одного объекта могут быть активными одновременно	+	+	+	+
Внутриобъектный параллелизм: в одном объекте допускается одновременное активное существование двух или более трэдов	+	+	-	-
Исключения: допускается обнаружение и обработка условий ошибок	+	-	-	-
Временные ограничения: обеспечивают средства ограничения времени на какое-либо действие	+	-	+	+
Темпоральные условия: поддерживают возможность формулировать условия, ссылающиеся на события в прошлом, настоящем и будущем	+	-	-	-
Метамодель: определяет правильный экземпляр модели	+	-	-	-
Родовой класс: параметризация классов - механизм абстракции, помогающий осуществлять анализ, хотя иногда его считают особенностью языка	-	-	-	-
Взаимодействие данных и событий: обеспечивает возможность объектам посылать и принимать данные и события	+	+	+	-
Унифицированные взаимодействия: разрешают взаимодействие и по данным, и по событиям одновременно; многие модели разделяют взаимодействия по данным (поток данных) и по событиям	+	-	-	-
Детализация взаимодействий: показывает когда и почему объект взаимодействует с другими объектами	+	-	-	-
Непрерывные взаимодействия: допускает непрерывный поток информации	+	-	-	-
Взаимодействия по бродкастингу: разрешает иметь много приемников для одной передачи данных или события; бродкастинг разрешен только для данных, но не для событий	+	-	-	-
Общее число аналитических возможностей

Таблица 4.2.Возможности сравниваемых методов ООА, используемые на этапе разработки системы

Возможность	OSA	OMT	SA/SD	JSD
Значения: имеют состояние, но не имеют поведения и индивидуальности; хотя значения можно считать постоянными объектами, во многих подходах существует различие между пространствами значений и объектов	-	+	+	+
Атрибуты и/или методы: определяют классы объектов в терминах атрибутов и/илиметодов, аналогично тому, как классы объектов определяются в ООЯ	-	+	+	+
Шаблоны классов объектов: шаблоны, по которым создаются экземпляры классов объектов, что подразумевает, что свойства экземпляра объекта определяет класс, а не свойства объекта определяют его класс	-	+	-	+
Абстрактные классы: шаблоны, которые определяют свойства, но не разрешают создавать экземпляры	-	+	+	+
Псевдонаследование: разрешает, чтобы атрибуты и сигнатуры методов подкласса совпадали с атрибутами и сигнатурами методов суперкласса	-	+	+	+
Тождественность по значениям: множества атрибутов (их обычно называют возможными ключами), используемые для определения тождественности объектов	-	+	+	-
Изменение семантики: разрешает переопределять в подклассе семантику методов суперкласса	-	+	+	-
Императивный вызов операций: позволяет вызов метода в отношении клиент-сервер	-	-	-	+
Общее число возможностей по разработке

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

Методология OSA, как и другие методологии, поддерживает три взаимно-ортогональных представления (модели) проектируемой системы:

· модель зависимостей между объектами;

· модель поведения объектов;

· модель взаимодействия объектов.

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

Рис. 4.1. Модель зависимостей между объектами для системы управления топкой в теплоцентрали

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

Рис. 4.2. Поведение объекта "термостат"

Модель взаимодействия объектов - это набор представлений проектируемой системы, на которых показаны взаимодействия объектов между собой и с окружением системы (см. рис. 4.3).

Рис. 4.3. Различные представления модели топки

Интерпретация и анализ представлений (моделей) проектируемой системы позволяет полностью формализовать описания объектов и получить строгую формальную спецификацию проектируемой системы до начала ее разработки (см. рис. 4.4).

Рис. 4.4. Формальная модель топки, разработанная с помощью методологии OSA

⇐ Предыдущая234567891011Следующая ⇒

Поделиться:

Воспользуйтесь поиском по сайту: