DRAKON.SU

Кстати, в каждой шутке есть лишь доля шутки... имеются в виду прежде всего параллельные процессы...

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

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

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

А Вельбицкий в своей статье и для сетевых графиков тоже предоставляет Р-вариант:



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


Ну, тут и спорить не нужно. Но, всё-таки, главное в предприятии - это иметь возможность продавать

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

Например:



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

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

Не совсем понятно о чём речь. На диаграмме плохо выделяются параллельные процессы? Хм..., тогда надеюсь, что здесь вопросов не будет...


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

Кстати, можно сравнить с mind map на ДРАКОНЕ

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

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

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

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

Вот это сопоставление интересно. И вызывает некоторые вопросы:

1) Так в Р-схемах некоторый тип вершин м.б. использован в качестве излома?..

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

Да, так дверь захлопнется с другой стороны, я только сейчас полностью прочитал условия и увидел, что это банальный поиск, до этого я обратил внимание на безусловную обратную дугу и отсутствие структуризаторов, что приводит приводит к зацикливанию, спасибо.
Кстати, сдув пыль с раритетной ДВК я решил проверить, как отреагирует РТК на эти схемы (после приведения к реальной программе). На последнем варианте после компиляции и запуска вылезло сообщение "ВЫПОЛНЕНИЕ ПРОГРАММЫ TEST1 ПРЕКРАЩЕНО: НЕВЫПОЛНИМАЯ СТРУКТУРА 3 ГРАФ 1", первая же программа зациклилась.

Это разработка МЦТП ИК АН УССР для младших машин типа СМ, ДВК, Электроника и т.п. работавших на ОС RT-11 (советских аналогах). Комплекм включал в себя трансляторы с языков графический паскаль, графический ассемблер, графическая модула, графический редактор ( в смысле редактор для написания программ с использование графов), система документирования (связанная с редактором), СУБД, Электронная таблица, статистическая подсистема (вовод графиков и т.п.) Всё это было полностью написано с использованием Р-технологии, все было взаимно интегрировано - так при написании можно было вывести на экран электронную таблицу/ы ( каждую в отдельный вид, произвольных размеров!) связать с БД, отредактировать и сохранить обратно, провести анализ, вывести графики (на экран в тектовом режиме, на плоттер в графическом), сама СУБД имела свои средства отображения, средства интерактивной работы.
В старших ЕС РТК были более развитые - групповая работа, управление проектами, контроль версий, средства кросскомпиляции и еще куча всего.
С использованием этой технологии была написан аналог электронной библиотеки ( в ней, конечно не было книжек про Эммануэль, а только техническая документация и тп), на которой, в свою очередь, была построена система электронного документооборота, учетная система для планово-экономического отдела, которая была связана с системой документооборота и библиотекой и легко можно было открыть на экране соответствующие нормативы и прочую связанную с документом или расчетом информацию. И это 80-е годы! Ничего подобного нигде не было. А потом случился 91-й.

Если у кого есть скан книги Вербицкоко, выложите сюда, plz.

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

Должно быть так и только так, всё остальное от бедности и перечёркивает исходную эргономику!

Уважаемый Kemet!

Есть ли у Вас сведения о том, что Р-технология где-либо применяется на практике?
Причем не в прошлом (это не вызывает сомнения), а в настоящее время. Если такие сведения есть, желательно рассказать поподробнее.

Спасибо

Я с трудом нашёл лишь один случай свидетельств тех лет, а оказывается, что здесь, на месте, не отходя от кассы, имеется "человек-легенда"

Присоединяюсь к вопросу от Владимира Даниеловича, хотя подозреваю, что "...сдув пыль с раритетной ДВК..." - это единственное современное применение с 91-го...

И позволю ещё немного "наглости". Если Вы непосредственно использовали Р-комплекс, то просьба поделиться впечатлениями:

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

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

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

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



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

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



Р-схему к такому виду можно притянуть, в т.ч. и "раздуть" именованные вершины.

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

Я убежден, что дело не в секретности. Секретность ни при чем.

Да, действительно, раньше была жуткая секретность.

Например, в 1976 году, когда начинался Буран, нам было запрещено произносить это слово. Полагалось говорить не Буран, а "изделие 11Ф35".

Но все это в прошлом. В космическом подразделении НПЦАП, где я работаю, секретности давно нет. Абсолютно никакой секретности. Даже запаха.
Вместо секретности теперь есть гриф "Коммерческая тайна НПЦАП".



Теперь об Р-технологии. Мне о ней рассказывал и показывал ракетчик Борис Михайлович Конорев. Честно говоря, я почти все позабыл. Помню лишь, что чертежи Р-схем были, кажется, формата А3.

Уважаемый PSV100!

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

Запомните, Борис Михайлович Конорев
В этой статье есть несколько упоминаний и фото (там он молодой):
http://www.buran.ru/htm/memory44.htm

Погуглите Борис Михайлович Конорев В инете еще что-то есть. Я не копался.

Последний раз я виделся с Борис Михайловичем примерно в 1995 году.
Если он жив (дай Бог ему здоровья), и Вы его найдете, я уверен, что он Вам расскажет во всех деталях (и без всякой секретности), как работала эта технология в ракетной технике.

Найдете — передавайте ему от меня привет.

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

Наверное... только ведь Р-вершины не обозначают работы (т.е. укрупнённые действия - это опять же к обратности семантики)?..
По сетевым графикам - мы в таком синтаксисе ими обычно и пользовались...

А нужно ли то же размытие на твёрдой копии (всё к тому же, что здесь)?..

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


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

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


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

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

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

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

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

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