The Object
OBJECT
Attributes
contained in data
structures
Procedures which
can operate on the
data structures
Object Identity
Object State
Object behaviour
1
UML and OO Design
2
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.
3
Conventional “Structured
Programming” Approach
Data
Data Access
Method
Call
Method
4
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.
5
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.
6
Layered Software Development
System using
PCBs
PCB using ICs
IC
Applications
Models
Classes
7
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.
8
OO Methods (Later…)
First Generation
OMT (Rumbaugh)
Booch (Booch)
Objectory (Jacobson)
 Second Generation
– Fusion (Coleman)
– Syntropy (Cook & Daniels)
 Third Generation
– Catalysis (Desouza
& Wills)
9
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.
10
UML Overview
Unified
Modelling
Language
 UML Models
 Views Provided by Models.
 UML Diagram Notation
11
UML Models
Nine different Diagram types providing...
Functionality Model
Static Models
Dynamic Models
Provide different (orthogonal and overlapping) views of the
system being modelled.
12
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).
13
UML Diagram Notations
Unified
Modelling
Language
The Diagrams
Use-case Diagram
Class Diagram
Object Diagram
State Diagram
Sequence Diagram
Collaboration Diagram
Activity Diagram
Component Diagram
Deployment Diagram
14
Use Case Diagram
(Mainly used in Analysis)
Take out policy
Sales stats.
Customer
Insurance Salesperson
Customer stats.
15
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.
16
Class Diagram
1 owns
1..*
1..*
handles
Portfolio
contains
Customer
1
Trader
0..*
0..*
Instrument
Bond
Stock
Stock
Option
17
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
18
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)
19
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.
20
Sequence Diagram
:Computer
:PrintServer
:Printer
:Queue
Print(file)
[printer free]print(file)
[printer busy]store(file)
21
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.
22
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.
23
Domain Analysis
 Use Natural Language
Natural
Language
Problem Domain
24
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.
25
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.
26
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
27
Structured Class Description
(cont..)
Public Methods:
Name: Pay_bill
Parameters: amount, date, destination,
account.
Description: Customer may pay bills
through the Bank.
28
Structured Class Description
(cont..)
Private Methods:
Name: Transfer
Parameters: amount, from_account,
to_account.
Description: Allow transfers from owned
accounts to any others.
29
Static Modelling
Classes and
Relationships
30
Static Modelling





1
2
3
4
5
Classes & Objects
The Class Diagram
Associations
Aggregation & Composition
Generalisation
31
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.
32
The Class Diagram
Classname
Classname
OR
attribute: datatype
operation (args: type): type
33
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?
34
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 (#).
35
 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.
36
Example UML Class
Name, bold
Invoice
+ amount :Real
+ date : Date = Current_date
+ customer : String
+ specification : String
- administrator: String = “Unspecified”
- number_of_invoices: Integer
+ status: Status = unpaid {paid, unpaid}
Public, typed
Default value
Private, typed,
default value
Class variable
Property
37
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++;
}
};
38
Example in C++
class Invoice
{
public
Invoice( );
~Invoice( );
double amount;
Date date;
char customer[25];
private
static int number_of _invoices = 0;
};
39
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.
40
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.
41
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
42
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.
43
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
Class
44
Cardinality Examples
Employee
Dept
1..*
Name:String
Number:EmpNo
Member
Customer
Name:Name
0..1
Rent
Has
*
Video
Account
AccNo:Account
Balance: Real
45
Class & Object Representation
Member
0..1
BrianStone: Member
Rent
*
Video
Chocolate: Video
Enemy at the gate: Video
46
Navigable Associations
 Used to indicate responsibility, later may be
translated into pointer mechanism.
 May be bi-directional.
owns
Person
0..*
Car
47
Roles
 Useful for indicating context of a class.
 Optional construct.
 Part of the association, not the class
Company
employer
Works for
*
Person
employee
48
Recursion
 Self referential construct.
 Complex construct, may not be supported by
target language.
User
owner
*
authorised user
*
*
container
0..1
Directory
contents
*
49
Aggregation & Composition
 Special type of association, “consists of”,
“contains”, “part of” identify it.
 Two types
– Shared Aggregation.
– Composition Aggregation.
 Many notations available.
50
Shared Aggregation
One person may be a member of many teams.
Person is part of team, shared by N teams.
*
*
Person
Team
Members
51
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.
52
Three Composition Notations
*
Text
*
Listbox
Window
*
*
Button
menu
53
*
*
Text
Listbox
Window
*
*
Button
menu
54
Window
Text
*
*
Listbox
Button
Component not bold.
May use syntax
rollname:classname
Multiplicity shown.
*
menu *
55
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.
56
Example
General
Car
Specific
Estate
Saloon
Hatchback
Coupe
57
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.
58
Subclass Concretises the
Abstract
Vehicle
Drive(){abstract}
Car
Drive()
Boat
Drive()
59
Implementation Issue
Vehicle
Drive(){abstract}
drives
Person
Car
Drive()
When person invokes
drive( ), method is bound
at runtime.
Like Virtual and Pure
Virtual function in C++.
Boat
Drive()
This Drive ( ) is
called
60
Books & References
 Visual Modelling with Rational Rose and UML
– Terry Quatrani Addison-Wesley
 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
 Real-Time UML
– Bruce Powel Douglas Addison-Wesley
61
Descargar

Object Oriented Design