УНИВЕРСИТЕТ ИТМО
Кафедра «Технологии программирования»



Главная

Новости
 Новости науки
 Важное
 Почетные доктора
 Инновации
 Культура
 Люди
 Разное
 Скартел-Yota
 Стрим
 Смольный
Учебный процесс
 Образование
 Дипломы
 Курсовые проекты
 Лабораторные работы
 Учебные курсы
 Визуализаторы
 Unimod-проекты
 Семинары
 Стипендии
Наука
 События и факты
 Госконтракты
 Статьи
 Диссертации
 Книги
 Презентации
 Свидетельства
 Сотрудничество
Исследования
 Автоматы
 Верификация
 Биоинформатика
 Искусственный интеллект
 Генетические алгоритмы
 Движение
 UniMod
 Роботы и агенты
 Нейронные сети
 ФЦП ИТМО-Аалто
 Разное

О нас
 Премии
 Сертификаты и дипломы
 Соревнования по программированию
 Прорыв
 Автографы
 Рецензии

Беллетристика
 Мотивация
 Мысли
Медиа
 Видео
 Фотографии
 Аудио
 Интервью

English
 Home

 Articles
 Posters
 Automata-Based Programming
 Initiatives
 Projects
 Presentations
 UniMod
 UniMod Projects
 Visualizers


Поиск по сайту

Яndex



   Главная / Статьи / SWITCH-технология — автоматный подход к созданию программного обеспечения «реактивных» систем (версия для печати)


SWITCH-технология — автоматный подход к созданию программного обеспечения «реактивных» систем



[ << | 1 | 2 | 3 | 4 | Литература | Приложение 1 | Приложение 2 | Приложение 3 | >> ]

2. Особенности предлагаемого варианта технологии

Предлагаемый вариант технологии характеризуется следующими особенностями:

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

Рис. 1 (полномасштабное изображение в отдельном окне)

  • на этапе изучения предметной области на основе технического задания, которое при автоматизации технологических процессов обычно выдается Заказчиком в словесной форме в виде совокупности сценариев и случаев использования [9], строится структурная схема системы, позволяющая получить общее представление об организации управления, применяемой аппаратуре и интерфейсе объекта управления;
  • на этапе анализа на основе технического задания выделяются сущности, каждая из которых называется автоматом (например, автомат управления насосом или автомат контроля температуры);
  • состояния каждого автомата первоначально определяются по выделенным состояниям объекта управления или его части, а при большом их количестве - по алгоритму управления, построенному в другой нотации (например, в виде схемы алгоритма [10]);
  • в автоматы также могут быть введены и другие состояния, связанные, например, с неправильными действиями Оператора;
  • каждый автомат при необходимости может быть декомпозирован;
  • итеративный процесс анализа может выполняться многократно и завершается созданием перечня автоматов и перечня состояний для каждого автомата;
  • на этапе проектирования в отличие от традиционного программирования вводится подэтап - кодирование состояний автомата. При этом в каждом автомате для различия состояний применяется многозначный код, в качестве комбинаций которого вводятся десятичные номера состояний;
  • автоматы взаимодействуют за счет обмена номерами состояний, вложенности и вызываемости. Они также могут быть одновременно вложенными и вызываемыми;
  • строится схема взаимодействия автоматов, отражающая указанные типы взаимодействий. Она формализует систему взаимодействующих автоматов. Эта схема заменяет в предлагаемой технологии диаграмму объектов и частично диаграмму взаимодействий (диаграмму кооперации), которые применяются в объектном моделировании [9]. Пример схемы взаимодействия автоматов приведен на рис.2;

Рис. 2 (полномасштабное изображение в отдельном окне)

  • входные воздействия разделяются на события, действующие кратковременно, и входные переменные, вводимые путем опроса;
  • входные воздействия целесообразно реализовывать в виде входных переменных, а применять события - для сокращения времени реакции системы. При этом одно и то же входное воздействие может быть одновременно представлено и событием и входной переменной;
  • прерывания обрабатываются операционной системой и передаются программе в виде сообщений, а после этого обрабатываются как события с помощью соответствующих обработчиков;
  • некоторые входные переменные могут формироваться в результате сравнения входных аналоговых сигналов с уставками;
  • номера состояний других автоматов, с которыми автомат взаимодействует за счет обмена, также могут рассматриваются в качестве его входных воздействий;
  • все выходные воздействия являются действиями, а не деятельностями [9];
  • группы входных и выходных воздействий связываются с состояниями, выделенными для каждого автомата;
  • связи каждого автомата с его "окружением" формализуются схемой связей автомата, предназначенной для полного описания интерфейса автомата. В этой схеме приводятся источники и приемники информации, полные названия всех воздействий и их обозначения, а также информация о том, в какой автомат он вложен и какие автоматы вложены в него. Пример схемы связей автомата приведен на рис.3;

Рис. 3 (полномасштабное изображение в отдельном окне)

  • имя автомата начинается с символа A, имя события - с символа e (от английского слова event - событие), имя входной переменной - с символа x, имя переменной состояния автомата - с символа y, а имя выходного воздействия - с символа z. После каждого из указанных символов следует номер соответствующего автомата или воздействия;
  • система взаимосвязанных автоматов образует системонезависимую (например, от операционной системы) часть программы, которая реализует алгоритм функционирования системы управления;
  • реализация входных переменных, обработчиков событий, выходных воздействий, вспомогательных модулей и пользовательских интерфейсов образует системозависимую часть программы;
  • если составляющая системозависимой части программы спроектирована как автомат (например, автомат разбора файла рекомендаций Оператору), то он также может быть введен в схему взаимодействия автоматов;
  • если платформа не изменяется, то вспомогательные модули могут быть использованы повторно, как образцы [9];
  • запуск автоматов может производиться как из системозависимой части программы (например, из обработчиков событий), так и из системонезависимой части;
  • вложенные автоматы последовательно запускаются с передачей "текущего" события в соответствии с путем в схеме взаимодействия автоматов, определяемым их состояниями в момент запуска головного автомата. При этом последовательность запуска и завершения работы автоматов напоминает алгоритм поиска в глубину [11];
  • вызываемые автоматы запускаются из выходных воздействий с передачей соответствующих "внутренних" событий;
  • автоматы могут запускаться однократно с передачей какого-либо события или многократно (в цикле) с передачей одного и того же события;
  • при реализации системы учтено, что функции, реализующие автоматы, не реентерабельны (не допускают повторного запуска до их завершения);
  • каждый автомат при запуске выполняет не более одного перехода;
  • после обработки очередного события автомат сохраняет свое состояние и "засыпает" до появления следующего события;
  • дуги и петли графов переходов помечаются произвольными логическими формулами, которые могут содержать входные переменные и предикаты, проверяющие номера состояний других автоматов и номера событий;
  • дуги и петли кроме условий переходов могут содержать список последовательно выполняемых выходных воздействий;
  • вершины в графах переходов практически всегда являются устойчивыми и содержат петли. Если на петле не выполняются выходные воздействия, то она умалчивается. В противном случае, в явном виде изображаются одна или несколько петель, каждая из которых помечена по крайней мере выходными воздействиями;
  • вершина графа переходов может содержать список последовательно запускаемых вложенных автоматов и список последовательно выполняемых выходных воздействий;
  • для обобщения "одинаковых" исходящих дуг в каждом графе переходов допускается объединение вершин в группы. Также допускается слияние входящих в вершину дуг в одну линию;
  • каждый граф переходов проверяется на достижимость, непротиворечивость, полноту и отсутствие генерирующих контуров;
  • этап завершается построением графа переходов для каждого автомата, совокупность которых образует систему взаимосвязанных автоматов. Пример графа переходов, соответствующий схеме связей, представленной на рис.3, приведен на рис. 4. Для хранения состояний этого автомата используется переменная y0, которая принимает девять значений (от 0 до 8);

Рис. 4 (полномасштабное изображение в отдельном окне)

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

Рис. 5 (полномасштабное изображение в отдельном окне)

  • каждый граф переходов формально и изоморфно реализуется отдельной функцией (подпрограммой), создаваемой по шаблону (Приложение 1), содержащему две конструкции switch и оператор if. Первая конструкция switch вызывает вложенные автоматы и реализует переходы и действия на дугах и петлях. Оператор if проверяет, изменилось ли состояние, и если оно изменилось, вторая конструкция switch активизирует вложенные автоматы и реализует действия в новой вершине. Пример функции, реализующей автомат, представленный на рис.4, приведен в Приложении 2;
  • в общем случае для активизации автоматов, вложенных в новое состояние, они вызываются с событием e0;
  • после реализации графа переходов текст подпрограммы должен корректироваться для обеспечения бесповторности опроса входных переменных, помечающих дуги, исходящие из одного состояния. Таким образом, решается проблема "риска" [1];
  • каждая входная переменная и каждое выходное воздействие также реализуется функцией, что позволяет применять SWITCH-технологию не только для решения задач логического управления;
  • имена функций и переменных, используемых при реализации автоматов, совпадают с обозначениями, применяемыми в схемах связей автоматов и графах переходов. Например, переменная, в которой хранится номер произошедшего события, имеет имя e;
  • все функции, реализующие входные переменные, записываются в порядке возрастания их номеров в один файл, а реализующие выходные воздействия - в другой;
  • функции, реализующие автоматы, входные переменные и выходные воздействия, содержат вызовы функций для обеспечения протоколирования;
  • этап завершается построением структурной схемы разработанного программного обеспечения, отражающей взаимодействие его частей (рис.6). Эта схема может включать схему взаимодействия автоматов, которая при этом отдельно не выпускается;

Рис. 6 (полномасштабное изображение в отдельном окне)

  • на этапе отладки обеспечена возможность одновременной индикации значений переменных состояний всех автоматов на одном экране;
  • на этапе сертификации за счет введения вызовов функций протоколирования в функции автоматов, входных и выходных воздействий обеспечено автоматическое ведение протокола (история реакции на событие). В нем указываются события, запуск автоматов, их состояния в момент запуска, переходы в новые состояния, завершение работы автоматов, значения входных переменных, выходные воздействия и время начала выполнения каждого из них. Кроме "полного" протокола также автоматически строится "короткий" протокол, в котором фиксируются только события и инициируемые ими выходные воздействия, интересующие Заказчика. Примеры "полного" и "короткого" протоколов для одного из событий, обрабатываемого системой взаимодействующих автоматов (рис.2), при выбранных значениях входных переменных, приведены в Приложении 3;
  • сообщения в "полном" протоколе о запуске и завершении реализации каждого автомата играют роль скобок, логически выделяющих разные уровни вложенности автоматов;
  • на этапе документирования для точного оформления результатов проектирования и разработки программы предлагается создавать и сдавать в архив документацию
    (по крайней мере в электронном виде), имеющую как минимум следующую комплектность: структурная схема системы; схема разработанного программного обеспечения; распечатки экранов пользовательских интерфейсов; перечни событий, входных переменных и выходных воздействий; диаграмма взаимодействия автоматов; описание нотации, используемой в графах переходов; шаблон для реализации графов переходов смешанных автоматов произвольного уровня вложенности; для каждого автомата: словесное описание (фрагмент технического задания), рассматриваемое в качестве комментария, схема связей автомата, граф переходов и исходный текст функции, реализующей автомат; алгоритмы, например в виде графов переходов, и исходные тексты вспомогательных модулей и функций, реализующих входные переменные, обработчики событий и выходные воздействия; протоколы для сертификации программы, выполняющие роль контрольных примеров [12]; руководство программиста; руководство пользователя;
  • изложенный вариант технологии может использоваться и при построении модели объекта управления, для которой должен создаваться аналогичный комплект документации;
  • после этого, при появлении любых изменений, возникающих в ходе дальнейших этапов жизненного цикла программы, весь комплект документации (по завершении каждого этапа) должен корректироваться. Для этого составляется перечень исполняемых модулей программы, в котором для каждого из них указывается значение циклической контрольной суммы, отражающей любое изменение в нем. При этом Контролер по документации должен знать значение этой суммы для исходного файла, и после завершения каждого этапа при любом изменении указанного значения требовать представления извещения на выполненную модификацию, по которому документация должна быть комплектно откорректирована и сдана в архив.

[ << | 1 | 2 | 3 | 4 | Литература | Приложение 1 | Приложение 2 | Приложение 3 | >> ]



© 2002—2024 По техническим вопросам сайта: alexvatyan@gmail.com