- •Глава 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
Реализация интерфейса
СОМ задает стандартный двоичный формат, который должен реализовать каждый СОМ-объект и для каждого интерфейса. Стандарт гарантирует, что любой клиент может вызывать операции любого объекта, причем независимо от языков программирования, на которых написаны клиент и объект.
Структуру интерфейса IРаботаСФайлами, соответствующую двоичному формату, «поясняет рис. 13.16.
Рис. 13.16. Внутренняя структура интерфейса IРаботаСФайлами
Внешний указатель на интерфейс (указатель клиента) ссылается на внутренний указатель объекта СОМ. Внутренний указатель — это адрес виртуальной таблицы. Виртуальная таблица содержит указатели на все операции интерфейса.
Первые три элемента виртуальной таблицы являются указателями на операции, унаследованные от интерфейса IUnknown. Видно, что на собственные операции интерфейса IРаботаСФайлами указывают 4-, 5- и 6-й элементы виртуальной таблицы. Такая ситуация типична для любого СОМ-интерфейса.
Обработка клиентского вызова выполняется в следующем порядке:
с помощью указателя на виртуальную таблицу извлекается указатель на требуемую операцию интерфейса;
указатель на операцию обеспечивает доступ к ее реализации;
исполнение кода операции обеспечивает требуемую услугу.
Unknown — базовый интерфейс com
Интерфейс lUnknown обеспечивает минимальное «снаряжение» каждого объекта СОМ. Он содержит три операции и предоставляет любому объекту СОМ две функциональные возможности:
операция Querylnterface() позволяет клиенту получить указатель на любой интерфейс объекта (из другого указателя интерфейса);
операции AddRef() и Release() обеспечивают механизм управления временем жизни объекта.
Свой первый указатель на интерфейс объекта клиент получает при создании объекта СОМ. Порядок получения других указателей на интерфейсы (для вызова их операций) поясняет рис. 13.17, где расписаны три шага работы. В качестве параметра операции Querylnterface задается идентификатор требуемого интерфейса (IID). Если требуемый интерфейс отсутствует, операция возвращает значение NULL.
Рис. 13.17. Получение указателя на интерфейс с помощью Querylnterface: 1 — с помощью
указателя на интерфейс А клиент запрашивает указатель на интерфейс В, вызывая
Querylnterface (IID_B); 2 — объект возвращает указатель на интерфейс В;
3 — теперь клиент может вызывать операции из интерфейса В
Имеет смысл отметить и второе важное достоинство операции Querylnterface. В сочетании с требованием неизменности СОМ-интерфейсов она позволяет «убить двух зайцев»:
развивать компоненты;
обеспечивать стабильность клиентов, использующих компоненты.
Поясним это утверждение. По законам СОМ-этики новый СОМ-объект должен нести в себе и старый СОМ-интерфейс, а операция Querylnterface всегда обеспечит доступ к нему.
Ну а теперь обсудим правила жизни, а точнее смерти СОМ-объекта. В многоликой СОМ-среде бремя ответственности за решение вопроса о финализации должно лежать как на клиенте, так и на СОМ-объекте. Можно сказать, что фирма Microsoft (создатель этой модели) разработала самурайский кодекс поведения СОМ-объекта — он должен сам себя уничтожить. Возникает вопрос — когда? Когда он перестанет быть нужным всем своим клиентам, когда вытечет песок из часов его жизни. Роль песочных часов играет счетчик ссылок (СЧС) СОМ-объекта.
Правила финализации СОМ-объекта очень просты:
при выдаче клиенту указателя на интерфейс выполняется СЧС+1;
при вызове операции AddRef выполняется СЧС+1;
при вызове операции Release выполняется СЧС-1;
при СЧС=0 объект уничтожает себя.
Конечно, клиент должен помогать достойному харакири объекта-самурая:
при получении от другого клиента указателя на интерфейс СОМ-объекта он должен вызвать в этом объекте операцию AddRef;
в конце работы с объектом он обязан вызвать его операцию Release.