![](/user_photo/2706_HbeT2.jpg)
- •Технология программирования
- •Режим доступа к электронному аналогу печатного издания: 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.5.2. Условия
Условие – это логическая (булева) функция от значений объектов, как, например, карточку удалось прочитать, температура ниже нуля и т.п. Условие может выполняться в течение некоторого отрезка времени; событие, в отличие от условия, происходит мгновенно и не имеет продолжительности во времени.
Условия могут использоваться как ограничения на переходы: условный переход выполняется только тогда, когда и произошло соответствующее событие, и выполнено условие этого перехода (диаграмма состояний, представленная на рисунке 2.47, демонстрирует это на примере автомобильного движения по магистралям «Север-Юг» и «Запад-Восток»). На диаграммах состояний условия записываются вслед за событиями в квадратных скобках.
Рис. 2.47. Диаграмма состояний, на которой указаны условия
2.5.3. Активности и действия
Диаграмма состояний была бы не очень полезной, если бы она содержала только переходы (безусловные и условные), соответствующие генерируемым во время работы системы событиям. Являясь описанием поведения объекта, диаграмма состояний должна описывать, что делает объект в ответ на переход в некоторое состояние или на возникновение некоторого события. Для этого в диаграмму состояний включаются описания активностей и действий.
Действием называется мгновенная операция, связанная с событием: при возникновении события происходит не только переход объекта в новое состояние, но и выполняется действие, связанное с этим событием. Например, в телефонной сети событие повесил трубку сопровождается действием разъединить связь (см. рис. 2.49). Действие указывается на диаграмме состояний вслед за событием, которому оно соответствует, и его имя (или описание) отделяется от имени события косой чертой («/») (рис. 2.48).
Рис. 2.48. Диаграмма состояний телефонной линии,
на которой указаны активности и действия
Действия могут также представлять внутренние операции управления объекта, как, например, присваивание значений атрибутам или генерация других событий.
Активностью называется операция, связанная с каким-либо состоянием объекта (она выполняется, когда объект попадает в указанное состояние); выполнение активности требует определённого времени. Примеры активностей: выдача картинки на экран телевизора, телефонный звонок, считывание порции файла в буфер и т.п.; иногда активностью бывает просто приостановка выполнения программы (пауза), чтобы обеспечить необходимое время пребывания в соответствующем состоянии (это бывает особенно важно для параллельной асинхронной программы).
Рис. 2.49. Указание активностей и действий на диаграмме состояний
Активность связана с состоянием, поэтому на диаграмме состояний она обозначается через «do: имя активности» в узле, описывающем соответствующее состояние (см. рис. 2.48).
2.5.4. Одновременные события. Синхронизация
На рисунке 2.50 представлена диаграмма состояний составного объекта: он состоит из четырёх параллельно и независимо работающих компонентов (состояние каждого компонента не зависит от состояний остальных компонентов).
Рис. 2.50. Диаграмма состояний составного объекта (подсистемы)
Состояние такого объекта определяется как кортеж, членами которого являются состояния каждого из составляющих объектов. Диаграмма состояний при этом распадается на четыре независимые диаграммы состояний каждого из компонентов. В системах, состоящих из нескольких параллельно работающих объектов, иногда бывает необходимо согласовать (синхронизировать) работу двух или более объектов. Для этого тоже используются события, так как синхронизация по существу состоит в необходимости задержать переход одного из синхронизируемых объектов в очередное состояние, пока другой объект не придёт в некоторое фиксированное состояние, а переходы из состояния в состояние управляются событиями. Синхронизирующее событие может вырабатываться в любом из синхронизируемых объектов либо в каком-либо третьем объекте.
Если синхронизирующее событие вырабатывается вне синхронизируемого объекта, оно может быть передано ему из другого объекта; на диаграмме это обозначается, как показано на рисунке 2.51.
Рис. 2.51. Передача события из одного объекта другому
Если объект получает события из нескольких независимых объектов, то состояние, в которое он перейдёт, может зависеть от порядка, в котором будут получены эти события (а этот порядок случаен, так как объекты независимы). Это называется условием конкуренции. Одной из задач проектирования является исключение нежелательных условий конкуренции. Это достигается с помощью синхронизации.
Синхронизация используется и в случае, когда в каком-либо состоянии требуется параллельно выполнить несколько активностей. В качестве примера рассмотрим устройство вывода ATM (рис. 2.52). Оно одновременно (параллельно) выдаёт наличные деньги и карточку; обе эти операции можно рассматривать как составную активность, состоящую из двух параллельно работающих активностей (пунктирная линия на диаграмме состояний делит состояние на две области, в каждой из которых выполняется одна из указанных активностей). Разделение управления на два параллельных потока схематически показано в виде стрелки, которая разделяется на две: событие готов вызывает переход из состояния установка сразу в два параллельных подсостояния состояния выдача; переход в следующее состояние происходит по двум событиям деньги взяты и карточка взята; если какое-либо из этих событий произойдет раньше другого, перехода всё равно не будет, пока не произойдёт и второе событие (в этом и состоит синхронизация).
Рис. 2.52. Синхронизация в подсистеме
Из рассмотренного примера видно, что в различных состояниях может параллельно работать разное число процессов (активностей).