- •Технология программирования
- •Режим доступа к электронному аналогу печатного издания: 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. Чем неудобны не объектно-ориентированные системы программирования
- •Контрольные вопросы
- •Библиографический список
- •Учебное издание
2.2.4. Уточнение атрибутов
На следующем этапе уточняется система атрибутов: корректируются атрибуты классов, вводятся, в случае необходимости, новые атрибуты. Атрибуты выражают свойства объектов рассматриваемого класса, либо определяют их текущее состояние.
Атрибуты обычно соответствуют существительным; например, цвет автомобиля (свойство объекта), позиция курсора (состояние объекта). Атрибуты, как правило, слабо влияют на структуру объектной модели.
Не следует стремиться определить как можно больше атрибутов: большое количество атрибутов усложняет модель, затрудняет понимание проблемы. Необходимо вводить только те атрибуты, которые имеют отношение к проектируемой прикладной системе, опуская случайные, малосущественные и производные атрибуты.
Наряду с атрибутами объектов необходимо ввести и атрибуты зависимостей между классами (связей между объектами).
При уточнении атрибутов руководствуются следующими критериями:
Замена атрибутов на объекты. Если наличие некоторой сущности важнее, чем её значение, то это объект, если важнее значение, то это атрибут: например, начальник – это объект (неважно, кто именно начальник, главное, чтобы кто-то им был), зарплата – это атрибут (её значение весьма существенно); город – всегда объект, хотя в некоторых случаях может показаться, что это атрибут (например, город как часть адреса фирмы); в тех случаях, когда нужно, чтобы город был атрибутом, следует определить зависимость (скажем, находится) между классами фирма и город.
Квалификаторы. Если значение атрибута зависит от конкретного контекста, его следует сделать квалификатором (см. примеры в п. 2.3.4).
Имена. Именам обычно лучше соответствуют квалификаторы, чем атрибуты объектов; во всех случаях, когда имя позволяет сделать выбор из объектов некоторого множества, его следует сделать квалификатором (см. примеры в п. 2.3.4).
Идентификаторы. Идентификаторы объектов связаны с их реализацией. На ранних стадиях проектирования их не следует рассматривать в качестве атрибутов.
Атрибуты связей. Если некоторое свойство характеризует не объект сам по себе, а его связь с другим объектом (объектами), то это атрибут связи, а не атрибут объекта.
Внутренние значения. Атрибуты, определяющие лишь внутреннее состояние объекта, незаметное вне объекта, следует исключить из рассмотрения.
Несущественные детали. Атрибуты, не влияющие на выполнение большей части операций, рекомендуется опустить.
2.2.5. Организация системы классов с использованием наследования
Далее необходимо постараться найти суперклассы для введённых классов. Это полезно, так как проясняет структуру модели и облегчает последующую реализацию. Соответствующий пример рассмотрен в п. 2.3.5.
2.2.6. Дальнейшее исследование и усовершенствование модели
Лишь в очень редких случаях построенная объектная модель сразу же оказывается корректной. Модель должна быть исследована и отлажена. Некоторые ошибки могут быть найдены при исследовании модели без компьютера, другие – при её интерпретации совместно с динамической и функциональной моделями на компьютере (эти модели строятся после того, как объектная модель уже построена).
Здесь мы рассмотрим приёмы бескомпьютерного поиска и исправления ошибок в объектной модели. В их основе лежат внешние признаки, по которым можно находить ошибки в модели; эти признаки могут быть объединены в следующие группы.
Признаки пропущенного объекта (класса):
несимметричности связей и обобщений (наследований); для исправления ошибки необходимо добавить пропущенные классы;
несоответствие атрибутов и операций у класса; для исправления ошибки необходимо расщепить класс на несколько других классов, так чтобы атрибуты и операции новых классов соответствовали друг другу;
обнаружена операция, не имеющая удовлетворительного целевого класса; для исправления ошибки необходимо добавить пропущенный целевой класс;
обнаружено несколько зависимостей с одинаковыми именами и назначением; для исправления ошибки необходимо сделать обобщение и добавить пропущенный суперкласс.
Признаки ненужного (лишнего) класса:
нехватка атрибутов, операций и зависимостей у некоторого класса; для исправления ошибки необходимо подумать, не следует ли исключить такой класс.
Признаки пропущенных зависимостей:
отсутствуют пути доступа к операциям; для исправления ошибки необходимо добавить новые зависимости, обеспечивающие возможности обслуживания соответствующих запросов.
Признаки ненужных (лишних) зависимостей:
избыточная информация в зависимостях; для исправления ошибки необходимо исключить зависимости, не добавляющие новой информации, или пометить их как производные зависимости;
не хватает операций, пересекающих зависимость; для исправления ошибки необходимо подумать, не следует ли исключить такую зависимость.
Признаки неправильного размещения зависимостей:
имена ролей слишком широки или слишком узки для их классов; для исправления ошибки необходимо переместить зависимость вверх или вниз по иерархии классов.
Признаки неправильного размещения атрибутов:
нет необходимости доступа к объекту по значениям одного из его атрибутов; для исправления ошибки необходимо рассмотреть, нужно ли ввести квалифицированную зависимость.
Примеры практического применения описанных признаков см. в п. 2.3.6.