Unified Modelling Language

OOA/OOD

a summary of the book:

Applying UML and Patterns, Craig Larman

D. Dranidis
October 2000
CITY College

1
 Introduction
• Owing a hammer doesn’t make one an architect
– Analysing and designing a system from an object perspective is critical

• UML
– “... a language for specifying, visualising and constructing the artefacts
of software systems...” [BJR97]
– a mainly diagrammatic notation for modelling systems using object-
oriented concepts.
• Patterns
– Problem-solution formulas that codify exemplary design principles
• Development process
– order of activities in a development life-cycle
• Study of a simple case study

2
 Object oriented Analysis and Design
• Analysis
– investigation of the problem: what the problem is about and what the
system must do.
• OOA
– finding and describing objects (concepts) in the problem domain.
• Design
– logical solution: how the system fulfils the requirements
• OOD
– defining logical software objects with attributes and methods

3
 What is UML?
• G. Booch and J. Rumbaugh (1994) and later I. Jacobson
– Booch method
– OMT (Object Modelling Technique)
– OOSE (OO Software Engineering)
• De facto approval in industry
• Modelling language
• DOES NOT define a standard methodology process

4
 Sample Development Activities
• Disadvantages of Waterfall Life-cycle
– complexity overload
– delayed feedback
– frozen specifications, while business environment changes
• Recommended development process [Booch96]
– iterative and incremental
– use case driven
– early emphasis on defining the architecture: high level structure of subsystems and
components
• Iterative
– planned process of revisiting an area, each time enhancing the system
• Incremental
– add functionality to a system during several release cycles
• An incremental release is composed of multiple iterative development cycles
• Time-boxing a Development cycle (between 2 weeks and two months).

5
 Case Study:
Point-of-Sale-Terminal (POST)
• Computerised system used to record sales and handle payments.
• HW components: computer and bar code scanner
• Architectural layers:
– Presentation: GUI
– Application Logic: Problem Domain Objects
– Application Logic: Service Objects - non problem domain objects,
such as interfaces to a database
– Storage: persistent storage mechanism.
• Iterative development strategy:
– 1st development cycle: simple core-functions application
– 2nd development cycle: expansion of the functionality

6
 Use Cases
• Use cases are dependent on having at least partial understanding of
the requirements of the system.
• Use case:
– narrative document that describes the sequence of events of an actor
(external agent) using a system to complete a process.
– story of using a system
– illustrates and implies requirements in the story it tells
• Actors:
– external entities to the system who participate in the story of a use
case
– roles that humans play, computer systems, devices

7
 Use Cases within a Development Process
• Plan and Elaborate Phase
– Define system boundary. Identify actors and use cases
– Write high-level use cases
– Draw a use-case diagram
– Write expanded use cases for the most critical, influential or risky use
cases. Defer rest use cases.
– Rank use-cases

8
 Identifying Use Cases
• Identify actors related to a system
– Cashier
– Customer
• For each actor, identify the processes they initiate or participate in
– Log In, Cash Out,
– Buy Items, Refund Items

• All system functions identified during the requirements specification

should be allocated to use cases

9
 Example of a High-level Use Case: Buy Items
• Use Case: Buy Items
• Actors: Customer, Cashier
• Type: primary
• Description:
– A Customer arrives at a checkout with items to purchase. The Cashier
records the purchase items and collects payment. On completion, the
Customer leaves with the items.

10
 Example of an Expanded Use Case: Buy Items
• Use Case: Buy Items
• Actors: Customer (initiator), Cashier
• Purpose: Capture a sale and its payment
• Type: primary
• Overview:
– A Customer arrives at a checkout with items to purchase. The Cashier
records the purchase items and collects a payment, which may be
authorised. On completion, the Customer leaves with the items.
• Cross References:
– Functions: R1.1, R1.2, etc
– Use cases: Cashier must have completed the Log In use case.

• continues...

11
 Typical Course of Events
Actor Action System Response
1. This use case begins when a Customer
arrives at the POST checkout with items
to purchase.
2. The cashier records each item.
3. Determines the item price and adds the
If there is more than one of an item, the item information to the running sales
Cashier can enter the quantity as well. transaction.
The description and price of the current
item are presented.
4. On completion of item entry, the Cashier
5. Calculates and presents the sale total.
indicates to the POST that item entry is
complete.
6. The Cashier tells the Customer the total.
7. Customer chooses payment type:
a. If cash payment initiate Pay by Cash. 8. Logs the completed sale.
b. if credit payment initiate Pay by Credit. 9. Updates inventory levels.
11. The Cashier gives the receipt to the 10. Generates a receipt.
Customer.
12. The Customer leaves with the items
purchased.

Alternative courses
Line 2: Invalid item identifier entered. Indicate error.
Line 7: Customer could not pay. Cancel sales transaction.
12
 Use Case Diagram
• Partial use case diagram

POST

Log In

Cashier
Customer Buy Items

Pay By Credit Pay By Cash

13
 Allocation of use cases to development cycles
• Buy Items version 1 is a simplified version of the original use case.

• Each development cycle con sists of

– Plann ing, Analysis, Design , Construction, Testing

Development Development Development

Cycle 1 Cycle 2 Cycle 3

Buy Items Buy Items Refund

version 1 version 2

Log In

14
 An
Building a Conceptual Model

al
ys
is
• Representation of concepts in a problem domain;
of real-world things, not of software components
• Static structure diagrams (no operations)
– concepts
– associations between concepts
– attributes of concepts

• It is better to overspecify a conceptual model with lots of fine-grained

concepts, than to underspecify it!

• A good conceptual model

– captures the essential abstractions and information required to
understand the domain in the context of the current requirements, and
– aids people in understanding the domain -- its concepts, terminology,
and relationships

15
 An
Finding Concepts

al
ys
is
• List of candidate concepts from Concept Category List:
– physical objects (POST), –containers (Store, Bin),
– specifications (ProductSpecification),
–things in a container (Item),
– places (Store),
–organizations (SalesDepartment),
– transactions (Sale, Payment),
– transaction line items (SalesLineItem), –events (Sale),
– roles of people (Cashier, Customer), –catalogs (ProductCatalog),...

• List of candidate concepts from Noun Identification

– Use cases can be used
– List: Customer, POST, checkout, items, Cashier, item, quantity, item
price, sales transaction, description, price, ...

16
 An
Adding associations

al
ys
is
• Associations:
– relationships between concepts that indicate some meaningful and
interesting connection
– structural relationships between objects of different types.
• Finding associations from common associations list:
– A is a physical (or logical) part of B
– A is physically (or logically) contained in/on B
– A is recorded in B
– A is a description for B
– A is a member of B
– A uses or manages or communicates or is related to B
• Finding concepts is much more important than finding associations
• Focus on
– «need-to-know» associations (knowledge of the relationship needs to
be preserved for some duration)
• Avoid redundant or derivable associations
17
 An
Adding Attributes

al
ys
is
• Attribute: logical data value of an object
• Include those attributes suggested by the use cases.
– for example: Sale needs a date and time attribute
• Attributes should be pure data values (value objects: number, string,
Boolean, date, time)
– otherwise represent as associations
• Relate concepts with an association, not with an attribute!

18
 An
Conceptual model

al
ys
is
Records-sale-of

Described-by

1
0..1 * Contains
Product Catalog 1 Product Specification
Sales LineItem
1..* description
quantity price
1
UPC
Used By
1..*

* 1
Describes
Store
1 *
address Stocks Item
Logs-completed
name
Contained-in 1 * 1
1

Houses
*
1
1..*
Sale POST Records-sales-on
Captured-on
date
time 1
1 1 1

1
Paid-by
1
1 Customer
1
Cashier
Payment Initiated-by
amount

19
 An
System sequence diagrams

al
ys
is
• Define the behaviour of a system as a black box: what the system
does, without explaining how.
• System sequence diagram is a picture that shows the events that
external actors generate, their order and intersystem events (for a
particular scenario of a use case)
• System sequence diagrams are strongly related to use cases

:Cashier :System

enterItem(UPC, quantity)

endSale()

makePayment(amount)

20
 An
System Behaviour - Contracts

al
ys
is
• Contracts are created for each system operation
• Contracts describe the effect of operations upon the system by defining
pre- and postconditions of operations.
• Contracts are declarative in style, emphasising what will happen rather
than how it will be achieved.
• Example:
– Name: enterItem ( upc: number, quantity: integer )
– Responsibilities: Enter sale of an item, add it to the sale, display the
item description and price.
– Pre-conditions: upc is known to the system
– Post-conditions:
• if a new sale, a Sale was created and was associated with the POST
• A SalesLineItem was created and associated with the Sale
• Attribute SalesLineItem.quantity was set to quantity
• The SalesLineItem was associated with a ProductSpecification, based
on UPC match

21
 From Analysis to Design

• Use Cases: What are the domain processes?

• Conceptual Model: What are the concepts, terms?

• System sequence diagrams: What are the system events and

operations?

• Contracts: What do the system operations do?

22
 De
Collaboration Diagrams

si
g n
• Contracts do not show a solution of how software objects are going to
fulfil the post-conditions.
• Interaction diagrams illustrate how objects interact via messages to
fulfils tasks.
• Starting point for the interactions is the fulfilment of the post-
conditions of the operation contracts.
• Use cases may provide additional guidance
• Objects are chosen from the conceptual model.

23
 De
Choosing the Controller Class

si
g n
• The first design decision involves choosing a controller for each system
operation.
• Controller pattern:
– assign the responsibility for handling a system event message to a
class representing one of the following choices:
• the overall system
• the overall business or organisation
• something in the real world that is active (the role of a person)
• an artificial handler of all system events of a use case
• Possible choices for enterItem:
– POST
– Store
1: enterItem(upc, qty)
– Cashier : POST

– BuyItemsHandler

24
 De
Creating a new sale

si
g n
• if a new sale, a Sale was created and was associated with the POST
– Creator Pattern:
• assign the responsibility for creation to a class that aggregates,
contains or records the class to be created
– Candidate: POST
• POST creates Sale, and
• Sale is easily associated to POST since POST keeps a reference to
created Sale
• Sale must create an empty collection to record all the future
SalesLineItem instances that will be added

enterItem(upc, qty) 1: [new sale] create()

: POST : Sale

1.1: create()

: Sales LineItem

25
 De
Creating a new SalesLineItem

si
g n
• A SalesLineItem was created and associated with the Sale
– By Creator:
• Sale creates SalesLineItem
• SalesLineItem is easily associated to Sale (by storing the new instance
in its collection)
• Attribute SalesLineItem.quantity was set to quantity
– POST must pass the quantity along to Sale, which must pass it along as
a parameter in the create message
• The SalesLineItem was associated with a ProductSpecification, based
on UPC match
– Who is responsible for knowing a ProductSpecification based on a UPC
match?
– Expert Pattern:
• assign the responsibility to the object that has the information required
to fulfil it.
– Candidate: ProductCatalog
– POST should ask ProductCatalog for ProductSpecification (Visibility)

26
 De
enterItem Collaboration Diagram

si
g n
by Creator

1: [new sale] create()

enterItem(upc, qty) 3: makeLineItem(spec, qty) 3.1: create(spec, qty)

: POST : Sale

2: spec := specification(upc)
1.1: create()

sl : Sales LineItem
By Expert : Product Catalog
3.2: add(sl)

2.1: spec:= find(upc)

: Product Specification : Sales LineItem

27
 De
Design Class Diagrams

si
g n
• A design class diagram illustrates the specifications for software classes
and interfaces in an application:
– classes, associations and attributes
– methods
– navigability
– dependencies
• The creation of design class diagrams is dependent upon the prior
creation of
– Interaction diagrams : the designer identifies the software classes that
participate in the solution, plus the methods of classes
– Conceptual model: the designer adds details to the class definitions.

28
 De
Design Class Diagram

si
g n
Store
address Uses
name

addSale()

ProductCatalog Product Specification

Looks-in Contains description
specification( ) price
UPC
Houses 1..*

Describes

Sale
*
date
POST time SalesLineItem
Captures Contains
quantity : Integer
endSale( ) becomeComplete( )
enterItem( ) makeLineItem( )
1..*
makePayment() makePayment( )
total( )

Paid-by Payment
Logs-completed
amount : Quantity

29
 Organising and refining the conceptual model
• Organising in Packages:
– used to partition the conceptual model
– organise elements depending on their
• subject area
• type hierarchy
• use cases participation
• strong associations

• Refining associations
– associative types
– aggregation and composition
– association role names

30
 State Diagrams
• Usage: for concepts and use cases enterItem

• Illustrate interesting events and

states of an object, and the enterItem EnteringItems
WaitingForSale
behaviour of an object in reaction
to an event
endSale
• Use case state diagrams
– describe the legal sequence of WaitingForPayment

external system events makePayment

• State diagrams for state-

dependent types off hook[ valid subscriber ] / play dial tone
digit
Idle Active

• Features
– transition actions PlayingDialTone digit
Dialing

– transition guard conditions

– nested states complete

on hook Talking Connecting

connected

31