Синтаксис и семантика IDEF0, IDEF3 и DFD-диаграмм

Размещено на http://www.allbest.ru/

Правительство Российской Федерации

Государственное образовательное бюджетное учреждение высшего профессионального образования

«Национальный исследовательский университет Высшая школа экономики»

Факультет бизнес-информатики

Практическое задание

по предмету «Архитектура предприятия»

Синтаксис и семантика IDEF0, IDEF3 и DFD-диаграмм

Выполнил:

Студент группы № 371

Фоос П.Ю.

Проверила:

Гончарова Д.А.

Москва 2013



Введение

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

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

Моделирование и описание бизнес-процессов -- это, прежде всего, информационная база для аналитика, но не цель проекта. Чтобы разработка модели бизнес-процессов была оправдана, а сама модель впоследствии эффективно применима, необходимо чётко сформулировать её цели, точку зрения, границы предметной области и глубину детализации.

В настоящее время двумя наиболее популярными методологиями построения функциональных моделей являются IDEF0 и DFD, и IDEF0 -- Function Modeling -- методология функционального моделирования, предназначенная для формализации и описания бизнес-процессов. Отличительной особенностью IDEF0 является её акцент на соподчинённость объектов. В IDEF0 рассматривается логические отношения между работами, а не их временная последовательность. В DFD (диаграмма потоков данных) же показывают, как объекты (включая и данные) реально перемещаются от одного действия к другому [1].

Именно эти модели будут подробно рассмотрены в данном реферате.



1. Этапы проектирования функциональной модели

Рис. 1. Схема построения функциональной модели

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

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

На третьем этапе операции классифицируют по задачам, стоящим перед каждой функцией управления, и составляют классификатор работ. Операции классифицируются по определенным признакам: содержанию, периодичности проведения, рутинные, формализуемые, неформализуемые работы и т.д.

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

На пятом и шестом этапах распределяются права и обязанности между подразделениями и персоналом при выполнении работ по функциям управления. Возможность обоснованно разделить задачи по подразделениям и службам аппарата управления, а также обеспечить комплексную реализацию работ позволяет матрица разделения административных задач управления (PA3У).

Рис. 2. Фрагмент матрицы РАЗУ

Эта матрица представляет собой таблицу, в подлежащем которой располагаются наименования подразделений и служб (работники аппарата управления могут быть указаны конкретно), а в сказуемом перечисляются задачи, выполняемые этими исполнителями. Условным знаком обозначается отношение каждого подразделения, службы или конкретного работника к решению определенной задачи [2].

2. Сравнение структурного и процессного подходов управления деятельностью предприятия

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

Недостатками такого подхода к организации и управлению деятельностью предприятия являются следующие:

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

отсутствие цельного описания технологий выполнения работы, в лучшем случае существует только фрагментарная (на уровне структурных элементов), и то не совсем актуальная документируемость технологий;

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

высокие накладные расходы, как правило, непонятно откуда появляющиеся;

неэффективность информационной поддержки, обусловленная наличием «лоскутной» автоматизацией деятельности отдельных структурных элементов и неудачными попытками внедрения корпоративных информационных систем.

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

Процессный подход впервые был предложен приверженцами школы административного управления, которые пытались определить функции менеджмента. Однако они, во-первых, рассматривали эти функции как независимые друг от друга, во-вторых, не ориентированные на управление бизнес-процессами предприятия.

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

В рамках процессного подхода любое предприятие рассматривается как бизнес-система, которая представляет собой связанное множество бизнес-процессов, конечными целями которых является выпуск продукции или услуги [4].

3. Методология структурного моделирования

Нотация диаграмм потоков данных (Data Flow Diagram, DFD) позволяет отображать как шаги бизнес-процесса, так и поток документов и управления (в основном управления, поскольку на верхнем уровне описания процессных областей значение имеет передача управления). Также на диаграмме можно отображать средства автоматизации шагов бизнес-процессов. Обычно используется для отображения третьего и ниже уровня декомпозиции бизнес-процессов (первый уровень -- перечень бизнес-процессов (IDEF0), а второй -- функции, выполняемые в рамках бизнес-процессов (IDEF3)).

Области применения диаграмм потоков данных:

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

-- моделирование существующего процесса движения информации;

-- описание документооборота, обработки информации;

-- дополнение к модели IDEF0 для более наглядного отображения текущих операций документооборота;

--проведение анализа и определения основных направлений реинжиниринга информационной системы.

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

Методология DFD (Data Flow Diagram) удобна для описания не только бизнес-процессов (как дополнение к IDEF0), но и программных систем:

-- DFD-диаграммы создавались как средство проектирования программных систем (в то время как IDEF0 -- средство проектирования систем вообще), поэтому DFD имеют более богатый набор элементов, адекватно отражающих их специфику (например, хранилища данных являются прообразами файлов или баз данных);

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

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

На схемах бизнес-процесса отображаются:

-- функции процесса;

-- входящая и исходящая информация при описании документов;

-- внешние бизнес-процессы, описанные на других диаграммах;

-- точки разрыва при переходе процесса на другие страницы.

При моделировании DFD система рассматривается как сеть связанных между собой функций, т. е. как совокупность сущностей. Методология основана на идее нисходящей иерархической организации. Целью является преобразование общих, неясных знаний о требованиях к системе в точные определения. Внимание фокусируется на потоках данных.

4. Варианты методологии DFD

Существует два основных варианта методологии DFD: методология Гейна-Сарсона и методология Йордана-Де Марко.

Главной отличительной чертой методологии Гейна-Сарсона является наличие этапа моделирования данных, определяющего содержимое хранилищ данных (БД и файлов) в DFD. Этот этап включает построение списка элементов данных, располагающихся в каждом хранилище данных; анализ отношений между данными и построение соответствующей диаграммы связей между элементами данных; представление всей информации по модели в виде связанных нормализованных таблиц.

Кроме того, эти методологии отличаются нотацией.

Обе методологии основаны на простой концепции нисходящего поэтапного разбиения функций системы на подфункции:

1) формирование контекстной диаграммы верхнего уровня, идентифицирующей границы системы и определяющей интерфейсы между системой и окружением;

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

3) проведение детализации для каждого из пустых процессов.

5. Синтаксис и семантика моделей DFD

Основные объекты нотации DFD:

-- блоки (Blocks) или работы (Activities) -- отображают процессы обработки и изменения информации;

-- стрелки (Arrows) или потоки данных (Data Flow) -- отображают информационные потоки;

-- хранилища данных (Data Store) -- отображают данные, к которым осуществляется доступ; эти данные используются, создаются или изменяются работами;

-- внешние ссылки (External References) или внешние сущности (External Entity) -- отображают объекты, с которыми происходит взаимодействие.

Работы DFD -- графическое изображение операции по обработке или преобразованию информации (данных). Входная информация преобразуется в выходную. Работы именуются глаголами в неопределённой форме с последующим дополнением.

По нотации Гейна-Сарсона DFD-блок изображается прямоугольником со скруглёнными углами. Каждый блок должен иметь уникальный номер для ссылки на него внутри диаграммы. Номер каждого блока может включать префикс, номер родительского блока (А) и номер объекта, представляющий собой уникальный номер блока на диаграмме.

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

Поток данных -- механизм, использующийся для моделирования передачи информации между участниками процесса информационного обмена (функциями, хранилищами данных, внешними ссылками). По нотации Гейна-Сарсона поток данных изображается стрелкой между двумя объектами DFD-диаграммы, предпочтительно горизонтальной и/или вертикальной, причём направление стрелки указывает направление потока. Каждая стрелка должна иметь источник и цель. В отличие от стрелок IDEF0-диаграммы, стрелки DFD могут входить или выходить из любой стороны блока.

Стрелки описывают, как объекты (включая данные) двигаются из одной части системы в другую. Поскольку в DFD каждая сторона блока не имеет чёткого назначения, в отличие от блоков IDEF0-диаграммы, стрелки могут подходить и выходить из любой грани.

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

Иногда информация может двигаться в одном направлении, обрабатываться и возвращаться обратно. Такая ситуация может моделироваться либо двумя различными потоками, либо одним двунаправленным потоком. На поток данных можно ссылаться, указывая процессы, сущности или накопители данных, которые поток соединяет. Каждый поток должен иметь имя, расположенное вдоль или над стрелкой, выбранное таким образом, чтобы в наибольшей степени передавать смысл содержания потока пользователям, которые будут рассматривать диаграмму потоков данных.

Хранилище данных - графическое представление потоков данных, импортируемых/экспортируемых из соответствующих баз данных, изображает объекты в покое. Является неким прообразом базы данных информационной системы организации.

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

Хранилища данных используются:

-- в материальных системах (там, где объекты ожидают обработки, например в очереди);

-- в системах обработки информации для моделирования механизмов сохранения данных с целью дальнейших операций.

По нотации Гейна-Сарсона хранилище данных обозначается двумя горизонтальными линиями, замкнутыми с одного края. Каждое хранилище данных должно идентифицироваться для ссылки буквой D и произвольным числом в квадрате с левой стороны, например D5.

В модели может быть создано множество вхождений хранилищ данных, каждое из которых может иметь одинаковое имя и ссылочный номер. Для того чтобы не усложнять диаграмму потоков данных пересечениями линий, можно изображать дубликаты накопителя данных дополнительными вертикальными линиями с левой стороны квадрата. Хранилища данных не изменяют потоки данных, а служат только для хранения поступающих объектов.

Рис. 3. Хранилище данных DFD

Внешняя сущность -- объект диаграммы потоков данных, являющийся источником или приёмником информации извне модели. Внешние сущности изображают входы и/или выходы, т. е. обеспечивают интерфейс с внешними объектами, находящимися вне моделируемой системы. Внешними ссылками системы обычно являются логические классы предметов или людей, представляющие собой источник или приёмник сообщений, например, заказчики, конструкторы, технологи, производственные службы, кладовщики и т. д.

По нотации Гейна-Сарсона пиктограмма внешней ссылки представляет собой оттенённый прямоугольник, верхняя левая сторона которого имеет двойную толщину и обычно располагается на границах диаграммы. Внешняя ссылка может идентифицироваться строчной буквой Е в левом верхнем углу и уникальным номером, например Е5. Кроме того, внешняя ссылка имеет имя.

Одна и та же внешняя ссылка может быть использована многократно на одной или нескольких диаграммах. Обычно к такому приёму прибегают для того, чтобы не рисовать слишком длинных и запутанных стрелок. Каждая внешняя сущность имеет префикс.

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

Рис. 4. Внешняя сущность DFD

Межстраничные ссылки (Off-Page Reference) -- инструмент нотации DFD, описывающий передачу данных или объектов с одной диаграммы модели на другую. Стрелка межстраничной ссылки имеет идентифицирующее имя, номер и изображение окружности.

Помимо этого, для каждого информационного потока и хранилища определяются связанные с ними элементы данных. Каждому элементу данных присваивается имя. Также для него может быть указан тип данных и формат. Именно эта информация является исходной на следующем этапе проектирования -- построении модели «сущность-связь». При этом, как правило, информационные хранилища преобразуются в сущности. Проектировщику остаётся только решить вопрос с использованием элементов данных, не связанных с хранилищами [5].

Пример.



Рис. 5. Пример DFD-диаграммы.

6. Функциональные диаграммы

IDEF0 -- Function Modeling -- методология функционального моделирования, предназначенная для формализации и описания бизнес-процессов. Отличительной особенностью IDEF0 является её акцент на соподчинённость объектов. В IDEF0 рассматривается логические отношения между работами.

Методология IDEF0 представляет собой совокупность методов, правил и процедур, предназначенных для построения функциональной модели объекта какой-либо предметной области.

Основные элементы методологии IDEF0 основываются на следующих концепциях:

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

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

-- связность диаграмм -- блоки нумеруются специальным образом;

-- уникальность меток и наименований -- отсутствие повторяющихся имён;

-- синтаксические правила для графических символов (блоков и стрелок);

-- разделение входов и управлений -- правило определения роли данных;

-- отделение организации от функции, т.е. исключение влияния организационной структуры на функциональную модель.

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

Модель IDEF0 всегда начинается с представления системы как единого целого -- одного функционального блока с интерфейсными дугами, уходящими за пределы рассматриваемой области. Такая диаграмма с одним функциональным блоком называется контекстной диаграммой и обозначается идентификатором «А0».

В процессе декомпозиции функциональный блок, который в контекстной диаграмме отображает систему как единое целое, подвергается детализации на другой диаграмме. Получившаяся диаграмма второго уровня содержит функциональные блоки, отображающие главные подфункции функционального блока контекстной диаграммы, и называется дочерней (Child Diagram) по отношению к нему, а каждый из функциональных блоков, принадлежащих дочерней диаграмме, соответственно называется дочерним блоком (Child Box). В свою очередь, функциональный блок-предок называется родительским блоком по отношению к дочерней диаграмме (Parent Box), а диаграмма, к которой он принадлежит, -- родительской диаграммой (Parent Diagram). Каждая из подфункций дочерней диаграммы может быть далее детализирована путём аналогичной декомпозиции соответствующего ей функционального блока. В случае декомпозиции функционального блока все интерфейсные дуги, входящие в данный блок или исходящие из него, фиксируются на дочерней диаграмме.

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

7. Иерархия диаграмм

Построение IDEF0-модели начинается с представления всей системы в виде простейшей компоненты -- одного блока и стрелок, изображающих интерфейсы с функциями вне системы. Поскольку единственный блок представляет всю систему как единое целое, то имя, указанное в блоке, является общим. Это верно и для интерфейсных дуг -- они также представляют полный набор внешних интерфейсов системы в целом.

Далее блок, который представляет систему в качестве единого модуля, детализируется на другой диаграмме с помощью нескольких блоков, соединённых интерфейсными дугами. Эти блоки представляют основные подфункции исходной функции. Данная декомпозиция выявляет полный набор подфункций, каждая из которых представлена как блок, границы которого определены интерфейсными дугами. Каждая из этих подфункций может быть разбита подобным образом для более детального представления.

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

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

8. Синтаксис и семантика моделей IDEF0

Нотация IDEF0 содержит только две сущности -- блоки и стрелки.

Рис. 6. Функциональный блок и интерфейсные дуги

Функциональные блоки (Activity Box) задают действия. Функциональный блок графически изображается в виде прямоугольника. Он задаёт некоторую конкретную функцию в рамках рассматриваемой системы.



9. Интерфейсные дуги

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

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

Типизацию категорий информации можно описать аббревиатурой ICOM:

I (Input), вход -- то, что потребляется в ходе выполнения процесса;

C (Control), управление -- ограничения и инструкции, влияющие на выполнение процесса;

O (Output), выход -- то, что является результатом выполнения процесса;

M (Mechanism), исполняющий механизм -- то, что используется для выполнения процесса, но остаётся неизменным.

Стрелки входа указывают на сырьё или информацию, потребляемые или преобразуемые функциональным блоком для производства чего-либо на выходе. Поскольку возможно существование блока, ничего не преобразующего и не изменяющего, то наличие входных стрелок не является обязательным. Стрелки входа направлены в левую сторону прямоугольника.

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

Управление остаётся неизменным при работе блока. Если же некая инструкция или правило должно быть изменено блоком, то соответствующую информацию следует рассматривать не как управление, а как входные данные. В случае, когда неясно, относить стрелку к входу или к управлению, следует отнести её к управлению, вплоть до разрешения неясности.

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

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

10. Комбинированные стрелки

Выделяют пять основных видов комбинированных стрелок: выход-вход, выход-управление, выход-механизм исполнения, выход-обратная связь на управление, выход-обратная связь на вход.

Рис. 7. Комбинированная стрелка «выход - вход»



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

Стрелка выход-управление показывает, что один блок управляет работой другого.

Стрелки выход-механизм исполнения показывают, что выход одного функционального блока применяется в качестве инструментария для работы второго.

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

Рис. 8. Комбинированная стрелка «выход-управление»

Стрелка выход-обратная связь на вход обычно применяется для описания циклов повторной обработки чего-либо Стрелка изображается под блоком. Кроме того, возможно применение данной связи при повторном использовании бракованной продукции.

11. Разъединение и соединение стрелок

Выход функционального блока может быть использован в нескольких блоках. В IDEF0 предусматривается соединение и разъединение стрелок. Разъединённые или объединённые стрелки могут иметь наименования, отличающиеся от наименования исходной стрелки. Совокупность исходной и разъединённых или объединённых стрелок называется связанными стрелками. Эта техника применяется для того, чтобы отразить использование только части сырья или информации, обозначаемых исходной стрелкой.

Рис. 9. Разъединение стрелок

12. Туннели

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



Рис. 10. Стрелка, выходящая из туннеля

Пример.

В качестве примера опишем метамодель IDEF0, то есть обозначим элементы диаграммы наиболее общими понятиями и проведём декомпозицию. Для уменьшения объёма составим только контекстную диаграмму и её деком позицию.

Вначале рисуется контекстная диаграмма, состоящая, как правило, из одного блока. Здесь изображены все элементы в общем виде.

Рис. 11. Пример контекстной диаграммы IDEF0

Входной поток разбит на группы:

-- материальные потоки;

-- информационные потоки;

-- энергетический поток;

-- финансовый поток.

Аналогично разбит и выходной поток:

-- материальные потоки;

-- информационные потоки;

-- финансовый поток.

Далее происходит первая декомпозиция -- декомпозиция контекстной диаграммы. На ней представлены основные действия, которые должны быть выполнены для реализации модели [5].

Рис. 12. Пример декомпозиции контекстной диаграммы.

13. Методология IDEF3

Модель IDEF3 описывается как упорядоченная последовательность событий, и поэтому хорошо приспособлена для сбора данных. Очень часто IDEF3 используют как метод, дополняющий IDEF0. Каждый функциональный блок IDEF0 может быть представлен в виде отдельного процесса IDEF3.

14. Синтаксис и семантика

Данная методика не имеет жёстких синтаксических и семантических ограничений.

Основой методологии является сценарий (Scenario) бизнес-процесса, осуществляющий описание последовательности изменений свойств объекта в рамках рассматриваемого процесса. Исполнение каждого сценария сопровождается соответствующим документооборотом, который состоит из двух основных потоков -- документов, определяющих структуру и последовательность процесса, и документов, отображающих ход его выполнения.

15. Диаграммы

В IDEF3 используется два типа диаграмм, представляющие описание одного и того же сценария в разных ракурсах.

1) С помощью диаграмм описания последовательности этапов процесса (Process Flow Description Diagrams, PFDD) документируется последовательность и описание стадий обработки в рамках исследуемого бизнес-процесса. Описание производится с точки зрения стороннего наблюдателя. Ключевыми элементами являются понятия, процесс, логика процесса.

2) Диаграммы перехода состояния объекта (Object State Transition Network, OSTN) используются для иллюстрации трансформаций, которые происходят на каждой стадии бизнес-процесса. При этом описание производится с точки зрения самого объекта.



16. Единица работы

Действие в IDEF3 называется единицей работы (Unit of Work, UOW) и обозначается прямоугольником. Действия именуются глаголами или отглагольными существительными. Каждому действию назначается уникальный номер.

Рис. 13. Единица работы

17. Связи

С помощью связей выделяются существенные взаимоотношения между действиями, задавая их последовательность. Все связи однонаправленные.

Выделяют три вида связей:

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

-- связь Объектный поток применяется в случае, когда объект, являющийся результатом выполнения исходного действия, необходим для выполнения конечного действия;

-- связь Нечёткое отношение используется, если невозможно применить предыдущие типы связей. При помощи связи типа Нечёткое отношение можно, например, описывать параллельные процессы. Корректная интерпретация нечётких связей должна быть документирована в модели.

Рис. 14. Типы связей

18. Соединения

Одно действие может порождать несколько. Или для выполнения действия требуется завершение нескольких действий. Для описания ветвлений процессов используют соединения.

Рис. 15. Типы соединений



Соединения разбиваются по следующим дихотомиям.

1) Разворачивающие и сворачивающие соединения (ветвление соединений):

-- разворачивающие соединения используют для разъединения потоков, так что завершение одного действия вызывает начало нескольких других;

-- сворачивающие соединения объединяют потоки, то есть завершение одного или нескольких действий вызывает начало выполнения другого.

2) Синхронные и асинхронные соединения. Иногда необходимо начинать или заканчивать параллельные действия одновременно, что изображается с помощью синхронных соединений. В противном случае соединение является асинхронным. Все соединения на диаграмме должны быть парными. Однако при этом типы соединений не обязаны совпадать. На диаграмме соединения обычно обозначаются буквой «J» и цифрой [5].

Пример.

Рис. 16. Пример IDEF3-диаграммы



Вывод

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

Методология IDEF0 -- это технология описания системы в целом как множества взаимозависимых действий, или функций. IDEF0 -- функции системы исследуются независимо от объектов, которые обеспечивают их выполнение. Одной из основных идей моделей IDEF0 является построение двух видов моделей: "как есть" и "как должно быть", которые используются для проведения реинжиниринга бизнес-процессов организации. Кроме того, IDEF0 обеспечивает удобный язык обмена информацией о моделируемой системе.

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



Список литературы

1. https://sites.google.com/site/vstusapr52/6-kurs/gosy/vse-otvety-na-voprosy/5-funkcionalnoe-modelirovanie-ctandart-idef-0-modelirovanie-potokov-dannyh-dfd.

2. http://www.basha.lv/download.php?id=37&lg=ru.

3. http://economican.ru/v_man.php?id=11.

4. http://quality.eup.ru/DOCUM/podp.htm.

5. Кулябов Д.С., Королькова А.В. Введение в формальные методы описания бизнес-процессов: Учеб. пособие. -- М.: РУДН, 2008. -- 173 с.: ил.

Размещено на Allbest.ru

...