Меня заинтересовал вопрос, можно ли использовать подсистемы JU независимо друг от друга.

Вспомним, что же такое подсистема.В доке ББ предлагается коллекции связанных компонентов размещать в отдельной папке:> -- BlackBox Design Practices, Figure 3-6 писал(а):
> For the BlackBox Component Builder, it is a convention that collections of related components, called subsystems, are placed into separate directories;
Стало быть, если компоненты разложены по разным папкам, то можно предположить возможность раздельного использования. Что же можно использовать из системы JU? Я напустил анализатор зависимостей на список компиляции JUstd\Docu\Tool-Map, потом свёл всё это в одну картинку:



Я надеялся получить послойное представление, но вышло несколько другое. Подсистема JUstd действительно представляет из себя отдельную прослойку, которую используют все остальные части JU. Особняком стоит JUhost, которая инсталлируется в JUmgr. Другие подсистемы в той или иной степени зависят друг от друга и разорвать связи невозможно.

Фактически, перед нами двухуровневая схема "JUstd -> механизмы JU". Уровень сервисов JUstd можно назвать независимым, а уровень механизмов, несмотря на вполне наглядное функциональное деление, выглядит монолитным.

Подведя итог, скажу так - принцип разделения JU на шесть папок-подсистем мне остался неясен. Тут максимум две подсистемы, а то даже одна, ведь сервисы JUstd разрабатывались для решения задач именно JU, и вряд ли в обозримом будущем их кто-то будет использовать независимо.

Проблема обозначения функциональных блоков вполне решается соответствующими префиксами в именах модулей. Я даже провёл эксперимент, файл JUhost\Mod\Analyzer перенёс в Ju\Mod\HostAnalyzer, читаемость не уменьшиласьВ защиту этой точки зрения добавлю, что все подсистемы JU сейчас компилируются единым списком из JUstd, а это говорит о том, что чисто логически JU - единая подсистема, а не агрегат из шести раздельных подсистем.

Что касается выделения гуя или загадочной JUdir в отдельные папки - а стоит ли овчинка выделки? В JUdir пять модулей, в JUmgr семь, не шибко много. К тому же это опять часть JU, даже по названию видно, и вряд ли кто-то из разработчиков будет использовать остальные подсистемы JU без dir и mgr. Конечно, в конкретный комплект клиентского приложения может не входить гуй, но для этого не нужна отдельная подсистема, достаточно просто не класть в комплект соответствующие модули и ресурсы.

P.S. Мне было интересно разобраться, потому что опыт анализа инфраструктуры всегда полезен. Критерии определения подсистемы всегда несколько размыты, поэтому уточнение никогда не помешает.