Home

Автор: К. Хенинджер

Heninger К. L. Specifying Software Requirements for Complex Systems: New Techniques and Their Application, IEEE Transactions on Software Engineering, vol. SE-5, № 1, January 1980, 2-13.

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

Резюме

Эта статья посвящена новым методам, позволяющим сделать описания требований точными, краткими, однозначными и легко проверяемыми на полноту и непротиворечивость. Методы хорошо подходят для сложных программных систем реального времени; они были разработаны для документирования существующего полетного программного обеспечения самолета А-7 ВМС США. В статье приводится обзор информации, входящей в состав описания требований, и обсуждаются цели, поставленные при разработке методов. Описание каждого метода иллюстрируется примерами из документа, содержащего требования к программному обеспечению самолета А-7. Цель этой статьи состоит в том, чтобы представить указанный документ как модель дисциплинированного подхода к описанию требований, а сам документ может служить полностью проработанным примером применения этого подхода.

IV . ПРИНЦИПЫ ДОКУМЕНТИРОВАНИЯ ТРЕБОВАНИЙ

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

1) Ставить вопросы прежде, чем пытаться на них отвечать.

На всех стадиях написания требований мы прежде всего кон­центрировали свои усилия на формулировке тех вопросов, на которые следовало дать ответы. Если этого не делать, то имеющийся в наличии материал мешает беспристрастному рассмотрению требований, так что задаются лишь вопросы, на которые легко отвечать. Прежде всего, чтобы охарактеризовать общие классы вопросов, на которые нужно дать ответы, мы составили оглавление показанное на рис. 1. Мы написали его еще до того, как впервые обратились к материалам по А-7, исходя из нашего опыта работы с другими систе­мами. Затем мы подготовили вопросы по каждому разделу.

Рисунок 1. Оглавление документа

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

2) Разделять аспекты.

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

3) Как можно больше формализации.

Мы избегали чисто словесных описаний и разработали формальные способы представления информации, чтобы добиться точности, краткости, непротиворечивости и полноты.

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

V . МЕТОДЫ ОПИСАНИЯ ИНТЕРФЕЙСОВ С АППАРАТУРОЙ

Организация описания в соответствии с элементами данных

При организации описания интерфейсов с аппаратурой мы используем специальную единицу — элемент данных. Элемент данных — это любой входной или выходной параметр, значение которого изменяется независимо от других параметров. Примерами входных элементов данных являются барометрическая высота, расстояние до выделенной точки на земной по­верхности, измеряемое радиолокационным методом, положение переключателя режима инерционной платформы и сигнал готовности инерционной платформы. Примерами выходных элементов данных могут служить координаты маркера траектории полета самолета на пилотажно-проекционном индикаторе, команды управления антенной радиолокатора и сигнал, включающий и выключающий индикаторную лампочку «сбой ЭВМ», Бортовая ЭВМ самолета А-7 получает 70 входных элементов данных и передает 95 выходных элементов данных,

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

Рисунок 2. Заполненный формуляр для входного элемента данных

Может ли ЭВМ проверить правильность значения, полученного от датчика? В процессе работы над конкретными элементами данных у нас появлялись новые вопросы. Мы вносили эти вопросы в наш формуляр, и таким образом они распространялись на все элементы данных. Иллюстрация использования формуляра приводится на рис. 2 и 3.

Символические имена элементов данных и значений

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

Рисунок 3. Заполненный формуляр для выходного элемента данных

Существенную информацию нужно выражать таким образом, чтобы в остальной части документа ее можно было использовать, не обращаясь к произвольным деталям. Например, каждому элементу данных присваивается символическое имя, и в дальнейшем этот элемент однозначно идентифицируется без ссылок на последовательности инструкций, (необходимые для работы с ним) или номера каналов (по которым он передается). Если элемент данных нечисловой и прини мает фиксированное множество возможных значений, то этим значениям присваиваются мнемонические имена, что позволяет ссылаться на них без указания двоичных кодировок. Например, значениями некоторого переключателя могут быть «вкл» и «выкл». Физическое представление указанных значений относится к разряду произвольных деталей и не упоминается в остальной части документа, которая, следовательно, остается неизменной при смене этого представления. Символические имена дают возможность составителям и читателям остальной части документа отвлечься от физических особенностей входных и выходных данных и внешне выглядят более осмысленно, чем те детали, которые они представляют.

Каждое мнемоническое имя мы заключаем в скобки, указывающие тип элемента, например /входные элементы данных/, //выходные элементы данных// и $нечисловые значения$. Эти скобки уменьшают путаницу, однозначно указывая тип элемента таким образом, что читатель знает, где ему искать точное определение. Кроме того, скобки облегчают систематическое отслеживание перекрестных ссылок как вручную, так и с помощью ЭВМ.

Шаблоны для описания значений

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

угол (?) измеряется от прямой (?) до прямой (?) в направлении (?), если смотреть (?)

Например, магнитный курс измеряется от направления на магнитный северный полюс до горизонтальной составляющей оси самолета в направлении по часовой стрелке, если смотреть вниз.

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

Описание входных элементов данных как ресурсов, независимых от использующих их программ

При описании входных элементов данных мы воздерживаемся от указаний того, как или когда эти данные используются программой, чтобы избежать каких бы то ни было предположений о функции программы. Вместо этого мы описываем входные элементы данных, как бы составляя перечень ресурсов, которые можно использовать для решения задачи. Численные значения мы определяем в терминах измеряемых ими величин. Например, входной элемент данных /РЛВЫСОТА/ определяется как расстояние до земной поверхности под самолетом, измеренное радиолокационным высотомером. Многие из нечисловых входных элементов данных указывают позиции переключателей; они описываются без упоминания об эффекте, которого ожидает пилот, изменяя положение переключателя, так как этот эффект реализуется программой. Например, когда пилот поворачивает переключатель масштаба индикатора, отображающего карту местности, он ожидает, что изменится масштаб карты. Поскольку это изменение осуществляется программой, о нем в описании соответствующего входного элемента данных не упоминается.

Это описание выглядит так:
«"МАСШТАБ" указывает положение двухпозици онного тумблера на панели дисплея, отображающего карту. Этот переключатель аппаратно не влияет на состояние индикатора».

Пример описания входного элемента данных

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

Подчеркиванием выделены заголовки разделов формуляра. Кодировка значения показывает, какими конкретными двоичными кодами представляются мнемонические имена, используемые в остальной части документа.

«Положение переключателя» указывает имена позиций переключателя, как их видит пилот, находящийся в кабине. Раздел Последовательность инструкций содержит инструкции на языке ассемблера ТС-2, которые вызывают передачу соответствующих данных извне в ЭВМ или наоборот. Указывая последовательность инструкций, мы вовсе не берем на себя работу программиста, поскольку никаким другим способом Передать описываемый элемент данных нельзя, и выбор последовательности инструкций не относится к числу решений, принимаемых программистом при реализации.

Номер канала. Представляет собой ссылку на раздел описания ЭВМ, в котором приведены общие характеристики всех восьми имеющих ся каналов. Представление показывает размещение значения во вводимом 16-разрядном слове. Обратите внимание, каким образом в разделе Примечание определено значение, прини­маемое переключателем в то время, когда пилот его поворачивает. Это пример вопроса, который мы задавали для всех переключателей, после того как он возник в отношении данного.