Sequence Diagram Reverse Engineering Tool?

Question

It's essential for me to find a tool that will reverse engineer sequence diagrams by integrating with the debugger. I suppose using the profiler could work also but less desirable. It's a key requirement that the tool in question will record all threads of execution since the app, TickZoom, is heavily parallelized.

We just evaluated a most awesome tool from Sparx called Enterprise Architect which integrates with the debugger. It allows you to set a break point, start recording method traces from that break point.

It's a lovely design and GUI. Hope it works for you but it only records a single thread of execution so that makes it unusable for us. I will put in a feature request to Sparx. But hope to find a similar tool that already does this since that's the only feature we need--not all the other amazing features that Sparx Enterprise Architect appears to do rather well.

Answer 1

I think you're going to struggle or pay a fortune. My advice would be to use Windows Workflow, and a little elbow grease. (.NET4 Sequence workflows will map nicely)

Answer 2

As per comment above, I decided to go with aspect oriented programming to trace for sequence diagrams for several reasons. 1. Easy to filter out methods you don't want to log 2. See activity of all threads. 3. Extremely high performance so it doesn't slow down the system. 4. Unnecessary to run the debugger to capture the traces.

Mind you, we have an elaborate Aspect developed in-house called Diagram (class name is DiagramAttribute) that we built based on PostSharp that uses Log4Net to log the call trace and then Trace2UML for converting to sequence diagrams. Works very sweet!

The Diagram attribute is multicast to ALL methods in an assembly.

Here's the cool part. The DiagramAttribute creates a separate log4 net logger for every method in the system. Then it gets named like this:

Diagram.{namespace}.{classname}.{method name}

Then we can enable or disable logging for any entire class or even specific methods just by setting log4net logging rules.

If we set the DIAGRAM logger to INFO, then there's ZERO overhead for tracing. If it gets set to DEBUG, then there's an extremely small overhead but still zero tracing. Then you set TRACE level of either the entire system or specific classes, etc. What I do is set TRACE for everything with the DIAGRAM logger. Then I use more specific loggers to exclude certain methods or classes that are only "noise".

We're very pleased with PostSharp 2.0. The performance meets our stringent requirements. Perviously, We had to drop usage of PostSharp 1.5 due to it being horrible slow in our particular need.

Sincerely, Wayne