Самостоятельная работа по теме Анализ предметной области процесса автоматизации

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

Тема: Анализ предметной области процесса автоматизации.

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

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

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

1. Диаграммы потоков данных (DataFlowDiagrams)

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

DFD описывает:

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

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

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

•        таблицы для хранения документов (хранилиш;а данных, datastore).

Для построения диаграмм DFD в BPWin используется нотация Гейна - Сарсона.

Таблица №1

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

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

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

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

Рисунок 11 - Внешняя сущность

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

Рисунок 12 - Activity Box Count

2. Диаграммы IDEF3

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

Цель IDEF3 - дать аналитикам описание последовательности выполнения процессов, а также объектов, участвующих совместно в одном процессе.

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

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

Диаграммы

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

Единицы работы - UnitofWork (UOW), также называемые работами, являются центральными компонентами модели. В IDEF3 работы изображаются прямоугольниками и имеют имя, обозначающее процесс действия и номер (идентификатор). В имя обычно включается основной результат работы (например, приготовление обеда).

Связи

Показывают взаимоотношения работ. Все связи в IDEF3 являются однонаправленными .

Старшая (Precedence) линия - сплошная линия (), связывающая единица работ. Рисуется слева направо или сверху вниз. Показывает, что работа-источник должна закончиться прежде, чем работа-цель начнется.

Линия отношения (RelationLink) - пунктирная линия (), использующаяся для изображения связей между единицами работ, а также между единицами работ и объектами ссылок.

Потоки объектов (ObjectFlow) - стрелка с двумя наконечниками

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

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

Различают перекрестки для слияния (Fan-inJunction) и разветвления (FanoutJunction) стрелок. Перекресток не может использоваться одновременно для слияния и для разветвления. Для внесения перекрестка служит кнопка .

Таблица №2

Типы перекрестков

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

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

Таблица №3

Типы объектов-ссылок

3. Пример

3.1. Диаграммы DFD

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

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

Рисунок 13 - DFD-декомпозиция работы «Выполнение запроса»

Согласно описанию системы проведем декомпозицию полученных блоков (рис. 14 - 17).

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

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

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

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

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

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

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

Получим второй вариант диаграммы (рис. 17).

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

(вариант 2)

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

(вариант 2)

Проведем анализ вариантов диаграммы «Выполнение запроса», изображенных на рис. 13 и рис. 19. Во втором варианте сократилось число блоков, упростив диаграмму.

(вариант 2)

3.2. Диаграммы IDEF3

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

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

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

(вариант 3)

1. Разработка технического задания.

(a) Составление технического задания.

(b) Утверждение технического задания.

2. Анализ.

(a) Определение объектов системы и их атрибутов.

b)  Определение категорий пользователей.

(c) Создание запросов к системе.

3. Разработка модульной структуры.

(a)  Разработка модульной структуры всей системы.

 (b) Разработка модульной структуры подсистемы обработки запросов, определения категории пользователей.

 (c) Разработка модульной структуры подсистемы экспертных оценок.

(d)             Разработка модульной структуры подсистемы профессиональных и психологических тестов.

 (e)  Разработка модульной структуры контроля успеваемости студентов.

4. Проектирование БД.

(а) Проектирование логической структуры БД.

(b) Проектирование физической структуры БД.

 (c) Определение взаимосвязей между БД.

(d) Выбор СУБД.

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

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

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

Рисунок 22 - Декомпозиция работы «Разработка технического задания»

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

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

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

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

Структура работ по подсистемам:

1. Разработка технического задания.

(a) Составление технического задания.

(b) Подписание технического задания.

2. Разработка подсистемы профессиональных и психологических тестов.

(a) Определение межсистемных соглашений.

(b) Определение объектов и их атрибутов.

(c) Определение категорий пользователей.

(d) Создание запросов к системе.

(e) Проектирование структуры БД.

3. Разработка подсистемы обработки запросов. Определение межсистемных соглашений.

(a) Определение межсистемных соглашений.

(b) Определение объектов и их атрибутов.

(c) Определение категорий пользователей.

(d) Создание запросов к системе.

(e) Проектирование структуры БД.

4. Разработка подсистемы экспертных оценок.

(a) Определение межсистемных соглашений.

(b) Определение объектов и их атрибутов.

(c) Определение категорий пользователей.

(d) Создание запросов к системе.

(e) Проектирование структуры БД.

5. Разработка подсистемы контроля успеваемости студентов.

(a) Определение межсистемных соглашений.

(b) Определение объектов и их атрибутов.

(c) Определение категорий пользователей.

(d) Создание запросов к системе.

(e) Проектирование структуры БД.

6. Разработка архитектуры всей системы.

7. Объединение подсистем.

(a) Проверка соблюдения межсистемных соглашений.

(b) Определение взаимосвязей между БД.

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

Создадим пакет диаграмм, соответствующий структуре работ «по подсистемам».

(вариант 2)

Рисунок 27 - Декомпозиция работы «Разработка технического задания» (вариант 2)

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

Рисунок 29 - Типовой фрагмент «Разработка подсистемы»

Задания

1. Дополнить созданную на предыдущей работе диаграмму IDEF0 диаграммой DFD.

2. Добавить на диаграмму DFD внешнюю сущность и хранилище данных.

3. Связать диаграмму и внешнюю сущность.

4. Связать диаграмму и хранилище.

5. Определить имя связи с внешней сущностью.

6. Создать диаграмму IDEF3, определяющую последовательность заполнения БД системы.

7. Связать работы на диаграмме.

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

9. Добавить объект-ссылку и связать его с диаграммой.

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

1. Что описывает диаграмма DFD?

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

3. Что описывает диаграмма IDEF3?

4. Перечислите составные части диаграммы DFD.

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

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

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

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

9. Перечислите составные элементы диаграмм IDEF3.

10. Что показывают связи в диаграммах IDEF3?

11. Перечислите типы стрелок в диаграммах IDEF3.

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

13. Назовите типы перекрестков.

14. Что называется объектом-ссылкой?

15. Какие бывают типы объектов-ссылок?

16. Как добавить объект-ссылку?

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