СТРУКТУРНЫЕ МЕТОДЫ МОДЕЛИРОВАНИЕ. МЕТОДОЛОГИЯ IDEF0

СТРУКТУРНЫЕ МЕТОДЫ МОДЕЛИРОВАНИЕ. МЕТОДОЛОГИЯ IDEF0.

Сущность структурного подхода

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

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

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

• 
  SADT (Structured Analysis and Design Technique) - модели и соответствующие функциональные диаграммы (подмножеством SADT является IDEF0);
  
• 
  DFD (Data Flow Diagrams) – диаграммы потоков данных;
  
• 
  ERD (Entity-Relationship Diagrams) – диаграммы «сущность-связь».
  

На стадии проектирования системы модели расширяются, уточняются и дополняются диаграммами, отражающими ее структуру.

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

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

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

Основными из этих принципов являются следующие:

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

Программный продукт BPWin 4.1/7.0 (Германская фрма «Computer Associates corp.») является мощным инструментом для создания моделей, позволяющих анализировать, документировать и планировать изменения сложных бизнес- процессов. BPwin 4.1/7.0 является средством сбора необходимой информации о работе предприятия и графического изображения этой информации в виде целостной и непротиворечивой модели. BРwin–модель является графическим представлением действительности, то есть средством документирования и формализации бизнес–процессов. BPWin 4.1/7.0 — это современное CASE–средство, позволяющие анализировать бизнес–процесс с трех ключевых точек зрения:

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

2. 
   С точки зрения потоков информации в системе. Диаграммы DFD (Data Flow Diagram) дополняют функциональные IDEF0–модели, поскольку они описывают потоки данных, позволяя проследить, каким образом происходит обмен информацией между бизнес-функциями внутри системы. Также модели потоков данных могут использоваться как самостоятельное средство при проектировании информационных систем или описании бизнес–процесса, но в DFD-модели акцент ставится на поток данных, его структуру, место и вид хранения данных в системе.
   
3. 
   С точки зрения последовательности этапов выполняемых работ — методология событийного моделирования IDEF3. Этот метод привлекает внимание к очередности выполнения этапов работ или изменения состояний. В IDEF3 включены элементы логики, что позволяет моделировать и анализировать альтернативные сценарии развития бизнес-процесса.
   

Методология IDEF(Integration Definition for Function Modeling).

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

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

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

• 
  IDEF0 — методология функционального моделирования. С помощью наглядного графического языка IDEF0, изучаемая система предстает перед разработчиками и аналитиками в виде набора взаимосвязанных функций (функциональных блоков — в терминах IDEF0). Как правило, моделирование средствами IDEF0 является первым этапом изучения любой системы;
  
• 
  IDEF1 — методология моделирования информационных потоков внутри системы, позволяющая отображать и анализировать их структуру и взаимосвязи;
  
• 
  IDEF1X (IDEF1 Extended) — методология построения реляционных структур. IDEF1X относится к типу методологий «Сущность-взаимосвязь» (ER — Entity-
  

Relationship) и, как правило, используется для моделирования реляционных баз данных, имеющих отношение к рассматриваемой системе;

• 
  IDEF2 — методология динамического моделирования развития систем. В связи с весьма серьезными сложностями анализа динамических систем от этого стандарта практически отказались, и его развитие приостановилось на самом начальном этапе. Однако в настоящее время присутствуют алгоритмы и их компьютерные реализации, позволяющие превращать набор статических диаграмм IDEF0 в динамические модели, построенные на базе «раскрашенных сетей Петри» (CPN — Color Petri Nets);
  
• 
  IDEF3 — методология документирования процессов, происходящих в системе, которая используется, например, при исследовании технологических процессов на предприятиях. С помощью IDEF3 описываются сценарий и последовательность операций для каждого процесса. IDEF3 имеет прямую взаимосвязь с методологией IDEF0 — каждая функция (функциональный блок) может быть представлена в виде отдельного процесса средствами IDEF3;
  
• 
  IDEF4 — методология построения объектно-ориентированных систем. Средства IDEF4 позволяют наглядно отображать структуру объектов и заложенные принципы их взаимодействия, тем самым позволяя анализировать и оптимизировать сложные объектно-ориентированные системы;
  
• 
  IDEF5 — методология онтологического исследования сложных систем. С помощью методологии IDEF5 онтология системы может быть описана при помощи определенного словаря терминов и правил, на основании которых могут быть сформированы достоверные утверждения о состоянии рассматриваемой системы в некоторый момент времени. На основе этих утверждений формируются выводы о дальнейшем развитии системы и производится её оптимизация.
  

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

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

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

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

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

• 
  Верхняя сторона имеет значение «Управление» (Control);
  
• 
  Левая сторона имеет значение «Вход» (Input);
  
• 
  Правая сторона имеет значение «Выход» (Output);
  
• 
  Нижняя сторона имеет значение «Механизм» (Mechanism).
  

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

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

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

Рис.10.1 Функциональный блок

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

В зависимости от того, к какой из сторон подходит данная интерфейсная дуга, она носит название «входящей», «исходящей» или «управляющей». Кроме того,

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

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

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

Рис. 10.2 Титульный лист модели

Такая диаграмма с одним функциональным блоком называется контекстной диаграммой, и обозначается идентификатором «А0» (Рис 10.2).

В пояснительном тексте к контекстной диаграмме должна быть указана цель (Purpose) построения диаграммы в виде краткого описания и зафиксирована точка зрения (Viewpoint).

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

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

жүктеу/скачать 0.58 Mb.

Достарыңызбен бөлісу: