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

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

Рассмотрим тенденцию развития какого-либо программного продукта за последние 15 лет. Возьмем в качестве примера, компилятор Pascal фирмы Borland. В 1984 году появился компилятор версии 3.0, дистрибутив которого занимал 37 Кб вместе со всеми необходимыми библиотеками ( включая возможность работы с графикой ). Последняя версия компилятора - Delphi 3.0, дистрибутив которого в простейшем варианте занимает 100 Мб. Т.е. размер программы вырос примерно в 2700 раз за 15 лет. Аналогичную картину можно наблюдать на любом другом программном средстве.

В этой связи можно обратить внимание на следующие две особенности:

· во-первых, размер дистрибутива растет в геометрической прогрессии,

· во-вторых, в геометрической прогрессии сокращаются сроки между появлением новых версий.

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

· машинные коды,

· ассемблеры,

· языки высокого уровня - FORTRAN,

· структурное программирование - С,

· абстрактные типы, модули и пакеты в ADA,

· объектно-ориентированное программирование С++.

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

Жизненный цикл программного обеспечения

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

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

Стандартные модели жизненного цикла

Этапы жизненного цикла

Традиционно, во всех стандартных моделях, выделяют следующие основные этапы жизненного цикла:

· стратегическое планирование;

· анализ требований;

· проектирование (предварительное и детальное);

· кодирование (программирование);

· тестирование и отладка;

· эксплуатация и сопровождение.

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

Рассмотрим подробнее отдельные этапы жизненного цикла.

Этапы стратегического планирования и анализа используются для определения самых общих требований к программной системе. Данные этапы предполагают решение следующих задач:

· определение целесообразности разработки и сравнение с аналогами,

· определение необходимых ресурсов для решения задачи,

· спецификация требований к системе в виде “что она должна делать”, но не в виде “как это реализовать”,

· проверка корректности и реализуемости требований.

На этапе проектирования создается структура будущей программой системы

Можно определить следующие фазы проектирования:

· проектирование архитектуры, включает в себя определение состава подсистем,

· спецификация подсистем, определяет спецификацию каждой подсистемы,

· проектирование интерфейса, определяет интерфейс каждой подсистемы, т.е. метод взаимодействия данной подсистемы с другими,

· проектирование компонентов, каждая подсистема разделяется на компоненты,

· проектирование структур данных, определяет где и как хранятся данные,

· проектирование алгоритмов, определяются алгоритмы обработки данных.

Реализацияподразумевает выбор языка программирования и составление текста программы ( кодирование ), а также, возможно, выполнение тестирования и отладки отдельных фрагментов.

Этап тестирования и отладки включает выполнение комплексного тестирования всей программной системы специальной группой и исправление ошибок

На этапе сопровождения и эксплуатации программная система сдается в эксплуатацию, происходит обслуживание пользователей, возможно устранение незначительных ошибок ( сейчас это делается повсеместно с помощью распространения так называемых patсh - файлов ).

Модели жизненного цикла

Исторически, в ходе эволюционного развития теории проектирования программного обеспечения и по мере его усложнения, сложились три основные модели жизненного цикла. Эти модели выражают последовательность этапов жизненного цикла ПО.

Первой, по времени появления, и самой распространенной являлась каскадная модель (рис. 2.1):

Рис. 2.1. Каскадная модель жизненного цикла

Каскадная Модель предполагает следующие свойства взаимодействия этапов:

· модель состоит из последовательно расположенных этапов,

· каждый этап полностью заканчивается до того как начнется следующий,

· этапы не перекрываются во времени, т.е. следующий этап не начинается пока не завершится предыдущий,

· возврат к предыдущим этапам не предусматривается или крайне ограничен,

· результат появляется только в конце разработки.

Выявление и устранение ошибок в такой модели производится только на стадии тестирования, которая может растянуться во времени, или, вообще ни когда не завершиться.

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

В ходе работ над системой могут измениться начальные требования, и в этом случае итерационная модель может оказаться неэффективной.

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

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

Одним из источников ошибок в процедурных языках программирования является передача неправильных параметров в подпрограммы. При передаче параметров в подпрограмму компилятор может проконтролировать синтаксическую совместимость типов, но не семантику. Например, подпрограмма имеет параметр типа “целое число”, который обозначает температуру воды, но в качестве фактического значения в нее можно передать любое целое число, например, 10000, которое не может являться температурой воды. Отследить такого рода ошибки очень не просто, особенно если учесть, что семантическая ошибка может быть намного тоньше и может не контролироваться простым попаданием числа в заданный диапазон. Уменьшение вероятности таких ошибок состоит в синтаксическом связывании данных с действиями. Имеются в виду данные, которые передаются в качестве фактических параметров в подпрограммы. Так появилось понятие абстрактного типа данных, реализованное например в языке Ада.

Инкапсуляция возникла как логическое продолжение идеи абстрактных типов данных, в которой каждый тип имеет некоторую, иногда недоступную извне внутреннюю структуру и набор всегда доступных операций над переменными данного типами. Т.е. в отличие от обычных подходов к типам ( например, в Pascal ), когда тип полностью определяется только структурой хранения информации, абстрактный тип дополнительно определяется набором операций. Достоинство такого подхода состоит в исключении ошибок, состоящих в применении операций, недопустимых для типа данных, большей универсальности, когда можно менять внутреннюю структуру хранения данных без необходимости изменения других частей системы.

Рассмотрим эти особенности на следующем примере. Пусть разрабатывается библиотека подпрограмм для работы с матрицами. Пусть выбрано хранение в виде двумерного массива. При необходимости перехода к разреженному хранению придется изменять любое определение данных для обращения к библиотеке. Если же матрица определена как абстрактный тип данных с операциями: “получить значение элемента”, “изменить значение элемента” и т.п., то изменение метода хранения матрицы не скажется на других частях программы. В программе не описываются переменные типа “array [1..10 ] of integer” и нет прямых обращений к элементам массива вида “A[i]”.

Объект, обладающий свойством инкапсуляции характеризуется следующими параметрами:

· уникальное имя,

· набор атрибутов - данных, характеризующих состояние объекта,

· набор действий (методов) для смены своих состояний, т.е. для описания своего поведения.

Рассмотрим характерное описание объекта:

объект:

точка

атрибуты:

позиция на плоскости

методы:

создать

удалить

переместить в новую позицию

отобразить

стереть

объект:

прибор

атрибуты:

показания

методы:

снять показания

Каждый объект, заданный именем, атрибутами и методами представляет собой замкнутую сущность, однозначно определенную для постороннего наблюдателя. Принципиальная особенность такого объекта состоит в том, что он может делать только то, что определено в качестве его методов и все, что определено в качестве методов объекта, объект выполняет самостоятельно. Мы не говорим "переместить (объект)", а говорим "объект переместись". Это обеспечивает все свойства абстрактного типа данных.

Наследование

В реальном мире наследование объектов можно рассматривать в двух аспектах. С одной стороны - это наследование вида "является", с другой стороны - вида "состоит из". Наследование вида "является" можно рассмотреть на упрощенном примере фрагмента классификации животных, представленном на рис. 3.1..

Рис. 3.1. Пример наследования свойств вида "является".

Наследование вида "является" предполагает, что объект-наследник полностью включает в себя все свойства объекта-родителя.

Другой вид наследования - сборочный, вида "состоит-из" можно продемонстрировать на примере автомобиля (рис. 3.2.)

Рис. 3.2. Пример наследования свойств вида "состоит - из"

Наследование свойствв объектно-ориентированном подходе понимается как наследование атрибутов и методов, т.е. возможность использования в производном объекте атрибутов и методов базового объекта. Пусть имеется два объекта:

объект:

геометрическая фигура

атрибуты:

позиция на плоскости

методы:

создать

удалить

переместить в новую позицию

отобразить

стереть

и

объект:

прямоугольник

атрибуты:

высота

ширина

методы:

создать

отобразить

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

Полиморфизм

Полиморфизм предполагает возможность одинакового именования разных действий. Эта особенность имеет два аспекта:

· возможность одинакового именования статических методов

· возможность одинакового именования динамических методов.

Пусть имеется два объекта, рассмотренных выше геометрическая фигура и прямоугольник. В обоих объектах определены методы “нарисовать”. Эти методы имеют одинаковые имена, но выполняют различные действия, в зависимости от варианта вызова:

· Геометрическая фигура. нарисовать или

· Прямоугольник. нарисовать.

Это пример статического полиморфизма. Его реализовать и осмыслить легко за счет того, что вызов каждого метода предваряется именем объекта.

Рассмотрим теперь метод переместить для геометрической фигуры. Предположим, что этот метод должен выполнять перемещение изображения объекта по плоскости. Его реализация на смысловом уровне может быть такой:

1. стереть объект в текущей позиции,

2. изменить позицию объекта,

3. нарисовать объект в текущей позиции.

Действия 1 и 3 реализуются с помощью методов стереть и нарисовать, а действие 2 - с помощью присвоения нового значения. Теперь обратим внимание на то, что эта последовательность действий одинакова для всех объектов, наследующих свои свойства от объекта геометрическая фигура. Различие только в том, что методы стереть и нарисовать должны вызываться для того объекта, который вызвал метод переместить. Это вариант динамического полиморфизма, который в языках программирования реализуется с помощью виртуальных функций.

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

Когда разрабатывается объектная программа, необходимо забыть о конкретной задаче и сконцентрироваться на объектах предметной области, то есть той области, для которой создается программа. Пусть в качестве задачи формулируется создать графический редактор. При процедурном подходе проектируется набор подпрограмм, например “Нарисовать точку”, “Нарисовать прямоугольник”, “Нарисовать окружность”, “Переместить точку”, “Удалить невидимые линии”, “Вывести содержимое экрана на принтер”, “Команда сохранить файл” и т.п. Если создание объектной программы ведется по тем же принципам, то она будет гораздо хуже, чем обычная процедурная программа. За счет того, что сами по себе свойства объектов ( например, инкапсуляция ) не дают никаких преимуществ. Эти преимущества реализуются только при умелом определении объектов. Рассмотрим такой пример. Необходимо создать объект для представления хэш-таблицы, хранящей фамилии, имена студентов группы.

Вариант 1:

тип:

элемент хэш-таблицы

атрибуты:

фамилия : строка

имя : строка

отчество : строка

№ группы : строка

объект:

хэш-таблица

атрибуты:

массив элементов типа элемент хэш-таблицы

количество элементов

методы:

вставить элемент( элемент : элемент хэш-таблицы )

удалить элемент ( фамилия : строка )

вычислить хэш-функцию( фамилия : строка )

В этом варианте определяется тип элемента хэш-таблицы, как некоторый структурный тип. Далее определяется объект хэш-таблица, хранящий элементы заданного типа. Данное определение вполне работоспособно, но перечеркивает все достоинства объектного подхода, т.к. в будущем никакого изменения поведения хэш-таблицы сделать нельзя. Рассмотрим другое определение.

Вариант 2:

объект:

элемент хэш-таблицы

атрибуты:

ключ : строка

объект:

хэш-таблица

атрибуты:

массив элементов типа элемент хэш-таблицы

количество элементов

методы:

вставить элемент(элемент : элемент хэш-таблицы )

удалить элемент (фамилия : строка )

вычислить хэш-функцию(фамилия : строка )

объект:

элемент хэш-таблицы

атрибуты:

фамилия : строка

имя : строка

отчество : строка

№ группы : строка

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

Варианты наследования

Использование наследования обычно вызвано необходимостью достичь одну из следующих целей:

1. Построение принципиально нового объекта, базирующегося на свойствах существующего.

2. Расширение и изменение функциональности имеющегося объекта.

В первом случае, примером может являться построения объектов "Прямоугольник", "Ромб", "Эллипс", на основе объекта "Геометрическая фигура", а иллюстрацией для второго пункта является создание объекта "Прямоугольник с утолщенной линией", путем модификации объекта "Прямоугольник".

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

Обычный вариант наследования в объектно-ориентированном подходе – наследование типа "является". Типы объекта-наследника и объекта-родителя в этом случае имеют одну природу и являются сравнимыми. У объекта имеется один родитель.

Возможен также случай множественного наследования, при котором новый объект включает все атрибуты и методы нескольких родительских объектов типы которых могут быть несравнимы. Тип объекта-наследника в этом случае может быть приведен к любому из родительских типов. Однако, использование такого вида наследования при проектировании и разработке программных систем не рекомендуется в связи с его сложностью.

Иногда требуется, чтобы вновь создаваемый объект состоял из нескольких компонент. Такой тип взаимодействия именуют композицией, или наследованием "состоит из", хотя с точки зрения объектно-ориентированного подхода это не есть наследование в чистом виде. Типы наследника и составляющих его объектов при этом могут быть несравнимыми. Чаще всего, такой вид взаимодействия реализуется путем включения исходного объекта (объектов) в качестве атрибутов нового объекта.

Схема предметной области

Схема предметной области содержит описание ее отдельных частей и взаимодействий между ними. Такая схема позволяет разделить предметную область на такие части, в которых должны содержаться однотипные объекты. Разделение предоставляет возможность разделение задачи на мелкие относительно независимые части. Это упрощает работу и позволяет проводить одновременное проектирование нескольким разработчикам. На рис.5.1. представлена схема предметной области контроля дорожного движения (примеры связанные с дорожным движением - из книги Йорден. О.О.А.)

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

Рис. 5.1. Схема предметной области управления дорожным движением.

Между частями предметной области устанавливаются связи, которые обозначают возможность взаимодействия объектов из этих частей друг с другом. В частности на рис. 5.1 объекты, относящиеся к Пользователям не могут общаться непосредственно с объектами Персонала.

Схема объектов

Каждому объекту на схемах соответствует графический элемент, показанный на рис. 5.2. В верхней части указывается имя, в средней - атрибуты, в нижней - методы.

Рис. 5.2. Графическое обозначение объекта.

Схема объектов содержит их простое перечисление, с обозначением того, к какой части предметной области объект относится. Перечисление объектов является вторым по порядку действием и является достаточно ответственным. На этой схеме не предполагается перечисление всех объектов относящихся к данной части предметной области. Но для каждой части должны быть обязательно перечислены все базовые объекты, от которых в дальнейшем будет проводиться наследование. Выбор набора бозовых объектов во многом определяет структуру и качество всего проекта. Неудачный выбор может перечеркнуть все достоинства объектно-ориентированного подхода. Ниже представлен пример выбора базовых объектов.

Рис. 5.3. Схема объектов управления дорожным движением.

Схема структуры

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

Рис. 5.4. Схема структуры управления дорожным движением.

Схема атрибутов

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

Для данной задачи и данного набора объектов можно было бы определить такие атрибуты:

· организация: ( наименование, адрес, руководитель, телефон )

· владелец: ( имя, адрес, телефон )

· событие: ( дата, время )

· регистрация: ( дата, время, начало, конец )

Схема методов

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

Контроль корректности

Контроль проекта в О.О.А. осуществляется по следующим параметрам:

для каждого объекта в схеме объектов:

· объект имеет имя,

· объект имеет уникальное имя,

· объект имеет два или более атрибутов, все атрибуты объектов имеют уникальные имена,

все методы объекта имеют уникальные имена,

объект имеет хотя бы один экземпляр (предупреждение)

для структуры:

· все компоненты имеют имена,

· все компоненты имеют уникальные имена,

· все компоненты имеют один и более атрибутов,

· все атрибуты имеют уникальные имена по всей линии родитель-потомок,

Диаграмма классов

Диаграмма классов включает следующие виды компонентов:

· классы,

· иерархия наследования классов,

· утилиты классов.

Классы понимаются так, как указано выше. Графическое обозначения класса содержит его имя и имеет вид, представленный на рис. 6.1.

Рис 6.1. Графическое обозначения класса.

Иерархии классов понимаются более широко. В частности рассматривается не только отношение наследования, но и целый ряд других отношений, а именно:

Таблица 6.2. Отношения между классами в ООП

№	Графическое обозначение	Смысл
а		Использование в интерфейсной части класса ( А использует В ). Например в качестве параметра метода
б		Использование в реализации класса ( А использует В ). Например в качестве локальной переменной в подпрограмме.
в		Включение ( А включает В ). А и В сравнимые типы
г		Включение ( А включает В ). А и В типы разной природы
д		Наследование ( А наследует от В ). А и В сравнимые типы
е		Наследование ( А наследует от В ). А и В типы разной природы
ж		Метакласс. ( В - метакласс для А )
з		Неопределенный тип связи

Отношение наследования в ООП - это отношение вида "является", в то время как отношение вида "состоит-из" описывается отношениями

а) использование в интерфейсной части класса.

б) использование в реализации класса.

Отношение б) позволяет отразить дополнительные оттенки взаимодействия классов. Отношение включение описывает такое взаимодействие классов, при котором экземпляры одного класса включают в себя (хранят в себе ) экземпляры другого класса. Типичными представителями классов, предназначенных для хранения других классов являются списки, деревья, коллекции.

Для каждого вида отношений может быть построена собственная диаграмма.

Рассмотрим пример проектирования классов для описания геометрических фигур.

Диаграмма наследования этого примера расположена на Рис. 6.2.

Рис. 6.2. Диаграмма классов для геометрических фигур.

Различные геометрические фигуры могут образовывать изображение. Для описания класса изображений не подходит отношение наследование, т.к. картинка не является подклассом геометрической фигуры, она скорее является накопителем геометрических фигур. На рис. Х.3.3. представлена соответствующая диаграмма.

Рис. 6.3. Диаграмма классов для геометрических фигур и рисунков.

На диаграмме классов могут изображаться так называемые утилиты классов - общедоступные интерфейсные подпрограммы. Отношение между утилитами и классами - те же, что и между классами. Графическое изображение утилиты демонстрируется на рис. 6.4

Рис. 6.4.Графическое обозначение утилиты класса.

Категории классов

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

Процесс проектирования и осмысления классов становится более обозримым при использовании категорий. Обозначение категорий классов приведено на рис. 6.5

Рис. 6.5. Графическое обозначение категории классов.

Между категориями классов возможно отношение вида "импортирует -из", обозначенное стрелкой (X > Y обозначает "Y импортирует из X). Для примера с геометрическими фигурами категории классов имеют вид:

Рис. 6.6. Категории классов для геометрических фигур.

Диаграмма объектов

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

Графическое обозначение объекта представлено на рис. 6.7, оно совпадает с обозначением класса, но используется не пунктирная, а сплошная линия.

Рис. 6.7. Графическое обозначение объекта.

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

Связь между объектами обозначается линией без направления, показывающей, что один объект может передавать сообщение ( вызвать операции из ) другому объекту. Рядом с линией можно указать стрелку с именем вызываемой операции.

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

На линии, связывающей два объекта, может быть указана метка конкретизирующая вид связи, перечень возможных меток приведен на рис 6.8.

Использование параметра

Общее использование параметра

Использование поля

Общее использование поля

Рис. 6.8. Обозначения для меток на линиях взаимодействия объектов.

Если объект А использует поле объекта В, то метка F располагается ближе к объекту А.

На диаграмме объектов можно отразить тот факт, что один объект включает в себя набор других. Для этого включаемые объекты располагаются внутри изображения внешнего объекта. Пример показан на рис. 6.9. Здесь объект "план работ" состоит из набора объектов "месячный план".

Рис. 6.9. Пример вложения объектов.

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

Рис. 6.10. Диаграмма объектов для геометрических фигур.

Диаграмма переходов

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

Таблица 6.3. Обозначения для диаграммы переходов

Обозначение	Смысл
	Состояние
	Начальное состояние
	Конечное состояние
	Переход между состояниями

Можно построить диаграмму состояний для схемы в целом, отдельной ее части, или для одного объекта. На рис. 6.11 представлена диаграмма в качестве примера.

Рис. 6.11. Диаграмма переходов для геометрической фигуры.

Классы

Графическое представление класса - это прямоугольник, который может быть разделен на три части:

Рис. 7.4. Пример изображения класса.

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

Каждый атрибут представляется в следующем виде:

видимость имя: тип = начальное значение

Перед именем может следовать знак обозначающий видимость атрибута для других классов:

+ общедоступный ( public ) атрибут

# защищенный ( protected ) атрибут

- закрытый ( private ) атрибут

Каждый метод представляется в следующем виде:

видимость имя( список параметров ): тип возвращаемого значения

Описатель видимости имеет те же значения, что и для атрибута.

Список параметров представляет собой перечень описателей параметров, разделенных запятой. Описатель каждого параметра имеет вид:

вид имя: тип = значение по умолчанию

вид параметра может быть следующим:

in входной параметр

out выходной параметр

inout входной и выходной параметр

Текст реализации операции может быть сопоставлен в качестве примечания для каждого метода.

Пример изображения класса представлен на рис. 7.5.

Рис. 7.5. Пример изображения класса "Геометрическая фигура".

Интерфейсы

Интерфейсы предназначены для спецификации внешнего вида операций для классов.

Отношения между классами

Класс, описывающий связь

(Associaton class). Связь между классами также может обладать свойствами, присущими некоему классу. Для определения таких свойств для связи может быть задан ассоциированный с ней класс. Связь и ассоциированный класс представляют одно целое.

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

Рис. 7.11. Пример класса, описывающего связь

N - местная связь

( N-ry Association ) Это связь между 3 и более классами. Эта связь графически обозначается ромбом, к которому подходят линии, соединяющие ромб с классами. Имя отношения указывается внутри или вблизи ромба. Класс, описывающий связь присоединяется к ромбу с помощью штрих - пунктирной линии. Пример такой связи представлен на рисунке:

Рис. 7.12. Пример многоместной связи.

Для подобного вида связей не может быть прим