OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Пятница, 13 Декабрь, 2019 05:18

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 679 ]  На страницу Пред.  1 ... 24, 25, 26, 27, 28, 29, 30 ... 34  След.
Автор Сообщение
 Заголовок сообщения: Re: Семантический редактор
СообщениеДобавлено: Среда, 12 Сентябрь, 2012 12:45 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Среди типов основных схем программы как требующий наибольшей проработки при текущем состоянии дел видится схема объявлений. Среди вспомогательных типов - схема зависимостей в принятой парадигматике (классов для ОО, функций для ФП, правил для ЛП). М.б. уже есть решения (для того же редактора)?..


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Семантический редактор
СообщениеДобавлено: Среда, 12 Сентябрь, 2012 14:40 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8215
Откуда: Троицк, Москва
Сергей Прохоренко писал(а):
Кто не сдал все лабы, к сессии не допускается, а потом вынужден ходить на платные дополнительные занятия для подготовки к экзаменам.
Финансовые потери -- один из самых доходчивых аргументов :)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Семантический редактор
СообщениеДобавлено: Четверг, 13 Сентябрь, 2012 05:56 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Это да... только нужно также дать и направление, как их избежать. :)
Язык, допустим, пущай сами осваивают - но при этом среда выдаёт каждую конструкцию/элементарный оператор/бибфункцию именно в виде, аннотированном по Лаптеву (с утверждениями обобщёнными - и с неформальными комментами, отражающими условия употребления, ну и конкретизации утверждений). И будет элемент того самого "включения учебника в среду", о котором Сергей говорил...

А вот технологию "говорения" думаю, для начала лучше зафиксировать. И тут ясно становится, что роли рабочих мест не сводятся к правам чтения/записи тех или иных частей проекта. А именно включают и назначение на работы.
И вот для каждого вида лабы делается типовой техпроцесс выполнения. К каждой техоперации которого определён комплект исходных данных и результатных. Вплоть до имён файлов. Тот же чекер, который подразумевается здесь, может проверять работу (по тем самым встроенным логам).
    Техпроцесс расписан в среде (как и положено, для условных РМ-юзеров). При выдаче задания его техоперации назначаются на РМ, как препод решил. Каждое РМ в среде - это роль исполнителя (юзерпрофиль среды), которая создаётся заранее для реального студента. Хочет препод бригаду - для каждого участника указывает, кто за какой участок ТП лабы отвечает. Индивидуально - значит, все ТП назначаются на одно РМ (профиль). И каждой ТО - сроки исполнения. И функции планирования (от норм времени - для начала опытных) и контроля назначенных работ.
Своё задание для начала надо повторить без изменений (скорее всего надо допустить сдвиг промежуточных сроков - при соблюдении завершающего). Но всё можно посмотреть в среде (примерно как в КУБе - схему ТП, свои назначения, содержание ТО). Вот вам ещё одна составляющая учебника (ну, методы по лабам можно, конечно, писать и издавать - т.к. пока что это критерий администрирования в вузе :wink: - но и тут среда может, скажем, макет собирать из каталожных заготовок и подстановок реальных заданий в их трафаретные поля - всё преподу помощь :))...
    Можно не запрещать произвольную (помимо среды) запись в базу проекта - тогда, если организация файлоцентричная, в принципе можно создать все файлы по лабе как пустышки (хотя бы в Блокноте) и закатать на положенные места - и думать, что обманул систему (при БД-центричном проекте, очевидно, придётся изучать организацию БД)... :wink:
Но. Чекер должен проверять формат файлов (в среде же он определён, как и любой пользуемый синтаксис) - и ругаться на несоответствие. И всё в подведение итогов для оценки/консультаций идёт... и высылается преподу (для которого тоже роль есть)... :)
    Да, кстати, у одного Петрова (да-да, того самого... только студента :wink:) как и у мастера (Лаптева, Грачёва etc :)) м.б. более одного рабочего места - в институте, дома, путевой (десктоп/ноут/планшет)... и условия доступа с каждого (очевидно, на сервер) прописаны. Так что поставил везде среду (с соответствующей лицензией) - и работай... Через сервак синхронизируешься (распределение работ упрощает дело - каждый там ждёт результатов от предшественников и забирает свои сэйвы сделанного на предыдущем РМ, а препод вообще только отслеживает/указывает :)).

Вот на такой основе можно переходить от бирюлек к работе... и вводить связь с промышленностью... :) Так что это только кажется неким идеалом... хотя реально не будет построено сразу. Но к этому уже можно привлекать студентов - и курсовые (а отчасти и те же лабы) наполнять реальными задачами достройки среды. Которые, начиная с какого-то уровня реализованности сказанного выше, планируются и организуются через саму же среду...
    А мотивация - да, и такая, и тоже чётко в среде прописана. К сожалению, вознаграждения за конкретную учебную работу вуз студенту платить не может... :) но некий род наряда на неё всё равно должен в среде вестись... просто в этой графе нули будут... с объяснением законодательных причин... :) А вот в графе штрафов - реальные тарифы д.б. заложены... чтобы студент свою выгоду видел... :wink:
Однако и пряник надо довести. Допустим, в виде указания, что возможны и ненулевые вознаграждения... за промышленную работу. И д.б. в справочниках среды прописаны (и легко доступны) критерии оценки (та же самая evolability, о которой Info21 писал). Откуда критерии? А от той самой московской и прочей "мафии", например... они же как-то с прогерами рассчитываются... :wink: Ессно, т.к. их много - то и систем оценок м.б. не одна... И у студента д.б. возможность "обсчитать" для примера даже и любую лабу (в той системе, где есть все критерии для "абстрактной выводиловки")... и почесать репу на предмет "а не добиться ли права получать такие реальные задания"?..
Разумеется, и на словах нужно это напоминать...

Тогда и студент (не каждый, но всё-таки), попробовав типовую схему на одной лабе, посмотрев, что из этого выходит, может прийти как-то к преподу и сказать: "- А дайте мне права на запись - хочу процесс выполнения лабы улучшить (новую функцию в библиотеку добавить etc)!". И тут есть повод задать обычные три вида рабочих вопросов: "Зачем?", "Что?", "Как?"... Чтобы:
Валерий Лаптев в viewtopic.php?p=74167#p74167 писал(а):
... по мере обучения "вожжи" можно отпускать.
:)

В то же время встаёт другой вопрос - а есть ли мотивация у преподов (в нынешней системе оценок от другой московской :wink:) организовывать и вести дело к такому результату?..


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 13 Сентябрь, 2012 07:14 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Вот что, например:
PSV100 в viewtopic.php?p=74686#p74686 писал(а):
...
Могу также сказать, что если у программиста отбирают удобство эмакса, вима, JEdit, Sublime, то должны быть серьёзные основания, это только Майкрософт или какой-нибудь Оракл смогут "нагнуть" под любую платформу, любой степени убогости :)
...
А большие кружочки не по ГОСТУ, как "дизайнерский ход", можно взять на вооружение. Короче говоря, в потенциальном редакторе должны быть настройки для всего: диаметр вершин, толщина линий, тип стрелок, шрифты и пр., в т.ч. и поддержка "чертёжного" стиля.

Кстати, если кому нужны чертёжные шрифты, то обращаю внимание, что появился OpenGostFont.
- м.б. есть понимание, так это насчёт удобств и если нет, то почему... :)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 13 Сентябрь, 2012 09:32 
Аватара пользователя

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 778
Откуда: Москва
Владислав Жаринов писал(а):
А вот в графе штрафов - реальные тарифы д.б. заложены... чтобы студент свою выгоду видел...


Я против. У студентов в их возрасте и социальном положении еще нет правильного отношения к деньгам. Деньги будут браться из родительского кармана без малейшего угрызения совести. Не все родители одинаково богаты. Стандартная ситуация, когда ленивые инфантильные юноши, не желая попадать под родительскую "опеку", просто плюнут на учебу. Мозги-то еще сырые. За разгильдяйство студенты должны расплачиваться повышенной учебной нагрузкой, повторением плохо усвоенного материала, пересдачами лаб и тестов (как можно раньше в течение семестра) и зачетов, посещением дополнительных занятий, заданиями на каникулы. Наоборот, за успехи должны следовать баллы, приближающие зачет "автоматом". И родители должны видеть в онлайне все "успехи" своих отпрысков.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Семантический редактор
СообщениеДобавлено: Четверг, 13 Сентябрь, 2012 09:54 

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 3124
Откуда: Астрахань
Info21 писал(а):
Сергей Прохоренко писал(а):
Кто не сдал все лабы, к сессии не допускается, а потом вынужден ходить на платные дополнительные занятия для подготовки к экзаменам.
Финансовые потери -- один из самых доходчивых аргументов :)

Вот не помогает! В этом году даже летнюю школу устроили - по 3500 за дисциплину. Бесполезно! Как не делали - так и не делают.
Выгнать 5 человек - невозможно, так как группу расформируют. Мне-то пофигу, а вот завкаф и директор института - те резко против.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Семантический редактор
СообщениеДобавлено: Четверг, 13 Сентябрь, 2012 09:57 

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 3124
Откуда: Астрахань
Владислав Жаринов писал(а):
[...]
Тогда и студент (не каждый, но всё-таки), попробовав типовую схему на одной лабе, посмотрев, что из этого выходит, может прийти как-то к преподу и сказать: "- А дайте мне права на запись - хочу процесс выполнения лабы улучшить (новую функцию в библиотеку добавить etc)!". И тут есть повод задать обычные три вида рабочих вопросов: "Зачем?", "Что?", "Как?"... Чтобы:
Валерий Лаптев в viewtopic.php?p=74167#p74167 писал(а):
... по мере обучения "вожжи" можно отпускать.
:)

В то же время встаёт другой вопрос - а есть ли мотивация у преподов (в нынешней системе оценок от другой московской :wink:) организовывать и вести дело к такому результату?..

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 13 Сентябрь, 2012 10:21 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8215
Откуда: Троицк, Москва
Сергей Прохоренко писал(а):
Мозги-то еще сырые.
Чётто у каких-нибудь американских студентов они не настолько сырые.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 13 Сентябрь, 2012 11:07 
Аватара пользователя

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 778
Откуда: Москва
Info21 писал(а):
Сергей Прохоренко писал(а):
Мозги-то еще сырые.
Чётто у каких-нибудь американских студентов они не настолько сырые.


А я читал, что такие же. С Computer Science на младших курсах вылетает треть, если не больше. Да и кино рисует ту же картину: сомнительные развлечения на первом месте. Хотя студентами там становятся в более старшем возрасте. В престижных вузах ситуация лучше, но она и в российских престижных вузах лучше. Не стоит думать, что в Америке вода более жидкая, а люди взрослеют раньше.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 13 Сентябрь, 2012 15:23 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8215
Откуда: Троицк, Москва
Сергей Прохоренко писал(а):
Не стоит думать, что в Америке вода более жидкая, а люди взрослеют раньше.
Ну, я основываюсь на личных наблюдениях.

Американская молодежь все-таки менее инфантильна.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Семантический редактор
СообщениеДобавлено: Пятница, 14 Сентябрь, 2012 09:40 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Валерий Лаптев в viewtopic.php?p=74714#p74714 писал(а):
Владислав Жаринов в viewtopic.php?p=74704#p74704 писал(а):
[...]
Тогда и студент (не каждый, но всё-таки), попробовав типовую схему на одной лабе, посмотрев, что из этого выходит, может прийти как-то к преподу и сказать: "- А дайте мне права на запись - хочу процесс выполнения лабы улучшить (новую функцию в библиотеку добавить etc)!". И тут есть повод задать обычные три вида рабочих вопросов: "Зачем?", "Что?", "Как?"... Чтобы:
Валерий Лаптев в viewtopic.php?p=74167#p74167 писал(а):
... по мере обучения "вожжи" можно отпускать.
:)

В то же время встаёт другой вопрос - а есть ли мотивация у преподов (в нынешней системе оценок от другой московской :wink:) организовывать и вести дело к такому результату?..

Именно к подобной среде я сремлюсь. Работы - выше крыши.
Преподы, которые будут ПОСЛЕ нас, получат уже наработанный вариант, который смогут изменять, обновлять, достраивать под себя.
Отлично! Тем более, что не только Вы с коллегами - что видно, скажем, здесь: viewtopic.php?p=74738#p74738.

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Семантический редактор
СообщениеДобавлено: Пятница, 14 Сентябрь, 2012 12:28 

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 3124
Откуда: Астрахань
1. Естественно, мы начали с того, что ближе нам: с начального обучения программированию (императивному). Стимулировали нас два проекта: КуМир и Школьная сборка Ткачева. Но идеи зрели давно. Особенно идеи включить в обучающую среду автоматизацию оценивания - это я думал давно и идеи вынашивал давно. Тут много работы, но начало есть. Например, мой аспирант защитил диссер по оценке качества объектно-ориентированных проектов. На основе метрик с помощью нечетких нейронных сетей Ванга-Менделя можно хоть как-то оценить качество. Там дело усугублялось текстовым представлением кода программы, а в семантическом редакторе сразу имеем семантическое дерево и соответствующие метрики много легче собирать. Можно и новые разработать - удобные именно для этого представление.
Более того, оценивание на основе сравнения с эталоном - это именно для учней использовать, а оценивание на основе измерений кода - тут и профессиональные проги можно оценивать (и курсовые тоже, между прочим... :) )
2. Одновременно сейчас у меня пацан уже 3 курса делает среду по автоматам. Начал с конечных, но задача поставлена: включить UML и Дракон (для рисования автоматов в этих нотациях) с генерацией кода из схемы. Потом соединим с семантическим редактором - получится совсем хорошо.
Надеюсь, он не пойдет зарабатывать деньги, а останется в магистратуре и аспирантуре... :)

3. Основной разработчик не собирается останавливаться на обучающей среде. Сейчас две девочки 4 курса озадачены сделать к концу семестра сайт, на котором начнется обсуждение всех идей и реализаций. ИМХО профессиональная версия должна обязательно иметь конвертер с один-два промышленных языка: в ветку С-подобного синтаксиса и ветку Паскале-подобного синтаксиса. Это должно произойти в следующем годе.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Семантический редактор
СообщениеДобавлено: Пятница, 14 Сентябрь, 2012 16:25 
Аватара пользователя

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 778
Откуда: Москва
Валерий Лаптев писал(а):
1. Естественно, мы начали с того, что ближе нам: с начального обучения программированию (императивному). Стимулировали нас два проекта: КуМир и Школьная сборка Ткачева. Но идеи зрели давно. Особенно идеи включить в обучающую среду автоматизацию оценивания - это я думал давно и идеи вынашивал давно. Тут много работы, но начало есть. Например, мой аспирант защитил диссер по оценке качества объектно-ориентированных проектов. На основе метрик с помощью нечетких нейронных сетей Ванга-Менделя можно хоть как-то оценить качество. Там дело усугублялось текстовым представлением кода программы, а в семантическом редакторе сразу имеем семантическое дерево и соответствующие метрики много легче собирать. Можно и новые разработать - удобные именно для этого представление.
Более того, оценивание на основе сравнения с эталоном - это именно для учней использовать, а оценивание на основе измерений кода - тут и профессиональные проги можно оценивать (и курсовые тоже, между прочим... :) )

С метриками можно "закопаться". Уж больно это субъективный подход, сильно зависящий от качества модели оценки и начального набора параметров. Знаю это по собственному опыту - сам занимался нейронными сетями. Существует более жесткий способ оценивания: прохождение множества (всех!) последовательных тестов на основе выданных заранее тестовых данных. Тесты могут быть на скорость выполнения, на объем используемой оперативной/дисковой памяти, на обработку некорректных данных или отказов, на обработку объемных, разнотипных или сложных данных, на использование/неиспользование каких-то библиотек, конструкций и т.п. в коде, на отсутствие предупреждающих сообщений компилятора, отсутствие утечек памяти и т.д. Тестовые задания могут требовать последовательного изменения программного кода, что проверит студента на способность создавать код, пригодный к рефакторингу и существенным изменениям. В МАИ задания конкретизируются и даже изменяются уже в ходе выполнения (обычная практика, когда заказчик/преподаватель не знает точно, чего хочет), тесты обычно заранее неизвестны студентам, а сообщения тестирующей программы, которые сообщаются студентам, лаконичны и требуют творческой интерпретации.

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

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

Валерий Лаптев писал(а):
2. Одновременно сейчас у меня пацан уже 3 курса делает среду по автоматам. Начал с конечных, но задача поставлена: включить UML и Дракон (для рисования автоматов в этих нотациях) с генерацией кода из схемы. Потом соединим с семантическим редактором - получится совсем хорошо.

А не хотите сделать сниппет конечного автомата прямо в структурном редакторе (как многоветочную конструкцию наподобие "длинной" формы условного оператора)?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Семантический редактор
СообщениеДобавлено: Пятница, 14 Сентябрь, 2012 20:31 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
А почему бы и нет?..
Но юмль-то здесь упомянут, наверное, в "математическом" смысле - т.е. речь идёт не об очередном его "прецизионировании до экзекутабельности"?.. А о поддержке автоматного графа как формы спецификации задач в редакторе... с дальнейшей генерацией программы (маршруты которой м.б. представлены как вариант дракон-схемами)?.. И с учётом известного о снятии неопределённостей для алгоритмизации - что обсуждалось, допустим, здесь: viewtopic.php?p=71826#p71826?..


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Семантический редактор
СообщениеДобавлено: Пятница, 14 Сентябрь, 2012 20:37 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Валерий Лаптев писал(а):
...
3. Основной разработчик не собирается останавливаться на обучающей среде. Сейчас две девочки 4 курса озадачены сделать к концу семестра сайт, на котором начнется обсуждение всех идей и реализаций. ИМХО профессиональная версия должна обязательно иметь конвертер с один-два промышленных языка: ...
Да, и смысл в том, чтобы иметь средства для разработки в среде и того же сайта... и для начала самой среды.

Именно поэтому здесь: viewtopic.php?p=74620#p74620 обсуждалось в таком смысле...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Семантический редактор
СообщениеДобавлено: Суббота, 15 Сентябрь, 2012 06:12 

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 3124
Откуда: Астрахань
Владислав Жаринов писал(а):
А почему бы и нет?..
Но юмль-то здесь упомянут, наверное, в "математическом" смысле - т.е. речь идёт не об очередном его "прецизионировании до экзекутабельности"?.. А о поддержке автоматного графа как формы спецификации задач в редакторе... с дальнейшей генерацией программы (маршруты которой м.б. представлены как вариант дракон-схемами)?.. И с учётом известного о снятии неопределённостей для алгоритмизации - что обсуждалось, допустим, здесь: viewtopic.php?p=71826#p71826?..

и УМЛ и Дракон - это стандартные средства представления конечных автоматов. Ничего специально изобретать не придется. С драконом я меньше знаком, а в УМЛ просто есть диаграмма состояний - непосредственное изображение конечного автомата.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Семантический редактор
СообщениеДобавлено: Суббота, 15 Сентябрь, 2012 10:26 
Аватара пользователя

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 778
Откуда: Москва
Валерий Лаптев писал(а):
в УМЛ просто есть диаграмма состояний - непосредственное изображение конечного автомата.

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

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


Последний раз редактировалось Сергей Прохоренко Суббота, 15 Сентябрь, 2012 17:36, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Семантический редактор
СообщениеДобавлено: Суббота, 15 Сентябрь, 2012 17:12 

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 3124
Откуда: Астрахань
Таблица переходов сделана с самого начала. И тут мы с окрября плотно садимся обсуждать реальные режимы работы и представления автоматов на экране. То есть начнется реальное проектирование уже техническое. Сейчас - только архитектурное и эксизное.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Семантический редактор
СообщениеДобавлено: Воскресенье, 16 Сентябрь, 2012 13:26 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Понятно. Т.е. нормальное математическое представление (как элемент спецификации) включать - а не весь конгломерат юмля тянуть... :wink:

Это актуально и в свете замечаний по ДРАКОНу. Например, того же Алмазова. Он на Спейсе как бы даже предубеждение к языку стал переносить на личности... :wink: Ну, лично для меня подобные вещи служат не к дискуссиям со столь же неотразимыми аргументами... :) - а к дополнительному анализу позиции собеседника. И вот что можно сказать по существу. Он именно предпочитает формализацию математическую (автоматного графа), считая, что информатизация делает модель плохой - и текстовая тоже. Понимая, конечно, что без этого нельзя, если хотим автомат реализовать технически... :) Но как бы лучше, чтобы человек с программно строго формой дела не имел.
    В принципе у меня к такому подходу нет возражений. Однако генерить автоматную программу в общем случае алгоритмически м.б. невозможно. Вот это можно, во-первых, обдумать. Во-вторых, человеку код, как и Сергей говорит, представлять в той же структурной форме. Не отвлекая ресурсы на реализацию полноценного "слепыша" (и всё равно только для маршрутов алгоритма - а для деклараций и исполнителя что-то другое придумывать придётся). Который ещё и компоновать на диосцене сложнее, чем структурные скобки...
Высвободившиеся т.о. ресурсы ВЛ-группы направить же именно на расширение возможностей автогенерации программ по автоматным спецификациям. :) Кстати, и на продумывание структурных деклараций, представления исполнителя...
    Полноценные схемы же оставить для "представления неявного" прежде всего. И стараться при определении их синтаксиса учитывать опыт материальных схем (по ЕСКД/ЕСТД)...
В частности, схема исполнителя, на мой взгляд, в основном м.б. такой, как у Поликарповой и Шалыто описана. Т.е. по понятиям юмля - "диаграмма кооперации+размещения". :) Реально - граф АРМов, машинной части каждого из которых сопоставлена инсталляция разрабатываемого продукта, человеческой - инструкции пользователя/сервисника/админа.


Есть и ещё одна сторона дела. Спецификации-то м.б. и не автоматными. Вот есть модельные программы для систем процессов. Автоматы там внутрях (скажем, для описания протоколов взаимодействия) м.б. полезны. Но сами целевые действия не обязательно к ним сводить удобно.
    Речь прежде всего о том, что в этом посте: viewtopic.php?p=74833#p74833. Программный продукт м.б. представлен как система техпроцессов на координируемых исполнителях. В таком виде спецификация может и проверяться - для анализа реализации техпроцессов. Приблизительного на практике, как правило - ибо у того же метода проверки моделей ограничения есть - но необходимого. Дабы добиваться результатов, описанных, например, здесь: viewtopic.php?p=73812#p73812 - и максимально исключать вещи вроде представленных в теме рядом.
Хорошая аналогия с материальным продуктом, думаю, здесь: http://forum.easyelectronics.ru/viewtop ... 48#p198848. Там выводы в посте интересны.
    Чтобы не реализовывать ещё и верификатор (тем более при наличии доступных) :), надо бы реализовать язык спецификаций для внешнего (м.б. не одного). И вот тут задача того же типа, что ваша группа и решала - выделить "ядро" для разных языков, сделать нотацию для него и для диффов, включить в среду системно с языками кода. Ну там, понятно, реализовать обмен данными. Но главное - определить соответствие понятий специф-языка и кодового. Так ведь?..
В общем, основная идея - специфицировать не только утверждениями про конструкции. А прежде всего - моделями смысловых единиц кода. И эти модели, конечно, также структурно[-графически] представлять - единообразно с моделируемыми программными единицами.

И здесь важно ещё - как связать спецификацию и реализацию. Лучше бы однозначно - так, чтобы было видно, какие понятия кода чем специфицированы.
    Некий подход был здесь: http://forum.easyelectronics.ru/viewtop ... 47#p204947 - но надо ставить в соответствие в редакторе конструкции и неравнообъёмные, и не всегда, быть может, точно совпадающие по смыслу. Стало быть, эти различия разработчик тоже должен описать (сколь возможно математически).
В общем, желательно поддерживать набор формул в самом редакторе. И нужно иметь переключение между спецификациями и реализациями - и, наверное, возможность совместного показа... Какие будут мнения?..


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Семантический редактор
СообщениеДобавлено: Среда, 19 Сентябрь, 2012 09:56 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Кажется, понял... перечитывая Новикова... ну и с учётом некоторых других других источников отсюда: viewtopic.php?p=73665#p73665. При этом то, что формализовано, в данном случае плюс - помогает построить "систему языков". Как обычно, идём от моделирования/формализации по Леонтьеву-Грековой-Фридланду.

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

Так вот, значит. Открыл редактор и создал структуру. Под именем, которое дал своей модели (задачи, предметки). Будет, само собой, интегрированный документ типа "проект" (в смысле сказанного здесь: http://forum.easyelectronics.ru/viewtop ... 47#p204947).
Выбрал язык "родной", организацию "линейная" - открылась трёхколонная вьюшка. Уже обсуждалась - кому надо, может найти подробно - а что важно, далее напомню.
    В правой колонке (напомню, она у нас "качественная" в терминах Грековой - т.е. комменты для человека, "неявно поощрённого к незнанию математики" ((С) borix)) пишет при начале структуры своё Дано, при конце - своё Надо. Это структурно как пред- и постусловия - только в свободной форме. Между ними - в общем как коммент в целом к структуре - излагает идею решения. Стараясь придерживаться ограничений структурированного ЕЯ.
    В левой колонке (она у нас математическая) пишет то же самое, но логически обоснованно. Т.е., формулирует Дано и Надо как соотношения между матемобъектами, а между ними - доказательство решения в целом. Как у Новикова для алгоритмов. Если сам из "неявно поощрённых" - то идёт за этим к коллеге-аналитику, владеющему математикой.
    В средней колонке (она "информатическая" в терминах уже Фридланда) на "родном" языке формализации предполагается псевдокод. В структурных скобках, само собой... и на национальном языке. Сам построитель пишет там что-то - например, как результат пошаговой детализации.
    В результате псевдокод может получиться в такой форме, как у Новикова - но разумнее предположить, что как у Вирта или Потопахина в "Решении сложных задач" - т.е. на "родном" ТЯС. Щаз объясню, почему.

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

Качественный переход здесь прежде всего будет связан с выбором системы абстракций задачи (предметки). В общем, парадигмы информоделирования (программирования машины, инструктирования человека). Бодаются по этому поводу много (на КЫВТ.рф, например :)) - а практический смысл в том, что часто надо с т.зр. более чем одной парадигмы на предмет посмотреть... :wink: И как же дать такую возможность нашему построителю?

Так вот. Теперь сочинитель посмотрел на это, подумал... и снова появился образ. Типа: "А вот как это можно описать в виде абстрактной программы!". Т.е. как раз в форме, принятой у Новикова (только не забывая про абстрактные типы данных - он не всегда их приводит, часто в силу тривиальности, иной раз - очевидно, ради сокращения изложения).
И тут он снова берётся за девайс (гаджет) с редактором, открывает тот же документ-проект. И создаёт там новую структуру. Под именем той же модели - но на "математическом" языке. Причём как вариант (среда это допускает). Почему, опять же дальше будет ясно.
Снова выбирает линейную организацию. Только теперь уже начинает, скорее всего, со средней колонки. Допустим, он придумал формализацию точно по Новикову - т.е. программу на математизированном импер-прогязыке. Вот её и записывает (только придётся при жёсткой структурности без явных БП и множественных выходов). Ну, к каждой строчке - связанный коммент в правой колонке - если надо. Левую оставил пустой (раз он у нас "неявно поощрённый" :wink:)...
    Причём здесь уже м.б. широко применена декомпозиция и иерархическая (на процедуры) и диспозитивная (на сопрограммы и пр.). Так что структура реально м.б. из многих других структур скомпонована... включая единицы каталога среды. Тогда в правой колонке для каждой структуры в целом он написал, на основании каких мнений считает возможным использовать (и из каких источников). Типа, "управленческое приложение Г-Ф" по смыслу выходит, короче... :)
Также, где надо, даются вычислительные процедуры - непрерывные и/или дискретные. Для чего составляется математическое описание предметки. Выбирается и логика управления решением - автоматная или ещё какая. В зависимости от идентифицированного рода поведения условной системы-решателя задачи - простое или зависимое от состояний. Общее описание или включается в модельную структуру, или помещается в охватывающий проектный документ.

Так получился вариант спецификации. Который можно показать руководителю работ. Если проект для "критической" предметки - то шеф посмотрит и скажет: "А чем докажешь? Вон разрабы не проверили как следует - видел, чего получилось?!". Если решение у Новикова (Вирта, Гриса, Дейкстры...) целиком списано - то можно и доказательства оттуда представить. :wink: Но обычно так не получается - используются наработки, которые по опыту/публикациям вроде как должны работать.
    Так что наш "сочинитель" (на полноценного построителя системы в смысле Усова он пока что не тянет) отвечает: "Так вот (показывает на своей структуре) - этот элемент по отзыву X в похожих условиях работает N1 месяцев нормально... а этот контора Y применяет N2 лет уже везде... а вот такое сочетание Z рассматривал в посте N3 на конференции R... вот все ссылки, можно посмотреть". На что шеф закономерно вопрошает: "Вы вообще-то понимаете, что это за проект?!... трам-тарарам?!! :wink: Идите и обоснуйте всё решение в совокупности! Не знаете как - вон Лаврова почитайте!".
И с этими словами вошёл в проект сочинителя в роли шефа (со своими правами доступа, стало быть), выбрал сетевой график проекта. Посмотрел нужный техмаршрут, уточнил отдельные техоперации в смысле сказанного (и/или новые добавил), сроки проверил. И активировал расширенное уведомление о ходе проекта - себе и сочинителю... чтоб жизнь мёдом не казалась... :)

Ну, пошёл сочинитель... в библиотеку/сеть... нашёл, почитал, как-то заполнил левую колонку для отдельных мест структур...
Принёс показать аналитику опытному - всё ли правильно и как дальше. Тот посмотрел и говорит: "Ну, тут нормально, здесь лажа... это обосновывается так... а это вообще только при таких допущениях...".
    Также просмотрел предлагаемую модель предметки, вычислительные методы и управляющие алгоритмы. Проверил Математику-2. Заодно и исходную модель уточнил.
Заполнил он всю математику, добавил кой-чего в комменты. А затем сказал: "Вот так примерно... но всё я доказать не могу... а кое-что вообще доказать проблематично." С тем и распрощались.

Решил сочинитель пойти ещё к другому аналитику. Тот почитал то, что уже написано. Потом задумался и говорит: "Слушай, а вообще-то зачем именно так проверять? Вон у меня стоит модел-чекер... сейчас составим модель, сформулируем требования... тебе чего проверить-то надо?..".
Читатель уже, возможно, догадался, что будет дальше. Правильно - открывает аналитик проект в инсталляции среды на своём АРМе из репоза конторы (или прямо на девайсе коллеги его локальную копию)... и создаёт там новую модель. :) Как другой вариант на своём "математическом" языке.
    В данном случае выбирается язык не "произвольного" рода - как все предыдущие - а "регулярного". Ибо это входной язык связанного со средой приложения, имеющий стандартное определение. Правда, как мы знаем (хотя бы из обсуждения грамматики Оберонов здесь и на Спейсе), оно м.б. не очень строгим...
    Ну, пусть чекер - это Спин, так что язык модели - Промела+логика требований.
И пишет аналитик своё видение каждого элемента модели, скомпонованной сочинителем, включая понимание связей между этими элементами. В средние колонки - Промела-исхтекст, в левые - формулы требований, в правые - свои объяснения. Прежде всего - по интерпретации качественного понимания задачи (оно у нас осталось в первой модели проекта, помните?). Т.е. почему "Мы придём к победе коммунистического труда!" записывается как "F Коммунистический_труд_победил!"... :) И, если его что-то не устраивает в качественном понимании - тоже пишет в комментах.
    При этом широко использует возможности среды по построению схем зависимостей элементов модели.
Написал - проверил - скомандовал трансляцию. Средний столбец превратился во входной Промела-файл (секцию единого - как там в чекере принято), левый - в *ТЛ-файл (секцию). Синтаксис реализован корректно - так что просто взяли файл[ы] и загрузили в чекер. Поработали с ними, нашли несоответствия, исправили кое-что в процессах/требованиях/комментах чекера. Загрузили обратно, указав среде обновить модель по входу. Она обновила - логировав, само собой. Возможно, сохранили прежнюю версию (или диффы - смотря какой принцип управления изменениями реализован).

Однако наш сочинитель решил подстраховаться. И пошёл к ещё одному аналитику. Тот посмотрел - и сказал: "Подождите-подождите... зачем здесь так? Я ясно вижу, как это можно реализовать композицией функций без побочных эффектов!". Что дальше? Правильно - создаётся ещё одна модель... теперь уже на функционально-математическом языке... :) Т.к. я по своей математической культуре недалеко от нашего главного героя ушёл :wink: - то не могу сказать абсолютно точно, как этот аналитик будет обосновывать её корректность - но понятно, что при принятой общей организации моделей результаты появятся в крайних колонках - а в средней будет сообственно функциональщина в нотации, принятой в среде. Чего там за синтаксис (и точная семантика за ним) будет - я тоже не знаю - вы, авторы редактора, решайте... :) я вот прагматику вам набросал... :wink:

Теперь у нашего героя голова совсем пошла кругом... :) И решил он... правильно... а очередной аналитик... правильно, сказал: "Эврика! Так мы же можем задать здесь предметную область через факты и отношения для исчисления предикатов первого порядка!". :) И дальше... правильно... новая модель... теперь уже на логико-математическом языке... например, на Прологе...
    Заодно проанализировал логику предметки и составил схему отношений (если редактор не позволяет из логпрограммы вытащить).
Т.к. опять же есть где исполнить (во внешнем приложении) - то туда и загружаем.

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

Ну а ещё один аналитик и объяснять ничего не стал - взял да составил структуру классов типа Эйффелевской... только вместо инвариантов составил N-мерную VMT, сказав при этом: "- Знаем мы эти инварианты классов...". :wink: Только без всякого юмля... примерно в той форме, как у Мейера и сделано...

    Ну и в качестве бонуса - выяснил у сочинителя, в какой оргструктуре эксплуатироваться будет, составил схему рабочих мест, выделил типы АРМов да набросал техпроцессы развёртывания и применения... :)

Но. Т.к. мы ещё не все возможности редактора рассмотрели - то волшебник Дед Секрет не хочет отдать нам предмет... в смысле, готовый продукт.... :) А говорит ехидно (устами шефа): "А откуда наши клиенты возьмут платформы для вашего кода?! Идите и пишите экзешники!" Снова вошёл в проект, набросал состав команды в части реализации, установил сроки. График-то работ уже задан как типовой - если что, шеф корректирует... при необходимости с командой советуясь...

И пошли теперь уже чисто прогеры работать... Но т.к. они не тупые кодеры - то тем, что уже было написано, не пренебрегают... :)
    Взяли, открыли каждый на своём АРМе проект в среде... посмотрели на всё уже написанное... подумали... разобрали специфицированные элементы модели по своим профилям в среде... и выбрали каждый свой прогязык. Всё равно же они в среде с общим семантическим ядром... :) так что как ни программируй, в пределе ЛИСП получится... :wink:
Написали... причём кто-то извратился мультипарадигменно (спецификации же разные есть :)), кто-то "экстремистски-объектно"... кто-то функциональщину закодировал императивно с динамическими структурами данных на одном из встроенных ЯВУ... кто-то переписал под внешний транслятор (используя механизм определения "произвольных" транслируемых языков)... ну и т.д...
    Сделали также руководства, сценарии развёртывания/обслуживания, где можно, автоматизировали.
И все снова пишут код, обоснования и комменты... правя при необходимости предметную и математические модели. А также - заимствуя готовое из каталога среды.

И вот тут что важно? В каталог включаются элементы не на основании чьего-то мнения в статье или в посте. А имеющие достоверные теоретические обоснования и подтверждённую практику применения. Т.е. по такому же принципу, что и конструкции деталей "их машин" ((С) Б. Мейер) и сооружений.
    И понятно, что показанная здесь форма должна облегчать документирование конструкций. А способы ведения документов в среде (прежде всего управления совместной работой и изменениями) - также и разработку конструкций.
Здесь важно понимать, что один элемент может иметь две и более разных реализаций. И на встроенных ЯВУ, и как произвольный текст (скажем, на внешних языках - хоть в кодах реальной/виртуальной машины). И в каждой он д.б. проверен - как и материальная деталь/сборочная единица. А язык/архитектура исполнителя кода - это вроде как материал детали. Их свойства обусловливают, что и как проверяем.

Причём речь не только о коде. Но и о спецификациях, кладущихся в его основу. И об архитектурных решениях - с т.зр. классификации, скажем, такой:
И. Ермаков в http://metasystems.ru/download/science/ ... 10-eie.pdf, Разд. II.4 писал(а):
...
    1) Инструменты программирования — языки программирования, окружения разработки и выполнения, библиотеки и программные каркасы (frameworks);
    2) Внутрипрограммные конструктивные схемы;
    3) Несущее программное обеспечение (middleware), которое обеспечивает выполнение, взаимодействие и управление в распределённых системах;
    4) Межпрограммные конструктивные схемы, применяемые в распределённых системах;
    5) Средства проектирования архитектуры, системного анализа, спецификации требований).
...
- т.е. двигаемся к принципам ЕСКД - не только виды схем по наполнению связей (электрика/гидравлика и пр. материальные, а в ИТ - данные) - но и типы схем по назначению.
    Потому и каждый пользователь (предметник, аналитик, программист) длжен иметь возможность оперативно получать и основные схемы моделей. и вспомогательные схемы, производные от содержания модельных единиц в их взаимосвязи. Скомандовал - появилась схема вызовов процедурами друг друга. Ещё - и схема обмена рандеву-сообщениями. Ещё - и схема порождения/снятия процессов (м.б. как частный случай конструкции/деструкции экземпляров представляющих классов). Ещё - и схема вводов/выводов. Ещё - и сохранений/извлечений.
    Раз - и АСД для средних столбцов превратились в АТ-схему типов... где мы и области видимости, и передачи параметров, и указательные связи видим нагляднее... ну а комменты/математика пошла как примечания к АТ-вершинам...
    И всё на отдельных вкладках, допустим...
И здесь поле применения исчисления графов. Не сводимого к маршрутным схемам само собой... Общая организация многих типов вспомогательных схем м.б. сходной и даже унифицированной. Конкретные же синтаксисы ещё надо определять.

И ещё. Модель на инфор-языке (программирования ВУ) можно рассматривать как реализацию какой-то из спецификаций на одном из математических языков. Но. В общем случае возможны заметные отличия. Может не совпадать и архитектура. Т.е. невозможно прямо сопоставить каждому специф-элементу один элемент реализации - или несколько, ведущих себя в модельной связке как один. И/или если и можно соспоставить - то принципы связи будут не эквивалентны. Т.е. реализация должна иметь своё обоснование (что и показано выше). Единственно что будет со всем структурно совпадать - это исходная постановочная модель на "родном" языке... она же без структурирования решения... :wink: Это весьма наглядно для случая проверки моделей - обычно такая модель весьма упрощает суть решения.

Ну и права доступа нужны, как мы видим. Можно предположить, что по умолчанию каждый должен видеть все спецификации и иметь возможность писать в их комменты. Далее всё настраивается.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 679 ]  На страницу Пред.  1 ... 24, 25, 26, 27, 28, 29, 30 ... 34  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 0


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
cron
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2019, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB