Функциональная декомпозиция системы выполняется на каждом уровне абстракции при проектировании: на уровне бизнес анализа, системного анализа, логического проекта, физического проекта. Функциональные декомпозиции с предыдущего уровня передаются на следующие, постепенно становясь все детальнее и детальнее. Необходимо поддерживать в согласованном состоянии результаты функциональной декомпозиции, выполненной на каждом из уровней абстракции. Также должна быть возможность согласованно вносить изменения в функциональные декомпозиции всех уровней, при появлении новых требований или изменении существующих.
Функциональные декомпозиции, выполненные на более детальных уровнях абстракции не заменяет функциональную декомпозицию, выполненную на более абстрактных этапах. Они слишком детальны и не могут использоваться всеми заинтересованными лицами. Например, есть участники проекта, которым важно представлять функциональную декомпозицию уровня системного анализа и не важны другие детали. Или другой пример: системный анализ выполняет заказчик. А логический и физический проект выполняет исполнитель.
Для удовлетворения потребностей всех заинтересованных лиц проекта, необходимо иметь и поддерживать в актуальном состоянии функциональные декомпозиции системы на разных уровнях абстракции.
Но и это не вся задача. Часто необходимо вносить изменения в функциональные декомпозиции, выполненные на более ранних этапах. После изменений необходимо приводить в соответствие функциональные декомпозиции, выполненные на более поздних этапах.
Например, на поздних этапах обнаруживаются новые пользовательские/системные требования к системе, которые приводят к появлению новых пользовательских задач, системных и логических функций. Данные изменения необходимо вносить в документы всех уровней, содержащих функциональную декомпозицию различных уровней.
Современные методы проектирования уже не предполагают, что жизненный цикл разработки системы представляет из себя модель водопада. Итерационные методы разработки предполагают разбиение разработки на итерации/фазы, когда разработка снова и снова проходит этапы концептуального/логического/физического проектирования. Дополнительные проходы этих этапов выполняются также при доработке системы по результатам эксплуатации.
В случае использования документов Word для фиксации результатов функциональной декомпозиции на каждом из этапов, возникает серьезная трудоемкая работа по поддержанию этих документов в целостном и непротиворечивом состоянии.
При использовании формальных моделей для выполнения функциональных декомпозиций на всех этапах, появляется возможность существенно снизить трудоемкость поддержания результов функциональных декомпозиций в непротиворечивом состоянии.
Далее я продемонстрирую как это делается в Capella.
Модель Capella содержит несколько разделов, которые соответствует различным уровням абстракции при проектировании системы. В каждом разделе есть подраздел для сохранения результатов функциональной декомпозиции системы на данном уровне абстракции
Если открыть эти разделы, то на первый взгляд в них содержатся одни и те же функции.
Но если присмотреться к иконкам функций, то можно увидеть, что это разные элементы модели, имеющие разные типы SF - системная функция, LF - логическая функция, PF - физическая функция
В логической функциональной декомпозиции функции проработаны более детально. Приведу пример из рассматриваемой модели. Детализация функциональной декомпозиции на уровне системного анализа заканчивается на уровне системных функций: электроснабжение мастерской, холодное водоснабжение и т.д.
На уровне логического проектирования системные фукнции декомпозируются глубже. Например, системная функция освещения декомпозируется на такие функций, как Коммутация освещения зоны готовки и Излучение света в зоне готовки.
Уровень детализации функций в логическом проекте определяется уровнем детализации компонентов системы, на которые система разбивается в логическом проекте. Если логический проект декомпозирует систему освещения до выключателей и ламп, то функциональная декомпозиция системы выполняется до уровня функций этих компонентов. В логическом проекте не только декомпозируются системные функции, но и появляются новые - поддерживающие.
Итак, имеем две согласованные функциональные декомпозиции системы, одна из которых более детальная.
Допустим, что появилось новое пользовательское требование: Житель должен иметь возможность удаленно управлять открытием калитки по результатам голосовых коммуникаций с посетителем. В результате функционального анализа этого требования, в часть модели, содержащей результаты концептуального проектирования будут добавлены новые функции, а также модифицированы существующие. Для визуализации новых системных функций и взаимодействий были созданы две диаграммы
Диаграмма функционального сценария
Диаграмма потоков данных
В случае использования документов Word на данном этапе предстоит тяжелая работа по приведению логической функциональной декомпозиции в соответствие с новой версией системной функциональной декомпозиции.
В случае использования Capella предстоит простая операция по обновлению логической части модели на основе системной части модели. Для обновления логической функциональной декомпозиции выбираем на диаграмме потоков данных элементы модели, которые мы хотим обновить. Из контекстного меню запускаем передачу функций на следующий этап. В результате открывается окно анализа изменений и обновления логической модели. Слева в окне отображается список изменений. По центру модель-кандидат после объединения. Справа текущая логическая модель.
После нажатия Apply и Ok изменения логической модели будут произведены.
В семантическом браузере модели видим, что для логической функции системы были созданы все связанные функции, порты и связи.
Для всех созданных логических функции также были созданы трассировочные связи к исходным системным функциям. Например для логической функции "Обеспечение удаленного управления калиткой" в семантическом браузере модели видим в категории Realized System Functions ссылку на системную функцию "Обеспечение удаленного управления".
После обновления можно продолжать работать над декомпозицией данной системной функции для ее реализации в логическом проекте. Для начала создадим функцию потоков данных, с помощью которой детализируем системную функцию Обеспечение удаленного управления.
Основу для данной диаграммы можно создать на основе диаграммы функциональных потоков данных, которую мы ранее создали для системной функции. Для этих целей используем команда Initialize from Existing diagram но вновь созданной диаграмме.
В открывшемся диалоговом окне выбираем интересующую нас исходную диаграмму
Нажимаем Ок и получаем аналогичную диаграмму, но на которой уже отображены элементы логической модели. Полученную диаграмму потоков данных модифицируем, создавая с помощью нее новые составные функции и перетаскивая на них порты с исходной функциии. Декомпозируем мы только функции системы. В общем случае, функции акторов мы не декомпозируем, оставляя их такими же как на этапе концептуального проектирования.
Результаты декомпозиции функция системы "Обеспечение удаленного управления" калиткой в стандартном браузере модели.
После этого можно создать функциональные сценарии, также передав их с системного уровня на логический. В результате автоматической передачи функциональный сценарий взаимодействия становится боле детальным и включает вновь определенные составные функции. Связи взаимодействия между функциями автоматически создаются на составных функциях.
Таким образом, используя формальные модели для фиксации результатов функциональных декомпозиций на каждом этапе проектирования, можно минимальными усилиями отслеживать изменения в проектах и обновлять последующие проекты на основе изменений в предыдущих, не тратя на это больших усилий.
