ActiveInsight - Создание компонентов для повторного использования.

Только Delphi 3 позволяет разработчикам легко создавать высокопроизводительные ActiveX-компоненты, не требующие отдельных runtime-файлов. С Delphi 3 пользователи могут путем визуального проектирования создавать формы и управляющие элементы ActiveX из шаблона, или превратить любой существующий компонент библиотеки визуальных компонентов Delphi или Borland C++Builder в ActiveX. Корпорации теперь могут использовать Delphi 3 для быстрого создания ActiveX, которые можно использовать в всех средствах разработки приложений, включая C++, Java, Visual Basic, Microsoft Office, PowerBuilder и Borland IntraBuilder.

Администрирование MQSeries

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

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

Рис. 3. Администрирование MQSeries

Другая возможность предлагает использование API-интерфейса PCF (Programmable Command Format) для вызова административных функций непосредственно из прикладных программ. Для удаленного администрирования менеджеров очередей MQSeries использует специальные командные очереди приема/передачи административных команд-сообщений и специальные мониторы (command servers) для их исполнения. Графические средства администрирования входят в MQSeries как компоненты MQSeries Explorer и MQSeries Services Snapin, а также предлагаются в ряде отдельных продуктов и модулей из общих пакетов управления системами: TME 10 Module for MQSeries (Tivoli), Command Center for MQSeries (Candle Corp.), Command MQ (Bool&Babbage), Patrol KnowledgeModule for MQSeries (BMC).

Адресация и маршрутизация сообщений

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

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

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

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

У менеджера очередей имеется специальная очередь DLQ (Dead-Letter Queue) - место для хранения недоставленных сообщений. Чаще всего сообщения появляются в DLQ, когда очереди, указанной в заголовке сообщения, не существует или когда очередь назначения оказывается полной. Сообщения из очереди DLQ позволяют разгрузить транспортные очереди и каналы от ошибочных сообщений, при этом в тело сообщения вставляется специальный информационный подзаголовок, позволяющий, если сообщение не доставлено, анализировать причины случившегося. MQSeries обладает механизмом задания правил для автоматической обработки недоставленных сообщений.

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

На первый окрик: "Кто идет?" - он стал шутить,
На выстрел в воздух закричал: "Кончай дурить!"
Я чуть замешкался и, не вступая в спор,
Чинарик выплюнул - и выстрелил в упор.
В. Высоцкий

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

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

1. Если ты левофланговый и получил приказ "Шеренга, пли!", то запомни число 1 - свой порядковый номер - и ровно через секунду сообщи его соседу справа.

2. Если ты неправофланговый и сосед слева сообщил тебе число V, запомни число V+1 - свой порядковый номер - и ровно через секунду сообщи его соседу справа.

3. Если ты правофланговый и сосед слева сообщил тебе число n-1, то ровно через секунду ответь ему: "Готов!" и приступай к обратному счету в уме: n, n-1, n-2, ..., отсчитывая по одному числу в секунду.

4. Если ты не правофланговый и сосед справа доложил тебе: "Готов!", то ровно через секунду приступай к обратному счету в уме: V, V-1, V-2, ..., где V - твой порядковый номер, отсчитывая по одному числу в секунду. При этом, если V>1, т.е. если ты не левофланговый, то ровно через секунду после получения сообщения от соседа справа доложи: "Готов!" соседу слева.

5. Досчитав до нуля, стреляй!

Автоматная модель поведения стрелка

Аналогичные указания даются, когда приказ получен правофланговым.

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

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

// Предикаты

x1 Состояние соседа слева "Огонь!"?

// Команда "Огонь";

x2 Состояние соседа справа "Готов!"?

x3 Свой номер не равен нулю?

// Действия

y1 Установить свой номер: взять номер

соседа слева

и увеличить на 1

y2 Уменьшить свой номер на 1

y3 Произвести выстрел

Кстати, эти строки в дальнейшем можно превратить в комментарии к операторам "автоматной программы".

Анализ предметной области – концептуальная модель

Прежде чем приступить к реализации какого либо проекта, руководитель проекта должен хорошо представлять предметную область поставленной перед ним задачи. Настоятельно рекомендую начать с построения диаграмм вариантов использования системы (use case diagram). Пример такой диаграммы изображен на рис.1. Данная диаграмма была позаимствована мной из некоммерческого проекта “Агент Интеллектуальных Услуг”, проект в котором я принимал участие.

Рис.1.

На рис.1 изображены укрупненные прецеденты, которые можно будет в дальнейшем детализировать. Человечками обозначаются актеры, которые взаимодействуют с разрабатываемой системой и выполняют определенные роли. Овалы показывают виды этих взаимодействий или прецедентов использования системы. Актерами могут быть как пользователи, так и части самой системы, которые функционируют самостоятельно. Более подробную нотацию данного вида диаграммы можно найти в любой литературе по UML.

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

Рис. 2

Данную диаграмму я позаимствовал из того же проекта. Понятия из предметной области необходимо объединить в классы и показать между ними связи. Связи должны иметь названия и кратности. Например, потребитель может послать ноль или много сообщений, но каждое сообщение должно иметь одного потребителя, это видно из связи между классами Consumer и Message. Более подробную нотацию данного вида диаграммы также можно найти в литературе по UML.

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

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

Application

Средства разработки приложений

А.М. Вендров , , # 4/2004

Гусев А.В., Дмитриев А.Г., Тихонов С.И., Вычислительный центр ОАО "Кондопога", КНМЦ СЗО РАМН

Сергей Кривошеев,

Михаил Продан,

Алексей Махоткин,

Вячеслав Яковенко,

(группа компаний АйТи)

(группа компаний АйТи)

21.08.2002

Дарвин Саной
15.12.2002

Reginald Stadlbauer & Monica Vittring (Перевод: Andi Peredri)

Matthias Kalle Dalheimer (Перевод: Andi Peredri)

Алексей Доля,

Андрей Колесов,

Фрэнк Хэйес, #24/99

Наталья Дубова, #03/99

Сервер компании

Николай Смирнов, IBM EE/A

Наталия Елманова, Компьютер-Пресс, 1998, N 1.

Аргументы в пользу использования DLL

Итак, прежде чем перейти к обсуждению структуры динамических библиотек, необходимо поговорить о тех преимуществах, которые предоставляет их использование разработчику. Во-первых, это повторное использование кода. Думаю, нет необходимости пояснять удобство использования один раз разработанных процедур и функций при создании нескольких приложений? Кроме того, в дальнейшем вы сможете продать некоторые из своих библиотек, не раскрывая исходных кодов. А чем тогда это лучше компонентов, спросите вы? А тем, что функции, хранящиеся в библиотеке, могут быть вызваны на выполнение из приложений, разработанных не на Object Pascal, а, например, с использованием C++Builder, Visual Basic, Visual C++ и т.д. Такой подход накладывает некоторые ограничения на принцип разработки библиотеки, но это возможно. Звучит заманчиво? Мне кажется, даже очень. Но это еще не все.

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

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

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

Архитектор баз данных

Моделирование баз данных осуществляется следующим образом. Создаются классы типа "Persistent class". Выполняется их разработка, определяются их атрибуты. Затем на основе указанных классов в полуавтоматическом режиме создается физическая база данных. При этом класс типа "Persistent class" становится таблицей, а его атрибуты - полями этой таблицы. Таким образом, физическая модель базы данных однозначно соответствует логической модели классов, что опять же позволяет ускорить процесс моделирования базы данных и упростить взаимодействие с ней в разрабатываемой информационной системе.

Рис. 9.

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

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

СУБД, поддерживаемые Rapid Developer:

IBM DB2 UDB v6.0, 7.2, 8 IBM DB2 eServer zSeries (S/390) v6, 7, 8 IBM DB2 iSeries V4R5, V5R1 (AS/400) IBM IMS IBM VSAM Microsoft SQL Server v7.x, 2000 Oracle v7.3, 8/8i, 9i Sybase 11 более 60 других источников данных (через iWay Adapters).

Архитектор классов

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

Классы, создаваемые в Rapid Developer имеют один из следующих 4 типов

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

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

Рис. 6.

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

Как и в Rose, мышью на диаграмме можно изменять размеры классов и перемещать их в пределах этой диаграммы. Пункт контекстного меню "Class Properties", вызванного над любым классом, позволяет определить его дополнительные свойства (атрибуты, методы и др.). Аналогичный пункт контекстного меню "Display Properties" позволяет изменить атрибуты отображения класса на диаграмме (следует ли автоматически подгонять размеры класса, показывать ли его атрибуты, методы и т.д.). Пункт главного меню "Draw/ Auto Arrange" позволяет быстро и оптимально расположить классы на диаграмме без необходимости долго таскать их вручную по всему экрану.

Архитектор логики

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

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

Рис. 11.

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

Здесь же можно установить или отредактировать бизнес-правила для атрибутов классов. Разрабатываемая система может быть интегрирована в структуру существующих информационных систем с помощью проектирования набора сообщений для обмена информацией. Rapid Developer позволяет выполнить проектирование сообщений (вкладка "Messages"). Можно определить сообщения, как в формате XML, так и в пользовательских форматах. Поддерживается большое разнообразие существующих стандартов сообщений:

IBM WebSphere MQ (MQ Series) JMS providers TIBCO MSMQ сообщения XML со своими словарями DTD простые текстовые сообщения и др.

Кроме того, Архитектор логики позволяет выполнить проектирование отдельных компонентов (вкладка "Components") и использовать их при разработке в текущем или будущих проектах.

Rapid Developer поддерживает возможности выявления и быстрой интеграции с существующими сервисами Web. При этом компоненты, созданные с помощью Rapid Developer, легко могут быть также представлены в виде Web-сервисов. А учитывая, что при использовании Web-сервисов разработчик изолирован от необходимости разбираться в тонкостях протоколов SOAP и API-интерфейсах, то это значительно ускоряет процесс разработки коммерческих информационных систем.

Архитектор приложения

После создания нового проекта в Rapid Developer автоматически запускается Архитектор приложения.

Рис. 4.

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

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

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

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

Rapid Developer позволяет проектировать и автоматически развертывать информационные системы:

Apache Tomcat v4.x BEA WebLogic 5.1, 6.1, 7.0 IBM WebSphere 3.5, 4.0, 5.0 Oracle 9iAS R1, R2 Generic J2EE Microsoft MTS

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

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

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

Распределение артефактов выполняется их простым перетаскиванием с помощью мыши (Drag & Drop механизм).

Рис. 10.

Архитектор сайта

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

Рис. 7. Архитектор сайта.

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

Архитектор Web-страниц

После проектирования структуры сайта с помощью упомянутого в предыдущем разделе Архитектора осуществляется запуск Архитектора Web-страниц. Указанный Архитектор позволяет определить внешний вид каждой Web-страницы разрабатываемой информационной системы, определить отображаемые на ней элементы графического интерфейса пользователя. Все проектируется опять же визуально в соответствии с известным метод WYSIWYG (What You See Is What You Get).

Рис. 8.

Архитектор Web-страниц построен по классическим принципам технологии RAD (Rapid Application Development) для средств визуальной разработки информационных систем. Справа находится список доступных элементов интерфейса, которые могут быть выделены и перенесены мышью на поверхность текущей Web-страницы. С помощью мыши также происходит настройка размеров этих элементов и их размещение на странице.

Как и многие RAD средства, Rapid Developer позволяет построить информационную систему, не написав ни единой строчки кода. Разумеется, это будет крайне простая система (например, система, реализующая просмотр информации в некоторой базе данных). В реальном сложном проекте все равно приходится какой-то код прописывать руками. Но Rapid Developer позволяет свести эту работу к минимуму, избегая кропотливого кодирования интерфейса. Разработчик может в большей степени сосредоточиться на более творческих процессах (например, на оттачивании бизнес-логики системы).

HTML страницы, создаваемые в Rapid Developer, совместимы либо с Microsoft Internet Explorer v4.0 и выше, либо с Netscape Navigator 3.0 и выше, либо с их клонами. WML/WAP страницы совместимы с широким кругом устройств с ограниченными функциональными возможностями и броузеров, эммулирующих работу последних.

Архитектура средств активной отладки

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

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

Общая структура активного кросс-отладчика приведена на рис.2.

Рис. 2. Активный кросс-отладчик

Рассмотрим протокол "менеджер-агент" на примере отладчика VxGDB (Wind River Systems, целевая система - VxWorks). Этот протокол базируется на RPC (Remote Procedure Call). Запросы менеджера можно классифицировать следующим образом: Запросы работы с модулями
Сюда относятся запрос на загрузку модуля, запрос на получении информации о загрузочном файле и запрос на получение информации о символе. Запросы работы с задачами
Это запросы на запуск, остановку и удаление задачи, на присоединение и отсоединение от запущенной задачи, на установку и удаление точки прерывания, на продолжение выполнения остановленной задачи. ptrace-запросы
Агент отладки эмулирует функцию ptrace и передает ей соответствующие запросы на чтение и запись.

Архитектура средств мониторинга

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

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

Рис. 4. Архитектура отладчика, осуществляющего мониторинг

Архитектура Sybase Central

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

Интерфейс Sybase Central составляют меню, панель инструментов, таблицы свойств с закладками и две панели наподобие Windows 95/NT Explorer. Левая панель представляет собой иерархический список, верхний уровень которого составляют plug-in приложения. При раскрытии plug-in отображаются все его установленные составляющие. Дальнейшее раскрытие показывает упрвляемые объекты внутри составляющих каждого plug-in приложения. Каждое plug-in приложение определяет иерархию объектов, имеет собственные визарды, диалоги и таблицы свойств, соответствующие данному продукту.

Один исполняемый файл запускает Sybase Central и подгружает все зарегистрированные в данный момент plug-in приложения. В любое время администратор может зарегистрировать или удалить из системы plug-in приложения. Помимо этого администратор может установить новые plug-in приложения без разрушения старых.

В настоящий момент в качестве plug-in приложений могут использоваться:

Adaptive Server Enterprise (and SQL Server release 11.0.x) Adaptive Server Anywhere Sybase IQ DbQ Net Impact Dynamo

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

Art_1.shtml

Распределенное программирование

С. С. Гайсарян, Институт системного программирования РАН

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

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

Распределенное программирование в малом связано с параллельным выполнением операторов одной программы (например, параллельным выполнением циклов). Технология разработки распределенных программ связана с реализацией коммуникационных пакетов, а также языков программирования и библиотек, облегчающих использование таких пакетов. Примерами коммуникационных пакетов могут служить такие широко используемые пакеты как PVM и MPI. Из языков, опирающихся на эти пакеты следует выделить прежде всего HPF/2 (High Performance Fortran, version 2) и язык, разработанный в ИСП РАН, - mpC. Среди многочисленных библиотек наиболее интересны различные алгебраические библиотеки (например, ScalaPack), а также библиотеки, вводящие параллельные конструкции в стандартные языки программирования (одна из таких библиотек DPJ - Data Parallel Java - разрабатывается в ИСП РАН).

Распределенное программирование в большом состоит в разработке распределенных программных систем. В последнее время широко используются объектно-ориентированные технологии разработки таких систем. Наиболее известные такие технологии связаны с системой стандартов OMG (стандарт CORBA).

Распределенные прикладные программные системы предназначены для поддержки коллективных разработок и других видов коллективной деятельности в самых различных областях.
В таких системах используются новейшие достижения в области вычислительной техники и коммуникаций. Примером такой системы может служить система POLITeam (GMD-FIT, Германия), основной целью которой является обеспечение оперативной работы правительства Германии, расположенного в двух городах - Берлине и Бонне, в настоящее время имеются в наличии как аппаратные, так и программные средства, позволившие реализовать и успешно эксплуатировать такую систему. С проектом POLITeam связано одно из ведущих научных направлений GMD - "Системы поддержки совместных разработок на основе коммуникации" (Communication and Cooperation Systems). Это одно из интенсивно развивающихся научно-исследовательских и прикладных направлений современной информатики. Широко известны такие системы для организации совместной работы как система Totem, разработанная в Университете г. Санта-Барбара, Калифорния, США, система Transis, разработанная в Университете г. Иерусалима, Израиль, система Horus Корнельского Университета (США) и многие другие. При разработке и реализации перечисленных систем применялись различные подходы, что позволяет разработать их аналитический обзор с целью выбора наиболее дешевого и приемлемого подхода. Это относится и к инструментальным программным средствам, используемым для реализации систем поддержки совместных разработок. Одним из широко известных инструментальных средств, используемых при разработке и реализации таких систем, является пакет Rampart Toolkit, разработанный в AT&T Bell Laboratories, Нью-Джерси, США. Для реализации системы поддержки совместных разработок в рамках проекта POLITeam использовалась другая не менее известная инструментальная система LinkWorks фирмы Digital Equipment Corporation, США.

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

Сфера применимости

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

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

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

Автоматический поиск терминологии

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

Азбука 64-разрядного программирования

Для работы с 64-разрядным кодом понадобятся компилятор, линкер и несколько подключаемых библиотек. Все это есть в последних дистрибутивах SDK и DDK. Прежде всего, необходимо рассмотреть макросы и директивы компилятора, предназначенные для 64-разрядного кода: _WIN64 - 64-разрядная платформа; _WIN32 - 32-разрядная платформа (для совместимости с 32-разрядной платформой); _WIN16 - 16-разрядная платформа.

Также компилятор имеет встроенные предопределенные макросы, специфичные для различных архитектур процессоров: _M_IA64 - 64-разрядная архитектура Intel; _M_IX86 - 32-разрядная архитектура Intel; _M_ALPHA_64 - 64-разрядная архитектура Alpha; _M_ALPHA32 - 32-разрядная архитектура Alpha; _M_ALPHA - архитектура Alpha, либо 32-разрядная, либо 64-разрядная.

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

Теперь есть возможность создавать приложения, работающие и на 32-, и на 64-разрядной платформах. Здесь есть, однако, немало подводных камней. Следует быть очень внимательным - например, следующий код был вполне пригоден для приложений, но не для 64-разрядной платформы: #ifdef _WIN32 // Win32 код ... #else // А здесь неясно, какой код следует далее: 64- или 16-разрядный... ... #endif И этот код не является корректным: #ifdef _WIN16 // Win16 код ... #else // То же самое: 32- или 64-разрядный код? ... #endif

Чтобы исправить этот код, нужно после #else добавить макросы _WIN32 или _WIN64. Просто придется привыкнуть к тому, что теперь код бывает трех (а не двух, как раньше) , поэтому использование директивы #else в привычных конструкциях приведет к неоднозначности (хотя 16-разрядных приложений становится все меньше и меньше, поддержка этой платформы в современных компиляторах остается).

Теперь рассмотрим новые типы данных. Их можно условно разделить на три группы (см. Таблицу 1): целочисленные типы явного представления (fixed-precision integer types); целочисленные типы, представленные указателями (pointer-precision integer types); типы специальных указателей (specific-precision pointer types).

Описания этих типов находятся в файле basetsd.h (входящем в состав DDK/SDK) и приведены в Таблице 1.

Теперь рассмотрим особенности новых типов данных.
Каждый целочисленный тип явного представления имеет размер, соответствующий его определению. Это означает, что переменная типа int32 всегда будет занимать 32 разряда, вне зависимости от платформы, на которой запускается и исполняется код. Обратите внимание, что при следующем макросе ... #ifdef _WIN32 // Win32 код ... под 32-разрядным кодом подразумевается использование 32-разрядных типов данных. Именно для переменных этой платформы служит тип int32. То же касается и других целочисленных типов явного представления, имеющих размер 32 разряда. Второй вид (целочисленные типы, представленные указателями) имеет свою особенность: размер данных каждого такого типа зависит от платформы, на которой исполняется приложение. Именно поэтому многие из этих типов названы интегральными. Они сочетают в себе свойства 32- и 64-разрядных типов. Эти типы можно сравнить с виртуальными функциями и поздним связыванием из объектно-ориентированного программирования, так как в обоих случаях среда исполнения определяет конкретные свойства элементов только во время исполнения приложения, а не компиляции (в этом и заключается позднее связывание). Эти типы данных позволяют создавать приложения, одинаково хорошо работающие на 32- и 64-разрядной платформах. Далее следуют указатели. При работе с ними надо соблюдать осторожность: необходимо учитывать разрядность данных, которые адресуются указателем, и помнить, что 32-разрядные указатели в 64-разрядном коде всегда расширяются операционной системой до нужного размера. Следующие функции Win64 (Helper Functions) отвечают за преобразование одного типа в другой (эти inline-функции определены в Basetsd.h). Смысл многих из них понятен из определения прототипов, к остальным требуются объяснения: unsigned long HandleToUlong( const void *h ); long HandleToLong( const void *h ); void *LongToHandle( const long h ); unsigned long PtrToUlong( const void *p ); unsigned int PtrToUint( const void *p ); unsigned short PtrToUshort( const void *p ); long PtrToLong( const void *p ); int PtrToInt( const void *p ); short PtrToShort( const void *p ); void * IntToPtr( const int i ) расширяет знаком (sign-extends) значение типа int; void * UIntToPtr( const unsigned int ui) расширяет нулем (zero-extends) значение типа unsigned int; void * LongToPtr( const long l ) расширяет знаком (sign-extends) значение типа long; void * ULongToPtr( const unsigned long ul) расширяет нулем (zero-extends) значение типа unsigned long. Теперь рассмотрим изменения в Win64 API.


Как уже отмечалось, лишь некоторые функции Win64 API были изменены. Для того чтобы перевести 32-разрядный код в 64-разрядный, следует использовать новые функции оконного класса (Window class). Если в private-данных окна или класса есть указатели, необходимо задействовать следующие новые функции: GetClassLongPtr, GetWindowLongPtr, SetClassLongPtr, SetWindowLongPtr. Эти функции могут работать и на 32- и на 64-разрядной платформе, но для компиляции требуют 64-разрядного компилятора. Также необходимо, чтобы указатели и дескрипторы (handles), входящие в private-данные класса, могли использовать новые 64-разрядные функции. Нужно иметь в виду, что следующие элементы в Winuser.h во время 64-разрядной компиляции не определены: GWL_WNDPROC, GWL_HINSTANCE, GWL_HWDPARENT, GWL_USERDATA. Вместо них в Winuser.h определены следующие новые элементы: GWLP_WNDPROC, GWLP_HINSTANCE, GWLP_HWNDPARENT, GWLP_USERDATA, GWLP_ID. Например, следующий код вызовет ошибку компиляции: SetWindowLong(hWnd, GWL_WNDPROC, (LONG)MyWndProc); Его нужно изменить так: SetWindowLongPtr(hWnd, GWLP_WNDPROC, (LONG_PTR)MyWndProc); Обращаю внимание читателей на следующий момент. Прежде чем делать cbWndExtra членом структуры WNDCLASS, необходимо убедиться, что для указателя имеется достаточно памяти. Например, если зарезервировано sizeof(DWORD) байт для адресуемой переменной, следует зарезервировать sizeof(DWORD_PTR) байт. Теперь вернемся к новым 64-разрядным API-функциям. Все они объявлены в Winuser.h, включены в Windows.h и используют User32.lib. 1. GetClassLongPtr. GetClassLongPtr возвращает значение из структуры WNDCLASSEX, которое связано с определенным окном. Если вы возвращаете указатель или дескриптор окна (handle), эта функция в точности повторяет GetClassLong. Но чтобы написать код, работающий под двумя платформами (32- и 64-разрядной), нужно использовать только GetClassLongPtr. Вот ее определение: ULONG_PTR GetClassLongPtr( HWND hWnd, // указатель на окно int nIndex // смещение возвращаемого значения). Было бы нецелесообразно описывать все аргументы, так как они в точности повторяют параметры 32-разрядной функции GetClassLong (и, следовательно, доступны в любой справке по Win32 API). 2.


GetWindowLongPtr. Здесь та же картина, что и в предыдущем случае. Эта функция является заменой функции GetWindowLong и служит лишь для совместимости двух платформ (а значит, и для создания кросс-платформенных приложений). Функция GetWindowLongPtr возвращает дескриптор окна и значение из экстрапамяти окна по указанному смещению. Вот ее определение: LONG_PTR GetWindowLongPtr( HWND hWnd, // указатель на окно int nIndex // смещение возвращаемого значения). 3. SetClassLongPtr. Функция SetClassLong заменяет определенные значения по заданным смещениям в экстрапамяти класса или WNDCLASSEX-структуры на значения того класса, к которому принадлежит данное окно. Во многом эта функция похожа на SetClassLong, но она является межплатформенной. ULONG_PTR SetClassLongPtr( HWND hWnd, // указатель на окно int nIndex, // указатель на значение, которое надо поменять LONG_PTR dwNewLong // новое значение); 4. SetWindowLongPtr. Функция SetWindowLongPtr меняет атрибуты окон. Она также записывает определенные значения (по определенным смещениям) в экстрапамять окна. Эта функция является интегральным (в смысле объединения двух платформ) аналогом SetWindowLong. LONG_PTR SetWindowLongPtr( HWND hWnd, // указатель на окно int nIndex, // смещение, куда записывать значение LONG_PTR dwNewLong // новое значение).

Батарея, огонь!

Коли поняли приказ -
Выполняйте сей же час!
Л. Филатов. Про Федота-стрельца, удалого молодца

Объект "Цепь стрелков" создается в теле метода OnCreate класса CFireView. При вызове метода OnSize вызывается одноименный метод объекта "Цепь стрелков", выполняющий начальную настройку цепи.

С помощью редактора ресурсов Visual C++ введем в основное меню программы команды для открытия огня и управления скоростью движения пуль. Программный код методов, связанных с этими пунктами меню, приведен в листинге 5.

Обратите внимание на то, что автоматные модели, включая и модели стрелков, сразу же после создания в методе OnCreate начинают работать. А управление скоростью движения пуль реализовано с помощью механизма управления скоростью работы сетевой автоматной среды (методы OnFast и OnSlow). Объект TNetFsa создается в основном классе программы CFireApp (подробнее см. [1], раздел "Редактирование основного класса программы").

Базовый цикл разработки программ

А теперь приступим к разработке настоящей Windows CE-программы. Последовательность необходимых для этого шагов здесь такая же, как и при подготовке программы для Windows настольных систем. Для начала организуем новую рабочую область в окне Visual C++. Можно прибегнуть к услугам одного из множества "мастеров", призванных помочь в составлении Windows CE-программ, либо заняться этим самостоятельно, выбрав тип приложения Win32 application и установив флажки для тех процессоров, на которые, как предполагается, будет рассчитана программа.

По завершении разработки проекта следует просто набрать текст программы и подготовить ресурсы, в том числе меню, пиктограммы и шаблоны диалоговых окон, почти так же, как в ходе аналогичных процедур в среде Windows 98 или Windows NT, исключение составляют вышеупомянутые отличия в API. Как было отмечено ранее, отличия эти не слишком значительны; тем не менее некоторые особенности модели программирования для Windows CE все же заслуживают внимания. Первая, и, на поверхностный взгляд, наиболее удивительная из них, - отсутствие в Windows CE меню для окон верхнего уровня. Это не означает, что Windows CE-программы не могут иметь меню, просто управление ими организуется через панель команд.

Элемент управления "панель команд" и ее более сложные "сестры" - "командные полосы" - обеспечивают доступ к меню и инструментальным панелям, кроме того, предусматривают место для размещения кнопок вызова справочной системы программ Windows CE и их закрытия. Благодаря своей конструкции эти элементы управления предельно просты в программировании. На деле незамысловатая панель команд, которая обеспечивает доступ к меню и кнопкам закрытия программы, может быть представлена всего тремя строчками в тексте программы. В элементе управления "командная полоса" получила дальнейшее развитие концепция панели команд, компоненты которой, т. е. меню, кнопки и другие элементы, группируются в отдельные полосы, размещаемые на экране пользователем.
Основой данного элемента служит элемент управления rebar (повторно используемая панель), разработанный для Internet Explorer 3. Еще одно отличие Windows CE-программ состоит в том, что в масштабах отдельной программы пиктограммы назначаются классам, а не экземплярам окна. Следовательно, два окна одного и того же оконного класса будут иметь одну и ту же пиктограмму. Это не играет особой роли, поскольку пиктограмма окна отображается только на соответствующей кнопке панели задач. Большинство остальных отличий, не считая уже перечисленных, касается соглашений по программированию, а не ограничений для программ или различий в реализации. Например, окна верхнего уровня в Windows CE могут содержать строки заголовка, в то время как по имеющимся соглашениям это недопустимо. Подобный запрет вызван необходимостью экономии места на крохотных экранах устройств Windows CE. В версиях Windows для настольных систем строка заголовка применяется для перемещения окна по экрану. Такой функции в Windows CE-системах чаще всего нет, так как по умолчанию окна верхнего уровня в Windows CE занимают весь экран. Здесь уместно упомянуть одну из новинок Windows CE. Начиная с версии Windows CE 2.1 диспетчер окон обзавелся средствами для работы со стандартными окнами переменного размера. Операционная система всегда обеспечивала возможность формирования окон любого фиксированного размера, однако теперь диспетчер окон позволяет окаймлять перекрывающиеся окна рамками, в результате пользователь может менять их размеры. Тем не менее даже на новых профессиональных РПК такое увидишь не часто, поскольку по умолчанию окна верхнего уровня занимают всю площадь экрана, несмотря на его относительно немалые размеры. //============================================================ // TinyCE - Небольшая программа для Windows CE // #include <windows.h> #include <commctrl.h> // подключение линейки команд LRESULT CALLBACK MainWndProc(HWND, UINT, WPARAM,LPARAM); TCHAR szAppName[] = TEXT ("TinyCE"); HINSTANCE hInst; //----------------------------------- // Точка входа в программу // int WINAPI WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance, LPWSTR lpCmdLine, int nCmdShow) { WNDCLASS wc; HWND hWnd; MSG msg; hInst = hInstance; // Регистрируется класс App Main Window memset (&wc, 0, sizeof (wc)); wc.lpfnWndProc = MainWndProc; // Внешний вызов wc.hInstance = hInstance; // Дескриптор владельца wc.hbrBackground = (HBRUSH) GetStockObject(WHITE_BRUSH); wc.lpszClassName = szAppName; // Имя класса окна if (RegisterClass(&wc) == 0) return -1; // Построение главного окна hWnd = CreateWindow (szAppName, // Класс окна szAppName, // Заголовок окна WS_VISIBLE, // Флаги стилей CW_USEDEFAULT, // Позиция по X CW_USEDEFAULT, // Позиция по Y CW_USEDEFAULT, // Исходная ширина CW_USEDEFAULT, // Исходная высота NULL, // Предок NULL, // Меню, должен иметь // значение NULL hInstance, // Экземпляр программы NULL); // Указатель для // создания параметров // В качестве return-значения передается код ошибки, // если окно не построено if (!IsWindow (hWnd)) return -2; // Стандартные вызовы отображения и обновления ShowWindow (hWnd, nCmdShow); UpdateWindow (hWnd); // Цикл обработки сообщений в программе while (GetMessage (&msg, NULL, 0, 0)) { TranslateMessage(&msg); DispatchMessage(&msg); } return 0; } //----------------------------------- // Основная оконная процедура // LRESULT CALLBACK MainWndProc(HWND hWnd, UINT wMsg, WPARAM wParam, LPARAM lParam) { HWND hwndCB; PAINTSTRUCT ps; RECT rect; HDC hdc; switch (wMsg) { case WM_CREATE: // Создание минимальной панели команд, содержащей только // кнопку Exit.


hwndCB = CommandBar_Create (hInst, hWnd, 0x10); CommandBar_AddAdornments (hwndCB, 0, 0); break; case WM_PAINT: // Настройка размера прямоугольника клиентского окна // с учетом высоты панели команд. GetClientRect (hWnd, &rect); rect.top += CommandBar_Height (GetDlgItem (hWnd, 0x10)); hdc = BeginPaint (hWnd, &ps); DrawText (hdc, TEXT ("Hello Windows CE!"), -1, &rect, DT_CENTER | DT_VCENTER | DT_SINGLELINE); EndPaint (hWnd, &ps); break; case WM_DESTROY: break; } return DefWindowProc(hWnd, wMsg, wParam, lParam); } Достаточно взглянуть на этот текст, чтобы увидеть, как похожи приложения Windows CE на обычные Windows-программы. А теперь, не упуская из виду все перечисленные соображения, рассмотрим элементарную программу для Windows CE. На рис. 1 показан исходный текст простой программы TinyCE, которая лишь выводит на экран строку текста в главном окне. При беглом взгляде программисты, сроднившиеся с функциями Win32, вряд ли обнаружат едва уловимые различия между этой программой и ее "кузинам" для Windows 98 или NT. Она так же регистрирует класс окна, конструирует окно, выполняет цикл обработки сообщений и работает с окнами, как и любая другая Windows-программа. В отличиях, наблюдающихся в данном примере, повинны уже упоминавшиеся расхождения в интерфейсах API. Например, для размещения кнопки закрытия программы используется панель команд. После набора текста программы для ее компиляции и запуска применяются точно такие же методы, как и для приложений на настольных ПК. Процедура компиляции предусматривает дополнительную операцию автоматической загрузки полученного EXE- или DLL-модуля в подключенное к настольному ПК Windows CE-устройство. Для запуска программы на выполнение в среде Windows CE выбирается тот же пункт меню Program | Run (Программа | Запуск либо [Ctrl] + [F5]), что и при запуске программы, подготовленной для Windows NT. И конечно, с помощью интегрированного отладчика можно выполнять программу в пошаговом режиме. Основное различие между отладкой программ для Windows CE и Windows NT вызвано влиянием скорости последовательного соединения между ПК разработчика и удаленной Windows CE-системой.


Из- за низкой скорости такого соединения пошаговая отладка превращается в раздражающе медленный процесс. Что касается меня, я обычно применяю отладчик только для поиска самых трудноуловимых ошибок. Вместо дистанционного отладчика можно применять другой вариант. Все SDK для платформ РПК, КПК и автомобильных ПК (Auto PC) оснащены программными эмуляторами, которые пытаются имитировать удаленное Windows CE-устройство в среде Windows NT. Такой эмулятор запускает скомпилированную специальным образом версию подготовленной программы. Он эмулирует интерфейс API Windows CE, в том числе такие его расширения, как API СУБД. Но и здесь не обходится без проблем: модель среды Windows CE, обеспечиваемая эмулятором, далека от идеала. Иногда после целого дня работы вдруг понимаешь, что проблема, над решением которой бьешся, - проблема эмулятора, а не ошибка в программе. Но выход из создавшейся ситуации все же есть: программы для Windows CE следует составлять таким образом, чтобы они компилировались как для Windows CE, так и для Windows NT. В результате общие для обеих систем фрагменты приложения можно отлаживать локально в среде Windows NT, а затем, выбрав иную целевую среду, провести компиляцию для Windows CE. Нужно только помнить, что многократные компиляции на любой из платформ чреваты сложностями. После бесконечных повторов компиляции для Windows NT придется потратить массу времени, чтобы путем внесения изменений добиться надлежащего функционирования программы в среде Windows CE. Разработать программу, которая будет компилироваться и для Windows NT, и для Windows CE, не так уж и трудно. Чтобы выделить фрагменты программы, характерные для конкретной операционной системы, следует применять выражения define компилятора, и тогда они будут выбираться при компиляции для заданной ОС. В приведенном ниже фрагменте программы функции формирования панели команд размещены в предложениях условной компиляции (#), поэтому будут охвачены процедурой компиляции только для Windows CE. #ifdef _WIN32_WCE // Если выполняется // компиляция для CE HWND hwndCB; // Формирование панели команд.


hwndCB = CommandBar_Create (hInst, hWnd, IDC_CMDBAR); // Добавление кнопки закрытия программы // в панель команд. CommandBar_AddAdornments (hwndCB, 0, 0); #endif // _WIN32_WCE Конечно, подготовка текста программы составляет только часть процесса разработки. Жизненно необходим набор инструментов для отладки и тестирования программы. В ходе установки Visual C++ для Windows CE инсталлируется комплект инструментов для работы в дистанционном режиме, который поможет при отладке Windows CE-программ. В комплект входят большей частью инструменты, аналогичные своим собратьям, ориентированным на отладку Windows-программ для настольных ПК. Среди них имеются Windows CE-версии программы Regedit для редактирования системного реестра на Windows CE-устройствах; Spy для отслеживания сообщений, поступающих для окон Windows CE, и ZoomIn для проверки прорисовки изображений при их увеличении. Кроме того, комплект содержит модуль мониторинга, который позволяет отслеживать состояние процессов, исполняющихся на устройстве. Программа обеспечивает информацию о текущих потоках каждого процесса, а также о том, какие DLL загружены в ходе выполнения этого процесса. И последний инструмент - программа просмотра памяти, с помощью которой можно проверять содержимое динамических областей памяти программы (хипов). Все эти инструменты запускаются на настольном ПК и взаимодействуют с ПО удаленного клиента подключенного к нему Windows CE-устройства.

Бизнес-приложения в Internet

Большинство Internet и intranet приложений определяются как "статические" или "динамические" в зависимости от содержания и доступа к данным (смотри Рис. 1). Сегодня большинство приложений в Internet - это публикации, предлагающие статическое содержание и обеспечивающие предсказуемый, универсальный доступ. Компании, разрабатывающие свои первые Web-приложения, обычно публикуют информацию о продукте в Internet или данные о служащих в корпоративных сетях intranet.

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

Имея целью Управляемую Диалоговую Обработку Запросов (Online Transaction Processing - OLTP) , а Web как способ доступа, Sybase предлагает название этого нового типа приложений – “WebOLTP”. Такие приложения становятся не простыми программами для просмотра данных, а приложениями для обработки в реальном режиме времени важной деловой информации, например, операций в банке, прием заказов, работа с клиентами.

Рисунок 1. Большинство Internet и Intranet приложений классифицируются как “статические” или “динамические” в зависимости от содержания и вида доступа

Благодарности

Выражаю свою благодарность людям, которые имели прямое отношение к реализации спецификации и внесения в нее своих поправок: Алексей Неупокоев, Юрий Юдин, Роман Камерлох, Тарас Улахович, Геннадий Пестунов, Иван Пономаренко. Без участия этих людей данная спецификация никогда бы не была мной получена.

BlueJ: учебная оболочка или полноценная среда разработки?

Программирование. Дайджесты и статьи

А.Г. Пискунов, С.М. Петренко

Игорь Савчук, Blogerator.ru

Пэт Хелланд, Дейв Кэмпбел
Перевод: Сергей Кузнецов

Майк Шапиро
Перевод: Сергей Кузнецов

А.И. Аветисян, В.В. Бабкова, А.В. Монаков
Труды Института системного программирования РАН

А. Белеванцев, Д. Журихин, Д. Мельник
Труды Института системного программирования РАН

В.А. Падарян, А.И. Гетьман, М.А. Соловьев
Труды Института системного программирования РАН

Джеймс Лярус, Кристос Козиракис
Пересказ: Сергей Кузнецов

Тед Ньюард
Пересказ: Сергей Кузнецов

Andrew Binstock, перевод: Сергей Кузнецов

Денис Турдаков, Максим Гринев

Перевод: Сергей Кузнецов
Оригинал: A Conversation with Bruce Lindsay, ACM Queue, Vol. 2, No. 8 - November 2004.

,

Вячеслав Любченко

Вячеслав Любченко

А. Белеванцев, М. Кувырков, Д. Мельник., Труды Института системного программирования РАН

, Труды Института системного программирования РАН

С.С. Гайсарян, К.Н. Долгова, Труды Института системного программирования РАН

(Good Ideas, through the Looking Glass)

Перевод:

,

Валентина Ванеева,

Лекция из курса "Основы программирования на языке Пролог"
П. А. Шрайнер, INTUIT.ru

Лекция из курса "Стили и методы программирования"
Н.Н.Непейвода, INTUIT.ru

Илья Аввакумов, Freepascal.ru

Глава из книги "Наука отладки"
Мэтт Тэллес, Юань Хсих, Пер. с англ. С. Лунин, науч.ред. С. Брудков
Издательство:

Максим Фокин,

, http://acedutils.narod.ru

, http://acedutils.narod.ru

ведущий .NET-разработчик компании

ведущий .NET-разработчик компании

ведущий .NET-разработчик компании

, руководитель геоинформационного проекта "GeoMapX",

, руководитель геоинформационного проекта "GeoMapX",

Андрей Кухар,

Михаил Продан,

Арсений Чеботарёв,

Татьяна Михно,

Александр Харьков,

Сергей Гущенко,

Шеломанов Роман,

В.В. Рубанов, А.И. Гриневич, Д.А. Марковцев, М.А. Миткевич,
Труды

С.С. Гайсарян, А.В. Чернов, А.А. Белеванцев, О.Р. Маликов, Д.М.
Мельник, А.В. Меньшикова,
Труды
А.Я. Калинов, К.А. Карганов, К.В. Хоренко, Труды
, книга
Богданов Николай Константинович,
журнал "Автоматизация в промышленности", №9 - 2003
Виктор Ематин, Борис Позин (),
Шилоносов Александр (), Dekart Inc
Шумаков С.М.
К.А. Костюхин, НИИСИ РАН
Евгений Игумнов

Ермолаев Д.С.,
П. В. Федосеев

Евгений Игумнов

Ермолаев Д.С.

В. Ковалев,



Stanislav Ievlev,
Олег Сергудаев,
,
,
,
Jim Blandy, Перевод на русский язык:
Николай Игнатович, журнал , #09-10/1999
Джеффри Воас, журнал , #09-10/1999
Дуглас Боулинг, PC Magazine/RE #10/1999
С. А. Андрианов, МИР ПК #11/99
Наталия Елманова, Центр Информационных Технологий
Наталия Елманова, Центр Информационных Технологий
Наталия Елманова, Центр Информационных Технологий
Сергей Кузнецов, Центр Информационных Технологий
Сергей Кузнецов, Центр Информационных Технологий
С. С. Гайсарян, Институт системного программирования РАН
Сергей Кузнецов, Центр Информационных Технологий, ComputerWord #1/97
,
Сервер
А. Соловьев,
С. Паронджанов, учебные материалы конференции ,
Виктор Олифер, учебные материалы конференции ,
Сергей Кузнецов, учебные материалы конференции ,
В. Сухомлин, НИВЦ МГУ, учебные материалы конференции ,
Павел Храмцов, Учебные материалы конференции ,
Материалы конференции,

Borland: Making Development Easier

Borland International, Inc.- лидирующий производитель высококачественных продуктов для разоаботчиков программного обеспечения во всем мире. Компания Borland известна своим популярным семейством средств быстрой разработки настольных приложений, клиент-серверных информационных систем, приложений для Internet/intranet, систем масштаба предприятия. Продукты компании используются корпоративными и индивидуальными разработчиками, реселлерами, системными интеграторами. Основанная в 1983 г., компания Borland расположена в Scotts Valley, California. Подробную информацию о компании можно получить на корпоративном сервере Borland

BusinessInsight - наглядное представление данных для принятия решений.

С Delphi 3 Client/Server Suite Borland поставляет новые инструменты представления данных для анализа и представления корпоративных данных и их создания отчетов на их основе: DecisionCube и DecisionGrid для многомерного анализа данных. QuickReports 2.0 для упрощенного создания, просмотра и печати более 10 типов отчетов, включая "отчет в отчете", составные отчеты, отчеты master-detail, и более 130 отчетов для печати почтовых этикеток. TeeChart обеспечивает визуальное представление данных в виде 11 различных типов диаграмм и графиков для удобства принятия решений.

CASE

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

Цель

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

Цели составления сценария

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

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

Часть 1: Дублирование интерфейсов

В вышеприведенном случае с Ричи Ричем мы видели, что DLL для аквариума и DLL для топливного бака не могли находиться на одном и том же компьютере, потому что ни клиентское приложение, ни две DLL не были COM компонентами. Какая бы DLL ни была скопирована на компьютер, только скопированная последней будет использоваться клиентским приложением. Как мы уже видели, использование некорректной DLL может привести к катастрофическим результатам: вертолет разбился. Мы предположили, что если бы разработчик программы использовал технологию COM, то он имел бы обе DLL на машине. Поскольку две DLL были бы различимы по их CLSID, они могли бы использоваться в пределах одного приложения. По технологии COM обе DLL должны задействовать идентичные методы через заменяемые интерфейсы.

Чтобы это доказать, мы собираемся создать единственное GUI-приложение, которое использует и показывает информацию, получаемую от двух серверов COM: GasTankLevelGetter DLL и FishTankLevelGetter DLL. Мы также создадим одно приложение, которое будет получать информацию от каждой COM DLL и отображать их. Опрос каждой DLL будет происходить попеременно по четырехсекундному таймеру. Чтобы подчеркнуть неизменность интерфейсов и что COM является двоичным стандартом, мы собираемся написать GUI-приложение FishTankLevelGetter COM DLL исключительно на основе информации о GasTankLevelGetter COM DLL. Однако мы не собираемся предоставлять вам исходный код GasTankLevelGetter COM DLL. Если вы переписали пример, вы найдете GasTankLevelGetter COM DLL в папке Binaries. Мы вам даже не скажем на чем написана GasTankLevelGetter: на Delphi, Visual C++, Java(tm), Cobol, Turbo Pascal или Visual Basic. Вам, однако, придется зарегистрировать GasTankLevelGetter DLL с помощью RegSvr32.

Как только вы зарегистрировали GasTankLevelGetter DLL с помощью RegSvr32, вы готовы начать, вооружившись OLE/COM Object Viewer. Если вы используете Visual C++ 5.0, OLE/COM Object Viewer находится в программной группе Visual C++ 5.0 при навигации через Start | Programs в Explorer.
Если у вас нет OLE/COM Object Viewer, спишите его из http://www.microsoft.com/oledev/ и запустите приложение.

Запустив OLE/COM Object Viewer, выберите режим View | Expert для просмотра Type Libraries. Пролистайте список и откройте папку под названием Type Libraries. Пролистайте папку пока не найдете GasTankLevelGetter 1.0 TypeLibrary (Ver 1.0). Выделите этот элемент списка и вы увидите на правой панели ID библиотеки типа и ее полный путь, как показано на рисунке.

Двойной щелчок на GasTankLevelGetter откроет окно, отображающее всю библиотеку типа. Эта информация берется их данных регистров, которые создаются при регистрации DLL. Данные по TypeLib хранятся в HKEY_CLASSES_ROOT \ TypeLib.



Раздел coclass содержит список поддерживаемых интерфейсов для компонентного объекта. Объект может иметь любое количество интерфейсов, перечисляемых в его теле и полностью описывающих тот набор интерфейсов, которые этот объект реализует, как входящих, так и исходящих. Ниже приведены CLSID и интерфейс, содержащиеся в coclass для данного COM объекта:

CLSID: 8A544DC6-F531-11D0-A980-0020182A7050
Interface Name: ILevelGetter

[ uuid(8A544DC6-F531-11D0-A980-0020182A7050), helpstring("LevelGetter Class") ] coclass LevelGetter { [default] interface ILevelGetter; }; Раскрывая далее информацию по интерфейсу наподобие coclass, мы можем определить:

ID интерфейса 8A544DC5-F531-11D0-A9 80-0020182A7050. Интерфейс наследуется от IUnknown. Интерфейс поддерживает методы. Первые три метода возвращают значения типа long, а четвертый - указатель на BSTR. [ odl, uuid(8A544DC5-F531-11D0-A980-0020182A7050), helpstring("ILevelGetter Interface") ] interface ILevelGetter : IUnknown { HRESULT _stdcall GetLowestPossibleSafeLevel([out, retval] long* plLowestSafeLevel); HRESULT _stdcall GetHighestPossibleSafeLevel([out, retval] long* plHighestSafeLevel); HRESULT _stdcall GetCurrentLevel([out, retval] long* plCurrentLevel); HRESULT _stdcall GetTextMessage([out, retval] BSTR* ppbstrMessage); }; Более детальный взгляд на структуру type library открывает нам методы и ID интерфейсов.







Теперь, поскольку мы знаем, как построить интерфейс ILevelGetter, давайте создадим наш собственный компонент COM на основе этой информации. Если вы решили работать с существующим примером, все источники находятся в папке LevelViewer. Запустите Visual C++ 5.0 и создайте новый проект. Определите тип ATLComAppWizard как проект и "FishTankLevelGetter" как имя проекта. Мы полагаем, что вы создали новую папку проекта. Окно New Project Dialog должно выглядеть как это показано ниже.



В AppWizard для Server Type укажите Dynamic Link Library (DLL). Отметьте обе опции Allow merging of proxy/stub code и Support MFC.



Когда вы создали новый проект FishTankLevelGetter, выберите в меню Insert | New Class... для создания нового ATL класса. Вы можете выбрать любое имя класса, но убедитесь, что интерфейс называется IlevelGetter, а его тип - Custom, что указывает на наследование ILevelGetter от IUnknown. Если бы ILevelGetter в GasTankLevelGetter COM DLL наследовалась от IDispatch, нам пришлось бы выбрать тип интерфейса Dual, который указывал бы на то, что новый интерфейс будет производным от IDispatch. Если диалог New Class выглядит как показано ниже, нажмите OK, чтобы создать новый класс.



Следующий шаг заключается в редактировании FishTankLevelGetter.IDL. В IDL файле вам нужно иметь новый интерфейс ILevelGetter, наследуемый из IUnknown. Если вы работаете с примерами, вы увидите следующий код, который содержит четыре одинаковых неизменяемых метода интерфейса IlevelGetter, которые мы видели в интерфейсе ILevelGetter GasTankLevelGetter.

[ object, uuid(7F0DFAA2-F56D-11D0-A980-0020182A7050), helpstring("ILevelGetter Interface"), pointer_default(unique) ] interface ILevelGetter : IUnknown { HRESULT GetLowestPossibleSafeLevel([out, retval] long* plLowestSafeLevel); HRESULT GetHighestPossibleSafeLevel([out, retval] long* plHighestSafeLevel); HRESULT GetCurrentLevel([out, retval] long* plCurrentLevel); HRESULT GetTextMessage([out, retval] BSTR* ppbstrMessage); }; Если вы пишите код, как и мы, самостоятельно, вы захотите добавить вышеуказанный код так, что ваш интерфейс соответствовал четырем идентичным неизменным методам.


Наиболее просто добавить код с помощью " copy and paste" непосредственно из окна ITypeLib Viewer. Ваш код должен выглядеть точно также, как в примере, за исключением ID интерфейса.

Откройте LevelGetter.H и объявите методы в классе. В вашем классе объявление методов должно выглядеть как это показано ниже:

class LevelGetter : public ILevelGetter, public CComObjectRoot, public CComCoClass<LevelGetter,&CLSID_LevelGetter> { public: LevelGetter(){} BEGIN_COM_MAP(LevelGetter) COM_INTERFACE_ENTRY(ILevelGetter) END_COM_MAP() //DECLARE_NOT_AGGREGATABLE(LevelGetter) // Remove the comment from the line above if you don't want your object to // support aggregation. DECLARE_REGISTRY_RESOURCEID(IDR_LevelGetter) // ILevelGetter public: //THE FOUR NEW METHODS STDMETHOD (GetLowestPossibleSafeLevel) (long* plLowestSafeLevel); STDMETHOD (GetHighestPossibleSafeLevel) (long* plHighestSafeLevel); STDMETHOD (GetCurrentLevel) (long* plCurrentLevel); STDMETHOD (GetTextMessage) (BSTR* ppbstrMessage); }; Вам теперь нужно сделать четыре метода. Для демонстрационных целей, давайте оставим методы простыми. Реализуйте их по вашему усмотрению или скопируете следующий код из образцов.

//--------------------------------------------------------------------------- STDMETHODIMP LevelGetter::GetLowestPossibleSafeLevel(long* plLowestSafeLevel) { *plLowestSafeLevel = 70; return S_OK; } //--------------------------------------------------------------------------- STDMETHODIMP LevelGetter::GetHighestPossibleSafeLevel(long* plHighestSafeLevel) { *plHighestSafeLevel = 98; return S_OK; } //--------------------------------------------------------------------------- STDMETHODIMP LevelGetter::GetCurrentLevel(long* plCurrentLevel) { *plCurrentLevel = 94; return S_OK; } //--------------------------------------------------------------------------- STDMETHODIMP LevelGetter::GetTextMessage(BSTR* ppbstrMessage) { *ppbstrMessage = ::SysAllocString(L"All clear, water level is fine"); return S_OK; } Поскольку у вас уже есть методы, скомпилируйте и слинкуйте вашу COM DLL.Затем мы начнем создавать клиентское приложение.

Часть 2: Наследование классов и наследование интерфейсов

В первой части стать мы показали значимость неизменности интерфейсов и продемонстрировали, как разработчик может построить приложение, которое может легко заменять компоненты, если разработан интерфейс. А что, если интерфейс существующего COM-сервера имеет сотни методов? В примере из первой части мы сделали это простым клонированием интерфейса IlevelGetter, поскольку он содержал только четыре метода. Попробуйте с помощью OLE/COM Object Viewer просмотреть некоторые другие библиотеки типов на вашем компьютере. Как вы можете убедиться, многие компоненты имеют интерфейсы с весьма значительным количеством методов. Клонирование интерфейсов, которые реализуют сотни методов, с целью изменить всего лишь несколько из них было бы весьма обременительно.

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

А что, если вы смогли бы наследовать интерфейсы без необходимости повторно описывать реализацию всех методов? Что если бы вы могли создать компонент, унаследовать интерфейсы и функциональное назначение и переделать функциональность по своему усмотрению? Сегодня это нельзя сделать с помощью COM объектов, разработанных вне вашей организации. Однако, если разработчики в вашей организации используют язык программирования, поддерживающий наследование и полиморфизм, типа Visual C++, вы это действительно сделаете. На самом деле, как мы покажем, MFC позволяет сделать это значительно легче.

В корне MFC есть CCmdTarget. CCmdTarget - это не только базовый класс для message-map архитектуры, он также содержит Dispatch планы, которые влияют на интерфейсы, такие как IDispatch и IUnknown. Каждый прямой потомок CCmdTarget, созданный с помощью Class Wizard, содержит эти интерфейсы со своими собственными CLSID. CCmdTarget - один из основных рабочих классов и базовый класс для таких "повседневных" MFC классов, как CView, CWinApp, CDocument, CWnd и CFrameWnd.
Соответственно, каждый производный класс от CCmdTarget может реализовывать собственные CLSID и интерфейсы.

Пример, который мы собираемся рассмотреть, покажет наследование интерфейсов путем образования новых C++ производных классов от CCmdTarget. В нашем базовом классе мы реализуем интерфейс с методами, которые вызывают виртуальные функции членов C++ класса. Наш производный класс заменит некоторые из отобранных виртуальных функций. Что особенно важно, вместо реализации наследуемого класса в той же DLL, мы создадим отдельную DLL со своим собственным CLSID. Наиболее эффективно наследовать реализацию интерфейса от одного кода в другой без переписывания исходного интерфейса.

Давайте начнем с просмотра кода в проекте BaseLevelGetterDLL. BaseLevelGetterDLL является типичной MFC DLL. Она была создана с помощью AppWizard как "regular DLL using the shared MFC DLL". Она также поддерживает автоматику (automation). Завершив работу с AppWizard, получаем BaseLevelGetterExport.h, а BASE_LEVEL_GETTER_DLL оказывается включенной как preprocessor definition в Project | Settings | C++. BaseLevelGetterExport.H и диалог Project | Settings приведены ниже.

//BaseLevelGetterExport.h #ifndef BASE_LEVEL_GETTER_EXPORT_DLL_H #define BASE_LEVEL_GETTER_EXPORT_DLL_H #if defined(BASE_LEVEL_GETTER_DLL) #define BASE_LEVEL_GETTER_EXPORT __declspec(dllexport) #else #define BASE_LEVEL_GETTER_EXPORT __declspec(dllimport) #endif #endif //BASE_LEVEL_GETTER_EXPORT_DLL_H

Определив BASE_LEVEL_GETTER_DLL, мы можем создавать классы и экспортировать их из нашей DLL.

Следующим шагом будет создание C++ класса, который содержит наши интерфейсы. С помощью Class Wizard несколькими нажатиями кнопки мыши мы создадим класс, наследованный от CCmdTarget. Выделив Createable by type ID в диалоге New Class, мы создадим наш новый класс с макросом IMPLEMENT_OLECREATE, присваивающем классу его собственные CLSID и интерфейс IDispatch.



Обращаясь к BaseLevelGetter.CPP, мы видим CLSID:

//Here is our CLSID // {C20EA055-F61C-11D0-A25F-000000000000} IMPLEMENT_OLECREATE(BaseLevelGetter, "BaseLevelGetterDLL.BaseLevelGetter", 0xc20ea055, 0xf61c, 0x11d0, 0xa2, 0x5f, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0) И интерфейс под названием IbaseLevelGetter типа IDispatch:



// {C20EA054-F61C-11D0-A25F-000000000000} static const IID IID_IBaseLevelGetter = { 0xc20ea054, 0xf61c, 0x11d0, { 0xa2, 0x5f, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0 } }; BEGIN_INTERFACE_MAP(BaseLevelGetter, CCmdTarget) INTERFACE_PART(BaseLevelGetter, IID_IBaseLevelGetter, Dispatch) END_INTERFACE_MAP() Вместо того, чтобы работать с интерфейсом, предоставляемым по умолчанию Class Wizard, мы собираемся добавить наш собственный интерфейс, чтобы показать как легко добавлять интерфейсы в классы-потомки от CCmdTarget. Первое, что мы должны сделать, - это описать наши интерфейсы. Определение интерфейса всегда одинаково. Каждый интерфейс должен иметь IID и IUnknown как основной интерфейс где-нибудь в своей иерархии. Также необходимо реализовать три метода IUnknown. В ILevelGetter.H мы используем GUIDGEN.EXE ( находится в \Program Files\DevStudio\VC\Bin) для генерации уникального IID для нашего интерфейса наследуем интерфейс от IUnknown. Дополнительно к трем виртуальным функциям IUnknown мы добавили еще 4 виртуальные функции, которые будут реализованы в нашем COM объекте. Ниже приведен полный код ILevelGetter.H.

#ifndef ILEVELGETTER_H #define ILEVELGETTER_H // {BCB53641-F630-11d0-A25F-000000000000} static const IID IID_ILevelGetter = { 0xbcb53641, 0xf630, 0x11d0, { 0xa2, 0x5f, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0 } }; interface ILevelGetter : public IUnknown { //first add the three always required methods virtual HRESULT STDMETHODCALLTYPE QueryInterface(REFIID riid, LPVOID* ppvObj) = 0; virtual ULONG STDMETHODCALLTYPE AddRef() = 0; virtual ULONG STDMETHODCALLTYPE Release() = 0; //now add methods for this custom interface virtual HRESULT STDMETHODCALLTYPE GetCurrentLevel(long* plCurrentLevel) = 0; virtual HRESULT STDMETHODCALLTYPE GetHighestPossibleSafeLevel(long* plHighestSafeLevel) = 0; virtual HRESULT STDMETHODCALLTYPE GetLowestPossibleSafeLevel(long* plLowestSafeLevel) = 0; virtual HRESULT STDMETHODCALLTYPE GetTextMessage(BSTR* ppbstrMessage) = 0; }; Следующим шагом будет определение методов интерфейса в BaseLevelGetter.H.


В верхней части BaseLevelGetter.H добавим директиву include для описания нашего интерфейса как это показано ниже:

#include "ILevelGetter.h" Как только мы включили ILevelGetter.H, мы можем добавить наши методы интерфейса, используя макрос BEGIN_INTERFACE_PART. В итоге BEGIN_INTERFACE_MACRO создает вложенный класс типа XLevelGetter и член класса m_xLevelGetter в BaseLevelGetter. (Более подробное описание макроса BEGIN_INTERFACE_PART смотри MFC Technical Note 38.) Каждый метод в интерфейсе объявляется в макросе так же, как если бы никакого макроса не было. Можно убедиться, что объявления метода в ILevelGetter.H такие же как и в версии с использованием ATL.

BEGIN_INTERFACE_PART(LevelGetter, ILevelGetter) STDMETHOD(GetCurrentLevel) (long* plCurrentLevel); STDMETHOD(GetHighestPossibleSafeLevel) (long* plHighestSafeLevel); STDMETHOD(GetLowestPossibleSafeLevel) (long* plLowestSafeLevel); STDMETHOD(GetTextMessage) (BSTR* ppbstrMessage); END_INTERFACE_PART(LevelGetter) Поскольку наша цель заключается в эффективном наследовании интерфейсов из одного источника в другой без необходимости повторного описания реализации всех методов, мы собираемся добавить четыре виртуальных функции в наш класс. Каждая виртуальная функция будет соответствовать методу в интерфейсе ILevelGetter. В примере эти методы описаны в нижней части class declaration сразу после макроса BEGIN_INTERFACE_PART.

//since the class can be dynamically created //these virtual functions cannot be pure virtual long GetCurrentLevel(); virtual long GetHighestSafeLevel(); virtual long GetLowestSafeLevel(); virtual CString GetMessage(); Отметим, что поскольку наш класс-потомок от CCmdTarget использует DECLARE_DYNCREATE, эти функции не могут быть чисто виртуальными.

Последнее, что осталось сделать, - объявить наш класс "exportable". Для этого нам необходимо всего лишь включить наше описание экспорта в описание класса. Это выглядит так:

#include "BaseLevelGetterExport.h" class BASE_LEVEL_GETTER_EXPORT BaseLevelGetter : public CCmdTarget { Реализация нашего интерфейса также проста.


Первое, что нужно сделать, - это добавить поддержку нашему новому интерфейсу ILevelGetter. Общее правило заключается в добавлении макроса INTERFACE_PART между BEGIN_INTERFACE_PART и END_INTERFACE_PART для каждого поддерживаемого интерфейса. В BaseLevelGetter.CPP это делается дополнением следующей строки:

INTERFACE_PART(BaseLevelGetter, IID_ILevelGetter, LevelGetter) Так что полное описание INTERFACE_PART выглядит следующим образом:

BEGIN_INTERFACE_MAP(BaseLevelGetter, CCmdTarget) INTERFACE_PART(BaseLevelGetter, IID_IBaseLevelGetter, Dispatch) INTERFACE_PART(BaseLevelGetter, IID_ILevelGetter, LevelGetter) END_INTERFACE_MAP() Далее мы описываем реализацию методов ILevelGetter. Первые три метода, которые должны быть реализованы, - это QueryInterface, AddRef и Release из IUnknown. Эти методы показаны ниже.

//------------------------------------------------------------------------ HRESULT FAR EXPORT BaseLevelGetter::XLevelGetter::QueryInterface ( REFIID iid, LPVOID* ppvObj ) { METHOD_PROLOGUE_EX_(BaseLevelGetter, LevelGetter) return (HRESULT) pThis->ExternalQueryInterface(&iid, ppvObj); } //------------------------------------------------------------------------- ULONG FAR EXPORT BaseLevelGetter::XLevelGetter::AddRef() { METHOD_PROLOGUE_EX_(BaseLevelGetter, LevelGetter) return (ULONG) pThis->ExternalAddRef(); } //------------------------------------------------------------------------- ULONG FAR EXPORT BaseLevelGetter::XLevelGetter::Release() { METHOD_PROLOGUE_EX_(BaseLevelGetter, LevelGetter) return (ULONG) pThis->ExternalRelease(); } Четыре метода ILevelGetter реализуются весьма просто. Вместо фактического выполнения обработки, каждый метод вызывает свою связанную функцию через указатель pThis. На самом деле это требует некоторых дополнительных объяснений. Если вы посмотрите на определение макроса BEGIN_INTERFACE_PART(...) (файл ...\MFC\include\AFXDISP.H), вы обратите внимание, что этот макрос является вложенным описанием класса. Макрос делает вложенный класс (в нашем случае, XLevelGetter) производным от интерфейса (ILevelGetter в нашем примере) и объявляет его в пределах существующего класса (BaseLevelGetter).



Макрос END_INTERFACE_PART(...) завершает "внутреннее" описание класса XLevelGetter и объявляет переменную члена этого класса m_xLevelGetter. Поскольку m_xLevelGetter является членом класса BaseLevelGetter, мы могли бы некоторыми сложными арифметическими операциями над указателями передать от this объекта XLevelGetter в this объекта, содержащего BaseLevelGetter. Однако библиотека MFC содержит другой макрос, выполняющий то же самое. Он называется METHOD_PROLOGUE_EX_, и в нашем конкретном случае он создаст переменную BaseLevelGetter* pThis. Вы можете использовать pThis для доступа к public членам и методам "внешнего" класса BaseLevelGetter, включая виртуальные (полиморфные) функции. Вызов виртуальных функций во "внешнем" классе, фактически, приводит к наследованию интерфейса. Обратите внимание, что виртуальные функции BaseLevelGetter возвращают бессмысленные значения и содержат комментарии, чтобы позволить разработчикам, создающим производные классы, переписать эти функции.

Другой способ показать виртуальное отношение, возможно значительно более удобный для чтения, - это "указать владельца объекта" (set an owner object) в классе XLevelGetter (класс, созданный макросом BEGIN_INTERFACE_PART). Внутри макроса BEGIN_INTERFACE_PART (BaseLevelGetter.H) мы добавляем две функции, и член класса выглядит следующим образом:

XLevelGetter() { m_pOwner = NULL; } //constructor sets member to NULL void SetOwner( BaseLevelGetter* pOwner ) { m_pOwner = pOwner; } //set the member BaseLevelGetter* m_pOwner; //class member Внутри конструктора BaseLevelGetter мы вызываем XLevelGetter::SetOwner. Как упоминалось выше, макрос BEGIN_INTERFACE_PART добавляет в BaseLevelGetter член класса m_xLevelGetter, который представляет LevelGetter. В конструкторе BaseLevelGetter мы вызываем:

m_xLevelGetter.SetOwner( this ); который присваивает m_pOnwer значение действительного объекта.

Ниже показана реализация четырех методов ILevelGetter и четырех ассоциированных виртуальных функций BaseLevelGetter.


Остальные два метода (GetLowestPossibleSafeLevel и GetTextMessage) реализованы по принципу использования "владельца объекта".

//------------------------------------------------------------------------ STDMETHODIMP BaseLevelGetter::XLevelGetter::GetCurrentLevel ( long* plCurrentLevel ) { METHOD_PROLOGUE_EX_(BaseLevelGetter, LevelGetter) //call outer object's GetCurrentLevel //whether this class or a derived class *plCurrentLevel = pThis->GetCurrentLevel(); return S_OK; } //------------------------------------------------------------------------- STDMETHODIMP BaseLevelGetter::XLevelGetter::GetHighestPossibleSafeLevel ( long* plHighestSafeLevel ) { METHOD_PROLOGUE_EX_(BaseLevelGetter, LevelGetter) //call outer object's GetHighestSafeLevel //whether this class or a derived class *plHighestSafeLevel = pThis->GetHighestSafeLevel(); return S_OK; } //------------------------------------------------------------------------- STDMETHODIMP BaseLevelGetter::XLevelGetter::GetLowestPossibleSafeLevel ( long* plLowestSafeLevel ) { METHOD_PROLOGUE_EX_(BaseLevelGetter, LevelGetter) //call outer object's GetLowestSafeLevel //whether this class or a derived class if( m_pOnwer != NULL) { *plLowestSafeLevel = m_pOwner->GetHighestSafeLevel(); } else { ASSERT(FALSE); } return S_OK; } //------------------------------------------------------------------------ STDMETHODIMP BaseLevelGetter::XLevelGetter::GetTextMessage ( BSTR* ppbstrMessage ) { METHOD_PROLOGUE_EX_(BaseLevelGetter, LevelGetter) //call outer object's GetMessage //whether this class or a derived class CString sMessage; If( m_pOwner != NULL ) { sMessage = m_pOwner->GetMessage(); } else { ASSERT(FALSE); } *ppbstrMessage = sMessage.AllocSysString(); return S_OK; } //--------------------------------------------------------------------- long BaseLevelGetter::GetCurrentLevel() { TRACE("Derived classes should override!"); return -1; } //--------------------------------------------------------------------- long BaseLevelGetter::GetHighestSafeLevel() { TRACE("Derived classes should override!"); return -1; } //--------------------------------------------------------------------- long BaseLevelGetter::GetLowestSafeLevel() { TRACE("Derived classes should override!"); return -1; } //--------------------------------------------------------------------- CString BaseLevelGetter::GetMessage() { TRACE("Derived classes should override!"); return "BaseLevelGetter"; } Скомпилируйте и слинкуйте приложение.


Как только DLL создана, скопируйте ее в каталог Windows\System (\WINNT\System32 для Windows NT).

Важно: Поскольку мы будем использовать интерфейс ILevelGetter из BaseLevelGetter, не забудьте после помещения этой DLL в соответствующий каталог зарегистрировать ее с помощью RegSvr32. Если бы мы использовали BaseLevelGetter как абстрактный базовый класс (т.е. виртуальные функции BaseLevelGetter должны были бы быть переопределены) и при этом, возможно, удалось бы избежать ошибок в реализации, тогда не было бы необходимости регистрировать COM объект с помощью RegSvr32. Чтобы построить COM объект, который реализует интерфейс ILevelGetter, но не требует переопределения всех методов, мы создаем COM DLL точно так же, как BaseLevelGetterDLL: мы создаем MFC AppWizard DLL, которая поддерживает automation, и добавляем класс, являющийся потомком CCmdTarget. Пример содержит проект HotTubLevelGetterDLL с классом HotTubLevelGetter - потомком от CmdTarget, который создается через диалог New Class в Class Wizard, как показано ниже.



Далее добавляем BaseLevelGetterDLL в путь include, указав его как каталог Additional Include на закладке Project | Settings | C/C++ , как показано ниже.



И линкуем BaseLevelGetterDLL.lib, добавляя ее как Library Module на закладке Project | Settings | Link.



Завершив все установки проекта, выполним следующие пять шагов для полного завершения создания COM DLL plug-in.

1. Открыть HotTubLevelGetter.H и заменить все instances из CCmdTarget на BaseLevelGetter (существует единственная instance CCmdTarget в HotTubLevelGetter.H).



2. Добавить BaseLevelGetter.H как include:

#include <BaseLevelGetter.h> class HotTubLevelGetter : public BaseLevelGetter { 3. Переписать виртуальные функции BaseLevelGetter как это требуется. В примере объявляются две следующие виртуальные функции:

virtual CString GetMessage( ) { return "HotTubLevelGetter"; } virtual long GetCurrentLevel( ) { return -2; } 4. Открыть HotTubLevelGetter.CPP и заменить все instances из CCmdTarget на BaseLevelGetter (существует пять instances CCmdTarget в HotTubLevelGetter.CPP).



5. Выполнить компиляцию и линковку. Не забудьте зарегистрировать вашу COM DLL через RegSvr32.

Прежде чем продемонстрировать работу COM plug-in на клиенте, давайте посмотрим что мы построили. Классы BaseLevelGetter и HotTubLevelGetter оба являются потомками CCmdTarget. Когда мы создавали HotTubLevelGetter, мы указали Class Wizard наследовать его от CCmdTarget. Напомним, что каждый класс, созданный Class Wizard как прямой потомок CCmdTarget, поддерживает собственные CLSID и интерфейс IDispatch. Когда мы изменяем базовый класс HotTubLevelGetter с CCmdTarget на BaseLevelGetter, HotTubLevelGetter наследует виртуальные методы BaseLevelGetter.

Когда клиенту необходим доступ к HotTubLevelGetter, он выполняет обычный CoCreateInstance(...) - передавая CLSID HotTubLevelGetter и IID_ILevelGetter, и вызывая методы ILevelGetter. Когда выполняется какой-либо метод, например, GetCurrentLevel, METHOD_PROLOGUE_EX_ берет значение pThis из offset table, и pThis действительно указывает на instance HotTubLevelGetter. То же вещь происходит, когда мы используем m_pOwner (он также указывает на instance HotTubLevelGetter); это немного легче для понимания из-за того, что мы можем наблюдать как выполняется метод m_xLevelGetter.SetOwner( this ). Давайте посмотрим на клиентское приложение и установим некоторые точки прерывания.

Откройте LevelViewer в папке LevelViewer2. Этот проект почти идентичен первому варианту LevelViewer. OnFish позиционирован в BaseLevelGetter, а OnGas - в HotTubLevelGetter, как показано далее.

//----------------------------------------------------------- void CLevelViewerDlg::OnFish() //mapped to BaseLevelGetter { m_sLastCalled = _T("CheckedFish"); CLSID clsid; HRESULT hRes = AfxGetClassIDFromString("BaseLevelGetterDLL.BaseLevelGetter", &clsid); if(SUCCEEDED(hRes)) SetNewData(clsid, IID_ILevelGetter); } //------------------------------------------------------------ void CLevelViewerDlg::OnGas() //mapped to HotTubLevelGetter { m_sLastCalled = _T("CheckedGas"); CLSID clsid; HRESULT hRes = AfxGetClassIDFromString("HotTubLevelGetterDLL.HotTubLevelGetter", &clsid); if(SUCCEEDED(hRes)) SetNewData(clsid, IID_ILevelGetter); } Обе функции вызывают SetNewData, передавая CLSID, созданный Class Wizard, и IID_ILevelGetter, описанный в ILevelGetter.H и включенный вLevelViewerDlg.H.



Замечание: на закладке C++ , категория Preprocessor, добавьте ..\BaseLevelGetterDLL в качестве дополнительного include каталога.

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



Когда выполнение остановится на точке прерывания, воспользуйтесь режимом "Step Into" (по клавише F8 или F11 в зависимости от установленной системы) и пошаговым проходом (F10) дойдите до строки с указателем объекта pThis или m_pOwner. Проверьте значение. В зависимости от того, подключил таймер HotTubLevelGetter или BaseLevelGetter, pThis (или m_pOnwer) будут указывать на правильный объект.





Как вы видели, COM plug-ins - весьма мощный метод разработки приложений, который может использоваться в реальных ситуациях, например, такой как описана ниже.

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

Как разработчик COM на C++, вы понимаете потребность в заменяемых компонентах, которые поддерживают полиморфизм. Рассмотрим следующее: интерфейс IBasePlan, входящий в класс BasePlan, реализует 100 методов интерфейса. Требования плана ABC включают модификацию реализации 50 методов в интерфейсе IBasePlan. Требования плана XYZ включают модификацию реализации 51 метода в интерфейсе IBasePlan, но 50 из них точно такие же, как для плана ABC.


Вместо полного определения реализации для каждого COM объекта, вы назначаете в BasePlan 100 виртуальных функций члена C++ класса, по одной для каждого метода в интерфейсе IBasePlan , как вышеприведенном примере.

Поскольку у вас есть ассоциированные виртуальные функции в классе BasePlan, иерархия класса для плана XYZ такова:

1. class BASE_PLAN_EXPORT BasePlan : public CCmdTarget

Реализует IBasePlan, 100 методов интерфейса и 100 ассоциированных виртуальных функций члена C++ класса.

2. class ABC_PLAN_EXPORT ABCPlan : public BasePlan

Наследуется от BasePlan, использует 50 виртуальных функций члена C++ класса в BasePlan и замещает 50 виртуальных функций BasePlan.

3. class XYZPlan : public ABCPlan

Наследуется от ABCPlan, использует 49 виртуальных функций члена C++ класса в BasePlan, использует 50 виртуальных функций члена C++ класса в ABCPlan и замещает 1 виртуальную функцию BasePlan.

Каждый компонент создается как отдельный binary и COM объект. Каждый из них имеет отдельный CLSID и, благодаря структуре наследования, реализует интерфейс IBasePlan. Применяя AppWizard и Class Wizard, вы можете завершить реализацию плана XYZ в течение нескольких минут без какого-либо затрагивания COM компонентов базового класса. Все библиотеки COM DLL размещаются на том же компьютере, и если вы используете компонентные категории или другие аналогичные методы регистрации, приложение клиента найдет план XYZ, как только он будет зарегистрирован RegSvr32.

Чтение файлов с помощью FSO

Для чтения данных из текстового файла используйте методы Read, ReadLine или ReadAll объекта TextStream:

Задача	Метод
Чтение определенного числа символов из файла	Read
Чтение строки целиком (но не включая символ новой строки)	ReadLine
Чтение текстового файла целиком	ReadAll

Если вы используете метод Read или ReadLine и хотите перейти к определенной части файла, воспользуйтесь методами Skip или SkipLine для пропуска определенного числа символов (или, соответственно, строк).

Полученный в результате использования этих методов текст может быть сохранен в символьной переменной и обрабатываться функциями Left, Right и Mid. Обратите внимание, что константа vbNewLine содержит символ или символы (в зависимости от операционной системы) перевода курсора на следующую строку (возврат каретки). Некоторые символьные переменные могут содержать в конце эти непечатаемые символы. Sub Read_Files() Dim fso As New FileSystemObject, txtfile Dim fil1 As File, ts As TextStream Set txtfile = fso.CreateTextFile("c:\testfile.txt", True) MsgBox "Writing file" ' Запись линии Set fil1 = fso.GetFile("c:\testfile.txt") Set ts = fil1.OpenAsTextStream(ForWriting) ts.Write "Hello World" ts.Close ' Чтение содержания файла Set ts = fil1.OpenAsTextStream(ForReading) s = ts.ReadLine MsgBox s ts.Close End Sub

Что мы сравниваем?

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

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

Целью этой статьи является сравнение C++/Qt и Java/AWT/Swing. Чтобы это сделать наиболее точно, мы сначала сравним языки программирования, то есть C++ и Java, а потом две GUI-библиотеки: Qt для C++ и AWT/Swing для Java.

Что потребуется

Для построения примеров вам потребуется Microsoft Visual C++(r) 5.0. Нет необходимости в десятилетнем опыте по Windows(r) и C, достаточно некоторого знакомства с Visual C++, MFC, наследованием и полиморфизмом. Примеры будут построены и выполнены под Windows NT(r) или Windows 95. Мы будем использовать OLE/COM Object Viewer - удобную утилиту, поставляемую вместе с Visual C++ 5.0 и Visual Basic(r) 5.0, а также доступную для download на http://www.microsoft.com/oledev.

Что предоставляют сценарии?

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

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

Поддержка сценариев - проверенное и широко используемое решение: от Microsoft Office VBA до Emacs Lisp. Некоторые клиенты Qt уже предлагают поддержку сценариев в своих приложениях на базе продуктов третьих фирм, поэтому потребность в поддержке сценариев для приложений Qt может быть удовлетворена Qt Script.

Что такое Baikonur Server.

Baikonur - програмный продукт компании Epsylon Technologies, предназначенный для быстрой разработки приложений, ориентированных на использование Web-браузеров в качестве клиентских мест для доступа к базам данных во внутрикорпоративных сетях Intranet, а также Internet. Собственно Baikonur из себя представляет сервер приложений, частным случаем которого является Web-сервер приложений, в состав поставки входят еще и дополнительные библиотеки для различных средств программирования, в частности, для Borland Delphi (для C++, Java, JavaScript - в старших версиях).

Baikonur Server предназначен для построения как очень простых, так и очень сложных Internet/Intranet систем на платформе Windows NT. Самое простое, что может делать Baikonur Server - это служить в качестве обыкновенного Web сервера, имеющего дело со стандартными HTML-документами. Однако, в отличие от стандартного Web-сервера, основные ресурсы, которыми оперирует Baikonur-сервер - это информационные потоки и задачи. В результате при помощи сервера Baikonur появляется возможность элегантного построения функционально весьма сложных и разветвленных информационных систем.

Что такое СММ

CMM (Capability Maturity Model) — модель зрелости процессов создания ПО, или эволюционная модель развития способности компании разрабатывать качественное программное обеспечение.

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

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

В зрелой организации, напротив, имеются четко определенные процедуры создания программных продуктов и отработанные механизмы управления проектами. Все процедуры и механизмы по мере необходимости уточняются и совершенствуются в пилотных проектах. Оценки времени и стоимости выполнения работ основываются на накопленном опыте и достаточно точны. Наконец, в компании существуют стандарты на процессы разработки, тестирования и внедрения, а также правила оформления конечного программного кода, компонентов, интерфейсов и т.д. Все это составляет инфраструктуру и корпоративную культуру, поддерживающую процесс разработки программного обеспечения.
Технология выпуска будет лишь незначительно меняться от проекта к проекту на основании абсолютно стабильных и проверенных подходов. CMM определяет пять уровней зрелости организаций. В результате аттестации компании присваивается определенный уровень, который в дальнейшем может повышаться или понижаться. Следует отметить, что каждый следующий уровень включает в себя все ключевые характеристики предыдущих. (1) Начальный уровень (initial level) — это основной стандарт. К данному уровню, как правило, относится любая компания, которой удалось получить заказ, разработать и передать заказчику программный продукт. Предприятия первого уровня не отличаются стабильностью разработок. Как правило, успех одного проекта не гарантирует успешность следующего. Для компаний данного уровня свойственны неравномерность процесса разработки — наличие авралов в работе. К этой категории можно отнести любую компанию, которая хоть как-то исполняет взятые на себя обязательства. (2) Повторяемый уровень (repeatable level). Данному уровню соответствуют предприятия, обладающие определенными технологиями управления проектами. Планирование и управление в большинстве случаев основывается на имеющемся опыте. Как правило, в компании данного уровня уже выработаны внутренние стандарты и организованы специальные группы проверки качества. (3) Определенный уровень (defined level). Уровень характеризуется наличием формального подхода к управлению (то есть описаны все типичные действия, необходимые для многократного повторения: роли участников, форматы документов, производимые действия и пр.). Для создания и поддержания подобного стандарта в актуальном состоянии в организации уже подготовлена специальная группа. Компания постоянно проводит специальные тренинги для повышения профессионального уровня своих сотрудников. Начиная с этого уровня организация перестает зависеть от личностных качеств конкретных разработчиков и не имеет тенденции скатываться на нижестоящие уровни. Абстрагирование от разработчиков обусловлено продуманным механизмом постановки задач и контроля исполнения. (4) Управляемый уровень (managed level).


Уровень, при котором устанавливаются количественные показатели качества. (5) Оптимизирующий уровень (optimizing level) характеризуется тем, что мероприятия по совершенствованию рассчитаны не только на существующие процессы, но и на оценку эффективности ввода новых технологий. Основной задачей всей организации на этом уровне является постоянное совершенствование существующих процессов, которое в идеале призвано способствовать предупреждению возможных ошибок или дефектов. Применяется механизм повторного использования компонентов от проекта к проекту, например шаблоны отчетов, форматы требований. Из градации уровней видно, что технологические требования сохраняются только до 3-го уровня, далее же в основном следуют требования к административному управлению. То есть уровни 4 и 5 по большей части управленческие и для их достижения важно не только выпустить программный продукт, но и проанализировать ход проекта, а также построить планы на будущий проект, основываясь на текущих шаблонах. Применение данных подходов должно обеспечить планомерно-плавное улучшение используемых процессов. Пока в России знают только аббревиатуру СММ, но не представляют себе, каким образом можно добиться качественного скачка. И дело не только в том, что неизвестно направление этого скачка, а в том, что каждой отдельно взятой компании довольно трудно выстроить свои процессы под требования CMM самостоятельно, без внешнего вмешательства. А зачем изобретать велосипед? Не проще ли взять готовый набор решений оптимизации (например, ), внедрить его (здесь уже можно и своими силами обойтись), получив готовый набор решений для качественного построения ПО, а уж затем приглашать специалистов и аттестоваться на определенный уровень? Как мы уже не раз упоминали в данной статье, Rational гарантирует получение 3-го уровня СММ. На Западе сегодня уже широко используют для оптимизации процесса выпуска ПО технологии компании . Причин тому несколько: во-первых, Rational Software — практически единственная компания, которая четко описала весь производственный цикл по выпуску программного обеспечения (), определила все возможные виды документов, сопровождающие проект, строго расписала роли (входные/выходные документы, шаблоны документов и пр.) каждого участника проекта.Во-вторых, компания создала специальное программное обеспечение для качественного исполнения как каждого этапа в отдельности, так и всего проекта в целом. Важно и то, что Rational посредством RUP предлагает перейти от программирования как искусства к программированию как к науке, где все понятно и прозрачно благодаря научному подходу к разработке. По некоторым оценкам западных аналитиков, соотношение возврата капитала до и после внедрения качественных процессов варьируется от 5:1 до 8:1.

Что такое SoDA?

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

По задаваемым пользователем шаблонам SoDA "компилирует" документацию, собирая в один документ текстовые и графические данные из различных источников, например из моделей, созданных в . Далее пользователь может отредактировать полученный документ с помощью Microsoft Word или Adobe FrameMaker. Как и любая система отчетности, SoDA базируется на тех данных, которые получает из сторонних программ.

SoDA поддерживает всю линейку продуктов Rational Software, позволяя создавать сложные комбинированные отчеты на основе выходных данных программ состава Rational Suite. Плюс ко всему SoDA имеет доступ к данным из Microsoft Project.

Основные возможности системы: Автоматическое извлечение информации из файлов, созданных различными инструментальными средствами. SoDA "понимает" структуру информации, хранимой теми системами, с которыми она интегрирована, а сама информация доступна ей через API этих систем. Сохранение при "перекомпиляции" текста и графики, введенных пользователем вручную в текстовом процессоре. Если пользователь, скажем, в Microsoft Word, добавил какие-нибудь комментарии или иллюстрации в сгенерированный с помощью SoDA документ, то при перестраивании данного документа SoDA его не испортит. Настройка шаблонов, по которым генерируется документация. С помощью удобного визуального редактора можно создавать шаблоны, соответствующие всевозможным внешним стандартам (таким как ISO 9000, IEEE, MIL-STD-498 и DOD-STD-2167A) или внутренним стандартам компании. Синхронизация с источниками и проверка актуальности документации. Связи между отдельными частями документации и исходными файлами запоминаются. Поэтому, во-первых, SoDA может отслеживать изменения, происходящие с источниками, на основе которых была в последний раз "скомпилирована" документация, а во-вторых, пользователь может из любой секции документа быстро получить доступ к источникам, информация из которых используется в этой секции. Частичная "перекомпиляция" больших документов.
Проектная документация к масштабным программным системам может достигать гигантских объемов. Поэтому в SoDA предусмотрена возможность "перекомпилировать" только такие части документации, которые действительно утратили актуальность. Сбор информации из многочисленных и разнородных источников. Документирование всех этапов работы над проектом. Проверка соблюдения требований, предъявляемых к разрабатываемой системе. SoDA позволяет сформировать таблицы, из которых можно понять, насколько полученные результаты соответствуют требованиям, определенным на начальных этапах проектирования. Поддержка русифицированных шаблонов и отчетов. Из описания следует, что SoDA может работать в двух режимах. Первый - генерация отчета по данным на основе существующего шаблона, который, в свою очередь, строго следует стандартам RUP и ISO. Второй - генерация отчета на основе собственного шаблона компании, оформленного произвольным образом в соответствии с ее традициями. Давайте немного остановимся на первом режиме, когда за основу берется стандартный шаблон. Известно, что компания Rational не только полностью описала процесс выпуска программного обеспечения, но и создала программные средства для каждого этапа этого процесса. Следовательно, каждый продукт сохраняет данные, а SoDA по ним строит ("компилирует") отчет. Если внимательнее присмотреться к этапам разработки приложений с точки зрения Rational, получится следующий список: Бизнес-моделирование. Определение требований. Анализ и проектирование. Тестирование. Реализация. Внедрение. Естественно, все этапы детально описаны, и на каждом из них предполагается получение документа строго определенного образца (согласно RUP), после того как соответствующие данные были обработаны той или иной программой из набора средств Rational. Так, на первом этапе при помощи SoDA можно получить документы "Оценка организации заказчика", "Словарь терминов предметной области", "Коммерческое предложение", "Бизнес-правила" и т.д.


На втором этапе можно получить документы "Спецификация на программную систему", "Спецификация на функции системы". Каждый из этих отчетов будет соответствовать RUP, а форма изложения - отражать требования ISO. В дальнейшем такой документ можно согласовать с заказчиком. Обратите внимание: первый этап называется "Бизнес-моделирование", что подразумевает использование на данном этапе средств визуального проектирования. Согласно технологии RUP, этим средством является Rational Rose, позволяющее на основе различных диаграмм получить полную бизнес-модель предприятия и модель проектируемой системы. Соответственно, опять же по технологии RUP, на этапе проектирования аналитик или проектировщик не только рисует модель, создавая определенные связи между диаграммами, но и комментирует каждое свое движение на специальных полях либо подключает уже имеющиеся документы к модели. Разумеется, в результате получается отличная модель, полностью описывающая бизнес-процессы и программную систему. Правда, понятной она будет только узкому кругу лиц, представляющих себе полную картину сделанного. Заказчик же, к сожалению, зачастую плохо ориентируется в мире диаграмм... Вот и настает черед SoDA! Из меню Rose запускается составитель отчетов, пользователь выбирает тип отчета и через 1-5 минут получает готовый документ с разметками, комментариями и фрагментами моделей в формате Word. При этом все элементы документа представляют собой внедренные объекты, а это значит, что изменения, внесенные в модель, автоматически отражаются в документе. В табл. 1 показано, с какими программными продуктами работает SoDA и какие отчеты может создавать. Для тех, кто не знаком с терминологией, в табл. 2 даны расшифровка и описание типов диаграмм в Rose. Таблица 1

ПродуктОтчетХарактеристика/комментарий

	Version	Отчет по версии одного элемента из репозитария ClearCase
	Vob	Отчет по состянию всех репозитариев в целом
	Element	Отчет по свойствам элементов
	Region	Отчет по всем используемым в проекте регионам
	All Defect in This State	Вывод всех дефектов, находящихся в указанном состоянии
	DocsReqts.doc	Отчет по требованиям и документам проекта
	Reqts.doc	Отчет по требованиям
	ReqtsAttrs.doc	Отчет по требованиям с выводом атрибутов требований
	ReqtsTraces.doc	Отчет по требованиям с использованием трассирования
	BuildDetail.doc	Детальный отчет по тестированию с выводом ошибок, состояний и владельцев
	Build Summary.doc	Упрощенная версия вышеуказанного отчета
	ComputerDetail.doc	Отчет по характеристикам компьютеров, на которых проводилось тестирование, в том числе IP-адрес машины, на которой проигрывались тесты, наименование операционной системы
	ScriptDetail.doc	Отчет по скриптам тестирования, в том числе путь к файлу, имя его владельца
	TestDocDetail.doc	Отчет по тестовым документам
	498idd.doc	Отчет по списку документов, дизайну интерфейса, трассировке требований
	498irs.doc	Список документов, требования к интерфейсу, квалификационный лист, трассировка требований
	498ocd.doc	Список документов, требования к продукту, квалификационный лист, трассировка требований
	498sdd.doc	CSCI-заключение, дизайн, трассировка требований
	Classes.doc	Отчет по всем классам в системе. Отчет следует иерархии и показывает связи
RUP	Actor Report.doc	Простой и быстрый отчет по характеристикам, отношениям и диаграммам состояний модели

Таблица 2 АббревиатураРасшифровкаОписание

IDD	Interface Design Description	Описание интерфейса системы
IRS	Interface Requirements Specification	Спецификации на требования интерфейса
OCD	Operational Concept Description	Операционное концептуальное описание
SDD	Software Design Description	Описание программного дизайна
SDP	Software Development Plan	План разработки
SRS	Software Requirements Specification	Спецификации на требования
SSS	System/Subsystem Specification	Спецификации на систему

Еще раз внимательно посмотрите на табл. 1. Хотя я не стал описывать все виды стандартных отчетов, представленного списка с лихвой должно хватить для правильной оценки возможностей продукта. К слову сказать, все вышеприведенные форматы отчетов помогут аналитикам и проектировщикам точно договориться с заказчиком о том, какую систему он хочет получить. Тестировщики же смогут генерировать отчеты по всем ошибкам (дефектам) и представлять их в удобной форме. Не остались без внимания и разработчики. Для них будет полезным отчет по классам, когда в наглядном виде можно получить список классов с иерархией и описанием всех атрибутов и методов, не выходя из среды разработки. В качестве одного дополнительного (я бы даже сказал - комплексного) штриха можно с помощью только Rose и SoDA сделать отчет по классам той системы, которая УЖЕ написана и скомпилирована! Rose имеет механизм так называемого обратного проектирования, когда исходный код превращается в модель Rose (преобразуясь в UML-нотацию). При обратном проектировании учитываются все составляющие классов, а также комментарии, которыми они снабжались, вследствие чего на выходе получается полная модель всех классов (с иерархией). После этого достаточно будет просто пропустить модель через систему генерации отчетов - и вы получите полноценный документ, описывающий систему классов программного продукта по всем мыслимым и немыслимым стандартам и правилам! Понятно, что даже с помощью SoDA трудно получить стопроцентно читабельный отчет для заказчика, но свои процентов восемьдесят такого отчета SoDA честно сгенерирует.Остальную правку можно возложить на плечи специалиста, способного придать отчету (на этом этапе уже - документу) литературный вид. Вернувшись к основе ведения проектов - RUP, можно выделить 10 важнейших моментов, когда без системы отчетности невозможно обойтись. Это бывает в тех случаях, когда необходимо: Выработать концепцию будущего приложения (документы, роли участников). Выработать план. Идентифицировать и смягчить риски. Устанавливать и отслеживать проблемы. Проанализировать прецеденты. Разработать компонентную архитектуру. Создавать и тестировать продукт. Проверять и оценивать результаты. Управлять изменениями и контролировать их. Обеспечивать ввод в коммерческую эксплуатацию и поддержку пользователей.

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

Delphi 3 предоставляет богатый и исчерпывающий набор экспертов для создания кода, позволяющий упростить создание приложений начинающим и опытнвм программистам: CodeTemplates Wizard для упрощения создания кода. CodeCompletion Wizard для упрощения создания синтаксически правильных конструкций. CodeParameter Wizard для вывода списка параметров процедур, а также свойств, событий и методов компонентов. CodeFind Wizard для навигации и поиска в исходных текстах Delphi. ToolTip Expression Evaluation быстрой и простой отладки. DLL Debugging экономит время при создании и отладке сложных приложений.

Configuration and Change Management с точки зрения CMM и RUP

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

Основная задача конфигурационного управления ПО — установление и поддержание целостности проектных данных на протяжении всего жизненного цикла развития проекта.

Конфигурационное управление участвует в идентификации конфигурации выпускаемого ПО (то есть в выборе программного продукта и в его описании) в срок. SCM (Source Configuration Management) обеспечивает систематизированное управление изменениями конфигурации, поддержание их целостности и актуальности на протяжении всего жизненного цикла проекта. Результаты разработки, которые поставляются клиенту, находятся под управлением конфигурационной системы. Также под ее управлением находятся все документы и результаты компиляции (документы требований, отчеты, исходные данные на любом языке программирования).

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

Все данные из ключевых областей процесса (Key Process Area) охватывают возможные методы исполнения функции конфигурационного управления. В СММ все качественные требования представляются именно как KPA. Каждый из этих методов четко описывает определенный участок с формализованными требованиями, а RUP способен привести этот участок в соответствие означенному требованию.

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

Ниже приведены основные постулаты конфигурационного управления по CMM (дословный перевод требований): Любые действия по направлению конфигурационного управления заранее запланированы Любые программные работы идентифицированы, управляются и являются общедоступными Любые изменения в продукте являются управляемыми Заинтересованные группы и индивидуумы постоянно информируются о состоянии развития проекта.

Для реализации тех или иных действий, связанных с конфигурационным управлением, в RUP имеются несколько взаимосвязанных программных продуктов: (средство версионного управления), (средство организации конфигурационного управления и управления изменениями).
Также на некоторых этапах удобно использовать систему генерации проектной документации для получения отчетов установленного образца. Для объединения регионально удаленных команд применяется приложение . описывает все этапы разработки программного обеспечения, включая конфигурационое управление. Содержит описание ролей участников проекта, шаблоны входных/выходных документов, набор рекомендаций для каждой проектной стадии. На рис. 1 изображены потоки работ и фазы по RUP. Обратите внимание на конфигурационное управление. Из диаграммы видно, что конфигурационное управление сопровождает все этапы и фазы проекта и вступает в действие с момента создания аналитиком бизнес-модели и до передачи готового программного продукта заказчику.

Рис. 1 Как говорилось выше, RUP описывает, каким образом следует построить конфигурационное управление. Если посмотреть на топик конфигурационного управления из RUP, то нашему взору предстанет диаграмма разработки проекта с точки зрения RUP (рис. 2). Рис. 1 Данная блок-схема четко описывает этапы конфигурационного управления (шаги, которые необходимо пройти, роли участников...). Схема представляет собой верхний уровень описания. Поскольку вложенность уровней в энциклопедии RUP большая, навигация здесь осуществляется выбором соответствующих поддиаграмм. Каждая последующая диаграмма содержит развернутые сведения по выбранной теме (подробное описание всех шагов, необходимых для успешного осуществления этапа). На рис. 3 в развернутом виде показан первый шаг (планирование конфигурационного управления). На нем представлены роли сотрудников (менеджер по конфигурации и менеджер по управлению изменениями), их действия и результирующий документ (конфигурационный план). Подобном образом описываются все этапы конфигурационного управления (более подробно о них будет рассказано в следующей статье). Рис. 3 Представленный ниже список показывает в структурном виде всех участников конфигурационного управления, их действия и выходные данные. Установка плана управления конфигурацией Участники и роли: Менеджер конфигурации установление конфигурационной политики создание конфигурационного плана Менеджер контроля изменений установление процесса контроля над версиями Артефакты: конфигурационный план Создание проекта и среды Участники и роли: Менеджер конфигурации установление среды конфигурации Интегратор создание интегрирующего пространства Артефакты: конфигурационный план (дополнения), модель внедрения, настройка проектного репозитария, разработка рабочего пространства Изменение и представления конфигурационных элементов Участники и роли: Интегратор создание базовых линий Остальные создание рабочего пространства создание изменений Обновление рабочего пространства Артефакты: наряд на работу, модификация пространства Управление базовыми линиями и релизами Участники и роли: Интегратор Создание базовых линий Выделение базовых линий Менеджер конфигурации Создание единицы развертывания Артефакты: спецификации материалов, репозитарий, единицы развертывания Составление отчетов по конфигурационному пространству Участники и роли: Менеджер конфигурации генерирование отчета по состоянию подготовка конфигурационного аудита Артефакты: проектные единицы измерения, аудит репозитария (отчет) Управление запросами на изменение Участники и роли: Менеджер контроля изменений просмотр запросов на изменение поиск дублей в запросах Интегратор проверка изменения в билде Остальные представление запросов на изменение обновление запросов на изменение Артефакты: запросы на изменения Под термином «артефакт» здесь подразумевается получение выходного документа. Список, как можно видеть, достаточно полно описывает всю деятельность, связанную с конфигурационным управлением.


В RUP можно получить гораздо более развернутый материал по каждому из приведенных элементов списка. Для дальнейшей иллюстрации возможностей и стоит привести шаблон документа, который заполняется в первую очередь, — это план конфигурационного управления. Данный план является основным документом, регламентирующим все дальнейшие проектные действия, связанные с конфигурационным управлением. В плане необходимо отмечать то, каким образом будет достигаться та или иная цель: ведь одну и ту же задачу можно решать различными способами, но, однажды выбрав определенное решение, не рекомендуется изменять его в процессе работы. Конфигурационный план: Введение Цели Область охвата Определения и сокращения Ссылки Краткий обзор SCM (Software Configuration Management) Организация, ответственность и интерфейс Инструментальные средства, среда и инфраструктура Идентификация элементов конфигурации Идентификация методов Проектные базовые линии Контроль изменений и конфигураций Процесс запроса изменений Группа управления изменениями Учет конфигурационного состояния Способы проектного хранения и процесс выпуска релизов Отчеты и аудит Основные производственные задания Обучение и ресурсы Подрядчик и услуги продавца Естественно, это шаблон, который предстоит заполнять данными в соответствии с рекомендациями (каждый пункт шаблона в RUP можно посмотреть в более развернутом виде). В заключение следует обратить внимание на соответствие ключей CMM их привязке к :

Crystal Reports Print Engine API

Модуль Crystal Reports Print Engine API предназначен для доступа к отчетам из приложений Windows. Доступ реализован через вызовы функций CRPE.DLL / CRPE32.DLL.

Первый шаг к использованию функций - их объявление. Функции могут быть объявлены как глобально, так и локально внутри использующей их секции кода. Каждая функция может быть объявлена отдельно, но имеется и возможность объявления всех функций сразу. Например, функция PEStartPrintJob может быть объявлена в Visual Basic как: Declare Function PEStartPrintJob Lib "CRPE.DLL" (ByVal printJob As Integer, ByVal waitUntilDone As Integer) As Integer

Для объявления всех функций сразу необходимо воспользоваться файлами заголовков, входящих в состав Crystal Reports. Например, для Visual Basic имя такого файла - GLOBAL.BAS, для С - CRPE.H.

После объявления функций для начала работы с отчетом необходимо вызвать функцию PEOpenEngine, которая возвращает значение TRUE (1), если вызов прошел успешно, либо FALSE(0), если CRPE.DLL / CRPE32.DLL загрузить не удалось. Функция PEOpenEngine не имеет параметров и служит только для обработки в программном коде факта успешного подключения Print Engine.

Для печати отчета используется функция PEPrintReport. Синтаксис функции приведен ниже: PEPrintReport("reportName", toPrinter, toWindow, "windowTitle", leftCoordinate, topCoordinate, windowWidth, windowHeight, windowStyle, parentWindow)

где: reportName - полное имя (включая путь) отчета. Можно использовать строковую переменную. toPrinter - TRUE (1), если отчет выводится на принтер и FALSE(0), если в окно Windows. Для выбора принтера следует использовать функцию PESelectPrinter. toWindow - если значение TRUE (1), отчет выводится в окно предварительного просмотра. При этом toPrinter должен быть равен 0. windowTitle - заголовок отчета в окне просмотра. Можно использовать строковую переменную. leftCoordinate - левая координата окна просмотра. topCoordinate -верхняя координата окна просмотра. windowWidth - ширина окна просмотра в пикселах. windowHeight - высота окна просмотра в пикселах. windowStyle - установка стиля (как определено в "Windows.h"). parentWindow - указатель родительского окна.
Например, если два последних параметра равны 0, Crystal Reports использует следующий стиль: (WS_VISIBLE | WS_THICKFRAME | WS_SYSMENU | WS_MAXIMIZEBOX | WS_MINIMIZEBOX) Функции Report Engine позволяют не только просматривать отчет в окне приложения, но и управлять некоторыми опциями отчета. Например, можно изменить порядок сортировки данных отчета, модифицировать формулы выборки и группировки, модифицировать формулы отчета и т.д. Прежде чем использовать функции, управляющие опциями отчета, необходимо вызвать шесть основных функций: PEOpenEngine - начало работы с Print Engine (загрузка CRPE.DLL/ CRPE32.DLL). PEOpenPrintJob - подготовка процесса печати. Возвращаемое значение функции - указатель процесса печати, который будет использован другими функциями Print Engine. PEOutputToPrinter , PEOutputToWindow или PEExportTo - подготовка вывода отчета на принтер, в окно просмотра или экспорта отчета соответственно. PEStartPrintJob - запуск печати. PEClosePrintJob - закрытие сеанса печати. PECloseEngine - закрытие сеанса работы Print Engine (CRPE.DLL / CRPE32.DLL выгружается). Совместно с обязательным набором из шести функций можно использовать другие функции управления отчетом. В качестве примера можно рассмотреть функцию, устанавливающую формулу выборки - PESetSelectionFormula. Ее синтаксис: PESetSelectionFormula (Print Job Handle, Formula String), где Print Job Handle - указатель процесса печати, Formula String - текст формулы Crystal Reports. Всего Crystal Reports 6.0 содержит 125 функций Print Engine - функции для управления данными, процессами печати, выводом в окно просмотра, принтером, экспортом, функции управления сортировкой , выборкой и группировкой, управлением форматом печати и т.д. При помощи функций Print Engine можно просматривать отчет, менять его параметры, но нельзя менять дизайн отчета. Это утверждение относится к любым приложениям, написанным на любом языке программирования.

DCOM против CORBA

И DCOM компании Microsoft, и CORBA консорциума Object Management Group поддерживают распределенные вычисления. Однако, похоже, две эти технологии развиваются в разных направлениях.

DCOMCORBA

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

Delphi_cs.shtml

Cоздание приложений для ORACLE с помощью Delphi Client/Server

Наталия Елманова, Центр Информационных Технологий

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

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

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

Современные средства быстрой разработки Windows-приложений, или так называемые RAD-средства (RAD расшифровывается как Rapid Application Development) обладают в той или иной степени почти всеми возможностями создания в приложениях подобных интерфейсных элементов.
Многие из них позволяют осуществлять доступ с базам данных, в том числе и к серверным БД. Однако Borland Delphi (как версия 1.0, так и версия 2.0), на взгляд автора, является в этом отношении наиболее наиболее простым и удобным в использовании средством. Причины этого заключаются в следующем: создание пользовательского интерфейса происходит практически без написания кода; поддерживаются все стандартные интерфейсные элементы - окна просмотра, списки, выключатели, радиокнопки и радиогруппы, полосы прокрутки, меню (как оконные, так и привязанные к конкретным элементам), а также большое количество иных полезных интерфейсных элементов - блокнотов а-ля Word, прогресс-баров и т.д.; легко создаются контекстно-зависимая справка, ярлычки с подсказками, панели состояний, инструментальные панели; имеется большая библиотека шаблонов форм и приложений, которую можно пополнять своими шаблонами; доступ к данным, будь то плоские таблицы или серверные БД типа ORACLE, совершенно однотипен, а описание конкретных источников данных можно вынести за пределы приложения в специальный файл конфигурации бибилиотеки BDE, обеспечивающей универсальную работу с разнородными данными, вплоть до гетерогенных запросов (это могут сделать далеко не все RAD-средства); в процессе разработки можно пользоваться реальными данными, отображаемыми в соответствующих интерфейсных элементах; приложения отличаются высокой производительностью, так как они являются полностью скомпилированными выполняемыми модулями (а большинство используемых RAD-средств использует интерпретируемый код), а, кроме того, язык программирования Object Pascal, используемый в Delphi, отличается жесткой типизацией переменных, что также положительно сказывается на производительности; отладка приложений очень удобна за счет того, что, во-первых , компилятор Pascal является очень быстрым, во-вторых, поддерживается инкрементная компиляция, в-третьих, в среду разработки встроен удобный и гибкий отладчик; средства работы с графикой так же удобны, как и в Pascal (для средств разработки приложений, работающих с БД, это большая редкость); поддерживаются элементы VBX (в первой версии) и OCX (во второй версии); на сегодняшний день на рынке имеется также большое количество дополнительных компонент для Delphi, созданных на самой Delphi, и их создание является несложным процессом; имеется интерфейс со средством контроля версий Intersolv PVCS, облегчающий групповую разработку крупных проектов; имеются удобные средства генерации отчетов, при этом можно использовать и генераторы отчетов сторонних разработчиков (например, Crystal Reports); среда разработки создана с учетом последних достижений в области эргономики - никаких лишних движений мышью, или лишних нажатий на клавиши (рис.1). Как создаются приложения на Delphi? Это очень просто.


Вы создаете новый проект (или используете готовый шаблон), помещаете на форму интерфейсные элементы, компоненты для доступа к данным, связываете все это между собой в инспекторе объектов, если нужно, дописываете обработчики событий (это может и не потребоваться) - и приложение готово! (рис.2). Что интересного может предложть Delphi для разработчиков информационных систем на базе ORACLE? Во-первых, высокопроизводительный драйвер этой СУБД (хотя, конечно, никто не запретит Вам пользоваться ODBC, который, естественно, поддерживается Delphi). Во-вторых, Ваши приложения будут добросовестно цитировать все высказвания созданных на сервере триггеров, если таковые будут срабатывать во время работы приложения. В-третьих, если Вы используете версию 2.0 - в Вашем распряжении репозиторий, включающий словарь данных, навигатор баз данных, SQL-монитор, поддержка хранимых процедур и сессий, модули данных, огромное разнообразие интерфейсных элементов, в том числе и похожих на те, что есть в Oracle Power Objects, а также неограниченные возможности наращивания функциональности среды разработки за счет дополнительных эспертов, редакторов свойств и компонент. В-четвертых, Вы можете легко интегрировать в среду разработки продукты третьих фирм, например, для интерфейса с CASE-средствами (один из таких продуктов, CASE Expert - средство для экспорта ER-диаграммы в словарь данных Delphi, входит в поставку Delphi 2.01). Отметим также, что Delphi 2.0 поддерживает многопоточность, OLE-automation и другие механизмы и технологии 32-разрядных операционных систем Windows. В Delphi 2.0 имеются эффктивные механизмы обработки транзакций с использванием механизмов кэшированного обновления данных, поддерживается ряд расширений SQL, имеется Data Pump Expert для переноса данных между серверами и масштабирования приложений. В обеих версиях Delphi Client/Server имеется визуальный конструктор запросов, позволяющий сгенерировать многотабличный запрос на языке SQL, в том числе с вычисляемыми полями (интерфейс и рабочий экран этого конструктора напоминает по внешнему виду некоторые популярные CASE-средства). Помимо этого, Delphi прекрасно работает с Personal Oracle, что существенно облегчает разработку и отладку приложений, позволяя вынести эти процессы за пределы сети, в которой эксплуатируется действующая версия информационной системы. На мой взгляд, у Delphi есть один крупный недостаток - созданные приложения не являются многоплатформенными и могут эксплуатироваться только в Windows 95 и NT в случае версии Delphi 2.0, а также дополнительно в Windows 3.1 и 3.11 в случае версии Delphi 1.0 .


Но и этот недостаток можно преодолеть путем использования технологии Intranet в корпоративных системах, когда приложение, созданное на Delphi, запускается Web-сервером, а полученные формы отображаются в Web-броузере на компьютере пользователя, где может быть использована любая другая операционная система, отличная от Windows. Таким образом, Delphi Client/Server 1.0 и Delphi Client/Server Suite 2.0 являются очень удобными инструментами для создания клиентских приложений, использующих серверы ORACLE. Об этом свидетельствует высокая популярность этого средства среди разработчиков программ. Если Вы выбрали это средство - Вы всегда найдете друзей и единомышленников, готовых помочь Вам в случае появления каких-либо проблем, в том числе и в фирме , имеющей авторизованный учебный центр Borland и консультационную службу.

Дерево объектов

В качестве узлов дерева объектов могут быть использованы различные объекты, в том числе. константы, переменные, агрегаты данных, указатели, графические и диалоговые объекты, группы объектов, пользовательские объекты, задачи, каналы, объекты ввода/вывода, базы данных, программы, функции и т.д. и т.п. Библиотека встроенных объектов насчитывает более 3,500 предопределенных объектов.

Диалоги

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

Напишем совсем коротенькую программку, выдающую на экран сообщение. Sub Hello() MsgBox "Hello Word", vbInformation, "Мое первое сообщение" End Sub

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

Теперь попробуем усложнить программу. Пусть она выводит на экран сообщение с надписью "Закрыть Word?" и кнопками "Ok" и "cancel". Кроме того пусть программа закрывает Word по нажатию Ok. Sub Hello() If MsgBox("Закрыть Word?", vbOKCancel, "Мое первое сообщение") = vbOK Then Application.Quit End If End Sub

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

Если функция возвратила vbOK, т.е. пользователь выбрал кнопку OK, мы вызываем метод Quit объекта Application (объектом Application является сам Word).

Но это еще не все. При выходе Word выдает предупреждения, если изменения в файлах не сохранены. Модифицируем программу так, чтобы эти сообщения не появлялись. Для этого установим свойство DisplayAlerts объекта Application, управляющее выводом сообщений на экран в false и укажем параметр wdDoNotSaveChanges (не сохранять изменения) для метода Application.Quit Sub Hello() Application.DisplayAlerts = False If MsgBox("Закрыть Word?", vbOKCancel, "Мое первое сообщение") = vbOK Then Application.Quit wdDoNotSaveChanges End If End Sub Макрос готов. Хотите удивить коллегу? Перепишите ему этот макрос в шаблон Normal.dot под названием Autoexec (макросы с таким названием выполняются автоматически при запуске Word).

Dig_1106.shtml

Обзор статей журнала , vol.10, N 4, April 1997 (11.06.97) С. Кузнецов,

Tackling Toolsets

Robin Schumacher, senior DBA and developer with Louisville Gas and Electric
E-mail: , Home page:

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

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

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

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

Вторая категория соображений относится к типу программирования, который навязывается самим средством разработки:

3GL. К этому типу относятся средства, основанные на использовании систем программирования языков C, C++ и чистого диалекта Java. Очевидно, что они требуют более детального программирования, чем средства быстрой разработки приложений (Rapid Application Development - RAD). С другой стороны, приложения, разработанные с использованием 3GL, обычно быстрее выполняются.

4GL или средства визуальной разработки. Многие из этих средств производят откомпилированный машинный код и обеспечивают более простую связь с базами данных посредством средств 3GL, позволяя производить разработку приложений в стиле RAD (Rapid Application Development - быстрая разработка приложений).
Достаточно взглянуть на Delphi (Borland) или PowerBuilder (Powersoft), чтобы оценить, насколько использование 4GL облегчает создание приложений баз данных с графическим интерфейсом (GUI - Graphical User Interface) по сравнению с применением С++. Средства разработки, основанные на использовании браузеров. В области разработки приложений наблюдается сдвиг от классических исполняемых приложений к приложениям, базирующихся на браузерах, в которых используются HTML-страницы, компоненты и встроенные скрипты. Примером средства, создающего основанные на браузерах приложения, является HAHTSite. В отличие от клиент-серверных приложений, в приложениях, основанных на использовании браузеров, используется модель HTML в дополнение к модели непосредственно исполняемых приложений. При наличии небольшой компании можно обойтись использованием настольных платформ. Однако, если имеется большая, динамичная организация, может потребоваться разработка, охватывающая все три платформы: настольные, корпоративные и Internet. Тогда нужно подыскать подходящего поставщика. Возникает вопрос: Насколько много нужно знать, чтобы добиться того, что нужно? Похоже, что наиболее оптимальное решение дают 4GL. Если же прикладная область ориентирована на использование Internet, то требуется применение 3GL, основанных на языке Java. Многое число приложений ориентировано на использование одним или небольшим числом пользователей. С этим связана тенденция к расширению круга мобильных (mobile - не привязанных к конкретному месту) или удаленных пользователей. Многие из средств, поддерживающих этот стиль разработки, обеспечивают полную среду разработки (IDE - Interactive Development Environment), связь с базами данных, а также возможности GUI, генерации отчетов и связь с Internet. К наиболее распространенным средствам относятся Microsoft Access и Borland Visual dBase. Для эффективной разработки подобных приложений разумно использовать продукты 4GL, многие из которых являются Basic-подобными. Редко требуются более тонкие возможности таких 3GL, как C или C++.


Для построения солидной настольной системы может понадобиться умение работать с языком SQL, а при использовании некоторых средств разработки - конкретных диалектов языков баз данных. В последние несколько лет популярным средством разработки настольных прикладных систем являлся продукт Microsoft Access, в то время как более старые средства семейства Xbase и Paradox (теперь принадлежит компании Corel Corp.) до некоторой степени утратили свои позиции. Рынок настольных систем также является областью распространения Visual Basic и PowerBuilder Desktop Edition (Powersoft). При ориентации на разработку именно настольных систем трудно конкурировать с Microsoft Access. Наличие хорошей реляционной СУБД, интегрированной со средствами разработки графических пользовательских интерфейсов и генерации отчетов, дает возможность как новичкам, так и профессионалам производить работоспособные и выразительные приложения. Access развивается в сторону сопряжения с Web-системами. В Access 97 добавлен новый тип данных "hyperlink", значения которого можно использовать для связи с узлами Internet. Разработчики могут встраивать связи в базу данных и предоставлять пользователям возможность выбора в многообразии Сети. При выборе связи вызывается браузер, назначенный ей по умолчанию, и отображается Web-страница. Основным недостатком настольных систем является то, что они недостаточно хорошо масштабируются. Можно привести массу примеров, когда люди с использованием Microsoft Access пытались разработать среднюю или большую систему уровня отдела или корпорации и потерпели неудачу. При переходе к разработки корпоративных приложений приходится сталкиваться с возрастающей сложностью и другими проблемами, которые нехарактерны на более мелких приложений. Например, однопользовательские системы часто создаются одним разработчиком, в то время как корпоративные приложения обычно разрабатываются коллективом. Следовательно, требуется поддержка коллективного труда, в том числе, управление версиями. Необходимо также учитывать, что корпоративные системы обычно связаны с серверами баз данных с помощью сети, в то время как настольные приложения, как правило, работают с базами данных, хранящимися в том же компьютере. Для того, чтобы правильно выбрать средство разработки корпоративной информационной системы, следует оценить потребности корпорации, возможности ее персонала и составить список необходимых качеств средств разработки.


Следует начать с того, что большинство компаний не связывают свою активность только с одним поставщиком СУБД. Поэтому выбираемое средство разработки должно быть в состоянии работать с набором наиболее популярных серверов баз данных. Обычно доступ к базам данных производится либо на основе собственных драйверов поставщика, либо на базе ODBC. Собственные драйверы обычно обладают лучшими характеристиками и скорости, и надежности. Примером продукта, в котором используются собственные драйверы, является Team Developer компании Centura Software Corp., который поддерживает связь со многими популярными реляционными СУБД. Это не означает, что подход ODBC плох; в некоторых случаях без специальных функций ODBC просто невозможно обойтись. Просто это другой уровень, через который должно пройти приложение, чтобы достичь данных. Примером средства разработки, основанным исключительно на ODBC, является Visual Basic. Некоторые средства поддерживают оба способа доступа; примеры - Magic (Magic Software Enterprises Inc.), PowerBuilder и Developer/2000 (Oracle Corp.). Другим важным для некоторых компаний соображений является возможность средства разработки производить кросс-платформенные приложения. Могут ли, например, использовать одно и то же корпоративное приложение пользователи NT и Macintosh? При создании кросс-платформенных систем следует избегать использования специальных возможностей, которые не поддерживаются на каждой платформе (например, OLE). Примерами средств разработки, которые близки к удовлетворению подобных требований, являются JAM (JYACC, www.prolitics.com), Magic, Passport IntrPrise (Passport Corp.), Unify (Unify). Однако нужно иметь в виду, что кросс-платформенные средства разработки не дешевы. Примерно год тому назад возможность разделения приложений являлась требованием к любому хорошему средству разработки в архитектуре "клиент-сервер". В настоящее время большее внимание уделяется разделению Web-приложений. Web-серверы и другие программы, выполняемые в Web-узле, составляют дополнительное звено в добавок к браузерам клиента, базе данных и даже другим серверам, таким как серверы приложений категории реляционных или многомерных OLAP.


После появления DCOM использование многозвенных приложений будет нарастать. В сообществе Internet увеличивается интерес к распределенным архитектурам, основанным на подходе CORBA. Недостатком n-звенной архитектуры является то, что возрастает число потенциально сбойных узлов, и увеличивается трафик сети. Тем не менее, если этот подход устраивает, рынок предлагает основательные средства: Dynastry, Forte, Allegris (новый продукт компании Intersosv Inc.) и PowerBuilder 5.0. Некоторые компании предлагают несколько средств для построения n-звенного приложения. Например, может использоваться Delphi при разработке логики приложения на основе Borland C++ с применением Borland C++ Toolkit. Реально, очень много зависит от возможностей персонала вашей компании. Можно пользоваться двумя разными способами выбора средств разработки. Во-первых, можно не обращать внимание на возможности персонала. Второй подход подразумевает строгий учет сильных и слабых качеств разработчиков и выбор средства, освоение которого по силам корпорации. Часто эти соображения приводят к выбору средств 3GL или 4GL. Большая часть коммерческого программного обеспечения написана на языках C или C++, и использование этих языков оправдано при наличии достаточно квалифицированных разработчиков. При ориентации на использование 3GL следует обратить внимание на такие продукты как Microsoft Visual C++, Borland C++ и Watcom C++ (последний из перечисленных продуктов принадлежит Sybase Inc.). Для доступа к базам данных можно использовать dbtools.h++ от компании Rogue Wave Software Inc. Следующий шаг на пути выбора средств разработки должен включать перечень требований к объектной ориентированности (Object-Oriented Approach - OO). От разработчика требуется не так много времени, чтобы понять принципы наследования, полиморфизма и инкапсуляции. Вместе с тем, применение этих принципов позволит получить более "чистый" код за более короткое время. Средства уровня 4GL (например, PowerBuilder), как правило, поддерживают этот метод разработки приложений.


Тем не менее, для полезного использования подхода OO требуется его основательное понимание. Возможно, проще использовать основанные на графических интерфейсах средства 4GL, чем 3GL (например, Delphi или Team Developer компании Centura). Большинство современных средств разработки одновременно поддерживает возможность создания Web-приложений. В частности, Developer/2000 (Oracle) и Internet Developer's Toolkit (Powersoft) обеспечивают такие возможности. С использованием Web.PB можно конструировать распределенные приложения на основе PowerBuilder, обеспечивающие доступ к базам данных на основе стандартных браузеров. Но это дорого стоит (базовый комплект - от $2,500 до $5,000); при этом нужно учитывать потребность в приобретении сопутствующих продуктов (библиотеки классов, драйверы ODBC, средства управления версиями и т.д.). Если корпорации требуются статические Web-страницы, можно пользоваться любимым редактором текстов с последующей его конвертацией в формат HTML. Например, можно пользоваться редактором Microsoft Word при поддержке Doc-To-Help (Wextech Systems Inc.) или продуктов RoboHelp и WinHelp (Blue Sky Software Corp.). Для создания простых форм для связи с базами данных можно использовать Microsoft FrontPage 97. Для создания динамических Web-приложений в настоящее время нет законченных инструментальных средств, однако компания Symantec Corp. успешно продвигается на пути к объявлению полной среды Java-программирования. Компания Microsoft со своим продуктом Visual J++ тоже движется в этом направлении. Inside DCOM Mark Roy, a principal consultant at Semaphore, E-mail:
Alan Ewald, a software architect at NobleNet Inc. E-mail:

На основе спецификации CORBA, разработанной Object Management Group, выпущен ряд программных продуктов, которые поддерживают распределенную объектную обработку. Теперь профессионалы в области программного обеспечения должны серьезно заинтересоваться другой распределенной объектной архитектурой, созданной в компании Microsoft Corp. и получившей название Distributed COM, или DCOM.


DCOM является расширением компонентной объектной модели (Component Object Model - COM), которая в течение многих лет входила как составная часть в операционные системы семейства Windows и на основе которой были разработаны OLE и ActiveX. COM позволяет разработчикам использовать в качестве абстракции интерфейсы компонентов и обеспечивает бинарные (заранее откомпилированные) класса, реализующие эти интерфейсы. Поддерживается строгая инкапсуляция объектов, так что из клиентского приложения можно вызвать только те функции, которые определены в интерфейсе объекта. Стандарт бинарной интероперабельности COM стимулирует независимую разработку программных компонентов и их распространение в бинарной форме. DCOM расширяет COM для использования в сетевой среде с применением удаленных вызовов методов, средств безопасности, масштабирования и прозрачности местоположения объектов. Поскольку возможности DCOM становятся доступными на платформах, отличных от Windows NT и Windows 95, компании могут создавать программное обеспечение с использованием существующей инфрастуктуры с доступом к унаследованным (legacy) приложениям и базам данных. В COM интерфейс определяет поведение или возможности программного компонента в виде набора методов и свойств. Каждый объект COM должен поддерживать по меньшей мере один интерфейс (с именем IUnknown), но может одновременно поддерживать и несколько интерфейсов. Для описания интерфейсов компонентов используется язык определения интерфейсов компании Microsoft (Microsoft's Interface Definition Language - MIDL), объектно-ориентированное расширение DCE RPC IDL. Имеется компилятор MIDL, который генерирует код прокси (proxy) и стабов (stub) на языках Си и Си++. Сгенерированный код прокси поддерживает на стороне клиента интерфейс прикладного программирования (Application Programming Interface - API), к объектам, реализующим соответствующий интерфейс. Объекты-стабы декодируют поступающие заявки клиентов и доставляют их нужному объекту на стороне сервера. Внутреннее взаимодействие прокси и стаба с целью обмена заявками и ответами реализуется с помощью соответствующих библиотек времени выполнения.


Программное обеспечение COM оптимизирует взаимодействие процессов, если они сосуществуют в одном процессе. Каждому интерфейсу сопоставляется уникальный идентификатор (Interface Identifier - IID), устраняющий потенциально возможные коллизии имен. На наличии IID основана также модель управления версиями. Каждый объект COM должен поддерживать по меньшей мере один стандартный интерфейс IUnknown, в котором обеспечиваются базовые строительные блоки для управления жизненным циклом объекта и возможности постепенного эволюционирования интерфейсов объекта. Метод QueryInterface интерфейса IUnknown используется клиентами для определения того, поддерживается ли данным объектом интерфейс с идентификатором IID. Со временем объект может начать поддерживать новые интерфейсы или новые версии существующих интерфейсов. Существующие клиенты могут продолжать поддерживать ранние версии интерфейсов, а новые клиенты могут узнать о существовании новых версий интерфейсов путем вызова метода QueryInterface. Этот метод возвращает указатель интерфейса, ссылающийся на структуру данных, организованную в соответствии со стандартом двоичной интероперабельности COM. Интерфейсов самих по себе недостаточно для построения полных COM-приложений. Класс COM - это тело исходного текста, которое, помимо прочего, является реализацией одного или нескольких COM-интерфейсов. Класс обеспечивает реальные функции для любого метода интерфейса, представленные на любом поддерживаемом языке программирования. Каждый COM-класс обладает уникальным идентификатором, называемом CLSID. Для взаимодействия с компонентом приложение-клиент должно знать (или быть в состоянии узнать) по меньшей мере один CLSID и IID интерфейса, который поддерживается этим классом. С использованием этой информации клиент может запросить COM создать объект и вернуть соответствующий указатель интерфейса. Один или несколько классов могут быть упакованы в сервер с использованием одного из нескольких доступных средств. COM-сервер может быть упакован как динамическая библиотека связи (Dynamic Link Library), которая загружается в процесс клиента при первом доступе к серверу.


Такой сервер называется внутрипроцессным. К категории внутрипроцессных серверов относится сервер управления ActiveX. COM-сервер может быть упакован в виде отдельной выполняемой программы. Серверы этого типа могут выполняться в той же машине, что и клиент, или в удаленной машине, доступной посредством DCOM. Такие серверы называются внепроцессными. Код клиента для взаимодействия с различными видами COM-серверов один и тот же. Клиентские приложения взаимодействуют с объектами COM на основе указателей интерфейсов. Инкапсуляция, обеспечиваемая COM, гарантирует, что клиент не зависим от всех деталей реализации объекта COM. Каждый COM-объект является экземпляром COM-класса. Каждый COM-класс ассоциируется с другим COM-классом, называемом фабрикой классов, задача которой состоит в создании экземпляров классов COM. Фабрика обычно поддерживает стандартный интерфейс, определенный в модели COM и называемый IClassFactory. При наличии известного CLSID и описания ассоциированного с ним COM-сервера служба поддержки времени выполнения COM может найти фабрику для этого CLSID. После создания COM-объекта COM использует стандартный протокол для отслеживания существующих ссылок на объект и распознавания ситуаций, в которых объект может быть уничтожен. Когда счетчик числа ссылок становится равным нулю, предполагается, что больше никто из клиентов не ссылается на объект, и его можно уничтожить. Любой из методов, возвращающих указатель на интерфейс, должен вызвать метод AddRef, чтобы оповестить COM о наличии новой ссылки на объект. Клиенты, использующие указатели на объекты, должны вызвать метод Release до того, как прекратить доступ к объекту через существующий указатель. В центре архитектуры COM находится интероперабельность компонентов. В документации COM определен стандарт бинарных вызовов, в котором определено расположение данных в стеке для всех вызовов методов. В DCOM этот стандарт расширен за счет спецификации сетевого протокола интероперабельности. Бинарный стандарт обеспечивает возможность использования готовых компонентов без потребности доступа к исходным текстам.


В этом стандарте указатель на интерфейс определяется как ссылка на таблицу функций. Для внутрипроцессных серверов таблица функций содержит ссылки на реальные функции, реализующие объект. Для внепроцессных серверов таблица функций ссылается на прокси-функции. Ключевым свойством архитектуры COM является прозрачность упаковки. Разработчики могут распространять компоненты в виде DLL или выполняемых программ. Клиентские приложения не должны заботиться о том, что представляет из себя сервер. Клиент может ограничить вид сервера, но не обязан делать это. Библиотека COM определяет место расположения запрашиваемого класса и устанавливает соединение между клиентом и сервером. COM обеспечивает этот сервис путем опроса реализаций COM-классов с тем, чтобы зарегистрировать в локальном режиме тип сервера и место расположения его DLL или отдельно выполняемого кода. Менеджер управления сервисами (Service Control Manager - SCM) COM производит поиск CLSID в системе локальной регистрации и предпринимает соответствующие действия для активизации сервера. Разработчики не взаимодействуют с 4SCM напрямую. 0Библиотечные функции COM используют 4ю 0т 4SCM при запросе создания объекта или 4установлении места расположения фабрики классов. DCOM расширяет COM возможностями работы в сети. Во-первых, это касается расширенных возможностей прозрачности местоположения; объект может существовать где угодно в сети. Протокол "Object RPC (ORPC)" DCOM расширяет RPC средствами указания типа объектного указателя. Когда объект обращается к фабрике классов COM на предмет создания удаленного объекта, локальный SCM контактирует с SCM на удаленной машине. Локальный SCM обнаруживает местоположение сервера и запускает его, а также возвращает RPC-подключение к запрошенной фабрике классов. Для клиентского приложения создается прокси фабрики классов, и создание объекта продолжается так же, как в несетевом варианте. При наличии соответствующих административных установок клиенты могут получить доступ к объектам DCOM на удаленных машинах без потребности специального сетевого программирования.


Кроме того, клиенты могут указать удаленный узел, к которому следует обратиться при создании нового объекта DCOM. На возможности масштабируемости распределенных объектных систем влияют несколько факторов. Для достижения наивысшей производительности на одной машине обычно требуется использование многопотоковых (multithreaded) серверов. Это обеспечивает эффективное применение мультипроцессорных машин. В DCOM многопотоковый стиль доступен для использования сервера в любом рассмотренном раньше режиме. При использовании модели асинхронного выполнения программ, внедренной в Windows NT 4.0 и получившей название "свободной многопотоковости" (free threading) каждый вызов объекта может обслуживаться в отдельном потоке; несколько вызовов одного объекта могут выполняться в разных потоках. С помощью специальных примитивов можно запретить многопотоковость для всех объектов, однако для приложений, требующих особо высокой эффективности, требуется расплачиваться повышенной сложностью. DCOM обеспечивает поддержку нескольких уровней безопасности, которые могут быть выбраны в соответствии с потребностями разработчика и администратора. Один и тот же компонент может быть использован в среде без требований безопасности и в среде с очень строгими требованиями безопасности. Для каждого компонента поддерживаются списки контроля доступа (Access Control Lists - ACL). Чтобы соблюдать высокий уровень безопасности, можно управлять ACL с помощью средства, называемого DCOMCNFG. С использованием этого средства администратор может определить, какие пользователи и группы имеют доступ к конкретным объектным серверам на данной машине. Дополнительный уровень безопасности указывает на возможность запуска сервера. По умолчанию только администратор может запускать удаленные объекты DCOM. Более тонкая безопасность достигается путем явного добавления соответствующего кода к методам объектов. Одной из проблем разработчиков распределенных приложений является создание серверов, которые могут распознать исчезновение своих клиентов. Типичное решение состоит в использовании служебных сообщений, подтверждающих, что процесс-партнер все еще жив.


В мире распределенных объектов такой подход существенно нагружает сетевой трафик. Для оптимизации в DCOM используются сообщения на межмашинном уровне: независимо от числа клиентских процессов на одной машине и серверных компонентов на удаленной машине посылается одно служебное сообщение. Если клиент исчезает, DCOM распознает это событие и вызывает метод Release через указатель интерфейса соответствующего сервера. Дополнительная оптимизация состоит во включении служебных сообщений в обычные сообщения-заявки. Кроме того, в DCOM реализован компонент Object Exporter, который следит за объектами и объектными ссылками, полученными из других машин. Управление и конфигурирование крупномасштабных распределенных сред остается сложной задачей. DCOM поддерживает средства для облегчения этой работы, но она все еще не является тривиальной. Каждый распространяемый компонент должен быть зарегистрирован на индивидуальных клиентских машинах и на одной или нескольких серверных машин. При возрастании числа компьютеров и компонентов менеджеры сети сталкиваются с проблемой балансировки загрузки сети клиентскими заявками. В DCOM нет встроенной поддержки балансировки. Если приложение не производит динамическую балансировку, менеджер сети должен статически конфигурировать среду так, чтобы указанные клиентские машины использовали конкретный сервер. При перемещении компонента на другую машину-сервер все ссылки на старую машину должны быть изменены. DCOM является составной частью Windows NT 4.0; производится окончательное бета-тестирование для среды Windows 95. Можно переписать версию Developer Beta RC2 с Web-сервера компании Microsoft и испытать ее самостоятельно. Бета-версия DCOM для платформы Solaris доступна от компании Software AG. В течение 1997 г. ожидается появление версий продукта для платформ IBM MVS, OS/400, AIX, HP-UX, Digital UNIX, OpenVMS, Linux и UnixWare компании SCO. DCOM применяется в двух новых технологиях компании Microsoft. Во-первых, это Directory Services, которые должны появиться в Windows NT 5.0 и обеспечить масштабируемое хранилище указателей на объекты и информации, касающейся безопасности.Вторая технология применяется в Microsoft Transsaction Server, который начали поставлять в начале 1997 г. Кроме того, COM и DCOM применяются для обеспечения доступа к базам данных. Стандарт компании Microsoft OLE DB специфицирует способы интероперабельности баз данных и доступа к ним со стороны приложений. Координаты компании: Microsoft Corp., Обзор подготовлен С.Кузнецовым, , 11 июня 1997 года

Directxopt.shtml

Как заставить игру работать быстрее

Автор: , .

В этой маленькой статье я дам несколько собранных мною советов как сделать ваш программный код для DirectX более быстрым.

Во-первых, если вы хотите работать с DirectX, переходите на VB6. Сама программа шестого бейсика работает быстрее, чем программа пятого (спасибо компилятору). Во-вторых, библиотека седьмого DirectX от Microsoft работает ГОРАЗДО (!) быстрее, чем Patrice Scribe TLB (неполная функциональность это уже отдельный разговор).

Итак, про компилятор вроде бы сказал. Вам не потребуется компилировать всю программу, если вы хотите посмотреть только маленькое изменение, так как делает это Си. Однако сама программа Visual Basic работает во много раз медленнее программы на Си - и опять это заслуга компилятора, ну не может он отучить прогу от родной msvbvm60 библиотеки. :(

Вот некоторые советы, которые помогут вам сделать вашу DirectX игру более быстрой: Если вы совершаете блиттинг в DirectX с помощью программного драйвера, а не аппаратного ускорения, то используйте функцию BltFast, если вам надо просто перенести спрайт, а не использовать растяжение, вращение и т. п. BltFast работает примерно на 10% быстрее, чем функция Blt, а также и просто удобнее в использовании, потому что вам надо передавать меньше структур. DirectDraw и Direct3D гораздо быстрее в полноэкранном режиме, чем в оконном Избегайте очень много операций блиттинга. Избегайте создания большого количества поверхностей. Не создавайте массивы поверхностей. Старайтесь размещать как можно больше спрайтов на одной поверхности. Если вы делаете игру с большим количеством спрайтов и/или тайлов, попробуйте размещать их в массивы структур, создавать классы или что-нибудь в этом роде. Таким образом, когда вам надо будет вывести все спрайты, вы можете нарисовать их в один цикл типа этого: Dim i As Long For i = 0 To NUM_SPRITES Call Sprite(i).DoAI Call Sprite(i).Move Call Sprite(i).Draw Next i В тайловых играх старайтесь не прорисовывать всю карту (я имею в виду видимую часть) каждый раз, когда спрайт героя двигается.
Постарайтесь сделать процедуру, которая будет прорисовывать за один раз одну колонку или строку. Избегайте большого количества циклов. Старайтесь сделать как можно больше работы за один цикл. Попробуйте сделать несколько "процессов". Операции блиттинга и флиппинга, а также ожидания нового цикла обновления экрана занимают время и в это время компьютер ничего не делает. Постарайтесь сделать параллельный процесс, который будет в это время обсчитывать, ну скажем следующую позицию спрайта. Если вы создаете Direct3D игру, выполните поиск устройства, наиболее подходящего для D3D Ramp эмуляция всегда лучше RGB эмуляции, однако ни одна из них не сравнится с HAL (Hardware Acceleration Layer - рендеринг через аппаратное ускорение). В Direct3D Retained Mode при рендеринге большого количества многоугольников без использования HAL используйте Flat shading. Этот эффект гораздо быстрее Gouraud shading. Без аппаратного ускорения избавляйтесь от эффекта Dithering (сглаживания пикселей). Конечно игра быдет выглядеть с ним лучше, но это очень сильно тормозит программу. Если используете HAL, тогда верните Dithering на место :) Не надо все время инициализировать объекты, как только они вам понадобятся. Инициализировать объект один раз - гораздо лучше, чем делать это дважды и трижды. Во-первых, вам не надо второй раз беспокоится об ошибках, которые могут быть при инициализации, а во-вторых знаете как раздражает, когда игра при выходе из меню начинает жевать винчестером???!!!! Избегайте множества переменных Public и длинных массивов. Они жрут больше стэкового места на протяжении всего сеанса запуска программы и они могут затормозить программу. Старайтесь не делать чего-то если можно этого не делать. VB еще не настолько быстр, чтобы позволять себе много эффектов. Старайтесь делать программу меньше, а код быстрее. Вобщем посмотрите на Unreal и скажите сами себе: Я НЕ ХОЧУ, ЧТОБЫ МОЯ ПРОГА СТОЛЬКО ГРУЗИЛАСЬ!!! Прятного программирования,  

Directxwhatis.shtml

Что такое DirectX?

Автор: , .

Эта статья предназначена для тех, кто хотел бы изучить основы программирования DirectX на Visual Basic, но знает только, что DirectX - это какая-то ускорительная фича, а в чем здесь собственно суть представляет себе не очень.

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

DirectX подразделяется на несколько частей, каждая из которых отвечает за что-то свое: DirectDraw - служит для ускорения отображения и обработки двумерной графики Direct3D - для ускорения трехмерной графики DirectSound - работает со звуком - микширование и 3D звук DirectInput - для обработки клавиатуры, мыши, джойстика и так далее DirectPlay - служит в основном для сетевой игры

Эти разделы освещаются здесь, в . Кроме этого существуют и другие разделы: DirectAnimation - для создания анимационных эффектов в WEB-стриницах DirectShow - для применения мультимедиа в WEB DirectMusic - новый раздел. Служит для применения музыки в играх

И это еще не все.

DirectX разрабатывался специально, чтобы превратить платформу Windows как в основную для разработки игр. До этого разработчики использовали только MS-DOS и лишь совсем незначительная часть игр делалась для Windows 3.xx Одной из более ранних попыток Microsoft был выпуск WinG, который позволял разработчикам не писать бесконечные поддержки для различных типов аудио-видеоадаптеров, однако появление DirectX полностью изменило дело в пользу Windows. Теперь, разработчики могли почти не отвлекаться на подержки различных карт, потому что если у карты была поддержка DirectX, то несовместимость больше не была проблемой.

К слову сказать, Direct3D был попыткой Microsoft как всегда все подгрести под себя. В их стратегии стояло создать универсальный интерфейс для программрования ускорителей трехмерной графики, однако среди преимуществ Direct3D было и много недостатков, поэтому не все производители трехмерных игр используют D3D, предпочитая или интерфейс OpenGL производства Silicon Graphics или пишут игры под Glide интерфейс, который поддерживается только видеокартами на чипсете 3DFX.
Так, в знаменитом Quake используется OpenGL, а в первых частях Tomb Raider - DosGlide. DirectX - это интефейс довольно низкого уровня. С помощью своих API он предоставляет программисту прямой доступ к памяти адаптеров, где программист может создавать изображение, хранить графические образы, звуки и т. д. За счет непосредственной работы с памятью достигается ускорение, то есть теоретически частота, с которой программист сможет заставить прорисоваваться экран будет зависеть только от частоты, поддерживаемой монитором. Реально же, человек уже слабо воспринимает различия в частоте обновления, если она более 33 FPS (Frame Per Second - кадров в секунду), поэтому будет очень хорошо, если Вы сможете подвести Вашу частоту к этой. Современные графические адаптеры позволяют доводить FPS двумерной графики до всех разумных пределов, поэтому все задержки с ее отображением от того, что компьютер не успел подготовить новое изображение, а это уже зависит от чатоты процессора и объема оперативной памяти. В трехмерной же графике все сложнее. Здесь скорость отображения зависит как и от мощности компьютера, так и от качества и способности ускорения графической карты. Разработчики видеоускорителей применяют все более и более навороченные технологии ускорения и все для того, чтобы увеличить FPS еще на десяток кадров, а также улучшить качетво картинки (устранить пикселизацию, сгладить цвета...) Direct3D позволяет вам программировать для всех распространенных типов видеоускорителей, и вы можете делать это с помощью Visual Basic. C выходом седьмой версии, DirectX теперь официально поддерживает Visual Basic. Однако и до этого было возможно использовать DirectX из VB с помощью библиотек типов (c) Patrice Scribe. Но все же, скорость работы и количество поддерживаемых функций DirectX из VB оставляют желать лучшего. Основная часть внимания DirectX легла конечно же на C++. DirectX работает с VB примерно так: Команда VB -> DirectX Type Library - > DirectX -> DirectX что-нибудь делает DirectX что нибудь делает -> DirectX сообщает TL -> TL сообщает VB -> VB возвращает значение Сами видите, что цепочка чересчур длинна.Но что поделаешь, Visual Basic не был изначально инструемнтом для создания игр. Но с другой стороны, именно поэтому, программирование DirectX становится таким простым. Дерзайте, экспериментируйте, и кто знает, может быть у вас получится нечто такое!.. А то, что хоть то-нибудь получится, так это точно.  

Для чего нужен CVS?

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

Добавление и удаление файлов

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

CVS не считает, что созданные файлы должны оказаться под его контролем; это не так во многих случаях. Например, не требуется записывать историю изменений объектных и выполняемых файлов, потому что их содержимое всегда может быть воссоздано из исходных файлов (надо надеяться). Вместо этого, когда вы создадите новый файл, cvs update маркирует этот файл флагом `?', пока вы не скажете CVS, что именно вы намереваетесь сделать с этим файлом.

Чтобы добавить файл в проект, сначала вы должны создать его, затем использовать команду cvs add, чтобы маркировать его как добавленный. Затем при следующем выполнении команды cvs commit CVS добавит этот файл в репозиторий. Например, вот так можно добавить файл README в проект httpc: $ ls CVS Makefile httpc.c poll-server $ vi README ...введите описание httpc... $ ls CVS Makefile README httpc.c poll-server $ cvs update cvs update: Updating . ? README --- CVS еще не знает об этом файле $ cvs add README cvs add: scheduling file `README' for addition cvs add: use 'cvs commit' to add this file permanently $ cvs update --- что же теперь думает CVS? cvs update: Updating . A README --- Файл помечен как добавленный $ cvs commit README ... CVS просит вас ввести журнальную запись... RCS file: /u/jimb/cvs-class/rep/httpc/README,v done Checking in README; /u/src/master/httpc/README,v <-- README initial revision: 1.1 done $

CVS обращается с удаленными файлами почти так же. Если вы удалите файл и выполните `cvs update', CVS не считает, что вы намереваетесь удалить файл из проекта. Вместо этого он поступает милосерднее -- он восстанавливает последнюю сохраненную в репозитории версию файла и маркирует его флагом U, точно так же, как и любой другое обновление. (Это означает, что если вы хотите отменить изменения файла в рабочем каталоге, вы можете просто удалить его и позволить команде `cvs update' создать его заново.)

Чтобы удалить файл из проекта, вы должны сначала удалить его,а потом использовать команду `cvs rm', чтобы пометить его для удаления. При следующем запуске команда `cvs commit' удалит файл из репозитория.

Фиксирование файла, маркированного с помощью `cvs rm' не уничтожает историю этого файла -- к ней просто добавляется еще одна редакция --- "не существует". В репозитории по прежнему хранятся все записи об этом файле, и к ним можно обращаться по желанию -- например, с помощью `cvs diff' или `cvs log'.

Для переименования файла существует несколько стратегий; самая простая --- переименовать файл в рабочем каталоге, затем выполнить `cvs rm' со старым именем и `cvs add' с новым. Недостаток этого подхода в том, что журнальные записи о содержимом старого файла не переносятся в новый файл. Другие стратегии позволяют избежать этого, но зато доставляют другие, более странные проблемы.

Вы можете добавлять каталоги точно также, как и обычные файлы.

Добавление поддержки сценариев в приложение

Процесс добавления поддержки сценариев в приложение состоит из пяти шагов. Собрать с библиотекой QSA.
Для этого достаточно в файл .pro приложения добавить пару строк:
unix:LIBS += -lqsa win32:LIBS += $(QTDIR)\lib\qsa100.lib Добавить объекты приложения в механизм поддержки сценариев.
Обеспечить доступ к объектам приложения из сценариев можно с помощью вызова QtApplicationScript::addObject(). Например, если будет добавлен объект fadeEffects, то из Qt Script он будет доступен как Application.fadeEffects. После того, как объект добавлен, автор сценария может вызывать слоты объекта и изменять любые его свойства. Сигналы, которые посылает объект, могут быть связаны с функциями Qt Script. Удалить объекты из области видимости механизма поддержки сценариев можно с помощью removeObject().
Любой подкласс QObject может быть сделан доступным для программистов Qt Script. На практике разработчики должны создать несколько подклассов QObject, которые будут использоваться для изменения состояния приложения. Чтобы подкласс QObject сделать доступным для использования в Qt Script, необходимо использовать макросс Q_OBJECT (который обычно используют все подклассы QObject), и макросс Q_PROPERTY для его свойств. Любые свойства, сигналы и слоты объекта можно сделать доступными для механизма поддержки сценариев. Открыть проект сценария.
Проект сценария (scripting project) является контейнером для набора функций и классов. Некоторые приложения могут использовать один проект сценария; другие могут использовать несколько. QSA может открыть и сохранить проект сценария в файл или поместить его в поток (datastream). Например, при инициализации приложение создает указатель на объект QtApplicationScript, потом для тех объектов, доступ к которым нужно предоставить, вызывает addObject(), и затем с помощью QtApplicationScript::open() открывает проект сценария. Разрешить пользователю создавать и редактировать сценарии.
Если пользователям разрешено создавать свои собственные диалоги (например, для установки параметров в пользовательских функциях), им может быть предоставлен доступ к программе QSA Designer, которая может использоваться для создания, редактирования, выполнения и отладки сценариев.
Это достигается с помощью лишь одного вызова: QtApplicationScript::self()->openDeveloper().
Если пользователям разрешено создавать лишь не-GUI функции, они могут использовать либо QSA Designer с отключенными возможностями по созданию интерфейса, например QtApplicationScript::self()->openDeveloper(FALSE), либо текстовый редактор (например, QTextEdit) для написания собственного кода. Разрешить пользователю выполнять сценарии.
Сценарии могут выполняться программой QSA Designer. Сценарии, созданные в текстовом редакторе, могут быть выполнены передачей строки, содержащей сценарий, в функцию QtApplicationScript::evaluate(). На практике мы хотим предоставить пользователям доступ к своим сценариям непосредственно из приложения. Вот пример, показывающий, как автоматически создать QAction для любой пользовательской глобальной функции:
void MyApp::addScript(const QString &funcName, const QPixmap &pixmap ) { QAction *a = new QAction( funcName, pixmap, funcName, 0, this, funcName.latin1() ); a->addTo( scriptsToolbar ); a->addTo( scriptsMenu ); connect( a, SIGNAL( activated() ), this, SLOT( runScript() ) ); }
В этом примере мы создаем объект QAction, добавляем его в меню и панель инструментов Qt Script, и связываем сигнал activated() с нашим слотом runScript().
Когда пользователь произведет выбор из меню или панели инструментов, сценарий будет выполнен с помощью функции call():
void MyApp::runScript() { QAction *action = (QAction*)sender(); QtApplicationScript::self()->call( action->text(), QValueList < QVariant >() ); }
Сначала мы получаем указатель на объект QAction, затем с помощью функции call() по имени объекта action вызываем сценарий. Так как в вызываемую функцию мы не передаем никаких параметров, указываем пустой объект QValueList. В случае необходимости передачи параметров пользователь должен будет создать диалог и установить параметры с помощью элементов управления.
Функция QtApplicationScript::globalFunctions() возвращает список всех глобальных функций в текущем проекте сценария. Как мы увидели, добавление поддержки сценариев в приложение является простым делом.Чтобы получить доступ к механизму поддержки сценариев и программе QSA Designer, приложение должно быть собрано с библиотекой QSA. Как только библиотека QSA становится доступной, добавление объектов приложения в механизм поддержки сценариев, открытие проектов сценариев и предоставление пользователям возможности создания, редактирования, выполнения и отладки сценариев может быть достигнуто всего лишь с помощью нескольких строк кода.

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

CS поставляется с дополнительными средствами для системного администрирования и инструментами менеджеров и операторов Web-сайта. С помощью BizDesk, мощного DHTML-приложения, работающего в Интернет-броузере клиента, менеджеры сайта могут наполнять информацией продуктовый каталог, анализировать информацию о пользователях, выявлять тренды в активности пользователей, проводить персональные почтовые рассылки, просматривать информацию о заказах. BizDesk является довольно сложным приложением, реализованным на технологиях "толстого" клиента с использованием JavaScript и XML. Разработчики продукта Commerce Server не обошли вниманием администраторов Web-сайтов и серверов СУБД. Commerce Server имеет свой snap-in (модуль для администрирования), интегрированный с Microsoft Management Console. Управлять Интернет сайтом, на котором установлен Commerce Server, достаточно просто благодаря централизации всех интерфейсов управления в одном месте - Microsoft Management Console. Опыт создания Интернет проектов показывает, что разработка инструментов оператора и менеджера для системы e-commerce составляет около 40-60% времени всей разработки, поэтому использование готового решения экономит много ресурсов.

ДОСТОИНСТВА И НЕДОСТАТКИ ИСПОЛЬЗОВАНИЯ COMMERCE SERVER ПРИ ПОСТРОЕНИИ РЕШЕНИЙ ДЛЯ E-COMMERCE

CS предназначен для быстрого построения систем, основанных на Интернет-технологиях, и с его помощью действительно можно построить Web-проект любой сложности: администратор устанавливает и настраивает готовые подсистемы, разработчики разрабатывают недостающие ASP-страницы, дизайнеры рисуют дизайн и полноценное программное решение для e-commerce готово. Причём не обязательно задействовать все функциональные модули, можно ограничиться использованием только того набора, который необходим для данной системы.

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

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

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

Это налагает серьёзные ограничения на использование таких инструментов как Commerce Server и вопрос о применении подобных продуктов должен обсуждаться очень тщательно в каждом конкретном случае.

 

Доступ к данным.

Прямой доступ реализован для большинства форматов персональных БД (dBASE, FoxPro, Clipper, Btrieve, Microsoft Access и др.) и некоторых реляционных СУБД (Oracle 7, Microsoft SQL Server 6.x, Sybase System 10/11). Другими словами Crystal имеет встроенные возможности доступа к указанным источникам. Возможность прямого доступа появляется при инсталляции Crystal Reports. Прямой доступ имеет три уровня: Уровень Crystal Reports, Уровень Data Translation, реализованный в соответствующих DLL, входящих в поставку Crystal Reports, Уровень БД.

Доступ через ODBC (Open DataBase Connectivity - стандарт, позволяющий приложению иметь доступ к различным источникам данных) имеет пять уровней: Уровень Crystal Reports. При работе с ODBC - источниками Crystal Reports генерирует SQL - запросы, которые позволяют выбирать из БД только те данные, которые необходимы для построения отчета. Уровень ODBC Data Translation. Crystal Reports использует динамическую библиотеку PDSODBC.DLL/P2ODBC.DLL для связи с ODBC (как для получения, так и для передачи данных). Уровень ODBC использует различные DLL - файлы и файлы настройки, входящие в состав окружения Windows. Все ODBC-драйверы должны быть настроены либо при помощи утилит, входящих в состав Windows, либо при помощи модуля, входящего в состав Crystal Reports - ODBC Administrator. Уровень DBMS Data Translation содержит один или несколько драйверов, обеспечивающих доступ к БД. Большинство СУБД, поддерживающих работу с Windows, содержат ODBC - драйвера в составе поставки. Некоторые драйвера (DB2, SQLBase, Informix) устанавливаются при инсталляции Crystal Reports. Уровень БД. Crystal Reports не должен знать о формате данных и местоположении БД в сети, поскольку вся информация содержится в настройке ODBC -источника.

Все пять уровней используют для взаимодействия язык SQL

---

---