DRAKON.SU

Уважаемые друзья,
Я совсем недавно познакомился с языком Дракон, мне он очень понравился и теперь я его повсеместно использую в своей работе (ныне работаю директором компании). Ранее я увлекался программированием (С#, VBasic, C++, Clipper, DBase, bash), правда сейчас это лишь мое хобби.

Позвольте выразить признательность авторам, самого языка и Интегрированной Среды. СПАСИвасБОг за возможность использования такого мощного инструментария в своей повседневной работе и жизни.

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

Уважаемый Алексей Евгеньевич!

Приветствую Вас на этом форуме.


Высказать замечания трудно, потому что я не вполне понял Ваш замысел.
Первые впечатления такие:

1. Вы тщательно и в основном правильно описали логику.

2. Но у Вас нет действий. На схеме я нашел всего одну икону действие: Отсутствие действий делает схему слепой. Чтобы довести схему до кондиции, надо добавить действия и/или вставки.

_____________________________

Грубо говоря, Ваша схема НИЧЕГО не делает.

Что такое действие?

Например:

1. Сходи в магазин

2. Купи картошку

3. Купи мясо

4. Свари суп
__________________

Можно по-другому:

1. Запуск программы

2. Получение результата.

3. Пересылка результата в хранилище.
___________________________________

В иконах "имя ветки" записаны МЕТКИ (а не действия). Эти иконы НИЧЕГО не делают.
Таким образом, получается, что Ваше схема НИЧЕГО не делает.

ВЫВОД

Желательно, чтобы Вы пояснили, что эта схема должна ДЕЛАТЬ.
Какую последовательность действий (алгоритм) эта схема призвана ВЫПОЛНЯТЬ.

2 Алексей Евгеньевич

Если речь об алгоритме, то, наверное, уместнее рассматривать алгоритм КАК создать ЕСР ДРАКОН.
У Вас же, имхо, получилось описание ЧТО должна содержать ЕСР ДРАКОН.

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

Вместе с тем замечание Эдуарда меткое - в таком виде фактически определены характеристики ЕСР. Ваши комментарии кое-где содержат идеи возможных действий (а где-то - дополняющих/уточняющих условий). Это по-своему интересный подход к формализации деятельности.
Конечно, декларации сущностей, имена которых будут фигурировать в более проработанной схеме, будут нужны. Хотя бы иллюстративные - как здесь: viewtopic.php?p=73245#p73245 - ну или ближе к теме, как здесь: viewtopic.php?p=74438#p74438 (имеем смешанную декларацию рисунком и текстом).

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

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

Согласен. Желательно "вытащить" эти идеи из комментариев и превратить смутные ИДЕИ ВОЗМОЖНЫХ ДЕЙСТВИЙ в четко сформулированные ДЕЙСТВИЯ, записанные в иконах "действие" и/или "вставка".

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

Уважаемые друзья, спасибо вам за ваши комментарии.

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

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

Подскажите пожалуйста, что вы думаете на сей счет.

Уважаемый Алексей Евгеньевич!

Дракон-схемы не предназначены для описания деклараций (декларативных знаний).
Дракон-схемы предназначены для описания алгоритмов (императивных знаний).

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

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

==================================

Таким образом, Вашу схему можно рассматривать только как эксперимент.

Уважаемый Владимир Даниелович,
Спасибо Вам за столь быстрый ответ.

А как бы вы рекомендовали поступить в данном случае? Использовать другой инструмент для этих целей?

1. Дракон — эффективный инструмент. Его эффективность подтверждена в огромном числе случаев. Но Дракон — не универсальная отмычка, позволяющая открыть любую дверь.

2. Я хотел подчеркнуть именно это. И Вы меня поняли.

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

3. Алексей Евгеньевич, Вы руководитель компании. Вы ставите цели и выбираете средства для их достижения. Если какие-либо правила (например, установленные мной для Дракона) мешают достижению Ваших целей, Вы вправе игнорировать их. Или изменить правила, чтобы они не мешали Вам, а наоборот, ПОМОГАЛИ. Это правильный путь.

4. Правила — это не икона, на которую надо молиться. В данном случае следует руководствоваться здравым смыслом.

5. Вы освоили ИС Дракон Тышова. И хотите приспособить этот инструмент для решения Вашей задачи. Считаю, что это вполне разумно.

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

7. В любом случае, окончательное решение — за Вами.

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

Отсюда и декларация через импер-схему...

Посоветовать что-либо здесь возможно только для редактора с алфавитом, поддающимся пользовательскому расширению и главное - со свободным построением схем - как разработка Митькина. Тогда можно воспользоваться, например, сказанным здесь: viewtopic.php?p=64737#p64737 - для некоторых случаев...

Имхо, для этого достаточно перечислить характеристики по пунктам:
1 .....
2 .....
........
N .....

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

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

Уважаемые друзья,
посмотрите пожалуйста на обновленную схему. Правильно ли я вас понял?


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

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

У Вас на схеме структурированные комментарии и некое действие в конце.
Причём прийти к этому действию можно только через весь этот структурированный комментарий из нескольких веток.
Тогда какой смысл разбивать комментарий на маленькие кусочки?
Если бы кусочки не были комментариями, а были условиями (как в первом варианте), причём условия предусматривали бы РАЗНЫЕ действия, а не выход в одну и ту же точку, в этом был бы смысл.

Сейчас правильнее сделать спецификацию требований отдельным текстом, а в алгоритм включить условие "удовлетворяет ли спецификации?". И не изобретать новый способ рисования текста только потому, что инструмент заинтересовал

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

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

Да, конечно.

P.S. Интересно было бы узнать, во сколько человеко-месяцев Вы оцениваете разработку ЕСР ...

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

А чё там думать - вот КУБ-система сделана за 20..25 человеко-лет (Усов говорил)... ВЛ-семредактор, как можно оценить - не больше. Желаемые возможности ЕСР примерно объединяют реализованное в этих двух системах... стало быть, примитивно применяя математику, берём прямое произведение (ну, здесь просто перемножаем )... и получаем 400..625 человеко-лет...
Если серьёзнее - то, конечно, при хорошем выборе среды разработки ЕСР (здесь не зря упомянута ВЛ-система) и концепции работы в ЕСР (а здесь уже не зря КУБ упомянут) можно, видимо, и быстрее сделать... тогда как если себя ограничивать в формах и средствах представления - не факт, что вообще получится что-то соответствующее этим требованиям...

Сами требования в целом вижу как отражающие ряд существенных вещей... вот только "Дракон" везде надо заменить на... ну, скажем: "проект[ирование]"...
Смысл этого можно уяснить по анализу требований Kori здесь: viewtopic.php?p=74438#p74438 - по сути, выявляется, что он тоже ЕСР хотел бы (и, как видно из темы, по которой хочет научную работу сделать, в том же направлении думает)...