ГЛАВА 4

МЕТОДЫ ЗАДАНИЯ СПЕЦИФИКАЦИЙ ПРОЦЕССОВ

Спецификация процесса (СП) используется для описания функционирования процесса в случае отсутствия необходимости детализировать его с помощью DFD (т.е. если он достаточно невелик, и его описание может занимать до одной страницы текста). Фактически СП представляют собой алгоритмы описания задач, выполняемых процессами: множество всех СП является полной спецификацией системы. СП содержат номер и/или имя процесса, списки входных и выходных данных и тело (описание) процесса, являющееся спецификацией алгоритма или операции, трансформирующей входные потоки данных в выходные. Известно большое число разнообразных методов, позволяющих задать тело процесса, соответствующий язык может варьироваться от структурированного естественного языка или псевдокода до визуальных языков проектирования (типа FLOW-форм и диаграмм Насси-Шнейдермана) и формальных компьютерных языков.

Независимо от используемой нотации спецификация процесса должна начинаться с ключевого слова (например, @СПЕЦПРОЦ). Требуемые входные и выходные данные должны быть специфицированы следующим образом:

@ВХОД = <имя символа данных>
@ВЫХОД = <имя символа данных>
@ВХОДВЫХОД = <имя символа данных>,
где <имя символа данных> - соответствующее имя из словаря данных.

Эти ключевые слова должны использоваться перед определением СП, например,

@ВХОД = СЛОВА ПАМЯТИ
@ВЫХОД = ХРАНИМЫЕ ЗНАЧЕНИЯ
@СПЕЦПРОЦ
Для всех СЛОВ ПАМЯТИ выполнить:
Распечатать ХРАНИМЫЕ ЗНАЧЕНИЯ
@

Ситуация, когда символ данных является одновременно входным и выходным, может быть описана двумя способами: либо символ описывается два раза с помощью @ВХОД и @ВЫХОД, либо один раз с помощью @ВХОДВЫХОД.

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

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

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

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

4.1. Структурированный естественный язык

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

В состав языка входят следующие основные символы:

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

Управляющие структуры языка имеют один вход и один выход. К ним относятся:

1) последовательная конструкция:
ВЫПОЛНИТЬ функция1
ВЫПОЛНИТЬ функция2
ВЫПОЛНИТЬ функция3

2) конструкция выбора:
ЕСЛИ <условие> ТО
ВЫПОЛНИТЬ функция1
ИНАЧЕ
ВЫПОЛНИТЬ функция2
КОНЕЦЕСЛИ

3) итерация:
ДЛЯ <условие>
ВЫПОЛНИТЬ функция
КОНЕЦДЛЯ
или
ПОКА <условие>
ВЫПОЛНИТЬ функция
КОНЕЦПОКА

При использовании структурированного естественного языка приняты следующие соглашения:

1. Логика процесса выражается в виде комбинации последовательных конструкций, конструкций выбора и итераций.
2. Ключевые слова ЕСЛИ, ВЫПОЛНИТЬ, ИНАЧЕ и т.д. должны быть написаны заглавными буквами.
3. Слова или фразы, определенные в словаре данных, должны быть написаны заглавными буквами.
4. Глаголы должны быть активными, недвусмысленными и ориентированными на целевое действие (заполнить, вычислить, извлечь, а не модернизировать, обработать).
5. Логика процесса должна быть выражена четко и недвусмысленно.

Ниже приведен пример спецификации процесса 1 (ПОЛУЧИТЬ ПАРОЛЬ) для диаграммы, изображенной на рис. 2.8.

@ВХОД = ВВЕДЕННЫЙ ПАРОЛЬ
@ВХОД = ПАРОЛЬ
@ВЫХОД = СООБЩЕНИЕ
@ВЫХОД = КОРРЕКТНЫЙ ПАРОЛЬ
@СПЕЦПРОЦ 1.1 ПОЛУЧИТЬ ПАРОЛЬ
ВЫПОЛНИТЬ выдать СООБЩЕНИЕ клиенту,
                          запрашивающее ввод пароля
                          принять ВВЕДЕННЫЙ ПАРОЛЬ
ДОТЕХПОРПОКА ВВЕДЕННЫЙ ПАРОЛЬ = ПАРОЛЬ
                          или были сделаны три попытки ввода
КОНЕЦВЫПОЛНИТЬ
ВЫПОЛНИТЬ установить флаг КОРРЕКТНЫЙ
                         ПАРОЛЬ в случае равенства
@ КОНЕЦ СПЕЦИФИКАЦИИ ПРОЦЕССА 1.1

4.2. Таблицы и деревья решений

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

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

ТР состоит из двух частей. Верхняя часть таблицы используется для определения условий. Обычно условие является ЕСЛИ-частью оператора ЕСЛИ-ТО и требует ответа "да-нет". Однако иногда в условии может присутствовать и ограниченное множество значений, например, ЯВЛЯЕТСЯ ЛИ ДЛИНА СТРОКИ БОЛЬШЕЙ, МЕНЬШЕЙ ИЛИ РАВНОЙ ГРАНИЧНОМУ ЗНАЧЕНИЮ?

Нижняя часть ТР используется для определения действий, т.е. ТО-части оператора ЕСЛИ-ТО. Так, в конструкции

ЕСЛИ ИДЕТ ДОЖДЬ ТО РАСКРЫТЬ ЗОНТ
ИДЕТ ДОЖДЬ является условием, а РАСКРЫТЬ ЗОНТ - действием.

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

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

1) если очередной символ является управляющим, то подать звуковой сигнал и вернуть код ошибки;
2) если буфер формируемой строки заполнен, то подать звуковой сигнал и вернуть код ошибки;
3) если очередной символ не находится в заданном диапазоне, то подать звуковой сигнал и вернуть код ошибки;
4) иначе поместить символ в буфер, увеличить значение счетчика выбранных символов и вернуть новое значение счетчика.
Таблица решений для данного примера выглядит следующим образом (таблица 4.1):

Таблица 4.1

Заметим, что если выполняется условие C1, то нет необходимости в проверке условий C2 и C3. Поэтому комбинации условий 1, 2, 3, 4 могут быть заменены обобщающей комбинацией (Д,-,-), где "-" означает любую из возможных альтернатив (в данном случае, Д или Н). Аналогично, комбинации условий 5 и 6 могут быть заменены обобщающей комбинацией (Н,Д,-). Редуцированная таким образом таблица решений будет иметь следующий вид (таблица 4.2):

Таблица 4.2

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

IF (isctrl(c)) { beep(); return(ERROR) }
   ELSE {
   IF (i>max_length) { beep(); return(ERROR) }
   ELSE {
   IF (out_of_range(c)) { beep(); return(ERROR) }
   ELSE { putchar(c); return(++i) }
   }
   }

Построение ТР рекомендуется осуществлять по следующим шагам:

1. Идентифицировать все условия (или переменные) в спецификации. Идентифицировать все значения, которые каждая переменная может иметь.
2. Вычислить число комбинаций условий. Если все условия являются бинарными, то существует 2**N комбинаций N переменных.
3. Идентифицировать каждое из возможных действий, которые могут вызываться в спецификации.
4. Построить пустую таблицу, включающую все возможные условия и действия, а также номера комбинаций условий.
5. Выписать и занести в таблицу все возможные комбинации условий.
6. Редуцировать комбинации условий.
7. Проверить каждую комбинацию условий и идентифицировать соответствующие выполняемые действия.
8. Выделить комбинации условий, для которых спецификация не указывает список выполняемых действий.
9. Обсудить построенную таблицу.

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

Рис. 4.1. Дерево решений

Обычно ДР используется при малом числе действий и когда не все комбинации условий возможны, а ТР - при большом числе действий и когда возможно большинство комбинаций условий.
Рекламная пауза!

4.3. Визуальные языки проектирования спецификаций

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

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

Символы FLOW-форм приведены на рис. 4.2. Каждый символ является блоком обработки. Каждый прямоугольник внутри любого символа также представляет собой блок обработки.

Рис. 4.2. Символы FLOW-форм.

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

Рис. 4.3. Пример FLOW-формы

Рис. 4.4. Диаграмма Насси-Шнейдермана.

Дальнейшее развитие FLOW-формы получили в диаграммах Насси-Шнейдермана. На этих диаграммах символы последовательной обработки и цикла изображаются также, как и соответствующие символы FLOW-форм. В символах условного выбора и case-выбора собственно условие располагается в верхнем треугольнике, выбираемые варианты - на нижних сторонах треугольника, а блоки обработки - под выбираемыми вариантами. Диаграмма Насси-Шнейдермана для вышеприведенного примера изображена на рис. 4.4.

4.4. Сравнение методов

Спектр методов задания спецификаций процессов в соответствии с увеличением трудности их проектирования приведен на рис 4.5. Наиболее трудным методом задания СП являются языки программирования (C, COBOL, FORTRAN и др.). Сложность заключается в том, что языки программирования концентрируют внимание на деталях реализации, а потоки данных в DFD представляются абстрактно (их фактическая композиция определяется в словаре данных). Поэтому сложность - не в написании СП, а в их синхронизации и согласовании с DFD, поскольку при редактировании DFD, вообще говоря, должны корректироваться и спецификации процессов.

Рис. 4.5. Спектр методов задания спецификаций процессов

Перечислим некоторые положительные и отрицательные стороны рассмотренных методов задания СП.

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

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

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

4.5. Спецификации процессов для примера банковской задачи

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

1) Спецификация процесса 1.1 приведена в 4.1.
2) Спецификация процесса 1.2.

@ВХОД = ЛИМИТ ДЕНЕГ
@ВХОД = ЗАПРОС НА ОБСЛУЖИВАНИЕ
@ВЫХОД = ДЕНЕЖНАЯ СУММА
@ВЫХОД = СООБЩЕНИЕ
@ВЫХОД = ТРЕБУЕМОЕ ОБСЛУЖИВАНИЕ
@СПЕЦПРОЦ 1.2 ПОЛУЧИТЬ ЗАПРОС НА ОБСЛУЖИВАНИЕ
ВЫПОЛНИТЬ выдать СООБЩЕНИЕ клиенту по вводу запроса на обслуживание
принять ЗАПРОС НА ОБСЛУЖИВАНИЕ
обновить данные ТРЕБУЕМОЕ ОБСЛУЖИВАНИЕ (а именно,
ЗАПРОС ДОКУМЕНТАЦИИ, ЗАПРОС ДЕНЕГ,
ЗАПРОС БАЛАНСА, ЗАПРОС НА ОПЕРАЦИЮ)
ЕСЛИ был сделан ЗАПРОС ДЕНЕГ
ТО ВЫПОЛНИТЬ запросить ДЕНЕЖНУЮ СУММУ
выдать требуемую ДЕНЕЖНУЮ СУММУ с учетом того,
что она не должно превышать ЛИМИТ ДЕНЕГ
КОНЕЦЕСЛИ
ДОТЕХПОРПОКА запрашивается продолжение обслуживания
или не все обслуживание было выполнено
КОНЕЦВЫПОЛНИТЬ
@ КОНЕЦ СПЕЦИФИКАЦИИ ПРОЦЕССА 1.2

3) Спецификация процесса 1.3.
3.1) Спецификация процесса 1.3.1.

@ВХОД = ЗАПРОС ДОКУМЕНТАЦИИ
@ВХОД = ДЕТАЛИ КЛИЕНТА
@ВЫХОД = ОБРАБОТАННАЯ ДОКУМЕНТАЦИЯ
@СПЕЦПРОЦ 1.3.1 ОБРАБОТАТЬ ДОКУМЕНТАЦИЮ БАНКА
По получении ЗАПРОСА ДОКУМЕНТАЦИИ выдать ОБРАБОТАННУЮ ДОКУМЕНТАЦИЮ,
содержащую ДЕТАЛИ КЛИЕНТА, КОМПЬЮТЕРУ БАНКА
@КОНЕЦ СПЕЦИФИКАЦИИ ПРОЦЕССА 1.3.1

3.2) Спецификация процесса 1.3.2.

@ВХОД = ДАННЫЕ ПО БАЛАНСУ
@ВХОД = ЗАПРОС БАЛАНСА
@ВХОД = ДЕТАЛИ КЛИЕНТА
@ВЫХОД = ДАННЫЕ ПО ИСТОРИИ ЗАПРОСА
@ВЫХОД = ВЫПИСКА ПО БАЛАНСУ
@СПЕЦПРОЦ 1.3.2 РАСПЕЧАТАТЬ БАЛАНС КЛИЕНТА
По получении ЗАПРОСА БАЛАНСА выдать ДАННЫЕ ПО ИСТОРИИ ЗАПРОСА
Затем выдать ВЫПИСКУ ПО БАЛАНСУ, содержащую ДАННЫЕ ПО БАЛАНСУ@ КОНЕЦ СПЕЦИФИКАЦИИ ПРОЦЕССА 1.3.2

3.3) Спецификация процесса 1.3.3.

@ВХОД = ДЕНЕЖНАЯ СУММА
@ВХОД = ЗАПРОС ДЕНЕГ
@ВХОД = ДЕТАЛИ КЛИЕНТА
@ВЫХОД = ДЕНЬГИ
@ВЫХОД = ВЫПИСКА О ДЕНЬГАХ
@ВЫХОД = ДЕНЕЖНАЯ СУММА
@СПЕЦПРОЦ 1.3.3 ПРИГОТОВИТЬ ДЕНЬГИ ДЛЯ КЛИЕНТА
По получении ЗАПРОСА ДЕНЕГ выдать ДЕНЬГИ по значению ДЕНЕЖНОЙ СУММЫ
Выдать ВЫПИСКУ О ДЕНЬГАХ, содержащую ДЕНЕЖНУЮ СУММУ
Передать КОМПЬЮТЕРУ БАНКА информацию о ДЕНЕЖНОЙ СУММЕ
@ КОНЕЦ СПЕЦИФИКАЦИИ ПРОЦЕССА 1.3.3

3.4) Спецификация процесса 1.3.4.

@ВХОД = ДАННЫЕ ПО СЧЕТУ
@ВХОД = ЗАПРОС НА ОПЕРАЦИЮ
@ВХОД = ДЕТАЛИ КЛИЕНТА
@ВЫХОД = ДАНННЫЕ ПО ИСТОРИИ ЗАПРОСА
@ВЫХОД = ВЫПИСКА ПО ОПЕРАЦИИ
@СПЕЦПРОЦ 1.3.4 РАСПЕЧАТАТЬ ОПЕРАЦИЮ КЛИЕНТА
получении ЗАПРОСА НА ОПЕРАЦИЮ выдать ДАННЫЕ ПО ИСТОРИИ ЗАПРОСА для
специфицирования ДЕТАЛЕЙ КЛИЕНТА, чтобы получить текущие ДАННЫЕ ПО СЧЕТУ
Выдать ВЫПИСКУ ПО ОПЕРАЦИИ, содержащую ДАННЫЕ ПО СЧЕТУ
@ КОНЕЦ СПЕЦИФИКАЦИИ ПРОЦЕССА 1.3.4

4) Спецификация процесса 1.4.

@ВХОД = УДАЛЕННАЯ КРЕДИТНАЯ КАРТА
@ВХОДВЫХОД = КРЕДИТНАЯ КАРТА
@ВЫХОД = ДАННЫЕ КРЕДИТНОЙ КАРТЫ
@ВЫХОД = ВВЕДЕННАЯ КРЕДИТНАЯ КАРТА
@СПЕЦПРОЦ 1.4 ОБРАБОТАТЬ КРЕДИТНУЮ КАРТУ
ВЫПОЛНИТЬ считать КРЕДИТНУЮ КАРТУ
записать в хранилище ДАННЫЕ КРЕДИТНОЙ КАРТЫ
выдать управляющий поток ВВЕДЕННАЯ КРЕДИТНАЯ КАРТА
по получении управляющего потока УДАЛЕННАЯ КРЕДИТНАЯ КАРТА удалить
КРЕДИТНУЮ КАРТУ
@ КОНЕЦ СПЕЦИФИКАЦИИ ПРОЦЕССА 1.4

Продолжение статьи