Затонский А.В. Пособие по полному жизненному циклу информационных систем
Подождите немного. Документ загружается.
181
Поток данных на диаграмме изображается линией, оканчивающейся
стрелкой, которая показывает направление потока (рис. 33). Каждый поток
данных имеет имя, отражающее его содержание.
Список обучаемых
10р.
Сформировать
учебные группы
1
Предприятие
Рис. 33. Поток данных
Построение иерархии диаграмм потоков данных
Главная цель построения иерархии DFD заключается в том, чтобы сделать
описание системы ясным и понятным на каждом уровне детализации, а также
разбить его на части с точно определенными отношениями между ними. Для
достижения этого целесообразно пользоваться следующими рекомендациями:
•
Размещать на каждой диаграмме от 3 до 6-7 процессов (аналогично
SADT). Верхняя граница соответствует человеческим возможностям
одновременного восприятия и понимания структуры сложной системы с
множеством внутренних связей, нижняя граница выбрана по
соображениям здравого смысла: нет необходимости детализировать
процесс диаграммой, содержащей всего один или два процесса.
•
Не загромождать диаграммы несущественными на данном уровне
деталями.
•
Декомпозицию потоков данных осуществлять параллельно с
декомпозицией процессов. Эти две работы должны выполняться
одновременно, а не одна после завершения другой.
•
Выбирать ясные, отражающие суть дела имена процессов и потоков, при
этом стараться не использовать аббревиатуры.
Первым шагом при построении иерархии DFD является построение
контекстных диаграмм. Обычно при проектировании относительно простых
систем строится единственная контекстная диаграмма со звездообразной
топологией, в центре которой находится так называемый главный процесс,
соединенный с приемниками и источниками информации, посредством
которых с системой взаимодействуют пользователи и другие внешние системы.
Перед построением контекстной DFD необходимо проанализировать внешние
события (внешние сущности), оказывающие влияние на функционирование
системы. Количество потоков на контекстной диаграмме должно быть по
возможности небольшим, поскольку каждый из них может быть в дальнейшем
разбит на несколько потоков на следующих уровнях диаграммы.
182
Для проверки контекстной диаграммы можно составить список событий.
Список событий должен состоять из описаний действий внешних сущностей
(событий) и соответствующих реакций системы на события. Каждое событие
должно соответствовать одному или более потокам данных: входные потоки
интерпретируются как воздействия, а выходные потоки — как реакции системы
на входные потоки.
Для сложных систем (признаками сложности могут быть наличие
большого количества внешних сущностей (десять и более), распределенная
природа системы или ее многофункциональность) строится иерархия
контекстных диаграмм. При этом контекстная диаграмма верхнего уровня
содержит не единственный главный процесс, а набор подсистем, соединенных
потоками данных. Контекстные диаграммы следующего уровня детализируют
контекст и структуру подсистем.
Для каждой подсистемы, присутствующей на контекстных диаграммах,
выполняется ее детализация при помощи DFD. Это можно сделать путем
построения диаграммы для каждого события. Каждое событие представляется в
виде процесса с соответствующими входными и выходными потоками,
накопителями данных, внешними сущностями и ссылки на другие процессы
для описания связей между этим процессом и его окружением. Затем все
построенные диаграммы сводятся в одну диаграмму нулевого уровня.
Каждый процесс на DFD, в свою очередь, может быть детализирован при
помощи DFD или (если процесс элементарный) спецификации. Спецификация
процесса должна формулировать его основные функции таким образом, чтобы
в дальнейшем специалист, выполняющий реализацию проекта, смог выполнить
их или разработать соответствующую программу.
Спецификация является конечной вершиной иерархии DFD. Решение о
завершении детализации процесса и использовании спецификации принимается
аналитиком исходя из следующих критериев:
•
наличия у процесса относительно небольшого количества входных и
выходных потоков данных (2-3 потока);
•
возможности описания преобразования данных процессов в виде
последовательного алгоритма;
•
выполнения процессом единственной логической функции
преобразования входной информации в выходную;
•
возможности описания логики процесса при помощи спецификации
небольшого объема (не более 20-30 строк).
Спецификации представляют собой описания алгоритмов задач,
выполняемых процессами. Они содержат номер и/или имя процесса, списки
входных и выходных данных и тело (описание) процесса, являющееся
спецификацией алгоритма или операции, трансформирующей входные потоки
данных в выходные. Языки спецификаций могут варьироваться от
структурированного естественного языка или псевдокода до визуальных языков
моделирования.
183
Структурированный естественный язык применяется для понятного,
достаточно строгого описания спецификаций процессов. При его
использовании приняты следующие соглашения:
•
логика процесса выражается в виде комбинации последовательных
конструкций, конструкций выбора и итераций;
•
глаголы должны быть активными, недвусмысленными и
ориентированными на целевое действие (заполнить, вычислить, извлечь,
а не модернизировать, обработать);
•
логика процесса должна быть выражена четко и недвусмысленно.
При построении иерархии DFD переходить к детализации процессов
следует только после определения содержания всех потоков и накопителей
данных, которое описывается при помощи структур данных. Для каждого
потока данных формируется список всех его элементов данных, затем элементы
данных объединяются в структуры данных, соответствующие более крупным
объектам данных (например, строкам документов или объектам предметной
области). Каждый объект должен состоять из элементов, являющихся его
атрибутами. Структуры данных могут содержать альтернативы, условные
вхождения и итерации. Условное вхождение означает, что данный компонент
может отсутствовать в структуре (например, структура «данные о страховании»
для объекта «служащий»). Альтернатива означает, что в структуру может
входить один из перечисленных элементов. Итерация означает вхождение
любого числа элементов в указанном диапазоне (например, элемент «имя
ребенка» для объекта «служащий»). Для каждого элемента данных может
указываться его тип (непрерывные или дискретные данные). Для непрерывных
данных могут указываться единица измерения, диапазон значений, точность
представления и форма физического кодирования. Для дискретных данных
может указываться таблица допустимых значений.
После построения законченной модели системы ее необходимо
верифицировать (проверить на полноту и согласованность). В полной модели
все ее объекты (подсистемы, процессы, потоки данных) должны быть подробно
описаны и детализированы. Выявленные не детализированные объекты следует
детализировать, вернувшись на предыдущие шаги разработки. В согласованной
модели для всех потоков данных и накопителей данных должно выполняться
правило сохранения информации: все поступающие куда-либо данные должны
быть считаны, а все считываемые данные должны быть записаны.
При моделировании бизнес-процессов диаграммы потоков данных (DFD)
используются для построения моделей AS-IS и TO-BE, отражая, таким образом,
существующую и предлагаемую структуру бизнес-процессов организации и
взаимодействие между ними. При этом описание используемых в организации
данных на концептуальном уровне, независимом от средств реализации базы
данных, выполняется с помощью модели «сущность-связь».
Ниже перечислены основные виды и последовательность работ при
построении бизнес-моделей с использованием методики Йордона:
1. Описание контекста процессов и построение начальной контекстной
диаграммы.
184
Начальная контекстная диаграмма потоков данных должна содержать
нулевой процесс с именем, отражающим деятельность организации,
внешние сущности, соединенные с нулевым процессом посредством
потоков данных. Потоки данных соответствуют документам, запросам
или сообщениям, которыми внешние сущности обмениваются с
организацией.
2. Спецификация структур данных.
пределяется состав потоков данных и готовится исходная информация
для построения концептуальной модели данных в виде структур данных.
Выделяются все структуры и элементы данных типа «итерация»,
«условное вхождение» и «альтернатива». Простые структуры и элементы
данных объединяются в более крупные структуры. В результате для
каждого потока данных должна быть сформирована иерархическая
(древовидная) структура, конечные элементы (листья) которой являются
элементами данных, узлы дерева являются структурами данных, а
верхний узел дерева соответствует потоку данных в целом.
3. Построение начального варианта концептуальной модели данных.
Для каждого класса объектов предметной области выделяется сущность.
Устанавливаются связи между сущностями и определяются их
характеристики. Строится диаграмма «сущность-связь» (без атрибутов
сущностей).
4. Построение диаграмм потоков данных нулевого и последующих
уровней.
Для завершения анализа функционального аспекта деятельности
организации детализируется (декомпозируется) начальная контекстная
диаграмма. При этом можно построить диаграмму для каждого события,
поставив ему в соответствие процесс и описав входные и выходные
потоки, накопители данных, внешние сущности и ссылки на другие
процессы для описания связей между этим процессом и его окружением.
После этого все построенные диаграммы сводятся в одну диаграмму
нулевого уровня.
Процессы разделяются на группы, которые имеют много общего
(работают с одинаковыми данными и/или имеют сходные функции). Они
изображаются вместе на диаграмме более низкого (первого) уровня, а на
диаграмме нулевого уровня объединяются в один процесс. Выделяются
накопители данных, используемые процессами из одной группы.
Декомпозируются сложные процессы, и проверяется соответствие
различных уровней модели процессов.
Накопители данных описываются посредством структур данных (ERD), а
процессы нижнего уровня – спецификациями.
5. Уточнение концептуальной модели данных.
Определяются атрибуты сущностей. Выделяются атрибуты-
идентификаторы. Проверяются связи, выделяются (при необходимости)
связи «супертип-подтип».
185
Проверяется соответствие между описанием структур данных и
концептуальной моделью (все элементы данных должны присутствовать
на диаграмме в качестве атрибутов).
На практике полезными при составлении DFD-моделей могут быть
приведенные ниже принципы.
А. Методика построения DFD-диаграмм
1. DFD-диаграмма должна быть полезной.
2. Цель построения DFD-диаграмм – общение с заказчиком и
пользователями, уточнение требований к системе, передача знаний о
предметной области от системных аналитиков к разработчикам
автоматизированной системы.
3. Каждая DFD-диаграмма должна быть проверена на соответствие
реальному положению дел («как есть»).
4. Правило от 2 до 6. На DFD-диаграмме должно быть не меньше двух и не
больше шести процессов/подсистем.
5. Принцип абстракции (отвлечения от деталей). Для подсистем и процессов
строится иерархия DFD-диаграмм. На каждой диаграмме должны быть
представлены только основные процессы, важные на данном уровне
рассмотрения. На диаграммах нужно абстрагироваться от
несущественных пока деталей, нюансов работы и т.д.
6. Материальные процессы, потоки и хранилища на диаграммах DFD не
отображаются (только процессы обработки информации, потоки данных
и хранилища данных).
7. Сначала должны быть рассмотрены функции (процессы), затем данные
(хранилища), необходимые для выполнения этих функций. Подход «от
данных к функциям» запрещен.
8. Не должно быть связей между внешними сущностями. Во внешних
сущностях не должно быть обработки информации.
9. Имена процессов должны быть глаголами или глагольными
существительными. Имена подсистем должны быть существительными
(названия отделов, должностей). Имена потоков должны быть
названиями документов или групп документов.
10. Для хранилища данных должен быть вход и выход. Должен соблюдаться
закон сохранения информации: нельзя использовать того, чего нет в
хранилище. Все что хранится, нужно использовать. Запросы к хранилищу
данных на диаграммах не отображаются.
11. Нужно избегать пересечений стрелок, можно создавать копии хранилищ
данных. Множественные однородные потоки данных можно объединять
в один.
12. Элементарные процессы на диаграммах DFD не детализируются.
13. На диаграммах DFD не должно быть изолированных (несвязанных)
объектов (внешних сущностей, подсистем, процессов, хранилищ данных)
B. Методика описания процесса обработки информации
Материальные процессы на DFD-диаграммах не отображаются. Только
процессы обработки информации.
186
1. Название процесса, основная функция
2. Ответственный за процесс, исполнитель процесса (должность, отдел)
3. Тип процесса (сложный или элементарный)
4. Длительность процесса (минимальная, максимальная, типичная)
5. Входящая информация (документы и хранилища по методикам C и D)
6. Исходящая информация (документы и хранилища по методикам C и D)
7. Алгоритм обработки информации (для сложных процессов с точностью
до документа, для элементарных процессов с точностью до полей,
желательно с использованием структурного естественного языка,
имеющего три конструкции: Последовательность, Ветвление и Цикл,
необходимо уложиться в 10-30 строк)
C. Методика описания документа
Материальные потоки на DFD-диаграммах не отображаются. Только потоки
данных.
Документ может быть бумажный, электронный или другое информационное
сообщение.
1. Название документа
2. Функция документа
3. Маршрут документа (составитель, источник, приемник, следующий
приемник и т.д.)
4. Периодичность (или интенсивность)
5. Объемы (кол-во строк в документе),
минимальные/максимальные/типичные
6. Образцы документа (ксерокопии с реальными данными)
7. Структура документа (поля шапки, табличной части, подвала, типы
данных каждого поля, длина, точность, список возможных значений,
ограничения на значение поля, взаимосвязь с другими полями документа)
8. Исходная информация для составления документа (другие и/или этот же
документ, хранилища данных)
9. Порядок составления документа (алгоритм)
D. Методика описания хранилища данных
Материальные хранилища на DFD-диаграммах не отображаются. Только
хранилища данных.
Хранилищем данных может быть справочник, журнал, ведомость, картотека,
база данных.
1. Название хранилища
2. Функция хранилища
3. Тип хранилища (нормативно-справочная информация или оперативные
данные)
4. Место физического размещения (отдел, рабочее место)
5. Ответственный за ведение хранилища данных (должность, отдел)
6. Образцы хранилища данных (ксерокопии с реальными данными)
7. Структура (разделы, применяемые классификаторы, поля, типы данных
каждого поля, длина, точность, список возможных значений, ограничения
на значение поля, взаимосвязь с другими полями этого хранилища)
187
8. Объемы хранилища данных (кол-во строк, карточек, документов)
9. Периодичность/интенсивность обновления (добавления, удаления,
корректировки)
10. Процессы, события, влияющие на хранилище данных
11. Процессы, подсистемы (должности, отделы), использующие хранилище
данных
12. Взаимосвязь с другими хранилищами данных с точностью до полей.
13. Порядок ведения хранилища данных.
E. Методика описания требований к новой системе.
1. Идентификационный номер требования (обязательно!), название
требования
2. Источник требования (ФИО, должность, отдел)
3. Приоритет выполнения требования (от 1 до 5)
4. Суть требования (подробно)
5. Требующие изменения или вновь создаваемые документы, отчеты,
хранилища данных, процессы (по соответствующей методике).
6. Исполнитель требования (отдел, рабочее место).
7. Стабильность требования (вероятность изменения, направление и
границы изменения)
Пример построения диаграмм
В качестве примера рассмотрим иерархию диаграмм процесса поступления
в ВУЗ (рис. 34-36).
Рис. 34. Уровень 0
188
Рис. 35. Детализация первого уровня
Рис. 36. Детализация процесса «Сдать экзамены» при помощи IDEF0-
диаграммы.
Диаграммы IDEF3 удобно использовать, где нет документов (например, в
описании действий автомата). В отличие от IDEF0 и DFD, позволяет точно
определить порядок действий, алгоритмизировать разветвления и параллельные
процессы.
189
Рис. 37. Детализация процесса «Определить тип экзамена» при помощи IDEF3-
диаграммы.
DFD-диаграмма легко преобразуется в UML документ (Universal Markup
Language) – универсальное средство описания объектов. Для разработки ИС
важно, что на DFD-диаграмме:
•
Определены внешние по отношению к системе сущности.
•
Видно, на каком этапе и какие данные начинают храниться.
Рис. 38. Пример DFD-диаграммы для процесса приема абитуриентов
Составление DFD завершается составлением спецификаций на каждый
процесс, хранилище, сущность, как описано выше.
190
00р.
Дея тельнос ть кафедры
10р.
Подг о товитель ны е
операции
20р.
Орг анизация
учебн ог о
про цес са
30р.
Управление
хозя йс тв енной
дея тель нос тью
40р.
Управление
научной
деяте льнос ть ю
50р.
Управление
другими в идам и
деяте льнос ти
60р.
Формиров ание
отчетов
10р.
Формиров ан ие
докумен тов
по учебному процесс у
в целом
20р.
Рас пре делен ие
наг рузки
10р.
Орг анизация
занятий и п рактик
20р.
Орг анизация
за четов и экзаменов
30р.
Орг анизация
итогов ой аттес тации
40р.
Орг анизация выдачи
дипломов и вкладышей
Разработка зада ний к
г ос экзамену
-----------------------------------
преп одаватель
Разработка методмате риалов
к го с э кзамену и В КР
-----------------------------------
преп одаватель
Разработка критериев оценки
-----------------------------------
преп одаватель
Разработка учебног о плана
-------------------------------------
зам. зав . каф едры по м етод.
работе
Разработка рабочих программ
------------------------------------
преп одаватель
Разработка прог раммы
г ос экзамена
-----------------------------------
преп одаватель
Разработка
учебно-методич ес ких
материалов
-----------------------------------
преп одаватель
Разработка э кзаменационны х
воп росов и вопрос ов к зач ету
------------------------------------
преп одаватель
Заполнение в ып ис ок из УП
----------------------------------------
методист
Заполнение вертикаль н ых ф орм
---------------------------------------
методист
Анализ, корректировка и утв ерж дение
выписок из УП
-------------------------------------- зав.
кафедрой
Рас пределение нагрузки
--------------------------------------- зав.
кафедрой
Формиров ание карточек учебных
поруч ений
-------------------------------------------
методист
Сос та вление 1 и 2 с тр.
индивидуаль ных планов
преп одавате лей
-----------------------------------------
методист
Сос та вление индивидуаль ных планов
преп одавате лей с 3 с траницы
---------------------------------------
преп одавате ль
Утв ерж дение индиви дуаль ных планов
------------------------------------- зав.
кафедрой
Формиров ание с пис ка доп ущ енны х
студен тов к зач ету
-------------------------------------------------
преп одавате ль
Формиров ание с пис ка доп ущ енны х
студен тов к экзам е ну
--------------------------------------------------
преп одавате ль
Пров едение заня тий
------------------------------------------------
преп одавате ль
Рас пре делени е с тудентов на практику
Пров ерка отч етов по практике
Пров едение экзамена
-------------------------------------------------
преп одавате ль
Пров едение зачета
--------------------------------------------------
преп одавате ль
Формиров ание
спис ка Г ЭК и ГА К
Аппеляция
Сос та вление
рас пис ания ГАК
Сос та вление
рас пис ания ГЭК
Пров едение защит
ВКР
Оф орм ление
протоколов
Пров едение ГА К
Формиров ание
вклады шей к
дипломам
Пров едение
г ос экзаменов
Формиров ание
отч етов
Рис. 39. Дерево иерархии диаграмм