
- •Глава 1. Организация процесса конструирования
- •Определение технологии конструирования программного обеспечения
- •Классический жизненный цикл
- •Макетирование
- •Стратегии конструирования по
- •Инкрементная модель
- •Быстрая разработка приложений
- •Спиральная модель
- •Компонентно-ориентированная модель
- •Тяжеловесные и облегченные процессы
- •Модели качества процессов конструирования
- •Контрольные вопросы
- •Глава 2. Руководство программным проектом
- •Процесс руководства проектом
- •Начало проекта
- •Измерения, меры и метрики
- •Процесс оценки
- •Анализ риска
- •Планирование
- •Трассировка и контроль
- •Планирование проектных задач
- •Размерно-ориентированные метрики
- •Функционально-ориентированные метрики
- •Выполнение оценки в ходе руководства проектом
- •Выполнение оценки проекта на основе loc- иFp-метрик
- •Конструктивная модель стоимости
- •Модель композиции приложения
- •Модель раннего этапа проектирования
- •Модель этапа постархитектуры
- •Предварительная оценка программного проекта
- •Анализ чувствительности программного проекта
- •Сценарий понижения зарплаты
- •Сценарий наращивания памяти
- •Сценарий использования нового микропроцессора
- •Сценарий уменьшения средств на завершение проекта
- •Контрольные вопросы
- •Глава 3. Основы проектирования программных систем
- •Особенности процесса синтеза программных систем
- •Особенности этапа проектирования
- •Структурирование системы
- •Моделирование управления
- •Декомпозиция подсистем на модули
- •Модульность
- •Информационная закрытость
- •Связность модуля
- •Функциональная связность
- •Информационная связность
- •Коммуникативная связность
- •Процедурная связность
- •Временная связность
- •Логическая связность
- •Связность по совпадению
- •Определение связности модуля
- •Сцепление модулей
- •Сложность программной системы
- •Характеристики иерархической структуры программной системы
- •Контрольные вопросы
- •Метрики объектно-ориентированных программных систем
- •Метрические особенности объектно-ориентированных программных систем
- •Локализация
- •Инкапсуляция
- •Информационная закрытость
- •Наследование
- •Абстракция
- •Эволюция мер связи для объектно-ориентированных программных систем
- •Связность объектов
- •Метрики связности по данным
- •Метрики связности по методам
- •Сцепление объектов
- •Зависимость изменения между классами
- •Локальность данных
- •Набор метрик Чидамбера и Кемерера
- •Метрика 1: Взвешенные методы на класс wmc (Weighted Methods Per Class)
- •Метрика 2: Высота дерева наследования dit (Depth of Inheritance Tree)
- •Метрика 3: Количество детей noc (Number of children)
- •Метрика 4: Сцепление между классами объектов сво (Coupling between object classes)
- •Метрика 5: Отклик для класса rfc (Response For a Class)
- •Метрики Лоренца и Кидда
- •Метрики, ориентированные на классы
- •Метрика 1: Размер класса cs (Class Size)
- •Метрика 2: Количество операций, переопределяемых подклассом, noo
- •Метрика 3: Количество операций, добавленных подклассом, noa
- •Метрика 4: Индекс специализации si (Specialization Index)
- •Операционно-ориентированные метрики
- •Метрика 5: Средний размер операции osavg (Average Operation Size)
- •Метрика 6: Сложность операции ос (Operation Complexity
- •Метрика 7: Среднее количество параметров на операцию npavg
- •Метрики для оо-проектов
- •Метрика 8: Количество описаний сценариев nss (Number of Scenario Scripts)
- •Метрика 9: Количество ключевых классов nkc (Number of Key Classes)
- •Метрика 10: Количество подсистем nsub (NumberofSuBsystem)
- •Набор метрик Фернандо Абреу
- •Метрика 1: Фактор закрытости метода mhf (Method Hiding Factor)
- •Метрика 2: Фактор закрытости свойства ahf (Attribute Hiding Factor)
- •Метрика 3: Фактор наследования метода mif (Method Inheritance Factor)
- •Метрика 4: Фактор наследования свойства aif (Attribute Inheritance Factor)
- •Метрика 5: Фактор полиморфизма pof (Polymorphism Factor)
- •Метрика 6: Фактор сцепления cof (Coupling Factor)
- •9. Тестирование программных продуктов
- •9.1. Виды контроля качества разрабатываемого программного обеспечения
- •9.2. Ручной контроль программного обеспечения
- •2. Контроль вычислений
- •3. Контроль передачи управления
- •4. Контроль межмодульных интерфейсов
- •9.3. Структурное тестирование
- •9.4. Функциональное тестирование
- •Глава 8. Организация процесса тестирования программного обеспечения
- •Методика тестирования программных систем
- •Тестирование элементов
- •Тестирование интеграции
- •Нисходящее тестирование интеграции
- •Восходящее тестирование интеграции
- •Сравнение нисходящего и восходящего тестирования интеграции
- •Тестирование правильности
- •Системное тестирование
- •Тестирование восстановления
- •Тестирование безопасности
- •Стрессовое тестирование
- •Тестирование производительности
- •Искусство отладки
- •Контрольные вопросы
- •2.Использование буфера обмена
- •3.Технология "перетяни и оставь"
- •4. Технология ole
- •5. Динамический обмен данными (dde)
- •6. Эволюция архитектуры «клиент-сервер»
- •6.1 Определение и назначение промежуточного по
- •6.2 Функции middleware
- •6.3 Виды промежуточного по
- •Промежуточное по межпрограммного взаимодействия
- •6.4 Промежуточное по доступа к базам данных
- •9. Основы компонентной объектной модели
- •Организация интерфейса сом
- •Идентификация интерфейса
- •Описание интерфейса
- •Реализация интерфейса
- •Unknown — базовый интерфейс com
- •Серверы сом-объектов
- •Преимущества com
- •Работа с сом-объектами
- •Создание сом-объектов
- •IClassFactory :: Createlnstance (iid a); 2 — фабрика класса создает сом-объект и получает
- •Повторное использование сом-объектов
- •Маршалинг
- •12. Введение в .Net Framework
Маршалинг
Клиент может содержать прямую ссылку на СОМ-объект только в одном случае — когда СОМ-объект размещен в сервере «в процессе». В случае локального или удаленного сервера, как показано на рис. 13.23, он ссылается на посредника.
Посредник — СОМ-объект, размещенный в клиентском процессе и предоставляющий клиенту те же интерфейсы, что и запрашиваемый объект. Запрос клиентом операции через такую ссылку приводит к исполнению кода посредника.
Посредник принимает параметры, переданные клиентом, и упаковывает их для дальнейшей пересылки. Эта процедура называется маршалингом. Затем посредник (с помощью средства коммуникации) посылает запрос в процесс, который на самом деле реализует СОМ-объект.
Рис. 13.23. Организация маршалинга и демаршалинга
По прибытии в процесс локального сервера запрос передается заглушке. Заглушка распаковывает параметры запроса и вызывает операцию СОМ-объекта. Эта процедура называется демаршалингом. После завершения СОМ-операции результаты возвращаются в обратном направлении.
Код посредника и заглушки автоматически генерируется компилятором MIDL (Microsoft IDL) по IDL-описанию интерфейса.
IDL-описаниеи библиотека типа
Помимо информации об интерфейсах, IDL-описание может содержать информацию о библиотеке типа.
Библиотека типа определяет важные для клиента характеристики СОМ-объекта: имя его класса, поддерживаемые интерфейсы, имена и адреса элементов интерфейса.
Рассмотрим пример приведенного ниже IDL-описания объекта для работы с файлами. Оно состоит из 3 частей. Первые две части описывают интерфейсы IРаботаСФайлами и IПреобразованиеФорматов, третья часть— библиотеку типа ФайлыБибл. По первым двум частям компилятор MIDL генерирует код посредников и заглушек, по третьей части — код библиотеки типа:
-----------1-я часть
[ object,
uuid(E7CDODOO-1827-11CF-9946-444553540000) ]
interface IРаботаСФайлами; IUnknown
{ import "unknown.idl"
HRESULT ОткрытьФайл ([in] OLECHAR имя[31]);
HRESULT ЗаписатьФайл ([in] OLECHAR имя[31]);
HRESULT ЗакрытьФайл ([in] OLECHAR имя[31]);
}
----------- 2-я часть
[ object.
uuid(5FBDD020-1863-11CF-9946-444553540000) ]
interface IПреобразованиеФорматов: IUnknown
{ HRESULT ПреобразоватьФормат ([in] OLECHAR имя[31],
[in] OLECHAR формат[31]);
}
------------ 3-я часть
[ uuid(B253E460-1826-11CF-9946-444553540000),
version (1.0)]
library ФайлыБибл
{ importlib ("stdole32.tlb");
[uuid(B2ECFAAO-1827-11CF-9946-444553540000) ]
coclass СоФайлы
{ interface IРаботаСФайлами;
interface IпреобразованиеФорматов;
}
}
Описание библиотеки типа начинается с ее уникального имени (записывается после служебного слова uuid), затем указывается номер версии библиотеки.
После служебного слова library записывается символьное имя библиотеки (ФайлыБибл).
Далее в операторе importlib указывается файл со стандартными определениями IDL - stdole32.tlb.
Тело описания библиотеки включает только один элемент — СОМ-класс (coclass), на основе которого создается СОМ-объект.
В начале описания СОМ-класса приводится его уникальное имя (это и есть идентификатор класса — CLSID), затем символьное имя — СоФайлы. В теле класса перечислены имена поддерживаемых интерфейсов — РаботаСФайлами и IПреобразованиеФорматов.
Как показано на рис. 13.24, доступ к библиотеке типа выполняется по стандартному интерфейсу ITypeLib, а доступ к отдельным элементам библиотеки — по интерфейсу ITypelnfo.
Рис. 13.24. Доступ к библиотеке типа
. Объекты автоматизации и интерфейс IDispatch
В технологиях OLE/COM (см. главу 25) активно используются так называемые объекты автоматизации (Automation objects). Эти объекты представляют собой экземпляры компонентных классов, родительским интерфейсом которых является специальный интерфейс IDispatch. Отличительной особенностью интерфейса IDispatch является то обстоятельство, что методы объектов автоматизации никогда не вызываются напрямую, но всегда — с помощью метода Invoke интерфейса IDispatch.
Для объявления класса автоматизации используется специальное зарезервированное слово dispinterf асе, а перечисляемые в объявлении методы и свойства должны снабжаться целочисленными идентификаторами, которые вставляются в конце описания методов (свойств) после зарезервированных слов dispid:
type
IStringsDisp = dispinterface
['{EE05DFE2-5549-11DO-9EA9-0020AF3D82DA}']
property ControlDefault[Index: Integer]: OleVariant dispid 0; default;
function Count: Integer; dispid 1;
property Item[Index: Integer]: OleVariant dispid 2;
procedure Remove(Index: Integer); dispid 3;
procedure Clear; dispid 4;
function Adddtem: OleVariant): Integer; dispid 5;
function _NewEnum: lUnknown; dispid -4; end;
С помощью зарезервированного слова dispid методу (свойству) интерфейса ставится в соответствие целочисленный номер. Это дает возможность языкам программирования, не поддерживающим указатели (Visual Basic, Java и др.), обращаться к методам и свойствам интерфейсных объектов по их именам. Для этого объект, имеющий интерфейс, родителем которого является dispinterface, автоматически создает таблицу имен его методов и свойств с указанием идентификаторов dispid. При обращении к методу по имени компилятор создает код вызова специального метода IDispatch.GetlDsOfName. Этот метод отыскивает в таблице имен нужное имя и возвращает соответствующий идентификатор dispid (если имя не найдено, возникает исключительная ситуация). Затем программа
использует полученный идентификатор как один из аргументов вызова метода IDispatch. Invoke. Этот метод отыскивает описание вызываемого метода в специальной таблице, проверяет количество и тип передаваемых методу параметров вызова и, если все правильно, вызывает его.
В отличие от обычного компонентного класса, класс автоматизации не может иметь родительского класса, и поэтому за словом dispinterf асе нельзя указать список родителей. Идентификаторы методов (свойств) должны быть уникальными в пределах объявления класса. Все возвращаемые функциями и свойствами результаты, а также все параметры обращения к методам должны иметь один из следующих типов: Byte, Currency, Real, Double, Longlnt, Integer, Single, Smalllnt, AnsiString, WideString, TDateTime, Variant, OleVariant, WordBool или любой интерфейсный тип. За исключением директивы default, которую можно указать для свойства-массива, никакие другие директивы в объявлении методов и свойств не допускаются.
Для доступа к объектам автоматизации используются переменные типа вариант. Инициализация такой переменной осуществляется вызовом функции Create-OleOb j ect, определенной в модуле ComOb j. Эта функция возвращает ссылку на интерфейс IDispatch, с помощью которой можно обращаться к методам и свойствам класса автоматизации так, как если бы они были методами и свойствами варианта. Например:
Uses ComObj;
... ^ var
Word: Variant; begin
Word := CreateOleObject('Word.Basic'); Word.FileNew('Normal'); Word.Insert('Первая строка'#13); Word.Insert('Вторая строка'#13); Word.FileSaveAs('c:\temp\test.txt', 3) ; end;
Параметром обращения к методу CreateOleOb j ect является имя сервера автоматизации, которое должно быть предварительно зарегистрировано в реестре 32-разрядных версий Windows. Характерно, что методы сервера не известны на этапе компиляции программы, поэтому компилятор никак не контролирует правильность их вызовов. Названия методов не подчиняются правилам построения идентификаторов Delphi, и в них могут использоваться символы национальных алфавитов.
Передаваемые методам параметры могут быть позиционными и именованными. Позиционные параметры являются обычными для подпрограмм Delphi параметрами-значениями. Именованные параметры записываются в следующем виде:
<имя_параметра> := <значение>
Например, при обращении к методу FileSaveAs (см. выше) были использованы два позиционных параметра. Это же обращение можно было бы записать с использованием именованных параметров следующим образом:
Word.FileSaveAs(Format := 3, Name := 'c:\temp\test.txt');
Именованные параметры могут перечисляться в произвольном порядке, но обязательно после позиционных параметров, если те тоже присутствуют в обращении.
Интерфейсы — наследники от IDispatch — называются дуальными, так как они дублируют свойства и методы основного интерфейса. Иными словами, Delphi может выполнять одну и ту же работу, либо обращаясь к экземплярам компонентного класса и используя указатели на нужные методы, либо по имени — с помощью дуального интерфейса. В отличие от этого, в Visual Basic доступен только последний способ. Методы дуальных интерфейсов (кроме унаследованных от интерфейсов lUnknow и IDispatch) должны компилироваться в режиме safecall.