DRAKON.SU

Илья!

Спасибо большое, принял во внимание конференцию.

Кстати, понравилась Ваша статья на 2010. Если у Вас есть материалы в части распределенного ООП для Оберон-систем (включая коммуникационное middleware), дайте знать.

Здравствуйте, Драконограф!

Мне иногда сложно Вас понять, поэтому извиняюсь за то, что иногда отвечаю невпопад на Ваши вопросы. Был бы признателен, если бы вопросы были сориентированы на уровень "обезьяны, описанной Паронджановым": вот банан, а вот палка. Как для глупого директора.
Еще раз извиняюсь за то, что мне, как новому человеку, непонятны пока Ваши подходы на сайте Драконографика. Их сложно разглядеть, а зрение у меня не очень http://drakonografika.narod.ru/L3/part_ ... html#n3121

Темы Ваши очень интересны. Но я со многим не согласен. Например, "придётся переписать как схему алгоритма FBD-вычисления над величинами".
Я считаю, что схема алгоритма делается для ЧЕЛОВЕКА а не для МАШИНЫ.

Я еще буду описывать свои подходы.

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

P.S. Да, об императивности исполнимого описания деятельности говорилось прежде всего в ЧаВо Информатики-21 - прежде всего ответ на первый вопрос здесь.

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

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

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

В /Паронджанов, 2001, Гл.18/, в п. "Почему взорвался чернобыльский реактор?" указывается, что игнорирование когнитивной эргономичности проекта АЭС (для участников разработки) и её технической части (для персонала) существенно понизили гарантоспособность станции. В то же время главные факторы лежат в общем понимании жизненного цикла АЭС вообще и данного типа в частности участниками ЖЦ на разных его этапах.
В своё время указывалось, что физика ЭАР БМК-типа (и, разумеется, конкретной модели РБМК-1000) сложная; управляющий комплекс "Скала", автоматизировавший часть задач по текущему управлению РБМК в составе энергоблока, может эффективно и безопасно её отрабатывать только при постоянном и содержательном контроле и управлении операторами ЭБ. В частности, нужно было выдерживать жёсткие коридоры по ряду физических параметров реактора - иначе процесс становился плохо управляем.
А что происходило на станции? Это одними характеристиками её как системы "человек-машина" не объясняется; нужно привлечь оргэкхарактеристики. По литературе известно следующее. Атомную энергетику в целом в "период застоя" сделали общепромышленной подотраслью в составе Минэнерго СССР. Соответственно главными критериями её оценки стали валовые. Поисковый характер создания средств производства для неё (АЭС), не всегда достаточный уровень знаний при этом во многом игнорировались. Потому и стала возможной ситуация, приведшая к катастрофе. Указывалось, что её непосредственной причиной было введение 4-го ЭБ в экспериментальный режим, имевшее целью - без ущерба для плана выработки энергии выявить возможности поднять производительность энергоблоков данного типа. Т.е. обычное "давай-давай"; при этом научные основы эксплуатации системы РБМК-Скала (диктовавшие иной стиль) игнорировались. И директор ЧАЭС Брюханов, на которого сначала возложили абсолютно всю ответственность, по сути был исполнителем директив руководства Минэнерго и Украинской ССР - конкретно Щербицкого, которому важны были успехи энергетической отрасли "по валу"; он же (вместе с союзным руководством), ничего против не имел, чтобы "наука не вмешивалась", ибо для него это было уже производство - причём не сильно отличающееся от, скажем, общемашиностроительного .

Что же произошло? По сути - недовложение труда в эксплуатацию АЭС по сравнению с требуемым исходя из природы её технической части как по объёму, так и прежде всего по качеству. А ведущая причина этому - произвольно изменившееся на протяжении ЖЦ АЭС представление о ней. При проектировании предполагалось, что она эксплуатируется в "особом режиме", как источник повышенной опасности "со многими неизвестными" - а при эксплуатации в какой-то момент сочли, что возможен "общий режим", что "всё главное уже известно", а остальное - выявим "испытанием на прочность" - притом не опытных образцов в специально отведённых местах, а промышленных - прямо по месту применения. Цель вроде бы была благая - сократить удельные трудозатраты на выпуск продукции - вот только достигать её решили "прямо сейчас", сокращая заодно трудозатраты на сокращение трудозатрат путём совмещения разработки с эксплуатацией, что делать для такой системы было недопустимо...

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

Модели вообще (и организации искусственных систем в частности) бывают либо общие, либо частные. Среди первых ВИМ мне известны только две системно разработанных, опубликованных и апробированных:

* ЭМВОС МОС - относится к чисто технической компоненте (описание можно найти во многих источниках);
* модель безопасной системы - относится к полной оргтехсистеме (охватывая и человеческий фактор) - можно найти в выдержке из Герасименко здесь.

Каждая из них так или иначе используется в практике. При этом нельзя рассматривать каждую из них как "окончательно верную" - но чтобы построить новую, нужна научная работа квалифицированных специалистов.
Частных ВИМ, разумеется, много; к ним, как я понимаю, относится и представленная. И для них справедливо вышесказанное. Но в более жёсткой форме - поскольку модель делалась под конкретные задачи и предполагаемые условия их решения, то пересмотр требуется при любом существенном отклонении.
Конечно, наиболее тщательно нужно к этому относиться, когда предметная область является, как говорит Г.Р. Громов "кризисной", т.е. Но ведь атомная отрасль и относится к таковым...

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

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

Возможно, и инноватор М.Цукерберг какую-то научную проработку ВИМ для Facebook на корректность организовал. Если и нет, то проблемы - от того, что по концептуальным причинам ресурс будет работать не совсем "24х365" или где-то "узкое место" в пользовании обнаружится - будут не очень "кризисные". А если такое будет в СУ реактором?.. Так что это только в ограниченной "предметке" пример.

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

Итак, как нетрудно понять из вышесказанного, претензий к концепции представления знаний о сложной оргтехсистеме с применением техноязыка, представленной Дмитрием, как к "вещи в себе", нет (не в последнюю очередь потому, что во всей полноте обсуждать её научные основания неспециалисту - значит уподобляться упомянутым "манагерам" ). Но любая система существует в конкретном оргэкокружении, реальной социальной ситуации. И вот если не игнорировать этого - возникают вопросы: а правильно ли "просто добавлять уровень"; не следует ли "поэтапно и аккуратно", как говорит Илья, спроектировать заново целостную ВИМ, органически включающую новые возможности, предоставляемые шампур-методом? Не станет ли "пропатчивание когнитивным уровнем" просто оправданием очередного "давай-давай"? И без должной переработки ВИМ в целом? И не станут ли построенные по этим моделям системы менее гарантоспособными - с учётом и возможного несоответствия реальным условиям протекания ЖЦ? И возникают они из здравого смысла, указывающего, что в реальной жизни не каждый способ создания моделей сложных систем (как опять-таки сложных систем ) м.б. равно успешен...

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

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

Есть и ещё один пример на неравноценность способов создания. Как известно, отечественное атомное оружие создавалось по двум направлениям. Одно использовало материалы атомного проекта США, которые нашей разведке удавалось получать в достаточных объёмах. На другом разработка велась самостоятельно. И по современным источникам известно, что в итоге вторая разработка получилась лучше - вследствие чего после неоднократных предложений учёных стали заниматься только ею (конечно, после успешных испытаний первых образцов). Так что иногда лучше делать и "вместо", а не "вместе"...

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

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

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

Уважаемый Драконограф!

Приведу пример стиля для Обезьяны:
(это банан) Платон: «Следующее высказывание Сократа будет ложным»
(это палка) Сократ: «То, что сказал Платон, истинно»
(это вопрос) Кто из них прав?

И не нужно длиннее

Уважаемый Драконограф!

Теперь по Вашей теме.

РБМК. Скала - не управляющий комплекс. Управляет реактором СУЗ. Я 5 лет работал в НИКИЭТ(главный конструктор РБМК), из них 2 года в отделе, разрабатывавшем СУЗ, 3 года - Скалу.
Про плохую физику, паровой коэффициент реактивности и плохую конструкцию стержней у Паронджанова правильно. Я даже удивился, обычно пишут плохо. Большинство физиков не знало, наличие положительных обратных связей было для них шоком, многие не согласны с этим и по сей день.

ВИМ и многия уровни. Я упоминал, что многоуровневые системы есть. И прогресс переходит на верхние уровни.
Вы писали: Не получается ли, что перестраивается фундамент построенного здания? И не будет ли такое построение иметь вид "пропатчивания"?
Это взаимоисключающие утверждения. Или перестроить, или использовать и патчить.
ДАВАЙТЕ ПОЭТАПНО И АККУРАТНО прописывать и обсуждать концепцию: что использовать и патчить, что использовать только как концепцию, а что переделывать заново. Согласен с Вами.
Кстати, мои наброски по уровням уже разделились на части. Я еще буду внимательно смотреть все Ваши ссылки.

По поводу проверки корректности. А как же! И Цукерберг, и все остальные. Каждый уровень независимо. По аккуратному тестированию тоже как тему отметил. Буду отражать.

Вы пишете, что претензий к концепции ... нет. Я тоже в большей степени начинаю Вас понимать.
НО КОНЦЕПЦИЯ ЕЩЕ НЕ НАПИСАНА, ибо представлена рецензия и набросок.

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

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

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

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

Уважаемые коллеги!

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

Уважаемый Дмитрий Викторович!

Если вы считаете, что в предыдущей подборке цитат
я допустил неточности и невольно исказил ваш замысел,
просьба меня поправить и исправить мои погрешности.

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

1. Иерархия абстракций (которую и представляет ВИМ) строится строго на основе масштаба абстрагируемой системы, что можно проследить из п. 3.1. Аналогичный подход можно видеть у Кагана к информашинам.

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

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

У каждого "другого представления" тоже есть язык записи в проектной документации. Метаязык (называемый у меня ТФРД) получается за счёт интеграции всех этих языков в РДП-описание (вместе с данными, которые нужны уже для их представления - размещение, форматирование).

3. Естественным образом объёмное описание разносится по структуре документов проекта. Для этого и служит язык схематизации, представленный в этом сообщении. Используя жёсткие поля и области, сочинитель может задавать подразделение описания для широкого выборочного комбинирования в различных целях.

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

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

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

5. Чётко проводятся линии описания как устройства системы (в данном случае - кода), так и принципа действия (runtime-аспекта в программистских терминах). Принцип можно сочинять заранее - а практически определять путём симуляции кода - что в матинженерии соответствует измерениям на опытном/промышленном экземпляре системы. И/или по записи кода - как у Каминского - но тогда нужно представленное у него в Гл.4 общее понимание, "как должно работать". Оно является частью того самого обобщённого знания. И здесь же место изложению того, как работает объектный или любой другой подход к сопряжению элементов.

Вот это самое понимание, "как должна работать" программно строгая модель деятельности при конкретных типах её элементов и способах их соединения, Дмитрий Викторович и начал формулировать применительно к компонентному инфор-языку Оберон. Именно это сейчас важно - едва ли не более, чем проработка "иерархии абстракций" - потому что, как видно из ЕСКД-опыта, при правильном её построении она не пересекается с системой представления "собственно системы" - а просто используется на каждом уровне абстрагирования. Узел/деталь реальной матсистемы остаётся собой, при каком масштабе его ни рассматривай... так же д.б. и в инфорсистемах (где их роль играют указанные выше в п.4 типы сущностей). Как это в концепции "Алаверды" - честно говоря, не вникал (автору, наверное, будет проще посмотреть).
В итоге можно сказать, что материал Гл.4 Каминского показывает, что д.б. написано по архитектуре систем и для данной сферы. И для обучения также, как в Гл.5, это иллюстрируется на примерах программно-аппаратных (а со временем и человеко-машинных - по мере уточнения подходов к описанию взаимодействия) систем.

Уважаемый Владимир Даниелович!

Все правильно. Одна ремарка: Картинка на рисунке справа с хитростью. Ибо может как засыпать на время паузы, так и возвращать управление. Во втором случае я могу ОДНОВРЕМЕННО выполнять другие действия, например, управлять вторым комплектом автоматики. И даже легкомысленно разместить на одной схеме
[img]two_auto.png[/img]

Как это сделано в Буране? В разных потоках?

Уважаемый Драконограф!


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

Отметил, пишу, буду учитывать

Я все же рассматривал определенный класс сложных программных систем. ББ под него не подпадает.
Но если вы возьмете Человека, тому уже все уровни нужны.

Уважаемый Дмитрий Викторович!

Посмотрите здесь
viewtopic.php?f=62&t=3331

А я и не утверждал категорически, что всегда (или часто) нужно визуализировать ассемблер - см. "если вообще..." . В то же время Дмитрий_ВБ рассматривал такой случай (неэргономичной визуализации машинного кода в некоторых средах программирования) - см. его предложения в этом сообщении.

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

Уважаемые господа!

Я опубликовал первую часть концепции касательно графического пакета и языка к Оберону
http://forum.oberoncore.ru/viewtopic.php?f=62&t=3337

Дмитрий, здравствуйте.

Вы пишете (Alaverdy_Drakon.pdf с.28): "Таким образом, распределенные системы будут состоять из некоторых блоков определенных типов. И будут получать и выдавать данные. И неважно, что внутри – блочный уровень необходим. А попадая «внутрь блока», мы уже имеем дело с алгоритмом – другими данными в другом виде."

На мой взгляд всё это очень близко к концепции HiASM. Только графические примитивы выглядят иначе, чем у Вас, и терминология немного другая. Есть ещё обсуждение некоторых особенностей HiASM здесь.

Здравствуйте, Рэйлвэй Каген!

Безусловно, близость есть. Но ... То, что я изложил, принятый стандарт МЭК 61499. Официальная терминология для распределенных АСУТП. Есть коммерческие продукты, реализующие, например http://www.holobloc.com. HiAsm - исследовательский проект. Причем, они захватили чуть больше, чем АСУТП. Что вызывает вопросы. И есть ли в HiAsm распределенные системы, не вижу.

Да. Одним из общих вопросов может стать сформулированный Ильёй Ермаковым в viewtopic.php?p=32988#p32988
Что на Ваш взгляд, сделано в 61499 стандарте для преодоления той самой "ямы"?

Рэйлвэй Каген!

61499 разработан специально для распределенных АСУТП. Для которых разные функциональные блоки возможно находятся на разных компьютерах. С асинхронными способами обмена данными. Такими, как я писал про message в понимании Вирта. Данные приходят, и блоки вызываются событийно.

Спасибо.