МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ Брянский государственный технический университет

Утверждаю

Ректор университета

__________А.В. Лагерев

“__”________ 2010 г.

Технология разработки программного обеспечения Моделирование потоков данных в среде allfusion process modeler 7.2

Методические указания к выполнению

лабораторной работы № 3

для студентов очной формы обучения

специальностей 230105 – «Программное обеспечение ВТ и АС» и 010503 – «Математическое обеспечение и администрирование информационных систем»

Брянск 2010

УДК 004.4 (22)

Технология разработки программного обеспечения. Моделирование потоков данных в среде AllFusion Process Modeler 7.2 [Текст]+[Электронный ресурс]: методические указания к выполнению лабораторной работы № 3 для студентов очной формы обучения специальностей 230105 – «Программное обеспечение ВТ и АС» и 010503 – «Математическое обеспечение и администрирование информационных систем». – Брянск: БГТУ, 2010. – 23с. – Режим доступа: http://www.elibrary.ru

Разработал:

Д.Г. Лагерев,

к.т.н., доц.

Рекомендовано кафедрой «Информатика и программное обеспечение» БГТУ (протокол № 1 от 31.08.10)

1. Цель работы

В современной практике анализа и проектирования программного обеспечения (ПО) широко применяются визуальные модели. Моделирование является центральным звеном деятельности по созданию качественного ПО. Для автоматизации моделирования используются программно-технологические средства специального класса – CASE-средства (Computer Aided Software Engineering). При структурном подходе для анализа и проектирования программных систем используются CASE-средства.

Целями лабораторной работы являются:

• освоение CASE-средства функционального моделирования AllFusionProcessModeler7.2;

• изучение методологии моделирования потоков данных DFD;

• применение методологии DFD для моделирования предметной области создаваемой программной системы.

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

2. Порядок выполнения работы

1. Освоение инструментальной среды AllFusionProcessModeler7.2.

2. Изучение основ моделирования потоков данных DFD с выполнением примера, представленного в п. 3.3.

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

4. Защита лабораторной работы.

Руководством к выполнению п. 1 и 2 является п. 3 методи­ческих указаний. Дополнительно можно воспользоваться [1].

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

3.1. Создание модели потоков данных в Process Modeler

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

Модель строится с помощью CASE-средстваProcessModeler. Общее описание инструментальной средыProcessModelerприведено в [1]. Для создания модели потоков данных вProcessModelerв окне диалога следует выбрать нотациюDFDи задать имя модели. Автоматически открывается палитра инструментов, соответствующая этой нотации (рис. 1).

Рис. 1. Палитра инструментов в нотации DFD:

1 – указатель; 2 – новый процесс; 3 – поток; 4 – выноска; 5 – внешний объект; 6 – хранилище данных; 7 – текст на диаграмме; 8 – словарь; 9 – дерево диаграмм; 10 – переход к родительской диаграмме; 11 – переход к дочерним диаграммам

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

Область моделирования(Scope).При определении области моделирования необходимо четко обозначить границы программной системы и уровень её детализации.

Цель моделирования (Purpose).Формулировка цели позволяет сфокусировать усилия аналитиков в нужном направлении. Пример формулирования цели: «Описать процессы создания и обработки документации для создания информационной системы».

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

Чтобы внести область, цель и точку зрения для модели потоков данных, в ProcessModelerследует выбрать пункт меню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 для определения