Unified Modelling Language OOA/OOD a summary of the book: Applying UML and Patterns, Craig Larman

1
Unified Modelling LanguageOOA/OODa summary of
the bookApplying UML and Patterns, Craig Larman

• D. Dranidis
• October 2000
• CITY College

2
Introduction

• Owing a hammer doesnt 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 Events

• Actor 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 courses Line 2 Invalid item
identifier entered. Indicate error. Line 7
Customer could not pay. Cancel sales transaction.
13
Use Case Diagram

• Partial use case diagram

POST
Log In
Cashier
Customer
Buy Items
Pay By Credit
Pay By Cash
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

Development Cycle 1
Development Cycle 2
Development Cycle 3
Buy Items version 1
Buy Items version 2
Refund
Log In
15
Building a Conceptual Model
Analysis

• 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

16
Finding Concepts
Analysis

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

• containers (Store, Bin),
• things in a container (Item),
• organizations (SalesDepartment),
• events (Sale),
• catalogs (ProductCatalog),...

17
Adding associations
Analysis

• 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

18
Adding Attributes
Analysis

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

19
Conceptual model
Analysis
Records-sale-of
Described-by
1
1


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


Describes
Store


1
Stocks
address
Item
Logs-completed
name
Contained-in
1


1
1
1
1
1
Houses

1
1..
1..
Sale
Records-sales-on
POST
Captured-on
date
time
1
1
1
1
1
1
1
1
1
Paid-by
1
1
1
1
Customer
1
1
Cashier
Payment
Initiated-by
amount
20
System sequence diagrams
Analysis

• 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

21
System Behaviour - Contracts
Analysis

• 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

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
Design

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

24
Choosing the Controller Class
Design

• 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

25
Creating a new sale
Design

• 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

1 new sale create()
enterItem(upc, qty)
POST
Sale
1.1 create()
Sales LineItem
26
Creating a new SalesLineItem
Design

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

27
enterItem Collaboration Diagram
Design
by Creator
1 new sale create()
3 makeLineItem(spec, qty)
enterItem(upc, qty)
3.1 create(spec, qty)
POST
Sale
2 spec specification(upc)
1.1 create()
sl Sales LineItem
Product Catalog
By Expert
3.2 add(sl)
2.1 spec find(upc)
Product Specification
Sales LineItem
28
Design Class Diagrams
Design

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

29
Design Class Diagram
Design
Store
address
Uses
name
addSale()
ProductCatalog
Product Specification
Looks-in
description
Contains
specification( )
price
UPC
1..
1..
Houses
Describes
Sale


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


Paid-by
Payment
Logs-completed
amount Quantity
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