Какого рода синтаксические ошибки выявляет пакет bpwin - Ремонт и установка крупной бытовой техники

П А Р У С — Д О Н

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

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

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

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

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

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

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

6.DataUsage Report. Отчет о результатах связывания модели процессов и модели данных. (Будет рассмотрен ниже.)

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

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

oВо-первых, это ошибки, которые BPwin выявить не в состоянии. Например, синтаксис IDEF0 требует, чтобы имя работы было выражено отглагольным существительным или глагольной формой, выражающей действие («Занесение звонка клиента», «Обслуживание клиента», «Выписка счета» и т.

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

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

oТретий тип ошибок BPwin позволяет допустить, но детектирует их. Полный их список можно получить в отчете Model Consistency Report. Это единственный неопциональный отчет в BPwin. Список ошибок может содержать, например, неименованные работы и стрелки (unnamed arrow, unnamed activity), несвязанные стрелки (unconnected border arrow), неразрешенные стрелки (unresolved (square tunneled) arrow connections), работы, не имеющие по крайней мере одной

П А Р У С — Д О Н

стрелки выхода и одной стрелки управления (Activity «Сборка блоков» has no Control, Activity «Сборка блоков» has no Output), и

т. д. Пример отчета Model Consistency Report приведен на рис. 1.38.

Р И С . 1 . 3 8 . О Т Ч Е Т M O D E L C O N S I S T E N C Y R E P O R T

П А Р У С — Д О Н

Р И С . 1 . 3 9 . Д И А Л О Г A R R O W R E P O R T

Раскрывающийся список Standart Reports позволяет выбрать один из стандартных отчетов. Стандартный отчет — это запоминаемая комбинация переключателей, флажков и других элементов управления диалога. Для создания собственного стандартного отчета необходимо задать опции отчета, ввести имя отчета в поле списка выбора и щелкнуть по кнопке New. BPwin сохраняет информацию о стандартном отчете в файле BPWINRPT.INI. Все определения этого файла доступны из любой модели. Единственное ограничение — свойства, определяемые пользователем (User-Defined Properties). Они сохраняются в виде указателя и поэтому доступны только из «родной» модели. Стандартный отчет можно изменить (кнопка Update) или удалить(кнопка Delete).

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

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

o Fixed Column — каждое поле печатается ,в собственной колонке;

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

oDDE Table — данные передаются по DDE приложению,

например MS Word или Excel;

oRPTwin — отчет создается в формате Platinum RPTwin —

специализированного генератора отчетов, который входит в поставку BPwin.

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

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

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

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

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

Стоимостныйанализ(ЛВС) исвойства, определяемыепользователем(UDP)

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

П А Р У С — Д О Н

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

BPwin предоставляет аналитику два инструмента для оценки модели — стоимостный анализ, основанный на работах (Activity Based Costing, ABC), и свойства, определяемые пользователем (User Defined Properties, UDP). ABC является широко распространенной методикой, используемой международными корпорациями и государственными организациями (в том числе Департаментом обороны США) для идентификации истинных движителей затрат в организации.

Стоимостный анализ представляет собой соглашение об учете, используемое для сбора затрат, связанных с работами, с целью определить общую стоимость процесса. Стоимостный анализ основан на модели работ, потому что количественная оценка невозможна без детального понимания функциональности предприятия. Обычно ABC применяется для того, чтобы понять происхождение выходных затрат и облегчить выбор нужной модели работ при реорганизации деятельности предприятия (Business Process Reengineering, BPR). С помощью стоимостного анализа можно решить такие задачи, как определение действительной стоимости производства продукта, определение действительной стоимости поддержки клиента, идентификация работ, которые стоят больше всего (те, которые должны быть улучшены в первую очередь), обеспечение менеджеров финансовой мерой предлагаемых изменений т. д.

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

ABC включает следующие основные понятия:

oобъект затрат — причина, по которой работа выполняется, обычно, основной выход работы, стоимость работ есть суммарная стоимость объектов затрат («Предоставление ответа», рис. 1.40).

Р И С . 1 . 4 0 . И Л Л Ю С Т Р А Ц И Я Т Е Р М И Н О В A B C

oдвижитель затрат — характеристики входов и управлений работы (рис. 1.40), которые влияют на то, как выполняется и как долго длится работа;

o центры затрат, которые можно трактовать как статьи расхода.

При проведении стоимостного анализа в BPwin сначала задаются единицы измерения времени и денег. Для задания единиц измерения следует вызвать

П А Р У С — Д О Н

диалог Model Properties (меню Edit/Model Properties), закладка ABC Units (рис. 1.41).

Если в списке выбора отсутствует необходимая валюта (например, рубль), ее можно добавить. Символ валюты по умолчанию берется из настроек Windows. Диапазон измерения времени в списке Unit of measurment достаточен для большинства случаев — от секунд до лет.

Р И С . 1 . 4 1 . Н А С Т Р О Й К А Е Д И Н И Ц И З М Е Р Е Н И Я В А Л Ю Т Ы И В Р Е М Е Н И

Затем описываются центры затрат (cost centers). Для внесения центров затрат необходимо вызвать диалог Cost Center Editor (меню Edit/ABC Cost Centers (рис. 1.42).

Каждому центру затрат следует дать подробное описание в окне Definition. Список центров затрат упорядочен. Порядок в списке можно менять при помощи стрелок, расположенных справа от списка. Задание определенной последовательности центров затрат в списке, во-первых, облегчает последующую работу при присвоении стоимости работам, а во-вторых, имеет значение при использовании единых стандартных отчетов в разных моделях. Хотя, как было указано в 1.2.5, BPwin сохраняет информацию о стандартном отчете в файле BPWINRPT.INI, информация о центрах затрат и UDP сохраняется в виде указателей, т. е. хранятся не названия центров затрат, а их номера. Поэтому, если нужно использовать один и тот же стандартный отчет в разных моделях, списки центров затрат должны быть в них одинаковы.

П А Р У С — Д О Н

Р И С . 1 . 4 2 . Д И А Л О Г C O S T C E N T E R E D I T O R

Для задания стоимости работы (для каждой работы на диаграмме декомпозиции) следует щелкнуть правой кнопкой мыши по работе и на всплывающем меню выбрать Cost Editor (рис. 1.43). В диалоге Activity Cost указывается частота проведения данной работы в рамках общего процесса (окно Frequency) и продолжительность (Duration). Затем следует выбрать в списке один из центров затрат и в окне Cost задать его стоимость. Аналогично назначаются суммы по каждому центру затрат, т. е. задается стоимость каждой работы по каждой статье расхода. Если в процессе назначения стоимости возникает необходимость внесения дополнительных центров затрат, диалог Cost Center Editor вызывается прямо из диалога Activity Cost соответствующей кнопкой.

Р И С . 1 . 4 3 . З А Д А Н И Е С Т О И М О С Т И Р А Б О Т В Д И А Л О Г Е A C T I V I T Y C O S T

П А Р У С — Д О Н

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

Р И С . 1 . 4 4 . В Ы Ч И С Л Е Н И Е З А Т Р А Т Р О Д И Т Е Л Ь С К О Й Р А Б О Т Ы

Этот достаточно упрощенный принцип подсчета справедлив, если работы выполняются последовательно. Встроенные возможности BPwin позволяют разрабатывать упрощенные модели стоимости, которые тем не менее оказываются чрезвычайно полезными при предварительной оценке затрат. Если схема выполнения более сложная (например, работы производятся альтернативно), можно отказаться от подсчета и задать итоговые суммы для каждой работы вручную (Override Decompositions). В этом случае результаты расчетов с нижних уровней декомпозиции будут игнорироваться, при расчетах на верхних уровнях будет учитываться сумма, заданная вручную. На любом уровне результаты расчетов сохраняются независимо от выбранного режима, поэтому при выключении опции Override Decompositions расчет снизу вверх производится обычным образом.

Для проведения более тонкого анализа можно воспользоваться специализированным средством стоимостного анализа EasyABC (ABC Technology, Inc.). BPwin имеет двунаправленный интерфейс с EasyABC. Для экспорта данных в EasyABC следует выбрать пункт меню File/Export/Node Tree , задать в диалоге Export Node Tree необходимые настройки и экспортировать дерево узлов в текстовый файл (.txt). Файл экспорта можно импортировать в EasyABC. После проведения необходимых расчетов результирующие данные можно импортировать из EasyABC в BPwin. Для импорта нужно выбрать меню

File/Import/Costs и в диалоге Import Activity Costs выбрать необходимые установки.

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

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

П А Р У С — Д О Н

Результаты стоимостного анализа наглядно представляются на специальном отчете BPwin — Activity Cost Report (меню Report/Activity Cost Report). Отчет позволяет документировать имя, номер, определение и стоимость работ, как суммарную, так и раздельно по центрам затрат (рис. 1.46).

Р И С . 1 . 4 5 Д И А Л О Г Н А С Т Р О Й К И О Т Ч Е Т А П О С Т О И М О С Т И Р А Б О Т

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

Edit/Model Properties), закладка Display, ABC Data, ABC Units.

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

Для описания UDP служит диалог User-Defined Property Name Editor (меню

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

П А Р У С — Д О Н

Р И С . 1 . 4 6 Д И А Л О Г О П И С А Н И Я U D P

Например, категория «Загрязнение окружающей среды» может объединять свойство «загрязнение воды» типа Real Number и свойство «загрязнение воздуха» типа Integer List с предварительно определенной областью значений

(1, 2, 3, 4, 5).

Каждой работе можно поставить в соответствие набор UDP. Для этого следует щелкнуть правой кнопкой мыши по работе и выбрать пункт меню UDP Editor. В закладке UDP Values диалога IDEF0 Activity Properties можно задать значения UDP. Свойства типа List отображаются списком выбора, который заполнен предварительно определенными значениями. Свойства типа Command могут иметь в качестве значения командную строку, которая выполняется при нажатии на кнопку !!!. Например, свойство «Спецификации» категории «Дополнительная документация» может иметь значение

«C:MSOffice97OfficeWINWORD.EXE sped.doc».

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

Результат задания проанализировать в отчете Diagram Object Report (меню

Report/Diagram Object Report) (рис. 1.47.

П А Р У С — Д О Н

Р И С . 1 . 4 7 Д И А Л О Г Н А С Т Р О Й К И О Т Ч Е Т А D I A G R A M

O B J E C T R E P O R T

В левом нижнем углу диалога настройки отчета показывается список UDP. С помощью кнопки Activity Categories можно установить фильтр по категориям.

Дополнениесозданноймоделипроцессов диаграммамиDFD иWorkflow (IDEF3)

Диаграммы потоков данных (Data Flow Diagramming)

Диаграммы потоков данных (Data flow diagramming, DFD) используются для описания документооборота и обработки информации. Подобно IDEF0, DFD представляет модельную систему как сеть связанных между собой работ. Их можно использовать как дополнение к модели IDEF0 для более наглядного отображения текущих операций документооборота в корпоративных системах обработки информации. DFD описывает:

o функции обработки информации (работы);

oдокументы (стрелки, arrow), объекты, сотрудников или отделы, которые учавствуют в обработке информации;

Соседние файлы в папке ИСУП

Источник

П А Р У С — Д О Н

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

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

6.DataUsage Report. Отчет о результатах связывания модели процессов и модели данных. (Будет рассмотрен ниже.)

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

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

П А Р У С — Д О Н

стрелки выхода и одной стрелки управления (Activity «Сборка блоков» has no Control, Activity «Сборка блоков» has no Output), и

т. д. Пример отчета Model Consistency Report приведен на рис. 1.38.

Р И С . 1 . 3 8 . О Т Ч Е Т M O D E L C O N S I S T E N C Y R E P O R T

П А Р У С — Д О Н

Р И С . 1 . 3 9 . Д И А Л О Г A R R O W R E P O R T

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

o Fixed Column — каждое поле печатается ,в собственной колонке;

oDDE Table — данные передаются по DDE приложению,

например MS Word или Excel;

oRPTwin — отчет создается в формате Platinum RPTwin —

специализированного генератора отчетов, который входит в поставку BPwin.

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

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

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

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

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

Стоимостныйанализ(ЛВС) исвойства, определяемыепользователем(UDP)

П А Р У С — Д О Н

ABC включает следующие основные понятия:

Р И С . 1 . 4 0 . И Л Л Ю С Т Р А Ц И Я Т Е Р М И Н О В A B C

o центры затрат, которые можно трактовать как статьи расхода.

П А Р У С — Д О Н

диалог Model Properties (меню Edit/Model Properties), закладка ABC Units (рис. 1.41).

Р И С . 1 . 4 1 . Н А С Т Р О Й К А Е Д И Н И Ц И З М Е Р Е Н И Я В А Л Ю Т Ы И В Р Е М Е Н И

П А Р У С — Д О Н

Р И С . 1 . 4 2 . Д И А Л О Г C O S T C E N T E R E D I T O R

Р И С . 1 . 4 3 . З А Д А Н И Е С Т О И М О С Т И Р А Б О Т В Д И А Л О Г Е A C T I V I T Y C O S T

П А Р У С — Д О Н

Р И С . 1 . 4 4 . В Ы Ч И С Л Е Н И Е З А Т Р А Т Р О Д И Т Е Л Ь С К О Й Р А Б О Т Ы

File/Import/Costs и в диалоге Import Activity Costs выбрать необходимые установки.

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

П А Р У С — Д О Н

Р И С . 1 . 4 5 Д И А Л О Г Н А С Т Р О Й К И О Т Ч Е Т А П О С Т О И М О С Т И Р А Б О Т

Edit/Model Properties), закладка Display, ABC Data, ABC Units.

Для описания UDP служит диалог User-Defined Property Name Editor (меню

П А Р У С — Д О Н

Р И С . 1 . 4 6 Д И А Л О Г О П И С А Н И Я U D P

(1, 2, 3, 4, 5).

«C:MSOffice97OfficeWINWORD.EXE sped.doc».

Результат задания проанализировать в отчете Diagram Object Report (меню

Report/Diagram Object Report) (рис. 1.47.

П А Р У С — Д О Н

Р И С . 1 . 4 7 Д И А Л О Г Н А С Т Р О Й К И О Т Ч Е Т А D I A G R A M

O B J E C T R E P O R T

Дополнениесозданноймоделипроцессов диаграммамиDFD иWorkflow (IDEF3)

Диаграммы потоков данных (Data Flow Diagramming)

o функции обработки информации (работы);

oдокументы (стрелки, arrow), объекты, сотрудников или отделы, которые учавствуют в обработке информации;

Соседние файлы в папке ИСУП

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

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

Во-первых, это ошибки, которые BPwin выявить не в состоянии. Например, синтаксис IDEF0 требует, чтобы имя действия было выражено отглагольным существительным или глагольной формой, выражающей действие («Просмотр графических файлов», «Выбор каталога», «Изменение масштаба», «Печать» и т.д.), а имя стрелки должно быть выражено существительным («Имя файла», «Изображение», «Данные от пользователя» и т.д.). BPwin не позволяет анализировать синтаксис естественного языка (английского и русского) и смысл имен объектов и поэтому игнорирует ошибки этого типа. Выявление таких ошибок — ручная работа, которая ложится на плечи аналитиков и должна контролироваться руководителем проекта.

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

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

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

Рис. 17.28. Диалог задания параметров отчета по синтаксическим ошибкам модели (Model Consistency Report)

Опции влияют на то, будет ли BPwin проверять у каждого функционального блока наличие управляющих стрелок (Report Activities Without Control Arrows) и стрелок выхода (Report Activities Without Output Arrows).

Отчет генерируется автоматически при нажатии кнопок предварительного просмотра Preview, печати Print или сохранения в текстовом файле Report.

Список ошибок может содержать, например, неименованные действия и стрелки (unnamed activity, unnamed arrow), несвязанные стрелки (unconnected border arrow), неразрешенные стрелки (unresolved (square tunneled) arrow connections), действия, не имеющие, по крайней мере, одной стрелки выхода и одной стрелки управления (Activity «Просмотр графических файлов» has no Control, Activity «Просмотр графических файлов» has no Output), и т.д.

Пример отчета Model Consistency Report приведен на рис. 17.29.

Рис. 17.29. Отчет по синтаксическим ошибкам

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

BPWin позволяет создавать следующие типы отчетов:

отчет по модели (Model Report) — включает в себя всю информацию о модели, созданной в BPWin (IDEF0, IDEF3 или DFD);
отчет о диаграмме (Diagram Report) — включает в себя информацию обо всех объектах, входящих в активную диаграмму BPWin;
отчет об объектах диаграммы (Diagram Object Report) — содержит полный список объектов, таких, как работы, хранилища, внешние ссылки, с указанием их свойств;
отчет о стоимостях работ (Activity Cost Report) — содержит данные о стоимостях работ и стоимостных центрах модели;
отчет о стрелках (Arrow Report) — включает в себя информацию о стрелках и связях модели;
отчет об использовании данных (Data Usage Report) — содержит информацию о таблицах БД, сущностях и атрибутах, сопоставленных с работами модели, а также действия, которые могут быть произведены над ними;
отчет согласованности с методологией (Model Consistency Report) -показывает насколько активная IDEFO-модель соответствует выбранной методологии.

Вышеперечисленные отчеты вызываются выбором -соответствующего подпункта из меню Reports главного окна. При этом открывается диалоговое окно для задания параметров формируемого отчета.

Каждый полученный отчет может быть открыт в режиме просмотра (кнопка Preview), распечатан (кнопка Print) или сохранен в файл (кнопка Report).

Создание отчета по модели

1. Откройте модель, по которой вы собираетесь создавать отчет.

2. Выберите Model Report из меню Report главного окна. При этом откроется диалог отчета по модели.

3. Установите в открывшемся окне опции согласно пунктам, которые будут включены в отчет. Порядок включения отображается рядом с флажком.

Model Name — название модели.
Definition — цель бизнес-процессов модели.
Scope — предметная область модели.
View point — точка зрения на модель.
Time frame — временные рамки модели.
Status — степень готовности модели.
Purpose — цель создания модели.
Source — источник, на основании которого создается модель.
Author name — автор модели.
Creation date — дата создания.
System last revision date — дата последнего просмотра в системе.
User last revision date — дата последнего просмотра пользователем.

4. Выберите форму представления отчета (Preview, Print, Report).

Создание отчета по диаграмме

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

Для диаграмм IDEF0 параметры задаются в рамках Activity options и Link options. Параметры в других рамках не имеют смысла. Например, группа параметров для хранилищ данных (Data Store) не имеет смысла для IDEF0-диаграмм.

Для диаграмм IDEF3 параметры задаются в рамках Activity Options, Link Options, Junction Options и Referent Options.

Для DFD-диаграмм — в рамках Activity Options, Link Options, Data store Options и External Options.

Создание отчета состоит из следующих действий:

1. Откройте диаграмму, по которой хотите создать отчет.

2. Выберите Diagram Report из меню Report, открыв диалог создания отчета по диаграмме.

3. В открывшемся окне располагаются списки свойств объектов, сгруппированные в шесть рамок:

Activity Options — свойства работ.
Data store Options — свойства хранилищ данных.
External Options — свойства внешних ссылок.
Link Options — свойства связей (стрелок).
Junction Options — свойства перекрестков.
Referent Options — справочная информация.

Включение кнопки, расположенной рядом со свойством, помещает его в отчет.

4. Выберите форму представления отчета (Preview, Print, Report).

Создание отчета об объектах диаграммы

Аналогично предыдущему отчету устанавливаемые опции должны соответствовать методологии диаграммы.

Для IDEF0-диаграмм выберите опцию Activities, которая включает в отчет свойства работ.
Для IDEFS-диаграмм можно выбрать одну или несколько опций: Activities — включает в отчет свойства работ, Data stores — включает в от чет свойства хранилищ данных, External reference — включает в отчет свойства объектов внешних ссылок.
Для диаграмм DFD можно выбрать опцию Activities, которая сформирует отчет по свойствам работ (информационным процессам).

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

1. Откройте диаграмму, по которой хотите создать отчет.

2. Выберите пункт Diagram Object Report из меню Report. С помощью ниспадающего списка Standard Reports можно выбрать название стандартного отчета, настройки которого были сохранены ранее. В рамках Activity Options и Arrow Options задается соответственно перечень свойств работ и стрелок, включаемых в отчет. Формат от чета задается в рамке Report Format.

Отчет можно создавать по всем декомпозированным диаграммам определенной работы, которая задается в ниспадающем списке Start From Activity. Глубина декомпозиции задается в поле Number of Levels. Способы упорядочения работ и стрелок в отчете указываются в рамках Activity Ordering и Arrow ordering.

3. Выберите способ представления отчета (Preview, Print, Report).

Создание отчета по стрелкам

Создание отчета по стрелкам производится по следующему алгоритму:

1. Откройте диаграмму, по которой хотите создать отчет.

2. Выберите из меню Report пункт Arrow Report. При этом откроется диалоговое окно отчета по стрелкам.

Состав и функции этого окна аналогичны остальным отчетам. В рамках Arrow Report Dictionary (Основные свойства стрелок), Source/Dest (Начало и конец стрелок), Arrow Bundle (Разветвления и слияния стрелок) расположены опции, каждая из которых соответствует одному из свойств стрелок. Установка такой опции помещает соответствующее свойство стрелки в отчет.

Опция Diagram Arrow определяет состав отчета. Если установить эту опцию, то в отчет будут включены стрелки активной диаграммы. Если сбросить — то в отчет включаются все стрелки на всех диаграммах открытой модели.

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

3. Выберите способ представления отчета (Preview, Print, Report).

Создание отчета согласованности с методологией

Данный тип отчета фактически позволяет выявить синтаксические ошибки в моделях IDEFO, которые подразделяются на три типа:

1. Невыявляемые ошибки. К данному типу ошибок относятся неправильные наименования объектов.

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

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

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

Стандартные отчеты

Для отчетов об объектах диаграммы, о стоимостях работ, о стрелках, об использовании данных можно формировать так называемые стандартные отчеты. Стандартные отчеты представляют собой совокупность на строек, сохраненных под определенным именем. Каждый из выше перечисленных отчетов имеет свои стандартные отчеты по умолчанию. Например отчет о стрелках имеет стандартный отчет Arrow Definition/Note.

При вызове стандартного отчет» в диалоговом окне восстанавливают ся сохраненные в нем опции. Например, если в диалоговом окне отчет о стрелках выбрать в списке Standard Reports стандартный отчет Аггоч Definition/Note, то установятся опции Arrow Name, Definition, Note, Diagra: Arrows, Fixed Columns, Header, Merge и Remove Special Char.

Помимо существующих стандартных отчетов можно создавать новые Для этого в диалоговом окне отчета установите все необходимые опцш введите имя стандартного отчета в рамке Standard Report и нажмите New Установленные параметры сохранятся под введенным именем.

Пример

В BPWin все отчеты, кроме отчета согласованности с методологией носят информационный характер, позволяя получить объекты модели и свойства. Отчет согласованности с методологией позволяет находить ошиС ки в моделях, поэтому является наиболее важным изо всех отчетов, испол! зуемых при анализе моделей.

Рассмотрим, что выдает этот отчет по диаграммам, построенным в предыдущих лабораторных работах.

Для диаграммы «Обслуживание клиента системы», содержащей IDEF0-и DFD-диаграммы, использованные для описания работы «Выполнение запроса», отчет содержит следующую запись:

Model Inconsistencies:

Diagram A1: Определение уровня доступа в систему
Activity «Определение категории пользователя» has no Control

Diagram A3: Изменение базы данных
Activity «Проверка целостности базы данных» has no Control

Отчет указал на наличие двух ошибок:

1. На диаграмме «Определение уровня доступа в систему» работа «Определение категории пользователя» не имеет стрелки управления.

2. На диаграмме «Изменение базы данных» работа «Проверка целостности базы данных» также не имеет стрелки управления.

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

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

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

Практическое занятие №3

Тема:
Составление
отчетов в пакете BPwin.

Цель: —
изучить основные способы создания отчетов в пакете BPwin

Вид
работы: групповой

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

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

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

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

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

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

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

DataUsage
Report. Отчет о результатах связывания модели процессов и модели данных. (Будет
рассмотрен ниже.)

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

Ход
работы

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 разделяются на три типа:

во-первых, это
ошибки, которые BPwin выявить не в состоянии. BPwin не позволяет анализировать
синтаксис естественного языка (английского и русского) и смысл имен объектов и
поэтому игнорирует ошибки этого типа. Выявление таких ошибок – ручная работа;

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

третий тип ошибок
BPwin позволяет допустить, но отмечает их. Полный их список можно получить в
отчете Model Consistency Report. Это единственный неопциональный отчет в BPwin.
Список ошибок может содержать, например, неименованные работы и стрелки (unnamed
arrow, unnamed activity), несвязанные стрелки (unconnected border arrow),
неразрешенные стрелки (unresolved (square tunneled) arrow connections), работы,
не имеющие, по крайней мере, одной стрелки выхода и одной стрелки управления, и
т.д.

Раскрывающийся
список Standard Reports
позволяет выбрать один из стандартных отчетов. Стандартный отчет – это
запоминаемая комбинация переключателей, флажков и других элементов управления
диалога. Для создания собственного стандартного отчета необходимо задать опции
отчета, ввести имя отчета в поле списка выбора и щелкнуть по кнопке New.
BPwin сохраняет информацию о стандартном
отчете в файле BPWINRPT.INI.
Все определения этого файла доступны из любой модели. Единственное ограничение
– свойства, определяемые пользователем (User
Defined Properties).
Они сохраняются в виде указателя и поэтому доступны только из родной модели.
Стандартный отчет можно изменить или удалить.

Рисунок
7 — Диалог настройки отчета

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

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

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

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

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

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

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

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

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

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

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

Задания
к практическому занятию

Задание.
По
полученной модели получить основные отчеты: по дугам и блокам модели. Проанализировать
полученные отчеты.

Контрольные
вопросы и задания

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

2. По каким признакам
можно классифицировать CASE-средства?

3. По каким основным
типам классифицируются CASE-средства, какие конкретные системы им
соответствуют?

4. Какие существуют
типы отчетов в пакете BPwin, для чего каждый из них предназначен?

5. Какого рода
синтаксические ошибки выявляет пакет BPwin?

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

Источник

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

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

Рис. 17.28. Диалог задания параметров отчета по синтаксическим ошибкам модели (Model Consistency Report)

Пример отчета Model Consistency Report приведен на рис. 17.29.

Рис. 17.29. Отчет по синтаксическим ошибкам

Источник

Подборка по базе: Конспект интегрированного занятия для детей дошкольного возраста, Дипломная работа_Селезнева Юлия Валерьевна_09.06.2023.docx, Контрольная работа_культура речи.docx, Практическая работа5.5.pdf, Практическая работа № 1.docx, Курсовая работа — Калькулятор.doc, Практическая работа 1а.docx, Курсовая работа, публичное и частное право, 02.05.docx, Курсовая работа.docx, Практическая работа Племенная деятельность.doc

1.3 Составление отчетов в пакете BPwin

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

Model Report. Этот отчет включает информацию о контексте модели — имя модели, точку зрения, область, цель, имя автора, дату создания и др.
Diagram Report. Отчет по конкретной диаграмме. Включает список объектов (работ, стрелок, хранилищ данных, внешних ссылок и т.д.).
Diagram Object Report. Наиболее полный отчет по модели. Может включать полный список объектов модели (работ, стрелок с указанием их типа и др.) и свойства, определяемые пользователем.
Activity Cost Report. Отчет о результатах стоимостного анализа.
Arrow Report. Отчет по стрелкам. Может содержать информацию из словаря стрелок, информацию о работе-источнике, работе-назначении стрелки и информацию о разветвлении и слиянии стрелок.
Data Usage Report. Отчет о результатах связывания модели процессов и модели данных.
Model Consistency Report. Отчет, содержащий список синтаксических ошибок модели.

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

во-первых, это ошибки, которые BPwin выявить не в состоянии. BPwin не позволяет анализировать синтаксис естественного языка (английского и русского) и смысл имен объектов и поэтому игнорирует ошибки этого типа. Выявление таких ошибок — ручная работа.
ошибки второго типа BPwin просто не допускает. Например, каждая грань работы предназначена для определенного типа стрелок. BPwin просто не позволит создать на диаграмме IDEF0 внутреннюю стрелку, выходящую из левой грани работы и входящую в правую грань.
третий тип ошибок BPwin позволяет допустить, но отмечает их. Полный их список можно получить в отчете Model Consistency Report. Это единственный неопциональный отчет в BPwin. Список ошибок может содержать, например, неименованные работы и стрелки (unnamed arrow, unnamed activity), несвязанные стрелки (unconnected border arrow), неразрешенные стрелки (unresolved (square tunneled) arrow connections), работы, не имеющие по крайней мере одной стрелки выхода и одной стрелки управления, и т.д.

Раскрывающийся список Standard Reports позволяет выбрать один из стандартных отчетов. Стандартный отчет — это запоминаемая комбинация переключателей, флажков и других элементов управления диалога. Для создания собственного стандартного отчета необходимо задать опции отчета, ввести имя отчета в поле списка выбора и щелкнуть по кнопке New. BPwin сохраняет информацию о стандартном отчете в файле BPWINRPT.INI. Все определения этого файла доступны из любой модели. Единственное ограничение — свойства, определяемые пользователем (User Defined Properties). Они сохраняются в виде указателя и поэтому доступны только из родной модели. Стандартный отчет можно изменить или удалить.

Рис.7.Диалог настройки отчета

Labeled — отчеты включают метку поля, затем, в следующей строке, печатается содержимое поля;
Fixed Column — каждое поле печатается в собственной колонке;
Tab-Comma Delimited — каждое поле печатается в собственной колонке. Колонки разделяются знаком табуляции или запятыми;
DDE Table — данные передаются по DDE приложению, например MS Word или Excel;
RPTwin — отчет создается в формате Platinum RPTwin — специализированного генератора отчетов, который входит в поставку BPwin.

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

Repeating Group — детальные данные объединяются в одно поле, между значениями вставляется +.
Filled — дублирование данных для каждого заголовка группы;
Header (опция по умолчанию) — печатается заголовок группы, затем — детальная информация.

Задание.

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

Вопросы.

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

1.4 Изучение объектов DFD-диаграмм

Диаграммы потоков данных (DFD, Data Flow Diagramming) используются для описания документооборота и обработки информации. Подобно IDEF0, DFD представляет модельную систему как сеть связанных между собой работ. Их можно использовать как дополнение к модели IDEF0 для более наглядного отображения текущих операций документооборота в корпоративных системах обработки информации.

DFD описывает:

функции обработки информации (работы, activities);
документы (стрелки, arrows), объекты, сотрудников или отделы, которые участвуют в обработке информации;
внешние ссылки (external references), которые обеспечивают интерфейс с внешними объектами, находящимися за границами моделируемой системы;
таблицы для хранения документов (хранилище данных, data store).

В BPwin для построения диаграмм потоков данных используется нотация Гейна-Сарсона.
Для того чтобы дополнить модель IDEF0 диаграммой DFD, нужно в процессе декомпозиции в диалоге Activity Box Count надавить на радио-кнопку DFD. В палитре инструментов на новой диаграмме появляются кнопки:

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

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

— ссылка на другую страницу. В отличие от IDEF0 инструмент off-page reference позволяет направить стрелку на любую диаграмму (а не только на верхний уровень).

В отличие от стрелок IDEF0, которые представляют собой жесткие взаимосвязи, стрелки DFD показывают, как объекты (включая данные) двигаются от одной работы к другой. Это представление потоков совместно с хранилищами данных и внешними сущностями делает модели DFD более похожими на физические характеристики системы — движение объектов (data flow), хранение объектов (data stores), поставка и распространение объектов.

В отличие от IDEF0, где система рассматривается как взаимосвязанные работы, DFD рассматривает систему как совокупность предметов. Контекстная диаграмма часто включает работы и внешние ссылки. Работы обычно именуются по названию системы, например «Система обработки информации». Включение внешних ссылок в контекстную диаграмму не отменяет требования методологии четко определить цель, область и единую точку зрения на моделируемую систему.

Работы.

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

Стрелки (Потоки данных).

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

Хранилище данных.

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

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

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

Логическая модель строится как совокупность работ и документирования того, что эти работы должны делать.

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

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

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

Нумерация объектов.

В DFD номер каждой работы может включать префикс, номер родительской работы (А) и номер объекта. Номер объекта — это уникальный номер работы на диаграмме. Например, работа может иметь номер А.12.4. Уникальный номер имеют хранилища данных и внешние сущности независимо от их расположения на диаграмме. Каждое хранилище данных имеет префикс D и уникальный номер, например D5. Каждая внешняя сущность имеет префикс Е и уникальный номер, например Е4.

Задание.

По заданному отделу построить диаграмму верхнего уровня взаимодействия отдела с внешними данными.

Вопросы.

Какие CASE-средства наиболее известны на российском рынке программного обеспечения?
Каковы основные функции наиболее известного российского CASE-средства функционального моделирования?
В чем особенности CASE-средства Rational Rose?
В чем особенности DFD-диаграмм, что в них описывается?
В чем особенности объектов DFD-диаграмм?
В чем различия функциональной, логической, физической моделей, а также моделей окружения и поведения?

Содержание работы:

Создание в среде BPwin новой модели в нотации IDEF0. Разработка контекстной диаграммы модели. Развитие модели. Декомпозиция контекстной диаграммы. Разработка функциональной модели системы c глубиной декомпозиции 3 уровня.

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

1. Создадим новую модель.

2. Разработаем диаграмму верхнего уровня модели (контекстную).

3. Определим функции, на которые может быть разложена функция, обозначенная на контекстной странице модели. Это:

подготовка участка под строительство;
строительство и обустройство дома;
обустройство участка.

4. Создадим диаграмму декомпозиции первого уровня. Для этого:

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

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

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

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

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

8. Аналогично создадим диаграммы декомпозиции для функциональных блоков А1, А2, А3.

Достигнутый результат.

В результате работы средствами редактора BPwin создана трехуровневая функциональная модель системы в нотации IDEF0.
Контрольное задание

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

Задание:

1. Создайте новую модель.

2. Разработайте контекстную страницу модели.

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

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

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

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

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

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

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

Источник

Рекомендации к ЛР№ 3. (раздел 3). «Составление отчетов в пакете BPwin»

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

Model Report. Этот отчет включает информацию о контексте модели — имя модели, точку зрения, область, цель, имя автора, дату создания и др.
Diagram Report. Отчет по конкретной диаграмме. Включает список объектов (работ, стрелок, хранилищ данных, внешних ссылок и т.д.).
Diagram Object Report. Наиболее полный отчет по модели. Может включать полный список объектов модели (работ, стрелок с указанием их типа и др.) и свойства, определяемые пользователем.
Activity Cost Report. Отчет о результатах стоимостного анализа.
Arrow Report. Отчет по стрелкам. Может содержать информацию из словаря стрелок, информацию о работе-источнике, работе-назначении стрелки и информацию о разветвлении и слиянии стрелок.
Data Usage Report. Отчет о результатах связывания модели процессов и модели данных.
Model Consistency Report. Отчет, содержащий список синтаксических ошибок модели.

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

во-первых, это ошибки, которые BPwin выявить не в состоянии. BPwin не позволяет анализировать синтаксис естественного языка (английского и русского) и смысл имен объектов и поэтому игнорирует ошибки этого типа. Выявление таких ошибок — ручная работа.
ошибки второго типа BPwin просто не допускает. Например, каждая грань работы предназначена для определенного типа стрелок. BPwin просто не позволит создать на диаграмме IDEF0 внутреннюю стрелку, выходящую из левой грани работы и входящую в правую грань.
третий тип ошибок BPwin позволяет допустить, но отмечает их. Полный их список можно получить в отчете Model Consistency Report. Это единственный неопциональный отчет в BPwin. Список ошибок может содержать, например, неименованные работы и стрелки (unnamed arrow, unnamed activity), несвязанные стрелки (unconnected border arrow), неразрешенные стрелки (unresolved (square tunneled) arrow connections), работы, не имеющие по крайней мере одной стрелки выхода и одной стрелки управления, и т.д.

При выборе пункта меню, который соответствует какому-либо отчету, появляется диалог настройки отчета. Для каждого из семи типов отчетов он выглядит по-своему. Рассмотрим типичный диалог Arrow Report (рис.7).
Раскрывающийся список Standard Reports позволяет выбрать один из стандартных отчетов. Стандартный отчет — это запоминаемая комбинация переключателей, флажков и других элементов управления диалога. Для создания собственного стандартного отчета необходимо задать опции отчета, ввести имя отчета в поле списка выбора и щелкнуть по кнопке New. BPwin сохраняет информацию о стандартном отчете в файле BPWINRPT.INI. Все определения этого файла доступны из любой модели. Единственное ограничение — свойства, определяемые пользователем (User Defined Properties). Они сохраняются в виде указателя и поэтому доступны только из родной модели. Стандартный отчет можно изменить или удалить.

Рис.7.Диалог настройки отчета

Labeled — отчеты включают метку поля, затем, в следующей строке, печатается содержимое поля;
Fixed Column — каждое поле печатается в собственной колонке;
Tab-Comma Delimited — каждое поле печатается в собственной колонке. Колонки разделяются знаком табуляции или запятыми;
DDE Table — данные передаются по DDE приложению, например MS Word или Excel;
RPTwin — отчет создается в формате Platinum RPTwin — специализированного генератора отчетов, который входит в поставку BPwin.

Repeating Group — детальные данные объединяются в одно поле, между значениями вставляется +.
Filled — дублирование данных для каждого заголовка группы;
Header (опция по умолчанию) — печатается заголовок группы, затем — детальная информация.

Задание.

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

Вопросы.

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

Трудоемкость – 4 часа

Рекомендации к ЛР№ 4. (раздел 5). «Изучение объектов DFD-диаграмм»

функции обработки информации (работы, activities);
документы (стрелки, arrows), объекты, сотрудников или отделы, которые участвуют в обработке информации;
внешние ссылки (external references), которые обеспечивают интерфейс с внешними объектами, находящимися за границами моделируемой системы;
таблицы для хранения документов (хранилище данных, data store).

— добавить в диаграмму внешнюю ссылку. Внешняя ссылка является источником или приемником данных извне модели;
— добавить в диаграмму хранилище данных. Хранилище данных позволяет описать данные, которые необходимо сохранить в памяти прежде, чем использовать в работах;
— ссылка на другую страницу. В отличие от IDEF0 инструмент off-page reference позволяет направить стрелку на любую диаграмму (а не только на верхний уровень).
В отличие от стрелок IDEF0, которые представляют собой жесткие взаимосвязи, стрелки DFD показывают, как объекты (включая данные) двигаются от одной работы к другой. Это представление потоков совместно с хранилищами данных и внешними сущностями делает модели DFD более похожими на физические характеристики системы — движение объектов (data flow), хранение объектов (data stores), поставка и распространение объектов.
В отличие от IDEF0, где система рассматривается как взаимосвязанные работы, DFD рассматривает систему как совокупность предметов. Контекстная диаграмма часто включает работы и внешние ссылки. Работы обычно именуются по названию системы, например «Система обработки информации». Включение внешних ссылок в контекстную диаграмму не отменяет требования методологии четко определить цель, область и единую точку зрения на моделируемую систему.

Работы.

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

Стрелки (Потоки данных).

Хранилище данных.

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

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

Диаграммы DFD могут быть построены с использованием традиционного структурного анализа, подобно тому, как строятся диаграммы IDEF0. Сначала строится физическая модель, отображающая текущее состояние дел. Затем эта модель преобразуется в логическую модель, которая отображает требования к существующей системе. После этого строится модель, отображающая требования к будущей системе. И наконец, строится физическая модель, на основе которой должна быть построена новая система.
Альтернативным является подход, популярный при создании программного обеспечения, называемый событийным разделением, в котором различные диаграммы DFD выстраивают модель системы.
Логическая модель строится как совокупность работ и документирования того, что эти работы должны делать.
Модель окружения описывает систему как объект, взаимодействующий с событиями из внешних сущностей. Модель окружения обычно содержит описание цели системы, одну контекстную диаграмму и список событий. Контекстная диаграмма содержит один прямоугольник работы, изображающий систему в целом, и внешние сущности, с которыми система взаимодействует.
Наконец, модель поведения показывает, как система обрабатывает события. Эта модель состоит из одной диаграммы, в которой каждый прямоугольник изображает каждое событие из модели окружения. Хранилища могут быть добавлены для моделирования данных, которые необходимо запоминать между событиями. Потоки добавляются для связи с другими элементами, и диаграмма проверяется с точки зрения соответствия модели окружения.
Полученные диаграммы могут быть преобразованы с целью более наглядного представления системы, в частности, работы на диаграммах могут быть декомпозированы.

Нумерация объектов.

Задание.

По заданному отделу построить диаграмму верхнего уровня взаимодействия отдела с внешними данными.

Вопросы.

Какие CASE-средства наиболее известны на российском рынке программного обеспечения?
Каковы основные функции наиболее известного российского CASE-средства функционального моделирования?
В чем особенности CASE-средства Rational Rose?
В чем особенности DFD-диаграмм, что в них описывается?
В чем особенности объектов DFD-диаграмм?
В чем различия функциональной, логической, физической моделей, а также моделей окружения и поведения?

Трудоемкость – 4 часа

Рекомендации к ЛР№ 5. (раздел 6). «Изучение основных функций пакета ERwin. Создание логической модели»

ERwin — средство концептуального моделирования БД, использующее методологию IDEF1X. ERwin реализует проектирование схемы БД, генерацию ее описания на языке целевой СУБД (ORACLE, Informix, Ingres, Sybase, DB/2, Microsoft SQL Server, Progress и др.) и реинжиниринг существующей БД. ERwin выпускается в нескольких различных конфигурациях, ориентированных на наиболее распространенные средства разработки приложений 4GL. Версия ERwin/OPEN полностью совместима со средствами разработки приложений PowerBuilder и SQLWindows и позволяет экспортировать описание спроектированной БД непосредственно в репозитории данных средств.
Для ряда средств разработки приложений (PowerBuilder, SQLWindows, Delphi, Visual Basic) выполняется генерация форм и прототипов приложений.
Сетевая версия ERwin ModelMart обеспечивает согласованное проектирование БД и приложений в рабочей группе.

Основные получаемые преимущества:

существенное повышение скорости разработки за счет мощного редактора диаграмм, автоматической генерации базы данных, автоматической подготовки документации;
нет необходимости ручной подготовки SQL-предложений для создания базы данных;
возможность легко вносить изменения в модель при разработке и расширении системы;
возможность автоматической подготовки отчетов по базе данных; важно, что эти отчеты всегда в точности соответствуют реальной структуре БД;
разработчики прикладного программного обеспечения снабжены удобными в работе диаграммами;
тесная интеграция со средствами 4GL позволяет уже на стадии информационного моделирования задавать отображение данных в приложениях;
обратное проектирование позволяет документировать и вносить изменения в существующие информационные системы;
поддержка однопользовательских СУБД позволяет использовать для персональных систем современные технологии, что значительно упрощает переход от настольных систем к системам в технологии клиент-сервер (upsizing).

Построение моделей в ERwin

Возможны две точки зрения на информационную модель и, соответственно, два уровня модели. Первый — логический уровень (точка зрения пользователя) означает прямое отображение фактов из реальной жизни. Например, люди, столы, отделы, собаки и компьютеры являются реальными объектами. Они именуются на естественном языке, с любыми разделителями слов (пробелы, запятые и т.д.). На физическом уровне модели рассматривается использование конкретной СУБД, определяются типы данных (например, целое или вещественное число), индексы для таблиц.
ERwin предоставляет возможности создавать и управлять этими двумя различными уровнями представления одной диаграммы (модели), равно как и иметь много вариантов отображения на каждом уровне. Термин «логический уровень» в ERwin соответствует концептуальной модели.

Этапы построения информационной модели:

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

Erwin создает визуальное представление (модель данных) для решаемой задачи. Это представление может использоваться для детального анализа, уточнения и распространения документации, необходимой в цикле разработки. Однако ERwin далеко не только инструмент для рисования. ERwin автоматически создает базу данных (таблицы, индексы, хранимые процедуры, триггеры для обеспечения ссылочной целостности и другие объекты, необходимые для управления данными).

Создание сущности.

Для внесения сущности в модель необходимо щелкнуть по кнопке сущности на панели инструментов (Erwin Toolbox) , затем — по тому месту на диаграмме, где необходимо расположить новую сущность. Щелкнув правой кнопкой мыши по сущности и выбрав из всплывающего меню пункт Entity Editor, можно вызвать диалог Entity Editor, в котором определяются имя, описание и комментарии сущности.
Каждая сущность должна быть полностью определена с помощью текстового описания в закладке Definition. Эти определения полезны как на логическом уровне, поскольку позволяют понять, что это за объект, так и на физическом уровне, поскольку их можно экспортировать как часть схемы и использовать в реальной БД (CREATE COMMENT on entity_name). Закладки Note, Note2, Note3, UDP (User Defined Properties — Свойства, определенные пользователем) служат для внесения дополнительных комментариев и определений к сущности.
В закладке Icon каждой сущности можно поставить в соответствие изображение, которое будет отображаться в режиме просмотра модели на уровне иконок и изображение, которое будет отображаться на всех других уровнях.
Закладка UDP диалога Entity Editor служит для определения свойств, определяемых пользователем (User — Defined Properties). При нажатии на кнопку этой закладки вызывается диалог User — Defined Property Editor (также вызывается из меню Edit/UDPs). В нем необходимо указать вид объекта, для которого заводится UDP (диаграмма в целом, сущность, атрибут и т.д.) и тип данных. Для внесения нового свойства следует щелкнуть в таблице по кнопке и внести имя, тип данных, значение по умолчанию и определение.

Создание атрибутов.

Для описания атрибутов следует, щелкнув правой кнопкой по сущности, выбрать в появившемся меню пункт Attribute Editor. Появится диалог Attribute Editor.
Если щелкнуть по кнопке New, то в появившемся диалоге New Attribute можно указать имя атрибута, имя соответствующей ему в физической модели колонки и домен. Домен атрибута будет использоваться при определении типа колонки на уровне физической модели.
Для атрибутов первичного ключа в закладке General диалога Attribute Editor необходимо сделать пометку в окне выбора Primary Key.
Закладки Definition, Note и UDP несут те же функции, что и при определении сущности, но на уровне атрибутов.
Для большей наглядности диаграммы каждый атрибут можно связать с иконкой. Это можно сделать при помощи списка выбора Icon в закладке General.
Очень важно дать атрибуту правильное имя. Атрибуты должны именоваться в единственном числе и иметь четкое смысловое значение.
Согласно синтаксису IDEF1X, имя атрибута должно быть уникальным в рамках модели (а не только в рамках сущности!). По умолчанию при попытке внесения уже существующего имени атрибута ERwin переименовывает его. Например, если атрибут Комментарий уже существует в модели, другой атрибут (в другой сущности) будет назван Комментарий/2, затем Комментарий/3 и т.д.
При переносе атрибутов внутри и между сущностями можно воспользоваться техникой drag&drop, выбрав кнопку в палитре инструментов.

Создание связи.

Для создания новой связи следует выбрать идентифицирующую или неидентифицирующую связь в палитре инструментов (ERwin Toolbox), щелкнуть сначала по родительской, а затем по дочерней сущности.
В палитре инструментов кнопка соответствует идентифицирующей связи, кнопка связи многие-ко-многим и кнопка соответствует неидентифицирующей связи. Для редактирования свойств связи следует щелкнуть правой кнопкой мыши по связи и выбрать на контекстном меню пункт Relationship Editor.
В закладке General появившегося диалога можно задать мощность, имя и тип связи.Мощность связи (Cardinality) — служит для обозначения отношения числа экземпляров родительской сущности к числу экземпляров дочерней.
Различают четыре типа мощности:
общий случай, когда одному экземпляру родительской сущности соответствуют 0, 1 или много экземпляров дочерней сущности, не помечается каким-либо символом;
символом P помечается случай, когда одному экземпляру родительской сущности соответствуют 1 или много экземпляров дочерней сущности (исключено нулевое значение);
символом Z помечается случай, когда одному экземпляру родительской сущности соответствуют 0 или 1 экземпляр дочерней сущности (исключены множественные значения);
цифрой помечается случай, когда одному экземпляру родительской сущности соответствует заранее заданное число экземпляров дочерней сущности.
По умолчанию символ, обозначающий мощность связи, не показывается на диаграмме. Для отображения имени следует в контекстном меню, которое появляется, если щелкнуть правой кнопкой мыши по любому месту диаграммы, не занятому объектами модели, выбрать пункт Display Options/Relationship и затем включить опцию Cardinality.

Тип связи (идентифицирующая/неидентифицирующая).

В IDEF1X различают зависимые и независимые сущности. Тип сущности определяется ее связью с другими сущностями. Идентифицирующая связь устанавливается между независимой (родительский конец связи) и зависимой (дочерний конец связи) сущностями. Когда рисуется идентифицирующая связь, ERwin автоматически преобразует дочернюю связь в зависимую. Зависимая сущность изображается прямоугольником со скругленными углами.
Экземпляр зависимой сущности определяется только через отношение к родительской сущности. При установлении идентифицирующей связи атрибуты первичного ключа родительской сущности автоматически переносятся в состав первичного ключа дочерней сущности. Эта операция дополнения атрибутов дочерней сущности при создании связи называется миграцией атрибутов. В дочерней сущности новые атрибуты помечаются как внешние ключи — (FK).
При установлении неидентифицирующей связи дочерняя сущность остается независимой, а атрибуты первичного ключа родительской сущности мигрируют в состав неключевых компонентов дочерней. Неидентифицирующая связь служит для связи независимых сущностей.
Идентифицирующая связь показывается на диаграмме сплошной линией с жирной точкой на дочернем конце связи, неидентифицирующая — пунктирной.
Для неидентифицирующей связи можно указать обязательность (Nulls в закладке General диалога Relationship Editor). В случае обязательной связи (No Nulls) при генерации схемы БД атрибут внешнего ключа получит признак NOT NULL, несмотря на то, что внешний ключ не войдет в состав первичного ключа дочерней сущности. В случае необязательной связи (Nulls Allowed) внешний ключ может принимать значение NULL. Необязательная неидентифицирующая связь помечается прозрачным ромбом со стороны родительской сущности

Источник