C UML знаком, но на практике нам не удаётся держать модель и код в
синхронизированном состоянии, поэтому мы UML-ем почти не пользуемся. В
этом плане мне ближе экстремальное программирование.
Хм... Together обладает двунаправленой
синхронизацией - меняешь код - тут же
меняется диграмма, и наоборот. Или о
чем-то другом идет речь?
Не знаю, может ECO чем-то лучше, но держать модель синхронной с
реализацией на Java у нас тоже выходит очень накладно. Мы и Together
пробовали, и несколько других продуктов. Всегда как-то все сводится к
выбору между "моделируй до последней маленькой детальки и используй
автоматическую синхронизацию" и "остановись на компонентах и
синхронизируй вручную". Пока последнее выходит выгоднее.
При чем, в Together/J (да и в других тулзах) при изменении кода
действительно меняются диаграммы, но это только диаграммы классов и/или
sequence. Остальные приходится осмысленно менять вручную, а если этого
не делать, то модель можно через некоторое время выбросить - в use cases
описано одно, в компонентах, activity и state - другое, а
классы/sequence показывают что-то совсем новое. Если потом сгенерировать
доку, но становится ничерта непонятно.
Поэтому мы пока держим яблоки и апельсины отдельно - модель до
классов/sequence даже не доходит. Для полноты картины проще потом (по
завершении проекта) симпортировать готовый код в модель и связать с
остальными частями модели (и если надо, выбросить все классы за раз и
симпортировать еще раз), чем пытаться их держать синхронными.
Роман
