|
|
bb:nohost [2016/04/03 12:12] prospero78 [Системный слой] |
bb:nohost [2020/10/29 07:08] |
![Схема](https://dl.dropboxusercontent.com/u/9533224/bb/bb-host.svg) | |
Рис.1. Переход от "хоста" к "платформе" | |
| |
| |
# Проблема герметичности # | |
| |
^ Блэкбокс ^^ | |
| с точки зрения пользователя | с точки зрения программной архитектуры | | |
|Является обычным приложением. То есть, для работы ему необходима **операционная система**. |Является //компонентным каркасом//(микро-операционной системой), то есть средой для запуска и управления **компонентами** и их работой.| | |
| |
==== Понятие компонента ==== | |
**Компонент** с точки зрения каркаса является совокупностью скомпилированных модулей. Модули могут использовать возможности других модулей, таким образом появляется **зависимость** (обозначена стрелкой по направлению от зависимого модуля к необходимому). FIXME ( А картинка где? ) | |
| |
Компоненты можно разделить на две группы: | |
| |
^ Компоненты ^^ | |
| Зависящие от операционной системы | Не зависящие от операционной системы | | |
| |
Также компоненты делятся по необходимости, для работы каркаса: | |
| |
^ Компоненты по нужности каркасу ^^ | |
| Нужны | Не нужны | | |
| системный слой | прикладной слой | | |
| |
Из представленной вертикальной и горизонтальной структуры можно уже сделать промежуточные выводы: зависящие от операционной системы компоненты //системного слоя// составляют некий //промежуточный слой//, позволяющий каркасу как бы //независимым// от нижележащей операционной системы. Если //прикладные компоненты// зависят только от "прокладки", то появляется возможность заменить "прокладку", перенеся тем самым //каркас// на другую операционную систему //без повреждений// прикладного слоя. | |
| |
| |
==== Системный слой ==== | |
Рассмотрим устройство системного слоя в [эталоне](http://oberoncore.ru/blackbox/oberoncore_official_position) **BlackBox**. | |
Основой системы является модуль *Kernel*, который реализует поддержку //этапа выполнения// для приложений **BlackBox** (см. [документацию](http://oberoncore.ru/library/ermakov_vnutrennij_interfejs_kernel) *Kernel*). | |
Модуль *Kernel* использует возможности операционной системы (на рисунке эта зависимость обозначена красной стрелкой). | |
Для работы клиентских (прикладных) модулей необходимы базовые //абстракции// файловой системы, оконной системы, отображений, контейнеров, диалогов и т. п. В эталоне эти //абстракции// собраны в подсистеме *System* (см. рис.), часть реализаций которых платформо-независима, а часть платформо-зависима. Платформо-независимые реализации *System* содержатся в подсистеме *Std*. В то же время, в подсистеме *Std* есть такие абстракции, которым тоже необходима платформо-зависимая реализация (например, элементы управления и диалоговые окна). Платформо-зависимые реализации *System* и *Std* содержатся в подсистеме *Host*. | |
| |
Разделение *System* на абстрактный интерфейс и платформо-зависимую реализацию позволяет добиться //герметичности// платформо-независимой части //системного слоя//. Герметичность позволяет заменять платформо-зависимые системные модули без модификации клиентских модулей. | |
| |
//Герметичность// здесь понимается как отсутствие [[http://www.joelonsoftware.com/articles/LeakyAbstractions.html|протечек абстракций]] системного и прикладного слоя. | |
| |
В идеале, абстракции системного слоя должны удовлетворять всем потребностям прикладного слоя. Но, по историческим причинам, в эталонной сборке **BlackBox** системные абстракции не идеальны и поэтому имеются **нарушения герметичности** системного слоя (также обозначенные на рисунке красными стрелками), что приводит к прямой или косвенной (строковые константы и т.д.) зависимости прикладных модулей от операционной системы. | |
| |
# Решение проблемы нарушения герметичности # | |
| |
## Модификация модуля Kernel ## | |
| |
На схеме показаны зависимости прикладного и системного слоя от модуля *Kernel*. | |
| |
Эти зависимости не позволяют нам произвести безопасную замену модуля *Kernel*, например, при замене операционной системы. Безопасность, в данном случае, это соблюдение контрактов интерфейса. Текущий интерфейс модуля *Kernel* явно зависит от модуля *WinApi*, что предполагает изменение этого интерфейса (а значит контрактов), при смене ОС. Это и есть нарушение герметичности системного слоя БлэкБокса. | |
| |
В целях устранения данного нарушения герметичности предлагается разделение интерфейса модуля *Kernel* на платформо-независимую (условно: Oberkernel) и платформо-зависимую части. | |
| |
Плюсом данного решения является полное изолирование клиентских модулей от платформы. | |
| |
Минусом является то, что модуль *Kernel* это специфический системный модуль: невозможно наверняка предугадать абстракции, которые могут понадобиться клиентам. А необходимые для работы каркаса низкоуровневые функции *Kernel* (ассемблерный код, прямая работа с памятью) не могут быть реализованы (или хотя бы представлены в виде абстракций) платформо-независимо. | |
| |
Решением данной проблемы может стать использование специальных соглашений и разделение платформо-зависимых компонентов на абстракции и платформо-зависимые реализации (Host-компоненты). | |
| |
## Устранение зависимостей от подсистемы Host ## | |
| |
Модули подсистем *Std* и *System*, входящие в эталон BlackBox, по большей части являются платформо-независимыми. Однако, в некоторых местах обнаруживаются прямые (импорт) или косвенные (через строковые константы/ресурсы, отображения на формах и т.д.) зависимости от подсистемы *Host*. | |
| |
Эти зависимости в той или иной степени обеспечивают функционирование эталона, при этом ухудшая его платформо-независимость. Так как функциональность *Host* нужна системному слою, то необходимо сохранить её, но уже с использованием герметичных решений. | |
| |
Для устранения зависимости подсистемы *Std* от *Host* введём ряд дополнительных абстракций в подсистему *System*, которые заместят необходимые ранее зависимости. А подсистему *Host* дополним подсистемой *Oberhost* (рабочее название, которое может измениться в дальнейшем), в которой находятся реализации этих абстракций. | |
| |
Некоторые прямые и косвенные зависимости (формы, строковые ресурсы) подсистем *Std* и *System* могут быть перемещены в подсистему *Host* целиком, или частично. Например, модуль *StdMenuTool* или содержимое меню *(System)Menus*, которое состоит из текстовых команд зависящих от подсистемы *Host*. Такие команды могут быть размещены в меню *(Host)Menus*. | |
| |
Прикладные компоненты с зависимостями от *Host*, должны быть аналогичным образом преобразованы в набор абстракций и Host-реализаций. | |
| |
---- | |
| |
Кушнир П.М., Кузьмицкий И.А. | |
| |
Ярославль, 2013 г. | |