Основной из трех методологий, поддерживаемых BPwin, является IDEF0. IDEF0, относится к семейству IDEF, которое появилось в конце шестидесятых годов под названием SADT (Structured Analysis and Design Technique). IDEF0 может быть использована для моделирования широкого класса систем. Для новых систем применение IDEF0 имеет своей целью определение требований и указание функций для последующей разработки системы, отвечающей поставленным требованиям и реализующей выделенные функции. Применительно к уже существующим системам IDEF0 может быть использована для анализа функций, выполняемых системой и отображения механизмов, посредством которых эти функции выполняются. Результатом применения IDEF0 к некоторой системе является модель этой системы, состоящая из иерархически упорядоченного набора диаграмм, текста документации и словарей, связанных друг с другом с помощью перекрестных ссылок. Двумя наиболее важными компонентами, из которых строятся диаграммы IDEF0, являются бизнес-функции или работы (представленные на диаграммах в виде прямоугольников) и данные и объекты (изображаемые в виде стрелок), связывающие между собой работы. При этом стрелки, в зависимости от того в какую грань прямоугольника работы они входят или из какой грани выходят, делятся на пять видов:
· Стрелки входа (входят в левую грань работы) - изображают данные или объекты, изменяемые в ходе выполнения работы.
· Стрелки управления (входят в верхнюю грань работы) - изображают правила и ограничения, согласно которым выполняется работа.
· Стрелки выхода (выходят из правой грани работы) - изображают данные или объекты, появляющиеся в результате выполнения работы.
· Стрелки механизма (входят в нижнюю грань работы) - изображают ресурсы, необходимые для выполнения работы, но не изменяющиеся в процессе работы (например, оборудование, людские ресурсы…)
· Стрелки вызова (выходят из нижней грани работы) - изображают связи между разными диаграммами или моделями, указывая на некоторую диаграмму, где данная работа рассмотрена более подробно.
Все работы и стрелки должны быть именованы. Первая диаграмма в иерархии диаграмм IDEF0 всегда изображает функционирование системы в целом. Такие диаграммы называются контекстными. В контекст входит описание цели моделирования, области (описания того, что будет рассматриваться как компонент системы, а что как внешнее воздействие) и точки зрения (позиции, с которой будет строиться модель). Обычно в качестве точки зрения выбирается точка зрения лица или объекта, ответственного за работу моделируемой системы в целом.
Рисунок 7.1. Функциональный блок и интерфейсные дуги
Работы на диаграммах изображаются в виде прямоугольников (функциональные блоки). Каждая работа изображает какую-либо функцию или задачу и именуется глаголом или глагольной фразой, обозначающей действие, например «Изготовление изделия», «Обслуживание клиента» и т.д. Стрелки помечаются существительным и обозначают объекты или информацию, связывающую работы между собой и с внешним миром.
После описания контекста проводится функциональная декомпозиция- система разбивается на подсистемы и каждая подсистема описывается в том же синтаксисе, что и система в целом. Затем каждая подсистема разбивается на более мелкие и так до достижения нужного уровня подробности. В результате такого разбиения, каждый фрагмент системы изображается на отдельной диаграмме декомпозиции.
После того как контекст описан, проводится построение следующих диаграмм в иерархии. Каждая последующая диаграмма является более подробным описанием (декомпозицией) одной из работ на вышестоящей диаграмме. Пример декомпозиции контекстной работы показан на Рис.7.2 и Рис.7.4. Описание каждой подсистемы проводится аналитиком совместно с экспертом предметной области. Обычно экспертом является человек, отвечающий за эту подсистему и, поэтому, досконально знающий все ее функции. Таким образом, вся система разбивается на подсистемы до нужного уровня детализации, и получается модель, аппроксимирующая систему с заданным уровнем точности. Получив модель, адекватно отображающую текущие бизнес-процессы (так называемую модель AS IS), аналитик с легкостью может увидеть все наиболее уязвимые места системы. После этого, с учетом выявленных недостатков, можно строить модель новой организации бизнес-процессов (модель TO BE).
Одной из наиболее важных особенностей методологии SADT является постепенное введение все больших уровней детализации по мере создания диаграмм, отображающих модель.
На рисунке 7.2, где приведены три диаграммы и их взаимосвязи, показана структура IDEF0.-модели. Каждый компонент модели может быть декомпозирован на другой диаграмме. Каждая диаграмма иллюстрирует "внутреннее строение" блока на родительской диаграмме.
Рисунок 7.2 - Пример контекстной диаграммы
Как видно на Рис.7.2, BPwin позволяет выделять работы и стрелки разными цветами, а также привязывать имена стрелок к самим стрелкам (стрелка по имени “Отчетность”), что повышает наглядность и читаемость диаграммы.
Рисунок 7.3 - Пример диаграммы декомпозиции
Рисунок 7.4 - Пример контекстной диаграммы
Рисунок 7.5 - Пример диаграммы декомпозиции
Иерархия диаграмм
Построение IDEF0-модели начинается с представления всей системы в виде простейшей компоненты - одного блока и дуг, изображающих интерфейсы с функциями вне системы. Поскольку единственный блок представляет всю систему как единое целое, имя, указанное в блоке, является общим. Это верно и для интерфейсных дуг - они также представляют полный набор внешних интерфейсов системы в целом.
Затем блок, который представляет систему в качестве единого модуля, детализируется на другой диаграмме с помощью нескольких блоков, соединенных интерфейсными дугами. Эти блоки представляют основные подфункции исходной функции. Данная декомпозиция выявляет полный набор подфункций, каждая из которых представлена как блок, границы которого определены интерфейсными дугами. Каждая из этих подфункций может быть декомпозирована подобным образом для более детального представления.
Во всех случаях каждая подфункция может содержать только те элементы, которые входят в исходную функцию. Кроме того, модель не может опустить какие-либо элементы, т.е., как уже отмечалось, родительский блок и его интерфейсы обеспечивают контекст. К нему нельзя ничего добавить, и из него не может быть ничего удалено.
Дуги, входящие в блок и выходящие из него на диаграмме верхнего уровня, являются точно теми же самыми, что и дуги, входящие в диаграмму нижнего уровня и выходящие из нее, потому что блок и диаграмма представляют одну и ту же часть системы.
Рисунк 7.6 - Структура SADT-модели. Декомпозиция диаграмм
Рисунок 7.7 - Соответствие должно быть полным и непротиворечивым
Некоторые дуги присоединены к блокам диаграммы обоими концами, у других же один конец остается неприсоединенным. Неприсоединенные дуги соответствуют входам, управлениям и выходам родительского блока. Источник или получатель этих пограничных дуг может быть обнаружен только на родительской диаграмме. Неприсоединенные концы должны соответствовать дугам на исходной диаграмме. Все граничные дуги должны продолжаться на родительской диаграмме, чтобы она была полной и непротиворечивой.
Как было отмечено, механизмы (дуги с нижней стороны) показывают средства, с помощью которых осуществляется выполнение функций. Механизм может быть человеком, компьютером или любым другим устройством, которое помогает выполнять данную функцию (рисунок 7.8).
Рис. 7.8. Пример механизма
Каждый блок на диаграмме имеет свой номер. Блок любой диаграммы может быть далее описан диаграммой нижнего уровня, которая, в свою очередь, может быть далее детализирована с помощью необходимого числа диаграмм. Таким образом, формируется иерархия диаграмм.
Для того, чтобы указать положение любой диаграммы или блока в иерархии, используются номера диаграмм. Например, А21 является диаграммой, которая детализирует блок 1 на диаграмме А2. Аналогично, А2 детализирует блок 2 на диаграмме А0, которая является самой верхней диаграммой модели. На рисунке 7.9 показано типичное дерево диаграмм.
Рисунок 7.9 - Иерархия диаграмм
Характеристика case-средств
ERwin - средство концептуального моделирования БД , использующее методологию IDEF1X (см. подраздел 2.5). ERwin реализует проектирование схемы БД, генерацию ее описания на языке целевой СУБД (ORACLE, Informix, Ingres, Sybase, DB/2, Microsoft SQL Server, Progress и др.) и реинжиниринг существующей БД. ERwin выпускается в нескольких различных конфигурациях, ориентированных на наиболее распространенные средства разработки приложений 4GL. Версия ERwin/OPEN полностью совместима со средствами разработки приложений PowerBuilder и SQLWindows и позволяет экспортировать описание спроектированной БД непосредственно в репозитории данных средств.
Для ряда средств разработки приложений (PowerBuilder, SQLWindows, Delphi, Visual Basic) выполняется генерация форм и прототипов приложений.
Сетевая версия Erwin ModelMart обеспечивает согласованное проектирование БД и приложений в рамках рабочей группы.
BPwin - средство функционального моделирования, реализующее методологию IDEF0 (см. подраздел 2.2).
S-Designor 4.2 представляет собой CASE-средство для проектирования реляционных баз данных . По своим функциональным возможностям и стоимости он близок к CASE-средству ERwin, отличаясь внешне используемой на диаграммах нотацией. S-Designor реализует стандартную методологию моделирования данных и генерирует описание БД для таких СУБД, как ORACLE, Informix, Ingres, Sybase, DB/2, Microsoft SQL Server и др. Для существующих систем выполняется реинжиниринг БД.
S-Designor совместим с рядом средств разработки приложений (PowerBuilder, Uniface, TeamWindows и др.) и позволяет экспортировать описание БД в репозитории данных средств. Для PowerBuilder выполняется также прямая генерация шаблонов приложений.
CASE.Аналитик 1.1 является практически единственным в настоящее время конкурентоспособным отечественным CASE-средством функционального моделирования и реализует построение диаграмм потоков данных в соответствии с методологией, описанной в подразделе 2.3. Его основные функции:
- построение и редактирование DFD;
- анализ диаграмм и проектных спецификаций на полноту и непротиворечивость;
- получение разнообразных отчетов по проекту;
- генерация макетов документов в соответствии с требованиями ГОСТ 19.ХХХ и 34.ХХХ.
Среда функционирования: процессор - 386 и выше, основная память - 4 Мб, дисковая память - 5 Мб, MS Windows 3.x или Windows 95.
База данных проекта реализована в формате СУБД Paradox и является открытой для доступа.
С помощью отдельного программного продукта (Catherine) выполняется обмен данными с CASE-средством ERwin. При этом из проекта, выполненного в CASE.Аналитике, экспортируется описание структур данных и накопителей данных, которое по определенным правилам формирует описание сущностей и их атрибутов.
Инструментальная среда BPWin
BPwin имеет достаточно простой и интуитивно понятный интерфейс пользователя, дающий возможность аналитику создавать сложные модели при минимальных усилиях. Ниже будет описан интерфейс версии 2.5.
Рис. 1.1. Интегрированная среда разработки модели BPwin 2.5
При запуске BPwin по умолчанию появляется основная панель инструментов, палитра инструментов (вид которой зависит от выбранной нотации) и, в левой части, навигатор модели - Model Explorer (рис. 1.1).
Функциональность панели инструментов доступна из основного меню Bpwin (табл. 1.1).
Таблица 1.1. Описание элементов управления основной панели инструментов Bpwin 2.5
| Элемент управления | Описание | Соответствующий пункт меню |
| Создать новую модель | File/New | |
| Открыть модель | File/Open | |
| Сохранить модель | File/Save | |
| Напечатать модель | File/Print | |
 | Выбор масштаба | View/Zoom |
| Масштабирование | View/Zoom | |
| Проверка правописания | Tools/Spelling | |
| Включение и выключение навигатора модели Model Explorer | View/Model Explorer | |
| Включение и выключение дополнительной панели инструментов работы с ModelMart | ModelMart |
При создании новой модели возникает диалог, в котором следует указать, будет ли создана модель заново, или она будет открыта из файла либо из репозитория ModelMart, внести имя модели и выбрать методологию, в которой будет построена модель (рис. 1.2).
Как было указано выше, BPwin поддерживает три методологии - IDEF0, IDEF3 и DFD, каждая из которых решает свои специфические задачи. В BPwin возможно построение смешанных моделей, т. е. модель может содержать одновременно как диаграммы IDEF0, так и IDEF3 и DFD. Состав палитры инструментов изменяется автоматически, когда происходит переключение с одной нотации на другую, поэтому палитра инструментов будет рассмотрена позже.
Рис. 1.2. Диалог создания модели
Модель в BPwin рассматривается как совокупность работ, каждая из которых оперирует с некоторым набором данных. Работа изображается в виде прямоугольников, данные - в виде стрелок. Если щелкнуть по любому объекту модели левой кнопкой мыши, появляется всплывающее контекстное меню, каждый пункт которого соответствует редактору какого-либо свойства объекта.
Установка цвета и шрифта объектов. Пункты контекстного меню Font Editor и Color Editor вызывают соответствующие диалоги для установки шрифта (в том числе его размера и стиля) и цвета объекта. Кроме того, BPwin позволяет установить шрифт по умолчанию для объектов определенного типа на диаграммах и в отчетах. Для этого следует выбрать меню Tools/Default Fonts, после чего появляется каскадное меню, каждый пункт которого служит для установки шрифтов для определенного типа объектов:
Context Activity - работа на контекстной диаграмме;
Context Arrow - стрелки на контекстной диаграмме;
Decomposition Activity - работы на диаграмме декомпозиции;
Decomposition Arrow - стрелки на диаграмме декомпозиции;
NodeTree Text - текст на диаграмме дерева узлов;
Frame User Text - текст, вносимый пользователем в каркасе диаграмм;
Frame System Text - системный текст в каркасе диаграмм;
Text Blocks - текстовые блоки;
Parent Diagram Text - текст родительской диаграммы;
Parent Diagram Title Text - текст заголовка родительской диаграммы;
Report Text - текст отчетов.
Методология IDEF0 в BPWin. Диаграмма IDEF0.
(тут очень дохуя написано, но если кто Бпвин в глаза не видел – тому будет полезно:)
Построение модели IDEF0
На начальных этапах создания ИС необходимо понять, как работает организация, которую собираются автоматизировать. Руководитель хорошо знает работу в целом, но не в состоянии вникнуть в детали работы каждого рядового сотрудника. Рядовой сотрудник хорошо знает, что творится на его рабочем месте, но может не знать, как работают коллеги. Поэтому для описания работы предприятия необходимо построить модель, которая будет адекватна предметной области и содержать в себе знания всех участников бизнес-процессов организации.
Наиболее удобным языком моделирования бизнес-процессов является IDEF0, где система представляется как совокупность взаимодействующих работ или функций. Такая чисто функциональная ориентация является принципиальной - функции системы анализируются независимо от объектов, которыми они оперируют. Это позволяет более четко смоделировать логику и взаимодействие процессов организации.
Процесс моделирования системы в IDEF0 начинается с создания контекстной диаграммы - диаграммы наиболее абстрактного уровня описания системы в целом, содержащей определение субъекта моделирования, цели и точки зрения на модель.
Под субъектом понимается сама система, при этом необходимо точно установить, что входит в систему, а что лежит за ее пределами, другими словами, определить, что будет в дальнейшем рассматриваться как компоненты системы, а что как внешнее воздействие. На определение субъекта системы будут существенно влиять позиция, с которой рассматривается система, и цель моделирования - вопросы, на которые построенная модель должна дать ответ. Другими словами, в начале необходимо определить область моделирования. Описание области как системы в целом, так и ее компонентов является основой построения модели. Хотя предполагается, что в ходе моделирования область может корректироваться, она должна быть в основном сформулирована изначально, поскольку именно область определяет направление моделирования. При формулировании области необходимо учитывать два компонента - широту и глубину. Широта подразумевает определение границ модели - что будет рассматриваться внутри системы, а что снаружи. Глубина определяет, на каком уровне детализации модель является завершенной. При определении глубины системы необходимо помнить об ограничениях времени - трудоемкость построения модели растет в геометрической прогрессии с увеличением глубины декомпозиции. После определения границ модели предполагается, что новые объекты не должны вноситься в моделируемую систему.
Цель моделирования
Цель моделирования определяется из ответов на следующие вопросы:
- Почему этот процесс должен быть смоделирован?
- Что должна показывать модель?
- Что может получить клиент?
Точка зрения (Viewpoint).
Под точкой зрения понимается перспектива, с которой наблюдалась система при построении модели. Хотя при построении модели учитываются мнения различных людей, все они должны придерживаться единой точки зрения на модель. Точка зрения должна соответствовать цели и границам моделирования. Как правило, выбирается точка зрения человека, ответственного за моделируемую работу в целом.
IDEF0-модель предполагает наличие четко сформулированной цели, единственного субъекта моделирования и одной точки зрения. Для внесения области, цели и точки зрения в модели IDEF0 в BPwin следует выбрать пункт меню Model/Model Properties, вызывающий диалог Model Properties. В закладке Purpose следует внести цель и точку зрения, а в закладку Definition - определение модели и описание области.
В закладке Status того же диалога можно описать статус модели (черновой вариант, рабочий, окончательный и т. д.), время создания и последнего редактирования (отслеживается в дальнейшем автоматически по системной дате). В закладке Source описываются источники информации для построения модели (например, "Опрос экспертов предметной области и анализ документации"). Закладка General служит для внесения имени проекта и модели, имени и инициалов автора и временных рамок модели - AS-IS и ТО-ВЕ.
Модели AS-IS и ТО-ВЕ. Обычно сначала строится модель существующей организации работы - AS-IS (как есть). Анализ функциональной модели позволяет понять, где находятся наиболее слабые места, в чем будут состоять преимущества новых бизнес-процессов и насколько глубоким изменениям подвергнется существующая структура организации бизнеса. Детализация бизнес-процессов позволяет выявить недостатки организации даже там, где функциональность на первый взгляд кажется очевидной. Найденные в модели AS-IS недостатки можно исправить при создании модели ТО-ВЕ (как будет) - модели новой организации бизнес-процессов.
Технология проектирования ИС подразумевает сначала создание модели AS-IS, ее анализ и улучшение бизнес-процессов, то есть создание модели ТО-ВЕ, и только на основе модели ТО-ВЕ строится модель данных, прототип и затем окончательный вариант ИС.
Иногда текущая AS-IS и будущая ТО-ВЕ модели различаются очень сильно, так что переход от начального к конечному состоянию становится неочевидным. В этом случае необходима третья модель, описывающая процесс перехода от начального к конечному состоянию системы, поскольку такой переход - это тоже бизнес-процесс.
Результат описания модели можно получить в отчете Model Report. Диалог настройки отчета по модели вызывается из пункта меню Tools/Reports/Model Report.
В диалоге настройки следует выбрать необходимые поля, при этом автоматически отображается очередность вывода информации в отчет.
Основу методологии IDEF0 составляет графический язык описания бизнес-процессов. Модель в нотации IDEF0 представляет собой совокупность иерархически упорядоченных и взаимосвязанных диаграмм. Каждая диаграмма является единицей описания системы и располагается на отдельном листе.
Модель может содержать четыре типа диаграмм:
- контекстную диаграмму(в каждой модели может быть только одна контекстная диаграмма);
- диаграммы декомпозиции;
- диаграммы дерева узлов;
- диаграммы только для экспозиции (FEO).
Контекстная диаграмма является вершиной древовидной структуры диаграмм и представляет собой самое общее описание системы и ее взаимодействия с внешней средой. После описания системы в целом проводится разбиение ее на крупные фрагменты. Этот процесс называется функциональной декомпозицией, а диаграммы, которые описывают каждый фрагмент и взаимодействие фрагментов, называются диаграммами декомпозиции. После декомпозиции контекстной диаграммы проводится декомпозиция каждого большого фрагмента системы на более мелкие и так далее, до достижения нужного уровня подробности описания. После каждого сеанса декомпозиции проводятся сеансы экспертизы - эксперты предметной области указывают на соответствие реальных бизнес-процессов созданным диаграммам. Найденные несоответствия исправляются, и только после прохождения экспертизы без замечаний можно приступать к следующему сеансу декомпозиции. Так достигается соответствие модели реальным бизнес-процессам на любом и каждом уровне модели. Синтаксис описания системы в целом и каждого ее фрагмента одинаков во всей модели.
Диаграмма дерева узловпоказывает иерархическую зависимость работ, но не взаимосвязи между работами. Диаграмм деревьев узлов может быть в модели сколь угодно много, поскольку дерево может быть построено на произвольную глубину и не обязательно с корня.
диаграммы для экспозиции (FEO)строятся для иллюстрации отдельных фрагментов модели, для иллюстрации альтернативной точки зрения, либо для специальных целей.
Работы (Activity)
обозначают поименованные процессы, функцииили задачи, которые происходят в течение определенного времени и имеют распознаваемые результаты. Работы изображаются в виде прямоугольников. Все работы должны быть названы и определены. Имя работы должно быть выражено отглагольным существительным, обозначающим действие (например, "Деятельность компании", "Прием заказа" и т.д.). Работа "Деятельность компании" может иметь, например, следующее определение: "Это учебная модель, описывающая деятельность компании". При создании новой модели (меню File/New) автоматически создается контекстная диаграмма с единственной работой, изображающей систему в целом.
Для внесения имени работы следует щелкнуть по работе правой кнопкой мыши, выбрать в меню Name Editor и в появившемся диалоге внести имя работы. Для описания других свойств работы служит диалог Activity Properties.
Диаграммы декомпозиции содержат родственные работы, т. е. дочерние работы, имеющие общую родительскую работу. Для создания диаграммы декомпозиции следует щелкнуть по кнопке
на панели инструментов.
Возникает диалог Activity Box Count, в котором следует указать нотацию новой диаграммы и количество работ на ней. Остановимся пока на нотации IDEF0 и щелкнем на ОК. Появляется диаграмма декомпозиции. Допустимый интервал числа работ - 2-8. Декомпозироватьработу на одну работу не имеет смысла: диаграммы с количеством работ более восьми получаются перенасыщенными и плохо читаются. Для обеспечения наглядности и лучшего понимания моделируемых процессов рекомендуется использовать от трех до шести блоков на одной диаграмме.
Если оказывается, что количество работ недостаточно, то работу можно добавить в диаграмму, щелкнув сначала по кнопке на палитре инструментов, а затем по свободному месту на диаграмме.
Работы на диаграммах декомпозиции обычно располагаются по диагонали от левого верхнего угла к правому нижнему.
Такой порядок называется порядком доминирования. Согласно этому принципу расположения в левом верхнем углу помещается самая важная работа или работа, выполняемая по времени первой. Далее вправо вниз располагаются менее важные или выполняемые позже работы. Такое размещение облегчает чтение диаграмм, кроме того, на нем основывается понятие взаимосвязей работ (см. ниже).
Каждая из работ на диаграмме декомпозиции может быть в свою очередь декомпозирована. На диаграмме декомпозиции работы нумеруются автоматически слева направо. Номер работы показывается в правом нижнем углу. В левом верхнем углу изображается небольшая диагональная черта, которая показывает, что данная работа не была декомпозирована. Так, на все работы еще не были декомпозированы.
Стрелки(Arrow) описывают взаимодействие работ и представляют собой некую информацию, выраженную существительными.(Например, "Звонки клиентов", "Правила и процедуры", "Бухгалтерская система".)
В IDEF0 различают пять типов стрелок:
Вход
(Input
) - материал или информация, которые используются или преобразуются работой для получения результата (выхода). Допускается, что работа может не иметь ни одной стрелки входа. Каждый тип стрелок подходит к определенной стороне прямоугольника, изображающего работу, или выходит из нее. Стрелка входа рисуется как входящая в левую грань работы. При описании технологических процессов (для этого и был придуман IDEF0) не возникает проблем определения входов. Действительно, "Звонки клиентов" на- это нечто, что перерабатывается в процессе "Деятельность компании" для получения результата. При моделировании ИС, когда стрелками являются не физические объекты, а данные, не все так очевидно. Например, при "Приеме пациента" карта пациента может быть и на входе и на выходе, между тем качество этих данных меняется. Другими словами, в нашем примере для того, чтобы оправдать свое назначение, стрелки входа и выхода должны быть точно определены с тем, чтобы указать на то, что данные действительно были переработаны (например, на выходе - "Заполненная карта пациента"). Очень часто сложно определить, являются ли данные входом или управлением. В этом случае подсказкой может служить информация о том, перерабатываются/изменяются ли данные в работе или нет. Если изменяются, то, скорее всего, это вход, если нет - управление.
Управление
(Control
) - правила, стратегии, процедуры или стандарты, которыми руководствуется работа. Каждая работа должна иметь хотя бы одну стрелку управления. Стрелка управления рисуется как входящая в верхнюю грань работы. На стрелка "Правила и процедуры" - управление для работы "Деятельность компании". Управление влияет на работу, но не преобразуется работой. Если цель работы - изменить процедуру или стратегию, то такая процедура или стратегия будет для работы входом. В случае возникновения неопределенности в статусе стрелки (управление или вход) рекомендуется рисовать стрелку управления.
Выход
(Output
) - материал или информация, которые производятся работой. Каждая работа должна иметь хотя бы одну стрелку выхода. Работа без результата не имеет смысла и не должна моделироваться. Стрелка выхода рисуется как исходящая из правой грани работы. На стрелки "Маркетинговые материалы" и "Проданные продукты" являются выходом для работы "Деятельность компании".
Механизм
(Mechanism
) - ресурсы, которые выполняют работу, например персонал предприятия, станки, устройства и т. д. Стрелка механизма рисуется как входящая в нижнюю грань работы. На стрелка "Бухгалтерская система" является механизмом для работы "Деятельность компании". По усмотрению аналитика стрелки механизма могут не изображаться в модели.
Вызов
(Call
) - специальная стрелка, указывающая на другую модель работы. Стрелка вызова рисуется как исходящая из нижней грани работы. На стрелка "Другая модель работы" является вызовом для работы "Изготовление изделия". Стрелка вызова используется для указания того, что некоторая работа выполняется за пределами моделируемой системы. В BPwin стрелки вызова используются в механизме слияния и разделения моделей.
Граничные
стрелки. Стрелки на контекстной диаграмме служат для описания взаимодействия системы с окружающим миром. Они могут начинаться у границы диаграммы и заканчиваться у работы, или наоборот. Такие стрелки называются граничными.
Для внесения граничной стрелки входа следует:
- щелкнуть по кнопке с символом стрелки
- в палитре инструментов перенести курсор к левой стороне экрана, пока не появится начальная штриховая полоска;
- щелкнуть один раз по полоске (откуда выходит стрелка) и еще раз в левой части работы со стороны входа (где заканчивается стрелка);
- вернуться в палитру инструментов и выбрать опцию редактирования стрелки
- щелкнуть правой кнопкой мыши на линии стрелки, во всплывающем меню выбрать Name и добавить имя стрелки в закладке Name диалога IDEF0 Arrow Properties.
Стрелкиуправления, входа, механизма и выхода изображаются аналогично. Имена вновь внесенных стрелок автоматически заносятся в словарь Arrow Dictionary.
ICOM-коды
. Диаграмма декомпозиции предназначена для детализации работы. В отличие от моделей, отображающих структуру организации, работа на диаграмме верхнего уровня в IDEF0 - это не элемент управления нижестоящими работами. Работы нижнего уровня - это то же самое, что работы верхнего уровня, но в более детальном изложении. Как следствие этого границы работы верхнего уровня - это то же самое, что границы диаграммы декомпозиции. ICOM (аббревиатура от Input, Control, Output и Mechanism) - коды, предназначенные для идентификации граничных стрелок. Код ICOM содержит префикс, соответствующий типу стрелки (I, С, О или М), и порядковый номер.
BPwin вносит ICOM-коды автоматически. Для отображения ICOM-кодов следует включить опцию ICOM codes на закладке Display диалога Model Properties (меню Model/Model Properties).
Словарь стрелок
редактируется при помощи специального редактора Arrow Dictionary Editor, в котором определяется стрелка и вносится относящийся к ней комментарий. Словарь стрелок решает очень важную задачу. Диаграммы создаются аналитиком для того, чтобы провести сеанс экспертизы, т. е. обсудить диаграмму со специалистом предметной области. В любой предметной области формируется профессиональный жаргон, причем очень часто жаргонные выражения имеют нечеткий смысл и воспринимаются разными специалистами по-разному. В то же время аналитик - автор диаграмм должен употреблять те выражения, которые наиболее понятны экспертам. Поскольку формальные определения часто сложны для восприятия, аналитик вынужден употреблять профессиональный жаргон, а чтобы не возникло неоднозначных трактовок, в словаре стрелок каждому понятию можно дать расширенное и, если это необходимо, формальное определение.
Содержимое словаря стрелок можно распечатать в виде отчета (меню Tools/ Report /Arrow Report...) и получить толковый словарь терминов предметной области, использующихся в модели.
Несвязанные граничные
стрелки (unconnected border arrow)
. При декомпозиции работы входящие в нее и исходящие из нее стрелки (кроме стрелки вызова) автоматически появляются на диаграмме декомпозиции (миграция стрелок), но при этом не касаются работ. Такие стрелки называются несвязанными и воспринимаются в BPwin как синтаксическая ошибка.
На приведен фрагмент диаграммы декомпозиции с несвязанными стрелками, генерирующийся BPwin при декомпозиции работы "Сборка настольных компьютеров"
. Для связывания стрелок входа, управления или механизма необходимо перейти в режим редактирования стрелок, щелкнуть по наконечнику стрелки и потом по соответствующему сегменту работы. Для связывания стрелки выхода необходимо перейти в режим редактирования стрелок, щелкнуть по сегменту выхода работы и затем по стрелке.
Внутренние
стрелки. Для связи работ между собой используются внутренние стрелки, то есть стрелки, которые не касаются границы диаграммы, начинаются у одной и кончаются у другой работы.
Для рисования внутренней стрелки необходимо в режиме рисования стрелок щелкнуть по сегменту (например, выхода) одной работы и затем по сегменту (например, входа) другой. В IDEF0 различают пять типов связей работ.
Связь по входу
(output-input
), когда стрелка выхода вышестоящей работы (далее - просто выход) направляется на вход нижестоящей (например, на стрелка "Собранные компьютеры"
связывает работы и "Отгрузка и получение"
).
Связь по управлению
(output-control
), когда выход вышестоящей работы направляется на управление нижестоящей. Связь по управлению показывает доминирование вышестоящей работы. Данные или объекты выхода вышестоящей работы не меняются в нижестоящей. На стрелка "Заказы клиентов"
связывает работы "Продажи и маркетинг"
и "Сборка и тестирование компьютеров"
.
Обратная связь по входу
(output-input feedback
), когда выход нижестоящей работы направляется на вход вышестоящей. Такая связь, как правило, используется для описания циклов. На стрелка "Результаты тестирования" связывает работы "Тестирование компьютеров"
и "Отслеживание расписания и управление сборкой и тестированием"
.
Обратная связь по управлению
(output-control feedback
), когда выход нижестоящей работы направляется на управление вышестоящей (стрелка "Результаты сборки и тестирования",). Обратная связь по управлению часто свидетельствует об эффективности бизнес-процесса. На объем продаж может быть повышен путем непосредственного регулирования процессов сборки и тестирования компьютеров (выхода) работы "Сборки и тестирование компьютеров".
Связь выход-механизм
(output-mechanism
), когда выход одной работы направляется на механизм другой. Эта взаимосвязь используется реже остальных и показывает, что одна работа подготавливает ресурсы, необходимые для проведения другой работы.
Явные
стрелки. Явная стрелка имеет источником одну-единственную работу и назначением тоже одну-единственную работу.
Разветвляющиеся и сливающиеся
стрелки. Одни и те же данные или объекты, порожденные одной работой, могут использоваться сразу в нескольких других работах. С другой стороны, стрелки, порожденные в разных работах, могут представлять собой одинаковые или однородные данные или объекты, которые в дальнейшем используются или перерабатываются в одном месте. Для моделирования таких ситуаций в IDEF0 используются разветвляющиеся и сливающиеся стрелки. Для разветвления стрелки нужно в режиме редактирования стрелки щелкнуть по фрагменту стрелки и по соответствующему сегменту работы. Для слияния двух стрелок выхода нужно в режиме редактирования стрелки сначала щелкнуть по сегменту выхода работы, а затем по соответствующему фрагменту стрелки.
Смысл разветвляющихся и сливающихся стрелок передается именованием каждой ветви стрелок. Существуют определенные правила именования таких стрелок. Рассмотрим их на примере разветвляющихся стрелок. Если стрелка именована до разветвления, а после разветвления ни одна из ветвей не именована, то подразумевается, что каждая ветвь моделирует те же данные или объекты, что и ветвь до разветвления.
Если стрелка именована до разветвления, а после разветвления какая-либо из ветвей тоже именована, то подразумевается, что эти ветви соответствуют именованию. Если при этом какая-либо ветвь после разветвления осталась неименованной, то подразумевается, что она моделирует те же данные или объекты, что и ветвь до разветвления.
Недопустима ситуация, когда стрелка до разветвления не именована, а после разветвления не именована какая-либо из ветвей. BPwin определяет такую стрелку как синтаксическую ошибку.
Правила именования сливающихся стрелок полностью аналогичны - ошибкой будет считаться стрелка, которая после слияния не именована, а до слияния не именована какая-либо из ее ветвей. Для именования отдельной ветви разветвляющихся и сливающихся стрелок следует выделить на диаграмме только одну ветвь, после чего вызвать редактор имени и присвоить имя стрелке. Это имя будет соответствовать только выделенной ветви.
Туннелирование стрелок
. Вновь внесенные граничные стрелки на диаграмме декомпозиции нижнего уровня изображаются в квадратных скобках и автоматически не появляются на диаграмме верхнего уровня.
Для их "перетаскивания" наверх нужно щелкнуть правой кнопкой мыши по квадратным скобкам граничной стрелки и в контекстном меню выбрать команду Arrow Tunnel.
Появляется диалог Border Arrow Editor.
Если щелкнуть по кнопке Resolve Border Arrow, стрелка мигрирует на диаграмму верхнего уровня, если по кнопке Change To Tunnel - стрелка будет туннелирована и не попадет на другую диаграмму. Туннельная стрелка изображается с круглыми скобками на конце.
Туннелирование может быть применено для изображения малозначимых стрелок. Если на какой-либо диаграмме нижнего уровня необходимо изобразить малозначимые данные или объекты, которые не обрабатываются или не используются работами на текущем уровне, то их необходимо направить на вышестоящий уровень (на родительскую диаграмму). Если эти данные не используются на родительской диаграмме, их нужно направить еще выше, и т. д. В результате малозначимая стрелка будет изображена на всех уровнях и затруднит чтение всех диаграмм, на которых она присутствует. Выходом является туннелирование стрелки на самом нижнем уровне. Такое туннелирование называется "не-в-родительской-диаграмме".
Другим примером туннелирования может быть ситуация, когда стрелка механизма мигрирует с верхнего уровня на нижний, причем на нижнем уровне этот механизм используется одинаково во всех работах без исключения. (Предполагается, что не нужно детализировать стрелку механизма, т. е. стрелка механизма на дочерней работе именована до разветвления, а после разветвления ветви не имеют собственного имени). В этом случае стрелка механизма на нижнем уровне может быть удалена, после чего на родительской диаграмме она может быть туннелирована, а в комментарии к стрелке или в словаре можно указать, что механизм будет использоваться во всех работах дочерней диаграммы декомпозиции. Такое туннелирование называется "не-в-дочерней-работе".
Нумерация работ и диаграмм
. Все работы модели нумеруются. Номер состоит из префикса и числа. Может быть использован префикс любой длины, но обычно используют префикс А. Контекстная (корневая) работа дерева имеет номер А0. Работы i декомпозиции А0 имеют номера А1, А2, A3 и т. д. Работы декомпозиции нижнего уровня имеют номер родительской работы и очередной порядковый номер, например работы декомпозиции A3 будут иметь номера А31, А32, АЗЗ, А34 и т. д. Работы образуют иерархию, где каждая работа может иметь одну родительскую и несколько дочерних работ, образуя дерево. Такое дерево называют деревом узлов, а вышеописанную нумерацию - нумерацией по узлам. Диаграммы IDEF0 имеют двойную нумерацию. Во-первых, диаграммы имеют номера по узлу. Контекстная диаграмма всегда имеет номер А-0, декомпозиция контекстной диаграммы - номер А0, остальные диаграммы декомпозиции - номера по соответствующему узлу (например, A1, A2, А21, А213 и т. д.). BPwin автоматически поддерживает нумерацию по узлам, т. е. при проведении декомпозиции создается новая диаграмма и ей автоматически присваивается соответствующий номер. В результате проведения экспертизы диаграммы могут уточняться и изменяться, следовательно, могут быть созданы различные версии одной и той же (с точки зрения ее расположения в дереве узлов) диаграммы декомпозиции. BPwin позволяет иметь в модели только одну диаграмму декомпозиции в данном узле. Прежние версии диаграммы можно хранить в виде бумажной копии либо как FEO-диаграмму. (К сожалению, при создании FEO-диаграмм отсутствует возможность отката, т. е. из диаграммы можно получить декомпозиции FEO, но не наоборот.) В любом случае следует отличать различные версии одной и той же диаграммы. Для этого существует специальный номер - C-number, который должен присваиваться автором модели вручную. C-number - это произвольная строка, но рекомендуется придерживаться стандарта, когда номер состоит из буквенного префикса и порядкового номера, причем в качестве префикса используются инициалы автора диаграммы, а порядковый номер отслеживается автором вручную, например МСВ00021.
42. Моделирование в ERWin. Сущности, атрибуты, связи .
ERwin - средство разработки структуры базы данных (БД). ERwin сочетает графический интерфейс Windows, инструменты для построения ER-диаграмм, редакторы для создания логического и физического описания модели данных и прозрачную поддержку ведущих реляционных СУБД и настольных баз данных. С помощью ERwin можно создавать или проводить обратное проектирование (реинжиниринг) баз данных.
Диаграмма ERwin строится из трех основных блоков - сущностей, атрибутов и связей. Если рассматривать диаграмму как графическое представление правил предметной области, то сущности являются существительными, а связи - глаголами.
Выбор между логическим и физическим уровнем отображения осуществляется через линейку инструментов или меню. Внутри каждого из этих уровней есть следующие режимы отображения:
Режим "сущности" - внутри прямоугольников отображается имя сущности (для логической модели) или имя таблицы (для физического представления модели); служит для удобства обзора большой диаграммы или размещения прямоугольников сущностей на диаграмме. Режим "определение сущности" служит для презентации диаграммы другим людям. Режим "атрибуты". При переходе от предметной области к модели требуется вводить информацию о том, что составляет сущность. Эта информация вводится путем задания атрибутов (на физическом уровне - колонок таблиц). В этом режиме прямоугольник-сущность делится линией на две части - в верхней части отображаются атрибуты (колонки), составляющие первичный ключ, а в нижней - остальные атрибуты. Этот режим является основным при проектировании на логическом и физическом уровнях. Режим "первичные ключи" - внутри прямоугольников - сущностей показываются только атрибуты/колонки, составляющие первичный ключ. Режим "пиктограммы". Для презентационных целей каждой таблице может быть поставлена в соответствие пиктограмма (bitmap). Режим "показ глагольной фразы". На дугах связей показываются глагольные фразы, связывающие сущности (для логического уровня) или имена внешних ключей (для физического уровня). Диаграмма может занимать более чем один экран и более чем один лист при печати. Для обзора модели предусмотрены, кроме прокруток экрана, режимы уменьшения/увеличения изображения, отображение всей модели, отображение выделенной части модели.
IDEF0 - нотация графического моделирования, используемая для создания функциональной модели, отображающей структуру и функции системы, а также потоки информации и материальных объектов, связывающие эти функции. Нотация IDEF0 является одной из самых популярных нотаций моделирования бизнес-процессов.
Целью методики является построение функциональной схемы исследуемой системы, описывающей все необходимые процессы с точностью, достаточной для однозначного моделирования деятельности системы.
В основе методологии лежат четыре основных понятия: функциональный блок, интерфейсная дуга, декомпозиция, глоссарий .
Функциональный блок (Activity Box) представляет собой некоторую конкретную функцию в рамках рассматриваемой системы. По требованиям стандарта название каждого функционального блока должно быть сформулировано в глагольном наклонении (например, "производить услуги"). На диаграмме функциональный блок изображается прямоугольником (Рис. 3.).
Каждая из четырех сторон функционального блока имеет свое определенное значение (роль), при этом:
Верхняя сторона имеет значение "Управление" (Control);
Левая сторона имеет значение "Вход" (Input);
Правая сторона имеет значение "Выход" (Output);
Нижняя сторона имеет значение "Механизм" (Mechanism).
Интерфейсная дуга (Arrow) отображает элемент системы, который обрабатывается функциональным блоком или оказывает иное влияние на функцию , представленную данным функциональным блоком. Интерфейсные дуги часто называют потоками или стрелками.
Рис. 3. - Функциональный блок
С помощью интерфейсных дуг отображают различные объекты, в той или иной степени определяющие процессы, происходящие в системе. Такими объектами могут быть элементы реального мира (детали, вагоны, сотрудники и т.д.) или потоки данных и информации (документы, данные, инструкции и т.д.).
В зависимости от того, к какой из сторон функционального блока подходит данная интерфейсная дуга, она носит название "входящей", "исходящей" или "управляющей".
Необходимо отметить, что любой функциональный блок по требованиям стандарта должен иметь, по крайней мере, одну управляющую интерфейсную дугу и одну исходящую. Это и понятно - каждый процесс должен происходить по каким-то правилам (отображаемым управляющей дугой) и должен выдавать некоторый результат (выходящая дуга), иначе его рассмотрение не имеет никакого смысла.
Обязательное наличие управляющих интерфейсных дуг является одним из главных отличий стандарта IDEF0 от других методологий классов DFD (Data Flow Diagram) и WFD (Work Flow Diagram).
Декомпозиция (Decomposition) является основным понятием стандарта IDEF0. Принцип декомпозиции применяется при разбиении сложного процесса на составляющие его функции . При этом уровень детализации процесса определяется непосредственно разработчиком модели.
Декомпозиция позволяет постепенно и структурировано представлять модель системы в виде иерархической структуры отдельных диаграмм, что делает ее менее перегруженной и легко усваиваемой (Рис.4.).
Последним из понятий IDEF0 является глоссарий (Glossary). Для каждого из элементов IDEF0 — диаграмм, функциональных блоков, интерфейсных дуг — существующий стандарт подразумевает создание и поддержание набора соответствующих определений, ключевых слов, повествовательных изложений и т.д., которые характеризуют объект, отображенный данным элементом. Этот набор называется глоссарием и является описанием сущности данного элемента. Глоссарий гармонично дополняет наглядный графический язык, снабжая диаграммы необходимой дополнительной информацией.
Модель IDEF0 всегда начинается с представления системы как единого целого - одного функционального блока с интерфейсными дугами, простирающимися за пределы рассматриваемой области. Такая диаграмма с одним функциональным блоком называется контекстной диаграммой .
В пояснительном тексте к контекстной диаграмме должна быть указана цель (Purpose) построения диаграммы в виде краткого описания и зафиксирована точка зрения.
Рис. 4. - Схема декомпозиции функциональных блоков модели
Определение и формализация цели разработки IDEF0-модели является крайне важным моментом. Фактически цель определяет соответствующие области в исследуемой системе, на которых необходимо фокусироваться в первую очередь.
Точка зрения определяет основное направление развития модели и уровень необходимой детализации .
Четкое фиксирование точки зрения позволяет разгрузить модель, отказавшись от детализации и исследования отдельных элементов, не являющихся необходимыми, исходя из выбранной точки зрения на систему. Правильный выбор точки зрения существенно сокращает временные затраты на построение конечной модели.
Выделение подпроцессов . В процессе декомпозиции функциональный блок, который в контекстной диаграмме отображает систему как единое целое, подвергается детализации на другой диаграмме. Получившаяся диаграмма второго уровня содержит функциональные блоки, отображающие главные подфункции функционального блока контекстной диаграммы, и называется дочерней (Child Diagram) по отношению к нему (каждый из функциональных блоков, принадлежащих дочерней диаграмме, соответственно называется дочерним блоком - Child Box).
В свою очередь, функциональный блок — предок называется родительским блоком по отношению к дочерней диаграмме (Parent Box), а диаграмма, к которой он принадлежит - родительской диаграммой (Parent Diagram). Каждая из подфункций дочерней диаграммы может быть далее детализирована путем аналогичной декомпозиции соответствующего ей функционального блока. В каждом случае декомпозиции функционального блока все интерфейсные дуги, входящие в данный блок или исходящие из него, фиксируются на дочерней диаграмме. Этим достигается структурная целостность IDEF0-модели.
Иногда отдельные интерфейсные дуги высшего уровня не имеет смысла продолжать рассматривать на диаграммах нижнего уровня, или наоборот — отдельные дуги нижнего отражать на диаграммах более высоких уровней - это будет только перегружать диаграммы и делать их сложными для восприятия. Для решения подобных задач в стандарте IDEF0 предусмотрено понятие туннелирования. Обозначение "туннеля" (Arrow Tunnel) в виде двух круглых скобок вокруг начала интерфейсной дуги обозначает, что эта дуга не была унаследована от функционального родительского блока и появилась (из "туннеля") только на этой диаграмме.
В свою очередь, такое же обозначение вокруг конца (стрелки) интерфейсной дуги в непосредственной близи от блока-приемника означает тот факт, что в дочерней по отношению к этому блоку диаграмме эта дуга отображаться и рассматриваться не будет. Чаще всего бывает, что отдельные объекты и соответствующие им интерфейсные дуги не рассматриваются на некоторых промежуточных уровнях иерархии, - в таком случае они сначала "погружаются в туннель", а затем при необходимости "возвращаются из туннеля".
Обычно IDEF0-модели несут в себе сложную и концентрированную информацию, и для того, чтобы ограничить их перегруженность и сделать удобочитаемыми, в стандарте приняты соответствующие ограничения сложности.
Рекомендуется представлять на диаграмме от трех до шести функциональных блоков, при этом количество подходящих к одному функциональному блоку (выходящих из одного функционального блока) интерфейсных дуг предполагается не более четырех.
Стандарт IDEF0 содержит набор процедур, позволяющих разрабатывать и согласовывать модель большой группой людей, принадлежащих к разным областям деятельности моделируемой системы.
Обычно процесс разработки является итеративным и состоит из следующих условных этапов : Создание модели группой специалистов, относящихся к различным сферам деятельности предприятия. Эта группа в терминах IDEF0 называется авторами (Authors). Построение первоначальной модели является динамическим процессом, в течение которого авторы опрашивают компетентных лиц о структуре различных процессов, создавая модели деятельности подразделений.
При этом их интересуют ответы на следующие вопросы:
Что поступает в подразделение "на входе"?
Какие функции и в какой последовательности выполняются в рамках подразделения?
Кто является ответственным за выполнение каждой из функций ?
Чем руководствуется исполнитель при выполнении каждой из функций ?
Что является результатом работы подразделения (на выходе)?
На основе имеющихся положений, документов и результатов опросов создается черновик (Model Draft) модели.
Распространение черновика для рассмотрения, согласований и комментариев. На этой стадии происходит обсуждение черновика модели с широким кругом компетентных лиц (в терминах IDEF0 — читателей) на предприятии. При этом каждая из диаграмм черновой модели письменно критикуется и комментируется, а затем передается автору. Автор, в свою очередь, также письменно соглашается с критикой или отвергает ее с изложением логики принятия решения и вновь возвращает откорректированный черновик для дальнейшего рассмотрения. Этот цикл продолжается до тех пор, пока авторы и читатели не придут к единому мнению.
Официальное утверждение модели. Утверждение согласованной модели происходит руководителем рабочей группы в том случае, если у авторов модели и читателей отсутствуют разногласия по поводу ее адекватности. Окончательная модель представляет собой согласованное представление о предприятии (системе) с заданной точки зрения и для заданной цели.
Наглядность графического языка IDEF0 делает модель вполне читаемой и для лиц, которые не принимали участия в проекте ее создания, а также эффективной для проведения показов и презентаций. В дальнейшем на базе построенной модели могут быть организованы новые проекты, нацеленные на производство изменений в модели.
Модель IDEF0 рекомендована к применению в предприятии при описании бизнес-процессов на верхнем уровне. При составлении функциональной модели бизнес-процесса (IDEF0) описываются выполняемые функции и входные, выходные потоки материальных, финансовых ресурсов и информации (документов, файлов).
Условные обозначения формата IDEF0 представлены в таблицах 2,3.
Таблица 2. - Графические символы нотации IDEF0
| Символ | Изображение | Описание |
| Блок | Блок описывает процесс. Типичный блок показан на рис. 1. Внутри каждого блока помещается его имя и номер. Имя должно быть активным глаголом, глагольным оборотом или отглагольным существительным. Номер блока размещается в правом нижнем углу. Номера блоков используются для идентификации на диаграмме и в соответствующем тексте. | |
| Стрелка | Стрелки обозначают входящие и исходящие из процесса объекты (данные). Каждая сторона функционального блока имеет стандартное значение с точки зрения связи блок-стрелка, В свою очередь, сторона блока, к которой присоединена стрелка, однозначно определяет ее роль. Стрелки, входящие в левую сторону блока - входы. Стрелки, входящие в блок сверху - управления. Стрелки, покидающие процесс справа - выходы, т.е. данные или материальные объекты, произведенные процессом. Стрелки, подключенные к нижней стороне блока, представляют механизмы. | |
| Туннелированная стрелка | Туннелированные стрелки означают, что данные, обозначаемые этими стрелками, не рассматриваются на родительской диаграмме и/или на дочерней диаграмме. Стрелка, помещенная в туннель там, где она присоединяется к блоку, означает, что данные, выраженные этой стрелкой, не обязательны на следующем уровне декомпозиции. Стрелка, помещаемая в туннель на свободном конце означает, что выраженные ею данные отсутствуют на родительской диаграмме. | |
| Внешняя ссылка | Внешняя ссылка - место, сущность или субъект, которые находятся за границами моделируемой системы. Используются для обозначения источника или приемника стрелки вне модели. На диаграммах Внешняя ссылка изображается в виде квадрата, рядом с которым показано наименование Внешней ссылки. | |
| Междиаграммная ссылка | Элемент, обозначающий другую диаграмму. Служит для обозначения перехода стрелок на диаграмму другого бизнес-процесса без показа стрелки на вышележащей диаграмме (при использовании иерархических моделей). |
Таблица 3. - Графические символы нотации IDEF0
Р 50.1.028-2001
Информационные технологии поддержки жизненного цикла продукции
МЕТОДОЛОГИЯ ФУНКЦИОНАЛЬНОГО МОДЕЛИРОВАНИЯ
Continuous acquisition and life-cycle support.
Methodology of functional modelling
ОКС 25.040.40
ОКСТУ 4002
Дата введения 2002-07-01
Предисловие
1
РАЗРАБОТАНЫ Научно-исследовательским Центром CALS-технологий
"Прикладная Логистика" при участии Всероссийского
научно-исследовательского института стандартизации
(ВНИИстандарт)
ВНЕСЕНЫ Техническим
комитетом по стандартизации ТК 431 "CALS-технологии"
2
ПРИНЯТЫ И ВВЕДЕНЫ В ДЕЙСТВИЕ Постановлением Госстандарта России от
2 июля 2001 г. N 256-ст
3
ВВЕДЕНЫ ВПЕРВЫЕ
Введение
Введение
Постоянное усложнение
производственно-технических и организационно-экономических систем -
фирм, предприятий, производств и других субъектов
производственно-хозяйственной деятельности - и необходимость их
анализа с целью совершенствования функционирования и повышения
эффективности обусловливают необходимость применения специальных
средств описания и анализа таких систем. Эта проблема приобретает
особую актуальность в связи с появлением интегрированных
компьютеризированных производств и автоматизированных
предприятий.
В
США в конце 70-х годов была предложена и реализована Программа
интегрированной компьютеризации производства ICAM (Integrated
Computer Aided Manufacturing), направленная на увеличение
эффективности промышленных предприятий посредством широкого
внедрения компьютерных (информационных) технологий.
Реализация программы ICAM
потребовала создания адекватных методов анализа и проектирования
производственных систем и способов обмена информацией между
специалистами, занимающимися такими проблемами. Для удовлетворения
этой потребности в рамках программы ICAM была разработана
методология моделирования IDEF (ICAM Definition), позволяющая
исследовать структуру, параметры и характеристики
производственно-технических и организационно-экономических систем.
Общая методология IDEF состоит из трех частных методологий
моделирования, основанных на графическом представлении систем:
IDEF0 используется для
создания функциональной модели, отображающей структуру и функции
системы, а также потоки информации и материальных объектов,
преобразуемые этими функциями;
IDEF1 применяется для
построения информационной модели, отображающей структуру и
содержание информационных потоков, необходимых для поддержки
функций системы;
IDEF2 позволяет построить
динамическую модель меняющихся во времени поведения функций,
информации и ресурсов системы.
К
настоящему времени наибольшее распространение и применение имеют
методологии IDEF0 и IDEF1 (IDEF1X).
Методология IDEF0,
особенности и приемы применения которой описываются в настоящих
рекомендациях, основана на подходе, получившем название SADT
(Structured Analysis & Design Technique - метод структурного
анализа и проектирования). Основу этого подхода и методологии IDEF0
составляет графический язык описания (моделирования) систем.
В
связи с расширяющимся применением информационных технологий и, в
частности, CALS-технологий в народном хозяйстве Российской
Федерации в настоящих рекомендациях приводятся основные сведения о
методологии IDEF0 и графическом языке описания моделей, а также
практические указания по методике разработки таких моделей.
1 Область применения
Настоящие рекомендации по
стандартизации предназначены для использования при анализе и
синтезе производственно-технических и организационно-экономических
систем методами функционального моделирования в различных отраслях
экономики. Рекомендации содержат описание комплекса средств для
наглядного представления широкого спектра деловых, производственных
и других процессов и операций предприятия на любом уровне
детализации, а также организационные и методические приемы
применения этих средств.
2 Определения
2.1 блок: Прямоугольник,
содержащий имя и номер и используемый для описания функции.
2.2 ветвление: Разделение
стрелки на два или большее число сегментов. Может означать
"развязывание пучка" (см. 2.27).
2.3 внутренняя стрелка:
Входная, управляющая или выходная стрелка, концы которой связывают
источник и потребителя, являющиеся блоками одной диаграммы.
Отличается от граничной стрелки.
2.4 входная стрелка:
Класс стрелок, отображающих вход IDEF0-блока, то есть данные или
материальные объекты, которые преобразуются функцией в выход.
Входные стрелки связываются с левой стороной блока IDEF0.
2.5 выходная стрелка:
Класс стрелок, отображающих выход IDEF0-блока, то есть данные или
материальные объекты, произведенные функцией. Выходные стрелки
связываются с правой стороной блока IDEF0.
2.6 глоссарий: Список
определений для ключевых слов, фраз и аббревиатур, связанных с
узлами, блоками, стрелками или с моделью IDEF0 в целом.
2.7 граничная стрелка:
Стрелка, один из концов которой связан с источником или
потребителем, а другой не присоединен ни к какому блоку на
диаграмме. Отображает связь диаграммы с другими блоками системы и
отличается от внутренней стрелки.
2.9 дерево узлов:
Представление отношений между родительскими и дочерними узлами
модели IDEF0 в форме древовидного графа. Имеет то же значение и
содержание, что и перечень узлов (см. 2.23).
2.10 диаграмма А-0 (А
минус ноль): Специальный вид (контекстной) диаграммы IDEF0,
состоящей из одного блока, описывающего функцию верхнего уровня, ее
входы, выходы, управление, и механизмы, вместе с формулировками
цели модели и точки зрения, с которой строится модель.
2.11 диаграмма: Часть
модели, описывающая декомпозицию блока.
2.12
диаграмма-иллюстрация (FEO): Графическое описание, используемое для
сообщения специфических фактов о диаграмме IDEF0. При построении
диаграмм FEO можно не придерживаться правил IDEF0.
2.13 дочерний блок: Блок
на дочерней (порожденной) диаграмме.
2.14 дочерняя диаграмма:
Диаграмма, детализирующая родительский (порождающий) блок.
2.15 имя блока: Глагол
или глагольный оборот, помещенный внутри блока и описывающий
моделируемую функцию.
2.16 интерфейс:
Разделяющая граница, через которую проходят данные или материальные
объекты; соединение между двумя или большим числом компонентов
модели, передающее данные или материальные объекты от одного
компонента к другому.
2.17 код ICOM
(аббревиатура Input - вход, Control - управление, Output - выход,
Mechanism - механизм): Код, обеспечивающий соответствие граничных
стрелок дочерней диаграммы со стрелками родительского блока;
используется для ссылок.
2.18 контекст: Окружающая
среда, в которой действует функция (или комплект функций на
диаграмме).
2.19 контекстная
диаграмма: Диаграмма, имеющая узловой номер А- (А минус ) (), которая представляет контекст модели.
Диаграмма А-0, состоящая из одного блока, является необходимой
(обязательной) контекстной диаграммой; диаграммы с узловыми
номерами А-1, А-2, (А минус 1, А минус 2)…, - дополнительные
контекстные диаграммы.
2.20 метка стрелки:
Существительное или оборот существительного, связанные со стрелкой
или сегментом стрелки и определяющие их значение.
2.21 модель IDEF0:
Графическое описание системы, разработанное с определенной целью
(см. 2.46) и с выбранной точки зрения (см. 2.39). Комплект
документов IDEF0, которые изображают функции системы с помощью
графики (диаграмм), текста и глоссария.
2.22 номер блока: Число
(0-6), помещаемое в правом нижнем углу блока и однозначно
идентифицирующее блок на диаграмме.
2.23 перечень узлов:
Список, часто ступенчатый, показывающий узлы модели IDEF0 в
упорядоченном виде. Имеет то же значение и содержание, что и дерево
узлов (см. 2.9).
2.24 примечание к модели:
Текстовый комментарий, являющийся частью диаграммы IDEF0 и
используемый для записи факта, не нашедшего графического
изображения.
2.25 родительская
диаграмма: Диаграмма, которая содержит родительский блок.
2.26 родительский блок:
Блок, который подробно описывается дочерней диаграммой.
2.27
связывание/развязывание: Объединение значений стрелок в составное
значение (связывание в "пучок"), или разделение значений стрелок
(развязывание "пучка"), выраженные синтаксисом слияния или
ветвления стрелок.
2.28 сегмент стрелки:
Сегмент линии, который начинается или заканчивается на стороне
блока, в точке ветвления или слияния, или на границе (несвязанный
конец стрелки).
2.29 семантика: Значение
синтаксических компонентов языка.
2.30 синтаксис:
Структурные компоненты или характеристики языка и правила, которые
определяют отношения между ними.
2.31 слияние: Объединение
двух или большего числа сегментов стрелок в один сегмент. Может
означать "связывание пучка" (см. 2.27).
2.32 С-номер: Номер,
создаваемый в хронологическом порядке и используемый для
идентификации диаграммы и прослеживания ее истории; может быть
использован в качестве ссылочного выражения при определении
конкретной версии диаграммы. Обычно С-номер состоит из инициалов
автора модели и хронологических данных (даты создания очередной
версии диаграммы).
2.33 стрелка:
Направленная линия, состоящая из одного или нескольких сегментов,
которая моделирует открытый канал или канал, передающий данные или
материальные объекты от источника (начальная точка стрелки), к
потребителю (конечная точка с "наконечником"). Имеется четыре
класса стрелок: входная, выходная, управляющая стрелка механизма
(включает стрелку вызова). (См. сегмент стрелки, граничная стрелка,
внутренняя стрелка).
2.34 стрелка вызова: Вид
стрелки механизма, который обозначает обращение из блока данной
модели (или части модели) к блоку другой модели (или другой части
той же модели) и обеспечивает связь между моделями или между
разными частями одной модели.
2.35 стрелка механизма:
Класс стрелок, которые отображают механизмы IDEF0, то есть
средства, используемые для выполнения функции; включает специальный
случай стрелки вызова. Стрелки механизмов связываются с нижней
стороной блока IDEF0.
2.36 стрелка, помещенная
в туннель (туннельная стрелка): Стрелка (со специальной нотацией),
не удовлетворяющая обычному требованию, согласно которому каждая
стрелка на дочерней диаграмме должна соответствовать стрелкам на
родительской диаграмме. Туннельные стрелки - дополнительное
средство графического языка, облегчающее чтение и понимание
диаграмм.
2.37 текст: Любой
текстовый (не графический) комментарий к графической диаграмме
IDEF0.
2.38 тильда: Небольшая
ломаная (волнистая) линия, используемая для соединения метки с
конкретным сегментом стрелки или примечания модели с компонентом
диаграммы.
2.39 точка зрения:
Указание на должностное лицо или подразделение организации, с
позиции которого разрабатывается модель. Для каждой модели точка
зрения единственная.
2.40 узел: Блок,
порождающий дочерние блоки; родительский блок. (См. перечень узлов,
дерево узлов, узловой номер, узловая ссылка, номер узла
диаграммы).
2.42 узловой номер
диаграммы: Часть узловой ссылки диаграммы, которая соответствует
номеру родительского блока.
2.43 узловой номер: Код,
присвоенный блоку и определяющий его положение в иерархии модели;
может быть использован в качестве подробного ссылочного
выражения.
2.44 управляющая стрелка:
Класс стрелок, которые в IDEF0 отображают управления, то есть
условия, при выполнении которых выход блока будет правильным.
Данные или объекты, моделируемые как управления, могут
преобразовываться функцией, создающей соответствующий выход.
Управляющие стрелки связываются с верхней стороной блока IDEF0.
2.45 функция:
Деятельность, процесс или преобразование (моделируемые блоком
IDEF0), идентифицируемое глаголом или глагольной формой, которая
описывает, что должно быть выполнено.
2.46 цель: Краткая
формулировка причины создания модели.
3 Сокращения
Сокращения, принятые в
настоящих рекомендациях:
ICAM - интегрированная
компьютеризация производства.
ICOM - вход (Input),
управление (Control), выход (Output), механизм (Mechanism).
IDEF0 - методология,
используемая для создания функциональной модели.
IDEF1 - методология,
используемая для создания информационной модели.
IDEF2 - методология,
используемая для создания динамической модели.
FEO -
диаграмма-иллюстрация.
4 Концепция IDEF0
Методология IDEF0
основана на следующих концептуальных положениях.
4.1 Модель -
искусственный объект, представляющий собой отображение (образ)
системы и ее компонентов. Считается, что
М
моделирует А, если М отвечает на вопросы относительно А.
Здесь М - модель, А -
моделируемый объект (оригинал). Модель разрабатывают для понимания,
анализа и принятия решений о реконструкции (реинжиниринге) или
замене существующей, либо проектировании новой системы. Система
представляет собой совокупность взаимосвязанных и взаимодействующих
частей, выполняющих некоторую полезную работу. Частями (элементами)
системы могут быть любые комбинации разнообразных сущностей,
включающие людей, информацию, программное обеспечение,
оборудование, изделия, сырье или энергию (энергоносители). Модель
описывает, что происходит в системе, как ею управляют, что она
преобразует, какие средства использует для выполнения своих функций
и что производит.
4.2 Блочное моделирование
и его графическое представление. Основной концептуальный принцип
методологии IDEF - представление любой изучаемой системы в виде
набора взаимодействующих и взаимосвязанных блоков, отображающих
процессы, операции, действия (определения - см. ниже), происходящие
в изучаемой системе. В IDEF0 все, что происходит в системе и ее
элементах, принято называть функциями. Каждой функции ставится в
соответствие блок. На IDEF0-диаграмме, основном документе при
анализе и проектировании систем, блок представляет собой
прямоугольник. Интерфейсы, посредством которых блок взаимодействует
с другими блоками или с внешней по отношению к моделируемой системе
средой, представляются стрелками, входящими в блок или выходящими
из него. Входящие стрелки показывают, какие условия должны быть
одновременно выполнены, чтобы функция, описываемая блоком,
осуществилась.
4.3 Лаконичность и
точность. Документация, описывающая систему, должна быть точной и
лаконичной. Сведения о свойствах и характеристиках системы в форме
традиционных текстов в этом смысле неудовлетворительны, поскольку
зачастую содержат избыточную информацию, допускают неоднозначное
толкование и т.д. Графический язык позволяет лаконично, однозначно
и точно показать все элементы (блоки) системы и все отношения и
связи между ними, выявить ошибочные, лишние или дублирующие связи и
т.д.
4.4 Передача информации.
Средства IDEF0 облегчают передачу информации от одного участника
разработки модели (отдельного разработчика или рабочей группы) к
другому. К числу таких средств относятся:
-
диаграммы, основанные на простой графике блоков и стрелок, легко
читаемые и понимаемые;
-
метки на естественном языке для описания блоков и стрелок, а также
глоссарий и сопроводительный текст, уточняющие смысл элементов
диаграммы;
-
последовательная декомпозиция диаграмм, строящаяся по
иерархическому принципу, при котором на верхнем уровне отображаются
основные функции, а затем происходит их детализация и
уточнение;
-
древовидные схемы иерархии диаграмм и блоков, обеспечивающие
обозримость модели в целом и входящих в нее деталей, что особенно
важно при моделировании больших систем.
4.5 Строгость и
формализм. Разработка моделей IDEF0 требует соблюдения ряда строгих
формальных правил, обеспечивающих преимущества методологии в
отношении однозначности, точности и целостности сложных
многоуровневых моделей. Эти правила описываются ниже. Здесь
отмечается только основное из них: на всех стадиях и этапах
разработки и корректировки модели должны строго, формально
соблюдаться синтаксические и семантические правила графического
языка, а результаты - тщательно документироваться с тем, чтобы при
ее эксплуатации не возникало вопросов, связанных с неполнотой или
некорректностью документации. Программный продукт Design/IDEF 3.7
(и более поздние версии) фирмы Meta Software Corporation
поддерживает автоматическое соблюдение большинства из перечисленных
правил.
4.6 Итеративное
моделирование. Разработка модели в IDEF0 представляет собой
пошаговую, итеративную процедуру. На каждом шаге итерации
разработчик предлагает вариант модели, который подвергают
обсуждению, рецензированию и последующему редактированию, после
чего цикл повторяется. Такая организация работы способствует
оптимальному использованию знаний системного аналитика, владеющего
методологией и техникой IDEF0, и знаний специалистов - экспертов в
предметной области, к которой относится объект моделирования.
4.7 Отделение
"организации" от "функций". При разработке моделей следует избегать
изначальной "привязки" функций исследуемой системы к существующей
организационной структуре моделируемого объекта (предприятия,
фирмы). Это помогает избежать субъективной точки зрения, навязанной
организацией и ее руководством. Организационная структура должна
явиться результатом использования (применения) модели. Сравнение
результата с существующей структурой позволяет, во-первых, оценить
адекватность модели, а во-вторых - предложить решения, направленные
на совершенствование этой структуры.
5 Синтаксис графического языка IDEF0
Набор структурных
компонентов языка, их характеристики и правила, определяющие связи
между компонентами, представляют собой синтаксис языка. Компоненты
синтаксиса IDEF0 - блоки, стрелки, диаграммы и правила. Блоки
представляют функции, определяемые как деятельность, процесс,
операция, действие или преобразование (см. ниже). Стрелки
представляют данные или материальные объекты, связанные с
функциями. Правила определяют, как следует применять компоненты;
диаграммы обеспечивают формат графического и словесного описания
моделей. Формат образует основу для управления конфигурацией
модели.
Блок описывает функцию.
Типичный блок показан на рисунке 1. Внутри каждого блока помещаются
его имя и номер. Имя должно быть активным глаголом или глагольным
оборотом, описывающим функцию. Номер блока размещается в правом
нижнем углу. Номера блоков используются для их идентификации на
диаграмме и в соответствующем тексте.
Рисунок 1
Рисунок 1
5.2 Стрелка
Стрелка формируется из
одного или нескольких отрезков прямых и наконечника на одном конце.
Как показано на рисунке 2, сегменты стрелок могут быть прямыми или
ломаными; в последнем случае горизонтальные и вертикальные отрезки
стрелки сопрягаются дугами, имеющими угол 90°. Стрелки не
представляют поток или последовательность событий, как в
традиционных блок-схемах потоков или процессов (потоковых
диаграммах). Они лишь показывают, какие данные или материальные
объекты должны поступить на вход функции для того, чтобы эта
функция могла выполняться.
Рисунок 2
Рисунок 2
5.3 Синтаксические правила
5.3.1 Блоки
Для блоков установлены
следующие синтаксические правила:
-
размеры блоков должны быть достаточными для того, чтобы включить
имя и номер блока;
-
блоки должны быть прямоугольными, с прямыми углами;
-
блоки должны быть нарисованы сплошными линиями.
5.3.2 Стрелки
Для стрелок установлены
следующие синтаксические правила:
-
ломаные стрелки изменяют направление только под углом 90°;
-
стрелки должны быть нарисованы сплошными линиями. Можно
использовать линии различной толщины;
-
стрелки могут состоять только из вертикальных или горизонтальных
отрезков; отрезки, направленные по диагонали, не допускаются;
-
концы стрелок должны касаться внешней границы функционального
блока, но не должны пересекать ее;
-
стрелки должны присоединяться к блоку на его сторонах.
Присоединение в углах не допускается.
6 Семантика языка IDEF0
Семантика определяет
содержание (значение) синтаксических компонентов языка и
способствует правильности их интерпретации. Интерпретация
устанавливает соответствие между блоками и стрелками, с одной
стороны, и функциями и их интерфейсами - с другой.
6.1 Семантика блоков и стрелок
Поскольку IDEF0 есть
методология функционального моделирования, имя блока, описывающее
функцию, должно быть глаголом или глагольным оборотом. Например,
имя блока "Выполнить проверку" означает, что блок с таким именем
превращает непроверенные детали в проверенные. После присваивания
блоку имени, к соответствующим его сторонам присоединяются входные,
выходные и управляющие стрелки, а также стрелки механизма, что и
определяет наглядность и выразительность изображения блока IDEF0
(см. рисунок 3).
Рисунок 3
Рисунок 3
Чтобы гарантировать
точность модели, следует использовать стандартную терминологию.
Блоки именуются глаголами или глагольными оборотами, и эти имена
сохраняются при декомпозиции. Стрелки и их сегменты, как отдельные,
так и связанные в "пучок", помечаются существительными или
оборотами существительного. Метки сегментов позволяют
конкретизировать данные или материальные объекты, передаваемые
этими сегментами, с соблюдением синтаксиса ветвлений и слияний.
Каждая сторона
функционального блока имеет стандартное назначение с точки зрения
связи блок/стрелки. В свою очередь, сторона блока, к которой
присоединена стрелка, однозначно определяет ее роль. Стрелка (и),
входящая (ие) в левую сторону блока, - вход (ы). Входы
преобразуются или расходуются функцией, чтобы создать то, что
появится на ее выходе. Стрелка (и), входящая (ие) в блок сверху, -
управление (я). Управление (я) определяет (ют) условия, необходимые
функции, чтобы произвести правильный выход. Стрелка (и), покидающая
(ие) блок справа, - выход (ы), то есть данные или материальные
объекты, произведенные функцией.
Стрелки, подключенные к
нижней стороне блока, представляют механизмы, то есть все то, с
помощью чего осуществляется преобразование входов в выходы.
Стрелки, направленные вверх, идентифицируют средства,
поддерживающие выполнение функции. Другие средства могут
наследоваться из родительского блока. Стрелки механизма,
направленные вниз, являются стрелками вызова. Стрелки вызова
обозначают обращение из данной модели или из данной части модели к
блоку, входящему в состав другой модели или другой части модели,
обеспечивая их связь, то есть разные модели или разные части одной
и той же модели могут совместно использовать один и тот же элемент
(блок).
Стандартное расположение
стрелок показано на рисунке 3.
6.2 Имена и метки
Как указывалось, имена
функций - глаголы или глагольные обороты.
Примеры таких имен:
производить детали
наблюдать за
выполнением
разработать детальные
чертежи
планировать ресурсы
проектировать систему
изготовить компонент
наблюдать
эксплуатировать
проверять деталь
Стрелки идентифицируют
данные или материальные объекты, необходимые для выполнения функции
или производимые ею. Каждая стрелка должна быть помечена
существительным или оборотом существительного, например:
спецификации
конструкторские
требования
инженер-конструктор
отчет об испытаниях
конструкция детали
плата в сборе
бюджет
директива
требования
Пример размещения меток
стрелок и имени блока показан на рисунке 4.
Рисунок 4
Рисунок 4
6.3 Сводка семантических правил для блоков и стрелок
а) Имя блока должно быть
глаголом или глагольным оборотом.
б) Каждая сторона
функционального блока имеет стандартное отношение блок/стрелки:
-
входные стрелки должны связываться с левой стороной блока;
-
управляющие стрелки должны связываться с верхней стороной
блока;
-
выходные стрелки должны связываться с правой стороной блока;
-
стрелки механизма (кроме стрелок вызова) должны указывать вверх и
подключаться к нижней стороне блока;
-
стрелки вызова механизма должны указывать вниз, подключаться к
нижней стороне блока, и помечаться ссылкой на вызываемый блок.
в) Сегменты стрелок, за
исключением стрелок вызова, должны помечаться существительным или
оборотом существительного, если только единственная метка стрелки
не относится к стрелке в целом.
г) Чтобы связать стрелку
с меткой, следует использовать ломаную молниеобразную выносную
линию ().
д) В метках стрелок не
должны использоваться следующие термины: функция, вход, управление,
выход, механизм, вызов.
6.4 Диаграммы IDEF0
IDEF0-модели состоят из
документов трех типов: графических диаграмм, текста и глоссария.
Эти документы имеют перекрестные ссылки друг на друга. Графическая
диаграмма - главный компонент IDEF0-модели, содержащий блоки,
стрелки, соединения блоков и стрелок и ассоциированные с ними
отношения. Блоки представляют основные функции моделируемого
объекта. Эти функции могут быть разбиты (декомпозированы) на
составные части и представлены в виде более подробных диаграмм;
процесс декомпозиции продолжается до тех пор, пока объект не будет
описан на уровне детализации, необходимом для достижения целей
конкретного проекта.
Диаграмма верхнего уровня
обеспечивает наиболее общее описание объекта моделирования. За этой
диаграммой следует серия дочерних диаграмм, дающих более детальное
представление об объекте.
6.5 Контекстная диаграмма верхнего уровня
Каждая модель должна
иметь контекстную диаграмму верхнего уровня, на которой объект
моделирования представлен единственным блоком с граничными
стрелками. Эта диаграмма называется А-0 (А минус ноль). Стрелки на
этой диаграмме отображают связи объекта моделирования с окружающей
средой. Поскольку единственный блок представляет весь объект, его
имя - общее для всего проекта. Это же справедливо и для всех
стрелок диаграммы, поскольку они представляют полный комплект
внешних интерфейсов объекта. Диаграмма А-0 устанавливает область
моделирования и ее границу. Пример диаграммы А-0 показан на рисунке
5.
Рисунок 5
Рисунок 5
Контекстная диаграмма А-0
также должна содержать краткие утверждения, определяющие точку
зрения должностного лица или подразделения, с позиций которого
создается модель, и цель, для достижения которой ее разрабатывают.
Эти утверждения помогают руководить разработкой модели и ввести
этот процесс в определенные рамки. Точка зрения определяет, что и в
каком разрезе можно увидеть в пределах контекста модели. Изменение
точки зрения приводит к рассмотрению других аспектов объекта.
Аспекты, важные с одной точки зрения, могут не появиться в модели,
разрабатываемой с другой точки зрения на тот же самый объект.
Формулировка цели
выражает причину создания модели, то есть содержит перечень
вопросов, на которые должна отвечать модель, что в значительной
мере определяет ее структуру. Наиболее важные свойства объекта
обычно выявляются на верхних уровнях иерархии; по мере декомпозиции
функции верхнего уровня и разбиения ее на подфункции, эти свойства
уточняются. Каждая подфункция, в свою очередь, декомпозируется на
элементы следующего уровня, и так происходит до тех пор, пока не
будет получена релевантная структура, позволяющая ответить на
вопросы, сформулированные в цели моделирования. Каждая подфункция
моделируется отдельным блоком. Каждый родительский блок подробно
описывается дочерней диаграммой на более низком уровне. Все
дочерние диаграммы должны быть в пределах области контекстной
диаграммы верхнего уровня.
6.6 Дочерняя диаграмма
Единственная функция,
представленная на контекстной диаграмме верхнего уровня, может быть
разложена на основные подфункции посредством создания дочерней
диаграммы. В свою очередь, каждая из этих подфункций может быть
разложена на составные части посредством создания дочерней
диаграммы следующего, более низкого уровня, на которой некоторые
или все функции также могут быть разложены на составные части.
Каждая дочерняя диаграмма содержит дочерние блоки и стрелки,
обеспечивающие дополнительную детализацию родительского блока.
Дочерняя диаграмма,
создаваемая при декомпозиции, охватывает ту же область, что и
родительский блок, но описывает ее более подробно.
Таким образом, дочерняя
диаграмма как бы вложена в свой родительский блок. Эта структура
иллюстрируется рисунком 6.
Рисунок 6
Рисунок 6
6.7 Родительская диаграмма
Родительская диаграмма -
та, которая содержит один или более родительских блоков. Иными
словами, это диаграмма верхнего уровня, на которой располагается
декомпозируемая функция со всеми ее связями. Каждая обычная
(неконтекстная) диаграмма является также дочерней диаграммой,
поскольку, по определению, она подробно описывает некоторый
родительский блок. Таким образом, любая диаграмма может быть как
родительской диаграммой (содержать родительские блоки), так и
дочерней (подробно описывать собственный родительский блок).
Аналогично, блок может быть как родительским (подробно описываться
дочерней диаграммой), так и дочерним (появляющимся на дочерней
диаграмме). Основное иерархическое отношение существует между
родительским блоком и дочерней диаграммой, которая его подробно
описывает (рисунок 6).
То, что блок является
дочерним и раскрывает содержание родительского блока на диаграмме
предшествующего уровня, указывается специальным ссылочным кодом,
написанным ниже правого нижнего угла блока. Этот ссылочный код
может формироваться несколькими способами, из которых самый простой
заключается в том, что код, начинающийся с буквы А (по имени
диаграммы А-0), содержит цифры, определяемые номерами родительских
блоков. Например, показанные на рисунке 7 коды означают, что
диаграмма является декомпозицией 1-го блока диаграммы, которая, в
свою очередь, является декомпозицией 6-го блока диаграммы А0, а
сами коды образуются присоединением номера блока.
Рисунок 7
Рисунок 7
Следовательно, код
формируется так:
6.8 Текст и глоссарий
Диаграмме может быть
поставлен в соответствие структурированный текст, представляющий
собой краткий комментарий к содержанию диаграммы.
Текст используется для
объяснений и уточнений характеристик, потоков, внутриблочных
соединений и т.д. Текст не должен использоваться для описания и без
того понятных блоков и стрелок на диаграммах. При большом объеме
текст располагается на отдельном листе модели (текстовой
странице).
Глоссарий предназначен
для определения аббревиатур, ключевых слов и фраз, используемых в
качестве имен и меток на диаграммах. Глоссарий определяет понятия и
термины, которые должны быть одинаково понимаемы всеми участниками
разработки и пользователями модели, чтобы правильно
интерпретировать ее содержание. Глоссарий составляется с любой
необходимой степенью подробности.
6.9 Диаграммы-иллюстрации (FEO)
[email protected] , мы разберемся.
6.2. Назначение и состав методологии SADT (IDEF0)Методология SADT (Structured Analysis and Design Technique – методология структурного анализа и проектирования) представляет собой совокупность методов, правил и процедур, предназначенных для построения функциональной модели системы.
Начало разработки данной методологии было положено Дугласом Россом (США) в середине 60-х гг. ХХ в. С тех пор системные аналитики компании SofTech, Inc. улучшили SADT и использовали ее в решении широкого круга проблем. Программное обеспечение телефонных сетей, диагностика, долгосрочное и стратегическое планирование, автоматизированное производство и проектирование, конфигурация компьютерных систем, обучение персонала, управление финансами и материально-техническим снабжением – вот некоторые из областей эффективного применения SADT. Широкий спектр областей указывает на универсальность и мощь методологии SADT. В программе «Интеграции компьютерных и промышленных технологий» (Integrated Computer Aided Manufacturing, ICAM) Министерства обороны США была признана полезность SADT. Это привело к публикации ее части в 1981 г., называемой IDEF0 (Icam DEFinition), в качестве федерального стандарта на разработку программного обеспечения. Под этим названием SADT стала применяться тысячами специалистов в военных и промышленных организациях . Последняя редакция стандарта IDEF0 была выпущена в декабре 1993г. Национальным институтом по стандартам и технологиям США (National Institute Standards and Technology, NIST).
Данная методология при описании функционального аспекта информационной системы конкурирует с методами, ориентированными на потоки данных (DFD). В отличие от них IDEF0 позволяет:
Описывать любые системы, а не только информационные (DFD предназначена для описания программного обеспечения);
Создать описание системы и ее внешнего окружения до определения окончательных требований к ней. Иными словами, с помощью данной методологии можно постепенно выстраивать и анализировать систему даже тогда, когда трудно еще представить ее воплощение.
Таким образом, IDEF0 может применяться на ранних этапах создания широкого круга систем. В то же время она может быть использована для анализа функций существующих систем и выработки решений по их улучшению.
Основу методологии IDEF0 составляет графический язык описания процессов. Модель в нотации IDEF0 представляет собой совокупность иерархически упорядоченных и взаимосвязанных диаграмм. Каждая диаграмма является единицей описания системы и располагается на отдельном листе.
Модель (AS-IS, TO-BE или SHOULD-BE) может содержать 4 типа диаграмм [ , ]:
Контекстную диаграмму;
Диаграммы декомпозиции;
Диаграммы дерева узлов;
Диаграммы только для экспозиции (for exposition only, FEO).
Контекстная диаграмма (диаграмма верхнего уровня), являясь вершиной древовидной структуры диаграмм, показывает назначение системы (основную функцию) и ее взаимодействие с внешней средой. В каждой модели может быть только одна контекстная диаграмма. После описания основной функции выполняется функциональная декомпозиция, т. е. определяются функции, из которых состоит основная.
Далее функции делятся на подфункции и так до достижения требуемого уровня детализации исследуемой системы. Диаграммы, которые описывают каждый такой фрагмент системы, называются диаграммами декомпозиции . После каждого сеанса декомпозиции проводятся сеансы экспертизы – эксперты предметной области указывают на соответствие реальных процессов созданным диаграммам. Найденные несоответствия устраняются, после чего приступают к дальнейшей детализации процессов.
Диаграмма дерева узлов показывает иерархическую зависимость функций (работ), но не связи между ними. Их может быть несколько, поскольку дерево можно построить на произвольную глубину и с произвольного узла.
Диаграммы для экспозиции строятся для иллюстрации отдельных фрагментов модели с целью отображения альтернативной точки зрения на происходящие в системе процессы (например, с точки зрения руководства организации).
6.3. Элементы графической нотации IDEF0
Методология IDEF0 нашла широкое признание и применение, в первую очередь, благодаря простой графической нотации, используемой для построения модели. Главными компонентами модели являются диаграммы. На них отображаются функции системы в виде прямоугольников, а также связи между ними и внешней средой посредством стрелок. Использование всего лишь двух графических примитивов (прямоугольник и стрелка) позволяют быстро объяснить правила и принципы построения диаграмм IDEF0 людям, незнакомым с данной методологией. Это достоинство позволяет подключить и активизировать деятельность заказчика по описанию бизнес-процессов с использованием формального и наглядного графического языка.
На следующем рисунке показаны основные элементы графической нотации IDEF0 .
Рис. 6.1. Элементы графической нотации IDEF0
Прямоугольник представляет собой работу (процесс, деятельность, функцию или задачу) , которая имеет фиксированную цель и приводит к некоторому конечному результату. Имя работы должно выражать действие (например, «Изготовление детали», «Расчет допускаемых скоростей», «Формирование ведомости ЦДЛ № 3»).
Взаимодействие работ между собой и внешним миром описывается в виде стрелок. В IDEF0 различают 5 видов стрелок :
- вход (англ. input) – материал или информация, которые используются и преобразуются работой для получения результата (выхода). Вход отвечает на вопрос «Что подлежит обработке?». В качестве входа может быть как материальный объект (сырье, деталь, экзаменационный билет), так и не имеющий четких физических контуров (запрос к БД, вопрос преподавателя). Допускается, что работа может не иметь ни одной стрелки входа. Стрелки входа всегда рисуются входящими в левую грань работы;
- управление (англ. control) – управляющие, регламентирующие и нормативные данные, которыми руководствуется работа. Управление отвечает на вопрос «В соответствии с чем выполняется работа?». Управление влияет на работу, но не преобразуется ей, т.е. выступает в качестве ограничения. В качестве управления могут быть правила, стандарты, нормативы, расценки, устные указания. Стрелки управления рисуются входящими в верхнюю грань работы. Если при построении диаграммы возникает вопрос, как правильно нарисовать стрелку сверху или слева, то рекомендуется ее рисовать как вход (стрелка слева);
- выход (англ. output) – материал или информация, которые представляют результат выполнения работы. Выход отвечает на вопрос «Что является результатом работы?». В качестве выхода может быть как материальный объект (деталь, автомобиль, платежные документы, ведомость), так и нематериальный (выборка данных из БД, ответ на вопрос, устное указание). Стрелки выхода рисуются исходящими из правой грани работы;
- механизм (англ. mechanism) – ресурсы, которые выполняют работу. Механизм отвечает на вопрос «Кто выполняет работу или посредством чего?». В качестве механизма могут быть персонал предприятия, студент, станок, оборудование, программа. Стрелки механизма рисуются входящими в нижнюю грань работы;
- вызов (англ. call) – стрелка указывает, что некоторая часть работы выполняется за пределами рассматриваемого блока. Стрелки выхода рисуются исходящими из нижней грани работы.
6.4. Типы связей между работами
После определения состава функций и взаимосвязей между ними, возникает вопрос о правильной их композиции (объединении) в модули (подсистемы). При этом подразумевается, что каждая отдельная функция должна решать одну, строго определенную задачу. В противном случае необходима дальнейшая декомпозиция или разделение функций.
При объединении функций в подсистемы необходимо стремиться, чтобы внутренняя связность (между функциями внутри модуля) была как можно сильнее, а внешняя (между функциями, входящими в разные модули), как можно слабее. Опираясь на семантику связей методологии , введем классификацию связей между функциями (работами). Данная классификация является расширением . Типы связей приводятся в порядке уменьшения их значимости (силы связывания). В приводимых примерах утолщенными линиями выделяются функции, между которыми имеется рассматриваемый тип связи.
1. Иерархическая связь (связь «часть» – «целое») имеет место между функцией и подфункциями, из которых она состоит.
Рис. 6.2. Иерархическая связь
2. Регламентирующая (управляющая, подчиненная) связь отражает зависимость одной функции от другой, когда выход одной работы направляется на управление другой. Функцию, из которой выходит управление, следует считать регламентирующей или управляющей, а в которую входит – подчиненной. Различают прямую связь по управлению , когда управление передается с вышестоящей работы на нижестоящую (рис. 6.3), и обратную связь по управлению , когда управление передается от нижестоящей к вышестоящей (рис. 6.4).
3. Функциональная (технологическая) связь имеет место, когда выход одной функции служит входными данными для следующей функции. С точки зрения потока материальных объектов данная связь показывает технологию (последовательность работ) обработки этих объектов. Различают прямую связь по входу , когда выход передается с вышестоящей работы на нижестоящую (рис. 6.5), и обратную связь по входу , когда выход передается с нижестоящей к вышестоящей (рис.6.6).
 |
 |
| Рис. 6.5. Прямая связь по входу | Рис. 6.6. Обратная связь по входу |
4. Потребительская связь имеет место, когда выход одной функции служит механизмом для следующей функции. Таким образом, одна функция потребляет ресурсы, вырабатываемые другой.
Рис. 6.7. Потребительская связь
5. Логическая связь наблюдается между логически однородными функциями. Такие функции, как правило, выполняют одну и ту же работу, но разными (альтернативными) способами или, используя разные исходные данные (материалы).
Рис. 6.8. Логическая связь
6. Коллегиальная (методическая) связь имеет место между функциями, алгоритм работы которых определяется одним и тем же управлением. Аналогом такой связи является совместная работа сотрудников одного отдела (коллег), подчиняющихся начальнику, который отдает указания и приказы (управляющие сигналы). Такая связь также возникает, когда алгоритмы работы этих функций определяются одним и тем же методическим обеспечением (СНИП, ГОСТ, официальными нормативными материалами и т. д.), служащим в качестве управления.
Рис. 6.9. Методическая связь
7. Ресурсная связь возникает между функциями, использующими для своей работы одни и те же ресурсы. Ресурсно-зависимые функции, как правило, не могут выполняться одновременно.
Рис. 6.10. Ресурсная связь
8. Информационная связь имеет место между функциями, использующими в качестве входных данных одну и ту же информацию.
Рис. 6.11. Информационная связь
9. Временная связь возникает между функциями, которые должны выполняться одновременно до или одновременно после другой функции.
Кроме указанных на рисунке случаев, эта связь имеет место также между другими сочетаниями управления, входа и механизма, поступающими в одну функцию.
Рис. 6.12. Временная связь
10. Случайная связь возникает, когда конкретная связь между функциями мала или полностью отсутствует.
Рис. 6.13. Случайная связь
Из приведенных выше типов связей наиболее сильной является иерархическая связь, которая, по сути, и определяет объединение функций в модули (подсистемы). Несколько слабее являются регламентирующие, функциональные и потребительские связи. Функции с этими связями обычно реализуются в одной подсистеме. Логические, коллегиальные, ресурсные и информационные связи одни из самых слабых. Функции, обладающие ими, как правило, реализуют в разных подсистемах, за исключением логически однородных функций (функций, связанных логической связью). Временная связь свидетельствует о слабой зависимости функций друг от друга и требует их реализации в отдельных модулях.
Таким образом, при объединении функций в модули наиболее желательными являются первые пять видов связей. Функции, связанные последними пятью связями, лучше реализовывать в отдельных модулях.
В IDEF0 существуют соглашения (правила и рекомендации) по созданию диаграмм, которые призваны облегчить чтение и экспертизу модели [ , ]. Некоторые из этих правил CASE-средства поддерживают автоматически, выполнение других следует обеспечить вручную.
1. Перед построением модели необходимо определиться, какая модель (модели) системы будет построена. Это подразумевает определение ее типа AS-IS, TO-BE или SHOULD-BE, а также определения позиции, с точки зрения которой строится модель. «Точку зрения» лучше всего представлять себе как место (позицию) человека или объекта, в которое надо встать, чтобы увидеть систему в действии. Например, при построении модели работы продуктового магазина можно среди возможных претендентов, с точки зрения которых рассматривается система, выбрать продавца, кассира, бухгалтера или директора. Обычно выбирается одна точка зрения, наиболее полно охватывающая все нюансы работы системы, и при необходимости для некоторых диаграмм декомпозиции строятся диаграммы FEO, отображающие альтернативную точку зрения.
2. На контекстной диаграмме отображается один блок, показывающий назначение системы. Для него рекомендуется отображать по 2–4 стрелки, входящие и выходящие с каждой стороны.
3. Количество блоков на диаграммах декомпозиции рекомендуется в пределах 3–6. Если на диаграмме декомпозиции два блока, то она, как правило, не имеет смысла. При наличии большого количества блоков диаграмма становится перенасыщенной и трудно читаемой.
4. Блоки на диаграмме декомпозиции следует располагать слева направо и сверху вниз. Такое расположение позволяет более четко отразить логику и последовательность выполнения работ. Кроме этого маршруты стрелок будут менее запутанными и иметь минимальное количество пересечений.
5. Отсутствие у функции одновременно стрелок управления и входа не допускается. Это означает, что запуск данной функции не контролируется и может произойти в любой произвольный момент времени либо вообще никогда.
Рис. 6.14. Функция без управления и входа
Блок с наличием только управления можно рассматривать как вызов в программе функции (процедуры) без параметров. Если у блока имеется вход, то он эквивалентен вызову в программе функции с параметрами. Таким образом, блок без управления и входа эквивалентен функции, которая в программе ни разу не вызывается на исполнение.
На рис. 6.7–6.12, отображающих фрагменты диаграмм IDEF0, встречаются блоки без входа и управления. Это не стоит рассматривать как ошибку, так как подразумевается, что одна из этих стрелок должна быть.
6. У каждого блока должен быть как минимум один выход.
Рис. 6.15. Функция без выхода
Работы без результата не имеют смысла и не должны моделироваться. Исключение составляют работы, отображаемые в модели AS-IS. Их наличие свидетельствует о неэффективности и несовершенстве технологических процессов. В модели TO-BE эти работы должны отсутствовать.
7. При построении диаграмм следует минимизировать число пересечений, петель и поворотов стрелок.
8. Обратные связи и итерации (циклические действия) могут быть изображены с помощью обратных дуг. Обратные связи по входу рисуются «нижней» петлей, обратная связь по управлению – «верхней» (см. рис. 6.4 и 6.6).
9. Каждый блок и каждая стрелка на диаграммах должны обязательно иметь имя. Допускается использовать ветвление (декомпозицию) или слияние (композицию) стрелок. Это связано с тем, что одни и те же данные или объекты, порожденные одной работой, могут использоваться сразу в нескольких других работах. И наоборот, одинаковые или однородные данные и объекты, порожденные разными работами, могут использоваться в одном месте.
Рис. 6.16. Ветвление стрелок
При этом допускается задание различным ветвям стрелки уточняющих имен после разветвления (до слияния). Если какая-либо ветвь после ветвления не именована, то считается, что ее имя соответствует имени стрелки, записанному до ветвления.
Так, на рис. 6.16 управления, входящие в блоки «Изготовление деталей» и «Сборка изделия», имеют уточняющие значения и являются составной частью более общего управления «Чертежи». Для работы блока «Контроль качества» используются все чертежи.
На диаграмме не допускается рисовать стрелки, когда до и после ветвления они не именованы. На рис. 6.17 стрелка, входящая в блок «Формирование типовых ведомостей», не имеет имени до и после ветвления, что является ошибкой.
Рис. 6.17. Неправильное именование стрелок
10. При построении диаграмм для лучшей их читаемости может использоваться механизм туннелирования стрелок. Например, чтобы не загромождать лишними деталями диаграммы верхних уровней (родительские), на диаграммах декомпозиции начало дуги помещают в тоннель.
Рис. 6.18. Туннелирование стрелок
В данном примере при построении модели проведения новогоднего утренника механизм «два топора» не будет отображаться на диаграммах верхних уровней, при чтении которых может возникнуть справедливый вопрос: «А зачем нужны два топора на новогоднем утреннике?».
Аналогичным образом можно выполнять туннелирование с обратной целью – недопущения отображения стрелки на диаграммах низших уровней. В этом случае круглые скобки ставятся на конце стрелки. На контекстной диаграмме (см. рис. 6.21) затуннелирован механизм «Инженер службы пути», входящий в блок «Определение допускаемых скоростей». Такое решение принято, так как инженер непосредственно участвует во всех работах, отображенных на диаграмме декомпозиции этого блока (см. рис. 6.22). Чтобы не показывать эту связь и не загромождать диаграмму декомпозиции, стрелка была затуннелирована.
11. Все стрелки, входящие и выходящие из блока, при построении для него диаграммы декомпозиции должны быть отображены на ней. Исключение составляют затуннелированные стрелки. Имена стрелок, перенесенных на диаграмму декомпозиции, должны совпадать с именами, указанными на диаграмме верхнего уровня.
12. Если две стрелки проходят параллельно (начинаются из одной и той же грани одной работы и заканчиваются на одной и той же грани другой работы), то по возможности следует их объединить и называть единым термином.
Рис. 6.19. Объединение связей
13. Каждый блок на диаграммах должен иметь свой номер. Для того чтобы указать положение любой диаграммы или блока в иерархии, используются номера диаграмм. Блок на диаграмме верхнего уровня обозначается 0, блоки на диаграммах второго уровня – цифрами от 1 до 9 (1, 2, …, 9), блоки на третьем уровне – двумя цифрами, первая из которых указывает на номер детализируемого блока с родительской диаграммы, а вторая номер блока по порядку на текущей диаграмме (11, 12, 25, 63) и т. д. Контекстная диаграмма имеет обозначение «А – 0», диаграмма декомпозиции первого уровня – «А0», диаграммы декомпозиции следующих уровней – состоят из буквы «А», за которой следует номер декомпозируемого блока (например, «А11», «А12», «А25», «А63»). На рисунке показано типичное дерево диаграмм (диаграмма дерева узлов) с нумерацией.
Рис. 6.20. Иерархия диаграмм
В современных CASE-средствах механизмы нумерации работ поддерживается автоматически. CASE-средства обеспечивают также автоматическое построение диаграмм дерева узлов, которые содержат только иерархические связи. Вершиной такой диаграммы может быть любой узел (блок), и она может быть построена на любую глубину.
6.6. Пример построения модели IDEF0 для системы определения допускаемых скоростей
Расчет допускаемых скоростей движения поездов является трудоемкой инженерной задачей. При проходе поездом какого-либо участка фактическая скорость движения поезда не должна превышать предельно допускаемую. Эта предельно допускаемая скорость устанавливается исходя из опыта эксплуатации и специально проводимых испытаний по динамике движения и воздействию на путь подвижного состава. Непревышение этой скорости гарантирует безопасность движения поездов, комфортабельные условия езды пассажиров и т. п. Они определяются в зависимости от типа подвижного состава (марки локомотива и типа вагонов), параметров верхнего строения пути (типа рельсов, балласта, эпюры шпал) и плана (радиуса кривых, переходных кривых, возвышения наружного рельса и т. д.). Как правило, для установления допускаемых скоростей необходимо определить не менее двух (на прямых) и пяти (в кривых) скоростей, из которых и выбирается окончательная допускаемая скорость, как наименьшая из всех рассчитанных. Расчет этих скоростей регламентируются Приказом МПС России № 41 от 12 ноября 2001 г. «Нормы допускаемых скоростей движения подвижного состава по железнодорожным путям колеи 1520 (1524) мм Федерального железнодорожного транспорта».
Как было отмечено, построение модели IDEF0 начинается с представления всей системы в виде простейшей компоненты (контекстной диаграммы). Данная диаграмма отображает назначение (основную функцию) системы и необходимые входные и выходные данные, управляющую и регламентирующую информацию, а также механизмы.
Контекстная диаграмма для задачи определения допускаемых скоростей показана на рис.6.21. Для построения модели использовался продукт BPwin 4.0 фирмы Computer Associates.
Рис. 6.21. Контекстная диаграмма системы определения допускаемых скоростей (методология IDEF0)
В качестве исходной информации , на основе которой выполняется определение допускаемых скоростей, используются:
Данные проекта новой линии или проекта реконструкции (содержат всю необходимую информацию для реализации проекта, а именно километраж, оси раздельных пунктов, план линии и др.);
Подробный продольный профиль (содержит информацию, аналогичную рассмотренной выше);
Паспорт дистанции пути (содержит информацию, аналогичную рассмотренной выше, а также сведения о верхнем строении пути (ВСП));
Данные о результатах съемки плана пути вагоном-путеизмерителем;
Ведомость возвышений наружного рельса в кривых (содержит информацию о плане пути).
Часть исходной информации может быть взята из разных источников. В частности сведения о плане (параметрах кривых) могут быть взяты из проекта новой линии или проекта реконструкции, подробного продольного профиля, паспорта дистанции пути и т.д.
Управляющими данными являются:
Указание начальника службы пути дороги или Департамента пути и сооружений ОАО «РЖД» на расчет;
Приказ № 41, содержащий нормативно-справочную информацию, порядок и формулы определения допускаемых скоростей;
Сведения о текущем или планируемом поездопотоке (данные о марках обращающихся локомотивов и типах используемых вагонов);
Сведения о планируемых ремонтах пути, реконструкции и переустройстве сооружений и устройств.
Результатом работы системы должны быть:
Ведомости допускаемых скоростей, содержащие все типы рассчитанных скоростей и позволяющие установить причину их ограничения;
Ведомости Приказа начальника дороги об установлении допускаемых скоростей на перегонах и раздельных пунктах (Приказ «Н») согласно принятой на дороге форме. Утвержденный Приказ «Н» официально закрепляет допускаемые скорости движения поездов;
Типовые формы № 1, 1а и 2, содержащие планируемые допускаемые скорости для разработки графика движения поездов.
Скорости, содержащиеся в Приказе «Н» и типовых формах, могут отличаться от рассчитанных и показываемых в ведомостях допускаемых скоростей. Это связано с тем, что в них отражают ограничения скорости не только по конструкции подвижного состава, параметров ВСП и кривых, но и по состоянию устройств и сооружений (деформация земляного полотна, перекос опор контактной сети и т. д.). Кроме того, они корректируются с учетом планируемых ремонтов пути, реконструкции и переустройства сооружений и устройств и т.д.
После построения контекстная диаграмма детализируется с помощью диаграммы декомпозиции первого уровня. На этой диаграмме отображаются функции системы, которые должны быть реализованы в рамках основной функции. Диаграмма, для которой выполнена декомпозиция, по отношению к детализирующим ее диаграммам называется родительской . Диаграмма декомпозиции по отношению к родительской называется дочерней .
Диаграмма декомпозиции первого уровня для рассматриваемой задачи приведена на рис.6.22. Как правило, при построении диаграммы декомпозиции исходная функция (декомпозируемая) разбивается на 3–8 подфункций (блоков). При этом блоки на диаграмме декомпозиции рекомендуется располагать слева направо сверху вниз, чтобы лучше была видна последовательность и логика взаимодействия подфункций.
Рис. 6.22. Диаграмма декомпозиции первого уровня (методология IDEF0)
Очередность выполнения функций для решения рассматриваемой задачи следующая:
Ввод и корректировка нормативно-справочной информации и данных по участкам дороги (блоки 1 и 2);
Подготовка задания на расчет (блок 3). В нем указывается, для какого участка и пути, а также марки локомотива и типа вагонов следует выполнить расчет;
Расчет допускаемых скоростей в соответствии с порядком и формулами, указанными в Приказе № 41 (блок 4). В качестве исходной информации выступают данные по пути участка (план, верхнее строение пути и т. д.) и нормативы, выбираемые на основании задания на расчет;
Формирование ведомостей допускаемых скоростей (блок 5). На базе результатов расчета создаются несколько видов выходных документов, которые, с одной стороны, позволяют выявить причину ограничений скорости, с другой стороны, выступают в качестве основы для подготовки регламентированных документов;
Формирование и подготовка проекта Приказа «Н» и типовых ведомостей (блоки 6 и 7).
После построения диаграммы декомпозиции первого уровня для указанных на ней функций строятся отдельные диаграммы (диаграммы декомпозиции второго уровня). Затем процесс декомпозиции (построения диаграмм) продолжается до тех пор, пока дальнейшая детализация функций не теряет смысла. Для каждой атомарной функции, описывающей элементарную операцию (т. е. функции, не имеющей диаграмму декомпозиции), составляется подробная спецификация, определяющая ее особенности и алгоритм реализации. В качестве дополнения к спецификации могут использоваться блок-схемы алгоритмов. Таким образом, процесс функционального моделирования заключается в постепенном выстраивании иерархии функций.
6.7. ICOM-коды
Стрелки, входящие в блок и выходящие из него на диаграмме верхнего уровня, являются теми же самыми, что и стрелки, входящие в диаграмму нижнего уровня и выходящие из нее, потому что блок и диаграмма представляют одну и ту же часть системы (см. рис. и ). Как следствие этого, границы функции верхнего уровня – это то же самое, что и границы диаграммы декомпозиции.
ICOM-коды (аббревиатура от Input, Control, Output и Mechanism) предназначены для идентификации граничных стрелок. ICOM-код содержит префикс, соответствующий типу стрелки (I, С, О или М), и порядковый номер (см. рис.).