[Uml-devel] ideas for 2.0

[Andrew Sutton]

i'm taking a class on software visualization this semester. pretty 
interesting. we had some discussion yesterday that sparked some ideas. 
radically different ideas for a UML editor.

as developers, it would be nice if we could visualize (see) our code at 
multiple levels of abstraction. its nice to look at a diagram of a class and 
see what attributes and methods it has. stepping up, we can see what classes 
it has relationships too - through inheritance or association. then it might 
be nice to step up again and see what libraries implement each class or what 
components implement each class and the relationship between components. 
maybe what files contain each class or method. what patterns are used and 
what classes they contain. any frameworks. the architecture. i don't know. 
whatever.

anyways, the point is that UML supports notations for most of these ideas 
(except patterns and architectures). however, no UML tools support the 
capability to "drill down" to a different level of abstraction - or done a 
good job merging the dynaminc and static attributes of UML. here's a good 
example of drillling down (and merging static and dynamic views): you look at 
a class diagram and you're interested in the behavior of a method in some 
class. you can click on the method and immediately see the sequence diagram 
for that method.

see? merging static and dynamic and allowing you to "drill down" a level. we 
can also back out a level. there's a lot of different abstractions that exist 
on different levels in source code. the UML object model is just what holds 
them all together.

i guess the big idea would be to generate diagrams on the fly. lay them out 
automatically. imagine if you had the code for a method. we could generate 
the sequence diagram for that method. or if you're looking at a class diagram 
and drill down into a package, a new class diagram is automatically 
generated. optionally, you could select a class from the tree view and see a 
class diagram involving it and its related classes.

here's a good question: what if the modeler didn't have to do ANY work making 
the diagrams. he/she could just focus on the data underlying the diagram - or 
understanding the multiple layers of abstraction within the system.

now, i don't know any tools that work like that for UML (and i've used a 
couple). i think if we could present UML in that way, we'd have a great 
application.

andy