Разработка методов и средств анализа и контроля диаграмматики

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ
федеральное государственное бюджетное образовательное учреждение
высшего профессионального образования
«УЛЬЯНОВСКИЙ ГОСУДАРСТВЕННЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ»
На правах рукописи
Гайнуллин Ринат Фаязович
РАЗРАБОТКА МЕТОДОВ И СРЕДСТВ АНАЛИЗА И
КОНТРОЛЯ ДИАГРАММАТИКИ БИЗНЕС-ПРОЦЕССОВ В
ПРОЕКТИРОВАНИИ АВТОМАТИЗИРОВАННЫХ
СИСТЕМ
Специальность: 05.13.12 –
Системы автоматизации проектирования (промышленность)
ДИССЕРТАЦИЯ
на соискание ученой степени кандидата технических наук
Научный руководитель:
доктор технических наук,
профессор кафедры
«Вычислительная техника»
Афанасьев Александр Николаевич
Ульяновск – 2014 г.
2
Принятые сокращения и обозначения ..................................................... 4
Введение ...................................................................................................... 5
Глава 1. Использование и реализация диаграмматических
нотаций бизнес-процессов в проектировании АС............................ 11
1.1 Место и роль диаграмматических моделей бизнес-процессов в
проектировании АС ........................................................................ 11
1.2 Анализ использования диаграмматических нотаций бизнеспроцессов в методологиях проектировании АС ............................. 21
1.3 Анализ методов контроля диаграмматических спецификаций в
процессе проектирования бизнес-процессов .................................. 32
1.4 Анализ систем разработки диаграмматических спецификаций
бизнес-процессов нотации UML ..................................................... 47
1.5 Постановка задачи........................................................................... 55
1.6 Выводы............................................................................................ 56
Глава 2. Разработка методов синтаксического и семантического
анализа и контроля диаграмматики нотаций бизнес-процессов,
созданных в процессе коллективного проектирования. ................. 59
2.1 Обзор методов многоуровневых описаний ..................................... 59
2.2 Разработка метода описания многоуровневых грамматик анализа
диаграмматических нотаций, созданных в процессе коллективного
проектирования............................................................................... 61
2.3 Оценка временных затрат многоуровневых грамматик .................. 73
2.4 Анализ методов построения онтологий .......................................... 78
2.5 Анализ языков описания онтологий................................................ 82
2.6 Исследование алгоритмов объединения онтологий ........................ 86
2.7 Разработка метода анализа и контроля семантических ошибок
диаграмм при коллективном проектировании ................................ 92
3
2.8 Выводы............................................................................................ 99
Глава 3. Разработка метода синтеза RV-грамматик и алгоритма
нейтрализации ошибок грамматики диаграммных нотаций
бизнес-процессов ................................................................................101
3.1 Инструментальные средства метатрансляции................................102
3.2 Разработка структуры метакомпилятора диаграмматических
нотаций бизнес-процессов на примере языка UML ......................105
3.3 Анализ методов нейтрализации ошибок в диаграмматических
нотациях бизнес-процессов............................................................116
3.4 Разработка метода нейтрализации в графических грамматиках ....125
3.5 Разработка алгоритма формирования множества продолжателей .127
3.6 Типы диагностируемых ошибок ....................................................129
3.7 Выводы...........................................................................................136
Глава 4. Разработка программных средств реализации анализа и
контроля диаграмматическх нотаций бизнес-процессов ...............138
4.1 Разработка анализатора графических нотаций для системы
вопросно- ответного проектирования WIQA .................................138
4.2 Разработка плагина для редактора Microsoft Visio.........................143
4.3 Разработка сетевых систем анализ диаграмматики бизнеспроцессов .......................................................................................149
4.4 Проведение эксперимента ..............................................................156
4.5 Выводы и рекомендации ................................................................157
Заключение ..............................................................................................159
Список литературы .................................................................................160
4
Принятые сокращения и обозначения
ARIS – Architecture of Integrated Information Systems
BPMN – Business Process Model and Notation
CASE-средства – Computer-Aided Software Engineering - средства
DSL – domain-specific language
EPC – Event-driven Process Chain
IDEF – Integration Definition Metodology
OCL – Object Constraint Language
RUP – Rational Unified Process
АС – автоматизированные системы
ГОСТ – Государственный стандарт
5
Введение
Актуальность темы. Подход к проектированию и реинжинирингу
автоматизированных систем (АС), в основу которого положено системное
представление
организации и функционирования АС в виде бизнес -
процессов, является в настоящее время одним из эффективных и активно
применяемых на практике.
Под
понятием
повторяющуюся
«бизнес-процесс»
последовательность
понимают
комплексов
регулярно
мероприятий,
направленных на удовлетворение потребностей потребителя с целью
извлечения полезных эффектов.
Для
представления
и обработки бизнес-процессов
широкое
распространение получили средства диаграмматики, использующие
графические нотации языков UML , IDEF, BPMN, DFD, ER-диаграмм и
других.
Практика
диаграмматики
проектирования
значительно
АС
показала,
повышает
что
использование
эффективность
процесса
проектирования и качество создаваемых систем за счет унификации языка
взаимодействия
участников
процесса
создания
АС,
строгого
документирования проектно-архитектурных, функциональных решений и
формального контроля корректности диаграммных нотаций.
Наиболее распространенным диаграмматическим инструментом,
используемым на всех этапах создания АС, является язык UML. Однако в
современной теории и практике применения UML-диаграмматики в
проектировании АС наблюдается слабое развитие методов и средств
анализа и контроля корректности проектируемых диаграмм. Отсутствуют
средства
контроля
корректности
семантической
согласованности
диаграммных нотаций в процессе коллективного проектирования. Данные
факты открывают дополнительный источник трудно диагностируемых и
6
«дорогих» ошибок в создании АС, их анализ и контроль является
актуальной научно-технической задачей.
Целью диссертационной работы является расширение класса
диагностируемых ошибок в процессе проектирования АС за счет развития
и реализации методов и средств анализа и контроля диаграммных нотаций
бизнес-процессов, что позволяет сократить ошибки и время создания АС.
В соответствии с поставленной целью в работе формулируются и
решаются следующие задачи исследования.
1. Анализ существующих методов
контроля диаграмматических
нотаций бизнес-процессов в проектировании АС.
2. Анализ структурных особенностей диаграматики описания бизнеспроцессов. Разработка многоуровневой автоматной графической RVграмматики.
3. Анализ семантических особенностей графических нотаций бизнеспроцессов. Разработка метода контроля семантической целостности
комплекса диаграмм в процессе коллективного проектирования.
4. Анализ методов нейтрализации ошибок. Разработка алгоритма
формирования множества комплексов продукций-продолжателей для
автоматной графической RV-грамматики.
5. Анализ методов метакомпиляции. Разработка метода синтеза
таблицы автоматной графической RV-грамматики.
6. Разработка
программного
обеспечения,
позволяющего
производить эффективный анализ и контроль графических нотаций
бизнес-процессов в диаграмматике UML.
Объектом
исследования
является
применение диаграмматики
бизнес-процессов при разработке АС.
Предметом исследования являются модели, методы и средства
анализа и анализа и контроля
диаграмматики бизнес-процессов,
7
используемые
для
выявления
синтаксических (топологических) и
семантических ошибок.
Методы исследования основаны на использовании положений и
методов теории множеств, теории графов, теории автоматов, теории
формальных языков, теории графических языков, математической
лингвистики, теории искусственного интеллекта, а также использовании
основ системотехники и теории автоматизированного проектирования.
Научная
новизна определяется
разработанными методами и
средствами анализа и контроля диаграмматики бизнес-процессов, основу
которых составляют авторские графические грамматики. В результате
исследований получены следующие результаты.
1. Предложен новый метод анализа и контроля диаграмматических
нотаций бизнес-процессов на основе автоматных многоуровневых
графических
сабтерма,
RVM-грамматик,
учитывающий
отличающийся
комплексную
и
введением
понятия
иерархическую
природу
диаграмматических нотаций бизнес- процессов и позволяющий расширить
класс диагностируемых ошибок за счет возможности определения ошибок
распределенных по взаимосвязанным диаграммам.
2. Предложен новый метод анализа и контроля семантических
ошибок
диаграмматических
комплексной
диаграммы,
нотаций
бизнес-процессов
созданной в
в
составе
процессе коллективного
проектирования, на основе автоматных графических RV-грамматик,
отличающийся использованием графовой модели отношений понятий
семантической
текстовой
информации
диаграмм
и
позволяющий
расширить класс ошибок, диагностируемых в процессе проектирования
АС, и, тем самым, сократить время проектирования АС. Извлечение
семантической информации из диаграммных нотаций происходит при
помощи адаптированного метода лексико-синтаксических шаблонов.
8
3. Предложен новый метод синтеза автоматной графической RVграмматики, отличающийся оригинальностью текстовых правил описания
конструкций
диаграмматических
нотаций
бизнес-процессов,
ориентированных на использование в метакомпиляторе, обеспечивающих
полноту описания их особенностей и позволяющих автоматически
сформировать таблицу RV-грамматики, включая операции с внутренней
памятью.
4. Впервые
предложен
алгоритм
формирования
множества
комплексов продукций-продолжателей для автоматной графической RVграмматики, позволяющий эффективно продолжать анализ с минимальным
количеством
пропущенных
диаграмматической
нотации
термов
входного
бизнес-процесса,
предложения
что
повышает
производительность труда проектировщика и сокращает время разработки
АС.
Практическими результатами диссертационной работы являются.
1. Разработан анализатор диаграмматических моделей потоков
бизнес-процессов вопросно-ответной системы моделирования АС.
2. Разработан синтаксически-ориентированный анализатор UMLдиаграмм для MS Visio, позволяющий обнаруживать допущенные при
построении диаграмм синтаксические ошибки.
3. Разработана и реализована архитектура системы анализа и
контроля корректности диаграммных спецификаций бизнес-процессов,
предлагающая полный набор функциональности для анализа и контроля
синтаксических и семантических ошибок.
На защиту выносятся следующие новые и содержащие элементы
новизны основные положения:
1) метод анализа и контроля диаграмматики бизнес-процессов на
основе многоуровневых графических RVM-грамматик;
9
2) метод
анализа
и
контроля
семантических
ошибок
диаграмматических нотаций бизнес-процессов в составе комплексной
диаграммы;
3) метод синтеза автоматной графической RV-грамматики;
4) алгоритм
автоматического
формирования
комплексов-
продолжателей;
5) разработанные программные средства анализа и контроля
синтаксических и семантических ошибок.
Реализация и внедрение результатов работы. Работа выполнена в
рамках гранта РФФИ № 13-07-00483. Разработанные программные
средства внедрены в производственные процессы ФНЦП ОАО «НПО
«Марс» (г. Ульяновск), производственный процесс ООО «Эквид» (г.
Ульяновск),
учебный
процесс
Ульяновского
государственного
технического университета.
Апробация работы. Основные положения диссертационной работы
докладывались
и обсуждались
Всероссийских
конференциях: 9-ой и 10-ой международных научно–
технических
конференциях
на следующих международных
«Интерактивные
системы:
и
Проблемы
человеко–компьютерного взаимодействия / ИС-2011, ИС-2013», г.
Ульяновск, 2011 и 2013; III и VI международных научно-практических
конференциях «Объектные Системы-2011» и «Объектные Системы-2012»,
г. Шахты, 2011 и 2012; Всероссийских научно-технических конференциях
«Информатика и вычислительная техника», г. Ульяновск, 2010, 2011, 2012,
2013; Всероссийских школах-семинарах "Информатика, моделирование,
автоматизация проектирования", г. Ульяновск, 2010, 2011, 2012, 2013;
научно-практических конференциях профессорско-преподавательского
состава УлГТУ 2010, 2011, 2012, 2013.
10
Публикации. По теме диссертации опубликовано 21 печатная работа,
в том числе 3 в журналах списка ВАК. Получено 3 СВИДЕТЕЛЬСТВА
(РОСПАТЕНТ) об официальной регистрации программ для ЭВМ.
11
Глава 1.
Использование и реализация диаграмматических нотаций
бизнес-процессов в проектировании АС
Целью данной главы является исследование подходов и методов
проектирования бизнес-процессов в разработке АС. Рассматривается
структурная модель бизнес-процесса в разрезе проектирования АС.
Проведен анализ современных сред проектирования диаграммных
спецификаций и их возможностей по анализу и контролю различных
классов ошибок.
1.1 Место и роль диаграмматических моделей бизнес-процессов
в проектировании АС
Под бизнес-процессом в АС понимается устоявшийся алгоритм
действий, реализуемый исполнителем с потреблением входных ресурсов
(материальных
и/или
информационных),
создающий
ценность
и
направленный на получение стабильного результата [70,160,137,80]. Целью
разработки и моделирования бизнес-процессов является выявление
значимых аспектов деятельности, на автоматизацию которых направлена
проектируемая АС.
Проектирование АС с использованием подхода, основанного на
модельном представлении бизнес-процессов, производится в соответствии
со следующими этапами [79].
1. Выделение
одного
глобального
бизнес-процесса,
который
обуславливает деятельность всей системы.
2. Проведение
анализа
бизнес-процессов,
необходимых
для
функционирования глобального бизнес-процесса. Выделяется множество
более мелких процессов, которые обеспечивают исполнение глобального.
3. Ранжирование
выделенных
бизнес-процессов.
Обычно
производится анализ по критериям важность и проблематичность. Первый
критерий определяет место выделенного бизнес-процесса в общей картине
разработки. Это определяющий критерий очередности разработки.
12
Критерий
проблематичность
определяет
сложность
реализации
автоматизированной версии бизнес-процесса. После оценки затрат на
реализацию некоторые бизнес-процессы признаются нерентабельными к
автоматизации и исключаются из дальнейшего рассмотрения. Данный
критерий фактически является фильтром бизнес-процессов по критерию
реализуемости.
4. Непосредственно описание бизнес-процесса. Описание состоит из
выявления цели, окружения, функциональной структуры, различных
потоков, алгоритмов и организационной структуры бизнес-процесса. Цели
бизнес-процесса – это ценности или результаты, которые собираются
достигнуть исполнители, выполняя бизнес-процесс. Цели ставят для
оценки полученного результата и для задания общего курса работы.
Окружение бизнес-процесса –
это все множество внешних
элементов, с которыми взаимодействует бизнес-процесс как отдельная
единица. К окружению относятся входы и выходы бизнес-процесса, с
указанием поставщиков и потребителей. Поставщики могут быть как
внешними, так и внутренними. Для лучшего анализа рекомендуется
составить графическое представление как в примере на рис. 1.1.
5. Следующие два этапа традиционно выполняются совместно.
Выделяют структурные особенности бизнес-процесса и потоки внутри
процесса. Для анализа строят множество действий внутри бизнес-процесса
и определяют взаимосвязь их входов и выходов.
Построенная схема является базой для построения алгоритма бизнеспроцесса. На основе схемы строятся список ограничений на входы и
выходы действий. Определяются требования на качество и время
исполнения действия исполнителем.
13
Рис. 1.1. Схема бизнес-процесса
Таким образом, модельное представление АС в виде бизнеспроцессов обладает следующими особенностями:

бизнес-процессы имеют иерархическую структуру;

бизнес-процесс не изолированная система – каждый бизнес-
процесс функционирует в окружении, который определяет множество
входов и выходов бизнес-процесс;

у каждого бизнес-процесса есть «заказчик»;

у каждого бизнес-процесса есть «исполнитель».
После анализа основных потоков работ, используемых в мастер
технологии RUP, было выявлено использование понятия бизнес-процесса в
проектировании АС. Результаты анализа этапа «Деловое моделирование»
представлены в Приложении 1. На рис. 1.2 в качестве примера
представлено графическая интерпретация бизнес-процесса «Требование
участников системы». Бизнес-процесс определяет цели и направления
14
развития разрабатываемой АС и создается бизнес-аналитиком на ранних
этапах проектирования АС.
Рис. 1.2. Бизнес-процесс требования участников системы
В России основными регламентирующими документами на создание
АС являются ГОСТы 34 серии. В них определены все понятия, стадии
создания и другие важные аспекты создания АС. Рассмотрим некоторые их
ГОСТов 34 серии.
ГОСТ 34.003-90 [146] «Информационная технология. Комплекс
стандартов на автоматизированные системы. Термины и определения».
Данный документ определяет АС как систему, состоящую из персонала и
комплекса средств автоматизации его деятельности, реализующую
информационную технологию выполнения установленных функций.
Таким образом, АС состоит из персонала, комплекса средств и некой
деятельности, подлежащей автоматизации.
ГОСТ 34.601-90 [147] «Информационная технология. Комплекс
стандартов
на
автоматизированные
системы.
Автоматизированные
системы. Стадии создания» выделяет этапы создания АС от формирования
требований до ввода в эксплуатацию и сопровождение. Множество
15
методологий, реализующих разработку по ГОСТу, утверждают, что на
ранних этапах создания АС важным аспектом является разработка
графических спецификаций для описания конкретных частей системы.
Для разработки и исследования моделей бизнес-процессов в
процессе проектирования АС активно применяются диаграмматические
средства. Ниже исследуется наиболее значимые с практической точки
зрения методологии проектирования АС, использующиеся в качестве
основного методологического базиса диаграмматические представления
бизнес-процессов [151].
1. UML [36, 30, 33, 63] является развитием методологии Объектноориентированного анализа и проектирования (OOAD [69]), которая была
разработана в 80х-90х годах прошлого века.
UML описывает только
языковой компонент методологии, который является составной частью
большой методологии Rational Unify Process (RUP).
Рис. 1.3. Комплексная диаграмма UML
UML, как язык моделирования, состоит из множества графических
примитивов (нотация языка) и множества правил (синтаксиса и
семантики), которые определяются языком. Пример UML-диаграммы
16
приведен на рис. 1.3. Множество правил может быть классифицировано
следующим образом:
 группа
синтаксических
правил
–
определяет
варианты
правил
–
определяет
значение
использования;
 группа
семантических
графических примитивов, индивидуально и в контексте;
 группа прагматичных правил – рекомендации по тому, как
использовать язык.
2. Методология структурного анализа и проектирования (Structured
Analysis and Design Technique , SADT) [89, 152, 57] разработана в конце
шестидесятых годов двадцатого века, является первой методологией
основанной на концепциях полного системного моделирования. Процесс
системного моделирования состоит из нескольких этапов: получение
знаний в процессе опроса, документирование полученных знаний,
проверка корректности модели в процессе итеративного рецензирования.
Аналитик документирует полученные им знания о данной проблемной
области, выражая их в виде одной или нескольких SADT-диаграмм.
3. Методология IDEF (Integrated Computer-Aided Manufacturing)
базируется на методах SADT и включает в настоящее время 15 стандартов
[167, 58, 63]
IDEF0 [57] (рис.
1.4) рекомендуется для начальных стадий
проектирования АС. Диаграммы потоков бизнес-процессов этой методики
описывает
функциональное
взаимодействие
различных
частей
проектируемой системы.
Стандарты IDEF1 и IDEF1Х используются для проектирования баз
данных в терминах «сущность-связь». Данные нотации позволяют строить
реляционные модели в третьей нормальной форме.
17
IDEF3 описывает потоки данных внутри проектируемой АС.
Диаграммные спецификации данной методологии описывает причинноследственную связь происходящих процессов.
Стандарт IDEF4 предназначен для компонентного проектирования
клиент-серверных систем. Диаграммная спецификация используется для
описания
архитектурного
уровня,
статуса
артефактов
системы,
архитектурных моделей, ранжирования разработанных артефактов.
Стандарт
IDEF5
представляет
онтологическую
модель
проектируемой АС. Используется для описания объектов и концептов в
специфической области, через его семантическую взаимосвязь с другими
объектами.
Развитие BPR методов (Business Process Reengineering [20]) получило
в стандартах IDEF6, IDEF8, IDEF9 и IDEF14.
Стандарты IDEF7, IDEF 10, IDEF 11, IDEF 12, IDEF 13 разработаны
только частично.
Рис. 1.4. Диаграмма IDEF0
18
4. Event-driven process chains (EPC) [94, 61, 60] – графический язык
описания бизнес-процесса, разработанный Келлером и Шеер в 1992. Язык
разработан
для описания процессов на уровне их бизнес-логики, не
опускаясь до уточнения каждого события, и легок для понимания и
использования бизне-разработчиками.
EPC-диаграмма (рис. 1.5) состоит из следующих элементов:
 функции
–
основные
стандартные
блоки,
соответствуют
деятельности (задача, шаг процесса), которая должна быть выполнен.
 события – описывают ситуацию прежде и/или после того, как
функция будет выполнена. Функции связаны с событиями. Событие может
соответствовать выходному условию одной функция и предварительному
условие другой функции.
 логические соединители могут использоваться, чтобы соединить
действия и события. Существует три типа соединителей: ^ (и), XOR
(исключающий или) и _ (или).
Рис. 1.5. Диаграмма EPC
5. BPMN (Business Process Model and Notation) [106, 59, 96, 110] –
язык для описания исполняемых процессов внутри глобального бизнес -
19
процесса, включая различные комплексы действий, транзакции, движение
данных, параллельные процессы и операционную семантику. Язык
ориентирован на создание компьютерных систем, поэтому его описание
ориентировано на отображение реальных процессов на диаграммы
автоматизируемых процессов. В BPMN находят отражение такие важные
для автоматизации характеристики процесса как атомарность, контекст,
свойство, значения по умолчанию. Также нотация BPMN вводит понятия
более высокого уровня – расписание, транзакционность, компенсация и
корреляция свойств.
В конечном счете, BPMN – язык для описания «течения» бизнеспроцесса без относительно описания особенностей для человека. Сейчас
основой
разработки
транслирующий
BPMN-диаграмм
диаграммы
в
является
XML-описание,
автоматизации обработки диаграммы. На рис.
инструментарий,
для
дальнейшей
1.6 приводится пример
диаграммы BPMN.
Рис. 1.6. Диаграмма BPMN
20
Сравним различные нотации графических описаний бизнеспроцессов. Результат сравнения сведем в табл. 1.1
Таблица 1.1 Сравнение графических нотаций бизнес-процессов
UML
IDEF
EPC
BPMN
Средняя
Сложно
Легко
Средняя
Взаимосвязь
артефактов
Есть
Есть
Есть
Нет
Взаимосвязь
артефактов
разного
класса
Есть
Неявная
Нет (Классы
отсутствуют)
Нет
Возможна
Возможна
Очень
строгое
Строгое
Сложность
изучения
Совместная
работа
Формальное
описание
синтаксиса
Область
применения
Активно
Активно
используется используется
Не строгое
Строгое
Программное Программное
БизнесБизнесобеспечение обеспечение процессы +
процессы +
+ Бизнес+ БизнесПрограммное Программное
процессы
процессы
обеспечение обеспечение
Проанализировав таблицу, видно, что для проектирования АС на
основе анализа бизнес-процессов подходят нотации UML и IDEF. При
этом стоит отметить, что нестрогий синтаксис
UML открывает
дополнительные возможности совершить ошибки при использовании
данной технологии. Данный факт обуславливает выбор для анализа
именно языка UML.
21
1.2 Анализ использования диаграмматических нотаций бизнеспроцессов в методологиях проектировании АС [138]
В процессе разработки АС для достижения предсказуемого
результата используют некоторый набор практик и методов. ГОСТ 34.60190 [148] определяет 8 этапов разработки АС: формирование требований,
концептуальное проектирование,
разработка технического
задания,
эскизный проект, технический проект, разработка рабочей документации,
ввод в эксплуатацию, сопровождение. Для реализации каждого из этапов
используются одна из множества технологий проектирования АС. В
настоящее время основными мастер технологиями являются ARIS и RUP
[158,156,135].
ARIS [93, 91, 118, 19] - платформа основанная на рассмотрении
бизнес-процессов с пяти основных точек зрения:
 функциональный
анализ
–
моделирование
всех
функций
преобразующих входной поток в выходной;
 организационный анализ – описание организационной структуры
предприятия;
 анализ данных – описание входных и выходных данных,
ограничения, наложенные на них, и контекста, в котором происходит
операции с данными;
 анализ результатов деятельности – моделируются предполагаемые
результаты деятельности;
 контроль моделей – анализируются созданные ранее модели и
устраняются недочеты обнаруженные в процессе анализа.
Концепция фреймворка ARIS и жизненный цикл моделей ARIS
описывается диаграммой (рис. 1.7), называемой «Дом ARIS» или «ARIS
house» [92].
22
Рис. 1.7. Модель ARIS house
RUP – регламентированное описание этапов процесса создания
приложения.
RUP
обеспечивает регламентированный подход
к
исполнению задач и обязанностей в группе разработки. Его цель состоит в
том, чтобы гарантировать создание высококачественного программного
обеспечения,
которое
соответствует
потребностям
его
конечных
пользователей в рамках графика и бюджета [114, 15, 50].
RUP [44] разработана и поддерживается компанией Rational
Software. Группа разработчиков работает в постоянном тесном контакте с
клиентами, партнерами, промышленными группами, чтобы гарантировать,
что процесс непрерывно обновляется и улучшается, чтобы постоянно
вводить только лучшие современные практики разработки.
RUP
призывает
диаграмматические модели.
активно
создавать
и
поддерживать
Вместо создания большого количества
печатных документов, RUP поддерживает активное использование
23
моделей — семантически богатых представлений разрабатываемой
системы программного обеспечения [51, 14].
При исследовании вопроса моделей в RUP составлена следующую
схема взаимодействий моделей.
Узлы
схемы могут быть более
детализированы или отсутствовать в конечной реализации конкретной
сложной АС.
Рис. 1.8. Схема взаимодействия моделей методологии RUP
RUP различает три этапа разработки, где активно используется UML
[5]:
 бизнес-моделирование;
 составление требований;
 анализ и проектирование.
Рассмотрим применение диаграмматических моделей на каждом из
этих этапов разработки сложной АС и схему взаимодействия различных
моделей друг с другом.
24
Бизнес-моделирование
В RUP выделяются две основные модели в процессе бизнесмоделирования [45]:
 модель бизнес-вариантов использования, которая описывает
внешние взаимодействия организации с точки зрения бизнеса;
 модель бизнес-анализа, которая показывает, как предприятие ведет
себя внутренне, чтобы выявить все узлы предприятия и их взаимодействие.
На рис. 1.8 эти модели находятся на верхнем уровне, что говорит об
их основополагающем значении в процессе проектирования.
Модели
бизнес-вариантов
использования
определяют
взаимодействие бизнеса и окружения. В этом случае бизнес-процесс
рассматривается как черный ящик. Варианты бизнес-использования
описываются с точки зрения актора. Для делового агента «потребитель»
примером может быть вариант использования «заказать модуль», а для
«исполнителя» - «реализовать требования». Для описания бизнес-модели,
дополнением служат следующие диаграммы:
 диаграмма пакетов – большая модель делится на группу более
конкретных и представляется с помощью диаграммы пакетов;
 диаграмма вариантов использования – демонстрирует бизнесвозможности взаимодействий и связанных с ними акторов;
 диаграмма активности – показывает поток работ в зависимости от
некоторых событий в системе.
Аналитическая
бизнес-модель
описывает
внутреннее
функционирование бизнеса. Модель предназначена, чтобы разобрать
внутренние процессы при различных вариантах бизнес-использования.
Здесь анализируются бизнес-процессы и потоки операций. Также
моделируется организационная структура и потоки данных. Для анализа
используют следующие виды диаграмм:
25
 диаграмма классов описывает структуру организации и потоки
данных в ней. Бизнес-акторы – активные объекты: сотрудники и
информационные системы. Сущности – пассивные объекты: документы и
продукты;
 диаграмма активности – модель потока работ, фокусирующаяся на
действиях. Деловые рабочие – блоки схемы, содержащие действия.
Сущности – вход и выход этих действий;
 диаграмма взаимодействия – модель потока бизнес-процессов,
фокусирующаяся на обмене сообщениями между исполнителями или
контролерами бизнес-процессов;
 диаграмма конечного
автомата – иерархическое описание
некоторого бизнес-процесса.
Анализ требований
На основе построенной бизнес-модели делаются выводы о
требованиях и ограничениях к архитектуре создаваемой АС. Для анализа
требований
опирающаяся
используется
на
диаграмма
бизнес-модели.
вариантов
Эта
использования,
диаграмма
становится
основополагающей для остального процесса проектирования.
Модель варианта использования рекомендована для всех RUPпроектов. Эта модель формируется в процессе итеративного выполнения
трех основных операций:
1) описание участников – кто фактически работает с системой, с
точки зрения ролей использования;
2) идентификация самих вариантов использования – чего участники
хотят достигнуть при помощи системы;
3) определения отношения между вариантами использования и
каждым участником бизнес-процесса.
26
Участники часто идентифицируются на этапе бизнес-анализа как
потребители и поставщики. Они – те, кто использует систему, чтобы
автоматизировать выполнение их рабочих потребностей. Участник (агент)
может полностью соответствовать деловому агенту, в случае, если деловой
агент может получить доступ к системе непосредственно.
Согласно RUP, варианты использования могут быть получены из
бизнес-вариантов использования, но это - только возможно, если
соответствующий агент идентичен деловому агенту. Это не означает, что
есть
непосредственное
соответствие
между
бизнес-вариантами
использования и вариантами использования в разрезе анализа требований.
Большинство
практиков
RUP
пишет
уточнение
вариантов
использования только как текст на естественном языке. Это работает
хорошо. Но может также стать проблемой в последующем. При осознании,
что в процесс нужно внести корректировки, текстовое описание
превращается во множество громоздких ссылок на этапы процесса.
Поэтому на данном этапе рекомендовано составить диаграмму активности,
чтобы
наглядно
представить
потоки
бизнес-процессов
при
функционировании системы.
Этап анализа и проектирования дополняет модель еще пятью
сущностями:
 карту навигации;
 аналитическую модель;
 проектную модель;
 модель данных;
 модель развертывания.
Эти модели, в отличие от предыдущих, уже имеют непосредственное
отношение к разработке сложной АС. Рассмотрим их более подробно.
27
Карта навигации
RUP определяет, что в результате завершения модели Карта
навигаций будет получен Пользовательский интерфейс и внешний вид
системы. Эта карта основывается на вариантах использования и
показывает самые важные пути следования пользователя внутри системы.
Путь следования – последовательность экранов (окна, веб-страницы),
используемых пользователем при работе с системой. В RUP нет никаких
требований к описанию модели карта навигации. Чаще всего считают, что
UML не применим.
Некоторые разработчики пытаются использовать Схемы конечного
автомата UML. Исходят из следующего правила: Активный экран является
состоянием
пользовательского
интерфейса,
и
стрелки
перехода
показывают возможные пути навигации. Часто предполагается, что связь
между уровнями диаграммы двунаправленная, и пользователь всегда
может вернуться назад. Причина состоит в том, что карта не формальная,
машиночитаемая модель, а визуальное представление, предназначенное
чтобы передать структуру пользовательского интерфейса людям.
Карта навигации дополняет модель системы в RUP. Для больших
систем карта может быть очень сложной. Согласно RUP, необходимо
поместить все в одну схему, но практика показывает, что наилучший
результат достигается при создании иерархической карты навигации для
каждого варианта использования.
Аналитическая модель
Аналитическая модель и проектная модель вместе показывают
содержание системы, которые реализуют описанные ранее варианты
использования. Аналитическая модель делает это на более высоком уровне
абстракции, чем
проектная модель. Аналитические объекты все еще
находятся на уровне "логики", в то время как компоненты Модели
архитектуры часто можно увидеть в исходном коде. RUP позволяет
28
переходить от вариантов использования непосредственно к модели
архитектуры, но если этот шаг слишком большой, лучше сначала
реализовать Аналитическую Модель.
проектная
модель
И аналитическая модель, и
содержат диаграммы
классов,
чтобы
описать
статическую структуру и диаграммы взаимодействия, которые показывают
реализацию вариантов использования с точки зрения взаимодействующих
объектов.
Основная проблема с классической Аналитической Моделью RUP это не компонентно-ориентированная модель. Она состоит из большого
количества аналитических классов, которые общаются посредством
пересылки сообщения непосредственно друг другу, не проходя через
компонентные интерфейсы.
Вторая проблема - аналитические объекты отражают логическую
структуру и иногда тяжело преобразуются в проектные компоненты,
несмотря на то, что объекты проектирования – это просто более подробная
версия аналитических объектов.
Проектная модель
RUP использует компонентную архитектуру, разделяя проектную
модель на два уровня:
 архитектурный уровень, где компоненты, являются черными
ящиками;
 уровень детализации компонентов, где содержание каждого
компонента проработано.
На обоих уровнях моделируется статическая структура,
на
основании которой строится поведенческая модель.
Проектная модель: Архитектурный уровень
Статическая структура на архитектурном уровне представлена,
главным образом, двумя диаграммами:
29
 диаграмма пакетов, которая изображает многоуровневый подход;
 компонентная
диаграмма,
показывающая,
как
компонент
реализует интерфейс другого компонента.
Эти уровни отражаются в документации по архитектуре системы.
Динамическая часть архитектуры состоит из реализации варианта
использования. Обычно достаточно иметь одну схему взаимодействия для
каждого
варианта
использования.
Хорошо
разработанная
диаграмматическая компонентная архитектура и набор компонентных
интерфейсов крайне важны для всех приложений.
Проектная модель: Компонентный уровень детализации
На компонентном уровне детализации моделируется каждый
компонент отдельно, так как интерфейсы и взаимодействия с другими
компонентами уже определены на архитектурном уровне.
Статическая часть состоит из диаграмм классов. Это классы, которые
будут запрограммированы, чтобы реализовать компонент.
Динамическая часть - набор компонентной реализации операций.
Для каждой работы с нетривиальной реализацией создается схема
взаимодействия
(схема последовательности или коммуникационная
схема).
Модель данных
Модель данных - модель базы данных, представленная, в основном, в
виде диаграмматических моделей. Если база данных является частью
приложения, то Модель данных определит таблицы, столбцы и отношения
между таблицами, а если потребуется также хранимые процедуры и
триггеры. Эти элементы вписываются в диаграммы классов, используя
специальные стереотипы как "таблица" и "столбец". При использовании
многократных баз данных каждая база данных должна быть показана как
компонент в Модели Проекта.
30
В ряде случаев, Модель данных разделена на пакеты, например по
одному для каждой схемы базы данных. Диаграмма пакетов показывает
зависимости.
Модель развертывания
Модель Развертывания определяет требуемые аппаратные средства и
сетевые соединения. В этой модели выделяют компоненты программного
обеспечения машинам, на которых они должны быть установлены. Схема
развертывания UML предназначается, чтобы описать эту модель.
Модель реализации
Модель Реализации необходима, если организация физического
исходного кода отличается от пакета и компонентной структуры,
определенной в Модели Проекта.
В этом случае Модель Реализации определяет структуру исходного
кода (например, каталоги) и порядок компиляции. Если необходимо
визуализировать этот этап, можно использовать схему пакета. Отношения
между этими пакетами и пакетами или компонентами в Модели Проекта
должны быть четкими, или при помощи универсального соглашения о
присвоении имен или явным отображением.
Сведем результаты
анализа использования
моделировании АС в табл. 1.2
диаграмматики в
31
Таблица 1.2. Использование диаграмматики в моделировании АС
Модель
Бизнесварианты
использования
Диаграмма
Диаграмма Диаграмма Диаграмма Диаграмма Диаграмма Диаграмма
вариантов
активности пакетов
последоват классов
развертыв состояний
использования
ельности
ания
Активно
Аналитическая
бизнес-модель
Вариантов
использования
Активно
Активно
Часто
Активно
Редко
Активно
Иногда
Карта
взаимодействий
Аналитическая
модель
Модель
архитектуры
Часто
Часто
Иногда
Часто
Иногда
Иногда
Активно
Модель
развертывания
Модель
реализации
Редко
Активно
Иногда
Активно
Активно
Часто
Часто
Активно
Активно
Часто
32
1.3 Анализ методов контроля диаграмматических спецификаций
в процессе проектирования бизнес-процессов [128, 140]
Для анализа диаграмматики графических спецификаций бизнеспроцессов
необходимо
выбрать
метод,
обладающий
достаточной
мощностью. Рассмотрим некоторые модели графических языков.
Атрибутика объектов графического языка и варианты их компоновки
является сущностью синтаксической модели языка. Выделяют несколько
основных моделей, позволяющих описать подавляющее большинство
графических предложений. На рис. 1.9 приведена иерархия синтаксических
моделей графических языков [29].
Рис. 1.9. Иерархия моделей языка
Плекс-модель [31, 6] - может использоваться для описания языков, в
которых
количество
точек
соединения
для
графических объектов
33
предопределено, и графические объекты могут соединяться только связями в
виде ломанных. Примерами таких языков являются блок–схемы, химические
структуры, логические и электрические схемы и т.п.
Блочная модель [40] – используется для описания языков объекты,
которых
описываются
квадратами
или
прямоугольниками.
Данная
синтаксическая модель, например, может быть использована для описания
структуры программы.
Пиктограммная
модель
–
еще
один
вид
пространственной
синтаксической модели. Синтаксические атрибуты пиктограммы-координаты
верхней левой и нижней правой точки ограничивающего ее прямоугольника.
Символическая
модель
–
это
специализация
пиктограммной.
Единственные синтаксические признаки символа – координаты его
местоположения, например, средней точки.
Строковая модель непосредственно происходит от символической
модели. Графическим объектом данной модели является символ, его
единственный синтаксический
признак - положение в одномерном
пространстве (строке).
В
графических
языках
невозможно
применять
формализмы,
описывающие текстовые языки. Для анализа графических языков используют
следующие формализмы:
 веб-грамматики (web grammars) [166, 34, 25];
 позиционные грамматики (positional grammars) [27];
 реляционные грамматики (relational grammars) [30, 35];
 многоуровневые графовые грамматики (layered graph grammars) [32,
16];
 сохраняющие графовые грамматики (reserved graph grammars) [123,
122];
 автоматные RV-грамматики [133, 132, 134];
34
 гибридные грамматики, представляющие собой синтез двух и более
грамматик для расширения целевых языков.
Веб-грамматики – первые из описанных графических грамматик.
Предложения данного языка являются ориентированными графами с
символами на вершинах.
Временная сложность – полиномиальная,
грамматика не использует внутреннюю память. Для генерации грамматики
не
используются
метакомпиляторы,
не
разработаны
алгоритмы
нейтрализации. Грамматика создавалась в качестве исследовательского
проекта и не нашла использования в реальных системах анализа и контроля.
На рис. 1.10 приведен пример предложения веб-грамматики.
Рис. 1.10. Пример графического предложения Web-грамматики
Позиционные грамматики реализуются на базе плекс-структур, для
анализа используются позиционные продукции графических примитивов.
Временная сложность – полиномиальная, грамматика не использует
внутреннюю
память.
Для
генерации
грамматики
не
используются
метакомпиляторы и не разработаны алгоритмы нейтрализации. На рис. 1.11
представлены примеры продукций позиционной грамматики.
35
Рис. 1.11. Примеры продукций позиционной грамматики
Реляционная
грамматика
–
контекстно-свободная
графическая
грамматика. Такие грамматики фокусируются на описании дополнительной
атрибутики графических объектов. Для генерации грамматики возможно
использовать метакомпиляторы, существуют алгоритмы нейтрализации.
Временная сложность – экспоненциальная, грамматика не использует
внутреннюю память. На рис. 1.12 приведены примеры правил реляционной
грамматики.
Рис. 1.12. Пример правил реляционной грамматики
36
Многоуровневая графовая грамматика – многослойная грамматика,
описываемая в виде множества вложенных графов. Временная сложность –
экспоненциальная,
грамматика
использует
память
пропорционально
количеству элементов и связей с коэффициентом k (k > 1). Для генерации
грамматики
возможно
использовать
алгоритмы нейтрализации. На рис.
метакомпиляторы,
существуют
1.13 приведены примеры правил
многоуровневой графовой грамматики.
Рис. 1.13. Пример правил многоуровненвой графовой грамматики
Сохраняющая
графовая
грамматика
–
множество
правил
преобразования графов. По шаблону из правила происходит замена части
графа на другой граф, и процесс поиска замены производится повторно.
Временная сложность – полиномиальная, грамматика использует память
пропорционально количеству элементов и связей с коэффициентом k (k > 1).
Для генерации грамматики не используются метакомпиляторы и не
разработаны алгоритмы нейтрализации. На рис.
1.14 приведен пример
правил сохраняющей графовой грамматики.
Рис. 1.14. Пример правил сохраняющей графовой грамматики
RV – грамматикой [132]
языка L (G) называется упорядоченная
пятерка непустых множеств G  (V    R r0 ) , где
37
V  { e  e  1 L} – вспомогательный алфавит (алфавит операций над
внутренней памятью);
  {at  t  1 T }
–
терминальный
алфавит
графического
языка,
являющийся объединением множеств его графических объектов и связей
(множество примитивов графического языка);
  {a t t  1 T }
–
квазитерминальный
алфавит,
являющийся
расширением терминального алфавита.
R  {ri  i  0 I } – схема грамматики G (множество имен комплексов
продукций, причем каждый комплекс ri состоит из подмножества Pij
продукций ri  {Pij  j  1 J } );
r0  R – аксиома RV – грамматики (имя начального комплекса
продукций), rk  R – заключительный комплекс продукций.
~
 [W ( ,...,  )]
  1
n
Продукция Pij  ri имеет вид at 
  
 rm
В качестве внутренней памяти предлагается использовать стеки для
обработки графических объектов, имеющих более одного выхода (чтобы
хранить информации о связях – метках), и эластичные ленты для обработки
графических объектов, имеющих более одного входа (чтобы отмечать
количество возвратов к данной вершине, а, следовательно, количество
входящих дуг). Ленты позволяют считывать данные из ячеек без
уничтожения их содержимого, а ячейки лент могут работать в режиме
счетчика целых положительных чисел.
Определим следующую интерпретацию правил RV – грамматики в
зависимости от параметров μ и ν.
Пусть μ = 0, тогда Ω0 [Wν (γ1, ... , γn)] ≡ Wλ (γ1, ... , γn), т.е. Ω0 – пустой
оператор.
38
Отношение Wλ (γ1, ... , γn) определяет операции над памятью
реализованной моделями стек или магазин.
При λ = 0 никаких действий над памятью не производится.
При λ = 1 (λ = 2) в стек / магазин с номером S ∈ {1, n} записывается
(стирается) γs ∈ V , причем если запись производится безусловно, то стирание
осуществляется при условии, что γs в правиле RV – грамматики и вершине
стека / магазины совпадают. В противном случае данное правило считается
неприемлемым (стирание не производится).
При μ = 1 оператор Ω1 имеет вид Ω1 [Wν (γ1, … , γn)] ≡ Wλ (γ1α1 , ... , γnαn),
определен для λ =1, 2, 3 и задает простую операцию записи, чтения или
сравнения над ленточной памятью, где (α1(L1), ... , αn(Ln)) указывают номера
ячеек соответствующих эластичных лент (1, ... , n), куда будут записаны при λ
= 1 (считаны при λ = 2, сравнены при λ = 3) символы γ1, ... , γn ∈ V .
При μ = 2 оператор Ω2 имеет вид Ω2 [Wν (γ1, ... , γn)] ≡ Wλ1 (γ1α1, ... ,
γnαn)/Wλ2(γ1β1, ... , γnβn),определен для λ1 = 1, 2, λ2 = 2, 3 и задает условную
рацию над ленточной памятью, т.е. операция в числителе выполняется при
условии выполнения операции в знаменателе.
В процессе исследования разработаны грамматики для пяти типов
диаграмм UML [128]: диаграмма активности (табл. 1.3), вариантов
использования (табл. 1.5), классов (табл. 1.7), развертывания (табл. 1.9) и
последовательности (табл. 1.10). Ниже приведены эти грамматики.
Таблица 1.3. RV-грамматика диаграммы активности UML
№ Комплекс
пп
Квази-терм
Комплекс –
преемник
RV – отношение
1
r0
label
r3
2
r1
label
r3
3
r2
labelP
r3
W2(b1m)
4
labelW
r3
W2(b2m)
5
labelR
r3
W2(b3m)
39
Таблица 1.4. RV-грамматика диаграммы активности UML (продолженеи)
№ Комплекс
пп
Квази-терм
Комплекс –
преемник
labelL
r3
A
r1
8
P
r1
W1(t1m)
9
W
r2
W1(1t(1),t2m)/ W2(et(1))
10
W
r2
W1(2t(1))/ W2(1t(1))
11
R
r1
W1(t3m(k-1))/ W3(k>1)
12
L
r2
W1(1t(2),kt(3),t4m)/ W2(et(2))
13
L
r2
W1(inc(mt(2)))/W3(mt(2)<kt(3))
14
AK
rk
6
7
r3
RV – отношение
W2(b4m)/ W3(mt(2)==kt(3))
Таблица 1.5. RV-грамматика диаграммы вариантов использования UML
№ Комплекс
пп
Квази-терм
Комплекс –
преемник
RI
r3
W1(it(1))/W3(it(1) ==
== )
|| it(2)
2
RE
r4
W1(it(1))/W3(it(1) ==
== )
|| it(2)
3
RG
r5
W1(it(1))/W3(it(1) ==
== )
|| it(2)
4
RI
r6
5
RE
r7
6
RG
r8
RA
r2
RG
r5
1
7
r0
r1
8
9
r2
C
r0
10
r3
C
r0
11
r4
C
r0
12
r5
C
r0
A
r1
13
RV – отношение
40
Таблица 1.6. RV-грамматика диаграммы вариантов использования UML
(продолжение)
№ Комплекс
пп
Квази-терм
Комплекс –
преемник
RV – отношение
14
r6
C
r0
W1(it(2))/W3(it(1) ==
== )
|| it(2)
15
r7
C
r0
W1(it(2))/W3(it(1) ==
== )
|| it(2)
16
r8
C
r0
W1(it(2))/W3(it(1) ==
== )
|| it(2)
17
A
r1
После окончания разбора провести операцию контроля:
* = W2(it(1),it(2))/W3(it(1) <>
&& it(2) <>
)
В результате должны остаться пустые ленты
Таблица 1.7. RV-грамматика диаграммы классов UML
№ Комплекс
пп
Квази-терм
Комплекс –
преемник
LinkC
r1
W1(it(1))/W3(it(1) ==
== )
|| it(2)
2
Linkn
r2
W1(it(3))/W3(it(3) ==
== )
|| it(4)
3
LinkG
r3
W1(it(5))/W3(it(5) ==
== )
|| it(6)
4
LinkA
r4
W1(it(7))/W3(it(7) ==
== )
|| it(8)
5
LinkK
r5
W1(it(9))/W3(it(9) ==
it(10) == )
||
6
AXOR
r6
7
AXOR
r7
1
r0
RV – отношение
8
r1
C
r0
W1(it(2))/W3(it(1) ==
== )
|| it(2)
9
r2
C
r0
W1(it(4))/W3(it(3) ==
== )
|| it(4)
41
Таблица 1.8. RV-грамматика диаграммы классов UML (прдолжение)
№ Комплекс
пп
Квази-терм
Комплекс –
преемник
RV – отношение
10
r3
C
r0
W1(it(6))/W3(it(5) ==
== )
|| it(6)
11
r4
C
r0
W1(it(8))/W3(it(7) ==
== )
|| it(8)
12
r5
C
r0
W1(it(10))/W3(it(9) ==
it(10) == )
13
r6
LinkC
r1
W1(t1m)
14
r7
C
r0
W2(t1m)
||
15
r8
C
r0
После окончания разбора провести операцию контроля:
* = W2(it(1),it(2))/W3(it(1) <>
&& it(2) <>
),
W2(it(3),it(4))/W3(it(3) <>
&& it(4) <>
),
W2(it(5),it(6))/W3(it(5) <>
&& it(6) <>
),
W2(it(7),it(8))/W3(it(7) <>
&& it(8) <>
),
W2(it(9),it(10))/W3(it(9) <>
&& it(10) <>
).
В результате должны остаться пустые ленты
Таблица 1.9. RV-грамматика диаграммы развертывания UML
№ Комплекс
пп
Квази-терм
Комплекс –
преемник
A
r0
2
label
r1
3
labelI
r2
A
r0
labelI
r2
W1(mt(1))
W2(mt(1))/W3(mt(1)==k)
1
4
r0
r1
5
6
r2
I
r4
7
r4
A
r1
RV – отношение
W1(mt(1))
42
Таблица 1.10. RV-грамматика диаграммы последовательности UML
№ Комплекс
пп
Квази-терм
Комплекс –
преемник
RV – отношение
1
r0
L
r6
2
r1
M
r3
3
MA
r4
4
MR
r5
5
L
r6
M
r3
W1(mt(1))
7
MA
r4
W1(mt(2))
8
MR
r5
9
L
r6
R
r1
F
r2
6
10
r2
r3
11
W2(mt(2))
12
r4
F
r2
13
r5
F
r2
W2(mt(1))
14
r6
F
r2
W1(mt(1))
D
r7
M
r3
17
MA
r4
18
MR
r5
15
16
r7
Рассмотрим типовые операции памятью используемые в грамматиках
нотаций бизнес-процессов.
W2(b1m) –обозначает чтение элемента из соответствующего магазина. В
данном случает чтение элемента класса b из магазина 1.
Операция W1(t1m) производит запись элемента типа t в первый магазин.
Таким образом в диаграмме активности сохраняется точка возврата при
условном разветвлении.
Операция W1(inc(mt(2)))/W3(mt(2)<kt(3)). Операция является условной, т.е.
часть до знака ―/‖ выполняется при корректном выполнении части после.
43
Условная часть (после ―/‖) содержит правило сравнения, которое не изменяет
состояние памяти, а только считывает значения из соответствующих
элементов. В рассматриваемом примере операция означает проверку
выполнения условий после чтения значений из соответствующих ячеек – при
этом правило грамматики выполняется, если число пройденных путей
меньше числа входных элементов элемента слияние. После удачной
проверки условия выполняется действие. В рассматриваемом примере
выполняется запись значения в ячейку ленты на единицу больше
предыдущего. Данная операция в правиле грамматики отсчитывает число
путей, входящих в символ слияния.
W1(1t(1),t2m)/ W2(et(1)) – обозначает условную операцию записи значения
1 в ячейку с номером t и запись элемента типа t во второй магазин, при
условии что ячейка пуста.
Операция вида W2(b4m)/W3(mt(2)==kt(3)) предполагает извлечение из 4ого магазина ссылки на связь, по которой нужно следовать, при условии, что
все связи входящие в слияние пройдены.
На базе данных грамматик строят современные языки визуального
программирования, в том числе визуальные DSL (Domain Specific Language),
являющиеся предметно-ориентированными и позволяющими повысить
производительность разработки за счет уменьшения когнитивного разрыва
между заказчиком и разработчиком АС.
Примером использования графических грамматик для построения DSL
[103] служит работа немецкого ученого Габриэля Тинцера (Gabriele
Taentzer)s [78]. Область интереса Тинцера составляет инструментарии
генерации языков. Первый вариант его системы базировался на построении
грамматики DSL с использованием расширенной БНФ нотации (с
применением Object Constraint Language), но со временем его интересы
сместились в область описания DSL с использованием графических
44
грамматик. Первоначальное описание грамматики трансформируется в
графовую грамматику при помощи авторского инструментария.
Автор
рассматривает
трансформацию
на
примере
диаграммы
активности. Определяется алфавит и правила, приводится пример конечной
грамматики:
Другим примером использования графических грамматик является
продукт
VisPro
[112]
–
система
генерации
визуальных
языков
программирования на базе сохраняющих грамматик. Разработка ведется в
университетах Даллас и Массачусетс США. Подход, используемый
разработчиками, – генерация графов, основанных на конкретной грамматике,
на основе продукций правил сохраняющих графических грамматик.
По утверждению авторов [112] для пользователей визуальных языков
главными аспектами является физическая схема грамматики (набор
графических примитивов, используемый для построения предложений языка)
и семантика элементов языка. Правильная физическая схема графического
языка может обеспечить легкое понимание значения каждой диаграммы
составленной разработчиком.
Авторы [112] убеждены, что физическая схема визуального языка
описания некоторой спецификации является краеугольным аспектом его
использования, а также популярности. Во-первых, большинство алгоритмов
45
построения графов концентрируются на геометрической атрибутике блоков и
связей, не учитывая синтаксис и семантику их взаимоотношения. Во-вторых,
применимость алгоритма базируется только на графических примитивах, не
учитывая область применения графического языка. VisPro исправляет эти
ошибки и генерируют алгоритм опираясь на синтаксис и семантику языка.
Таким образом, граф, построенный с применением VisPro, становится
семантически более корректным и легче читаемым.
Группа исследователей из Кембриджа в составе Алистаир Стид, Алан
Блэквел и
Самуэль Аарон в своем докладе [98] предлагает систему
генерации грамматик для новых графических нотаций, спроектированных по
требованиям
пользователя.
ориентированность
на
Особенностью
генерацию
программ
системы
разбора
является
предложений
графического языка запускаемых на мобильных устройствах, что позволит
использовать программу в любое удобное время. В основу работы положена
транслирующая графическая грамматика.
Авторы [98] рассматривают работу системы на примере грамматики
языка для распознавания мелодий закодированных цветовым кодом на
маркерной доске. Отдельные инструменты кодируются различными цветами
на доске. От амплитуды и длины штриховки зависит звучание каждого
инструмента. Упоминается, что существует грамматика, разработанная ими,
которая распознает нотную грамоту и воспроизводит соответствующее
произведение.
Введение цветовой градации инструментов позволяет
прозрачно описывать для какого инструмента записана нота.
Описанный инструмент позволяет описывать графические нотации
людям, не имеющим специального образования в области формальных
грамматик. Такие грамматики позволяют ускорить рутинную работу, что в
свою очередь сказывается на общей продуктивности работы в целом.
Группа ученных из Китая представила разработку по распознаванию
действий на фотографии на базе многоуровневых графовых грамматик [115].
46
Их разработка применима в области визуального анализа, например анализа
видеопотока в реальном времени, или при разработке нового интерфейса
взаимодействия человек-компьютер. Человеческие действия, направленные
на достижение определенной цели и заключающиеся в определѐнном наборе
телодвижений, можно описать некоторым набором пространственновременных шаблонов, обладающих двумя основополагающими свойствами:
 они обладают высокоорганизованной иерархией и композицией. Это
означает, что действие может быть разделено на множество более мелких
действий и эти действия могут быть декомпозированы еще больше. В
качестве примера рассматривается пример действия – баскетбольный бросок.
Оно состоит из приседания на корточки, вытягивания тела, поворота запястья
и т.д.;
 существует большое количество вариантов совершения действия, что
сильно усложняет задачу распознавания действий. Такое разнообразие может
быть обусловлено различными факторами, такими как стилистика действия,
ограничениями окружающей обстановки, точка наблюдения за действием.
Однако, несмотря на эти проблемы, задачи распознавания могут быть
решены использованием иерархически структурированными паттернами.
На основе большего количества паттернов строится грамматическая
модель видео потока и делается логический вывод о представленном в кадре
действии. На момент написания статьи было ограничение на входной поток:
в кадре должен присутствовать только один действующий объект, кадр
должен быть предварительно нормализован (действующий объект занимает
не менее половины кадра и четко различим на кадрах). Но, не смотря на эти
ограничения метод, достигал точности в 92,5% на различных тестовых
выборках.
Рассмотренные примеры показывают, что графические грамматики
широко применяются в процессе синтеза и анализа графических схем и
нотаций, в области распознавания сцен и образов. Область применения
47
распростирается
от синтеза и анализа формализованных схем до
распознавания рукописных текстов. Широкая применимость в области
анализа диаграмматики дает возможность делать вывод о достаточной
мощности аппарата графических грамматик.
1.4 Анализ систем разработки диаграмматических спецификаций
бизнес-процессов нотации UML
Сегодня проектировщикам в их деятельности помогают огромное
количество проектных и аналитических инструментов, которые повышают
производительность,
повышают
уменьшают
производительность,
изменениями,
надежность.
стоимость,
улучшают
Есть
минимизируют
восприятие,
специализированные
инструменты во всех областях разработки.
усилия,
управление
средства
и
Средства моделирования
помогают в анализе проблем, в проведении экспериментов или трудоемких
аналитических операций. Так же модели являются хорошими.
Имеется
определенный
набор
инструментов
под
названием
Автоматизированная разработка программного обеспечения (CASE), которые
используются в разработке программного обеспечения. Их использование
похоже на подобные инструменты в других областях разработки в том
смысле, что они помогают в анализе и разработке программного
обеспечения.
Глобально CASE-средства можно разделить на две большие группы –
универсальные графические редакторы и интегрированные средства
построения
графических
спецификаций.
Универсальные графические
редакторы строят некоторое графическое описание работы без последующей
его привязки к какой-либо модели. Такие редакторы нацелены на сохранение
описания о визуальном представлении спецификации.
Интегрированные средства построения графических спецификаций
работ служат для наполнения графическими спецификациями некоторой
глобальной модели. Таким примером могут служить среда Rational Software
48
Architect [43] интегрированная в набор пакетов для разработки сложных АС
Rational.
Универсальные графические редакторы ориентированы на построение
графики и поэтому чаще всего отличается богатым набором графических
примитивов. Яркими представителями являются редакторы MS Visio, Visual
Paradigm.
Microsoft Visio [87, 147] – мощный редактор диаграммных схем от
компании Microsoft. Он позволяет пользователю создавать множество схем и
технических рисунков, дополнительно поставляются шаблоны, которые
ускоряют создание графических спецификаций. Предназначен для быстрого
создания дополнительных рисунков для текстовых документов.
Microsoft Visio обладает следующими преимуществами:
 полная и всесторонняя интеграция со всеми инструментами
компании Microsoft, которая де-факто используется в любом производстве;
 встроенный
язык
манипулирования
схемами,
позволяющий
автоматизировать процесс разработки графической спецификации;
 поддержка
множества
нотаций
графических
спецификаций,
позволяет использовать многим относительно маленьким компаниям этот
инструмент, как стартовый в своих внутренних процессах.
Наряду с преимуществами Microsoft Visio содержит ряд недостатков:

нет инструментов для поддержки коллективного проектирования.
Встроенные средства не позволяют синхронизировать диаграммы, что
требует ручного процесса объединения диаграмм;

нет инструментов для контроля корректности графической
спецификации, можно комбинировать элементы из различных диаграмм и не
будет инициировано никакого сообщения об ошибке.
Visual paradigm for UML [75, 148] – инструмент CASE с несколькими
опциями для того, чтобы работать с диаграммами UML2. Также
49
поддерживает диаграммы требований SysML и диаграммы ER. Рабочая среда
представляет хорошую рабочую среду, которая упрощает просмотр и
манипулирование проектом разработки. Инструмент поддерживает обратную
миграцию диаграмм определенных изменений в исходном коде некоторых
языков программирования, например C++ и Java.
Visual paradigm поддерживает следующие нотации графических
спецификаций: UML, SysML, ERD, BPMN, DFD, ArchiMate и другие.
В Visual paradigm есть частичный контроль корректности диаграммы.
Он заключается в контроле связываемых объектов. Например, в диаграмме
вариантов использования запрещена связь между блоками вариантов
использования типа обобщение. При попытке добавить входящую или
исходящую связь в блок вариант использования появляется графическое
сообщение (красный крест), сообщающее о невозможности добавления
текущей
связи
на
палитру.
Такой
вариант
контроля
позволяет
контролировать базовые синтаксические ошибки в диаграммах. Ошибки,
находящиеся на большом «контекстном расстоянии» друг от друга, найти
таким способом невозможно. Например, ошибки ветвления/слияния,
связанные с требованием слияния исходящих ветвей, вышедших из одного
блока, в соответствующем конечном блоке, такой метод не обнаружит.
Aris Toolset [90, 8] – набор средств для бизнес-моделирования
сложных систем, одним из которых является создание и анализ UMLмоделей. ARIS Toolset - профессиональное инструментальное средство для
описания и анализа бизнес-процессов. Программный продукт ARIS Toolset и
его дополнительные компоненты (ARIS BSC, ARIS ABC, ARIS Simulation и
ARIS Web Publisher) позволяют описывать и совершенствовать бизнеспроцессы всей компании и проводить их анализ и оптимизацию. ARIS
Toolset необходим для проектов по реинжинирингу и улучшению бизнес процессов. ARIS Toolset предназначен для описания бизнес-процессов, их
документирования,
проведения
анализа,
дальнейшего
улучшения
и
50
оптимизации Знания о бизнес-процессах компании, документируемые при
помощи ARIS Toolset, не просто визуализируются в графическом виде, но и
хранятся в базе данных ARIS Server. ARIS Toolset предоставляет большое
количество многократно апробированных методов моделирования бизнес процессов и это позволяет легко настраивать ARIS к требованиям проекта.
ARIS Toolset состоит из следующих компонентов:
ARIS Easy Design - инструментальное средство для моделировщиков,
предназначенное только для описания бизнес-процессов.
ARIS Web Designer - предназначен для разработки бизнес-процессов в
Интернет.
ARIS BSC - предназначен для моделирования системы стратегического
управления компании.
ARIS Process Cost Analyzer - ARIS Process Cost Analyzer – это модуль,
заменивший ARIS ABC. Он позволяет анализировать затраты при помощи
большего количества инструментов и проводить различные виды агрегации
получаемых данных.
ARIS Simulation (работает с ARIS Toolset) – модуль системы ARIS
Toolset, используемый для динамического моделирования разработанных
моделей бизнес-процессов.
ARIS Web Publisher (работает с программными продуктами ARIS Easy
Design и ARIS Toolset) - предназначен для публикации информации о бизнеспроцессах в Интернет ARIS Web Publisher используется в тех случаях, когда
надо
разместить
информацию
о
бизнес-процессах
для
множества
пользователей.
ARIS Quality Management Scout - предназначен для совершенствования
системы управления качеством.
ARIS
Process
Risk
Scout
-
ориентированного управления рисками.
предназначен
для
процессно-
51
ARIS UML Designer - ARIS UML Designer - позволяет работать со
всеми диаграммами UML 2.4
В Aris UML Designer предусмотрен режим верификации ошибок,
основанный на шаблонах. При построении диаграммы разработчик не может
контролировать корректность диаграммы в реальном времени. Вместо этого
он может сгенерировать отчет об ошибках, в котором будет список
обнаруженных ошибок с текстовым описанием обнаруженной ошибки. Такой
отчет не всегда понятно диагностирует место ошибки, что является
неоспоримым минусом данного вида анализа.
IBM Rational Software Architect (RSA) [42]– программный комплекс
проектирования, разработки и оценки АС различной сложности. IBM RSA
построен на основе Eclipse. Это позволяет легко расширять продукт
различными плагинами. Как известно, Eclipse разрабатывалась как IDE.
Данный факт обуславливает возможность вести разработку и проектирование
в одной среде. Как следствие, разработчик не переключается в сторонние
программы при работе и более сосредоточен на работе.
IBM Rational Software Architect обладает следующими свойствами:
 создание эскизов – простой и неформальный способ оформить идею
и взять быстрый старт. Но в дальнейшем необходимо прорабатывать
формальные архитектуры. Данный подход возможен с IBM RSA;
 управление
рисками,
уровнем качества и изменений более
эффективно. Выявление и понимание требований более высокого уровня.
Позволяет проводить более точное планирование и оценку;
 более эффективный контроль архитектуры и выпуска продуктов;
 эффективный
менеджмент
и
повторное
использование
архитектурных решений и примитивов;
 управление эволюцией, объединением, контрактами проектирования
в ситуациях, когда работа производится в распределенной команде;
52
 акцент на творческие аспекты разработки, уменьшая рутинную
работу;
 возможность проектировать облачные решения;
 возможность быстро создавать множество решений на основе
примеров из предметной области пользователя, используя инструменты,
анализирующие загруженные примеры.
IBM
Rational
Software
Architect
позволяет
контролировать
проектируемую систему с различных точек зрения. Реализовано множество
правил для построения диаграмм. Система проектирования не дает
возможности построить диаграмму не соответствующую какому-то из
правил. Например, при попытке соединить два элемента, связь между
которыми запрещена, связь между ними не добавится. Систему можно
дополнительно проверить при помощи ограничений написанных на языке
Object Constraint Language (OCL) [116, 111]. OCL – декларативный язык, для
описания правил, применимых для UML-моделей. Изначально язык
разрабатывался в компании IBM, потом стал частью спецификации UML.
Для верификации данных правил существует отдельный инструмент,
интегрированный в среду проектирования.
Разработка модели ведется в среде Eclipse. Eclipse – расширяемая
система для создания сложных программных систем. Eclipse известен своими
расширениями для разработки на разных языках. Таким образом, разработка
и
проектирование
программных
продуктов
происходит
в
тесном
взаимодействии, что призвано повысить качество разрабатываемых систем.
Контроль разрабатываемой диаграммы происходит в двух режимах:
1.
На этапе создания диаграммы контролируется корректность
связей. Этот тип контроля основан на правилах. Правило имеет следующий
вид: P(связь, источник, приемник) -> (Правильно/Не правильно)
Если правило возвращает «Не правильно», то связь не добавляется на
полотно. Этот механизм предельно прост и универсален, но недостатком
является его ограниченность:
53
 возможно проверить только синтаксические ошибки;
 правило, требующее большего количества элементов для контроля,
не может быть применено. Например, для диаграммы последовательностей
есть правило – для каждого вызова должен быть возврат. Для контроля
необходимо 4 элемента: Исходный элемент, Вызов, Вызываемый элемент,
Возврат;
 в диаграмме активности не следует употреблять более одного
входного и конечного элемента, но пользуясь правилами этого нельзя
контролировать.
В случае сигнализации о
запрещѐнном правиле генерируется
сообщение об ошибке, которое выводится в лог сообщений для
проектировщика.
2.
Разработчик может создать
описание ограничений
UML
диаграммы, используя язык OCL. По данным правилам происходит
верификация
построенной
диаграммы.
Эти
правила
могут
быть
использованы для генерации макета программного продукта. Проверка
происходит по запросу проектировщика. Данная проверка призвана
проверить не противоречивость самих правил и достижимость узлов
диаграммы. Язык OCL описывает логику диаграммы, но не контролирует ее
синтаксис. Ошибки записываются в журнал.
RSA построен по принципам модульной системы Eclipse, что позволяет
легко провести интеграцию в среду проектирования. Для добавления
функциональности в RSA необходимо написать plugin по правилам Eclipse.
RSA предоставляет комплекс средств для работы с диаграммами UML
Modeler. Данный класс позволяет создавать и редактировать разные типы
диаграмм. Через данный класс можно получить информацию о диаграмме,
загруженной в Rational Software Architect. Диаграмма представляется двумя
списками: списком узлов и списком связей между узлами.
Плагин пишется на языке Java. Инструментарий для разработки
доступен в продукте Eclipse Java Development Tools.
54
Сведем результаты обзора в сравнительную таблицу (табл. 1.11)
Таблица 1.11. Сравнение современных редакторов
Показатель
Контроль
синтаксиса
модели
Визуализация
модели
Стандарты
MS Visio
Visual
Paradigm
Rational
Software
Architect
ARIS Toolset
Частично
Частично
Да
Да
Средняя
Средняя
Хорошая
Хорошая
UML, ER
Динамическое
моделирование
Оптимизация
модели
Функциональностоимостной
анализ
Генерация
программного
кода
Возможность
добавить
собственное
правило
Стоимость
Распространенно
сть
Доступность
Групповая работа
Контроль
синтаксических
ошибок
Контроль
семантических
ошибок
Наиболее
UML, ERD,
UML,
BPMN, DFD BPMN, EPC
UML, EPC,
ERM, DFDчастично
Нет
Нет
Да
Да
Нет
Нет
Нет
Да
Плохой
Плохой
Средний
Хороший
Нет
Нет
Да
Нет
Нет
Нет
Слабая
Слабая
Средняя
Средняя
Средняя
Средняя
Широкая
Широкая
Слабая
Слабая
Широкая
Да
Широкая
Да
Слабая
Да
Слабая
Да
Нет
Нет
Да
Да
Нет
Нет
Нет
Нет
распространенным
диаграмматическим
инструментом,
используемым на всех этапах создания АС, является язык UML. Однако в
современной теории и практике применения UML-диаграмматики в
55
проектировании АС наблюдается слабое развитие методов и средств анализа
и контроля корректности проектируемых диаграмм. Отсутствуют средства
контроля корректности семантической согласованности диаграммных
нотаций в процессе коллективного проектирования. Данные факты
открывают дополнительный источник трудно диагностируемых и «дорогих»
ошибок в создании АС.
1.5 Постановка задачи
Проведенный выше анализ методологий проектирования АС и средств
проектирования графических спецификаций показывают:
1. Существующие
средства
проектирования
графических
спецификаций не используют универсальные методы синтаксического
анализа. Разработка средств контроля для новых языков занимает
значительное время, т.к. требует фактически создания нового анализатора с
самого начала.
2. Современные автоматные синтаксически-ориентированные методы
анализа и контроля графических нотаций бизнес-процессов не обладают
эффективными механизмами обнаружения ошибок.
3. Не развиты механизмы создания эффективного анализатора на
основе описания графических конструкций целевого языка. Современные
средства
требуют
глубокого
знания
теорий
анализа
и
требуют
высококвалифицированных в этой области специалистов для создания
анализаторов.
4. Предлагаются средства анализа и контроля отдельных графических
спецификаций, не рассматриваются вопросы корректности комплексных
диаграмм проектируемой АС.
5. Оставлены без внимания семантическое наполнение создаваемых
диаграмм, что может в итоге привести к большому рассогласованию в
используемых понятиях при создании АС.
56
На основании вышесказанного и проведенного в первой главе данной
работы
анализа
предметной
области,
сформулируем
основные
исследовательские задачи.
1. Анализ структурных особенностей диаграматики описания бизнеспроцессов. Разработка многоуровневой автоматной графической RVграмматики.
2. Анализ семантических особенностей графических нотаций бизнеспроцессов. Разработка метода контроля семантической целостности
комплекса диаграмм в процессе коллективного проектирования.
3. Анализ методов нейтрализации ошибок. Разработка алгоритма
формирования множества комплексов продукций-продолжателей для
автоматной графической RV-грамматики.
4. Анализ методов метакомпиляции. Разработка метода синтеза
таблицы автоматной графической RV-грамматики.
5. Разработка программного обеспечения, позволяющего производить
эффективный анализ и контроль графических нотаций бизнес-процессов в
диаграмматике UML
1.6 Выводы
1. В современной практике проектирования АС одним из базовых методологических
описывать
и
понятий
представлять
является
бизнес-процесс,
организацию
и
позволяющий
функционирование АС.
Использование методологической базы проектирования АС на основе
парадигмы бизнес-процессов позволяет создавать адекватную требованиям
заказчика модельную среду.
2. Эффективными
и
общепринятыми
средствами
проектной
деятельности при создании АС являются диаграмматика в
виде
диаграмматических моделей, методик их разработки и инструментальных
средств поддержки.
3. Анализ существующих графических нотаций бизнес-процессов
показывает, что наиболее эффективными с точки зрения отражения
концептуальных и реализационных особенностей проектируемой АС
является модельный аппарат UML. Данный факт в сумме с простотой
57
изучения делает UML наиболее популярным графическим языком описания
проектных решений.
4. UML-диаграмматика бизнес-процессов в основе мастер технологии
проектирования RUP, регламентирующей системную и комплексную
разработку UML-моделей на всем протяжении жизненного цикла АС.
5. Особенно важным является создание корректных UML-диаграмм на
концептуальном этапе проектирования АС. Ошибки в таких диаграммах
являются самыми «дорогими».
6. В теоритическом плане достаточно широкое распространение
получил синтаксически-ориентированный подход анализа и контроля
графических
спецификаций
(схем,
диаграмм,
фотографий,
сцен,
видеопотоков), основанный на графических грамматиках. Однако, в
современных
инструментальных
средствах
проектирования
АС,
использующих прямые методы контроля диаграмматических моделей,
основные на многочисленных «проходах» по диаграмме на соответствие
определѐнному правилу, что не позволяет диагностировать контекстно удаленные синтаксические ошибки и семантические ошибки, связанные с
текстовым наполнением диаграммной модели, такой подход не реализован.
7. Анализ
применения
графической
грамматики
обнаруживает
эффективную возможность создания грамматики по графическому описанию
конструкций
языка.
Это
открывает
возможность
создания
новых
анализаторов по графическому описанию конструкций языка, что позволит
изменять грамматики под нужды конкретного предприятия без внесения
изменений в код анализатора.
8. В теории и практике проектирования АС отсутствуют методы и
средства анализа и контроля ошибок, распределенных по нескольким
диаграммам. Контроль такого класса ошибок позволит значительно
уменьшить
количество
допускаемых
ошибок
на
ранних
этапах
проектирования. Уменьшение количества ошибок, в конечном итоге,
сократит время разработки АС.
58
9. Рассмотренные инструментальные системы проектирования АС не
предоставляют
возможности
анализа
распределенных
ошибок,
а,
следовательно, нет возможности анализа семантической корректности
диаграмм при коллективном проектировании, это открывает возможность
допустить трудно диагностируемые и опасные ошибки в процессе
проектирования АС.
Указанные недостатки нашли отражение в сформулированных задачах
исследования с целью их устранения при проектировании АС.
59
Глава 2. Разработка методов синтаксического и семантического анализа
и контроля диаграмматики нотаций бизнес-процессов,
созданных в процессе коллективного проектирования.
В данной главе предлагается и исследуется метод анализа связанных
ошибок, распределенных по множеству диаграмматических моделей бизнеспроцессов, создаваемых в процессе коллективного проектирования. Метод
основан на разработанном аппарате многоуровневых RVM-грамматики.
Разработан метод анализа семантической корректности комплекса
диаграммных нотаций бизнес-процессов на основе онтологического подхода.
Исследуются
методы
онтологического
контроля
согласованности
графических нотаций, в частности модифицированный метод лексикосинтаксических шаблонов.
2.1 Обзор методов многоуровневых описаний
Теория Иерархии [153, 154] - подмножество общей теории систем. Она
появилась в качестве развития общей научной дисциплины, исследующей
комплексные системы. Теория иерархии использует ряд принципов, чтобы
описывать и сложную структуру и оперировать с поведением систем с
многократными уровнями.
Иерархия: в математических терминах это - частично упорядоченный
набор. Если использовать менее строгое определение, то можно сказать, что
иерархия - множество частей целого с упорядоченными ассиметричными
отношениями в целом. То есть верхние уровни находятся над более низкими
(по какой-либо классификации), и отношения вверх асимметричны с
отношениями вниз.
Иерархические уровни представляют собой уровни наполненные
сущностями, свойства которых характеризуют рассматриваемый уровень.
Конкретная
сущность
может
принадлежать
множеству
уровней
в
60
зависимости
от
определяющих
критериев,
используемых,
чтобы
характеризовать иерархию уровней.
Уровень организации – это характеристика системы, описывающая
отношение выше/ниже, позволяя выделять уровни системы. Например,
проектирование АС состоит из комплекса задач проектирования отдельных
бизнес-задач. Такое деление организуется самим определением конкретной
иерархии. Нет никакого особого масштаба, ограничивающего уровень
детализации иерархии.
Уровень наблюдения – это тип детализации, базирующийся на
основании относительных масштабов рассмотрения исследуемого объекта.
Например, глобальная задача оптимизация производительности системы
является общим контекстом подзадач оптимизации производительности
отдельных подсистем.
Критерий для рассмотрения вводится при наблюдении системы. При
этом учитывается пространственно-временная размерность, в которой
происходит рассмотрение, а также точка отсчета, которая определяет, что в
системе находится на переднем плане, а что на заднем. Критерий для
наблюдения использует типы составляющих и их отношений друг к другу,
чтобы характеризовать систему в общем виде. Если критерии для
рассмотрения соединены асимметричным способом, то критерии приводят к
уровням организации. Иначе, критерии для наблюдения просто производят
изолированные иерархические классы.
Порядок уровней - есть несколько критериев, посредством чего другие
уровни поддерживают отношение выше ниже. Эти критерии часто
используются параллельно, но иногда только один или несколько из них
обращаются предыдущему уровню. Верхние уровни могут определяться на
основании следующих критериев для нижних уровней:
 быть контекстом;
 быть ограничением для;
61
 происходит более медленно (с более низким темпом), чем;
 быть наполненным сущностями с большей связностью чем;
 содержать и быть сделанным из.
У грамматик рассмотренных выше есть одна слабость, которая ярко
проявляется во время реального применения. При анализе сложной
структуры диаграмматических нотаций (комплексной диаграммы UML)
классические графические RV-грамматики становятся громоздкими, их
разработка усложняется, не обеспечивается контроль взаимосвязанных
вершин и диаграмм комплексных моделей. Для устранения этих недостатков
предложен аппарат многоуровневых грамматик.
2.2 Разработка метода описания многоуровневых грамматик
анализа диаграмматических нотаций, созданных в процессе
коллективного проектирования [141]
Коллективное проектирование вносит новые требования в вопросы
корректности диаграмм. Виды диаграмм и количество термов увеличивается
многократно. Классическая грамматика становится не читаемой и тяжело
проектируется. При проектировании в коллективе используется комплексные
UML-диаграммы, которые детализируют различные аспекты предметной
области
разными
проектировщиками.
Отличительной
особенностью
комплексной диаграммы является ее многоуровневая структура.
Рассмотрим многоуровневую систему взаимодействующих
грамматик, представленную в виде кортежа из четырех элементов:
RVM  n,  n , RV n , r0  , где
n - индекс грамматики;
 n - алфавит n-ой грамматики;
RV n - множество продукций n-ой грамматики ;
r0 - аксиома грамматки верхнего уровня.
RV-
62
Грамматика RV i содержит в качестве одного из состояний грамматику
RV j . Грамматика RV j также может быть составной.
RV n – грамматикой языка L(G) является упорядоченная пятерка
~
непустых множеств G  (V , , , R, r0 ) , где
V  {vl , l  1, L} - алфавит операций над внутренней памятью;
  {at , t  1, T } - терминальный алфавит
(множество примитивов графического языка);
~
~
графического
~
- квазитерминальный алфавит,
  {a t , t  1, T }
расширением терминального алфавита. Алфавит включает:
языка
являющийся
– квазитермы графических объектов, не являющихся продолжателями
анализа,
– квазитермы графических объектов имеющих более одного входа,
– квазитермы связей – меток с определенными для них семантическими
различиями,
– квазитерм для завершения анализа;
R  {ri , i  1, I } - схема грамматики G (множество имен комплексов
продукций, причем каждый комплекс ri
состоит из подмножества Pij
продукций ri  {Pij , j  1, J } );
r0  R
аксиома RV – грамматики (имя начального комплекса
продукций), rk  R – заключительный комплекс продукций.
Продукция Pij  ri имеет вид P ij :
~
W ( ,..., )
1
n
a t  

 rm , где
Wν (γ1, . . . , γn) – n – арное отношение, определяющее вид операции над
внутренней памятью в зависимости от  {0,1,2,3} ;
rm  R –имя комплекса продукции – преемника.
Грамматика RVni содержит в качестве одного из состояний грамматику
RVnj. Грамматика RVnj так же может быть составной.
63
В структуру внутренней памяти входят стеки для обработки
графических объектов, имеющих более одного выхода, и эластичные ленты
для обработки графических объектов, имеющих более одного входа.
Система RVM получает с входной ленты символы терминального
алфавита и передает их на соответствующий уровень.
Элементы, которые переводят грамматику на другой уровень, назовем
сабтермами. Тогда описание RV n -грамматики принимает вид:
~ 
G  (V , , , , R, r0 ) ,
_
где  – множество сабтермов, т.е. элементов грамматики, переводящих
автомат на следующий более низкий уровень.
Продукция, содержащая сабтерм, имеет вид:
_
W ( ,..., )
 1
n
a t 
 
 rmn ,где
r0n 1
где r0n 1 -комплекс-преемник – начальный комплекс грамматики следующего
уровня, rmn -комплекс-преемник, к которому производится переход при
достижении rkn 1 .
Такую продукцию следует читать так: если с ленты считывается
_
сабтерм a t , тогда выполняем операцию над памятью W . В стек возврата
запишем комплекс и перейдем в комплекс r0n1 . Комплекс r0n1 - начальный
комплекс подграмматики, при переходе в который инициализируется
вложенная грамматика. При достижении конечного элемента подграмматики
из стека возврата считывается комплекс rmn и работа продолжается, применяя
правила для данного комплекса.
При использовании многоуровневого описания грамматики возникает
вопрос об использовании памяти. Есть два возможных варианта выполнения
операций с памятью:
 оперировать с единой областью памятью для всех подграмматик;
 для каждой подграмматики использовать свою область памяти.
64
Первый механизм проще в понимании – используется вся доступная
область памяти для всех грамматик, но неудобен для реализации. Для
манипулирования с некоторым типом памяти необходимо эксклюзивно
захватить управление над ним. Для этого нужно промаркировать данный
отрезок как используемый конкретной грамматикой. Например, пусть
грамматика RVi является родительской для грамматики RVj
и они
модифицируют некоторую ленту Lk. Тогда разметка Lk будет выглядеть
следующим образом:
При таком подходе необходимо контролировать, что бы ни одна
операция грамматики RVj не затрагивала области памяти других грамматик.
Это приводит
к необходимости дополнительных проверок на каждую
элементарную операцию, что плохо сказывается на быстродействии
анализатора.
Дополнительные трудности возникают при восстановлении анализа в
случае обнаружения ошибки в диаграмме. При анализе термов необходимо
различать термы, принадлежащие грамматике, и знать, на основании каких
областей памяти проводить восстановление, что дополнительно замедлит
процесс восстановления.
Второй вариант состоит в том, что для каждой грамматики необходимо
выделять отдельную область памяти, в которой может оперировать только
одна грамматика. Тогда при входе в грамматику все указатели на области
памяти смещаются в новую область, и происходит однократная проверка
прав доступа. При переходе в подграмматику необходимо записать указатель
на текущую область памяти, инициализировать новую область памяти и
перевести указатель на вновь инициализированную область памяти.
При таком варианте управления памятью нейтрализация ошибок
происходит как в классической грамматике, но с тем исключением, что при
65
достижении конечного символа подграмматики весь уровень объявляется
ошибочным и производится возвращение на верхний уровень. При переходе
на верхний уровень возвращаемся в согласованное состояние, и возможно
продолжение
анализа.
Автомат,
работающий по
такому принципу,
представлен на рис. 2.1
Магазины
Конечное устройство
управления
Устройство
Выбора
Грамматики
RV1
Устройство
памяти
RV2
Память 2
…
RVn
…
Память m
Память1
Ленты
Рис 2.1. RVH - анализатор
Рассмотрим RVM грамматику для диаграммы активности языка UML.
Грамматика RV0 является главной. Состояниями A0 каждого автомата
обозначены начальные состояния каждой грамматики. При инициализации
подграмматики в нее передается элемент, под воздействием которого
произошел переход в составное состояние.
Существует несколько
представлений
RV-грамматики, наиболее
наглядной является графовое представление. Поэтому переведем табличное
представление грамматики из приложения 3 в графовое рис. 2.1.
На диаграмме квазитермам грамматике сопоставлены строки из
таблицы грамматики из Приложения 3. Рассмотрим запись RI[1]. Эта запись
означает, что переход активируется под действием квазитерма RI и в это
66
время выполняется операции с памятью из табл. П3.1 (строка 1) W1 (it(1))/W3 (it(1) ==
|| it(2) ==
). Часть грамматики представлена в таблице 2.1
Таблица 2.1. Часть многоуровневой RV-грамматики
Комплекс
Квази-терм
r1 0
RI
r1 3
W1 (it(1))/W3 (it(1) ==
|| it(2) ==
)
2.
RE
r1 4
W1 (it(1))/W3 (it(1) ==
|| it(2) ==
)
3.
RG
r1 5
W1 (it(1))/W3 (it(1) ==
|| it(2) ==
)
4.
RI
r1 6
5.
RE
r1 7
6.
RG
r1 8
7.
̅R̅I
r
8.
̅R̅E
r
9.
̅R̅G
r
10.
̅R̅I
r
11.
̅R̅E
r
12.
̅R̅G
r
RA
r1 2
RG
r1 5
пп
1.
13.
r1 1
14.
Комплекс – Комплекс –
преемник
возврата
4
0
4
0
4
0
4
0
4
0
4
0
15.
r1 2
C
r1 0
16.
r1 3
C
r1 0
17.
r1 4
C
r1 0
18.
r1 5
C
r1 0
A
r1 1
C
r1 0
19.
20.
r1 6
…
RV – отношение
r1 3
W1 (it(1))/W3 (it(1) ==
|| it(2) ==
)
r1 4
W1 (it(1))/W3 (it(1) ==
|| it(2) ==
)
r1 5
W1 (it(1))/W3 (it(1) ==
|| it(2) ==
)
r1 6
r1 7
r1 8
W1 (it(2))/W3 (it(1) ==
|| it(2) ==
)
67
Первая схема представляет грамматику в самом общем виде и
определяет
последовательность
вызовов
подграмматик.
Рассмотрим
продукцию для сабтерма:
W ( 2l 2 )
1
P 
 r3
r6
Эта продукция означает следующее: для сабтерма P определена
операция записи W1 количества исходящих связей – 2. При выполнении
данной продукции в стек возврата записывается комплекс r3 и происходит
переход в комплекс r6.
68
Рис. 2.2. Многоуровневая грамматика комплексных UML-диаграмм
69
Рис. 2.3. Комплексная UML диаграмма
Рассмотрим пример комплексной диаграммы UML (рис.
2 3UML
диаграмма). Рассмотрим состояние памяти при достижении анализатором
точки A. Анализ начинается с нулевого уровня – диаграммы Вариантов
70
использования (I – на диаграмме). Область памяти для данной диаграммы
состоит из одной ленты, которая служит для анализа циклических и
дублирующих ссылок. На втором уровне находятся диаграммы Активности II
и III. К моменту достижения точки A анализатор закончит анализ диаграммы
II и память окажется пустой. Память для диаграммы III состоит из элементов
того же типа, что и память II. Память для анализа диаграммы IV состоит из
одного магазина, который контролирует переходы из линий жизни объекта и
возвраты в них. Графическое представление состояния памяти представлено
на рис. 2. 4
Рис. 2.4. Состояние памяти анализатора RV-грамматики
Рассмотрим работу анализатора для комплексной UML-диаграммы. В
табл. 2.2 приведены все вызовы анализатора при анализе данной диаграммы.
Таблица 2.2. Порядок операций RVM-анализатора
№
Комплекс
Уровень I []
1.
r1 0
2.
r1 1
Квази
-терм
Правило
Состояние памяти
L1
A
RG
W1(it(1))/
W3(it(1) =
||it(2) = )
1RG1
L2
71
Таблица 2.3. Порядок операций RVM-анализатора (продолжение)
№
Комп- Квази
лекс
-терм
1
↓Уровень II [r 5 ]
Правило
Состояние памяти
L1
4
3.
4.
5.
6.
7.
8.
9.
10.
r0
r4 3
r4 1
r4 3
r4 1
r4 3
r4 1
r4 3
label
A
label
P
label
A
label
W
11.
12.
13.
14.
r4 1
r4 3
r4 1
r4 3
label
A
label
R
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
r4 1
r4 3
r4 1
r4 3
r4 1
r4 3
r4 1
r4 3
r4 1
r4 3
r4 1
r4 3
r4 2
label
A
label
L
label
A
label
L
label
A
label
L
labelL
28.
29.
30.
31.
32.
r4 3
r4 1
r4 3
r4 1
r4 3
A
label
A
label
W
33.
r4 1
labelW
34. r4 3
Ak
↑Уровень I []
L2
35.
r
5
С
L4
W1 (t1m)
1W1
2P1
2P1
2P1
,t1m)/ 2P1
1W1
1W1
1W1
1W1
3R1
P1
P1
P1
R1 , P1
W1
W1
W1
W1
2P1
2P1
2P1
2P1
2P1
2P1
2P1
2P1
2P1
2P1
2P1
2P1
2P1
1W1
1W1
1W1
1W1
1W1
1W1
1W1
1W1
1W1
1W1
1W1
1W1
1W1
3R1
3R1
3R1
3R1
3R1
3R1
3R1
3R1
3R1
3R1
3R1
3R1
3R1
3L1
3L1
R1 , P1
R1 , P1
R1 , P1
R1 , P1
R1 , P1
R1 , P1
R1 , P1
R1 , P1
R1 , P1
R1 , P1
R1 , P1
R1 , P1
P1
W1
W1
W1
W1 ,L1
W1 ,L1
W1 ,L1
W1 ,L1
W1 ,L1
W1 ,L1
W1 ,L1
W1 ,L1
W1
W1
2P1
2P1
2P1
2P1
2P1
1W1
1W1
1W1
1W1
2W1
3R1
3R1
3R1
3R1
3R1
3L1
3L1
3L1
3L1
3L1
P1
P1
P1
P1
P1
W1
W1
W1
W1
2P1
2W1
3R1
3L1
2P1
2W1
3R1
3L1
W 2 (b 2m)/
W 3 (mt(4)=mt(3))
W 1 (2t(2))/
W 2 (1t(2))
W2 (b2m )
M2
2P1
W1 (1t(1),t2m)/
W2 (et(1))
W1 (it(3)
W3 (k>1)
M1
P1
P1
P1
P1
P1
L1
1
L3
1
RG1
1L1
2L1
L2
W1
72
Таблица 2.4. Порядок операций RVM-анализатора (продолжение)
№
36.
Комплекс
r1 0
Квази
-терм
RG
37.
38.
r1 5
r1 0
A
RG
Правило
Состояние памяти
W1(it(1))/
W3(it(1) =
||it(2) = )
1RG1, 1RG2
W1(it(1))/
W3(it(1) =
||it(2) = )
1RG1, 1RG2
1RG1, 1RG3
↓Уровень III [r1 5 ]
L1
39.
40.
41.
42.
43.
44.
45.
46.
4
r0
r4 3
r4 1
r4 3
r4 1
r4 3
r4 1
r4 3
label
A
label
P
label
A
label
W
W1 (t1m)
W1 (1t(1),t2m)/
W2 (et(1))
47. r4 1
label
4 1
↓Уровень IV [r 3 ,r 5 ]
2P1
2P1
2P1
2P1
2P1
2P1
L2
L3
L4
M1
M2
1W1
P1
P1
P1
P1
P1
W1
1W1
P1
W1
M1
48.
49.
50.
51.
52.
53.
54.
55.
56.
5
r1
r51
r51
r51
r51
r51
r52
r52
r52
A
label
W1 (t1m)
1label1
A
label
1label1
W1 (t1m)
1label1 ,1label2
1label1 ,1label2
A
label
W1 (t1m)
1label1 ,1label2 ,1label3
labelI
W2 (t1m))
1label1 ,1label2
labelI
W2 (t1m))
1label1
labelI
W2 (t1m))
↑Уровень III [r1 5 ]
4
57.
58.
59.
60.
61.
r3
r4 1
r4 3
r4 1
r4 3
A
label
A
label
P
62.
r4 1
label
W1 (t1m)
L1
2P1
2P1
2P1
2P1
2P1 ,
2P2
2P1 ,
2P2
W1
L2
L3
L4
M1
1
1W1
1W1
1W1
1W1
P1
P1
P1
P1
P2 ,P1
M2
W1
W1
W1
W1
W1
1W1
P2 ,P1
W1
73
Таблица 2.5. Порядок операций RVM-анализатора (продолжение)
№
63.
Комплекс
r4 3
Квази
-терм
A
Правило
64.
r4 1
label
65.
r4 3
W
66.
r4 1
label
67.
r4 3
A
68.
r4 1
label
69.
r4 3
W
W 1 (2t(2))/
W 2 (1t(2))
70.
r4 1
labelW
W2 (b2m )
71.
r4 3
W
W 1 (2t(2))/
W 2 (1t(2))
72.
r4 1
labelW
W2 (b2m )
73.
r4 3
Ak
W1 (1t(1),t2m)/
W2 (et(1))
Состояние памяти
2P1 ,
2P2
2P1 ,
2P2
2P1 ,
2P2
2P1 ,
2P2
2P1 ,
2P2
2P1 ,
2P2
2P1 ,
2P2
2P1 ,
2P2
2P1 ,
2P2
2P1 ,
2P2
2P1 ,
2P2
1W1
P2 ,P1
W1
1W1
P2 ,P1
W1
1W1 ,1W2
P2 ,P1
W2 ,W1
1W1 ,1W2
P2 ,P1
W2 ,W1
1W1 ,1W2
P2 ,P1
W2 ,W1
1W1 ,1W2
P2 ,P1
W2 ,W1
1W1 ,2W2
P2 ,P1
W1
1W1 ,2W2
P1
W1
2W1 ,2W2
P1
2W1 ,2W2
2W1 ,2W2
↑Уровень I []
L1
1
74.
75.
r5
r1 0
С
RG
76.
77.
r1 5
r1 0
A
RG
78.
79.
r1 5
r1 0
С
RG
RG1,
t(1)
W1(i )/
W3(it(1) =
||it(2) = )
W1(it(1))/
W3(it(1) =
||it(2) = )
W1(it(1))/
W3(it(1) =
||it(2) = )
L2
RG3
1
1
RG1
1 , 1RG3 , 1RG2
1RG1 , 1RG3 , 1RG2 , 1RG4
1RG1 , 1RG3 , 1RG2 , 1RG4
1RG1 , 1RG3 , 1RG2 , 1RG4 ,
1RG5
2.3 Оценка временных затрат многоуровневых грамматик
RVM – анализатор обладает линейной временной характеристикой
контроля, т.е. время, затрачиваемое на анализ входного списка элементов
74
диаграммы, определяется линейной функцией от его длины и вычисляется по
формуле:
t
c
ck
L
 Ls или t 
 Lk , k  s ,
R
R
Lk
где с – константа реализации алгоритма, показывающая, сколько
команд (операторов) затрачивается на анализ одного объекта при реализации
алгоритма контроля на конкретной ЭВМ, а R -число одновременно
обрабатываемых элементов.
Количество переходов по состояниям автомата ( Ls ) и количество
элементов диаграммы ( Lk ) определяются по следующим формулам:
l
tn
Vin
Lk   (Vi n   v _ out ij n )
n 1 i 1
l
mn
Vin
Vin
j 1
j 1
Ls   ( ( v _ inij n   v _ out ij n ) 
n 1 i 1
j 1
tn

i  mn 1
Vin
(Vi n   v _ out ij n )  no _ label n ) ,
j 1
где
Vin – количество графических объектов i – го типа n – ой грамматики;
v _ inij n – количество входов в j – ый графический объект i – го типа
для n –ой грамматики;
v _ out ij n – количество выходов из j – го графического объекта i – го
типа для n –ой грамматики;
t n – общее количество типов объектов для n –ой грамматики;
mn – количество типов объектов, имеющих более одного выхода
(количество типов меток), используемых для конкретной реализации
диаграммы для n –ой грамматики;
1, если mn  0
no _ labeln  
0, если mn  0 .
75
Тогда k принимает вид
l
mn Vin
Vin
tn
i 1 j 1
j 1
i mn 1
Vin
 ( ( v _ inij n   v _ outij n )  
L
n 1
k s 
Lk
l
tn
Vin
(Vi n   v _ outij n )  no _ labeln )
j 1
 (Vi n   v _ outij n )
n 1 i 1
j 1
Если в грамматике отсутствуют графические объекты, имеющих более
одного входа или выхода ( n, mn  0 ), то получим нижнюю оценку времени.
l
k
tn
Vin
 (Vi n   v _ outij n )
n 1 i 1
l tn
j 1
Vin
n 1 i 1
j 1
1
 (Vi n   v _ outij n )
Значение k достигает максимума в случае, если все типы вершин
графического языка имеют более одного входа и выхода ( n, mn  t n ).
l
k
mn Vin
Vin
i 1 j 1
j 1
 ( ( v _ inij n   v _ outij n )  no _ labeln )
Ls n1

Lk
l
tn
Vin
 (Vi n   v _ outij n )
n 1 i 1
j 1
В этом случае
Vin
Vin
j 1
j 1
 v _ inij n   v _ outij n
mn Vin
Пусть yn   v _ outij n , тогда зависимость приобретает следующий
i 1 j 1
вид
l
 (2  yn  no _ labeln )
k  n1
l
tn
 (Vi n  yn )
n 1 i 1
76
l
k
l
 2  yn
n 1
tn
l

 no _ labeln
n 1
tn
l
 (Vi n  yn )  (Vi n  yn )
n 1 i 1
n 1 i 1
т.к. n, mn  t n , т.е., больше 0, то
l
 no _ labeln  l
n 1
Оценим каждое из слагаемых:
l
 yn
n 1
tn
l
 1,
 (Vi n  yn )
n 1 i 1
l
 no _ labeln
n 1
tn
l

l
l
tn
не превышает единицы.
 (Vi n  yn )  (Vi n  yn )
n 1 i 1
n 1 i 1
Получим оценку верхней границы k  3 .
Таким образом, в зависимости от количества типов графических
объектов графического языка и количества входящих / исходящих дуг (не
исключено, что разных типов) k  1,3 . Время работы одного анализатора
лежит в пределах границ обозначенных на графике (рис. 2. 5)
77
Рис. 2.5. Распределение временных затрат на анализ диаграммы
R число одновременно обрабатываемых элементов ограничивается
количеством параллельных ядер в системе и изменяется в пределах от 1 до
числа физических ядер в обрабатывающей системе. Максимальное число в
большинстве современных вычислительных систем достигает 4096 (для
достижения такого числа потоки не должны иметь исполняемой части).
Среднее же число колеблется в промежутке от 4 до 256.
Стоит отметить, что в худшем случае исследуемая диаграмма
получается полностью последовательной, т.е. квазитермов или нет, или
квазитермы являются последними символами входной цепочки каждой
диаграммы. Получаем, что значение R принадлежит промежутку [1, 256].
Таким образом, временная оценка определяется формулой
t
где k  1,3 , R  1,256
ck
 Lk ,
R
78
2.4 Анализ методов построения онтологий
Существует ряд подходов для построения онтологий из корпусов
текстов [71, 47]. Среди них выделяют три больших группы на базе
основополагающего метода:

статистический;

с использованием методов искусственного интеллекта;

с использованием метаданных языка.
С конца пятидесятых было предложено множество подходов, для
извлечения концептов, понятий и взаимоотношений из текста. Но с середины
девяностых эти исследования получили новый мощный импульс благодаря
возможности использования более сложных и требовательных к ресурсам
статистических методов и методов процессинга естественных языков (NLP,
Natural Language
Processing).
Эти
методы
теперь
используются
в
большинстве алгоритмов для построения онтологии (Soergel и др., 2005) [85].
Метод Райнбергера [49] (Rheinberger и др., 2004) позволяет построить
онтологию из текста. Его основная цель состоит в том, чтобы построить
скелетную онтологию, которая будет наполнена в процессе использования
экспертами. Построение состоит из трех шагов:
 текстовый
корпус
предметной
области
анализируется
поверхностным синтаксическим анализатором;
 строится множество глагольных групп – глагол и его связь с
существительным или прилагательным;
 применяются кластеризующие условия для связывания идентичных
групп и построения связей между группами.
79
Рис. 2.6. Представление онтологии по методу Райнберга [49]
Метод Хана и Ло [108] (2002) строит онтологию предметной области,
начинается с анализа корпуса текстов и используюет кластеризующий
алгоритм на основе онтологии WordNet (рис.
кластеризации
документов
сходных
по
2.2). Базовая иерархия
содержанию
(документы
предоставляются человеком) с последующей интеграцией их в иерархию,
используя алгоритм под названием SOTA. После создания кластера
иерархии, понятия (или тема) присваиваются каждому домену кластера с
использованием восходящего алгоритма присвоения понятия (присвоение
запускается с конечных вершин иерархии). И наконец, понятие внутренних
узлов соотносится с узлами и их гипонимами в WordNet.
Другой метод для создания онтологий использует лингвистические
методы,
которые
происходят
из
Дифференциальной
семантики,
предложенной Бачимонт [125](2002). В этом методе построение онтологии
состоит из трех шагов:

семантическая
нормализация
–
пользователь
выбирает
соответствующие условия домена и нормализует их значение, выражая
80
семантическое различие каждого понятия относительно его соседей. Эти
термы помещаются в иерархию (и пользователь должен поправить
предложенную иерархию);

формализация знаний – используя таксономию, полученную на
первом шаге, для различных термов эксперт устраняет неоднозначность,
чтобы выполнить формализацию знания;

созданная
таксономия
переводится
на
язык
представления
специальных знаний.
Ауссенак-Жиль и др. (2000) [16] предложили метод, который позволяет
создавать модель предметной области, используя инструменты NLP и
лингвистические методы для анализа корпусов. Этот метод использует текст
в качестве начальной точки, но может использовать также другие
существующие онтологии или терминологические ресурсы (например,
толковые словари), чтобы создать онтологию. Они выделили три уровня
образования онтологии:

лингвистический уровень;

уровень нормализации;

формальный уровень.
Первый этап состоит из извлечения терминов и лексических ресурсов
из текста. На уровне нормализации данные элементы кластеризируются и
преобразовываются в понятия и семантические отношения. Затем понятия и
отношения описываются средствами формальных языков. Процесс состоит
из четырех этапов. Первые два этапа образуют лингвистический уровень и
включают: образование корпуса, на котором подготавливают тексты,
относящиеся к данной предметной области, и лингвистическое исследование,
целью которого
является
выбор
соответствующих лингвистических
инструментов для анализа текста. В конце данной фазы образуются понятия
предметной области, отношения, типичные для данной области, и некоторый
список синонимов. Третья фаза – нормализация. Результат этой фазы концептуальная модель, выраженная в форме семантической сети. Ее
81
разделяют на две подфазы: лингвистическая фаза и концептуальная. Во
время лингвистической фазы автор
онтологии выбирает термины и
лексические отношения (например, гипонимы), которые должны быть
смоделированы, тогда он добавляет определение на естественном языке для
этих терминов. Если существует несколько значений для термина,
оставляются только самые существенные для предметной области. Во время
концептуальной фазы понятия и семантические отношения определяются в
нормализованной форме, используя метки понятий и отношений. Последняя
фаза - формализация. Она включает проверку непротиворечивости онтологии
и реализацию. Оценка качества полученного знания делается экспертом. Как
только онтология была доведена до нужного уровня, она может быть
реализована.
Существуют методы построения онтологий, использующие в качестве
базы анализа словари. Рассмотрим подход, описанный Джанник и
Виедхолдом [99] (1999). Подход использует алгебру извлечений для
преобразования данных из словаря в их графическое представление. Для
представления используется связь между определяемым словом и его
определением.
В результате получается направленный граф с двумя
специфическими свойствами: каждое определяемое слово и определение
сгруппированы в узле и каждое слово в узле определения имеет связь к узлу,
c главным словом. Основная гипотеза этого подхода – структурное
отношение между терминами, относится к их значению. Они извлекаются в
три этапа с использованием статистического алгоритма PageRank для
определения силы отношения.
Кроме корпусов текстов и словарей можно строить онтологии на
основе баз знаний. Один из алгоритмов предложен Сиранто и Комптон [64]
(2001). Авторы предлагают алгоритм, чтобы извлечь таксономию классов,
где класс – множество разнородных правил, которые приводят к тому же
выводу. Алгоритм, опираясь на исходные деревья, создает множество
классов, пытаясь обнаружить взаимоотношения между ними. Авторы
82
алгоритма предлагают использовать три вида отношений: категоризация,
взаимоисключение, подобие.
Основополагающая идея этого подхода состоит в том, чтобы
сгруппировать все правила в каждом классе и вычислить количественные
показатели для каждого отношения между парами терминов в некотором
классе. Эти количественные оценки показывают вероятность существования
того или иного отношения между понятиями. При окончании анализа
классов
онтологии и отношений внутри них онтология считается
завершенной. Весь процесс производится вручную.
Для построения онтологии по графическому описанию домена не
подходят методы извлекающие данные из полностью формальных систем.
Таким образом, наиболее подходящим является алгоритм, строящий
онтологии на основе корпусов текстов. Статистические методы построения
онтологий накладывают ограничение на размеры входного массива текстов.
Чем больше этот объем, тем качественнее будет итоговая онтология. Если
строить онтологию на основе отдельной диаграммы, то ее качество будет
низким. Поэтому остаются методы построения на основе лингвистических
особенностей языка.
2.5 Анализ языков описания онтологий
Для применения онтологического анализа в процессе коллективного
проектирования необходимо определить методы и средства описания
онтологий. Существует несколько базовых метода описания онтологии
какого-либо языка. Большинство существующих онтологий базируются на
трех основных моделях онтологии:

eCOIN – Extended Context Interchange;

OWL – Web Ontology Language;

RuleML – Rule Markup Language.
Рассмотрим модели предлагаемых выше языков описания онтологии.
83
eCOIN [32] предлагает использовать гибридную технику описания на
основе слабо- и сильно- связанных отношений по интеграции данных в
гетерогенной среде знаний. Формализм eCOIN был первым среди остальных
формализмов и был описан Гохом [21] и позже реализован Фиратом [2].
Формализм базируется на следующих компонентах:
 модель предметной области – коллекция типов верхнего уровня,
называемых семантическими типами. Модель области описывает словарь
типов, атрибутов и модификаторов для каждого семантического типа.
Семантические типы в целом определяют область применения описываемых
данных;
 теория «поднятия» (elevation theory) – состоит из набора аксиом
«поднятия», которые определяют типы и источники данных, а также их
согласование с семантическими данными внутри модели области;
 теория
контекстов
включает
описание
состояний,
которые
обеспечивают связывание значения и модификатора, либо определяют
функцию преобразования, которая может использоваться в качестве базиса
по переводу характеристик объектов в различных контекстах.
Аксиомы языка eCOIN описаны на основе операторов языка
программирования Prolog. Коллекция аксиом представлена как расширение
языка пролог eCOIN FOL/Prolog. Реализация онтологии в данном языке
заключается в программировании на данном языке.
Web Ontology Language [73, 72] (OWL) – язык спроектированный для
использования
программными
средствами
автоматического
анализа
семантического представления документа. В отличие от других языков
проектировался как «понятный» компьютеру, но не человеку, язык описания
онтологии. OWL значительно упрощает машинный анализ сетей знаний. Это
обеспечивается такими составляющими как поддержка XML, RDF и RDF
Schema (RDF-S). OWL имеет три разновидности языка: OWL lite, OWL DL,
OWL Full.
84
OWL является следующим шагом консорциума W3C [113] в борьбе за
семантический Веб.
XML позволяет описать правильный синтаксис для документов в сети,
но не предоставляет возможности по анализу семантики.
Схема XML – описание структуры XML документа и введение понятия
тип данных в XML.
RDF модель данных вида сущность-связь представляет простую
семантическую модель данных (данная модель может быть представлена при
помощи XML).
Схема RDF – словари, описывающие свойства и классификации
ресурсов RDF, с семантической иерархией понятий.
OWL добавляет еще больше словарей для описания семантики
отношений в онтологии.
Существует методология SBVR [22, 82] описания семантики бизнеспроцессов на основе синтеза UML диаграмм и языка OWL.
SBVR – позволяет создавать информационную модель АС путем
автоматизированного преобразования UML-диаграмм АС в описание
онтологических аспектов системы.
OWL представляет три различных варианта языка:
 OWL Lite подходит для описания области, в которой требуется
простая иерархическая классификация и несложные ограничения.
 OWL DL подходит тем, кто хочет получить максимальную
предсказуемость анализа. Язык гарантирует, что любой поиск по онтологии
будет закончен и закончен за конечное число шагов. В языке содержатся все
конструкции
OWL,
но на их использование наложены некоторые
ограничения;
 OWL Full подходит тем, кто хочет получить максимальную свободу
языка RDF. Платой за такую свободу служит отсутствие гарантий на
конечность вычислений.
85
Каждый из этих диалектов - расширение его более простого
предшественника, и в том, что касается выразительных возможностей, и в
том,
что
касается
возможностей
производимых
заключений.
Поддерживаются следующие отношения, но не наоборот.
 каждая допустимая OWL Lite онтология - допустимая OWL DL
онтология;
 каждая допустимая OWL DL онтология - допустимая OWL Full
онтология;
 каждое правильное OWL Lite заключение - правильное OWL DL
заключение;
 каждое правильное OWL DL заключение - правильное OWL Full
заключение.
Разработчики онтологий, использующие OWL, должны решить, какой
из диалектов лучше подходит к их задачам. Выбор между OWL Lite и OWL
DL зависит от степени того, насколько пользователям требуются более
выразительные конструкции, обеспечиваемые OWL DL. Выбор между OWL
DL и OWL Full, главным образом, зависит от степени того, насколько
пользователям требуются средства мета-моделирования схем RDF.
Rule Markup Language (RuleML) [53, 88] – язык онтологии основанный
на XML,
использующий формальную семантику и нацеленный на
эффективность реализации. Описание правил может быть на естественном
языке, формальной нотации или быть комбинацией двух предыдущих. Язык
RuleML использует последний подход, комбинируя формальные правила и
описания на естественном языке. Данный подход позволяет сформировать
более широкую онтологию, но при этом приходится отказаться от
гарантированной обработки текстов грамматикой этого языка.
В таблице приводится сравнение языков по некоторым признакам:
86
Характеристика
eCOIN
OWL
RuleML
Общие характеристики
Развивается
-
+
+
Документация
+
+
+
Атрибуты экземпляра
-
+
-
Атрибуты класса
+
+
+
Локальная видимость
+
+
+
Глобальная видимость
+
+
-
Ограничение на типы
+
+
-
Язык ограничений
-
-
+
Инструменты автоматизации
+
+
+
Возможность машинного анализа
-
+
-
Атрибутика
Особенности
Все языки подходят для описания онтологий, но язык OWL обладает
некоторыми преимуществами – язык развивается и единственный без
модификаций позволяет производить гарантированный машинный анализ.
Поэтому для описания онтологии выбран Ontology Web Language.
2.6 Исследование алгоритмов объединения онтологий
При контроле семантической корректности семантики диаграммы в
процессе коллективного проектирования одним из этапов является
объединение построенной семантической схемы и семантической сети
проектной области. В области обработки текстовых данных существует
задача объединения онтологий. Эта задача решает проблемы схожие с
исследуемой.
Рассмотрим,
какие существуют решения
объединения
онтологий.
Существуют два принципиально различных подхода к объединению
онтологий
отображении
–
отображение
онтологии
(mapping)
соответствия
и
интеграция(merging).
между двумя
При
онтологиями
обнаруживаются отдельно от онтологий и, таким образом, находятся вне
87
самих онтологий. Соответствия могут использоваться для верификации
разнородных баз знаний, используя общий интерфейс или преобразовывая
данные
между
различными
типами
представлениями.
Полу
автоматизированный или автоматизированный поиск таких соответствий
называют выравниванием онтологии.
Когда производят операцию интеграции онтологий, создается новая
онтология, представляющая собой объединение исходных онтологий.
Интегральная онтология содержит все знание из исходных онтологий.
Главная проблема в интеграции онтологий состоит в том, чтобы
гарантировать,
что
все
похожие
элементы
остались
похожими в
интегральной онтологии, а все различное остались различными.
Существует несколько подходов к объединению онтологий. Главная
задача всех этих подходов – обнаружение и уточнение соответствия и
различий между понятиями, отношениями и экземплярами в различных
онтологиях. Для лучшего понимания проблематики, которые все эти
подходы пытаются преодолеть, сделаем обзор противоречий, которые могли
бы возникнуть между различными онтологиями (в основу обзора возьмем
работы Клейна) [116].
Два основных типа несоответствий онтологии:
1) несоответствия
концептуализации
– несоответствие различных
определений одного и того же понятия;
2) несоответствия объяснения – несоответствие способов объяснения
одного и того же понятий.
Ошибки концептуализации делится на две категории:
1) граничные промахи происходят, когда у двух классов есть некоторое
перекрытие в их расширениях (набор экземпляров), но расширяющие
экземпляры
не
Налогоплательщик);
эквивалентны
(например,
понятие
Студент
и
88
2) несоответствие в покрытии и детализации модели возникает, если
есть
рассогласованность
между
двумя
областями
одновременно
присутствующих в обеих онтологиях или уровене детализации, которым
описаны модели (например, у одной онтологии могло существовать только
одно понятие Человек, тогда как другая онтология различает Младенца,
Юношу и Старика).
Существует
три
глобальные
причины
возникновения
таких
рассогласований:
1) стилистика оформления онтологий, либо способ описания понятий
сильно различается;
2) понятийное
несоответствие
–
два
эквивалентных
понятия
представляются с использованием различные имена (проблема синонимии)
или когда то же имя используется для различных понятий (проблема
омонимии);
3) несоответствие представлений – значения в различных онтологиях
закодированы по-разному (например, используются различные меры длинны
или веса).
При объединении онтологий в процессе коллективного проектирования
наиболее остро стоит проблема номер два. Традиционно при проектировании
существует ограничение на использование терминов, что позволяет в
большинстве
случаев
избежать
проблемы
стилистики
понятий.
Несоответствие представлений избегается ограничениями, наложенными на
проектную деятельность. Использование различных единиц измерения
скорее
свидетельствует
об
ошибке,
либо
снабжено
специальными
механизмами конвертации, отображенными в диаграммах.
Рассмотрим механизмы слияния онтологий. Отображение онтологии –
(декларативная) спецификация семантического перекрытия между двумя
онтологиями.
89
Соответствие между различными объектами этих двух онтологий
обычно выражается с помощью аксиом, сформулированных на определенном
языке отображения. В процессе отображения обычно присутствуют 3 фазы:
1) поиск перекрытия онтологий;
2) отображение перекрытия;
3) отображение вариантов употребления/применения.
Большинство
существующих подходов
отображения
онтологий
(например, MAFRA, RDFT ), используют подход составления словарей для
представление отображений.
MAFRA (MApping FRAmework для распределенных онтологий)[55, 95]
(2002) система поддержки интерактивного, инкрементного и динамического
процесса отображения онтологии. Заключительная цель такого процесса
состоит в том, чтобы результат преобразования был согласован. Это
относится ко всем фазам процесса отображения:

подъем и нормализация – приведение онтологий к RDF-S и
нормализации их словарей с устранением синтаксических и лексических
различий;

выявление подобия – вычисление общих черт между объектами
онтологии как этап поддержки поиска перекрытия;

составление семантических переходов – расставление соответствий
между подобными объектами в форме так называемых семантических
переходов – собствено этап определения отображения

выполнение – построение объединѐнной онтологии, используя
переходы/отображение;

постобработка – проверка полученной онтологии с целью
уменьшения количества ошибок.
Существует библиотека готовых семантических переходов Semantic
Bridging Ontology [23] (SBO). Используя эту библиотеку, можно существенно
сократить время построения онтологии.
90
Семантический переход содержит пять харатеристик:

объект - описывает объекты, связанные отношением перехода.
Может быть понятием, отношением, атрибутом и расширяющим шаблоном;

количество элементов - описывает размерность элементов на
концах отношения перехода (традиционно используется 1:n или m:1,
значительно реже m:n);

структурность - определяет способ, которым переходы нижнего
уровня могут быть объединены в более сложный переход;

преобразование - описывает, как экземпляры будут преобразованы
с использованием функции перехода;

ограничения - позволяет выражать условия, от выполнения которых
зависит применимость перехода. Правило преобразования, связанное с
мостом, не выполняется, если эти условия не выполняются.
RDFT [67, 68] (2002) является отображающейся метаонтологией для
того, чтобы отобразить XML данные на схемы языка RDF с прицелом на
решение задачи взаимодействия распределенных сервисов.
Самый важный класс метаонтологии – переход (Bridge), который
позволяет определить соответствие между одним объектом и рядом объектов
или наоборот, в зависимости от типа перехода: один ко многим или многие к
одному. Отношение между исходными и целевыми компонентами перехода
может быть отношение эквивалентности (утверждает, что эквивалентность
между
этими
двумя
компонентами)
или
отношение
версионности
(утверждает, что целевой набор элементов формирует более позднюю
версию исходного набора элементов, принимая идентичные домены для
двух).
C-OWL [18, 100] другой подход к отображению онтологий, который
является языком, расширяющим язык OWL. Расширение происходит как
синтаксически,
так
и
семантически
для
получения
возможности
представления контекстных онтологий. Термин контекстная онтология
91
применяется потому, что элементы онтологии связаны с локальным
контекстом, и они могут быть перенесены в другую онтологию через явные
отображения (правила перехода). Этот механизм, в отличии от правил
импорта OWL, извлекает множество локальных моделей предметной области
объединѐнных в более глобальную модель предметной области.
Семантика
локальных
моделей,
определенная
для
C-OWL,
в
противоположность глобальной семантике OWL, полагает, что каждый
контекст использует локальный набор моделей и локальные области
интерпретации. Таким образом, предоставляется возможность объединить
онтологии с противоречивыми аксиомами.
PROMPT [65, 64] (2000) название алгоритма и интерактивного
инструмента, реализующего его для слияния двух онтологий. Центральный
элемент PROMPT – алгоритм, который определяет последовательность
шагов для интерактивного процесса слияния:

обнаружение ключевых кандидатов для слияния на базе схожести
классов и имен. Результат представляется пользователю как список
потенциальных операций слияния;

пользователь выбирает одну из предложенных операций из списка
или определяет работу слияния вручную;

система исполняет требуемое действие и автоматически выполняет
дополнительные изменения, вытекающие из действия;

система создает новый список потенциальных действий для
пользователя, базируясь на новой структуре онтологии, выявляет конфликты,
вытекающие из последнего действия, находит возможные решения этих
конфликтов и предлагает их.
PROMPT идентифицирует множество операций слияния онтологий
(классы слияния, слоты слияния, привязка слияния между слотом и классом,
и
т.д.)
и
множество
использовании
этих
возможных конфликтов,
операций
(конфликты
имен,
образующихся
повисшие
при
связи,
92
избыточность в иерархии классов и ограничениях значения слота, которые
нарушают наследование классов).
OntoMerge [66] (2002) является онлайновым подходом, в котором
исходные онтологии сохраняются после операции слияния, тогда как в
PROMPT объединенная онтология заменяет исходные онтологии. Результат
работы слияния в OntoMerge не полная объединенная онтология, как в
PROMPT, а онтология перехода, которая импортирует исходные онтологии и
у которой есть много так называемых Аксиом Образования переходов.
2.7 Разработка метода анализа и контроля семантических ошибок
диаграмм при коллективном проектировании [139, 141]
При коллективном проектировании в группах важным является
контроль
непротиворечивости
комплекса
составляемых
диаграмм.
Проектировщики, составляя диаграммы, могут забыть учесть принятые ранее
решения (отраженные на диаграммах). Например, проектировщик может
конкретизировать некоторый компонент системы и упустить из внимания тот
факт, что на предыдущих этапах подобный компонент был реализован с
применением других технологий.
Для анализа на семантическую корректность предлагается составить
многоуровневую грамматику. Верхний уровень композиционной грамматики
будет грамматика диаграмм вариантов использования, потому что разработка
систем должна начинаться именно с этой диаграммы (согласно методологии
RUP). В процессе анализа будет накапливаться семантическая информация о
предметной области, и каждая новая диаграмма будет добавляться в общую
структуру на условиях непротиворечивого расширения понятий предметной
области.
При построении первых диаграмм проверяются только семантическая
непротиворечивость
внутри
диаграммы.
Проверяется
возможность
использования понятий в семантической паре. При добавлении новых
93
диаграмм проверяется непротиворечивость диаграммы обособлено и на
непротиворечивость комплексной модели проектируемой АС (рис. 2.7).
Рис. 2.7. Общая схема онтологического анализа UML диаграмм
Для проверки комплексной модели необходимо построить граф
семантических связей между элементами АС. Для решения данной задачи
выбран адаптированный метод лексико-синтаксических шаблонов.
В настоящее время существуют два больших класса методов
извлечения знания из корпусов текстов – статистический и метод шаблонов.
Каждый из них имеет как преимущества, так и недостатки. Статистический
метод главным образом ориентирован на обработку потока данных. Методы
данного класса тем лучше, чем больше объемы исследуемых текстов.
Методы, основанные на шаблонах, используют информацию о целевом языке
для извлечения данных. Для методов этого класса характерно отсутствие
зависимости
от
объемов
исследуемого
корпуса данных.
Так как
диагностирование ошибок важно с самых ранних этапов, был выбран метод
из второй группы – метод лексико-синтаксических шаблонов.
Кратко
шаблонов.
опишем
классический
Лексико-синтаксические
метод
шаблоны
лексико-синтаксических
позволяют
построить
семантическую конструкцию, которая соответствует концептуальному
94
содержанию единицы текста. Для этого используются особенности языка, на
котором представлен текст. При анализе текстов используется отношение
сочетаемости текстовых единиц – коолокация. Данное отношение говорит о
фиксировании некоторых синтаксических и грамматических свойств в
лексических единицах.
В графических грамматиках лексической единицей является терм
(сабтерм) грамматики в паре с текстовыми характеристиками, погруженными
в него. Из таких единиц составляется семантический граф диаграммного
языка. Пусть элемент представляющий сущность на диаграмме будет
называться блок, а связи между блоками – связями. Для наглядности
предположим, что в блоках присутствует элементарные понятия (одиночные
или составные).
Обозначим блоки через символ NP, а отношение через rel. Для
диаграммы вариантов использования имеем 3 вида отношений rel:
Включение и Расширение – отношение «часть-целое»;
Агрегации – отношение «выше-ниже»;
Связь – недетерминированное отношение.
Тогда таксономию онтологии составят блоки NP. Онтологические
отношения строятся на отношениях rel. Для этого используется правила вида
NPi + rel + NPj.
Правило для связи включения диаграммы вариантов использования
определяет, что NPj является понятием верхнего уровня для понятия NPj.
Для
реализации
модифицированного
метода
необходимо
модифицировать правила продукций классической RV-грамматики. После
выполнения
извлечения
правила
продукции
семантической
необходимо
информации
диаграмматики. Правило примет вид:
из
запустить
графического
процедуру
элемента
95
W ( ,...,  )
at (  ) 1n rm ,
где  - процедура извлечения семантической информации.
Процедура состоит из поиска соответствующего правила в списке.
Правило состоит из двух частей – replacement и pattern. Часть pattern
описывает
лексико-синтаксический шаблон.
Часть
block определяет
квазитерм, к которому может быть применен шаблон, часть text –
синтаксические характеристики текста в данном квазитерме.
Часть
replacement определяет местоположение данной текстовой единицы в
частичном семантическом дереве диаграммы. Ниже приведен пример
правила, для квазитерма Actor диаграммы вариантов использования.
<rule>
<pattern>
<block>
<type>actor</type>
</block>
<text>
<type>noun</type>
</text>
</pattern>
<replacement>
<place>actor</place>
<value>text</value>
</replacement>
</rule>
Остальные правила приведены в приложении 4.
Все следующие диаграммы образуют собственную мини-онтологию и
должны быть согласованы с общей онтологией предметной области.
Объединение онтологий состоит из следующих этапов:
1) отображение онтологии;
96
2) выравнивание онтологий;
3) объединение онтологий.
Отображение онтологии – процесс определяющий связующие звенья.
На данном этапе происходит поиск точных совпадения текстовых единиц,
совпадений в иерархических отношениях. Последнее обозначает поиск пары
текстовых единиц находящихся в некотором иерархическом отношении
(например, часть-целое). Примерами таких текстовых единиц могут быть
АС-компонент, компонент-класс, класс-метод.
Выравнивание онтологий – это процесс поиска похожих мест в
объединяемых онтологиях. Выявленные на этапе отображения онтологий
пары подвергаются дальнейшему анализу. Цель такого анализа найти группы
похожих между собой пар. Степень похожести определяется применением
пар в одинаковых правилах в онтологии.
Объединение онтологий – процесс создания одной онтологии из двух
исходных. На основе выявленных на предыдущем этапе групп строится
объединѐнная онтология. Общей частью являются выделенные ранее группы.
Если на этапе объединения не получается найти объединяющего звена,
то выдается предупреждение об ошибке. Такое предупреждение может
сигнализировать о слишком большой разрозненности спроектированных
диаграмм. Для устранения ошибок такого типа можно либо уточнить
существующую диаграмму, либо добавить новую связующую.
Если объединение онтологий прошло удачно, то проводится анализ
значимых характеристик онтологий для оценки корректности онтологии.
Рассмотрим пример онтологического преобразования. В качестве
базовой диаграммы возьмем часть диаграммы Вариантов использования рис.
2 8. Для наглядности был выбран пример с небольшим числом элементов.
97
Рис. 2.8. Диаграмма вариантов использования и ее онтологическая модель
К данной диаграмме применяются следующие шаблоны:
block{type: actor} –> Resource > Actor [value: name]
block{type: usecase} & block{value: name} == verb –> Action[value:
name]
block{type:
usecase}
&
block{value:
name}
==
noun
–>
Resource>Action[value:name]
Рассмотрим, что обозначает шаблон block{type: usecase} & block{value:
name} == verb –> Action[value: name]. В левой части записано условие,
состоящее из двух частей объединѐнных символом &. Это означает, что
шаблон применим при одновременном выполнении обоих частей условия.
Первая часть условия означает, что правило применимо для блока тип
вариант использования. Вторая часть – текст в блоке, являющийся
существительным. В итоге получается, что правило применимо для
существительного в блоке вариант использования.
Вторая часть означает, какое место в иерархии должно занять значение
из правила. В данном случае правило означает, что выделенный на первом
этапе фрагмент должен быть помещен в онтологическую сеть под понятием
Action.
98
Предположим, на втором этапе разбиралась диаграмма, часть которой
представлена на рисунке ниже, и в результате получилась следующая
семантическая сеть:
При объединении онтологий выявляются следующие опорные
элементы: Action, Content, Actor. Результат объединения представлен на
следующем рисунке:
При анализе получившейся диаграммы сеть разложится на две части.
Такой результат означает, что диаграммы описывают разные варианты
использования и не согласованы между собой. Такой результат может быть
из-за внесения диаграммы из другого проекта, из-за не правильно
99
составленной диаграммы или из-за отсутствия связующей диаграммы. В
каждом из этих случаев разработчику выдается сообщение об ошибке, и
вторая диаграмма помечается как ошибочная. Проектировщик может
отказаться использовать вторую диаграмму или дополнить ее, что бы
диаграммы стали семантически согласованными.
2.8 Выводы
При коллективном проектировании АС создаются иерархические
1.
комплексные диаграммы.
Для анализа и контроля таких диаграмм
предлагается авторский аппарат многоуровневых грамматик.
Аппарат многоуровневых RV-грамматик позволяет оперировать с
2.
каждым уровнем изолировано, что позволяет проводить анализ параллельно.
Такая
возможность
позволяет
сократить
время
анализа
за
счет
одновременного анализа нескольких диаграмм.
3.
Анализ методов построения онтологий показал широкое развитие
разнообразных методов и алгоритмов формирования онтологий предметной
области. Для задачи формирования онтологии на базе диагрмматики бизнес процессов наиболее оптимальными является метод лексико-синтаксических
шаблонов.
4.
Анализ методов объединения онтологий выявлил достоинства
метода C-OWL. Этот метод позволяет объединять онтологии каждой
диаграммы бизнес-процесса с обобщенной онтологией предметной области.
5.
открывает
В коллективной разработке АС работа проектировщиков
дополнительные
источники
сложно
диагностируемых
распределенных по множеству диаграмм ошибок. Данные ошибки трудно
диагностируются, и их позднее обнаружение может увеличить время
стоимость разработки.
6.
понятий,
При работе в коллективе важно контролировать согласованность
используемых
в
комплексных
диаграммах.
Для
анализа
семантической составляющей диаграмматики предложен метод анализа и
контроля семантических ошибок диаграмматических нотаций бизнес-
100
процессов в составе комплексной
диаграммы, созданной в процессе
коллективного проектирования, на основе автоматных графических RVграмматик, отличающийся использованием графовой модели отношений
понятий семантической текстовой информации диаграмм и позволяющий
расширить класс ошибок, диагностируемых в процессе проектирования АС,
и, тем самым, сократить время проектирования АС.
7.
Семантический контроль комплексных диаграмм, позволяет
контролировать ошибки, распределенные по различным диаграммам. При
семантическом контроле создаваемое комплексное представление о АС
становится согласованным и непротиворечивым.
8.
Предлагаемый метод к анализу семантического наполнения
диаграмматики бизнес-процессов
позволяет диагностировать ошибки
несогласованности понятий на ранних этапах разработки АС. Ранняя
диагностика таких ошибок позволяет сократить время разработки за счет
уменьшения итераций, связанных с их исправлением.
101
Глава 3. Разработка метода синтеза RV-грамматик и алгоритма
нейтрализации ошибок грамматики диаграммных нотаций
бизнес-процессов
В данной главе исследуются методы и организация метатрансляции на
основе
RV-грамматик.
диаграмматических
разрабатывается
Предлагается
нотаций
система
бизнес-процессов,
правил
на
основе
описания
которой
алгоритм синтеза автомата RV-грамматик, включая
операции с внутренней памятью.
Второй
вопрос,
рассматриваемый
нейтрализации
ошибок
при
анализе
представления
бизнес-процессов.
в
главе,
касается
диаграмматических
Исследуются
известные
задачи
моделей
методы
нейтрализации в плане их возможного применения в автоматных RVграмматиках. В результате такого анализа сделан выбор на группе методов,
использующих множество термов-продолжателей. Разрабатывается алгоритм
автоматической генерации множества пар продолжателей на основе правил
автоматных грамматик.
Представим графически общую схему синтеза и применения готовой
RV-грамматики (рис. 3.1)
Рис. 3.1. Обобщенная схема синтеза и применения RV-анализатора
Процесс создания анализатора начинается с разработки правил
графической грамматики. Метакомпилятор преобразует правила в таблицу
102
грамматики целевого языка, понятную RV-анализатору. По данной таблице
алгоритм формирования списка продолжателей строит множества пар
продолжателей. По окончании этих этапов RV-анализатор готов к работе. На
вход ему подаются анализируемая диаграмма, нужная грамматика и
множество пар продолжателей для восстановления в случае нейтрализации
ошибки. Результатом работы является список и местоположение ошибок,
содержащихся в данной диаграмме.
3.1 Инструментальные средства метатрансляции
Для создания парсера или компилятора формального описания
некоторого
целевого
языка
используют
программы
класса
метакомпиляторов. Подавляющее большинство современных программ
данного класса это компиляторы парсеров. В качестве формального описания
чаще всего используют запись языка в форме Бэкуса-Наура (БНФ) –
формальная система описания синтаксиса, в которой одни синтаксические
конструкции последовательно определяются через другие. Идеальный
компилятор компиляторов по БНФ-описанию и множеству инструкций
целевой архитектуры генерирует готовый к применению компилятор. На
практике современные компиляторы компиляторов плохо интерпретируют
семантику целевого языка, поэтому при проектировании компилятора
компиляторов стоит ожидать только синтаксически верной интерпретации
языка.
Существует ряд компиляторов компиляторов, среди которых наиболее
известны следующие:
 ANTLR [76, 7];
 Bison [29, 13];
 Coco/R [62, 104];
 DMS Software Reengineering Toolkit [10, 28];
 Lemon [56, 105];
103
 YACC [77, 54].
Рассмотрим принципы работы компилятора компиляторов на примере
YACC. YACC выбран в качестве примера, потому что является одним из
универсальных инструментов и обладает полнотой свойств присущих
инструментов его класса.
YACC использует классическое БНФ-описание грамматики для
работы. Это описание подготавливается проектировщиком языка. По
описанию генерируется функция контроля входных символов – parser.
Внутри этой функции вызывается функция более низкого уровня – функция
лексического анализа. Лексический анализатор считывает символы с
входного потока и преобразуют их в токены (tokens), используемые в БНФ
описании. Токены собираются в правила. Когда одно из правил полностью
собрано, вызывается код, сопоставленный с этим правилом. Такой код в
терминах YACC называется действие – action.
Центральное место в работе компилятора компиляторов занимает
набор правил грамматики языка. Каждое правила описывает какую-либо
синтаксическую конструкцию языка. В некоторых случае при работе
входной сигнал не соответствует описанной грамматике языка. В таком
случае вызывается правило нейтрализации ошибок (error_handling). Это
правило должно описывать поведение компилятора в случае ошибки и
переводить его в какое-то валидное состояние.
Рассмотрим подробнее каждый из этапов работы парсера языка,
написанного на YACC.
Лексический анализ
Задача лексического анализатора – преобразование входных сигналов в
токены «понятные» парсеру. В YACC существует специальная функция
yylex, которая считывает
очередной символ из входной цепочки и
преобразует его в предопределенный токен. Например, она преобразует
цифры от 0 до 9 в токен DIGIT.
104
Парсер
Задача парсера - преобразовать исходный код программы в целевой
язык. Модель парсера представляет собой конечный автомат со стеком с
сигналами,
позволяющими
изменять
его
состояние.
Парсер
имеет
возможность прочитать следующий входной токен (вызвав функцию
lookahead). Текущее состояние всегда будет находится на вершине стека.
Существует четыре сигнала, изменяющие состояние автомата: сдвиг
(shift), свертка (reduce), применение (accept)
и ошибка (error). Действие
анализатора определяется следующим алгоритмом:
 в зависимости от текущего состояния парсер определяет, нужен ли
ему следующий токен для выполнения текущего действия. Если нужного
токена нет, то вызывается лексический анализатор;
 опираясь
на текущее состояние и следующий токен (при
необходимости), парсер выполняет текущее действие и переходит в новое
состояние. Действие может положить новое состояние в стек или извлечь
одно из состояний из стека.
Самая часто используемая операция парсера – сдвиг. Данная операция
выполняет следующие действия: добавляет текущее состояние на вершину
стека и переводит автомат в новое состояние.
Следующая операция – свертка. Операция применяется, когда
обнаружена правая часть правила. При обнаружении правой части в стеке,
верхушка стека заменяется на один символ, являющийся левой частью
правила.
Конфликты и неоднозначность
Иногда случается, что некоторое множество правил неоднозначно и
некоторая входная последовательность может быть разобрано разным
набором правил. Примером такого правила может служить правило expr ‗-‗
expr.
105
Если во входной последовательности имеется expr ‗-‗ expr ‗-‗ expr, то ее
можно разобрать двояко (в скобках правая часть правила):
1) (expr ‗-‗ expr) ‗-‗ expr = expr ‗-‗ expr,
2) Expr ‗-‗ (expr ‗-‗ expr) = expr ‗-‗ expr.
В парсере возникает противоречие, какие правила надо применять
сдвиг-свертка-сдвиг-свертка или свертка-сдвиг-свертка. Такое противоречие
называется конфликтом типа «сдвиг/свертка». Для разрешения такого
конфликта введено несколько правил поведения по умолчанию:
 в случае конфликта «сдвиг/свертка» использовать действие сдвиг;
 в случае конфликта «свертка/свертка» использовать правило,
которое объявлено раньше в наборе правил.
Обработка ошибок
Обработка ошибок компилятором очень сложная задача, требующая
учета семантики конечного языка.
В момент обнаружения ошибки
необходимо привести дерево разбора в состояние, пригодное для
продолжения разбора, перевести указатель текущего токена в необходимую
позицию во входной цепочке символов и отразить, что обнаружена ошибка в
разборе текущего предложения языка. Анализ методов восстановления при
обнаружении ошибок приводится далее в этой главе.
При обнаружении ошибок автомат разбора в процедуре парсинга
переводится
в
специальное
состояние
error,
которое
применяет
предопределенные правила и алгоритмы для восстановления разбора.
3.2 Разработка структуры метакомпилятора диаграмматических
нотаций бизнес-процессов на примере языка UML [129]
Процесс метакомпиляции состоит из следующих этапов:
1) лексический разбор описания диаграммного языка;
2) синтаксический разбор и построение дерева разбора;
106
3) анализ дерева разбора и построение промежуточной структуры
грамматики в терминах языка спецификаций;
4) трансляция – преобразование внутреннего представления в термины
RV-грамматики;
5) оптимизация и минимизация;
6) сохранение таблиц RV-грамматики в формате XML.
В процессе анализа описания диаграммного языка метакомпилятор
формирует набор паросочетаний между терминальными символами языка,
строит таблицу переходов автомата RV-грамматики и генерирует набор
операций
с
памятью
для
контроля
соответствия
вложенности
нетерминальных символов и блоков с количеством входов или выходов
больше одного.
«Отделение» описания RV-грамматики от ее анализатора позволяет
использовать полученный XML-файл на разных платформах вне зависимости
от того, с каким приложением интегрирован анализатор.
Метакомпилятор
представляет
собой
консольное
приложение,
написанное на C# с использованием GOLD Parser Builder [34] для разбора
языка метаописаний. Структура взаимодействия его компонентов в составе
проекта показана на рис. 3.2.
107
Грамматика
языка
спецификаций
GOLD Parser
Builder
Описание
грамматики
правил
Таблица
разбора языка
спецификаций
Компилятор
языка
спецификаций
XML
представлени е
RVграмматики
Открытый код
RV-
анализатора
Внешний целевой проект
Рис.
3.1 Рис
Структура
метакомпилятора
диаграммныхдиаграммных
языков
3.2. Структура
метакомпилятора
диаграммныхязыков
языков
Рис..
1. Структура
метакомпилятора
Разбор диаграмм происходит с помощью RV-грамматик.
Правила описания синтаксиса языка диаграмм активности
UML
Для описания были разработаны правила расширяющие нотацию БНФ.
Подобное расширение позволяет производить описание графических
конструкций в виде, наиболее похожем на их визуальное представление.
Правая часть правила разделяется на две группы – блоки и связи между
ними. Связи, в свою очередь, делятся на внутренние, связывающие элементы
внутри, и внешние, связывающие правило с «внешними» элементами.
Описание спецификаций диаграммных языков состоит из правил,
содержащих
имя
нетерминального
символа,
следующего
зарезервированного слова Rule, перечисления набора
после
терминальных и
нетерминальных символов, входящих в правило, а также описания
отношений между терминальными и нетерминальными символами внутри
правила.
108
В табл. 3.1 приведены конструкции диаграмм активности и их
метаописания. Рамка, в которую заключены составляющие правил,
обозначает границу сущности правила и иллюстрирует соответствующие
входы и выходы.
Таблица 3.1 Конструкции диаграммы активности и метаописания их правил
Rule Диаграмма
Consist of Начало начало, Конец конец, Блоки
блок
Internal Relationships: блок.Вход =
начало.Выход, блок.Выход = конец.Вход
External Relationships:
блок
Rule Блоки
Consist of Действие действие, Блоки блок
Internal Relationships: блок.Вход =
действие.Выход
External Relationships: Блоки.Вход =
действие.Вход, Блоки.Выход = блок.Выход
действие
блок
услови
блок 1
блок
блок 2
продол
жение
Rule Блоки
Consist of Блоки блок1, Блоки блок2, Условие
условие , Слияние слияние
Internal Relationships: условие.Выход1 =
блок1.Вход, условие.Выход2 = блок2.Вход,
слияние.Вход1=Блок1.Вход,
слияние.Вход2=Блок2.Вход
External Relationships: блоки.Вход =
условие.Вход, блоки.Выход = слияние.Выход
Rule Блоки
Consist of Блоки блок, Распараллеливание
распараллеливание, Слияние параллельных
ветвей слияние, Продолжение продолжение
Internal Relationships:
распаралеливание.Выход1 = блок.Вход,
распараллеливание=продолжение. Вход, слияние
=продолжение. Выход
External Relationships: блок.Вход =
распаралеливание.Вход, блок.Выход =
слияние.Выход
109
Таблица 3.2 Конструкции диаграммы активности и метаописания их правил
(продолжение)
блок
продол
жение
Rule Продолжение
Consist of Блоки блок, Распараллеливание
распараллеливание, Слияние параллельных
ветвей слияние, Продолжение продолжение
Internal Relationships:
распараллеливание.Выход1 = блок.Вход,
распараллеливание=продолжение.Вход, слияние
=продолжение.Выход
External Relationships: продолжение.Вход =
распаралеливание, продолжение.Выход =
Слияние
Первое правило описывает диаграмму в целом. Далее правила
описывают множество допустимых блоков в диаграмме активности.
Последнее правило «Продолжение» рекурсивно ссылается на себя, благодаря
чему может содержать несколько параллельных ветвей «Блоки».
Синтез RV-грамматики производится в соответствии со следующими
этапами:
1) построение квазитермального алфавита;
2) построение множества имен правил;
3) анализ
количественных
характеристик
правил
(выборка
элементов имеющих более одно входа или выхода);
4) построение операций с внутренней памятью.
На основе приведенных правил генерируются терминальные и
квазитерминальные символы.
Построение квазитермального алфавита
Квазитермальный алфавит строится на основе части правила,
начинающегося с Consist of. Построение происходит в два прохода:
построение множества имен и фильтрация множества имен.
110
Во время первого прохода собираются все имена из правил. Для этого в
каждом правиле из части Consist of строится множество используемых имен.
Во время этого же прохода строится дополнительное множество имен
правил. Для первого правила получим следующие множества (табл. 3.2).
Таблица 3.3 Формировани квазитермального алфавита
Правило
Множество
имен
Множество
имен правил
Rule Диаграмма
Начало,
Диаграмма
Consist of Начало, Конец, Блоки
Конец,
Internal Relationships:
Блоки
External Relationships: Блоки.Вход
= Начало.Выход, Блоки.Выход =
Конец.Вход
После окончания первого прохода необходимо отфильтровать
множество имен. Целевое отфильтрованное множество равно разности
Множества имен и Множества правил. Таким образом формируется
квазитермальный алфавит блоков.
На следующем проходе формируется терминальный алфавит связей.
Для диаграммы активности существует только один тип связи. Для других
диаграммных языков, где связи могут быть разного типа, алгоритм
построения терминального алфавита содержит шаги:

обрабатываются правила Relation;

выделяются все типы связей для их правила;

добавляется квазитерминальный символ в алфавит.
В
табл.
3.4
приведены
терминальные
и
соответствующие
квазитерминальные символы. Последняя строка табл. 3.4 соответствует
случаю, когда анализатор не достигает конечного состояния, и во входном
потоке нет символов для анализа. В процессе анализа правил присваиваются
произвольные
квазитерминальные
символы
(обычно a,b,c…).
Для
наглядности в табл. 3.4 приведены семантически понятные имена
квазитерминальных символов.
111
Таблица 3.4. Терминальный и квазитерминальный алфовит
Терминальный
символ
Квазитерминальный
символ
Примечание
A0
Начало диаграммы
Ak
Конец диаграммы
A
Действие
P
Ветвление
S
Объединение
взаимоисключающих
ветвей
R
Параллельное
выполнение действий
L
Слияние выполнения
параллельных ветвей
label
Связь
ø
Отсутствие связей меток
Синтез операций с внутренней памятью
Из приведенных выше примеров видно, что правила имеют общую
структуру. У каждого правила «Блоки» есть вход и выход, следовательно,
для контроля контекста можно использовать стековый механизм. В начале
112
обработки правила в стек заносится первый элемент. В конце обработки из
стека извлекается этот элемент. Если путей в правиле более одного, то
возникает вопрос, когда заканчивается обработка одного правила и
начинается обработка следующего.
Для контроля количества путей необходимо определить, сколько
выходов имеет стартовый блок и сколько входных связей проанализировано
в конечном блоке. Рассмотрим в качестве примера правило условного
ветвления. В начале обработки правила в стек записывается вершина
условия, в ленту в ячейку i, соответствующую номеру условной вершины,
записывается число выходов из вершины (для нашего случая 2). При
достижении точки слияния в ячейку j, соответствующую номеру слияния
условных ветвей, записывается значение, на единицу большее предыдущего
(начальное значение ноль). Когда значения в ячейках i и j совпадут,
считается, что все возможные пути проанализированы, и дальнейший анализ
продолжается по связи метки соответствующей выходу из конечного
элемента. Для правила распараллеливания данный механизм аналогичен.
В результате получаем автоматную RV-грамматику, содержащую 69
комплексов продукций. Получившаяся грамматика приведена в табл. 3.5.
Таблица 3.5. Грамматика диаграммы активности UML до минимизации
№
пп
Комплекс Квазитерм
Комплекс – преемник RV – отношение
1
r0
A0
r1
2
r1
rel
r9
3
r2
r9
4
r3
rel
rel
5
r4
labelP
r10
W2 (b1m )
6
labelW
r11
W2 (b 2 m )
7
labelR
r12
W2 (b 3m )
8
labelL
r13
W2 (b 4m ) / W3 (mt ( 2)  k t (3) )
r9
113
Таблица 3.6. Грамматика диаграммы активности UML до минимизации
(продолжение)
№
пп
Комплекс Квазитерм
labelP
r10
W2 (b1m )
10
labelW
r11
W2 (b 2 m )
11
labelR
r12
W2 (b 3m )
labelL
r13
W2 (b 4m ) / W3 (mt ( 2)  k t (3) )
no_label
rk
9
r5
Комплекс – преемник RV – отношение
12
13
14
r6
rel
r9
15
r7
labelP
r10
W2 (b1m )
labelW
r11
W2 (b 2 m )
17
labelR
r12
W2 (b 3m )
18
labelL
r13
W2 (b 4m ) / W3 (mt ( 2)  k t (3) )
labelP
r10
W2 (b1m )
20
labelW
r11
W2 (b 2 m )
21
labelR
r12
W2 (b 3m )
22
labelL
r13
W2 (b 4m ) / W3 (mt ( 2)  k t (3) )
23
no_label
rk
A
r1
25
P
r1
W1 (t 1m )
26
W
r2
W1 (1t (1) , t 2m ) / W2 (et (1) )
27
W
r2
W1 (2t (1) ) / W2 (1t (1) )
R
r1
W1 (t 3m
29
L
r2
W (1t ( 2) , k t (3) , t 4m ) / W2 (et ( 2) )
30
L
r2
W1 (inc (mt ( 2) )) / W3 (mt ( 2)  k t (3) )
31
AK
rk
A
r1
33
P
r1
W1 (t 1m )
34
W
r2
W1 (1t (1) , t 2m ) / W2 (et (1) )
16
19
24
r8
r9
28
32
r10
( k 1)
) / W3 (k  1)
114
Таблица 3.4. Грамматика диаграммы активности UML до минимизации
(продолжение)
№
пп
Комплекс Квазитерм
Комплекс – преемник RV – отношение
W
r2
W1 (2t (1) ) / W2 (1t (1) )
R
r1
W1 (t 3m
37
L
r2
W (1t ( 2) , k t (3) , t 4m ) / W2 (et ( 2) )
38
L
r2
W1 (inc (mt ( 2) )) / W3 (mt ( 2)  k t (3) )
39
AK
rk
A
r1
41
P
r1
W1 (t 1m )
42
W
r2
W1 (1t (1) , t 2m ) / W2 (et (1) )
43
W
r2
W1 (2t (1) ) / W2 (1t (1) )
R
r1
W1 (t 3m
45
L
r2
W (1t ( 2) , k t (3) , t 4m ) / W2 (et ( 2) )
46
L
r2
W1 (inc (mt ( 2) )) / W3 (mt ( 2)  k t (3) )
47
AK
rk
A
r1
49
P
r1
W1 (t 1m )
50
W
r2
W1 (1t (1) , t 2m ) / W2 (et (1) )
51
W
r2
W1 (2t (1) ) / W2 (1t (1) )
R
r1
W1 (t 3m
53
L
r2
W (1t ( 2) , k t (3) , t 4m ) / W2 (et ( 2) )
54
L
r2
W1 (inc (mt ( 2) )) / W3 (mt ( 2)  k t (3) )
55
AK
rk
A
r1
57
P
r1
W1 (t 1m )
58
W
r2
W1 (1t (1) , t 2m ) / W2 (et (1) )
59
W
r2
W1 (2t (1) ) / W2 (1t (1) )
R
r1
W1 (t 3m
35
36
40
r11
44
48
r12
52
56
60
r13
( k 1)
( k 1)
( k 1)
( k 1)
) / W3 (k  1)
) / W3 (k  1)
) / W3 (k  1)
) / W3 (k  1)
115
Таблица 3.4. Грамматика диаграммы активности UML до минимизации
(продолжение)
№
пп
Комплекс Квазитерм
Комплекс – преемник RV – отношение
61
L
r2
W (1t ( 2) , k t (3) , t 4m ) / W2 (et ( 2) )
62
L
r2
W1 (inc (mt ( 2) )) / W3 (mt ( 2)  k t (3) )
63
AK
rk
labelP
r10
W2 (b1m )
65
labelW
r11
W2 (b 2 m )
66
labelR
r12
W2 (b 3m )
67
labelL
r13
W2 (b 4m ) / W3 (mt ( 2)  k t (3) )
68
no_label
rk
r14
64
rk
69
После минимизации, заключающейся в исключении одинаковых
комплексов продукций, получаем RV-грамматику (табл. 3.7).
Таблица 3.7. Грамматика диаграммы активности UML
№
пп
Комплекс Квази-терм Комплекс – преемник
RV – отношение
1
r0
label
r3
2
r1
label
r3
3
r2
labelP
r3
W2 (b1m )
4
labelW
r3
W2 (b 2 m )
5
labelR
r3
W2 (b 3m )
6
labelL
r3
W2 (b 4m ) / W3 (mt ( 2)  k t (3) )
A
r1
8
P
r1
W1 (t 1m )
9
W
r2
W1 (1t (1) , t 2m ) / W2 (et (1) )
7
r3
116
Таблица 3.8. Грамматика диаграммы активности UML (продолжение)
10
W
r2
W1 (2t (1) ) / W2 (1t (1) )
11
R
r1
W1 (t 3m
12
L
r2
W (1t ( 2) , k t (3) , t 4m ) / W2 (et ( 2) )
13
L
r2
W1 (inc (mt ( 2) )) / W3 (mt ( 2)  k t (3) )
14
Ak
rk
( k 1)
) / W3 (k  1)
На выходе метакомпилятора получается RV-грамматика в формате
XML, которая используется кодом RV-анализатора для разбора конкретных
графических
предложений.
Более
подробно
данное
XML-описание
рассматривается в главе 4.
3.3 Анализ методов нейтрализации ошибок в диаграмматических
нотациях бизнес-процессов
Важной задачей при анализе диаграмматических нотаций бизнеспроцессов
анализатора
в
проектировании АС
является
после диагностирования
ошибки.
восстановление работы
При выборе метода
нейтрализации были исследованы основные методы нейтрализации. Их
классификация
представлена
на
рис.
3.3.
Стрелками обозначена
историческая связь между методами, т.е. метод продукций для ошибок
появился в результате развития метода корректировки на уровне фразы.
Ниже исследуются указанные методы нейтрализации с возможностью
их применения в автоматных RV-грамматиках, т.е. основной алгоритма
являются «переходы по автомату», при этом выполняются операции с его
внутренней памятью.
117
Рис. 3.3. Методы нейтрализации ошибок в грамматиках
Техника минимального преобразования и режим паники
Одним из самых ранних методов восстановления анализа является
техника минимального преобразования [3,4]. Метод заключается в
разработке цепочки преобразований для коррекции ошибки. Класс
трансформаций ошибок определяется следующим образом: каждый элемент
класса есть преобразование, на вход которого подана цепочка P и который
возвращает цепочку P`, такую что P` отличается на один и только один
модифицированный символ (удаленный или добавленный). Цепочка P
содержит k ошибок, если существует последовательность длиной k
состоящая из элементов класса трансформаций ошибок, такой что
преобразует последовательность P в P`, принадлежащую данному языку.
Теоретически доказано [3], что все синтаксические ошибки могут быть
скорректированы методом минимальных преобразований (что в принципе и
делает автор при исправлении программы или графической нотации), но на
практике этот метод входит в класс NP-полных задач [4].
Рассмотрим метод минимальных преобразований на примере элемента
«условное ветвление» Диаграммы активности языка UML. Всего в диаграмме
118
активности восемь графических элементов. Для ошибки вида PP (за
условным ветвлением, следует символ условного ветвления) допустимыми
будут являться преобразования: PA0, PA, Plabel, PW, PR, PL, PAk. Всего семь
преобразований. Если ошибка возникает в двух символах, то число
преобразований увеличится в семь раз (рис. 3.4). С увеличением количества
ошибок число возможных преобразований растет в геометрической
прогрессии. Такой метод имеет неоправданно большие временные затраты.
Поэтому его практическое применение не оправдано.
Рис. 3.4. Техника минимального преобразования
В противовес данному методу был предложен «легкий» метод паники
[11, 12]. Метод паники не корректирует ошибки совсем. В момент
проектирования языка определяется множество специальных символов –
опорные символы. При обнаружении ошибки из входной последовательности
удаляются все символы вплоть до опорного, а память приводится в состояние
достаточное для продолжения разбора. На практике данный метод приводит
к пропуску большого количества входных символов, что приводит к
пропуску ошибок и поэтому не применяется.
Рассмотрим метод паники на примере диаграммы представленной на
рис.
3.5. Определим опорными символами квазитермы R и L. Впервые
ошибка возникнет после выхода из множества состояний под номером 4.
Следующим опорным символом во входном потоке является символ слияния
параллельных ветвей. Совершая переход к нему, пропускаются группы №5,
6, 3. Таким образом, непроанализированным остается большое количество
элементов.
119
Рис. 3.5. Пример ошибочной диаграммы активности
Стратегия без нейтрализации ошибок
Существует стратегия,
основанная
на работе анализатора без
коррекции ошибки[84]. В данной стратегии предлагается разбора входной
цепочки без какой-либо коррекции ошибок. Главная идея данной данного
подхода состоит в том, что количество возможных ошибочных комбинаций
настолько велико, что автор стратегии восстановления не сможет удержать
их в голове. К тому же для каждого множества ошибок всегда может быть
найдена такая ошибка, которая должна быть включена в это множество.
В момент обнаружения ошибки анализатор может предпринять
несколько попыток по уменьшению неопределѐнности состояния. Все эти
варианты удовлетворяют следующим требованиям: участок, на котором
проявляется ошибка, идентифицируется однозначно; диагностирование
ошибки происходит без попытки исправления ее; каждое сообщение об
ошибке указывает на разные синтаксические ошибки; ложные сообщения не
генерируются; ни один символ входной цепочки не изменяется, поэтому
каждая ошибка ссылается на ошибки в языке или грамматике. Главное
преимущество метода состоит в том, что диагностируемая ошибка
120
определяется в контексте окружающих элементов, но обратной стороной
может быть слишком большой контекст показываемый с ошибкой, на
котором сложно исправить саму ошибку.
Рассмотрим восстановление анализа с использованием данного метода
на примере предыдущей диаграммы рис. 3.5. Ошибка однозначно
идентифицируется на участке блок 4 – символ параллельного слияния. Но по
выходу из блоков 5 и 6 будет повторная генерация ошибки о том же
элементе, следовательно, участок расширяется на блоки 4, 5, 6. Таким
образом, количество элементов окружающих ошибочный становится очень
большим, и поиск конкретной ошибки становится трудной задачей.
Нейтрализация на уровне фразы
Все методы нейтрализации перечисленные на рисунке имеют главной
целью продолжение разбора с помощью исправления или пропуска ошибки.
Методы нейтрализации могут изменять входную или цепочку, или стек, или
входную цепочку и стек одновременно. Вся дополнительная информация,
необходимая для правильной нейтрализации должна быть извлечена слева и
справа по контексту от ошибочного символа. Рассмотрим подкласс
восстановления на уровне фразы методов, как первый в хронологии[38].
Данный метода делится на 2 стадии:
1) фаза уточнения – на этой стадии определяются входные символы
включающие в себя ошибку;
2) фаза коррекции – формирование диагностического сообщения,
содержащее информацию об ошибке и осуществление действий по
восстановлению анализа.
Уточнѐнная фраза, не использующая символы слева от ошибочного
символа, называется прогрессивной (forward). Анализ продолжается до
момента, пока уточнение ошибочного символа не будет завершено или не
встретится новая ошибка. В последнем случае рекурсивный вызов процесса
восстановления может привести к зависанию. Основой прогрессивного
121
поиска является предположение, что множество символов языка всегда
заканчивается
одинаковым
множеством символов.
Поэтому анализ,
стартовавший с определѐнного символа, всегда оперирует ограниченным
подмножеством правил, и обнаружение этих правил не нуждается в
контексте слева.
В более ранних методах, исследованных Грэхемом и Родесом,
предложен другой вариант первой фазы – обратный (backward) просмотр. В
попытке уменьшить неопределѐнность в стеке правые части продукций
заменяются на левую настолько глубоко, на сколько это возможно.
Фаза коррекции изменяет входную цепочку или стек, используя
информацию, полученную на первом этапе. Для выбора корректировки из
множества возможных каждая вставка или удаление ассоциируется с
правилами грамматики. Если ни одна из корректировок не применима,
например, количество вставок или удалений больше предопределенного
максимума, возвращается ошибка, и разбор прекращается.
Преимущество данного метода состоит в том, что он подходит для
любого разбора сверху вниз и является независимым от языка.
Интерактивное восстановление
Назовем метод, который требует исправления ошибки пользователем в
момент ее обнаружения и продолжает свою работу с места исправления
ошибки, интерактивным.
Такие методы [41] концентрируют свое внимание на локализации всех
ошибок и определении их природы, чтобы помочь пользователю исправить
их. Когда обнаруживается ошибка, не предпринимается никаких мер по
исправлению ошибки, а запускается интерактивный диалог с пользователем.
Для облегчения исправления пользователю предлагаются некоторые
варианты
исправления,
которые
должны
привести
к
уменьшению
неопределѐнности анализатора. Предложенные варианты сортируются по
степени релевантности к ошибке.
122
Для оптимальной коррекции пользователь должен иметь возможность
поменять входную цепочку в любом месте. Такое может потребоваться, если
ошибка возникла вне контекста, где может быть обнаружена (например,
использование неинициализированной переменной). Такая корректировка
инициализирует повторную проверку контекста,
где было внесено
исправление.
Главной
проблемой
такого
метода
является
синхронизация
предыдущих этапов анализа. Любая модификация входной цепочки требует
переместить указатель анализа левее внесенного исправления. Такое
перемещение требует приведение памяти в соответствующее положению
указателя состояние. При этом нужно не удалить из памяти элементы,
которые приведут к ложному срабатыванию сигнализатора об ошибках.
Преимуществом такого подхода является то, то за один проход
анализатора ошибки не только диагностируются, но и входная цепочка
преобразуется в корректную. Действительно, все исправления, сделанные
или подтвержденные пользователем - оптимальны; никакие ложные ошибки
не исправляются; все ошибки обнаруживаются, потому что никакую часть
входной цепочки не отбрасывают во время анализа; повторный запуск
анализатора не нужен, потому что все исправления уже проверены.
Из-за таких возможностей этот метод иногда применим в паре с
инкрементальными
парсерами
и
синтаксически-ориентированными
редакторами.
Главный недостаток этого метода – необходимость участия человека в
процессе восстановления. Данный аспект делает метод применимым всегда,
но и накладывает ограничения в невозможности автоматизации.
Глобальное восстановление
С начала восьмидесятых было предложено множество методов
восстановления в глобальном контексте [74,17,12]. Все они берут начало в
попытке улучшить метод минимального преобразования. Метод глобальной
123
коррекции основывается на определении правила, которое однозначно может
сказать, сколько символов вокруг ошибочного нужно проанализировать для
получения наилучшего восстановления.
Глобальное восстановление использует большие куски контекста.
Таким образом, достигается лучшее восстановление, но в противовес
снижается производительность. Механизм восстановления тратит равное
время на анализ ошибочного и правильного участки входной цепочки. Чтобы
сделать метод восстановления независимым от длинны входной цепочки,
предложен метод местного восстановления.
Техники местного восстановления имеют общие черты и с локальными,
и с глобальными методами. Они основываются только на фиксированной
части входной цепочки для анализа.
Локальное восстановление
Стратегия локального восстановления была предложена Боилер и
Джордан в 1987 году [85]. Эта стратегия призвана улучшить восстановления
на уровне фразы и отличается от него в определении количества
затрагиваемых
входных
символов,
которые участвуют в
процессе
восстановления после определения ошибки. Алгоритмы этого класса
преобразуют входной символ таким образом, что, по крайней мере,
следующий символ может быть разобран. Другими словами – это алгоритм,
который использует одновременно стратегии прогрессивного и обратного
просмотра, ограниченные только одним символом. Методы этого класса
характеризуются
простотой
и
эффективностью,
обусловленные
ограничением дальности просмотра. Более того, они дают хороший результат
в большинстве случаев за исключением некоторых редко встречающихся.
Как и восстановление на уровне фразы, этот метод делится на две или
более фазы. Первая пытается восстановиться, модифицируя только один
символ. Другие фазы используются в случае неудачи в первой фазе.
Используются модификации: вставка, удаление, замена, объединение 2-х
124
рядом стоящих символов. Ошибки, поддающиеся исправлению с помощью
этих методов, называются простыми. Восстановление простых ошибок
делится на 2 фазы. На первой генерируется множество возможных
исправлений, на второй выбирается одно из них либо, отвергаются все. На
втором этапе немаловажной задачей является предотвращение бесконечных
циклов или возможных тупиков. Эффективность данного алгоритма оценено
в 75% [85].
При восстановлении на уровне фразы при разборе в автоматной
грамматике необходимо дополнительно сохранять цепочку переходов,
предшествовавшую попаданию в каждое конкретное состояние (для варианта
обратного просмотра) и знать подмножество состояний, в которое может
привести каждый последующий символ (для варианта прогрессивного
просмотра). При обратном просмотре алгоритм следующий: возвращаемся
по истории переходов до состояния, в котором следующий символ является
корректным
и
объявляем все переходы
в
«отмотанной»
цепочке
некорректными. Фраза, образовавшаяся из некорректных переходов,
содержит ошибку и выдается в диагностическом сообщении компилятора.
При прогрессивном анализе можно считать, что следующий символ – A в
разбираемом приложении является корректным, если от места обнаружения
ошибки до любого из состояний, в которое может привести символ A, не
превышает n переходов.
Для анализа по данному алгоритму необходимо хранить много
контекстной информации (например, множество состояний, в которое может
привести каждый символ), что накладывает определенные ограничения на
использование. Также встает вопрос в установлении «правильного» значения
N – количества переходов, дальше которых обнаруживать ошибку не
эффективно. Слишком маленькое число N приведет к множеству ложных
срабатываний, и большое количество символов входного предложения будет
пропущено. Для двух разных языков число N может сильно различаться.
Слишком большое – к долгому анализу предложения в случае нескольких
125
подряд идущих ошибочных символов. Именно проблема обнаружения числа
необходимых переходов делает метод не универсально применимым.
Метод продолжателей
Для нейтрализации ошибок на этапе проектирования грамматики
выделяются типы входных сигналов, имеющие специальный вид правил в
грамматике. Такие пары входных сигналов являются ‖ключевыми‖, т.к. на
них строится базис по восстановлению после ошибок.
Стартовый элемент пары продолжателей вносится в стек при
обнаружении во входной последовательности. Если во входной цепочке
встречается парный конечный продолжатель, то из стека извлекается
стартовый продолжатель.
Если в момент анализа анализатор переходит в состояние ошибки, то
входная цепочка пропускается до первого парного конечного символа
соответствующий стартовому символу на вершине стека. После этого анализ
продолжается с символа продолжателя. Если продолжатель не будет
обнаружен на заранее определѐнном расстоянии от места возникновения
ошибки, то в качестве стартового символа используют следующий элемент
стека. Если восстановить анализ не возможно, а символы из стека кончились,
то выдается ошибка о не возможности продолжать анализ.
Основная трудность метода заключается в определении минимального
множества продолжателей, которое обеспечит высокую вероятность
продолжить анализ в случае ошибки. Эта задача творческая и требует
решения на этапе создания грамматики для языка.
3.4 Разработка метода нейтрализации в графических грамматиках
[134, 142, 144]
В графических грамматиках применимы большинство из методов
нейтрализации классических грамматик: режим паники, минимального
преобразования, исправление на уровне фразы и глобальном уровне,
интерактивный и метод продолжателей. Для RV-грамматик был выбран
126
метод продолжателей. Выбор обусловлен хорошими показателями данного
метода: длина пропускаемой входной цепочки относительно невелика,
применим в большинстве случаев, с учетом особенности RV-грамматик
позволяет проанализировать большую часть диаграммы.
Для нейтрализации ошибок используется формализм под названием
RVC-грамматика.
возможностью
RVC
–
грамматика
использования
метода
расширяет
RV-грамматику с
продолжателей
для
задачи
нейтрализации обнаруживаемых ошибок. RVC – грамматикой языка L(G)
называется упорядоченная пятерка непустых множеств G  (V    R r0 ) ,
где
V  { e  e  1 L} – вспомогательный алфавит (алфавит операций над
внутренней памятью);
  {at  t  1 T } – терминальный алфавит графического языка;
  {a t t  1 T }
–
квазитерминальный
расширением
терминального
~
~
~
~
~ ~
  A S  AC  A MI  A MO  A L включает:
~
– A S квазитермы
графических
алфавит,
алфавита.
объектов
не
являющийся
Алфавит
являющихся
продолжателями анализа;
~
– A C квазитермы графических объектов – продолжателей анализа;
~
– A MI квазитермы графических объектов имеющих более одного
входа;
–
~
AL
квазитермы связей – меток с определенными для них
семантическими различиями;
~
– A MO квазитерм для проверки наличия графических объектов –
продолжателей анализа;
– квазитерм для завершения анализа.
127
R  {ri  i  0 I }
– схема грамматики G (множество имен комплексов
продукций, причем каждый комплекс ri состоит из подмножества Pij
продукций ri  {Pij  j  1 J } );
r0  R – аксиома RV – грамматики (имя начального комплекса
продукций), rk  R – заключительный комплекс продукций.
Правило продукции грамматики изменяется и принимает следующий
вид:
 [W (1 ,...,  n )]
C
C
a~t [a~1 ,...,a~k ] 
 rm
При использовании конкретной продукции, в которой список
продолжателей [a~1C ,...,a~k C ] не пустой, в стек продолжателей записывается
квазитерм a~t . Когда диагностируется ошибка в диаграмме, то в стеке
продолжателей ищется начальный символ пары продолжателей. Если такой
символ не обнаружен, то текущий квазитерм пропускается и производится
попытка восстановления на следующем квазитерме.
Изначально метод предполагал формирование списка продолжателей
вручную. Рассмотрим алгоритм формирующий список продолжателей на
основе схемы RV-грамматики, лежащей в основе RVC-грамматики.
3.5 Разработка алгоритма формирования множества
продолжателей
Для формирования списка продолжателей предлагается следующий
алгоритм:
1) выделить все области памяти, с которыми работает RV грамматика;
2) составить таблицу модификации памяти под воздействием каждого
элемента алфавита грамматики;
3) выделить парные элементы – элементы, которые работают с одной и
той же областью памяти, но с разными операциями (чтение-запись).
128
Рассмотрим построение списка продолжателей на основе RVграмматики для диаграмм активности UML.
На первом этапе выделяем четыре области памяти, над которыми
происходят операции в процессе анализа: m1,m2,s1,s2. Для анализа
используются два магазина – s1 и s2, и две ленты, для контроля количества
пройденных меток-связей – l1 и l2.
На втором этапе строим таблицу изменения состояний памяти. В
столбцах отметим выделенные на первом этапе области памяти. В строках
отметим квазитермы.
s1
s2
l1
l2
A0
Ak
label
R
W1
P
L
W
W1
W1
W2/ W3
W1
W3
W2
W3
A
На последнем этапе выделяются комплексы продолжатели, выбирая
парные операции в столбцах таблицы. В разбираемом случае:
 для памяти s1 выделяется пара R-L, где R – стартовый элемент
комплекса продолжателя, а L – конечный;
 для памяти s2 выделяется пара P-W, где P – стартовый элемент
комплекса продолжателя, а W – конечный;
 для l1 и l2 парных операций нет.
129
3.6 Типы диагностируемых ошибок
Обзор современных средств анализа и контроля корректности
диаграмматических моделей показал слабое развитие методов и средств
анализа ошибок, разорванных по контексту. Примеры таких ошибок
представлены на рис. 3.6.
Рис. 3.6. Типовые ошибки, удаленные по контексту
На рис. 3.6 а) представлена ситуация, когда выход из конструкции
никогда не будет достигнут. Это происходит потому, что элемент решение
предполагает передачу управления по одной из ветвей, тогда как элемент
слияния параллельных ветвей ожидает, когда все входные потоки будут
завершены. На рис. 3.6 б) представлена обратная ситуация: слияние после
решения ожидает, что передача ему управления произойдет один раз, но из
элемента параллельные работы управление передается по всем ветвям сразу.
На рис. 3.6 в) представлена ситуация, когда вход в элемент параллельных
работ никогда не произойдет, так как входящий поток может быть запушен
только после начала работы элемента. Анализ ошибок такого типа
осложняется тем, что между ошибочными элементами может находится
значительный контекст.
В процессе исследования были проанализированы пять диаграмм UML
и выявлены ошибки для них (табл. 3.9, табл. 3.11, табл. 3.13, табл. 3.15, табл.
3.17).
130
Таблица 3.9. Ошибки диаграммы активности
Синтаксические ошибки
Отсутствие
связи
Ошибка




условное ветвление без связи c действием
условное ветвление без связи с
распаралеливанием
распараледивание без связи с действием
другие

связь входящая в другую связь






Узел начала кратность 0
Узел конец – 1
Условное ветвление – 1
Слияние условных ветвей -2
Распараллеливание – 1
Активность – 1






Узел начала – 1
Узел окончания – 0
Условное ветвление – 2
Слияние условных ветвей – 1
Слияние параллельных ветвей -1
Активность -1
передачи
управления
Ошибка
кратности
входов
Ошибка
кратности
выходов
Семантические
Элемент конца 
в паралельной
не возможно завершить все паралельные
ветви
ветке
Бесконечный
цикл

возвращение паралельной ветви в
распаралеливание
131
Таблица 3.10. Ошибки диаграммы активности (продолжение)
Не верное

переключение
Условное ветвление должно
заканчиваться в том же потоке что и
начиналось
контекстов

должна иметь 
Диаграмма
Начальный узел должен быть только один
Конечный узел должен быть только один
конец и начало
Таблица 3.11. Ошибки диаграммы классов
Синтаксические ошибки

между классами нет связи

в / из тернарной ассоциации входит /
исходит не бинарная связь
Ошибка связи

вход связи любого типа в другую связь
Исключающие

XOR объединение отношений не
бинарного типа
Отсутствие
связи
Недопустимая
связь
связи неверного
типа
132
Таблица 3.12. Ошибки диаграммы классов (продолжение)
Семантические

Кольцевые
связи
Множественная 
однотипная
любой тип отношения между классом
A и классом B, и одновремеенное
какое -либо отношение между
классами B и A
включение класса A классом B, и
одновремеенное расширение класса B
классом A
связь
Ошибка ссылки 
класса на
Класс не должен содержать себя как
элемент прямо или коствено
самого себя
Таблица 3.13. Ошибки диаграммы последовательности
Синтаксические ошибки
Отсутствие

связи
Недопустимая 

связь
не рекурсивное пересечение фокусов
управления
связь вызова направленая справа налево
связь возврата направленая слева
направо
133
Таблица 3.14. Ошибки диаграммы последовательности (продолжение)
Вход связи в

любой тип связи входящий в другой тип
связи

вход линии вызова в линию жизни
связь
Вызов
направленный
в линию
жизни
Семантические
Синхронный
вызов до
получения
 При синхронном вызове, нужно
дождаться ответа, перед следующем
вызове
ответа
Стартовые и
финальные
 События должны начинаться и
заканчиваться на одном объекте
события
должны быть
на одной
Lifeline
Таблица 3.15. Ошибки диаграммы развертывания
Синтаксические ошибки
Не связанная 
связь
Связь исходящая из элемента, но не
входящая никуда
 Связь входящая в элемент, но не
исходящая из другог элемента
Вход связи в

связь
связь входящая в другую связь
134
Таблица 3.16. Ошибки диаграммы развертывания (продолжение)
Семантические
Интерфейс

объявленый интерфейс без реализаций

Зависимость между компонентами
должна быть только одна
без
реализации
Нарушение
кратности
зависимостей
Таблица 3.17. Ошибки диаграммы вариантов использования
Синтаксические ошибки
Отсутствие
связи



связь actor-case
связь actor-actor
связь case-case
Недопустимая 

связь
связь включения/расширения для actor
отношение ассоциации между классами

любой тип связи входящий в другой тип
связи

включение класса A классом B, и
одновремеенное расширение класса B
классом A
Вход связи в
связь
Семантические
Кольцевые
связи
Взаимоисклю 
чающие связи
одновременное расширение и включение
класса B классом A
Сгруппируем определяемые ошибки по типам и обозначим диаграммы
в которых встречаются (табл. 3.11.):
135
Таблица 3. 18. Типы ошибок встречающиеся в диаграммах
Тип ошибки
Отсутствие связи
Ошибка передачи
управления
Ошибка кратности
входов
Ошибка кратности
выходов
Недопустимая связь
Ошибка связи
Ошибка
уровня
доступа
Ошибка передачи
сообщения
Ошибка
делегирования
управления
Количественная
ошибка элементов
диаграммы
Исключающие
связи
неверного
типа
Вызов,
направленный
в
линию жизни
Не связанная связь
Нарушение
кратности
зависимостей
Взаимоисключающи
е связи
Множественная
связь
Бесконечный цикл
Кольцевые связи
Синхронный вызов
до получения ответа
Ошибка удаленного
контекста
Диаграмма
вариантов
использования
Диаграмма
активности
Диаграмма
последовател
ьности
+
+
+
Диаграм Диаграмма
ма
развертыва
классов ния
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
136
Исследование современных систем создания диаграмматики UML
показало, что они позволяют обнаруживать первые 16 из перечисленных
типов ошибок. Авторский аппарат RV-грамматик позволяет обнаруживать 4
дополнительных типа ошибок: бесконечный цикл, кольцевые связи,
множественная связь, ошибка удаленного контекста.
Ошибкой удаленного контекста называется ошибка, возникающая в
парных элементах, например условное ветвление и слияние условных ветвей,
и характеризующаяся возможным присутствием неограниченного количества
блоков и связей между ними. Примером такой ошибки может служить
условное ветвление на диаграмме активности, которое предполагает
исполнение только одной из возможных ветвей, и парное ему слияние
параллельных ветвей, которое передает управление дальше, только при
достижении всех входных связей. Такое сочетание элементов никогда не
позволит достигнуть
конца диаграммы.
Данные типы
ошибок не
диагностируются современными средствами анализа и контроля диаграмм,
но могут быть обнаружены авторскими RV-грамматиками.
3.7 Выводы
1. Предложена простая система правил описания диаграмматических
для использования в метакомпиляторе.
2. По результатам анализа существующих методов автоматической
генерации грамматик для формальных языков принято решение о создании
собственного метакомпилятора на основе Gold Parser Builder.
3. Описаны основные этапы процесса метакомпиляции, включающие
дополнительный
этап
генерации
операций
с
внутренней
памятью,
специфичной для RV-грамматик.
4. Проведен анализ методов нейтрализации ошибок, и рассматриваются
их достоинства и недостатки в новой области их применения в автоматных
графических грамматиках. Приведены примеры применения алгоритмов к
графическим языкам описания бизнес-процессов.
137
5. Анализ
методов
нейтрализации
ошибок
показал,
что
из
существующих наиболее подходящим является класс методов локальной
коррекции. Был выбран метод продолжателей вследствие его эффективности
и разработанного алгоритма автоматического формирования списка
продолжателей.
6. Из недостатков метода продолжателей существенным является
необходимость генерировать пары продолжателей вручную. Для аппарата
RV-грамматик разработан алгоритм автоматической генерации комплексов
продолжателей.
138
Глава 4.
Разработка программных средств реализации анализа и
контроля диаграмматическх нотаций бизнес-процессов
4.1 Разработка анализатора графических нотаций для системы
вопросно- ответного проектирования WIQA
В процессе разработки авторских алгоритмов анализа и контроля (RVграмматик) графических нотаций бизнес-процессов, был реализован
анализатор
для
диаграммного
редактора среды
вопросно-ответного
проектирования WIQA, разрабатываемого на кафедре ВТ.
Описание вопросно-ответной системы моделирования WIQA
WIQA (Work In Question and Answer) [161] – система вопросноответного моделирования, направленная на решение концептуальных
проблем в процессе проектирования АС. В основу разработки положены
средства вопросно-ответного моделирования. К числу отличительных
свойств по словам авторов относятся:
 различие
в
понимании
понятия
«вопроса»,
в
отличие от
традиционного в QA-моделировании под вопросом понимают природноискусственный
феномен,
рождающийся
в
процессе
применения
накопленного опыта;
 каждый созданный объект описывается в базе проекта АС в виде
объекта
(в
понимании
концепции
объектно-ориентированного
программирования);
 одной из особых форма вопроса является «задача», для экземпляров
которой предлагается строить QA- модели
Первая
реализация
анализатора
была
«жестко
привязана»
к
архитектуре комплекса WIQA и не являлась отдельным компонентом (рис. 4
1). Система WIQA имеет «плагинную»-архитектуру. Каждый компонент
расширяет ядро системы через механизмы .net Remoting. Одним из
компонентов
редактор.
вопросно-ответного
процессора
является
графический
139
Рис. 4.1. Общая структура интеграция RV-анализатора с системой WiQA
Графический редактор обладает характеристиками традиционного
векторного редактора. В верхней части редактора находятся множество
панелей управления сгруппированных по направлению воздействия на
диаграмму. Центральную часть занимает основное полотно диаграммы,
которое наполняется элементами из палитры компонентов (палитра
представлена
слева).
На
палитре
компонентов
представлены
сгруппированные компоненты для создания диаграмм UML.
Для создания редактора использовалась современная технология
Windows Presentation Foundation (WPF) [46, 119] от компании Microsoft. В
основе лежит система компонентов базирующаяся на прорисовке элементов
в
векторном
режиме,
что
позволяет произвольно
масштабировать
компоненты. Существует множество дополнительных функций, в том числе
XAML (Extensible Application Markup Language), элементов управления,
140
привязки данных, двухмерной и трехмерной графикой, анимацией, стилями,
шаблонами и др. WPF входит в состав Microsoft .NET Framework (старше
версии 4.0) и позволяет создавать приложения, включающие другие
элементы библиотеки классов .NET Framework.
В WPF особое внимание уделено облегчению создания новых
пользовательских интерфейсов. Одним из основных усовершенствований
является возможность разрабатывать приложения с использованием разметки
XAML [121, 155]. Разметка представляет собой валидный xml документ,
который сильно похож на HTML документ. Таким образом, достигается
разделение программного кода и представления. Эти возможности дают
следующие преимущества:
 затраты на разработку и обслуживание снижаются, так как разметка
определенного внешнего вида тесно не связана с кодом определенного
поведения;
 разработка более эффективна, так как разработчики, реализующие
внешний вид приложения, могут это делать одновременно с разработчиками,
реализующими поведение приложения;
 для реализации и совместного использования разметки Язык XAML
применяется множество средств конструирования, чтобы удовлетворить
требованиям участников разработки приложений.
При разработке палитры компонентов для создания графических
примитивов
и
компонентов
пользовательского
интерфейса
активно
использовался язык разметки XAML. XAML (англ. eXtensible Application
Markup
Language
— расширяемый язык разметки
приложений) –
реализованный на базе XML язык разметки для декларативного описания
графического интерфейса создаваемых приложений.
Модель
приложений разрабатываемых по
методологии
XAML
начинается с создания экземпляра объекта Application. Этот объект является
диспетчером
работы
приложения
и
обрабатывает
все
события
141
сгенерированные пользователями в процессе работы системы. Логика
приложения обрабатывается программным кодом н языке C#, вызов которого
описывается в соответствующих тегах разметки.
XAML состоит из четырех разных групп компонентов: панели,
элементы управления, элементы, связанные с документом и графические
фигуры. В стандартной сборке компонентов XAML существует семь классов
панелей, которые определяют компоновку элементов интерфейса. Для
позиционирования элементов используется атрибуты на манер CSS.
Для интеграции было написано расширение редактора – UMLредактор.
Одной из
его
частей являлся
анализатор корректности
составляемых спецификаций.
Разработанная версия анализатора работала по следующему алгоритму
(рис. 4.2):
1. графическое представление диаграммы преобразовывалось в XMLописание;
2. созданное описание предавалось на вход анализатору с указанием
типа диаграмм;
3. анализатор выбирает конкретный класс для анализа;
4. проводятся анализ, в процессе которого формируется список
ошибок;
5. полученный список отображается на палитре с диаграммой.
142
Рис. 4.2. Диаграмма активности анализатора для WIQA
На диаграмме последовательности (рис. 4.3) показаны вызовы внутри
системы анализа, которые происходят во время работы анализатора. Из
диаграммы видно, что
редактор,
центральным компонентом системы является
который синхронизирует взаимодействие всех остальных
элементов системы анализа диаграмматики. Такой объект отвечающий за
работу всех остальных называется диспетчер.
Если объект диспетчер выделен отдельно, то его расширение является
довольно легковесной операцией. Но первая реализация анализатора в
качестве диспетчера имела редактор, перегруженный другими функциями.
Изменение такого объекта задача трудоемкая, из-за непредсказуемых
143
зависимостей внутри объекта. Поэтому первая реализация обладала рядом
серьезных недостатков.
Рис. 4.3. Диаграмма последовательности анализатора для WIQA
В результате первого эксперимента с программной реализацией
анализатор
было
принято
решение
о
переходе
к
использованию
компонентной системы. Для этого система должна быть разделена на
независимые
компоненты,
и
каждый
компонент
реализовывается
изолированно. С использованием такого подхода был реализован плагин для
редактора Visio.
4.2 Разработка плагина для редактора Microsoft Visio [136, 145]
При проектировании новой версии анализатора были поставлены и
удачно решены следующие задачи:
 мягкая связанность компонентов – это позволит повторно
использовать созданные компоненты;
144
 использовать синтаксически ориентированный подход анализа –
это позволяет интерпретировать список ошибок для отображения в
другом редакторе;
 синтаксически
ориентированный
подход
к
построению
анализатора – это позволяет расширять анализатор новыми
диаграмматиками без написания программного кода.
Для реализации второй версии анализатора был выбран компонентно
ориентированный
подход.
Компонентно-ориентированное
программирование — методология программирования, базисным элементом
которой является компонент.
Компонентно-ориентированное программирование [126, 149] является
модификацией
традиционного
объектно-ориентированного
подхода.
Основная цель вносимых изменений и ограничений является повышение
надежности разрабатываемых систем. Главная проблема, решаемая данным
подходом, называется проблемой хрупкого базового класса.
Проблема хрупкого базового класса заключается в возможности
малейшими изменениями в классе предке внести кардинальное изменение в
производном классе. В худшем случае для внесения изменения в базовый
класс необходимо изучить структуру наследования и провести тестирование
всех производных классов. В общем случае задача не разрешима и всегда
требует индивидуального подхода к решению.
Основным требованием при создании компонентной структуры
заключается в том, что каждый компонент компилируется по отдельности и
подключается
динамически.
Была предложена идея единообразного
взаимодействия между вызывающим и вызываемым компонентом. Эта идея
воплотилась в виде в виде готовых решений CORBA [117], COM [159], SOAP
[97], dotNet Remoting [1].
Общая структура системы представлена на рис. 4.4.
145
Рис. 4.4. Общая структура плагина для MS Visio
Для анализа языков IDEF и UML было реализовано два отдельных
анализатора, что обусловлено спецификой данных графических нотаций.
На практике используются два варианта создания расширения для
Microsoft Visio.
1. Создание компонента согласно технологии Component Object Model
(COM) [39].
2. Создание встраиваемого в документ макроса на языке Visual Basic
for Application (VBA) [9].
Достоинствами первого варианта являются недостатки второго и
наоборот. Так, разработка макроса на языке VBA занимает меньшее время,
но ограничена по функциональности. Поэтому для разработки анализатора
был выбран первый вариант, так как он обеспечивает более широкие
возможности по работе как с объектами самого Visio, так и со сторонними
библиотеками и самой операционной системой в целом. Компонент COM
представляет собой обычную DLL библиотеку, которая регистрируется в
системе и имеет свой уникальный номер. Непосредственно в компоненте
согласно стандарту COM необходимо реализовать интерфейс IUnknown.
Информация
по
этому
компоненту
указывается
в
ключе
HKEY_CURRENT_USER/ Software/Mirosoft/Visio/Addins/ реестра системы
для того, чтобы Visio мог загрузить данные компонента. Подключение
146
компонента в самом Microsoft Visio осуществляется из пункта меню Сервис –
Настройки – Панели Инструментов.
RV-грамматика графического языка хранится в формате XML. Первая
секция файла грамматики описывает структуру внутренней памяти,
используемой данной грамматикой. Параметры для каждого элемента памяти
это уникальный идентификатор и тип элемента памяти (0 – стек, 1 –
эластичная лента). В листинге 1 приведена внутренняя память автомата,
состоящая из двух стеков с идентификаторами 1, 4 и двух эластичных
лент 2, 3.
<memory>
<storage id="1" type="0" />
<storage id="2" type="1" />
<storage id="3" type="1" />
<storage id="4" type="0" />
</memory>
Листинг 1. XML-описание внутренней памяти
Далее идѐт секция с описанием продукций грамматики, каждая
составляющая которой отражает строку табличной формы RV-грамматики.
Параметры продукции currentState и nextState отражают соответственно
текущее и следующее состояния автомата, term – соответствующий
графический примитив. Далее идет список операций записи значений во
внутреннюю память. Каждая операция записи содержит информацию об
идентификаторе элемента памяти storageId и заносимом значении value. Для
элемента памяти «эластичная лента» необходим номер ячейки key, в которую
производится запись. После списка операций следует условие выполнения
этих операций, параметры у которого те же, что и параметры операций
записи. Для примера приведем типичную продукцию, xml описание которой
представлено в листинге 2.
147
<production>
<currentState>1</currentState>
<nextState>2</nextState>
<term>A</term>
<operations>
<operation storageId="2" key="t" value="1"/>
<operation storageId="3" key="t" value="k"/>
<operation storageId="4" value="t"/>
</operations>
<conditions>
<condition storageId="2" key="t" value="0" />
</conditions>
</production>
Листинг 2. XML-описание продукции RV-грамматики
Алгоритм работы анализатора состоит из следующих шагов (рис. 4.5).
1. Проектировщик строит диаграмму в среде проектирования Visio.
2. С помощью разработанного расширения диаграмма преобразуется в
XML-описание, которое содержит все элементы диаграммы и связи между
ними. Описание не содержит информации о расположении элементов, т.к.
данная информация не используется при разборе.
3. Анализатор
принимает на вход
XML-описание построенной
диаграммы.
4. XML-описание преобразуется во внутреннее представление для
работы
анализатора.
Внутреннее
представление
содержит
описание
диаграммы, аналогичное входному XML-файлу. Происходит дополнительная
148
обработка
входной информации необходимой для
работы
с
RV-
анализатором.
5. Последовательно, считывая элемент за элементом, анализатор
производит анализ и контроль диаграммы.
6. По результатам анализа и контроля формируется список ошибок.
7. Список
преобразуется
в
XML
и
возвращается
в
среду
проектирования.
8. По полученному списку в Visio отмечаются типы и местоположения
синтаксических и семантических ошибок, обнаруженные анализатором.
Рис. 4.5. Диаграмма активности плагина для MS Visio
149
Данная
реализация
обладала
двумя
большими
недостатками:
сложность распространения и сложность обновления.
Под
сложностью
распространения
подразумевается
большое
количество элементов требующихся для установки одного плагина и
дублирования компонентов при установке на несколько редакторов на одном
рабочем месте. Под сложностью обновления подразумевается необходимость
ручной доставки каждого изменения на конкретное рабочие место.
Для решения этих проблем была спроектирована и реализована сетевая
система анализа и контроля диаграмматики бизнес-процессов.
4.3 Разработка сетевых систем анализ диаграмматики бизнеспроцессов [127, 130, 131, 143]
Общие характеристики системы
Инструментарий позволяет выполнять следующие основные функции
для пользователя:
 создание диаграмм графических языков;
 добавление новых нотаций диаграммно-графических языков;
 анализ построенных диаграмм по предварительно загруженным в
систему описаниям языка и алгоритмам анализа;
 добавление новых алгоритмов анализа с помощью плагинов;
 добавление синтаксических и семантических правил графических
языков;
 создание взаимосвязи между построенными проектировщиками
диаграммами; мультидоступ к базе данных построенных диаграмм.
К системе предъявляются следующие требования:
 возможность подключения средств визуального проектирования,
расширяемых плагинами;
 взаимодействие компонентов системы должно быть основано на
открытых стандартах.
150
Архитектура системы
Для реализации третьей версии системы была выбрана клиентсерверная архитектура приложения в качестве базовой архитектуры
приложения [157]. Такая архитектура подразумевает распределение нагрузки
и задач между поставщиками (серверами) и заказчиками (клиенты). Часто
клиенты и сервера взаимодействуют через компьютерную сеть и используют
различные физические устройства и программное обеспечение.
Рис. 4.6. Архитектура многоуровневой сетевой системы анализа и контроля
Многоуровневая
архитектура
клиент-сервер
—
разновидность
архитектуры клиент-сервер, в которой функция обработки данных вынесена
на один или несколько отдельных серверов. Это позволяет разделить
151
функции хранения,
обработки и представления данных для более
эффективного использования возможностей серверов и клиентов.
На
рис.
4.6
приведена
архитектура
системы,
содержащая
презентационный слой (клиент); слой рендеринга интерфейса (клиент); API
для работы с анализатором (сервер); слой бизнес-логики (сервер).
При необходимости пользователь может разместить все элементы
системы на одной машине и пользоваться ей как обычным приложением.
Презентационный слой
Уровень презентационной логики реализуется различными системами
проектирования, например, Rational Arcitech или BPWin. Для использования
системы анализа диаграммных языков прикладные системы проектирования
должны предоставлять:
 доступ к построенной диаграмме и ее внутреннему представлению.
Для анализа необходима информация о списке всех элементов диаграммы и
связях между ними;
 возможность вывода информации об ошибке в консоль в человекочитаемом виде, либо непосредственнона диаграмму (например, подсвечивать
элемент красным цветом).
Большинство современных сред разработок позволяет использовать
расширения. При разработке системы с множеством различных front-end
компонентов стоит вопрос о разработке протокола взаимодействия между
элементами системы. Для решения этой проблемы предлагается написание
промежуточного слоя между сервером и клиентом - слой рендеринга
интерфейса.
Слой рендеринга интерфейса
Слой рендеринга интерфейса отвечает за взаимодействие систем
проектирования и анализа диаграмм. Этот слой реализуется в виде плагина к
системе проектирования и преобразует внутреннее представление диаграммы
в формат понятный серверу. В качестве базовых выбраны два наиболее
152
распространенных формата JSON (JavaScript Object Notation) и XML
(eXtensible Markup Language). Основными задачами данного компонента
являются:
 авторизация на сервере. Пользователь получит уникальную сессию
на сервере, в рамках которой будет вести свою работу;
 преобразование диаграммы в XML/JSON представление;
 передача XML/JSONпредставления на сервер;
 получение списка ошибок от анализатора и передача их в
презентационный слой.
API для работы с анализатором
Анализатор
представляет себой сервис, который работает по
принципам REST[102, 124]. Одним из преимуществ RESTful-сервиса
является предоставление данных в удобном для пользователя формате.
Технология REST использует базовые принципы передачи данных по http,
это обеспечивает легкость реализации взаимодействия с сервисом и
подключать различные системы проектирования, написанные на различных
языках программирования, без больших временных затрат.
Сервер выполняет следующие функции:
 проверка на корректность описание диаграммы;
 преобразование
xml описание во
внутреннее представление,
понятное RV-анализатору;
 запуск анализа входной диаграммы;
 вывод списка ошибок.
На рис. 4 7 изображена система вызовов многоуровневой системы. На
рисунке представлена схема работы контролера приложения. На старте
приложения создаются все необходимые объекты: Receiver, Request и
Response Factory, Encode Factory, Protocol Factory и собственно анализатор.
На вход серверу приходит запрос на анализ, который разбирается
Request Factory. Создается объект Request, содержащий все необходимые
153
параметры. В процессе разбора используется Encode Factory, которая
позволяет преобразовать входной поток байт в реальный текст. Protocol
Factory определяет протокол взаимодействия клиента и сервера. Response
Factory формирует пустой объект response, который передается в анализатор.
Рис. 4.7. Диаграмма последовательности многоуровневой системы
154
Когда анализатор завершает анализ диаграммы, результат анализа
возвращается
в
контролер.
Контролер
заполняет
объект
response
необходимыми данными, такими как кодировка, служебные заголовки,
версия протокола, и возвращает ответ клиенту.
Слой бизнес-логики
Анализ диаграммы происходит с использованием автоматных RVграмматик. В основу реализации данного слоя легли принципы автоматного
программирования [150, 165]. На рис.
4.8 представлена схема
работы
анализатора.
Рис. 4.8. Схема работы анализатора
На этапе инициализации возможно два варианта загрузки диаграммы.
В первом анализатор «знает», какую диаграмму анализирует. Из библиотеки
грамматик выбирается нужная, и разбор происходит по этой грамматике. Во
втором варианте анализатор получает только диаграмму и по первым 3-5
элементам выбирает нужную грамматику.
На этапе анализа поочередно считываются все элементы диаграммы и
подаются на вход автомата, происходит изменение состояния автомата. При
обработке состояния возможны два случая. Обрабатываемый сигнал исходит
из текущего состояния. В этом случае выбирается необходимый переход и
выполняется операция с памятью, которая соответствует активному
155
переходу. В случае, если очередной элемент является запрещенным в данном
состоянии, то автомат переходит в режим восстановления.
Режим восстановления представляет собой особое состояние автомата,
в котором разрешается проблема обработки ошибочного входного элемента.
Происходит
восстановление
состояния
анализатора
по
методу
продолжателей. Данный режим позволяет обнаружить не только первую
ошибку в диаграмме, но и, по возможности, все ошибки допущенные
разработчиком. Запись об ошибке производится в момент перехода в
состояние восстановления. Указывается место возникновения ошибки и
диагностическая информация о ней.
На третьем этапе происходит формирование отчета об ошибках,
обнаруженных в диаграмме. Если список ошибок пуст, то возвращается
сообщение, что анализ завершился без ошибок. В противном случае
формируется отчет со списком всех ошибок.
Программное обеспечение системы
В качестве программного обеспечения системы анализа и контроля был
выбран неблокирующий современный веб-сервер на языки python – Tornado
Web Server [107]. Этот веб-сервер является относительно простым. На основе
веб сервера Tornado было создано ни одно высоконагруженное приложение,
что доказывает его хорошую производительность.
Tornado Web Server – открытая версия веб-сервиса и некоторых
приложений, которыми пользовались разработчики сервиса FreindFeed. Этот
фреймворк в отличие от большинства других фреймворков (в том числе и на
языке python) имеет значительные преимущества, потому что является не
блокирующим и быстрым. Из-за этого, а также использованию epoll, вебсервер способен обрабатывать тысячи одновременных соединений.
156
4.4 Проведение эксперимента
Для проверки работоспособности созданных программных средств был
проведен эксперимент, результаты которого доказывают корректность
работы спроектированных и запрограммированных продуктов.
Первый эксперимент базировался на созданном в научной группе
генераторе диаграммных спецификаций бизнес-процессов. Генератор на
входе принимает число в диапазоне от 1 до 100, которое является
показателем вероятности возникновения ошибки, и строковое значение,
которое определяет тип генерируемой ошибки. За проход генератор
создается диаграмма и выдается ее характеристика, которая определяет
количество и тип допущенных в данной диаграмме ошибок.
Каждая диаграмма подается на вход анализатора, который выдает
список ошибок в данной диаграмме. Результат, выданный анализатором,
сравнивается со списком ошибок, созданным в процессе генерации входной
диаграммы. Если список ошибок совпадает, то тест считается пройденным.
После тренировки на генераторе,
было
проведено
сравнение
возможностей анализатора и существующих систем анализа и контроля
диаграмматики бизнес-процессов. Результат сравнения приведен в табл. 4.1
Таблица 4.1. Результаты работы анализаторов и RV-грамматики
Вероятность
появления
ошибки
Обнаруживаемые ошибки
Стандартными
анализаторами
RVанализатор
Системные ошибки
55%
~70%
~80%
Алгоритмические
ошибки
25%
~90%
~97%
Ошибки реализации 15%
спецификаций
~95%
~97%
Технологические
ошибки
~100%
Без
изменений
5%
157
В продолжение эксперимента был проведено исследование анализатора
с привлечением студентов выпускного курса магистратуры Ульяновского
государственного технического университета. Требования к выполнению
работы были следующими: создать диаграммы активности, вариантов
использования
и
последовательности
для
какой-либо
программно-
информационной системы. На создаваемые диаграммы были наложены
ограничения:
 полное описание информационной системы;
 не менее 20 функциональных вершин на диаграмме;
 не более 1,5 часов на создание диаграмм.
Для составления диаграмматики программно-информационных систем
использовался редактор диаграмм от Microsoft – MS Visio 2010. В редакторах
отсутствовал плагин по анализу диаграмматики, разработанный автором
работы. В результате проведенного занятия были получены диаграммы для
17 различных программно-информационных систем. После ручного анализа
диаграмм, среднее число ошибок на диаграмме составило 10-15%.
Набор из 17 диаграмм был подвергнут анализу авторскими RVграмматиками. И составлен список обнаруженных ошибок. При ручной
верификации результатов анализа было выявлено, что RV-грамматики
обнаружили 100% синтаксических ошибок и 97% семантических ошибок.
4.5 Выводы и рекомендации
1. Разработанные
программные
средства
анализа
и
контроля
диаграмматических нотаций бизнес-процессов позволили опробовать на
практике предложенные в работе методы и алгоритмы и в результате
проведенных экспериментов полностью доказали свою состоятельность.
2. Для
вопросно-ответной
системы
моделирования
АС
WIQA
разработанный плагин для редактора следует применять при индивидуалном
проектировании UML-диаграмм.
158
3. Компонентная структура, спроектированная в процессе разработки
плагина для среды создания диаграммных спецификаций MS Visio,
позволила
декомпозировать
монолитную
структуру
первой
версии
анализатора. Такая декомпозиция позволяет легче развивать и тестировать
различные компоненты системы. Программное средство следует применять в
MS Visio версии 2007 и выше, для анализа и контроля сложных комплексных
UML-диаграмм.
4. Многоуровневая система позволяет создать программный комплекс,
распространяемый по принципу SaaS(Software as a Services). Такой подход
позволит единовременно распространять новые версии всем специалистам,
использующим продукт. Реализована возможность при помощи внесения
правок
в
грамматику,
распространять
требования
по
новым
диаграмматическим спецификациям. Программный комплекс обеспечивает
анализ и контроль всего спектра синтаксических и семантических ошибок,
заявленных
в
главе
3.
Реализованный
авторский
аппарат
RVM-
грамматикпозволяет обнаруживать 4 дополнительных типа ошибок, что
составляет 20% от общего числа ошибок.
5. Программные
средства
внедрены
на
крупном
проектном
предприятии ФНЦП ОАО «НПО «Марс» (г. Ульяновск), производственный
процесс ООО «Эквид» (г. Ульяновск),
учебный процесс Ульяновского
государственного технического университета.
6. На
программные
РОСПАТЕНТа [161, 162, 163].
продукты
получено
три
свидетельства
159
Заключение
Цель диссертационной работы расширение класса диагностируемых
ошибок в процессе проектирования АС за счет развития и реализации
методов и средств анализа и контроля графических нотаций бизнеспроцессов – достигнута.
1. Предложен новый метод анализа и контроля диаграмматики бизнеспроцессов на основе автоматных многоуровневых графических RVMграмматик.
2. Предложен новый метод анализа и контроля семантических ошибок
диаграмматики бизнес-процессов в составе комплексной
диаграммы,
созданной в процессе коллективного проектирования на основе автоматных
графических
RVM-грамматик.
Авторский
аппарат
RVM-грамматик
позволяет обнаруживать 4 дополнительных типа ошибок, что составляет 20%
от общего числа ошибок.
3. Предложен новый алгоритм формирования множества комплексов
продукций-продолжателей для автоматной графической RV-грамматики.
4. Предложен новый метод синтеза автоматной графической RVграмматики,
позволяющий
автоматически
сформировать
таблицу
грамматики, включая операции с внутренней памятью.
5. Разработан анализатор диаграмматических моделей потоков бизнеспроцессов вопросно-ответной системы моделирования АС.
6. Разработан
синтаксически-ориентированный
анализатор
UML-
диаграмм для MS Visio, позволяющий обнаруживать допущенные при
построении диаграмм синтаксические и семантические ошибки.
7. Разработана
и
реализована
архитектура
системы
контроля
корректности диаграмматики бизнес-процессов, содержащая полный набор
функциональности для анализа и контроля синтаксических и семантических
ошибок.
160
Список литературы
1. .NET
Framework
Remoting
Overview
http://msdn.microsoft.com/en-us/library/kwdt6w2k(v=vs.85).aspx
URL:
(Дата
обращение 11.03.2014)
2. A. Firat, Information Integration Using Contextual Knowledge and
Ontology Merging, Ph.D. Thesis, Massachusetts Institute of Technology, Sloan
School of Management, 2003
3.
Aho A. V., Johnson S. C. LR parsing //ACM Computing Surveys
(CSUR). – 1974. – Т. 6. – №. 2. – С. 99-124.
4. Aho A. V., Peterson T. G. A minimum distance error-correcting parser for
context-free languages //SIAM Journal on Computing. – 1972. – Т. 1. – №. 4. – С.
305-312.
5. Ambler S., Nalbone J., Vizdos M. Enterprise Unified Process, the:
Extending the Rational Unified Process. // Prentice Hall Press - 2005. - 408 C.
6. Ankudinov G. I. Aspects of the theory of plex-languages// Cybernetics. –
1978 – Т. 14, С. 363-369.
7. ANTLR URL: http://www.antlr.org/ (Дата обращение 14.02.2014)
8. ARIS Express - Free Modeling Software | ARIS BPM Community URL:
http://www.ariscommunity.com/aris-express (Дата обращение 10.02.2014)
9. Balena F., Foreword By-Fawcette J. Programming Microsoft Visual Basic
6.0. – Microsoft Press, 1999.
10. Baxter I. D., Pidgeon C., Mehlich M. DMS®: Program transformations
for practical scalable software evolution //Proceedings of the 26th International
Conference on Software Engineering. – IEEE Computer Society, 2004. – С. 625634.
11. Bianchi U. et al. Generating the analytic component parts of syntaxdirected editors with efficient-error recovery //Journal of Systems and Software. –
1993. – Т. 23. – №. 1. – С. 65-79.
161
12. Bianchi U. et al. Generating the analytic component parts of syntaxdirected editors with efficient-error recovery //Journal of Systems and Software. –
1993. – Т. 23. – №. 1. – С. 65-79.
13. Bison - GNU parser generator URL: http://www.gnu.org/ software/bison/
(Дата обращение 14.02.2014)
14. Booch G., Rumbaugh J., Jacobson I. Unified Modeling Language—User‘s
Guide. // Addison-Wesley - 2005. – 496 С.
15. Booch G., Rumbaugh J., Jacobson I. Unified Software Development
Process. // Addison-Wesley - 1999. - 512 С.
16. Bottoni P., Taentzer G., Schurr A. Efficient parsing of visual languages
based on critical pair analysis and contextual layered graph transformation //Visual
Languages, 2000. Proceedings. 2000 IEEE International Symposium on. – IEEE,
2000. – С. 59-60.
17. Boullier P., Jourdan M. A new error repair and recovery scheme for
lexical and syntactic analysis //Science of computer programming. – 1987. – Т. 9.
– №. 3. – С. 271-286.
18. Bouquet P. et al. C-owl: Contextualizing ontologies //The Semantic WebISWC 2003. – Springer Berlin Heidelberg, 2003. – С. 164-179.
19. Business process management discussions, news and articles | ARIS BPM
Community URL: http://www.ariscommunity.com/ (Дата обращения 01.03.2014)
20. Business
process
re—engineering
URL:
http://www.adi.pt/docs/
innoregio_bpr-en.pdf (Дата обращения 18.03.2014)
21. C. H. Goh, S. Bressan, S. Madnick, and M. Siegel, ʺContext Interchange:
New Features and Formalisms for the Intelligent Integration of Information,ʺ ACM
Transactions on Information Systems, vol. 17, С. 270-293, 1999.
22. Cabot J., Pau R., Raventós R. From UML/OCL to SBVR specifications:
A challenging transformation //Information Systems. – 2010. – Т. 35. – №. 4. – С.
417-440.
23. Choi N., Song I. Y., Han H. A survey on ontology mapping //ACM
Sigmod Record. – 2006. – Т. 35. – №. 3. – С. 34-41.
162
24. COM:
Component
Object
Model
Technologies
URL:
https://www.microsoft.com/com/default.mspx (Дата обращение 11.03.2014)
25. Costagliola G. et al. Positional grammars: A formalism for LR-like
parsing of visual languages //Visual language theory. – Springer New York, 1998.
– С. 171-191.
26. Costagliola G., Lucia A. D., Orefice S., Tortora G. A parsing
methodology
for
the
implementation
of
visual
systems.
http://www.dmi.unisa.it/people/costagliola/www/home/papers/method.ps.gz.
27. Costagliola G., Polese G. Extended positional grammars //Visual
Languages, 2000. Proceedings. 2000 IEEE International Symposium on. – IEEE,
2000. – С. 103-110.
28. DMS
Software
Reengineering
Toolkit
http://www.semanticdesigns.com/Products/DMS/DMSToolkit.html
URL:
(Дата
обращение 14.02.2014)
29. Donnelly C., Stallman R. Bison //Free Software Foundation. – 1995.
30. D'souza D. F., Wills A. C. Objects, components, and frameworks with
UML: the catalysis approach. – Reading : Addison-Wesley, 1998. – Т. 1.
31. Feder J. Plex languages // Information Science.— 1971.— no. 3. — С.
225–241.
32. Firat A., Madnick S., Manola F. Multi-dimensional ontology views via
contexts in the ECOIN semantic interoperability framework //Contexts and
Ontologies: Theory, Practice and Applications. AAAI Workshop. AAAI Press. –
2005. – С. 1-8.
33. Fowler M. UML Distilled: A Brief Guide to the Standard Object
Modeling Languange. – Addison-Wesley Professional, 2004.
34. GOLD Parsing System - A Free, Multi-Programming Language, Parser
Generator URL: http://goldparser.org/ (Дата обращение 14.02.2014)
35. Golin E. J. Parsing visual languages with picture layout grammars
//Journal of Visual Languages & Computing. – 1991. – Т. 2. – №. 4. – С. 371-393.
163
36. Graham I. Object oriented methods. – Wokingham, England : AddisonWesley, 1991. – Т. 991.
37. Graham S. L., Haley C. B., Joy W. N. Practical LR error recovery. –
ACM, 1979. – Т. 14. – №. 8. – С. 168-175.
38. Graham S. L., Rhodes S. P. Practical syntactic error recovery
//Communications of the ACM. – 1975. – Т. 18. – №. 11. – С. 639-650.
39. Gray D. N. et al. Modern languages and Microsoft's component object
model //Communications of the ACM. – 1998. – Т. 41. – №. 5. – С. 55-65.
40. Hagge N., Wagner B. A new function block modeling language based on
Petri nets for automatic code generation // Industrial Informatics, IEEE
Transactions. - 2005 - С. 226-237
41. Hermeler J. C. C. et al. Error Correction and Recovery in a LL (l) Parser.
– 1998. – 35 С.
42. Hoffmann H. P. Deploying model-based systems engineering with IBM®
rational® solutions for systems and software engineering //Digital Avionics
Systems Conference (DASC), 2012 IEEE/AIAA 31st. – IEEE, 2012. – С. 1-8.
43. IBM -
Rational Software Architect URL: http://www-03.ibm.com/
software/products/ru/ratisoftarch/ (Дата обращение 12.01.2014)
44. IBM
Rational
Unified
Process
(RUP)
URL:
http://www-
01.ibm.com/software/rational/rup/ (Дата обращение 25.02.2014)
45. Introduction to business modeling using the Unified Modeling Language
(UML)
URL:
http://www.ibm.com/developerworks/
rational/library/360.html
(Дата обращение 23.01.2014)
46. Jones A., Freeman A. Windows Presentation Foundation //Visual C# 2010
Recipes. – Apress, 2010. – С. 789-904.
47. Jones D., Bench-Capon T., Visser P. Methodologies for ontology
development //Proc. IT&KNOWS Conference of the 15th IFIP World Computer
Congress. – 1998. – С. 20-35.
48. Knuuttila T. From representation to production: Parsers and parsing in
language technology //Simulation. – Springer Netherlands, 2006. – С. 41-55.
164
49. Knuuttila T., Voutilainen A. A parser as an epistemic artifact: A material
view on models //Philosophy of Science. – 2003. – Т. 70. – №. 5. – С. 1484-1495.
50. Kruchten P. A Rational Development Process // CrossTalk. — 1996. —
С. 11-16.
51. Kruchten P. Rational Unified Process—An Introduction. //
Addison-
Wesley - 2003. - 336 С.
52. Leborg C. Visual grammar. – Princeton Architectural Press, 2006.
53. Lee J. K., Sohn M. M. The extensible rule markup language
//Communications of the ACM. – 2003. – Т. 46. – №. 5. – С. 59-64.
54. Lex & Yacc Tutorial URL: http://epaperpress.com/lexandyacc/ (Дата
обращение 14.02.2014)
55. Maedche A. et al. Mafra—a mapping framework for distributed
ontologies //Knowledge engineering and knowledge management: ontologies and
the semantic web. – Springer Berlin Heidelberg, 2002. – С. 235-250.
56. Mairesse F. et al. Phrase-based statistical language generation using
graphical models and active learning //Proceedings of the 48th Annual Meeting of
the Association for Computational Linguistics. – Association for Computational
Linguistics, 2010. – С. 1552-1561.
57. Marca D.A., McGowan C.L. IDEF0 and SADT: A Modeler's Guide //
OpenProcess, Inc. – 2005. – 392 С.
58. Mayer R.J., Painter M.K., deWitte P.S. IDEF family of methods for
concurrent Engineering and Business Re-engineering Application//
Knowledge
Based Systems - 1994. – 60 С.
59. Mendling J., Müller M. A Comparison of BPML and BPEL4WS
//Berliner XML Tage. – 2003. – Т. 2003. – С. 305-316.
60. Mendling J., Neumann G., Nüttgens M. Towards workflow pattern
support of event-driven process chains (EPC) //Proc. of the 2nd Workshop
XML4BPM. – 2005. – С. 23-38.
165
61. Mendling J., Nüttgens M. EPC markup language (EPML): an XML-based
interchange format for event-driven process chains (EPC) //Information Systems
and e-Business Management. – 2006. – Т. 4. – №. 3. – С. 245-263.
62. Mössenböck H. et al. The compiler generator Coco/R //Peter Rechenberg–
Festschrift zum. – 1990. – 70 С.
63. Noran O. S. Business modelling: UML vs. IDEF //Lecture note, Griffith
University, School of Computing and Information Technology. – 2000. – С. 16-23.
64. Noy N. F., Musen M. A. Anchor-PROMPT: Using non-local context for
semantic matching //Proceedings of the workshop on ontologies and information
sharing at the international joint conference on artificial intelligence (IJCAI). –
2001. – С. 63-70.
65. Noy N. F., Musen M. A. The PROMPT suite: interactive tools for
ontology merging and mapping //International Journal of Human-Computer
Studies. – 2003. – Т. 59. – №. 6. – С. 983-1024.
66. Noy N. Ontology Mapping and Alignment //Fifth International Workshop
on Ontology Matching collocated with the 9th International Semantic Web
Conference ISWC-2010, Shangai, China. – 2012.
67. Omelayenko B. RDFT: A mapping meta-ontology for business integration
//Proc. of the Workshop on Knowledge Transformation for the Semantic Web at
the 15th European Conference on Artificial Intelligence (KTSW2002). – 2002. –
С. 77-84.
68. Omelayenko B. RDFT: A Mapping Meta-Ontology for Web Service
Integration. – 2003.
69. OOAD UML Object oriented analysis and Design using UML or similar
modeling languages URL: http://ooaduml.com/ (Дата обращения 18.03.2014)
70. Osterwalder A., Pigneur Y. Business Model Generation: A Handbook for
Visionaries, Game Changers, and Challengers. // Wiley - 2010. - 288 С.
71. Overview
Of
Methodologies
For
Building
http://oa.upm.es/5480/1/Overview_Of_Methodologies.pdf
10.02.2014)
Ontologies
(Дата
URL:
обращение
166
72. OWL - Semantic Web Standards URL: http://www.w3.org/2001/
sw/wiki/OWL (Дата обращение 02.02.2014)
73. OWL Web Ontology Language Overview URL: http://www.w3.org/
TR/owl-features/ (Дата обращение 02.02.2014)
74. Pai A. B., Kieburtz R. B. Global context recovery: A new strategy for
syntactic error recovery by table-drive parsers //ACM Transactions on
Programming Languages and Systems (TOPLAS). – 1980. – Т. 2. – №. 1. – С. 1841.
75. Paradigm V. Visual paradigm for uml //Hong Kong: Visual Paradigm
International. Available at: http://www. visual-paradigm. com/product/vpuml/.
Accessed April. – 2010. – Т. 15. – С. 2010.
76. Parr T. The definitive ANTLR reference: Building domain-specific
languages. – Pragmatic Bookshelf, 2007.
77. Parr T., Fisher K. LL (*): the foundation of the ANTLR parser generator
//ACM SIGPLAN Notices. – 2012. – Т. 47. – №. 6. –
С. 425-436.
78. Philipps Gabriele Taentzer Syntax Definition of Visual Domain-Specific
Languages by Graph Transformation // Universitat Marburg. — 2012.
79. Podeswa H. The Business Analyst's Handbook. // Cengage Learning PTR
- 2008. - 432 С.
80. Quality management systems — Fundamentals and vocabulary, ISO
9000:2005. — 2005. — http://www.iso.org
81. R.
Gainullin Diagrams
languages
analysis software system// IX
International conference on interactive systems: problems of human-computer
interaction. – 2011г. - С. 157-161
82. Raj A., Prabhakar T. V., Hendryx S. Transformation of SBVR business
design to UML models //Proceedings of the 1st India software engineering
conference. – ACM, 2008. – С. 29-38.
83. Rekers J., Schürr A. Defining and parsing visual languages with layered
graph grammars //Journal of Visual Languages & Computing. – 1997. – Т. 8. – №.
1. – С. 27-55.
167
84. Richter H. Noncorrecting syntax error recovery //ACM Transactions on
Programming Languages and Systems (TOPLAS). – 1985. – Т. 7. – №. 3. – С.
478-489.
85. Rimell L., Clark S., Steedman M. Unbounded dependency recovery for
parser evaluation //Proceedings of the 2009 Conference on Empirical Methods in
Natural Language Processing: Volume 2-Volume 2. – Association for
Computational Linguistics, 2009. –
С. 813-821.
86. Röhrich J. Methods for the automatic construction of error correcting
parsers //Acta Informatica. – 1980. – Т. 13. – №. 2. – С. 115-139.
87. Roth C. Using Microsoft Visio 2010. – Pearson Education, 2011.
88. RuleML
Wiki
URL:
http://wiki.ruleml.org/index.php/RuleML_Home
(Дата обращение 14.02.2014)
89. SADT-моделирование. Основные понятия и принципы. Режим
доступа: http://vernikov.ru/media/K2/item_attachments /stacionar_idef0.pdf (дата
обращения 22.07.2013)
90. Santos Jr P. S., Almeida J. P. A., Pianissolla T. L. Uncovering the
organisational modelling and business process modelling languages in the ARIS
method //International Journal of Business Process Integration and Management. –
2011. – Т. 5. – №. 2. – С. 130-143.
91. Scheer A. W., Cameron I. Architecture of integrated information systems:
foundations of enterprise modelling. – Springer-Verlag, 1992. – 220 С.
92. Scheer A. W., Nüttgens M. ARIS architecture and reference models for
business process management. – Springer Berlin Heidelberg, 2000. – С. 376-389.
93. Scheer A. W., Schneider K. Aris—architecture of integrated information
systems //Handbook on architectures of information systems. – Springer Berlin
Heidelberg, 2006. – С. 605-623.
94. Scheer A. W., Thomas O., Adam O. Process modeling using event-driven
process chains //Process-Aware Information Systems. – 2005. – С. 119-146.
168
95. Silva N., Rocha J. MAFRA–an ontology MApping FRAmework for the
semantic web //Proceedings of the 6th International Conference on Business
information Systems. – 2003.
96. Smith H. Business process management—the third wave: business
process modelling language (bpml) and its pi-calculus foundations //Information
and Software Technology. – 2003. – Т. 45. – №. 15. – С. 1065-1069.
97. SOAP
Specifications
URL:
http://www.w3.org/TR/soap/
(Дата
обращение 11.03.2014)
98. Stead A. G., Blackwell A. F., Aaron S. Graphic Score Grammars for EndUsers //Proceedings of the International Conference on New Interfaces for Musical
Expression (NIME). – 2012. – С. 176-179.
99. Strötgen J., Gertz M., Popov P. Extraction and exploration of spatiotemporal information in documents //Proceedings of the 6th Workshop on
Geographic Information Retrieval. – ACM, 2010. – С. 16.
100.
Stuckenschmidt H. et al. Using C-OWL for the alignment and
merging of medical ontologies. – 2004.
101.
Swierstra S. D., Duponcheel L. Deterministic, error-correcting
combinator parsers. – Springer Berlin Heidelberg, 1996. – С. 184-207.
102.
Szepielak D.
REST-based
Service Oriented Architecture for
Dynamically Integrated Information Systems //PhD Symposium at ICSOC. – 2006.
– Т. 2006.
103.
Tawara Y., Yamauchi T., Olukotun K. Introduction to domain specific
programming approach for heterogeneous multicore. – 2012.
104.
The Compiler Generator Coco/R URL: http://ssw.jku.at/Coco/ (Дата
обращение 14.02.2014)
105.
The
LEMON
Parser
Generator
URL: http://www.hwaci.com/
sw/lemon/ (Дата обращение 14.02.2014)
106.
Thiagarajan R. K. et al. BPML: A process modeling language for
dynamic business models //Proceedings of the Fourth IEEE International
169
Workshop on Advanced Issues of E-Commerce and Web-Based Information
Systems (WECWIS'02). – IEEE Computer Society, 2002. – С. 239.
107.
Tornado Web Server — Tornado 3.2 documentation [Официальный
сайт] URL: http://www.tornadoweb.org/ (Дата обращения 15.02.2014)
108.
Tsai T. M. et al. Ontology-mediated integration of intranet web
services //Computer. – 2003. – Т. 36. – №. 10. – С. 63-71.
109.
UML CASE tool for software development URL: http://www.visual-
paradigm.com/product/vpuml/ (Дата обращение 10.02.2014)
110.
Van der Aalst W. M. P. et al. Pattern-based analysis of BPML (and
WSCI). – Technical Report FIT-TR-2002-05, Queensland University of
Technology, 2002. – Т. 1. – С. 60.
111.
Vaziri M., Jackson D. Some Shortcomings of OCL, the Object
Constraint Language of UML //TOOLS (34). – 2000. – С. 555-562.
112.
VISpro - Vision Imaging & Signal Processing Research Group --
SEECS – NUST URL: http://vispro.seecs.nust.edu.pk/ (Дата обращение
10.01.2014)
113.
W3C OWL Working Group et al. OWL 2 Web Ontology Language
Document Overview, W3C Recommendation, Oct, 2009.
114.
Walker R. Software Project Management - A Unified Framework. //
Addison-Wesley - 1998. - 448 С.
115.
Wang L., Wang Y., Gao W. Mining layered grammar rules for action
recognition //International journal of computer vision. – 2011. – Т. 93. – №. 2. – С.
162-182.
116.
Warmer J., Kleppe A. The object constraint language second edition:
Getting your models ready for MDA //Canada: Person Education, Inc. – 2003.
117.
Welcome To The OMG's CORBA Website http://www.corba.org/
(Дата обращение 11.03.2014)
118.
Wiederhold G. Mediators in the architecture of future information
systems //Computer. – 1992. – Т. 25. – №. 3. – С. 38-49.
170
119.
Windows Presentation Foundation [Microsoft Development Network]
URL: http://msdn.microsoft.com/ru-ru/library/ms754130(v=vs.110). aspx (Дата
обращения 15.02.2014)
120.
Wittenburg K. B., Weitzman L. M. Relational grammars: Theory and
practice in a visual language interface for process modeling //Visual language
theory. – Springer New York, 1998. – С. 193-217.
121.
XAML
в
WPF
[Microsoft
Development
Network]
http://msdn.microsoft.com/ru-ru/library/ms747122(v=vs.110).aspx
URL:
(Дата
обращения 15.02.2014)
122.
Zhang D. Q., Zhang K. Reserved graph grammar: A specification tool
for diagrammatic VPLs //Visual Languages, 1997. Proceedings. 1997 IEEE
Symposium on. – IEEE, 1997. – С. 284-291.
123.
Zhang K. B., Zhang K., Orgun M. A. Using Graph Grammar to
Implement Global Layout for A Visual Programming Language Generation
System. – 2002.
124.
Zur Muehlen M., Nickerson J. V., Swenson K. D. Developing web
services choreography standards—the case of REST vs. SOAP //Decision Support
Systems. – 2005. – Т. 40. – №. 1. – С. 9-29.
125.
Zweigenbaum P. et al. A multi-lingual architecture for building a
normalised conceptual representation from medical language //Proceedings of the
Annual Symposium on Computer Application in Medical Care. – American
Medical Informatics Association, 1995. – С. 357.
126.
Александров А. Е., Шильманов В. П. Инструментальные средства
разработки и сопровождения программного обеспечения на основе генерации
кода //От сервисов к субъектам. – 2012. – С. 10-16.
127.
Афанасьев А.Н., Брагин Д.Г., Гайнуллин Р.Ф. Распределеная
система анализа и контроля диаграмных языков // Всероссийская школа
семинар ИМАП-2012. – 2012г. - С. 21-26.
171
128.
Афанасьев
А.Н.,
Гайнуллин
Р.Ф.
Анализ
графических
спецификаций потоков проектных работ на примере языка UML// Вестник
УлГТУ- 4т. – 2010 г. С. 42-45.
129.
Афанасьев А.Н., Гайнуллин Р.Ф. Метакомпилятор диаграмных
языков // Автоматизация процессов управления. – С. 62-67.
130.
Афанасьев А.Н., Гайнуллин Р.Ф. Система контроля диаграммных
языков // Материалы III международной научно-практической конференции
Объектные Системы-2011 – 2011г. - С. 29-32.
131.
Афанасьев А.Н., Гайнуллин Р.Ф., Шаров О.Г. Программная
система анализа диаграммных языков // Программные продукты. – 2012. - №
3. – С. 138-141.
132.
Афанасьев, А. Н. Автоматная графическая грамматика / А. Н.
Афанасьев, О. Г. Шаров // Вестник УлГТУ. – 2005. – №1. –
133.
диаграмм /
С. 54-56.
Афанасьев, А. Н. Методы и средства трансляции графических
О. Г. Шаров ,А. Н. Афанасьев // Программирование. – 2011. –
№3. – С. 65-76.
134.
Афанасьев, А. Н. Нейтрализация синтаксических ошибок в
графических языках / О. Г. Шаров, А. Н. Афанасьев // Программирование. –
2008. – №1. – С. 61-66.
135.
Боковой Ю. В. Особенности методологии проектирования
информационных систем для малого и среднего бизнеса // Прикладная
информатика. 2006. №5. С. 3-11.
136.
Брагин Д.Г., Гайнуллин Р.Ф. Анализатор диаграммных языков
для диаграммного редактора Microsoft Visio // Информационные системы. –
2013 - №6. – С. 18-21.
137.
процессов
Вендров А. М. Методы и средства моделирования бизнес(обзор)
//
JetInfo.
—
№
10
(137).
—
2004.
—
http://www.jetinfo.ru/2004/10/1/article1.10.2004.html.
138.
Гайнуллин Р.Ф. Анализ диаграммных спецификаций потоков
проектных работ в технологии RUP// Сборник научных трудов 4-й
172
Российской научно-технической конференции аспирантов,
студентов и
молодых ученных ИВТ-2012. - 2012г. - С.128 -134.
139.
Гайнуллин Р.Ф. Анализ семантики диаграмм языка UML//
Всероссийская школа семинар ИМАП-2011. – 2011г. 140.
Гайнуллин
Р.Ф.
Аналитический
обзор
С.104 -108.
по
графическим
грамматикам// Всероссийская школа семинар ИМАП-2010. – 2010г. - С.142 146.
141.
Гайнуллин
Р.Ф.
Контроль
графических
спецификаций
в
процессах коллективного проектирования автоматизированных систем//
Сборник научных трудов 5-й Российской научно-технической конференции
аспирантов, студентов и молодых ученных ИВТ-2013. - 2013г. - С. 31-39.
142.
Гайнуллин Р.Ф. Метод нейтрализации синтаксических ошибок В
RV-грамматиках// Всероссийская школа семинар ИМАП-2012. – 2012г. - C.
52-63.
143.
Гайнуллин
Р.Ф.
Разработка
анализатора
UML-диаграмм//
Сборник научных трудов 3-й Российской научно-технической конференции
аспирантов, студентов и молодых ученных ИВТ-2011. – 2011г. - С.166 -169.
144.
Гайнуллин Р.Ф. Разработка метода нейтрализации ошибок для
анализатора диаграммных языков// Сборник научных трудов 3-й Российской
научно-технической конференции аспирантов,
студентов и молодых
ученных ИВТ-2011. - 2011г. - С.169 -174.
145.
Гайнуллин Р.Ф., Брагин Д.Г. Анализатор диаграммных языков
для Microsoft Visio// Материалы III международной научно-практической
конференции Объектные Системы-2012 – 2012г. - С. 40-45.
146.
ГОСТ
34.003-90.
Автоматизированные
системы.
Термины и определения.
147.
ГОСТ
34.601-90
Информационная
технология.
Комплекс
стандартов на автоматизированные системы. Автоматизированные системы.
Стадии создания
173
148.
ГОСТ
34.601-90.
Автоматизированные
системы.
Стадии
создания.
149.
Грищенко В. Н., Лаврищева Е. М. Компонентно-ориентированное
программирование. Состояние, направления и перспективы развития
//Проблемы программирования. – 2002. – №. 1-2. – С. 80-90.
150.
Гуров В. С., Мазин М. А., Шалыто А. А. Текстовый язык
автоматного программирования //Тезисы докладов Международной научной
конференции,
посвященной
памяти
профессора
АМ
Богомолова
«Компьютерные науки и технологии». Саратов: СГУ. – 2007. – С. 66-69.
151.
Замятина О. М. Метод моделирования и комплексного анализа
бизнес-процессов // Известия ТПУ. - 2005. - №6. С.180-186
152.
анализа
Марка Д.А., МакГоуэн К. SADT. Методология структурного
и
проектирования.
Режим
доступа:
http://www.pqm-
online.com/assets/files/lib/marka.pdf (дата обращения 22.07.2013)
153.
Месарович М., Мако Д., Такахара И. Теория иерархических
многоуровневых систем.// М.: Мир, 1973. – 344 с.
154.
Новиков Д. А. Теория управления организационными системами.
– М. : Моск. психол.-соц. ин-т, 2005.
155.
Обзор языка XAML (Windows) URL: http://msdn.microsoft.com/ru-
ru/library/windows/apps/hh700354.aspx (Дата обращение 10.03.2014)
156.
Паронджанов С.Д. Методология создания корпоративных ИС//
CIT форум образования (эл. журнал). - 2003. - № 4
157.
систем
Платонов Ю. Г. Анализ перспектив перехода информационных
на
сервисно-ориентированную
архитектуру
//Проблемы
информатики. – 2011. – №. 4. – С. 56-65.
158.
Попов, А. В. Объектно-ориентированный анализ, проектирование
и программирование информационной системы университета / А. В. Попов,
А. Л. Григорьева, А. Ю. Лошманов // Современные проблемы науки и
образования (эл. журнал). - 2012. - № 6
174
159.
Профессиональное программное обеспечение для построения
схем - Microsoft Visio - Office.com URL: http://office.microsoft.com/ ru-ru/visio/
(Дата обращение 12.02.2014)
160.
Репин
В.
Бизнес-процессы.
Моделирование,
внедрение,
управление.// М.:Манн, Иванов и Фербер - 2010. - 512 с.
161.
Соснин П.И., Афанасьев А.Н., Гайнулллин Р.Ф. Анализатор
диаграматических моделей потоков проектных работ на основе UML.
РОСПАТЕНТ: свидетельство № 2012612447 от 6 марта 2012г.
162.
Афанасьев
А.Н.,
Гайнулллин
Р.Ф.
Синтаксически-
ориентированный анализатор UML-диаграмм для MS Visio. РОСПАТЕНТ:
свидетельство № 2012617248 от 13 августа 2012г.
163.
Афанасьев А.Н., Брагин Д.Г., Гайнулллин Р.Ф. Сетевая система
анализа и контроля диаграмматических моделей потоков проектных работ
компьютеризированных систем. РОСПАТЕНТ: свидетельство № 2013661176
от 29 ноября 2013г.
164.
Соснин П.И., Маклаев В.А. Инструментальные средства для
спецификации концептуализаций в проектировании автоматизированных
систем// Онтология проектирования – 2012г., № 1 - С. 39-53
165.
Степанов О. Г., Шалыто А. А., Шопырин Д. Г. Предметно-
ориентированный
язык
автоматного
программирования
на
базе
динамического языка Ruby //Информационно-управляющие системы. – 2007.
– №. 4.
166.
Фу К. Структурные методы в распознавании образов.— М.: Мир,
1977.— 319 с.
167.
Черемных С. В. Структурный анализ систем: IDEF-технологии. //
М.: Финансы и статистика - 2003.
175
Приложение 1.Схема потоков бизнес-процессов этапа «Деловое
моделирование» в методологии RUP
БП1.1
БП1.2
БП1.3
БП1.4
БП1.5
БП1.6
БП1.7
БП2.1
БП4.1
БП4.2
БП4.3
БП6.1
БП2.2
БП6.2
БП6.3
Рис. П1.1. Схема потоков бизнес-процессов этапа «Деловое
моделирование» в методологии RUP
БП 1.1. Оценка целевой организации
БП 1.1.1. Инициализация оценивания
БП 1.1.2. Идентификация совладельцев
БП 1.1.3. Описание структуры целевой организации
БП 1.1.4. Идентификация ключевых лиц
БП 1.1.5. Оценивание бизнес-идеи и бизнес-стратегии
БП 1.1.6. Измерение целевой организации
БП 1.1.7. Идентификация скрытых причин для изменений
БП 1.1.8. Оценивание объѐма изменений
БП 1.1.9. Идентификация проблем
БП 1.1.10. Оформление заключения
БП 1.2. Постановка и регулирование целей
БП 1.2.1. Определение границ целевой организации
БП 1.2.2. Идентификация совладельцев
БП 1.2.3. Сборка соглашения по целям
БП 1.2.4. Идентификация накладываемых ограничений
БП 1.2.5. Формулирование проблемы
БП 1.2.6. Оформление приоритетных областей
176
БП 1.2.7. Формирование документа «Деловое видение»
БП 1.2.8. Оценивание результатов
БП 1.3. Формирование общего бизнес
БП 1.3.1. Нахождение общих термов
БП 1.3.2. Оценивание результатов
БП 1.4. Определение деловой архитектуры
БП 1.4.1. Создание обзора деловой архитектуры
БП 1.4.2. Описание сил, влияющих на деловую архитектуру
БП 1.4.3. Ранжирование деловых вариантов использования
БП 1.4.4. Наметка контуров организации верхнего уровня
БП 1.4.5. Идентификация бизнес-процессов
БП 1.4.6. Наметка контуров приоритетных реализаций деловых
прецедентов
БП 1.4.7. Определение географического вида
БП 1.4.8. Определение человеческих ресурсов
БП 1.4.9. Оценка результатов
БП 1.5. Идентификация бизнес-целей
БП 1.5.1. Анализ конкурентного позиционирования
БП 1.5.2. Определение бизнес-целей
БП 1.5.3. Описание измерений
БП 1.5.4. Структуризация бизнес-целей
БП 1.5.5. Оценивание результатов
БП 1.6. Обслуживание бизнес-правил
БП 1.6.1. Сбор исходных данных
БП 1.6.2. Выражение правил
БП 1.6.3. Оценивание результатов
БП 1.7. Поиск бизнес-акторов и деловых прецедентов
БП 1.7.1. Поиск бизнес-акторов
БП 1.7.2. Поиск деловых прецедентов
БП 1.7.3. Рассмотрение бизнес-целей
БП 1.7.4. Ранжирование деловых прецедентов
БП 1.7.5. Создание эскиза бизнес-процессов деловых прецедентов
БП 1.7.6. Описание взаимодействия бизнес-акторов и деловых
прецендентов
БП 1.7.7. Группирование деловых прецедентов и бизнес-акторов
БП 1.7.8. Представление модели деловых прецедентов
БП 1.7.9. Разработка обзора модели деловых прецедентов
БП 1.7.10. Оценка результатов
Владелец
Анализ
субъектов
системы
Детальный
анализ
системы
Бизнесаналитик
Бизнесаналитик
Бизнесаналитик
Определение
входных
требований
Разработка
видения
Исследование
субъектов
системы
Разработка
Бизнесдополнительных аналитик
спецификаций
Разработка
видения
системы
Утверждение
бизнес-целей
Бизнесаналитик
Утверждение
тезауруса
Предметной
области
Цель
Создание
общего словаря
Бизнес-моделирование
БП
2.
Название
Расширение
спецификаций
системы
Список
участников
системы
Видение
Раскадровка
требований
Глоссарий
Результат
Словарь общий
определений
Выход
План итераций
Запросы заказчиков
системы
Запросы заказчиков
системы
Дополнительные
спецификации
Модель прецедентов
Экономическое
Бизнес-видение
обоснование проекта
Запросы заказчиков
системы
Экономическое
Запросы заказчиков
обоснование проекта системы
Документация
предметной области
Вход
Таблица П1.1. Содержательное описание бизнес-процессов этапа «Деловое проектирование»
177
Бизнесаналитик
Управление
зависимостями
Технически
й писатель
Технически
й писатель
Технически Контроль
й контролер требований
Детализация
вариантов
Требований к
ПО
Контроль
требований
Детализация
список
вариантов
Определение
требований к
ПО
Архитектор Разработка
стратегии
реализации
Утверждение
зависимостей
Цель
Определение
приоритетов
вариантов
Анализ требований
Владелец
Название
Видение
План итераций
Варианты
План Итераций
План итераций
Модель прецедентов
Список рисков
Модель прецедентов
Дополнительные
спецификации
Вход
Спецификации ПО
Требования ПО
Детализированные
варианты
Архитектура
системы
Требования к ПО
План управления
зависимостями
Выход
Непротиворечи План итераций
Проверки записи
вые требования Экономическое
к системы
обоснование проекта
Требование ПО
Список ПО
Детализирован
ные варианты
План
проведения
работ
План
управления
требованиями
Результат
Таблица П1.1. Содержательное описание бизнес-процессов этапа «Деловое проектирование» (продолжение)
178
Владелец
Построение
концепции
Оценка
концепции
Системный
архитектор
Системный
архитектор
Архитектурный
анализ
Построение
концепции
системы
Оценка
Системный
жизнеспособнос архитектор
ти системы
Анализ
архитектуры
Архитектор Выявление
-аналитик
окружения
системы
Цель
Определение
Контекста
системы
Анализ и проектирование
Название
Оценка
доказательства
концепции
Концепция
системы
Детализация
архитектуры
Контекстное
окружение
системы
Результат
Доказательство
концепции
архитектуры
Видение
Глоссарий
Архитектура ПО
Модель
развертывания
Модель проекта
Модель анализа
Дополнительные
спецификации
Модель прецедентов
Видение
Глоссарий
Список рисков
Вход
Проверки записи
Модель проекта
Модель
развертывания
Модель анализа
Доказательство
концепции
архитектуры
Аналитическая
модель
Операции
Выход
Таблица П1.1. Содержательное описание бизнес-процессов этапа «Деловое проектирование» (продолжение)
179
Архитектор Анализ
проектиров Операции
щик
Анализ
операций
Проектирование Архитектор Разбиение на
подсистем
проектиров подсистемы
щик
Проектирование Проектиров Разработка
интерфейса
щик
шаблона
интерфейсо интерфейса
в
Создание
Проектиров Разработка
прототипа
щик
интерфейсов
интерфейса
интерфейсо
в
Архитектор Анализ
проектиров вариантов
щик
Анализ
прецедентов
Цель
Владелец
Название
Интерфейсы
Список прецедентов
Схема навигации
Прототипы
интерфейсов
Список
подсистем
Требование ПО
Модель анализа
Операция
Модель прецедентов
Варианты
Вход
Эскиз
прототипы
интерфейсов
Реализация
операции
Модель
вариантов
Результат
Модель проекта
Прототипы
интерфейсов
Схема навигации
Модель анализа
Модель прецедентов
Модель анализа
Реализация
прецедентов
Выход
Таблица П1.1. Содержательное описание бизнес-процессов этапа «Деловое проектирование» (продолжение)
180
181
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
MagicDraw UML
+
GenMyModel
+
Gaphor
Синхронный вызов до
получения ответа
Enterprise Architect
+
+
DIA
Взаимоисключающие
связи
+
Eclipse UML2 Tools
+
BOUML
Нарушение кратности
зависимостей
Borland Together
+
ATL
Вызов направленный в
линию жизни
Оборванная связь
+
Astah
Количественная
ошибка элементов
диаграммы
Исключающие связи
неверного типа
+
Artisan Studio
Ошибка делегирования
управления
+
Altova UModel
Семантическая ошибка
Циклическая связь
Взаимоисключающие
связи
Множественная связь
Ошибка удаленного
контекста
Ошибка передачи
управления
Ошибка кратности
входов
Ошибка кратности
выходов
Недопустимая связь
Ошибка связи
Ошибка уровня
доступа
Ошибка передачи
сообщения
Aris Toolset
Таблица П2.1. Характеристика редакторов UML- диаграмм
Приложение 2. Обзор редакторов диаграмм UML
Семантическая ошибка
Циклическая связь
Взаимоисключающие
связи
Множественная связь
Ошибка удаленного
контекста
Ошибка передачи
управления
Ошибка кратности входов
Ошибка кратности выходов
Недопустимая связь
Ошибка связи
Ошибка уровня доступа
Ошибка передачи
сообщения
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Ошибка делегирования
управления
+
Количественная ошибка
элементов диаграммы
+
Исключающие связи
неверного типа
+
Вызов направленный в
линию жизни
+
Оборванная связь
Нарушение кратности
зависимостей
+
+
+
+
Взаимоисключающие
связи
+
+
Rational Software Modeler
Visual Paradigm for UML
+
MS Visio
+
RTDS
+
Rational Software Architect
Prosa UML Modeller
Poseidon for UML
PlantUML
Papyrus
Objecteering
Modelus Suite
Синхронный вызов до
получения ответа
Rational Rhapsody
+
Modelio
Таблица П2.1. Характеристика редакторов UML- диаграмм (продолжение)
182
183
Приложение 3. Многоуровневая грамматика комплексных UMLдиаграмм
Таблица П3.1. Многоуровневая грамматика комплексных UML диаграмм
Комплекс
Квази-терм
r1 0
RI
r1 3
W1 (it(1))/W3 (it(1) ==
|| it(2) ==
)
2.
RE
r1 4
W1 (it(1))/W3 (it(1) ==
|| it(2) ==
)
3.
RG
r1 5
W1 (it(1))/W3 (it(1) ==
|| it(2) ==
)
4.
RI
r1 6
5.
RE
r1 7
6.
RG
r1 8
7.
̅R̅I
r
8.
̅R̅E
r
9.
̅R̅G
r
10.
̅R̅I
r
11.
̅R̅E
r
12.
̅R̅G
r
RA
r1 2
RG
r1 5
пп
1.
13.
r1 1
14.
Комплекс – Комплекс –
преемник
возврата
4
0
4
0
4
0
4
0
4
0
4
0
15.
r1 2
C
r1 0
16.
r1 3
C
r1 0
17.
r1 4
C
r1 0
18.
r1 5
C
r1 0
A
r1 1
19.
RV – отношение
r1 3
W1 (it(1))/W3 (it(1) ==
|| it(2) ==
)
r1 4
W1 (it(1))/ W3 (it(1)==
|| it(2)== )
r1 5
W1 (it(1))/ W3 (it(1)==
|| it(2) ==
)
r1 6
r1 7
r1 8
20.
r1 6
C
r1 0
W1 (it(2))/W3 (it(1) ==
|| it(2) ==
)
21.
r1 7
C
r1 0
W1 (it(2))/W3 (it(1) ==
|| it(2) ==
)
22.
r1 8
C
r1 0
W1 (it(2))/W3 (it(1) ==
|| it(2) ==
)
A
r1 1
23.
184
Таблица П3.1. Многоуровневая грамматика комплексных UML диаграмм (продолжение)
Комплекс
Квази-терм
r2 0
LinkC
r2 1
W1 (it(1))/W3 (it(1) ==
|| it(2) ==
)
25.
Linkn
r2 2
W1 (it(3))/W3 (it(3) ==
|| it(4) ==
)
26.
LinkG
r2 3
W1 (it(5))/W3 (it(5) ==
|| it(6) ==
)
27.
LinkA
r2 4
W1 (it(7))/ W3 (it(7)==
|| it(8) ==
)
28.
LinkK
r2 5
W1 (it(9))/ W3 (it(9) ==
|| it(10) ==
)
29.
AXOR
r2 7
пп
24.
Комплекс – Комплекс –
преемник
возврата
RV – отношение
30.
r2 1
C
r2 0
W1 (it(2))/ W3 (it(1) ==
|| it(2) ==
)
31.
r2 2
C
r2 0
W1 (it(4))/ W3 (it(3) ==
|| it(4) ==
)
32.
r2 3
C
r2 0
W1 (it(6))/ W3 (it(5) ==
|| it(6) ==
)
33.
r2 4
C
r2 0
W1 (it(8))/ W3 (it(7) ==
|| it(8) ==
)
34.
r2 5
C
r2 0
W1 (it(10))/W3 (it(9) ==
|| it(10) ==
)
35.
r2 6
LinkC
r2 1
W1 (t1m)
36.
r2 7
C
r2 0
W2 (t1m)
37.
r2 8
C
r2 0
38.
r
3
0
L
r3 6
39.
r3 1
M
r3 3
40.
MA
r3 4
41.
MR
r3 5
42.
L
r3 6
M
r3 3
W1 (mt(1))
44.
MA
r3 4
W1 (mt(2))
45.
MR
r3 5
46.
L
r3 6
47.
M
r4 0
r3 3
W1 (mt(1))
48.
MA
r4 0
r3 4
W1 (mt(2))
43.
3
r
2
W2 (mt(2))
185
Таблица П3.1. Многоуровневая грамматика комплексных UML диаграмм (продолжение)
Комплекс
Квази-терм
пп
Комплекс – Комплекс –
преемник
возврата
49.
MR
r4 0
r3 5
50.
L
r4 0
r3 6
R
r3 1
F
r3 2
51.
3
r
3
52.
RV – отношение
W2 (mt(2))
53.
r3 4
F
r3 2
54.
r3 5
F
r3 2
W2 (mt(1))
55.
r
3
F
r3 2
W1 (mt(1))
D
r3 7
M
r3 3
MA
r3 4
6
56.
57.
3
r
7
58.
59.
r
0
label
r4 3
60.
r4 1
label
r4 3
label
r3 0
labelP
4
r
3
W2 (b1m )
63.
labelW
r4 3
W2 (b2m )
64.
labelR
r4 3
W2 (b3m )
65.
labelL
r4 3
W2(b2m)/
W3(mt(4)=mt(3))
A
r4 1
67.
P
r4 1
W1 (t1m )
68.
W
r4 2
W1(1t(1),t2m)/
W2(et(1))
69.
W
r4 2
70.
R
r4 1
W1(2t(2))/W2(1t(2))
W1(it(3),t1m)/
W3(k>1)
71.
L
r4 2
W1(it(2),kt(3),t4m)/
W2(et(2))
72.
L
r4 2
W1(inc(mt(2)))/
W3(mt(2)<kt(3))
73.
AK
r4 k
A
r5 0
label
r5 1
4
61.
62.
66.
74.
75.
4
r
2
r4 3
r5 0
4
r
3
186
Таблица П3.1. Многоуровневая грамматика комплексных UML диаграмм (продолжение)
Комплекс
Квази-терм
пп
76.
77.
r5 1
78.
Комплекс – Комплекс –
преемник
возврата
RV – отношение
labelI
r5 2
A
r5 0
labelI
r5 2
W1 (t1m)
W2 (t1m))
79.
r5 2
I
r5 3
80.
r5 3
A
r5 1
W1 (t1m)
187
Приложение 4. Процедуры онтологического разбора
Квазитерм
Таблица П4.1 Процедуры онтологического разбора
Текстовая единица
Местоположение в
модели
Use Case Diagram
Actor
Подлежащее
actor
Use Case
Сказуемое
action
Подлежащее
content
Extends
Сказуемое
action
Include
Сказуемое
action
General
Сказуемое
action
class
Сказуемое
task
link
Сказуемое
event
Подлежащее
action
object
Сказуемое
content
link
Сказуемое
event
Подлежащее
action
Сказуемое
content
Подлежащее
action
Сказуемое
content
Class Diagram
Sequence Diagram
Activity Diagram
action
if
188
Приложение 5. Акты о внедрении
189