неверно что сценарий idef3 является частным случаем реализации процесса
Основы IDEF3
Два типа диаграмм в IDEF3
На следующем примере, опишем, как графические средства IDEF3 позволяют документировать вышеуказанный производственный процесс окраски детали. В целом, этот процесс состоит непосредственно из самой окраски, производимой на специальном оборудовании и этапа контроля ее качества, который определяет, нужно ли деталь окрасить заново (в случае несоответствия стандартам и выявления брака) или отправить ее в дальнейшую обработку.
Рисунок 1. Пример PFDD диаграммы.
На рис.1 изображена диаграмма PFDD, являющаяся графическим отображение сценария обработки детали. Прямоугольники на диаграмме PFDD называются функциональными элементами или элементами поведения (Unit of Behavior, UOB) и обозначают событие, стадию процесса или принятие решения. Каждый UOB имеет свое имя, отображаемое в глагольном наклонении и уникальный номер. Стрелки или линии являются отображением перемещения детали между UOB-блоками в ходе процесса. Линии бывают следующих видов:
— Отношения (Relational Link)- пунктирная линия, использующаяся для изображения связей между UOB
— Потоки объектов (Object Flow)- стрелка с двумя наконечниками используется для описания того факта, что объект (деталь) используется в двух или более единицах работы, например, когда объект порождается в одной работе и используется в другой.
Смысл в случае слияния стрелок
(Fan-in Junction)
Смысл в случае разветвления стрелок (Fan-out Junction)
Все предшествующие процессы должны быть завершены
Все следующие процессы должны быть запущены
Все предшествующие процессы завершены одновременно
Все следующие процессы запускаются одновременно
Один или несколько предшествующих процессов должны быть завершены
Один или несколько следующих процессов должны быть запущены
Один или несколько предшествующих процессов завершаются одновременно
Один или несколько следующих процессов запускаются одновременно
Только один предшествующий процесс завершен
Только один следующий процесс
запускается
Все перекрестки в PFDD диаграмме нумеруются, каждый номер имеет префикс «J».
Сценарий, отображаемый на диаграмме, можно описать в следующем виде:
Деталь поступает в окрасочный цех, подготовленной к окраске. В процессе окраски наносится один слой эмали при высокой температуре. После этого, производится сушка детали, после которой начинается этап проверки качества нанесенного слоя. Если тест подтверждает недостаточное качество нанесенного слоя (недостаточную толщину, неоднородность и т.д.), то деталь заново пропускается через цех окраски. Если деталь успешно проходит контроль качества, то она отправляется в следующий цех для дальнейшей обработки.
Рисунок 2. Пример OSTN диаграммы
Если диаграммы PFDD технологический процесс «С точки зрения наблюдателя», то другой класс диаграмм IDEF3 OSTN позволяет рассматривать тот же самый процесс «С точки зрения объекта». На рис.2 представлено отображение процесса окраски с точки зрения OSTN диаграммы. Состояния объекта (в нашем случае детали) и Изменение состояния являются ключевыми понятиями OSTN диаграммы. Состояния объекта отображаются окружностями, а их изменения направленными линиями. Каждая линия имеет ссылку на соответствующий функциональный блок UOB, в результате которого произошло отображаемое ей изменение состояния объекта.
Неверно что сценарий idef3 является частным случаем реализации процесса
2.1 СЦЕНАРИИ: ОРГАНИЗУЮЩАЯ СТРУКТУРА ДЛЯ ОПИСАНИЙ
ПРОЦЕССОВ IDEF3
Понятие «сценарий» или «рассказ» используется как базовая организующая структура для описаний процессов IDEF3. Сценарий можно рассматривать как повторяющуюся ситуацию или набор ситуаций, описывающих типичный класс проблем, рассматриваемых организацией или системой, а также как обстановку, в которой происходит процесс. Сценарии обеспечивают направленность внимания и граничные условия описания. В подобном применении сценариев используется тенденция людей описывать то, что они знают, в виде упорядоченной последовательности действий в рамках контекста данного сценария или ситуации. Кроме того, сценарии представляют удобный механизм для организации совокупности процессо-центрированных знаний.
Поскольку основная роль сценария заключается в связывании контекста описания процессов IDEF3, важно, чтобы сценарий имел соответствующее имя. Имена сценариев часто имеют форму повелительного наклонения (например, глагол или глагольная фраза типа «Выдать заказ на поставку«, «Проверить соответствие» и т.д.), а иногда имеют форму герундия (отглагольного существительного) (например, глагол, выполняющий функцию существительного, типа «Выполнение проверок на непротиворечивость«). Правильно выбранное имя сценария обеспечивает для пользователей описания соответствующие ассоциации с описываемыми ситуациями реального мира. Правильная идентификация, спецификация и именование сценариев представляют необходимый шаг для создания процессо-центрированных описаний процессов IDEF3. Примеры типичных имен сценариев:
Описание процессов IDEF3 разрабатывается при использовании двух стратегий приобретения знаний: процессо-центрированной стратегии и объектно-центрированной стратегии. Процессо-центрированная стратегия при организации знаний о процессах направлена на процессы и их временные, причинно-следственные и логические связи в рамках одного сценария. Вторая стратегия при организации знаний о процессах направлена на объекты и их поведение при изменении состояний в одном сценарии или в нескольких сценариях.
При использовании одной или обеих стратегий приобретения знаний о процессах пользователи IDEF3 разрабатывают описания процессов IDEF3. В обеих стратегиях используются базовые элементы языка IDEF3 для сбора и выражения утверждений, формирующих описание. При использовании графического языка IDEF3 создаются графические проекции информации, содержащейся в описаниях процессов. Эти графические проекции, которые используются для непосредственной регистрации информации о процессах и в качестве механизма отображения информации о процессах, называются схематиками.
Параллельно двум стратегиям приобретения знаний по процессам существует два типа схематик IDEF3. Схематика процессов IDEF3 отображает процессо-центрированное представление сценария. Схематики объектов обеспечивают поддержку графического отображения объектно-центрированной информации. Схематики объектов, отображающие объектно-центрированное представление одного сценария, называются схематиками переходов состояний. Схематики переходов состояний, отображающие дополнительные объекты и отношения объектов для обеспечения информации для установки контекста, называются схематиками расширенных переходов состояний. Схематики объектов, отображающие объектно-центрированную информацию, охватывающую множество сценариев, называются просто схематиками объектов.
Описание процессов IDEF3 может содержать нулевое количество или больше сценариев процессов и нулевое количество или больше схематик объектов. Например, регистрация факта, что определенный объект распознается участниками в определенной предметной области, считается частью описания данной предметной области. Идентифицированный таким образом объект может иметь или не иметь схематику объектов, ассоциированную с ним в описании. Однако, эти объекты считаются частью описания. Для организации процессо-центрированных и объектно-центрированных представлений используется понятие сценария. Совокупность сценариев и информации, для организации которой они служат, и есть описание процессов IDEF3.
Два следующих раздела представляют краткое введение в концепции представления описаний и синтаксис, используемый в двух типах схематик IDEF3.
Стандарт моделирования сценариев IDEF3
Стандарт IDEF3 предназначен для документирования технологических процессов, происходящих на предприятии, и предоставляет инструментарий для наглядного исследования и моделирования их сценариев.
Рассмотрим особенности данного стандарта, используя работу [48].
Сценарием называется описание последовательности изменений свойств объекта, в рамках рассматриваемого процесса (например, описание последовательности этапов обработки детали в цеху и изменение её свойств после прохождения каждого этапа). Исполнение каждого сценария сопровождается соответствующим документооборотом, который состоит из двух основных потоков: документов, определяющих структуру и последовательность процесса (технологических указаний, описаний стандартов и т.д.), и документов, отображающих ход его выполнения (результатов тестов и экспертиз, отчетов о браке, и т.д.). Для эффективного управления любым процессом, необходимо иметь детальное представление о его сценарии и структуре сопутствующего документооборота. Средства документирования и моделирования IDEF3 позволяют выполнять следующие задачи:
— Документировать имеющиеся данные о технологии процесса, выявленные, скажем, в процессе опроса компетентных сотрудников, ответственных за организацию рассматриваемого процесса.
— Определять и анализировать точки влияния потоков сопутствующего документооборота на сценарий технологических процессов.
— Определять ситуации, в которых требуется принятие решения, влияющего на жизненный цикл процесса, например изменение конструктивных, технологических или эксплуатационных свойств конечного продукта.
— Содействовать принятию оптимальных решений при реорганизации технологических процессов.
— Разрабатывать имитационные модели технологических процессов, по принципу «Как будет если. ».
Существуют два типа диаграмм в стандарте IDEF3, представляющих описание одного и того же сценария технологического процесса в разных ракурсах. Диаграммы относящиеся к первому типу называются диаграммами Описания Последовательности Этапов Процесса (Process Flow Description Diagrams – PFDD), а ко второму – диаграммами Состояния Объекта в Процессе его Трансформации (Object State Transition Network – OSTN).
Предположим, требуется описать процесс окраски детали в производственном цеху на предприятии. С помощью диаграмм PFDD (см. рис. 3.35 и [48]) документируется последовательность и описание стадий обработки детали в рамках исследуемого технологического процесса. Диаграммы OSTN (см. рис. 3.36 и [48]) используются для иллюстрации трансформаций детали, которые происходят на каждой стадии обработки.
 |
На рис. 3.35 изображена диаграмма PFDD, являющаяся графическим отображение сценария обработки детали. В целом, этот процесс состоит непосредственно из самой окраски, производимой на специальном оборудовании и этапа контроля ее качества, который определяет, нужно ли деталь окрасить заново (в случае несоответствия стандартам и выявления брака) или отправить ее на дальнейшую обработку. Прямоугольники на диаграмме PFDD называются функциональными элементами, единицами работы или элементами поведения (Unit of Behavior – UOB) и обозначают событие, стадию процесса или принятие решения. Каждый UOB имеет свое имя, отображаемое в глагольном наклонении и уникальный номер. Стрелки являются отображением перемещения детали между UOB-блоками в ходе процесса. Они бывают следующих видов:
 |
— Предшествование – сплошная одинарная стрелка, связывающая UOB в соответствии с последовательностью выполнения работ. Рисуется слева направо или сверху вниз.
— Отношение – пунктирная одинарная стрелка, использующаяся для изображения различного вида связей между UOB.
— Поток объектов – сплошная стрелка с двумя наконечниками, используемая для описания того факта, что объект, порождаемый одной работой, используется для выполнения другой.
Объект, обозначенный J1 – называется перекрестком (junction). Перекрестки используются для отображения логики взаимодействия стрелок (потоков) при слиянии и разветвлении или для отображения множества событий, которые могут или должны быть завершены перед началом следующей работы. Различают перекрестки для слияния (fan-in junction) и разветвления (fan-out junction) стрелок. Все перекрестки в PFDD диаграмме нумеруются, каждый номер имеет префикс «J». Классификация возможных типов перекрестков приведена в таблице 3.6.
Каждый функциональный блок UOB может иметь последовательность декомпозиций, и, следовательно, может быть детализирован с любой необходимой точностью. Под декомпозицией понимается представление каждого UOB с помощью отдельной IDEF3 диаграммы.
Таблица 3.6. Возможные перекрестки в стандарте IDEF3.
| Обозначе-ние | Наименова-ние | Слияние стрелок (Fan-in Junction) | Разветвление стрелок (Fan-out Junction) |
 | Asynchronous AND | Все предшествующие процессы должны быть завершены. | Все следующие процессы должны быть запущены. |
 | Synchronous AND | Все предшествующие процессы завершены одновременно. | Все следующие процессы запускаются одновременно. |
 | Asynchronous OR | Один или несколько предшествующих процессов должны быть завершены. | Один или несколько следующих процессов должны быть запущены. |
 | Synchronous OR | Один или несколько предшествующих процессов завершаются одновременно. | Один или несколько следующих процессов запускаются одновременно. |
 | XOR Exclusive OR) | Только один предшествующий процесс завершен. | Только один следующий процесс запускается. |
Например, можно декомпозировать UOB «Окрасить деталь», представив его отдельным процессом и построив для него свою PFDD диаграмму. При этом эта диаграмма будет называться дочерней, по отношению к изображенной на рисунке, а та, соответственно, родительской. Номера UOB дочерних диаграмм имеют сквозную нумерацию, т.е., если родительский UOB имеет номер «1», то блоки UOB на его декомпозиции будут соответственно иметь номера «1.1», «1.2» и т.д.
Если диаграммы PFDD представляет технологический процесс «c точки зрения наблюдателя», то другой класс диаграмм IDEF3 – OSTN позволяет рассматривать тот же самый процесс «c точки зрения объекта». Состояния объекта (в данном случае детали, см. рис. 3.36) и Изменение состояния являются ключевыми понятиями OSTN-диаграммы. Состояния объекта отображаются окружностями, а их изменения направленными одинарными стрелками. Каждая стрелка имеет ссылку на соответствующий функциональный блок UOB, в результате которого произошло отображаемое ею изменение состояния объекта. Таким образом, OSTN-диаграмма представляет собой аналог STD-диаграммы технологии 3VM.
С точки зрения основного примера, рассматриваемого в данном разделе (ресторана), стандарт IDEF3 является удобным средством анализа и документирования процессов (сценариев) приема гостей в различных ситуациях (например: ресторан «fast food» или вечерний ресторан; обычный обед/ужин, заказанное мероприятие, праздничный ужин, завтрак), а также технологических процессов приготовления различных блюд. На рисунках 3.37 и 3.38 представлен пример сценария приема гостей в вечернем ресторане при обслуживании обычного обеда/ужина (подготовлен с помощью BPwin (IDEF3)).
Сценарии, IDEF3-диаграмма сценария
СЦЕНАРИЙ
СЦЕНАРИЙ (Scenario) — описание последовательности изменений свойств объекта, в рамках рассматриваемого процесса (например, описание последовательности этапов обработки детали в цеху и изменение её свойств после прохождения каждого этапа). Метод IDEF3 использует сценарии для упрощения структуры описаний сложного многоэтапного процесса. Сценарии определяют граничные условия описания и представляют собой повторяющуюся по-следовательность ситуаций или действий, которые описывают типичный класс проблем, при-сутствующих в организации или системе, описание последовательности изменений свойств объекта, в рамках рассматриваемого процесса (например, описание последовательности обработки менеджером заявки). Использование сценариев упрощает структуру описаний сложного многоэтапного процесса.
На основе IDEF3-диаграмм создаются сценарии действий сотрудников предприятия/организации, например последовательность этапов конструкторско-технологической подготовки производства машиностроительного изделия или иного события, которые необходимо обработать за конечное время. Каждый сценарий сопровождается описанием процесса и может быть использован для документирования каждой функции. Исполнение каждого сценария сопровождается соответствующим документооборотом, который состоит из двух основных потоков: документов, определяющих структуру и последовательность процесса (технологических указаний, описаний стандартов и т.д.), и документов, отображающих ход его выполнения (ре-зультатов тестов и экспертиз, отчетов о браке, и т.д.).
IDEF3-ДИАГРАММА СЦЕНАРИЯ
IDEF3-ДИАГРАММА СЦЕНАРИЯ (scenario diagram) — это специфический вид диаграммы, которая создается для иллюстрации сценария типа what if – «что будет, если» для декомпози-ционных IDEF3-диаграмм. Для сценария номер декомпозиции всегда больше единицы.
При создании сценария, как и при создании описания, требование, что при декомпозиции может существовать только одна точка входа, за которой обязательно следует функция или перекресток, дополняется разрешением, что сценарий, который не является декомпозицией, может иметь несколько точек выхода.
Создание сценариев путем декомпозиции IDEF3-диаграммы должно производиться при непосредственном участии автора и экспертов в предметной области. Алгоритм совместной работы имеет вид:
Аналитик производит описание сценария, области и точки зрения. Для четкого понимания цели декомпозиции — особенно важно задокументировать сценарии и рамки модели. В некоторых случаях целесообразно создавать графическую модель для представления ее эксперту предметной области.
При отсутствии личного контакта между автором и экспертом необходимо приготовить список вопросов для проведения интервью.
После анализа предоставленной информации эксперт в предметной области передает ана-литику текстовое описание сценария. Дополнительно может быть передана документация, описывающая отдельные, особо важные процессы.
На основании полученной информации аналитик составляет список кандидатов на описанные функции (отглагольные существительные, обозначающие процесс, одиночные или в составе именного словосочетания) и кандидатов на объекты (существительные, обозначающие результат выполнения работы), которые необходимы для перечисленных в списке функций. При такой организации работы разные фрагменты IDEF3-диаграммы могут быть созданы различными группами авторов в разное время, поэтому нотация IDEF3 поддерживает схему нумерации работ в рамках всей модели, согласно которой разные аналитики, работаю независимо друг от друга, оперируют различными диапазонами номеров.
После проведения интервью, аналитик принимает решения, относящиеся к иерархии диа-грамм. Если последовательность и согласование диаграмм не очевидны, то может быть проведена еще одна экспертиза для детализации и уточнения информации.
‹ Стандарт IDEF3, IDEF3-диаграмма
Вверх
PFDD и OSTN диаграммы ›
1.4.2. Метод описания процессов IDEF3
1.4.2. Метод описания процессов IDEF3
Техника описания набора данных IDEF3 является частью структурного анализа. В отличие от некоторых методик описаний процессов IDEF3 не ограничивает аналитика чрезмерно жесткими рамками синтаксиса, что может привести к созданию неполных или противоречивых моделей.
IDEF3 может быть также использован как метод создания процессов. IDEF3 дополняет IDEF0 и содержит все необходимое для построения моделей, которые в дальнейшем могут быть использованы для имитационного анализа.
Каждая работа в IDEF3 описывает какой-либо сценарий бизнес-процесса и может являться составляющей другой работы. Поскольку сценарий описывает цель и рамки модели, важно, чтобы работы именовались отглагольным существительным, обозначающим процесс действия, или фразой, содержащей такое существительное.
Диаграммы. Диаграмма является основной единицей описания в 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
«DefinitionПодготавливаются все компоненты компьютера согласно
«ObjectsКомпоненты: винчестеры, корпуса, материнские платы,
видиокарты, звуковые карты, дисководы CD-ROM
и флоппи, модемы, программное обеспечение
«Constrains Установка модема требует установки дополнительного пограммного обеспечения
Связи. Связи показывают взаимоотношения работ. Все связи в IDEF3 однонаправленны и могут быть направлены куда угодно, но обычно диаграммы IDEF3 стараются построить так, чтобы связи были направлены слева направо. В IDEF3 различают три типа стрелок, изображающих связи, стиль которых устанавливается во вкладке Style (рис. 1.4.5) диалога Arrow Properties (пункт контекстного меню Style).
Рис. 1.4.5. Вкладка Style диалога Arrow Properties
Старшая связь и поток объектов. Старшая связь показывает, что работа-источник заканчивается ранее, чем начинается работа-цель. Часто результатом работы-источника становится объект, необходимый для запуска работы-цели. В этом случае стрелку, обозначающую объект, изображают с двойным наконечником. Имя стрелки должно ясно идентифицировать отображаемый объект. Поток объектов имеет ту же семантику, что и старшая стрелка.
Рис. 1.4.6. Временная диаграмма выполнения работ
Таблица 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 или их сочетания. Если завершается более чем одна работа, требуется их одновременное завершение
Правила создания перекрестков. На одной диаграмме IDEF3 может быть создано несколько перекрестков различных типов. Определенные сочетания перекрестков для слияния и для разветвления могут приводить к логическим несоответствиям. Чтобы избежать конфликтов необходимо соблюдать следующие правила:
Каждому перекрестку для слияния должен предшествовать перекресток для разветвления.
Перекресток для слияния «И» не может следовать за перекрестком для разветвления типа синхронного или асинхронного «ИЛИ» (рис. 1.4.12).
Рис. 1.4.12. Неверное размещение перекрестков. Перекресток для слияния «И» не может следовать за перекрестком для разветвления «ИЛИ»
Перекресток для слияния «И» не может следовать за перекрестком для разветвления типа исключающего «ИЛИ» (рис. 1.4.13).
Рис. 1.4.13. Неверное размещение перекрестков. Перекресток для слияния «И» не может следовать за перекрестком для разветвления типа исключающего «ИЛИ»
Рис. 1.4.14. Неверное размещение перекрестков. Перекресток для слияния типа исключающего «ИЛИ» не может следовать за перекрестком для разветвления типа «И»
Перекресток, имеющий одну стрелку на одной стороне, должен иметь более одной стрелки на другой.
Рис. 1.4.15. Объект ссылки
При внесении объектов ссылок помимо имени следует указывать л объекта ссылки. Типы объектов ссылок приведены в табл. 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). Это позволяет аналитику вносить информацию в удобном в данный момент времени виде. Важно учитывать, что модели могут быть реорганизованы, например для их представления в более презентабельном виде. Выбор формата для презентации часто имеет важное значение для организации модели, поскольку комбинация перекрестков занимает значительное место на диаграмме и использование иерархии перекрестков затрудняет расположение работ на диаграмме.
Читайте также
R.7 Описания
R.7 Описания Описания используются для интерпретации каждого из идентификаторов; необязательно, чтобы они сопровождались выделением памяти, сопоставляемой с идентификатором. Описания имеют видописания: спецификации-описания opt список-описателей
R.7.3 Описания asm
R.7.3 Описания asm Описание asm имеет вид:описание-asm: asm ( строка-литерал );Назначение описания asm определяется реализацией. Обычно оно используется для передачи информации от транслятора к
R.17.3 Описания
R.17.3 Описания описания: спецификации-описания opt список-описателей
R.17.5 Описания класса
R.17.5 Описания класса спецификация-класса: заголовок-класса < список-членов opt >заголовок-класса: служебное-слово-класса идентификатор opt спец-базовых opt служебное-слово-класса имя-класса спец-базовых optслужебное-слово-класса: class struct unionсписок-членов: описание-члена
1.4. Дополнение созданной модели процессов организационными диаграммами, диаграммами DFD и Workflow (IDEF3)
1.4. Дополнение созданной модели процессов организационными диаграммами, диаграммами DFD и Workflow (IDEF3) 1.4.1. Диаграммы потоков данных (Data Flow Diagramming) Диаграммы потоков данных (Data flow diagramming, DFD) используются для описания документооборота и обработки информации. Подобно IDEF0, DFD
1.4.2. Метод описания процессов IDEF3
1.4.2. Метод описания процессов IDEF3 Наличие в диаграммах DFD элементов для описания источников, приемников и хранилищ данных позволяет более эффективно и наглядно описать процесс документооборота. Однако для описания логики взаимодействия информационных потоков более
4.14.4. Модификация диаграммы IDEF3 «Сборка продукта» с целью отображения новой информации
4.14.4. Модификация диаграммы IDEF3 «Сборка продукта» с целью отображения новой информации Так же как в модели AS-IS, сборка продукта состоит из сборки компонентов и установки программного обеспечения. Однако теперь в работу «Сборка продукта» включена работа «Тестирование
Структурные описания
1.5. Дополнение созданной модели процессов диаграммами DFD и Workflow (IDEF3)
1.5. Дополнение созданной модели процессов диаграммами DFD и Workflow (IDEF3) 1.5.1. Диаграммы потоков данных (Data Flow Diagramming) Диаграммы потоков данных (Data flow diagramming, DFD) используются для описания документооборота и обработки информации. Подобно IDEF0, DFD представляет модельную систему как
1.4.9 Описания
1.4.9 Описания Описание – это оператор, вводящий имя в программе. Оно может также инициализировать объект с этим именем. Выполнение описания означает, что когда поток управления доходит до описания, вычисляется инициализирующее выражение (инициализатор) и производится
2.1 Описания
2.1 Описания Прежде чем имя (идентификатор) может быть использовано в С++ программе, он должно быть описано. Это значит, что надо задать его тип, чтобы сообщить компилятору, к какого вида сущностям относится имя. Вот несколько примеров, иллюстрирующих разнообразие
8. Описания
8. Описания Описания используются для определения интерпретации, дваемой каждому идентификатору. Они не обязательно резервируют память, связанную с идентификатором. Описания имеют вид:описание: спецификаторы_описания opt список_описателей opt ; описание_имени
8.5 Описания Классов
8.5 Описания Классов Класс есть тип. Его имя становится typedef-имя (см. #8.8), которое может быть использовано даже внутри самого спецификатора класса. Объекты класса состоят из последовтельности членов.спецификатор_класса: заголовок_класса (* список_членов opt *) заголовок_класса
8.10 Описания Перечислений
14.2 Описания
14.2 Описания описание: спецификаторы_описания opt список_описателей opt ; описание_имени asm-описаниеописание_имени: сост идентификатор ; enum идентификатор ;сост:class struct unionasm-описание: asm ( строка ) ;спецификаторы_описания: спецификатор_описания спецификаторы_описания