OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Четверг, 17 Октябрь, 2019 08:14

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 135 ]  На страницу Пред.  1 ... 3, 4, 5, 6, 7  След.
Автор Сообщение
 Заголовок сообщения: Re: Задача на перспективу
СообщениеДобавлено: Пятница, 21 Сентябрь, 2012 06:46 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
PSV100 в viewtopic.php?p=74882#p74882 писал(а):
...
В принципе, в eEPC логика та же: на верхнем уровне - цепочки процессов а-ля сетевые графики, которые могут "расшифровываться" более детальными цепочками с алгоуказаниями, плюс всякие структурные диаграммы. Есть и некие "расширенные цепочки", как на верхнем уровне:

Вложение:
01_29.gif


так и пониже:

Вложение:
01_31.gif


Что-то полезное в этих "прикрученных" иконах есть, тот же "документопоток". М.б. и какие-то "координации" прикручивать ?
Кстати, есть и какая-то "фича": модель вариантов бизнес-процесса, можно глянуть в файлике про "Соглашение по моделированию", с. 98, вот картинка оттуда:

Вложение:
eEPC_PSD.PNG


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

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

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

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

Теперь замечания по содержанию обсуждения.
Прежде всего - не забудем разницу между формализацией и жизнью. :wink:
    Всё, что мы можем записать в любой нотации - есть "отслаивание" части результатов мышления в смысле Леонтьева - т.е. "отчуждение" части "смешанного смысла" по Фридланду. Усов справедливо указывал, что этот процесс дискретен - и отчуждение всегда отстаёт. Реальный исполнитель, возможно уже нашёл новый вариант того же коорд-процесса для своего типа РМ, а в модели (даже и системной) пока формализован прежний...
Именно в этом смысле говорилось, что каждый субъект деятельности есть полноправный владелец своих процессов - техоперационных и координационнного. На основании внешнего [полу]формального смысла, [квази]статически заданного в описании, у него возникает неформальный. Заданная же цель в процессе её достижения порождает также смешанный смысл по поводу этой цели и текущих результатов. Оба эти смысла динамичны. Так ообеспечивается адаптация к меняющейся обстановке.
По взаимодействию совместно протекающих процессов - Р.К. верно указал на отложенность. Анекдот про сына лорда иллюстрирует то же самое - только как частный случай общего. :) Можно взяться за вновь пооступивший предмет труда сразу - на данном П/ТРМ за него и берутся. И только если нет - начинают решать, как лучше откладывать. :wink: Решает конкретное РМ - по определению действующего коорд-процесса. Формально считается, что статичного - реально динамичного как продукта достижения цели "пригодно/оптимально/адаптивно распределить силы и средства между целями, которые заданы входящими предметами".
    Короче. Всё, что мы тут или ещё где запишем - будет принципиально неполно/неточно. И надо не "суперить" - а осознавать это. И делать формализацию, действительно, "простой как пробка" в основе. Хотя и допускающей извлечение из неё данных (НЕ знаний!) для анализа порой и довольно сложного.
Результаты анализа могут приводить субъекта-аналитика к знаниям. Которые он может частично "отслаивать" как данные. А другие могут использовать.

Отсюда и некоторые замечания по типам схем и нотациям.
Выше снова подтверждается, что для самой системной модели деятельности (т.е. импер-составляющей модели предприятия) достаточны доалгоритмические модели техпроцессов и модели "алгорасшифровки" их элементов и связей. Имеем два подхода к структуризации доалгомодели - элементы-работы или связи-работы. Семантика разная, надо думать.
"Плюс всякие", как правило, нужно не сочинять, а получать как производные схемные (табличные, текстовые) отчёты. Ибо всё, что идёт от "БПР-описания" - это "проекции слона" - т.е. системной модели. Да ещё и как реализации при конкретных начальных/граничных условиях моделирования. Что обсуждалось в связи с Промелой выше - ну и чуть позже здесь: viewtopic.php?p=74853#p74853.
    В частности, схемы с "перекрёстками" можно рассматривать как детализацию сетевых графиков. Где предварительно определяются условия "алгорасшифровки". Как уже говорилось, можно сократить число типов "перекрёстков" даже не до двух, а до одного - И/ИЛИ ("выбрать от [ни]одного до всех").
    В реализации же выбираем всегда один. Поэтому "бизнес-процесс" вовсе не требует таких сложных конструкций, какие обсуждались выше. Достаточно переключателей - между "другой работой" и техоперацией данного техпроцесса на данном РМ.
Отсюда - проектируя среду поддержки, мы закладываем редактирование в ней ограниченнного набора моделей. Надо исходить из того, что пользователь будет делать в общем то же, что в КУБе. А по некотоорым вспомогательным представлениям сверяться. Отобранным из множества модных сейчас или когда-то нотаций так, чтобы помогать ему либо в собственно полезной работе по "отслаиванию" - либо во взаимоотношениях с любителями "миссий предприятия", "бизнес-процессного подхода" и пр. И не тратить время на оформление в таких нотациях - а получать их как результат автогенерации в среде.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Задача на перспективу
СообщениеДобавлено: Понедельник, 24 Сентябрь, 2012 20:19 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 371
Владислав Жаринов писал(а):
...
Ну и наконец как достичь интеллектуального взаимопонимания. :) ...

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

Вложение:
R_vs_UML.PNG
R_vs_UML.PNG [ 121.16 КБ | Просмотров: 7164 ]


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

Или схема чуть "пониже":

Вложение:
r_bar_gost.PNG
r_bar_gost.PNG [ 213.98 КБ | Просмотров: 7164 ]


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

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

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

alexus писал(а):
...
Никого же не удивляет, что в машиностроении, например, есть инженеры-конструкторы, которые придумывают новое изделие, отвечая на вопрос: "Что нужно делать?"; и есть инженеры-технологи, придумывающие новые методы изготовления, отвечая на вопрос: "Как нужно делать?". Наконец, есть исполнители, которые, выполняя инструкции технологов, делают то, что придумали конструкторы.
В программировании инженерные подходы плохо приживаются... исполнитель здесь является и конструктором, и технологом... ООП ему, "как собаке пятая нога".

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Задача на перспективу
СообщениеДобавлено: Вторник, 25 Сентябрь, 2012 06:55 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Табуретка приводилась как пример системы 1-го уровня развития - с неподвижными связями. Разумеется, возможен любой другой подходящий объект - и я указал документ (заполняемый однозначно по всем трафаретным полям, если таковые есть) как пример... :)

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

Насчёт языка для "бизнес-процессов" (как систем с жёсткими опять же связями) - постарался раскрыть здесь: viewtopic.php?p=75011#p75011. Там видно, что в общем всё, что Вы тут говорите, верно - только к понятиям еЕРС требуется поправка - нет "вариантов использования бизнес-процесса", а сам бизнес-процесс и есть "вариант использования" системной модели. Т.е. меняя цель на множестве возможных на данном КУБ-описании - получаем "бизнес-процесс" достижения этой цели. С точностью до динамики исполнения артефактных субпроцессов. Если есть детерминация/статистика выбора - то можем точность повысить. Нету - значит, модель в классе неопределённостных (как это у Одинцова понимается, например).

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

По объектности - Усов как раз говорил о разделении ООА и ООП. И что объектный анализ сам по себе возможен - и с программной реализацией никак не связан (её может вообще не быть). Отсюда то, что Вы привели в этом посте как "таблицу вариантов БП", как мне думается, можно понимать скорее как попытку определить объектную динамику системы чем-то вроде N-мерной VMT...
Ну и сказанное о том, что другие парадигмы формализации м.б. уместнее в конкретных случаях, разделяю - потому и примерный процесс с разными возможностями описал здесь: viewtopic.php?p=74873#p74873. :)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Задача на перспективу
СообщениеДобавлено: Вторник, 25 Сентябрь, 2012 20:49 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 371
Владислав Жаринов писал(а):
Насчёт языка для "бизнес-процессов" (как систем с жёсткими опять же связями) - постарался раскрыть здесь: viewtopic.php?p=75011#p75011.

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

Владислав Жаринов писал(а):
...к понятиям еЕРС требуется поправка - нет "вариантов использования бизнес-процесса", а сам бизнес-процесс и есть "вариант использования" системной модели. Т.е. меняя цель на множестве возможных на данном КУБ-описании - получаем "бизнес-процесс" достижения этой цели. С точностью до динамики исполнения артефактных субпроцессов. Если есть детерминация/статистика выбора - то можем точность повысить. Нету - значит, модель в классе неопределённостных (как это у Одинцова понимается, например).
...

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

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


Мне кажется (да и N-мерная VMT подсказывает), что Вы в поисках языка для описания системы...

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

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

- робот Адам, совершивший научное открытие - "Машинное понимание результата — главное достижение этого проекта. «Адам» же принимает от людей общую задачу (изучение работы генов в определённом организме, например), составляет план опытов, выстраивает гипотезы, проверяет их в деле, отбрасывает и выстраивает новые.";

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

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

Кстати, насчёт DSL. Как-то вспомнился проект SymADEблоге автора чуть больше инфы по сути) - это в дополнение к размышлениям насчёт семантических редакторов, в проекте пытаются сделать упор на мета-программировании (как-то мало информации о подобных проектах, в отличие от MPS и Xtext).


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Задача на перспективу
СообщениеДобавлено: Среда, 26 Сентябрь, 2012 03:13 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8185
Откуда: Троицк, Москва
PSV100 писал(а):
- роботы, которые сами придумали себе язык для общения - "Когда два аппарата встречались в одном месте, первый из них, уже открывший этот участок, произносил его название вслух, а второй — понимал, что ему хотят сказать. При этом "понимать, что говорится", восприниающий робот не мог, потому что изначально не было единого языка, на котором роботы могли общаться. Он мог лишь "понимать, что имеется в виду";

- робот Адам, совершивший научное открытие - "Машинное понимание результата — главное достижение этого проекта. «Адам» же принимает от людей общую задачу (изучение работы генов в определённом организме, например), составляет план опытов, выстраивает гипотезы, проверяет их в деле, отбрасывает и выстраивает новые.";

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

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

С третьей стороны, человеческий интеллект тоже мифологизирован и заведомо переоценен.

С учетом всех этих caveat emptor -- любопытно.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Задача на перспективу
СообщениеДобавлено: Среда, 26 Сентябрь, 2012 11:21 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
PSV100 писал(а):
...
Интересное упорядочивание, нужно подумать. Если выделять транспортные процессы через силуэт (а также при необходимости их уточнять в отдельных ветках), то в самих ветках, как техоперациях или опер-ТП, получается, что мы отражаем некую цельную техоперацию или скрываем транспортные передачи между "действиями" процесса. Как бы так не пришлось бы сильно "растягивать" силуэт...
...
Именно! :) Вот потому-то следующий шаг - это отделить "представление неявного" от "полного описания" по принципам ЕСКД.
Т.е. в "бизнес-укладке" показываем тела веток как единичные вершины. Разумно, чтобы это были Вставки - тогда каждая будет ссылочно связана (в модели) со схемой своей техоперации. В общем, имеем набор системных схем - принципиальных в смысле ЕСКД - и их "схему подключений по рандеву".
И типов таких схем нужно несколько - уже говорил.

PSV100 писал(а):
...
Всё-таки, нужно уточнить. Имхо, "бизнес-процесс" м.б. "кусочком" (элементом) системной модели. Те же сетевые графики можно заменить алгоритмическими схемами (как бы раскрывая сеть работ), в них будет заложено алгоповедение системы в зависимости от состояний и взаимосвязей, некий шаблон, в т.ч. будет отражена и привязка к ПМ. Тогда меняя цели в КУБ-описании мы можем получать картинки как здесь, т.е. именно вариант раскрытого алгоритма в зависимости от входных данных, фактически, имитационное моделирование.
...
Всё верно... только то, о чём Вы говорите, есть построение системной модели... а я о том, что получится из данных "бизнес-интервью" с исполнителями на тему: "и как это Вы ухитряетесь работать на своём месте?"... :wink: Улавливаете разницу?..
Из интервью получится "вьюшка" реальной системы техпроцессов. Именно как "имитация" прогона реальной. И значения в формализации у неё по-честному будет не больше, чем у только что описанной "схемы подключений"... :wink:
Но и не меньше - вменяемым участникам ЖЦ оргсистемы такая вьюшка покажет достижение конкретных целевых параметров на охватываемых ПМ. Только вот для вменяемости надо именно "прогонять" системную модель, как в КУБе и сделано... а не интервью брать... :| Его в данном случае "берёт сам у себя" технолог, который разработал охваченные ТП... а если опыта нехватает, то обращается к более опытным технологам, учёным по этому делу... и/или к литературе... Что было описано в этом посте. А исполнитель, если есть наработки по совершенствованию продукта/технологии, сам идёт к технологу... что тоже было описано... :)
А так только одна поправка - "заменяется" как раз при построении "бизнес-вьюшки". В системной модели просто раскрывается...

PSV100 писал(а):
...
Мне кажется (да и N-мерная VMT подсказывает), что Вы в поисках языка для описания системы...

Имхо, тут одним форумом не отделаешься. Что-то конкретное пока вряд ли скажу. Имхо, всё-таки, функциональные языки как-то лучше адаптированы для системного моделирования.
...
Ну, в общем это обсуждалось и здесь - но у Усова есть статьи по ВОТ ТАК - ссылка теперь здесь: viewtopic.php?p=73673#p73673 (и на обсуждения тоже).
Тут штука в том, что языков нужно много, и д.б. правила их употребления. Прежде всего - в зависимости от сложности системы, её "уровня развитости" по Усову.
Вот ещё Анимотрон есть... и здесь обсуждался...
Ну и какой язык используется прежде всего - можно теперь видеть в обещанной книге: viewtopic.php?p=75074#p75074. В основе - тот самый, о котором Фёдор Васильевич говорил как о "беспрецедентно масштабируемом, гибком и пр."...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Задача на перспективу
СообщениеДобавлено: Среда, 26 Сентябрь, 2012 11:40 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
И ещё уточнения.

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

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

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

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

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

Можно алгоритмизовать и иначе - возвращая результат техоперации из ТО-алгопроцесса, понимаемого как функция - в контекст, доступный для коорд-алгопроцесса. Тогда можем формализовать взаимодействия в системе процессов как вызовы/возвраты функций - т.е. уже другой стиль, о котором Вы говорили.

Ну и главное - перспективная цель состоит всё-таки не в новом языке "описания всего". А в формировании подхода к среде поддержки организованной деятельности людей как к инструментальной, позволяющей им самим строить модели решения своих задач. А среда при этом то, что алгоритмически разрешимо - автоматизирует сама (возможно, с некоторыми ограничениями, при вариациях постановки задачи). На примере Усов объяснял здесь: http://www.alexus.ru/russian/articles/d ... page07.htm - а обоснование, например, тут: http://www.alexus.ru/russian/articles/d ... page05.htm (обратите внимание на роль моделирования). Ну и Фридланд говорил:
На практике, в связи с невозможностью полностью формальных постановок задач, всегда есть возможность так варьировать начальные условия, так менять постановку задачи, что алгоритм всегда находится, но вопрос об адекватности этих моделей, доведённых до численного решения, реальным проблемам всегда зависит от уровня компетенции разработчика и заказчика, так называемых конечных пользователей.
- и то же примерно можно видеть у Усова здесь: http://www.alexus.ru/russian/articles/d ... page13.htm - в более общем виде.

Это снова к вопросу, какие нужны языки - пользователям среды максимально приближенные к их роли в ЖЦ оргсистемы - общей (предметник, аналитик, разработчик) и конкретной (по сути требуемых от него результатов).

Для системной модели также возможны разные случаи. Выше предполагался случай подвижности предмета труда между неподвижными РМ.
Усов указывал, что его подход применим также к случаю неподвижного предмета труда ("стапельное" производство).
Кроме этого, однако, есть случаи:

    * подвижных РМ (действия на местности) - в частности, с динамически определяемым предметом труда (спорт, игры, военные действия, изыскания).

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

С учётом этого и подход к построению модели (и к языковому базису формализации) м.б. уточнён.


Последний раз редактировалось Владислав Жаринов Четверг, 27 Сентябрь, 2012 12:49, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Задача на перспективу
СообщениеДобавлено: Четверг, 27 Сентябрь, 2012 09:32 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Кое-что дополнил в предыдущем посте - и также по поводу этого:
PSV100 в viewtopic.php?p=75065#p75065 писал(а):
...
Те же сетевые графики можно заменить алгоритмическими схемами (как бы раскрывая сеть работ), в них будет заложено алгоповедение системы в зависимости от состояний и взаимосвязей, некий шаблон, в т.ч. будет отражена и привязка к ПМ. Тогда меняя цели в КУБ-описании мы можем получать картинки как здесь, т.е. именно вариант раскрытого алгоритма в зависимости от входных данных, фактически, имитационное моделирование. Обратные вычисления Одинцова помогут при случае угадать вариант входных данных для достижения нужной цели. В принципе, это и есть варианты "бизнес-процессов". Они могут гармонично дополнить (в рамках целостности среды для проектирования) варианты самих исходных алгосхем (т.е. как ветки кода в системах контроля версий).
...
- для начала расскажу реальную историю, связанную с этой же задачей.

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

Какие выводы здесь на предмет темы?

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

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

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

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

А язык представления расчётных схем в граф-нотации - это хорошо известные функциональные схемы... по которым, кстати, нетрудно построить и те самые динамические ("электронные") таблицы... вот только формировать их оправданно тоже внутри среды (пусть и для внешнего динатаб-процессора, если следовать концепции интегрирующей среды, представленной здесь: viewtopic.php?p=75096#p75096).

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Задача на перспективу
СообщениеДобавлено: Четверг, 27 Сентябрь, 2012 19:44 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 371
Владислав Жаринов писал(а):
...
Всё верно... только то, о чём Вы говорите, есть построение системной модели... а я о том, что получится из данных "бизнес-интервью" с исполнителями на тему: "и как это Вы ухитряетесь работать на своём месте?"... :wink: Улавливаете разницу?..
Из интервью получится "вьюшка" реальной системы техпроцессов. Именно как "имитация" прогона реальной. И значения в формализации у неё по-честному будет не больше, чем у только что описанной "схемы подключений"... :wink:
...


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

http://forum.oberoncore.ru/viewtopic.php?f=86&t=2930&start=20#p53014 писал(а):
Peter Almazov писал(а):
Любопытно. По идее, правильность описания должен определять заказчик. Но, подозреваю, что описания были столь сложными (хотя бы по количеству разнообразных элементов), что заказчик мало что понимал. Интересно было бы узнать подробности.

Чтобы проверить правильность описания, в голове заказчика уже должна существовать правильная модель (представления), но именно за получение такой модели... он и платит деньги.
Вообще, это давняя история... В начале 00-х годов приезжал к нам Ляпидус (они свой филиал открывали Приоритет-Урал), ну, и проводил он встречу... Я тогда его спросил об этом... на примере. Есть мол директор предприятия, которое "поймало волну" и быстро развивается. Пока коллектив был маленький, вроде бы все было под контролем. Но коллектив рос... Решили поучится тому, как правильно управлять, пригласили консультантов. Те пришли, начали описывать бизнес-процессы. Оставили пухлые тома, рассказали, как все делать правильно, научили всех натягивать улыбки и заставили зазубрить слоганы... Прошло какое-то время, решили сертифицироваться по ISO:900х (так солиднее на рынке представляться). Приехали консультанты, взялись снова описывать бизнес-процессы. "Эй", - закричал директор: "Постойте! Вот тут до вас уже поработали, все описали!!!", - и он натянул дежурную улыбку. Консультанты хмуро полистали пухлые тома и вынесли резюме: "Это не по стандарту. Надо все переделать". И... переделали. И на самом деле, бизнес-процессы стали другими. Сотрудники покорно выучили новые слоганы и тексты, которые надо говорить проверяющим СМК.
Прошло время... Решили поставить автоматизированную систему. Приехали консультанты... начали описывать бизнес-процессы... поскольку их бизнес-процессы "заточены" под ту систему, которую они продают... Сотрудники привычно положили в карман буклеты, которые им предстоит выучить...
Знаете, что мне сказал по этому поводу Ляпидус?.. Дословно, конечно, не помню, но суть такая: "Это правильно, что каждый рисует свой взгляд на бизнес-процессы, поскольку у них цели разные". У консультантов, может быть цели и разные, а вот у руководства предприятия?.. Но до их проблем никому похоже нет дела...

PS. Если Вы думаете, что эта история уникальна... то отнюдь... каждое предприятие, которое проходило через эти стадии... все это пережило.


К тому же могут и свои инициаторы устраивать глобальное описательство. Так, действительно, часто и происходит, но толку от этого мало, хотя иногда хоть какие-нибудь бумажки могут помочь для стартовых разборок. И я говорил именно о процессе извлечения знаний для построения моделей. Это тоже, фактически, постоянное явление. Ведь, к примеру, в том же планировании есть отработанные методики и алгоритмы, но у каждого предприятия свои особенности и хотелки, рассказать о которых могут только их местные жители. Или конкретный пример. Сейчас меня в срочном порядке подключают к новому проекту: автоматизация задач насчёт медицинского обслуживания сотрудников. Крупное предприятие (Азовсталь) выполняет социальное обеспечение своих работников (это немалая часть всего города), включая и медобслуживание (организует свои медучреждения/кабинеты, банк крови, оплачивает лечение в др. лечебницах и т.д.). Вот передо мной лежит пачка каких-то ведомостей, куча образцов документов, и есть какая-то непонятная программка, которая не пойми что считает, какую-то среднюю температуру по больнице - это и вся "постановка" задачи. Для меня это "тёмный лес", за какую хвататься литературу и к какому учёному обращаться - ума не приложу. Вот сижу и рисую Р-схемы для себя, причём не алгоритмы, а какие-то "Р-mind-map" (всё-таки, не хватает бумаги, на которой бы всё само выравнивалось, да с удобным рефакторингом :) ). Скоро ехать в командировку и общаться с исполнителями, местными "технологами" и "конструкторами", но я хотя бы буду вопросы задавать с нужной "системной" позиции, «правильно заданный вопрос — половина ответа». А был бы на своем месте какой-нибудь РТК, где хранились бы все нужные документы с чертежами - вот бы...
Короче говоря, одно другое дополняет, что подтверждает и вики:
Цитата:
Системный подход — направление методологии исследования, в основе которого лежит рассмотрение объекта как целостного множества элементов в совокупности отношений и связей между ними, то есть рассмотрение объекта как системы.

Говоря о системном подходе, можно говорить о некотором способе организации наших действий, таком, который охватывает любой род деятельности, выявляя закономерности и взаимосвязи с целью их более эффективного использования. При этом системный подход является не столько методом решения задач, сколько методом постановки задач. Как говорится, «Правильно заданный вопрос — половина ответа». Это качественно более высокий, нежели просто предметный, способ познания.


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

Добавлю: на практике не все процессы формализуются, особенно заранее. Что-то подразумевается "по умолчанию", а всё формализовать вряд ли возможно.

Теперь по языкам. Точнее, сначала по среде поддержки:
Владислав Жаринов писал(а):
Ну и главное - перспективная цель состоит всё-таки не в новом языке "описания всего". А в формировании подхода к среде поддержки организованной деятельности людей как к инструментальной, позволяющей им самим строить модели решения своих задач. А среда при этом то, что алгоритмически разрешимо - автоматизирует сама (возможно, с некоторыми ограничениями, при вариациях постановки задачи). На примере Усов объяснял здесь: http://www.alexus.ru/russian/articles/d ... page07.htm - а обоснование, например, тут: http://www.alexus.ru/russian/articles/d ... page05.htm (обратите внимание на роль моделирования).


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


Отдельное спасибо за Анимотрон. Сама его модель вычислений очень специфична, не могу сказать, что для широкого применения, да и конкретная реализация тоже специализированная. Но для себя я нашёл ценным их подход в организации данных, пролого-подобный, с псевдо топологиями "have, is" и т.д. Это альтернативный взгляд на то, как можно подойти ко всяким NoSQL. Как раз эта конкретная реализация основана на Neo4j, сейчас набирает обороты их конкурент Orient-DB, а точнее, пока не набирает, а подаёт надежды (СУБД, действительно, интересная, но с надёжностью и глючностью дела плохи). В принципе, такой подход и для любого "Key-Value" имеет смысл.


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

Цитата:
Что имеем в настоящий момент, при создании информационных систем?

* М + ЯП + SQL + RDB
* М + ЯП + ΝοSQL + ΝοSQL DB
* М + ЯП + XQuery + XSLT + XML + XML-DB
* М + ЯП + SparQL + OWL/RDF + Tripplet Store
* и различные вариации ...

Где М — модель, ЯП — язык программирования логики (Oberon/Pascal/Java/Python/C++/C#....)

Фактически, это похоже на ВОТ ТАК, где ЯП -> ООП. Такую модель пытаются "усилить" ребята с РСДН в проекте Nemerle, который помогает создавать и поддерживать свои сторонние DSL и прочие 4GL.

По опыту. Раньше тоже стремился к DSL-строению, наколенные 4GL активно применяются и сейчас (и ещё долго проекты будут жить). Но постепенно пришло понимание того, что при реализации сложного без простоты не выжить. От зоопарка языков и инструментов под них, откровенно говоря, уже тошнит. На сегодня крайне перспективным вижу функциональный подход, который может дать основу для единого языка (для основной сферы разработки). Ключевая проблема ООП - это сильная связность между элементами, к примеру, иерархия наследования, особенно множественного, крайне проблематичная штука. Для проектирования и разработки, особенно сложного и объемного, нужны отдельные кирпичики, простые как ... Те же Р-схемы, как видим, "поструктурнее" многих паскале-/С-подобных языков. Функциональные языки дают такую "кирпичность", уменьшают зависимости, в то же время дают удобные способы для построения структур, интерфейсов и прочего "ООА", к тому же решают задачи повторного использования кода попроще, чем в ООП, причём могут это реализовать без всяких VMT и виртуальных вызовов. В том же Анимотроне реализовали один базовый язык для замены зоопарка, лиспо-подобный. Отличие функциональных от лиспа - это более удобный синтаксис, а точнее, его наличие :).
В то же время, семантика функциональных соответствует как самому низкому уровню (функции и данные), так и может удовлетворить потребности и "повыше". Вот пример "SQL" отсюда (майкрософт обкатывала свой LINQ на Хаскеле):
Код:
SELECT dept, SUM(salary)
FROM employees
GROUP BY dept
ORDER BY SUM(salary) DESCENDING
LIMIT 5


[ (the dept, sum salary)
| (name, dept, salary) <- employees
, group by dept
, order by Down (sum salary)
, order using take 5 ]


Или примерчик на Ela как декларативные указания:
Код:
test1 =
  test "Integer equality"
  given 2
    should be 2
    shouldn't be 33


Иными словами, это "встроенный" DSL или 4Gl. Те же пролог-декларации выглядят естественно (собственно, Erlang - тот же Пролог, без двустороннего сопоставления да с императивщиной). Конечно, абсолютно всех потребностей такие "встройки" не удовлетворят, но можно найти удобные способы интеграции с "инородными" языками, включая вычисления и на этапе компиляции или интерпретации (скажем, даже можно задать тип для структур на основе таблицы или SQL-запроса к БД, и пр.). Есть и проблемы, к примеру, в том же Хаскеле хоть и нет явного наследования, но есть косвенная зависимость в классах типов, и в целом, его система типов подразумевает борьбу с собой, не же ли проектирование. Варианты упрощения приводил ранее, "протоколы" в Кложуре и Ela. Также есть потенциал и для "немудрённого" синтаксиса самого языка.

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

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

Спасибо за очередную порцию "матчасти".


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Задача на перспективу
СообщениеДобавлено: Пятница, 28 Сентябрь, 2012 14:11 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Вот ещё порция :) - поработал с материалами задачи и сделал всё-таки извлечения, касающиеся расчёта и оформления бюджета:
Вложение:
Вложение:
Рисунки А3L ГЧ1 Разд.II Прил.10 Информатика (Бланк 2хА4S).png
Рисунки А3L ГЧ1 Разд.II Прил.10 Информатика (Бланк 2хА4S).png [ 194.6 КБ | Просмотров: 6958 ]
- это как дополнение к представленному в этом посте.

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

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

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

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

По отражению особенностей. Как можно понять, системный подход предлагает построить систему деятельности для нормативных условий (т.е. по стандартам на ПМ, ТП, предметы труда). Что видно отсюда:
...
Влад Жаринов в http://oberspace.dyndns.org/index.php/t ... ml#msg7888 писал(а):
...
...
Есть значительное количество стандартов под названием ЕСТПП (единая система технологической подготовки производства), ЕСТП (единая система технологической документации) и пр., которые является частичной проекцией международных стандартов ISO.

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

Тогда как сохраняется главное - инвариантная модель организации как системы.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Задача на перспективу
СообщениеДобавлено: Понедельник, 01 Октябрь, 2012 20:52 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 371
Владислав Жаринов писал(а):
В первую очередь можно отметить, что показанная схема, видимо, и есть та форма, которую предлагал Усов для представления вычислений здесь. Только предлагается её строить справа налево - в отличие от организации здесь сверху вниз.

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

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


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

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

На всякий случай подкину смежные материалы:

- книга Хамби Э. "Программирование таблиц решений";
- здесь ещё один современный взгляд на таблицы решений;
- здесь современная критика Форта;

Современные языки, вдохновленные Фортом:
- Factor (кстати, разработка толкового парня, автора JEdit)
- Cat
- Joy

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Задача на перспективу
СообщениеДобавлено: Понедельник, 01 Октябрь, 2012 21:02 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9147
Откуда: Россия, Орёл
PSV100 писал(а):
Собственно, ничего необычного незаметно. В любом случае, ООП - ущербная технология. Далеко не всегда требуется отношения между элементами именно как иерархия, часто эта иерархия искусственная, надуманная, к тому же, как правило, всегда есть неоднозначность как эту иерархию правильно организовать. Например, пусть реализовали в проекте классы "Геометрическая фигура" -> "Прямоугольник". После некоторых итераций разработки (итерационный способ - фактически, естественный) появляются "Квадраты". Первая мысль - сделать их наследниками от "прямоугольника", как их частного случая, тем более это не требует переделки имеющейся иерархии


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

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

См. viewtopic.php?f=8&t=3925
http://www.oberoncore.ru/library/component_soft
http://store.oberoncore.ru/lib/article/DesignIdeas.pdf


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Задача на перспективу
СообщениеДобавлено: Вторник, 02 Октябрь, 2012 11:02 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1040
Откуда: Россия, Чебоксары
PSV100 писал(а):
Может быть А. Донской что-нибудь добавил бы по сути, подозреваю, что ему, как непосредственному участнику "боевых действий", известны какие-то нюансы.
К сожалению, никаких нюансов. Про Седова и "Машину теорий" с тех пор больше ничего не слышно. Могу только порекомендовать пойти по ссылкам,
приведённым у меня - Гугл вроде хорошо сохранил все ветки этой конференции, а я в текстовом файле мог чего и пропустить :)

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Задача на перспективу
СообщениеДобавлено: Вторник, 02 Октябрь, 2012 22:16 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 371
Илья Ермаков писал(а):
На самом деле это проблема не ООП, а мейнстрим-трактовки, которая активно использует наследование. Многоуровневое, и особенно наследование реализации.
Есть ООП-архитектуры, использующие преимущественно одноуровневое наследование (от ABSTRACT-интерфейса).
...

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

Спасибо за ссылки. В очередной раз Компонентный Паскаль мне напомнил язык Go, есть общие внешние черты. В Go тоже постарались обойтись одними интерфейсами, и пошли по "объектному" пути, поддерживая возможность повторного использования кода применили подмешивание вместо явного наследования, в результате получилась структурная типизация, где легко можно слонов сложить с мухами. Относительно недавно на РСДН обсуждали Go, и я, в качестве бреда, предложил подтюнить интерфейсы по мотивам функционального подхода, добавив реализацию по умолчанию и полиморфизм с параметрами. Приведу пример:
Код:
type Visual interface {
    Show() string
}

type Writer interface {
    Write(data string) err error
}

// Реализуем какой-то универсальный логгер:

type Logger struct {
    LogObj Visual
    Stream Writer
}

// сделаем парочку методов:

func (p *Logger) Log(msg string) {
    p.Stream.Write("Object: " + p.LogObj.Show() + ". Message: " + msg)
}

func (p *Logger) Logf(format string, args ...interface{}) {
    // что-то аналогичное + форматирование
}

// Сделаем новую структуру, куда подмешаем наш абстрактный логгер:

type Job struct {
    *Logger
    someField AnyType
    ...
}

// сделаем какой-то конструктор для нашей структуры:

func makeJob (cmd, filename string) *Job {
    log := new(Logger)
    log.LogObj = cmd
    log.Stream = FileStream.New(filename) //считаем, что FileStream реализует интерфейс Writer
    return &Job{Logger: &log, ...}
}

// чтобы заработало, нам нужно реализовать интерфейс Visual для string:

func (s string) Show() string {
    return s
}

// нам нужно для работы ещё "свойство" Command:

func (job *Job) Command() string {
    return string. (job.Logger.LogObj) //Go у меня сейчас нет, я не уверен в корректности здесь
}

// теперь у нас готовый Job, можем работать:

var job = makeJob("My Supper Comand", "data.txt")
job.Log("starting now...")
cmd := job.Command()
...


Теперь вариант с потенциальными параметрическими интерфейсами. Обращаю внимание на то, что такая методика не только несколько уменьшает проблемы наследования, но и позволяет более гибко реализовать функционал:
Код:
// Здесь есть реализация по умолчанию функции Show (с использованием self, как параметр по умолчанию), которая просто
// вызывает операцию ToString, и пусть эта операция определена для многих типов, включая и string.
// Поэтому нам уже нет смысла переопределять интерфейс для строки.

type Visual interface {
    Show() string {
        return self.ToString()
    }
}

type Writer interface {
    Write(data string)
}

// Теперь логгер будет интерфейсом с параметрами, где уже есть
// обобщённая реализация:

type Logger(logObj Visual, stream Writer) interface {
    Log(msg string) {
        stream.Write("Object: " + logObj.Show() + ". Message: " + msg)
    }

    Logf(format string, args ...interface{}) {
        ...
    }
}

// Делаем наш Job, подмешивая интерфейс. Обращаю внимание:
// - сразу имеем "свойство" Command. Не нужна лишняя функция как в примере выше,
//   где есть преобразование к типу во время рантайм: string. (job.Logger.LogObj)
// - сразу в структуре у нас есть возможность указать явный тип FileStream для
//   поля Stream, а не только интерфейс Writer (хотя никто не запрещает здесь
//   указывать и как Writer с целью абстракции).

type Job struct {
    Command  string
    Stream   FileStream
    Logger(Command, Stream)
    ...
}

// При этом интерфейс Logger нас никак не ограничивает в устройстве своей структуры,
// например, я могу сделать так:

type SuperJob struct {
    Command  string
    anyData  OtherStruct
    Logger(Command, anyData.Stream)
    ...
}


// конструктор для нашего Job:

func makeJob (cmd, filename string) *Job {
    return &Job{Command: cmd, Stream: FileStream.New(filename)}
}

// можем работать:

var job = makeJob("My Smart Comand", "super.txt")
job.Log("starting now...")
cmd := job.Command
...


Имхо, подобных "mixin"-ов не хватает и Компонентному Паскалю, но я могу ошибаться, т.к. его знаю плохо, Oberon не использую.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Задача на перспективу
СообщениеДобавлено: Вторник, 02 Октябрь, 2012 22:19 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 371
Alexey_Donskoy писал(а):
...
По сути я подозреваю, что речь шла о том, что нынче здесь называется "семантический редактор"... по крайней мере в той части, что была у Седова реализована.


Имхо, на семантический редактор "машина теорий" похоже лишь в первом приближении, всё-таки, была какая-то именно "машина", которая обрабатывала "теории".

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Задача на перспективу
СообщениеДобавлено: Вторник, 02 Октябрь, 2012 23:31 
Аватара пользователя

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 778
Откуда: Москва
PSV100 писал(а):
Кстати, спасибо, что напомнили про семантические редакторы. Повнимательнее посмотрел на PureBuilder (я так и не понимаю - это некий прототип/спецификация/мечты, или реальный действующий проект)


Это попытка описать идеальную среду для визуального программирования. Идея предлагается для воплощения профессиональными программистами. Прообразом послужили разнообразные визуальные построители и другие удобные средства в Microsoft Access.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Задача на перспективу
СообщениеДобавлено: Среда, 03 Октябрь, 2012 10:34 
Аватара пользователя

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Задача на перспективу
СообщениеДобавлено: Среда, 03 Октябрь, 2012 12:39 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9147
Откуда: Россия, Орёл
Alexey_Donskoy писал(а):
с документированным процессом поиска решения задачи.


Хочется выделить эту формулировку Алексея.... Основная проблема, действительно, в том, как бы это сделать.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Задача на перспективу
СообщениеДобавлено: Среда, 03 Октябрь, 2012 17:22 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 371
Сергей Прохоренко писал(а):
Это попытка описать идеальную среду для визуального программирования. Идея предлагается для воплощения профессиональными программистами. Прообразом послужили разнообразные визуальные построители и другие удобные средства в Microsoft Access.

Спасибо. Ваши идеи положил в копилочку.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Задача на перспективу
СообщениеДобавлено: Среда, 03 Октябрь, 2012 17:27 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 371
Alexey_Donskoy писал(а):
Имхо, в терминологии Седова "теория" - это метаинформация, которая относится к решению задачи и процессу его поиска. В конечном счёте это схемы данных и "чистые" алгоритмы (свободные от платформной зависимости) - то есть то, что ранее называлось "математической моделью".
"Семантический редактор" нацелен именно на такой результат. Но (пока) представление о нём более узкое - даже поддержка каких-нибудь систем контроля версий не сильно коррелирует с документированным процессом поиска решения задачи.

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

А. Седов писал(а):
>AS>бесполезные споры. ПОРОЧЕН САМ ПРИНЦИП современных ЯВУ: вместо инструментов
>>познания, записи, накопления и расширения человеческого опыта в конкретных
>>предметных областях, ЯВУ представляют собой громоздкие, противоречивые,
>
SS> Не предназначены ЯВУ для таких громких целей как познание и накопление опыта.
> Для этих целей есть язык математики или, если хотите обычные языки, нотная грамота,
> палитра художника. Но если рассматривать только рациональное познание, то
> там где нет математики, нет и познания. Зачем придумывать избыточную сущность?

1. Вот и я говорю: не предназначены ЯВУ для обслуживания процесса познания.
Можно встречный вопрос? А зачем они тогда ВООБЩЕ нужны? Ответ: для маскировки
нашего ВАРВАРСКОГО СПОСОБА использования отличных устройств классификации,
ввода и поиска данных, ситуационного планирования, мониторинга и контроля,
называемых в просторечии компьютерами. Идеи БЭББИДЖА о сущности компьютеров
выдержали проверку временем. ВСЕ ОСТАЛЬНЫЕ ГИПОТЕЗЫ о способах использования
таких машин с треском провалились: не пишут они ни стихов, ни музыки, НЕ
ПРИНИМАЮТ РЕШЕНИЙ, не ГОВОРЯТ на естественном языке, НЕ ИМЕЮТ ничего схожего
с "интеллектом" и т.д. Хотя ОТЛИЧНО ПОМОГАЮТ ЛЮДЯМ делать все это!

2. Никакого "языка математики" В ДЕЙСТВИТЕЛЬНОСТИ НЕ СУЩЕСТВУЕТ! По простой
причине: на сегодня существует НЕСКОЛЬКО "математик" с СОВЕРШЕННО РАЗНЫМИ
подходами к делу: интуиционисткая, конструктивная, "конкретная" и пр.
То, что Вы принимаете за "язык математики", есть МЕТОД ФОРМАЛЬНЫХ МОДЕЛЕЙ.
В основании любой математической теории лежит одна или более формальная
модель (математическая структура), описав которую, Вы, по принятым В ДАННОЙ
ВЕРСИИ математики правилам логики (а они РАЗЛИЧНЫ), получаете развертку
"генотипа" модели (аксиоматики) в логическую структуру, выявляя "по дороге"
ее "законы строения", "следствия", "ограничения".

3. Для применимости таких построений требуется выполнить два простых условия:

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

4. Теперь посмотрите вокруг и скажите, как много Вы найдете областей челове-
ческой деятельности, где можно строить ТОЛЬКО ТАКИЕ модели? Ответ: ничтожно
мало. Даже физика -- самая "математизированная" дисциплина использует вовсе
не "математику" КАК ТАКОВУЮ. Она использует ИСКЛЮЧИТЕЛЬНО наряженные в
математические одежды СОБСТВЕННЫЕ ФОРМАЛЬНЫЕ МОДЕЛИ. Эти модели сплошь и
рядом НЕ ЯВЛЯЮТСЯ "математическими" просто потому, что ДОПУСКАЮТ отступления
от логических канонов ЛЮБОЙ ИЗ "математик", если математический формализм
противоречит корректному опыту. Помнится, Ландау говорил, что если число
из теоретической формулы меньше числа, полученного из опыта, в 2 раза, то
формулу нужно просто умножить на 2! И это -- НОРМАЛЬНО! Для физики. НЕ
для математики, где за такие действия Вам на первом курсе универа поставят
также 2: тот самый коэффициент, который будет БЕССПОРЕН в физике (где кри-
терий ценности теории -- соответствие опыту), но негоден в математике
(где критерий ценности теории -- как минимум, непротиворечивость) :-))).

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

6. Аналогичные физическим СПЕЦИАЛЬНЫЕ формализмы (нарушающие "строгие"
математические принципы и правила там, где это требуется, заменяя их
"содержательными рассуждениями" и "физическим смыслом") используются во ВСЕХ
технических дисциплинах, которые, естественно, пользуются РАЗРАБОТАННЫМИ
формализмами самой математики, не забывая их дополнять и "курочить"
собственной "семантикой". Результатом такого использования математики
является типичная "кусочно-линейная" логическая структура прикладных теорий,
куда с великой непринужденностью из математики "с кровью" "забриваются"
подходящие куски и из них составляется ЛОГИЧЕСКИЙ УРОД, сплошь и рядом
ПОТРЯСАЮЩЕ ЭФФЕКТИВНЫЙ на практике. Всякий, кто изучал сопромат, хорошо про
это знает. Иногда, по прошествии изрядного времени с момента появления
"прикладной теории", развитие специальной дисциплины достигает уровня
зрелости, на котором ОНА САМА выявляет, наконец, собственную "аксиоматику"
и в ее рамках появляется возможность создания ЛОГИЧЕСКИ ГЛАДКОГО
представления о предмете. Вот тогда-то и появляется новая версия
специальной теории, ВНЕШНЕ облаченная в более "непрерывный" математический
формализм, но ВНУТРЕННЕ по прежнему не имеющая к математике НИКАКОГО
ОТНОШЕНИЯ. Если завтра данная дисциплина столкнется с явлениями, описание
которых потребует от нее потерять обретенную "математическую невинность",
прикладная теория немедленно пустится во все тяжкие, наплевав на матема-
тические критерии целостности и истинности ради ЕГО ВЕЛИЧЕСТВА РЕЗУЛЬТАТА.

7. МЕТОД ФОРМАЛЬНЫХ МОДЕЛЕЙ (МФМ) является ОБЩИМ методом постижения истины
во ВСЕХ развитых науках, включая сюда (да-да, в "общую очередь") и
(одно время бывшую вместе с философией законодательницей мод) математику.
Но трактовать МФМ как якобы чисто математический нельзя просто
потому, что он изобретен не в математике, а (как и вся парадигма античной
науки) в философии. Математику интересуют структурные свойства формальных
моделей, физику -- физический смысл, который можно туда нагрузить. Это
значит всего лишь, что математика и физика могут рассматривать разные
аспекты одной и той же модели, но это ВОВСЕ НЕ значит, что все физические
модели -- математические.

8. Суть лично моих предложений крайне проста:

а) прекратить муссировать слова Гаусса "о королеве наук" -- старик
жил во времена, когда всю математику можно было освоить за несколько
лет, а еще лет за 10 изучить и остальные "технические" науки;

б) осознать, что метод формальных моделей не является МОНОПОЛИЕЙ
математики, а есть общеприменимый способ развитого описания в любой
предметной области, отличающейся от математической "кусочно-
линейной" прерывностью логики, а также характерной динамичной
эволюцией исходных понятий, часто не позволящей "зафиксировать"
математичекую структуру модели на более-менее длительный срок,
и (страшно сказать) допускающую БОЛЕЕ ОДНОГО правильного взгляда
на предмет в рамках одной системы понятий;

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

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

9. Нужно отметить, что и "чистые" математики прекрасно осознают характер
описанных проблем. А потому и появились такие новые области математики, как
"нечеткие множества", "темпоральные логики", теории моделей и категорий
и пр. Общий вектор математических устремлений сегодня состоит в попытках
"собрать заново, в целостном виде всю математику", обрести утерянное
"математическое единство" описаний, критериев, методов. Будущее покажет,
насколько это получится. Но сегодня этого ПРОСТО НЕТ!

10. Как видно из вышесказанного, размахивать логической бритвой Оккама
нужно С ВЕЛИКОЙ ОСТОРОЖНОСТЬЮ, дабы не уязвить вместо оппонента самого
себя ;-). Монах Оккам не предполагал, что его тезис об избыточных сущностях
будет СЛИШКОМ ЧАСТО являться основанием для ЗАПРЕТА не логической избыточ-
ности, а просто "неудобного вопроса", понимать истинную природу которого
либо трудно, либо лениво, а значит -- не обязательно.

>систему для обеспечения СЛУЧАЙНОГО блуждания программиста в пространстве
>состояний решаемой задачи. Все существующие ЯВУ были построены в результате

> Не нужно ни по чему бродить программисту - ему надо только закодировать
> матмодель. Грубо говоря, нужна "теория всего сущего".
> Будет она, да хоть на бэйсике можно будет все закодировать.

В простейшем случае. А ести НЕТ матмодели? ЛИЧНО ВЫ много пишите программ
по матмоделям? Подозреваю, что почти не пишите. Разве что, компилятор с
RSL... ;-) Думаю, > 90% современных программ пишутся БЕЗ КАКОЙ-ЛИБО
модели вообще (не говоря уже о математической). Это не только упрек
разработчикам, плохо знающим математику. Это в еще большей степени
свидетельство СЛАБОСТИ математики и проблем с применением ее в существующем
виде для решения большинства практических задач. Так что я предлагаю
реально общепринятый "метод проб и ошибок" заменить на метод "сокращенных
проб и ошибок" (в логических моделях), не теша себя иллюзиями, что вот
проснусь завтра, а математика уже изменилась и программисты -- тоже.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 135 ]  На страницу Пред.  1 ... 3, 4, 5, 6, 7  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2019, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB