
ПКС / Лекции все
.pdf
Стандарт UML и GoF-стандарт |
111 |
|
Общие рекомендации по использованию паттернов (шаблонов) проектирования (Design Pattern)
-Рекомендуется использовать подходящий паттерн проектирования, когда необходимо обеспечить ГИБКОСТЬ (Flexibility) при разработке программного обеспечения (подключение к разным базам данных, а не к фиксированной БД; передача данных через динамический IP-адрес, а не через «жестко» привязанный статический адрес);
-Рекомендуется выбирать язык и набор библиотек программирования так, чтобы часть необходимых паттернов проектирования были уже РЕАЛИЗОВАНЫ (implemented) (создание ассоциативного массива: в C# есть объект Dictionary, в PHP/Pyhton есть объект HashTable; объект-перечислитель: в C#/PHP/Python есть конструкция foreach);
-Рекомендуется НЕ использовать паттерны проектирования, если на данном этапе или в будущем не потребуется обеспечивать изменчивость порождения, структурирования и/или поведения объектов (в этом случае используются ЖЕСТКИЕ (Rigid) взаимосвязи между объектами);
-Строго рекомендуется избегать антипаттернов; в том числе, когда адаптация паттерна проектирования приводит к появлению антипаттерна.
1. Антипаттерн «Spaghetti-code» (“спагетти-код”)
Антипаттерн «спагетти-код» состоит в излишнем и неоправданном нагромождении разных объектов внутри одного модуля (например, более 15-20 функций внутри объекта или дублирование реализации одинаковых функций 2 раза или более).
2. Антипаттерн «God-object» (“божественный объект”)
Антипаттерн «God-object» состоит в излишней перегрузке объекта разными функциями (например, функции подключения к БД, обработки пользовательских сообщений и выполнения функций обновления и настройки приложения внутри одного объекта).

Список литературы |
112 |
1. Gamma, E. Design Patterns. Elements of Reusable Object-Oriented Software : [Text] / E. Gamma, R. Helm, R. Johnson, J. Vlissides // Forework by Grady Booch. – 37th printing. – Boston: Adisson-Wesley, 2009. 417 p.
2. Фримен, Э. Паттерны проектирования : [Электронный ресурс] / Э. Фримен [и др.]. – Санкт-Петербург : Питер, 2017. –
656 с. : ил. – URL: http://ibooks.ru/reading.php?productid=354827
3. Шпаргалка по шаблонам проектирования [Электронный ресурс]. – 2014. – URL: https://habr.com/ru/post/210288/
4. Паттерны/шаблоны проектирования [Электронный ресурс]. – 2021. – URL: https://refactoring.guru/ru/design-patterns
5. Коломец, Н. В. О методах и средствах проектирования программного обеспечения (обзор и примеры) [Текст] / Н. В. Коломец // Ростовский научный журнал. – 2017. – № 4. – С. 249–265.
6. Pattern: Microservice Architecture [Electronic Resource]. – 2018. – URL: https://microservices.io/patterns/microservices.html
7. Плас, Дж. Вандер. Python для сложных задач: наука о данных и машинное обучение : [Электронный ресурс] / Дж. Вандер Плас. – Санкт-Петербург : Питер, 2018. – 576 с. : ил. – URL: http://ibooks.ru/reading.php?productid=356721
8. Северенс, Ч. Введение в программирование на Python : [Электронный ресурс]: учебное пособие / Ч. Северенс. – 2-е
изд. – Москва : ИНТУИТ, 2016. 231 с. – URL: https://e.lanbook.com/book/100703
9. Practical Microservices Development Patterns: CRUD Vs. CQRS : [Electronic Resource]. – 2020. – URL: https://hackernoon.com/practical-microservices-development-patterns-crud-vs-cqrs-h6m3y5y
10.Eventuate example microservices applications : [Electronic Resource]. – 2021. – URL: https://eventuate.io/exampleapps.html
11.Онлайн-редактор диаграмм PlantText [Электронный ресурс]. – URL: https://www.planttext.com/, https://www.plantuml.com/plantuml
12.Drawing UML with PlantUML. Language Reference Guide [Electronic Resource]. – 2021. 416 p. – URL: http://plantuml.com/guide

Список литературы |
113 |
13.About the Unified Modeling Language Specification Version 2.5.1 [Electronic Resource]. – 2017. – 754 p. – URL: https://www.omg.org/spec/UML/2.5.1
14.Fowler, M. UML Distilled: A Brief Guide to the Standard Object Modeling Language [Text] / M. Fowler. – 3rd Ed. Boston: Addison-Wesley, 2003. – 178 p.
15.Параничев, А. В. Опыт проектирования учебного программного продукта с помощью инструментария PlantUML
[Текст] / А. В. Параничев // Системы проектирования, технологической подготовки производства и управления этапами жизненного цикла промышленного продукта (CAD/CAM/PDM – 2017) : Труды XVII международной научно-практической конференции, Москва, 12–14 декабря 2017 года / Под ред. А.В. Толока, Институт проблем упр. им. В. А. Трапезникова. – Москва: Институт проблем управления им. В.А. Трапезникова РАН, 2017. – С. 224-227. – URL: https://www.elibrary.ru/download/elibrary_32807215_95747964.pdf
16. Котлова, М. В. Методы и средства проектирования информационных систем и технологий : [Текст] : учебное пособие / М. В. Котлова, Е. В. Давыдова ; рец.: М. П. Белов, Т. В. Матюхина. – СПб. : СПбГУТ, 2015. – 62 с.
МИНИСТЕРСТВО ЦИФРОВОГО РАЗВИТИЯ, СВЯЗИ И МАССОВЫХ КОММУНИКАЦИЙ РОССИЙСКОЙ ФЕДЕРАЦИИ
ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ОБРАЗОВАНИЯ «САНКТ-ПЕТЕРБУРГСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ ТЕЛЕКОММУНИКАЦИЙ ИМ. ПРОФ. М.А. БОНЧ-БРУЕВИЧА» (СПбГУТ)
Кафедра информационных управляющих систем
Б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
Формат записи акторов: имя_объекта : тип_объекта
типовое (стереотипное) действие/объект принято указывать в << >>
основное действие в виде обращения одного актора к другому