4 курс (заочка) / Учебное пособие / Tekhnologii_programmirovania

- 23 -

целом образует приемлемое качество всего ПС для заказчика. Причём каждое из этих свойств должно быть в достаточной степени конкретизировано. Для конкретизации качества ПС по каждому из критериев используется стандартный набор довольно простых свойств и характеристик [1]. Эти свойства однозначно интерпретируются разработчиками. Такие элементарные свойства называют примитивами качества ПС. Некоторые примитивы могут использоваться несколькими критериями.

Используемые примитивы качества ПС определяются следующим образом [1]. Завершённость – это свойство, характеризующее степень обладания ПС всеми

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

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

- 24 -

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

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

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

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

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

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

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

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

Эффективность по устройствам – это мера, характеризующая экономичность использования устройств машины для решения поставленной задачи.

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

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

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

- 25 -

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

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

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

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

Независимость от устройств – свойство, отражающее способность ПС работать на различных аппаратных платформах.

4.3.Формирование функциональной спецификации ПС (ФС)

Сучётом назначения ФС и тяжёлых последствий ошибок в ней, она должна ба-

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

ФС включает три части [1]:

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

2)описание функций ПС, которые определены на множестве состояний информационной среды. Такие функции называются внешними.

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

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

- 26 -

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

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

4.4. Контроль ВО ПС

Разработка внешнего описания ПС должна завершаться проведением тщательного контроля. Цель методов контроля – выявление, как можно большего числа ошибок. Выделяют следующие методы контроля [1]:

1)статический просмотр;

2)смежный контроль;

3)пользовательский контроль;

4)ручная имитация.

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

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

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

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

5. Разработка архитектуры ПС

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

- 27 -

этапом борьбы со сложностью ПС, так как позволяет выделять относительно независимые модули или подсистемы. Результатом правильного выделения модулей является уменьшение сложности ПС. Основные задачи разработки архитектуры ПС [1]:

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

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

5.1. Классификация архитектур ПС (АПС)

Выделяют следующие основные классы АПС [6]:

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

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

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

4)коллектив параллельно выполняемых программ.

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

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

каждая из которых удовлетворяет условиям:

а) любая из программ может быть активизирована (запущена) пользователем; б) при выполнении активизированной программы другие программы этого набора не могут быть активизированы, пока не закончит выполнение активизирован-

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

ной среде.

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

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

- 28 -

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

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

в) каждый слой располагает определёнными ресурсами, которые он предоставляет непосредственно последующему слою.

Примером использования данной архитектуры является построенная Дейкстрой учебно-показательная ОС (рис. 4).

П р и к л а д н ы е п р о г р а м м ы

Слой 3. Управление входными-выходными потоками данных

Слой 2. Поддержка связи с операторской консолью

Слой 1. Управление и распределение памяти

Слой 0. Диспетчеризация и синхронизация процессов

К о м п ь ю т е р

Рис. 4. Архитектура учебно-показательной ОС Дейкстры

Коллектив параллельно выполняемых программ – это набор программ, взаи-

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

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

Каждое сообщение поступает на вход первой программы, которая обрабатывает сообщение и передаёт его на вход следующей программы. Первая программа

- 29 -

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

5.2. Архитектурные функции и контроль АПС

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

Для контроля АПС используются смежный контроль и ручная имитация

[1].

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

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

6.Таблицы решений как основной подход

кспецификации семантики функций

Табличный подход хорошо известен и широко используется при составлении ФС. Таблица решений (ТР) состоит из четырёх частей [7]:

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

Вход условий – это перечень всех возможных ответов на указанные вопросы.

- 30 -

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

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

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

ТР может быть полной и неполной. Таблица называется полной, если в ней содержатся столбцы для всех комбинаций ответов «да» и «нет».

Представим ТР для управления печатью наибольшего из трёх чисел А, В и С.

Эта таблица является полной, так как на три вопроса, предполагающих один из двух ответов, можно ответить восемью способами ( 23 ), и все комбинации ответов в ней представлены. Эта таблица имеет ограниченный вход, так как на входе условий содержится только «да» и «нет», а во входе действий – только пометки и пробелы.

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

ТР всё время осуществляется вправо и вниз.

- 31 -

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

ТР можно упрощать и записывать в более компактном виде, если опускать те из столбцов-правил, которые не соответствуют реальным условиям. Кроме того, не для всех комбинаций данных необходимо отвечать на все вопросы. Например, в нашем примере можно убрать 2 и 7 столбцы, 1 и 3 столбцы можно совместить, так как неважно В > С или С > В (А всё равно больше их обоих).

Но у метода ТР есть ограничения. Полную ТР из 5-6 условий уже довольно трудно изобразить. Эффективную обработку таблицы с числом условий >>10 трудно выполнить даже на ЭВМ. Если число условий n, то число правил составля-

ет 2n , т.е. число столбцов входа таблицы растёт по экспоненциальному закону.

7. Разработка структур программ. Модульное программирование

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

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

-32 -

7.1.Характеристики для оценки ПМ

Не всякий ПМ способствует упрощению программы. Выделить хороший с этой точки зрения модуль является серьёзной творческой задачей. Для оценки приемлемости выделенного модуля используются некоторые критерии. Майерс [6] предлагает для этого использовать конструктивные характеристики ПМ:

–размер модуля;

–прочность модуля;

–сцепление с другими модулями;

–рутинность модуля (независимость от предыстории обращений к нему). Размер модуля измеряется числом содержащихся в нём операторов или строк.

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

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

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

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

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