Tuesday, 21 August 2012 09:37

Putting The Inclusion Use Case In Focus Featured

Written by 
Rate this item
(7 votes)

FEATUREAug21stIntroduction

The circumstances that made me analyze the extension use case from the ground up (see [1]) also led me to examine the inclusion use case.  Like the extension use case, the inclusion use case is at times misinterpreted and misapplied.  Like the extension use case, once it’s understood from first principles, the inclusion use case has a more specialized purpose than is sometimes thought.  This article mentions six fundamental points that contribute to creating quality use case models, with or without inclusion use cases.

Note: Section 16.1 of [2] uses “subject” to refer to “the system under consideration to which the use cases apply.”  This article uses “system” instead.

Point 1: Include relationships cannot cross system boundaries

An include relationship — between a base use case and an inclusion use case — can only be defined between use cases of the same system.

This assertion is based on the following rationale.

 

Only associations can cross system boundaries

The association is a core element of a system’s use case diagram.

  • An actor is always external to the system and a use case is always internal to the system.
  • An actor and a use case can only be connected through an association, which therefore crosses the system boundary.

This is illustrated in the following diagram, which contains a “directed” association to show the flow of control (the actor initiates the interaction with the system).

WillemAug212

Include relationships are not associations

When use case A of one system can initiate use case B of a second system, then:

  • In the use case diagram of the first system, the second system is shown as a supporting actor of use case A.
  • In the use case diagram of the second system, the first system can be shown as the initiating actor of use case B.

Thus, a relationship between two use cases that crosses system boundaries can only be an association.  Since an include relationship is not an association, it cannot cross system boundaries, and can therefore only be used within a system boundary.

Supportive UML superstructure excerpts

Crucial excerpts from [2] that support the above are:

  • “An Actor models […] an entity that interacts with the [system], but which is external to the [system].”  Section 16.3.1, Description.
  • “An actor can only have associations to use cases […].  Furthermore these associations must be binary.”  Section 16.3.1, Constraints.

Point 2: Actors, associations and use cases are classes

This point connects points 1 and 3.

Classes

An association connects two classes (*).

  • At its simplest, a class is a set of entities (objects, instances) of a certain type.
  • An association represents that an instance in the one class can be connected to an instance in the other class through a link.
  • A link is an instance of an association.

(*)  In the UML an association is between “classifiers”, which is a broad category that includes the narrower (and somewhat informal) “classes” category used here.

Thus, a use case diagram represents a class view, where:

  • An actor is a class of possible actor instances.
  • A use case is a class of possible use case instances.
  • The association between the actor and the use case is a class of links between actor instances and use case instances.

A class view is a model-time view and an instance view is a run-time view.

Throughout this article, “use case” and “use case class” are used interchangeably.

Supportive UML superstructure excerpt

A key excerpt from [2] that supports the above is:

  • “An association describes a set of tuples whose values refer to typed instances.  An instance of an association is called a link.  A link is a tuple with one value for each end of the association, where each value is an instance of the type of the end.”  Section 7.3.3.

Point 3: Inclusion use cases are not real use cases

Key UML superstructure excerpt

Section 16.3.5 of [2] states:

  • “The include relationship is intended to be used when there are common parts of the behavior of two or more use cases [(*)].  This common part is then extracted to a separate use case, to be included by all the base use cases having this part in common.” 

(*)  Based on the preceding, this can be enhanced to “… two or more use cases of a single system.”     

Thus, an inclusion use case is simply a common fragment lifted from two or more use case specifications and defined as the specification of a single inclusion use case.  The inclusion use case is then referenced from the base use case specifications by an include statement in place of the original fragment.

WillemAug213 

Inclusion use cases (and extension use cases) are fragments

Section 16.3.6 of [2] states that a use case “describes a complete usage of the [system]” by an initiating actor.  Since, as shown above, inclusion use cases only represent portions of base use cases, an inclusion use case never “describes a complete usage of the [system]” and is therefore not a real use case.  In [3] Jacobson proposes to call them “fragments” rather than use cases and even suggests a separate notation.  Within the current UML notation, I use the custom-defined <<fragment>> stereotype for inclusion use cases (and extension use cases as well), as illustrated in the following diagram.   

Inclusion use cases (and extension use cases) are abstract use cases

The UML refers to real and not real use cases as concrete and abstract use cases. 

  • A concrete use case is a use case that can be instantiated.
  • An abstract use case is a use case that cannot be instantiated.

Concrete and abstract use cases in use case diagrams

  1. Any use case that has an association with an initiating actor is a concrete use case (*).
  • At execution time, the initiation of the use case by an actor instance (within the actor class) creates a use case instance (within the use case class) (**). 
  • The use case instance behaves according to the use case specification, which is attached to the use case class and applies to all its instances.
  1. Any use case that does not have an association with an initiating actor is an abstract use case (*).
  • At execution time, the specification of the abstract use case is combined with the specification of a related concrete use case, and the instance of the concrete use case behaves according to the combined specification. 
  • An abstract use case cannot be instantiated, so there will never be a use case instance that is solely based on an abstract use case.

(*)  The exception is a generalized use case, which is outside the scope of this article.

(**)  This applies if the actor is a person.  When the actor is a system, the use case is initiated by an instance of a particular use case of that system, not by an instance of the system itself.

Regarding notation:

  • A concrete use case’s name appears in straight font, an abstract use case’s name in italic font.
  • An include relationship (and an extend relationship as well) appears as a dashed arrow (as opposed to a solid arrow used for a directed association) to convey that the relationship is between the specifications of the related use cases, not between instances of those use cases.

See the above diagram.  

Public and private use cases

Because actors can only initiate a system’s concrete use cases, these are the only use cases that are visible outside the system, while the system’s abstract use cases are invisible outside the system.  Thus, a system’s concrete use cases are its public use cases and the system’s abstract <<fragment>> use cases are its private use cases. 

A key consequence of this is that if abstract use cases are to be introduced at all, they ought to be introduced after concrete use cases have been defined first.    

Point 4: Inclusion use cases come in two varieties

One variety is the “textually included” inclusion use case.  The inclusion use case’s specification text seamlessly connects with the specification texts of the base use cases, by referring directly to elements within those specification texts by name.  Textually included inclusion use cases are context-aware. 

  • According to section 16.3.5 of [2], “the behavior of the [inclusion] use case is inserted into the behavior of the [base] use case.”
  • For those of us who are old enough to remember, these are like copybooks in a COBOL program’s PROCEDURE DIVISION.

The other variety is the “parameterized” inclusion use case.  The inclusion use case’s context is represented by input parameters, whose values are set by a base use case and used by the inclusion use case.  The inclusion use case’s outcome is represented by output parameters, whose values are set by the inclusion use case and used by a base use case.  Parameterized inclusion use cases are context-agnostic. 

  • Section 16.3.5 of [2] adds, “The [base] use case may only depend on the result (value) of the [inclusion] use case.”
  • Continuing the COBOL analogy, these are like statically called subprograms.

Point 5: Inclusion use cases may be optional

A UML superstructure statement

Section 16.3.5 of [2] states:

  • “Note that the [inclusion] use case is not optional, and is always required for the [base] use case to execute correctly.” 

Cause for confusion

Some seem to interpret this to mean that an inclusion use case must be performed during each and every execution of a base use case. 

Nothing is further from the truth and the truth is simple.

The simple truth

Whether an inclusion use case is mandatory or optional to a base use case depends on where in the base use case the fragment was defined that is now replaced with an include statement for the inclusion use case.

  • If that fragment was part of the base use case’s unconditional flow (steps that always get executed), the inclusion use case is mandatory. 
  • If that fragment was part of a conditional flow (steps that get executed optionally), the inclusion use case is optional.  

So what does the UML statement mean?

The purpose of the UML statement seems to be to contrast the include relationship with the extend relationship, as follows.

At an extension point (not for the entire base use case), the extension use case’s execution is optional. 

  • When the execution of a base use case reaches an extension point, an extension use case may or may not be inserted, because there may be a condition attached to the extend relationship.

However, at an “inclusion point” (not for the entire base use case), the inclusion use case’s execution is mandatory.

  • When the execution of a base use case reaches an inclusion point (i.e., an include statement in the base use case), the inclusion use case will always be performed, because there is no provision for attaching a condition to the include relationship. 

Point 6: Inclusion use cases are not intended for functional decomposition

The principle of creating an inclusion use case to represent “common parts of the behavior of two or more use cases [of a single system]” is at the same time a key argument against using inclusion use cases for functional decomposition, where a base use case would be decomposed into several inclusion use cases that would be included only in that base use case.  Since such inclusion use cases would not be shared by “two or more use cases”, functional decomposition goes against the above principle. 

This underlines that the key reason for introducing inclusion use cases is to optimize a system’s use case model through re-use of inclusion use cases. 

  • However, care must be taken not to take this to the extreme. 
  • Sometimes it’s “better” to introduce an inclusion use case and sometimes it’s “better” to describe a common fragment in multiple use case specifications.  

In conclusion

These points may seem trivial to some, but being mindful of them inevitably results in better use case models.  In fact, ignoring the first three may cause a larger omission.  Due to space limitations, that must wait until later.

This article is about including an abstract use case, but that’s not the only use of the include relationship.  Article [4] deals with including a concrete use case.

Don't forget to leave your comments below.


References

[1] Willem Van Galen, Excavating the extension use case, 10 July 2012, (Part 1) and 24 July 2012, (Part 2).

[2] Object Management Group (OMG), OMG Unified Modeling LanguageTM (OMG UML), Superstructure, Version 2.4.1.

[3] Ivar Jacobson, Use Cases: Yesterday, Today, and Tomorrow, 20 November 2003.

[4] Willem Van Galen, The Include Relationship’s Other Use, 19 June 2013.

Read 6869 times Last modified on Thursday, 20 June 2013 08:22
Willem Van Galen

Willem Van Galen is a senior systems analyst at a large financial services company in London, ON, Canada. For the last five years, one of his responsibilities has been designing, delivering and reinforcing use case modeling training, practices and standards. Last year, he enhanced them to reflect service-oriented architecture and event-driven architecture.

Comments  

0 # Darlene Marriott 2012-08-21 15:24
Just curious about your use of the stereotype .

Is that not redundant? Shouldn't the Include relationship (dotted arrow) be enough?

What benefit does the stereotype provide?

D. Marriott
Reply | Reply with quote | Quote
0 # Willem 2012-08-21 20:34
Thanks for your question, Darlene.

Actually, I use custom-defined stereotypes for all use cases in a use case model. Space didn't permit me to elaborate on these in this article, but you can see additional stereotypes in the diagrams included in my BA Times article Modeling Loosely Coupled Use Cases.

These stereotypes are quite useful in recognizing and highlighting the different use case types, each of which has certain unique characteristics . The stereotypes raise awareness on the part of both producers and consumers of use case models. Moreover, these stereotypes invite the use of separate use case templates, from a distinct use case template for each concrete stereotype to separate templates for inclusion and extension use cases. The stereotypes and templates introduce a more specific use case vocabulary, because people almost automatically start to refer to "service use cases", "inclusion use cases", and so on.

Yes, since inclusion and extension use cases as presented here are abstract use cases, each is always a fragment. The stereotype merely underscores this and fits in the larger strategy of using a stereotype for every use case in a use case model.

Does this answers your question?

Regards,

Willem
Reply | Reply with quote | Quote
0 # Simo 2013-03-05 10:31
Thank you for this helpful article..
I have some questions:
As Jacobson says "Inclusion use cases (and extension use cases) are fragments", I agree with that, but:
1- What about primary actor of these fragments/usecases?!
2- What about these fragment's Specification Document?
3- Which actor should be located as Primary Actor in Specification document?

Thank in advance
Simo
Reply | Reply with quote | Quote
0 # Willem 2013-03-05 20:54
Thanks, Simo. I'm glad you find the article of some help. My answers to your questions are as follows.

1. Instead of Primary Actor, I prefer the clearer term Initiating Actor. In the diagram under point 3 above, the inclusion and extension use cases do not have an Initiating Actor. This is because they are essentially, each in its own way, added to the base use case, which does have an Initiating Actor. If steps of these use case fragments refer to an actor, it can only be the Initiating Actor of the base use case, as the diagram shows no Supporting Actors. The writing convention I advocate for steps in use case specifications is to refer to the Initiating Actor simply as "the actor" and to Supporting Actors by their specific names. Thus, "the actor" used in steps of an inclusion or extension use case corresponds directly to "the actor" in the base use case, so that both refer to the base use case's Initiating Actor.

2. & 3. Based on experience, I advocate the use of different templates for concrete, inclusion and extension use cases. One difference is that the template for concrete use cases has an Initiating Actor section, but those for inclusion and extension use cases do not. (This applies when no generalized use cases are involved, which are outside the article's scope.)

Does that answer your questions?

Regards,

Willem
Reply | Reply with quote | Quote
0 # Simo 2013-03-06 03:52
--Willem
Thank you very much for you quick reply :)

Changing template is so quick and handy way but are you have any standard for it?

What should I write in Actors Section of Specification?
Something like that:

Actors:
1- The primary Actor of "UC001(Base Use Case)" as primary actor

Is it what you are trying to say or we should completely remove this section from Specification document?

I believe this mature Rule of use case:
"When we haven't any Actor then we haven't any Use Case"

Then, Sorry about my full of question sentences :o)

Cheers
Simo
Reply | Reply with quote | Quote
0 # Willem 2013-03-06 21:24
Hi again, Simo:

Jacobson views inclusion and extension use cases as discussed here as use case fragments, whose instructions can only be executed once they are added to the instructions of a concrete use case, after which the combined set of instructions serves as the script for the interaction between the System and the Initiating Actor of the concrete use case (the instructions of a use case fragment can never be executed on their own, because a fragment cannot be initiated by an actor outside the system).

In other words, inclusion and extension use cases as depicted in the diagram under point 3 above don't have an Initiating Actor, so there is no need to have an Initiating Actor section in the templates for such use case fragments. Only the template for a concrete use case needs an Initiating Actor section, because a concrete use case is by definition a use case that can be initiated by an Actor (this is represented by naming the Actor in the use case template's Initiating Actor section).

As for the rule "When we haven't any Actor then we haven't any Use Case":
-- If "Use Case" does not include the idea of "Use Case Fragment", then I would agree with it.
-- However, if "Use Case" does include the idea of "Use Case Fragment", then I'd reword it as "When we haven't any Actor then we haven't any CONCRETE Use Case".

(Cont'd)
Reply | Reply with quote | Quote
0 # Isha 2014-01-11 07:29
Hi Willem,

This article is worth reading to have an in depth understanding with regards to the inclusion use cases and exclusion use cases.

Can you please clarify some queries in extension to it:
1. Can one inclusion use case(UC-i) for UC1 be a inclusion use case(UC-i) for UC2? I have come across such scenarios, so wanna clarify it.

2. As it is mentioned in the article that if inclusion use case is a part of conditional flow, then its inclusion is optional. Let's say inclusion use case is a part of one of the alternative flow of the use case. In that case how to justify the mention of inclusion use case?
Reply | Reply with quote | Quote
0 # Willem 2014-01-11 10:34
Hello Isha:

Thanks for your feedback and your questions. My answers are as follows.

1. Yes. That's my definition of an "inclusion use case": a use case fragment (not a complete use case in its own right) that is included in two or more other use cases. By the way, it's also possible to include a use case that already is "a complete use case in its own right"; for more on that, please see http://www.batimes.com/articles/the-include-relationships-other-use.html.

(Cont'd)
Reply | Reply with quote | Quote
0 # Willem 2014-01-11 10:34
(Cont'd from part 1)

2. Remember that an included use case represents steps (of a main flow or a conditional flow) that otherwise would be defined in that flow itself (if we didn't represent those steps as an included use case). So, rather than write those steps at a certain point in a flow, simply write "Include " instead. (*) You can write such an include statement as part of the main flow, or as part of any conditional flow.

When an include statement is part of a conditional flow, the included use case only gets activated when the conditional flow itself is activated. In other words, the simple or complex condition under which an included use case gets activated is not defined for the included use case itself, but for the conditional flow in which it is included. So, while a use case diagram can show that UC1 and UC2 include UC-i, the diagram cannot show whether UC-i is included in the main flow or in a conditional flow; you need to read the UC1 and UC2 use case specifications to find that out.

For more on flows, see http://www.batimes.com/articles/use-case-goals-scenarios-and-flows.html.

(*) There is no need to specify, in the include statement, the system to which the included use case applies, because that system is always the same as the system to which the including use case applies (as per the article's "Point 1: Include relationships cannot cross system boundaries" section.

Does that (help to) answer your questions?

Willem

P.S. I'm not sure what you mean with "exclusion use cases."
Reply | Reply with quote | Quote
0 # Isha 2014-01-17 21:17
Hi Willem,

Thanks for the response.
"exclusion use cases" was a typo. Kindly read it as extension use case.

Well, I am probably referring to a different template for a use case wherein "inclusion use case" is a separate field in the beginning of the use case. Then, I start with the main flow and alternate flow. It will not imply, to which flow inclusion use case is referred.
But I got an alternate to it based on your response. I will discuss it with my team :)

Thanks and Regards,
Isha
Reply | Reply with quote | Quote
0 # Willem 2014-01-19 10:01
Isha, you bring up a good point about different templates. My preference is for (at least) 5 templates, using some homegrown terms:
1. For (concrete) FUNCTION use cases ("function" is short for "application function"). These are use cases initiated by human users.
2. For (abstract) INCLUSION use cases. These are use case fragments included in two or more use cases.
3. For (abstract) EXTENSION use cases. These are use case fragments that extend one or more use cases.
4. For (concrete) PROCESS use cases (“process” is short for "scheduled process", whether recurring or on demand). These are use cases initiated by the passage of time.
5. For (concrete) SERVICE use cases. These are use cases initiated by an electronic entity. Anytime you model a component, for example, you can use this template to represent each of its services.

Incidentally, each of the above qualifiers (e.g., PROCESS) is purposely a noun, not an adjective (e.g., SCHEDULED).

By the way, for more on concrete and abstract use cases, see the following articles:
http://www.batimes.com/articles/comparing-and-contrasting-use-case-model-elements-part-1.html
http://www.batimes.com/articles/comparing-and-contrasting-use-case-model-elements-part-2.html
http://www.batimes.com/articles/comparing-and-contrasting-use-case-model-elements-part-3.html

(Cont’d)
Reply | Reply with quote | Quote
0 # Willem 2014-01-19 10:01
(Cont’d from part 1)

Each template has unique characteristics . For example:
1. The Function, Process and Service use case templates have an Initiating Actor section, but the Inclusion and Extension use case templates do not (because they're fragments that don't get initiated from outside the system to which they apply).
2. A Function use case template's Initiating Actor section allows for a custom-defined actor, but the Process use case template's Initiating Actor section specifies "Time" (the same for all Process use cases) and the Service use case template's Initiating Actor section specifies "Electronic Entity" (the same for all Service use cases).
3. The Inclusion use case template has sections for Input Parameters and Output Parameters (for parameterized inclusion use cases), which can be taken out if the template is used to define a textually included inclusion use case.
4. The Service use case template has sections for Input Parameters and Output Parameters as well, but these are mandatory (because each service has these).
5. The Extension use case template obviously has no input and output parameters, but is does enable the writer to refer to the extended use case(s) and to the extension point(s) in the extended use case(s).

There are additional differences that you can discover on your own. By the way, all templates have a Supporting Actor(s) section.

These templates bring with them different writing styles for flows.
1. In a Function use case, each step in a flow is carried out by either the user or the system.
2. In a Process and a Service use case, each step is always carried out by the system.
3. In an Inclusion and an Extension use case, each step is carried out as described in point 1 or point 2, depending on what the use case is about.

I hope this is of some help. Much success in refining your use case modeling practice!

Kind regards,

Willem
Reply | Reply with quote | Quote

Add comment


Security code
Refresh