OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Среда, 26 Апрель, 2017 01:29

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




Начать новую тему Ответить на тему  [ Сообщений: 106 ]  На страницу Пред.  1, 2, 3, 4, 5, 6  След.
Автор Сообщение
СообщениеДобавлено: Воскресенье, 07 Март, 2010 13:25 
Модератор
Аватара пользователя

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

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

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

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

Кроме своего опыта. Те примеры крупных сложных комплексов из оборонки и проч., которые попадались лично мне в классике по программной инженерии, сделаны именно в таком стиле. Архитектуры комплексов ПО на Ada (а, видимо, именно на ней более 50% самой крупной критической распределёнки в мире) заточены именно на структурное проектирование.

Ещё раз: ООП - механизм разделения системы на компоненты и их коммутации, преимущественно. Остальное - от лукавого, преимущественно. :)

"Распределённые объекты" - вообще дурь. Давайте задумаемся: расширение типа, полиморфизм и виртуализация - это ПО СУТИ своей механизмы внутрипрограммные. Способ расширяемо выполнять вызовы, передавать параметры, с сохранением предельной эффективности.
Удалённый вызов - любой - по определению виртуален. Передача сообщения по определению полиморфна. Замена реализации удалённого сервиса вообще прозрачна изначально. Какое ООП, господа? Просто хочется не передавать параметром ID удалённой сущности, а имитировать объектное обращение к ней? Дурь.

Пардон за эмоции :)


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

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

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

Ну да, напр. в Обероне объектные принципы, если я верно понимаю спецификацию у Свердлова, можно проследить в следующих элементах:
    * инкапсуляция - в управляемой видимости именуемых элементов (за счёт экспорта/импорта идентификаторов);
    * наследование - в объявлении расширений типа запись (в т.ч. процедурных);
    * полиморфизм - в логике работы оператора WITH - выбирается нужное течение процесса для динамического типа (фактически получившегося в предыдущих вычислениях).
Кстати, есть мысль - хотя над переводом работали не просто так люди :) - не трактовать ли "type guard" как "установление типа" - в смысле как действие (аналогично "установлению подлинности")?

А "методность объектов" вижу в реализации процедурных типов, в т.ч. как связанных с типом запись. Возможно, именно это я подразумевал (ещё не зная того), когда при МШ-записи процесса варки кофе Эдуарда в этом сообщении ввёл переменную-действие Наполнить в силуэты 2 и 3 и во вставку Напиться. Правда, сделано не по-программному, а "в лоб", через присваивание этой переменной той или иной формулировки действия :), но если принцип в Обероне подобен - этот стиль в любом случае мне нравится больше, чем прятать код в объекты с конструкторами/деструкторами.
А можно было, как я вижу, и по другому - выбирать разные формулировки прямо в Напиться переключателем по установленному в силуэте значению переменной выбора... но меня интересовало получить более компактный алгоритм Напиться

И всё это без упоминания объектов... и более логично.
И вот хотелось бы ещё наложить на текстовые объявления графический язык визуализации, что начал продумывать Ярослав в связи с ДРОНом... чтобы можно было ввести его в дракон-среду и тем самым получить полноценную дракон-систему - и алгоритм, и его структура данных прорисовываются, а далее из схемы данных (у Романченко - "дерево таблиц", а конкретно - граф-схема записи, узлы которой атрибутируются в табличной форме) получается деклар-текст на Обероне (все объявления и список импорта модуля), а из схемы алгоритма - импер-текст (фактически остальная часть модуля). Прослеживая употребление объявленных имён в импер-тексте (командах икон) можно контролировать правильность сочинения, я так понимаю, сразу при визуализации (поскольку типизация статическая).
Вспомним у Вирта: "данная книга начинается главой о структурах данных, и тому есть две причины. Во-первых, интуитивно ощущается, что данные предшествуют алгоритмам; нужно иметь какие-то объекты прежде, чем что-то с ними делать." (Алгоритмы и структуры данных, 2010. - с.11). То же у Гегечкори в статье, помещённой в этом сообщении (хотя он, скорее всего, сам опирался на Вирта).
Целостная визуализация "программа = алгоритмы + структуры данных", IMHO, послужит и наведению порядка в мозгах прикладников. Как ДРАКОН м.б. учебным импер-языком, позволяющим наглядно представить исполнение программ (систем программ), так ДРАКОН+деклар-язык позволит представить информатизацию деятельности в целом и многое объяснить неспециалисту... но сам стандарт деклар-языка, наверно, должны выработать прежде всего программисты.


Последний раз редактировалось Владислав Жаринов Вторник, 16 Март, 2010 04:00, всего редактировалось 1 раз.

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

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 8648
Откуда: Россия, Орёл
Драконограф писал(а):
Ну да, напр. в Обероне объектные принципы, если я верно понимаю спецификацию у Свердлова, можно проследить в следующих элементах:[list]
* инкапсуляция - в управляемой видимости именуемых элементов (за счёт экспорта/импорта идентификаторов);
* наследование - в объявлении расширений типа запись (в т.ч. процедурных);
* полиморфизм - в логике работы оператора WITH - выбирается нужное течение процесса для динамического типа (фактически получившегося в предыдущих вычислениях).


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

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

Расширение и сопряжение - это статические возможности (как я что описываю в программе).
Полиморфизм и виртуализация - динамические возможности на основе соотв. статических.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 13 Март, 2010 15:23 

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 14 Март, 2010 01:18 

Зарегистрирован: Воскресенье, 09 Март, 2008 22:38
Сообщения: 367
Илья Ермаков писал(а):
принципы

Еще, конечно, надо назвать базовый принцип - абстрагирование. Для, собственно, выделения классов.


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

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 8648
Откуда: Россия, Орёл
Но это ведь не средство, не механизм, а интеллектуальное действие проектировщика. Ну или свойство в системе, которое делается через какие-то механизмы. Т.е. не того же рода пункт.

А, ну да, это моя ошибка. Озаглавил список как "принципы". Не принципы, а средства всё-таки перечислил.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Семиотика, однако :)
СообщениеДобавлено: Воскресенье, 04 Апрель, 2010 05:05 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Иванов В. В. Чёт и нечет. Об асимметрии мозга и знаковых систем. - М.:Советское радио, 1978.
О дуальности механизмов мышления ("правом" и "левом") у человека и ряда других живых существ, свойствах знаков языка.

Кстати, свойства языков довольно подробно обсуждаются и в /Девятов, Мартиросьян, Гл.9/.
    И такой пример на тему как семиотики, так и соотношения художественного и научного познания. Наш "Поэт Революции" (Маяковский) был одним из основоположников футуризма в поэзии. Стремясь построить теорию этого нового направления в искусстве, он размышлял в своих сочинениях над свойствами языка. В 1914 году он написал следующее:
    «Каковы же изменения, происходящие в законах слов?
    1. Изменение отношения слова к предмету, от слова как цифры, как точного обозначения предмета, к слову-символу и слову-самоцели.
    2. Изменение отношения слова к слову. Быстреющий темп жизни провел дорогу от главного периода до растрёпанного синтаксиса.
    3. Изменение отношения <человека> к слову. Увеличение словаря новыми словами.»
    Видно, что Маяковский фактически дал краткие определения уровней значения информации: семантики, синтаксиса и прагматики.
    В 1938 г. американский логик и философ Уильям Моррис, давая определения трёх основных разделов науки о знаках, сам того не ведая повторил эти формулировки, определив семантику как «отношения знаков к объектам» (т.е. «слова к предмету»), синтактику как «отношения знаков к знакам» («слова к слову»), прагматику – как «отношения знаков к интерпретаторам» («отношение <человека> к слову»).
    Эти определения были положены в основу семиотики – науки о знаковых системах, которая тесно связана с информатикой. Т.о., Маяковский предвосхитил ее и был одним из первопроходцев научного изучения информации. Также он наметил и некоторые проблемы культуры и технологии общения («самоцельные» слова, чересчур растрёпанный синтаксис, произвольное увеличение словаря), которые сейчас очевидны.


Также появился сайт, посвящённый Вячеславу Иванову.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: О языковом базисе информатики
СообщениеДобавлено: Вторник, 06 Апрель, 2010 04:28 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Упоминаемая концепция "трёх схем" (точнее, классов ЯПЗ, соответствующих разным т.зр. на предмет формализации) была определена для датаматики в стандарте IDEF1X (см. выдержка):
Вложение:
Комментарий к файлу: Информационное моделирование. Методология IDEF1Х: Стандарт. Русская редакция. – М.: МетаТехнология, 1993. - Разд.1,2
Стандарт_IDEF1X-русский-Разд1,2.djvu [202.2 КБ]
Скачиваний: 242

Далее начинается собственно описание МФЗ IDEF1X; по крайней мере одно определение оттуда представляется общезначимым: "Сущность является ...независимой, если каждый экземпляр сущности м.б. однозначно идентифицирован без определения его отношений с другими сущностями." (с.13). Полагаю, перекликается с понятием независимости процессов в алгоритмике. Этот же принцип использовал в определении независимости для МШ-метода - процесс независим, если не использует (статически, т.е. в текстуальном определении) те же объекты, что и любой другой процесс, возможный в данной системе; то же относится и к коду, который в случае повторной используемости надо дублировать для каждого использующего процесса (о чём уже говорил Илья, обсуждая "развёртку силуэта") - причём явно (как я понимаю, тоже текстуально).

Уже говорил, что считаю эту концепцию приложимой к любому роду частного отчуждённого знания;.

Вот ещё выдержка:
Вложение:
Комментарий к файлу: Агафонов В.Н. Спецификация программ: понятийные средства и их организация. – Новосибирск: Наука, Сиб. отд., 1990. – Гл.10
Agafonov_SpfPrg_Gl10.djvu [242.04 КБ]
Скачиваний: 274

Обзор языков спецификации программ как способа организации понятийных средств, описанных в предыдущих главах книги.

Отражает ещё один взгляд на вопрос, рассмотренный здесь. Отличие, IMHO,
прежде всего в том, что автор выявляет максимально широкий круг средств представления знаний на стадии математической формализации, чтобы предоставить сочинителю-спецификатору поле выбора ЯПЗ для конкретной задачи (класса задач). В то же время среди классификаций средств нет такой, которая введена в Драконографике - для организации языкового базиса практической формализации.


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

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Возможно, будет интересно; здесь три подхода к содержанию информации как понятия и как сущности.
Вложение:
Комментарий к файлу: Присяжнюк С.П., Сазонов К.В. Потенциальная информативность как новая характеристика отражения материального объекта. // Информация и Космос. – 2006. – №2. – С.100-105.
Излагается конкретная философская т. зр. на информацию, вводятся матмодели оценки потенциальной информативности.

Присяжнюк,Сазонов-Информация-cтатья(ИнфиКосмос-2_06).djvu [67.36 КБ]
Скачиваний: 256
Интересно подразделение информации по мерности в пространстве; любопытно было бы видеть модель многомерного представления (хотя и абстрактного, но практически значимого).

Вложение:
Комментарий к файлу: Лагутин В.А., Петраков А.В. Защита абонентского телетрафика. - М.: Радио и связь, 2001. - п. 1.7
Система свойств информации.

Петраков,Лагутин-Защ_Абон_Телетрафика-п1_7(КачДанных).djvu [62.94 КБ]
Скачиваний: 233
Несколько иная классификация, чем у Герасименко.

Вложение:
Комментарий к файлу: Информатика: Учебник / под ред. Н.В. Макаровой. – ВыхДанные+п. 2.1
Система свойств информации с обоснованием назначения показателей. Вводятся свойства на всех уровнях значения: синтаксис, семантика, прагматика.

подред_Макаровой-Информатика-п2_1(ХарДанных).djvu [196.16 КБ]
Скачиваний: 233
Учебник в целом может служить образцом когнитивной проработки: многое сделано для оптимизации текстовой части (система стилей абзаца и знака); охвачено многое из информатики в уточнённом смысле (по Фридланду); материал хорошо структурирован. В то же время фактический материал по инфорсимам и инфортехам часто относится к периоду 1997-99 гг.; похоже, что последующие издания были едва ли не стереотипными. В то же время это имеет свои плюсы: нет особых реверансов в сторону "объектности", а в разделе о технологии программирования описан модульный подход к инфопрогам.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Модерная ТРИЗ
СообщениеДобавлено: Пятница, 23 Апрель, 2010 04:44 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
оть здесь и проскальзывало ироническое отношение к названной методологии, но вот такой современный источник, тесно связанный с практикой:
Вложение:
Комментарий к файлу: Орлов М.А. - из Гл. 3...9,14...21
Выдержки, относящиеся к представлению и использованию отчуждённых знаний о технических решениях проблем.

Орлов-ОснКлассТРИЗ-извл.djvu [2.32 МБ]
Скачиваний: 312

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

Понятие изобретательской задачи вводится в Гл.3. Далее в Гл. 4-5 устанавливаются закономерности целенаправленного решения. Они позволяют перейти в типах решения от "что будет, если..." к "как сделать, чтобы...". При этом подчёркивается, что "алгоритм изобретения", по сути, всё-таки методика, т.к. содержит "принципиально не алгоритмизуемые акты мышления" - тогда, конечно, сохранение названия "алгоритм" некорректно.

В Гл. 6...9 сущность методики раскрывается. Существенно, что вводится три уровня рассмотрения проблемы - административный, технический и физический - это перекликается со взглядами теории безопасности. В частности, если ограничиться источниками, данными в этом сообщении, то первые два уровня можно отождествить с неформальным и формальным метауровнями СЗИ у /Герасименко В.А., Рис. 7.1/ (если вспомнить ЭМВОС по стандарту ИСО7498, то легко находится место и для физического - нужно добавить к СЗИ физическую среду как основание), а по /Диев, Шаваев, Гл.3/ - все три уровня со сферами ОТМ, НСД, ПДТР.
Поскольку модели деятельности есть тоже технические системы, то наверное можно, основываясь и на доказательной формализации, формировать постепенно "каталог логических эффектов", обеспечивающий рациональное проектирование решений по информатизации на техническом уровне; системотехнический же уровень (подробно раскрытый в Гл. 14-15) инвариантен к природе объекта проектирования (материальная или информатическая система).
    В начале п. 7.2 (с. 92-95) автор обосновывает свою т. зр. на определение алгоритма. охватывающее человеческую деятельность. Видимо, это подлежит осмыслению и проверке на корректность (а м.б. и нет - всё-таки автор "проф.д-р.д-р.т.н." и потому знает, что говорит? :)).
В Гл. 8 рассматривается правильное в общем смысле построение машин (по Фридланду - "устройств"); инвариантная модель машины формулируется на с. 113-114.

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

В Гл.14 сформулирован, по сути, пожицикл системы на основе системотехнического представления о её назначении (главное/вспомогательное, целевое/функциональное). Важна целостная формулировка на с. 255-256 показателя эффективности искусственных систем, не "выносящая за скобки" эффекты, не видимые (и/или допускающие сиюминутное игнорирование) решателем/заказчиком решения.
Данная концепция системного анализа, IMHO, весьма отличается от первоначальной "бизнес-технократической", известной, напр., в следующей формулировке: "Операция <по достижению заданной цели> м.б. представлена как обмен, в результате которого So-система за приобретённый эффект q расплачивается некоторым количеством ресурсов C в течение времени проведения операции T." (Надёжность и эффективность в технике: Справочник. Т.3. - М:Машиностроение, 1988. - Гл.1). О чём речь, станет более понятно, если вспомнить. что ещё лет полтораста назад наш А.Н. Островский по существу вскрыл (сам того не ведая :)) её суть одной фразой "Я буду грешить и каяться, грешить и каяться." (вроде вложена в уста Турусиной из "На всякого мудреца довольно простоты", но не уверен). Отсюда в т.ч. положенная в социально-экономическую практику "цивилизованных народов" концепция благотоворительности "активных" (сначала неважно как приобрёл эффект, затем увидел некоторые побочные результаты своей и/или чужой деятельности и кинул "долю малую" на то, чтобы кто-то за тебя их попытался устранить - причём часто не из искреннего желания сделать "по-божески", а просто чтоб глаза не кололо :)) - вместо нормального комплексного просчёта последствий принятого решения и соответствующей корректировки не только деятельности, но и поставленных себе (и другим) целей.


Принципиальны законы развития искусственных систем, сформулированные в Гл.15. Интересны и метамодели развития, следующие далее в этом разделе.
    Проявление отмеченных в Примере 112 недостатков структуры транспортного обеспечения современной цивилизации нам только что подкинул вулкан Эйя-Фьятла Ёкуль :), а к чему ведёт частноиндивидуализация наземного транспорта в местах компактного проживания, сегодня каждый городской житель может видеть на улицах (у этой проблемы есть ещё одна сторона - перманентное пребывание в личном "автоседле" деформирует поведение индивида по образцу любых кочевников, напр. ордынцев или гуннов - о чём из отечественных специалистов предупреждают, в частности, историки Н. Басовская и Н. Нарочницкая).
    Развивающаяся же авария в Мексиканском заливе показывает, как "неожиданно" знаменатель показателя эффективности решения может начать движение к неопределённо большому значению... начали строить платформы, не отработав аварийное задавливание скважин под водой...


В Гл.16 напоминается, что методологии управления качеством сегодня широко применяются и главное, работают - очевидно, если их правильно формулировать и применять.

В Гл.18 по существу вводится принцип смены т. зр. на культурное наследие - рассматривать элементы художественной сферы как источник научно-технических принципов (в своё время нечто подобное в обратном смысле предлагал Марк Твен: "Я провёл много увлекательных часов ...за чтением свода законов или Толкового словаря, с волнением следя за судьбой героев." :)) (Налегке. - Гл.III)).
Введённое в п. 18.2 РВС-моделирование, IMHO, непосредственно следует из диаматических категорий действительного, где оценка движения как частный случай сведена к стоимостной.

Сказанное в гл.19 о целостном освоении ТРИЗ и тренировке в её применении, IMHO, перекликается с интенсификацией интеллекта по Паронджанову. В преодолении ошибок, перечисленных в п. 19.3, может помочь комплексная постановка задачи.

В п.20.1 Орлов фактически соглашается с /Фридланд А.Я., 2005, Гл.3/, что интеллект до конца неформализуем, хотя и возлагает надежды на "ряд математических моделей". О неформализуемости социальных аспектов информатизации, кстати, говорил ещё в 1980-е Игорь Бестужев-Лада. Рассуждения о прогрессе и творчестве, конечно, "с головой выдают" европейский образ мыслей - линейность прогресса и утопизация человека и социума - в реальности при ведущем частноиндивидуалистическом в человеке само по себе внедрение творческого стиля жизни ничего не решит (но может стать импульсом для подъёма "спирали истории"). Расширение же "ТРИЗ-трансфера в сферы искусства, менеджмента, воспитания" при этих условиях может привести и к "отрицательному творчеству", напр. в виде наработки более совершенных приёмов "выбивания/вбивания" установок сознания, выгодных ТРИЗ-кающему и/или его заказчику в полном соответствии с /Почепцов, Гл.1/.
В п. 20.2 важнейшим является формулирование "принципа включения", интеграции альтернатив на базе нового понимания. Здесь на рис. 20.4 снова "западное" понимание истории как "уходящего будущего" - в отличие от описанного в /Девятов, Мартиросьян, Гл.2, п. Порядок времён/ китайского понимания как "приходящего будущего".

В организации ТРИЗ-софта по Гл. 21, думаю, можно почерпнуть идеи и для систем визуализации знаний. Принципиально, что для одной ТРИЗ-технологии у Орлова существуют реализации как автоматизированная, так и ручная - что вполне естественно и должно считаться нормой.

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


Последний раз редактировалось Владислав Жаринов Четверг, 06 Май, 2010 13:02, всего редактировалось 4 раз(а).

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 26 Апрель, 2010 12:36 

Зарегистрирован: Вторник, 30 Июнь, 2009 14:58
Сообщения: 1352
О больших системах Поспелова
http://gen.lib.rus.ec/search?req=%D0%9F%D0%BE%D1%81%D0%BF%D0%B5%D0%BB%D0%BE%D0%B2
Там еще для начинающих есть Шилейко "Микропроцессоры"
И другие книжки интересные есть. Все ссылки прямые


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 17 Май, 2010 09:46 

Зарегистрирован: Вторник, 30 Июнь, 2009 14:58
Сообщения: 1352
Цитата:
ПРЕДИСЛОВИЕ РЕДАКТОРА ПЕРЕИЗДАНИЯ
С момента выхода книги прошло уже 30 лет, но, перечитывая ее, понимаешь,
что классика бессмертна. Всё, что здесь написано, актуально и по сей день, и будет
актуально, пока существует программирование.
В далёком 1983-м году я, 18-тилетним парнем, пришел работать в одно ПКБ. Это
была эра большим машин (ЕС ЭВМ, если еще кто помнит). Реальный мир
программирования оказался слишком далёким от того, что преподавали в институтах.
Оказалось, что на производстве не перемножали и даже не складывали матрицы! Зато
мне выдали распечатки одного САПР на ФОРТРАНе, которые весили килограмм 5–6. В
них то я и углубился. Программы были написаны в стиле того времени – идеально
выровнены по 7-й колонке, без единого комментария и со всякими интересными
трюками, как то GOTO во внутрь цикла и т.п. САПР был не очень популярный, спроса
на него не было, и что бы заполнить свободное время, я решил заняться
самообразованием и заглянул в техническую библиотеку ПКБ. И среди всевозможных
справочников, задачников и учебников по ФОРТРАНу я случайно наткнулся на
«Методы программирования».
Эта книга перевернула моё представление о программировании. Всё встало на
свои места. Программирование вместо какого–то шаманства превратилось в строгую
математическую дисциплину, где действуют свои законы. Находясь под сильным
впечатлением от книги и не имея доступа к алголоподобным языкам (на тот момент
использовались ФОРТРАН IV, КОБОЛ и ПЛ/1), я даже написал препроцессор для
ФОРТРАНа на самом же ФОРТРАНе, который реализовывал все базовые управляющие
структуры, описанные здесь (скажу сразу, что символьная обработка на ФОРТРАНе IV
– занятие не для слабонервных).
В начале 90-х дни ПКБ были сочтены, пора было менять работу. Книга осталась
в библиотеке. После этого я неоднократно возобновлял безуспешные попытки найти ее
в продаже. Со второй половины 90-х я стал разыскивать ее в Интернете. В лучшем
случае можно было оформить предварительный заказ (без гарантии, что он будет
исполнен) на каком-нибудь книжном сайте. И на запрос: «Мейер Б. Бодуэн К. Методы
программирования» поисковые службы выдавали тысячи ссылок, но все они были либо
сообщениями в форумах, либо (что наиболее распространено) ссылками на литературу
в университетских курсах.
Книга на русском языки вышла в 1982 году тиражом всего в 30 000 экземпляров
(что для СССР очень мало). Да еще очень ненадёжный переплёт (кто держал эту книгу
в руках знают). Так что к этому времени, очевидно, осталось очень мало живых
экземпляров.
Судя по всему, переизданием этой книги с 82-го года не занималось ни одно
издательство. Сейчас книжные магазины ломятся от литературы по информатике, но, к
сожалению, там очень проблематично найти книги, подобные этой. Зато масса книг
типа «Освой Java за 21 день», «C/C++ для хакеров», «Delphi изнутри» и т.д., где
тщательно рассматриваются возможности получить доступ к private полям классов,
создания «круглых» форм и прочие трюки, которые, по большому счету, к
программированию не имеют никакого отношения. А вот книги подобной этой,
которые закладывают самые основы программирования, встретить на прилавках
книжных магазинов весьма проблематично.
Мне повезло, я все таки достал эту книгу. Так как издательства совершенно не
интересуют фундаментальные труды, я решил восполнить этот пробел, издать ее в
электронном виде и сделать доступной всему программистскому сообществу.

http://gen.lib.rus.ec/search?req=%D0%91%D0%BE%D0%B4%D1%83%D1%8D%D0%BD


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 11 Август, 2010 17:40 

Зарегистрирован: Вторник, 30 Июнь, 2009 14:58
Сообщения: 1352
Торрентино на Грaфы в пр0граммир0вании Касьян0ва Евстuгнеева 2003 г. 1104 страниц 18 мег
ТОЛЬКО ДЛЯ ОЗНАКОМЛЕНИЯ! НЕ НАРУШАЕМ ТОВАРИСЧИ ПРАВ АВТОРОВ И ИЗДАТЕЛЬСТВ

Модератор: Удалена невалидная ссылка на Касьянов В. Н., Евстигнеев В. А. - Графы в программировании: обработка, визуализация и применение [2003, DJVU]


Последний раз редактировалось Борис Рюмшин Суббота, 12 Сентябрь, 2015 21:26, всего редактировалось 1 раз.
Удалена невалидная ссылка


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

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Полные тексты для двух МФЗ, пока сохраняющих актуальность:
Вложение:
IDEF0-Стандарт-рус.djvu [1.84 МБ]
Скачиваний: 233

Вложение:
IDEF1X-Стандарт-рус.djvu [1.58 МБ]
Скачиваний: 216

Сравнивая документы, можно увидеть в них компоненты структуры МФЗ, введённой в этом подпункте - реализация показывается как ручная ИСП, на базе натурального документа "IDEF-папки", соответственно и ТФЗ задана как процесс документооборота - "цикл IDEF-папки".

И ещё обзор, по своему представляющий содержание взаимосвязь распространённых МФЗ:
Вложение:

Из последнего документа хорошо видны проблемы согласования разных подходов.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 16 Сентябрь, 2010 03:50 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
По ошибке это сообщение (новое) заменило собой старое, расположенное теперь по этому адресу: viewtopic.php?p=52313#p52313

Тут высказывалось пожелание выложить машобраз книги /Паронджанов, 2000/:
Геннадий Тышов в viewtopic.php?p=43261#p43261 писал(а):
Уважаемые Владимир Паронджанов и модераторы форума, книгу "Занимательная информатика" от 2000 года было бы хорошо выложить в WIKI для скачивания.
Очевидно, это так никто и не сделал, т.к. при обсуждении подобных пожеланий справедливо указывалось, что произвольно выкладывать "для ознакомления" копии книг, на которые не истёк срок исключительных прав - значит входить в конфликт с правообладателями. В то же время закон нас не полностью ограничивает - см. в этом сообщении о Ст.1274 ГКРФ08.
Познакомился с этой книжкой (в издании 2007 года) и возникли некоторые соображения. В результате публикую большую часть её содержания со своими комментариями
Итак, пойдём по темам (машобраз разбил по главам - иначе обработка цветного усложняется):

Вложение:
§1. Ну, тут всё понятно... только можно ввести понятие задачи как тройки <Дано, Надо, Решение> явно :)

§§2,6. Не знаю, как для школьников, я бы уточнил, что "однозначность" алгоритма надо связывать со свойствами исполнителя. Что для одного исполнителя "неточно" - для другого будет точным. На вершину здесь нужно поставить человека - он будет уточнять указания как раз путём рассуждений, что не под силу машине (и те же продукты купит такие, какие именно ему нравятся "в пределах отпущенных средств" :D). Конечно, это вопрос тонкий, из области "искусственного интеллекта" - но сейчас об этом и в школьных курсах есть - а кроме того, дополнительно ориентирует на формализацию профессиональных знаний вообще, а не только того, "что завтра надо запрограммировать" :wink:
    Существует и определение процедуры деятельности (неалгоритмической) как алгоритма, для которого не выполнено (ослаблено) требование детерминированности - квазиалгоритма. См. выдержку из Поспелова в этом сообщении.

§4. В запоминателях допущена "перетасовка" определений... это так задумано или редакционная ошибка? :)

§5. Быть может, стоит включить в состав исполнителей и человека... уточнив, что дракон-схема помогает ему выполнять какую-то работу "педантично" (всё к тому же, что для §2)?

§§8...10. Здесь интересно было бы ввести подразделение немаршрутной компоненты техноязыка (текстоэлементов) на командный и декларативный, понятие величины... и в дальнейшем выделять (стилем текста) имена сущностей (а равно их литеральные значения, которые только и употребляются здесь) - так юный сочинитель усвоит одну из составляющих "когнитивного стиля" визуализации и заодно наглядно познакомится с величинами.

§11...12. Можно упомянуть, что содержимое комментариев в данном случае - это основная часть состояния алгоритма. А состояние - это все данные, которые нужны исполнителю, чтобы правильно исполнить следующий оператор.
    У формального (информатически - в смысле стадийности процесса моделирования/формализации, вводимой на этой странице) исполнителя в вектор состояния будет входить конечное число параметров с конечными областями определения.
Вложение:
§§14...16. Различие между линейными и нелинейными алгоритмами я бы пояснил так. Линейный получается, если сочинитель представляет исполнителя без обратной связи с окружающим миром (см. также Рис.53 из §26; в этом свете стоит его дать пораньше) - что бы ни получилось в результате исполнения очередного действия, мы всё считаем правильным для решения задачи. Нелинейный - это когда исполнитель должен при следующих действиях учитывать результат предыдущих; для этого он имеет обратную связь ("глаз"), и поступающие по ней (равно как и сформированные предыдущими преобразованиями по маршруту) данные используются для выбора маршрута. При этом стоит ввести понятие алгоритмической обстановки (представления сочинителя об исполнителе и окружающей его среде через набор свойств, каждое из которых может принимать одно из конкретных значений) и данных - этих самых значений, возникающих при конкретном исполнении алгоритма. По сути, в терминах кибернетики речь идёт о разомкнутом или замкнутом управлении.
    Кстати, кибернетический подход проводится и в "Общей информатике" Симоновича (см. в этом сообщении)... тоже школьный учебник.

§18. Как бы нам убедиться, что алгоритм решает поставленную задачу? :wink: Возможно, стоит для старших школьников всё-таки что-то сказать о логическом выводе алгоритма с наглядными примерами (имея целью - показать, что можно сочинять алгоритм как результат проверки его правильности, и в комментариях прежде всего фиксировать доказательства этой правильности)?
    А лучше пойти путём гарантоспособных прогязыков и фиксировать как операторные инварианты - см. макровиопы 30Д...34Д здесь.

§20. Возможно, стоит уточнить (как в /Паронджанов, 2001/), что одинаковым текстам (однотипных вершин) на схеме соответствуют одинаковые буквы?

§22. Возможно, для старших школьников стоит сказать и о допвходах?

§§23...24. Можно уточнить, что исправление ошибок, связанных с неточным описанием, может заключаеться и в постепенном уточнении всех действий и условий, возникающих при решении задачи, до соответствия "репертуару" и "багажу" выбранного исполнителя (заданному стандарту представления знаний), т.е. допустимым для него предписаниям и типам аргументов этих предписаний.
    То, что с самого начала решение задачи описывается на алгоязыке, само по себе не проясняет его смысла - ведь обстановка изначально остаётся такой же неопределённой - не показать ли, что выбор точной формы описания упрощает диалог сочинителя с исполнителем (и/или человеком-экспертом в решении данной задачи) и выявление сути?

§§25...26. Можно уточнить, что состояние - это все данные, которые нужны "мозгу робота" (хранятся в нём), чтобы правильно исполнить следующий оператор. В этом состоянии находится исполнитель между вершинами; при исполнении очередной вершины что-то в этом состоянии меняется (хотя бы положение "дракон-поезда").

Вложение:
§33. Можно и об эквивалентных алгоритмах рассказать... здесь или при обсуждении подстановки. В частности, о том, что можно заполнять вершины текстом на разных языках и получать алгоритм решения той же задачи на языке, понятном исполнителю (я имею в виду гибридизацию техноязыка).
Далее (до следующей откомментированной темы) всё описано в /Паронджанов, 2001, с. 105-110/.

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

§§41...42. Иной раз при программировании мы нуждаемся и в разъединении (об общем правиле развёртки нелинейного алгоритма в командную модель говорил Илья Ермаков в этом сообщении.)... не знаю только, нужно ли это школьникам (вне программистских "профильных классов")?

§43. Хотелось бы ввести понятие для системы алгоритмов, получающейся в результате подстановок (то, что я называю "дракон-модель").

§44. Вообще-то для меня, например, вставка - это сразу и команда вызова процедуры и метка для возврата из неё, т.е. место, откуда совершается прямой "акробатический прыжок" и куда совершается обратный. Поскольку возврат связан с восстановлением контекста вызывающего алгоритма (с учётом возможных побочных эффектов от вызываемого, о чём школьникам, наверное, знать пока не обязательно :P); только после этого мы можем идти по звену к следующему оператору (у нас уже есть состояние, соответствующее завершению вставки).
    При таком взгляде и Рис.91 будет другим. Возможно, он должен учитывать сказанное о БП с возвратом здесь - а для "совсем старших школьников" также и здесь.

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

Вложение:
§48. Даже не знаю... м.б. стоит при раскрытии этой темы рассказать о предусловии, постусловии и инварианте цикла... конечно, подбирая слова? И вообще об инварианте алгоритма (который мы в Обероне или Promela можем проверять по assert при переходе к любому оператору) - ведь и в "школьной" алгонотации assert имеется (в виде НАЧ/УТВ/КОН)...
    Дальнейшее описано в /Паронджанов, 2001, с. 126-129/

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

§§57...58. Цикл в цикле также полагал бы возможным представить как цикл Дейкстры; имеет смысл дать преобразование в ЦД приведённых примеров.
    Конечно, без формул-"лягушек" здесь не обойдёшься :lol: в то же время, возможно, удастся показать логический вывод частично посредством "развилочной логики" техноязыка - так наглядней. А в целом стоило бы показывать связь с математикой - тем более здесь всё вроде оказывается в рамках школьного её курса и даже может в чём-то иллюстрировать его положения - быть может, это неплохой способ внедрять "когнитивную письменность" в математику, о чём говорилось в /Паронджанов, 2001, Гл.19/?

Вложение:
§§61...63. Хотелось бы акцента, что "акробатический прыжок" по имени ветки - не то же самое, что по вставке - здесь нет "командира" и "солдата", т.е. не происходит смены контекста алгопроцесса - просто для удобства расположения на плоскости мы делим шампур на веточные участки по определённым правилам и связываем эти участки петлёй силуэта. Возможно, стоит и показать, что можно обратно перейти к примитиву (как сделано в этом примере); запись получается неэргономичной, но исполнитель-машина именами веток не обязательно пользуется.

§64. Здесь разбирается силуэт только с одним ВЦ. Неплохо было бы указать, что веточных циклов м.б. и два и больше, и соответственно дать иной синтаксис пометки ВЦ - напр., предложенный в /Паронджанов, 2001, Рис.105-107/ и развитый, напр., в этом подпункте Д2М-определения техноязыка. См. также замечания по концептуализации дракон-моделей в этом сообщении.
И уместны примеры, иллюстрирующие разные случаи вложения (без совпадения границ; с совпадением по начальной ветке; по конечной; по обеим - уже говорил в этом сообщении) - это скорее для старших школьников, конечно...
    Далее описано в /Паронджанов, 2001, с. 86-95/

§69. Здесь у нас снова описаны состояния и инварианты алгоритма. Наверное, хороший повод вернуться к этому "для закрепления".

§70. Здесь мы по сути разбили основное содержание алгоритма на ряд веток (в данном случае на две) для удобства компоновки дракон-силуэта на диосцене (критерий эрговыделения веток, или "правило Я. Романченко"). Хорошо бы остановить внимание читателя на этом как на допустимом приёме сочинения (наряду с подстановками в тела веток).

§71. Неплохо было бы перед обсуждением этой темы ввести цикл ДЛЯ; тогда здесь показать, что такой цикл в дракон-силуэте можно располагать только целиком внутри одной ветки, иначе также возникают "сиамские близнецы", только "против шампура" - из ветки с концом цикла ДЛЯ в ветку с его началом (предшествующую по правилу "чем правее, тем позже").
    См. также замечания по визуальному синтаксису цикла ДЛЯ в этом примере.

Вложение:
§72. Очень удачно (хотя и неявно - через комментарий на Рис. 130) показано, что с областями определения условной переменной в сложном ветвлении нужно быть внимательным; то же самое (проблема выбора по "любому другому" значению) явно обсуждалось где-то на конференции, по-моему, а также в конце этого пункта - возможно, стоит акцентировать внимание читателя.

§74-75. Пожалуй, смысл "застывшего условия" шире - это "риторический вопрос", обсуждавшийся, в частности, в этом подпункте. И было бы уместно, считаю (если не для 5-х, то для 9-х классов наверняка), показать переход от "риторического вопроса" к зацикливанию алгоритма - и визуализацию этого зацикливания посредством силуэтных БП (удалением конечной ветки). Объяснить, что это необходимо для реагирующих систем (в смысле теории взаимодействующих процессов), т.е. для любой программы, поддерживающей диалог со внешней средой (объектом управления).

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

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

Ну и "вкратце об остальном" (без машобразов). Насчёт того, должны ли "быть иконы не только в церкви" применительно к нашей культуре, некоторое замечание высказал Дмитрий_ВБ; в этом сообщении замечание обсуждалось и учтено (предварительно) в Д2М-редакции стандарта техноязыка.
Ежели говорить о продолжении, которое я понимаю как расширенное и углублённое изложение визуализации деятельности "для отроков" (уж не знаю, планируется оно или нет :)), то, IMHO, имело бы смысл положить в основу гибрид с конкретным прогязыком, и лучше РВ... хорошо бы для начала Оберон взять, а потом перейти к чему-то вроде Promela/AO.
    Так говорю, поскольку разделяю:
      * и мысли Ильи в Разд.5 этого доклада о нетенденциозном выборе прогязыка;
      * и предложение Info21 о необходимости единого языка как сквозного при обучении программированию (в предисловии к АиСД-Оберон);
      * и идеи о явном выделении состояний процесса для последующей верификации (у тех же Карпова и Шалыто).
    Кстати, связь графит-метода с автоматным программированием использована в этом примере. А выдержки из новой книги по этой методологии теперь вложены в это сообщение.
      При этом, пожалуй, следует проводить единый подход для материальных и датаматических процессов ("техпроцессов" и "алгоритмов"), подчёркивая, что отличие только в объектах предметной области - реальные или виртуальные - а информатическая модель строится по единым принципам, включая представление объектов типизированными структурами данных. И межпредметные связи наводить - на обсуждении постановок и алгообстановок для конкретных задач из разных "предметок".
    В то же время в подобной книжке не стоит обходить уже и дискуссионные вопросы. В первую очередь это как раз упомянутая точность указаний - здесь интересным представляется мнение М.А. Орлова в связи с мета-АРИЗ, приведённое в п. 2 этого сообщения. У меня готовых ответов здесь нет; но хороший математик, думаю, сформирует мнение, которое можно высказать для "старшеклассников и младшекурсников". Далее, сказанное Фридландом о сущности и значении информатики (напр. в п/р 8.4 из учебника, вложенного в это сообщение) - здесь я бы скорректировал определение информатики, о чём говорил в этом пункте. И переопределение данных и знаний, введённое Фридландом в п/р 3.4, с чем согласен.
В целом такое продолжение должно подводить к "серийному производству" визуальных моделей профессионального знания (не только алгоритмических) на инженерной основе. Потому хорошо, если бы оно было увязано по примерам с теми же "Алгоритмами и структурами данных для Оберона" - и в то же время отражало то знание, которое должно этому предшествовать. Тут можно обсудить поподробнее (и визуально) как алгоритмику, так и датаматику, и... активионику, что ли?... не знаю, как назвать отрасль информатических знаний об исполнителях ;)
    В алгоритмике можно рассмотреть и "гвардейские команды" Дейкстры, и "роботы в стране Задач", т.е. алгоритмические обстановки. В датаматике - раскрыть и "герметизацию типов", и типизацию воообще. Если говорить об актив-знаниях - то стоит донести до читателя и реализацию алгопроцессов (структуры времени выполнения), и их взаимодействие (с основными механизмами синхронизации), и представление деятельности как программы в "клеточной стране Тьюрингии", т.е. внутри адресного исполнителя, другие базовые вещи :D) - в общем, что-то вроде исполнителеориентированной части из Звенигородского, только на достойной "дракон-обероновской" основе :)
И в то же время чётко ориентировать на то, что:
Илья Ермаков писал(а):
в viewtopic.php?p=48527#p48527: Алгоритмы - это только небольшая составляющая структуры программной системы.
в viewtopic.php?p=48436#p48436: ...когда алгоритмизация выполнена, программировать тоже ещё рано. В программных системах большая часть решений сегодня ложится на архитектуру - структуру компонентов, их связей, структуру информационного обмена и т.п.
И только потом - программирование.
А это уже базируется на той ветви инфорзнания, которое я назвал обобщённым (о задаче в целом, её структуризации и модуляризации). Я бы сказал, что эти суждения относятся и к неавтоматизированной реализации трудовых процессов... :)
И пусть эти решения тоже получат визуальную основу (только не "всё как картинки" - по-моему, так порой трактуют визуализацию - а как и предлагает создатель техноязыка, "ГРАФИТно" :)).

Такие вот мысли...

P.S. Также в продолжение имеет смысл включать передовые результаты, имеющие значение для инженерной формализации - такие, как существование погранично-корректного класса математических формализаций (см. работы Ю.П. Петрова, упоминавшиеся, скажем, здесь: viewtopic.php?f=75&t=2219&start=20#p63721) и вопросы ограничения типов для автоматической верификации (отказ от нецелых чисел и соответственно от приближённых вычислений, от текстуально не конечных структурных типов - см. критику Оберона от Патрика Реали, которую упоминал здесь: viewtopic.php?p=50800#p50800, работы по model checking).

P.P.S. §47. Когда обобщаем операторы в теле цикла - нужно сохранять в величинах обобщённое состояние алгопроцесса. Конкретно для данного примера действие формулируется так: "Отрубить очередную голову Змея Горыныча". Тем самым сохраняются данные о том, что на каждой итерации имеем дело с новой алгообстановкой - возможно, отличной от предыдущей (здесь - новая голова, очевидно, расположена в пространстве иначе, чем предыдущая; за время после отрубания следующей Змей Горыныч мог переместиться; и т.д.) - и по необходимости сочинитель может детализировать состояние для учёта в алгоритме. Это, кстати, и к вопросу о детерминации точности указаний свойствами исполнителя - человеку-исполнителю указания "очередную" вполне достаточно :)


Последний раз редактировалось Владислав Жаринов Вторник, 30 Август, 2011 09:21, всего редактировалось 12 раз(а).

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

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 2846
Откуда: Астрахань
Подробности об автоматном программировании можно прочитать в монографии Шалыто "SWITCH-технологии", которая вышла еще в 98 или 99 году.


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

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Валерий Лаптев писал(а):
Подробности об автоматном программировании можно прочитать в монографии Шалыто "SWITCH-технологии", которая вышла еще в 98 или 99 году.

Да-да, спасибо. Я имел в виду именно перспективы связи с верификацией, в этой книжке лишь упомянуто о такой возможности, а появилось, если посмотреть Карпова, уже после 1999-го (новые результаты по model checking)... впрочем, из того, что отражено Карповым, уже многое можно понять...


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

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
По ошибке новым сообщением было заменено это.
Новое сообщение по этому адресу: viewtopic.php?p=51403#p51403

Вышла в свет книга:
Поликарпова Н., Шалыто А. Автоматное программирование. - СПб.:Питер, 2010. - 176 с. - библ.156 назв.
Основы формализации деятельности системами переходов между явно выделенными состояниями предметной области. Принципы и методы приложения в процедурно- и объектно-ориентированной парадигмах с примерами программ (на Си/Си++). Проблемы и перспективы автоматного подхода.

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

Добавлена выдержка из работы:
Вложение:
Комментарий к файлу: Основы автоматного подхода (формализация знаний с ЯВС). Программная реализация ЯВС-моделей в процедурной парадигме.
Поликарпова,Шалыто-АвтоматнПрог-извл(ВД+Огл+Пред+ГЛ1,2+Лит+ПУ).djvu [951.36 КБ]
Скачиваний: 382
Вложение:
Комментарий к файлу: Об авторах и о работе.
Поликарпова,Шалыто-АвтоматнПрог-извл(обл_цв).djvu [336.49 КБ]
Скачиваний: 189
Определения типов реагирующих систем на с. 10 коррелируют с уровнями реализма информоделирования деятельности, введёнными в начале этого подпункта. Важен проводимый подход к проектированию деятельности от качественного описания через математические автоматные спецификации к информоделям с увязкой компонентов частного отчуждённого знания, выделенных в начале этого подпункта. Прежде всего это касается импер- и актив-знания; деклар-компонента, как видим, глубоко не рассматривается (и её увязка уже д.б. результатом работы читателей - если Шалыто не предлагает стройного решения в других своих работах).
Интересно, что Поликарпова работает в Цюрихе... по соседству, можно сказать, с Виртом :) При этом имеются определённые различия в подходах - см. на с. 162 в следующей выдержке:
Вложение:
Комментарий к файлу: Проблемы и перспективы автоматного подхода.
Поликарпова,Шалыто-АвтоматнПрог-извл(Гл4+Закл).djvu [165.81 КБ]
Скачиваний: 242
Т.к. образы разворотами, то последнюю страницу (164-ю) см. в предыдущей выдержке.


Последний раз редактировалось Владислав Жаринов Пятница, 14 Январь, 2011 11:55, всего редактировалось 4 раз(а).

Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Основные ресурсы информатики
СообщениеДобавлено: Пятница, 08 Октябрь, 2010 04:24 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
В связи с использованием материала в ряде сообщений сюда помещаю машобраз выдержки из Фридланда.
Вложение:

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

Взгляд на инфоркультуру, изложенный на с. 248-249, весьма актуален; приведённые там правила касательно информативности учёл при определении формата РДП-документов в этом сообщении.

В п. 7.3.2 среди ресурсов определён и языковой как "совокупность языков анализа и проектирования, в т.ч. языков программирования" (с.216) - это также соответствует представлению о разработке и документировании как о двуедином интеллектуальном процессе. В целом классификацию средств, видимо, можно уточнить (используя положения системотехники о видах обеспечения искусственных систем). В частности, я бы объединял методы, методики, модели, алгоритмы (понимая их как символические импер-модели), символическое обеспечение косавтов (в основном определённое как signware в /Паронджанов, 2001, Рис.142/) в вид когнитивного обеспечения орг[тех]систем, к которому как раз и предъявляется требование когнитивной эргономичности как ведущий показатель качества наряду с показателями качества для достижения целей применения.

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

Ну и конечно даты в п/р 1.2 уточнил бы. Транзистор изобрели (как мы помним, Шокли, Бардин и Браттейн) в 1948-м; даже у нас первый транзистор появился, по-моему, пораньше 1956-го :) Считается, что ИМС создана практически в 1958-м (Килби и Нойс; идея высказана Д. Даммером в 1952). Если говорить о работающей информашине независимо от принципа действия - то первой можно считать как релейные из Z-серии Конрада Цузе (первую рабочую модель относят к 1940; тогда же он создал для неё первый прогязык Планкалкюль), так и "интерполятор" Дж. Атанасова (1939-41); если о дискретной автоматической программируемой - то это британский "Колосс" (1943). Микропроцессор всё-таки был сделан в 1971-м. Телевидение в 1939-м появилось в СССР; за рубежом пораньше (электронное - ок. 1935 в Германии; кстати, доктор Геббельс был "отцом" концепции "информационно-развлекательного ТВ", перенятой всеми коммерческими телевещателями в мире (или переоткрытой, исходя из общности взглядов) - ему и его сотрудникам принадлежит обоснование содержания программы, разбивки его по составу передач, их "сетки").

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

Кое-что также обсудил в конце этого сообщения.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 14 Октябрь, 2010 09:33 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Опять же часто использую в обсуждениях и потому даю выдержку:
Вложение:
Комментарий к файлу: В Гл.8 на примерах рассмотрено применение метода для верификации задач различных предметных областей.
Карпов-ModelChecking-извл(Огл+Гл8+Лит+ПУ).djvu [648.71 КБ]
Скачиваний: 361
Здесь можно видеть, как этот метод помогает на практике доказывать правильность формализации процесса (системы процессов) в отношении сформулированных свойств (техтребований, выраженных современными логическими средствами).
Вложение:
Комментарий к файлу: Обоснование необходимости формальной верификации. Вопросы проверки моделей на качественных темпоральных логиках.
Карпов-ModelChecking-извл(Гл.2,3,5-7).djvu [1.73 МБ]
Скачиваний: 309
Здесь ещё ряд обсуждаемых вопросов доказательной формализации.


Последний раз редактировалось Владислав Жаринов Пятница, 14 Январь, 2011 12:00, всего редактировалось 1 раз.

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

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


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

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


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

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