Предыдущая версия справа и слева
Предыдущая версия
Следующая версия
|
Предыдущая версия
Следующая версия
Следующая версия справа и слева
|
bb:nohost [2016/04/03 12:19] prospero78 [Модификация модуля Kernel] |
bb:nohost [2017/04/01 21:33] admin старая ревизия восстановлена (2016/03/30 22:25) |
# Проблема герметичности # | # Проблема герметичности # |
| |
^ Блэкбокс ^^ | Блэкбокс с точки зрения пользователя является обычным приложением. То есть, для работы ему необходима **операционная система**. |
| с точки зрения пользователя | с точки зрения программной архитектуры | | |
|Является обычным приложением. То есть, для работы ему необходима **операционная система**. |Является //компонентным каркасом//(микро-операционной системой), то есть средой для запуска и управления **компонентами** и их работой.| | |
| |
==== Понятие компонента ==== | |
**Компонент** с точки зрения каркаса является совокупностью скомпилированных модулей. Модули могут использовать возможности других модулей, таким образом появляется **зависимость** (обозначена стрелкой по направлению от зависимого модуля к необходимому). FIXME ( А картинка где? ) | |
| |
Компоненты можно разделить на две группы: | Блэкбокс с точки зрения программной архитектуры является компонентным каркасом, то есть средой для запуска и управления **компонентами** и их работой. |
| |
^ Компоненты ^^ | Компонент с точки зрения каркаса является совокупностью скомпилированных модулей. Модули могут использовать возможности других модулей, таким образом появляется **зависимость** (обозначена стрелкой по направлению от зависимого модуля к необходимому). |
| Зависящие от операционной системы | Не зависящие от операционной системы | | |
| |
Также компоненты делятся по необходимости, для работы каркаса: | Среди всех компонентов можно выделить такие, которые не зависят от операционной системы и такие, которые зависят от неё. |
| |
^ Компоненты по нужности каркасу ^^ | В отдельную группу можно выделить компоненты, необходимые для работы каркаса - системный слой. Остальные компоненты не являются необходимыми, и могут быть выделены в прикладной слой. |
| Нужны | Не нужны | | |
| системный слой | прикладной слой | | |
| |
Из представленной вертикальной и горизонтальной структуры можно уже сделать промежуточные выводы: зависящие от операционной системы компоненты //системного слоя// составляют некий //промежуточный слой//, позволяющий каркасу как бы //независимым// от нижележащей операционной системы. Если //прикладные компоненты// зависят только от "прокладки", то появляется возможность заменить "прокладку", перенеся тем самым //каркас// на другую операционную систему //без повреждений// прикладного слоя. | Теперь можно ввести важное определение. Зависящие от операционной системы компоненты системного слоя составляют некий "прокладочный" слой, позволяющий каркасу как бы "плавать" на нижележащей операционной системе. Если прикладные компоненты зависят только от "прокладки", то появляется возможность заменить "прокладку", перенеся тем самым каркас на другую операционную систему без повреждений прикладного слоя. |
| |
| Рассмотрим устройство системного слоя в [эталоне](http://oberoncore.ru/blackbox/oberoncore_official_position) BlackBox. |
==== Системный слой ==== | Основой системы является модуль *Kernel*, который реализует поддержку времени выполнения для приложений BlackBox (см. [документацию](http://oberoncore.ru/library/ermakov_vnutrennij_interfejs_kernel) *Kernel*). |
Рассмотрим устройство системного слоя в [эталоне](http://oberoncore.ru/blackbox/oberoncore_official_position) **BlackBox**. | |
Основой системы является модуль *Kernel*, который реализует поддержку //этапа выполнения// для приложений **BlackBox** (см. [документацию](http://oberoncore.ru/library/ermakov_vnutrennij_interfejs_kernel) *Kernel*). | |
Модуль *Kernel* использует возможности операционной системы (на рисунке эта зависимость обозначена красной стрелкой). | Модуль *Kernel* использует возможности операционной системы (на рисунке эта зависимость обозначена красной стрелкой). |
Для работы клиентских (прикладных) модулей необходимы базовые //абстракции// файловой системы, оконной системы, отображений, контейнеров, диалогов и т. п. В эталоне эти //абстракции// собраны в подсистеме *System* (см. рис.), часть реализаций которых платформо-независима, а часть платформо-зависима. Платформо-независимые реализации *System* содержатся в подсистеме *Std*. В то же время, в подсистеме *Std* есть такие абстракции, которым тоже необходима платформо-зависимая реализация (например, элементы управления и диалоговые окна). Платформо-зависимые реализации *System* и *Std* содержатся в подсистеме *Host*. | Для работы клиентских (прикладных) модулей необходимы базовые абстракции файловой системы, оконной системы, отображений, контейнеров, диалогов и т.п. В эталоне эти абстракции собраны в подсистеме *System* (см. рис.), часть реализаций которых платформо-независима, а часть платформо-зависима. Платформо-независимые реализации *System* содержатся в подсистеме *Std*. В то же время, в подсистеме *Std* есть такие абстракции, которым тоже необходима платформо-зависимая реализация (например, элементы управления и диалоговые окна). Платформо-зависимые реализации *System* и *Std* содержатся в подсистеме *Host*. |
| |
Разделение *System* на абстрактный интерфейс и платформо-зависимую реализацию позволяет добиться //герметичности// платформо-независимой части //системного слоя//. Герметичность позволяет заменять платформо-зависимые системные модули без модификации клиентских модулей. | Разделение *System* на абстрактный интерфейс и платформо-зависимую реализацию позволяет добиться **герметичности** платформо-независимой части системного слоя. Герметичность позволяет заменять платформо-зависимые системные модули без модификации клиентских модулей. |
| |
//Герметичность// здесь понимается как отсутствие [[http://www.joelonsoftware.com/articles/LeakyAbstractions.html|протечек абстракций]] системного и прикладного слоя. | Герметичность здесь понимается как отсуствие [[http://www.joelonsoftware.com/articles/LeakyAbstractions.html|протечек абстракций]] системного и прикладного слоя. |
| |
В идеале, абстракции системного слоя должны удовлетворять всем потребностям прикладного слоя. Но, по историческим причинам, в эталонной сборке **BlackBox** системные абстракции не идеальны и поэтому имеются **нарушения герметичности** системного слоя (также обозначенные на рисунке красными стрелками), что приводит к прямой или косвенной (строковые константы и т.д.) зависимости прикладных модулей от операционной системы. | В идеале, абстракции системного слоя должны удовлетворять всем потребностям прикладного слоя. Но, по историческим причинам, в эталонной сборке BlackBox системные абстракции не идеальны и поэтому имеются **нарушения герметичности** системного слоя (также обозначенные на рисунке красными стрелками), что приводит к прямой или косвенной (строковые константы и т.д.) зависимости прикладных модулей от операционной системы. |
| |
# Решение проблемы нарушения герметичности # | # Решение проблемы нарушения герметичности # |
На схеме показаны зависимости прикладного и системного слоя от модуля *Kernel*. | На схеме показаны зависимости прикладного и системного слоя от модуля *Kernel*. |
| |
Эти зависимости не позволяют нам произвести безопасную замену модуля *Kernel*, например, при замене операционной системы. Безопасность, в данном случае, это //соблюдение контрактов интерфейса//. Текущий интерфейс модуля *Kernel* явно зависит от модуля *WinApi*, что предполагает изменение этого интерфейса (а значит контрактов), при смене ОС. Это и есть нарушение герметичности системного слоя **БлэкБокса**. | Эти зависимости не позволяют нам произвести безопасную замену модуля *Kernel*, например, при замене операционной системы. Безопасность, в данном случае, это соблюдение контрактов интерфейса. Текущий интерфейс модуля *Kernel* явно зависит от модуля *WinApi*, что предполагает изменение этого интерфейса (а значит контрактов), при смене ОС. Это и есть нарушение герметичности системного слоя БлэкБокса. |
| |
В целях устранения данного нарушения герметичности предлагается разделение интерфейса модуля *Kernel* на платформо-независимую (условно: Pascal_kernel) и платформо-зависимую части(условно: Win32kernel, Win64kernel, Lin32kernel, Lin64kernel и т. д.). | В целях устранения данного нарушения герметичности предлагается разделение интерфейса модуля *Kernel* на платформо-независимую (условно: Oberkernel) и платформо-зависимую части. |
| |
Плюсом данного решения является **полное изолирование** клиентских модулей от платформы. | Плюсом данного решения является полное изолирование клиентских модулей от платформы. |
| |
Минусом является то, что модуль *Kernel* это //специфический// системный модуль: **невозможно** наверняка предугадать абстракции, которые могут понадобиться клиентам. А необходимые для работы каркаса низкоуровневые функции *Kernel* (ассемблерный код, прямая работа с памятью) не могут быть реализованы (или хотя бы представлены в виде абстракций) платформо-независимо. | Минусом является то, что модуль *Kernel* это специфический системный модуль: невозможно наверняка предугадать абстракции, которые могут понадобиться клиентам. А необходимые для работы каркаса низкоуровневые функции *Kernel* (ассемблерный код, прямая работа с памятью) не могут быть реализованы (или хотя бы представлены в виде абстракций) платформо-независимо. |
| |
Решением данной проблемы может стать использование специальных соглашений и разделение платформо-зависимых компонентов на абстракции и платформо-зависимые реализации (Host-компоненты)(( --- //[[prospero.78.su@gmail.com|Валерий Шипков]] 2016/04/03 12:16// Имхо, *Kernel* должен _гарантированно_ использовать только те абстракции и реализации, которые будут доступны везде )). | Решением данной проблемы может стать использование специальных соглашений и разделение платформо-зависимых компонентов на абстракции и платформо-зависимые реализации (Host-компоненты). |
| |
## Устранение зависимостей от подсистемы Host ## | ## Устранение зависимостей от подсистемы Host ## |