Общие вопросы создания САПР

КОНСПЕКТ ЛЕКЦИЙ

по дисциплине

РАЗРАБОТКА САПР

Направление подготовки: 230100 – «Информатика и вычислительная техника»

Форма обучения: очная

Тула 2013
Рассмотрено на заседании кафедры "Автоматизированные станочные системы

протокол №1 от "02" сентября 2013 г.

Зав. кафедрой ________________________ А.Н. Иноземцев

Оглавление

1. Общие вопросы создания САПР.. 4

1.1. Общие сведения о проектировании. 4

1.2. Процесс проектирования. Основные понятия и определения. 4

1.3. Стадии процесса проектирования. 5

2. Основные понятия системотехники. САПР как объект системотехники. 6

2.1. Концепция системотехники. 6

2.2. САПР как объект системотехники. 12

3. Принципы создания САПР. 13

3.1. Процесс проектирования. Основные понятия и определения. 13

3.2. Этапы проектирования САПР. 15

3.3. Виды обеспечения САПР. Системные среды САПР. 18

3.4. Особенности систем управления проектированием и проектными данными. Понятие об открытых системах 23

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

4.1. CASE технологии. 28

4.2 Методология IDEF моделирования. 29

4.3. Нотации IDEF моделирования. 31

5. Аналитические и имитационные модели.. 31

5.1. Разработка имитационных моделей сложных систем.. 31

5.1.1. Имитационное моделирование. 31

5.1.2. Функции моделей. 32

5.1.3. Классификация моделей. 33

5.1.4. Достоинства и недостатки имитационного моделирования. 34

5.1.6.Структурный синтез систем.. 38

5.1.7. Искусство моделирования. 39

5.1.8. Требования к хорошей модели. 40

5.1.9. Процесс имитации. 40

5.1.10. Проверка модели. 42

5.2. Языки имитационного моделирования. 43

5.3. Способы представления множества проектных решений. 44

6. Математическое моделирование автоматизированных систем.. 48

6.1. Системы массового обслуживания. 48

6.1.1 Основные сведения из теории массового обслуживания. 48

6.1.2. Аналитические модели СМО.. 50

6.1.3. Имитационное моделирование СМО.. 50

6.1.4. Событийный метод моделирования. 52

6.2. Сети Петри. 52

Общие вопросы создания САПР

1.1. Общие сведения о проектировании

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

Прежде всего, определимся, что такое проектирование.

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

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

Если этот процесс осуществляется человеком при взаимодействии с компьютером, то проектирование называется автоматизированным, если нет, то, соответственно, - неавтоматизированным.

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

Нас будет интересовать, в первую очередь, автоматизированное проектирование, которое и является предметом САПР.

1.2. Процесс проектирования. Основные понятия и определения

Дадим определение САПР: САПР (система автоматизированного проектирования) - это комплекс средств автоматизации проектирования, взаимосвязанных с коллективом специалистов (пользователей системы), выполняющих автоматизированное проектирование.

В последнее время все чаще пропагандируется новый подход к проектированию, который заключается в замене последовательного процесса сквозной разработки изделия с передачей результатов проектирования от одного подразделения к другому на интегрированный, параллельный процесс создания изделия на основе концепции “рабочих групп”. Эта концепция предполагает создание на предприятии многопрофильных рабочих групп в составе различных специалистов по конструированию, технологической подготовке производства, вопросам качества, маркетинга и т.д.

Различают семь стадий процесса проектирования новых изделий:

1) предпроектные исследования;

2) техническое задание;

3) эскизный проект;

4) технический проект;

5) рабочий проект;

6) изготовление, отладка, испытание;

7) ввод в действие.

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

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

1.3. Стадии процесса проектирования

Рассмотрим содержание работ на различных стадиях проектирования на примере разработки некоторой абстрактной САПР.

Прежде всего, отметим, что при создании САПР как нового изделия необходимо реализовать все стадии проектирования.

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

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

Третья стадия (эскизный проект), как и все последующие, относится уже к внутреннему проектированию.

На стадии эскизного проекта разрабатываются принципиальные решения по созданию САПР и формам проектной документации.

На стадии технического проекта разрабатываются окончательные решения по созданию САПР, которые опять согласовываются и утверждаются.

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

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

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

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

Проектирование новых изделий проходит три основных этапа:

1. Научно-исследовательские работы (НИР).

2. Опытно-конструкторские работы (ОКР).

3. Этап рабочего проектирования.

Иногда первый и второй этапы объединяют в один этап: НИОКР.

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

Этап опытно-конструкторских работ объединяет эскизный и технический проекты.

Этап рабочего проектирования объединяет стадии рабочего проекта, изготовления, отладки, испытания и ввода в действие.

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

2. Основные понятия системотехники. САПР как объект системотехники

2.1. Концепция системотехники

Системоте́хника - научное направление, охватывающее проектирование, создание, испытание и эксплуатацию сложных систем.

Основные понятия системотехники:

Система – множество элементов, находящихся в отношениях и связях между собой.

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

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

Подсистема – часть системы (подмножество элементов и их взаимосвязей), которая имеет свойства системы.

Надсистема – система, по отношению к которой рассматривая система является подсистемой.

Структура – отображение совокупности элементов системы и их взаимосвязей; понятие структуры отличается от понятия самой системы тем, что при описании структуры принимают во внимание лишь типы элементов и связей без конкретизации значений их параметров.

Параметр – величина, выражающая свойство или системы, или ее части.

В научном познании можно выделить несколько компонентов, дополняющих друг друга:

1) эмпирико-интуитивный, вероятно, наиболее древний, основанный на наблюдениях (экспериментах) и «угадывании» взаимосвязей между ними;

2) дедуктивно аксиоматический, принятый Евклидом в его «Началах»;

3) конструктивный, обобщенный Сократом, идущий от частного к общему и избегающий догматизма;

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

Процесс познания всегда направлен одновременно от частей к целому и от целого к частям.

В системотехнике на равных правах используются все компоненты, это и определяет ее научную парадигму, сближающую методологии естественных и гуманитарных наук. Классическая методология «точных» наук основана на причинно-следственных зависимостях и выражается логико-аксиоматическим отношением: «если А истинно, а из А следует Б, то Б истинно». Иначе говоря, из А следует Б, но не наоборот. В частности, понимая под А систему аксиом, а под Б множество теорем, доказанных исходя из А, мы утверждаем, что Б есть следствие, но не основание А. Эта цепочка бесконечна: на основании Б делаются выводы В и т. д., но ни одно из следствий не воспринимается как обоснование А. Фундаментом являются аксиомы (в математике), законы (в физике), эмпирические факты и предположения (в физике на предположениях основываются гипотезы, если предположения экспериментально подтверждены, гипотезы становятся теориями). Доказав Б, В и т. д., мы не узнаем ничего нового об А: процесс познания строго детерминирован и следует закону причинности. Понятия в точных науках трансформируются в переменные, множествa и классы, связь между которыми устанавливается при помощи однозначных строгих формульных зависимостей.

Аксиоматический подход к элементному составу любого объекта весьма ограничен: в новом целом могут выявиться новые свойства частей, формирующих целое. Имея дело с новым объектом или с известным, но попавшем в новую среду или ситуацию, полностью полагаться на априорное знание опасно. Типовой состав переменных, которые описывают свойства компонентов объекта, может оказаться непригодным для целого объекта, более того, в различных структурах может потребоваться различный состав переменных, а как определить их — неясно. Трудности возникают и при установлении связей между переменными, поскольку число возможных связей нарастает комбинаторно по отношению к числу переменных. Части целого описываются на различных языках (проблемно-ориентированных или семиотических), если и удается перевести эти описания на язык математики, то объединить эти описания в единую математическую структуру редко удается. Все эти трудности вытекают из игнорирования многосвязности и взаимооп-ределяемости свойств и понятий.

В системотехнике вместо классического вопроса «что происходит» на первый план выступает вопрос: «что нам нужно узнать о том, что происходит». Части и целое выступают в диалектическом единстве и взаимопределяемости. Для объекта, рассматриваемого как система, решается проблема «что из чего состоит». Декомпозиция и композиция, анализ и синтез, познание частей через целое и целое через части выступают в единстве. Главная практическая задача системотехники состоит в том, чтобы, обнаружив и описав сложность, обосновать такие дополнительные физически реализуемые связи, которые, будучи наложенными на сложную систему, сделали бы ее управляемой в требуемых пределах, сохранив при этом области самостоятельности (следовательно, слабой предсказуемости), способствующие повышению эффективности системы. Таким образом, новые связи выполняют ограничительную и охранительную функции. Из всех методологических концепций системотехническая наиболее близка к «естественному» человеческому мышлению — гибкому, неформальному, разноплановому. Системный подход объединяет естественно научный метод, основанный на эксперименте, формальном выводе и количественной оценке, с умозрительным методом, опирающимся на образное восприятие окружающего мира и качественный синтез.

В исследовании любой проблемы можно выделить несколько главных подпроблем.

1. Выделение проблемы: учесть все, что нужно, и отбросить то, что не нужно.

2. Описание: выразить на едином языке, разнородные по физической природе явления и факторы.

3. Установление критериев: определить, что значит «хорошо» и «плохо» для сравнения альтернатив.

4. Идеализация: ввести рациональную идеализацию проблемы, упростить ее до допустимого предела.

5. Декомпозиция: найти способ разделения целого на части, не теряя свойств целого.

6. Композиция: найти способ объединения частей в целое, не теряя свойств частей.

7. Решение: найти решение проблемы.

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

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

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

На рис. 1 приведена схема системного подхода. Она содержит перечисленные подпроблемы, которые решаются не поочередно, а одновременно, при непрерывном взаимодействии.

Рис. 1. Схема системного подхода

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

Моделирование в системотехнике реализует одну из основных кибернетических идей Винера о «черном ящике» — устройстве, о котором известно состояние входов и выходов, но неизвестно внутреннее строение и принцип действия. Винер предлагал следующий способ раскрытия «черного ящика»: рядом с «черным» ставится «белый» ящик, с полностью известным и изменяемым в широком диапазоне устройством. На входы обоих ящиков подается одинаковый по свойствам белый шум, а затем устройство белого ящика изменяется до тех пор, пока выходные функции совпадут. С точки зрения исследователя, ящики станут тождественными. При этом физическое содержание их может быть различным: белый ящик — не копия, а модель черного (допустим, белый ящик построен на электронных, а черный — на механических компонентах).

Оперируя сложными системами, нельзя использовать в качестве средства идентификации белый шум. Во-первых, исследуя систему, мы не можем делать с ней все, что пожелаем: систему недопустимо выводить из рабочего диапазона условий. Во-вторых, при создании новой, реально не существующей системы сами условия плохо известны. В-третьих, применительно к сложным системам трудно определить, что такое «белый шум». Поэтому вместо белого шума берется некоторый ансамбль важных для представления ситуации внешних воздействий, уточняемый в процессе моделирования. Законы, управляющие поведением таинственного ящика, зависят от ситуации.

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

Относительно новой несуществующей системы обычно известны (и то — не полностью) входы (определяемые средой) и выходы (определяемые назначением системы). Экспериментировать с такой системой невозможно — ее нет, в нашем распоряжении только «белый ящик» — модель, отражающая замысел, который и требуется совершенствовать до уровня соответствия заданному назначению. Модель позволяет проверять идеи, выдвигаемые в процессе разработки, методы и средства их реализации и оценивать предполагаемый результат. Но — не только.

Рис. 2. Схема раскрытия «черного ящика»

Модель — это самостоятельно действующая система, хотя и упрощенная. Она уступает теории в общности, зато превосходит ее в конкретности и ясности получаемых данных, целенаправленности, она точнее ориентирует мысль разработчика в том направлении, которое соответствует замыслу. При использовании нескольких моделей с различной целевой ориентацией возникает потребность в интерпретации и согласовании результатов моделирования, что создает предпосылки к объединению моделей и помогает созданию теории. В этом смысле модель является предтечей теории несуществующей системы, заменяя гипотезу и недоступный исследователю эксперимент.

Концепция системотехники состоит в представлении реальных (существующих) или воображаемых (создаваемых) сложных систем посредством упрощенных описаний, т. е. моделей, отражающих определенные, наиболее важные грани сущности сложной системы, и исследовании таких моделей. Формирование моделей осуществляется на основании тех данных, которые можно получить о сложной системе экспериментальными и интеллектуальными средствами. Теория имеет дело с идеализацией реальности, модель — с самой реальностью.

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

1. Описание подсистем избыточно: для каждой подсистемы задаются значения входных и выходных величин («входов» и «выходов»); при этом возможно взаимное пополнение данных и исключение ошибок.

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

2.2. САПР как объект системотехники

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

Целенаправленность – свойство искусственной системы, выражающее назначение системы. Это свойство необходимо для оценки эффективности вариантов системы.

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

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

2.3. Структура и классификация САПР

Система автоматизированного проектирования (САПР) определена в ГОСТ 23501.0-79 как организационно-техническая система, состоящая из комплекса средств автоматизации проектирования (КСАП), взаимодействующего с подразделениями проектной организации, и выполняющая автоматизированное проектирование (рис. 3).

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

Такого типа подсистемы называют проектирующими.

Примером подсистемы может служить, например, любая программная система на персональном компьютере, осуществляющая проектирование управляющей программы, скажем, для токарных станков с ЧПУ по заданному чертежу детали, получаемому из другой проектирующей подсистемы.

Рис. 3.Структура программного обеспечения САПР

Помимо проектирующих подсистем в САПР используются подсистемы, которые принято называться обслуживающими. Например, ясно, что если вы используете некоторую базу данных, и соответственно некоторую СУБД, то система управления базами данных сама по себе ничего не проектирует, а лишь управляет процессом хранения, накопления, модификации и поиска данных, необходимых вам для проектирования.

3. Принципы создания САПР

3.1. Процесс проектирования. Основные понятия и определения

В процессе проектирования используются следующие принципы:

а) иерархичности;

б) декомпозиции;

в) многоэтапности;

г) итерационности;

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

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

Обратите внимание! В определении принципа говорится о структуризации описаний, т.к. физически объект не существует, а является только представлением о будущем реальном объекте в коллективе проектировщиков!

Декомпозиция означает структуризацию (разбиение) представлений соответствующего уровня описания объекта на составные части с целью их раздельного проектирования с учетом согласования принимаемых проектных решений.

Многоэтапность проектирования означает, что процесс проектирования в соответствии со степенью готовности проектных решений подразделяется на стадии, этапы, проектные процедуры и операции.

В процессе проектирования выделяют стадии предпроектных исследований, технического задания, технического предложения, технического и рабочего проектов, испытаний и внедрения. Содержание отдельных стадий проектирования регламентируется ГОСТ 23501.1-79, а технического проекта - ГОСТ 23501.106-85. Этапы проектирования включают формирование всех требующихся описаний объекта, относящихся к одному или нескольким иерархическим уровням или аспектам проектирования (функциональному, конструкторскому, информационному или технологическому).

Составными частями этапа являются проектные процедуры.

Под проектной процедурой понимают формализованную совокупность действий, в результате выполнения которой получают проектное решение.

Проектное решение - промежуточное или конечное описание объекта проектирования, необходимое и достаточное для рассмотрения и определения дальнейшего направления или окончания проектирования.

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

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

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

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

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

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

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

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

3.2. Этапы проектирования САПР

В общем случае процесс проектирования может быть рассмотрен как последовательность следующих относительно самостоятельных действий:

1) Постановка проблемы и формирование общей цели проектирования.

Это творческий акт, логически вытекающий из хода и прогноза развития событий в определенной сфере деятельности. Он требует от проектировщика понимания перспективных потребностей обновления.

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

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

3) Предпроектные исследования. Собственно проектирование начинается с иерархической декомпозиции общей цели, функций и принципов построения объекта до такой степени конкретизации, когда становятся очевидными конструктивные решения элементов декомпозиции с количественными оценками критериев качества.

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

Перечисленные работы выполняются в рамках стадии предпроектных исследований. Иначе этот этап называют стадией научно-исследовательских работ (НИР).

4) Разработка технических заданий (ТЗ) на проектирование объектов и составляющих его частей. Формулируются назначение и функции, определяются планируемые эффекты и технико-экономические показатели, а также технические требования.

Это стадия технического задания. Результатом ее выполнения является техническое задание (ТЗ) на проектирование.

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

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

6) Эскизное проектирование объектов. На этой стадии проектирования осуществляется основная работа, окончательное теоретическое и эксплуатационное обоснование и описание устройства и работы объекта проектирования с высокой степенью достоверности прогноза его эксплуатационных качеств.

7) Разработка технического проекта (ТП). Здесь идеи эскизного проекта доводятся до уровня конструкторских документов, содержащих технические решения.

На этапах 6 и 7 разрабатываются ММ оригинальных элементов, осуществляется оптимизация принимаемых решений, для чего привлекается соответствующий математический аппарат. Этап характеризуется высокой степенью формализации.

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

9) Коррекция проектируемых решений и документации по результатам испытаний опытных образцов. Чаще всего это требует возврата к этапам 6-7 проектирования, реже - к 3-4. Кроме того, отметим, что на любом этапе проектирования может быть возврат к предыдущей стадии по принципу обратной связи, в этом случае производится корректировка ранее принятых решений.

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

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

Для каждой степени детализации описания объекта (иначе говоря, для каждого уровня иерархической структуры проектируемого объекта: объект (0-уровень) —> обеспечивающие подсистемы (1 уровень) —> узлы (2 уровень) —>.......—> элементы (последний к-ый уровень)) выполняется следующая последовательность проектных операций:

1) формализация целей проектной задачи,

2) анализ исходных данных,

3) выработка предварительных предложений о средствах достижения целей (декомпозиция объекта проектирования на составляющие части или синтез структуры),

4) моделирование выбранных классов или типов объектов проектирования в виде функциональных соотношений или других математических моделей, о которых речь пойдет далее; ограничений, и функционалов качества.

5) выработка вариантов проектных решений на основе анализа моделей,

6) испытание и структурное согласование предварительных проектных решений,

7) принятие окончательных проектных решений,

8) документирование результатов проектирования как законченного фрагмента проекта.

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

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

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

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

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

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

3.3. Виды обеспечения САПР. Системные среды САПР

Средства автоматизации проектирования структурируются по видам обеспечения: математическое обеспечение, программное обеспечение, техническое обеспечение, информационное обеспечение, организационное обеспечение, методическое обеспечение.

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

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

БД - сами данные, находящиеся на машинных носителях информации, т.е. в запоминающих устройствах ЭВМ, и структурированные в соответствии с принятыми в БД правилами. СУБД - совокупность программных средств, обеспечивающих функционирование банка данных. С помощью СУБД производится запись данных в банк, их выборка по запросам пользователей и прикладных программ, обеспечивается защита данных от искажений и от несанкционированного доступа и т.п.

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

Методическое обеспечение составляют документы, регламентирующие состав, правила отбора и эксплуатации средств автоматизированного проектирования. Допускается и более широкая трактовка понятия методического обеспечения, при котором под ним понимается совокупность математического, лингвистического обеспечения и названных документов, реализующих правила использования средств проектирования.

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

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

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

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

В общесистемном программном обеспечение выделяют, в свою очередь, такой компонент, как базовое программное обеспечение, т.е. такое, которое не является объектом разработки при создании программного обеспечения, например, какая-либо СУБД.

Информационное обеспечение представляет собой совокупность данных, размещенных на различных носителях информации, которые используются для проектирования. Это могут быть различные справочники, таблицы, промежуточные проектные решения, параметры проектируемого изделия и т.п., в общем все, что угодно. Иногда совокупность такого рода данных называют еще информационным фондом. Формы организации информационного обеспечения в компьютере могут быть различны, например: файлы или библиотеки. Библиотечная форма организации данных широко применяется в отечественных ЭВМ типа ЕС или СМ. Наиболее естественным и распространенным способом ведения информационного фонда в настоящее время является формирование баз данных, доступ к которым осуществляется различными системами управления базами данных.

Остановимся более подробно на проблемах выбора технических средств САПР.

Как мы уже отмечали ранее, к техническим средствам САПР относятся не только компьютеры, но и различные технические устройства, приборы, периферийные средства, которые необходимы для обеспечения процесса проектирования. К периферийным техническим средствам относятся, в частности, графопостроители и перфораторы (устройства вывода информации на перфоленту). Причем, если для функционирования наиболее распространенных графопостроителей, как правило, в базовом программном обеспечении САПР имеются необходимые программные средства (драйверы), то для стыковки, скажем, IBM-совместимых персональных компьютеров и широко распространенных на предприятиях перфораторов типа ПЛ150М необходимы уже дополнительные технические устройства (адаптеры).

Остановимся несколько подробнее на компьютерах, применяемых в САПР.

Очевидно, что подавляющая часть компьютеров, используемых в настоящее время в нашей стране для автоматизации проектирования(впрочем, и не только для этих целей) представляют собой IBM-совместимые персональные компьютеры. Надо отметить, что термин “IBM-совместимые” сейчас используется реже, больше говорят о “ платформа х”, аппаратной или программной. Для персональных компьютеров аппаратная платформа определяется типом процессора (часто говорят: “интелловская“ платформа), а программная - типом операционной системы (MS DOS или MS WINDOWS). Впрочем, терминология здесь очень не устоявшаяся. И не всегда люди, использующие один термин, имеют в виду одно и то же. Характерным примером является термин “ рабочая станция ”. Если вы говорите со специалистом по сетевым технологиям, то под рабочей станцией он обычно понимает персональный компьютер, выполняющий функции “клиента” в технологии “клиент-сервер”. Вместе с тем, этот термин уже довольно давно используется для обозначения вполне определенного класса компьютеров, выпускаемых,как правило, на основе так называемых RISC-процессоров рядом известных западных производителей. Именно этот класс компьютеров в отличие от персональных чаще всего применяется для решения задач автоматизации проектирования на крупных и средних предприятиях большинства развитых стран Запада. Рабочие станции, в частности, производят такие знаменитые компьютерные фирмы, как HEWLETT PACKARD(HP), IBM, SILICON GRAPHICS(SGI), SUN Microsystem, DIGITAL(DEC) и ряд других. Как правило, рабочие станции работают на программной платформе UNIX, хотя большинство фирм-производителей предлагают и собственные специфические операционные системы. Нужно отметить, что версии OC UNIX для разных типов рабочих станций также имеют свою специфику.

Можно выделить две основные особенности рабочих станций как типа компьютеров:

- высокая производительность (наряду с другими техническими характеристиками) и использование RISC-процессоров;

- повышенные возможности для решения задач машинной графики.

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

В заключении разговора о компьютерах приведу несколько наиболее покупаемых в России модификаций рабочих станций:

- Sun SPARC Solaris, Sun SPARC SunOS;

- Alpha (Digital);

- IRIX (SGI);

- HP-UX;

- IBM AIX/600.

О лингвистическом обеспечении САПР. Основу лингвистического обеспечения САПР составляют, так называемые, проблемно-ориентированные языки, предназначенные для описания процедур автоматизированного проектирования. Собственно говоря, это и не языки вовсе, а комплексы программных средств, в качестве входных данных использующие языковые конструкции. В качестве “классического” примера можно привести язык СТЕП-Ш, разработанный преподавателем кафедры “Прикладная геометрия и автоматизация проектирования” УГТУ-УПИ Николаем Евгеньевичем Возмищевым под научным руководством проф. Р.А. Вайсбурда. Это ориентированный на конечного пользователя-непрограммиста технологический язык для описания информации о процессе и условиях проектирования в горячештамповочном производстве, а также методах решения проектных задач.

Разумеется, что в состав лингвистического обеспечения САПР входят и универсальные алгоритмические языки высокого уровня и различного типа “макроязыки”, расширяющие языковые средства больших программных систем и т.д.

Как уже отмечалось выше, стандарты по САПР выделяют еще 2 типа обеспечения САПР: методическое и организационное. Выделение это, на наш взгляд, достаточно искусственное, но “стандарт есть стандарт”. Под методическим обеспечением понимается набор документов, регламентирующих эксплуатацию САПР. Причем документы, касающиеся разработки САПР, сюда не входят. Т.е. методическое обеспечение - это, в общем смысле, просто набор инструктивных положений, касающихся эксплуатации САПР.

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

3.4. Особенности систем управления проектированием и проектными данными. Понятие об открытых системах

К проектированию АС непосредственное отношение имеют два направления деятельности: 1) собственно проектирование АС конкретных предприятий (отраслей) на базе готовых программных и аппаратных компонентов с помощью специальных инструментальных средств разработки; 2) проектирование упомянутых компонентов АС и инструментальных средств, ориентированных на многократное применение при разработке многих конкретных автоматизированных систем.

Сущность первого направления можно охарактеризовать словами “ Системная интеграция ” (другое близкое понятие имеет название — консалтинг). Разработчик АС должен быть специалистом в области системотехники, хорошо знать соответствующие международные стандарты, состояние и тенденции развития информационных технологий и программных продуктов, владеть инструментальными средствами разработки приложений (CASE-cредствами) и быть готовым к восприятию и анализу автоматизируемых процессов в сотрудничестве с специалистами-прикладниками.

Существует ряд фирм, специализирующихся на разработке проектов АС (например, Price Waterhouse, Jet Info, Consistent Software, Interface и др.).

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

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

В России действует государственный стандарт на стадии создания автоматизированных систем ГОСТ 34.601-90. Существует и международный стандарт на стадии жизненного цикла программной продукции (ISO 12207:1995). Как собственно АС, так и компоненты АС являются сложными системами и при их проектировании можно использовать один из стилей проектирования:

— нисходящее (Top-of-Design); четкая реализация нисходящего проектирования приводит к спиральной модели разработки ПО, на каждом витке спирали блоки предыдущего уровня детализируются, используются обратные связи (альтернативой является так называемая каскадная модель, относящаяся к поочередной реализации частей системы);

— восходящее (Bottom-of-Design);

— эволюционное (Middle-of-Design).

Чаще всего используется нисходящий стиль блочно-иерархического проектирования.

Рассмотрим этапы нисходящего проектирования АС.

Верхний уровень проектирования АС часто называют концептуальным проектированием. Концептуальное проектирование выполняют в процессе предпроектных исследований, формулировки ТЗ, разработки эскизного проекта и прототипирования (согласно ГОСТ 34.601-90 эти стадии называют формированием требований к АС, разработкой концепции АС и эскизным проектом).

Предпроектные исследования проводят путем анализа (обследования) деятельности предприятия (компании, учреждения, офиса), на котором создается или модернизируется АС. При этом нужно получить ответы на вопросы: что не устраивает в существующей технологии? Что можно улучшить? Кому это нужно и, следовательно, каков будет эффект? Перед обследованием формируются и в процессе его проведения уточняются цели обследования — определение возможностей и ресурсов для повышения эффективности функционирования предприятия на основе автоматизации процессов управления, проектирования, документооборота и т.п. Содержание обследования — выявление структуры предприятия, выполняемых функций, информационных потоков, имеющихся опыта и средств автоматизации. Обследование проводят системные аналитики (системные интеграторы) совместно с представителями организации-заказчика.

На основе анализа результатов обследования строят модель, отражающую деятельность предприятия на данный момент (до реорганизации). Такую модель называют “As Is”. Далее разрабатывают исходную концепцию АС. Эта концепция включает в себя предложения по изменению структуры предприятия, взаимодействию подразделений, информационным потокам, что выражается в модели “To Be” (как должно быть).

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

Эскизный проект (техническое предложение) представляют в виде проектной документации, описывающей архитектуру системы, структуру ее подсистем, состав модулей. Здесь же содержатся предложения по выбору базовых программно-аппаратных средств, которые должны учитывать прогноз развития предприятия.

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

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

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

При концептуальном проектировании применяют ряд спецификаций, среди которых центральное место занимают моделипреобразования, хранения и передачи информации. Модели, полученные в процессе обследования предприятия, являются моделями его функционирования. В процессе разработки АС модели, как правило, претерпевают существенные изменения (переход от “As Is” к “To Be”) и в окончательном виде модель “To Be” рассматривают в качестве модели проектируемой АС.

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

Содержанием последующих этапов нисходящего проектирования (согласно ГОСТ 34.601-90 это стадии разработки технического проекта, рабочей документации, ввода в действие) является уточнение перечней приобретаемого оборудования и готовых программных продуктов, построение системной среды, детальное инфологическое проектирование БД и их первоначального наполнения, разработка собственного оригинального ПО, которая, в свою очередь, делится на ряд этапов нисходящего проектирования. Эти работы составляют содержание рабочего проектирования. После этого следуют закупка и инсталляция программно-аппаратных средств, внедрение и опытная эксплуатация системы.

Особое место в ряду проектных задач занимает разработка проекта корпоративной вычислительной сети, поскольку техническое обеспечение АС имеет сетевую структуру.

Если территориально АС располагается в одном здании или в нескольких близко расположенных зданиях, то корпоративная сеть может быть выполнена в виде совокупности нескольких локальных подсетей типа Ethernet или Token Ring, связанных опорной локальной сетью типа FDDI или высокоскоростной Ethernet. Кроме выбора типов подсетей, связных протоколов и коммутационного оборудования приходится решать задачи распределения узлов по подсетям, выделения серверов, выбора сетевого ПО, определения способа управления данными в выбранной схеме распределенных вычислений и т.п.

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

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

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

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

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

Аспекты открытости выражаются в стандартизации:

— API (Application Program Interface) — интерфейсов прикладных программ с операционным окружением, в том числе системных вызовов и утилит ОС, т.е. связей с ОС;

— межпрограммного интерфейса, включая языки программирования;

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

— пользовательского интерфейса, в том числе средств графического взаимодействия пользователя с ЭВМ;

— средств защиты информации.

Стандарты, обеспечивающие открытость ПО, в настоящее время разрабатываются такими организациями, как ISO (International Standard Organization), IEEE (Institute of Electrical and Electronics Engineers), EIA (Electronics Industries Association) и рядом других.

Выше уже были отмечены телекоммуникационные и сетевые стандарты семиуровневой модели взаимосвязи открытых систем (ЭМВОС).

Стандарты POSIX (Portable Operating System Interface) предназначены для API и составляют группу стандартов IEEE 1003. В этих стандартах содержатся перечень и правила вызова интерфейсных функций, определяются способы взаимодействия прикладных программ с ядром ОС на языке С (что означает преимущественную ориентацию на ОС Unix), даны расширения для взаимодействия с программами на других языках, способы тестирования интерфейсов на соответствие стандартам POSIX, правила административного управления программами и данными и т.п.

Ряд стандартов ISO посвящен языкам программирования. Имеются стандарты на языки C (ISO 9899), Фортран (ISO 1539), Паскаль (ISO 7185) и др.

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

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