Норенков И.П. Основы автоматизированного проектирования

Подождите немного. Документ загружается.

J. 4.

Автоматизированные

системы

управления

Инструментальную среду

ISaGRAF

используют

для

разработки прикладного

ПО

про-

граммируемых контроллеров PLC. Среда реализует методологию граф-схем Flowchart

пять языков программирования

по

стандарту

МЭК

61131-3

(IEC

1131-3).

Это

графичес-

кие

языки функциональных схем SFC, блоковых диаграмм FBD, диаграмм релейной

ло-

гики

LD и

текстовые языки

паскалеподобный

низкоуровневый

язык инструкций

IL.

Автоматизированные

системы

делопроизводства

Информационные технологии

и АСУ

документами

документооборотом

пользуются

все

возрастающим вниманием среди предприятий

фирм различ-

ного профиля, поскольку организация работы

документами существенно вли-

яет на

эффективность производственных

бизнес-процессов. Такие системы

не

только имеют самостоятельное значение,

но и

играют важную роль

интег-

рированных

АС

управления

проектирования.

Автоматизированные

системы делопроизводства

(АСД)

по

своему назна-

чению подразделяют

на

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

(СУД),

управления

документооборотом

(СДО),

управления знаниями

(в

сфере

де-

лопроизводства)

инструментальные среды делопроизводства.

соответствии

другими

критериями классификации

системы

делопроизводства

подразделя-

ют на

специализированные

комплексные, локальные

распределенные, фак-

тографические

документографические

(полнотекстовые), заказные

тира-

жируемые.

Системы управления техническими документами

документооборотом,

относящиеся

сфере проектирования

производства

промышленности,

на-

зывают системами управления техническими данными

или

системами

TDM

(Technical

Data

Management). Специфические отличия систем

TDM от

офис-

ных АСД

заключаются

большом числе чертежной документации

и в

тесной

взаимосвязи

САПР.

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

для

обеспечения санк-

ционированного доступа

документам. Характерные функции СУД:

•

ввод документов,

частности,

помощью средств

их

автоматического

распознавания;

•

индексирование документов, например, оформление регистрационных кар-

точек

полями

для

атрибутов; возможно атрибутивное индексирование

(к ат-

рибутам относятся автор документа, дата создания

ключевые слова)

или

полнотекстовое

индексирование

(в

индекс заносят весь текст,

но без

предло-

гов

окончаний некоторых слов);

•

хранение документов;

•

поиск нужных данных, который может

быть

атрибутивным

фактографи-

ческих базах данных

или

полнотекстовым

случае слабоструктурированных

документов;

•

поддержка групповой работы

над

документами;

•

разграничение прав доступа

документам;

•

контроль

управление версиями документов, регламентирующие внесе-

ние

в них

изменений;

•

сбор

анализ статистических данных

по

параметрам документов

функ-

ционированию системы;

243

Методическое

программное обеспечение автоматизированных систем

•

подготовка

отчетов.

Системы управления документооборотом служат

для

управления деловы-

ми

процессами прохождения

обработки документов

соответствующих под-

разделениях

службах организации. Характерные функции СДО:

•

регистрация документов

при их

вхождении

систему;

•

маршрутизация документов,

учет

их

движения (маршрутизация может быть

жесткой

при

фиксированных маршрутах

или

свободной); управление потоками

документов обеспечивает прохождение документов

по

заданному маршруту

контролем

внесения

в них

резолюций, управление внесением изменений вклю-

чает систему приоритетов, средства протоколирования изменений;

•

контроль исполнения предписываемых документами действий;

•

защита информации

при ее

передаче между пунктами распределенной

си-

стемы;

•

автоматическое уведомление соответствующих

лиц о

состоянии докумен-

тов

содержащихся

в них

директив

рекомендаций;

•

планирование работ, связанных

прохождением документов.

системам управления знаниями

области делопроизводства относят

си-

стемы, выполняющие функции, характерные

для

интеллектуальных систем. При-

меры таких функций:

классификация

документов

по тем или

иным признакам;

взаимное связывание документов, например,

помощью гипертекста;

тематический отбор документов;

интеграция

данных,

поступающих

из

различных источников;

аналитическая обработка данных;

моделирование

деловых

процессов.

Инструментальные

среды

системах делопроизводства служат

для

фор-

мирования

АСД, адаптированных

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

фирм.

Часто такое формирование проводится путем дополнения некоторого базового

компонента,

состав системы входит соответствующий

язык

расширения.

Кроме

перечня решаемых задач выделяют следующие свойства

характе-

ристики АСД:

•

открытость, программные интерфейсы

форматы данных

для

обмена

другими информационными системами;

•

мобильность

для

инсталляции

на

ведущих платформах;

•

модульное построение,

что

обеспечивает масштабируемость

—

возмож-

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

на

предприятиях

по

частям;

•

пользовательский интерфейс;

•

быстродействие, временные затраты

на

выполнение задач;

•

уровень защиты информации;

•

соответствие стандартам информационных технологий;

•

операционные среды

используемые СУБД, требования

аппаратным

ресурсам.

•

перенос документов

по

мере

их

устаревания

на

более дешевые носители.

244

5 5

Инструментальные

средства

концептуального

проектирования

Основными компонентами систем управления документами

документо-

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

контроля исполнения, модули сопряжения

прикладными программами, сред-

ства ввода информации

бумажных носителей.

крупных

АСД

предусматривается распределенное хранение

доступом

документам

режимах

как

off-line,

так и

on-line.

первом случае пользова-

тель формирует запрос

виде совокупности ключевых слов

направляет

его

средствами электронной почты (E-mail),

СДО

выдает список релевантных

до-

кументов, пользователь выбирает

из

списка нужные документы

посылает

вторичный более конкретный запрос, получая

по

E-mail запрошенные докумен-

ты. Во

втором случае используется связь

реальном времени: документ

вы-

зывается

на

экран дисплея

пользователь может непосредственно

его

про-

сматривать

редактировать.

Современные корпоративные системы делопроизводства являются распре-

деленными, имеющими архитектуру клиент

—

сервер.

На

серверной стороне

находят применение серверы

баз

данных, полнотекстовых документов, элект-

ронной почты, приложений, SQL-

Web-серверы.

На

клиентской

стороне

могут

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

разработчиков

баз

данных, информационно-поисковых систем, форм документов

т. п. В

час-

тности, применяются

трехзвенные

распределенные системы.

широко

известным

СДО и АСД

относятся Lotus Notes, Docs Open,

ДЕЛО-96

и др.

Примерами систем

TDM на

20-30

одновременно работающих пользователей могут

слу-

жить

или

T-Flex

DOCs

и на

большее число пользователей

системы документо-

оборота, используемые

в PDM

Optegra

или

iMAN.

5.5.

Инструментальные средства концептуального

проектирования автоматизированных систем

Типы

CASE-систем

современных информационных технологиях важное место отводится

ин-

струментальным средствам

средам разработки

АС, в

частности системам

разработки

сопровождения

их ПО. Эти

технологии

среды образуют систе-

мы,

называемые

CASE-системами.

Аббревиатура CASE имеет двоякое толкование, соответствующее двум

на-

правлениям использования CASE-систем. Первое

из них —

Computer

Aided

System

Engineering

—

подчеркивает направленность

на

поддержку концепту-

ального

проектирования сложных

систем,

преимущественно слабоструктури-

рованных. Далее

CASE-системы

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

ми

CASE

для

концептуального

проектирования.

Второе

направление называют

Computer

Aided

Software

Engineering,

что

переводится

как

автоматизирован-

ное

проектирование программного обеспечения. Соответствующие CASE-си-

стемы называют инструментальными

CASE

или

инструментальными среда-

ми

разработки

ПО.

245

Методическое

программное обеспечение автоматизированных систем

Среди систем CASE

для

концептуального проектирования различают сис-

темы функционального, информационного

или

поведенческого проектирования.

Наиболее известной методикой

функционального

проектирования сложных

систем является методика SADT (Structured Analysis

and

Design Technique),

предложенная

1973

г. Р.

Россом

впоследствии ставшая основой стандарта

IDEFO

(Integrated

DEFinition

0).

Системы

информационного

проектирования реализуют методики инфо-

логического

проектирования

баз

данных. Широко используются

язык

мето-

дика

создания информационных моделей приложений, закрепленные

методи-

ке

IDEF1X.

Кроме

того,

развитые коммерческие СУБД,

как

правило, имеют

своем составе совокупность CASE-средств проектирования приложений.

Основные положения стандартов

IDEFO

IDEFIX

использованы также

при

создании

комплекса стандартов

ISO

10303,

лежащих

основе технологии STEP

для

представления

компьютерных средах информации, относящейся

проек-

тированию

производству

промышленности.

Поведенческое

моделирование

сложных систем используют

для

опреде-

ления

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

В его

основе лежат моде-

ли

методы имитационного моделирования систем массового обслуживания,

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

щих

поведение системы

как

последовательность смены состояний.

Применение инструментальных CASE-систем ведет

сокращению затрат

на

разработку

ПО за

счет уменьшения числа итераций

числа ошибок,

улуч-

шению качества продукта вследствие лучшего взаимопонимания разработчи-

ка

заказчика,

облегчению

сопровождения

готового

ПО.

Среди

инструментальных CASE-систем различают интегрированные комп-

лексы

инструментальных средств

для

автоматизации всех этапов жизненного

цикла

ПО

(такие системы называют

Workbench}

специализированные инст-

рументальные средства

для

выполнения отдельных функций (Tools). Средства

CASE-систем

по

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

одной

из

следующих групп:

средства программирования;

средства управления

программным проектом;

средства

верификации

(анализа)

программ;

сред-

ства документирования.

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

алгоритмичес-

ких

языков;

построители диаграмм потоков данных; планировщики

для

постро-

ения

высокоуровневых спецификаций

планов

ПО

(возможно

на

основе

баз

знаний, реализованных

экспертных системах); интерпретаторы языков спе-

цификаций

языков четвертого поколения;

прототайпер

для

разработки вне-

шних интерфейсов

—

экранов, форм выходных документов, сценариев диалога;

генераторы программ определенных классов (например, конверторы заданных

языков,

драйверы устройств программного управления, постпроцессоры); кросс-

средства; отладчики программ.

При

этом

под

языками спецификаций понима-

ют

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

программ,

языкам

4GL

относят языки

для

компиляции программ

из

набора готовых

модулей,

реализующих типовые функции достаточно общих приложений (чаще

всего

это

функции технико-экономических

систем).

246

5.5. Инструментальные

средства

концептуального

проектирования

Управление программным проектом называют также управлением конфи-

гурациями

ПО.

Этому понятию

соответствуют

корректное внесение измене-

ний

программную систему

при ее

проектировании

сопровождении, контроль

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

параллельной работы членов коллектива разработчиков. Использование средств

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

системы

из

сотен

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

модернизировать

уже

поставленные заказчикам системы.

Основой

средств

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

репозито-

рий -

база данных проекта. Именно

репозитории

отражена история развития

программного проекта, содержатся

все

созданные версии (исходный программ-

ный

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

ция

и т.

п.),

помощью

репозитория

осуществляются контроль

отслеживание

вносимых изменений.

Средства верификации служат

для

оценки эффективности исполнения раз-

рабатываемых программ

определения наличия

в них

ошибок

противоречий.

Различают

статические

динамические анализаторы.

статических

анализа-

торах

ПО

исследуется

на

наличие неопределенных данных, бесконечных

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

и т. п.

Динамический анализатор

функционирует

процессе исполнения проверяемой программы;

при

этом

ис-

следуются трассы, измеряются частоты обращений

модулям

и т. п.

Используе-

мый

математический аппарат

—

сети Петри, теория массового обслуживания.

последнюю

из

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

для

оформле-

ния

программной документации, например

отчетов

по

данным репозитория;

различные редакторы

для

объединения, разделения,

замены,

поиска фрагмен-

тов

программ

других

операций редактирования.

Проектирование

ПО с

помощью CASE-систем включает

себя несколько

этапов. Начальный этап

—

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

представляют

виде

исходной диаграммы потоков данных

согласуют

с за-

казчиком.

На

следующем

этапе выполняют детализацию ограничений

функ-

ций

программной системы

полученную логическую модель вновь согласуют

заказчиком. Далее разрабатывают физическую модель,

т. е.

определяют

мо-

дульную структуру программы, выполняют

инфологическое

проектирование

баз

данных,

детализируют

граф-схемы программной системы

и ее

модулей.

Подсистема CASE

составе системной среды САПР предназначена

для

адаптации САПР

нуждам конкретных пользователей, разработки

сопро-

вождения прикладного

ПО. Ее

можно рассматривать

как

специализированную

САПР,

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

САПР,

частности

версии,

адаптированные

требованиям конкретного заказ-

чика.

Другими словами, такие

CASE-подсистемы

позволяют пользователям

формировать сравнительно

малыми затратами усилий варианты прикладных

ПМК

из

имеющегося базового набора модулей

под

заданный узкий диапазон

конкретных

условий проектирования.

247

Методическое

программное обеспечение автоматизированных систем

CASE-система,

как

система проектирования

ПО,

содержит компоненты

для

разработки структурных схем алгоритмов

«экранов»

для

взаимодействия

пользователем

интерактивных процедурах, средства

для

инфологического

проектирования

баз

данных, отладки программ, документирования, сохране-

ния

«истории» проектирования

т. п.

Наряду

этим

CASE-подсистему

САПР

входят

компоненты

со

специфическими

для

САПР функциями.

Так,

состав

САПР Microstation

(фирма

Bentley

Systems)

включена

инструменталь-

ная

среда

Microstation

Basic

язык

MDL

(Microstation

Development

Language)

соответ-

ствующей

программной

поддержкой.

Язык

MDL

—

С-подобный,

с его

помощью

можно

лаконично выразить

обращения

проектным операциям

процедурам.

целом

среда

Microstation

Basic

близка

по

своим

функциям

среде

Visual

Basic,

в ней

имеются

генератор

форм,

редактор,

конструктор

диалога,

отладчик.

САПР

Спрут

(российская

фирма

Sprut

Technologies),

вообще

говоря,

создана

как

инструментальная

среда

для

разработки

пользователем

потоков задач конструкторского

технологического

проектирования

машиностроении

последующим

возможным

оформлением потоков

виде

пользовательских

версий

САПР. Сконструированный

по-

ток

поддерживается

компонентами

системы,

число

которых

входят

графические

2D- и

ЗД-подсистемы,

СУБД,

продукционная экспертная

система,

документатор,

технологи-

ческий

процессор

создания

программ

для

станков

ЧПУ,

постпроцессоры.

Наиболее

известной

CASE-системой

составе

САПР

настоящее

время

является

описываемая ниже

система

CAS.CADE

фирмы

MatraDatavision,

с ее

помощью

фирма

разработала

версию

Euclid

Quantum

своей

САПР

Euclid.

Спецификации

проектов

программных

систем

Важное значение

процессе разработки

ПО

имеют средства специфика-

ции

проектов

ПО.

Средства спецификации

значительной мере определяют

суть методов CASE.

Способы

средства спецификации классифицируют

по

базовой методоло-

гии,

используемой

для

декомпозиции

ПО как

сложной системы,

и по

аспектам

моделирования

ПО.

Различают

два

подхода

декомпозиции

ПО.

Первый способ называют функ-

циональным

или

структурным.

Он

основан

на

выделении функций

потоков

данных. Второй способ

объектный, выражает идеи объектно-ориентирован-

ного проектирования

программирования.

Аспектами моделирования приложений являются функциональное, поведен-

ческое

информационное описания.

Практически

все

способы функциональных спецификаций имеют следую-

щие

общие черты:

•

модель имеет иерархическую структуру, представляемую

виде диа-

грамм нескольких уровней;

•

элементарной частью диаграммы каждого уровня является конструкция

вход

функция

выход;

•

необходимая дополнительная информация содержится

файлах поясняю-

щего текста.

большинстве случаев функциональные диаграммы являются диаграмма-

ми

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

(DFD

Data Flow Diagram). Блоки (прямоугольники)

DFD

соответствуют функциям, дуги

входным

выходным потокам данных. Пояс-

няющий

текст представлен

виде «словарей данных»,

которых указаны ком-

248

5 5

Инструментальные средства концептуального проектирования

Поток

данных

Имя -

Хранилище

данных

-Процесс

Имя

-Внешняя

сущность

Рис. 5.3. Изображения

элементов

нотации

Йордана

понентный

состав потоков данных, число повторений циклов

и т. п. Для

описа-

ния

структуры информационных потоков можно использовать нотацию

Бэ-

куса

Наура.

Одна

из

нотаций

для DFD

предложена

Е.

Йорданом.

В ней

описывают про-

цессы (функции), потоки данных, хранилища

внешние сущности,

их

условные

обозначения

показаны

на

рис.

5.3.

Разработка

DFD

начинается

построения диаграммы верхнего уровня,

от-

ражающей

связи программной системы, представленной

виде единого про-

цесса,

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

до

уровня,

на ко-

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

одностраничными

описаниями алгоритмов (мини-спецификациями)

на

терми-

нальном

языке программирования.

Для

описания информационных моделей наибольшее распространение

по-

лучили диаграммы сущность

отношение

(ERD

—

Entity-Relation

Diagrams),

которых предусмотрены средства

для

описания сущностей, атрибутов

отно-

шений.

Спецификации хранилищ данных

CASE,

как

правило, даются

помо-

щью

диаграмм сущность

отношение. Стандартной методикой построения

таких диаграмм является

IDEF1X.

Поведенческие

модели

о'писывают

процессы обработки информации.

В ин-

струментальных CASE-системах

их

представляют

виде граф-схем, диаграмм

перехода

состояний, таблиц решений, псевдокодов (языков спецификаций), про-

цедурных

языков

программирования,

в том

числе

языков

четвертого поколе-

ния.

граф-схемах,

как и в

диаграммах DFD, блоки используют

для

задания

процессов обработки,

но

дуги

имеют иной смысл

они

описывают последова-

тельность передач управления (вместе

со

специальными блоками управления).

диаграммах

перехода

состояний

узлы соответствуют состояниям

мо-

делируемой системы,

дуги

переходам

из

состояния

состояние, атрибуты

дуг

условиям перехода

инициируемым

при их

выполнении действиям. Оче-

видно,

что,

как и в

других конечно-автоматных моделях, кроме графической

формы

представления диаграмм перехода состояний можно использовать так-

же

табличные формы. Так,

при

изоморфном представлении

помощью таблиц

перехода состояний каждому переходу

соответствует

строка таблицы,

кото-

рой

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

при

этом

действие

новое состояние после перехода.

249

Методическое

программное обеспечение автоматизированных систем

...

then

cas

~АЛ\

А2

whil

unti

for

/ /

Условный CASE-

Следование

выбор выбор

Операторы

цикла

Рис. 5.4.

Примеры

описания

операторов

визуальных

языках

программирования

Близкий

по

своему характеру способ описания процессов основан

на

табли-

цах

(или деревьях) решений. Каждый столбец таблицы решений соответствует

определенному сочетанию условий,

при

выполнении которых осуществляются

действия, указанные

нижерасположенных клетках столбца.

Таблицы

решений

удобны

при

описании процессов

многократными

ветв-

лениями.

этих случаях помогают также визуальные языки программирова-

ния,

которых

для

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

подобные приведенным

на

рис. 5.4.

псевдокодах алгоритмы записываются

помощью

как

средств некоторо-

го

языка программирования (преимущественно

для

управляющих операторов),

так

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

ков).

Используются конструкции (операторы) следования, условные, цикла.

Служебные слова

из

базового языка программирования

или из DFD

записыва-

ются заглавными буквами, фразы естественного языка

строчными.

Языки четвертого поколения предназначены

для

описания программ

как

совокупностей заранее разработанных программных модулей. Поэтому одна

команда

языка

четвертого

поколения может соответствовать значительному

фрагменту программы

на

языке 3GL. Примерами языков

4GL

могут

служить

Informix-4GL,

JAM, NewEra, XAL.

Мини-спецификации

процессов

могут

быть выражены

помощью псевдо-

кодов

(языков спецификаций), визуальных языков проектирования

или

языков

программирования.

Объектный подход представлен компонентно-ориентированными техноло-

гиями

разработки

ПО. При

объектном подходе

ПО

формируется

из

компонен-

тов, объединяющих

себе алгоритмы

данные

взаимодействующих путем

обмена сообщениями.

Для

поддержки объектного подхода разработан рассмат-

риваемый далее стандартный

язык

моделирования приложений

UML.

Методики

IDEFO

IDEF3

Взаимосвязанная

совокупность методик IDEF

для

концептуального проек-

тирования разработана

по

программе Integrated Computer Aided Manufacturing

США.

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

информа-

250

5.5.

Инструментальные

средства

концептуального

проектирования

ционного

поведенческого моделирования

проектирования,

в ее

состав

настоящее время входит

ряд

IDEF-методик,

часть

из

которых стандартизиро-

вана.

Методики

IDEF

задают единообразный подход

моделированию приложе-

ний,

но не

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

про-

цессах информационного обмена между разными компьютерными системами

приложениями. Необходимость решения этих проблем

интегрированных

АС

привела

появлению ряда унифицированных форматов представления данных

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

форматы

IGES,

DXF (в

машиностроительных приложениях),

EDIF

(в

электро-

нике)

некоторые

другие.

Ограниченные возможности этих форматов обусло-

вили продолжение работ

направлении создания более совершенных методик

представляющих

их

стандартов.

На эту

роль

настоящее время претендует

совокупность стандартов STEP.

Как

отмечено выше,

наиболее

известной методикой функционального

мо-

делирования сложных систем является методика

SADT

(Structured

Analysis

and

Design

Technique), положенная

основу

стандарта

IDEFO.

IDEFO

- это

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

SADT

методика, рекомендуемая

для

начальных стадий проектирования слож-

ных

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

людей, оборудование,

ПО.

Начиная

момента создания первой версии мето-

дика

успешно применялась

для

проектирования телефонных

сетей,

систем

управления

воздушными перевозками, производственных предприятий

и др.

Разработку SADT-модели начинают

формулировки вопросов,

на

которые

модель должна давать ответы,

т. е.

формулируют цель моделирования. Далее

строят иерархическую совокупность диаграмм

лаконичным описанием фун-

кций.

Недостатки SADT-моделей

слабая

формализованность

для

автоматичес-

кого

выполнения проектных процедур

на их

основе. Однако наличие графичес-

кого

языка

диаграмм, удобного

для

восприятия человеком, обусловливает

по-

лезность

применимость методики SADT.

Описание объектов

процессов

SADT

(IDEFO)

выполняется

виде сово-

купности

взаимосвязанных блоков

(рис.

5.5).

Блоки

выражают функции

(работы),

по-

этому

их

названиями обычно являются

та-

Управление

(условия выполнения)

голы

или

отглагольные существительные.

Типичные примеры функций: планировать,

разработать, классифицировать, измерить,

Вход

Выход

изготовить, отредактировать, рассчитать,

I I

продать (или планирование, разработка,

классификация,

измерение,

изготовление,

(

ср

едс™™олнения)

редактирование, расчет, продажа). Число

блоков

на

одном уровне иерархии

- не бо-

Рис

5.5.

Блок

ICOM

IDEFO-

лее 6,

иначе восприятие диаграмм будет

диаграммах

251

Методическое

программное обеспечение автоматизированных систем

затруднено.

Число уровней иерархии

не

ограничено,

но

обычно

их не

более

Блоки

нумеруются (номер записывается

правом нижнем углу). Дуги (стрел-

ки)

отображают множества объектов (данных),

их

имена

—

существительные.

Управление

определяет условия выполнения. Примеры управления: требова-

ния,

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

ства,

например: компьютер, оснастка, заказчик, фирма. Входы

выходы могут

быть

любыми

объектами.

Блоки

на

рис.

5.5 в

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

ICOM(Input

—

Control

—

Output

—

Mechanism).

Рассмотрим пример функциональной модели

для

процесса создания САПР

на

предприятии,

на

котором ранее автоматизация проектирования была разви-

та

слабо.

Диаграмма верхнего (нулевого) уровня

АО

включает единственный блок

ICOM

«Разработать САПР».

качестве исполнителей фигурируют специали-

зированная

организация, занимающаяся проектированием автоматизированных

систем

называемая консалтинговой фирмой,

также представители органи-

зации-заказчика,

объединенные

создаваемый

на

предприятии отдел

САПР.

Диаграмма первого уровня, показанная

на

рис. 5.6,

а,

включает блоки

А1 —

обследования

предприятия,

А2 —

проектирования

САПР,

A3 -

реализации САПР

А4 —

испытаний системы. Диаграммы следующего второго уровня, раскры-

вающие первые блоки

Al,

A2 и A3,

представлены

на

рис.

5.6,б,виг

соответ-

ственно

(на

этих рисунках

не

отмечены данные, соответствующие внутренним

стрелкам диаграмм,

также стрелки условия

«финансы»).

При

обследовании

предприятия

специалисты консалтинговой фирмы вместе

работниками отде-

ла

САПР изучают структуру предприятия, типичные маршруты проектирова-

ния,

информационные потоки

и на

этой базе разрабатывают модель

«As

Is».

Далее создается новая модель

«То Be» с

учетом

не

только требований авто-

матизации

проектирования,

но и

будущих информационных потребностей про-

цессов

управления

делопроизводства. Модель

«То Be»

составляет основу

технического предложения

на

создание САПР.

При

проектировании САПР выбирают аппаратно-программную платформу,

базовое

ПО

проектирующих

обслуживающих подсистем, разрабатывают

структуру корпоративной сети, определяют типы сетевого оборудования, сер-

веров

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

программных компонентов.

Реализация

проекта САПР включает подготовку помещений, монтаж

ка-

бельной

сети,

обучение будущих пользователей САПР, закупку

инсталляцию

ТО

и ПО.

Разработка SADT-моделей состоит

из

ряда этапов.

Сбор информации. Источниками информации

могут

быть документы,

наблюдение, анкетирование

и т. п.

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

экспертов

анкетирования.

252