Структура декомпозиции на модули А-7Е

В качестве описания структуры декомпозиции модулей А-7Е и примера документации модульной структуры мы намерены привести ряд отрывков из руководства по модулям программной части А-7Е. Описание декомпозиционного де­рена начинается с трех модулей высшего уровня. Связано это с тем, что, по неко­торым наблюдением, изменения в системах, подобных А-7Е, обычно происходят из трех источников: из области аппаратного обеспечения, с которым взаимодей­ствует программная часть, из области предполагаемого внешнего поведения си­стемы и, наконец, из той области, в которой решения принимает программный проектировщик проекта.

Модуль сокрытия аппаратного обеспечения. Модуль сокрытия аппаратного обеспечения (Hardware-Hiding Module) содержит процедуры, которые модифицируются в случае замены старых аппаратных блоков новыми, функционально аналогичными, но обладающими ориги­нальным аппаратно-программным интерфейсом. Этот модуль реализует виртуальное обо­рудование (virtual hardware) — набор абстрактных устройств, к которым обращаются все остальные программные элементы. Первичными секретами здесь являются аппаратно-про­граммные интерфейсы. В качестве вторичных секретов выступают структуры данных и алго­ритмов, участвующие в реализации виртуального оборудования. Одним из подмодулей мо­дуля сокрытия аппаратного обеспечения является модуль расширения компьютера (Extended Computer Module), скрывающий элементы процессора.

Модуль сокрытия поведения. Процедуры модуля сокрытия поведения (Behavior-Hiding Module) модифицируются в тех случаях, когда изменение требований влечет за собой кор­ректировку предполагаемого поведения. Эти требования являются первичным секретом дан­ного модуля. Его процедуры вычисляют значения, которые впоследствии отправляются вир­туальным устройствам вывода, реализуемым модулем сокрытия аппаратного обеспечения.

Модуль программных решений. Модуль программных решений (Software Decision Module) скрывает те программно-проектные решения, которые основываются на математических теоремах, физических фактах и факторах программирования наподобие алгоритмической эффективности и точности. Описание секретов этого модуля в сводке требований отсутствует. Основное его отличие от других модулей заключается в том, что в данном случае решения о секретах и интерфейсах принимаются программными проектировщиками. Следовательно, внесение изменений здесь обычно обусловливается не внешними факторами, а желанием повысить производительность и точность.

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

Модуль прикладных типов данных (Application Data Type Module). Этот модуль дополняет типы данных расширенного модуля компьютера типами данных, характерными для авиационных приложений и не требующими машинозависимой реализации. Среди них — расстояние (тип данных, применяемый для определения высоты), временные интервалы и углы (используют­ся для вычисления широты и долготы). Реализуются они через элементарные числовые типы данных модуля расширения компьютера, а их переменные применяются так, как будто соот­ветствующие типы встроены в упомянутый модуль.

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

Модуль банка данных (Data Banker Module). В большинстве случаев данные производятся одним модулем, а потребляются другим. При этом потребители обычно требуют предоставитьим самые свежие значения. Период времени, по проник; тии которого данное значение сле­дует пересчитывать, определяется свойствами его потреби юля (требованиями по точности) и производителя (стоимостью вычислений и часлотой изменения значений). В этих условиях модуль банка данных исполняет роль посредника - именно он определяет, когда следует проводить подсчет новых значений.

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

Модуль банка данных содержит все значения, которые мог ут что-либо сообщить о внут­реннем состоянии модуля или о состоянии воздушного судна. Кроме того, он сигнализирует обо всех событиях, которые предполагают внесение изменений в сохраненные значения. Модуль банка данных необходим во всех ситуациях, при которых в ролях потребителя и про­изводителя выступают разные модули, — пусть они даже оба входят в более крупный модуль на правах подмодулей. Модуль банка не используется только в двух случаях: во-первых, если потребителям требуются конкретные члены последовательности вычисленных производи­телем значений и, во-вторых, если вычисленное значение представляет собой не что иное, как функцию значений входных параметров, предоставленных процедуре- производителю, — например, sin(x)^[1].

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

Модуль фильтрации поведения (Filter Behavior Module) содержит цифровые модели физи­ческих фильтров. С их помощью сторонние процедуры фильтруют потенциально зашумлен­ные данные. Первичными секретами этого модуля являются модели вычисления значений, которые строятся на основе выборочных значений и оценки погрешности. Вторичные секре­ты — это вычислительные алгоритмы и структуры данных, с помощью которых реализуются упомянутые модели.

Модуль физических моделей (Physical Models Module). Некоторые количественные величи­ны, которые программе требуется определить, вычисляются не напрямую, а посредством математических моделей на основе наблюдаемых значений. Пример — время, за которое баллистический снаряд долетает до земли. В качестве первичных секретов модуля физиче­ских моделей выступают математические модели; вторичные секреты — это их вычислитель­ные реализации.

Модуль обслуживающих программ (Software Utility Module) содержит служебные программы, которые в противном случае пришлось бы писать сразу нескольким программистам. Среди них — математические функции, диспетчер ресурсов, а также процедуры, которые сигнали­зируют о завершении модулями инициализации при включении питания. Секретами этого модуля являются структуры данных и алгоритмы реализации упомянутых процедур.

Модуль генерации системы (System Generation Module). Первичными секретами модуля ге­нерации системы считаются решения, которые откладываются вплоть до периода генера­ции системы. Это, во-первых, значения параметров генерации системы, а во-вторых, аль­тернативные реализации модуля. В качестве вторичных секретов модуля генерации системы выступают метод генерации машинно-исполняемого кода и представление отложенных ре­шений. Процедуры этого модуля запускаются не на бортовом компьютере, а на машине, при­меняемой для генерации его кода.

Декомпозиция в руководстве по модулям доводится до третьего (а иногда даже до четвертого) уровня, но здесь мы в эти детали углубляться не намерены. Третий уровень структуры декомпозиции для архитектуры А-7Е приводится лишь на рис. 3.4. Обратите внимание на идентичность имен некоторых модулей интер­фейсов устройств (Device Interface) и управления функциями (Function Driver).

 

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

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

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