Use Case and Activity Diagrams Modeling Notation

Use Case Modeling With Activity And Use Case Diagrams An Environment Discipline June 8, 2009

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. 06/08/09

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. 06/08/09

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. Terms Used In This Presentation 06/08/09

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). 06/08/09

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. 06/08/09

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. 06/08/09

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. 06/08/09

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. 06/08/09

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>>. 06/08/09

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.) 06/08/09

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. 06/08/09

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. 06/08/09

The Activity Diagram Components Initial Node Control Flow Action or Activity Object Flow Branch Merge Fork Join Final Node 06/08/09

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. 06/08/09

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, noun-verb(past-tense) 06/08/09

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 06/08/09

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. 06/08/09

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. 06/08/09

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. 06/08/09

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. 06/08/09

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. 06/08/09

Mapping To The Use Case? Precondition Actor input System Step Alternative or extension flow Basic Flow Returning alternate flow Parallel activities Postcondition 06/08/09

Dematerialize Cargo Example 1 Precondition The system is ready to transport cargo. 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. 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. 06/08/09

Dematerialize Cargo Example 2 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. Postcondition The system is ready to transmit cargo. 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. Postcondition The system is shutdown 06/08/09

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. 06/08/09

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. 06/08/09

Swimlane Example Diagram 06/08/09

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. 06/08/09

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. 06/08/09

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. 06/08/09

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). 06/08/09

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. 06/08/09

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. 06/08/09

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. 06/08/09

Use Case and Activity Diagrams Modeling Notation

More Related Content

What's hot

Similar to Use Case and Activity Diagrams Modeling Notation

More from Leslie Munday

In this document

Use Case and Activity Diagrams Modeling Notation