OberonCore

Поскольку мой вопрос касается терминологии, я решил его сунуть в ветку для начинающих. Ибо, как написание модуля начинается с определений, так и обучение часто начинают с терминологии.
Роль "начинающего" в данном случае я решил примерить на себя. Иногда это бывает исключительно полезно

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

Интересно, что думает об этом уважаемая публика. Кстати, сам бы я не задумываясь ответил, что низкоуровневые модули -- это те, которые предоставляют низкоуровневые средства. Например, модуль Math в Блэкбокс, то есть те, которые ближе к корням дага. Но червячок сомнения гложет.

Модули типа Math вообще не имеет так классифицировать...
Это - библиотеки функций.

Касательно остального - исходим из угла зрения "слои виртуальных машин" (по Пратту, например) - и сразу видим, какие абстракции над чем наслоены..

А в даге может быть и так, и так. Если учитывать динамически инсталлируемые реализации.

"Уровневость" не соотносится с положением в даге.
В самом корне дага находится главный модуль приложения, а уж высокоуровневый он или низкоуровневый - это из другой оперы. Листьями могут быть как модули реализации, так и абстрактыне модули (не импортирующие реализацию напрямую).

Правильно ли я понял, что шкалы "корень-лист" и "низкоуровневый-высокоуровневый" не связаны друг с другом? В дном конретном случае связь между ними является одной, в другом -- противоположной.

Но тогда встаёт вопрос о критериии оценки уровня того или иного модуля. Вариантов собственно два:

1. Критерий, который я указал в своём первом посте.

2. Традиционно схемы импорта (а также упорядоченные списки модулей) изображают таким образом, что модули-серверы располагаются сверху схемы (в начале списка), и в этом смысле они высокоуровневые, а модули-клиенты -- наоборот.

Вопрос в том, насколько правомочно пользоваться вторым критерием.

Кстати, даг в отличие от дерева может иметь несколько корней. Или я не прав?

Это работает в том случае, если реализация сервера импортируется клиентом напрямую. Если же вводятся абстрактные интерфейсы и фабрики, то структура импорта меняется.Клиент здесь Main, а Win32Bitmaps - не клиент, а реализация сервера. Хотя в даге выглядят равноправно. Традиционная схема такова:

Вы правы. С "официальной" точки зрения, то есть с точки зрения языка, модули Main и Win32Bitmaps совершенно равноправны. Это формальная сторона вопроса, просто импорт-экспорт и ничего личного А с точки зрения программиста, который мыслит категориями паттернов, всем трём модулям отводится совершенно разная роль, и можно говорить о том, что структура импорта меняется. (Правда компилятор об этом ничего не знает )

Но вопрос всё-таки был немного не об этом. Я хотел бы сейчас заострить внимание именно на формальной стороне вопроса. Попробую озвучить вопрос немного по другому. Тот факт, что модуль М1 (не Math ) находится сверху упорядоченного списка модулей, даёт ли нам достаточно оснований для того, чтобы утверждать, что он является модулем верхнего (или нижнего) уровня? И если такие основания есть, то какого он уровня?

Можно, кстати, отойти от модулей и говорить об иерархиях классов, объектов и даже контроллеров. У всех на слуху выражение "котроллер верхнего уровня". Но с контроллерами мне всё ясно и никаких вопрсов не возникает. Сейчас меня интересуют не классы, не объекты, а именно модули.

PS Аналогичные примеры неоднозначности терминологии можно привести и из другой "оперы". Половина авторов изображает память меньшими адресами сверху, другая половина -- снизу. Что такое тогда "верхние адреса памяти"? И даже привычный термин "вершина стека" может ввести неискушённого новичка в заблуждение.

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

Хм... Интересно.
Вот какой вывод у меня получается. Термины "верхний" и "нижний" уровень применительно к модулям являются "неправильными" в том смысле, что в зависимости от контекста они могут обозначать сущности с точностью до наоборот.
Конечно, это не означает, что на них нужно ставить крест. Но применять их (и слушать!) нужно осторожно. Иначе, мы рискуем быть не просто не понятыми, а понятыми неправильно, что ещё хуже, так как ошибка в понимании обнаружится не сразу.
Личный опыт, однако, учит меня никогда не делать окончательных выводов
Спасибо за ответы!

Поискал у себя Пратта. Нашёл только "Язык программирования C++. Лекции и упражнения". Но кажется это не та книжка. Илья, можно мне источник или ссылочку? Хочу посмотреть на досуге.

Книга: Пратт, Зелковиц "Языки программирования: разработка и реализация".

viewtopic.php?f=6&t=1090&start=0 - там сначала старое издание; в конец добавил новое.

Спасибо! Качнул. А книжица кстати на слуху оказалась. Жаль, что раньше не почитал