Монография2009

41

State1

Знак минус означает, что остаемся в том же состоянии, в котором были

Рисунок 22. Пример использования меток и таймера А. Н. Тереховым и его сотрудниками в Санкт-Петербургском

госуниверситете и компании «Ланит-Терком» на основе языка SDL была разработана автоматизированная технология разработки программ для телефонных станций RTST, дальнейшим развитием которой стала технология REAL [30].

На рисунке 23 представлен экран разработчика в технологической среде REAL.

Рисунок 23. Использование языка SDL в среде разработки программ REAL

42

Поведенческая диаграмма на языке SDL в этой технологии может быть автоматически конвертирована в исходный текст программы на алгоритмическом языке высокого уровня. Изначально это был Алгол-68, в более поздних версиях – С++ и Java. Кроме того, технология предусматривает использование таких инструментальных средств, как подсистема имитационного моделирования, отладчик, подсистема снятия и анализа трасс исполнения, и пр.

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

Несмотря на это, технология REAL обладает некоторыми особенностями, не позволяющими применять ее, в частности, при разработке БПО КА:

1)Системы связи ориентированы на асинхронный режим взаимодействия, когда программа на протяжении больших периодов времени находится в состоянии ожидания некоторых сигналов, являющихся одним из центральных понятий SDL, а УА РВ в космической отрасли в основном ориентированы на отработку заданной циклограммы полета, т.е. синхронный режим.

2)Как следствие, в технологии REAL отсутствует понятие «входа», являющееся центральным в дисциплине разработки УА РВ для КА.

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

4)В технологии REAL не предусматривается легкой перестройки (путем замены настроечных файлов) с одного целевого языка, на котором генерируется программа, на другой.

5)Генерация целевой программы на ассемблере БЦВМ не предусмотрена, изначально технология ориентировалась на генерацию программ на языках высокого уровня, что требует промежуточных стадий трансляции и отладки и затрудняет потенциальное внедрение и использование технологии.

6.2. Диаграммы состояний в UML

Как уже отмечалось, язык UML представляет собой комплексный графический язык, включающий в свой состав набор диаграмм [32]. В том

43

числе в него входит язык диаграмм состояний, иногда также называемый языком диаграмм конечных автоматов (statechart diagram). Диаграмма состояний позволяет специфицировать поведение моделируемой с помощью UML системы, наряду с такими диаграммами, как диаграммы деятельности, последовательности, кооперации и реального времени. В отличие от них, диаграмма состояний концентрируется на изменении состояний конкретного отдельно взятого объекта. Диаграмма состояний UML по существу является графовой моделью конечного автомата. Для диаграмм состояний UML характерно допущение вложенности, т. е. могут образовываться иерархические состояния для более детального представления отдельных аспектов модели.

Сложную структуру в диаграммах состояний UML могут иметь и отдельные состояния (в которые могут «вкладываться» подсостояния).

На рисунке 24 показан пример statechart-диаграммы языка UML

Рисунок 24. Пример диаграммы состояний языка UML

Говоря о statechart-диаграммах и других диаграммах UML, предназначенных для описания поведения, следует отметить, что в настоящее время в основном UML применяется как язык спецификации (upper или middle CASE), без выхода на этап генерации исполняемого программного кода. Только некоторые из существующих UML-средств средств дают возможность автоматически генерировать код логики программы по диаграммам состояний. Можно считать, что в настоящее время указанная функциональность существует в «зачаточном состоянии» [31], так как известные инструменты не позволяют в полной мере эффективно связывать модель поведения, которую можно описывать с помощью четырех типов диаграмм (состояний, деятельностей, кооперации или последовательностей), с генерируемым кодом. Это во многом определяется отсутствием в языке UML формального однозначного описания операционной семантики для поведенческих диаграмм.

44

6.3. Языки Grafcet и SFC (МЭК61131-1)

Набор стандартов международной электротехнической комиссии МЭК 61131-3 включает в свой состав графический язык, ориентированный на состояния – SFC (Sequential Function Chart), который, как и другие языки стандарта, предназначен для программирования промышленных контроллеров и широко используется в SCADA/HMI пакетах. Язык входит в состав программного обеспечения программируемых логических контроллеров, выпускаемых ведущими в области автоматизации фирмами мира. Так, например, фирма "Сименс" обеспечивает возможность написания программ для своих программируемых логических контроллеров с помощью языка STEP-5 (языки инструкций, лестничных и функциональных схем), а также языка S7-GRAF. Язык SFC используется совместно с другими языками стандарта (обычно с ST и IL) и является графическим языком, в котором программа описывается в виде последовательности шагов, объединенных переходами. Язык SFC использует концепцию, близкую к концепции конечного автомата, что делает его одним из самых мощных языков программирования стандарта МЭК 61131-3. Пример программы на языке SFC приведен на рисунке 25.

↓

START Переход на начальное состояние

Рисунок 25. Графическая программа на языке SFC

Однако языку SFC присущ ряд недостатков. Наиболее простым и естественным образом на языке SFC описываются технологические процессы, состоящие из последовательно выполняемых шагов с возможностью описания нескольких параллельно выполняющихся процессов, для чего в языке имеются специальные символы разветвления и слияния потоков (дивергенции и конвергенции, в терминах стандарта МЭК 61131-3). При организации слияния потоков возможно возникновение ряда трудноустранимых ошибок. Например, язык допускает переход из шага, находящегося внутри «скобок» слияния и разветвления наружу, при этом

45

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

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

Вообще, несмотря на то, что язык SFC может быть использован для моделирования конечных автоматов, его математическая модель соответствует не конечному автомату, а является близкой к ординарной сети Петри. Это связано с тем, что текущее состояние программы определяется не переменной состояния, а набором флагов активности каждого шага, в связи с чем при недостаточном контроле со стороны программиста могут оказаться одновременно активными несколько шагов, не находящихся в параллельных потоках. Можно в этой связи отметить, что язык SFC создан на базе языка Grafcet [35]. Этот графический язык, разработанный в Центре космических исследований в Тулузе (Франция), применяется в настоящее время наряду с другими языками такими фирмами как, например, "Телемеханик" (Франция), "Сименс" (Германия), "Ален Бредли" (США), "Тошиба" (Япония), "Омрон" (Япония). Созданы трансляторы с этого языка по крайней мере указанными выше фирмами для своих управляющих вычислительных устройств. Одно из достоинств диаграмм "Графсет" состоит в стандартизации их изображения. При этом диаграммы преимущественно располагаются в направлении сверху вниз. Нарушает при этом целостность восприятия то, что переход, идущий в обратном направлении, изображается в неявной форме в виде стрелки с номером состояния, в которое осуществляется переход. Вообще вертикальная ориентация является существенным недостатком для любого графического языка [34], так как для целостного (гештальтного) восприятия "картин" человеком более целесообразно их плоскостное изображение (как это имеет место в графах переходов), которое позволяет по этой причине отображать алгоритмы более компактно.

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

46

Рисунок 26. Графическая диаграмма языка Графсет (Grafcet)

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

48

конечных автоматов. Компоненты, разделяемые пунктирной линией, выполняются параллельно.

Автоматы могут взаимодействовать между собой посредством событий. Выходные события одного автомата могут быть входными событиями для другого автомата. Язык Argos позволяет задать область видимости локального события. В состояние автомата может быть вложена подсистема. На рис. 27приведена программа, демонстрирующая вложение подсистем. Переключение режимов осуществляется событием e0. До первого события e0 подсистема Sampling находится в состоянии Sampling2. При получении события e0 эта подсистема переходит в состояние Sampling4. В этот момент создается подсистема Sampling4 и запускается в своем начальном состоянии InitialState2. При повторном получении события e0 подсистема Sampling4 уничтожается и подсистема Sampling переходит в состояние Sampling2.

49

7. Языки описания потока управления (CONTROL FLOW)

Поскольку целью настоящего отчёта является исследование средств графического программирования, потенциально пригодных для описания УА РВ, применяемых для управления БА КА, среди описываемых графических языков и средств программирования языки, сконцентрированные на описании потока управления (control flow), и родственные им языки описания потоков работ (workflow), заслуживают особого внимания.

7.1. Графические схемы (блок-схемы) алгоритмов и программ

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

Блок-схемы алгоритмов и программ были достаточно быстро стандартизированы, имеются как международный, так и российский стандарты (ISO 5807-85, ГОСТ 19.003-80, ГОСТ 19.701-90) [23].

Теоретической основой графического языка блок-схем служит управляющий граф программы. Схема отражает порядок исполнения отдельных операторов (действий) в программе, которые отображаются с помощью набора стандартизированных графических примитивов, как показано на рисунке 28. Процесс, или действие отображается с помощью прямоугольника, решение (ветвление потока управления в зависимости от истинности или ложности логического условия) – с помощью ромба. Передача управления отображается с помощью линий (стрелок). Имеются специальные символы для отображения начала и конца алгоритма. Блоксхемы вертикально ориентированы, что может затруднять их восприятие и манипулирование с ними. Надо отметить, что ГОСТ 19.701-90 предусматривает средства и для отображения параллельных ветвей алгоритма и параллельно выполняемых процессов. Более того, как описано в стандарте, он может применяться и для описания процессов, выполняемых людьми, т.е. в современном понимании – бизнес-процессов организации и протекающих в ней потоков работ (workflow).

50

Рисунок 28. Базовые графические примитивы блок-схем алгоритмов и программ

Следует отметить, что возможности стандарта ГОСТ 19.701-90 вообще достаточно широки, он предусматривает средства для графического описания не только схем программ (т.е. фактически потока управления – controlflow), но и схемы данных, схемы работы системы, схемы взаимодействия программ и схемы ресурсов автоматизированной системы.

Как уже отмечалось, нотация графических блок-схем программ поддерживается большим количеством инструментальных средств. В частности, система ГРАФКОНТ, созданная в СГАУ и НТЦ «Наука», г. Самара, по заказу ГНПРКЦ «ЦСКБ-Прогресс» [10], позволяет отображать графически программу, наряду с другими представления, и в виде ее блоксхемы, что отражено на рисунке 29.