Система Автоматизированного Проектирования

К общесистемному ПО относят операционные системы (ОС) используемых ЭВМ и вычислительных систем и сетевое ПО типовых телекоммуникационных услуг.

Различают ОС со встроенными  сетевыми функциями и оболочки над  локальными ОС. В соответствии с  другим признаком классификации сетевые ОС подразделяют на одноранговые и функционально несимметричные (ОС для систем клиент-сервер).

Основные функции сетевой  ОС:

— управление каталогами и файлами;

— управление ресурсами;

— коммуникационные функции;

— защита от несанкционированного доступа;

— обеспечение отказоустойчивости;

— управление сетью.

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

Управление ресурсами включает в себя функции запроса и предоставления ресурсов.

Коммуникационные функции обеспечивают адресацию, буферизацию, маршрутизацию сообщений.

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

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

Чем сложнее сеть, тем острее встают вопросы управления сетью. Основные функции управления сетью реализуются в ПО, поддерживающем протоколы управления такие, как ICMP и SNMP в стеке TCP/IP или протокол CMIP (Common Management Information Protocol) в семиуровневой модели ISO. Как рассмотрено выше, это ПО представлено менеджерами и агентами. Менеджер — прикладная программа, выдающая сетевые команды. Агенты доводят эти команды до исполнительных устройств и сигнализируют о событиях в состоянии устройств, они следят за трафиком и фиксируют аномалии, помогают восстановлению информации после сбоев, борются с вирусами и т.п.

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

 

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

 

Рис. 3.1. Удаленный узел и дистанционное управление

 

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

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

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

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

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

Находят применение технологии распределенных вычислений RPC (Remote Procedure Call), ORB (Object Request Broker), DCE (Distributed Computing Environment), мониторы транзакций ТРМ (Тransaction Рrocessing Мonitors) и др.

Средства RPC входят во многие системы сетевого ПО. RPC — процедурная  блокирующая синхронная технология, предложенная фирмой Sun Microsystems. Вызов удаленных программ подобен вызову функций в языке С. При пересылках на основе транспортных протоколов TCP или UDP данные представляются в едином формате обмена. Синхронность и блокирование означают, что клиент, обратившись к серверу, для продолжения работы ждет ответа от сервера.

Для систем распределенных вычислений разработаны специальные  языки, например для RPC — язык IDL (Interface Definition Language), который позволяет пользователю оперировать различными объектами безотносительно к их расположению в сети. На этом языке можно записывать обращения к серверам приложений.

Рассмотрим типичную схему реализации RPC.

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

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

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

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

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

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

В CORBA создан протокол IIOP (Internet Inter-ORB Protocol), который обеспечивает взаимодействие между брокерами разных производителей.

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

DCE разработана консорциумом OSF (Open Software Foundation). Она не противопоставляется другим технологиям (RPC, ORB), а является средой для их использования, например, в одной из реализаций DCE пакет Encina есть монитор транзакций, а пакет Orbix ORB представляет собой технологию ORB.

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

К функциям DCE относятся  распределение вычислений по технологии RPC; распараллеливание вычислений (но программист сам проектирует параллельный процесс); защита данных; синхронизация (согласование времени); поддержка распределенной файловой системы.

Работая в DCE, пользователь дополнительно к своей прикладной программе пишет IDL-файл, в котором указывает свое имя, требуемые операции и типы данных. IDL-компилятор на основе этого файла создает три модуля: клиентский стаб (Сl), серверный стаб (Sr), головной файл (Hd). Cl содержит вызовы процедур, Sr — обращения к базе процедур, Hd устанавливает связь между стабами.

Определение нужного  сервера в DCE либо происходит автоматически  с помощью ORB, либо возлагается на программиста, как в RPC .

 

2. НАЧНАЧЕНИЕ И СОСТАВ СИСТЕМНЫХ СРЕД САПР.

 

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

САПР с системами  управления предприятием и документооборота. Для управления столь сложными интегрированными системами в их составе имеется специальное ПО — системная среда САПР или АС.

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

Термин Framework применительно к системным средам САПР был введен в 1980 г. фирмой Cadence — одним из пионеров в создании системных сред САПР. Кроме Cadence, тематикой Frameworks для САПР электронной промышленности занималось несколько ведущих в этой области фирм (Mentor Graphics, IBM, DEC, Sun Microsystems и др.), создавших международную ассоциацию CFI (CAD Framework Initiative). Широкую известность получили такие системные среды, как Falcon Framework фирмы Mentor Graphics, Design Framework-2 фирмы Cadence и JCF (Jessy-Common Framework) европейской программы ESPRIT.

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

В типичной структуре  ПО системных сред современных САПР можно выделить следующие подсистемы.

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

Подсистема управления проектом, называемая также подсистемой сквозного параллельного проектирования CAPE (Concurrent Art-to-Product Environment), выполняет функции слежения за состоянием проекта, координации и синхронизации, параллельно выполняемых процедур разными исполнителями. Примерами подсистем управления проектами в машиностроении могут служить Design Manager в САПР Euclid, UG/Manager в Unigraphics. Иногда в отдельную подсистему выделяют управление методологией проектирования. При этом под методологией понимают совокупность методов и средств образования маршрутом проектирования — последовательностей проектных операций и процедур, ведущих к цели проектирования.

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

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