OberonCore

Хорошо, раз это интересно, то я попытаюсь изложить формализацию в другой теме.
Полноту и непротиворечивость... никто не отменял.
Это та, которая лучше всего передает семантику.

Да, мне это очень интересно, если Вас не затруднит. Спасибо.

Это ж классика: сапожник - без сапог, у воды - и без воды...

Смотрите по фамилии "Энгельбарт" - создатель мыши. И вообще отец всего оконного интерфейса...

Присоединяюсь к просьбе. Тема очень интересная.

См. Предприятие - открытая, гибкая система

А что нужно смотреть? Что он якобы сначала "мышь" сделал, а только потом придумал?..

Не-а Я имел в виду, что сам глубоко в Буча не вникал, потому из Ваших пояснений просто понял, что он решил пойти аналогичным "конвергентным" путём - смешать ООА с ООП... надеясь, что как при физическом процессе диффузии, из них образуется однородный раствор с полезными свойствами смешиваемых компонентов

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

Всё-таки уточню - организацию уровней по Вашему предложению понимаю как обычно - в виде вертикально-иерархической модели, исходящей из понимания разработчиком смысла системы как некоей иерархии абстракций. Для примера это м.б. ЭМВОС по стандарту МОС7498 - или, допустим, такая модель:

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

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

(параллельно м.б. введены и параметры форматирования содержания экранной формы, не показанные здесь) ...и затем в нейтральном описании типизировали эти величины и подставили их в алгоритмы, совершающие нужные преобразования формы.

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

И вот, получается, целесоообразно, что внешние языки для каждого уровня могут подчиняться своим правилам, а нейтральные д.б. единой системой. И даже нейтральный язык д.б. один (для которого мы можем получить код для всех исполнителей) - а разные уровни выражаются через описания на этом языке. Тот же ПРОЛОГ или ЛИСП мы можем привлечь как внешний язык того или иного уровня - а параллельно должен существовать исходный текст на нейтральном языке, описывающий реальное выполнение ПРОЛОГ- или ЛИСП-модели.
Как внешняя схема переходит в нейтральную - об этом должен заботиться разработчик (привлекая и специалиста в "предметке"). Перевод же из нейтральной во внутреннюю - дело транслятора, т.е. для искусственной части подлежит автоматизации.
Фактически совокупность внешних описаний - это лишь формализованное техзадание/техописание на систему, реально разрабатываемую на нейтральном языке - т.е. эта совокупность одновременно служит комментарием к исходному тексту. Так я понимаю эргономически оправданный подход к делу.

Вот такие соображения.

Возможно. Плохо то, что некоторые читают эти ерунду, думая, что это и есть ООА и ООП. Я рад, что в этом вопросе мы поняли друг друга.

Да я помнил про "водопад" и остальное. Там много всего было сказано, что не укладывалось в нечто целостное. Но это Ваше сообщение многое прояснило. В частности, то, что я не участвовал в разработке больших систем, и они выпали из моего сознания.

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

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

Согласен с таким пониманием... и так же понимаю разработку "из середины".


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

Проблема именно в выборе. Как узнать, что надо выбирать (из какого списка, по каким признакам)? Очевидно, что для правильного выбора надо иметь четкие представления о над-системе. Если выбор будет неправильный, то "подмножество" будет перестраиваться, а, следовательно, и проект будет возвращаться на начальный этап.
Что считается задачей в данном случае? Есть задача реализации (интерфейсов) верхнего уровня, есть задача реализации (интерфейсов) нижнего уровня, есть задача проверки соответствия реализаций (соблюдения соответствия интерфейсам). И, наконец, есть задача построения композиций, создание предопределенных связок между верхним и нижним уровнем. В данном примере дизайнер(!) решает, какими графическими примитивами лучше рисовать кнопку, поле ввода... И он может создать решение 1 (прямые линии), решение 2 (скругленные углы), решение 3 (эллиптические формы), решение... И оформить свои композиции в виде "тем", которыми потом смогут оперировать пользователи.

Под задачей я понимал разбиение на уровни. Что нужно на самом высоком уровне? То, что нужно заказчику. Что нужно на более низком уровне? То, что понадобится на более высоком. И если так, то почему Вы описываете уровни снизу вверх, или я что-то упускаю?

То, что нужно заказчику - это одно, то что представляет собой система, может быть совсем иное. Я бы сказал так, если мы понимаем, что представляет собой система, то мы (почти... автоматически) знаем, как она делится на уровни. Зная уровни, то есть, понимая их суть, мы понимаем и задачи, которые они решают, и их направление развития и структуры (сущностный состав). При этом становится не слишком значимо, откуда и куда идет повествование: снизу-вверх, или сверху-вниз, или с середины в разные стороны.
В теме "предприятия" я начал с самого предприятия, но вполне можно было бы начать с макро-уровня, показать что представляет собой предприятие "с этой колокольни", а потом спуститься к предприятию. Можно было начать с подсистем (подразделений) и оттуда подняться к предприятию. Собственно, так мы и делаем, в зависимости от аудитории, выбираем наиболее понятную для нее "точку отсчета".

Ясно, спасибо.