Надежность архитектуры программного обеспечения

Зависимости компонентов позволяют неисправности распространяться из компонента, в котором она происходит, к другим компонентам.

Это распространение может вызывать сбои в цепочке (или в дереве) компонентов. Обнаружение отказов зависит от выполненных тестов или от количества и типа запросов пользователя. Ошибка может произойти в любом компоненте. Она может быть вызвана сбоем, переданным другим компонентом, или это может быть сбой, произошедший именно в этом компоненте. Ошибка может быть прослежена через цепочку (или дерево) зависимости компонентов для устранения всех сбоев, которые связаны с этой ошибкой.

Уровни архитектуры

Надежность ПО зависит от уровня, соответствующего различным компонентам и их зависимостям. В связи с тем, где произошел сбой, длительность отказа системы и его влияние на надежность системы различны. Сбой может происходить на различных уровнях архитектуры, в модуле, процессе, интерфейсе компонента или в связи и механизме контроля.

Число архитектурных уровней в модели архитектуры ПО зависит от частного проекта системы. Как показано на рис. 1.1, каждый архитектурный уровень содержит граф компонентов каждого типа (граф модулей и граф процессов). Процессы используют модули в течение их выполнения: эти зависимости показаны прерывистыми линиями. Процесс может использовать несколько различных модулей, и модуль может использоваться несколькими различными процессами. Граф процессов представляет динамическую зависимость компонентов, а граф модулей - статическую зависимость компонентов. Эта архитектура может быть расширена до произвольного числа уровней с графами компонентов на различных уровнях.

В модели архитектуры граф процессов находится на самом верхнем уровне, а графы остальных компонентов, например функции, примитивы, данные, структуры и сообщения - на отдельных уровнях.

В архитектуре программного обеспечения можно выделить следующие архитектурные уровни:

  • • процессы;
  • • функции;
  • • примитивы;
  • • данные;
  • • структуры;
  • • сообщения.

Процесс - это компонент, занимающий ячейку в таблице процессов процессора. Процесс может также являться компонентом, который управляется с помощью примитивов операционной системы. Для каждого процесса в системе собрана информация относительно функций, примитивов, данных, структур и сообщений, используемых процессом. Функции определены в той же самой подсистеме, что и процесс. Примитивы включают все функции вне подсистемы, в которой они определены, и вызываются функциями в процессе. Данные вызываются функциями в процессе. Структуры включают все структуры данных, вызванные функциями в процессе. Сообщения включают все данные, вызванные функциями в процессе.

Архитектурные уровни в модели архитектуры ПО

Рис. 1.1. Архитектурные уровни в модели архитектуры ПО

Для числа изменений, вызванных неисправностями в модулях подсистемы ПО, собираются дополнительные данные. Используя эти данные, а также информацию относительно архитектуры, процессов системы, и дефектных изменений модуля, можно оценивать и изменять надежность архитектуры.

В крупных современных системах обработки информации часто используются системы управления базами данных (СУБД) как компонент архитектуры. Быстродействие и надежность СУБД значительно влияют на надежность всей системы, поэтому оптимизации быстродействия СУБД должно уделяться больше внимания на всех стадиях разработки ПО.

Среднее время простоя системы

Среднее время простоя системы в архитектуре зависит от условных и безусловных вероятностей сбоев на всех уровнях архитектуры и от среднего времени доступа, анализа и восстановления сбойных компонентов.

Время устранения сбоя равно времени, которое требуется для доступа, анализа, восстановления, это означает, что время восстановления меньше, чем время устранения сбоя. Если используется автоматическое восстановление и компонент не содержит сбоев, то он рассматривается как восстановленный компонент. Ошибка того же типа, что была устранена, считается новой ошибкой.

Среднее время простоя системы вычисляется для всех архитектурных уровней и всех компонентов на каждом уровне. Для каждого архитектурного уровня в ПО вероятность использования каждого компонента зависит от вероятности сбоя компонента и средних времен анализа, доступа и восстановления для этого компонента.

Вдобавок сбойный компонент может вызывать сбои в зависящих от него компонентах, как на других уровнях архитектуры, так и на том же самом уровне. Поэтому для каждого отдельного уровня архитектуры и для всех компонентов надо учитывать условную вероятность появления сбоя и относительные времена доступа, анализа и восстановления этих компонентов. Также для одного уровня и для всех компонентов условная вероятность появления сбоя зависит от относительных времен доступа, анализа и восстановления этих компонентов.

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

В каждом отдельном архитектурном уровне и для всех компонентов условная вероятность работы без сбоев зависит от относительного времени использования этих компонентов.

Коэффициент готовности архитектуры

программного обеспечения

Время появления сбоя (MTTF) и среднее время простоя системы (TR) характеризуют возможность архитектуры программного обеспечения по обеспечению потенциальной производительности и для достижения этой производительности после отказа. Первый показатель связан с понятием отказа ПО, а второй - с понятием восстановления. Время появления сбоя позволяет пользователю оценить возможность решения той или иной задачи. Среднее время простоя информирует о том, когда отказавшая система будет восстановлена.

Время появления сбоя и среднее время простоя системы характеризуют поведение архитектуры ПО на начальном этапе работы вычислительной системы. Эти показатели не информативны при оценке работы архитектуры в течение длительного времени функционирования.

Готовность системы к эксплуатации в данный момент времени определяется как вероятность того, что система нормально функционирует в данный момент времени.

Коэффициент надежности архитектуры

программного обеспечения

Надежность программного обеспечения определяется как вероятность того, что программное обеспечение функционирует без сбоев, в определенной операционной среде, в течение определенного промежутка времени. Коэффициент надежности архитектуры ПО можно оценить по формуле:

где М- число уровней архитектуры ПО; Ni - число компонент на уровне /, / = 1, ..., М; PUjj - вероятность использования компонента; Щ - надежность компонента.

Оценить данные параметры на фазе разработки архитектуры невозможно, численные показатели в модель берутся непосредственно на фазах кодирования и тестирования.

 
Посмотреть оригинал
< Пред   СОДЕРЖАНИЕ   ОРИГИНАЛ     След >