Всё-таки уточню - организацию уровней по Вашему предложению понимаю как обычно - в виде вертикально-иерархической модели, исходящей из понимания разработчиком смысла системы как некоей иерархии абстракций. Для примера это м.б. ЭМВОС по стандарту МОС7498 - или, допустим, такая модель:
Вложение:
Комментарий к файлу: ВИМ условной управляющей программы.
СоврКомп_Деннинг,Браун-ОС-извл(Иерархия абстракций).djvu [17.48 КБ]
Скачиваний: 352
Далее должен уточнить себя - некорректно наложил "три схемы"
в этом сообщении. Деление "внешняя-нейтральная-внутренняя" д.б. самостоятельным измерением базиса - если уровни "по вертикали", то схемы "по горизонтали". Соответственно вся иерархия имеет три представления. Что же можно о каждом сказать в языковом аспекте? Во-первых, следуя когнитивной эргономике, стоит ввести ещё одно измерение - по формам представления (символическое, или "человекочитаемое", и предметное, или "машиночитаемое"). Если мы разрабатываем полностью автоматизированно (поддержка начиная от выражения задумки архитектуры) - то каждая схема сверху донизу имеет оба представления (упрощённо - натуральный документ и файловый). Во-вторых, у нас есть обобщённое знание о системе и частное - которое в свою очередь делится на декларативное (об объектах), императивное (о процессах) и активностное (об исполнителе - субъекте).
Внутренняя схема детерминирована репертуаром исполнителя - для естественного (человека) его квалификацией, для искусственного (информашины) её системой команд. Соответственно внутренним искусственным языком будет либо машинный (предметно - коды, символически - Ассемблер, можно визуальный), либо платформенный (когда на машину, как Вы и указываете, поставлена некая программная среда исполнения, предоставляющая входной язык, отличный от машинного).
Внешняя схема детерминирована взглядом разработчика на формы представления архитектуры - в когнитивной эргономике учитывающим также возможности пользователя воспринять нужные ему элементы содержания в этих формах. Тут справедливы Ваши рассуждения - я бы только добавил, что язык описания каждого уровня д.б. визуальным. В то же время не забудем, что внешняя схема непосредственно не переходит во внутреннюю - поэтому см. далее.
Нейтральная схема определяет содержание внешней настолько формально, чтобы можно было это определение алгоритмически перевести на внутрений язык исполнителя (единичного/коллективного, естественного/машинного/смешанного). Понятно, что здесь опять есть и императивная, и декларативная составляющая - исполнительская также присутствует через учёт особенностей реализации. Практически язык нейтральных схем - это алго/прогязык высокого уровня, задающий исходные тексты (визуальный ЯВУ - чертежи) процессов и объектов в расчёте на исполнителя, для которого возможен перевод. Ну, человеку-исполнителю перевод осуществлять в своём сознании (для чего ЯВУ д.б. эргономичен) - для машины же производится трансляция в коды. Объекты здесь представлены через абстрактные типы данных - а чтобы понимать смысл объектов, привлекается внешнее символическое представление - скажем, мы прорисовали экранную форму с указанием отображения на неё некоей совокупности величин из содержания предметной области, например, так... :
Вложение:
Комментарий к файлу: "Лицо Чернова" как модель внешнего символического представления совокупности параметров предметной области.
Информатика - Графика - ЛицоЧернова(Ч2).jpg [ 52.54 КБ | Просмотров: 8800 ]
(параллельно м.б. введены и параметры форматирования содержания экранной формы, не показанные здесь) ...и затем в нейтральном описании типизировали эти величины и подставили их в алгоритмы, совершающие нужные преобразования формы.
Конечно, "лицо Чернова" (как форма многопараметрического индикатора) - пример частный - какие-то формы будут управленческими документами, какие-то - визуализациями физических обстановок и т.д.
И вот, получается, целесоообразно, что внешние языки для каждого уровня могут подчиняться своим правилам, а нейтральные д.б. единой системой. И даже нейтральный язык д.б. один (для которого мы можем получить код для всех исполнителей) - а разные уровни выражаются через описания на этом языке. Тот же ПРОЛОГ или ЛИСП мы можем привлечь как внешний язык того или иного уровня - а параллельно должен существовать исходный текст на нейтральном языке, описывающий реальное выполнение ПРОЛОГ- или ЛИСП-модели.
Как внешняя схема переходит в нейтральную - об этом должен заботиться разработчик (привлекая и специалиста в "предметке"). Перевод же из нейтральной во внутреннюю - дело транслятора, т.е. для искусственной части подлежит автоматизации.
Фактически совокупность внешних описаний - это лишь формализованное техзадание/техописание на систему, реально разрабатываемую на нейтральном языке - т.е. эта совокупность одновременно служит комментарием к исходному тексту. Так я понимаю эргономически оправданный подход к делу.
Вот такие соображения.