Добавлен: 15.11.2018
Просмотров: 1955
Скачиваний: 7
6
Технологические
указания
Рабочий Петров И.
Обработать
заготовку
А0
Корректировать
технологически
е указания
А0
крайней мере одну управляющую интерфейсную дугу и одну исходящую. Это и понятно - каждый процесс должен
протекать по каким-то правилам (отображаемым управляющей дугой), а также выдавать некоторый результат
(выходящая дуга), иначе его рассмотрение не имеет смысла.
При построении IDEF0 - диаграмм важно правильно отделять входящие интерфейсные дуги от
управляющих, что часто бывает непросто. К примеру, на рис. 2 изображен функциональный блок «Обработать
заготовку».
В реальном процессе рабочему, производящему обработку, выдают заготовку и технологические указания
по обработке (или правила техники безопасности при работе на станке). Ошибочно может показаться, что и
заготовка и документ с технологическими указаниями являются входящими объектами. На самом деле, в этом
процессе заготовка обрабатывается по правилам, отраженным в технологических указаниях, которые должны,
соответственно, изображаться управляющей интерфейсной дугой.
В другом случае (рис.3) технологические указания обрабатываются главным технологом в целях внесения
изменений. При этом старые указания отображаются уже входящей интерфейсной дугой, а управляющим
объектом являются, например, новые промышленные стандарты, исходя из которых проводятся данные
изменения.
Заготовка
Деталь
Рис.2. Представление функции «Обработать заготовку»
Технологические
указания
Новые промышленные
стандарты
Новые
технологические
указания
Рис.3. Представление функции технолога
Приведенные выше примеры подчеркивают внешне схожую природу входящих и управляющих
интерфейсных дуг. Однако для систем одного класса всегда есть определенные разграничения. Например, в случае
рассмотрения предприятий и организаций существуют пять основных видов объектов: материальные потоки
(детали, товары, сырье и т.д.), финансовые потоки (наличные и безналичные средства, инвестиции и т.д.), потоки
документов (коммерческие, финансовые и организационные документы), потоки информации (данные о
намерениях, устные распоряжения и т.д.) и ресурсы (сотрудники, станки, машины и т.д.). При этом в различных
случаях входящими и исходящими интерфейсными дугами могут отображаться все виды объектов, управляющими
- только относящиеся к потокам документов и информации, а дугами-механизмами - только ресурсы.
Обязательное наличие управляющих интерфейсных дуг является одним из главных отличий стандарта
IDEF0 от других методов (например, DFD (Data Flow Diagram) или WFD (Work Flow Diagram)).
Третьим основным понятием стандарта IDEF0 является декомпозиция (Decomposition). Операция
декомпозиции применяется при разбиении сложного процесса на составляющие его функции. При этом уровень
детализации процесса определяется непосредственно разработчиком модели.
Декомпозиция позволяет постепенно и структурировано представлять модель системы в виде
иерархической структуры отдельных диаграмм, что делает ее менее перегруженной и легко читаемой.
Главный технолог
7
Модель IDEF0 всегда начинается с представления системы как единого целого - одного функционального
блока с интерфейсными дугами, выходящими за пределы рассматриваемой области. Такая диаграмма с одним
функциональным блоком называется контекстной диаграммой, и обозначается идентификатором А-0.
В пояснении к контекстной диаграмме должна быть указана цель (Purpose) построения диаграммы в виде
краткого описания и зафиксирована точка зрения (Viewpoint).
Определение и формализация цели разработки IDEF0 - модели является крайне важным моментом.
Фактически, цель определяет соответствующие области в исследуемой системе, на которых необходимо
сосредоточиться в первую очередь. Например, если моделируется деятельность предприятия с целью построения
его информационной системы, то построенная модель будет существенно отличаться от той, которая была
разработана для того же самого предприятия, но уже с целью оптимизации технологических процессов.
При построении модели точка зрения определяет основное направление развития модели и уровень
необходимой детализации. Четкое фиксирование точки зрения позволяет разгрузить модель, отказавшись от
детализации и исследования отдельных элементов, не являющихся необходимыми, исходя из выбранной цели.
Например, функциональные модели одного и того же предприятия с точек зрения главного технолога и
финансового директора будут существенно различаться по направленности их детализации. Это связано с тем, что
в конечном итоге, финансового директора мало интересуют производственные аспекты обработки сырья, а
главному технологу ни к чему прорисованные схемы финансовых потоков. Правильный выбор точки зрения
существенно сокращает временные затраты на построение конечной модели.
В процессе декомпозиции функциональный блок, который в контекстной диаграмме отображает систему
как единое целое, подвергается детализации на другой диаграмме. Получившаяся диаграмма второго уровня
содержит функциональные блоки, отображающие главные подфункции функционального блока контекстной
диаграммы и называется дочерней (Child diagram) no отношению к нему (каждый из функциональных блоков,
принадлежащих дочерней диаграмме соответственно называется дочерним блоком - Child Box). В свою очередь,
функциональный блок - предок называется родительским блоком по отношению к дочерней диаграмме (Parent
Box), а диаграмма, к которой он принадлежит - родительской диаграммой (Parent Diagram). Каждая из
подфункций дочерней диаграммы может быть далее детализирована путем аналогичной декомпозиции
соответствующего ей функционального блока. Важно отметить, что в каждом случае декомпозиции
функционального блока все интерфейсные дуги, входящие в данный блок, или исходящие из него фиксируются на
дочерней диаграмме. Этим достигается структурная целостность IDEF0 - модели. Графически механизм
декомпозиции показан на рис.4.
Следует обратить внимание на взаимосвязь нумерации функциональных блоков и диаграмм - каждый
блок имеет свой уникальный порядковый номер на диаграмме (цифра в правом нижнем углу прямоугольника), а
обозначение под правым углом указывает на номер дочерней для этого блока диаграммы. Отсутствие этого
обозначения говорит о том, что декомпозиции для данного блока не существует.
8
Рис.4. Декомпозиция функциональных блоков
Часто бывают случаи, когда отдельные интерфейсные дуги не имеет смысла продолжать рассматривать в
дочерних диаграммах ниже какого-то определенного уровня в иерархии, или наоборот - отдельные дуги не имеют
практического смысла выше какого-то уровня. Например, интерфейсную дугу, изображающую «деталь» на входе
в функциональный блок «Обработать на токарном станке» не имеет смысла отражать на диаграммах более
высоких уровней - это будет только перегружать диаграммы и делать их сложными для восприятия. С другой
стороны, иногда необходимо избавиться от отдельных «концептуальных» интерфейсных дуг и не детализировать
их глубже некоторого уровня. Для решения подобных задач в стандарте IDEF0 предусмотрено понятие
туннелирования. Обозначение туннеля {Arrow Tunnel) в виде двух круглых скобок вокруг начала интерфейсной
дуги обозначает, что эта дуга не была унаследована от функционального родительского блока и появилась (из
туннеля) только на этой диаграмме. В свою очередь, такое же обозначение вокруг конца интерфейсной дуги
(стрелки) в непосредственной близи от блока-приемника означает тот факт, что в дочерней, по отношению к этому
блоку, диаграмме эта дуга отображаться и рассматриваться не будет. Чаще всего отдельные объекты и
соответствующие им интерфейсные дуги не рассматриваются на некоторых промежуточных уровнях иерархии. В
таком случае они сначала «погружаются в туннель», а затем, при необходимости, «возвращаются из туннеля».
Последним из понятий IDEF0 является глоссарий (Glossary). Для каждого из элементов IDEF0 (диаграмм,
функциональных блоков, интерфейсных дуг) существующий стандарт подразумевает создание и поддержание
набора соответствующих определений, ключевых слов, повествовательных изложений и т.д., которые
А.0
1
А4
А0
3
А4
А42
Более
обобщѐнно
Более
детально
Этот функциональный блок
является родительским по
отношению к диаграмме А
4
Номер А
42
означает, что
данный функциональный
блок имеет декомпозицию
– дочернюю диаграмму с
номером А42
0
2
3
4
1
2
1
2
3
9
характеризуют объект, отображенный данным элементом. Этот набор называется глоссарием и является
описанием сущности данного элемента. Например, для управляющей интерфейсной дуги «распоряжение об
оплате» глоссарий может содержать перечень полей соответствующего дуге документа, необходимый набор виз и
т.д. Глоссарий гармонично дополняет наглядный графический язык, снабжая диаграммы необходимой дополни-
тельной информацией.
Обычно IDEF0-модели несут в себе сложную и концентрированную информацию. Для ограничения их
перегруженности и удобочитаемости в стандарте приняты соответствующие ограничения сложности:
ограничение количества функциональных блоков на диаграмме тремя-шестью. Верхний предел (шесть)
заставляет разработчика использовать иерархии при описании сложных объектов, а нижний предел (три)
гарантирует, что на соответствующей диаграмме достаточно деталей, чтобы оправдать ее создание;
ограничение количества подходящих к одному функциональному блоку (выходящих из одного
функционального блока) интерфейсных дуг четырьмя.
Разумеется, строго следовать этим ограничениям вовсе необязательно, однако они являются весьма
действенными в реальной работе.
Стандарт IDEF0 содержит набор процедур, позволяющих разрабатывать и согласовывать модель большой
группой людей, принадлежащих к разным областям деятельности моделируемой системы. Обычно процесс
разработки является итеративным и состоит из следующих условных этапов:
1. Создание модели группой специалистов, относящихся к различным сферам деятельности предприятия. Эта
группа в терминах IDEF0 называется авторами {Authors). Построение первоначальной модели является
динамическим процессом, в течение которого авторы опрашивают компетентных лиц о структуре различных
процессов. На основе имеющихся положений, документов и результатов опросов создается черновик (Model
Draff) модели.
2. Распространение черновика для рассмотрения, согласований и комментариев. На этой стадии происходит
обсуждение черновика модели с широким спектром компетентных лиц (в терминах IDEF0- читателей) на
предприятии. При этом каждая из диаграмм черновой модели письменно критикуется и комментируется, а
затем передается автору. Автор, в свою очередь, также письменно соглашается с критикой или отвергает ее с
изложением логики принятия решения и вновь возвращает откорректированный черновик для дальнейшего
рассмотрения. Этот цикл продолжается до тех пор, пока авторы и читатели не придут к единому мнению.
3. Официальное утверждение модели. Утверждение согласованной модели происходит руководителем рабочей
группы в том случае, если у авторов модели и читателей отсутствуют разногласия по поводу ее адекватности.
Окончательная модель представляет собой согласованное представление о предприятии (системе) с заданной
точки зрения и для заданной цели.
Наглядность графического языка IDEF0 делает модель вполне читаемой и для лиц, которые не принимали
участия в проекте ее создания, а также эффективной для проведения показов и презентаций. В дальнейшем, на
базе построенной модели могут быть организованы новые проекты, нацеленные на производство изменений на
предприятии (в системе).
Обобщая сказанное, моделирование с использованием метода IDEF0 включает:
1. Концептуальный этап (определение объекта и цели моделирования, обоснование точки зрения, подбор
субъектов и установление сроков моделирования);
2. Этап разработки модели (построение IDEF0-диаграмм, проведение циклов «автор-читатель»);
3. Проведение экспериментов с моделью (изучение модели «AS IS», получение ответов на вопросы типа «что
будет если...»);
4. Интерпретация результатов (построение модели «ТО BE», документирование результатов).
1.2
Задание № 1. Создание контекстной диаграммы
1. Запустите AllFusion Process Modeler.
2. В появившемся диалоге ModelMart Connection Manager (только для AllFusion Process Modeler версии 4.1 и
выше) нажмите на кнопку Cancel.
3. 3. Автоматически либо в момент создания новой модели появляется диалог «I would like to». Внесите имя
модели «Деятельность компании Quill» и выберите Type - IDEF0. Нажмите ОК.
4. Появляется диалог «Properties for New Models», в котором можно выставить значения основных свойств новой
модели.
5. Автоматически создается контекстная диаграмма.
6. Закладки в Model Explorer (окно слева) позволяют переходить от одного режима просмотра модели к другому
и предоставляют возможность быстро переходить от одной диаграммы к другой.
7. Если Вам непонятно как выполнить то или иное действие, Вы можете вызвать помощь - клавиша F1 или меню
Help.
8. Перейдите в меню Model/Model Properties. В закладке General диалога Model Properties следует внести имя
модели «Деятельность компании Quill», имя проекта «Модель деятельности Quill», имя автора и тип модели -
10
Time Frame {AS-IS}.
9. В полях закладки «Purpose» внесите Цель - «Цель: Моделировать текущие (AS-IS) бизнес-процессы компании
Quill» и Точку зрения - «Точка зрения: Директор».
10. В поля закладки «Definition» внесите определение «Эта учебная модель, описывающая деятельность компании
Quill» и «Scope» - «Общее управление бизнесом компании: исследование рынка, закупка компонент, сборка,
тестирование и продажа продуктов».
11. В закладке Sourse - «Материалы курса по работе с AllFusion Process Modeler».
12. Перейдите в меню Diagram/Diagram Properties и установите свойства диаграммы.
13. Перейдите на контекстную диаграмму и правой кнопкой мыши щелкните по работе. В контекстном меню
выберите Name Editor. В закладке Name внесите имя «Деятельность компании Quill».
14. В закладке Definition внесите определение «Текущие бизнес-процессы компании Quill».
15. В закладке Status установите WORKING.
16. Создайте стрелки на контекстной диаграмме, как показано в табл.2.
Таблица 2 Стрелки контекстной диаграммы
Наименование
(Arrow Name)
Назначение
(Arrow Definition)
Тип
(Arrow Type)
Бухгалтерская система
Оформление счетов, оплата счетов, работа с
заказами
Mechanism
Звонки клиентов
Запросы информации, заказы, тех. поддержка и тд. Input
Правила и процедуры
Правила продаж, инструкции по сборке, процедуры
тестирования, критерии производительности
Control
Проданные продукты
Настольные и портативные компьютеры
Output
1.3
Задание № 2. Создание диаграммы декомпозиции
1. Выберите кнопку перехода на нижний уровень в палитре инструментов и в диалоге Activity Box Count
установите число работ на диаграмме нижнего уровня - 3 и нажмите ОК. Автоматически будет создана
диаграмма декомпозиции. Правой кнопкой мыши щелкните по работе, выберите Name Editor и внесите имя
работы. Повторите операцию для всех трех работ. Затем внесите определение, статус и источник для каждой
работы согласно табл. 3.
Таблица 3 Описание работ
Наименование
(Activity Name)
Описание
(Definition)
Состояние
(Status)
Источник
(Source)
Продажи и марке-
тинг
Телемаркетинг и презентации,
выставки
WORKING
Материалы курса по работе с AHFusion
Process Modeler
Сборка и тестиро-
вание компьютеров
Сборка и тестирование на-
стольных и портативных
компьютеров
WORKING
Материалы курса по работе с AHFusion
Process Modeler
Отгрузка и получе-
ние
Отгрузка заказов клиентам и
получение компонент от
поставщиков
WORKING
Материалы курса по работе с AHFusion
Process Modeler
2. Для изменения свойств работ после их внесения в диаграмму можно воспользоваться словарем объектов
модели. Вызов словаря - Model/Diagram Object Editor... или Dictionary/Activity... Результат построения показан
на рис.5. Описав имя и свойства работы в словаре, ее можно будет внести в диаграмму позже с помощью
кнопки в палитре инструментов. При этом нельзя удалять работу из словаря, если она используется на какой-
либо диаграмме. Если Вы удалите работу из диаграммы, из словаря она не удаляется. Имя и описание такой
работы может быть использовано в дальнейшем. Для добавления работы в словарь щелкните по кнопке Clear,
внесите имя и свойства работы, затем щелкните по Add. Для удаления всех имен работ, не использующихся в
модели, щелкните по Purge.