OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Вторник, 19 Март, 2024 08:07

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




Начать новую тему Ответить на тему  [ Сообщений: 42 ]  На страницу 1, 2, 3  След.
Автор Сообщение
СообщениеДобавлено: Суббота, 06 Ноябрь, 2010 06:25 

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

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

Геннадий Тышов писал(а):
Цель создания и.с. Drakon определяется 1-й книгой В.Д. Паронджанова "Занимательная информатика"...
Владимир Паронджанов писал(а):
2. Что касается алгоритмизации (понимаемой, в частности, как формализация собственных процедурных знаний), то эта задача может и должна быть предметом массового обучения.

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

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

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

У кого-то будут мнения на этот счёт?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 06 Ноябрь, 2010 09:45 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Драконограф писал(а):
В то же время есть люди, преподающие формализацию знаний школьникам и ссузовцам - тот же Илья Евгеньевич, например. Давайте спросим его как профессионально сориентированного на эту сферу (насколько я понимаю, Вы также информатику в школе не преподаёте) - давать "выжимки" из методов и средств формализации знаний или целостное (пусть слегка облегчённое - в т.ч. и за счёт когнитивно-эргономичной формы, и базирования на конкретном относительно синтаксически простом прогязыке) понимание информатизации как процесса, приводящего к формальному (относительно свойств принятого исполнителя), целостному и максимально проверяемому описанию...


Ну, моя специфика - это профильное образование. Программисты на базе СПО. Соответственно, баланс знаний иной, чем у непрофильников - не общие понятие об информатизации, а полная система знаний-умений-навыков программиста. На общие вещи информатики (со стороны информ. моделирования) мне часов в моих предметах не хватает (основы алгоритмизации и программирования; технология разработки программных продуктов, САПР, ПО компьютерных сетей - в первых 3-х я плюю на ГОСы и делаю единый курс программирования; на ПОКС изучаем основательно сетевое программирование и Веб-разработку - XHTML, CSS, PHP, JavaScript, Web-разработку в КП/ББ) . По идее, "информатизацию всякую" должны вести другие, у кого введение в предмет на 1 курсе, общий курс информатики,теория информации, БД, распределённые БД...
В раздумьях пока, как расходовать в этом году во втором семестре 52 часа Основ построения автоматизированных ИС. Там надо бы хороший прикладной курс, но опять же, часов мало; есть соблазн потратить на углубленные темы единого курса программирования. Ибо, рассуждая прагматически, общими словами их потом в ВУЗе накормят, а мне на выходе хорошие программёры нужны - этому их уже в ВУЗе не научат.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 07 Ноябрь, 2010 04:03 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Илья Ермаков писал(а):
Ну, моя специфика - это профильное образование. По идее, "информатизацию всякую" должны вести другие, у кого введение в предмет на 1 курсе, общий курс информатики,теория информации, БД, распределённые БД...
В раздумьях пока, как расходовать в этом году во втором семестре 52 часа Основ построения автоматизированных ИС. Там надо бы хороший прикладной курс, но опять же, часов мало; есть соблазн потратить на углубленные темы единого курса программирования. Ибо, рассуждая прагматически, общими словами их потом в ВУЗе накормят, а мне на выходе хорошие программёры нужны - этому их уже в ВУЗе не научат.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 07 Ноябрь, 2010 15:29 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Драконограф писал(а):
(хорошо, что можно не придерживаться ГОСов... не знаю, везде ли так :)).


В КТП и раб. программы вписано всё, как надо. Журнал по КТП тоже заполняется как надо. А как расходовать в реальности часы, я определяю сам... :)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 07 Ноябрь, 2010 15:38 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Драконограф писал(а):
...


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

Очень нужна наработка эталонного пути получения из новичка нормального инженера-программиста за 3 года; тогда потом можно на этот скелет "мясо" разное наращивать.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 09 Ноябрь, 2010 05:34 

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

Илья Ермаков писал(а):
Очень нужна наработка эталонного пути получения из новичка нормального инженера-программиста за 3 года;...
Да, наверное, раз инженеров - значит, постараться дать ещё и умение верифицировать формально, и выводить программу... часов на теорию и методы этого, конечно, может потребоваться даже при опоре на конкретные примеры :)
Я, как можно видеть, в основном размышляю о том, как подготовить непрограммиста, взаимодействующего с этим самым инженером-программистом - и так, чтобы "взаимно сокращать опыты быстротекущей жизни" :) за счёт лучшего "интеллектуального взаимопонимания". Имеется в виду "представитель заказчика" в части автоматизации/реинжиниринга. Кто этот специалист в организации заказчика (будем говорить о достаточно крупной - в малых всё ещё долго будет "точно по Михайлову", и тут пока трудно предложить альтернативу - впрочем, м.б. у кого-то есть иной опыт)? По опыту - чаще всего выделенный сотрудник/группа, лучше понимающие трудовые процессы оргсистемы; теоретически при наличии службы качества это д.б. её специалист-аналитик - но не секрет, что служба эта обычно занимается тем, что "рисует для сертификации" ;)
И эту ситуацию можно изменить - а заодно создать ещё один фактор привлечения/удержания серьёзных заказчиков - если предложить инструментарий, увязывающий задачи "реинжиниринга" с инженерным проектированием процессов.
И вот хорошо бы, чтобы он не только понимал процессы - но и мог ориентироваться в их автоматизированной реализации - чтобы и приёмка решения грамотно и без лишних трат времени/сил проходила, и в процессе разработки он мог оценить (по "человекочитаемой" модели решения), сохраняется ли соответствие нуждам, сформулированным в ТЗ, принять реалистичные корректировки и где-то, возможно, сам предложить сам иные требования - не "переламывающие объективных законов информатики", но более соответствующие задаче, как он её понимает с позиции заказчика. А для этого и нужно, чтобы программисты ориентировались на описание задач "по нейтральной схеме" в визуальной форме - но опять-таки, дабы не тратить время на "картинки, оторванные от реализации" - визуальный язык д.б. просто отображением прогязыка разработки (с возможностью выборочной детализации и/или определения вариантов непосредственно для узлов и/или компактных фрагментов схем - через вершины-области, как указано в этом сообщении - и вообще редактор должен поддерживать широкие возможности каталогизации, хотя бы перечисленные в связанном сообщении). Отсюда вытекают и следующие соображения.

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

А визуальная "нейтральная" модель становится существенной частью документации на изделие - в основном для разработчика, но также и для грамотного приёмщика - и для независимой экспертизы, если таковая потребуется (а вот взаимопонимание, между прочим, должно максимально способствовать исключению таких ситуаций)...
РДП-редактор, конечно, должен стоять и у разработчика, и у заказчика - только сотрудники последнего обычно пользуются лишь частью его возможностей (другие м.б. вообще "закрыты" настройкой).
    Конечно, "предметник" изначально будет описывать логику процессов на "родном" диалекте визуального языка - с неформальными текстами вершин - но структурно этот диалект должен предоставлять те же возможности описания, что и гибридный с прогязыком (параллелизм, исключения, ЦД и пр.). И визуализацию структур абстрактных типов - хотя опять-таки "предметнику" привычнее будет описывать алгообъекты через их "внешние схемы" (см. ниже).
    При этом исхтексты должны генерироваться как для прогязыка, так и для специф-языка, входного в среде инженерной проработки изделия - на конкретных стандартах можно увидеть, что и в части описания процесса специф-язык (конкретно - Promela) не обязательно точно совпадает с прогязыком (Оберон/АО) - а для верификации ещё нужно фиксировать требования на *TL-языках - и их тоже нужно визуализировать и включать в РДП-документ.
Собственно трансляция в исхтексты - чисто ИТ-профессиональная тема, но есть и вещи, связанные с тем самым взаимодействием и взаимопониманием представителей сторон разработки. В связи с этим, похоже, актуальны темы подготовки (и поддерживающие пособия) и по верификации, и по приведению решения к "доказуемой" форме. При этом подразумевается, что и грамотный "закпред" их сможет изучить - в идеале, конечно, на курсах организации-разработчика или её партнёра на образовательном направлении (вот и небольшая, но область для бизнеса ;) - а грамотные, в "когнитивно-эргономичной" форме пособия при распространении поспособствуют привлечению на курсы). И пользоваться - приводя внутри заказчика описания коллег к приемлемому виду (а постепенно и обучая сразу нормально описывать) и тем самым сокращая усилия разработчика (ну и свои затраты на эту часть процесса - если действует ценообразование от сложности разработки, конечно).

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

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

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

P.P.S. Кстати, для малых заказчиков, но вдруг вознуждавшихся в чём-то подобном (напр., если работают на субподряде у крупной конторы, которая решила ввести "аттестацию" партнёров) возможен путь опять-таки "ИТ-аутсорсинга" по принципу "централизованной бухгалтерии" - внешний подрядчик приходит и не только автоматизирует отдельные задачи, но и описывает бизнес процессы полностью своими силами. И ему опять-таки потребуется РДП-среда...


Последний раз редактировалось Владислав Жаринов Пятница, 12 Ноябрь, 2010 06:14, всего редактировалось 2 раз(а).

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 09 Ноябрь, 2010 13:44 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Драконограф писал(а):
Вот такие мысли. Прошу оценить - возможен такой подход, м.б. с какими-то изменениями?


Если честно, то Ваши тексты читаю фрагментарно, уж слишком объемён поток...
Вспоминается фраза из "17-ти мгновений весны": "Самые счастливые люди на земле те, кто могут свободно обращаться со временем". :)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 10 Ноябрь, 2010 06:02 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Илья Ермаков в viewtopic.php?p=53561#p53561 писал(а):
Очень нужна наработка эталонного пути получения из новичка нормального инженера-программиста за 3 года; тогда потом можно на этот скелет "мясо" разное наращивать.

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 10 Ноябрь, 2010 06:07 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Илья Ермаков писал(а):
...
Вспоминается фраза из "17-ти мгновений весны": "Самые счастливые люди на земле те, кто могут свободно обращаться со временем". :)

Это точно :) Хотя здесь скорее результат возможности сосредоточиться в данный момент на теме (и опыта взаимодействия с "разработчиками бизнес-объектов" и участия в "менеджменте качества") :)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 10 Ноябрь, 2010 11:31 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Драконограф писал(а):
в этом сообщении[/url], дадут что-то, если Вы с ними незнакомы. Скорее второй - первый больше для вузов с "общими словами", а третий - для школы с базовой конкретикой...


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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 18 Ноябрь, 2010 05:29 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Info21 в viewtopic.php?p=20025#p20025 писал(а):
...Программирование как деятельность по написанию текстов -- точных по форме и по содержанию -- работает в эту самую сторону.
В том числе при написании обычных текстов -- мозг-то один.

Т.е. мысль в том, что явление, описывавшееся Дейкстрой (хорошие программисты получаются из ясно излагающих), обязано работать и в другую сторону.
--------------------
То, что программирование накладывает несомненный отпечаток "точности" на ум, подтверждается наблюдением, что самые упрямые софисто-логики на всех форумах (например, среди любителей классической музыки на http://www.forumklassika.ru) оказываются программерами. (На втором месте -- математики, но у этих обычно нет синдрома "туннельного кругозора", о коем отдельно.)

Очень существенное замечание о взаимозависимости различных направлений деятельности сознания и возможном "перетекании стиля между предметками" :) В частности, позволяет вспомнить пример общераспространённого непрофессионализма в конкретной деятельности, который сегодня уже не может не оказывать влияния на другие сферы деятельности большинства разделяющих этот подход. Имеется в виду "автолюбительство" (которое сегодня частенько пытаются замаскировать приравниванием к термину "автовладение") ;) Когда человек в местностях с низкой плотностью населения и застройки садится за руль сам - это не только понятно, но, как правило, совершенно оправданно - он там в абсолютном большинстве случаев никому не мешает, а альтернатив доставить себя и груз (пусть небольшой), часто ему просто по объективным экономическим условиям никто не предложит :)) Во многом то же относится и к тому, что владелец в этой ситуации сам осуществляет не только ТО, но и достаточно сложный ремонт своей машины. Но когда "каждый первый" гражданин стремится ездить на том, что купил, и часто "в единственном числе" в густонаселённых местах, к каковым относятся все сколько-нибудь крупные населённые пункты (особенно испытавшие последствия "уплотнённой" застройки) - то это означает, что он просто бестолку занимает незастроенную местность проекциями площади мотоотсека своей "телеги", незанятых мест в салоне и далеко не всегда заполненного багажника. Тем самым и условия осуществления движения объективно друг другу такие граждане ужесточают - ограничивая площадь, доступную собственно для езды (в т.ч. бросанием машин где придётся). Все мы видим, что профессиональное (эффективное и безопасное) движение (включающее, ессно, как езду, так и остановку/стоянку) в этих условиях в основном невозможно - сама ориентация на непрофессиональное использование автотехники подталкивает всё более широкие массы использующих к хамству, переходящему в экстремизм - у некоторой части "автолюбящих" граждан уже переходящий в политический ("дайте нам вести себя так, как мы хотим").
Естественно, даже "Тяньаньмэнь-1989/Новочеркасск-1962 ежеквартально" против такого "броуновского политического движения" не выход - исходная проблема лежит не в той плоскости - в то же время, если пытаться "массовыми капризами" оттягивать цивилизованное решение, то в какой-то момент у власти просто может не быть другого выхода (хотя бы потому, что существует известный в социологии и криминологии порог "массификации типа поведения", в т.ч. отклоняющегося - примерно 12...15% от популяции). Наивно и полагать, что на ситуацию существенно повлияет регулировка "преимущественно любительского" движения - даже если практически исчезнет "торговля полосатыми палками" :) Необходима жёсткая профессионализация использования транспорта в местах концентрации населения/застройки - как цель имеющая эффективное использование в этих местах ограниченного числа ТС, управляемых профессиональными водителями и обеспеченных местами хранения и профессиональным же ТО (независимо от собственности на ТС - здесь уже должны включаться экономические механизмы, гарантирующие собственнику доход от передачи в профессиональное пользование и возмещение возможного ущерба - вероятность и ожидаемый размер которого, кстати, снизятся при облегчении условий движения)...
Немало сделали для подобной экстремизации "активные" из автопрома - и здесь прослеживается, что позиция ЛПР в конкретной "предметке" неотделима от общего взгляда на мир - достаточно вспомнить Г. Форда, который стремился каждого усадить за руль своей "тачки" независимо от условий дорожного движения - и одновременно, как мы знаем, разделял и активно поддерживал "управление государством через толпы домохозяек" любыми методами, вплоть до холокоста... :| Кстати, показательно и совпадение названия его мемуаров с гитлеровскими - очень уж эта "чётно-рационально-активная" публика любит "самость" (в сочетании с мистицизмом - как удобной альтернативой "софисто-логике" в обосновании правильности "моей жизни", "моих достижений", "моей борьбы" - что, кстати, не исключает его применимости в познании донаучном при правильных исходных посылках)...
В немалой степени из-за того, что "каждый суслик стремится в агрономы", мы (и американцы, и многие другие) теряем множество людей в ДТП. Не говоря уже о потерях времени и сил в "пробках" и попытках наверстать потерянное время...

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

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 18 Ноябрь, 2010 05:40 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Илья Ермаков в viewtopic.php?p=53622#p53622 писал(а):
Вот у меня есть группа динамических объектов в куче, каким-то образом связанных и взаимодействующих. Между чем же будет устанавливать связи редактор? Редактор даже не может знать, куда же ведёт виртуальный вызов obj.Method, ибо это будет зависеть от динамического типа obj во время выполнения программы.

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

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

Кстати, ещё о представлении структур данных. В свете замечаний того же Вирта интересно рассмотрение влияния способа информатизации тех же графов на эффективность работы с ними. Вот в работе: Овчиников В.А. Алгоритмизация комбинаторно-оптимизационных задач при проектировании ЭВМ и систем. - М.: Изд-во МГТУ им. Н.Э. Баумана, 2001 приведены 10 способов представить граф как списковую структуру (то же вкратце рассмотрено в: Иванова Г.С. Технология программирования. - М.:Кнорус, 2011). Наверное, тот или иной способ для какой-то цели представления в чём-то более удобен, а в чём-то менее...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 18 Ноябрь, 2010 06:55 
Аватара пользователя

Зарегистрирован: Суббота, 27 Февраль, 2010 23:34
Сообщения: 746
Драконограф писал(а):
И эти вещи также имеют прямые соответствия в информатике, как ни удивительно ;) В частности, ни один "предметник" не станет программистом только оттого, что у него появится в распоряжении некий "суперязык" формализации вплоть до программирования и поддерживающие язык средства. Надо ещё уметь "водить программы", а также быть подготовленным к этой работе - не так ли? И в то же время это не отменяет возможности пользоваться этим языком для формализации - только эскизной, "без права шить программы" ;) О том, что в программировании как реальном бизнесе также необходимо регулировать поток заявителей, ограничивать срочность и частично передавать "на внешнее исполнение" (естественно, за комиссионные :)), говорил тот же Михайлов - да это элементарная экономика в принципе.
Со всем сказанным можно было бы согласиться, но... что-то не позволяет :) "Что-то" имеет три составляющих. Первая. Понятие "профессионализма" слишком размыто. Профессионал - это тот, кто:
    а) умеет пользоваться инструментами, знает основные методы и приемы выполнения работы?
    б) может выполнить типовую работу с заданным/требуемым качеством, в установленные сроки, за согласованную плату?
    в) умеет находить неожиданные решения в известной ему области, исследовать смежные области, самостоятельно находить и устранять проблемы?
(нужное подчеркнуть) Как правило, а-профессионалы ("вечные студенты"), не считают профессионалами тех, кто относится к категориям б-профессионалов ("ремесленники/практики") и в-профессионалов (исследователи). Точно также и другие категории профессионалов относятся к другим своим "коллегам" с не большей степенью уважения.
Второе. "Суперязык" - это... не более, чем метафора, как правило... обобщение (до абстрагирования с последующей фетишизацией) инструментальных средств. Было бы разумно говорить о "суперязыке" не как о средстве, но, как о методе... тогда все встает... на свои места... легко и непринужденно. И любой "предметник", владея методом, сможет формализовывать и даже оптимизировать решение задач в своей предметной области. Примеров тому изрядно...
И, наконец, третье. Программирование - это не... "реальный бизнес". Программирование - это "идеальный бизнес". Если "реальная экономика" преобразует и направляет материальные потоки, то "идеальная экономика" преобразует и направляет потоки идей. И не следует, наверное, априори считать эти "экономики" тождественными... ни с точки зрения принятия заявок, ни с точки зрения планирования и выполнения работ, ни с точки зрения распределения результатов. IMHO... разумеется.


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

Зарегистрирован: Суббота, 27 Февраль, 2010 23:34
Сообщения: 746
Драконограф писал(а):
Илья Ермаков в viewtopic.php?p=53622#p53622 писал(а):
Вот у меня есть группа динамических объектов в куче, каким-то образом связанных и взаимодействующих. Между чем же будет устанавливать связи редактор? Редактор даже не может знать, куда же ведёт виртуальный вызов obj.Method, ибо это будет зависеть от динамического типа obj во время выполнения программы.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 18 Ноябрь, 2010 23:35 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
alexus писал(а):
Есть интерфейсы, и любая сущность, обладающая требуемым набором интерфейсов, может выступать в требуемой роли (собственно, роль, в данном контексте, это поименованный набор интерфейсов). Разрабатывая/проектируя свою часть, мы оперируем не сущностями, но только ролями, абстрагируясь от сущностей (которые могут быть очень большими и многообразными), выступающих в данной роли в конкретной реализации, в конкретный момент времени.


Мне нравятся формулировки харьковско-белгородской школы системного анализа (проф. С.И. Маторин).
Подход УФО - Узел-Функция-Объект.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 19 Ноябрь, 2010 00:45 
Аватара пользователя

Зарегистрирован: Суббота, 27 Февраль, 2010 23:34
Сообщения: 746
Илья Ермаков писал(а):
Мне нравятся формулировки харьковско-белгородской школы системного анализа (проф. С.И. Маторин).
Подход УФО - Узел-Функция-Объект.

Каждый узел данного уровня системы - это пересечение связей, т.е. потоков. Узел - это просто точка балансировки потоков какого-то типа. Функция - это то, как именно балансируются потоки. А дальше в узел может быть подставлена любая субстанция - объект, которая может выполнять в этом узле эту функцию.
Это не очень корректно... Пересечение связей/потоков... Куда текут эти потоки? Откуда они вытекают?.. Видимо, "узлы" - это и есть сущности... но, дело в том, что связи могут перестраиваться в динамике (в run-time). Будут ли образовываться новые узлы? Что должно происходить со "старыми" узлами?
Если же речь идет о системе, то... она, как известно состоит из элементов и связей... Узлы, потоки, функциии... нет, это все надуманное...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 19 Ноябрь, 2010 06:28 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8500
Откуда: Троицк, Москва
Илья Ермаков писал(а):
Мне нравятся формулировки ...
Всегда полезно подумать, *почему* они мне нравятся.
Разные могут получиться ответы.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 19 Ноябрь, 2010 12:43 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Info21 писал(а):
Илья Ермаков писал(а):
Мне нравятся формулировки ...
Всегда полезно подумать, *почему* они мне нравятся.
Разные могут получиться ответы.


Как инженеру-практику, мне обычно нравится то, что помогает мне думать/говорить о каких-то реальных системах.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 19 Ноябрь, 2010 14:43 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
alexus писал(а):
Видимо, "узлы" - это и есть сущности...


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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 19 Ноябрь, 2010 14:47 
Аватара пользователя

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

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


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 42 ]  На страницу 1, 2, 3  След.

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


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

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


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

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