1

Unified Modelling LanguageOOA/OOD

a summary of the book:Applying UML and Patterns, Craig Larman

D. DranidisOctober 2000CITY College

2

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

3

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

4

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

5

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).

6

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

7

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

8

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

9

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

10

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.

11

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...

12

Typical Course of EventsActor Action

1. This use case begins when a Customer arrives at the POST checkout with items to purchase.

2. The cashier records each item.

If there is more than one of an item, the Cashier can enter the quantity as well.

4. On completion of item entry, the Cashier 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.b. if credit payment initiate Pay by Credit.

11. The Cashier gives the receipt to the Customer.

12. The Customer leaves with the items purchased.

System Response

3. Determines the item price and adds the item information to the running sales transaction.The description and price of the current item are presented.

5. Calculates and presents the sale total.

8. Logs the completed sale.9. Updates inventory levels.10. Generates a receipt.

Alternative coursesLine 2: Invalid item identifier entered. Indicate error.Line 7: Customer could not pay. Cancel sales transaction.

13

Use Case Diagram

• Partial use case diagram

Buy Items

Log In

Cashier

Pay By Cash

Customer

Pay By Credit

POST

14

Allocation of use cases to development cycles

• Buy Items version 1 is a simplified version of the original use case.

• Each development cycle consists of– Planning, Analysis, Design, Construction, Testing

DevelopmentCycle 1

Buy Itemsversion 1

DevelopmentCycle 2

Buy Itemsversion 2

DevelopmentCycle 3

Log In

Refund

15

Building a Conceptual Model

• 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

Analysis

16

Finding Concepts

• List of candidate concepts from Concept Category List:– physical objects (POST), – specifications (ProductSpecification), – places (Store), – transactions (Sale, Payment), – transaction line items (SalesLineItem), – roles of people (Cashier, Customer),

• 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, ...

Analysis

–containers (Store, Bin),

–things in a container (Item),

–organizations (SalesDepartment),

–events (Sale),

–catalogs (ProductCatalog),...

17

Adding associations

• 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

Analysis

18

Adding Attributes

• 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!

Analysis

19

Conceptual model

1..*

*

1 *

Product Catalog

1

*

1

1..*

Store

addressname

1

*

Used By

1 1

Product Specification

descriptionpriceUPC

1..*

1Contains*

1

Payment

amount

Sale

datetime

1

1

Initiated-by

1

1

Paid-by

1

1

POST

1

1..*

Houses

1

Captured-on

1

1

Records-sales-on

1

1

1

1

Sales LineItem

quantity

1

1..*

Contained-in

1*

Described-by

Item

1

*

Describes

*1

Stocks

1

0..1

Records-sale-of

1

0..1

Analysis

Logs-completed1

*

CashierCustomer

20

System sequence diagrams

• 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)

Analysis

21

System Behaviour - Contracts

• 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

Analysis

22

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?

23

Collaboration Diagrams

• 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.

Design

24

Choosing the Controller Class

• 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– Cashier– BuyItemsHandler

: POST

1: enterItem(upc, qty)

Design

25

Creating a new sale

• 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

: POST : Sale

: Sales LineItem

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

1.1: create()

Design

26

Creating a new SalesLineItem• 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)

Design

27

enterItem Collaboration Diagram

: POST : Sale

: Sales LineItem

: Product Catalog

: Product Specification

sl : Sales LineItem

1: [new sale] create()

3: makeLineItem(spec, qty)

2: spec := specification(upc)

enterItem(upc, qty)

1.1: create()

3.2: add(sl)

3.1: create(spec, qty)

2.1: spec:= find(upc)

by Creator

By Expert

Design

28

Design Class Diagrams

• 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.

Design

29

Design Class Diagram

Payment

amount : Quantity

POST

endSale( )enterItem( )makePayment()

ProductCatalog

specification( )Looks-in

Store

addressname

addSale()

Uses

Houses

Sale

datetime

becomeComplete( )makeLineItem( )makePayment( )total( )

Captures

Paid-by

*

Logs-completed

SalesLineItem

quantity : Integer

1..*

Contains

Product Specification

descriptionpriceUPC

1..*

Contains

*

Describes

1..*

*

*

1..*

Design

30

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

31

State Diagrams• Usage: for concepts and use

cases• Illustrate interesting events

and states of an object, and the behaviour of an object in reaction to an event

• Use case state diagrams– describe the legal sequence

of external system events

• State diagrams for state-dependent types

• Features– transition actions– transition guard conditions– nested states

WaitingForSale EnteringItemsenterItem

WaitingForPayment

enterItem

endSale

makePayment

Idle Active

PlayingDialTone

Talking

Dialing

Connecting

PlayingDialTone

Talking

Dialing

Connecting

digit

digit

complete

connected

off hook[ valid subscriber ] / play dial tone

on hook