Программа компьютерного моделирования BPwin (AllFusion Process Modeler). IDEF0. Знакомство с нотацией и пример использования Каким образом строится схема idef0

Министерство образования и науки РФ

Федеральное агентство по образованию

Государственное образовательное учреждение высшего профессионального образования

Курсовая работа

«Моделирование систем»

«Разработка модели предприятия тепличного хозяйства, используя методологии проектирования IDEF0, DFD и IDEF3»

1. Цель работы

2. Теоретическое введение

3. Описание предметной области

4. Описание BPwin

4.1 Принцип построения модели IDEF0

4.2 Принцип построения модели DFD

4.3 Принцип построения модели IDEF3

5. Моделирование

5.1 Модель тепличного хозяйства

5.2 Математическая модель

6. Сравнительный анализ

6.1 Методологии

6.2 Сравнение инструментальных средств

Литература

1. Цель работы

Целями данной курсовой работы были:

применение методов предпроектного обследования предприятия;

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

разработка модели процесса в стандарте IDEF0;

описание документооборота и обработки информации в стандарте DFD;

описания процессов в стандарте IDEF3;

разработка смешанной модели описания процесса на основе стандартов IDEFO, DFD и IDEF3.

создание сценариев работы предприятия;

построение структурной схемы предприятия;

создание математической модели данного предприятия.

сравнительный анализ

2. Теоретическое введение

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

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

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

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

Основными целями моделирования при разработке проектов являются:

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

формирование на основании анализа предложений по реорганизации организационно-управленческой структуры;

упорядочивание информационных потоков (в том числе документооборота) внутри предприятия;

анализ требований и проектирование спецификаций корпоративных информационных систем.

3. Описание предметной области

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

Организация работы осуществляется по следующей схеме:

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

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

Служба охраны труда, основная функция которого подготовка персонала;

Бухгалтерский отдел занимается документооборотом;

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

Сектор технического обслуживания, занимается ремонтными работами.

Отделы, службы и рабочие места данного предприятия представлены в таблице №1:

таблица №1

Задачи и функции нашего тепличного хозяйства показаны в таблице №2:

Таблица №2

Документация представлена в таблицах №3:

таблица №3

Справочник организаций представлен в таблице №4:

таблица №4

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

Схема сценария работы предприятия

4. Описание BPwin

BPwin относится к малым интегрированным средствам моделирования, которые поддерживают несколько типов моделей и методов.

Для проведения анализа и реорганизации бизнес-процессов Logic Works предлагает CASE-средство верхнего уровня - BPwin, поддерживающее методологии IDEF0 (функциональная модель), IDEF3 (WorkFlow Diagram) и DFD (DataFlow Diagram). Основной из трех методологий, является IDEF0. BPwin имеет достаточно простой и интуитивно понятный интерфейс пользователя, дающий возможность аналитику создавать сложные модели при минимальных усилиях.

BPwin автоматизирует задачи, связанные с построением моделей развития, обеспечивая семантическую строгость, необходимую для гарантирования правильности и непротиворечивости результатов. Это достигается применением в BPwin следующих методологий: IDEF0, DFD и IDEF3.

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

В BPwin возможно построение смешанных моделей, т. е. модель может содержать одновременно как диаграммы IDEFO, так и IDEF3 и DFD. Модель в BPwin рассматривается как совокупность работ, каждая из которых оперирует с некоторым набором данных. Работа изображается в виде прямоугольников, данные – в виде стрелок.

Все работы модели нумеруются. Номер состоит из префикса и числа. Может быть использован префикс любой длины, но обычно используют префикс А. Контекстная (корневая) работа дерева имеет номер А0. Работа декомпозиции А0 имеет номера Al, A2, A3 и т.д. Работы декомпозиции нижнего уровня имеют номер родительской работы и очередной порядковый номер, например работы декомпозиции A3 будут иметь номера А3.1 А3.2, АЗ.З, А3.4 и т. д.

В результате дополнения диаграмм, IDEFO диаграммами DFD и IDEF3 может быть создана смешанная модель, которая наилучшим образом описывает все стороны деятельности предприятия. Иерархию работ смешанной модели можно увидеть в окне Model Explorer. Работы в нотации IDEFO изображаются зеленым цветом, DFD – синим.

BPwin так же как и локальные интегрированные системы, практически не позволяют выполнить комплексный анализ систем, который в большей или меньшей степени необходим для создания малых, средних и крупных ИСУП. С их помощью можно разрабатывать локальные ИС или небольшие подсистемы, предназначенные для автоматизации отдельных бизнес-цепочек, т. е. когда нет необходимости в комплексном анализе предприятия. Типичная сфера использования малых интегрированных средств - решение задач так называемой “кусочной” автоматизации предприятия.

4.1 Принцип построения модели IDEFO

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

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

Модель может содержать четыре типа диаграмм:

контекстную диаграмму (в каждой модели может быть только одна контекстная диаграмма);

диаграммы декомпозиции;

диаграммы дерева узлов;

диаграммы только для экспозиции (FEO).

Контекстная диаграмма является вершиной древовидной структуры диаграмм и представляет собой самое общее описание системы и ее взаимодействия с внешней средой.

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

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

верхняя сторона имеет значение "управления";

левая - "входа";

правая - "выхода";

нижняя - "механизма".

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

Изобразительным элементом, представляющим "поток", является стрелка.

Управление - это что управляет деятельностью бюро, в данной разрабатываемой модели - это законы об индивидуальном ПУ.

Стрелки "входа" вносят функции входных данных, в контекстной диаграмме – это персональные данные работника.

Стрелки "выхода" – выходные данные. В контекстной диаграмме – это различные сведения, которые подаются в Пенсионный фонд РФ.

Стрелка "механизма" - это влияющие на процессы данные. В диаграмме – это персонал и ПК.

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

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

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

Все перекрестки на диаграмме нумеруются, каждый номер имеет префикс J. Можно редактировать свойства перекрестка при помощи диалога Definition Editor.

4.2 Принцип построения модели DFD

Диаграммы потоков данных (DFD) являются основным средством моделирования функциональных требований проектируемой системы. С их помощью эти требования разбиваются на функциональные компоненты (процессы) и представляются в виде сети, связанной потоками данных. Главная цель таких средств - продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами.

Для изображения DFD традиционно используются две различные нотации: Йодана (Yourdon) и Гейна-Сарсона (Gane-Sarson). Далее при построении примеров будет использоваться нотация Йодана, все исключения будут предварительно оговариваться.

В основе данной методологии (методологии Gane/Sarson) лежит построение модели анализируемой ИС - проектируемой или реально существующей. В соответствии с методологией модель системы определяется как иерархия диаграмм потоков данных (ДПД или DFD), описывающих асинхронный процесс преобразования информации от ее ввода в систему до выдачи пользователю. Диаграммы верхних уровней иерархии (контекстные диаграммы) определяют основные процессы или подсистемы ИС с внешними входами и выходами. Они детализируются при помощи диаграмм нижнего уровня. Такая декомпозиция продолжается, создавая многоуровневую иерархию диаграмм, до тех пор, пока не будет достигнут такой уровень декомпозиции, на котором процесс становятся элементарными и детализировать их далее невозможно.

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

внешние сущности;

системы/подсистемы;

процессы;

накопители данных;

потоки данных.

4.3 Принцип построения модели IDEF3

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

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

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

Перекрестки (Junction). Окончание одной работы может служить сигналом к началу нескольких работ или же одна работа для своего запуска может ожидать окончания нескольких работ. Перекрестки используются для отображения логики взаимодействия стрелок при слиянии и разветвлении или для отображения множества событий, которые могут или должны быть завершены перед началом следующей работы. Типы перекрёстков представлены в табл.:

Типы перекрестков

Обозначение	Наименование	Смысл в случае слияния стрелок (Fan-in Junction)	Смысл в случае разветвления стрелок (Fan-out Junction)
\|\|&	Asynchronous AND	Все предшествующие процессы должны быть завершены	Все следующие процессы должны быть запущены
\|\|&\|\|	Synchronous AND	Все предшествующие процессы завершены одновременно	Все следующие процессы запускаются одновременно
\|\|O	Asynchronous OR	Один или несколько предшествующих процессов должны быть завершены	Один или несколько следующих процессов должны быть запущены
\|\|O\|\|	Synchronous OR	Один или несколько предшествующих процессов завершены одновременно	Один или несколько следующих процессов запускаются одновременно
\|\|X		Только один предшествующий процесс завершен	Только один следующий процесс запускается

Все перекрестки на диаграмме нумеруются, каждый номер имеет префикс J. Можно редактировать свойства перекрестка при помощи диалога Definition Editor. В отличие от IDEFO и DFD в IDEF3 стрелки могут сливаться и разветвляться только через перекрестки.

Объект ссылки. Объект ссылки в IDEF3 выражает некую идею, концепцию или данные, которые нельзя связать со стрелкой, перекрестком или работой. Для внесения объекта ссылки служит кнопка |R| – (добавить в диаграмму объект ссылки - Referent) в палитре инструментов. Объект ссылки изображается в виде прямоугольника, похожего на прямоугольник работы. Имя объекта ссылки задается в диалоге Referent (пункт всплывающего меню Name Editor), в качестве имени можно использовать имя какой-либо стрелки с других диаграмм или имя сущности из модели данных. Объекты ссылки должны быть связаны с единицами работ или перекрестками пунктирными линиями. Официальная спецификация IDEF3 различает три стиля объектов ссылок – безусловные (unconditional), синхронные (synchronous) и асинхронные (asynchronous). BPwin поддерживает только безусловные объекты ссылок. Синхронные и асинхронные объекты ссылок, используемые в диаграммах переходов состояний объектов, не поддерживаются.

5. Моделирование

5.1 Модель тепличного хозяйства

Навигатор модели – Model Explorer

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

Диаграмма декомпозиции А0:

Диаграмма декомпозиции А1:

Диаграмма IDEF3 A11.1:

Диаграмма потоков данных А12:

Диаграмма декомпозиции А2:

Диаграмма IDEF3 A21.1:

Диаграмма декомпозиции А3:

Диаграмма декомпозиции А4:

Диаграмма декомпозиции А5:

Диаграмма декомпозиции А6:

Диаграмма потоков данных А63:

5.2 Математическая модель

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

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

e - себестоимость единицы товара, определяется производителем, в нее входят все издержки связанные с производством единицы товара, основную часть этой цифры составляет цена закупки семян;

v - цена закупки семян, это цена по которой предприятие закупило семена у поставщика (раздел «закупка семян»);

а - расход на труд (заработная плата и прочие расходы внутри предприятия);

g – ГСМ (горюче-смазочные материалы);

n – налоги (потребительская часть) устанавливаются государством и имеют фиксированную ставку;

k – НДС, налог на добавочную стоимость, так же имеет фиксированную ставку;

r – розничная цена, это сумма денег за которую производитель продает единицу своего товара на рынка, как правило розничная цена определяется себестоимостью с определенным процентом наценки;

s – наценка предприятия на единицу товара, как правило её количество определяет каждый предприниматель индивидуально, в данном случае она составляет 40% от себестоимости, т. е. (e*40)/100

о – оптовая цена, это сума денег предлагаемой за единицу товара, при покупке от 100 единиц, в этом случае действует скидка 10% от розничной цены;

os – скидка при оптовой покупке (os

Математическая модель расчета себестоимости за единицу произведенного товара:

Математическая модель расчета розничной цены за единицу произведенного товара:

Математическая модель расчета оптовой цены за единицу произведенного товара:

o= v+a+g+n+k+s - os

o=r - (r*10)/100

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

6. Сравнительный анализ

Для моделирования нашего предприятия нами было использовано 5 методологий: Дракон, UML, IDEF0, IDEF3, DFD. На наш взгляд наилучшим вариантом представления модели нашего предприятия является методология UML, так как она более наглядно и точно отображает основные аспекты работы тепличного хозяйства.

Диаграммы UML сравнительно просты для чтения.

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

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

Visio - наиболее простое и доступное средство моделирования процессов. Этот продукт имеет стандартные, привычные всем панели управлении в стиле MS Office и легко интегрируется с любыми приложениями этого пакета, что упрощает работу с ним для неопытных пользователей. Однако для временного или стоимостного анализа требуется разработка отчетов, что значительно усложняет использование этого продукта. Типовые отчеты явно не достаточны для анализа бизнес-процессов. Несмотря на это, Visio является распространенным средством для описания бизнес-процессов как в России, так и за рубежом. Visio поддерживает IDEF и UML форматы для описания бизнес-процессов. Возможна также самостоятельная разработка форматов.

BPWIN - занимает промежуточное место, отличаясь достаточной простотой и большими возможностями анализа. Функциональность BPWIN заключается не только в рисовании диаграмм, но и в проверке целостности и согласованности модели. BPWIN обеспечивает логическую четкость в определении и описании элементов диаграмм, а также проверку целостности связей между диаграммами. Инструмент обеспечивает коррекцию наиболее часто встречающихся ошибок при моделировании. Кроме того, BPWIN поддерживает пользовательские свойства, которые применяются к элементам диаграммы для описания специфических свойств, присущих данному элементу. Основным ограничением этой системы является положенный в ее основу стандарт IDEF, в котором существуют жесткие ограничения при построении моделей. Это упрощает задачу при описании простых процедур, но усложняет описание больших процессов. Схемы 1DEF при описании сложных процессов начинают представлять бесчисленное множество взаимосвязанных схем, внешне очень похожих, что затрудняет понимание процесса в целом.

7. Вывод:

В ходе выполнения данной курсовой работы были достигнуты все поставленные нами цели.

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

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

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

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

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

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

Литература:

Рогозов Ю.И., Стукотий Л.Н., Свиридов А.С. «Моделирование систем» ТРТУ, 2004.

С.В. Маклаков «CASE-средства разработки информационных систем. BPwin и Erwin» –М.: ДиалогМифи, 2001.

Маклаков С. «Объединение структурного и объектного подхода в новом поколении CASE-средств Computer Associates» // Учебно-консалтинговый центр. 2002.

Цель работы:

изучение основных принципов методологии 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 не меняет своего значения, следовательно, сбалансированность диаграммы не меняется.

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

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

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

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

Что представляет собой модель в нотации IDEF0?
Что обозначают работы в IDEF0?
Назовите порядок наименования работ?
Какое количество работ должно присутствовать на одной диаграмме?
Что называется порядком доминирования?
Как располагаются работы по принципу доминирования?
Каково назначение сторон прямоугольников работ на диаграммах?
Перечислите типы стрелок.
Назовите виды взаимосвязей.
Что называется граничными стрелками?
Объясните принцип именования разветвляющихся и сливающихся стрелок.
Какие методологии поддерживаются BPWin?
Перечислите основные элементы главного окна BPWin.
Опишите процесс создания новой модели в BPWin.
Как провести связь между работами?
Как задать имя работы.
Опишите процесс декомпозиции работы.
Как добавить работу на диаграмму?
Как разрешить туннелированные стрелки?
Может ли модель BPWin содержать диаграммы нескольких методологий?

Описание Диаграмм бизнес процесса «Учет компьютерной техники предприятия»

Описание IDEF0 диаграммы

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

1. Контекстная

2. Функциональная декомпозиция

Рисунок 1 - Контекстная диаграмма «Учет компьютерной техники предприятия»

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

На контекстной диаграмме обозначены стрелки.

Виды стрелок:

· вход (входные материалы: компьютеры и комплектующие)

· выход (выходом является отчет)

· стрелками управления являются документы и руководители

· стрелками механизмов являются сотрудники и оборудование

Входная информация для обработки:

Компьютеры - ПК (персональные компьютеры) находящиеся на предприятии

Комплектующие - материалы, необходимые для модернизации компьютеров (видеокарты, материнские платы, процессоры, корпуса, блоки питания, модули памяти)

Выходные потоки:

Отчет - готовый отчет по учету компьютерной техники предприятия

Входные управления:

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

Приказы - поставленная задача предприятию (провести учет компьютерной техники на предприятии с помощью тех или иных информационных систем)

Руководители - директора и главные управляющие предприятием.

Входные ресурсы:

ПК - компьютеры, с помощью которых ведется учёт.

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

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

Рисунок 2 - Функциональная декомпозиция «Учет компьютерной техники предприятия»

Были выделены следующие виды работ:

1) Оформление поставок - процесс, в котором происходит присвоение id товару, отправка на хранение, на склад и занесение информации о товаре в программу.

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

Стрелка связь по входу между работами Оформление поставок и Обслуживание компьютера (компьютер);

Стрелки входа, выхода, управления повторяются в последующих работах.

2) Обслуживание компьютера - процесс, в котором происходит сборка, ремонт и модернизация компьютеров.

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

Стрелка управление - правила, приказы, руководитель;

Стрелка связь по входу между работами Обслуживание компьютера и Расстановка (занесение данных в базу), между работами Обслуживание компьютера и Составление отчета (занесение данных в базу);

3) Расстановка - процесс, в котором происходит расстановка компьютеров по офисам (кабинетам).

Стрелки управление - правила, приказы, руководитель;

Стрелка механизма - сотрудники;

Стрелка связь по входу между Расстановка и Составление отчета (присвоение id);

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

Затем каждая подсистема разбивается на более мелкие декомпозиции и так далее, до достижения нужной степени подробности.

На рисунке 3 представлена диаграмма, показывающая работу Оформления поставок более подробно.

В результате детализации были выделены основные функции. В раздел «Оформление поставок» входит семь главных стрелок (вход, выход, управление, механизм).

Стрелка входа - компьютеры и комплектующие;

Стрелками управления являются правила, приказы и руководитель. Стрелки разветвляющие;

Стрелки механизма, разветвляющие - ПК, сотрудники;

Стрелки входа, управления, механизмы повторяются во всех работах.

1) Присвоение номера - присвоение индивидуального номера компьютерам и комплектующим.

Стрелки входа - компьютеры и комплектующие. Стрелка компьютеры повторяется в последующих работах, кроме составления отчета;

Стрелки управления - правила, приказы и руководитель;

Стрелки механизма - ПК и Сотрудники;

Стрелка связь по входу между работами Присвоение номера и Отправка товара на склад (перемещение), между «Присвоение номера» и «Постановка на баланс» (внесение в базу);

2) Отправка товара на склад - оправка товара с присвоенным номером на склад.

Стрелка выхода - компьютер;

Стрелки управления - правила, приказы и руководитель.

Стрелка связь по входу между работами «Отправка товара на склад» и «Постановка на баланс» (количество);

3) Постановка на баланс - занесение информации в компьютер.

Стрелки управления - правила, приказы и руководитель;

Стрелки механизма - ПК и Сотрудники;

На рисунке 4 представлена диаграмма, детализирующая обслуживание компьютера более подробно.

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

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

1) Сборка компьютеров - конфигурация компьютеров по индивидуальному заказу руководителей.

Стрелка входа - компьютеры;

Стрелки управления - правила, приказы и руководитель;

Стрелки механизма - Сотрудники;

Стрелка связь по входу между работами: «Сборка компьютеров» и «Ремонт компьютеров» (компьютер);

2) Ремонт компьютеров - сборка утвержденных к улучшению компьютеров.

Стрелка входа - компьютеры;

Стрелка выхода - занесение в базу;

Стрелки управления - правила, приказы и руководитель;

Стрелки механизма - Сотрудники;

Стрелки входа, выхода, управления, механизма являются разветвляющимися;

Стрелка связь по входу между работами: «Ремонт компьютеров» и «Upgrade» (комплектующие);

3) Upgrade - усовершенствование, улучшение, обновление компьютера.

Стрелка выхода - занесение в базу;

Стрелки управления - правила, приказы и руководитель;

Стрелки механизма - Сотрудники;

Стрелки управления, механизма являются разветвляющимися;

На рисунке 5 представлена диаграмма «Составление отчета» более подробно. В декомпозицию работы Составление отчета входит 4 граничных стрелки (вход, выход, управление, механизмы). Внутренние стрелки (обратная связь по входу, связь по входу).

В результате работы были выведены следующие функции:

1) Сбор данных - сбор информации для анализа и принятия решений.

Стрелка входа - присвоение id;

Стрелки управления - правила, приказы и руководитель;

Стрелки входа, управления, механизма являются разветвляющимися;

Стрелка связь по входу между работами: Сбор данных и Проверка данных (записи);

2) Проверка данных - проверка информации и отправка ее на составление отчета.

Стрелка входа - присвоение id, занесение данных в базу;

Стрелка выхода - Отчет;

Стрелки управления - правила, приказы и руководитель;

Стрелки механизма - Сотрудники, ПК;

Стрелки входа (присвоение id), управления, механизма являются разветвляющимися;

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

Описание DFD диаграммы

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

Рисунок 1 - Обслуживание компьютера

1) Сборка компьютера - процесс сборки компьютера из существующих комплектующих.

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

3) Диагностика - проверка на работоспособность

4) Upgrade - усовершенствование, улучшение, обновление компьютера.

Внешние сущности: компьютеры и комплектующие

Хранилища данных:

1) Склад - место, где хранятся собранные и модернизированные компьютеры.

2) БД - база данных, в которой хранятся все отчеты и вся информация о проделанных работах.

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

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

В декомпозиции работы «Составление отчета» Рисунок 2 определено три внутренние работы, три внешние сущности и два хранилища данных.

1) Сбор данных - сбор сведений о компьютерах и комплектующих.

2) Проверка - проверка данных на точность.

3) Отчет - написание отчета о проделанной работе.

Внешние сущности: комплектующие, компьютеры, руководитель.

Хранилище данных - Данные о компьютерах и комплектующих, данные отчета.

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

Руководитель проверяет, делает пометки, исправления и отправляет на повторную проверку. После чего отчет отправляется на хранение до повторной проверки руководителя.

Описание IDEF3 диаграммы

В декомпозиции работы Обслуживание компьютера (рис. 1) определено несколько перекрестков, которые соединяют одну или несколько работ, несколько внутренних работ.

1) Ремонт - сборка компьютера сборными комплектующими

2) Сборка - приведение компьютера в нормальный вид

3) Upgrade - модернизация компьютера

4) Компьютеры - товар после сборки и модернизации

5) Отправить на склад - отправить на хранение после улучшения (сборки)

6) Диагностика - проверка на работоспособность.

7) Отчет - информация о проделанной работе.

Перекрестки - соединители:

1) J2 - все действия начинаются одновременно.

2) J6 - Перекресток слияния. Узел, собирающий множество стрелок в одну, указывая на необходимость условия завершенности работ-источников стрелок для продолжения процесса.

3) J7 - показано, что эти условия одновременно выполняться не могут.

4) J9 - эти действия заканчиваются одновременно после чего составляется отчет по проделанной работе.

На диаграмме IDEF3 показано, что перекрёсток J2 имеет две разветвляющие стрелки на работы (сборка и upgrade), которые начинают выполняться одновременно. Только после выполнения этих работ выходит готовый продукт (компьютер), соединяет перекресток J6. После чего идет соединение перекрестком J7, который показывает что две работы (отправка товара на склад и диагностика) одновременно выполняться не могут. После выполнения предыдущих работ идет процесс составление отчета по проведенной работе, который соединен перекрестком J9.

Знаете ли Вы, что такое мысленный эксперимент, gedanken experiment?
Это несуществующая практика, потусторонний опыт, воображение того, чего нет на самом деле. Мысленные эксперименты подобны снам наяву. Они рождают чудовищ. В отличие от физического эксперимента, который является опытной проверкой гипотез, "мысленный эксперимент" фокуснически подменяет экспериментальную проверку желаемыми, не проверенными на практике выводами, манипулируя логикообразными построениями, реально нарушающими саму логику путем использования недоказанных посылок в качестве доказанных, то есть путем подмены. Таким образом, основной задачей заявителей "мысленных экспериментов" является обман слушателя или читателя путем замены настоящего физического эксперимента его "куклой" - фиктивными рассуждениями под честное слово без самой физической проверки.
Заполнение физики воображаемыми, "мысленными экспериментами" привело к возникновению абсурдной сюрреалистической, спутанно-запутанной картины мира. Настоящий исследователь должен отличать такие "фантики" от настоящих ценностей.

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

Это мы видим на примере СТО и ОТО, превратившихся в своеобразный вид религии, управляющей наукой и общественным мнением. Никакое количество фактов, противоречащих им, не может преодолеть формулу Эйнштейна: "Если факт не соответствует теории - измените факт" (В другом варианте " - Факт не соответствует теории? - Тем хуже для факта").

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

Эксперимент на то и эксперимент, что он есть не изощрение мысли, а проверка мысли. Непротиворечивая внутри себя мысль не может сама себя проверить. Это доказано Куртом Гёделем.

Откройте проект, в котором вы хотите создать модель. Если вы еще не создавали ни одного проекта, то можете воспользоваться проектом DEMO, который доступен сразу после установки Cradle или создать свой проект.

Чтобы войти в DEMO проект используйте имя пользователя — MANAGER , пароль — MANAGER

Как создать свой проект подробно показывается в этом видео

После создания нового проекта вы также сможете использовать для входа имя пользователя — MANAGER и пароль — MANAGER

Создание модели

Для того, чтобы создать модель IDEF0 включите Панель проекта и перейдите в раздел моделирования Essential Domain

Примечание : аналогично можно создавать модели и в разделе моделирования Implementation Domain, а также в любом разделе, настроенном пользователем. Раздел моделирования — это фактически пространство имен, в рамках которого можно повторно использовать потоки.

Чтобы создать контекстную модель IDEF0 щелкните правой кнопкой мыши по разделу IDEF0 и выберите пункты меню Новый->Элемент

Обратите внимание, что это наименование всей модели в целом, а не функционального блока на A0.

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

Создание функционального блока

Для этого выберите символ функционального блока на палитре

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

Появится диалоговое окно, в котором необходимо ввести наименование функционального блока, после чего нажать ОК.

В результате будет создан функциональный блок с заданным вами именем

Вы можете выделить границу блока и изменить его масштаб

Создание потоков

Чтобы создать потоки, выберите на палитре символ потока (без туннелирования или с туннелированием)

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

после этого появится диалоговое окно для ввода наименования потока. Введите краткое наименование потока и нажмите OK

Примечание: Вы сможете ввести подробное описание потока потом в его спецификации.

После этого по аналогии можно создать все необходимые потоки

Сохраните модель, нажав кнопку с дискетой или сочетание клавиш CTRL+S. При сохранении будут созданы спецификации символов, которые можно отредактировать, чтобы дать более подробное описание элементов модели.

После сохранения модели, вы сможете увидеть созданные спецификации на панели проекта в том же разделе, где вы создавали модель. Будут созданы спецификации двух типов — Function и Flow.

Декомпозиция модели

в появившемся диалоге оставьте настройки по умолчанию и нажмите OK

После чего будет создана дочерняя диаграмма A1 и на нее перенесены все потоки с диаграммы A0.

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

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

и введите требуемое наименование

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

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

В результате вы получите поток с двумя изгибами

Вы можете откорретировать положение изгибов, выделив поток и перетащив в нужное место точки изгибов

Посмотрите видеофрагмент для того, чтобы увидеть это в динамике

Чтобы удалить (или добавить) точку изгиба, нажмите клавишу SHIFT на клавиатуре и щелкните в точку, которую необходимо удалить или в то место потока, где ее надо создать