DRAKON.SU

Уважаемый Владимир Даниелович,
Это действительно это так. Я полагал, что икона "Вставка" является неким вызовом подпрограммы с единым названием и разными передаваемыми и возвращаемыми параметрами...
Тогда следуя вашей логике я должен буду описывать несколько одинаковых вставок с разными названиями но с одинаковой структурой реализации? Я правильно вас понимаю?

БУДЬТЕ ПРОЩЕ — К ВАМ ПОТЯНУТСЯ

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

Что Вы сделали в ответ на замечание Эдуарда? Вы заменили икону действие на икону вставка. Но в данном случае это ничего не меняет. По сути дела, Вы, к сожалению, не обратили должного внимания на совет Эдуарда Ильченко.

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

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


Почему ОДИНАКОВЫХ вставок? Не одинаковых, а разных. Совершенно разных.
Почему с одинаковой структурой реализации? Этот термин здесь неуместен.

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

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

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

ВЫВОДЫ

1. Пустые слова (Поиск и обработка идей) не должны находиться на почетном месте внутри икон. Им вообще не место на дракон-схеме.

2. Главные слова (описание действий) нельзя выносить в комментарии. Они должны находиться не в комментариях, а на почетном месте. То есть внутри икон.

3. В обсуждаемой схеме дело поставлено с ног на голову. Незначащие (пустые) слова занимают почетное место. А главные слова (описание действий) изгнаны с почетного места и отправлены в комментарии.

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

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

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

Ну хорошо, уважаемый Владимир Даниелович,
спорить с Вами не буду. Посмотрите пожалуйста на исправленный вариант. Вы это имели в виду?

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

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

1. Желательно (если получится) полностью убрать левые комментарии.

2. В тех случаях, когда комментарии детализируют или поясняют действия в иконах.

3. При этом желательно не терять ВАЖНУЮ информацию из левых комментариев, а перенести ее в иконы. А НЕВАЖНУЮ инфомацию можно просто выбросить.

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

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

6. Сказанное не относится к правым комментариям.

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

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

P.S.
Может быть у Вас и уважаемых посетителей форума есть какие либо предложения и замечания по существу самих процессов?

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

По существу. Кое-какие слова уже были сказаны при развитии того самого жизненного примера, который использован в "Задаче на перспективу" - где-то отсюда: viewtopic.php?p=74750#p74750.

Постов (по ссылкам) было вроде два, но есть по крайней мере одна объединяющая их мысль. Она и разъяснялась там с разных сторон.

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

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

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

Ну и в общем включающая тема содержит кое-что интересное для предмета данной... в дополнение к основной...

Точно ошибся. Это был не КУБ, а СФЕРА : )

Да, она вроде как попроще - в то же время основа д.б. той же. Ну и можно, видимо, не только посмотреть - но и с демкой поработать...

А вот ещё ТЗ на среду поддержки : - открывал программу бывшего РТР-Спорт, но всё у них там, блин, переадресовалось... зато такой материал на этом месте в тему... Вот и подумайте - а где ЕСР будет востребована?..
Кстати, по другому адресу к этому посту есть и комменты... и там кое-что любопытное можно найти... Одно из важных - среда прозрачной поддержки должна использоваться в контексте "вывода из тени" деятельности тех ЛПР, кто ещё вменяем и не хочет дальше рубить сук, на коотором сидит... И об этом тоже стоит подумать...

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

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



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

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

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

Алексей Евгеньевич, разрешите скажу немного о схемах:

1. Т.к. у всех икон А, Б, П тексты пустые, то надо отключить их отображение, в меню "Вид" снимите галочку у пункта "А, Б, П тексты".

2. На схеме 1 измените вид иконы 15 с "Действие" на "Вставка" т.к. есть соответствующая схема. Для замены есть соответствующий пункт контекстного меню иконы.

3. На схеме 1 имеется икона 282 "Вставка", но на листе нет соответствующей схемы.

4. Схемы 2, 3, 4 помечены свойством "|", т.е. это схемы вставки. Можно установить тоже свойство у икон "Вставок" на схеме 1. Или совсем отказаться от пометки этого свойства, оно в основном нужно при программировании.

5. На схеме 4 есть неиспользуемые 2-а блока "Параллельных действий", их надо удалить.


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

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

Во-первых, смысл ЕСР можно уточнить, как сделал чуть выше: viewtopic.php?p=74934#p74934. Ибо есть уже единые системы поддержки управления предприятием, но не связанным с проектным производством. И есть отдельно единые среды разработки ПО - но ограниченные только этим, без интеграции управления. Единственным примером соединения, известным на сегодня, можно считать РТК-Микро, как он только что описан здесь: viewtopic.php?p=74955#p74955. Но в современных условиях это м.б. лучше делать иначе. Вот дальше расскажу, что думаю насчёт этого.

Во-вторых, отсюда и сказанное здесь по облику ЕСР как продукта: viewtopic.php?p=74620#p74620. Т.е. делать в концепции КУБа (ну или РТК-Микро) - но со встроенным "семантическим редактором".
Для начала правильно будет ограничиться созданием программной части только на языках высокого уровня - с выходом на внешние трансляторы. И обязательным д.б. создание и оформление руководств для человека - как операторских для заданной техники. Имея в виду, что изначально никакой автоматизации может не быть - стало быть, описываем ручную работу (возможно, механизированную). И уж потом постепенно выделяем из неё автоматизируемые части.

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

Отсюда описание деятельности сторон д.б. увязано с характеристиками этих мощностей. Причём доалгоритмическое является исходным, а алгоритмическое следует из него. Как - теперь описал здесь: viewtopic.php?p=75011#p75011. В уточнение того, что было сказано раньше: viewtopic.php?p=74833#p74833.

Для программ, также как и для материальных предметов разработки, нужны как схемные, так и текстовые описания. Причём общая логика д.б. как в ЕСКД. Как мне думается, разработчики семредактора нашли один из возможных балансов форм записи. И нужны описания с различных позиций моделирования. Всё это недавно постарался отразить в этой полушутливой зарисовке работы с приемлемым редактором: viewtopic.php?p=74873#p74873. Тут как критерии по форме моделирования, так и по его способу.

Чуть точнее по реализации модели было здесь: http://forum.easyelectronics.ru/viewtop ... 47#p204947. Там же некое распределение возможностей между исполнениями (принято два - обычное и профессиональное).

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

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

Однако именно начинал бы. Потому что лучший способ на деле совершенствовать ЕСР - вести в ней её же разработку. Недаром было сказано потенциальным потребителем недавно:
Kori в http://forum.easyelectronics.ru/viewtop ... 64#p203364 писал(а):
...
Кстати, а ИС Дракон можно сгенерировать полностью (без правки кода руками) в ИС Дракон?
- ну и как требование это выдвигалось и раньше... хотя бы здесь...

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

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

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

Уважаемый Геннадий Николаевич,
Спасибо за Ваши комментарии...
Снял...
Изменил...
Это та же процедура поиска на схеме № 3...
Убрал...
К моему великому сожалению я так и не смог удалить...возможно я просто не нашел правильной точки ввода для подобной операции...подскажите как это можно сделать? У меня удаляется либо вся схема, либо параллельное действие...

Не знаю, поможет ли... когда-то эти операции разработчик описывал так: viewtopic.php?p=41215#p41215.

Уважаемый Владислав,
Ваши предложения очень ценны...спасибо...
Приглашаю Вас продолжить нашу дискуссию в этой ветке.

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

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