Тема:   Исследование предметной области проектируемой автоматизированной информационной системы

Структура проекта АИС

1. Титульный лист

2. Описание предметной области разрабатываемой системы (ПР №1)

3. Функциональная модель системы по методологии IDEF0 (ЛР №1)

4. Функциональная модель системы по методологии DFD (ЛР №2)

5. Описание DFD-диаграмм: составление словаря данных (ЛР №2)

6. Описание DFD-диаграмм: описание спецификации процессов (ЛР №2)

7. Отчеты (не менее 5) по моделям IDEF0 и DFD (ПР №3)

8. Расчет показателей оценки и внедрения экономической эффективности (ЛР №3)

ПРАКТИЧЕСКОЕ ЗАНЯТИЕ №1

Тема:   Исследование предметной области проектируемой автоматизированной информационной системы

Цель:    сформировать умения анализа (исследования) предметной области проектируемой АИС.

Задачи:

- изучить административную деятельность предприятия;

- представить структуру организации (предприятия) и описание решаемых задач в каждом подразделении (отделе);

- проанализировать документооборот предприятия, движение потоков информации;

- сформулировать требования к проектируемой АИС.

Оборудование: персональный компьютер, ОС Windows XP, MS Word.

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

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

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

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

Фактически разработчиками выполняется два вида работ:

− элементарное наведение порядка в организации, когда в результате обследования выявляются неэффективные процессы и структуры: предлагаются пути улучшения бизнеса компании, т.е. происходит реинжиниринг бизнес-процессов (BPR - Business Process Reengineering);

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

ПРАКТИЧЕСКОЕ ЗАНЯТИЕ №2

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

Цель:    изучение возможностей и элементов интерфейса программы и инструментария BPWin, формирование умений построения контекстных диаграмм и проведение связей.

Задачи:

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

- изучить инструментарий BPWin;

- сформировать умения построения диаграмм.

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

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

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

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

Возможности пакета BPWin

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

- С точки зрения функциональности системы. В рамках методологии IDEF0 (Integration Definition for Function Modeling) бизнес-процесс представляется в виде набора элементов-работ, которые взаимодействуют между собой, а также показывается информационные, людские и производственные ресурсы, потребляемые каждой работой.

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

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

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

Диаграммы IDEF 0

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

    проведение новой связи

    инструмент редактирования объектов

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

Диаграммы DFD

    добавление в диаграмму внешней ссылки

    добавление стрелки потока данных в диаграмму

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

    добавление хранилища данных

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

Диаграммы IDEF 3

    «старшая» связь

    перекресток

   объект ссылки

Каркас диаграммы

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

Значения полей каркаса задаются в диалоге Diagram Properties (в меню Edit/Diagram Properties).

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

Поля заголовка каркаса (слева направо)

Таблица 2

Поле	Назначение
Used At	Используется для указания на родительскую работу в случае, если на текущую диаграмму ссылались посредством стрелки вызова.
Author, Date, Rev, Project	Имя создателя диаграммы, дата создания и имя проекта, в рамках которого была создана диаграмма. REV - дата последнего редактирования диаграммы.
Notes 1 2 3 4 5 6 7 8 9 10	Используется при проведении сеанса экспертизы. Эксперт должен (на бумажной копии диаграммы) указать число замечаний, вычеркивая цифру из списка каждый раз при внесении нового замечания.
Status	Статус отображает стадию создания диаграммы, отображая все этапы публикации.
Working	Новая диаграмма, кардинально обновленная диаграмма или новый автор диаграммы.
Draft	Диаграмма прошла первичную экспертизу и готова к дальнейшему обсуждению.
Recommended	Диаграмма и все ее сопровождающие документы прошли экспертизу. Новых изменений не ожидается.
Publication	Диаграмма готова к окончательной печати и публикации.
Reader	Имя читателя (эксперта).
Date	Дата прочтения (экспертизы).
Context	Схема расположения работ в диаграмме верхнего уровня. Работа, являющаяся родительской, показана темным прямоугольником, остальные - светлым. На контекстной диаграмме (А-0) показывается надпись TOP. В левом нижнем углу показывается номер по узлу родительской диаграммы.

Поля подвала каркаса (слева направо)

Таблица 3

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

 

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

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

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

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

- диаграммы декомпозиции (в том числе диаграмма первого уровня декомпозиции А0, раскрывающая контекстную);

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

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

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

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

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

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

Вопросы для самопроверки:

1. Каковы основные функции CASE-средства BPwin?

2. Какие методологии поддерживаются BPWin?

3. Перечислите основные элементы главного окна BPWin.

4. Опишите процесс создания новой модели в BPWin.

5. Что такое каркас диаграммы? Назовите назначение полей каркаса.

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

1. Запустить программу BPWin.

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

3. Рассмотреть элементы интерфейса программы, используя теоретический материал работы.

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

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

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

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

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

9. Определить отличительные особенности функциональных моделей, построенных с применением разных методологий (IDEF0, IDEF3,DFD).

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

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

1. Что такое контекстная диаграмма?

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

3. Что называется функциональной декомпозицией?

4. Что называется диаграммой декомпозиции?

5. Какой номер имеет диаграмма декомпозиции после декомпозиции контекстной диаграммы?

6. Как добавить элемент на диаграмму?

Рекомендуемая литература: [1, 3, 7, 8, 10]

ЛАБОРАТОРНОЕ ЗАНЯТИЕ №1

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

Граничные стрелки

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

- щелкнуть по кнопке с символом стрелки  в палитре инструментов, затем перенести курсор к левой стороне экрана, пока не появится начальная штриховая полоска;

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

- вернуться в палитру инструментов и выбрать опцию редактирования стрелки ;

- щелкнуть правой кнопкой мыши на линии стрелки, во всплывающем меню выбрать пункт Name Editor и добавить имя стрелки в закладке Name диалога IDEF0 Arrow Properties.

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

Имена вновь внесенных стрелок автоматически заносятся в словарь (Arrow Dictionary).

Словарь стрелок (Arrow Dictionary) редактируется при помощи специального редактора Arrow Dictionary Editor (рис. 7), в котором определяется стрелка и вносится относящийся к ней комментарий.

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

 

Рис.7. Редактор словаря стрелок

 

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

Внутренние стрелки

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

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

 

 

Рис. 8. Связь по выходу                                Рис. 9. Связь по управлению

 

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

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

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

 

 

Рис. 10. Обратная связь по входу                Рис. 11. Обратная связь по управлению

 

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

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

 

 

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

 

Тоннелирование стрелок

Вновь внесенные граничные стрелки на диаграмме декомпозиции нижнего уровня изображаются в квадратных скобках и автоматически не появляются на диаграмме верхнего уровня. Для их «перетаскивания» наверх нужно сначала выбрать кнопку  на палитре инструментов и щелкнуть по квадратным скобкам граничной стрелки. Появится диалог Border Arrow Editor (рис.13).

Рис.13.Диалог для тоннелирования стрелок

Если щелкнуть по кнопке Resolve Border Arrow, стрелка мигрирует на диаграмму верхнего уровня, если по кнопке Change To Tunnel – стрелка будет затоннелирована и не попадет на другую диаграмму. Тоннельная стрелка изображается с круглыми скобками на конце.

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

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

ЛАБОРАТОРНОЕ ЗАНЯТИЕ №2

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

Методология DFD

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

Компонентами модели являются:

- диаграммы;

- словари данных;

- спецификации процессов.

DFD -диаграммы

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

DFD описывает:

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

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

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

- таблицы для хранения документов (хранилище данных, data store).

В BPwin для построения диаграмм потоков данных используется нотация Гейна-Сарсона (табл. 4).

Нотация Гейна – Сарсона

    Таблица 4

Компонент	Обозначение
Поток данных
Процесс
Хранилище
Внешняя сущность	имя
Система

 

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

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

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

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

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

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

Для того чтобы дополнить модель IDEF0 диаграммой DFD, нужно в процессе декомпозиции в диалоге Activity Box Count  (рис. 15) выбрать радиокнопку DFD.

 

Рис. 15

 

В палитре инструментов на новой диаграмме появляются кнопки:

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

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

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

Словарь данных

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

По типу поток может быть:

- простой или групповой;

- внутренний или внешний;

- поток данных или управления;

- непрерывный или дискретный.

Атрибуты потока данных включают:

- имена-синонимы потока данных в соответствии с узлами изменения имени;

- БНФ- определение в случае группового потока;

- единицы измерения потока;

- диапазон значений для непрерывного потока;

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

- список номеров диаграмм, в которых поток встречается;

- список потоков, в которые данный поток входит.

БНФ – статья используется для описания компонентов данных в потоках данных и в хранилищах.

Синтаксис БНФ- статьи:

@ БНФ=<простой оператор>! <БНФ- выражение>

где    <простой оператор> есть текстовое описание, заключенное в "/ "

<БНФ- выражение> есть выражение в форме Бэкуса- Наура, допускающее следующие операции отношений:

= - композиция из + - "И"! - "ИЛИ" () - компонент в скобках необязателен.

Примеры описания потоков:

@ИМЯ = ДАННЫЕ О КАБИНЕТАХ

@ТИП = внешний, дискретный, данных

@БНФ = /этаж + площадь + номер отдела + номер кабинета/

 

@ИМЯ = ИНФОРМАЦИЯ О КАБИНЕТАХ

@ТИП = внутренний, дискретный, данных

@БНФ = /ДАННЫЕ О КАБИНЕТАХ/

Спецификация процесса (СП)

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

Спецификация процессов содержит:

- номер и/или имя процесса;

- списки входных и выходных данных;

- тело (описание) процесса.

Методы задания спецификаций процесса:

- текстовое описание;

- структурированный естественный язык;

- таблица решений;

- дерево решений;

- визуальный язык;

- язык программирования.

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

Используются следующие структуры языка:

Конструкция выбора

Синтаксис:        ЕСЛИ <условие> ТО

ВЫПОЛНИТЬ функция 1

ИНАЧЕ

ВЫПОЛНИТЬ функция 2

КОНЕЦЕСЛИ

Итерация

Синтаксис:        ДЛЯ <условие>

ВЫПОЛНИТЬ функция

ПОКА< условие>

                  ВЫПОЛНИТЬ функция

КОНЕЦДЛЯ

КОНЕЦПОКА

При использовании структурированного естественного языка приняты следующие соглашения:

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

- ключевые слова ЕСЛИ и др. должны быть написаны заглавными буквами;

- слова или фразы, определённые в словаре данных должны быть написаны заглавными буквами.

Независимо от используемой нотации спецификация процесса должна начинаться с ключевого слова                   @СПЕЦПРОЦ#

Требуемые входные и выходные данные должны быть специфицированы следующим образом:

@ВХОД=<имя символ данных>

@ВЫХОД=<имя символа данных>

@ВХОДВЫХОД=<имя символа данных >,

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

Пример задания спецификации процесса:

 

@ВХОД = ДАННЫЕ О КАБИНЕТАХ

@ВЫХОД = ИНФОРМАЦИЯ О КАБИНЕТАХ

@СПЕЦПРОЦ А2 УЧИТЫВАТЬ КАБИЕНТ

ЕСЛИ добавить кабинет ТО

ИНФОРМАЦИЯ О КАБИНЕТАХ = ДАННЫЕ О КАБИНЕТАХ

КОНЕЦ ЕСЛИ

ЕСЛИ изменить ИНФОРМАЦИЮ О КАБИНЕТЕ ТО

ВЫПОЛНИТЬ редактировать ИНФОРМАЦИЮ О КАБИНЕТЕ

КОНЕЦ ЕСЛИ

ЕСЛИ убрать ИНФОРМАЦИЮ О КАБИНЕТЕ ТО

ВЫПОЛНИТЬ удалить ИНФОРМАЦИЮ О КАБИНЕТЕ

КОНЕЦ ЕСЛИ

 

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

Вопросы для самопроверки:

1. Как представляется функциональная модель деятельности в методологии DFD?

2. Перечислите компоненты методологии DFD.

3. Назовите, какие элементы входят в состав DFD-диаграмм?

4. В чем состоит назначение процесса?

5. Что называется внешней сущностью?

6. Что описываю хранилища?

7. Для чего предназначен словарь данных?

8. Для чего предназначены спецификации процессов?

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

Построить функциональную модель проектируемой системы с помощью CASE-средства BPWin, применяя методологию DFD: дополнить созданную диаграмму IDEF0 лабораторной работ №1 диаграммой DFD.

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

2. Показать движение информационных потоков данных между внешними сущностями и системой.

3. Декомпозировать систему на совокупность процессов.

4. Потоками данных объединить процессы системы, сохраняя при этом целостность всей системы.

5. Определить «срезы» потоков данных (накопитель данных).

6. При необходимости выполнить декомпозицию процесса.

7. Составить словарь данных.

8. Описать спецификации процессов.

9. Модель системы вставьте в отчет лабораторной работы №2.

10. После анализа предметной области и построения функциональной модели проектируемой АИС, сформулировать постановку задачи на разработку комплекса программного обеспечения, предназначенного для автоматизации каких-либо процессов функций, организации, предприятия, отдела, структурного подразделения и т.д..

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

1. Когда и кем принимается решение о завершении процесса детализации процесса?

2. Объясните механизм дополнения диаграммы IDEF0 диаграммой DFD.

3. Что включает в себя словарь данных?

4. Как определить, что поток данных имеет тип – внутренний?

5. Как определить, что поток данных имеет тип – составной?

6. Для каких элементов DFD-диаграмм необходима спецификация?

7. Что включает в себя спецификация процессов?

8. Можно ли применять 2 структуры естественного языка для составления спецификации одного процесса?

Рекомендуемая литература: [1, 2, 3, 4, 7, 8, 10]

ПРАКТИЧЕСКОЕ ЗАНЯТИЕ №3

Тема:   Отчеты в BPWin

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

Задачи:

- изучить виды отчетов;

- рассмотреть способы создания отчетов;

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

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

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

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

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

Виды отчетов

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

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

- отчет по модели (Model Report) – включает в себя всю информацию о модели, созданной в BPWin (IDEF0, IDEF3 или DFD);

- отчет о диаграмме (Diagram Report) – включает в себя информацию обо всех объектах, входящих в активную диаграмму BPWin;

- отчет об объектах диаграммы (Diagram Object Report) – содержит полный список объектов, таких, как работы, хранилища, внешние ссылки, с указанием их свойств;

- отчет о стоимостях работ (Activity Cost Report) – содержит данные о стоимостях работ и стоимостных центрах модели;

- отчет о стрелках (Arrow Report) – включает в себя информацию о стрелках и связях модели;

- отчет об использовании данных (Data Usage Report) – содержит информацию о таблицах БД, сущностях и атрибутах, сопоставленных с работами модели, а также действия, которые могут быть произведены над ними;

- отчет согласованности с методологией (Model Consistency Report) – показывает насколько активная модель соответствует выбранной методологии, т.е. показывает список синтаксических ошибок модели

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

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

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

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

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

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

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

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

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

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

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