Стоп. Прошу прощения. "Образует граф". Все верно. Граф, но ациклический направленный и иерархический.
Читайте не "дерево", а иерархию. Суть не меняются.
Возвращаясь к примеру... Пусть модуль Net уже импортирует модуль Files. Таким образом, сервис от Files входит в качестве подсистемы в Net.
Модуль Server импортирует и Net, и Files - и обращается напрямую к Files. Ну и что? Иерархичность-то соблюдена! Files вошел в качестве подсистемы и в Server, и в Net. "Вассал моего вассала стал и моим вассалом". Но уровни-то строго очерчены, никаких "одноранговых" связей нет.

Ответ на »сообщение 4151« (ASU)
___________________________

Ответ на »сообщение 4145« (Илья Ермаков)
___________________________
Импорт в модульных языках может быть только иерархическим. Таким образом, вся статическая "связка" модулей образует дерево.
... не только иерархическим... В общем случае, статическая связка образует «граф».

За такой "общий случай" в Обероне бьет компилятор с сообщением "Cyclic import not allowed".
Иерархичность дерева импорта - одно из основных требований. В частности, чтобы гарантировать детерминированный порядок загрузки, инициализации и выгрузки модулей.
Это ж вам не include :-)

Ответ на »сообщение 4152« (Stargazer)
___________________________
Пользуясь той же стилистикой, скажу: системная логика стога сена формируется на логике взаимодействия травинок. Иначе стог не был бы стогом.
Логику стога сможете раскрыть? Расскажите, мне интересно...

Ничего себе. Летит самолёт, и вдруг у него отваливаются двигатели. Никто ничего не заметил, все продолжают лететь.
Всё чудесатее и чудесатее.
Если Вы не заметили, то повторю, что речь шла о нашей системе, а не о Вашем самолете. Ферштейн?.. «Блочный ремонт» без остановки для многих систем давно стал нормой... уважительного отношения к заказчикам/потребителям.

>>> как из модулей получить объект?(MS)
>>> пример на ассемблере... там всё ясно (ASU)
:)))

>>> Мы даже не знаем, что с чем сопоставляем.(Руслан Богатырёв)
>>> Мы ничего не сопоставляем... (ASU из более раннего)
:)

>>>... не только иерархическим... В общем случае, статическая связка образует «граф».
Вау! Опять переменивши !

>>> Дабы поставить точку в "системности" импорта модулей. (Илья Ермаков)
Хм ... Забавно ...

"Если у тебя есть фонтан - заткни его". (С) Козьма Прутков.

Ответ на »сообщение 4151« (ASU)
___________________________
Логика системы не может сформироваться из логик составляющих ее элементов. Это сено в стоге... не более того. В стоге каждая травинка взаимодействует со множеством других травинок, но система при этом не образуется.

Пользуясь той же стилистикой, скажу: системная логика стога сена формируется на логике взаимодействия травинок. Иначе стог не был бы стогом. Системообразованием крестьяне занимаются издавна, так что Ваш пример со стогом неудачный.

Например, в нашей системе выход из строя любой (в том числе, и системообразующих) подсистем не приводи к немедленному краху системы. Люди продолжают работать в системе даже не замечая, что не все в порядке. После восстановления «выпавшей» части она включится в работу прозрачно для пользователей.

Ничего себе. Летит самолёт, и вдруг у него отваливаются двигатели. Никто ничего не заметил, все продолжают лететь.
Всё чудесатее и чудесатее.

Ответ на »сообщение 4145« (Илья Ермаков)
___________________________
Импорт в модульных языках может быть только иерархическим. Таким образом, вся статическая "связка" модулей образует дерево.
... не только иерархическим... В общем случае, статическая связка образует «граф».

Рассматривайте всю цепь импорта от одного узла как систему. Срежьте этот узел - система распадется на подсистемы.
Она просто распадется... что не всегда допустимо. Например, в нашей системе выход из строя любой (в том числе, и системообразующих) подсистем не приводи к немедленному краху системы. Люди продолжают работать в системе даже не замечая, что не все в порядке. После восстановления «выпавшей» части она включится в работу прозрачно для пользователей. Мне кажется что для некоторых задач такое решение более предпочтительно, чем простой...

У меня есть две подсистемы - сетевая с лицевым модулем Net и файловая с лицевым модулем Files.
Я создам новый модуль Server. В начале модуля Server я напишу IMPORT Net, Files.
В итоге я получаю новую систему более высокого уровня, в которую в качестве подсистем вошли Net и Files. А вся собственная логика системы "сервер" собрана в модуле Server.
Таким образом, импорт модулей куда как системен...
Системен?.. Хорошо, если подсистемы написаны Вами и Вы гарантируете, что они не имеют других связей между собой, кроме тех, что Вы определили в модуле Server. При наличии же прямых связей Импорт модулей становится... несистемен... Как же так, то системен, то несистемен?.. Может быть этот механизм (импорта) просто... не до конца формализован?.. И в этом все дело? Представьте, что нет никакого импорта, а есть четко определенный интерфейс... как над-модульный механизм (то есть, такой, который разработчик не может изменить по своему «хотению»). Вы в модуле Server связываете отдельные интерфейсы, а модули Net и Files реализуют эти интерфейсы. Реализация интерфейса не должна допускать обращения к другому интерфейсу того же уровня (исключение прямых связей между элементами одного уровня), только к интерфейсам подуровня. Произвольность исчезла, надежность (которую совсем не зря любят «обероновцы») возрасла.
И еще... в Вашем решении... Попробуйте изменить логику Server, не останавливая работу системы... Сможете? Нет... Вы получили «неотчуждаемое» решение... то есть, Вы стали рабом (заложником) своего собственного детища... Любое изменение требует привлечения разработчика.

Ответ на »сообщение 4144« (Илья Ермаков)
___________________________
Посмотрим и с другой стороны. Вы не хотите и считаете вредным наличие "проектных" средств в языке.
С моей точки зрения, негоже смешивать две совершенно разные логики на одном уровне. Скорее всего, и та и другая логика (или хотя бы одна из них) получат ущербную реализацию.

Да, это прекрасно - спроектировать систему в специализированных средах. Но доходит дело до реализации - и что же мы видим? Все богатство наработанных отношений и связей напрямую выразить в языке мы не можем...
Это и плохо...

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

Елки-палки, да неужели же это лучше, чем иметь аккуратный, строгий набор средств единого языка, в который легко отобразить все ваши наработанные "особыми инструментами" проекты?
Согласитесь, что написать и изменить строчку в скрипте значительно проще, гибче и надежнее, чем при каждом изменении переписывать (пересобирать) программу...

Меня такие ставшие модными "мультиязыко-скриптовые" с позволения сказать "архитектуры" очень сильно раздражают. Напоминает нарезку деталей из трухлявой древесины корявого "основного языка", с последующей склейкой, уж извините, "соплями" всевозможных скриптов и скриптиков...
Мне нравятся Ваши сообщения, мысли... но это высказывание, увы, из другого ряда...
...кстати, а скрипт и к конечному пользователю проще адаптировать...

Инженеры-"железники" знают - где тонко, там и порвется.
... «а мягкое и гибкое побеждает твердое и жесткое»... младенец мягкий и гибкий, труп старика твердый и жесткий... трава мягкая и гибкая, асфальт который она пробила твердый и жесткий... Будем и дальше использовать такие аргументы?..

Кому что... Я предпочитаю "идеальную пригонку" универсального, строгого языка - дешевке mainstream-калейдоскопа...
А я предпочитаю... буйство жизни... Кому что...

Ответ на »сообщение 4142« (Илья Ермаков)
___________________________
Основными качествами системы, насколько я помню, является:
а) наличие четкой границы "система-окружение"
Только для закрытых систем. Для открытых систем это в принципе неверно. Попробуйте, для примера очертить границы себя. Воздух который внутри Вас – это Вы или нет? А тот, что Вы еще не вдохнули?.. То есть, открытая система постоянно ведет обмен с внешней средой и строго сказать, где еще система, а где уже окружение... нельзя. Граница государств и предприятий не проходит по забору...

б) наличие внутренней структуры: подсистем и их связей
Безусловно.

в) наличие собственной логики (система представляет собой нечто большее, чем сумма частей, что Вы справедливо все время подчеркиваете).
Да.

Пункт "наличие собственной логики" может, на самом деле, предполагать все, что угодно. Логика может концентрироваться на отдельном "объемлющем" уровне системы, а может - в ее внутренних связях. И связи эти могут быть как гибкими, так и жесткими. И инициироваться связи могут как централизованно, с "объемлющего" уровня, так и каждой подсистемой в отдельности. Самоорганизующиеся системы как раз-таки характеризуются тем, что связи инициируются отдельными элементами системы.
Вы поднимаете очень важный и серьезный вопрос. Логика всегда сконцентрирована в над-уровне (в над-системе). Реализация этой логики может быть передана на нижние уровни. Конструктор соединил две части, теперь часть А «намертво» привязана к части Б. Мы не знаем ни конструктора, ни его замысла. Для нас очевидна прямая связь между А и Б. Но конструктор (обладая авторским правом) может иначе соединить части А-В-Б. Это пример прямого управления. Два предприятия заключили договор и взаимодействуют... но строго в рамках законодательства, иначе их связь будет разорвана. Это пример косвенного управления. (Законодательство посредством нормативных актов и правительство путем стимулирования постоянно воздействуют на экономику).
Другими словами. «Слабые» связи есть всегда и есть над-уровень, даже если мы его не можем наблюдать непосредственно.

Есть отдельные системы a, b, c, d..., обладающие некотрыми интерфейсами. Они оказались вместе ("сумма") и по своей инициативе образовали взаимные связи. Каждая система знает, с кем взаимодействует. Однако именно в этих взаимодействиях и заключена логика системы, только в данном случае - не централизованная, а распределенная.
Значит (над-) система есть, у системы есть логика... а связи элементы (под-системы) образовали по своей инициативе?.. Согласитесь, что это не выглядит убедительным.

Просто совокупность a, b, c, d не была системой. Совокупность a, b, c, d, образовавших между собой прямые связи и взаимодействие, уже дает систему, поскольку это нечто большее, чем просто сумма частей, обладающее качественными особенностями и новыми возможностями.
Логика системы не может сформироваться из логик составляющих ее элементов. Это сено в стоге... не более того. В стоге каждая травинка взаимодействует со множеством других травинок, но система при этом не образуется.

Чем плохо введение в язык "системных" в Вашем понимании возможностей?
Очевидно тем же, чем был неугоден GoTo адептам структурного программирования... Система превращается в «спагетти» за счет связей между подсистемами. Тем, что вопросы образования системы решаются по ходу дела в частном порядке. И, несмотря на то, что каждая часть (модуль, компонент) может быть почти идеальной, система в целом получается... кривой. На своем веку я видел много великолепных программистов, которые писали замечательный код, которые знали особенности кодогенерации десятков компиляторов... но хороших архитектур видел очень мало. А Вы?

Чем плохо, что программируя на Обероне, я несколько раз в день разбиваю с помощью модульной декомпозиции разрабатываемый сервис на отдельные "подсистемы", слои со строго специфицированными связями через "узкие горла"?
В этом я не вижу ничего плохого...

Что вместо написания "монолита" я разбиваю на изолированные модули, связь между которыми выношу на отдельный уровень, уровень диспетчерских модулей - ну прямо "по ASU" :-)
Чем плохо, что каждый студент с самых первых занятий усваивает принципы таких архитектур?
Ничего плохого и в этом не вижу... (хотя ссылка на ASU совершенно лишняя).

Вы же предлагаете "элитарность системного подхода", когда рядовые разработчики как муравьи будут копошиться в хаосе вермишели на "бессистемных" 3GL, а "гуру" из отдела системного анализа будут применять "особые подходы", недоступные простым смертным? (я Вас не упрекаю в такой "злонамеренности", Боже упаси, я просто пытаюсь вскрыть противоречия вашей позиции).
Нет никакой «злонамеренности»... И картина, как раз совершенно обратная... Сначала разработчики обсуждают архитектуру будущей системы, потом определяют структуру каждого уровня (от интерфейсов до логики элементов, отвечающих за эти реализацию этих элементов), после этого реализуют эти элементы. Те, кто видел, как работают наши разработчики, наверное, смогут подтвердить, что они (разработчики) – архитекторы и строители. В нашей отрасли такое сочетание не только возможно, но и крайне желательно!

Так что посеем, то и пожнем.
Вот и хотелось бы, чтобы «сеяли доброе, мудрое, вечное»...

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

Ответ на »сообщение 4141« (Илья Ермаков)
___________________________
Прекрасно. Человеческий организм - тоже не система? Нет "слабых связей", нельзя отделить руки-ноги, а потом присоединить обратно?
Хороший пример. Да, человеческий организм это система. Органы отделяются и пересаживаются, даже искусственные или от другого организма.

Биосфера - тоже не система, потому что нельзя отдельно взятого зайца выкинуть в космос - он там помрет?
Это неудачный пример.

Ответ на »сообщение 4143« (Jack Of Shadows)
___________________________

Последние несколько десятков постов я просто ниасилил. :))

Как? 8-о Ведь всё кристально ясно!
Зайцу не выжить без воздуха, воды и еды!
Я так сразу это понял... :о))