Cameo Systems Modeler - урезанная версия MagicDraw

Постепенно подхожу к мысли о покупке лицензии на MagicDraw. Пока пользуюсь trial версией, разбивая модель на маленькие модели (по 25 элементов каждого типа). Но с ростом модели это становится все менее удобно. При этом инструмент продолжает нравиться.

Сегодня осознал, что для моих целей моделирования систем на SysML достаточно приобрести Cameo Systems Modeler за 120 Евро. Это существенно дешевле чем приобретать отдельно MagicDraw и к нему SysML Plugin (ранее смотрел, было в сумме около 1000$) .

Cameo - это бренд компании NoMagic (разработчика MagicDraw). Каждый из продуктов в этой линейке - это ядро MagicDraw с некоторым набором предустановленных плагинов-расширений (для Eclipse).
Cameo Systems Modeler = ядро MagicDraw + SyMLPlugin

В Cameo Systems Modeler входят следующие основные возможности моделирования:
- моделирование на SysML
- управление требованиями
- трассировка между уровнями требований и моделей
- кастомизация инструмента для создания языков предметной области
- автоматическая валидация моделей на основе правил на языке OCL
- публикация документации из модели на основе настраиваемых шаблонов
- доступ моделей из скриптов на 6 языках

В Cameo Systems Modeler не входят все что связано с исполнением и оценкой параметров
- исполнение и отладка поведенческих моделей
- решение параметрических ограничений

Конечно хотелось бы иметь нотации UPDM, BPMN, а также DataModeling, возможность моделирования GUI. Это возможности доступны при приобретении других плагинов MagicDraw. В данный момент мне достаточно SysML.

Сегодня даже зашел в электронный магазин на сайте NoMagic и понял что от покупки меня отделяет один клик, так как купить можно просто по карте.

Структурная декомпозиция поселка

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

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

На рисунке представлена схема поселка в графическом виде. 

Далее представлены диаграммы, которые сверху вниз формально описывают структуру поселка с использованием диаграмм языка SysML

Высокоуровневая структура поселка 

Структура основной части, примыкающей к нашему району 1

Структура района 1, содержащего наш участок

Интерфейсы владения 122 с границами района 1

Я определял порты для элементов поселка, относящихся к нашему участку: основной части поселка, района 1 и самого владения 122. Остальные элементы архитектуры поселка я связывал без определения портов. 

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

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

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

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

Движение от конца к началу

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

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

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

Это начальный вариант целей которым должна соответствовать создаваемая физическая модель дома.

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

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