DRAKON.SU

Текущее время: Четверг, 28 Март, 2024 20:56

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




Начать новую тему Ответить на тему  [ Сообщений: 254 ]  На страницу Пред.  1 ... 6, 7, 8, 9, 10, 11, 12, 13  След.
Автор Сообщение
 Заголовок сообщения: Re: ДРАКОН vs Р-схемы
СообщениеДобавлено: Среда, 05 Сентябрь, 2012 18:59 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
PSV100 в viewtopic.php?p=74405#p74405 писал(а):
...
Вы, как и всегда, зрите в самый корень.
...
Конечно, это идеал, к которому хочется стремиться. Повторюсь, что я пытаюсь разобрать Р-схемы и с целью, в т.ч., разгрузить их дуги. Но как загрузить адекватно вершины, пока не могу понять...
Да я-то просто раздумываю над конкретикой реализации... отсюда и множество правил (сообразил, что Вы, видимо, о графит-методе) - потому что надо учесть, кроме специфики структур, ещё и всё, как если бы собрался писать свой ГРАФИТ-ФЛОКС (точней, скорее ТЗ на него)... :)
Насчёт как чего загрузить - единственное, что можно сказать - от смысла предметки, передаваемой языком... :) Т.к. антисистемность определения оргсистемы через бизнес-процессы, как уже говорил, прочувствовал на опыте создания хорошо проработанного аналога БПР-грамматики Калянова (независимо от последнего :) ), то по смыслу для Вашей постановки чего-то посоветовать не могу. Тем более, что "создание велосипедов м.б. полезно" ((С) Усов) - в чём тоже убеждался - так что и отговаривать смысла вроде нет... :)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: ДРАКОН vs Р-схемы
СообщениеДобавлено: Среда, 05 Сентябрь, 2012 19:07 

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

Ну хоть одна польза от голливуда - широкоформатные мониторы для Р-схем :) (и для драконовских силуэтов тоже).

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

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


Они чуть отличаются по содержанию, но непринципиально. На UML-варианте мы явно наблюдаем все пути, причём наглядно. Пусть "Прокладка электропроводки" выполняется также и после "Закупка труб", и, к примеру, "Прокладка водопровода" в т.ч. и после "Подводка электролинии" - т.е. появляется пересечения линий, плюс необходимость в новых uml-чёрточек, и в результате мы можем поиметь непроходимый лес. В Р-варианте подразумевается, что всё соединение маршрутных линий скрыто в спецвершине между структурами (точнее в каждой соединительной вершине, не только в спец.). Логика прохождения по дуге указана в предикате, в данном случае вписаны работы, предшествующие для дуги. При этом предполагается, что дуги (действия) в структуре (по умолчанию) исполняются параллельно, работа начнётся когда сработает предикат, или если его нет, то "Р-запускальщик" ничего не ждёт. Явных символов "&" в вершинах нет, как раз это попытка не использовать что-то вроде IDEF-перекрёстков вроде "and, or, xor и т.д.". Т.е. эта схема для своего Р-запускальщика и Р-исполнителей. Эту диаграмму также можно задать и в виде сетевого графика работ, о котором тут немного говорили, и очень вероятно, что схема окажется проще для восприятия (в т.ч. и как Р-вариант). Но в такой исходной схеме мы можем реализовывать необходимые алгоритмические уточнения, если хотим это увидеть не отходя от кассы. К примеру, указать условие не только как "провода закуплены", но и в т.ч. "белого цвета или жёлтого, если хозяйка не против", расписать все возможные исходы события и реакцию на них, что-то подробнее раскрыть, т.е. простая дуга заменяется на структуру, с циклами, переходами и т.д. Короче говоря, это возможный прототип "доалгоритмической" схемы, в данном случае в разрезе неких материальных процессов, но тот же принцип и для программных "доалгоритмов".
Повторюсь, схема оформлена не по ГОСТу. Здесь как раз, вроде как, параллельное соединение, но этого не заметно, т.к. знак "+" как вершина не выделяется, к тому же он в каждой вершине, кроме специальных. Между структурами "много-много" введена спецвершина, т.е. не только для спецдуги, которой нет на схеме (имхо, лучше явно выделять соединение). По поводу оформления ещё нужно думать, если появится реальное применение.

Спасибо за разъяснения. Если появится желание, то подбрасывайте дровишек, всем будет полезно.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: ДРАКОН vs Р-схемы
СообщениеДобавлено: Среда, 05 Сентябрь, 2012 19:35 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
Вы хорошо разъяснили ещё с одной стороны. Дровишки будут такие:

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

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

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


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

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
Думаю, что системный подход, как я его понимаю, можно изложить и на примере.

Пусть у нас есть некая оргсистема реального сектора, юзающая что-то вроде КУБа. В некоем состоянии справочники заполнены, ПМ и ТП описаны, какой-то набор заказов принят, расцехован и исполняется.

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

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

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

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

Ага! - воскликнет человек не из реального сектора - так это же всё про "вещное", а у нас же все предметы знаковые?.. :wink: Всё нормально - просто заменяем "детали" на "бумаги/файлы (на ноосителях и "в пути" в среде связи)"...

Ну, в общем, "проблемы известны, планы разработаны, силы распределены. За работу, товарищи!"... одни - выпускать продукт, другие - выпускать системы автоматизации выпуска... только осталось неясным, для чего же Р-схемы?.. :)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: импеР-схемы и жизнь :)
СообщениеДобавлено: Четверг, 06 Сентябрь, 2012 11:14 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
Посмотрим теперь, как наши работы выполняются. Может, чего и узнаем...

Петров приступил к обработке очередного заказа (пусть он сверловщик). Интересно отметить, что делается это на станке по-разному - в зависимости от типа.
Если станок одношпиндельный (ну, дрель на стойке, короче :)) - то Петров будет, само собой, последовательно (в порядке, заданном технологом) по разметке (при неединичном производстве - скорее всего, по кондуктору - пластина такая, на которой просверлены по разметке все отверстия - твёрдая, чтоб подольше не рассверливалась) засверливать отверстие за отверстием. Если диаметры неодинаковы или тип инструмента (м.б. ещё развёртка, зенковка) - то после отвода меняет инструмент.
На РБНФ (для любителей) в синтаксисе Мейера будет укрупнённо так: {подвёл-подал-отвёл[-сменил]}+Nотв... :)
Импер-граф-запись для этого случая - очевидно, дракон-схема.

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

Ну и есть такой тип станка - "обрабатывающий центр". Тут ряд шпинделей - но независимых и со сменой инструмента на ходу. В этом случае тоже можно обрабатывать последовательно и где-то - одновременно. Причём синхронность м.б. и не полной.
На этот случай у технологов тоже есть выразительные средства, не переживайте... :) называются "техпереходы". Это так - расписываем процесс в терминах "начать[-продолжить]-завершить". Тут нам и средства "точного времени" пригодятся.
    Скажем, не совпадают начала подходов - пишем (ну-ка, ЧПУ-шники, проверьте неспециалиста): "Т1=0 - начать подвод РабОргана1 на базу Х1У1З1; Т1=Нач2 - начать подвод РабОргана2 на базу Х2У2З2 (а РО1 в это время по технологии ещё движется, по датчикам координат встанет); Т1=Раб1 - начать подачу РО1 по Х (закон задан, конец по датчикам; аналогично РО2 ещё движется); Т1=Раб2 - начать подачу РО2 по Х,З (опять же закон задан, конец по датчикам; на самом деле, если линейный и не совпадает с осями станочной СК - то не заморачиваются и считают это ещё одной осью координат :)); Т1=Ост1 - начать отвод РО1,2;... " в общем, понятно, думаю... :)
Здесь мы использовали события пространственного контроля и потому выдержка времени операций (с явным указанием завершения) не потребовалась. Однако при программировании станка "на низком уровне" всё будет явным.

Ну и снова вопрос - каким будет процесс, описанный таким образом?..

Неполный синхронизм, кстати, возможен и при двух и более многошпиндельных РО. Это, конечно, третий случай.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Взаимодействия и схемы
СообщениеДобавлено: Четверг, 06 Сентябрь, 2012 14:37 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
Теперь посмотрим, а как наш Петров принимает и отдаёт предметы труда, а также данные о своей работе?

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

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


Последний раз редактировалось Владислав Жаринов Пятница, 07 Сентябрь, 2012 07:23, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: ДРАКОН vs Р-схемы
СообщениеДобавлено: Четверг, 06 Сентябрь, 2012 20:02 

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

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

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

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

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

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

Плюс есть потребность в описании программных алгоритмов. Здесь та же модель: граф "программных мощностей" -> "доалгоритмика" -> "расшифровка". Думаю, Вы лучше меня всё понимаете. И место в "Р-Кубе" тоже можно подыскать для них.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: ДРАКОН vs Р-схемы
СообщениеДобавлено: Четверг, 06 Сентябрь, 2012 20:07 

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

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

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

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

Для всего этого есть потенциал у Р-схем, но "лисп" ..., нужно ещё разбираться ...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: ДРАКОН vs Р-схемы
СообщениеДобавлено: Четверг, 06 Сентябрь, 2012 20:12 

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

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

Короче говоря, всегда нужно "системно...".


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 06 Сентябрь, 2012 23:16 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1098
Откуда: Россия, Чебоксары
Владислав Жаринов писал(а):
Итак, работа переназначена. Как это представляется на моделях разного вида? На алгоритмической схеме - вообще никак. :) В схеме типа "попытки изображения бизнес-процесса" получится, что чья-то невидимая рука стёрла прежнее значение исп-атрибута действия (в поле или в боковике) "Иванов:123456" и написала новое "Петров:654321".
Ух, понесло так понесло.
Куда, зачем?!

Модель - она моделирует ПРОИЗВОДСТВО. Про то, что такое производство и предприятие, Вы читали у Усова.
Что, здесь у вас техпроцесс поменялся? Какой-нибудь из компонентов поменялся? Связи поменялись?

Алгоритмы деятельности относятся к РОЛЯМ, а не к конкретным исполнителям.
Конкретные исполнители в данном случае являются данными (ресурсами). Вы что, при простом изменении данных собираетесь менять структуру таблицы в Вашей базе?!

При такой каше в изначальном подходе к задаче Вы не только системного подхода не получите, а вообще ничего не решите. Собственно, это и демонстрирует далее PSV100, всё время говоря об анализе СЛОЖИВШЕЙСЯ СИТУАЦИИ. Не о решении задачи, не о постановке задачи, не о материальных и финансовых потоках, не о планировании производства - а о наблюдении того, как муравьи суетятся, и попытке понять и воспроизвести всю эту суету...
Ну, друзья, какой нынче век на дворе?! Сколько можно заниматься так называемой "автоматизацией" вместо реального дела? В "учёте материальных ценностей", который я в 80-е годы писал на ДВК для "автоматизации бухгалтерии", было больше пользы и даже системности, чем в так называемом "анализе" передачи бумажки какой-то Марье Ивановне...

Короче, обоим читать Усова в соседнем форуме (Владислав, напомните ссылку, у меня на этом компе нет)! :D

И, пожалуйста, не валите в одну кучу данные и метаинформацию.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: ДРАКОН vs Р-схемы
СообщениеДобавлено: Пятница, 07 Сентябрь, 2012 07:52 

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

По Усову на этом форуме, полагаю, Вы имеете в виду прежде всего две ветки - эту: viewtopic.php?f=12&t=3852 и эту: viewtopic.php?f=12&t=3853?.. но также, наверное, и эту: viewtopic.php?f=86&t=3317, эту: viewtopic.php?f=86&t=2915, эту: viewtopic.php?f=86&t=2930?..

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

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


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

Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: ДРАКОН vs Р-схемы
СообщениеДобавлено: Пятница, 07 Сентябрь, 2012 08:15 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
PSV100 писал(а):
...
Короче говоря, всегда нужно "системно...".
Вот именно... и для того, чтобы понять логику подхода Усова, в общем достаточно роликов. Мне для начала и этого не потребовалось - главное было осмыслено здесь ещё по первым дискуссиям... Но понадобилось ещё уточнить место импер-компоненты - и алгоритмической, и доалгоритмической.

Как можно видеть, в комментируемых постах кое-что оставлено открытым. Это потому, что мне интересен не свой монолог, а обсуждение... :) В принципе там кое-что дорабатываю, учитывая, что выявляется неясного.

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: ДРАКОН vs Р-схемы
СообщениеДобавлено: Пятница, 07 Сентябрь, 2012 10:08 
Аватара пользователя

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

Но связи ли это на самом деле?
Полагаю, что не обязательно.

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

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

Перестройку связей внутри подсистемы имеет смысл учитывать разве что при имитационном моделировании :)
Ну или внутри "системы управления подсистемой", если таковая вообще есть в виде самостоятельной IT-сущности.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: ДРАКОН vs Р-схемы
СообщениеДобавлено: Пятница, 07 Сентябрь, 2012 11:17 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
Да разумеется... вон у китайцев целая культура, когда и как брать... :wink:

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

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

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

Ну, про Р-схемы алгоритмов уже было сказано...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: ДРАКОН vs Р-схемы
СообщениеДобавлено: Пятница, 07 Сентябрь, 2012 22:31 

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

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

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

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

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

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

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

Владислав Жаринов писал(а):
И кстати, в системе типа КУБа могли бы работать и Вы - разработка АИС тоже ведь деятельность :wink: - только особого рода (в терминах Усова - тип проектного производства).

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

Alexey_Donskoy писал(а):
Ну, друзья, какой нынче век на дворе?! Сколько можно заниматься так называемой "автоматизацией" вместо реального дела? В "учёте материальных ценностей", который я в 80-е годы писал на ДВК для "автоматизации бухгалтерии", было больше пользы и даже системности, чем в так называемом "анализе" передачи бумажки какой-то Марье Ивановне...

Вот как раз в 80-е и можно было говорить о системности. Хотя я в те годы только в школу бегал, но я в этом уверен. А сейчас о системности говорят только на форумах, и то в разделах для философии...

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

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

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

Поэтому, РТК-комплексы, 80-х годов (!), были лучшим решением для предприятий, и вряд ли когда-либо появится им адекватная альтернатива.

Так что, "системное" понимание сути - это первоочередное и главное. Но на местах эта "системность" никому не нужна...


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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Системы и автоматизация
СообщениеДобавлено: Суббота, 08 Сентябрь, 2012 08:58 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
Вот об чём и речь... Вы сами в оргсистеме-разработчике, может (из описания я не понял), и пытаетесь работать уже системно, по принципу "проектного производства"... тогда как Вашим потребителям, м.б. и несложно это объяснить (как видите, я приближённое описание уложил в четыре поста) - но им в нынешней экономике часто проще "ловить рыбку в мутной воде" - так что не каждый захочет (и об этом Усов тоже говорил :wink:)...
    Короче, не системность это, а "комплексность" - в реальном смысле от английского "complex - с-ложный"... :wink: :|
Поэтому, кстати, в графит-методе именно этим словом обозначил тип маршрутного макроблока неатомарный, с "БП-шными" лианами. Хотя и здесь Усов (и не он один - тот же TAU) указывали, что иногда и goto целесообразен... Отсюда, кстати, воопрос - в Р-нотации всё должно выводиться исключительно вложением атомов (вершин/подграфов)... и сами атомы-подграфы структурные?..

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

А переназначение - это даже не табель (роль которого - именно обозначить текущее замещение). А именно пересопоставление графа ТП с графом ПМ (ну или таблицы, или текста - тот же мастер вряд ли будет объяснять Петрову, вершины двигая... :wink: если, конечно, у него системная среда не внедрена).

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

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

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

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

Короче - попробуйте сначала внутри своей оргсистемы окончательно уйти от того, что:
Alexey_Donskoy в viewtopic.php?p=74453#p74453 писал(а):
..., всё время говоря об анализе СЛОЖИВШЕЙСЯ СИТУАЦИИ. Не о решении задачи, не о постановке задачи, не о материальных и финансовых потоках, не о планировании производства - а о наблюдении того, как муравьи суетятся, и попытке понять и воспроизвести всю эту суету...
...
- возможно, через это в такой (типичной, конечно) ситуации лучше, естественнее воспримется системность...


Вот так как-то...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: ДРАКОН vs Р-схемы
СообщениеДобавлено: Понедельник, 10 Сентябрь, 2012 20:08 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 396
Владислав Жаринов писал(а):
...
По некоторым частностям. Как раз Донской и говорил "понесло" в том смысле - что, например, никакой граф ПМ под переназначение на работы корректировать не надо (и я этого не предлагал). :)
...

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

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

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


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

Надеюсь, что ключевую суть я уловил. Но потребности в "анализе СЛОЖИВШЕЙСЯ СИТУАЦИИ" никогда не избежать (включая и в своей "маленькой компании"), это неотъемлемая часть производственного процесса. А в "кубик" в рамках состава ТП и ПМ, и их сопоставления, вносятся только результаты "бизнес-разборок" и мучений программирования, точно так же, как определяются только итоги "инженерно-конструкторских стрелок и сходок" вокруг самого производства, подкрепляемых чертежами и сопутствующей документацией. И как раз есть потребность хранить и все промежуточные, и итоговые данные, для всего "тех-" и "нетех-производства" (теперь уже как единого производства), что реализовывалось в древних комплексах РТК, имхо, это образец для "кубико-строения".


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: ДРАКОН vs Р-схемы
СообщениеДобавлено: Понедельник, 10 Сентябрь, 2012 20:31 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 396
Владислав Жаринов писал(а):
...
Хотя и здесь Усов (и не он один - тот же TAU) указывали, что иногда и goto целесообразен... Отсюда, кстати, воопрос - в Р-нотации всё должно выводиться исключительно вложением атомов (вершин/подграфов)... и сами атомы-подграфы структурные?..

Если отбросить теории, то goto, всё-таки, иногда жизнь упрощает. Вон в Lua столько лет жили без goto и только относительно недавно сдались (а в Lua принцип - ни грамма лишнего, и здесь есть чему поучиться) и специально ввели его в язык, видимо, как раз для облегчения решений задач по кодогенерации (в том числе), скажем, по тем же ДРАКОН-схемам (хотя, если посмотреть на Lua-платформу, то сам язык Lua уже превращается в некий ассемблер, на основе которого выращиваются свои DSL и алгоязыки, как MoonScript, например).

По поводу Р-схем. Я не могу обосновать их некую "степень структурности", но на мой взгляд, как нетеоретика, то она весьма высокая. Это предположение исходя из сущности структурных переходов. Даю выдержку из статьи Вельбицкого:

Вложение:
r_struct.PNG
r_struct.PNG [ 69.68 КБ | Просмотров: 11272 ]


На поясняющем рисунке плохо различимы символы "звёздочка" и "решётка", но вроде и так всё понятно. Видимо, структурные переходы также объясняют наличие типов вершин "как кружочки" и "без них", как на этом рисунке:

Вложение:
r_par_str.PNG
r_par_str.PNG [ 4.94 КБ | Просмотров: 11272 ]


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

Как по мне, то Р-схемы структурные "по самое не могу". При этом нет возможности "разорвать" какую-то дугу, тот же цикл.

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

Изображение

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

Вложение:
r_for.PNG
r_for.PNG [ 3.55 КБ | Просмотров: 11272 ]


А если посмотреть на примеры обычных циклов, как здесь:

Изображение

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

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

Вложение:
r_pereh.PNG
r_pereh.PNG [ 8.55 КБ | Просмотров: 11272 ]


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


Одним словом, в Р-схемах есть и структурность и гибкость. Кстати, если бы я решал и вопрос об обработке исключительных ситуаций, то также подошёл бы к этому на принципах исходной Р-машины. Т.е. не вводил бы явных управляющих инструкций вида try-catch/except/finally, а необходима семантика чего-то вроде Go-шного Defer, Panic, Recover (одного универсального обработчика ошибок, как в Р-машине из книги Вельбицкого, в современных боевых условиях явно недостаточно, нужно идти дальше). В этом случае нет также мучений и с визуальным маршрутным представлением, т.к. нет явных отдельных маршрутных указаний (точнее, они как бы есть, их при необходимости можно отобразить, но это уже конкретные проблемы реализации Р-технологии, уже отдельная тема, сейчас это просто мысли вслух).


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: ДРАКОН vs Р-схемы
СообщениеДобавлено: Вторник, 11 Сентябрь, 2012 09:32 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5846
Откуда: Москва
PSV100 в сообщении viewtopic.php?p=74587#p74587 писал(а):
Если отбросить теории, то goto, всё-таки, иногда жизнь упрощает.

Вон в Lua столько лет жили без goto и только относительно недавно сдались (а в Lua принцип - ни грамма лишнего, и здесь есть чему поучиться) и специально ввели его в язык.

Видимо, как раз для облегчения решений задач по кодогенерации (в том числе), скажем, по тем же ДРАКОН-схемам.

(Хотя, если посмотреть на Lua-платформу, то сам язык Lua уже превращается в некий ассемблер, на основе которого выращиваются свои DSL и алгоязыки, как MoonScript, например).

Уважаемый PSV100!

Не могли бы Вы дать ссылки, из которых ясно, что:
1. В начале в Lua не было goto.
2. На втором этапе (когда именно?) в Lua ввели goto.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: ДРАКОН vs Р-схемы
СообщениеДобавлено: Вторник, 11 Сентябрь, 2012 13:29 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 396
Владимир Паронджанов писал(а):
...
Не могли бы Вы дать ссылки, из которых ясно, что:
1. В начале в Lua не было goto.
2. На втором этапе (когда именно?) в Lua ввели goto.


Всё доступно, например, в официальной документации. Оператор goto был введён в последней версии 5.2, декабрь 2011 (анонс новых возможностей), краткая справка об операторе, примеры использования. Следует обратить внимание, что этот goto, всё-таки, не полный беспредел, а ограничен синтаксическими блоками, к примеру, нельзя прыгнуть во вложенный блок. Одним словом, всё в пределах структурного подхода. В ряде других языков также имеются аналоги "невинного goto", только без "стыдного" слова, но с меньшими возможностями: break и continue, плюс метки на внешние циклы, выходы из вложенных функций сразу на более верхние уровни. Сейчас такие "финты", например, реализуют для языка Kotlin. И обращаю внимание, что это аналоги структурных переходов в Р-схемах древних лет.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 254 ]  На страницу Пред.  1 ... 6, 7, 8, 9, 10, 11, 12, 13  След.

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


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

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


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

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