Конспект лекций case cals. Конспект_САСТ-2. Конспект лекций по дисциплине case и cals технологии по направлению подготовки
 Скачать 3.53 Mb.
|
|
2.4.3. WorkFlow- и DocFlow-системы BPM-системы делятся на WorkFlow-системы и DocFlow-системы. Основным элементом WorkFlow-системы является поток работ. В WorkFlow-системе деятельность бизнес-системы можно представить в виде эле- ментов работы, перемещающихся по определённому маршруту между исполни- телями в соответствии с заданными правилами. При этом от одного исполнителя к другому передаётся точка управления. Данная парадигма легко представима в виде графа. Основным элементом DocFlow-системы является поток документов. В DocFlow-системе деятельность бизнес-системы можно представить в виде доку- ментов, перемещающихся между их редакторами по определённому маршруту в соответствии с заданными правилами. При этом от одного редактора к другому передаётся не точка управления, а «корзины» документов. В настоящее время WorkFlow- и DocFlow-системы представляют собой системы разных типов, однако постепенно системы документооборота по функ- циональности приближаются к WorkFlow-системам. При помощи DocFlow- систем можно моделировать многие виды бизнес-процессов, а посредством WorkFlow-систем — автоматизировать элементы документооборота. 2.4 .4. Перспектива бизнес-процесса Назовём перспективой бизнес-процесса точку зрения или слои/уровни рас- смотрения бизнес-процесса. Выделяют следующие перспективы: –– перспектива управления потоком (Control-Flow Perspective); –– перспектива данных (Data Perspective); –– перспектива ресурсов (Resource Perspective); –– перспектива операций (Operational Perspective). 51 Перспектива управления потоком представляет собой граф со множеством узлов, соединённых между собой переходами, по которым согласно некоторым правилам перемещается точка управления (указатель на активный узел процес- са). В узле, соответствующем некоторому шагу процесса, система даёт задание (работу) исполнителю (сотруднику или информационной системе) и ожидает от- вета (сообщения) о выполнении работы. После поступления сообщения о выпол- нении работы точка управления перемещается по переходу к следующему узлу процесса. При этом к узлу, соответствующему шагу процесса, может примыкать только один входящий и один исходящий переход. Маршрутный узел соответствует разветвлению или слиянию точек управ- ления, где система на основании некоторых правил выбирает следующий узел, в который будет передано управление. С маршрутными узлами обязательно связа- но более одного входящего или исходящего перехода. Перспектива данных представляет собой набор переменных и данных внешних информационных систем, которые используются при исполнении биз- нес-процесса. Переменные бизнес-процесса могут являться входящими и исходящими параметрами при взаимодействии системы с информационными системами предприятия. При помощи внутренних переменных происходит обмен информа- цией между шагами процесса и, как следствие, между внешними информацион- ными системами, а также выбор конкретного внутреннего перемещения точки управления между узлами по одному из возможных переходов. Выбор перехода осуществляется согласно правилам бизнес-логики процес- са, описанной в перспективе управления потоком. Перспектива ресурсов представляет собой список исполнителей, которые могут выполнять шаги бизнес-процесса. Исполнителями могут быть как сотруд- ники предприятия, так и информационные системы или специализированные устройства. 52 Перспектива операций представляет собой список элементарных действий, совершаемых исполнителями в рамках шага бизнес-процесса. 2.5 Методология IDEF моделирования Взаимная совокупность методик и моделей концептуального проектирова- ния разработана в США по программе Integrated Computer-Aided Manufacturing. В настоящее время имеются методики функционального, информационного и поведенческого моделирования и проектирования, в которые входят IDEF- модели, приведенные таблице. IDEF0 реализует методику функционального моделирования сложных систем. Наиболее известной реализацией IDEF0 является методология SADT (Structured Analysis and Design Technique), преложенная еще в 1973 г. Д. Россом и впоследствии ставшая основой стандарта IDEF0. Эта методика рекомендуется для начальных стадий проектирования сложных искусственных систем управле- ния, производства, бизнеса, включающих людей, оборудование, программное обеспечение. IDEF1X и IDEF1 реализуют методики инфологического проектирования баз данных. В IDEF1X имеется ясный графический язык для описания объектов и отношений в приложениях, так называемый язык диаграмм "сущность-связь" (ERD - Entity-Relations Diagrams). Стандарт IDEF1 был разработан как инстру- мент для анализа и изучения взаимосвязей между информационными потоками анализируемой системы. Целью подобного исследования является структуриза- ция и дополнение существующей информации, обеспечение качественного управления информационными потоками. Применение методологии IDEF1 позволяет решить следующие задачи: –– выяснить структуру и содержание существующих потоков информации в системе; –– выявить проблемы, вызванные недостатком управления соответствую- щими потоками информации; 53 –– выявить информационные потоки, требующие дополнительного управ- ления для эффективной реализации модели. IDEF1 является аналитическим методом и используется преимущественно для выполнения следующих действий: –– определение информации, имеющей отношение к деятельности систе- мы, а также структуры её потоков; –– определение существующих правил и законов, по которым осуществля- ется движение информационных потоков, а также принципов управления ими; –– выяснение взаимосвязей между существующими информационными потоками в рамках системы; –– выявление проблем, возникающих при некачественном информацион- ном управлении. IDEF1X является методом для разработки реляционных баз данных. Ис- пользование метода IDEF1X наиболее целесообразно для построения логической структуры базы данных после исследования другими методами информацион- ных ресурсов системы и принятия решения о внедрении реляционной базы дан- ных, как части корпоративной информационной системы. Основным преимуще- ством IDEF1X, по сравнению с другими методами разработки реляционных баз данных, является жёсткая и строгая стандартизация моделирования, которая по- зволяет избежать различной трактовки построенной модели. Разработка информационной модели по IDEF1X выполняется в несколько этапов: выясняются цели проекта, составляется план сбора информации, при этом обычно исходные положения для информационной модели следуют из IDEF0-модели; выявляются и определяются основные сущности - элементы базы данных, в которых будут храниться данные системы; выявляются и определяются основные отношения, результаты представ- ляются графически в виде так называемых ER-диаграмм; 54 детализируются нестандартные отношения, определяются ключевые атри- буты сущностей. Детализация отношений заключается в замене связей "многие ко многим" на связи "многие к одному" и "один ко многим"; определяются атрибуты сущностей. Таблица 2.1 IDEF-модели Название Назначение IDEFO Функциональное моделирование Function Modeling Method IDEF1 и IDEF1X Информационное моделирование Information and Data Modeling Method IDEF2 Поведенческое моделирование Simulation Modeling Method IDEF3 Моделирование деятельности Process Flow and Object Stale Description Capture Method IDEF4 Объективно-ориентированное проектирование Object-oriented Design Method IDEF5 Систематизация объектов приложения Ontology Description Capture Method IDEF6 Использование рационального опыта проектирования Design Rational Capture Method IDEF8 Взаимодействие человека и системы Human-System Interaction Design IDEF9 Учет условий и ограничений Business Constraint Discovery 55 Название Назначение IDEF14 Моделирование вычислительных сетей Network Design Методологии IDEF2 и IDEF3 [4] реализуют поведенческое моделирование системы. Если методика IDEF0 связана с функциональными аспектами и позво- ляет отвечать на вопрос: «Что делает эта система?», то в этих методиках детали- зируется ответ на вопрос: «Как система это делает?». В основе поведенческого моделирования лежат модели и методы имитационного моделирования систем массового обслуживания, сети Петри, возможно применение модели конечного автомата, описывающей поведение системы как последовательности смен со- стояний. Методология IDEF3 разработана в конце 1980-х гг. для моделирования по- следовательности действий и процессов анализируемой системы. На данный момент методология IDEF3 является стандартом документирования процессов, происходящих в системе. Основой методологии служит сценарий процесса, выделяющий из модели последовательность происходящих в системе действий. Диаграммы IDEF3 по- зволяют моделировать сценарии происходящих в системе процессов, исследо- вать связи между действиями процессов, описывать последовательности измене- ний свойств объекта в рамках рассматриваемого процесса. Средства моделирования и документирования IDEF3 позволяют выполнять следующие задачи: –– документировать имеющиеся данные о технологии процесса; –– определять и анализировать точки влияния потоков сопутствующего документооборота на сценарий технологических процессов; –– определять ситуации, в которых требуется принятие решения, влияю- щего на жизненный цикл процесса; –– содействовать принятию оптимальных решений при реорганизации технологических процессов; 56 –– разрабатывать имитационные модели технологических процессов. Перечисленные методики относятся к так называемым структурным мето- дам. IDEF4 реализует объектно-ориентированный анализ больших систем. Он предоставляет пользователю графический язык для изображения классов, диа- грамм наследования, таксономии методов. IDEF5 направлена на представление онтологической информации прило- жения в удобном для пользователя виде, для этого используются символические обозначения (дескрипторы) объектов, их ассоциаций, ситуаций и схемный язык описания отношений классификации, "часть-целое", перехода и т. п. В методике имеются правила связывания объектов (термов) в предложения и аксиомы ин- терпретации термов. Как схематический язык, IDEF5 ближе всего к IDEF1 и IDEF1X. Информа- ция, отражающаяся в модели IDEF1 или IDEF1X, может быть выражена в IDEF5. IDEF6 используется для описания и обоснования дизайна разрабатываемой информационной системы, а также для отображения связи проектных решений по разработке моделей и системы документации. Преимуществом данной мето- дологии является то, что она помогает организации избежать повторения ошибок проектирования, определяя влияние вносимых в дизайн системы изменений. В отличие от других методик IDEF, в которых фиксируются результаты проектирования, в IDEF6 главный упор сделан на пути получения этих результа- тов и обосновании промежуточных решений. Такой подход особенно важен при разработке сложных систем в недостаточно определённых ситуациях. Фиксация шагов и обоснований помогает при дальнейших модернизациях систем, сохра- нению и использованию рационального опыта проектирования. Методика упо- рядочивает обнаружение и устранение неопределённостей, ошибок, неудовле- творительных ограничений. IDEF8 предназначен для проектирования диалогов человека и технической системы. Создаваемые сценарии должны удовлетворять ряду оговорённых в ме- тодике принципов, таких как уменьшение нагрузки на человека, идентичность 57 средств диалога в разных системах, наличие обратной связи для исправления ошибок, хранение истории диалога, помощь советами по выполнению действий и т.д. Методология IDEF9 [7] предназначена для анализа имеющихся условий и ограничений (в том числе физических, юридических, политических) и их влия- ния на принимаемые решения в процессе реинжиниринга. Данная методика при- звана помочь в обнаружении и анализе проблем, возникающих в бизнес- системах. Выявление ограничений в бизнес-системе и их систематический ана- лиз позволяют улучшить функционирование системы. Обычно в качестве систем фигурируют сложные информационные систе- мы с ориентацией на экономические и управленческие приложения. Под ограни- чением понимается отношение, которое должно соблюдаться. Ограничения де- лятся на контексты (группы родственных ограничений). Применение IDEF9 заключается в выполнении нескольких шагов: 1) сбор свидетельств (фактов, указывающих на наличие ограничения); 2) классификация — определение контекстов, объектов, отношений; 3) прогнозирование — выявление ограничений на основе свидетельств; 4) отбор значимых ограничений; 5) определение экспертов для тестирования результатов; 6) детализация и фильтрация ограничений. В методике даны рекомендации по выполнению этих шагов. Предлагается графический язык, элементами которого являются система, блоки ограничений, контексты, линии связи, логические связки OR, AND, XOR (исключающее ИЛИ). IDEF14 предназначен для представления и анализа данных при проектиро- вании вычислительных сетей на графическом языке с описанием конфигураций, очередей, сетевых компонентов, требований к надежности и т.п. Чаще всего методика применяется для модернизации уже существующих сетей. Проектирование включает в себя определение топологии сети или схемы коммуникаций, реализацию нужного качества обслуживания, анализ функцио- 58 нирования (трафик, дисциплины обслуживания в узлах, протоколы доступа). Модель топологии дополняется моделями очередей, надёжности, материальных затрат. Важную роль играет библиотека методов построения и компонентов се- тей. Методика основана на выполнении ряда шагов: установлениецелей модер- низации, исследование существующей сети, определение типов компонентов в ней, построение модели «как есть», её верификация, анализ результатов, коррек- тировка с переходом к модели «как должно быть». Для моделирования адекватного представления сложной системы, харак- теризуемой структурой, выполняемыми процессами (функциями), поведением системы во времени применяют функциональные, информационные и поведен- ческие модели, пересекающиеся друг с другом. Функциональная модель системы описывает совокупность выполняемых системой функций, характеризует морфологию системы (ее построение) - состав подсистем, их взаимосвязи. Информационная модель отображает отношения между элементами сис- темы в виде структур данных (состав и взаимосвязи). Поведенческая (событийная) модель описывает информационные процес- сы (динамику функционирования), в ней функционируют такие категории, как состояние системы, событие, переход из одного состояния в другое, условия пе- рехода, последовательность событий. Используется в основном для систем ре- ального времени. 2.6 Нотации DFD моделирования Диаграммы потоков данных (Data Flow Diagramming, DFD) представляют собой иерархию процессов, которые связаны между собой потоками данных. Диаграммы показывают, как обрабатывает информацию каждый процесс, как процессы связаны друг с другом, а также как работает сама система, каким обра- зом она обрабатывает поступающие данные. В основе классической DFD-технологии лежат три группы средств моде- лирования: 59 • диаграммы, иллюстрирующие функции, которые система должна выпол- нять, и связи между этими функциями - для этой цели используются собственно диаграммы потоков данных DFD (Data Flow Diagrams), дополненные словарями данных и спецификациями процессов нижнего уровня; • диаграммы, моделирующие данные и их взаимосвязи, - для этой цели ис- пользуются диаграммы «сущность-связь» ERD (Entity-Relationship Diagrams); • диаграммы, моделирующие поведение системы, - для этой цели исполь- зуются диаграммы переходов состояний STD (State Transition Diagrams). Все эти диаграммы содержат графические и текстовые средства моделиро- вания: первые - для удобства демонстрирования основных компонентов модели, вторые - для обеспечения точного определения ее компонентов и связей. 2.7. UML Унифицированный язык моделирования (Unified Modeling Language, UML) представляет собой общецелевой язык визуального моделирования, который разработан для спецификации, визуализации, проектирования и документирова- ния компонентов программного обеспечения, бизнес-процессов и других систем. Язык UML является результатом совместной работы Г. Буча (G. Booch), Д. Рамбо (J. Rumbaugh), И. Якобсона (I. Jacobson) и др. Г. Буч разработал нотацию графических символов для описания различных аспектов модели, Д. Рамбо — нотацию технологии объектного моделирования (Object Mod26 Глава 2. Поколе- ния средств моделирования бизнес-процессов eling Technology, OMT). И. Якоб- сон — впервые описал процесс выявления и фиксации требований к системе в виде совокупностей транзакций, а также разработал метод проектирования сис- тем под названием «Объектно-ориентированное проектирование программного обеспечения» (Object Oriented Software Engineering, OOSE). Процесс консолидации методов, впоследствии вошедших в UML, начался в 1993 г. В октябре 1995 г. была выпущена предварительная версия 0.8 унифи- цированного метода (Unified Method). Затем консорциум OMG (Object Management Group), образованный ещё в 1989, выпустил в 1996 г. предваритель- 60 ную версию спецификации UML. К разработке новых версий языка в рамках консорциума UML Partners присоединились такие компании, как Digital Equipment Corporation, Hewlett-Packard, i-Logix, IntelliCorp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle Corporation, Rational Software, Texas Instruments и Unisys. Результатом их совместной работы стала специфика- ция UML 1.0, вышедшая в январе 1997 года. Последующие релизы UML вклю- чали версии 1.3, 1.4 и 1.5, опубликованные, соответственно, в июне 1999 г., сен- тябре 2001 г. и марте 2003 г. Формальная спецификация последней версии UML 2.0 опубликована в августе 2005 г. Семантика языка была значительно уточнена и расширена для поддержки методологии Model Driven Development (MDD). UML 1.4.2 принят в качестве международного стандарта ISO/IEC 19501:2005 [8]. UML содержит в себе механизмы расширения, предназначенные для адап- тации определённого языка моделирования к конкретным требованиям разра- ботчика без необходимости изменения метамодели. Наличие механизмов расши- рения принципиально отличает UML от таких средств моделирования, как IDEF0, IDEF1X, IDEF3, DFD, которые сильно типизированы, т.к. не допускают произвольной интерпретации семантики элементов моделей. UML, допуская та- кую интерпретацию, является слабо типизированным языком. Язык UML используется также в методе моделирования бизнес-процессов, являющемся частью технологии Rational Unified Process (RUP) компа 2.6. BPMN, BPEL, BPML 27 нии IBM Rational Software. Этот метод, направленный прежде всего на создание основы для формирования требований к программному обес- печению, предусматривает построение двух базовых моделей: модели бизнес- процессов (Business Use Case Model) и модели бизнес-анализа (Business Analysis Model). 61 2.8. BPMN, BPEL, BPML Business Process Modeling Notation (BPMN) представляет собой графиче- скую нотацию для отображения бизнес-процессов при моделировании потоков работ, происходящих в исследуемой системе. Нотация BPMN была разработана организацией Business Process Management Initiative (BPMI), в настоящее время разработка BPMN ведётся кон- сорциумом OMG (Object Management Group). Выходу первой версии BPMN в 2003–2004 гг. предшествовало появление в 2000 г. книги о системах управления бизнес-процессами (Business Process Management Systems, BPMS), первой версии BPMS в 2001 г., спецификации BPML 1.0 в 2002 г. В 2005 г. стандарт был пере- дан OMG, и в 2006 г. вышла спецификация BPMN 1.0 от OMG [9]. В 2007 г. OMG выпустила спецификацию BPMN 2.0 [10]. Целью проекта BPMN является создание общей нотации разработки моделей бизнес-процессов для различных категорий специалистов: от аналитиков и экспертов, модели- рующих бизнес-процессы, технических разработчиков, которые создают систе- мы для выполнения этих процессов, до менеджеров различных уровней, которые должны понимать процессные диаграммы, чтобы принимать деловые решения. Благодаря абстрактному представлению модели нотация BPMN позволяет наглядным образом описывать модели бизнес-процессов независимо от среды их функционирования. Для реализации нотации модели используются языки ис- полнения бизнес-процессов — BPML (Business Process Modeling Language) и BPEL (Business Process Execution Language). Язык определения бизнес-процессов BPML, основанный на технологии Web-сервисов, разработан коалицией BPMI в 2002 г. В настоящее время есть возможность экспорта из графической нотации BPMN как в BPML, так и в BPEL. Язык BPEL (или BPEL4WS) был разработан группой ИТ-компаний, где ведущую роль в разработке языка сыграли IBM и Microsoft. BPEL фактически стал прямым наследником ранее созданных спецификаций IBM WSFL и 62 Microsoft XLANG. В нём используются сразу несколько XML-спецификаций — WSDL, XML Schema, XPath. В марте 2003 г. BPEL был утверждён в качестве стандарта организацией по продвижению стандартов в области структурированной информации (Organization for the Advancement of Structured Information Standards, OASIS). Весной 2004 г. появилась версия BPEL 1.1. Эта спецификация была впер- вые реализована в продуктах IBM WebSphere Business Integration Server Foundation 5.1 и Microsoft BizTalk Server 2004. Кроме того, поддержка BPEL обеспечивается в ряде ведущих платформ исполнения приложений и сервисов (например, SAP NetWeaver и BEA WebLogic). BPEL представляет собой метаязык на базе XML, позволяющий опреде- лить последовательность выполнения функционала Web-сервисов в ходе раз- личных потоков операций (транзакций). |