![](/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.3.4. Уточнение атрибутов
Применяя критерии, сформулированные в п. 2.2.4, получим:
Карточка содержит код банка и код карточки; их можно считать атрибутами объектов класса карточка, но удобнее использовать в качестве квалификаторов, так как код банка обеспечивает выбор банка, сокращая кратность зависимости консорциум – банк; для аналогичного использования кода карточки необходимо добавить зависимость Банк выпускает карточки, квалификатором которой будет код карточки.
После внесения перечисленных изменений диаграмма примет вид, представленный на рисунке 2.38.
Рис. 2.38. Объектная диаграмма для банковской сети
после уточнения атрибутов и добавления квалификаторов
2.3.5. Организация системы классов с использованием наследования
В рассматриваемом примере естественно определить суперклассы для объектов, определяющих различные терминалы: кассовый терминал и ATM (банкомат), и для объектов, определяющих проводки: проводка кассира и удалённая проводка (с банкомата).
Внеся соответствующие изменения, получим объектную диаграмму, представленную на рисунке 2.39.
Рис. 2.39. Объектная диаграмма для банковской с учётом наследования
2.3.6. Дальнейшее усовершенствование модели
Карточка выступает в двух сущностях: как регистрационная единица в банке (сберкнижка), обеспечивающая клиенту доступ к его счетам, и как структура данных, с которой работает ATM. Поэтому удобно расщепить класс карточка на два класса: регистрация карточки и карточка; первый из этих классов обеспечивает клиенту доступ к его счетам в банке, а второй определяет структуру данных, с которой работает ATM.
Класс проводка удобно представить как агрегацию классов изменение, так как проводка – это согласованная последовательность внесения изменений в счета и другие банковские документы; при работе с банковскими документами рассматривается три вида изменений: снятие, помещение и запрос.
Класс банк естественно объединить с классом компьютер банка, а класс консорциум – с классом центральный компьютер.
Рис. 2.40. Окончательный вид объектной диаграммы для банковской сети
После внесения перечисленных изменений объектная диаграмма примет вид, представленный на рисунке 2.40. На этом построение объектной модели этапа предварительного проектирования заканчивается. Дальнейшие уточнения объектной модели будут производиться на следующих фазах жизненного цикла системы.
2.4. Выделение подсистем
2.4.1. Понятие подсистемы
Итак, прикладная система представляет собой множество взаимозависимых объектов (см. п. 2.1). Каждый объект характеризуется набором атрибутов, значения которых определяют состояние объекта, и набором операций, которые можно применять к этому объекту. При разработке прикладных систем удобно считать, что все атрибуты объектов являются закрытыми (т.е. они не доступны вне объекта, и для того чтобы в некотором объекте узнать значение атрибута другого объекта, или изменить его, необходимо воспользоваться одной из открытых операций этого объекта, если, конечно, такая операция определена). Операции объектов могут быть как открытыми, так и закрытыми.
Таким образом, каждый объект имеет строго определённый интерфейс, т.е. набор открытых операций, которые можно применять к этому объекту. Все объекты одного класса имеют одинаковый интерфейс. Интерфейс класса (а следовательно, и каждого объекта этого класса) задаётся списком сигнатур его открытых (общедоступных) операций (и реализующих их методов); сигнатуры закрытых операций в интерфейс объектов соответствующего класса не входят.
Объектная модель системы задаёт множество взаимозависимых объектов, составляющих систему, и, следовательно, определяет набор интерфейсов, доступных внутри системы. Все возможности по обработке данных внутри системы (т.е. в каждом объекте, входящем в состав системы) определяются этим набором интерфейсов, который определяет внутреннее окружение (или среду) системы.
Наряду с внутренним окружением системы можно определить её внешнее окружение. Оно определяется функциями (операциями), реализованными в составе системного программного обеспечения (т.е. операционной системы, системы программирования, различных редакторов, системы управления базами данных и т.п.), а также в других прикладных системах и библиотеках, используемых совместно с системой. Объекты и операции, составляющие внешнее окружение системы, тоже могут быть доступны внутри системы. Чтобы не упустить этого из виду, можно было бы добавить в объектную модель ещё один объект, интерфейс которого представлял бы возможности внешнего окружения, используемые в системе (такой интерфейс обычно представляет лишь часть возможностей внешнего окружения). Но это было бы не совсем точно, так как внешнее окружение реализуется не одним, а несколькими объектами. С другой стороны внутри системы нет резона рассматривать структуру её внешнего окружения. Выход из указанного противоречия во введении в рассмотрение ещё одной сущности – подсистемы.
Подсистема – это набор объектов и подсистем, обеспечивающих некоторую функциональность, и взаимодействующих между собой в соответствии с их интерфейсами. Интерфейс подсистемы представляет собой подмножество объединения интерфейсов всех объектов и подсистем, составляющих эту подсистему. В состав подсистемы может входить один или более взаимозависимых объектов и/или подсистем.
Множество интерфейсов объектов (и подсистем), которые в своей совокупности составляют некоторую подсистему, составляет внутреннее окружение этой подсистемы. В состав каждой подсистемы должна быть включена подсистема окружение, представляющая внешнее окружение этой подсистемы. Подсистема окружение для системы банковского обслуживания, рассматриваемой в качестве сквозного примера, представлена на рисунке 2.41.
Рис. 2.41. Объектная диаграмма банковской сети,
в которой указан интерфейс с системным окружением
Интерфейс подсистемы окружение определяет, в каком программном окружении будет работать проектируемая система и какие возможности этого окружения будут использоваться во время её работы (это важно, когда возникает потребность модификации или замены отдельных компонентов окружения).
Отметим, что подсистема окружение представляет только интерфейс системы банковского обслуживания с её внешним окружением. Внешнее окружение системы банковского обслуживания состоит из нескольких подсистем и библиотек, и для него тоже может быть разработана объектная модель, которая может содержать и разрабатываемую систему (в этой объектной модели она будет одной из подсистем).
Объектную модель системы банковского обслуживания и её системного (внешнего) окружения тоже можно изобразить в виде объектной диаграммы (правда, в состав этой объектной диаграммы будут входить не объекты, а только подсистемы; каждая подсистема изображается на диаграмме в виде прямоугольника с двойными вертикальными сторонами). Зависимости между подсистемами, изображённые на этой объектной диаграмме (рис. 2.42), отражают взаимодействие проектируемой системы банковского обслуживания и соответствующих подсистем в процессе работы системы. Тем самым определяются требования проектируемой системы к её системному окружению.
Рис. 2.42. Объектная диаграмма банковской сети
и её системного окружения
Введение понятия подсистемы и возможность включать в объектную модель наряду с объектами (классами) и подсистемы определяет иерархическую структуру объектной модели и позволяет использовать методологию OMT при проектировании достаточно сложных программных систем, содержащих большое число различных объектов и классов.