- •Технология программирования
- •Режим доступа к электронному аналогу печатного издания: http://www.Libdb.Sssu.Ru
- •Оглавление
- •Введение
- •1. Основные понятия объектно-ориентированного подхода
- •1.1. Объектно-ориентированная разработка программ
- •1.2. Объектно-ориентированные языки программирования
- •1.3. Сквозной пример
- •Контрольные вопросы
- •2. Первая фаза жизненного цикла – анализ требований и предварительное проектирование системы. Объектно-ориентированное моделирование
- •2.1. Объектная модель системы
- •2.1.1. Объекты и классы
- •2.1.2. Атрибуты объектов
- •2.1.3. Операции и методы
- •2.1.4. Зависимости между классами (объектами)
- •2.1.5. Атрибуты зависимостей
- •Зарегистрирован
- •2.1.6. Имена ролей, квалификаторы
- •2.1.7. Агрегация
- •2.1.8. Обобщение и наследование
- •2.1.9. Абстрактные классы
- •2.1.10. Множественное наследование
- •2.1.11. Связь объектов с базой данных
- •2.2. Построение объектной модели
- •2.2.1. Определение классов
- •2.2.2. Подготовка словаря данных
- •2.2.3. Определение зависимостей
- •2.2.4. Уточнение атрибутов
- •2.2.5. Организация системы классов с использованием наследования
- •2.2.6. Дальнейшее исследование и усовершенствование модели
- •2.3. Пример объектной модели
- •2.3.1. Определение объектов и классов
- •2.3.2. Подготовка словаря данных
- •2.3.3. Определение зависимостей
- •2.3.4. Уточнение атрибутов
- •2.3.5. Организация системы классов с использованием наследования
- •2.3.6. Дальнейшее усовершенствование модели
- •2.4. Выделение подсистем
- •2.4.1. Понятие подсистемы
- •2.4.2. Интерфейсы и окружения
- •2.5. Динамическая модель системы или подсистемы
- •2.5.1. События, состояния объектов и диаграммы состояний
- •2.5.2. Условия
- •2.5.3. Активности и действия
- •2.5.4. Одновременные события. Синхронизация
- •2.5.5. Вложенные диаграммы состояний
- •2.5.6. Динамическая модель банковской сети
- •2.6. Функциональная модель подсистемы
- •2.6.1. Диаграммы потоков данных
- •2.6.2. Описание операций
- •2.6.3. Ограничения
- •2.6.4. Функциональная модель банковской сети
- •2.7. Заключительные замечания к разделу
- •Контрольные вопросы
- •3. Вторая фаза жизненного цикла – конструирование системы
- •3.1. Разработка архитектуры системы
- •3.1.1. Разбиение системы на модули
- •3.1.2. Выявление асинхронного параллелизма
- •3.1.3. Распределение модулей и подсистем по процессорам и задачам
- •3.1.4. Управление хранилищами данных
- •3.1.5. Управление глобальными ресурсами
- •3.1.7. Пограничные ситуации
- •3.1.8. Обзор архитектур прикладных систем
- •3.2. Архитектура системы управления банковской сетью
- •3.3. Разработка объектов
- •3.3.1. Совместное рассмотрение трёх моделей
- •3.3.2. Разработка алгоритмов, реализующих полученные операции
- •3.3.3. Оптимизация разработки
- •3.3.4. Реализация управления
- •3.3.5. Уточнение наследования классов
- •3.3.6. Разработка зависимостей
- •Контрольные вопросы
- •4. Сравнительный анализ объектно-ориентированных методологий разработки программных систем
- •4.1. Методология omt
- •4.2. Методология sa/sd
- •4.3. Методология jsd
- •4.4. Методология osa
- •Аналитические возможности сравниваемых методологий объектно-ориентированного анализа
- •Возможности сравниваемых методов объектно-ориентированного анализа, используемые на этапе разработки системы
- •5. Третья фаза жизненного цикла – реализация объектно-ориентированного проекта
- •5.1. Объектно-ориентированный стиль программирования
- •5.2. Объектно-ориентированные системы программирования
- •5.3.1. Реализация классов
- •5.3.2. Порождение объектов
- •5.3.3. Вызов операций
- •5.3.4. Использование наследования
- •5.3.5. Реализация зависимостей
- •5.4. Другие объектно-ориентированные системы программирования
- •5.4.1. Реализация классов
- •5.4.2. Порождение объектов
- •5.4.3. Вызов операций
- •5.4.4. Реализация наследования
- •5.4.5. Реализация зависимостей
- •5.5. Не объектно-ориентированные системы программирования
- •5.5.1. Преобразование классов в структуры данных
- •5.5.2. Передача параметров методам
- •5.5.3. Размещение объектов в памяти
- •5.5.4. Реализация наследования
- •5.5.5. Выбор методов для операций
- •5.5.6. Реализация зависимостей
- •5.5.7. Объектно-ориентированное программирование на Фортране
- •5.5.8. Чем неудобны не объектно-ориентированные системы программирования
- •Контрольные вопросы
- •Библиографический список
- •Учебное издание
4.4. Методология 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
Аналитические возможности сравниваемых методологий объектно-ориентированного анализа
|
Возможность |
OSA |
OMT |
SA/SD |
JSD |
|
1 |
2 |
3 |
4 |
5 |
|
Объекты: должны иметь индивидуальное и независимое состояние и поведение |
+ |
+ |
+ |
+ |
|
Классы объектов: должны определять свойства своих членов и должны иметь место в памяти |
+ |
+ |
+ |
+ |
|
Множества связей: множества соединений объектов |
+ |
+ |
+ |
+ |
|
Реляционные классы объектов: рассматривают связи как объекты |
+ |
+ |
- |
+ |
|
Полностью интегрированные подмодели: допускаютпроизвольную интеграцию подмоделей анализа; знак «-»в таблице означает, что подмодели, представленные, например, блок-схемами, не могут комбинироваться с другими видами подмоделей (например, моделями поведения) |
+
|
- |
- |
+ |
|
Агрегация: часто используемый механизм абстракции, который представляет взаимосвязи между системами и их частями |
+ |
+ |
+ |
+ |
|
Обобщение/наследование: механизм абстракции: если Aесть специализация B, то свойства A подразумевают свойства B |
+ |
+ |
- |
+ |
|
Полномасштабные ограничения мощности связей: допускают мощности связей, являющихся произвольными множествами неотрицательных целых чисел (не только 1-1, 1-M, M-1, M-M) |
+ |
- |
- |
- |
|
Синонимы и омонимы: допускают несколько имён для одной конструкции и многократное использование одного имени для различных конструкций; полезно при интеграции моделей |
+ |
- |
- |
- |
|
Полная система триггеров: допускаются толькоусловия, только события, или комбинации условий и событий |
+ |
+ |
- |
- |
|
Действия: описывают поведение, которое завершается |
+ |
+ |
+ |
+ |
|
Недетерминированное поведение: описание поведения, которое при отсутствии внешних воздействий может и не завершиться |
+ |
+ |
- |
- |
|
Межобъектный параллелизм: более одного объекта могут быть активными одновременно |
+ |
+ |
+ |
+ |
|
Внутриобъектный параллелизм: в одном объекте допускается одновременное активное существование двух или более трэдов |
+ |
+ |
- |
- |
|
Исключения: допускается обнаружение и обработка условий ошибок |
+ |
- |
- |
- |
|
Временные ограничения: обеспечивают средства ограничения времени на какое-либо действие |
+ |
- |
+ |
+ |
|
Темпоральные условия: поддерживают возможность формулировать условия, ссылающиеся на события в прошлом, настоящем и будущем |
+ |
- |
- |
- |
Окончание табл. 4.1
|
1 |
2 |
3 |
4 |
5 |
|
Метамодель: определяет правильный экземпляр модели |
+ |
- |
- |
- |
|
Родовой класс: параметризация классов – механизм абстракции, помогающий осуществлять анализ, хотя иногда его считают особенностью языка |
- |
- |
- |
- |
|
Взаимодействие данных и событий: обеспечивает возможность объектам посылать и принимать данные и события |
+ |
+ |
+ |
- |
|
Унифицированные взаимодействия: разрешают взаимодействие и по данным, и по событиям одновременно; многие модели разделяют взаимодействия по данным (поток данных) и по событиям |
+ |
- |
- |
- |
|
Детализация взаимодействий: показывает когда и почему объект взаимодействует с другими объектами |
+ |
- |
- |
- |
|
Непрерывные взаимодействия: допускает непрерывный поток информации |
+ |
- |
- |
- |
|
Взаимодействия по бродкастингу: разрешает иметь много приёмников для одной передачи данных или события; бродкастинг разрешен только для данных, но не для событий |
+ |
- |
- |
- |
|
Общее число аналитических возможностей |
29 |
13 |
8 |
9 |
Таблица 4.2