Saturday, December 8, 2007

Reverse Engineering Sequence Diagrams - Are they effective

I have been asked this question several times - How do we synchronize designs automatically? THis is more of a question for sequence diagrams than for class diagrams.

Just to give a little bit more background, in almost all the projects that fall in my perimeter, we use OOAD with UML for design. We follow design, coding and unit testing in that order. We have still some catch up to do with agile practices (such as Model Storming, Refactoring). We typically prepare Class Diagrams, Sequence Diagrams and occasionally State Chart Diagrams to capture the design. Once we are satisfied with the design, we transition to Coding.

During coding phase, often times we introduce methods, private members, modify method signatures and occasionally even add new classes. And since the focus is entirely on implementation, the models prepared during design phase go out of sync. Of course if there is a gross design miss, we go back to the design phase, which is relatively very less. But this topic is more about the other majority of cases when the changes to design are nominal. I should be careful with words here. When i say "nominal" it means no major structural changes.

Once the coding & unit testing is over, typically developers are asked to synchronize original design models & documentation to match their implementation (what a pity!). And thats when they crib. Because both Rational Rose (or XDE) and MS Visio (to some extent) can reverse engineer class diagrams, but not sequence diagrams. I know some of you would be thinking - "There are loads of tool available that do it for you". My wishful thinking brings out 2 different questions(although they are related) -
  1. Why did IBM Rational Rose / MS Visio not provide this functionality even though there tools available out there that do it for you?
  2. Supposing even if you had a tool that automatically regenerated sequence diagrams for you, is it really helpful?
I think I have an answer for both the questions. I think part of the answer for the first question lies in the second question and more over thats what this blog is about. So lets try to explore the second question first and for that we need to backtrack and understand why(and more importantly when) we need sequence diagrams.

A sequence diagram depicts the time ordering of messages exchanged between objects. Following is a sequence diagram that depicts the scenario of a customer viewing the account balance using an Automated Teller Machine(ATM).




Perhaps, I overdid the example. Anyway, I think it serves the purpose. I have tried to depict a high level flow right from the insertion of ATM card to the balance display. For the sake of simplicity, i have used only a minimal set of objects.


What if this sequence diagram had been auto generated from reverse engineering the code?

  1. The auto generating tool would have depicted the message flow related to the low level functionality of reading the card. Obviously there is more to it than just a ReadCard(). Since the goal of this diagram was to depict the "View Balance" Scenario, we did not drill down on ReadCard().
  2. Take a close look at the message OnOptionSelected(ViewBalance). The design decision is that the option chosen will be handled by the ATM object(A switch-case implementation). It could be ViewBalance, WithdrawMoney or ChequeDeposit. Once again we were interested in just the ViewBalance and hence did not show the others. There is no way the sequence diagram generating tool would know the difference and would have message flows for other options too.
  3. Lastly, the actual code contains other aspects such as using a Messaging mechanism to post messages to other parts of the system. It can also include a Trace Logging mechanism for debugging purposes. Typically these would be calls to other infrastructural components. You may not want a sequence diagram depicting a functional scenario include message flows related to these.
The point of the matter is what is depicted in a sequence diagram is totally a designer's decision and the sole goal is to display the message flow between objects for a specific usage scenario and context and a auto generator tool can never match it. An auto generating tool on the other hand relies on the method calls present in the actual code and obviously there can be more than one scenarios cutting through the same object( For example, Withdraw, Deposit and Balance all cut through the Account object) and even though they are meant for different scenarios, they would all appear in the same sequence diagram.

In short, reverse engineering tool can only be of little help. A reverse engineering sequence diagram is more of a flow diagram than anything else and thus are not effective in the true sense of it. Atleast thats what I tend to think. What are your thoughts on this?

5 comments:

Anonymous said...

I would like to add more flavor to this topic.
Reverse engineering cannot create a sequence diagram for polymorphic behavior. Let me explain. Have a look at the following code:

class Base {
int baseVar;
virtual someMethod1()
{
call someMethod2();
}
someMethod2()
{
}
};
class Der: public Base{
int derVar;
someMethod1()
{
/// do some thing
}

};
main()
{
Base *ptrBase;
ptrBase = new Der();
ptrBase->someMethod1();
}

I am damn sure that any reverse engineering software will not draw actual flow. It will draw call to someMethod1() of Base only. :)

G. Sriram said...

Thanks for pointing that out.

You are correct that a reverse engineering tool will not be able to address the scenario you have provided in the example.

Unknown said...

I agree, tools cannot completely generate sequence diagram.

Owen Corpening said...

Of course a tool can generate the sequence diagram!

Think in terms of a tool which parses a log, that log will have "Entering ..", "Leaving ...", and "Calling method .." type statements.

The tool would string together the calls by parsing the log so when it says "calling method" and there is subsequent calls to that method and a base, it would catch that.

There would be technicalities to handle threading and stuff, but MUCH of a sequence diagram could be drawn from properly instrumented code.

Perhaps Aspects could do this.

Personally I could really use such a tool, would like to generate diagrams as part of junit tests, so each Story could get a diagram.

Maybe have a config file to specify the packages/namespaces to be included.

owen

Owen Corpening said...

Of course a tool can generate the sequence diagram!

Think in terms of a tool which parses a log, that log will have "Entering ..", "Leaving ...", and "Calling method .." type statements.

The tool would string together the calls by parsing the log so when it says "calling method" and there is subsequent calls to that method and a base, it would catch that.

There would be technicalities to handle threading and stuff, but MUCH of a sequence diagram could be drawn from properly instrumented code.

Perhaps Aspects could do this.

Personally I could really use such a tool, would like to generate diagrams as part of junit tests, so each Story could get a diagram.

Maybe have a config file to specify the packages/namespaces to be included.

owen