OberonCore

Т.е. Вы подразумеваете, что аналитика выбрасывать из связки с заказчиком и программистом нельзя?

Имеется в виду непригодность UML-методологии или объектность вообще (или по Бучу в частности, если это можно отделить) И какие подходы и соответствующие языки Вы видите взамен?

Как минимум, не надо этого делать...
Я вижу непригодность Г. Буча... UML - это вообще что-то несуразное... Давайте вспомним историю... конец 80-х - начало 90-х. Никто Буча (и иже с ним) серьезно не воспринимал, ну, ездили они по конференциям в Америке и Европе, ну, размахивали руками с возгласами: "Давайте создадим единую методологию ООА и ООП!". Единой не получилось, получилась... объединенная... В одну кучу свалили все, что было под рукой, не слишком задумываясь над тем, насколько это совместимо, полезно... или просто нужно. А потом сели писать не менее несуразные книги. Я, когда Г. Буча читал, то удивлялся... то ли плакать, то ли смеяться над его перлами... То, что он пишет про системы... даже дилетантством не назовешь, откуда-то надергал каких-то мыслей и, совершенно не понимая того, о чем они... включил в книгу. Но и в ООП он разбирается примерно также... То у него дерево "состоит_из" (part_of) ствола, кроны, корней, цветов, то оно же у него "плод множественного наследования" (is_a) от тех же элементов, представленных какими-то "специальными" классами. Про методику проектирования... нет это, правда, смех сквозь слезы...

Вопрос-то был не кто, а что

Ну понятно... в общем по аналогичной схеме, что и предложения академика Сахарова о "конвергенции капитализма и социализма" (кстати, недавно уточнили, что это он предложил Хрущёву "кузькину мать" рвануть - в смысле 100-мегатонную водородную бомбу в 1961-м - а не сам персек до этого додумался)... на этом фоне невольно вспоминаешь китайцев, которые даже ракет не делали больно много, а выдавали за базы МБР другие объекты в общем нужно хорошо думать, прежде чем представления "своей" предметки переносить куда-то ещё...

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

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

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

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


Имеется в виду, наверное, принятие решений, заложенное в разрабатываемую систему, а не решений по её разработке? Анализ состояний самой системы в процессе разработки вроде продвинулся за последние годы... см. работу, выдержка из которой вложена в это сообщение. В принципе эти же результаты можно использовать для изначального моделирования состояний системы в алгообстановке.
Кстати, в той же работе показаны пути сокращения "произвольно большого числа" ("взрыва") состояний...



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


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

Очевидно, пробовали новые формы взаимодействия человека с комплексом средств автоматизации... исходя и из эргономики.

Помнится, так это называлось в политэкономии социализма

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

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

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

Да, попробовали... но чтобы попробовать, надо было сначала сделать, а, чтобы сначала сделать, еще раньше надо было "увидеть" эти новые формы в своем сознании.

Совмещать их в одном языке - не слишком разумно (язык - не догма). Каждый уровень имеет свой интерфейс. Интерфейс описывается декларативным языком. Мало того, эти описания на разных уровнях имеют одну и ту же природу, и описания разных уровней образуют формальную декомпозицию (семантики) системы. Представление декомпозиции имеет большое значение для всех: для разработчиков (постановщиков задач, аналитиков, моделистов, проектировщиков, программистов, тестировщиков), для руководства и для заказчика/покупателя.
Хорошо, вспомните...
Языки не определяются произвольно... Задача унификации здесь не совсем уместна. Хорошо, давайте попробуем рассмотреть фрагмент системы. Раз уж здесь заговорили о графическом пользовательском интерфейсе... Очевидно, что любой графический интерфейс рисуется средствами графики (линиями, дугами и пр.). Тогда имеем нижний уровень: уровень графических примитивов. Задаем интерфейс этого уровня: нарисовать, изменить цвет/размер/положение... и т.п. Создаем некоторое множество графических примитивов (точки, полотна, прямые линии, дуги и т.д). Агрегируя эти примитивы, получаем (на том же уровне - интерфейс-то пока неизменен) фигуры: окружности, эллипсы, многоугольники, буквы (шрифты) и пр.). На каком языке лучше реализовать эту простую графику?.. С моей точки зрения, наиболее удобно здесь пользоваться императивными языками (Си, Паскаль, Оберон и т.п.). Можно напрямую использовать среду OpenCL, OpenGL, DirectX и т.п. А можно сделать... декларацию для нижнего уровня и потом портировать эту декларацию (фактически она задает функциональность некоторой библиотеки, которая, в свою очередь, перенаправляет запросы на рисование к конкретной среде). Если сменится среда (появится новая, например), то надо будет портировать эту же библиотеку на новую среду (согласовать заданный интерфейс с объектами, функциями и структурами новой среды). По этому уровню вопросы есть?..
Теперь займемся следующим уровнем: уровнем элементов управления. Интерфейс этого уровня принципиально отличается от предыдущего уровня, хотя элементы рисуются с помощью графики нижнего уровня. Элементы управления отвечают за взаимодействия с пользователем. Здесь не просто появляется понятие "состояние", но оно имеет несколько "проявлений" (доступен/недоступен, выбран/не выбран, в фокусе/не фокусе и т.д.). И основной задачей элементов - является получение и простейшая обработка пользовательского ввода. Описав существо интерфейса с данным уровнем, начнем его населять. Создадим кнопки, поля ввода текста, и т.п, на их основе создадим агрегатные элементы управления: выпадающие списки, комбобоксы, редактируемые таблицы, "деревья" и пр.
Перейдем еще на один уровень выше: на уровень форм и приложений. Задача формы/приложения: позволить пользователю осуществить некое цельное действие/выполнить работу, взаимодействуя с элементами управления на форме и формами в приложении. То есть, форма/приложение, в отличие от элементов управления, ориентированы на предметную область. И отслеживая состояния элементов/форм и действия пользователя, они должны контролировать соответствие логике (небольшой части) предметной области. И т.д.

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

"увидеть в сознании" -- двусмысленная фраза.
Ограничусь этой констатацией.

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

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

Мыслили, конечно... от сотворения мира... Что касается ссылки, то это не слишком интересно. IDEF ничуть не лучше, чем UML... это все от тщетного желания понять целое (систему) через частности (бизнес-процессы или структуру). Любое предприятие гораздо легче строго(!) формализовать без применения этих средств и методов. Попробуйте, на досуге, верифицировать какой-нибудь бизнес-процесс... для примера. "Полезность" подобных описательных подходов станет вполне очевидной.
Оптимальная форма только одна, та которая передает смысл/суть. Но именно, об этом я и говорил.

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

Не могли бы Вы уточнить, как именно можно легко и строго формализовать работу предприятия? Или дать ссылки.

Насчёт IDEF с Вами согласен... именно потому, что делал на нём, и понял "полезность" - потому и интересуюсь другими подходами. Только Грабин о нём и слыхом не слыхивал (и кстати, в упомянутом сообщении о нём ни слова) - а ратовал за работу "в одной упряжке" конструктора, технолога и инструментальщика - вот эти роли там и обсуждались.
Насчёт того, что главное требование к представлению знания - целостность (а не полнота) - тоже, считаю, в точку - и современные специалисты уже высказываются в этом духе.
А вот что это за одна оптимальная форма?

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

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

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

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

Если это интересно, то можно сделать формализацию в другой теме. Не проблема.