Синтез эффективных математических моделей дискретной обработки данных

Если кто хочет строить UML по готовым исходникам, описание dp есть во второй работе по ссылке http://opslab.org.ru/public

Валерий, залогиньтесь!

Расскажите кно-тибудь вкрадце про понятийный анализ? О чем это вообще?

Пеар ?!

какбе все клево, молодец, респект, но шо это делает в _новостях_? :)

> кно-тибудь

кто-нибудь. fixed.

> вкрадце вкратце. fixed.

Блин. Я на русском языке науку совершенно не воспринимаю. На английском есть ?

Вроде как-то с ДСЛями связанно.

интересно, навеяло. в украинском виховати - воспитать, а поховати - похоронить.

Автор не осилил LaTeX ! Оно написано в ворде !

Анафема ! :)

>понятийного анализа

Анализация "па панятиям"? :)

>Терморектальный криптоанализ по понятиям.

fixed

Уберите нахер это с глагне!

А причём здесь Linux?

Шома, может хоть ты в курсе, о чём эта новость?

лучше бы в девелопмент кинули

а где, извините abstract и/или слайды? Или вы всерьез думаете что народ 400-страничный сухой текст неизвестно чего станет читать?

> Или вы всерьез думаете что народ 400-страничный сухой текст неизвестно чего станет читать?

Там в конце есть 3 примера использоваия всего этого.

>А причём здесь Linux?

Собственно и правда. при чём?

>Собственно и правда. при чём?

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

Как я понял из выложенного текста, предлагается результат анализа задачи (предметной области) изображать в виде диаграммы типа "сущность-связь", или ER, где в качестве узлов используются понятия, а дуги бывают четерех типов: обобщение (типизация) и ассоциация (агрегация). Ясно, что все это уже давно используется в ER и объектном анализе (UML), но там фигурируют типы данных (классы), а тут "понятия". Чем же такие "понятия" отличаются от типов данных? Наверное тип данных (классы) - это частный вид понятия.

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

Хорошо... Что дальше? Зачем все это? Попробуем разобраться... Утверждается, что такая форма позволяет построить процедуры проверки получившейся диаграммы ("понятийной структуры") на полноту и непротиворечивость. Для этого строиться целая теория. Ну и ладно. Сравним теперь с UML: на сколько мне известно в объектном анализе такая задача формально не решается. Похоже, что рациональное зерно в этом какое-то есть.

Свяь с Linux видна при внимательном чтении. Предлагается использовать что-то похожее на генератор программ для синтаксического анализа типа YACC. Т.е. для каждого понятия-класса предлагается задавать не методы и свойства - как это делается в объектных языках, а формы выражения понятий в тексте - в виде правил (продукций) формальной грамматики некоторого языка. Этот язык потом используется для написания программ. Однако, в отличие от YACC, действия, связываемые с продукциями, описываются не на С-подобном языке, а на том языке, который создается. Сама продукция названа описанием синтаксиса понятия, а привязываемые действия - описанием семантики.

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

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

Суть рассматриваемой темы, по-моему, такова: на каком языке удобнее описать решение стоящей задачи, такой и будем использовать. Если последний не обнаружится, то создадим его. Технология отличается от Domain Specific Language (DSL) тем, что, по утверждению автора, удается описывать семантику произвольных языковых конструкций, опять же, на удобной для этого языке (т.е. решается новая задача, или выполняется "семантическая рекурсия"). А в подходах DSL (SymADE, Intentional Programming, JetBrains, Nemerle и др.) все, в конечном итоге, описывается на некотором заранее заданном языке.