Что следует понимать под методологией sadt какой подход
Методология SADT
Методология SADT разработана Дугласом Россом. На ее основе разработана, в частности, известная методология IDEF0 (IcamDEFinition), которая является основной частью программы ICAM (Интеграция компьютерных и промышленных технологий), проводимой по инициативе ВВС США.
Методология SADT представляет собой совокупность методов, правил и процедур, предназначенных для построения функциональной модели объекта какой-либо предметной области. Функциональная модель SADT отображает функциональную структуру объекта, т.е. производимые им действия и связи между этими действиями. Основные элементы этой методологии основываются на следующих концепциях:
1. графическое представление блочного моделирования. Графика блоков и дуг SADT-диаграммы отображает функцию в виде блока, а интерфейсы входа/выхода представляются дугами, соответственно входящими в блок и выходящими из него. Взаимодействие блоков друг с другом описываются посредством интерфейсных дуг, выражающих «ограничения», которые в свою очередь определяют, когда и каким образом функции выполняются и управляются;
2. строгость и точность. Выполнение правил SADT требует достаточной строгости и точности, не накладывая в то же время чрезмерных ограничений на действия аналитика. Правила SADT включают:
3. ограничение количества блоков на каждом уровне декомпозиции (правило 3-6 блоков);
4. связность диаграмм (номера блоков);
5. уникальность меток и наименований (отсутствие повторяющихся имен);
6. синтаксические правила для графики (блоков и дуг);
7. разделение входов и управлений (правило определения роли данных).
8. отделение организации от функции, т.е. исключение влияния организационной структуры на функциональную модель.
Методология SADT может использоваться для моделирования широкого круга систем и определения требований и функций, а затем для разработки системы, которая удовлетворяет этим требованиям и реализует эти функции. Для уже существующих систем SADT может быть использована для анализа функций, выполняемых системой, а также для указания механизмов, посредством которых они осуществляются.
3. Методологии и нотации описания бизнес-процессов
Функциональное моделирование в методике IDEF0
Тема 7. Методология функционального моделирования SADT
Тема 7. Методология функционального моделирования SADT
Оглавление
Основные понятия методологии IDEF0. 3
Функциональный блок (Activity Box). 3
Интерфейсная стрелка. 4
Принцип функциональной декомпозиции. 9
Принцип ограничения сложности.. 10
Принцип контекста (целеполагания) 10
Правила построения IDEF0 диаграмм.. 11
Правило контекста. 11
Правило «доминирования». 11
Правило ограничения сложности.. 12
Правило выбора управления. 12
Правила нумерации и именования диаграмм, блоков и дуг. 13
Правила компоновки объектов диаграмм.. 14
Процесс моделирования. 16
Моделирование сложных систем (какими является большинство современных промышленные системы) было начато в программе интегрированной автоматизации производства (ICAM – Integrated Computer Aided Manufacturing) Министерства обороны США, в которой была признана полезность методологии SADT (Structured Analysis and Design Technique – Технология структурного анализа и проектирования), разработанная в 1973 г. Дугласом Россом. На ее основе разработана методология IDEF0 (ICAM DEFinition или Integration Definition for Function Modeling), которая является основной частью программы ICAM (Интеграция компьютерных и промышленных технологий), проводимой по инициативе ВВС США.
Методология SADT представляет собой совокупность методов, правил и процедур, предназначенных для построения функциональной модели объекта какой-либо предметной области. Функциональная модель SADT отображает функциональную структуру объекта, т. е. производимые им действия и связи между ними. Основные элементы этой методологии основываются на следующих концепциях:
1. графическое представление блочного моделирования. Графика блоков и дуг SADT-диаграммы отображает функцию в виде блока, а интерфейсы входа/выхода представляются дугами. Взаимодействие блоков друг с другом описываются посредством интерфейсных дуг, выражающих «ограничения», которые определяют, когда и как функции выполняются и управляются;
2. строгость и точность. Выполнение правил SADT требует достаточной строгости и точности, не накладывая в то же время чрезмерных ограничений на действия аналитика. Правила SADT включают:
− ограничение количества блоков на каждом уровне декомпозиции (правило 3-6 блоков);
− связность диаграмм (номера блоков);
− уникальность меток и наименований (отсутствие повторяющихся имен);
− синтаксические правила для графики (блоков и дуг);
− разделение входов и управлений (правило определения роли данных).
3. отделение организации от функции, то есть исключение влияния организационной структуры на функциональную модель.
Методология SADT может использоваться для моделирования широкого круга систем и определения требований и функций, а затем для разработки системы, которая удовлетворяет этим требованиям и реализует эти функции. Для уже существующих систем SADT может быть использована для анализа функций, выполняемых системой, а также для указания механизмов, посредством которых они осуществляются.
Далее приведем характеристику стандарта функционального моделирования IDEF0, основные принципы и правила построения диаграмм в соответствии с данным стандартом и обосновать причины выбора его для проектирования ИС отдела УМК МБИ.
C 1981 г. стандарт IDEF0 претерпел несколько незначительных изменений, в основном ограничивающего характера, и последняя его редакция была выпущена в декабре 1993 года Национальным Институтом по Стандартам и Технологиям США (NIST). В 2000 г. – IDEF0 был принят в качестве стандарта и в Российской Федерации (РД IDEF0-2000).
Методология моделирования SADT (IDEF0) предназначена для анализа всей системы как множества взаимодействующих взаимосвязанных функций.
Далее приведено описание основных понятий, связанных с использованием данной методологии в настоящей работе.
Основные понятия методологии IDEF0
IDEF0 – методология функционального моделирования. С помощью простого графического языка IDEF0 моделирование систем позволяет разработчикам и аналитикам представить систему в виде набора взаимосвязанных функциональных блоков.
Функциональный блок (Activity Box).
ОПР1.: В основе IDEF0 методологии лежит понятие блока, который отображает некоторую функцию.
В соответствии с методологией IDEF0 любой процесс представляется в виде функционального блока, который преобразует входы в выходы при наличии необходимых ресурсов (механизмов) в управляемых условиях.
ОПР2.: Функциональный блок (или Функция) преобразует Входы в Выходы. Управление определяет, когда и как это преобразование может или должно произойти. Механизмы непосредственно осуществляют это преобразование.
Функциональный блок графически изображается в виде прямоугольника и представляет собой некоторую конкретную функцию в моделируемой системе. Название каждого функционального блока должно быть сформулировано в глагольном наклонении (например, «производить услуги», а не «производство услуг»). Каждый функциональный блок в рамках единой рассматриваемой системы должен иметь свой уникальный идентификационный номер. Каждая из четырех сторон функционального блока имеет своё определенное значение (роль) (Рис. 68):
– верхняя сторона – «Управление» (Control);
– левая сторона – «Вход» (Input);
– правая сторона – «Выход» (Output);
– нижняя сторона – «Ресурсы» (Mechanism).
Рис. 68 Функциональный блок
Интерфейсная стрелка
Интерфейсная стрелка, интерфейсная дуга или поток (Arrow). Интерфейсная стрелка отображает элемент системы, который обрабатывается функциональным блоком или оказывает влияние на функцию, отображенную данным функциональным блоком. С дугами связаны надписи (или метки) на естественном языке, описывающие данные, которые они представляют.
ОПР.: Взаимодействие между функциями (блоками) в IDEF0 представляется в виде дуги, которая отображает поток данных или материалов, поступающий с выхода одной функции на вход другой.
Выходы одной функции могут быть Входами, Управлением или Механизмами для другой. В зависимости от того, с какой стороной блока связан поток, его называют соответственно “входным”, “выходным”, “управляющим”.
1. Интерфейсная стрелка «вход» (Input) — это материалы, предметы или информация, которые трансформируются в процессе выполнения функции с целью получения результата. Стрелки входа соединяются с левой стороной блока. Некоторые блоки могут не иметь стрелок входа, поскольку не каждая функция преобразует или изменяет что-либо.
2. Интерфейсная стрелка «управление» (Control) определяет как, когда и в каком случае выполняется функция, и какой результат от нее ожидается. Каждая функция (IDEF0-блока) должна иметь как минимум один вход управления. Управление часто представляется в виде правил, норм, процедур, стандартов. Они оказывают влияние на выполнение функции, не изменяясь при этом сами. Управление – это особый тип входных данных функции. Часто даже возникает вопрос, какого типа должна быть стрелка: вход или управление.
3. Интерфейсная стрелка «ресурс» или «механизм» (Mechanism) обозначает те ресурсы, при помощи которых выполняется функция. В качестве механизма выступают люди, машины, оборудование, которые обеспечивают все необходимое для реализации функции. IDEF0-блок может не содержать стрелок механизма. Это объясняется тем, что знание механизма, осуществляющего функцию, зачастую не является целью моделирования системы.
4. Интерфейсная стрелка «выход» (Output) – это материалы, предметы, информация, производимые функцией, это результат выполнения функции. Каждый блок обязательно имеет хотя бы одну стрелку выхода. При моделировании непроизводственных процессов, выходом функции часто являются данные, которые были обработаны или переработаны по алгоритму, определяемому функцией.
5. Интерфейсные стрелки ссылки (Call Arrow) используются для указания на другие модели или диаграммы внутри модели, которые помогают лучше понять модель. Интерфейсная стрелка ссылки может ссылаться на другую диаграмму внутри самой модели или на специфическое дочернее действие другой модели. Данный вид стрелок в дипломной работе не использовался.
Одним из главных отличий стандарта IDEF0 от других методологий классов DFD (Data Flow Diagram) и WFD (Work Flow Diagram) является обязательное наличие управляющих интерфейсных стрелок.
Дуги позволяют отражать взаимосвязи между блоками. По типу этой связи выделяют 5 видов взаимодействия (Рис. 69). Примеры данных взаимодействий и их отражения на модели показаны на схемах (Рис. 70, Рис. 71, Рис. 72, Рис. 73, Рис. 74).
Рис. 69. Варианты взаимодействия функциональных блоков
Рис. 70. Взаимодействие типа выход-вход
Рис. 71. Взаимодействие типа выход-управление
Рис. 72. Взаимодействие типа выход-механизм
Рис. 73. Взаимодействие типа ОС выход-управление
Рис. 74. Взаимодействие типа ОС выход-вход
Модель в IDEF0
Модель в IDEF0 представляет собой совокупность иерархически упорядоченных и взаимосвязанных диаграмм. Каждая диаграмма располагается на отдельном листе (Рис. 75).
Модель IDEF0 всегда начинается с представления системы как единого целого – одного функционального блока с интерфейсными стрелками, простирающимися за пределы рассматриваемой области. Такая диаграмма с одним функциональным блоком называется контекстной диаграммой, и обозначается идентификатором А-0.
Ни одна модель не может быть создана без конкретного объекта или цели. Формулировка цели должна ответить на следующие вопросы: почему был смоделирован данный процесс; что модель собирается показать; что с ней могут сделать читающие. Формулировка цели позволяет команде экспертов придерживаться ее в течение всего моделирования. Без формулировки цели моделирование может зайти в тупик.
Модели создаются для получения ответа на ряд вопросов. Данные вопросы должны подготавливаться заранее и будут служить основой для создания цели модели. Примерные вопросы могут звучать следующим образом: каковы основные задачи сотрудника; кто отвечает за произведенную продукцию; кто управляет начальной стадией производства; какой требуется инструмент для каждого этапа.
Точка зрения (Viewpoint). Особенно важно включать в процесс разработки модели представителей различных мнений, однако сама модель должна базироваться на единой точке зрения. Чаще всего разнообразные точки зрения кратко фиксируют на диаграмме ФЕО (FEO – For Exposition Only – только для комментариев). Эти диаграммы используются только в качестве материалов для презентаций.
Точка зрения должна формулироваться исходя из цели построение диаграммы. При построении модели важно придерживаться одной точки зрения, которая должна содержать наименование должности, структурного подразделения или описание должностных обязанностей работника. Модели могут содержать разнообразные точки зрения с целью детальной фиксации всех действий (функций).
В комментариях к контекстной диаграмме должна быть указана цель (Purpose) построения диаграммы в виде краткого описания и зафиксирована точка зрения (Viewpoint).
Определение и формализация цели разработки и точки зрения IDEF0 – модели является крайне важным моментом. Фактически цель определяет соответствующие области в исследуемой системе, на которых необходимо обратить внимание в первую очередь. Точка зрения определяет основное направление развития модели и уровень необходимой детализации. Четкое фиксирование точки зрения позволяет разгрузить модель, отказавшись от детализации и исследования отдельных элементов, не являющихся необходимыми, исходя из выбранной точки зрения на систему.
Диаграммы IDEF0 второго уровня называются дочерней (Child diagram) по отношению к первому (каждый из функциональных блоков, принадлежащих дочерней диаграмме соответственно называется дочерним блоком – Child Box). В свою очередь, функциональный блок – предок называется родительским блоком по отношению к дочерней диаграмме (Parent Box), а диаграмма, к которой он принадлежит – родительской диаграммой (Parent Diagram).
При декомпозиции функционального блока все стрелки, входящие в данный блок, или исходящие из него фиксируются на дочерней диаграмме. Этим достигается структурная целостность IDEF0-модели. Каждый блок имеет свой уникальный порядковый номер на диаграмме (цифра в правом нижнем углу), а обозначение под правым углом указывает на номер дочерней для этого блока диаграммы. Отсутствие этого обозначения говорит о том, что декомпозиции для данного блока не существует.
Туннели (Tunnels). Связывание интерфейсных стрелок используется в моделях для определения уровня детализации. Когда интерфейсная стрелка не возникает на базовой диаграмме, но не связана с другими стрелками, туннель используется для указания того, что интерфейсная стрелка входит или выходит из системы. Туннель используется, чтобы не загромождать базовую диаграмму. В других случаях туннель может быть использован в интерфейсной стрелке, ведущей к базовому действию. Это указывает, что взаимоотношения интерфейсной стрелки с дочерними действиями не определены.
Глоссарий (Glossary). Для каждого из элементов IDEF0 (диаграмм, функциональных блоков, интерфейсных стрелок) существующий стандарт подразумевает создание и поддержание набора соответствующих определений, ключевых слов, повествовательных изложений и т. д., которые характеризуют объект, отображенный данным элементом. Этот набор называется глоссарием и является описанием сущности данного элемента. Он дополняет наглядный графический язык, снабжая диаграммы необходимой дополнительной информацией.
Принципы IDEF0
Принцип функциональной декомпозиции.
Принцип декомпозиции или, как его еще называют принцип «разделяй и властвуй» применяется при разбиении сложного процесса на составляющие его функции. Декомпозиция позволяет представить модель системы в виде иерархической структуры отдельных диаграмм, что делает ее менее перегруженной и легко усваиваемой.
Суть принципа функциональной декомпозиции очень прост (Рис. 75):
1. Функциональный блок, который представляет систему в качестве единого модуля, детализируется на другой диаграмме с помощью нескольких блоков, соединенных между собой дугами.
2. Эти блоки представляют основные подфункции (подмодули) единого исходного модуля.
3. Данная декомпозиция выявляет полный набор подмодулей, каждый из которых представлен как блок, границы которого определены дугами.
4. Каждый из этих подмодулей может быть декомпозирован подобным же образом для более детального представления.
Рис. 75. Декомпозиция процесса
Принцип ограничения сложности
При работе с IDEF0 диаграммами существенным является условие их разборчивости и удобочитаемости, поэтому количество блоков на диаграмме должно быть не менее двух и не более шести. Такой диапазон вызван учетом особенностей психологии человеческого восприятия. Практика показывает, что соблюдение этого принципа приводит к тому, что функциональные процессы, представленные в виде IDEF0 модели, хорошо структурированы, понятны и легко поддаются анализу.
Принцип контекста (целеполагания)
Как было указано выше любая модель должна отвечать на вопросы о системе («М есть модель системы S, если М может быть использована для получения ответов на вопросы относительно S с точностью А»). Это означает, что не может быть модели вообще. Любая модель – это лишь инструмент и чтобы правильно ее создать надо иметь однозначное представление о цели моделирования (Purpose), точке зрения (Viewpoint) и границах моделирования (Scope). Принцип целеполагания как раз и означает, что любая модель в SADT – должна быть определена прежде всего по перечисленным трем позициям.
Правила построения IDEF0 диаграмм
Выполнение вышеперечисленных принципов требует введения ряда ограничений, которые должен выполнять любой автор IDEF0 модели. Как было указано ранее, эти требования сведены в документе РД IDEF0-2000. Основные из этих правил приведем ниже с необходимыми комментариями.
Правило контекста
В составе модели должна присутствовать контекстная диаграмма number prefix-0 (например, А-0), которая содержит только один блок. Номер единственного блока на контекстной диаграмме А-0 должен быть 0 (Рис. 76). Это правило обеспечивает выполнение принципа контекста.
Рис. 76. Пример контекстной диаграммы
Правило «доминирования»
Рис. 77. Правило доминирования
Правило ограничения сложности
Это правило дополняет одноименный принцип. Неконтекстные диаграммы должны содержать не более шести блоков. Это ограничение поддерживают сложность диаграмм на уровне, доступном для чтения, понимания и использования.
Диаграммы с количеством блоков более шести сложны для восприятия читателями и вызывают у автора трудности при внесении в нее всех необходимых графических объектов и меток.
Однако, несмотря на существование этого правила в реальной практике моделирования из него иногда допускаются исключения. Более подробно об этих исключениях будет рассказано ниже.
Правило выбора управления
Часто возникает проблема, когда автор модели не может однозначно определить, к какому из типов дуг отнести ту или иную интерфейсную стрелку. Прежде всего такая ситуация возникает, когда речь идет об отображении на диаграмме информационных потоков. Для преодоления этой проблемы и существует правило выбора управления. В соответствии с этим правилом если одни и те же данные служат и для управления, и для входа, вычерчивается только стрелка управления. Этим подчеркивается управляющий характер данных и уменьшается сложность диаграммы (Рис. 78).
Рис. 78. Правило выбора управления
Правила нумерации и именования диаграмм, блоков и дуг
Правило нумерации блоков
Рис. 79. Правило нумерации блоков
Правило нумерации диаграмм
Каждая диаграмма имеет свой уникальный код, который формируется следующим образом (Рис. 80):
NP – number prefix (например TD);
N – номер блока на диаграмме NP0;
M – номер блока на диаграмме NP N.
Рис. 80. Правило именования диаграмм
Каждый блок, подвергнутый декомпозиции, должен иметь отметку об этом.
Имена блоков (выполняемых функций) и метки дуг должны быть уникальными (Рис. 81). Если метки интерфейсных стрелок совпадают, это значит, что стрелки отображают тождественные данные.
Рис. 81. Правило именования
Правила компоновки объектов диаграмм
Правило компоновки блоков
Следует обеспечить максимальное расстояние между блоками и поворотами стрелок, а также между блоками и пересечениями стрелок для облегчения чтения диаграммы. Одновременно уменьшается вероятность перепутать две разные стрелки.
Правило рисования стрелок
Надо пытаться максимально увеличивать расстояние между параллельными стрелками (Рис. 82), что облегчает размещение меток, их чтение и позволяет проследить пути стрелок.
Рис. 82. Правило рисования дуг
Правило минимизации пересечений
При соединении большого числа блоков необходимо избегать необязательных пересечений стрелок. Следует минимизировать число петель и поворотов каждой стрелки (Рис. 83).
Рис. 83. Правило минимизации пересечений
Правило связывания дуг
Дуги связываются (сливаются), если они представляют сходные данные и их источник не указан на диаграмме.
Дуги объединяются, если они имеют общий источник или приемник, или они представляют связанные данные. Общее название лучше описывает суть данных. Следует минимизировать число дуг, касающихся каждой стороны блока, если, конечно, природа данных не слишком разнородна (Рис. 84).
Рис. 84. Правило связывания дуг
Правило присоединения дуг к блокам
Если возможно, дуги присоединяются к блокам в одной и той же позиции. Тогда соединение дуг конкретного типа с блоками будет согласованным и чтение диаграммы упростится (Рис. 85).
Рис. 85. Правило присоединения дуг к блокам
Процесс моделирования
В одной из лучших книг по SADT-моделированию дается следующая характеристика этой методологии: «В значительной мере успех методологии SADT объясняется ее графическим языком, хотя не менее ценным является сам процесс моделирования. Процесс моделирования в SADT включает сбор информации об исследуемой области, документирование полученной информации и представление ее в виде модели и уточнение модели посредством итеративного рецензирования. Кроме того, этот процесс подсказывает вполне определенный путь выполнения согласованной и достоверной структурной декомпозиции, что является ключевым моментом в квалифицированном анализе системы. SADT уникальна в своей способности обеспечить как графический язык, так и процесс создания непротиворечивой и полезной системы описаний». Если процесс моделирования описанный в РД IDEF0-2000 представить в нотации IDEF0, то получится следующее видение (Рис. 86).
Рис. 86. Процесс IDEF0 моделирования
Именно то, что SADT представляет собой не просто нотацию, но, прежде всего системный подход к анализу и синтезу сложных систем делает SADT полноценной методологией, которая нашла широкое распространение не только в сфере создания ИС, но и в областях связанных с оптимизацией организационно-экономических и производственно-технических систем.