Архитектура ПС - это его строение как оно видно (или должно быть видно) из-вне его,
т.е. представление ПС как системы, состоящей из некоторой совокупности
взаимодействующих подсистем. В качестве таких подсистем выступают
обычно отдельные программы. Разработка архитектуры является первым
этапом борьбы со сложностью ПС, на котором реализуется принцип
выделения относительно независимых компонент.
Основные задачи разработки архитектуры ПС:
С учетом принимаемых на этом этапе решений производится дальнейшая конкретизация и функциональных спецификаций.
Различают следующие основные классы архитектур программных средств [4.1]:
Цельная программа представляет
вырожденный случай архитектуры ПС: в состав ПС входит только одна
программа. Такую архитектуру выбирают обычно в том случае, когда ПС
должно выполнять одну какую-либо ярко выраженную функцию и ее реализация
не представляется слишком сложной. Естественно, что такая архитектура
не требует какого-либо описания (кроме фиксации класса архитектуры),
так как отображение внешних функций на эту программу тривиально, а
определять способ взаимодействия не требуется (в силу отсутствия
какого-либо внешнего взаимодействия программы, кроме как взаимодействия
ее с пользователем, а последнее описывается в документации по
применению ПС).
Комплекс автономно выполняемых программ состоит из набора программ, такого, что:
Таким
образом, программы этого набора по управлению никак не взаимодействуют
- взаимодействие между ними осуществляется только через общую
информационную среду.
Слоистая программная система состоит из некоторой упорядоченной совокупности программных подсистем, называемых слоями, такой, что:
Таким образом, в слоистой программной системе каждый слой
может
реализовать некоторую абстракцию данных. Связи между слоями ограничены
передачей значений параметров обращения каждого слоя к смежному снизу
слою и выдачей результатов этого обращения от нижнего слоя верхнему.
Недопустимо использование глобальных данных несколькими слоями.
В качестве примера рассмотрим использование такой архитектуры для построения операционной системы. Такую архитектуру применил Дейкстра при построении операционной системы THE [4.2]. Эта операционная система состоит из четырех слоев (см. рис. 4.1).
На нулевом слое производится обработка всех прерываний и выделение
центрального процессора программам (процессам) в пакетном режиме.
Только этот уровень осведомлен о мультипрограммных аспектах системы. На
первом слое осуществляется управление страничной организацией памяти.
Всем вышестоящим слоям предоставляется виртуальная непрерывная (не
страничная) память. На втором слое осуществляется связь с консолью
(пультом управления) оператора. Только этот слой знает технические
характеристики консоли. На третьем слое осуществляется буферизация
входных и выходных потоков данных и реализуются так называемые
абстрактные каналы ввода и вывода, так что прикладные программы не
знают технических характеристик устройств ввода и вывода.
|
Для
обеспечения взаимодействия между подсистемами в ряде случаев не
требуется создавать какие-либо дополнительные программные компоненты
(помимо реализации внешних функций) - для этого может быть достаточно
заранее фиксированных соглашений и стандартных возможностей базового
программного обеспечения (операционной системы). Так в комплексе
автономно выполняемых программ для обеспечения взаимодействия
достаточно описания (спецификации) общей внешней информационной среды и
возможностей операционной системы для запуска программ. В слоистой
программной системе может оказаться достаточным спецификации выделенных
программных слоев и обычный аппарат обращения к процедурам. В
программном конвейере взаимодействие между программами также может
обеспечивать операционная система (как это имеет место в операционной
системе UNIX).
Однако
в ряде случаев для обеспечения взаимодействия между программными
подсистемами может потребоваться создание дополнительных программных
компонент. Так для управления работой комплекса автономно выполняемых
программ часто создают специализированный командный интерпретатор,
более удобный в данной предметной области для подготовки требуемой
внешней информационной среды и запуска требуемой программы, чем базовый
командный интерпретатор используемой операционной системы. В слоистых
программных системах может быть создан особый аппарат обращения к
процедурам слоя (например, обеспечивающий параллельное выполнение этих
процедур). В коллективе параллельно действующих программ для управления
портами сообщений требуется специальная программная подсистема. Такие
программные компоненты никаких внешних функций не выполняют - они
реализуют функции, возникшие в результате разработки архитектуры
программного средства. В связи с этим такие функции мы будем называть
архитектурными.
Для контроля архитектуры ПС используется смежный контроль иручная имитация.
Смежный
контроль архитектуры ПС сверху - это ее контроль разработчиками
внешнего описания: разработчиками спецификации качества и
разработчиками функциональной спецификации. Смежный контроль
архитектуры ПС снизу - это ее контроль потенциальными разработчиками
программных подсистем, входящих в состав ПС в соответствии с
разработанной архитектурой.
Ручная имитация архитектуры ПС производится аналогично ручной имитации функциональной спецификации, только целью этого контроля является проверка взаимодействия между программными подсистемами. Так же как и в случае ручной имитации функциональной спецификации ПС должны быть сначала подготовлены тесты. Затем группа разработчиков должна для каждого такого теста имитировать работу каждой программной подсистемы, входящей в состав ПС. При этом работу каждой подсистемы имитирует один какой-либо разработчик (не автор архитектуры), тщательно выполняя все взаимодействия этой подсистемы с другими подсистемами (точнее, с разработчиками, их имитирующими) в соответствии с разработанной архитектурой ПС. Тем самым обеспечивается имитационное функционирование ПС в целом в рамках проверяемой архитектуры.
Друзья! Приглашаем вас к обсуждению. Если у вас есть своё мнение, напишите нам в комментарии.