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

Выделение структурных компонентов и связей между ними.

Структурирование, моделирование, декомпозиция на модули, интеграция.

Результат структурного проектирования – иерархическая структура системы.

 

Схематично применение структурного подхода можно представить в виде последовательности этапов:

1. Разработка функциональной модели.

Используются методологии структурного анализа и проектирования:

Поддержка функционального проектирования - это диаграммы потоков данных DFD (Data Flow Diagrams), определение функций, которые система должна выполнять.

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

Показывают внешние источники и получатели (потоки) данных, процессы преобразования входных данных в выходные, связи, хранилища данных – БД, внешние сущности (терминаторы).

Это иерархические спецификации, описывающие систему с позиций потоков данных.

 

2. Разработка информационной модели.

Используются методологии ERD – для информационной модели.

ERD – entity – relation diagram.

Диаграммы моделирования данных – ER – сущность связь (отношения между данными).

Методология ERD была впервые введена Питером Ченом в 1976 г.

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

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

Содержимое каждого хранилища также сохраняют в словаре данных, модель данных хранилища раскрывается с помощью ERD.

 

Одна из разновидностей модели "сущность-связь" используется в методе IDEF1Х, входящем в семейство стандартов IDEF и реализованном в ряде распространенных CASE-средств (в частности, AllFusion ERwin Data Modeler).

ER модель включает:

1. Сущность – объект.

2. Связь – ассоциации (1:1, 1: n, m:n).

3. Атрибут сущности.

4. Ключи.

В настоящее время ER – это стандарт инфологического представления БД.

Широко используются язык и методика создания информационных моделей приложений, закрепленные в методике IDEF1X (IEEE 1320.2-1998).

Кроме того, развитые коммерческие СУБД, как правило, имеют в своем составе совокупность CASE - средств проектирования приложений.

 

3. Разработка поведенческой модели.

Используются методологии STD (State Transition Diagrams) для поведенческой модели.

Диаграммы моделирования поведения – обычно STD (state translation transition diagram) – диаграммы переходов состояний (для моделирования зависящего от времени поведения системы - аспекты реального времени).

STD состоит из объектов:

1. Состояние.

2. Начальное состояние.

3. Переходы и условия переходов.

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

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

 

Общая характеристика структурных методологий IDEF

 

Взаимосвязанная совокупность методик IDEF– integrated definition for function modeling  для концептуального проектирования разработана по программе ICAM (Integrated Computer Aided Manufacturing) в США.

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

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

Методики IDEF (ICAM DEFinition) задают единообразный подход к моделированию приложений, но не затрагивают проблем единообразного представления данных в процессах информационного обмена между разными компьютерными системами и приложениями.

 

В рамках программы ICAM было разработано несколько графических языков моделирования, которые получили следующие названия:

* Наиболее известной методикой функционального проектирования сложных систем является методика SADT (Structured Analysis and Design Technique), предложенная в 1973 г. Р.Россом и впоследствии ставшая основой международного стандарта IEEE 1320.1-1998 IDEF0 (Integrated DEFinition 0).

* Нотация IDEF0 - для документирования процессов производства и отображения информации об использовании ресурсов на каждом из этапов проектирования систем.

* Нотация IDEF1 - для документирования информации о производственном окружении систем.

* Нотация IDEF2 - для документирования поведения системы во времени.

* Нотация IDEF3 - специально для моделирования бизнес - процессов.

Нотация IDEF2 никогда не была полностью реализована.

Нотация IDEF1 в 1985 году была расширена и переименована в IDEF1X.

 

Общие принципы методологий IDEF

 

1. Описание системы с помощью IDEF называется моделью.

2. Модель состоит из диаграмм, имеющих ссылки друг на друга, фрагментов текстов и глоссария.

3. Диаграммы - главные компоненты модели, все функции объекта автоматизации и информационные и материальные потоки (интерфейсы) на них представлены как блоки и дуги соответственно.

4. Основным методом построения диаграмм является декомпозиция – разделение функций на подфункции, в результате которой формируется иерархия диаграмм.

5. Место соединения дуги с блоком определяет тип интерфейса.

6. Функция на диаграмме представлена блоком, имеющим 3 входа (снизу, слева, сверху) и один выход (справа).

 

 

Данный блок обозначается как ICOM (I – input (вход), C – control (управление), O – output (выход), M – mechanism (механизм)).

Потоки информации об управлении или ограничениях входят в блок сверху.

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

Результаты выхода показаны с правой стороны.

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

 

7. Блок читается: функция преобразует входы в выходы при управлении с помощью механизма.

 

Функциональная методика IDEF0

 

Одним из стандартов,  получившем широкое распространение, является стандарт IDEF0.

Это методология структурного подхода.

В основу спецификации IDEF0 положена методика хорошо известного графического описания и функционального  моделирования сложных систем  SADT (Structured Analysis and Design Technique).

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

Однако наличие графического языка диаграмм, удобного для восприятия человеком, обусловливает полезность и применимость методики SADT.

В совокупности методологий SADT имеются методики функционального, информационного и поведенческого моделирования и проектирования.

Методологию IDEF0 можно считать следующим этапом развития SADT.

Поэтому для нее часто используют название IDEF0 (SADT).

Методика IDEF0 - это более четко очерченное представление методики SADT, рекомендованное к использованию в США в 1981 г. и в России в 2002 г. (рекомендация Госстандарта РФ "Методика функционального моделирования" Р50.1.028-2001).

Последняя редакция IDEF0 была выпущена в декабре 1993 года Национальным Институтом по Стандартным Технологиям США (NIST).

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

IDEF0 предписывает построение иерархической системы диаграмм – описаний фрагментов систем.

Описание системы с помощью IDEF0 называется функциональной мо­делью.

 

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

Основные понятия:

* Activity.box.

Каждая сторона блока имеет особое, вполне определенное назначение.

Левая сторона блока предназначена для входов.

Правая - для выходов.

Верхняя - для управления.

Нижняя - для механизмов.

 

Каждый блок должен иметь уникальный номер.

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

Не должно быть замкнутых процессов.

 

* Интерфейсные дуги (потоки, стрелки, arrows).

Уникальное имя каждой дуги.

Важно отделять интерфейсные дуги от управляющих.

Наличие управляющих дуг – главное отличие IDEF0 от других методологий (DFD).

Блоки в англоязычной терминологии называют блоками ICOM (Input - Control - Output - Mechanism).

В IDEF0 различают пять типов стрелок.

Они задают пять типов взаимодействия блоков.

Вход - объекты, используемые и преобразуемые работой для получе­ния результата (выхода).

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

Стрелка входа рисуется как входящая в левую грань работы.

Управление - информация, определяющая условия выполнения и управляющая действиями работы.

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

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

Выход - объекты, в которые преобразуются входы.

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

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

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

По усмотрению аналитика стрелки механизма могут не изображаться на модели.

 

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

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

 

В IDEF0 стрелка редко изображает один объект.

Обычно она символизи­рует набор объектов.

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

Поэтому они могут разветвляться и соединяться различ­ными способами.

Вся стрелка или ее часть может выходить из одного или нескольких блоков и заканчиваться в одном или нескольких блоках.

Разветвление стрелок, изображаемое в виде расходящихся линий, означает, что все их содержимое или часть может появиться в каждом ответвле­нии.

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

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

* непомеченные ветви содержат все объекты, указанные в метке стрелки перед разветвлением;

* ветви, помеченные после точки разветвления, содержат все объекты или их часть, указанные в метке стрелки перед разветвлением.

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

После слияния ре­зультирующая дуга всегда помечается для указания нового набора объек­тов, возникшего после объединения.

 

Кроме того, каждая ветвь перед слия­нием может помечаться или не помечаться в соответствии со следующими правилами:

* непомеченные ветви содержат все объекты, указанные в общей метке дуги после слияния;

* помеченные перед слиянием ветви содержат все или некоторые объ­екты из перечисленных в общей метке после слияния.

 

 

Контекстная диаграмма процесса (или системы)

 

Декомпозиция процесса

 

Разработка IDEF0 (SADT) - моделей состоит из ряда этапов:

 

1. Разработку IDEF0 (SADT) - модели начинают со сбора информации и формулировки вопросов, на которые модель должна давать ответы, т.е. формулируют цель моделирования.

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

Существуют специальные методики выбора экспертов и анкетирования.

Цель моделирования определяется из ответов на следующие вопросы:

Почему этот процесс должен быть смоделирован?

Что должна показывать модель?

Что может получить клиент?

Определение и формализация цели разработки IDEF0 - модели является крайне важным моментом.

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

 

2. Формирование главной функции объекта автоматизации (системы).

 

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

Создается диаграмма наиболее абстрактного уровня описания системы в целом.

Такая диаграмма с одним функциональным блоком называется контекстной диаграммой.

На ее построение существенно влияет позиция - точка зрения (viewpoint), с которой рассматривается система, и цель моделирования - вопросы, на которые построенная модель должна дать ответ.

Под точкой зрения понимается перспектива, с которой наблюдалась система при построении модели.

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

Точка зрения должна соответствовать цели и границам моделирования.

Точка зрения определяет основное направление развития модели и уровень необходимой детализации.

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

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

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

Это подразумевает определение границ модели - что будет рассматриваться внутри системы, а что вне ее.

Глубина определяет, на каком уровне детализации модель является завершенной.

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

 

3. Декомпозиция функций.

 

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

Контекстная диаграмма является вершиной древовидной структуры диаграмм и представляет собой общее описание системы и ее взаимодействия с внешней средой.

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

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

Эти блоки представляют основные подфункции исходной функции.

Уровень детализации определяется исполнителем.

IDEF0 требует, чтобы число блоков на одном уровне иерархии в диаграмме было не менее трех и не более шести блоков.

Эти ограничения поддерживают сложность диаграмм и модели на уровне, доступном для чтения, понимания и использования.

Число уровней иерархии не ограничено, но обычно их не более 5.

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

 

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

В свою очередь, функциональный блок – называется родительским блоком по отношению к дочерней диаграмме (Parent Box), а диаграмма, к которой он принадлежит – родительской диаграммой (Parent Diagram).

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

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

Этим достигается структурная цель IDEF0 – модели

Задаются входы, выходы, механизмы и управление.

Устанавливаются связи по входу, управлению и выходу.

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

Каждый блок на диаграмме имеет свой номер.

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

Некоторые объекты могут быть необходимы лишь для описания верхних уровней модели

Их передача на более детальные уровни загромоздит диаграмму.

Если дугу нецелесообразно передавать на другой уровень детализации, то ее помещают в туннель.

Помещение дуги в туннель является способом скрыть ее источник приемник.

Существуют два вида помещаемых в туннель дуг:

* со скрытым источником дуга как бы появляется из туннеля.

* со скрытым приемником дуга как бы уходит в туннель.

Дуга со скрытым источником помечается круглыми скобками у своего начала

Дуга со скрытым приемником помечается круглыми скобками у своего конца у стрелки.

 

4. Ревизия или рецензирование диаграмм.

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

Участники отмечают на диаграмме замечания и нумеруют их (как правило, допускается 10 замечаний на диаграмме).

Каждая диаграмма имеет своего автора, и состояние: черновик, рабочий, утвержденный.

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

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

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

Результатом является полная контекстная диаграмма.

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

Полнота контекстной диаграммы носит относительный характер.

Она может быть на всю систему или отдельных подсистем различного уровня иерархии

 

Поведенческое моделирование IDEF3

 

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

Поведенческие аспекты систем  отражает методика IDEF3.

Если методика IDEF0 связана с функциональными аспектами и позволяет отвечать на вопросы "Что делает система?", то в IDEF3 детализируются и конкретизируются IDEF0-функции, IDEF3-модель отвечает на вопросы "Как система это делает?"

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

 

Методология IDEF1X

 

Одним из важнейших вопросов создания автоматизированных систем является   разработка информационных моделей автоматизированных систем.

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

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

В качестве языка представления информационной модели наибольшее распространение получил диаграммный язык, предлагаемый в методике информационного (инфологического) проектирования приложений IDEF1X (IEEE 1320.2-1998), получившей международное признание

Он создан на основе совершенствования методологии IDEF1.

Основными компонентами информационной модели в методике IDEF1X являются сущности, отношения и атрибуты методологии «сушность – связь» ERD (Entity Relation Diagram).

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

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

Конкретные элементы этого множества называют экземплярами сущности.

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

 

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

Различают также специфические и неспецифические отношения.

Специфические отношения - это связи "один ко многим", а неспецифические - связи типа "многие ко многим".

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

Свойства сущностей, отображаемые в информационной модели, называют атрибутами.

Различают ключевые и неключевые атрибуты.

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

Ключевые атрибуты могут быть составными.

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

На IDEF1X - диаграммах ключи записывают в верхней части прямоугольника сущности, причем внешние ключи помечают меткой FK (Foreign Key), неключевые атрибуты помещают в нижнюю часть прямоугольников.

Разработка информационной модели  в соответствии с методикой IDEF1X выполняется за несколько стадий.

На начальной стадии производится сбор информации о приложении, выясняется цель создания ИМ.

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

Результат представляют в виде диаграммы "сущность - связь".

Далее определяют свойства сущностей, начиная с ключевых атрибутов.

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

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

 

Функциональная методика моделирования

потоков данных DFD

 

DFD (Data Flow Diagram) – диаграммы потоков данных.  

 

Это структурная (функциональная) методология, ориентированная на потоки данных.

Идея этой методологии базируется на примере реорганизации офиса.

На основе анализа передач данных работников они были пересажены так, что те, которые передают друг другу много документов, были посажены наиболее близко.

Так появилась идея потоковой диаграммы.

Практически любой класс систем успешно моделируется при помощи DFD -ориентированных методов.

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

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

DFD можно представить ориентированным графом, вершинами которого являются функции или элементы системы, а дуги – информационные потоки.

Входы интерпретируются как события – потоки данных, процессы - действия сущностей, а выходы как реакция на них.

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

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

Назначение процесса (работы) состоит в продуцировании выходных потоков из входных в соответствии с действием, задаваемым именем процесса.

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

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

Внешние сущности выделяются по отношению к основному процессу.

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

Например, основной процесс «обращения граждан», внешняя сущность – "граждане", описание взаимодействия – "подает заявку и получает ответы".

Этот этап является принципиально важным, поскольку именно он определяет тип моделируемой системы

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

 

Определение некоторого объекта или системы в качестве внешней сущности не является строго фиксированным.

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

С другой стороны, отдельные процессы могут быть вынесены за пределы диаграммы и представлены как внешние сущности.

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

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

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

Иногда внешнюю сущность называют также терминатором.

 

 

Изображение внешней сущности на диаграмме потоков данных.

 

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

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

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

Поле номера процесса служит для идентификации последнего.

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

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

Нижнее поле содержит указание на способ физической реализации процесса.

 

 

Необходимо отделять обрабатывающие процессы от управляющих.

Например:

Сущности – клиент и банк.

Потоки (входные и выходные) – готовность принять заявку, заявка, ввод пароля, данные кредитной карты.

Процесс – обслужить.

Декомпозиция процесса – обслужить: получить запрос, принять пароль, обслужить кредитную карту, обработать запрос.

Далее – детализация этих процессов.

Управляющий процесс – это интерфейс между DFD и функциями управления – процесс управления преобразования входных данных в выходные.

 

Построение DFD начинается с контекстной диаграммы.

Перед построением начальной контекстной DFD необходимо проанализировать внешние события и реакции на них.

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

Таблица событий включает в себя наименование внешней сущности, событие, его тип.

Каждому событию (входному потоку или запросу) соответствует реакция системы (выходной поток).

Потоки работ изображаются стрелками и описывают движение объектов из одной части системы.

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

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

 

В DFD также применяются двунаправленные стрелки для описания диалогов типа "команда - ответ" между работами, между работой и внешней сущностью внешними сущностями

В DFD стрелки могут сливаться и разветвляться, что позволяет описать декомпозицию стрелок.

В отличие от IDEF0, где система рассматривается как взаимосвязанные работы, DFD рассматривает как совокупность предметов.

Контекстная диаграмма DFD – наиболее общее представление системы.

Она отражает общий интерфейс системы с внешним миром – между внешними сущностями и системой и определяют основные процессы или подсистемы.

 

Это корень дерева уровней DFD системы.

 

 

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

Так же, как процессы IDEF3, они имеют входы и выходы, но не поддерживают управляющие механизмы, как IDEF0.

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

Одна внешняя сущность может быть использована многократно на одной или нескольких диаграммах.

Обычно такой прием используют, чтобы не рисовать слишком длинных и запутанных структур.

Функции могут быть описаны в виде текста.

Например, "Система обработки информации".

 

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

Декомпозиция сопровождается детализацией основного процесса.

Контекстные диаграммы следующего уровня детализируют контекст и структуру подсистем.

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

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

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

 

Так процессы, полученные при детализации процесса или подсистемы «1», должны нумероваться «1.1», «1.2» и т. д.

Номер каждой работы может включать префикс, номер родительской работы и номер.

Каждое хранилище данных имеет префикс D и уникальный номер, например, D5.

Каждая сущность имеет префикс Е и уникальный номер, например Е5.

Кроме этого желательно размещать на каждой диаграмме от 3-х до 6-7-ми процессов и не загромождать диаграммы деталями, не существенными на данном уровне.

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

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

Миниспецификация является конечной вершиной иерархии DFD.

Множество всех миниспецификаций является полной спецификацией системы.

 

Решение о завершении детализации процесса и использовании миниспецификации принимается исходя из следующих критериев:

* наличия у процесса относительно небольшого количества входных и выходных потоков данных потока (2-3);

* возможности описания преобразования данных процессом в виде последовательного алгоритма;

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

* возможности описания логики процесса при помощи миниспецификации небольшого объема не более 20-30 строк программы.

 

К преимуществам методики DFD относятся:

* возможность однозначно определить внешние сущности, анализируя потоки информации вне системы;

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

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

 

К недостаткам модели можно отнести:

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

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

 

Методика функционального моделирования SADT

 

Хорошо известной методикой функционального моделирования сложных систем является методика SADT (Structured Analysis and Design Technique), положенная в основу спецификации IDEF0.

SADT реализован в одном стандартов семейства IDEF - IDEF0.

Методика IDEF0 - это более четко очерченное представление методики SADT.

Основные рабочие инструменты структурного функционального проектирования – диаграммы DFD,ERD (Entity Relation Diagrams), STD(State Transition Diagrams).

DFD, ER и STD дополняют друг друга.

SADT – это и методология структурного системного анализа и проектирования.

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

Предложена и разработана Дугласом Россом в 1973 г.

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

Т.е она функционально - ориентирована.

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

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

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

С точки зрения SADT модель предметной области может быть представлена в виде:

1. Функций – активностях модели предметной области.

2. Предметов системы – моделях данных (объектах предметной области: оборудование, информация, материалы и т.д.).

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

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

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

Методика SADT рекомендует