Last post raised some interesting questions by a reader . it was a) why does a sequence diagram force sequentiality? and b) what is the problem with bob becoming also a cook tomorrow?.Let me elaborate on each of these points here.
I will first address the first question. But to address this i would like to elaborate on sequence diagram a bit. A sequence diagram depicts how a usecase is realized by depicting the objects and how they collaborate to complete the usecase.The sequence diagram has arrows which represent messages, i.e the arrows represent how message is exchanged between objects. But there is a implicit time ordering, i.e the messages are time ordered and is assumed to start from top and goes in a Left to right and top to bottom (LRTB). The sequence diagram uses a construct called "par" to depict parallelism. As depicted picture in the post, the arrows (in combination with activation boxes) depict control. I.e how one method or message is preceded by another,in a single thread. . This implicit time ordering in a sequence diagram makes the sequence diagram sequential.
Elaborating more on this and to answer the second question, i would like to take the instance (refer to the same figure mentioned in the post) of the object Waiter becoming a cook. the object waiter in the picture is capable of two methods order food and Serve fine after it is activated with the orderFood method. So the developed code is Waiter.OrderFood; Cook.OrderFood; Waiter.Pickup; Waiter.ServeFood. Once this waiter adds the capability of a cook, then this sequence diagram and the code that it generates needs to be reworked, without which this new capability will not be added to the sequence. i.e the whole code, which is what a sequence diagram is, needs to be reworked and retested, leading to very expensive SDLC costs.
But, new minituarisation and networking technologies, is bringing in new expectations and possibilities or new waves of technolgies like WEB 3.0. Some of the technolgies that are being discussed are a) Webtops, b)Mashups, and c).Semantic service oriented architectures. These technologies are parallel technologies and cannot be explained with sequence diagram, they need more of a concurrent representation. This i believe is the fundamental limitation of a sequence diagram.
2 comments:
It would've been nice to leave a comment on the original post about your expansion here, it would've made it easier to track it.
Anyway, a couple of observations :
The left-to-right ordering is of no importance whatsoever. It is simply a preference, see this article on the left-to-right bias in UML sequence diagrams.
The top-to-bottom ordering implies only a partial ordering on the messages, read the actual UML specification.
Sequence diagrams CAN handle all kinds of multi-threading scenarios, what gave you the idea they can't?
The arrows you're using signify async messages so there are really a lot of threads, not one as you state.
You cannot generate code from sequence diagrams except in very trivial cases.
A sequence diagram is not 'really code'.
In short, I do not agree with your conclusion. Sequence diagrams can show all kinds of concurrent behaviour, did you have something particular in mind that cannot be represented on a diagram?
Best regards,
Yanic
Thanks a lot for leaving a comment and making this site alive.
I would like to difer with you on the use of sequence diagram. I am a practitioner in developing Sophisticated Logistics system and Sequence along with Collaboration diagram is used extensively so that we can stub out code to be used by the developers. The idea here is that the developers are following in the overall vision of the designer.
When i refer to concurrency i am not referring to Multi threading. A thread is a OS construct. I am referring to syncing actions. A system represents true concurrency only when two parties are involved in a communication, and a message receiving party is autonomous to not to accept this message. For example in the functional example, Fred sends a message orderFood to Bob, but there is no way bob can refuse this message even though he is not ready to accept this message. A sequence diagram does not capture this autonomous property. This is the essential difference i would like to bring about between a funcitonal language (which is any oo language or lambda calculus) and a true concurrent system (depicted by pi calculus).
I will be exploring on this more in later posts.
Post a Comment