Методология SADT и стандарты IDEF

Мировой опыт свидетельствует, что внедрению на предприятии ИС должно предшествовать серьезное функционально-информационное обследование предприятия, с целью определения оптимальности бизнеспроцессов, распределения ресурсов между функциями и т.д.

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

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

Автор методологии, Дуглас Росс, в 1969 г. часть своих теорий, относящихся к методологии и языку описания систем, назвал SADT "Structured Analysis and Design Technique" ("Методология структурного анализа и проектирования"). Первое ее крупное приложение было реализовано в 1973 г. при разработке большого аэрокосмического проекта, а на рынке SADT появляется в 1975 г.

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

С помощью SADT -методологии решаются следующие основные задачи (для систем любой природы):

­ анализ функций, выполняемых системой;

­ описание спецификаций требований и функций проектируемой системы;

­ проектирование системы.

В основе пакета лежит доведенное до уровня стандарта подмножество SADT методология IDEF (Integrated Definition - Интегрированная автоматизированная система управления технологическими процессами или интегрированное описание процессов или систем), состоящая из следующих методологий:

­ IDEF 0 — Function Modeling — методология функционального моделирования. С помощью наглядного графического языка IDEF 0 изучаемая система предстает перед разработчиками и аналитиками в виде набора взаимосвязанных функций (функциональных блоков — в терминах IDEF 0). Как правило, моделирование средствами IDEF 0 является первым этапом изучения любой системы;

­ IDEF 1 — Information Modeling — методология моделирования информационных потоков внутри системы, позволяющая отображать и анализировать их структуру и взаимосвязи;

­ IDEF 1 X (IDEF 1 Extended) — Data Modeling — методология построения реляционных структур (баз данных), относится к типу методологий «Сущность-взаимосвязь» (ER — Entity-Relationship) и, как правило, используется для моделирования реляционных баз данных, имеющих отношение к рассматриваемой системе;

­ IDEF 2 — Simulation Model Design — методология динамического моделирования развития систем. В связи с весьма серьезными сложностями анализа динамических систем от этого стандарта практически отказались, и его развитие приостановилось на самом начальном этапе. В настоящее время присутствуют алгоритмы и их компьютерные реализации, позволяющие превращать набор статических диаграмм IDEF 0 в динамические модели, построенные на базе «раскрашенных сетей Петри» (CPN — Color Petri Nets);

­ IDEF 3 — Process Description Capture — Документирование технологических процессов,

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

­ IDEF 4 — Object-Oriented Design — методология построения объектно-ориентированных систем, позволяют отображать структуру объектов и заложенные принципы их взаимодействия, тем самым позволяя анализировать и оптимизировать сложные объектно-ориентированные системы;

­ IDEF 5 — Ontology Description Capture — Стандарт онтологического исследования сложных систем. С помощью методологии IDEF 5 онтология системы может быть описана при помощи определенного словаря терминов и правил, на основании которых могут быть сформированы достоверные утверждения о состоянии рассматриваемой системы в некоторый момент времени. На основе этих утверждений формируются выводы о дальнейшем развитии системы и производится её оптимизация;

­ IDEF 6 — Design Rationale Capture — Обоснование проектных действий. Назначение IDEF 6 состоит в облегчении получения «знаний о способе» моделирования, их представления и использования при разработке систем управления предприятиями. Под «знаниями о способе» понимаются причины, обстоятельства, скрытые мотивы, которые обуславливают выбранные методы моделирования. Проще говоря, «знания о способе» интерпретируются как ответ на вопрос: «почему модель получилась такой, какой получилась?» Большинство методов моделирования фокусируются на собственно получаемых моделях, а не на процессе их создания. Метод IDEF 6 акцентирует внимание именно на процессе создания модели;

­ IDEF 7 — Information System Auditing — Аудит информационных систем. Этот метод определён как востребованный, однако так и не был полностью разработан;

­ IDEF 8 — User Interface Modeling — Метод разработки интерфейсов взаимодействия оператора и системы (пользовательских интерфейсов). Современные среды разработки пользовательских интерфейсов в большей степени создают внешний вид интерфейса. IDFE 8 фокусирует внимание разработчиков интерфейса на программировании желаемого взаимного поведения интерфейса и пользователя на трех уровнях: выполняемой операции (что это за операция); сценарии взаимодействия, определяемом специфической ролью пользователя (по какому сценарию она должна выполняться тем или иным пользователем); и, наконец, на деталях интерфейса (какие элементы управления, предлагает интерфейс для выполнения операции);

­ IDEF 9 — Scenario-Driven IS Design (Business Constraint Discovery method) — Метод исследования бизнес ограничений был разработан для облегчения обнаружения и анализа ограничений в условиях которых действует предприятие. Обычно, при построении моделей описанию ограничений, оказывающих влияние на протекание процессов на предприятии уделяется недостаточное внимание. Знания об основных ограничениях и характере их влияния, закладываемые в модели, в лучшем случае остаются неполными, несогласованными, распределенными нерационально, но часто их вовсе нет. Это не обязательно приводит к тому, что построенные модели нежизнеспособны, просто их реализация столкнется с непредвиденными трудностями, в результате чего их потенциал будет не реализован. Тем не менее в случаях, когда речь идет именно о совершенствовании структур или адаптации к предсказываемым изменениям, знания о существующих ограничениях имеют критическое значение;

­ IDEF 10 — Implementation Architecture Modeling — Моделирование архитектуры выполнения. Этот метод определён как востребованный, однако так и не был полностью разработан;

­ IDEF 11 — Information Artifact Modeling. Этот метод определён как востребованный, однако так и не был полностью разработан;

­ IDEF 12 — Organization Modeling — Организационное моделирование. Этот метод определён как востребованный, однако так и не был полностью разработан;

­ IDEF 13 — Three Schema Mapping Design — Трёхсхемное проектирование преобразования данных. Этот метод определён как востребованный, однако так и не был полностью разработан;

­ IDEF 14 — Network Design — Метод проектирования компьютерных сетей, основанный на анализе требований, специфических сетевых компонентов, существующих конфигураций сетей. Также он обеспечивает поддержку решений, связанных с рациональным управлением материальными ресурсами, что позволяет достичь существенной экономии.

­ DFD (Data Flow Diagrams - диаграммы потоков данных) методология структурного анализа, описывающая внешние по отношению к системе источники и адреса, логические функции, потоки и хранилища данных, к которым осуществляется доступ.

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

­ STD (State Transition Diagrams - диаграммы переходов состояний) методология моделирования последующего функционирования системы на основе ее предыдущего и текущего функционирования.

­ CRN (Color Petri Nets - раскрашенные сети Петри) методология создания динамической модели бизнес-процесса, позволяющая проанализировать зависящие от времени характеристики процесса и распределение ресурсов для входящих потоков различной структуры.

­ ABC (Activity Based Costing - функционально-стоимостный анализ) метод определения стоимости и других характеристик изделий и услуг на основе функций и ресурсов, задействованных в бизнес-процессах.

Рисунок 3.1 – Пример описания системы

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

3.2 Основы анализа и проектирования информационных систем

в стандартах IDEF

Из всех названных методологий наибольшее распространение получили IDEF 0, IDEF 1(1 X), IDEF 3 и ABC. Остальные методологии не получили широкого распространения.

3.2.1 Основные элементы и понятия IDEF0

В основе методики лежат четыре основных понятия:

1. Функциональный блок – прямоугольник, описывающий некоторую функцию. По стандарту название блока должно иметь глагольное наклонение (например, «производить», а не «производство»). Каждая сторона играет свою роль (рисунок 3.2):

­ верхняя сторона имеет значение «Управление»;

­ левая сторона имеет значение «Вход»;

­ правая сторона имеет значение «Выход»;

­ нижняя сторона имеет значение «Механизм».

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

Рисунок 3.2 - Функциональный блок IDEF0

2. Интерфейсная дуга – отображает элемент системы, который обрабатывается функциональным блоком или оказывает иное влияние на функцию, отображенную блоком.

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

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

Рисунок 3.3 - Интерфейсная дуга IDEF0

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

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

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

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

Рисунок 3.4 – Пример делового процесса в швейном ателье

Например, швейное ателье производит (шьет) женские пальто, заключая договора с потребителями. Потребителями продукции являются магазины женкой одежды и торгово-посреднические компании. Ателье закупает сырье на камвольных комбинатах, а также у торгово-посреднических компаний. Деловым процессом в швейном ателье является процесс «Производить женские пальто» (Рисунок 3.4).

3. Декомпозиция – позволяет постепенно раскрывать структуру системы в виде иерархической последовательности диаграмм.

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

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

Модель IDEF 0 всегда начинается с представления системы как единого целого – одного функционального блока с интерфейсными дугами, простирающимися за пределы рассматриваемой области. Такая диаграмма с одним функциональным блоком называется контекстной диаграммой, и обозначается идентификатором «А-0».

Модель IDEF 0 всегда начинается с представления системы как единого целого – одного функци­о­нального блока.

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

Рисунок 3.5 - Принцип декомпозиции IDEF0

В процессе декомпозиции, функциональный блок, который в контекстной диаграмме отображает систему как единое целое, подвергается детализации на другой диаграмме. Получившаяся диаграмма второго уровня содержит функциональные блоки, отображающие главные подфункции функционального блока контекстной диаграммы и называется дочерней (Child diagram) по отношению к нему (каждый из функциональных блоков, принадлежащих дочерней диаграмме соответственно называется дочерним блоком – Child Box). В свою очередь, функциональный блок - предок называется родительским блоком по отношению к дочерней диаграмме (Parent Box), а диаграмма, к которой он принадлежит – родительской диаграммой (Parent Diagram). Каждая из подфункций дочерней диаграммы может быть далее детализирована путем аналогичной декомпозиции соответствующего ей функционального блока. Важно отметить, что в каждом случае декомпозиции функционального блока все интерфейсные дуги, входящие в данный блок, или исходящие из него фиксируются на дочерней диаграмме. Этим достигается структурная целостность IDEF 0 – модели. Наглядно принцип декомпозиции представлен на рисунке 3.5. Следует обратить внимание на взаимосвязь нумерации функциональных блоков и диаграмм - каждый блок имеет свой уникальный порядковый номер на диаграмме (цифра в правом нижнем углу прямоугольника), а обозначение под правым углом указывает на номер дочерней для этого блока диаграммы. Отсутствие этого обозначения говорит о том, что декомпозиции для данного блока не существует.

Часто бывают случаи, когда отдельные интерфейсные дуги не имеет смысла продолжать рассматривать в дочерних диаграммах ниже какого-то определенного уровня в иерархии, или наоборот - отдельные дуги не имеют практического смысла выше какого-то уровня. Например, интерфейсную дугу, изображающую «деталь» на входе в функциональный блок «Обработать на токарном станке» не имеет смысла отражать на диаграммах более высоких уровней – это будет только перегружать диаграммы и делать их сложными для восприятия. С другой стороны, случается необходимость избавиться от отдельных «концептуальных» интерфейсных дуг и не детализировать их глубже некоторого уровня. Для решения подобных задач в стандарте IDEF 0 предусмотрено понятие туннелирования. Обозначение «туннеля» (Arrow Tunnel) в виде двух круглых скобок вокруг начала интерфейсной дуги обозначает, что эта дуга не была унаследована от функционального родительского блока и появилась (из «туннеля») только на этой диаграмме. В свою очередь, такое же обозначение вокруг конца (стрелки) интерфейсной дуги в непосредственной близи от блока – приёмника означает тот факт, что в дочерней по отношению к этому блоку диаграмме эта дуга отображаться и рассматриваться не будет. Чаще всего бывает, что отдельные объекты и соответствующие им интерфейсные дуги не рассматриваются на некоторых промежуточных уровнях иерархии – в таком случае, они сначала «погружаются в туннель», а затем, при необходимости «возвращаются из туннеля».

Одним из важных моментов при проектировании ИС с помощью методологии SADT является точная согласованность типов связей между функциями. Различают по крайней мере шесть типов связывания.

(0) Тип случайной связности: наименее желательный. Случайная связность возникает, когда конкретная связь между функциями мала или полностью отсутствует. Это относится к ситуации, когда имена данных на SADT -дугах в одной диаграмме имеют малую связь друг с другом.

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

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

(3) Тип процедурной связности. Процедурно-связанные элементы появляются сгруппированными вместе вследствие того, что они выполняются в течение одной и той же части цикла или процесса.

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

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

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

Пример диаграммы, построенной по методологии IDF 0 представлен на рисунке 3.6.

4. Глоссарий (Glossary) – набор соответствующих определений, ключевых слов, повествовательных изложений и т.д., которые характеризуют объект, отображенный данным элементом.

Для каждого из элементов IDEF 0: диаграмм, функциональных блоков, интерфейсных дуг существующий стандарт подразумевает создание и поддержание набора соответствующих определений, ключевых слов, повествовательных изложений и т.д., которые характеризуют объект, отображенный данным элементом. Этот набор называется глоссарием и является описанием сущности данного элемента. Например, для управляющей интерфейсной дуги «распоряжение об оплате» глоссарий может содержать перечень полей соответствующего дуге документа, необходимый набор виз и т.д. Глоссарий гармонично дополняет наглядный графический язык, снабжая диаграммы необходимой дополнительной информацией.

Дата добавления: 2015-10-31