Автоматизированное проектирование. Норенков И.П. - 157 стр.

 5@!"! 6                                      %*#$A&,&    +($*,#&($"!)&P !"#$%!#&'&($"!))KH :&:#*%

ют проблем единообразного представления данных в процессах информационного обмена между раз-
ными компьютерными системами и приложениями. Необходимость решения этих проблем в интегри-
рованных АС привела к появлению ряда унифицированных форматов представления данных в меж-
компьютерных обменах, среди которых наиболее известными являются форматы IGES, DXF (в маши-
ностроительных приложениях), EDIF (в электронике) и некоторые другие. Однако ограниченные воз-
можности этих форматов обусловили продолжение работ в направлении создания более совершенных
методик и представляющих их стандартов. На эту роль в настоящее время претендует совокупность
стандартов STEP.
      E.-45+7: IDEF0. Как отмечено выше, наиболее известной методикой E7*%='#*)45*#8# /#-$-
4'"#()*'9 сложных систем является методика SADT (Structured Analysis and Design Technique), поло-
женная в основу стандарта IDEF0.
      IDEF0 — это более четко очерченное представление методики SADT. SADT — методика, реко-
мендуемая для начальных стадий проектирования сложных искусственных систем управления, про-
изводства, бизнеса, включающих людей, оборудование, ПО. Начиная с момента создания первой вер-
сии, методика успешно применялась для проектирования телефонных сетей, систем управления воз-
душными перевозками, производственных предприятий и др.
      Разработку SADT-модели начинают с формулировки вопросов, на которые модель должна да-
вать ответы, т.е. формулируют цель моделирования. Далее строят иерархическую совокупность диа-
грамм с лаконичным описанием функций.
      Недостатки SADT-моделей — их слабая формализованность для автоматического выполнения
проектных процедур на их основе. Однако наличие графического языка диаграмм, удобного для вос-
приятия человеком, обусловливает полезность и применимость методики SADT.
      Описание объектов и процессов в SADT (IDEF0) выполняется в виде совокупности взаимосвя-
занных блоков (рис. 6.3).
      Блоки выражают функции (работы), поэтому их назва-
ниями обычно являются глаголы или отглагольные существи-
тельные. Типичные примеры функций: планировать, разрабо-
тать, классифицировать, измерить, изготовить, отредактиро-
вать, рассчитать, продать (или планирование, разработка,
классификация, измерение, изготовление, редактирование,
расчет, продажа). Число блоков на одном уровне иерархии — %+,. 6.3. Блок ICOM в IDEF0-диаграммах
не более 6, иначе восприятие диаграмм будет затруднено.
Число уровней иерархии не ограничено, но обычно их не более 5. Блоки нумеруются (номер записы-
вается в правом нижнем углу). Дуги (стрелки) отображают множества объектов (данных), их имена —
существительные. Управление определяет условия выполнения, примеры управления: требования,
чертеж, стандарт, указания, план. Механизм выражает используемые средства, например: компьютер,
оснастка, заказчик, фирма. Входы и выходы могут быть любыми объектами.
      Блоки рис. 6.3 в англоязычной литературе называют блоками ICOM (Input — Control — Output
— Mechanism).
      Рассмотрим пример функциональной модели для процесса создания САПР на предприятии, на котором ранее авто-
матизация проектирования была развита слабо.
      Диаграмма верхнего (нулевого) уровня А0 включает единственный блок ICOM “Разработать САПР”. В качестве
исполнителей фигурируют специализированная организация, занимающаяся проектированием автоматизированных сис-
тем и называемая консалтинговой фирмой, а также представители организации-заказчика, объединенные в создаваемый
на предприятии отдел САПР.
      Диаграмма первого уровня, показанная на рис. 6.4,а, включает блоки А1 — обследования предприятия, А2 — про-
ектирования САПР, А3 — реализации САПР и А4 – испытаний системы. Диаграммы следующего второго уровня, раскры-
вающие первые блоки А1, А2 и А3, представлены на рис. 6.4,б, в и г соответственно (на этих рисунках не отмечены дан-
ные, соответствующие внутренним стрелкам диаграмм). При обследовании предприятия специалисты консалтинговой
фирмы вместе с работниками отдела САПР, изучают структуру предприятия, типичные маршруты проектирования, ин-
формационные потоки и на этой базе разрабатывают модель “As Is”. Далее создается новая модель “To Be” с учетом не
только требований автоматизации проектирования, но и будущих информационных потребностей процессов управления
и делопроизводства. Модель “To Be” составляет основу технического предложения на создание САПР.

 &.+.)$(*),$" . !"#$%!#&'&($"!))$*                +($*,#&($"!)&*                                           157