Принципы объектно-ориентированного проектирования 1 страница

Объектно-ориентированное проектирование

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

Другим принципом построения моделей сложных систем является принцип многомодельности. Этот принцип представляет собой утверждение о том, что никакая единственная модель не может с достаточной степенью адекватности описывать различные аспекты сложной системы. Применительно к методологии ООАП это означает, что достаточно полная модель сложной системы допускает некоторое число взаимосвязанных представлений (views), каждое из которых адекватно отражает некоторый аспект поведения или структуры системы. При этом наиболее общими представлениями сложной системы принято считать статическое и динамическое представления, которые в свою очередь могут подразделяться на другие более частные представления.) феномен сложной системы как раз и состоит в том, что никакое ее единственное представление не является достаточным для адекватного выражения всех особенностей моделируемой системы.

Еще одним принципом прикладного системного анализа является принцип иерархического построения моделей сложных систем. Этот принцип предписывает рассматривать процесс построения модели на разных уровнях абстрагирования или детализации в рамках фиксированных представлений. При этом исходная или первоначальная модель сложной системы имеет наиболее общее представление (метапредставление). Такая модель строится на начальном этапе проектирования и может не содержать многих деталей и аспектов моделируемой системы.

Рис.1. Общая схема взаимосвязей моделей и представлений сложной системы в процессе объектно-ориентированного анализа и проектирования

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

Классы и их свойства. Диаграммы классов

Класс имеет следующий внешний вид:

Рис2. Пример структуры класса

Рис3. Пример классов

Классы – это описания совокупности объектов с общими атрибутами,

операциями, отношениями (у каждого класса обязательно есть имя). Имя

бывает простое и составное. Составное – состоит из: имени пакета и

названия класса.

Атрибут – это именованное свойство класса, включающее описание

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

при описании атрибута можно указать его тип и начальные значения,

принятые системой по умолчанию.
Операция – это реализация услуг которые можно запросить у любого

объекта класса для воздействия на его поведение, т. е. это абстракция того,

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

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

по отношению к функциям еще и тип возвращаемого значения.

Класс может быть абстрактным, т. е. не иметь экземпляров и объектов. Имя

для него записывается курсивом. Если надо указать пакет, к которому

относится класс, то используется составное имя(Например: Банк:: Счет).

Абстрактные классы создаются на диаграмме в качестве резерва для
последующей расшифровки, во второй сверху секции прямоугольника
записываются атрибуты в виде отдельной строки.
<квантор видимости><имя атрибута [кратность]>:<тип атрибута>=
<исходное значение>{строка – свойство}
Область видимости:

• public (общий открытый) атрибут виден всем остальным классам любой класс может посмотреть или изменить этот атрибут. В нотации UML обозначается («+»)
• protected (защищенный) атрибут доступен только самому классу или его потомкам («#»)
• private (закрытый, секретный) атрибут не виден ни каким другим классам, но другой класс может попросить у данного разрешение на просмотр или изменение значения атрибута («-»)
• package of Implementation (пакетный) атрибут является общим, но только в пределах своего пакета.

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

При описании системы классы автономно не существуют, следовательно, их необходимо описывать их взаимодействия. При моделировании системы не только выделяют сущности, но и описывают отношения между ними (см. ниже «Отношения и их свойства»).
Объекты и их свойства. Диаграммы объектов
Объект (object) является отдельным экземпляром класса, который создается на этапе выполнения программы. Он имеет свое собственное имя и конкретные значения атрибутов. В силу самых различных причин может возникнуть необходимость показать взаимосвязи не только между классами модели, но и между отдельными объектами, реализующими эти классы. В данном случае может быть разработана диаграмма объектов, которая, хотя и не является канонической в метамодели языка UML, но имеет самостоятельное назначение.
Для графического изображения объектов используется такой же символ прямоугольника, что и для классов. Отличия проявляются при указании имен объектов, которые в случае объектов обязательно подчеркиваются. При этом запись имени объекта представляет собой строку текста "имя объекта: имя класса", разделенную двоеточием.
Имя объекта может отсутствовать, в этом случае предполагается, что объект является анонимным, и двоеточие указывает на данное обстоятельство. Отсутствовать может и имя класса. Тогда указывается просто имя объекта.
Атрибуты объектов принимают конкретные значения.

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

Активный объект (active object) имеет свою собственную нить (thread) управления и может инициировать деятельность по управлению другими объектами. При этом под нитью понимается некоторый облегченный поток управления, который может выполняться параллельно с другими вычислительными нитями или нитями управления в пределах одного вычислительного процесса или процесса управления.

Линия жизни объекта (object lifeline) изображается пунктирной вертикальной линией, ассоциированной с единственным объектом на диаграмме последовательности. Линия жизни служит для обозначения периода времени, в течение которого объект существует в системе и, следовательно, может потенциально участвовать во всех ее взаимодействиях. Если объект существует в системе постоянно, то и его линия жизни должна продолжаться по всей плоскости диаграммы последовательности от самой верхней ее части до самой нижней.

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

Рис.5. Графическое изображение различных вариантов линий жизни

Пакеты: видимость, импорт и экспорт, обобщения
Пакет (package) – это часть модели. Любая такая часть модели может принадлежать только одному пакету. разработчик может распределить содержание модели по целому набору пакетов. При этом распределение по пакетам должно производится с учетом сходства функций элементов и их взаимосвязей при реализации в программном коде.
В пакетах содержатся высокоуровневые элементы модели. Одни пакеты могут содержать в себе другие. В модели имеется также корневая папка которая содержит в себе все ее содержимое. пакеты можно также организовывать: по виду модели, по функциональности или по любому другому признаку, который выберет разработчик.
Пакеты – это иерархически организованные блоки UML-модели. Набор пакетов, на которые разбита модель, отображает архитектуру всей системы (ее деление на подклассы и зависимости между ними).
Зависимость
Зависимости существуют между единичными элементами, однако они должны находить отражение и на высоком уровне проектирования. Зависимость между пакетами указывает на то, что между единичными элементами этих пакетов существует (при восходящем подходе) или допускается к существованию (при нисходящем подходе) как минимум одно отношение такого типа деятельности:

• Нисходящий подход – отражает архитектуру всей системы
• восходящий подход – позволяет автоматически сгенерировать схему зависимостей пакетов на основе зависимости индивидуальных элементов.

В моделировании применяются оба эти подхода иногда даже в рамках одной системы.
Импорт и экспорт
Пусть в системе два равноправных класса: С1 и С2, оба открыты, следовательно они видят друг друга. Если один класс в одном пакете, а другой в другом, следовательно, классы перестают видеть друг друга, так как пакеты непрозрачны. При импортировании используют отношение зависимости со стереотипом «import». Свойство транзитивности отсутствует.
Если существуют вложенные пакеты, то они могут видеть все, что видит объемлющий пакет.

Стандартные элементы пакетов:

1. facado – определят пакет, который является лишь представлением другого пакета
2. framework – определяет пакет состоящий из образов
3. stub - определяет пакет служащий заместителем открытого содержимого другого пакета
4. subsystem - определяет пакет представляющий часть моделируемой системы
5. system – определяет пакет представляющий всю моделируемую систему.
6. import - отношение зависимости между пакетами, один из которых импортирует другой.

Моделирование пакетов:

1. найти семантические и концептуально близкие элементы системы
2. объединить в один пакет
3. определить видимость пакета
4. определение импорта, использовать с теми пакетами, от которых есть зависимость
5. если существует семейство пакетов, следовательно, можно воспользоваться отношениями обобщения
6. сбалансировать количество элементов в пакете
7. если с помощью пакетов моделируются сущности, относящиеся к управлению конфигурацией следует обязательно открыть значение меток, которые связаны с номерами версий.

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

1. Зависимость – это отношение использования, согласно которому изменение специфики одного элемента может повлиять на другой (обратная не обязательно). Обозначается - - - -> (направление стрелки на тот элемент, от которого зависит данный)

Рис.6. Графическое представление зависимости между классом-клиентом (Класс_С) и классами-источниками (Класс_Л и Класс_Б)
У зависимости может быть:
имя (указывает на роль которую она исполняет в моделировании);
стереотип (обозначает её истинную природу, а также подробное текстовое описание).
Виды зависимости:

• Доступ «access» - пакет имеет доступ к содержимому другого пакета
• Вызов «call» - метод одного класса вызывает операцию другого класса
• Вывод «derive» - один экземпляр может быть вычислен на основе информации представленной другим экземпляром
• Дружественность «friend» - элемент имеет доступ к содержимому другого пакета и добавляет имена из пространства имен этого пакета в пространство имен импортера
• Отправка «send» - отношение между объектом, который принимает сообщение и объектом, который этот сигнал получает
• Трассировка «trace» - используется для гарантии выполнения моделями системных требований и отслеживания тех изменений, которые могут повлиять на другие модели
• Использование «use» - одному элементу для правильного функционирования нужны услуги другого элемента

Рис.7. Пример зависимости
Обобщение:

• Это отношение между общей сущностью и конкретным видом
• Это отношение типа «is a», т. е. когда одна сущность является частным выражением более общей
• Потомок наследует свойства родителей (атрибуты, операции)
• Можно создать классы имеющие любое число родителей (множественное наследование)

Рис.8. Графическое изображение отношения обобщения в языке UML

Рис.9. Вариант графического изображения отношения обобщения классов для случая объединения отдельных линий

1. 
   Ассоциация
• 
  Это структурное отношение, которое показывает, что объекты одного типа некоторым способом связаны с объектами другого типа
• 
  Ассоциация может иметь имя и отношения
• 
  Изображается прямой линией, если по ассоциации идет навигация стрелка указывает ее направление
• 
  Класс, участвующий в ассоциации играет определенную роль. Роль имеет имя
• 
  ассоциация обладает кратностью, по умолчанию она равна бесконечности.

Рис.10. Графическое изображение отношения бинарной ассоциации между классами

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

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

Рис.11. Диаграмма классов для иллюстрации отношения агрегации на примере ПК

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

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

• целое должно передавать своим частям поступающую к нему информацию
• в композиции всегда существует хотя бы один компонент без которого структура композита уничтожается

Рис.12. Диаграмма классов для иллюстрации отношения композиции на примере класса окна программы.
Общие механизмы. Стереотипы, ограничения, обозначение значений, примечания
Пакет. Общие механизмы
В этом пакете определены общие механизмы, которые применимы ко всем моделям UML. Пакет состоит из единственного подпакета управления моделями. Этот подпакет служит для спецификации способов организации элементов в модели, пакеты и подсистемы. Кратко рассмотрим основные особенности данного подпакета.

Рис.13. Состав пакета Общие механизмы
Пакет Управление моделями (Model Management) специфицирует базовые элементы языка UML, которые необходимы для формирования всех модельных представлений. Именно в нем определяется семантика модели (Model), пакета (Package) и подсистемы (Subsystem). Эти элементы служат своеобразными контейнерами для группировки других элементов модели.
Стереотипы:
В UML описываются 4 типа сущностей

структурные

поведенческие

группирующие

анатационные

При работе со сложными системами возникает необходимость вводить новые сущности специфичные для словаря конкретной предметной области.
СТЕРЕОТИП – расширение словаря UML позволяющее создать новые строительные блоки.
Стереотип – это не то же самое, что и родительский класс по отношению к субклассу. Его можно считать неким метотипом, который создаем эквивалент классу он изображается в виде имени в «» и располагается над именем другого элемента. Стереотипами для пакетов являются слова facade, framework, stub и topLevel. Можно использовать графическое изображение.

Стереотипы, определяемые как стандартные элементы в UML:
actor – применяется к классу, определяет связанное множество ролей, которые играет пользователь.
access – применяется к зависимости. Он передает сообщение о том, что содержание какого-то пакета (целевого) доступно только внутри этого пакета.
Наиболее важные из встроенных механизмов расширения основываются на понятии стереотип. Стереотипы обеспечивают некоторый способ классификации модельных элементов на уровне объектной модели и возможность добавления в язык UML "виртуальных" метаклассов с новыми атрибутами и семантикой. Другие встроенные механизмы расширения основываются на понятии списка свойств, содержащего помеченные значения и ограничения. Эти механизмы обеспечивают пользователю возможность включения дополнительных свойств и семантики непосредственно в отдельные элементы модели.

ПРИМЕЧАНИЕ – это графическое представление ограничения или комментариев, присоединяемое к одному элементу, либо их совокупности

Рис.14.Примеры примечаний в языке UML

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

При моделировании комментариев необходимо:

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

Интерфейсы, типы и роли

Интерфейс (interface) служит для спецификации параметров модели, которые видимы извне без указания их внутренней структуры. В языке UML интерфейс является классификатором и характеризует только ограниченную часть поведения моделируемой сущности. Применительно к диаграммам вариантов использования, интерфейсы определяют совокупность операций, которые обеспечивают необходимый набор сервисов или функциональности для актеров. Интерфейсы не могут содержать ни атрибутов, ни состояний, ни направленных ассоциаций. Они содержат только операции без указания особенностей их реализации. Формально интерфейс эквивалентен абстрактному классу без атрибутов и методов с наличием только абстрактных операций.

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

Рис.15. Графическое изображение интерфейсов на диаграммах вариантов использования

В качестве имени может быть существительное, которое характеризует соответствующую информацию или сервис (например, "датчик", "сирена", "видеокамера"), но чаще строка текста (например, "запрос к базе данных", "форма ввода", "устройство подачи звукового сигнала"). Если имя записывается на английском, то оно должно начинаться с заглавной буквы I, например, ISecurelnformation, ISensor

^ Имена интерфейсов подчиняются общим правилам наименования компонентов языка UML, т. е. имя может состоять из любого числа букв, цифр и некоторых знаков препинания, таких как двойное двоеточие "::". Последний символ используется для более сложных имен, включающих в себя не только имя самого интерфейса (после знака), но и имя сущности, которая включает в себя данный интерфейс (перед знаком). Примерами таких имен являются: "Сеть предприятия сервер" для указания на сервер сети предприятия или "Система аутентификации клиентов::форма ввода пароля".

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

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

Рис.16. Графическое изображение взаимосвязей интерфейсов с вариантами использования

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

Рациональный Унифицированный процесс

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

Процесс построения отдельных типов диаграмм имеет свои особенности, которые тесно связаны с семантикой элементов этих диаграмм. Сам процесс ООАП в контексте языка UML получил специальное название — рациональный унифицированный процесс (Rational Unified Process, RUP). Концепция RUP и основные его элементы разработаны А. Джекобсоном в ходе его работы над языком UML.

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

Структурные диаграммы

В UML существует четыре структурных диаграммы для визуализации, специфицирования, конструирования и документирования статических аспектов системы, составляющих ее относительно прочный "костяк". Подобно тому как статические аспекты дома показывают, что и каким образом будет размещено в здании (стены, двери, окна, трубы, электропроводки, вентиляционные отверстия и т.д.), так и статические аспекты программных систем отражают наличие и расположение классов, интерфейсов, коопераций, компонентов, узлов и других сущностей.
Названия структурных диаграмм UML соответствуют названиям основных групп сущностей, используемых при моделировании системы:

Дата добавления: 2017-01-14