Меню
Главная
Авторизация/Регистрация
 
Главная arrow Информатика arrow Архитектура и проектирование программных систем

Варианты архитектур программных систем

Далее рассматриваем доминантные архитектуры программных систем в смысле, определенном в предыдущее разделе. Архитектуры программных систем менялись по мере развития информационных технологий. В 60-е гг. XX в. значительный процент систем составляли традиционные пакетные системы, которые представляли собой ряд автономных последовательных программ, общающихся через файлы во вторичной памяти. Выделялись лишь два похода к построению систем: метод уровней абстракции и метод портов [17]. Позже получил развитие модульно-интерфейсный подход - один из методов структурного проектирования, затем подходы, основанные на потоках данных, независимых компонентах, объектно ориентированном проектировании и др.

Цель данного раздела - рассмотрение некоторых типичных вариантов архитектур программных систем на основе классификации, приведенной в [9, 17] и материалах других публикаций [24, 25].

Архитектура, основанная на уровнях абстракций

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

Не существует такого понятия, как вполне определенная, единственная абстракция конкретной системы. Для каждой системы имеется множество возможных абстракций. Каждая абстракция дает разработчику различную точку зрения на то, как выглядит система и что она делает. Абстракции системы могут быть тесно связаны. Так, например, одна абстракция а(2) может быть уточнением абстракции а{ 1). Если абстракция а(2) уточняет абстракцию а( 1), то абстракция описывает все, что описывает абстракция а(1), но уровень детализации в абстракции а(2) всегда не меньше, чем в абстракции а( 1). Другими словами, абстракция а{2) является равномерно более детализированным описанием, чем «(1).

Пусть п(1), а{2), ..., а(п)~ такой ряд абстракций, что для каждого г абстракция а(г + 1) - уточнение предыдущей абстракции а(Г). Каждая абстракция а(г) представляет собой полное, хотя и не обязательно подробное описание всей системы. Когда абстракции упорядочены таким образом, имеет смысл говорить об уровне абстракции, т.е. о степени детализации описания.

Концепция уровней абстракции была предложена Э. Дейкстрой в 1968 г. [17]. Программа разбивается на различные иерархически упорядоченные части Ь( 1), Ь(2), ..., Ь(п), называемые слоями (уровнями), удовлетворяющие определенным проектировочным критериям. Каждый уровень является группой тесно связанных модулей. Идея уровней призвана минимизировать сложность системы за счет такого их определения, которое обеспечивает высокую степень независимости уровней друг от друга. Это достигается благодаря тому, что свойства определенных объектов такой системы (ресурсы, представления данных и т.п.) убираются внутрь каждого уровня, что позволяет рассматривать каждый уровень как абстракцию этих объектов.

На рис. 2.4 и 2.5 показаны две возможные (общие) структуры таких уровней.

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

Вариант классической структуры

Рис. 2.4. Вариант классической структуры

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

Вариант произвольной структуры

Рис. 2.5. Вариант произвольной структуры

Перечислим свойства уровней абстракции [17, 25].

  • 1. На каждом уровне абсолютно ничего не известно о свойствах (и даже существовании) более высоких уровней. Это фундаментальное свойство уровней абстракции, существенно сокращающее число связей между частями программной системы и их предположений относительно свойств друг друга, благодаря чему уменьшается сложность системы.
  • 2. На каждом уровне ничего не известно о внутреннем строении других уровней. Связь между уровнями осуществляется только через жесткие, заранее определенные сопряжения.
  • 3. Каждый уровень представляет собой группу модулей (раздельно компилируемых подпрограмм). Некоторые из этих модулей являются внутренними для уровня, т.е. недоступны для других уровней. Имена остальных модулей известны на следующем, более высоком уровне. Эти имена представляют собой сопряжение с этим уровнем.
  • 4. Каждый уровень располагает определенными ресурсами и либо скрывает их от других уровней (более низких), либо предоставляет другим (более высоким) некоторые их абстракции. Например, в системе управления файлами один из уровней может содержать физические файлы, скрывая их организацию от остальных частей системы. Другие уровни могут владеть такими ресурсами, как каталоги, словари данных, механизмы защиты.
  • 5. Каждый уровень может обеспечивать некоторую абстракцию данных в системе. Например, запись в базе данных - это абстракция таблицы данных, хранящаяся в некотором файле.
  • 6. Предположения, которые делаются на каждом уровне относительно других уровней, должны быть минимальны. Эти предположения могут принимать вид соотношений, которые должны соблюдаться перед выполнением функции, либо относиться к представлению данных или факторов внешней среды.
  • 7. Связи между уровнями ограничены явными аргументами, передаваемыми с одного уровня на другой. Недопустимо использование глобальных данных несколькими уровнями. Более того, желательно полностью исключить использование глобальных данных (даже внутри уровня) в системе.
  • 8. Каждый уровень должен иметь высокую прочность и слабое сцепление (далее остановимся на этом более подробно). Это значит, что всякая функция, выполняемая уровнем абстракции, должна быть представлена единственным входом. Аргументы, пересылаемые между уровнями, должны быть отдельными элементами данных, а не сложными структурами.

Одной из первых программных систем, основанных на уровнях абстракции, была операционная система ТНЕ [17, 25]. Она является пакетной системой с мультипрограммированием и виртуальной памятью. Система включает в себя пять уровней абстракций, структура которых близка к изображенной на рис. 2.5. Почему выбрана эта схема, а не схема по рис. 2.4?

На рис. 2.4 и 2.5 изображена последовательность слоев ЦО), Ц1), ..., Ь(п), причем ЦО) - аппаратура, а 7,(1) - первый слой программ. Рассмотрим вариант, когда слой Дг), может иметь доступ только к средствам виртуальной машины, определяемой слоем Щ— 1). Если слою Ь(г) потребуется какое-либо средство слоя Д/ - 2), то слой Ц7 - 1) должен также предоставить это средство.

Рассмотрим теперь другой вариант, когда слой Дг), может использовать все средства, предоставляемые слоями Д1), Д2), ..., Дг-1). Таким образом, виртуальная машина, определяемая слоем Д/), включает в себя все команды до слоя Д/) и команды, реализуемые слоем Дг). Третий вариант является промежуточным между двумя первыми. В этом случае слою Д/) разрешается использовать только некоторые из команд, обеспечиваемых слоями Д1), Д2), ..., Дг— 1).

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

Другие слои могут выполнять непривилегированные команды плюс команды нижележащих слоев в соответствии с одним из трех рассмотренных выше вариантов.

Каждый вариант имеет свои достоинства и недостатки. Для их рассмотрения обратимся к рис. 2.7. Здесь показаны два варианта возможной структуры операционной системы: слева (рис. 2.7 а)) - вариант структуры с многоуровневым модульным ядром, справа (рис. 2.7 б)) -вариант структуры с компактным микроядром [19]. Если в варианте 2.7 а) каждый слой имеет доступ к командам только одного слоя, разработчик должен иметь в виду только предыдущий слой. Хотя с точки зрения проектирования этот вариант кажется привлекательным, он может оказаться очень неэффективным.

Интерфейс системных вызовов АР1

Утилиты, системные программы Приложения пользователей

Многоуровневая иерархическая структура

Рис. 2.6. Многоуровневая иерархическая структура

операционной системы

Менеджеры ресурсов Файловая система, вирт. память

Вазовые механизмы ядра

Машинно-зависимые модули ядра ОС

Средства аппаратной поддержки ОС ядра

Например, если некоторое средство, предоставляемое слоем Д2) (базовые механизмы ядра), потребуется в слое Д/), то каждый из слоев ДЗ), Д4), ..., Д/ - 1) должен обеспечить это средство. Это значит, что запрос данного средства слоем Д/) должен «просачиваться» вниз через слой Д/ - 1), пока не достигнет слоя Д2), который способен выполнить запрос. Эти трудности, связанные с проблемой эффективности, могут склонить к принятию структуры, в которой каждый слой Ц/), где 2 < / < п, может непосредственно обращаться к слою Д2), реализующему базовые механизмы ядра. Так, например, организована операционная система Vindows 2000/2003/ХР/7 (рис. 2.8) из [20].

Рассмотрим теперь вариант по рис. 2.7 б). В данном случае выделено три слоя: два - в микроядре, третий - остальные модули системы. При этом если какой-либо компонент (модуль) третьего слоя потребует функцию другого компонента этого же слоя, то такая услуга может быть получена только через микроядро. В данном случае взаимодействие модулей слоев организовано по принципу клиент-серверной архитектуры (рис. 2.9), эффективность которого может быть выше по сравнению с вариантом по рис. 2.7 а) при условии доступа модулей слоя Д/) только к слою Д/ - 1).

'?м —?

с>

о

5

н

н

сз

X

2

и

о

S

т ч

н

о

я

. Л

S

X

и

Р

о

ЭХ

С

м

о

с

CU

с

о

го

X

о

X

&

X

Б

  • 5
  • ?

<

о

ю

о.

о

сз

a

о ' *

а

>5

X

о

СС

С.

о

3

е

ся

а

и

В.

а

Утилиты ОС, приложения

1

Интерфейс системы ввода-вы вода

?

ч

Cs

S

Я

и

Менеджер виртуальной памяти

Менеджер процессов

Ом

1

Базовые механизмы ядра

1

Машинно-зависимые модули

Средства аппаратной поддержки ОС

Аппаратура

2

З

ц я

1 §

*

Й ^

2 а п с

МИКРОЯДРО (режим ядра)

Средства аппаратной поддержки ОС

Аппаратура

а) многоуровневое ядро б) микроядерное ядро

Рис. 2.7. Варианты структур операционных систем

Однако производительность микроядерной ОС в целом ниже производительности архитектуры, приятой в упомянутых системах Windows 2000/2003/ХР (это же относится и Windows 7/8) по причине возможного многократного переключения работы компьютера из пользовательского режима в режим ядра при выполнении системных вызовов (рис. 2.10).

В заключение данного раздела отметим, что можно построить древовидную структуру слоев системы (рис. 2.11), в которой каждый слой может иметь доступ только к тем слоям, которые соответствуют его предшественникам по дереву. Дерево частей такой программы представляет на самом деле дерево виртуальных машин. Такая организация была впервые использована при создании ядра операционной системы SUE, разработанной в Университете Торонто в 1972 г. для семейства машин IBM/360 [24].

 
Если Вы заметили ошибку в тексте выделите слово и нажмите Shift + Enter
< Пред   СОДЕРЖАНИЕ   След >
 

Популярные страницы