Неправильный перевод информации как причина ошибок в программных средствах (стр. 6 из 7)

Основные задачи разработки архитектуры ПС:

• выделение программных подсистем и отображение на них внешних функций (заданных во внешнем описании) ПС;

• определение способов взаимодействия между выделенными программными подсистемами.

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

6.2. Основные классы архитектур программных средств

Различают следующие основные классы архитектур программных средств [35]:

• цельная программа;

• комплекс автономно выполняемых программ;

• слоистая программная система;

• коллектив параллельно действующих программ.

Цельная программа представляет вырожденный случай архитектуры ПС: в состав ПС входит только одна программа. Такую архитектуру выбирают обычно в том случае, когда ПС должно выполнять одну ка-

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

Комплекс автономно выполняемых программ состоит из набора программ, такого, что:

• любая из этих программ может быть активизирована (запущена) пользователем;

• при выполнении активизированной программы другие программы этого набора не могут быть активизированы до тех пор, пока не закончит выполнение активизированная программа;

• все программы этого набора применяются к одной и той же информационной среде.

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

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

• на каждом слое ничего не известно о свойствах (и даже существовании) последующих (более высоких) слоев;

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

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

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

В качестве примера рассмотрим использование такой архитектуры для построения операционной системы. Такую архитектуру применил Дейкстра при построении операционной системы THE [60]. Эта операционная система состоит из четырёх слоев (см. рис. 6.1). На нулевом слое производится обработка всех прерываний и выделение централь-

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

Прикладные программы

3: Управление входными и выходными потоками данных

2: Обеспечение связи с консолью оператора

1: Управление памятью

0: Диспетчеризация и синхронизация процессов

Компьютер

Рис. 6.1. Архитектура операционной системы THE

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

Простейшей разновидностью такой архитектуры является конвейер. Возможности для организации конвейера имеются, например, в операционной системе UNIX [28]. Конвейер представляет собой последова-

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

Рис. 6.2. Конвейер параллельно действующих программ

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

Пример программной системы с портами сообщений приведен на рис. 6.3. Порт Uможет рассматриваться как порт вводных сообщений для представленного на этом рисунке коллектива параллельно действующих программ, а порт W - как порт выводных сообщений для этого коллектива программ.

Рис. 6.3. Пример программной системы с портами сообщений

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

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

6.3. Архитектурные функции

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