Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Моделирование систем. Инструменты и возможности моделирования производственных систем. Методическое пособие
.pdf
Наконец, приведем пример конкретной диаграммы нижнего
уровня – выполнение лабораторной работы (рис. 4.6).
4.4. Стандарт моделирования потоков
данных DFD
Как указывалось в предыдущей части, при моделировании
в системе SADT наряду с подмножеством IDEF0 для функционального моделирования информационных систем используются и другие подмножества. Одной из таких альтернатив
является методология диаграмм потоков данных (Data Flow
Diagrams – DFD). В отличие от IDEF0, предназначенной для
проектирования систем вообще, DFD предназначена для проектирования информационных систем и автоматизированных
систем вообще. Обе эти методологии могут применяться как
по отдельности, так и совместно – IDEF0 моделирует функциональность, DFD – потоки данных и информационную составляющую.
Пример такого взаимодействия приводится на рис. 4.7.
Рис. 4.7. Совместная разработка ИС
Общая методология одинакова. В основе ее лежит разбиение
более общих сущностей на более мелкие путем декомпозиции
31
диаграмм. Однако есть и существенные различия. Если в IDEF0
основными элементами являются функциональные блоки и
дуги, то DFD, моделируя потоки данных и их преобразование
в системе, оперирует такими понятиями, как:
• внешние сущности;
• системы и подсистемы;
• процессы;
• накопители данных;
• потоки данных.
Из приведенного перечня видно, что в DFD моделируется все
процессы – от ввода информации в систему (внешняя сущность),
ее асинхронной обработки и преобразования системами и процессами, накопления информации и до выдачи ее конечному потребителю (тоже внешняя сущность).
Источники информации (внешние сущности) порождают информационные потоки (потоки данных), переносящие информацию к подсистемам или процессам. Те, в свою очередь, преобразуют информацию и порождают новые потоки, которые
переносят информацию к другим процессам или подсистемам,
накопителям данных или внешним сущностям — потребителям
информации.
Соответственно, есть различия и в нотациях (системах значков, используемых для построения диаграмм). В DFD традиционно используются две различные нотации, соответствующие
методам Йордона–ДеМарко и Гейна–Сэрсона. Эти нотации отличаются друг от друга графическим изображением символов.
Эти различия приводятся на рис. 4.8. Мы далее в примерах будем использовать нотацию Гейна–Сэрсона. Она в нашей стране является основной в связи с широким использованием для
моделирования системы BPWin. В целом можно утверждать,
что DFD – это нотация, предназначенная для моделирования
информационный систем с точки зрения хранения, обработки и
передачи данных.
В соответствии с данным методом модель системы определяется как иерархия диаграмм потоков данных, описывающих
асинхронный процесс преобразования информации от ее ввода
в систему до выдачи потребителю.
32
Рис. 4.8. Основные нотации DFD
4.5. Состав диаграмм потоков данных
Приведем краткую характеристику элементов диаграмм по-
токов данных.
Внешняя сущность – это физическое лицо или материальный
объект, являющиеся источником или приемником информации,
например персонал, поставщики, заказчики, клиенты, отдел продаж, хранилища данных или любые носители информации. Внешние сущности находятся за пределами границ анализируемой системы. В процессе анализа некоторые внешние сущности могут
быть перенесены внутрь диаграммы анализируемой системы, если
это необходимо, или, наоборот, часть процессов может быть вынесена за пределы диаграммы и представлена как внешняя сущность.
Внешняя сущность обозначается квадратом (рис. 4.9), распо-
ложенным над диаграммой и бросающим на нее тень для того,
33
чтобы можно было выделить этот символ среди других обозначений.
Рис. 4.9. Графическое изображение внешней сущности
При построении модели сложной системы она может быть
представлена в самом общем виде на так называемой контекстной диаграмме в виде одной системы как единого целого либо
может быть декомпозирована на ряд подсистем. Каждая внешняя сущность имеет префикс (обозначение в левом верхнем
углу).
Подсистема (или система) на контекстной диаграмме изображается так, как она представлена на рис. 4.10.
Рис. 4.10. Подсистема по работе с физическими лицами
(ГНИ — Государственная налоговая инспекция)
В отличие от функциональных блоков она изображается
прямоугольником со скругленными углами и имеет четкую
структуру. В отличие от функциональных блоков IDEF0 номер
подсистемы указывается в верхней части и служит для ее идентификации. В центральной части – поле имени – вводится наи-
34
менование подсистемы в виде предложения с подлежащим и
соответствующими определениями и дополнениями. Название
работы строится по принципу: действие плюс объект, над которым это действие производится. Например, если это подсистема
продаж, то название будет «Продажа товара». Наконец, в нижней части указывается, где эта система (подсистема) физически
реализуется.
Процесс – это функция или последовательность действий,
которые нужно предпринять, чтобы данные были обработаны,
и представляет собой преобразование входных потоков данных
в выходные в соответствии с определенным алгоритмом. Физически процесс может быть реализован различными способами:
это может быть подразделение организации (отдел), выполняющее обработку входных документов и выпуск отчетов, программа, и т.д. В названиях нет строгой системы требований, как,
например, в IDEF0, где нотации имеют жестко определенный
синтаксис процессов, но вообще-то принято использовать глаголы, т.е. «создать клиента» (а не «создание клиента») или «обработать заказ» (а не «проведение заказа»). Изображение процессов на диаграмме потоков данных такое же, как у систем, что
показано на рис. 4.11.
Рис. 4.11. Графическое изображение процесса
Номер процесса служит для его идентификации. В поле
имени вводится наименование процесса в виде предложения
с активным недвусмысленным глаголом в неопределенной форме (вычислить, рассчитать, проверить, определить, создать, получить), за которым следуют существительные в винительном
падеже, например: «Ввести сведения о налогоплательщиках»,
35
«Выдать информацию о текущих расходах», «Проверить поступление денег».
Информация в поле физической реализации показывает, какое подразделение организации, программа или аппаратное
устройство выполняет данный процесс.
Есть разница в нумерации блоков в IDEF0 и DFD – в последнем случае они изображаются через точку. То есть, например,
если в IDEF0 блок имеет номер А42, то в DFD он будет нумероваться А4.2. Еще одно отличие – в диаграммах DFD процессы и
подсистемы располагаются не по принципу «выше–ниже», доминантности и подчиненности, а справа налево в хронологическом порядке обработки информации.
Накопитель данных — это абстрактное устройство для хранения информации, которую можно в любой момент поместить
в накопитель и через некоторое время извлечь, причем способы
помещения и извлечения могут быть любыми. Это внутреннее
хранилище данных для процессов в системе. Поступившие данные перед обработкой и результат после обработки, а также промежуточные значения или результаты обработки должны где-то
храниться. Это и есть базы данных, таблицы или любой другой
вариант организации и хранения данных.
Накопитель данных может быть реализован физически в виде
микрофиши, ящика в картотеке, таблицы в оперативной памяти, файла на магнитном носителе и т.д. Накопитель информации на диаграмме потоков данных изображается, как показано
на рис. 4.12.
Рис. 4.12. Графическое изображение накопителя данных
На диаграммах накопители данных идентифицируются расположенными слева буквой «D» + число. На рисунке 4.12 это
«D1» Отметим, что накопитель данных не обязательно находится в системе, он может быть и внешней сущностью. В этом случае он изображается как внешняя сущность. При построении на-
36
званий потоков обычно применяется правило указывать объект,
над которым совершается действие, и его статус, например «Товар отгруженный».
Поток данных – это информация, передаваемая через некоторое соединение от источника к приемнику. Физически соединение может быть произвольным, не обязательно это электронное
соединение, но это и, например, бумажный документооборот.
Поток данных на диаграмме изображается линией, оканчивающейся стрелкой, которая показывает направление потока
(рис. 4.13).
Рис. 4.13. Изображение направления потока данных
Каждый поток данных имеет имя, отражающее его содержание. Имя, как правило, раскрывает сущность передаваемой
информации (например, как на рис 4.13, – «Отчетность по подоходному налогу»). И, в отличие от диаграмм IDEF0, где расположение стрелок-дуг строго регламентировано, потоки могут
присоединяться к блокам в произвольном месте.
4.6. Построение иерархии диаграмм потоков
данных
Методологически построение модели DFD совпадает с другими нотациями, но есть и серьезные различия. Связаны они с тем,
что у каждого стандарта есть своя специфика, что и отражается
и нотациях, и в методах построения диаграмм. Но также, как и
в других методологиях, главная цель построения иерархии DFD
заключается в том, чтобы сделать описание системы ясным, понятным и целостным на каждом уровне детализации.
37
Первым шагом при построении иерархии DFD является построение контекстных диаграмм. Обычно при проектировании
относительно простых систем строится единственная контекстная диаграмма со звездообразной топологией, в центре которой находится так называемый главный процесс, соединенный с приемниками и источниками информации, посредством
которых с системой взаимодействуют пользователи и другие внешние системы. Пример такой диаграммы приводится
на рис. 4.14.
Рис. 4.14. Начальная контекстная диаграмма для библиотеки
Однако в некоторых случаях (например, наличие большого
количества внешних сущностей (десять и более), распределенная природа системы, многофункциональность системы с уже
сложившейся или выявленной группировкой функций в отдельные подсистемы) целесообразнее и нагляднее построить несколько контекстных диаграмм с иерархией. При этом контекстная
диаграмма верхнего уровня содержит не единственный главный
процесс, а набор подсистем, соединенных потоками данных.
38
Контекстные диаграммы следующего уровня детализируют контекст и структуру подсистем. Затем все построенные диаграммы
сводятся в одну диаграмму нулевого уровня.
Существует и альтернативный подход к разработке системы,
обычно применяемый при создании программного обеспечения,
называемый событийным разделением, в котором различные
диаграммы DFD выстраивают модель системы. Вначале ло-
гическая модель строится как совокупность процессов и документирования того, что эти процессы должны делать. Затем
с помощью модели окружения система описывается как взаимодействующий с событиями из внешних сущностей объект.
Модель окружения обычно содержит описание цели системы,
одну контекстную диаграмму и список событий. Контекстная
диаграмма содержит один блок, изображающий систему в целом, внешние сущности, с которыми система взаимодействует (как минимум, одну внешнюю сущность и один блок), ссылки и некоторые стрелки, импортированные из диаграмм IDEF0
и DFD. Следующий шаг – моделирование поведения. Эта модель
показывает, как система обрабатывает события. Эта модель
состоит из одной диаграммы, в которой каждый блок изображает каждое событие из модели окружения, могут быть добавлены хранилища для моделирования данных, которые необходимо запоминать между событиями. Потоки добавляются для
связи с другими элементами, и диаграмма проверяется с точки
зрения соответствия модели окружения.
Отметим, что поскольку в DFD-диаграммах изображается гораздо больше объектов, чем, например, в JDEF0, то при построении диаграмм следует придерживаться некоторых правил (подчеркнем, что правило – не закон, бывают исключения).
Правило первое – «Правило не больше 7». Размещать на каждой диаграмме от 3 до 6–7 процессов (аналогично SADT). Поскольку на каждой диаграмме присутствуют и другие объекты
(внешние сущности, накопители данных), то диаграмма получается сложной для понимания. Лучше потом добавить еще один
уровень декомпозиции. Но и нельзя переборщить: если объектов
меньше 3, то количество диаграмм неоправданно возрастает.
Правило второе: не загромождать диаграммы несущественными на данном уровне деталями.
39
Правило третье – декомпозицию потоков данных осущест-
влять одновременно с декомпозицией процессов.
Правило четвертое – выбирать ясные, отражающие суть дела
имена процессов и потоков, при этом стараться не использовать
аббревиатуры.
Для иллюстрации действенности этих правил приведем пример из конкретного госзаказа по выработке алгоритма решения
по оптимальной скорости движения составов на железной дороге. Начальная диаграмма приведена на рис. 4.15.
Рис. 4.15. Контекстная диаграмма допускаемых скоростей
Очевидно, что при подобной загроможденности диаграмм
в них трудно разобраться даже IT-специалистам, не говоря о заказчиках.
После построения контекстных диаграмм, полученную модель следует проверить на полноту исходных данных об объектах системы и изолированность объектов (отсутствие инфор-
40
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]