1. Object-Oriented Analysis & Design
Dr. M.E. Fayad, Professor
Computer Engineering Department – RM#
College of Engineering
San José State University
One Washington Square
San José, CA
URL:
Fall 2002
SJSU -- CmpE

2. Type-Oriented Paradigm
Lesson 6:
Type-Oriented Paradigm
(TOP) 2
Fall 2002
SJSU --- CmpE M.E. Fayad

3. 3 Lesson Objectives (1) Overview of Previous Lecture
Be able to use the type-oriented paradigm to define objects, classes, behaviors, and achieve good object-oriented software engineering objectives
Understand how types define interfaces
Learn about type specification and how to specify behavior
Understand how classes implement types 3
Fall 2002
SJSU --- CmpE M.E. Fayad

4. 4 Lesson Objectives (2) Understand types and classes in C++
Understand subtypes
Understand the differences between hierarchies and inheritance
Learn the maintenance, modifications, and enhancements of software systems in TOP
Understand the goals and qualities of TOP
Explore the differences of terminology for types and classes 4
Fall 2002
SJSU --- CmpE M.E. Fayad

5. Type-Oriented Paradigm
You aren’t
my type. 5
Fall 2002
SJSU --- CmpE M.E. Fayad

6. Type-Oriented Paradigm: An Outline
Types Define Interfaces
Type Specification
Classes Implement Types
Types and Classes in C++
Subtypes
Hierarchies and Inheritance
Maintenance, Modifications, and Enhancements
Goals and Qualities
Observations and Conclusions 6
Fall 2002
SJSU --- CmpE M.E. Fayad

7. Type-Oriented Paradigm
Types Define Interfaces
Topics
A Type Names An Interface
Elements of An Interface
The Interface Includes Behavior
Interfaces With and Without Behavior 7
Fall 2002
SJSU --- CmpE M.E. Fayad

8. A Type Names an Interface
Complete set of services/requests
Says nothing about the implementation
Message send, sender, receiver, length
Stack push, pop, top, length
Integer +, -, /, *, **
ReadAbleFile open, close, read, seek, length
WriteAbleFile open, close, write, seek, length
ReadWriteFile open, close, read, write, seek, length 8
Fall 2002
SJSU --- CmpE M.E. Fayad

9. Elements of an Interface
A type names an interface.
An interface is a collection of operation/requests/services
ReadWriteFile: open, close, read, write, seek, length
An operation has a signature
void open(String name, Mode mode)
A signature consists of a Name and Parameter Types
Name - open
Parameter Types - String, Mode 9
Fall 2002
SJSU --- CmpE M.E. Fayad

10. More about Elements of an Interface
The Interface includes Behavior
Behavior defines what an operation does; behavior defines the semantics of an operation
The Elements of Behavior
Intended purpose of the operation name and the parameter names
Requirements placed on the client of the interface
What the object promises to do when it is requested to perform the operation
What the object does in exceptional circumstances or when an error occurs 10
Fall 2002
SJSU --- CmpE M.E. Fayad

11. Elements of Behavior: Examples
The purpose of operation “draw” defined as part of the interface for Type Person is to remove a bucket full of water from a well
Type ReadAbleFile requires the object to be in the state “open” before the operation “read” can be requested
Type ReadAbleFile promises that the object will read “numBytes” bytes and store them in “buffer”
Type ReadAbleFile promises to throw an exception “ReadError” If the operation “read” is requested and the object is not in the “open” state 11
Fall 2002
SJSU --- CmpE M.E. Fayad

12. Interfaces Without Behavior
Without well-defined behaviors, the following interfaces would be identical:
Stack
void push(int i);
int pop();
Car 12
Fall 2002
SJSU --- CmpE M.E. Fayad

13. Interfaces With Behavior
With well-defined behaviors, the following interfaces would be distinct:
Stack
void push(int i); //put ‘ i ‘ on the Stack
int pop(); //remove and return the top value on the Stack
Car
void push(int i); //push Car at ‘ i ‘ feet per minute
int pop(); //pop the Car’s tire; return # of OK tires 13
Fall 2002
SJSU --- CmpE M.E. Fayad

14. A Type Names an Interface
A type is a name used to denote a particular interface
An object is of Type “ReadAbleFile” if it supports all the operations defined by the interface “ReadAbleFile”
An object may have more than one type
One portion of an object’s interface may be defined by one type and other portions may be defined by other types
Two objects with the same type need only have portions of their interfaces in common 14
Client Code uses the Type Interface
Fall 2002
SJSU --- CmpE M.E. Fayad

15. Type-Oriented Paradigm
Type Specification 15
Fall 2002
SJSU --- CmpE M.E. Fayad

16. 16 Specifying Behavior The Goal is Accurate Communication. Type Name
Type “MessageRequest”
Type Invariant
properties shared by all objects of this type
For each Operation
void send(Address destination);
//Purpose:
//Parameters:
//Requirements:
//Promises:
//Return Values:
//Exceptions:
//Intentional Vagueness
Some Useful Special Symbols
INITIAL, FINAL, RESULT,
#<Operation Name>
IF, THEN, ELSE, WHEN, ....
The Goal is Accurate
Communication. 16
Fall 2002
SJSU --- CmpE M.E. Fayad

17. Type-Oriented Paradigm
Classes Implement Types
Topics
A Class Implements a Type.
The Class Must Correctly Implement the Type.
Substitutability: Require No More and Promise No Less.
One Class Can Be Substituted for Another
A Type Can Have Multiple Classes
Clients Program to the Interface 17
Fall 2002
SJSU --- CmpE M.E. Fayad

18. A Class Implements A Type
A class defines:
1. Data layout 2. Data structures
3. Source code 4. Auxiliary methods
5. Algorithms
Types and Classes
Type Class
Integer int, +, -, *, /, ....
Stack Stack implementation using Array
Container Linked List with Index 18
In this context, a “class” means “the encapsulated implementation of a type. (in particular, a “class” is not being used to mean “C++ class”)
Fall 2002
SJSU --- CmpE M.E. Fayad

19. The Class Must Correctly Implement the Type.
Assume “sample” is a method associated with a suitable class
Correct
int sample()
//Promise: Returns an even integer between 0 and 100 {
return 8; }
Incorrect
// with uniform distribution across this range 19
Fall 2002
SJSU --- CmpE M.E. Fayad

20. 20 Substitutability* Promise no less! Require no more!
*This is known as “controvariance.
Fall 2002
SJSU --- CmpE M.E. Fayad

21. Require No More! (1)
Class cannot impose requirements on the client code beyond those defined by the Type.
Type ReadAbleFile requires that the file be in the “open” state before the operation “read” can be performed.
Class must check for and respond in the way defined by the Type when requirements are not satisfied by the client code.
Type ReadAbleFile requires that the file be in the “open” state before the operation “read” can be performed and promises to throw an “IllegalRead” exception if the file is not “open”. 21
Fall 2002
SJSU --- CmpE M.E. Fayad

22. Require No More! (2)
Class can do whatever it wants when the specification is vague.
Type ReadAbleFile requires that the file be in the “open” state before the operation “read” can be performed (“Intentional Vagueness”).
Class ReadAbleFile can do anything it wants when the file is not “open” and the operation “read” is requested (read the file, throw an exception, print an error message, close the file, truncate the file, ....)
In this case, “Intentional Vagueness” informs the client of a requirement but gives the implementer flexibility in how to handle the situation. 22
Fall 2002
SJSU --- CmpE M.E. Fayad

23. Promise No Less!
Class must fully perform the operation as defined by the type if the client code satisfies the requirements.
Correct
int sample()
//Promise: Returns an even integer between 0 and 100. {
return 8; }
Incorrect
return 5; 23
Fall 2002
SJSU --- CmpE M.E. Fayad

24. One Class Can Be Substituted for Another.
Type Stack
Implemented by Class StackLL
Replace Class StackLL with Class StackAR
Type Message
Implemented by Class MessageAppleTalk
Replace Class MessageAppleTalk with Class MessageUDP
Both classes must implement the same interface
Client code unaffected by substitution 24
Fall 2002
SJSU --- CmpE M.E. Fayad

25. A Type Can Have Multiple Classes
Type Stack
Class StackLL implements a Stack.
Class StackAR implements a Stack.
Type Message
Class MessageAppleTalk implements a Message.
Class MessageUDP implements a Message
Both classes must implement the same interface
Client code unaffected by substitution 25
Fall 2002
SJSU --- CmpE M.E. Fayad

26. Clients Program to the Interface.
The interface defines well-specified behavior.
The interface (i.e., type) should be more stable than the implementation since it is based on the problem domain.
When clients program to the interface:
1. Able to modify classes
2. Able to substitute classes
3. Able to change class hierarchy
Aside If your interfaces are not stable, then you probably don’t have good abstractions or they are too closely tied to the implementation. 26
Fall 2002
SJSU --- CmpE M.E. Fayad

27. Programming to the Implementation Considered Harmful
Today
int sample()
//Promise: Returns an even integer between 0 and 100. {
return 8; }
Client Code
void clientCode()
int a[10];
cout << a[sample()];
return 88; 27
Fall 2002
SJSU --- CmpE M.E. Fayad

28. Programming to the Implementation Considered Harmful
Developer’s modification is substitutable (complies with specification)
Clients are at fault because they relied on the implementation instead of the interface.
Aside Developers would be at fault if they failed to specify the interface. 28
Fall 2002
SJSU --- CmpE M.E. Fayad

29. Class Implement Types: Summary
Types Encapsulate the Design
Classes Encapsulate the Implementation 29
Fall 2002
SJSU --- CmpE M.E. Fayad

30. Type-Oriented Paradigm
Types & Classes in C++
Topics
Two Concepts, One Language Facility
Guidelines 30
Fall 2002
SJSU --- CmpE M.E. Fayad

31. Two Concepts & One Language Facility
C++ classes are used for defining types and classes
//Type Stack
class Stack { /*.....*/ };
//Class StackLL -- an implementation of a Stack.
class StackLL : public Stack { /* .... */ };
//Class StackAR-- implementation of a Stack.
class StackAR : public Stack { /* .... */ };
You must use C++ classes in a disciplined fashion to properly separate these two concepts.
This approach leads to a design which is more
1. Understandable/comprehensible
2. Flexible/extensible
3. Reusable 31
Fall 2002
SJSU --- CmpE M.E. Fayad

32. Guidelines
Define a type for every important concept in the problem domain
Support client by modeling their problem domain
Flexibility must be provided by developer
Pass function parameters by type
Flexibility must be received by client
Request services using the interface defined by the type
Avoid representation in types
Do not impose implementation upon derived C++ classes
“Client” refers to any user of an interface; a developer next door; a developer at a corporate partner; an end-user developer at a customer site. 32
Fall 2002
SJSU --- CmpE M.E. Fayad

33. Type-Oriented Paradigm
Subtypes
Topics
Subtypes Can Be Substituted for a Type
Guidelines for Subtyping
Repairing Improper Subtype Relationships
Programming to the Implementation Considered Harmful 33
Fall 2002
SJSU --- CmpE M.E. Fayad

34. Subtypes Can be Substitutable for a Type
Subtype is substitutable when it
Supports the entire interface defined by the type (behavior as well as signatures
Requires no more
Promises no less
May extend the interface by adding new operations
Type/subtype hierarchy equivalent to the Inheritance tree
Clients can be able to choose the interface they need 34
Fall 2002
SJSU --- CmpE M.E. Fayad

35. Guidelines for Subtyping
Define why a subtype is needed?
Which clients need to use types/subtypes in a substitutable fashion?
Define a subtype for each extended concept
An extended concept is still a concept
Subtypes normally extend the interface of an existing type
Define a subtype for each significant modification to a type
Removing requirements on client (weakening pre-conditions)
Adding promises (strengthening pre-conditions) 35
Fall 2002
SJSU --- CmpE M.E. Fayad

36. Repairing Improper Subtype Relationships
No “good” solution
Change specification of type
Change specification of subtype
Add/delete/rearrange operations
Admit that there is no type/subtype relationship
Modify type hierarchy 36
Subtypes implemented by their own classes.
Fall 2002
SJSU --- CmpE M.E. Fayad

37. Programming to the Implementation Considered Harmful
This is even more true when using object-oriented technology
When you use dynamic binding
•• You may get any one of several implementations
•• New implementations can be added anytime
•• The only thing all the implementations share in common is the well- specfied interface
Clients are at fault because they relied on the implementation instead of the interface.
Aside Developers would be at fault if they failed to specify the interface. 37
Fall 2002
SJSU --- CmpE M.E. Fayad

38. Type-Oriented Paradigm
Hierarchies & Inheritance
Topics
Type Hierarchy
Class Hierarchy
Subtyping versus Inheritance
Summary 38
Fall 2002
SJSU --- CmpE M.E. Fayad

39. 39 Interface Inheritance Substitutable Interfaces Subtyping
Type Hierarchy
Interface Inheritance
Substitutable Interfaces
Subtyping 39
Fall 2002
SJSU --- CmpE M.E. Fayad

40. 40 Implementation Inheritance Inherits Bits and Code Design Artifact
Class Hierarchy
Implementation Inheritance
Inherits Bits and Code
Design Artifact 40
Fall 2002
SJSU --- CmpE M.E. Fayad

41. Subtyping Versus Inheritance
Two Concepts, One Language Facility
Separate Hierarchies
Different Number of Hierarchies 41
Fall 2002
SJSU --- CmpE M.E. Fayad

42. 42 Summary Client Programs Use the Type Hierarchy
Type Hierarchy Encapsulates Design 42
Fall 2002
SJSU --- CmpE M.E. Fayad

43. Type-Oriented Paradigm
Maintenance, Modifications, and Enhancements
Topics
Modifying Classes in a Substitutable Manner
Modifying a Class - Small Change
Modifying the Type - Big Change
Summary - Three Roles for Substitutability 43
Fall 2002
SJSU --- CmpE M.E. Fayad

44. Typical Maintenance Paradigm
“Spaghetti” We
must throw away
everything
and start over!!! 44
Fall 2002
SJSU --- CmpE M.E. Fayad

45. Modifying Classes in a Substitutable Manner
Modifications include changing a class or substituting one class for another
The modifications still implement the same interface as defined by the specification.
//Purpose:
//Parameters:
//Requirements:
//Promises:
//Return values:
//Exceptions:
//Intentional vagueness: 45
Require no more, Promise no less
Fall 2002
SJSU --- CmpE M.E. Fayad

46. Modifying a Class -- Small change (1)
Modifications must conform to type interface
Modifying a class should not break client code.
If modifying the class breaks client code,
either the class is not a valid implementation
of the type or you need to modify the type.
Thus can have significant costs. 46
Fall 2002
SJSU --- CmpE M.E. Fayad

47. Modifying the Type -- Small Change (2)
Substitutable Modifications
1. Implements all operations
2. No affects on client code
3. May affect classes 47
Fall 2002
SJSU --- CmpE M.E. Fayad

48. Modifying the Type -- Big Change
Non-substitutable modifications
Requires more and/or promises less
Affects clients
affects classes
Becomes increasingly more expensive that later it occurs in the product life-cycle
May be inexpensive for developer
But it is extremely expensive when you consider the number of clients that are affected
Reuse client code
Due to:
Poor domain analysis
Improper understanding of client needs
Refinement
Late generalization 48
Fall 2002
SJSU --- CmpE M.E. Fayad

49. Summary: Three Roles for Substitutability
Between Type and Class
Between Type and Revised Type
Between Type and Subtype 49
Fall 2002
SJSU --- CmpE M.E. Fayad

50. Type-Oriented Paradigm
Goals & Qualities
Topics
Goals
Qualities
Extensibility
Composition 50
Fall 2002
SJSU --- CmpE M.E. Fayad

51. 51 Goals Better Quality Faster Development Lower Development Costs
Lower Product Life-Cycle Costs
Faster Modification and Enhancement 51
Fall 2002
SJSU --- CmpE M.E. Fayad

52. 52 Qualities Good Abstractions Proper Encapsulation
Understandable & Comprehensible
Implementation is Flexible
Extensible
Reusable 52
Fall 2002
SJSU --- CmpE M.E. Fayad

53. Type-Oriented Paradigm
Observations and Conclusions 53
Fall 2002
SJSU --- CmpE M.E. Fayad

54. 54 Conclusions Types are for Analysis Classes are for Design
Types More Valuable Than Classes 54
Fall 2002
SJSU --- CmpE M.E. Fayad

55. Discussion Questions (1)
1. Define: types and substitutability
2. Explain the following facts:
a. A type names an interface. b. A class implement a type.
c. One class can be substituted for another.
3. What are the elements of an interface? Provide examples
4. What are the elements of behavior?
5. How to specify behavior?
6. Mark (T) for true or (F) for false
( ) 1. A set of all signatures defined by an object’s operations is called the interface to the object.
( ) 2. A type is a name used to denote a particular interface.
( ) 3. An object can be substituted for another if it has the same type or it is a subtype of the other object.
( ) 4. Class inheritance allows classes to be defined simply as extensions of other classes. 55
Fall 2002
SJSU --- CmpE M.E. Fayad

56. Discussion Questions (2)
1. Define: type hierarchy, class hierarchy and subtypes
2. What are the guidelines for typing and subtyping?
3. When can subtype be substituted?
4. Explain:
a. Subtypes implemented by their own classes.
b. Modifying a class is a small change but modifying a type is a big change.
5. Mark (T) for true or (F) for false
( ) 1. Class inheritance allows classes to be defined simply as extensions of other classes.
( ) 2. When inheritance is used carefully, all classes derived from an abstract c lass will share the interface defined by the abstract class.
( )3. There are three ways to reuse functionality in OO systems: class inheritance, object composition, and information hiding. 56
Fall 2002
SJSU --- CmpE M.E. Fayad

57. Questions for the Next Lecture
Define:
Guidelines
Heuristics
What do you think of these heuristics
A designer should distribute system intelligence uniformly among the top level classes in the system.
A designer should have 4.6 top level classes per 1,000 lines of code.
Eliminate classes that are outside the system 57
Fall 2002
SJSU --- CmpE M.E. Fayad

58. Tasks for Next Lecture
Task 1: Think About a problem statement for your team Project (see sample problems on the course web site). This is due on the sixth week of the semester.
Task 2: Read Chapter 1 to 3 (Heuristics) and Chapter 8 UML 58
Fall 2002
SJSU --- CmpE M.E. Fayad