Дмитрий_ВБ писал(а):
желательно, чтобы формализация алгоритмов проводилась специалистами-
предметниками, хорошо разбирающимися в своей области, но плохо разбирающихся
в программировании. Эти люди с высшим техническим образованием знают, что такое
блок-схемы, но у них часто нет ни времени, ни желания разбираться с дополнительной
терминологией описания блоков, введенной В.Д. Паронджановым.
С первой частью не могу не согласиться, а во второй, конечно, транслируется позиция заказчиков информатизации; предполагаю, что позиция Дмитрия необязательно с ней совпадает. Корни понятны: языки представления знаний относятся к конструктивным, а в то время, как обычно для постановки задач предметниками используются стихийные. Понимание различия между ними (см.
Фридланд, 2005, с.54-55; вкратце - стихийные языки возникают, конструктивные - создаются) не требует "высшего технического"; вполне достаточно "средне-школьной эрудиции"; в результате возникает желание, вроде бы вполне невинное - сделать язык под свои потребности/желания. А такое ли уж оно невинное?
Невольно пришёл на ум диалог из одной сказки:
"- Вообще хорошо, что вы пришли, вы поможете мне разрешить одну порблему. - сказал тролль Кумле.
- Надо говорить "проблема", не "порблема" - сказал Юн.
- Разве у нас в стране нет свободы? Разве мы не имеем права выговаривать слова так, как нам заблагорассудится?! - возмутился Кумле.
- А всё же слова надо произносить правильно - не уступал Юн.
- Ну хорошо, послушай сначала, о чём идёт речь, - ответил Кумле, - а как ты это назовёшь, это уж твоё дело." (Синкен Хопп. Волшебный мелок.//Сказочные повести скандинавских писателей. - М.:Правда, 1987. - с. 73)Конечно, здесь ничего личного - просто люблю иной раз иллюстрировать мысль художественными образами
А мысль такая - облик искусственной системы определяется целью её создания. Цель создания ЯПЗ (в частности, техноязыка) - дать формальную основу для взаимопонимания; если менять язык произвольно - отойдём от этой цели.
В данном случае цель подменяется, грубо говоря, такой: создать у предметников иллюзию, что можно без особых усилий формально выражать свои мысли. Как и в геометрии, в формализации "царского пути нет"
... как нет и "народного"... а вот "путь ДРАКОНа" есть, что не отменяет и иных, напр. "пути Оберона"... однако на любом этом пути от человека требуются умственные усилия на освоение языка. ДРАКОН сделан так, чтобы сократить эти усилия; но эта задача решалась не прямым учётом "желаний трудящихся", а учётом результатов изучения умственного труда. Недавно Рэйлвей Каген где-то
в этой теме подчёркивал, когда попытались голосовать по поводу различных предложений по мультишампур-расширению техноязыка: "коллеги, голосованием здесь ничего не решить"... притом что голосовать начали, по-моему, как раз в пользу его варианта
Вон недавно здесь обсуждалось решение СПбГУ и некоторых других вузов отказаться от обучения заочников - и потому, что они всё чаще учатся именно по принципу "разбираться, если есть время и желание". В то же время и когда "нет ни времени, ни желания разбираться", можно иногда заинтересовать, если судить по примеру
в этом сообщении. Ну и конечно, проблема решается в рамках повышения квалификации "без отрыва" - нужно проводить курсы непосредственно у предметника. Вообще образование на месте/дистанционно в ряде случаев, наверное, будет заменять заочное. В вопросах реинжиниринга обычно явочным порядком это дело возлагается на специалистов по качеству (если они есть)...
Вообще, какова суть информатики? Формальный анализ на формальном языке. А что такое "компьютер"? Формально-языковая машина. Там, куда приходит информатизация - становится нужным знание необходимого минимума формальных языков в дополнение к родному и профессиональным; и это д.б. закреплено изменением квалификационных требований по соответствующим (а при внедрении системы менеджмента качества/реинжигиринга - по всем) должностям. Проще можно сказать словами из "Аквариума": "не выучишь два языка - вылетишь <из Генштаба> на космодром Плесецк"
... а "Генштабом" ныне становится любая "конкурентоспособная" отрасль... Утешить предметников должно то, что ДРАКОН - не из худших языков описания деятельности
... я лично такие видел
Однако для ИТ-специалиста (напр., Дмитрия) это объективно "высокие слова" - он же, как я понимаю, не командует предметниками, а работает с ними "под общим начальством" (или согласно условиям договора с отдельной организацией-заказчиком - в данном случае несущественно) - и наверно, нужно подумать о том, как это "политически" провести в жизнь. Прежде всего, я думаю - подчёркивать то же, что и Паронджанов - ДРАКОН для предметников не является прогязыком - это просто способ не описывать, а рисовать то, что они делают/хотят сделать (поручить машине).
Далее нужно побудить руководство заказчика задуматься об организации всего ИТ-дела на основе интенсификации и языковой доподготовки. Что я думаю об этом по существу - изложил
в этом сообщении. Естественно, упирать следует на то, что это даст дополнительный экономический эффект (а в уме держа, что если начальство не оценит необходимости этих мер, то вся контора в условиях "инновационной экономики" в обозримом будущем скорее всего "вылетит в Плесецк"... и кто тогда будет тебе хорошие деньги за ИТ платить?...
).
Кроме того, формально-языковая база даже для предметников объективно меняется динамичнее, чем естественно-языковая (несмотря на все усилия изобретателей "заеца", ударений, СМС-ной "глснсти" и т.д.
) - вот хотя бы сейчас уже обсуждается расширение техноязыков для независимых процессов - и к этой перспективе (непрерывного языкового образования) людей тоже нужно готовить... осторожненько.
Здесь я всё больше о "кнуте" , но лишь потому, что "пряник" хорошо обозначил Паронджанов в своих работах. Разумеется, в практике внедрения нужно и разъснять людям достоинства нового языка, но из жизни ясно, что одной "пропаганды светлого" недостаточно - нужно и чётко ставить задачу с ограничениями, чтобы ум работал на её решение.
Дмитрий_ВБ писал(а):
Эти люди с высшим техническим образованием знают, что такое
блок-схемы, но... Для них ромб — это условие, а прямоугольник — действие.
О ромбах - прежде всего, на схемах в Драконографике и не только можно видеть, как плохо умещается там сколько-нибудь длинный текст... а предметнику ведь привычно формулировать условия, пожалуй, в виде текстовых вопросов... потом уже аналитик/программист превратит их в логвыры. Но и тогда эта форма неудобна и для записи/чтения текста, и для компоновки на диосцене.
Дмитрий_ВБ писал(а):
И зачем, с их точки зрения, придумывать что-то
еще ?
А правда, зачем столько икон разных? А затем, чтобы отразить структуру деятельности и облегчить как сочинение её моделей, так и мозговую проверку последних. Хороший пример этому родился "буквально вчера" - речь об
этом сообщении. Именно несоответствие графики некоторых икон И20 на схеме и их текста сразу обратило на себя внимание - а что это за сообщение другому процессу "Выдать"? вроде такого не было... А в результате оказалась ошибка - не тот оператор поставлен(см.
это сообщение).
Как сократить сложность начального восприятия большого алфавита операторов? Ну а как мы учим алфавит родного/иностранного языка? По букварю, однако
Вот и надо посадить предметников в рамках доподготовки прежде всего за азбуку техноязыка. Пример её можно найти
в этом пункте; безусловно, она может не подойти конкретному контингенту - тогда какие-то статьи нужно изложить по-другому (а некоторые иконы предметнику м.б. вообще не потребуются - их добавит аналитик/программист).
Дмитрий_ВБ писал(а):
Но хотя корни у псевдографики конечно же исторические, она послужила хорошим базисом для макетного варианта среды разработки ПО, позволив отбросить все, не
относящееся непосредственно к структуре алгоритма.
будучи сильно ограничен по времени и ресурсам, я должен выбирать
для реализации заведомо минималистскую модель системы разработки и документирования
ПО РВ.
Ну да, значит, ухватил я это дело
только подчеркну снова - это м.б. лишь прототипом (макетом-техзаданием) для внутреннего пользования программистов, дабы не нарушать интеллектуального взаимопонимания в среде пользователей. Искренне желаю побыстрее пройти этап "только псевдографики" и получить возможность делать полнографическую систему на нормальном алфавите... наверное, она будет иметь определённый потенциальный сбыт, что даст и дальнейшие ресурсы.
Дмитрий_ВБ писал(а):
либо
нормальный силуэт, либо конечный результат
на
Рис. 6, где не надо извлекать смысл переходов по петле силуэта из икон где-то внутри тела.»
Возможно, что так — тогда можно ввеси кнопку смены представления «примитив/силуэт».
Очень даже правильно... оператору надо давать побольше нужных настроек.
Дмитрий_ВБ писал(а):
В отличие от математики, или от программирования, или даже от
эргономических требований по созданию пультов управления,... ...в вопросе выбора
формы блока условия я за демократичное задание формы этого блока в файле
конфигурации, а упертость типа - «тут должны быть ромбы!» или «тут должны быть
Ну, тут я цитату оборву - почему, объяснил в документе, а если коротко - то по принципу "неназываемости неблагоприятного" (а Почепцов-то прав - вон как хорошо представления можно навязывать
). Чисто технически также согласен - почему бы не дать и такую настройку, но содержательно - не уверен... демократия это или анархия (см. сказку)?
Вообще сохранение двойственности/множественности обозначений ставит говорящих на языке в положение "Буриданова осла"... недаром при внедрении баз данных действует принцип единства банка - при актуализации очередной порции данных в новом банке старый (напр. в виде бумажных документов) уничтожается. Так и здесь - при доподготовке слушателям устраиваем "очные ставки" старых и новых конструкций, спрашиваем "Новая система обозначений понятна?" потом командуем: "Старое забыть, сочинять по-новому! (ать-два )". Конечно, реально "забывание" не будет происходить по мановению волшебной палочки ... но оно вообще возможно только при жёстком запрете на пользование забываемого.
По поводу отличия - Паронджанов показал, что закономерности восприятия зрительной сцены одни и те же, поэтому и "кнопки" (операторы) разного назначения должны различаться уже на уровне формы, и движение по ним д. б. минимизировано, а для этого построение маршрутов деятельности нужно согласовать с закономерностями чтения текста человеком. Я не могу опровергнуть эти соображения на той же почве (инженерной психологии), а на любой другой это будет
IMHO, некорректно.
Дмитрий_ВБ писал(а):
Разработка интерфейса для дракон-редактора — это обширная область, над которой еще надо хорошеньно поразмыслить — пока у меня нет определенных предложений на эту тему.
Да, в общем-то, нестрогий режим обсуждался, скажем,
в этой теме, и наверное, что-то новое трудно к этому добавить... Если обобщить, то гл. обр. нужно предоставить сочинителю возможность "таскать" концы лиан куда он хочет, причём, говоря языком "банальной эрудиции", редактор должен обнаруживать нарушение топологических отношений перемещаемой лианы с остальными. А проще можно изобразить... допустим так:
Вложение:
Комментарий к файлу: Принцип пересадки лианы (в условном окружении).
Nestr_peresadka.pdf [99.48 КБ]
Скачиваний: 525
В правилах здесь в основном заложен строгий режим. Наверное, правило П2 здесь можно ослабить - не запрещать присоединение к горизонтали правее доминатора данной лианы, а создавать выше этого места излом (вводить в горизонталь вершину типа "излом вниз"), а в точке присоединения - древесную точку слияния (лиана идёт к ней слева; до этого написал здесь не то ).
Также для нестрогого режима, видимо, можно ослабить ограничения на образование цикла посредством пересадки - только надо запрещать пересечение петель циклов. Это соответствует общей формулировке запрета на образование второго входа в цикл - маршрут не может входить в данный цикл, если его начало не лежит также внутри этого цикла. Отсюда и принцип обнаружения - как только потащили лиану из контура существующего цикла, где она берёт начало (а равно в контур, где она начало не берёт) - фиксируется ошибка.
Ну и можно допустить пересечение лианы с другими вертикалями - как временное (реализация предложена в МШ-методе).Возможны варианты исполнения:
1) Редактор сразу по ходу перемещения (пока рисует "резиновую линию" лианы) отвергает нарушение;
2) Редактор отвергает нарушение после команды сочинителя на завершение операции.
То и другое, безусловно, ресурсоёмче, чем в строгом режиме, но наверное, случай 2) несколько проще; так работает DesignIDEF в режиме контроля грамматики дуг. Правда, лучше при этом указывать конкретные нарушения - пользователю понятнее.
P.S. Говорить по поводу сомнений в научности, вероятно, здесь оффтопик; свои соображения вынес
в это сообщение (не знаю, подходящая ли тема... возможно пора создать что-нибудь отдельное типа "Организация и экономика информатизации"
).