close

Вход

Забыли?

вход по аккаунту

?

РўР Р Р DFD 2 (2)

код для вставкиСкачать

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ
Брянский государственный технический университет Утверждаю
Ректор университета
__________А.В. Лагерев
"__"________ 2010 г.
ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
МОДЕЛИРОВАНИЕ ПОТОКОВ ДАННЫХ В СРЕДЕ ALLFUSION PROCESS MODELER 7.2
Методические указания к выполнению лабораторной работы № 3 для студентов очной формы обучения
специальностей 230105 - "Программное обеспечение ВТ и АС" и 010503 - "Математическое обеспечение и администрирование информационных систем"
Брянск 2010
УДК 004.4 (22)
Технология разработки программного обеспечения. Моделирование потоков данных в среде AllFusion Process Modeler 7.2 [Текст]+[Электронный ресурс]: методические указания к выполнению лабораторной работы № 3 для студентов очной формы обучения специальностей 230105 - "Программное обеспечение ВТ и АС" и 010503 - "Математическое обеспечение и администрирование информационных систем". - Брянск: БГТУ, 2010. - 4с. - Режим доступа: http://www.elibrary.ru
Разработал:
Д.Г. Лагерев,
к.т.н., доц.
Рекомендовано кафедрой "Информатика и программное обеспечение" БГТУ (протокол № 1 от 31.08.10)
1. ЦЕЛЬ РАБОТЫ
В современной практике анализа и проектирования программного обеспечения (ПО) широко применяются визуальные модели. Моделирование является центральным звеном деятельности по созданию качественного ПО. Для автоматизации моделирования используются программно-технологические средства специального класса - CASE-средства (Computer Aided Software Engineering). При структурном подходе для анализа и проектирования программных систем используются CASE-средства.
Целями лабораторной работы являются:
* освоение CASE-средства функционального моделирования AllFusion Process Modeler 7.2;
* изучение методологии моделирования потоков данных DFD;
* применение методологии DFD для моделирования предметной области создаваемой программной системы.
Перед выполнением лабораторной работы студент должен самостоятельно повторить лекционный материал по теме и ознакомиться с рекомендуемой литературой. Продолжительность работы - 2 часа.
2. ПОРЯДОК ВЫПОЛНЕНИЯ РАБОТЫ
1. Освоение инструментальной среды AllFusion Process Modeler 7.2.
2. Изучение основ моделирования потоков данных DFD с выполнением примера, представленного в п. 3.3.
3. Разработка модели потоков данных предметной области для программной системы по индивидуальному заданию.
4. Защита лабораторной работы.
Руководством к выполнению п. 1 и 2 является п. 3 методических указаний. Дополнительно можно воспользоваться [1].
3. ТЕОРЕТИЧЕСКИЕ СВЕДЕНИЯ
3.1. Создание модели потоков данных в Process Modeler
При разработке программной системы на этапе проектирования необходимо определить процессы, обрабатывающие информацию. Для этого используется модель потоков данных по стандарту DFD (Data Flow Diagramming) в нотации Гейна-Серсона. Стандарт содержит описание графического языка моделирования потоков данных на основе структурного подхода. Модель строится с помощью CASE-средства Process Modeler. Общее описание инструментальной среды Process Modeler приведено в [1]. Для создания модели потоков данных в Process Modeler в окне диалога следует выбрать нотацию DFD и задать имя модели. Автоматически открывается палитра инструментов, соответствующая этой нотации (рис. 1).
Рис. 1. Палитра инструментов в нотации DFD:
1 - указатель; 2 - новый процесс; 3 - поток; 4 - выноска; 5 - внешний объект; 6 - хранилище данных; 7 - текст на диаграмме; 8 - словарь; 9 - дерево диаграмм; 10 - переход к родительской диаграмме; 11 - переход к дочерним диаграммам
Процесс моделирования начинается с определения контекста, т.е. описания системы в целом. Контекст включает определение области моделирования, цели и точки зрения на модель.
Область моделирования (Scope). При определении области моделирования необходимо четко обозначить границы программной системы и уровень её детализации.
Цель моделирования (Purpose). Формулировка цели позволяет сфокусировать усилия аналитиков в нужном направлении. Пример формулирования цели: "Описать процессы создания и обработки документации для создания информационной системы".
Точка зрения (Viewpoint). Модель необходимо строить с единой точки зрения, которая должна соответствовать цели моделирования. Очевидно, что описание работы предприятия с точки зрения финансиста и технолога будет выглядеть совершенно по-разному, поэтому важно придерживаться выбранной точки зрения.
Чтобы внести область, цель и точку зрения для модели потоков данных, в Process Modeler следует выбрать пункт меню Model/Model Properties, вызывающий диалог Model Properties (рис. 2). Во вкладку Purpose следует внести цель и точку зрения, а во вкладку Definition - описание предметной области. Рис. 2. Диалог задания свойств модели
Во вкладке Sourse описываются источники информации для построения модели (например, "Опрос работников подразделений предприятия и анализ документации").
Модель программной системы по стандарту DFD определяется как иерархия упорядоченных и взаимосвязанных диаграмм потоков данных, описывающих асинхронный процесс преобразования информации от её ввода в систему до выдачи пользователю. Источники информации (внешние сущности) порождают информационные потоки (потоки данных), переносящие информацию к процессам. Процессы, в свою очередь, преобразуют информацию и порождают новые потоки, которые переносят информацию к другим процессам, хранилищам данных и потребителям информации (внешним сущностям). Чтобы получить полную модель потоков данных, следует выполнить декомпозицию процессов до уровня, на котором каждый процесс будет элементарным. Для каждого элементарного процесса пишется спецификация, которая является исходным документом при реализации программного кода.
Любой объект модели имеет контекстное меню, каждый пункт которого соответствует редактору какого-либо свойства объекта.
Модель может содержать три типа диаграмм: контекстная; декомпозиции; дерева узлов.
Контекстная диаграмма является вершиной древовидной структуры и представляет общий процесс системы (может быть подсистемой) и его взаимосвязь с внешним миром. На основе контекстной диаграммы выполняется декомпозиция системы до достижения нужного уровня подробности описания. Каждая диаграмма декомпозиции содержит блоки и стрелки. Блоки изображают процессы, а стрелки - потоки данных. Стороны блока не имеют чёткого назначения, как в стандарте IDEF0, поэтому стрелки могут подходить и выходить из любой стороны блока. Диаграмма дерева узлов показывает иерархическую зависимость между процессами.
Основными компонентами диаграмм потоков данных являются внешние сущности; процессы; потоки данных; хранилища данных.
Внешняя сущность (external referance) - это материальный объект или физическое лицо, представляющие собой источник или приемник информации, например заказчики, персонал, склад, поставщики, клиенты. Определение некоторого объекта или системы в качестве внешней сущности указывает на то, что они находятся за границей анализируемой системы. Внешние сущности изображаются в виде прямоугольников с тенью и обычно располагаются по краям диаграммы (рис.3).
Процесс (activity) представляет собой преобразование входных потоков данных в выходные в соответствии с определённым алгоритмом. Процесс изображается прямоугольником со скругленными углами и именуется в виде предложения с активным однозначным глаголом в неопределённой форме, за которым следует существительное в винительном падеже, например: "Ввести сведения о налогоплательщике", "Выдать отчет о текущих расходах" (рис. 4).
Рис.3.Внешняя сущностьРис.4. ПроцессРис.5.Хранилище данных Поток данных (data flow) определяет информацию, передаваемую из одной части системы в другую. Поток данных изображается линией, оканчивающейся стрелкой, которая показывает направление потока. Имя потока данных задается существительным, например "Данные о клиенте", "Отчетность по подоходному налогу". Между внешней сущностью и процессом можно применять двунаправленные стрелки. Для каждого потока данных в словаре необходимо хранить имя потока, его тип и атрибуты.
Хранилище данных (data store) - это абстрактное устройство (накопитель данных) для хранения информации, которую в любой момент можно поместить в хранилище и спустя некоторое время извлечь из него (рис. 5). Хранилище данных физически может быть реализовано в виде таблицы в оперативной памяти, файла на магнитном носителе, базы данных. Имя хранилища данных должно быть понятным проектировщику.
При создании новой модели (меню File/New) автоматически создаётся контекстная диаграмма с единственным процессом, изображающим программную систему в целом (рис. 6).
Для внесения имени процесса и задания его свойств следует выбрать в контекстном меню пункт Name (рис. 7).
Рис. 6. Пример контекстной диаграммы
Рис. 7. Редактор задания свойств процесса
Для создания диаграммы декомпозиции следует щелкнуть по кнопке. В открывшемся окне диалога необходимо указать нотацию DFD и выбрать количество процессов на диаграмме (рис. 8).
Рис. 8. Диалог декомпозиции диаграммы
Для обеспечения наглядности рекомендуется использовать от 3 до 6 блоков на одной диаграмме декомпозиции. Блоки на диаграммах располагаются по диагонали от левого верхнего угла к правому нижнему. Процессы нумеруются автоматически слева направо. Диагональная черта в левом верхнем углу показывает, что данный процесс не декомпозирован (рис.9).
Рис.9. Пример диаграммы декомпозиции
Граничные стрелки. Стрелки могут начинаться у границы диаграммы и заканчиваться у процесса и наоборот. Такие стрелки называются граничными. Для внесения граничной стрелки следует выбрать кнопку в палитре инструментов, перенести курсор к требуемой стороне диаграммы, пока не появится чёрная полоса, щелкнуть сначала по полосе, а затем по процессу. Для определения имени стрелки необходимо вернуться в режим редактирования (кнопка на палитре инструментов) и через контекстное меню выбрать Name (рис. 10). Имена стрелок автоматически заносятся в словарь Arrow Dictionary. Рис.10. Диалог Arrow Properties для определения имени и свойств стрелки
Несвязанные граничные стрелки (unconnected border arrow). При декомпозиции функции входящие в неё и исходящие из неё стрелки (кроме стрелок вызова) автоматически появляются на диаграмме декомпозиции (миграция стрелок), но при этом не касаются процессов. Такие стрелки называются несвязанными (рис.11). Для связывания стрелок входа необходимо перейти в режим редактирования стрелок, сначала щелкнуть по наконечнику стрелки а затем - по соответствующему процессу. Для связывания стрелок выхода необходимо щелкнуть сначала по соответствующему сегменту процесса, а затем - по стрелке.
Внутренние стрелки. Для связывания процессов между собой используются внутренние стрелки, они не касаются границы диаграммы, начинаются у одного и заканчиваются у другого процесса. Для рисования внутренней стрелки необходимо в режиме рисования стрелок щелкнуть по одному процессу и затем по другому. Рис.11. Пример несвязанных стрелок
Разветвляющиеся и сливающиеся стрелки. Одни и те же потоки данных могут быть использованы несколькими процессами. С другой стороны, потоки данных, порожденные в разных процессах, могут быть одинаковыми и в дальнейшем перерабатываться одним процессом. Для моделирования таких ситуаций используются разветвляющиеся и сливающиеся стрелки. Для разветвления стрелки нужно в режиме редактирования щелкнуть по фрагменту стрелки и по соответствующему процессу. Для слияния двух стрелок нужно в режиме редактирования сначала щелкнуть по процессу, а затем по фрагменту стрелки. Туннелирование стрелок. Вновь внесенные граничные стрелки на диаграмме декомпозиции нижнего уровня изображаются в квадратных скобках и автоматически не появляются на диаграмме верхнего уровня (рис.12). Для "перетаскивания" таких стрелок наверх нужно в контекстном меню квадратных скобок выбрать пункт Arrow Tunnel и в диалоге Border Arrow Edition отметить опцию Resolve it to border arrow (рис.13). При выборе опции Change it to resolved rounded tunnel стрелка будет туннелирована и не попадёт на диаграмму верхнего уровня. Туннельная стрелка изображается с круглыми скобками на конце. Туннелирование применяется для изображения малозначимых стрелок.
Рис.12. Неразрешенная стрелкаРис.13. Диалог Border Arrow Edition Нумерация процессов, внешних сущностей, хранилищ данных и диаграмм. Все процессы модели нумеруются с использованием префикса любой длины (по умолчанию А) и числа. Процесс контекстной диаграммы имеет номер А0. Процессы декомпозиции А0 имеют номера А1, А2, А3. Процессы декомпозиции нижнего уровня имеют номер родительской диаграммы и очередной порядковый номер, например процессы декомпозиции А3 будут иметь номера А31, А32, А33, А34 и т. д. В иерархической структуре каждый процесс может иметь один родительский и несколько дочерних процессов. Внешние сущности и хранилища данных имеют сквозную числовую нумерацию в пределах модели.
Диаграммы модели потоков данных имеют двойную нумерацию. Контекстная диаграмма всегда имеет номер А-0, а декомпозиция контекстной диаграммы - номер А0, остальные диаграммы декомпозиции имеют номера по соответствующему узлу (например, А1, А2, А21, А213). Process Modeler автоматически поддерживает нумерацию диаграмм по узлам.
Рекомендации по рисованию диаграмм. Методология DFD содержит рекомендации по рисованию диаграмм, которые облегчают чтение и экспертизу модели. Некоторые из этих правил Process Modeler поддерживает автоматически, выполнение других следует обеспечить вручную. Ниже рассматриваются основные правила:
1. Процессы должны располагаться по диагонали с левого верхнего в правый нижний угол в порядке доминирования. При добавлении новых процессов нарушать диагональное расположение не следует. Данное правило позволяет минимизировать изгибы и пересечения стрелок.
2. Если две стрелки проходят параллельно (начинаются с одной и той же грани одного процесса и заканчиваются на одной и той же грани другого процесса), то по возможности их следует объединить и назвать единым термином.
3. Следует минимизировать число пересечений, петель и поворотов стрелок. Это ручная, творческая работа.
3.2. Пример модели потоков данных
Поставлена задача: Разработать модель потоков данных для подсистемы "Абитуриент" АСУ БГТУ. Подсистема необходима для автоматизации работы с документацией в приемной комиссии университета. Используется точка зрения секретаря приёмной комиссии.
На контекстной диаграмме (рис. 14) определены базовый процесс "Работа приёмной комиссии", внешние сущности "Абитуриент" и "Руководство", а также информационные потоки между ними.
На диаграмме первого уровня (рис. 15) выполнена декомпозиция базового процесса на пять подпроцессов. На диаграммах второго уровня проведена детализация процессов "Проверить документы" (рис. 16) и "Обработать результаты экзаменов" (рис. 17).
На рис. 18 представлена диаграмма дерева узлов модели потоков данных.
Для получения полной модели потоков данных следует выполнить декомпозицию процессов до уровня, на котором каждый процесс будет элементарным.
Рис. 14. Контекстная диаграмма модели потоков данных для подсистемы "Абитуриент Рис. 15. Диаграмма первого модели потоков данных для подсистемы "Абитуриент"
Рис. 16. Диаграмма второго уровня модели потоков данных. Процесс "Проверить документы"Рис. 17. Диаграмма второго уровня модели потоков данных. Процесс "Обработать результаты экзаменов"Рис. 18. Диаграмма дерева узлов модели потоков данных4. ВАРИАНТЫ ЗАДАНИЙ
Во всех вариантах необходимо разработать функциональную модель для предметной области, которая составляет основу программной системы. Студент выполняет задание по теме, которую определяет ему преподаватель. Примеры тем:
1. Автоматизированная система "Библиотека".
2. Автоматизированная система "Видеопрокат".
3. Автоматизированная система "Автосервис".
4. Автоматизированная система "Автостоянка".
5. Автоматизированная система "Автосалон".
6. Автоматизированная система "Бассейн".
7. Автоматизированная система "Театр".
8. Автоматизированная система организации спортивных соревнований.
9. Автоматизированная система оптового склада.
10. Автоматизированная система магазина самообслуживания.
11. Автоматизированная система ателье.
12. Автоматизированная система "Электронная библиотека".
13. Автоматизированная система управления лечебными учреждениями.
14. Автоматизированная система обработки заказов.
15. Автоматизированная система салона красоты.
16. Автоматизированная система интернет-магазина.
17. Автоматизированная обучающее-контролирующая система.
18. Автоматизированная система расчёта заработной платы.
19. Система автоматического сбора и анализа информации по использованию сетевого оборудования.
20. Подсистема "Деканат" АСУ ВУЗ.
21. Подсистема "Абитуриент" АСУ ВУЗ.
5. ОФОРМЛЕНИЕ И ПОРЯДОК КОНТРОЛЯ РЕЗУЛЬТАТОВ
Результатом выполнения лабораторной работы является функциональная модель, включающая:
* предметную область, цель и точку зрения;
* контекстную диаграмму;
* диаграмму первого уровня;
* диаграммы второго уровня для всех процессов;
* дерево диаграмм.
Лабораторная работа выполняется в среде Process Modeler и сдаётся в электронном виде.
Преподаватель проверяет логическую правильность функциональной модели. При защите лабораторной работы преподаватель вправе задать вопросы по теоретической части.
6. КОНТРОЛЬНЫЕ ВОПРОСЫ
1. Перечислите основные элементы окна Process Modeler.
2. Какие методологии поддерживаются в Process Modeler?
3. Какие вкладки имеет навигатор модели Model Explorer? 4. Перечислите основные элементы модели потоков данных.
5. Какая нотация используется в среде Process Modeler для построения модели потоков данных?
6. Перечислите основные положения стандарта DFD.
7. Какую роль играют в модели потоков данных цель и точка зрения?
8. Какое количество блоков должно присутствовать на диаграмме?
9. По какому принципу выполняется декомпозиция процессов?
10. Сформулируйте правила именования процессов и потоков данных (стрелок).
11. Какие стрелки называют граничными?
12. Каково назначение разветвляющихся и сливающихся стрелок?
13. Какие стрелки называют туннельными? 14. Укажите правила нумерации диаграмм.
15. Каково назначение диаграммы дерева узлов?
СПИСОК РЕКОМЕНДУЕМОЙ ЛИТЕРАТУРЫ
1. Маклаков, С.В. Создание информационных систем с AllFusion Modeling Suite / С. В. Маклаков. - М.:Диалог-МИФИ, 2007. - 432с.
2. Черемных, С.В. Моделирование и анализ систем. I DEF-технологии: практикум / С.В. Черемных, И.О. Семенов, B.C. Ручкин. - М.: Финансы и статистика, 2005. - 192с.
3. Федотова, Д.Э. CASE-технологии: практикум / Д.Э. Федотова, Ю.Д. Семенов, К.Н. Чижик. - М.: Телеком, 2005. - 160с.
Технология разработки программного обеспечения. Моделирование потоков данных в среде AllFusion Process Modeler 7.2: методические указания к выполнению лабораторной работы № 3 для студентов очной формы обучения специальностей 230105 - "Программное обеспечение ВТ и АС" и 010503 - "Математическое обеспечение и администрирование информационных систем" ЛАГЕРЕВ ДМИТРИЙ ГРИГОРЬЕВИЧ
Научный редактор А.Г. Подвесовский
Редактор издательства Л.И. Афонина
Компьютерный набор Д.Г. Лагерев
Темплан 2010 г., п. 230
Подписано в печать 10.10.10. Формат 60х84 1/16. Бумага офсетная. Офсетная печать. Усл. печ.л. 1,32. Уч.-изд.л. 1,27. Тираж 20 экз. Заказ . Бесплатно.
Брянский государственный технический университет.
241035, Брянск, бульвар 50-летия Октября, 7, БГТУ. 58-82-49.
Лаборатория оперативной полиграфии БГТУ, ул. Институтская, 16.
2
22
Документ
Категория
Рефераты
Просмотров
41
Размер файла
286 Кб
Теги
лабораторная работа, рур, лаба, dfd, лабораторная
1/--страниц
Пожаловаться на содержимое документа