Почитал предлагаемые решения. У Руслана Богатырева очень масштабный взгляд на проблему - разные виды пакетов с учетом асинхронности среды выполнения и т.п. Начать хотелось бы с чего-то попроще. Поскольку задача наша сформулирована, я подытожу лишь основные требования к системе модулей (поправляйте, если что):
[list=]
Наглядное описание состава системы и связей внутри нее;
Ограничение на видимость, наследуемость элементов каждого модуля системы. Ограничение на запись/чтение их значений;
Предъявленные требования должны выполняться при условии вхождения модуля в состав системы (пакета);
[/list]
Несколько раз переписывал свое сообщение и до конкретного предложения так и не дошел. Приведу цепочку своих рассуждений, чтобы можно было выявить ошибки. Ничего нового в них нет, явно или неявно повторяются уже предлагавшиеся варианты, но вдруг кого-то наведет на мысль...
Итак, организация множества модулей в условную систему, по-моему, не привносит в нее ни одной радикально новой черты или свойства (всеми перечисленными свойствами обладает и каждый модуль в отдельности), соответственно, незачем и порождать новые сущности.
Первое тербование выполняется априори: модульная структура легко составляется по разделам IMPORT каждого модуля. Если нам известны модули, составляющие систему, то структура системы очевидна.
На уровне модуля, вообще ничего не должно изменяться, в связи с его входом в состав системы (или даже нескольких). Он по своему "положению" не может ничего знать о структуре, которая, как мы договорились, является следующим уровнем абстракции.
Получается, нам нужна отдельная структура, которая бы содержала информацию о новой организации модулей (системе). А также могла обеспечить выполнение остальных требований.
Структурной единицей оберон-систем является модуль. Попробуем его подставить на требующееся место. Пусть это будет "описательный" модуль, который станет признаком системы. Дальше я крутил его и так и сяк, но удобного решения не нашел. Выделилось 2 крайних варианта.
Первый вариант. Он будет импортировать все модули, входящие в систему и "перекрывать" их интефейсы. SYM-файлы остальных модулей системы пусть считаются неактивными или вообще удаляются. Работа с системой осуществляется через единственный интерфейс "описательного" модуля.
Минус: система не привязана к описательному модулю. Удаляем его - и перед нами все раскрыто.
Второй вариант. Все модули системы импортируют "описательный". Тогда его невозможно исключить из системы. Однако, в таком случае, он не будет явно знать о составе системы и не сможет перекрывать их интерфейсы.
Единственным результатом моих рассуждений, на данный момент, явилась формулировка противоречия для построения системы модулей: "Нужен модуль, который являлся бы неотъемлемой частью системы и, с другой стороны, знал все ее составляющие и мог перекрывать их интерфейсы." Так-как в модульной структуре все связи односторонние, получается, в идеальном варианте, наш "описательный" модуль должен быть и "на входе" и "на выходе" системы (в самом начале дерева импорта и в самом ее конце).
Теперь беремся за АРИЗ и предлагаем варианты решения противоречия!