Практикум для выполнения лабораторных работ состоит из семнадцати лабораторных работ по дисциплинам Спецификация, архитектура и проектирование программных систем
 Скачать 2.9 Mb.
|
|
Индивидуальные задания В соответствии со своим вариантом разработать модель IDEF3, содержащую не менее трех функциональных блоков второго уровня. Выполнить детализацию одного функцио- нального блока с использованием не менее чем 3 функцио- нальных блоков. Примерный перечень индивидуальных заданий: 1. Информационная система ВУЗа. 2. Информационная система проектной организации. 3. Информационная система библиотеки. 4. Информационная система аптеки. 5. Информационная система городской телефонной сети. 6. Информационная система фотоцентра. 7. Информационная система железнодорожной пасса- жирской станции. 8. Информационная система альпинистского клуба. 9. Информационная система поликлиники. 10. Информационная система Городской Думы. 11. Информационная система рыболовной фирмы. 12. Информационная система фирмы, проводящей аук- ционы. 13. Информационная система учета успеваемости сту- дентов. 14. Информационная система учета аудиторного фонда университета. 15. Информационная система учета происшествий. 16. Информационная система учета и проведения конфе- ренций. 17. Информационная система обслуживания склада. 18. Информационная система музыкального магазина. 19. Информационная система деканат. 20. Информационная система «отдел кадров университета». Контрольные вопросы 1. В чем заключается метод моделирования IDEF3? 2. Что является основной единицей модели IDEF3? 3. Какие правила именования объектов определены для диаграмм IDEF3? 4. Какие возможные типа связей определены для диа- грамм IDEF3? 5. Какие типы соединений определены для диаграмм IDEF3? 65 Лабораторная работа 7. Построение модели потоков данных Цель работы Целями лабораторной работы являются: – изучение методологии моделирования потоков дан- ных DFD; – применение методологии DFD для моделирования предметной области создаваемой программной системы. Теоретические сведения Стандарт описания бизнес-процессов DFD — Data Flow Diagram переводится как диаграмма потоков данных. Диаграммы потоков данных показывают, как каждый процесс преобразует свои входные данные в выходные, и вы- являют отношения между этими процессами. DFD представля- ет моделируемую систему как сеть связанных работ. Основными компонентами диаграмм потоков данных яв- ляются: – внешние сущности; – процессы; – накопители данных; – потоки данных. Ход работы Создание модели потоков данных в Process Modeler При разработке программной системы на этапе проек- тирования необходимо определить процессы, обрабатываю- щие информацию. Для этого используется модель потоков данных по стандарту DFD (Data Flow Diagramming) в нотации Гейна-Серсона. Стандарт содержит описание графического языка моделирования потоков данных на основе структурного подхода. Модель строится с помощью CASE-средства Process Modeler. Общее описание инструментальной среды Process Modeler приведено в [1]. Для создания модели потоков данных в Process Modeler в окне диалога следует выбрать нотацию DFD и задать имя модели. Автоматически открывается палитра инструментов, соответствующая этой нотации (рис. 7.1). 66 Рис. 7.1. Палитра инструментов в нотации DFD: 1 — указатель; 2 — новый процесс; 3 — поток; 4 — выноска; 5 — внешний объект; 6 — хранилище данных; 7 — текст на диаграмме; 8 — словарь; 9 — дерево диаграмм; 10 — переход к родительской диаграмме; 11 — переход к дочерним диаграммам Процесс моделирования начинается с определения контек- ста, т. е. описания системы в целом. Контекст включает опреде- ление области моделирования, цели и точки зрения на модель. Область моделирования (Scope). При определении об- ласти моделирования необходимо четко обозначить границы программной системы и уровень её детализации. Цель моделирования (Purpose). Формулировка цели поз- воляет сфокусировать усилия аналитиков в нужном направле- нии. Пример формулирования цели: «Описать процессы создания и обработки документации для создания информационной си- стемы». Точка зрения (Viewpoint). Модель необходимо строить с единой точки зрения, которая должна соответствовать цели моделирования. Очевидно, что описание работы предприятия с точки зрения финансиста и технолога будет выглядеть совер- шенно по-разному, поэтому важно придерживаться выбранной точки зрения. Чтобы внести область, цель и точку зрения для модели по- токов данных, в Process Modeler следует выбрать пункт меню Model/Model Properties, вызывающий диалог Model Properties ( рис. 7.2). Во вкладку Purpose следует внести цель и точку зрения, а во вкладку Definition — описание предметной области. 67 Рис. 7.2. Диалог задания свойств модели Во вкладке Sourсe описываются источники информации для построения модели (например, «Опрос работников подраз- делений предприятия и анализ документации»). Модель про- граммной системы по стандарту DFD определяется как иерархия упорядоченных и взаимосвязанных диаграмм потоков данных, описывающих асинхронный процесс преобразования информации от её ввода в систему до выдачи пользователю. Источники информации (внешние сущности) порождают ин- формационные потоки (потоки данных), переносящие инфор- мацию к процессам. Процессы, в свою очередь, преобразуют информацию и порождают новые потоки, которые переносят информацию к другим процессам, хранилищам данных и по- требителям информации (внешним сущностям). Чтобы получить полную модель потоков данных, следует выполнить декомпозицию процессов до уровня, на котором каждый процесс будет элементарным. Для каждого элемен- тарного процесса пишется спецификация, которая является 68 исходным документом при реализации программного кода. Любой объект модели имеет контекстное меню, каждый пункт которого соответствует редактору какого-либо свойства объ- екта. Модель может содержать три типа диаграмм: контекст- ная; декомпозиции; дерева узлов. Контекстная диаграмма является вершиной древовид- ной структуры и представляет общий процесс системы (мо- жет быть подсистемой) и его взаимосвязь с внешним миром. На основе контекстной диаграммы выполняется декомпози- ция системы до достижения нужного уровня подробности описания. Каждая диаграмма декомпозиции содержит блоки и стрелки. Блоки изображают процессы, а стрелки — потоки данных. Стороны блока не имеют чёткого назначения, как в стандарте IDEF0, поэтому стрелки могут подходить и выходить из любой стороны блока. Диаграмма дерева узлов показывает иерархическую зависимость между процессами. Основными компонентами диаграмм потоков данных яв- ляются внешние сущности; процессы; потоки данных; храни- лища данных. Внешняя сущность (external referance) — это материаль- ный объект или физическое лицо, представляющие собой источ- ник или приемник информации, например заказчики, персонал, склад, поставщики, клиенты. Определение некоторого объекта или системы в качестве внешней сущности указывает на то, что они находятся за границей анализируемой системы. Внешние сущности изображаются в виде прямоугольников с тенью и обычно располагаются по краям диаграммы (рис 7.3). Рис. 7.3. Внешняя сущность Процесс (activity) представляет собой преобразование входных потоков данных в выходные в соответствии с опреде- лённым алгоритмом. Процесс изображается прямоугольником со скругленными углами и именуется в виде предложения с активным однозначным глаголом в неопределённой форме, за которым следует существительное в винительном падеже, 69 например: «Ввести сведения о налогоплательщике», «Выдать отчет о текущих расходах» (рис. 7.4). Рис. 7.4. Процесс Поток данных (data flow) определяет информацию, пе- редаваемую из одной части системы в другую. Поток данных изображается линией, оканчивающейся стрелкой, которая показывает направление потока. Имя потока данных задается существительным, например «Данные о клиенте», «Отчетность по подоходному налогу». Между внешней сущностью и процес- сом можно применять двунаправленные стрелки. Для каждого потока данных в словаре необходимо хранить имя потока, его тип и атрибуты. Хранилище данных (data store) — это абстрактное устройство (накопитель данных) для хранения информации, которую в любой момент можно поместить в хранилище и спустя некоторое время извлечь из него (рис. 7.5). Хранилище данных физически может быть реализовано в виде таблицы в оператив- ной памяти, файла на магнитном носителе, базы данных. Имя хранилища данных должно быть понятным проектировщику. Рис. 7.5. Хранилище данных При создании новой модели (меню File/New) автоматиче- ски создаётся контекстная диаграмма с единственным процес- сом, изображающим программную систему в целом (рис. 7.6). Для внесения имени процесса и задания его свойств следует выбрать в контекстном меню пункт Name (рис. 7.7). Для создания диаграммы декомпозиции следует щелк- нуть по кнопке . В открывшемся окне диалога необходимо 70 указать нотацию DFD и выбрать количество процессов на диаграмме (рис. 7.8). Рис. 7.6. Пример контекстной диаграммы Рис. 7.7. Редактор задания свойств процесса 71 Рис. 7.8. Диалог декомпозиции диаграммы Для обеспечения наглядности рекомендуется использо- вать от 3 до 6 блоков на одной диаграмме декомпозиции. Бло- ки на диаграммах располагаются по диагонали от левого верхнего угла к правому нижнему. Процессы нумеруются авто- матически слева направо. Диагональная черта в левом верхнем углу показывает, что данный процесс не декомпозирован ( рис. 7.9). Рис. 7.9. Пример диаграммы декомпозиции Граничные стрелки. Стрелки могут начинаться у грани- цы диаграммы и заканчиваться у процесса и наоборот. Такие стрелки называются граничными. Для внесения граничной стрелки следует выбрать кнопку в палитре 72 инструментов, перенести курсор к требуемой стороне диа- граммы, пока не появится чёрная полоса, щелкнуть сначала по полосе, а затем по процессу. Для определения имени стрелки необходимо вернуться в режим редактирования (кнопка на палитре инструментов) и через контекстное меню выбрать Name (рис. 7.10). Имена стрелок автоматически заносятся в словарь Arrow Dictionary. Рис. 7.10. Диалог Arrow Properties для определения имени и свойств стрелки Несвязанные граничные стрелки (unconnected border arrow). При декомпозиции функции входящие в неё и исходя- щие из неё стрелки (кроме стрелок вызова) автоматически появляются на диаграмме декомпозиции (миграция стрелок), но при этом не касаются процессов. Такие стрелки называются несвязанными (рис. 7.11). Для связывания стрелок входа необходимо перейти в ре- жим редактирования стрелок, сначала щелкнуть по наконеч- 7 3 нику стрелки, а затем — по соответствующему процессу. Для связывания стрелок выхода необходимо щелкнуть сначала по соответствующему сегменту процесса, а затем — по стрелке. Рис. 7.11. Пример несвязанных стрелок Внутренние стрелки. Для связывания процессов между собой используются внутренние стрелки, они не касаются границы диаграммы, начинаются у одного и заканчиваются у другого процесса. Для рисования внутренней стрелки необхо- димо в режиме рисования стрелок щелкнуть по одному про- цессу и затем по другому. Разветвляющиеся и сливающиеся стрелки. Одни и те же потоки данных могут быть использованы несколькими процес- сами. С другой стороны, потоки данных, порожденные в разных процессах, могут быть одинаковыми и в дальнейшем перераба- тываться одним процессом. Для моделирования таких ситуаций используются разветвляющиеся и сливающиеся стрелки. Для разветвления стрелки нужно в режиме редактирования щелк- нуть по фрагменту стрелки и по соответствующему процессу. Для слияния двух стрелок нужно в режиме редактирования сначала щелкнуть по процессу, а затем по фрагменту стрелки. Туннелирование стрелок. Вновь внесенные граничные стрелки на диаграмме декомпозиции нижнего уровня изобража- ются в квадратных скобках и автоматически не появляются на диаграмме верхнего уровня (рис. 7.12). Для «перетаскивания» таких стрелок наверх нужно в контекстном меню квадратных скобок выбрать пункт Arrow Tunnel и в диалоге Border Arrow Edition отметить опцию Resolve it to border arrow (рис. 7.13). 74 При выборе опции Change it to resolved rounded tunnel стрелка будет туннелирована и не попадёт на диаграмму верх- него уровня. Туннельная стрелка изображается с круглыми скобками на конце. Туннелирование применяется для изобра- жения малозначимых стрелок. Рис. 7.12. Неразрешенная стрелка Рис. 7.13. Диалог Border Arrow Edition Нумерация процессов, внешних сущностей, хранилищ данных и диаграмм. Все процессы модели нумеруются с ис- пользованием префикса любой длины (по умолчанию А) и числа. Процесс контекстной диаграммы имеет номер А0. Процессы декомпозиции А0 имеют номера А1, А2, А3. Процессы декомпозиции нижнего уровня имеют номер родительской диаграммы и очередной порядковый номер, например процес- сы декомпозиции А3 будут иметь номера А31, А32, А33, А34 и т. д. В иерархической структуре каждый процесс может иметь один родительский и несколько дочерних процессов. Внешние сущности и хранилища данных имеют сквозную числовую нумерацию в пределах модели. Диаграммы модели потоков данных имеют двойную нумерацию. Контекстная диаграмма всегда имеет номер А-0, а декомпозиция контекстной диа- граммы — номер А0, остальные диаграммы декомпозиции 75 имеют номера по соответствующему узлу (например, А1, А2, А21, А213). Process Modeler автоматически поддерживает ну- мерацию диаграмм по узлам. Рекомендации по рисованию диаграмм. Методология DFD содержит рекомендации по рисованию диаграмм, которые облегчают чтение и экспертизу модели. Некоторые из этих правил Process Modeler поддерживает автоматически, выпол- нение других следует обеспечить вручную. Ниже рассматриваются основные правила: 1. Процессы должны располагаться по диагонали с левого верхнего в правый нижний угол в порядке доминирования. 2. При добавлении новых процессов нарушать диаго- нальное расположение не следует. Данное правило позволяет минимизировать изгибы и пересечения стрелок. 3. Если две стрелки проходят параллельно (начинаются с одной и той же грани одного процесса и заканчиваются на одной и той же грани другого процесса), то по возможности их следует объединить и назвать единым термином. 4. Следует минимизировать число пересечений, петель и поворотов стрелок. Это ручная, творческая работа. Пример модели потоков данных Поставлена задача: разработать модель потоков данных для подсистемы «Абитуриент» АСУ БГТУ. Подсистема необхо- дима для автоматизации работы с документацией в приемной комиссии университета. Используется точка зрения секретаря приёмной комис- сии. На контекстной диаграмме (рис. 7.14) определены базовый процесс «Работа приёмной комиссии», внешние сущности «Аби- туриент» и «Руководство», а также информационные потоки между ними. На диаграмме первого уровня (рис. 7.15) выполнена декомпозиция базового процесса на пять подпроцессов. На диа- граммах второго уровня проведена детализация процессов «Про- верить документы» (рис. 7.16) и «Обработать результаты экзаменов» (рис. 7.17). На рис. 7.18 представлена диаграмма дере- ва узлов модели потоков данных. Для получения полной модели потоков данных следует выполнить декомпозицию процессов до уровня, на котором каждый процесс будет элементарным. 7 6 Рис .7. 14. Контекстная диаграмма модели потоков 7 7 Рис. 7.15. Диаграмма первого модели потоков данных для подсистемы «Абитуриент» 7 8 Рис. 7.16. Диаграмма второго уровня модели потоков данных. Процесс «Проверить документы» 79 Рис. 7.17. Диаграмма второго уровня модели потоков данных. Процесс «Обработать результаты экзаменов» 8 0 Рис. 7.18. Диаграмма дерева узлов модели потоков данных 81 Индивидуальные задания Во всех вариантах необходимо разработать функцио- нальную модель для предметной области, которая составляет основу программной системы. Студент выполняет задание по теме, которую определяет ему преподаватель. Примеры тем: 1. Автоматизированная система «Библиотека». 2. Автоматизированная система «Видеопрокат». 3. Автоматизированная система «Автосервис». 4. Автоматизированная система «Автостоянка». 5. Автоматизированная система «Автосалон». 6. Автоматизированная система «Бассейн». 7. Автоматизированная система «Театр». 8. Автоматизированная система организации спортив- ных соревнований. 9. Автоматизированная система оптового склада. 10. Автоматизированная система магазина самообслужи- вания. 11. Автоматизированная система ателье. 12. Автоматизированная система «Электронная библио- тека». 13. Автоматизированная система управления лечебными учреждениями. 14. Автоматизированная система обработки заказов. 15. Автоматизированная система салона красоты. 16. Автоматизированная система интернет-магазина. 17. Автоматизированная обучающее-контролирующая система. 18. Автоматизированная система расчёта заработной платы. 19. Система автоматического сбора и анализа информа- ции по использованию сетевого оборудования. 20. Подсистема «Деканат» АСУ ВУЗ. 21. Подсистема «Абитуриент» АСУ ВУЗ. Контрольные вопросы 1. Перечислите основные элементы окна Process Modeler. 2. Какие методологии поддерживаются в Process Modeler? 3. Какие вкладки имеет навигатор модели Model Explorer? 4. Перечислите основные элементы модели потоков данных. 5. Какая нотация используется в среде Process Modeler для построения модели потоков данных? 6. Перечислите основные положения стандарта DFD. 7. Какую роль играют в модели потоков данных цель и точка зрения? 8. Какое количество блоков должно присутствовать на диаграмме? 9. По какому принципу выполняется декомпозиция про- цессов? 10. Сформулируйте правила именования процессов и по- токов данных (стрелок). 11. Какие стрелки называют граничными? 12. Каково назначение разветвляющихся и сливающихся стрелок? |