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

Текст из файла (страница 7)

анализировать существующие процессы и разрабатывать новые;

определять и анализировать точки влияния потоков сопутствующего документооборота на сценарий технологических процессов;

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

содействовать принятию оптимальных решений при реорганизации процессов;

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

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

IDEF3-ДИАГРАММА (диаграмма потока, process flow diagram, IDEF3-diagram, workflow) - основная единица описания в IDEF3, являющаяся графическим представлением назначения системы или процесса и применяются для анализа завершенности процесса обработки информации (проверка модели ИС на целостность). Обычно IDEF3-диаграммы являются дополнением к IDEFO-диаграммам, т.к. содержат все необходимые сведения для построения моделей, которые в дальнейшем могут быть использованы для имитационного анализа. С помощью диаграмм IDEF3 можно анализировать сценарии из реальной жизни, например, как закрывать магазин в экстренных случаях или какие действия должны выполнить менеджер и продавец при закрытии. Каждый такой сценарий содержит в себе описание процесса и может быть использован, что бы наглядно показать или лучше задокументировать бизнес-функции организации.

Типы перекрестков стандарта IDEF3.

Диаграммы потоков данных (DFD). Основные принципы построения.

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

Для изображения DFD традиционно используются две различные нотации: Йодана (Yourdon) и Гейна-Сарсона (Gane-Sarson). Далее при построении примеров будет использоваться нотация Йодана, все исключения будут предварительно оговариваться.

В основе данной методологии (методологии Gane/Sarson) лежит построение модели анализируемой ИС - проектируемой или реально существующей. В соответствии с методологией модель системы определяется как иерархия диаграмм потоков данных (ДПД или DFD), описывающих асинхронный процесс преобразования информации от ее ввода в систему до выдачи пользователю. Диаграммы верхних уровней иерархии (контекстные диаграммы) определяют основные процессы или подсистемы ИС с внешними входами и выходами. Они детализируются при помощи диаграмм нижнего уровня. Такая декомпозиция продолжается, создавая многоуровневую иерархию диаграмм, до тех пор, пока не будет достигнут такой уровень декомпозиции, на котором процесс становятся элементарными и детализировать их далее невозможно.

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

• внешние сущности;

• системы/подсистемы;

• процессы;

• накопители данных;

• потоки данных.

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

1.Размещать на каждой диаграмме от 3 до 6-7 процессов. Верхняя граница соответствует человеческим возможностям одновременного восприятия и понимания структуры сложной системы с множеством внутренних связей, нижняя граница выбрана по соображениям здравого смысла: нет необходимости детализировать процесс диаграммой, содержащей всего один или два процесса.

2.Не загромождать диаграммы несущественными на данном уровне деталями.

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

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

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

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

7.Отделять управляющие структуры от обрабатывающих структур (т.е. процессов), локализовать управляющие структуры.

В соответствии с этими рекомендациями процесс построения модели разбивается на следующие этапы:

1.Расчленение множества требований и объединение их в основные функциональные группы.

2.Идентификация внешних объектов, с которыми система должна быть связана.

3.Идентификация основных видов информации, циркулирующей между системой и внешними объектами.

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

5. Изучение предварительной контекстной диаграммы и внесение в нее изменений по результатам ответов на возникающие при этом изучении вопросы по всем ее частям.

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

7.Формирование DFD первого уровня на базе процессов предварительной контекстной диаграммы.

8.Проверка основных требований по DFD первого уровня.

9.Декомпозиция каждого процесса текущей DFD с помощью детализирующей диаграммы или спецификации процесса.

10.Проверка основных требований по DFD соответствующего уровня.

11.Добавление определений новых потоков в словарь данных при каждом их появлении на диаграммах.

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

13.После построения двух-трех уровней проведение ревизии с целью проверки корректности и улучшения понимания модели.

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

Методология IDEF1X. Диаграммы «сущность-связь» (ERD). Принципы построения.

В настоящее время на основе совершенствования методологии IDEF1 создана ее новая версия - методология IDEF1X, разработанная с учетом таких требований, как простота изуче-ния и возможность автоматизации. IDEF1X-диаграммы используются рядом распространенных CASE-средств (в частности, ERwin, Design/IDEF).

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

Диаграммы “Сущность-связь”(ERD) предназначены для разработки моделей данных и обеспечивают стандартный способ определения данных и отношений между ними. С помощью ERD осуществляется детализация хранилищ данных проектируемой системы, а также документируются сущности системы и способы их взаимодействия, включая идентификацию объектов, важных для предметной области(сущностей), свойств этих объектов (атрибутов) и их отношений с другими объектами(связей).Нотация была введена Ченом (Chen) и получила дальнейшее развитие в работах Баркера (Barker).

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

IDEF1X является методом разработки реляционных БД основанном на применении условного синтаксиса, специально разработанного для построения концептуальных схем. КОНЦЕПТУАЛЬНАЯ СХЕМА - универсальное представление структуры данных в рамках предприятия, независимое от конечной реализации БД и аппаратной платформы.

IDEF1X является статическим методом проектирования логической структуры БД после того, как все информационные ресурсы исследованы (например, с помощью метода IDEF1), определены с помощью функциональной модели информационные потоки предприятия и принято решение о внедрении реляционной БД, как части корпоративной ИС.

Однако, в связи с тем, что методология IDEF1X разработана специально для построения реляционных ИС, то создаваемая аналитиком IDEF1X-модель является некорректной для при-менения методов объектно-ориентированной реализации. IDEF1X не следует применять для построения не реляционных систем:

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

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

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

Основным преимуществом IDEF1X, по сравнению с другими многочисленными методами разработки реляционных баз данных, такими как ER и ENAL

IM является жесткая и строгая стандартизация моделирования. Установленные стандарты позволяют избежать различной трактовки построенной модели, которая, несомненно, является значительным недостатком ER.

Характеристики

Список файлов ответов (шпаргалок)