Теоретические сведения

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

1.     Требования к ПС (Определение требований);

2.   Спецификация качества ПС;

3.     Функциональная спецификация ПС.

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

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

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

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

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

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

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

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

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

В первой части ФС необходимо описать:

1.     формат команд, посылаемых прибору;

2.     формат данных, принимаемых от прибора в различных режимах;

информация о работе с каналом ввода – вывода.

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

В первой части ПС необходимо описать:

3.     графическое представление экрана и графических объектов, отображаемых на нём в различных режимах;

4.     данные для построения изображения;

5.     данные  предоставляемые в текстовом режиме:

Пример 4 В требованиях  к ПС задан источник входных данных – протоколы ответов студентов на тестовые вопросы.

В первой части ПС необходимо описать:

1.     как структурированы данные (например каждый протокол в отдельном файле);

2.     где могут быть расположены эти файлы в файловой системе;

3.     формат данных в файле протокола.

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

Пример 5: Необходимо пополнить базу, содержащую количество правильных и неправильных ответов, данных студентами на каждый из вопросов тестовых заданий. (см. пример   2).

Во второй части ФС данную функцию можно представить как:

Функция I: UPDATEBASE

входные данные (см. первую часть ФС, пример2):

N файлов, имеющих расширение txt и содержащих текстовую информацию в следующем формате:

незначащий заголовок M строк;

наименование набора тестовых вопросов – строковый тип – QTITLE;

число вопросов – целочисленная переменная, строковый тип – QNUMBER;

для каждого вопроса: – текст тестового задания – строковый тип – QTEXT;

отметка об ответе: ПРАВИЛЬНО, НЕПРАВИЛЬНО, НЕОТВЕЧЕН – строковый тип QMARK;

выходные данные создаваемые или пополняемые функцией UPDATEBASE:

1.     Файл базы данных создаваемый ПС BASE.db - текстовый файл содержащий  L записей формата:   д набора текстовых вопросов BKOD – целочисленный;

       текст тестового вопроса BTEXT – строковый;

       число правильных ответов BTRUE – целочисленный;

       число неправильных ответов BFALSE – целочисленный;

       число вопросов без ответа BNOTRESP – целочисленный.

2       Файл наименований текстовых вопросов TITLES.db -  текстовый файл содержащий  P строк – названий наборов тестов.

3       Файл протокола обновления базы – текстовый файл UPDATE.LOG, в каждой строке которого фиксируется событие EVENT время и дату события TIMEDATE и дополнительно для некоторых событий – значение параметра PARAMETR. Разделителем является символ “:”.

Определены следующие события:

 -  START. Начало работы с программой – без параметра;

 -  STOP. Завершение программы – число обработанных протоколов SEANSNUMBER;

 -  QPROCEED. Обработан протокол – имя файла проотоколаFILENAME;

 -  QUESTIONADD. Новый вопрос добавлен в базу BASE.db - BKOD:BTEXT;

 -  TITLEADD. Заголовок тестового задания добавлен в базу TITLE.db;

 - DATAERROR. Ошибка чтения/записи/доступа носителя информации – имя файла операция с которым вызвала ошибку ERRORFILE

 - STRUCTERROR. Ошибка структуры файла протокола – имя файла операция с которым вызвала ошибку ERRORFILE

Семантика функции UPDATEBASE может быть описана следующим образом:

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

 Из каждого протокола необходимо выделить:

-       Название тестового задания TITLE. Если это название не существует в базе TITLE.db, оно должно быть туда добавлено. Порядковый номер тестового задания в базе TITLE, запоминается для использования как QKOD.

-       Текст тестового вопроса QTEXT для совпадения в базе  BASE.db. При найденном совпадении  QTEXT и BTEXT значение одного из полей  BTRUE, BFALSE, BNOTRESP в зависимости от значения QMARK увеличивается на единицу. Если  совпадений не найдено, в базу BASE.db добавляется новая запись с кодом QKOD, и её поля модифицируются в соответствии с QMARK.

При выполнении обновления базы возникающие события фиксируются в файле протокола обновления (см. п.3).

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

Пример 5: Исключительные ситуации при выполнении ПС функции UPDATEBASE (см. пример 4):

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

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

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