logo
9 сем

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

SADT (технология структурного анализа и проектирования) — одна из самых известных методологий анализа и проектирования си­стем, введенная в 1973 года Россом. Используется повсеместно.

Типы моделей по SADT:

-модель активностей системы (другие названия — бизнес-функции, работы)- основывается на функциях системы/блока;

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

Основным элементом в модели по SADT является диаграмма (рис. 3.7). Модель может объединять несколько диаграмм в одну иерархию. Чем глубже диаграмма находится в иерархии, тем более она детализована, т.е. тем более подробно отображает данные или ак­тивности системы или блока.

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

Обычно в качестве точки зрения выбирается точка зрения лица или объекта, ответственного за работу моделируемой системы в целом.

Диаграммы более низких уровней имеют подобный вид, но отоб­ражать контекст только одного из блоков системы.

Блоки на диаграмме размещаются по «ступенчатой» схеме в со­ответствии с их доминированием — влиянием, которое один блок оказывает на другие. Часто блоки еще и нумеруют, также в соответ­ствии с доминированием.

95

Этот язык придумали американские военные с целью успешного тиражирования бизнес-процессов предприятий аэрокосмической промышленности. В свое время американские военные столкнулись со следующей проблемой. При проектировании заводов было заме­чено, что каждый раз приходится заново проделывать один и тот же шаг — проектировать одинаковые подсистемы управления, на что уходило дополнительное время и ресурсы. После этого было пред­ложено разработать язык или чертеж, с помощью которого можно было бы описать типовые подсистемы управления и при строитель­стве нового завода использовать наработанные схемы. Язык, который был придуман и использован для этих целей, лег в основу методоло­гии описания бизнес-процессов IDEF0.

Графический язык IDEF0 удивительно прост и гармоничен. В основе методологии лежат четыре основных понятия:

  1. функциональный блок;

  2. интерфейсная дуга;

96

3) декомпозиция;

4)глоссарий.

Функциональный блок (Activity Box) графически изображает­ся в виде прямоугольника (рис. 3.8) и олицетворяет собой некоторую конкретную функцию в рамках рассматриваемой системы. По требо­ваниям стандарта название каждого функционального блока должно быть сформулировано в глагольном наклонении (например, «произ­водить услуги», а не «производство услуг»).

Каждая из четырех сторон функционального блока имеет своё определенное значение (роль), при этом:

Каждый функциональный блок в рамках единой рассматривае­мой системы должен иметь свой уникальный идентификационный номер.

Отличительным атрибутом методологии IDEF0 является поня­тие интерфейсной дуги (Arrow). Также интерфейсные дуги часто называют потоками или стрелками. Интерфейсная дуга отображает элемент системы, который обрабатывается функциональным блоком или оказывает иное влияние на функцию, отображенную данным функциональным блоком.

Графическим отображением интерфейсной дуги является одно­направленная стрелка. Каждая интерфейсная дуга должна иметь свое

97

уникальное наименование (Arrow Label). По требованию стандарта, наименование должно быть оборотом существительного.

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

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

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

98


На рис 3.9 показан пример бизнес-процесса «Выточить деталь».

Бизнес-процесс «Выточить деталь» выполняет токарь. Входом про­цесса является заготовка, из которой вытачивается деталь она физически преобразуется в процессе. Для того, что бы токарь начал точить деталь ему нужно дать задание или план. Также ему понадо­бится чертеж: с размерами детали. Так вот, чертеж:, задание или план нужны для реализации бизнес-процесса и процесс без них не начнется, но по ходу выполнения процесса они не преобразуются. Со­гласно стандарту IDEFO их относят к управлению. Для того, что бы выточить деталь, нужен токарь, нужен станок их относят к ме­ханизмам. Выходами или результатами бизнес-процесса является де­таль.

Принцип декомпозиции (Decomposition) в методологии IDEF0 применяется при разбиении сложного процесса на составляющие его функции. При этом уровень детализации процесса определяется непосредственно разработчиком модели.

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

Глоссарий гармонично дополняет наглядный графический язык, снабжая диаграммы необходимой дополнительной информацией.

101


Стандарт IDEF0 получил большое распространение в США и ак­тивно используется в России. Практика показала, что стандарт IDEF0 целесообразно использовать в проектах по описанию и оптимизации локальных бизнес-процессов, в небольших проектах в которых больше участвуют и принимают решения специалисты предметных областей, а руководители высшего уровня привлекаются для приня­тия решений по минимуму. На рис. 3.11-3.12 приведены диаграммы IDEF0 верхнего уровня.

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

Методология DFD в нотациях Гейна-Сарсона и Йордана-Де Марко

Следующий стандарт описания бизнес-процессов, который по­лучил распространение, был разработан на основе развития клас­сической методологии DFD. Данный стандарт представлен двумя вариантами, которые называют нотациями. Первая из них называ­ется нотацией Гейна Сарсона, вторая — нотацией Йордона-Де Марко.

Гейн Сарсон, предложил классическую DFD-схему немного усложнить. Он предложил ввести дополнительный объект, с помо-

!04

іью которого показываются места оизнес-процесса, в которых хра­нится информация, либо материальные ресурсы. Примерами таким мест являются архив, в котором хранятся документы, база данных, в которой хранится информация, либо склад, на котором хранятся ма­териальные ресурсы. Данный объект получил название — хранилище

данных.

Нотация Иордона-Де Марко методологии DFD аналогична нота­ции Гейна Саросна, за исключение форм объектов: для описаний операций бизнес-процесса вместо закругленных прямоугольников стали использоваться круги, немного видоизменились и другие объ­екты — хранилище данных и внешние сущности:

На DFD-схемах в нотациях Гейна-Сарсона и Иордона-Де Марко также используются объекты, с помощью которых показывают внешних субъектов, с которыми бизнес-процесс взаимодействует. Данные объекты называют внешними сущностями.

С помощью диаграмм потоков данных DFD (Data Flow Diagrams) процессы в системе представляются в виде сети, связанной потоками данных. Главная цель этих диаграмм — продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между процессами. Для представления DFD традиционно используются две нотации — Иордана-Де Марко и Гейна-Сарсона (рис. 3.14, 3.15), отличающиеся символами для обо­значения процессов и хранилищ данных (табл. 3.4).

Приведенный пример диаграммы в нотации Гейна-Сарсона представ­ляют самый верхний уровень функциональной модели. Это весьма по­верхностное описание предметной области. Уточнение модели произ­водится путем детализации необходимых функций на DFD-диаграмме следующего уровня. Так .можно разбить функцию «Определение по­требностей и обеспечение материалами» на подфункции «Определе­ние потребностей», «Поиск поставщиков», «Заключение и анализ до­говоров на поставку», «Контроль платежей», «Контроль поставок», связанные собственными потоками данных, которые будут представ­лены на отдельной диаграмме. Детализация модели должна произво­дится до тех пор, пока она не будет содержать всю информацию, не­обходимую для построения информационной системы.