Modeling with UML - Department of Computer Science -...

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 1

Modeling with UML

Dr. Anne Ngu


Outline of this Class

•  Use case diagrams •  Describe the functional behavior of the system as seen

by the user

•  Class diagrams •  Describe the static structure of the system: Objects,

attributes, associations

•  Sequence diagrams •  Describe the dynamic behavior between objects of the

system

•  Statechart diagrams •  Describe the dynamic behavior of an individual object

•  Activity diagrams •  Describe the dynamic behavior of a system, in

particular the workflow.


Class Diagrams

•  Class diagrams represent the structure of the system

•  Used •  during requirements analysis to model application

domain concepts •  during object design to specify the detailed behavior

and attributes of classes.

Table zone2priceEnumeration getZones()Price getPrice(Zone)

TarifSchedule

* *

Tripzone:Zone

Price: Price


Classes

•  A class represents a concept •  A class encapsulates state (attributes) and behavior

(operations)

Table zone2priceEnumeration getZones()Price getPrice(Zone)

TarifSchedule

zone2pricegetZones()getPrice()

TarifSchedule

Name

Attributes

Operations

Signature

TarifSchedule

The class name is the only mandatory information

Each attribute has a type Each operation has a signature

Type


Instances

•  An instance represents a phenomenon •  The attributes are represented with their values •  The name of an instance is underlined •  The name can contain only the class name of the instance

(anonymous instance)

zone2price = {{‘1’, 0.20}, {‘2’, 0.40},{‘3’, 0.60}}

tarif2006:TarifSchedulezone2price = {{‘1’, 0.20}, {‘2’, 0.40},{‘3’, 0.60}}

:TarifSchedule


Actor vs Class vs Object

•  Actor •  An entity outside the system to be modeled,

interacting with the system (“Passenger”) •  Class

•  An abstraction modeling an entity in the application or solution domain

•  The class is part of the system model (“User”, “Ticket distributor”, “Server”)

•  Object •  A specific instance of a class (“Joe, the passenger who

is purchasing a ticket from the ticket distributor”).


Associations

Associations denote relationships between classes

Price Zone

Enumeration getZones()Price getPrice(Zone)

TarifSchedule

* *

The multiplicity of an association end denotes how many objects the instance of a class can legitimately reference Association can be directional

Trip


1-to-1 and 1-to-many Associations

1-to-1 association

1-to-many association

Country

name:String

City

name:String

11

*


Many-to-Many Associations

StockExchange

Company

tickerSymbol**


From Problem Statement to Code

Problem Statement : A stock exchange lists many companies. Each company is identified by a ticker symbol

Class Diagram:

private Vector m_Company = new Vector();

public int m_tickerSymbol; private Vector m_StockExchange = new Vector();

public class StockExchange{

};

public class Company{

};

Java Code

StockExchange Company

tickerSymbolLists **

Associationsare mapped to

Attributes!


Association Class

Field Officier Incident* 1

Alocates

Role: StringnotificationTime: Time

The allocation of field officer to an incident


Aggregation •  An aggregation is a special case of association denoting

a “consists-of” or “part-of” hierarchy •  The aggregate is the parent class,

the components are the children classes

Exhaust system

Mufflerdiameter

Tailpipediameter

1 0..2

TicketMachine

ZoneButton3

A solid diamond denotes composition: A strong form of aggregation where the life time of the component instances is controlled by the aggregate. That is, the parts don’t exist on their won (“the whole controls/destroys the parts”)


Inheritance

•  Inheritance is another special case of an association denoting a “kind-of” hierarchy

•  Inheritance simplifies the analysis model by introducing a taxonomy

•  The children classes inherit the attributes and operations of the parent class.

Button

ZoneButtonCancelButton


Constraints and Notes

•  Constraints are an extension of the semantics of a UML element, allowing one to add new rules or modify existing ones. Sometimes it is helpful to present an idea about restrictions on attributes and associations for which there is no specific notation.

•  Constraints are represented by a label in curly brackets ({constraintName} or {expression}) that are attached to the constrained element. The expression is expressed in OCL (Object Constraint Language)


Constraints and Notes (cont’d)


Packages

•  Packages help you to organize UML models to increase their readability

•  We can use the UML package mechanism to organize classes into subsystems

•  Any complex system can be decomposed into subsystems, where each subsystem is modeled as a package.

Account

CustomerBank


Information Model via linguistics analysis

•  Identify the classes. The classes derive from noun phrases. Go through the requirements statement and pick out all of the important nouns. Categorize these nouns into tangible items or devices, physical classes, roles, interactions, instance specifications, etc.. Decide which ones are significant and which ones are redundant and select classes.

•  2. Define attributes for each object. Attributes come from possessive phrases, as descriptions of the nouns. Recall that the attributes define the identity and the state of an object.

•  3. Define relationships. Relationships can be derived by looking at the verb phrases of the requirements analysis. Verb phrases include such things as the PC board “is made up of” chips and connectors, etc..

•  4. Specialize and generalize classes into subtypes and supertypes and create associations, create object definitions for m to n associations or dynamic associations which fall under the heading of events, interactions which have to be remembered.


Example – Online Stock Trading •  A stock brokerage firm wants to provide an online stock

trading service to enable its clients to trade via the computer. With this system, a client must first be registered before he can trade online. The registration process involves the client providing his ID, address and telephone number. A client may open one or more accounts for stock trading. The stock brokerage firm needs to be registered with a stock exchange before its clients can trade the stocks listed on the stock exchange. A stock brokerage firm can be registered with one or more stock exchanges. The stock brokerage firm may need to pay monthly charges for using the services provided by the stock exchange.


Example – Online Stock Trading (cont’d) •  Once registered, the client can buy and sell stocks.

The client can check the current price, bid price, ask price and traded volume of a stock in real time. The stock price and traded volume information is provided by the stock exchange on which the stock is listed and traded. When a client issues a buy order for an account, the client must specify the stock code, the number of shares and the maximum price that he is willing to pay for them (the bid price). A client must have sufficient funds in his account to settle the transaction, when it is completed. When a client issues a sell order, the client must specify the stock code, the number of share and the minimum price that he is willing to sell them (the ask price). The client must have sufficient shares of the stock in his account before he can issue the sell order.


Example – Online Stock Trading (cont’d) •  A client can check the status of execution of his (buy or

sell) orders. The client can issue a buy or sell order before the end of the trading day of the stock exchange which processed the order. All trade orders will be forwarded to the stock trading system of the stock exchange for execution. When an order is completed, the stock trading system of the stock exchange will return the transaction details of the order to the online stock trading system. The transaction details of a trade order may be a list of transactions, each transaction specifying the price and the number of shares traded. For example, the result of a buy order of 20,000 HSBC (stock code: 0005) shares at HK$88.00 on the Hong Kong Stock Exchange may be as follows:

•  4,000 shares at HK$87.50, •  8,000 shares at HK$87.75, and •  8,000 shares at HK488.00.


Example – Online Stock Trading (cont’d) •  An order will be kept on the system for execution until the order

is completed or the end of a trading day is reached. There are three possible outcomes for a trade order: 1.  The trade order is completed. For a buy order, the total

amount for the buy order will be deducted from the client’s account and the number of shares of the stock purchased deposited into the account. For a sell order, the number of shares sold will be deducted from the client’s account and the proceeds of the sell order deposited into the client’s account.

2.  The trade order is partially completed. The number of shares actually traded (sell or buy) is less than the number of shares specified in the order. The number of shares successfully traded in the order will be used for the calculation of the amount of the proceeds, and the client’s account adjusted accordingly.

3.  The trade order is not executed by the end of a trading day. The order will be canceled.


Identifying objects and classes •  To identify objects and classes, perform a

textual analysis to extract all nouns and noun phrases from the problem statement.

•  Nouns or noun phrases of the following categories are more likely to represent objects:

•  Tangible things (e.g. classroom, playground) •  Conceptual things (e.g. course, bank account) •  Events (e.g. test, incident) •  Outside organizations (e.g. publisher, supplier) •  Roles played (e.g. student, teacher, principal) •  Other systems (e.g. admission system, grade

reporting system)


Practice in Object Analysis: Identifying objects and classes

Stock brokerage firm (conceptual) Buy order (event)

Monthly charge Stock code (simple value, attribute)

Trade (event) Number of shares (simple value, attribute)

Trade order (event) Maximum price (simple value, attribute)

Computer (tangible thing) Transaction (event)

Client (role played) Sell order (event)

ID (simple value, attribute) Trading hours (simple value, attribute)

Address (simple value, attribute) Trading day (simple value, attribute)

Telephone number (simple value, attribute) Stock trading system (other systems)

Account (conceptual) Order (event)

Stock exchange (outside organization) Execution result (event)


Identifying objects and classes (Cont.)

Stock (conceptual) Hong Kong Bank (instance of stock)

Current price (simple value, attribute) Hong Kong Stock Exchange (instance of stock exchange)

Bid price (simple value, attribute) Lot size (simple value, attribute)

Ask price (simple value, attribute) Registration process (not an object)

Traded volume (simple value, attribute)


Categories of Inappropriate Classes

Category Description

Redundant classes

Classes that mean the same thing. Choose the most descriptive class. For example, order, trade and trade order mean the same thing. Eliminate trade and order, and keep trade order.

Irrelevant classes

Those classes which are not directly related to the problem. For example, monthly charge is not directly related to the system.

Vague classes Classes with a loosely defined scope.

Attributes Attributes of classes also represent as nouns or noun phrases. Therefore, the list of nouns or noun phrases extracted by textual analysis may contain attributes of classes. For example, address and telephone number are attributes of the client. So are the

various prices.


Categories of Inappropriate Classes (cont’d)

Category Description

Operations The performance of actions is sometimes expressed as nouns or noun phrases. For example, the registration process is the action taken by the client to register on the system. It should be considered an operation of a class, rather than a class.

Roles The role names help to differentiate the responsibilities of the objects in an interaction. However, they should not be considered as classes.

Implementation constructs

Sometimes, implementation details of a particular solution are written in the problem statement, for example, array, indexed sequential file, etc. Candidate classes representing the implementation details should be removed, e.g. Computer


Inappropriate Classes

Stock brokerage firm (irrelevant) Stock code (attribute)

Monthly charge (irrelevant) Number of shares (attribute)

Trade (redundant) Maximum price (attribute)

Computer (implementation) Trading hours (attribute)

ID (attribute) Trading day (attribute)

Address (attribute) Order (redundant)

Telephone number (attribute) Hong Kong Bank (instance of stock)

Current price (attribute) Hong Kong Stock Exchange (instance of stock exchange)

Bid price (attribute) Lot size (attribute)

Ask price (attribute) Registration process (operation)

Traded volume (attribute)


Revised Candidate Classes

Trade order (event) Transaction (event)

Client (role played) Sell order (event)

Account (concept) Stock trading system (other systems)

Stock exchange (outside organization)

Execution result (event)

Buy order (event) Stock (concept)


Identifying Associations between Classes

•  An association is a relationship between objects.

•  For example, John and Peter are instances of the class Person and John is the father of Peter.

•  Association can be identified by looking for verbs and verb phrases connecting two or more objects in the problem statement.

•  e.g. “A client may open one or more accounts for stock trading.”

•  Name of the association: has or opened by? •  The name of the association should reflect

the nature rather than the historic event.


Identifying Associations between Classes (cont’d)

Verb phrase Association

A client may open one or more accounts for stock trading. has

When a client issues a buy order for an account, the client must specify the stock code, number of shares and the maximum price that he is willing to pay for them (the bid price).

issued by, buy

When a client issues a sell order for an account, the client must specify the stock code, the number of share and the minimum price that he is willing to sell them (the ask price).

issued by, sell

All trade orders will be forwarded to the stock trading system of the stock exchange for execution.

executed by

When an order is completed, the stock trading system of the stock exchange will return the transaction details of the order to the online stock trading system.

returned by

The transaction details of a trade order may be a list of transactions, and each transaction specifies the price and the number of shares traded.

consists of


Identifying Associations between Classes (cont’d)n  From the domain knowledge, we have

the following associations: n  A stock is listed on a stock exchange. n  A stock is traded on a stock trading

system of a stock exchange. n  The result of a trade order is a list of

transactions. n  A stock exchange has one or more stock

trading systems.


Verifying Access Paths for Likely Queries

•  Check whether the class diagram can provide the correct answers to queries that are common the applications in the domain.

•  In the online stock trading system example, a typical client query would be the current stock balance of his account.

•  This requires an association between the account class and the stock class to provide the information on the number of shares held in the account.


Verifying Access Paths for Likely Queries (cont’d)


UML Use Case Diagrams

An Actor represents a role, that is, a type of user of the system

Passenger

PurchaseTicket

Used during requirements elicitation and analysis to represent external behavior (“visible from the outside of the system”)

Use case model: The set of all use cases that completely describe the functionality of the system.

A use case represents a class of functionality provided by the system


Guidelines for Identifying Use Cases

•  The following questions may be useful in collecting information from users:

•  What are the main tasks carried out by each actor?

•  What data are manipulated and processed by the actor?

•  What goals does an actor want to achieve using the system?

•  What are the major problems with the current system and how could the proposed system simplify the work of the user/actor?


Actors

•  An actor is a model for an external entity which interacts (communicates) with the system:

•  User •  External system (Another system) •  Physical environment (e.g. wearable

device) •  An actor has a unique name and an

optional description •  Examples:

•  Passenger: A person in the train •  GPS satellite: An external system that

provides the system with GPS coordinates.

Passenger

Name

Optional Description


Use Case • A use case represents a class of

functionality provided by the system

• Use cases can be described textually, with a focus on the event flow between actor and system

• The textual use case description consists of 6 parts: 1. Unique name 2.  Participating actors 3.  Entry conditions 4.  Exit conditions 5.  Flow of events 6.  Special requirements.

PurchaseTicket


Textual Use Case Description Example

1. Name: Purchase ticket 2. Participating actor: Passenger

3. Entry condition: •  Passenger stands in front

of ticket distributor •  Passenger has sufficient

money to purchase ticket

4. Exit condition: •  Passenger has ticket

5. Flow of events: 1. Passenger selects the

number of zones to be traveled

2. Ticket Distributor displays the amount due

3. Passenger inserts money, at least the amount due

4. Ticket Distributor returns change

5. Ticket Distributor issues ticket

6. Special requirements: None.

PassengerPurchaseTicket


Uses Cases can be related

•  Extends Relationship •  To represent seldom invoked use cases or exceptional

functionality

•  Includes Relationship •  To represent functional behavior common to more than

one use case.


The <<extends>> Relationship •  <<extends>> relationships

model exceptional or seldom invoked cases

•  The exceptional event flows are factored out of the main event flow for clarity

•  The direction of an <<extends>> relationship is to the extended use case

•  Use cases representing exceptional flows can extend more than one use case.

Passenger

PurchaseTicket

TimeOut

<<extends>>

NoChange

<<extends>>OutOfOrder

<<extends>>

Cancel

<<extends>>


The <<includes>> Relationship •  <<includes>> relationship

represents common functionality needed in more than one use case

•  <<includes>> behavior is factored out for reuse, not because it is an exception

•  The direction of a <<includes>> relationship is to the using use case (unlike the direction of the <<extends>> relationship).

Passenger

PurchaseSingleTicket

PurchaseMultiCard

<<includes>>

CollectMoney

<<includes>>

NoChange

<<extends>>

Cancel

<<extends>>

Cancel

<<extends>>


Inheritance (or Generalization) relationship

•  Used when one use case is a specialization of another

✦ It adds more detail

43

• Solid arrow points to the generalized use case


Use Case Relationships Compared

44

Generalization Extend Include

Base use case could be abstract use case(incomplete) or concrete (complete).

Base use case is complete (concrete) by itself, defined independently.

Base use case is incomplete (abstract use case).

Specialized use case is required, not optional, if base use case is abstract.

Extending use case is optional, supplementary.

Included use case required, not optional.

No explicit location to use specialization.

Has at least one explicit extension location.

No explicit inclusion location but is included at some location.

No explicit condition to use specialization.

Could have optional extension condition.

No explicit inclusion condition.


A larger sample use case diagram

45

How could the names of the use cases be improved?


Sequence Diagrams

•  Used during analysis •  To refine use case descriptions •  to find additional objects

(“participating objects”) •  Used during system design

•  to refine subsystem interfaces •  Instances are represented by

rectangles. Actors by sticky figures

•  Lifelines are represented by dashed lines

•  Messages are represented by arrows

•  Activations are represented by narrow rectangles.

selectZone()

pickupChange()

pickUpTicket()

insertCoins()

TicketMachinePassenger

Focus on Controlflow

Messages ->Operations on

participating Object

zone2priceselectZone()insertCoins()pickupChange()pickUpTicket()

TicketMachine


Sequence Diagrams can also model the Flow of Data

•  The source of an arrow indicates the activation which sent the message

•  Horizontal dashed arrows indicate data flow, for example return results from a message

Passenger

selectZone()

ZoneButton TarifSchedule Display

lookupPrice(selection)

displayPrice(price)

price

Dataflow…continued on next slide...


Sequence Diagrams: Iteration & Condition

•  Iteration is denoted by a * preceding the message name •  Condition is denoted by boolean expression in [ ] before

the message name

Passenger ChangeProcessor

insertChange(coin)

CoinIdentifier Display CoinDrop

displayPrice(owedAmount)

lookupCoin(coin)

price

[owedAmount<0] returnChange(-owedAmount)

Iteration

Condition

…continued on next slide...

…continued from previous slide...

*


Branching

ConditionalMessage

Transmission


Using alt box to show branching.


Recursion

Recursion


Creation and destruction

•  Creation is denoted by a message arrow pointing to the object •  Destruction is denoted by an X mark at the end of the

destruction activation •  In garbage collection environments, destruction can be used to

denote the end of the useful life of an object.

Passenger ChangeProcessor

…continued from previous slide...

Ticket

createTicket(selection)

free()

Creation of Ticket

Destruction of Ticket

print()


Example - A Soft Drink Vending Machine


Sequence Diagram Properties

•  UML sequence diagram represent behavior in terms of interactions

•  Useful to identify or find missing objects •  Time consuming to build, but worth the

investment •  Complement the class diagrams (which

represent structure).


State Diagram of the – Control Object of Vending Machine


Statechart Diagram

Active Inactive Closed ArchivedIncident-Handled

Incident-Documented

Incident-Archived

Statechart Diagram for IncidentFocus on the set of attributes of a single abstraction (object, system)

Event causesstate transition


UML Summary

•  UML provides a wide variety of notations for representing many aspects of software development

•  Powerful, but complex

•  UML is a programming language •  Can be misused to generate unreadable models •  Can be misunderstood when using too many exotic

features

•  We concentrated on a few notations: •  Functional model: Use case diagram •  Object model: class diagram •  Dynamic model: sequence diagrams and statechart

Modeling with UML - Department of Computer Science -...

Documents

Transcript of Modeling with UML - Department of Computer Science -...