Читайте также статьи и материалы о технологиях Rational и Microsoft в блоге Новичкова Александра и Шамрая Александра

Описание требований к ПО для сложных систем

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

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

I. ВВЕДЕНИЕ

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

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

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

II. ПОЛЕТНАЯ ПРОГРАММА САМОЛЕТА А-7

Полетная программа самолета А-7 ВМС США работает в условиях жестких ограничений на память и время. Ее объем — примерно 12 000 инструкций языка ассемблера, а исполняется она на ЭВМ системы IBM-PI (модель ТС-2) с объемом памяти 16 кбайт. Мы выбрали эту программу, желая продемонстрировать, что дополнительные затраты ресурсов, связанные с использованием перечисленных выше принципов разработки программных систем, допустимы для систем реального времени, а также потому, что существующую программу, по мнению сопровождающего персонала, трудно мо­дифицировать.

Рассматриваемая программа входит в состав системы навигации и управления оружием самолета А-7. Она получает входные данные от датчиков, переключателей, расположенных в кабине, а также от пилота, который вводит их c помощью специальной клавиатуры. Программа управляет несколькими устройствами отображения информации в кабине и производит установку положения нескольких датчиков. Всего к ЭВМ подключены 22 устройства; в качестве примеров можно указать инерционный измеритель скорости и пилотажно-проекционный индикатор. Последний проецирует символы в поле зрения пилота так, что тот видит их «поверх» панорамы, наблюдаемой через лобовое стекло кабины. Программа вычисляет навигационную информацию, такую, как текущее положение самолета, его скорость и курс; она управляет также применением оружия, подсказывая пилоту нужный курс и вычисляет подходящий момент для применения оружия.

III. ЦЕЛИ ДОКУМЕНТАЦИИ ТРЕБОВАНИИ

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

Ее содержание, организация и стиль зависят от решений, принятых по следующим вопросам:

1. На какие вопросы документация должна давать ответы?
2. Кто ее читатели?
3. Как ее будут использовать?
4. Какие предварительные знания нужны читателю?

Рассмотрев эти вопросы, мы выработали шесть пунктов, определяющих цели нашего документа.

1) Задавать только внешнее поведение.

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

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

2) Задавать ограничения на реализацию.

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

3) Быть легко изменяемым.

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

4) Служить справочным материалом.

Основное назначение рассматриваемого документа — быстро давать ответы на конкретные вопросы, а не объяснять в общих словах, что делает программа. Мы предполагаем, что им будут пользоваться опытные программисты. В этих условиях важны точность и краткость. Необходимо предусмотреть глоссарий, детальное оглавление и различного рода указатели. Поскольку учебным материалам свойственные иные черты, такие, как повествовательный стиль, их, если надо, следует разрабатывать отдельно.

5) Прогнозировать жизненный цикл системы.

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

6) Описывать допустимую реакцию на нежелательные со бытия.

При определении требований следует предвидеть нежелательные события, такие, как сбои аппаратуры и ошибки пользователя. Поскольку пользователь знает область применения, ему больше, чем разработчику, известно о допустимых реакциях на нежелательные события. Например, пилоту лучше, чем программисту, известно, уменьшит или увеличит его трудности какая-то конкретная реакция на отказ некоторого датчика. Реакции на нежелательные события следует задавать в документе, содержащем определение требований, а не оставлять на усмотрение программиста.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

21.01.2008

Комментарии

• jDbrhFQZBF
  Автор: Well done artclie that. I'll make sure to use it wisely.  ·  21.09.2011 12:15:21
  Well done artclie that. I'll make sure to use it wisely.
• 
  Автор:   ·  04.09.2011 22:33:25
  Houses and cars are not very cheap and not everyone can buy it. Nevertheless, loans are invented to support people in such hard situations.

Добавить комментарий (анонимные комментарии не публикуются!!!)

ФИО:
E-mail:
Тема:
Комментарий:
Оценка:
Код подтверждения:

Читайте также статьи и материалы о технологиях Rational и Microsoft в блоге Новичкова Александра и Шамрая Александра

Новости и пресс-релизы СМ-Консалт

Архив "Новости и пресс-релизы СМ-Консалт"