1. Краткие теоретические сведения

1.1. Внешние спецификации программного обеспечения

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

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

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

Для примера рассмотрим функционирование банкомата при обслуживании клиента по его кредитной карте /4/. Цель верхнего уровня ‘обслужить клиента’ включает такие подцели:

а) получить пароль,

б) получить запрос на обслуживание,

в) обработать запрос на обслуживание,

г) обработать кредитную карту.

Подцели “а”, “б” и “г” не требуют дальнейшей детализации, а подцель “в” не является столь очевидной и требуется ее структурирование на подцели следующего уровня. Этими подцелями будут:

1. обработать внутреннюю банковскую документацию;

2. распечатать баланс клиента;

3. распечатать операцию клиента (уведомление о проведенной операции);

4. подготовить деньги клиента.

Окончательная структура целей для рассматриваемого примера приведена на рис. 1.1.

обслужить

получить получить обработать обработать

пароль запрос на запрос карту

обслужив.

обработать распечатать распечатать подготовить

документа- баланс операцию деньги

цию клиента клиента клиенту

Рис. 1.1. Структура целей задачи “обслуживание клиента

по кредитной карте”

1.1.2. Спецификация функций с помощью таблиц решений.

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

На следующем этапе составляются внешние спецификации выявленных функций или, иначе, спецификации процессов. Фактически спецификации являются описаниями алгоритмов соответствующих функций. Для этих целей существует достаточно много средств, которые перечислим в порядке увеличения трудности проектирования алгоритмов /4/:

- текстовое описание,

- структурированный естественный язык,

- таблица решений,

- дерево решений,

- визуальный язык,

• схемы систем, программ, данных и другие нотации для представления алгоритмов (псевдокоды, Flow-формы и диаграммы Насси-Шнейдермана) /10/,

- язык программирования.

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

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

ТР состоит из двух частей. Верхняя часть таблицы используется для определения условий. Обычно условие является ЕСЛИ-частью оператора ЕСЛИ-ТО и требует ответа “да-нет:”. Нижняя часть ТР используется для определения действий, т.е. ТО-части оператора ЕСЛИ-ТО. Левая часть ТР содержит собственно описание условий и действий, а в правой части перечисляются все возможные комбинации условий и, соответственно, указывается, какие конкретно действия и в какой последовательности выполняются, когда определенная комбинация условий имеет место.

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

Здесь “Д” означает “да”, “Н” – “нет”, прочерк “-” означает, что условие не проверяется, цифры 1,2 означают, что помеченные действия выполняются в указанном порядке.

Таблица 1.1

Таблица решений для функции “получить пароль”

Условия	1	2	3
Нажата клавиша “ввод”?	Н	Д	Д
Пароль введен верно?	-	Н	Д
Действия
Ждать ввода	1
Выдать предупреждение об ошибке		1
Перейти к основному меню		2	1

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

Таблица 1.2

Таблица решений для усложненной функции “получить пароль”

Условия	1	2	3	4	5	6	7
Нажата клавиша “ввод”?	Н	Д	Д	Д	Д	Д	Д
Первый ввод пароля?	-	Д	Д	Н	Н	Н	Н
Повторный ввод пароля?	-	Н	Н	Д	Д	Д	Д
Счетчик повторений равен 3?	-	Н	Н	Н	Н	Д	Д
Пароль введен верно?	-	Д	Н	Н	Д	Н	Д
Действия
Ждать ввода	1
Выдать предупреждение об ошибке			1	1
Увеличить счетчик повторений			2	2
Блокировать карту клиента						1
Окончание таблицы 1.2
Действия	1	2	3	4	5	6	7
Выдать приглашение к повторному вводу пароля			3	3
Перейти к основному меню		1			1	2	1

Методика построения ТР заключается в следующем:

а) определить все условия и действия в спецификации;

б) вписать действия и условия в таблицу;

в) в нумерованных столбцах отметить все возможные комбинации условий и порядок выполняемых при этом действий;

г) при необходимости редуцировать таблицу, Редуцирование заключается в следующем: если есть 2 столбца, у которых перечень действий совпадает, и которые отличаются только результатами условий “Д” и “Н” в одной строке, то такие столбцы могут быть слиты в один. В этом столбце отличающиеся исходы “Д” и “Н” заменяются прочерком, что интерпретируется как независимость действий от данного условия. Для ТР 1.2 такими столбцами являются столбцы с номерами 3 и 4. Редуцированная ТР приводится в таблице 1.3.

Таблица 1.3

Редуцированная таблица решений для функции “получить пароль”

Условия	1	2	3	4	5	6
Нажата клавиша “ввод”?	Н	Д	Д	Д	Д	Д
Первый ввод пароля?	-	Д	-	Н	Н	Н
Повторный ввод пароля?	-	Н	Н	Д	Д	Д
Счетчик повторений равен 3?	-	Н	Н	Н	Д	Д
Пароль введен верно?	-	Д	Н	Д	Н	Д
Действия
Ждать ввода	1
Выдать предупреждение об ошибке			1
Увеличить счетчик повторений			2
Блокировать карту клиента					1
Выдать приглашение к повторному вводу пароля			3
Перейти к основному меню		1		1	2	1

Отметим, что на основе ТР легко осуществить кодирование программы на языке высокого уровня, таком, как Pascal.