1. Object-Oriented Software Life Cycle

2. SOLID principles Single Responsibility Open Close
Each object should be responsible for only one task or functionality in the application.
Open Close
Open for extensions and closed for modifications
Liskov’s Substitution
Polymorphic substitution of objects
CS446/546

3. SOLID principles (continued)
Interface Segregation
Clients should only use the objects through the object’s interface
Dependency Inversion
Objects should depend on their abstractions, not on their levels (high-level, low-level, …)
Abstraction should not depend on details; rather, details should depend on abstractions
SOLID principles introduced by Robert Martin in early 2000.
CS446/546

4. Stages in OO life cycle Requirements engineering OO Design
requirements gathering, analysis and specification
inherently procedural because customers describe what the software system is supposed to do
OO Design
architectural design
detailed design
both require the transformation of functional requirements into OO design elements
Implementation or Coding or Programming using OO programming languages and tools
CS446/546

5. Stages in OO life cycle (continued)
Testing
unit testing; test methods within each object
integration testing; test collaborations between objects
system testing; test the entire system as a collection of objects
acceptance testing; test for standards and customer satisfaction
CS446/546

6. Maintenance
fixing bugs, enhancements, adapting to changing environment
all the three activities require that some objects to be changed; easy to trace those objects
add developed classes to library of classes, if appropriate
generalization
(possibly) create patterns and frameworks
reuse
CS446/546

7. Procedural and OO life cycles
Object-Oriented
Requirements
Requirements
Design
Design
Programming
Programming
CS446/546

8. 3-Tier Modeling of a data oriented system
GUI
Database
Application
DB Interface
CS446/546

9. OO Definitions and Concepts

10. Object What characterizes an “object”?
An object should possess attributes or behaviors, preferably both
An object can be primitive and well-understood
Example:
An object can be complex and needs to be defined further
Only those objects that are relevant to the goal of the problem should be modeled
CS446/546

11. Exercise Identify the objects in the following problems
A small store attached to a gas station sells several items. The store uses a database to maintain inventory, sales and profits. A report is generated at the end of each day on sales and purchases.
An intelligent traffic signal has four lights – RED, AMBER, GREEN and GREEN ARROW. The green arrow is turned on only when there is at least one vehicle on the turning lane. The signal is associated with a sensor to identify the vehicles in the turning lane.
CS446/546

12. Class and Objects
A class represents a group of objects who share similar structure and behavior
Class
Receipt
Speech
Objects
Receipt from BestBuy, Receipt on Dec 12
President’s speech, Keynote speech in a conference
CS446/546

13. Class Vs Object Template Created/defined by programmers
Can be abstract
One class represents a collection of objects
Actual structures with values (concrete)
Created by run-time system
Cannot be abstract
Each object belongs to exactly one class (traditional definition)
CS446/546

14. Class Vs Object (continued)
Class name serves as the identity
Static; serves as a source of definitions; possibly never be destroyed
Possesses an internal identity, generated by the run-time system
Dynamic; created and destroyed during execution; some objects may persist even after termination of execution
CS446/546

15. A bit of Theory
Classes are implementations of Abstract Data Types (ADTs)
An Abstract Data Type (ADT) is defined only by its behaviors without committed to any implementation
a Stack ADT
a behavior: Elements can be pushed in or popped out from one end of the stack.
The actual representation of the elements is not part of the definition of stack
a speech ADT
a behavior: must have a topic and contents
The actual representation of the topic or contents is not part of the definition of speech
CS446/546

16. A bit of Theory (continued)
Classes are implementations of ADTs
Why?
A class has a structure, along with its behavior
The integer data type is an ADT
The integer class in OO has a representation and hence a limitation (32 bits, 64 bits etc.)
The stack is an ADT
The stack class has a structure; may use an array for implementation; has a limited size
CS446/546

17. Encapsulation
When an object is encapsulated, its internal details are hidden and its usage is exhibited through its external interface.
Example:
Explain how an item in a store is encapsulated.
CS446/546

18. Encapsulation – a question
How to identify components of an external interface? How to identify internal details of an object?
needs application domain information and access restrictions
what seems to be an external interface for one person may be an internal detail for another person
levels of access restrictions
public, private, protected – terms used by C++ and Java
not just these; may be more
CS446/546

19. Encapsulation Vs Information Hiding
Encapsulation is a concept
Information hiding (how to) is a concretization process of encapsulation (what)
information hiding implements encapsulation
OO analysis deals with encapsulation
OO design and implementation take care of information hiding
CS446/546

20. Communication between Objects
Objects communicate with each other or interact among themselves by message-passing
Single thread of control - client-server mode of communication
Client sends a message to server indicating a request and server sends a response back to client through another message
Requires that client and server know each other
Communication link established statically or dynamically
CS446/546

21. Communication (continued)
Multiple threads of control
Each object sends messages to one or more objects and continues to execute its own tasks
Information shared through messages
Each object should know the other objects with which it communicates
Communication link established statically or dynamically
CS446/546

22. Communication (continued)
Pre-defined / static communication links
Designer / programmer knows / decides well in advance the links between the objects
Explicit in the class definitions
inheritance, aggregation, association (will be discussed shortly)
Dynamic communication links
Decided at run-time
delegation
CS446/546

23. Static Relationships among Classes

24. Static Relationships
Decided during the analysis phase and/or the design phase, and carried over to the implementation phase
Establish static communication links
Three types
-Association
-Aggregation
-Generalization/specialization
CS446/546

25. Association Denotes a relationship between the objects
Some relationship between the objects that is meaningful in the chosen application domain
Synonymous to “relation” in databases
CS446/546

26. Association – example 1 In a course registration system,
A student object has an association with a course object
the student object depends on some information in the course object
The course object has another (different) association with the student object
the course object needs to know the identification of the student if he/she registered for that course
Both associations are unidirectional
CS446/546

27. Association – example 2 In an automated ticket purchasing system,
A customer object has an association with a ticket object
Customer purchases ticket
An administrator object may have an association with the ticket object
Administrator changes the price of a ticket
Both associations are unidirectional
CS446/546

28. Association – Example 3 In a university game system,
A game object has an association with a team object
A player object has an association with a team object
A game may have an association with a player object
The best player of the game
This is a ternary (3-way) association
CS446/546

29. Association – Example 4 In an office environment,
A person object may have an association with another person
One person works for another person OR
One person supervises another person
In a computer program,
A statement has an association with another statement
The body of an IF statement may include an assignment statement
These are unary (1-way) associations
CS446/546

30. Association (continued)
Generally identified during the analysis phase
Not all associations are refined into the design phase and/or into the implementation phase
Some are useful in understanding the application domain and may lead to a better design
N-ary associations may give clues to identify concurrency issues
CS446/546

31. Association - exercises
Identify the objects and associations between them in the following problems
A small store attached to a gas station sells several items. The store uses a database to maintain inventory, sales and profits. A report is generated at the end of each day on sales and purchases.
An intelligent traffic signal has four lights – RED, AMBER, GREEN and GREEN ARROW. The green arrow is turned on only when there is at least one vehicle on the turning lane. The signal is associated with a sensor to identify the vehicles in the turning lane.
CS446/546

32. Specialization
Specialization is also called “Generalization” relationship
Specialization describes how one class becomes a specialized version of another class
There must be some difference between the two classes but there must also be some commonality.
Do not use specialization relationship just for code reuse purposes
CS446/546

33. Specialization (continued)
Specialization relationship forms a hierarchy and is defined from a child to a parent
It is a transitive relation
If a grandchild is a specialization of a child and the child is a specialization of a parent, then the grandchild is a specialization of the parent
Example:
A Color Laser Printer is a specialization of a Laser Printer which in turn is a specialization of a Printer
Find out the differences and common features between the child and parent classes
CS446/546

34. Specialization (continued)
Another name for the specialization relationship is “generalization” which is a view from parent to child
The parent class is called “superclass”, “base class”, or “parent”
The child classes are called “subclasses”, “specialized classes”, “derived classes” or “children”
CS446/546

35. Specialization - Exercise
Give some classes and specialization relationships for the following problem:
A software system that maintains the catalog of materials in a university library
A software system used by a car dealer
An electronic voting system
CS446/546

36. Multiple specialization relationship
A subclass may be a specialized version of more than one superclass
It is called “multiple inheritance property” in OO programming languages
Designers must ensure that the properties inherited from the multiple superclasses do not conflict with each other
Most of the OO programming languages provide some mechanism to work around this problem
CS446/546

37. Aggregation
Also known as “composition” relationship, and “has-a/contains” relationship
Synonymous to “structure” in C and C++
Basic idea is to group a set of entities/fields into one single bundle and use it as a single entity
Denotes composition of objects
An aggregate object encloses a component object
The aggregate object cannot exist without the component but the component may exist without the aggregate
CS446/546

38. Aggregation (continued)
Examples
A person object encloses an address object
A ticket object encloses date object
A seminar object encloses a contents object, a theme object and a duration object
A book object encloses ….
A car object encloses ….
CS446/546

39. Aggregation (continued)
Sometimes reflexive (recursive aggregation)
A procedure may contain another procedure (Pascal)
A class may contain another class (Java)
Requires careful design and implementation mechanisms
Aggregation is a special case of Association
Is it not interesting to know?
A person object contains an address object
So, the person object depends on the address object  existence of a semantic dependency
CS446/546

40. Aggregation - exercises
Define the aggregation relationships, if any, in
The library catalog system discussed earlier
The software system used by the car dealer
The electronic voting system
CS446/546

41. Confusion between Specialization and Aggregation
Often, designers and programmers (particularly the latter) get confused between specialization and aggregation
Consequence: choose the wrong relationship
Will this decision affect the software product?
YES… in the long run.. may not be significant
CS446/546

42. Specialization Vs Aggregation
Relationship between classes
Objects of these classes are totally unrelated
Is not reflexive
Relationship between objects, even though their respective classes are used to define the relationship
Objects are related by composition
Sometimes reflexive (recursive aggregation)
CS446/546

43. Specialization Vs Aggregation - An Example
Toyota Camry is a Car
by “is a” relationship, we can say Camry is a specialization of a car  Specialization
The class car has an attribute called “model” which is instantiated with the value “Camry”  Aggregation
car is an aggregate and “Camry” is the value of one of its component, namely model
Both are indeed correct
which one to choose…. depends on the context
CS446/546

44. Specialization Vs Aggregation – Another example
An ENT specialist is a specialization of a physician in a hospital
specialization relationship
A physician object includes a field called “specialty” that describes the specialization of a physician
aggregation relationship
The first one may be used in the hospital whereas the second one may be used in the City Office for book-keeping
CS446/546

45. Abstract Class A class that cannot be instantiated
No direct objects for this class
At least one of its behavior definitions must be incomplete
Example: The class Printer has a behavior “print” which is deliberately left unspecified because it requires additional information depending on the type of printer
A subclass of an abstract class may itself be still abstract
CS446/546

46. Uses of abstract class
Intended to define general characteristics of an object in an abstract class with some behaviors deliberately left undefined  make the class abstract
Another class (may be more than one) specializes the abstract class and complete the undefined behavior
Basic idea is to capture more general properties separately in an abstract class
CS446/546

47. Abstract Class - examples
One-level refinement
Printer is an abstract class which includes a behavior called “print” but does not define the behavior
Deliberately left undefined because we do not know the type of the printer
Postscript printer is a concrete class which specializes Printer and completes the behavior “print”
CS446/546

48. Abstract class – Examples (continued)
One-level refinement (continued
Inkjet printer is another concrete class which specializes Printer and completes the behavior “print” in a different way
Postscript printer 600 may be another concrete class which specializes Postscript printer, but both are concrete classes
CS446/546

49. Abstract class – examples (Continued)
Two-level refinement
Polygon is an abstract class which includes two incomplete behaviors “area” and “number of sides”
4-sided figure is an abstract class which specializes Polygon and completes the definition of the behavior “number of sides”, but the behavior “area” is still left incomplete and so this class is still abstract
Rectangle is a concrete class which specializes 4-sided figure and completes the definition of the behavior “area”
Square is another concrete class which specializes Rectangle but redefines the behavior “area”
CS446/546

50. Metaclass Class whose instantiations are class definitions
High level concept; not used by end users
UML uses the concept of meta classes to define the semantics of other entities in UML notation
Refer to UML manual from OMG
Meta class concept is supported by Smalltalk, CLOS
CS446/546

51. Inheritance
A mechanism to implement (normally) a specialization relationship
Specialization is a concept, whereas inheritance is a mechanism
Analogous to encapsulation and information hiding
A distinguishing feature of object-oriented programming
Subclass inherits features (structure and behavior) of superclass
interface or internal or both??
Traditionally viewed as a code reuse mechanism in AI and non-OO applications
CS446/546

52. Inheritance- examples
HDTV inherits features of TV
Mechanism: adds more features
High Definition Signal receiver is included
Student president inherits Student
mechanism: adds more features
adds additional responsibilities
Square inherits Rectangle
mechanism : redefines perimeter and area
restricts the length and breadth to be the same
CS446/546

53. Three types of Inheritance
Inheritance by expansion
Subclass adds more features in addition to the features that are inherited from the superclass
Internship student inherits Student and adds employment details -- structural expansion
Student President inherits Student and adds administrative duties -- behavioral expansion
CS446/546

54. Three types of Inheritance (continued)
Inheritance by restriction
Subclass restricts some of the features that are inherited from the superclass
Subclass does not want its objects to use these restricted features
A “special non-degree” student is a specialization of student, but the former restricts the behavior “getProgram()” because the “special non-degree” student is not associated with any program
A “fixed-deposit” account is a specialization of account but the former restricts the behavior “withdraw”
CS446/546

55. Three types of Inheritance (continued)
Inheritance by redefinition
Subclass may redefine one or more features that are inherited from the superclass
CS department inherits Department and may redefine the behavior “admission requirements”
Square inherits Polygon and redefines the behavior “area”
Structural redefinition is generally not permitted in OO programming languages since the redefinition may not be meaningful
CS446/546

56. Polymorphism
Generally implementation-oriented, but still can be considered at the design level
“Ability to exist in more than one form”
- Oxford Dictionary
Advantage in OO design/programming
able to use one class/object/method in multiple contexts
CS446/546

57. Types of Polymorphism Universal polymorphism Parametric polymorphism
Provided by parametric classes
When parametric classes are instantiated, they exist in different forms
Examples
CS-Course[546], CS-Course[341]
Sony[TV] and Sony[DVD]
CS446/546

58. Polymorphism (continued)
Universal polymorphism (continued)
Inclusion polymorphism
Supported by inheritance
Subclass objects substituted for superclass objects
A subclass object when substituted for a superclass object behaves identically as a superclass object
CS446/546

59. Polymorphism (continued)
Inclusion polymorphism examples
A Flat panel TV can be substituted for a TV
A student seminar can be substituted for a seminar
A Student President object can be substituted for an object of Student
A CS faculty member object can be substituted for a University faculty member object
CS446/546

60. Polymorphism (continued)
Inclusion polymorphism (continued)
Valid only for inheritance by expansion
If inheritance by restriction or inheritance by redefinition is used, the subclass object WILL NOT BEHAVE identically as expected for the superclass object
One exception for the condition on inheritance is the use of abstract classes
Abstract classes cannot be instantiated; only subclass objects can support when abstract class needs to be instantiated; redefinition is mandatory in this context, but still exhibits inclusion polymorphism
CS446/546

61. Polymorphism (continued)
Ad hoc polymorphism
Exists at the level of behavior definitions
More than one definition for the same behavior
“sort” can be used to sort elements of different types
More than one constructors in Java and C++
Mostly a feature of OO programming
Redefining an operator definition (also called operator overloading)
CS446/546