23) Языки и среды моделирования архитектуры предприятия. Языки моделирования предприятий. Idеf, dfd- технология, aris, bpml.

IDEF — методологии семейства ICAM (Integrated Computer-Aided Manufacturing) для решения задач моделирования сложных систем, позволяет отображать и анализировать модели деятельности широкого спектра сложных систем в различных разрезах. При этом широта и глубина обследования процессов в системе определяется самим разработчиком, что позволяет не перегружать создаваемую модель излишними данными.

IDEF — методологии создавались в рамках предложенной ВВС США программы компьютеризации промышленности — ICAM, в ходе реализации которой выявилась потребность в разработке методов анализа процессов взаимодействия в производственных (промышленных) системах. Принципиальным требованием при разработке рассматриваемого семейства методологий была возможность эффективного обмена информацией между всеми специалистами — участниками программы ICAM (отсюда название: Icam DEFinition — IDEF другой вариант — Integrated DEFinition). После опубликования стандарта он был успешно применен в самых различных областях бизнеса, показав себя эффективным средством анализа, конструирования и отображения бизнес-процессов. Более того, собственно с широким применением IDEF (и предшествующей методолoгии — SADT) и связано возникновение основных идей популярного ныне понятия — BPR (бизнес-процесс реинжиниринг).

В настоящий момент к семейству IDEF можно отнести следующие стандарты:

IDEF0

Пример диаграммы IDEF0: функциональная модель процесса "Поддержка запчастей, подлежащих починке".

Function Modeling — методология функционального моделирования. С помощью наглядного графического языка IDEF0 изучаемая система предстает перед разработчиками и аналитиками в виде набора взаимосвязанных функций (функциональных блоков — в терминах IDEF0). Как правило, моделирование средствами IDEF0 является первым этапом изучения любой системы. Методологию IDEF0 можно считать следующим этапом развития хорошо известного графического языка описания функциональных систем SADT (Structured Analysis and Design Technique);

IDEF1

Пример диаграммы IDEF1X.

Information Modeling — методология моделирования информационных потоков внутри системы, позволяющая отображать и анализировать их структуру и взаимосвязи. IDEF1X(IDEF1 Extended) — Data Modeling — методология моделирования баз данных на основе модели «сущность-связь». Применяется для построения информационной модели, которая представляет структуру информации, необходимой для поддержки функций производственной системы или среды. Метод IDEF1, разработанный Т. Рэмей (T. Ramey), также основан на подходе П. Чена и позволяет построить модель данных, эквивалентную реляционной модели в третьей нормальной форме. В настоящее время на основе совершенствования методологии IDEF1 создана ее новая версия — методология IDEF1X. IDEF1X разработана с учетом таких требований, как простота изучения и возможность автоматизации. IDEF1X–диаграммы используются рядом распространённых CASE–средств (в частности, ERwin, Design/IDEF).

IDEF2

Пример расширенной схемы перехода, модель IDEF3.

Simulation Model Design — методология динамического моделирования развития систем. В связи с весьма серьёзными сложностями анализа динамических систем от этого стандарта практически отказались, и его развитие приостановилось на самом начальном этапе. В настоящее время присутствуют алгоритмы и их компьютерные реализации, позволяющие превращать набор статических диаграмм IDEF0 в динамические модели, построенные на базе «раскрашенных сетей Петри» (CPN — Color Petri Nets);

IDEF3

Process Description Capture (Документирование технологических процессов) — методология документирования процессов, происходящих в системе (например, на предприятии), описываются сценарий и последовательность операций для каждого процесса. IDEF3 имеет прямую взаимосвязь с методологией IDEF0 — каждая функция (функциональный блок) может быть представлена в виде отдельного процесса средствами IDEF3;

IDEF4

Пример методологии проектированияIDEF4: диаграмма поведения для обьектов, реализующих метод «Громче».

Object-Oriented Design — методология построения объектно-ориентированных систем, позволяют отображать структуру объектов и заложенные принципы их взаимодействия, тем самым позволяя анализировать и оптимизировать сложные объектно-ориентированные системы. Подробнее - Технология;

IDEF5

Пример IDEF5-схемы состава шариковой ручки.

Ontology Description Capture — Стандарт онтологического исследования сложных систем. С помощью методологии IDEF5 онтология системы может быть описана при помощи определенного словаря терминов и правил, на основании которых могут быть сформированы достоверные утверждения о состоянии рассматриваемой системы в некоторый момент времени. На основе этих утверждений формируются выводы о дальнейшем развитии системы и производится её оптимизация;

IDEF6

Модель IDEF6 деятельностей проектирования IDEF4

Design Rationale Capture — Обоснование проектных действий. Назначение IDEF6 состоит в облегчении получения «знаний о способе» моделирования, их представления и использования при разработке систем управления предприятиями. Под «знаниями о способе» понимаются причины, обстоятельства, скрытые мотивы, которые обуславливают выбранные методы моделирования. Проще говоря, «знания о способе» интерпретируются как ответ на вопрос: «почему модель получилась такой, какой получилась?» Большинство методов моделирования фокусируются на собственно получаемых моделях, а не на процессе их создания. Метод IDEF6 акцентирует внимание именно на процессе создания модели;

IDEF7

Information System Auditing — Аудит информационных систем. Этот метод определён как востребованный, однако так и не был полностью разработан;

IDEF8

User Interface Modeling — Метод разработки интерфейсов взаимодействия оператора и системы (пользовательских интерфейсов). Современные среды разработки пользовательских интерфейсов в большей степени создают внешний вид интерфейса. IDEF8 фокусирует внимание разработчиков интерфейса на программировании желаемого взаимного поведения интерфейса и пользователя на трех уровнях: выполняемой операции (что это за операция); сценарии взаимодействия, определяемом специфической ролью пользователя (по какому сценарию она должна выполняться тем или иным пользователем); и, наконец, на деталях интерфейса (какие элементы управления, предлагает интерфейс для выполнения операции);

IDEF9

Типичные бизнесс-системы.

Scenario-Driven IS Design (Business Constraint Discovery method) — Метод исследования бизнес ограничений был разработан для облегчения обнаружения и анализа ограничений в условиях которых действует предприятие. Обычно, при построении моделей описанию ограничений, оказывающих влияние на протекание процессов на предприятии уделяется недостаточное внимание. Знания об основных ограничениях и характере их влияния, закладываемые в модели, в лучшем случае остаются неполными, несогласованными, распределенными нерационально, но часто их вовсе нет. Это не обязательно приводит к тому, что построенные модели нежизнеспособны, просто их реализация столкнется с непредвиденными трудностями, в результате чего их потенциал будет не реализован. Тем не менее в случаях, когда речь идет именно о совершенствовании структур или адаптации к предсказываемым изменениям, знания о существующих ограничениях имеют критическое значение;

IDEF10 — IDEF14

IDEF10 — Implementation Architecture Modeling — Моделирование архитектуры выполнения. Этот метод определён как востребованный, однако так и не был полностью разработан;

IDEF11 — Information Artifact Modeling. Этот метод определён как востребованный, однако так и не был полностью разработан;

IDEF12 — Organization Modeling — Организационное моделирование. Этот метод определён как востребованный, однако так и не был полностью разработан;

IDEF13 — Three Schema Mapping Design — Трёхсхемное проектирование преобразования данных. Этот метод определён как востребованный, однако так и не был полностью разработан;

IDEF14 — Network Design — Метод проектирования компьютерных сетей, основанный на анализе требований, специфических сетевых компонентов, существующих конфигураций сетей. Также он обеспечивает поддержку решений, связанных с рациональным управлением материальными ресурсами, что позволяет достичь существенной экономии.

DFD — общепринятое сокращение от англ. Data Flow Diagrams — диаграммы потоков данных. Так называется методология графического структурного анализа, описывающая внешние по отношению к системе источники и адресаты данных, логические функции, потоки данных и хранилища данных, к которым осуществляется доступ.

Диаграмма потоков данных (data flow diagram, DFD) — один из основных инструментов структурного анализа и проектирования информационных систем, существовавших до широкого распространения UML. Несмотря на имеющее место в современных условиях смещение акцентов от структурного к объектно-ориентированному подходу к анализу и проектированию систем, «старинные» структурные нотации по-прежнему широко и эффективно используются как в бизнес-анализе, так и в анализе информационных систем.

Исторически сложилось так, что для описания диаграмм DFD используются две нотации — Йодана (Yourdon) и Гейна-Сарсона (Gane-Sarson), отличающиеся синтаксисом. На приведенной ниже иллюстрации использована нотация Гейна-Сарсона.

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

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

Кроме того, нотация DFD поддерживает понятие подсистемы — структурной компоненты разрабатываемой системы.

Нотация DFD — удобное средство для формирования контекстной диаграммы, то есть диаграммы, показывающей разрабатываемую АИС в коммуникации с внешней средой. Это — диаграмма верхнего уровня в иерархии диаграмм DFD. Ее назначение — ограничить рамки системы, определить, где заканчивается разрабатываемая система и начинается среда. Другие нотации, часто используемые при формировании контекстной диаграммы — диаграмма SADT, диаграмма Диаграмма вариантов использования.

External Entity (Внешняя сущность) представляет собой материальный предмет или физическое лицо, представляющее собой источник или приемник информации, например, заказчики, персонал, поставщики, клиенты, склад. Определение некоторого объекта или системы в качестве внешней сущности указывает на то, что она находится за пределами границ анализируемой ИС. В процессе анализа некоторые внешние сущности могут быть перенесены внутрь диаграммы анализируемой ИС, если это необходимо, или, наоборот, часть процессов ИС может быть вынесена за пределы диаграммы и представлена как внешняя сущность. Внешняя сущность обозначается квадратом (рисунок 1), расположенным как бы "над" диаграммой и бросающим на нее тень, для того, чтобы можно было выделить этот символ среди других обозначений.

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

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

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

ARIS (акроним от англ. Architecture of Integrated Information Systems) — методология и тиражируемый программный продукт для моделирования бизнес-процессов организаций. Продукт и методология принадлежат немецкой компании Software AG как результат поглощения компании IDS Scheer автора методологии Августа-Вильгельма Шеера.

Любая организация в методологии ARIS рассматривается с четырёх точек зрения: организационной, функциональной, обрабатываемых данных и структуры бизнес-процессов. При этом каждая из этих точек зрения разделяется ещё на три подуровня: описание требований, описание спецификации, описание внедрения. Для описания бизнес-процессов предлагается использовать около 80 типов моделей, каждая из которых принадлежит тому или иному аспекту. ARIS предоставляет визуальный инструментарий для обеспечения наглядности моделей. Также инструментарий поставляется с набором референтных моделей, заранее разработанных для типичных процессов в различных отраслях.

Среди большого количества возможных методов описания можно выделить следующие:

eEPC (англ. extended event-driven process chain) — метод описания процессов;

ERM (англ. entity-relationship model) — модель «сущность-связь» для описания структуры данных;

UML (англ. unified modeling language) — объектно-ориентированный язык моделирования.

Кроме того, в ARIS предусмотрена возможность создания сценариев автоматизации составления различных аналитических отчётов, нормативных документов, новых моделей. Каждый сценарий представляет собой подпрограмму, запускаемую в ARIS Business Architect (либо Toolset - более ранней версии) или непосредственно на сервере ARIS. Сценарии пишутся на специальном языке программирования — SAX Basic. Для автоматизированного формирования того или иного отчёта в ARIS сценарии оперируют данными из базы моделей, вычленяя из неё конкретные объекты и модели.

Технология ARIS Script позволяет в автоматическом режиме производить:

Формирование нормативных документов на основании моделей ARIS (например, паспорт процесса, регламент процесса).

Формирование аналитических отчётов на основании моделей ARIS.

Интеграцию ARIS Toolset с другими приложениями и базами данных.

Формирование базы моделей ARIS на основании готовых спецификаций.

Продукт ARIS используется в проектах внедрения и эксплуатации ERP-систем, в частности, есть проработанное интеграционное решение для SAP R/3. Также программное обеспечение ARIS составляет основу пакета Business Process Analysis Suite корпорации Oracle.

BPM (англ. Business Process Management, управление бизнес-процессами) — концепция процессного управления организацией, рассматривающая бизнес-процессы как особые ресурсы предприятия, непрерывно адаптируемые к постоянным изменениям, и полагающаяся на такие принципы, как понятность и видимость бизнес-процессов в организации за счёт моделирования бизнес-процессов с использованием формальных нотаций, использования программного обеспечения моделирования, симуляции, мониторинга и анализа бизнес-процессов, возможность динамического перестроения моделей бизнес-процессов силами участников и средствами программных систем[1].

BPMS/BPMT (англ. Business Process Management System/Tool, система (инструмент) управления бизнес-процессами) — технологическое программное обеспечение для поддержки концепции BPM. Среди нотаций моделирования бизнес-процессов в различных решениях используются языки BPMN, EPC (англ. Event-driven Process Chain), IDEF0 и другие. Среди известных нотаций выполнения бизнес-процессов, применяемых в программных системах — BPEL и её диалекты, YAWL (англ.).

Критерии оценки решений

Аналитики Gartner выделяют как основные следующие критерии оценки BPM-решений:

поддержка задач «человек-человек» (англ. human workflow) и удобство интерфейса пользователя;

поддержка организационной структуры и ролевых групп;

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

возможность управления логикой процесса с рабочего места пользователя;

удобство использования и администрирования;

наличие графических средств разработки моделей бизнес-процесса;

поддержка общепринятых архитектур и стандартов;

производительность и масштабируемость;

способность обслуживать многочисленные, продолжительные и распределённые процессы;

понятный интерфейс настройки и возможность минимального участия ИТ-специалистов во внедрении и поддержке;

возможность информирования в реальном времени по отклонениям показателей процесса;

поддержка сервис-ориентированной архитектуры;

присутствие шаблонов бизнес-процессов, референтных моделей бизнес-процессов на основании которых могут быть разработаны новые процессы;

низкая совокупная стоимость владения.

Цели внедрения BPM

Концепция предполагает внедрение BPM-решения для достижения следующих целей:

Скорость — сокращение времени выполнения процессов за счёт регламентации и автоматизации шагов процессов, введения временных ограничений для исполнения шагов процессов;

Качество — за счёт прозрачности бизнес-процессов для всех участников, регламентации и средств мониторинга обеспечивается соблюдение всех предусмотренных правил;

Управление на основе показателей — выполнение процессов может контролироваться через наборы процессных показателей которые отражают затраты на процесс, время выполнения и загрузку ресурсов, таким образом, облегчая анализ и оптимизацию процесса на основании реальных значений показателей;

Гибкость — возможность достижения организационной гибкости компании через привлечение участников процессов к моделированию и перестройке.