Доклад А.Левенчука "SysArchi -- системное моделирование в ArchiMate 3.0" на семинаре "Дни инженерии организаций" факультета информатики, математики и компьютерных наук НИУ ВШЭ. Москва-Нижний Новгород, 11 сентября 2018
1. SysArchi – системное моделирование
в ArchiMate 3.0
Москва-Нижний Новгород,
11 сентября 2018г.
2. Что такое SysArchi
2
SysArchi, или "системный Архимейт" это стиль программирования
на ArchiMate 3.0, помогающий явным образом опереться на
понятия системного подхода при моделировании не только
организационных систем, но и их целевых систем по тем же
принципам, что декларируются в подходе моделе-
ориентированной системной инженерии (Model-Based Systems
Engineering, MBSE) с использованием архитектурных языков
SysML, AADL и др..
При этом моделирование на Архимейте ещё и обеспечивающей
системы (жизненного цикла, вместо традиционно
использующихся тут языков ситуационной инженерии методов
OMG SPEM, OMG Essence, ISO 24744, но также и структуры ролей и
организационных мест предприятия) обеспечивают полноту
системного моделирования в инженерном проекте.
3. SysArchi
• Инициатива: Русского отделения INCOSE
(решения IX рабочей встречи в Бекасово),
координатор проекта – А.Левенчук, директор
по исследованиям
(https://ailev.livejournal.com/1422923.html).
• Поддержка: Школа системного менеджмента
(используется в курсах «Системная
инженерия.Менеджмент продукта»
В.Мизгулина, «Системный менеджмент и
стратегирование» А.Левенчука, «Системное
лидерство» А.Турханова) – http://system-
school.ru/ (используется как обязательный)
• Состояние: проект обсуждается
(https://yadi.sk/i/DgjcxXh3yPjQIA), делается
пример моделирования.
3
4. OpenGroup АrchiMate 3.0
• Открытая спецификация:
http://pubs.opengroup.org/architecture/archimate3-doc/
(перевода на русский нет)
• Системный язык: соответствует ISO 42010
• Соответствует TOGAF 9.1 (и есть проект гармонизации)
• Прямые соответствия с BPMN, UML, BMM
• Начальная дизайн-цель Архимейта: общая архитектурная
модель для деятельности и её IT-поддержки [более чем
удалось!]
• Примеры: в Сети отсутствуют, но сам язык крайне
распространён
• Огромное количество программного обеспечения (моделеров)
• Бесплатный моделер Archi 4.1 для ArchiMate 3.0 (от 21 ноября
2017) -- http://www.archimatetool.com/ с русификацией
• Новость: превью плагина для коллективной работы
4
6. Пример архитектурной диаграммы
(student lifecycle core diagram)
6
http://enterprisearchitect.blogs.ilrt.org/2014/05/19/enterprise-architecture-approach-in-an-he-institution-10-practical-steps/
7. Архитектурный подход
Что кто с чем зачем делает
Возможности
Деятельность
Программы
«Железо»
Физика
Реализация
7
У
р
о
в
н
и
Основная дизайн-цель:
• На одной диаграмме показать объекты интереса бизнеса и IT (софта и железа)
Полезен для:
• «вгрызания в детали» одного уровня
• коммуникации между ответственными за уровни
• облегчения работ по модуляризации предприятия
предметы действия выполнители целеполагание
10. Нужен моделер
Почему не VISIO или yED: типы!!!
10
Это только одна из четырёх таблиц Core concepts.
Таблицы входят в спецификацию и поддерживаются софтом.
11. Руководство «Архимейт по-русски» (пока для 2.1)
• Эти материалы есть в интернете:
http://ailev.livejournal.com/988360.html
• Для удобства прилагаются одним файлом к слайдам
этого тренинга
• История:
• Классический перевод
• «перевод для директора» версии 1.0
• Уточнения версии 1.1 (ещё меньше канцелярита):
http://ailev.livejournal.com/1205591.html
• По-английски свежие новости по 3.1:
http://blog.bizzdesign.com/topic/archimate
• Видеоканал: https://www.youtube.com/channel/UC-
fR7d7Z2HheSUqFxzTq6Ow
11
12. Основные решаемые
проблемы
• Нет элемента «система», объединяющего многие
ипостаси. В частности, «аристотелевская физика»
(пассивные и активные объекты), много сортов
разных систем.
• Показ модульного синтеза: трудности в
единообразном показе назначения функции на
конструкцию
• Практика и business function: неполное их
соответствие и плохое различение их от процессов.
• Слишком много элементов языка для
моделирования, невозможно использовать как
«чеклист» понятий системного подхода.
12
13. Работа с уровнями абстракции
13
Понятия системного подхода
Прикладная дисциплина
Предметы в 4D мире
Архимейт
SysArchi
SysМоLan
14. Системная инженерия: борьба со сложностью
14
Systems Engineering (SE) is an interdisciplinary approach
and means to enable the realization of successful systems.
It focuses on holistically and concurrently understanding stakeholder needs; exploring
opportunities; documenting requirements; and synthesizing, verifying, validating, and
evolving solutions while considering the complete problem, from system concept
exploration through system disposal.
http://sebokwiki.org/wiki/Systems_Engineering_(glossary)
15. Наш вариант системного подхода
• Не изобретаем «системный велосипед»!
• Опора на современные международные и отраслевые
стандарты и публичные документы системной
инженерии и инженерии предприятий.
• ISO/IEC/IEEE 15288:2015
• ISO/IEC/IEEE 42010:2011
• IEC 81346-1:2009
• ISO 11354-1:2011
• ISO 15926-2:2003
• OMG Essence 1.1:2015
• OMG SBVR:2013
• OpenGroup ArchiMate 3.0
• NIST PWG CPS Framework
• … и другие
16. Системное мышление
• Есть онлайн-курс с
проверкой задач
(Курсера, еНано):
http://www.systemsthinkingcourse.ru/
• Универсален для
инженерии предприятия
и системной инженерии
• Раскрывает основные
понятия системного
подхода
16
https://www.litres.ru/anatoliy-levenchuk/sistemnoe-myshlenie/
17. Понятие системы
(один курс – и вся жизнь)
• Воплощение (присутствие в мире)
• Стейкхолдеры: деятельностная субъективность
• Холон (целокупность и эмерджентность)
• Идеальное против материального (моделирование:
определение и воплощение)
• Функционал против конструктива: дуальность
холона. И далее за дуальностью: «многерица»
междисцилинарности. Творчество и противоречия.
• Жизненный цикл (с выделенной стадией
эксплуатации) как система деятельности. 17
18. Холархия (holarchy) и холон (holon)
18
Целевая система
(Использующая система)
(система в операционном окружении)
(подсистема)
Подсистема
(Целевая система)
(Использующая система)
(система в операционном
окружении)
Использующая система
(целевая система)
(система в операционном окружении)
(подсистема)
Обеспечивающая
система1
3
2
5
4
Система в
операционном
окружении
Истинные отношения «часть – целое» (composition):
различные разбиения (breakdown)
19. На этой картинке пять систем!
System of
interest
Требования
(стратегия)
System of
interest
Ограничения
(Архитектура)
Using system
Нужды
стейкхолдеров
19
1 2
4 Enabling systemСистема в
операционном
окружении
3
Подсистема
5
Холархия
21. Базовые структуры определения системы
• =Компоненты
• -Модули
• +Места
• Огромное число вариантов представления каждого.
• Это только базовые, есть огромное число других!
• В чистом виде не бывают, распространены гибридные стили.
21
Разные холархии
(разбиения)!
На уровне целевой
системы все
совпадают!
22. Пространственно-временная карта элемента системы
22
Насос 1 Насос 2
Тег P101
время
пространство
Установка первичной
перегонки нефти
Компонента
Установленный на своё место
модуль
Физический объект – модуль
Система
(компонента)
http://www.matthew-west.org.uk/Publications.html
Замены насосов, программ, президентов, супругов, поставщиков, …
23. Рекомендуем прочитать
• Chris Partridge
«Business Objects:
Re-Engineering for
Re-Use»
(BORO book)
23
http://www.borosolutions.co.uk/research/conte
nt/files/books/BusObj-Printed-20050531-with-
watermark.pdf
Business в IT –
«организационный»
26. Совмещение логической и физической архитектур
(важных решений) по версии ISO 81346-1
(Figure 7)
26
«Логическая архитектура»
(функциональная
декомпозиция, структура
компонент) итеративно
совмещается с «физической
архитектурой» (продуктная
декомпозиция, структура
модулей)
27. Итак, архитектура:
• функция + конструкция
или оно же как
• компоненты+модули+размещения (только важные,
верхнеуровневые!),
или оно же как
• принципиальная схема + заказная спецификация+компоновка
(только важные, верхнеуровневые!)
или оно же как
• логическая архитектура + физическая архитектура (при учёте
возражения о недопустимости «частных
однодисциплинарных архитектур»)
или оно же как
• Список важнейших принятых конструкторских/проектных
решений
27
30. Дисциплины жизненного цикла
моделеориентированной системной инженерии
• Инженерия системных целей
• Высокоуровневое моделирование (инженерия системной
архитектуры)
• Низкоуровневое моделирование – мультифизика,
мегамоделирование
• Обеспечение качества (верификация)
• Порождающее производство (из битов в атомы)
• Приёмка (валидация)
• Эксплуатация и поддержка
• Мусоропереработка
• Инженерия знаний, НСИ, справочных данных
• Приход AI всё меняет
Доклад «Практики системной инженерии»:
https://ailev.livejournal.com/1433768.html
30
31. Инженерия предприятия
• Всё то же самое!!!
• Это просто обеспечивающая система, она тоже
система.
• Терминология различается:
• Потребности-требования: стратегия
• Модули: подразделения
• Компоненты: практики
• Управление конфигурацией: учёт
31
34. Стейкхолдер
• В Архимейте – business role (внутренний),
stakeholder (внешний).
• В OMG Essence та же проблема: stakeholders
(внешние) и team (внутренние)
• В SysArchi: оставляем business role и называем
«стейкхолдер» -- обеспечивая рекурсивное
применение паттернов моделирования на
многих уровнях системы.
34
35. Оргзвено и оргинтерфейс
• В архимейте Actor взят из DEMO – это единица принятия
ответственности.
• В SysArchi это модуль как единица организации: оргзвено
• business в ISO29148 рекомендуется переводить как
«организационный»
• В ISO 15288 организация определяется как люди, оборудование и
сооружения, с известным распределением полномочий (т.е. люди
там Actors из DEMO)
• Нас интересуют совещания, рабочие команды проекта (не только
фирмы), отдельные люди. Общее название: оргзвено, где «орг»
означает отнесение к уровню координационной работы.
• Это модули организационной структуры («из чего сделано», а не
«как работает»).
• Оргзвенья собираются в целую организацию через
оргинтерфейсы.
• Склоняемся к решению, что интерфейсы – это «междумордия», а
не «интерфейсные модули». То есть они не включаются в состав
оргзвеньев, они «между».
• Сервисы/практики/capabilities пока не рассматриваем как главные
соединительные элементы уровней архитектуры
35
36. Подход Яна Диеца (DEMO)
36
http://ailev.livejournal.com/644440.html
37. Оборудование и его функционал
• Оборудование/инструменты показываются как
equipment
• Оборудование это часть оргзвена («мои вещи –
часть моего тела»), показываем через
отношение ассоциации с именем «имеет» --
«отдел разработки имеет 3D принтер»,
«департамент IT имеет серверную ферму»
• Функционал оборудования – это
компоненты/функциональные элементы.
37
38. Физические объекты и
информационные объекты
• Пассивные физические объекты моделируем
элементом material, но называем «физический
объект» для общности.
• Информационные объекты Архимейта уважаем, это
концептуальные объекты – частные system
definitions. System descriptions моделируем как
данные и далее artifacts. От использования
representations воздерживаемся.
• Показ активного и пассивного объекта
(оборудования в использующей системе –
физического объекта как целевой системы)
используем ассоциацию с именем «то же, что».
38
39. Целеполагание
• Интерес/concern – driver (тема)
• Дисциплина (в том числе определяет viewpoint) –
principle
• Оценка интереса – assessment
• Цель (goal) – указание на действие, глагол
повелительного наклонения, направлена на
изменение оценки интереса
• Требование – Requirement (поскольку
многоуровневость, то воздерживаемся от
«ограничения», это требование к элементам более
низкого системного уровня.
39
40. Практика
• Для моделирования практик используем business
function, для функционала программ и аппаратуры
используем соответствующие functions.
• Оргсервис не показываем, но показываем
выполнение практики на оргинтерфейсе, если
нужно указать SLA, то указываем элементом
«требование».
• Оргвозвожность/capability не моделируем отдельно.
По сути появление оргвозможности это указание
того, что а) практика назначена на оргзвено, б)
воплощена, в) валидирована, г) налажено
оперативное управление (логистика ресурсов,
нужных для выполнения назначаемых на неё
работ).
40
42. Спектр формальности мышления
42
Цепочка «Фундаментальное образование»: https://ailev.livejournal.com/1390318.html
Надо работать и со схемами, и со схемоидами!
Архимейт/SysArchi
Архитектурное
эссе
ISO 15926
43. Архимейт намеренно невнятен
• Это утка или заяц?
• Тем не менее, это не обувная фабрика, и не
космический корабль!
• Тип важен, но в Архимейте он не дискретен!
• Разные типы ведут себя по-разному в отношениях!
43
44. Развитие и совершенствование инженерии
(в том числе инженерии предприятия)
44
Р
Е
З
У
Л
Ь
Т
А
Т
Ы
ВРЕМЯ
III поколение
Моделе-ориентированная (model-
based) инженерия: формальные
языки (вычисляемый «код»)
II поколение
Современная («классическая»)
инженерия: диаграммы и
чертежи («псевдокод»)
I поколение
«Алхинженерия»:
неформальные тексты и
эскизы
199018601400
IV поколение
Искусственный
интеллект:
гибридные
вычисления
(+автоматизация
неформального)
2020
45. Визуальное мышление
Утопия «графического языка»:
• Только для маленьких
моделей
• Сложность в управлении
конфигурацией (сравнение,
поиски, изменения, вставки,
утеря понимания при
переразводке диаграмм)
• Утеря контекста при листании
(текст более компактен в
передаче информации на
единицу площади)
• …
45
https://www.litres.ru/anatoliy-levenchuk/vizualnoe-myshlenie-doklad-o-tom-pochemu-im-nelzya-obol/
46. Что делаем: SysMoLan
SysMoLan : System Modeling Language
https://ailev.livejournal.com/1443879.html
«Иметь возможность нарисовать на одной схеме
системы то, что раньше рисовалось только на двух
разных, чтобы явно указать связи и обсудить».
• Ничего нового: такая была дизайн-цель ArchiMate
(прожекторный язык, факт-ориентированный).
• Отличия от SysML: в самом SysML множество
диаграмм изначально, нет языка запросов и мэппинга,
нет факт-ориентированности, нет upper ontology и т.д.
• Одновременно product и project модели
46
47. SysMoLan
• Три языка в одном (данных, прожективный-запросы, синтетический-мэппинг для «инженерии в
большом»). Проблема.
• Факт-ориентированный [как Архимейт], со внешним представлением, но не семантический
веб. Проблема.
• Графический и текстовый синтаксисы. Проблема
• Онтологический (конфигуратор для дисциплин: upper ontology, общая модель мира – против
онтик-микротеорий-без-объединения) – как ISO 15926, но со внешним представлением.
Проблема.
• Требования и архитектура [как SysML]
• Гибридные вычисления [тексты и эскизы, псевдокод, код в одном флаконе]. Выход на поиск-
ориентированность. Проблема.
• Аказуальное моделирование [как Modelica и SyM]
• Киберфизические системы [как AADL]. Исполняемость [как xUML] – проблема.
• Язык как стандарт отдельно, моделеры как софт отдельно.
• Архитектурные библиотеки (как в Modelica) + каталоги продукции (как ISO 15926): поддержка
языком «инженерии в большом»
• Жизненный цикл и ситуационность (независимость от проекта) [как Essence].
• Стык product model и project model (case management и project management). Проблема.
• 20% выразительных фич должны закрыть 80% случаев использования. Проблема. Но это и
есть определение предметной области.
47
https://ailev.livejournal.com/1443879.html
48. 48
Спасибо за внимание
Анатолий Левенчук
Школа системного менеджмента,
научный руководитель
Русское отделение INCOSE, директор
по исследованиям
http://ailev.ru
ailev@asmp.msk.su
11 сентября
2018