Приведите и опишите основные символы, используемые при описании dfd диаграмм.
Диаграммы потоков данных (DFD – Data Flow Diagram) являются основным средством моделирования функциональных требований проектируемой системы. С их помощью эти требования разбиваются на функциональные компоненты (процессы) и представляются в виде сети, связанной потоками данных. Главная цель таких средств – продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами.
Основные символы DFD изображены на рис3. Опишем их назначение. На диаграммах функциональные требования представляются с помощью процессов и хранилищ, связанных потоками данных.
Потоки данных являются механизмами, использующимися для моделирования передачи информации (или даже физических компонент) из одной части системы в другую. Важность этого объекта очевидна: он дает название целому инструменту. Потоки на диаграммах обычно изображаются именованными стрелками, ориентация которых указывает направление движения информации.
Рис3.Основные символы
Назначение процесса состоит в продуцировании выходных потоков из входных в соответствии с действием, задаваемым именем процесса. Это имя должно содержать глагол в неопределенной форме с последующим дополнением (например, «вычислить максимальную высоту»). Кроме того, каждый процесс должен иметь уникальный номер для ссылок на него внутри диаграммы. Этот номер может использоваться совместно с номером диаграммы для получения уникального индекса процесса во всей модели.
Хранилище (накопитель) данных позволяет на определенных участках определять данные, которые будут сохраняться в памяти между процессами. Фактически хранилище представляет «срезы» потоков данных во времени. Информация, которую оно содержит, может использоваться в любое время после ее определения, при этом данные могут выбираться в любом порядке. Имя хранилища должно идентифицировать его содержимое и быть существительным. В случае, когда поток данных входит или выходит в/из хранилища, и его структура соответствует структуре хранилища, он должен иметь то же самое имя, которое нет необходимости отражать на диаграмме. Несмотря на это, рекомендуется всегда указывать имена потоков на диаграмме.
Внешняя сущность (терминатор) представляет сущность вне контекста системы, являющуюся источником или приемником системных данных. Ее имя должно содержать существительное, например, склад товаров. Предполагается, что объекты, представленные такими узлами, не должны участвовать ни в какой обработке.
Опишите процесс создания диаграмм dfd. Обоснуйте именно такую последовательность создания диаграмм.
В качестве примера создания модели рассмотрим фрагмент проекта системы обработки заказов клиентов и их обслуживания. Организация принимает от клиентов заказы на поставку товаров. Клиенту выписывается счет, после оплаты которого происходит отгрузка товара. Основными функциями системы являются выписка счета клиенту, прием оплаты от клиента, отгрузка товаров.
|
Для создания новой DFD модели необходимо выбрать пункт меню File New,а в открывшемся окне выбрать тип модели (Type) Data Flow (DFD), ввести наименование модели и нажать OK. В открывшемся при этом окне указать фамилию автора-составителя модели и его инициалы. Значения всех остальных параметров можно оставить по умолчанию. |
Построим контекстную диаграмму системы. Для этого изобразим основную функцию рассматриваемой системы и внешние по отношению к ней сущности, а также взаимосвязи между внешними сущностями и функцией системы. Контекстная диаграмма будет выглядеть следующим образом (рис.39). Здесь сущность Склад является внешней по отношению к системе, т.к. рассматриваемая система не выполняет складских операций. Таким образом она лишь получает необходимую для работы информацию от Склада. Клиенты делают заказы на покупку товаров и получают товары, что изображено в виде стрелок с соответствующими наименованиями. Двунаправленная стрелка «счета, статусы/платежи, запросы» является аналогом двух стрелок направленных от сущности Клиенты к функции Обработка заказов и наоборот. В данном случае, Клиент получает информацию о счетах и статусах своих заказов, и может передавать в систему информацию о платежах и запросах (тех же статусов заказов).
Приведите рекомендации относительно построения модели DFD и этапы составленные на основе этих процессов.
Главная цель построения иерархического множества DFD заключается в том, чтобы сделать требования ясными и понятными на каждом уровне детализации, а также разбить эти требования на части с точно определенными отношениями между ними. Для достижения этого целесообразно пользоваться следующими рекомендациями:
Размещать на каждой диаграмме от 3 до 6-7 процессов. Верхняя граница соответствует человеческим возможностям одновременного восприятия и понимания структуры сложной системы с множеством внутренних связей, нижняя граница выбрана по соображениям здравого смысла: нет необходимости детализировать процесс диаграммой, содержащей всего один или два процесса.
Не загромождать диаграммы несущественными на данном уровне деталями.
Декомпозицию потоков данных осуществлять параллельно с декомпозицией процессов; эти две работы должны выполняться одновременно, а не одна после завершения другой.
Выбирать ясные, отражающие суть дела, имена процессов и потоков для улучшения понимаемости диаграмм, при этом стараться не использовать аббревиатуры.
Однократно определять функционально идентичные процессы на самом верхнем уровне, где такой процесс необходим, и ссылаться на него на нижних уровнях.
Пользоваться простейшими диаграммными техниками: если что-либо возможно описать с помощью DFD, то это и необходимо делать, а не использовать для описания более сложные объекты.
Отделять управляющие структуры от обрабатывающих структур (т.е. процессов), локализовать управляющие структуры.
В соответствии с этими рекомендациями процесс построения модели разбивается на следующие этапы:
Расчленение множества требований и организация их в основные функциональные группы.
Идентификация внешних объектов, с которыми система должна быть связана.
Идентификация основных видов информации, циркулирующей между системой и внешними объектами.
Предварительная разработка контекстной диаграммы, на которой основные функциональные группы представляются процессами, внешние объекты – внешними сущностями, основные виды информации – потоками данных между процессами и внешними сущностями.
Изучение предварительной контекстной диаграммы и внесение в нее изменений по результатам ответов на возникающие при этом изучении вопросы по всем ее частям.
Построение контекстной диаграммы путем объединения всех процессов предварительной диаграммы в один процесс, а также группирования потоков.
Формирование DFD первого уровня на базе процессов предварительной контекстной диаграммы.
Проверка основных требований по DFD первого уровня.
Декомпозиция каждого процесса текущей DFD с помощью детализирующей диаграммы или спецификации процесса.
Проверка основных требований по DFD соответствующего уровня.
Добавление определений новых потоков в словарь данных при каждом их появлении на диаграммах.
Параллельное (с процессом декомпозиции) изучение требований (в том числе и вновь поступающих), разбиение их на элементарные и идентификация процессов или спецификаций процессов, соответствующих этим требованиям.
Проведение ревизии после построения двух-трех уровней с целью проверки корректности и улучшения понимаемости модели.
Построение спецификации процесса (а не простейшей диаграммы) в случае, если некоторую функцию сложно или невозможно выразить комбинацией процессов.
Дайте сравнительный анализ SADT моделей и потоковых моделей. Что на ваш взгляд предпочтительнее использовать SADT или DFD, почему и в каком случае?
На практике довольно часто встречаются ситуации, когда при детализации процесса SADT диаграммы, наилучшим образом для изображения бизнес процессов подходит DFD диаграмма. В этом случае существует возможность изображения диаграммы декомпозиции в виде DFD диаграммы. Так, в примере детализация работы Хранение может быть представлена следующим образом (рис.41).
Здесь документы на закупленный товар проходят регистрацию, в результате чего отчет о проделанной работе, содержащий информацию о наличии товара поступает в корпоративную базу данных и на выход работы Хранение, а товарно-транспортная накладная и разрешение на погрузочно-разгрузочные работы используются в функции Обработка груза. Кроме того, функция Обработка груза использует информацию о доставленном товаре. В результате ее работы формируются информационные потоки Отгруженный товар и Списанный товар, являющиеся выходными для работы Хранение. Следует отметить, что приведенная диаграмма описывает процессы, происходящие в работе Хранение в достаточно общем виде. Например, хранилище Корпоративная БД является слишком общим понятием, которое в рельности будет преобразовано в несколько более мелких хранилищ. Потоки Отгруженный товар и Списанный товар, тоже, вполне вероятно, должны быть сохранены в базе данных, однако на данной диаграмме это не показано.
При необходимости, на DFD диаграмме можно изображать и внешние по отношению к модели сущности, если это улучшит понимание модели. Рассмотрим пример детализации работы Списание товара с помощью DFD диаграммы.
На DFD диаграммах возможно также изображать не только информационные потоки и процессы их обработки, но и потоки, обозначающие действие и относящиеся скорее к уровню управления изображенным на диаграмме процессом