- •Введение
- •От издательства
- •ГЛАВА 1. Организация процесса конструирования
- •Определение технологии конструирования программного обеспечения
- •Классический жизненный цикл
- •Макетирование
- •Стратегии конструирования ПО
- •Инкрементная модель
- •Быстрая разработка приложений
- •Спиральная модель
- •Компонентно-ориентированная модель
- •Тяжеловесные и облегченные процессы
- •ХР-процесс
- •Модели качества процессов конструирования
- •Контрольные вопросы
- •ГЛАВА 2. Руководство программным проектом
- •Процесс руководства проектом
- •Начало проекта
- •Измерения, меры и метрики
- •Процесс оценки
- •Анализ риска
- •Планирование
- •Трассировка и контроль
- •Планирование проектных задач
- •Размерно-ориентированные метрики
- •Функционально-ориентированные метрики
- •Выполнение оценки в ходе руководства проектом
- •Выполнение оценки проекта на основе LOC- и FP-метрик
- •Конструктивная модель стоимости
- •Модель композиции приложения
- •Модель раннего этапа проектирования
- •Модель этапа постархитектуры
- •Предварительная оценка программного проекта
- •Анализ чувствительности программного проекта
- •Сценарий понижения зарплаты
- •Сценарий наращивания памяти
- •Сценарий использования нового микропроцессора
- •Сценарий уменьшения средств на завершение проекта
- •Контрольные вопросы
- •Ошибки
- •Стоимость
- •Выполнение операции не изменяет состояния объекта
- •Проблема
- •Читать карту клиента
- •ГЛАВА 3. Классические методы анализа
- •Структурный анализ
- •Диаграммы потоков данных
- •Описание потоков данных и процессов
- •Расширения для систем реального времени
- •Расширение возможностей управления
- •Модель системы регулирования давления космического корабля
- •Методы анализа, ориентированные на структуры данных
- •Метод анализа Джексона
- •Методика Джексона
- •Шаг объект-действие
- •Шаг объект-структура
- •Шаг начального моделирования
- •Контрольные вопросы
- •ГЛАВА 4. Основы проектирования программных систем
- •Особенности процесса синтеза программных систем
- •Особенности этапа проектирования
- •Структурирование системы
- •Моделирование управления
- •Декомпозиция подсистем на модули
- •Модульность
- •Информационная закрытость
- •Связность модуля
- •Функциональная связность
- •Информационная связность
- •Коммуникативная связность
- •Процедурная связность
- •Временная связность
- •Логическая связность
- •Связность по совпадению
- •Определение связности модуля
- •Сцепление модулей
- •Сложность программной системы
- •Характеристики иерархической структуры программной системы
- •Контрольные вопросы
- •ГЛАВА 5. Классические методы проектирования
- •Метод структурного проектирования
- •Типы информационных потоков
- •Проектирование для потока данных типа «преобразование»
- •Проектирование для потока данных типа «запрос»
- •Диаграмма потоков данных
- •Метод проектирования Джексона
- •Доопределение функций
- •Учет системного времени
- •Контрольные вопросы
- •ГЛАВА 6. Структурное тестирование программного обеспечения
- •Основные понятия и принципы тестирования ПО
- •Тестирование «черного ящика»
- •Тестирование «белого ящика»
- •Особенности тестирования «белого ящика»
- •Способ тестирования базового пути
- •Потоковый граф
- •Цикломатическая сложность
- •Шаги способа тестирования базового пути
- •Способы тестирования условий
- •Тестирование ветвей и операторов отношений
- •Способ тестирования потоков данных
- •Тестирование циклов
- •Простые циклы
- •Вложенные циклы
- •Объединенные циклы
- •Неструктурированные циклы
- •Контрольные вопросы
- •ГЛАВА 7. Функциональное тестирование программного обеспечения
- •Особенности тестирования «черного ящика»
- •Способ разбиения по эквивалентности
- •Способ анализа граничных значений
- •Способ диаграмм причин-следствий
- •Контрольные вопросы
- •ГЛАВА 8. Организация процесса тестирования программного обеспечения
- •Методика тестирования программных систем
- •Тестирование элементов
- •Тестирование интеграции
- •Нисходящее тестирование интеграции
- •Восходящее тестирование интеграции
- •Сравнение нисходящего и восходящего тестирования интеграции
- •Тестирование правильности
- •Системное тестирование
- •Тестирование восстановления
- •Тестирование безопасности
- •Стрессовое тестирование
- •Тестирование производительности
- •Искусство отладки
- •Контрольные вопросы
- •ГЛАВА 9. Основы объектно-ориентированного представления программных систем
- •Принципы объектно-ориентированного представления программных систем
- •Абстрагирование
- •Инкапсуляция
- •Модульность
- •Иерархическая организация
- •Объекты
- •Общая характеристика объектов
- •Виды отношений между объектами
- •Связи
- •Видимость объектов
- •Агрегация
- •Классы
- •Общая характеристика классов
- •ПРИМЕЧАНИЕ
- •Виды отношений между классами
- •Ассоциации классов
- •Наследование
- •Полиморфизм
- •Агрегация
- •Зависимость
- •Конкретизация
- •Контрольные вопросы
- •ГЛАВА 10. Базис языка визуального моделирования
- •Унифицированный язык моделирования
- •Предметы в UML
- •Отношения в UML
- •Диаграммы в UML
- •Механизмы расширения в UML
- •Контрольные вопросы
- •ГЛАВА 11. Статические модели объектно-ориентированных программных систем
- •Вершины в диаграммах классов
- •Свойства
- •ПРИМЕЧАНИЕ
- •Операции
- •Организация свойств и операций
- •Множественность
- •Отношения в диаграммах классов
- •Деревья наследования
- •Примеры диаграмм классов
- •Контрольные вопросы
- •Моделирование поведения программной системы
- •Диаграммы схем состояний
- •Действия в состояниях
- •Условные переходы
- •Вложенные состояния
- •Диаграммы деятельности
- •Диаграммы взаимодействия
- •Диаграммы сотрудничества
- •Диаграммы последовательности
- •Диаграммы Use Case
- •Актеры и элементы Use Case
- •Отношения в диаграммах Use Case
- •Работа с элементами Use Case
- •Спецификация элементов Use Case
- •Главный поток
- •Подпотоки
- •Альтернативные потоки
- •Пример диаграммы Use Case
- •Построение модели требований
- •Расширение функциональных возможностей
- •Кооперации и паттерны
- •Паттерн Наблюдатель
- •Паттерн Компоновщик
- •Паттерн Команда
- •Бизнес-модели
- •Контрольные вопросы
- •ГЛАВА 13. Модели реализации объектно-ориентированных программных систем
- •Компонентные диаграммы
- •Компоненты
- •Интерфейсы
- •Компоновка системы
- •Разновидности компонентов
- •Использование компонентных диаграмм
- •Моделирование программного текста системы
- •Моделирование реализации системы
- •Основы компонентной объектной модели
- •Организация интерфейса СОМ
- •Unknown — базовый интерфейс COM
- •Серверы СОМ-объектов
- •Преимущества COM
- •Работа с СОМ-объектами
- •Создание СОМ-объектов
- •Повторное использование СОМ-объектов
- •Маршалинг
- •IDL-описаниеи библиотека типа
- •Диаграммы размещения
- •Узлы
- •Использование диаграмм размещения
- •Контрольные вопросы
- •ГЛАВА 14. Метрики объектно-ориентированных программных систем
- •Метрические особенности объектно-ориентированных программных систем
- •Локализация
- •Инкапсуляция
- •Информационная закрытость
- •Наследование
- •Абстракция
- •Эволюция мер связи для объектно-ориентированных программных систем
- •Связность объектов
- •TCC(Stack)=7/10=0,7
- •Сцепление объектов
- •Набор метрик Чидамбера и Кемерера
- •Использование метрик Чидамбера-Кемерера
- •Метрики Лоренца и Кидда
- •Метрики, ориентированные на классы
- •Операционно-ориентированные метрики
- •Метрики для ОО-проектов
- •Набор метрик Фернандо Абреу
- •Метрики для объектно-ориентированного тестирования
- •Метрики инкапсуляции
- •Метрики наследования
- •Метрики полиморфизма
- •Контрольные вопросы
- •Эволюционно-инкрементная организация жизненного цикла разработки
- •Этапы и итерации
- •Рабочие потоки процесса
- •Модели
- •Технические артефакты
- •Управление риском
- •Первые три действия относят к этапу оценивания риска, последние три действия — к этапу контроля риска [20].
- •Идентификация риска
- •Анализ риска
- •Ранжирование риска
- •Планирование управления риском
- •Разрешение и наблюдение риска
- •Этапы унифицированного процесса разработки
- •Этап НАЧАЛО (Inception)
- •Этап РАЗВИТИЕ (Elaboration)
- •Этап КОНСТРУИРОВАНИЕ (Construction)
- •Этап ПЕРЕХОД (Transition)
- •Оценка качества проектирования
- •Пример объектно-ориентированной разработки
- •Этап НАЧАЛО
- •Этап РАЗВИТИЕ
- •Этап КОНСТРУИРОВАНИЕ
- •Разработка в стиле экстремального программирования
- •ХР-реализация
- •ХР-итерация
- •Элемент ХР-разработки
- •Коллективное владение кодом
- •Взаимодействие с заказчиком
- •Стоимость изменения и проектирование
- •Контрольные вопросы
- •ГЛАВА 16. Объектно-ориентированное тестирование
- •Расширение области применения объектно-ориентированного тестирования
- •Изменение методики при объектно-ориентированном тестировании
- •Особенности тестирования объектно-ориентированных «модулей»
- •Тестирование объектно-ориентированной интеграции
- •Объектно-ориентированное тестирование правильности
- •Проектирование объектно-ориентированных тестовых вариантов
- •Инкапсуляция
- •Полиморфизм
- •Тестирование, основанное на ошибках
- •Тестирование, основанное на сценариях
- •Тестирование поверхностной и глубинной структуры
- •Способы тестирования содержания класса
- •Стохастическое тестирование класса
- •Тестирование разбиений на уровне классов
- •Способы тестирования взаимодействия классов
- •Стохастическое тестирование
- •Тестирование разбиений
- •Тестирование на основе состояний
- •Предваряющее тестирование при экстремальной разработке
- •Контрольные вопросы
- •ГЛАВА 17. Автоматизация конструирования визуальной модели программной системы
- •Общая характеристика CASE-системы Rational Rose
- •Создание диаграммы Use Case
- •Создание диаграммы последовательности
- •Создание диаграммы классов
- •ПРИМЕЧАНИЕ
- •ПРИМЕЧАНИЕ
- •Создание компонентной диаграммы
- •Генерация программного кода
- •Заключение
- •Приложение А.
- •Факторы затрат постархитектурной модели СОСОМО II
- •Факторы персонала
- •Низкий
- •Ada.Text_IO
- •Любой целый тип со знаком
- •Приложение Б.Терминология языка UML и унифицированного процесса
- •Приложение В. Основные средства языка программирования Ada 95
- •Список литературы
Сцепление модулей
Сцепление (Coupling) — мера взаимозависимости модулей поданным [58], [70], [77]. Сцепление — внешняя характеристика модуля, которую желательно уменьшать.
Количественно сцепление измеряется степенью сцепления (СЦ). Выделяют 6 типов сцепления. 1. Сцепление по данным (СЦ=1). Модуль А вызывает модуль В.
Все входные и выходные параметры вызываемого модуля — простые элементы данных (рис. 4.13).
Рис. 4.13. Сцепление поданным
2.Сцепление по образцу (СЦ=3). В качестве параметров используются структуры данных (рис.
4.14).
Рис. 4.14. Сцепление по образцу
3.Сцепление по управлению (СЦ=4). Модуль А явно управляет функционированием модуля В (с помощью флагов или переключателей), посылая ему управляющие данные (рис. 4.15).
Рис. 4.15. Сцепление по управлению
4.Сцепление по внешним ссылкам (СЦ=5). Модули А и В ссылаются на один и тот же глобальный элемент данных.
5.Сцепление по общей области (СЦ=7). Модули разделяют одну и ту же глобальную структуру данных (рис. 4.16).
6.Сцепление по содержанию (СЦ=9). Один модуль прямо ссылается на содержание другого модуля (не через его точку входа). Например, коды их команд перемежаются друг с другом (рис. 4.16).
Рис. 4.16. Сцепление по общей области и содержанию
На рис. 4.16 видим, что модули В и D сцеплены по содержанию, а модули С, Е и N сцеплены по общей области.
Сложность программной системы
64
В простейшем случае сложность системы определяется как сумма мер сложности ее модулей. Сложность модуля может вычисляться различными способами.
Например, М. Холстед (1977) предложил меру длины N модуля [33]:
N ≈ n1log2 (n1) + n2log2(n2),
где n1 — число различных операторов, п2 — число различных операндов.
В качестве второй метрики М. Холстед рассматривал объем V модуля (количество символов для записи всех операторов и операндов текста программы):
V = N x log2 (n1 + n2).
Вместе с тем известно, что любая сложная система состоит из элементов и системы связей между элементами и что игнорировать внутрисистемные связи неразумно.
Том МакКейб (1976) при оценке сложности ПС предложил исходить из топологии внутренних связей [49]. Для этой цели он разработал метрику цикломатической сложности:
V(G) = E-N + 2,
где Е — количество дуг, a.N — количество вершин в управляющем графе ПС. Это был шаг в нужном направлении. Дальнейшее уточнение оценок сложности потребовало, чтобы каждый модуль мог представляться как локальная структура, состоящая из элементов и связей между ними.
Таким образом, при комплексной оценке сложности ПС необходимо рассматривать меру сложности модулей, меру сложности внешних связей (между модулями) и меру сложности внутренних связей (внутри модулей) [28], [56]. Традиционно со внешними связями сопоставляют характеристику «сцепление», а с внутренними связями — характеристику «связность».
Вопросы комплексной оценки сложности обсудим в следующем разделе.
Характеристики иерархической структуры программной системы
Иерархическая структура программной системы — основной результат предварительного проектирования. Она определяет состав модулей ПС и управляющие отношения между модулями. В этой структуре модуль более высокого уровня (начальник) управляет модулем нижнего уровня (подчиненным).
Иерархическая структура не отражает процедурные особенности программной системы, то есть последовательность операций, их повторение, ветвления и т. д. Рассмотрим основные характеристики иерархической структуры, представленной на рис. 4.17.
Рис. 4.17. Иерархическая структура программной системы
Первичными характеристиками являются количество вершин (модулей) и количество ребер (связей между модулями). К ним добавляются две глобальные характеристики — высота и ширина:
высота — количество уровней управления;
ширина — максимальное из количеств модулей, размещенных на уровнях управления. В нашем примере высота = 4, ширина = 6.
Локальными характеристиками модулей структуры являются коэффициент объединения по входу и
коэффициент разветвления по выходу.
Коэффициент объединения по входу Fan_in(i) — это количество модулей, которые прямо управляют i-м модулем.
В примере для модуля n: Fan_in(n)=4.
Коэффициент разветвления по выходу Fan_out(i) — это количество модулей, которыми прямо управляет i-й модуль.
В примере для модуля m: Fan_out(m)=3.
65
Возникает вопрос: как оценить качество структуры? Из практики проектирования известно, что лучшее решение обеспечивается иерархической структурой в виде дерева.
Степень отличия реальной проектной структуры от дерева характеризуется невязкой структуры. Как определить невязку?
Вспомним, что полный граф (complete graph) с п вершинами имеет количество ребер
ес=n(n-1)/2,
адерево (tree) с таким же количеством вершин — существенно меньшее количество ребер
et=n-l.
Тогда формулу невязки можно построить, сравнивая количество ребер полного графа, реального графа и дерева.
Для проектной структуры с п вершинами и е ребрами невязка определяется по выражению
Nev = |
e −et |
|
= |
(e −n +1)×2 |
= |
2×(e −n +1) |
. |
e −e |
|
n×(n −1) −2×(n −1) |
|
||||
|
t |
|
(n −1)×(n −2) |
||||
|
c |
|
|
|
|
Значение невязки лежит в диапазоне от 0 до 1. Если Nev = 0, то проектная структура является деревом, если Nev = 1, то проектная структура — полный граф.
Ясно, что невязка дает грубую оценку структуры. Для увеличения точности оценки следует применить характеристики связности и сцепления.
Хорошая структура должна иметь низкое сцепление и высокую связность.
Л. Констентайн и Э. Йордан (1979) предложили оценивать структуру с помощью коэффициентов
Fan_in(i) и Fan_out(i) модулей [77].
Большое значение Fan_in(i) — свидетельство высокого сцепления, так как является мерой зависимости модуля. Большое значение Fan_out(i) говорит о высокой сложности вызывающего модуля. Причиной является то, что для координации подчиненных модулей требуется сложная логика управления.
Основной недостаток коэффициентов Fan_in(i) и Fan_out(i) состоит в игнорировании веса связи. Здесь рассматриваются только управляющие потоки (вызовы модулей). В то же время информационные потоки, нагружающие ребра структуры, могут существенно изменяться, поэтому нужна мера, которая учитывает не только количество ребер, но и количество информации, проходящей через них.
С. Генри и Д. Кафура (1981) ввели информационные коэффициенты ifan_in(i) и ifan_out(j) [35]. Они учитывают количество элементов и структур данных, из которых i-й модуль берет информацию и которые обновляются j-м модулем соответственно.
Информационные коэффициенты суммируются со структурными коэффициентами sfan_in(i) и sfan_out( j), которые учитывают только вызовы модулей.
В результате формируются полные значения коэффициентов:
Fan_in (i) = sfan_in (i) + ifan_in (i), Fan_out (j) = sfan_out (j) + ifan_out (j).
На основе полных коэффициентов модулей вычисляется метрика общей сложности структуры:
S = ∑n length(i) x (Fan_in(i) + Fan_out(i))2,
i=1
где length(i) — оценка размера i-го модуля (в виде LOCили FP-оценки).
Контрольные вопросы
1.Какова цель синтеза программной системы? Перечислите этапы синтеза.
2.Дайте определение разработки данных, разработки архитектуры и процедурной разработки.
3.Какие особенности имеет этап проектирования?
4.Решение каких задач обеспечивает предварительное проектирование?
5.Какие модели системного структурирования вы знаете?
6.Чем отличается модель клиент-сервер от трехуровневой модели?
7.Какие типы моделей управления вы знаете?
8.Какие существуют разновидности моделей централизованного управления?
9.Поясните разновидности моделей событийного управления.
10.Поясните понятия модуля и модульности. Зачем используют модули?
11.В чем состоит принцип информационной закрытости? Какие достоинства он имеет?
66