Re[4]: ТРИЗ: устранение программных противоречий
От: dmp  
Дата: 08.02.09 16:27
Оценка:
Здравствуйте, 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
)


Осуждаемые там статьи я бегло читал, не впечатлился.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.