Декомпозиция ППО на составные части – процесс трудно формализуемый и не является предметом рассмотрения данного отчёта. Предположим, что такая декомпозиция осуществлена руководителем или группой руководителей проекта наилучшим образом. Задачи перед разработчиками составных частей ППО поставлены и они приступили к работе. При этом начинается согласование программного интерфейса между составными частями (или согласование изменений этого интерфейса). Очевидно, что затрат времени на такое согласование будет меньше, если большая часть интерфейса спроектирована ещё до начала работы над изделием. Более того, лучше, если интерфейс программного взаимодействия одинаков для всех составных частей ППО и для всех изделий, разрабатываемых на предприятии. Такой интерфейс должен быть разработан специально для организации взаимодействия разработчиков составных частей ППО. Его использование позволит существенно снизить трудозатраты на разработку программного обеспечения и затраты на повторное использование программ, так как любые составные части ППО могут быть использованы в любом проекте без их изменения на основе единого интерфейса программного взаимодействия.
Составные части ППО тренажного комплекса, которые будут иметь единый программный интерфейс, назовём программными компонентами (ПК). Главное требование к ПК – это минимизация взаимодействия с другими ПК, входящими в состав проекта. Это требование достаточно неконкретное, поэтому необходимо сформулировать набор вытекающих из него частных требований.
Первым требованием является "модульная обособленность". ПК должна быть оформлена в виде такого программного модуля, который мог бы включаться в любой программный проект без его изменений и без изменений в коде других ПК. Вследствие этого ПК не должна иметь прямых связей с другими ПК (под прямой связью понимается наличие глобальных имён переменных и процедур, доступных из других ПК). При включении ПК в проект и её удалении трансляция и компоновка проекта должны происходить так, как будто этого изменения не было. Модульная обособленность обеспечивает минимизацию затрат на соединение ПК, изготовляемых разными разработчиками, и повторное использование ПК.
Другим требованием является соответствие ПК единому программному интерфейсу. Это требование вытекает из первого, так как отсутствие прямых связей между ПК предполагает наличие связей косвенных. Такие связи могут быть реализованы посредством набора общих для всех ПК процедур, образующих единый программный интерфейс. Кроме этих процедур каждая ПК должна иметь некий логический идентификатор, посредством которого можно получить косвенный доступ к её общим процедурам. При наличии такого интерфейса разработчик ПК ничего не должен знать об устройстве других компонент, кроме их логических идентификаторов и перечня описаний взаимодействий. Описание взаимодействия может включать набор команд взаимного управления ПК и форматы данных (не сами данные!), которыми обмениваются компоненты. Подразумевается, что любая ПК должна включать в себя некий минимальный набор фиксированных процедур, необходимых для реализации программного взаимодействия.
Следующим требованием, обеспечивающим выполнение первых двух, является наличие организатора взаимодействия компонент. Так как ПК ничего "не знают" друг о друге (и даже о наличии друг друга в программном проекте), должна существовать некая системообразующая программа, обеспечивающая связывание ПК в единый программный комплекс посредством их логических идентификаторов и единого программного интерфейса.
Декомпозиция ППО на ПК осуществляется на основе нескольких принципов:
- принцип физического соответствия - когда ПК выделяется в силу сопоставления реального предмета или явления соответствующим вычислительным задачам (например, процесс движения самолёта, прибор или группа приборов естественным образом могут быть оформлены соответствующими моделирующими ПК).
- принцип оптимизации размера – когда необходимость выделения ПК проверяется её ожидаемым размером (имеется в виду просто объём исходного кода). Очевидно, что большое количество мелких ПК, как и малое количество огромных, равно неудобно при разработке ППО.
- принцип минимизации связей – когда декомпозиция осуществляется таким образом, чтобы информационный обмен между ПК был минимален.
организационный принцип – когда разные разработчики работают над разными ПК (это минимизирует трудозатраты на взаимодействие разработчиков).