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

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, показывает, что можно описать солидную систему в терминах внешних воздействий на нее и ее видимого извне поведения. Методами, рассмотренными в данной работе, мы руководствовались при получении информации; они помогали нам справляться со сложностями и позволили отвлечься от деталей реализации. Документ служит отправной точкой для этапа проектирования в нашей разработке. На многие вопросы, которые обычно возникают и решаются только на фазе программирования, документ дает точные ответы. Так как информация в нем представлена систематически, мы можем многое планировать заранее, вместо того чтобы вставлять каждую деталь в программу как придется.

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

ИЗ *ДИГ* В *ДИ*

@Т ('широта! > 70°)

@Т (/РЕЖСИИ/ = $Инер$) КОГДА (!ДРЛ подключен!)

Согласно этой записи, система переходит из режима *ДИГ* в режим *ДИ* (радиолокационно-инерционной навигации), когда самолет попадает в широты, большие 70°, или

Рисунок 4 Секция таблицы условий для режимов навигации.

когда переключатель режима инерционной платформы переставляется в положение ИНЕР при подключенном доплеровском радиолокаторе.

В таблицу на рис. 4 сведены условия, истинные для раз­личных режимов навигации. Например, в режиме *ДИГ* переключатель режима инерционной платформы установлен в положение НОРМ, самолет находится в воздухе на широте, меньшей 70°, а доплеровский радиолокатор и инерционная платформа работают нормально. X в графе таблицы озна­ чает, что значение соответствующего условия для данного ре­жима несущественно.

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

Специальные таблицы для точности и полноты описания

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

Рисунок 5 Пример таблицы условий

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

Согласно рис. 5, значение магнитного курса равно 0, когда система находится в режиме *Сбой СИИ* и истинно условие (/РЕЖСИИ/ - $Между$). Всегда, когда система находится в режиме *Сбой СИИ*, истинно следующее условие, показы­ вающее полноту строки таблицы:

(/РЕЖСИИ/ = $Между$ ИЛИ (НЕ /РЕЖСИИ/ = $Между$))

Кроме того, при этих условиях ложно утверждение

(/РЕЖСИИ/ =$Между$ И (НЕ /РЕЖСИИ/ = $Между$'))

которое выражает взаимоисключаемость элементов строки.

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

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

Таблица событий на рис. б определяет, что сигнал автокалибровки, управляемый выходным элементом данным //АВ ТОКЛБ//, должен включаться, когда система входит в какой- либо из перечисленных режимов, и выключаться, когда систе­ ма выходит из этого режима. Символом := мы обозначаем присваивание. Событие @Т(В режиме) происходит тогда, когда все условия, представляемые режимом, становятся истинными, т. е. когда система входит в этот режим. Событие @ F (В режиме) происходит при изменении значения любого

Рисунок 6 Пример таблицы событий

из этих условий на "ложь", т. е. при переходе системы в какой-либо другой режим.

Примеры описания функций

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

Таблица событий на рис. 7 показывает события, вызывающие запрос функции, и значения, выдаваемые функцией в разное время. Например, если при входе в режим *Зем* значение //ШКАЛАСИИ// равно $Грубо$, то оно изменяется функцией на $Точно$. Обратите внимание на использование в таблице символических имен, введенных в разделе аппаратуры для элементов данных и их значений.

На рис. 8 в разделе "Запускающие и останавливающие события" указаны события, вызывающие запуск и останов описываемой периодической функции.

Периодическое исполнение функции начинается, когда другой выходной элемент данных //СКОРППИ// получает значение $Вкл$, и прекращается, когда этому элементу данных присваивается значение $Выкл$. Функция вычисляет положение некоторого символа на индикаторном устройстве. Положение символа обычно отражает направление вектора скоро­сти самолета, но при определенных условиях соответствующие выходные элементы данных получают другие значения. Описание выходных элементов данных включает в себя две части: краткое словесное описание обычного смысла упомянутого символа и таблицу условий, показывающую, что будет происходить при различных условиях. Заметим, что в таблице учтены все режимы,

Рисунок 7 Заполненный формуляр для запрашиваемой функции

указанные в списке режимов. На данную функцию влияют условия !ДС работает! и !ДС не работает! (статус датчика ЭВМ, обеспечивающего измерение истинной скорости), а также /ВВОЗДУХЕ/ = $Да$ и /ВВОЗДУХЕ/= = $Нет$! (находится ли самолет в воздухе). В частности, если система находится в инерционном режиме навигации (*И*) и самолет находится на земле (/ВВОЗДУХЕ/ = *= $Нет$), то обе координаты символа устанавливаются на нуль.

Маркер траектории полета (МТП) на пилотажно-проекционном индикаторе показывает направление вектора скорости самолета. Если вектор скорости самолета совпадает со строительной осью самолета, то МТП находится в центре индикатора. Смещение МТП в сторону показывает горизонтальную составляющую скорости, а отклонение вверх или вниз — ее вертикальную составляющую.

Хотя способ вычисления положения МТП меняется, как показано на таблице внизу, основой для его вычисления обычно служат !Системные скорости!. Сначала из этих скоростей выделяются скорость в прямом направлении, горизонтальная и вертикальная составляющие. После этого ко­ординаты МТП вычисляются следующим образом:

//ДЗМТП// = (Горизонтальная скорость)/(Скорость в прямом направлении)
//ПОДЪЕММТП// = (Вертикальная скорость)/( Скорость в прямом направлении)

Рисунок 8 Заполненный формуляр для периодической функции

МЕТОДЫ ЗАДАНИЯ НЕЖЕЛАТЕЛЬНЫХ СОБЫТИЙ

Списки нежелательных событий

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

1. Отказы ресурсов
1.1 Временные
1.2. Постоянные

2. Ошибки во входных данных
2.1. Обнаруживаемые путем изучения только, входных данных
2.2. Обнаруживаемые при сравнении с внутренними данными
2.3. Обнаруживаемые пользователем, понявшим, что он допустил ошибку
2.4. Обнаруживаемые пользователем по некорректным выходным данным

3. Ошибки во внутренних данных
3.1. Обнаруживаемые по внутренним несоответствиям
3.2. Обнаруживаемые при сравнении с входными данными
3.3.Обнаруживаемые пользователем по некорректным выходным данным

ХАРАКТЕРИСТИКА ВОЗМОЖНЫХ ИЗМЕНЕНИИ

Чтобы дать характеристику типов возможных изменений в системе, мы просмотрели список пожеланий по изменению системы и провели опрос сопровождающего ее персонала. Если бы мы занимались определением требований для новой системы, было бы естественно изучить пожелания по модификации аналогичных систем. Кроме того, мы составили длинный список фундаментальных предположений о системе, которые, как мы думали, должны быть справедливы всегда, что бы ни произошло. В результате совещания с несколькими сопровождающими систему инженерами и программистами от нашего списка фундаментальных предположений остались лишь, четыре; все остальные были отвергнуты и перенесены в список возможных изменений. Например, для имеющейся программы справедливо следующее утверждение, которое может быть нарушено в будущем: "В каждый момент ЭВМ выполняет расчеты по применению оружия только для одной цели; при указании новой цели система забывает о предыдущей". Составляя два дополняющих друг друга списка, — возможных изменений и фундаментальных предположений, — мы обдумывали задачу в двух разных направлениях и обнаружили множество разногласий. Разработка списка фундаментальных предположений заставила нас явно высказать некоторые неявные предположения, в результате чего выявился ряд возможных изменений, на которые мы бы иначе не обратили внимания. Одна из причин успеха этой процедуры в том, что рецензенту гораздо легче обнаружить ошибку, нежели упущение. Ниже перечислены примеры вероятных изменений.

1. Может измениться привязка устройств к конкретным каналам.
2. Может измениться скорость передвижения символов на индикаторе при изменении положения ручки управле­ ния.
3. Могут быть добавлены новые датчики (что уже случалось в истории данной программы).
4. Новые типы оружия могут потребовать управления со стороны ЭВМ после его применения.
5. Может потребоваться самопроверка ЭВМ в воздухе (сейчас она проводится только на земле).
6. Может возникнуть необходимость отказа от некоторых функций невысокого приоритета, чтобы освобождать ресурсы для более важных функций в критических ситуациях (в настоящее время, если программа не успевает выполнять все функции, она останавливается с сообщением об ошибке).

ОБСУЖДЕНИЕ

Мы полагаем, что составленный нами документ будет под держиваться в соответствии с текущей ситуацией по мере эволюции программы, поскольку он полезен во многих отноше ниях независимо от нашего проекта. Специалисты, сопровож дающие существующую систему, планируют с его помощью вести обучение нового персонала, так как документ описывает назначение программы в согласованной систематической форме. Он содержит единственное полное и соответствующее реальному положению дел описание интерфейсов с аппаратурой. Одна из проблем, возникающих у них при внесении изменений, заключается в том, что трудно отследить все места в программе, которые нужно изменить. Например, в одном месте программу изменили так, чтобы индикатор включался, когда цель находится на расстоянии в 22 морские мили, а в другом месте он включается при расстоянии до цели 20 миль. Эта непреднамеренная разница в 2 мили не вызывает особых проблем, но вносит неоправданную дополнительную сложность в работу пилота и программиста. Подобные несоответствия хорошо видны в таблицах, содержащихся в нашем документе. Наряду с использованием документа для контроля за последствиями небольших изменений специалисты по сопровождению хотят изменять документ так, чтобы он соответствовал новой версии программы. Они считают особенно перспективным использование документа при составлении системных тестов, так как он дает описание допустимого поведения системы независимо от конкретной реализации (прежде им приходилось выяснять, что должна делать программа, путем изучения ее текста). В конце концов они намерены систематически получать тесты по таблицам и схемам переходов из режима в режим.

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

ЗАКЛЮЧЕНИЕ

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

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

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

Данная статья — это лишь введение в идеи, которые иллюстрирует документ [б], содержащий описание требований. Этот документ является полностью проработанным примером; проблема рассмотрена без упрощений, во всех деталях. Затраты труда на разработку и применение описанных методов составили примерно 17 человеко-месяцев. Составленный документ позволяет всем желающим ознакомиться с идеями более подробно. Технология часто основывается на рекомендациях следовать каким-либо моделям. Мы полагаем, что наш документ является хорошей моделью документирования требований.

Благодарность

Методы, описанные в этой статье, разработаны автором совместно с Д. Парнасом, Дж. Шором и Дж. Калландером. Автор выражает благодарность Е. Бриттону, X . С. Еловиду, Д. Парнасу, Дж. Шору и Д. Вайесу за тщательное и полезное рецензирование рукописи.

ЛИТЕРАТУРА

• Brinch Hansen P. Operating Systems Principles. Englewood Cliffs, N,J.: Prentice-Hall, 1973.
• Dijkstra E. W. Co-operating sequential processes, in Programming Languages, F. Genuys, Ed. New York : Academic, 1968, pp . 43—112. (Имеется перевод: Э. Дейкстра. Взаимодействие последовательных процессов. В кн.: Языки программирования. Ред. Ф. Женюи.— М,: Мир, 1972.)
• Dijkstra E. W. A Discipline of Programming. Englewood Cliffs, N. J.: Prentice-Hall, J977. (Имеется перевод: Э. Дейкстра. Дисциплина программирования. — М.; Мир, 1978.)
• Guttag J. V, Abstract data types and the development of data structures, Commun. Ass. Comput. Mach., vol. 20, pp. 396—404, June 1976.
• Heninger K., Kallander J., Parnas D. L., Shore J. Software Requirements for the A-7E Aircraft, Naval Res. Lab., Washington, DC, Memo fteo 3876, Nov. 27, 1978.
• Hoare C. A. R. Monitors: An Operating system structuring concept, Commun. Ass. Comput. Mach., vol. 17, pp. 549—557, Oct. 1974.
• Howard J, Proving 1 monitors, Commun, Ass. Comput. Mach., vol 19, pp. 273—279, May 1976.
• Upton R. On Synchronization Primitive Systems, Ph. D. dissertation, Carnegie-Mellon Univ., Pittsburg, PA, 1973.
• Liskov В ., Zilles S. Specification tecniques for data abstractions, IEEE Trans. Software Eng., vol. SE-1, pp. 7—19, Mail. 1975. ( Имеется перевод ; Сб . «Данные в языках программирования».—М.: Мир 1982 с. 91 — 122.)
• Liskov В ., Berzins V. An appraisal of program specifications, in Proc. Conf, on Research Directions in Software Technology, Oct. 10—12 1977, pp. 13.1-13.24.
• Parnas D. L. Information distribution aspects of design meshodology, an Proc. Int. Fed. Inform. Processing Corigh, Aug. 1971, vol. TA-3.
• Parnas D. L. On the criteria to be used in decomposing systems into modules, Commun. Ass. Comput. Mach,, vol. f5, pp. 1053—1058, Dec. 1972.
• Parnas D. L, Handzel G. More on Specification Techniques for Software Modules, Fachbereich Informatik, Technfsche Hochschule Darmstadt, Darmstadt , W. Germany, 1975.
• Parnas D. L., Wurges H. Response to undesired events in software systems, in Proc. 2nd Int. Conf. Software Eng., 1978, pp. 437—446.
• Parnas D. L. Use of Abstract Interfaces in the Development of Software for Embedded Computer Systems, Naval Res. Lab., Washington, DC , Rep. 8047, 1977.
• Parnas D. L. The use of precise specifications in the development of software, in Proc. Int. Fed. Inform, Processing Congr., 1977.
• Parnas D. L. Designing software for ease of extension and contraction, in Proc. 3rd Int. Conf. Software Eng., May 1978.
• Parnas D. L., Henjnger K. Implementing process.es in HAS, n Software Engineering Principles, Naval Res. Lab., Washington, DC, 1978, Document HAS, 9.
• Parnas D. L. Desired system behavior in undesired situations, in Software Engineering Principles, Naval Res. Lab., Washington, DS, 1978, Document UE. 1.
• Roubine O., Robinson L. SPECIAL Reference Manual, Stanford Res. Inst., Menlo Park, CA, SRI ech. Rep. CSL-45, SRI project 4828, 3rd ed., 1977.
• Shaw A. C. The Logical Design of Operating Systems. Englewood Cliffs, NJ: Prentice-Hall, 1974.
• Weiss D. M. The MUDD Report: A Case Study of Navy Software Development Practices, Naval Res. Lab., Washington, DC, Rep. 7909, 1975.