Idef0 Аэропорт Сочинения и курсовые работы. Описание учета реализации автомобилей Требования к функциональным характеристикам

Цель работы:

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

Описание системы с помощью IDEF0 называется функциональной моделью. Функциональная модель предназначена для описания существу­ющих бизнес-процессов, в котором используются как естественный, так и графический языки. Для передачи информации о конкретной системе источником графического языка является сама методология IDEF0.

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

Каждая IDEF0-диаграмм а содержит блоки и дуги. Блоки изображают функции моделируемой системы. Дуги связывают блоки вместе и отобра­жают взаимодействия и взаимосвязи между ними.

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

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

Каждая сторона блока имеет особое, вполне определенное назначение. Левая сторона блока предназначена для входов, верхняя - для управления, правая - для выходов, нижняя - для механизмов. Такое обозначение отражает определенные системные принципы: входы преобразуются в выходы управление ограничивает или предписывает условия выполнения преобразований, механизмы показывают, что и как выполняет функция.

Блоки в IDEF0 размещаются по степени важности, как ее понимает автор диаграммы. Этот относительный порядок называется доминированием. Доминирование понимается как влияние, которое один блок оказывает на другие блоки диаграммы. Например, самым доминирующим блоком диаграммы может быть либо первый из требуемой последовательности функций, либо планирующая или контролирующая функция, влияющая на все другие.

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

Расположение блоков на странице отражает авторское определение доминирования. Таким образом, топология диаграммы показывает, какие функции оказывают большее влияние на остальные. Чтобы подчеркнуть это, аналитик может перенумеровать блоки в соответствии с порядком их доминирования. Порядок доминирования может обозначаться цифрой, размещенной в правом нижнем углу каждого прямоугольника: 1 будет указывать на наибольшее доминирование, 2 - на следующее и т. д.

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

Типы стрелок

В IDEF0 различают пять типов стрелок.

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

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

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

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

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

Рис. 2.1 Типы стрелок

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

Рис. 2.2. Связь по выходу

Рис. 2.3. Связь по управлению

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

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

Обратная связь по управлению возникает тогда; когда выход некоторого блока влияет на блок с большим доминированием.

Связи «выход-механизм» встречаются нечасто. Они отражают ситуацию, при которой выход одной функции становится средством достижения цели для другой.

Рис. 2.4. Обратная связь по входу

Рис. 2.5. Обратная связь по управлению

Связи «выход-механизм» характерны при распределении источников ресурсов (например, требуемые инструменты, обученный персонал, физическое пространство, оборудование, финансирование, материалы).

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

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

• непомеченные ветви содержат вес объекты, указанные в метке дугиперед разветвлением;
• ветви, помеченные после точки разветвления, содержат все объектыили их часть, указанные в метке дуги перед разветвлением.

Слияния дуг в IDEFO, изображаемое как сходящиеся вместе линии, указывает, что содержимое каждой ветви идет на формирование метки для дуги, являющейся результатом слияния исходных дуг. После слияния результирующая дуга всегда помечается для указания нового набора объектов, возникшего после объединения. Кроме того, каждая ветвь перед слиянием может помечаться или не помечаться в соответствии со следующими правилами:

Рис. 2.6. Связь выход-механизм

• непомеченные ветви содержат вес объекты, указанные в общей меткедуги после слияния;
• помеченные перед слиянием ветви содержат все или некоторые объекты из перечисленных в общей метке после слияния,

Количественный анализ диаграмм

Для проведения количественного анализа диаграмм перечислим показатели модели:

• количество блоков на диаграмме - N;
• уровень декомпозиции диаграммы - L ;
• сбалансированность диаграммы - В;
• число стрелок, соединяющихся с блоком, - А

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

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

Диаграммы должны быть сбалансированы. Это означает, что в рамках одной диаграммы не должно происходить ситуации, изображенной на рис. 2.7: у работы 1 входящих стрелок и стрелок управления значительно больше, чем выходящих. Следует отметить, что данная рекомендация может не выполняться в моделях, описывающих производственные процессы. Например, при описании процедуры сборки в блок может входить множество стрелок, описывающих компоненты изделия, а выходить одна стрелка -- готовое изделие.

Рис. 2.7. Пример несбалансированной диаграммы

Введем коэффициент сбалансированности диаграммы

Необходимо стремиться, чтобы Кь был минимален для диаграммы.

Помимо анализа графических элементов диаграммы необходимо рассматривать наименования блоков. Для оценки имен составляется словарь элементарных (тривиальных) функций моделируемой системы. Фактически в данный словарь должны попасть функции нижнего, уровня декомпозиции диаграмм. Например, для модели БД элементарными могут являться функции «найти запись», «добавить запись в БД», в то время как функция «регистрация пользователя» требует дальнейшего описания.

После формирования словаря и составления пакета диаграмм системы необходимо рассмотреть нижний уровень модели. Если на нем обнаружатся совпадения названий блоков диаграмм и слов из словаря, то это говорит, что достаточный уровень декомпозиции достигнут. Коэффициент, количественно отражающий данный критерий, можно записать как L*C - произведение уровня модели на число совпадений имен блоков со словами из словаря. Чем ниже уровень модели (больше L), тем ценнее совпадения.

Инструментарий BPWin

При запуске BPWin по умолчанию появляется основная панель инструментов, палитра инструментов и Model Explorer.

При создании новой модели возникает диалог, в котором следует указать, будет ли создана модель заново, или она будет открыта из репозитария ModelMart, внести имя модели и выбрать методологию, в которой будет построена модель (рис. 2.8).

Рис.2.8 Диалог создания модели

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

Модель в BPWin рассматривается как совокупность работ, каждая из которых оперирует с некоторым набором данных. Если щелкнуть по любому объекту модели левой кнопкой мыши, появляется всплывающее контекстное меню, каждый пункт которого соответствует редактору какого-либо свойства объекта.

Пример

Построение модели системы должно начинаться с изучения всех документов, описывающих ее функциональные возможности. Одним из таких документов является техническое задание, а именно разделы "Назначение разработки", "Цели и задачи системы" и "Функциональные характеристики системы " .

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

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

Начнем с построения контекстной IDEF0-диаграммы- Согласно описанию системы основной функцией является обслуживание ее клиентов посредством обработки запросов, от них поступающих. Таким образом, определим единственную работу контекстной диаграммы как «Обслужить клиента системы». Далее определим входные и выходные данные, а также механизмы и управление.

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

Контекстная диаграмма

Таким образом, определим контекстную диаграмму системы (рис. 2.9).

Рис 2.9. Контекстная диаграмма системы

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

• Определение уровня доступа в систему.
• Выбор подсистемы.
• Обращение к подсистеме.
• Изменение БД (при необходимости).

Получим диаграмму, изображенную на рис. 2.10.

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

Рис. 2.10. Декомпозиция работы «Обслуживание, клиента системы»

Декомпозируем последовательно все блоки полученной диаграммы. Первым этапом при определении уровня доступа в систему является определение категории пользователя. По имени клиента осуществляется поиск в базе пользователей, определяя его категорию. Согласно определенной категории выясняются полномочия, предоставляемые пользователю системы. Далее проводится процедура доступа в систему, проверяя имя и пароль доступа. Объединяя информацию о полномочиях и уровне доступа в систему, для пользователя формируется набор разрешенных действий. Таким образом, определение уровня доступа в систему будет выглядеть как показано на рис. 2.11.

Рис. 2.11. Декомпозиция работы «Определение уровня доступав систему»

После прохождения процедуры доступа в систему монитор анализирует запрос клиента, выбирая подсистему, которая будет обрабатывать запрос. Декомпозиция работы «Обращение к подсистеме» не отвечает цели и точке зрения модели. Пользователя системы не интересуют внутренние алгоритмы ее работы. В данном случае ему важно, что выбор подсистемы будет произведен автоматически, без его вмешательства, поэтому декомпозиция обращения к подсистеме только усложнит модель.

Декомпозируем работу «Обработка запроса клиента», выполняемую подсистемой обработки запросов, определения категорий и полномочий пользователей. Перед осуществлением поиска ответа на запрос необходимо открыть БД (подключиться к ней). В общем случае БД может находиться на удаленном сервере, поэтому может потребоваться установление соединения с ней. Определим последовательность работ:

• Открытие БД.
• Выполнение запроса.
• Генерация отчетов.

После открытия БД необходимо сообщить системе об установлении соединения с БД, после чего выполнить запрос и сгенерировать отчеты для пользователя (рис. 2.12).

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

Рис. 2.12.

Корректировка диаграммы

При анализе полученной диаграммы возникает вопрос, по каким правилам происходит генерация отчетов? Необходимо наличие заранее сформированных шаблонов, по которым будет производиться выборка из БД, причем эти шаблоны должны соответствовать запросам и должны быть заранее определены. Кроме того, клиенту должна быть предоставлена возможность выбора формы отчета.

Скорректируем диаграмму, добавив в нее стрелки «Шаблоны отчетов» и «Запросы на изменение БД» и туннельную стрелку «Клиент системы». Туннелирование «Клиента системы» применено для того, чтобы не выносить стрелку на диаграмму верхнего, так как функция выбора формы отчета не является достаточно важной для отображения ее на родительской диаграмме.

Изменение диаграммы потянет за собой корректировку всех родительских диаграмм (рис. 2.13 - 2.15).

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

Рис. 2.13. Декомпозиция работы «Обработка запроса клиента»

Рис. 2.14. Декомпозиция работы «Обслуживание клиента системы»(вариант 2)

Рис. 2.15. Контекстная диаграмма системы (вариант 2)

Перейдем к декомпозиции последнего блока «Изменение БД». С точки зрения клиента, данные системы располагаются в одной БД. Реально в системе присутствует шесть БД:

• БД пользователей,
• БД студентов,(вариант 2)
• БД вакансий,
• БД успеваемости,
• БД тестов,
• БД экспертных оценок,
• БД резюме.

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

• Определяется БД, в которой будет изменяться информация.
• Оператором формируется временный набор данных и предоставляется администратору.
• Администратор осуществляет контроль данных и вносит их в БД.

Данную модель реализовать другим способом, предоставив возможность обновления БД непосредственно по запросам, минуя процесс контроля данных. В этом случае необходимо обеспечить контроль целостности БД для избежания ее повреждения. В этом случае диаграмма будет выглядеть следующим образом (рис. 2.17).

Рис. 2.16. Декомпозиция работы «Изменение БД»

Рис. 2.17. Декомпозиция работы «Изменение БД» (вариант 2) Для первого варианта, изображенного нарис. 2.12

Проведение дальнейшей декомпозиции «Изменения БД» будет усложнять модель, объясняя, как осуществляется физическое изменение БД в системе. При этом пользователь не получит никакой дополнительной информации о работе системы службы занятости. Декомпозицию этой работы целесообразно проводить в процессе проектирования БД системы на этапе создания логической модели БД.

Декомпозиция работы «Выполнение запроса» будет проведена в следующей лабораторной работе, иллюстрируя применение диаграмм DFD для описания процессов обработки информации.

Проведем количественный анализ моделей, изображенных на рис. 2.12 и 2.13, согласно вышеописанной методике. Рассмотрим поведение коэффициента ^ у этих моделей. У родительской диаграммы «Обработка запроса клиента» коэффициент равен 4/2 = 2, а диаграммы декомпозиции 3/3 = 1. Значение коэффициента убывает, что говорит об упрощении описания функций с понижением уровня модели.

Рассмотрим изменение коэффициента К b у двух вариантов моделей.

для второго варианта

Коэффициент К b не меняет своего значения, следовательно, сбалансированность диаграммы не меняется.

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

Подводя итоги рассмотренного примера необходимо отметить важность рассмотрения нескольких вариантов диаграмм при моделировании системы. Такие варианты могут возникать при корректировке диаграмм, как это было сделано с «Обработкой запроса клиента» или при создании альтернативных реализаций функций системы (декомпозиция работы «Изменение БД»). Рассмотрение вариантов позволяет выбрать наилучший и включить его в пакет диаграмм для дальнейшего рассмотрения.

Контрольные вопросы

Список Контрольных вопросов :

1. Что представляет собой модель в нотации IDEF0?
2. Что обозначают работы в IDEF0?
3. Назовите порядок наименования работ?
4. Какое количество работ должно присутствовать на одной диаграмме?
5. Что называется порядком доминирования?
6. Как располагаются работы по принципу доминирования?
7. Каково назначение сторон прямоугольников работ на диаграммах?
8. Перечислите типы стрелок.
9. Назовите виды взаимосвязей.
10. Что называется граничными стрелками?
11. Объясните принцип именования разветвляющихся и сливающихся стрелок.
12. Какие методологии поддерживаются BPWin?
13. Перечислите основные элементы главного окна BPWin.
14. Опишите процесс создания новой модели в BPWin.
15. Как провести связь между работами?
16. Как задать имя работы.
17. Опишите процесс декомпозиции работы.
18. Как добавить работу на диаграмму?
19. Как разрешить туннелированные стрелки?
20. Может ли модель BPWin содержать диаграммы нескольких методологий?

1. Отчет о проведении научно-исследовательской работы «разработка методических рекомендаций по описанию и оптимизации процессов в органах исполнительной власти в рамках подготовки внедрения эар»

   Отчет

   ЭЛЕКТРОННЫЙ АДМИНИСТРАТИВНЫЙ РЕГЛАМЕНТ, АДМИНИСТРАТИВНЫЙ РЕГЛАМЕНТ, ДОЛЖНОСТНОЙ РЕГЛАМЕНТ, АДМИНИСТРАТИВНО-УПРАВЛЕНЧЕСКИЙ ПРОЦЕСС, ОПИСАНИЕ АДМИНИСТРАТИВНО-УПРАВЛЕНЧЕСКИХ ПРОЦЕССОВ,

2. управление процессами

   Документ

   Позняковский Валерий Михайлович – директор НИИ биотехнологии и сертификации, зав. кафедры биотехнологии, товароведения и управления качеством Кемеровского технологического института пищевой промышленности,

3. Технологии защиты информации в сети Курс лекций Введение В данном курсе изложены теоретические основы криптографии и вопросы сетевой безопасности Предназначено для чтения курса «Технологии защиты информации в сети» Содержание

   Обзор

4. Информационные технологии в профессиональной деятельности

   Учебно-методический комплекс

   Учебно-методический комплекс по учебной дисциплине «Информационные технологии в профессиональной деятельности» для специальности 030503.52 – «Правоведение» среднего профессионального образования.

5. Учебно-методический комплекс по дисциплине «информационные технологии в бизнес-планировании»

   Учебно-методический комплекс

6. Лабораторная работа № 2. Разработка моделей IDEF0

   Порядок выполнения лабораторной работы:

   1. Изучите теоретические сведения.

   2. Выполните следующие задания:

   · Создание контекстной диаграммы.

   · Создание диаграммы узлов.

   · Создание FEO диаграммы.

   · Расщепление и слияние моделей.

   3. Выполните структурный анализ задачи, определенной в ТЗ (первая лабораторная работа).

   4. Выполненный анализ задачи оформите в виде диаграмм IDEF0 (программные продукты MS Visio, BPwin).

   Теоретическая часть

   Методология функционального моделирования IDEF 0

   Лекционный материал

   Общая постановка задачи

   Выполните структурный анализ задачи (первая лабораторная работа) и оформите результат данного анализа в виде диаграмм IDEF0.

   Список индивидуальных данных

   Продолжается работа над задачей, выбранной в первой лабораторной работе.

   Пример выполнения работы

   Как было определено в ТЗ, входной информацией системы является:

   · бухгалтерская информация;

   · информация о нажатой кнопке RTE;

   · регистрационная информация;

   · информация о считанном идентификаторе.

   Выходной информацией системы является:

   · управляющие воздействия на исполнительный механизм;

   · отчеты.

   Контекстная диаграмм (диаграмма А-0) разрабатываемой системы управления платной автостоянкой приведена на рис. 1.

   Рис. 1. IDEF0-диаграмма А-0 - контекстная диаграмма системы управления платной автостоянкой

   Детализация контекстной диаграммы А-0 представлена на рис. 2 (диаграмма А0). На данной диаграмме выделены три функциональных блока «Регистрация клиентов и корректировка информации о клиентах», «Пропуск клиента» и «Формирование отчетов».

   
   

   

   Рис. 2. IDEF0-диаграмма А0 – детализация контекстной диаграммы

   Клиентами в данном случае являются арендаторы машиномест автостоянки. При регистрации клиентов вводится ФИО клиента, уникальный идентификатор клиента, срок действия идентификатора. В качестве идентификатора клиента могут выступать магнитные карты, пропуска со штрих-кодом, радио-брелки. Срок действия идентификатора определяется исходя из бухгалтерской информации (оплата машиноместа, договор).

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

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

   Детализация блока «Регистрация клиентов и корректировка информации о клиентах» представлена на рис. 3. Как видно из диаграммы, перед регистрацией клиента и изменением информации о клиенте осуществляется проверка соответствующих прав сотрудника автостоянки (права администратора). Права определяются на основании введенного пароля.

   Владелец" href="/text/category/vladeletc/" rel="bookmark">владельце идентификатора не осуществляется. Информация о нажатии данной кнопки сразу поступает на блок формирования управляющих воздействий.

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

   

   Рис. 4. IDEF0-диаграмма А2 – детализация блока «Пропуск клиента» диаграммы А0

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

   Детализация блока «Формирование отчетов» диаграммы А0 представлена на рис. 5. (диаграмма А3). Вначале необходимо выбрать тип отчета. Затем формируется соответствующий отчет. Все отчеты в системе можно разделить на два типа:

   1. Отчеты, для формирования которых используется только информация о клиенте.

   2. Отчеты, для формирования которых нужна информация о выполненных действиях.

   

   Рис. 5. IDEF0-диаграмма А3 – детализация блока «Формирование отчетов» диаграммы А0

   
   

   К первому типу относятся следующие отчеты:

   · список клиентов;

   · задолжености клиентов.

   Ко второму типу относятся следующие отчеты:

   · активность использования машиномест;

   · список занятых и свободных машиномест;

   · список событий.

   Детализация блока «Выполнить изменение информации о клиенте» диаграммы А1 представлена на рис. 6 (диаграмма А14). Требования внесения информации о клиенте могут быть вызваны следующими причинами:

   · не произведена оплата аренды машиноместа;

   · не произведена оплата пропуска;

   · требуются изменения в договоре;

   · требуется замена пропуска (идентификатора).

   

   Рис. 6. IDEF0-диаграмма А14 – детализация блока «Выполнить изменение информации о клиенте» диаграммы А1

   Детализация блока «Изменение договора» диаграммы 14 представлена на рис. 7 (диаграмма А142). Если требуется изменение договора, то выписывается новый договор, который отдается клиенту. После подписания договора клиентом и руководством автостоянки, информации о договоре вносится в бухгалтерскую программу и в разрабатываемую систему.

   

   Рис. 7. IDEF0-диаграмма А142 – детализация блока «Изменение договора» диаграммы А14

   Детализация блока «Оплата» диаграммы А14 представлена на рис. 8 (диаграмма А143). Если требуется произвести оплату аренды машиномест или изготовления нового пропуска, то выписываются документы, на основании которых будет производиться оплата. С этими документами клиент отправляется в бухгалтерию и производит оплату. Информация об оплате фиксируется в бухгалтерской программе и передается в разрабатываемую систему.

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

   

   Рис. 8. IDEF0-диаграмма А143 – детализация блока «Оплата» диаграммы А14

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

   Контрольные вопросы:

   1. В чем суть методологии IDEF0 ?

   2. Синтаксис и семантика функциональных блоков диаграммах IDEF0 ?

   3. Синтаксис и семантика стрелок в диаграммах IDEF0:

   · стрелки входа;

   · стрелки управления;

   · стрелки выхода;

   · стрелки механизма исполнения;

   · комбинированные стрелки;

   · разбиение и соединение стрелок;

   · туннели.

   4. Основы методики построения моделей IDEF0.

   5. Основные возможности программного продукта MS Visio.

   6. Построение диаграмм IDEF0 с помощью программного продукта MS Visio.

   7. Основные возможности программного продукта BPwin.

   8. Построение диаграмм IDEF0 с помощью программного продукта BPwin.

   IDEF0 диаграммы строятся с помощью программы BPWin. Предназначены они для графического моделирования происходящих бизнес-процессов

   О методологии IDEF0

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

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

   

   Элементы, используемые для IDEF0

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

   
   

   Возможности использования IDEF0

   Методологию IDEF0 можно применять для описи функционального аспекта любой информационной системы.

   
   

   Типы связей между процессами IDEF0

   В интересах модели создавать такие связи построений, чтобы внутренние связи были как можно сильней, а внешние - как можно слабей. Это сильная сторона моделирования с помощью IDEF0. Примеры диаграмм вы можете увидеть сами и убедиться в правдивости этих слов. Для облегчения установления связей подобные соединяются в модули. Между модулями устанавливаются внешние связи, а внутри модулей - внутренние. Различают несколько типов связей.

   1. Иерархическая («часть» - «целое») связь.

   2. Управляющая (регламентирующая, подчинённая):

   2) обратная связь управления.

   3. Функциональная или технологическая:

   2) обратная входная.

   3) потребительская;

   4) логическая;

   5) методическая или коллегиальная;

   6) ресурсная;

   7) информационная;

   8) временная;

   9) случайная.

   Построение блоков и связей в диаграммах

   Методология IDEF0 предоставляет целый ряд правил и рекомендаций по своему использованию и улучшению качества использования. Так, в диаграмме отображается один блок, на котором можно задать название системы, её назначение. К блоку или от блока ведёт 2-5 стрелок. Можно больше или меньше, но как минимум две стрелки необходимы для входа/выхода, а остальные для дополнительных работ и их указания на диаграмме. Если стрелок больше 5, следует задуматься об оптимальности построения модели, и нельзя ли сделать её ещё более детализированной.

   

   Построение блоков в диаграммах декомпозиции

   Количество блоков, которое будет на одной диаграмме, рекомендовано в численности 3-6. Если их меньше, то такие диаграммы вряд ли будут нести смысловую нагрузку. Если количество блоков будет огромным, то прочитать такую диаграмму будет весьма сложно, учитывая наличие ещё и дополнительных стрелок. Для улучшения восприятия информации размещать блоки рекомендуется сверху вниз и слева направо. Такое расположение позволит отразить логику исполнения последовательности процессов. А также стрелки будут создавать меньшую путаницу, обладая минимальным количеством пересечений друг с другом.

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

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

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

   Именование

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

   Часто используется слияние стрелок, и встают вопросы об их именовании. Но слияние возможно только в случае передачи однородных данных, поэтому отдельные имена не нужны, хотя в программе BPWin их можно задать. Также, если происходит расхождение стрелок, то их можно отдельно наименовать, чтобы понимать, что за что отвечает.

   Если после ветвления нет наименования, то считается, что имя точно такое, как было до ветвления. Так может быть, если два блока требуют одинаковую информацию. Контекстная диаграмма IDEF0, пример которой можно найти в данной статье, подтвердит эти слова.

   

   Информация о стрелках

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

   Пример реализации методологии IDEF0 на конкретной модели

   Вы уже узнали, что такое IDEF0 диаграмма, примеры и правила построения таких диаграмм частично увидели. Теперь следует обратиться и к практике. Для лучшего понимания объяснение будет идти не на какой-то «общей» модели, а на конкретном примере, который позволит лучше и полнее понять особенности работы с IDEF0 в программе BPWin.

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

   

   Исходной информацией выступают:

   1. данные про линию путей;
   2. паспорт всей дистанции;
   3. план пути.

   Управляющие данные:

   1. Указание начальника, заведующего службой путей.
   2. Сведения о существующем потоке передвижения составов.
   3. Сведения о запланированных ремонтах, реконструкциях и изменении путей.

   Результатом модели является:

   1. Ограничение допустимых скоростей с указанием причины ограничения.
   2. Допустимые скорости при движении на раздельных пунктах и во время перегона составов.

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

   Заключение

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