OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Четверг, 16 Август, 2018 13:04

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 16 ] 
Автор Сообщение
СообщениеДобавлено: Суббота, 13 Апрель, 2013 19:07 

Зарегистрирован: Вторник, 29 Август, 2006 12:32
Сообщения: 2516
Откуда: Россия, Ярославль
JU это от "Jabber Updater", забавное историческое название. Когда-то давно первый прототип был предназначен для распространения маленьких архивов по зданию института через джаббер и распаковке этих архивов в каталог ББ.

Суть подсистемы в том, что она позволяет автоматизировать несколько процессов:
1) составление актуального списка файлов (кодовых файлов, ресурсов и прочего) конкретного приложения (Проекта), которое вы разрабатываете в ББ.
2) создание архивов (Пакет), которые содержат только изменённые файлы из списка всех файлов из (1), то есть, при изменении одного модуля будет упакован в обновление только один модуль. Экономия и всё такое.
3) обработку этих архивов на стороне клиента, то есть, то что принято называть "система обновления", получаем архив из (2), обрабатываем, распаковываем средствами встраиваемой части.
4) в планах так же было создание инструмента автоматического анализа сырцов на предмет фиксирования новых модулей, которые нужны вашему приложению из (1). Анализ штука трудоёмкая, но в принципе, анализ зависимостей (прямых и обратных) уже более менее готов.
5) ну и дань истории, реализованный способ передачи пакетов по джабберу :)

Как можно видеть, функций много, и соответственно функциям сложилось разделение компоненты на подсистемы:
JUapp - основные сущности, Проект, Пакет, Конвертеры и прочее.
JUstd - основные сервисы, архиватор, хранилище, и прочее.
JUmgr - менеджер проектов, пользовательский интерфейс для формирования Проектов, опирается на сервисы.
JUemb - встраиваемая часть, используется для соединения вашего проекта с системой обновлений.
JUdir - абстракция источников обновлений, и реализации для файловой системы и для удалённого джаббер-ресурса с обновлениями.
JUhost - хост-часть и грязные хаки, которые по необходимости приходилось применять, и чтобы обозначить их хост-сущность они были вынесены в отдельную подсистему.
ну и плюс всякие там зависимости.

Сейчас система работает достаточно стабильно на нескольких наших внутренних проектах, но пока не развивается, опенгл-хостъ съедает всё доступное время.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 13 Апрель, 2013 19:14 

Зарегистрирован: Вторник, 29 Август, 2006 12:32
Сообщения: 2516
Откуда: Россия, Ярославль
Шесть подсистем, больше чем в O3 web framework :)

Основным посылом для разделения на подсистемы послужило наличие хост-части, встраиваемой части, и менеджера с гуем.
Очевидно, хост-часть может быть заменяемой, а значит её можно будет заменить на уровне подсистемы, например, при использовании параметра /USE или /SHADOW
А ещё очевидно, что гуй менеджера вообще не нужен в вашем приложении, поэтому он должен быть отделяемым.
А потом, когда я реализовал необязательный сервисный компонент JUdir, который использует сущности проекта и пакета, стало понятно, что их тоже надо выделить в отдельную подсистему.
Разделение JUapp и JUstd вроде и необязательно, но оно показывает нам, что app часть кроссплатформенная и ни от чего не зависит, лежит в основе всего, а для std-части, хоть она и кроссплатформеная, нужна реализация хост-части.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 13 Апрель, 2013 19:37 

Зарегистрирован: Четверг, 17 Ноябрь, 2005 11:51
Сообщения: 2930
Откуда: г. Ярославль
Пётр Кушнир писал(а):
Разделение JUapp и JUstd вроде и необязательно, но оно показывает нам, что app часть кроссплатформенная и ни от чего не зависит...
Это спорное утверждение, т.к. JUapp сильно зависит от JUstd, причём уже на уровне импорта. Ну а модули JUstd, похоже, импортированы во все остальные подсистемы JU, то есть, просто взять и заменить JUstd никак не выйдет.

Да, и в этом разрезе непонятен термин "хост", т.к. JUhost использует возможности подсистемы JUstd, а значит, JUstd более нижнего уровня, чем JUhost.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 13 Апрель, 2013 21:34 

Зарегистрирован: Вторник, 29 Август, 2006 12:32
Сообщения: 2516
Откуда: Россия, Ярославль
Иван Кузьмицкий писал(а):
Да, и в этом разрезе непонятен термин "хост", т.к. JUhost использует возможности подсистемы JUstd, а значит, JUstd более нижнего уровня, чем JUhost.

хост может использовать стандартные модули, почему нет?
Инверсия зависимости, не Std зависит от хоста, а наоборот. Стало быть хост с зависимостью от платформы можно заменить. Ну и если так рассуждать, то модули System более нижнего уровня, чем Host.

Иван Кузьмицкий писал(а):
Это спорное утверждение, т.к. JUapp сильно зависит от JUstd, причём уже на уровне импорта. Ну а модули JUstd, похоже, импортированы во все остальные подсистемы JU, то есть, просто взять и заменить JUstd никак не выйдет.
Да, там описка, JUstd ни от чего не зависит, то есть, ни от чего внутри JU, конечно.
Зачем менять JUstd?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 14 Апрель, 2013 10:05 

Зарегистрирован: Четверг, 17 Ноябрь, 2005 11:51
Сообщения: 2930
Откуда: г. Ярославль
Меня заинтересовал вопрос, можно ли использовать подсистемы 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. Мне было интересно разобраться, потому что опыт анализа инфраструктуры всегда полезен. Критерии определения подсистемы всегда несколько размыты, поэтому уточнение никогда не помешает.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 14 Апрель, 2013 10:49 

Зарегистрирован: Четверг, 17 Ноябрь, 2005 11:51
Сообщения: 2930
Откуда: г. Ярославль
Пётр Кушнир писал(а):
Основным посылом для разделения на подсистемы послужило наличие хост-части, встраиваемой части, и менеджера с гуем.
Хост и менеджер связаны меж собой, и используют остальные интерфейсы JU. Если опираться на соглашения ББ, то они должны быть в общей подсистеме. Группирование компонентов по функциональному принципу и деление на подсистемы по принципу связности, на мой взгляд, суть разные вещи.
Пётр Кушнир писал(а):
Очевидно, хост-часть может быть заменяемой, а значит её можно будет заменить на уровне подсистемы, например, при использовании параметра /USE или /SHADOW
Там же инсталлируемые реализации, а это значит, что при возникновении необходимости замены хоста, я спокойно инсталлирую собственные реализации, не обращая внимания на наличие стандартного хоста. Мне нет нужды выделять собственную реализацию в отдельную подсистему, так как это ни на что не повлияет, поэтому выделение JUhost в подсистему не имеет смысла тоже.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 14 Апрель, 2013 11:13 

Зарегистрирован: Вторник, 29 Август, 2006 12:32
Сообщения: 2516
Откуда: Россия, Ярославль
Иван Кузьмицкий писал(а):
достаточно просто не класть в комплект соответствующие модули и ресурсы.

В WinAOS вообще нет подсистем. И не страдают.

emb и dir встраиваемые части
mgr программерская
host платформозависимая
std утилитарная
app базовая

Конечно, если намеренно говорить "А можно ли использовать app отдельно?" всегда будет за что потыкать. Это зависимость, запрещать зависимости теперь чтоли?
Можно использовать emb без mgr, можно не использовать ни emb, ни dir, ни mgr, и при этом останется возможность написать своё приложение для JU.
Иван Кузьмицкий писал(а):
файл JUhost\Mod\Analyzer перенёс в Ju\Mod\HostAnalyzer, читаемость не уменьшилась
Это субъективно.
Иван Кузьмицкий писал(а):
В доке ББ предлагается коллекции
Я уже разбирал это определение в рассылке ББ в споре про O3, в определении никак не ограничивается состав компонентов, если у меня компонент в виде двух подсистем, никто этого не регулирует и не предопределяет законы по размещению модулей.

Картинка должна быть такой
Изображение
Тогда понятно, что существуют вполне очевидные пользовательские службы, которые имеют разные цели. Объединение JUapp и JUstd будет нарушать схему, в которой появляется JUsuperApp, которое использует только стандартные модули JU, дополняя сущности app новыми.
Иван Кузьмицкий писал(а):
все подсистемы JU сейчас компилируются единым списком из JUstd, а это говорит о том, что чисто логически JU - единая подсистема, а не агрегат из шести раздельных подсистем.
Это наследие кровавого монолитного прошлого, удобнее компилировать из одного списка, и, это не единая подсистема.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 14 Апрель, 2013 11:18 

Зарегистрирован: Вторник, 29 Август, 2006 12:32
Сообщения: 2516
Откуда: Россия, Ярославль
Иван Кузьмицкий писал(а):
Хост и менеджер связаны меж собой, и используют остальные интерфейсы JU. Если опираться на соглашения ББ, то они должны быть в общей подсистеме. Группирование компонентов по функциональному принципу и деление на подсистемы по принципу связности, на мой взгляд, суть разные вещи.
Нет, не между собой, а в одну сторону, хост реализует предоставленные интерфейсы. Подозреваю, что в новом ББ старая хост-часть JU будет вообще не нужна. И включать её в состав другой подсистемы значит вводить зависимость от старого хоста во всю подсистему.
Ну или делать отдельный список компиляции для хост-модулей, что повторит решение с отдельным хостом.
Иван Кузьмицкий писал(а):
Там же инсталлируемые реализации, а это значит, что при возникновении необходимости замены хоста, я спокойно инсталлирую собственные реализации, не обращая внимания на наличие стандартного хоста. Мне нет нужды выделять собственную реализацию в отдельную подсистему, так как это ни на что не повлияет, поэтому выделение JUhost в подсистему не имеет смысла тоже.
Это субъективные вещи.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 14 Апрель, 2013 11:53 

Зарегистрирован: Четверг, 17 Ноябрь, 2005 11:51
Сообщения: 2930
Откуда: г. Ярославль
Пётр Кушнир писал(а):
Иван Кузьмицкий писал(а):
Хост и менеджер связаны меж собой, и используют остальные интерфейсы JU. Если опираться на соглашения ББ, то они должны быть в общей подсистеме. Группирование компонентов по функциональному принципу и деление на подсистемы по принципу связности, на мой взгляд, суть разные вещи.
Нет, не между собой, а в одну сторону, хост реализует предоставленные интерфейсы. Подозреваю, что в новом ББ старая хост-часть JU будет вообще не нужна. И включать её в состав другой подсистемы значит вводить зависимость от старого хоста во всю подсистему.
Что значит, "вводить зависимость во всю подсистему"? Да, хост реализует интерфейс JUmgr. Это интерфейсная зависимость. Но JUmgr не может функционировать без JUhost, это функциональная зависимость. Если функциональные модули положить в общую папку, разве это повлияет на интерфейсные и функциональные зависимости? Никак не повлияет. Поэтому говорить о наличии каких-то других, особенных зависимостей в общей подсистеме нельзя, это рассуждения ни о чём.

Пётр Кушнир писал(а):
Иван Кузьмицкий писал(а):
Мне нет нужды выделять собственную реализацию в отдельную подсистему, так как это ни на что не повлияет, поэтому выделение JUhost в подсистему не имеет смысла тоже.
Это субъективные вещи.
Я вижу только функциональные и интерфейсные зависимости. Расположение модулей по разным подсистемам на них никак не влияет. Если это субъективно, значит, я не вижу ещё каких-то зависимостей, вопрос - каких?


Пётр Кушнир писал(а):
В WinAOS вообще нет подсистем. И не страдают.

emb и dir встраиваемые части
mgr программерская
host платформозависимая
std утилитарная
app базовая
В подсистеме Projector, например, 84 модуля. Их тоже можно поделить на подобные функциональные части (не менее десятка возможных подсистем, с лёту можно насчитать), но они лежат в одной папке и никакие зависимости не нарушаются.

Пётр Кушнир писал(а):
Конечно, если намеренно говорить "А можно ли использовать app отдельно?" всегда будет за что потыкать. Это зависимость, запрещать зависимости теперь чтоли?
Можно использовать emb без mgr, можно не использовать ни emb, ни dir, ни mgr, и при этом останется возможность написать своё приложение для JU.
Я думаю, стоит определить, с какими видами зависимостей мы имеем дело, объективно. Чтобы не допускать субъективной группировки модулей по какому угодно принципу.

Пётр Кушнир писал(а):
Я уже разбирал это определение в рассылке ББ в споре про O3, в определении никак не ограничивается состав компонентов, если у меня компонент в виде двух подсистем, никто этого не регулирует и не предопределяет законы по размещению модулей.
Начнём с того, что это не жёсткое определение, а довольно размытое соглашение. Для нас же важно определить виды зависимостей, чтобы понимать - когда выгодно выделить отдельную подсистему, а когда это выделение увеличивает сложность. Да, и подсистема - это не компонент. Можно взять определение Куно Пфистера, которое опирается на понятие интерфейса компонента, связанного с его содержанием. А у подсистемы нет интерфейса, потому что это коллекция компонентов.

Пётр Кушнир писал(а):
ИзображениеИзображение
Если их поставить рядом, то легко увидим - JUhost покрашена в красный, а взаимосвязи остались без изменений. Суть не поменялась.

Пётр Кушнир писал(а):
Тогда понятно, что существуют вполне очевидные пользовательские службы, которые имеют разные цели.
Речь идёт о функциональных блоках, это очевидно. "Пользовательская служба" (кстати, что это?) никоим образом не требует для себя отдельной подсистемы в обязательном порядке.

Пётр Кушнир писал(а):
Объединение JUapp и JUstd будет нарушать схему
Никаких новых зависимостей не появляется, объединение чисто механическое, файлы переложили в одну папку, а на функциональности компонентов это вообще никак не отразилось. Или тут речь о каком-то другом объединении, которое формализуется в исходных текстах?

Пётр Кушнир писал(а):
, в которой появляется JUsuperApp, которое использует только стандартные модули JU, дополняя сущности app новыми.
Файлы всего лишь положили в одну папку, и это вызвало необходимость появления новой сущности? С чего вдруг? ;)

Пётр Кушнир писал(а):
Это наследие кровавого монолитного прошлого, удобнее компилировать из одного списка, и, это не единая подсистема.
Для новых пользователей это тест на сообразительность - попробуй найди список компиляции JU :) Не сообразил - значит, по интеллекту не подходишь, систему JU тебе не судьба юзать!


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 14 Апрель, 2013 14:28 
Аватара пользователя

Зарегистрирован: Пятница, 25 Сентябрь, 2009 13:10
Сообщения: 1158
Откуда: Tel-Aviv
Поясните: JU - это менеджер обновлений, который включает систему контроля версий компонентов некоторого проекта?


Последний раз редактировалось Роман М. Воскресенье, 14 Апрель, 2013 14:35, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 14 Апрель, 2013 14:31 
Аватара пользователя

Зарегистрирован: Пятница, 25 Сентябрь, 2009 13:10
Сообщения: 1158
Откуда: Tel-Aviv
И чем обоснован выбор технологий? Того же протокола обмена данными, к примеру.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 14 Апрель, 2013 14:39 

Зарегистрирован: Вторник, 29 Август, 2006 12:32
Сообщения: 2516
Откуда: Россия, Ярославль
Иван Кузьмицкий писал(а):
Поэтому говорить о наличии каких-то других, особенных зависимостей в общей подсистеме нельзя, это рассуждения ни о чём.
Это схоластика. Необходимость наличия в памяти фабрики, которую создают в хосте вообще не обязывает хранить хост в одной подсистеме с модулями-клиентам фабрики. В этом и суть, расположение модулей влияет на субъективное восприятие, объективно компилятору всё равно. А значит, споров про "смыслы" может быть бесконечно много. А формально, я уже сказал, в винАОС нет подсистем в виде каталогов, и никто не страдает.
В данном случае я вижу попытку признать решение с разделением модулей по подсистемам неканоничным без наличия канона.
Иван Кузьмицкий писал(а):
В подсистеме Projector, например, 84 модуля. Их тоже можно поделить на подобные функциональные части (не менее десятка возможных подсистем, с лёту можно насчитать), но они лежат в одной папке и никакие зависимости не нарушаются.
Возможно, разделение поможет ему совершить квантовый скачок в развитии :mrgreen:
Иван Кузьмицкий писал(а):
Если их поставить рядом, то легко увидим - JUhost покрашена в красный, а взаимосвязи остались без изменений. Суть не поменялась.
Поменялись уровни расположения. Этого не хватает в рассуждениях.
Иван Кузьмицкий писал(а):
Файлы всего лишь положили в одну папку, и это вызвало необходимость появления новой сущности? С чего вдруг?
Без комментариев. Я вижу непонимание примера. Если появляется superApp, который импортирует std, он распологается на одном уровне с app. Иначе, если superApp импортирует app ради того, что мы называем std, то superApp размещается на уровень ниже.
Иван Кузьмицкий писал(а):
Для новых пользователей это тест на сообразительность - попробуй найди список компиляции JU Не сообразил - значит, по интеллекту не подходишь, систему JU тебе не судьба юзать!
Да их и нету, этих пользователей, зачем о них думать?
Иван Кузьмицкий писал(а):
"Пользовательская служба" (кстати, что это?)
Это всё то, что пользуется сервисами, которые предоставлены подсистемой Xxx и не представлено в виде абстракции внутри Xxx.
Иван Кузьмицкий писал(а):
А у подсистемы нет интерфейса, потому что это коллекция компонентов.
Ну, видимо, интерфейс подсистемы будет состоять из интерфейсов модулей внутри неё. Пишем ведь "IMPORT SubMod".
Иван Кузьмицкий писал(а):
достаточно просто не класть в комплект соответствующие модули и ресурсы.
То есть, объективно получается, что смысловое разделение групп модулей внутри подсистемы надо будет документировать отдельно, оговаривая правила дистрибуции и разделения реализаций.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 14 Апрель, 2013 14:45 

Зарегистрирован: Вторник, 29 Август, 2006 12:32
Сообщения: 2516
Откуда: Россия, Ярославль
Роман М. писал(а):
Поясните: JU - это менеджер обновлений, который включает систему контроля версий компонентов некоторого проекта?

Да, имеются функции слежения за содержимым файлов проекта, при этом для кодовых файлов используется особый алгоритм, анализирующий содержимое игнорируя отметку о времени компиляции, то есть модуль в котором ничего не меняли, просто откомпилированный заодно со всеми, не будет включён в пакет изменений.
Роман М. писал(а):
И чем обоснован выбор технологий? Того же протокола обмена данными, к примеру.
Ну, изначально только джабер и был в наличии, а вообще можно любой протокол воткнуть. Ну, пакеты в формате Zip. Список файлов в формате XML, сжатый в зип. В ББ не так много полезных штук, чтобы можно было выбирать.
А вообще не знаю, как вы видите достаточное обоснование выбора технологий?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 14 Апрель, 2013 14:59 
Аватара пользователя

Зарегистрирован: Пятница, 25 Сентябрь, 2009 13:10
Сообщения: 1158
Откуда: Tel-Aviv
Значит, менеджер обновлений для ББ и только. Ну тогда насчёт выбора Джаббера тоже ясно: под рукой, наверно, была готова его реализация, что и повлияло на выбор.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 14 Апрель, 2013 15:03 

Зарегистрирован: Вторник, 29 Август, 2006 12:32
Сообщения: 2516
Откуда: Россия, Ярославль
Ну почему, можно любые файлы добавлять, просто ориентация на ББ, да, вполне понятна.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 14 Апрель, 2013 18:03 

Зарегистрирован: Четверг, 17 Ноябрь, 2005 11:51
Сообщения: 2930
Откуда: г. Ярославль
Пётр Кушнир писал(а):
Иван Кузьмицкий писал(а):
Поэтому говорить о наличии каких-то других, особенных зависимостей в общей подсистеме нельзя, это рассуждения ни о чём.
Это схоластика. Необходимость наличия в памяти фабрики, которую создают в хосте вообще не обязывает хранить хост в одной подсистеме с модулями-клиентам фабрики. В этом и суть, расположение модулей влияет на субъективное восприятие, объективно компилятору всё равно. А значит, споров про "смыслы" может быть бесконечно много. А формально, я уже сказал, в винАОС нет подсистем в виде каталогов, и никто не страдает.
В данном случае я вижу попытку признать решение с разделением модулей по подсистемам неканоничным без наличия канона.
Я что-то не вижу связи между наличием какой-то фабрики (мы про неё не говорили, откуда она взялась?) и субъективным восприятием модулей (это вообще причём тут?). В винаос нету подсистем, прекрасно, так зачем понадобилось дробить одно маленькое приложение JU на несколько подсистем? Объяснения до сих пор нет. Канон в ББ есть, он описан, это соглашение хранить все связанные компоненты в одной коллекции.

Конечно, я не исключаю ситуации, когда ядро приложения, сервисный слой и гуй необходимо разделять по отдельным каталогам. Но это реально может потребоваться только в одном случае - когда на этом разделении зарабатываются деньги. Ядро продаётся отдельно, сервисы отдельно, гуй отдельно. Иначе получается действительно, схоластика и разговоры о "канонах".

Для чего ввели подсистемы в ББ? Да ровно для того же самого, чтобы расширять ББ платными компонентами. Компонент должен поставляться одновременно со своими частями (кодовые, символьные, исходники, документация, ресурсы), и это логично делать путём выделения подсистем в отдельные каталоги.

Пётр Кушнир писал(а):
Иван Кузьмицкий писал(а):
В подсистеме Projector, например, 84 модуля. Их тоже можно поделить на подобные функциональные части (не менее десятка возможных подсистем, с лёту можно насчитать), но они лежат в одной папке и никакие зависимости не нарушаются.
Возможно, разделение поможет ему совершить квантовый скачок в развитии :mrgreen:
Ну это как перестановка мебели по фэншую позволит добиться счастья в жизни. Или покрасить Кремль в зелёный цвет, приёмы рядоположные.

Пётр Кушнир писал(а):
Иван Кузьмицкий писал(а):
Для новых пользователей это тест на сообразительность - попробуй найди список компиляции JU Не сообразил - значит, по интеллекту не подходишь, систему JU тебе не судьба юзать!
Да их и нету, этих пользователей, зачем о них думать?
О них уже подумали, и всерьёз, раскроив микропроект на шесть частей. Всю дорогу об этом речь идёт - как использовать JU по частям, разве не так?

Пётр Кушнир писал(а):
Иван Кузьмицкий писал(а):
"Пользовательская служба" (кстати, что это?)
Это всё то, что пользуется сервисами, которые предоставлены подсистемой Xxx и не представлено в виде абстракции внутри Xxx.
Что-то я вообще не понял, о чём речь, если честно. Абстракция - это POINTER TO ABSTRACT RECORD? А POINTER TO LIMITED RECORD или вообще POINTER TO RECORD уже не абстракция, и то, что их использует, пользовательской службой уже нельзя назвать? А не-пользовательские службы как выглядят?

Пётр Кушнир писал(а):
Иван Кузьмицкий писал(а):
А у подсистемы нет интерфейса, потому что это коллекция компонентов.
Ну, видимо, интерфейс подсистемы будет состоять из интерфейсов модулей внутри неё. Пишем ведь "IMPORT SubMod".
Всё-таки рекомендую почитать хотя бы Пфистера, что он там "понавыдумывал" про компоненты, я уж не говорю о Design Practices :) А то от понимания можно уйти легко и далеко.

Пётр Кушнир писал(а):
Иван Кузьмицкий писал(а):
достаточно просто не класть в комплект соответствующие модули и ресурсы.
То есть, объективно получается, что смысловое разделение групп модулей внутри подсистемы надо будет документировать отдельно, оговаривая правила дистрибуции и разделения реализаций.
Ну я так и знал, что в конце-концов обсуждение придёт к страшной и ужасной проблеме документирования :) А если серьёзно, то см. выше, тезис про деньги. Все проблемы, которые предлагается решать делением JU на несколько подсистем, спокойно решаются в рамках одной-единственной подсистемы.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 16 ] 

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
cron
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2018, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB