Модифицируемость

Общие сценарии готовности

Ниже описываются элементы сценария готовности, которые, в частности, показаны на рис. 4.2.

♦ Источник стимула. Признаки отказов и неисправностей делятся на внутренние и внешние — в зависимости от их характера система может демонстрировать разные реакции. В нашем примере непредвиденное сообщение приходит извне.

♦ Стимул. Неисправности подразделяются на несколько типов.

- Бездействие. Компонент не реагирует на входные данные.

- Аварийная ситуация. Компонент регулярно демонстрирует бездействие. О Несоблюдение временных требований. Компонент реагирует, но отклик происходит слишком рано или слишком поздно.

- Неверная реакция. Компонент реагирует, но выдает неверное значение.

В сценарии, изображенном на рис. 4.3, стимулом является поступление непредвиденного сообщения. Это — пример отклонения от временных тре-бований. Компонент сгенерировал сообщение не вовремя.

♦ Артефакт. Под артефактом имеется в виду ресурс, к которому предъявлены требования по готовности, — например, процессор, канал обмена данными, процесс или память.

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

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

♦ Количественная мера реакции. Этот показатель выражает процент готовности, продолжительность восстановления, периоды, в течение которых система должна пребывать в состоянии готовности, и продолжительность готовности. Согласно схеме на рис. 4.3, простоя в результате поступления непредвиденного сообщения не происходит.

Возможные значения всех элементов сценария готовности представлены в табл. 4.1.

Качество модифицируемости выражает стоимость внесения изменений. Оно решает два вопроса.

1. Под воздействием чего артефакт может быть изменен? Изменения можно внести в любой аспект системы — как правило, это ее функции, платформа (аппаратная часть, операционная система, промежуточное программное обеспечение и т. д.), условия, в которых функционирует система (системы, с которыми она взаимодействует, протоколы, при помощи которых обменивается информацией с внешним миром, и т. д.), ее атрибуты качества (производительность, надежность системы или даже предполагаемые в будущем изменения) и возможности (количество пользователей, одновременных операций и т. д.). Некоторые элементы системы — например, пользовательский интерфейс и платформа — в этом отношении настолько выделяются из числа других, что их мы рассмотрим отдельно. Категория изменения платформы имеет также другое название — переносимость. Изменения могут заключаться в добавлении, удалении и модификации этих аспектов.

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

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

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

Дата добавления: 2015-04-25