Функциональные диаграммы SADT

Функциональными - называют диаграммы, отражающие взаимосвязи функций разрабатываемого ПО. Каждый блок такой диаграммы (Activity) соответствует некоторой функции, для которой должны быть определены: исходные данные, результаты, управляющая информация и механизмы ее осуществления. Все связи на диаграмме представляются дугами, причем тип связи и ее направление строго регламентированы. Дуги, изображающие каждый тип связей, должны подходить к блоку с определенной стороны, а направление связи должно указываться стрелкой в конце.

Физически дуги исходных данных, результатов и управления представляют собой наборы данных, передаваемые между функциями. Дуги, определяющие механизм выполнения функции, в основном используются при описании спецификаций сложных информационных систем, которые включают как автоматизированные, так и ручные операции. Блоки и дуги маркируются текстами на естественном языке.

Блоки на функциональной диаграмме размещают по «ступенчатой» схеме в соответствии с последовательностью их работы или доминированием, которое понимается как влияние, оказываемое одним блоком на другие. В функциональных диаграммах SADT различают пять типов влияний блоков друг на друга:

· вход – выход блока подается на вход блока с меньшим доминированием, т.е. на вход следующего (рис. 3.1а);

· управление – выход блока используется как управление для блока с меньшим доминированием (следующего) (рис. 3.1б);

· обратная связь по входу – выход блока подается на вход блока с большим доминированием (на вход предыдущего) (рис. 3.1в);

· обратная связь по управлению – выход блока используется как управляющая информация для блока с большим доминированием (предыдущего) (рис. 3.1г);

· выход – исполнитель – выход блока используется как механизм для другого блока (рис. 3.1д).

Дуги могут разветвляться и соединяться вместе различными способами. Разветвление означает, что часть или вся информация может использоваться в каждом ответвлении дуги. Дуга всегда помечается до ветвления, чтобы идентифицировать передаваемый набор данных. Если ветвь дуги после ветвления не помечена, то непомеченная ветвь содержит весь набор данных. Каждая метка ветви уточняет, что именно содержит данная ветвь (рис. 3.2).

Рис. 3.1. Типы влияний блоков:

а – связь по входу; б – связь по управлению; в – обратная связь по входу;

г – обратная связь по управлению; д – связь выход-исполнитель.

 

 

Рис. 3.2. Пример обозначения дуг при ветвлении

 

Построение иерархии функциональных диаграмм ведется поэтапно с увеличением уровня детализации: диаграммы каждого следующего уровня уточняют структуру родительского блока. Построение модели предметной области (с точки зрения бизнес-процессов) начинают с блока самого верхнего уровня – контекстная диаграмма предметной области, для которого определяют исходные данные, результаты, управление и механизмы реализации. Затем этот блок последовательно детализируется с использованием метода пошаговой детализации. При этом рекомендуется каждую функцию представлять не более чем 3-7 блоками.

Во всех случаях каждая подфункция может использовать или продуцировать только те элементы данных, которые использованы или продуцируются родительской функцией, причем никакие элементы не могут быть опущены, что обеспечивает непротиворечивость построенной модели.

Стрелки, проходящие с родительской диаграммы или уходящие на нее, нумеруют, используя символы и числа. Символ, в этом случае, обозначает тип связи: I – входная, C – управляющая, М – механизм, R – результат. Число – номер связи по соответствующей стороне родительского блока, считая сверху вниз и слева направо.

Все диаграммы связаны друг с другом иерархической нумерацией блоков: первый уровень – А0 (А – от слов Activity), второй – А1, А2, и т.п., третий – А11, А12, А13 и т.п., где первые цифры – номер родительского блока, а последняя – номер конкретного субблока родительского блока.

Процесс детализации завершается после получения функций, назначение которых хорошо понятно как заказчику, так и разработчику. Для описания полученных функций используют естественный язык, либо псевдокод.

В процессе построения иерархии диаграмм фиксируют всю уточняющую информацию и строят словарь стрелок, в котором определяют структуры и элементы данных, показанных на диаграммах.

Словарь стрелок решает очень важную задачу. Диаграммы создаются аналитиком для того, чтобы провести сеанс экспертизы, т.е. обсудить содержимое диаграммы со специалистом предметной области. Как известно, в любой предметной области формируется профессиональный жаргон, причем очень часто жаргонные выражения имеют нечеткий смысл и поэтому воспринимаются разными специалистами по-разному. В то же время аналитик, как автор диаграмм, вынужден употреблять те выражения, которые наиболее понятны экспертам. Поскольку формальные определения часто сложны для восприятия, аналитик вынужден употреблять профессиональный жаргон, а чтобы не возникло неоднозначных трактовок, в словаре стрелок каждому понятию можно дать расширенное и, если это необходимо, формальное определение.

Таким образом, в результате функционального моделирования предметной области получают спецификацию, которая состоит из:

· иерархии функциональных диаграмм;

· спецификаций функций нижнего уровня;

· словаря стрелок (данных),

при этом, элементы полученной спецификации должны иметь ссылки друг на друга.

Приведем пример разработки функциональных диаграмм при уточнении спецификации программы построения таблиц / графиков функций одной переменной [8].

 

Рис. 3.3. Функциональные диаграммы для системы исследования функций:

а- диаграмма верхнего уровня; б - уточняющая диаграмма

 

Диаграмма на рис. 3.3а, является диаграммой верхнего уровня (контекстной диаграммой). Диаграмма, представленная на рис. 3.3.б, уточняет функции программы.

Для каждого из блоков определены исходные данные, управляющие воздействия и результаты. Согласно правилам наименования входов / выходов, имеющих продолжение на родительской диаграмме, на диаграмме использованы следующие обозначения:

I1 – функция, I2 – отрезок, I3 – шаг, C1 – вид график / таблица,

R1 – график функции на отрезке, R2 – таблица значений функции на отрезке.

Словарь стрелок должен в этом случае содержать описание всех данных, используемых в системе, например, по формату: «имя: тип данного = начальное значение».

Функциональные модели рекомендуется применять для определения спецификации ПО, не предусматривающего работу со сложными структурами данных. На рис. 3.4 и 3.5 показаны контекстная диаграмма (А0) и диаграмма декомпозиции первого уровня (А0).

Рис. 3.4. Контекстная диаграмма модели

 

Рис. 3.5. Диаграмма декомпозиции А0 модели

 

Диаграммы потоков данных

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

DFD описывает:

· функции обработки информации (работы);

· документы (стрелки, arrows), объекты, сотрудников или отделы, которые участвуют в обработке информации;

· внешние ссылки (external references), которые обеспечивают интерфейс с внешними объектами (сущностями), находящимися за границами моделируемой системы;

· таблицы для хранения документов (хранилище данных, data store).

В BPwin для построения диаграмм потоков данных используется нотация Гейна-Сарсона (Ч.Гейн и Т.Сарсон, 1979), либо нотация Е.Йордана (1975г.) для следующих понятий:

Внешняя сущность – материальный объект или физическое лицо, выступающие в качестве источников или приёмников информации, например, заказчики, персонал, поставщики, клиенты, банк и т.п.

Процесс – преобразование входных потоков данных в выходные в соответствии с определенным алгоритмом. Каждый процесс в системе имеет свой номер и связан с исполнителем, который осуществляет данное преобразование. Также как и в функциональных диаграммах, в DFD существует контекстная диаграмма, и применяется пошаговая декомпозиция процессов.

Хранилище данных – абстрактное устройство для хранения информации. Тип устройства и способы помещения, извлечения и хранения информации для такого устройства не детализируют. Физически это может быть база данных, файл, таблица в оперативной памяти, картотека на бумаге и т.п.

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

Таким образом, DFD иллюстрирует как потоки данных, порожденные некоторыми внешними сущностями, трансформируются соответствующими процессами (или подсистемами), сохраняются накопителями данных и передаются другим внешним сущностям – приемникам информации. В результате мы получаем сетевую модель хранения / обработки информации.

Разработку модели предметной области с применением DFD выполняют в два этапа.

Первый этап – построение контекстной диаграммы – включает выполнение следующих действий:

· классификацию множества требований к проектируемой системе и организацию их в основные функциональные группы – процессы;

· идентификацию внешних объектов – внешних сущностей, с которыми система должна быть связана;

· идентификацию основных видов информации – потоков данных, циркулирующих между системой и внешними объектами;

· предварительную разработку контекстной диаграммы;

· изучение предварительной контекстной диаграммы и внесение в нее изменений, по результатам ответов на возникающие при изучении вопросы по всем ее частям;

· построение контекстной диаграммы путем объединения всех процессов предварительной диаграммы в один процесс, а также группирования потоков.

Второй этап – формирование иерархии диаграмм потоков данных – включает для каждого уровня:

· проверку и изучение основных требований по диаграмме соответствующего уровня (для первого уровня – по контекстной диаграмме);

· декомпозицию каждого процесса текущей DFD с помощью детализирующей диаграммы или – если некоторую функцию сложно или невозможно выразить комбинацией процессов, построение спецификации процесса;

· добавление определений новых потоков в словарь стрелок при каждом появлении их на диаграмме;

· проведение ревизии с целью проверки корректности и улучшения наглядности модели после построения двух-трех уровней.

Полная спецификация процессов включает также описание структур данных, используемых как при передаче информации в потоке, так и при хранении в накопителе. Описываемые структуры данных могут содержать альтернативы, условные вхождения и итерации. Условные вхождения обозначают, что соответствующие элементы данных в структуре могут отсутствовать. Альтернатива означает, что в структуру может входить один из перечисленных элементов. Итерация означает, что элемент может повторяться некоторое количество раз (см. п.3.4).

Кроме того, для данных должен быть указан соответствующий тип: непрерывное или дискретное значение. Для непрерывных данных могут определяться единицы измерений, диапазон значений, точность представления и форма физического кодирования. Для дискретных – может указываться таблица допустимых значений.

Полученную модель необходимо проверить на полноту и согласованность. Под согласованностью модели понимают выполнение для всех потоков данных правила сохранения информации: все поступающие куда-либо данные должны быть считаны и записаны.

Приведем пример разработки DFD программы построения графиков / таблиц функций (рис. 3.6. и рис. 3.7).

Внешняя сущность – студент, который вводит или выбирает из списка функцию, задает интервал и количество точек, а затем получает таблицу значений функции, и ее график. В результате детализации получаем три процесса и добавляем хранилище функций. Затем определяем потоки данных.

 

Рис. 3.6. Контекстная диаграмма программы построения

графиков функций (нотация Гейна - Сарсона)

 

Существенное отличие DFD от функциональных в том, что диаграммы потоков данных позволяют точно адресовать функции системы при наличии нескольких категорий пользователей.

 

Рис. 3.7. Детализирующая диаграмма потоков данных системы

исследования функций ( нотация Гейна - Сарсона)

Приведем еще один пример разработки иерархии DFD системы учета успеваемости студентов (рис.3.8).

Определим потоки данных между внешними сущностями и системой.

Декан должен получать:

· сводку успеваемости по факультету (процент успеваемости групп, курсов и в целом по факультету) на текущий или указанный момент времени;

· полные сведения об учебе конкретного студента (успеваемость по всем изученным предметам всех завершенных семестров обучения с учетом пересдач).

Заместитель декана по учебной работе должен получать:

· сводку успеваемости по курсу (процент успеваемости по группам) на текущий или указанный момент;

· сведения о сдаче экзаменов и зачетов указанной группы;

· текущие сведения об успеваемости конкретного студента;

 

Рис. 3.8. Контекстная диаграмма системы учёта успеваемости

студентов (нотация Гейна-Сарсона)

 

· полные сведения об учебе конкретного студента (успеваемость по всем изученным предметам всех завершенных семестров обучения с учетом пересдач);

· список задолжников по факультету с указанием групп и несданных предметов.

Сотрудник деканата должен обеспечивать:

· ввод списков студентов, зачисленных на первый курс;

· корректировку списков студентов в соответствии с приказами о зачислении, отчислении, переводе и т.п.;

· ввод учебных планов кафедр;

· ввод расписания сессии;

· ввод результатов сдачи экзаменов и зачетов на основании ведомостей и направлений.

Кроме этого, сотрудник деканата должен иметь возможность получать:

· справку о прослушанных студентом предметах с указанием часов и итоговых оценок;

· приложение к диплому выпускника с указанием часов и итоговых оценок.

Приведенный пример из [8] не соответствует положениям кредитной технологии обучения с точки зрения понятий и некоторых критериев оценки знаний, тем не менее, пример хорошо демонстрирует суть процесса контроля обучения и, используемые при этом, структуры данных.

Далее происходит детализация процессов в системе, рис. 3.9, где выделены две подсистемы: подсистема наполнения базы данных и подсистема формирования отчетов, а также хранилище данных, которое может быть реализовано как с помощью средств СУБД, так и без него.

Рис. 3.9. Детализирующая диаграмма потоков данных второго

уровня (нотация Гейна-Сарсона)

 

В заключении сделаем некоторые обобщения и дополнения к DFD.

DFD используется для описания документооборота и обработки информации и, представляет собой модельную систему как сеть связанных между собой работ (Activity). Стрелки DFD показывают, как объекты (включая данные) двигаются от одной работы к другой (в IDEF0 стрелки – это жесткие взаимосвязи). DFD рассматривает систему, как совокупность предметов, а не как систему взаимосвязанных работ, как в IDEF0. В DFD работы представляют собой функции системы, преобразующие входы в выходы. Также как работы IDEF0, они имеют входы и выходы, но не поддерживают управления и механизмы, как IDEF0.

Внешние сущности изображают входы в систему и/или выходы из системы. Одна внешняя сущность может быть использована многократно на одной или нескольких диаграммах.

Стрелки (потоки данных) описывают движение объектов из одной части системы в другую. В DFD применяются также двунаправленные стрелки для описания диалогов типа «команда-ответ» между работами, между работой и внешней сущностью и между внешними сущностями.

Хранилище данных – изображает объекты в покое, а не в движении, как в стрелках. В материальных системах хранилища данных изображаются там, где объекты ожидают обработки, например в очереди. В системах обработки информации хранилища данных являются механизмом, который позволяет сохранить данные для последующих процессов.

В DFD стрелки могут сливаться и разветвляться, что позволяет описать декомпозицию стрелок (декомпозицию данных). Каждый новый сегмент сливающейся или разветвляющейся стрелки может иметь собственное имя.

Техника построения диаграмм DFD подобна той, какая применяется для диаграммы IDEF0. Сначала строится физическая модель, отображающая текущее состояние дел, затем эта модель преобразуется в логическую модель, которая отображает требования к существующей системе. После этого строится логическая модель, отображающая требования к будущей системе. И наконец, строится физическая модель, на основе которой должна быть построена новая система.

Альтернативным подходом является подход, популярный при создании программного обеспечения, называемый событийным разделением (event partitioning), в котором различные диаграммы DFD выстраивают модель системы.

Во-первых, логическая модель строится как совокупность работ и документирования того, что эти работы должны делать.

Во-вторых, строится модель окружения (environment model), которая описывает систему как объект, взаимодействующий с событиями из внешних сущностей. Модель окружения обычно содержит описание цели системы, одну контекстную диаграмму и список событий.

В-третьих, строится модель поведения (behavior model), показывающая, как система обрабатывает события внешних сущностей. Эта модель состоит из модели окружения. Хранилища могут быть добавлены для моделирования данных, которые необходимо запоминать между событиями. Потоки добавляются для связи с другими элементами, и диаграмма проверяется с точки зрения соответствия модели окружения.

Нумерация объектов.

В DFD номер каждой работы может включать префикс, номер родительской работы (А) и номер объекта. Номер объекта – это уникальный номер работы на диаграмме. Например, работа может иметь номер А.12.4. Уникальный номер имеют хранилища данных и внешние сущности независимо от их расположения на диаграмме. Каждое хранилище данных имеет префикс D и уникальный номер, например D5. Каждая внешняя сущность имеет префикс Е (Event) и уникальный номер, например Е5.

В заключении следует отметить, что на диаграмме потоков данных можно дополнительно моделировать управляющие процессы. Для этого применяются диаграммы переходов состояний или диаграммы управляющих потоков данных, которые используют понятия: управляющий процесс, управляющий поток данных и, возможно, хранилище управляющих данных.

 

⇐ Предыдущая12345678910Следующая ⇒

Поделиться: