Лекция 7ВР (1088292), страница 2
Текст из файла (страница 2)
Это и понятно – каждый процесс должен происходить по каким-то правилам(отображаемым управляющей дугой) и должен выдавать некоторый результат (выходящаядуга), иначе его рассмотрение не имеет никакого смысла.При построении IDEF0 – диаграмм важно правильно отделять входящие интерфейсныедуги от управляющих, что часто бывает непросто. К примеру, на рисунке 2 изображенфункциональный блок “Обработать заготовку”.В реальном процессе рабочему, производящему обработку, выдают заготовку итехнологические указания по обработке (или правила техники безопасности при работе состанком). Ошибочно может показаться, что и заготовка и документ с технологическимиуказаниями являются входящими объектами, однако это не так.
На самом деле в этомпроцессе заготовка обрабатывается по правилам отраженным в технологическихуказаниях, которые должны соответственно изображаться управляющей интерфейснойдугой.Рисунок 2.Другое дело, когда технологические указания обрабатываются главным технологом и вних вносятся изменения (рис. 3). В этом случае они отображаются уже входящейинтерфейсной дугой, а управляющим объектом являются, например, новыепромышленные стандарты, исходя из которых производятся данные изменения.Рисунок 3.Приведенные выше примеры подчеркивают внешне схожую природу входящих иуправляющих интерфейсных дуг, однако для систем одного класса всегда естьопределенные разграничения. Например, в случае рассмотрения предприятий иорганизаций существуют пять основных видов объектов: материальные потоки (детали,товары, сырье и т.д.), финансовые потоки (наличные и безналичные, инвестиции и т.д.),потоки документов (коммерческие, финансовые и организационные документы), потокиинформации (информация, данные о намерениях, устные распоряжения и т.д.) и ресурсы(сотрудники, станки, машины и т.д.).
При этом в различных случаях входящими иисходящими интерфейсными дугами могут отображаться все виды объектов,управляющими только относящиеся к потокам документов и информации, а дугамимеханизмами только ресурсы.Обязательное наличие управляющих интерфейсных дуг является одним из главныхотличий стандарта IDEF0 от других методологий классов DFD (Data Flow Diagram) иWFD (Work Flow Diagram).Третьим основным понятием стандарта IDEF0 является декомпозиция (Decomposition).Принцип декомпозиции применяется при разбиении сложного процесса на составляющиеего функции.
При этом уровень детализации процесса определяется непосредственноразработчиком модели.Декомпозиция позволяет постепенно и структурированно представлять модель системы ввиде иерархической структуры отдельных диаграмм, что делает ее менее перегруженной илегко усваиваемой.Модель IDEF0 всегда начинается с представления системы как единого целого – одногофункционального блока с интерфейсными дугами, простирающимися за пределырассматриваемой области. Такая диаграмма с одним функциональным блоком называетсяконтекстной диаграммой, и обозначается идентификатором “А-0”.В пояснительном тексте к контекстной диаграмме должна быть указана цель (Purpose)построения диаграммы в виде краткого описания и зафиксирована точка зрения(Viewpoint).Определение и формализация цели разработки IDEF0 – модели является крайне важныммоментом.
Фактически цель определяет соответствующие области в исследуемой системе,на которых необходимо фокусироваться в первую очередь. Например, если мымоделируем деятельность предприятия с целью построения в дальнейшем на базе этоймодели информационной системы, то эта модель будет существенно отличаться от той,которую бы мы разрабатывали для того же самого предприятия, но уже с цельюоптимизации логистических цепочек.Точка зрения определяет основное направление развития модели и уровень необходимойдетализации. Четкое фиксирование точки зрения позволяет разгрузить модель,отказавшись от детализации и исследования отдельных элементов, не являющихсянеобходимыми, исходя из выбранной точки зрения на систему.
Например,функциональные модели одного и того же предприятия с точек зрения главного технологаи финансового директора будут существенно различаться по направленности ихдетализации. Это связано с тем, что в конечном итоге, финансового директора неинтересуют аспекты обработки сырья на производственных станках, а главному технологуни к чему прорисованные схемы финансовых потоков. Правильный выбор точки зрениясущественно сокращает временные затраты на построение конечной модели.В процессе декомпозиции, функциональный блок, который в контекстной диаграммеотображает систему как единое целое, подвергается детализации на другой диаграмме.Получившаяся диаграмма второго уровня содержит функциональные блоки,отображающие главные подфункции функционального блока контекстной диаграммы иназывается дочерней (Child diagram) по отношению к нему (каждый из функциональныхблоков, принадлежащих дочерней диаграмме соответственно называется дочернимблоком – Child Box).
В свою очередь, функциональный блок - предок называетсяродительским блоком по отношению к дочерней диаграмме (Parent Box), а диаграмма, ккоторой он принадлежит – родительской диаграммой (Parent Diagram). Каждая изподфункций дочерней диаграммы может быть далее детализирована путем аналогичнойдекомпозиции соответствующего ей функционального блока. Важно отметить, что вкаждом случае декомпозиции функционального блока все интерфейсные дуги, входящие вданный блок, или исходящие из него фиксируются на дочерней диаграмме. Этимдостигается структурная целостность IDEF0 – модели.
Наглядно принцип декомпозициипредставлен на рисунке 4. Следует обратить внимание на взаимосвязь нумерациифункциональных блоков и диаграмм - каждый блок имеет свой уникальный порядковыйномер на диаграмме (цифра в правом нижнем углу прямоугольника), а обозначение подправым углом указывает на номер дочерней для этого блока диаграммы. Отсутствие этогообозначения говорит о том, что декомпозиции для данного блока не существует.Часто бывают случаи, когда отдельные интерфейсные дуги не имеет смысла продолжатьрассматривать в дочерних диаграммах ниже какого-то определенного уровня в иерархии,или наоборот - отдельные дуги не имеют практического смысла выше какого-то уровня.Например, интерфейсную дугу, изображающую “деталь” на входе в функциональныйблок “Обработать на токарном станке” не имеет смысла отражать на диаграммах болеевысоких уровней – это будет только перегружать диаграммы и делать их сложными длявосприятия.
С другой стороны, случается необходимость избавиться от отдельных“концептуальных” интерфейсных дуг и не детализировать их глубже некоторого уровня.Для решения подобных задач в стандарте IDEF0 предусмотрено понятиетуннелирования. Обозначение “туннеля” (Arrow Tunnel) в виде двух круглых скобоквокруг начала интерфейсной дуги обозначает, что эта дуга не была унаследована отфункционального родительского блока и появилась (из “туннеля”) только на этойдиаграмме. В свою очередь, такое же обозначение вокруг конца (стрелки) интерфейснойдуги в непосредственной близи от блока – приёмника означает тот факт, что в дочернейпо отношению к этому блоку диаграмме эта дуга отображаться и рассматриваться небудет. Чаще всего бывает, что отдельные объекты и соответствующие им интерфейсныедуги не рассматриваются на некоторых промежуточных уровнях иерархии – в такомслучае, они сначала “погружаются в туннель”, а затем, при необходимости “возвращаютсяиз туннеля”.Последним из понятий IDEF0 является глоссарий (Glossary).
Для каждого из элементовIDEF0: диаграмм, функциональных блоков, интерфейсных дуг существующий стандартподразумевает создание и поддержание набора соответствующих определений, ключевыхслов, повествовательных изложений и т.д., которые характеризуют объект, отображенныйданным элементом. Этот набор называется глоссарием и является описанием сущностиданного элемента. Например, для управляющей интерфейсной дуги “распоряжение обоплате” глоссарий может содержать перечень полей соответствующего дуге документа,необходимый набор виз и т.д.
Глоссарий гармонично дополняет наглядный графическийязык, снабжая диаграммы необходимой дополнительной информацией.Рисунок 4. Декомпозиция функциональных блоков.Принципы ограничения сложности IDEF0-диаграммОбычно IDEF0-модели несут в себе сложную и концентрированную информацию, и длятого, чтобы ограничить их перегруженность и сделать удобочитаемыми, всоответствующем стандарте приняты соответствующие ограничения сложности:•Ограничение количества функциональных блоков на диаграмме тремя-шестью.Верхний предел (шесть) заставляет разработчика использовать иерархии приописании сложных предметов, а нижний предел (три) гарантирует, что насоответствующей диаграмме достаточно деталей, чтобы оправдать ее создание;•Ограничение количества подходящих к одному функциональному блоку(выходящих из одного функционального блока) интерфейсных дуг четырьмя.Разумеется, строго следовать этим ограничениям вовсе необязательно, однако, какпоказывает опыт, они являются весьма практичными в реальной работе.Дисциплина групповой работы над разработкой IDEF0-моделиСтандарт IDEF0 содержит набор процедур, позволяющих разрабатывать и согласовыватьмодель большой группой людей, принадлежащих к разным областям деятельностимоделируемой системы.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
