вторник, 27 декабря 2016 г.

Документация в формате MS Word из моделей Capella

На основе моделей Capella необходимо уметь генерировать документацию в формате MS Word.  Стандартный дополнительный компонент Capella позволяет генерировать только гипертекстовую документацию в формате HTML. Данный компонент необходимо устанавливать дополнительно после установки Capella

Для генерации документации в формате MS Word необходимо использовать универсальный компонент Eclipse Gendoc , позволяющий генерировать документацию в форматах MS Word и OpenOffice на основе любых EMF моделей, в том числе на основе моделей Capella. С использование GenDoc шаблоны документов создаются с помощью MS Word (или Open Office) и языка для создания шаблонов Acceleo.

Для генерации документации на основе моделей Capella можно использовать и просто Acceleo (см. пост). Однако, сгенерировать документацию в формате Word используя просто Acceleo будет не так просто.
Преимущество использования GenDoc состоит в том, что появляется возможность разработать шаблоны документов непосредственно в Word и форматировать документ необходимым образом с использованием средств Word. 

Есть и неудобство от использования GenDoc. При разработке шаблонов приходится использовать яызк Acceleo без подсветки синтаксиса и без контекстной подсказки по API и элементам мета-модели. Если сравнить работу с Acceleo в специализированном редакторе Eclipse, то это очень большое неудобство. С этим неудобством получается справиться, используя интерактивное окно запросов в Capella, которое позволяет выполнять Acceleo запросы к модели. При разработке шаблона документа приходится постоянно проверять запросы элементов в окне запросов и только потом вставлять их в шаблон.

Устанавливать GenDoc в Capella нужно по инструкции на форуме (используя версию GenDoc с форума)

По этой же ссылке есть пример шаблона для GenDoc. Попробовать его можно на модели
In-Flight Entertainment (IDE) Sample Model

Документация поGenDoc доступна по ссылке

Для своих целей я создал отельные шаблоны GenDoc для каждого типа моделей в Capella
- System Analysis
- Logical Architecture
- Physical Architecture
И генерирую отдельные документы для каждой из этих моделей.

Ниже скриншоты моих документов, которые я генерирую c использованием GenDoc.


суббота, 24 декабря 2016 г.

Реализация системных функций в логическом проекте

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

Это пост дополняет информацию в посте 

На уровне системного анализа определим 2 функции с двумя функциональными связями между ними.




Для передачи системных функций в логический проект необходимо выполнить команду Functional Transition на корневой функции (SystemFunctionRealization)

В результате в логическом проекте будут созданы соответствующие логические функции. Пока они отличаются только иконкой ( LF вместо SF)

Для начала отобразим новые функции на диаграмме потоков данных. 
Чтобы снова не рисовать диаграмму, уже созданную при системном анализе, можно автоматически создавать диаграммы в логическом проекте на основе диаграмм в системном анализе. 
Для этого на диаграмме потоков данных в логическом проекте используем команду Initialization from existing diagram и выбираем из списка существующую диаграмму.

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

Если просмотреть информацию о функции LF SystemFunction 1 в семантическом браузере модели, то видно, что данная функция логического проекта реализует системную функцию SystemFunction 1 из системного анализа. Более подробно об использовании семантического браузера модели Capella см в посте по ссылке.





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


Чтобы завершить декомпозицию функций в логическом проекте необходимо для функций 2-го уровня указать системные функции, которые они реализуют.  Просмотрим в семантическом браузере информацию о логической функции LF Logical Function. Видим, что данная функция не реализует ни одной системной функции.



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

Запустим валидацию модели для корневой системной функции в системном анализе. 


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



Capella позволяет исправлять многие ошибки в модели автоматическим образом. Для этого необходимо выделить сообщения об ошибках и выполнить команду из раздела Quick Fix. В нашем случае это будет Realize Function.


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



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

Анализ функциональной декомпозиции на разных уровнях абтсракции

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

На диаграмме ниже отображены 2 уровня функциональной декомпозиции. На диаграмме связи функциональных взаимодействий соединяют функции 2-го уровня декомпозиции. А функции 1 уровня просто являются контейнерами для функций 2 уровня. 


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


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



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


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

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

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

пятница, 23 декабря 2016 г.

Множественные связи функционального взаимодействия

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

Вариант 1. Для функции SystemFunction1 создаются отдельные выходные функциональные порты для каждой связи. 

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

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

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

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

Гораздо понятнее смотреть на диаграмму последовательности, получаемую при использовании Варианта 1 и 2


А вот так стоит поступать при переходе на следующий уровень декомпозиции функций при использовании Варианта 1. Выходные порты просто переносятся на вложенные функции.


Evernote помогает вам помнить всё и без труда организовать свою жизнь. Загрузить Evernote.