Методология 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) | + | - | - | - |
| Синонимы и омонимы: допускают несколько имен для одной конструкции и многократное использование одного имени для различных конструкций; полезно при интеграции моделей | + | - | - | - |
| Полная система триггеров: допускаются только условия, только события, или комбинации условий и событий | + | + | - | - |
| Действия: описывают поведение, которое завершается | + | + | + | + |
| Недетерминированное поведение: описание поведения, которое при отсутствии внешних воздействий может и не завершиться | + | + | - | - |
| Межобъектный параллелизм: более одного объекта могут быть активными одновременно | + | + | + | + |
| Внутриобъектный параллелизм: в одном объекте допускается одновременное активное существование двух или более трэдов | + | + | - | - |
| Исключения: допускается обнаружение и обработка условий ошибок | + | - | - | - |
| Временные ограничения: обеспечивают средства ограничения времени на какое-либо действие | + | - | + | + |
| Темпоральные условия: поддерживают возможность формулировать условия, ссылающиеся на события в прошлом, настоящем и будущем | + | - | - | - |
| Метамодель: определяет правильный экземпляр модели | + | - | - | - |
| Родовой класс: параметризация классов - механизм абстракции, помогающий осуществлять анализ, хотя иногда его считают особенностью языка | - | - | - | - |
| Взаимодействие данных и событий: обеспечивает возможность объектам посылать и принимать данные и события | + | + | + | - |
| Унифицированные взаимодействия: разрешают взаимодействие и по данным, и по событиям одновременно; многие модели разделяют взаимодействия по данным (поток данных) и по событиям | + | - | - | - |
| Детализация взаимодействий: показывает когда и почему объект взаимодействует с другими объектами | + | - | - | - |
| Непрерывные взаимодействия: допускает непрерывный поток информации | + | - | - | - |
| Взаимодействия по бродкастингу: разрешает иметь много приемников для одной передачи данных или события; бродкастинг разрешен только для данных, но не для событий | + | - | - | - |
| Общее число аналитических возможностей | 29 | 13 | 8 | 9 |
Таблица 4.2.Возможности сравниваемых методов объектно-ориентированного анализа, используемые на этапе разработки системы
| Возможность | OSA | OMT | SA/SD | JSD |
| Значения: имеют состояние, но не имеют поведения и индивидуальности; хотя значения можно считать постоянными объектами, во многих подходах существует различие между пространствами значений и объектов | - | + | + | + |
| Атрибуты и/или методы: определяют классы объектов в терминах атрибутов и/или методов, аналогично тому, как классы объектов определяются в объектно-ориентированных языках | - | + | + | + |
| Шаблоны классов объектов: шаблоны, по которым создаются экземпляры классов объектов, что подразумевает, что свойства экземпляра объекта определяет класс, а не свойства объекта определяют его класс | - | + | - | + |
| Абстрактные классы: шаблоны, которые определяют свойства, но не разрешают создавать экземпляры | - | + | + | + |
| Псевдонаследование: разрешает, чтобы атрибуты и сигнатуры методов подкласса совпадали с атрибутами и сигнатурами методов суперкласса | - | + | + | + |
| Тождественность по значениям: множества атрибутов (их обычно называют возможными ключами), используемые для определения тождественности объектов | - | + | + | - |
| Изменение семантики: разрешает переопределять в подклассе семантику методов суперкласса | - | + | + | - |
| Императивный вызов операций: позволяет вызов метода в отношении клиент-сервер | - | - | - | + |
| Общее число возможностей по разработке | 0 | 7 | 6 | 6 |
Методология 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
Назад | Содержание | Вперед