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

1. Функциональное моделирование

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

Система разбивается на функциональные подсистемы,
которые, в свою очередь, делятся на подфункции,
подфункции – на задачи и т.д. до конкретных процедур
…
…
…
Функция 1
Система
Функция 2
…
Подфункция 1
Задача 1
Подфункция 2
…
Задача 2
…
Подфункция n
Функция n
…
…
…
Задача n
…

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

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

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

Базовые
принципы структурного подхода
• принцип "разделяй и властвуй" –
принцип решения сложных проблем
путем их разбиения на множество
меньших независимых задач, легких
для понимания и решения;
• принцип
иерархического
упорядочивания
–
принцип
организации
составных
частей
проблемы
в
иерархические
древовидные
структуры
с
добавлением
новых
деталей
на
каждом уровне.

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

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

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

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

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

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

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

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

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

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

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

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

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

функция
Контекстная диаграмма определяет все
функции, входы и выходы, которые могут
появиться на диаграммах нижних уровней
А0
Каждая подфункция может содержать
только те элементы, которые входят в
исходную функцию.
Подфункц Выход
Подфункция
А1 ия 1
Подфункц Выход
Подфункци
А2 ия 2
я1
Вхо
д
Управлен
ие
Подфункц
А3 ия 3

12.

IDEF0
• Сущность методологии функционального моделирования
IDEF0
• Основные понятия методологии IDEF0
• Правила построения моделей IDEF0
• Пример функциональной модели в нотации IDEF0

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

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

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

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

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

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

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

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

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

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

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

Цель моделирования должна отвечать на следующие вопросы:
• Почему процесс должен быть смоделирован?
• Что должна показывать модель?
• Что может получить читатель?
Примеры целей: «Идентифицировать слабые стороны процесса
сбора данных», «Определить ответственность сотрудников для
написания должностных инструкций» и т.п.

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

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

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

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

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

А0
А11
А1
А2
А12
А13
А0 ____________
А1____________
А11___________
А12___________
А13___________
А2____________
А3____________
А3
Дерево узлов
Индекс узлов

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

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

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

1. На одной диаграмме рекомендуется рисовать от 3 до 6 блоков. Иначе
диаграмма будет плохо читаемой.
2. Функциональные блоки должны располагаться слева направо сверху вниз в
порядке доминирования.
3. Следует избегать излишнего пересечения стрелок.

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

4. Выход одного блока может являться входом (управлением) для
другого. Могут быть и обратные связи по входу и управлению.
Связь по управлению
Связь по входу

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

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

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

5. Стрелки могут быть сливающимися и
разветвляющимися
Слияние стрелок
Разветвление стрелок

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

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

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

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

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

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

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

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

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

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

32.

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

33. Контекстная функция

• Функциональная модель имеет иерархическую структуру.
• Контекстная функция – функция верхнего уровня модели.
• Контекстная функция несет имя основного действия выполняемого системой.
• Изображается на отдельной диаграмме, называемой контекстной.
Контекстная
функция
© 2002 ГОУ “ГМЦ CALS-технологий”

34. Контекстная диаграмма

• На контекстной диаграмме указываются связи системы с внешним миром.
Граничные
связи
© 2002 ГОУ “ГМЦ CALS-технологий”

35. Потоки на контекстной диаграмме

• Потоки делятся на:
• входные (то, что перерабатывается системой),
• выходные (результат работы системы),
• управления (регламентирующая и управляющая информации или правила)
• механизма (ресурсы выполняющие работы).
• Система преобразует входные потоки в выходные с учетом управления и с использованием
механизмов.
© 2002 ГОУ “ГМЦ CALS-технологий”

36. Миграция связей

• При декомпозиции связи
автоматически продолжаются на
следующем уровене
ICOM-код
© 2002 ГОУ “ГМЦ CALS-технологий”

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

• Диаграммы декомпозиции содержат
вложенное поуровневое описание
функций модели.
© 2002 ГОУ “ГМЦ CALS-технологий”

38. Диаграмма IDEF0 и ее элементы

• Диаграмма IDEF0 формируется из двух типов элементов:
• прямоугольники, обозначающие функциональные блоки
• стрелки, обозначающие информационные и материальные потоки.
Стрелки
Функциональный
блок
© 2002 ГОУ “ГМЦ CALS-технологий”

39. Диаграмма IDEF0 и ее элементы

Связи
управления
Входящие
связи
Выходящие
связи
Связи
механизмов
© 2002 ГОУ “ГМЦ CALS-технологий”

40. Изображение функции

• Изображается прямоугольником.
• Обозначает действие выполняемое над «входом» и выдающее в результате
«выход».
• Имя функции состоит из:
• глагола, определяющего действие функции;
• существительного определяющего объект или цель действия.
Действие
Объект
действия
Префикс
номера
Уникальный номер
функционального
блока
© 2002 ГОУ “ГМЦ CALS-технологий”

41. Расположение блоков на диаграмме

• Блок А1 доминирует над блоком А2
• Блок А2 доминирует над блоком А3
© 2002 ГОУ “ГМЦ CALS-технологий”

42. Нумерация функций и диаграмм

• Все функциональные блоки должны быть пронумерованы.
• Номер состоит из префикса и одной или нескольких цифр.
• Обычно используется префикс «А», но допустимо использовать
префикс любой длины.
• Контекстная функция всегда именуется А0.
• Функция А0 декомпозируется в функции А1, А2, А3 и т.д.
• Функция А2 декомпозируется в функции А21, А22, А23 и т.д.
Каждый уровень декомпозиции добавляет один разряд в номер
функционального блока.
© 2002 ГОУ “ГМЦ CALS-технологий”

43. Роль стрелок

• Показывают взаимодействие функций со внешним миром и между собой.
• Могут обозначать вещи, места, людей, события и понятия.
© 2002 ГОУ “ГМЦ CALS-технологий”

44. Обозначение стрелок

• Стрелки могут быть только однонаправленными.
• Именуются существительными.
• Подписи соединяются со стрелками с помощью специального элемента - тильды.
Тильда
© 2002 ГОУ “ГМЦ CALS-технологий”
Наименование
стрелки

45. Применение стрелок

• В литературе часто встречается термин ICOM
(Input/Control/Output/Mechanism), обозначающий четыре основных типа
стрелок:
вход;
управление;
выход;
механизм.
• Механизм и управление не видоизменяются в процессе выполнения
функции.
• Если какой либо поток данных преобразуются функцией, то характер этих
изменений должен быть отражен в названии потоков на входе и выходе.
© 2002 ГОУ “ГМЦ CALS-технологий”

46. Входные стрелки

• Вход (Input) – материальный или информационный поток который потребляется или
преобразовывается функцией чтобы произвести результат работы на выходе.
• Входит в левую грань блока.
• Присутствие не обязательно.
• Если какой либо поток данных преобразуются функцией, то характер этих изменений
должен быть отражен в названии потоков на входе и выходе.
© 2002 ГОУ “ГМЦ CALS-технологий”

47. Управление

• Управление (Control) – содержит неизменяемые объекты:
• правила;
• инструкции;
• стандарты в соответствии с которыми выполняется функция.
• Присутствие обязательно.
• Изображается как входящая в верхнюю грань блока.
© 2002 ГОУ “ГМЦ CALS-технологий”

48. Выход

• Выход (Output) – результат работы функции.
• Присутствие выходов обязательно.
• Изображается как выходящая из правой грани.
© 2002 ГОУ “ГМЦ CALS-технологий”

49. Механизм

• Механизм (Mechanism) – неизменяемые ресурсы выполняющие работу
функции, например организационные единицы предприятия, отдельные
работники, машины и механизмы, вычислительные системы и программные
средства.
• Присутствие обязательно.
• Изображается как входящая в нижнюю грань.
© 2002 ГОУ “ГМЦ CALS-технологий”

50. Граничные связи

Граничные стрелки начинаются от границ диаграммы и заканчиваются у функции или
наоборот.
Связывают функции диаграммы с внешним миром.
Определяются на родительской диаграмме
Для идентификации граничных стрелок используются ICOM-коды.
ICOM-код
© 2002 ГОУ “ГМЦ CALS-технологий”

51. Внутренние связи

Внутренние связи не касаются границ диаграммы.
Разделяются на виды:
Выход-вход.
Выход-управление.
Выход-механизм.
Обратная связь по входу.
Обратная связь по управлению.
Обратная связь по механизму.
© 2002 ГОУ “ГМЦ CALS-технологий”

52. Выход-вход

• Описывает последовательность обработки потока объектов.
Выход-вход
© 2002 ГОУ “ГМЦ CALS-технологий”

53. Выход-управление

• Предшествующая функция управляет выполнением последующей функции.
Выход-управление
© 2002 ГОУ “ГМЦ CALS-технологий”

54. Выход-механизм

• Одна функция выбирает или создает ресурс, который будет являться
исполнительным механизмом другой функции.
Выход-механизм
© 2002 ГОУ “ГМЦ CALS-технологий”

55. Обратная связь по входу

• Выход функции направляется на вход предыдущей.
• Используется для описания возможности повторной обработки потока объектов или
для описания циклических действий над потоком.
Обратная связь по
входу
© 2002 ГОУ “ГМЦ CALS-технологий”

56. Обратная связь по управлению

• Выход функции направляется на управление одной из предыдущих функций.
• Например, она может описывать обратную связь, регулирующую производственные
процессы, что может повлиять на качество выпускаемого изделия.
Обратная
связь по
управлению
© 2002 ГОУ “ГМЦ CALS-технологий”

57. Слияние стрелок

Функция производит объекты, которые используется в нескольких других
функциях.
Объекты, полученные в результате работы нескольких функций,
объединяются в один общий поток.
• Случай когда какой либо
однотипный
результат
получается от двух различных
функций.
Достаточно отметить
только общую часть стрелки.
• Два
различных
сливаются в один
выхода
общий.
Должны быть отмечены каждая
ветвь и общий участок связи.
© 2002 ГОУ “ГМЦ CALS-технологий”

58. Разветвление

• Поток разветвляясь сохраняет
первоначальное содержание.
• Подпись необходима только
для общей части стрелки.
• Поток ответвляется от общего
потока, неся в себе часть
объектов (чертежи).
• Подписываются общая стрелка
и ответвления.
• Если ответвление не подписано,
то оно несет в себе общий поток
объектов.
© 2002 ГОУ “ГМЦ CALS-технологий”

59. Разветвление

• Разделение общего потока
на несколько независимых
потоков.
• Обозначается общая часть
стрелки
и
каждое
ответвление.
• Ошибка - не именованы
общая часть стрелки и какая
либо из ветвей.
© 2002 ГОУ “ГМЦ CALS-технологий”

60. Применение туннелей

• Применяются когда:
• хотят чтобы стрелка используемая только
начиная с какого либо уровня не
присутствовала на всех промежуточных
уровнях декомпозиции. Это помогает
освободить промежуточные диаграммы от
неиспользуемых стрелок.
• необходимо скрыть граничную стрелку на
диаграмме декомпозиции.
© 2002 ГОУ “ГМЦ CALS-технологий”

61. Методика построения модели

1.
2.
3.
Определение предмета моделирования
Определение цели и точки зрения
Создание контекстной функции
Цель: Внедрение электронного документооборота
Точка зрения: Команда по внедрению
© 2002 ГОУ “ГМЦ CALS-технологий”

62. 4. Определение основных граничных ICOM

• Цель любой функции - получение какого-либо результата.
• Следовательно нужно начать с определения выходов функций.
• Далее в следующей последовательности:
• определение входов;
• определение управления;
• определение механизмов.
2
4
1
3
Цель: Внедрение электронного документооборота
Точка зрения: Команда по внедрению
© 2002 ГОУ “ГМЦ CALS-технологий”

63. 5. Декомпозиция

AUTHOR:
PROJECT:
USED AT:
DATE: 28.10.2002
REV:
NOTES: 1 2 3 4 5 6 7 8 9 10
Конструкторская
документация
x
WORKING
DRAFT
RECOMMENDED
PUBLICATION
READER
Производственная
программа
Нормативные
документы
C1
C2
DATE
CONT EXT :
A-0
I1
Расцеховка
Технологические
процессы
I2
O1
A1
Состав
изделий
I3
Карточки
технологических
процессов
A2
O2
ТЗ на разработку
технологической
документации
Разрешения
технологические
I4
O3
A3
M1
Цех, ХМО, ОГТ, ЕОТД
NODE:
A0
TITLE:
Разрабатывать, согласовывать и утверждать технологическую документацию
© 2002 ГОУ “ГМЦ CALS-технологий”
NUMBER:
P. 2

64. 6. Построение основных функций диаграммы верхнего уровня

AUTHOR:
PROJECT:
USED AT:
DATE: 28.10.2002
REV:
NOTES: 1 2 3 4 5 6 7 8 9 10
Конструкторская
документация
x
WORKING
DRAFT
RECOMMENDED
PUBLICATION
READER
Производственная
программа
Нормативные
документы
C1
C2
DATE
CONT EXT :
A-0
I1
Разрабатывать
технологическую
документацию
Расцеховка
I2
Технологические
процессы
O1
A1
Утверждать
технологическую
документацию
Состав
изделий
I3
Карточки
технологических
процессов
A2
O2
ТЗ на разработку
технологической
документации
Ставить на учет
технологическую
документацию
I4
Разрешения
технологические
O3
A3
M1
Цех, ХМО, ОГТ, ЕОТД
NODE:
A0
TITLE:
Разрабатывать, согласовывать
и утверждать
технологическую документацию
© 2002 ГОУ “ГМЦ
CALS-технологий”
NUMBER:
P. 2

65. 7. Построение основных связей на диаграмме верхнего уровня

2
4
1
3
© 2002 ГОУ “ГМЦ CALS-технологий”

66. Определение Выходов

• Нужно отразить все возможные варианты связанные с результатами
работы функции.
• Действие некоторых функций может заканчиваться неудачно.
• Выходы должны отражать любое развитие событий.
• Отрицательные результаты часто используются при создании стрелок
обратной связи и должны быть рассмотрены для каждой функции.
• Полезно включить в модель сомнительные или неясные стрелки,
обозначенные знаком вопроса, чтобы потом обсудить их с экспертом.
© 2002 ГОУ “ГМЦ CALS-технологий”

67. Определение Управления

• Управление принимает форму:
правил;
стандартов;
рекомендаций;
инструкций.
• Управление - «неизменная» форма входа.
• Если возникает затруднение с определением характера связи
между входом и управлением, то следует выбирать управление
© 2002 ГОУ “ГМЦ CALS-технологий”

68. Определение Механизмов

• Механизм включает в себя:
людей;
машины и механизмы;
вычислительные системы.
любые материальные ресурсы силами или с помощью которых
выполняются действия функции.
© 2002 ГОУ “ГМЦ CALS-технологий”

69. Определение Входов

• Входы - объекты из которых получаются объекты на выходе.
• При работе с материальными объектами они преобразуются в
выходное изделие или уничтожаются в результате действия
функции.
• Информационный объект может остаться нетронутым.
© 2002 ГОУ “ГМЦ CALS-технологий”

70. 8. Декомпозиция блоков диаграммы верхнего уровня

AUTHOR:
PROJECT:
USED AT:
DATE: 28.10.2002
REV:
NOTES: 1 2 3 4 5 6 7 8 9 10
Конструкторская
документация
C1
x
WORKING
DRAFT
RECOMMENDED
PUBLICATION
READER
DATE
Производственная
программа
C2
CONT EXT :
Нормативные A0
документы
I1
Состав
изделий
I2
A11
O1
Разработанная
технологическая
документация
A12
I3
ТЗ на разработку
технологической
документации
A13
I4
Замечания по
технологической
документации
A14
A15
M1
Цех, ХМО
NODE:
A1
TITLE:
Разрабатывать
технологическую документацию
© 2002 ГОУ
“ГМЦ
CALS-технологий”
NUMBER:
P. 3

71. Резюме

© 2002 ГОУ “ГМЦ CALS-технологий”