Понятие информационной системы

Статическое и динамическое удаленное обращение к методам

После того как клиент свяжется с объектом, он может через заместителя обратиться к методам объекта. Подобное удаленное обращение к методам (Remote Method Invocation, RMI) в части маршалинга и передачи параметров очень напоминает RPC. Основное различие между RMI и RPC состоит в том, что RMI, как говорилось ранее, в основном поддерживает внутрисистемные ссылки на объекты. Кроме того, отпадает необходимость в клиентских и серверных заглушках общего назначения. Вместо них мы можем использовать значительно более удобные в работе и специфические для объектов заглушки, которые мы также обсуждали.

Стандартный способ поддержки RMI -- описать интерфейсы объектов на языке определения интерфейсов, так же как в RPC. Однако с тем же успехом мы можем использовать объектный язык, например Java, который обеспечивает автоматическую генерацию заглушек. Такой подход к применению предопределенных определений интерфейсов часто называют статическим обращением (static invocation). Статическое обращение требует, чтобы интерфейсы объекта при разработке клиентского приложения были известны. Также оно предполагает, что при изменении интерфейса клиентское приложение перед использованием новых интерфейсов будет перекомпилировано.

В качестве альтернативы обращение к методам может осуществляться более динамичным образом. В частности, иногда удобнее собрать параметры обращения к методу во время исполнения. Этот процесс известен под названием динамического обращения (dynamic invocation). Основное его отличие от статического обращения состоит в том, что во время выполнения приложение выбирает, какой метод удаленного объекта будет вызван. Динамическое обращение обычно выглядит следующим образом:

Здесь object идентифицирует распределенный объект; method -- параметр, точно задающий вызываемый метод; input_parameters -- структура данных, в которой содержатся значения входных параметров метода; output_parameters -- структура данных, в которой хранятся возвращаемые значения.

В качестве примера рассмотрим добавление целого числа int к объекту fobject файла. Для этого действия объект предоставляет метод append. В этом случае статическое обращение будет иметь вид:

Здесь операция id(append) возвращает идентификатор метода append. Для иллюстрации динамического обращения рассмотрим браузер объектов, используемый для просмотра наборов объектов. Предположим, что этот браузер поддерживает удаленное обращение к объектам. Это будет означать, что браузер в состоянии выполнить привязку к распределенному объекту и предоставить пользователю интерфейс с объектом. Пользователю после этого может быть предложено выбрать метод и ввести значения его параметров, после чего браузер сможет произвести действительное обращение. Обычно подобные браузеры объектов разрабатываются так, чтобы они поддерживали любые возможные интерфейсы. Такой подход требует исследования интерфейсов во время выполнения и динамического создания обращений к методам.

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

7. Связь посредством сообщений

Вызовы удаленных процедур и обращения к удаленным объектам способствуют сокрытию взаимодействия в распределенных системах, то есть повышают прозрачность доступа. К сожалению, ни один из этих механизмов не идеален. В частности, в условиях, когда нет уверенности в том, что принимающая сторона в момент выполнения запроса работает, приходится искать альтернативные пути обмена. Кроме того, синхронную по определению природу RPC и RMI, при которой на время осуществления операции необходимо блокировать клиента, временами тоже хочется заменить чем-то другим.

Это «что-то другое» -- обмен сообщениями. В этом разделе мы сосредоточимся на использовании в распределенных системах взаимодействия на основе сообщений.

Сохранность и синхронность во взаимодействиях

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

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

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

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

Система электронной почты -- это типичный пример сохранной связи (persistent communication). При сохранной связи сообщение, предназначенное для отсылки, хранится в коммуникационной системе до тех пор, пока его не удастся передать получателю. Если отталкиваться от рисунка, можно сказать, сообщение сохраняется на коммуникационном сервере до тех пор, пока его не удастся передать на следующий коммуникационный сервер. Поэтому у отправляющего сообщение приложения нет необходимости после отправки сообщения продолжать работу. Аналогично, у приложения, принимающего сообщения, также нет необходимости находиться в рабочем состоянии во время отправки сообщения.

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

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

Помимо сохранной и нерезидентной связи существует деление на синхронную и асинхронную связь. Характерной чертой асинхронной связи (asynchronous communication) является немедленное после отправки письма продолжение работы отправителя. Это означает, что письмо сохраняется в локальном буфере передающего хоста или на ближайшем коммуникационном сервере. В случае синхронной связи (synchronous communication) отправитель блокируется до того момента, пока его сообщение не будет сохранено в локальном буфере принимающего хоста или доставлено реальному получателю. Наиболее жесткая форма синхронного взаимодействия предполагает, что отправитель остается блокированным и на время обработки его сообщения получателем.

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

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

Нерезидентная синхронная связь существует в различных вариантах. В наиболее слабой форме, основанной на подтверждениях приема сообщений, отправитель блокируется до тех пор, пока сообщение не окажется в локальном буфере принимающего хоста. После получения подтверждения отправитель продолжает свою работу. В ориентированной на доставку нерезидентной синхронной связи отправитель блокируется до тех пор, пока сообщение не будет доставлено получателю для дальнейшей обработки. Мы рассматривали эту форму синхронного поведения при обсуждении асинхронных вызовов RPC. При асинхронных вызовах RPC клиент синхронизируется с сервером, ожидая, пока его запрос будет принят на дальнейшую обработку. Наиболее жесткая форма -- ориентированная на ответ нерезидентная синхронная связь -- предполагает блокировку отправителя до получения ответного сообщения с другой стороны, как в поведении запрос-ответ при взаимодействии клиент-сервер. Эта схема характерна также для механизмов RPC и RMI.

Все сочетания сохранности и синхронности при взаимодействиях показаны на рис. 2.21.

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

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

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

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

Должно быть понятно, что выбор исключительно между нерезидентным и сохранным типами связи во многих случаях неприемлем. Аналогично, только синхронный и асинхронный типы связи -- это еще не все. В зависимости от задач распределенной системы ей могут потребоваться все возможные типы связи. Ранее мы говорили в основном о нерезидентной синхронной связи -- RPC и RMI. Другие формы взаимодействия, как правило, представлены системами, работающими на основе передачи сообщений.

Связь на основе потоков данных

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

Однако существуют формы взаимодействия, в которых временные характеристики имеют решающее значение. Рассмотрим, например, поток аудиоданных, состоящий из последовательности 16-битных выборок, каждая из которых представляет собой амплитуду звуковой волны в импульсно-кодовой модуляции. Предположим также, что поток аудиоданных имеет качество компакт-дисков, а это значит, что исходный звук был оцифрован с частотой 44 100 Гц. Для воспроизведения звука необходимо, чтобы выборки аудиопотока проигрывались в том же порядке, в котором они представлены в потоке данных, и с интервалами, ровно по 1/44100 с. Воспроизведение с другой скоростью создаст неверное представление об исходном звуке.

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

Поддержка непрерывных сред

Поддержка обмена критичной к временным характеристикам передачи информации часто сводится к поддержке непрерывных сред. Под средой понимается то, что несет информацию. Сюда могут входить среды передачи и хранения, среда представления, например монитор, и т. д. Важнейшая характеристика среды -- способ представления информации. Другими словами, как информация кодируется в компьютерной системе? Для различных типов информации используются различные представления. Так, текст обычно кодируется символами ASCII или Unicode. Изображения могут быть представлены в различных форматах, например GIF или JPEG. Аудиопотоки в компьютерных системах могут кодироваться, например, с помощью 16-битных выборок, использующих импульсно-кодовую модуляцию.

В непрерывной среде представления (continuous representation media) временные соотношения между различными элементами данных лежат в основе корректной интерпретации смысла данных. Мы уже давали пример получения звука при воспроизведении аудиопотока. В качестве другого примера рассмотрим представление движения. Движение может быть представлено в виде серии картинок, причем последовательно идущие картинки должны воспроизводиться в течение одинакового срока T, обычно составляющего 30-40 мс на картинку. Правильное воспроизведение требует не только показа картинок в нужной последовательности, но и поддержания постоянной частоты показа -- 1/T картинок в секунду.

В отличие от непрерывной среды дискретная среда представления (discrete representation media), характеризуется тем, что временные соотношения между элементами данных не играют фундаментальной роли в правильной интерпретации данных. Типичными примерами дискретной среды являются представления текста и статических изображений, а также объектный код и исполняемые файлы.

Поток данных

Для обмена критичной ко времени передачи информацией распределенные системы обычно предоставляют поддержку потоков данных (data streams, или просто streams). Поток данных есть не что иное, как последовательность элементов данных. Потоки данных применимы как для дискретной, так и для непрерывной среды представления. Так, каналы UNIX или соединения TCP/IP представляют собой типичные примеры дискретных потоков данных (байт-ориентированных). Воспроизведение звукового файла обычно требует непрерывного потока данных между файлом и устройством воспроизведения.

Временные характеристики важны для непрерывных потоков данных. Для поддержания временных характеристик часто приходится выбирать между различными режимами передачи. В асинхронном режиме передачи (asynchronous transmission mode) элементы данных передаются в поток один за другим, но на их дальнейшую передачу никаких ограничений в части временных характеристик не вводится. Это традиционный вариант для дискретных потоков данных. Так, файл можно преобразовать в поток данных, но выяснять точный момент окончания передачи каждого элемента данных чаще всего бессмысленно.

В синхронном режиме передачи (synchronous transmission mode) для каждого элемента в потоке данных определяется максимальная задержка сквозной передачи. Если элемент данных был передан значительно быстрее максимально допустимой задержки, это не важно. Так, например, датчик может с определенной частотой измерять температуру и пересылать эти измерения по сети оператору. В этом случае временные характеристики могут вызвать наш интерес, если время сквозного прохождения сигнала по сети гарантированно ниже, чем интервал между измерениями, но никому не повредит, если измерения будут передаваться значительно быстрее, чем это действительно необходимо.

И, наконец, при изохронном режиме передачи (isochronous transmission mode) необходимо, чтобы все элементы данных передавались вовремя. Это означает, что передача данных ограничена максимально, а также минимально допустимыми задержками, также известными под названием предельного дрожания. Изохронный режим передачи, в частности, представляет интерес для распределенных систем мультимедиа, поскольку играет значительную роль в воспроизведении аудио- и видеоинформации. Далее мы коснемся только непрерывных потоков данных.

Потоки данных могут быть простыми или комплексными. Простой поток данных (simple stream) содержит только одну последовательность данных. Комплексный поток данных (complex stream) состоит из нескольких связанных простых потоков, именуемых вложенными потоками данных (substreams). Взаимодействие между вложенными потоками в комплексном потоке часто также зависит от времени. Так, например, стереозвук может передаваться посредством комплексного потока, содержащего два вложенных потока, каждый из которых используется для одного аудиоканала. Важно отметить, что эти два вложенных потока постоянно синхронизированы. Другими словами, элементы данных каждого из потоков должны передаваться попарно для получения стереоэффекта. Другим примером комплексного потока данных может быть поток данных для фильма. Такой поток мог бы состоять из одного видеопотока и двух аудиопотоков для передачи стереофонической звуковой дорожки к фильму. Четвертый поток мог бы содержать субтитры для глухих или синхронный перевод на другой, нежели в звуковой дорожке, язык. И вновь необходима синхронизация вложенных потоков. При нарушениях синхронизации нарушается нормальное воспроизведение фильма.

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

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

Главной проблемой групповой рассылки потоков данных являются разные требования разных приемников к качеству потока. Рассмотрим, например, источник передачи высококачественного кино со стереозвуком. Он может потребовать комплексного потока данных, содержащего вложенный поток для видео, по которому с частотой 50 Гц передается картинка, и два вложенных потока для аудио с качеством на уровне компакт-дисков. Даже при использовании современных технологий сжатия комплексный поток может потребовать скорости передачи порядка 30Ч106 бит/с. Не всякий приемник в состоянии обработать такой объем данных. Поэтому поток должен быть настроен на фильтрацию, которая приводит в соответствие качество входящего потока и отличное от него качество исходящего потока, как показано на рис. 2.30.

8. Оценка технических параметров ИС и ее компонент

Общая постановка задачи

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

В зависимости от целей исследования и этапов жизненного цикла ИС дефектологические свойства разделяют на дефектогенность, дефектабельность и дефектоскопичность.

Дефектогенность определяется влиянием следующих факторов:

- численностью разработчиков ИС, их профессиональными психофизиологическими характеристиками;

- условиями и организацией процесса разработки ИС;

- характеристиками инструментальных средств и комплексов ИС;

- сложностью задач, решаемых ИС;

- степенью агрессивности внешней среды (потенциальной возможностью внешней среды вносить преднамеренные дефекты, например, воздействие вирусов).

Дефектабельность характеризует наличие дефектов ИС и определяется их количеством и местонахождением. Другими факторами, влияющими на дефектабельность, являются:

- структурно-конструктивные особенности ИС;

- интенсивность и характеристики ошибок, приводящих к дефектам.

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

- количество, типы и характер распределения дефектов;

- устойчивость ИС к проявлению дефектов;

- характеристики средств контроля и диагностики дефектов;

- квалификация обслуживающего персонала.

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

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

- общая полезность;

- исходная полезность;

- удобство эксплуатации.

Далее формируются показатели, к числу которых могут быть отнесены:

- практичность;

- целостность;

- корректность;

- удобство обслуживания;

- оцениваемость;

- гибкость;

- адаптируемость;

- мобильность;

- возможность взаимодействия.

Каждому показателю качества ставится в соответствие группа критериев. Для указанных показателей приведем возможные критерии. Надо отметить, что один и тот же критерий может характеризовать несколько показателей:

- практичность -- работоспособность, возможность обучения, коммуникативность, объем ввода, скорость ввода-вывода;

- целостность -- регулирование доступа, контроль доступа;

- эффективность -- эффективность использования памяти, эффективность функционирования;

- корректность -- трассируемость, завершенность, согласованность;

- надежность -- точность, устойчивость к ошибкам, согласованность, простоту;

- удобство обслуживания -- согласованность, простоту, краткость, информативность, модульность;

- оцениваемость -- простоту, наличие измерительных средств, информативность, модульность;

- гибкость -- распространяемость, общность, информативность, модульность;

- адаптируемость -- общность, информативность, модульность, аппаратную независимость, программную независимость;

- мобильность -- информативность, модульность, аппаратную независимость, программную независимость;

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

С помощью метрик можно дать количественную или качественную оценку качества ИС. Различают следующие виды метрических шкал для измерения критериев. информационный приложение сервер связь

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

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

Третий тип -- метрики, которым соответствуют номинальная, или категорированная шкала, определяющая наличие рассматриваемого свойства или признака у рассматриваемого объекта без учета градаций по этому признаку.

Развитием иерархического подхода является представленная на рис. 12.1 модель классификации критериев качества информационных систем. С помощью функциональных критериев оценивается степень выполнения ИС основных целей или задач. Конструктивные критерии предназначены для оценки компонент ИС, не зависящих от целевого назначения.

Одним из путей обеспечения качества ИС является сертификация. В США Радиотехническая комиссия по аэронавтике в своем руководящем документе определяет процесс сертификации следующим образом:

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

В настоящее время не существует стандартов, полностью удовлетворяющих оценке качества ИС. В западноевропейских странах имеется ряд стандартов, определяющих основы сертификации программных систем. Стандарт Великобритании (BS750) описывает структурные построения программных систем, при соблюдении которых может быть получен документ, гарантирующий качество на государственном уровне. Имеется международный аналог указанного стандарта (ISO9000) и аналог для стран-членов НАТО (AQAP1). Существующая в нашей стране система нормативно-технических документов относит программное обеспечение к «продукции производственно-технического назначения», которая рассматривается как материальный объект. Однако программное обеспечение является скорее абстрактной нематериальной сферой. Существующие ГОСТы (например, ГОСТ 28195-89 «Оценка качества программных средств. Общие положения») явно устарели и являются неполными.

Стандарты управления качеством промышленной продукции

Международные стандарты серии ISO 9000 разработаны для управления качеством продукции, их дополняют стандарты серии ISO 14000, отражающие экологические требования к производству промышленной продукции. Хотя эти стандарты непосредственно не связаны с CALS-стандартами, их цели -- совершенствование промышленного производства, повышение его эффективности -- совпадают.

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

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

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

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

В стандартах ISO 9000 используется определение качества из стандарта ISO 8402: «Качество -- совокупность характеристик продукта, относящихся к его способности удовлетворять установленные или предполагаемые потребности». Аналогичное определение содержится в ГОСТ 15467-79: «Качество продукции -- это совокупность свойств продукции, обусловливающих ее пригодность удовлетворять определенные потребности в соответствии с ее назначением». В ISO 9000 вводится понятие системы качества (QS -- Quality System), под которой понимают документальную систему с руководствами и описаниями процедур достижения качества. Другими словами, система качества есть совокупность организационной структуры, ответственности, процедур, процессов и ресурсов, обеспечивающая осуществление общего руководства качеством. Система качества обычно представляет собой совокупность трех слоев документов:

- описание политики управления для каждого системного элемента;

- описание процедур управления качеством (что, где, кем и когда должно быть сделано);

- тесты, планы, инструкции и т. п.

Сертификация предприятий по стандартам ISO 9001-9003 выполняется некоторой уполномоченной внешней организацией. Наличие сертификата качества -- одно из важных условий для успеха коммерческой деятельности предприятий.

Вторичные стандарты включают в себя:

- ISO 9000 -- основные понятия, руководство по применению ISO 9001;

- ISO 9004 -- элементы систем управления качеством. Поддерживающие стандарты предназначены для развития и установки систем качества:

- ISO 10011 -- аудит, критерии для аудита систем качества ;

- ISO 10012 -- требования для измерительного оборудования;

- ISO 10013 -- пособие для развития руководств по управлению качеством.

Часть этих стандартов утверждена как государственные стандарты Российской Федерации. В частности, к ним относятся:

ГОСТ Р ИСО 9001-96 «Системы качества. Модель обеспечения качества при проектировании, разработке, производстве, монтаже и обслуживании»;

ГОСТ Р ИСО 9002-96 «Системы качества. Модель обеспечения качества при производстве, монтаже и обслуживании»;

ГОСТ Р ИСО 9003-96 «Системы качества. Модель обеспечения качества при окончательном контроле и испытаниях».

В настоящее время разработана новая версия стандартов серии ISO 9000 под названием ISO 9000:2000 Quality management systems (системы управления качеством), в которую включены следующие документы:

ISO 9000:2000 Fundamentals and vocabulary (основы и терминология);

ISO 9001:2000 Requirements (требования);

ISO 9004:2000 Guidelines for performance improvement (руководство по развитию).

Главное отличие новой версии от предыдущей состоит в том, что она обусловлена стремлением упростить практическое использование стандартов, направлена на их лучшую гармонизацию и заключаются в следующем.

В стандарте ISO 9001 минимизируется объем требований к системе качества. Стандарты ISO 9002-9003 из новой версии исключаются. Расширяется круг контролируемых ресурсов, в их число включены такие элементы, как информация, коммуникации, инфраструктура.

Введенные в стандарте ISO 9004 двадцать элементов качества сворачиваются в четыре группы:

- распределение ответственности (management responsibility);

- управление ресурсами (resource management);

- реализация продукции и услуг (product and/or service realization);

- измерения и анализ (measurement, analysis, and improvement).

Сертификация предприятий по стандартам ISO 9001-9003 выполняется некоторой уполномоченной внешней организацией. Наличие сертификата качества -- одно из важных условий для успеха коммерческой деятельности предприятий.

Стандарты ISO 14000 являются также системой управления влиянием на окружающую среду; они, как и ISO 9000, реализуются в процессе сертификации предприятий, задают процедуры управления и контроль документации, аудит, подразумевают соответствующее обучение и сбор статистики. Кроме требований заказчиков и покупателей, в них воплощаются внутренние требования организации.

9. Отказоустойчивость

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

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

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

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

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

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

Основные концепции

Чтобы понять роль отказоустойчивости в распределенных системах, сначала необходимо выяснить, что для распределенных систем означает «быть отказоустойчивыми». Отказоустойчивость тесно связана с понятием надежных систем (dependable systems). Надежность -- это термин, охватывающий множество важных требований к распределенным системам, включая:

- доступность (availability);

- безотказность (reliability);

- безопасность (safety);

- ремонтопригодность (maintainability).

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

Под безотказностью имеется в виду свойство системы работать без отказов в течение продолжительного времени. В противоположность доступности безотказность определяется в понятиях временного интервала, а не момента времени. Система с высокой безотказностью -- это система, которая, скорее всего, будет непрерывно работать в течение относительно долгого времени. Между безотказностью и доступностью имеется небольшая, но существенная разница. Если система отказывает на одну миллисекунду каждый час, она имеет доступность порядка 99,9999 %, но крайне низкую безотказность. С другой стороны, система, которая никогда не отказывает, но каждый август отключается на две недели, имеет высокую безотказность, но ее доступность составляет всего 96 %. Эти две характеристики -- не одно и то же.

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

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

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

Говорят, что система отказывает (fail), если она не в состоянии выполнять свою работу. В частности, если распределенная система создавалась для предоставления пользователям некоторых услуг, то система будет считаться находящейся в состоянии отказа в том случае, если она не сможет предоставлять все или некоторые услуги. Ошибкой (error) называется такое состояние системы, которое может привести к ее неработоспособности. Так, например, при передаче пакетов по сети может случиться, что некоторые пакеты, пришедшие к получателю, окажутся поврежденными. Повреждения в данном случае будут означать, что получатель может неверно прочесть значения битов (например, 1 вместо 0) или оказаться не в состоянии определить сам факт прихода пакета.

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

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

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

Перемежающиеся отказы (intermittent faults) появляются и пропадают, «когда захотят», а потом появляются снова и т. д. Перемежающиеся отказы нередко бывают вызваны потерей контакта в разъеме. Из-за трудностей в диагностике перемежающиеся отказы часто вызывают сильное раздражение. Обычно когда приходит ремонтник, система работает просто прекрасно.

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

Модели отказов

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

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

Таблица Различные типы отказов

Тип отказа	Описание
Поломка Пропуск данных Пропуск приема Пропуск передачи Ошибка синхронизации Ошибка отклика Ошибка значения Ошибка передачи состояния Произвольная ошибка	Сервер перестал работать, хотя до момента отказа работал правильно Сервер неправильно реагирует на входящие запросы Сервер неправильно принимает входящие запросы Сервер неправильно отправляет сообщения Реакция сервера происходит не в определенный интервал времени Отклик сервера неверен Сервер возвращает неправильное значение Сервер отклоняется от верного потока управления Сервер отправляет случайные сообщения в случайные моменты времени

Поломка (crash failure) имеет место при внезапной остановке сервера, при этом до момента остановки он работает нормально. Важная особенность поломки состоит в том, что после остановки сервера никаких признаков его работы не наблюдается. Типичный пример поломки -- полное зависание операционной системы, когда единственным решением проблемы является перезагрузка. Многие операционные системы персональных компьютеров претерпевают поломки настолько часто, что люди уже начинают полагать, что для них это обычное дело. В этом смысле перенос кнопки Reset с задней части корпуса компьютера на переднюю панель был, несомненно, оправдан.

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

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

Следующий класс ошибок связан с синхронизацией. Ошибки синхронизации (timing failures) возникают при ожидании ответа дольше определенного временного интервала. Как мы говорили во время обсуждения изохронных потоков данных, слишком раннее предоставление данных легко может вызвать у принимающей стороны проблемы, связанные с отсутствием места в буфере для хранения получаемых данных. Чаще, однако, сервер отвечает слишком поздно, в этом случае говорят, что произошла ошибка производительности (performance failure).

...