Главная » Мануалы

1 ... 20 21 22 23 24 25 26 ... 32

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

С точки зрения модульности структура, изображенная на рис. 6.1, в, имеет ряд преимуществ:

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

функциональная модульность потенциально очень высока, поскольку каждый правильно спроектированный модуль будет выполнять четко определенные функции и иметь понятную спецификацию;

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

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

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

1 Уровень N

(а) Прямое сцепление. (б) косвенное сцепление.

(в) Косвенное сцепление через модуль управления системой.

Рис. 6,2, Принципы межуровневого сцепления - представление информационного потока.

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

ПЕРЕДАЧА ПРИЕМ

О

Активныйпакет

ПЕРЕДАЧА ПРИЕМ

о

(aj Интерфейсное представление.

(б) Внутренняя структура tmnM лри наличии задач-курьеров.

Условные обозначения;

т - задача-курьер; М - ведущая задача.

Рис. 6.3. Прямое нисходящее сцепление уровней.

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

Что можно сказать о структуре всей системы? Для определе-

ния порядка обработки потоков данных, схематически показанных на рис. 6.2, рассмотрим структурные графы, отображающие различные типы сцепления между пакетами (рис. 6.3-6.5).

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

Нисходящая схема взаимодействия пакетов, изображенная

ПЕРЕДАЧА ПРИЕМ

ПЕРЕДАЧА ПРИЕМ

ПЕРЕДАЧА ПРИЕМ

(б) Внутренняя структура системы {в) Внутренняя структура при наличии задач-курьеров. системы с использованием

буферизующих задач.

Условные обозначения:

Т - задача-курьер;

В -буферизующая задача.

М - ведущая задача уровня.

Рис. 6i4, Прямое симметричное сцепление уровней.

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

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

На рис. 6.3, б, 6.4, б, в показано, каким образом канонические схемы взаимодействий задач, описанные в гл. 3 и изображенные на рис. 3.21, связаны со схемами взаимодействия непосредственно сцепленных пакетов, приведенными на рис. 6,3, а и 6.4, а соответственно. Использование задачи, осуществляющей двойную транспортировку данных (рис. 3.21,(5), приводит либо к нисходящей, либо к симметричной схеме взаимодействий, а в случае применения буферизующей задачи (рис. 3.21, з) получается симметричная структура взаимодействий пакетов. Таким образом, выбор между нисходящей (рис. 6.3, а) и симметричной (рис. 6.3, б) схемами зависит не только от внешних требований к пакетам, но основывается также и на компромиссе между возможными внутренними структурами. Как уже отмечалось в гл. 3, применение задач-курьеров обеспечивает условия для более гибкого подхода к внутреннему структурированию системы, чем использование буферизующей задачи, но требует порождения большого числа задач и может быть несколько менее эффективным (хотя в обоих случаях необходимо одинаковое число рандеву для передачи данных). Если применяется первый метод, то число задач может быть уменьшено при использовании единственной задачи-курьера для организации приема информации (рис. 3.18, г); реализация обращений для передачи данных возлагается при этом на задачи управляющего уровня. Однако анализ требований, предъявляемых в данном случае к блоку управления информационным потоком, показал, что такой подход непригоден для использования, поскольку при этом за

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

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

Автономный -активный пакет

Активный обслуживающий naKef, -реализующий интерфейс между уровнями пи (n~1j

(а) Независимые уровни,

сцепленные через обслуживании? МРАули,

u: гт

Активный пакет, р'еализующий функции секретаря системы

Вариант управляющего модуля

И

Транспортировочный пакет

Транспортировочный пакет

I

f6J Обслуживающие пакеты различных уровней, -

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

Рис. 6.5. Способы косвенного сцепления уровней.

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

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

Основываясь на результатах предыдущего обсуждения концепции модульности, при проектировании подсистемы СОММ мы остановимся на следующих предварительных решениях:

реализовать трехуровневую структуру, иллюстрируемую рис. 6.1, в;

использовать схему прямого сцепления модулей, изобра- Женную на рис. 6.2, а, 6.3 или 6.4.

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

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

6.4. Надежность

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

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

1) вследствие ошибок человека, включая

(а) неправильные команды или неверные ответные действия;

(б) неправильные данные;

2) из-за отказов канала связи, приводящих к

(а) искажению данных,

(б) потере данных,

(в) дублированию данных;

3) из-за отказов компонентов системы, включая

(а) отказ процессора,

(б) отказ линии связи,

(в) отказ какого-либо устройства,

(г) отказ узла надежности.

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

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

6.4.1. Корректность внутренней логики подсистемы

Буферизация при обмене данными является той частью подсистемы СОММ, проектирование и реализация которой сопряжены с наибольшим количеством ошибок. На рис. 6.6 представлен возможный граф потоков данных, поступающих в буфер обмена. На этом рисунке изображены модуль обработки событий Е и модули М, F, Р, описанные ниже. Кроме того, отдельно показаны модули S и В, осуществляющие управление пулом буферов визуальных сообщений и пулом кадров данных соответственно; в пулах имеются предварительно выделенные группы

Условные обозначения:

О > заполненные буферы О->>- свободные буферы

использованный буфер ТХ

.ftlAUOGUE

RXMSG

9 Исходный буфер RX

ТХ MSG

Кадр ЛанН11Х

Кадр данных (копил)

Иоиодный буфер ТХ

ИспользоваинЬ!Й буфер RX

Квитированный ТХ :или отвергнутый RX)

Исходный буфер RX

Пул свободных) кадровых буферов

Рис. 6.6. Поток кадров данных в подсистеме СОММ с совместно используемыми буферными пулами,

1 ... 20 21 22 23 24 25 26 ... 32