32. Использование стандартов idef0 и idef3 для описания бизнес процессов.

IDEF0 – Function Modeling – методология функционального моделирования и графическая нотация, предназначенная для формализации и описания бизнес-процессов.Данная модель используется при организации бизнес-проектов и проектов, основанных на моделировании всех процессов: как административных, так и организационных.Отличительной особенностью IDEF0 является её акцент на соподчинённость объектов.В IDEF0 рассматриваются логические отношения между работами, а не их временная последовательность (WorkFlow).Стандарт IDEF0 представляет организацию как набор функций, здесь сущест-вует правило – наиболее важная функция находится в верхнем левом углу, кроме того есть правило стороны:1стрелка входа приходит всегда в левую кромку активности,2стрелка управления – в верхнюю кромку,3стрелка механизма – нижняя кромка,4стрелка выхода – правая кромка. Описание выглядит как «чёрный ящик« с входами, выходами, управлением и механизмом, который постепенно детализируется (декомпозируется) до необходимого уровня.Для того чтобы быть правильно понятым, существуют словари описания активностей и стрелок. В этих словарях можно дать описания того, какой смысл вы вкладываете в данную активность либо стрелку.Отображаются все сигналы управления.

IDEF3 – Integrated DEFinition for Process Description Capture Method – мето

дология моделирования и стандарт документирования процессов, происходящих в системе.Метод документирования технологических процессов предоставляет меха-низм документирования и сбора информации о процессах.IDEF3 показывает причинно-следственные связи между ситуациями и событиями в понятной эксперту форме, используя структурный метод выражения знаний о том, как функционирует система, процесс или предприятие.IDEF3 широко применяется при разработке информационных систем. При этом используется инструмент визуального моделирования бизнес-процессов Система описывается как упорядоченная последовательность событий с одновременным описанием объектов, имеющих отношение к моделируемому процессу.IDEF3 состоит из двух методов (два типа диаграмм в IDEF3).Process Flow Description (PFD) – Описание технологических процессов, с указанием того, что происходит на каждом этапе технологического процесса.Object State Transition Description (OSTD) – описание переходов состояний объектов, с указанием того, какие существуют промежуточные состояния у объектов в моделируемой системе.

Основу методологии IDEF3 составляет графический язык описания процессов. Диаграмма IDEF3 Process Flow Description (описания процесса) может состоят из 4 основных описательных блоков:1работы (boxes, activities)

2стрелки или связи (arrows, links)3перекрёстки (junctions)4объекты ссылок

Unit of Behavior (единица поведения) Decomposition (декомпозиция) Elaboration (разработка)

33. Модель, как представление описываемой системы.

Результатом применения методологии SADT является модель, которая состоит из имеющих ссылки друг на друга:1диаграмм2фрагментов текстов3глоссария. Диаграммы – главные компоненты модели представлены как блоки (прямоугольники) и дуги (стрелки).1управляющая информация входит в блок сверху2информация, которая подвергается обработке, показана с левой стороны блока3результаты выхода показаны с правой стороны4механизм, ресурсы (человек или автоматизированная система), которые осуществляет операцию, представляется дугой, входящей в блок снизу. Модель является некоторым толкованием системы. Поэтому субъектом моделирования служит сама система. Однако моделируемая система никогда не существует изолированно: она всегда связана с окружающей средой. Причем зачастую трудно сказать, где кончается система и начинается среда. По этой причине в методологии SADT подчеркивается необходимость точного определения границ системы.

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

34.Принципы, цели и этапы SADT-моделирования.Принципы построения SADT-моделей1Используются как естественный, так и графический языки. 2Для передачи информации о конкретной системе источником:а)естественного языка служат люди, описывающие системуб)графического языка – сама методология SADT.Графический язык SADT организует естественный язык вполне определеннымоднозначным образом.1Необходимость точного определения границ системы. SADT-модель всегда ограничивает свой субъект, т.е. модель устанавливает точно, что является и что не является субъектом моделирования, описывая то, что входит в систему, и, подразумевая то, что лежит за ее пределами. Ограничивая субъект, SADT-модель помогает сконцентрировать внимание именно на описываемой системе и позволяет избежать включения посторонних субъектов.2На SADT-диаграммах не указаны явно ни последовательность, ни время. Цели моделиSADT-модель дает полное, точное и адекватное описание системы, имеющее конкретное назначение, которое называется целью модели и вытекает из формального определения модели в SADT:М есть модель системы S, если М может быть использована для получения ответов на вопросы относительно S с точностью А.Целью модели является получение ответов на некоторую совокупность вопросов.2Эти вопросы неявно присутствуют (подразумеваются) в процессе анализа и, следовательно, они руководят созданием модели и направляют его.3Это означает, что сама модель должна будет дать ответы на эти вопросы с заданной степенью точности.3Если модель отвечает не на все вопросы или ее ответы недостаточно точны, то мы говорим, что модель не достигла своей цели.4Определяя модель таким образом, SADT закладывает основы практического моделирования.

Этапы моделирования 1 Этап. Построение SADT-модели начинается с представления всей системы в виде простейшей компоненты - одного блока и дуг, изображающих интерфейсы с функциями вне системы.Этот единственный блок представляет всю систему как единое целое (имя, указанное в блоке, является общим).Это верно и для интерфейсных дуг – они также представляют полный набор внешних интерфейсов системы в целом. 2 Этап. Особенностью методологии SADT является постепенное введение все больших уровней детализации по мере создания диаграмм, отображающих модель.На следующем рис., где приведены четыре диаграммы и их взаимосвязи, показана структура SADT-модели.Каждый компонент модели может быть декомпозирован на другой диаграмме. Каждая диаграмма иллюстрирует «внутреннее строение» блока на родительской диаграмме.3 Этап. Блок, который представляет систему в качестве единого модуля,детализируется на другой диаграмме с помощью нескольких блоков, соединенных интерфейсными дугами (связями). Эти блоки представляют основные подфункции исходной функции. Данная декомпозиция выявляет полный набор подфункций, каждая из которых представлена как блок, границы которого определены интерфейсными дугами. Каждая из этих подфункций может быть декомпозирована подобным образом для более детального представления.

35.Графическое и текстовое описание SADT-моделиПростейшие описания0) Диаграммы – главные компоненты модели представлены как блоки (прямо-угольники, показывающие действие, функцию) и дуги (стрелки, показывающие свя-зи и движение информации).1)Обратные связи, итерации, продолжающиеся процессы и перекрывающиеся (по времени) функции могут быть изображены с помощью дуг (так как на SADT-диаграммах не указаны явно ни последовательность, ни время процесса).2)Обратные связи могут выступать в виде комментариев, замечаний, исправ-лений и т.д.Рис. Пример обратной связи3)Механизмы (дуги с нижней стороны блока) показывают ресурсы и средства, с помощью которых осуществляется выполнение функций. Механизм может быть человеком, компьютером или любым другим устройством, которое помогает выполнять данную функцию. Рис. Пример механизма4) Каждый блок на диаграмме имеет свой номер. Блок любой диаграммы может быть далее описан диаграммой нижнего уровня, которая, в свою очередь, может быть далее детализирована с помощью необходимого числа диаграмм. Таким образом, формируется иерархия диаграмм.Чтобы указать положение любой диаграммы или блока в иерархии, используются номера диаграмм. Например, А21 является диаграммой, которая детализирует блок 1 на диаграмме А2. Аналогично, А2 детализирует блок 2 на диаграмме А0, которая является самой верхней диаграммой модели.Рис. Иерархия диаграммТипы связей между функциями5) Важной является точная согласованность типов связей между функциями (блоками).Различают, по крайней мере, семь типов связывания:0)Тип случайной связности: наименее желательный.Случайная связность возникает, когда конкретная связь между функциями мала или полностью отсутствует. Это относится к ситуации, когда имена данных на SADT-дугах в одной диаграмме имеют малую связь друг с другом. Крайний вариант этого случая показан на следующем рисунке.

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

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

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

36. Принцип декомпозиции.Декомпозиция1процесс разделения сложного объекта, системы, экономического показателя, задачи на составные части, элементы; 2состояние объекта, системы, характеризуемое разделенностью на части. Принципы декомпозиции производственного объекта:1выделения в его составе подразделений с учетом выполнения требований минимального объема деятельности;2придания им определенных форм внутрипроизводственной специализации;3формирования вертикальной структуры подразделений по схеме «цех – участок – поточная линия – бригада»;4придания выделенным элементам статуса экономического субъекта или субъекта внутреннего предпринимательства;5формирования горизонтальных структур процессов (бизнес-процессов) на принципах инжиниринга;6создания необходимых подразделений материально-технического обеспечения.Сформированная структура специализированных подразделений и взаимосвязей между ними в процессе осуществления деятельности называется производственной структурой.Декомпозиция управляющего субъекта осуществляется на основе следующих принципов:

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

37. Функциональные блоки в модели IDEF0.IDEF0 – Function Modeling – методология функционального моделирования и графическая нотация, предназначенная для формализации и описания бизнес-процессов. Отличительной особенностью является её акцент на соподчинённость объектов. Рассматриваются логические отношения между работами, а не их временная последовательность (WorkFlow).Графический язык IDEF0 прост и гармоничен. В основе методологии лежат четыре основных понятия.1Функциональные блоки.2Интерфейсные дуги.3Диаграммы и декомпозиция.4Глоссарий.Функциональный блок (Activity Box) графически изображается в виде прямоугольника и олицетворяет конкретную функцию в рамках рассматриваемой системы.Название каждого функционального блока должно быть сформулировано в форме глагола (например, «производить услуги», а не «производство услуг»).Каждая из четырех сторон функционального блока имеет своё определенное значение (роль):1Верхняя сторона имеет значение «Управление» (Control);2Левая сторона имеет значение «Вход» (Input);3Правая сторона имеет значение «Выход» (Output);4Нижняя сторона имеет значение «Механизм» (Mechanism). Каждый функциональный блок в рамках единой рассматриваемой системы

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

38.Интерфейсные дуги в модели IDEF0.Интерфейсная дуга (потоки или стрелки) – Arrow отображает элемент системы, который обрабатывается функциональным блоком или оказывает иное влияние на функцию, отображенную данным функциональным блоком.Графическим отображением интерфейсной дуги является однонаправленная стрелка.Каждая интерфейсная дуга должна иметь свое уникальное наименовании(Arrow Label).Наименование должно быть оборотом существительного.С помощью дуг отображают объекты, определяющие процессы, происходящие в системе.Такими объектами могут быть:1элементы реального мира (детали, вагоны, сотрудники и т. д.)2или потоки данных и информации (документы, данные, инструкции и т.д.).В зависимости от того, к какой из сторон подходит данная интерфейсная дуга, она носит название «входящей», «исходящей» или «управляющей».«Источником» (началом) и «приемником» (концом) каждой функциональной дуги могут быть только функциональные блоки. Обязательное наличие управляющих интерфейсных дуг является одним из главных отличий стандарта IDEF0 от других методологий DFD (Data Flow Diagram) и WFD (Work Flow Diagram).

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

Рис.2 - Декомпозиция функционального блокаВзаимосвязь нумерации функциональных блоков и диаграмм – каждый блок имеет свой уникальный порядковый номер на диаграмме (цифра в правом нижнем углу прямоугольника), а обозначение под правым углом указывает на номер дочерней для этого блока диаграммы. Отсутствие этого обозначения говорит о том, что

декомпозиции для данного блока не существует.

40. Глоссарий в модели IDEF0.Глоссарий (Glossary). Для каждого из элементов IDEF0: диаграмм, функциональных блоков, интерфейсных дуг существующий стандарт подразумевает создание и поддержание набора соответствующих определений, ключевых слов, повествовательных изложений и т.д., которые характеризуют объект, отображенный данным элементом. Этот набор называется глоссарием и является описанием сущности данного элемента. Например, для управляющей интерфейсной дуги «распоряжение об оплате» глоссарий может содержать перечень полей соответствующего дуге документа, необходимый набор виз и т.д. Глоссарий гармонично дополняет наглядный графический язык, снабжая диаграммы необходимой дополнительной информацией.

41. Правила построения модели в стандарте IDEF0.1) Модель IDEF0 всегда начинается с представления системы как единого целого – одного функционального блока с интерфейсными дугами, простирающимися за пределы рассматриваемой области. Такая диаграмма называется контекстной диаграммой, и обозначается «А-0».в пояснительном тексте к контекстной диаграмме должны быть указаны:1цель (Purpose) построения диаграммы в виде краткого описания2и точка зрения (Viewpoint). Определение и формализация цели разработки IDEF0-модели определяет соответствующие области в исследуемой системе, на которых необходимо фокусироваться в первую очередь.Точка зрения определяет основное направление развития модели и уровеньнеобходимой детализации. Четкое фиксирование точки зрения позволяет разгрузить модель, отказавшись от детализации и исследования отдельных элементов, не являющихся необходимыми, исходя из выбранной точки зрения на систему. Правильный выбор точки зрения существенно сокращает временные затраты на построение конеч-ной модели.2) В процессе декомпозиции каждый функциональный блок подвергается детализации.

Получившаяся диаграмма второго уровня содержит функциональные блоки, отображающие главные подфункции функционального блока контекстной диаграммы и называется дочерней (Child diagram) по отношению к нему (каждый из функциональных блоков, принадлежащих дочерней диаграмме соответственно называется дочерним блоком – Child Box).Функциональный блок – предок называется родительским блоком по отношению к дочерней диаграмме (Parent Box), а диаграмма, к которой он принадлежит –родительской диаграммой (Parent Diagram).Каждая из подфункций дочерней диаграммы может быть далее детализирована путем аналогичной декомпозиции соответствующего ей функционального блока.В каждом случае декомпозиции функционального блока все интерфейсные дуги, входящие в данный блок, или исходящие из него фиксируются на дочерней диаграмме. Этим достигается структурная целостность IDEF0-модели.Часто отдельные интерфейсные дуги не имеет смысла продолжать рассматривать в дочерних диаграммах ниже (или выше) определенного уровня в иерархии.Иногда необходимо избавиться от отдельных «концептуальных» интерфейсных дуг и не детализировать их глубже некоторого уровня. Для решения подобных задач предусмотрено понятие «туннель» (Arrow Tunnel) в виде двух круглых скобок вокруг начала интерфейсной дуги обозначает, что эта дуга не была унаследована от функционального родительского блока и появилась (из «туннеля») только на

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

42. Принципы ограничения сложности IDEF0-диаграмм. IDEF0-модели несут в себе сложную и концентрированную информацию. Чтобы ограничить их перегруженность и сделать удобочитаемыми, приняты ограничения сложности:1Ограничение количества функциональных блоков на диаграмме Верхний предел (шесть) заставляет разработчика использовать иерархии при описании сложных предметов, а нижний предел (три) гарантирует, что на соответствующей диаграмме достаточно деталей, чтобы оправдать ее создание.2Ограничение количества дуг, подходящих к одному блоку (выходя-щих из одного функционального блока) .Строго следовать этим ограничениям необязательно, но опыт показывает, что они – весьма практичны.

43. Синтаксис и семантика моделей IDEF3.Основой модели IDEF3 служит так называемый сценарий бизнес-процесса, который выделяет последовательность действий или подпроцессов анализируемой системы. Поскольку сценарий определяет назначение и границы модели, довольно важным является подбор подходящего наименования для обозначения действий. Для подбора необходимого имени применяются стандартные рекомендации по предпочтительному использованию глаголов и отглагольных существительных. Например, "Обработать заказ клиента" или "Применить новый дизайн" — вполне подходящие названия сценариев.Точка зрения для большинства моделей должна быть явным образом документирована. Обычно это название набора должностных обязанностей человека, являющегося источником информации о моделируемом процессе.Для системного аналитика также важно понимание цели моделирования — набора вопросов, ответами на которые будет служить модель, границ моделирования (какие части системы войдут в модель, а какие не будут в ней отображены) и целевой аудитории (для кого разрабатывается модель).2Диаграммы Как и в любой рассматриваемой в этой книге технологии моделирования действий, главной организационной единицей модели IDEF3 является диаграмма. Вза-имная организация диаграмм внутри модели IDEF3 особенно важна в случае, когда модель заведомо создается для последующего опубликования или рецензирования, что является вполне обычной практикой при проектировании новых систем. В этом случае системный аналитик должен позаботиться о таком информационном наполнении диаграмм, чтобы каждая из них была самодостаточной и в то же время понятной читателю.3Единица работы. Действие Аналогично другим технологиям моделирования действие, или в терминах IDEF3 "единица работы" (Unit of Work — UOW) — другой важный компонент модели. Диаграммы IDEF3 отображают действие в виде прямоугольника. Как уже отмечалось, действия именуются с использованием глаголов или отглагольных существительных, каждому из действий присваивается уникальный идентификационный номер. Этот номер не используется вновь даже в том случае, если в процессе построения модели действие удаляется. В диаграммах IDEF3 номер действия обычно предваряется номером его родителя (рис. 1.2).

Рис. 1.2. Изображение и нумерация действия в диаграмме IDEF3

44. Типы связей в модели IDEF3.Связи выделяют существенные взаимоотношения между действиями. Все связи в IDEF3 являются однонаправленными, и, хотя стрелка может начинаться или заканчиваться на любой стороне блока, обозначающего действие, диаграммы IDEF3 обычно организовываются слева направо таким образом, что стрелки начинаются на правой и заканчиваются на левой стороне блоков. Связь типа "Временное предшествование". Как видно из названия, связи этого типа отражают, что исходное действие должно полностью завершиться, прежде чем начнется выполнение конечного действия. Связь должна быть поименована таким образом, чтобы человеку, просматривающему модель, была понятна причина ее появления. Во многих случаях завершение одного действия инициирует начало выполнения другого, Связь типа "Объектный поток". Одной из наиболее часто встречающихся причин использования связи типа "объектный поток" состоит в том, что некоторый объект, являющийся результатом выполнения исходного действия, необходим для выполнения конечного действия. Такая связь отличается от связи временного предшествования двойным концом обозначающей ее стрелки. Наименования потоковых связей должны четко идентифицировать объект, который передается с их помощью. Временная семантика объектных связей аналогична связям предшествования. Это означает, что порождающее объектную связь исходное действие должно завершиться, прежде чем конечное действие начнет выполняться. Связь типа "Нечеткое отношение". Связи этого типа используются для выделения отношений между действиями, которые невозможно описать с использованием предшественных или объектных связей. Значение каждой такой связи должно быть определено, поскольку связи типа "Нечеткое отношение" сами по себе не предполагают никаких ограничений. Одно из применений нечетких отношений — отображение взаимоотношений между параллельно выполняющимися действиями. Рис. 1.5 иллюстрирует фрагмент процесса запуска бензопилы с водяным охлаждением и нечеткое отношение между действиями "Запустить двигатель" и "Запустить водяной насос". Название стрелки может быть использовано для описания природы отношения, более подробное объяснение может быть приведено в виде отдельной ссылки.

45. Типы соединений в модели IDEF3.Завершение одного действия может инициировать начало выполнения сразу нескольких других действий, или, наоборот, определенное действие может требовать завершения нескольких других действий для начала своего выполнения. Соединения разбивают или соединяют внутренние потоки и используются для описания ветвления процесса.1Разворачивающие соединения используются для разбиения потока. Завершение одного действия вызывает начало выполнения нескольких других.2Сворачивающие соединения объединяют потоки. Завершение одного или нескольких действий вызывает начало выполнения только одного другого действия.Соединения этого типа инициируют выполнение всех своих

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

Соединение "Эксклюзивное ИЛИ". Вне зависимости от количества действий, прицепленных к сворачивающему или разворачивающему соединению "Эксклюзивное ИЛИ", инициировано будет только одно из них, и поэтому только одно из них будет завершено перед тем, как любое действие, следующее за сворачивающим соединением "Эксклюзивное ИЛИ", сможет начаться.Если правила активации соединения известны, они обязательно должны быть

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

соединение "Эксклюзивное ИЛИ" используется для отображения того факта, что студент не может одновременно быть направлен на лекции по двум разным курсам.Соединение "ИЛИ". Соединения этого типа предназначены для описания ситуаций, которые не могут быть описаны двумя предыдущими типами соединений. Аналогично связи нечеткого отношения соединение "ИЛИ" в основном определяется и описывается непосредственно системным аналитиком.

46. Синхронные соединения модели IDEF3.связей "И" и "ИЛИ"между началом и окончанием действий, инициируемых разворачивающими соединениями. Все действия в этих примерах выполнялись асинхронно, т.е. они не должны были начинать выполняться одновременно. Однако есть случаи, когда время начала или окончания параллельно выполняемых действий должно быть одинаковым, т.е. действия должны выполняться синхронно. Для моделирования такого поведения системы используются синхронные соединения.Синхронное соединение обозначается двумя вертикальными линиями внутри обозначающего его прямоугольника в отличие от одной вертикальной линии в асинхронном соединении.Во многих спортивных состязаниях выстрел стартового пистолета, запуск секундомера и начало состязания должны произойти одновременно. В противном случае состязание будет нечестным. синхронное разворачивающее соединение не обязательно должно иметь парное себе сворачивающее соединение. Действительно, начинающиеся одновременно действия вовсе не обязаны оканчиваться одновременно, как это видно из примера с состязаниями. Также возможны ситуации синхронного окончания асинхронно начавшихся действий.Парность соединений. Все соединения на диаграммах должны быть парными, из чего следует, что любое разворачивающее соединение имеет парное себе сворачивающее. Однако типы соединений вовсе не обязательно должны совпадать.Соединения могут комбинироваться для создания

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

47. Типы указателей модели IDEF3. Указатели — это специальные символы, которые ссылаются на другие разделы описания процесса. Они выносятся на диаграмму для привлечения внимания читателя к каким-либо важным аспектам модели.Указатель изображается на диаграмме в виде прямоугольника, похожего на изображение действия. Имя указателя обычно включает его тип (например, ОБЪЕКТ, UOB и т.п.) и идентификатор.Декомпозиция действий Действия в IDEF3 могут быть декомпозированы, или разложены на составляющие, для более детального анализа. Декомпозировать действие можно несколько раз. Это позволяет документировать альтернативные потоки процесса в одной модели.Для корректной идентификации действий в модели с множественными декомпозициями схема нумерации действий расширяется и наряду с номерами действия и его родителя включает в себя порядковый номер декомпозиции. Например, в номере действия 1.2.5: 1 — номер родительского действия, 2 — номер декомпозиции, 5 — номер действия.

48. Требования стандарта IDEF3 к описанию бизнес-процессов.1. Определение сценария, границ моделирования, точки зрения.Перед тем как попросить экспертов предметной области подготовить описание моделируемого процесса, должны быть документированы границы моделирования, чтобы экспертам была понятна необходимая глубина и полнота требуемого от них описания. Кроме того, если точка зрения аналитика на процесс отличается от обычной точки зрения для эксперта, это должно быть ясно и аккуратно описано.Вполне возможно, что эксперты не смогут сделать приемлемое описание без применения формального опроса автором модели. В таком случае автор должен заранее приготовить набор вопросов таким же образом, как журналист заранее подготавливает вопросы для интервью.2 Определение действий и объектов.Результатом работы экспертов обычно является текстовый документ, описывающий интересующий аналитика круг вопросов. В дополнение к нему может иметься письменная документация, позволяющая пролить свет на природу изучаемого процесса. Вне зависимости от того, является ли информация текстовой или вербальной, она анализируется и разделяется частями речи для идентификации списка действий (глаголы и отглагольные существительные), составляющих процесс, и объектов (имена существительные), участвующих в процессе.В некоторых случаях возможно создание графической модели процесса в присутствии экспертов. Такая модель также может быть разработана после сбора всей необходимой информации, что позволяет не отнимать время экспертов на детали форматирования получающихся диаграмм.3 Последовательность и параллельность.Если модель создается после проведения интервью, аналитик должен принять решения по построению иерархии участвующих в модели диаграмм, например, на-сколько подробно будет детализироваться каждая отдельно взятая диаграмма. Если последовательность или параллельность выполнения действий окончательно не ясна, эксперты могут быть опрошены вторично (возможно, с использованием черновых вариантов незаконченных диаграмм) для получения недостающей информации. Важно, однако, различать предполагаемую (появляющуюся из-за недостатка информации о связях) и явную (ясно указанную в описании эксперта) параллельности.

49. Диаграмм потоков данных: Назначение, синтаксис и семантика диаграмм.

Так же, как и диаграммы IDEF0, диаграммы потоков данных моделируют систему как набор действий, соединенных друг с другом стрелками.DFD-диаграммы также могут содержать:1объекты, собирающие и хранящие информацию – хранилища данных2внешние сущности – объекты, которые моделируют взаимодействие с теми частями системы (или другими системами), которые выходят за границы моделирования.В отличие от стрелок в IDEF0, которые иллюстрируют отношения, стрелки в DFD показывают, как объекты (включая и данные) реально перемещаются от одного действия к другому.Это позволяет отражать в DFD-моделях:1движение объектов (потоки данных), хранение объектов (хранилища данных),3источники и потребители объектов (внешние сущности).Построение DFD-диаграмм в основном ассоциируется с разработкой программного обеспечения, поскольку нотация DFD изначально была разработана для этих целей.Синтаксис и семантика диаграмм потоков данных

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

Контекстная DFD-диаграмма часто состоит из одного функционального блока и нескольких внешних сущностей.

Функциональный блок на этой диаграмме обычно имеет имя, совпадающее с именем всей системы

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

2.1 Функциональные блокиDFD моделирует некоторую функцию, которая преобразует какое-либо сырье в какую-либо продукцию (или, в терминах IDEF, вход в выход). Функциональные блоки DFD изображаются в виде прямоугольников с закругленными углами, они почти идентичны функциональным блокамIDEF0 и действиям IDEF3.Внешние сущности обеспечивают необходимые входы для системы и/или являются приемниками для ее выходов.Одна внешняя сущность может одновременно предоставлять входы (функционируя как поставщик) и принимать выходы (функционируя как получатель).

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

50. Два подхода к построению DFD-моделей.1. Диаграммы DFD можно строить с использованием подхода, аналогичного структурному методу анализа и проектирования, применяемому в IDEF0.1Вначале строится модель физической реализации реальной системы, которая используется пользователями в настоящее время.2Затем создается логическая модель текущего состояния системы для моделирования основных требований существующей системы.3После этого создается новая логическая модель для отражения основных параметров предлагаемой разрабатываемой системы.4Наконец, создается новая физическая модель, реализующая логическую модель новой системы.2. Альтернативный подход – разделение событий, в котором для моделирования системы строится несколько моделей DFD.1Вначале строится логическая модель, отображающая систему как набор действий и описывающая, что должна делать система.2Затем строится модель окружения, описывающая систему как объект, отвечающий на события, порождаемые внешними сущностями.Такая модель обычно состоит из описания назначения системы, одной диаграммы контекстного уровня и списка событий.

Контекстная диаграмма содержит один функциональный блок, представляющий систему в целом, и внешних сущностей (окружения), с которыми система взаимодействует.3На заключительном этапе создается модель поведения, показывающая, как система обрабатывает те или иные события.Эта модель начинается с единственной диаграммы с одним функциональным блоком на каждый ответ системы на событие, описанное в модели окружения.Хранилища данных в модели поведения используются для моделирования данных, которые должны сохраняться в промежутках между обработкой событий.Потоки применяются для соединения элементов диаграмм между собой и для проверки согласованности моделей поведения и окружения.2Нумерация объектовВ DFD каждый номер функционального блока может включать в себя префикс, номер родительской диаграммы и собственно номер объекта.Номер объекта уникальным образом идентифицирует функциональный блок на диаграмме.Номер родительской диаграммы и номер объекта в совокупности обеспечивают уникальную идентификацию каждого блока модели.

Уникальные номера присваиваются также каждому хранилищу данных и каждой внешней сущности вне зависимости от расположения.Каждый номер хранилища содержит префикс D (от английского Data Store) и уникальный номер хранилища в модели. Аналогично каждый номер каждой внешней сущности содержит префикс Е (от английского External entity) и уникал ьный номер сущности в модели (например, Е5)