Изображение объектов диаграммы иерархии функций

Объект	Йодана	Гейна-Сарсона	SADT	SAG
I. Функция		№ Имя	Имя №
2. Декомпозиция функции			осуществляется с помощью иерархически взаимосвязанных уровней детализации
Приемка товара

Методология SADT

Рассмотрим наиболее актуальную в настоящее время методологию структурного проектирования ИС.

Методология функционального проектирования SADT была разработана Дугласом Россом и получила дальнейшее развитие в известной методологии IDEF0 (Icam DEFinition), которая явилась основной частью программы ICAM (Интеграция компьютерных и промышленных технологий), проводимой по инициативе ВВС США, в основе методологии лежит структурный подход к проектированию ИС.

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

Система разбивается на:

• функциональные подсистемы, которые в свою очередь делятся на

• подфункции, подразделяемые на

• задачи и так далее.

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

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

Методология SADT – это совокупность методов, правил и процедур, предназначенных для построения функциональной модели объекта какой-либо предметной области.

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

• графическое представление блочного моделирования. Графика блоков и дуг SADT-диаграммы отображает функцию в виде блока (рис. 2), а интерфейсы входа/выхода представляются дугами, соответственно входящими в блок и выходящими из него. Взаимодействие блоков друг с другом описываются посредством интерфейсных дуг, выражающих "ограничения", которые в свою очередь определяют, когда и каким образом функции выполняются и управляются;

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

Рис. 2.

Правила методологии SADT включают:

• ограничение количества блоков на каждом уровне декомпозиции (правило 3-6 блоков);

• связность диаграмм (номера блоков);

• уникальность меток и наименований (отсутствие повторяющихся имен);

• синтаксические правила для графики (блоков и дуг);

• разделение входов и управлений (правило определения роли данных).

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

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

Диаграммы - главные компоненты модели, все функции ИС и интерфейсы на них представлены как блоки и дуги.

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

Методология SADT может использоваться для моделирования широкого круга систем и определения требований и функций, а затем для разработки системы, которая удовлетворяет этим требованиям и реализует эти функции.

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

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

В качестве примера рассмотрим фрагмент диаграммы иерар­хий функций в нотации SAG (рис.3.) для задачи аналитического учета товаров на складе.

Согласно рис.3, одной из функций аналитического уче­та товаров на складе является организация товародвижения. Да­лее эта функция декомпозируется на следующие подфункции: приемка товара; отпуск товара; ведение БД «Движение товаров»; инвентарный контроль.

Организация

товародвижения

на складе

Приемка Отпуск Ведение БД Инвентарный

товара товара «Движение товара» контроль

Рис.3. Фрагмент диаграммы иерархии функций для задачи аналитического учета товаров на складе

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

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

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

Потоки данных – отражают передачу информации от одного процесса к другому. (направленная стрелка, указывающая направление движения информации или материалов).

Процесс - преобразование входной информации в выходную. Имя процесса содержит глагол в неопределенной форме с последующим дополнением (например, «нарисовать форму»).

Хранилище информации - позволяет на определенных участ­ках ДПД сохранить в памяти данные между процессами. Имя хранилища должно идентифицировать его, а также его содержимое, выражается существительным.

Внешняя сущность (источник/приемник данных) - объект вне системы, являющийся внешним объек­том.

Контекстная диаграмма - самый верхний процесс (ТОР-уро­вень) декомпозиции системы, который отражает общие представ­ления о системе. В контекстной диаграмме есть один процесс, с кото­рым связаны внешние сущности.

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

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

• на каждом уровне представлять 3-6 процессов и не более; не загромождать диаграмму несущественными моментами на данном уровне детализации;

• декомпозицию процессов и потоков вести параллельно;

• выбирать ясные, отражающие суть объектов, имена для всех объектов ДПД;

• однократно определять функционально идентичные процес­сы (в других местах просто ссылаться на этот процесс);

• использовать ДПД для процессов, которые можно описать с их помощью.

Пример контекстной диаграммы и диаграмм l-ro уровня в нотации SADT для задачи аналитического учета товаров на скла­де приведен на рис.4. На уровне контекстной диаграммы по­казаны основная цель построения ДПД и потоки информации, необходимые для ее достижения. в дальнейшем контекстная ди­аграмма детализируется на первом уровне, где отражаются основные функции, которые взаимосвязаны информационными потоками.

Диаграммы переходов состояний (ДПС), (STD) моделируют поведение системы во времени в зависимости от происшедших событий (нажатая клавиша, дата отчетного периода и т.д.). Такие диаг­раммы позволяют осуществить декомпозицию управляющих про­цессов, происходящих в системе, и описать отношение между уп­равляющими потоками. С помощью ДПС можно моделировать последующее функционирование системы исходя из предыдущих и текущего состояний.

Товарно-сопроводительные док-ты Нормативы складского учета Приказ (распоряжение) об инвентаризации

АРМ работника склада Менеджер по инвентар-ции

Организация учета товародвижения на складе операции

Рис.4. Контекстная диаграмма и диаграмма 1-го уровня в нотации SADT для задачи аналитического учета товаров на складе

Моделируемая система в текущий момент времени находится только в одном состоянии из всего множества состояний. В течение времени она может изменить свое состояние и тем самым пе­рейти в следующее состояние из заданного множества состояний. Для перехода в состояние нужно какое-либо особое условие - условие перехода. Оно может быть информационным (условие появления информации) или временным. В тaбл.2 представле­ны символы ДПС в различных нотациях. Определим основные объекты ДПС.

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

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

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

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

Условие перехода - событие, вызывающее переход и идентифицируемое именем перехода.

Фрагмент диаграммы переходов состояний для задачи ана­литического учета товаров на складе в нотации SAG приведен на рис.5. Текущее состояние системы представлено ожиданием выбора того или иного пункта меню. Выбранный пункт меню - это информационное событие, а сам выбор - действие перехода в следующее состояние системы. Переход в состояние системы «Ведение БД «Движение товаров»» выпол­няется по логическому условию ИЛИ, что отражено в триггере. Одно из событий этого перехода является временным (дата закрытия периода).

Таблица 2