Объектно-ориентированный анализ и проектирование. Объектная декомпозиция. Паттерны объектно-ориентированного проектирования.

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

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

Как соотносятся ООА, OOD и OOP? На результатах ООА формируются модели, на которых основывается OOD; OOD в свою очередь создает фундамент для окончательной реализации системы с использованием методологии OOP. Объектно-ориентированный анализ и проектирование стандартизованы в IDEF4.

Объектная декомпозиция

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

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

Паттерны ООП – типовые решения задач, часто возникающих в процессе проектирования. Любой паттерн описывает задачу, которая снова и снова возникает в нашей работе, а также принцип ее решения, причем таким образом, что это решение можно потом использовать миллион раз, ничего не изобретая заново. В общем случае паттерн состоит из четырех основных элементов: Имя. Сославшись на него, мы можем описать проблему проектирования, ее решения и их последствия. Задача. Описание того, когда следует применять паттерн. Необходимо сформулировать задачу и ее контекст. Может описываться конкретная проблема проектирования, например способ представления алгоритмов в виде объектов. Решение. Описание элементов дизайна, отношений между ними, функций каждого элемента. Результаты - это следствия применения паттерна и разного рода компромиссы. Паттерны проектирования помогают выявить не вполне очевидные абстракции и объекты, которые могут их использовать. Например, объектов, представляющих процесс или алгоритм, в действительности нет, но они являются неотъемлемыми составляющими гибкого дизайна. Принято разделять паттерны на порождающие, структурные и поведенческие. Первые связаны с процессом создания объектов. Вторые имеют отношение к композиции объектов и классов. Паттерны поведения характеризуют то, как классы или объекты взаимодействуют между собой. В крупных программных системах как правило применяются несколько паттернов в связке. Singleton - Класс, который может иметь только один экземпляр. Decorator - Класс, расширяющий функциональность другого класса без использования наследования. Proxy - Объект, который является посредником между двумя другими объектами, и который реализовывает/ограничивает доступ к объекту, к которому обращаются через него.

Объектно-ориентированное моделирование. Унифицированный язык моделирования (Unified Modeling Language, UML). Классификация канонических диаграмм UML. Основные элементы модели, отношения между элементами модели, механизмы расширения в языке UML.

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

абстрагирование - в модель следует включать только те элементы проектируемой системы, которые имеют непосредственное отношение к выполнению ей своих функций или своего целевого предназначения. Другие элементы опускаются, чтобы не усложнять процесс анализа и исследования модели; многомодельность - никакая единственная модель не может с достаточной степенью точности описать различные аспекты системы. Допускается описывать систему некоторым числом взаимосвязанных представлений, каждое из которых отражает определенный аспект её поведения или структуры; иерархическое построение – при описании системы используются различные уровни абстрагирования и детализации в рамках фиксированных представлений. При этом первое представление системы описывает её в наиболее общих чертах и является представлением концептуального уровня, а последующие уровни раскрывают различные аспекты системы с возрастающей степенью детализации вплоть до физического уровня. Модель физического уровня в языке UML отражает компонентный состав проектируемой системы с точки зрения ее реализации на аппаратурной и программной платформах конкретных производителей.

UML (англ. Unified Modeling Language — унифицированный язык моделирования – язык визуализации) — язык графического описания для объектного моделирования в области разработки программного обеспечения. UML является языком широкого профиля, это открытый стандарт, использующий графические обозначения для создания абстрактной модели системы, называемой UML-моделью. UML был создан для определения, визуализации, проектирования и документирования в основном программных систем.

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

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

Структурные сущности - это имена существительные в моделях на языке UML. Как правило, они представляют статические части модели, соответствующие концептуальным или физическим элементам системы. Примерами структурных сущностей являются «класс», «интерфейс», «кооперация», «прецедент», «компонент», «узел», «актер». Поведенческие сущности являются динамическими составляющими модели UML. Это глаголы, которые описывают поведение модели во времени и в пр-ве. Существует 2 основных типа поведенческих сущностей:

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

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

Канонические диаграммы языка UML. Диаграмма (diagram) — графическое представление совокупности элементов модели в форме связного графа, вершинам и ребрам (дугам) которого приписывается определенная семантика. Нотация канонических диаграмм - основное средство разработки моделей на языке UML.

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

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

UML является открытым языком, то есть допускает контролируемые расширения, чтобы отразить особенности моделей предметных областей. Механизмы расширения UML включают: стереотипы (stereotype) - расширяют словарь UML, позволяя на основе существующих элементов языка создавать новые, ориентированные для решения конкретной проблемы; помеченные значения (tagged value) - расширяют свойства основных конструкций UML, позволяя включать дополнительную информацию в спецификацию элемента; ограничения (constraints) - расширяют семантику конструкций UML, позволяя создавать новые и отменять существующие правила. Совместно эти три механизма расширения языка позволяют модифицировать его в соответствии с потребностями проекта или особенностями технологии разработки.