1. The Object Object Identity Object State Object behaviour OBJECT
Attributes
contained in data
structures
Object State
Procedures which
can operate on the
data structures
Object behaviour
Based on notes from Brian Stone

2. UML and OO Design

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

4. Conventional “Structured Programming” Approach
Data Access
Data
Method
Call
Method

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

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

7. Layered Software Development
System using
PCBs
Applications
PCB using ICs
Models IC
Classes

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

9. OO Methods (Later…) First Generation Second Generation
OMT (Rumbaugh)
Booch (Booch)
Objectory (Jacobson)
Second Generation
Fusion (Coleman)
Syntropy (Cook & Daniels)
Third Generation
Catalysis (Desouza & Wills)

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

11. UML Overview UML Models Views Provided by Models. UML Diagram Notation
Unified Modelling Language

12. UML Models
Nine different Diagram types providing...
Functionality Model
Static Models
Dynamic Models
Provide different (orthogonal and overlapping) views of the system being modelled.

13. UML provides rich set of modelling tools.
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).

14. Unified Modelling Language
UML Diagram Notations
The Diagrams
Use-case Diagram
Class Diagram
Object Diagram
State Diagram
Sequence Diagram
Collaboration Diagram
Activity Diagram
Component Diagram
Deployment Diagram
Unified Modelling Language

15. Use Case Diagram (Mainly used in Analysis)
Take out policy
Sales stats.
Customer
Insurance Salesperson
Customer stats.

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

17. Class Diagram 1..* 1..* 1 1 owns handles Customer Portfolio Trader
0..*
contains
0..*
Instrument
Bond
Stock
Stock
Option

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

19. State Diagram Go up(floor) On first floor Moving up Arrive first floor
arrived
Moving to
first floor
arrived
Moving
down
idle
Go down(floor)
timeout

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

21. Sequence Diagram :Computer :PrintServer :Printer :Queue Print(file)
[printer free]print(file)
[printer busy]store(file)

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

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

24. Domain Analysis
Use Natural Language
Natural
Language
Problem Domain

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

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

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

28. Structured Class Description (cont..)
Public Methods:
Name: Pay_bill
Parameters: amount, date, destination,
account.
Description: Customer may pay bills
through the Bank.

29. Structured Class Description (cont..)
Private Methods:
Name: Transfer
Parameters: amount, from_account,
to_account.
Description: Allow transfers from owned
accounts to any others.

30. Classes and Relationships
Static Modelling
Classes and
Relationships

31. Static Modelling 1 Classes & Objects 2 The Class Diagram
3 Associations
4 Aggregation & Composition
5 Generalisation

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

33. OR The Class Diagram Classname Classname attribute: datatype
operation (args: type): type

34. 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?

35. 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 (#).

36. Only name and type are mandatory.
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.

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

38. 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++; } };

39. Example in C++
class Invoice {
public
Invoice( );
~Invoice( );
double amount;
Date date;
char customer[25];
private
static int number_of _invoices = 0; };

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

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

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

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

44. Associations & Cardinality
Association Name
Class1
Class2
Exactly One
(default)
Class *
Class
Zero or more
0..1
Class
Optional (zero or one)
1.. *
One or more
Class
1..5,8
Numerically specified
Class

45. Cardinality Examples Employee Dept 1..* Name:String Name:Name
Number:EmpNo
Name:Name
0..1
Rent *
Member
Video
Has
Customer
Account
AccNo:Account
Balance: Real

46. Class & Object Representation
0..1 *
Rent
Member
Video
Chocolate: Video
BrianStone: Member
Enemy at the gate: Video

47. Navigable Associations
Used to indicate responsibility, later may be translated into pointer mechanism.
May be bi-directional.
owns
0..*
Person
Car

48. Roles Useful for indicating context of a class. Optional construct.
Part of the association, not the class *
Works for
Company
Person
employer
employee

49. Recursion Self referential construct.
Complex construct, may not be supported by target language.
owner *
User
container
Directory * *
0..1
authorised user
contents *

50. Aggregation & Composition
Special type of association, “consists of”, “contains”, “part of” identify it.
Two types
Shared Aggregation.
Composition Aggregation.
Many notations available.

51. Shared Aggregation One person may be a member of many teams.
Person is part of team, shared by N teams. * *
Person
Team
Members

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

53. Three Composition Notations*
Text *
Listbox
Window *
Button
menu *

54. *
Text *
Listbox
Window *
Button *
menu

55. Window *
Text
Component not bold.
May use syntax
rollname:classname
Multiplicity shown. *
Listbox *
Button *
menu

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

57. Example
General
Car
Specific
Estate
Hatchback
Coupe
Saloon

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

59. Subclass Concretises the Abstract
Vehicle
Drive(){abstract}
Car
Boat
Drive()
Drive()

60. Implementation Issue Vehicle
When person invokes drive( ), method is bound at runtime.
Like Virtual and Pure Virtual function in C++.
drives
Drive(){abstract}
Person
Car
Boat
Drive()
This Drive ( ) is
called
Drive()

61. 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:
UML Toolkit
Hans-Erik Eriksson, Magnus Penker,Wiley, 1997, ISBN:
UML Distilled
Martin Fowler, Kendall Scott Addison-Wesley, 1997, ISBN:
Real-Time UML
Bruce Powel Douglas Addison-Wesley