Файл: Лабораторная работа 1 Методология функционального моделирования 1def0, 1def0, dfd.docx

ВУЗ: Не указан

Категория: Не указан

Дисциплина: Не указана

Добавлен: 05.12.2023

Просмотров: 78

Скачиваний: 3

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.

ЛАБОРАТОРНАЯ РАБОТА №1
Методология функционального моделирования - 1DEF0, 1DEF0, DFD


Цель работы: изучить основные принципы методологии IDEF0.

Программное обеспечение: BPWin.

Оборудование: персональный компьютер, практикум

Правила по технике безопасности: общие (приложение).

Время проведения: 2 уч. часа

ВОПРОСЫ ВХОДНОГО КОНТРОЛЯ:

1. Приведите этапы разработки программного обеспечения.

2. Опишите, что включает в себя постановка задачи и предпроектные исследования.

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

4. Перечислите правила разработки технического задания.

5. Назовите основные разделы технического задания.

6. Назовите этапы разработки программного обеспечения.

7. Расскажите, что такое жизненный цикл программного обеспечения.

8. Расскажите, в чем заключается постановка задачи и предпроектные исследования.

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

10. Перечислите составляющие эскизного проекта.
КРАТКИЕ ТЕОРЕТИЧЕСКИЕ СВЕДЕНИЯ

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

О сновные элементы и понятия IDEF0

1. Функциональный блок (Activity Box).

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

2. Интерфейсная дуга (Arrow).

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


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

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

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

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

Механизм - ресурсы, которые выполняют работу (персонал предприятия, станки, устройства и т. д.).

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

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

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

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

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

Правила построения:

1. Блоки на диаграмме должны располагаться по диагонали – от левого верхнего угла диаграммы до правого нижнего. Блоки на диаграмме, расположенные вверху слева «доминируют» над блоками, расположенными внизу справа.

2. Диаграммы более низкого уровня (не являющиеся контекстными) должны содержать от трех и до шести блоков.

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

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



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



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

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



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



Рис. 3.1.4 – Обратная связь по управлению
Связи «выход-механизм» характерны при распределении источников ресурсов (например, требуемые инструменты, обученный персонал, физическое пространство, оборудование, финансирование, материалы). В IDEFO дуга редко изображает один объект. Обычно она символизирует набор объектов. Так как дуги представляют наборы объектов, они могут иметь множество начальных точек (источников) и конечных точек (назначений). Поэтому дуги могут разветвляться и соединяться различными способами. Вся дуга или ее часть может выходить из одного или нескольких блоков и заканчиваться в одном или нескольких блоках.




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

Пример №1:

Функциональное моделирование начинается с того, что выделяется основная задача, которая решается путём выполнения этого бизнес-процесса. В нашем случае эта задача формулируется следующим образом: «Приготовить борщ». Эффективнее начинать процесс моделирования с того, что определить, какими данными и материалами мы обладаем до выполнения бизнес-процесса (Входные данные / Input), а также чётко уяснить, что мы хотим получить в результате выполнения бизнес-процесса (Выходные данные / Output). Это позволит выявить чёткие требования к бизнес-процессу и отбросить несбыточные надежды: обладая лишь горсткой сомнительного происхождения камней невозможно получить золотые слитки. В случае приготовления борща на входе имеются, например, овощи и мясо (их может, конечно, и не быть, но допустим, что все продукты были предусмотрительно закуплены). На выходе мы должны вполне логично получить борщ.

Нотация IDEF0 предполагает также, что для проведения функционального моделирования нужно выделить так называемый механизм (mechanism), т.е. тех исполнителей, которые будут задействованы в бизнес-процессе. В нашем примере в качестве механизма выступает Аристарх Григорьевич ну и, скажем, его старший сын Коля. Правильное выполнение процесса должно чем-то контролироваться (какими-то стандартами, методиками, технологиями и проч.). Это что-то в нотации IDEF0 называется «управлением» (control) и обязательно должно фигурировать на функциональной диаграмме.

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



Рис. 3.1.6 – Пример контекстной диаграммы

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


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



Рис. 3.1.7 – Диаграмма декомпозиции первого уровня

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

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

Пример №2:


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



Рис. 3.1.9 – Диаграмма декомпозиции первого уровня
МЕТОДИЧЕСКИЕ РЕКОМЕНДАЦИИ
BPwin имеет достаточно простой и интуитивно понятный интерфейс пользователя, дающий возможность аналитику создавать сложные модели при минимальных усилиях.