DRAKON.SU

Поддерживаю

Уважаемый Александр!

Я не понял. На Вашем рисунке много исполнителей.
Но далеко не все исполнители изображены в соответствии с Вашим Правилом 1.

Ваш рисунок не соответствует Вашему Правилу 1.
Или я не прав?

Просьба пояснить.

Уважаемый Владимир Данилович!
По правилу 1 я выполнил только одну ветку. Все остальные пока без изменений.
Думаю как изображать исполнителя в параллельных процессах. Наверное нужно привязывать к каждому процессу, т.к. в общем случае исполнители могут быть разные.
К вечеру отрисую новую схему

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

Вот что у меня вышло.
Дополнения к ДРАКОНУ незначительные.

Это часть реального процесса. Ничего не придумано.
Поэтому здесь фиксация знаний о процессе.

Уважаемый VOT7!

Заверяю Вас, что так было и так будет. Никаких изменений нет и не предвидится.
Таким образом, у Вас нет никаких оснований для беспокойства.

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

Вы блестяще показали это на примере инструкции о добавленной стоимости.
viewtopic.php?p=61290#p61290 (см. длинную цитату в конце)
Вы великолепно продемонстрировали, как следует извлекать из подобных документов спрятанные в них алгоритмы. viewtopic.php?p=64047#p64047

Огромное Вам спасибо.
_______________________________________

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

Вы -- уважаемый Главный бухгалтер.
Насколько мне известно, Вы единственный Главный бухгалтер, который участвует в работе данного форума.

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

_____________________________________________________________

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

Если нет, не стоит тратить время на чтение этой темы.

Эта тема - экспериментальная.
В ней делается попытка приспособить ДРАКОН для описания бизнес-процессов.
Это очень сложная проблема. Надо попробовать разные варианты.

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

Но! Эти добавления никак не влияют на тот ДРАКОН, который Вы знаете.
Таким образом, Вы можете полностью игнорировать добавления.

Тот ДРАКОН, который Вы знаете остается таким же, каким был.
Говоря Вашими словами, Дракон демонстрирует замечательную стабильность. Самые ранние руководства по языку и самые поздние различаются лишь подачей материала. Никаких радикальных отличий в методике рисования дракон-схем нет. Что, конечно, привлекало людей и позволяло предположить, что это целостная самодостаточная система визуализации информации, в основе которой лежат незыблемые неизменные принципы.

Уважаемый Александр!

Мне хотелось бы, чтобы Ваша схема была попроще и попонятнее.
Поясню на примере.

У Вас икона "вывод".
Написано.

Я это плохо понимаю.

Мне кажется, что лучше будет так:
Убрать икону "вывод".
Вместо нее вставить икону " действие".
В иконе написать

Или я не прав?

Уважаемый Владимир Данилович!
Здесь я имел в виду следующее:
- иконой "ввод" я обозначил документ, созданный за пределом процесса (таковых у меня на схеме два: учебный план и ФГОС, второй поступает из министерства)
- иконы "вывод" фиксируют документ и адрес его передачи по процессу или за рамки процесса.
Что посоветуете? Может быть добавить икону "Документ"?

Советовать не берусь. Боюсь ошибиться.
Предлагаю искать истину (рисовать схему) методом последовательных приближений

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

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


И еще. На первом этапе ввести правило: "Сокращения слов запрещены"
В том смысле, что МСФ надо расшифровывать

2 этап. Ввести икону документ (годится например стандартная икона, у которой низ волнистой линией).
Перед этим в иконе действие объяснить (разжевать) все про этот документ.

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

3 этап. Когда освоим эти этапы, там дальше видно будет.

_____________________________________________

Поясните мне.
Я написал " Разработка учебного плана".
Что я упустил?

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

Хорошо. Буду пробовать


А вот здесь главное не перегнуть палку.
Есть замечательный Принцип Шоу:
Если вы разработали систему, понятную даже дураку, то только дурак и будет ею пользоваться.

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

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

Я со своей стороны очень рад, что изменений не предвидится, и благодарен Вам за популяризацию языка ДРАКОН. Это незаменимый инструмент в работе любого специалиста, а также прекрасное средство совершенствование мышления. Но остаются для меня непонятными следующие моменты.

1. Правило "ритма и метра" и другие аналогичные правила и рекомендации, приведенные Вами на данном форуме. Включите ли Вы их в Вашу последнюю книгу? Следует ли их рассматривать как официальные указания по использования языка ДРАКОН наряду с теми, что приведены в Ваших книгах?

2. Допустим Александр Владимирович Игнатьев с коллегами придумают новые иконы и то, как их использовать при описании бизнес-процессов. Вы включите эти дополнения в новое руководство по языку ДРАКОН?

3. Разве бизнес-процесс чем-то отличается от алгоритма? Это же алгоритм в чистом виде. В Ваших книгах есть примеры экономических алгоритмов, которые вполне подходят под определение бизнес-процессов. И они реализованы стандартными средствами.

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

Утверждение необоснованно совершенно. Считаю это высказывание бредом.

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

По мотивам этих схем


Попробовал сделать описание бизнес-процесса, используя только стандартный ДРАКОН.

Та же схема с некоторыми пояснениями.

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


Некоторые плюсы данной схемы, которые мне в ней видятся : )

1
Ясно видны все ИСПОЛНИТЕЛИ, участвующие в данном процессе.

2
Обозначены все РАБОЧИЕ ЭТАПЫ, которые проходят ИСПОЛНИТЕЛИ.

3
Понятно какие функции (процессы) самих ИСПОЛНИТЕЛЕЙ принимают участие в данном процессе.

4
Достаточно просто определяются документы и их перемещение (хотя и менее явным образом).

5
Неявно заданная последовательность РАБОЧИХ ЭТАПОВ разных ИСПОЛНИТЕЛЕЙ достаточно легко восстанавливается.

!
Структура данного способа представления процесса позволяет автоматически собрать информацию для дальнейшего развития представления об описываемом процессе, а также о месте самого процесса и ИСПОЛНИТЕЛЕЙ в системе.

6
ИСПОЛНИТЕЛИ и РАБОЧИЕ ЭТАПЫ могут автоматически трансформироваться в объекты и их методы.

МСФ
------
РЕШЕНИЕ О РАЗРАБОТКЕ РПУД.
ВЫДАТЬ ДОКУМЕНТ (параметры).
ПОЛУЧИТЬ ДОКУМЕНТ (параметры).
Согласовать РПУД.
Включить РПУД в ООП ВПО направления подготовки.
Выработать замечания.
Определить возможность включения программы.

ЗАВЕДУЮЩИЙ КАФЕДРОЙ
---------------------------------------
НАЗНАЧЕНИЯ.
ЗАМЕЧАНИЯ.
ВЫДАТЬ ДОКУМЕНТ (параметры).
ПОЛУЧИТЬ ДОКУМЕНТ (параметры).
Назначить разработчиков РПУД.
Назначить рецензентов РПУД.

РАЗРАБОТЧИКИ
-----------------------
РАЗРАБОТКА
ДОРАБОТКА
ВЫДАТЬ ДОКУМЕНТ (параметры).
ПОЛУЧИТЬ ДОКУМЕНТ (параметры).
Разработать РПУД.
Доработать РПУД.

РЕЦЕНЗЕНТЫ
--------------------
ЭКСПЕРТИЗА
ВЫДАТЬ ДОКУМЕНТ (параметры).
ПОЛУЧИТЬ ДОКУМЕНТ (параметры).
Провести экспертизу РПУД.
Написать отзыв.
Определить наличие назначенных рецензентов.
Определить наличие замечаний.

КАФЕДРА
--------------
ЗАСЕДАНИЕ
ВЫДАТЬ ДОКУМЕНТ (параметры).
ПОЛУЧИТЬ ДОКУМЕНТ (параметры).
Обсудить экспертизу РПУД.
Определить необходимость доработки РПУД.

ПРОРЕКТОР ПО УР
----------------------------
УТВЕРЖДЕНИЕ
ВЫДАТЬ ДОКУМЕНТ (параметры).
ПОЛУЧИТЬ ДОКУМЕНТ (параметры).
Утвердить РПУД.

7
Явная последовательность РАБОЧИХ ЭТАПОВ легко создаётся автоматически, при этом остаётся возможность видеть на основании каких решений происходит ветвление процесса.

Вот например «Обобщённая линейная схема процесса».

Также легко создаётся «Подробная линейная схема процесса».
(Как пишут в умных книжках «Предоставляем возможность читателю проделать это самостоятельно» : )

8
Автоматически формируется список документов, обрабатываемых в данном процессе.

Протокол о разработке РПУД.
Распоряжение с указанием разработчиков.
Распоряжение с указанием рецензентов.
РПУД.
Подписанная РПУД.
Рецензия.
Замечания рецензентов.
Выписка из протокола заседания кафедры.
Рассмотренная РПУД.
Замечания кафедры.
Замечания МСФ.
Выписка из протокола.
Утверждённая РПУД.

9
Автоматически создаётся линейная схема движения документов (по количеству документов).

10
Уже сейчас можно пользоваться такими схемами, например, используя ИС Дракон.

11 добавлено 02.09.12 16:15
Схема удобно разбивается на части для печати на стандартных форматах А4.
По ИСПОЛНИТЕЛЯМ или по РАБОЧИМ ЭТАПАМ.

Ну а минусы, я надеюсь, подскажут уважаемые критики : )

Хороший результат! Вы реализовали процесс на автомате с вложенными состояниями. Собственно, замечание лишь одно, да и то формальное - полки не вызывают циклы. Цикл у Вас уже задан - "Рабочие этапы". Полками Вы лишь "переключаете состояния".

Вложенность состояний наследуется из организации процесса: исполнители имеют разделённые обязанности == выполняют различные функции.

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

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

1. явное указание достигнутого состояния на конце лианы;

2. слой обмена данными между исполнителями - через ввод-вывод.

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

Уважаемый Эдуард Ильченко!

Огромное Вам спасибо за эту работу. Прекрасную работу. Значительную работу.

Я рассматриваю данную работу как продолжение Вашего титанического труда, проделанного в теме "Сравнение Дракона со всякими другими".
viewtopic.php?f=78&t=2215

Та (предыдущая) тема вошла в историю, как инициированный Вами коллективный творческий труд, вызвавший огромный интерес (290 сообщений).

Надеюсь, что это Ваше начинание будет столь же масштабным.

Тема "Приспособление Дракона к описанию бизнес-процессов" является исключительно важной и перспективной.

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

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

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

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

Именно на примере этой задачи я и хотел изначально продемонстрировать свой подход : ), но потом остановился на более нейтральном варианте, имеющем несколько явных исполнителей.

Да, конечно. Я не правильно сформулировал. Поторопился : )