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

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.

Продолжение: Описание выходных элементов данных в терминах воздействия на внешние устройства; Пример описания выходного элемента данных; Методы описания функций программного обеспечения; Организация описания в соответствии с функциями; Выходные значения как функции условий и событий; Согласованная нотация для описания условий; Режимы и их использование для организации и упрощения описания требований.

Описание выходных элементов данных в терминах воздействия на внешние устройства

Большая часть выходных элементов данных описывается в терминах их воздействия на соответствующие устройства. Например, описание выходных элементов данных //УПРАЗИ-МУТ// и //УПРПОДЪЕМ// показывает, как ими пользоваться для указания положения, в которое нужно установить антенну радиолокатора. В этом разделе не объясняется, каким образом программа выбирает это положение. Для других выход­ных элементов данных мы указываем значения, которые периферийные устройства должны получать, чтобы правильно работать. Например, описание выходного элемента данных //УГОЛНП// показывает, что радиолокатор ожидает значение некоторого угла, которое он использует для определения угла подъема или пикирования самолета, необходимого для огибания рельефа местности. При описании выходного значения мы стараемся избегать любых ассоциаций, не связанных со свойствами аппаратуры.

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

На рис. 3 (см. часть 2, рис.3) изображен заполненный формуляр для числового выходного элемента данных. Обратите внимание, что значение описано в терминах его воздействия на стрелку индикатора без какой-либо связи с тем, какую информацию при этом получает пилот. Значение характеризуется стандартным набором параметров, таких, как диапазон и цена деления, используемых для всех числовых элементов данных. В разделе Представление показано, как образуется 16-разрядное выходное слово, и в том числе: какие разряды должны быть нуле­выми, какие игнорируются устройством и какие кодируют значение. Поскольку фактическое выходное значение не измеряется в каких-либо стандартных единицах, мы указываем, каким образом его получить из величины, выраженной в стан­дартных единицах (в данном случае — в градусах). Это соотношение задается в виде равенства

вых. значение = ед. шкалы X (значение в станд. ед. - f - + смещение)

Так как это равенство используется для всех числовых элементов данных, то в любом конкретном случае требуется ЛИШЬ подставить значения единицы шкалы и смещения. Например, выходное значение элемента данных //ОШУПР// на рис. 3 получается из значения в градусах по следующей формуле:

вых. значение = 409.6 Х (значение в град. + 0)

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

VI . Методы описания функций программного обеспечения

Организация описания в соответствии с функциями

Мы описываем программу как набор функций, связанных с выходными элементами данных: каждая функция опреде­ляет значения одного или более выходных элементов данных, и значения любого выходного элемента данных задаются в точности одной функцией. Таким образом, любую функцию можно описать через видимый извне производимый ею эффект. Например, функция , вычисляющая значения выходного элемента данных //ОШУПР//, описывается в терминах ее воздействия па стрелку индикатора. Здесь же определяется смысл показаний индикатора для пилота.

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

В нашем случае имеется единственное устройство общего назначения панель ЭВМ, на которой один и тот же набор из 13 семисегментных индикаторов может отображать информацию разных видов, включая координаты самолета, скорость Ветра и СОСТОЯНИЯ датчиков. Мы справились с этой ситуацией, построив описание так, как если бы для каждого вида информации была отдельная панель, управляемая отдельной функцией, Таким образом мы получили 48 функций и каждую из них описали так, как будто она постоянно управляет панелью.

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

Функции программного обеспечения подразделяются на запрашиваемые и периодические. Каждое исполнение запрашиваемой функции происходит в ответ на некоторое событие. Например, сигнал "сбой ЭВМ" включается запрашиваемой функцией при обнаружении ошибки в работе аппаратуры. Периодическая функция выполняется многократно, и ее не нужно каждый раз запрашивать. Например, координаты симво­лов на экране пилотажно-проекционного индикатора постав­ляются периодическими функциями. Если периодическую функцию не нужно исполнять все время, ее можно запускать и останавливать специальными событиями.

Такое разделение полезно, потому что для периодических и запрашиваемых функций требуется разная информация о режиме исполнения и временных характеристиках. При описании запрашиваемой функции нужно указать события, вы­зывающие ее выполнение, а вопрос, который следует задавать в отношении временных характеристик, таков: какова максимально допустимая задержка между запросом и действием по запросу! Описывая периодическую функцию, необходимо задать события, запускающие и останавливающие ее (перио­дическое) исполнение и условия, влияющие на ее работу после того, как она запущена. В отношении временных характе­ристик для такой функции уместно задать вопрос: Какова ми­нимальная и максимальная частота повторения этой функции?

Выходные значения как функции условий и событий

Сначала мы предполагали описывать выходные значения как математические функции от входных значений. Такой подход оказался слишком наивным. Нам редко удавалось описать выходные значения непосредственно через входные; вместо этого приходилось определять промежуточные значения, вычисляемые имеющейся программой, но не соответ ствующие никаким выходным значениям. Их в свою очередь нужно было описывать в терминах других промежуточных значений. Когда мы наконец добирались до входных значений, оказывалось, что мы фактически описали реализацию.

Вместо этого мы стали описывать требования, задавая выходные значения в виде функций от условий работы самолета. Например, выходной элемент данных //ШИРЗА70// должен ме нять значение в тот момент, когда самолет пересекает 70-ю широту, а каким образом программа узнает об этом событии, оставляется на усмотрение реализации. Чтобы описывать выходные значения в терминах условий работы самолета, мы определили несложный язык условий и событий.

Например, условие /РЕЖСИИ/ = $Выравн$ истинно тогда, когда переключатель режима системы инерционных измерений установлен в положение ВЫРАВН (см. рис. 2). Если каждый раз, когда этот переключатель нахо­дится в данном положении, пилот ожидает отображения некоторой информации на индикаторе, то значение /РЕЖСИИ/ влияет на функцию, управляющую индикатором. Событие происходит тогда, когда значение условия изменя­ется с истины на ложь или наоборот. Таким образом, события указывают моменты времени, в то время как условия задают промежутки времени. События запускают и останавливают периодические функции, они же вызывают исполнение запрашиваемых функций. С помощью событий удобно описывать такие ситуации, когда нечто происходит при нажатии кнопки, но ничего не меняется, если продолжать удерживать ее в нажатом положении. До того, как мы ввели четкое различие между событиями и условиями, подобные ситуации плохо поддавались простому описанию.

Согласованная нотация для описания условий

Макроопределения. Чтобы описания функций были краткими, мы ввели более двухсот терминов, которые обрамляются с обеих сторон восклицательными знаками и определяются в словаре в алфавитном порядке. Такое макроопределение может задавать некоторую величину, влияющую на какое-либо выходное значение, но не выводимую непосредственно из входных данных. Примером может служить !угол фактического!, определяемый как "угол, измеряемый от направления на истинный север до !линии фактического пути!, в направле­нии по часовой стрелке, если смотреть вниз". И хотя точные значения такого рода определяются реализацией, макроопределения дают удобный, единообразный способ ссылки на них при описании значений функций.

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

Список событий, определяющих это условие, появляется лишь в словаре; при чтении остальной части документа их рассма­тривать не нужно. При изменении процедуры указания цели меняется лишь определение, данное в словаре. Еще одним примером сокращения сложного условия может служить !СИИ в пределах нормы!(1), заменяющее следующее громоздкое и узкоспециальное условие:

!общ скор СИИ! <= 1440 фут/с И

изменение !общ скор СИИ! за последние .2 с <= 50 фут/с

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

Использование макроопределений является примером пошагового уточнения: при описании функций мы даем имена сложным условиям или значениям, откладывая на будущее их точное определение. Как показывают приведенные примеры, мы продолжаем вводить новые термины и в самих определениях. Это позволяет нам ограничить объем подробностей, с которыми приходится иметь дело в одном месте. Кроме того, так же как скобки /, //, $ в описаниях аппаратуры, восклицательные знаки указывают на то, что где-то имеется точное определение термина. Это делает менее вероятными двусмыс­ленности, присущие чисто словесным описаниям.

Условия. Мы записываем эти предикаты в виде выражений, содержащих ссылки на входные элементы данных, например /РЕЖСИИ/ = $Выравн$, или на величины, задаваемые мак­роопределениями, например !угол фактического пути! = 30°. Условие можно также целиком задать в виде макроопределения и ссылаться на него соответствующим образом, например !СИИ в пределах нормы!. Сложные условия можно получать из простых с помощью логических операций И, ИЛИ и НЕ. Например, условие !СИИ в пределах нормы! И /РЕЖСИИ/== $Вырави$ истинно тогда и только тогда, когда истинны оба составляющих его простых условий.

События. Мы используем обозначение @,Т (условие 1) для указания события, состоящего в том, что условие 1 становится истинным. Соответственно @ F (условие 2) обозначает событие, что значением условия 2 становится "ложь".

Например, событие @Т (!угол фактического пути! < 30°) происходит тогда, когда значение !угол фактического пути! пересекает сверху отметку 30°. Событие @Т (!угол фактического пути! = 30°) происходит, когда это значение достигает 30° с любой стороны. Событию @Т (/РЕЖСИИ/= $Выравн$) соответствует момент установки пилотом переключателя режимов системы инерционных измерений в положение ВЫ-РАВН. В некоторых случаях событие происходит при изменении одного условия и истинности другого, что обозначается так:

@Т (условие 3) КОГДА (условие 4)

Так,. @7(/ВВОЗДУХЕ/=$Да$) КОГДА (/РЕЖСИИ/= = $Выравн$) означает событие, заключающееся в отрыве самолета от земли при переключателе, установленном в положение ВЫРАВН. А событие @Т (/РЕЖСИИ/= $Выравн$) КОГДА (/ВВОЗДУХЕ/= $ДА$) соответствует моменту уста­новки переключателя в режим ВЫРАВН в то время, когда самолет находится в воздухе.

Режимы и их использование для организации и упрощения описания требований

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

Каждому режиму присваивается короткое мнемоническое имя, обрамляемое звездочками, например *ДИГ* (режим ра диолокационно-инерционной навигации с установкой по гирокомпасу). Имя режима употребляется в остальной части документа в качестве сокращения, заменяя набор условий, истинных в соответствующем режиме.

1) Это макроусловие означает, что значения, получаемые от системы инерционных измерений, находятся в допустимых пределах, а именно вычисляемая по этим значениям скорость самолета не превышает 1440 футов в секунду и за последние 0,2 секунды изменилась не более чем на 50 футов в секунду.
[вернуться в текст к месту врезки]