Глава 5. Сравнительный анализ программных
Инструментариев и методологий описания функциональных и информационных моделей
Анализ современных программных инструментариев
Для создания ИС
Автоматизация деятельности любого предприятия предполагает обязательный изначальный анализ его деятельности системными аналитиками с последующим подключением проектировщиков, информационщиков, разработчиков и программистов. Современную технологию автоматизированного проектирования прикладных программных систем обеспечивают CASE-средства (Computer Aided System Engineering), которые поддерживают все этапы их жизненного цикла – от первоначального формирования исходных требований к будущей системе до генерации готового продукта и его сопровождения.
Более 30 лет интенсивно развиваются многообразные CASE-инструментарии различными фирмами – средства компьютерного анализа, проектирования, контроля за соблюдением соответствия тому, что было спроектировано и т.п. В целом они представляют собой мощный аппарат для создания ИС, который позволяет быстро, без ошибок, с небольшим количеством разработчиков проектировать и создавать сложные прикладные системы с автоматической выдачей документации на всех этапах жизненного цикла.
При этом CASE-системы используются не только как комплексные технологические конвейеры для производства ИС, но и как мощный инструмент решения исследовательских и проектных задач, связанных с начальными этапами разработки, таких как анализ предметной области, разработка проектных спецификаций, выпуск проектной документации, планирование и контроль разработок, управление ресурсами и т. д.
СASE-средства позволяют проектировщику с помощью простых средств визуального моделирования вводить сведения о предметной области в единственное хранилище (репозиторий) для всех участников проекта, а затем с помощью процедур автоматической генерации преобразовывать введенную в виде моделей информацию в таблицы базы данных и программные модули, готовые к выполнению на компьютере. Таким образом, средства визуального проектирования позволяют разработчикам создавать ИС, используя исключительно визуальные объекты, а затем автоматически генерировать программный код по этим построениям с помощью средств языков программирования четвертого поколения (4GL).
Используемые в CASE-средствах модели (функциональные, информационные, событийные и др.), представляют собой визуальную составляющую CASE-инструментов и являются общим языком для всех участников проекта. Если на каком-либо этапе необходимо внести изменение в проект, то достаточно внести изменение в соответствующие модели и затем в автоматическом режиме произвести перегенерацию системы.
В отличие от подобных интегрированных систем Down-CASE (Oracle, Sybase, Interbase, Informix, MS SQLServer) имеются более простые системы класса так называемых Upper-CASE, которые позволяют строить модели концептуального уровня, а программы приложений строятся затем с помощью других инструментов класса 4GL или средств быстрой разработки типа Delphi. Особенностью систем класса Upper-CASE является принципиальное решение об отказе их привязки к какой-либо конкретной СУБД и возможность совместного использования со многими СУБД и языками 4GL.
Таким образом, CASE-технология позволяет отделить проектирование системы от собственно программирования и отладки. Системные аналитики и проектировщики занимаются проектированием на более высоком уровне, не отвлекаясь на мелкие детали. Это дает возможность избежать множество ошибок на ранних стадиях проекта и получить более совершенные программные продукты. Ошибки, допущенные на ранних этапах анализа и проектирования и необнаруженные в процессе тестирования, выливаются в итоге в трудноразрешимые проблемы, которые способны привести к неудаче всего проекта.
Другим достоинством CASE-средств является их способность быстро строить прототип (или макет) ИС – упрощенную черновую версию системы, которая дает возможность заказчику увидеть приложение в действии, поэкспериментировать с ней и выдать разработчикам соответствующие коррективы.
Нередко применение CASE-средств выходит за рамки проектирования и разработки ИС. CASE-технология дает возможность оптимизировать модели организационных и управленческих структур предприятий, позволяет более эффективно решать задачи планирования, финансирования и управления производством.
И кроме этого, CASE-средства обеспечивают правильное ведение работ коллективом разработчиков, обеспечивает коммуникацию участников проекта на всех этапах и с разных позиций (как между командами заказчика и разработчика, так и внутри рабочей группы).
Единый пользовательский интерфейс позволяет сказать, что CASE-инструментарий – это программные средства коллективного пользования для совместной реализации проекта. Коллективная работа команды разработчиков в сетевой среде предполагает обмен информации, контроль выполнения задач, отладку изменений и версий, планирование, взаимодействие и управление.
В этом плане CASE-технологии аналогичны CALS-технологиям, если изделием считать саму информационную систему: разработка ведется в соответствии с этапами ЖЦ в едином информационном пространстве (репозитарии), в котором информация представлена в электронном виде и к которой имеют доступ все участники ЖЦ изделия (ИС).
К настоящему моменту наиболее интенсивное развитие получили два главных направления применения CASE-средств: BPR (business process reengineering), системный анализ и проектирование.
BPR или перепроектирование бизнес-процессов позволяет представить бизнес-процесс как некоторую деятельность, получающую входные данные и выдающую результат, имеющий ценность для клиента.
Системный анализ и проектирование включает функциональное, информационное и событийное моделирование как вновь создаваемой, так и существующей системы.
Такое разбиение является весьма условным, поскольку при анализе деятельности предприятия и разработке проекта его автоматизации используются элементы BPR (более того, теоретически BPR должно быть первым этапом разработки), в то же время необходимым этапом проектирования является, по крайней мере, создание функциональной модели бизнес-процесса.
Всегда следует иметь в виду, что CASE-средства становятся весьма эффективными только при их комплексном применении на всех этапах жизненного цикла. Поэтому производители CASE-средств стремятся к тому, чтобы их программный инструментарий имел средства разработки и сопровождения проекта одинаково эффективный на всех стадиях разработки проекта.
Применение CASE-технологии для разработки системы комплексной автоматизации предприятия предполагает выполнение комплексного анализа, который требует использования множества разных типов моделей, отображающих разные стороны деятельности системы. При этом для обеспечения целостности процесса моделирования и анализа необходимо иметь возможность интеграции результатов моделирования в рамках общего проекта или одной модели.
Поэтому от выбора инструментальных средств моделирования существенно зависят объем и сроки выполнения, глубина и качество анализа при создании системы. Хотя формальный перечень работ, который необходимо выполнить на начальных этапах анализа системы, практически не зависит от того, какие методологии и инструменты будут использованы для моделирования и анализа. От выбора программного инструментария зависит только результат.
В процессе разработки ИС обычно выполняются три уровня анализа, каждый из которых соответствует трем этапам жизненного цикла: определение требований, формирование спецификаций и внедрение [35].
Определение требований начинается со сбора информации о предметной области, которая после предварительного экспресс-анализа отображается в виде моделей текущего состояния объекта проектирования (модели «AS IS»). Анализ этих моделей позволяет изучить особенности функционирования объекта, выявить имеющиеся узкие места, определить недостатки в организации процессов, структур и т.п.
Следующим шагом на этом этапе является создание концептуальных моделей будущей ИС (модели «TO BE»).
Результатом первого уровня анализа обычно становится техническое задание на разработку ИС.
Формирование спецификаций сопровождается выпуском технического проекта ИС, составной частью которого являются модели. На этом шаге принимаются во внимание ограничения, которые необходимо учитывать в моделях.
Третий уровень анализа – внедрение – связан с конкретной реализацией проекта ИС на предприятии.
При выполнении работ по моделированию на каждом из трех представленных выше уровней могут быть использованы различные инструментальные средства. Однако решающее значение при выборе инструмента моделирования имеет класс, к которому относится проектируемая ИС [34].
Специфика решаемых с помощью ИС задач, различная сложность их создания, модификации, сопровождения, интеграции с другими ИС позволяют разделить информационные системы на следующие классы:
- малые информационные системы;
- средние информационные системы;
· крупные информационные системы (корпоративные информационные системы – системы уровня федеральных организаций).
К классу малых информационных систем относятся системы уровня небольшого предприятия. К основным признакам таких систем следует отнести:
- непродолжительный жизненный цикл;
- ориентацию на массовое использование;
- невысокую цену;
· практическое отсутствие средств аналитической обработки данных;
· отсутствие возможности незначительной модификации без участия разработчиков;
· использование в основном настольных СУБД (Clarion, FoxPro, Clipper, Paradox, Access и др.);
· однородность аппаратного и системного программного обеспечения (широкое использование в качестве аппаратного обеспечения недорогих персональных компьютеров);
· практическое отсутствие средств обеспечения безопасности.
В отличие от предыдущего класса, признаками средних информационных систем являются:
· длительный жизненный цикл (возможность роста до крупных систем);
- наличие аналитической обработки данных;
· наличие штата сотрудников, осуществляющих функции администрирования аппаратных и программных средств;
- наличие средств обеспечения безопасности;
· тесное взаимодействие с фирмами-разработчиками программного обеспечения по вопросам сопровождения компонентов ИС.
И наконец, к характерным признакам корпоративных информационных систем следует отнести:
- длительный жизненный цикл;
- миграцию унаследованных систем;
· разнообразие используемого аппаратного обеспечения, жизненный цикл которого меньше, чем у создаваемой системы;
- разнообразие используемого программного обеспечения;
- масштабность и сложность решаемых задач;
- пересечение множества различных предметных областей;
- ориентацию на аналитическую обработку данных;
· территориальную распределенность, что особенно характерно для России.
В зависимости от класса создаваемой ИС выбираются соответствующие программные инструментарии, которые могут быть отнесены к следующим четырем категориям: локальные, малые, средние и крупные интегрированные средства моделирования.
Локальные инструментальные средства поддерживают не более двух типов моделей и методов (Design/IDEF, ProCap, S-Disignor, CASE.Аналитик). Например, в Design/IDEF реализованы две методологии: IDEF0 (функциональные иерархические модели) и IDEF1Х (информационная модель в виде ER-диаграммы). При разработке ИС локальные средства моделирования используются в основном на концептуальном уровне для предварительного анализа или как средство графического описания предметной области для обсуждения с заказчиком содержания будущего проекта. Они могут быть использованы при разработке малых ИС.
Малые интегрированные средства моделирования поддерживают несколько типов моделей и методов (BPwin, ERwin). Например, BPwin позволяет строить организационные диаграммы, диаграммы плавательных дорожек, интегрированные функциональные модели на основе методологий IDEF0, IDEF3 и DFD. В BPwin имеется возможность для любого процесса указать стоимость, время и частоту его выполнения. Эти характеристики в дальнейшем могут быть просуммированы с целью вычисления общей стоимости затрат – таким образом выявляются узкие места технологических цепочек, определяются затратные центры.
В настоящее время BPwin и ERwin реализованы в составе одного пакета All Fusion Modeling Suite .
ERwin поддерживает несколько методологий информационного моделирования, основанных на ER-диаграммах, имеет средства для реализации многомерных хранилищ данных типа «звезда» и «снежинка», обеспечивает коллективную работу над проектом (All Fusion Model Manager), для выбранной СУБД автоматически создает базу данных (таблицы, индексы, хранимые процедуры, триггеры и другие объекты).
Характерными особенностями этой категории является наличие в инструментальном средстве независимых компонентов (All Fusion Process Modeler, All Fusion ERwin Data Modeler и др.) и интеграция моделей путем экспорта и импорта.
Малые интегрированные системы, выросшие исторически из локальных, практически не позволяют выполнить комплексный анализ систем, который в большей или меньшей степени необходим для создания средних и крупных ИС. С их помощью можно разрабатывать локальные и малые ИС или небольшие подсистемы, предназначенные для автоматизации отдельных бизнес-цепочек, например систем электронной коммерции, управления взаимоотношениями с клиентами, а также для решения задач так называемой «кусочной» автоматизации предприятия в соответствии с принципом «снизу-вверх».
Средние интегрированные средства моделирования представлены продуктами, которые имеют единую среду для разработки всех поддерживаемых типов моделей и которые изначально были ориентированы на комплексное использование различных методов и типов моделей: Designer/2000 (Oracle), Rational Rose (Rational Software), Paradigm Plus (CA/Platinum).
В состав Designer/2000 входят Process Modeller и System Modeller. Process Modeller предназначен для разработки иерархических моделей процессов, по структуре аналогичных IDEF0-моделям, а по форме - диаграммам плавательных дорожек, которые позволяют в графической форме описать бизнес-процессы автоматизируемого предприятия и представить их более наглядно за счет анимации и использования мультимедийных файлов. Модели процессов используются на всех этапах разработки ИС.
System Modeller содержит в своем составе диаграммы для построения моделей иерархии функций (Function Hierarchy Diagrammer), в том числе на основе модели процессов в автоматическом режиме, моделей потоков данных (Data Flow Diagrammer) и информационных моделей типа сущность-связь.
Rational Rose и Paradigm Plus основаны на объектно-ориентированном подходе к моделированию на базе языка UML (Unified Modeling Language). Отличия между ними состоят в основном в доступных пользователю типах диаграмм и методов. Последние версии Rational Rose позволяют строить восемь типов диаграмм: диаграммы прецедентов, диаграммы классов, диаграммы последовательности, диаграммы сотрудничества, диаграммы состояний, диаграммы действий, компонентов и диаграммы развертывания. Основным типом диаграмм являются диаграммы классов.
Средства моделирования среднего класса предназначены для выполнения комплексного анализа систем и могут быть использованы при создании локальных, малых и средних систем, особенно с этапа анализа спецификаций.
Крупные интегрированные средства моделирования ориентированы на проектирование крупных ИС, например систем управления предприятием класса ERP. Таким инструментальным средством является семейство ARIS (ARIS Toolset, ARIS Easy Design) компании IDS Sheer AG. В ARIS особое внимание уделено первому уровню анализа – анализу требований, и в нем обеспечивается четыре различных «взгляда» на моделирование и анализ: процессы, функции, данные и организация.
 |
При этом для каждого «взгляда» поддерживаются три уровня: требования, спецификации и внедрение. Каждый из уровней анализа состоит из своего комплекта моделей различных типов, в том числе и диаграмм UML. Процессный взгляд является характерной особенностью этого инструментария – для моделирования процессов предназначено 57 типов моделей из 85 (рис. 5.1).
Рис. 5.1 Количество типов моделей ARIS для разных «взглядов» и уровней моделирования
Для конкретных разработок количество используемых типов моделей может быть ограничено с помощью специальных фильтров.
Система ARIS имеет уникальные возможности для моделирования и анализа систем, моделирование может выполняться как «сверху-вниз», так и «снизу-вверх». Система позволяет контролировать процесс разработки моделей, определять условия для функционально-стоимостного анализа, имитационного моделирования, определять цели и критические факторы, производить оценку рисков и конкурентов.
Наряду с классификацией инструментальных средств на локальные, малые, средние и крупные в настоящее время используется классификация ERP и не-ERP.
Принадлежность к категории ERP для средства моделирования означает, что оно предназначено для выполнения комплексного анализа на всех стадиях разработки ERP-системы: требования, спецификации, внедрение. Из рассмотренных выше инструментальных средств к категории ERP можно отнести только ARIS. Естественно, что такое средство может быть использовано при создании любых ИС.
Принадлежность средства моделирования к категории не-ERP означает, что оно не предназначено для выполнения всех уровней анализа при проектировании ИС класса ERP, но его можно использовать при создании локальных, малых и средних ИС.
Методология IDEF 0
Для построения функциональных моделей обычно используется методология IDEF0, которая хорошо представлена в пакетах Design/IDEF и BPwin (All Fusion Process Modeler 4.1) [20].
Построение IDEF0-моделей в среде этих двух пакетов практически не отличается, поэтому рассмотрим процесс построения только в BPwin, поскольку в нем возможно построение интегрированных функциональных моделей, объединяющих три вида методологий: IDEF0, IDEF3 и Data Flow Diagramm (диаграмм потоков данных, DFD).
Методология IDEF0 предназначена для представления функций системы и анализа требований к системам и является одной из самых известных и широко используемых методологий проектирования ИС.
В IDEF0 реализованы идеи структурного анализа, под которыми понимают исследования, начинающиеся с общего обзора системы, а затем детализируют ее в виде иерархической структуры с определенным числом уровней, на каждом из которых не более 8 элементов. В результате система разбивается на функциональные части, дается их описание, исследуются информационные потоки и формализуется структура данных. В основе структурного анализа используются два базовых принципа: принцип «разделяй и властвуй» и принцип иерархического упорядочения.
Первый принцип позволяет решение трудных проблем выполнять путем разбиения их на множество более мелких независимых задач, легких для понимания и решения.
Второй принцип в дополнение к первому декларирует, что эти независимые задачи должны быть организованы в виде древовидных иерархических структур.
В нотации IDEF0 система представляется в виде комбинации блоков и дуг. Блоки используются для предоставления функций системы и сопровождаются текстами на естественном языке. Дуги представляют собой множества объектов (как физических, так и информационных) или действия, которые образуют связи между функциональными блоками.
В методологии IDEF0 функциональный блок, который на самом верхнем уровне иерархии представляет систему в качестве единого модуля, детализируется на другой диаграмме с помощью нескольких блоков, соединенных между собой интерфейсными дугами. Эти блоки представляют основные подфункции (подсистемы) единого исходного модуля. Каждый из этих подмодулей может быть декомпозирован подобным образом для более детального представления. Количество уровней иерархии не ограничивается, процесс декомпозиции блоков заканчивается тогда, когда каждый из модулей самого нижнего уровня декомпозиции может быть реализован в проектируемой системе одним программным модулем.
Результатом применения IDEF0 к некоторой системе является модель этой системы, состоящая из иерархически упорядоченного набора диаграмм, текста документации и словарей, связанных друг с другом с помощью перекрестных ссылок.
Двумя наиболее важными компонентами, из которых строятся диаграммы IDEF0, являются бизнес-функции (или работы) и данные, изображаемые в виде дуг, которые связывают работы.
При запуске BPwin появляется основная панель инструментов, палитра инструментов и навигатор. Для создания новой модели необходимо выполнить команду File / New, которая вызовет диалоговое окно создания модели, в котором следует выбрать тип методологии из трех (IDEF0, IDEF3 и DFD) и щелкнуть по кнопке ОК (рис. 5.2).
Рис. 5.2. Окно выбора методологии
Первая диаграмма (контекстная) в иерархии IDEF0-диаграмм представляет собой единственный блок, изображающий функционирование системы в целом (рис. 5.3).
Рис. 5.3. Контекстная диаграмма методологии IDEF0
Для отображения данных используется четыре вида дуг.
1. Входные дуги – входят в левую грань блока и изображают данные или объекты, которые преобразуются работой для получения результата на выходе (медицинская карта, заявления клиентов, накладные на поступивший товар и т.д.), допускается отсутствие входных дуг у блока.
2. Выходные дуги – выходят из правой грани работы и изображают данные или объекты, появившиеся в результате выполнения бизнес-функции. Должна быть хотя бы одна дуга, так как работа без результата не имеет смысла (всевозможные выходные формы, отчеты, договора, больничный лист и т.д.).
3. Дуги механизмов (ресурсов) – входят в нижнюю грань блока и изображают ресурсы, необходимые для выполнения работы, но не изменяющиеся в процессе работы (персонал, подразделения, предприятия, оборудование и т.п.). По усмотрению системного аналитика дуги ресурсов могут не изображаться графически, а могут быть представлены в виде текстового описания на диаграмме.
4. Дуги управления – входят в верхнюю грань блока и изображают правила или ограничения, которые определяют порядок выполнения работы, управляют работой (приказы Минздрава России, нормативная документация для выполнения данной работы в виде стандартов, законов, устава предприятия, инструкций, технических условий, должностных обязанностей и т.п.). Должна быть хотя бы одна дуга управления.
Все дуги и функциональные блоки должны быть поименованы (имена дуг – существительные, имена блоков должны начинаться с глагола или отглагольного существительного: «выполнить расчет зарплаты», «сформировать накладную», «оформление договора»). С каждой стороны блока может входить не более шести дуг одновременно.
Диаграмма следующего уровня описывает связи между несколькими подфункциями и является дочерней диаграммой по отношению к родительской. На нее автоматически передаются дуги в виде ICOM-кодов, что обеспечивает сохранение целостности всей модели. Для создания диаграммы нижнего уровня, необходимо выделить родительский блок и щелкнуть по кнопке 
.
В появившемся диалоговом окне следует выбрать количество функциональных блоков (от 2 до 6), на которые декомпозируется родительский блок, и методологию, в которой будет строиться новая диаграмма (IDEF0, IDEF3 и DFD). Затем необходимо соединить между собой блоки новой диаграммы с помощью соединительных дуг, а ICOM-коды – граничными дугами с соответствующими блоками диаграммы (рис. 5.4).
Каждый из полученных функциональных блоков может быть, в свою очередь, также декомпозирован.
IDEF0 дает возможность отражения реального процесса с помощью задания обратных связей по управлению и информации. Обратные связи по информации показываются в виде дуг, выходящих из правой стороны блока и входящих в левую сторону одного из предшествующих блоков.
Рис. 5.4. IDEF0-диаграмма второго уровня иерархии
Обратные связи этого типа на диаграмме отображаются снизу, то есть обходят функции снизу (например, дуга «Информация для корректировки плана»). С помощью этой обратной связи на диаграмме отображают тот факт, что регулярно анализируется выполнение плана и при необходимости формируют информацию, необходимую для корректировки плана на следующий период.
То есть обратные связи по информации позволяют отобразить на диаграммах информационные потоки, необходимые для корректировки действий, выполняемых по ходу бизнес-процесса.
Обратная связь по управлению изображается в виде дуги, выходящей из правой стороны блока и входящей в верхнюю сторону блока, огибая диаграмму сверху функций. Обратная связь по управлению означает, что при анализе выполнения плана могут быть приняты оперативные управленческие решения, регулирующие выполнение по производству готовой продукции.
IDEF0-методология в большей степени ориентирована на описание процессов верхних уровней. Ее применение характеризуется полнотой описания предметной области, которая достигается за счет наличия средств, отображающих управляющие воздействия, обратные связи по управлению и информации. Эта методология обеспечивает связанность диаграмм различных уровней декомпозиции в составе единой модели предметной области за счет использования механизма мигрирования (ICOM-кодов) и туннелирования дуг. Такой механизм обеспечивает связанность создаваемых диаграмм между собой и делает модель предметной области наглядной.
Рис. 5.5. Фрагмент дерева узлов IDEF0-диаграммы
Для того, чтобы представить все диаграммы модели на едином листе, следует воспользоваться деревом узлов (рис. 5.5), которое создается с помощью команды: Diagramm/Add Node Tree.
На более низких уровнях иерархии можно использовать применение методологий IDEF3 и DFD для создания диаграмм в составе единой модели. Основными признаками для применения методологии IDEF3 является наличие логики в описании процессов для применения методологии DFD – наличие хранилищ данных или материальных ресурсов для промежуточного хранения.
Методология IDEF 3
Нотация IDEF3 (Workflow diagramming) является второй важнейшей категорией после IDEF0 и ориентирована на описание логики взаимодействия информационных потоков. Особенно удобно применять IDEF3 на нижних уровнях функциональных моделей при описании работ, выполняемых в подразделениях и на рабочих местах (рис. 5.6). С помощью диаграмм IDEF3 удобно описывать сценарии действий работников подразделения, содержащих логику: когда процессы выполняются в определенной последовательности, задаваемой соответствующими логическими условиями (есть ли товар на складе, подписан ли документ, заключен ли договор с поставщиком и т.п.).
IDEF3 предполагает создание двух типов моделей: модель может отражать некоторые процессы в их логической последовательности, позволяя увидеть, как функционирует предприятие (процессно-ориентированный подход), или же модель может показывать сеть переходных состояний объекта, предлагая вниманию системного аналитика последовательность состояний, в которых может оказаться объект при прохождении через определенный процесс.
Центральным компонентом модели является единица работы, близкая по смыслу к работе IDEF0, которая изображается прямоугольником с прямыми углами и имеет имя в виде отглагольного существительного, обозначающим процесс действия, в составе фразы (изготовление изделия, генерация выходной формы и т.п.).
Взаимоотношения между работами реализуются с помощью стрелок, которые рисуются слева направо или сверху вниз.
Старшая стрелка (связь предшествования) изображается сплошной линией и означает, что работа-источник должна закончиться прежде, чем работа-цель начнется.
Связь отношения обозначается пунктирной линией и показывает связь между двумя работами или между работой и объектом ссылки.
Объект ссылки в IDEF3 выражает данные или определенную идею, которые нельзя связать со стрелкой, перекрестком или работой (клиент, заказы клиента, склад и т.п.). Объекты ссылок должны быть связаны с единицами работ или перекрестками пунктирными линиями.
Характерным объектом IDEF3 является перекресток, который отображает не только логику взаимодействия стрелок при слиянии и разветвлении, но и для отображения множества событий, которые могут быть завершены перед началом следующей работы. В диаграммах IDEF3 любое разветвление или объединение стрелок происходит только с помощью перекрестков для разветвления (Fan-out Junction) или слияния (Fan-in Junction) соответственно. Имеется пять наименований перекрестков, которые обеспечивают любую логику в сценариях (см. табл. 4).
Для внесения перекрестка в диаграмму служит кнопка в палитре инструментов (добавить в диаграмму перекресток – Junction), тип перекрестка выбирается из диалогового окна Junction Type Editor. Все перекрестки на диаграмме нумеруются, каждый номер имеет префикс J.
Рис. 5.6. IDEF3-диаграмма
Работы в диаграммах IDEF3 также декомпозируются как и в диаграммах IDEF0, но при этом не происходит мигрирования и туннелирования стрелок. Поэтому системный аналитик должен сам заботиться о связанности моделирования процесса и корректности декомпозиции.
Эту особенность необходимо учитывать при декомпозиции работы из диаграмм IDEF0 и в диаграмму IDEF3. Как уже было отмечено, согласно нотации IDEF3-диаграмма не должна иметь граничных стрелок, все стрелки должны заканчиваться на работах, перекрестках или объектах ссылки. Поэтому все стрелки на родительском функциональном блоке IDEF0-диаграммы следует затоннелировать, а в дочерней диаграмме создать нужные объекты ссылки и внутренние стрелки, начинающиеся с объектов ссылки, вместо граничных стрелок.
Таблица 4
Описание перекрестков IDEF 3
| Обозначение | Наименование | Смысл в случае слияния стрелок | Смысл в случае разветвления стрелок |
| Asynchronus AND | Все предшествующие процессы должны быть завершены | Все следующие процессы должны быть запущены |
| Synchronus AND | Все предшествующие процессы завершены одновременно | Все следующие процессы запускаются одновременно |
| Asynchronus OR | Один или несколько предшествующих процессов должны быть завершены | Один или несколько следующих процессов должны быть запущены |
| Synchronus OR | Один или несколько предшествующих процессов завершены одновременно | Один или несколько процессов запускаются одновременно |
| XOR (Exclusive OR) | Только один предшествующий процесс завершен | Только один следующий процесс запускается |
Методология DFD
Диаграммы потоков данных (Data Flow Diagramming, DFD) применяются для документирования механизма передачи и обработки информации в проектируемой системе, они удобны для наглядного изображения текущей работы системы документооборота организации. Обычно DFD используют в качестве дополнения IDEF0-модели или в ее составе на нижних уровнях иерархии для более наглядного отображения текущих операций документооборота в корпоративных системах обработки информации [20, 27]. DFD строится на основе четырех элементов.
Работы (функции обработки информации) обозначают процессы, которые обрабатывают и изменяют ситуацию. Они представляются на диаграммах в виде прямоугольников со скругленными углами. Стрелки идут от объекта-источника к объекту-приемнику, обозначая информационные потоки в системе документооборота. В DFD каждая сторона работы не имеет четкого назначения, как в IDEF0, поэтому стрелки могут подходить и выходить из любой грани прямоугольника работы, они могут сливаться и разветвляться.
Хранилища данных изображают объекты в покое, например в очереди на обработку, представляя собой данные, к которым осуществляется доступ и которые могут быть созданы или изменены работами (бумажный документ, файл, база данных и т.п.). На одной диаграмме может присутствовать несколько копий одного и того же хранилища.
Внешние ссылки (сущности) указывают на организацию или человека, которые участвуют в процессе обмена информацией с системой, но располагаются за пределами данной диаграммы. То есть они изображают входы в систему и/или выходы из нее. Внешние ссылки изображаются в виде прямоугольника с тенью и располагаются по краям диаграммы. Одна внешняя ссылка может быть использована многократно на одной или нескольких диаграммах, чтобы исключить наличие длинных и запутанных стрелок.
С помощью нотации DFD можно создать описание реально существующих в организации потоков данных как по процессному, так и по функциональному признаку. В первом случае получают модели бизнес-процессов в формате DFD, во втором – схему обмена данными между подразделениями.
Диаграмма потоков данных при функциональном подходе для кардиологического терапевтического отделения представлена на рис. 5.7.
Пациент при поступлении в терапевтическое отделение представляет медицинскую и статистическую карту, проходит обследование – все это является входным потоком документов. На выходе диаграммы данного уровня пациент может получить следующий перечень выходных документов: медицинскую и статистическую карты с результатами обследования и лечения, санаторно-курортную карту и больничный лист. На диаграмме присутствует хранилище данных, в котором будут размещаться копии документов и отчетные журналы.
Рис. 5.7. Диаграмма потоков данных при функциональном
подходе (DFD-методология)
В тех случаях, когда организационная структура терапевтического отделения не представляет интереса, более удобно использовать «объектную» диаграмму потоков данных (рис. 5.8). Основным объектом на диаграмме является терапевтическое отделение, а пациент представляется диаграмме как внешняя ссылка.
Подобная реализация диаграммы потоков данных позволяет более наглядно представить потоки документов между различными объектами.
Рис. 5.8. Диаграмма потоков данных при объектном подходе (DFD-методология)
На практике обычно применяют смешанные модели: на верхних уровнях иерархии используют нотацию IDEF0 для выявления функций, входящих в процесс. Затем при достижении некоторого уровня иерархии становится целесообразно сформировать диаграммы в формах DFD (для отображения потоков данных и материалов) и IDEF3 (для отображения логики в сложных сценариях).
Применение универсальных графических языков моделирования IDEF0, IDEF3 и DFD обеспечивает логическую целостность и полноту описания предметных областей.
BPwin обладает удобным инструментом для навигации по уровням иерархии модели. Это Model Explorer, который по организации похож на обычный проводник Windows. Функциональные IDEF0-блоки в Model Explorer показываются зеленым цветом, DFD – желтым и IDEF3 – синим. Щелкнув мышкой по любой из работ, представленных в навигаторе, пользователь может переходить на диаграмму, которая содержит данную работу.
Однако следует помнить об определенных правилах декомпозиции работы одной нотации в диаграмму другой. В BPwin допускаются только следующие переходы с одной нотации на другую: IDEF 0 ® DFD ; IDEF 0 ® IDEF 3; DFD ® IDEF 3.
Согласно нотации DFD-диаграмма не должна иметь граничных стрелок, то есть все стрелки должны начинаться и заканчиваться на работах, хранилищах данных или внешних ссылках. Поэтому при строгом следовании правилам нотации необходимо на дочерней DFD-диаграмме удалить все граничные дуги и вместо них создать соответствующие внешние ссылки и хранилища данных. Затем вместо удаленных граничных стрелок создать внутренние стрелки, начинающиеся с внешних ссылок или хранилищ данных, а стрелки на родительской диаграмме IDEF0 поместить в тоннель.
В тех случаях, когда на смешанных моделях сложно придерживаться этих правил нотации, BPwin позволяет создавать граничные дуги на DFD-диаграммах, не идентифицируя их как синтаксическую ошибку.
При декомпозиции работы IDEF0 или DFD в диаграмму IDEF3 дуги не мигрируют на дочернюю диаграмму, поскольку дуги на диаграммах IDEF3 могут показывать только последовательность выполнения работ и, следовательно, имеют другой смысл, чем в IDEF0 и DFD. Поэтому вместо граничных дуг используют соответствующие объекты ссылки, которые затем соединяются вспомогательными дугами с соответствующими работами на диаграмме IDEF3.
Рис. 5.9. Диаграмма потоков данных при объектном подходе
в нетрадиционном синтаксисе
BPwin 4.1 позволяет во всех нотациях использовать для работы не прямоугольники, а практически любые геометрические фигуры. При этом на работах можно разместить изображение, импортированное в словарь Bitmap Dictionary. Для использования нетрадиционного синтаксиса необходимо щелкнуть по работе и выбрать в контекстном меню пункт Box Style. Во вкладке Box Style следует выбрать опцию Custom и указать геометрическую фигуру (Shape) для работы и изображение (Bitmap). После щелчка по кнопке ОК на диаграмме работа отображается в нетрадиционном синтаксисе (рис. 5.9).
Использование нетрадиционного синтаксиса удобно не только для визуального эффекта, но и при преобразовании диаграммы IDEF3 в имитационную модель Arena.
Дата добавления: 2019-07-17; просмотров: 190; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!