| |||
|
Коммуникация в кибернетике и в искусстве ... Конспект доклада, сделанного на Григорьевских чтениях 13-14 марта 2008 г в Доме Искусства на Пречистенке 21 ... Коммуникация в кибернетике и в искусстве ... Доклад, сделанный на конференции MEDIAS 2008 Кипр май 2008 г ... Коммуникация, визуализация и онтология ... Доклад, сделанный на конференции МФТИ в 2008 году Горбиков С.И., Рыков В.В. Коммуникация, визуализация и онтология 1 Вербальная и графическая коммуникация – постановка проблемы Современная предметная и знаковая деятельность людей очень сложна и зачастую в ней соучаствуют представители разных специальностей и даже мировоззрений (как сейчас говорят – людей с различными менталитетами). Существуют различные методологии и знаковые системы для координации и повышения эффективности коммуникации людей в самых различных процессах совместной трудовой деятельности. Однако до сих пор нельзя сказать, что они эффективны. К сожалению, единственный пока реальный и универсальный инструмент общения людей в описанной выше ситуации это великий и могучий язык – в устной или письменной форме. Про письменную форму общения часто говорят, что оно проходит в рамках текстового процессора Word. Этого часто бывает недостаточно. Для более четкого понимания того, какой аспект этой сложной и многообразной проблемы имеется в виду, рассмотрим классический пример, когда люди часто безуспешно пытаются восстановить разрезанную на части плоскую бумажную фигуру, используя только словесную коммуникацию в качестве подсказки. В бизнес тренингах этот эксперимент играет роль изначального доказательства того, что самое важное для успеха проекта – говорить на одном языке [1, 2,3,4,5 ]. И этот язык (вернее – здесь уже надо говорить – знаковая система) может и должен быть не только вербальным. Это видно не только из приведенного выше примера. Давно была осознана необходимость нетекстовых - графических или визуальных средств коммуникации. 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 [4] (Business Process Execution Language). Но, несмотря на наличие такого большого числа языков и приложений, обеспечивающих их программную реализацию, в коммуникации между заказчиком и разработчиком существует инструментальная брешь [3]. Все вышеперечисленные нотации могут быть восприняты разработчиками, бизнес-аналитиками, но далеко не всегда понятны заказчику. Наоборот, чаще всего заказчик, не понимая сложных схем представленных, например в ARIS, просто подписывается под ТЗ, особенно не вникая в его содержание, так как у него просто нет другого выхода, а понять сложные диаграммы невозможно. Казалось бы, решением из сложившейся ситуации могли быть стать курсы, на которых можно было обучить заказчика данным нотациям, но это практически вряд ли осуществимо, так как требует от заказчика времени и денег. Кроме того, на практике заказчик представляет из себя не одного человека, а группу лиц (десятки людей), каждый из которых является экспертом в своей предметной области. Данная проблема обсуждалась в статье «На пути к приемлемому определению сервиса» в журнале «Открытые системы» [3]: «Для того чтобы определение сервиса стало успешным, необходима инструментальная поддержка автоматического распределения потока информации среди архитекторов, дизайнеров, разработчиков, эксплуатационников и, что важнее всего, клиентов» «Надо сказать, предпринимались многочисленные попытки заполнить брешь между группами специалистов для выработки единого определения сервиса. Свидетельством их неудачи является то, что на первом месте по-прежнему остаются многословные документы Word.» На основании описанных бизнес-процессов ведется разработка программных продуктов. Пользователи работают с формами (Рис. 2). Формы – это конечный пользовательский интерфейс, где пользователи вводят, выводят, анализируют и изменяют информацию. На этом уровне осуществляется «контакт» бизнес-пользователя предприятия с информационной системой. Бизнес-пользователь – это пользователь информационной системы, который использует ее для целей управлением бизнесом и который не имеет глубоких ИТ-знаний. Например, бизнес-пользователем может быть кладовщик, начальник цеха или генеральный директор. Рис. 2 Что является важным в таком типе устройства информационной системы, это то что бизнес-логика осуществляется полностью приложением. Она как бы вшита в него. Любые изменения бизнеса, а модернизация информационной системы в большинстве случаев связана именно с этим (появлением нового продукта, переход к новому способу расчета себестоимости или учета затрат на капитальный ремонт и т.д.), приводят к изменению требований к системе. Модернизация приложения крайне трудоемкий процесс, требующий сотен часов работы программиста, а если речь идет о разработке нового модуля, то и тысяч. В такой ситуации естественной представляется идея отделения бизнес-логики от приложения и ее выноса на более высокий уровень. Данная идея приобретает популярность, хотя говорить о ее глобальном применении пока рано. Толчком к реализации данного концепта явился XML, который вошел в жизнь ИТ и является носителем громадного количества идей, в основном связанных со стандартизацией, созданием эффективной среды для обмена данными между приложениями и Web-сервисами. Стоит назвать только такие проекты как Semantic Web, XBRL, BPML, BizTalk. Всему этому положил начало XML. 4. IPO нотация В настоящее время для решения такого типа задач совместно с неподготовленным пользователем, единственной стороной, которая знает конкретную логику своего бизнес приложения, существует единственный графический язык - так называемая «пост-нотация», стоящая обособленно от всех вышеперечисленных [1]. Ее отличие состоит в том, что она без труда может быть понята как разработчиком, так и заказчиком. Простота обусловлена тем, что в основе этого языка лежат всего два базовых элемента: объекты и действия, интуитивно понятные любому. Использование данной нотации позволяет сделать коммуникацию заказчика и разработчика более эффективной. Указанные особенности нагляднее всего рассмотреть опять же на примере простейшей бизнес проблемы, описываемой при помощи этой нотации. Предлагаемая модель графической коммуникации называется IPO (input-process-output) нотация Беляева-Капустяна [1]. Эта нотация описывает бизнес-процесс как последовательность, состоящую из входных объектов, самого процесса и его выходных объектов. Такова довольно простая синтактика этой нотации. Объекты обозначаются прямоугольниками. Процессы – эллипсами. В середине пишется дополнительная информация о том, что собой представляет данный объект или процесс. Объекты и процессы соединены стрелками. Ясно, что выходные объекты одного процесса могут служить входными объектами другого процесса. Синтактика этой нотации имеет довольно естественные ограничения. Например, два эллипса (процесса) или два объекта не могут непосредственно соединяться друг с другом. Действительно, один процесс не может переходить в другой без промежуточных результатов. Два объекта неразличимы, если между ними нет процесса, хоть как-то меняющими их. Проиллюстрировать эту нотацию можно на простом примере процесса заварки чая при помощи пакетика. Тогда нотация IPO будет выглядеть так – два входных объекта – кипяток и пакетик чая (прямоугольники) соединяются с эллипсом, внутри которого надпись «заварка», который соединяется стрелкой с одним выходным объектом – прямоугольником с надписью «заваренный чай». В качестве упражнения можно попробовать представить этот «бизнес процесс» в графической IPO нотации. Неподготовленные пользователи сразу начинали выражать в графической форме свои соображения, только увидев такую картинку. Для наглядности можно дать схему в IPO нотации простейшей бизнес операции по отгрузке товара. Рис. 4 Как можно видеть из описания, эта нотация очень наглядна, проста в освоении и может описывать (моделировать) самые сложные бизнес процессы. Однако сразу видны ограничения, которые вытекают из простоты ее синтактики. Эти ограничения касаются возможного преобразования этой нотации в программные коды, что могло бы резко повысить ее эффективность. Действительно, в этой нотации синтаксически различимы только два типа знаков – объекты и процессы. Следовательно, автоматически преобразоваться они могут только в два соответствующих класса программных объектов. Надписи внутри неформальны и не позволяют преобразовать их в программный код. Эта нотация проста и очень эффективна для коммуникации между проектировщиками в процессе предварительного построения модели. Однако, для более серьезных задач нужны более сложные семиотические системы – или преобразование этой нотации в стандартную программно воспринимаемую форму. 5. Коммуникация и онтология Процесс, описанный в рассматриваемой нотации может и должен быть преобразован к программно воспринимаемому виду. Наиболее подходящим для этого является универсальный язык XML. Для этого был предложен способ, который позволяет преобразовать процессную схему сначала в онтологию, и доказать утверждение о том, что это всегда возможно. Полное доказательство невозможно привести здесь за недостатком места (полностью доказательство приведено в [2]), однако общая схема доказательства сводится к следующему. Действительно, онтология в самом общем смысле этого слова представляет модель некоторой предметной области. Онтология это объекты, их свойства и связи (отношения) между ними. Основными понятиями, использующимися в конкретных онтологических описаниях, в стандартных редакторах (таком как Protégé) являются классы, их слоты (свойства), подклассы и экземпляры классов. Классы представляют собой понятия предметной области. Например, если речь идет об онтологии туристического бизнеса, то классами могут быть «гостиница», «страна», «туристическое агентство». Видно, что можно установить одно-однозначное соответствие между элементами процессной схемы в IPO нотации и онтологией. После того, как процессная схема преобразована в онтологию, онтология вводится в программу, для описания онтологий, - Protégé Далее стандартными средствами редактора Protege онтология экспортируется в XML. 6. Программная реализация В заключительной части работы покажем кратко пример реализации преобразования финансового бизнес-процесса в онтологию и объединения полученной онтологии с онтологией одной из предметных областей предприятия. В качестве процесса был взят процесс получения займа, в качестве онтологии использовалась онтология для предоставления финансовой отчетности Extensible Business Reporting Language (XBRL). Получение долгосрочных займов: Процесс начинается с того, что бухгалтер по операциям с денежными средствами на основании даты получения займа и величины займа делает проводку Dr SecuredLongTerm Cr UnrestrictedCash, увеличивая значение баланса по долгосрочным займам и величину денежных средств. Получившийся на выходе превращения объект SecuredLongTerm является входящим для превращения Repayment of LT, которое обозначает частичное погашение величины полученного займа за счет возвращения части полученного займа. Следующее превращение Transformation to ST переводит долгосрочное обязательство в краткосрочное, когда срок погашения обязательства становится равным одному году. После истечения срока погашения обязательство гасится за счет денежных средств, что отображено превращением Repayment of ST Loan, использующим в качестве входящих объектов LoansPayableCurrent и дающий на выходе уменьшенное количество UnrestrictedCash* и. LoansPaya |
