Вы находитесь на странице: 1из 47

Технологии конструирования

программного обеспечения
Software Engineering
Лекция 4-5

Основы проектирования
программных систем
Особенности процесса синтеза программных
систем

Технологический цикл разработки программной системы (ПС) включает


три процесса — анализ, синтез и сопровождение.
В ходе анализа ищется ответ на вопрос: «Что должна делать будущая
система?». Именно на этой стадии закладывается фундамент успеха всего
проекта. Известно множество неудачных реализаций из-за неполноты и
неточностей в определении требований к системе.
В процессе синтеза формируется ответ на вопрос: «Каким образом
система будет реализовывать предъявляемые к ней требования?».
Выделяют три этапа синтеза: проектирование ПС, кодирование ПС,
тестирование ПС.

3
Информационные потоки процесса синтеза ПС
Модель анализа
· Информационная
· Функциональная
· Поведенческая

Этап проектирования
Модель Модель
архитектуры данных
Модели
подсистем

Этап кодирования
Программные модули

Этап тестирования

Проверенная и объединенная программная система


4
Этап проектирования питают требования к ПС, представленные
информационной, функциональной и поведенческой моделями
анализа. Модели анализа поставляют этапу проектирования
исходные сведения для работы. Информационная модель
описывает информацию, которую, по мнению заказчика, должна
обрабатывать ПС. Функциональная модель определяет перечень
функций обработки. Поведенческая модель фиксирует желаемую
динамику системы (режимы ее работы). На выходе этапа
проектирования — модель данных, модель архитектуры и модель
подсистем архитектуры ПС.
Модель данных  — результат преобразования информационной модели
анализа в структуры данных программной системы.
Модель архитектуры выделяет основные структурные подсистемы,
фиксирует связи между ними и задает принципы взаимодействия
подсистем.
Модели подсистем описывают организацию подсистем, то есть
определяют их содержание.
После создания текстов программных модулей проводится тестирование
для объединения и проверки ПС. На проектирование, кодирование и
тестирование приходится более 75% стоимости разработки ПС.
Проектирование обеспечивает такими представлениями ПС, качество
которых можно оценить. Проектирование — единственный путь для
правильной трансляций требований заказчика в конечный продукт.
Под качеством понимают степень соответствия системы, компонента или процесса
определенным требованиям.
5
Особенности этапа проектирования

Проектирование — итерационный процесс, при помощи которого


требования к ПС транслируются в инженерные представления
ПС. Вначале эти представления дают только концептуальную
информацию (на высоком уровне абстракции), последующие
уточнения приводят к формам, которые близки к программным
текстам.
Обычно в проектировании выделяют две ступени: архитектурное
проектирование и детальное проектирование. Архитектурное
проектирование формирует абстракции высокого уровня,
детальное проектирование уточняет эти абстракции, добавляет
подробности алгоритмического уровня. Кроме того, во многих
случаях выделяют интерфейсное проектирование, цель
которого — сформировать графический интерфейс
пользователя (GUI).

6
Схема информационных связей процесса проектирования

Архитектура Структуры данных


Требования программ и данных и модули

Архитектурное Детальное
проектирование проектирование

Интерфейсное
проектирование (создание GUI)
Характеристики, формы
человеко-машинного
взаимодействия

7
Архитектурное проектирование включает три типа деятельности:
1. Структурирование системы. Система структурируется на
несколько подсистем, где под подсистемой понимается
независимый программный компонент. Определяются
взаимодействия подсистем.
2. Моделирование управления. Определяется модель связей
управления между частями системы.
3. Декомпозиция подсистем на модули. Каждая подсистема
разбивается на модули. Определяются типы модулей и
межмодульные соединения.

8
Структурирование системы

Архитектура программной системы может быть основана на


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

9
Паттерн Модель-представление-контроллер (Model-View-Controller) MVC
Имя MVC (Модель-представление-контроллер)
Описание Отделяет представление системы и взаимодействие с системой от
данных системы. Система разделяется на три логических компонента,
которые взаимодействуют друг с другом. Компонент Модель управляет
системными данными и операциями над данными. Компонент
Представление отображает данные для пользователя. Компонент
Контроллер взаимодействует с пользователем, инициирует операции в
модели и управляет работой представления. Структуру паттерна
поясняет рис. 6. 3
Пример Архитектура Web-системы на основе паттерна MVC показана на рис.
6.4
Когда используется 1. Когда требуется несколько вариантов обработки и представления
данных. 2. Когда неизвестны требования к взаимодействию и
представлению данных
Преимущества Позволяет изменять данные независимо от их представления.
Изменение данных, сделанное в одном представлении, отображается во
всех остальных представлениях
Недостатки Избыточность программного кода при простой модели данных и
простых схемах взаимодействия

10
Контроллер Предс тавление
Выбор представления
Передача команд Избражение модели
на обновление модели Запросы обновления модели
Выбор представления Посылка событий в контроллер
События

Уведомление
изменения
Изменение
состояния Запрос
Модель состояния

Генерация состояния
приложения
Уведомление об изменении
состояния

Рис. 06_03

11
Web-браузер

Контроллер Представление
Форма для отображения
Обработка Http-запроса Генерация
Логика приложения динамической страницы
Проверка данных
События Управление формами

Уведомление
изменения
Изменение
состояния Запрос
Модель обновления

Функциональная логика

База данных

12
Рис. 06_04
Этот паттерн определяет архитектуру многих систем,
ориентированных на обслуживание клиентов. Поскольку паттерн
является образцом типового решения, с которым знакомятся и
которое могут применить многие архитекторы, его описание
должно содержать развернутую характеристику. Обычно
описание состоит из следующих разделов:
• Имя паттерна (должно характеризовать его суть).
• Описание (краткое и понятное описание функциональных
возможностей и структуры паттерна, структура поясняется
графической диаграммой).
• Пример (приводится пример типового применения паттерна,
поясняемый диаграммой).
• Когда используется (описываются условия применения, дается
обобщенная характеристика предметных областей).
• Преимущества (перечисляются преимущества применения).
• Недостатки (указываются слабые стороны данного паттерн-
решения).

13
Архитектура с хранилищем данных
Паттерн Хранилища данных
Имя Хранилище данных
Описание В центральном хранилище находятся все данные системы. Эти данные
доступны всем подсистемам. Подсистемы взаимодействуют друг с
другом косвенно, через хранилище
Пример Архитектура Case-системы на основе хранилища показана на рис. 6.5.
Здесь каждая подсистема генерирует данные, которые доступны
другим подсистемам
Когда используется Когда требуется создавать и долгое время хранить большие объемы
информации. Удобно использовать в системах, порядок работы
которых определяется данными
Преимущества 1. Предоставляет подсистемам простую схему для получения
устойчиво существующих объектов и управления их жизненным
циклом. 2. Убирает необходимость в технической поддержке
целостности объектов, разных вариантов технологий СУБД, и даже
разных источников данных. 3. Скрывает сложность механизма доступа
к устойчивым объектам 4. Обеспечивает функциональную
независимость подсистем
Недостатки Трудности размещения хранилища на нескольких компьютерах.
Возможно понижение скорости доступа к данным. Проблемы
хранилища прямо влияют на всю систему

14
Редактор Генератор Транслятор
моделей кода моделей

Хранилище данных проектирования

Редактор Анализатор
программ моделей

Рис. 06_05

Этот паттерн удобен для систем, где одни компоненты генерируют


данные, а другие используют их (например, систем управления,
информационных систем, среды для разработки программ).
Обычно хранилище является ведомым элементом системы, который
управляется другими подсистемами. Возможно и другое решение,
получившее название «классной доски». Хранилище, играющее
роль классной доски, само вызывает подсистемы по мере
готовности данных.
15
Клиент-серверная архитектура

Паттерн Клиент-сервер
Имя Клиент-сервер
Описание Функциональность системы обеспечивается набором услуг (сервисов).
Каждый сервис располагается на своем сервере. Клиенты являются
пользователями этих сервисов. Для получения услуги клиент
обращается к серверу
Пример Архитектура сетевой библиотечной системы на основе паттерна
клиент-сервер показана на рис. 6.6
Когда используется 1. Когда услуги должны быть доступны из разных мест. 2. Когда
требуется гибкий механизм перестройки системы по загружаемым
начальным данным
Преимущества 1. Предоставление клиентам различных услуг через сеть. 2.
Устраняется необходимость тиражирования реализации услуг среди
серверов
Недостатки Возможно понижение скорости доступа к данным из-за проблем в сети.
Поломка сервера лишает клиента услуги

16
Клиент 1 Клиент 2 Клиент 3 … Клиент N

Интернет

Сервер Видео Сервер Сервер


каталога сервер фотографий книг

Рис. 06_06

Система здесь организована в виде набора сервисов, находящихся на


серверах, и клиентов, которые обращаются к серверам и используют
сервисы. Главные элементы этой архитектуры:
• Набор серверов, предлагающих услуги клиентам (например, серверы
услуг печати, серверы для записи и хранения файлов, серверы-
переводчики).
• Набор клиентов, которые обращаются к сервисам серверов. В роли
клиентов выступают клиентские программы, часто запускаемые
одновременно на различных компьютерах.
• Сеть, которая позволяет клиентам обращаться к сервисам. Чаще
всего клиент-серверные системы реализованы как распределенные
системы, соединенные с помощью Internet-протокола.
17
Трехъярусная архитектура является развитием архитектуры
клиент-сервер.
Графический интерфейс пользователя
 

Бизнес-логика

Реляционная СУБД

Ярус графического интерфейса пользователя запускается на машине


клиента. Бизнес-логику образуют модули, осуществляющие
функциональные обязанности системы. Этот ярус запускается на
сервере приложения. Реляционная СУБД хранит данные,
требуемые уровню бизнес-логики. Этот ярус запускается на
втором сервере — сервере базы данных.
Преимущества трехъярусной модели:
• упрощается такая модификация яруса, которая не влияет на
другие уровни;
• отделение прикладных функций от функций управления БД
упрощает оптимизацию всей системы.

18
Моделирование управления

Известны два типа управления:


1. централизованное управление;
2. событийное управление.
При централизованном управлении одна подсистема выделяется
как системный контроллер. Ее обязанности — руководить
работой других подсистем.
При событийном управлении системой управляют внешние
события. На внешние события может реагировать любая
подсистема. События, на которые откликается система, могут
происходить либо в ее подсистемах, либо во внешнем
окружении системы.
Типовые решения управления представляются паттернами
управления.
Паттерны управления дополняют структурные паттерны. Все
описанные структурные паттерны можно реализовать с
помощью централизованного управления или управления,
основанного на событиях.
19
Паттерны централизованного управления
В паттернах централизованного управления одна из подсистем
назначается главной и управляет работой других подсистем.
Различают две разновидности паттернов, зависящие от режима
работы управляемых подсистем (последовательная работа,
параллельная работа).
Паттерн вызов-возврат
Имя Вызов-возврат
Описание Вызов компонентов осуществляется «сверху вниз», то есть управление
начинается на вершине иерархии компонентов и через многократные
вызовы передается на нижние уровни иерархии
Пример Иллюстрация организации управления приведена на рис. 6.11
Когда используется Применима только в системах последовательной обработки, то есть в
таких системах, в которых процессы должны протекать
последовательно
Преимущества Простой анализ потоков управления. Такие системы легче
проектировать и тестировать
Недостатки Сложно обрабатывать исключительные ситуации

20
Главный
компонент

Компонент 1 Компонент 2 Компонент 3

Компонент Компонент Компонент Компонент Компонент Компонент


1.1 1.2 2.1 2.2 3.1 3.2

Рис. 06_11

Паттерн менеджера
Имя Менеджер
Описание Один системный компонент назначается менеджером и управляет
запуском и завершением других компонентов системы, координирует
их работу. Компоненты могут работать параллельно
Пример Иллюстрация системы с менеджером приведена на рис. 6.12
Когда используется Применяется в системах, в которых необходимо организовать
параллельные процессы, но может использоваться и для систем
последовательной обработки, в которых менеджер вызывает отдельные
подсистемы в зависимости от значений некоторых переменных
Преимущества Можно использовать в системах реального времени, где нет чересчур
строгих временных ограничений (в так называемых «мягких» системах
реального времени)
21
Недостатки Малая скорость реакции на внешние события
Датчики Исполнители

Системный
контроллер

Вычислители Обработчики
отказов

Пользовательский
интерфейс

Рис. 06_12

22
Паттерны событийного управления
При событийном подходе управление системами основано на внешних
событиях (событиях внешней среды) и на аварийных событиях,
возникших внутри системы.
Паттерн широковещательного управления
Имя Широковещательное управление
Описание Все события и сообщения поступают в обработчик, который передает
их конкретным адресатам. Адресатом является подсистема,
предварительно объявившая о своем интересе к событию. Адресат,
который обрабатывает данное событие, отвечает на него
Пример Иллюстрация системы широковещательного управления приведена на
рис. 6.13
Когда используется Данный подход эффективен при сетевой интеграции подсистем,
распределенных на разные компьютеры
Преимущества Простота изменения системы, легкость ее размещения
Недостатки Возможны конфликты в реакции на внешние события

Подсистема 1 Подсистема 2 ... Подсистема N

Обработчик событий и сообщений 23


Паттерн управления на основе прерываний
Имя Управление на основе прерываний
Описание В системе присутствует набор обработчиков. Специализация
обработчиков задается системой. Каждая категория прерываний
обслуживается своим обработчиком. Обработчик только регистрирует
прерывание, а затем передает управление заранее определенному
процессу
Пример Иллюстрация системы, управляемой прерываниями приведена на рис. 6.14
Когда Используется в системах реального времени со строгими требованиями по
используется времени реакции. Данный паттерн может быть скомбинирован с
паттерном Менеджер. Менеджер управляет нормальной работой системы,
а в критических ситуациях применяют управление, основанное на
прерываниях
Преимущества Быстрая реакция системы на внешние события
Недостатки Система сложна в программировании и проверке. При тестировании
системы затруднительно имитировать все прерывания. Число прерываний
ограничено используемой аппаратурой (после достижения предела,
связанного с аппаратными ограничениями, никакие другие прерывания не
обрабатываются)
Прерывания

Вектор ...
прерывания

Обработчик Обработчик Обработчик


1 3 N

Процесс Процесс Процесс 24


1 3 N
Разделение понятий
В 1972 году Э. Дейкстра ввел очень важный принцип проектирования —
разделение понятий (separation of concerns):
Любую сложную проблему проще понять, разделив ее на части, каждую
из которых можно решать и оптимизировать независимо.
Понятие — это черта (свойство, отличительная особенность), или поведение,
которое определяется как часть модели требований к ПО. Разделяя
понятия на небольшие и поэтому более управляемые части, мы
экономим усилия и время на решение проблемы.
Пусть С(x) — функция сложности решения проблемы x, T(x) — функция затрат
времени на решение проблемы x. Для двух проблем p1 и p2 из
соотношения С(p1) > С(p2) следует, что
T ( p1 )  T ( p2 ) (1)
Этот вывод интуитивно ясен: решение сложной проблемы требует большего
времени.
Из практики решения проблем человеком следует
C ( p1  p2 )  C ( p1 )  C ( p2 )
Отсюда, с учетом соотношения (1), запишем
T(p1 + p2) > T(p1) + T(p2). (2)
25
Модульность
Модульность — это наиболее общая демонстрация разделения
понятий. Программная система делится на именуемые и
адресуемые компоненты, часто называемые модулями, которые
затем интегрируются для совместного решения проблемы.
Модуль — фрагмент программного текста, являющийся строительным
блоком для физической структуры системы. Модуль состоит из
интерфейсной части и части-реализации.
Модульность — свойство системы, которая может подвергаться
декомпозиции на ряд внутренне связанных и слабо зависящих
друг от друга модулей.
По определению Г. Майерса модульность — свойство ПО,
обеспечивающее интеллектуальную возможность создания сколь
угодно сложной программы.
Возвращаясь к обсуждению разделения понятий, заключаем, что
путем последовательного дробления ПО можно добиться, что
затраты на разработку станут ничтожно малы.

26
Модульность
Однако это отражает лишь часть реальности — ведь здесь не
учитываются затраты на дальнейшую интеграцию модулей . С
увеличением количества модулей (и уменьшением их размера)
эти затраты также растут:

Стоимость Общая стоимость

Стоимость
интеграции

Стоимость модуля

Opt

Область Количество модулей


минимальной
стоимости

27
Информационная закрытость
Принцип информационной закрытости (автор — Д. Парнас,
1972) утверждает: содержание модулей должно быть
скрыто друг от друга. Модуль должен определяться и
проектироваться так, чтобы его содержимое (процедуры и
данные) было недоступно тем модулям, которые не
нуждаются в такой информации (клиентам):
Модуль

Интерфейс Алгоритм
Структура данных
Реализация интерфейса
Клиенты Размещение ресурсов
«Секрет»

Конкретное проектное решение


28
Информационная закрытость означает:
1. все модули независимы, обмениваются только
информацией, необходимой для работы;
2. доступ к операциям и структурам данных модуля
ограничен.
Достоинства информационной закрытости:
• обеспечивается возможность разработки модулей
различными, независимыми коллективами;
• обеспечивается легкая модификация системы
(вероятность распространения ошибок очень мала, так как
большинство данных и процедур скрыто от других частей
системы).
Идеальный модуль играет роль черного ящика, содержимое
которого невидимо клиентам. Он прост в использовании —
количество «ручек и органов управления» им невелико.
Его легко развивать и корректировать в процессе
сопровождения программной системы. Для обеспечения
таких возможностей система внутренних и внешних связей
модуля должна отвечать особым требованиям.

29
Связность модуля
Связность модуля (Cohesion) — это мера зависимости его частей.
Связность — внутренняя характеристика модуля. Чем выше
связность модуля, тем лучше результат проектирования, то есть
тем «черней» его ящик (капсула, защитная оболочка модуля),
тем меньше «ручек управления» на нем находится и тем проще
эти «ручки».
Для измерения связности используют понятие силы связности (СС).
Существует 7 типов связности:
1. Связность по совпадению (СС=0). В модуле отсутствуют явно
выраженные внутренние связи.
2. Логическая связность (СС=1). Части модуля объединены по
принципу функционального подобия. Например, модуль состоит
из разных подпрограмм обработки ошибок. При использовании
такого модуля клиент выбирает только одну из подпрограмм.
Недостатки:
• сложное сопряжение;
• большая вероятность внесения ошибок при изменении
сопряжения ради одной из функций.

30
3. Временная связность (СС=3). Части модуля не связаны,
но необходимы в один и тот же период работы системы.
Недостаток: сильная взаимная связь с другими модулями,
отсюда — сильная чувствительность к внесению
изменений.
4. Процедурная связность (СС=5). Части модуля связаны
порядком выполняемых ими действий, реализующих
некоторый сценарий поведения.
5. Коммуникативная связность (СС=7). Части модуля
связаны по данным (работают с одной и той же
структурой данных).
6. Информационная (последовательная) связность
(СС=9). Выходные данные одной части используются как
входные данные в другой части модуля.
7. Функциональная связность (СС=10). Части модуля
вместе реализуют одну функцию.

31
Отметим, что типы связности 1, 2, 3 — результат
неправильного планирования архитектуры, а тип
связности 4 — результат небрежного планирования
архитектуры приложения.

Характеристика связности модуля


Тип связности Сопровождаемость Роль модуля
Функциональная Черный ящик
Информационная лучшая Не совсем черный ящик
(последовательная) сопровождаемость
Коммуникативная Серый ящик
Процедурная Белый или просвечивающий ящик
Временная худшая
Логическая сопровождаемость Белый ящик
По совпадению

32
Определение связности модуля
правило параллельной цепи

Модуль

2 2 2
5 5 5
7 7 7
a b c

CCпармодуля = 7

33
Определение связности модуля
правило последовательной цепи

Модуль

2 5 7

a b c

CCпослмодуля = 2

34
Сцепление модулей
Сцепление (Coupling) — мера взаимозависимости модулей по
данным. Сцепление — внешняя характеристика модуля,
которую желательно уменьшать.
Количественно сцепление измеряется степенью сцепления
СЦ. Выделяют 6 типов сцепления.
1. Сцепление по данным (СЦ=1). Модуль A вызывает
модуль B.
Все входные и выходные параметры вызываемого
модуля — простые элементы данных:

A
Элементы Данных

35
2. Сцепление по образцу (СЦ=3). В качестве параметров
используются структуры данных:
A  
Структуры Данных

3. Сцепление по управлению (СЦ=4). Модуль A явно


управляет функционированием модуля B (с помощью
флагов или переключателей), посылая ему управляющие
данные: B

Флаг

Флаг
B

Флаг

Конец

36
4. Сцепление по внешним ссылкам (СЦ=5). Модули A и B
ссылаются на один и тот же глобальный элемент данных.
5. Сцепление по общей области (СЦ=7). Модули
разделяют одну и ту же глобальную структуру данных.
6. Сцепление по содержанию (СЦ=9). Один модуль прямо
ссылается на содержание другого модуля (не через его
точку входа). Например, коды их команд перемежаются
друг с другом.
  Общая M
A область
Структура
Данных N
B C

D E

На рисунке модули B и D сцеплены по содержанию, а модули


C, E и N сцеплены по общей области.

37
Сложность программной системы
В простейшем случае сложность системы определяется как
сумма мер сложности ее модулей. Сложность модуля
может вычисляться различными способами.
Например, М. Холстед (1977) предложил меру длины N
модуля:
N  n1 log 2 (n1 )  n2 log 2 (n2 )
где n1 — число различных операторов,  n2 — число различных
операндов.
В качестве второй метрики М. Холстед рассматривал объем
V модуля (количество символов для записи всех
операторов и операндов текста программы):
. 2  n1  n2 
V  N  log

Вместе с тем известно, что любая сложная система состоит из


элементов и системы связей между элементами и что
игнорировать внутрисистемные связи неразумно.
 
38
Том МакКейб (1976) при оценке сложности ПС предложил
исходить из топологии внутренних связей. Для этой цели он
разработал метрику цикломатической сложности:

V (G )  E  N  2
где E — количество дуг, а N — количество вершин в управляющем
графе ПС.
Это был шаг в нужном направлении. Дальнейшее уточнение
оценок сложности потребовало, чтобы каждый модуль мог
представляться как локальная структура, состоящая из
элементов и связей между ними.
Таким образом, при комплексной оценке сложности ПС
необходимо рассматривать меру сложности модулей, меру
сложности внешних связей (между модулями) и меру
сложности внутренних связей (внутри модулей). Традиционно
со внешними связями сопоставляют характеристику
«сцепление», а с внутренними связями — характеристику
«связность».

39
Характеристики иерархической структуры
программной системы
Иерархическая структура программной системы — основной
результат предварительного проектирования. Она
определяет состав модулей ПС и управляющие
отношения между модулями. В этой структуре модуль
более высокого уровня (начальник) управляет модулем
нижнего уровня (подчиненным).
m

Высота
Depth

Ширина
Width

40
Иерархическая структура не отражает процедурные
особенности программной системы, то есть
последовательность операций, их повторение, ветвления
и т. д. m

  Высота
Depth

Ширина
Width

Первичными характеристиками являются количество вершин


(модулей) и количество ребер (связей между модулями).
К ним добавляются две глобальные характеристики:
• высота — количество уровней управления;
• ширина — максимальное из количеств модулей,
размещенных на уровнях управления.
В нашем примере высота=4, ширина=6.

41
Локальными характеристиками модулей структуры являются
коэффициент объединения по входу и коэффициент
разветвления по выходу.
Коэффициент объединения по входу Fаn_in(i) — это
количество модулей, которые прямо управляют i-м
модулем.
Для модуля n: Fаn_in(n)=4.
  m

Высота
Depth

Ширина
Width

Коэффициент разветвления по выходу Fаn_out(i) — это


количество модулей, которыми прямо управляет i-й
модуль.
Для модуля m: Fаn_out(m)=3.

42
Как оценить качество структуры? Из практики проектирования
известно, что лучшее решение обеспечивается
иерархической структурой в виде дерева.
Степень отличия реальной проектной структуры от дерева
характеризуется невязкой структуры. Как определить
невязку?
Полный граф (complete graph) с n вершинами имеет
количество ребер
ec  n (n  1) / 2
а дерево (tree) с таким же количеством вершин — существенно
меньшее количество ребер
et  n  1
Тогда формулу невязки можно построить, сравнивая
количество ребер полного графа, реального графа и
дерева.

43
Для проектной структуры с n вершинами и e ребрами невязка
определяется по выражению:

e  et (e  n  1)  2 2  (e  n  1)
Nev   
ec  et n  (n  1)  2  (n  1) (n  1)  (n  2)

Значение невязки лежит в диапазоне от 0 до 1. Если Nev=0, то


проектная структура является деревом, если Nev=1, то
проектная структура — полный граф.
Невязка дает грубую оценку структуры. Для увеличения
точности оценки следует применить характеристики
связности и сцепления.
Хорошая структура должна иметь низкое сцепление и высокую
связность.

44
Л. Констентайн и Э. Йордан (1979) предложили оценивать
структуру с помощью коэффициентов Fаn_in(i) и
Fаn_out(i) модулей.
Большое значение Fаn_in(i) — свидетельство высокого
сцепления, так как является мерой зависимости модуля.
Большое значение Fаn_out(i) говорит о высокой
сложности вызывающего модуля. Причиной является то,
что для координации подчиненных модулей требуется
сложная логика управления.
Основной недостаток коэффициентов Fаn_in(i) и Fаn_out(i)
состоит в игнорировании веса связи. Здесь
рассматриваются только управляющие потоки (вызовы
модулей). В то же время информационные потоки,
нагружающие ребра структуры, могут существенно
изменяться, поэтому нужна мера, которая учитывает не
только количество ребер, но и количество информации,
проходящей через них.

45
С. Генри и Д. Кафура (1981) ввели информационные
коэффициенты ifаn_in(i) и ifаn_out(j). Они учитывают
количество элементов и структур данных, из которых i-й
модуль берет информацию, и которые обновляются j-м
модулем соответственно.
Информационные коэффициенты суммируются со
структурными коэффициентами sfаn_in(i) и sfаn_out(j),
которые учитывают только вызовы модулей.
В результате формируются полные значения коэффициентов:

Fan _ in (i )  sfan _ in (i )  ifan _ in (i )


Fan _ out ( j )  sfan _ out ( j )  ifan _ out ( j )

46
На основе полных коэффициентов модулей вычисляется
метрика общей сложности структуры:
n
S   length(i )  ( Fan _ in(i )  Fan _ out (i )) 2,
i 1

где length(i) — оценка размера i-го модуля (в виде LOC или FP-
оценки).

47