Показаны различия между двумя версиями страницы.
Предыдущая версия справа и слева Предыдущая версия Следующая версия | Предыдущая версия | ||
bbnohost [2013/12/04 16:47] admin |
bbnohost [2018/11/30 01:12] |
||
---|---|---|---|
Строка 1: | Строка 1: | ||
- | ![Схема](https:// | ||
- | Рис.1. Переход от " | ||
- | |||
- | # Проблема герметичности # | ||
- | |||
- | Блэкбокс с точки зрения пользователя является обычным приложением. То есть, для работы ему необходима **операционная система**. | ||
- | |||
- | Блэкбокс с точки зрения программной архитектуры является компонентным каркасом, | ||
- | |||
- | Компонент с точки зрения каркаса является совокупностью скомпилированных модулей. Модули могут использовать возможности других модулей, | ||
- | |||
- | Среди всех компонентов можно выделить такие, которые не зависят от операционной системы и такие, которые зависят от неё. | ||
- | |||
- | В отдельную группу можно выделить компоненты, | ||
- | |||
- | Теперь можно ввести важное определение. Зависящие от операционной системы компоненты системного слоя составляют некий " | ||
- | |||
- | Рассмотрим устройство системного слоя в [эталоне](http:// | ||
- | Основой системы является модуль *Kernel*, который реализует поддержку времени выполнения для приложений BlackBox (см. [документацию](http:// | ||
- | Модуль *Kernel* использует возможности операционной системы (на рисунке эта зависимость обозначена красной стрелкой). | ||
- | Для работы клиентских (прикладных) модулей необходимы базовые абстракции файловой системы, | ||
- | |||
- | Разделение *System* на абстрактный интерфейс и платформо-зависимую реализацию позволяет добиться **герметичности** платформо-независимой части системного слоя. Герметичность позволяет заменять платформо-зависимые системные модули без модификации клиентских модулей. | ||
- | |||
- | В идеале, | ||
- | |||
- | # Решение проблемы нарушения герметичности # | ||
- | |||
- | ## Модификация модуля Kernel ## | ||
- | |||
- | На схеме показаны зависимости прикладного и системного слоя от модуля *Kernel*. | ||
- | |||
- | Эти зависимости не позволяют нам произвести безопасную замену модуля *Kernel*, например, | ||
- | |||
- | В целях устранения данного нарушения герметичности предлагается разделение интерфейса модуля *Kernel* на платформо-независимую (условно: | ||
- | |||
- | Плюсом данного решения является полное изолирование клиентских модулей от платформы. | ||
- | |||
- | Минусом является то, что модуль *Kernel* это специфический системный модуль: | ||
- | |||
- | Решением данной проблемы может стать использование специальных соглашений и разделение платформо-зависимых компонентов на абстракции и платформо-зависимые реализации (Host-компоненты). | ||
- | |||
- | ## Устранение зависимостей от подсистемы Host ## | ||
- | |||
- | Модули подсистем *Std* и *System*, входящие в эталон BlackBox, по большей части являются платформо-независимыми. Однако, | ||
- | |||
- | Эти зависимости в той или иной степени обеспечивают функционирование эталона, | ||
- | |||
- | Для устранения зависимости подсистемы *Std* от *Host* введём ряд дополнительных абстракций в подсистему *System*, которые заместят необходимые ранее зависимости. А подсистему *Host* дополним подсистемой *Oberhost* (рабочее название, | ||
- | |||
- | Некоторые прямые и косвенные зависимости (формы, | ||
- | |||
- | Прикладные компоненты с зависимостями от *Host*, должны быть аналогичным образом преобразованы в набор абстракций и Host-реализаций. | ||
- | |||
- | ---- | ||
- | |||
- | Кушнир П.М., Кузьмицкий И.А. | ||
- | |||
- | Ярославль, |