#begin

I was finally able to continue reading my Object-Oriented Software Engineering, A Use Case Driven Approach book again. I encountered another interesting bit in the book that I wanted to write down.

This time it’s something about the structure of Sequence/Interaction Diagrams and what they can tell you about the system. Hidden in the structure of such interaction diagrams you find information about the dependencies your objects might have. If you can easily change the order of the function calls and determine the information and ‘consists-of’ hierarchy among things.

Let’s quickly discuss this 🙂

Structures

So in the structures of Sequence Diagrams we can identify two extremes. There are forked structures which model some kind of centralized control and we can identify another structures called a stair structure which reflect a decentralized form of control. I’ll explain both cases and what implications and benefits they have.

Fork structure

This type is identified by some object that is acting like a spider in a web to control many different objects. I really like this analogy (which comes from the book). Much of the behaviour is programmed inside the controlling object (spider) which makes the behaviour be centralized to that object. It knows about many objects which it uses for direct questions and commands.

Implications here are that the controlling object can become a very complex object. Programmers need to maintain proper discipline not to make this object too complex and keep it maintainable. In the context of the book, the fork structure fits very well with “Control Objects” i.e. UseCase objects. Behaviour is encapsulated and centralized in a usecase object which controls, as Uncle Bob would say it, “the dance of the entities”. In this kind of structure it is very easy to change the order of operations so if you think the order is volatile you should consider using a control object.

Stair structure

The stair structure is the other extreme and is characterized by delegating responsibility. This object only knows about it’s direct neighbors and know which of them can help with specific behaviour. Here, there is no control object and thus the stair structure indicates a decentralized structure. Here each object has a separate task and knows about surrounding objects that are able to help to achieve it.

Implications for the stair structure is that behaviour will be spread out over many different objects, each just carrying a tiny bit of the total responsibility. In this structure it is very easy to change how a sequence is actually performed and you can encapsulate it very nicely. I think a decentralized structure reflects the core design principles of OOP since each object has his own set of operations nicely encapsulated.

Properties

We see that both structures have their benefits. So… when do you choose what kind of structure? This is very nicely explained in the book. They say the crucial part here is the determining if operations have a “strong connection”. A strong connection means, if objects:

• Form a ‘consists-of’ hierarchy, such as country-state-city.
• Form an information hierarchy, such as document-chapter-section-paragraph-character.
• Represent a fixed temporal relationship, such as advertisement-order-invoice-delivery-payment.
• Form a (conceptual) inheritance hierarchy, such as animal-mammel-cat.

A stair (decentralized) structure best fits the following rules: Operations have a strong connection, like described above. The operations will always be performed in the same order, and you want to encapsulate the behaviour.

A fork (centralized) structure is appropriate when the operations can change order and new operations could be inserted.

This leads to the conclusion that these two structures should be combined to yield a stable and robust structure for a system.

Now what!?

Well the thing I wanted to point out with this post was that just by remembering these control structures you are able to distill some nice information from sequence diagrams. So the next time I see sequence diagrams in some project I can determine very quickly if the design follows a centralized or decentralized approach, or a combination of both. I think this will greatly increase the understanding of sequence diagrams.

Further Reading

I’m happily going to continue reading in the book. I think I might do more of these small blogs about it because it will make the eventual review blog much easier to write. It wont be as massive as it would since I can simply refer to these small blogs for further reading.

#end

01010010 01110101 01100010 01100101 01101110