|
|
bb:nohost [2016/04/06 20:12] prospero78 [Устранение зависимостей от подсистемы Host] |
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** системные абстракции не идеальны и поэтому имеются **нарушения герметичности** системного слоя (также обозначенные на рисунке красными стрелками) FIXME , что приводит к прямой или косвенной (строковые константы и т. д.) зависимости прикладных модулей от операционной системы. | |
| |
# Решение проблемы нарушения герметичности # | |
| |
## Модификация модуля Kernel ## | |
| |
На схеме показаны зависимости прикладного и системного слоя от модуля ''Kernel''. | |
| |
Эти зависимости не позволяют нам произвести безопасную замену модуля ''Kernel'', например, при замене операционной системы. Безопасность, в данном случае, это //соблюдение контрактов интерфейса//. Текущий интерфейс модуля ''Kernel'' явно зависит от модуля ''WinApi'', что предполагает изменение этого интерфейса (а значит контрактов), при смене ОС. Это и есть нарушение герметичности системного слоя **БлэкБокса**. | |
| |
В целях устранения данного нарушения герметичности предлагается разделение интерфейса модуля ''Kernel'' на платформо-независимую (условно: Pascal_kernel) и платформо-зависимую части(условно: Win32kernel, Win64kernel, Lin32kernel, Lin64kernel и т. д.). | |
| |
Плюсом данного решения является **полное изолирование** клиентских модулей от платформы. | |
| |
Минусом является то, что модуль ''Kernel'' это //специфический// системный модуль: **невозможно** наверняка предугадать абстракции, которые могут понадобиться клиентам. А необходимые для работы каркаса низкоуровневые функции ''Kernel'' (ассемблерный код, прямая работа с памятью) не могут быть реализованы (или хотя бы представлены в виде абстракций) платформо-независимо. | |
| |
Решением данной проблемы может стать использование специальных соглашений и разделение платформо-зависимых компонентов на абстракции и платформо-зависимые реализации (Host-компоненты)(( --- //[[prospero.78.su@gmail.com|Валерий Шипков]] 2016/04/03 12:16// Имхо, ''Kernel'' должен _гарантированно_ использовать только те абстракции и реализации, которые будут доступны везде )). | |
| |
## Устранение зависимостей от подсистемы Host ## | |
| |
Модули подсистем ''Std'' и ''System'', входящие в эталон **BlackBox**, по большей части являются платформо-независимыми. Однако, в некоторых местах обнаруживаются прямые (импорт) или косвенные (через строковые константы/ресурсы, отображения на формах и т. д.) зависимости от подсистемы ''Host''. | |
| |
Эти зависимости в той или иной степени обеспечивают функционирование эталона, при этом ухудшая его платформо-независимость. Так как функциональность ''Host'' нужна системному слою, то необходимо сохранить её, но уже с использованием герметичных решений. | |
| |
Для устранения зависимости подсистемы ''Std'' от ''Host'' введём ряд дополнительных абстракций в подсистему ''System'', которые заместят необходимые ранее зависимости. А подсистему ''Host'' дополним подсистемой ''(Host)Pascal'', в которой находятся реализации этих абстракций( (Host)Win32, (Host)Win64, (Host)Lin32, (Host)Lin64). | |
| |
Некоторые прямые и косвенные зависимости (формы, строковые ресурсы) подсистем ''Std'' и ''System'' могут быть перемещены в подсистему ''Host'' целиком, или частично. Например, модуль ''StdMenuTool'' или содержимое меню ''(System)Menus'', которое состоит из текстовых команд зависящих от подсистемы ''Host''. Такие команды могут быть размещены в меню ''(Host)Menus''. | |
| |
Прикладные компоненты с зависимостями от ''Host'', должны быть аналогичным образом преобразованы в набор абстракций и Host-реализаций. | |
| |
---- | |
| |
Кушнир П.М., Кузьмицкий И.А. | |
| |
Ярославль, 2013 г. | |