Transcript Object Oriented Design
Week 10.1
OO Design and the U nified M odelling L anguage
CA212 OO Design © Brian Stone 2001 1
Introducing the
U M L An Introduction to OO Design using the U nified M odelling L anguage
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
OBJECT Attributes contained in data structures Procedures which can operate on the data structures
The Object
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 Applications PCB using ICs Models IC 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
• UML Models • Views Provided by Models.
• UML Diagram Notation
U
nified
M
odelling
L
anguage
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
U M L
UML Diagram Notations
nified odelling anguage
• The Diagrams – – – –
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
Customer
Use Case Diagram (Mainly used in Analysis)
Take out policy Sales stats.
Customer stats.
CA212 OO Design © Brian Stone 2001 Insurance Salesperson 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
Customer
Class Diagram
1 owns 1..*
Portfolio
1..* handles 0..* 1
Trader
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 Moving down Go up(floor) arrived arrived Go down(floor) timeout Moving up idle Go up(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 Print(file) [printer free]print(file) :Printer :Queue [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 Classes & Objects • 2 The Class Diagram • 3 Associations • 4 Aggregation & Composition • 5 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 OR Classname
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} Default value Private, typed, default value Class variable Property CA212 OO Design © Brian Stone 2001 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-type expression {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
- size: Size - pos: Position + figureCounter: Integer + draw( ) + resize(percentX: Integer=25, percentY=30) + returnPosition( ): Position + incrementCounter( ): Integer Signatures ?
Class scope ?
Defaults ?
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 45 2001
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
Association Name
Class1 Class2
Exactly One (default) Zero or more * Optional (zero or one) One or more Numerically specified 1..5,8 CA212 OO Design © Brian Stone 2001 0..1
1.. *
Class Class Class Class Class
47
Cardinality Examples
Employee
Name:String Number:EmpNo
Member
1..* 0..1
Rent
Dept
Name:Name *
Video Customer
Has CA212 OO Design © Brian Stone 2001
Account
AccNo:Account Balance: Real 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..*
Car
CA212 OO Design © Brian Stone 2001 50
Roles
• Useful for indicating context of a class.
• Optional construct.
• Part of the association, not the class
Company
employer
Works for
*
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 *
Directory
container 0..1
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.
Team
* * Members CA212 OO Design © Brian Stone 2001
Person
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
Window
*
Text
*
Listbox
*
Button
CA212 OO Design © Brian Stone 2001 *
menu
56
Window
*
Text
*
Listbox
*
Button
CA212 OO Design © Brian Stone 2001 *
menu
57
Window
Text * Listbox * Button * menu * • Component not bold.
• May use syntax – rollname:classname • Multiplicity shown.
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
General
Example
Car Specific Estate Saloon Hatchback Coupe
CA212 OO Design © Brian Stone 2001 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