Use Case Modeling With Activity And Use Case Diagrams

An Environment Discipline 13 January 2012

2009 copyright Leslie Munday University

Precursor


In order to understand the material in this course, you should have equivalent knowledge of the following:
 

An Introduction To Business Use Cases. Working with AUC documents.

Leslie Munday 2008

1/13/2012

Use Case And Activity Diagrams



In this presentation we will learn:

  

what are the components of a use case diagram. how the use case diagram components are related. what is the difference between an application use case diagram and a business use case diagram. what are the different components of an activity diagram. what are the relationships between the different components. how to represent a business use case with an activity diagram. how to represent an application use case with an activity diagram.

Leslie Munday 2008

1/13/2012

Terms Used In This Presentation

       

   

  

Activity - The specification of an executable statement that includes 1 or more actions and may result in a change in the state of the system. Application the software part of the system under discussion. Artifact Any complete piece of a model. Business Actor Someone who gets benefit from the business use case. Component Anything that can be placed on a diagram. Diagram A graphical depiction of all or part of a model. Model A complete description of a system from a particular perspective. Object - An entity with a well-defined boundary and identity that encapsulates state and behavior. Postcondition the state of the system after a use case has executed. Precondition the state of the system prior to a use case executing. Relationship shows communication between an actor and a use case. State - A condition or situation during the life of an object during which it satisfies some condition, performs some activity, or waits for some event. Package A container for grouping artifacts. System the item under discussion, it may comprise hardware, software or both. System Actor - Someone or something, outside the system that interacts with the system. Use Case A set of actions a that yields an observable result of value to a particular actor.
1/13/2012 4

Leslie Munday 2008

Diagram History
 

     

The use case was invented by Ivar Jacobson and adopted by Rational. The activity diagram is a derivation of the state transition diagram. (State transition diagrams, (STD) as their name suggests contain states connected by transitions.) A transition is triggered by an event. A state is the result of the execution of an event. With the emergence of use cases a diagram was required that also shows events and actions. Actions were added to the STD to create the activity diagram. Think of it as a hybrid of a state transition diagram and a flowchart. Both diagrams are part of the Unified Modeling Language (UML), which is now owned by the Object Management Group (OMG).
1/13/2012 5

Leslie Munday 2008

Overview


The notation used in this presentation is based upon that specified in the UML 1.x specifications, not UML 2.x. The notation is specific to modeling use cases. Where the definition of a component is not relevant to this goal, I either ignore it or redefine it appropriately. The objective is to define a notation that is consistent, easy to use and does not allow ambiguous modeling rules (one way and one way only to represent a concept) yet will not restrain you from expressing everything that is required in your use case model.
1/13/2012 6

Leslie Munday 2008

Why Do We Need Notation?



Don t the UML specifications specify how to draw these diagrams? No, they define the semantics of the symbols used in the diagrams, but do not commit to a consist use on diagrams. UML tries to be all things to all people. It is impossible to use in consistent and unambiguous manner unless guidelines are built around the semantics in order to constrain their rules. For example, Rational recommends that the primary actor in a use case is identified with a directed association. UML contains no such rules or guidelines. I was taught that when two threads are created, from a fork, (which run concurrently) that neither thread could continue (return to the main path) until both threads reached a join. According to the UML specifications, concerning forks and joins, either can be used without the other. In my understanding this does not make sense because the threads will never complete, hence the use case will never end.
1/13/2012 7

Leslie Munday 2008

The Use Case Diagram



There are two types of use case diagram:

 

business use case (BUC) diagram. application use case (AUC) diagram.

The business use case diagram describes the activities performed by any number of business workers (people) in order to achieve a business goal (whether they are manual or automated is not specified in the BUC). The application use case describes the activities performed by the software in order to achieve a system goal.
1/13/2012 8

Leslie Munday 2008

Use Case Diagram Overview



A use case diagram contains actors, use cases and relationships between them. If a use case diagram becomes difficult to read on a single page, then break it into 2 diagrams. I recommend, especially for systems with a large number of use cases, showing actors connecting to a single use case, by duplicating the actor. In this manner restructuring the use case diagram is much simpler.
1/13/2012 9

Leslie Munday 2008

Common To Use Case Diagrams



Indicate the primary actor using an arrowhead on the relationship entering the use case. Indicate secondary actors by using no arrowheads on the relationship line. Included use cases have an arrowhead entering the use case and the relationship contains the stereotype <<include>>. Extending use cases have an arrowhead entering the use case being extended and the relationship contains the stereotype <<extend>>.
1/13/2012 10

Leslie Munday 2008

Business Use Case Diagrams

 

The primary actor is the stakeholder that is getting benefit from the BUC. The secondary actors are people outside the business, that interact with the activity of the BUC. Some modeling tools will distinguish a BUC from an AUC by placing a line through the use case shape; alternatively give the BUC a stereotype named Business . Some guidelines distinguish between business actors and system actors; rarely do I find this necessary. (If a role of the same name appears in both organizations; business and system, but they perform different roles, then distinguishing between business and system actors may be necessary.)

Leslie Munday 2008

1/13/2012

11

Application Use Case Diagrams



The primary actor is the role that initiates the execution of the AUC. The secondary actors are applications or people outside of the AUC that interact with the use case.

Leslie Munday 2008

1/13/2012

12

Using Inheritance In Use Cases



When two or more roles are the primary actor of a use case, create a common role and use the generalization relationship to inherit that role s capabilities. The systems and business process analysts both inherit everything the analyst role does. I have rarely found a need to use the generalization relationship between use cases. If anything I have found that it adds ambiguity to the use cases.
1/13/2012 13

Leslie Munday 2008

The Activity Diagram Components

    

Initial Node Control Flow Action or Activity Object Flow Branch Merge Fork Join Final Node

 

Leslie Munday 2008

1/13/2012

14

Initial Node


This represents the start of the flow of an activity diagram. An activity diagram contains a single start node. The name of the initial node is entered on the node. It takes the form of an adjective.
1/13/2012 15

Leslie Munday 2008

Control Flow


A control flow connects any combination of:

    

activities branches merges forks joins

  

A control flow has direction, which is indicated by the arrow head you may only traverse the control flow in the direction of the arrow. A control flow may not enter an initial state. A control flow may not exit a final node. A control flow is the representation of an occurrence of an event. The name of the event is entered on the control flow. It takes the form of something has been done, nounverb(past-tense)

Leslie Munday 2008

1/13/2012

16

Activity And Action



The activity represents the actions that occur as a result of an incoming event from a control flow. The name of the activity is entered on the activity and takes the form of something being done, present tense verb-noun

Leslie Munday 2008

1/13/2012

17

Branch
     

The branch is used to show alternative paths in the activity diagram. Label the decision node with a question(?). Do not label the merge, (unless you have a good reason to). One control flow enters the decision node and two or more alternative control flows exit the decision node. Only one of the paths may be transitioned as the result of an event occurring. Each exiting control flow contains the condition under which it is taken (called a guard), dependent upon the answer to the question. These guards must be mutually exclusive. The guards on exiting control flows must cover all possible outcomes of the question being asked by the branch.


The simplest way to ensure all possible outcomes are covered is to phrase the branch question such that the only possible answers are Yes or No . Note, this can add extra branches to the diagram.

Two or more control flows enter the merge node and one control flow exits.
1/13/2012 18

Leslie Munday 2008

Fork
 

The fork may be represented by vertical or horizontal bars. The fork represents that the flow through the diagram has split into 2 paths that are running in parallel (multitasking). The fork has a single control flow on entry and several control flows exiting. Use a fork when there is no requirement on the order of activities in a flow.


For example, the Dematerializer receives an event that the door is shut. It now suspends the cargo and creates a vacuum, but these actions may be performed in parallel, so we model them with a fork.

Leslie Munday 2008

1/13/2012

19

Join


For every fork there should be a join (if not your activity diagram is broken). The join may be represented by vertical or horizontal bars. A join simply shows that when the parallel activities have finished that they then come back to join a single flow again. The join has several control flows entering and a single control flow on exit. The exiting control flow cannot be executed until every incoming control flow has completed. There is no need to label the fork or join.
1/13/2012 20

Leslie Munday 2008

Final Node


The final node represents the termination of the activity diagram. There may be several termination states in a single diagram. Label the final node with an adjective.

Leslie Munday 2008

1/13/2012

21

The Use Case Details



How does the activity diagram relate to the use case template? Each component of the activity diagram represents a detail in the use case, as follows:
       

Precondition Initial state. User step Event. System action Activity. Alternate flow Decision. Alternate flow returning to the basic flow Merge. System activities running in parallel Fork. Parallel activities joining the basic flow Join. Postcondition Final node.
1/13/2012 22

Leslie Munday 2008

Mapping To The Use Case?

   

   

Precondition Actor input System Step Alternative or extension flow Basic Flow Returning alternate flow Parallel activities Postcondition
1/13/2012 23

Leslie Munday 2008

Dematerialize Cargo Example 1




Precondition
The system is ready to transport cargo.


1.

Basic Flow
The system receives a command to open the door to the Dematerializer. The system opens the door to the Dematerializer. The system receives a command to transport the cargo. The Transmitter is ready to transmit and the system closes the door to the Dematerializer.

2.

3.

4.


1.

Alternate Flow
At step 4, the Transmitter is not ready to transmit, and the system waits for the transmitter to be ready to transmit. The Transmitter is ready to transmit and the use case continues from step 4.
1/13/2012 24

2.

Leslie Munday 2008

Dematerialize Cargo Example 2


6.

Basic Flow (continued)

The system sends the deconstructed cargo to the Transmitter and sends the cargo blueprint to the Blueprint Manager. The system removes the vacuum from the Dematerializer. The vacuum is removed and the use case ends.

7.

8.




Postcondition
The system is ready to transmit cargo.


1.

Extension Flow
At step 8, the system is set to shutdown when the cargo is transmitted, and the systems performs a shutdown. The system shutsdown and the use case ends.

2.




Postcondition
The system is shutdown
1/13/2012 25

Leslie Munday 2008

Advanced Notation


In addition to the basic activity diagram components there are:

 

Objects and object flows. Swimlanes.

Objects are used to identify potential analysis classes. Swimlanes can be used on BUC activity diagrams to group activities or indicate roles that perform an activity.
1/13/2012 26

Leslie Munday 2008

Swimlanes


Consider the following activity diagram which describes the Exploring Automation Requirements workflow from the business modeling discipline. Set And Adjust Goals activity is performed by the business process analyst. Define Automation Requirements activity is performed by the business designer. The activities performed by the same role (or department) are positioned such that they all fall into the same vertical column. Beware: swimlanes can become very expensive to maintain, you might want to consider using stereotypes to identify the role.
1/13/2012 27

Leslie Munday 2008

Swimlane Example Diagram

Leslie Munday 2008

1/13/2012

28

Another Swimlane Example



This example demonstrates how swimlanes can be used to define the steps of a business use case that are to be automated.
1/13/2012 29

Leslie Munday 2008

Object


 

Objects represent external information that is being manipulated by the use case. Every use case activity should be reading from or writing to at least one object, (otherwise how can you test that the activity executed). Any data manipulated by an activity, should be shown as being input from an object. The results are output to an object. The object takes the name of an instance of its class.
1/13/2012 30

Leslie Munday 2008

AUC With Objects



The Opening Door activity sends an open command to the door object. The Waiting For Transmitter activity reads the status of the transmitter object. The objects are instances of the Door and Transmitter classes.
1/13/2012 31

Leslie Munday 2008

Why Model Use Cases?



Gives an overview of your use case steps without having to read the details. Performing a simulated execution, aids identifying missing or misplaced steps in the use case. Shows the alternative paths through the use case with the basic flow. Allows for a consistent and unambiguous method for specifying the steps in the use case. It s a faster way to get the basic flow from the stakeholders (they will thank you in the long term).

Leslie Munday 2008

1/13/2012

32

Naming Conventions
 

 

 

Name events in the past tense with text that describes what happened in order to trigger the event. Text of the form of Verb Noun is appropriate, (or Noun Verb if preferred, but be consistent). Activities should be named in the present tense with text that describes what is currently happening. Text of the form Doing Something With Noun is appropriate. The control flows exiting a fork synchronization bar are effectively the same as the control flow entering the fork and do not need to be named. The control flow exiting a join synchronization bar is effectively a combination of all entering control flows. It is not necessary to label the exiting control flow. Use Capitalized Words for names of activities, events and guards. The start state should be labeled such that it describes a precondition of the activity diagram (i.e. the state of the system or business prior to the occurrence of the event that control flows out of this state). Label the end state with text that describes the postcondition of the system/business when the end state is reached. Label a decision with text representing the question being asked, followed by a ? . It is not necessary to label a merge, fork or join.

Leslie Munday 2008

1/13/2012

33

Activity Diagram Semantics

  

Every activity diagram should have exactly one start state. Every activity diagram should contain one or more end states. Every activity should have at least one entering control flow and one exiting control flow. (An activity with no entering control flow will never be executed. An activity with no exiting control flow will never terminate.) Ensure that the labels on the control flows exiting a decision cover every possible outcome to the question being asked by the decision node. Ensure that no two exiting control flows from a decision can take the same answer to the question. Use the [guard] field to label the outgoing control flows from a decision; because the text does not represent an event, it represents a guard on the incoming event. Avoid placing activities (or any other activity diagram component) within activities. If you feel the need to break your activity into smaller sub-activities (the general semantic meaning of placing activities within activities) it suggests that the activities are too complex and their scope should be re-visited. For every fork synchronization bar there should be a corresponding join synchronization bar. The join synchronization bar allows every activity on a parallel path in the fork, to complete. The omission of a join synchronization bar indicates that the activity diagram can end with an activity not completed.

Leslie Munday 2008

1/13/2012

34

Exercise


 

Create a use case diagram that shows a customer making a withdrawal and a deposit with an ATM. Model The ATM example use case With An Activity Diagram. There are no right answers. There is no industry standard for modeling use cases.

Leslie Munday 2008

1/13/2012

35