Проектирование программ

1. По словесному описанию поведения системы строится набор управляющих состояний.

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

3. Входным переменным автомата сопоставляются запросы: булевы функции или (реже) двоичные переменные. Выходным переменным сопоставляются команды: процедуры. Если упомянутые подпрограммы являются недостаточно простыми для непосредственной реализации, для каждой из них производится цикл традиционного проектирования сверху вниз.

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

Для примера рассмотрим, как применить этот метод для проектирования программного эмулятора часов с будильником, рассмотренных выше.

1. Из словесного описания поведения часов можно заключить, что они ведут себя по-разному в зависимости от того, включен или выключен будильник. Кроме того, у часов есть режим установки времени будильника. Следовательно, в данной системе целесообразно выделить три управляющих состояния: «1. Будильник выключен», «2. Установка времени будильника», «3. Будильник включен» (рис. 2.3).

Управляющие состояния эмулятора часов с будильником

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

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

2. В данном случае целесообразно спроектировать событийную систему. Автомат будет обрабатывать три события, соответствующие нажатию трех различных кнопок. На графе переходов (рис. 2.4) для обозначения событий используются названия кнопок. Переходы между состояниями осуществляются по нажатию кнопки «A». При нажатии других кнопок («H» и «M») переходов между состояниями не происходит, но выполняются соответствующие действия (изменение текущего времени или времени срабатывания будильника). Эти действия обозначим выходными переменными z1–z4.

Управляющий автомат эмулятора часов с будильником

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

3. Выходным переменным автомата, введенным на предыдущем шаге, сопоставим команды: z1 – «увеличить число часов текущего времени», z2 – «увеличить число минут текущего времени», z3 – «увеличить число часов времени срабатывания будильника», z4 – «увеличить число минут времени срабатывания будильника».

4. Наконец, введем четыре целочисленные переменные: «число часов», «число минут», «число часов будильника», «число минут будильника». Таким образом, совокупность значений текущего времени и времени срабатывания будильника определяет текущее вычислительное состояние системы.

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

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

Изложенный метод проектирования имеет ряд преимуществ перед традиционной функциональной декомпозицией сверху вниз. Помимо общих достоинств, характерных для любого «автоматного» метода (таких как наглядное представление логики сложного поведения), явное выделение состояний попутно привело к частичному решению основных проблем традиционного процедурного программирования. Один из основных недостатков метода сверху вниз состоит в том, что при проектировании в первую очередь задается вопрос «Что делает система?»

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

Дата добавления: 2015-05-26