Вызов COM-клиентом внешнего компонента

Связь с отдельным EXE-компонентом через COM сложнее, чем связь с DLL-компонентом. EXE-компонент находится так, будто всегда существует прямая связь. О деталях позаботится COM посредством своей удаленной архитектуры, которая включает в себя вызов удаленных процедур (Remote Procedure Calls, RPC)

В RPC клиент обращается в вызовом к особой DLL, называемой заместителем (proxy). Заместитель передает поток данных так называемой заглушке (stub), которая представляет собой DLL в процесс компонента. Когда клиент вызывает функцию компонента, заместитель уведомляет об этом заглушку, посылая программе компонента сообщение, которое обрабатывается в ней скрытым окном. Механизм преобразования параметров в поток данных и обратно называется маршалингом (marshaling).

При использовании стандартных интерфейсов (т.е. тех, которые разработаны сомой Microsoft) – таких, как IClassFactory и IPersist – код заместителя и заглушки, реализующий маршалинг, находится в Windows-библиотеке OLE32.DLL. Если же Вы разрабатываете собственные интерфейсы, то писать коды заместителя и заглушки придется самостоятельно. Теперь для определения этого кода достаточно определить интерфейсы на специальном языке определения интерфейсов (Interface Definition Language, IDL) и скомпилировать код, создаваемый компилятором MIDL (Microsoft Interface Definition Language).

Источник: Кент Бек, Мартин Фаулер «Экстремальное программирование: планирование»

Экстремальное программирование (eXtreme Programming, XP) определяет кодирование как ключевую и основополагающую деятельность при работе над программным проектом.

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

• Если пересмотр кода — это хорошо, значит, мы будем пересматривать код постоянно (программирование парами);

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

• если проектирование — это хорошо, значит, проектирование надо сделать составной частью повседневной работы каждого из участников проекта (переработка кода);

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Нововведениями в ХР являются следующие особенности:

• все эти давно известные приемы собраны под одной крышей;

• интенсивность, с которой эти приемы внедряются в повседневную работу, доведена до крайности;

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

6.Формальное определение языка и грамматики. Понятия продукции, аксиомы, цепочки, длины цепочки. Классификация грамматик по Холмскому. Регулярные выражения и конечные автоматы

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

Для формального определения грамматики нам потребуются следующие обозначения. Если А есть алфавит, то A^* обозначает множество всех строк (включая пустую строку ε), составленных из символов, входящих в А. Аналогично, A⁺ определяет множество всех строк, составленных из символов, входящих в А, но без пустой строки. Нетерминалы мы будем обозначать прописными буквами, а терминалы – строчными. Итак, грамматика G определяется как следующая четверка: G = (V_T, V_N, P, S), где

· V_T – конечное множество терминальных символов;

· V_N – не пересекающееся с V_T конечное множество нетерминальных символов;

· P – конечный набор порождающих правил вида (α, β), где

· S – начальный символ, где

Например, грамматикой, порождающей язык { 0ⁿ1ⁿ | n ≥0 }, является G₀: G₀= ({ 0,1 }, { S }, P, S), где P = { S→0S1, S→ε }. Другой пример: рассмотрим грамматику, порождающую язык { a^mbⁿ | m,n ≥ 0 }. Такая грамматика имеет вид G₁= ({ a,b }, { S,A, B }, P, S), где набор правил определяется следующим образом: P = { S→AB, A→aA, A→ε, B→bB, B→ε }.

Определим также понятие выводимости: если αβγ – цепочка, состоящая из символов языка G, а β→δ – правило языка G, то αβγ =>_G αδγ (αδγ непосредственно выводима из αβγ в G). Рефлексивное и транзитивное замыкание этого отношения обозначим как α=>^*_Gβ (цепочка β выводима из а(, возможно за несколько шагов); имя грамматики можно опускать для краткости).