With MDA being totally out of the picture, Gregor Hophe (energetic and excellent speaker) and Erik Doemenburg is getting down to the point of what is really important point when it comes to modeling, not do create pictures that you can generate code from, but to generate a graphical presentation from an existing system and an existing codebase.
I write a blog entry called "Feeding the architect" that dealt with this topic. In that case using maven, dotuml and GrapViz to generate diagrams (static and dynamic) from an existing codebase. The main problem is to combine data from static code analysis and from a running system, exactly what Gregor and Erik is going into presenting.
Three different models are suggested:
- DAGS
- Metrcics
- Petri nets
- Trees
Try to extract data from static and dynamic analysis in a simple form, preferably in a text file and then extract data from the text files and map into whatever model you seem fit for the given analysis. A good example of this may be to get a representation of message flow through a workflow system.
The first example being using a 95 line XSLT to generate a dot file put into graphviz to generate a dependency diagram from a spring config file. Well, since I am lazy, I would rather just use
BeanDoc. Remember that lazy is good here, do more with less kind of thing :-) But I think the audience get the point here.
The next demo is much more interesting. By doing some modification of the jar packaging and adding some metainformation, the build step create metainformation in text files that makes us able to create a graphical presentation of dependencies between jar - files, components and to create clickable images drilling down to classes and source code. This may be a very effective means to get an overview of the system and to see how well it really aligns with the architecture that you anticipated. This is good stuff, and it should be added to the tool portfolio of every architect and developer.
Gregor now gives a presentation of how he has generated an svg from a running messaging system by instrumenting his own messaging library.
Process mining is interesting in the sense that we do not only present a model that can be generated from a simple dynamic and static analysis, but a heuristic approach to get a picture of what kind of processes that executes and in what order. Gregor presents a really nice example with using
ProM to
visualize processes using petrinets. This is a tools that accepts XML files as an example that may be nicely represented in a swing gui, really cool.
References:
