Монография2009

51

Рисунок 29. Отображение блок-схемы программы в системе ГРАФКОНТ Блок-схемы алгоритмов стали основой также для их дальнейшей модификации и усовершенствования, в частности, при их приведении к некоторым эргономическим требованиям (запрет разрывов и блоковсоединителей и некоторых других конструкций), добавлении был получен графический язык ДРАКОН, являющийся одной из важнейших частей технологии разработки БПО «Графит-Флокс» в Центре автоматики и приборостроения им. Пилюгина.

7.2. Технология графосимволического программирования ГРАФ

На кафедрах информационных систем и технологий и программных систем Самарского государственного аэрокосмического университета была создана и развивается технология так называемого графосимволического программирования (ГСП) ГРАФ [16], использующая для описания программ

52

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

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

Графическая модель программы строится в технологии ГРАФ с использованием некоторого исходного базиса, «строительного материала». В качестве такового выступают две категории: базовые модули и типы данных. Базовые модули представляют собой перечень локальных вычислимых функций, на основе которых в конечном итоге порождаются все объекты технологии ГРАФ - акторы, агрегаты и предикаты. Типы данных описывают семантический аспект строения данных, обрабатываемых базовыми функциями. Как формулируют авторы языка (А.Н. Коварцев), «если вкладывать в понятие программирование традиционный смысл, то в графосимволическом программировании оно начинается на этапе конструирования новых граф-программ из имеющегося набора вычислимых функций, точно так же, как программы, написанные на алгоритмических языках программирования, составляются из конечного набора операторов языка».

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

В технологии ГРАФ основными программными единицами являются объекты. По способу порождения и функциональному назначению различаются три типа объектов: акторы, агрегаты и предикаты. При этом они действуют в рамках некоторой «предметной области программирования».

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

53

Рисунок 30. Пример графической программы в технологии ГРАФ Так, в теории газотурбинных двигателей перечень параметров, их

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

Программирование в рамках технологии ГРАФ начинается с формирования так называемого «словаря данных» предметной области программирования, который служит целям каталогизации данных, спецификации их семантики и областей значений. Словарь данных представляет собой таблицу, в которой каждому данному задается уникальное имя, тип, начальное значение и краткий комментарий его роли в предметной области. Технология ГРАФ имеет четкие стандарты описания и документирования программных модулей, представления и поддержки информационного обеспечения предметной области. Таким образом, для каждой предметной области строится единая информационная среда, позволяющая унифицировать проектирование написание программных модулей разными разработчиками.

54

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

Информационный интерфейс базовых модулей представляет собой отношение, устанавливающее связь между типами данных базового модуля (формальными параметрами), и данными предметной области. В результате установления связи порождаются новые объекта либо акторы, либо предикаты. Это отношение в технологии ГРАФ формируется "паспортизацией" типов данных базовых модулей. В этом смысле оно совместно с базовым модулем определяет понятие актора или предиката.

Структура автоматически компилируемого текста объекта-агрегата достаточно проста. Текст программы состоит из стандартного для всех объектов заголовка, структур данных, описывающих граф-программы, и обращения к стандартной программе – «граф-машине» [16]. С помощью компилятора языка Си текст агрегата компилируется в объектный модуль и помещается в библиотеку объектных модулей предметной области. Особенностью используемого способа построения межмодульного информационного интерфейса является то, что формируемые (автоматически) программные коды и информационные связи не зависят друг от друга. Модификация любого из объектов (актора, предиката или агрегата) не требует переделки кодов других объектов, входящих в предметную область. Более того, на самом деле при порождении акторов, предикатов или агрегатов никаких программных конструкций, описывающих информационный интерфейс, для них не создается. Акторы и предикаты на данном этапе - это лишь "фантомные" конструкции, не имеющие текстов программ, а описанные в виде "паспортов" в информационном фонде предметной области программирования.

7.3. Диаграммы деятельности и активностей в UML

Язык UML имеет несколько видов диаграмм, предназначенных для описания динамических аспектов систем, что соответствует общему представлению о том, что поведение может рассматриваться в нескольких аспектах. Поведение системы как смена состояний отражается в диаграмме конечных автоматов (состояний) языка UML (см. главу 6), взаимодействие объектов – в диаграммах последовательностей и взаимодействия. Наконец, поведение может характеризоваться некоторой последовательностью действий, исполняемых элементами, входящими в состав системы [31]. В такой постановке задача описания системы становится очень близкой задаче описания потока управления (control flow) в алгоритме. Вместе с тем, следует отметить, что предназначение диаграммы деятельности в языке UML более широкое, она позволяет описывать не только процесс исполнения некоторой программы с помощью ЭВМ, но и в широком смысле выполнение бизнес-

55

процессов в некоторой организации, причем ряд процессов может протекать параллельно.

Надо отметить, что по сравнению с диаграммами активностей предыдущих версий языка UML в версии UML 2.0 данный вид диаграмм претерпел ряд существенных изменений [31,32]. Например, вместо семантики конечных автоматов для моделирования деятельности в качестве базового используется механизм, подобный сетям Петри, что позволяет рассматривать дополнительно потоки объектов и данных. Отметим, что это изменение можно рассматривать, как недостаточно оправданное с точки зрения концептуальной чистоты усложнение. Фактически оно частично превращает диаграммы деятельности языка UML 2.0 в диаграммы потоков данных. Чрезмерная громоздкость и сложность языка UML 2.0 вызывает в настоящее время многочисленную критику [39]. Кроме того, на нотацию UML 2.0 оказала влияние нотация моделирования бизнес-процессов BPMN, что привело к горизонтальной ориентации диаграммы деятельности в UML 2.0 по сравнению с вертикальной ориентацией в языке UML 1.4.

Рисунок 31. Основные графические примитивы диаграмм деятельности UML

2.0

Центральным аспектом моделирования деятельности в языке UML 2.0 является последовательность действий и условий их выполнения, а также поток объектов, которые являются необходимыми для выполнения отдельных действий или являются их результатами. На рисунке 32 представлен пример диаграммы деятельности UML 1.4

56

Рисунок 32. Пример диаграммы деятельности UML

Действие (action) представляет собой в UML элементарную единицу спецификации поведения, которая не может быть далее декомпозирована в форме деятельности.

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

Особенностями диаграммы деятельности UML является наличие узлов синхронизации (разветвлений и соединений) потоков. Еще одной важной возможностью является вложенность деятельностей, т.е. некоторое действие может быть декомпозировано с помощью вспомогательной диаграммы деятельности, существуют также графические примитивы отображения вызова деятельности. Имеются символы передачи сигнала и приема события, что роднит (в том числе благодаря такому же внешнему виду), UML 2.0 с языком SDL. Возможно также, например, задание специального вида деятельности – обработчика исключения, сопоставляемого в качестве запасного некоторому другому примитиву деятельности на диаграмме.

Язык UML в настоящее время является индустриальным стандартом при разработке информационных систем, и поддержан целым рядом инструментальных средств, среди которых можно назвать Rational Rose,

Borland Together, MagicDraw, Visual Paradigm, и др. Вариант Rational Rose

57

Real-time используется NASA, в частности, при создании программного обеспечения космического телескопа Вебба.

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

Рисунок 33. Диаграмма деятельности UML с «дорожками» в среде Rational

Rose

Кроме того, диаграммы деятельности, несмотря на богатые выразительные возможности в версии UML 2.0, не имеют средств для отражения параметров реального времени.

В связи с этим применение диаграмм деятельности UML в качестве средства графического программирования управляющих алгоритмов реального времени, в том числе - для БВС КА, не представляется целесообразным.

7.4. Язык потоковых диаграмм FC (Flow Chart) системы

IsaGraf

Многие производители инструментальных средств, поддерживающих стандарт МЭК 61131-3, не ограничиваются поддержкой языков стандарта.

58

Так, например, в популярный пакет IsaGraf включен язык FC (Flow Chart, или язык потоковых диаграмм). Программы на этом языке описываются в виде граф-схем алгоритмов (см. рисунок 34).

Рисунок 34. Графический язык Flow Chart системы IsaGraf

Язык FC, как видно из представленного примера, является типичным языком отражения потока управления (control flow), с несколько измененной по сравнению со стандартными блок-схемами системой обозначений. При этом в системе IsaGraf подразумевается использование языка FC совместно с языками стандарта МЭК 61131-3, в частности, конкретные действия, выполняемые блоками, описываются на языке ST.

7.5. Язык ДРАКОН и технология ГРАФИТ-ФЛОКС

Язык ДРАКОН разработан НПЦ автоматики и приборостроения имени Н.А. Пилюгина и Российской академией наук (Институт прикладной математики имени М.В. Келдыша) как обобщение опыта работ по созданию БПО космического корабля «Буран». На базе ДРАКОНА в НПЦ

59

АП построена автоматизированная технология проектирования программных систем под названием «ГРАФИТ-ФЛОКС» [26]. Данная технология была успешно использована в ряде космических проектов: «Морской старт», «Фрегат», «Протон-М» и др. Несмотря на «космическое» происхождение, авторами языка он активно популяризируется и декларируется его широкая применимость в самых разных сферах человеческой деятельности – от описания технологических процессов до обучения, что приводит к несколько спорным примерам (см. рисунок 35).

В языке ДРАКОН используются два типа элементов – графоэлементы и текстовые надписи (текстоэлементы). Графоэлементы языка ДРАКОН называются иконами, которые могут объединяться в составные иконы - макроиконы. Шампур-блок - часть ДРАКОН-схемы, имеющая один вход в верхней части диаграммы и один выход внизу, включающая элементы, расположенные на одной вертикали. «Ветки» - смысловые блоки, куски алгоритма, представляющие составной оператор языка ДРАКОН. С помощью веток удобно формализовать смысловое разбиение проблемы, программы или процесса на части и дать частям удобные смысловые названия.

Рисунок 35. Пример схемы на языке ДРАКОН Алгоритмическая часть описания программы на ДРАКОНЕ отделяется

от описания декларативного (в частности, структур данных). При практическом использовании в НПЦ АП имени Пилюгина помимо описания программы в среде ГРАФИТ используется описание на специальном языке ФЛОКС. Это делает при необходимости возможным создание гибридных визуальных языков программирования, например, ДРАКОН-ПАСКАЛЬ. В таких языках к визуальному синтаксису языка ДРАКОН по определенным правилам присоединяется текстовый синтаксис (например, языка Pascal).

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

60

являются программистами. Как пишет автор языка В.Д. Паронджанов, в технологии приближаются к принципу «программирования без программистов» [26]. Причина этого в том, что при решении практических прикладных задач специалисты по управлению бортовыми системами досконально владеют материалом и хорошо знают постановку задачи. В отличие от них программисты могут не владеть в достаточной степени «физикой» протекающих на борту КА процессов. Это позволяет значительно сократить издержки, ускорить ход работ и сократить число ошибок по принципу «испорченного телефона», вызванных взаимным непониманием между специалистами по управлению и программистами.

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

Говоря о возможной применимости языка ДРАКОН для решения задач создания БПО КА ДЗЗ, следует отметить следующее. В технологии разработки сложных комплексов управляющего ПО, в том числе – БПО КА ДЗЗ, подразумевается параллельное выполнение множества программ на борту под управлением операционной системы реального времени. При этом одна и та же управляющая программа может иметь несколько «входов», т.е. допускать многократное включение.

В языке ДРАКОН, несмотря на наличие операций реального времени, понятие «входа» не предусматривается. Это принципиальный момент, не позволяющий напрямую применить ее при создании БПО КА ДЗЗ.

Следует также отметить, что УА РВ могут выполнять различные по своей природе операции - выдача команд управления, занесение запросов на выполнение программ, формирования признаков в программной памяти, и др.

Эту особенность можно отразить и, задействуя на полную мощь возможности графического подхода, эффективно применить за счет использования разных по начертанию графических примитивов. ДРАКОН этого не предусматривает, для всех операций используется один и тот же графоэлемент - прямоугольник. Это затрудняет понимание логики УА РВ при его описании в нотации ДРАКОНА по сравнению, например, с нотацией, используемой в технологии ГРАФКОНТ [10].

Еще одним моментом, отличающим диаграммы ДРАКОНА, является строго вертикальная ориентация этих схем. В то же время, горизонтальная ориентация позволяет более четко отразить структуру управляющей программы, особенно во временном аспекте.