- •Технология программирования
- •Режим доступа к электронному аналогу печатного издания: 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.1.5. Атрибуты зависимостей
Зависимости, как и классы, могут иметь атрибуты: например, при организации доступа пользователя к файлу разрешение на доступ является атрибутом зависимости доступен (рис. 2.10), на котором атрибут зависимости обозначается прямоугольником, связанным дугой с прямой, изображающей зависимость. Такое обозначение атрибутов зависимостей принято в технологии OMT. Отметим, что разрешение на доступ связано как с пользователем, так и с файлом и не может быть атрибутом ни пользователя, ни файла в отдельности.

Рис. 2.10. Пример атрибута зависимости
Ещё один пример зависимостей, имеющих атрибуты, показан на рисунке 2.11. Из примера видно, что зависимость может иметь несколько атрибутов. Кроме того, здесь указаны роли различных объектов в зависимости (подробнее см. ниже). Зависимость руководит на этом рисунке удобнее именовать как начальник-сотрудник.

Рис. 2.11. Атрибуты двух зависимостей между одним и многими
Иногда зависимости, имеющие много атрибутов, представляют с помощью классов. Такие зависимости в базах данных представляются временными таблицами, организуемыми в процессе обращения с базой данных. Пример зависимости, представленной через класс, показан на рисунке 2.12, на котором представлена информация о регистрации пользователей на рабочих станциях.
Зарегистрирован
Рис. 2.12. Представление зависимости в виде класса
Пользователь может быть зарегистрирован на нескольких рабочих станциях, каждая регистрация содержит приоритет пользователя и его привилегии доступа (атрибуты зависимости). Пользователь может иметь свою директорию для каждой зарегистрированной рабочей станции, но одна и та же директория может принадлежать одновременно нескольким пользователям или нескольким рабочим станциям.
2.1.6. Имена ролей, квалификаторы
Роль определяет одну сторону зависимости. В бинарной зависимости определены две роли. Имя роли однозначно определяет одну сторону зависимости. Роли дают возможность рассматривать бинарную зависимость как связь между объектом и множеством зависимых объектов: каждая роль является обозначением объекта или множества объектов, связанных зависимостью с объектом на другом конце зависимости. Имя роли можно рассматривать как производный атрибут, множеством значений которого является множество связанных с этой ролью объектов. В бинарной зависимости пара имён ролей может использоваться для идентификации этой зависимости.
На рисунке 2.11имена начальник и сотрудник в зависимости руководит – это имена ролей; как уже было отмечено, эту зависимость удобнее назвать начальник-сотрудник. Ещё один пример имён ролей показан на рисунке 2.13.
Пользователь может быть либо владельцем, либо зарегистрированным пользователем директории; директория может содержать в себе другие директории.

Рис. 2.13. Имена ролей
Имена ролей следует обязательно указывать в тех случаях, когда зависимость устанавливается между объектами одного и того же класса (как в случаях, показанных на рисунках 2.11и 2.13). Имена ролей должны быть уникальны, так как они используются для различения объектов, участвующих в зависимости.
Квалификатором называется некоторый атрибут, который позволяет снизить эффективную кратность зависимости. Квалификаторы применяются в зависимостях типов «один-ко-многим» или «много-ко-многим». Так, в примере, показанном на рисунке 2.14, использование квалификатора имя файла позволяет привести зависимость даёт доступ от вида, приведённого на рисунке 2.14а, к виду, показанному на рисунке 2.14б, сократив число зависимых объектов до одного. Ещё один пример использования квалификатора показан на рисунке 2.14в: использование квалификаторов и здесь позволяет сократить кратность зависимости до одного объекта. Квалификаторы указываются на схемах в прямоугольничках, пририсованных к прямоугольнику, изображающему соответствующий класс.
а)
б)
в)
Рис. 2.14. Использование квалификаторов
Рисунок 2.14в может быть проинтерпретирован следующим образом: центральный компьютер + код ATM определяют конкретную ATM (отметим, что код АTM – имя одного из атрибутов класса ATM, а не класса центральный компьютер); аналогично центральный компьютер + код банка определяют конкретный компьютер банка. Использование квалификаторов повышает точность описания семантики и наглядность описания зависимостей.
