- •Технология программирования
- •Режим доступа к электронному аналогу печатного издания: 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.5. Вложенные диаграммы состояний
Диаграмма состояний компонента трансмиссия (рис. 2.50) имеет узел (состояние) вперёд, который сам является диаграммой состояний (вложенная диаграмма состояний). Интерпретация этой диаграммы следующая: трансмиссия имеет три состояния: нейтральное, назад и вперёд; состояние вперёд имеет три подсостояния (они уточняют состояние вперёд): первая, вторая и третья скорости. На диаграммах состояний суперсостояние изображается как прямоугольник с закруглёнными углами, внутрь которого помещаются все его подсостояния.
2.5.6. Динамическая модель банковской сети
В качестве примера применения рассмотренных принципов построения динамической модели построим динамическую модель банковской сети. Начнём с составления и изучения сценариев.
ATM просит клиента вставить карточку
клиент вставляет карточку
ATM принимает карточку и читает её номер
ATM просит ввести пароль
клиентвводит «1234.»
ATM передаёт номер и пароль в консорциум,
консорциум проверяет номер и пароль,
определяет код банка – «39» и сообщает ATM, что запрос принят
ATM просит клиента (с помощью меню на экране) выбрать вид
проводки
(снятие, вклад, перевод, запрос)
клиент выбирает снятие
ATM спрашивает клиента, какова требуемая сумма
клиентвводит $100
ATM убеждается, что введённая сумма в пределах лимита и
просит консорциум выполнить проводку,
консорциум передаёт запрос в банк,
банквыполняет проводку и возвращает новое значение баланса
счёта
ATM выдаёт сумму и просит клиента взять её
клиентберёт деньги
ATM спрашивает, не нужно ли клиенту что-то ещё
клиент вводит нет
ATM печатает счёт, выдаёт карточку и просит клиента взять их
клиентберёт счёт и карточку
ATM просит (другого) клиента ввести карточку
Рис. 2.53. Нормальный сценарий для банковской сети
На рисунке 2.53 представлен нормальный сценарий обслуживания клиента в банковской сети; один из возможных сценариев, содержащих исключительные ситуации, показан на рисунке 2.54.
Для каждого сценария можно составить соответствующую трассу событий (рис. 2.55). Для этого выделяем в сценарии имена событий (событиями являются все сигналы, вводы данных, решения, прерывания, переходы и действия, выполняемые клиентом или внешними устройствами), указывая для каждого события объект, порождающий это событие (активный объект).
Имея трассы событий, можно построить диаграммы состояний объектов проектируемой системы. Банковская сеть есть агрегация определённого числа параллельно и независимо работающих объектов четырёх классов: консорциум, банк, ATM (банкомат) и клиент; поэтому состояние банковской сети определяется как кортеж состояний составляющих её объектов: 1 – объекта класса консорциум, b – объектов класса банк, a – объектов класса ATM (банкомат) и c – объектов класса клиент (a, b, c – количество ATM, банков и клиентов сети соответственно). Классификация объектов, используемая при объектно-ориентированном подходе, позволяет вместо a+b+1 диаграмм состояний построить всего три (диаграммы состояний клиентов строить не нужно, так как их текущее состояние ясно и так).
ATM просит клиента вставить карточку
клиент вставляет карточку
ATM принимает карточку и читает её номер
ATM просит ввести пароль
клиент вводит «9999.»
ATM передаёт номер и пароль в консорциум;
консорциум, проконсультировавшись с соответствующим
банком, отвергает запрос
ATM сообщает, что пароль введён неверно
клиент вводит «1234.»
ATM передаёт номер и пароль в консорциум,
консорциум проверяет номер и пароль,
определяет код банка – «39» и сообщает ATM, что запрос
принят
ATM просит выбрать вид проводки
клиент выбирает снятие
ATM спрашивает, какова требуемая сумма
клиент (раздумав брать деньги) набирает отмену
ATM выдаёт карточку и просит клиента взять её
клиент берёт карточку
ATM просит (другого) клиента вставить карточку
Рис. 2.54. Сценарий для банковской сети,
содержащий исключительные ситуации
Построение диаграмм состояний начинается с привязки событий к объектам банковской сети (см. рис. 2.56), являющимся источниками этих событий. Сначала рассматриваются нормальные события, потом исключительные. Построение диаграммы состояний объекта (класса) может считаться законченным, когда диаграмма охватывает все рассматриваемые сценарии.
Рис. 2.55. Трасса событий в банковской сети
Рис. 2.56. Привязка событий к объектам банковской сети
Диаграммы состояний объектов классов ATM (банкомат), консорциум и банк представлены на рисунках 2.57, 2.58 и 2.59 соответственно.
Рис. 2.57. Диаграмма состояний объектов класса ATM (банкомат)
Рис. 2.58. Диаграмма состояний объектов класса консорциум
Рис. 2.59. Диаграмма состояний объектов класса банк