Логистика и CALS. Занятие 2 Изучение и освоение стандартов (IDEF3) 2. Основы стандарта IDEF3 2.1. Предназначение IDEF3 IDEF3 является стандартом документирования информационных, технологических и иных процессов и предоставляет инструментарий для наглядного исследования и моделирования их сценариев. Сценарием (Scenario) называется описание последовательности изменений свойств объекта, в рамках рассматриваемого процесса (например, описание последовательности этапов обработки детали в цеху и изменение её свойств после прохождения каждого этапа). Описание процесса может состоять из одного или нескольких сценариев. Сценарий определяется как повторяющаяся ситуация, некий набор ситуаций, описывающих типичный класс проблем в системе или организации, обстановка или среда, в которой происходит рассматриваемый процесс. Основным назначением сценария является определение контекста описания через присвоение сценарию имени. Таким образом, сценарий устанавливает ориентацию и границы описания. Исполнение каждого сценария сопровождается соответствующими потоками информации, например, в виде документов. На промышленном предприятии документооборот производственных процессов состоит из двух основных потоков: документов, определяющих структуру и последовательность процесса (технологических указаний, описаний стандартов и т.д.); документов, отображающих ход его выполнения (результатов тестов и экспертиз, отчетов о браке, и т.д.). Для эффективного управления любым процессом, необходимо иметь детальное представление о его сценарии и структуре сопутствующего документооборота. Средства документирования и моделирования IDEF3 позволяют выполнять следующие задачи: документировать имеющиеся данные о технологии процесса, выявленные в процессе предпроектного обследования путем опроса компетентных сотрудников, ответственных за организацию рассматриваемого процесса; определять и анализировать точки слияния и разделения потоков информации; определять ситуации, в которых требуется принятие решения, влияющего на жизненный цикл процесса; содействовать принятию оптимальных решений при реорганизации процессов; разрабатывать модели процессов, по принципу "КАК БУДЕТ, ЕСЛИ..." IDEF3 обеспечивает аналитика методологией структурированного подхода и графическим языком для наглядного представления с необходимой степенью детализации знаний об очередности событий и действий описываемого процесса. В отличие от некоторых методик описаний процессов, IDEF3 не ограничивает аналитика чрезмерно жесткими рамками синтаксиса, что может привести к созданию неполных или противоречивых моделей. IDEF3 имеет прямую взаимосвязь с IDEF0 – каждая функция (функциональный блок IDEF0) может быть представлена в виде отдельного процесса средствами IDEF3. Может быть создана смешанная модель (см. рисунок ниже). 1 Логистика и CALS. Занятие 2 Изучение и освоение стандартов (IDEF3) 2.2. Два типа диаграмм в IDEF3 Для описания процесса в IDEF3 определены две стратегии и, соответственно, два типа диаграмм: process-centered strategy – стратегия описания процесса как последовательности выполняемых действий. Диаграммы этого типа получили название Process Flow Description Diagrams (PFDD) – диаграммы потокового описания процесса или диаграммы работ WFD (Work Flow Diagram); object-centered strategy – стратегия описания процесса как последовательности изменений состояний объекта, над которым выполняются действия. Диаграммы такого типа получили название Object State Transition Network (OSTN) – диаграммы последовательности изменений состояний объекта. Описание процесса в IDEF3 может содержать диаграммы PFDD и OSTN или диаграммы какоголибо одного типа. Пример. Пусть требуется описать процесс окраски детали в производственном цеху на предприятии. С помощью диаграмм PFDD документируется последовательность и описание стадий обработки детали в рамках исследуемого технологического процесса. Диаграммы OSTN используются для иллюстрации трансформаций детали, которые происходят на каждой стадии обработки. Процесс обработки состоит непосредственно из самой окраски, производимой на специальном оборудовании и этапа контроля ее качества, который определяет, нужно ли деталь окрасить заново (в случае несоответствия стандартам и выявления брака) или отправить ее в дальнейшую обработку. Сценарий можно описать в следующем виде: Деталь поступает в окрасочный цех, подготовленная к окраске. В процессе окраски наносится один слой эмали при высокой температуре. После этого, производится сушка детали, после которой начинается этап проверки качества нанесенного слоя. Если тест подтверждает недостаточное качество нанесенного слоя (недостаточную толщину, неоднородность и т.д.), то деталь заново пропускается через цех окраски. Если деталь успешно проходит контроль качества, то она отправляется в следующий цех для дальнейшей обработки. На рисунке изображена диаграмма PFDD, являющаяся графическим отображением сценария обработки детали. Прямоугольники на диаграмме PFDD называются функциональными элементами или элементами поведения (Unit of Behavior, UOB) и обозначают событие, стадию процесса или принятие решения. Каждый UOB имеет свое имя, отображаемое в глагольном наклонении и уникальный номер. Стрелки или линии являются отображением перемещения детали между UOBблоками в ходе процесса. 2 Логистика и CALS. Занятие 2 Изучение и освоение стандартов (IDEF3) Пример PFDD диаграммы Объект, обозначенный J1, называется перекрестком (Junction). Перекрестки используются для отображения логики взаимодействия стрелок (потоков) при слиянии и разветвлении или для отображения множества событий, которые могут или должны быть завершены перед началом следующей работы. Различают перекрестки для слияния (Fan-in Junction) и разветвления (Fan-out Junction) стрелок. Перекресток не может использоваться одновременно для слияния и для разветвления. При внесении перекрестка в диаграмму необходимо указать тип перекрестка. Все перекрестки в PFDD диаграмме нумеруются, каждый номер имеет префикс "J". Каждый функциональный блок UOB может иметь последовательность декомпозиций, и может быть детализирован с любой необходимой точностью. Под декомпозицией понимается представление каждого UOB с помощью отдельной IDEF3 диаграммы. Например, можно декомпозировать UOB "Окрасить Деталь", представив его отдельным процессом и построив для него свою PFDD диаграмму. При этом эта диаграмма будет называться дочерней, по отношению к изображенной (на рисунке выше), а та, соответственно, родительской. Номера UOB дочерних диаграмм имеют сквозную нумерацию, т.е., если родительский UOB имеет номер "1", то блоки UOB на его декомпозиции будут соответственно иметь номера "1.1", "1.2" и т.д. Применение принципа декомпозиции в IDEF3 позволяет структурировано описывать процессы с любым требуемым уровнем детализации. Важное замечание: стандарт и методология IDEF3 рассматривают функциональный модуль как некоторое обобщенное представление действия или события, то есть как представление некоторого типа действий, которое может иметь в различных ситуациях различные характеристики и свойства. Совокупность этих характеристик и свойств превращает действие, представляемое на диаграмме как некоторый тип действия, в конкретный его экземпляр или образец. Например, действие «Выписать счет за товар» может выполняться по-разному: просто выписать счет; проверить наличие нужного количества товара на складе, зарезервировать часть товара, уточнить в отделе маркетинга текущую цену на товар, уточнить в транспортном отделе тарифы на доставку товара, уточнить в бухгалтерии ставки налогов на данный вид товара, согласовать цену и количество товара с отделом продаж, выполнить какие-то другие действия и выписать счет; представить процесс выписки счета как набор действий, которые могут выполняться в различном порядке, часть из которых может выполняться или не выполняться в конкретном случае. Чтобы отобразить различные варианты детализации действий или событий в IDEF3 предусмотрена возможность многократной декомпозиции одного функционального модуля. Поэтому в диаграмме декомпозиции первая цифра номера модуля указывает номер декомпозируемого, то есть родительского модуля, а вторая цифра порядковый номер декомпозиции. Третья цифра указывает порядковый номер модуля в диаграммах описания процесса. Если диаграммы PFDD технологический процесс "С точки зрения наблюдателя", то другой класс диаграмм IDEF3 – OSTN – позволяет рассматривать тот же самый процесс "С точки зрения объекта". На рис.6 представлено отображение процесса окраски с точки зрения OSTN диаграммы. Состояния объекта (детали) и изменение состояния являются ключевыми понятиями OSTN диаграммы. 3 Логистика и CALS. Занятие 2 Изучение и освоение стандартов (IDEF3) Состояния объекта отображаются окружностями, а их изменения направленными линиями. Каждая линия имеет ссылку на соответствующий функциональный блок UOB, в результате которого произошло отображаемое ей изменение состояния объекта (см. рисунок ниже). 2.3. Правила формирования моделей бизнес-процессов в IDEF3 1. 2. 3. 4. Формат IDEF3 применяется для описания бизнес-процессов в виде потоков операций (работ). Точка зрения на модель должна быть документирована. Обычно это точка зрения владельца БП. Необходимо документировать цель модели — вопросы, на которые призвана ответить модель. Условные обозначения формата IDEF3 представлены в следующих таблицах 1 и 2. Таблица 1. Таблица 2. 4 Логистика и CALS. Занятие 2 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. Изучение и освоение стандартов (IDEF3) Операции (работы) обозначают преобразования потоков материальных, финансовых ресурсов и информации (документов, файлов). Операции изображаются прямоугольниками со сплошными границами и прямыми углами, при этом нижняя часть прямоугольника отделена сплошной линией. Каждая операция имеет имя и уникальный номер. Название операции выражается глаголом или отглагольным существительным. Номер операции используется для ее идентификации в модели. Стрелки связей обозначают взаимосвязи между выполняемыми операциями, которые могут выражаться через связь операций посредством потока объектов или последовательность выполнения операций во времени. Связь между операциями, выраженная как последовательность выполнения во времени может быть двух видов: связь предшествования; связь потоков объектов; связь-отношение. Связь предшествования показывает, что для начала работы одной операции необходимо завершение выполнения другой. Старшая связь изображается однонаправленной сплошной стрелкой с одним наконечником и может иметь имя, которое должно быть уникальным. Связь через потоки объектов изображается однонаправленной сплошной стрелкой с двойным наконечником и должна иметь уникальное имя, соответствующее единице потока. Связь-отношение показывает, что для выполнения операции нет необходимости в завершении выполнения другой операции, необходимо только начать выполнение этой операции. Связьотношение изображается однонаправленной пунктирной стрелкой с одним наконечником и может иметь имя, которое должно быть уникальным. При наличии стрелок со сложной топологией целесообразно повторить имя для удобства ее идентификации. Рекомендуется строить диаграммы IDEF3 так, чтобы стрелки, обозначающие связи были направлены слева направо, либо сверху вниз. Необходимо избегать необязательных пересечений стрелок. Следует минимизировать число петель и поворотов каждой стрелки. Стрелки изображаются вертикальными и горизонтальными отрезками прямых с одним или двумя наконечниками конце, пересекающиеся под прямым углом и сопряженные дугами. Стрелки соединяются с прямоугольниками, изображающими операции следующим образом: концы стрелок должны касаться внешней стороны прямоугольника, но не пересекать ее; стрелки должны подсоединяться к прямоугольнику на его сторонах, присоединение в углах не допускается; в отличие от IDEF0-диаграмм, стрелки могут подходить и исходить из любых граней прямоугольников. Следует обеспечить максимальное расстояние между прямоугольниками и поворотами стрелок, а также между прямоугольниками и пересечениями стрелок для облегчения чтения диаграммы. Одновременно уменьшается вероятность перепутать две разные стрелки. В случаях сложных диаграмм рекомендуется использовать различные цвета или «уровни» для прямоугольников и стрелок, позволяющие показывать или распечатывать только часть схемы и добиваться её большей наглядности. Объект модели типа «перекресток» используется для отображения логики взаимодействия стрелок при слиянии (Fan-in Junction – узел, собирающий множество стрелок в одну, указывая на необходимость условия завершенности работ-источников стрелок для продолжения процесса) и разветвлении (Fan-out Junction – узел, в котором единственная входящая в него стрелка ветвится, показывая, что работы, следующие за перекрестком, выполняются параллельно или альтернативно) или для отображения множества событий, которые могут или должны быть завершены перед началом выполнения следующей операции. Перекрестки используются для обозначения следующих ситуаций: окончание реализации одной операции может служить сигналом к началу выполнения нескольких операций, или же одна операция для своего запуска может ожидать окончания выполнения нескольких операций. 5 Логистика и CALS. Занятие 2 22. Изучение и освоение стандартов (IDEF3) Всё перекрестки на диаграмме имеют уникальные номера, каждый номер имеет префикс J. Стрелки могут сливаться и разветвляться только через перекрестки. Таблица 3 (типы используемых перекрестков) Комментарий: для синхронного «ИЛИ» при слиянии всегда должно быть больше одной операции, а при разветвлении не может быть меньше двух операций. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. Перекресток изображается квадратом, с двойной правой или левой границей. На одной диаграмме IDEF3 может быть создано несколько перекрестков различных типов. Перекресток не может использоваться одновременно для слияния и для разветвления. Каждому перекрестку для слияния должен предшествовать перекресток для разветвления. Перекресток для слияния «И» не может следовать за перекрестком для разветвления типа синхронного или асинхронного «ИЛИ». Перекресток для слияния «И» не может следовать за перекрестком для разветвления типа исключающего «ИЛИ». Перекресток для слияния типа исключающего «ИЛИ» не может следовать за перекрестком для разветвления типа «И». Перекресток, имеющий одну стрелку на одной стороне, должен иметь более одной стрелки на другой. Ссылки используются для указания некоторой дополнительной информации об операциях или перекрестках. Ссылки применяются для указания следующих свойств операций и перекрестков: участия важного объекта в выполнении операции; циклов выполнения операций; частоты выполнения операций; другой важной информации. Ссылки изображаются прямоугольником, похожим на прямоугольник, обозначающий операцию. Ссылки соединяются сплошной линией с операцией и перекрестком к которому они относятся. Объекты ссылок должны обладать уникальным именем. 6 Логистика и CALS. Занятие 2 35. Изучение и освоение стандартов (IDEF3) При внесении объектов ссылок помимо имени следует указывать тип объекта ссылки (таблица 4). Таблица 4 36. 37. 38. 39. 40. 41. 42. 43. 44. Диаграммы должны содержать не менее трех и не более 8 операций. При построении диаграмм в IDEF3 используется принцип декомпозиции. В результате декомпозиции образуется иерархическая структура диаграмм IDEF3. Родительская диаграмма, расположенная на вершине иерархической структуры диаграмм, должна быть либо диаграммой IDEF0, либо диаграммой DFD. В случае если IDEF3 диаграммы не дополняют IDEF0 модель или DFD модель, а являются самостоятельной моделью, то на указанной родительской диаграмме верхнего уровня должна быть обозначена цель моделирования и точка зрения создателя модели. В качестве контекстной диаграммы рекомендуется использовать контекстную диаграмму, выполненную в IDEF0 нотации. На вершине дерева декомпозиции диаграмм должна находится либо контекстная диаграмма в нотации IDEF0 с указанием цели моделирования и точки зрения, либо IDEF0 или DFD диаграмма (в случае если IDEF3-диаграммы дополняют модель в нотации IDEF0 или DFD). Каждая операция, не имеющая декомпозиции, помечается небольшой диагональной чертой, расположенной в левом верхнем углу прямоугольника, изображающего эту операцию. Диаграммы должны быть декомпозированы до уровня, на котором присутствуют элементарные операции обработки (например, конкретных документов или совокупности документов). В ссылках на операции обработки должны быть указания на то, что данная операция обрабатывает (например, документы). 2.4. Продолжение примера описания основных бизнес-процессов торговой организации. Построение IDEF3 диаграмм. Постановка задачи и описания бизнес-процессов верхнего уровня приведены в разделе 1.8. Задание: Основываясь на приведенных описаниях бизнес-процессов «Управлять движением денежных средств» и «Обеспечить своевременные и полные расчеты с ГОСУДАРСТВОМ» необходимо в уже созданной модели (см. практическое занятие 1, задание для самостоятельной работы №1 и 2) построить детализацию этих процессов в нотации IDEF3. Таким образом, будет создана смешанная модель. Важные замечания. Создание IDEF3 диаграммы аналогично созданию IDEF0 диаграммы. Объекты IDEF3 диаграммы (блоки, перекрестки, ссылочные элементы, стрелки) представлены на соответствующей панели инструментов. 7 Логистика и CALS. Занятие 2 Изучение и освоение стандартов (IDEF3) При создании IDEF3 диаграммы как детализации IDEF0 диаграммы, рамочные стрелки (входы, выходы, управления) родительского блока на дочерней диаграмме должны быть представлены в виде ссылочных элементов. Для этого, на диаграмме надо создать объекты Referent (тип объекта выбирается из панели инструментов, указателем мыши задается позиция объекта на диаграмме, и нажатием левой клавиши мыши создается соответствующий объект). При этом в открывшемся окне надо указать, что собой представляет данный ссылочный объект – (стрелка, сущность, или нечто иное). В нашем случае надо выбрать тип «стрелка», и из открывшегося списка выбрать имя требуемой рамочной стрелки. Создаваемые диаграммы должны соответствовать стандарту IDEF3. Нарушение стандарта недопустимо, но есть одно исключение – число блоков на диаграмме может быть больше 8. Блоки должны представлять собой операции, не требующие (в контексте примера) дальнейшей детализации. Соответствующие IDEF3 диаграммы приведены ниже. 8 Логистика и CALS. Занятие 2 Изучение и освоение стандартов (IDEF3) 9 Логистика и CALS. Занятие 2 Изучение и освоение стандартов (IDEF3) 2.5. Задание на самостоятельную работу 1 задание. В уже имеющейся модели создать IDEF3 диаграммы для процессов «Управлять движением денежных средств» и «Обеспечить своевременные и полные расчеты с ГОСУДАРСТВОМ». Для процесса «Обеспечить своевременные и полные расчеты с ГОСУДАРСТВОМ» необходимо ответить на вопрос: как надо изменить диаграмму, если налогов (и связанных расчетов) несколько? Внести соответствующие изменения в диаграмму. 2 задание. Исходной информацией служит построенная смешанная модель основных бизнес-процессов торговой организации. Каждая бригада выполняет одну и ту же задачу – определение функций, составляющих бизнес-процесс «Вести складской учет», логику их взаимодействия, и данные, необходимые для их выполнения. Этот процесс является внутренним процессом процесса «Выполнить заявку ПОКУПАТЕЛЯ» и должен быть реализован в модели. Здесь могут быть варианты: 1). Процесс реализован отдельным блоком – тогда необходимо построить IDEF3 дочернюю диаграмму для этого блока. 2). Процесс распределен по нескольким блокам. Тогда в каждом таком блоке должна быть детализирована (IDEF3 диаграммой) та функция, которая соответствует данному процессу. Эта работа должна выполняться в рамках рассматриваемого примера построения модели основных бизнес-процессов торговой организации и в опоре на развернутые описания бизнес-процессов контекстной модели и ее детализации, в том числе на вышеприведенное описание необходимых функций бизнес-процесса. Требования к выполнению заданий: задание выполняется теми же бригадами (в бригаде не больше 3 человек); Так как создаваемая модель – смешанная (содержит IDEF0 и IDEF3 диаграммы), то она должна соответствовать требованиям стандарта IDEF0 и стандарта IDEF3, нарушение стандарта не допустимо (кроме приведенного в разделе 2.4 исключения). Модель не должна содержать в глоссарии определения для неиспользуемых объектов. Для созданных дочерних диаграмм (всех их объектов), в глоссарий должны быть внесены соответствующие определения. Полнота и завершенность определений влияет на оценку. Также на оценку влияет функциональная полнота диаграмм. Каждая бригада должна представить свою собственную модель, одинаковых моделей не должно быть. Если несколько бригад представляют одинаковую модель, то эта модель будет закреплена за бригадой, представившей данную модель первой. Каждая бригада должна защитить свою работу. Каждый студент получает оценку (не аттестован, неуд., удовл., хор., отл.). Полученная оценка является составной частью интегральной оценки за курс в целом (дифференцированный зачет). Методологически более подробно подходы, техники и приемы методологии функционального моделирования представлены в следующей литературе: Основная литература: 1. Прокофьев Г.И. Ранние стадии создания продукции: учеб. пособие. – СПб.: Изд-во СПбГЭТУ «ЛЭТИ», 2004. – 63 с. 2. Прокофьев Г.И. Ранние стадии проектирования сложных систем: учеб. пособие. – СПб.: Изд-во СПбГЭТУ «ЛЭТИ», 2015. – 123 с. Рекомендуемая литература: 1. Черемных С.В., Семенов И.О., Ручкин В.С. Структурный анализ систем: IDEF технологии. – М., Финансы и статистика, 2003. 2. Черемных С.В., Семенов И.О., Ручкин В.С. Структурный анализ систем. IDEF технологии: практикум. – М., Финансы и статистика, 2006. 10 Логистика и CALS. Занятие 3 Изучение и освоение стандартов (DFD) 3. Диаграммы потоков данных (DFD) 3.1. Общие замечания. Диаграммы потоков данных (data flow diagram) – диаграммы, применяемые для графического представления (flowchart) движения и обработки информации в организации или в каком-либо процессе. Обычно диаграммы этого типа используются для проведения анализа организации информационных потоков и являются графическими иерархическими спецификациями, описывающими систему с позиций потоков данных. Для диаграмм этого типа обычно применяется сокращенное обозначение DFD. DFDдиаграммы моделируют функции, которые система должна выполнять, но почти ничего не сообщают об отношениях между данными, а также о поведении системы в зависимости от времени - для этих целей используются диаграммы сущность-связь (ER) и диаграммы переходов состояний, соответственно. DFD позволяют представить систему с точки зрения данных, иллюстрируют внешние механизмы подачи данных, которые потребуют наличия специальных интерфейсов и выполняют ориентированное на данные секционирование всей системы. В DFD не показываются процессы, которые управляют собственно потоком данных. При интерпретации DFD-диаграммы используются следующие правила: функции преобразуют входящие потоки данных в выходящие; хранилища данных не изменяют потоки данных, а служат только для хранения поступающих объектов; преобразования потоков данных во внешних ссылках игнорируется. Диаграммы DFD могут быть построены с использованием традиционного структурного анализа, подобно тому, как строятся диаграммы IDEF0: строится физическая модель, отображающая текущее состояние дел; полученная модель преобразуется в логическую модель, которая отображает требования к существующей системе; строится модель, отображающая требования к будущей системе; строится физическая модель, на основе которой должна быть построена новая система. Альтернативным подходом является подход, применяемый при создании программного обеспечения, называемый событийным разделением (event partitioning), в котором различные диаграммы DFD выстраивают модель системы: логическая модель строится как совокупность процессов и документирования того, что эти процессы должны делать; с помощью модели окружения 1 система описывается как взаимодействующий с событиями из внешних сущностей объект; модель поведения 2 показывает, как система обрабатывает события. Полученные диаграммы с целью более наглядного представления системы могут быть декомпозированы. 1 Модель окружения (environment model) – обычно содержит описание цели системы, одну контекстную диаграмму и список событий. Контекстная диаграмма содержит один блок, изображающий систему в целом, внешние сущности, с которыми система взаимодействует. Не отменяется требование методологии четко определить цель, область и единую точку зрения на моделируемую систему. 2 Модель поведения (behavior model) –состоит из одной диаграммы, в которой каждый блок изображает каждое событие из модели окружения, могут быть добавлены хранилища для моделирования данных, которые необходимо запоминать между событиями. Потоки добавляются для связи с другими элементами, и диаграмма проверяется с точки зрения соответствия модели окружения. 11 Логистика и CALS. Занятие 3 Изучение и освоение стандартов (DFD) Для изображения DFD традиционно используются две различные нотации: Йодана (Yourdon) и Гейна-Сарсона (Gane-Sarson). 3.2. Основные элементы Основные элементы DFD в нотациях Йордона и Гейна-Сарсона 3.2.1. DFD-блоки. Представляют собой графическое изображение процесса (функции, работы, операции) по обработке или преобразованию информации (данных). Процесс преобразует входной поток данных в выходной в соответствии с действием, задаваемым именем процесса, смысл блока почти идентичен смыслу функциональных блоков IDEF0 и действиям IDEF3. Как и действия IDEF3, блоки DFD имеют входы и выходы, но не имеют управления и механизма исполнения как в IDEF0. Имя процесса должно содержать глагол в неопределенной форме с последующим дополнением (например, «вычислить максимальную высоту»). Каждый процесс должен иметь уникальный номер для ссылок на него внутри диаграммы. Этот номер может использоваться совместно с номером диаграммы для получения уникального индекса процесса во всей модели. Номер каждого блока может включать префикс (например, А.2.1 – префикс, номер родительского блока, уникальный номер процесса на данной диаграмме). По нотации Гейн-Сарсона DFD-блок изображается прямоугольником со скругленными углами. Каждая функция (процесс) может быть детализирована с помощью DFD нижнего уровня; когда дальнейшая детализация перестает быть полезной, переходят к выражению логики функции при помощи спецификации процесса (мини-спецификации). 3.2.2. Data flow (поток данных). Поток данных является механизмом моделирования передачи информации между участниками процесса информационного обмена (функциями, хранилищами данных, внешними ссылками). По нотации Гейн-Сарсона поток данных изображается именованной стрелкой между двумя объектами DFD-диаграммы, предпочтительно горизонтальной и/или вертикальной, причем направление стрелки указывает направление потока. Каждая стрелка должна иметь источник и цель. В отличие от стрелок IDEF0диаграммы (ICOM), стрелки DFD могут входить или выходить из любой стороны блока. Стрелки описывают, как объекты (включая данные) двигаются из одной части системы в другую. Стрелки могут сливаться и разветвляться, что позволяет описать декомпозицию 12 Логистика и CALS. Занятие 3 Изучение и освоение стандартов (DFD) стрелок. Каждый новый сегмент сливающейся или разветвляющейся стрелки может иметь собственное имя. При необходимости, поток может моделироваться либо двумя различными потоками, либо одним двунаправленным. Каждый поток должен иметь имя, расположенное вдоль или над стрелкой, выбранное таким образом, чтобы в наибольшей степени передавать смысл содержания потока пользователям, которые будут рассматривать диаграмму потоков данных. Структуры потоков данных и определения их компонентов хранятся и анализируются в словаре данных. 3.2.3. Data store (хранилище данных). Представляет собой графическое представление потоков данных импортируемых/экспортируемых из соответствующих баз данных. В отличие от стрелок, описывающих объекты в движении, хранилища данных изображают объекты в покое. Накопители данных являются неким прообразом базы данных информационной системы организации. Хранилища данных включаются в модель системы в том случае, если имеются этапы технологического цикла, на которых появляются данные, которые необходимо сохранять в памяти. Фактически хранилище представляет «срезы» потоков данных во времени. При отображении процесса сохранения данных стрелка потока данных направляется в хранилище данных, и, наоборот – из хранилища, если идет импорт данных. Хранилища данных предназначены для изображения неких абстрактных устройств для хранения информации, которую можно туда в любой момент времени поместить или извлечь, безотносительно к их конкретной физической реализации. Хранилища данных используются: в материальных системах - там, где объекты ожидают обработки, например в очереди; в системах обработки информации для моделирования механизмов сохранения данных для дальнейших операций. По нотации Гейн-Сарсона хранилище данных обозначается двумя горизонтальными линиями, замкнутыми с одного края. Каждое хранилище данных должно идентифицироваться для ссылки буквой D и произвольным числом в квадрате с левой стороны, например D5. Имя должно быть существительным и подбираться с учетом наибольшей информативности для пользователя. В модели может быть создано множество вхождений хранилищ данных, каждое из которых может иметь одинаковое имя и ссылочный номер. В случае, когда поток данных входит или выходит в/из хранилища, и его структура соответствует структуре хранилища, он должен иметь то же самое имя, которое нет необходимости отражать на диаграмме. Несмотря на это, рекомендуется всегда указывать имена потоков на диаграмме. 3.2.4. External reference или external entity (внешняя ссылка или внешняя сущность). Объект диаграммы потоков данных, являющийся источником или приемником информации извне модели. Внешние ссылки/сущности изображают входы и/или выходы, т.е. обеспечивают интерфейс с внешними объектами, находящимися вне моделируемой системы. Объекты, представленные внешними сущностями, не должны участвовать ни в какой обработке. Внешними ссылками системы обычно являются логические классы предметов или людей, представляющие собой источник или приемник сообщений, например, заказчики, конструкторы, технологи, производственные службы, кладовщики и т.д. 13 Логистика и CALS. Занятие 3 Изучение и освоение стандартов (DFD) Это могут быть специфические источники, такие, как бухгалтерия, информационнопоисковая система, служба нормоконтроля, склад. Если рассматриваемая система принимает данные от другой системы или передает данные в другую систему, то эта другая система является элементом внешней системы. По нотации Гейн-Сарсона пиктограмма внешней ссылки представляет собой оттененный прямоугольник верхняя и левая сторона, которого имеет двойную толщину для того, чтобы можно было выделить этот символ среди других обозначений на диаграмме, и обычно располагается на границах диаграммы. Внешняя ссылка может идентифицироваться строчной буквой Е в левом верхнем углу и уникальным номером, например Е5. Кроме того, внешняя ссылка имеет имя. Оно должно быть существительным. Одна и та же внешняя ссылка может быть использована многократно на одной или нескольких диаграммах. Обычно такой прием используют, чтобы не рисовать слишком длинных и запутанных стрелок. Каждая внешняя сущность имеет префикс. При рассмотрении системы как внешней функции, часто указывается, что она находится за пределами границ, моделируемой системы. После проведения анализа некоторые внешние ссылки могут быть перемещены внутрь диаграммы потоков данных рассматриваемой системы или, наоборот, какая-то часть функций системы может быть вынесена и рассмотрена как внешняя ссылка. 3.3. Правила формирования моделей бизнес-процессов в DFD 1. 2. Формат DFD применяется для описания бизнес-процессов в виде потоков данных. Условные обозначения формата DFD представлены в следующих таблицах. 3. Модель информационных потоков бизнес-процесса (DFD) представляет бизнеспроцесс как совокупность выполняемых операций в привязке к движению информационных потоков. Модель информационных потоков (DFD) описывает: операции обработки информации; 4. 14 Логистика и CALS. Занятие 3 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. Изучение и освоение стандартов (DFD) документы и информацию; объекты, организационные единицы, сотрудников и т.д., участвующих в обработке информации; внешние объекты, которые участвуют в бизнес-процессе, но находятся за его границами; хранилища документов, данных и информации. В модели информационных потоков должны отражаться исполнители, а так же субъекты, взаимодействующие с бизнес-процессом. Основными объектами моделей DFD являются: операции; хранилища данных; внешние объекты (сущности); потоки данных и объектов. Операции обозначают преобразования потоков материальных, финансовых ресурсов и информации (документов, файлов). Операции изображаются прямоугольниками со сплошными границами и скругленными углами. Операции выделяются серым фоном. Внешние объекты (иначе говоря, внешние сущности) обозначают некоторые объекты, которые участвуют в бизнес-процессе, но находятся за его границами, то есть являются частью внешней среды. Внешние объекты поддерживают обмен потоками объектов из внешней среды в систему и обратно через входы и выходы моделируемой системы. Один внешний объект может быть использован многократно в рамках одной модели (на одной или нескольких диаграммах). Внешние объекты изображаются в виде прямоугольников с прямыми углами, сплошными границами. Обычно изображение внешних объектов размещается по краям диаграммы. Рекомендуется присваивать внешним объектам наименования, выраженные отглагольными существительными. Хранилища данных (объектов) обозначают места хранения данных. Потоки данных и объектов обозначают движение объектов, информации и данных из одной части системы в другую. Потоки объектов, включая данные, связывают операции, внешние объекты и хранилища. Потоки данных и объектов изображаются стрелками. В отличие от IDEF0, в DFD моделях нет стрелок, обозначающих механизмы реализации функции и управление функцией. Стрелки изображаются вертикальными и горизонтальными отрезками прямых с наконечником на одном или двух концах, пересекающиеся под прямым углом и сопряженные дугами. Стрелки с наконечником на одном конце изображают однонаправленный поток объектов. Стрелки соединяются с прямоугольниками, изображающими операции, хранилища и внешние объекты, следующим образом: концы стрелок должны касаться внешней стороны блока, но не пересекать ее; стрелки должны подсоединяться к прямоугольнику на его сторонах, присоединение в углах не допускается; в отличие от IDEF0-диаграмм, стрелки могут подходить и исходить из любых граней прямоугольников. Рекомендуется, использовать левую грань прямоугольника, обозначающего операцию, в качестве входа и правую грань в качестве выхода и располагать прямоугольники по направлению слева направо и сверху вниз. 15 Логистика и CALS. Занятие 3 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. Изучение и освоение стандартов (DFD) При изображении стрелок допускаются их слияние и разветвление. Слияние и разветвление стрелок применяется для уменьшения загруженности диаграмм графическими элементами. Именование стрелок и создание меток в случае разветвления стрелок подчиняется следующим правилам: если стрелка именована до разветвления, а после разветвления ни одна из ветвей не именована, то подразумевается, что каждая ветвь моделирует те же данные или объекты, что и ветвь до разветвления; если стрелка именована до разветвления, а после разветвления какая-либо из ветвей не именована, то подразумевается, что она моделирует те же данные или объекты, что и до разветвления; недопустима ситуация, когда стрелка до разветвления не именована, а после не именована какая либо из ветвей. При формировании моделей в DFD может использоваться декомпозиция. На вершине дерева декомпозиции диаграмм должна находиться либо контекстная диаграмма, либо диаграмма IDEF0 (если DFD-диаграммы дополняют модель в нотации IDEF0). Связи системы с внешней средой отображаются исключительно внутренними стрелками, которые связывают внешние объекты с одной стороны и операции, хранилища с другой. Ограничений по количеству операций на диаграмме нет. Рекомендуется создавать диаграммы, которые позволяют размещать их на листе формата А3. Следует обеспечить максимальное расстояние между прямоугольниками и поворотами стрелок, а также между прямоугольниками и пересечениями стрелок для облегчения чтения диаграммы. Одновременно уменьшается вероятность перепутать две разные стрелки. Максимально увеличенное расстояние между параллельными стрелками облегчает размещения меток, их чтение и позволяет проследить пути стрелок. Стрелки связываются (сливаются), если они представляют сходные данные и их источник не указан на диаграмме. Стрелки объединяются, если они имеют общий источник или приемник, или они представляют связанные данные. Общее название лучше описывает суть данных. Следует минимизировать число стрелок, касающихся каждой стороны блока, если, конечно, природа данных не слишком разнородна. Если возможно, стрелки присоединяются к прямоугольникам в одной и той же позиции. Тогда соединение стрелок конкретного типа с прямоугольниками будет согласованным и чтение диаграммы упростится. При соединении большого числа прямоугольников необходимо избегать необязательных пересечений стрелок. Следует минимизировать число петель и поворотов каждой стрелки. При описании операций, преобразующих информационные потоки, на диаграммах нижних уровней названиям стрелок-входов должен быть поставлен в соответствие конкретный документ или перечень документов. Рекомендуется, чтобы хранилища данных соответствовали либо информационным системам, либо бумажным архивам. 3.4. Пример: описание основных бизнес-процессов торговой организации с помощью DFD. По сравнению с первоначальной постановкой задачи, для большей наглядности, было сформулировано упрощенное описание основной функции торговой организации. 16 Логистика и CALS. Занятие 3 Изучение и освоение стандартов (DFD) Основной бизнес-процесс организации – «Выполнить заказ клиента»: При поступлении заказа на основании информации о наличии товара на складе оценивается возможность выполнения заказа. Если заказ выполнить невозможно, то клиент получает отказ (извещение об отказе). Иначе заказ регистрируется как новый (статус "не оплачен"), выписывается счет на оплату, на 3 дня резервируется на складе соответствующий товар. В течение 3 дней для каждого неоплаченного заказа по выписке банка проверяется наличие оплаты. Если за 3 дня оплата не поступила, то соответствующий товар разблокируется на складе, заказ получает статус "просрочен платеж" и формируется извещение об отказе. Если оплата поступила, то заказ получает статус "оплачен", формируется накладная на отгрузку товара со склада и передается на склад, откуда поступает подписанная накладная на отгрузку и собственно товар. Считается, что задержек нет. На основании подписанной накладной на отгрузку формируется товарно-транспортная накладная, которая вместе с товаром передается клиенту, подписанная клиентом товарно-транспортная накладная возвращается в организацию. Заказ получает статус "выполнен". Задание. По вышеприведенному описанию необходимо построить DFD модель бизнеспроцесса «Выполнить заказ клиента». Для контекстной диаграммы, в соответствии с данным описанием, были определены следующие объекты: Внешние сущности. КЛИЕНТ СКЛАД БАНК Формулирует требования по номенклатуре и количеству товара в заявке, в зависимости от которых заявка либо принимается, либо отклоняется. Место хранения товара. Характеризуется текущей номенклатурой и количеством товара. Кредитная организация, осуществляющая РКО торговой организации. Предоставляет информацию по текущим денежным поступлениям. Информационные потоки взаимодействия с внешней средой. ЗАЯВКА Документ, содержащий информацию о номенклатуре и количестве товара, необходимого КЛИЕНТУ. ДОКУМЕНТАЦИЯ Ответ торговой организации на ЗАЯВКУ, полученную от ПО ЗАКАЗУ КЛИЕНТА. Представляет собой либо форму мотивированного отказа (отсутствие товара на складе или просрочен срок оплаты по выставленному счету), либо счет на оплату. ТОВАРНОПоток двунаправленный. Документ, фиксирующий факт передачи ТРАНСПОРТНАЯ клиенту и факт получения клиентом соответствующего заказу НАКЛАДНАЯ товара от торговой организации. ВЫПИСКА БАНКА Представляет собой список номеров оплаченных счетов с ПО Р/С указанными суммами оплаты на текущую дату. НАЛИЧИЕ ТОВАРА Список товаров, имеющихся в наличии на складе, которые НА СКЛАДЕ соответствуют (на текущую дату и время) указанным в ЗАЯВКЕ товарам по номенклатуре и количеству. НАКЛАДНАЯ НА Поток двунаправленный. Документ, фиксирующий факт 17 Логистика и CALS. Занятие 3 ОТГРУЗКУ Изучение и освоение стандартов (DFD) распоряжения на отгрузку и собственно заказанного и оплаченного товара со склада. факт отгрузки Контекстная DFD – диаграмма основного бизнес-процесс организации «Выполнить заказ клиента» Для детализации контекстной диаграммы, в соответствии с данным описанием, были определены следующие объекты: Внутренние информационные потоки. ФОРМА ОТКАЗА Документ, представляющий собой мотивированный отказ (отсутствие товара на складе или просрочен срок оплаты по выставленному счету) КЛИЕНТУ в выполнении заказа. СЧЕТ Документ, содержащий номенклатуру, количество и стоимость заказанного товара. Счет выдается КЛИЕНТУ и должен быть оплачен в течение 3 дней с момента его выписки (статус ВЫСТАВЛЕН), Если в течении 3 дней КЛИЕНТ не оплатил счет, то присваивается статус НЕ ОПЛАЧЕН, иначе статус ОПЛАЧЕН. ЗАКАЗ Документ, созданный на основании ЗАЯВКИ содержащий номенклатуру, количество, стоимость заказанного КЛИЕНТОМ товара, номер и дату выставленного СЧЕТА. При создании – получает статус НЕ ОПЛАЧЕН. Если СЧЕТ оплачен КЛИЕНТОМ, ЗАКАЗ получает статус ОПЛАЧЕН. При передачи КЛИЕНТУ товара ЗАКАЗ получает статус ВЫПОЛНЕН. ЗАРЕЗЕРВИРОВАННЫЙ Список товаров, имеющихся в наличии на складе, которые ТОВАР соответствуют указанным в ЗАКАЗЕ (статус НЕ ОПЛАЧЕН) товарам по номенклатуре и количеству, и которые исключаются из списка товаров доступных для продажи на 3 суток (резервирование). РАСПОРЯЖЕНИЕ НА Документ, являющийся основанием для создания ОТГРУЗКУ НАКЛАДНОЙ НА ОТГРУЗКУ, фиксирующий факт того, что СЧЕТ за конкретный ЗАКАЗ оплачен КЛИЕНТОМ в срок. РАЗБЛОКИРОВАННЫЙ Список зарезервированных товаров, для которых признак ТОВАР блокировки должен быть отменен (из-за того, что СЧЕТ за конкретный ЗАКАЗ не оплачен КЛИЕНТОМ в срок). Операции. ПРИНЯТЬ ЗАКАЗ Входы: ЗАКАЗ, НАЛИЧИЕ ТОВАРА НА СКЛАДЕ Выходы: ФОРМА ОТКАЗА, ПРИНЯТЫЙ ЗАКАЗ Алгоритм: 18 Логистика и CALS. Занятие 3 ВЕСТИ ЗАКАЗ Изучение и освоение стандартов (DFD) Проверить соответствие номенклатуры и количества товара в ЗАКАЗЕ клиента и на складе. Если есть несоответствие по номенклатуре или количеству товара, то сформировать ФОРМУ ОТКАЗА в выполнении заказа клиента по причине отсутствия товара на складе. Иначе зарезервировать товар на складе в соответствии с ЗАПРОСОМ клиента на 3 дня. Передать ЗАКАЗ на оформление (сформировать новый документ ЗАКАЗ со статусом НЕ ОПЛАЧЕН) Получить номер оформленного НОВОГО ЗАКАЗА. Выписать СЧЕТ НА ОПЛАТУ оформленного ЗАКАЗА Входы: ЗАКАЗ (статус НЕ ОПЛАЧЕН), СЧЕТ (статус ОПЛАЧЕН) Выходы: ФОРМА ОТКАЗА (по причине просроченной оплаты), ЗАКАЗ (статус ПРОСРОЧЕН ПЛАТЕЖ и ОПЛАЧЕН), СЧЕТ (статус НЕ ОПЛАЧЕН), РАЗБЛОКИРОВАННЫЙ ТОВАР, РАСПОРЯЖЕНИЕ НА ОТГРУЗКУ. Алгоритм: Ежедневно проверять список ЗАКАЗОВ (статус НЕ ОПЛАЧЕН) на наличие оплаты на основании списка СЧЕТОВ (статус ОПЛАЧЕН). Если для очередного ЗАКАЗА (статус НЕ ОПЛАЧЕН) есть СЧЕТ (статус ОПЛАЧЕН), то изменить статус ЗАКАЗА на ОПЛАЧЕН и сформировать РАСПОРЯЖЕНИЕ НА ОТГРУЗКУ. Иначе Проверить превышение срока оплаты для очередного ЗАКАЗА (статус НЕ ОПЛАЧЕН). Если превышение срока есть, то изменить статус ЗАКАЗА на ПРОСРОЧЕН ПЛАТЕЖ и сформировать ФОРМУ ОТКАЗА (причина: просрочен срок оплаты по выставленному счету). Иначе ждать оплаты СЧЕТА. СФОРМИРОВАТЬ Входы: РАСПОРЯЖЕНИЕ НА ОТГРУЗКУ, ЗАКАЗ И ТОВАРНО-ТРАНСПОРТНАЯ НАКЛАДНАЯ, ОТГРУЗИТЬ ТОВАР НАКЛАДНАЯ НА ОТГРУЗКУ. Выходы: ТОВАРНО-ТРАНСПОРТНАЯ НАКЛАДНАЯ, НАКЛАДНАЯ НА ОТГРУЗКУ, ЗАКАЗ (статус ВЫПОЛНЕН). Алгоритм: При поступлении РАСПОРЯЖЕНИЯ НА ОТГРУЗКУ товара, на его основе сформировать НАКЛАДНУЮ НА ОТГРУЗКУ указанного товара со склада. При поступлении НАКЛАДНОЙ НА ОТГРУЗКУ товара за подписью СКЛАДА: Сформировать ТОВАРНО-ТРАНСПОРТНУЮ НАКЛАДНУЮ для КЛИЕНТА, Подписать ТОВАРНО-ТРАНСПОРТНУЮ НАКЛАДНУЮ для КЛИЕНТА, Изменить статус ЗАКАЗА на ВЫПОЛНЕН. 19 Логистика и CALS. Занятие 3 Изучение и освоение стандартов (DFD) Детализация контекстной DFD – диаграммы основного бизнес-процесс организации «Выполнить заказ клиента» Принятые упрощения: Временные задержки при выполнении операций, а также при взаимодействии с внешней средой не рассматриваются. Отказ КЛИЕНТА от оплаченного ЗАКАЗА не рассматривается. В модели отслеживается только текущая дата, синхронизация событий привязана к текущей дате. Вопросы, связанные с закупкой товара (пополнение склада), инвентаризацией склада и списанием негодного товара, а также вопросы по организации хранения товара в данном примере не рассматриваются. Рассматриваются только информационные потоки. 3.5. Задание на самостоятельную работу 1 задание. На основании вышеприведенного описания, необходимо: создать в Erwin Process Modeler DFD-модель рассмотренного бизнес-процесса, задать цель и точку зрения, построить контекстную диаграмму и ее детализацию, и сформировать полный глоссарий модели. задание выполняется бригадами, в бригаде не должно быть больше 3 человек. 2 задание. Исходной информацией служит построенная DFD-модель. Каждая бригада выполняет одну и ту же задачу – верификацию построенной модели. Требуется проанализировать выделенные красным цветом потоки данных на предмет их корректности и корректности их обработки связанными с ними элементами модели, как с точки зрения соответствия правилам построения DFD-моделей, так и с точки зрения логики описываемого бизнес-процесса. 20 Логистика и CALS. Занятие 3 Изучение и освоение стандартов (DFD) Необходимо внести в DFD-модель соответствующие изменения и подготовить защиту исправленной модели. 3 задание. Необходимо: проработать приведенное ниже описание предметной области, оценить его полноту и, при необходимости, аргументировано дополнить (сократить) описание; построить для этого описания контекстную диаграмму и ее детализацию в нотации DFD; подготовить защиту разработанной модели. Вопросы по защите будут к участнику бригады. Описание предметной области. При оформлении в банке кредита сотрудник банка требует от клиента заявление о выдаче кредита и пакет сопроводительных документов (копия паспорта, справку о размере заработной платы). При возникновении вопросов (состав документов не соответствует установленным нормам) сотрудник банка направляет запрос клиенту или назначает встречу. При принятии решения о выдаче кредита банк сначала проверяет наличие клиента (заемщика) в «черном списке». При наличии клиента в этом списке следует отказ в выдаче кредита. Иначе сотрудник банка проверяет предоставленные документы. В случае несоответствия документов действительности или некредитоспособности клиента следует отказ в выдаче кредита и информация о клиенте заносится в «черный список». При согласии банка выдать кредит заключается кредитный договор между банком и клиентом (заемщиком) и формируется график погашения задолженности. На данном этапе заемщику предоставляют право разделить ответственность с поручителем. В этом случае оформляется договор поручительства, и информация о поручителе вносится в систему. После заключения договора на имя заемщика открывается ссудный счет, с которого осуществляется выдача наличных средств. При выдаче кредита банком формируется расходный кассовый ордер. Заемщик забирает кредит наличными, либо (по предварительной договоренности между банком и продавцом товара) банк осуществляет перечисление полной стоимости товара (собственные средства заемщика и/или кредитные средства) на расчетный счет продавца. При этом формируется приходный кассовый ордер, а заемщику-покупателю выдается квитанция о полной оплате стоимости покупки. Погашение кредита производится заемщиком ежемесячно по графику погашения задолженности. Каждый платеж фиксируется в системе. Возможны следующие ситуации: В случае преждевременного погашения кредита происходит перерасчет сумм выплат (пересмотр графика погашения задолженности). В случае нарушения сроков и сумм погашения кредита: происходит пересмотр графика погашения задолженности; к заемщику применяются штрафные санкции; в случае наличия у заемщика поручителя, банк обращается к последнему с требованием погашения кредита. В случае отказа от погашения кредита: в случае наличия у заемщика поручителя, банк обращается к последнему с требованием погашения кредита; банком изымается предмет залога; 21 Логистика и CALS. Занятие 3 - Изучение и освоение стандартов (DFD) происходит расторжение кредитного договора с заемщиком; заемщик вносится в «черный список». После погашения заемщиком всей суммы задолженности следует процедура окончательного погашения кредита: расторгается кредитный договор с заемщиком; осуществляется закрытие ссудного счета заемщика, и выдаются соответствующие документы заемщику. Общие требования к выполнению заданий: Задание выполняется теми же бригадами (в бригаде не больше 3 человек); Создаваемая модель должна соответствовать правилам построения DFD-модели, нарушение правил не допустимо. Модель не должна содержать в глоссарии определения для неиспользуемых объектов. Полнота и завершенность определений влияет на оценку. Также на оценку влияет функциональная полнота диаграмм. Каждая бригада должна представить свою собственную модель, одинаковых моделей не должно быть. Если несколько бригад представляют одинаковую модель, то эта модель будет закреплена за бригадой, представившей данную модель первой. Каждая бригада должна защитить свою работу. Каждый студент получает оценку (не аттестован, неуд., удовл., хор., отл.). Полученная оценка является составной частью интегральной оценки за курс в целом (дифференцированный зачет). Методологически более подробно подходы, техники и приемы функционального моделирования представлены в следующей литературе: методологии Дополнительная литература: 1. Калашян, А.Н., Калянов Г.Н. Структурные модели бизнеса: DFD-технологии / под ред. Г.Н. Калянова. – М.: Финансы и статистика, 2003. – 252 с. Рекомендуемая литература: 1. Маклаков С.В. Создание информационных систем с AllFusion Modeling Suite. – М., Диалог МИФИ, 2003. – 432 с. 22
