КОММУНИКАЦИЯ, ВИЗУАЛИЗАЦИЯ И ОНТОЛОГИЯ

...

КОММУНИКАЦИЯ, ВИЗУАЛИЗАЦИЯ И ОНТОЛОГИЯ

COMMUNICATION, VISUALIZATION AND ONTOLOGY

Рыков В.В. (Московский физико-технический институт)

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

1. Вербальная и графическая коммуникация. Треугольник успеха.

Современная предметная и знаковая деятельность людей очень сложна и зачастую в ней соучаствуют представители разных специальностей и даже мировоззрений (как сейчас говорят – людей с различными менталитетами). Существуют различные методологии и знаковые системы для координации и повышения эффективности коммуникации людей в самых различных процессах совместной трудовой деятельности. Однако до сих пор нельзя сказать, что они эффективны.
К сожалению, единственный пока реальный и универсальный инструмент общения людей в описанной выше ситуации это великий и могучий язык – в устной или письменной форме. Про письменную форму общения ИТ специалисты часто говорят, что оно проходит в рамках текстового процессора Word. Однако вербальной формы часто бывает недостаточно. Для более четкого понимания того, какой аспект этой сложной и многообразной проблемы имеется в виду, рассмотрим классический пример, когда люди часто безуспешно пытаются восстановить разрезанную на части плоскую бумажную фигуру, используя только словесную коммуникацию в качестве подсказки. В бизнес тренингах этот эксперимент играет роль изначального доказательства того, что самое важное для успеха проекта – говорить на одном языке [1, 2, 3, 4, 5]. И этот язык (вернее – здесь уже надо говорить – знаковая система или нотация) может и должен быть не только вербальным. Это видно не только из приведенного выше примера. Давно была осознана необходимость невербальных - графических или визуальных средств коммуникации.
Эта проблема (в сущности - эффективной передачи знаний) настолько важна, что в мире ИТ технологий ее включают в стандартную парадигму – треугольник успеха [6]. Действительно, три компоненты – нотация, инструмент и технология неразрывно связаны. Но «хорошая» нотация сама включает в себя три составляющие - она не только помогает выработке зачастую неочевидных решений, но и предоставляет приемлемую семантику, а затем и удобную форму для ее преобразования и последующего использования рабочим инструментом [6]. В процессе «войны нотаций» выжили очень удобные графические системы. Но все они обладают существенным недостатком – они понятны только специалистам. О нотации, понятной любому человеку пойдет ниже речь.

2. Графическая коммуникация и неподготовленные пользователи.

Далее для определенности будем говорить о разработке информационных систем (ИС) в процессе диалога, что не повлияет на общность рассуждений и выводов. Описание процессов функционирования ИС давно уже производится в некоторой нотации. Таковых существует большое количество: UML, IDEF, BMPL, BPEL и др. Количество нотаций исчисляется десятками. Все вышеперечисленные нотации могут быть восприняты разработчиками, бизнес-аналитиками, но далеко не всегда понятны заказчику. Наоборот, чаще всего заказчик, не понимая сложных схем представленных, например в ARIS, просто подписывается под ТЗ, особенно не вникая в их содержание. У него просто нет другого выхода, а понять сложные диаграммы не всегда возможно. Это непонимание между разработчиками и заказчиками порождает серьезные проблемы в процессе разработки практически любых изделий. Казалось бы, выходом из сложившейся ситуации могли быть стать курсы, на которых можно было обучить заказчика данным нотациям, но это практически вряд ли осуществимо, так как требует от заказчика времени и денег. Кроме того, на практике заказчик представляет из себя не одного человека, а группу лиц (десятки людей), каждый из которых является экспертом в своей предметной области [1].

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


3. Графическая нотация как способ моделирования и визуализации.

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

Процесс разработки информационных систем начинается с постановки задач, которые должна решать информационная система (Рис. 1). Задачи, в свою очередь, определяются заказчиком системы. Обычно основной задачей информационной системы является покрытие некоторого количества бизнес-процессов. Покрытие, то есть реализация некоторой последовательности действий, присущих данному бизнес-процессу, в информационной системе. Для того чтобы, во-первых, с достаточной степенью точности формализовать процесс его нужно описать. Описание можно проводить в словесной форме, но чаще это делают в графической форме, представляя бизнес процесс в виде диаграмм и графов. Часто графическое представление комбинируется со словесным (например, в продукте Rational Rose).


Рис. 1
Описание обычно проводят с привлечением Case-средств (Computer Aided Software Engineering), например, таких как ARIS, Casewise, Rational Rose. Для того чтобы сделать процесс разработки и интеграции программного обеспечения более прозрачным были разработаны стандарты, ставшие уже нарицательными, IDEF и UML. Процесс стандартизации продолжается и по сей день. В 2000 году был введен стандарт BPML (Business Process Modelling Language), в разработке которого приняли практически все ведущие софтверные компании, но стандарт несколько сдал свои позиции после того, как в 2002 году проект покинули IBM, Microsoft и BEA, предложив свой стандарт BPEL (Business Process Execution Language) [4].

Но, как уже говорилось, несмотря на наличие такого большого числа языков и приложений, обеспечивающих их программную реализацию, в коммуникации между заказчиком и разработчиком существует инструментальная брешь [4]. Данная проблема обсуждалась в статье «На пути к приемлемому определению сервиса» в журнале «Открытые системы» [3]:
«Для того чтобы определение сервиса стало успешным, необходима инструментальная поддержка автоматического распределения потока информации среди архитекторов, дизайнеров, разработчиков, эксплуатационников и, что важнее всего, клиентов»
«Надо сказать, предпринимались многочисленные попытки заполнить брешь между группами специалистов для выработки единого определения сервиса. Свидетельством их неудачи является то, что на первом месте по-прежнему остаются многословные документы Word.»

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



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

В такой ситуации естественной представляется идея отделения бизнес-логики от приложения и ее выноса на более высокий уровень. Данная идея приобретает популярность, хотя говорить о ее глобальном применении пока рано. Толчком к реализации данного концепта явился XML, который вошел в жизнь ИТ и является носителем громадного количества идей, в основном связанных со стандартизацией, созданием эффективной среды для обмена данными между приложениями и Web-сервисами. Стоит назвать только такие проекты как Semantic Web, XBRL, BPML, BizTalk. Всему этому положил начало XML.

4. ПОСТ нотация

В настоящее время для решения такого типа задач совместно с неподготовленным пользователем, единственной стороной, которая знает конкретную логику своего бизнес приложения, существует единственный графический язык - так называемая «ПОСТ-нотация» (ПОСТ = процесс-объект-связь-технология), стоящая обособленно от всех вышеперечисленных [1]. Ее отличие состоит в том, что она без труда может быть понята как разработчиком, так и заказчиком или пользователем. Простота обусловлена тем, что в основе этого языка лежат всего два базовых элемента: объекты и действия, интуитивно понятные любому. Использование данной нотации позволяет сделать коммуникацию заказчика и разработчика более эффективной.
Указанные особенности нагляднее всего рассмотреть опять же на примере простейшей бизнес проблемы, описываемой при помощи этой нотации. Предлагаемая ПОСТ модель графической коммуникации называется еще IPO (input-process-output) или нотация Беляева-Капустяна [1]. Эта нотация описывает бизнес-процесс как последовательность, состоящую из входных объектов, самого процесса и его выходных объектов. Такова довольно простая синтактика этой нотации. Объекты обозначаются прямоугольниками. Процессы – эллипсами. В середине пишется дополнительная информация о том, что собой представляет данный объект или процесс. Объекты и процессы соединены стрелками. Ясно, что выходные объекты одного процесса могут служить входными объектами другого процесса. Синтактика этой нотации имеет довольно естественные ограничения. Например, два эллипса (процесса) или два объекта не могут непосредственно соединяться друг с другом. Действительно, один процесс не может переходить в другой без промежуточных результатов. Два объекта неразличимы, если между ними нет процесса, хоть как-то меняющими их.
Проиллюстрировать эту нотацию (а заодно и серьезность проблемы) можно на простом примере процесса заварки чая при помощи пакетика. Тогда нотация IPO будет выглядеть так – два входных объекта – чашка с кипятком и пакетик чая (прямоугольники) соединяются с эллипсом, внутри которого надпись «заварка», который соединяется стрелкой с одним выходным объектом – прямоугольником с надписью «заваренный чай». В качестве упражнения можно попробовать представить этот «бизнес процесс» в графической IPO нотации и уяснить себе сложность процесса коммуникации при совместной работе без графического языка. Однако, только увидев IPO нотацию, даже неподготовленные пользователи сразу начинают выражать в этой графической форме свои соображения [1].

Теперь для наглядности можно дать схему в IPO нотации простейшей бизнес операции по отгрузке товара.
















Рис. 3




Как можно видеть из рисунка, эта нотация очень наглядна, проста в освоении и может описывать (моделировать) самые сложные бизнес процессы. Cразу видны преимущества, которые вытекают из простоты ее синтактики. Эти преимущества могут быть существенно усилены при реализованной возможности преобразования этой нотации в программные коды. Будучи преобразованной в программный код, такие схемы могли бы служить не только эффективным способом для понимания, но и стать компонентой разрабатываемой системы, что могло бы резко повысить эффективность IPO нотации [6].
Эта нотация проста и очень эффективна для коммуникации между проектировщиками в процессе предварительного построения модели. Действительно, в этой нотации синтаксически различимы только два типа знаков – объекты и процессы. Следовательно, автоматически преобразоваться они могут только в два соответствующих класса программных объектов. Надписи внутри неформальны и не позволяют преобразовать их в программный код. Поэтому для более серьезных задач применялись более сложные семиотические системы, позволяющие преобразование этой нотации в стандартную программно воспринимаемую форму [6].

5. Коммуникация и онтология


Однако, процесс, описанный в рассматриваемой нотации не только очень удобен для восприятия непрофессионалом. Для более эффективного использования он может и должен быть преобразован к программно воспринимаемому виду. Наиболее подходящим для этого является универсальный язык XML. Для этого здесь предложен способ, который позволяет преобразовать процессную схему сначала в онтологию, а затем доказать утверждение о том, что это всегда возможно. Полное доказательство невозможно привести здесь за недостатком места (полностью доказательство приведено в [2]), однако общая схема доказательства сводится к следующему.
Действительно, онтология в самом общем смысле этого слова представляет модель некоторой предметной области. Онтология - это объекты, их свойства и связи (отношения) между ними. Нетрудно видеть, что эта концепция хорошо совместима с ПОСТ (IPO) нотацией. Основными понятиями, использующимися в конкретных онтологических описаниях в стандартных редакторах (таком, как Protégé) являются классы, их слоты (свойства), подклассы и экземпляры классов. Классы представляют собой понятия предметной области. Например, если речь идет об онтологии туристического бизнеса, то классами могут быть «гостиница», «страна», «туристическое агентство».

Видно, что можно установить одно-однозначное соответствие между элементами процессной схемы в IPO нотации и онтологией. После того, как процессная схема преобразована в онтологию, эта онтология вводится в программу-редактор для описания онтологий - Protégé. Далее стандартными средствами редактора Protege эта онтология не только может быть визуализирована в стандартной форме, но и экспортирована в XML-представление.




6. Программна