Здравствуйте, FR, Вы писали:
FR>Я тоже тогда зачитывался книжками Альтшулера, у него интересная философия, но практической пользы (ну не изобретатель я) не увидел.
Практическая польза из личного опыта:
Необходимо было организовать передачу крайне критичного к задержкам траффика по относительно медленному каналу (пакетная передача), при этом по тому же каналу должен передаваться некритичный траффик, занимая часть полосы, оставшуюся после критичного, ни в коем случае не мешая ему. Частота пакетов критичного траффика в секунду поддаётся небольшой регулировке.
Никакая пакетная приоретизация не давала нужного эффекта — пакет некритичного траффика, начав передаваться, занимает среду и критичному, если он пришел чуть позже, приходится ждать. Дробление пакетов на мелкие кусочки тоже ничего не дало — слишком большие накладники на инициализацию посылки пакета.
Решил обдумать задачу по ТРИЗ. ИКР ясен сразу — критичный должен передаваться абсолютно без задержек, при этом некритичный не должен никак ему мешать. Противоречие — некритичный должен передаваться достаточно быстро, но не должен вставать на пути у критичного, а время прихода некритичного — не прогнозируемо.
После формулировки противоречия сразу вылезло решение — передавать пакет некритичного только вслед за критичным. На практике такое решение не показало желаемой производительности.
Попытался сформулировать подобие веполя. Два типа траффика, и между ними вредное влияние "временнОго" поля.
Видоизменения некритичного траффика не принесли результата, значит для разрушения веполя нужно видоизменять критичный.
Новый ИКР в этом контесте: критичный траффик должен сам обеспечивать передачу и себя без задержек, и некритичного с достаточной скоростью.
Из этого сразу стало очевидным решение — приклеивать данные некритичного траффика к критичному, скорость некритичного регулировать размером этого приелеенного "хвоста" и количеством пакетов критичного в секунду.
Это решение оказалось рабочим, и было воплощено в жизнь.
Да, возможно, кто-то нашел бы это решение без всякого ТРИЗ. Но у меня так сразу не получалось.
Этот случай не единичный, просто тот, для которого поиск решения я смог более-менее восстановить по памяти.
FR>Все попытки адаптации пока дали практически нулевой выхлоп.
Вообще говоря, пользоваться можно и без адаптации, просто имея достаточную фантазию чтобы перенести
сущности, которыми манипулирует ТРИЗ, на сущности в программной задаче. Пользу вижу именно в
нахождении таких аналогий, т.к. фантазия — штука капризная
FR>По моему есть какая то принципиальная несовместимость ТРИЗА с программированием и проектированием программ.
FR>Все кроме общих принципов (типа эволюции систем и надсистем) или не работает в нашей области или дает очень скромные и протеворечивые результаты (это мнение у меня сложилось во многом из обсуждений ТРИЗ здесь на RSDN http://www.rsdn.ru/forum/message/1790637.flat.1.aspxАвтор: Кирилл Лебедев
Дата: 18.03.06
http://www.rsdn.ru/forum/message/2516100.flat.1.aspxАвтор: borisman3
Дата: 06.06.07
)
Осуждаемые там статьи я бегло читал, не впечатлился.