ГЛАВА 9. Основы объектно-ориентированного представления программных систем

Девятая глава вводит в круг вопросов объектно-ориентированного представления программных систем. В этой главе рассматриваются: абстрагирование понятий проблемной области, приводящее к формированию классов; инкапсуляция объектов, обеспечивающая скрытность их характеристик; модульность как средство упаковки набора классов; особенности построения иерархической структуры объектно-ориентированных систем. Последовательно обсуждаются объекты и классы как основные строительные элементы объектно-ориентированного ПО. Значительное внимание уделяется описанию отношений между объектами и классами.

Принципы объектно-ориентированного представления программных систем

Рассмотрение любой сложной системы требует применения техники декомпозиции — разбиения на составляющие элементы. Известны две схемы декомпозиции: алгоритмическая декомпозиция и объектно-ориентированная декомпозиция.

В основе алгоритмической декомпозиции лежит разбиение по действиям — алгоритмам. Эта схема представления применяется в обычных ПС.

Объектно-ориентированная декомпозиция обеспечивает разбиение по автономным лицам — объектам реального (или виртуального) мира. Эти лица (объекты) — более «крупные» элементы, каждый из них несет в себе и описания действий, и описания данных.

Объектно-ориентированное представление ПС основывается на принципах абстрагирования, инкапсуляции, модульности и иерархической организации. Каждый из этих принципов не нов, но их совместное применение рассчитано на проведение объектно-ориентированной декомпозиции. Это определяет модификацию их содержания и механизмов взаимодействия друг с другом. Обсудим данные принципы [22], [32], [41], [59], [64], [66].

Абстрагирование

Аппарат абстракции — удобный инструмент для борьбы со сложностью реальных систем. Создавая понятие в интересах какой-либо задачи, мы отвлекаемся (абстрагируемся) от несущественных характеристик конкретных объектов, определяя только существенные характеристики. Например, в абстракции «часы» мы выделяем характеристику «показывать время», отвлекаясь от таких характеристик конкретных часов, как форма, цвет, материал, цена, изготовитель.

Итак, абстрагирование сводится к формированию абстракций. Каждая абстракция фиксирует основные характеристики объекта, которые отличают его от других видов объектов и обеспечивают ясные понятийные границы.

Абстракция концентрирует внимание на внешнем представлении объекта, позволяет отделить основное в поведении объекта.от его реализации. Абстракцию удобно строить путем выделения обязанностей объекта.

Пример:физический объект — датчик скорости, устанавливаемый на борту летательного аппарата (ЛА). Создадим его абстракцию. Для этого сформулируем обязанности датчика:

q знать проекцию скорости ЛА в заданном направлении;

q показывать текущую скорость;

q подвергаться настройке.

Теперь опишем абстракцию датчика. Описание сформулируем как спецификацию класса на языке Ada 95 [4]:

Package Класс_ДатчикСкорости is

subtype Скорость is Float range ...

subtype Направление is Natural range ...

type ДатчикСкорости is tagged private;

function НовыйДатчик(нокер: Направление)

return ДатчикСкорости:

function ТекущаяСкорость (the: ДатчикСкорости)

return Скорость;

procedure Настраивать(the: in out ДатчикСкорости;

ДействитСкорость: Скорость);

private — закрытая часть спецификации

-- полное описание типа ДатчикСкорости

end Класс_ДатчикСкорости;

Здесь Скорость и Направление — вспомогательные подтипы, обеспечивающие задание операций абстракции (НовыйДатчик, ТекущаяСкорость, Настраивать). Приведенная абстракция — это только спецификация класса датчика, настоящее его представление скрыто в приватной части спецификации и теле класса. Класс ДэтчикСкорости — еще не объект. Собственно датчики — это его экземпляры, и их нужно создать, прежде чем с ними можно будет работать. Например, можно написать так:

ДатчикПродольнойСкорости : ДатчикСкорости;

ДатчикПоперечнойСкорости : ДатчикСкорости;

ДатчикНормальнойСкорости : ДатчикСкорости;

Инкапсуляция

Инкапсуляция и абстракция — взаимодополняющие понятия: абстракция выделяет внешнее поведение объекта, а инкапсуляция содержит и скрывает реализацию, которая обеспечивает это поведение. Инкапсуляция достигается с помощью информационной закрытости. Обычно скрываются структура объектов и реализация их методов.

Инкапсуляция является процессом разделения элементов абстракции на секции с различной видимостью. Инкапсуляция служит для отделения интерфейса абстракции от ее реализации.

Пример:физический объект регулятор скорости.

Обязанности регулятора:

q включаться;

q выключаться;

q увеличивать скорость;

q уменьшать скорость;

q отображать свое состояние.

Спецификация класса Регулятор скорости примет вид

with Кяасс_ДатчикСкорости. Класс_Порт;

use Класс_ДатчикСкорости. Класс_Порт;

Package Класс_РегуляторСкорости is

type Режим is (Увеличение, Уменьшение);

subtype Размещение is Natural range ...

type РегуляторСкорости is tagged private;

function НовРегуляторСкорости (номер: Размещение;

напр: Направление; порт; Порт)

return РегуляторСкорости;

procedure Включить(the: in out РегуляторСкорости);

procedure Выключить(1пе: in out РегуляторСкорости);

procedure УвеличитьСкорость(1г1е: in out

РегуляторСкорости);

procedure УменьшитьСкорость(the: in out

РегуляторСкорости);

Function OnpocCocтояния(the: РегуляторСкорости)

eturn Режим;

private

type укз_наПорт is access all Порт;

type РегуляторСкорости is tagged record

Номер; Размещение;

Состояние: Режим;

Управление: укз_наПорт;

end record;

end Класс_РегуляторСкорости;

Здесь вспомогательный тип Режим используется для задания основного типа класса, класс ДатчикСкорости обеспечивает класс регулятора описанием вспомогательного типа Направление, класс Порт фиксирует абстракцию порта, через который посылаются сообщения для регулятора. Три свойства: Номер, Состояние, Управление — формулируют инкапсулируемое представление основного типа класса РегуляторСкорости. При попытке клиента получить доступ к этим свойствам фиксируется семантическая ошибка.

Полное инкапсулированное представление класса РегуляторСкорости включает описание реализаций его методов — оно содержится в теле класса. Описание тела для краткости здесь опущено.

Модульность

В языках C++, Object Pascal, Ada 95 абстракции классов и объектов формируют логическую структуру системы. При производстве физической структуры эти абстракции помещаются в модули. В больших системах, где классов сотни, модули помогают управлять сложностью. Модули служат физическими контейнерами, в которых объявляются классы и объекты логической разработки.

Модульность определяет способность системы подвергаться декомпозиции на ряд сильно связанных и слабо сцепленных модулей.

Общая цель декомпозиции на модули: уменьшение сроков разработки и стоимости ПС за счет выделения модулей, которые проектируются и изменяются независимо. Каждая модульная структура должна быть достаточно простой, чтобы быть полностью понятой. Изменение реализации модулей должно проводиться без знания реализации других модулей и без влияния на их поведение.

Определение классов и объектов выполняется в ходе логической разработки, а определение модулей — в ходе физической разработки системы. Эти действия сильно взаимосвязаны, осуществляются итеративно.

В Ada 95 мощным средством обеспечения модульности является пакет.

Пример:пусть имеется несколько программ управления полетом летательного аппарата (ЛА) — программа угловой стабилизации ЛА и программа управления движением центра масс ЛА. Нужно создать модуль, чье назначение — собрать все эти программы. Возможны два способа.

1. Присоединение с помощью указателей контекста:

with Класс_УгловСтабил, Класс_ДвиженЦентраМасс;

use Класс_УгловСтабил, Класс_ДвиженЦентраМасс;

Package Класс_УпрПолетом is

…

2. Встраивание программ управления непосредственно в объединенный модуль:

Package Класс_УпрПолетом is

type УгловСтабил is tagged private;

type ДвиженЦентраМасс is tagged private;

-------------------------