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

ВУЗ: Не указан

Категория: Курсовая работа

Дисциплина: Не указана

Добавлен: 26.06.2023

Просмотров: 105

Скачиваний: 3

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.

Достоинствами применения моделей SADT для описания бизнес-процессов являются:

- полнота описания бизнес-процесса (управление, информационные и материальные потоки, обратные связи);

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

Следующим этапом развития графического языка описания функциональных систем SADT явилась методология IDEF0.

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

1. Функциональный блок (ActivityBox), который графически изображается в виде прямоугольника и олицетворяет собой некоторую конкретную функцию в рамках рассматриваемой системы. Название каждого функционального блока должно быть сформулировано в глагольном наклонении (например, “производить услуги”, а не “производство услуг”).

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

- верхняя - “Управление” (Control);

- левая - “Вход” (Input);

- правая - “Выход” (Output);

- нижняя - “Механизм” (Mechanism) (см. рисунок 1.1).

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

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

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

При построении IDEF0–диаграмм важно правильно отделять входящие интерфейсные дуги от управляющих. Так при рассмотрении организаций существуют пять основных видов объектов:

- материальные потоки (детали, товары, сырье и т.д.);

- финансовые потоки (наличные и безналичные, инвестиции и т.д.);

- потоки документов (коммерческие, финансовые и организационные документы);

- потоки информации (информация, данные о намерениях, устные распоряжения и т.д.);


- ресурсы (сотрудники, станки, машины и т.д.).

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

Рисунок 1.2. Интерфейсная дуга

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

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

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

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

Рисунок 1.3. Декомпозиция

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

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


Для того, чтобы сделать IDEF0-модели неперегруженными и удобочитаемыми приняты соответствующие ограничения сложности:

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

- количество подходящих к одному функциональному блоку (выходящих из одного функционального блока) интерфейсных дуг - 4.[4]

В настоящее время к семейству IDEF относятся и следующие структурные методологии:

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

- IDEF1X – метод разработки реляционных баз данных. IDEF1X был разработан на основе метода моделирования баз данных «диаграммы сущность-связь» (метод ER-D);

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

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

Среди всего многообразия средств решения данных задач в методологиях структурного анализа наиболее часто и эффективно применяются:

- DFD (DataFlowDiagrams) - диаграммы потоков данных совместно со словарями данных и спецификациями процессов или миниспецификациями;

- ERD (Entity-Relationship Diagrams) - диаграммы«сущность-связь»;

- STD (StateTransitionDiagrams) - диаграммы переходов состояний.

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

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

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


Содержимое каждого хранилища также сохраняют в словаре данных, модель данных хранилища раскрывается с помощью ERD. В случае наличия реального времени DFD дополняется средствами описания зависящего от времени поведения системы, раскрывающимися с помощью STD. Эти связи показаны на рисунке 1.4.

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

Рисунок 1.4. Компоненты логической модели

Таким образом, методология структурного анализа и проектирования SADT основной своей идеей имеет построение древовидной иерархической модели организации. На основе SADT принят стандарт моделирования бизнес-процессов IDEF0,позволяющий обеспечить групповую работу всех аналитиков и специалистов, занятых в рамках проекта. В основе IDEF0методологии лежат четыре основных понятия: функциональный блок, интерфейсные дуги, декомпозиция и глоссарий.В целом методы IDEF (IntegratedDEFinition) предназначены для решения различных задач моделирования сложных систем и позволяют отображать и анализировать модели деятельности широкого спектра сложных систем в различных разрезах. При этом широта и глубина обследования процессов в системе определяется самим разработчиком, что позволяет не перегружать создаваемую модель излишними данными. Часто применяемыми и эффективными средствами структурного анализа являются DFD - диаграммы потоков данных совместно со словарями данных и спецификациями процессов или миниспецификациями,ERD - диаграммы «сущность-связь» и STD - диаграммы переходов состояний.

ГЛАВА 2.АНАЛИЗ СРЕДСТВ РЕАЛИЗАЦИИ СТРУКТУРНЫХ МЕТОДОВ АНАЛИЗА И ПРОЕКТИРОВАНИЯ ИНФОРМАЦИОННОЙ СИСТЕМЫ


2.1. Характеристика и оценка средств реализации структурных методов анализа и проектирования

Сегодня существует множество средств реализации структурных методов анализа и проектирования. В данной курсовой работе дана характеристика следующих средств:

-AllFusionERwinDataModeler;

- Design/IDEF;

- BusinessStudio.

AllFusionERwinDataModeler (ранее ERwin)- CASE-средство для проектирования и документирования баз данных, которое позволяет создавать, документировать и сопровождать базы данных, хранилища и витрины данных.

Данное CASE-средство является лидером среди систем, реализующих структурные подходы к развитию информационной системы, около 60% средств моделирования данных мирового рынка принадлежит AllFusionErwinDataModeler.

Следует отметить, что программы ERwin иBPwin были разработаны компанией LogicWorks. Название BPwin сложилось из сокращения BP (businessprocess) и суффикса win, отражавшего ориентацию на графические операционные системы. Затем компания LogicWorks была поглощена фирмой PlatinumTechnology, которая в свою очередь, была куплена ComputerAssociates (CA).Последняя версия программного обеспечения вошла в объединённый пакет CA ERwinModelingSuite.

AllFusionErwinDataModelerобладает следующими возможностями:

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

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

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

Общая функциональная схема проектирования баз данных с помощью AllFusionErwinDataModeler представлена на рисунке2.1.

Рисунок 2.1. Общая функциональная схема проектирования базы данныхс помощью AllFusionErwinDataModeler

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