ПКС / Design_patterns_Лекции все_114-146
.pdfМИНИСТЕРСТВО ЦИФРОВОГО РАЗВИТИЯ, СВЯЗИ И МАССОВЫХ КОММУНИКАЦИЙ РОССИЙСКОЙ ФЕДЕРАЦИИ
ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ОБРАЗОВАНИЯ «САНКТ-ПЕТЕРБУРГСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ ТЕЛЕКОММУНИКАЦИЙ ИМ. ПРОФ. М.А. БОНЧ-БРУЕВИЧА» (СПбГУТ)
Кафедра информационных управляющих систем
Б1.В.24 «Программирование критических сервисов» для специальностей по направлению 09.03.02 «Информационные системы и технологии»
1.Cервисы программного обеспечения в международных стандартах.
2.Cервисы программного обеспечения в российских стандартах.
3.Критические объекты и процессы программных средств в международных стандартах.
4.Шаблоны проектирования критических сервисов. Часть 2: Порождающие,
структурирующие и поведенческие шаблоны GoF-стандарта на UML-диаграмме классов.
5.Программные компоненты для создания критического сервиса на языке Python.
6.Программные решения на основе критических сервисов в задаче развертывания микросервисной архитектуры.
Преподаватель: Параничев Андрей Викторович
Санкт-Петербург 2023
4. Шаблоны проектирования критических сервисов |
|
115 |
4.1) Применение концепции MVC (Model-View-Controller) для разработки критических сервисов:
•шаблон представления «Model» (critical section, time-critical task; critical range, critical value);
•шаблон представления «View» (FMECA: CAI, CDR; C4I: CPI);
•шаблон представления «Controller» (SQuaRE; QFD: CPM, Critical Chain Method, Critical Piece First; MOP, MOE.
4.2) Применение GoF-стандарта (Gang of Four, Design Patterns) для разработки критических сервисов:
•порождающие (Creational) шаблоны в отношении объектов вида Application Service Object и CMIS;
•структурирующие (Structural) шаблоны в отношении объектов, определяемых как service component, service primitives, functional service и continuity service;
•поведенческие (Behavior) шаблоны, реализующих SLA, SAS, ISR.
4. Шаблоны проектирования критических сервисов |
|
|
116 |
||
1) Синглетон |
блок класса, определяемый в UML тремя горизонтальными |
|
Шаблон Синглетон (Singleton, «Одиночка») |
подблоками («полочками»): название, данные и методы/свойства. |
|
предназначен для создания уникального |
|
|
(единственного) объекта и единой точки доступа к |
|
|
нему. |
область доступа к объекту с единой глобальной точкой |
|
Различают 2 вида создания Синглетона: |
входа (entry point) к такому объекту |
|
-статический (как правило, с помощью
ключевого слова static и «приватного» |
‘+’ означает общедоступ- |
двойные |
|||
ность элементов класса |
|||||
конструктора); |
|
||||
|
угловые скобки |
||||
- динамический: реализуется с помощью |
(public), ‘-’ – закрытость для |
||||
обозначают |
|||||
вспомогательного класса: Lazy (С#), .. |
внешнего доступа (private) |
||||
типовое |
|||||
|
|
|
|
||
Динамический Синглетон сложнореализуем и обычно |
область реализации |
действие |
|||
менее предпочтителен, чем статический: при |
|
Синглетона |
|
||
отложенном создании объекта приходится |
|
|
|||
|
с единой |
|
|||
отслеживать факт его существования в режиме |
|
|
|||
|
точкой |
|
|||
времени, близком к реальному (для небольших |
|
||||
доступа |
|
||||
объектов часто более приемлемо зарезервировать |
|
||||
[база данных |
|
||||
достаточное количество статических Синглетонов с |
|
||||
разными характеристиками). |
подчеркиванием выделяют |
товаров, еди- |
|
||
|
ный сервер |
|
|||
|
статический элемент |
|
|||
|
доступа] |
|
|||
|
|
|
|
||
name_var : int; // переменная целого типа - int
main() : void; // функция, возвращающая пустое значение
4. Шаблоны проектирования критических сервисов |
|
117 |
|
2) Фабричный Метод, Виртуальный конструктор |
|
Шаблон Фабричный Метод
(Factory Method; Виртуальный Конструктор, Virtual Constructor)
предназначен для создания объектов через общий интерфейс [switch-case + общий интерфейс доступа]; рекомендуется использовать, если выборка объектов через общий интерфейс
является ограниченной (2-5%
случаев против 95-98% случаев использования Прототипа - по экспертной оценке).
область создания объекта пользователем
область «производства» объекта через общий
интерфейс доступа
I
общий
интерфейс
область реализаций объектов в соответствии с общим интерфейсом доступа
взаимосвязь физической и/или логической
принадлежности объектов (Shape «живет» внутри наследование интерфейса
ShapeFactory), «жесткая» взаимосвязь (rigid relationship)
|
4. Шаблоны проектирования критических сервисов |
|
|
|
118 |
|
|
3) Прототип |
наследование [класса]: наследуются не только форматы данных, но и методы/данные/свойства |
||
Шаблон Прототип (Prototype) рекомендуется использовать при создании типовых объектов (в >95% случаев, в противопоставление <5% Фабричного Метода).
Различают 2 вида клонирования (clone) данных при реализации Прототипа:
-«обычная» копия, (shallow copy, clone): при создании копируются все статические данные объекта;
-«полная» копия (deep copy): копируются статические и динамические данные объекта.
область |
|
|
|
|
создания |
|
|
|
|
объекта |
|
|
|
|
область |
|
A |
общий интер- |
|
|
фейс для оп- |
|||
размещения и |
|
|
||
|
|
ределения |
||
извлечения |
|
|
||
|
|
конкретных |
||
прототипов по |
|
|
||
|
|
характеристик |
||
соотношению |
|
|
||
|
|
каждого из |
||
«один-ко-одному» |
|
|
||
общий |
|
объектов- |
||
(с помощью |
интерфейс |
|
прототипов |
|
«менеджера прото- |
|
|||
доступа при |
область создания |
|||
типов», Prototype |
получении |
каждого из прототипов |
||
Manager) |
||||
копии объекта |
через общий интерфейс |
|||
|
||||
наследование интерфейса (объекты Shape обязаны включать реализацию метода Clone() )
4. Шаблоны проектирования критических сервисов |
|
119 |
4) Билдер (Построитель, Строитель)
Шаблон Билдер (Builder) применяется для создания объектов путем их поэтапной
«сборки» (assembly). [Примеры: среды разработки (Visual Studio, Android Studio, Net Beans) и приложения, «похожие» по функциональным особенностям
на IDE (MySQL Workbench, Microsoft Office)].
команды управления компонентами сборки через общий интерфейс («внутренняя» сборка)
|
область составных частей, из |
область инст- |
область зап- |
||
|
которых создается |
|
рукций по |
роса на сбор- |
|
Результат сборки |
«собранный» объект (область |
сборке |
ку и получе- |
||
«ингридиентов» сборки) |
|
|
ния «собран- |
||
создаваемых объектов – |
|
|
|||
после выполнения всех |
|
|
|
ного» объекта |
|
этапов построения. |
|
|
|
|
|
наследование [класса] |
|
|
|
|
|
(“extended” – в Java): |
|
|
|
|
|
«расширение» класса |
|
|
|
|
|
наследование интерфейса |
|
|
|
|
|
(“implemented” – в Java): |
|
команды надстройки над управлением сборкой создаваемых |
|||
имплементирование (реализация) |
|||||
объектов через общий интерфейс («внешняя» сборка) |
|||||
объявленных методов |
|
||||
|
|
|
|
||
4. Шаблоны проектирования критических сервисов |
|
|
|
120 |
|
4) Билдер (Построитель, Строитель) |
Акторы (actor), ролевые |
|
|
||
|
объекты |
|
@startuml hide footbox autonumber
participant Demo as ": BuilderPatternDemo" participant Builder as ": MealBuilder" participant Parts as ": Meal"
Demo -> Builder : <<call>> Builder -> Builder : <<create>>
Builder -> Parts : PrepareVegMeal() Parts --> Builder : ShowItems()
Builder -> Parts : PrepareNonVegMeal() Parts --> Builder : ShowItems()
Demo -> Builder : <<derive>> @enduml
|
«ответное» действие в |
|
виде возвращаемого |
на диаграмме последовательности (sequence |
значения |
diagram) указывается последовательный «план |
|
создания» объектов при использовании паттерна Builder
Формат записи акторов: имя_объекта : тип_объекта
типовое (стереотипное) действие/объект принято указывать в << >>
основное действие в виде обращения одного актора к другому
4. Шаблоны проектирования критических сервисов |
|
121 |
5) Абстрактная Фабрика (Abstract Factory; Kit, Toolkit, Инструментарий, «Набор инструментов»)
Абстрактная Фабрика предоставляет инструменты для немедленного создания типовых объектов (сами объекты создаются после предоставления ссылки на интерфейс доступа к ним). Примеры использования: Системы хранения данных (СХД, Data Storage System), файлообменники, инструменты меню в приложениях.
область «решателя» по подбору инструментов для создания объектов (например,
выбора сервера хранения данных и самих серверов) |
СХД |
«решатель» |
|
область объектов, |
|
создаваемых по |
|
запросу (ссылки на |
|
фрагменты файла) |
область пользователя |
|
|
|
инструментарием |
|
(например, отображения |
|
ссылки на размещаемый |
|
видеофайл в Сети) |
4. Шаблоны проектирования критических сервисов |
|
|
122 |
||
область «рас- |
6) Фасад |
|
|
|
|
пределения |
область |
|
полномочий» |
|
|
«полномочий» |
|
|
по отображе- |
|
|
определяет дос- |
|
|
нию объектов и |
|
|
тупные функции |
|
|
их скрытию |
|
|
|
|
|
(при реализации функций через
интерфейсы показывают
наследование
интерфейса |
область взаимодействия с |
(имплементи- |
«видимыми» и «невидимыми» |
рование функ- |
объектами по отношению к |
ций по «ро- |
пользователю (обычно через |
дительскому |
интерфейсы) |
шаблону») |
|
4. Шаблоны проектирования критических сервисов |
|
123 |
7) Мост (дескриптор/контекст)
Различают два подхода к построению Моста:
-Bridge-Down (сначала выполняется построение абстракций управляющих объектов, затем – управляемых реализаций);
-Bridge-Up (сначала – управляемые реализации, затем – управляющие объекты).
Мост также называют Handle/Body (идиома «дескриптор-контекст»)
область пользователя GUI инструментария
область встраи- |
|
|
ваемых техно- |
область инст- |
|
логических |
||
рументов |
||
решений |
||
управления |
||
|
||
наследование |
наследование |
|
интерфейса |
||
(класса) |
||
|