Конструкции для расширения возможностей языка моделирования

Существует три основных типа конструкций для расширения воз­можностей языка UML: ограничения (constraints), стереотипы (ste­reotypes) и именованные значения (tagged values).

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

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

Рис. 11 Конструкции расширения возможностей языка UML

На рис. 11 представлены примеры ограничения, стереотипа и име­нованного значения. Так, ограничение для класса Show (Постановка) обеспечивает уникальность названия каждого конкретного спектак­ля в системе. На рис. 1 отображено ограничение xor (исключающее «или») для двух ассоциаций (объект может иметь только одну связь в один момент времени). Ограничения удобны для выражения ут­верждений, которые могут быть выражены в текстовой форме, но при этом не поддерживаются напрямую конструкциями языка UML. Стереотип на компоненте TicketDB показывает, что данный компонент является базой данных. Это позволяет не указывать интерфейсы, реа­лизуемые этим компонентом, так они поддерживаются всеми базами данных. Для моделирования новых элементов разработчики могут создавать новые стереотипы. Со стереотипом можно проассоциировать набор ограничений, именованных значений и правил генерации кода. Для большей наглядности стереотип можно изобразить в виде специального значка, как показано на рис. 11. Впрочем, можно все­гда использовать и текстовое обозначение.

Именованные значения, присоединенные к пакету Scheduling (Распи­сание), показывают, что ответственность за него несет некий Фрэнк Мартин и что он должен закончить свою работу к концу тысячеле­тия.

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

Тема: Паттерны проектирования.

Содержание:

1. Понятие паттерна.

2. Классификация паттернов.

3. Характеристика паттернов.

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

Под паттерна­ми проектирования понимается описание взаимодействия объектов и классов, адап­тированных для решения общей задачи проектирования в конкретном контексте.

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

Одна из классификации паттернов по двум критериям. Пер­вый - цель — отражает назначение паттерна. В связи с этим выделяются:

• порожда­ющие паттерны (создание объектов)

• структурные паттерны (композиции объек­тов и классов)

• паттерны поведения (как классы или объекты взаимодействуют между собой)

Второй критерий - уровень — говорит о том, к чему обычно применяется пат­терн: к объектам или классам.

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

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

Цель Уровень	Порождающие паттерны	Структурные паттерны	Паттерны поведения
Класс	Фабричный метод	Адаптер (класса)	Интерпретатор Шаблонный метод
Объект	Абстрактная фабрика Одиночка Прототип Строитель	Адаптер (объекта) Декоратор Заместитель Компоновщик Мост Приспособленец Фасад	Итератор Команда Наблюдатель Посетитель Посредник Состояние Стратегия Хранитель Цепочка обязанностей

Каталог содержит 23 паттерна:

Abstract Factory (абстрактная фабрика)

Назначение

Предоставляет интерфейс для создания семейств, связанных между собой, или независимых объектов, конкретные классы которых неизвестны.

Мотивация

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

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

Применимость

Используйте паттерн абстрактная фабрика, когда:

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

• входящие в семейство взаимосвязанные объекты должны использоваться вместе;

• система должна конфигурироваться одним из семейств составляющих ее объектов;

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

Структура

Участники

• AbstractFactory - абстрактная фабрика:объявляет интерфейс для операций, создающих абстрактные объекты-продукты;

• ConcreteFactory - конкрет­ная фабрика:реализует операции, создающие конкретные объекты-продукты;

• AbstractProduct - абстрактный продукт: объявляет интерфейс для типа объекта-продукта;

• ConcreteProduct - конкретный продукт:

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

-реализует интерфейс AbstractProduct;

• Client - клиент:

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

Отношения

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

• AbstractFactory передоверяет создание объектов-продуктов своему под-классу ConcreteFactory.

Результаты

+ изолирует конкретные классы

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

+ упрощает замену семейств продуктов

Приложение может изменить конфигурацию продуктов, просто подставив новую конкретную фабрику; + гарантирует сочетаемость продуктов

- фиксирует набор продуктов

Для поддержки новых продуктов необходимо расширить интерфейс фаб­рики, то есть изменить класс AbstractFactory и все его подклассы.

Пример кода:

class IUI Factory{

IMenu * create Menu ();

IScrollBar * create Scrollbar ();

}

class Motif UI Factory: public IUI Factory{

IMenu * create Menu ();

IScrollBar * create Scrollbar ();

}

class IMenu{

void draw ();

}

class IScrollbar{

void draw ();

}

Adapter (адаптер)

Назначение

• преобразует (адаптирует) интерфейс одного класса в интерфейс другого, который ожидают клиенты;

• обеспечивает совместную работу классов с несовместимыми интерфейсами.

Применимость

• при несоответствии интерфейса существующего класса потребностям;

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

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

Структура

Участники

• Target - целевой:определяет зависящий от предметной области интерфейс, которым поль­зуется Client;

• Client - клиент:вступает во взаимоотношения с объектами, удовлетворяющими интер­фейсу Target;

• Adaptee - адаптируемый:определяет существующий интерфейс, который нуждается в адаптации;

• Adapter - адаптер: адаптирует интерфейс Adaptee к интерфейсу Target.

Отношения

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

Результаты

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

Адаптер класса:

• адаптирует Adaptee к Target, перепоручая действия конкретному классу Adaptee. Поэтому данный паттерн не будет работать, если мы захотим од­новременно адаптировать класс и его подклассы;

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

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

Адаптер объектов:

• позволяет одному адаптеру Adapter работать со многим адаптируемыми объектами Adaptee, то есть с самим Adaptee и его подклассами (если та­ковые имеются). Адаптер может добавить новую функциональность сразу всем адаптируемым объектам;

• затрудняет замещение операций класса Adaptee. Для этого потребуется по­родить от Adaptee подкласс и заставить Adapter ссылаться на этот под­класс, а не на сам Adaptee.

Bridge (мост)

Назначение

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

Мотивация

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

Структура

Участники

• Abstraction - абстракция:

-определяет интерфейс абстракции;

-хранит ссылку на объект типа Implementor;

• RefinedAbstraction - уточненная абстракция:расширяет интерфейс, определенный абстракцией Abstraction;

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

• lmplementorA, B - конкретный реа­лизатор:содержит конкретную реализацию интерфейса класса Implementor.

Отношения

Объект Abstraction перенаправляет своему объекту Implementor запросы клиента.

Результаты

• отделение реализации от интерфейса. Объект может динамически изменять свою реализацию.Разделение классов Abstraction и Implementor устраняет также зави­симости от реализации, устанавливаемые на этапе компиляции. Чтобы из­менить класс реализации, вовсе не обязательно перекомпилировать класс Abstraction и его клиентов.

• повышение степени расширяемости. Можно расширять независимо иерар­хии классов Abstraction и Implementor;

• сокрытие деталей реализации от клиентов.

1 2 3 4 5 6 7 8 9

class Window{ WindowImpl*impl; draw(); resire(); create() … } class Window Impl{ draw(); } class Button:public Window{ draw();{Window::draw();} }

//базовый //наследуемый

Назначение

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

Builder (строитель)

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

Chain of Responsibility (цепочка обязанностей)

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

Command (команда)

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

Composite (компоновщик)

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

Decorator (декоратор)

Назначение

Динамически добавляет объекту новые обязанности.

Применимость

• для динамического добавления обязанностей отдельным объектам (не классам в целом);

• для реализации обязанностей, которые могут быть сняты с объекта;

• когда расширение путем порождения подклассов невозможно.

Структура

Участники

• Component - компонент:определяет интерфейс для объектов, на которые могут быть динамичес­ки возложены дополнительные обязанности;

• ConcreteComponent - конкретный компонент:определяет объект, на который возлагаются дополнительные обязанности;

• Decorator - декоратор:хранит ссылку на объект Component и определяет интерфейс, соответ­ствующий интерфейсу Component;

• DecoratorA, B - конкрет­ные декораторы:возлагают дополнительные обязанности на компонент.

Отношения

Decorator переадресует запросы объекту Component.

Результаты

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

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

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

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

Facade (фасад)

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

Factory Method (фабричный метод)

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

Flyweight (приспособленец)

Использует разделение для эффективной поддержки большого числа мел­ких объектов.

Interpreter (интерпретатор)

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

Iterator (итератор)

Назначение

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

Структура

Участники

• Iterator - итератор:определяет интерфейс для доступа и обхода элементов;

• Concretelterator - конкретный итератор:

-реализует интерфейс класса Iterator;

-следит за текущей позицией при обходе агрегата;

• Aggregate - агрегат: определяет интерфейс для создания объекта-итератора;

• ConcreteAggregate - конкретный агрегат: реализует интерфейс создания итератора и возвращает экземпляр подходящего класса Concretelterator.

Отношения

Concretelterator отслеживает текущий объект в агрегате и может вычислить идущий за ним.

Результаты

• поддерживает различные виды обхода агрегата;

• итераторы упрощают интерфейс класса Aggregate благодаря наличию интерфейса для обхода в классе Iterator избавляет от дублирования этого интерфейса в классе Aggregate;

• одновременно для данного агрегата может быть активно несколько обходов.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

class Storage{ Iterator*createIterator(); } class Iterator{ First(); Next(); IsDone(); } Item*CurrentItem(); class List:public Storage{ Iterator*createIterator(){ return new ListIterator(this); }}; class ListIterator:public Iterator{ ListIterator(Lrst*cont) Item*pBegin; class Item{ int value; Item*pNext; } Item*ListIterator First(){ current = return current; }

//если элемент последний, к нему нельзя применить Next, то IsDone - TRUE else - FALSE

Mediator (посредник)

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

Memento (хранитель)

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

Observer (наблюдатель)

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

Prototype (прототип)

Назначение

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

Применимость

Система не зависит от того, как в ней создаются, компонуются и представляются продукты:

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

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

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

Структура

Участники

• Prototype - прототип:объявляет интерфейс для клонирования самого себя;

• ConcretePrototype - конкретный прототип:реализует операцию клонирования себя. Их количество может меняться;

• Client - клиент:создает новый объект, обращаясь к прототипу с запросом клонировать себя.

Отношения

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

Преимущества

• добавление и удаление прототипов во время выполнения

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

• специфицирование новых объектов путем изменения структуры (инстанцирование новой структуры из уже существующих крупных и мелких составляющих)

• уменьшение числа подклассов (позволяет клонировать прототип, а не создать новый объект)

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

- недостаток заключается в том, что каждый под­класс класса Prototype должен реализовывать операцию Clone, что затруднительно. Например, сложно добавить операцию Clone, когда рассматрива­емые классы уже существуют. Проблемы возникают и в случае, если во внутреннем представлении объекта есть другие объекты или наличествуют круговые ссылки.

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

1 2 3 4

Request(){ Prototype*pProto; pPrototype = getCurrentPrototype(); … = pProto -> Clone(); }

// дубликат, который используется в работе

Пример 1:

1 2

I class Node{ Clone(); }

Конструктор копирования Node(constNode&a)

Для каждого типа могут создаваться свои узлы

1 2 3 4 5 6

class VarNode; public Node{ Clone(); } Node*getCurrentTypeNode(); . . . createNode; Node*pNode = getCurrent… … = pNode->Clone();

//возвращает текущий выбранный тип узла

Пример 2:

Элементы одного типа, но с разным значением переменной type

1 2

class Node{ Clone(); int type node.type = NODE_CONST; }

Proxy (заместитель)

Подменяет другой объект для контроля доступа к нему.

Singleton (одиночка)

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

State(состояние)

Позволяет объекту варьировать свое поведение при изменении внутренне­го состояния. При этом создается впечатление, что поменялся класс объекта.

Strategy (стратегия)

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

Template Method (шаблонный метод)

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

Visitor (посетитель)

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

15

16

Тема: Язык IDL. Назначение, основные понятия.

Содержание:

ЯЗЫК IDL

Рабочее определение IDL

ЯЗЫК IDL- описывает интерфейс объекта по синтаксису схож с С++.

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

В реальности разработчики СОМ пишут определения IDL для полной функциональности своих СОМ серверов и посылают файл *.idl компилятору MIDL (midl.exe). MIDL генерирует несколько выходных файлов, которые в дальнейшем могут использоваться компоновщиками (builders) объектов СОМ, а также потребителями этих объектов. Упомянутые файлы являются ключевыми в обеспечении языковой независимости и прозрачности местонахождения.

Замечание

Может быть, вы слышали об языке описания объекта (Object Definition Language, или ODL). Этот язык является более старой версией MIDL, разработанной тайной специально для создания библиотек типов для серверов автоматизации OLE с использованием утилиты MkTyplib.exe. MIDL 2.0 не поддерживал re рации библиотеки типов, но генерировал коды заглушек и прокси-объектов д пересылки СОМ-интерфейсов через границы между машинами и процессами С современной версией MIDL 3.0 вы можете изобразить на IDL все, что могли написать на ODL (включая библиотеки типов). Так что вы спокойно можете за­быть старый синтаксис ODL и пользоваться исключительно IDL. (если, конечно вам не достались по наследству какие-нибудь определения на ODL).

Что IDL вносит в СОM?

IDL — это исключительно язык определений. Синтаксис IDL скроен по образцу С, но ОТСУТСТВУЮТ КОНСТРУКЦИИ ЦИКЛОВ (ЦИКЛЫ for, while и пр.)

и условные операторы (if/else, switch и пр.). Конечно же, на IDL невоз­можно создать исполняемой программы (типа MS Word) и невозможно реа­лизовать кокласс. А что можно сделать в IDL? Чтобы ответить на этот во­прос, вспомним некоторые наши нерешенные проблемы.

• Элементы СОМ, определенные на данном языке, привязаны к этому языку.

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

Когда вы описываете ваши СОМ-серверы с помощью IDL, то гарантируете следующее:

• GUID уникально назначаются каждому и любому элементу СОМ.

• Из определений убирается всякая неоднозначность благодаря использо­ванию атрибутов IDL.

• Обеспечивается языковая независимость, позволяющая реализовыват¹ интерфейсы и программировать коклассы на любом СОМ-совместимо' языке.

Базовые типы данных IDL

Базовый тип IDL	Биты	Эквивалент С / C++
boolean	8-битовое значение	(unsigned) char
byte	8-битовое значение	unsigned char
char	8-битовое значение	(unsigned) char
small	8-битовое short со знаком	char
wchar_t	16-битовое storage	wchar_t (e.g unsigned short)
short	16-битовое со знаком	short
long	32-битовое integer	long
void*	32-битовый указатель	void*
float	32-битовое с плавающей точкой	float
double	64-битовое с плавающей точкой (десятичное число высокой точности)	double
hyper	64-битовое чрезвычайно большое целое число	Эквивалентно типу _int64

1. целочисленные: short, int, long, long long…

2. вещественные: float,double…

3. символы: char, wchar (latin-1)

4. octer- 8-ми разрядное целое число последовательность разрядов одинакова для всех систем (аналог вJava-byter)

5. Boolean {true, false}

6. string

7. any

Производные типы данных IDL:

1. struct

2. union

3. set

4. interface

Модификаторы signed и unsigned могут использоваться с большинством основных типов IDL. Также каждый тип может быть объявлен как указа­тель. Кроме того, можно писать перечисления, объединения, массивы или структуры этих типов с помощью ключевых слов enum, union, array и struct.

В свете сказанного можно заключить, что основные типы данных IDL ведут себя очень похоже на их аналоги из С. Это обстоятельство и порождает определенную проблему, учитывая, что модель СОМ декларируется как языково-независимая.

Проблемы с основными типами IDL

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

И так будет продолжаться вплоть до момента, когда в офисе появится ваш начальник и произнесет: "Нужно разработать приложение под Web с доступом к этому COM-объекту”.

17

Тема: Объектная модель

Содержание:

4. OLE.

5. ActiveX.

6. COM.

7. DCOM.