Содержание к диссертации
Введение
Глава 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
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
- Анализ методов контроля диаграмматических спецификаций в процессе проектирования бизнес-процессов
- Оценка временных затрат многоуровневых грамматик
- Разработка структуры метакомпилятора диаграмматических нотаций бизнес-процессов на примере языка UML
- Разработка плагина для редактора Microsoft Visio
Введение к работе
Актуальность темы. Подход к проектированию и реинженирингу автоматизированных систем (АС), в основу которого положено системное представление организации и функционирования АС в виде бизнес-процессов, является в настоящее время одним из эффективных и активно применяемых на практике.
Под понятием «бизнес-процесс» понимают регулярно повторяющуюся
последовательность комплексов мероприятий, направленных на
удовлетворение потребностей потребителя с целью извлечения полезных эффектов.
Для представления и обработки бизнес-процессов широкое
распространение получили средства диаграмматики, использующие
графические нотации языков UML, IDEF, BPMN, DFD, ER-диаграмм и других. Практика проектирования АС показала, что использование диаграмматики значительно повышает эффективность процесса проектирования и качество создаваемых систем за счет унификации языка взаимодействия участников процесса создания АС, строгого документирования проектно-архитектурных, функциональных решений и формального контроля корректности диаграммных нотаций.
Наиболее распространенным диаграмматическим инструментом,
используемым на всех этапах создания АС, является язык UML. Однако в современной теории и практике применения UML-диаграмматики в проектировании АС наблюдается слабое развитие методов и средств анализа и контроля корректности проектируемых диаграмм. Отсутствуют средства контроля корректности семантической согласованности диаграммных нотаций в процессе коллективного проектирования. Данные факты открывают дополнительный источник трудно диагностируемых и «дорогих» ошибок в создании АС, их анализ и контроль является актуальной научно-технической задачей.
Целью диссертационной работы является расширение класса
диагностируемых ошибок в процессе проектирования АС за счет развития и реализации методов и средств анализа и контроля диаграммных нотаций бизнес-процессов, что позволяет сократить ошибки и время создания АС.
В соответствии с поставленной целью в работе формулируются и решаются следующие задачи исследования.
1. Анализ существующих методов контроля диаграмматических нотаций бизнес-процессов в проектировании АС.
-
Анализ структурных особенностей диаграмматики описания бизнес-процессов. Разработка многоуровневой автоматной графической RV-грамматики.
-
Анализ семантических особенностей графических нотаций бизнес-процессов. Разработка метода контроля семантической целостности комплекса диаграмм в процессе коллективного проектирования.
-
Анализ методов нейтрализации ошибок. Разработка алгоритма формирования множества комплексов продукций-продолжателей для автоматной графической RV-грамматики.
-
Анализ методов метакомпиляции. Разработка метода синтеза таблицы автоматной графической RV-грамматики.
-
Разработка программного обеспечения, позволяющего производить эффективный анализ и контроль графических нотаций бизнес-процессов в диаграмматике UML.
Объектом исследования является применение диаграмматики бизнес-процессов при разработке АС.
Предметом исследования являются модели, методы и средства анализа и контроля диаграмматики бизнес-процессов, используемые для выявления синтаксических (топологических) и семантических ошибок.
Методы исследования основаны на использовании положений и методов теории множеств, теории графов, теории автоматов, теории формальных языков, теории графических языков, математической лингвистики, теории искусственного интеллекта, а также использовании основ системотехники и теории автоматизированного проектирования.
Научная новизна определяется разработанными методами и средствами анализа и контроля диаграмматики бизнес-процессов, основу которых составляют авторские графические грамматики. В результате исследований получены следующие результаты.
-
Предложен новый метод анализа и контроля диаграмматических нотаций бизнес-процессов на основе автоматных многоуровневых графических RVM-грамматик, отличающийся введением понятия «сабтерма», учитывающий комплексную и иерархическую природу диаграмматических нотаций бизнес-процессов и позволяющий расширить класс диагностируемых ошибок за счет возможности определения ошибок, распределенных по взаимосвязанным диаграммам.
-
Предложен новый метод анализа и контроля семантических ошибок диаграмматических нотаций бизнес-процессов в составе комплексной диаграммы, созданной в процессе коллективного проектирования, на основе автоматных графических RV-грамматик, отличающийся использованием
графовой модели отношений понятий семантической текстовой информации диаграмм и позволяющий расширить класс ошибок, диагностируемых в процессе проектирования АС, и, тем самым, сократить время проектирования АС. Извлечение семантической информации из диаграммных нотаций происходит при помощи адаптированного метода лексико-синтаксических шаблонов.
-
Предложен новый метод синтеза автоматной графической RV-грамматики, отличающийся оригинальностью текстовых правил описания конструкций диаграмматических нотаций бизнес-процессов, ориентированных на использование в метакомпиляторе, обеспечивающих полноту описания их особенностей и позволяющих автоматически сформировать таблицу RV-грамматики, включая операции с внутренней памятью.
-
Впервые предложен алгоритм формирования множества комплексов продукций-продолжателей для автоматной графической RV-грамматики, позволяющий эффективно продолжать анализ с минимальным количеством пропущенных термов входного предложения диаграмматической нотации бизнес-процесса, что повышает производительность труда проектировщика и сокращает время разработки АС.
Практическая ценность
Практические результаты диссертационной работы:
-
разработан анализатор диаграмматических моделей потоков бизнес-процессов вопросно-ответной системы моделирования АС;
-
разработан синтаксически-ориентированный анализатор UML-диаграмм для MS Visio, позволяющий обнаруживать допущенные при построении диаграмм синтаксические ошибки;
-
разработана архитектура системы анализа и контроля корректности диаграммных спецификаций, предлагающая полный набор функциональности для анализа и контроля синтаксических и семантических ошибок.
На защиту выносятся следующие новые и содержащие элементы новизны основные положения:
-
метод анализа и контроля диаграмматики бизнес-процессов на основе многоуровневых графических RVM-грамматик;
-
метод анализа и контроля семантических ошибок диаграмматических нотаций бизнес-процессов в составе комплексной диаграммы;
-
метод синтеза автоматной графической RV-грамматики;
-
алгоритм автоматического формирования комплексов-продолжателей;
-
разработанные программные средства анализа и контроля синтаксических и семантических ошибок.
Реализация и внедрение результатов работы. Работа выполнена в рамках гранта РФФИ № 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.
Публикации. По теме диссертации опубликована 21 печатная работа, в том числе 3 в журналах списка ВАК. Получено 3 СВИДЕТЕЛЬСТВА (РОСПАТЕНТ) об официальной регистрации программ для ЭВМ.
Структура и объем работы. Диссертационная работа состоит из введения, четырех глав с выводами, заключения, библиографического списка, изложенных на 174 страницах машинописного текста, а также приложения на 15 страницах машинописного текста, содержит 37 рисунков и 21 таблицу. Список литературы включает 167 наименований.
Анализ методов контроля диаграмматических спецификаций в процессе проектирования бизнес-процессов
В процессе разработки АС для достижения предсказуемого результата используют некоторый набор практик и методов. ГОСТ 34.601-90 [148] определяет 8 этапов разработки АС: формирование требований, концептуальное проектирование, разработка технического задания, эскизный проект, технический проект, разработка рабочей документации, ввод в эксплуатацию, сопровождение. Для реализации каждого из этапов используются одна из множества технологий проектирования АС. В настоящее время основными мастер технологиями являются ARIS и RUP [158,156,135].
ARIS [93, 91, 118, 19] - платформа основанная на рассмотрении бизнес-процессов с пяти основных точек зрения: функциональный анализ - моделирование всех функций преобразующих входной поток в выходной; организационный анализ - описание организационной структуры предприятия; анализ данных - описание входных и выходных данных, ограничения, наложенные на них, и контекста, в котором происходит операции с данными; анализ результатов деятельности - моделируются предполагаемые результаты деятельности; контроль моделей - анализируются созданные ранее модели и устраняются недочеты обнаруженные в процессе анализа. Концепция фреймворка ARIS и жизненный цикл моделей ARIS описывается диаграммой (рис. 1.7), называемой «Дом ARIS» или «ARIS house» [92]. Рис. 1.7. Модель ARIS house RUP – регламентированное описание этапов процесса создания приложения. RUP обеспечивает регламентированный подход к исполнению задач и обязанностей в группе разработки. Его цель состоит в том, чтобы гарантировать создание высококачественного программного обеспечения, которое соответствует потребностям его конечных пользователей в рамках графика и бюджета [114, 15, 50].
RUP [44] разработана и поддерживается компанией Rational Software. Группа разработчиков работает в постоянном тесном контакте с клиентами, партнерами, промышленными группами, чтобы гарантировать, что процесс непрерывно обновляется и улучшается, чтобы постоянно вводить только лучшие современные практики разработки. RUP призывает активно создавать и поддерживать диаграмматические модели. Вместо создания большого количества печатных документов, RUP поддерживает активное использование моделей — семантически богатых представлений разрабатываемой системы программного обеспечения [51, 14].
При исследовании вопроса моделей в RUP составлена следующую схема взаимодействий моделей. Узлы схемы могут быть более детализированы или отсутствовать в конечной реализации конкретной сложной АС. Рис. 1.8. Схема взаимодействия моделей методологии RUP RUP различает три этапа разработки, где активно используется UML [5]: бизнес-моделирование; составление требований; анализ и проектирование.
Рассмотрим применение диаграмматических моделей на каждом из этих этапов разработки сложной АС и схему взаимодействия различных моделей друг с другом. Бизнес-моделирование В RUP выделяются две основные модели в процессе бизнес-моделирования [45]: модель бизнес-вариантов использования, которая описывает внешние взаимодействия организации с точки зрения бизнеса; модель бизнес-анализа, которая показывает, как предприятие ведет себя внутренне, чтобы выявить все узлы предприятия и их взаимодействие.
На рис. 1.8 эти модели находятся на верхнем уровне, что говорит об их основополагающем значении в процессе проектирования.
Модели бизнес-вариантов использования определяют взаимодействие бизнеса и окружения. В этом случае бизнес-процесс рассматривается как черный ящик. Варианты бизнес-использования описываются с точки зрения актора. Для делового агента «потребитель» примером может быть вариант использования «заказать модуль», а для «исполнителя» - «реализовать требования». Для описания бизнес-модели, дополнением служат следующие диаграммы: диаграмма пакетов - большая модель делится на группу более конкретных и представляется с помощью диаграммы пакетов; диаграмма вариантов использования - демонстрирует бизнес-возможности взаимодействий и связанных с ними акторов; диаграмма активности - показывает поток работ в зависимости от некоторых событий в системе.
Аналитическая бизнес-модель описывает внутреннее функционирование бизнеса. Модель предназначена, чтобы разобрать внутренние процессы при различных вариантах бизнес-использования. Здесь анализируются бизнес-процессы и потоки операций. Также моделируется организационная структура и потоки данных. Для анализа используют следующие виды диаграмм: диаграмма классов описывает структуру организации и потоки данных в ней. Бизнес-акторы - активные объекты: сотрудники и информационные системы. Сущности - пассивные объекты: документы и продукты; диаграмма активности - модель потока работ, фокусирующаяся на действиях. Деловые рабочие - блоки схемы, содержащие действия. Сущности - вход и выход этих действий; диаграмма взаимодействия - модель потока бизнес-процессов, фокусирующаяся на обмене сообщениями между исполнителями или контролерами бизнес-процессов; диаграмма конечного автомата - иерархическое описание некоторого бизнес-процесса. Анализ требований
На основе построенной бизнес-модели делаются выводы о требованиях и ограничениях к архитектуре создаваемой АС. Для анализа требований используется диаграмма вариантов использования, опирающаяся на бизнес-модели. Эта диаграмма становится основополагающей для остального процесса проектирования.
Модель варианта использования рекомендована для всех RUP-проектов. Эта модель формируется в процессе итеративного выполнения трех основных операций: 1) описание участников - кто фактически работает с системой, с точки зрения ролей использования; 2) идентификация самих вариантов использования - чего участники хотят достигнуть при помощи системы; 3) определения отношения между вариантами использования и каждым участником бизнес-процесса. Участники часто идентифицируются на этапе бизнес-анализ а как потребители и поставщики. Они - те, кто использует систему, чтобы автоматизировать выполнение их рабочих потребностей. Участник (агент) может полностью соответствовать деловому агенту, в случае, если деловой агент может получить доступ к системе непосредственно.
Согласно RUP, варианты использования могут быть получены из бизнес-вариантов использования, но это - только возможно, если соответствующий агент идентичен деловому агенту. Это не означает, что есть непосредственное соответствие между бизнес-вариантами использования и вариантами использования в разрезе анализа требований.
Большинство практиков RUP пишет уточнение вариантов использования только как текст на естественном языке. Это работает хорошо. Но может также стать проблемой в последующем. При осознании, что в процесс нужно внести корректировки, текстовое описание превращается во множество громоздких ссылок на этапы процесса. Поэтому на данном этапе рекомендовано составить диаграмму активности, чтобы наглядно представить потоки бизнес-процессов при функционировании системы.
Оценка временных затрат многоуровневых грамматик
Сегодня проектировщикам в их деятельности помогают огромное количество проектных и аналитических инструментов, которые повышают производительность, уменьшают стоимость, минимизируют усилия, повышают производительность, улучшают восприятие, управление изменениями, надежность. Есть специализированные средства и инструменты во всех областях разработки. Средства моделирования помогают в анализе проблем, в проведении экспериментов или трудоемких аналитических операций. Так же модели являются хорошими.
Имеется определенный набор инструментов под названием Автоматизированная разработка программного обеспечения (CASE), которые используются в разработке программного обеспечения. Их использование похоже на подобные инструменты в других областях разработки в том смысле, что они помогают в анализе и разработке программного обеспечения.
Глобально CASE-средства можно разделить на две большие группы – универсальные графические редакторы и интегрированные средства построения графических спецификаций. Универсальные графические редакторы строят некоторое графическое описание работы без последующей его привязки к какой-либо модели. Такие редакторы нацелены на сохранение описания о визуальном представлении спецификации.
Интегрированные средства построения графических спецификаций работ служат для наполнения графическими спецификациями некоторой глобальной модели. Таким примером могут служить среда Rational Software 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. Также поддерживает диаграммы требований 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 предназначен для описания бизнес-процессов, их документирования, проведения анализа, дальнейшего улучшения и оптимизации Знания о бизнес-процессах компании, документируемые при помощи ARIS Toolset, не просто визуализируются в графическом виде, но и хранятся в базе данных ARIS Server. ARIS Toolset предоставляет большое количество многократно апробированных методов моделирования бизнес-процессов и это позволяет легко настраивать ARIS к требованиям проекта. ARIS Toolset состоит из следующих компонентов
Разработка структуры метакомпилятора диаграмматических нотаций бизнес-процессов на примере языка UML
При коллективном проектировании в группах важным является контроль непротиворечивости комплекса составляемых диаграмм. Проектировщики, составляя диаграммы, могут забыть учесть принятые ранее решения (отраженные на диаграммах). Например, проектировщик может конкретизировать некоторый компонент системы и упустить из внимания тот факт, что на предыдущих этапах подобный компонент был реализован с применением других технологий.
Для анализа на семантическую корректность предлагается составить многоуровневую грамматику. Верхний уровень композиционной грамматики будет грамматика диаграмм вариантов использования, потому что разработка систем должна начинаться именно с этой диаграммы (согласно методологии RUP). В процессе анализа будет накапливаться семантическая информация о предметной области, и каждая новая диаграмма будет добавляться в общую структуру на условиях непротиворечивого расширения понятий предметной области.
При построении первых диаграмм проверяются только семантическая непротиворечивость внутри диаграммы. Проверяется возможность использования понятий в семантической паре. При добавлении новых диаграмм проверяется непротиворечивость диаграммы обособлено и на непротиворечивость комплексной модели проектируемой АС (рис. 2.7).
Общая схема онтологического анализа UML диаграмм Для проверки комплексной модели необходимо построить граф семантических связей между элементами АС. Для решения данной задачи выбран адаптированный метод лексико-синтаксических шаблонов.
В настоящее время существуют два больших класса методов извлечения знания из корпусов текстов – статистический и метод шаблонов. Каждый из них имеет как преимущества, так и недостатки. Статистический метод главным образом ориентирован на обработку потока данных. Методы данного класса тем лучше, чем больше объемы исследуемых текстов. Методы, основанные на шаблонах, используют информацию о целевом языке для извлечения данных. Для методов этого класса характерно отсутствие зависимости от объемов исследуемого корпуса данных. Так как диагностирование ошибок важно с самых ранних этапов, был выбран метод из второй группы – метод лексико-синтаксических шаблонов.
Кратко опишем классический метод лексико-синтаксических шаблонов. Лексико-синтаксические шаблоны позволяют построить семантическую конструкцию, которая соответствует концептуальному содержанию единицы текста. Для этого используются особенности языка, на котором представлен текст. При анализе текстов используется отношение сочетаемости текстовых единиц – коолокация. Данное отношение говорит о фиксировании некоторых синтаксических и грамматических свойств в лексических единицах.
В графических грамматиках лексической единицей является терм (сабтерм) грамматики в паре с текстовыми характеристиками, погруженными в него. Из таких единиц составляется семантический граф диаграммного языка. Пусть элемент представляющий сущность на диаграмме будет называться блок, а связи между блоками – связями. Для наглядности предположим, что в блоках присутствует элементарные понятия (одиночные или составные).
Обозначим блоки через символ NP, а отношение через rel. Для диаграммы вариантов использования имеем 3 вида отношений rel: Включение и Расширение – отношение «часть-целое»; Агрегации – отношение «выше-ниже»; Связь – недетерминированное отношение. Тогда таксономию онтологии составят блоки NP. Онтологические отношения строятся на отношениях rel. Для этого используется правила вида NPi + rel + NPj. Правило для связи включения диаграммы вариантов использования определяет, что NPj является понятием верхнего уровня для понятия NPj. Для реализации модифицированного метода необходимо модифицировать правила продукций классической RV-грамматики. После выполнения правила продукции необходимо запустить процедуру извлечения семантической информации из графического элемента диаграмматики. Правило примет вид: at(z) WM, ",Yn) rm, где x процедура извлечения семантической информации.
Процедура состоит из поиска соответствующего правила в списке. Правило состоит из двух частей - 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) отображение онтологии; 2) выравнивание онтологий; 3) объединение онтологий. Отображение онтологии – процесс определяющий связующие звенья. На данном этапе происходит поиск точных совпадения текстовых единиц, совпадений в иерархических отношениях. Последнее обозначает поиск пары текстовых единиц находящихся в некотором иерархическом отношении (например, часть-целое). Примерами таких текстовых единиц могут быть АС-компонент, компонент-класс, класс-метод.
Выравнивание онтологий – это процесс поиска похожих мест в объединяемых онтологиях. Выявленные на этапе отображения онтологий пары подвергаются дальнейшему анализу. Цель такого анализа найти группы похожих между собой пар. Степень похожести определяется применением пар в одинаковых правилах в онтологии.
Объединение онтологий – процесс создания одной онтологии из двух исходных. На основе выявленных на предыдущем этапе групп строится объединнная онтология. Общей частью являются выделенные ранее группы.
Если на этапе объединения не получается найти объединяющего звена, то выдается предупреждение об ошибке. Такое предупреждение может сигнализировать о слишком большой разрозненности спроектированных диаграмм. Для устранения ошибок такого типа можно либо уточнить существующую диаграмму, либо добавить новую связующую.
Если объединение онтологий прошло удачно, то проводится анализ значимых характеристик онтологий для оценки корректности онтологии.
Рассмотрим пример онтологического преобразования. В качестве базовой диаграммы возьмем часть диаграммы Вариантов использования рис. 2 8. Для наглядности был выбран пример с небольшим числом элементов.
Разработка плагина для редактора Microsoft Visio
Важной задачей при анализе диаграмматических нотаций бизнес процессов в проектировании АС является восстановление работы анализатора после диагностирования ошибки. При выборе метода нейтрализации были исследованы основные методы нейтрализации. Их классификация представлена на рис. 3.3. Стрелками обозначена историческая связь между методами, т.е. метод продукций для ошибок появился в результате развития метода корректировки на уровне фразы.
Ниже исследуются указанные методы нейтрализации с возможностью их применения в автоматных RV-грамматиках, т.е. основной алгоритма являются «переходы по автомату», при этом выполняются операции с его внутренней памятью. Техника минимального преобразования и режим паники Одним из самых ранних методов восстановления анализа является техника минимального преобразования [3,4]. Метод заключается в разработке цепочки преобразований для коррекции ошибки. Класс трансформаций ошибок определяется следующим образом: каждый элемент класса есть преобразование, на вход которого подана цепочка P и который возвращает цепочку P`, такую что P` отличается на один и только один модифицированный символ (удаленный или добавленный). Цепочка P содержит k ошибок, если существует последовательность длиной k состоящая из элементов класса трансформаций ошибок, такой что преобразует последовательность P в P`, принадлежащую данному языку. Теоретически доказано[3], что все синтаксические ошибки могут быть скорректированы методом минимальных преобразований (что в принципе и делает автор при исправлении программы или графической нотации), но на практике этот метод входит в класс NP-полных задач [4].
Рассмотрим метод минимальных преобразований на примере элемента «условное ветвление» Диаграммы активности языка UML. Всего в диаграмме
активности восемь графических элементов. Для ошибки вида PP (за условным ветвлением, следует символ условного ветвления) допустимыми будут являться преобразования: PA0, PA, Plabel, PW, PR, PL, PAk. Всего семь преобразований. Если ошибка возникает в двух символах, то число преобразований увеличится в семь раз (рис. 3.4). С увеличением количества ошибок число возможных преобразований растет в геометрической прогрессии. Такой метод имеет неоправданно большие временные затраты.
Поэтому его практическое применение не оправдано.
В противовес данному методу был предложен «легкий» метод паники [11, 12]. Метод паники не корректирует ошибки совсем. В момент проектирования языка определяется множество специальных символов – опорные символы. При обнаружении ошибки из входной последовательности удаляются все символы вплоть до опорного, а память приводится в состояние достаточное для продолжения разбора. На практике данный метод приводит к пропуску большого количества входных символов, что приводит к пропуску ошибок и поэтому не применяется.
Рассмотрим метод паники на примере диаграммы представленной на рис. 3.5. Определим опорными символами квазитермы R и L. Впервые ошибка возникнет после выхода из множества состояний под номером 4. Следующим опорным символом во входном потоке является символ слияния параллельных ветвей. Совершая переход к нему, пропускаются группы №5, 6, 3. Таким образом, непроанализированным остается большое количество элементов.
Существует стратегия, основанная на работе анализатора без коррекции ошибки[84]. В данной стратегии предлагается разбора входной цепочки без какой-либо коррекции ошибок. Главная идея данной данного подхода состоит в том, что количество возможных ошибочных комбинаций настолько велико, что автор стратегии восстановления не сможет удержать их в голове. К тому же для каждого множества ошибок всегда может быть найдена такая ошибка, которая должна быть включена в это множество.
В момент обнаружения ошибки анализатор может предпринять несколько попыток по уменьшению неопределнности состояния. Все эти варианты удовлетворяют следующим требованиям: участок, на котором проявляется ошибка, идентифицируется однозначно; диагностирование ошибки происходит без попытки исправления ее; каждое сообщение об ошибке указывает на разные синтаксические ошибки; ложные сообщения не генерируются; ни один символ входной цепочки не изменяется, поэтому каждая ошибка ссылается на ошибки в языке или грамматике. Главное преимущество метода состоит в том, что диагностируемая ошибка определяется в контексте окружающих элементов, но обратной стороной может быть слишком большой контекст показываемый с ошибкой, на котором сложно исправить саму ошибку.
Рассмотрим восстановление анализа с использованием данного метода на примере предыдущей диаграммы рис. 3.5. Ошибка однозначно идентифицируется на участке блок 4 – символ параллельного слияния. Но по выходу из блоков 5 и 6 будет повторная генерация ошибки о том же элементе, следовательно, участок расширяется на блоки 4, 5, 6. Таким образом, количество элементов окружающих ошибочный становится очень большим, и поиск конкретной ошибки становится трудной задачей.
Нейтрализация на уровне фразы
Все методы нейтрализации перечисленные на рисунке имеют главной целью продолжение разбора с помощью исправления или пропуска ошибки. Методы нейтрализации могут изменять входную или цепочку, или стек, или входную цепочку и стек одновременно. Вся дополнительная информация, необходимая для правильной нейтрализации должна быть извлечена слева и справа по контексту от ошибочного символа. Рассмотрим подкласс восстановления на уровне фразы методов, как первый в хронологии[38].
