Материал: 1778

Внимание! Если размещение файла нарушает Ваши авторские права, то обязательно сообщите нам

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

 

А

If A

Case off

White A

Do B

For A

 

 

 

Then B

1 A1

Do B

Until A

Do B

 

В

 

 

 

Else C

2 A2

 

 

 

 

 

 

 

 

 

. . .

Следование Условный

Case

 

выбор

выбор

Операторы цикла

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

В псевдокодах алгоритмы записываются с помощью как средств некоторого языка программирования (преимущественно для управляющих операторов), так и естественного языка (для выражения содержания вычислительных блоков). Используются конструкции (операторы) следования, условные, цикла. Служебные слова из базового языка программирования или из DFD записываются заглавными буквами, фразы естественного языка – строчными. Языки четвертого поколения предназначены для описания программ как совокупностей заранее разработанных программных модулей. Поэтому одна команда языка четвертого поколения может соответствовать значительному фрагменту программы на языке 3GL. Примерами языков 4GL могут служить Informix-4GL, JAM, NewEra, XAL.

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

111

Технологии реинжиниринга и параллельного проектирования

Взаимосвязанная совокупность методик IDEF для концептуального проектирования разработана по программе Integrated Computer Aided Manufacturing в США. В этой совокупности имеются методики функционального, информационного и поведенческого моделирования и проектирования, в ее состав в настоящее время входят IDEFметодики, часть из которых имеет статус международного стандарта.

Методики IDEF задают единообразный подход к моделированию приложений, но не затрагивают проблем единообразного представления данных в процессах информационного обмена между разными компьютерными системами и приложениями. Необходимость решения этих проблем в интегрированных АС привела к появлению ряда унифицированных форматов представления данных в межкомпьютерных обменах, среди которых наиболее известными являются форматы IGES, DXF (в машиностроительных приложениях), EDIF (в электронике) и некоторые другие. Однако ограниченные возможности этих форматов обусловили продолжение работ в направлении создания более совершенных методик и представляющих их стандартов. На эту роль в настоящее время претендует совокупность стандартов

STEP.

Методика IDEF0

Наиболее известной методикой функционального моделирования сложных систем является методика SADT (Structured Analysis and Design Technique), положенная в основу стандарта IDEF0. IDEF0 – это более четко очерченное представление методики SADT. SADT – методика, рекомендуемая для начальных стадий проектирования сложных искусственных систем управления, производства, бизнеса, включающих людей, оборудование, ПО. Начиная с момента создания первой версии, методика успешно применялась для проектирования телефонных сетей, систем управления воздушными перевозками, производственных предприятий и др.

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

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

112

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

Рис. 22. Блок ICOM в IDEF0-диаграммах

Блоки выражают функции (работы), поэтому их названиями обычно являются глаголы или отглагольные существительные. Типичные примеры функций: планировать, разработать, классифицировать, измерить, изготовить, отредактировать, рассчитать, продать (или планирование, разработка, классификация, измерение, изготовление, редактирование, расчет, продажа). Число блоков на одном уровне иерархии – не более 6, иначе восприятие диаграмм будет затруднено. Число уровней иерархии не ограничено, но обычно их не более 5. Блоки нумеруются (номер записывается в правом нижнем углу). Дуги (стрелки) отображают множества объектов (данных), их имена – существительные. Управление определяет условия выполнения, примеры управления: требования, чертеж, стандарт, указания, план. Механизм выражает используемые средства, например: компьютер, оснастка, заказчик, фирма. Входы и выходы могут быть любыми объектами.

Блоки рис. 22 в англоязычной литературе называют блоками

ICOM (Input – Control – Output – Mechanism).

Рассмотрим пример функциональной модели для процесса создания САПР на предприятии, на котором ранее автоматизация проектирования была развита слабо. Диаграмма верхнего (нулевого) уровня АО включает единственный блок ICOM «Разработать САПР». В качестве исполнителей фигурируют специализированная организация, за-

113

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

Диаграмма первого уровня, показанная на рис. 23,а, включает блоки А1 – обследования предприятия; А2 – проектирования САПР; A3 – реализации САПР и А4 – испытаний системы.

Диаграммы следующего второго уровня, раскрывающие первые блоки Al, A2 и A3, представлены на рис. 23, б, в и г соответственно (на этих рисунках не отмечены данные, соответствующие внутренним стрелкам диаграмм). При обследовании предприятия специалисты консалтинговой фирмы вместе с работниками отдела САПР изучают структуру предприятия, типичные маршруты проектирования, информационные потоки и на этой базе разрабатывают модель «As Is». Далее создается новая модель «To Be» с учетом не только требований автоматизации проектирования, но и будущих информационных потребностей процессов управления и делопроизводства. Модель «To Be» составляет основу технического предложения на создание САПР.

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

114

115