Reverse Architecting

[radirpok]

Hello,

I'm looking for ANY resources regarding reverse architecting a complex system.
By reverse architecting I don't mean reverse engineering source code (although later on that could happen too), rather a way to describe an existing software system and produce UML diagrams on all levels.
The system is quite heterogeneous, there are multiple nodes and operating systems involved, also several network protocols and authentication and encryption methods, external dependencies, many many roles and actors etc.
I don't even know where to start, we have a list of requirements (in EA, about 2000 of them) which may or may not be valid today. We have some use case models (in EA), and several design documents (in Word). And of course the source code in C, Perl, Java, SQL... etc.
The expected result - maybe not tomorrow :-) - would be a more or less complete UML model with all the requirements, use-cases, components and classes/interfaces, so that when we will need to add new features we'll know if we touch something what else it will affect.
Any ideas are appreciated. Google was not my friend this time ;-(

[bioform]

http://dobbscodetalk.com/index.php?option=com_myblog&show=Grokking-Groker.html&Itemid=29

Describes new tool being developed for reverse engineering architecture of a system...

[radirpok]

http://dobbscodetalk.com/index.php?option=com_myblog&show=Grokking-Groker.html&Itemid=29

Describes new tool being developed for reverse engineering architecture of a system...

Nice indeed.
All I could find was two research papers, one from 1997, and the other a Masters Thesis from 2005.
Which means that the topic is in its infancy, and I could make a really nice PhD thesis of it if I wanted to....  maybe we'll invent our own methodology.

[Thelonius]

We have been doing "reverse architecting" of enterprise architecture for clients - not discrete applications / systems.

As in - using Component diagrams to build macro models of enterprise systems architecture for medium / large private sector customers.

Have been calling this "forensic architecture" - but "reverse architecture" may be a better term. Or perhaps "reverse enterprise architecture".
 

[Thomas Mercer-Hursh]

This is a problem area I have been working on for some time, albeit focusing on the Progress ABL.  The hope when we started was, like you, to end up with a multi-level model of the sort that arises from the usual OOAD process so that we could clean up and modernize at a fairly abstract level and then use MDA to produce a new system which was built according to modern architectural principles.

We have come to accept that there is an inherent limitation here, however.  When one proceeds from abstract to concrete in the usual new system OOAD process at each level some information is left behind.  New information is created as well, but it is the left behind part that is the problem.  In general what is left behind is the why.  In the more concrete layer one has the expression of the what and the how, but not the why.  In trying to go from code to an abstract model there isn't really anyway to impute the why.

You have an advantage in having some of the abstract elements already in existence.  It is mostly going to be a long slog, but there is the potential there for recognizing that one of the abstract bits you have relates to a particular concrete bit and connecting the two.  You can then also look at the code and existing system and say "this piece behaves this way" and then look at what is related to it in the abstract stuff and make connections and create intermediary model tools the express the design and rational that is reflected in the current code and which is implied by your use cases and such.

But, don't expect a magic bullet.