aspose file tools*
The moose likes OO, Patterns, UML and Refactoring and the fly likes How to show Include Use Case in Sequence Diagram? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "How to show Include Use Case in Sequence Diagram? " Watch "How to show Include Use Case in Sequence Diagram? " New topic
Author

How to show Include Use Case in Sequence Diagram?

Da Zhu
Greenhorn

Joined: Jan 02, 2001
Posts: 29
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.
Paul Newton
Ranch Hand

Joined: Jul 17, 2001
Posts: 67
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.
Michal Harezlak
Ranch Hand

Joined: Jul 06, 2000
Posts: 185
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).]
Da Zhu
Greenhorn

Joined: Jan 02, 2001
Posts: 29
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?
Paul Newton
Ranch Hand

Joined: Jul 17, 2001
Posts: 67
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.
Michal Harezlak
Ranch Hand

Joined: Jul 06, 2000
Posts: 185
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).]
Da Zhu
Greenhorn

Joined: Jan 02, 2001
Posts: 29
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.
Michal Harezlak
Ranch Hand

Joined: Jul 06, 2000
Posts: 185
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.
Da Zhu
Greenhorn

Joined: Jan 02, 2001
Posts: 29
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.
Michal Harezlak
Ranch Hand

Joined: Jul 06, 2000
Posts: 185
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?
Desai Sandeep
Ranch Hand

Joined: Apr 02, 2001
Posts: 1157
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)


<b>Sandeep</b> <br /> <br /><b>Sun Certified Programmer for Java 2 Platform</b><br /> <br /><b>Oracle Certified Solution Developer - JDeveloper</b><br /><b>-- Oracle JDeveloper Rel. 3.0 - Develop Database Applications with Java </b><br /><b>-- Object-Oriented Analysis and Design with UML</b><br /> <br /><b>Oracle Certified Enterprise Developer - Oracle Internet Platform</b><br /><b>-- Enterprise Connectivity with J2EE </b><br /><b>-- Enterprise Development on the Oracle Internet Platform </b>
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: How to show Include Use Case in Sequence Diagram?