Методологии проектирования информационных систем. Методология структурного моделирования SADT

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

2. 3.1 Методология структурного моделирования SADT

3.1 МЕТОДОЛОГИЯ
СТРУКТУРНОГО
МОДЕЛИРОВАНИЯ SADT
Сущность структурного подхода
Основные принципы структурного
подхода

3. Сущность структурного подхода к моделированию систем

СУЩНОСТЬ СТРУКТУРНОГО ПОДХОДА К
МОДЕЛИРОВАНИЮ СИСТЕМ
Система
разбивается
на
функциональные
подсистемы, которые, в свою очередь, делятся на
подфункции, подфункции – на задачи и т.д. до
конкретных процедур
Функция 1
Система
Функция 2
…
…
…
Подфункция 1
Задача 1
Подфункция 2
Задача 2
…
Задача n
…
…
Подфункция n
Функция n
…
…
…
…

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

КЛЮЧЕВЫЕ ПОНЯТИЯ СТРУКТУРНОГО
АНАЛИЗА
Структурным
анализом
принято
называть
метод
исследования системы, которое начинается с ее общего обзора, а
затем детализируется, приобретая иерархическую структуру с
все большим числом уровней.
Функция
– совокупность операций, сгруппированных по
определенному признаку.
Бизнес-процесс — связанная совокупность функций, в ходе
выполнения которой потребляются определенные ресурсы и
создается продукт (предмет, услуга, научное открытие, идея),
представляющая ценность для потребителя.
Подпроцесс – это бизнес-процесс, являющийся структурным
элементом некоторого бизнес-процесса и представляющий
ценность для потребителя.
Бизнес-модель – структурированное графическое описание
сети процессов и операций, связанных с данными, документами,
организационными
единицами
и
прочими
объектами,
отражающими существующую или предполагаемую деятельность
предприятия.

5. Базовые принципы  структурного подхода

БАЗОВЫЕ ПРИНЦИПЫ
СТРУКТУРНОГО
ПОДХОДА
принцип
"разделяй и властвуй" –
принцип решения сложных проблем
путем их разбиения на множество
меньших независимых задач, легких
для понимания и решения;
принцип
иерархического
упорядочивания
–
принцип
организации
составных
частей
проблемы
в
иерархические
древовидные структуры с добавлением
новых деталей на каждом уровне.

6. Основные принципы структурного подхода

ОСНОВНЫЕ ПРИНЦИПЫ СТРУКТУРНОГО
ПОДХОДА
Принцип абстрагирования – выделение существенных с некоторых позиций
аспектов системы и отвлечении от несущественных с целью представления
проблемы в простом общем виде.
Принцип формализации –необходимость строгого методического подхода к
решению проблемы.
Принцип упрятывания –упрятывание несущественной на конкретном этапе
информации: каждая часть "знает" только необходимую ей информацию.
Принцип концептуальной общности –следование единой философии на всех
этапах ЖЦ информационных систем (структурный анализ – структурное
проектирование – структурное программирование – структурное тестирование).
Принцип полноты –контроль на присутствие лишних элементов.
Принцип
непротиворечивости
–обоснованность
и
согласованность
элементов.
Принцип логической независимости – заключается в концентрации
внимания на логическом проектировании для обеспечения независимости от
физического проектирования.
Принцип
независимости
данных
–модели
данных
должны
быть
проанализированы и спроектированы независимо от процессов их логической
обработки, а также от их физической структуры и распределения.
Принцип структурирования данных –данные должны быть структурированы
и иерархически организованы.
Принцип доступа конечного пользователя –пользователь должен иметь
средства доступа к базе данных, которые он может использовать
непосредственно (без программирования).

7. Структурный подход к проектированию ИС

СТРУКТУРНЫЙ ПОДХОД К ПРОЕКТИРОВАНИЮ
ИС
SADT (Structured Analysis and Design Technique - Технология
структурного анализа и проектирования) - одна из самых
известных и широко используемых систем проектирования.
Создатель методологии SADT – Дуглас Росс.
На ее основе разработана известная методология IDEF0 (Icam
DEFinition), которая является основной частью программы
“Интеграция компьютерных и промышленных технологий”,
проводимой по инициативе ВВС США.

8. Основные положения методологии SADT

ОСНОВНЫЕ ПОЛОЖЕНИЯ МЕТОДОЛОГИИ SADT
графическое изображение блоков и дуг SADT-диаграммы
отображает функцию в виде блока, а входы и выходы
представляются дугами, соответственно входящими в блок
и выходящими из него. Взаимодействие блоков друг с
другом описываются с помощью дуг, выражающих
"ограничения", которые определяют, когда и каким образом
функции выполняются и управляются;
выполнение правил SADT требует строгости и точности, не
накладывая в то же время сильных ограничений на
действия аналитика.
Правила SADT:
ограничение количества блоков на каждом уровне
декомпозиции (как правило 3-6 блоков);
связь диаграмм осуществляется при помощи нумерации
блоков;
метки и наименования должны быть уникальными, т.е. не
допускается повторение имен;
входы и управления должна разделяться.

9. Стандарты IDEF (Integrated Computer Aided Manufacturing DEFinition)

СТАНДАРТЫ IDEF (INTEGRATED COMPUTER AIDED
MANUFACTURING DEFINITION)
IDEF0 - методология функционального моделирования.
Система отображается в виде набора взаимосвязанных
функциональных блоков.
IDEF1 – методология моделирования информационных
потоков внутри системы, позволяющая отображать и
анализировать их структуру и взаимосвязи;
IDEF1X (IDEF1 еХtended) – методология построения
реляционных структур. IDEF1X относится к типу методологий
“Сущность-взаимосвязь”
(ER
–
Entity-Relationship)
и
используется для моделирования реляционных баз данных в
системе;
IDEF3 – методология документирования процессов. С
помощью IDEF3 описываются сценарий и последовательность
операций для каждого процесса.
IDEF4 – методология построения объектно-ориентированных
систем.

10. Сущность функционального моделирования

СУЩНОСТЬ ФУНКЦИОНАЛЬНОГО
МОДЕЛИРОВАНИЯ
В основе функционального моделирования лежит
функциональное
содержание
системы,
в
качестве
отношений
между
функциями
рассматривается информация об объектах,
связывающих эти функции.

11. Состав функциональной модели

СОСТАВ ФУНКЦИОНАЛЬНОЙ МОДЕЛИ
SADT-модель - это описание системы, у которого есть
единственный субъект, цель и одна точка зрения.
Цель - набор вопросов, на которые должна ответить модель.
Точка зрения - позиция, с которой описывается система.

12. Синтаксис SADT-диаграмм

СИНТАКСИС SADT-ДИАГРАММ
Диаграммы содержат блоки и дуги;
Блоки представляют функции;
Блоки имеют доминирование (выражается в их ступенчатом
расположении, причем доминирующий блок располагается в левом
верхнем углу диаграммы);
Дуги изображают наборы объектов, передаваемых между блоками;
Дуги изображают различные типы взаимосвязей между блоками:
выход – управление
выход – вход
обратная связь по управлению
обратная связь по входу
выход – механизм.

13. Декомпозиция функциональных диаграмм

ДЕКОМПОЗИЦИЯ ФУНКЦИОНАЛЬНЫХ ДИАГРАММ
Контекстная диаграмма определяет все
функции, входы и выходы, которые могут
появиться на диаграммах нижних уровней
функция
А0
IDEF0
Каждая подфункция может содержать
только те элементы, которые входят в
исходную функцию.
Подфункция
Подфункция1 Выход
А1
Управление
Подфункция 2 Выход
Подфункция 1
А2
Подфункция 3
Вход
А3

14. Пример SADT-диаграмм(контекстная диаграмма)

ПРИМЕР SADT-ДИАГРАММ(КОНТЕКСТНАЯ ДИАГРАММА)

15.

16. 3.1.1 Методология IDEF0

3.1.1 МЕТОДОЛОГИЯ IDEF0
• Сущность методологии функционального
моделирования IDEF0
• Основные понятия методологии IDEF0
• Правила построения моделей IDEF0
• Пример функциональной модели в нотации
IDEF0

17. Основные понятия методологии IDEF0

ОСНОВНЫЕ ПОНЯТИЯ МЕТОДОЛОГИИ IDEF0
Модель
– искусственный объект, представляющий собой
отображение (образ) системы и ее компонентов.
Система представляет собой совокупность взаимосвязанных и
взаимодействующих частей, выполняющих некоторую полезную
работу.
Лаконичность и точность. Документация, описывающая
систему, должна быть точной и лаконичной.
Передача информации. Средства IDEF0 облегчают передачу
информации от одного участника разработки модели (отдельного
разработчика или рабочей группы) к другому.
Строгость и формализм. Разработка моделей IDEF0 требует
соблюдения ряда строгих формальных правил, обеспечивающих
преимущества методологии в отношении однозначности, точности
и целостности сложных многоуровневых моделей.
Итеративное моделирование. Разработка модели в IDEF0
представляет собой пошаговую, итеративную процедуру.
Отделение «организации» от «функций». При разработке
моделей следует избегать изначальной «привязки» функций
исследуемой системы к существующей организационной структуре
моделируемого объекта (предприятия, фирмы).

18. Функциональный блок

ФУНКЦИОНАЛЬНЫЙ БЛОК
Олицетворяет некоторую конкретную функцию или работу в
рамках рассматриваемой системы
РД IDEF0 – 2000: прямоугольник, содержащий имя и номер и
используемый для описания функции
Каждая сторона
функционального
блока имеет свое
вход
назначение
управление
выход
Управлять
предприятием
А0
Наименование
осуществляется
оборотом глагола
или
существительного
механизм
Каждый блок в
рамках единой
системы имеет
уникальный номер

19. Интерфейсная дуга

ИНТЕРФЕЙСНАЯ ДУГА
Интерфейсная
дуга отображает элемент системы,
который обрабатывается функциональным блоком
или оказывает иное влияние на функцию,
отображаемую функциональным блоком.
Графически изображается в виде однонаправленной
стрелки.
Каждая
дуга должна иметь свое уникальное
название,
сформулированное
оборотом
существительного (должно отвечать на вопросы кто?,
что?). Примеры: информация, разработчик, документ,
обработанная заявка.
В зависимости от того, к какой стороне блока она
подходит, интерфейсная дуга будет являться
входящей, выходящей, управления, механизма.

20. Интерфейсная дуга

ИНТЕРФЕЙСНАЯ ДУГА
Ресурсы,
перерабатываемые
системой
управление
вход
Регулирует работу
системы, управляет
(нормативная
документация и т.п.)
выход
Функциональный
блок
А0
Ресурсы, необходимые для
проведения работы
(человеческие ресурсы,
оборудование, ИС).
механизм
Результат работы
системы,
переработанные
ресурсы, продукт
деятельности
Стрелки входа может не быть. Остальные интерфейсные дуги обязательны.

21. Декомпозиция

ДЕКОМПОЗИЦИЯ
Принцип декомпозиции применяется при
разбиении сложных процессов на
составляющие его функции. При этом уровень
детализации определяется непосредственно
разработчиком модели.
Модель IDEF0 всегда начинается с
рассмотрения системы как единого целого, т.е.
одного функционального блока с
интерфейсными дугами, простирающимися за
пределы рассматриваемой области. Такая
диаграмма называется контекстной, она
обозначается идентификатором А-0.
Для определения границ системы на
контекстной диаграмме обязательно должны
быть цель и точка зрения.

22. Контекстная диаграмма верхнего уровня

КОНТЕКСТНАЯ ДИАГРАММА ВЕРХНЕГО УРОВНЯ
Эта диаграмма называется A-0 (А ноль). Стрелки на этой диаграмме
отображают связи объекта моделирования с окружающей средой.

23. Цель моделирования

ЦЕЛЬ МОДЕЛИРОВАНИЯ
Цель
моделирования
должна
отвечать
на
следующие вопросы:
Почему процесс должен быть смоделирован?
Что должна показывать модель?
Что может получить читатель?
Примеры целей: «Идентифицировать слабые
стороны процесса сбора данных», «Определить
ответственность
сотрудников
для
написания
должностных инструкций» и т.п.

24. Точка зрения

ТОЧКА ЗРЕНИЯ
Точка зрения – позиция, с которой будет строиться
модель. В качестве точки зрения берется взгляд
человека, который видит систему в нужном для
моделирования аспекте.
Как правило, выбирается точка зрения человека,
ответственного за выполнение моделируемой работы.
Между целью и точкой зрения должно быть жесткое
соответствие.

25. Декомпозиция

ДЕКОМПОЗИЦИЯ
Контекстная
диаграмма
А0
Цель:
Т.зрения:
А-0
Декомпозиция
контекстной
диаграммы
А1
А2
А3
А0
А11
А31
А12
А32
А13
А1
Декомпозиция блока А1
А33
А3
Декомпозиция блока А3

26. Декомпозиция

ДЕКОМПОЗИЦИЯ
А0
А11
А1
А2
А12
А13
А0 ____________
А1____________
А11___________
А12___________
А13___________
А2____________
А3____________
А3
Дерево узлов
Индекс узлов

27. Нумерация работ и диаграмм

НУМЕРАЦИЯ РАБОТ И ДИАГРАММ
Номер
функционального
блока на
контекстной
диаграмме
Формат номера
блока:
1. Префикс
2. Номер
родительской
работы
3. Собственный
порядковый
номер
Номер контекстной
диаграммы
А0
Цель:
Т.зрения:
А-0
Диаграммы
декомпозиции
имеют номер
декомпозируемого
блока
А1
А2
А3
А0
А11
А31
А12
А32
А13
А1
А33
А3

28. Основные правила построения диаграмм

ОСНОВНЫЕ ПРАВИЛА ПОСТРОЕНИЯ
ДИАГРАММ
1. На одной диаграмме рекомендуется рисовать от 3
до 6 блоков. Иначе диаграмма будет плохо
читаемой.
2. Функциональные блоки должны располагаться
слева
направо
сверху
вниз
в
порядке
доминирования.
3. Следует избегать излишнего пересечения стрелок.

29. Основные правила построения диаграмм

ОСНОВНЫЕ ПРАВИЛА ПОСТРОЕНИЯ
ДИАГРАММ
4. Выход одного блока может являться входом
(управлением) для другого. Могут быть и обратные
связи по входу и управлению.
Связь по управлению
Связь по входу

30. Основные правила построения диаграмм

ОСНОВНЫЕ ПРАВИЛА ПОСТРОЕНИЯ
ДИАГРАММ
Обратная связь по входу,
как правило, используется
для описания циклов.
а) обратная связь по входу
б) обратная связь по управлению
в) обратная связь по механизму
Обратная связь по
управлению – выход
нижестоящей работы
передается на управление
вышестоящей
Обратная связь по
механизму – выход
нижестоящей работы
создает ресурсы,
выполняющие
вышестоящую работу

31. Основные правила построения диаграмм

ОСНОВНЫЕ ПРАВИЛА ПОСТРОЕНИЯ
ДИАГРАММ
5. Стрелки могут быть сливающимися и
разветвляющимися
Слияние стрелок
Разветвление стрелок

32. Ветвление и слияние сегментов стрелок

ВЕТВЛЕНИЕ И СЛИЯНИЕ СЕГМЕНТОВ СТРЕЛОК
непомеченные сегменты содержат все объекты, указанные в метке
стрелки перед ветвлением (т.е. все объекты принадлежат
каждому из сегментов)

33. Ветвление и слияние сегментов стрелок

ВЕТВЛЕНИЕ И СЛИЯНИЕ СЕГМЕНТОВ СТРЕЛОК
сегменты, помеченные после точки ветвления, содержат все
объекты, указанные в метке стрелки перед ветвлением, или
их часть, описываемую меткой каждого конкретного
сегмента;

34. Ветвление и слияние сегментов стрелок

ВЕТВЛЕНИЕ И СЛИЯНИЕ СЕГМЕНТОВ СТРЕЛОК
при слиянии непомеченных сегментов объединенный сегмент
стрелки содержит все объекты, принадлежащие сливаемым
сегментам и указанные в общей метке стрелки после слияния

35. Ветвление и слияние сегментов стрелок

ВЕТВЛЕНИЕ И СЛИЯНИЕ СЕГМЕНТОВ СТРЕЛОК
при слиянии помеченных сегментов объединенный сегмент содержит
все или некоторые объекты, принадлежащие сливаемым сегментам
и перечисленные в общей метке после слияния; если общая метка
после слияния отсутствует, это означает, что общий сегмент
передает все объекты, принадлежащие сливаемым сегментам;

36. Туннельные стрелки

ТУННЕЛЬНЫЕ СТРЕЛКИ
Иногда необходимо отобразить граничные стрелки,
которые значимы на данном уровне и не значимы
на родительской диаграмме. Например, некоторые
данные используются только на данном уровне и не
используются на других. Без использования
механизма туннелирования малозначимая стрелка
появится на всех уровнях модели, что затруднит
чтение диаграмм.

37. Пример модели процесса постройки садового домика

ПРИМЕР МОДЕЛИ ПРОЦЕССА ПОСТРОЙКИ
САДОВОГО ДОМИКА
1. Строим контекстную диаграмму.
Проект дома
Материалы
Построить дом
Дом
Строители
Цель: Определить действия, необходимые для постройки дачного домика
Точка зрения: владельца дачного участка

38. Пример модели процесса постройки садового домика

ПРИМЕР МОДЕЛИ ПРОЦЕССА ПОСТРОЙКИ САДОВОГО
ДОМИКА
2. Декомпозируем контекстную диаграмму
Проект дома
Материалы
Заложить
фундамент
Фундамент
Стены
Возвести
стены
Крыша
Положить
крышу
Выполнить
отделку
Каменщики
Плотники
Строители
Кровельщики
Мастера по
отделке
Дом

39. 3.1.2 Диаграммы потоков данных (DFD)

3.1.2 ДИАГРАММЫ ПОТОКОВ ДАННЫХ (DFD)
•Определение и функциональное
назначение DFD-моделей
• Основные компоненты DFDмоделей
•Иерархия DFD

40. Что такое DFD-модель

ЧТО ТАКОЕ DFD-МОДЕЛЬ
DFD – Data Flow Diagrams – диаграммы потоков
данных
Модель системы определяется как иерархия
диаграмм потоков данных, описывающих
асинхронный процесс преобразования информации
от ее входа в систему до выдачи пользователю.

41. Что такое DFD-модель?

ЧТО ТАКОЕ DFD-МОДЕЛЬ?
Главная цель такого представления –
продемонстрировать, как каждый процесс
преобразует свои входные данные в
выходные, а также выявить отношения
между этими процессами.
Примечание. DFD-модели могут быть
использованы в дополнение к модели IDEF0
для более наглядного отображения
текущих операций документооборота в
корпоративных системах обработки
информации.

42. Основные компоненты диаграмм потоков данных

ОСНОВНЫЕ КОМПОНЕНТЫ
ДИАГРАММ ПОТОКОВ ДАННЫХ
Основными компонентами диаграмм потоков данных
являются:
внешние сущности
системы и подсистемы
процессы
накопители данных
потоки данных.

43. Нотации, используемые в DFD-моделировании

НОТАЦИИ, ИСПОЛЬЗУЕМЫЕ В DFDМОДЕЛИРОВАНИИ
Нотации
DFD-моделирования
Гейна-Сарсона
(Gene-Sarson)
Йордона-ДеМарко
(Yordon-DeMarco)
Примечание. В зависимости от используемой нотации графическое
представление элементов диаграмм будет различным

44. Внешняя сущность

ВНЕШНЯЯ СУЩНОСТЬ
Представляет собой материальный объект или
физическое лицо, являющееся источником или
приемником информации (например, заказчики,
клиенты, поставщики, склад, персонал, банк).
USED AT: AUTHOR: asu
Внешняя сущность находится за
пределами
границ
PROJECT: уу
анализируемой системы.
Одна и та же внешняя сущность может быть
NOTES: 1 2 3 4 5 6 7 8 9
использована многократно на одной или нескольких
диаграммах.
1
Имя
Внешняя сущность в
нотации Йордона-ДеМарко
Имя
Внешняя сущность в
нотации Гейна-Сарсона

45. Система и подсистема

СИСТЕМА И ПОДСИСТЕМА
При построении модели сложной системы она может быть
представлена в самом общем виде на так называемой контекстной
диаграмме в виде одной системы, либо в виде ряда подсистем.
Наименование системы/подсистемы представляется в виде
словосочетания с отглагольным существительным (рассмотрение
повестки дня, решение задачи, получение денег и т.п.).
Система/подсистема
Наименование
системы
в нотации ГейнаСарсона
Имя системы/
подсистемы
Поле идентификации
1
Поле имени
Персонал, оборуд-е
Поле физической реализации
1
Система/подсистема в
нотации ЙордонаДеМарко
или
имя

46. Процесс

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

47. Процесс

ПРОЦЕСС
Поле идентификации
1.1
Наименование
процесса
Поле имени
Персонал, оборуд-е
Имя
процесса
Поле физической реализации
1
или
Процесс в нотации
Гейна-Сарсона
имя
Процесс в нотации
Йордона-ДеМарко
!!!!! Процесс отличается от системы/подсистемы по
полю наименования!!!!

48. Накопитель данных

НАКОПИТЕЛЬ ДАННЫХ
Это абстрактное устройство для хранения
информации, которую можно в любой
момент поместить в накопитель и через
некоторое время извлечь.
Примеры: ящик в картотеке, таблицы в ОЗУ,
файл на электронном носителе
Примечание: В нотациях Гейна-Сарсона и Йордона-ДеМарко графическое
представление данного элемента аналогичное.

49. Поток данных

ПОТОК ДАННЫХ
Определяет информацию, передаваемую
через некоторые соединения от источника к
приемнику. Реальный поток данных может
быть информацией, передаваемой по кабелю
между двумя устройствами, пересылаемыми
по почте письмами и т.п.
1.1.1
Деканат
Ведомость
Заполнить
ведомость
Преподаватель

50. Нумерация объектов

Н
УМЕРАЦИЯ
USED
AT: AUTHOR: asu ОБЪЕКТОВ
DATE: 06.03.2009
PROJECT: уу
REV:
06.03.2009
DATE:
WORKING
DAT
DRAFT REV:
REV
RECOMMEND
1 2 31 2
4 35 46 PUBLICATION
NOTES:
57 687 98 10
9 10
NOTES: 1 2 3 4 5 6 7 8 9 10 NOTES:
USED AT:
AUTHOR: asu
USED AT: AUTHOR: asu
PROJECT:
уу
PROJECT:
уу
Системы, подсистемы
1
Наименование
подсистемы
Процессы
2.1
E1
Имя
Наименование
процесса
DATE: 06.03.2009
WORKING
READER
2
[Префикс]+номер
родительской
REV:
06.03.2009
DRAFT
RECOMMENDED
номер
[Префикс] + собственный номер подсистемы+собственный
USED AT:
AUTHOR: asu
PROJECT: уу
NOTES: 1 2 3 4 5 6 7 8 9 10
Внешние сущности
PUBLICATION
Хранилища данных
0
E1
Имя
D1 Имя
Наименование
системы
[Префикс]+номер
[Префикс]+номер

51. Уровни DFD-модели

УРОВНИ DFD-МОДЕЛИ
Уровень системы
Уровень подсистемы
Уровень процесса

52. Построение иерархии DFD

DATE: 02.03.2009
WORKING
ПОСТРОЕНИЕ ИЕРАРХИИ
DFD
REV: 02.03.2009
DRAFT
AUTHOR: 1
PROJECT: 1
READER
RECOMMENDED
PUBLICATION
NOTES: 1 2 3 4 5 6 7 8 9 10
1. Построение диаграмм уровня системы и подсистемы
1
Преподаватель
2
Знания
Деканат
Сведения об
успеваемости
0р.
A0
Обучение
в университете
Книги
3
Библиотека
Оснащ ение
4
Дисплейные
классы
DATE CO

53. Построение иерархии DFD

ПОСТРОЕНИЕ
ИЕРАРХИИ DFD
AUTHOR: 1
DATE: 02.03.2009
WORKING
USED AT:
PROJECT: 1
REV: 02.03.2009
READER
DATE CONTEXT:
DRAFT
RECOMMENDED
PUBLICATION
2. Построение
NOTES: 1 2 3 диаграмм
4 5 6 7 8 9 10 уровня процесса
5
Клиенты
БД
1 заказов
Сведения
о заказе
0р.
Заказы
A1
Информация о доставке
Сведения о
клиенте
Обработать
заказы
A-0
6
3
Данные о клиенте
БД
клиентов
Данные о клиенте
Склад
Продукция
Данные счета
0р.
2 БД счетов
Данные счета
A2
Проконтроллировать
оплату
A3 Продукция
0р.
Доставить
продукцию
Платежные документы
5
Клиенты

54. Пример DFD-модели постройки дачного домика

ПРИМЕР DFD-МОДЕЛИ
ПОСТРОЙКИ ДАЧНОГО ДОМИКА
USED AT:AUTHOR: Шилина
DATE: 10.03.2010
PROJECT : Постройка домаREV: 10.03.2010
WORKING
READER
DRAFT
1. Контекстная диаграмма уровня системы
RECOMMENDED
NOTES: 1 2 3 4 5 6 7 8 9 10
PUBLICATION
Проект дома
0р.
3
Магазин
DATE CONTEXT:
1
Архитектор
0
Прайс-лист на
материалы
Пос тройка
дома
Акт приемки
2
Заказчик
TOP

55. Пример DFD-модели постройки дачного домика

ПРИМЕР DFD-МОДЕЛИ
ПОСТРОЙКИ ДАЧНОГО ДОМИКА
USED AT:AUTHOR: Шилина
DATE: 10.03.2010
WORKING
READER
PROJECT:
Постройка
дома
REV:
10.03.2010
DRAFT
2. Диаграмма уровня подсистемы
RECOMMENDED
NOTES: 1 2 3 4 5 6 7 8 9 10
PUBLICATION
Проект
Спис ок
дома
ис правлений
2
Заказчик
0р.
1
Чеки на
Согласование
материалы
проекта
Утвержденный
проект
Прайс-лист на
материалы
0р.
2
Выполнение
строительных
работ
DATE CONT EXT:
A-0
1 Документация
Акты
выполненных
работ
0р.
3
Сдача
работ
Акт
приемки

56. Пример DFD-модели постройки дачного домика

ПРИМЕР DFD-МОДЕЛИ
ПОСТРОЙКИ ДАЧНОГО ДОМИКА
USED AT:AUTHOR: Шилина
DATE: 10.03.2010
WORKING
READER
PROJECT:
Постройкауровня
дома
REV: 10.03.2010
3. Диаграмма
процесса DRAFT
RECOMMENDED
NOTES: 1 2 3 4 5 6 7 8 9 10
PUBLICATION
Утвержденный
Чеки на материалы
проект
0р.
1
Заложить
фундамент
Прайс-лист на
материалы
DATE CONT EXT:
A0
Акты
выполненных
работ
0р.
2
Возвести
стены
0р.
3
Положить
крышу
0р.
4
Выполнить
отделку

57. 3.1.3 Методология IDEF3

3.1.3 МЕТОДОЛОГИЯ IDEF3
• Понятие динамического моделирования
• Методология IDEF3
• Основные элементы динамической
модели
• Правила и особенности построения
IDEF3-модели
• Декомпозиция в IDEF3

58. Что отражает модель IDEF3?

ЧТО ОТРАЖАЕТ МОДЕЛЬ IDEF3?
В общем случае, процесс – это упорядоченная
последовательность действий.
Следовательно, процессная модель IDEF3
позволяет:
Отразить последовательность процессов
Показать логику взаимодействия элементов
системы.
Цель IDEF3 - дать возможность аналитикам
описать ситуацию, когда процессы
выполняются в определенной
последовательности, а также объекты,
участвующие совместно в одном процессе.

59. Основные элементы диаграмм IDEF3

ОСНОВНЫЕ ЭЛЕМЕНТЫ ДИАГРАММ
IDEF3
Точка зрения на модель - это точка зрения человека, ответственного за
работу в целом.
Цель модели — те вопросы, на которые призвана ответить модель.
Единицы работы - Unit of Work (UOW), также называемые работами
(activity), являются центральными компонентами модели.
Связи. Связи показывают взаимоотношения работ.
Перекрестки - используются для отображения логики взаимодействия
стрелок при слиянии и разветвлении или для отображения множества
событий, которые могут или должны быть завершены перед началом
следующей работы.
Объект ссылки - в IDEF3 выражает некую идею, концепцию или данные,
которые нельзя связать со стрелкой, перекрестком или работой.

60. Единицы работ

AT:
AUTHOR: as u
PROJECT: 123
DATE: 18.03.2009
REV: 18.03.2009
ЕДИНИЦЫ РАБОТ
NOTES: 1 2 3 4 5 6 7 8 9 10
WORKING
DRAFT
RECOMMENDED
PUBLICATION
READER
DATE
CONTEXT:
TOP
Единица работ (UOW, Unit of Work)
является центральным компонентом
модели.
Номер работы
является
уникальным,
присваивается
при ее создании и
не меняется
никогда
Им я работы
1.1
Словосочетание с
отглагольным
существительным,
изображающим
действие
(выполнение,
изготовление,…)
Или
Инфинитив
глагола
(изготовить
продукцию)

61. Связи

СВЯЗИ
Связи показывают взаимоотношения работ.
Связи однонаправлены и могут быть
направлены куда угодно
Обычно диаграммы рисуют таким образом,
чтобы связи были направлены слева
направо
Различают 3 типа связей:
Старшая стрелка
Стрелка отношений
Поток объектов.

62. Связь «старшая стрелка»

СВЯЗЬ «СТАРШАЯ СТРЕЛКА»
AUTH OR: as u
PROJECT: 123
DATE:
REV:
18.03.2009
18.03.2009
DATE
CONTEXT
Связь типа «временное предшествование» - Precedence
TO
Соединяет единицы работ
NOTES: 1 2 3 4 5 6 7 8 9 10
WOR KING
DR AFT
REC OMMEN DED
PUBLICATION
READER
Показывает, что работа-источник должна быть
закончена прежде, чем начнется работа-цель
Принятие
рекомендаций
рецензента
Внесение
исправлений
1.1
1.2
1.1
1.1´ 1.2
1.2´

63. Стрелка отношений

СТРЕЛКА ОТНОШЕНИЙ
TH OR: as u
ROJECT: 123
DATE:
REV:
18.03.2009
18.03.2009
WOR KING
DR AFT
REC OMMEN DED
PUBLICATION
READER
DATE
Связь типа нечеткое отношение - Relational
Изображается в виде пунктирной линии,
OTES: 1 2 3 4 5 6 7 8 9 10
используется для изображения связи между
единицами работ, а также между единицами
работ и объектами ссылок
Принятие
рекомендаций
рецензента
Внесение
исправлений
1.1
1.2
1.1
1.2
1.1´ 1.2´
CON

64. Поток объектов

ПОТОК ОБЪЕКТОВ
HOR: as u
JECT: 123
DATE:
REV:
18.03.2009
18.03.2009
WORKING
DRAFT
RECOMMENDED
PUBLICATION
READER
DATE
Стрелка, изображающая поток объектов - Object
Flow
Применяется для описания того факта, что
объект используется в двух и более единицах
работ, например, когда объект порождается в
одной работе и используется в другой
ES: 1 2 3 4 5 6 7 8 9 10
Получение
счета
на оплату услуг
1.1
Оплата
1.2
C

65. Перекрестки (соединения)

ПЕРЕКРЕСТКИ (СОЕДИНЕНИЯ)
Используются для отображения логики
взаимодействия стрелок при их слиянии или
разветвлении, для отображения множества
событий, которые могут или должны быть
завершены перед началом следующей работы.
Различают перекрестки для слияния и
разветвления стрелок.
Перекрестки не могут быть одновременно
использованы для слияния и разветвления
стрелок.
Все перекрестки на диаграммах нумеруются,
каждый номер имеет префикс J.
В отличие от других методологий (IDEF0, DFD)
стрелки могут сливаться или разветвляться
только через перекрестки.

66. Типы перекрестков

ТИПЫ ПЕРЕКРЕСТКОВ
Обозначение
Наименов
ание
Смысл в случае
слияния стрелок
Смысл в случае
разветвления стрелок
Асинхрон- Все предшествующие Все последующие
ное «И»
процессы должны
процессы должны быть
быть завершены
Синхронное «И»
запущены
Все предшествующие Все последующие
процессы должны
процессы запускаются
быть завершены
одновременно
одновременно
Асинхрон- Один или несколько
ное
предшествующих
процессов должны
«ИЛИ»
быть завершены
Один или несколько
следующих процессов
должны быть запущены

67. Типы перекрестков

ТИПЫ ПЕРЕКРЕСТКОВ
Обозна- Наименов
ание
чение
Смысл в случае
слияния стрелок
Смысл в случае
разветвления стрелок
Синхронн Один или несколько
ое «ИЛИ» предшествующих
процессов должны
быть завершены
Один или несколько
следующих процессов
должны быть
запущены
Эксклюзи
вное
(исключа
ющее)
«ИЛИ»
одновременно
одновременно
Только один
предшествующий
процесс должен
Только один
следующий процесс
быть завершен
запускается

68. Правила создания перекрестков

:
ПРАВИЛА СОЗДАНИЯ ПЕРЕКРЕСТКОВ
1. Каждому перекрестку
для слияния
должен READER
DATE: 18.03.2009
WORKING
REV:
18.03.2009 для
DRAFT
предшествовать перекресток
разветвления.
RECOMMENDED
2. Перекресток
может следовать
NOTES:
1 2 3 4 5 6 7 8 9 10для слияния «И» не
PUBLICATION
за перекрестком для разветвления типа
синхронного или асинхронного «ИЛИ»
AUTHOR: asu
PROJECT: 123
2.1.6
O
2.1.5
&
J1
J2
2.1.7
2.1.8
DAT

69. Правила создания перекрестков

ПРАВИЛА СОЗДАНИЯ
ПЕРЕКРЕСТКОВ
DATE: 18.03.2009
WORKING
READER
DAT
AUTHOR: asu
PROJECT: 123
REV:
18.03.2009
DRAFT
RECOMMENDED
PUBLICATION
3. Перекресток для слияния «И» не может
NOTES: 1 2 3 4 5 6 7 8 9 10
следовать за перекрестком типа
исключительного «ИЛИ»
2.1.6
X
2.1.5
&
J1
J2
2.1.7
2.1.8

70. Правила создания перекрестков

AT:
AUTHOR: asu
PROJECT: 123
DATE:
REV:
18.03.2009
18.03.2009
WORKING
DRAFT
RECOMMENDED
PUBLICATION
READER
ПРАВИЛА СОЗДАНИЯ ПЕРЕКРЕСТКОВ
4. Перекресток для слияния типа исключительного
«ИЛИ» не может следовать за перекрестком для
разветвления типа «И»
NOTES: 1 2 3 4 5 6 7 8 9 10
2.1.6
&
2.1.5
X
J1
J2
2.1.8
2.1.7
5. Перекресток, имеющий одну стрелку на одной
стороне, должен иметь более одной стрелки на другой.
DATE

71. Примеры

UT HOR: asu
ROJECT : р
DAT E: 18 .03.200 9
REV: 18 .03.200 9
ПРИМЕРЫ
WO RKING
READER
DRAFT
PUBLICAT ION
1
Включен ие
по жар ной
си гна лизации
1.1 .3
1.1 .2
Набо р
но ме ра
01
O
J1
CON
RECOM MENDED
OTES: 1 2 3 4 5 6 7 8 9 10
Обн аружени е
по жар а
DAT E
1.1 .4
Самосто яте льн ое
тушени е
по жар а
1.1 .5
За пис ь
в жур нале
де журс тв
O
J2
1.1 .6

72. Примеры

RECOM MENDED
1
PUBLI CAT ION
ПРИМЕРЫ
Оплата
на личн ыми
1.1 .7
X
X
J4
J3
Безналичная
оп лата
1.1 .8

73. Примеры

RECOMMENDED
PUBLICATION
1
ПРИМЕРЫ
Выстрел
из стартового
пистолета
1.1.3
Начало
состязания
1.1.2
Запуск
секундомера
&
J1
1.1.4
J2
Начало
забега
1.1.5
&

74. Комбинации перекрестков

PROJECT: 1
REV: 18.03.2009
DRAFT
RECOMMENDED
PUBLICATION
КОМБИНАЦИИ ПЕРЕКРЕСТКОВ
NOTES: 1 2 3 4 5 6 7 8 9 10
Перекрестки могут комбинироваться для
создания сложных соединений
1.1.3
&
1.1.2
J3
J2
X
&
1.1.4
J1
X
J4
1.1.5
1.1.6

75. Объект ссылок

ОБЪЕКТ ССЫЛОК
выражает идею, концепцию данных, которые
нельзя связать со стрелкой, перекрестком,
03.2009работой
WORKING
READER
DATE CONTEXT:
03.2009
DRAFT
используется
при построении диаграммы для
RECOMMENDED
привлечения
внимания пользователя к какимPUBLICATION
1.1
либо
важным аспектам модели
Тип / Имя объекта
ссылок

76. Объект ссылок

ОБЪЕКТ ССЫЛОК
Официальная спецификация IDEF3
различает 3 стиля объектов ссылок –
безусловные (unconditional), синхронные
(synchronous), асинхронные (asynchronous).
BPWin поддерживает только безусловные
объекты ссылок.

77. Типы объектов ссылок

ТИПЫ ОБЪЕКТОВ ССЫЛОК
Тип
объекта
ссылок
Назначение
1. Object
Используется для описания того, что в действии
принимает участие какой-либо заслуживающий
отдельного внимания объект
2. Ссылка
Используется для реализации цикличности
выполнения действий. Этот объект также может
относиться к перекрестку
GOTO
3. Единица Используется для многократного отображения на
действий
диаграмме одного и того же действия, но без цикла
UOB (Unit of
Behavior)

78. Типы объектов ссылок

ТИПЫ ОБЪЕКТОВ ССЫЛОК
Тип объекта
ссылок
Назначение
4. Заметка
(Note)
Используется для документирования какой-либо
важной информации общего характера,
относящейся к изображаемому на диаграммах.
Служит альтернативой методу помещения
текстовых заметок непосредственно на диаграммах
5. Уточнение
Elaboration
(ELAB)
Для уточнения или более подробного описания
изображаемого на диаграмме. Обычно
используется для детального описания
разветвления или слияния стрелок на перекрестках

79. Декомпозиция работ в IDEF3

ДЕКОМПОЗИЦИЯ РАБОТ В IDEF3
В IDEF3 декомпозиция используется для
детализации работ.
Методология IDEF3 позволяет
декомпозировать работу многократно, т.е.
работа может иметь множество дочерних
работ.
Это позволяет в одной модели описать
альтернативные потоки.
Возможность множественной декомпозиции
предъявляет дополнительные требования к
нумерации работ

80. Нумерация работ в IDEF3

J2
X
1.1.2 РАБОТ В IDEF3
НУМЕРАЦИЯ
J1
1.1
Номер работы состоит из номера родительской
работы, версии декомпозиции и собственного
номера работы на текущей диаграмме
1.1
Номер родительской
работы
Версия
декомпозиции
1.1.7
Собственный номер
единицы работ

81. Структура множественной декомпозиции работ

СТРУКТУРА МНОЖЕСТВЕННОЙ
USED AT:
AUTHOR: Øèëèíà Ì.À.
DATE: 18.03.2009
WORKING
PROJECT: ï
REV: 18.03.2009
DRAFT
READER
DATE CONTE
ДЕКОМПОЗИЦИИ РАБОТ
RECOMMENDED
AUTHOR: 1
NOTES: 1 2 3 4 5 6 7 8 9 10
PROJECT: 1
PUBLICATION
DATE: 19.03.2009
WORKING
REV:
DRAFT
19.03.2009
2.1
READE
RECOMMENDED
NOTES: 1 2 3 4 5 6 7 8 9 10
Первая
декомпозиция
работы 1.2
PUBLICATION
1.1
1.2
2.1.4
2.1.5
Вторая
декомпозиция
работы 1.2
2.2.7
NODE:
1.3
2.1.6
2.2.8
TITLE:
2.2.9
Context
NUMBER:

82. Пример построения модели IDEF3

ПРИМЕР ПОСТРОЕНИЯ МОДЕЛИ IDEF3
Рассмотрим на примере построения динамической
модели процесса «Выполнение курсовой работы»
Начнем с построения контекстной диаграммы
Выполнение
курсовой работы
1.1

83. Пример построения модели IDEF3

ПРИМЕР ПОСТРОЕНИЯ МОДЕЛИ IDEF3
Выполним декомпозицию контекстной диаграммы:
Выполнение
разделов к/р
1.1.4
Получение
задания
Подбор
литературы
&
1.1.2
1.1.3
J1
&
Посещение
консультаций
J2
Оформление
пояснит.
записки
1.1.6
1.1.5
OBJECT/
Преподаватель
Защита
1.1.7
Примечание: Обратите внимание на нумерацию единиц работ. Родительской
является работа с собственным номером 1. Она декомпозируется первый раз,
следовательно, версия декомпозиции = 1, далее следует собственный номер
единицы работ в рамках модели (2-7).

84. Пример построения модели IDEF3

ПРИМЕР ПОСТРОЕНИЯ МОДЕЛИ IDEF3
Выполним декомпозицию UOW №4 – «Выполнение разделов к/р»
ELAB/ Если есть ошибки
в расчетах – внесение
исправлений
Выполнение
расчетов
4.1.9
Написание
теор.части
4.1.8
Оформление
Х
&
&
Х
4.1.11
J6
J3
J4
Построение
графиков
4.1.10
J5

85. Пример построения модели IDEF3

ПРИМЕР ПОСТРОЕНИЯ МОДЕЛИ IDEF3
Продекомпозируем повторно контекстную диаграмму (в виде
сценария IDEF3 для выполнения курсовой работы по «Информатике
и программированию»)
Построение
блок-схемы
1.2.13
Получение
задания
1.2.12
&
&
J7
Написание
программы
Математическое
моделирование
J8
1.2.15
1.2.14
GOTO/ При обнаружении
ошибок при тестировании
возврат к 1.2.15
Тестирование
и отладка
1.2.16
Оформление
поясн. записки
1.2.17

86. Построение информационной модели процесса постройки садового домика

ПОСТРОЕНИЕ ИНФОРМАЦИОННОЙ МОДЕЛИ
ПРОЦЕССА ПОСТРОЙКИ САДОВОГО ДОМИКА
1. На основе функциональной модели IDEF0 составим
пул – список потенциальных сущностей.
Пул:
1. Дом
2. Крыша
3. Материалы
4. Проект дома
5. Стены
6. Строители
7. Фундамент
8. Каменщики
9. Плотники
10. Кровельщики
11. Мастера по отделке

87. Построение информационной модели процесса постройки садового домика

ПОСТРОЕНИЕ ИНФОРМАЦИОННОЙ МОДЕЛИ
ПРОЦЕССА ПОСТРОЙКИ САДОВОГО ДОМИКА
2. Определим сущности
Проект дома
Материал
Дом
Строитель
Фундамент
Стены
Крыша
Каменщ ик
Кровельщ ик
Плотник
Мастер по отделке

88. Построение информационной модели процесса постройки садового домика

ПОСТРОЕНИЕ ИНФОРМАЦИОННОЙ МОДЕЛИ
ПРОЦЕССА ПОСТРОЙКИ САДОВОГО ДОМИКА
Материал
Проект дома
3. Зададим атрибуты для каждой сущности и
установим связи между ними
№_проекта
Код_материала
ФИО_архитектора
Дата_создания
Стоимость_проекта
Название
Вид_материала
Характеристики
используется
используется для
P
Строитель
P
Табельный_номер
Дом
ФИО
Профессия
Стаж_работы
Адрес
Адрес
ФИО_хозяина
строит
Фундамент
Стены
Крыша
№_проекта (FK)
Код_материала (FK)
Табельный_номер (FK)
Вид
Дата_сдачи
Z
Профессия
Z
Z
Z
Z
Каменщ ик
Кровельщ ик
Плотник
Мастер по отделке
Табельный_номер (FK)
Табельный_номер (FK)
Табельный_номер (FK)
Табельный_номер (FK)