chapter 28 uml activity diagrams and modeling

Dr. Kivanc Dincer CS319 Week 11 - Nov.21,2005 1

Chapter 28UML Activity Diagrams and Modeling

Objectives

• Introduce UML activity diagram notation, with examples, and various modeling applications.

“ If it wasn’t backed-up, then it wasn’t important.” - The Sysadmin Motto


Introduction

• A UML activity diagram shows sequential and parallel activities in a process.

• They are useful for modeling business processes, workflows, data flows, and complex algorithms as well as use cases.


Fig 28.1 Basic UML activity

diagram notation.

• Once an action is finished, there is an automatic outgoing transition.• The diagram can show both control flow and data flow.

Receive Video Order

Fill Order Send Invoice

Deliver Order

Receive Payment

Close Order

Fulfillment Customer Service

Finance

Order

Invoice

start

Action. It does something. There is an automatic transition on its completion.

A transition supports modeling of control flow.

Fork. One incoming transition, and multiple outgoing parallel transitions and/or object flows.

Partitions. Show different parties involved in the process

Join. Multiple incoming transitions and/or object flows; one outgoing transition.

The outgoing continuation does not happen until all the inputs arrive from all flows.

Object Node. An object produced or used by actions. This allows us to model data flows or object flows.

end of activity


Business Process Modeling

• “A picture worth a thousand words.”• Use activity diagrams when necessary to

understand complex business processes by visualizing them.– See multiple parties and parallel actions involved at

once.

Fig 28.2 Classic DFD notation.

1Check Course

Availability

Courses

2Check Applicant

Qualification

Applications Students

Applicant application

course data

applicationapplication

student data

accept/deny reply

external actor

data store, such as a DB, DB table, or file

data flow

processDFD for Automated Course Registration System


Data Flow Modeling

• In the 1970s, Data Flow Diagrams (DFD) became a popular way to visualize the major steps and data involved in softwarea system processes.

• DFDs were useful to document the major data flows or to explore a new high-level design in terms of data flow.

• UML activity diagrams can be used for data flow modeling, replacing traditional DFD notation.


Fig. 28.3 Applying activity diagram notation to show a data flow model.

Student Registration System

Application

Complete Application

Check Course Availability

«datastore»Courses

«datastore»Applications

Check Applicant Qualification

«datastore»Students

Accept/DenyReply


Fig. 28.4 An activity will be expanded in another diagram.

Fill Order

Deliver Order

the “rake” symbol (which represents a hierarchy) indicates this activity is expanded in a sub-activity diagram


Deliver Regular Deliver Rush

[ rush ][ else ]

Deliver Order

Decision: Any branch happens. Mutual exclusion

Merge: Any input leads to continuation. This is in contrast to a join, in which case all the inputs have to arrive before it continues.

Fig. 28.5 The expansion of an activity.


Fig. 28.6 Signals.

Receive Video Order

Fill Order Send Invoice

Deliver Order

Receive Payment

Close Order

Accept a signal

Resend Invoice

Cancel request

Cancel Order

30 days since sent last invoice, and no payment received

A time signal


Guidelines

• Activity modeling proves most valuable for complex processes, usually involving many parties. Use-case text suffices for simple processes.

• If modeling a business process, take advantage of the “rake” notation and sub-activity diagrams.– On the first overview “level 0” diagram, keep all the

actions at a very high level of abstraction, so that the diagram is short and sweet.

– Expand the detains in subdiagrams at “level 1” and so on.


Fig. 28.7 Modeling the Process Sale use case with an activity diagram.

[ cash payment ]

Enter Cart Items

Calculate Taxes and Discounts

Customer Cashier NextGen POS

Receipt

Shop and Fill Cart

Cart

Submit Authorization

Request

[ else ]

Create Receipt

Hand Over Items

Authorization Service

Authorize Payment


Process: Activity Diagrams in the UP

• One of the UP disciplines is Business Modeling; its purpose is to understand and communicate “the structure and dynamics of the organization in which a system is deployed.”

• A key artifact of the Business Modeling discipline is the Business Object Model, a superset of the UP Domain Model– visualizes how a business works, using UML class,

sequence, and activity diagrams.


Chapter 29UML State Machine Diagrams and Modeling

Objectives

• Introduce UML state machine diagram notation, with examples, and various modeling applications.

“ No, no you’re not thinking, you are just being logical.” - Niels Bohr


Introduction

• As with activity diagrams, UML sate diagrams show a dynamic view.– İllustrates the events and states of things –

transactions, use cases, people, and so forth.


off hookIdle Active

on hook

Telephone

state

transition event

initial state

Fig. 29.1 State machine diagram for a telephone.

• Illustrates the interesting events and states of an object, and the behavior of an object in reaction to an event.

• A state machine diagram shows the lifecycle of an object: what events it experiences, its transitions, and the states it is in between these events.


Events, States and Transactions

• Event – is an occurrence that triggered the state.– A telephone receiver is taken off the hook.

• State – is the condition of a object at a specific time.– A telephone is on “idle” state until it is taken from

the hook.

• Transition – involves going from one state to the other when an event occurs. Transitions are label in form: Event [Guard] / Action.– When the event “off hook” occurs, transition the

telephone from the “idle” state to the “active” state.


Types of Events

• External Event – Events caused by an outside actor, outside of the system’s boundary.

• Internal Event – Events caused by an internal action, inside the system’s boundary.

• Temporal Event – Events caused by a determined date or time clock.


State-Independent and State-Dependent Objects

• If an object always responds the same way to an event, then it is considered state-independent (or modeless) wrt that event.

• By contrast, state-dependent objects react differently to events depending on their state or mode.

• Guideline: Consider state machines for state-dependent objects with complex behavior, not for state-independent objects.


Modeling State-Dependent Objects

– Physical Devices controlled by Software• Microwave oven, Radio

– Transactions - The way transaction respond to events• Cancel a sale

– Role Mutators, i.e., Objects that change their role.• Full-time vs. half-time worker

– Communication Protocols

– UI Page/Window Flow or Navigation

– UI Flow Controllers or Stateful Sessions• Server-side software objects

– Use Case System Operations • For Process Sale: makeNewSale, enterItem, etc.

– Indivitual UI Window Event Handling• Window’s action “Edit-Copy”


Fig. 29.2 Transaction action and guard notation.

Idle

on hook

Active

transition action

guard condition

[valid subscriber]

off hook / play dial tone


Fig. 29.3 Nested states.

Idle

off hook / play dial tone

on hook

Active[valid subscriber]

PlayingDialTone

Dialing Connecting

digitdigit

complete

Talking

connected


Fig. 29.4 Applying a state machine to Web page navigation modeling.


Fig. 29.5 A sample state machine for legal sequence of use case operations.

WatingForSale EnteringItems

enterItem

WaitingForPayment

makeNewSale

makeCashPayment

endSale

AuthorizingPayment makeCheckPayment

makeCreditPayment

authorized

Process Sale


Process: State Machine Diagrams in the UP

• There is not one model in the UP called the “state model.”

• Any element in any model (Design Model, Domain Model, Business Object Model, etc.) may have a state machine to better understand or communicate its dynamic behavior in response to events.


Chapter 30Relating Use Cases

Objectives

• Relate use cases with include and extend associations, in both text and diagram formats.

“ Why do programmers get Halloween and Christmass mixed up? Because OCT(31) = DEC(25).”


Introduction

• Use cases can be related to each other. For example, a subfunction use case such as Handle Credit Payment may be part of several use cases, such as Process Sale or Process Rental.

– Organizing use cases into relationships has no impact on the bahavior or requirements of the system.

– Rather, it is simply an organization machanigm to (ideally) improve communication and comprehension of the use cases, reduce duplication of text, and improve management of the use case documents.


Guideline

• Avoid agonizing over use case relationships– Do not spend unproductive time on debating how to

relate use cases in a use case diagram, rather do the important work: writing text.


The include Relationship

• This is the most common and important relationship.• It is common to have some partial behavior that is

common across several use cases. Rather than duplicate this text, it is desirable to separate it into its own subfunction use case, and indicate its inclusion.

• Guideline: Use include when you are repeating yourself in two or more separate use cases and you want to avoid repetition.

• Guideline: Decompose an overwhelmingly long use case into subunits to improve comprehension.


Using include with Asynchronous Event Handling

• Use include to describe the handling of an asynchronous event, such as when a user is able to, at any time, select or branch to a particular window, function, or Web page, or within a range of steps.


Concrete, Abstract, Base and Addition Use Cases

• A concrete use case is initiated by an actor and performs the entire behavior desired by the actor. There are the elementary business process use cases.– Ex. Process Sale

• An abstract use case is never instantiated by itself; it is a subfunction use case that is part of another use case.– Ex. Handle Credit Payment

• A use case that includes another use case, or that is extended or specialized by another use case is called a base use ease. – Ex. Process Sale wrt Handle Credit Payment

• The use case that is an inclusion, extension, or specialization is called an addition use case. – Ex. Handle Credit Payment in the include relationship to Process Sale.

• Addition use cases are usually abstract. Base use cases are usually concrete.


The extend Relationship

• Suppose a use case’s text should not be modified for some reason, perhaps it is baselined as a stable artifact, and can’t be touched.

• How to append to the use case without modifying its original text?– The extend relationship provides an answer. The idea is to

create an extending or addition use case, and within it, describe where and under what condition it extends the behavior of some base use case.

• Some use case guidelines recommend using extending use cases and the extend relationships to model conditional or optional behavior inserted into the base use case.– Guideline: Prefer to use the Extensions section when

possible to avoid further complication.


2. Cashier enters gift certificate ID.


Fig. 30.1 Use case include relationship in the Use-Case Model.

NextGen POS

Cashier

Customer

Handle CashPayment

Process Rental

Process Sale

Handle CheckPayment

Handle Returns

«include» «include»

«include»

«include» «include»«include»

«actor»Accounting

System

«actor»Credit

AuthorizationService

Manage Users

...

UML notation:the base usecase points tothe included usecase

Handle CreditPayment


Fig. 30.2 The extend relationship.

Process Sale

Extension Points:Payment

VIP Customer

«extend»Payment, if Customer

presents a gift certificate

UML notation:1. The extending use casepoints to the base use case.

2. The condition andextension point can beshown on the line.

Handle Gift CertificatePayment


Chapter 20Mapping Designs to Code

Objectives

• Map design artifacts to code in an object-oriented language.

“ Beware of bugs in the above code; I have only proved it correct, not tried it.”

- Donald Knuth


Introduction

• With the completion of interaction diagrams and DCDs for the current iteration of the case studies, there is more than enough thought and detail to cut some code for the domain layer of objects.

• The UML artifacts created during design work will be used as inpıt to the code generation process.

• UP Implementation Model is all the implementation artifacts, such as source code, database definitions, JSP/XML/HTML pages, and so forth.

• Implementation in an O-O Language requires writing source code fo– Class and interface definitions– Method definitions.


Defining a Class with Method Signatures and Attributes

Fig. 20.1 SalesLineItem in Java.

public class SalesLineItem{private int quantity;

private ProductDescription description;

public SalesLineItem(ProductDescription desc, int qty) { ... }

public Money getSubtotal() { ... }

}

SalesLineItem

quantity : Integer

getSubtotal() : Money

ProductDescription

description : Textprice : MoneyitemID : ItemID

...

1

description


Creating Methods from Interaction Diagrams

Fig. 20.2 The enterItem interaction diagram.

2: makeLineItem(desc, qty)enterItem(id, qty)

1: desc = getProductDesc(id) 2.1: create(desc, qty)

1.1: desc = get(id)

:Register :Sale

:ProductCatalog

sl: SalesLineItem

lineItems : List<SalesLineItem>

: Map<ProductDescription>

2.2: add(sl)


Fig. 20.3 The Register class.

ProductCatalog

...

getProductDesc(...)

Sale

isComplete : Booleantime : DateTime

becomeComplete()makeLineItem(...)makePayment(...)getTotal()

Register

...

endSale()enterItem(id: ItemID, qty : Integer)makeNewSale()makePayment(cashTendered : Money)

public class Register{private ProductCatalog catalog;private Sale currentSale;

public Register(ProductCatalog pc) {...}

public void endSale() {...}public void enterItem(ItemID id, int qty) {...}public void makeNewSale() {...}public void makePayment(Money cashTendered) {...}}

1

1

catalog

currentSale


Fig. 20.4 The enterItem method.


1: desc := getProductDescription(id)

:Register :Sale

:ProductCatalog

{ ProductDescription desc = catalog.ProductDescription(id); currentSale.makeLineItem(desc, qty);}


Fig. 20.5 Adding a collection.

Collection Classes in Code

SalesLineItem

quantity : Integer

getSubtotal()1..*

Sale


becomeComplete()makeLineItem()makePayment()getTtotal()

public class Sale{...

private List lineItems = new ArrayList();}

A collection class is necessary to maintain attribute visibility to all the SalesLineItems.

lineItems


Fig. 20.6 Sale.makeLineItem method.

{ lineItems.add( new SalesLineItem(desc, qty) );}


2.1: create(desc, qty)

:Register :Sale

sl: SalesLineItemlineItems :

List<SalesLineItem>

2.2: add(sl)


Order of Implementation

Fig. 20.7 Possible order of class implementation and testing.

SalesLineItem

quantity : Integer

getSubtotal()

ProductCatalog

...

getProductDesc(...)

ProductDescription

description : Textprice : MoneyitemID : ItemID

...

Store

address : Addressname : Text

addSale(...)

Payment

amount : Money

...

1..*

1..*

Register

...

endSale()enterItem(...)makeNewSale()makePayment(...)

Sale


becomeComplete()makeLineItem(...)makePayment(...)getTotal()...

1

1

1

1

1

1

* 1

23

4

56

7

chapter 28 uml activity diagrams and modeling

Documents

uml activity diagrams

use activity diagrams

subactivity diagrams

modeling business processes

data flow diagrams dfd

uml sate diagrams

uml state machine diagrams

business modeling discipline