Структурный проект

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

Ларман К. Применение UML и шаблонов проектирования. 2-е издание. – М.: Издат. дом «Вильямс», 2002.- 624 с.

выделения слоёв модулей ПО, которое уменьшает сложность и делает более понятной зависимость модуля, запрещая непосредственную связь объектов, находящихся не на соседних слоях, и
использования стандартов программирования, которые делают зависимости модуля видимыми в компилируемых структурах программ и запрещают запутанные программные решения, использующие только структуры исполняемых программ.
Структурное проектирование – это управление зави­симостями модулей.

Модуль А зависит от модуля В, если изменения в моду­ле В могут потребовать изменений в модуле А.

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

(packages) согласно структурному шаблону, принятому для разрабатываемого проекта.

Пакет - группировка элементов моделирования под назначенным именем.

Пакет может содержать другие пакеты. Пакеты могут быть сгруппированы и структурированы в иерархию слоёв.
В UML пакет - логическая концепция проекта. В языках программирования поддержка пакета обеспечивается в форме пространства имен для классов и для импортирования других пакетов.

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

значит, что:
Изменения в Package В могут воздействовать на Package А, обычно приводя к потребности перекомпилировать и перепроверить Package A.
Package А может повторно использоваться только вместе с Package В.

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

устранить циклические зависимости между пакетами.

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

и пакетов

Устранять или выводить из структуры циклические зависимости между слоями (и пакетами в це­лом) позволяет структурное проектирование классов.

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

В переопределяет метод do2() объекта А. Это со­здает потенциально полиморфное поведение do2() и представляет вероят­ную зависи-мость времени выполнения в противоположном направлении от А к В. А будет зависеть от В, если метод do1() объекта А должен вызвать ме­тод do2() объекта В, а не свой собственный.
Такими видами циклических зависимостей, полученных из-за наследования, трудно управлять.

Все отношения обобщения в диаграмме пред-ставляют зависимос­ти времени компиляции в направлении изображенных стрелок. Зависимости транзитивны: если С зависит от В и В зависит от А, то С зависит от А и т.д.

не использу­ет методы объекта А. В результате Test не имеет зависимости наследования времени выполнения от А.
Если бы А переопределил метод wait(), то появилась бы зависимость времени выполнения от Test к Object и А.

2. Зависимости наследования времени выполнения

то это будет наследова-ние без полимор­физма.

переопределяет do3(), возможно, расширяя функциональные возможности, полученные от унаследованного метода. Ме­тод do3() может быть вызван как из объекта А, так и из объекта В. Он будет выполняться по-разному в зависимости от того, из какого объекта вызван.

возможность использовать вызовы методов подкласса.

Даже притом, что класс X связан с классом А, тем не менее, когда X выполня­ет do2(), он фактически выполняет реализацию do2() класса В. Это проис­ходит потому, что do2() выполняется на объекте myА, который является эк­земпляром класса В.

Вызов метода подкласса на рисунке представляет зависимость наследова­ния времени выполнения от X к B, которая не видна в статической структуре программы времени компиляции. X имеет связь с А, но не с В. Такими зави­симостями времени выполнения очень трудно управлять

также и вызо­вы методов суперкласса (или обратные вызовы).

Подкласс В явно использует реализацию предка do2(), хотя фактически и имеет свою собственную переопределенную версию do2(). Хотя такой вызов через super (base) и можно объяснить, комбинация вы­зовов методов подкласса и суперкласса представляет неприятную проблему циклической зависимости вовлеченных в это классов.

и пакетов

Зависимости между мето-дами создают проблему, пото-му что многие зависимости методов нельзя проследить, анализируя только статичес-кую структуру программы времени компиляции.
CActioner использует метод do1(), чтобы послать сообщение do3() классу EEmployee. Поэтому do1() за­висит от do3().
Зависимость распростра-няется на классы-владельцы и паке­ты. CActioner зависит от EEmployee, и control зависит от entity.

Сделать зависимости методов видимыми посредством явных ассоциаций между классами — настоятельно рекомендуемая практика.

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

CActioner и EOutMessage запрашивают сервис do3() от EEmployee. EEmployee делеги-рует выполнение сервиса классу MBroker, a MBroker делегирует его далее классу FUpdater. FUpdater исполняет сервис.
Клиент может и не знать своего реального поставщи-ка.
Без явных ассоциаций анализ воздей­ствий из-за изменений в поставляемом коде может быть невозможен.

на Subclass - подкласс, но вместо этого хранит эту ссылку как тип Superclass - суперкласс (1). Назначе­ние экземпляра Subclass ссылке на Superclass произойдет во время выполнения. Когда вызывается метод do1(), он выполняет doA () класса Superclass (2). Кажется, что doA() вызывает метод manualA(). Однако manualA класса Superclass переопределен, и поэ­тому вместо него вызывается переопределенный метод (3). Выполнение (2) и (3) — пример вызова метода под­класса.

пре-доставление струк­туры и поведения интерфейса для остальной части программы.

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

интерфейс

абстрактный класс

класс

(явная метка)

(пиктограмма)

(«оформление»)

интерфейс может быть реализован более чем одним классом.

Между классом и интерфейсом существует зависимость реализации.

Interface1 и Interface2 называются предоставленным интерфейсом класса Class1.

(или другими интерфейсами), которые затребуют их. Это называется зави­симостью использования.

Class1 содержит метод do1(), который вызывает услуги операции о1(). В статическом коде неясно, какая реализация требуемого интерфейса будет выполнять услугу.
Это может быть экземпляр любого класса, который реализует Interface1. Точный экземпляр будет определен во время вы­полнения, когда выполняемый экземпляр класса Class1 задает величину элемента данных myInterface, чтобы обратиться к конкретному объекту конкретного класса.

в коде. Программирование с интерфейсами позволяет объектам-клиентам не знать конкретные классы объектов, которые они используют, и классы, кото­рые фактически реализуют эти интерфейсы.

Цикл вызван использованием классом CInit сервисов класса PPrimaryWindow и использованием классом PDialogBox сервисов класса CActioner.
Две явные од­нонаправленные ассоциации устанавливают передачу сообщений между эти­ми классами.

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

Интерфейс определяет метод do2 (), необходи-мый для класса CInit, который находится в том же самом пакете. Но интерфейс фактически реализован классом PPrimaryWindow в паке-те presentation. CInit использует интерфейс, a PPrimaryWindow реали-зует его.

асинхронные связи, где методы «инициализируются», что­бы обслужить асинхронные события.
В обработке событий происходит отделение создателя события (объект-издатель) от различных приемни­ков/наблюдателей событий (обычно называемых объектами-подписчика­ми).
В больших системах выполнять подписку может отдельный объект-ре­гистратор, который обеспечивает «взаимодействие» между издателем и под­писчиками. Чтобы зарегистрировать подписчика у объекта-издателя, объ­ект-регистратор, действующий в интересах подписчика, вызывает метод из­дателя addActionListener() (добавить приемник операций) с объектом-подписчиком в качестве аргумента.
Обычно, объект-издатель создает объект-событие — издатель переводит внутренний смысл события в объект-событие (называя его как-то вроде BCommandButtonEvent - объект «событие от командной кнопки В»). Объект-событие передается (в режиме обратной связи) всем подписчикам, которые зафиксировали свои интересы в отношении нажатия кнопки мышью.

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

начиная с фразы add (до­бавить) и кончая фразой Listener (приемник). Имя объекта-события (XXX) поме­щается между этими двумя фразами, например addXXXListener.
Класс-издатель будет обычно содержать «нор­мальные» методы, вместе с методами, инициализирующими события. Что­бы отличать последние, они начинаются с фразы fire (инициализировать), например: fireCommandButtonEvent() (инициализация события от командной кнопки).
Метод fire пробегает список подписчиков и для каждого подписчика вызывает его собственный метод process (обработка). Для удобства имя метода process может начинаться с фразы process, например, processCommandButtonEvent() (обработка собы­тия от командной кнопки).

на события класса Pconsole. PDisplayEventRegistrator формирует подтверждение связи классам PConsole и CActioner. Метод do1() перехватывает и интерпретирует события, что инициализирует объект fireDisplayEvent(). PConsole создает объект PDisplayEvent.

Помещение PDisplayEventRegistrator в пакет presentation создает приемлемую нисходящую зависи­мость между пакетами presentation и control.

IPDisplayEventSubscriber (интерфейс «под­писчик на события отображения») отделяет PConsole от CActioner.
PConsole создает объект PDisplayEvent и использует интерфейс IPDisplayEventSubscriber, чтобы известить CActioner относительно объекта PDisplayEvent. CActioner предварительно обрабатывает PDisplayEvent с помощью своего метода processDisplayEvent () и создает объект PDecisionEvent.

как аргумент своего метода. Объект А знакомится с объектом В, если другой объект С передает В к А в качестве аргумента сообщения к А.

Зависимости знакомства - зависимости методов, возникающие динамически во время выполнения.

нарушает восходящую зависи­мость от control до presentation. IPEmployee (интерфейс «сотрудник») нарушает зависимость знакомства от presentation до domain.

состоящий только из интерфейсов. Он не представ-ляет ни слой, ни часть иерархии слоёв.

Пакет acquaintance (знакомство) отделяет зависимости знакомств в изолированную проблему, которая может управ­ляться независимо.
Используется принципа разделения задач.

исполь­зования проекта.

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

Паттерн проекта называет и объясняет лучшие и широко подтвержден­ные практику и знания, используемые для решения задач проектирования.

о клиенте на экране. Объект View получает событие и передает его своему объекту Controller. Объект Controller просит модель обеспечить данные о клиенте. Объект Model возвращает дан­ные объекту Controller, который передает их View, для отображения.

унифицированный про­цесс — использует принципы MVC при разделении классов на граничные объ­екты (boundary), объекты управления (control) и объекты-сущности (entity).

import domain.entity.*;
import domain.mediator.*;
package entity;
package mediator;
import entity.*;
import foundation.*;
package foundation;

domain.entity;
using domain.mediator;
namespace control {
// слой Управление
}
using System;
using entity;
using foundation;
namespace domain {
// слой Предметная область
namespace mediator {
// пакет Посредник
}
}

using System;
namespace domain {
// слой Предметная область
namespace entity {
// пакет Сущность
}
}
using System;
namespace foundation {
// слой Основание
}

Слои PCMEF в C#

DDP);
принцип восходящего уведомления (Upward Notification Principle — UNP);
принцип соседней связи (Neighbor Communication Principle —NCP);
принцип явной ассоциации (Explicit Association Principle — EAP);
принцип устранения циклов (Cycle Elimination Principle — CEP);
принцип именования классов (Class Naming Principle — CNP);
принцип использования пакета знакомств (Acquaintance Package Principle — APP).

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

неза-висимо, как компоненты.

Развертывание PCMEF-слоёв как компонентов завершается некоторой клиент-серверной структурой.

Компонент определя-ется в UML как «модуль-ная часть системы, ко-торая инкапсулирует ее содержание и чье объявление можно заменить в пределах среды этой системы». UML 2.0 обеспечивает также диаграмму развёртывания компо-нентов, чтобы показать ввод их в действие в среде выполнения.

лучшие и широко под-твержденные теорией и прак-тикой решения задач про-ектирования.

Отношения между паттернами Gof

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

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

Объекты-клиенты связыва-ются с пакетом через объект Фасад. Объект Фа­сад делеги-рует свою работу другим объектам пакетов. Сокращаются пути связи между пакетами и уменьшается число объектов, с которыми клиенты пакета имеют дело. Факти­чески пакет оказывается скрытым за объектом Фасад.
EEntity — доминирующий класс. Делая его интерфейсом или абстрактным классом, можно далее уменьшить зависимости клиентов от пакета entity.

семейств связанных или зависимых объектов без определения их конкретных классов».

IPPresentation (интерфейс пакета presentation) - Абстрактная фабрика, которая передает создание кон­кретных объектов или классу PConsole или PWindow, явля­ющимся конкрет-ными фабриками, в зависимости от того, как конфигуриру­ется система.
Объекты-клиенты (типа PInit) обращаются к конкретным объектам через интер­фейс (IPPresentation).

«избежать непосредственного соединения отправителя запроса с его получателем, давая возможность более чем одному объекту обработать запрос». Цепочка обязанностей — всего лишь другое название концепции делегирования.

Объект PWindow получает запрос displayContact() (отобразить делового парт-нера) и посылает сообщение retrieveContact() (извлечь делового партнера) объекту CActioner. CActioner пересылает запрос объ­екту EContact (если требуемый объект EContact был ранее инициализирован и существует в памяти про­граммы) или к MBroker (если объект EContact должен быть извлечен из БД). Если объект находится в памяти, EContact обеспечит об­служивание, и объект будет возвращен объекту PWindow для отображения. Иначе MBroker делегирует запрос объекту FReader, чтобы объект мог быть извлечен из БД и инициа­лизирован.

ко многим между объектами так, чтобы в случае изменения состояния объекта все зависимые от него объекты были уведомлены и автоматически обновлены».

Паттерн Издание-подписка (publish/subscribe ). Субъект может иметь много наблюдателей, которые подпишутся на него.

PContactBrowser подписан на EContact. EContact использует addContactListener() для регистра-ции IAContactSubscriber в качестве наблюдателя. В действительности наблюдателем является Pcontact-Browser, который реализует интерфейс IAContactSubscriber. Когда состояние EContact изменяется, fireContactChange() уведомляет об изменении интерфейс PContactBrowser, вызывая метод processContact-Change(). Метод processContact-Change() может затем запросить метод displayContact(), чтобы показать новое состояние EContact в окне браузера.