Object Oriented Design

Report
Week 10.1
OO Design and the
Unified Modelling Language
CA212 OO Design © Brian Stone
2001
1
Introducing the
UML
An Introduction to
OO Design using the
Unified Modelling Language
CA212 OO Design © Brian Stone
2001
2
This part of the Course CA212
• The course is OO based but many features
of structured design also pertain here.
• Course CA214 deals with structured design
and SSADM, much in common…
– Coupling & Cohesion
– Complexity
– Software life-cycle models (Spiral, Waterfall
etc)
CA212 OO Design © Brian Stone
2001
3
To follow next year
• OO Analysis and Design Methods.
• Full life-cycle for OO development
• Only introductory UML notations are
introduced here, along with OO Design
principles.
CA212 OO Design © Brian Stone
2001
4
The Object
OBJECT
Attributes
contained in data
structures
Procedures which
can operate on the
data structures
Object Identity
Object State
Object behaviour
CA212 OO Design © Brian Stone
2001
5
Some Object Oriented
Terminology
• The following characteristics are generally
understood to be included
– Identity: Two Objects with the same attribute values are distinct.
– Classification: Objects with the same attributes and behaviour are
grouped into Classes.
– Polymorphism: The same procedure name may be used by
different Classes to invoke different code.
– Inheritance: Allows a Class to be defined as a sub-type of another
Class.
– Encapsulation: Separates the external interface of an Object from
its internal implementation details.
CA212 OO Design © Brian Stone
2001
6
Conventional “Structured
Programming” Approach
Data
Data Access
Method
Call
Method
CA212 OO Design © Brian Stone
2001
7
Program Modifications
• Modifications to Procedures usually require
modifications to data and vice versa.
• When the application is designed around the
procedural aspects of the users business,
then the structure of the application must
change as the business practice changes.
CA212 OO Design © Brian Stone
2001
8
Benefits of OO Design
• Objects are more stable building blocks for systems
than traditional procedures.
• Objects are extensible.
• Objects are more reusable than procedures alone
because they can be more independent of program
context.
• End users may relate easily to Object concept.
• Object Oriented development reduces project risk by
spreading integration across the project life cycle.
CA212 OO Design © Brian Stone
2001
9
Layered Software Development
System using
PCBs
PCB using ICs
IC
Applications
Models
Classes
CA212 OO Design © Brian Stone
2001
10
OO State Of The Art
• Object Oriented programming languages have matured
over 20 years (Smalltalk, C++, Object-Pascal, Java).
• Development of GUIs like Windows and X have
accelerated interest in Object Oriented techniques.
• Increasing desire for reusability increases interest in OO.
• Object Oriented databases still not widely accepted.
• Analysis and Design methodologies in a constant state of
flux. At present a very big effort is being made to develop
a standardised notation, the UML, under the auspices of
the OMG.
CA212 OO Design © Brian Stone
2001
11
OO Methods (Later…)
• First Generation
– OMT (Rumbaugh)
– Booch (Booch)
– Objectory (Jacobson)
• Second Generation
– Fusion (Coleman)
– Syntropy (Cook & Daniels)
• Third Generation
– Catalysis (Desouza
& Wills)
CA212 OO Design © Brian Stone
2001
12
OO Development Processes
• UML is not a process, it is a set of related
notations.
• Rational promote Objectory as the process
for UML, there are others (three amigos).
• Process is related to environment, it must
also encourage rigour.
CA212 OO Design © Brian Stone
2001
13
UML Overview
Unified
Modelling
Language
• UML Models
• Views Provided by Models.
• UML Diagram Notation
CA212 OO Design © Brian Stone
2001
14
UML Models
• Nine different Diagram types providing...
– Functionality Model
– Static Models
– Dynamic Models
• Provide different (orthogonal and overlapping)
views of the system being modelled.
CA212 OO Design © Brian Stone
2001
15
Views Provided by Models
• UML provides rich set of modelling tools.
• Different views of system supported by models.
• Models provide differing perspectives.
–
–
–
–
–
Use-case view (externally perceived functionality).
Logical view (internal functionality).
Component view (organisational).
Concurrency view (comms. & synch.).
Deployment view (physical architecture).
CA212 OO Design © Brian Stone
2001
16
UML Diagram Notations
• The Diagrams
Unified
Modelling
Language
–
–
–
–
–
–
–
–
–
Use-case Diagram
Class Diagram
Object Diagram
State Diagram
Sequence Diagram
Collaboration Diagram
Activity Diagram
Component Diagram
Deployment Diagram
CA212 OO Design © Brian Stone
2001
17
Use Case Diagram
(Mainly used in Analysis)
Take out policy
Sales stats.
Customer
Insurance Salesperson
Customer stats.
CA212 OO Design © Brian Stone
2001
18
Use-case Notations
• Describe functionality requirements of the
system, i.e. functional spec.
• May be described in plain text.
• May be supported by activity diagrams or
state diagrams.
CA212 OO Design © Brian Stone
2001
19
Class Diagram
1 owns
1..*
1..*
handles
Portfolio
contains
Customer
1
Trader
0..*
0..*
Instrument
Bond
Stock
CA212 OO Design © Brian Stone
2001
Stock
Option
20
Class Diagram Notation
•
•
•
•
Depicts static structure of classes.
Development of Entity-Relationship Diagrams
Classes represent things in the system.
Classes may be related in many ways…
–
–
–
–
Associated
Dependant
Specialised
Packaged
CA212 OO Design © Brian Stone
2001
21
State Diagram
On first
floor
Arrive first floor
Moving to
first floor
Go up(floor)
Go up(floor)
arrived
arrived
Moving
down
timeout
Moving
up
idle
Go down(floor)
CA212 OO Design © Brian Stone
2001
22
State Diagram Notation
• Styled on work of David Harel.
• Used also in OMT, Syntropy and most other
OO methods.
• Each Class may be modelled with a STD, if
important dynamic behaviour is exhibited
by that Class.
CA212 OO Design © Brian Stone
2001
23
Sequence Diagram
:Computer
:PrintServer
:Printer
:Queue
Print(file)
[printer free]print(file)
[printer busy]store(file)
CA212 OO Design © Brian Stone
2001
24
Sequence Diagram Notation
• Developed from ITU standard X.100 State
Transition Diagram (STD) notation.
• Portrays dynamic collaboration between
objects.
• Objects shown in boxes across top.
• Time marches down the page.
CA212 OO Design © Brian Stone
2001
25
Engineering Process for Allocation
of Responsibility
• Process will lay down rules for timing of
allocation of responsibilities to classes.
• May use domain analysis, find classes &
relationships, then allocate from use cases.
• May find classes from use cases.
CA212 OO Design © Brian Stone
2001
26
Domain Analysis
• Use Natural Language
Natural
Language
Problem Domain
CA212 OO Design © Brian Stone
2001
27
Natural Language
• Nouns suggest candidate Classes.
• Not every noun is an Object Class.
– Some are attributes of another Class.
– Some are irrelevant, outside the scope of the
application.
• Verb phrases suggest class associations
– some relationships are irrelevant (caution).
• Proper nouns suggest Objects of a Class type.
Beware of singular nouns.
CA212 OO Design © Brian Stone
2001
28
Class Description
• Develop a Class description, either in
textual prose or some other structured form.
E.G. using a customer in a Bank
– Customer: a holder of one or more accounts in
a Bank. A customer can consist of one or more
persons or companies. A customer can: make
withdrawals; deposit money; transfer money
between their accounts or to another account;
query their accounts.
CA212 OO Design © Brian Stone
2001
29
Structured Class Description
Class Name: Customer
Description: Personal or company details
Superclass: User
Name: Name
Description: Customer’s name
Type: String (max. 12 chars)
Cardinality: 1
Name: Owns
Description: Details of bank accounts
Type: Account
Cardinality: Many CA212 OO Design © Brian Stone
2001
30
Structured Class Description
(cont..)
Public Methods:
Name: Pay_bill
Parameters: amount, date, destination,
account.
Description: Customer may pay bills
through the Bank.
CA212 OO Design © Brian Stone
2001
31
Structured Class Description
(cont..)
Private Methods:
Name: Transfer
Parameters: amount, from_account,
to_account.
Description: Allow transfers from owned
accounts to any others.
CA212 OO Design © Brian Stone
2001
32
Static Modelling
Classes and
Relationships
CA212 OO Design © Brian Stone
2001
33
Static Modelling
•
•
•
•
•
1
2
3
4
5
Classes & Objects
The Class Diagram
Associations
Aggregation & Composition
Generalisation
CA212 OO Design © Brian Stone
2001
34
Classes and Objects
• Classes, Objects and their relationships are
the primary modelling elements in the OO
paradigm.
• A class is to a type as an object is to an
instance.
• Classification has been around for a long
time, we apply it now to programs.
CA212 OO Design © Brian Stone
2001
35
The Class Diagram
Classname
Classname
OR
attribute: datatype
operation (args: type): type
CA212 OO Design © Brian Stone
2001
36
Finding Classes
•
•
•
•
•
Use domain analysis as before.
Derive them from the use cases (descriptions).
Look for data which must be stored or analysed.
Are there external systems?
Are there any devices under the control of the
system?
• Are there any organisational parts?
CA212 OO Design © Brian Stone
2001
37
Attributes
• Describe the state and characteristics of the
object.
• Must be typed, primitives like integer, real,
Boolean, point, area, enumeration, these are
primitives. May be language specific.
• Visibility may be public (+), private (-) or
protected (#).
CA212 OO Design © Brian Stone
2001
38
• Class variables have scope across every instance
of class, change one changes all (C++ static).
• Property strings may be used to define allowable
properties of an attribute. Used for enumeration
types.
• Syntax
– visibility name : type-expression = initial-value
{property-string}
• Only name and type are mandatory.
CA212 OO Design © Brian Stone
2001
39
Example UML Class
Name, bold
Public, typed
Invoice
+ amount :Real
+ date : Date = Current_date
+ customer : String
+ specification : String
- administrator: String = “Unspecified”
- number_of_invoices: Integer
+ status: Status = unpaid {paid, unpaid}
CA212 OO Design © Brian Stone
2001
Default value
Private, typed,
default value
Class variable
Property
40
Example in Java
public class Invoice
{
public double amount;
public Date date = new Date();
public String customer;
static private int number_of _invoices = 0;
//constructor
public Invoice()
{
number_of_invoices++;
}
};
CA212 OO Design © Brian Stone
2001
41
Example in C++
class Invoice
{
public
Invoice( );
~Invoice( );
double amount;
Date date;
char customer[25];
private
static int number_of _invoices = 0;
};
CA212 OO Design © Brian Stone
2001
42
Operations
• Operations manipulate attributes and
perform other tasks.
• Scope is the Class.
• Operation signature is composed of name,
parameters and return type.
– name(parameter-list) return-type-expression
• Scope and visibility rules apply.
CA212 OO Design © Brian Stone
2001
43
Syntactic Constructs
• Formal syntax is as follows
– visibility name(parameter-list) return-typeexpression {property-string}
• parameter-list specified as …
– name: type-expression=default-value
• All operations must have unique signature.
• Default values on parameters are Ok.
CA212 OO Design © Brian Stone
2001
44
On the Class Diagram
Figure
Signatures ?
Class scope ?
Defaults ?
- size: Size
- pos: Position
+ figureCounter: Integer
+ draw( )
+ resize(percentX: Integer=25, percentY=30)
+ returnPosition( ): Position
+ incrementCounter( ): Integer
MyFigure.resize(10,10)
MyFigure.resize(27)
MyFigure.resize()
percentX=10, percentY=10
percentX=27, percentY=30
percentX=25, percentY=30
CA212 OO Design © Brian Stone
2001
45
Associations
• Associations model Class relationships.
• Associations should be named where appropriate.
Usual to use verbs from the problem domain.
• Roles played by classes may also be named.
• Associations have a cardinality.
• Rules from programming about sensible names
apply.
CA212 OO Design © Brian Stone
2001
46
Associations & Cardinality
Class1
Association Name
Class2
Class
Exactly One
(default)
*
Zero or more
Optional (zero or one)
One or more
Numerically specified
Class
0..1
Class
1.. *
Class
1..5,8
CA212 OO Design © Brian Stone
2001
Class
47
Cardinality Examples
Employee
Dept
1..*
Name:String
Number:EmpNo
Member
Customer
Name:Name
0..1
Rent
*
Video
Has
Account
AccNo:Account
Balance: Real
CA212 OO Design © Brian Stone
2001
48
Class & Object Representation
Member
0..1
*
Rent
Video
Chocolate: Video
BrianStone: Member
Enemy at the gate: Video
CA212 OO Design © Brian Stone
2001
49
Navigable Associations
• Used to indicate responsibility, later may be
translated into pointer mechanism.
• May be bi-directional.
owns
Person
0..*
CA212 OO Design © Brian Stone
2001
Car
50
Roles
• Useful for indicating context of a class.
• Optional construct.
• Part of the association, not the class
Works for
Company
employer
*
Person
employee
CA212 OO Design © Brian Stone
2001
51
Recursion
• Self referential construct.
• Complex construct, may not be supported
by target language.
User
*
owner
*
authorised user
*
container
0..1
Directory
contents
CA212 OO Design © Brian Stone
2001
*
52
Aggregation & Composition
• Special type of association, “consists of”,
“contains”, “part of” identify it.
• Two types
– Shared Aggregation.
– Composition Aggregation.
• Many notations available.
CA212 OO Design © Brian Stone
2001
53
Shared Aggregation
• One person may be a member of many teams.
• Person is part of team, shared by N teams.
*
*
Person
Team
Members
CA212 OO Design © Brian Stone
2001
54
Composition Aggregation
• More restrictive. Strong ownership here.
• Rules
– Parts live inside whole, parts die with whole,
like automatic variables.
– Multiplicity on whole side must be “0..1”, on
part side may be anything.
• Composition aggregation forms a tree of
parts, shared forms a network of parts.
CA212 OO Design © Brian Stone
2001
55
Three Composition Notations
*
Text
*
Listbox
Window
*
*
CA212 OO Design © Brian Stone
2001
Button
menu
56
*
*
Text
Listbox
Window
*
*
CA212 OO Design © Brian Stone
2001
Button
menu
57
Window
Text
*
*
Listbox
Button
*
• Component not bold.
• May use syntax
– rollname:classname
• Multiplicity shown.
menu *
CA212 OO Design © Brian Stone
2001
58
Generalisation
• Generalisation and Inheritance allow
sharing of similarities among Classes while
also preserving differences.
• Inheritance refers to mechanism of sharing
attributes & operations between subclasses
and their superclass.
• Default values of attributes & methods for
operations may be overridden in subclass.
CA212 OO Design © Brian Stone
2001
59
Example
General
Car
Specific
Estate
Saloon
Hatchback
CA212 OO Design © Brian Stone
2001
Coupe
60
Normal Generalization
• Subclasses inherit from Superclasses.
• Scope rules apply, public, private and
protected are available (+, -, #).
• Abstract classes have no Objects.
• Car class is a good abstract class, denoted
with {abstract} tag under name in top
compartment. Abstract operations are
tagged also.
CA212 OO Design © Brian Stone
2001
61
Subclass Concretises the Abstract
Vehicle
Drive(){abstract}
Car
Drive()
Boat
Drive()
CA212 OO Design © Brian Stone
2001
62
Implementation Issue
Vehicle
Drive(){abstract}
drives
Person
Car
Drive()
Boat
Drive()
• When person
invokes drive( ),
method is bound at
runtime.
• Like Virtual and
Pure Virtual function
in C++.
This Drive ( ) is
called
CA212 OO Design © Brian Stone
2001
63
Books & References
• Using UML: software engineering with objects and components. [main
text]
– Stevens & Pooley, Addison Wesley, ISBN: 0-201-64860-1
– http://www.dcs.ed.ac.uk/home/pxs/Book/
• UML Toolkit
– Hans-Erik Eriksson, Magnus Penker,Wiley, 1997, ISBN: 0-471-19161-2
• UML Distilled
– Martin Fowler, Kendall Scott Addison-Wesley, 1997, ISBN: 0-201-32563-2
• Visual Modelling with Rational Rose and UML
– Terry Quatrani Addison-Wesley
• Real-Time UML
– Bruce Powel Douglas Addison-Wesley
CA212 OO Design © Brian Stone
2001
64

similar documents