Самостоятельная работа по теме Изучение возможностей пакета BPWin

Самостоятельная работа№1

Тема: Изучение возможностей пакета BPWin.

Цель работы: Ознакомиться с возможностями пакета BPWin

Время выполнения: 8 часов

Теоретический материал

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

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

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

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

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

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

Каждая сторона блока имеет особое, вполне определенное назначение.

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

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

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

Расположение блоков на странице отражает авторское определение доминирования.

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

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

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

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

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

может не иметь ни одной стрелки входа. Стрелка входа рисуется как входящая в левую грань работы.

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

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

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

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

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

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

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

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

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

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

Рисунок 1 - Пример несбалансированной диаграммы

Определим контекстную диаграмму системы (рис. 2).

Рисунок 2 - Контекстная диаграмма системы

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

1. Определение уровня доступа в систему.

2. Выбор подсистемы.

3. Обращение к подсистеме.

4. Изменение БД (при необходимости).

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

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

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

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

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

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

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

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

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

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

1. Открытие БД.

2. Выполнение запроса.

3. Генерация отчетов.

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

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

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

При анализе полученной диаграммы возникает вопрос, по каким правилам происходит генерация отчетов?

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

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

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

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

(вариант 2)

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

(вариант 2)

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

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

·                   БД пользователей,

·                   БД студентов.

·                   БД вакансий,

·                   БД успеваемости,

·                   БД тестов,

·                   БД экспертных оценок,

·                   БД резюме.

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

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

2. Оператором формируется временный набор данных и предоставляется администратору.

3. Администратор осуществляет контроль данных и вносит их в БД.

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

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

Рисунок 10 - Декомпозиция работы «Изменение БД» (вариант 2)

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

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

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

Задания к работе

1.Создать новый проект в BPWin.

2. Сформировать контекстную диаграмму по системе согласно методологии IDEF0.

3. Задать входы, выходы, механизмы и управление.

4. Декомпозировать контекстную диаграмму.

5. Провести связи по выходу.

6. Провести связи по управлению.

7. Провести связи по входу.

8. Сохранить проект в отдельный файл.

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

1. Что представляет собой модель в нотации IDEF0?

2. Что обозначают работы в IDEF0?

3. Назовите порядок наименования работ?

4. Какое количество работ должно присутствовать на одной диаграмме?

5. Что называется порядком доминирования?

6. Как располагаются работы по принципу доминирования?

7. Каково назначение сторон прямоугольников работ на диаграммах?

8. Перечислите типы стрелок.

9. Назовите виды взаимосвязей.

10. Что называется граничными стрелками?

11. Объясните принцип именования разветвляющихся и сливающихся стрелок.

Скачано с www.znanio.ru