
- •Глава 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
Набор метрик Чидамбера и Кемерера
В 1994 году С. Чидамбер и К. Кемерер (Chidamber и Кетегег) предложили шесть проектных метрик, ориентированных на классы [24]. Класс — фундаментальный элемент объектно-ориентированной (ОО) системы. Поэтому измерения и метрики для отдельного класса, иерархии классов и сотрудничества классов бесценны для программного инженера, который должен оценить качество проекта.
Набор Чидамбера-Кемерера наиболее часто цитируется в программной индустрии и научных исследованиях. Рассмотрим каждую из метрик набора.
Метрика 1: Взвешенные методы на класс wmc (Weighted Methods Per Class)
Допустим, что в классе С определены п методов со сложностью с1...,c2,..., сn. Для оценки сложности может быть выбрана любая метрика сложности (например, цикломатическая сложность). Главное — нормализовать эту метрику так, чтобы номинальная сложность для метода принимала значение 1. В этом случае
Количество методов и их сложность являются индикатором затрат на реализацию и тестирование классов. Кроме того, чем больше методов, тем сложнее дерево наследования (все подклассы наследуют методы их родителей). С ростом количества методов в классе его применение становится все более специфическим, тем самым ограничивается возможность многократного использования. По этим причинам метрика WMC должна иметь разумно низкое значение.
Очень часто применяют упрощенную версию метрики. При этом полагают Сi= 1, и тогда WMC — количество методов в классе.
Метрика 2: Высота дерева наследования dit (Depth of Inheritance Tree)
DIT определяется как максимальная длина пути от листа до корня дерева наследования классов. Для показанной на рис. 14.3 иерархии классов метрика DIT равна 3.
Рис. 14.3. Дерево наследования классов
Соответственно, для отдельного класса DIT, это длина максимального пути от данного класса до корневого класса в иерархии классов.
По мере роста DIT вероятно, что классы нижнего уровня будут наследовать много методов. Это приводит к трудностям в предсказании поведения класса. Высокая иерархия классов (большое значение DIT) приводит к большей сложности проекта, так как означает привлечение большего количества методов и классов.
Вместе с тем, большое значение DIT подразумевает, что многие методы могут использоваться многократно.
Метрика 3: Количество детей noc (Number of children)
Подклассы, которые непосредственно подчинены суперклассу, называются его детьми. Значение NOC равно количеству детей, то есть количеству непосредственных наследников класса в иерархии классов. На рис. 14.3 класс С2 имеет двух детей — подклассы С21 и С22.
С увеличением NOC возрастает многократность использования, так как наследование — это форма повторного использования.
Однако при возрастании NOC ослабляется абстракция родительского класса. Это означает, что в действительности некоторые из детей уже не являются членами родительского класса и могут быть неправильно использованы.
Кроме того, количество детей характеризует потенциальное влияние класса на проект. По мере роста NOC возрастает количество тестов, необходимых для проверки каждого ребенка.
Метрики DIT и NOC — количественные характеристики формы и размера структуры классов. Хорошо структурированная объектно-ориентированная система чаще бывает организована как лес классов, чем как сверхвысокое дерево. По мнению Г. Буча, следует строить сбалансированные по высоте и ширине структуры наследования: обычно не выше, чем 7 ± 2 уровня, и не шире, чем 7 + 2 ветви [22].