/
Автор: Цехановский В.В. Водяхо А.И.
Теги: программотехника разработка вычислительных систем программирование проектирование информационные системы
ISBN: 978-5-4497-2315-4
Год: 2024
Текст
Владислав Цехановский, Александр Водяхо
АРХИТЕКТОР
ИНФОРМАЦИОННЫХ СИСТЕМ:
КАК ПРОЕКТИРОВАТЬ
БОЛЬШИЕ СИСТЕМЫ
Москва
Ай Пи Ар Медиа
2024
Алматы
EDP Hub (Идипи Хаб)
2024
УДК 004.415.2
ББК 32.973
Ц55
Авторы:
Владислав Цехановский — кандидат технических наук, профессор, заведующий
кафедрой информационных систем Санкт-Петербургского государственного
электротехнического университета «ЛЭТИ», заслуженный работник высшего
образования РФ, специалист в области проектирования информационных систем,
автор ряда учебников, монографий и более 400 статей в области информационных
систем и технологий, искусственного интеллекта;
Александр Водяхо — доктор технических наук, профессор кафедры вычислительной
техники Санкт-Петербургского государственного электротехнического университета
«ЛЭТИ», специалист в области вычислительных и информационных систем,
автор ряда учебников, монографий и более 200 статей, включая статьи
в ведущих зарубежных журналах
Цехановский, Владислав Владимирович.
Ц55 Архитектор информационных систем: как проектировать боль¬
шие системы / В.В. Цехановский, А.И. Водяхо. — Москва : Ай Пи Ар
Медиа ; Алматы : EDP Hub (Идипи Хаб), 2024. — 284 с.
ISBN 978-5-4497-2315-4
Главным ресурсом ускоренного развития современного информаци¬
онного общества являются знания, главным механизмом развития — циф¬
ровая экономика, основанная на знаниях. Современный этап развития
информационных технологий характеризуется появлением большого чи¬
сла новых концепций и парадигм проектирования информационно-ори¬
ентированных систем, таких как интернет вещей, промышленный интер¬
нет вещей, большие данные, умные данные, машинное обучение, глубокое
машинное обучение. Все более широко используются ИОС в различных
областях человеческой деятельности. Отличительной особенностью таких
сверхбольших и сверхсложных систем является быстрый рост размеров,
усложнение структуры и реализуемых функций.
В издании на основе современных представлений об информацион¬
ном проектировании рассматриваются вопросы создания информацион¬
ных и программных систем на архитектурном и платформенном уровнях.
Издание предназначено для широкого круга читателей, интересую¬
щихся вопросами проектирования информационных систем.
ISBN 978-5-4497-2315-4
© Цехановский В.В., Водяхо А.И., 2024
© ООО Компания «Ай Пи Ар Медиа», 2024
СОДЕРЖАНИЕ
ОСНОВНЫЕ СОКРАЩЕНИЯ 5
О ЧЕМ ЭТА КНИГА? 6
ЧАСТЬ 1. АРХИТЕКТУРНЫЙ ПОДХОД
К ПОСТРОЕНИЮ ИОС 9
1. Каковы основные положения теории систем 10
Познакомимся с понятиями, свойствами
и классификацией систем 10
О системности, системном подходе и системном анализе 25
Система систем 27
Социотехнические системы 30
Данные, информация, знания 33
В чем отличие информационных
и информационно-ориентированных систем 37
Каковы особенности киберфизических систем 44
2. Что собой представляет архитектура ИОС 51
О понятии архитектуры 51
Каково значение архитектуры 55
Для чего нужно архитектурное описание 57
Как использовать архитектурные виды и точки зрения 68
Какие перспективы называются архитектурными 72
Для чего применяются архитектурные модели 75
В чем особенность архитектур, управляемых моделями 77
Какие существуют языки описания архитектуры 81
3. Каковы методологии архитектурного проектирования 91
Какие существуют атрибуты качества ИС 91
Какие стили используются в проектировании ИС 96
О методах управления процессом проектирования ИС 98
Как происходит работа с требованиями 114
Какие методы применяются
при архитектурном проектировании 128
-3-
СОДЕРЖАНИЕ
Что собой представляют
основные архитектурные тактики 137
О семействах и линейках продуктов 146
Архитектор ИС: какие к нему предъявляются
требования и что входит в его обязанности 149
ЧАСТЬ 2. ПЛАТФОРМЫ И ПАРАДИГМЫ,
ИСПОЛЬЗУЕМЫЕ ДЛЯ ПОСТРОЕНИЯ ИОС 157
4. Познакомимся с классическими платформами
и парадигмами 158
Как можно классифицировать архитектурные стили 158
Когда используются потоки данных 160
В каких случаях выполняется вызов с возвратом 164
О независимых компонентах 178
Что собой представляют
централизованные репозитории данных 184
В чем смысл принципа виртуальной машины 188
5. Каковы особенности перспективных парадигм
и платформ 211
О сервисно-ориентированных архитектурах 211
Как работают Web-cepвисы 218
Как выполняются облачные вычисления 225
Что такое интернет вещей (IoT) 235
Когда используются туманные и граничные вычисления 241
В чем особенности промышленного
интернета вещей (IIoT) 258
ЗАКЛЮЧЕНИЕ 270
ЛИТЕРАТУРА 272
-4-
ОСНОВНЫЕ СОКРАЩЕНИЯ
ИС — информационные системы
ИТ — информационные технологии
ИОС — информационно-ориентированные системы
IoT — Internet of Things (интернет вещей)
IIoT — Industrial Internet of Things (промышленный интернет
вещей)
ИКТ — информационные и коммуникационные технологии
КФС — киберфизические системы
ТС — теории систем
SOS — System of Systems (система систем)
SWIS — Software Intensive Systems (система интенсивного про¬
граммного обеспечения)
AmI — Ambient intelligence, системы окружающего интеллекта
АО — архитектурное описание
КИС — корпоративные ИС
ADL — Architecture Definition Language (язык описания архитек¬
туры)
ТЗ — точка зрения
MDA — Model Driven Architecture (архитектура, управляемая мо¬
делями)
MDE — Model-Driven Engineering (разработка, управляемая мо¬
делями)
DSL — Domain-Specific Language (предметно-ориентированный
язык)
UML — Unified Modeling Language (унифицированный язык мо¬
делирования)
ПО — программное обеспечение
СУБД — система управления базами данных
TCO — Total Cost of Ownership (совокупная стоимость владения)
АР — архитектурные решения
SOA — Service-Oriented Architecture (сервис-ориентированная ар¬
хитектура)
FEN — Fog Edge Nodes (туманно-граничные узлы)
SDN— Software-Defined Network (программно-определяемая сеть)
DT — Digital Twins (цифровые двойники)
-5-
О ЧЕМ ЭТА КНИГА?
Основной движущей силой современного этапа развития тех¬
ники и технологии наряду с нанотехнологиями выступают успехи
в области информационных и коммуникационных технологий (ИКТ),
науки о данных и программной инженерии. Успехи в области техни¬
ки и технологии позволяют создавать системы принципиально но¬
вого уровня сложности, обладающие принципиально новыми функ¬
циональными возможностями, в частности в плане создания, сбора,
обработки, накопления, хранения, поиска, распространения и ис¬
пользования информации.
При этом постоянно увеличивается сложность создаваемых
антропогенных систем, которая выражается не только и не столь¬
ко в увеличении числа элементов, внутренних и внешних связей
сколько в постоянном повышении уровня их вариабельности. Еще
одной важной особенностью современных антропогенных систем
является то, что они строятся из элементов разной физической при¬
роды. Это киберфизические системы (КФС), социо-кибернетиче-
ские системы, природные системы и т. п. Существенная часть сов¬
ременных антропогенных систем используют в качестве элементов
другие системы и являются системами систем.
В настоящее время информация и знания все в большей мере
становятся стратегическим ресурсом общества, его движущей про¬
изводительной силой. На смену индустриальному этапу развития
общества пришла новая эволюционная фаза, фаза информатиза¬
ции и соответствующая общественно-экономическая формация —
информационное общество, при котором наиболее эффективное
и динамичное его развитие возможно на основе максимально
полного использования имеющихся информационных ресурсов
и средств их обработки, составляющих основу соответствующих
информационных пространств. Главным ресурсом ускоренного
развития современного информационного общества становятся
знания, главным механизмом развития — цифровая экономика,
основанная на знаниях.
Главными технологиями цифровой экономики становятся но¬
вые ИКТ, которые уже фактически являются технологиями общего
-6-
о ЧЕМ ЭТА КНИГА?
назначения, так же как технологии производства тепла и электро¬
энергии. В новых условиях значительно возрастает значимость ин¬
формационных процессов, обеспечивающих материальные произ¬
водства [92].
Современный этап развития информационных технологий ха¬
рактеризуется появлением большого числа новых концепций и па¬
радигм проектирования информационно-ориентированных сис¬
тем, таких как интернет вещей, промышленный интернет вещей,
большие данные, умные данные, машинное обучение, глубокое ма¬
шинное обучение.
При внедрении и сопровождении ИС возникает ряд серьезных
проблем, часть из которых является следствием принятых архитек¬
турных решений. Можно выделить следующие проблемы:
- слабая приспособленность к изменениям в предметной обла¬
сти, проектных решениях, ИТ-ресурсах;
- внедрение и сопровождение приложений ИС требует суще¬
ственных трудозатрат вследствие отсутствия электронной модели
приложений и встроенных высокоуровневых инструментальных
средств настройки периода исполнения и разрыва между проект¬
ными решениями и кодом приложения;
- в рамках концепции управления некоторые важные функци¬
ональные области деятельности не поддерживаются действующи¬
ми приложениями;
- действующие приложения не обеспечивают поддержание
единого информационного пространства, так как представляют со¬
бой комплекс слабосвязанных программных систем.
Основными целями рассматриваемых решений являются по¬
вышение качества автоматизации деятельности в различных сфе¬
рах, сокращение затрат на проектирование, внедрение и сопро¬
вождение ИС за счет высокого уровня автоматизации реализации
проектных решений на основе использования архитектурных ре¬
шений, поддерживающих базовые модели задач управления.
Успехи техники и технологии, с одной стороны, открывают пе¬
ред разработчиками систем и, в частности, информационных сис¬
тем (ИС) принципиально новые возможности, а с другой стороны,
требуют от специалистов наличия нового уровня компетенций, как
в плане использования существующих технологий, так и способно¬
-7-
о ЧЕМ ЭТА КНИГА?
сти максимально быстро осваивать новые технологии. Этому и при¬
звана способствовать данная книга.
Издание содержит пять разделов, которые сгруппированы в две
части.
Первая часть «Архитектурный подход к построению ИОС» по¬
священа общим вопросам построения информационных и инфор¬
мационно-ориентированных систем и включает в себя три разде¬
ла. В первом разделе приводятся общие сведения из теории систем,
рассматриваются общие понятия, такие как данные, информация,
знания, понятия информационной и информационно-ориентиро¬
ванной системы. Во втором разделе определяются основные поня¬
тия, связанные с архитектурой ИОС, такие как архитектурные ви¬
ды и точки зрения, перспективы, языки архитектурного описания.
В третьем разделе рассматриваются общие вопросы архитектурно¬
го проектирования ИОС, в частности методологии управления про¬
цессом проектирования ИС, работа с требованиями, методологии
архитектурного проектирования, архитектурные тактики.
Вторая часть «Платформы и парадигмы, используемые для по¬
строения ИОС» включает два раздела. В четвертом разделе рассма¬
триваются классические платформы и парадигмы, используемые
при построении. В пятом разделе рассматриваются перспективные
парадигмы и платформы.
-8-
ЧАСТЬ 1
АРХИТЕКТУРНЫЙ ПОДХОД
К ПОСТРОЕНИЮ ИОС
1
КАКОВЫ ОСНОВНЫЕ ПОЛОЖЕНИЯ
ТЕОРИИ СИСТЕМ
ПОЗНАКОМИМСЯ С ПОНЯТИЯМИ, СВОЙСТВАМИ
И КЛАССИФИКАЦИЕЙ СИСТЕМ
Современный этап развития техники и технологии характе¬
ризуется появлением и все более широким использованием ИОС
в различных областях человеческой деятельности. Отличительной
особенностью таких сверхбольших и сверхсложных систем являют¬
ся быстрый рост размеров, усложнение структуры и реализуемых
функций, а также увеличение числа людей и коллективов, вовлечен¬
ных в процесс создания и их эксплуатации. В соответствии с хорошо
известным законом Гроша объем научной информации возраста¬
ет по экспоненте по сравнению с объемом создаваемой продукции.
Это приводит к тому, что количество появляющихся новых концеп¬
ций многократно превышает возможности изучения их специали¬
стами. Для решения этой проблемы требуется не просто научный,
а системный подход как в плане теории, так и в плане практической
деятельности [1, 2]. Новое мышление требует использования новой
теории, в качестве которой выступает теория систем [3, 4, 5, 6, 7],
основным предназначением которой является изучение вопросов
интеграции и сжатия научного знания посредством создания обо¬
бщенных моделей. В настоящее время идет процесс перехода от ин¬
дустриального к постиндустриальному обществу, которое является
информационным обществом и обществом знаний.
-10-
Познакомимся с понятиями, свойствами и классификацией систем
Определение понятия системы. Понятие «система» обычно
используется в тех случаях, когда исследуемый объект рассматри¬
вается как нечто сложное, о чем нельзя составить цельное пред¬
ставление.
Термин «система» является одним из наиболее часто исполь¬
зуемых. Известно достаточно много различных определений это¬
го термина. Единого строгого определения понятия системы в на¬
стоящее время нет. Существует несколько десятков определений
понятия «система» [4]. В отдельных предметных доменах исполь¬
зуются собственные определения понятия системы, которые отли¬
чаются как используемой терминологией, так и уровнем абстрак¬
ции. В разных конкретных ситуациях могут использоваться разные
определения.
На ранних этапах развития теории систем (ТС) понятие систе¬
мы определялось как совокупность элементов, находящихся в опре¬
деленных отношениях друг с другом и со средой [8], или как «ком¬
плекс взаимодействующих элементов». В этом случае систему S
формально можно представить как S = <E, R>, где E — сущности,
а R — отношения между сущностями.
Еще одно популярное определение системы [2], в соответствии
с которым система определяется как «нечто целое, абстрактное или
реальное, состоящее из взаимодействующих частей».
Достаточно популярно определение [6], которое рассматривает
систему как модель черного ящика, содержащую входы и выходы.
На входе имеется множество входных объектов InE, а на выходе —
множество результатов OutE, между которыми устанавливаются
обобщенные отношения пересечения S = InE * OutE.
Приведенные выше определения системы являются очень об¬
щими и с практической точки зрения их полезности ограничены.
В более поздних определениях системы [9] вводятся такие по¬
нятия, как свойства сущностей и связей, цель (Z), контекст (Ctx), вре¬
менной интервал (АТ), наблюдатель (Obs), язык наблюдателя (DSL).
В этом случае система может быть определена как S = < E, R, Qe,
Or, Z, Ctx, AT, Obs, DSL >. В данном случае понятие системы может
быть определено как отображение в сознании субъекта (наблюдате¬
ля) свойств объектов и отношений с определенной целью в рамках
определенного временного интервала. Следует заметить, что дан¬
-11-
1. КАКОВЫ ОСНОВНЫЕ ПОЛОЖЕНИЯ ТЕОРИИ СИСТЕМ
ное определение системы, являющееся обобщением нескольких ра¬
нее известных определений, отражает только статическую структу¬
ру системы и в явном виде не описывает ее поведение.
Основные понятия, относящиеся к теории систем. К основ¬
ным понятиям, связанным с понятием «система», обычно отно¬
сят следующие: элемент, подсистема, надсистема, связь, структура,
свойства, характеристики, состояние, функция, функционирование
системы, среда (контекст).
Элемент. Элементом называют атомарную (неделимую) само¬
стоятельно функционирующую часть системы. При этом преставле¬
ние об атомарности связывают с целью рассмотрения объекта, и это
решение принимает наблюдатель.
Подсистема. Система может быть разделена на относительно
независимые части, включающие в себя несколько элементов. Под¬
система обладает свойствами системы. Обычно подсистема реали¬
зует некоторую относительно независимую функцию.
Надсистема. Понятие надсистемы предполагает, что ника¬
кая система не может быть полностью отделена от внешней сре¬
ды и входит в качестве составной части в систему более высоко¬
го уровня.
Связь. Понятие связи описывает отношения между элемента¬
ми, входящими в состав системы. Связи можно также рассматри¬
вать как ограничения, накладываемые на свободу элементов.
Структура. Структуру системы обычно определяют как сово¬
купность связей, которые используются для реализации различных
типов взаимодействий между элементами системы и внешней сре¬
дой, в частности это могут быть информационные взаимодействия.
Свойства. Под свойствами системы понимают множество
параметров, определяющих поведение системы, проявляющее¬
ся в процессе взаимодействия с другими системами и объектами.
Свойства можно разделить на внешние и внутренние. Внешние
свойства проявляются при взаимодействии с другими системами
и объектами. Внутренние свойства проявляются при взаимодей¬
ствии между подсистемами, входящими в состав систем. Свойст¬
ва можно разделить на простые и сложные, которые описываются
в терминах простых свойств.
-12-
Познакомимся с понятиями, свойствами и классификацией систем
Характеристики. Характеристики — это то, что отражает не¬
которое свойство элементов или подсистем, входящих в состав си¬
стемы. Характеристики могут быть количественными или качест¬
венными.
Состояние. Состояние определяется как множество значений
характеристик, существенных с точки зрения цели исследования,
в некоторый момент времени. В простейших случаях состояние
может определяться одним параметром, например исправен/неис-
правен. Чаще состояние характеризуется многими параметрами,
представленными векторной величиной. Применительно к разным
системам изменение состояния может интерпретироваться как биз¬
нес-процесс, функционирование, движение и т. п.
Функция. Это характеристика, которая определяет поведение
системы. Обычно это понятие можно определить как внешнее про¬
явление свойств объекта. Это может быть назначение, деятельность,
работа. Функцию можно определить также через последователь¬
ность состояний, которые система проходит в процессе функцио¬
нирования. Функционированием системы обычно называют про¬
цесс последовательного изменения состояний системы. При этом
в процессе функционирования системы могут изменяться как по¬
ведение, так и структура системы.
Среда (контекст). Этот термин можно определить как «сово¬
купность всех объектов, которые влияют на систему, а также тех
объектов, чьи свойства меняются в результате функционирова¬
ния системы» [7]. При этом границы определяет исследователь (на¬
блюдатель), исходя из целей исследования. В этом контексте сис¬
тему можно рассматривать как часть мира, в которую включаются
те элементы, которые вступают между собой в разного рода связи,
определяющие ее как целостное образование, которое может взаи¬
модействовать со средой. При этом характер обмена может быть ве¬
щественным, энергетическим или информационным. Для системы
среда является источником неопределенности. Следует иметь в ви¬
ду, что наблюдаемая (исследуемая) система является элементом си¬
стемы более высокого порядка, т. е. среда, как и сама система, име¬
ет структуру и обладает свойствами.
Входы. Входами в систему называется все то, что изменяет¬
ся в процессе функционирования системы. Это могут быть вещест¬
-13-
1. КАКОВЫ ОСНОВНЫЕ ПОЛОЖЕНИЯ ТЕОРИИ СИСТЕМ
во, энергия, информация. Обобщенным входом называют некоторое
обобщенное состояние всех входов, которое определяют через вектор.
Выходы. Выходом называют конечное состояние или результат
функционирования системы. Выходы являются результатом прео¬
бразований вещества, энергии или информации.
Поведение системы. Поведение можно определить как реаль¬
ное или возможное действие системы по переходу из одного в дру¬
гое состояние. Этот термин обычно определяется применительно
к целенаправленным системам.
Показатели. Показатели можно определить как характеристи¬
ки, отражающие качество системы или ее целевую направленность.
Принято различать показатели качества и показатели эффективно¬
сти. Разница состоит в том, что первые характеризуют сам процесс
(алгоритм), а вторые характеризуют пригодность системы с точки
зрения пригодности для решения конкретных задач.
Событие. Событием называют изменение хотя бы одного свой¬
ства системы.
Процесс функционирования системы определяют как неко¬
торую последовательность смены состояний, упорядоченных по из¬
менению какого-либо параметра.
Цель. Цель определяется как желаемое состояние системы или
ситуации, которое должно быть достигнуто в результате функцио¬
нирования системы.
Ситуация. Это совокупность состояний самой системы и сре¬
ды в некоторый момент времени.
Эффективность функционирования системы определяется
как степень ее приспособленности для достижения цели.
Система как «белый ящик». Это кибернетическое понятие,
которое обозначает систему, состоящую из известных элементов
и реализующую преобразования по известным алгоритмам.
Система как «черный ящик». Это кибернетическое понятие,
которое обозначает систему, состоящую из неизвестных исследова¬
телю (наблюдателю) элементов, и он может изучать систему по из¬
менению состояний входов и выходов.
Связи и отношения. Кроме перечисления элементов, входя¬
щих в состав системы, и их характеристик, с точки зрения анали¬
за систем важными являются отношения и связи между элемента¬
-14-
Познакомимся с понятиями, свойствами и классификацией систем
ми, входящими в состав систем. Отношения связывают элементы
в систему. Отношение можно обозначить как R(X,Y), что означает,
что объект X находится в отношении R с объектом Y. Можно выде¬
лить следующие основные типы отношений: аналогия, гомомор¬
физм, идентичность, изоморфизм, логическое отношение, причин¬
ность, пространственное отношение, связь, сходство, цель-способ.
Сходство определяется как отношение совпадения между дву¬
мя или несколькими системами, объектами или процессами, опре¬
деленное наличием общих свойств.
Аналогия определяется как сходство между предметами, яв¬
лениями.
Гомоморфизм можно определить как отношение между дву¬
мя системами или процессами, когда каждую отдельную часть од¬
ной системы можно отобразить на некоторую составную часть дру¬
гой системы, но не наоборот.
Изоморфизм определяется как симметричное отношение
между двумя системами, когда каждой составной части одной сис¬
темы соответствует часть другой системы и наоборот.
Идентичность — это отношение между объектами, которое
характеризуется наличием у них одинаковых свойств. Если одина¬
ковы все свойства, то говорят об абсолютной идентичности. При
совпадении только части свойств говорят об относительной иден¬
тичности или сходстве.
Причинность представляет собой асимметричное отношение
между причиной и действием. Причины вызывают действие.
Пространственное отношение характеризует взаимное рас¬
положение элементов системы в пространстве, которое обычно за¬
дается трехмерной системой координат.
Логическое отношение можно определить как отношение
между объектами, которое описывается посредством типа «а > b»,
«не или» и т. п.
Временные отношения используются для контроля процес¬
сов. В качестве временных отношений могут выступать такие по¬
нятия, как «раньше», «позже», «одновременно».
Отношение связи. Это одно из основных отношений в теории
систем. Отношение связи имеет место в случае, если выходы одно¬
го элемента системы являются входами другого элемента системы.
-15-
1. КАКОВЫ ОСНОВНЫЕ ПОЛОЖЕНИЯ ТЕОРИИ СИСТЕМ
Типы связей. Если выходы системы или ее элемента однов¬
ременно являются входами другой системы или элемента, то такое
отношение называется связью. Связи могут быть материальными,
энергетическими. Понятие связи входит в определение системы,
используется для описания как статики, так и динамики системы.
Связь можно определить также как ограничение степени свободы
элементов системы. Чаще всего связи характеризуются направле¬
нием (направленные, ненаправленные), силой (сильные, слабые),
видом (подчинение, равноправные, управление и др.). В качест¬
ве простейших типов связей выступают последовательное соеди¬
нение элементов, параллельное соединение элементов, обратная
связь, комбинированные связи.
Структура системы. Структура отражает наиболее значимые
взаимодействия между элементами системы, которые незначитель¬
но меняются при изменениях, происходящих в системе. Под структу¬
рой можно также понимать принцип связи элементов в единое целое.
Для описания структуры системы часто используют теорию
графов [10, 11].
Классификация структур систем. В зависимости от топологии
принято выделять следующие основные структуры: линейные струк¬
туры, иерархические (древовидные) структуры, сетевые структуры,
матричные структуры и смешанные (комбинированные) структуры.
С точки зрения степени подчиненности в системе можно вы¬
делить три типа структур: иерархические, неиерархические и смешан¬
ные. Подсистемы, которые получаются в результате выделения из
одной системы, называют подсистемами одного уровня. Подси¬
стемы, получаемые в результате дальнейшего деления, рассматри¬
ваются как подсистемы более низкого уровня. Подобное деление
называют иерархией. Иерархию можно рассматривать как упоря¬
дочение компонентов по степени важности. Более строго иерархию
можно определить как структуру, в которой присутствуют неравно¬
правные связи между элементами, т. е. отношения подчиненности.
В этом случае воздействие в одном из направлений оказывается
более сильным, чем в другом направлении. Можно считать, что на¬
личие иерархии является показателем высокого уровня организа¬
ции системы. Для иерархических систем характерно использование
управляющих подсистем, а в неиерархических системах функции,
-16-
Познакомимся с понятиями, свойствами и классификацией систем
связанные с управлением, распределены между разными элемен¬
тами или группами элементов.
Многоуровневые иерархические системы. Данное понятие
является многоаспектным, и его сложно определить краткой фор¬
мулировкой. Практически все многоуровневые иерархические сис¬
темы обладают следующими свойствами:
1) вертикальное расположение подсистем;
2) право вмешательства подсистем верхнего уровня в функци¬
онирование подсистем более низкого уровня;
3) зависимость действий, реализуемых подсистемами верхне¬
го уровня, от результатов функционирования подсистем нижнего
уровня.
В теории систем обычно принято рассматривать три вида
иерархий: страты, слои и эшелоны.
С понятием «страты» принято связывать уровень абстрагиро¬
вания при описании системы. Например, функционирование ком¬
пьютера может быть описано как в терминах физических процес¬
сов, протекающих в микросхемах, так и в терминах алгоритмов,
используемых для обработки информации. Классические автома¬
тизированные системы управления описывались на четырех уров¬
нях: экономико-математические модели (модельное обеспечение,
информационное обеспечение, программное обеспечение, техни¬
ческое обеспечение).
Страты. Следует заметить, что описания системы на разных
стратах в общем случае не связаны между собой, и принципы, ис¬
пользуемые для описания системы на одной страте, не могут быть
выведены из принципов, используемых для описания системы на
других стратах. На каждой страте имеются собственный словарь
(набор терминов), собственные концепции и принципы. Обычно
чем ниже мы спускаемся по иерархии страт, тем более детально
описываются структура и поведение системы. Напротив, чем выше
мы поднимаемся по иерархии страт, тем яснее становится общая
логика организации и функционирования системы.
Слои. В теории систем понятие многослойной системы связы¬
вают с процессом принятия сложных решений [7]. Примером может
быть решение проблемы принятия сложных решений посредством
сведения процесса решения сложной задачи к решению последо¬
-17-
1. КАКОВЫ ОСНОВНЫЕ ПОЛОЖЕНИЯ ТЕОРИИ СИСТЕМ
вательности подзадач. Построение многослойных структур — это
один из основных элементов системного анализа (дерево целей).
Применительно к материальным системам можно считать, что если
стратифицированные системы характеризуют объект с точки зре¬
ния пространственных отношений, то многослойные системы ха¬
рактеризуют его с точки зрения временных отношений.
Эшелоны. Многоэшелонные системы выступают в качестве обо¬
бщающей иерархии, которую можно рассматривать как сочетание
структурной и функциональной иерархий. При описании многоэше¬
лонных систем с понятием эшелона связывают уровень или элемент
системы, ответственный за принятие тех или иных решений. Отли¬
чительной особенностью многоэшелонных структур является предо¬
ставление отдельным подсистемам определенной свободы при вы¬
боре их собственных решений. При описании системы в терминах
эшелонов обычно предполагается, что система состоит из множест¬
ва четко выделенных взаимодействующих между собой подсистем,
при этом некоторые из подсистем могут принимать решения.
Каждая из перечисленных выше форм описания иерархи¬
ческих структур имеет свое назначение. Страты обычно исполь¬
зуются для целей моделирования. Слои — для вертикальной де¬
композиции задачи на подзадачи. Эшелоны — для описания
взаимодействия между отдельными подсистемами, ответствен¬
ными за принятие решений.
Помимо перечисленных подходов можно выделить разноо¬
бразные их комбинации, которые чаще всего используются на пра¬
ктике.
В качестве общих для всех трех видов описаний можно выде¬
лить следующие черты:
1) элементы более высокого уровня работают с более крупными
подсистемами и более общими механизмами поведения;
2) для элементов верхнего уровня период принятия решения
больше, чем для элементов, расположенных на более низких уровнях;
3) проблемы и их описания на верхних уровнях содержат боль¬
ше неопределенностей, и их количественная оценка не всегда воз¬
можна.
-18-
Познакомимся с понятиями, свойствами и классификацией систем
Наряду с иерархичностью важнейшим свойством системы яв¬
ляется ее целостность. Под целостностью системы понимают не¬
сводимость свойств системы к сумме составляющих ее элементов,
т. е. система по отношению к окружающей среде будет восприни¬
маться как целое. Необходимо иметь в виду, что целостность сис¬
темы тесно связана с целью, для достижения которой предназначе¬
на система. Одним из признаков целостности системы является ее
обособленность от окружающей среды. Под средой при этом пони¬
мают множество объектов, находящихся вне рассматриваемой си¬
стемы. Со средой система может обмениваться веществом, энерги¬
ей или информацией (данными, знаниями). При этом среда может
оказывать воздействие на систему только через ее входы и воспри¬
нимать реакцию на эти действия через выходы системы.
Если речь идет об искусственных системах, то их создание
практически всегда имеет некоторую цель. Цель можно опреде¬
лить как «субъективный образ не существующего состояния среды
или объекта, который бы решил возникшую проблему» [7]. Одна
система может иметь несколько целей, несколько разных систем
могут иметь одну цель.
Системы, которые могут взаимодействовать со средой, назы¬
вают открытыми, закрытые системы не имеют среды. Кроме того,
выделяют условно закрытые системы, которые взаимодействуют со
средой по известным каналам и используют известные интерфей¬
сы. Большинство современных ИС относится именно к этому классу.
Модели системы. Модель системы можно определить как опи¬
сание системы, отображающее группу свойств. Использование мо¬
дели позволяет, в частности, предсказать ее поведение в определен¬
ном диапазоне условий.
Понятия, характеризующие функционирование и развитие
систем. Процессы, протекающие в системах, особенно сложных си¬
стемах, часто не удается описать с помощью математических соот¬
ношений, поэтому обычно для этой цели используют аппарат, раз¬
работанный в теории автоматического регулирования. Обычно для
описания процессов, протекающих в системах, теория систем ис¬
пользует такие понятия, как «состояние», «поведение», «равновесие»,
«устойчивость», «развитие», «модель функционирования системы».
-19-
1. КАКОВЫ ОСНОВНЫЕ ПОЛОЖЕНИЯ ТЕОРИИ СИСТЕМ
Состояние представляет упорядоченную совокупность значе¬
ний параметров системы, отнесенную к определенному моменту
времени.
Поведение системы можно определить как развернутую во
времени последовательность реакций системы на внешние воз¬
действия.
Моделью функционирования системы называют модель,
способную предсказывать изменения состояния системы во вре¬
мени.
Под устойчивостью понимают способность системы возвра¬
щаться в состояние равновесия после того, как она была выведена
из этого состояния под влиянием внешних воздействий.
Понятие развития описывает возможные изменения в струк¬
туре и поведении системы в течение времени ее жизни. Системы,
способные к развитию, выделяют в отдельный класс развивающих¬
ся систем.
Классификация систем. В настоящее время существует огром¬
ное число классификаций систем, что обусловлено их разнообра¬
зием. Следует заметить, что любая классификация имеет опреде¬
ленную цель. На рис. 1.1 приведена классификация систем, целью
которой является выделение класса ИОР. За основу данной клас¬
сификации взята классификация, приведенная в [4, 7, 8]. В качест¬
ве классификационных признаков верхнего уровня предлагается
использовать следующие признаки: тип субстанциональности, тип
отображаемого объекта, возможность связи с внешней средой, спо¬
собность к изменению состояния, характер функционирования, по
виду элемента, по происхождению, по научной области, к которой
относится система, типы элементов системы, по способу управле¬
ния и уровню сложности.
По субстанциональному признаку можно выделить искусст¬
венные, естественные, концептуальные (идеальные) и виртуальные.
Искусственные (антропогенные) системы — это системы, со¬
зданные человеком. К этому классу систем могут быть отнесены
технические системы, производственные комплексы, организаци¬
онные структуры. Естественные системы — это объективно сущест¬
вующие в живой, неживой природе и обществе системы.
-20-
Познакомимся с понятиями, свойствами и классификацией систем
Системы
X
Тип субстанциональности
Искусственные
JZ
Естественные
Ко н це птуал ьн ые
X
Виртуальные
Отображаемый объект
т
Технические
Биологические
х
Социальные
х
Смешанные
Связь со средой
X
Открытые
X
Закрытые
Изменение состояния
Статические
х
Динамические
Характер функционирования
Детерминированные
X
Стохастические
По виду элемента
X
Реальные объекты
X
Абстрактные объекты
Происхожден ие
X
Искусственные
X
Природные
X
Социальные
X
Виртуальные
X
Смешанные
Научная область
X
Физика
X
Химия
Математика
X
Прочее
Тип элементов
X
Объекты
X
Процессы
По способу управления
X
Внешнее
X
Внутреннее
X
Комбинированное
1
Сложность
X
Простые
X
Сложные
X
Сверхсложные
X
Ультрасложные
Рис. 1.1. Классификация систем
-21-
1. КАКОВЫ ОСНОВНЫЕ ПОЛОЖЕНИЯ ТЕОРИИ СИСТЕМ
Концептуальные (идеальные) системы выражают некоторый
образцовый мир, который обычно рассматривается как цель. При¬
мером концептуальной теории может служить научная теория.
Виртуальные системы можно определить как системы, которые
не существуют в действительности. Это может быть, например, мы¬
сленное представление реальных объектов.
Система может состоять из объектов разной природы. Это мо¬
гут быть технические, биологические, социологические, экономи¬
ческие объекты.
Если система имеет хотя бы один вход или выход, который свя¬
зывает ее с окружением, то она называется открытой. В противном
случае речь идет о закрытой системе.
Если система с течением времени изменяет свое состояние, то
такая система называется динамической. Если состояние системы
остается неизменным, то систему определяют как статическую.
По характеру функционирования системы можно разделить
на детерминированные, когда в зависимости от ее состояния мож¬
но однозначно судить о ее функционировании, и стохастические,
когда можно только высказывать предположения о возможных ва¬
риантах функционирования.
Элементы системы могут быть как конкретными, так и аб¬
страктными сущностями. Также элементами могут быть не толь¬
ко объекты, но и процессы.
По происхождению элементы системы можно разделить на
искусственные, естественные (природные), виртуальные (вообража¬
емые) и смешанные.
По способу управления системы можно разделить на три груп¬
пы: управляемые извне, управляемые изнутри (самоуправляемые)
и комбинированные системы со смешанным управлением.
С точки зрения сложности системы можно разделить на про¬
стые, сложные, сверхсложные и ультрасложные.
Сложные и большие системы. Понятия «большая система»
и «сложная система» достаточно безлики и в ряде частных случа¬
ев могут совпадать. Известны различные подходы к определению
уровня сложности систем. В [7], например, в зависимости от числа
-22-
Познакомимся с понятиями, свойствами и классификацией систем
элементов, входящих в состав системы, выделяются четыре клас¬
са систем:
- простые (малые) системы, состоящие из 10—103 элементов;
- сложные системы, состоящие из 103—107 элементов;
- сверхсложные (ультрасложные) системы, состоящие из 107—1030
элементов;
- очень сложные (суперсистемы) системы, состоящие из 1030¬
10206 элементов.
Следует заметить, что разделение системы на элементы зави¬
сит от цели исследования системы и носит субъективный характер,
поэтому приведенное выше разделение систем на классы являет¬
ся относительным.
Понятие сложной системы близко, но не идентично понятию
большой системы. Сложную систему определяют как систему, в ко¬
торой не хватает ресурсов для эффективного описания ее состоя¬
ния, законов функционирования и механизмов управления.
В соответствии с этим определением к сложным системам
можно отнести такие системы, как человеческий мозг, экономику
на макроуровне, человеческое общество.
Сложность системы может быть как внешней, так и внутренней.
В качестве меры внутренней сложности может выступать число
внутренних состояний. В качестве меры внешней сложности — чи¬
сло обратных связей со средой [4, 7].
Следует различать статическую сложность (сложность струк¬
туры) и динамическую сложность, связанную со сложностью пове¬
дения. Статическая и динамическая сложность напрямую не связа¬
ны между собой. Приблизительной мерой сложности может служить
число уровней иерархии.
Чаще всего выделяют такие виды сложности, как структурная
сложность, сложность поведения и сложность выбора правил по¬
ведения.
Структурная сложность определяется количеством, разно¬
образием элементов и связей, а также числом уровней иерархии.
Сложность поведения определяется мощностью множества состо¬
яний, сложностью правил перехода между состояниями, сложно¬
-23-
1. КАКОВЫ ОСНОВНЫЕ ПОЛОЖЕНИЯ ТЕОРИИ СИСТЕМ
стью процедур взаимодействия с внешним миром и степенью не¬
определенности этих характеристик и правил. Сложность выбора
поведения в многоальтернативной ситуации определяется гибко¬
стью реакции системы на внешние воздействия. Чаще всего этот
вид сложности встречается в адаптивных и самоорганизующихся
системах.
Следует заметить, что сложность существенно зависит от уров¬
ня описания.
Понятие большой системы отражает точку зрения исследовате¬
ля на систему. Система определяется как большая, если «ее исследо¬
вание или моделирование затруднено из-за большой размерности
и для ее исследования не хватает таких ресурсов, как время, произ¬
водительность компьютеров, объем баз данных и т. п.» [7]. При этом
под размерностью понимается число состояний системы.
Примерами больших систем могут служить экологические си¬
стемы, экономические системы. В большинстве больших систем
в контуре управления присутствует человек, на которого возлага¬
ются наиболее ответственные функции, связанные с управлением.
Управление в больших системах может быть централизован¬
ным или децентрализованным.
Централизованное управление предполагает концентрацию
функций управления в одном центре системы. При использова¬
нии децентрализованного подхода, напротив, функция управления
распределяется по отдельным элементам системы. При использо¬
вании централизованного подхода информация о состоянии всех
объектов собирается в едином центре, где осуществляется ее об¬
работка и вырабатываются управляющие воздействия. Основным
достоинством централизованного управления является принципи¬
альная возможность реализации глобально-оптимального управ¬
ления всей системой, поскольку управляющие воздействия мож¬
но формировать на основе полной информации о состоянии всей
системы, появляется возможность достижения максимальной эф¬
фективности функционирования подсистемы управления. Необхо¬
димо собирать, хранить и обрабатывать чрезвычайно большие объ¬
емы информации.
-24-
О системности, системном подходе и системном анализе
Децентрализованное управление предполагает распределение
функций управления по отдельным элементам системы. Для вы¬
работки управляющих воздействий на каждый объект использует¬
ся информация о состоянии этого объекта, информация о состоя¬
нии других объектов не учитывается. В этом случае фактически речь
идет о системе систем. Децентрализованное управление свободно
от недостатков, присущих централизованному управлению, но име¬
ет свои собственные серьезные недостатки, в частности проблема¬
тичность реализации оптимального управления, высокая стоимость
всей подсистемы управления, невысокое качество управления.
На практике большая часть реальных больших и сложных сис¬
тем относятся к промежуточному типу. Примером может служить
централизованно-распределенная структура. От полностью центра¬
лизованной системы управления она отличается тем, что не име¬
ет четкой локализации в единой подсистеме управления, т. е. сис¬
тема продолжает управляться на основе полной информации о ее
состоянии, но сама подсистема управления является распределен¬
ной. Часто на разных уровнях иерархии используются разные ме¬
ханизмы управления. Если представить систему состоящей из двух
подсистем: собственно системы и подсистемы управления, то в со¬
ответствии с принципом Эшби [3] можно утверждать, что подсис¬
тема управления должна иметь более высокий уровень организа¬
ции по сравнению с управляемой системой. При этом под уровнем
организации понимается число состояний, в которых может нахо¬
диться подсистема.
О СИСТЕМНОСТИ, СИСТЕМНОМ ПОДХОДЕ
И СИСТЕМНОМ АНАЛИЗЕ
Рассмотрим более подробно взаимосвязь между основны¬
ми понятиями, относящимися к теории систем, и их соотношение
с ИС, такими как «системность», «теория систем», «системный ана¬
лиз, «системный подход».
Наиболее общим понятием следует считать понятие системно¬
сти. Принцип системности предполагает, что объект исследования
представляется в виде системы, состоящей из связанных между со¬
-25-
1. КАКОВЫ ОСНОВНЫЕ ПОЛОЖЕНИЯ ТЕОРИИ СИСТЕМ
бой элементов, обладающей некоторой структурой и реализующей
определенное поведение. Системное познание предполагает рас¬
смотрение объекта исследования или другой деятельности как си¬
стемы, состоящей из множества взаимодействующих между собой
и внешним миром элементов.
Системное познание в качестве составных частей включает
в себя системный подход, теорию систем и системный метод.
Системный подход можно определить как принцип позна¬
вательной деятельности, включающий в себя совокупность при¬
емов и способов изучения или проектирования чего-либо или
ведения дел. Однако это не детальный алгоритм, а множество
обобщенных правил, использование которых позволяет в боль¬
шинстве случаев получить правильное, но не гарантированно
правильное решение.
Теорию систем в отличие от системного подхода можно рас¬
сматривать как строго научное знание о мире систем.
Системный метод определяется как «некоторая интегральная
совокупность относительно простых методов и приемов познания,
а также преобразования действительности» [1, 2].
Успехи техники и технологии открыли широкие перспективы
в плане создания систем нового уровня сложности, проектирова¬
ние которых оказалось невозможным без использования систем¬
ного мировоззрения, что резко повысило интерес к системным
исследованиям.
Постепенно различные виды системных теорий начали интег¬
рироваться в системологию, представляющую собой науку о сис¬
темах, которая включает в себя общую теорию систем, отраслевые
и частные теории, системотехнику. Обобщенная структура показа¬
на на рис. 1.2.
Общая теория систем включает в себя наиболее общие зна¬
ния о системах. Она тесно связана и в значительной степени ба¬
зируется на философии и математике. Специальные теории сис¬
тем направлены на изучение отдельных аспектов организации
и функционирования систем. Отраслевые теории систем изуча¬
ют специфику систем различной природы (физических, биологи¬
-26-
Система систем
ческих, социальных). Термин «системный подход» обычно приме¬
няется с целью подчеркнуть использование теории систем или ее
отдельных элементов для решения практических задач. При этом
предполагается необходимость комплексного исследования объ¬
екта с разных точек зрения с целью получить о нем правильное
представление. Системный подход находит самое широкое приме¬
нение при проектировании антропогенных (инженерных) систем,
к числу которых могут быть отнесены информационные системы.
Как будет показано ниже, архитектурный подход к проектиро¬
ванию ИС можно рассматривать как интерпретацию системного
подхода к проектированию ИС.
Рис. 1.2. Структура системологии связи с ИС
СИСТЕМА СИСТЕМ
Фактически ни одна система не разрабатывается с нуля
и не используется независимо от других систем. Каждая система
имеет контекст, то есть, с одной стороны, она взаимодействует
с людьми, а с другой стороны, с системами в своей среде. Систе¬
мы иногда используются в сочетании со многими другими техни¬
-27-
1. КАКОВЫ ОСНОВНЫЕ ПОЛОЖЕНИЯ ТЕОРИИ СИСТЕМ
ческими и социально-техническими системами как часть более
крупной и гораздо более сложной системы. При определенных
обстоятельствах такого рода композиции из множества рассеян¬
ных и независимых систем называются системой систем (System
of Systems, SoS) [1].
SoS отличается от единой монолитной системы и от дру¬
гих видов системных группировок (например, семейства систем)
следующим образом:
1. Слабая связь элементов. В общем случае термин «связь» от¬
носится к степени зависимости составляющих друг от друга. Од¬
ной отличительной особенностью, которая позволяет понять, что
вы столкнулись с системой систем, а не с одной монолитной сис¬
темой, является очень слабая связь ее составляющих, то есть ее со¬
ставных систем. Составные системы не обмениваются друг с дру¬
гом энергией, веществом или информацией в большом объеме.
Связь между ними обычно осуществляется посредством обмена
данными через ИТ-интерфейсы. Обычно SoS являются распреде¬
ленными системами.
2. Эмерджентное поведение. Система поведения систем воз¬
никает в результате совокупных действий и взаимодействий ее
составляющих. Поведение SoS — это нечто большее, чем про¬
сто сумма возможностей составляющих ее систем. Для создания
эмерджентного поведения все системы должны взаимодейство¬
вать друг с другом. Необходимым условием является то, что ка¬
ждая система может обмениваться сообщениями с другими сис¬
темами, входящими в состав SoS.
3. Операционная независимость: SoS можно разбить на состав¬
ные части (компонентные системы), эти системы могут работать
независимо вне SoS или могут присоединиться к другой SoS.
4. Независимое управление элементами: большинство систем-
компонентов, которые образуют SoS, независимо разрабатывают¬
ся, производятся, приобретаются и администрируются. Их жизнен¬
ный цикл не зависит от жизненного цикла всей системы систем и от
жизненного цикла других составляющих SoS.
5. Эволюционное развитие. Обычно не существует полностью
развитой SoS. Ее развитие и существование носят эволюцион¬
-28-
Система систем
ный характер, то есть на протяжении всего жизненного цикла-
системы ее структура и реализуемый функционал могут быть из¬
менены в зависимости от новых или измененных требований,
новых возможностей, измененных базовых условий или изме¬
ненных целей.
Хотя не каждая SoS обладает всеми вышеупомянутыми свой¬
ствами, эти критерии являются типичными характеристиками SoS.
Наиболее важной характеристикой SoS являются ее эмерджентные
свойства. В этом отношении SoS наиболее существенно отличается
от концепции семейства систем.
Отличительной особенностью SoS является то, что два или бо¬
лее ее элементов управляются независимо. Разные люди с разны¬
ми приоритетами имеют полномочия принимать повседневные
оперативные решения об изменениях в системе.
Поскольку их работа не обязательно согласована, могут возни¬
кать конфликты, для разрешения которых требуется значительное
количество времени и усилий. Таким образом, SoS всегда имеют не¬
которую степень сложности управления.
Следует заметить, что SoS охватывает очень широкий спектр
типов систем, которые могут принадлежать одной организации,
но управляются разными подразделениями этой организации.
SoS также включает системы, составляющие системы которых
принадлежат и управляются различными организациями, кото¬
рые иногда могут конкурировать друг с другом. С точки зрения
сложности управления SoS можно классифицировать следую¬
щим образом:
1. Управляемые системы. Управляемые SoS принадлежат одной
организации и строятся путем интеграции систем, которые также
принадлежат этой организации. Элементы такой SoS могут управ¬
ляться подразделениями организации независимо друг от друга.
Однако в организации существует высший руководящий орган, ко¬
торый может устанавливать приоритеты для управления SoS. Он
может, например, разрешать споры между менеджерами различных
элементов SoS. Примером такой SoS может служить военная систе¬
-29-
1. КАКОВЫ ОСНОВНЫЕ ПОЛОЖЕНИЯ ТЕОРИИ СИСТЕМ
ма командования и управления, которая объединяет информацию
от бортовых и наземных систем.
2. Федеративные системы. Федеративные SoS — это системы,
в которых нет центрального органа для определения приоритетов
управления и разрешения споров. Как правило, элементы системы
принадлежат и управляются различными организациями. Одна¬
ко все участвующие организации признают взаимные выгоды сов¬
местного управления системой. Поэтому они обычно создают добро¬
вольный орган управления, который принимает решения о системе.
Системы сотрудничества обладают как сложностью управления, так
и ограниченной степенью сложности управления. Интегрированная
информационная система общественного транспорта является при¬
мером такой SoS. Поставщики услуг автобусного, железнодорожно¬
го и воздушного транспорта соглашаются связать свои системы для
предоставления пассажирам актуальной информации.
3. Коалиционные системы. Коалиционные системы не имеют
централизованного управления, и участники могут не прийти к со¬
гласию относительно общей цели системы. Системы-участники мо¬
гут входить в SoS или выходить из нее. Совместимость не гаранти¬
руется, но зависит от опубликованных интерфейсов, которые могут
измениться. Эти системы обладают очень высокой степенью управ¬
ленческой сложности. Примером коалиционной SoS является авто¬
матизированная торговая система, в рамках которой системы от
разных компаний автоматически покупают и продают акции друг
у друга, причем сделки совершаются за доли секунды.
СОЦИОТЕХНИЧЕСКИЕ СИСТЕМЫ
Основными компонентами ИОС являются программное обес¬
печение и аппаратное обеспечение. Без аппаратного обеспечения
ИОС — это не более чем абстракция. Без программного обеспече¬
ния аппаратное обеспечение представляет собой набор инертных
электронных устройств. Однако если их объединить вместе, чтобы
сформировать систему, то можно создать систему, которая может
выполнять сложные вычисления и передавать результаты этих вы¬
числений в некоторую среду. Это иллюстрирует одну из фундамен¬
-30-
Социотехнические системы
тальных характеристик системы, которая состоит в том, что систе¬
ма — это нечто большее, чем сумма ее частей.
Системы обладают свойствами, которые становятся очевид¬
ными только тогда, когда их компоненты интегрированы и ра¬
ботают вместе. ИОС являются не изолированными системами,
а частью более крупных систем, которые имеют социальное или
организационное назначение.
Поэтому разработка ИОС — это не изолированный вид деятель¬
ности, а неотъемлемая часть системной инженерии.
Например, программное обеспечение, которое управляет при¬
борами на метеостанции, взаимодействует с другими программ¬
ными системами и является частью региональной, национальной,
международной системы прогнозирования погоды. Помимо аппа¬
ратного и программного обеспечения, эти системы включают про¬
цессы прогнозирования погоды и людей, которые управляют сис¬
темой и анализируют ее результаты, а также организации, которые
используют эти системы с целью предоставления прогноза погоды
частным лицам, правительству и транспорту.
Системы, включающие в себя нетехнические элементы, такие
как люди, процессы и правила, а также технические компоненты,
такие как компьютеры, программное обеспечение и другое обору¬
дование, называют социотехническими системами. Социотехни¬
ческую систему обычно определяют как совокупность технологиче¬
ского процесса производства, трудовых отношений и институтов,
обеспечивающих их стабильность. Все организации рассматрива¬
ются как системы, а люди являются в общем смысле компонентами
организаций (социальные компоненты), наряду с техникой, кото¬
рые вместе используются для выполнения работы, они называют¬
ся социотехническими системами [12].
Социотехническая система включает в себя две основные
подсистемы:
1) техническую подсистему (устройства, инструменты и техно¬
логии, преобразующие вход в выход);
2) социальную подсистему, которая включает занятых в орга¬
низации служащих (знания, умения, настрой, ценностные установ¬
-31-
1. КАКОВЫ ОСНОВНЫЕ ПОЛОЖЕНИЯ ТЕОРИИ СИСТЕМ
ки, отношение к выполняемым функциям), управленческую струк¬
туру, систему поощрений.
Если рассматривать организацию в более широком контексте,
тогда в качестве ее внешних связей можно учитывать связи орга¬
низации с окружающей средой, социальными и государственны¬
ми институтами, с которыми взаимодействует организация, дру¬
гие организации, выступающие конкурентами или находящиеся
в других отношениях.
Социотехнические системы обычно представляют в виде семи¬
уровневой системы (рис. 1.3), слои которой образуют социотехни¬
ческие системы:
1. Уровень оборудования состоит из аппаратных устройств, не¬
которые из которых могут быть компьютерами.
2. Уровень операционной системы взаимодействует с аппарат¬
ным обеспечением и предоставляет набор общих возможностей для
более высоких уровней программного обеспечения в системе.
3. Уровень связи и управления данными расширяет возможно¬
сти операционной системы и предоставляет интерфейс, позволяю¬
щий взаимодействовать с более широкими функциональными воз¬
можностями, такими как доступ к удаленным системам и доступ
к системной базе данных. Это иногда называют промежуточным
программным обеспечением, так как оно находится между прило¬
жением и операционной системой.
4. Уровень приложений обеспечивает необходимую функци¬
ональность для конкретного приложения. На этом уровне может
быть много различных прикладных программ.
5. Уровень бизнес-процессов включает организационные биз¬
нес-процессы, в которых используется программная система.
6. Организационный уровень включает стратегические процес¬
сы более высокого уровня, а также бизнес-правила, политику и нор¬
мы, которые следует соблюдать при использовании системы.
7. Социальный слой относится к законам и правилам общества,
которые регулируют функционирование системы.
На рис. 1.4 показано, как соотносятся понятия системной и про¬
граммной инженерии. Программная инженерия является более уз¬
ким понятием по сравнению с системной инженерией.
-32-
Данные, информация, знания
Общество
Организация
Бизнес-процессы
Прикладные системы
Коммуникации и управление
Операционная система
Оборудование
Рис. 1.3. Системная и программная инженерия
ДАННЫЕ, ИНФОРМАЦИЯ, ЗНАНИЯ
Для определения понятия «информационная система» важ¬
ным представляется определить само понятие информации. Можно
выделить, по крайней мере, два подхода к определению этого по¬
нятия: классический подход, развиваемый в теории информации,
и иерархический подход.
Классический подход. В классической ИС информацию опреде¬
ляют как косвенное сигнальное взаимодействие. При этом сигналь¬
-33-
1. КАКОВЫ ОСНОВНЫЕ ПОЛОЖЕНИЯ ТЕОРИИ СИСТЕМ
ной считается информация, сила и форма представления которой
достаточны для восприятия и взаимодействия элементов системы.
При этом сигнал определяется как энергия, преобразованная в фор¬
му, которая может восприниматься некоторым элементом системы
и может вызвать его переход в новое состояние. Таким образом, ин¬
формация рассматривается как сведения о событиях, происходя¬
щих внутри системы и во внешней среде. Информация в системе
полностью определяется состоянием ее элементов и связей. Следу¬
ет заметить, что в качестве материальных носителей могут высту¬
пать разные сущности, что позволяет абстрагироваться от природы
источника информации. Из этого следует, что информацию мож¬
но рассматривать как свойство материи иметь разнообразие. Ин¬
формация существует независимо от людей, и она является атри¬
бутом материи.
При работе с информацией можно выделить три подхода:
1) синтаксический, направленный на структурный анализ ин¬
формации;
2) семантический, направленный на анализ содержания ин¬
формации;
3) прагматический, направленный на оценку полезности (цен¬
ности) информации.
Эти подходы рассматриваются в рамках семиотики (науки
о знаковых выражениях).
Информацию чаще всего используют в целях управления. При
этом информацию можно характеризовать такими параметрами,
как объем, уровень, достоверность, ценность, насыщенность и сте¬
пень открытости.
Объем информации можно оценивать с двух точек зрения:
с точки зрения объема символьной информации и с точки зрения
объема воспринимаемой информации.
Объем воспринимаемой информации зависит от таких факторов,
как объем символьной информации, формы представления инфор¬
мации, сложности информации, времени, отведенного на обработ¬
ку информации, а также от индивидуальных особенностей челове¬
ка, работающего с информацией.
-34-
Данные, информация, знания
Уровень воспринимаемой информации может колебаться от из¬
быточного до состояния информационного голода. Уровень инфор¬
мации может быть абсолютным (100 %), доверительным (80-90 %)
и негативным (< 70 %).
Уровень достоверности информации можно определить как от¬
ношение набора истиной информации к общему объему информа¬
ции. Уровень достоверности может быть абсолютным, доверитель¬
ным или негативным.
Ценность (полезность) информации определяется с помощью
экспертной оценки и может колебаться в пределах от сверхвысо¬
кой до нулевой.
Насыщенность информацией можно определить как соотноше¬
ние ценной и фоновой информации.
При оценке количества информации применяется вероят¬
ностно-статистический метод, а классическая теория информации
является ветвью теории вероятностей и математической статисти¬
ки. Чаще всего при этом используется мера количества информа¬
ции, предложенная К. Шеноном и определяемая как разность ло¬
гарифмов условной и безусловной вероятности событий. Главное
свойство информации при данном подходе состоит в том, что она
снимает, уничтожает неопределенность.
Иерархический подход. Данный подход рассматривает инфор¬
мацию как иерархическую структуру и представляет ее в виде че¬
тырехуровневой пирамиды (рис. 1.4).
На нижнем уровне располагаются данные (Data), на следую¬
щем уровне находится информация (Information), на третьем уров¬
не находятся знания (Knowledge), а на вершине пирамиды находится
мудрость (Wisdom). Структуру по рис. 1.4 обычно называют DIKW-
пирамидой, или ДИЗМ-пирамидой. Основная идея ДИЗМ-пира-
миды состоит в том, что информация определяется в терминах дан¬
ных, знания — в терминах информации, а мудрость — в терминах
знаний [13]. Для разных классов систем в понятия «данные», «ин¬
формация», «знания» и «мудрость» может вкладываться разный
смысл, но идея остается неизменной.
Применительно к ДИЗМ-пирамиде данные могут определяться
как сигналы, символы или факты. Данные можно рассматривать как
продукт наблюдения. Применительно к данным иногда используют
-35-
1. КАКОВЫ ОСНОВНЫЕ ПОЛОЖЕНИЯ ТЕОРИИ СИСТЕМ
термин «сырые данные» (raw data). В данном случае термин «дан¬
ные» практически совпадает с термином «информация», использу¬
емым в теории информации.
В контексте ДИЗМ-пирамиды информацию можно определить
как метаданные, т. е. как некоторое полезное знание о данных. Ин¬
формацию можно рассматривать как результат обработки данных,
выполненный с определенной целью.
Одним из наиболее удачных определений информации для це¬
лей настоящего издания следует считать определение информации,
приведенное в [13], в соответствии с которым информация при¬
менительно к ДИЗМ-пирамиде определяется как «организованные
или структурированные данные, которые были обработаны таким
образом, что информация теперь имеет отношение к определен¬
ной цели или контексту, и поэтому является значимой, ценной, по¬
лезной и актуальной».
Понятие «знание» используется во многих областях, поэтому
дать общее определение этому понятию достаточно сложно. В [14]
даются два определения знания.
Знание в широком смысле — определяется как «совокупность
понятий, теоретических построений и представлений». В узком
смысле знание определяется как «признак определенного объема
информации, определяющий ее статус и отделяющий от всей про¬
чей информации по критерию способности к решению поставлен¬
ной задачи». Другие определения знаний можно найти в [15].
Применительно к ДИЗМ-пирамиде знание можно определить
как метаинформацию, т. е. как результат обработки информации,
выполненный с определенной целью, представленный в форме, от¬
личной от формы представления исходной информации.
Знания могут быть разными, в частности это может быть про¬
цедурное знание, описательное знание.
Процедурное знание можно рассматривать как знание о спосо¬
бе достижения некоторой цели. Этот тип знаний является своего
рода «ноу-хау». Описательное знание предполагает множество ут¬
верждений о свойствах элементов системы или отношений между
элементами системы. Для ИС, ориентированных на работу со зна¬
ниями, первостепенный интерес представляют способы машинного
представления знаний и способы получения знаний, которые пред¬
-36-
В чем отличие информационных и информационно-ориентированных систем
ставляются в форме, пригодной для машинной обработки. Более
подробнее этот вопрос будет рассмотрен ниже, подробную инфор¬
мацию о способах представления данных можно найти в [16].
Понятие мудрости применительно к ДИЗМ-пирамиде можно
интерпретировать как знания о знаниях, т. е. как получать знания,
как представлять знания, как обрабатывать и отображать знания.
Можно утверждать, что ДИЗМ-пирамида во многом определя¬
ет идеологию построения современных ИС.
В ЧЕМ ОТЛИЧИЕ ИНФОРМАЦИОННЫХ
И ИНФОРМАЦИОННО-ОРИЕНТИРОВАННЫХ СИСТЕМ
Определения. Понятие информационной системы является
многоаспектным. Существует достаточно много разных определе¬
ний этого понятия, которые отражают разные точки зрения разных
заинтересованных сторон на ИС. Можно выделить, по крайней ме¬
ре, три разные точки зрения на ИС: ИС рассматривается как под¬
класс класса систем, ИС рассматривается как закрытая система и ИС
рассматривается как открытая система.
Как указывалось ранее, на входы системы могут поступать
вещество, энергия, информация. В этом контексте ИС можно
определить как систему, на вход которой поступает информа¬
ция. Очевидно, что на входы системы может поступать не только
информация, но также вещество, энергия. В этом случае можно
говорить об ИОС. Данное определение отражает в первую оче¬
редь точку зрения системных аналитиков, использующих мето¬
ды системного анализа.
Второй подход — это точка зрения IT-специалистов на ИОС.
Это наиболее распространенная точка зрения, в соответствии с ко¬
торой понятие ИС определяется как «совокупность технического,
программного и организационного обеспечения, а также персона¬
ла, предназначенная для того, чтобы своевременно обеспечивать
надлежащих людей надлежащей информацией» [17].
Похожим образом понятие информационной системы (ИС)
определяет Федеральный закон от 27 июля 2006 г. № 149-ФЗ «Об ин¬
формации, информационных технологиях и о защите информа¬
-37-
1. КАКОВЫ ОСНОВНЫЕ ПОЛОЖЕНИЯ ТЕОРИИ СИСТЕМ
ции»: «Информационная система — совокупность содержащейся
в базах данных информации и обеспечивающих ее обработку ин¬
формационных технологий и технических средств» [18].
Одно из наиболее широких определений ИС дал М.Р. Когалов-
ский: «Информационной системой называется комплекс, вклю¬
чающий вычислительное и коммуникационное оборудование,
программное обеспечение, лингвистические средства и информа¬
ционные ресурсы, а также системный персонал и обеспечивающий
поддержку динамической информационной модели некоторой ча¬
сти реального мира для удовлетворения информационных потреб¬
ностей пользователей» [19].
Стандарт ISO/IEC 2382-1 дает следующее определение: «Ин¬
формационная система — система обработки информации, ра¬
ботающая совместно с организационными ресурсами, такими как
люди, технические средства и финансовые ресурсы, которые обес¬
печивают и распределяют информацию» [20].
Российский ГОСТ РВ 51987-2002 определяет информаци¬
онную систему как «автоматизированную систему, результатом
функционирования которой является представление выходной ин¬
формации для последующего использования».
В еще более узком смысле информационной системой на¬
зывают только подмножество компонентов ИС в широком смыс¬
ле, включающее базы данных, СУБД и специализированные
прикладные программы. ИС в узком смысле рассматривают как
программно-аппаратную систему, предназначенную для автома¬
тизации целенаправленной деятельности конечных пользовате¬
лей, обеспечивающую в соответствии с заложенной в нее логикой
обработки возможность получения, модификации и хранения
информации.
С точки зрения конечного пользователя ИС, в качестве кото¬
рого выступает, в частности, бизнес, в соответствии с [18] ИС опре¬
деляется как «формальные, социально-технические, организаци¬
онные системы, предназначенные для сбора, обработки, хранения
и распространения информации». В рамках данного определения
выделяются четыре компонента ИС: ИТ, люди, процессы и струк¬
тура, которые группируются в две подсистемы: техническую под¬
систему и социальную подсистему (рис. 1.5).
-38-
В чем отличие информационных и информационно-ориентированных систем
Социальные системы Технические системы
Струю
j
ура
N
Техн<
/ 1
элогия
i
Лю,)
ди
\ j
Про
Г
щессы
Рис. 1.5. Техническая и социальная подсистемы
Техническая подсистема, включающая ИТ и процессы, явля¬
ется той частью информационной системы, которая не включа¬
ет человеческие элементы. Социальная подсистема, включающая
людей и людей по отношению друг к другу (т. е. структуру), пред¬
ставляет человеческий элемент ИС.
В самом деле перечисленные выше три группы определений от¬
вечают на разные вопросы. Первая группа определений отвечает на
вопрос «Как ИС соотносятся с другими системами?». Вторая группа
определений отвечает на вопрос «Как строятся ИС?», а третья груп¬
па определений отвечает на вопрос «Для чего строятся ИС?».
Классификация ИС. ИС представляют собой очень большой
класс систем, и дать его детальную классификацию вряд ли возмож¬
но. Схема классификации на верхнем уровне показана на рис. 1.6.
ИС предлагается классифицировать по следующим независи¬
мым признакам: тип ИС, масштаб, домен задач, домен решений,
используемые парадигмы, способность к реконфигурации и адап¬
тации, уровень интеллекта. (Следует заметить, что это далеко не
полная классификация.)
Можно выделить два основных типа ИС: чисто информацион¬
ные системы и информационно-ориентированные системы. Чис¬
то информационные системы включают в себя элементы, ориен¬
-39-
1. КАКОВЫ ОСНОВНЫЕ ПОЛОЖЕНИЯ ТЕОРИИ СИСТЕМ
тированные на решение задач, связанных со сбором, обработкой
и хранением информации. Информационно-ориентированные сис¬
темы наряду с подсистемами, предназначенными для работы с ин¬
формацией, могут включать элементы любой физической природы,
в том числе природные объекты и людей. К этой группе можно от¬
нести КФС, социотехнические системы и др. В таких системах обыч¬
но присутствует мощная программная компонента, и их иногда на¬
зывают Software Intensive Systems (SWIS) [21].
Рис. 1.6. Классификация ИС
-40-
В чем отличие информационных и информационно-ориентированных систем
Домен задач можно представить как множество возможных
сфер применения и множество типовых задач обработки данных.
В качестве примеров областей применения ИС можно назвать та¬
кие области, как системы, управляемые событиями, системы, ори¬
ентированные на обработку больших данных, и т. п.
По принадлежности к предметной области обычно ИС ориен¬
тированы на использование и удовлетворение информационных
потребностей в рамках конкретной предметной области. В насто¬
ящее время ИС используются практически повсеместно, поэто¬
му перечислить все области, в которых используются ИС, просто
невозможно. В качестве примера можно указать следующие об¬
ласти, в которых ИС активно используются: системы управления
организацией, системы управления производством, телекомму¬
никационные системы, геоинформационные системы, банковские
ИС; встроенные системы управления сложными объектами, таки¬
ми как самолеты и корабли, медицинская информационная сис¬
тема и многие другие.
С точки зрения характера обработки можно выделить такие
типы систем, как системы, ориентированные на решение крупно¬
масштабных задач преимущественно вычислительного характера,
информационно-справочные и информационно-поисковые ИС, ав¬
томатизированные системы управления и системы поддержки при¬
нятия решений, коммуникационные системы, ИС, ориентирован¬
ные на предоставление услуг (сервисов), др.
С точки зрения реализации (домен решений) ИС можно клас¬
сифицировать по следующим признакам: архитектура, использу¬
емые структурные решения, принцип управления и используемая
платформа.
Множество архитектурных решений можно классифицировать
в соответствии с используемыми архитектурными стилями. Мож¬
но выделить следующие основные группы архитектурных стилей:
потоки данных; вызов с возвратом; независимые компоненты; цен¬
трализованные данные; виртуальные машины. Более подробно ар¬
хитектурные стили будут рассмотрены ниже. С точки зрения ис¬
пользуемых структурных решений на верхнем уровне ИС можно
разделить на монолитные и распределенные. С точки зрения прин¬
-41-
1. КАКОВЫ ОСНОВНЫЕ ПОЛОЖЕНИЯ ТЕОРИИ СИСТЕМ
ципов управления ИС можно разделить на системы с централизо¬
ванным и децентрализованным управлением. Для построения сов¬
ременных ИС чаще всего используются такие платформы, как IoT,
IIoT, облачные вычисления, туманные вычисления.
ИС могут строиться с использованием одной или нескольких
парадигм. К числу наиболее часто используемых архитектурных па¬
радигм можно отнести такие парадигмы, как КФС, IoT, IIoT, облач¬
ные вычисления, туманные вычисления, граничные вычисления,
AmI, нейрокомпьютинг, онтологический инжиниринг.
Отличительной особенность современных ИС, как и всяких
сложных систем, является способность к адаптации. При этом
можно выделить следующие варианты: способность к адаптации
отсутствует, система способна адаптироваться к изменениям во
внешнем мире и система способна к самоадаптации.
С точки зрения уровня интеллекта ИС можно разделить на си¬
стемы, использующие механизмы работы со знанием (извлечение
знаний, обработка знаний, представление знаний), системы окру¬
жающего интеллекта (AmI) [22], способные адаптироваться к по¬
требностям пользователей, и системы, способные к обучению в ши¬
роком смысле.
Эволюция архитектурных парадигм. За последние 40-50 лет
успехи в области технологии привели к значительным изменени¬
ям в том, как мы должны разрабатывать программные приложе¬
ния (рис. 1.7).
До и в течение 1980-х гг. использовались в основном монолит¬
ные архитектуры. Приложение, как правило, выполняется на одной
машине и использует всю системную программную среду (диспет¬
чер экрана, монитор транзакций, база данных, операционная сис¬
тема), поставляемую производителем машины. Само программное
приложение, как правило, рассматривалось как единое монолитное
целое. Архитектура программного обеспечения в значительной сте¬
пени диктовалась производителем компьютера, а не разработчика¬
ми программного обеспечения для конечных пользователей. Затем
постепенно перешли в эпоху клиент-серверных систем, и приложе¬
ния начали разделять на два или три физических уровня, что бы¬
-42-
В чем отличие информационных и информационно-ориентированных систем
ло обусловлено широкой доступностью настольных персональных
компьютеров (ПК) и серверных компьютеров на базе Unix. Архи¬
тектура программного обеспечения была не очень сложной, но раз¬
работчикам программного обеспечения (ПО) приходилось самим
принимать решение: где находится бизнес-логика. Она могла рас¬
полагаться в пользовательском интерфейсе, в процедурах, храни¬
мых в базе данных.
2020
Распределенные
монолитные
приложения 2000
Облачные
системы
1980
Йт 2010
О О
Интеллектуальные
экосистемы
Интернет¬
приложения
Монолитные
приложения
Рис. 1.7. Эволюция архитектурных парадигм
Позже, в 2000-х гг., архитектура ПО действительно достигла со¬
вершеннолетия, поскольку Интернет расширился, предлагая новые
возможности, что позволяло пользователям работать с приложе¬
ниями практически из-за пределов своей организации, потенци¬
ально из любой точки мира. При этом требования к безопасности,
производительности, масштабируемости и доступности вышли на
новый уровень.
В последние годы Интернет стал частью нашей повседневной
жизни, а облачные вычисления, сервисы, подключенные к Интерне¬
ту, превратились в часть создаваемых ИС. В свою очередь, это рас¬
ширение Интернета вызвало потребность в быстрых изменениях
и безупречных качественных характеристиках, что привело к та¬
-43-
1. КАКОВЫ ОСНОВНЫЕ ПОЛОЖЕНИЯ ТЕОРИИ СИСТЕМ
ким тенденциям, как использование общедоступных облачных вы¬
числений, микросервисов и непрерывной доставки. В будущем, если
текущие тенденции сохранятся, то создаваемые ИС будут все более
распределенными, гибкими и взаимосвязанными, образуя интел¬
лектуальные экосистемы.
КАКОВЫ ОСОБЕННОСТИ
КИБЕРФИЗИЧЕСКИХ СИСТЕМ
Термин «киберфизические системы» появился в начале теку¬
щего века, и его появление было вызвано ростом сложности тех¬
нических систем и повышением в них доли информационного
компонента. КФС — это комплексное понятие. Однозначного и об¬
щепринятого определения на сегодняшний день оно не получило,
так как эти системы находятся на пересечении сразу нескольких
сфер и в зависимости от реализации способны затрагивать самые
разные аспекты нашей жизни.
Их главной общей характеристикой является очень плотное
взаимодействие между вычислительными процессами и процес¬
сами физическими, поэтому можно сказать, что КФС представля¬
ет собой комплексную систему, состоящую из информационных
и физических элементов, которая постоянно получает данные из
окружающей среды и использует их для дальнейшей оптимиза¬
ции процессов управления.
Другими словами, КФС можно определить как информацион¬
но-ориентированную систему, состоящую из тесно связанных меж¬
ду собой программных (виртуальных) и физических компонентов.
Принципиально всегда можно выделить программные и физиче¬
ские компоненты, но такое разделение может привести к тому, что
окажется трудно понять общие принципы функционирования всей
системы. В этом смысле КФС — это некоторый взгляд на информа¬
ционно-ориентированную систему или подход к проектированию.
-44-
Каковы особенности киберфизических систем
КФС включает в себя трансдисциплинарные подходы, объеди¬
няющие теории кибернетики, мехатроники, проектирования и на¬
уки о процессах. КФС во многом аналогичен интернету вещей (IoT),
использующему ту же базовую архитектуру, но КФС можно считать
более общим понятием по сравнению с IoT, а IoT можно считать од¬
ним из возможных реализаций КФС.
КФС находят широкое применение при реализации таких кон¬
цепций, как умный город, умное электроснабжение, умное произ¬
водство, умный дом, умный транспорт, умное здравоохранение, ум¬
ное общество, умный офис, умная лаборатория и т. п. Ниже кратко
рассмотрены некоторые примеры.
Умное здравоохранение. Интеллектуальные приложения
для здравоохранения привлекли большое внимание во многих
секторах здравоохранения. Наличие интеллектуальных биоме¬
дицинских устройств и технологий связи с низким энергопо¬
треблением позволило получить доступ к медицинской инфор¬
мации пациента, даже если он находится в удаленном районе.
В настоящее время благодаря мобильной системе телемедици¬
ны пациенты продолжают свою обычную деятельность, получая
медицинские сервисы. Технология интернета вещей позволяет
поддерживать различные приложения электронного здравоох¬
ранения, такие как носимое устройство и доступ к его данным
(автоматическая система диагностики), удаленный монито¬
ринг состояния здоровья пожилых пациентов и немедленное
реагирование в чрезвычайных ситуациях. Интеллектуальные
системы здравоохранения в больницах собирают информа¬
цию с измерительных устройств ЭКГ, измерительных устройств
ЭЭГ, рентгеновских аппаратов и хранят ее в своей базе данных,
к этой информации о здоровье пациентов могут получить до¬
ступ эксперты здравоохранения и на основе истории болезни
от медицинских экспертов интеллектуальных систем здраво¬
охранения продолжить лечение. Благодаря интеллектуальным
системам здравоохранения обеспечиваются получение точной
медицинской информации о пациентах и предоставление им
-45-
1. КАКОВЫ ОСНОВНЫЕ ПОЛОЖЕНИЯ ТЕОРИИ СИСТЕМ
эффективных медицинских услуг. Приложение электронного
здравоохранения является одним из важнейших приложений
для мониторинга. Постоянный мониторинг пациентов с хрони¬
ческими заболеваниями и отчетность перед медицинским ра¬
ботником — основная задача, которая практикуется в приложе¬
ниях электронного здравоохранения.
Умное электроснабже¬
ние. Электросеть обеспечива¬
ет электроэнергией различные
инфраструктуры (офисы, дома,
промышленные предприятия,
огромные квартиры и т. д.). Рас¬
пределение электроэнергии от
электростанций потребителям
более разумным способом (эф¬
фективным способом) называ¬
ется интеллектуальной сетью.
Потребление электроэнер¬
гии каждым потребителем изме¬
ряется счетчиками электроэнер¬
гии, таким образом, внедрение
интеллектуальных счетчиков
в системах производства элек¬
троэнергии, а также в системах
распределения электроэнергии
выполняет как зондирование,
так и приведение в действие для
улучшения работы сети.
Интеллектуальные устрой¬
ства собирают информацию, свя¬
занную с электричеством, между
производством электроэнергии
и распределительными система¬
ми и направляют эту информацию
в аналитические инструменты
Умное производство. Ки¬
берфизические идеи активно
внедряются в производствен¬
ные системы в таких отраслях,
как машиностроение, автомо¬
билестроение, металлургия, су¬
достроение.
В производственной сре¬
де КФС включат в себя интел¬
лектуальные машины, системы
хранения данных и производ¬
ственные мощности, способные
автономно обмениваться ин¬
формацией, инициировать дей¬
ствия и независимо контролиро¬
вать друг друга. Эта концепция
способствует повышению эф¬
фективности производственных
процессов, участвующих во всей
производственно-сбытовой це¬
почке, включая разработку, ис¬
пользование материалов, исхо¬
дящую логистику и управление
жизненным циклом. Устройства
такого интеллектуального заво¬
да являются уникально иденти¬
фицируемыми, могут находить¬
ся в любом месте, знать свою
собственную историю и текущее
-46-
Каковы особенности киберфизических систем
для сбалансированного исполь¬
зования электроэнергии, а также
помогают в выявлении проблем
в системах распределения элек¬
троэнергии и потерь электроэ¬
нергии в системах распределе¬
ния электроэнергии. Для такого
сетевого сценария распределе¬
ние электроэнергии должно под¬
держиваться надежной сетевой
инфраструктурой.
состояние, возможности кон¬
фигурации и производствен¬
ные условия, а также обмени¬
ваться данными друг с другом
даже без проводов. Данная кон¬
цепция также предполагает воз¬
можность внесения изменений
на производстве «в последнюю
минуту» и гибкие ответы на пре¬
рывания в работе и сбои со сто¬
роны поставщиков.
Умный город. Умный город — это взаимосвязанная система
коммуникативных и информационных технологий с IoT, благо¬
даря которой упрощается управление внутренними бизнес-про¬
цессами города и улучшается уровень жизни населения. Умный
город должен решать две важные задачи: сбор и передача дан¬
ных представителям управления и налаживание обратной свя¬
зи между администрацией и горожанами. Умный город должен
обеспечить повышение уровня жизни граждан и уменьшение
издержек на реализацию бизнес-процессов благодаря автома¬
тизации деятельности, не требующей применения аналитиче¬
ских навыков.
Умный или цифровые города постоянно совершенствуют свои
функции за счет непрерывной обработки и обновления сведений.
Интегрированные датчики собирают информацию, полученную от
жителей города и с помощью электронных устройств. После ана¬
лиза собранных данных происходит оптимизация, решающая про¬
блемы неэффективности.
Термин «умный город» был введен относительно недавно,
и однозначного толкования этого понятия до сих пор нет. Однако
эксперты сошлись в том, что основными компонентами умного
города должны стать:
- видеонаблюдение и фотофиксация;
- интеллектуальные транспортные системы;
- единая система экстренного вызова;
-47-
1. КАКОВЫ ОСНОВНЫЕ ПОЛОЖЕНИЯ ТЕОРИИ СИСТЕМ
- единая диспетчерская служба и ситуационные центры;
- пятое поколение мобильной связи (5G).
Эти инструменты сбора и анализа информации используют¬
ся для улучшения функционирования транспортной развязки, ме¬
дицины, промышленности и других сфер, формирующих модель
цифрового города.
Можно выделить следующие основные направления развития
умного города.
Умная экономика. Формирование благоприятной среды для
инновационной деятельности, в том числе для развития ин¬
формационно-коммуникационных технологий.
Умное управление. Отлаженное функционирование системы
коммуникации между жителями города и представителями испол¬
нительной власти, информационная открытость городской адми¬
нистрации.
Активность граждан в управлении городом. Актуальность доку¬
ментации стратегического планирования, высокая посещаемость
официальных сайтов городской администрации.
Умные финансы. Доступность банкоматов. Прозрачность госу¬
дарственных тендеров. Система оплаты проезда по безналично¬
му расчету.
Умная инфраструктура. Отлаженная работа интернет-сер¬
висов для вызова и оплаты такси. Возможность мониторить до¬
рожный трафик в режиме онлайн. Наличие сети заправочных
станций для электромобилей. Сервис по предоставлению услуг
каршеринга.
Умные жители. Активность и количество пользователей Все¬
мирной сети. Применение электронных карт учащихся. Доступ¬
ность данных о рынке труда.
Умная среда. Развитая система мониторинга экобезопасности.
Участие горожан и администрации в устранении последствий не¬
санкционированного выброса мусора.
Умные технологии. Наличие бесплатных точек Wi-Fi, в т. ч.
в общественном транспорте. Функционирование сетей мобиль¬
ного широкополосного доступа.
-48-
Каковы особенности киберфизических систем
Умный дом. Умный дом по¬
зволяет автоматизировать и уп¬
ростить управление различ¬
ными встроенными системами
и другим оборудованием квар¬
тиры или дома. Данная концеп¬
ция включает в себя управление
освещением — включение света
по сигналу датчика движения,
изменение варианта подсвет¬
ки, дистанционное управление
светом через смартфон; обес¬
печение безопасности — полу¬
чение СМС и уведомлений при
срабатывании охранной систе¬
мы; обеспечение климат-кон¬
троля — система поддержива¬
ет температуру помещения на
заданном уровне и позволя¬
ет изменять ее дистанционно,
а также устанавливать режим
максимальной экономии энер¬
гопотребления во время отсут¬
ствия хозяев. Также при нали¬
чии в доме/квартире «умной»
техники с модулем Wi-Fi воз¬
можны дистанционное управ¬
ление этой техникой и плани¬
рование действий.
Мониторинг окружающей
среды. Приложения для мони¬
торинга окружающей среды со¬
бирают информацию, связанную
с окружающей средой (темпе¬
ратура, влажность, дым, пожар
и т. д.), и передают ее на базо¬
вую станцию. Мониторинг окру¬
жающей среды включает мони¬
торинг оползней, мониторинг
лесных пожаров, мониторинг
наводнений, мониторинг темпе¬
ратуры, мониторинг снегопадов,
мониторинг орошения, монито¬
ринг цунами, мониторинг ди¬
кой природы, мониторинг про¬
мышленного дыма, мониторинг
пешеходов и т. д. Все эти прило¬
жения расположены в удаленной
зоне, поэтому в них используют¬
ся устройства с батарейным пи¬
танием. Когда батарея разряжа¬
ется, необходимо начать замену
батареи, частая замена батареи
в таких суровых условиях невоз¬
можна.
Из приведенного выше краткого описания различных КФС вид¬
но, что КФС представляют собой очень широкий класс систем, для
построения которых могут использоваться разные архитектурные
решения, разные технологии и разные платформы.
Фактически единственно, что объединяет эти системы, это
то, что они построены из элементов разной физической приро-
-49-
1. КАКОВЫ ОСНОВНЫЕ ПОЛОЖЕНИЯ ТЕОРИИ СИСТЕМ
ды и в них присутствует значительный по объему распределен¬
ный информационный компонент, который позволяет этим си¬
стемам реализовывать сложные функции, поэтому КФС могут
быть отнесены к классу интеллектуальных систем. При их реа¬
лизации активно используются такие парадигмы и платформы,
как: интернет вещей, промышленный интернет вещей, окру¬
жающий интеллект, Industry 4.0, которые будут рассмотрены
ниже [23, 24, 25].
-50-
2
ЧТО СОБОЙ ПРЕДСТАВЛЯЕТ
АРХИТЕКТУРА ИОС
О ПОНЯТИИ АРХИТЕКТУРЫ
Термин архитектура происходит от лат. architectura и озна¬
чает искусство строительства зданий и других сооружений, кото¬
рые образуют материально организованную среду (экосистему),
необходимую для жизни и деятельности людей, соответствуют тех¬
ническим возможностям и эстетическим воззрениям людей. По
мере развития техники и технологий этот термин стал использо¬
ваться применительно к антропогенным системам для определе¬
ния принципов построения чего-либо сложного, без указания де¬
талей реализации.
Если речь идет об архитектуре ИС, то прежде всего возникает
очевидный вопрос: зачем нужно само понятие «архитектура» и ка¬
кую пользу можно получить из его существования? Применительно
к ИС и программным системам ответ на этот вопрос можно cфор-
мулировать следующим образом.
Программную архитектуру можно определить как модель,
описывающую ИС, которая обычно создается на этапе концептуаль¬
ного (архитектурного) проектирования, при этом создаваемой сис¬
теме ставится в соответствие архитектурное описание (АО), кото¬
рое может быть использовано при решении по крайней мере трех
задач проектирования ИС:
1. АО, созданное в соответствии с определенными правилами,
может быть использовано в качестве языка, на котором общают¬
2. что собой представляет архитектура иос
ся между собой заинтересованные стороны (архитектор, аналитик,
программист, владелец, покупатель, пользователь).
2. АО можно использоваться для создания кода приложения.
Подобный подход известен как проектирование с помощью мо¬
делей.
3. АО может быть использовано в процессе проектирования се¬
мейств или линеек продуктов, которые могут использовать одинако¬
вые архитектурные решения, что создает предпосылки для уменьше¬
ния стоимости разработки и позволяет снизить риски [26, 27].
Определение понятий архитектуры ИС и АО ИС формировалось
на протяжении нескольких десятков лет.
На сайте SEI (Software Engineering Institute) имелся даже отдельный
раздел, где было собрано более ста определений этих понятий [28].
В результате длительных обсуждений, которые проходили
еще в конце прошлого века, появились два стандарта — [29] и [30].
Первый назывался «Рекомендации по архитектурному описанию
программных систем (IEEE Recommended Practice for Architectural
Description of Software-Intensive Systems) и был утвержден в 2000 г.,
а второй был утвержден 2011 г. и называется «Системная и про¬
граммная инженерия — архитектурное описание». В этом стандар¬
те понятия системной и программной архитектуры определяются
как «принципы организации системы, в терминах основных компонен¬
тов, их взаимосвязей, окружения и принципов проектирования и эво¬
люции, а архитектурное описание как набор артефактов, состав¬
ляющих описание архитектуры». Появление последнего стандарта
положило конец дискуссиям о том, что есть системная и программ¬
ная архитектура. Однако использовать данное определение при¬
менительно к корпоративным ИС (КИС) оказалось затруднитель¬
но, поскольку КИС являются многоуровневыми ИС и имеют очень
длительный жизненный цикл, и на протяжении всего жизненного
цикла они совершенствуются и развиваются.
Применительно к КИС обычно используют такие понятия,
как корпоративная архитектура, корпоративная информацион¬
ная система.
Корпоративная архитектура (Enterprise architecture (EA))
определяется как методология, ориентированная на формирование
проактивной холлистической реакции организации на внешние
-52-
О понятии архитектуры
деструктивные воздействия посредством идентификации, анализа
и формирования реакции с целью перехода в желаемое состояние
бизнеса и результатов его функционирования. Предполагается, что
ЕА должна представлять лицам, принимающим решения, информа¬
цию для принятия решений и формирования политик, обеспечива¬
ющих достижение максимальной эффективности функционирова¬
ния организации [31].
Корпоративная информационная система (КИС) (Enterprise
Information System (EIS)) — любая ИС, предназначенная для совер¬
шенствования реализуемых в организации бизнес-процессов по¬
средством их интеграции. КИС может работать на любых уровнях.
Термин «корпоративная» (enterprise) в данном случае используется
в самом широком смысле. Это может быть транснациональная кор¬
порация, небольшая коммерческая фирма, образовательное учре¬
ждение, больница, некоммерческая организация и т. д. При этом
речь может идти не только об организации в классическом пони¬
мании, но и о виртуальной организации.
Корпоративная информационная архитектура (КИА) (Enter¬
prise information architecture (EIA))— это часть корпоративного архи¬
тектурного процесса. КИА предназначена для описания текущего
состояния и прогнозирования изменения состояния с целью повы¬
шения качества функционирования системы. КИА оперирует таки¬
ми понятиями, как требования, принципы, модели [32].
Приведенные определения фактически отражают только требо¬
вания, но не дают никакой информации о принципах организации
и функционирования КИС. Эта информация содержится в докумен¬
те, который называется Корпоративный архитектурный фреймворк
(Enterprise Architecture framework) [32]. В данном случае под терми¬
ном «фреймворк» понимается эталонная реализация. Эта мо¬
дель восходит к предложенной еще в 1988 г. модели NIST Enterprise
Architecture Model (Национальный институт стандартов и техноло¬
гий — одно из агентств Министерства торговли США), в соответст¬
вии с которой модель описывается как пятиуровневая, в которой
определяются следующие уровни (рис. 2.1):
1) бизнес-архитектура (Business architecture);
2) ИТ-архитектура (Information Technology Architecture), или ин¬
формационная архитектура (Information Architecture);
-53-
2. что собой представляет архитектура иос
3) архитектура данных (Data Architecture);
4) архитектура приложения (Application Architecture), или про¬
граммная архитектура (Software Architecture);
5) техническая архитектура (Hardware Architecture). Совокуп¬
ность данных архитектур и является архитектурой ИС.
Рис. 2.1. Архитектурные уровни
Бизнес-архитектура, или архитектура уровня бизнес-процес¬
сов, определяет бизнес-стратегии, управление, организацию, клю¬
чевые бизнес-процессы в масштабе предприятия, причем не все
бизнес-процессы реализуются средствами ИТ-технологий. Бизнес¬
архитектура отображается на ИТ-архитектуру.
ИТ-архитектура рассматривается в трех аспектах:
- обеспечивает достижение бизнес-целей посредством исполь¬
зования программной инфраструктуры, ориентированной на реа¬
лизацию наиболее важных бизнес-приложений;
- среда, обеспечивающая реализацию бизнес-приложений;
- совокупность программных и аппаратных средств, составляю¬
щая информационную систему организации и включающая, в част¬
ности, базы данных и промежуточное программное обеспечение.
Архитектура данных организации включает логические и фи¬
зические хранилища данных и средства управления данными. Ар¬
хитектура данных должна быть поддержана ИТ-архитектурой.
-54-
Каково значение архитектуры
В современных ИТ-системах, ориентированных на работу со зна¬
ниями, иногда выделяют отдельный тип архитектуры — архитек¬
туру знаний (Knowledge Architecture).
Программная архитектура отображает совокупность про¬
граммных приложений. Программное приложение — это компью¬
терная программа, ориентированная на решение задач конечного
пользователя. Архитектура приложений — это описание отдель¬
ного приложения, работающего в составе ИТ-системы, включая его
программные интерфейсы. Архитектура приложения базируется
на ИТ-архитектуре и использует сервисы, предоставляемые ИТ-
архитектурой.
Техническая архитектура характеризует аппаратные средст¬
ва, системное ПО и включает такие элементы, как ОС, процессор,
память, жесткие диски, периферийные устройства, элементы, ис¬
пользуемые для их соединения, а также сетевые средства.
Часто нельзя провести четкую границу между ИТ-архитек-
турой и архитектурой отдельного приложения. В частности,
в случае, когда некоторую функцию требуется реализовать в не¬
скольких приложений, она может быть перенесена на уровень
ИТ-архитектуры. Обычно приложения интегрируются средства¬
ми ИТ-архитектуры.
КАКОВО ЗНАЧЕНИЕ АРХИТЕКТУРЫ
Как указывалось выше, каждая ИС обладает архитектурой неза¬
висимо от наличия архитектурного описания. Однако наличие ар¬
хитектурного описания в форме документа и моделей дает ряд пре¬
имуществ, хотя и требует дополнительных затрат.
Наличие архитектурного описания создаваемой ИС позволяет
упростить решение, по крайней мере, четырех задач:
1) упрощает общение между заинтересованными сторонами;
2) позволяет оценивать характеристики системы на ранних
этапах проектирования;
3) полезно с точки зрения повторного использования решений,
в частности повторного использования кода;
4) дает возможность автоматической генерации кода.
-55-
2. что собой представляет архитектура иос
Создание в короткие сроки крупных систем, состоящих из эле¬
ментов разной физической природы, требует создания крупных ко¬
манд разработчиков, в которые включаются специалисты разных
профилей, в частности те, кто не являются специалистами в обла¬
сти ИС. Это могут быть специалисты в соответствующих предмет¬
ных областях (электромеханики, биологи, врачи, социологи, финан¬
систы т. п.). Грамотно составленное архитектурное описание может
оказаться крайне полезным на всех этапах жизненного цикла сис¬
тем, начиная от этапа формирования требований и заканчивая эта¬
пом модернизации ИС. В этом контексте можно говорить о том, что
архитектура является языком общения заинтересованных сторон.
Архитектурное описание создается на начальных этапах про¬
ектирования ИС, когда закладываются общие принципы построе¬
ния ИС, такие как выбор концепции построения системы, выбор
платформы, принимаются ключевые решения, связанные с обеспе¬
чением таких архитектурно значимых характеристик, как произво¬
дительность, надежность, безопасность.
Практически всегда архитектурные решения принимают¬
ся в условиях неопределенности. Ошибочные решения, приня¬
тые на этапе архитектурного (концептуального) проектирования,
оказывается очень сложно, а иногда и невозможно исправить. Та¬
ким образом, оказывается, что наиболее ответственные решения
принимаются в условиях неопределенности.
Наличие явного архитектурного описания позволяет до опре¬
деленной степени повысить обоснованность принятия принципи¬
альных архитектурных решений. В частности, это может быть до¬
стигнуто за счет привлечения сторонних экспертов и специалистов
в области моделирования, которым может быть предоставлено ар¬
хитектурное описание создаваемой ИС. Архитектурное описание,
как будет показано ниже, содержит обоснование выбранных архи¬
тектурных решений и описание моделей, что также облегчает про¬
цесс принятия правильных решений на этапе архитектурного про¬
ектирования.
Современные системы автоматизированного проектирования
позволяют автоматически генерировать программный код или его
-56-
Для чего нужно архитектурное описание
каркас по моделям, которые являются частью архитектурного опи¬
сания, что позволяет говорить о принципиальной возможности ав¬
томатического получения кода по архитектурному описанию. Дан¬
ный подход известен как архитектуры, управляемые моделями [33],
и широко используется на практике.
Наличие архитектурного описания является полезным, ког¬
да речь идет о проектировании семейств или линеек продуктов.
В этом случае обычно используют понятие эталонной архитекту¬
ры (Reference architecture), которое можно рассматривать как неко¬
торое типовое решение, использование которого позволяет избе¬
жать серьезных ошибок при проектировании.
Наличие архитектурного описания также может быть полезно
для целей модернизации ИС.
ДЛЯ ЧЕГО НУЖНО АРХИТЕКТУРНОЕ ОПИСАНИЕ
Стандарты. Как указывалось ранее, первый стандарт, относя¬
щийся к программной архитектуре, IEEE 1471-2000 [29] был выпущен
в в 2000 г., а второй стандарт ISO/IEC/IEEE 42010:2011 [30] появился
в 2011 г. Его российским аналогом является стандарт, определенный
ГОСТ Р 57100-2016. Последний стандарт достаточно четко различа¬
ет 3 основных понятия, относящиеся к архитектуре ИС: архитекту¬
ра, архитектурное описание и архитектурный процесс. Эти понятия
предлагается рассматривать как независимые друг от друга. Предме¬
том стандарта ISO/IEC/IEEE 42010:2011 является архитектурное опи¬
сание. В основу стандарта положены четыре основные идеи:
1. Каждая система имеет собственную архитектуру, но все ар¬
хитектуры различны.
Программная архитектура рассматривается как абстракция,
некоторый взгляд на систему, который содержит самую важную ин¬
формацию о системе. Из архитектуры, а точнее из архитектурного
описания, заинтересованные стороны могут получить интересую¬
щую их информацию о системе. Однако из архитектурного описа¬
ния невозможно получить информацию о деталях реализации. Са¬
ма система является конкретным продуктом, а архитектура — это
высокоуровневая абстракция.
-57-
2. ЧТО СОБОЙ ПРЕДСТАВЛЯЕТ АРХИТЕКТУРА ИОС
2. Программная архитектура и архитектурное описание — это
разные понятия.
Программная архитектура существует, если существует система.
Архитектурное описание — это артефакт, который появляется на
определенном этапе проектирования системы, основной целью кото¬
рого является определение того, из каких элементов состоит система
и как эти элементы связаны между собой. Таким образом, архитек¬
турное описание появляется раньше самой системы и ее архитектуры.
Фактически это пожелание того, какой должна быть система.
Стандарт определяет архитектуру как принципы организа¬
ции системы в терминах основных компонентов, их взаимосвязей,
окружения и принципов проектирования и эволюции, а архитек¬
турное описание — как набор артефактов, составляющих описание
архитектуры.
Из приведенного определения видно, что архитектура — это не¬
что неосязаемое, с чем нельзя работать, т. е. работать можно только
с архитектурным описанием. Для составления архитектурного опи¬
сания могут использоваться различные языковые средства, блок-
схемы, различные языки архитектурного описания (Architecture
Definition Language, ADL), такие как UML, ADL и др.
Следует заметить, что архитектурное описание очень час¬
то вообще отсутствует. Это относится к унаследованным систе¬
мам, которые создавались задолго до появления самого понятия
«программная архитектура», и к очень простым системам, когда
один или несколько членов команды разработчиков очень хоро¬
шо представляют себе создаваемую систему.
Однако и в первом, и во втором случае архитектура существует
и в случае необходимости может быть восстановлена. Этот процесс
обычно называют реконструкцией архитектуры (Architectural
Reconstructing).
3. Программная архитектура, архитектурное описание и про¬
цесс разработки ПО — это разные сущности как с точки зрения те¬
ории, так и с точки зрения практики.
Программная архитектура — это то, что представляет со¬
бой система на концептуальном уровне. Архитектурное описание,
-58-
Для чего нужно архитектурное описание
относящееся к конкретной архитектуре, может быть выполнено
с использованием различных изобразительных средств и нотаций.
В этом плане за архитектором оставляется свобода выбора. Кон¬
кретный способ описания выбирается исходя из специфики архи¬
тектуры и используемого процесса проектирования. Стандарт ISO/
IEC/IEEE 42010:2011 только в самом общем виде определяет модель
жизненного цикла системы, она определяет точки зрения и виды,
но не предписывает использование конкретных видов и точек зре¬
ния для описания архитектуры. Следует заметить, что выбор той или
иной нотации определяется используемым подходом к проектирова¬
нию. Использование конкретного инструментария проектирования
часто предопределяет выбор нотации для архитектурного описания.
Например, при использовании Ratinoml Unified Process (RUP) естест¬
венным представляется использование языка UML, который более
подробно будет рассмотрен ниже.
4. Стандарт определяет только общие подходы к построению
архитектурного описания, оставляя за архитектором выбор кон¬
кретных моделей, видов и точек зрения.
В стандарте определяются только базовые принципы и отно¬
сящиеся к ним активности. Архитектор может комбинировать эти
принципы исходя из контекста. В стандарте в основном использу¬
ются формулировки типа «по меньшей мере, должно быть», но пра¬
ктически отсутствуют формулировки типа «необходимо иметь» или
«должно быть». Например, при определении списка заинтересован¬
ных лиц используется формулировка: к основным категориям заин¬
тересованных сторон как минимум следует отнести пользователей
системы, покупателей, разработчиков и специалистов по эксплуа¬
тации. В стандарте отсутствуют какие-либо ограничения по выбо¬
ру процесса разработки на архитектурном уровне. Можно выбирать
типовой процесс или создавать собственный.
Очевидно, что появление данного стандарта не может решить
всех проблем архитектурного проектирования. Его следует рассма¬
тривать как эталонную метамодель, которую следует использовать
для построения моделей более низкого уровня, например, относя¬
щихся к конкретным классам ИС [34, 35].
Основные понятия и определения. Основные термины и по¬
нятия, связанные с архитектурой информационных и программ¬
-59-
2. ЧТО СОБОЙ ПРЕДСТАВЛЯЕТ АРХИТЕКТУРА ИОС
ных систем, определены в международном стандарте ISO/IEC/IEEE
42010:2011 [30]. В этом стандарте определены ключевые понятия,
связанные с архитектурой, архитектурным описанием, архитектур¬
ными фреймворками и архитектурным процессом. В [30] они опре¬
деляются следующим образом.
Архитектура (architecture) — система фундаментальных кон¬
цепций или свойств системы, воплощенная в элементах системы,
их взаимосвязях, а также в принципах проектирования и развития.
Архитектурный процесс (architecting) определяется как про¬
цесс, включающий порождение, определение, документирование,
сертификацию, реализацию, сопровождение и модификацию, т. е.
архитектурная поддержка системы на всех этапах жизненного ци¬
кла. Этот процесс реализуется в рамках конкретной организации
и регламентируется такими международными стандартами, как
ISO/IEC 12207, ISO/IEC 15288.
Архитектурное описание (architecture description, AD) — сово¬
купность описаний архитектуры.
Архитектурный фреймворк (architecture framework) — сово¬
купность договоренностей принципов и практик применительно
к определенному предметному домену и (или) в сообществе заин¬
тересованных лиц.
Архитектурные виды (architecture view) — описание архитек¬
туры системы с точки зрения отдельных интересов.
Архитектурные точки зрения (architecture viewpoint) — набор
соглашений, который определяет способы построения, интерпре¬
тации и использования архитектурных видов с целью формирова¬
ния требуемых концернов.
Интересы (concern) — предмет интереса одной или нескольких
заинтересованных сторон. Это относится также к влиянию на сис¬
тему различных внешних факторов, таких как технологии, эконо¬
мика, политика, экология и др.
Окружение (environment) определяет факторы и условия, при
которых эти факторы могут оказать влияние на состояние системы.
Вид моделей (model kind) — соглашения о способе моделиро¬
вания. В качестве моделей могут выступать, например, сети Петри,
UML-диаграммы и т. п.
-60-
Для чего нужно архитектурное описание
Заинтересованная сторона (stakeholder) — человек, группа
людей, организация, которые заинтересованы в системе.
Архитектурное описание системы или класса систем разраба¬
тывается и существует в некотором контексте, структура которого
показана на рис. 2.2 [30].
Рис. 2.2. Контекст архитектурного описания
В данном случае термин «системы» подразумевает под собой
следующее: «системы, которые созданы человеком и которые могут
конфигурироваться на уровне аппаратных средств, программного
обеспечения, данных, людей, процессов, предоставляющих серви¬
сы людям, процедур, в частности инструкций для операторов, а так¬
же программные системы и сервисы (software-intensive systems)» [28],
которые определяются как любая система, в которой программная
составляющая является существенной для ее разработки, производ¬
ства, эксплуатации и модернизации.
На рис. 2.3 показано, как соотносятся между собой введен¬
ные выше понятия. Следует заметить, что стандарт [30] четко раз¬
личает понятия «архитектура» и «архитектурное описание», при
этом в качестве предмета стандартизации выступает архитектур¬
ное описание.
Если архитектурное описание — это некоторый артефакт или
совокупность артефактов, то сама архитектура — это абстракция,
включающая в себя концепции и свойства.
-61-
2. ЧТО СОБОЙ ПРЕДСТАВЛЯЕТ АРХИТЕКТУРА ИОС
exhibits ^
Рис. 2.3. Соотношения между основными понятиями
Стандарт [30] никак не определяет то, какой процесс использу¬
ется для проектирования архитектуры, и не регламентирует состав
используемых моделей и нотаций.
Заинтересованные стороны имеют интересы относительно не¬
которой системы, несколько заинтересованных сторон могут иметь
общий интерес. Интересы появляются на протяжении всего жиз¬
ненного цикла системы. Интересы могут быть обозначены в раз¬
ных формах: в форме целей, ожиданий, требований, ограничений,
показателей качества, рисков и т. д. Способ описания интересов во
многом зависит от системы. Например, свойства программных си¬
стем определены в [30].
Отношения между элементами архитектурного описания опре¬
деляются в терминах соответствия (correspondence), которые, в свою
очередь, определяются посредством правил соответствия (cor¬
respondence rules) (рис. 2.4).
-62-
Для чего нужно архитектурное описание
Рис. 2.4. Правила соответствия
Для объяснения того, почему приняты те или иные архитек¬
турные решения, используются обоснования (rationale). Решения
могут касаться, в частности, интересов, изменения характеристик
элементов, исключения или включения новых видов и точек зре¬
ния и т. п. (рис. 2.5).
depends upon
Рис. 2.5. Архитектурные обоснования
Архитектурное описание сопровождает систему на протяжении
всего жизненного цикла и может использоваться для решения сле¬
дующих основных задач:
1) как инструмент проектирования системы;
2) для оценки альтернативных вариантов реализации;
3) при составлении документации;
4) в качестве исходных данных для систем моделирования;
5) для составления спецификаций семейств продуктов;
6) при проведении работ, связанных с переходом на новые ар¬
хитектуры, и т. д.
Архитектурное описание системы или класса систем разраба¬
тывается и существует в контексте, структура которого представле¬
-63-
2. ЧТО СОБОЙ ПРЕДСТАВЛЯЕТ АРХИТЕКТУРА ИОС
на на рис. 2.6. Контекст описания системы определяют заинтересо¬
ванные стороны и окружение системы.
Рис. 2.6. Структура контекста
Архитектурное описание включает один или более архитек¬
турных видов (далее видов). Каждый вид относится к одной или
более области интересов заинтересованных сторон. Архитектур¬
ный вид описывает архитектуру в соответствии с архитектурны¬
ми точками зрения. Архитектурная точка зрения включает один
или более интересов, при этом каждый из интересов может входить
в несколько точек зрения, а также соглашение о видах. Точка зре¬
ния определяет вид в соответствии с интересом. Соглашение о ви¬
дах может включать языки, нотации, виды используемых моделей,
правила проектирования, методы моделирования и др. В стандар¬
те [30] предлагается использовать соответствующие виды: business
view, physical view и technical view. Архитектурный вид включает од¬
ну или несколько архитектурных моделей, каждая из которых ис¬
пользует соглашения о способе моделирования. Соглашения, в свою
очередь, определяются типом модели.
Архитектурное описание обычно включает следующие эле¬
менты: информацию, идентифицирующую данное описание, за¬
интересованные стороны и их интересы, определение каждой из
архитектурных точек зрения, архитектурные виды и модели для ка¬
ждой из точек зрения, правила соответствия, обоснования. Кроме
того, архитектурное описание может содержать информацию, кото¬
рая не относится к определенному виду, например общее описание
-64-
Для чего нужно архитектурное описание
системы, соответствие моделей, обоснования архитектурных реше¬
ний. Стандарт не определяет конкретных форматов описаний, воз¬
можно использование альтернативных вариантов архитектурного
описания одной и той же архитектуры.
В стандарте определяются следующие типовые группы заин¬
тересованных сторон: пользователи (users), операторы (operators),
покупатель (acquirers), владельцы (owners), поставщики (suppliers),
разработчики (developers), наладчик, изготовитель, специалист по
эксплуатации (maintained). В качестве интересов предлагается рас¬
сматривать следующие моменты: цели создания системы, степень
достижения поставленных целей, возможность реализации, по¬
тенциальные риски заинтересованных сторон на протяжении все¬
го времени жизни системы, простота поддержки и модернизации
системы. Описание должно в явном виде связывать интересы с за¬
интересованными сторонами.
Стандарт не определяет такие моменты, как уровень детали¬
зации при описании интересов и взаимосвязи отдельных интере¬
сов, каким образом интересы соотносятся с такими понятиями,
как цели создания системы, требования пользователей. Эти мо¬
менты относят к фреймворкам или конкретным практикам.
Описание каждой точки зрения должно содержать: один или
несколько интересов и соответствующих им точек зрения, пере¬
числение типовых заинтересованных сторон с указанием соответ¬
ствующих им точек зрения, типы моделей, используемых в точках
зрения, при этом для каждой модели определяются: язык, исполь¬
зуемые нотации, техника моделирования, описание аналитических
моделей, ссылки на источники, содержащие описания моделей.
Архитектурный вид связывается с одной или несколькими мо¬
делями, каждая из которых имеет идентификатор версии в рамках
проекта или организации. Каждая архитектурная модель принад¬
лежит определенному типу и использует соглашения о способе мо¬
делирования, которые определяются типом модели. Для описания
типов моделей могут использоваться метамодели. Должно опреде¬
ляться преобразование типа модели в конкретный экземпляр. Сов¬
местное использование моделей в нескольких архитектурных видах
-65-
2. ЧТО СОБОЙ ПРЕДСТАВЛЯЕТ АРХИТЕКТУРА ИОС
открывает возможность использования аспектно-ориентированно¬
го стиля описания архитектуры. Архитектурные модели можно рас¬
сматривать как контейнеры, в которые помещаются архитектурные
стили и паттерны. Сам стандарт не предписывает использование
тех или иных моделей.
Архитектурное описание должно содержать описание всех со¬
ответствий между отдельными элементами, в частности между мо¬
делями, видами.
Для определения соответствия элементы архитектурного опи¬
сания, в качестве которых могут выступать экземпляры таких клас¬
сов, как заинтересованные стороны, интересы, точки зрения, виды,
типы моделей (кроме того, могут быть введены и другие элементы),
описываются с помощью правил соответствия (correspondence rules).
Архитектурные обоснования. Архитектурное описание долж¬
но содержать обоснование всех ключевых решений.
Описание содержит идентифицирующую и дополнительную
информацию, определяемую в рамках организации или проекта,
ссылки на точку зрения, которая соответствует данному виду, ссыл¬
ки на все интересы, которые определены в соответствующей точ¬
ке зрения.
Архитектурный процесс поддержки системы включает два
основных механизма — архитектурные фреймворки и языки опи¬
сания архитектур (architecture description languages, ADLs). Архитек¬
турный фреймворк в соответствии с [30] показан на рис. 2.7.
Рис. 2.7. Архитектурный фреймворк
-66-
Для чего нужно архитектурное описание
Архитектурные фреймворки предназначены прежде всего
для создания архитектурных описаний конкретных проектов, раз¬
работки семейств и линеек продуктов, разработки инструментария
архитектурного моделирования как в рамках одной организации, так
и многих. Типичными примерами архитектурных фреймворков мо¬
гут служить Zachman’s Information Systems Architecture Framework, UK
Ministry of Defence Architecture Framework, The Open Group’s Architecture
Framework (TOGAF), Kruchten’s «4 + 1» view model, Siemens’4 views method,
Reference Model for Open Distributed Processing (RM-ODP), Generalized
Enterprise Reference Architecture (GERA) [36, 37, 38, 39].
Архитектурное описание фреймворка должно содержать
следующие элементы: идентификатор фреймворка, идентифи¬
каторы одного или нескольких интересов, идентификаторы од¬
ного или более пользователей, которые имеют данные интересы,
одну или несколько архитектурных точек зрения, которые инкап¬
сулируют интересы, правила, определяющие соответствия. Кроме
того, описание фреймворка должно содержать условия его при¬
менимости.
Язык архитектурного описания (ADL) (рис. 2.8) предлагает один
(или более) тип моделей для описания области интересов конкрет¬
ных заинтересованных сторон. ADL отличаются многообразием.
Можно выделить специализированные языки, ориентированные на
модели одного типа или на поддержку многих моделей, например,
такие как UML. Обычно для ADL имеются соответствующие инстру¬
ментальные средства, с помощью которых можно создавать и ана¬
лизировать модели. В качестве примера ADL могут выступать такие
языки, как UML, Rapide, Wright, SysML, ArchiMate и viewpoint languages
of RM-ODP [36-39].
Рис. 2.8. Язык архитектурного описания
-67-
2. ЧТО СОБОЙ ПРЕДСТАВЛЯЕТ АРХИТЕКТУРА ИОС
Язык описания архитектуры определяется через описание сле¬
дующих элементов: определение одного или нескольких интересов,
определение заинтересованных сторон, имеющих данные интере¬
сы, определение используемых типов моделей и соответствующих
им точек зрения.
КАК ИСПОЛЬЗОВАТЬ АРХИТЕКТУРНЫЕ ВИДЫ
И ТОЧКИ ЗРЕНИЯ
При проектировании ИС ее необходимо представлять таким
образом, чтобы идея проектируемой ИС была понятна и однознач¬
но воспринималась всеми заинтересованными сторонами. Невоз¬
можность отразить функциональные особенности и качественные
свойства сложной ИС в единой понятной модели, которая была бы
понятна и ценна для всех заинтересованных сторон, достаточно
очевидна. Достаточно очевидным решением этой проблемы явля¬
ется описание ИС с нескольких точек зрения, которые должны кор-
релироваться с интересами заинтересованных сторон.
Для реализации этого подхода в стандарте 42010, отечествен¬
ным аналогом которого является стандарт ГОСТ Р 57100-2016/ISO/
IEC/IEEE 42010:2011, предлагается два механизма: архитектурные ви¬
ды (views) и архитектурные точки зрения (view points). Кроме того, на
практике достаточно часто используется понятие архитектурных пер¬
спектив. Все эти понятия и их взаимосвязь будут рассмотрены ниже.
При выборе набора видов, которые могут с достаточной точно¬
стью описать разрабатываемую ИС, рекомендуется исходить из сле¬
дующих соображений [40]:
- кто является заинтересованными сторонами и какова квали¬
фикация каждой из сторон;
- каковы интересы каждой из заинтересованных сторон;
- какие структурные и функциональные аспекты ИС должны
отображаться;
- в терминах каких архитектурных элементов следует описы¬
вать создаваемую систему;
- какой уровень детализации требуется при описании архи¬
тектуры.
-68-
Как использовать архитектурные виды и точки зрения
Архитектурные виды. В стандарте архитектурный вид опре¬
деляется как «представление одного или нескольких аспектов ар¬
хитектуры, которая иллюстрирует, каким именно образом реализу¬
ет интересы одного или нескольких пользователей».
Этот подход восходит к предложенной Ф. Крачтеном (Kruchten)
еще в архитектурной модели 1995 г., которая известна как «4 + 1»
view model (рис. 2.9) [41].
Статические
Логическое
Физическое
модели
представление
представление
архитектуры
компонентов
системы
Архитектор,
Аналитик,
программист
архитектор
—
Модель ИС
Динамические
м одел и
Концептуальная
Логическое
модель поведения
представление
системы
процесса
Конечный
фунционирования
пол ьзователь,
Аналитик,
аналитик
системный инженер
Обобщенные
модели
Детальные
м одел и
Рис. 2.9. Архитектурные виды
Данная модель предлагает рассматривать создаваемую ИС
с пяти точек зрения: системной точки зрения, с точки зрения кон¬
цептуальной структуры, с точки зрения реализуемой функцио¬
нальности, детальное описание структуры и детальное описание
функционирования. Системная точка зрения описывает взаимо¬
действие создаваемой системы со средой. Этот вид отражает ин¬
тересы потенциальных владельцев системы, бизнес-аналитиков,
архитектора. Концептуальная структура описывает систему как
множество соединенных подсистем на верхнем уровне и отража¬
-69-
2. ЧТО СОБОЙ ПРЕДСТАВЛЯЕТ АРХИТЕКТУРА ИОС
ет интересы системного аналитика, архитектора и программиста.
Реализуемая функциональность описывает концептуальное пред¬
ставление поведения системы и отражает интересы системного
аналитика, а также интересы конечных пользователей. Детальное
описание структуры ИС представляет интерес для архитектора
и программиста. Детальное описание динамики функционирова¬
ния системы представляет интерес для специалистов по техниче¬
ской поддержке, в частности системных администраторов и сис¬
темных инженеров.
Архитектурные точки зрения (Viewpoints). Архитектурный
вид никак не определяет способ, которым будет представлена со¬
ответствующая информация. Для этого используются архитектур¬
ные точки зрения.
Стандарт [30] определяет термин «архитектурная точка зре¬
ния» как «набор паттернов, шаблонов и соглашений для построе¬
ния одного конкретного архитектурного вида. Точки зрения опре¬
деляют заинтересованные стороны». В нем также определяются
заинтересованные стороны и типовые модели, используемые для
представления их интересов.
Из приведенного определения видно, что по сравнению с точ¬
кой зрения архитектурный вид является более общим понятием.
Можно утверждать, что одному архитектурному виду могут соот¬
ветствовать несколько архитектурных точек зрения, которые мо¬
гут, в частности, учитывать специфику создаваемой ИС. Соотно¬
шение между понятиями «архитектурный вид» и «архитектурная
точка зрения» приблизительно такое же, как между понятиями
«класс» и «экземпляр класса».
Точки зрения можно рассматривать как механизм накопления
архитектурного знания.
В [30] в качестве основных точек зрения рекомендуется ис¬
пользовать следующие точки зрения: контекстная ТЗ, функцио¬
нальная ТЗ, информационная ТЗ, ТЗ распараллеливания, ТЗ, свя¬
занная с разработкой, ТЗ, связанная с размещением, операционная
ТЗ (рис. 2.10).
-70-
Как использовать архитектурные виды и точки зрения
Контекстная ТЗ
Функциональная ТЗ
Разработка
Информационная ТЗ
Размещение
Распараллеливание
Операционная ТЗ
Рис. 2.10. Архитектурные точки зрения
Контекстная точка зрения описывает отношения, зависимости
и взаимодействия между системой и ее окружением (людьми, сис¬
темами и внешними объектами, с которыми она взаимодействует).
Контекстный вид может представлять интерес для многих катего¬
рий заинтересованных лиц и должен позволить им сферу ответст¬
венности отдельных заинтересованных сторон и роль системы в си¬
стеме более высокого уровня.
Функциональная, информационная и ТЗ, связанная с распарал¬
леливанием, характеризуют фундаментальную организацию систе¬
мы. ТЗ, связанная с разработкой, отражает процесс разработки си¬
стемы. Точка зрения, связанная с размещением, и операционная
ТЗ характеризуют разрабатываемую систему с точки зрения ее экс¬
плуатации.
Функциональная ТЗ описывает процесс функционирования
системы, в частности назначение отдельных элементов, их ин¬
терфейсы и взаимосвязи. Этот вид можно рассматривать как
ключевой вид, поскольку именно здесь рассматриваются такие
ключевые характеристики системы, как производительность,
гибкость и др.
Информационная ТЗ описывает, каким образом система соби¬
рает, хранит и обрабатывает данные, информацию, знания, выпол¬
няет их обработку и представление. Данный вид должен отвечать
на вопросы, связанные с тем, какие данные, информация и знания
(ДИЗ) обрабатывает ИС, где они хранятся, кому принадлежат ДИЗ,
кто имеет доступ к конкретным ДИЗ.
-71-
2. что собой представляет архитектура иос
Распараллеливание. Эта ТЗ описывает функционирование сис¬
темы с точки зрения одновременного выполнения отдельных час¬
тей бизнес-процесса в терминах процессов, нитей и межпроцесс¬
ных взаимодействий.
Разработка. Эта ТЗ описывает процесс разработки ИС, вклю¬
чая все стадии: построение, тестирование, эксплуатацию, модер¬
низацию.
Размещение. Эта ТЗ описывает окружение, в которое помещает¬
ся создаваемая ИС: аппаратные средства, сетевая инфраструктура,
системы обработки и хранения данных, а также требования, предъ¬
являемые к ним.
Операционная ТЗ. Эта ТЗ описывает процесс функционирова¬
ния, поддержания в исправном состоянии, администрирования
и технической поддержки системы.
Следует заметить, что перечисленные точки зрения не всег¬
да применимы ко всем типам разрабатываемых ИС и что относи¬
тельная важность разных точек зрения для разных типов систем
и для разных постановок задач проектирования может сущест¬
венно различаться.
КАКИЕ ПЕРСПЕКТИВЫ НАЗЫВАЮТСЯ
АРХИТЕКТУРНЫМИ
Использование архитектурных видов помогает решать многие
проблемы, связанные с архитектурным проектированием, в частно¬
сти проблемы, связанные со сложностью. Идея архитектурных ви¬
дов состоит в том, чтобы привязать виды к интересам заинтересо¬
ванных сторон. Однако реально оказывается, что многие группы
заинтересованных сторон имеют интерес к одним и тем же характе¬
ристикам, причем интересы могут различаться. Для решения этой
проблемы в [40] было предложено понятие архитектурной перспек¬
тивы, которое достаточно активно используется на практике, хотя
и не определяется в основном стандарте [30].
Понятие архитектурной перспективы определяется как «со¬
вокупность архитектурных решений, тактик и руководящих прин¬
-72-
Какие перспективы называются архитектурными
ципов, которые используются для обеспечения того, чтобы система
демонстрировала определенный набор связанных свойств качества,
которые требуют рассмотрения в ряде архитектурных представле¬
ний системы» [40]. Из приведенного определения следует, что архи¬
тектурная перспектива ставит во главу угла достижения некоторых
значений одного или нескольких параметров качеств.
Понятие архитектурной перспективы можно рассматривать
как средство накопления архитектурного знания, которое в своей
основе является процедурным знанием, которое представляется
в форме архитектурной тактики.
Архитектурную тактику можно определить как устоявшийся
и проверенный подход, который может использоваться для дости¬
жения архитектурно значимых параметров создаваемой ИС [26, 40].
При этом под архитектурно значимой характеристикой понима¬
ется характеристика, которая определяется на начальном (архитек¬
турном) этапе проектирования. Как правило, это наиболее важные
характеристики, на достижение которых определяющее влияние
оказывают архитектурные решения. Наиболее полезно использо¬
вание архитектурных перспектив в том случае, когда предъявля¬
ются высокие требования к значению определенного параметра,
например производительности, надежности или совокупной стои¬
мости владения.
Понятие архитектурной перспективы напрямую связано с по¬
нятием архитектурно значимых параметров. Значимость отдель¬
ных параметров определяется двумя основными факторами: типом
разрабатываемой системы и постановкой задачи проектирования.
К числу архитектурно значимых параметров обычно относят
следующие параметры: производительность, доступность, безопас¬
ность, масштабируемость, гибкость (способность к модернизации).
Кроме того, достаточно часто используются такие перспекти¬
вы, как удобство для пользователя, стоимость (сроки) разработки,
соответствие стандартам.
Взаимосвязь между архитектурными видами и перспективами
приведена в табл. 2.1.
-73-
-74-
Таблица 2.1
Соотношение видов и перспектив
№
Вид
Производительность
Доступность
Безопасность
Масштабируемость
1
Контекстный
-
-
+ -
+ -
2
Функциональный
+ -
-
+ -
+
3
Информационный
+ -
+-
+ -
+
4
Распараллеливание
+
+-
-
+
5
Разработка
-
+
+ -
-
6
Размещение
+
+
+ -
+ -
7
Операционный
-
+
+
-
2. ЧТО СОБОЙ ПРЕДСТАВЛЯЕТ АРХИТЕКТУРА ИОС
ДЛЯ ЧЕГО ПРИМЕНЯЮТСЯ
АРХИТЕКТУРНЫЕ МОДЕЛИ
Для чего применяются архитектурные модели
В процессе проектирования модели находят самое широкое
применение, при этом используются разнообразные модели.
Применительно к архитектурному проектированию понятие
модели можно определить как абстрактное, упрощенное или ча¬
стичное представление некоторых аспектов архитектуры, целью ко¬
торого является доведение этих аспектов системы до сведения од¬
ной или нескольких заинтересованных сторон.
В процессе архитектурного проектирования модели могут ис¬
пользоваться для решения различных частных задач проекти¬
рования.
1. На начальных этапах проектирования модели, описываю¬
щие функционирование всей системы, помогают понять ситуацию
и определить ключевые проблемы, которые возникают при проек¬
тировании системы.
2. В процессе проектирования очень часто архитектору при¬
ходится принимать решения в условиях неопределенности, на¬
пример при проектировании некоторой системы архитектор дол¬
жен принять решение о выборе типа процессора, используемого
в некоторой подсистеме. При этом оказывается не совсем понят¬
но, как производительность данного процессора влияет на произ¬
водительность всей системы. В этом случае полезными оказыва¬
ются частные модели. В этом случае модель можно передать для
анализа другим специалистам, например профессиональным ма¬
тематикам.
3. Если доступны инструментальные средства, которые могут
по моделям генерировать код приложения или его каркас, то в этом
случае модель выступает в качестве конечной цели архитектурно¬
го проектирования.
4. Модели могут выступать в качестве языка общения между
заинтересованными сторонами. В этом случае архитектор исполь¬
зует модель для того, чтобы донести свое видение системы как до
заказчиков системы, так и до исполнителей (программистов, тести¬
ровщиков).
-75-
2. ЧТО СОБОЙ ПРЕДСТАВЛЯЕТ АРХИТЕКТУРА ИОС
Типы моделей. В первом приближении архитектурные моде¬
ли можно разделить на формальные и неформальные, а также на ка¬
чественные и количественные.
Эскизы (sketch) представляют собой простейший тип моделей,
который часто используется на ранних этапах проектирования.
Эскиз представляет собой намеренно неформальную графиче¬
скую модель, созданную для того, чтобы донести наиболее важные
аспекты архитектуры до нетехнической аудитории. Он может со¬
четать в себе элементы ряда обозначений моделирования, а также
изображения и значки.
Эскизы представляют собой полезный инструмент, когда требу¬
ется помочь заинтересованным сторонам, особенно нетехническим
специалистам, понять суть архитектуры. Эскизы часто используют¬
ся на начальных этапах проекта разработки системы, чтобы объяс¬
нить ключевые функции более широкому сообществу. Этот процесс
иногда называют «социализация архитектуры».
Опасность слишком широкого использования эскизов состо¬
ит в том, что они могут достаточно легко внести двусмысленность
и даже привести к путанице и непониманию. Поэтому рекомен¬
дуется возможно быстрее заменить эскизы более формальными
моделями.
Качественные модели иллюстрируют ключевые структурные
или поведенческие элементы, особенности или атрибуты модели¬
руемой архитектуры. Неформальные качественные модели иногда
называют эскизами.
Качественные модели во многом подобны масштабным моде¬
лям и чертежам, созданным архитекторами зданий и инженерами-
строителями для определения структуры нового здания с целью по¬
казать, как оно будет выглядеть в его окружении. Подобные модели
направлены на то, чтобы представить сущность моделируемой ве¬
щи — ее форму и особенности, — а не на то, чтобы предсказать ее из¬
меримые качества. Качественные модели чрезвычайно важны для
архитектора и используются на протяжении всего жизненного ци¬
кла системы, начиная с ранних стадий определения архитектуры,
когда идеи выкристаллизовываются, и заканчивая поздними ста¬
-76-
В чем особенность архитектур, управляемых моделями
диями жизненного цикла, когда необходимо уточнить подробные
аспекты проектирования системы.
Некоторые из моделей, особенно используемые на ранних
стадиях проектирования, могут быть ориентированы на смешан¬
ную аудиторию заинтересованных сторон в бизнесе и технологиях.
Иногда модели создаются в ответ на конкретные политические по¬
требности внутри организации, например подчеркивать финансо¬
вые преимущества новой архитектуры.
Такие смешанные модели обычно должны быть менее фор¬
мальными и строгими, чем модели, ориентированные на более спе¬
циализированные группы заинтересованных сторон.
Количественные модели. Количественные модели можно опре¬
делить как модели, которые позволяют судить об измеримых свой¬
ствах архитектуры, таких как производительность, надежность про¬
пускная способность.
Поскольку они имеют дело с системными качествами, а не со
структурами, то они, как правило, соответствуют перспективам, а не
точкам зрения. Результатом количественных моделей является на¬
бор показателей, который предсказывает поведение или другие ха¬
рактеристики системы. Количественные модели обычно имеют ма¬
тематическую или статистическую основу.
Количественный анализ обычно подразумевает либо высокую
математическую квалификацию, либо наличие инструментария ма¬
тематического моделирования.
Эффективные количественные модели часто требуют много
времени для создания и проверки, поэтому часто в условиях де¬
фицита времени и ресурсов ограничиваются созданием грубых
моделей.
В ЧЕМ ОСОБЕННОСТЬ АРХИТЕКТУР,
УПРАВЛЯЕМЫХ МОДЕЛЯМИ
Архитектура, управляемая моделями (Model Driven Archi¬
tecture, MDA), — это подход к проектированию приложений, осно¬
ванный на широком использовании моделей, в частности платфор¬
менно-независимых моделей.
-77-
2. ЧТО СОБОЙ ПРЕДСТАВЛЯЕТ АРХИТЕКТУРА ИОС
Под платформенно-независимой моделью (Platform Inde¬
pendent Model, PIM) понимается такое представление системы, в ко¬
тором внимание концентрируется на общей архитектуре систе¬
мы, а детали реализации, относящиеся к конкретной платформе,
скрываются.
PIM представляет только часть полной спецификации системы,
которая не изменяется при переходе с одной платформы на другую.
В соответствии с концепцией MDA разработка ИС начинает¬
ся с создания PIM-модели, которая определяет состав, структуру
и поведение будущей ИС. PIM представляет совокупность архитек¬
турных элементов проектируемой ИС и связей между ними, но без
привязки к конкретным языкам программирования и ОС.
На последующих этапах разработки ИС на базе PIM строится
одна или несколько платформенно-зависимых моделей (Platform
Specific Model, PSM), которые уже учитывают специфику конкрет¬
ной платформы и технологии реализации программных компо¬
нентов.
Описание архитектурных моделей. Наиболее эффективным
и повсеместно используемым подходом к описанию архитектур¬
ных моделей является методология Model-Driven Engineering (MDE),
основанная на построении иерархии моделей. Для описания мо¬
делей применяются специализированные доменно-ориентиро¬
ванные языки (domain-specific modeling languages, DSMLs), которые
используются для построения моделей систем в соответствии с се¬
мантикой и ограничениями, определенными в метамодели. Состав¬
ной частью MDE является набор утилит для генерации разного ро¬
да артефактов, таких как исходный код, диаграммы размещения
и преобразования моделей.
Ключевыми для MDE являются следующие концепции: мо¬
дель (model, M), метамодель (metamodel, MM), связывание моделей
(model weaving, MW), преобразование моделей (model transformation,
MT), метаметамодель (MMM). Модели, используемые в рамках
MDE-подхода, образуют стек (табл. 2.2), который содержит четы¬
ре уровня М0-М3.
Уровень М0 представляет собой саму моделируемую систе¬
му; уровень М1 соответствует модели системы. Уровень М2 —
это уровень метамоделей. Каждая модель должна соответство-
-78-
В чем особенность архитектур, управляемых моделями
вать определенной метамодели, которая определяет семантику
и элементы модели. Можно говорить, что метамодель определя¬
ет ключевые сущности, отношения и ограничения языка модели¬
рования. Уровень М3 определяется как уровень метамоделей для
метамоделей, которые называются метаметамоделями. Посколь¬
ку уровень метаметамоделей — это самый высокий уровень, то
метаметамодели должны соответствовать только сами себе. Мо¬
дели стека понимаются в соответствии с определением модели,
предложенным в [39].
Таблица 2.2
Стек моделей
Уровень
Описание
Взаимосвязь моделей
Уровень М3
Определяется как уровень
у Соответствует^
(высший)
метамоделей для
метамоделей
1
^Метаметамо дель) мз
V
к Соответствует^/
Уровень М2
Соответствует уровень
1
Метамодель
N
M2
метамоделей
i
^ Соответствует^
(
Уровень М1
Соответствует
Модель
!)) mi
модель системы
к
| Представляет
(
▼
Л
Уровень М0
Соответствует
Система
M0
(низший)
сама моделируемая система
При построении моделей должны выполняться следующие
требования: во-первых, модель должна содержать только значи¬
мые для решения конкретных задач анализа элементы, т. е. она
не должна быть излишне сложной, во-вторых, модель должна со¬
ответствовать определенной точке зрения, и, в-третьих, модель
должна быть полезной, т. е. отвечать на конкретные вопросы.
-79-
2. ЧТО СОБОЙ ПРЕДСТАВЛЯЕТ АРХИТЕКТУРА ИОС
Модели трансформации. Представление набора моделей в ви¬
де стека требует определения процедуры перехода от модели верх¬
него уровня к моделям нижнего уровня. Преобразование моделей —
это процесс, который определяет, каким образом можно получить
целевую модель из нескольких исходных моделей. Процесс прео¬
бразования моделей (modelware) можно определить следующим
образом (рис. 2.11). Пусть модель Ма, соответствующая метамоде¬
ли ММа, трансформируется в модель Mb, которая соответствует ме¬
тамодели MMb. Само преобразование можно определить как MT,
также представляющую собой модель, которая соответствует мета¬
модели MMT. В свою очередь, MMTявляется моделью и должна со¬
ответствовать метаметамодели, например MOF-модели.
Рис. 2.11. Преобразования моделей
Модели могут трансформироваться либо «по горизонтали», ли¬
бо «по вертикали». В первом случае трансформируемая модель пре¬
образовывается в модель, которая принадлежит одному с ней уров¬
ню. Во втором случае трансформируемая модель является моделью
более высокого уровня. С точки зрения типов трансформируемых
моделей можно выделить следующие основные варианты [42]:
1) трансформация типа «формальная модель — формальная мо¬
дель»; 2) XML-описание — формальная модель; 3) текстовое описа¬
ние — XML-описание; 4) текстовое описание — формальная модель;
5) формальная модель — код. В классической работе [43] опреде¬
ляются следующие базовые механизмы трансформации моделей:
прямое преобразование (Direct manipulation), структурное преобра¬
зование (Structure Driven), операционное (Operational), преобразо¬
-80-
Какие существуют языки описания архитектуры
вание с использованием шаблонов (Template-based), реляционное
(Relational), преобразование графа (Graph Transformation), XSLT-пре¬
образование (XSLT-based), гибридное (Hybrid).
Модели связывания — это специальный тип моделей, пред¬
назначенный для связывания моделей разных типов. Данные мо¬
дели также могут быть представлены в рамках 4-уровнего стека мо¬
делей. Основное назначение этих моделей состоит в установлении
соответствия между отдельными элементами моделей (низкоуров¬
невое связывание).
Модель связывания может быть использована для связывания
любых элементов разных метамоделей, таких как метаклассы, атри¬
буты, ссылки, типы данных. На рис. 2.12 модель связывания WM ис¬
пользуется для установления соответствия между элементами ме¬
тамоделей MMa и MMb. При этом сама WM должна соответствовать
метамодели связывания WMM.
Рис. 2.12. Соответствия между элементами метамоделей
КАКИЕ СУЩЕСТВУЮТ ЯЗЫКИ
ОПИСАНИЯ АРХИТЕКТУРЫ
Наблюдаемое на современном этапе развития многократное
увеличение сложности ИС приводит к невозможности обеспечить
требуемые уровни качества ИС, такие как надежность, возмож¬
ность повторного использования, сопровождаемость. Это приво¬
дит к появлению новых подходов к проектированию ИС, в част¬
ности архитектурного подхода, который предполагает анализ
-81-
2. ЧТО СОБОЙ ПРЕДСТАВЛЯЕТ АРХИТЕКТУРА ИОС
структуры и поведения ИС с глобальных позиций. Использование
архитектурного подхода само по себе предполагает наличие язы¬
ка или языков архитектурного описания (architectural description
languages, ADL), которые позволяют описывать архитектуру и вы¬
полнять определенные преобразования. В течение многих лет ве¬
дутся работы по разработке таких языков. В данном параграфе
приведено краткое описание некоторых ADL. Следует отметить,
что это далеко не полный список известных ADL, кроме того, пос¬
тоянно предлагаются новые языки.
В настоящее время отсутствует общепринятое определение
ADL. На неформальном уровне ADL можно определить как специ¬
ализированный машинно ориентированный язык, предназначен¬
ный для описания программной или системной архитектуры на
требуемом уровне. Если использовать данное определение в каче¬
стве рабочего, то под него подпадают две группы ADL. К первой
группе можно отнести языки, которые условно можно назвать язы¬
ками моделирования системы на архитектурном уровне. Эти языки
базируются на определении архитектуры как системы фундамен¬
тальных концепций или свойств системы, воплощенной в элемен¬
тах системы, их взаимосвязях, а также в принципах проектирова¬
ния и развития.
На первый план при этом выступают элементы системы и их
взаимосвязи. При использовании данного подхода система чаще
всего описывается как набор объектов, обладающих интерфейса¬
ми и соединенных между собой с помощью коннекторов.
К этой группе относится большинство ранних ADL. Динамика
функционирования может описываться в терминах изменения со¬
стояния элементов. Фактически ADL рассматривается как язык опи¬
сания концептуальной модели.
Второй подход основывается на том, что ADL — это прежде
всего средства архитектурного описания в смысле [30], которое
использует такие понятия, как заинтересованные стороны, архи¬
тектурные виды, точки зрения, а сопровождающие ADL инстру¬
ментальные средства — это инструмент, позволяющий составлять
и анализировать архитектурные описания. Крайне желательно,
-82-
Какие существуют языки описания архитектуры
чтобы имелась возможность перехода от архитектурного описа¬
ния к программному коду или его каркасу. К этой группе можно
отнести UML, SysML [45, 46]. Инструментальные средства в этом
случае рассматриваются как средства разработки архитектурно¬
го описания с последующим переходом от архитектурного опи¬
сания к коду.
Можно сформулировать основные требования, предъявляе¬
мые к ADL:
- ADL должен описывать систему с точки зрения всех заинте¬
ресованных сторон;
- ADL должен быть ориентирован на решение задач созда¬
ния, архитектуры, ее уточнения и проверки на корректность (ва¬
лидации);
- ADL должен обеспечивать возможность генерации описа¬
ний более низкого уровня, от которых можно переходить к реа¬
лизации;
- ADL должен поддерживать различные архитектурные стили;
- ADL должен позволять получать архитектурные метрики по¬
лучаемых архитектур или обеспечивать возможность оперативно
генерировать прототипы создаваемых систем.
Перечисленные выше требования относятся к «идеальному»
ADL, и далеко не все реальные ADL соответствуют им.
Классификация ADL. Работы по разработке и внедрению ADL
в практику проектирования ИС ведутся уже не один десяток лет. За
это время были разработаны, по крайней мере, десятки ADL, если
не сотни языков, в основу которых были положены разные подхо¬
ды. Укрупненная классификация ADL приведена на рис. 2.13.
ADL можно классифицировать по следующим основным при¬
знакам: назначение, подход к реализации, тип архитектуры, ис¬
пользуемая нотация. С точки зрения назначения можно выделить
ADL, ориентированные только на документирование архитектур¬
ных решений, на генерацию кода архитектурному описанию, про¬
верку архитектурных решений на корректность и генерацию кода
на языке описания аппаратуры. Можно выделить два основных под¬
хода к построению ADL. Первый подход предполагает, что в осно¬
-83-
2. ЧТО СОБОЙ ПРЕДСТАВЛЯЕТ АРХИТЕКТУРА ИОС
ву ADL положена формальная теория, например алгебра процессов.
Второй подход не предполагает использование формального аппа¬
рата и опирается на опыт разработчиков. Обычно ADL в той или
иной степени ориентированы на описание определенных классов
архитектур. Это могут быть корпоративные, системные, программ¬
ные, аппаратно-программные или аппаратные архитектуры. ADL
могут использовать различные способы описания архитектур (но¬
тации): графическую, обычную текстовую (строковую), возможно
использование XML-описаний.
Рис. 2.13. Классификация ADL
UML (Unified Modeling Language). UML — это формальный гра¬
фический язык, являющийся de facto промышленным стандартом.
Первоначально он создавался как графический язык для поддер¬
жки объектно-ориентированной парадигмы проектирования про¬
граммного обеспечения. Позже в него были добавлены возможно¬
-84-
Какие существуют языки описания архитектуры
сти моделирования бизнес-процессов, системного проектирования
и отображения организационных структур. В настоящее время UML
является языком широкого профиля, это открытый стандарт, ис¬
пользующий графические обозначения для создания абстрактной
модели ИС. UML был создан для определения, визуализации, про¬
ектирования и документирования в основном программных сис¬
тем. UML не является языком программирования, но на основании
UML-моделей возможна генерация кода.
UML имеет хорошо определенный формальный синтаксис
и семантику, что позволяет реализовывать процесс машинной об¬
работки UML-моделей. Строго говоря, UML нельзя отнести к фор¬
мальным языкам, поскольку за ним не стоит математический
аппарат. Обычно UML определяют как язык, который определен
полуформально.
Несмотря на то, что классический UML входит в состав инстру¬
ментария современного архитектора, как правило, его часто не от¬
носят к семейству ADL.
Следует отметить, что по своим выразительным возможно¬
стям UML превосходит большинство современных ADL, в частно¬
сти позволяет строить архитектурные модели ИС. Если принять
во внимание возможность создания в рамках UML профилей, то
последние версии UML, начиная с 2.0, можно рассматривать в ка¬
честве ADL, поскольку он удовлетворяет большинству из перечи¬
сленных требований, предъявляемых к ADL.
Особо следует отметить, что все версии UML, начиная с ран¬
них, успешно использовались и продолжают использоваться для со¬
ставления архитектурных описаний. Таким образом, UML можно
рассматривать как один из наиболее часто используемых архитек¬
тором языков, поэтому имеет смысл рассмотреть более подробно
состав UML.
Используемые диаграммы разбиты на три группы: структур¬
ные диаграммы, диаграммы поведения и диаграммы взаимодейст¬
вия (рис. 2.14). Следует заметить, что в новых версиях UML появля¬
ются новые диаграммы.
-85-
2. что собой представляет архитектура иос
Диаграммы UML
Структурные
Диаграмма
классов
Диаграмма
пакетов
Диаграмма
объектов
Диаграмма
компонентов
Диаграмма
развертывания
Диаграмма
композитной
структуры
Диаграмма
профилей
Поведенческие
Диаграмма
вариантов
использования
Диаграмма
деятельности
Диаграммы
последовательности
Диаграмма
коммуникации
Рис. 2.14. Диаграммы UML
Структурные диаграммы (Structure Diagrams): диаграмма
классов (Class diagram), диаграмма композитных структур (Composite
Structure diagram), диаграмма пакетов (Package diagram), диаграм¬
ма объектов (Object Diagram), диаграмма компонентов (Component
diagram), диаграмма развертывания (Deployment Diagram), диаграм¬
ма профилей (Profile diagram).
Диаграммы поведения (Behavior Diagrams): диаграмма вариан¬
тов использования (Use Case diagram), диаграмма деятельности
-86-
Какие существуют языки описания архитектуры
(Activity diagram), диаграмма конечного автомата (State Machine
diagram).
Диаграммы взаимодействия (Interaction Diagrams): диаграм¬
ма последовательности (Sequence Diagram), диаграмма коммуника¬
ции (Communication Diagram), диаграмма обзора взаимодействия
(Interaction Overview Diagram), временная диаграмма (TimingDiagram).
Диаграмма классов — это статическая структурная диаграм¬
ма, описывает структуру системы в терминах классов, их атрибутов,
методов и зависимостей между классами.
Диаграмма композитной структуры — статическая струк¬
турная диаграмма, которая демонстрирует внутреннюю структуру
классов и взаимодействие элементов внутренней структуры клас¬
са. Подвидом диаграмм композитной структуры являются диаграм¬
мы кооперации, которые показывают роли и взаимодействие клас¬
сов в рамках кооперации.
Диаграмма пакетов — это структурная диаграмма, на кото¬
рой отображаются пакеты и связи между ними. Диаграммы паке¬
тов предназначены для организации элементов в группы с целью
упрощения анализируемой структуры.
Диаграмма объектов — это полный или частичный снимок
моделируемой системы в некоторый момент времени. На диаграм¬
ме объектов представлены экземпляры классов ИС и указываются
текущие значения их атрибутов и связи между объектами.
Диаграмма компонентов — это статическая структурная диа¬
грамма, показывающая разбиение программной системы на струк¬
турные компоненты и зависимости между компонентами. В качестве
компонентов выступают пакеты, модули, библиотеки файлов и т. п.
Диаграмма профилей (появилась в новых версиях) описыва¬
ет использование профилей.
Диаграмма развертывания используется для моделирования
работающих узлов и артефактов, развернутых на них.
Диаграмма вариантов использования (диаграмма преце¬
дентов) — диаграмма, на которой отражены отношения, существу¬
ющие между актерами и вариантами использования.
Диаграмма деятельности — это диаграмма, показывающая
разложение деятельности на ее составные части. Под деятельностью
понимается спецификация исполняемого поведения в виде коор¬
динированного последовательного и параллельного выполнения
-87-
2. ЧТО СОБОЙ ПРЕДСТАВЛЯЕТ АРХИТЕКТУРА ИОС
подчиненных элементов — вложенных видов деятельности и от¬
дельных действий, соединенных между собой потоками, которые
идут от выходов одного узла к входам другого.
Диаграмма конечного автомата — диаграмма, на которой
представлен конечный автомат с простыми состояниями, перехо¬
дами и композитными состояниями.
Диаграмма последовательности — это диаграмма, которая
описывает взаимодействия элементов модели в форме последова¬
тельности сообщений и соответствующих событий на линиях жиз¬
ни объектов.
Диаграмма коммуникации — диаграмма, которая описыва¬
ет взаимодействия между линиями жизни объектов в форме эле¬
ментов внутренней структуры системы и передаваемых между ни¬
ми сообщений.
Диаграмма обзора взаимодействия служит для представле¬
ния только взаимодействия потока управления.
Временная диаграмма явным образом показывает измене¬
ния состояния на линии жизни с заданной шкалой времени, что мо¬
жет быть полезно в приложениях реального времени.
SysML как ADL. SysML — это язык моделирования общего на¬
значения, имеющий графический интерфейс пользователя. Этот
язык используется для спецификации, анализа, проектирования
и верификации сложных технических систем, которые могут вклю¬
чать аппаратные средства, программные средства, информацион¬
ные ресурсы, персонал и т. д.
С помощью SysML, используя графические нотации, можно мо¬
делировать требования, структуру, поведение систем, выполнять ин¬
женерный анализ систем. SysML очень тесно связан с UML. Эти языки,
по существу, используют один и тот же подход к проектированию си¬
стем на основе моделей. Разница состоит в сфере применения.
UML ориентирован на проектирование программных систем,
а SysML — на проектирование аппаратно-программных и челове¬
ко-машинных систем. В этом смысле UML можно рассматривать
как подмножество SysML. Однако с точки зрения числа использу¬
емых диаграмм UML богаче SysML. В этом плане SysML можно рас¬
сматривать как подмножество UML.
-88-
Какие существуют языки описания архитектуры
SysML определяет две группы диаграмм (рис. 2.15) — струк¬
турные диаграммы (Structure Diagram) и поведенческие диаграм¬
мы (Behavior Diagram) — и диаграмму требований (Requirement
Diagramm). К структурным относятся четыре типа диаграмм: ди¬
аграмма определения блоков (Block Definition Diagram), диаграм¬
ма внутренних блоков (Internal Block Diagram), пакетная диаграмма
(Package Diagram) и параметрическая диаграмма (Parametric Dia¬
gram). К группе поведенческих диаграмм относят четыре типа ди¬
аграмм: диаграмму вариантов использования (Use Case Diagram),
диаграмму последовательностей (Sequence Diagram), диаграмму ак¬
тивностей (Activity Diagram) и диаграмму конечного автомата (State
Machine Diagram).
□ — совпадает с UML
— новая
! — модифицированная
с UML диаграмма
Рис. 2.15. Диаграммы SysML
-89-
2. ЧТО СОБОЙ ПРЕДСТАВЛЯЕТ АРХИТЕКТУРА ИОС
Основным понятием для SysML является «блок», в качестве
блока может выступать любой элемент, программная компонента,
аппаратный блок, персонал и т. п. Структуру системы можно опи¬
сать в терминах диаграммы определения блоков, которая описывает
систему в терминах система — подсистема. Диаграмма внутренних
блоков описывает систему в терминах частей, портов и коннекто¬
ров. Пакетная диаграмма используется для упрощения модели и по
своему назначению совпадает с аналогичной UML диаграммой. Па¬
раметрическая диаграмма позволяет описывать систему ограниче¬
ний, налагаемых на систему (по производительности, надежности,
массе, габаритам и т. п.).
Поведенческие диаграммы описывают динамику (поведение)
системы. Диаграмма вариантов использования позволяет на доста¬
точно высоком уровне описать функциональность системы. Эта ди¬
аграмма идентична соответствующей диаграмме в UML. Диаграмма
активностей позволяет описать поток данных и управление между
активностями. Диаграмма последовательностей описывает взаимо¬
действие между различными подсистемами. Диаграмма конечного
автомата (машина состояний) позволяет описывать систему в тер¬
минах состояний и переходов между состояниями при возникно¬
вении событий. Диаграмма требований позволяет описать требо¬
вания, предъявляемые к системе в графической форме.
Если сравнивать состав моделей UML и SysML, то видно, что
в SysML появляются только две новые модели — это модель тре¬
бований и параметрическая модель. Три диаграммы: диаграмма
вариантов использования, диаграмма последовательностей и ма¬
шина состояний, идентичны соответствующим диаграммам UML.
Прочие диаграммы можно рассматривать как модификации соот¬
ветствующих диаграмм UML [46].
-90-
3
КАКОВЫ МЕТОДОЛОГИИ
АРХИТЕКТУРНОГО ПРОЕКТИРОВАНИЯ
КАКИЕ СУЩЕСТВУЮТ АТРИБУТЫ КАЧЕСТВА ИС
Понятие качества ИС соответствует понятию о том, что систе¬
ма успешно справляется со всеми возлагаемыми на нее задачами,
имеет хорошие показатели надежности, имеет приемлемую стои¬
мость, удобна в эксплуатации и обслуживании, легко сопрягается
с другими системами и в случае необходимости может быть моди¬
фицирована.
Следует заметить, что разные группы заинтересованных лиц
могут иметь свои точки зрения на то, какой должна быть качест¬
венная система.
Поскольку в современных ИС ключевой компонентой является
программная компонента, а пользователи, работающие с системой,
в подавляющем большинстве случаев взаимодействуют непосред¬
ственно с программной компонентой, поэтому показатели качест¬
ва информационных и программных систем в значительной сте¬
пени совпадают.
Качество программного обеспечения (ПО) определяется
в стандарте ISO 9126 [23] как вся совокупность его характеристик,
относящихся к возможности удовлетворять высказанные или по¬
дразумеваемые потребности всех заинтересованных лиц.
Различаются понятия внутреннего качества, связанного с ха¬
рактеристиками ПО самого по себе, без учета его поведения; внеш¬
него качества, характеризующего ПО с точки зрения его поведения;
-91-
3. КАКОВЫ МЕТОДОЛОГИИ АРХИТЕКТУРНОГО ПРОЕКТИРОВАНИЯ
и качества ПО при использовании в различных контекстах — то¬
го качества, которое ощущается пользователями при конкретных
сценариях работы ПО. Для всех этих аспектов качества введены
метрики, позволяющие оценить их. Кроме того, для создания доб¬
ротного ПО существенно качество технологических процессов его
разработки.
ISO 9126 — это международный стандарт, определяющий оце¬
ночные характеристики качества программного обеспечения. Рос¬
сийский аналог стандарта — ГОСТ 28195. Стандарт разделяется на
четыре части, описывающие следующие вопросы: модель качества;
внешние метрики качества; внутренние метрики качества; метри¬
ки качества в использовании.
Вторая и третья части стандарта ISO 9126-2,3 посвящены фор¬
мализации соответственно внешних и внутренних метрик харак¬
теристик качества сложных программных систем. В ней изложены
содержание и общие рекомендации по использованию соответст¬
вующих метрик и взаимосвязей между типами метрик.
Четвертая часть стандарта ISO 9126-4 предназначена для поку¬
пателей, поставщиков, разработчиков, сопровождающих, пользова¬
телей и менеджеров качества ПС. В ней повторена концепция трех
типов метрик, а также аннотированы рекомендуемые виды изме¬
рений характеристик.
Модель качества, установленная в первой части стандарта
ISO 9126-1, классифицирует качество ПО в шести структурных
наборах характеристик:
1) функциональность;
2) надежность;
3) эффективность (производительность);
4) удобство использования;
5) удобство сопровождения;
6) переносимость.
Перечисленные характеристики, в свою очередь, детализиро¬
ваны подхарактеристиками (субхарактеристиками). Ниже приве¬
дены определения этих характеристик и атрибутов по стандарту
ISO 9126:2001.
-92-
Какие существуют атрибуты качества ИС
Функциональность (functionality) определяется как способ¬
ность ПО в определенных условиях решать задачи, нужные поль¬
зователям.
Для данной характеристики выделяются следующие субхарак¬
теристики:
- функциональная пригодность;
- точность;
- способность к взаимодействию;
- защищенность;
- соответствие стандартам и правилам.
Функциональная пригодность (suitability) определяется как
способность решать нужный набор задач.
Точность (accuracy) определяется как способность выдавать
нужные результаты.
Способность к взаимодействию (interoperability) — это спо¬
собность взаимодействовать с нужным набором других систем.
Соответствие стандартам и правилам (compliance) — соот¬
ветствие ПО имеющимся индустриальным стандартам, норматив¬
ным и законодательным актам, другим регулирующим нормам.
Защищенность (security) — способность предотвращать неав-
торизированный, т. е. без указания лица, пытающегося его осуще¬
ствить, и неразрешенный доступ к данным и программам.
Надежность (reliability) — это способность ПО поддерживать
определенную работоспособность в заданных условиях.
Для данной характеристики выделяются следующие субхарак¬
теристики:
- зрелость;
- устойчивость к отказам;
- способность к восстановлению;
- соответствие стандартам.
Зрелость, завершенность (maturity) — величина, обратная ча¬
стоте отказов ПО. Обычно измеряется средним временем работы
без сбоев и величиной, обратной вероятности возникновения от¬
каза за данный период времени.
Устойчивость к отказам (fault tolerance) — способность под¬
держивать заданный уровень работоспособности при отказах и на¬
рушениях правил взаимодействия с окружением.
-93-
3. КАКОВЫ МЕТОДОЛОГИИ АРХИТЕКТУРНОГО ПРОЕКТИРОВАНИЯ
Способность к восстановлению (recoverability) определяет¬
ся как способность восстанавливать определенный уровень рабо¬
тоспособности и целостность данных после отказа, необходимые
для этого время и ресурсы.
Соответствие стандартам надежности (reliability compliance).
Удобство использования (usability), или практичность, опре¬
деляется как способность ПО быть удобным в обучении и использо¬
вании, а также привлекательным для пользователей.
Для данной характеристики выделяются следующие субхарак¬
теристики:
- понятность;
- удобство обучения;
- удобство работы;
- привлекательность;
- соответствие стандартам.
Понятность (understandability) — это показатель, обратный
к усилиям, которые затрачиваются пользователями на восприятие
основных понятий ПО и осознание их применимости для решения
своих задач.
Удобство обучения (learnability) — показатель, обратный уси¬
лиям, затрачиваемым пользователями на обучение работе с ПО.
Удобство работы (operability) — это показатель, обратный уси¬
лиям, предпринимаемым пользователями для решения своих за¬
дач с помощью ПО.
Привлекательность (attractiveness) — это способность ПО быть
привлекательным для пользователей. Этот атрибут добавлен в 2001 г.
Соответствие стандартам определяется как удобство исполь¬
зования (usability compliance).
Производительность (efficiency), или эффективность, — это
способность ПО при заданных условиях обеспечивать необходимую
работоспособность по отношению к выделяемым для этого ресур¬
сам. Можно определить ее и как отношение получаемых с помо¬
щью ПО результатов к затрачиваемым на это ресурсам всех типов.
Для данной характеристики выделяются следующие субхарак¬
теристики:
- временная эффективность;
- эффективность использования ресурсов;
- соответствие стандартам.
-94-
Какие существуют атрибуты качества ИС
Временная эффективность (time behaviour) — способность ПО
выдавать ожидаемые результаты, а также обеспечивать передачу
необходимого объема данных за отведенное время.
Эффективность использования ресурсов (resource utilisa¬
tion) — способность решать нужные задачи с использованием опре¬
деленных объемов ресурсов определенных видов. Имеются в виду
такие ресурсы, как оперативная и долговременная память, сетевые
соединения, устройства ввода и вывода и пр.
Удобство сопровождения (maintainability) определяется как
удобство проведения всех видов деятельности, связанных с сопро¬
вождением программ.
Для данной характеристики выделяются следующие субхарак¬
теристики:
- анализируемость;
- удобство внесения изменений;
- стабильность;
- удобство проверки;
- соответствие стандартам.
Анализируемость (analyzability), или удобство проведения ана¬
лиза, определяется как удобство проведения анализа ошибок, де¬
фектов и недостатков, а также удобство анализа необходимости из¬
менений и их возможных последствий.
Удобство внесения изменений (changeability) — показатель,
обратный трудозатратам на выполнение необходимых изменений.
Стабильность (stability) — это показатель, обратный риску воз¬
никновения неожиданных эффектов при внесении необходимых
изменений.
Удобство проверки (testability) — это показатель, обратный
трудозатратам на проведение тестирования и других видов про¬
верки того, что внесенные изменения привели к нужным резуль¬
татам.
Переносимость (portability) определяется как способность ПО
сохранять работоспособность при переносе из одного окружения
в другое, включая организационные, аппаратные и программные
аспекты окружения.
Иногда эта характеристика называется в русскоязычной ли¬
тературе мобильностью. Однако термин «мобильность» стоит за¬
резервировать для перевода “mobility” — способности ПО и ком¬
-95-
3. КАКОВЫ МЕТОДОЛОГИИ АРХИТЕКТУРНОГО ПРОЕКТИРОВАНИЯ
пьютерной системы в целом сохранять работоспособность при ее
физическом перемещении в пространстве.
Для данной характеристики выделяются следующие субхарак¬
теристики:
- адаптируемость;
- удобство установки;
- способность к сосуществованию;
- удобство замены;
- соответствие стандартам.
Адаптируемость (adaptability) — способность ПО приспосабли¬
ваться к различным окружениям без проведения для этого дейст¬
вий, помимо заранее предусмотренных.
Удобство установки (installability) — это способность ПО быть
установленным или развернутым в определенном окружении.
Способность к сосуществованию (coexistence) — это пособ-
ность ПО сосуществовать с другими программами в общем окру¬
жении, деля с ними ресурсы.
Удобство замены (replaceability) другого ПО данным опреде¬
ляется как возможность применения данного ПО вместо других
программных систем для решения тех же задач в определенном
окружении.
КАКИЕ СТИЛИ ИСПОЛЬЗУЮТСЯ
В ПРОЕКТИРОВАНИИ ИС
Обычно выделяются пять различных подходов к проектирова¬
нию, которые называют также стилями проектирования, кото¬
рые, по существу, определяют группы методологий разработки ПО:
стиль, основанный на календарном планировании (Calendar-driven),
стиль, основанный на управлении требованиями (Requirements-
driven), стиль, в основу которого положен процесс разработки доку¬
ментации (Documentation-driven), стиль, основанный на управлении
качеством (Quality-driven), архитектурный стиль (Architecture-driven).
Основой календарного стиля является график работ. Коман¬
да разработчиков выполняет работы поэтапно. Проектные решения
принимаются из целей и задач конкретного этапа. Слабым местом
-96-
Какие стили используются в проектировании ИС
данного стиля является то, что основные решения принимаются ис¬
ходя из локальных целей, при этом мало внимания уделяется про¬
цессу разработки, разработке документации, созданию стабильных
архитектур и процессу внесения изменений. Все это приводит к вы¬
сокой суммарной стоимости владения в долгосрочном плане. Дан¬
ный стиль считается морально устаревшим, однако многие органи¬
зации продолжают его использовать.
Стиль, основанный на управлении требованиями или черта¬
ми (features), предполагает, что основное внимание уделяется функ¬
циональным характеристикам системы, при этом часто недоста¬
точно внимания уделяется нефункциональным характеристикам,
таким как масштабируемость, портабельность, поддерживаемость,
и другим, определенным в ISO 9126. Проектные решения прини¬
маются преимущественно исходя из локальных целей, связанных
с реализацией тех или иных функций. Данный подход достаточно
эффективен в случае, если требования определены и не изменяют¬
ся в процессе проектирования. Основными недостатками данного
подхода являются следующие: недостаточное внимание уделяет¬
ся требованиям стандарта ISO 9126 (управление качеством); раз¬
рабатываемые архитектуры, как правило, не являются стабильны¬
ми, так как каждая из реализуемых функций отображается на один
или несколько функциональных компонентов. Это обстоятельство
усложняет добавление к системе новых требований. Данный под¬
ход позволяет успешно отслеживать требования в плане реализа¬
ции требуемой функциональности, однако использование его для
долгосрочных проектов является неэффективным.
Стиль, в основу которого положен процесс разработки до¬
кументации, до настоящего времени продолжает использоваться
в правительственных организациях и крупных компаниях. Данный
стиль может рассматриваться как вырожденный вариант стиля, ос¬
нованного на управлении качеством, и ориентирован на разработ¬
ку документации. В качестве основных недостатков данного под¬
хода выделяются следующие: неоправданно много времени и сил
затрачивается на разработку документации в ущерб качеству раз¬
рабатываемого кода. При этом создаваемая документация часто не
используется ни пользователем, ни заказчиком.
Стиль, основанный на управлении качеством, предполагает
самое широкое использование различных мер для отслеживания
-97-
3. КАКОВЫ МЕТОДОЛОГИИ АРХИТЕКТУРНОГО ПРОЕКТИРОВАНИЯ
критичных с точки зрения функционирования параметров. Напри¬
мер, требуется получить время реакции системы на запрос менее
одной секунды или обеспечить среднее время между отказами не
менее 10 лет. В этом случае данные параметры отслеживаются на
всех этапах проектирования систем, и часто это делается в ущерб
другим характеристикам, таким как масштабируемость, простота
сопровождения и т. п. Типовыми проблемами, возникающими при
использовании данного стиля, являются следующие: часто опти¬
мизируются не те параметры, которые должны быть в действитель¬
ности, когда появляются новые требования, бывает очень трудно
изменить функциональность системы. Созданные таким образом
системы обычно не отличаются высоким качеством архитектурных
решений. В целом данный стиль считается консервативным. Его ис¬
пользование может быть оправдано в случае, когда необходимо со¬
здать системы с экстремальными характеристиками.
Архитектурный стиль представляет собой наиболее зрелый
подход к проектированию. В рамках данного стиля во главу угла
ставится создание фреймворков, которые могут быть легко адап¬
тированы ко всем потенциальным требованиям всех потенциаль¬
ных заказчиков. Отличительная особенность данного стиля состо¬
ит в том, что задача проектирования разбивается на две отдельные
подзадачи: создание многократно используемого фреймворка и со¬
здание конкретного приложения (системы) на его основе. При этом
эти две задачи могут решать разные специалисты. Основная цель
создания данного стиля — это устранение недостатков стиля, ос¬
нованного на управлении требованиями. Использование архитек¬
турного стиля позволяет реализовать инкрементное и итеративное
проектирование, т. е. оперативно изменять существующую и добав¬
лять новую функциональность.
О МЕТОДАХ УПРАВЛЕНИЯ ПРОЦЕССОМ
ПРОЕКТИРОВАНИЯ ИС
Ролевые модели в программном проекте. Разработка ИС обыч¬
но осуществляется в рамках какого-либо программного проекта. При
этом можно выделить несколько ситуаций (ролевых моделей).
-98-
О методах управления процессом проектирования ИС
В ролевой модели типа «Заказчик — исполнитель» определены
роли, указанные в ее названии. Заказчик формирует основные ис¬
ходные требования, финансирует разработку и осуществляет при¬
емку готовой системы, а исполнитель выполняет разработку с до¬
стижением определенного уровня удовлетворения ее результатом
со стороны заказчика. Все права на такой программный продукт,
включая все его промежуточные рабочие продукты, как правило,
принадлежат заказчику, а исполнитель лишь получает оговоренную
плату за выполненную работу при ее успешном завершении.
Если система создается для неопределенного круга пользовате¬
лей, т. е. в явном виде заказчик отсутствует, то используется модель
типа «Инициативная разработка». При этом исходные требования
к конечному продукту формирует сам исполнитель, исходя из соб¬
ственного представления о будущих пользователях и их потребно¬
стях. В этом случае права на разработку остаются у исполнителя, ко¬
торый может предоставлять лицензию на использование системы
желающим пользователям на определенных условиях. В этой моде¬
ли появляется «спонсор проекта», в качестве которого обычно вы¬
ступает какой-либо распорядитель бюджета, который принимает
решение о финансировании проекта, его бюджете и сроках испол¬
нения, а также является последней инстанцией в разрешении кон¬
фликтных ситуаций в проекте.
Ролевая модель «Разработка продукта для внутреннего исполь¬
зования» предполагает использовать создаваемый программный
продукт исключительно самим исполнителем без последующего
отчуждения программного продукта. В этом случае сам исполни¬
тель определяет требования к продукту, финансирует его разработ¬
ку (как правило, в расчете на оптимизацию каких-то собственных
производственных процессов) и сохраняет все права на него. В этом
случае также присутствует роль спонсора проекта.
Существуют и другие ролевые модели, которые в большинст¬
ве случаев являются комбинацией перечисленных выше моделей.
Из всех известных моделей наиболее простой является ролевая мо¬
дель «Заказчик — исполнитель». На эту модель будет ориентирова¬
но дальнейшее изложение.
Модели жизненного цикла. Разработка программного продук¬
та, составляющего основу ИС, ведется с использованием определен¬
-99-
3. КАКОВЫ МЕТОДОЛОГИИ АРХИТЕКТУРНОГО ПРОЕКТИРОВАНИЯ
ной методики, выбор которой определяется характеристиками как
разрабатываемой системы, так и самого проекта, включая разме¬
ры разрабатываемой системы, сроки разработки, а также опыт ко¬
манды разработчиков.
Процесс разработки разбивается на фазы (phases) или этапы
(milestones), исполнение которых может совмещаться во времени
и состоять из нескольких более мелких этапов.
На каждом этапе реализуются определенные для этапа дея¬
тельности (activities), результатом которых являются рабочие про¬
дукты (work products) в виде некоторых документов (documents),
создаваемых в ходе их исполнения. В качестве документов могу
выступать: исходный код, отчет о тестировании, отчет об исправ¬
лении дефектов. Рабочие продукты, поставляемые заказчику в хо¬
де проекта, называются поставками (deliverables).
Описанная выше модель может быть реализована разными
способами. Известно, по крайней мере, шесть подходов.
Далее будут рассмотрены шесть различных моделей жизнен¬
ного цикла, отличающихся своими фазами, вариантами деятельно¬
стей и создаваемыми рабочими документами. Однако все они укла¬
дываются в описанную выше обобщенную схему.
Водопадная модель. Идея водопадной (waterfall) модели состо¬
ит в том, что реализуется конвейерный процесс проектирования.
По завершении каждой очередной фазы ее результат «перетекает»
к следующей фазе без возможности возврата к предыдущей фазе.
В рамках водопадной модели процесс разработки разбивает¬
ся на девять фаз:
1) разработка концепции;
2) распределение системных ресурсов (привязка предполагае¬
мой реализации разработанной концепции к системным ресурсам,
необходимым будущей ИС для ее функционирования);
3) разработка требований;
4) проектирование — по разработанной на предыдущей фа¬
зе спецификации требований создается высокоуровневый проект
(архитектура) будущей системы, где, в частности, определяются
-100-
О методах управления процессом проектирования ИС
все ее необходимые крупные модули (подсистемы) и интерфей¬
сы между ними;
5) реализация — разработанные ранее по спецификации требо¬
ваний высокоуровневый проект и при необходимости низкоуровне¬
вые проекты отдельных подсистем превращаются в исходный код
данного программного продукта; т. е. происходят его кодирование
и отладка с получением готового программного продукта;
6) установка;
7) эксплуатация;
8) сопровождение в течение некоторого срока;
9) вывод из эксплуатации.
Водопадная модель проста в использовании, она ясная, под¬
дается жесткому контролю, однако не допускает изменений ни
в требованиях, ни в высокоуровневых спецификациях. В этом со¬
стоит ее основной недостаток, поэтому в настоящее время эта мо¬
дель практически не используется.
Спиральная модель. Спиральная (spiral) модель была предложе¬
на еще в середине 1980-х гг. Основная особенность этой модели со¬
стоит в выделении анализа рисков в отдельные шаги разработки,
которая представляет собой повторяющиеся циклы. При этом каж¬
дый виток начинается с анализа рисков и построения очередного
прототипа системы. После устранения рисков разрабатывается кон¬
цепция, составляются требования.
На следующем витке спирали в свете полученных новых дан¬
ных заново проводится анализ рисков в изменившейся ситуации,
и на основании него, если заказчик соглашается, создается следу¬
ющий прототип. После нескольких итераций на основании нако¬
пленных данных строится уже проект программного продукта, и по
нему после очередного анализа рисков создается действующий ра¬
бочий прототип, который затем превратится в конечный продукт.
Заключительные фазы разработки проходят уже относительно
быстро, так как уже сделано много предварительной работы.
В спиральной модели суммарная стоимость разработки зави¬
сит от числа итераций и при большом числе итераций может ока¬
заться достаточно высокой.
-101-
3. КАКОВЫ МЕТОДОЛОГИИ АРХИТЕКТУРНОГО ПРОЕКТИРОВАНИЯ
Однако за счет постоянного анализа рисков перед каждым
очередным витком спирали заказчик может выявлять ключевые
риски и принимать обоснованное решение о ее продолжении или
завершении с текущим вариантом рабочего прототипа в качест¬
ве результата.
Спиральная модель может рассматриваться как один из «пред¬
ков» таких современных технологий, как технологии SCRUM.
Модель быстрой разработки приложения. Основная идея моде¬
ли быстрой разработки приложений (Rapid Application Development,
RAD) состоит в том, чтобы собирать систему из готовых компонен¬
тов блоков COTS (Commercial Off The Shelf) с большой долей генера¬
ции рабочего кода из высокоуровневых описаний. При этом центр
тяжести разработки переносится на взаимодействие с потенциаль¬
ными пользователями, а на собственно кодирование приходится
минимум затрат времени.
Модель RAD нацелена прежде всего на получение быстрого
результата, хотя созданная система может оказаться далеко не
оптимальной с точки зрения требований по памяти и другим ре¬
сурсам, но при этом система получается быстро и с учетом тре¬
бований пользователей, которые сами принимают участие в их
определении.
V-образная модель. V-образная (V-shaped) модель получила та¬
кое название, потому что авторы изображают ее в форме латин¬
ской буквы V (рис. 3.1). Важное место в этой модели занимает те¬
стирование.
Процесс проектирования начинается с разработки специфика¬
ций и планирования проекта, после чего выполняется анализ тре¬
бований и спецификаций, на котором выявленные требования ана¬
лизируются, проверяются и изучаются. Если эти фазы пройдены
успешно, то процесс переходит в фазу архитектурного (высокоуров¬
невого) проектирования системы на основе требований и специ¬
фикаций, которые к этому моменту уже проверены и утверждены,
а затем на основе высокоуровневого проекта осуществляется пере¬
ход к детальному или низкоуровневому проектированию, а затем
к кодированию.
После фазы кодирования начинается «подъем».
-102-
О методах управления процессом проектирования ИС
Рис. 3.1. V-образная модель
Фаза модульного тестирования проверяет корректность реали¬
зации закодированных модулей, их соответствие низкоуровневому
проекту. Если здесь обнаруживаются ошибки в детальном проекте,
то происходит возврат к фазе детального проектирования, где эти
ошибки исправляются, после повторяются фаза кодирования и мо¬
дульное тестирование, пока все найденные отклонения от деталь¬
ного проекта или ошибки в нем не будут устранены. Таким образом,
фазе модульного тестирования на «подъеме» соответствует фаза де¬
тального проектирования на «спуске».
Следующей фазой на «подъеме» является фаза сборки и ин¬
теграционного тестирования. Поскольку все модули, из которых
собирается система, считаются протестированными, то интегра¬
ционное тестирование на этой фазе проверяет корректность ре¬
ализации интерфейсов между ними и соответствие сборки высо¬
коуровневому проекту. Таким образом, парной фазой на «спуске»
для сборки и тестирования является высокоуровневое проекти¬
рование. При обнаружении несоответствий процесс возвращает¬
ся к фазе высокоуровневого проектирования, в высокоуровневый
проект вносятся соответствующие исправления, и процесс повто¬
ряется от этой фазы.
-103-
3. КАКОВЫ МЕТОДОЛОГИИ АРХИТЕКТУРНОГО ПРОЕКТИРОВАНИЯ
После успешного прохождения фазы сборки и тестирования
«подъем» продолжается далее, на фазу системного тестирования.
Поскольку до этого уже проверены функции модулей, их интерфей¬
сы и соответствие реализации модулей и всей системы детальным
и высокоуровневым проектам, то системное тестирование прове¬
ряет, насколько собранная система удовлетворяет требованиям ис¬
ходных спецификаций.
Параллельная для данной фазы деятельность на «спуске» — это
анализ требований и спецификаций, как они были заданы заказчи¬
ком, а затем доработаны и согласованы. Как и на предыдущих фа¬
зах «подъема», если обнаруживается расхождение со спецификаци¬
ями, то определяются их причины и процесс возвращается на фазу
анализа требований и спецификаций с внесением соответствую¬
щих изменений в спецификацию и повторением «спуска» и после¬
дующего «подъема».
Если, наконец, и фаза системного тестирования завершена
успешно, то процесс переходит на заключительную фазу запуска про¬
дукта в серийное производство и эксплуатацию данной системы.
Если у заказчика появляются новые требования, то открывает¬
ся новый проект.
В отличие от водопадной модели в рамках V-образной модели
в процессе проектирования используют обратные связи, но не по¬
зволяется изменять требования к системе.
Инкрементная модель. Инкрементная (Incremental) модель
внешне имеет достаточно много общего с рассмотренной выше V-
образной моделью, но по своей идее она существенно отличает¬
ся. В основу инкрементной модели положена идея эволюционного
прототипа (evolutionary prototype), которая состоит в том, что про¬
цесс проектирования разбивается на последовательность шагов от
1 до N (рис. 3.2). На первом шаге создается некоторое ядро буду¬
щей системы, в котором реализуется очень ограниченное количе¬
ство функций. На последующих шагах это ядро расширяется до пол¬
ного объема спецификаций, какой задается заранее и неизменен на
протяжении процесса проектирования.
Каждый шаг исполняется по V-образной модели, но с учетом
уже имеющихся наработок на предыдущем шаге. В отличие от обо¬
бщенной модели здесь на первой же фазе каждого шага идет раз¬
-104-
О методах управления процессом проектирования ИС
работка «тестов приемки», которые либо разрабатываются, либо
берутся уже готовыми от заказчика. Таким образом, в отличие от
V-образной модели, в которой приемочное тестирование выполня¬
ется на завершении разработки, при использовании инкрементной
модели вопрос о тестировании системы выходит на первый план.
На начальных шагах эти тесты применяются к продуктам постав¬
щиков и возможных конкурентов, а в конце каждого шага — к оче¬
редной версии разрабатываемого продукта.
Рис. 3.2. Инкрементная модель
Инкрементная модель, которая известна достаточно давно, по¬
служила основой для создания популярной технологии SCRUM [47].
Использование инкрементной технологии позволяет сни¬
зить затраты на достижение начальной работоспособности про¬
граммного продукта, правда с ограниченной функциональностью,
и в определенной степени помогает справиться с проблемой из¬
менения требований в процессе разработки.
Прототипная модель. Идея прототипной модели (prototyping)
состоит в построении «быстрой» частичной реализации системы до
или во время фазы сбора требований. Заказчик или потенциальные
пользователи некоторое время работают с этим прототипом и да¬
ют свои выводы о его сильных и слабых сторонах. Затем по этим за-
-105-
3. КАКОВЫ МЕТОДОЛОГИИ АРХИТЕКТУРНОГО ПРОЕКТИРОВАНИЯ
ключениям изменяются спецификации требований, чтобы отразить
реальные потребности заказчика.
Прототипная модель предполагает, что разработка начинает¬
ся с составления плана, затем делается его быстрый анализ, созда¬
ются базы данных, где будут копиться все данные о проекте и его
рабочих продуктах, разрабатывается пользовательский интерфейс,
и после него разрабатываются прототипы, реализующие те функ¬
ции, которые определяются спецификациями.
Прототипы могут несколько раз перерабатываться и допол¬
няться новой функциональностью.
После того как получен набор прототипов, достаточных для де¬
монстрации требуемой функциональности, и получено их одобре¬
ние заказчика, тогда из последних версий прототипов собирается
конечный продукт, который выдается в качестве результата.
Прототипная модель близка к пошаговой модели, но, в отличие
от нее, строится на непрерывном совершенствовании и расшире¬
нии работающих прототипов отдельных функций с участием заказ¬
чика в их оценивании.
Для быстро устаревающих ИС прототипная модель может
стать удачным решением по соотношению затраты/результат.
Сравнение моделей. Каждая из моделей имеет свои достоин¬
ства и недостатки.
Водопадная модель подходит для небольших проектов с хоро¬
шо определенными требованиями и минимальным взаимодейст¬
вием с заказчиком.
Сильной стороной спиральной модели является работа с риска¬
ми, и она хорошо подходит для сложных проектов с большими не¬
определенностями. Ее можно определить как водопадную модель
с обратными связями.
Быстрая разработка приложений подходит для небольшой
и высокопрофессиональной группы разработчиков, когда требует¬
ся максимально сократить сроки разработки. Это модель требует
прежде всего очень высокой квалификации разработчиков.
V-образная модель достаточно проста в использовании и в ней
делается упор на тестирование через его сопряжение с разработ¬
-106-
О методах управления процессом проектирования ИС
кой; нисходящая и восходящая ветви процесса хорошо согласова¬
ны между собой.
Инкрементная модель позволяет в кратчайшие сроки полу¬
чить действующую систему, которую можно показать заказчику
и получить от него обратную связь. Это важно в случае, если за¬
казчик не может четко сформулировать требования к разрабаты¬
ваемой системе.
Прототипную модель также можно применять в случае, ког¬
да требования к системе не ясны и (или) явно не полны. Созда¬
вая прототипы один за другим, уже в самом начале проекта ис¬
полнитель проясняет для себя и для заказчика все неясные или
упущенные требования. Важным аспектом этой модели являет¬
ся своевременная обратная связь от заказчика. В результате со¬
здается именно то, что ему нужно, хотя в начале заказчик был
не в состоянии исчерпывающим образом сформулировать свои
требования.
В заключение следует заметить, что в реальных организа¬
циях, занимающихся профессиональной разработкой ИС, обыч¬
но применяется какая-то одна модель, чаще всего использует¬
ся Scrum.
Водопадная модель накладывает достаточно жесткие требова¬
ния на организацию процесса разработки, которые позволяют эф¬
фективно организовать работу крупных проектов, разрабатывае¬
мых на заказ. В то же время эти требования могут быть лишними
для небольших команд и компаний, занимающихся продуктовой
разработкой. Для решения этого противоречия предлагается ис¬
пользовать «гибкие» процессы разработки — Scrum, Kanban, Lean
и др. [47]. Наибольшую популярность сейчас завоевал Scrum, поэ¬
тому далее будет рассмотрен он.
Экстремальное программирование. Большое влияние на
развитие гибких процессов оказали практики экстремального
программирования (XP, Extreme Programming), в которых цент¬
ральная роль в разработке отводится разработчикам, а главным
артефактом является удовлетворяющая требованиям заказчика
программа.
-107-
3. КАКОВЫ МЕТОДОЛОГИИ АРХИТЕКТУРНОГО ПРОЕКТИРОВАНИЯ
Концепция XP строится на четырех исходных предпосыл¬
ках [48]:
1) люди и их взаимодействие важнее, чем процессы и среда;
2) работающее ПО важнее, чем исчерпывающая докумен¬
тация;
3) сотрудничество с заказчиком важнее, чем обсуждение ус¬
ловий контракта и соблюдение технического задания;
4) реагирование на изменение важнее, чем следование плану.
Технически экстремальное программирование привнесло та¬
кие практики, как постоянное улучшение кода путем его рефакто¬
ринга (т. е. изменение кода без изменения его функциональности),
разработка модульных тестов, парное программирование, непре¬
рывные сборки и поставки и др. Тем не менее экстремальное про¬
граммирование не является методологией разработки в чистом
виде, правильней рассматривать его как набор хороших практик
разработки. Немаловажным является требование участия в раз¬
работке только опытных разработчиков с высокой мотивацией на
производство продукта.
Scrum. Процессные методологии разработки подразумевают
механистическую модель управления, когда сотрудники рассма¬
триваются как часть большой машины по производству продуктов.
Современный менеджмент активно пользуется системным мышле¬
нием в управлении, при котором ключевая роль в работе отдается
непосредственно исполнителю, которому дается достаточно прав
и обязанностей для самостоятельного принятия решений в рам¬
ках поставленной цели. В разработке ПО данный подход представ¬
лен в виде методологии Scrum. Scrum оперирует всего тремя роля¬
ми: Владелец продукта (Product Owner), Scrum-мастер (Scrum Master)
и член команды [47]. Команда работает итерациями, в конце ка¬
ждой из которых предоставляет готовый к поставке продукт. Зада¬
ча Владельца продукта — составление и поддержка в актуальном
состоянии списка задач, которые команда должна взять в следую¬
щие итерации. При этом Владелец продукта ставит бизнес-задачи,
которые дают бизнес-прирост функционала команды. Scrum-мас¬
тер хоть и рассматривается как отдельная роль, но он является чле¬
-108-
О методах управления процессом проектирования ИС
ном команды (т. е. человек одновременно выполняет две роли). Его
задача — контролировать, что команда придерживается принци¬
пов scrum’а и взятых на себя обязательств по улучшению процес¬
са. В команде нет четко выделенных исполнителей ролей, каждый
член команды может выполнять разные роли. Например, один член
команды может совмещать роли аналитика и тестировщика, а дру¬
гой — программиста и тестировщика. Такие команды называются
кроссфункциональными. Очень важным является аспект доверия
между всеми участниками процесса — заказчик должен доверять
исполнителю, а владелец продукта — команде.
В отличие от проектных видов деятельности Scrum не опери¬
рует временем в астрономических единицах (часы, дни, недели
и т. д.). В нем используются абстрактные единицы объема работ —
story и task points (стори и таск поинты, SP и TP). Владелец продук¬
та за несколько итераций вычисляет объем story point, который ко¬
манда может выполнить в полном составе.
Жизненный цикл состоит из следующих видов деятельности:
1. Проработка задач. Встреча, на которой владелец продукта
вместе с командой обсуждает суть задач и их примерную оценку
в story point. По результатам грумминга у команды должно быть чет¬
кое понимание, что именно нужно сделать истории.
2. Планирование итерации. Перед планированием владелец
продукта выбирает из backlog наиболее приоритетные задачи, ко¬
торые команда должна взять в очередную итерацию. Само плани¬
рование проходит как встреча, на которой команда еще раз, более
тщательно оценивает задачи и фиксирует, какие именно задачи она
обязуется сделать в конце итерации. Тщательность оценки достига¬
ется за счет разбивки историй Владельца продукта на технические
задачи, которые, в свою очередь, могут быть разбиты на подзадачи.
Каждая подзадача оценивается с помощью task point.
3. Спринт. Основной вид деятельности, длится от одной до трех
недель. Во время спринта команда занимается разработкой. Важ¬
ным элементом являются утренние короткие встречи (их длитель¬
ность не должна превышать 15 минут), на которых члены команды
делятся результатами за предыдущий день и планами на новый. Как
-109-
3. КАКОВЫ МЕТОДОЛОГИИ АРХИТЕКТУРНОГО ПРОЕКТИРОВАНИЯ
правило, такие встречи проходят у доски, на которой вывешены за¬
дачи. Доска разбита на несколько вертикальных дорожек: не взята
в работу, взята в работу, выполнена (конкретный набор дорожек вы¬
бирает сама команда). Изначально все задачи находятся на дорожке
«не взята в работу». После завершения работы над задачей она пе¬
ремещается в дорожку «выполнена». Для наглядного отображения
прогресса работы спринта после каждой утренней встречи обнов¬
ляется диаграмма burndown, на которой отмечается количество ре¬
ально выполненных и количество оставшихся taskpoint у команды.
4. Демонстрация результатов спринта. Встреча, на которой
команда показывает свои успехи за прошедший спринт. При этом
на демонстрацию приглашаются все заинтересованные стороны
и в первую очередь — заказчик разработки. Обязательным являет¬
ся присутствие всех членов команды, которые должны видеть ре¬
акцию приглашенных на результаты своей работы.
5. Ретроспектива. Последняя деятельность в итерации. На ре¬
троспективе команда обсуждает, как прошел спринт, и планирует,
как можно улучшить процесс в дальнейшем.
Как правило, демонстрация результатов спринта и ретроспек¬
тива проходят в один день, а на следующий день осуществляются
планирование и запуск новой итерации. В иерархических моделях
управления оценки по трудозатратам дают начальники, и они спу¬
скаются исполнителям как данность. В scrum же, напротив, оцен¬
ки стоимости разработки задач осуществляются непосредствен¬
но исполнителями. При этом обоснованно считается, что быстрее
указанного командой срока задача выполнена быть не может.
DevOps. Термин DevOps является сокращением от англ. Deve¬
lopment and Operations (разработка и эксплуатация) и представля¬
ет собой методологию активного взаимодействия специалистов
по разработке со специалистами по техническому обслуживанию
и взаимную интеграцию их бизнес-процессов с целью повышения
качества продукта и уменьшения совокупной стоимости владения
(Total Cost of Ownership, TCO). Эта методология основана на идее тес¬
ной взаимозависимости создания продукта и эксплуатации про¬
граммного обеспечения и предназначена для эффективной орга¬
низации создания и обновления программных продуктов и услуг.
-110-
О методах управления процессом проектирования ИС
DevOps ориентирована прежде всего на организации, которым
необходимы частые выпуски (релизы) ПО.
Эта методология фокусируется на стандартизации окружений
разработки с целью обеспечения возможности быстрого переноса
программного обеспечения через стадии, способствуя оперативно¬
му выпуску версий. В идеале системы автоматизации сборки и вы¬
пуска должны быть доступны всем разработчикам в любом окру¬
жении, и у разработчиков должен быть контроль над окружением,
а информационно-технологическая инфраструктура должна стано¬
виться более сфокусированной на приложении.
Задача DevOps-разработчиков состоит в том, чтобы сделать
процесс разработки и поставки программного обеспечения согла¬
сованным с эксплуатацией, объединив их в единую команду, что
должно позволить организовать процессы разработки, которые да¬
лее можно автоматизировать.
Современные DevOps-практики включают такие стандартные
принципы, как: автоматизация сборки и тестирование, непрерыв¬
ная интеграция и непрерывная поставка.
Потребность в DevOps родилась из-за растущей популярности
гибкой (agile) методологии разработки, поскольку это привело к уве¬
личению количества выпускаемых версий.
DevOps можно рассматривать как способ организации группо¬
вой работы, поскольку в состав команды входят сотрудники, зани¬
мающиеся разработкой, тестированием и эксплуатацией, но нет
единого инструмента DevOps. Обычно используется некоторый на¬
бор инструментов, состоящий из нескольких инструментов. Как
правило, инструменты DevOps вписываются в одну или несколь¬
ко из этих категорий, что отражает ключевые аспекты разработки
и доставки программного обеспечения.
Считается, что DevOps дает преимущества в управлении выпу¬
ском программного обеспечения для организации путем стандар¬
тизации среды разработки. События можно более легко отслежи¬
вать, а также разрешать документированные процессы управления
и подробные отчеты. Методики DevOps делают простые процессы
более программируемыми и динамическими. С помощью DevOps
можно максимизировать предсказуемость, эффективность, без¬
опасность и ремонтопригодность операционных процессов.
-111-
3. КАКОВЫ МЕТОДОЛОГИИ АРХИТЕКТУРНОГО ПРОЕКТИРОВАНИЯ
Интеграция DevOps предназначена для доставки продукта,
непрерывного тестирования, тестирования качества, разработки
функций и обновлений обслуживания для повышения надежно¬
сти и безопасности и обеспечения более быстрого цикла разработ¬
ки и развертывания.
DevOps дает преимущества в управлении выпуском программ¬
ного обеспечения для организации путем стандартизации среды
разработки. События можно более легко отслеживать, а также разре¬
шать документированные процессы управления и подробные отче¬
ты. Подход DevOps предоставляет разработчикам больше контроля
над средой, предоставляя инфраструктуре более ориентированное
на приложения понимание.
Компании, которые используют DevOps, сообщают о значитель¬
ных преимуществах, в том числе: значительном сокращении вре¬
мени выхода на рынок, улучшении удовлетворенности клиентов,
улучшении качества продукции, более надежных выпусках, повы¬
шении производительности и эффективности, а также увеличении
способности создавать правильный продукт путем быстрого экспе¬
риментирования [49].
Чтобы эффективно использовать DevOps, прикладные про¬
граммы должны соответствовать набору архитектурно значимых
требований, таких как: возможность развертывания, изменяе¬
мость, тестируемость и возможности мониторинга.
Хотя в принципе можно использовать DevOps с любым архитек¬
турным стилем, использование микросервисов, которые будут рас¬
смотрены ниже, становится стандартом. Поскольку размер каждого
сервиса невелик, появляется возможность изменять каждый отдель¬
ный сервис посредством непрерывного рефакторинга, что уменьша¬
ет необходимость в большом объеме повторного проектирования.
Соотношение между понятиями DevOps, «непрерывная достав¬
ка», «непрерывная интеграция» и «непрерывное развертывание» по¬
казано на рис. 3.3. Более подробную информацию можно найти в [50].
Непрерывная доставка, непрерывное развертывание и непре¬
рывная интеграция. В данном случае термин «непрерывность» от¬
носится к изменениям программного обеспечения, которые проис¬
ходят в течение всего цикла жизни ИС.
-112-
О методах управления процессом проектирования ИС
Кодирование
Сборка
Интеграция
Тестирование
Релизы
Развертывание
Функционирование
Гибкое проектирование
^ ь
г
Непрерывная интеграция
^ W
Непрерывные поставки
W
Непрерывное развертывание
^
DevOps
Рис. 3.3. Соотношение между понятиями DevOps
Непрерывная доставка (Continuous delivery). В большинстве
случаев непрерывная доставка — это серия практик, направленных
на то, чтобы обновления программного обеспечения происходи¬
ли практически постоянно. Данные методы гарантируют быстрое
развертывание, не меняя существующий функционал. Непрерыв¬
ная доставка осуществима благодаря различным оптимизациям на
ранних этапах процесса разработки.
Непрерывная доставка поставляет заказчику каждый функци¬
онал постепенно. Это позволяет получить сразу отклик от клиента
и при необходимости сделать некоторые изменения, позволяет опе¬
ративно реагировать на потребности рынка и подстраиваться под
изменение бизнес-стратегии заказчика.
Непрерывная интеграция (Continuous integration) являет¬
ся ключевым компонентом практики «гибкая разработка» (Agile
Development). Основой данной практики является постоянное по¬
падание кода в центральный репозиторий после успешного запу¬
ска тестов. Основной целью непрерывной интеграции являются
поиск и устранение потенциальных проблем как можно быстрее,
улучшение качества ПО и сокращение времени для выпуска об¬
новлений. До того, как непрерывная интеграция стала широко
распространенной, разработчики обычно работали изолировано,
-113-
3. КАКОВЫ МЕТОДОЛОГИИ АРХИТЕКТУРНОГО ПРОЕКТИРОВАНИЯ
а только по окончании работы объединяли свои наработки. Сле¬
дует заметить, что ранее это был очень трудоемкий и длитель¬
ный процесс. Процесс непрерывной интеграции нацелен на ав¬
томатизированную проверку интеграции между изменениями
разработчика и остальным кодом. В этот процесс могут входить
статический анализ кода на уязвимости и несоответствие общим
практикам разработки, сборка приложения и автоматизирован¬
ное тестирование с динамической проверкой на уязвимости. Ав¬
томатизация процессов интеграции позволяет ускорить процесс
разработки, устраняя рутинные операции по ручной проверке
интеграции с остальным кодом и сокращая нагрузку на отдел те¬
стирования благодаря более раннему нахождению проблем ин¬
теграции с остальными частями приложения. Кроме того, у раз¬
работчика исчезает возможность сэкономить себе время, отправив
изменения на тестирование без какой-либо проверки.
Непрерывное развертывание (Continuous deployment). Про¬
цесс непрерывного развертывания нацелен на развертывание но¬
вой версии приложения в окружение эксплуатации или тестирова¬
ния. Обычно этот этап не выделяют как отдельный, а развертывание
включают в процесс доставки.
КАК ПРОИСХОДИТ РАБОТА С ТРЕБОВАНИЯМИ
Какие существуют типы требований
Работа с требованиями является важнейшей составной частью
процесса создания ИС. Это очень непростой этап, и ошибки, допу¬
щенные при определении требований к ИС, очень дорого обходят¬
ся разработчикам, поскольку весь процесс проектирования или его
существенную часть приходится проводить заново.
Следует отметить, что выбор основных архитектурных ре¬
шений осуществляется на этапе формирования требований. Пра¬
вильное определение требований и эффективное управление тре¬
бованиями — это краеугольные камни успеха любого IT-проекта.
-114-
Как происходит работа с требованиями
До настоящего времени сохраняется ситуация, при которой
около 10 % проектов оканчиваются крахом и не менее 20 % су¬
щественно превышают смету расходов по причине неправильно¬
го определения требований к системе [51]. В последние годы пра¬
ктически все разработчики уделяют самое пристальное внимание
работе с требованиями, но ситуацию это не спасает, поскольку де¬
ло не в том, что аналитики не учли требования тех или иных заин¬
тересованных сторон, а в том, что требования постоянно изменя¬
ются. Прежде всего изменяется окружение, в котором работает или
должна работать система: на рынке появляются конкурирующие
продукты, появляются новые ИТ-технологии и т. д. Таким образом,
аналитик, вырабатывающий требования к системе, должен прогно¬
зировать развитие ситуации и учитывать возможность появления
новых требований. Основным документом, регулирующим работу
с требованиями, на момент написания книги является стандарт [52].
Подробное описание возможных подходов к работе с требования¬
ми можно найти в [53, 54, 55].
В соответствии со стандартом [48] требование — это утвержде¬
ние, которое идентифицирует эксплуатационные, функциональные
параметры, характеристики или ограничения проектирования про¬
дукта или процесса, которое однозначно, проверяемо, измеримо
и необходимо для приемки продукта или процесса заказчиком.
Требование должно обладать следующими свойствами:
1. Единичность — требование описывает одну и только одну
сущность.
2. Завершенность — требование полностью определено в одном
месте.
3. Реализуемость — требование может быть исполнимо с учетом
возможностей доступных технологий и ресурсов.
4. Непротиворечивость — требование не противоречит другим
требованиям и соответствует документации.
5. Атомарность — требование нельзя разделить на более мел¬
кие требования.
6. Отслеживаемость — требование полностью или частично со¬
ответствует бизнес-потребностям заинтересованных лиц.
7. Актуальность — требование не стало устаревшим с течени¬
ем времени.
-115-
3. КАКОВЫ МЕТОДОЛОГИИ АРХИТЕКТУРНОГО ПРОЕКТИРОВАНИЯ
8. Недвусмысленность — требование определено без обраще¬
ния к техническому жаргону, акронимам и другим скрытым фор¬
мулировкам. Требование должно выражать объекты и факты, а не
субъективные мнения. Возможна единственная интерпретация тре¬
бования. Определение не должно содержать нечетких фраз. Исполь¬
зование отрицательных и составных утверждений запрещено.
9. Проверяемость — возможность составления теста, с помощью
которого можно проверить, выполнено ли требование.
10. Обязательность — требование представляет собой опреде¬
ленную заинтересованным лицом характеристику, отсутствие ко¬
торой ведет к неполноценности решения, которая не может быть
проигнорирована, однако это не исключает ранжирования требо¬
ваний. Необязательное требование — противоречие самому поня¬
тию требования.
Основные типы требований. На рис. 3.4 приведена укрупнен¬
ная схема классификации требований.
Рис. 3.4. Классификация требований
-116-
Как происходит работа с требованиями
Требования могут быть сформулированы на трех разных уров¬
нях: бизнес-уровне, пользовательском уровне и системном уровне.
Бизнес-требования (business requirements) содержат высокоу¬
ровневые цели организации или заказчиков системы. Как правило,
их высказывают те, кто финансируют проект, покупатели системы,
менеджер реальных пользователей, отдел маркетинга. Бизнес-тре¬
бование — это описание целей, которые должны быть достигнуты
за счет создания системы.
Требования пользователей (user requirements) описывают це¬
ли и задачи, которые пользователям позволит решить система. К от¬
личным способам представления этого вида требований относятся
варианты использования, сценарии, т. е. требования пользователей
описывают то, что они могут делать с помощью системы.
Термином «системные требования» (system requirements)
обозначают высокоуровневые требования как ко всей ИС, так
и к отдельным подсистемам. Системные требования к подсисте¬
мам формируются на основе требований ко всей системе. Систем¬
ные требования формулируются в терминах, которыми пользуют¬
ся разработчики системы.
Можно выделить следующие основные группы источников
требований (заинтересованных сторон): потенциальные пользо¬
ватели ИС, внутренние требования к продукту, внешние требо¬
вания к продукту. Потенциальные пользователи — это те, кто
непосредственно работает или будет работать с системой. Внут¬
ренние требования — это требования организации, например ИС
должна позволить организации выйти на новый для нее рынок.
Это, как правило, бизнес-требования. Доменные требования от¬
ражают требования окружения, в котором работает создаваемая
ИС. Доменные требования формулируются в терминах предмет¬
ной области и могут использовать профессиональную термино¬
логию. Например, это могут быть специфические требования ко
всем системам военного назначения или всем медицинским сис¬
темам. Внешние требования — это требования со стороны госу¬
дарственных и негосударственных организаций. Чаще всего они
выражаются в форме стандартов.
С точки зрения предмета требований их принято делить на
функциональные и нефункциональные требования.
-117-
3. КАКОВЫ МЕТОДОЛОГИИ АРХИТЕКТУРНОГО ПРОЕКТИРОВАНИЯ
Функциональные требования. Функциональные требования
описывают, что должна делать ИС в соответствии с ожиданиями
потенциальных пользователей ИС. Функциональные требования
описываются на языке, понятном пользователю. Обычно основ¬
ные функциональные требования описываются на естественном
языке с использованием терминологии, принятой в соответству¬
ющем бизнес-сообществе. Для описания более тонкого поведения
системы, например работы с исключениями, могут использовать¬
ся и формализованные описания. Функциональные требования ко
всей ИС могут носить разноплановый характер. С одной стороны,
это могут быть требования ко всей системе, а с другой стороны, тре¬
бования, которые относятся к конкретной подсистеме, но являются
важными, с точки зрения конкретного пользователя.
Надо заметить, что формулирование функциональных требо¬
ваний — это процесс, в котором участвуют, с одной стороны, ко¬
нечные пользователи (обычно это их представители, которые уве¬
рены, что знают истинные требования конечных пользователей),
а с другой стороны, представители разработчиков. Часто заказчи¬
ки выдвигают крайне трудно реализуемые требования, а разра¬
ботчики стремятся их интерпретировать таким образом, чтобы их
можно было реализовать максимально просто.
К совокупности функциональных требований предъявляются
два основных требования — список требований должен быть пол¬
ным, а требования не должны быть противоречивыми. Полнота пред¬
полагает, что список требований является исчерпывающим и он не
будет расширяться, а непротиворечивость предполагает, что требо¬
вания не должны быть взаимоисключающими. На первый взгляд
эти требования кажутся естественными и даже тривиальными, но на
практике при проектировании крупных ИС полный перечень непро¬
тиворечивых требований оказывается практически невозможным.
Первая причина состоит в том, что при составлении списка требо¬
ваний, включающего сотни, а иногда и тысячи позиций, очень легко
пропустить те или иные требования. Вторая причина состоит в том,
что список требований обычно готовится некоторой командой, чле¬
ны которой могут иметь свои точки зрения на требуемую функцио¬
нальность, а могут продвигать и собственные интересы.
-118-
Как происходит работа с требованиями
Нефункциональные требования. Это требования, которые на¬
прямую не связаны с конкретными сервисами, которые проектируе¬
мая ИС предоставляет конечному пользователю. Нефункциональные
требования можно рассматривать как ограничения, накладываемые
на конкретные свойства ИС, например требования, связанные с под¬
держанием интерфейсов с определенными внешними системами,
такими как, например, MS Office. К нефункциональным требовани¬
ям относят такие требования, как время реакции, надежность, удоб¬
ство обслуживания и т. п. Такие нефункциональные характеристи¬
ки, как производительность, безопасность, доступность, относятся
ко всей ИС. В определенных ситуациях нефункциональные характе¬
ристики могут оказаться даже более важными, чем функциональные.
Например, если графический редактор не удобен в работе, то
наличие некоторой дополнительной функциональности не сможет
обеспечить его успех на рынке. Иногда бывает трудно определить,
какой именно компонент реализует ту или иную функцию, но еще
труднее это сделать применительно к нефункциональным требо¬
ваниям. Достаточно часто одно функциональное требование может
определить архитектуру всей системы.
Типовая проблема, которая появляется при работе с нефунк¬
циональными требованиями, состоит в том, что очень часто потен¬
циальные пользователи формируют их в форме целей. Например,
пользователь считает, что проектируемая система должна быть про¬
ста в использовании или система должна быть спроектирована та¬
ким образом, чтобы минимизировать ошибки оператора. Очевид¬
но, что проверить, удовлетворяет ли система таким требованиям,
невозможно.
Поэтому при формулировании нефункциональных требова¬
ний, насколько это возможно, надо использовать метрики, кото¬
рые можно проверить.
Например, указанные выше требования можно сформулиро¬
вать следующим образом. Для подготовки оператора достаточно
16-часового курса, после прохождения которого оператор допуска¬
ет в течение смены не более трех ошибок.
Однако на практике потенциальным пользователям бывает
трудно сопроводить свои требования соответствующими метри¬
-119-
3. КАКОВЫ МЕТОДОЛОГИИ АРХИТЕКТУРНОГО ПРОЕКТИРОВАНИЯ
ками, а для таких нефункциональных характеристик часто про¬
сто трудно придумать адекватные метрики. Например, достаточно
сложно определить количественно ремонтопригодность системы.
Пользователи должны понимать, каким образом они могут ин¬
терпретировать подобные метрики в понятных им бизнес-терми¬
нах. Заказчики системы хотят знать, каким образом та или иная
нефункциональная характеристика отобразится на стоимости си¬
стемы. Нефункциональные требования могут быть связаны между
собой и вступать в конфликт между собой и функциональными тре¬
бованиями. Например, в качестве одного из требований безопасно¬
сти выступает требование, в соответствии с которым пользователи
получают доступ к системе только с помощью пластиковой карты,
т. е. все рабочие станции должны иметь картридеры. При этом од¬
новременно требуется, чтобы пользователи могли получать удален¬
ный доступ к системе с помощью принадлежащих им ноутбуков
и планшетов. Очевидно, что для этой группы пользователей при¬
дется обеспечить другой механизм контроля доступа.
При составлении документации по требованиям к системе
не рекомендуется очень жестко разделять функциональные и не¬
функциональные требования, поскольку в этом случае оказыва¬
ется сложно проследить взаимосвязи между ними.
Как реализуется процесс разработки требований
Процесс выработки требований является частью процесса раз¬
работки ИС, который реализуется в рамках четырех основных под¬
процессов [52].
1. Оценка реализуемости (Feasibility study). Оценивается прин¬
ципиальная возможность реализации проекта при существующем
уровне развития технологии, оценка экономической эффектив¬
ности реализации проекта, оценка стоимости работ. На этом эта¬
пе принимается принципиальное решение о возможности постро¬
ения системы с требуемыми характеристиками при существующих
ограничениях.
2. Выделение и анализ требований (Requirements elicitation and
analysis). Это процесс формирования списка требований посред¬
-120-
Как происходит работа с требованиями
ством анализа существующих систем, общения с потенциальными
пользователями. Для формирования списка требований может по¬
требоваться разработка ряда моделей и прототипов.
3. Спецификация требований (Requirements specification). Эту ак¬
тивность можно определить как процесс упорядочения собранной
информации о требованиях.
4. Валидация требований (Requirements Validation). Это актив¬
ность, связанная с проверкой требований на полноту, непротиво¬
речивость и реалистичность, т. е. на наличие реальной потребности.
На этом этапе обнаруживаются разного рода неточности и ошибки
в спецификации требований. Обычно этот процесс носит цикличе¬
ский характер, при этом могут появляться новые требования. Ре¬
зультатом данного этапа является окончательная спецификация
требований.
Обобщенная структура процесса формирования требований
приведена на рис. 3.5.
Рис. 3.5. Обобщенная структура процесса формирования требований
-121-
3. КАКОВЫ МЕТОДОЛОГИИ АРХИТЕКТУРНОГО ПРОЕКТИРОВАНИЯ
Оценка реализуемости. Основная цель данного этапа со¬
стоит в том, чтобы возможно быстрее и дешевле получить от¬
вет на вопрос: можно ли создать ИС с требуемыми характери¬
стиками в установленные сроки с определенным бюджетом. На
входе этого процесса обычно имеем набор бизнес-требований,
обобщенное описание проектируемой системы и определение
ее роли в бизнес-процессах организации. Результатом данно¬
го этапа должен стать отчет, содержащий обоснованные выводы
о возможности и целесообразности реализации системы с уче¬
том предъявляемых к ней требований и ресурсов организации
разработчика.
Сам процесс оценки реализуемости обычно предполагает сбор
информации, ее оценку и написание отчета. В качестве источников
информации могут выступать менеджеры организации заказчика,
потенциальные пользователи, ИТ-специалисты, разного рода экс¬
перты по конкретным вопросам.
Ниже приведен далеко не полный список вопросов, ответы
на которые должны содержаться в отчете.
1. В чем состоят проблемы организации и каким образом со¬
здаваемая система поможет их решить?
2. Какова стоимость перехода на новую систему?
3. Используются ли в системе технологии, ранее не применя¬
емые в организации?
4. Какими будут последствия для организации, если система
не будет создана?
В отчете могут содержаться предложения по изменению со¬
става требований. Обычно процесс оценки реализуемости зани¬
мает не более 2-3 недель.
Выделение и анализ требований. После того, как принято по¬
ложительное решение о создании системы, переходят к процес¬
су выделения и анализа требований. Обычно аналитики работают
с потенциальными пользователями и покупателями и другими за¬
интересованными лицами, такими как бизнес-менеджеры, экспер¬
ты в данной предметной области, т. е. со всеми, кто прямым или
-122-
Как происходит работа с требованиями
косвенным образом определяет требования к системе. Этот про¬
цесс в разных организациях может быть организован по-разному,
в зависимости от типа разрабатываемых ИС и традиций организа¬
ции разработчика.
Обычно процесс выделения и анализа требований имеет ите¬
рационный характер и включает несколько активностей, напри¬
мер это могут быть следующие активности:
1. Выявление требований (Discovery). Процесс взаимодействия
с заинтересованными сторонами с целью выявления их требова¬
ний, а также формулирование доменных требований.
2. Классификация и организация требований (Qassification and
organization). Процесс упорядочения списка выявленных требова¬
ний. Для упорядочения требований обычно используется архитек¬
турная модель, применительно к которой формируются требования
к отдельным подсистемам. На этом этапе разрабатывается архитек¬
турная модель. Таким образом, можно утверждать, что процесс ар¬
хитектурного проектирования и процесс разработки требований —
это, по существу, один и тот же процесс.
3. Согласование требований. Требования отдельных заинтере¬
сованных сторон могут противоречить друг другу. В этом случае не¬
обходимо, чтобы эти заинтересованные стороны согласовали свои
требования.
4. Спецификация требований. Содержание спецификации было
рассмотрено ранее. Следует отметить, что составление специфика¬
ции обычно требует нескольких итераций.
Основные проблемы, которые возникают в процессе выявле¬
ния требований, сводятся к следующим моментам:
1. Заинтересованные стороны часто не могут четко сформули¬
ровать свои требования и начинают выставлять нереалистичные
требования.
2. Потенциальные пользователи формулируют свои требо¬
вания в терминах предметного домена, и аналитикам трудно их
понять.
3. Разные заинтересованные лица формулируют свои термины
в разной форме, от аналитика требуется определить все заинтере¬
сованные стороны и обнаружить конфликты в требованиях.
-123-
3. КАКОВЫ МЕТОДОЛОГИИ АРХИТЕКТУРНОГО ПРОЕКТИРОВАНИЯ
4. Достаточно часто на требования, формулируемые пользова¬
телем, оказывают влияние разного рода политические и личные мо¬
тивы. Например, менеджер может продвигать то или иное решение
с целью укрепить свое положение в организации.
5. Следует иметь в виду, что бизнес-ситуация и, соответствен¬
но, требования к разрабатываемой системе могут измениться, по¬
ка система находится в разработке.
Основными приемами, используемыми на данном этапе, яв¬
ляются: интервьюирование, сценарии вариантов использования.
Интервьюирование. Обычно используется два типа интер¬
вью: в первом случае (закрытое интервью) заинтересованное ли¬
цо отвечает на заранее определенный набор вопросов, а во втором
случае (открытое интервью) список вопросов заранее не опреде¬
ляется. На практике чаще всего используется некоторая смесь ин¬
тервью этих двух типов. Механизм интервью хорошо работает при
выявлении требований конечных пользователей, однако не всег¬
да работает на уровне выявления доменных требований, поэтому
для выявления доменных требований аналитикам приходится ра¬
ботать с документацией.
Сценарии. Конечному пользователю часто бывает проще объ¬
яснить свои требования на конкретных примерах. Сценарии обыч¬
но используются для уточнения деталей того, как пользователь хо¬
тел бы общаться с системой. В качестве языка описания сценариев
обычно используются диаграммы вариантов использования (use
case), входящих с состав UML [56], который будет описан ниже.
В чем заключатеся валидация требований
Валидация — это процесс проверки истинности сформулиро¬
ванного списка требований, т. е. установление того, что выделен¬
ные требования — это действительно требования пользователей.
Валидация — это один из наиболее сложных и трудно формализу¬
емых этапов. На этапе валидации используют следующие основ¬
ные технологии:
1. Рецензирование списка требований несколькими экспертами.
2. Разработка прототипа системы. (Это может быть, например,
модель экранных форм приложения.)
-124-
Как происходит работа с требованиями
3. Оценка возможности создания теста. Каждое требование
должно быть тестируемым. Если не удается составить тест, кото¬
рый может проверить выполнение некоторого требования, то это
может означать, что реализация этого требования может оказаться
очень сложной, поэтому на это требование следует обратить особое
внимание и по возможности реструктуризировать его.
Для чего выполняется
документирование требований
Документирование, или спецификация — это процесс, в ре¬
зультате которого в качестве артефакта появляется документ, в ко¬
тором описывается то, что должны сделать разработчики ИС. В нем
детально описываются как пользовательские, так и системные тре¬
бования. Иногда они интегрируются в единое описание, иногда сна¬
чала излагаются пользовательские требования, а затем подробно
описываются системные требования.
Обычно требования документируются до начала проектиро¬
вания, однако не всегда. При использовании процесса проекти¬
рования, известного как экстремальное программирование [48],
пользовательские требования собираются в процессе проекти¬
рования и постоянно уточняются. Пользователи могут назначать
приоритеты отдельным требованиям. Подобный подход достаточ¬
но хорошо проявляет себя применительно к проектированию от¬
носительно небольших по размеру систем с постоянно меняющи¬
мися требованиями.
Спецификация требований выполняется в интересах нескольких
категорий заинтересованных сторон (stakeholders). В табл. 3.1 приве¬
дены список основных заинтересованных лиц и их интересы приме¬
нительно к списку требований.
Документ, описывающий требования к системе, должен быть
написан таким образом, чтобы он был понятен всем перечислен¬
ным категориям пользователей и отвечал на их вопросы. Это не
всегда просто сделать надлежащим образом.
-125-
3. КАКОВЫ МЕТОДОЛОГИИ АРХИТЕКТУРНОГО ПРОЕКТИРОВАНИЯ
Таблица 3.1
Основные заинтересованные лица и их интересы
№
Заинтересованное лицо
Интерес
1
Покупатель, пользователь
Проверка степени соответствия
потребностям
2
Менеджер проекта
Планирование процесса разработки
3
Программист
Понимание того, какую систему
требуется разработать
4
Специалист по тестированию
Разработка тестов
5
Системный администратор
Понимание структуры системы и того,
как она должна функционировать
В соответствии со стандартом [30] спецификация требований
включает в себя следующие разделы:
1. Преамбула, в которой приводится самая общая информация
о системе, описывается история версий документа и указываются
основные отличия текущей версии от предыдущих версий.
2. Введение, в котором описываются назначение системы, ее
основная функциональность, возможные варианты взаимодейст¬
вия с другими системами и возможные варианты использования.
3. Глоссарий, в котором приводятся определения основных тер¬
минов.
4. Пользовательские требования, описывающие сервисы, пре¬
доставляемые пользователю системой, здесь также описываются
нефункциональные требования. Описание пользовательских тре¬
бований обычно выполняется на естественном языке, понятном ко¬
нечному пользователю. Здесь же перечисляются стандарты, кото¬
рым должна соответствовать разрабатываемая система.
5. Описание системной архитектуры, содержащее высокоуров¬
невое описание системы в терминах основных подсистем и спосо¬
бов их взаимодействия.
6. Системные требования: подробно описываются функцио¬
нальные и нефункциональные требования, определяются интер¬
фейсы с внешними системами.
-126-
Как происходит работа с требованиями
7. Системные модели, описывающие функционирование сис¬
темы и ее взаимодействие с внешним миром. Эти описания ори¬
ентированы на тех, кто должен разрабатывать систему. Они долж¬
ны быть максимально точны и подробны. Для описания системных
моделей могут использоваться объектные модели, модели потоков
данных, семантические модели.
8. Возможные направления эволюции системы: рассматрива¬
ются возможные варианты развития системы, обусловленные
развитием элементной базы, изменениями потребностей поль¬
зователей и т. п. Фактически речь идет о формировании требова¬
ний к следующим поколениям систем данного класса. Основная
цель данного раздела — помочь разработчикам избежать реше¬
ний, которые будут ограничивать возможности системы в плане
модернизации.
9. Приложения, в частности, при проектировании крупных си¬
стем могут содержать описания требований к подсистемам второ¬
го уровня.
10. Индексы — чаще всего это алфавитный указатель использу¬
емых в описании терминов.
Как можно управлять требованиями
Требования к крупномасштабным системам постоянно ме¬
няются. Для этого есть много причин. Во-первых, система знаний
о внешнем мире практически никогда не бывает исчерпывающей,
во-вторых, со временем меняется сама окружающая среда, в-тре¬
тьих, заказчики (покупатели) системы — это не одни и те же люди.
Как правило, закупками занимаются менеджеры, конечные пользо¬
ватели — это специалисты в предметной области, и их понимание
требований может отличаться.
Процесс управления требованиями можно определить как
процесс отслеживания изменений требований к системе. Орга¬
низация этого процесса состоит в том, чтобы организовать по¬
ток запросов на изменение требований от всех заинтересованных
сторон. Этот процесс может стартовать после появления перво¬
го варианта списка требований. Процесс управления требования¬
ми включает три фазы: 1) проблемы и изменение спецификации;
-127-
3. КАКОВЫ МЕТОДОЛОГИИ АРХИТЕКТУРНОГО ПРОЕКТИРОВАНИЯ
2) анализ предлагаемых изменений, включая оценку стоимости
изменений; 3) реализация изменений. При этом в обсуждении
должны принимать участие заинтересованные стороны, которые
являлись инциаторами процесса изменений требований. Фаза
анализа предлагаемых изменений — это, прежде всего, оценка сто¬
имости изменений в денежном и временном исчислении. Содер¬
жание фазы реализации изменений зависит от того, на какой ста¬
дии жизненного цикла находится система. В простейшем случае,
если команда не приступила к проектированию, это может быть
переделка спецификации требований. Если система уже спроекти¬
рована и находится в эксплуатации, то может потребоваться мо¬
дификация системы. В этом случае разрабатывается план перехо¬
да на новую версию системы.
Инструментальные средства поддержки процесса разра¬
ботки требований. На современном уровне развития ИС ана¬
литикам и системным архитекторам необходимо иметь эф¬
фективные средства управления требованиями для выработки
архитектурных решений. Управление требованиями — это про¬
цесс, в рамках которого осуществляются первичное накопление,
формирование, анализ и последующий контроль за реализаци¬
ей потребностей заинтересованных сторон, а также дальней¬
шее управление изменениями информации на протяжении все¬
го жизненного цикла проекта.
КАКИЕ МЕТОДЫ ПРИМЕНЯЮТСЯ
ПРИ АРХИТЕКТУРНОМ ПРОЕКТИРОВАНИИ
Архитектурный процесс описывает разработку проектного
решения, и является основным подпроцессом в проектировании
ПО, и состоит из следующих задач [26]:
- работа с командами сбора требований, которая сфокусирова¬
на на сборе требований от заказчика;
- работа с различными заинтересованными сторонами. Архи¬
тектор должен гарантировать, что интересы каждой из сторон по¬
няты и удовлетворяются проектным решением;
-128-
Какие методы применяются при архитектурном проектировании
- управление командой технического дизайна, которая мо¬
жет состоять из ведущих специалистов групп разработки, сис¬
темных администраторов или других архитекторов (в крупных
проектах);
- взаимодействие с командой управления проектом. Архи¬
тектор тесно взаимодействует с командой управления проек¬
том, помогая в декомпозиции, оценке и планировании работ по
проекту.
Для решения этих задач используется итеративный архитек¬
турный процесс, состоящий из трех видов деятельности (рис. 3.6):
1) определение архитектурных требований, которые будут ве¬
сти архитектурный процесс;
2) разработка проектного решения;
3) валидация (тестирование) проектного решения на удовлет¬
ворение всем требованиям.
Рис. 3.6. Архитектурный процесс
-129-
3. КАКОВЫ МЕТОДОЛОГИИ АРХИТЕКТУРНОГО ПРОЕКТИРОВАНИЯ
При выполнении работ в рамках архитектурного процесса
важно руководствоваться следующими принципами [26, 40]:
- архитектурный процесс ведется на основе запросов от заин¬
тересованных сторон, которые являются ядром процесса. При этом
следует учитывать, что запросы могут противоречить друг другу
и их следует согласовывать между собой;
- должны поддерживаться эффективные коммуникации, в ре¬
зультате которых заинтересованные стороны имеют полное пред¬
ставление о принятых решениях и принципах;
- архитектурные решения и принципы должны исполняться во
время всего процесса разработки ПО;
- архитектурный процесс должен быть структурированным,
с описанием входа, выхода и шагов;
- прагматичный подход к принятию решений — должны учиты¬
ваться внешние факторы (время, нехватка денег и т. п.);
- процесс должен быть достаточно гибким, чтобы его можно
было адаптировать к используемому процессу разработки;
- процесс должен использовать лучшие практики и опираться
на стандарты.
Определение архитектурных требований. Все архитектурные
решения должны приниматься на основе зафиксированных и ран¬
жированных по приоритету требований.
Разработка проектного решения (архитектуры). Любые проект¬
ные решения архитектора должны обосновываться требованиями,
согласованными со списками заинтересованных лиц.
При разработке решения архитектор должен всегда рассма¬
тривать следующие ключевые моменты [40]:
1. Одновременное выполнение задач (синхронизация, плани¬
рование задач по расписанию).
2. Управление событиями.
3. Хранение долго живущих данных.
4. Схема размещения программных компонент на физических
серверах.
5. Управление ошибками и устойчивость к падению.
6. Взаимодействие с пользователем и предоставление данных.
7. Безопасность.
-130-
Какие методы применяются при архитектурном проектировании
Рис. 3.7. Метод attribute driven design
-131-
3. КАКОВЫ МЕТОДОЛОГИИ АРХИТЕКТУРНОГО ПРОЕКТИРОВАНИЯ
Перед разработкой проектного решения полезно создать ме¬
тафору системы, комплексно ее описывающей. Метафора может
быть взята из любой предметной области, главное, чтобы она мак¬
симально соответствовала решению.
Например, для системы обрабатывающей заявки с высокими
требованиями к скорости можно использовать метафору водопро¬
водной системы. Для системы с требованиями к безопасности мо¬
жет подойти метафора крепости с воротами (элементами, в которых
происходит обеспечение безопасности). Хорошая метафора значи¬
тельно улучшает понимаемость архитектуры.
После составления первого варианта высокоуровневого ди¬
зайна архитектуры необходимо осуществить более детальную про¬
работку. При создании окончательного варианта архитектуры не¬
обходимо проработать ее элементы (подсистемы, компоненты)
и удостовериться, что окончательный вариант удовлетворяет всем
предъявляемым требованиям качества. Институт SEI предлагает ме¬
тод attribute driven design [51] — дизайн, ведомый атрибутами. Метод
является рекурсивным и подразумевает последовательную прора¬
ботку элементов до нужной степени детализации. При этом каждый
этап проработки заканчивается проверкой соответствия решения
на предъявляемые требования. Метод состоит из 7 шагов (рис. 3.7):
1. Подтвердить полноту требований. На первом шаге происхо¬
дит проверка списка требований. Все недостаточно проработанные
или не имеющие приоритета требования возвращаются на доработ¬
ку к заинтересованным лицам.
2. Выбрать элемент для декомпозиции. Когда этот шаг выполня¬
ется первый раз, существует лишь один элемент для декомпозиции —
вся система целиком. В ином случае стоит вопрос выбора элемента,
который будет проработан. Следует обращать внимание на факторы:
количество связей элемента с другими элементами (выбирать более
связанные); насколько сложно провести анализ элемента и сколь¬
ко рисков присутствует в этом элементе (выбирать более сложные,
с большим количеством рисков); насколько элемент необходим для
поставки продукта, какую роль он играет в текущем релизе.
3. Определить кандидатов в архитектурные драйвера. Выбира¬
ются требования, которые оказывают влияние на компонент. Для
каждого требования дополнительно к приоритету от заинтересо¬
-132-
Какие методы применяются при архитектурном проектировании
ванных лиц ставится степень влияния на архитектуру. По получен¬
ным приоритетам выбираются 5-6 требований, которые имеют
максимальную оценку по обоим параметрам. Выбранные требова¬
ния называются «кандидаты в архитектурные драйвера». Дальней¬
ший анализ может исключить некоторые выбранные кандидаты из
архитектурных драйверов.
4. Выбрать концепцию дизайна. Первоначально определяются
ключевые нефункциональные требования к элементу (производи¬
тельность, доступность, надежность и т. п.). Далее для каждого требо¬
вания выбирается список способов его удовлетворения. В список мо¬
гут входить архитектурные тактики, имеющиеся на рынке решения,
шаблоны реализации и т. д. Важно для каждого требования найти не¬
сколько способов. Далее составляется и заполняется таблица приня¬
тия решений, в которой каждый выбранный способ рассматривается
с точки зрения каждого архитектурного драйвера. На основе анали¬
за принимается решение о выбранных способах достижения ключе¬
вых требований и осуществляется их документирование. Архитек¬
турное описание содержит типы компонентов и связи между ними.
5. Выделить архитектурные элементы и распределить обязан¬
ности. Для каждого типа компонента выделяется один элемент ре¬
ализации, которому назначаются обязанности, учитывая функцио¬
нальные требования и архитектурные драйвера. При этом требуется
ответить на ряд таких вопросов, как: общее количество экземпля¬
ров компонента, запущенных в режиме выполнения, зависимости
от других компонент, как будет происходит взаимодействие между
компонентами и другие.
6. Определить интерфейсы для выделенных компонент. На осно¬
ве требований, архитектурных драйверов и обязанностей компо¬
нента его элементам назначаются обязанности. Обязанности — это
не просто список названий функций и их параметров, а также опи¬
сание семантики операций, пред- и постусловий, ограничений, об¬
рабатываемой информации и т. д. Также указываются атрибуты ка¬
чества (для каждой операции или всего элемента в целом).
7. Верифицировать и уточнить требования, сделать их ограни¬
чениями для выделенных элементов. Проверка качества проделан¬
ной работы. Проверяется, что все поставленные перед элементом
требования соблюдены, а все обязанности распределены между его
компонентами.
-133-
3. КАКОВЫ МЕТОДОЛОГИИ АРХИТЕКТУРНОГО ПРОЕКТИРОВАНИЯ
Валидация проектного решения (архитектуры). Список тре¬
бований, упорядоченный по приоритетам, дает архитектору воз¬
можность оценивать различные варианты архитектуры по согласо¬
ванным с заинтересованными лицами критериям. Самым сложным
при разработке проектного решения является учет различных огра¬
ничений, которые накладывают требования к информационной си¬
стеме и контекст ее поставки (сроки, бюджет, доступность сотруд¬
ников определенной квалификации и навыков и т. п.).
Для сравнения и выбора наилучшего варианта были разрабо¬
таны разнообразные методы оценки вариантов архитектурного ре¬
шения. Выделяют четыре категории методов оценки [54]:
1) экспертная оценка — эксперт или консультант дает оценку
архитектуре;
2) имитационное моделирование может быть осуществлено на
высокоуровневых прототипах системы. Может использоваться для
оценки таких параметров качества, как производительность, над¬
ежность, корректность;
3) математическое моделирование может быть использовано
для проверки производительности и надежности;
4) на основе сценариев — архитектура проверяется путем вос¬
произведения (возможно, мысленного) различных сценариев. Хо¬
рошо подходит для проверки функциональных и нефункциональ¬
ных требований.
Методы оценки архитектуры на основе сценариев являются
специфичными для деятельности по разработке архитектуры ИС
и были специально разработаны для использования архитектора¬
ми ПО. Поэтому подробней будут рассмотрены именно они.
Первым описанным методом был метод анализа архитекту¬
ры ПО (Software Architecture Analysis Method, SAAM) [26]. Главным от¬
личием от существующих подходов стали отказ от использования
метрик объектно-ориентированного дизайна (сфокусированность,
связность и т. п.) для оценки архитектур в пользу оценки на осно¬
ве сценариев, а также ориентация не только на техническую сторо¬
ну вопроса, но и социальную (организация взаимодействия меж¬
ду заинтересованными лицами). Суть метода показана на рис. 3.8.
-134-
Какие методы применяются при архитектурном проектировании
Рис. 3.8. Метод SAAM
В дальнейшем метод SAAM был заменен на метод анализа ком¬
промиссов архитектуры методом (Architecture Tradeoff Analysis
Method, ATAM) [26]. Исходной предпосылкой метода является кон¬
статация факта наличия компромиссов в любой архитектуре — из¬
менение в одном компоненте архитектуры может затронуть каче¬
ство другого компонента или всей системы в целом. ATAM помогает
идентифицировать такие зависимости между атрибутами и называ¬
ет их «точками компромисса» (tradeoff points). Метод является ите¬
ративным и состоит из 6 шагов, разбитых на четыре этапа (рис. 3.9).
1. Сбор сценариев — базовый для разработки архитектуры шаг,
который заключается в построении приоритезированного списка
сценариев от всех заинтересованных лиц.
2. Сбор требований, ограничений и информации об окружении.
Важно, что вся собранная информация должна в итоге быть пред¬
ставлена как набор атрибутов. Данный шаг выполняется на этапе
сбора архитектурных требований.
3. Описание архитектурного представления. Создается на осно¬
ве требований, сценариев, информации об окружении и подходов
к созданию архитектуры. Архитектура должна быть описана в по¬
нятиях архитектурных элементов, релевантных каждому важному
атрибуту качества. Данный шаг выполняется на этапе разработки
архитектурного решения.
4. Анализ конкретных атрибутов. Для варианта архитектуры
осуществляется определение значений атрибутов качества на ос¬
-135-
3. КАКОВЫ МЕТОДОЛОГИИ АРХИТЕКТУРНОГО ПРОЕКТИРОВАНИЯ
нове выбранных сценариев. На данном шаге все атрибуты анали¬
зируются независимо друг от друга.
5. Определение чувствительных точек. Все моделируемые зна¬
чения, на которые значительно влияют изменения архитектуры,
рассматриваются как чувствительные точки.
6. Определение компромиссов. На данном шаге осуществля¬
ется критическая оценка построенной модели, при этом ана¬
лиз осуществляется с точки зрения взаимного влияния друг на
друга чувствительных точек (т. е. анализируются точки компро¬
миссов).
Рис. 3.9. Метод анализа компромиссов архитектуры
-136-
Что собой представляют основные архитектурные тактики
ЧТО СОБОЙ ПРЕДСТАВЛЯЮТ
ОСНОВНЫЕ АРХИТЕКТУРНЫЕ ТАКТИКИ
Понятие архитектурной тактики. В ряде классических мо¬
нографий, посвященных архитектурному проектированию (АП) [26,
34, 40], используются такие термины, как «архитектурные решения
(architectural tactics)», «сценарии (scenario)», «архитектурные такти¬
ки (architectural tactics)», причем часто в эти термины вкладывает¬
ся разный смысл, поэтому представляется целесообразным опре¬
делить эти термины.
Архитектурные решения (АР) определяются как правило или
множество правил, сформулированных в терминах архитектурно
значимых качественных атрибутов.
АР можно рассматривать как процедурное знание в форме
правил. Архитектурную тактику (architectural tactic, ATAC) можно
определить как АР, принимаемое в определенном контексте с це¬
лью улучшения одного конкретного параметра.
Архитектурный сценарий (architectural scenario) можно опре¬
делить как множество возможных тактик и их комбинаций для
улучшения некоторого архитектурно значимого качественного
атрибута.
Ниже в качестве примера использования архитектурных так¬
тик подробно рассмотрены архитектурные тактики, направленные
на обеспечение двух важнейших архитектурно значимых характе¬
ристик: производительности и доступности.
Тактики управления производительностью. Производитель¬
ность ИС может оцениваться в терминах времени отклика и (или)
пропускной способности (ПС). Тактики обычно принято описывать
в «Стимул — Реакция — Метрика» (рис. 3.10) [26, 40].
Тактики, направленные на повышение производительности,
можно разделить на:
- тактики, направленные на ограничение потребности в ресурсах;
- тактики, направленные на повышение производительности
ресурсов.
На рис. 3.11 приведены тактики управления производитель¬
ностью.
-137-
3. КАКОВЫ МЕТОДОЛОГИИ АРХИТЕКТУРНОГО ПРОЕКТИРОВАНИЯ
Метрики
Побочные эффекты
Рис. 3.10. Тактики управления производительностью
Рис. 3.11. Тактики управления производительностью
-138-
Что собой представляют основные архитектурные тактики
Уменьшение потребности в ресурсах может быть достигнуто
за счет использования следующих тактик: ранжирование и филь¬
трация поступающих логов о событиях и ранжирование запросов;
уменьшение точности моделей, а также за счет контентной и кон¬
текстной адаптации алгоритмов. К основным тактикам, направлен¬
ным на управление ресурсами, можно отнести следующие тактики:
- добавление ресурсов;
- распараллеливание обработки;
- перенесение обработки на более мощные узлы;
- использование более эффективных механизмов диспетчери¬
зации.
Тактики, направленные на повышение доступности. Доступ¬
ность (Availability) является одной из подхарактеристик надежно¬
сти [52]. Доступность определяют как вероятность того, что систе¬
ма находится в исправном состоянии через отношение:
Среднее время между отказами / (Среднее время между отказами +
+ Среднее время ремонта неисправной системы).
Еще один возможный способ для СМ влиять на характери¬
стики надежности НС — это способность предсказывать отказы
(Dependability).
Разные предметные домены используют собственные града¬
ции серьезности отказов.
Обычно отказы принято разделять на критические, серьезные
и незначительные. Применительно к сервисам иногда говорят об
отказах, влияющих и не влияющих на обслуживание. Для систем
с повышенными требованиями к надежности (авиация, космонав¬
тика) используется более тонкая градация:
- катастрофический (catastrophic) — потеря возможности вы¬
полнять критические функции;
- опасный (hazardous) — оказывает большое негативное влия¬
ние на безопасность или производительность;
- существенный (major) — оказывает значительное, но меньшее
воздействие, чем опасный;
- ничтожный (minor) — не оказывает влияния на реализуемую
функциональность, влияет на безопасность, эксплуатацию воздуш¬
ного судна или экипаж.
-139-
3. КАКОВЫ МЕТОДОЛОГИИ АРХИТЕКТУРНОГО ПРОЕКТИРОВАНИЯ
В любом случае оператору требуется знать точное состояние
системы для использования соответствующей стратегии ремонта.
Стратегия может быть автоматизирована или может потребовать
ручного вмешательства.
Одна из ключевых проблем обнаружения неисправностей со¬
стоит в том, что выход из строя одного элемента может привести
к выходу из строя подсистем более высокого уровня, что может
привести к эффекту лавины сообщений об ошибках.
Имеется достаточно много техник для решения этой пробле¬
мы. Одна из наиболее действенных — использование дерева неи¬
справностей (Fault tree analysis), которое позволяет рассчитывать
вероятности появления отказов разного уровня.
На рис. 3.12 показаны архитектурные тактики, направленные на
повышение доступности в формате «Стимул — Реакция — Метрика».
Метрики
Побочные эффекты
Рис. 3.12. Архитектурные тактики, направленные
на повышение доступности
На рис. 3.13 приведена классификация архитектурных так¬
тик, направленных на повышение доступности, они разделяются
на три группы:
1) тактики, направленные на обнаружение ошибок;
2) тактики, направленные на восстановление;
3) тактики, направленные на предотвращение ошибок.
-140-
Что собой представляют основные архитектурные тактики
Тактики, направленные на повышение доступности
Обнаружение
ошибок
/
Восстановление
Предотвращение
ошибок
Пингование
Мониторинг
Взаимопроверка
Метки времени
Мониторинг
по событию (запросу)
Голосование
Самотестирование
Обнаружение
исключений
Починка
Игнорирование
сообщений
об ошибках
Реконфигурация
Деградация
Попытка повтора
Апгрейд ПО
Перезапуск
Активное
резервирование
Перевод
в наблюдаемый
режим
Пассивное
резервирование
Восстановление
внутреннего
состояния
подсистемы
Использование
запчастей
Перезапуск по
уровням
Откатка
Временное отключение
ненадежной
подсистемы
Транзакции
Предсказание ошибок
Подсистема
информирует о своей
ненадежности
Рис. 3.13. Классификация тактик, направленных
на повышение доступности
К первой группе можно отнести, по крайней мере, восемь так¬
тик: пингование, мониторинг, взаимопроверка, метки времени, мо¬
ниторинг по событию, голосование, самотестирование, обнаруже¬
ние исключений. (Это далеко не полный список.)
Пингование представляет собой механизм, который предпола¬
гает периодическую посылку сообщения с целью получения ответа
о состоянии другого элемента системы. Чаще всего это просто эхо.
Мониторинг чаще всего представляет собой процедуру скани¬
рования состояния элементов системы (поллинг). Часто реализует¬
ся как фоновый процесс.
-141-
3. КАКОВЫ МЕТОДОЛОГИИ АРХИТЕКТУРНОГО ПРОЕКТИРОВАНИЯ
Взаимопроверка предполагает использование ресурсов одной
подсистемы для определения состояния элемента системы. Этот
механизм можно рассматривать как обобщение механизма пин¬
гования.
Метки времени или временные метки предполагают формиро¬
вание БП-логов, содержащих информацию о ходе БП.
Мониторинг по событию предполагает запуск процедуры мо¬
ниторинга при получении информации о некотором системном со¬
бытии. В простейшем случае по таймеру запускается один и тот же
тест. В этом случае имеем процедуру мониторинга. Мониторинг по
событию предполагает асинхронный запуск разных тестов.
Голосование предполагает, что параллельно работают несколь¬
ко экземпляров системы (подсистемы) и полученные результаты
сравниваются. В классическом случае имеем три параллельно ра¬
ботающих модуля, что позволяет обнаружить ошибку в работе од¬
ного модуля.
Самотестирование предполагает наличие в составе системы
встроенных систем тестирования (мониторинга).
Обнаружение исключений. Система выдает информацию в ви¬
де логов при срабатывании исключения в исполняемой программе.
Тактики, направленные на восстановление, делятся на две
подгруппы:
1) тактики, направленные на восстановление работоспособ¬
ности;
2) тактики, ориентированные на перезапуск системы.
К первой подгруппе можно отнести следующие тактики:
- активное резервирование;
- пассивное резервирование;
- использование запчастей;
- откатка;
- игнорирование сообщений об ошибках;
- реконфигурация;
- попытка повтора;
- апгрейд ПО.
Активное резервирование предполагает использование не¬
скольких параллельно работающих модулей, но результат берется
только с выходов основного модуля. В случае обнаружения ошибки
система переключится на исправный модуль.
-142-
Что собой представляют основные архитектурные тактики
Пассивное резервирование отличается тем, что резервный мо¬
дуль запускается после обнаружения ошибки в работе основного
модуля.
Использование запчастей (Spare или cold spare) предполагает на¬
личие резервных подсистем, которые могут использоваться при ре¬
ализации процедур реконфигурации. (Эта тактика в большей степе¬
ни направлена на повышение надежности, но не готовности.)
Откатка (Rollback) предполагает возможность вернуться к не¬
которому предыдущему состоянию, которое определяется как кор¬
ректное.
Игнорирование сообщений об ошибках предполагает фильтрацию
поступающих сообщений об ошибках. Позволяет отфильтровать по¬
вторяющиеся сообщения, а также вторичные сообщения. Действен¬
ная тактика для работы с множеством ошибок, являющимся следст¬
вием одной ошибки (лавины).
Реконфигурация представляет собой управляемое изменение
структуры системы. Обычно реконфигурация выполняется либо
с целью частичного сохранения функциональности, либо с целью
контекстной или контентной адаптации.
Попытка повтора предполагает, что при возникновении ошиб¬
ки делается одна или несколько попыток повторить действие.
Апгрейд ПО — установка патчей.
Ко второй подгруппе можно отнести:
- перевод системы в наблюдаемый режим;
- восстановление внутреннего состояния подсистемы;
- перезапуск системы по уровням.
Перевод системы в наблюдаемое состояние представляет собой
тактику, основная идея которой состоит в выборочном наблюдении
за отдельными подсистемами, например за подсистемами, кото¬
рые представляются наименее надежными с точки зрения появле¬
ния ошибки, или подсистемами, которые оказываются в перегру¬
женном состоянии.
Восстановление внутреннего состояния подсистемы предпола¬
гает возможность вернуться к некоторому корректному состоянию,
которое относится к более раннему моменту в прошлом.
Перезапуск по уровням предполагает возможность частичного
перезапуска системы.
-143-
3. КАКОВЫ МЕТОДОЛОГИИ АРХИТЕКТУРНОГО ПРОЕКТИРОВАНИЯ
К тактикам, ориентированным на предотвращение ошибок,
можно отнести следующие основные тактики:
- временное отключение ненадежной подсистемы;
- транзакции;
- предсказание ошибок;
- подсистема информирует о своей ненадежности.
Временное отключение ненадежной подсистемы предполагает, что
система, применительно к которой есть подозрения о возможности
появления ошибки (например, подсистема часто не может выполнить
задание с первой попытки), временно отключается для диагностики.
Транзакции — общеизвестная тактика объединения операторов
в группы с возможностью отката в случае ошибки.
Предсказание ошибок предполагает наличие информации о том,
что параметры подсистемы приближаются к критическим.
Подсистема информирует о своей ненадежности в случае, если
встроенные подсистемы, отвечающие за состояние подсистемы,
определяют, что параметры подсистемы приближаются к критиче¬
ским, информация о ненадежном состоянии отсылается вышесто¬
ящей подсистеме.
Прочие тактики. Описанные выше тактики направлены на
совершенствование наиболее значимых архитектурных характе¬
ристик. Ниже перечисляются характеристики, которые могут в не¬
которых аспектах учитываться на архитектурном этапе проектиро¬
вания. Описания этих тактик можно найти в [40].
Архитектурное проектирование с использованием тактик.
Данный подход является комбинацией достаточно хорошо извест¬
ных подходов, и его можно описать как последовательность актив¬
ностей, показанную на рис. 3.14.
На первом этапе выполняется анализ требований. В зависимо¬
сти от постановки задачи проектирования, требования могут быть
представлены в разной форме.
На данном этапе может потребоваться моделирование с целью
определить степень взаимовлияния параметров. В результате получа¬
ем список требований. После этого требуется ранжировать требования.
На втором этапе выполняется выбор архитектурного паттерна.
Эта процедура не представляет особого труда. В ряде случаев может
использоваться некоторая комбинация паттернов. Объем модели¬
рования обычно небольшой.
-144-
Что собой представляют основные архитектурные тактики
Рис. 3.14. Обобщенный подход к проектированию ИС
Третий этап является самым трудоемким и предусматривает
несколько итераций, которые могут реализовываться в рамках про¬
ектных итераций:
Шаг 1. Формирование ранжированного списка архитектурно
значимых параметров.
Шаг 2. Применение архитектурных тактик для /-го параметра.
Шаг 3. Проверка достижимости /-го параметра.
-145-
3. КАКОВЫ МЕТОДОЛОГИИ АРХИТЕКТУРНОГО ПРОЕКТИРОВАНИЯ
Шаг 4. Пополнение списка побочных эффектов.
Шаг 5. Устранение побочных эффектов.
Шаг 6. Если список архитектурно значимых параметров исчер¬
пан, то переход к шагу 7, иначе переход к шагу 2.
Шаг 7. Если архитектурно значимые параметры могут быть до¬
стигнуты, то конец, иначе изменения параметров и переход к шагу 2.
Возникает очевидный вопрос, связанный с обработкой побоч¬
ных эффектов. Возможны следующие подходы к обработке побоч¬
ных эффектов:
- обрабатывать их по мере появления;
- формировать список побочных эффектов и обрабатывать их
после обработки всех тактик, относящихся к архитектурно значи¬
мым характеристикам.
Использование первого подхода на практике приводит к хао¬
тичному применению тактик, относящихся к разным характерис¬
тикам.
Более четким является второй подход, однако он не всегда при¬
водит к желаемому результату. В случае, когда требования оказыва¬
ются очень жесткими, требуется балансировать требования в руч¬
ном режиме. Как правило, для этого используются методы мозгового
штурма.
О СЕМЕЙСТВАХ И ЛИНЕЙКАХ ПРОДУКТОВ
Архитектура программного обеспечения представляет собой зна¬
чительную инвестицию времени и усилий, обычно разработкой архи¬
тектуры занимаются высокооплачиваемые специалисты, поэтому ес¬
тественно хотеть максимизировать отдачу от этих инвестиций за счет
повторного использования архитектуры в нескольких системах.
Известно много разных подходов к повторному использованию
программных систем и их фрагментов.
Одним из таких подходов является использование концепции
линеек продуктов.
Линейка программных продуктов — «набор систем с интен¬
сивным использованием программного обеспечения, имеющих об¬
щий управляемый набор функций, которые удовлетворяют конк¬
ретным потребностям определенного сегмента рынка или миссии
-146-
О семействах и линейках продуктов
и которые разработаны на основе общего набора основных активов
в установленном порядке» [51].
Концепция состоит в наборе повторно используемых модулей
(называемых основными активами), основанных на общей архи¬
тектуре и программных элементах, которые образуют эту архитек¬
туру. К основным активам также относятся проекты и их документа¬
ция, руководства пользователя, артефакты управления проектами,
такие как бюджеты и графики, планы тестирования программного
обеспечения и тестовые случаи, и многое другое.
Подход к линейке продуктов работает, потому что основные
активы были созданы специально для поддержки нескольких чле¬
нов одного семейства продуктов. Следовательно, их повторное ис¬
пользование происходит быстрее и дешевле, чем создание этих
программных активов для каждого нового продукта или системы
в портфеле организации.
Основные активы, включая архитектуру, обычно проектируют¬
ся со встроенными точками изменения, где их можно быстро адап¬
тировать заранее запланированными способами.
Как только основные активы будут на месте, построение сис¬
темы может быть сведено к четырем моментам:
- получение доступа к соответствующим активам в базе основ¬
ных активов;
- использование точек изменения для их настройки в соответ¬
ствии с требованиями создаваемой системы;
- разработка недостающих модулей;
- сборка системы.
Как правило, базовое приложение, предназначенное для упро¬
щения повторного использования и реконфигурации, включает
в себя (рис. 3.15):
1. Основные компоненты, обеспечивающие поддержку инфра¬
структуры. Они обычно не изменяются при разработке нового эк¬
земпляра линейки продуктов.
2. Настраиваемые компоненты, которые могут быть изменены
и настроены для их специализации в новом приложении. Иногда
можно перенастроить эти компоненты без изменения их кода, ис¬
пользуя встроенный язык конфигурации компонентов.
-147-
3. КАКОВЫ МЕТОДОЛОГИИ АРХИТЕКТУРНОГО ПРОЕКТИРОВАНИЯ
3. Специализированные, специфичные для конкретной области
компоненты, некоторые или все из которых могут быть заменены.
Специализированные компоненты
Конфигурируемые многофункциональные компоненты
Ядро
Рис. 3.15. Базовое приложение, предназначенное для упрощения
повторного использования и реконфигурации
При разработке архитектуры линейки продуктов архитектор
должен учитывать три момента, которые являются уникальными
для архитектуры продуктовой линейки: необходимо определить
точки вариабельности, определить механизмы реализации вариа¬
бельности и оценить архитектуру с точки зрения пригодности для
построения линейки продуктов [51].
Следует заметить, что фреймворки и линейки программных
продуктов имеют много общего. И те, и другие поддерживают об¬
щие архитектуру и компоненты и требуют новой разработки для
создания конкретной версии системы. Основные различия между
этими подходами заключаются в следующем:
1. Фреймворк ориентируется на такие объектно-ориентиро¬
ванные функции, как наследование и полиморфизм, для реали¬
зации расширений фреймворка. Как правило, код фреймворка не
изменяется.
Линейки программных продуктов не обязательно создаются
с использованием объектно-ориентированного подхода. Компо¬
ненты приложения изменяются, удаляются или перезаписывают¬
ся. Нет никаких ограничений, по крайней мере в принципе, для
изменений, которые могут быть внесены.
2. Линейки программных продуктов часто являются приложе¬
ниями для управления оборудованием. Например, может сущест-
-148-
Архитектор ИС: какие к нему предъявляются требования и что входит в его обязанности
вовать линейка программных продуктов для семейства принтеров.
Это означает, что линейка продуктов должна обеспечивать под¬
держку аппаратного взаимодействия. Фреймворк, напротив, обыч¬
но ориентирован на программное обеспечение и, как правило, не
включает компоненты типа драйверов.
3. Линейки программных продуктов состоят из семейства свя¬
занных приложений, принадлежащих одной и той же организации.
Когда создается новое приложение, отправной точкой чаще всего
является ближайший член семейства приложений, а не общее ба¬
зовое приложение.
Основное отличие линеек продуктов от эталонных архитектур
состоит в том, что эталонные архитектуры в отличие от линеек про¬
дуктов не имеют точек вариабельности.
АРХИТЕКТОР ИС: КАКИЕ К НЕМУ
ПРЕДЪЯВЛЯЮТСЯ ТРЕБОВАНИЯ
И ЧТО ВХОДИТ В ЕГО ОБЯЗАННОСТИ
Роль архитектора. Архитектора ИС можно определить как ли¬
цо или группу лиц, ответственных за принятие архитектурных ре¬
шений.
Следует заметить, что при разработке небольших по размеру
систем должность штатного архитектора может отсутствовать, но
архитектурные решения все равно надо принимать.
Когда никто конкретно не определен как архитектор, то кто-
то в команде должен в конечном итоге принимать архитектурные
решения. Такого человека иногда называют случайным архитекто¬
ром. Им не присвоено звание архитектора программного обеспече¬
ния, но они выполняют одни и те же обязанности и принимают од¬
ни и те же решения. Иногда, когда нет архитектора программного
обеспечения, архитектурный дизайн является результатом сотруд¬
ничества между несколькими разработчиками.
Чем меньше и менее сложна создаваемая система, тем мень¬
ше работы у архитектора и тем меньше оснований иметь в проек¬
те должность архитектора.
-149-
3. КАКОВЫ МЕТОДОЛОГИИ АРХИТЕКТУРНОГО ПРОЕКТИРОВАНИЯ
Однако, если проект большой по размеру и (или) сложности,
скорее всего, понадобится профессиональный архитектор или да¬
же команда архитекторов.
Архитекторы программного обеспечения являются технически¬
ми лидерами проекта программного обеспечения и должны быть
привержены проекту независимо от того, какие проблемы возни¬
кают. Они предоставляют технические рекомендации руководству,
клиентам и разработчикам. Как таковые они часто являются связу¬
ющим звеном между техническими и нетехническими ресурсами.
Хотя у архитекторов достаточно широкий круг обязанностей,
главной из них является ответственность за технические аспекты
разрабатываемых ИС. Архитектор в конечном счете несет ответст¬
венность за архитектуру создаваемой ИС, ее проектирование и ар¬
хитектурную документацию.
Архитекторы программного обеспечения обязаны выполнять
различные виды обязанностей, не все из которых являются техни¬
ческими. Архитекторы объединяют свой опыт, знания и навыки,
как технические, так и нетехнические, для выполнения своих обя¬
занностей. Архитектор программного обеспечения должен иметь
четкое представление о разработке программных архитектур, ша¬
блонах архитектуры и передовых методах и, кроме того, должен
обладать способностью предвидеть возможные проблемы и разра¬
батывать архитектуры для их преодоления. На первый взгляд не¬
которые навыки и обязанности архитектора похожи на то, что мог
бы делать ведущий разработчик, но это совсем другая роль. Архи¬
тектор несет большую ответственность, и есть большие ожидания
от того, что архитектор привносит в проект.
Ведущие разработчики обладают большой глубиной знаний
о технологиях, которые они используют в проекте. Они хорошо вла¬
деют языками, инструментами, фреймворками и базами данных,
которые используются в ИС. В то время как архитекторы, как ожи¬
дается, кроме глубины знаний, должны обладать широким кругозо¬
ром. Архитектор должен быть знаком с технологиями, которые в на¬
стоящее время не используются в организации, чтобы принимать
обоснованные решения о проектировании архитектуры.
-150-
Архитектор ИС: какие к нему предъявляются требования и что входит в его обязанности
В идеале разработчики обладают широтой знаний, чтобы
быть в курсе множества решений проблемы и понимать компро¬
миссы между ними. Для архитектора более важно понять, почему
конкретное решение не будет работать, как и понять, почему оно
будет работать.
Если архитектор работает изолированно от команды, то он мо¬
жет создавать архитектуру, основанную на среде идеального мира,
которая на самом деле не отражает реальных сценариев.
Чем больше архитектор работает самостоятельно, изолиро¬
ванно от заинтересованных сторон и других разработчиков, тем
больше вероятность того, что он будет оторван от потребностей
этих людей. В результате он или она могут разрабатывать архитек¬
туры, которые не соответствуют реальным потребностям и требо¬
ваниям различных групп заинтересованных сторон.
Архитекторам следует применять более практический подход.
Обязанности архитектора включают участие в ряде этапов жизнен¬
ного цикла программного обеспечения, но практическая работа по¬
могает избежать потери связи.
Вовлеченный подход поможет вам быть в курсе того, какие про¬
блемы и трудности возникают у разработчиков, может быть, это
именно то, что отсутствует в архитектуре.
В организации не должно быть процессов и (или) организацион¬
ной иерархии, которые отделяют архитектора от заинтересованных
сторон. Их не следует отделять от технической реализации, потому что
это уведет архитектора от технологии и навыков, которые в первую
очередь сделали его хорошим кандидатом на должность архитектора.
Что должны знать архитекторы программного обеспече¬
ния? Ожидается, что разработчики программного обеспечения бу¬
дут обладать навыками и знаниями по различным, не только тех¬
ническим темам, таким как:
- способность обеспечения лидерства;
- быть в состоянии оказывать помощь в управлении проекта¬
ми, включая оценку затрат и усилий;
- участвовать в выборе членов команды;
-151-
3. КАКОВЫ МЕТОДОЛОГИИ АРХИТЕКТУРНОГО ПРОЕКТИРОВАНИЯ
- понимание сферы бизнеса;
- участие в сборе и анализе требований;
- общение с различными техническими и нетехническими за¬
интересованными сторонами;
- иметь видение будущих продуктов.
Технические темы, с которыми должен быть знаком архитек¬
тор ИС, включают:
1) понимание нефункциональных требований и атрибутов ка¬
чества;
2) способность эффективно проектировать архитектуры про¬
граммного обеспечения;
3) понимание закономерностей и передовых методов разра¬
ботки программного обеспечения;
4) обладание глубокими знаниями архитектурных стилей и пат¬
тернов проектирования;
5) быть знакомым с типовыми архитектурными практиками;
6) уметь документировать архитектурные решения;
7) понимать проблемы развертывания и сопровождения ИС;
8) владеть технологиями работы с унаследованными приложе¬
ниями.
Каждая компания предъявляет свои требования к сотрудни¬
кам на различных ролях. Кроме того, понимание ролей может
сильно различаться в разных организациях. Для создания единого
понимания, что должен человек на той или иной позиции и какие
требования к нему предъявлять, разрабатывают фреймворки ком¬
петенций. Понятие компетенций трактуется достаточно широко,
но на текущий момент базовой является модель «Знания — Навы¬
ки — Возможности — Иное» (Knowledge — Skills — Abilities — Others,
KSAO) [57, 58]. В рамках этой модели компетенция описывается как
совокупность характеристик:
- знания — теоретическая подготовка, необходимая для реше¬
ния задач;
- навыки — наблюдаемая компетенция выполнять обученные
действия;
- возможности — выполнение наблюдаемого поведения, кото¬
рое приводит к наблюдаемого продукту;
- другое — иные характеристики.
-152-
Архитектор ИС: какие к нему предъявляются требования и что входит в его обязанности
Навыки архитектора. Хотя работа архитектора традиционно
сосредоточена на технологиях, и почти во всех случаях сам архитек¬
тор имеет хорошую подготовку в области информационных техно¬
логий, однако его роль гораздо шире, чем просто составление тех¬
нических планов и проектов.
Он (она) должен обладать всесторонним пониманием технологий
на высоком уровне, а также реальных проблем и проблем, которые
должна решать система. У архитектора должен быть реальный опыт
проектирования и построения систем, хотя не всегда возможно иметь
прямые практические знания о конкретных технологиях, которые пла¬
нируете использовать в конкретном проекте. Это пример того, когда
следует опираться на опыт специалистов в области технологий.
Помимо знаний в области технологий, вам также необходимо
хорошо понимать сферу бизнеса, в которой работает архитектор.
Хотя ему не нужно понимать каждую деталь каждого процесса, но
нужно понять основные бизнес-процессы и основные типы инфор¬
мации, которые находятся в бизнес-области, а также зависимости,
важность и критичность каждого из них. Эти знания позволят более
эффективно общаться с заинтересованными сторонами, ориенти¬
рованными на бизнес, и позволят принимать более обоснованные
решения о приоритизации и компромиссах.
Также очень важно, чтобы у вас были хорошие кандидаты для дру¬
гих ИТ-ролей, таких как менеджер проекта, аналитик, программист.
Эти навыки включают в себя:
1) сбор информации от широкого круга различных заинтересо¬
ванных сторон с различными интересами и различными уровнями
деловых и технических знаний, нужно уметь следить за тем, что¬
бы во время собеседований они сосредоточились на важных архи¬
тектурных проблемах и при необходимости «углубились» в детали;
2) уметь вести переговоры с целью достижения консенсуса меж¬
ду широким кругом заинтересованных сторон с часто противоре¬
чивыми или несовместимыми интересами;
3) необходимо уметь быстро осваивать незнакомые области
бизнеса и технологии, быстро менять направление, когда это не¬
обходимо, и быть готовым отказаться от своих предвзятых пред¬
ставлений о проблеме или ее решении, но нужно знать, когда нуж¬
но стоять на своем.
-153-
3. КАКОВЫ МЕТОДОЛОГИИ АРХИТЕКТУРНОГО ПРОЕКТИРОВАНИЯ
Приблизительный список обязанностей архитектора будет
включать следующие пункты:
а) убедиться, что область применения, контекст и ограниче¬
ния задокументированы и приняты;
б) принимать решения на системном уровне на основе воз¬
можно более полной наилучшей информации и в соответствии
с потребностями заинтересованных сторон;
в) находить разумные компромиссы, когда потребности заин¬
тересованных сторон находятся в конфликте или несовместимы;
г) собирать и интерпретировать информацию, поступающую
от технических специалистов и специалистов по предметной об¬
ласти, и при необходимости точно представлять ее заинтересо¬
ванным сторонам;
д) определение и документирование архитектуры системы;
е) определение и документирование стратегий, стандартов
и руководящих принципов для руководства построением и раз¬
вертыванием системы.
Специализации архитектора. До сих пор мы рассматривали ар¬
хитектора как специалиста широкого профиля, который занимает¬
ся всеми аспектами разрабатываемой ИС. Это не всегда так, особен¬
но в крупных проектах, где может работать команда архитекторов.
Отдельные члены команды архитекторов могут брать на себя
следующие обязанности:
- архитектор продукта, который отвечает за поставку одного
или нескольких выпусков продукта для внешних клиентов и, как
правило, остается связанным с продуктом в течение нескольких ци¬
клов выпуска; архитектор продукта является ключевым членом ко¬
манды разработчиков продукта и следит за технической целостно¬
стью продукта;
- архитектор домена, который отвечает за бизнес-архитектуру,
архитектуру данных, сетевую архитектуру и так далее; эти специа¬
листы особенно полезны при работе над большими, сложными или
новаторскими системами или для заполнения пробелов в знаниях
архитектора программного обеспечения;
- архитектор инфраструктуры, который отвечает за аппарат¬
ную и программную инфраструктуру, в частности за центры обра¬
-154-
Архитектор ИС: какие к нему предъявляются требования и что входит в его обязанности
ботки данных, серверы, хранилища и резервные копии, настольные
компьютеры, глобальные и локальные сети, офисные периферий¬
ные устройства и т. п.;
- архитектор решений, в отличие от архитектора домена, отве¬
чает за общие вопросы, такие как закупки, укомплектование пер¬
соналом и т. д.;
- корпоративный архитектор несет ответственность за архи¬
тектуру ИС всей организации, включая продажи и маркетинг, ори¬
ентирован на клиентов систем, продуктов и услуг, покупку и счета,
поставку услуги, человеческие ресурсы и так далее.
Трудовые обязанности архитектора информационных сис¬
тем. Архитектор ИС всегда выполняет несколько бизнес-ролей
(business roles). В свою очередь, каждая бизнес-роль описывается
ответственностью, трудовыми функциями (business function) и биз¬
нес-процессами, которые она должна выполнять. В зависимости от
процессов работы организации обязанности архитектора ИС могут
сильно варьироваться.
В Российской Федерации принят профессиональный стандарт
Архитектор Программного обеспечения (утвержден Приказом Мин¬
труда России от 30 августа 2021 г. № 579н). В стандарте описаны тру¬
довые функции, а также умения и знания, которые необходимы для
их успешного выполнения. При разработке стандарта был исполь¬
зован опыт Европейского союза и США.
Профессиональный стандарт вводит три уровня квалификации
архитектора программного обеспечения, от 4-го до 6-го. На 4-м, на¬
чальном, уровне архитектор может создавать проектные решения,
документировать их и планировать их реализацию группой работ¬
ников. При этом деятельность осуществляется под общим руковод¬
ством с самостоятельным решением практических задач. На 5-м
уровне ожидается полная самостоятельность в работе, а также до¬
бавляются функции оценки требований к программному обеспече¬
нию, оценка и выбор архитектурного решения, выделение повторно
используемых компонентов. Участие в разработке может сводиться
к контролю над реализациями. На 6-м, высшем, уровне архитектор
должен давать оценку возможности создания архитектурного проек¬
та, определять цели и ключевые сценарии для архитектурного проек¬
та. На данном уровне квалификации можно ожидать не просто тех¬
-155-
3. КАКОВЫ МЕТОДОЛОГИИ АРХИТЕКТУРНОГО ПРОЕКТИРОВАНИЯ
нологический вариант размещения информационной системы, но
и его технико-экономическое обоснование, включая сравнительный
анализ нескольких вариантов. Отдельно выделяются модернизация
программного обеспечения, внедрение новой системы взамен ста¬
рой. Также архитектор 6-го уровня квалификации осуществляет вы¬
бор средств и технологий разработки программного обеспечения.
В табл. 3.2 приведен список обобщенных трудовых функций
и соответствующий им уровень квалификации.
Таблица 3.2
Обобщенные трудовые функции
и соответствующий им уровень квалификации
Трудовая функция
Уровень
квалификации
Создание вариантов архитектуры программного средства
4
Документирование архитектуры программных средств
4
Реализация программных средств
4
Оценка требований к программному средству
5
Оценка и выбор варианта архитектуры программного
средства
5
Контроль реализации программного средства
5
Контроль сопровождения программных средств
5
Оценка возможности создания архитектурного проекта
6
Утверждение и контроль методов и способов
взаимодействия программного средства со своим
окружением
6
Модернизация программного средства и его окружения
6
В заключение следует сказать, что архитектор является преж¬
де всего техническим лидером, который в конечном счете несет
ответственность за технические решения, архитектуру и ее доку¬
ментацию. Они выполняют ряд обязанностей и, как ожидается, бу¬
дут обладать знаниями по различным темам, как техническим, так
и нетехническим.
-156-
ЧАСТЬ 2
ПЛАТФОРМЫ И ПАРАДИГМЫ,
ИСПОЛЬЗУЕМЫЕ
ДЛЯ ПОСТРОЕНИЯ ИОС
ПОЗНАКОМИМСЯ С КЛАССИЧЕСКИМИ
ПЛАТФОРМАМИ И ПАРАДИГМАМИ
КАК МОЖНО КЛАССИФИЦИРОВАТЬ
АРХИТЕКТУРНЫЕ СТИЛИ
Архитектурный стиль представляет собой обобщение опыта
проектирования ИТ-систем.
Архитектурный стиль обычно определяют как семейство си¬
стем, использующих общие структурно-функциональные решения.
Вместо термина «архитектурный стиль» часто используют тер¬
мин «архитектурный паттерн». Однако следует заметить, что меж¬
ду архитектурными стилями и паттернами имеются определенные
различия. Паттерн можно определить как фрагмент кода на опре¬
деленном языке программирования, а архитектурный стиль пред¬
ставляет собой подход к проектированию.
Несмотря на многочисленные попытки до сих пор отсутству¬
ет единый подход к описанию архитектурного стиля как класса ар¬
хитектур.
Традиционно выделяют 12 базовых архитектурных стилей,
которые принято делить на пять групп (рис. 4.1):
- потоки данных (Data Flow Systems);
- вызов с возвратом (Call-and-Return Systems);
- независимые компоненты (Independent Component Systems);
- централизованные данные (Data-Centric Systems);
- виртуальные машины (Virtual Machines).
-158-
-159-
Рис. 4.1. Классификация архитектурных стилей
Как можно классифицировать архитектурные стили
4. ПОЗНАКОМИМСЯ С КЛАССИЧЕСКИМИ ПЛАТФОРМАМИ И ПАРАДИГМАМИ
К системам, которые работают по принципу потоков данных,
относят два стиля: системы пакетно-последовательной обработки
(Batch Sequential Systems) и системы типа конвейеры и фильтры (Pipe
and Filter Architecture).
К системам, работающим по принципу вызова с возвратом,
относятся четыре стиля: программа-сопрограммы (Main Program
and Subroutines), объектно-ориентированные системы (Object-
Oriented Systems), клиент-серверные системы (Client-Server Systems)
и иерархические многоуровневые системы (Hierarchically Layered
Systems).
К системам, использующим принцип независимых компонен¬
тов, обычно относят два стиля: система взаимодействующих про¬
цессов (Communicating Sequential Processes), системы, управляемые
событиями (Event-Based Systems).
К системам, использующим централизованные хранилища
(репозитории) данных, относят два стиля: системы, основанные
на использовании централизованной базы данных (Database Sys¬
tems), а также системы, построенные по принципу классной доски
(Blackboard Systems).
К системам, использующих принцип виртуальной машины, от¬
носят два стиля: интерпретаторы (Interpreters), системы, основан¬
ные на использовании правил (Rule-Based Systems).
КОГДА ИСПОЛЬЗУЮТСЯ ПОТОКИ ДАННЫХ
В основу функционирования ИС, использующих стиль «пото¬
ки данных», положен принцип конвейерной обработки, сущность
которой состоит в том, что процесс обработки разбивается на от¬
дельные фазы. За выполнение обработки на каждой фазе отвеча¬
ет отдельная подсистема, которая по окончании обработки переда¬
ет результаты следующей подсистеме (ступени). При этом данные
обычно перемещаются в одном направлении — от входов к выхо¬
дам, хотя могут присутствовать и обратные связи. В самом общем
виде идея программного конвейера показана на рис. 4.2.
Укрупненная классификация ИС, построенных по принципу об¬
работки потока данных, приведена на рис. 4.3.
-160-
Когда используются потоки данных
Рис. 4.2. Программный конвейер
ИС, использующие стиль «потоки данных»
Пакетно-последовательная
обработка
Конвейеры и фильтры
1 ~
Многоступенчатый конвейер
обработки данных
Системы доставки контента
1
1
Системы покадровой
Конвейер потока работ
обработки данных
Конвейер слияния данных
Рис. 4.3. Классификация ИС, использующих стиль «потоки данных»
Системы, работающие по принципу потоков данных, можно
разделить на две группы: системы пакетно-последовательной об¬
работки и системы типа конвейеры и фильтры.
Системы пакетно-последовательной обработки можно опре¬
делить как системы, основным назначением которых является
транспортировка данных. В этой группе можно выделить две под¬
группы. В первую подгруппу входят системы, основной функцио¬
нал которых связан с доставкой данных (контента). К этой группе
относятся такие системы, как системы кабельного телевидения,
интернет-вещание. Их основное назначение состоит в том, что¬
бы своевременно без искажений доставить данные адресату. Ти¬
пичные ступени обработки реализуют такие алгоритмы, как коди¬
рование-декодирование, сжатие-восстановление данных, очистка
данных и т. п.
Ко второй группе относятся системы покадровой обработки
данных. Это могут быть, например, системы видеонаблюдения, ко¬
-161-
4. ПОЗНАКОМИМСЯ С КЛАССИЧЕСКИМИ ПЛАТФОРМАМИ И ПАРАДИГМАМИ
торые в простейшем случае просто запоминают покадровые изоб¬
ражения, а в более сложных случаях на конечном этапе могут вы¬
полнять некоторую обработку, например распознавание лиц.
Другой разновидностью систем, использующих архитектурный
стиль «потоки данных», являются системы, работающие по прин¬
ципу «конвейеры и фильтры» (pipes&filters).
Архитектурный стиль «конвейеры и фильтры» близок к си¬
стемам пакетно-последовательной обработки и может рассма¬
триваться как обобщение пакетно-последовательной обработ¬
ки. Система, построенная с использованием стиля «конвейеры
и фильтры», представляет собой множество модулей, каждому из
которых ставится в соответствие один или несколько процессов.
Модули могут быть как одинаковыми, так и разными и могут вы¬
полняться как на одном, так и на различных хостах. Данные с вы¬
ходов одного модуля могут поступать на входы одного или не¬
скольких других модулей (рис. 4.4). Система работает по принципу
конвейера.
Filter
Pipe
—
Filter
Pipe
Filter
W
W
Рис. 4.4. Конвейеры и фильтры
Архитектурный стиль «конвейеры и фильтры» можно разде¬
лить на три подстиля: многоступенчатый конвейер обработки дан¬
ных; конвейер потока работ и конвейер слияния данных.
Многоступенчатый конвейер обработки данных выполняет от¬
носительно несложную обработку. Примерами таких систем могут
служить нейронные сети, где на каждой ступени выполняется от¬
носительно простая обработка. Примером данного подхода может
также служить компилятор (рис. 4.5). На вход компилятора посту¬
пает исходный код компилируемой программы. В качестве перво¬
го фильтра выступает лексический анализатор. В качестве второй
ступени выступает семантический анализатор. В качестве третьей
ступени выступает оптимизатор. В качестве четвертой ступени вы¬
ступает генератор кода. Системы типа конвейеры и фильтры нахо¬
-162-
Когда используются потоки данных
дят также достаточно широкое применение при построении систем
обработки сигналов и изображений.
Рис. 4.5. Компилятор как пример использования стиля
«конвейеры и фильтры»
Второй подстиль — конвейер потока работ — отличается от рас¬
смотренного выше подстиля тем, что отдельным ступеням соответ¬
ствуют более сложные элементы обработки, в качестве которых вы¬
ступают обычно работы. Примером может служить Unix Shell, где
механизм канала оболочки Unix является примером архитектуры
канала и фильтра. Unix использует каналы для подключения про¬
цессов Unix для поддержки односторонней (например, нисходя¬
щей) связи [59]. Задания могут выполняться на разных компьюте¬
рах, имеющих сетевые соединения. Отличительной особенностью
данного подстиля является то, что разделение на отдельные фазы
осуществляется на макроуровне.
Третий подстиль — конвейер слияния данных — характеризует¬
ся тем, что на отдельных этапах обработки происходит преобразо¬
вание «сырых» данных в информацию, а затем преобразование ин¬
формации в знание. Такой механизм называют слиянием данных
(data fusion). В качестве примера рассмотрим достаточно популяр¬
ную /DL-модель, которая часто используется для построения разно¬
го рода систем мониторинга. Модель описывает системы обработки
сигналов и использует шестиступенчатый конвейер [60].
Сырые данные поступают от датчиков. Источники могут быть
локальными, распределенными и внешними. В качестве источни¬
ков могут выступать датчики, базы данных и знаний.
-163-
4. ПОЗНАКОМИМСЯ С КЛАССИЧЕСКИМИ ПЛАТФОРМАМИ И ПАРАДИГМАМИ
В КАКИХ СЛУЧАЯХ ВЫПОЛНЯЕТСЯ
ВЫЗОВ С ВОЗВРАТОМ
Вызов с возвратом представляет собой очень большой подкласс
ИС, в основу функционирования которого положен вызов проце¬
дур. При использовании локальных процедур, которые выполняют¬
ся в том же адресном пространстве, что и основной процесс, приме¬
няется команда вызова с возвратом и возврата из процедуры. Если
вызываемая процедура работает в другом адресном пространстве,
то используется механизм вызова удаленных процедур. При этом
несколько процедур могут выполняться одновременно. Подобный
механизм часто называют режимом синхронного обмена.
Можно выделить, по крайней мере, четыре подхода к реали¬
зации данного стиля (подстиля): программа-сопрограммы (Main
Program and Subroutines), объектно-ориентированные системы
(Object-Oriented Systems), иерархические многоуровневые системы
(Hierarchically Layered Systems), клиент-серверные системы (Client-
Server Systems).
Программа-сопрограммы
Архитектурный стиль «программа-сопрограммы» положен
в основу концепции структурного программирования.
В рамках группы стилей «программа-сопрограммы» можно вы¬
делить, по крайней мере, четыре стиля: простые структурирован¬
ные программы, распределенные структурированные программы,
системы типа ведущий-ведомый и системы типа map reduce.
Простые структурированные программы. Для реализации
этого подхода были созданы такие языки процедурного програм¬
мирования, как ALGOL, FORTRAN, ADA и др. В общем случае проце¬
дуры подпрограммы могут вызываться в произвольном порядке,
уровень вложенности не ограничивается, несколько процедур мо¬
гут выполняться одновременно (рис. 4.6).
Распределенные структурированные программы. Этот стиль
отличается от предыдущего тем, что вместо операторов CALL
и RETURN используются механизмы вызова удаленных процедур.
-164-
В каких случаях выполняется вызов с возвратом
Рис. 4.6. Использование сопрограмм
Ведущий-ведомый. Системы с архитектурой ведущий-ведомый
(master-slave(s)) можно рассматривать как параллельный вариант
архитектуры программа-сопрограмма. Идея состоит в том, что вы¬
деляется основной (координирующий) процесс, который распре¬
деляет работу между одним или несколькими подчиненными про¬
цессами. Когда подчиненный процесс заканчивает свою работу, он
запрашивает у главного процесса дополнительную работу. Для это¬
го требуется соответствующая система маршрутизации, с помощью
которой ведущий знает, где находятся подчиненные устройства, их
конфигурацию и свойства. Модель ведущий-ведомый может быть
реализована в произвольной сети процессоров; она не зависит от
топологии сети.
Эта модель хорошо подходит для задач с интенсивными вы¬
числениями, в которых подчиненные процессы практически не
взаимодействуют или вообще не взаимодействуют. Каждому под¬
чиненному процессу дается отдельная задача для выполнения; он
передает свои результаты главному процессу, когда это сделано.
Это наиболее эффективно, когда связь с подчиненными устройст¬
вами может перекрываться с вычислениями подчиненными про¬
цессами.
Модель ведущий-ведомый отличается от параллельной модели
данных тем, что при использовании параллельной модели данные
распределяются по процессам статическим способом, в то время
-165-
4. ПОЗНАКОМИМСЯ С КЛАССИЧЕСКИМИ ПЛАТФОРМАМИ И ПАРАДИГМАМИ
как модель «ведущий-ведомый» распределяет данные для обработ¬
ки по частям за раз. Это отражает тот факт, что процессы могут раз¬
виваться с разной скоростью.
Основная программа выполняет функции контроллера, кото¬
рый управляет вычислительным процессом, в то время как функ¬
циональность реализуется в сопрограммах. Сопрограммы могут вы¬
полняться как на локальном, так и на удаленном хосте. В последнем
случае речь идет о вызове удаленных процедур. Отличительной осо¬
бенностью данного стиля является то, что программа имеет только
одну нить управления. Данный стиль является, по существу, реали¬
зацией идей структурного программирования. В качестве разно¬
видности стиля «основная программа-сопрограммы» можно выде¬
лить архитектуры типа ведущий-ведомый (Master-Slave Architecture).
Обычно такие архитектуры не выделяют в отдельный стиль и рас¬
сматривают как параллельную версию стиля «Основная програм¬
ма-сопрограммы». Отличительной особенностью данных архитек¬
тур является то, что основная программа и сопрограммы работают
одновременно (параллельно). В данном случае на основную про¬
грамму (Ведущий) возлагаются функции диспетчеризации процес¬
са вычислений. Сопрограмма (Ведомый) получает задание, выпол¬
няет его, а по завершении задания запрашивает Ведомого о новом
задании. Данная архитектура может реализовываться как в рамках
многопроцессорных систем, так и в сетевой среде с произвольной
топологией.
MapReduce. Этот подстиль можно рассматривать как разновид¬
ность подстиля «ведущий-ведомый».
Работа MapReduce состоит из двух шагов: Map и Reduce. На Map-
шаге происходит предварительная обработка входных данных. Для
этого один из узлов, который выполняет функции ведущего (master
node), получает входные данные задачи, разделяет их на части и пе¬
редает ведомым узлам (worker node) для предварительной обработ¬
ки. На Reduce-шаге происходит свертка предварительно обработан¬
ных данных. Главный узел получает ответы от рабочих узлов и на их
основе формирует результат — решение задачи, которая изначаль¬
но формулировалась.
MapReduce-системы предназначены в первую очередь для об¬
работки больших наборов данных. Наборы данных разбивают¬
-166-
В каких случаях выполняется вызов с возвратом
ся на наборы данных меньшего размера, которые называют splits,
и помещаются в глобальную файловую систему. После этого каждый
подчиненный узел обрабатывает один или несколько наборов дан¬
ных и помещает промежуточные результаты в свою локальную фай¬
ловую систему. Ведущий узел собирает данные из локальных фай¬
ловых систем и обрабатывает их. Очевидно, что все ведомые узлы
могут работать независимо друг от друга.
MapReduce может быть применен к большим объемам дан¬
ных, которые могут обрабатываться большим количеством сер¬
веров. При этом сами алгоритмы обычно не очень сложные, типа
выполнить сортировку, найти число появлений слов в тексте и т. п.
Для программирования MapReduce-систем имеются фреймвор-
ки, которые позволяют свести работу программиста к написанию
двух функций: map и функции reduce. Первая размещает данные по
узлам обработки, а вторая определяет характер обработки.
Объектно-базированные системы
Под объектно-базированными системами (Object Based Sys¬
tems) [61] в данном случае понимаются системы, в которых исполь¬
зуются объекты времени выполнения, т. е. приложения, разрабо¬
танные на объектно-ориентированных языках программирования,
и системы, спроектированные с использованием методов и средств
объектно-ориентированного проектирования, далеко не всегда яв¬
ляются объектно-ориентированными с точки зрения архитектур¬
ного стиля.
В рамках архитектурного стиля «объектно-базированные си¬
стемы» можно выделить два основных подстиля: системы распре¬
деленных объектов и распределенные объектно-ориентированные
системы и компонентно-базированные системы.
Распределенные объектно-базированные системы можно
определить как системы, базирующиеся на взаимодействии меж¬
ду объектами, находящимися в разных адресных пространствах
(рис. 4.7).
-167-
4. ПОЗНАКОМИМСЯ С КЛАССИЧЕСКИМИ ПЛАТФОРМАМИ И ПАРАДИГМАМИ
Рис. 4.7. Типовая структура распределенной объектной системы
Идею системы распределенных объектов можно рассматривать
как развитие идеи вызова удаленных процедур. Отличие состоит
в том, что объекты имеют состояние и отдельные объекты, принад¬
лежащие одному и тому же классу, различаются. Удаленная проце¬
дура не помнит истории, а объект «помнит» историю обращений.
Удаленную процедуру достаточно поместить в некоторую точ¬
ку сети и сообщить заинтересованным сторонам адрес, по которо¬
му располагается процедура, и способ обращения к ней. Для рабо¬
ты с удаленными объектами, кроме этого, необходимо обеспечить
возможность создания объекта, получения сведений о его состоя¬
нии, изменения состояния, сохранения состояния объекта и унич¬
тожения объекта.
Система распределенных объектов функционирует следующим
образом (рис. 4.8). На клиентской и на серверной стороне помеща¬
ются клиентская и серверная заглушки соответственно. Клиентскую
заглушку обычно называют прокси (proxy), а серверную — скелето¬
ном (skeleton).
Можно выделить три основных механизма работы с прокси:
1) прокси создаются на этапе проектирования и являются
частью кода клиентского приложения;
2) прокси загружаются с сервера;
3) прокси генерируются при необходимости вызвать метод уда¬
ленного объекта.
-168-
В каких случаях выполняется вызов с возвратом
Клиентская машина
Клиентская машина
Сервер
Клиентская ОС
Серверная ОС
* ' *
Сеть
Объект
Скелетон
Клиент
▼
Прокси
Рис. 4.8. Работа удаленных объектов
Первый вариант самый простой и быстрый, но для его реали¬
зации требуется иметь полную информацию о способе обращения
к серверу на этапе проектирования. Реально это возможно в слу¬
чае, когда клиент и сервер проектируются в рамках одной системы.
Второй способ предполагает, что прокси загружается с внешне¬
го сервера. Следует заметить, что для разных языков и разных плат¬
форм требуется иметь разные прокси. Этот механизм достаточно
хорошо работает, если все клиенты используют одну и ту же плат¬
форму, например /ava-платформу.
В третьем случае прокси создается «на лету». В этом случае
с сервера скачивается сигнатура метода и формируется прокси.
Данный подход предполагает наличие интерпретатора языка опи¬
сания интерфейсов на стороне клиента. Это решение очень гибкое,
но достаточно сложное и медленное.
В качестве примера реально использующейся системы распре¬
деленных объектов можно привести систему, используемую в /ava.
Системы распределенных объектов были достаточно популярны
в конце прошлого века. Их описание можно найти, например, в [61].
-169-
4. ПОЗНАКОМИМСЯ С КЛАССИЧЕСКИМИ ПЛАТФОРМАМИ И ПАРАДИГМАМИ
Компонентно-базированные системы
Понятие компонента. Термин «компонент» в ИТ-отрасли ис¬
пользуется для обозначения различных понятий. Во-первых, можно
выделить аппаратные (hardware components) и программные компо¬
ненты (software components).
Термин «программный компонент» (ПрК) используется для
обозначения двух связанных, но разных понятий. Если речь идет
о программной архитектуре, то под компонентом подразумева¬
ется программный модуль, реализующий некоторую функцию или
набор функций и решающий определенные подзадачи в рамках об¬
щих задач, решаемых системой. Это те компоненты, которые могут
быть изображены на диаграммах компонентов (component diagram)
в языке UML. Если речь идет о компонентных технологиях програм¬
мирования или компонентно-ориентированной (component based)
разработке ПО, то под ПрК понимают объекты со специальными
свойствами. В дальнейшем термин «компонент» будет употреблять¬
ся во втором смысле.
В этом случае понятие ПрК выступает в качестве ключевого
для определения таких понятий, как компонентно-ориентирован¬
ное программирование и компонентно-ориентированный подход
к проектированию ИС.
Согласно [62], ПрК представляет собой структурную единицу
программной системы, обладающую четко определенным интер¬
фейсом, который полностью описывает ее зависимости от контекста.
Можно говорить о следующих основных различиях между ком¬
понентами и объектами:
1) как ПрК, так и объекты ориентированы на повторное исполь¬
зование кода, однако объекты ориентированы преимущественно на
повторное использование на низком уровне, а ПрК — на высокоу¬
ровневое повторное использование кода;
2) ПрК в большей степени ориентированы на интерфейсы, чем
объекты;
3) ПрК разрабатываются в рамках конкретного фреймворка,
а объекты — в рамках конкретного языка программирования;
4) объекты тесно связаны с конкретным языком программиро¬
вания, в то время как ПрК в явном виде не связаны с конкретным
-170-
В каких случаях выполняется вызов с возвратом
языком программирования, но связаны с платформой, а платфор¬
ма может быть связана с конкретным языком, например JEE связа¬
на с Java.
Обычно объекты не являются автономными модулями, кото¬
рые можно легко заменить на другие объекты, поскольку они, как
правило, имеют вложенные объекты, для выполнения процедуры
замены объекта обычно требуется перекомпилировать приложе¬
ние, а для замены компонента часто оказывается достаточно по¬
местить файл, в котором находится исполняемый код, в заданное
место и отредактировать конфигурационный файл [63].
Для функционирования ПрК, как правило, необходимо нали¬
чие соответствующей инфраструктуры, которая позволяет компо¬
нентам находить друг друга и взаимодействовать по определенным
правилам. Набор правил, определяющих интерфейсы ПрК и их реа¬
лизации, а также правил, по которым ПрК работают в системе и вза¬
имодействуют друг с другом, называют компонентной моделью
(component model) [62, 63]. В компонентную модель входят также
правила, регламентирующие жизненный цикл ПрК. Взаимодейст¬
вовать друг с другом могут только ПрК, построенные в рамках од¬
ной модели.
Для работы ПрК необходим некоторый набор базовых служб
(basic services), которые обеспечивают, например, нахождение ком¬
понентов в распределенной среде, обмен данными через сеть.
Набор таких базовых, необходимых для функционирования
большинства компонентов служб вместе с поддерживаемой с их по¬
мощью компонентной моделью называется компонентной сре¬
дой, или компонентным фрейворком (component framework).
Известно достаточно много различных компонентных техно¬
логий. Некоторые из них остались на уровне теоретических иссле¬
дований, однако ряд технологий активно используются на практике
в течение уже многих лет. К последней группе можно отнести такие
компонентно-ориентированные (component based) технологии, как
JavaBeans, EJB, CORBA, ActiveX, VBA, COM, DCOM, .Net-компоненты.
Принципиально мультиагентные технологии также можно рассмат¬
ривать как разновидность компонентных технологий.
-171-
4. ПОЗНАКОМИМСЯ С КЛАССИЧЕСКИМИ ПЛАТФОРМАМИ И ПАРАДИГМАМИ
CORBA. CORBA (Component Object Request Broker Architecture) — это
стандарт, определенный группой компаний OMG (Object Management
Group), который позволяет различным программным компонентам,
написанным на разных языках программирования и работающим
на разных машинах, взаимодействовать друг с другом.
Спецификация CORBA лежит в основе всех стандартов, разра¬
ботанных ОМG, и определяет механизмы взаимодействия прило¬
жений в распределенной системе.
Ключевыми компонентами данного стандарта являются объект¬
ный брокер запросов и язык определения интерфейсов IDL. Следу¬
ющими по важности элементами являются сервис динамического
формирования запросов, репозиторий интерфейсов, сервис дина¬
мической обработки запросов и сервис, обеспечивающий взаимо¬
действие различных брокеров запросов.
Ключевая идея состоит в том, что приложение представляется
в виде множества объектов. Каждый из объектов содержит инфор¬
мацию о возможностях кода и способах его вызова. Объект может
быть вызван локально или через сеть из других приложений или
объектов CORBA.
Обобщенная структура системы, построенной с использовани¬
ем CORBA, показана на рис. 4.9. Основу CORBA-системы составляет
«системная шина», которая позволяет компонентам, реализован¬
ным на разных языках и работающим на разных платформах, на¬
ходить друг друга и взаимодействовать. Эту шину называют броке¬
ром объектных запросов (Common Object Request Broker Architecture)
или просто ORB.
Рис. 4.9. Обобщенная структура системы,
построенной с использованием CORBA
-172-
В каких случаях выполняется вызов с возвратом
Интерфейсы в CORBA определяются средствами языка IDL
(Interface Definition Language — язык описания интерфейса). IDL-
описание используется для генерации кода заглушек для поддер¬
живаемых языков программирования (Java, C++, C, COBOL, Lisp, PL/I,
Smalltalk, Python). Сгенерированный код используется как основа
для доступа к объекту в определенной программной среде.
Данные вызова преобразуются в сетевой формат, сериализу¬
ются с помощью сгенерированных для объекта заглушек (Stubs)
и передаются клиентским ORB (Object Request Broker — посредник
вызова объектов) серверному ORB. На сервере данные вызова де¬
сериализуются с помощью сгенерированных для объекта скелето¬
нов (Skeletons), где вызов выполняется. Данные, полученные при об¬
работке вызова, передаются по цепочке обратно клиентскому коду.
Архитектура CORBA. Глобальная архитектура CORBA восхо¬
дит к модели Object Management Group (OMG), в рамках которой вы¬
деляются четыре группы архитектурных элементов (рис. 4.10):
1) брокер объектных запросов;
2) сервисы CORBA;
3) средства CORBA;
4) прикладные объекты и приложения.
Рис. 4.10. Группы архитектурных элементов CORBA
-173-
4. ПОЗНАКОМИМСЯ С КЛАССИЧЕСКИМИ ПЛАТФОРМАМИ И ПАРАДИГМАМИ
Брокер объектных запросов (Object Request Broker — ORB) опре¬
деляет объектную шину CORBA, сервисы CORBA (CORBA Services)
определяют системный уровень объектной структуры и могут рас¬
сматриваться как расширение объектной шины, общие средства
CORBA (CORBA Facilities) определяют сервисы, которые непосредст¬
венно используются приложениями (бизнес-объектами), Application
Objects представляют прикладные объекты и приложения, то есть
конечных потребителей инфраструктуры CORBA.
Каждый нижележащий уровень выступает как сервер для вы¬
шележащего.
В настоящее время CORBA практически не используется. Ее
вытеснили СОА.
Клиент-серверные системы можно рассматривать как специаль¬
ный случай стиля «Основная программа-сопрограммы». Основное
отличие состоит в том, что клиент и сервер находятся на разных хо¬
стах, хотя, в принципе, клиент и сервер могут работать на одном хо¬
сте. Клиент — это процесс, который формирует запрос на обслужива¬
ние. Сервер — это процесс, который реализует сервис. В простейшем
случае клиент посылает серверу команды, ожидает окончания вы¬
полнения запроса. Результатом выполнения запроса могут быть ли¬
бо данные, либо подтверждение выполнения команды. Большинст¬
во серверов работает с множеством клиентов. Широко используемая
разновидность клиент-серверных систем — транзакционные систе¬
мы, к которым могут быть отнесены, например, системы продажи би¬
летов. В системах, ориентированных на выполнение транзакций, чи¬
сло и типы транзакций фиксированы. Серверы в клиент-серверных
системах при увеличении числа запросов могут масштабироваться.
Принято выделять два типа клиент-серверных систем: системы
с толстым и тонким клиентом. Толстым называют клиентское при¬
ложение, которое содержит наряду с кодом, отвечающим за пред¬
ставление данных, достаточно большой объем кода, реализующего
бизнес-логику. Тонкий клиент содержит код, который реализует ис¬
ключительно функции, связанные с представлением информации.
Обычно тонкий клиент — это веб-браузер. Каждый из этих подхо¬
дов имеет собственные достоинства и недостатки. Например, при
использовании тонкого клиента достаточно просто модифициро¬
-174-
В каких случаях выполняется вызов с возвратом
вать код приложения, поскольку нет необходимости обновлять код
на многочисленных клиентских хостах. Код сервера обычно орга¬
низуется по принципу супервизор-рабочие процессы. Супервизор
обслуживает единую точку доступа к сервисам. Рабочие процессы
обрабатывают каждый конкретный запрос.
Обычно реализуется следующий алгоритм:
1. Сервер открывает «хорошо известный порт».
2. Сервер принимает запросы к открытому порту.
3. При поступлении запроса сервер передает его одному из
рабочих процессов и ожидает следующего запроса.
Клиент-серверные архитектуры имеют несколько разновидно¬
стей. Большинство ранних версий клиент-серверных приложений
имели двухслойную организацию, в которой на сервере размещался
репозиторий данных (рис. 4.11). Бизнес-логика размещалась в кли¬
ентском приложении, на сервере или была разделена между клиен¬
том и сервером.
Сервер
Управление данными
i
Логика приложения
Логика представления
Клиент
Рис. 4.11. Двухслойная организация клиент-серверной архитектуры
-175-
4. ПОЗНАКОМИМСЯ С КЛАССИЧЕСКИМИ ПЛАТФОРМАМИ И ПАРАДИГМАМИ
Трехслойная архитектура отличается от двухслойной тем, что
бизнес-логика размещается на отдельном сервере. Процессы ста¬
новятся более устойчивыми, поскольку работают независимо как
от клиентов, так и от серверов (рис. 4.12).
Сервер данных
Управление данными
Логика приложения
1
Сервер приложений
1
i
1
Логика приложения
■X
Логика представления
Клиент
Рис. 4.12. Трехслойная организация клиент-серверной архитектуры
Иногда используется и четырехслойная архитектура, которая
может включать, например, следующие слои: контроллер домена,
веб-сервер, сервер приложений, сервер баз данных. Сервер может
общаться с клиентом как с установлением соединения, например
по протоколу TCP/IP, так и без установления соединения, например
по протоколу UDP. Сервер может либо сохранять, либо не сохранять
информацию об обслуживаемом клиенте. Информацию о клиенте
-176-
В каких случаях выполняется вызов с возвратом
в этом случае называют состоянием. Информация о состоянии мо¬
жет быть полезна, если сеанс работы с клиентом включает обмен
несколькими сообщениями.
Иерархические системы
Иерархические многоуровневые системы используются преиму¬
щественно для построения крупномасштабных приложений. Систе¬
ма представляет собой несколько слоев. Каждый слой можно рассма¬
тривать как виртуальную машину для вышележащего слоя. Каждый
из слоев можно рассматривать также как набор сервисов для выше¬
лежащего слоя, таким образом, вышележащий слой работает в ре¬
жиме клиента, а нижележащий — сервера. Обычно каждый из сло¬
ев взаимодействует с соседними слоями через четко определенные
интерфейсы. Данный стиль повсеместно используется для построе¬
ния стеков протоколов, в частности коммуникационных протоколов.
Другим возможным применением данного стиля являются ОС.
На рис. 4.13 показана структура ОС, имеющей трехуровневую орга¬
низацию.
Рис. 4.13. Операционная система с трехуровневой организацией
-177-
4. ПОЗНАКОМИМСЯ С КЛАССИЧЕСКИМИ ПЛАТФОРМАМИ И ПАРАДИГМАМИ
Система включает три уровня: уровень ядра системы, уровень
системных утилит и уровень, на котором работает прочее про¬
граммное обеспечение.
О НЕЗАВИСИМЫХ КОМПОНЕНТАХ
К системам, работающим по принципу независимых компонен¬
тов, обычно относят системы взаимодействующих процессов и сис¬
темы, управляемые событиями. Такие системы обычно называют
слабо связанными системами, в отличие от систем, работающих
по принципу «вызов с возвратом», которые обычно называют силь¬
но связанными системами. Можно считать, что отличительной
особенностью этой группы стилей являются относительно слабые
связи между отдельными подсистемами. В ИС, которые могут быть
отнесены к системам, построенным по принципу независимых
компонентов, для реализации взаимодействий между подсистема¬
ми и для взаимодействия с внешним миром используются преиму¬
щественно асинхронные механизмы взаимодействия, как напри¬
мер сообщения.
Однако с точки зрения подходов к реализации эти системы до¬
статочно сильно различаются.
Системы, использующие архитектурный стиль «взаимодейст¬
вующие процессы», реализуются как множество процессов, кото¬
рые в общем случае работают на разных хостах. Для реализации
взаимодействий могут использоваться такие стандартные меха¬
низмы межпроцессорного взаимодействия, как сигналы, каналы,
сообщения, разделяемая память, семафоры, сокеты, вызовы уда¬
ленных процедур.
В отличие от систем, использующих архитектурный стиль «вза¬
имодействующие процессы», системы, построенные с использова¬
нием стиля «системы, управляемые событиями», являются система¬
ми, предназначенными для обработки информации о поступающих
событиях. В основе своей это асинхронные системы, которые во
многом напоминают механизмы прерываний, используемые на ап¬
паратном уровне.
-178-
О независимых компонентах
Взаимодействующие процессы
Взаимодействующие процессы и системы, управляемые собы¬
тиями, объединяет то, что в обоих случаях используется механизм
неявного вызова оператора. Другими словами, вызывающий и вы¬
зываемый оператор могут существовать независимо и могут быть
распределены по разным хостам. В системах, управляемых события¬
ми, компоненты могут не знать о существовании друг друга. Актива¬
ция оператора происходит по получении информации о наступлении
события. Системы, управляемые событиями, могут основываться на
использовании механизма «публикация-подписка».
В самом общем виде идея взаимодействующих процессов со¬
стоит в том, что имеется множество независимых процессов, ко¬
торые обмениваются сообщениями.
Эта модель была предложена и разработана еще в 1970-х гг.
Хоаром и имеет множество вариантов реализаций, наиболее по¬
пулярными из которых являются микроядерные архитектуры, па¬
раллельные системы, основанные на обмене сообщениями, а так¬
же мультиагентные системы.
Системы, управляемые событиями
Отличительной особенностью систем, управляемых события¬
ми, является то, что процесс обработки запускается только тогда,
когда происходит соответствующее событие. Событие обычно опре¬
деляют как значимое изменение состояния системы или контекста.
Термин «событие» может использоваться как применительно к не¬
которому классу или типу событий, так и для определения отдель¬
ного экземпляра этого класса, т. е. конкретного события.
Следует отметить, что не всякое изменение состояния систе¬
мы является событием. Событиями являются только те изменения,
которые представляют интерес для тех или иных заинтересован¬
ных сторон, в частности отдельных подсистем.
-179-
4. ПОЗНАКОМИМСЯ С КЛАССИЧЕСКИМИ ПЛАТФОРМАМИ И ПАРАДИГМАМИ
Системы, управляемые событиями, имеют много общего с про¬
граммами, работающими от прерываний, поскольку прерывания
и события по своей сути очень похожи тем, что им соответствует
некоторое асинхронное событие, на которое система должна реа¬
гировать.
Информация о событии обычно приходит в форме сообщения.
Каждое событие имеет заголовок события и тело события. Заголо¬
вок содержит элементы, описывающие тип события, имя события,
метку времени, идентификатор спецификации события, номер со¬
бытия и источник (создателя) события.
Тело события описывает то, что произошло, например: на скла¬
де низкий уровень запасов некоторого товара или слишком высо¬
кая температура в холодильнике.
В идеале тело должно содержать полную информацию о собы¬
тии, чтобы любая заинтересованная сторона могла на основе этой
информации сформировать реакцию на это событие без обраще¬
ния к источнику информации о событии. Например, сообщение
с информацией о низком уровне запасов продукта на складе мо¬
жет содержать не только идентификатор продукта, но также опи¬
сание продукта, уровни запасов и порога на момент времени. Для
обеспечения понимания событий всеми потребителями они долж¬
ны иметь общий словарь или онтологию.
Существует три основных типа обработки событий: простой,
потоковый и сложный. Эти три стиля часто используются вместе
в зрелой архитектуре, управляемой событиями.
Простая обработка событий. При простой обработке собы¬
тий происходит заметное событие, инициирующее последующее
действие (действия). Простая обработка событий обычно исполь¬
зуется для управления потоком работ в реальном времени, что со¬
кращает время задержки и затраты бизнеса.
Обработка потоковых событий. При потоковой обработке со¬
бытий происходят как обычные, так и заметные события. Обычные
события (заказы, передачи RFID) проверяются на предмет заметно¬
сти и передаются информационным подписчикам.
Потоковая обработка событий обычно используется для управ¬
ления потоком информации в реальном времени на предприятии
и вокруг него, что позволяет своевременно принимать решения.
-180-
О независимых компонентах
Комплексная обработка событий. Комплексная обработка со¬
бытий (Complex Event Processing, CEP) связана с оценкой совокупно¬
сти событий и последующим принятием мер. События (заметные
или обычные) могут пересекаться по типам событий и происходить
в течение длительного периода времени.
Корреляция событий может быть причинной, временной или
пространственной. CEP требует использования сложных интер¬
претаторов событий, определения и сопоставления шаблонов со¬
бытий, а также методов корреляции. CEP обычно используется для
обнаружения и реагирования на бизнес-аномалии, угрозы и воз¬
можности.
Основные подстили стиля архитектуры, управляемой со¬
бытиями. Обобщенная структура системы обработки событий по¬
казана на рис. 4.14 и включает в себя два основных типа элемен¬
тов: диспетчер событий и множество подсистем обработки событий
(процессоров обработки событий).
Источник событий
Рис. 4.14. Обобщенная структура системы обработки событий
В рамках стиля архитектуры, управляемой событиями, можно
выделить два подстиля: архитектуры, основанные на использова¬
нии медиатора (mediator), и архитектуры на основе брокера (broker).
Разница между этими подстилями состоит в том, что в первом слу¬
чае используется централизованная система обработки событий,
когда все события проходят обработку в одной подсистеме (медиа¬
торе), а во втором случае используется рапределенная система об¬
работки событий.
-181-
4. ПОЗНАКОМИМСЯ С КЛАССИЧЕСКИМИ ПЛАТФОРМАМИ И ПАРАДИГМАМИ
Централизованная система обработки событий. Централи¬
зованную структуру на базе мидиатора используют в случае, когда
обработка событий реализуется в несколько этапов и требуется ко¬
ординация этих этапов, т. е. когда появление события инициализи¬
рует некоторый бизнес-процесс.
Типовая структура централизованной системы показана на
рис. 4.15. Использует четыре типа элементов: очереди событий,
посредник (медиатор) событий, каналы событий и процессоры
событий.
Рис. 4.15. Типовая структура централизованной системы
обработки событий
Имеются два типа событий: начальное событие и производное
событие.
Начальное событие — это исходное событие, полученное по¬
средником, тогда как производное событие — это событие, сгене¬
рированное посредником и отправленное отдельным процессорам
обработки событий.
Обработка потока событий начинается с того, что клиент от¬
правляет событие в очередь событий, которая используется для пе¬
редачи события посреднику событий. Посредник событий получает
начальное событие и обрабатывает его, формирует дополнитель¬
ные события и отправляет их в каналы событий для выполнения
-182-
О независимых компонентах
каждого шага процесса. Процессоры событий прослушивают кана¬
лы событий, получают информацию о событии и выполняют обра¬
ботку события в соответствии со своей ролью в бизнес-процессе об¬
работки события.
Централизованные системы могут иметь разные размеры.
В системе может иметься от десятков до нескольких сотен оче¬
редей событий, которые могут быть реализованы как с помо¬
щью очередей сообщений, так и в виде конечных точек веб-сер¬
висов.
Медиатор событий отвечает за организацию шагов, требуемых
для формирования реакции на это событие. Реакцией в этом случае
является запуск бизнес-процесса, т. е. можно говорить, что медиа¬
тор отвечает за формирование бизнес-процесса.
Медиатор событий может быть реализован различными спосо¬
бами. Для этого можно использовать, в частности, рассмотренные
выше корпоративные сервисные шины.
Компоненты обработчика событий содержат бизнес-логику при¬
ложения, необходимую для обработки события обработки. Процес¬
соры событий также могут быть реализованы разными способами.
Это может быть как монолитное приложение, так и множество ав¬
тономных, независимых модулей, каждый из которых выполняет
одну или несколько частных задач.
Распределенная система обработки событий. Распределен¬
ная система на основе брокера сообщений отличается от системы,
построенной по принципу медиатора, тем, что в ней нет централь¬
ного посредника событий, а поток сообщений о событиях распре¬
деляется по отдельным подсистемам (процессорам обработки сооб¬
щений) по цепочке. Для этого может быть использован упрощенный
вариант медиатора, в качестве которого может быть использована
очередь сообщений.
Такое решение используется в случае, когда каждое событие
обрабатывается одним процессором и нет необходимости в цент¬
рализованной обработке, т. е. в оркестровке.
-183-
4. ПОЗНАКОМИМСЯ С КЛАССИЧЕСКИМИ ПЛАТФОРМАМИ И ПАРАДИГМАМИ
Упрощенная структура децентрализованной системы обработ¬
ки событий показана на рис. 4.16.
Рис. 4.16. Типовая структура децентрализованной системы
обработки событий
В системе по рис. 4.16 используется два типа компонентов: ка¬
нал сообщений и процессор обработки событий. Каждый процессор
отвечает за обработку определенного типа событий. После обработ¬
ки он помещает результаты в очередь сообщений, а процессоры, ко¬
торые отвечают за обработку данного типа событий, выбирают са¬
мостоятельно события из очереди и обрабатывают его.
ЧТО СОБОЙ ПРЕДСТАВЛЯЮТ
ЦЕНТРАЛИЗОВАННЫЕ РЕПОЗИТОРИИ ДАННЫХ
К системам, работающим по принципу централизованных дан¬
ных (репозитория), относят системы, основанные на использова¬
нии централизованной базы данных, и системы, использующие
принцип классной доски. Репозитории иногда называют также
системами с централизованным хранением данных (Data-centric
systems).
-184-
Что собой представляют централизованные репозитории данных
Централизованная база данных
Отличительной особенностью данного архитектурного стиля
является наличие централизованного хранилища, в котором могут
находиться ДИЗ. Централизованное хранилище обеспечивает удоб¬
ный доступ к данным и метаданным.
На рис. 4.17 показана обобщенная структура системы, работа¬
ющей по принципу репозитория.
Рис. 4.17. Структура системы, работающей по принципу репозитория
Системы данного класса — это прежде всего системы, в осно¬
ву функционирования которых положены механизмы управления
данными.
Под управлением данными в данном случае понимается со¬
вокупность процедур, связанных со сбором, передачей, запомина¬
нием, хранением, обработкой, поиском и отображением данных.
Иначе говоря, управление данными — это процедура преобразова¬
ния исходных данных в форму, удобную для пользователя.
Это один из наиболее часто используемых архитектурных сти¬
лей. Укрупненная классификация ИС, которые могут быть отнесены
к данному архитектурному стилю, показана на рис. 4.18.
В централизованном хранилище могут быть данные, информа¬
ция, знания или некоторая их комбинация.
Содержимое централизованного хранилища может быть струк¬
турированным, частично структурированным или неструктуриро¬
ванным. Если данные хранятся в неструктурированном виде, то та¬
кой подход называют озера данных (data lakes).
-185-
4. ПОЗНАКОМИМСЯ С КЛАССИЧЕСКИМИ ПЛАТФОРМАМИ И ПАРАДИГМАМИ
Рис. 4.18. Укрупненная классификация ИС типа
централизованное хранилище
Известно достаточно много разных способов организации
хранилищ данных, основными из которых являются следующие:
файловые, сетевые, реляционные, объектно-ориентированные,
объектно-реляционные, постреляционные, гипертекстовые, иерар¬
хические, онтологические, графовые и др. [64].
С точки зрения реализации на физическом уровне репозито¬
рии могут быть трех типов: централизованные, распределенные
и виртуальные, например облачные хранилища.
С точки зрения характера обработки системы, работающие по
принципу централизованного репозитория, можно разделить на
системы оперативной обработки и хранилища данных.
В первом случае система оперирует структурированными дан¬
ными и предназначена для обработки конкретных запросов за¬
интересованных сторон, обычно их называют операционными
(транзакционными), или OnLine Transaction Processing (OLTP).
-186-
Что собой представляют централизованные репозитории данных
Во втором случае речь идет о хранилищах данных, которые пред¬
ставляют собой предметно-ориентированный, интегрированный,
привязанный ко времени и неизменный набор ретроспективных
данных, предназначенный для поддержания процесса стратеги¬
ческого принятия решений, прогноза и выявления скрытых зако¬
номерностей.
Системы, основанные на хранилищах данных, получили назва¬
ние аналитических, или OnLine Analytic Processing (OLAP).
Классная доска
Системы, использующие принцип классной доски, реализу¬
ют метафору классной доски, на которой можно писать мелом, при
этом написанное доступно всем участникам обсуждения. В основе
своей классная доска представляет собой базу данных, в которую
процессы могут записывать, читать и удалять данные.
Системы, построенные с использованием данного архитек¬
турного стиля, находят применение в первую очередь в системах
искусственного интеллекта, в качестве репозитория для хранения
системных знаний.
Обобщенная структура системы, работающей по принципу
классной доски, показана на рис. 4.19. В данной системе источники
знаний представлены независимыми процессами, которые обла¬
дают определенными знаниями о внешнем мире и о ходе реше¬
ния текущей задачи. Процессы могут изменять данные, находящи¬
еся на доске.
Доска представляет собой разделяемую память, в которой
хранятся данные и знания о ходе решения задачи. Каждый про¬
цесс, выполнив свою часть работы по решению задачи, помеща¬
ет результат на доску, где он становится доступен другим процес¬
сам. Каждый процесс может пользоваться услугами подсистемы
информирования об изменении конкретной информации, поме¬
щенной на доску.
-187-
4. ПОЗНАКОМИМСЯ С КЛАССИЧЕСКИМИ ПЛАТФОРМАМИ И ПАРАДИГМАМИ
Рис. 4.19. Структура системы, работающей по принципу классной доски
Таким образом, если один процесс изменил данные, находя¬
щиеся на доске, то все процессы, которые заинтересованы в ис¬
пользовании этих данных, немедленно информируются о факте
изменения данных. Уведомления процессам об изменении дан¬
ных поступают в форме сообщений.
В системах, работающих по принципу классной доски, для ре¬
шения прикладных задач широко используются системы логиче¬
ского вывода, при этом используются три подхода: прямой логи¬
ческий вывод, обратный логический вывод, смешанные стратегии.
Данный архитектурный стиль появился еще в 1970-х гг. и первона¬
чально использовался в системах распознавания речи. В настоящее
время данный стиль широко применяется в мультиагентных систе¬
мах для обеспечения взаимодействия агентов.
В ЧЕМ СМЫСЛ ПРИНЦИПА ВИРТУАЛЬНОЙ МАШИНЫ
К системам, работающим по принципу виртуальной машины,
относят интерпретаторы и системы, основанные на правилах. Сле¬
дует заметить, что это один из наиболее интенсивно развивающих¬
ся классов ИС.
-188-
В чем смысл принципа виртуальной машины
Технологии виртуализации
В широком смысле понятие виртуализации представляет собой
сокрытие истиной реализации процесса или объекта его представ¬
ления для того, кто им пользуется. В ИТ под термином «виртуали¬
зация» понимается абстракция вычислительных ресурсов и их пре¬
доставление пользователю системы в нужном ему (ей) виде. Иначе
говоря, пользователь работает с удобным для себя представлени¬
ем объекта, и он не знает, как ресурс устроен в действительности.
Например, виртуализация ресурсов физического сервера позволя¬
ет гибко распределять их между приложениями, каждое из которых
при этом «видит» только предназначенные ему ресурсы и «счита¬
ет», что ему выделен отдельный сервер, т. е. в данном случае реали¬
зуется подход «один сервер — несколько приложений».
В основе механизма виртуализации лежит способность одно¬
го компьютера выполнять работу нескольких компьютеров за счет
распределения его ресурсов по нескольким средам. Использова¬
ние виртуальных серверов и виртуальных рабочих станций позво¬
ляет разместить несколько ОС и несколько приложений в едином
месте, в результате чего физические и географические ограниче¬
ния скрываются от пользователя.
Определим основные понятия, связанные с виртуализацией.
Виртуализация — процесс представления набора вычисли¬
тельных ресурсов или их логического объединения, который дает
какие-либо преимущества перед оригинальной конфигурацией.
Виртуальная машина — программная или аппаратная сре¬
да, которая скрывает настоящую реализацию какого-либо процес¬
са или объекта от его видимого представления.
Хостовая ОС — ОС, которая установлена на физической ма¬
шине.
Гостевая ОС — ОС, работающая на виртуальной машине. В ОС
физического компьютера (хостовой ОС) устанавливается платфор¬
ма виртуализации, с помощью которой создаются виртуальные ма¬
шины, в которых, в свою очередь, устанавливаются различные гос¬
тевые ОС.
-189-
4. ПОЗНАКОМИМСЯ С КЛАССИЧЕСКИМИ ПЛАТФОРМАМИ И ПАРАДИГМАМИ
Полная виртуализация — виртуализация, при которой ис¬
пользуются немодифицированные экземпляры гостевых ОС, а для
поддержки работы этих ОС служит общий слой эмуляции их испол¬
нения поверх хостовой ОС, в роли которой выступает обычная ОС.
Паравиртуализация — виртуализация, при которой произво¬
дится модификация ядра гостевой ОС с целью включения в новый
набор API, используя который она может напрямую работать с ап¬
паратурой, не конфликтуя с другими виртуальными машинами.
Виртуализация на уровне ОС — разновидность виртуализа¬
ции, которая предполагает использование одного ядра хостовой ОС
для создания независимых параллельно работающих операцион¬
ных сред.
Виртуализация серверов — это запуск на одном физическом
сервере нескольких виртуальных серверов. Виртуальные машины
или сервера представляют собой приложения, запущенные на хо-
стовой ОС, которые эмулируют физические устройства сервера. На
каждой виртуальной машине может быть установлена ОС, на кото¬
рую инсталлируются приложения и сервисы.
Виртуализация приложений — разновидность виртуализа¬
ции, которая предполагает применение модели сильной изоляции
прикладных программ с управляемым взаимодействием с ОС, при
которой виртуализации подвергается каждый экземпляр прило¬
жений и все его основные компоненты: файлы, включая систем¬
ные (реестр, 7М-файлы). Приложение исполняется без процедуры
инсталляции в традиционном ее понимании и может запускаться
с внешних носителей.
Виртуализация рабочих мест (представлений) — сервер
предоставляет свои ресурсы клиентам, причем клиентское прило¬
жение выполняется на этом сервере, а клиент получает только пред¬
ставление.
Гипервизор (монитор виртуальных машин) — аппаратное
или программное средство, позволяющее одновременное (парал¬
лельное) выполнение нескольких ОС на одном компьютере. Гипер¬
визор обеспечивает изоляцию ОС друг от друга, защиту и безопас¬
ность, разделение ресурсов между различными запущенными ОС.
Гипервизор может предоставлять одновременно работающим под
его управлением ОС средства связи и взаимодействия между собой,
например через обмен файлами или сетевые соединения, так, как
-190-
В чем смысл принципа виртуальной машины
если бы эти ОС выполнялись на разных физических компьютерах.
Гипервизор можно рассматривать как саму ОС или микроядро, ко¬
торое предоставляет запущенным под его управлением ОС сервис
виртуальной машины, эмулируя реальное аппаратное обеспечение
конкретной машины. Гипервизор управляет этими виртуальными
машинами, выделением и освобождением ресурсов для них. Гипер¬
визор позволяет независимое «включение», перезагрузку, «выклю¬
чение» любой из виртуальных машин с той или иной ОС. При этом
ОС, работающая в виртуальной машине под управлением гиперви¬
зора, может, но не обязана «знать», что она выполняется в виртуаль¬
ной машине, а не на реальном аппаратном обеспечении.
Монолитная архитектура гипервизора — архитектура ги¬
первизора, при которой гипервизор размещается в едином уровне,
который также включает большинство требуемых компонентов, та¬
ких как ядро, драйверы устройств и стек ввода/вывода.
Микроядерная архитектура гипервизора. Подход, при кото¬
ром используется специализированный гипервизор, выполняющий
лишь основные задачи обеспечения изоляции разделов и управ¬
ления памятью. Этот уровень не включает стек ввода/вывода или
драйверы устройств.
Рассмотрим более подробно определенные выше понятия.
Виртуальная машина — это полностью изолированный про¬
граммный контейнер, который работает с собственной ОС и прило¬
жениями, подобно физическому компьютеру. Виртуальная машина
работает так же, как физический компьютер, и содержит собствен¬
ную виртуальную оперативную и дисковую память и адаптер. ОС
и работающие под ее управлением приложения не различают вир¬
туальную и физическую машины. То же самое можно сказать о при¬
ложениях и других компьютерах в сети. Даже сама виртуальная ма¬
шина считает себя «настоящим» компьютером.
Виртуализация серверов предполагает запуск нескольких
виртуальных серверов на одном физическом сервере. Виртуаль¬
ные машины или сервера представляют собой приложения, кото¬
рое запускается на хостовой ОС, эмулирующей физические устрой¬
ства сервера. На каждой виртуальной машине устанавливается ОС,
на которую устанавливаются приложения и службы. Обычно сред¬
ствами технологий виртуализации консолидируются серверы, раз¬
-191-
4. ПОЗНАКОМИМСЯ С КЛАССИЧЕСКИМИ ПЛАТФОРМАМИ И ПАРАДИГМАМИ
мещенные на нескольких физических серверах в виде виртуальных
машин на одном высокопроизводительном сервере. При этом чи¬
сло физических машин, необходимых для работы в качестве серве¬
ров, уменьшается, что снижает количество энергии, необходимой
для работы машин, и пространство, требуемое для их размещения.
Используются два альтернативных подхода к решению этой за¬
дачи: паравиртуализация и полная виртуализация.
Поддержка однородных вычислительных сред подразумевает
изоляцию сервисов в рамках одного экземпляра ядра ОС (виртуа¬
лизация на уровне ОС). Этот подход чаще всего используется про¬
вайдерами сервисов для хостинга приложений.
Паравиртуализация. Обобщенная структура системы, исполь¬
зующей паравиртуализацию, показана на рис. 4.20. В ядро гостевой
ОС включается новый набор API, через который она может напря¬
мую работать с аппаратурой, не конфликтуя с другими виртуаль¬
ными машинами. При этом отпадает необходимость иметь пол¬
ноценную ОС в качестве хостового ПО, функции которого в этом
случае выполняет гипервизор. Этот вариант используется во мно¬
гих реальных системах, таких как VMware ESX Server, Microsoft Hyper-
V [65]. Достоинство данного подхода состоит в потребности в хосто-
вой ОС. Виртуальная машина устанавливается непосредственно на
аппаратную платформу, что создает реальные предпосылки для по¬
лучения высокой скорости работы. Основным недостатком данного
подхода является его сложность, которая обусловлена необходимо¬
стью создания специализированной ОС — гипервизора.
Приложение
Приложение
Модифицированная
Модифицированная
Управление
гостевая ОС
гостевая ОС
Г ипервизор
Оборудование
Рис. 4.20. Паравиртуализация
Полная виртуализация (Full, Native Virtualization). Обобщенная
структура системы, использующей полную виртуализацию, показа-
-192-
В чем смысл принципа виртуальной машины
на на рис. 4.21. При использовании механизма полной виртуализа¬
ции применяются немодифицированные экземпляры гостевых ОС.
Для поддержки работы гостевых ОС служит отдельный слой эму¬
ляции, в роли которой выступает обычная ОС. Такой подход часто
применяется во многих популярных продуктах, таких как MS Virtual
PC, MS Virtual Server, VMware Workstation и др. [65] Несомненными
достоинствами данного подхода являются его простота реализации,
универсальность и надежность решения; поскольку функции управ¬
ления берет на себя хост-ОС. Основной недостаток состоит в отно¬
сительно невысокой скорости работы.
Приложение
Приложение
Управление ...
Гостевая ОС
Гостевая ОС
Г ипервизор
Оборудование
Рис. 4.21. Полная виртуализация
Виртуализация на уровне ядра ОС. Обобщенная структура си¬
стемы, использующей виртуализацию на уровне ядра ОС, показана
на рис. 4.22. Данный подход ориентирован на создание только одно¬
родных вычислительных сред и подразумевает использование од¬
ного ядра хостовой ОС для создания независимых параллельно ра¬
ботающих операционных сред. Для гостевого ПО создается только
собственное аппаратное сетевое и окружение. Данный подход по¬
зволяет получить высокую эффективность использования аппарат¬
ных ресурсов и хорошую управляемость, но может быть использо¬
ван только для создания однородных вычислительных сред.
Выделенный
Выделенный
Выделенный
сервер
сервер
сервер
ОС
Оборудование
Рис. 4.22. Виртуализация на уровне ядра ОС
-193-
4. ПОЗНАКОМИМСЯ С КЛАССИЧЕСКИМИ ПЛАТФОРМАМИ И ПАРАДИГМАМИ
Виртуализация приложений подразумевает применение мо¬
дели, при которой виртуализируется каждый экземпляр прило¬
жений и все его основные компоненты: файлы (включая систем¬
ные), реестр, шрифты, 7М-файлы, службы. Обобщенная структура
системы, использующей виртуализацию приложений, показана на
рис. 4.23. При использовании данного подхода приложение можно
запускать без процедуры инсталляции, в частности прямо с внеш¬
них носителей, что позволяет ускорить развертывание настольных
систем и дает возможность управления ими, сведения к минимуму
не только конфликтов между приложениями, но и потребности в те¬
стировании приложений на совместимость. Данная технология по¬
зволяет использовать на одном компьютере, а точнее в одной и той
же ОС, несколько несовместимых между собой приложений однов¬
ременно. Виртуализация приложений позволяет пользователям за¬
пускать одно и то же заранее сконфигурированное приложение или
группу приложений с сервера. При этом приложения будут работать
независимо друг от друга, не внося никаких изменений в ОС. Такой
подход используется, в частности, в Java Virtual Machine и ряде дру¬
гих систем [65].
Приложение
Приложение
Приложение
Приложение
ОС
Оборудова
ние
Рис. 4.23. Виртуализация приложений
Контейнеры
Контейнеризацию можно рассматривать как облегченную вер¬
сию виртуализации, хотя ее иногда рассматривают как отдельный
архитектурный стиль. Под контейнеризацией обычно понимают
такой подход к разработке ИС, при котором отдельные приложения,
которые, в частности, может реализовать сервис, вместе со своими
конфигурационными файлами упаковываются в образ контейнера.
Для того чтобы контейнеры могли работать на хосте, на нем дол¬
-194-
В чем смысл принципа виртуальной машины
жен быть установлен узел (node) контейнеров. На одном узле может
быть размещено несколько контейнеров.
Философию контейнеризации часто описывают с помощью
метафоры «доставки грузов в контейнерах», которая, вполне оче¬
видно, объясняет происхождение этого термина. Подобно тому,
как при транспортировке грузов используются трейлеры, поезда
и корабли.
При транспортировке грузов используются разнообразные
средства, включая автопогрузчики, краны. Если все перевозимые
грузы помещены в одинаковые контейнеры, то это резко упроща¬
ет процесс их обработки.
Использование контейнеров позволяет разработчикам упро¬
стить решение многих задач. Контейнеры выступают в качест¬
ве стандартных модулей для развертывания программного обес¬
печения, которые могут содержать различный код и зависимости.
Контейнеризация программного обеспечения позволяет разработ¬
чикам и ИТ-специалистам развертывать его в разных средах без ка¬
ких-либо изменений или с минимальными изменениями, т. е. резко
упрощает решение задач, связанных с мобильностью кода. Контей¬
неры также позволяют изолировать приложения друг от друга при
работе в общей операционной системе. Контейнерные приложения
выполняются на основе узла контейнеров, который, в свою очередь,
работает в ОС (Linux или Windows). Одним из основных достоинств
контейнеров является то, что по сравнению с виртуальными маши¬
нами они требуют гораздо меньше ресурсов.
Еще одним преимуществом контейнеризации является мас¬
штабируемость. Можно оперативно создавать контейнеры для ре¬
шения краткосрочных задач. Создание экземпляра образа (созда¬
ние контейнера) аналогично созданию экземпляра процесса. Для
обеспечения надежности можно запускать нескольких экземпля¬
ров одного образа на нескольких серверах.
Можно утверждать, что использование контейнеров предос¬
тавляет такие преимущества, как изоляция, переносимость, гиб¬
кость, масштабируемость и контроль, на протяжении всего жиз¬
ненного цикла приложения.
-195-
4. ПОЗНАКОМИМСЯ С КЛАССИЧЕСКИМИ ПЛАТФОРМАМИ И ПАРАДИГМАМИ
Таким образом, технология контейнеризации оказывается тес¬
ным образом связана с технологией DevOps.
Фактическим стандартом контейнерного подхода можно счи¬
тать системы фирмы Docker. Docker — это компания, которая разраба¬
тывает и продвигает эту технологию в сотрудничестве с поставщика¬
ми облачных служб, а также поставщиками Linux и Windows решений.
Docker представляет собой проект с открытым исходным кодом для
автоматизации развертывания приложений в виде переносимых ав¬
тономных контейнеров, выполняемых в облаке или локальной среде.
Контейнеры Docker могут работать в любой среде, например
в локальном центре обработки данных или в облаке. Контейнеры
образов Docker работают в исходном формате используемой ОС, т. е.
образы Windows будут выполняться только на узлах Windows, а обра¬
зы Linux выполняются на Windows, установив поверх виртуальной
машины соответствующий узел.
На рис. 4.24 показана структура, использующая виртуальную
машину, а на рис. 4.25 — структура, использующая контейнерное
решение.
Приложение]
Приложение2
ПриложениеЗ
bins/libs
bins/libs
bins/libs
Гостевая ОС
Гостевая ОС
Гостевая ОС
Гипервизор
Родная ОС
Инфраструктура
Рис. 4.24. Сравнение традиционных виртуальных машин.
Виртуальные машины
Виртуальные машины содержат приложение, необходимые би¬
блиотеки или двоичные файлы и всю операционную систему. Кон¬
тейнеры включают в себя приложение и все его зависимости. Но
они используют ядро ОС совместно с другими контейнерами, кото¬
рые выполняются в изолированных процессах в пользовательском
пространстве операционной системы узла.
-196-
В чем смысл принципа виртуальной машины
Приложение 1
bins/libs
bins/libs
Приложение 1
bins/libs
Инфраструктура
Рис. 4.25. Сравнение традиционных виртуальных машин. Контейнер
Полная виртуализация требует больше ресурсов, чем создание
контейнеров, поскольку узел, в котором работают контейнеры, ак¬
тивно использует ресурсы ядра ОС.
Для виртуальных машин на сервере узла создается три базо¬
вых уровня: самый нижний инфраструктурный слой; затем опера¬
ционная система узла и низкоуровневая оболочка; и поверх это¬
го каждая виртуальная машина использует собственную ОС и все
необходимые библиотеки. Для Docker сервер узла предоставля¬
ет только инфраструктуру и операционную систему, а также ядро
контейнеров.
Поскольку контейнеры требуют гораздо меньше ресурсов, то
их проще развертывать и они быстрее запускаются. Однако запуск
нескольких контейнеров на одном узле приводит к тому, что уро¬
вень изоляции будет ниже, чем на виртуальных машинах.
Контейнер отвечает за выполнение одного приложения, про¬
цесса или сервиса и состоит из содержимого образа, среды выпол¬
нения и стандартного набора инструкций. При масштабировании
службы можно создать несколько экземпляров контейнера из од¬
ного образа. Пакетное задание может создать несколько контей¬
неров из одного образа, передавая разные параметры каждому эк¬
земпляру.
-197-
4. ПОЗНАКОМИМСЯ С КЛАССИЧЕСКИМИ ПЛАТФОРМАМИ И ПАРАДИГМАМИ
Применительно к контейнерным решениям различают поня¬
тие образ контейнера и контейнер. Образ — это класс, а контей¬
нер — это экземпляр класса.
Образ контейнера представляет собой пакет со всеми зави¬
симостями и сведениями, необходимыми для создания контейне¬
ра. Образ включает в себя все зависимости (например, платфор¬
мы), а также конфигурацию развертывания и выполнения для
среды выполнения контейнера. Обычно образ контейнера создает¬
ся на основе нескольких базовых образов, наслоенных друг на дру¬
га в файловой системе контейнера. После создания образ остается
неизменным.
Основное назначение образа состоит в том, чтобы привести
среду (зависимости) к единообразию в различных развертывани¬
ях. Это позволяет отладить образ на одном хосте, а затем развер¬
нуть его на другом хосте и получить ту же среду.
Образ контейнера можно рассматривать как способ упаковки
приложения или сервиса для надежного и воспроизводимого раз¬
вертывания.
Действие по созданию образа контейнера на основе сведений
и контекста называют сборкой, которая представляется файлом
Dockerfile, а также дополнительными файлами в папке, где создает¬
ся образ. Сборка образов выполняется с помощью следующей ко¬
манды Docker — docker build.
Dockerfile представляет собой текстовый файл, содержащий ин¬
струкции по сборке образа Docker. Он похож на пакетный сценарий,
где первая строка указывает базовый образ, с которого начинает¬
ся работа, а следующие инструкции устанавливают необходимые
программы, копируют файлы и т. п. для создания необходимой ра¬
бочей среды.
Docker можно рассматривать как многослойную систему, каж¬
дый слой которой представляет некоторый набор изменений, кото¬
рые применяются к файловой системе после выполнения команды,
такой как установка программы.
После копирования очередного слоя можно увидеть все файлы
в том состоянии, которое они приняли после установки програм¬
-198-
В чем смысл принципа виртуальной машины
мы. Такой образ можно рассматривать как готовый к установке до¬
полнительный жесткий диск с установленной ОС. В качестве «ком¬
пьютера» в этом случае выступает контейнер, который как обычный
компьютер можно включать и отключать.
Поскольку образы доступны только для чтения, а большинст¬
ву программ требуется возможность записи в файловую систему,
то для этого используются тома, которые добавляют слой с под¬
держкой записи поверх образа контейнера, который программы
смогут использовать как файловую систему с возможностью за¬
писи. Программа не знает, что она обращается к многоуровневой
файловой системе. Для нее это обычный вызов файловой систе¬
мы. Тома размещаются в системе узла под управлением Docker.
Для того чтобы различать разные образы или версии одного
образа (в зависимости от номера версии или целевой среды), ис¬
пользуются теги.
Для хранения образов используется репозиторий, который мо¬
жет содержать образы для разных платформ.
Для доступа к репозиторию используются реестры.
Узлы можно объединять в кластеры. Кластер можно опреде¬
лить как коллекцию узлов, которая представляется как единый вир¬
туальный узел. Для создания кластеров используются такие инстру¬
менты, как, например, Kubernetes.
Инструмент, используемый для управления кластерами и уз¬
лами Docker, называют оркестратором. С помощью оркестраторов
можно управлять образами, контейнерами и узлами через интер¬
фейс командной строки или графический интерфейс. Оркестра¬
тор можно использовать для выполнения, распределения, масшта¬
бирования и восстановления рабочих нагрузок в коллекции узлов.
В качестве оркестраторов обычно используются те же продукты,
которые обеспечивают кластерную инфраструктуру, например
Kubernetes Docker Swarm, Azure Service Fabric и др.
Kubernetes. Kubernetes — это проект с открытым исходным ко¬
дом от компании Google, которая имеет богатый опыт развертыва¬
ния контейнеров в большом масштабе и управления ими. Kubernetes
позволяет запускать приложения в контейнерах в нужном месте
-199-
4. ПОЗНАКОМИМСЯ С КЛАССИЧЕСКИМИ ПЛАТФОРМАМИ И ПАРАДИГМАМИ
и в нужное время и выделять необходимые ресурсы. Типовая струк¬
тура Kubernetes показана на рис. 4.26.
Клиент
Kubectl
Ведущий узел
Сервер API
Контроллер
репликаций
Планировщик
Распределенная БД
Рабочий узел 1
Kuberlet
Kube Proxy
Рабочий узел 2
Kuberlet
Kube Proxy
Рис. 4.26. Типовая структура Kubernetes
Основными компонентами Kubernetes являются ведущий узел,
рабочие узлы, консоль управления (клиент) и распределенная ба¬
за данных, используемая для сохранения состояния контейнеров.
Центральным элементом архитектуры Kubernetes является ве¬
дущий узел, который координирует работу с помощью набора сер¬
висов. На ведущем узле функционируют сервер API, планировщик
и контроллер репликаций, которые управляют всеми действиями,
связанными с планированием и поддержкой приложений в требу¬
емом состоянии, масштабированием и др.
Сервер API отвечает за поддержку API для взаимодействий
с кластером Kubernetes, которые реализуются с использованием мик¬
росервисов.
Этот сервер отвечает как за взаимодействие между рабочими
узлами и ведущим узлом, так и за взаимодействие между класте¬
ром Kubernetes и консолью (kubectl).
Кроме того, это единственный компонент, который может об¬
ращаться к распределенному хранилищу, в котором сохраняются
состояния контейнеров в виде пар ключ/значение.
-200-
В чем смысл принципа виртуальной машины
Kubernetes имеет интерфейс командной строки kubectl, который
используется для запуска команд и взаимодействия с кластерами
Kubernetes.
Например, запустить пять контейнеров контейнера сервлетов
Tomcat можно с помощью команды:
kubectl run myTomcat --image=Tomcat --replicas=3.
Этот запрос будет направлен серверу API, который задействует
компоненты планировщика и контроллер репликации для выпол¬
нения запроса и приведет кластер в требуемое состояние.
Планировщик Kubernetes отвечает за размещение контейнеров
на узлах кластера. Планирование осуществляется в терминах под¬
ов (pod — гроздь, связка). Под можно рассматривать как логический
хост с собственным пространством имен и одним или нескольки¬
ми подами, которые совместно используют его пространство имен.
Решение о месте размещения контейнеров принимает плани¬
ровщик. Для этого он проверяет ряд условий:
- какие узлы имеют достаточно ресурсов для запуска контей¬
неров;
- имеются ли свободные порты, необходимые для работы пода;
- не приведет ли размещение пода на данном узле к перегруз¬
ке сети;
- следует ли распределять поды по отдельным кластерам для
обеспечения высокой доступности или их можно поместить в один
кластер.
Очевидно, что при принятии решения о размещении подов
планировщик должен учесть большое число факторов. Для это¬
го он считывает из образов контейнеров информацию о требу¬
емых ресурсах (требуемую производительность, объем памяти,
пропускную способность каналов связи) и запускает процесс оп¬
ределения узла для размещения пода.
Kubernetes имеет модульную архитектуру, и если пользовате¬
ля не устраивает штатный планировщик, то он может заменить его
собственным планировщиком.
-201-
4. ПОЗНАКОМИМСЯ С КЛАССИЧЕСКИМИ ПЛАТФОРМАМИ И ПАРАДИГМАМИ
Контроллер репликаций обеспечивает одновременное выпол¬
нение в кластере заданного количества реплик пода. Допустим, мы
решили запустить пять экземпляров контейнера Tomcat. В этом слу¬
чае контроллер репликаций создаст пять подов и обеспечит их за¬
пуск в кластере, т. е. выполнит процедуру планирования и подбе¬
рет лучшие узлы для запуска этих подов (pod). Если один из узлов,
где выполнялся под, по какой-то причине остановился, то, обнару¬
жив эту ситуацию, контроллер репликации обратится к планиров¬
щику и потребует запустить еще один экземпляр.
Если нагрузка снизилась и требуется сократить потребление ре¬
сурсов, то можно запустить команду:
kubectl run myTomcat --image=tomcat--replicas=2.
В этом случае контроллер репликации обнаружит разницу
и остановит лишние экземпляры.
Рабочими называются узлы, в которых размещаются и запу¬
скаются поды. На каждом узле работает агент, который называет¬
ся kubelet. Этот агент отвечает за получение «заданий» от ведуще¬
го узла и их выполнение на рабочем узле. Под заданием в данном
случае подразумевается запуск или остановка одного или несколь¬
ких подов.
Для передачи информации о состоянии подов планировщик
использует сервер API. После получения задания от ведущего узла
kubelet запускает требуемые поды.
Kubelet обеспечивает также доступ к информации о текущем
состоянии рабочего узла и каждого из подов, выполняющихся
на данном узле. Эту информацию kubelet сохраняет в базе дан¬
ных etcd через сервер API. Эта информация используется плани¬
ровщиком для определения доступных узлов и объемов ресур¬
сов, доступных на узлах при запуске новых подов. Контроллер
репликации использует эти данные для подсчета количества ре¬
плик, работающих в кластере. Если фактическое количество ре¬
плик не соответствует требуемому, то контроллер приводит кла¬
стер в нужное состояние.
В Kubernetes поды создаются по мере необходимости, могут пе¬
ремещаться на другие узлы и масштабироваться.
-202-
В чем смысл принципа виртуальной машины
Для того чтобы программы-пользователи могли найти ресур¬
сы, находящиеся в контейнерах, используются сервисы Kubernetes.
Сервисы Kubernetes образуют уровень абстракции, служащий
единой точкой входа для клиентских запросов, передаваемых свя¬
занной группе подов. Можно сказать, что они являются интерфей¬
сом доступа к соответствующим подам.
Это избавляет программы-клиенты от необходимости точно
знать, где находятся поды. Они просто обращаются к сервисам,
каждый из которых имеет виртуальный TP-адрес и номер порта,
не изменяющиеся в течение всего времени работы сервиса.
Полную информацию можно найти на сайте [66], а также в [67].
Системы, основанные на правилах
Любая организация использует в процессе функционирования
определенный набор законов, постановлений правительства, про¬
мышленных стандартов и корпоративных политик, которые в сово¬
купности и называются бизнес-правилами (business rules). Наблю¬
дение за их выполнением и соблюдением может осуществляться
как непосредственно людьми, так и ИТ-системами.
Под бизнес-логикой обычно понимают совокупность правил,
принципов, зависимостей поведения объектов предметной области
системы. Иначе можно сказать, что бизнес-логика применительно
к ^ — это реализация правил и ограничений автоматизируемых
операций. Термин «бизнес-логика» часто используют как синоним
термина «логика предметной области» (Domain Logic).
К бизнес-логике относятся, к примеру, формулы расчета еже¬
месячных выплат по ссудам (в финансовой сфере), автоматизиро¬
ванная отсылка электронного письма руководителю проекта по
окончании выполнения частей задания всеми подчиненными (в си¬
стемах управления проектами) и т. п.
Согласно определению Business Rules Group (1993), «бизнес-пра¬
вило — это положение, определяющее или ограничивающее какие-
либо стороны бизнеса; его назначение состоит в том, чтобы защитить
структуру бизнеса, контролировать или влиять на его операции». Це¬
-203-
4. ПОЗНАКОМИМСЯ С КЛАССИЧЕСКИМИ ПЛАТФОРМАМИ И ПАРАДИГМАМИ
лые методологии разработаны специально для создания и докумен¬
тирования бизнес-правил и их применения в ИС. Если не создается
система, которая в значительной степени управляется бизнес-прави¬
лами, тщательно разработанная методология не нужна. Достаточно
выявить и задокументировать относящиеся к системе правила и свя¬
зать их с конкретными функциональными требованиями.
Бизнес-правила берут начало вне контекста какой-либо кон¬
кретной ИС, а являются одним из главных источников функцио¬
нальных требований к ИС, поскольку они определяют те возмож¬
ности, которыми должна обладать система для выполнения правил.
Не все организации рассматривают собственные важнейшие
бизнес-правила как ценность, которой они являются на самом де¬
ле. Если эта информация не документирована и не хранится долж¬
ным образом, то она существует только в головах сотрудников. Со¬
трудники и разработчики ИС могут по-разному понимать правила,
в результате чего отдельные программные системы могут пo-раз-
ному выполнять одно и то же бизнес-правило. Если известно, где
и каким образом приложение реализует относящиеся к нему биз¬
нес-правила, то модифицировать приложения в случае изменения
соответствующих правил гораздо проще.
В больших организациях часто бывает очень трудно опреде¬
лить, какое именно приложение ответственно за реализацию то¬
го или иного бизнес-правила. Создание общих правил и наличие
централизованного хранилища бизнес-правил упрощают согласо¬
ванную реализацию приложений, на которые эти правила влияют.
Типы правил. Известны разные подходы к классификации пра¬
вил. Схема простейшей классификации, показанная на рис. 4.27, вы¬
деляет пять типов бизнес-правил.
Рис. 4.27. Схема простейшей классификации типов бизнес-правил
-204-
В чем смысл принципа виртуальной машины
Факты (facts) представляют собой верные утверждения о биз¬
несе, которые описывают связи и отношения между значимыми
бизнес-терминами. Факты также называют инвариантами, т. е. не¬
изменными истинами о сущности данных и их атрибутах. Бизнес¬
правила могут ссылаться на факты, однако факты обычно не пре¬
образуются напрямую в функциональные требования к системе.
Сведения о сущности, важные для системы, применяют в моделях
данных, создаваемых аналитиком или архитектором.
Можно привести следующие примеры фактов:
- на каждом продукте имеется наклейка, на которую наносит¬
ся уникальный штрих-код;
- каждый сотрудник имеет пропуск;
- каждый элемент заказа содержит данные о продукте и сро¬
ке поставки;
- стоимость билетов не возвращается, если пассажир опоздал
на рейс.
Ограничения (constraints) определяют состав операций, кото¬
рые могут выполнять как отдельные пользователи, так и ИС. При
описании ограничивающего бизнес-правила обычно используют¬
ся следующие глаголы: должен, не должен, не может, которые мо¬
гут встречаться в разных комбинациях:
а) постоянный читатель библиотеки может взять для прочте¬
ния до пяти книг;
б) при входе в зоопарк взрослый может провести бесплатно до
двух детей;
в) все входы в медицинские учреждения должны соответство¬
вать правительственным постановлениям, касающимся использо¬
вания их людьми с ограниченными физическими возможностями.
Можно выделить смешанные подходы, когда модули, отвеча¬
ющие за работу с правилами, встраиваются в код, написанный на
Java, или в код, описывающий бизнес-процесс.
Примером системы, позволяющей совместно использовать
Java-код и правила, является система Jess [69].
В качестве примера систем, позволяющих использовать прави¬
ла в системах управления бизнес-процессами, можно привести та¬
кие продукты, как ILOG JRules и JBoss Drools [69, 70].
-205-
4. ПОЗНАКОМИМСЯ С КЛАССИЧЕСКИМИ ПЛАТФОРМАМИ И ПАРАДИГМАМИ
Системы управления бизнес-правилами. Под системами
управления бизнес-правилами (Business Rule Management System,
BRMS) обычно понимают ИС, предназначенные для поддержки
и выполнения бизнес-правил организации.
Типовая структура управления бизнес-правилами включает
(рис. 4.28):
- сервер исполнения бизнес-правил;
- среду разработки бизнес-правил;
- подсистему тестирования бизнес-правилами;
- среду управления бизнес-правилами;
- репозиторий бизнес-правил.
Рис. 4.28. Типовая структура управления бизнес-правилами
Сервер исполнения бизнес-правил (Business Rule Engine), ко¬
торый иногда называют движком исполнения бизнес-правил,
представляет собой компонент системы управления бизнес-пра¬
вилами, в функции которого входит выполнение (интерпретация)
правил. Можно считать, что сервер исполнения бизнес-правил пре¬
доставляет сервисы принятия решений, которые могут вызывать
внешние приложения.
Типовой сервер исполнения бизнес-правил реализует следую¬
щие основные функции:
- исполнение правил;
- горячее развертывание правил;
-206-
В чем смысл принципа виртуальной машины
- публикацию наборов правил, в частности в виде веб-сервисов;
- управление наборами правил;
- сбор статистики по выполнению правил.
Среда разработки бизнес-правил представляет собой графиче¬
скую среду, предназначенную для разработки и публикации биз¬
нес-правил. Обычно это среда, поддерживающая режим групповой
работы. Среда разработки ориентирована на разработчиков и ин¬
теграторов, но не на бизнес-пользователей.
Подсистема тестирования бизнес-правил позволяет разработ¬
чикам выполнять их валидацию.
Среда управления бизнес-правилами в отличие от среды раз¬
работки предназначена для бизнес-пользователей, не являющих¬
ся ИТ-специалистами. Это может быть, например, менеджер, отве¬
чающий за продажи.
Репозиторий бизнес-правил представляет собой хранилище
бизнес-правил, доступ к которому осуществляется через среду раз¬
работки и среду управления. Обычно поддерживается работа с вер¬
сиями.
В самом общем виде функционирование системы управления
бизнес-правилами выглядит следующим образом.
На этапе разработки при формулировании требований к ИТ-
системе определяются возможности системы по настройке параме¬
ров функционирования в терминах бизнес-политик. Например, при
разработке системы управления продажами одним из требований
может являться обеспечение возможности для конечного пользова¬
теля системы (менеджера) реализовывать политику типа:
Покупатель, который совершил единовременную покупку на опре¬
деленную сумму, должен быть переведен в более высокую категорию.
Для того чтобы бизнес-пользователи могли редактировать
и писать новые правила, на этапе разработки создается словарь
бизнес-правил. Этот процесс иногда называют вербализацией
(verbalization). Вербализация предполагает создание объектной
бизнес-модели (business object model, BOM), которая может стро¬
иться на основе, например, объектной модели, определенной
в /ava-проекте.
-207-
4. ПОЗНАКОМИМСЯ С КЛАССИЧЕСКИМИ ПЛАТФОРМАМИ И ПАРАДИГМАМИ
Бизнес-политика представляет собой совокупность нескольких
правил. Бизнес-правила являются формализацией бизнес-полити¬
ки, представленной в форме последовательности “if-then” утверж¬
дений, например:
If the customer’s category is Silver and the value of the customer’s
shopping cart is more than $500.
Then change the customer’s category to Gold.
If the customer’s category is Gold and the value of the customer’s
shopping cart is more than $1000.
Then change the customer’s category to Platinum.
После того как правила разработаны, они компануются в ис¬
полняемый модуль, и его можно вызывать как единую сущность.
Если используется СОА, а бизнес-процессы реализуются на язы¬
ке bpel, то сервер исполнения бизнес-правил представляет собой сер¬
вис принятия решений, на вход которого поступает SOAP-послание.
Каждое обращение к серверу исполнения бизнес-правил можно
представить как выполнение одного или нескольких условных опе¬
раторов. Если менеджер в некоторый момент времени решит, что
для получения платиновой карты достаточно совершить покупки
только на $700, то он может откорректировать эту цифру через до¬
ступную ему среду управления бизнес-правилами.
Обычно это делается с помощью графического конструктора.
Перед пользователем появляются список правил, отдельные поля
которых он может редактировать, при этом не требуется не только
перерабатывать код, но даже перезагружать систему.
Если по результатам эксплуатации системы появится идея до¬
полнить политику еще одним правилом, в соответствии с кото¬
рым покупателю, имеющему серебряную карту и истратившему
$1 200 сразу, выдается платиновая карта, то пользователь открыва¬
ет конструктор правил и с помощью одного из доступных ему ша¬
блонов создает новое правило посредством выбора значений эле¬
ментов нового правила из выпадающего списка, что также можно
сделать без перепрограммирования системы.
Для конкретных систем данный процесс может отличаться,
однако принципиальным является то, что бизнес-пользователь
может в определенных пределах изменять поведение системы без
внесения изменений в код.
-208-
В чем смысл принципа виртуальной машины
Практически все системы управления бизнес-правилами обес¬
печивают доступ к репозиторию бизнес-правил не только через GUI,
но и с помощью API, что позволяет, например, добавлять правила,
полученные автоматически, например с помощью систем извлече¬
ния знаний.
Преимущества от использования бизнес-правил. Использо¬
вание бизнес-правила потенциально позволяет достигнуть следу¬
ющих преимуществ:
- уменьшение времени разработки;
- оперативная реакция на изменения требований;
- возможность повторного использования кода;
- снижение стоимости разработки и владения ИС.
В системах, основанных на правилах, знания и логика пред¬
ставлены в виде множества правил — это отличает их от систем,
основанных на использовании традиционных языков программи¬
рования. Структура типовой системы, ориентированной на рабо¬
ту с правилами, показана на рис. 4.29, включает в себя множество
правил, базу данных фактов и подсистему логического вывода (дви¬
жок), используемого для обработки правил.
Рабочая память
п
Интерфейс
Запросы
Процессор
Запросы
W
логического
W
База знаний
I юльзова1еля
Результаты
вывода
Результаты
Рис. 4.29. Типовая система, ориентированная на работу с правилами
Обычно пользователь получает доступ к системе через тот или
иной пользовательский интерфейс. Запросы к системе выполняют¬
ся с помощью специального языка.
Подсистема логического вывода выполняет анализ запроса
пользователя и определяет логический вывод. В процессе выпол¬
нения вывода подсистема логического вывода по мере надобности
выбирает из базы знаний правила и данные. В базе знаний хранит¬
-209-
4. ПОЗНАКОМИМСЯ С КЛАССИЧЕСКИМИ ПЛАТФОРМАМИ И ПАРАДИГМАМИ
ся два типа данных: факты, относящиеся к домену задач, и набор
правил, также относящихся к домену задач. Подсистема логическо¬
го вывода применяет правила к данным до тех пор, пока не будет
получен результат. Рабочая память используется для хранения про¬
межуточных результатов.
Более сложные системы, основанные на правилах, могут содер¬
жать кроме перечисленных выше подсистем подсистему объясне¬
ния, которая представляет пользователю кроме конечного результа¬
та информацию о тех правилах, которые использовались в процессе
логического вывода.
В системах, основанных на правилах, используется два типа
логического вывода: прямой и обратный. Прямой логический вывод
инициируется появлением нового факта, а в результате примене¬
ния правил формируется некоторое заключение или выполняет¬
ся некоторое действие. При использовании обратного вывода в ка¬
честве исходных данных выступает некоторое утверждение (цель),
процесс логического вывода посредством применения правил под¬
тверждает истинность исходного высказывания или его ложность.
Возможно совместное применение прямого и обратного логическо¬
го вывода. Что касается практического применения систем, осно¬
ванных на правилах, то можно выделить три основных варианта их
использования: оболочка экспертной системы, которая может на¬
полняться фактами и правилами [71].
-210-
5
КАКОВЫ ОСОБЕННОСТИ
ПЕРСПЕКТИВНЫХ ПАРАДИГМ
И ПЛАТФОРМ
О СЕРВИСНО-ОРИЕНТИРОВАННЫХ
АРХИТЕКТУРАХ
Понятие сервисно-ориентированной архитектуры (СОА).
Сервис-ориентированная архитектура (service-oriented architec¬
ture, SOA) — это подход к созданию ИС, основанный на использо¬
вании сервисов или служб (service). Ниже термины «сервис» и «служ¬
ба» рассматриваются как синонимы. СОА — это в первую очередь
интеграционная архитектура, использование которой позволяет
обеспечить гибкую интеграцию приложений в рамках ИС. При ис¬
пользовании СОА приложения взаимодействуют, вызывая сервисы,
входящие в состав других приложений. Сервисы объединяются в бо¬
лее крупные последовательности, реализуя бизнес-процессы, кото¬
рые могут быть доступны как сервисы.
СОА можно рассматривать также как подход к построению сла¬
бо связанных (loosely coupled) ИС, реализующих механизмы асин¬
хронного взаимодействия. Термин СОА используется очень широко,
однако разные специалисты понимают его по-разному. Некоторые
рассматривают СОА как ИТ-инфраструктуру, ориентированную на
поддержку бизнеса, другие рассматривают СОА как средство повы¬
шения эффективности бизнеса. Применительно к тематике данно¬
-211-
5. КАКОВЫ ОСОБЕННОСТИ ПЕРСПЕКТИВНЫХ ПАРАДИГМ И ПЛАТФОРМ
го издания под СОА будем понимать слабо связанную архитектуру,
предназначенную для удовлетворения бизнес-потребностей орга¬
низации. Это определение никаким образом не фиксирует способ
реализации сервисов.
СОА можно рассматривать как философию проектирования ИС,
в соответствии с которой ИС строится на базе сервисов, которые
никаким образом не завязаны на конкретного производителя или
конкретную технологию.
Хотя в качестве сервиса может выступать любая бизнес-функ¬
ция, крайне желательно, чтобы имелась возможность повторного
использования бизнес-функций одним или разными приложени¬
ями. Примером может служить система журналирования, которая
присутствует практически в каждом приложении.
Во время выполнения каждый сервис размещается в одном
и только одном месте и удаленно вызывается всеми клиентами, ко¬
торые используют данный сервис. Достоинство подобного подхода
состоит в том, что изменения в интерфейс или реализацию серви¬
са, например изменение кода реализации или настроек, нужно вно¬
сить только в одном месте.
На этапе размещения каждый сервис создается один раз, но его
можно локально размещать в любой системе или наборе систем, ко¬
торым он необходим. Использование такого подхода позволяет по¬
высить гибкость в достижении нужной производительности, а так¬
же гибкость настройки сервиса.
Эталонная архитектура СОА. Наиболее полно и формально
понятие СОА определено в документе (спецификации), который
называется «эталонная архитектура СОА» (Reference Architectu¬
re Foundation for Service Oriented Architecture) [72]. Данная специ¬
фикация предложена глобальным консорциумом OASIS (Organi¬
zation for the Advancement of Structured Information Standards),
который занимается вопросами разработки и принятием про¬
мышленных стандартов, преимущественно в области электрон¬
ной коммерции.
В соответствии с этой спецификацией СОА определяется как
архитектурная парадигма, которая должна служить мостом между
-212-
О сервисно-ориентированных архитектурах
бизнесом и ИТ, при этом СОА не относится целиком ни к бизнесу,
ни к ИТ-сферам. При этом под бизнесом понимается произволь¬
ная деятельность, которой занимаются люди, а не только коммер¬
ческая деятельность. Основное назначение эталонной архитекту¬
ры состоит в том, чтобы обеспечить некоторый общий язык, на
котором могут общаться основные заинтересованные стороны
(stakeholders), к которым можно отнести архитекторов, менедже¬
ров, разработчиков. Особо следует отметить, что эталонная архи¬
тектура не описывает какую-то конкретную архитектуру, она не
ориентирована на конкретную технологию, она может быть опре¬
делена на нескольких уровнях.
В основу этой модели положены следующие основные по¬
сылки:
1) используемые ресурсы могут принадлежать разным органи¬
зациям;
2) взаимодействующие между собой люди и системы также мо¬
гут принадлежать разным организациям;
3) при построении СОА используются распределенные систе¬
мы управления и безопасности;
4) общение между людьми системами реализуется преимуще¬
ственно посредством обмена сообщениями.
Такое окружение в рамках рассматриваемой спецификации на¬
зывают СОА экосистемой (SOA ecosystem). Необходимость введения
данного понятия определяется тем, что часто бывает очень трудно
понять принципы функционирования системы, рассматривая толь¬
ко ее внутреннюю структуру. Особенно сложно сделать это в слу¬
чае, если отдельные автономные части активно взаимодействуют
с внешним миром. Для того чтобы адекватно описать функциони¬
рование таких систем, требуется понимать контекст, в котором они
функционируют. Сам термин «экосистема» пришел из биологии, где
под ним понимают систему, в которую входят растения, животные,
человек. В рамках эталонной модели СОА экосистема рассматрива¬
ется как сеть дискретных процессов, систем, а также человеческие
сообщества, которые создают, используют и управляют некоторы¬
ми сервисами, формируемыми по мере возникновения потребно¬
стей. Ни одна из организаций не может полностью контролировать
или управлять экосистемой.
-213-
5. КАКОВЫ ОСОБЕННОСТИ ПЕРСПЕКТИВНЫХ ПАРАДИГМ И ПЛАТФОРМ
Экосистема строится с использованием трех базовых
принципов:
1. СОА — это парадигма, которая должна быть положена
в основу системы обмена сообщениями между участниками (за¬
интересованными сторонами).
2. Участники (заинтересованные сторон) продолжают оста¬
ваться владельцами ресурсов, задействованных при построении
СОА экосистемы.
3. Поведение участников (заинтересованных сторон) опреде¬
ляется правилами, определяемыми самой СОА экосистемой, а так¬
же политиками и контрактами.
Эталонная СОА архитектура в полной мере согласована с под¬
робно рассмотренным выше стандартом ISO/IEC/IEEE 42010:2011.
В рамках эталонной СОА архитектуры определяются три вида
(views), которые совпадают с тремя точками зрения (viewpoints):
участие в СОА экосистеме, реализация СОА экосистемы и владение
СОА экосистемой.
Можно выделить два основных альтернативных подхода к реа¬
лизации СОА. Это микросервисы и Web-сервисы. Исторически пер¬
выми появились Web-сервисы. Микросервисы появились позже
и в значительной мере вытеснили Web-сервисы, по крайней мере
из корпоративных ИС.
Микросервисы. Идея микросервисной архитектуры (Microservice
architecture) состоит в том, что приложения строятся из сервисов
с ограниченной функциональностью (мелкозернистых (fine grained)
сервисов), каждый из которых работает в собственном процессе
и может общаться с другими сервисами посредством простых ме¬
ханизмов, таких как протокол http. Управление системой сервисов
может быть как централизованным, когда имеется некоторый про¬
цессор (engine), который может вызывать сервисы последовательно
или параллельно, так и децентрализованным, когда сервисы взаимо¬
действуют по принципу одноранговой системы. Сервисы являются
независимыми как при развертывании, так и при масштабирова¬
нии. Различные сервисы могут разрабатываться с использовани¬
ем разных языков программирования и разными командами раз¬
работчиков.
-214-
О сервисно-ориентированных архитектурах
В настоящее время нет общепринятого определения понятия
«микросервисная архитектура». Считается, что типовая микросер¬
висная архитектура обладает следующими свойствами:
1. Система строится из небольших по объему модулей, каждый
из которых реализует одну функцию, которая ориентирована на ре¬
шение определенной бизнес-задачи. Модуль имеет четко опреде¬
ленный интерфейс, который известен другим модулям.
2. Все сервисы работают на одном уровне. В случае, когда сер¬
висов становится слишком много, система может строиться по
сотовому принципу. Каждая сота представляет собой отдельную
экосистему. Соседние соты могут взаимодействовать через погра¬
ничные сервисы.
3. Модули взаимодействуют по принципу «каждый с каждым»,
используя относительно простые механизмы. В принципе, могут
использоваться как синхронные, так и асинхронные механизмы
взаимодействия.
4. Сервисы могут проектироваться разными группами разра¬
ботчиков на разных платформах, которые работают независимо
друг от друга.
5. Сервисы могут быть развернуты независимо друг от друга,
в автоматическом режиме.
Микросервисные архитектуры начинают находить применение
во многих реальных ИС. Подавляющее большинство известных ИТ
компаний перешло от монолитных к микросервисным решениям.
Опыт практического применения микросервисных архитектур
показал их сильные и слабые стороны.
Основными достоинствами микросервисов являются следу¬
ющие:
- использование микросервисных архитектур открывает перед
архитекторами широкие возможности, поскольку позволяет разра¬
батывать и размешать сервисы независимо друг от друга;
- отдельные сервисы могут быть реализованы на разных язы¬
ках и на разных платформах;
- каждый отдельный микросервис может разрабатываться не¬
большой командой разработчиков;
- микросервисы относительно легко интегрировать в систему;
-215-
5. КАКОВЫ ОСОБЕННОСТИ ПЕРСПЕКТИВНЫХ ПАРАДИГМ И ПЛАТФОРМ
- ИС, построенные с использованием микросервисных архитек¬
тур, легко модифицируются;
- при построении отдельных микросервисов можно использо¬
вать самые новые технологии, что позволяет говорить о микросер¬
висных архитектурах как средстве интеграции технологий;
- микросервисы можно рассматривать как компонент, ориен¬
тированный на повторное использование;
- микросервисные решения просты для понимания разработ¬
чиками, что позволяет привлекать сторонних разработчиков.
Основными недостатками микросервисных архитектур яв¬
ляются следующие:
- микросервисые архитектуры существенно проигрывают по
скорости работы по сравнению с монолитными, и возможность их
использования в системах даже мягкого реального времени вызы¬
вает сомнение;
- микросервисные системы сложны в отладке;
- микросервисные системы по своей сути являются одноуров¬
невыми системами, поэтому при увеличении числа входящих в них
сервисов организация управления в таких системах может оказать¬
ся непростой задачей;
- отсутствие общей теории построения микросервисных систем
приводит к тому, что декомпозиция системы на отдельные сервисы
продолжает оставаться искусством.
Опыт проектирования и практического применения микро¬
сервисных систем показал, что больше всего этот подход подходит
для построения распределенных ИС небольшого и среднего раз¬
мера, которые могут управляться централизованно. К этой груп¬
пе относятся, в частности, приложения, построенные с использо¬
ванием облачных сервисов.
REST. REST (Representational State Transfer) — иногда этот термин
переводят как «передача состояния представления», но чаще всего
используют термин REST без расшифровки. Обычно REST опреде¬
ляют как архитектурный стиль, ориентированный на использова¬
ние в распределенных системах. Системы, поддерживающие REST,
называются RESTfuZ-системами. Основная идея REST-архитектуры
-216-
О сервисно-ориентированных архитектурах
состоит в том, что мир (Интернет) состоит из множества ресурсов,
каждому из которых ставится в соответствие URL, используя кото¬
рый можно обращаться к ресурсу для того, чтобы узнать или из¬
менить его состояние. Для работы с ресурсами пользователю пре¬
доставляется набор методов, таких как GET, POST, PUT и DELETE.
Данные должны передаваться в виде небольшого количества стан¬
дартных форматов (например, HTML, XML, JSON).
Иногда REST противопоставляют RPC. Основное отличие состо¬
ит в том, что подход, основанный на RPC, позволяет использовать
произвольные процедуры на стороне сервера, а REST позволяет вы¬
полнять ограниченный набор действий, поэтому можно говорить,
что REST, с точки зрения пользователя, — более простой протокол.
Для передачи данных REST обычно использует HTTP протокол, хо¬
тя могут использоваться и другие протоколы, а RPC работает на¬
прямую через сокеты, т. е. скорость работы RPC будет выше. Несом¬
ненным достоинством REST является использование URI в качестве
системы именований.
REST-архитектура предполагает наличие клиента и сервера.
Клиент инициирует запросы к серверу; который обрабатывает за¬
прос и возвращает ответы. Запрос и ответ формируются в терминах
представлений ресурсов. Ресурс может быть любым адресуемым
объектом, а его представлением может быть документ, отражаю¬
щий текущее или требуемое состояние ресурса. В конкретный мо¬
мент времени клиент может находиться либо в состоянии покоя, ли¬
бо в состоянии перехода между состояниями.
Когда клиент хочет перейти в новое состояние, он посылает за¬
прос серверу. Пока один или более запросов не выполнены, кли¬
ент находится в состоянии перехода. REST является относительно
простым интерфейсом управления информацией, каждая единица
которой однозначно определяется глобальным идентификатором,
таким как URL. Каждая единица информации однозначно опреде¬
ляется URL, который можно рассматривать как первичный ключ для
соответствующей единицы данных. Например, если формируется
сборник статей, то, например, пятая статья в сборнике определяет¬
ся как /book/5, а вторая страница этой статьи — /book/5/page/2. При
этом не уточняется, в каком формате представлена статья. Это мо¬
жет быть pdf, docx или rtf. Чаще всего в рамках REST используется
-217-
5. КАКОВЫ ОСОБЕННОСТИ ПЕРСПЕКТИВНЫХ ПАРАДИГМ И ПЛАТФОРМ
протокол http, для которого действия над данными задаются с по¬
мощью методов: GET (получить), PUT (добавить, заменить), POST
(добавить, изменить, удалить), DELETE (удалить). Таким образом,
действия CRUD (Create-Read-Updae-Delete) могут выполняться как
со всеми 4-мя методами, так и только с помощью GET и POST. На¬
пример: GET /book/ — означает получить список всех статей, GET /
book/12/ — получить статью номер 12, PUT /book/ — добавить статью
(данные в теле запроса), POST /book/12 — изменить статью (данные
в теле запроса), DELETE /book/12 — удалить статью.
Архитектура REST используется достаточно часто при постро¬
ении таких приложений, как интернет-магазины, поисковые сис¬
темы и прочие системы, основанные на данных. В частности, эта
архитектура является ключевой при построении микросервисных
систем [73].
КАК РАБОТАЮТ WEB-СЕРВИСЫ
В самом общем виде понятие Web-сервиса можно определить
как сервис (услугу), который предоставляется через WWW с ис¬
пользованием языка XML и протокола HTTP. Практически все ве¬
дущие ИТ-компании положительно относились к использованию
Web-сервисов, поэтому Web-сервисы можно использовать в каче¬
стве механизма интеграции приложений, реализованных на лю¬
бых платформах.
Существует много разных определений понятия Web-серви¬
са. В качестве «официального» определения можно рассматривать
определение, которое дается консорциумом W3C: «Web-сервис
представляет собой приложение, которое идентифицируется стро¬
кой URI. Интерфейсы и привязки данного приложения описывают¬
ся и обнаруживаются с использованием XML-средств. Приложения
взаимодействуют посредством обмена сообщениями, которые пе¬
ресылаются с использованием Интернет-протоколов».
Иногда вместо термина «Web-сервисы» используется термин
«Web-услуги», в данной книге эти термины рассматриваются как
синонимы.
-218-
Как работают Web-сервисы
Web-сервис — это парадигма реализации сервисов через Web.
Для обмена данными web-сервис использует такие протоколы, как
XML, HTTP, TCP/IP, т. е. протоколы, которые поддерживают практи¬
чески все производители.
Web-сервисы оказали очень существенное влияние на под¬
ходы к построению распределенных систем, поскольку обладают
такими ценными свойствами, как самоописываемость, их легко
создавать, размещать, регистрировать и находить в репозитори¬
ях. Для того чтобы работать с сервисами, достаточно знать их ин¬
терфейсы. Унаследованные приложения могут быть относитель¬
но легко оформлены в виде Web-сервисов.
Web-сервисы представляют собой самостоятельные модульные
приложения, которые могут быть описаны, опубликованы, разме¬
щены и вызваны как локально, так и удаленно. Web-сервисы могут
инкапсулировать как простейшие бизнес-функции типа «запрос¬
ответ», так и полномасштабные взаимодействия бизнес-процессов.
Службы могут создаваться заново или строиться на основе сущест¬
вующих приложений методом «обертывания».
Архитектура Web-сервисов. Наиболее важными компонен¬
тами архитектуры Web-сервисов являются: пользователь сервиса
(клиент) и провайдер сервиса (сервер). Провайдер должен опу¬
бликовать (зарегистрировать) сервис в репозитории, который
может быть реализован, в частности, как UDDI-реестр (Universal
Description, Discovery, and Integration (UDDI) registry). UDDI-реестр
внешне выглядит как Web-сервис и в нем хранится информа¬
ция о зарегистрированных сервисах. Клиент может обращаться
к UDDI-реестру с запросами о месте нахождения отдельных сер¬
висов и способах обращения к ним. Следует отметить, что для
обращения к Web-сервисам клиент не обязательно должен пред¬
варительно обращаться к тому или иному репозиторию. Если
клиенту известны место нахождения сервиса и его интерфейс,
то он может обращаться к сервису напрямую. Множество про¬
токолов, используемых для работы с Web-сервисами, составля¬
ют стек (рис. 5.1).
-219-
5. КАКОВЫ ОСОБЕННОСТИ ПЕРСПЕКТИВНЫХ ПАРАДИГМ И ПЛАТФОРМ
UDDI, ebXML
WSDL
SOAP, XML-RPC
HTTP, JMS, FTP, SMTP
Рис. 5.1. Стек протоколов, используемых
для работы с Web-сервисами
На нижнем уровне находятся транспортные протоколы, ко¬
торые отвечают за доставку сообщений (HTTP, JMS, FTP, SMTP).
Протоколы, определяющие форматы сообщений (SOAP, XML-
RPC), располагаются на следующем уровне. На третьем уровне
располагается протокол WSDL (Web Services Description Language,
язык описания Web-сервисов). На четвертом уровне располага¬
ются протоколы, определяющие механизмы обнаружения Web-
сервисов, такие как UDDI и ebXML. Кроме перечисленных, име¬
ется большое число вспомогательных протоколов, которые часто
называют WS*.
Язык XML (eXtensible Markup Language) является основным при
работе с Web-сервисами. Подробную информацию об этом язы¬
ке можно найти, например, в [74] и многих других книгах, посвя¬
щенных XML. XML можно рассматривать как надмножество HTML.
В XML пользователь может вводить и использовать собственные те¬
ги. Любой XML-документ регламентируется метаданными, которые
находятся в специальном файле.
Метаданные — это данные, которые описывают данные, на¬
пример можно указать, что в году ровно 12 месяцев, в месяце мо¬
жет быть от 28 до 31 дня, в почтовом индексе должно быть ровно
6 цифр и т. д.
Непосредственным предшественником Web-сервисов являлся
протокол XML-RPC. Это очень простой протокол, предназначенный
для вызова удаленных процедур. В отличие от традиционного RPC
для вызова удаленной процедуры используются XML-послания. От¬
вет приходит также в форме XML-послания.
-220-
Как работают Web-сервисы
Механизм XML-RPC был создан в середине 1990-х гг., однако не
получил широкого распространения. Причины этого достаточно по¬
нятны и состоят в следующем:
1. Запросы, выполняемые в рамках XML-RPC, только отчасти
являются самоописываемыми, поскольку пространства имен в нем
не определены.
2. XML-RPC, подобно классическому RPC, не поддерживают ра¬
боту с объектами.
3. При работе с XML-RPC появляются проблемы, вызванные ис¬
пользованием XML. На стороне клиента необходимо сформировать
запрос. На стороне сервера необходимо его разобрать. То же самое
требуется сделать с ответом. Все это усложняет код и требует суще¬
ственных временных затрат.
4. Сообщения, отправляемые в формате XML, за счет тегов име¬
ют большую избыточность.
Протокол SOAP. SOAP — это основанный на XML прото¬
кол, определяющий механизм обмена сообщениями. Протокол
SOAP появился в 1998 г. как W3C спецификация. В ранних верси¬
ях спецификации SOAP расшифровывался как Simple Object Access
Protocol. В последних версиях этот термин никак не расшифро¬
вывается.
Хотя SOAP имеет много общего с XML-RPC, но имеются
и принципиальные отличия. Во-первых, протокол SOAP не раз¬
личает вызов процедуры и ответ на него, а просто определяет фор¬
мат послания (message) в виде документа XML, который может со¬
держать вызов процедуры, ответ на него, запрос на выполнение
каких-то других действий или просто текст, а во-вторых, SOAP-по¬
слание представляет собой самоописываемый документ, включа¬
ющий, в частности, описания пространств имен.
Структуру SOAP-послания определяет соответствующая ему
XML Schema. Для пересылки SOAP-посланий обычно используется
HTTP POST метод, хотя можно использовать и другие протоколы,
такие как FTP, SMTP. SOAP-послание включает два элемента: за¬
головок (Header) и тело (Body), которые помещаются в контейнер
(Envelope). SOAP-послание представляет собой правильный XML-до-
-221-
5. КАКОВЫ ОСОБЕННОСТИ ПЕРСПЕКТИВНЫХ ПАРАДИГМ И ПЛАТФОРМ
кумент. Заголовок является факультативным элементом, а тело —
обязательным.
WSDL описание. WSDL используется для описания интерфей¬
сов Web-сервисов. Средствами WSDL можно описать, где находит¬
ся Web-сервис и каким образом к нему следует обращаться. WSDL-
описание позволяет создавать независимое от платформы и языка
реализации описание Web-сервиса.
Спецификации WS-*. Помимо основных спецификаций и стан¬
дартов, таких как SOAP WSDL и UDDI, существует ряд специфика¬
ций, предназначенных для расширения концепции Web-сервисов
на основе SOAP и WSDL с целью обеспечения надежности, безопас¬
ности, поддержки состояния и качества обслуживания.
Для чего выполняется оркестровка
и хореография Web-сервисов
Web-сервисы представляют собой интерфейсы для доступа
к автономным, модульным приложениям. Для того чтобы обратить¬
ся к Web-сервису, необходимо послать SOAP-послание по опреде¬
ленному адресу, который представляет собой XML-документ, при
этом не имеет значения, каким именно образом формируются эти
послания.
BPEL (Business Process Execution Language) — это язык, который
позволяет описывать бизнес-процесс в терминах некоторой после¬
довательности обращения к Web-сервисам. BPEL, по существу, яв¬
ляется скриптовым языком программирования, который поддер¬
живает синхронные и асинхронные взаимодействия, параллельное
выполнение и обработку исключений. Программа (приложение),
написанная на языке BPEL, является XML-документом. Язык BPEL
позволяет задавать бизнес-процессы, при этом приложение, напи¬
санное на языке BPEL, можно рассматривать как Web-сервис, и к не¬
му можно обращаться посредством посылки SOAP-посланий.
BPEL является интерпретируемым языком, и для его использо¬
вания необходимо наличие процессора (движка).
Основу BPEL составляют три ключевых свойства: асинхрон¬
ность, координация потоков и управление исключительными си¬
туациями.
-222-
Как работают Web-сервисы
Асинхронность имеет дело с асинхронными взаимодействия¬
ми, корреляцией сообщений и надежностью. За счет разделения за¬
просов на обслуживание и соответствующих им откликов асинхрон¬
ность повышает масштабируемость и помогает избежать узких мест
при выполнении приложения. Кроме того, она допускает непреры¬
ваемое выполнение, когда сервисы временно недоступны и когда
клиенты работают в автономном режиме или отключены.
Координация потоков включает параллельные потоки выполне¬
ния, образцы соединений и динамические потоки. В реальных при¬
ложениях бизнес-потоки могут включать образцы сложных взаи¬
модействий как с синхронными, так и с асинхронными сервисами.
Координация потока включает интерфейс с WSDL, действия пото¬
ка, переменные XML и отвечает за координацию. BPEL использует
WSDL для обращения к сообщениям, вызванным операциям и ти¬
пам портов. Действия с потоком используют общие переменные
XML, так что компенсационные обработчики (compensation handlers)
должны сохранять снимки данных, которые могут быть использова¬
ны обработчиком. Компенсационные обработчики могут отменить
шаги, которые были уже завершены.
Управление исключительными ситуациями. Управление исклю¬
чительными ситуациями имеет дело с синхронными ошибками,
асинхронным управлением исключительными ситуациями и ком¬
пенсацией бизнес-транзакций. Для того чтобы автоматизиро¬
вать бизнес-процессы, большие усилия сосредоточены на управле¬
нии исключительными ситуациями, и BPEL упрощает управление
исключительными ситуациями для Web-сервисов. При возникно¬
вении исключительных ситуаций вызываются локальные обработ¬
чики ошибки, связанные с Web-сервисами, и асинхронные сервисы
уведомляются об этих исключительных ситуациях.
Принято выделять два основных подхода к объединению Web-
сервисов в бизнес-процессы:
- оркестровка (Orchestration);
- хореография (Choreography).
Идея оркестровки состоит в том, что в системе имеется един¬
ственный BPEL-процессор (движок), который выполняет функции
интерпретатора BPEL-файлов. Для внешнего мира BPEL-процес¬
сор доступен как Web-сервис. Получив запрос, движок уже от свое¬
-223-
5. КАКОВЫ ОСОБЕННОСТИ ПЕРСПЕКТИВНЫХ ПАРАДИГМ И ПЛАТФОРМ
го имени рассылает SOAP-послания Web-сервисам, участие которых
необходимо для реализации бизнес-процесса. Задействованные
Web-сервисы не знают, что они вовлечены в бизнес-процесс более
высокого уровня. Только движок обладает полной информацией
о выполняемой задаче, и поэтому оркестровка является централи¬
зованным механизмом с явным определением операций и поряд¬
ком инициирования работы Web-сервисов (рис. 5.2).
Рис. 5.2. Схема оркестровки
Использование хореографии (рис. 5.3), напротив, не предпола¬
гает использования центрального координатора.
Рис. 5.3. Схема хореографии
Каждому из Web-сервисов, участвуюших в хореографии, извест¬
но, когда следует выполнить те или иные операции и с какими Web-
-224-
Как выполняются облачные вычисления
сервисами необходимо взаимодействовать. Хореография пред¬
ставляет собой совместное действие, ориентированное на обмен
сообщениями при реализации бизнес-процессов, в которых участ¬
вует несколько организаций, при этом все участники должны знать
бизнес-процесс, выполняемые операции, сообщения, которыми они
обмениваются, и синхронизировать эти обмены сообщениями.
На первый взгляд, кажется, что оркестровка и хореография
представляют собой альтернативные подходы к организации биз¬
нес-процессов, однако если предположить, что за Web-сервисами,
участвующими в оркестровке, стоят отдельные движки, то разли¬
чия между оркестровкой и хореографией уже не столь очевидны.
Обычно оркестровка используется для создания исполняемых
BPEL-файлов, а хореография — как средство для описания прото¬
колов, описывающих взаимодействие, например, между органи¬
зациями, при этом не предполагается использовать эти описания
в качестве исполняемых файлов.
BPEL поддерживает два различных способа описания бизнес¬
процессов, которые поддерживают оркестровку и хореографию.
Исполняемые процессы (Executable processes) позволяют опре¬
делять точную детализацию бизнес-процессов. Исполняемый про¬
цесс моделирует поведение участников определенного бизнес¬
взаимодействия, в сущности, моделируя частный поток работ.
Исполняемые процессы находятся в парадигме оркестровки и мо¬
гут быть выполнены механизмом оркестровки.
Абстрактные бизнес-протоколы (Abstract business protocols)
определяют обмен публичными сообщениями между участниками.
Они не включают внутренние детали потока процессов, не являют¬
ся выполнимыми и находятся в парадигме хореографии.
КАК ВЫПОЛНЯЮТСЯ ОБЛАЧНЫЕ ВЫЧИСЛЕНИЯ
Идея облачных вычислений состоит в предоставлении пользо¬
вателям удаленного доступа к сервисам, вычислительным ресурсам
и приложениям через Интернет. Набор ресурсов, предоставляемых
-225-
5. КАКОВЫ ОСОБЕННОСТИ ПЕРСПЕКТИВНЫХ ПАРАДИГМ И ПЛАТФОРМ
конечному пользователю ресурсов, может динамически масштаби¬
роваться в сторону увеличения или уменьшения в зависимости от
нагрузки.
При этом плата с пользователей облачных платформ может
взиматься в зависимости от уровня потребления, тарификация воз¬
можна по времени работы приложений потребителя, по объему об¬
рабатываемых данных и количеству транзакций над ними, по сете¬
вому трафику. Такой подход обычно называют вычислениями по
запросу (on demand computing).
I Облака, как правило, строятся на базе крупных центров об-1
I работки данных, которые ориентированы на внешнего потре-1
бителя. При этом центры создают иллюзию единого облачного
ресурса, в то время как на самом деле может быть использовано
; много географически распределенных ресурсов. Это обеспечи-;
I вает пользователю независимость от местоположения. Серви-1
сы, которые работают в облаке, отличаются от традиционного
! программного обеспечения своей конструкцией и реализаци-!
| ей. Облачные приложения могут разрабатываться и разверты-1
ваться быстрее и в меньшей степени зависеть от изменчиво¬
сти среды.
Согласно документу IEEE, опубликованному в 2008 г., облач¬
ные вычисления обычно определяют как парадигму, в рамках ко¬
торой информация постоянно хранится на серверах в Интернете
и временно кэшируется на клиентской стороне, например на пер¬
сональных компьютерах, игровых приставках, ноутбуках, смартфо¬
нах и так далее, и предоставляется конечному пользователю в фор¬
ме сервисов.
Национальный институт стандартов и технологий CША (NIST)
определяет облачные вычисления (Cloud Computing) как «модель
обеспечения повсеместного сетевого доступа по требованию к сов¬
местно используемому пулу конфигурируемых вычислительных
ресурсов, которые можно быстро предоставить и внедрить с ми¬
нимумом административных усилий или взаимодействия с сервис-
провайдером» [75].
-226-
Как выполняются облачные вычисления
Облачные вычисления по замыслу создателей должны: реа¬
лизовывать самообслуживание по требованию, обеспечивать ши¬
рокополосный сетевой доступ, поддерживать пул ресурсов, обес¬
печивать возможность быстрой перенастройки или расширения
и иметь измеряемое обслуживание.
Облачные провайдеры обычно поддерживают целый ряд сер¬
висов.
На рис. 5.4 показаны типовые модели облачных вычислений. Мо¬
дель облачных вычислений можно представить в виде виртуальной
девятислойной машины, которая отображается на две другие вирту¬
альные машины, в качестве которых выступают облачная структура,
реализованная на стороне провайдера, и пользовательская структу¬
ра. Виртуальная машина облачных вычислений включает следующие
слои: сетевой слой, хранилища ДИЗ, серверный слой, слой виртуа¬
лизации, операционная система, промежуточное ПО, среда выпол¬
нения, данные и собственно приложения. Отдельные слои связаны
между собой интерфейсами. Интерфейсы определенного уровня мо¬
гут быть доступны пользователю в форме сервисов.
Сеть Инфраструктура
как сервис как сервис
Приложения
Приложения
Данные
Данные
Среда
выполнения
Среда
выполнения
Промежу¬
точное ПО
Промежу¬
точное ПО
ОС
ОС
Виртуали¬
зация
Виртуали¬
зация
Серверы
Серверы
Хранилище
Хранилище
Сеть
Сеть
Платформа ПО
как сервис как сервис
Приложения
Данные
Среда
выполнения
Промежу¬
точное ПО
ОС
Виртуали¬
зация
Серверы
Хранилище
Сеть
Приложения
Данные
Среда
выполнения
Промежу¬
точное ПО
ОС
Виртуали¬
зация
Серверы
Хранилище
Сеть
Рис. 5.4. Типовые модели облачных вычислений
-227-
5. КАКОВЫ ОСОБЕННОСТИ ПЕРСПЕКТИВНЫХ ПАРАДИГМ И ПЛАТФОРМ
С точки зрения распределения функций между облаком, кото¬
рое находится на стороне провайдера, и конечным пользователем
можно выделить четыре базовых варианта.
В качестве основных обычно выделяют четыре модели:
1) сеть как сервис (Network As A Service, NaaS);
2) инфраструктура как сервис (Infrastructure As A Service, IaaS);
3) платформа как сервис (Platform As A Service, PaaS);
4) программное обеспечение как сервис (Software A Service, SaaS).
NaaS предоставляет конечному пользователю защищенную се¬
тевую инфраструктуру и сервисы поддержки сетевых взаимодей¬
ствий. Идея состоит в том, чтобы вместо того чтобы строить кор¬
поративную сеть, можно просто реализовать требуемую сетевую
структуру в облаке на стороне провайдера.
IaaS была изначальной концепцией облачных сервисов.
В этой модели провайдер создает масштабируемые эмулято¬
ры аппаратуры в облаке и предоставляет сервисы, позволяю¬
щие пользователю запускать собственные виртуальные машины,
что обеспечивает максимальную гибкость при развертывании,
однако использование этой модели требует больших усилий со
стороны пользователя в плане построения КИС. В этом случае
пользователь освобождается от необходимости приобретать соб¬
ственное серверное оборудование. В IaaS пользователю предо¬
ставляется возможность самостоятельно управлять ресурсами
обработки, хранения, сетями, например он (она) может устанав¬
ливать и запускать произвольное программное обеспечение, та¬
кое как ОС, платформенное и прикладное ПО, контролировать
ОС, виртуальные системы хранения данных и установленные
приложения.
Управление и контроль за основной физической и виртуаль¬
ной инфраструктурой облака, в том числе сетями, серверами, осу¬
ществляются провайдером. Основное достоинство такого подхода
состоит в том, что отпадает необходимость в приобретении физи¬
ческого оборудования, организации его обслуживания.
PaaS использует базовое оборудование и программные сред¬
ства нижнего уровня, предоставляемые облаком. В этом случае ко-
-228-
Как выполняются облачные вычисления
нечный пользователь просто использует расположенное на сторо¬
не провайдера аппаратное обеспечение центра обработки данных,
операционную систему, промежуточное ПО и различные базы дан¬
ных для размещения своих приложений или сервисов. Промежуточ¬
ное ПО может включать, в частности, базы данных. Разница между
PaaS и IaaS заключается в том, что при использовании PaaS конеч¬
ный пользователь получает доступ к масштабируемой инфраструк¬
туре, проверенному промежуточному ПО и операционной системе.
Это могут быть, в частности, контейнеры типа Docker. PaaS — это
модель предоставления облачных сервисов, при которой пользова¬
тель получает доступ к использованию информационно-технологи¬
ческих платформ, включая ОС, СУБД, промежуточному ПО, инстру¬
ментальным средствам разработки и тестирования, размещенным
у облачного провайдера.
В этой модели вся информационно-технологическая ин¬
фраструктура полностью управляется провайдером, который
также определяет состав доступных для потребителей видов
платформ и управляемых параметров платформ, а пользова¬
тель может использовать платформы, создавать их виртуаль¬
ные экземпляры, устанавливать, разрабатывать, тестировать,
эксплуатировать на них прикладное программное обеспечение,
при этом динамически изменяя количество потребляемых вы¬
числительных ресурсов.
SaaS является основой облачных вычислений. У провайдера
обычно имеется набор приложений и сервисов, которые предлага¬
ются конечным пользователям с помощью таких клиентов, как мо¬
бильные устройства, тонкие клиенты или фреймворки в других об¬
лаках. С точки зрения пользователя, виртуальный SaaS фактически
работает на клиенте пользователя. Эта абстракция программного
обеспечения позволила отрасли добиться значительного роста в об¬
лачном сервисе. Примером SaaS может служить облачная реализа¬
ция Microsoft Office. SaaS — это модель использования бизнес-при¬
ложений в качестве интернет-сервисов. SaaS-приложения работают
на сервере провайдера. Пользователь не покупает, а арендует при¬
ложение и работает с ним через браузер.
-229-
5. КАКОВЫ ОСОБЕННОСТИ ПЕРСПЕКТИВНЫХ ПАРАДИГМ И ПЛАТФОРМ
В качестве преимуществ SaaS по сравнению с традиционным
программным обеспечением обычно указывают следующие: низ¬
кая стоимость владения, более короткие сроки внедрения, возмож¬
ность оперативно и часто бесплатно протестировать приложение,
поддержка и обновление системы обеспечивается, возможность
работать через Интернет, что очень удобно для географически
распределенных компаний и удаленных сотрудников, минималь¬
ные требования к производительности компьютера пользователя,
кросс-платформенность. Основные недостатки — это риски, свя¬
занные с передачей коммерческих данных стороннему провай¬
деру, ограниченная скорость работы приложения и возможности
сбоев в связи с необходимостью работать через Интернет.
Приведенный список сервисов далеко не полный. В настоящее
время провайдеры предлагают очень много разнообразных облач¬
ных сервисов, для обозначения всего множества сервисов исполь¬
зуют термин «все как сервис» (XaaS).
Использование различных типов облачных сервисов в разной ме¬
ре ограничивает свободу пользователя. Отличия в границах управля¬
емости для различных типов облачных сервисов показаны в табл. 5.1.
Таблица 5.1
Отличия в границах управляемости
для различных типов облачных сервисов
Показатели
Собственная
IT-инфраструктура
SaaS
IaaS
PaaS
Приложения
+
+
+
-
Данные
+
+
+
-
Промежуточное ПО
+
+
-
-
ОС
+
-
-
-
Виртуализация
+
-
-
-
Серверы
+
-
-
-
Сетевая инфраструктура
+
-
-
-
-230-
Как выполняются облачные вычисления
Из табл. 5.1 видно, что при развертывании собственной IT-
инфраструктуры пользователь может управлять всеми ее компо¬
нентами — от сетевых ресурсов до выполняющихся приложений.
При использовании модели IaaS пользователь может контролиро¬
вать данные, приложения и промежуточное ПО, а при использо¬
вании модели PaaS все компоненты платформы предоставляются
пользователю как сервисы с ограниченными возможностями для
управления ими. Таким образом, пользователь получает в свое рас¬
поряжение оптимально сконфигурированную платформу, не требу¬
ющую дополнительных настроек.
Модели развертывания. Можно выделить четыре основные
модели развертывания облачных сервисов:
1. Публичное облако (public cloud) представляет собой инфра¬
структуру, предназначенную для свободного использования, и может
находиться в собственности, управлении и эксплуатации коммерче¬
ских, научных и правительственных организаций (или какой-либо
их комбинации). Владельцем облака является поставщик сервисов.
2. Общественное облако (community cloud) может находить¬
ся в совместной собственности, управлении и эксплуатации одной
или более из организаций сообщества или третьей стороны. Физи¬
чески оно может существовать как внутри, так и вне юрисдикции
владельца.
3. Частное облако (private cloud) ориентировано на использо¬
вание в рамках одной организации, но может включать несколь¬
ко групп пользователей, например подразделений одной организа¬
ции. Частное облако может находиться в собственности, управлении
и эксплуатации как самой организации, так и третьей стороны (или
какой-либо их комбинации). Физически оно может существовать
как внутри, так и вне юрисдикции владельца.
4. Гибридное облако (hybrid cloud) представляет собой ком¬
бинацию публичных, общественных или частных, облачных ин¬
фраструктур, остающихся уникальными объектами, но связанных
между собой стандартизованными или частными технологиями пе¬
редачи данных и приложений.
К основным характеристикам облачных платформ обыч¬
но относят: масштабируемость, эластичность, многофункциональ¬
ность, самообслуживание по требованию, билинг.
-231-
5. КАКОВЫ ОСОБЕННОСТИ ПЕРСПЕКТИВНЫХ ПАРАДИГМ И ПЛАТФОРМ
Масштабируемость можно определить как способность вы¬
держивать растущие нагрузки и обрабатывать большие объемы
данных, быстрая и надежная работа, исключающая отказы в обслу¬
живании, задержки в ответах от системы и сбои, позволяющая по¬
высить удовлетворенность и лояльность пользователей.
Эластичность можно определить как способность реагировать
на изменяющиеся условия ведения бизнеса, например сложившая¬
ся рыночная конъюнктура и действия конкурентов могут потребо¬
вать быстро внедрить новый сервис, выполнив полный цикл плани¬
рования, проектирования и разработки ИС. Эластичность позволяет
оперативно наращивать мощность облачной инфраструктуры при
минимальных инвестициях в оборудование и ПО. Эластичность тес¬
но связана с масштабируемостью приложений, так как решает за¬
дачу моментального изменения количества выделяемых для рабо¬
ты вычислительных ресурсов.
Многофункциональность можно рассматривать как один из
способов снижения расходов за счет максимального использова¬
ния общих ресурсов для обслуживания разных организаций и раз¬
личных групп пользователей. Многофункциональность может быть
особенно привлекательна для разработчиков приложений, так как
позволяет снизить собственные расходы на оплату ресурсов облач¬
ной платформы и максимально использовать доступные вычисли¬
тельные ресурсы.
Самообслуживание по требованию можно определить как
наличие у пользователя возможности самостоятельно определять
и изменять параметры сервисов, такие как скорость доступа, объ¬
ем хранимых данных, без взаимодействия с провайдером сервисов.
Биллинг обычно определяют как комплекс процессов и реше¬
ний, ответственных за сбор информации об использовании серви¬
сов, их тарификацию, выставление счетов абонентам. Провайдер
автоматически исчисляет потребленные ресурсы на определенном
уровне абстракции, например объем хранимых данных, пропуск¬
ная способность, количество пользователей, количество транзак¬
ций, и на основе этих данных оценивает объем предоставленных
потребителям услуг.
Другие типы облачных сервисов. SaaS, IaaS и PaaS — это толь¬
ко основные модели облачных сервисов. В первую очередь в рам¬
-232-
Как выполняются облачные вычисления
ках гибридных облаков предлагается большое число других моде¬
лей. Рассмотрим некоторые из них.
При использовании модели компонент как сервис, облако
превращается из среды, основанной на SaaS, в экосистему, в кото¬
рой приложения сокращаются до своих основных функций и предо¬
ставляются как компоненты, при этом под компонентом понима¬
ется готовая, независимая часть бизнес-функциональности. Подход
«каждый компонент как сервис» (XaaS), напоминающий многочи¬
сленные и разнообразные Web-сервисы, стал центральной кон¬
цепцией вычислений на основе гибридного облака. Выбор компо¬
нентов «как сервис» быстро растет, что делает модель гибридного
облака все более привлекательной.
Например, в современном офисе часто используется компо¬
нент «связь как сервис», который включает такие сервисы, как го¬
лос поверх интернет-протокола (VoIP) и единая связь (Unified
Communications), в которую входят обмен мгновенными сообщени¬
ями, видеоконференции и интерактивная доска. «Связь как сервис»
позволяет сотрудникам предприятия быстрее и эффективнее взаи¬
модействовать и общаться.
Достаточно часто популярным является подход «рабочий стол
как сервис». При использовании этой модели провайдер несет от¬
ветственность за хранение данных, резервное копирование, обес¬
печение безопасности и обновления.
При использовании гибридных облаков основные функции
можно предоставлять как сервисы. «Сеть как сервис» — это ком¬
бинация предложений «платформа как сервис» (PaaS) и «инфра¬
структура как сервис» (IaaS). Используя «сеть как сервис», сетевые
ресурсы можно наращивать и сокращать в зависимости от их фак¬
тического использования.
«Хранение как сервис» — это способ арендовать дисковое про¬
странство, обеспечивая экономию расходов на персонал, обору¬
дование и физические запоминающие устройства. К этому можно
добавить «базу данных как сервис», «мониторинг как сервис», что
позволяет дистанционно контролировать и управлять сетями, при¬
ложениями и службами; а «безопасность как сервис» обеспечивает
управление учетными записями и доступом. В гибридном облаке
легко управлять всеми этими новыми ИТ-сервисами.
-233-
5. КАКОВЫ ОСОБЕННОСТИ ПЕРСПЕКТИВНЫХ ПАРАДИГМ И ПЛАТФОРМ
Разработку тоже можно вести в облаке, используя «проектиро¬
вание как сервис». Это интегрированная среда, к которой локальные
и удаленные группы разработчиков могут обращаться для целей со¬
здания, тестирования и передачи своего кода. Система планирова¬
ния ресурсов предприятия также может быть развернута в облаке —
с использованием услуг «корпоративные приложения как сервисы».
«Вычисления как сервис» можно использовать для доступа к виртуа-
лизированным серверам с целью быстрого наращивания вычисли¬
тельной мощности в случае необходимости и ее сокращения при
изменении требований.
На самом деле в облаке можно разместить все бизнес-процес¬
сы предприятия, используя «бизнес-процессы как сервис». Даже та¬
кие процессы, как выставление счетов, могут предоставляться как
сервис. Это приводит к созданию гибкой и динамичной архитекту¬
ры предприятия, оптимальной для реалий сегодняшней глобаль¬
ной цивилизации и торговли.
Преимущества облачных вычислений:
1. Пользователь оплачивает услугу только тогда, когда она ему
необходима, а самое главное, он платит только за то, что использует.
2. Облачные технологии позволяют экономить на приобрете¬
нии, поддержке, модернизации ПО и оборудования.
3. Масштабируемость, отказоустойчивость и безопасность —
автоматическое выделение и освобождение необходимых ресур¬
сов в зависимости от потребностей приложения. Техническое об¬
служивание, обновление ПО производит провайдер услуг.
4. Удаленный доступ к данным в облаке — работать можно из
любой точки на планете, где есть доступ в сеть Интернет.
Недостатки облачных вычислений:
1. Пользователь не является владельцем и не имеет доступа
к внутренней облачной инфраструктуре. Сохранность пользова¬
тельских данных сильно зависит от компании провайдера.
2. Недостаток актуальный для российских пользователей: для
получения качественных услуг пользователю необходимо иметь
надежный и быстрый доступ в сеть Интернет.
3. Отсутствие общепринятых стандартов в направлении без¬
опасности облачных технологий.
-234-
Что такое интернет вещей (IoT)
ЧТО ТАКОЕ ИНТЕРНЕТ ВЕЩЕЙ (IOT)
Идея интернета вещей (Internet of Things, IoT) сама по себе до¬
статочно тривиальна и состоит в том, что все окружающие предме¬
ты и устройства имеют уникальные идентификаторы и могут быть
снабжены датчиками (сенсорами) и исполнительными устройства¬
ми (актуаторами). Все эти устройства соединены между собой с по¬
мощью сети, в качестве которой может выступать Интернет. В этом
случае все устройства IoT становятся полноправными хостами. Тог¬
да появляется возможность отслеживать эти объекты и их параме¬
тры в пространстве и во времени и управлять ими.
Первые IoT-системы представляли собой системы управления
удаленными физическими объектами, в качестве которых часто вы¬
ступали чайники, пылесосы и т. п. Достаточно быстро пришло осоз¬
нание того, что в качестве «вещей» может выступать все что угодно:
промышленное оборудование, разного рода виртуальные объекты,
и что для построения сети, которая соединяет «вещи», могут ис¬
пользоваться не только такие же как и люди каналы доступа к сети
Internet, но и различные протоколы взаимодействия между собой.
IoT не исключает участия человека, поскольку он не во всех слу¬
чаях полностью автоматизирует вещи, а чаще всего просто предо¬
ставляет человеку доступ к вещам. В IoT каждая вещь имеет свой
уникальный идентификатор, которые совместно образуют конти¬
нуум вещей, способных взаимодействовать друг с другом, созда¬
вая временные или постоянные сети. Так, вещи могут принимать
участие в процессе их перемещения, делясь сведениями о текущей
геолокации, что позволяет полностью автоматизировать процесс
логистики, а имея встроенный интеллект, вещи могут менять свои
свойства и адаптироваться к окружающей среде, в том числе для
уменьшения энергопотребления. IoT позволяет создавать комби¬
нацию из интеллектуальных устройств, объединенных сетями свя¬
зи, и людей.
Сферы применения. Начиная с момента появления в конце
прошлого века IoT постоянно развивалась. Расширение шло как
в плане совершенствования характеристик, так и в плане расши¬
рения сферы применения. В качестве движущей силы развития IoT
выступает в первую очередь прогресс в области инфокоммуникаци-
-235-
5. КАКОВЫ ОСОБЕННОСТИ ПЕРСПЕКТИВНЫХ ПАРАДИГМ И ПЛАТФОРМ
онных технологий, увеличение доступных вычислительных мощно¬
стей и широкополосных каналов связи при постоянном снижении
их стоимости, с одной стороны, приводит к увеличению объемов
данных, поступающих из внешнего мира, а с другой стороны, по¬
зволяет использовать мощные алгоритмы обработки данных. Эти
факторы приводят к необходимости и возможности использовать
новые архитектурные решения.
На сегодняшний день очень сложно перечислить все сферы
применения IoT. Можно указать следующие наиболее популяр¬
ные сферы применения IoT:
1. Умный дом. Главные задачи — безопасность, интеллектуаль¬
ный дверной звонок, управление телевизором и кухней, автома¬
тические системы полива и освещения, сигнализация пожара, га¬
за, утечки воды, температуры дома.
2. Умный город. Главные задачи — управление и регулирова¬
ние автомобильного движения, ночное/дневное уличное освеще¬
ние, уведомление об опасности для пешеходов, определение не¬
стандартных и опасных ситуаций в городе.
3. Оптимизация использования ресурсов в доме, городе, стране.
Освещение, потребление электричества, отопления, оптимизация
и прогнозирование использования, например, топлива на элек¬
тростанциях.
4. Погода и стихийные бедствия. Метеорологическая инфор¬
мация, сейсмическая активность, противопожарный контроль.
Прогнозирование погодных данных.
5. Оптимизация перевозок, доставок, хранения и сортиров¬
ки. Многие компании используют решение для построения оп¬
тимальных транспортных маршрутов, для управления потоком
грузов в терминалах хранения и сортировки грузов в крупных аэ¬
ропортах.
6. Промышленный мониторинг и контроль, управление кон¬
вейерными линиями, управление роботами, сортировка товаров,
сырья и тестирование готовой продукции.
7. Встроенные системы управления транспортными средства¬
ми. Сложные механизмы, высокотехнологичные устройства, та¬
кие как современные автомобили, самолеты и пр. Автоматизи-
-236-
Что такое интернет вещей (IoT)
рованнаясистема управления, защита от угона, контроль агрега¬
тов системы. Распознавание лица и тела водителя для предотвра¬
щения сна, потери внимания. Прогнозирование обслуживания
и замены компонентов системы.
При этом список областей применения постоянно расши¬
ряется.
Обобщенная идея IoT показана на рис. 5.5.
Коммуникация
любых устройств
Коммуникация
в любое время
в движении
ночью
днем
- на улице
дома
- около компьютера
оммуникация
любом месте
между комьютерами
- между людьми (без компьютера)
- между людьми и устройствами
- между устройствами
Рис. 5.5. Идея интернета вещей
Следует заметить, что в настоящее время нет общепринятого
четкого определения этого понятия. Обычно термин IoT определя¬
ют следующим образом: «Интернет вещей (англ. Internet of Things,
IoT) — это концепция развития технологий сетей Интернет в сторо¬
ну автоматизации, и исключения участия человека из большинства
процессов работы IT-инфраструктуры. Интернет-вещи посредством
обмена информацией между различными датчиками и сенсорами
должны полностью автоматизировать процессы управления груп¬
пами устройств» [76].
Это очень общее определение, но для этого есть веские причи¬
ны. Дело в том, что в настоящее время IoT представляет собой па¬
радигму, которая, подобно зонтику, накрывает большое число бо¬
лее мелких парадигм, платформ и протоколов.
-237-
5. КАКОВЫ ОСОБЕННОСТИ ПЕРСПЕКТИВНЫХ ПАРАДИГМ И ПЛАТФОРМ
Наиболее важными отличиями IoT от интернета людей
являются следующие моменты:
а) фокус не на человеке, а на вещах;
б) IoT включает в свой состав большее число подключенных
объектов;
в) объекты могут иметь существенно меньшие размеры и ис¬
пользовать низкоскоростные каналы связи;
г) фокус на считывании информации, а не на коммуникациях.
С IoT связано множество стандартов, относящихся к разным со¬
ставляющим IoT, в частности Российский стандарт. Официальное
определение интернета вещей приведено в Рекомендации МСЭ-Т,
согласно которой IoT — глобальная инфраструктура информацион¬
ного общества, обеспечивающая передовые услуги за счет органи¬
зации связи между вещами (физическими или виртуальными) на
основе существующих и развивающихся совместимых информаци¬
онных и коммуникационных технологий.
Под вещами (things) здесь понимается физический объект (фи¬
зическая вещь) или объект виртуального (информационного) ми¬
ра, которые могут быть идентифицированы и объединены через
коммуникационные сети. Часто вместо термина «вещи» использу¬
ют термин «сущность».
Схема отображения физических и виртуальных вещей пред¬
ставлена на рис. 5.6.
Информационный
"'*0
о
,-*0
о О
мир
0
Физический объект
О Виртуальный объект
| | Шлюз
Рис. 5.6. Физический и виртуальный миры
-238-
Что такое интернет вещей (IoT)
Из рисунка следует, что виртуальные вещи могут существовать
без их физических воплощений, в то время как физическим объек-
там/вещам обязательно соответствует минимум один виртуальный
объект. При этом ведущую роль играют именно устройства, кото¬
рые могут собирать различную информацию и распространять ее
по коммуникационным сетям различными способами: через шлю¬
зы и через сеть; без шлюзов, но через сеть; напрямую между собой.
Следует различать понятия «интернет вещей» и «интернет¬
вещь». Под интернет-вещью понимается любое устройство, кото¬
рое имеет доступ к сети Интернет с целью передачи или запроса ка¬
ких-либо данных, имеет конкретный адрес в глобальной сети или
идентификатор, по которому можно осуществить обратную связь
с вещью, имеет интерфейс для взаимодействия с пользователем.
Каждый узел сети интернет-вещей предоставляет свой сервис,
оказывая определенный набор услуг поставки (обработки) данных.
В то же время узел такой сети может принимать команды от любо¬
го другого узла. Это означает, что все интернет-вещи могут взаимо¬
действовать друг с другом и решать совместные вычислительные
задачи. Интернет-вещи могут образовывать локальные сети, объ¬
единенные какой-либо одной зоной обслуживания или функцией.
Архитектура IoT. IoT является многоуровневой иерархиче¬
ской гетерогенной киберфизической системой и с точки зрения
архитектуры верхнего уровня может быть отнесена к системам,
реализующим иерархический стиль. При этом сами уровни мо¬
гут быть выделены разными способами. К настоящему времени
известно большое число разнообразных эталонных архитектур,
ориентированных на разные подклассы IoT, которые отличают¬
ся числом уровней со способами распределения работ между от¬
дельными уровнями.
Реализация интернета вещей включает в себя четыре основных
строительных блока. К ним относятся вещи, шлюзы, сетевая инфра¬
структура и облачная инфраструктура.
Архитектурные слои. Функциональность описанных выше
модулей может быть распределена по слоям разными способами.
Способ разбиения IoT системы на слои во многом зависит от обла¬
сти ее применения, размеров, требований многих других факторов.
Известно достаточно много эталонных архитектур IoT, которые раз¬
-239-
5. КАКОВЫ ОСОБЕННОСТИ ПЕРСПЕКТИВНЫХ ПАРАДИГМ И ПЛАТФОРМ
личаются в основном числом слоев. Известные эталонные архитек¬
туры могут содержать от трех до шести слоев (рис. 5.7).
Уровень
приложений
Сетевой уровень
Уровень восприятия
Уровень приложений
Уровень управления
сервисами
Сетевой уровень
Умные устройства
Бизнес-уровень
Уровень управления
сервисами
Сервисный уровень
Транспортный
уровень
Уровень восприятия
Уровень приложений
Сервисный уровень
Коммуникационный
уровень
Сетевой уровень
Аппаратный уровень
Уровень окружения
Три уровня Четыре уровня Пять уровней Шесть уровней
Рис. 5.7. Уровневые архитектуры
Трехслойную архитектуру можно рассматривать как базовую
эталонную архитектуру IoT. Это наиболее простая с точки зрения
реализации архитектура. В ней присутствуют только три уровня:
уровень восприятия (perception layer), сетевой уровень (network
layer) и уровень приложений (application layer). Данная архитек¬
тура достаточно хорошо работает для простых систем, в которых
требуется минимальная обработка, например для дачных систем,
где требуется следить за температурой и при ее понижении закры¬
вать форточки и регулярно включать на определенное время ка¬
пельный полив.
Четырехслойная архитектура как некоторый компромисс меж¬
ду простейшей трехслойной и многослойными архитектурами.
Данная архитектура включает следующие четыре слоя: слой сен¬
соров и умных устройств (smart device / sensor layer), слой шлюзов
и сетей (Gateway sand Networks Layer), слой управления сервисами
(Management Service Layer) и слой приложений (Application Layer).
Данная архитектура может использоваться во многих типах IoT-
систем. Первоначально она была ориентирована на такие системы,
как умный дом, умное здание, умный город.
-240-
Когда используются туманные и граничные вычисления
Для систем средней сложности трехслойной архитектуры яв¬
но недостаточно. В этом случае обычно используют пятислойную
архитектуру. Имеются разные варианты пятиуровневой эталонной
архитектуры уровневой архитектуры IoT.
Пятислойная архитектура [77] аналогична трехслойной архи¬
тектуре, но с добавлением дополнительных слоев. В трехслойную
модель добавляются два дополнительных слоя: транспортный слой
(transport layer) и бизнес-слой (business layer).
КОГДА ИСПОЛЬЗУЮТСЯ ТУМАННЫЕ
И ГРАНИЧНЫЕ ВЫЧИСЛЕНИЯ
Интернет вещей представляет собой комплексную среду, кото¬
рая объединяет большое количество разнородных физических объ¬
ектов или вещей, таких как приборы, сооружения, животные, транс¬
портные средства, фермы, фабрики и т. д.
В большинстве своем классические IoT-системы являются об¬
лачно-ориентированными. В них физические объекты представ¬
лены в виде веб-ресурсов, управляемых серверами в глобальной
сети Интернет [78]. По сути, для подключения физических объек¬
тов к сети система будет использовать различные интерфейсные
устройства, такие как проводные или беспроводные датчики, ис¬
полнительные механизмы и считывающие устройства для взаи¬
модействия с ними. Кроме того, интерфейсные устройства обеспе¬
чивают подключение к Интернету через промежуточные шлюзы,
такие как маршрутизаторы, коммутаторы, базовые станции сото¬
вой связи и так далее.
В целом IoT-система вещей включает в себя три основные
элемента: встроенные системы, промежуточное программное
обеспечение и облачные сервисы, где встроенные системы обеспе¬
чивают доступ к данным, промежуточное программное обеспече¬
ние соединяет разнородные встроенные системы интерфейсных
устройств с облаком, и, наконец, облако предоставляет сервисы
хранения,обработки и управления.
-241-
5. КАКОВЫ ОСОБЕННОСТИ ПЕРСПЕКТИВНЫХ ПАРАДИГМ И ПЛАТФОРМ
Это достаточно распространенный подход к построению IoT-си¬
стем, использование которого сталкивается с целым рядом проблем.
Хотя данная модель является распространенным подходом
к внедрению систем интернета вещей, она сталкивается с расту¬
щими проблемами в области интернета вещей. В частности, появ¬
ляются проблемы, связанные с пропускной способностью, задер¬
жкой, непрерывностью, ограничением ресурсов и безопасностью,
которые принято называть BLURS (bandwidth, latency, uninterrupted,
resource-constraint, security) [78].
Возникает закономерный вопрос: каким образом могут быть
решены эти проблемы. Очевидно, что для того, чтобы решить
эти проблемы, требуется приблизить вычислительные ресурсы
к источникам данных. Однако с точки зрения программирования
наличие единого виртуального ресурса, реализованного в виде
облачного сервиса, очень привлекательно. В последнее десяти¬
летие было предпринято несколько попыток решить проблему
в рамках облачного подхода, однако нельзя назвать эти подхо¬
ды успешными.
В результате остановились на решении, предложенном фир¬
мой Cisco, которое получило название «туманные вычисле¬
ния» (fog computing). В результате работы организации Open Fog
consortium, в которую входят такие фирмы и университеты, как:
ARM; AT&T; Cisco; Dell; Fog Horn Systems; Fujitsu; Hitachi; Foxconn;
Indian Institute of Technology, Intel; Microsoft; Mitsubishi Electric
Corporation, Princeton University и еще несколько десятков других
организаций в 2017 г. была разработана эталонная модель туман¬
ных вычислений, на базе которой годом позже был создан меж¬
дународный стандарт [79].
Модель туманных вычислений включает в себя широкий
спектр оборудования и сетей. В целом это концептуальная модель,
которая учитывает все возможности расширения облака за счет
включения некоторой промежуточной сети. С точки зрения поль¬
зователя, туманная система представляет собой сервисную эко¬
систему.
В соответствии с [79] основным назначением туманных вычи¬
слений является «обеспечение недостающего звена в континууме
“облако-вещь”».
-242-
Когда используются туманные и граничные вычисления
Туманные архитектуры выборочно перемещают вычисления,
хранение, связь, управление и принятие решений ближе к грани¬
це сети, туда, где генерируются данные, чтобы устранить ограни¬
чения по характеристикам для обеспечения критически важных
вариантов использования с высокой плотностью данных.
В упомянутом стандарте туманные вычисления определяют¬
ся следующим образом: «Туманные вычисления — это горизон¬
тальная архитектура системного уровня, которая распределяет вы¬
числительные, запоминающие, управляющие и сетевые функции
ближе к пользователям по континууму “облако-вещь”».
По мнению авторов стандарта, туманные вычисления — это
расширение традиционной модели облачных вычислений, в кото¬
рой реализации архитектуры могут располагаться на нескольких
уровнях топологии сети. Ключевой идеей является то, что все пре¬
имущества облачных технологий должны быть сохранены с помо¬
щью этих расширений. К этим преимуществам относятся возмож¬
ности использования таких механизмов, как контейнеризация,
виртуализация, оркестровка, управляемость и эффективность. Во
многих случаях туманные вычисления работают с облаком.
Близким по значению к термину «туманные вычисления» яв¬
ляется термин «граничные вычисления» (edge computing).
Согласно определению Гартнера, edge computing — «это подвид
распределенных вычислений, в котором обработка информации
происходит в непосредственной близости к месту, где данные были
получены и будут потребляться» [80]. Это основное отличие гранич¬
ных вычислений от облачных вычислений, при которых информация
собирается и обрабатывается в публичных или частных дата-цент¬
рах. Основным отличием от локальных вычислений является то, что
обычно edge computing — это часть большей системы, которая вклю¬
чает в себя сбор статистики, централизованное управление и удален¬
ное обновление приложений на граничных устройствах.
Различия между туманными и граничными вычислениями.
Это достаточно часто задаваемый вопрос, на который разные спе¬
циалисты отвечают по-разному. Авторы стандарта [79] считают, что
ключевое отличие состоит в том, что туманные вычисления работа¬
ют с облаком, в то время как граничные вычисления предполагают
выход за пределы облака.
-243-
5. КАКОВЫ ОСОБЕННОСТИ ПЕРСПЕКТИВНЫХ ПАРАДИГМ И ПЛАТФОРМ
Существует точка зрения, в соответствии с которой туманные
вычисления используют в качестве ресурсов ресурсы, используе¬
мые в устройствах, например в умном доме может быть много ум¬
ных вещей, имеющих встроенные контроллеры, на которых можно
организовать вычисления, объединив их в сеть. Можно, напротив,
поставить в доме мини дата-центр, выполнять в нем все вычисле¬
ния и хранилище данных [81].
Однако разница между этими подходами не слишком велика,
поскольку реализуется одна и та же идея, которая состоит в том,
что вычисления следует выполнять в непосредственной близости
от источников данных, поэтому эти подходы будут рассматривать¬
ся как единый подход — граничные туманные вычисления.
Иерархическая модель гранично-туманных вычислений пока¬
зана на рис. 5.8.
Рис. 5.8. Иерархическая модель гранично-туманных вычислений
-244-
Когда используются туманные и граничные вычисления
Данная модель фактически является моделью размещения
по уровням (deployment model). Серверы развертываются на трех
граничных уровнях или границах (edges) — внутреннем, среднем
и внешнем [82].
Внутренний слой. Внутренняя граница (также известная как
ближняя граница) соответствует глобальной сети фирмы, интер¬
нет-провайдеров, центра обработки данных. Этот уровень можно
рассматривать как уровень, на котором работают провайдеры, ко¬
торые традиционно предлагали только основные инфраструктуры
для подключения локальных сетей к глобальному Интернету. Тем
не менее возрастающие потребности в повышении качества обслу¬
живания привели к созданию механизма географически распреде¬
ленного кэширования. Например, многие интернет-провайдеры
(например, AT&T, Vodafone, Deutsche Telekom и др.) знают, что мно¬
гим местным предприятиям требуется облако с низкой задержкой,
и они предлагают локальное облако внутри страны.
Основываясь на эталонной архитектуре туманных вычисле¬
ний, облачные центры обработки данных на основе глобальной
сети можно рассматривать как туман внутреннего слоя.
Средний слой. Средний слой — это то, что соответствует инту¬
итивному пониманию туманных вычислений. Этот слой состоит из
сетей двух типов: локальных сетей и сотовой сети.
Обычно в нем присутствует маршрутизатор, который обес¬
печивает доступ к облачным сервисам внутреннего слоя. Сервера
располагаются таким образом, чтобы они находились на расстоя¬
нии одного перехода (hope) между устройством интернета вещей
и сервером.
Обычно такой подход также известен как локальное облако, ло¬
кальный центр обработки данных или облако. На серверах данно¬
го уровня активно используются механизмы виртуализации и кон¬
тейнеризации.
На этом уровне самым активным образом используются сото¬
вые сети. В целом большинство развитых городов имеют широкий
охват сотовых сетей, предоставляемых многочисленными типами
базовых станций, которые являются идеальными объектами для ис¬
-245-
5. КАКОВЫ ОСОБЕННОСТИ ПЕРСПЕКТИВНЫХ ПАРАДИГМ И ПЛАТФОРМ
пользования в качестве придорожных узлов туманных вычислений
для различных случаев использования мобильного интернета ве¬
щей, таких как подключенные транспортные средства, мобильное
здравоохранение и виртуальная или дополненная реальность, ко¬
торые требуют быстрый процесс и реагирование на поток данных
в реальном времени.
Внешний слой. Внешний слой, который также известен как
крайний слой, дальний край или туман (mist) [81, 82], представляет
собой интерфейсную часть сети интернета вещей, которая состоит
из трех типов устройств: оконечные устройства, интегрированные
устройства и ТР-шлюзы.
Оконечные устройства, такие как датчики или исполнительные
механизмы, обычно управляются микроконтроллерами, которые
имеют очень ограниченную вычислительную мощность и память.
Например, популярный однокристальный микроконтроллер Atmel
ATmega328, который является процессором Arduino Uno Rev3 [83], ра¬
ботает на частоте 20 МГц и имеет всего 32 КБ флэш-памяти.
Обычно администраторы интернета вещей не ожидают раз¬
вертывания сложных задач на устройствах такого типа. Однако
благодаря возможности программирования на местах современ¬
ных беспроводных датчиков и исполнительных механизмов сис¬
тема интернета вещей всегда может динамически и удаленно об¬
новлять или перенастраивать программный код устройств.
Интегрированные устройства — это встроенные в оборудова¬
ние микропроцессоры, которые могут обладать достаточно прилич¬
ными вычислительными возможностями. Они также имеют встро¬
енные средства сетевого взаимодействия, такие как Wi-Fi и Bluetooth.
Эти устройства управляются процессорами, которые обладают
приличной вычислительной мощностью.
Кроме того, интегрированные устройства имеют множество
встроенных возможностей в сети, например подключения Wi-Fi
и Bluetooth, встроенные датчики, такие как гироскоп, ускорители.
Примерами таких устройств могут служить смартфоны и планше¬
ты, которые работают под управлением полноценных операцион¬
ных систем.
-246-
Когда используются туманные и граничные вычисления
Оконечные устройства, работающие во внешнем слое, не исполь¬
зуют IP-протокол, в частности, по причине ограничений на потребля¬
емую мощность. Устройства внешнего слоя используют очень простые
протоколы, такие как Bluetooth с низким энергопотреблением, ZigBee
или Z-Wave, которые не могут работать напрямую с IP-сетью.
Шлюз можно построить на базе одноплатного компьютера, на¬
пример такого как Raspberry Pi [84] или любого другого одноплат¬
ного компьютера.
Например, модель Raspberry Pi 4 Model B, которая стоит порядка
24 000 руб., обеспечивает производительность настольного компью¬
тера, сравнимую с системами ПК начального уровня x86. Ключевые
характеристики этого продукта включают высокопроизводитель¬
ный 64-разрядный четырехядерный RISC процессор ARMCortex-
A-72, поддержку двух дисплеев с разрешением до 4K через пару
портов micro-HDMI, аппаратное декодирование видео до 4Kp60, бес¬
проводную локальную сеть 2,4/5,0 ГГц, Bluetooth 5.0, Gigabit Ethernet,
USB 3.0, в качестве жесткого диска использует SD-карты. Кроме это¬
го, имеется большое число модулей расширения. Основной опера¬
ционной системой является ОС Raspbian, построенная на базе по¬
пулярной ОС Debian Linux. Эта модель появилась в 2019 г. Плата по
размеру сопоставима с кредитной карточкой. Очевидно, что, соеди¬
нив несколько плат через Gigabit Ethernet, можно построить доста¬
точно мощный кластер.
На туманном узле, построенном на базе одноплатного ком¬
пьютера, можно легко разместить среду виртуализации, такую как
Docker Containers Engine, можно также построить локальную облач¬
ную среду. Для отладки к HDMI порту можно подключить дисплей,
а к USB портам можно подключить клавиатуру и мышь и превра¬
тить одноплатный компьютер в полноценный РС.
Средний слой, который реализует туманные вычисления, мож¬
но представить себе состоящим из множества узлов, которые далее
будем называть туманно-граничными узлами (FogEdge Nodes, FEN).
Обобщенная структура такого узла показана на рис. 5.9.
FEN обычно рассматривают, принимая во внимание следую¬
щие архитектурно значимые характеристики: задержка, эффек¬
тивность, безопасность, возможность масштабирования, когнитив-
ность, гибкость.
-247-
5. КАКОВЫ ОСОБЕННОСТИ ПЕРСПЕКТИВНЫХ ПАРАДИГМ И ПЛАТФОРМ
Процессор
Память
О
Ускоритель
*
I
Сетевые
подключения
Управление
Рис. 5.9. Обобщенная структура FEN
Основным источником получения выигрыша можно считать
уменьшение времени пересылок. В случае, когда альтернативой
являются обработка события в облаке и время вычислений, если
в качестве альтернативы рассматривается обработка события в IoT
контроллере.
Использование FEC позволяет повысить эффективность с точ¬
ки зрения повышения производительности и снижения ненужных
затрат. Например, применяя FEN в системе здравоохранения или
ухода за пожилыми людьми, многие задачи можно решать, ис¬
пользуя серверы туманного слоя для обработки сенсорных дан¬
ных. В идеале, поскольку процесс происходит рядом с источником
данных, система может генерировать результат намного быстрее.
Кроме того, можно снизить затраты за счет уменьшения объема
интернет-трафика.
FEN поддерживает дополнительную защиту устройств интер¬
нета вещей для обеспечения безопасности и надежности транзак¬
ций. Например, современные беспроводные датчики, развернутые
на открытом воздухе, часто требуют удаленного обновления исход¬
ного кода через беспроводные сети для решения проблем, связан¬
ных с безопасностью. Однако из-за различных динамических фак¬
торов окружающей среды, таких как нестабильный уровень сигнала,
перебои, ограниченная пропускная способность и т. д., удаленный
сервер может столкнуться с трудностями при быстром выполнении
обновления, что, следовательно, повышает вероятность кибератаки.
-248-
Когда используются туманные и граничные вычисления
С другой стороны, если доступна туманная инфраструктура, то об¬
новления можно вносить намного быстрее. Кроме того, можно опе¬
ративно реагировать на попытки атак.
Туманная структура может накапливать информацию о пове¬
дении своих клиентов и использовать ее для того, чтобы прини¬
мать решения о том, где и когда развертывать модули, реализующие
функции вычисления, хранения и управления. Это позволяет реали¬
зовывать такие механизмы, как самоадаптация, самоорганизация,
самовосстановление и др. В перспективе это позволяет перейти от
пассивных оконечных устройств к интеллектуальным датчикам,
которые могут непрерывно работать и реагировать на требования
клиентов, не полагаясь на решение из удаленного облака.
Использование туманных архитектур позволяет повысить
уровень гибкости систем, в частности, за счет того, что решение
о реконфигурации может приниматься «по месту», что ускоря¬
ет развертывание крупномасштабных инфраструктур интерне¬
та вещей.
Рассмотрим более подробно, за счет чего можно получить пе¬
речисленные выше преимущества.
Обобщенная структура FEN показана на рис. 5.9. В каждом FEN
реализуются пять базовых механизмов: хранение данных, вычисле¬
ния, ускорение вычислений и сети, и управление.
С точки зрения хранения информации FEN реализует преиму¬
щественно функции, связанные с кэшированием и временным хра¬
нением информации с целью повышения производительности при
решении задач, связанных с доставкой контента. Например, беспи¬
лотные автомобили могут получать свежую информацию о состо¬
янии внешнего мира, в частности о состоянии дороги, собранную
другими автомобилями.
FEN реализует доступ к вычислительным ресурсам в двух фор¬
мах. Чаще всего это сервисы типа инфраструктура или платформа
как сервис (PaaS) и программное обеспечение как сервис (SaaS). Как
правило, при построении FEN используются виртуальные машины
с гипервизором (VM) или механизмы контейнеров (CES), которые
позволяют развертывать необходимое программное обеспечение
-249-
5. КАКОВЫ ОСОБЕННОСТИ ПЕРСПЕКТИВНЫХ ПАРАДИГМ И ПЛАТФОРМ
в изолированной среде. Сам характер обработки может быть раз¬
ным. Это может быть простая обработка по запросу клиента, а мо¬
жет быть и более сложная обработка, при которой клиенту возвра¬
щается некоторый ответ, представленный в форме знания.
В FEN используются два основных подхода к увеличению про¬
изводительности: ускорение вычислений и увеличение скорости
работы сети.
Одним из действенных механизмов является использование
технологии сетевой виртуализации, которая позволяет FEN парал¬
лельно управлять несколькими таблицами маршрутизации и реа¬
лизовывать программно-определяемую сеть (SDN) [85]. Таким обра¬
зом, клиенты узлов могут настраивать индивидуальный маршрут
маршрутизации для своих приложений, чтобы достичь оптималь¬
ной скорости передачи данных по сети.
Повысить производительность FEN можно несколькими спо¬
собами. Во-первых, можно просто использовать более мощный
процессор. Во-вторых, можно использовать графический или сиг¬
нальный сопроцессор. В-третьих, можно использовать вентильные
матрицы (FPGA). В частности, использование графических про¬
цессоров для реализации сложных алгоритмов является распро¬
страненным подходом в облачных вычислениях. Поэтому мож¬
но предположить, что поставщики FEN могут также предоставлять
оборудование, содержащее независимые графические процессо¬
ры средней или высокой производительности. ПЛИС уже довольно
давно используют для реконфигурации датчиков во время выпол¬
нения. Кроме того, по сравнению с графическими процессорами,
FPGA потенциально может быть более энергоэффективным подхо¬
дом для обеспечения необходимого ускорения, основанного на пре¬
доставлении клиентам возможности настраивать свой индивиду¬
альный код на FEN.
Сетевое взаимодействие FEN включает в себя вертикальные
и горизонтальные связи. Вертикальная сеть соединяет объекты
и облако, которое использует TP-сети; в то время как горизонталь¬
ная сеть в зависимости от комплектации может использовать са¬
мые разные протоколы.
Узлы FEC обеспечивают вертикальные сетевые соединения
с использованием стандартных сетевых протоколов IP, таких как
-250-
Когда используются туманные и граничные вычисления
сокеты TCP/UDP, HTTP, CoAP или очереди сообщений (AMQP; ISO/
IEC 19464), MQTT (ISO/IEC PRF 20922) и так далее.
Необходимость поддержки горизонтальных сетевых взаимо¬
действий основывается на различных требованиях к оптимизации,
таких как энергоэффективность или эффективность сетевой пере¬
дачи, системы интернета вещей часто используют разнородные
экономически эффективные сетевые подходы. В частности, умный
дом, умные заводы и подключенные транспортные средства обыч¬
но используют Bluetooth, ZigBee и Z-Wave на устройствах интернета
вещей и подключают их к шлюзу IP-сети для обеспечения подклю¬
чения между устройствами и внутренним облаком.
В общем, устройства шлюза IP-сети являются идеальными
объектами для размещения серверов туманного уровня, посколь¬
ку они имеют возможность подключения к устройствам интерне¬
та вещей.
На туманном уровне могут реализовываться четыре основных
механизма управления: развертывание, управление элементами
нижележащего, управление внешними взаимодействиями и безо¬
пасность:
1. Управление развертыванием позволяет клиентам динамиче¬
ски выполнять настраиваемое развертывание программного обес¬
печения. Кроме того, клиенты могут настраивать FEN для управле¬
ния тем, какую программу должен выполнять узел и когда он должен
ее выполнять. Кроме того, клиентам может предоставляться сервис
получения информации о полной топологии сети, что позволяет им
управлять перемещениями приложений с одного узла на другой.
Кроме того, клиенты также могут управлять несколькими FEN для до¬
стижения оптимальной производительности для своих приложений.
2. Управление элементами нижележащего уровня предполага¬
ет, что управление устройствами ведется не напрямую из облака,
а используются некоторые механизмы типа политик, т. е. в FEN из
облака поступают указания, что нужно сделать, а FEN решает, как
это должно быть сделано.
3. Управление внешними взаимодействиями предполагает ор¬
ганизацию взаимодействия с внешними сущностями, которые мо¬
-251-
5. КАКОВЫ ОСОБЕННОСТИ ПЕРСПЕКТИВНЫХ ПАРАДИГМ И ПЛАТФОРМ
гут принадлежать другим организациям и использовать собствен¬
ные протоколы.
4. Контроль безопасности является одним из основных требо¬
ваний, предъявляемым к FEN, и предполагает реализацию таких
функций, как аутентификация, авторизация, идентификация и за¬
щита виртуализированной среды выполнения, размещенной на уз¬
лах FEN.
Пример использования туманных вычислений. Кластеры дро-
нов. В последние несколько лет беспилотные летательные аппараты
(дроны) получили широкое распространение и широкое примене¬
ние в различных областях, таких как военные применения, сельское
хозяйство, торговля и др. Все большее число дронов используется
в составе кластеров (групп), реализующих роевое поведение. Ожи¬
дается, что к 2025 г. беспилотные летательные аппараты будут об¬
ладать полной способностью к автономной групповой работе в со¬
ставе кластеров [86].
Кластеры дронов можно рассматривать как одну из реализаций
концепции облачно-граничных вычислений.
По сравнению с обычными сетями граничных вычислений
с поддержкой одного или нескольких дронов, туманные сети под¬
держки кластера (роя) дронов могут намного более эффективно
решать такие задачи, как доставка грузов, мониторинг земли, точ¬
ное сельское хозяйство и крупномасштабные военные операции
и многие другие.
Этот подход часто называют интернет дронов (Internet of
Drones, IoD).
IoD обладает рядом несомненных достоинств, основными из
которых являются следующие:
- использование кластера дронов позволяют распределять
вычислительные ресурсы между большим количеством дронов,
т. е. распараллелить процессы;
- повышение надежности связи, которое может быть достигну¬
то благодаря гибкому антенному соединению нескольких дронов
с одной антенной для формирования виртуальной системы с не¬
сколькими антеннами, с помощью которой качество приема сиг¬
-252-
Когда используются туманные и граничные вычисления
нала и передачи информации может быть значительно улучшено
при той же или даже меньшей мощности используемого приемно¬
передающего оборудования;
- может быть достигнуто существенное повышение отказоустой¬
чивости, например если несколько дронов покидают кластер, то ра¬
боты могут быть перераспределены между оставшимися дронами.
Эти преимущества можно получить в случае, если дроны могут
общаться не только с наземной станцией, но и между собой.
Ниже рассмотрены наиболее типичные применения кластеров
дронов. Следует заметить, что этот список далеко не полный.
Мониторинг Земли. Использование традиционных механиз¬
мов мониторинга, основанных на сетях стационарных датчиков,
для слежения за состоянием таких объектов, как вулканы, динами¬
ка моря, а также измерения температуры атмосферы, уровней за¬
грязняющих веществ, выбросов углерода в воздух и т. д., как пра¬
вило, является дорогостоящим или трудоемким из-за отсутствия
поблизости адекватных средств хранения и обработки информа¬
ции. Эффективной альтернативой может быть развертывание кла¬
стера дронов, оснащенных бортовыми датчиками и блоками об¬
работки, что позволит своевременно и экономически эффективно
выполнять вышеуказанные задачи за счет автономного полета по
заданной траектории.
Военные применения. На поле боя рой дронов, охватывающий
большую площадь, может собирать и обрабатывать массивные раз¬
ведданные в режиме реального времени, а затем передавать их на
близлежащие боевые станции, значительно повышая их осведом¬
ленность о ситуации на поле боя. Например, кластер дронов можно
использовать, чтобы помочь обнаружить скрытых врагов в уличных
боях и найти вражеские корабли вне поля зрения в морских сраже¬
ниях в режиме реального времени. Кластер дронов может сыграть
важную роль в этих сценариях.
Борьба со стихийными бедствиями. В случае стихийного бед¬
ствия крайне важно провести спасательные работы в первые не¬
сколько часов. Отсутствие надежной связи и основных средств не¬
отложной медицинской помощи, несомненно, окажет негативное
влияние на жизнь и имущество людей. Поэтому ситуация, как пра¬
вило, требует, чтобы спасательные силы оказали немедленную по¬
-253-
5. КАКОВЫ ОСОБЕННОСТИ ПЕРСПЕКТИВНЫХ ПАРАДИГМ И ПЛАТФОРМ
мощь. В этом случае кластер дронов, способных выполнять вычис¬
ления непосредственно на борту, может сыграть очень важную роль.
С одной стороны, дроны могут помочь оценить риски и поврежде¬
ния, а также обеспечить связь с изолированными людьми и доста¬
вить грузы.
Доставка грузов. На базе кластера дронов можно организовать
сервис быстрой и дешевой доставки грузов. Этот подход активно ис¬
пользуется такими компаниями, как Amazon и Google.
Точное земледелие (Precision agriculture). Точное земледелие,
в соответствии с определением в Википедии [87], — это «комплекс¬
ная высокотехнологичная система сельскохозяйственного менед¬
жмента, включающая в себя технологии глобального позициони¬
рования, географические информационные системы, технологии
оценки урожайности, технологию переменного нормирования,
технологии дистанционного зондирования земли и решения тех¬
нологии “интернет вещей”». Кластерам дронов в системе точного
земледелия отводится важная роль. Это может быть мониторинг со¬
стояния здоровья растений, распыление пестицидов на поражен¬
ные растения, что сопряжено с риском для здоровья людей.
Типовые архитектурные решения. Если рассматривать кла¬
стер дронов как элемент КФС, реализующей парадигму граничных
вычислений, то такие КФС можно классифицировать в соответст¬
вии с рис. 5.10.
С точки зрения назначения это могут быть системы монито¬
ринга окружающей среды, системы военного назначения, системы
сельскохозяйственного назначения, системы, используемые в усло¬
виях чрезвычайных ситуаций, системы поддержки точного земле¬
делия и др.
Кластер дронов может быть самого разного размера — от еди¬
ниц до тысяч дронов.
Структура кластера может быть однородной или неоднород¬
ной. Чаще всего используются иерархические структуры. Это может
быть одноуровневая структура, когда кластер дронов принимает ре¬
шения автономно. При двухуровневой организации кластер дронов
напрямую взаимодействует с наземной станцией или станциями.
При трехуровневой организации для взаимодействия с наземной
станцией используется отдельный, обычно более крупный дрон.
-254-
Когда используются туманные и граничные вычисления
Рис. 5.10. Классификация архитектурных решений КФС,
использующих кластеры дронов
Дрон, входящий в состав кластера, может обладать разными
вычислительными и коммуникационными возможностями. В про¬
стейших дронах на борту может находиться контроллер, обладаю¬
щий минимальными вычислительными возможностями. В крупных
дронах на борту может находиться контроллер, способный выпол¬
нять функции туманного узла.
С точки зрения коммуникационных возможностей дроны мо¬
гут иметь возможность реализовывать разные типы взаимодей¬
ствия, в частности взаимодействия типа дрон — наземная стан¬
ция (D2S) и (или) дрон — дрон (D2D).
Реализация дронами механизма роевого интеллекта напря¬
мую не связана со способностью реализовывать взаимодействие
типа D2D. Дроны могут взаимодействовать друг с другом, но не ис¬
-255-
5. КАКОВЫ ОСОБЕННОСТИ ПЕРСПЕКТИВНЫХ ПАРАДИГМ И ПЛАТФОРМ
пользовать роевые алгоритмы, и, напротив, роевые алгоритмы мо¬
гут реализовываться в наземных станциях на основе информации,
полученной от дронов.
Можно выделить следующие типовые подходы к построению
КФС, использующих кластеры дронов:
- система строится по принципу классического IoT (рис. 5.11);
- система строится по принципу туманно-граничных вычисле¬
ний (рис. 5.12).
Рис. 5.11. ДКФС строится по принципу классического IoT
Рис. 5.12. ДКФС строится по принципу
туманно-граничных вычислений
В первом случае дрон только формирует поток данных, а обра¬
ботка идет на наземной станции. Обычно это видеоданные. Связь
может идти либо напрямую по принципу D2S (рис. 5.11), либо че-
-256-
Когда используются туманные и граничные вычисления
рез более крупный дрон (рис. 5.12). Если на борту дрона можно
установить достаточно мощный вычислитель, то обработку или су¬
щественную часть обработки можно организовать по месту. Это по¬
зволяет уменьшить задержки и снизить нагрузку на каналы свя¬
зи. Основные ограничения на вычислительные мощности на борту
дрона связаны первую очередь с потребляемой мощностью, а также
с весогабаритными ограничениями. В этом случае наземная стан¬
ция выступает в роли сервера, обслуживающего заявки дрона. Дрон
обычно работает с ближайшей наземной станцией.
Дроны могут взаимодействовать между собой для решения
разного рода задач, таких как доставка данных, построение карты
местности, оповещение о событиях и др.
В частности, для первой парадигмы для удовлетворения требо¬
ваний к обслуживанию со сверхнизкой задержкой можно использо¬
вать возможности наземных систем мобильной связи. В [88] описа¬
на система управления кластером дронов, использующая 5 G-сети для
построения «летающей» сети (Flying Ad-Hoc Network, FANET), состоя¬
щей из дронов, оснащенных средствами поддержки граничных вычи¬
слений. В соответствии с предлагаемой структурой большие объемы
данных, создаваемых наземными устройствами, расположенными
в географических районах, удаленных от структурированной базо¬
вой сети, могут быть оперативно переправлены к стационарным сер¬
верам, на которых осуществляются накопление и обработка данных.
Для решения задачи, связанной с минимизацией энергопо¬
требления, вычислительные элементы каждого дрона могут быть
адаптивно включены и выключены в зависимости от уровня ак¬
тивности контролируемой области. Кроме того, если один из дро-
нов перегружен, он может с некоторой вероятностью переложить
работу на близлежащие недогруженные дроны, чтобы сэкономить
свою энергию и, следовательно, продлить продолжительность по¬
лета кластеров дронов. Данный вариант предполагает, что в райо¬
не действия кластера дронов работает мобильная связь.
Однако если речь идет об устранении чрезвычайных ситуаций,
то мобильная связь часто отсутствует. В этом случае сами дроны мо¬
гут использоваться в качестве маршрутизаторов. В [89] для решения
-257-
5. КАКОВЫ ОСОБЕННОСТИ ПЕРСПЕКТИВНЫХ ПАРАДИГМ И ПЛАТФОРМ
этой проблемы предлагается архитектура дрона, ориентированная
на максимально быструю передачу важных и срочных сообщений
в центр управления, в которой для передачи используется только
два прыжка (хоупа) [90]. Во время первого прыжка небольшие дро-
ны — аппараты с вращающимся крылом — в кластере передают об¬
наруженные данные большому беспилотному летательному аппа¬
рату с неподвижным крылом по беспроводной восходящей линии
связи. Беспилотный летательный аппарат с неподвижным крылом
сжимает полученные данные с помощью встроенного сервера гра¬
ничных вычислений, а затем пересылает результаты в центр управ¬
ления по каналу связи во время второго перехода. Использование
крупногабаритного самолета в качестве воздушной вычислитель¬
ной платформы является многообещающей альтернативой, особен¬
но в районах, которые не охвачены наземными сетями.
Протоколы маршрутизации для роя беспилотных летатель¬
ных аппаратов. Протокол маршрутизации играет жизненно важ¬
ную роль в обеспечении надежной связи между дронами в составе
кластера. Однако из-за особенностей беспилотных летательных ап¬
паратов, таких как высокая скорость, прерывистое воздушное сооб¬
щение, разнообразные требования к качеству обслуживания и ог¬
раниченная энергия, традиционные протоколы маршрутизации не
могут использоваться для связи внутри роя или между роем и на¬
земной станцией. Как указывалось выше, кластер дронов может
быть организован как FANET, которая имеет много общего с тради¬
ционной специальной сетью. Таким образом, традиционные прото¬
колы маршрутизации могут быть использованы в качестве основы
для предоставления таблиц маршрутизации для роя беспилотных
летательных аппаратов в FANET [86].
В ЧЕМ ОСОБЕННОСТИ ПРОМЫШЛЕННОГО
ИНТЕРНЕТА ВЕЩЕЙ (NOT)
Развитие техники и технологии принято делить на 4 этапа, ко¬
торые называют также технологическими укладами, переход между
которыми связывают с появлением принципиально новых, револю¬
ционных для своего времени технологий. Смена технологических
-258-
В чем особенности промышленного интернета вещей (IIoT)
укладов приводит к резким скачкам производительности и росту
экономики. Обычно выделяют четыре таких этапа, которые назы¬
вают индустриальными революциями.
Первую промышленную революцию (конец XVIII — начало
XIX вв.) связывают с переходом от аграрной экономики к промыш¬
ленному производству за счет изобретения паровой энергии, меха¬
нических устройств, развития металлургии.
Вторую промышленную революцию (вторая половина XIX в. —
начало XX в.) связывают с активным использованием электриче¬
ской энергии и с переходом к поточному производству и разделе¬
нию труда.
Третья промышленная революция (с 1970 г.) — применение
в производстве информационных систем, обеспечивших интенсив¬
ную автоматизацию и роботизацию производственных процессов.
Четвертую промышленную революцию связывают с переходом
на полностью автоматизированное цифровое производство, управ¬
ляемое интеллектуальными системами в режиме реального време¬
ни в постоянном взаимодействии с внешней средой, выходящее за
границы одного предприятия, с перспективой объединения в гло¬
бальную промышленную сеть Вещей и услуг.
В узком смысле Индустрия 4.0 (Industry 4.0) — это название од¬
ного из 10 проектов государственной Hi-Tech стратегии Германии
до 2020 г., описывающего концепцию умного производства (Smart
Manufacturing) на базе глобальной промышленной сети интернета
вещей и услуг (Internet of Things and Services). Следует заметить, что
аналогичные программы имеются во многих других странах.
В широком смысле Индустрия 4.0 характеризует текущий тренд
развития автоматизации и обмена данными, который включает
в себя КФС, IoT и облачные вычисления. Индустрия 4.0 представля¬
ет собой новый уровень организации производства и управления
цепочкой создания стоимости на протяжении всего жизненного ци¬
кла выпускаемой продукции.
В качестве основных составных частей Индустрии 4.0 высту¬
пают следующие элементы (рис. 5.13): IoT, искусственный интел¬
лект, машинное обучение и робототехника, облачные вычисления,
Big Data, аддитивное производство, кибербезопасность, моделиро¬
вание, дополненная реальность.
-259-
5. КАКОВЫ ОСОБЕННОСТИ ПЕРСПЕКТИВНЫХ ПАРАДИГМ И ПЛАТФОРМ
Рис. 5.13. Элементы Индустрии 4.0
Многие из этих элементов уже давно и успешно применяются
на практике, но в данном случае речь идет об их объединении в си¬
стему. Именно объединение их в одну целостную систему позво¬
лит развить концепцию Индустрии 4.0 и обеспечить новый уровень
эффективности производства и дополнительный доход за счет ис¬
пользования цифровых технологий, формирования сетевого взаи¬
модействия поставщиков и партнеров, а также реализации иннова¬
ционных бизнес-моделей.
На смену индустриальному этапу развития общества пришла
новая эволюционная фаза — фаза информатизации, и соответст¬
вующая общественно-экономическая формация — информацион¬
ное общество, при котором наиболее эффективное и динамичное
его развитие возможно на основе максимально полного использо¬
вания имеющихся информационных ресурсов и средств их обра¬
ботки, составляющих основу соответствующих информационных
пространств. Главным ресурсом ускоренного развития совре¬
менного информационного общества становятся знания, глав¬
ным механизмом развития — цифровая экономика, основанная
-260-
В чем особенности промышленного интернета вещей (IIoT)
на знаниях. Главными технологиями цифровой экономики стано¬
вятся новые ИКТ, которые уже фактически являются технология¬
ми общего назначения, так же как технологии производства тепла
и электроэнергии. В новых условиях значительно возрастает зна¬
чимость информационных процессов, обеспечивающих матери¬
альные производства.
Главной компонентой цифрового производства и в целом
цифровой экономики становятся разнообразные классы КФС.
В перспективных КФС наряду с функциями позиционирования,
контроля и диагностики также будут реализованы функции авто¬
матического составления отчетов о состоянии соответствующей
подсистемы контролируемого оборудования, в том числе данных
о всех возникающих неисправностях; об остатке ресурса изнаши¬
ваемых деталей; о ресурсе расходных материалов; загрузке обо¬
рудования и режиме его эксплуатации.
Производственные КФС включают в себя интеллектуальные
производственные мощности и складские системы, которые спо¬
собны взаимодействовать в электронном виде и за счет этого мо¬
гут быть интегрированы на основе ИКТ на протяжении всего про¬
изводственного процесса от размещения заказа до производства,
маркетинга, исходящей логистики. Указанные возможности от¬
крывают широчайшие перспективы по автоматизации и интеллек¬
туализации не только самого цифрового производства продукции,
но и ее обслуживания и эксплуатации во время послепродажного
функционирования.
Ключевыми элементами предлагаемого электронного об¬
служивания (e-maintenance) будут являться базирующееся на веб¬
технологиях дистанционное администрирование, мониторинг,
тестирование, диагностика, прогнозирование состояния эксплуа¬
тируемых изделий, реконфигурация их структур в случае возник¬
новения аварийных и нештатных ситуаций и отсутствия необхо¬
димых резервов.
Особый класс КФС представлен формируемым в настоящее
время понятием промышленного интернета, включающим ин¬
-261-
5. КАКОВЫ ОСОБЕННОСТИ ПЕРСПЕКТИВНЫХ ПАРАДИГМ И ПЛАТФОРМ
теллектуальные сетевые объекты, облачные, граничные и туман¬
ные вычислительные платформы, обеспечивающие сбор, анализ,
обмен данными в реальном времени в промышленной среде для
повышения производительности труда, уменьшения себестоимо¬
сти производимой продукции и сокращения расходов ресурсов.
Проведенный анализ основных тенденций, связанных с со¬
зданием и развитием промышленного интернета, показал, что его
основное предназначение связано с реализацией перспективных
технологий, способствующих широкомасштабному развитию кли-
ент-ориентированных, мелкосерийных и гибких производств, глав¬
ным отличием которых от крупных поточных линий является не¬
постоянство (нестационарность) производственных процессов,
вместе с ними и характеристик соответствующих информацион¬
ных потоков, а также вычислительных процессов.
Так, например, становится возможным перенос ряда функ¬
ций обработки данных ближе к месту их возникновения (к грани¬
це с физическим миром), что позволяет снизить сетевые задер¬
жки и нагрузки на каналы связи, а также вычислительную нагрузку
на ресурсы облачных вычислений. Но при этом возникают про¬
блемы, вызванные низкой производительностью таких «умных»
устройств и их энергопотреблением при автономной работе. Та¬
ким образом, для эффективного управления описанным выше ти¬
пом производства необходимо создать новую архитектуру, моде¬
ли, методы, алгоритмы и программные комплексы управления
соответствующей КФС.
Эталонная архитектурная модель «Индустрия 4.0», сокращен¬
но RAMI 4.0 (Reference Architecture Model Industry 4.0), показанная
на рис. 5.14, состоит из трехмерной системы координат, которая
описывает все важнейшие аспекты Индустрии 4.0. Таким образом,
сложные взаимосвязи могут быть разбиты на более мелкие и про¬
стые кластеры [91].
Ось «Уровни иерархии». На правой горизонтальной оси указа¬
ны уровни иерархии из стандарта IEC 62264 серии международных
стандартов для корпоративных ИТ и систем управления. Эти уров¬
ни иерархии представляют различные функциональные возможно¬
сти на заводах или объектах.
-262-
В чем особенности промышленного интернета вещей (IIoT)
Связанный мир "N
Организация
Подразделение
Сеть
Устройство j
Бизнес-уровень
Функциональный уровень
Информационный уровень
Коммуникационный уровень
Интеграционный уровень
Ресурсный уровень
Разработка Производство Эксплуатация Модернизация
Рис. 5.14. Эталонная архитектурная модель «Индустрия 4.0»
Ось «Жизненный цикл и Поток создания ценности». Левая го¬
ризонтальная ось представляет жизненный цикл объектов и про¬
дуктов, основанный на стандарте IEC 62890 для управления жиз¬
ненным циклом. Кроме того, проводится различие между «типами»
и «экземплярами». «Тип» становится «экземпляром», когда проек¬
тирование и прототипирование завершены и производится факти¬
ческий продукт.
Ось «Слои». Шесть слоев на вертикальной оси служат для опи¬
сания декомпозиции машины на ее свойства, структурированные
слой за слоем, т. е. виртуальное отображение машины. Такие пред¬
ставления происходят из информационных и коммуникационных
технологий, где свойства сложных систем обычно разбиваются на
уровни.
В рамках этих трех осей могут быть сопоставлены все важней¬
шие аспекты Индустрии 4.0, что позволяет классифицировать такие
объекты, как машины, в соответствии с моделью. Таким образом,
очень гибкая концепция Индустрии 4.0 могут быть описана и реа¬
лизована с использованием RAMI 4.0.
Эталонная архитектурная модель позволяет поэтапно перехо¬
дить из настоящего в мир Индустрии 4.0.
-263-
5. КАКОВЫ ОСОБЕННОСТИ ПЕРСПЕКТИВНЫХ ПАРАДИГМ И ПЛАТФОРМ
Модель объединяет различные точки зрения пользователей
и обеспечивает общее понимание технологий Индустрии 4.0. С помо¬
щью RAMI 4.0 требования секторов — от автоматизации производства
и машиностроения до технологического проектирования — могут быть
рассмотрены в отраслевых ассоциациях и комитетах по стандартиза¬
ции. Таким образом, RAMI 4.0 обеспечивает общее понимание стан¬
дартов и вариантов использования. RAMI 4.0 можно рассматривать как
своего рода дорожную карту по переходу к Индустрии 4.0.
IIoT можно рассматривать как платформу для построения Ин¬
дустрии 4.0. IIoT представляют собой индустриальную сервисную
экосистему, построенную на базе IoT-инфраструктуры, способную
гибко взаимодействовать с промышленным оборудованием, под¬
держивать производственные бизнес-процессы и адаптироваться
к изменениям производственных процессов. В основе IIoT лежит
идея объединения механизмов межмашинного (М2М) анализа дан¬
ных, которые поступают от промышленного оборудования.
IIoT должен обладать шестью базовыми возможностями:
1) интеллектуальное восприятие;
2) способность взаимодействовать с самым широким кругом
устройств;
3) реализовывать сложные процедуры управления;
4) работать с цифровыми моделями;
5) выполнять в реальном времени анализ данных;
6) реализовывать в реальном времени процедуры оптимиза¬
ции как структур, так и бизнес-процессов.
Наиболее важным для IIoT-систем представляется возможность
обрабатывать и «осмысливать» огромные объемы данных, которые
поступают от производственных подсистем, логистики, подразделе¬
ний, связанных с продажами. Это могут быть данные от RFID (Radio¬
frequency identification) аппаратуры, информация о складских запа¬
сах, информация о персонале и многое другое.
Для IIoT характерен очень высокий уровень гетерогенности
структуры и разнообразие БП, как следствие, использование боль¬
шого числа разнообразных протоколов и стандартов для поддержа¬
ния связей между оборудованием и людьми.
-264-
В чем особенности промышленного интернета вещей (IIoT)
Цифровое моделирование является средством представления
производственных ресурсов и создаваемых изделий в цифровой
форме, что открывает широкие возможности по моделированию
бизнес-процессов производства и управлению самим производст¬
вом с использованием моделей.
Использование IIoT предполагает возможность обрабатывать
в реальном времени в цифровом пространстве весь объем данных,
поступающих от всех ресурсов, используемых в производственном
процессе, и на основе анализа этих данных выдавать управляющие
воздействия для внешних физических сущностей.
IIoT должна обладать способностью к самоанализу и обучению.
Это должна быть открытая система, которую можно постоянно со¬
вершенствовать и развивать как в плане оптимизации структуры
и (или) масштабирования, так и в плане постоянного совершенст¬
вования БП.
Использование IIoT, обладающих перечисленными выше свой¬
ствами, должно привести к кардинальным изменениям в самом
подходе к организации процесса производства, в основу которого
предлагается положить такие технологии, как адаптивное управ¬
ление оборудованием, прогнозное техническое обслуживание обо¬
рудования, цифровые двойники, 3.0-печать и многие другие. Про¬
изводственные системы, построенные на платформе IIoT, также
называют киберфизическими производственными системами.
Одним из серьезных вызовов при создании киберфизических
производственных систем является стандартизация, поскольку
уровень их гетерогенности крайне высок. Можно считать, что IIoT
является базовой платформой для четвертой промышленной ре¬
волюции.
Следует заметить, что понятие IIoT во многом совпадает с по¬
нятием «Умное производство» (Smart Manufacturing). Однако поня¬
тие «умное производство» является более широким, поскольку
включает в себя само производственное оборудование, персонал,
производственные процессы, конечную продукцию. IIoT можно рас¬
сматривать как платформу, на которой строится подсистема управ¬
ления умным производством. IIoT также можно рассматривать как
двигатель цифровых трансформаций общества и производства.
-265-
5. КАКОВЫ ОСОБЕННОСТИ ПЕРСПЕКТИВНЫХ ПАРАДИГМ И ПЛАТФОРМ
С технической точки зрения IIoT представляет собой множество
взаимосвязанных датчиков, приборов и других устройств, объеди¬
ненных в сеть вместе с промышленными приложениями компьюте¬
ров, включая производство и управление энергопотреблением. Эта
связь позволяет осуществлять сбор, обмен и анализ данных, потен¬
циально способствуя повышению производительности и эффектив¬
ности, а также другим экономическим выгодам. IIoT — это эволюция
распределенной системы управления, которая обеспечивает более
высокую степень автоматизации за счет использования облачных
и туманных вычислений для контроля и оптимизации БП.
Современные IIoT строятся на платформах IoT по принципу ту¬
манных вычислений.
Эталонная архитектура IIoT определена в стандарте, разрабо¬
танном Консорциумом промышленного интернета в 2019 г., — «Эта¬
лонная архитектура промышленного интернета» [91]. В состав кон¬
сорциума входят такие компании, как Toshiba, IBM, General Electric,
SAP, Fujitsu, Oracle и ряд других. Данный документ предоставляет
рекомендации для архитекторов ИС, технологов, менеджеров раз¬
ного уровня и пользователей для согласования их усилий по созда¬
нию производственных систем нового поколения с принципиаль¬
но новыми функциональными возможностями.
В рамках эталонной архитектуры IIoT определяются четыре
уровня, которые соответствуют четырем точкам зрения:
- извлечение прибыли;
- использование ресурсов;
- функционирование;
- реализация.
На верхнем уровне (уровне извлечения прибыли) важными
функциями с точки зрения проблем управления производственны¬
ми процессами являются формирование критериев качества функ¬
ционирования, а также учет экономической эффективности, кото¬
рые в дельнейшем должны учитываться при организации работы
всего предприятия на основе промышленного интернета.
На уровне использования ресурсов формируются представле¬
ния о том, какие специалисты и какое оборудование будут исполь¬
зованы в технологических и управленческих процессах промыш¬
ленного предприятия.
-266-
В чем особенности промышленного интернета вещей (IIoT)
Следует заметить, что верхние два уровня отсутствуют в сте¬
ках протоколов IoT.
Следующие два уровня рассматривают IIoT с точки зрения БП
и реализации.
Уровень функционирования IIoT сконцентрирован на функци¬
ональных компонентах, их взаимосвязи, а также их связи с внеш¬
ними системами. Фактическое исполнение этих компонентов опи¬
сывается на уровне реализации.
На функциональном уровне проблемы построения промыш¬
ленного интернета делятся на пять областей:
1) системы управления технологическими процессами;
2) системы управления информационными процессами;
3) системы обработки данных и информации;
4) прикладные системы;
5) системы управления предприятием.
К настоящему времени в мировой практике достигнуты значи¬
тельные результаты в четырех из этих направлений.
Цифровые двойники (Digital twins, DT). В основе современной
концепции DT лежит идея модельного сопровождения системы на
всех этапах ее жизненного цикла.
В настоящее время известно несколько определений понятия
DT. Чаще всего его определяют как «виртуальное представление
объекта любой природы, которое двунаправленно связано с двой¬
ником. DT можно рассматривать как набор моделей для поддержки
всех заинтересованных сторон в течение всего жизненного цикла
системы или объекта».
В этом определении важными являются два момента. Во-пер¬
вых, c помощью цифрового двойника может быть представлен не
только физический объект, но и БП, а также система любой фи¬
зической природы, включая людей. Следует также заметить, что
с помощью DT может быть представлена и программная система.
Вторым важным моментом является то, что сама моделируемая
система может управлять состоянием DT. Это может быть полез¬
но, когда моделируемая система, например, изменила свое состо¬
яние. В этом случае DT также изменяет состояние.
-267-
5. КАКОВЫ ОСОБЕННОСТИ ПЕРСПЕКТИВНЫХ ПАРАДИГМ И ПЛАТФОРМ
Известно и еще одно определение, в соответствии с которым
DT определяется как «набор данных, информации и знаний, кото¬
рые представляют структуру, поведение и контекст наблюдаемой
и управляемой системы, а DT предлагает интерфейс, позволяющий
получать эти данные, информацию и знания о прошлой и нынеш¬
ней работе наблюдаемой и управляемой системы и делать прогноз
о будущем состоянии наблюдаемой и управляемой системы».
В этом определении важными являются следующие моменты:
- DT является в общем случае многоуровневой и многослойной
системой, которая может включать в себя другие модели;
- на разных этапах жизненного цикла используются разные
модели;
- DT могут строиться с использованием разных методологий
программирования (распределенные системы объектов, компо¬
нентные технологии SOA, Multi-Agent Systems (MAS));
- DT могут строиться в терминах знаний;
- для построения DT, соответствующих разным подсистемам
одной системы, могут использоваться различные технологии и плат¬
формы.
Цифровые нити (Digital threads). Идея цифровой нити в опре¬
деленном смысле обобщает идею DT и состоит в следующем. DT яв¬
ляется моделью, которая используется на этапе эксплуатации. С по¬
мощью множества цифровых теней можно отследить поведение
наблюдаемой и управляемой системы во времени. (Цифровая тень
отражает текущее состояние наблюдаемой системы.) Идея цифро¬
вой нити состоит в том, чтобы отследить состояние системы на всех
этапах жизненного цикла, начиная от момента появления идеи со¬
здания системы до момента окончания ее использования.
Цифровую нить обычно определяют как систему моделей,
которые описывают систему на протяжении всего ее жизненно¬
го цикла.
Таким образом идея состоит в том, чтобы построить некото¬
рый континиум моделей, которые описывают систему на протяже¬
нии всего времени жизни, включая проектирование, производство,
эксплуатацию и модернизацию.
В этом контексте DT — это одна из моделей, которая исполь¬
зуется на этапе эксплуатации. В этом случае процесс проектиро¬
-268-
В чем особенности промышленного интернета вещей (IIoT)
вания включает два параллельных процесса: процесс разработки
собственно системы и процесс разработки ее моделей, в качестве
которых выступает DT. Следует заметить, что на разных этапах ис¬
пользуется разный набор моделей. Например, на этапе производ¬
ства КФС используются модели оборудования и модели технологи¬
ческого процесса.
Цифровые нити можно рассматривать как процесс оцифров¬
ки и отслеживания продукта «от колыбели до могилы». Цифровая
нить соединяет все различные возможности цифрового двойни¬
ка с конструкциями деталей, требованиями и программным обес¬
печением, которые входят в продукт, представленный цифровым
двойником.
Можно сказать, что цифровая нить и полная отслеживаемость
продукта на протяжении всего жизненного цикла являются сино¬
нимами. В этом случае можно говорить, что цифровая нить являет¬
ся механизмом управления жизненным циклом изделия.
-269-
ЗАКЛЮЧЕНИЕ
ИТ занимают все более значимое место в жизни человека. Пос¬
тоянно увеличиваются их возможности и расширяется сфера при¬
менения. Современные ИС становятся все более сложными. Основ¬
ные подходы к проектированию ИС направлены на создание систем
из готовых компонентов, что приводит к повышению значимости
архитектурного подхода к проектированию ИС.
В настоящем издании авторы отразили современные достиже¬
ния в области проектирования ИС на основе архитектурных реше¬
ний, что обеспечивает переход к промышленным методам и сред¬
ствам работы с информацией в различных сферах человеческой
деятельности. Это дает возможность существенно сократить сро¬
ки и стоимость разработки, а также уменьшить вероятность непра¬
вильного функционирования ИС.
Тенденции развития архитектуры ИС связаны с формировани¬
ем ее ключевых элементов: принципов, стандартов и моделей. Эти
основополагающие конструкции взаимосвязаны между собой, и ко¬
нечной целью их применения является создание абстрактных кон¬
струкций, инвариантных к предметной области, которые обеспе¬
чивают единство в подходах к проектированию и созданию систем.
Современные ИС развиваются очень быстрыми темпами. Пос¬
тоянно появляются новые парадигмы и платформы, прежде все¬
го направленные на построение КФС и социотехнических систем
нового поколения, ориентированных на работу со знаниями. Ак¬
тивно идет процесс слияния информационных и телекоммуника¬
ционных технологий, все более активно используются технологии
виртуализации.
Создание ИС нового уровня сложности и надежности возможно
только посредством использования проверенных решений и, в част¬
ности, проверенных практикой архитектурных решений, поскольку
исправление ошибок, допущенных на архитектурном уровне, обхо¬
дится наиболее дорого.
ИТ стали важной сферой производственной деятельности с на¬
растающей динамикой роста, оказывающей непосредственное вли¬
яние на развитие всей экономики. Перечисленные ниже факторы
-270-
ЗАКЛЮЧЕНИЕ
являются наиболее важными в дальнейшем развитии информаци¬
онной индустрии в плане использования архитектурных решений.
1. Создание полноценного промышленного информационного
производства, соединяющего научное (теоретическое), исследова¬
тельское и производственное направления.
2. Развитие методов, технологий, навыков и инструменталь¬
ных средств, ориентированных на создание качественных продук¬
тов информационных технологий.
3. Комплексная стандартизация как одно из основных направ¬
лений промышленного развития информационных технологий.
Сформированная международная система стандартов информа¬
ционных технологий в области производства и образования (объе¬
диняет десятки профессиональных организаций) непрерывно раз¬
вивается.
4. Качество и надежность должны стать визитной карточкой
информационных продуктов. Основным ориентиром для обеспе¬
чения качества должно быть создание условий производства, га¬
рантирующих необходимый уровень качества.
-271-
ЛИТЕРАТУРА
1. Jamshidi, M. Systems of systems engineering. Principles and applications / M. Jam-
shidi. — Boca Raton : CRC Press, 2009.
2. Холл, А. Опыт методологии для системотехники / А. Холл. — Москва : Совет¬
ское радио, 1975.
3. Эшби, У.Р. Введение в кибернетику / У.Р. Эшби. — Москва : Иностранная лите¬
ратура, 1959.
4. Садовский, В.Н. Основания общей теории систем. Логико-методологический
анализ / В.Н. Садовский. — Москва : Наука, 1974.
5. Месарович, М. Теория иерархических многоуровневых системы / М. Месарович,
Д. Мако, Я. Такахара. — Москва : Мир, 1973.
6. Месарович, М. Общая теория систем / М. Месарович, Я. Такахара. — Москва :
Мир, 1978.
7. Бутырский, Е. Теория систем и системный анализ. Основы, конепции, методы /
Е. Бутырский. — Saarbrucken : Palmarium Academic Publishing, 2012.
8. Берталанфи, Л. фон. История и статус общей теории систем / Л. фон Берталан-
фи // Системные исследования : ежегодник. — Москва : Наука : Радио, 1974.
9. Черняк, Ю.И. Системный анализ и управление экономикой / Ю.И. Черняк. —
Москва : Экономика, 1975.
10. Харари, Ф. Теория графов / Ф. Харари. — Москва : Editorial URSS, 2003.
11. Оре, О. Теория графов / О. Оре. — 2-е изд. — Москва : Наука, 1980.
12. Calinescu, R.C. Socio-Cyber-Physical Systems: Models, Opportunities, Open Chal¬
lenges / R.C. Calinescu, J. Camara Moreno, C. Paterson // Proceedings of the 5th
International Workshop on Software Engineering for Smart Cyber-Physical Sys¬
tems. — URL: https://dl.acm.org/doi/proceedings/10.5555/3354016 (date of access:
15.08.2023).
13. Ackoff, R. From Data to Wisdom / R. Ackoff // Journal of Applied Systems Analysis. —
1989. — № 16.
14. Облачные вычисления // Википедия : [сайт]. — URL: http://ru.wikipedia.org/wiki/
Облачные_вычисления (дата обращения: 15.08.2023).
15. Знания // Википедия : [сайт]. — URL: http://ru.wikipedia.org/wiki/Знание (дата
обращения: 15.08.2023).
16. Данные // Википедия : [сайт]. — URL: http://m:wikipedia.org/wiki/Данные (дата
обращения: 15.08.2023).
17. Davis, W. The Information System Consultant’s Handbook. Systems Analysis and
Design / W. Davis, D. Yen. — Boca Raton : CRC Press, 1998.
18. Российская Федерация. Законы. Об информации, информационных техноло¬
гиях и о защите информации : Федеральный закон № 149-ФЗ : [принят Госу¬
дарственной Думой 8 июля 2006 года : одобрен Советом Федерации 14 июля
2006 года]. — Российская газета. — 29 июля 2006. — № 165.
19. Кагаловский, М.Р. Перспективные технологии информационных систем /
М.Р. Кагаловский. — Москва : ДМК Пресс : Компания АйТи, 2003.
-272-
ЛИТЕРАТУРА
20. ISO/IEC 2382-1:1993. Information technology — Vocabulary — Part 1: Fundamental
terms (утратил силу). — URL: https://www.iso.org/standard/7229.html (date of
access: 15.08.2023).
21. Lattanze, A.J. Architecting Software Intensive Systems. Practitioner’s Guide /
A.J. Lattanze. — Boca Raton : CRC Press, 2009.
22. Ambient Intelligence Services in IoT Environments: Emerging Research and Op¬
portunities / D. Korzun, E. Balandina, A. Kashevnik [et al.]. — Hershey : IGI-Global,
2019.
23. Internet of Nano-Things, Things and Everything: Future Growth Trends / M.H. Miraz,
M. Ali, P.S. Excell, R. Picking // Future Internet. — 2018. — № 10. — URL: https://arxiv.
org/ftp/arxiv/papers/1808/1808.09869.pdf (date of access: 15.08.2023).
24. Sanfelice, R. G. Analysis and Design of Cyber-Physical Systems. A Hybrid Control Sys¬
tems Approach / R.G. Sanfelice // Cyber-Physical Systems: From Theory to Practice /
D. Rawat, J. Rodrigues, I. Stojmenovic. — Boca Raton : CRC Press, 2016.
25. Cyber-Physical Systems: Architecture, Security and Application / Song Guo, Deze
Zeng (ed.). — Berlin : Heidelberg : Springer International Publishing AG, 2019. —
URL: https://doi.org/10.1007/978-3-319-92564-6 (date of access: 15.08.2023).
26. Bass, L. Software Architecture in Practice / L. Bass, P. Clements, R. Kazman. —
3rd ed. — Upper Saddle River : Addison-Wesley, 2013.
27. ISO/IEC 15288. Systems and software engineering — Life cycle processes. — URL:
https://www.iso.org/ru/standard/63711.html (date of access: 15.08.2023).
28. CMMI : [website]. — URL: http://www.sei.cmu.edu/ (date of access: 15.08.2023).
29. IEEE Std 1471-2000. IEEE Recommended Practice for Architectural Description
of Software-Intensive Systems. — URL: http://cabibbo.dia.uniroma3.it/ids/altrui/
ieee1471.pdf (date of access: 15.08.2023).
30. ISO/IEC/IEEE 42010. Systems and software engineering—Architecture description. —
URL: https://www.iso.org/standard/50508.html (date of access: 15.08.2023).
31. IT Glossary : [website]. — URL: http://www.gartner.com/it-glossary/ (date of access:
15.08.2023).
32. NIST_Enterprise_Architecture_Model // Wikipedia : [website]. — URL: https://en.wiki-
pedia.org/wiki/NIST_Enterprise_Architecture_Model (date of access: 15.08.2023).
33. Gasevic, D. Model Driven Architecture and Ontology Development / D. Gasevic,
D. Djuric, V. Devedzi. — Berlin : Heidelberg : Springer-Verlag, 2006.
34. Zheng, O. Software Architecture / O. Zheng, X. Jiankuan, Z. Xiang. — Hangzhou :
Zhejiang University Press ; Berlin : Heidelberg : Springer, 2008.
35. Taylor, R. Software Architecture Foundations, Theory and Practice / R. Taylor, N. Med-
vidovic, E. Dashofy. — Hoboken : Wiley, 2009.
36. ISO/IEC 10746. Reference Model for Open Distributed Processing (RM-ODP). — URL:
https://www.iso.org/ru/standard/55724.html (date of access: 15.08.2023).
37. Luckham, D.C. Specification and analysis of system architecture using RAPIDE /
D.C. Luckham, J.J. Kenney, L.M. Augustin [et al.] // IEEE Transactions on Software
Engineering. — 1995. — № 21 (4).
38. Matinlassi, M. The impact of maintainability on component-based software systems /
M. Matinlassi, E. Niemela // Proceedings of the 29th EUROMICRO Conference
(EUROMICRO’03). — Washington, DC : IEEE Computer Society, 2003.
-273-
ЛИТЕРАТУРА
39. Mellor, S.J. Guest editors’ introduction: Model-driven development / S.J. Mellor,
A.N. Clark, T. Futagami // IEEE Software. - 2003. - Vol. 20. - № 5.
40. Rozanski, N. Software Systems Architecture: Working with Stakeholders Using
Viewpoints and Perspectives / N. Rozanski, E. Woods // Viewpoints. — 2005. —
Vol. 8. — № 2.
41. Kruchten, P The Rational Unified Process. An Intriduction / P. Kruchten. — New York :
Addison-Wesley, 2000.
42. ATL — a model transformation technology // Eclipse Foundation : [website]. — URL:
http://eclipse.org/atl/ (date of access: 15.08.2023).
43. Czarnecki, K. Feature-Based Survey of Model Transformation Approaches / K. Czar-
necki, S. Helsen // IBM Systems Journal. — 2006. — № 45.
44. Zivin, B.E. On the Need for Megamodels / B.E. Zivin, J. Jouault, P. Valduriez // Proceedings
of the OOPSLA/GPCE: Best Practices for Model-Driven Software Development
Workshop, 2004. — URL: https://www.researchgate.net/publication/247043061_On_
the_Need_for_Megamodels (date of access: 15.08.2023).
45. Bharathi, B. UML as an Architecture Description Language / B. Bharathi, D. Sridharan //
International Journal of Recent Trends in Engineering. — 2009. — Vol. 1. — № 2, May.
46. OMG Systems Modeling Language (OMG SysML™) Version 1.4 // The Object Ma¬
nagement Group : [website]. — URL: http://www.omg.org/spec/SysML/L4/ (date of
access: 15.08.2023).
47. Stellman, A. Learning Agile. Understanding Scrum, XP, Lean, and Kanban / A. Stellman,
J. Greene. — Sebastopol, CA : O’Reilly, 2014.
48. Бек, К. Экстремальное программирование: разработка через тестирование /
K. Бек. — Санкт-Петербург : Питер, 2003.
49. Bass, L. DevOps. A Software Architect’s Perspective / L. Bass, I. Weber, L. Zhu. —
Hudson : Pearson Education, 2015.
50. Shahina M. Continuous Integration, Delivery and Deployment: A Systematic
Review on Approaches, Tools, Challenges and Practices / M. Shahina, M.A. Babara,
L. Zhu // IEEE Access. — 2017. — March. — URL: https://www.researchgate.net/
publication/315381994_Continuous_Integration_Delivery_and_Deployment_A_Sys -
tematic_Review_on_Approaches_Tools_Challenges_and_Practices (date of access:
15.08.2023).
51. Sommerville, I. Software Engineering / I. Sommerville. — Boston : Addison-Wesley,
2011.
52. ISO/IEC/IEEE 29148. Systems and software engineering — Life cycle processes —
Requirements engineering. ISO/IEC 2011 (утратил силу). — URL: https://www.iso.
org/ru/standard/45171.html (date of access: 15.08.2023).
53. Леффингуэл, Д. Принципы работы с требованиями к программному обеспече¬
нию / Д. Леффингуэл, Д. Уидриг. — Москва : Вильямс, 2002.
54. Вигерс, К. Разработка требований к программному обеспечению / К. Вигерс. —
Москва : Русская Редакция, 2004.
55. Халл, Э. Разработка и управление требованиями / Э. Халл, К. Джексон, Д. Дик. —
Лондон : Springer, 2005.
56. Ларман, К. Применение UML 2.0 и шаблонов проектирования / К. Ларман. —
3-е изд. — Москва : Вильямс, 2006.
-274-
ЛИТЕРАТУРА
57. Kazman, R. The architecture tradeoff analysis method / R. Kazman // Engineering
of Complex Computer Systems, IEEE International Conference. — URL: https://
www.computer.org/csdl/proceedings/iceccs/1998/12OmNAsk4xQ (date of access:
15.08.2023) .
58. Doing competencies well: Best practices in competency modeling / M.A. Campion,
A. Fink, B. Ruggeberg [et al.] // Personnel Psychology. Wiley Online Library. — 2011. —
Vol. 64. — № 1.
59. UNIX: руководство системного администратора / Э. Неммет pfgzne. Г. Снайдер,
C. Сибасс [и др.]. — Киев : BHV, 1996.
60. Handbook of multisensor data fusion: theory and practice / editors, M. Liggins,
D. Hall, J. Llinas. — 2nd ed. — Boca Raton : Taylor & Francis Group, 2009.
61. Стин, ван М. Распределенные системы / М. ван Стин, Э.С. Таненбаум. — Мос¬
ква : ДМК Пресс, 2021.
62. Szyperski, C. Component Software / C. Szyperski. — New York : Addison Wesley, 2002.
63. Wang, A. Component-Oriented Programming / A. Wang, K. Qian. — New Jersey : John
Wiley & Sons, 2005.
64. Цехановский, В.В. Управление данными : учебник / В.В. Цехановский, В.Д. Чер¬
товской. — Санкт-Петербург : Лань, 2015.
65. Hess, K.A. Practical Virtualization Solutions: Virtualization from the Trenches /
K.A. Hess, A. Newman. — Boston, MA, 2009.
66. Kubernetes : [website]. — URL: https://kubernetes.io/docs/home/ (date of access:
15.08.2023) .
67. Vohra, D. Kubernetes Microservices with Docker / D. Vohra. — New York : Apress
Media, 2016.
68. Частиков, А.П. Разработка экспертных систем. Среда CLIPS / А.П. Частиков,
Т.А. Гаврилова, Д.Л. Белов. — Санкт-Петербург : БХВ-Петербург, 2003.
69. Friedman-Hill, E. Jess in Action / E. Friedman-Hill. — Greenwich : Maning Publication
Co, 2003.
70. Halle, von B. Business Rules Applied: Building Better Systems Using the Business
Rules Approach / B. von Halle. — New York : Wiley Computer Publishing, 2002.
71. Browne, P JBoss Drools Business Rules / P. Browne. — New York : Packt Publishing,
2009.
72. Reference Architecture Foundation for Service Oriented Architecture Version 1.0. —
URL: https://docs.oasis-open.org/soa-rm/soa-ra/v1.0/soa-ra.html (date of access:
15.08.2023) .
73. Кочер, П.С. Микросервисы и контейнеры Docker / П.С. Кочер. — Москва : ДМК
Пресс, 2019.
74. Хабибуллин, И.Ш. Разработка Web-служб средствами Java / И.Ш. Хабибуллин. —
Санкт-Петербург : БХВ-Петербург, 2003.
75. Linux Virtualization // IBM Developer : [website]. — URL: http://www.ibm.com/deve-
loperworks/ru/library/l-linuxvirt/index.html (date of access: 15.08.2023).
76. Интернет вещей // Википедия : [сайт]. — URL: http://m.wikipedia.org/wiki/Интер-
нет вещей (дата обращения: 15.08.2023).
77. Lea, P Internet of Things for Architects / P. Lea. — Birmingham : Packt Publishing,
2018.
-275-
ЛИТЕРАТУРА
78. Gupta, D. Edge, and Pervasive Computing in Intelligent IoT Driven Applications /
D. Gupta, A. Khamparia. — New Jersey : John Wiley & Sons, 2021.
79. Open Fog Reference Architecture for Fog Computing. — URL: https://iiconsortium.
org/pdf/OpenFog_Reference_Architecture_2_09_17.pdf (date of access: 15.08.2023).
80. Edge computing // Gartner : [website]. — URL: https://www.gartner.com/en/infor-
mation-technology/glossary/edge-computing (date of access: 15.08.2023).
81. Edge-ик в тумане и другие приключения периферийных вычислений // Хабр :
[сайт]. — URL: https://habr.com/ru/company/ibm/blog/508n8/ (дата обращения:
15.08.2023) .
82. Buyya, R. Fog and Edge Computing Principles and Paradigms / R. Buyya, S.N. Sri-
rama. — New Jersey : John Wiley & Sons, 2019.
83. Макаров, С.Л. Arduino Uno и Raspberry Pi 3: от схемотехники к интернету вещей /
С.Л. Макаров. — Москва : ДМК Пресс, 2018.
84. Shovic, J.C. Raspberry Pi IoT Projects: Prototyping Experiments for Makers / J.C. Sho-
vic. — Washington, DC : Apress Liberty Lake, 2016.
85. Pujolle, G. Software Networks / G. Pujolle. — New Jersey : John Wiley & Sons, 2020.
86. Um, J.-S. Drones as Cyber-Physical Systems / J.-S. Um. — Singapore : Springer Nature
Pte Ltd, 2019.
87. Точное земледелие // Википедия : [сайт]. — URL: http://ru.wikipedia.org/wiki/Точ-
ное земледелие (дата обращения: 15.08.2023).
88. Mobile Edge Computing in Unmanned Aerial Vehicle Networks / F. Zhou, R.Q. Hu,
Z. Li, Y. Wang // IEEE Wireless Communications. — 2020, June. — URL: https://www.
researchgate.net/publication/338673494_Mobile_Edge_Computing_in_Unmanned_
Aerial_Vehicle_Networks (date of access: 15.08.2023).
89. Unmanned Aerial Vehicle Swarm-Enabled Edge Computing: Potentials, Promising
Technologies, and Challenges / W. Wu, F. Zhou, B. Wang [et al.]. — URL: https://arxiv.
org/pdf/2201.08517.pdf (date of access: 15.08.2023).
90. Таненбаум, Э. Компьютерные сети / Э. Таненбаум, Д. Уэзеролл. — 5-е изд. —
Санкт-Петербург : Питер, 2012.
91. Patnaik, S. New Paradigm of Industry 4.0 Internet of Things, Big Data & Cyber Phy¬
sical Systems / S. Patnaik. — URL: https://doi.org/10.1007/978-3-030-25778-1 (date
of access: 15.08.2023).
92. Верзилин, Д.Н. Неокибернетика: состояние исследований и перспективы раз¬
вития / Д.Н. Верзилин, Б.В. Соколов, Р.М. Юсупов // Научная электронная биб¬
лиотека «КиберЛенинка» : [сайт]. — URL: https://cyberleninka.ru/article/n/neo-
kibernetika-sostoyanie-issledovanii-i-perspektivy-razvitiya (дата обращения:
15.08.2023) .
-276-
ДЛЯ ЗАМЕТОК
С 2005 года выпускаем качественную
литературу, развиваем инновационные
платформы и меняем систему образования
ЭКОСИСТЕМА IPR SMART
^prsmart - цифровой образовательный ресурс, большая
электронная библиотека учебных и практических изданий,
а также современные, удобные сервисы для преподавания и обучения,
в том числе с применением адаптивных технологий.
Включает более 155 000 книг, журналов, аудиоизданий.
U
IPR MEDIA
ИЗДАТЕЛЬСТВО
МОБИЛЬНЫЕ ПРИЛОЖЕНИЯ
\J^ Мобильное приложение полностью обеспечивает
эффективную и удобную работу пользователей
с книгами на смартфоне или планшете.
ш IPR BOOKS-WV Reader
Мобильное приложение для людей с ограниченными
возможностями по зрению.
Приложения работают на операционных системах IOS и Android
DataLIB j - первая образовательная платформа по освоению
цифровых компетенций - более 3 500 изданий
по информационным и сквозным цифровым технологиям,
а также набор интерактивных инструментов для преподавания
и обучения (SMART-курсы, модуль «Цифровая кафедра»,
система групповой работы, лекторий).
- современный цифровой ресурс для обучения
иностранных студентов и абитуриентов, содержащий
издания, онлайн-курсы, тесты, аудио- и видеоматериалы.
в рки
Заинтересованы
в сотрудничестве с нами?
Следите за новостями
в социальных сетях
8 800 555 22 35
Звонок бесплатный по всей России
izdat@iprmedia.ru
Ответим на все Ваши вопросы
@iprmedia
@ipredu_online
Получайте образование уже сегодня
на платформе онлайн-обучения DATALIB.RU
(37 Онлаин-курсы и другой контент по всем сквозным цифровым
технологиям и направлениям подготовки
(37 Топовые образовательные программы
от ведущих университетов страны
(37 Лекторий с лучшими спикерами -
экспертами-практиками и преподавателями
(37 Возможность выстроить свою образовательную траекторию
на платформе и обучаться у лучших
(37 Образовательные сертификаты всем слушателям
Профориентация
в цифровой экономике
Цифровые технологии
в транспортном строительстве
Получите
тестовый
доступ
8 800 555 22 35
marketing@iprmedia.ru
EDP HUB
ИЗДАТЕЛЬСТВО
Международное издательство,
выпускающее учебные, научные
и практические издания на разных языках
для всех уровней образования
В e-uni - международная платформа для подготовки высоко¬
квалифицированных кадров с цифровой библиотекой,
онлайн-курсами и digital-сервисами для обучения. Ресурс
объединяет лучшие международные практики на одной платформе.
0 Самая большая национальная цифровая библиотека
учебного и научного контента для университета и колледжей
0
0
0
0 Удобный модуль для выстраивания «Цифрового университета»
Только лицензионный контент на казахском, английском и русском языках
Доступные интерактивные инструменты для обучения: онлайн-курсы и Лекторий
Современные сервисы для преподавания и обучения
Станьте автором международного уровня:
выгодные условия сотрудничества для авторов
^2) затраты по производству и популяризации изданий EDP Hub берет на себя
^ индивидуальный подход к каждой работе
^ публикация изданий в электронном виде на международных платформах
^5) издание книг в печатном виде
^6) профессиональная редакционно-издательская подготовка, присвоение ISBN
присвоение DOI, повышение видимости и увеличение цитируемое™ изданий
возможность участия в международных конкурсах авторских работ, ежегодно
организуемых издательством
Направьте свою авторскую
работу или откройте
тестовый доступ к платформе
edp_hub@mail.kz
г]
ПРОФОБРАЗОВАНИЕ
Издательство «Профобразование» -
издательство учебной и профильной
литературы для среднего
профессионального образования.
Издания включены в ПОП в качестве
основной и дополнительной литературы
(более 700 рекомендаций ФУМО СПО)
ПАРТНЕРСКИЕ ПРОЕКТЫ
СИ пюЁаонш№1 - °дна из крупнейших в России
специализированных библиотек
для учреждений СПО. В цифровой библиотеке доступны к
подключению более 8 000 учебных изданий, журналы, онлайн-
курсы, тесты, аудио- и видеоматериалы, а также учебники
издательства «Просвещение», входящие в Федеральный
перечень учебников.
^4 смарт - современное решение для проверок работ
на объем заимствований и банк электронных
портфолио обучающихся. Безопасный и надежный
репозиторий данных, а также работ студентов
и преподавателей.
Заинтересованы
в сотрудничестве с нами?
Следите за новостями
в социальных сетях
8 800 5111470
Звонок бесплатный по всей России
office@profspo.ru
Ответим на все Ваши вопросы
@profobrazovanie_official
{Sprofobrexp
Издавайте книги вместе с нами!
IPR MEDIA, «Профобразование» и «Вузовское образование»
ведущие издательства, с 2005 года выпускающие
высококачественную учебную и практическую литературу
для высшего и среднего профессионального образования,
а также практическую литературу по актуальным
востребованным темам для широкого круга лиц
Преимущества работы для авторов:
,Т) индивидуальный подход
профессиональная редакционно-издательская подготовка
и оперативное издание
J) публикация изданий в электронном и печатном виде
^4) качественное полиграфическое исполнение изданий
выплата вознаграждения
бесплатные авторские экземпляры
^2) рост публикационной активности и цитируемости
^S) присвоение изданиям ISBN и DOI,
передача данных в РИНЦ
^9) защита изданий от незаконного использования
и распространения
jg) продвижение авторов и их изданий,
в том числе через маркетплейсы, конкурсы, мероприятия
Хотите издать книгу?
Свяжитесь с нами,
880055522 35
доб. 208, 227,229
чтобы обсудить условия ,§) izdat@iprmedio.ru
Рекомендуемые новинки
КАК
ОБЕЗОПАС
СВОЙ
БИЗНЕС
АНАСТАСИЯ
КУЛЬНАЗАРОВА
УМНОЕ
ПРОДВИЖЕНИЕ
si
цифровые технологии
Купить книгу
8 800 555 22 35 (доб 214)
bookstaiprmedia.ru
Владислав Цехановский
Александр Водяхо
АРХИТЕКТОР ИНФОРМАЦИОННЫХ СИСТЕМ:
КАК ПРОЕКТИРОВАТЬ БОЛЬШИЕ СИСТЕМЫ
Главный редактор Ю.Б. Захарова
Выпускающий редактор Н.Г. Шиндина
Редактор Ю.В. Семенова
Технический редактор Ю.Ю. Желтова
Корректор О.А. Адясова
Компьютерная верстка Ю.Р. Валиахметова
Обложка Т.А. Антонова, фотобанк Freepik
По вопросам приобретения экземпляров издания:
ООО Компания «Ай Пи Ар Медиа»
8-800-555-22-35 (бесплатный звонок по России)
доб. 214, 208, 222
E-mail: izdat@iprmedia.ru, books@iprmedia.ru
Наши книги представлены:
Читай-город (chitai-gorod.ru)
Ozon (ozon.ru)
Wildberries (wildberries.ru)
Яндекс Маркет (market.yandex.ru)
Подписано в печать 06.10.2023. Бумага офсетная.
Формат 60*90/16. Гарнитура «PT Serif».
Печать цифровая. Печ. л. 17,75
Тираж 1000 экз. (1-й з-д 1-100 экз.).
Общество с ограниченной ответственностью Компания «Ай Пи Ар Медиа»,
410012, г. Саратов, а/я 916
Акционерное Общество «Т 8 Издательские Технологии» (АО «Т 8»),
109316, г. Москва, Волгоградский пр-т, д. 42, корп. 5