Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

А.Левенчук -- SysArchi

4,257 views

Published on

Доклад А.Левенчука "SysArchi -- системное моделирование в ArchiMate 3.0" на семинаре "Дни инженерии организаций" факультета информатики, математики и компьютерных наук НИУ ВШЭ. Москва-Нижний Новгород, 11 сентября 2018

Published in: Engineering
  • Be the first to comment

А.Левенчук -- SysArchi

  1. 1. SysArchi – системное моделирование в ArchiMate 3.0 Москва-Нижний Новгород, 11 сентября 2018г.
  2. 2. Что такое SysArchi 2 SysArchi, или "системный Архимейт" это стиль программирования на ArchiMate 3.0, помогающий явным образом опереться на понятия системного подхода при моделировании не только организационных систем, но и их целевых систем по тем же принципам, что декларируются в подходе моделе- ориентированной системной инженерии (Model-Based Systems Engineering, MBSE) с использованием архитектурных языков SysML, AADL и др.. При этом моделирование на Архимейте ещё и обеспечивающей системы (жизненного цикла, вместо традиционно использующихся тут языков ситуационной инженерии методов OMG SPEM, OMG Essence, ISO 24744, но также и структуры ролей и организационных мест предприятия) обеспечивают полноту системного моделирования в инженерном проекте.
  3. 3. SysArchi • Инициатива: Русского отделения INCOSE (решения IX рабочей встречи в Бекасово), координатор проекта – А.Левенчук, директор по исследованиям (https://ailev.livejournal.com/1422923.html). • Поддержка: Школа системного менеджмента (используется в курсах «Системная инженерия.Менеджмент продукта» В.Мизгулина, «Системный менеджмент и стратегирование» А.Левенчука, «Системное лидерство» А.Турханова) – http://system- school.ru/ (используется как обязательный) • Состояние: проект обсуждается (https://yadi.sk/i/DgjcxXh3yPjQIA), делается пример моделирования. 3
  4. 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
  5. 5. Элементы языка Архимейт 3.0 5 И всё! обслуживания путь
  6. 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. Архитектурный подход Что кто с чем зачем делает Возможности Деятельность Программы «Железо» Физика Реализация 7 У р о в н и Основная дизайн-цель: • На одной диаграмме показать объекты интереса бизнеса и IT (софта и железа) Полезен для: • «вгрызания в детали» одного уровня • коммуникации между ответственными за уровни • облегчения работ по модуляризации предприятия предметы действия выполнители целеполагание
  8. 8. Что принёс 3.0 -- https://twitter.com/ArchiMate_r 8
  9. 9. Метамодель (из спецификации) 9
  10. 10. Нужен моделер Почему не VISIO или yED: типы!!! 10 Это только одна из четырёх таблиц Core concepts. Таблицы входят в спецификацию и поддерживаются софтом.
  11. 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. 12. Основные решаемые проблемы • Нет элемента «система», объединяющего многие ипостаси. В частности, «аристотелевская физика» (пассивные и активные объекты), много сортов разных систем. • Показ модульного синтеза: трудности в единообразном показе назначения функции на конструкцию • Практика и business function: неполное их соответствие и плохое различение их от процессов. • Слишком много элементов языка для моделирования, невозможно использовать как «чеклист» понятий системного подхода. 12
  13. 13. Работа с уровнями абстракции 13 Понятия системного подхода Прикладная дисциплина Предметы в 4D мире Архимейт SysArchi SysМоLan
  14. 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. 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. 16. Системное мышление • Есть онлайн-курс с проверкой задач (Курсера, еНано): http://www.systemsthinkingcourse.ru/ • Универсален для инженерии предприятия и системной инженерии • Раскрывает основные понятия системного подхода 16 https://www.litres.ru/anatoliy-levenchuk/sistemnoe-myshlenie/
  17. 17. Понятие системы (один курс – и вся жизнь) • Воплощение (присутствие в мире) • Стейкхолдеры: деятельностная субъективность • Холон (целокупность и эмерджентность) • Идеальное против материального (моделирование: определение и воплощение) • Функционал против конструктива: дуальность холона. И далее за дуальностью: «многерица» междисцилинарности. Творчество и противоречия. • Жизненный цикл (с выделенной стадией эксплуатации) как система деятельности. 17
  18. 18. Холархия (holarchy) и холон (holon) 18 Целевая система (Использующая система) (система в операционном окружении) (подсистема) Подсистема (Целевая система) (Использующая система) (система в операционном окружении) Использующая система (целевая система) (система в операционном окружении) (подсистема) Обеспечивающая система1 3 2 5 4 Система в операционном окружении Истинные отношения «часть – целое» (composition): различные разбиения (breakdown)
  19. 19. На этой картинке пять систем! System of interest Требования (стратегия) System of interest Ограничения (Архитектура) Using system Нужды стейкхолдеров 19 1 2 4 Enabling systemСистема в операционном окружении 3 Подсистема 5 Холархия
  20. 20. Междисциплинарность (на одном уровне, даже без холархии) На основе рис.3 в ISO 81346-1 -Модули =Компоненты +Места 20
  21. 21. Базовые структуры определения системы • =Компоненты • -Модули • +Места • Огромное число вариантов представления каждого. • Это только базовые, есть огромное число других! • В чистом виде не бывают, распространены гибридные стили. 21 Разные холархии (разбиения)! На уровне целевой системы все совпадают!
  22. 22. Пространственно-временная карта элемента системы 22 Насос 1 Насос 2 Тег P101 время пространство Установка первичной перегонки нефти Компонента Установленный на своё место модуль Физический объект – модуль Система (компонента) http://www.matthew-west.org.uk/Publications.html Замены насосов, программ, президентов, супругов, поставщиков, …
  23. 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 – «организационный»
  24. 24. 24 Описание системы (ISO 42010 – OMG Essence): субъективно и требует метода
  25. 25. Альтернативное определение Архитектура – это обо всём важном. Что бы это ни было. Ralf Johnson 25
  26. 26. Совмещение логической и физической архитектур (важных решений) по версии ISO 81346-1 (Figure 7) 26 «Логическая архитектура» (функциональная декомпозиция, структура компонент) итеративно совмещается с «физической архитектурой» (продуктная декомпозиция, структура модулей)
  27. 27. Итак, архитектура: • функция + конструкция или оно же как • компоненты+модули+размещения (только важные, верхнеуровневые!), или оно же как • принципиальная схема + заказная спецификация+компоновка (только важные, верхнеуровневые!) или оно же как • логическая архитектура + физическая архитектура (при учёте возражения о недопустимости «частных однодисциплинарных архитектур») или оно же как • Список важнейших принятых конструкторских/проектных решений 27
  28. 28. Что важного считают в INCOSE 28
  29. 29. MBSE в версии INCOSE 29
  30. 30. Дисциплины жизненного цикла моделеориентированной системной инженерии • Инженерия системных целей • Высокоуровневое моделирование (инженерия системной архитектуры) • Низкоуровневое моделирование – мультифизика, мегамоделирование • Обеспечение качества (верификация) • Порождающее производство (из битов в атомы) • Приёмка (валидация) • Эксплуатация и поддержка • Мусоропереработка • Инженерия знаний, НСИ, справочных данных • Приход AI всё меняет Доклад «Практики системной инженерии»: https://ailev.livejournal.com/1433768.html 30
  31. 31. Инженерия предприятия • Всё то же самое!!! • Это просто обеспечивающая система, она тоже система. • Терминология различается: • Потребности-требования: стратегия • Модули: подразделения • Компоненты: практики • Управление конфигурацией: учёт 31
  32. 32. ArchiEssence 32 Возможности Материал Оборудование
  33. 33. Метамодель SysArchi 33
  34. 34. Стейкхолдер • В Архимейте – business role (внутренний), stakeholder (внешний). • В OMG Essence та же проблема: stakeholders (внешние) и team (внутренние) • В SysArchi: оставляем business role и называем «стейкхолдер» -- обеспечивая рекурсивное применение паттернов моделирования на многих уровнях системы. 34
  35. 35. Оргзвено и оргинтерфейс • В архимейте Actor взят из DEMO – это единица принятия ответственности. • В SysArchi это модуль как единица организации: оргзвено • business в ISO29148 рекомендуется переводить как «организационный» • В ISO 15288 организация определяется как люди, оборудование и сооружения, с известным распределением полномочий (т.е. люди там Actors из DEMO) • Нас интересуют совещания, рабочие команды проекта (не только фирмы), отдельные люди. Общее название: оргзвено, где «орг» означает отнесение к уровню координационной работы. • Это модули организационной структуры («из чего сделано», а не «как работает»). • Оргзвенья собираются в целую организацию через оргинтерфейсы. • Склоняемся к решению, что интерфейсы – это «междумордия», а не «интерфейсные модули». То есть они не включаются в состав оргзвеньев, они «между». • Сервисы/практики/capabilities пока не рассматриваем как главные соединительные элементы уровней архитектуры 35
  36. 36. Подход Яна Диеца (DEMO) 36 http://ailev.livejournal.com/644440.html
  37. 37. Оборудование и его функционал • Оборудование/инструменты показываются как equipment • Оборудование это часть оргзвена («мои вещи – часть моего тела»), показываем через отношение ассоциации с именем «имеет» -- «отдел разработки имеет 3D принтер», «департамент IT имеет серверную ферму» • Функционал оборудования – это компоненты/функциональные элементы. 37
  38. 38. Физические объекты и информационные объекты • Пассивные физические объекты моделируем элементом material, но называем «физический объект» для общности. • Информационные объекты Архимейта уважаем, это концептуальные объекты – частные system definitions. System descriptions моделируем как данные и далее artifacts. От использования representations воздерживаемся. • Показ активного и пассивного объекта (оборудования в использующей системе – физического объекта как целевой системы) используем ассоциацию с именем «то же, что». 38
  39. 39. Целеполагание • Интерес/concern – driver (тема) • Дисциплина (в том числе определяет viewpoint) – principle • Оценка интереса – assessment • Цель (goal) – указание на действие, глагол повелительного наклонения, направлена на изменение оценки интереса • Требование – Requirement (поскольку многоуровневость, то воздерживаемся от «ограничения», это требование к элементам более низкого системного уровня. 39
  40. 40. Практика • Для моделирования практик используем business function, для функционала программ и аппаратуры используем соответствующие functions. • Оргсервис не показываем, но показываем выполнение практики на оргинтерфейсе, если нужно указать SLA, то указываем элементом «требование». • Оргвозвожность/capability не моделируем отдельно. По сути появление оргвозможности это указание того, что а) практика назначена на оргзвено, б) воплощена, в) валидирована, г) налажено оперативное управление (логистика ресурсов, нужных для выполнения назначаемых на неё работ). 40
  41. 41. Онтология – дисциплина – технология (нет понятий системного уровня!) 41
  42. 42. Спектр формальности мышления 42 Цепочка «Фундаментальное образование»: https://ailev.livejournal.com/1390318.html Надо работать и со схемами, и со схемоидами! Архимейт/SysArchi Архитектурное эссе ISO 15926
  43. 43. Архимейт намеренно невнятен • Это утка или заяц? • Тем не менее, это не обувная фабрика, и не космический корабль! • Тип важен, но в Архимейте он не дискретен! • Разные типы ведут себя по-разному в отношениях! 43
  44. 44. Развитие и совершенствование инженерии (в том числе инженерии предприятия) 44 Р Е З У Л Ь Т А Т Ы ВРЕМЯ III поколение Моделе-ориентированная (model- based) инженерия: формальные языки (вычисляемый «код») II поколение Современная («классическая») инженерия: диаграммы и чертежи («псевдокод») I поколение «Алхинженерия»: неформальные тексты и эскизы 199018601400 IV поколение Искусственный интеллект: гибридные вычисления (+автоматизация неформального) 2020
  45. 45. Визуальное мышление Утопия «графического языка»: • Только для маленьких моделей • Сложность в управлении конфигурацией (сравнение, поиски, изменения, вставки, утеря понимания при переразводке диаграмм) • Утеря контекста при листании (текст более компактен в передаче информации на единицу площади) • … 45 https://www.litres.ru/anatoliy-levenchuk/vizualnoe-myshlenie-doklad-o-tom-pochemu-im-nelzya-obol/
  46. 46. Что делаем: SysMoLan SysMoLan : System Modeling Language https://ailev.livejournal.com/1443879.html «Иметь возможность нарисовать на одной схеме системы то, что раньше рисовалось только на двух разных, чтобы явно указать связи и обсудить». • Ничего нового: такая была дизайн-цель ArchiMate (прожекторный язык, факт-ориентированный). • Отличия от SysML: в самом SysML множество диаграмм изначально, нет языка запросов и мэппинга, нет факт-ориентированности, нет upper ontology и т.д. • Одновременно product и project модели 46
  47. 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. 48 Спасибо за внимание Анатолий Левенчук Школа системного менеджмента, научный руководитель Русское отделение INCOSE, директор по исследованиям http://ailev.ru ailev@asmp.msk.su 11 сентября 2018

×