Ответы на госэкзамен / Спецификации_ПО
.doc
Здесь найдете материалы для ответов на вопросы 1, 10, 16, 17.
3 Спецификации программного обеспечения
Схема - графическое представление определения, анализа или метода решения задачи, в котором используются символы для отображения операций, данных, потока, оборудования и т.д.
При документировании проекта разработки ПО применяют схемы:
-
работы системы, в которой формализуется процесс выполнения программы, взаимодействие с пользователем и данными;
-
программ (или иначе блок-схем), в которых формализуется алгоритм обработки данных;
-
данных, в которых уточняются потоки данных между процессами и (или) носителями данных;
-
взаимодействия программ, отображающих путь активации программ и взаимодействий с данными;
-
ресурсов системы, отображающих конфигурацию блоков данных и обрабатывающих блоков, требуемую для решения задачи или набора задач.
Правила оформления схем описаны в ГОСТ 19.701-90 и /3/. Краткое описание схем приведено в разделе “схемы+ символы” электронной версии курса лекций по дисциплине “технология программирования”.
Общие рекомендации к выполнению схем следующие:
-
схемы выполняются без соблюдения масштаба, действительное пространственное расположение составных частей изделия в схеме не учитывается или учитывается приближенно;
-
в схемах применяют условные графические обозначения: чаще всего прямоугольники или другие простые фигуры. Размеры условных графических обозначений и толщина составляющих их линий должны быть одинаковыми на всех схемах проекта;
-
допускается пропорциональное изменение условных графических обозначений;
-
условные графические обозначения составных частей узла устройства допускается изображать уменьшенными по сравнению с узлами;
-
линии связи и линии графических обозначений должны быть одной толщины. Рекомендуемая толщина линий – 0.3- 0.4 мм ( пределы изменения толщины – от 0.2 мм до 1.0 мм);
-
линии связи должны состоять из вертикальных и горизонтальных отрезков и иметь наименьшее число возможных изломов и точек пересечения.
Структура проектируемого программного продукта представляется в виде схемы деления изделия на составные части (ГОСТ 2.711-82). Линии связи выполняются со стрелками, направленными от комплектующих к узлам (снизу вверх), как показано на рисунке 3.3. Наименование изделия и его составных частей помещается внутри условного обозначения. Допускается данные о составных частях изделия помещать в таблице, расположенной под схемой деления.
Условных графические обозначения составных частей изделия приведены на рисунке 3.2.
В таблице 3.1 приведена таблица соответствия функций и разрабатываемых модулей для рассматриваемого нами примера разработки автоматизированной системы учета успеваемости.
а) новые б) покупные в) заимствованные
разрабатываемые изделия изделия или
изделия и составные
составные части
части
Рисунок 3.2 Условные графические обозначения составных частей изделия
Таблица 3.1 – Соответствие функций и реализующих их модулей
Наименование функции обработки информации |
Наименование модуля |
Автоматизация анализа успеваемости студентов |
USPEV |
Ввод информации об успеваемости |
VVOD |
Обработка информации об успеваемости |
ANALIZ |
Вывод результатов анализа |
REZ |
Ввод информации из зачетной ведомости |
ZACH_VED |
Корректировка информации об успеваемости |
KORR |
Получение итоговой ведомости успеваемости |
ITOG_VED |
Получение списков неуспевающих |
POLET |
Получение рейтинговой ведомости успеваемости |
REITING |
Ввод результатов экзаменов |
EKZ_VED |
Восстановление из архивных копий |
IZ_ARH |
Защита от несанкционированного. доступа |
SANKS |
Сохранение архивных. копий |
V_ARH |
Допустим, что модули восстановления из архивных копий, сохранения архивных копий и защиты от несанкционированного доступа разрабатывались ранее для другой АСОИ, но применимы и для вновь разрабатываемой системы анализа успеваемости. При этих условиях схема деления изделия на составные части будет выглядеть так, как показано на рисунке 3.3.
USPEV
VVOD ANALIZ REZ
ZACH_VED KORR ITOG_VED POLET
REITING
EKZ_VED
Рисунок 3.3 - Пример системной архитектуры
.
3.3 Таблицы решений как внешние спецификации функций программного обеспечения
Одной из основных задач этапа проектирования является разработка спецификаций функций ПО. Фактически спецификации являются описаниями алгоритмов соответствующих функций, но разработанными для пользователей ПО. Для этих целей существует достаточно много методов, которые перечислим в порядке увеличения трудности проектирования алгоритмов /2/:
- текстовое описание,
- структурированный естественный язык,
- таблица решений,
- дерево решений,
- визуальный язык,
- блок-схема,
- алгоритмический язык программирования.
Следует отметить, что в перечисленном выше порядке увеличивается степень формализации описания алгоритма и понимание деталей его функционирования проектировщиками и программистами, но уменьшается степень понимания алгоритма заказчиком и будущим пользователем ПО, для которого оно разрабатывается. Компромиссным решением проблемы понимания являются методы алгоритмизации, лежащие в середине спектра методов. Рассмотрим подробнее таблицу решений как вариант этого компромисса / 2/.
Проектирование спецификаций процессов с помощью таблиц решений (ТР) заключается в задании матрицы, отображающей множество входных условий и множество решений.
Таблица решений (ТР) – это такая внешняя спецификация ПО, в которой отражаются комбинации условий, выполняемых для входных данных, и соответствующие этим комбинациям действия по преобразованию информации.
Правила формирования ТР следующие. Таблица имеет 4 зоны: верхняя и нижняя, правая и левая. Верхняя левая зона ТР используется для описания условий, которым должны отвечать входные данные. Нижняя левая часть ТР используется для определения действий по преобразованию информации в программе. В верхней правой зоне отмечаются комбинации условий для входных данных, в нижней правой зоне отмечаются действия, выполняемые когда определенная комбинация условий для входных данных имеет место.
Верхняя часть таблицы используется для определения условий. Обычно условие является ЕСЛИ-частью оператора ЕСЛИ-ТО и требует ответа ‘да-нет’. Совокупность ответов ‘да-нет’ представляет собой комбинацию условий для входных данных.
Нижняя часть ТР используется для определения действий, т.е. ТО-части оператора ЕСЛИ-ТО и в ней указывается, какие конкретно действия и в какой последовательности выполняются, когда определенная комбинация условий имеет место.
Поясним сказанное на примере спецификации процесса выбора символов из входного потока по следующим правилам:
а) если очередной символ является управляющим, то подать звуковой сигнал и вернуть код ошибки;
б) если буфер формируемой строки заполнен, то подать звуковой сигнал и вернуть код ошибки;
в) если очередной символ не находится в заданном диапазоне, (положим, от ‘а’ до ‘я’), то подать звуковой сигнал и вернуть код ошибки;
г) иначе поместить символ в буфер, увеличить значение счетчика выбранных символов и вернуть новое значение счетчика.
Таблица решений для данного примера приведена ниже ( таблица 1.1).
Здесь ‘Д’ означает ‘да’, ‘Н’ - ‘нет’, 1,2 - помеченные действия выполняются в указанном порядке.
Таблица 1.1 - ТР для функции выбора символов из входного потока
Условия |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
С1 символ управляющий? |
Д |
Д |
Д |
Д |
Н |
Н |
Н |
Н |
С2 буфер заполнен? |
Д |
Д |
Н |
Н |
Д |
Д |
Н |
Н |
С3 символ от ‘a’ до ’я’? |
Д |
Н |
Д |
Н |
Д |
Н |
Д |
Н |
Действия |
|
|
|
|
|
|
|
|
D1 подать звуковой сигнал |
1 |
1 |
1 |
1 |
1 |
1 |
|
1 |
D2 вернуть код ошибки (>0) |
2 |
2 |
2 |
2 |
2 |
2 |
|
2 |
D3 увеличить значение счетчика и вернуть его |
|
|
|
|
|
|
2 |
|
D4 поместить символ в буфер |
|
|
|
|
|
|
1 |
|
Заметим, что если выполняется условие С1, то нет необходимости в проверке условий С2 и С3. Поэтому комбинации условий 1,2,3,4 могут быть заменены обобщающей комбинацией (Д, -, -), где ‘-’ означает любую из возможных альтернатив (в данном случае Д или Н).
Аналогично комбинации условий 5 и 6 могут быть заменены обобщающей комбинацией (Н, Д, -). Редуцированная таким образом ТР будет иметь вид таблицы 1.2.
Таблица 1.2 Редуцированная ТР
Условия |
1 |
2 |
3 |
4 |
С1 символ управляющий? |
Д |
Н |
Н |
Н |
С2 буфер заполнен? |
- |
Д |
Н |
Н |
С3 символ от ‘a’ до ’я’? |
- |
- |
Д |
Н |
Действия |
|
|
|
|
D1 подать звуковой сигнал |
1 |
1 |
|
1 |
D2 вернуть код ошибки (>0) |
2 |
2 |
|
2 |
D3 увеличить значение счетчика и вернуть его |
|
|
2 |
|
D4 поместить символ в буфер |
|
|
1 |
|
Методика построения ТР заключается в следующем:
а) определить все условия и действия в спецификации;
б) вписать действия и условия в таблицу;
в) в нумерованных столбцах отметить все возможные комбинации условий и выполняемых при выполнении условий действий;
г) при необходимости редуцировать таблицу (если есть 2 столбца, у которых перечень действий совпадает, и которые отличаются только результатами условий ‘Д’ и ‘Н’ в одной строке, то такие столбцы могут быть слиты в один).
Отметим, что на основе ТР легко осуществить кодирование программы на языке высокого уровня, таком, как Pascal.
В /4/ приведен пример разработки таблиц решений для задачи совместной обработки двух файлов.