 |
ГЛАВА 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;
-------------------------
Иерархическая организация
Мы рассмотрели три механизма для борьбы со сложностью:
q абстракцию (она упрощает представление физического объекта);
q инкапсуляцию (закрывает детали внутреннего представления абстракций);
q модульность (дает путь группировки логически связанных абстракций).
Прекрасным дополнением к этим механизмам является иерархическая организация — формирование из абстракций иерархической структуры. Определением иерархии в проекте упрощаются понимание проблем заказчика и их реализация — сложная система становится обозримой человеком.
Иерархическая организация задает размещение абстракций на различных уровнях описания системы.
Двумя важными инструментами иерархической организации в объектно-ориентированных системах являются:
q структура из классов («is a» -иерархия);
q структура из объектов («part of» -иерархия).
Чаще всего «is а»-иерархическая структура строится с помощью наследования. Наследование определяет отношение между классами, где класс разделяет структуру или поведение, определенные в одном другом (единичное наследование) или в нескольких других (множественное наследование) классах.
Пример: положим, что программа управления полетом 2-й ступени ракеты-носителя в основном похожа на программу управления полетом 1-й ступени, но все же отличается от нее. Определим класс управления полетом 2-й ступени, который инкапсулирует ее специализированное поведение:
with Класс_УпрПолетом1; use Класс_УпрПолетом1;
Package Класс_УпрПолетом2 is
type Траектория is (Гибкая. Свободная);
type УпрПолетом2 is new УпрПолетом1 with private;
procedure Установиться: in out УпрПолетом2:
тип: Траектория; ориентация: Углы;
параметры: Координаты_Скорость; команды: График);
procedure УсловияОтделенияЗступени (the: УпрПолетом2;
критерий:КритерийОтделения);
function ПрогнозОтделенияЗступени (the: УпрПолетом2)
return БортовоеВремя;
function ИсполнениеКоманд(the: УпрПолетом2)
return Boolean;
private
type УпрПолетом2 is new УпрПолетом1
with record
типТраектории: Траектория; доОтделения: БортовоеВремя;
выполнениеКоманд: Boolean;
end record;
end Класс_УпрПолетом2;
Видим, что класс УпрПолетом2 — это «is а»-разновидность класса УпрПолетом1, который называется родительским классом или суперклассом.
В класс УпрПолетом2 добавлены:
q авспомогательный тип Траектория;
q три новых свойства (типТраектории, доОтделения, выполнениеКоманд);
q три новых метода (УсловияОтделенияЗступени, ПрогнозОтделенияЗступени, ИсполнениеКоманд).
|
|
|
Кроме того, в классе УпрПолетом2 переопределен метод суперкласса Установить. Подразумевается, что в наследство классу УпрПолетом2 достался набор методов и свойств класса УпрПолетом1. В частности, тип УпрПолетом2 включает поля типа УпрПолетом1, обеспечивающие прием данных о координатах и скорости ракеты-носителя, ее угловой ориентации и графике выдаваемых команд, а также о критерии отделения следующей ступени.
Классы УпрПолетом1и УпрПолетом2 образуют наследственную иерархическую организацию. В ней общая часть структуры и поведения сосредоточены в верхнем, наиболее общем классе (суперклассе). Суперкласс соответствует общей абстракции, а подкласс — специализированной абстракции, в которой элементы суперкласса дополняются, изменяются и даже скрываются. Поэтому наследование часто называют отношением обобщение-специализация.
Иерархию наследования можно продолжить. Например, используя класс УпрПолетом2, можно объявить еще более специализированный подкласс — УпрПолетомКосмическогоАппарата.
Другая разновидность иерархической организации — «part of»-иерархическая структура — базируется на отношении агрегации. Агрегация не является понятием, уникальным для объектно-ориентированных систем. Например, любой язык программирования, разрешающий структуры типа «запись», поддерживает агрегацию. И все же агрегация особенно полезна в сочетании с наследованием:
1) агрегация обеспечивает физическую группировку логически связанной структуры;
2) наследование позволяет легко и многократно использовать эти общие группы в других абстракциях.
Приведем пример класса ИзмерительСУ (измеритель системы управления ЛА):
with Класс_НастройкаДатчиков. Класс_Датчик;
use Класс_НастройкаДатчиков, Класс_Датчик;
Package Класс_ИзмерительСУ is
type ИзмерительСУ is tagged private;
-- описание методов
private
type укз_наДатчик is access all Датчик'Class;
type ИзмерительСУ is record
датчики: array(1..30) of укз_наДатчик;
процедураНастройки: НастройкаДатчиков;
end record;
end Класс_ИзмерительСУ;
Очевидно, что объекты типа ИзмерительСУ являются агрегатами, состоящими из массива датчиков и процедуры настройки. Наша абстракция ИзмерительСУ позволяет использовать в системе управления различные датчики. Изменение датчика не меняет индивидуальности измерителя в целом. Ведь датчики вводятся в агрегат с помощью указателей, а не величин. Таким образом, объект типа ИзмерительСУ и объекты типа Датчик имеют относительную независимость. Например, время жизни измерителя и датчиков независимо друг от друга. Напротив, объект типа НастройкаДатчиков физически включается в объект типа ИзмерительСУ и независимо существовать не может. Отсюда вывод — разрушая объект типа ИзмерительСУ, мы, в свою очередь, разрушаем экземпляр НастройкиДатчиков.
Интересно сравнить элементы иерархий наследования и агрегации с точки зрения уровня сложности. При наследовании нижний элемент иерархии (подкласс) имеет больший уровень сложности (большие возможности), при агрегации — наоборот (агрегат ИзмерительСУ обладает большими возможностями, чем его элементы — датчики и процедура настройки).
Объекты
Рассмотрим более пристально объекты — конкретные сущности, которые существуют во времени и пространстве.
|
|
|
