Программные среды, снабженные протоколами

[Гость LisNerpa]

Не секрет, что сегодня многие программные среды снабжены протоколами.

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

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

Всем удач и, как водится, пряников.

[Гость LisNerpa]

:)))

Уважаемый ЧЕ!

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

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

Итак, представьте себе, что конструктору надо сделать кучу повторяемых действий. Например, на этапе закладки структуры сборки надо создать неск. десятков (сотен, а может - тыс.?) деталей при помощи одного шаблона, затем на их основе (пусть это некие базовые детали) создать подсборки, а затем все их собрать в сборку. Конкретный пример - хочется сделать модель здания с оборудованием. Каждое помещение хочется сделать деталью (стены, пол), потом втянуть его в сборку "Помещение" (чтобы потом наполнять оборудованием), а потом все эти помещения собрать в сборку "Здание" (возможно появление подсборок "Этаж"="Отметка").

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

Поскольку Вы, уважаемый ЧЕ, человек умный (только умный человек обладает чувством юмора), то Вы уже несомнено поняли, куда же я клоню (не путать с "клонированием"). Но, если Вам интересны подробности, то "Спроси меня Как?" (из надписей на модных значках).

Надеюсь, наша беседа небезынтересна.

ВСЕМ дальнейших удач и пряников.

[Che 0]

Итак, представьте себе, что конструктору надо сделать кучу повторяемых действий. Например, на этапе закладки структуры сборки надо создать неск. десятков (сотен, а может - тыс.?) деталей при помощи одного шаблона, затем на их основе (пусть это некие базовые детали) создать подсборки, а затем все их собрать в сборку. Конкретный пример - хочется сделать модель здания с оборудованием. Каждое помещение хочется сделать деталью (стены, пол), потом втянуть его в сборку "Помещение" (чтобы потом наполнять оборудованием), а потом все эти помещения собрать в сборку "Здание" (возможно появление подсборок "Этаж"="Отметка").

К чему столько лишних действий и такой нестандартный подход? Не проще ли сделать параметрическую модель?

И к тому же (IMHO) оборудование в зданиях (и сами здания рисвать тоже) лучше расставлять в системах типа ArchiCAD и ADT. Смысла просто не вижу в создании зданий как сборок в "машиностроительных" САПРах типа ProE.

[Гость LisNerpa]

(Перенес сюда из Флейма - ото там ему не место)

Эта запись в основном для поклонников Прохора (ProE).

Вот пример заготовочки файла-протокола, которая, будучи наполняемой каждый раз новым P_NAME, позволит Вам...

~ Select `main_dlg_cur` `MenuBar1`

1  `File`

~ Close `main_dlg_cur` `MenuBar1`

~ Activate `main_dlg_cur` `File.psh_new`

~ Input `new` `InputPanel1`

`P_NAME`

~ Update `new` `InputPanel1`

`P_NAME`

~ Activate `new` `OK`

!Command ProCmdModelNewExe was pushed from the software.

~ FocusOut `new_file_opts` `new_file_opts`

~ FocusIn `new_file_opts` `lst_template_names`

~ Select `new_file_opts` `lst_template_names`

1  `T_NAME`

~ Activate `new_file_opts` `psh_ok`

!20-Mar-03 12:59:47  Start C:PTCpro_stds_2001templatesT_NAME.prt

!20-Mar-03 12:59:47  End   C:PTCpro_stds_2001templatesT_NAME.prt

!20-Mar-03 12:59:47  Start Dir_PathP_NAME.prt.1

!20-Mar-03 12:59:47  End   Dir_PathP_NAME.prt.1

!%CIUsing C:PTCpro_stds_2001templatesT_NAME.prt as the template.

~ Activate `main_dlg_cur` `ProCmdModelSave.file`

!%CPEnter object to save  [P_NAME.PRT]

!%TR

!%CIP_NAME has been saved.

~ Select `main_dlg_cur` `MenuBar1`

1  `File`

~ Close `main_dlg_cur` `MenuBar1`

~ Activate `main_dlg_cur` `File.psh_close_win`

!Command ProCmdWinClose was pushed from the software.

!%CIBase window cannot be closed.

... проделать автоматически столько однообразной работы по созданию новой детали по одному шаблону, сколько надо. Для этого нужно иметь лишь список имен деталей, ну и средство, которым удобно генерировать протокол из повторяющейся части с заменой Р_NAME каждый раз новым именем из списка.

[Гость LisNerpa]

Для ЧЕ:

1. В ПроЕ любая модель - параметрическая, так что я не понимаю Вашего предложения.

2. Смысл дело высшее. Примерно, как политика. Но, предположите на минутку, что я обсуждаю не надуманную задачу, а ту, которую пришлось решать. Точнее в таком виде я ее для себя поставил, и таким способом подошел к решению.

3. Что до идеи революции, то Вы абсолютно правы. Однако я бы сказал, что "ее нельзя не осуждать". Т.е. каждая конкретная особь ОБЯЗАНА осуждать идею революции. Примерно так же, как Вы осуждаете сборку здания в ПроЕ.  Но Вы лишь предположите, что некто спроектировал в ПроЕ сложную установку, которая должна сидеть в здании. И что же - Здание в АрхиКад делать? А потом что куда передавать, чтобы соединить их в стремительном домкрате?

Дальнейших архикадных пряников Вам.

[GPN 3]

LisNerpa

:)

соединить их в стремительном домкрате

:)

Мне лично крайне приятно оценить Ваш юмор.

По сути поставленного Вами вопроса.

В ПроЕ я - ноль без палочки, но в том же акаде Вы можете проделать тоже самое: ведёте "history file", а затем лёгким движением руки превращаете его в "script file" и запускаете на повторное исполнение. Сразу же или предварительно произведя в нём лёгкие косметические измения.

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

неядовитый ляпсус в форме змеи :)

[Che 0]

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

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

Кстати по поводу соединения в стремительном домкрате :).

Интересно было бы знать, что в данном случае первично - конструкция или здание, если конструкция - то нет проблем, сваяли в PROe, сделали SAT или DWG или DXF или еще в что-нидь и в Архикад, а в нем быстренько сетку колонн вокруг агрегата, пол, стены, потолок, крышу, лестницы, коммуникации и вот вам - стремительный домкрат. Ассоциативности конечно никакой между импортированной SAT моделью в Архикаде и в Про-Е, но тем не менее при изменении модели в Прое, вы всегда сможете ее заново экспортнуть в Архикад и вставить в тоже здание.

(Отредактировал(а) Che - 16:27 - 23 Апр., 2003)

[Che 0]

:)

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

[Гость LisNerpa]

Уважаемый GPN,

конечно, то что я выставил на обсуждение, не панацея.

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

Пара разъяснений.

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

2. Я получил некоторые практические результаты, измысленных предварительно нестандартных отношений со средой. И эти результаты вошли составной частью в мою профессиональную деятельность.

Мне было бы интересно услышать от почтеннейшей публики:

1. Все, что она захочет сказать о таком подходе к использованию среды с протоколом, вплоть до простого нравится/не нравится, понятно/не понятно.

2. На какие еще среды, кроме названных ПроЕ и АКАД, можно распространить данный подход?

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

ВСЕМ дальнейших прянишных удач.

[Гость LisNerpa]

Да нет, ЧЕ, это Вы не поняли суть того, что я поставил на обсуждение.

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

А GPN понял...

:)

[Гость]

эээ... а чем это отличается от написания макросов?

[Che 0]

эээ... а чем это отличается от написания макросов?

Ну и я про тоже в принципе ... :)

[IBV 112]

    Не знаю что на эту тему есть в ПроЕ, но в UG есть встроенный язык, позволяющий писать свои приложения, используя возможности ядра системы. В ПроЕ наверняка тоже что-то подобное есть. По-моему этот путь позволит создать более гибкий инструмент.

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

[Гость]

IBV

не, наверно имелось немного другое.

LisNerpa наверно имел ввиду следующее:

1. Пользователь имеет схожий модельный ряд

2. Садится начинает строить первую деталь - программа(Про/е,Акад) записывает действия  пользователя на внутреннем языке - протокол

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

Данная функция реализована в очень многих программах. Даже в ворде :)

[IBV 112]

Это я понял, просто мне путь этот как-то не очень...

[Che 0]

А для чего тогда по вашему нужна параметризация?

Это просто один из нескольких способов облегчить (автоматизировать) труд конструктора, чтобы не ваять одно и то же по сто раз. Способов много, начиная с макросов, LISPов, VBA и других прелестей программирования, заканчивая параметризацией (которая придумана тоже для этих целей), адаптивностью и т.п., в том числе и протоколами, но это не есть панацея от всех бед.

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

[Гость LisNerpa]

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

NickeL - вот-вот.  Примерно эта Ваша комбинация из трех (пальцы не предлагать). :)

Так-с, значит третьим будет ВОРД. Хорошо хоть, что не за клинским его посылаем...

Кстати, граждане, я давно хотел спросить...

Вот пиво... Оно же... Ну зачем, ЗАЧЕМ народ водку с квасом мешает?

...

Хотя это, конечно, для флейма вопрос.

[IBV 112]

Che

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

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

[Гость LisNerpa]

ЧЕ...

Речь идет о том, чтобы заставить среду делать что-то (нужное, ясное дело!) в автоматическом режиме БЕЗ вникания в программирования и выборы в Думу. Интересно, что мне в голову эта мысль пришла после того, что я довольно много написал разных строчек кода.

А вообще...

Насколько сильно в данном форуме развита тема автоматизации конструкторских и других работ?

Я вижу, что это вызывает некоторый интерес. Граждане, он у вас перманентный или одноразовый?

:)

ВСЕМ - липисинов бочкотарами.

[Гость]

Речь идет о том, чтобы заставить среду делать что-то (нужное, ясное дело!) в автоматическом режиме БЕЗ вникания в программирования и выборы в Думу. Интересно, что мне в голову эта мысль пришла после того, что я довольно много написал разных строчек кода.

это не ново

как правило если не писать или редактровать код, то не во всех случаях это работает и этот вариант подходит как правило только для себя, имхо.

А уж каждый сам выбирает что и чем ему это делать.

Если же это спец задача для стороннего человека, тот тут вариант IBV почти идеальный.