Перечень средств автоматизации разработки проекта IDEF0 в AllFusionProcessModeler 7 (BPwin/ ERwin) и их краткое описание.

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

Для того чтобы задать свойства блока необходимо нажать правой клавишей мыши на изображении блока и выбрать нужное свойство Activity properties.  Для каждого действия необходимо задать его имя ( Name ) и описание (Definition). Разработка модели начинается с определения контекстной диаграммы.

Второй основной элемент IDEFO-методологии — это стрелка. Для задания и изменения свойств стрелки необходимо выбрать на панели инструментов элемент «стрелка» и дважды щелкнуть левой кнопкой мыши на стрелке.

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

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

 

41. Назначение и состав модели в нотации DFD. Элементы графической нотации DFD: перечислить и дать краткую характеристику.

Назначение и состав модели в нотации DFD

При построении функциональной модели системы альтернативой методологии IDEF0 является методология диаграмм потоков данных (DataFlowDiagrams, DFD). В отличие от IDEF0, предназначенной для проектирования систем вообще, DFD предназначена для проектирования информационных систем. Ориентированность этой методологии на проектирование автоматизированных систем делает ее удобным и более выгодным инструментом при построении функциональной модели TO-BE.

Как и в IDEF0, основу методологии DFD составляет графический язык описания процессов.

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

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

 

Элементы графической нотации DFD

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

При построении диаграмм различают элементы графической нотации, представленные в табл.1.

Таблица 1. Элементы графической нотации DFD

Наименование	Нотация Гейна-Сарсона
Поток данных
Процесс (система, подсистема)
Накопитель данных
Внешняя сущность

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

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

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

Процесс (в IDEF0 – функция, работа) представляет собой преобразование входных потоков данных в выходные в соответствии с определенным алгоритмом.

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

Номер процесса служит для его идентификации и ставится с учетом декомпозиции. В отличие от IDEF0 вложенность процессов обозначается через точку (например, в IDEF0 – «236», в DFD – «2.3.6»).

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

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

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

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

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

 

42. Правила построения диаграмм в нотации DFD. Основные рекомендации и отличия от IDEF0.

 

Правила и рекомендации построения модели DFD в основном совпадают с принятыми в IDEF0. Часть из них приведена в подразд. 6.9.

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

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

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

Построение диаграмм DFD. Диаграммы DFD могут быть построены с использованием традиционного структурного анализа, подобно тому как строятся диаграммы IDEF0. Сначала строится физическая модель, отображающая текущее состояние дел. Затем эта модель преобразуется в логическую модель, которая отображает требования к существующей системе. После этого строится модель, отображающая требования к будущей системе. И наконец, строится физическая модель, на основе которой должна быть построена новая система.

Альтернативным подходом является подход, популярный при создании программного обеспечения, называемый событийным разделением (eventPartitioning), в котором различные диаграммы DFD выстраивают модель системы. Во-первых, логическая модель строится как совокупность работ и документирования того, что они (эти работы) должны делать.

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

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

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

Нумерация объектов. В DFD номер каждой работы может включать префикс, номер родительской работы (А) и номер объекта. Номер объекта -это уникальный номер работы на диаграмме. Например, работа может иметь номер А. 12.4. Уникальный номер имеют хранилища данных и внешние сущности независимо от их расположения на диаграмме. Каждое хранилище данных имеет префикс D и уникальный номер, например D5. Каждая внешняя сущность имеет префикс Е и уникальный номер, например Е5.

В отличие от стрелок IDEF0, которые представляют собой жесткие взаимосвязи, стрелки DFD показывают, как объекты (включая данные) двигаются от одной работы к другой. Это представление потоков совместно с хранилищами данных и внешними сущностями делает модели DFD более похожими на физические характеристики системы - движение объектов (dataflow), хранение объектов (datastores), поставка и распространение объектов (externalentities)

 

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

 

43. Назначение и состав модели в нотации IDEF3. Элементы графической нотации IDEF3: перечислить и дать краткую характеристику.

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

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

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

· • диаграмма описания последовательности этапов процесса (ProcessFlowDescriptionDiagrams — PFDD), с помощью которой моделируется последовательность действий, реализуемых в рамках бизнес-процесса;

· • диаграмма состояния и трансформации объекта в процессе (ObjectStateTransitionNetwork — OSTN), с помощью которой описываются изменения, происходящие с объектом в ходе его обработки.

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

Основными элементами диаграммы PFDD IDEF3 (далее — IDEF3) являются:

· • функциональный элемент;

· • стрелка;

· • перекресток.

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

Рис. 5.8. Структура функционального элемента в IDEF3

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

Перекресток (условные символы ветвления) используется для отражения логики движения потоков между функциональными элементами (операциями). Перекресток позволяет указать события, которые могут или должны произойти для того, чтобы началось выполнение следующего действия. На диаграмме IDEF3 перекресток представляет собой прямоугольник с индикатором " J" и номером данного перекрестка на диаграмме (рис. 5.10). Существуют перекрестки, используемые для отражения слияния стрелок, и перекрестки, используемые для отражения разветвления стрелок. Стоит отметить, что один перекресток не может одновременно использоваться для слияния и для разветвления. В методологии IDEF3 выделяют: разворачивающиеся соединения, используемые для отражения связей, где завершение одного процесса инициирует запуск нескольких других процессов: сворачивающиеся соединения, используемые для отражения связей, где завершение нескольких процессов приводит к запуску следующего одного процесса.

Разворачивающиеся и сворачивающиеся соединения могут быть также нескольких типов:

· • " и" (обозначается квадратом с символом " & " );

· • " исключающее “или”" (обозначается квадратом с символом " X" );

· • " или" (обозначается квадратом с символом " О" ).

 

 

44. Типы стрелок в нотации IDEF3, их графическая интерпретация, назначение и сущность.

 

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

 

Изображение стрелки	Название	Описание
	Старшая (Precedence) стрелка	сплошная линия, связывающая единицы работ (UOW). Рисуется слева направо или сверху вниз. Показывает, что работа-источник должна закончиться прежде, чем работа-цель начнется
	Потоки объектов (ObjectFlow)	стрелка с двумя наконечниками, применяется для описания того факта, что объект используется в двух или более единицах работы, например когда объект порождается в одной работе и используется в другой
	Стрелка отношения (RelationalLink)	пунктирная линия, использующаяся для изображения связей между единицами работ (UOW), а также между единицами работ и объектами ссылок. Значение задается аналитиком отдельно для каждого случая

 

45. Перекрестки в нотации IDEF3: их назначение, типы, правила создания.

 

Перекрестки (Junction). Окончание одной работы может служить сигналом к началу нескольких работ, или же одна работа для своего запуска может ожидать окончания нескольких работ. Перекрестки используются для отображения логики взаимодействия стрелок при слиянии и разветвлении или для отображения множества событий, которые могут или должны завершены перед началом следующей работы. Различают перекрестки я слияния (Fan-inJunction) и разветвления (Fan-outJunction) стрелок. Перекресток не может использоваться одновременно для слияния и для «ветвления. Для внесения перекрестка служит кнопка Щ (добавить ^диаграмму перекресток - Junction) в палитре инструментов. В диалоге junctionTypeEditor необходимо указать тип перекрестка. Смысл каждого типа приведен в табл. 1.4.2.

Таблица 1.4.2. Типы перекрестков

Все перекрестки на диаграмме нумеруются, каждый номер имеет префикс J. Можно редактировать свойства перекрестка при помощи диалога JunctionProperties (вызывается из контекстного меню). В отличие от IDEF0 и DFD в IDEF3 стрелки могут сливаться и разветвляться только через перекрестки. Рис. 1.4.7-1.4.11 иллюстрируют смысл перекрестков каждого типа.

Правила создания перекрестков. На одной диаграмме IDEF3 может быть создано несколько перекрестков различных типов. Определенные сочетания перекрестков для слияния и для разветвления могут приводить к логическим несоответствиям. Чтобы избежать конфликтов необходимо соблюдать следующие правила:

Каждому перекрестку для слияния должен предшествовать перекресток для разветвления.

Перекресток для слияния " И" не может следовать за перекрестком для разветвления типа синхронного или асинхронного " ИЛИ" (рис. 1.4.12).

Действительно, после работы 1 может запускаться только одна работа - 2 или 3, а для запуска работы 4 требуется окончание обеих работ - 2 и 3. Такой сценарий не может реализоваться.

Перекресток для слияния " И" не может следовать за перекрестком для разветвления типа исключающего " ИЛИ" (рис. 1.4.13).

4. Перекресток для слияния типа исключающего " ИЛИ" не может следовать за перекрестком для разветвления типа " И" (рис. 1.4.14). Здесь после завершения работы 1 запускаются обе работы - 2 и 3, а для запуска работы 4 требуется, чтобы завершилась одна и только одна работа -или 2, или 3.

Перекресток, имеющий одну стрелку на одной стороне, должен иметь более одной стрелки на другой.

 

46. Объекты ссылок в нотации IDEF3: их назначение, типы, правила создания.

Любая IDEF3-диаграмма может содержать работы, связи, перекрестки и объекты ссылок.

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

Объекты ссылки должны быть связаны с единицами работ или перекрестками линиями.

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

Кроме имени следует указывать тип объекта ссылки.

Типы объектов ссылок

Тип объекта ссылки	Цель описания
ОБЪЕКТ	Описывает участие важного объекта в действии
ССЫЛКА	Инструмент циклического перехода (в повторяющейся последовате­ль­ности действий), переход возможен как на действие текущей диаграммы, так и на действие любой другой, но не обязательно. Если все действия цикла присутствуют на текущей диаграмме, цикл может также изображаться стрелкой, возвращающейся на стартовое действие. ССЫЛКА может ссылаться и на перекресток
ЕДИНИЦА ДЕЙСТВИЯ	Применяется для многократного отображения на диаграмме одного и того же действия, т.е. действия, которое используется в процессе несколько раз, но не в цикле. В этом случае в первый раз действие создается как единица работы, а последующие его появления на диаграмме оформляются объектами ЕДИНИЦА ДЕЙСТВИЯ
ЗАМЕТКА	Используется для документирования важной информации общего характера, относящейся к изображенному на диаграмме. ЗАМЕТКА является альтернативой внесению текстового объекта в диаграмму
УТОЧНЕНИЕ	Используется для уточнения или более детального описания изображенного на диаграмме. Обычно употребляется для детального описания логики ветвления у соединений

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

Например, логика взаимодействия единиц работ может быть отображена графически в виде комбинации перекрестков, что может занять значительное место на диаграмме, затруднит расположение работ. Поэтому та же информация может быть отображена в виде объекта ссылки УТОЧНЕНИЕ

 

47. Декомпозиция работ в диаграммах IDEF3. Множественная декомпозиция.

 

Декомпозиция работ. В 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). Это позволяет аналитику вносить информацию в удобном в данный момент времени виде. Важно учитывать, что модели могут быть реорганизованы, например для их представления в более презентабельном виде. Выбор формата для презентации часто имеет важное значение для организации модели, поскольку комбинация перекрестков занимает значительное место на диаграмме и использование иерархии перекрестков затрудняет расположение работ на диаграмме.

48. Правила построения диаграмм в нотации DFD. Основные рекомендации и отличия от IDEF0.

 

СМ ВОПРОС 42

⇐ Предыдущая123

Поделиться: