42. Методологии и технологии автоматизированного проектирования.Создание интегрированных информационных систем с использованием технологии corba и технологии сом.

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

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

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

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

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

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

По отношению к объекту проектирования различают объектно-ориентированные (объектные) и объектно-независимые (инвариантные) подсистемы.

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

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

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

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

Технологии проектирования в САПР базируются на следующих принципах:

• использование комплексного моделирования;

• интерактивное взаимодействие с математической моделью;

• принятие проектных решений на основе математических моделей и проектных процедур, реализуемых средствами вычислительной техники;

• обеспечение единства модели проекта на всех этапах и стадиях проектирования;

• использование единой информационной базы для автоматизированных процедур синтеза и анализа проекта, а также для управления процессом проектирования;

• проведение многовариантного проектирования и комплексной оценки проекта с применением методов оптимизации;

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

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

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

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

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

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

• синтеза и анализа объектов с физически разнородными элементами, каковыми являются различные виды роботов, манипуляторов, технологических аппаратов;

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

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

Объектно –ориентированный подход основан на:

• выделении классов объектов;

• установлении характерных свойств объектов и методов их обработки;

• создании иерархии классов объектов, наследовании свойств и методов обработки объектов.

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

Применение объектно - ориентированного подхода к анализу и проектированию

Объектно – ориентированное проектирование родилось и получило широкое распространение ввиду осознания трех важнейших проблем:

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

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

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

CORBA (сокр. от англ.Common Object Request Broker Architecture — общая архитектура брокера объектных запросов) — это технологический стандарт написания распределённых приложений, продвигаемый консорциумом OMG. Задача CORBA — осуществить интеграцию изолированных систем, дать возможность программам, написанным на разных языках, работающим на разных узлах сети, взаимодействовать друг с другом так же просто, как если бы они находились в адресном пространстве одного процесса.

Общий обзор

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

CORBA использует язык описания интерфейсов (OMG IDL) для определения интерфейсов взаимодействия объектов с внешним миром. CORBA описывает правила отображения из IDL в язык, используемый разработчиком CORBA-объекта. Стандартизованы отображения для Ada, C, C++, Lisp, Smalltalk, Java, COBOL, PL/I и Python. Также существуют нестандартные отображения на языки Perl, Visual Basic, Ruby и Tcl, реализованные средствами ORB, написанных для этих языков.

Ключевые понятия технологии

Объекты по значению (ОПЗ)

Помимо удаленных объектов в CORBA 3.0 определено понятие ОПЗ. Код методов таких объектов по умолчанию выполняется локально. Если ОПЗ был получен с удаленной стороны, то необходимый код должен либо быть заранее известен обеим сторонам, либо быть динамически загружен. Чтобы это было возможно, запись, определяющая ОПЗ, содержит поле Code Base — список URL, откуда может быть загружен код. У ОПЗ могут также быть и удаленные методы. У ОПЗ могут быть поля, которые передаются вместе с самим ОПЗ. Они также могут быть ОПЗ, формируя таким образом списки, деревья или произвольные графы. ОПЗ могут иметь иерархию классов, включая множественное наследование и абстрактные классы.

Компонентная модель CORBA (CCM)

Компонентная модель CORBA (CCM) —недавнее дополнение к семейству определений CORBA. CCM была введена начиная с CORBA 3.0 и описывает стандартный каркас приложения для компонент CORBA. CCM построено под сильным влиянием Enterprise JavaBeans (EJB) и фактически является его независимым от языка расширением. CCM предоставляет абстракцию сущностей, которые могут предоставлять и получать сервисы через четко определенные именованные интерфейсы, порты.

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

Общий протокол межброкерного взаимодействия (GIOP)

GIOP - абстрактный протокол в стандарте CORBA, обеспечивающий интероперабельность брокеров. Стандарты, связанные с протоколом выпускает Object Management Group (OMG). Архитектура GIOP включает несколько конкретных протоколов:

Internet InterORB Protocol (IIOP) - Межброкерный протокол для Интернет, это протокол для организации взаимодействия между различными брокерами, опубликованный консорциумом OMG. IIOP используется GIOP в среде интернет, и обеспечивает отображение сообщений между GIOP и слоем TCP/IP.

SSL InterORB Protocol (SSLIOP) - это IIOP поверх SSL, поддерживаются шифрование и аутентификация.

HyperText InterORB Protocol (HTIOP) - это IIOP поверхHTTP.

Corba Location

CorbaLoc — это сокращение от Corba Location и является строковой ссылкой на объект CORBA и выглядит похоже на URL.

Все реализации CORBA должны поддерживать как минимум два варианта определенный OMG URL: corbaloc: и corbaname:. Их назначение в том, чтобы предоставить возможность человеку способ читать/править ссылку, посредством которой можно получить IOR.

Вотпримерcorbaloc:

corbaloc::160.45.110.41:38693/StandardNS/NameServer-POA/_root

Реализация CORBA может предоставлять поддержку форматов "http:", "ftp:" и "file:". Назначение этих форматов в том, чтобы указать способ, откуда взять строковое представление IOR.

Объект CORBA. Это абстрактный элемент, интерфейс взаимодействия с которым определяется с помощью языка определения интерфейсов IDL.

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

Каждая система на основе технологии CORBAдолжна обеспечиватьдоступность объектов, поэтому понимание этих вопросов очень важно.

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

Как видим, модель обнаружения объектов состоит из сервера, клиента, и каталога объектов.

Сервер реализует прикладные объекты.

Клиент использует прикладные объекты, реализованные сервером.

Каталог объектов отвечает за хранение ссылок на объекты, а также данных, которые с ними связаны.

Итак, объекты становятся доступными для клиентов после вы­полнениятрех шагов:

• публикация

• поиск

• использование

Т.е. механизмобнаружения объектовсистемы следующий:

Снача­ла сервер публикует определенный набор объектов в каталоге, предоставляя несколько атрибутов, полностью определяющих конкретные объекты.

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

Как только клиент получает ссылку на один или несколько объектов из каталога, он может их использовать.

Здесь важно понимать, что серверыпубликуют не сами объекты, а только ссылки на них.

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

СOM (англ.Component Object Model — компонентная модель объектов) — это технологический стандарт от компании Microsoft, предназначенный для создания программного обеспечения на основе взаимодействующих распределённых компонентов, каждый из которых может использоваться во многих программах одновременно. Технология воплощает в себе идеи полиморфизма и инкапсуляцииобъектно-ориентированного программирования. Технология COM в принципе является универсальной и платформо-независимой, но закрепилась в основном на операционных системах семейства Windows. В современных версиях Windows COM используется очень широко. На основе COM также было создано множество других стандартов: OLE Automation, ActiveX, DCOM, COM+