Неправильный перевод информации как причина ошибок в программных средствах

    Устойчивость {robustness) ПС - свойство, характеризующее способность ПС продолжать корректное функционирование, несмотря на задание неправильных (ошибочных) входных данных.

    Защищённость {defensiveness) ПС - свойство, характеризующее способность ПС противостоять преднамеренным или нечаянным деструктивным (разрушающим) действиям пользователя.

    П-документированностъ {и. documentation) ПС - свойство, характеризующее наличие, полноту, понятность, доступность и наглядность

    учебной, инструктивной и справочной документации, необходимой для применения ПС.

    Информативность {accountability) ПС - свойство, характеризующее наличие в составе ПС информации, необходимой и достаточной для понимания назначения ПС, принятых предположений, существующих ограничений, входных данных и результатов работы отдельных компонент, а также текущего состояния программ в процессе их функционирования.

    Коммуникабельность {communicativeness) ПС - свойство, характеризующее степень, в которой ПС облегчает задание или описание входных данных, и способность выдавать полезные сведения в достаточно простой форме и с простым для понимания содержанием.

    Временная эффективность {time efficiency) ПС - мера, характеризующая способность ПС выполнять возложенные на него функции в течение определённого отрезка времени.

    Эффективность по ресурсам {resource efficiency) ПС - мера, характеризующая способность ПС выполнять возложенные на него функции при определённых ограничениях на используемые ресурсы (память).

    Эффективность по устройствам {device efficiency) ПС — мера, характеризующая экономичность использования устройств компьютера для решения поставленной задачи.

    С-документированность  ПС {documentation) - свойство, характеризующее с точки зрения наличия документации, отражающей требования к ПС и результаты различных этапов разработки данного ПС, включающие возможности, ограничения и другие черты ПС, а также их обоснование.

    Понятность {understandability) ПС - свойство, характеризующее степень, в которой ПС позволяет изучающему его лицу понять его назначение, сделанные допущения и ограничения, входные данные и результаты работы его программ, тексты этих программ и состояние их реализации. Этот примитив качества синтезирован нами из таких примитивов ISO [59], как согласованность, самодокументированность, четкость и, собственно, понятность (текстов программ).

    Структурированность {structuredness) ПС - свойство, характеризующее программы ПС с точки зрения организации взаимосвязанных их частей в единое целое определённым образом (например, в соответствии с принципами структурного программирования).

    Удобочитаемость (readability) ПС - свойство, характеризующее лёгкость восприятия текста программ ПС (отступы, фрагментация, фор-матированность).

    Расширяемость (augmentability) ПС - свойство, характеризующее способность ПС к наращиванию объёма памяти для хранения данных или расширению функциональных возможностей отдельных компонент.

    Лёгкость  изменения (modifiability) ПС - мера, характеризующая ПС с точки зрения простоты внесения необходимых изменений и доработок на всех этапах и стадиях жизненного цикла ПС.

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

    Независимость ПС от устройств (device independence) - свойство, характеризующее способность ПС работать на разнообразном аппаратном обеспечении (различных типах, марках, моделях компьютеров).

    4.4. Функциональная спецификация  программного средства

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

    Функциональная  спецификация состоит из трёх частей:

    •    описания внешней информационной среды, к которой должны применяться программы разрабатываемой ПС;

    •    определение функций ПС, определённых на множестве состояний этой информационной среды (такие функции будем называть внешними функциями ПС);

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

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

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

    В третьей  части должны быть перечислены все  существенные случаи, когда ПС не сможет нормально выполнить ту или иную свою функцию (с точки зрения внешнего наблюдателя). Примером может служить обнаружение ошибки во время взаимодействия с пользователем, попытка применить какую-либо функцию к данным, не удовлетворяющим соотношениям, указанным в её спецификации, или получение результата, нарушающего заданное ограничение. Для каждого такого случая должна быть определена (описана) реакция ПС.

    4.5. Методы контроля  внешнего описания  программного средства

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

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

    •    статический просмотр,

    •    смежный контроль,

    •    пользовательский контроль,

    •    ручная имитация.

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

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

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

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

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

    Вопросы к главе 4

    4.1. Что  такое определение требований к ПС!

    4.2. Что  такое спецификации качества ПС!

    4.3. Что  такое устойчивость {robustness) ПС!

    4.4. Что  такое защищённость (defensiveness) ПС!

    4.5. Что  такое коммуникабельность {communicativeness) ПС!

    4.6. Что  такое функциональная спецификация ПС!

    А.1. Что такое ручная имитация внешнего описания ПС!

    Разделяй  и властвуй!

    Латинское изречение

    Глава 6 АРХИТЕКТУРА ПРОГРАММНОГО СРЕДСТВА

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

    6.1. Понятие  архитектуры программного средства

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

    Основные  задачи разработки архитектуры ПС:

    •    выделение программных подсистем  и отображение на них внешних  функций (заданных во внешнем описании) ПС;

    •    определение     способов     взаимодействия     между     выделенными программными подсистемами.

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

    6.2. Основные  классы архитектур программных  средств

    Различают следующие основные классы архитектур программных средств [35]:

    •   цельная программа;

    •    комплекс автономно выполняемых  программ;

    •   слоистая программная система;

    •    коллектив параллельно действующих  программ.

    Цельная программа представляет вырожденный случай архитектуры ПС: в состав ПС входит только одна программа. Такую архитектуру выбирают обычно в том случае, когда ПС должно выполнять одну ка-

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

    Комплекс  автономно выполняемых  программ состоит из набора программ, такого, что:

    •    любая из этих программ может быть активизирована (запущена) пользователем;

    •    при выполнении активизированной программы  другие программы этого набора не могут быть активизированы до тех пор, пока не закончит выполнение активизированная программа;

    •    все программы этого набора применяются  к одной и той же информационной среде.

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

    Слоистая  программная система  состоит из упорядоченной совокупности программных подсистем, называемых слоями, такой, что:

    •    на каждом слое ничего не известно о  свойствах (и даже существовании) последующих (более высоких) слоев;

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