Понятие архитектуры и задачи ее описания. Основные классы архитектур программ-ных средств. Взаимодействие между подсистемами и архитектурные функции. Контроль архитектуры программных средств.
1. Понятие архитектуры программного средства. Архитектура ПС это его строение как оно видно (или должно быть видно) извне его, т.е. представление ПС как системы, состоящей из некоторой совокупности взаимодействую-щих подсистем. В качестве таких подсистем выступают обычно отдельные программы. Разра-ботка архитектуры является первым этапом борьбы со сложностью ПС, на котором реализует-ся принцип выделения относительно независимых компонент. Основные задачи разработки архитектуры ПС: • Выделение программных подсистем и отображение на них внешних функций (заданных во внешнем описании) ПС; • определение способов взаимодействия между выделенными программными подсистемами. С учетом принимаемых на этом этапе решений производится дальнейшая конкретизация и функциональных спецификаций.
2. Основные классы архитектур программных средств. Различают следующие основные классы архитектур программных средств: * цельная программа; * комплекс автономно выполняемых программ; * слоистая программная система; * коллектив параллельно выполняемых программ. Цельная программа представляет вырожденный случай архитектуры ПС: в состав ПС входит только одна программа. Такую архитектуру выбирают обычно в том случае, когда ПС должно выполнять одну какую-либо ярко выраженную функцию и ее реализация не пред-ставляется слишком сложной. Естественно, что такая архитектура не требует какого-либо описания (кроме фиксации класса архитектуры), так как отображение внешних функций на эту программу тривиально, а определять способ взаимодействия не требуется (в силу отсутст-вия какого-либо внешнего взаимодействия программы, кроме как взаимодействия ее с пользователем, а последнее описывается в документации по применению ПС). Комплекс автономно выполняемых программ состоит из набора программ, такого, что: • любая из этих программ может быть активизирована (запущена) пользователем; • при выполнении активизированной программы другие программы этого набора не мо-гут быть активизированы до тех пор, пока не закончит выполнение активизированная программа; • все программы этого набора применятся к одной и той же информационной среде. Таким образом, программы этого набора по управлению не взаимодействуют взаимодейст-вие между ними осуществляется только через общую информационную среду. Слоистая программная система состоит из некоторой упорядоченной совокупности программных подсистем, называемых слоями, такой, что: • на каждом слое ничего не известно о свойствах (и даже существовании) последующих (более высоких) слоев; • каждый слой может взаимодействовать по управлению (обращаться к компонентам) с непосредственно предшествующим (более низким) слоем через заранее определен-ный интерфейс, ничего не зная о внутреннем строении всех предшествующих слоев; • каждый слой располагает определенными ресурсами, которые он либо скрывает от дру-гих слоев, либо предоставляет непосредственно последующему слою (через указанный интерфейс) некоторые их абстракции. Таким образом, в слоистой программной системе каждый слой может реализовать некоторую абстракцию данных. Связи между слоями ограничены передачей значений параметров обра-щения каждого слоя к смежному снизу слою и выдачей результатов этого обращения от ниж-него слоя верхнему. Недопустимо использование глобальных данных несколькими слоями. В качестве примера рассмотрим использование такой архитектуры для построения опе-рационной системы. Такую архитектуру применил Дейкстра при построении операционной системы THE. Эта операционная система состоит из четырех слоев (см. рис. 6.1). На нулевом слое производится обработка всех прерываний и выделение центрального процессора про-граммам (процессам) в пакетном режиме. Только этот уровень осведомлен о мультипрограмм-ных аспектах системы. На первом слое осуществляется управление страничной организаци-ей памяти. Всем вышестоящим слоям предоставляется виртуальная непрерывная (не стра-ничная) память. На втором слое осуществляется связь с консолью (пультом управления) опе-ратора. Только этот слой знает технические характеристики консоли. На третьем слое осуще-ствляется буферизация входных и выходных потоков данных и реализуются так называемые абстрактные каналы ввода и вывода, так что прикладные программы не знают технических характеристик устройств ввода и вывода.
Прикладные программы
3: Управление входными и выходными потоками данных
2: Обеспечение связи с консолью оператора
1: Управление памятью
0: Диспетчеризация и синхронизация процессов
Компьютер
Рис. 6.1. Архитектура операционной системы THE.
Коллектив параллельно действующих программ представляет собой набор программ, способных взаимодействовать между собой, находясь одновременно в стадии выполнения. Это означает, что такие программы, во-первых, вызваны в оперативную память, активизиро-ваны и могут попеременно разделять по времени один или несколько центральных процессо-ров, а во-вторых, осуществлять между собой динамические (в процессе выполнения) взаимо-действия, на базе которых производиться их синхронизация. Обычно взаимодействие между такими процессами производится путем передачи друг другу некоторых сообщений. Простейшей разновидностью такой архитектуры является конвейер. Возможности для организации конвейера имеются, например, в операционной системе UNIX. Конвейер пред-ставляет собой последовательность программ, в которой стандартный вывод каждой про-граммы, кроме самой последней, связан со стандартным вводом следующей программы этой последовательности (см. рис. 6.2). Конвейер обрабатывает некоторый поток сообщений. Каж-дое сообщение этого потока поступает на ввод первой программе, которая переработанное сообщение передает следующей программе, а сама начинает обработку очередного сообщения потока. Таким же образом действует каждая программа конвейера: получив сообщение от предшествующей программы и, обработав его, она передает переработанное сообщение сле-дующей программе и приступает к обработке следующего сообщения. Последняя программа конвейера выводит результат работы всего конвейера (результирующее сообщение). Таким образом, в конвейере, состоящим из n программ, может одновременно находиться в обработке до n сообщений. Конечно, в силу того, что разные программы конвейера могут затратить на обработку очередных сообщений разные отрезки времени, необходимо обеспечить каким-либо образом синхронизацию этих процессов (некоторые процессы могут находиться в ста-дии ожидания либо возможности передать переработанное сообщение, либо возможности получить очередное сообщение).
В общем случае коллектив параллельно действующих программ может быть организо-ван в систему с портами сообщений. Порт сообщений представляет собой программную подсистему, обслуживающую некоторую очередь сообщений: она может принимать на хранение от программы какое-либо сообщение, ставя его в очередь, и может выдавать очередное сообщение другой программе по ее требованию. Сообщение, переданное какой-либо программой некоторому порту, уже не будет принадлежать этой программе (и ис-пользовать ее ресурсы), но оно не будет принадлежать и никакой другой программе, пока в порядке очереди не будет передано какой-либо программе по ее запросу. Таким образом, программа, передающая сообщение не будет находиться в стадии ожидания пока программа, принимающая это сообщение, не будет готова его обрабатывать (если только не будет переполнен принимающий порт). Пример программной системы с портами сообщений приведен на рис. 6.3. Порт U мо-жет рассматриваться как порт вводных сообщений для представленного на этом рисунке коллектива параллельно действующих программ, а порт W как порт выводных сообщений для этого коллектива программ.
Рис. 6.3. Пример программной системы с портами сообщений.
Программные системы с портами сообщений могут быть как жесткой конфигурации, так и гибкой конфигурации. В системах с портами жесткой конфигурации каждая программа жестко связывается с одним или с несколькими входными портами. Для передачи сообщения такая программа должна явно указать адрес передачи: имя программы и имя ее входного пор-та. В этом случае при изменении конфигурации системы придется корректировать исполь-зуемые программы: изменять адреса передач сообщений. В системах с портами гибкой конфи-гурации с каждой программой связаны как входные, так и выходные виртуальные порты. Пе-ред запуском такой системы программы на основании информации, задаваемой пользовате-лем, должна производиться ее предварительная настройка с помощью специальной программ-ной компоненты, осуществляющей совмещение каждого выходного виртуального порта одной программы с каким-либо входным виртуальным портом другой. Тем самым при изме-нении конфигурации системы в этом случае не требуется какой-либо корректировки исполь-зуемых программ необходимые изменения должны быть отражены в информации для на-стройки. Однако в этом случае требуется иметь специальную программную компоненту, осуществляющую настройку системы.
3. Архитектурные функции. Для обеспечения взаимодействия между подсистемами в ряде случаев не требуется соз-давать какие-либо дополнительные программные компоненты (помимо реализации внешних функций) для этого может быть достаточно заранее фиксированных соглашений и стан-дартных возможностей базового программного обеспечения (операционной системы). Так в комплексе автономно выполняемых программ для обеспечения взаимодействия достаточно описания (спецификации) общей внешней информационной среды и возможностей операци-онной системы для запуска программ. В слоистой программной системе может оказаться дос-таточным спецификации выделенных программных слоев и обычный аппарат обращения к процедурам. В программном конвейере взаимодействие между программами также может обеспечивать операционная система (как это имеет место в операционной системе UNIX). Однако в ряде случаев для обеспечения взаимодействия между программными подсис-темами может потребоваться создание дополнительных программных компонент. Так для управления работой комплекса автономно выполняемых программ часто создают специализированный командный интерпретатор, более удобный (в данной предметной области) для подготовки требуемой внешней информационной среды и запуска требуемой программы, чем базовый командный интерпретатор используемой операционной системы. В слоистых программных системах может быть создан особый аппарат обращения к процедурам слоя (например, обеспечивающий параллельное выполнение этих процедур). В коллективе параллельно действующих программ для управления портами сообщений требуется специальная программная подсистема. Такие программные компоненты реализуют не внешние функции ПС, а функции, возникшие в результате разработки архитектуры этого ПС. В связи с этим такие функции мы будем называть архитектурными.
4. Контроль архитектуры программных средств. Для контроля архитектуры ПС используется смежный контроль и ручная имитация. Смежный контроль архитектуры ПС сверху это ее контроль разработчиками внешнего описания: разработчиками спецификации качества и разработчиками функциональной специ-фикации. Смежный контроль архитектуры ПС снизу это ее контроль потенциальными раз-работчиками программных подсистем, входящих в состав ПС в соответствии с разработанной архитектурой. Ручная имитация архитектуры ПС производится аналогично ручной имитации функциональной спецификации, только целью этого контроля является проверка взаимодействия между программными подсистемами. Так же как и в случае ручной имитации функциональной спецификации ПС должны быть сначала подготовлены тесты. Затем группа разработчиков должна для каждого такого теста имитировать работу каждой программной подсистемы, входящей в состав ПС. При этом работу каждой подсистемы имитирует один какой-либо разработчик (не автор архитектуры), тщательно выполняя все взаимодействия этой подсистемы с другими подсистемами (точнее, с разработчиками, их имитирующими) в соответствии с разработанной архитектурой ПС. Тем самым обеспечивается имитационное функционирование ПС в целом в рамках проверяемой архитектуры.
