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.
