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



Главная

Новости
 Новости науки
 Важное
 Почетные доктора
 Инновации
 Культура
 Люди
 Разное
 Скартел-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 | >> ]

3. Достоинства предлагаемого варианта технологии

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

  • в отличие от объектного моделирования [7, 9], во-первых, построение всех основных моделей основано на применении только автоматной терминологии, а во-вторых, используется динамическая модель только одного типа - система взаимосвязанных автоматов;
  • применение такой динамической модели позволяет эффективно описывать и реализовывать задачи рассматриваемого класса даже при большой их размерности. Применение графов переходов в качестве языка спецификаций алгоритмов делает обозримым даже весьма сложное поведение программы и позволяет легко вносить изменения как в спецификацию, так и в ее реализацию;
  • совместное рассмотрение схемы связей автомата и его графа переходов позволяет понимать этот граф, а совместное рассмотрение этого графа и изоморфной ему подпрограммы позволяет понимать эту подпрограмму;
  • подробное документирование проекта создания программного обеспечения позволяет при необходимости вносить изменения в него через длительный срок после его выпуска, в том числе специалистами, не участвовавшими в проектировании;
  • без использования объектно-ориентированного подхода программа четко разделяется на две части - системонезависимую и системозависимую;
  • при проектировании системонезависимой части программы детали реализации входных и выходных воздействий скрыты. Они раскрываются только при реализации системозависимой части программы;
  • этапы проектирования и реализации системонезависимой части программы полностью разделены;
  • реализация входных переменных и выходных воздействий в виде функций обеспечивает: их протоколирование, простоту перехода от одних типов источников и приемников информации к другим, наличие действующего макета программы [12] в любой момент времени после начала реализации системозависимой части;
  • упорядоченное хранение функций, реализующих входные переменные и выходные воздействия, упрощает внесение изменений;
  • для кодирования любого числа состояний автомата используется только одна внутренняя переменная, что обеспечивает наблюдаемость поведения автомата за счет "слежения" за изменениями значений только этой переменной. Для системы из N автоматов "слежение" выполняется по N многозначным переменным, значения каждой из которых выводятся на "отладочный" экран, представленный в форме, определяемой схемой взаимодействия автоматов;
  • каждый граф переходов формально и изоморфно реализуется по шаблону в виде подпрограммы на выбранном языке программирования. Указанный изоморфизм позволяет при необходимости решить обратную задачу [9] - однозначно восстановить граф переходов по этой подпрограмме;
  • системонезависимая часть программы имеет регулярную структуру и, следовательно, легко читается и корректируется;
  • системонезависимая часть программы зависит только от наличия компилятора или интерпретатора выбранного языка программирования на используемой платформе. При смене аппаратуры или переносе программы под другую операционную систему необходимо изменить только системозависимую часть;
  • автоматическое ведение протокола в терминах спецификации обеспечивает возможность сертификации программы. При этом демонстрируется соответствие функционирования программы "поведению" системы взаимосвязанных графов переходов для рассматриваемых событий при выбранных значениях входных переменных. Это достигается за счет сопоставления "полного" протокола со спецификацией. Совокупность "полных" протоколов обеспечивает возможность сертификации программы в целом. Для сертификации в терминах, понятных Заказчику, могут применяться "короткие" протоколы, которые можно использовать также и в качестве фрагментов методики проверки функционирования системы. При этом отметим, что из двух групп понятий "объект - алгоритм" и "алгоритм - программа" сертификация обычно связывается только со второй группой понятий;
  • "короткий" протокол позволяет определить наличие ошибки в выдаче выходных воздействий, а "полный" - определить автомат, который при этом необходимо откорректировать. Поэтому "короткие" протоколы могут быть названы "проверяющими", а "полные" - "диагностирующими";
  • возможность автоматического получения "полных" протоколов в терминах автоматов показывает, что система взаимосвязанных графов переходов, используемая для спецификации алгоритмов, является не "картинкой", а математической моделью;
  • несмотря на достаточно высокую трудоемкость проведения "подробной" сертификации при применении предлагаемых протоколов, этот способ существенно более конструктивен, чем другие подходы, например изложенные в [13], так как "постепенно среди теоретиков программирования сложилось представление, что множество протоколов лучше характеризует программу, нежели сам исходный программный текст" [14];
  • порождаемый некоторыми событиями протокол или его часть является соответствующим сценарием. Таким образом, сценарий строится автоматически при анализе программы, а не вручную при ее синтезе, как это предлагается делать при других подходах [7, 9]. Ручное построение всей совокупности сценариев и формальный синтез системонезависимой части программы по ним для задач со сложной логикой практически не осуществимы;
  • предлагаемый подход не исключает интерактивной отладки и сертификации;
  • поведение системы взаимосвязанных автоматов является разновидностью коллективного поведения автоматов [15] и может использоваться при построении "многоагентных систем, состоящих из реактивных агентов" [16].

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



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