Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Лабы_по_BPWin_new.doc
Скачиваний:
12
Добавлен:
12.11.2019
Размер:
9.73 Mб
Скачать

Свойства, определяемые пользователем (udp)

АВС позволяет оценить стоимостные и временные характеристики системы. Если стоимостных показателей недостаточно, имеется возможность внесения собственных метрик — свойств, определенных пользователем — (User Defined Properties, UDP). UDP позволяют провести дополнительный анализ, хотя и без суммирующих подсчетов.

Для описания UDP служит диалог User-Defined Property Editor (меню Model/UDP Definition Editor). В верхнем окне диалога вносится имя UDP, в списке выбора Datatype описывается тип свойства. Имеется возможность задания 18 различных типов UDP, в том числе управляющих команд и массивов, объединенных по категориям. Для внесения категории следует задать имя категории в окне New Keyword и щелкнуть по кнопке Add Category. Для присвоения свойства категории необходимо выбрать UDP из списка, затем категорию из списка категорий и щелкнуть по кнопке Update. Одна категория может объединять несколько свойств, в то же время одно свойство может входить в несколько категорий. Свойство типа List может содержать массив предварительно определенных значений. Для определения области значений UDP типа List следует задать значение свойства в окне New Keyword и щелкнуть по кнопке Add Member. Значения из списка можно редактировать и удалять.

Каждой работе можно поставить в соответствие набор UDP. Для этого следует щелкнуть правой кнопкой мыши по работе и выбрать пункт меню UDP. В закладке UDP Values диалога IDEF0 Activity Properties можно задать значения UDP. Результат задания можно проанализировать в отчете Diagram Object Report (меню Tools | Report | Diagram Object Report).

Выполнение работы.

В диалоговом окне Model Properties (вызывается из меню Mode/Model Properties) во вкладке ABC Units установите единицы измерения денег - рубли и времени - часы.

Вкладка ABC Units диалога Model Properties

Для отображения стоимости каждой работы в нижнем левом углу прямоугольника перейдите в меню Model/Model Properties и во вкладке Display диалога Model Properties включите опцию ABC Data

Вкладка Display диалога Model Properties

Для отображения частоты или продолжительности работы переключите радиокнопки в группе ABC Units.

Далее можно поступить двумя различными способами: либо внести в Dictionary/Cost Center Cost Center (Словарь/Центр Затрат) внесите название и определение центров затрат, либо сделать это через Cost Center Editor, вызвав Activity Properties через контекстное меню и перейдя на вкладку Cost.

Для продолжения работы по первому способу перейдите в меню Dictionary/Cost Center (Словарь/Центр Затрат) и в окне Cost Center Dictionary (Словарь Центра Затрат) внесите название и определение центров затрат. Для второго способа порядок действий приведен ниже.

Выбор меню Dictionary/Cost Center

Незаполненное окно Cost Center Dictionary

Вид окна Cost Center Dictionary после внесения название и определение центров затрат представлен ниже (обратите внимание на то, что центры затрат упорядочились по алфавиту).

Центры затрат ABC

Центр затрат

Определение

Управление/management

Затраты на управление, связанные с составлением графика работ, формированием партий компьютеров, контролем над сборкой и тестированием/management for planning and control

Рабочая сила/human resources

Затраты на оплату рабочих, занятых сборкой и тестированием компьютеров/human resources cost

Компоненты/components

Затраты на закупку компонентов/components cost

Заполненное окно Cost Center Dictionary

Для назначения стоимости работе "Computer assembly" следует на диаграмме А2 щелкнуть по ней правой кнопкой мыши и выбрать в контекстном меню Cost.

Диаграмма А2 - выбор в контекстном меню опции Cost

Вкладка Cost диалога Activity Properties

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

Однако существует второй способ, который представляется более простым.

На диаграмме А0 выбираем блок, для которого будет рассчитывать стоимость.

Чтобы стоимость была рассчитана как сумма стоимостей нижних уровне декомпозиции, необходимо в открывшемся окне Activity Properties выбрать переключатель Compute from decomposition, как показано ниже:

Далее переходим на диаграмму А2 и для каждого блока вносим свои расчеты стоимости:

В открывшемся окне выбираем Cost Center Editor:

И вносим название деятельности и определение:

Нажимаем кнопку "Add" и закрываем окно. После этого вносим стоимость работы, ее продолжительность и частоту:

На диаграмме А2 появляется стоимость данного этапа.

Показатели стоимости работ на диаграмме А2.

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

Activity Name

Cost Center

Cost Center Cost, руб.

Duration, час

Frequency

Отслеживание расписания и управление сборкой и тестированием/ Ordering of schedule and assemble and testing management

Управление/management

500,00

0,50

14,00

Сборка настольных компьютеров/computer assembly

Рабочая сила/ computer assembly

100,00

2,00

8,00

Компоненты/ components for computers

16000,00

Сборка ноутбуков/notebook assembly

Рабочая сила/notebook assembly

140,00

4,00

6,00

Компоненты/components for notebook

28000,00

Тестирование/testing компьютеров

Рабочая сила/testing

60,00

1,00

14,00

Обратите внимание, что работа "Computer assembly" имеет IDEF3 декомпозицию, поэтому на вкладке необходимо выбрать "Override decompositions" как показано ниже, чтобы показать, что на более низком уровне декомпозиции стоимость работ не указана:

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

В результате получаем полностью рассчитанные стоимости по работам:

Перейдя на диаграмму А0 убеждаемся, что стоимость посчитана для всего блока:

Отображение стоимости в нижнем левом углу прямоугольника работы

Более того, если посмотреть в Dictionary/Cost Center Cost Center (Словарь/Центр Затрат), то увидим, что все виды деятельности, для которых рассчитывается стоимость туда внесены:

Теперь сгенерируем отчет по стоимости: Activity Cost Report.

Выбираем соответствующие опции меню:

Выбор опций меню для генерации отчета Activity Cost Report

В открывшемся диалоговом окне Activity Based Costing Report задайте параметры генерации отчета Activity Cost Report как показано ниже.

Задание параметров генерации отчета Activity Cost Report

Нажав на кнопку "Preview" (предварительный просмотр), увидим:

Фрагмент отчета Activity Cost Report

Использование категорий UDP.

Для этого (как и для работы с ABC) существует два способа – через словарь и через контекстное меню. При работе через словарь перейдите в меню Dictionary/UDP Keywords и в диалоговом окне UDP Keyword Dictionary внесите ключевые слова UDP(User Defined Properties - Свойства Определяемые Пользователем), затем создайте UDP. Для этого перейдите в меню Dictionary/UDP и в словаре внесите имя UDP.

Если работать через контекстное меню, то вызываем контекстное меню и выбрать пункт UDP.

Выбор в контекстном меню UDP для работы

Появится окно User Defined Property Dictionary Edition, в котором в дальнейшем будут внесены и ключевые слова, и свойства, и их тип:

Внесем следующие ключевые слова:

  • Расход ресурсов/Resources;

  • Документация/Documents;

  • Информационная система/Information system.

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

Выбор типа данных.

Подключение к UDP ключевого слова

Добавление значений (списка приложений).

Наименование UDP

(Name)

Тип

(UDP Datatype)

Значение

(Value)

Ключевое слово

(Keyword)

Приложения/ attachment

Text List (Multiple Selection)

Модуль оформления заказов/ordering module.

Модуль создания и контроля расписания работ/planning module.

Модуль учета комплектующих и оборудования/components accounting module.

Модуль процедур сборки и поиска неисправностей/assembly and testing module

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

Дополнительная документация/ additional documents

Command List

Winword.exe sample_1.doc

Winword.exe sample_2.doc

Документация

История изменения/ history of changes

Paragraph

Text

Документация

Загрязнение окружающей среды/ environmental pollution

Text List (Single Selection)

Очень высокое

Высокое

Среднее

Низкое

Расход электроэнергии/ power consumption

Real Number

Расход ресурсов

После внесения UDP типа Command или Command List (Дополнительная документация/ additional documents) щелчок по кнопке приведет к запуску соответствующего приложения (Winword.exe → 1.doc). Для того, чтобы соответствующее приложение было запущено необходимо, чтобы оно было предварительно создано.

При добавлении исполняемых файлов можно воспользоваться кнопкой "Browse".

После внесения значений получаем:

Заметим, что все данные появились в словаре UDP (Dictionary|UDP):

Заполненный словарь UDP

Для назначения UDP работе следует щелкнуть по ней правой кнопкой мыши и выбрать в контекстном меню UDP (см. выше). Появится уже привычная вкладка UDP Values диалога Activity Properties.

Вкладка UDP Values диалогового окна Activity Properties

Activity Name

Дополнительная документация

Приложения

История изменения

Расход электроэнергии

кВтч

Загрязнение окружающей среды

Сборка настольных компьютеров

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

Сборка ноутбуков

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

25,00

Среднее

Тестирование компьютеров

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

40,00

Среднее

Отслеживание расписания и управление сборкой и тестированием

Win word.EXE sample2.doc

Модуль создания и контроля расписания выполнения работ

История изменения спецификаций

10,00

Низкое

В диалоге Activity Properties щелкните по кнопке Filter. В появившемся диалоге Diagram object UDP filter отключите ключевые слова "Информационная система". Щелкните по ОК. В результате в диалоге Activity Properties не будут отображаться UDP с ключевыми словами "Информационная система".

Диалоговое окно Diagram object UDP filter

Вкладка UDP Values диалогового окна Activity Properties

Отметим, что свойства UDP можно присвоить не только работам, но и стрелкам.

Посмотрите отчет по UDP. Меню Tools/Report/Diagram Object Report:

Меню Tools/Report/Diagram Object Report

Выберите опции отчета:

Выбор опций отчета

Щелкните по кнопке Report. В появившемся диалоге "Сохранение файла" щелкните по кнопке "Сохранить.

Диалоговое окно "Сохранение файла" отчета

Далее внимание! Если соответствующие библиотеки установлены, то запускается генератор отчетов RPTwin и появляется диалог New Report (Новый Отчет). Выберите тип отчета Columnar (Колоночный). Если не установлены, то на этом выполнение упражнения заканчивается.

Диалоговое окно New Report

Автоматически создается шаблон отчета.

Шаблон отчета в RPTwin

Нажатие на кнопку позволяет просмотреть отчет.

Отразим в отчете суммарный расход электроэнергии.

Выберите в меню Insert/Formula Field, затем переместите маркер в секцию отчета Page Footer, затем щелкните один раз. Появляется диалог Formula Editor.

Диалоговое окно Formula Editor

В поле Formula внесите текст формулы: Sum ({"Расход электроэнергии/power consumption"})

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

Окно просмотра отчета в RPTwin

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

1. Какие средства анализа предоставляет разработчику All Fusion Processer Modeler?

2. На какой модели основан стоимостной анализ?

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

4. Что такое UDP? Для каких целей их необходимо использовать?

5. Расскажите, каким образом эти данные используются для оценки модели?

Лабораторная работа 6. DFD диаграммы и отчеты в BPWin.

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

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

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

Всего DFD использует четыре важных элемента:

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

Потоки данных являются механизмами, использующимися для моделирования передачи информации (или даже физических компонент) из одной части системы в другую. Важность этого объекта очевидна: он дает название целому инструменту. Потоки на диаграммах обычно изображаются именованными стрелками, ориентация которых указывает направление движения информации. Иногда информация может двигаться в одном направлении, обрабатываться и возвращаться назад в ее источник. Такая ситуация может моделироваться либо двумя различными потоками, либо одним – двунаправленным для описания диалогов типа "команда-ответ". В DFD также двунаправленные стрелки используются между работами, между работой и внешней сущностью и между внешними сущностями Поскольку в DFD каждая сторона работы не имеет четкого назначения, как в IDEF0, стрелки могут подходить и выходить из любой грани прямоугольника работы. В DFD стрелки могут сливаться и разветвляться, что позволяет описать декомпозицию стрелок. Каждый новый сегмент сливающейся или разветвляющейся стрелки может иметь собственное имя.

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

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

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

Диаграммы DFD могут быть построены с использованием традиционного структурного анализа, подобно тому, как строятся диаграммы IDEF0.

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

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

Создание отчетов в BPwin

BPwin имеет мощный инструмент генерации отчетов. Отчеты по модели вызываются из пункта меню Report. Всего имеется семь типов отчетов:

  1. Model Report. Включает информацию о контексте модели — имя модели, точку зрения, область, цель, имя автора, дату создания и др.

  2. Diagram Report. Отчет по конкретной диаграмме. Включает список объектов (работ, стрелок, хранилищ данных, внешних ссылок и т. д.).

  3. Diagram Object Report. Наиболее полный отчет по модели. Может включать полный список объектов модели (работ, стрелок с указанием их типа и др.) и свойства, определяемые пользователем.

  4. Activity Cost Report. Отчет о результатах стоимостного анализа. Рассмотрен ранее.

  5. Arrow Report. Отчет по стрелкам. Может содержать информацию из словаря стрелок, информацию о работе-источнике, работе-назначении стрелки и информацию о разветвлении и слиянии стрелок.

  6. Data Usage Report. Отчет о результатах связывания модели процессов и модели данных.

  7. Model Consistency Report. Отчет, содержащий список синтаксических ошибок модели.

Синтаксические ошибки IDEF0 с точки зрения BPwin делятся на три типа:

1. Ошибки, которые BPwin выявить не в состоянии. Например, проверка чтобы имя работы было выражено отглагольным существительным, а имя стрелки существительным, это ручная работа, которая должна выполняться аналитиками.

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

3. Ошибки, которые BPwin позволяет допустить, но детектирует их. Полный их список можно получить в отчете Model Consistency Report.

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

Раскрывающийся список Standart Reports позволяет выбрать один из стандартных отчетов. Стандартный отчет - это запоминаемая комбинация переключателей, флажков и других элементов управления диалога. Для создания собственного стандартного отчета необходимо задать опции отчета, ввести имя отчета в поле списка выбора и щелкнуть по кнопке New. Стандартный отчет можно изменить (кнопка Update) или удалить(кнопка Delete).

В правом верхнем углу диалога находится группа управляющих элементов для выбора формата отчета. Доступны следующие форматы:

    • Labeled - отчеты включают метку поля, затем, в следующей строке, печатается содержимое поля;

    • Fixed Column - каждое поле печатается в собственной колонке;

    • Tab-Comma Delimited - каждое поле печатается в собственной колонке. Колонки разделяются знаком табуляции или запятыми;

    • DDE Table - данные передаются по DDE приложению, например MS Word или Excel;

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

Опция Ordering (на отчете по стрелкам отсутствует) сортирует данные по какому-либо значению.

Опция Multi-Valued Format регулирует вывод полей в отчете при группировке данных:

    • Repeating Group - детальные данные объединяются в одно поле, между значениями вставляется +.

    • Filled - дублирование данных для каждого заголовка группы;

    • Header (опция по умолчанию) - печатается заголовок группы, затем -детальная информация.

Выполнение работы

Построение DFD диаграмм.

DFD диаграмму можно (как и диаграмму IDEF3) использовать для более детального описания потоков информации работ диаграммы IDEF0. В этом случае, так же как и для детализации работ при помощи диаграммы IDEF3, выбирается работа на контекстной диаграмме, затем в панели инструментов выбирается «стрелка вниз», в появившемся окне выбирается тип диаграммы DFD и число процессов, которые будут построены.

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

При построении диаграммы будем реализовывать следующую модель.

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

  2. Затем принимает заказ и заносит данные в базу по заказам клиента.

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

  4. Составляет окончательную калькуляцию для клиента.

  5. Формирует заказ-наряд для конкретного инженера по сборке.

Входим в программу и создаем файл: File | New, появляется следующее окно. В диалоговом окне Name, пишем название нашего проекта: Pаспределение заказов/Ordering.

Как и в случае построения IDEF диаграмм, вносятся данные автора и появляется окно программы, панель инструментов имеет некоторые отличия, связанные со спецификой построения DFD диаграмм.

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

Затем внесем прямоугольник со скругленными углами – подсистему Обработки заказа/Order processing.

Имена для подсистем, процессов и стрелок можно вносить используя контекстное меню. Назовем стрелки: Звонки клиентов/Client's call и Заказы клиентов/Clients order.

Детализируем процессы системы обработки заказов.

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

Появляется следующее окно: выбираем модель DFD, Number of Activities in this – количество объектов 4.

Так же как и в ранее заполняем все названия потоков и процессов как показано ниже:

Процессы:

Название

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

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

Проверить данные клиента/Verify client’s data

Звонок клиента/Client's call, Данные клиента/Client's data

Авторизованный заказ/Authorized order

Проверить наличие компонент/Check avaliability of components

Авторизованный заказ/Authorized order,

Компоненты в наличии/Available components

Компоненты подлежащие заказу/Requiered components, Список компонентов/List of

components

Рассчитать стоимость заказа для клиента/Calculate price for client

Список компонентов/List of

Components

Создать наряд на работу/Make work order

Список компонентов/List of

Components, Внутренние инструкции/Instructions

Заказ клиента/Client’s order

Хранилища:

Название

Определение

Список клиентов/Client' list

Для занесения данных по клиенту (ФИО, телефон, адрес и пр.)

Список заказов/Order list

Для занесения данных по заказу (требуемые компоненты)

Склад/Storehouse

Данные о компонентах в наличии

Список компонент для приобретения/Purchase order

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

Нормативы/Regulations

Данные о стоимости работ и нормо-часах на их выполнение

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

Обратите внимание, что часть стрелок имеет двустороннее направление, предполагающее запрос-ответ. Чтобы создать такие стрелки необходимо в контекстном меню выбрать пункт "Style" и там выбрать соответствующий вид стрелки.

Затем необходимо отразить на диаграмме документы, которые менеджер составляет для клиента – окончательный счет по заказу. Для этого из процесса Посчитать окончательную стоимость/Calculate price for client необходимо направить стрелку к внешней сущности Клиент/Client. Назовем эту стрелку Счет по заказу/Order price.

Туннелированная стрелка не появится на диаграмме более высокого уровня. Для того, чтобы она там появилась, поступим как и ранее: щелкнем правой кнопкой мыши по стрелке, выберем пункт контекстного меню "Arrow Tunnel"

И затем выбираем пункт меню, как показано ниже:

Окончательный вид диаграммы верхнего уровня:

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

И на вкладку определение.

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

Далее перейдем на вкладку "Arrow Data". Если вы уверены, что определение внесено, можно сразу из контекстного меню перейти на вкладку "Arrow Data".

Заполняем вкладку "Arrow Data" как показано ниже. Для этого перейдем в пункт "Ent/Att Editor". На основании данных логической модели, мы вносим данные, которые будут храниться в БД

Вносим название сущности Клиент/Client и значения атрибутов: ID_client, Name, Surname, Order_number, Phone.

Возвращаемся на вкладку "Arrow Data", там появились данные по создаваемой таблице.

Теперь необходимо эти данные экспортировать в ERWin для дальнейшего построения базы данных. Для этого выбираем пункт меню File | Export | – Erwin (BPX).

Выбираем место, где файл с расширением bpx будет сохранен.

Затем вызываем программу ERwin, создаем новую модель (физическую и логическую!),

После чего необходимо импортировать созданный файл в ERwin. Для этого выбираем пункты меню File | Import AllFusion PM

Затем в открывшемся окне выбирается файл, после чего появляется окно AllFusion ERwin DM/ AllFusion PM Import.

Нажимаете кнопку "Import".

Таблица базы данных сгенерирована и готова к дальнейшей работе. Перенесем первичный ключ ID_client в верхнюю часть сущности, проверим, что тип данных соответствует требуемому (по умолчанию char(18)).

Окончательно получаем вид таблицы:

Примеры создания отчетов.

Создайте отчет по синтаксическим ошибкам: выберите Tools | Report , выберите Model Consistency Report, выберите Preview, просмотрите ошибки, выберите Close.

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

Создайте отчет по модели: выберите диаграмму А0, выберите Tools | Report | Diagram Object Report, в списке Standart Report выберите Activity Definition <hierarchical>, в области Start from Activity выберите А0,

в области Report On выберите Activities, Data stores, External, References,

в области Activity options выберите Name, Number , Definition, в области Arrow options выберите Input Name, Input Definition, Control Name, Control Definition, Output Name, Output Definition, Mech Name, Mech Definition, в области Report Format выберите Fixed Column, выберите Preview, на экране должно быть описание модели,

выберите Close, в области Report Format выберите DDE Table , выберите Report, выберите Word, нажмите ОК, выберите Файл | Сохранить как, введите имя «имя_файла».rtf, выберите Сохранить.

Полученный файл в формате Word может быть использован в дальнейшей работе над моделью.

Создайте новый шаблон отчета: выберите Tools | Report s Builder | Report Builder, в списке Output Type выберите HTML, выберите New,

выберите в правом окне Document Properties, выберите вкладку Title, в поле Document title введите название вашего отчета, например, Report Number1, выберите цвет какой понравится, закройте окно свойств.

Чтобы поместить объект в отчет в левом окне выберите Model, нажмите стрелку вправо, в правом окне выберите Model Section, выберите вкладку Section, выберите шрифт, размер, закройте окно.

Аналогично в левом окне выберите Activity, Data Store, External Reference. Сохраните отчет: выберите File | Save, введите имя файла. Отчет создастся в формате HTML. Создайте отчет: File | Run

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

1. Приведите и опишите основные символы, используемые при описании DFD диаграмм.

2. Опишите процесс создания диаграмм DFD.

3. Приведите пример построения DFD диаграммы. Опишите каждый этап создания модели.

4. Опишите как возможно совместно использовать диаграммы IDEF0 и DFD.

5 Какие виды отчетов существуют в BPWin? Приведите примеры их использования.

Список литературы:

1. Маклаков С.В. Создание информационных систем с AIIFusion Modeling Suite – М.: Диалог-МИФИ, 2007 г.

2. Маклаков С. В. Моделирование бизнес-процессов с AIIFusion Process Modeler -

М.: Диалог-МИФИ, 2004 г.

3. Дубейковский В. И. Эффективное моделирование с AllFusion Process Modeler -

М.: Диалог-МИФИ, 2007 г.

4. Калянов Г. Н. Моделирование, анализ, реорганизация и автоматизация бизнес-процессов – М.: Финансы и статистика, 2006 г.

5. Черемных С.В., Семенов И.О., Ручкин В.С. Моделирование и анализ систем. IDEF-технологии: практикум Серия: Прикладные информационные технологии – М.: Финансы и статистика, 2006 г.

Отчет по лабораторным работам 1 – 4 (5).

По разработке информационной системы должен содержать:

  1. Заголовок: название темы, разрабатываемой ИС.

  2. Исследование выбранной предметной области в произвольной форме: словесное описание, выделение основных работ системы в виде таблиц с описаниями и т.п.

  3. Построенную модель деятельностей организации в BPWin. С внесением описаний по деятельностям, построить Node Tree диаграмму и FEO диаграмму.

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

  5. Для выбранной работы предметной области (возможно, другой) построить DFD диаграмму.

  6. Построить организационную диаграмму.

  7. Провести стоимостной анализ разработанной системы, показать возможные ее оценки при помощи UDP.

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

Отчет предоставляется в электронном виде.

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

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

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

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

  4. Знать, для каких целей используются IDEF0, IDEF3 и DFD диаграммы.

  5. Уметь выполнять стоимостной анализ системы и создавать свойства, определяемые пользователем.

  6. Иметь представление о генерации отчетов.