Transcript eXtreme Programming

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 objectoriented 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:
Actors:
Type:
Description:
Buy Items
Customer, Cashier
primary
– 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:
Actors:
Purpose:
Type:
Overview:
Buy Items
Customer (initiator), Cashier
Capture a sale and its payment
primary
– 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
1.
2.
Actor Action
This use case begins when a Customer
arrives at the POST checkout with items
to purchase.
The cashier records each item.
System Response
3.
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.
5.
Determines the item price and adds the
item information to the running sales
transaction.
The description and price of the current
item are presented.
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.
12
Use Case Diagram
•
Partial use case diagram
POST
Log In
Customer
Buy Items
Pay By Credit
Cashier
Pay By Cash
13
Allocation of use cases to development cycles
•
Buy Items version 1 is a simplified version of the original use case.
Development
Cycle 1
Development
Cycle 2
Buy Items
version 1
Buy Items
version 2
Development
Cycle 3
Refund
Log In
•
Each development cycle consists of
– Planning, Analysis, Design, Construction, Testing
14
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
15
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),
–containers (Store, Bin),
–things in a container (Item),
–organizations (SalesDepartment),
–events (Sale),
–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
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
A
A
A
A
A
is a physical (or logical) part of B
is physically (or logically) contained in/on B
is recorded in B
is a description for B
is a member of B
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
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!
18
Conceptual model
Records-sale-of
Described-by
1
*
0..1
Contains
Product Catalog
Sales LineItem
Product Specification
1
1
description
price
UPC
*
Describes
1..*
quantity
Used By
1..*
Store
Logs-completed
1 address
name
*
Stocks
Contained-in
1
1
Item
*
1
1
Houses
*
1
1..*
POST
Sale
Captured-on
date
time
1
1
1
Paid-by
1
Payment
Records-sales-on
1
1
1
Initiated-by
Customer
1
Cashier
amount
19
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)
20
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
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
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.
23
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
1: enterItem(upc, qty)
: POST
24
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
enterItem(upc, qty)
1: [new sale] create()
: POST
: Sale
1.1: create()
: Sales LineItem
25
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)
26
enterItem Collaboration Diagram
by Creator
1: [new sale] create()
enterItem(upc, qty)
3: makeLineItem(spec, qty)
: POST
2: spec := specification(upc)
By Expert
3.1: create(spec, qty)
: Sale
1.1: create()
sl : Sales LineItem
: Product Catalog
3.2: add(sl)
2.1: spec:= find(upc)
: Product Specification
: Sales LineItem
27
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.
28
Design Class Diagram
Store
address
name
Uses
addSale()
ProductCatalog
Looks-in
specification( )
Product Specification
Contains
1..*
Houses
description
price
UPC
Describes
Sale
POST
endSale( )
enterItem( )
makePayment()
Captures
*
date
time
SalesLineItem
Contains
becomeComplete( )
makeLineItem( )
makePayment( )
total( )
quantity : Integer
1..*
*
Paid-by
Logs-completed
Payment
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
Illustrate interesting events and
states of an object, and the
behaviour of an object in reaction
to an event
Use case state diagrams
enterItem
WaitingForSale
State diagrams for statedependent types
WaitingForPayment
makePayment
off hook[ valid subscriber ] / play dial tone
Idle
•
EnteringItems
endSale
– describe the legal sequence of
external system events
•
enterItem
Active
digit
Features
– transition actions
– transition guard conditions
– nested states
PlayingDialTone
digit
Dialing
complete
on hook
Talking
Connecting
connected
31