On Sun, Mar 8, 2009 at 3:25 AM, Vishal <vsapr...@gmail.com> wrote: > Hi, > Does anyone know of a tool that can produce Python code from UML diagrams? >
Never used personally, but found few moments back -- 'Gaphor' ( http://gaphor.devjavu.com/) <http://gaphor.devjavu.com/> I know that BOUML is superfast and is quite extensible with possibility of writing it's plugins using a well documented API (mixed C/Python plugin possible). I've used BOUML (but for C++ projects), and it is one of _the_ fastest babes around. > Is something of this sort being added to NetBeans? > Impossible is nothing ;-) Or is it that the ease of programming in Python acts as a deterrent in the > way of having to create something in UML and then covert that model into > Python. > Forward engineering should not be a challenge, but any programming language that has too many ways of representing the same idea, and where the OO paradigm can be functionally represented in multiple (too many) form, reverse-engineering (not round-trip, simple reverse) presents some challenges (not unsurmountable though). Once the forward and reverse engg parts are individually nailed, the full round-trip thing becomes possible, though some tools _by design_ choose to work in completely context-free manner, and make round-trip jobs difficult. My knowledge of Python isn't good enough to say whether Python is such a language, however given that Gaphor exists, this (forward engg) is a solved problem. > > it would be good to have a tool of that sort (Python to UML and UML to > Python)? > > Also, is there a way to find Python call graphs (something like Doxygen), > but not just the typical static code structure...instead something that can > tell execution paths while a certain function is called. > I came across 'pycallgraph'. Its good. except two things, its slow for big > projects, and it goes all the way into tracing every single call...that > means if I am using a COM library underneath, it traces that as well. What I > was interested in is figuring out only part of the trace...may be specifying > exclusions in the trace tree. > I am guessing that it does dynamic (run-time) analysis, and unlike static analysis tools, the depth control can only be "simulated", i.e. in reality full depth traversal happens, hence you find it slow. -- regards, Banibrata http://www.linkedin.com/in/bdutta
_______________________________________________ BangPypers mailing list BangPypers@python.org http://mail.python.org/mailman/listinfo/bangpypers
