Originally posted by Da Zhu: Say use case A has an include use case B. Now how can I draw a sequence diagram for use case A? Any suggestion or reference would be really appreciated.
When realising use cases, I prefer to focus on 'concrete' uses cases - those that are initiated by external actors, and provide observable results. I see relationships between UCs (include, generalise, extend) as a way of organising and structuring the UC model, but nothing more than that. In the case of an 'include' relationship, this is not much more than a way of avoiding copy-paste'ing the same UC text. It should not be seen as a way of doing some 'early' design, or decomposing the system. The danger is that you start to use Use Case relationships to decompose by function, instead of a more object-oriented, behavioural decomposition. As numerous authors have pointed out - the important bit is the UC text, not the relationships. I would write sequence diagrams for the concrete UCs (use case A in this example). If A includes another use case, B, then this must be captured in the use case realisation. I would include this as part of the same interaction diagram. Of course, sequence diagrams do not need to begin with a system event - they can be used for any collection of interactions that the designer wants to show. It may be that a particular set of interactions can be reused in other Use Case realisations, and are factored out into a separate responsibility/interaction diagram. This is what design is all about - identifying responsibilities. However, this decomposition is by behaviour, not according to some arbitrary 'include' relationship from a Use Case model. I would avoid first writing a use case realisation for use case A, then writing another for Use case B. In this way, we have assumed a functional decomposition, which may not be appropriate. Decomposition should be as a result or our design activities, not our use case modelling. Use Cases are a convenient way to capture requirements, but they are not Object-Oriented. As a final comment, you can relate use case realisations to the original use cases, using a 'trace' dependency between models. Although I have not normally found this to be necessary. I am not sure if my point is clear, but I would invite any discussion on this. regards, paul.
Da: IMHO: There is nothing exceptional about this situation. Use cases: A, B will have separate sequence diagrams if required at all. Lets look at �Pay� uses case that will include �Pay by check�, �pay by CC� etc. Sequence diagrams will begin when customer chooses to use CC or check. Hope that helps. Regards.
[This message has been edited by Michal Harezlak (edited October 01, 2001).]
Thanks a lot, Paul and Michal, Let me make sure I understand your point. Say Use Case A includes Use Case B, then you mean part of the sequence diagram for Use Case A is identical to the sequence diagram for Use case B, right?
If I understand Michal's post correctly, we are saying different things. Michal says: 2 Use cases = 2 sequence diagrams. I was saying that sequence diagrams should be written for :_concrete UCs_. Include relationships do not imply/require a corresponding separation in the design. regards, paul.
If you have already decided to "branch out" the use case, it is probably a complex one and in order to understand all the messages it is better to have separate sequence diagram (it is not a rule, it's always the best to use a common sense). Dividing is a way of managing complexity.
Originally posted by Paul Newton: Include relationships do not imply/require a corresponding separation in the design.
IMHO: It is not the other way around either, or is it? So again use your common sense. Best regards and thanks for your opinions. [This message has been edited by Michal Harezlak (edited October 03, 2001).]
Let me confirm again with Michal, did my summary to your point in last message correct? Which means the sequence diagrams for two cases A and B (assuming A includes B) are independent to each other. Thanks for your patient. I really what to understand your conclusion, even if I can not fully understand your reason.
Originally posted by Da Zhu: Let me confirm again with Michal, did my summary to your point in last message correct? Which means the sequence diagrams for two cases A and B (assuming A includes B) are independent to each other. Thanks for your patient. I really what to understand your conclusion, even if I can not fully understand your reason.
Not a problem and yes that is my opinion. Let me know what is not clear, might be I can rephrase it.
Thanks, Michal, I am glad that I finally get your point, although I am not sure if it is the best solution. My main concern is the relationship between two use cases A and B (assuming A contains B) gets lost in the sequence diagrams in your approach, while such relationship may be useful in the design of class diagrams.
Originally posted by Da Zhu: [...] My main concern is the relationship between two use cases A and B (assuming A contains B) gets lost in the sequence diagrams in your approach, while such relationship may be useful in the design of class diagrams.
Do not think so. Ask yourself why do you draw sequence diagram in the first place. How is that useful in the deign of class model?
Hi, Sequence Diagrams and Use cases address different issues.Even if you decide to use the include relationship in the Use case diagram, the sequence diagram will not get affected. For the Sequence Diagram you need to know the objects that would be collabarating with each other.The message A that is passed to an Object may pass a message B to another object which may have been identified as an concept in another use case. So basically these diagrams actually help you to understand the System better.IMO, the most important artifact is the Design phase is the Collaboration Diagram and Class Diagrams. Hope this helps, Sandeep SCJP2, OCSD(Oracle JDeveloper), OCED(Oracle Internet Platform)