Лекция 8. Методологии DFD и IDEF3
Для того чтобы документировать механизмы передачи и обработки информации в моделируемой системе, используются диаграммы потоков данных (Data Flow Diagrams). Диаграммы DFD обычно строятся для наглядного изображения текущей работы системы документооборота вашей организации. Чаще всего диаграммы DFD используют в качестве дополнения модели бизнес-процессов, выполненной в IDEF0.
Всего DFD использует четыре важных элемента:
- Работы . Работы в DFD обозначают функции или процессы, которые обрабатывают и изменяют информацию. Работы представлены на диаграммах в виде прямоугольников со скругленными углами. (cм. Рис.8.3 - “Проверить наличие товара на складе”)
- Стрелки . Стрелки идут от объекта-источника к объекту-приемнику, обозначая информационные потоки в системе документооборота. (cм. Рис.8.3 - “Запрос на склад”)
- Внешние ссылки . Внешние ссылки указывают на место, организацию или человека, которые участвуют в процессе обмена информацией с системой, но располагаются за рамками этой диаграммы. . (cм. Рис.8.3 - “Клиент”)
- Хранилища данных . Хранилища данных представляют собой собственно данные, к которым осуществляется доступ, эти данные также могут быть созданы или изменены работами. На одной диаграмме может присутствовать несколько копий одного и того же хранилища данных. (cм. Рис.8.3 - “Сведения о заказах”)
В отличие от стрелок IDEF0, которые представляют собой жесткие взаимосвязи, стрелки DFD показывают, как объекты (включая данные) двигаются от одной работы к другой.
Стрелки (Потоки данных). Стрелки описывают движение объектов из одной части системы в другую. Поскольку в DFD каждая сторона работы не имеет четкого назначения, как в IDEF0, стрелки могут подходить и выходить из любой грани прямоугольника работы. В DFD также применяются двунаправленные стрелки для описания диалогов типа "команда-ответ" между работами, между работой и внешней сущностью и между внешними сущностями (рис. 8.1).
Рисунок 8.1 - Внешняя сущность
Хранилище данных. В отличие от стрелок, описывающих объекты в движении, хранилища данных изображают объекты в покое (рис. 8.2).
Рисунок 8.2 - Хранилище данных
В материальных системах хранилища данных изображаются там, где объекты ожидают обработки, например в очереди. В системах обработки информации хранилища данных являются механизмом, который позволяет сохранить данные для последующих процессов.
Рисунок 8.3 - Пример диаграммы DFD
В диаграммах потоков данных все используемые символы складываются в общую картину, которая дает четкое представление о том, какие данные используются, и какие функции выполняются системой документооборота. При этом часто выясняется, что существующие потоки информации, важные для деятельности компании, реализованы ненадежно и нуждаются в реорганизации.
Наличие в диаграммах DFD элементов для описания источников, приемников и хранилищ данных позволяет точно описать процесс документооборота. Однако для описания логики взаимодействия информационных потоков модель дополняют диаграммами еще одной методологии - IDEF3, также называемой workflow diagramming. Методология моделирования IDEF3 позволяет графически описать и задокументировать процессы, фокусируя внимание на течении этих процессов и на отношениях процессов и важных объектов, являющихся частями этих процессов.
IDEF3 предполагает построение двух типов моделей: модель может отражать некоторые процессы в их логической последовательности, позволяя увидеть, как функционирует организация, или же модель может показывать “сеть переходных состояний объекта”, предлагая вниманию аналитика последовательность состояний, в которых может оказаться объект при прохождении через определенный процесс.
С помощью диаграмм IDEF3 можно анализировать сценарии из реальной жизни, например, как закрывать магазин в экстренных случаях или какие действия должны выполнить менеджер и продавец при закрытии. Каждый такой сценарий содержит в себе описание процесса и может быть использован, что бы наглядно показать или лучше задокументировать бизнес-функции организации.
Модель, выполненная в IDEF3, может содержать следующие элементы:
- Единицы работы (Unit of Work) - основной компонент диаграммы IDEF3 близкий по смыслу к работе IDEF0.
- Связи (Links) - Связи, изображаемые стрелками, показывают взаимоотношения работ. В IDEF3 различают три типа связей:
- Связь предшествования (Precedence) - показывает, что прежде чем начнется работа-приемник, должна завершиться работа-источник. Обозначается сплошной линией.
- Связь отношения (Relational) - показывает связь между двумя работами или между работой и объектом ссылки. Обозначается пунктирной линией.
- Поток объектов (Object Flow) - показывает участие некоторого объекта в двух или более работах, как, например, если объект производится в ходе выполнения одной работы и потребляется другой работой. Обозначается стрелкой с двумя наконечниками.
- Перекрестки (Junctions) - перекрестки используются в диаграммах IDEF3, чтобы показать ветвления логической схемы моделируемого процесса и альтернативные пути развития процесса могущие возникнуть во время его выполнения. Различают два типа перекрестков:
- Перекресток слияния (Fan-in Junction) - узел, собирающий множество стрелок в одну, указывая на необходимость условия завершенности работ-источников стрелок для продолжения процесса.
o Перекресток ветвления (Fan-out Junction) - узел, в котором единственная входящая в него стрелка ветвится, показывая, что работы, следующие за перекрестком, выполняются параллельно или альтернативно.
Таблица 1.4. Типы перекрестков
Обозначение | Наименование | Смысл в случае слияния стрелок (Fan-in Junction) | Смысл в случае разветвления стрелок (Fan-out Junction) |
Asynchronous AND | Все предшествующие процессы должны быть завершены | Все следующие процессы должны быть запущены | |
Synchronous AND | Все предшествующие процессы завершены одновременно | Все следующие процессы запускаются одновременно | |
Asynchronous OR | Один или несколько предшествующих процессов должны быть завершены | Один или несколько следующих процессов должны быть запущены | |
Synchronous OR | Один или несколько предшествующих процессов завершены одновременно | Один или несколько следующих процессов запускаются одновременно | |
XOR (Exclusive OR) | Только один предшествующий процесс завершен | Только один следующий процесс запускается |
Всё перекрестки на диаграмме нумеруются, каждый номер имеет префикс J. Можно редактировать свойства перекрестка при помощи диалога Definition Editor. В отличие от IDEF0 и DFD в IDEF3 стрелки могут сливаться и разветвляться только через перекрестки.
· Объекты ссылок (Referents) - служат для выражения идей и концепций без использования специальных методов, таких как стрелки, перекрестки или работы. Объект ссылки изображается в виде прямоугольника, похожего на прямоугольник работы. Имя объекта ссылки задается в диалоге Referent (пункт всплывающего меню Name Editor), в качестве имени можно использовать имя какой-либо стрелки с других диаграмм или имя сущности из модели данных. Объекты ссылки должны быть связаны с единицами работ или перекрестками пунктирными линиями. Официальная спецификация IDEF3 различает три стиля объектов ссылок - безусловные (unconditional), синхронные (synchronous) и асинхронные (asynchronous). BPwin поддерживает только безусловные объекты ссылок. Синхронные и асинхронные объекты ссылок, используемые в диаграммах переходов состояний объектов, не поддерживаются.
Декомпозиция работ. В IDEF3 декомпозиция используется для детализации работ. Методология IDEF3 позволяет декомпозировать работу многократно, т.е. работа может иметь множество дочерних работ. Это позволяет в одной модели описать альтернативные потоки. Возможность множественной декомпозиции предъявляет дополнительные требования к нумерации работ. Так, номер работы состоит из номера родительской работы, версии декомпозиции и собственного номера работы на текущей диаграмме (рис. 1.54).
Рисунок 8.5 - Номер единицы работы (UOW)
Рисунок 8.6 Пример диаграммы IDEF3
Рассмотрим процесс декомпозиции диаграмм IDEF3, включающий взаимодействие автора (аналитика) и одного или нескольких экспертов предметной области.
Кроме того, что уже было сказано по поводу трех поддерживаемых BPwin методологий, необходимо отметить еще несколько вещей. Как мы уже замечали ранее модель, выполненная в BPwin представляет собой набор иерархически упорядоченных диаграмм (не обязательно сделанных в одной методологии, чаще модели бывают смешанными). При размещении на очередной диаграмме некоторого элемента (работы, стрелки…) этот элемент вместе со всеми своими свойствами (которые всегда можно просмотреть или изменить в соответствующем редакторе BPwin) автоматически заносится в словарь BPwin, в результате вместе с графическим изображением моделируемой системы аналитик получает десятки страниц с подробным текстовым описанием системы.
Применение универсальных графических языков бизнес-моделирования IDEF0, IDEF3 и DFD обеспечивает логическую целостность и полноту описания, необходимую для достижения точных и непротиворечивых результатов. Посредством набора графических инструментов для отображения действий и объектов, BPwin позволяет легко построить схему процесса, на которой показаны исходные данные, результаты операций, ресурсы, необходимые для их выполнения, управляющие воздействия, взаимные связи между отдельными работами. Интерактивное выделение объектов обеспечивает постоянную визуальную обратную связь при построении модели. BРwin поддерживает ссылочную целостность, не допуская определения некорректных связей и гарантируя непротиворечивость отношений между объектами при моделировании.
Моделирование бизнес-процессов с BPwin 4.0 Маклаков Сергей Владимирович
1.4.2. Метод описания процессов IDEF3
1.4.2. Метод описания процессов IDEF3
Наличие в диаграммах DFD элементов для описания источников, приемников и хранилищ данных позволяет более эффективно и наглядно описать процесс документооборота. Однако для описания логики взаимодействия информационных потоков более подходит IDEF3, называемая также workflow diagramming - методологией моделирования, использующая графическое описание информационных потоков, взаимоотношений между процессами обработки информации и объектов, являющихся частью этих процессов. Диаграммы Workflow могут быть использованы в моделировании бизнес-процессов для анализа завершенности процедур обработки информации. С их помощью можно описывать сценарии действий сотрудников организации, например последовательность обработки заказа события, которые необходимо обработать за конечное время. Каждый тенарий сопровождается описанием процесса и может быть использован я документирования каждой функции.
IDEF3 - это метод, имеющий основной целью дать возможность налитикам описать ситуацию, когда процессы выполняются в определенной последовательности, а также описать объекты, участвующие совместно в одном процессе.
Техника описания набора данных IDEF3 является частью структурного анализа. В отличие от некоторых методик описаний процессов IDEF3 не ограничивает аналитика чрезмерно жесткими рамками синтаксиса, что может привести к созданию неполных или противоречивых моделей.
IDEF3 может быть также использован как метод создания процессов. IDEF3 дополняет IDEF0 и содержит все необходимое для построения моделей, которые в дальнейшем могут быть использованы для имитационного анализа.
Каждая работа в IDEF3 описывает какой-либо сценарий бизнес-процесса и может являться составляющей другой работы. Поскольку сценарий описывает цель и рамки модели, важно, чтобы работы именовались отглагольным существительным, обозначающим процесс действия, или фразой, содержащей такое существительное.
Точка зрения на модель должна быть задокументирована. Обычно это точка зрения человека, ответственного за работу в целом. Также необходимо задокументировать цель модели - те вопросы, на которые призвана ответить модель.
Диаграммы. Диаграмма является основной единицей описания в IDEF3. Важно правильно построить диаграммы, поскольку они предназначены для чтения другими людьми (а не только автором).
Единицы работы - Unit of Work (UOW). UOW, также называемые работами (activity), являются центральными компонентами модели. В IDEF3 работы изображаются прямоугольниками с прямыми углами и имеют имя, выраженное отглагольным существительным, обозначающим процесс действия, одиночным или в составе фразы, и номер (идентификатор); другое имя существительное в составе той же фразы обычно отображает основной выход (результат) работы (например, "Изготовление изделия"). Часто имя существительное в имени работы меняется в процессе моделирования, поскольку модель может уточняться и редактироваться. Идентификатор работы присваивается п Ри создании и не меняется никогда. Даже если работа будет удалена, ее идентификатор не будет вновь использоваться для других работ. Обычно номер работы состоит из номера родительской работы и порядкового номера на текущей диаграмме.
Работа в IDEF3 требует более подробного описания, чем работа в IDEF0 Каждая UOW должна иметь ассоциированный документ, который включает текстовое описание компонентов работы: объектов (Objects) и фактов (Facts), связанных с работой, ограничений (Constraints), накладываемых на работу, и дополнительное описание работы (Description). Эта информация заносится во вкладку UOW диалога Activity Properties (рис. 1.4.4).
Рис. 1.4.4. Вкладка UOW диалога Activity Properties Пример значений свойств UOW приведен в табл. 1.4.1.
Таблица 1.4.1. Пример текстового описания компонентов UOW
ТunИспользование
NAMEПодготовка компонентов
"DefinitionПодготавливаются все компоненты компьютера согласно
спецификации заказа
"ObjectsКомпоненты: винчестеры, корпуса, материнские платы,
видиокарты, звуковые карты, дисководы CD-ROM
и флоппи, модемы, программное обеспечение
"Constrains Установка модема требует установки дополнительного пограммного обеспечения
Связи. Связи показывают взаимоотношения работ. Все связи в IDEF3 однонаправленны и могут быть направлены куда угодно, но обычно диаграммы IDEF3 стараются построить так, чтобы связи были направлены слева направо. В IDEF3 различают три типа стрелок, изображающих связи, стиль которых устанавливается во вкладке Style (рис. 1.4.5) диалога Arrow Properties (пункт контекстного меню Style).
Рис. 1.4.5. Вкладка Style диалога Arrow Properties
Старшая (Precedence) стрелка - сплошная линия, связывающая единицы работ (UOW). Рисуется слева направо или сверху вниз. Показывает, что работа-источник должна закончиться прежде, чем работа-цель начнется.
Стрелка отношения (Relational Link) - пунктирная линия, использующаяся для изображения связей между единицами работ (UOW), а также между единицами работ и объектами ссылок.
Потоки объектов (Object Flow) - стрелка с двумя наконечниками, применяется для описания того факта, что объект используется в двух или более единицах работы, например когда объект порождается в одной работе и используется в другой.
Старшая связь и поток объектов. Старшая связь показывает, что работа-источник заканчивается ранее, чем начинается работа-цель. Часто результатом работы-источника становится объект, необходимый для запуска работы-цели. В этом случае стрелку, обозначающую объект, изображают с двойным наконечником. Имя стрелки должно ясно идентифицировать отображаемый объект. Поток объектов имеет ту же семантику, что и старшая стрелка.
Отношение показывает, что стрелка является альтернативой старшей стрелке или потоку объектов в смысле задания последовательности выполнения работ - работа-источник не обязательно должна закончиться прежде, чем работа-цель начнется. Более того, работа-цель может закончиться прежде, чем закончится работа-источник (рис. 1.4.6).
Старт работы Окончание работы Старт работы- Окончание-источника -источника цели работы -цели Старшая или поток объектов
Старт работы Старт работы- Окончание работы Окончание -источника цели -источника работы-цели "" Отношение
Старт работы Старт работы- Отношение Окончание работы -источника цели работы-цели -источника Отношение
Рис. 1.4.6. Временная диаграмма выполнения работ
Перекрестки (Junction). Окончание одной работы может служить сигналом к началу нескольких работ, или же одна работа для своего запуска может ожидать окончания нескольких работ. Перекрестки используются для отображения логики взаимодействия стрелок при слиянии и разветвлении или для отображения множества событий, которые могут или должны завершены перед началом следующей работы. Различают перекрестки я слияния (Fan-in Junction) и разветвления (Fan-out Junction) стрелок. Перекресток не может использоваться одновременно для слияния и для «ветвления. Для внесения перекрестка служит кнопка Щ (добавить ^диаграмму перекресток - Junction) в палитре инструментов. В диалоге junction Type Editor необходимо указать тип перекрестка. Смысл каждого типа приведен в табл. 1.4.2.
Таблица 1.4.2. Типы перекрестков
Все перекрестки на диаграмме нумеруются, каждый номер имеет префикс J. Можно редактировать свойства перекрестка при помощи диалога Junction Properties (вызывается из контекстного меню). В отличие от IDEF0 и DFD в IDEF3 стрелки могут сливаться и разветвляться только через перекрестки. Рис. 1.4.7-1.4.11 иллюстрируют смысл перекрестков каждого типа.
Рис. 1.4.7. Перекрестки для слияния и разветвления типа синхронного "И". Здесь после завершения работы 1 одновременно запускаются работы 2 и 4. Для запуска работы 5 требуется одновременное завершение работ 3 и 4
Рис. 1.4.8. Перекрестки для слияния и разветвления типа асинхронного "И". Здесь после завершения работы 1 запускаются работы 2 и 4 (не обязательно одновременно). Для запуска работы 5 требуется завершение работ 3 и 4 (не обязательно одновременное)
Рис. 1.4.9. Перекрестки для слияния и разветвления типа асинхронного "ИЛИ". Здесь после завершения работы 1 запускается либо работа 2, либо работа 3, либо работа 4, либо их сочетание (не обязательно одновременно). Для запуска работы 5 требуется завершение любой из работ 2, 3 и 4 или их сочетания (не обязательно одновременное)
Рис. 1.4.10. Перекрестки для слияния и разветвления типа синхронного "ИЛИ". Здесь после завершения работы 1 запускается либо работа 2, либо работа 3, либо работа 4, либо их сочетание. Если запускается более одной работы, требуется их одновременный запуск. Для запуска работы 5 требуется завершение любой из работ 2, 3 и 4 или их сочетания. Если завершается более чем одна работа, требуется их одновременное завершение
Рис. 1.4.11. Перекрестки для слияния и разветвления типа исключающего "ИЛИ". Здесь после завершения работы 1 запускается только одна работа - либо работа 3, либо работа 4. Для запуска работы 5 требуется завершение только одной из работ, 3 или 4
Правила создания перекрестков. На одной диаграмме IDEF3 может быть создано несколько перекрестков различных типов. Определенные сочетания перекрестков для слияния и для разветвления могут приводить к логическим несоответствиям. Чтобы избежать конфликтов необходимо соблюдать следующие правила:
Каждому перекрестку для слияния должен предшествовать перекресток для разветвления.
Перекресток для слияния "И" не может следовать за перекрестком для разветвления типа синхронного или асинхронного "ИЛИ" (рис. 1.4.12).
Действительно, после работы 1 может запускаться только одна работа - 2 или 3, а для запуска работы 4 требуется окончание обеих работ - 2 и 3. Такой сценарий не может реализоваться.
Рис. 1.4.12. Неверное размещение перекрестков. Перекресток для слияния "И" не может следовать за перекрестком для разветвления "ИЛИ"
Перекресток для слияния "И" не может следовать за перекрестком для разветвления типа исключающего "ИЛИ" (рис. 1.4.13).
Рис. 1.4.13. Неверное размещение перекрестков. Перекресток для слияния "И" не может следовать за перекрестком для разветвления типа исключающего "ИЛИ"
4. Перекресток для слияния типа исключающего "ИЛИ" не может следовать за перекрестком для разветвления типа "И" (рис. 1.4.14). Здесь после завершения работы 1 запускаются обе работы - 2 и 3, а для запуска работы 4 требуется, чтобы завершилась одна и только одна работа -или 2, или 3.
Рис. 1.4.14. Неверное размещение перекрестков. Перекресток для слияния типа исключающего "ИЛИ" не может следовать за перекрестком для разветвления типа "И"
Перекресток, имеющий одну стрелку на одной стороне, должен иметь более одной стрелки на другой.
Объект ссылки. Объект ссылки в IDEF3 выражает некую идею, концепцию или данные, которые нельзя связать со стрелкой, перекрестком или работой (рис. 1.4.15). Для внесения объекта ссылки служит кнопка ШЗ (добавить в диаграмму объект ссылки - Referent) в палитре инструментов. Объект ссылки изображается в виде прямоугольника, похожего на прямоугольник работы. Имя объекта ссылки задается в диалоге Referent Properties (пункт контекстного меню Name), в качестве имени можно использовать имя какой-либо стрелки с других диаграмм или имя сущности из модели данных. Объекты ссылки должны быть связаны с единицами работ или перекрестками пунктирными линиями. Официальная спецификация IDEF3 различает три стиля объектов ссылок - безусловные (unconditional), синхронные (synchronous) и асинхронные (asynchronous). BPwin поддерживает только безусловные объекты ссылок. Синхронные и асинхронные объекты ссылок, используемые в диаграммах переходов состояний объектов, не поддерживаются.
При внесении объектов ссылок помимо имени следует указывать л объекта ссылки. Типы объектов ссылок приведены в табл. 1.4.3.
Таблица 1.4.3. Типы объектов ссылок
Декомпозиция работ. В IDEF3 декомпозиция используется для детализации работ. Методология IDEF3 позволяет декомпозировать работу многократно, т. е. работа может иметь множество дочерних работ. Это позволяет в одной модели описать альтернативные потоки. Декомпозиция может быть сценарием или описанием. Описание включает все возможные пути развития процесса. Сценарий является частным случаем описания и иллюстрирует только один путь реализации процесса. По умолчанию при декомпозиции на диаграмму IDEF3 создается описание. Чтобы создать сценарий, необходимо перейти в меню Diagram/Add IDEF3 Scenario.
Возможность множественной декомпозиции предъявляет дополнительные требования к нумерации работ. Так, номер работы состоит из номера родительской работы, номера декомпозиции и собственного номера работы на текущей диаграмме (рис. 1.4.16).
Рис. 1.4.16. Номер единицы работы (UOW)
Для описания номер декомпозиции равен 1. Для сценария номер декомпозиции всегда больше 1.
При создании сценария или описания необходимо придерживаться дополнительных ограничений - в сценарии или декомпозиции может существовать только одна точка входа. За точкой входа следует работа или перекресток. Для декомпозиции может существовать только одна точка выхода. Сценарий, который не является декомпозицией, может иметь несколько точек выхода.
Рассмотрим процесс декомпозиции диаграмм IDEF3, включающий взаимодействие автора (аналитика) и одного или нескольких экспертов предметной области.
Описание сценария, области и точки зрения. Перед проведением сеанса экспертизы у экспертов предметной области должны быть задокументированы сценарии и рамки модели для того, чтобы эксперт мог понять цели декомпозиции. Кроме того, если точка зрения моделирования отличается от точки зрения эксперта, она должна быть особенно тщательно задокументирована.
Возможно, что эксперт самостоятельно не сможет передать необходимую информацию. В этом случае аналитик должен приготовить список вопросов для проведения интервью.
Определение работ и объектов. Обычно эксперт предметной области передает аналитику текстовое описание сценария. В дополнение к этому может существовать документация, описывающая интересующие процессы. Из всей этой информации аналитик должен составить список кандидатов на работы (отглагольные существительные, обозначающие процесс, одиночные или в составе фразы) и кандидатов на объекты (существительные, обозначающие результат выполнения работы), которые необходимы для перечисленных в списке работ.
В некоторых случаях целесообразно создать графическую модель для представления ее эксперту предметной области. Графическая модель может быть также создана после сеанса сбора информации для того, чтобы детали форматирования диаграммы не смущали участников.
Поскольку разные фрагменты модели IDEF3 могут быть созданы разными группами аналитиков в разное время, IDEF3 поддерживает простую схему нумерации работ в рамках всей модели. Разные аналитики оперируют разными диапазонами номеров, работая при этом независимо. Пример выделения диапазона приведен в табл. 1.4.4.
Таблица 1.4.4. Диапазоны номеров работ
Последовательность и согласование. Если диаграмма создается после проведения интервью, аналитик должен принять некоторые решения, относящиеся к иерархии диаграмм, например сколько деталей включать в одну диаграмму. Если последовательность и согласование диаграмм неочевидны, может быть проведена еще одна экспертиза для детализации и уточнения информации. Важно различать подразумевающее согласование (согласование, которое подразумевается в отсутствие связей) и ясное согласование (согласование, ясно изложенное в мнении эксперта).
Работы, перекрестки и документирование объектов. IDEF3 позволяет внести информацию в модель различными способами. Например, логика взаимодействия может быть отображена графически в виде комбинации перекрестков. Та же информация может быть отображена в виде объекта ссылки типа ELAB (Elaboration). Это позволяет аналитику вносить информацию в удобном в данный момент времени виде. Важно учитывать, что модели могут быть реорганизованы, например для их представления в более презентабельном виде. Выбор формата для презентации часто имеет важное значение для организации модели, поскольку комбинация перекрестков занимает значительное место на диаграмме и использование иерархии перекрестков затрудняет расположение работ на диаграмме.
Из книги C++ автора Хилл Мюррей1.4.9 Описания Описание – это оператор, вводящий имя в программе. Оно может также инициализировать объект с этим именем. Выполнение описания означает, что когда поток управления доходит до описания, вычисляется инициализирующее выражение (инициализатор) и производится
Из книги Справочное руководство по C++ автора Страустрап Бьярн2.1 Описания Прежде чем имя (идентификатор) может быть использовано в С++ программе, он должно быть описано. Это значит, что надо задать его тип, чтобы сообщить компилятору, к какого вида сущностям относится имя. Вот несколько примеров, иллюстрирующих разнообразие
Из книги Практика и проблематика моделирования бизнес-процессов автора Всяких Е И8. Описания Описания используются для определения интерпретации, дваемой каждому идентификатору. Они не обязательно резервируют память, связанную с идентификатором. Описания имеют вид:описание: спецификаторы_описания opt список_описателей opt ; описание_имени
Из книги BPwin и Erwin. CASE-средства для разработки информационных систем автора8.5 Описания Классов Класс есть тип. Его имя становится typedef-имя (см. #8.8), которое может быть использовано даже внутри самого спецификатора класса. Объекты класса состоят из последовтельности членов.спецификатор_класса: заголовок_класса (* список_членов opt *) заголовок_класса
Из книги Моделирование бизнес-процессов с BPwin 4.0 автора Маклаков Сергей Владимирович8.10 Описания Перечислений Перечисления являются типами int с именованными констатами.enum_спецификатор: enum идентификатор opt (* enum_список *)enum_список: перечислитель enum_список, перечислительперечислитель: идентификатор идентификатор = константное_выражениеИдентификаторы в
Из книги Firebird РУКОВОДСТВО РАЗРАБОТЧИКА БАЗ ДАННЫХ автора Борри Хелен14.2 Описания описание: спецификаторы_описания opt список_описателей opt ; описание_имени asm-описаниеописание_имени: сост идентификатор; enum идентификатор;сост:class struct unionasm-описание: asm (строка) ;спецификаторы_описания: спецификатор_описания спецификаторы_описания
Из книги автораR.17.5 Описания класса спецификация-класса: заголовок-класса { список-членов opt }заголовок-класса: служебное-слово-класса идентификатор opt спец-базовых opt служебное-слово-класса имя-класса спец-базовых optслужебное-слово-класса: class struct unionсписок-членов: описание-члена
Из книги автора Из книги автора1.5. Дополнение созданной модели процессов диаграммами DFD и Workflow (IDEF3) 1.5.1. Диаграммы потоков данных (Data Flow Diagramming) Диаграммы потоков данных (Data flow diagramming, DFD) используются для описания документооборота и обработки информации. Подобно IDEF0, DFD представляет модельную систему как
Из книги автора1.4. Дополнение созданной модели процессов организационными диаграммами, диаграммами DFD и Workflow (IDEF3) 1.4.1. Диаграммы потоков данных (Data Flow Diagramming) Диаграммы потоков данных (Data flow diagramming, DFD) используются для описания документооборота и обработки информации. Подобно IDEF0, DFD
Из книги автора1.4.2. Метод описания процессов IDEF3 Наличие в диаграммах DFD элементов для описания источников, приемников и хранилищ данных позволяет более эффективно и наглядно описать процесс документооборота. Однако для описания логики взаимодействия информационных потоков более
Из книги автора4.14.4. Модификация диаграммы IDEF3 "Сборка продукта" с целью отображения новой информации Так же как в модели AS-IS, сборка продукта состоит из сборки компонентов и установки программного обеспечения. Однако теперь в работу "Сборка продукта" включена работа "Тестирование
Из книги автораСтруктурные описания Метаданные- физические описания таблиц, их столбцов и атрибутов, так же как и описания всех других объектов - сами хранятся в обычных таблицах Firebird внутри базы данных. Сервер Firebird изменяет данные в этих таблицах, когда объекты базы данных создаются,
Модель в нотации IDEF0 позволяет получить общее представление о функциях , выполняемых моделируемой системой, и связях между функциями, действиями.
Модель в нотации IDEF3 позволяет проследить логику взаимодействия процессов, функций . Техника IDEF3 является частью структурного анализа.
Можно сначала построить функциональную модель в нотации IDEF0, проведя исследования предметной области. Затем, используя полученные знания о предметной области, построить отдельную модель в нотации IDEF3.
А можно создать смешанную модель , дополняя по мере необходимости функциональную модель в нотации IDEF0 диаграммами в нотации IDEF3. Также можно дополнять модель DFD диаграммами в нотации IDEF3.
В каждом конкретном случае моделирования системы принимается решение о необходимости построения каждого вида модели.
Основная цель нотации IDEF3 — дать аналитикам возможность описать ситуацию , когда процессы (действия) выполняются в определенной последовательности, а также описать объекты , участвующие совместно в одном процессе.
В отличие от IDEF0 нотация IDEF3 не ограничивает автора модели (аналитика) чрезмерно жесткими рамками синтаксиса и семантики, что удобно для описания неполных или не целостных систем, особенно если аналитик плохо знает предметную область. Но нужно иметь в виду, что модель может получиться неполной или противоречивой.
Основной организационной единицей описания в IDEF3 является диаграмма .
Важна взаимная организация диаграмм внутри модели, также важно правильно построить каждую из диаграмм, поскольку они предназначены для чтения другими людьми (а не только автором). В целом методика построения модели, рекомендации по построению диаграмм аналогичны тем, которые применяются при моделировании в нотации IDEF0.
Как и при моделировании в нотации IDEF0 сначала опрашиваются эксперты предметной области, определяется цель моделирования — набор вопросов, на которые будет отвечать модель, точка зрения , границы моделирования , с учетом глубины и широты — какие объекты войдут, а какие не будут отображены в модели.
При изучении предметной области составляются списки кандидатов на действия (работы) , составляющих процесс, и кандидатов на объекты , участвующих в процессе, обозначающих результат выполнения работ.
Рассмотрим основные символы .
Единица или работа, действие
В IDEF3 действия изображаются прямоугольниками с прямыми углами (рис. 9.1). Действия имеют имя , выраженное отглагольным существительным или глаголом , одиночным или в составе фразы с другим именем существительным, обычно отображающим основной выход (результат) работы, например , "Создание файла". Все действия должны быть названы и определены.
Рис. 9.1. Символ действие в IDEF3
Каждому действию присваивается уникальный номер (идентификатор ), который никогда не меняется. В отличие от имени действия, которое в процессе уточнения и редактирования модели может меняться. Даже если действие будет удалено, его идентификатор не должен вновь использоваться для других действий. Обычно номер действия состоит из номера родительского действия и порядкового номера на текущей диаграмме.
Нотация IDEF3 позволяет декомпозировать (детализировать) действие много- кратно, т.е. включить в одну модель альтернативные описания процессов. Поэтому в номере действия стоит и порядковый номер декомпозиции родительского действия (рис. 9.1).
Действия имеют входы и выходы , но не поддерживают управления и механизмы, как функции в нотации IDEF0.
Связи
Связи показывают существенные взаимоотношения между действиями. Все связи в IDEF3 однонаправлены, могут начинаться и заканчиваться на любой стороне блока. Обычно диаграммы IDEF3 стараются построить так, чтобы связи были направлены слева направо, сверху вниз .
В IDEF3 различают три типа стрелок , изображающих связи(табл. 9.1).
Таблица 9.1
Типы связей
Изображение |
Название |
Назначение |
Временное предшествование |
Сплошная стрелка, связывающая единицы работ. Показывает, что работа-источник должна полностью закончиться прежде, чем работа-цель начнется. Во многих случаях завершение одного действия инициирует начало выполнения дру-гого. Связь именуют так, чтобы была понятна причина ее появления. Например, прежде чем найти вхождение текста в документе, необходимо его ввести (рис. 9.2). Временная шкала выполнения действий показана на рис. 9.3. Вертикальными линиями показано начало и окончание действий. Время окончания А1.1.1 и время начала А1.1.2 может совпадать, может не совпадать |
|
Объектный поток |
Стрелка с двумя наконечниками. Применяется для описания того, что результатом выполнения исходного действия является некоторый объект , который необходим для выполнения конечного действия. Временная семантика объектных связей аналогична связям предшествования. Связь именуют так, чтобы четко определить передающийся объект. Например, файл является результатом выполнения действия А1.1.3 (рис. 9.4) |
|
Нечеткое отношение |
Пунктирная линия. Используется, когда невозможно описать связи с использованием предшественных или объектных связей. Значение такой связи должно быть четко определено с помощью названия и описания стрелки, так как связи такого типа сами по себе не предполагают никаких ограничений. Применение нечетких отношений: отображение задержки между действиями; отображение взаимоотношений между параллельно выполняющимися действиями. На рис. 9.5 показано нечеткое отношение между действиями "Вывод пользователю сообщения об ошибке" и "Обработка ошибки" |
Рис. 9.2. Связь "временное предшествование" между действиями А1.1.1 и А1.1.2
Рис. 9.3. Временная шкала выполнения действий для рис. 9.2
Рис. 9.4. Объектная связь между действиями А1.1.3 и А1.1.4
Рис. 9.5. Связь "нечеткое отношение"
Нечеткое отношение является альтернативой временному предшествованию и объектному потоку в смысле задания последовательности выполнения работ — работа-источник не обязательно должна закончиться, прежде чем работа-цель начнется. Более того, работа-цель может закончиться прежде, чем закончится работа-источник.
Рассмотрим пример нечеткого отношения (рис. 9.6), альтернативного предшественной связи, приведенной на рис. 9.2.
Рис. 9.6. Альтернативная связь предшествования
В этом примере в соответствии с порядком действий, показанным на рис. 9.7, поиск вхождения текста в документе начинается по мере ввода текста, т.е. до непосредственного окончания ввода текста. Данный вид поиска используется в справочных системах.
Рис. 9.7. Альтернативная временная шкала выполнения действий для рис. 9.6
Необходимо четко документировать временные ограничения между действиями, соединенными нечетким отношением.
Рассмотрим другую возможную временную шкалу для того же примера нечеткого отношения (рис. 9.8).
Рис. 9.8. Вариант альтернативной временной шкалы для рис. 9.6
В этом случае поиск вхождения текста будет начат после получения первых букв искомого текста, но закончится до того, как все буквы будут введены, это означает, что поиск будет выполнен неверно.
Оба варианта альтернативной временной шкалы могут иметь место, поэтому корректная интерпретация нечеткого отношения должна быть документирована в модели.
Соединения или перекрестки (Junction)
Окончание одного действия может служить сигналом к началу нескольких действий, или же одно действие для своего запуска может ожидать окончания нескольких действий.
Перекрестки используются для отображения логики взаимодействия стрелок при слиянии и разветвлении . В табл. 9.2 приведены возможные типы перекрестков.
В отличие от IDEF0 и DFD в IDEF3 стрелки могут сливаться и разветвляться только через перекрестки .
Различают перекрестки для слияния и разветвления стрелок. Перекресток не может использоваться одновременно для слияния и для разветвления.
Различают синхронные и асинхронные соединения . Используются для изображения соответственно синхронных действий, т.е. начинающихся и заканчивающихся одновременно, и для изображения асинхронных действий.
Все перекрестки на диаграмме нумеруются, каждый номер имеет префикс J .
Таблица 9.2
Типы перекрестков
Обо-значение |
Наименование |
Смысл в случае слияния стрелок (сворачивающее соединение) |
Смысл в случае разветвления стрелок (разворачивающее соединение) |
Асинхронное соединение "И" |
Все предшествующие работы должны быть обязательно завершены, прежде чем начнется выполнение следующей работы |
Все следующие работы должны быть обязательно запущены |
|
Синхронное соединение "И" |
Все предшествующие работы должны быть завершены одновременно |
Все следующие работы должны быть запущены одновременно |
|
Асинхронное соединение "ИЛИ" |
Одна или несколько предшествующих работ должны быть завершены |
Одна или несколько следующих работ должны быть запущены |
|
Синхронное соединение "ИЛИ" |
Одна или несколько предшествующих работ должны быть завершены одновременно |
Одна или несколько следующих работ должны быть запущены одновременно |
|
Соединение "эксклюзивное "ИЛИ" |
Только одна предшествующая работа должна быть завершена, прежде чем сможет начаться следующая работа |
Только одна следующая работа должна быть запущена |
Если правила активизации соединения известны, они обязательно должны быть документированы либо в его описании, либо названием стрелок, исходящих из разворачивающего соединения или входящих в сворачивающее соединение.
В примере на рис.
9.9 выполняется ввод параметров окружности с клавиатуры, если пользователь использует клавиатуру, указание параметров с помощью мыши — при использовании мыши. И то, и другое действие выполняются при частичном вводе параметров, как с клавиатуры, так и при помощи мыши. Подобное описание вносится в свойства перекрестка.
Парность соединений . Все соединения на диаграммах должны быть парными, т.е. любое разворачивающее соединение должно иметь парное себе сворачивающее соединение, хотя типы соединений не обязательно должны совпадать. На рис. 9.10, а разворачивающее соединение "И" имеет парное сворачивающее соединение "ИЛИ".
Однако если нет необходимости строго придерживаться нотации IDEF3 при построении диаграмм, то в них могут присутствовать и фрагменты, показанные на рис. 9.10, б - в .
Синхронное разворачивающее соединение не обязательно должно иметь парное себе синхронное сворачивающее соединение, так как начинающиеся одновременно действия вовсе не должны оканчиваться одновременно. Также возможны ситуации синхронного окончания асинхронно начавшихся действий.
Рис. 9.9. Пример использования соединения "ИЛИ"
Комбинации соединений . Соединения могут комбинироваться для создания более сложных ветвлений (рис. 9.11, 9.12). Комбинации соединений следует использовать с осторожностью, так как перегруженные ветвлением диаграммы сложны для восприятия.
Рис. 9.10. Фрагменты диаграмм в нотации IDEF3
Рис. 9.12. Вариант диаграммы декомпозиции действия "Редактирование изображений с помощью примитивов"
в модели "Деятельность пользователя ПЭВМ при работе с графическими изображениями" в нотации IDEF3
На рис. 9.11 показано важное для данной модели отношение между действием "Копирование файла" и объектом "Содержимое дисков".
Объект ссылки изображается в виде прямоугольника , похожего на прямоугольник работы. В качестве имени можно использовать имя какой-либо стрелки, процесса, действия с других диаграмм или имя сущности из модели данных.
Кроме имени следует указывать тип объекта ссылки (табл. 9.3).
Таблица 9.3
Типы объектов ссылок
Цель описания |
|
Описывает участие важного объекта в действии |
|
Инструмент циклического перехода (в повторяющейся последовательности действий), переход возможен как на действие текущей диаграммы, так и на действие любой другой, но не обязательно. Если все действия цикла присутствуют на текущей диаграмме, цикл может также изображаться стрелкой, возвращающейся на стартовое действие. ССЫЛКА может ссылаться и на перекресток |
|
ЕДИНИЦА ДЕЙСТВИЯ |
Применяется для многократного отображения на диаграмме одного и того же действия, т.е. действия, которое используется в процессе несколько раз, но не в цикле. В этом случае в первый раз действие создается как единица работы, а последующие его появления на диаграмме оформляются объектами ЕДИНИЦА ДЕЙСТВИЯ |
Используется для документирования важной информации общего характера, относящейся к изображенному на диаграмме. ЗАМЕТКА является альтернативой внесению текстового объекта в диаграмму |
|
УТОЧНЕНИЕ |
Используется для уточнения или более детального описания изображенного на диаграмме. Обычно употребляется для детального описания логики ветвления у соединений |
В нотации IDEF3 информация в модель может вноситься различными способами. Это позволяет аналитику отображать информацию в удобном в данный момент виде.
Например, логика взаимодействия единиц работ может быть отображена графически в виде комбинации перекрестков, что может занять значительное место на диаграмме, затруднит расположение работ. Поэтому та же информация может быть отображена в виде объекта ссылки УТОЧНЕНИЕ.
Сеансы экспертизы
Сеансы экспертизы проводятся после каждого сеанса декомпозиции. Найденные несоответствия исправляются, и только после прохождения экспертизы без замечаний приступают к следующему сеансу декомпозиции.
IDEF3 - способ описания процессов с использованием структурированного метода, позволяющего эксперту в предметной области представить положение вещей как упорядоченную последовательность событий с одновременным описанием объектов, имеющих непосредственное отношение к процессу.
IDEF3 является технологией, хорошо приспособленной для сбора данных, требующихся для проведения структурного анализа системы.
В отличие от большинства технологий моделирования бизнес-процессов, IDEF3 не имеет жестких синтаксических или семантических ограничений, делающих неудобным описание неполных или нецелостных систем. Кроме того, автор модели (системный аналитик) избавлен от необходимости смешивать свои собственные предположения о функционировании системы с экспертными утверждениями в целях заполнения пробелов в описании предметной области. На рис. 3.1 изображен пример описания процесса с использованием методологии IDEF3 .
IDEF3 также может быть использован как метод проектирования бизнес-процессов. IDEF3-моделирование органично дополняет традиционное моделирование с использованием стандарта методологии IDEF0 . В настоящее время оно получает все большее распространение как вполне жизнеспособный путь построения моделей проектируемых систем для дальнейшего анализа имитационными методами. Имитационное тестирование часто используют для оценки эксплуатационных качеств разрабатываемой системы. Более подробно методы имитационного анализа будут рассмотрены ниже.
Рис.3.1 Описание процесса в методологии IDEF3
Синтаксис и семантика моделей IDEF3
Основой модели IDEF3 служит так называемый сценарий бизнес-процесса, который выделяет последовательность действий или подпроцессов анализируемой системы. Поскольку сценарий определяет назначение и границы модели, довольно важным является подбор подходящего наименования для обозначения действий. Для подбора необходимого имени применяются стандартные рекомендации по предпочтительному использованию глаголов и отглагольных существительных, например «обработать заказ клиента» или «применить новый дизайн».
Сценарий для большинства моделей должен быть документирован. Обычно это название набора должностных обязанностей человека, являющегося источником информации о моделируемом процессе.
Также важным для системного аналитика является понимание цели моделирования - набора вопросов, ответами на которые будет служить модель, границ моделирования - какие части системы войдут, а какие не будут отображены в модели, и целевой аудитории - для кого разрабатывается модель.
Диаграммы
Как и в любой рассматриваемой в этой книге технологии моделирования действий, главной организационной единицей модели IDEF3 является диаграмма. Взаимная организация диаграмм внутри модели IDEF3 особенно важна в случае, когда модель заведомо создается для последующего опубликования или рецензирования, что является вполне обычной практикой при проектировании новых систем. В этом случае системный аналитик должен позаботиться о таком информационном наполнении диаграмм, чтобы каждая из них была самодостаточной и в то же время понятной пользователю.
Единица работы. Действие
Аналогично другим технологиям моделирования действие, или в терминах IDEF3 «единица работы» (Unit of Work - UOW), - другой важный компонент модели. Диаграммы IDEF3 отображают действие в виде прямоугольника. Как уже отмечалось, действия именуются с использованием глаголов или отглагольных существительных, каждому из действий присваивается уникальный идентификационный номер. Этот номер не используется вновь даже в том случае, если в процессе построения модели действие удаляется. В диаграммах IDEF3 номер действия обычно предваряется номером его родителя (рис. 3.2)
Рис. 3.2. Изображение и нумерация действия в диаграмме IDEF3
Связи
Связи выделяют существенные взаимоотношения между действиями. Все связи в IDEF3 являются однонаправленными, и хотя стрелка может начинаться или заканчиваться на любой стороне блока, обозначающего действие, диаграммы IDEF3 обычно организуются слева направо таким образом, что стрелки начинаются на правой и заканчиваются на левой стороне блоков. В табл. 3.1 приведены три возможных типа связей.
Связь типа «временное предшествование» . Как видно из названия, связи этого типа показывают, что исходное действие должно полностью завершиться, прежде чем начнется выполнение конечного действия. Связь должна быть поименована таким образом, чтобы человеку, просматривающему модель, была понятна причина ее появления. Во многих случаях завершение одного действия инициирует начало выполнения другого, как показано на рис. 3.3. В этом примере автор должен принять рекомендации рецензентов, прежде чем начать вносить соответствующие изменения в работу.
Изображение |
Название |
Назначение |
Временнбе предшествование (Temporal precedence) |
Исходное действие должно завершиться, прежде чем конечное действие сможет начаться |
|
Объектный поток (Object flow) |
Выход исходного действия является входом конечного действия. Из этого, в частности, следует, что исходное действие должно завершиться, прежде чем конечное действие сможет начаться |
|
Нечеткое отношение (Relationship) |
Вид взаимодействия между исходным и конечным действиями задается аналитиком отдельно для каждого случая использования такого отношения |
Таблица 2.1
Рис. 3.3. Связь типа “временное предшествование” между действиями 1 и 2.
Связь типа «объектный поток» . Одна из наиболее часто встречающихся причин использования связи типа «объектный поток» заключается в том, что некоторый объект, являющийся результатом выполнения исходного действия, необходим для выполнения конечного действия. Обозначение такой связи отличается от связи временного предшествования двойной стрелкой. Наименования потоковых связей должны четко идентифицировать объект, который передается с их помощью. Временная семантика объектных связей аналогична связям предшествования, это означает, что порождающее объектную связь исходное действие должно завершиться, прежде чем конечное действие может начать выполняться.
Связь типа «нечеткое отношение». Связи этого типа используются для выделения отношений между действиями, которые невозможно описать с использованием предшественных или объектных связей. Значение каждой такой связи должно быть определено, поскольку связи типа «нечеткое отношение» сами по себе не предполагают никаких ограничений. Одно из применений нечетких отношений - отображение взаимоотношений между параллельно выполняющимися действиями. Наиболее часто нечеткие отношения используются для описания специальных случаев связей предшествования, например для описания альтернативных вариантов временного предшествования.
Соединения
Завершение одного действия может инициировать начало выполнения сразу нескольких других действий или, наоборот, определенное действие может требовать завершения нескольких других действий до начала своего выполнения. Соединения разбивают или соединяют внутренние потоки и используются для описания ветвления процесса:
- разворачивающие соединения используются для разбиения потока. Завершение одного действия вызывает начало выполнения нескольких других;
- сворачивающие соединения объединяют потоки. Завершение одного или нескольких действий вызывает начало выполнения другого действия.
В табл. 2.2 объединены три типа соединений .
Графическое обозначение |
Название |
Правила инициации |
|
Соединение «и» |
Разворачивающее |
Каждое конечное действие обязательно инициируется |
|
Сворачивающее |
Каждое исходное действие обязательно должно завершиться |
||
Соединение «эксклюзивное "или"» |
Разворачивающее |
Одно и только одно конечное действие инициируется |
|
Сворачивающее |
Одно и только одно исходное действие должно завершиться |
||
Соединение «или» |
Разворачивающее |
Одно или несколько конечных действий инициируются |
|
Сворачивающее |
Одно или несколько исходных действий должны завершиться |
Таблица 3.2
Примеры разворачивающих и сворачивающих соединений приведены на рис. 3.4
Рис. 3.4 Два вида соединений
«И»-соединения. Соединения этого типа инициируют выполнение конечных действий. Все действия, присоединенные к сворачивающему «и»-соединению, должны завершиться, прежде чем начнется выполнение следующего действия. На рис. 3.5 после обнаружения
Рис. 3.5 “И” – cоединения
пожара инициируются включение пожарной сигнализации, вызов пожарной охраны, и начинается тушение пожара. Запись в журнал производится только тогда, когда все три перечисленных действия завершены.
Соединение «эксклюзивное "или "». Вне зависимости от количества действий, связанных со сворачивающим или разворачивающим соединением «эксклюзивное «или», инициировано будет только одно из них, и поэтому только оно будет завершено перед тем, как любое действие, следующее за сворачивающим соединением «эксклюзивное «или», сможет начаться. Если правила активации соединения известны, они обязательно должны быть документированы либо в его описании, либо пометкой стрелок, исходящих из разворачивающего соединения, как показано на рис. 3.6
На рис. 3.6 соединение «эксклюзивное «или» используется для отображения того факта, что студент не может одновременно быть направлен на лекции по двум разным курсам.
Рис. 3.6 Соединение «эксклюзивное “или” »
Соединение «или» предназначено для описания ситуаций, которые не могут быть описаны двумя предыдущими типами соединений. Аналогично связи нечеткого отношения соединение «или» в основном определяется и описывается непосредственно системным аналитиком.
Указатели
Указатели - это специальные символы, которые ссылаются на другие разделы описания процесса. Они используются при построении диаграммы для привлечения внимания пользователя к каким-либо важным аспектам модели.
Указатель изображается на диаграмме в виде прямоугольника, похожего на изображение действия. Имя указателя обычно включает его тип (например, ОБЪЕКТ, UOB и т.п.) и идентификатор (табл. 3.3).
Тип указателя |
Назначение |
ОБЪЕКТ (OBJECT) |
Для описания того, что в действии принимает участие какой-либо заслуживающий отдельного внимания объект |
Для реализации цикличности выполнения действий. Указатель ССЫЛКА может относиться и к соединению |
|
ЕДИНИЦА ДЕЙСТВИЯ (Unit of Behavior - UOB) |
Для многократного отображения на диаграмме одного и того же действия. Например, если действие «Подсчет наличных» выполняется несколько раз, в первый раз оно создается как действие, а последующие его появления на диаграмме оформляются указателями UOB |
ЗАМЕТКА (NOTE) |
Для документирования любой важной информации общего характера, относящейся к изображенному на диаграммах. В этом смысле ССЫЛКА служит альтернативой методу помещения текстовых заметок непосредственно на диаграммах |
УТОЧНЕНИЕ (Elaboration - ELAB) |
Для уточнения или более подробного описания изображенного на диаграмме. Указатель УТОЧНЕНИЕ обычно используется для описания логики ветвления у соединений |
Таблица 3.3
Декомпозиция действий
Действия в IDEF3 могут быть декомпозированы или разложены на составляющие для более детального анализа. Метод IDEF3 позволяет декомпозировать действие несколько раз, что обеспечивает документирование альтернативных потоков процесса в одной модели.
Для корректной идентификации действий в модели с множественными декомпозициями схема нумерации действий расширяется и наряду с номерами действия и его родителя включает в себя порядковый номер декомпозиции. Например, в номере действия 1.2.5: 1 - номер родительского действия, 2 - номер декомпозиции, 5 - номер действия.
Требования IDEF3 к описанию бизнес-процессов
В этом разделе мы рассмотрим построение IDEF3-диаграммы на основании выраженного в текстовом виде описания процесса. Предполагается, что в построении диаграммы принимают участие ее автор (в основном как системный аналитик) и один или несколько экспертов предметной области, представляющие описание процесса.
Определение сценария, границ моделирования, точки зрения
Для экспертов предметной области, подготавливающих описание моделируемого процесса, должны быть документированы границы моделирования, чтобы им была понятна необходимая глубина и полнота требуемого от них описания. Кроме того, если точка зрения аналитика на процесс отличается от точки зрения эксперта, это должно быть ясно и подробно обосновано.
Вполне возможно, что эксперты не смогут сделать приемлемое описание без их формального опроса автором модели. В таком случае автор должен заранее подготовить перечень вопросов таким же образом, как журналист для интервью.
Определение действий и объектов
Результатом работы экспертов обычно является текстовый документ, описывающий интересующий аналитика круг вопросов. В дополнение к нему может прилагаться письменная документация, позволяющая определить природу изучаемого процесса. Вне зависимости от того, является ли информация текстовой или вербальной, она анализируется и разделяется частями речи для идентификации списка действий (глаголы и отглагольные существительные), составляющих процесс, и объектов (имена существительные), участвующих в процессе.
В некоторых случаях возможно создание графической модели процесса при участии экспертов. Такая модель может быть разработана после сбора всей необходимой информации, что позволяет не отнимать время экспертов на детали форматирования получающихся диаграмм.
Поскольку модели IDEF3 могут одновременно разрабатываться несколькими командами, IDEF3 поддерживает простую схему резервирования номеров действий в модели. Каждому аналитику выделяется уникальный диапазон номеров действий, что обеспечивает их независимость друг от друга. В табл. 3.4 номера действий выделяются каждому аналитику большими блоками. В этом примере аналитик 1 полностью использовал данный ему вначале диапазон номеров и дополнительно получил второй.
Таблица 3.4
Последовательность и параллельность
Если модель создается после проведения интервью, аналитик должен принять решение по построению иерархии участвующих в модели диаграмм, например, насколько подробно будет детализироваться каждая отдельно взятая диаграмма. Если последовательность или параллельность выполнения действий окончательно не ясна, эксперты могут быть опрошены вторично (возможно, с использованием черновых вариантов незаконченных диаграмм) для получения недостающей информации. Важно, однако, различать предполагаемую (появляющуюся из-за недостатка информации о связях) и явную (указанную в описании эксперта) неясности.
Выводы. IDEF3 - это способ описания бизнес-процессов, который нужен для описания положения вещей как упорядоченной последовательности событий с одновременным описанием объектов, имеющих непосредственное отношение к процессу. IDEF3 хорошо приспособлен для сбора данных, требующихся для проведения структурного анализа системы. Кроме того, IDEF3 применяется при проведении стоимостного анализа поведения моделируемой системы.
Стандарт IDEF0 является развитием классического DFD - подхода и предназначен для описания бизнес-процессов верхнего уровня. Для описания временной последовательности и алгоритмов выполнения работ стандарт IDEF0 не подходит. Для решения этой задачи стандарт IDEF0 получил дальнейшее развитие в результате чего был разработан стандарт IDEF3, который входит в семейство стандартов IDEF.
В IDEF3 декомпозиция используется для детализации работ. Методология IDEF3 позволяет декомпозировать работу многократно, т.е. работа может иметь множество дочерних работ. Это позволяет в одной модели описать альтернативные потоки. Возможность множественной декомпозиции предъявляет дополнительные требования к нумерации работ. Так, номер работы состоит из номера родительской работы, версии декомпозиции и собственного номера работы на текущей диаграмме.
Отличием стандарта IDEF3 от классической методологии WFD является также использование на схеме бизнес-процесса элемента «объект ссылки», который связывается с работами и перекрестками. С помощью объектов ссылки показывается прочая важная информация, которую целесообразно зафиксировать при описании бизнес-процесса.
IDEF3 предполагает построение двух типов моделей: 1) модель, отражающая некоторые процессы в их логической последовательности, позволяющая увидеть, как функционирует предприятие;
2) модель, показывающая «сеть переходных состояний объекта», предлагающая вниманию аналитика последовательность состояний, в которых может оказаться объект при прохождении через определенный процесс,
С помощью диаграмм IDEF3 можно анализировать сценарии из реальной жизни, например, как закрывать магазин в экстренных случаях или какие действия должны выполнить менеджер и продавец п ри закрытии. Каждый такой сценарий содержит в себе описание процесса и может быть использован, что бы наглядно показать или лучше задокументировать бизнес-функции предприятия.
В отличие от классической методологии WFD в стандарте IDEF3 связи между работами делятся на три типа, обозначения, названия и смыл которых, приведены на рис. 3.16.
Существуют два типа диаграмм в стандарте IDEF3, представляющих описание одного и того же сценария технологического процесса в разных ракурсах:
диаграммы Описания Последовательности Этапов Процесса (Process Flow Description Diagrams, PFDD);
диаграммы Состояния Объекта и его Трансформаций в Процессе (Object State Transition Network, OSTN).
Предположим, требуется описать процесс окраски детали в производственном цеху на предприятии. С помощью диаграмм PFDD документируется последовательность и описание стадий обработки де тали в рамках исследуемого технологического процесса. Диаграммы OSTN используются для иллюстрации трансформаций детали, кото рые происходят на каждой стадии обработки.
Графические средства IDEF 3 позволяют документировать вышеуказанный производственный процесс окраски детали. В целом, этот процесс состоит непосредственно из самой окраски, производимой на специальном оборудовании и этапа контроля ее качества, который определяет, нужно ли деталь окрасить заново (в случае несоответ ствия стандартам и выявления брака) или отправить ее в дальнейшую
обработку.
Стрелки или линии являются отображением перемещения детали между иОВ-блоками в ходе процесса. Линии бывают следующих видов:
Старшая (Precedence) - сплошная линия, связывающая UOB. Рисуется слева направо или сверху вниз;
Отношения (Relational Link) - пунктирная линия, использующаяся для изображения связей между UOB;
Потоки объектов (Object Flow) - стрелка с двумя наконечниками используется для описания того факта, что объект (деталь) используется в двух или более единицах работы, например, когда объект порождается в одной работе и используется в другой.
Объект, обозначенный J1 - называется перекрестком (Junction). Перекрестки используются для отображения логики взаимодействия стрелок (потоков) при слиянии и разветвлении или для отображения множества событий, которые могут или должны быть завершены перед началом следующей работы. Различают перекрестки для слияния (Fan-in Junction) и разветвления (Fan-out Junction) стрелок. Перекресток не может использоваться одновременно для слияния и для разветвления. При внесении перекрестка в диаграмму необходимо указать тип перекрестка.
Все перекрестки в PFDD диаграмме нумеруются, каждый номер имеет префикс «J».
Сценарий, отображаемый на диаграмме, молено описать в следующем виде: деталь поступает в окрасочный цех, подготовленной к окраске. В процессе окраски наносится один слой эмали при высокой температуре. После этого, производится сушка детали, после которой начинается этап проверки качества нанесенного слоя. Если тест подтверждает недостаточное качество нанесенного слоя (недостаточную толщину, неоднородность и т.д.), то деталь заново пропускается через цех окраски. Если деталь успешно проходит контроль качества, то она отправляется в следующий цех для дальнейшей обработки.
Каждый функциональный блок UOB может иметь последовательность декомпозиций, и, следовательно, может быть детализирован с любой необходимой точностью. Под декомпозицией мы понимаем представление каждого UOB с помощью отдельной IDEF3 Диаграммы.
Например, мы можем декомпозировать UOB «Окрасить Деталь», представив его отдельным процессом и построив для него свою PFDD диаграмму. При этом эта диаграмма будет называться дочерней, по отношению к изображенной на рис. 3.18, а та, соответственно родительской. Номера UOB дочерних диаграмм имеют сквозную нумерацию, т.е., если родительский UOB имеет номер «1», то блоки UOB на его декомпозиции будут соответственно иметь номера «1.1». «1.2» и т.д. Применение принципа декомпозиции в IDEF 3 позволяет структурировано описывать процессы с любым требуемым уровнем детализа ции.
Если диаграммы PFDD технологический процесс «С точки зрения наблюдателя», то другой класс диаграмм IDEF3 OSTN позволяет рассматривать тот же самый процесс «С точки зрения объекта». Состояния объекта (в нашем случае детали) и Изменение состояния являются ключевыми понятиями OSTN диаграммы. Состояния объекта отображаются окружностями, а их изменения направленными линиями. Каждая линия имеет ссылку на соответствующий функциональный блок UOB, в результате которого произошло отображаемое ей изменение состояния объекта.
Первой работой является «Обработка заявок». Эта работа использует два объекта ссылок - «Заказы клиентов» и «Склад» - причем на диаграмме они показаны без деталей, т.к. не являются центральными для данной диаграммы. Работа «Обработка заявок» требует выпол нения одной из двух работ -либо «Оформление документов», либо «Дооформление заявок» (в случае, если заявка неверно оформлена). Ра бота «Дооформление заявок» использует ссылочный объект «Клиенты». Работа «Оформление документов» передает управление на две параллельные работы: «Формирование партии» и «Составление отчетности», причем работа «Формирование партии» также обращается к ссылочному объекту «Заказы клиентов». Как видно, на диаграмме есть два перекрестка ветвления, перекре сток с ветвлением по логическому исключающему «ИЛИ», и перекре сток с ветвлением по «И», означающим выполнение двух работ парал лельно.
Методология ARIS
В настоящее время наблюдается тенденция интеграции разнообразных методов моделирования, проявляющаяся в форме создания интегрированных средств моделирования. Одним из таких средств является программный продукт, носящий название ARIS (Architecture of Integrated Information Systems), разработанный германской фирмой IDS Scheer.
ARIS поддерживает четыре типа моделей (и множество видов моделей в каждом типе), отражающих различные аспекты исследуемой системы:
организационные модели, представляющие структуру системы - иерархию организационных подразделений, должностей и конкретных лиц, связи между ними, а также территориальную привязку структурных подразделений;
функциональные модели, содержащие иерархию целей, стоящих перед аппаратом управления, с совокупностью деревьев функций, необходимых для достижения поставленных целей;
информационные модели, отражающие структуру информации, необходимой для реализации всей совокупности функций системы;
модели управления, представляющие комплексный взгляд на реализацию бизнес-процессов в рамках системы.
Для построения перечисленных типов моделей используются как собственные методы моделирования ARIS, так и различные извест-
ные методы и языки моделирования, в частности, UML. Процесс моделирования можно начинать с любого из типов моделей.
Основная бизнес-модель ARIS - еЕРС (extended Event-driven Process Chain, расширенная модель цепочки процессов, управляемых событиями). Нотация ARIS еЕРС является расширением нотации IDEF3. Бизнес-процесс в нотации еЕРС представляет собой поток последовательно выполняемых работ (процедур, функций), расположенных в порядке их выполнения. Реальная длительность выполнения процедур в еЕРС визуально не отражается. Для получения информации о реальной длительности процессов необходимо использовать другие инструменты описания, например, MS Project.
Модели в ARIS представляют собой диаграммы, элементами которых являются разнообразные объекты - «функции», «события», «структурные подразделения», «документы» и т.д. Между объектами определённых видов могут быть установлены связи определённых видов («выполняет», «принимает решение», «должен быть проинформирован о результатах» и т.д.). Каждому объекту соответствует определенный набор атрибутов, которые позволяют ввести дополнительную информацию о конкретном объекте.
Платформа ARIS является специализированным набором инструментов для структурированного описания и анализа бизнес-процессов. В состав системы входят функциональные модули для:
Проектирования и оптимизации бизнес-процессов (ARIS Easy Design, ARIS Toolset, ARIS Business Design, ARIS Business Architect, ARIS Business Server);
динамического анализа и оптимизации бизнес-процессов (ARIS Simulation);
разработки и внедрения системы менеджмента качества (ARIS Quality Management Scout);
мониторинга и контроля эффективности бизнес-процессов (ARIS Process Perfomance Manager);
управления процедурами, обеспечивающими работу системы внутреннего контроля за формированием финансовой отчетности (ARIS Audit manager):
разработки, внедрения и поддержания системы управления операционными рисками (ARIS Process Risk Scout);
создания системы попроцессного калькулирования - Activity based costing (ARIS Process Cost Analyzer);
Проектирования системы сбалансированных показателей (ARIS
В ARIS существует более 130 различных способов графического представления моделей деятельности предприятия. Пример моделирования в нотации ARIS представлен на рис. 3.20. и в Приложении Д.
Преимущества. ARIS-платформа обладает большим набором функций. В ней предусмотрена возможность анализа построенных моделей бизнес-процессов, определения «узких» мест и оптимизации бизнес-процессов на основе анализа «что-если». Иными словами, пользователь может изменять те или иные бизнес-процессы, к примеру, перераспределить полномочия сотрудников и оценить, насколько увеличится время на выполнение тех или иных операций или стоимость работ. Модуль ARIS Process Cost Analyzer позволяет реализовать традиционную методологию Activity based costing для определения стоимости бизнес-процессов, а результаты использовать в модуле стратегического управления предприятием (ARIS BSC). Применяя дополнительные модули и внутренний язык программирования, пользователь может сформировать любые регламенты и положения, а также управлять рисками компании, создать систему менеджмента качества и внутреннего контроля.
Недостатки. К недостаткам можно отнести достаточно высокую стоимость программного обеспечения. Графическое представление моделей бизнес-процессов достаточно сложное для восприятия неподготовленных пользователей. Надо также отметить, что для использования.
Например, ЕМ Tool Kit требуется пройти учебный курс длительно стью два-три дня, а для освоения основных функциональных возможностей ARIS придется посетить несколько специализированных учеб ных курсов продолжительностью от пяти до пятнадцати дней.
К недостаткам функционального плана можно отнести подходы к реализации методологии попроцессного калькулирования. В системе отсутствует возможность задания как элементарных, так и сложных драйверов действий, то есть нельзя использовать сложные схемы распределения затрат между продуктами, услугами, клиентами и заказами.
Оплата безналичным расчетом
Рис. 3.20 - Модель верхнего уровня взаимосвязи ЗАТ НКМЗ с внешней средой в нотации AR1S Express
Моделирование бизнес-процессов -это
эффективное средство поиска путей оптимизации деятельности предприятия, позволяющее определить, как оно работает в целом и как организована деятельность на каждом рабочем месте.
Целью моделирования является систе матизация знаний о предприятии и его биз нес-процессах в наглядной графической фор ме более удобной для аналитической обработки полученной информации.
Анализ бизнес-процессов предприятия с разных точек зрения называется аудитом бизнес-процессов. Он проводится после создания и описания модели предприятия.
Под методологией (нотацией) создания модели (описания) бизнес-процесса понимается совокупность способов, при помощи которых объекты реального мира и связи между ними представляются в виде модели.
Модель бизнес-процесса -прикладное представление (в заданной нотации) исполняемых предприятием работ.
Выделяют следующие модели бизнес-процесса разной направленности: верхнего уровня, алгоритмическую, потоковую, функциональную.
Методология -это совокупность методов применяемых в жизненном цикле разработки системы (бизнес-процесса) и объединенных одним общим философским подходом.
Описание бизнес-процесса может производиться в текстовой форме, табличной форме, в виде алгоритмических схем.
Совокупность специальных графических элементов определяет нотацию моделирования.
Методологии моделирования бизнес-процессов классифицируют по трем категориям: 1) Методологии ведения проекта; 2) Методологии использования программных продуктов для моделирования бизнес-процессов в проекте; 3) Методологии моделирования и анализа бизнес-процессов.
Методологии ведения проектов связаны с изменением бизнес-процессов, существующих на предприятиях.
Методологии моделирования и анализа бизнес-процессов определяют руководящие указания для оценки и выбора проекта разрабатываемого программного продукта, шаги работы, которые должны быть вы-
полиены, их последовательность, правила распределения и назначения операций и методов.
SADT ( Structured Analysis and Design Tecchnique ) - методология структурного анализа и проектирования, которая породила целый ряд методов IDEFx . завоевавших особую популярность в задачах инжини ринга и реинжиниринга бизнес - процессов.
IDEFO - метод функционального моделирования позволяющий опи сать бизнес-процесс в виде иерархической системы взаимосвязанных функций.
IDEF 3 - метод описания процессов, рассматривающий последовательность выполнения и причинно-следственные связи между ситуациями и событиями для структурного представления знаний о системе.
DFD ( Data Flow Diagrams ) - диаграммы потоков данных - методо логия структурного анализа, описывающая внешние по отношению к си стеме источники и адресаты данных, логические функции, потоки дан ных и хранилища данных к которым осуществляется доступ.
1. Калянов Г.Н. Моделирование, анализ, реорганизация и автоматизация бизнес- процессов [Текст]: учеб. пособие для студ. вузов, обучающихся по специальности 080801 «Прикладная информатика (по областям)» и др. экон. специальностям. - М. : Финансы и статистика, 2007. - 240с.
Сериков А.В., Титов Н.В., Белоцерковский А.В., Лобанов А.В., Успаленко В.И. Компьютерное моделирование бизнес-процессов [Текст]: учеб. пособие для студ. вузов / Харьковский гос. технический ун-т строительства и архитектуры. - X. : Бурун Книга, 2007. -303 с.
Щенников С. Ю. Реинжиниринг бизнес-процессов. Экспертное моделирование, управление, планирование и оценка [Текст]. - М.:Ось-89, 2004. -288 с.
Робсон Майк, Уллах Филип. Реинжиниринг бизнес-процессов [Текст]: Практическое руководство / Л.Е. Долгова (пер.). - М. : ЮНИТИ, 2003. - 222 с.
Репин В.В., Елиферов В.Г. Процессный подход к управлению. Моделирование бизнес-процессов [Текст]. - М.: РИА «Стандарты и качество», 2004. - 408 с
а Шеер Август-Вильгельм. Моделирование бизнес-процессов [Текст]. - М.: Весть-МетаТехнология, 2000. - 206 с.
7 Виноградова О.В. Реінжиніринг бізнес-процесів торговельних підприємств [Текст]: Монографія. - Донецьк: ДонДУЕТ, 2006.- 183 с.
Виноградова О.В. Реінжиніринг бізнес-процесів у сучасному менеджменті [Текст]: Монографія. - Донецьк: ДонДУЕТ, 2005. - 195 с.
Ойхман Е.Г. Реинжиниринг бизнеса [Текст]/ Е. - М.: Финансы и статистика, 1997. - 336с.
Ю.Марка Д. Методология структурного анализа и проектирования.
[Текст] / Марка Д. - пер. с англ. - М. Финансы и статистика. -
2003. -240 с. H.Draheim, D. Business process technology: a unified view on business
processes, workflows and enterprise applications / Dirk
Draheim. - Berlin: Springer, 2010. - 323 p. 12.Holt, J. A Pragmatic guide to business process modelling / Jon
Holt. - British Informatics Society Ltd, 2009. - 246 p. 13.Laguna, M. Business process modeling, simulation and design /
Manuel Laguna, Johan Marklund. - Prentice Hall, 2005. - 429 p.
/. Что представляет собой процесс моделирования бизнес-процессов?
Назовите цель моделирования бизнес-процессов.
Перечислите преимущества моделирования.
Что называется аудитом бизнес-процессов?
Перечислите причины, по которым принимается решение по моделированию бизнес-процессов.
6 Что представляет собой модель в целом? 7 Раскройте сущность модели бизнес-процесса.
8 В чем состоит сущность нотации бизнес-процессов?
9- Перечислите виды моделей, которые могут применяться в дея тельности предприятия. Раскройте их сущность.
10. В каких формах может производиться описание бизнес-процесса? В чем их преимущества и недостатки? П. Что представляет собой методология?
По каким признакам классифицируют методологии моделирования бизнес-процессов?
Раскройте сущность методологий ведения проектов.
Обоснуйте необходимость применения методологий использования программных продуктов для создания моделей бизнес-процессов.
В чем состоит сущность методологии моделирования и анализа бизнес-процессов?
Перечислите основные исторические этапы развития методологий.моделирования бизнес-процессов.
В чем состоит многообразие «проекций» предприятия?
SADT . Охарактеризуйте типы данных моделей.
Какие основные элементы используются в модели по SADT ?
Раскройте историю появления методологии IDEFO .
Какие основные понятия лежат в основе методологии IDEFO ? Раскройте их содержание.
Какие составляющие имеет функциональный блок?
Охарактеризуйте виды интерфейсных дуг.
В чем заключается сущность принципа декомпозиции и в каких случаях декомпозиция выполняется?
Для чего необходим глоссарий?
В каких случаях используются диаграммы потоков данных DFD (Data Flow Diagrams )?
Перечислите и раскройте сущность основных элементов DFD диаграмм.
Раскройте сущность методологии DFD в нотациях Гейна-Сарсона и Иордана-Де Марко. В чем их сходства и отличия?
Для каких целей был разработан стандарт IDEF 3?
Назовите основные отличия стандарта 1 DEF 3 от классической методологии WFD .
Какие два типа диаграмм используются в стандарте IDEF 3?
І.Что понимают под моделированием бизнес-процессов?
а) это комплексный инструмент поиска путей оптимизации деятельности предприятия, позволяющее определить, как оно работает в целом и как организована деятельность на каждом рабочем месте;
б) это эффективное средство поиска путей оптимизации деятель ности предприятия, позволяющее определить, как оно работает в целом и как организована деятельность на каждом рабочем месте;
в) это универсальное средство поиска путей оптимизации дея тельности предприятия, позволяющее определить, как оно ра ботает в целом и как организована деятельность на каждом ра бочем месте.
Отчетность