|
Следующая версия
|
Предыдущая версия
|
bbnohost [2013/12/04 12:21]
admin created |
bbnohost [2022/12/27 13:39] (текущий)
iadenisov |
|  |  |
| | Рис.1. Переход от "хоста" к "платформе" |
| |
| |
| |
| Разделение *System* на абстрактный интерфейс и платформо-зависимую реализацию позволяет добиться **герметичности** платформо-независимой части системного слоя. Герметичность позволяет заменять платформо-зависимые системные модули без модификации клиентских модулей. | Разделение *System* на абстрактный интерфейс и платформо-зависимую реализацию позволяет добиться **герметичности** платформо-независимой части системного слоя. Герметичность позволяет заменять платформо-зависимые системные модули без модификации клиентских модулей. |
| | |
| | Герметичность здесь понимается как отсуствие [[http://www.joelonsoftware.com/articles/LeakyAbstractions.html|протечек абстракций]] системного и прикладного слоя. |
| |
| В идеале, абстракции системного слоя должны удовлетворять всем потребностям прикладного слоя. Но, по историческим причинам, в эталонной сборке BlackBox системные абстракции не идеальны и поэтому имеются **нарушения герметичности** системного слоя (также обозначенные на рисунке красными стрелками), что приводит к прямой или косвенной (строковые константы и т.д.) зависимости прикладных модулей от операционной системы. | В идеале, абстракции системного слоя должны удовлетворять всем потребностям прикладного слоя. Но, по историческим причинам, в эталонной сборке BlackBox системные абстракции не идеальны и поэтому имеются **нарушения герметичности** системного слоя (также обозначенные на рисунке красными стрелками), что приводит к прямой или косвенной (строковые константы и т.д.) зависимости прикладных модулей от операционной системы. |
| ## Модификация модуля Kernel ## | ## Модификация модуля Kernel ## |
| |
| На схеме показаны зависимости прикладного и системного слоя от модуля Kernel. | На схеме показаны зависимости прикладного и системного слоя от модуля *Kernel*. |
| |
| Эти зависимости не позволяют нам произвести безопасную замену модуля Kernel, например, при замене операционной системы. Безопасность, в данном случае, это соблюдение контрактов интерфейса. Текущий интерфейс модуля Kernel явно зависит от модуля WinApi, что предполагает изменение этого интерфейса (а значит контрактов), при смене ОС. Это и есть нарушение герметичности системного слоя БлэкБокса. | Эти зависимости не позволяют нам произвести безопасную замену модуля *Kernel*, например, при замене операционной системы. Безопасность, в данном случае, это соблюдение контрактов интерфейса. Текущий интерфейс модуля *Kernel* явно зависит от модуля *WinApi*, что предполагает изменение этого интерфейса (а значит контрактов), при смене ОС. Это и есть нарушение герметичности системного слоя БлэкБокса. |
| |
| В целях устранения данного нарушения герметичности предлагается разделение интерфейса модуля Kernel на платформо-независимую (условно: Oberkernel) и платформо-зависимую части. | В целях устранения данного нарушения герметичности предлагается разделение интерфейса модуля *Kernel* на платформо-независимую (условно: Oberkernel) и платформо-зависимую части. |
| |
| Плюсом данного решения является полное изолирование клиентских модулей от платформы. | Плюсом данного решения является полное изолирование клиентских модулей от платформы. |
| |
| Минусом является то, что модуль Kernel это специфический системный модуль: невозможно наверняка предугадать абстракции, которые могут понадобиться клиентам. А необходимые для работы каркаса низкоуровневые функции Kernel (ассемблерный код, прямая работа с памятью) не могут быть реализованы (или хотя бы представлены в виде абстракций) платформо-независимо. | Минусом является то, что модуль *Kernel* это специфический системный модуль: невозможно наверняка предугадать абстракции, которые могут понадобиться клиентам. А необходимые для работы каркаса низкоуровневые функции *Kernel* (ассемблерный код, прямая работа с памятью) не могут быть реализованы (или хотя бы представлены в виде абстракций) платформо-независимо. |
| |
| Решением данной проблемы может стать использование специальных соглашений и разделение платформо-зависимых компонентов на абстракции и платформо-зависимые реализации (Host-компоненты). | Решением данной проблемы может стать использование специальных соглашений и разделение платформо-зависимых компонентов на абстракции и платформо-зависимые реализации (Host-компоненты). |
| ## Устранение зависимостей от подсистемы Host ## | ## Устранение зависимостей от подсистемы Host ## |
| |
| Модули подсистем Std и System, входящие в эталон BlackBox по большей части являются платформо-независимыми. Однако, в некоторых местах обнаруживаются прямые (импорт) или косвенные (через строковые константы/ресурсы, отображения на формах и т.д.) зависимости от подсистемы Host. | Модули подсистем *Std* и *System*, входящие в эталон BlackBox, по большей части являются платформо-независимыми. Однако, в некоторых местах обнаруживаются прямые (импорт) или косвенные (через строковые константы/ресурсы, отображения на формах и т.д.) зависимости от подсистемы *Host*. |
| | |
| | Эти зависимости в той или иной степени обеспечивают функционирование эталона, при этом ухудшая его платформо-независимость. Так как функциональность *Host* нужна системному слою, то необходимо сохранить её, но уже с использованием герметичных решений. |
| |
| Эти зависимости в той или иной степени обеспечивают функционирование эталона, при этом, ухудшая его платформо-независимость. Так как функции, которые обеспечивает Host необходимы системному слою, необходимо предоставить возможность использования этих функций, но уже с использованием герметичных решений. | Для устранения зависимости подсистемы *Std* от *Host* введём ряд дополнительных абстракций в подсистему *System*, которые заместят необходимые ранее зависимости. А подсистему *Host* дополним подсистемой *Oberhost* (рабочее название, которое может измениться в дальнейшем), в которой находятся реализации этих абстракций. |
| |
| Для устранения зависимости подсистемы Std от Host введем ряд дополнительных абстракций в подсистему System, которые заместят необходимые ранее зависимости. А подсистему Host дополним подсистемой Oberhost, в которой находятся реализации этих абстракций. | Некоторые прямые и косвенные зависимости (формы, строковые ресурсы) подсистем *Std* и *System* могут быть перемещены в подсистему *Host* целиком, или частично. Например, модуль *StdMenuTool* или содержимое меню *(System)Menus*, которое состоит из текстовых команд зависящих от подсистемы *Host*. Такие команды могут быть размещены в меню *(Host)Menus*. |
| |
| Некоторые прямые и косвенные зависимости (формы, строковые ресурсы) подсистем Std и System могут быть перемещены в подсистему Host целиком, или частично. Например, модуль StdMenuTool или содержимое меню (System)Menus, которое состоит из текстовых команд зависящих от подсистемы Host. Такие команды могут быть размещены в меню (Host)Menus. | Прикладные компоненты с зависимостями от *Host*, должны быть аналогичным образом преобразованы в набор абстракций и Host-реализаций. |
| |
| Прикладные компоненты с зависимостями от Host, должны быть аналогичным образом преобразованы в набор абстракций и Host-реализаций. | ---- |
| |
| | Кушнир П.М., Кузьмицкий И.А. |
| |
| | Ярославль, 2013 г. |
| |
