Возможности сравниваемых методов объектно-ориентированного анализа, используемые на этапе разработки системы

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

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

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

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

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

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

Рис. 4.1. Модель зависимостей между объектами

для системы управления топкой в теплоцентрали

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

а)

	б)

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

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

г)

в)

б)

а)

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

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

с помощью методологии OSA

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

Контрольные вопросы

1. Итеративная и инкрементальная разработка.

2. Методология разработки Rational Unified Process: стадии разработки и примеры.

3. Методология создания ПО Microsoft Solutions Framework: стадии разработки и примеры.

4. Экстремальное программирование: этапы методологии и примеры.

5. Третья фаза жизненного цикла – реализация объектно-ориентированного проекта

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

Каждый язык программирования имеет средства для выражения трёх сторон спецификации разрабатываемой прикладной системы: структур данных, потоков управления и функциональных преобразований. В этом разделе будут рассмотрены проблемы, решаемые на этапе реализации объектно-ориентированного проекта, разработанного с использованием методологии OMT.