|
|
|
bb:nohost [2016/04/03 12:23]
prospero78 [Понятие компонента] |
bb:nohost [2020/10/29 07:08]
|
|  | |
| Рис.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* на платформо-независимую (условно: 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* дополним подсистемой *PascalHost*, в которой находятся реализации этих абстракций(Win32Host, Win64Host, Lin32Host, Lin64Host). | |
| |
| Некоторые прямые и косвенные зависимости (формы, строковые ресурсы) подсистем *Std* и *System* могут быть перемещены в подсистему *Host* целиком, или частично. Например, модуль *StdMenuTool* или содержимое меню *(System)Menus*, которое состоит из текстовых команд зависящих от подсистемы *Host*. Такие команды могут быть размещены в меню *(Host)Menus*. | |
| |
| Прикладные компоненты с зависимостями от *Host*, должны быть аналогичным образом преобразованы в набор абстракций и Host-реализаций. | |
| |
| ---- | |
| |
| Кушнир П.М., Кузьмицкий И.А. | |
| |
| Ярославль, 2013 г. | |
