Декларативное планирование revisited: темпоральная логика

[gaperton]

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

Comments

[v_e_b_e_r]

Было бы здорово небольшим примером проиллюстрировать. Очень интересно.

[gaperton]

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

Я попробую выложить один из реальных планов и процессов.

[gaperton]

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

[gaperton]

В принципе, стоит сфотографировать бумажку, наверное. Через несколько дней сделаю, как вернусь в Москву.

[nivanych]

Правильно, правильно.
Более 95% насущных задач замечательно
описываются (мульти)модальными логиками.
Займусь этим подробнее летом, после моего текущего
подробного разибрательства со всяко-разными топосами.

[spamsink]

И почему это мне System Verilog assertions напоминает...

[gaperton]

Вероятно потому, что Verilog Assertions также постороены на базе линейной темпоральной логики.

[thrust_breaker]

Положим, с некоторой натяжкой, что множество фич известно на берегу. Однако не очень понятно, откуда перед началом планирования возьмется множество компонентов. Или первой целью в плане будет то самое "множество компонентов" плюс уточненное множество фич?

[thesz]

Компонента - это тоже "фича".

[thrust_breaker]

Автор сказал так:
Множество это состоит из функций (фич), и компонентов (классов/модулей/итд). Мы воспользуемся CRC-картами, которые связывают модули и фичи.
Где брать фичи перед планированием -- понятно (почти, потому что фича, как минимум, является результатом анализа внешних требований). Вопрос о компонентах в силе.

[gaperton]

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

[fireox]

Темпоральная логика - это круто. Очень нравится математическая строгость.
А как быть с неопределённостью оценок сроков? Может стоит ввести нечёткую темпоральную логику? Хотя с практической точки зрения наверное лишняя сложность только во вред.

[gaperton]

Предикат на стрелку вешается, и все.

"Не может случиться ранее чем через Х дней, и позже чем через Y"

[gaperton]

Это кажется называется "интервальная темпоральная логика". Или что-то вроде того. Хотя я не вижу смысла ограничивать предикат на стрелке. Еще ресурсы надо задавать.

[gaperton]

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