Вложенные порты SysML 1.3

В SysML 1.3 (текущая официальная версия, выпущеная в 2012 году) впервые появилась нотация вложенных портов (nested ports), которая позволяет декомпозировать порты до любого уровня вложенности. С помощью портов моделируются точки взаимодействия блоков. Взаимодействие блоков может быть логическое, а может быть и физическое.

Декомпозиция портов позволяет отразить уровни абстракции при определении интерфейсов логического взаимодействия:
- группировать порты по функциональному назначению (например, порты все логические выходы элекроснабжения из помещения)
- группировать порты по объекту взаимодействия (например, все порты взаимодействия между туловищем и рукой человека, см рис. по ссылке)

Декомпозиция портов позволяет отразить физическую структуру при определении портов физического взаимодействия
- например порт RS-485 может быть декомпозирован на вложенные порты соответствующие пинам подключения этого интерфейса

Хоть созданная модель и содержит информации о всех уровнях декомпозиции порта,  на диаграммах мы можем отображать порты и связи между ними на нужном для нас уровне абстракции. На диаграмме внутренней структуры дома представлены порты электроснабжения помещений дома из коридора, в котором расположен центральный распределительный щиток. Электроснабжение из коридора в каждое из помещений моделируется с помощью отдельного порта. Все порты электроснабжения помещений из коридора сгрупированы в порт пЭлектроснабжение, определенный в блоке определения коридора.

На другой диаграмме внутренней структуры дома могут быть показана более детальное информация о портах электроснабжения отдельных помещений. На диаграмме ниже для портов пЭлКухни и пЭлектроснабжение отображены вложенные порты электроснабжения кухонной техники. 

Теперь давайте посмотрим, как спецификации портов выглядят в браузере модели. Типы портов в SysML определяются с помощью отдельных блоков определения интерфейсов. Данные блоки имеют стереотип <<InterfaceBlock>>.  Порт определяется как вложенное свойство блока. Порт может быть типизирован с помощью интерфейсных блоков.

Блок КоридорЛог определяет в модели логическую модель коридора. В нем определен порт пЭлектроснабжение, имеющий тип иЭлКоридор. 

Тип иЭлКоридор определен в виде интерфейсного блока и содержит порты электроснабжения помещений. Каждый из этих портов может быть типизирован с помощью интерфейсных блоков. Так порт электроснабжения кухни пЭлКухни имеет тип иЭлКухня.

Тип иЭлКухня определен с виде интерфейсного блока, внутри которого определены порты электроснабжения кухонных приборов и других потребителей электричества на кухне.

При желании мы может отобразить все блоки определения интерфейсов портов на отдельной диаграмме определения блоков SysML. 

Выше были представлены скриншоты "представления спецификации" браузера модели, в котором отображается только один уровень декомпозиции портов. В "структурном представлении" браузера модели в MagicDraw вся информация о вложенных портах собирается в едином представлении, и для каждого порта отображаются порты всех уровней вложенности.

Введение нотации вложенных портов в SysML 1.3 (это текущая официальная версия, выпущенная в 2012 году) очень сильно приблизило данный язык для использования в задачах моделирования систем. И это та функциональность, которая обязательно должна быть поддержана в инструменте моделирования.

Уровни взаимодействия между элементами системы

Для моделирования взаимодействия между элементами системы необходимо четко разделять уровни данного взаимодействия и уровни ответственности участников процесса. При разработке системы присутствуют как минимум два уровня взаимодействия: верхний логический или прикладной и нижний физический. Системный инженер создает спецификацию прикладного/логического взаимодействия, которая является заданием на реализацию физического взаимодействия. На физическом уровне возможны различные реализации одного и того же логического взаимодействия.  Выбор конкретного способа - это проектное решение, которое принимает инженер в конкретной инженерной области исходя из спецификации логического взаимодействия и кучи других требований и факторов.

Между верхним прикладным уровнем и физическим уровнем могут находиться множество промежуточных уровней взаимодействия. Пример нескольких уровней взаимодействия - стек сетевых (программных) протоколов различного уровня. У каждого промежуточного уровня реализации взаимодействия свои задачи.

Логическим взаимодействием называют передачу сигналов, потоков вещества, сил. Ими обмениваются взаимодействующие элементы системы.

Логическое взаимодействие между элементами системы реализуется за счет физического взаимодействия, а именно путем подключения элементов системы с помощью электрических кабелей, Ethernet-кабелей, труб, воздуховодов. Это самые понятные способы физического взаимодействия, которые обеспечивают передачу сигналов и вещества.

Но есть и механические типы физического взаимодействия, связанные с передачей сил или размещения в пространстве. Пример таких взаимодействий - соединение двух элементов системы с помощью гвоздей. Картина, повешенная на стену взаимодействует со стеной несколькими способами: 1. точками, крепления, которые удерживают картину на стене, прикладывая к ней соответствующие силы; 2. местом, необходимым для размещения картины на стене. Если этого места нет, то картина просто "не состыкуется" со стеной.

Приведу пример логического и физического взаимодействия между Колодцем и Домом. Логическое взаимодействие - это передача воды от колодца в дом. На уровне описания логического взаимодействия важен именно поток воды, а не способ которым она доставляется в дом. Способы реализации логического взаимодействия могут быть разные: например человек может носить воду ведрами, можно подавать воду по шлангу с помощью насоса, а можно как в сказке "По щучьему велению, по-моему хотению, идите ведра сами домой".

Выбор способа реализации логического взаимодействия - это одно из проектных решений, которые делает проектировщик, сопоставляя все плюсы и минусы каждой из возможных реализаций. Например, доставка воды в дом с помощью насоса по шлангу будет гораздо комфортнее, чем носить воду ведрами. Но данный способ более дорогой в реализации, зависит от электричества, требует альтернативных способов доставки воды в дом.

Приведу еще один пример логического взаимодействия и нескольких способов его реализации на физическом уровне. Допустим, что стоит задача электроснабжения потребителей на кухне от распределительного щитка, расположенного в коридоре. Логический уровень взаимодействия - это подача электроснабжения ко всем потребителям на кухне. Возможный способ физической реализации - это протяжка проводов.  При этом возможны варианты - к каждому прибору/розетке/лампочке тянется отдельный провод. Другой вариант - тянется один провод на всю кухню, который придет к распределительному шитку на кухне и уже от него пойдут провода по кухне. Возможны и промежуточные варианты, когда на кухню идут несколько проводов, например отдельные провода на освещение, на "мощные приборы" и т.д., но на каждом из проводов могут сидеть несколько приборов.  Провода из коридора на кухню будут протянуты внутри стен, перекрытия, в полу. Поэтому необходимо заранее понять сколько и каких проводов необходимо протянуть на кухню. Выбора конкретного способа - это проектное решение. Логический уровень предоставляет исходную информацию для принятия этого решения.

Системный инженер отвечает за уровень логического взаимодействия между элементами системы. Логические взаимодействия специфицируются на уровне системной модели.  Эти спецификации являются заданиями для инженеров в различных инженерных областях. На основе этих спецификаций электрики думают сколько проложить проводов и какого сечений, сантехники выбирают схему параметры системы водоснабжения и канализации, программисты думаю к примеру как обеспечить надежность доставки сообщений, конструктора думают о том как обеспечить механические сочленения, а дизайнеры располагают предметы с учетом требуемого для них места в пространстве.

Интеграция человека из составных частей

Поставим себе целью опубликовать документ на основе модели, содержащий детальную спецификацию всех частей, отделов и компонентов тела человека. Для публикации такого документа на основе модели будем действовать в соответствии с шаблоном "Сборка документа из частей на основе моделей". В соответствии с этим шаблоном нам необходимо собрать из ранее определенных элементов единую иерархию нашего документа.

Можно и по другому взглянуть на данную задачу, а именно как процесс интеграции в соответствии с шаблоном "Декомпозиция и интеграция элемента системы". До этого я описывал рекурсивный процесс проектирования - декомпозицию на части. После того как данный процесс достигнет нижнего уровня, эти части необходимо интегрировать друг с другом снизу вверх в соответствии с определенной в проекте архитектурой, подставив реализованные части в вышестоящую структуру. На основе интегрированного представления можно будет опубликовать необходимый документ.

Из-за отделения спецификаций от реализаций в процессе проектирования
все физические иерархии у нас в модели содержат только один уровень декомпозиции. На нижнем уровне всех физических декомпозиций находятся спецификации составных частей. Вот так это выглядит в "Структурном представлении" браузера модели на примере физической декомпозиции человека на части тела.

То же самое имеем для частей тела человека. Например, для руки видим следующее в "Структурном представлении" браузера модели.

Для интеграции человека нам необходимо вместо частей-спецификаций на всех уровнях подставить реализации этих частей. Нам нужно сделать это на всех уровнях физической декомпозиции. Будем делать это снизу вверх, постепенно интегрируя реализованные части в составляющие их элементы. 

Начинаем с руки, интегрируя ее из реализаций плеча, предплечья и кисти.
Для этого создаем новый блок "Рука - Реализация". Наследуем этот блок от блока "Рука - Отделы руки". Последний определяет архитектуру руки, основываясь на которую мы будет производить интеграцию. Новый блок наследует все части и связи. Для интеграции мы переопределяем типы частей со спецификаций на реализации.

Далее интегрируем части тела человека, аналогичным образом подставляя вместо спецификаций частей тела их реализации. Создаем новый блок для интеграции человека с названием "Человек - Реализация". Наследуем его от блока "Человек - Части тела". Этот блок определяет физическую архитектуру человека и является блоком-спецификаций архитектуры. От него новый блок наследует все части тела: голова, левая рука, .... и определенные ранее связи между частями. На диаграмме ниже показана частичная интеграция. Переопределены типы частей только для левой и правой руки. 

Теперь давайте посмотрим как выглядит блок "Человек-Реализация", в котором мы интегрировали части тела и отделы руки, в "Структурном представлении" браузера модели MagicDraw. В этом представлении отображаются все уровни иерархии частей блоков. В браузере видно, что типы для левой и правой руки были переопределены на "Рука - Реализация". Так как блок "Рука - Реализация" содержит вложенные части, то в браузере для левой и правой руки человека отображаются их составные части: плечо, скелет, кровоснабжение. Также видно что на следующем уровне детализации для плеча, предплечья, кисти также переопределены типы на соответствующие реализации. Для этих частей в браузере отображаются подсистемы и компоненты нижнего уровня, например, мышцы: бицепс, трицепс, плечевая мышца.

На основе блока модели "Человек - Реализация" (который выступает в роли индекса для документа) мы можем опубликовать документ, содержащий детальную спецификацию всех частей и отделов тела человека, их интерфейсов.

Отделение спецификаций от реализаций в процессе декомпозиции и размещения систем

Хочу дополнительно проиллюстрировать рабочие продукты процесса декомпозиции и размещения логических систем по физическим. Необходимо подчеркнуть момент создания двух типов блоков в этом процессе: блоков спецификации и блоков реализации. Ранее этот процессы был описан на высоком уровне, теперь приведу некоторые детали. 

Раннее в шаблоне Декомпозиция элемента системы я проиллюстрировал процесс декомпозиции и интеграции элемента системы из частей. В процессе логической и физической декомпозиции и размещения создаются несколько реализаций для каждого физического элемента системы. Использование двух типов блоков позволяет организовать процесс интеграции элементов из частей, подставляя в модели в качестве составных частей любые их реализации. 

Когда я декомпозирую физический элемент любого уровня на физические составляющие в названии блоков частей я использую блок с суффиксом "-Спецификация". В этом блоке определяются все внешние интерфейсы части, которые состоят из интерфейсов с другими частями и внешними интерфейсами декомпозируемого элемента. 

Для иллюстрации декомпозируем тело человека на части. Это удобно делать на диаграмме определения блоков SysML. 

Для блока "Человек - Части тела" определяем связи между частями тела. 

Далее переходим на уровень отдельных частей тела. Рассмотрим процесс на примере руки. Применяем для руки процесс декомпозиции и размещения, получаем несколько "реализаций" руки человека. Все эти реализации наследуются от блока "Рука-Спецификация", в котором определены все внешние интерфейсы руки. Каждый блок "реализации" руки реализует эти интерфейсы. Благодаря этому каждая из реализаций руки может быть подставлена в блок "Человек - Части тела" в качестве составной части. Это мы будем делать в процессе интеграции человека из реализованных частей. При этом диаграмма внутренней структуры человека, определяющая связи между частями, остается верной при подстановке любых реализаций частей.

Для перехода на следующий уровень физической декомпозиции декомпозируем руку на отделы. И опять для составных частей использую суффикс "Спецификация", подчеркивая этим, что будет несколько "реализаций" отделов руки.  

Далее действуем аналогично, "реализуя" спецификации отделов руки.  

Перевод книги по применению UML/SysML для разработки встраиваемых систем

В 2011 году под моей редакцией был закончен перевод книги "Real-Time UML Workshop for Embedded Systems" by Powel Douglass. Название данной книги на русском языке "Лабораторный практикум по UML реального времени для разработки встраиваемых систем". В этой книге на примере двух систем и практических упражнений демонстрируется метод применения языка моделирования SysML/UML для разработки систем и ПО на основе моделей.

Автор книги Powel Douglass - методолог IBM Rational по разработке технических систем и встраиваемого ПО, ранее методолог iLogix и Telelogic. У Дугласса более 6 книг, посвященным применению UML для разработки систем и ПО (см. список книг по моделированию по ссылке). А вот по следующей ссылке можно полистать книгу на английском языке.

Я выступал в качестве научного редактора, переводчика моделей и рисунков для данной книги. В период с 2007 по 20014 год я занимался продвижением решения для разработки систем и ПО на основе моделей с использованием IBM Rational Rhapsody (изначально принадлежавшей iLogic, затем Telelogic и сейчас IBM). Эту книгу мы решили перевести для методологической поддержки этой деятельности. Перевод книги выполняла Наталья Желнова, а к первым двум главам прикладывал свою руку и Иванов Денис (сайт www.uml3.ru). Книга была переведена при финансовой поддержке компании SWD Software (www.swd.ru).

Данную книгу мы выбрали для перевода из-за ее максимальной практической направленности. В ней не просто описывается язык моделирования или метод его применения, а на примере двух реальных систем язык и метод демонстрируется на практике. Демонстрация метода в книге ведется на примере разработки систем двух уровней сложности:
- Системы управления интеллектульным дорожным перекрестком (простая система)
- Системы беспилотного летательного аппарата (сложная система)

Книга выполнена в виде лабораторного практикума по моделированию систем и ПО. Первые две главы посвящены краткому рассмотрению языка UML и метода его применения Harmony. В приложениях А и B приводятся спецификация требований к рассматриваемым в книге системам. В главах 1-7 даются задания по моделированию, а в главах 8-12 рассматриваются примеры решения этих заданий. В главах 3-4 содержатся задания по разработке систем (анализ и проектирование). Главы 5-7 содержат задания по разработке ПО. В главах 8-9 содержатся задания па разработке систем. А в главах 10-12 содержатся примеры решений для заданий по разработке ПО.

Оглавление книги:

Глава 1. Введение
Глава 2. Процесс Harmony
Глава 3. Спецификация требований
Глава 4. Системная архитектура
Глава 5. Объектный анализ
Глава 6. Архитектурное проектирование
Глава 7. Техническое и детальное проектирование
Глава 8. Спецификация требований: Решения
Глава 9. Системная архитектура: Решения
Глава 10. Объектный анализ: Решения
Глава 11. Архитектурное проектирование: Решения
Глава 12. Техническое и детальное проектирование: Решения
Приложение А. Система управления дорожным перекрестком Роадраннер
Приложение B. Система беспилотного летательного аппарата Койот

Работы по переводу и редактированию книги были выполнены еще в 2011 году в процессе моей работы в SWD Software. Из-за моего ухода из SWD публикация книги зависла в воздухе. В этом состоянии книга сейчас и существует. На данный момент выполнены две (научные) редакции книги. Еще требуется выполнить литературную редакцию и коррекцию книги. Тем не менее, даже в текущем состоянии книгу можно без проблем читать. Когда я сам первый раз прочитал книгу на английском она была для меня очень полезна. До сих пор я получал очень положительные отзывы и о ее переводе на русский язык.

Вы можете скачать архив с книгой либо просмотреть книгу онлайн.

Данная книга позволит концептуально понять как выполняются все основные задачи процесса разработки систем и ПО на основе моделей. Но для реального успешного использования данного подхода понадобится самостоятельно создать не одну модель в процессе практической деятельности. Своим опытом по созданию таких моделей и другой информацией по теме моделирования систем я и делюсь в этом блоге.

Размещение логических систем по физическим частям человека

Человека, как и любую другую сложную систему, можно одновременно декомпозировать на логические системы и физические части. С одной стороны человек состоит из логических систем: кровообращения, нервной, пищеварительной и т.д. С другой стороны человек состоит из физических частей тела: туловища, головы, шеи, рук и ног и т.д. В процессе системного проектирования логические системы декомпозируются на подсистемы и производится их размещение по физическим составляющим. Ниже процесс размещения с использованием языка моделирования SysML описан на примере модели человека.

Верхние уровни декомпозиции человека на системы и на физические части изображены да двух диаграммах определения блоков SysML ниже.

Верхние уровни логической декомпозиции человека (на системы)

Верхние уровни физической декомпозиции человека

В процессе проектирования производится постепенное объединение логического и физического представления путем размещения логических подсистем по физическим составляющим. Размещение подсистем логического представления производится на каждом уровне декомпозиции физического представления. 

Возьмем верхний уровень декомпозиции человека на части (туловище, голова, ...) и произведем размещения систем по этим физическим частям. Для примера возьмем систему кровообращения человека. Для размещения данная система декомпозируется на подсистемы: подсистема кровообращения туловища, подсистема кровообращения головы, подсистема кровообращения верхних конечностей и т.д. Аналогичным образом поступаем со всеми системами человека.

После декомпозиции всех систем человека на подсистемы, соответствующие частям тела, можно приступать собственно к размещению систем по физическим частям. Не все системы будут представлены во всех частях тела. Например, для руки мы получаем следующий состав размещенных в ней подсистем.

На этом этапе мы спустились в процессе размещения логических систем по физическим частям человека  на один уровень ниже . Для каждой части тела верхнего уровня (туловище, рука, голова, нога, шея) мы имеем две декомпозиции. Одна логическая - на подсистемы и вторая физическая - на отделы части тела человека. Например, физическая декомпозиция для руки будет содержать отделы: плечевой, предплечье и кисть. 

На следующих шагах мы применяем описанную выше процедуру к каждой части тела человека (первого уровня). Мы декомпозируем системы еще один уровень и производим их размещение по отделам частей человека (второго уровня). Рекурсивно применяя данную процедуру на последующих уровнях физической декомпозиций мы доходим в процессе размещения систем до нижнего уровня физической декомпозиции.  

Вопрос какие физические части находятся в самом внизу физической декомпозиции? Органы? Да, органы человека - это компоненты физической декомпозиции человека. Но каждый орган может быть и дальше разделен на части. Пример такой физической декомпозиции - декомпозиция сердца на камеры. Отделы органов могут быть разделены и дальше на детали органов. И для каждого из этих уровней физической декомпозиции мы продолжаем размещение систем.

Нижний уровень декомпозиции в системной модели выбираем мы сами, в зависимости от решаемой нами задачи (для которой мы строим системную модель). На нижнем уровне физической декомпозиции могут быть органы человека, а могут быть и отделы органов или даже их отдельные части.  В моей системной модели человека на нижнем уровне будут отделы органов человека (например, камеры сердца).

Механические сочленения в плечевом суставе на SysML

С помощью портов SysML могут быть смоделированы не потоки информации и вещества, но и механические сочленения. Для примера ниже показана диаграмма внутренней структуры для плечевого сустава. На диаграмме отображены все кости и мышцы плечевого сустава и механические сочленения между ними. 

По следующей ссылке приведено очень хорошее "традиционное" трехмерное и текстовое описание устройства плечевого сустава

http://www.sportmedicine.ru/shoulder_anatom.php

У этого описания есть и преимущества и недостатки. Из преимуществ - легче понять пространственное расположение мышц. Из недостатков - не так легко понять из 3D изображений точки прикрепления мышц к костям. Приходится описывать точки прикрепления в текстовом виде. Эта информация получается размазоной по тексту.

Ниже структура сустава, отображенная на диаграмме внутренней структуры SysML. Синим на диаграмме отмечены кости, а желтым мышцы. Для костей с помощью портов показаны точки прикрепления мышц. Эти точки показаны на рисунке выше. На этой диаграмме сразу виден состав мышц, количество точек подсоединения и сами точки подсоединения к костям. 

Структура кровообращения туловища человека на SysML

А вот и первый набросок на SysML структуры системы кровообращения туловища человека. И несколько слов о том, что я осознал для себя нового при создании этой модели.

Ниже изображена диаграмма внутренней структуры SysML для туловища человека. На диаграмме отображены связи между органами для системы кровообращения. В центре находится сердце. Красным отмечены системы артерий. Синим отмечены системы вен. По краям диаграммы 5 портов для связи подсистемы кровообращения туловища с подсистемами кровообращения конечностей и головы. 

Как и любая диаграмма SysML, эта диаграмма отображает не все органы туловища, а только существенные. Подключение других органов туловища человека к системе кровообращение будет показано других диаграммах.

Для меня создание этой диаграммы уже принесло плоды в изучении системы кровообращения человека. Вот что я осознал:
- кровь к печени подходит не из аорты, а из желудка, селезенки и кишечника, печень выступает здесь выступает в качестве фильтра крови от вредных веществ, поступивших с пищей
- в сердце кровь возвращается не через два входа (по одному для большого и малого круга кровообращения), а аж через 6 входов
   - 2 входа из большого круга кровообращения: из большого круга кровообращения кровь возвращается черед две вены: верхняя полая и нижняя полая
   - 4 входа из малого круга кровообращения: от каждого легкого в сердце приходит по две вены, итого от 2 легких идут 4 вены

Шаблон "Сборка документов из частей на основе моделей"

Шаблон "Сборка документов из частей на основе моделей" иллюстрирует возможность создания документов из частей, описанную в предыдущем посте, но с помощью модели. Результирующий документ получается путем автоматической публикации документа на основе модели.

Давайте посмотрим на процедуру создания модели и убедимся в ее схожести с процедурой сборки документа из частей - файлов. Для каждого элемента этой процедуры (файла документа, каталога на диске) есть аналог в процедуре с использованием модели. Аналогом файлов в модели SysML будут выступать блоки. Аналогом каталогов на диске в модели SysML будут выступать пакеты. Пакеты физически содержат в себе блоки, также как каталоги на диске содержат в себе файлы. Блоки могут логически включать другие блоки (аналог включения в файл других файлов с помощью ссылок). Включаемые блоки могут физически находиться в любом пакете модели.

Каждый блок может включать в себя другие блоки. Другие блоки включают в себя еще какие-то блоки и так далее. При этом, любой блок может быть включен в произвольное количество блоков. В модели SysML включения между блоками можно визуально отобразить на диаграмме определения блоков. Стрелками с заштрихованным ромбом отображаются отношения включения.

В модели SysML блоки раскладываются по папкам произвольным образом, также как раскладывались по каталогам на диске файлы в предыдущем посте . Например, в браузере модели мы можем создать пакеты с названиями "Блоки первого уровня", "Блоки второго уровня", "Блоки третьего уровня" и разложить по ним созданные блоки.

Структура пакетов и размещенных в них блоков может быть отображена на диаграмме пакетов SysML. На диаграмме ниже отображены пакеты модели и для примера отображены два блока, остальные блоки просто не показаны на диаграмме. Для отображения блоков и связей включения достаточно перетащить блок из браузера модели на диаграмму. 

Для каждого блока в браузере модели мы можем увидеть информацию о логически включенных в него блоках (см. рис. ниже). В этом представлении для каждого блока мы видим только один уровень включения.

В браузере модели MagicDraw есть чрезвычайно-полезное "Представление структуры". Оно отображает все уровни включения для блока, собирая для отображения информацию из всех уровней включенных блоков. Ниже показан такое представления, в котором для Блока А и Блока B отображена вся иерархия включения.

В MagicDraw я впервые увидел такое представление в браузере модели. Ни в Eclipse Papyrus, ни в Rational Rhapsody такого сборного представления модели нет. Для получения подобной информации в этих инструментах необходимо генерировать отчет по модели. В MagicDraw позволяет просмотреть всю информацию о структуре (все уровни) непосредственно в интерфейсе. Это чрезвычайно удобно в определенные моменты при создании модели. 

На основе любого элемента модели может быть опубликован документ, содержащий информацию о всех вложенных в него и рекурсивно ниже блоках.  Блоки могут содержать текстовые описания, которые тоже могут быть включены в опубликованный документ. Публикуя документы для различных элементов модели (например, Блока А или Блок B) мы будем получать несколько отличающиеся друг от друга документы, созданные на основе одного источника. Процесс создания таких документов в модели очень напоминает создание сборного документа в текстовом редакторе, но помимо этого еще позволяет визуально отобразить отношения между "частями документа" на диаграммах. 

Сборка документов из кусочков на базе одного источника

Прежде чем активно заняться методом разработки систем на основе моделей я реализовал некоторые преимущества данного подхода путем использования обычных текстовых документов. Для этого мне понадобилось реализовать возможность сборки документов из кусочков.

Сборка документов из кусочков позволяет собирать несколько отличающихся документов, используя в них одинаковые разделы. Приведу два примера, когда сборка документа из кусочков может существенно облегчить работу. Если мы создаем линейку продуктов, в которой продукты создаются на одной платформе и отличаются друг от друга некоторым набором возможностей. Тогда документы с описанием требований, архитектуры, руководств пользователя и др. будут несколько отличаться друг от друга, но также содержать много общих разделов. Даже если мы не создаем линейку продуктов, а рассматриваем различные варианты реализации частей системы, нам может понадобиться собрать несколько документов с описанием архитектуры, в которых включены различные описания спецификации какой-нибудь части или нескольких частей.

Возьмем традиционный монолитный документ.  При открытии файла документа в редакторе можно просмотреть иерархическую структуру частей, глав, разделов, ... параграфов документа.  При просмотре в документе эти элементы образуют однородную физическую иерархию. Недостаток такой физической иерархии состоит в том, что мы не можем воспользоваться элементом этого документа при создании другого документа. Единственный способ, который у нас есть, это полностью скопировать содержимое раздела из первого документа во второй. Если вдруг окажется, что необходимо внести изменение в скопированный раздел, его придется вносить в обоих документах. Если таких документов не два, а больше, их поддержание в согласованном состоянии становится большой головной болью.

Чтобы реализовать возможность сборки документов из кусочков необходимо каждый раздел нижнего уровня помещать в отдельном файле. После этого мы сможем повторно использовать их в нескольких документах. Собирать - это значит включать в некоторый индексный файл собираемого документа.

Можно даже организовать несколько уровней сборки. Допустим, на нижнем уровне мы имеем файлы, содержащие текст разделов нижнего уровня. На втором уровне мы создаем по одному файлу для каждого раздела следующего уровня. И собираем в этом файле (с помощью включения в индекс) разделы нижнего уровня, просто включая в индекс соответствующие файлы. Двигаясь таким образом вверх мы постепенно соберем документ из отдельных файлов. Большинство файлов (кроме тех, что содержат разделы нижнего уровня) будут содержать просто индексы включения других файлов.

- файл 0
   - включение файла 1
   - включение файла 5
- файл 1
   - включение файла 2
   - включение файла 3
   - включение файла 4
- файл 5
   - включение файла 6
   - включение файла 7
   - включение файла 8

Для того чтобы структурировать полученные файлы на диске мы создадим каталоги, в которые поместим полученные файлы. Структура каталогов на диске может отражать иерархию документа, а может и отличаться от нее. Например, на диске у нас может получиться вот такая структура, не совпадающая с логической структурой документа.

- каталог на диске 1
    - файл 0
    - файл 1
    - файл 5
- каталог на диске 1
   - файл 2
   - файл 3
   - файл 4

   - файл 6

   - файл 7
   - файл 8

Понятно, что данная процедура должна быть поддержана инструментом. Инструмент должен позволять для любого индексного файла показать содержимое всех файлов, включенных в него на следующем и т.д. уровнях. Инструмент должен позволять редактировать документ в собранном представлении, в фоновом режиме изменяя содержимое соответствующих файлов. Инструмент должен позволять опубликовать обычный документ, автоматически включив в него все вложенные разделы.

Для реализации подобного подхода могут использоваться разные технологии, например HTML, XML DocBook или DITA XML. В качестве редакторов могут использоваться HTML, XML редакторы или Web CMS. Пример таких редакторов, которые я использовал XML Spy и XMetal - для редактирования XML DocBook и DITA XML, или Daisy CMS для создания документов в формате Web CMS.

Изложение биологии человека на SysML

Вторая системная модель, которую я хочу создать на SysML в качестве примера - это модель организма человека (см. первую). Это прекрасный пример систем, в которой компоненты (органы  человека) взаимосвязаны друг с другом и выполняют возложенные на них функции, а также объединены в системы. Одновременно, биология человека - это интересная для меня тема, в которой хочется поглубже разобраться. А без системной модели как обычно разобраться не очень просто. Благо, что жена у меня биолог и может мне помочь в ее создании.

Уже появились соображения, какие возможности системная модель добавит к традиционным анатомическим картинкам. Последние отображают физическую архитектуру, за которой скрыта логика работы организма. Например, в организме человека существуют две "транспортных" системы: кровеносная и лимфатическая. Артерии/вены и лимфатические сосуды - это каналы физического уровня. На из анатомических картинок совершенно не понятно какие типы веществ и клеток движутся в крови и лимфе.

Моделирование организма нужно начинать с логического (прикладного) уровня.  Также как Ethernter провод является транспортом для разнообразной прикладной информации, так и кровеносная и лимфатические системы являются транспортом очень различных веществ и клеток, имеющих разных адресатов и различное назначение. Логическая архитектура должна отобразить потоки разнообразных веществ между органами организма. Эти потоки не отображаются на схемах физической архитектуры (анатомических рисунках).  Моделируя данный обмен на логическом уровне (создав логическую архитектуру человека) можно гораздо лучше визуально отобразить логику его функционирования.

Жена выдала мне книгу для изучения "Биология человека в таблицах, рисунках и схемах". Отличная книжка, полностью соответствует моим текущим потребностям. Приступаю к изучению. Книга онлайн

Шаблон Декомпозиция и интеграция элемента системы

Первый шаблон разработки систем определяет как декомпозировать элемент системы на части, как интегрировать части в целое с применением модели. Данный шаблон создания системных моделей позволяет правильно организовать элементы структурного представления в модели.

Возможности шаблона "Декомпозиция элемента системы":

- рекурсивно декомпозировать систему на части

- разделять внешние интерфейсы элементов системы и их реализации

- гарантировать соответствие реализации специфицированным интерфейсам элемента системы

- определять несколько типов архитектур элемента системы (например функциональной и логической)

- интегрировать элементы системы из реализованных частей, строго в соответствии с определенной архитектурой

На диаграмме SysML определения блоков показаны элементы модели данного шаблона. Ниже приведено описание каждого элемента шаблона, изображенного на диаграмме.

Блок "Элемент Спецификация" - специфицирует элемент системы как черный ящик. Этот элемент определяет внешние порты элемента.

Блок "Архитектура элемента" - наследуется от блока "Элемент Спецификация". Он наследует определения внешних портов элемента и должен им соответствовать. Далее блок декомпозируется на части "Часть 1...3 Спецификация".

Блоки "Часть 1...3 Спецификация" специфицируют части элемента. Эти части - элементы следующего уровня системы и являются аналогами элемента "Элемент Спецификация" для следующего уровня детализации.

Блоки "Часть 1..3 Реализация" реализуют части элемента. Если реализация частей являются конечными элементами декомпозиции, то они наследуются от блоков "Часть 1...3 Спецификация". Если же эти части декомпозируются далее, то "Часть 1...3 Реализация" наследуется от "Архитектура части 1...3". И в этом случает реализация части является для нее полным аналогом блока "Интеграция элемента" для элемента системы.

Блок "Интеграция элемента" - наследуются от блока "Архитектура элемента". Используется для интеграции элемента системы из частей в соответствии с архитектурой. Для этого он просто переопределяет (redefines) свойства элемента "Архитектура элемента": часть 1..часть 3, подставляя вместо спецификаций элементов их реализации. 

Диаграмма внутренней структуры блока "Архитектура элемента" отображает декомпозицию элемента на части, порты частей и связи между частями. 

Данная внутренняя структура наследуется блоком "Интеграция элемента". Для интеграции элемента не нужно заново определять связи между частями. Достаточно переопределить эти части, а связи будут унаследованы из архитектуры.

Элементы модели организуются по папкам модели определенным образом. Правильная структура папок позволяет рекурсивно декомпозировать систему до любого уровня вложенности. Например, в предлагаемой организации папка "Часть 1" имеет такую же структуру как папа "Элемент".

Данный шаблон не описывает полностью структуру папок модели. В полной модели для каждого элемента системы помимо структурного представления определяются представления вариантов использования, требований, поведения, а также параметрические представления. Элементы модели этих представлений раскладываются по папкам модели, наряду с элементами структурного представления. 

Ресурсы по моделированию 1

Начну добавлять ссылки на полезные ресурсы по теме блога. Так как таких постов будет в дальнейшем много, буду добавлять к ним ярлык resources по которому можно будет сделать выборку всех постов по ресурсам.

Страница стандарта SysML на сайте OMG

http://www.omgsysml.org/

Книги по SysML (их больше, это две книги, которые я читал)

A Practical Guide to SysML

Systems Engineering with SysML/UML

SysML Tutorials

OMG SysML Tutorial

MBSE with SysML Tutorial (Johns Hopkins Applied Physics Lab)

Блог NoMagic по моделированию

http://blog.nomagic.com/

Блог Tim Weilkiens (автора книги SE with SysML/UML)
http://model-based-systems-engineering.com/

MBSE Challenge Team - инициатива по применению SysML в нескольких больших проектах, с онлайн демонстрацией моделей, результатов и рекомендаций по моделированию
http://mbse.gfse.de/index.html

Контекст применения метода разработки на основе моделей

Разработка систем на основе моделей - это метод решения стандартных задач системной инженерии.  Контекст для применения метода - это технические процессы системной инженерии.

В процессе разработки система рекурсивно декомпозируется на части, части разрабатываются и система интегрируется из частей. Уровней декомпозиции может быть произвольно много. Элементы систем: нижнего уровня обычно имеют название комплекс, система, подсистем, компонент/изделие, деталь. Все что выше можно называть система систем.

Разработка элемента системы на каждом уровне декомпозиции состоит в следовании примерно одному и тому же набору технических процессов разработки:
- анализ требований
- определение архитектуры (деление на части)
- разработка частей
- интеграция частей
- верификация и валидация
Этот процесс разработки часто отображается в виде V цикла. Результатом каждого из этих процессов является определенный набор документов и схем. МЕТОД разработки на основе моделей определяет как применяется моделирование для выполнения задач этих основных 5 технических процессов разработки системы. В результате применения метода должны быть получены стандартный набор документов. С применением нового метода сделано это может быть более быстро и качественно (документы содержат меньше ошибок).

Разработка системы - рекурсивная процедура, которая примерно в одном виде применяется на каждом из уровней декомпозиции системы. Для разработки каждого элемента системы (на разных уровнях и горизонталях) применяется свой V цикл. Соответственно и метод разработки на основе моделей применяется на разных уровнях, в рамках каждого V цикла. 

Системная инженерия в некотором роде итерационна на макро уровне. Фазы системной инженерии - это макро итерации. Обычно выделяют фазы концептуального, эскизного, технического и рабочего проектирования. У каждой из этой фазы есть свои цели. Деление на фазы - это желание как можно раньше уменьшить риски проекта, не заглубляясь сразу в детали, а концентрируясь на рискованных моментах. На каждой фазе создается спецификации системы и/или ее прототип с некоторым уровнем проработки деталей.

Таким образом метод разработки на основе моделей описывает как выполняются стандартные задачи процессов в рамках V цикла. Метод рекурсивно применяется на всех уровнях декомпозиции системы и на всех фазах ее разработки.

Два класса читателей, на которые я буду ориентироваться

Пока я выделяю для себя два основных класса читателей данного блока. Первый - практикующий системный инженер, использующий документо-ориентированный подход. Второй - бывший разработчик ПО, знающий UML и развивающий у себя навыки системного инженера.

Практикующий системный инженер (аналитик/архитектор). Имеет опыт создания систем с использованием документо-ориентированного подхода. Обычно про UML не знает. Привык работать с большими документами-спецификациями требований, архитектуры, интерфейсов. Хорошо осознает процесс разработки систем, его результаты (документы). В основном использует для работы текстовый редактор. Также использует программы такие как MatLab, Mathcad для создания "математических" моделей систем. Скорее всего не подозревает о возможной замене текстового редактора для выполнения задачи анализа, проектирования и спецификации систем . Хотел бы сделать свою деятельность эффективнее.

Бывший разработчик ПО. Имеет хорошее представление или опыт использования UML для анализа и проектирования ПО. Постепенно переквалифицируется в системного инженера (аналитика/архитектора). Начинает заниматься программными/ИТ/техническими системами большего размера, либо включающими несколько инженерных дисциплин. При развитии в эту сторону меняются способы и результаты его работы. В традиционном подходе к разработке систем основным инструментом для бывшего разработчика ПО должен стать текстовый редактор. Это его немного смущает. Склонен привносить новые инструменты моделирования в новую деятельность. Но пока еще не очень хорошо понимает процесс системной инженерии и его результаты.

Для меня это два абсолютно разные классы. Если их сложить они бы очень дополняли друг друга, слабо пересекаясь. Одной из целей этого блога - это объединить знания практикующих системных инженеров и бывших разработчиков ПО, придя к новому типу системного инженера, которого требует создание современных систем.

Классы тем в этом блоге

Что же я буду писать в этом блоге? Задам себе этот вопрос, чтобы начать планировать и в будущем организовать информацию.

Почему формат блога? Он позволит эффективно двигаться маленькими обозримыми и законченными шажками, делая небольшие обещания и шаг за шагом их выполняя. С помощью формата блога я собираюсь есть слона и избегать страха, что он такой большой.

Формат блога напоминает мне подход topic-oriented writing. Основной смысл этого подхода заключается в создании различных документов путем комбинации их из небольших топиков. Сами топики создаются так, чтобы их можно было использовать в различных документах. Примерно такие топики я и планирую писать в этом блоге. В дальнейшем их можно будет скомбинировать под различные потребности.

Вот список классов тем, которые будут возникать у меня в блоге
- коммиты планов (как этот пост)
- постановки задач на моделирование (контекст моделирования и что должны давать модели)
- возникшие трудности/проблемы при моделировании
- описание конкретных моделей (умного дома и может быть других)
- описание и анализ альтернативных подходов к моделированию
- возможности языков для моделирования систем
- описание важных возможностей инструментов моделирования
- паттерны моделирования для анализа, проектирования и интеграции систем
- tutorials - как что-то проделать в инструменте
- новости
- ссылки на полезные ресурсы
- история развития мысли, как я к этому шел

В последующем я создам для каждого из классов отдельные теги в блоге, что позволит легко получать выборки из блоге по этим темам. Еще позже, можно будет создать индексные страницы, в которых.

Создание системной модели умного дома

Мы планируем построить недалеко от Зеленограда на Пятницком шоссе дом для ПМЖ. У нас уже есть участок, но еще предстоит заработать денег на постройку дома. Это реальная система, которую я планирую создать в ближайшие несколько лет. И эта система должна позволить мне на практике проложить путь к разработке на основе моделей.

Так как денег на постройку дома еще нет, у меня есть время на анализ требований и проектирование дома и его систем. Нет необходимости бросаться сразу строить. Есть время разработать концепцию дома и спроектировать дом, следуя правильному методу. Этот метод должен позволить учесть все наши требования, заложить основу развития дома в будущем, дать основу для бюджетирования и планирования работ по строительству. Заодно и разработать этот метод. Я планирую создать модель дома на SysML, которая бы позволила получить в результате полную спецификацию проекта дома и его систем.

Разработкой SysML модели нашего будущего дома я и занимаюсь последнее время. Эта конкретная деятельность по созданию моделей дома выявила кучу вопросов и проблем как в языке моделирования SysML, новых проблем (к тем, которые мне были и раньше известны) в инструменте моделирования IBM Rational Rhapsody, так и пробелов в практическом осознании метода моделирования у меня в голове.

На основе модели дома я и планирую проложить путь к разработке на основе моделей. На текущем этапе при создании модели я буду идти не всегда последовательно. Скорее я буду пробовать на практике те или иные моменты по созданию модели дома. Я буду двигаться, как сверху вниз, так и снизу вверх. Заниматься то структурным представлением, то поведенческим, то параметрическим, то представлением требований. Постепенно я буду сводить все эти представления в единую модель дома.

Могу сказать, что модель уже приносит свои результаты. Я уже использую модель для "документирования" результаты изучения устройства отдельных систем дома: ХВС, ГВС, отопления, вентиляции и др. В этом блоге я не буду останавливаться на технологиях этих систем. Для этого у меня есть отдельный блог, в котором я публикую свои находки в отношении технологий строительства и систем дома. В этом же блоге я буду публиковать свои находки по методологии анализа и проектирования на основе моделей, в ближайшее время на примере модели дома.

Процесс/метод/язык/инструмент для создания моделей

Поиск пути к разработке на основе моделей включает поиск/разработку процесса/метода/языка и инструмента. 

Моделирование систем о котором идет речь не ограничивается рисованием большого количества несвязанных диаграмм в нотации языка моделирования (например в Visio). Речь идет о моделировании, которое больше похоже на наполнение базы данных с определенной схемой. При этом диаграммы - это лишь удобный способ по наполнению этой базы, а также способ ее анализа. Схема базы данных задается как языком моделирования, так и используемым методом. Для создания таких моделей нужны специализированные инструменты.

В данный момент я использую для создания моделей язык моделирования SysML. Этот язык развивается от языка моделирования ПО - UML и предназначен для моделирования систем. Он рекомендуется всемирной организацией системных инженеров INCOSE в качестве основного языка для этих целей. Нельзя сказать, что этот язык полностью готов для выполнения возложенной цели. Он тоже активно развивается. У него есть преимущества, но есть и недостатки.

Метод определяет как с использованием языка моделирования SysML решаются стандартные задачи процесса разработки, какие артефакты (формальные модели) создаются на каждом из этапов, как они связаны друг с другом. Я знаком со следующими методами использования SysML: IBM Rational Harmony SE, метод SYSMOD из книги Tim Weilkiens по SysML, и метод из книги A Practical Guide to SysML. Не могу сказать, что эти описания методов закрывают все мои потребности и вопросы, поэтому в процессе моделирования постепенно идет разработка своего собственного метода.

Инструмент должен максимально автоматизировать создание модели с использованием выбранного метода. У меня есть опыт использования трех инструментов для создания моделей на SysML: IBM Rational Rhapsody, Eclipse Papyrus и NoMagic MagicDraw. В данный момент для создания моделей систем я использую MagicDraw. 

От разработки на основе документов к формальным моделям

Традиционно системы разрабатываются на основе создания большого количества текстовых документов. В виде текстовых документов создаются спецификации требований, описаний архитектуры, проекта, методик испытаний и т.д. С увеличением сложности современных систем данный метод разработки систем все чаще становится не эффективным. 

Под системами в этом блоге я подразумеваю два типа систем. Первый тип - это программные и ИТ-системы. Второй тип - это технические системы, такие как самолет, автомобиль, умный дом. У этих двух типов систем есть своя специфика к подходам разработки, но есть много и общего.

Сложность современных систем растет экспоненциально и методы разработки должны успевать за этой сложностью. Системы становятся более интегрированными и более интеллектуальными. Многие инновационные функции технических систем реализуются в виде программного обеспечения. Роль программного обеспечения при разработке ранее механических систем сильно меняется, оно становится более интегрированным в системы. Это привносит новый уровень сложности и новый уровень рисков при разработке данных систем. 

Для борьбы со сложность современных систем на смену традиционного метода разработки на основе документов должен прийти метод разработки на основе моделей. На смену неформальных текстовых спецификаций требований и архитектуры должны прийти формальные модели. Стандартные текстовые документы можно будет автоматически генерировать на основе создаваемых моделей. Но основным, центральным артефактов в данном методе являются модели. Результирующие артефакты (документы) могут быть те же, вот только качество их выше, а трудоемкость процесса по достижению этого качества ниже. 

Путь к разработке систем на основе моделей

Ночь. Проснулся и не смог заснуть. В голове куча мыслей, которые не дают покоя. Опять работал до самого отбоя, потому и навеяло. Решено. Создаю блог, чтобы освободиться от мыслей. И называю блог  "Путь к разработке систем на основе моделей".

В этом блоге я буду отражать свой путь поиска процесса/метода/языка/инструмента, который бы позволил разрабатывать системы более эффективно. За плечами у меня есть опыт движения по этому пути и я хочу поделиться им. Но путь этот пока не завершен. Я не претендую на знание всего пути, но стремлюсь проложить его.

С 2007 по 2014 год моя работа была связана с продвижением/внедрением решений IBM Rational для разработки систем и ПО на основе моделей, а также решения по управлению жизненным циклом их разработки. Среди прочего в это время я вел presale-семинары и обучающие тренинги по методам и инструментам, разрабатывал и переводил различные материалы по этой тематике, занимался консультированием и внедрением ИТ-систем на основе данных решений.

Ранее с 1999 по 2007 год я занимался разработкой программно-аппаратных систем и что называется вкусил проблем разработки и управления данными проектами на практике. После 2007 года в плане разработки я больше занимался разработкой/интеграцией ИТ-систем, целью которых было управление жизненным циклом разработки, управление контентом при разработке, управления знаниями и коммуникациями в команде разработки. Основой этих систем были как продукты от IBM Rational, так и свободные продукты.

У этого блога нет коммерческой направленности, потому, что я больше не занимаюсь продвижением решения IBM Rational. Но я продолжаю идти по своему пути. А у каждого пути есть свое начало.

Когда-то на тренинге по инструменту, который я вел, один человек произнес очень хорошую фразу "Обучение - это передача знаний о той не глюкавой тропе, по которой можно прийти к цели". В этом блоге я постараюсь рассказать о той части пути, который я уже прошел, и буду освещать мои попытки прокладывания дальнейшего пути.