Файл: Анализ и оценка средств реализации структурных методов анализа и проектирования экономической информационной системы...pdf

Модель IDEF0 может включать четыре вида диаграмм:

• контекстная диаграмма (в каждой модели может содержаться только одна контекстная диаграмма);
• диаграммы декомпозиции;
• диаграммы дерева узлов;
• диаграммы «только для экспозиции» (FEO). [16]

Модель IDEF0 начинается с создания целостного представления системы в виде одного функционального блока с интерфейсными дугами, которые выходят за пределы рассматриваемой области. Такая диаграмма, представляющая наиболее абстрактное описание системы, называется контекстной («Top») и имеет идентификатор «А-0». Важным моментом при составлении контекстной диаграммы является необходимость четко определить, что будет входить в систему, а что нет, соответственно, что будет в дальнейшем являться компонентами системы, а что будет рассматриваться как внешнее воздействие.

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

При определении области нужно учитывать широту и глубину. Широта задает границы (то есть то, что будет рассматриваться внутри системы). Глубина определяет уровень детализации. При этом важно учитывать ограничения времени, поскольку трудоемкость создания модели увеличивается в геометрической прогрессии в зависимости от глубины декомпозиции. [11]

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

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

Иногда при выборе точки зрения необходимо зафиксировать альтернативные точки зрения. Для этого предназначены диаграммы FEO (For Exposition Only). [3]

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

Функциональный блок, отображающий в контекстной диаграмме в целом, посредством декомпозиции обретает детализацию в другой диаграмме. Каждая диаграмма размещается на отдельном листе и считается единицей описания. Данная диаграмма соответствует декомпозиции второго уровня и обозначается идентификатором А1. Она включает функциональные блоки, представляющие основные подфункции блока контекстной диаграммы, и называется дочерней по отношению к нему («Child diagram»). Соответственно, все функциональные блоки, отраженные на дочерней диаграмме, называются дочерним блоком («Child Box»), а функциональный блок – родитель называется «Parent Box» по отношению к дочерней диаграмме. [11]

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

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

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

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

Диаграммы для экспозиции («For Exposition Only», FEO) создаются для отражения отдельных фрагментов модели, для отражения альтернативных точек зрения, а также для отражения функциональных деталей, демонстрация которых невозможна с использованием IDEF0. Диаграммы для экспозиции могут дополняться поясняющим текстом и не обязаны учитывать ограничения стандарта IDEF0. Диаграммы FEO не являются частью иерархической модели, но при этом могут быть ассоциированы с любой диаграммой модели.[9]

Еще один термин технологии IDEF0 - глоссарий («Glossary»). Для интерфейсных дуг подразумевается создание набора соответствующих определений, описаний, ключевых слов, которые характеризуют отображенный объект. Этот набор получил название «глоссарий». Например, для интерфейсной дуги «приказ об оплате» глоссарий может включать перечень полей соответствующего ей документа. За счет внесения дополнительной текстовой информации глоссарий качественно дополняет графический язык диаграмм. [11]

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

2.2 Методология DFD

DFD (data flow diagram) – один из важнейших инструментов структурного анализа. Относится к методологиям графического структурного анализа. В DFD отображаются внешние по отношению к системе источники данных, адресаты данных, потоки и хранилища данных. [5]

В настоящее время одной из наиболее распространенных является нотация Гейна-Сарсона.

Модель DFD является иерархической. Модель системы представляет собой набор иерархически упорядоченных и связанных между собой диаграмм. Каждая из них является единицей описания ИС и размещается на отдельном листе. Соответственно, все процессы могут подвергаться разбиению на структурные элементы, отношения между которыми могут быть отражены на отдельной диаграмме. По достижении необходимой глубины декомпозиции к процессу нижнего уровня добавляется мини-спецификация. [16]

Нотация DFD включает понятие подсистемы — структурного компонента проектируемой системы.

Принципы создания функциональной модели средствами DFD аналогичны принципам IDEF0-методологии.

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

DFD сфокусирована на потоках данных, которые передаются между операциями, а также их хранении для достижения максимальной доступности и скорости ответа. [11]

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

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

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

Внешняя сущность – это материальный объект или физическое лицо, являющееся источником либо приемником информации. Это могут быть персонал, поставщики, склад и так далее. Внешние сущности в модели DFD соответствуют управлению и механизмам в контекстной диаграмме IDEF0. [11]

Важно отметить, что определение объекта в качестве внешней сущности означает, что он располагается за пределами проектируемой ИС. Как правило, внешние сущности представлены только на контекстной диаграмме модели DFD. В дальнейшем некоторые внешние сущности могут переноситься на диаграммы декомпозиции, либо наоборот, некоторые процессы могут быть обозначены внешней сущностью.

Как и в IDEF0, у каждого процесса на диаграмме DFD должен быть хотя бы один входящий и минимум один выходящий поток. Процесс должен быть запущен на выполнение через обрабатываемый или через управляющий поток данных. Каждый процесс должен завершаться определенным результатом. [9]

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

Data Flow Diagrams – удобное средство для анализа и описания информационного пространства системы. Позволяет быстро и наглядно создавать описания процессов обработки информации и документооборота в компании. Диаграммы DFD являются важным и полезным дополнением к функциональной модели бизнес-процессов предприятия, разработанной в IDEF0. [11]

2.4 Методология IDEF3

Нотация IDEF3 (Integrated DEFinition for Process Description Capture Method) - моделирование потоков работ, позволяет разобрать процесс, составляющие его операции и точки принятия решений, которые оказывают на него влияние.

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

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

• Process Flow Description Diagrams, PFDD – диаграмма описания последовательности этапов процесса
• Object State Transition Network, OSTN - диаграмма сети трансформаций состояния объекта.

В отличие от IDEF0, в нотации IDEF3 стороны прямоугольника, представляющего работу, не предназначены для привязки входов различного типа. В IDEF3 в прямоугольник может входить и выходить только одна стрелка. [16]

Как инструмент моделирования, IDEF3 фиксирует следующие детали процесса:

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

Описательные методы нотации IDEF3 позволяют:

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

Нотация IDEF3, предназначенная для описания потоков работ, при построении моделей бизнес-процессов, зачастую используется совместно с описанными выше нотациями. IDEF3 имеет прямую связь с методологией IDEF0, каждая функция которой может быть рассмотрена в виде отдельного процесса средствами IDEF3. IDEF3 позволяет работать с данными, необходимыми для анализа системы с целью выявления слабых мест в согласованности рабочих процессов во времени. [9]

2.5 CASE-средства на примере BPwin и ERwin

Термин «CASE-средства» (Computer Aided Software Engineering) обозначает программные средства, которые поддерживают все основные процессы жизненного цикла информационных систем: создание (включая анализ и формирование требований), сопровождение ИС, проектирование прикладного программного обеспечения, написание кода, тестирование ИС, документирование, управление проектом и конфигурацией и многие другие процессы. [1]

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