Software Engineering and
Object-Oriented Design and Development
CSE300
Prof. Steven A. Demurjian, Sr.
Computer Science & Engineering Department
The University of Connecticut
371 Fairfield Road, Box U-255
Storrs, CT 06269-2155
steve@engr.uconn.edu
http://www.engr.uconn.edu/~steve
(860) 486 - 4818
Copyright © 2000 by S. Demurjian, Storrs, CT.
SW&OO-1.1
Overview of Presentation


CSE300




Motivation and Background Concepts
Software Engineering Qualities and Principles
 Extensibility, Correctness, Reliability, etc.
 Abstraction, Modularity, Incrementality, etc.
Revisiting Core Object-Oriented Concepts
 Encapsulation, Hiding, Inheritance, etc.
Advanced Object-Oriented Concepts
 Polymorphism, Dispatching, Generics, etc.
OO Design, Programming, and Databases
 Assessing Available Technologies
 Predicting the Future
Summary and Discussion
SW&OO-1.2
What is Software?

CSE300

Software is the Definition and Organization of a
Set of Tasks and Functionality Encapsulated into a
Form that is Executable on a Computer
What are Different Types of Software?
 Commercial-Off-the-Shelf (COTS)
 Legacy: Written in an “Old” Programming
Language
 Cobol, PL/1 (Y2k/SNET), Fortran, etc.
 C and C++!



Customized New Software
Client vs. Server Software
Database Management Systems/Applications
SW&OO-1.3
What is Software Engineering?

CSE300 


Engineering: The Application of Science to the
Solution of Practical Problems
Software Engineering: The Application of CS to
Building Practical Software Systems
Programming
 Individual Writes Complete Program
 One Person, One Computer
 Well-Defined Problem
 Programming-in-the-Small
Software Engineering
 Individuals Write Program Components
 Team Assembles Complete Program
 Programming-in-the-Large
SW&OO-1.4
Why Software Engineering?

CSE300 


Program Complexity Transcends Individual or
Lone Programmer
Software Engineering Targeted for
 Constructing Large Software Applications
 Defining Problem Clear and Completely
 Tools and Techniques to Support Process
 Team-Oriented Experience
Software Engineering must Evolve to be an
Engineering Discipline
Software Engineering Must Promote and Support
Multi-Person Construction of Multi-Version
Software
SW&OO-1.5
Software Engineering
A Historical Perspective

CSE300
“Early Days”
 1950’s Programmers Wrote Programs
 Early 1960’s - Very Large Software Projects
Constructed by “Experts”
 Mid-Late 1960’s - Advent of Large
Commercial Software Applications
 Large Systems Involved Teams of Individuals
 Coining the Term “Software Engineering”


Towards a Software Engineering Discipline
 Individuals Couldn’t see “Big Picture”
 Increase in Communication Time
 Personnel Changes Impact on Productivity
SE: Management, Organization, Tools, Theories,
Methodologies, Techniques, etc.
SW&OO-1.6
Influences on Software Engineering

CSE300


Cost of Software Continues to Increase, Requiring
More Efficient Software Production
 Software Acquisition vs. Outsourcing
 Software Reuse vs. Build-from-Scratch
Complexity of Large Software Altered the View
from Development Perspective
Conception
Design
Development
Integration
Distribution Documentation
Maintenance Evolution
Extension
Software Engineering/Computer Science Growth
 350,000 Information Technology Jobs Open
 100,000 New Jobs per Year for 10 Years
SW&OO-1.7
Programmer vs. Software Engineer

CSE300 




Individual with Good
Skills
Programming-in-the-Small
Knowledge on
 Data Structures
 Algorithms
Fluent in Several
Programming Languages
May Lack Formal Training
Minimal Exposure to CS









Part of a Team
Programming-in-theLarge
Design Approaches
 OO, Modules, etc.
 Top-Down/Bottm-Up
Translates Requirements
into Specifications
Familiarity in Multiple
Application Areas
Converses with Users
Sees “Big Picture”
Can Model Application
Good Communication
and Interpersonal Skills
SW&OO-1.8
How is Software Engineered?
Waterfall Process Model
Requirements
Analysis and
Specification
What is Major Disadvantage?
CSE300
Design and
Specification
Coding and
Module Testing
50 %
Integration and
System Testing
Delivery and
Maintenance
50 %
SW&OO-1.9
Software Lifecycle of Waterfall Model

CSE300

Requirements Analysis and Specification
 What is the Problem to Solve?
 What Does Customer Need/Want?
 Interactions Between SE and Customer
 Identify and Document System Requirements
 Generate User Manuals and Test Plans
Design and Specification
 How is the Problem to be Solved?
 High-Level Design
 Determine Components/Modules
 Transition to Detailed Design
 Detail Functionality of Components/Modules
SW&OO-1.10
Software Lifecycle of Waterfall Model

CSE300


Coding and Module Testing
 Writing Code to Meet Component/Module
Design Specifications
 Individual Test Modules in Isolation
 Drivers and Stubs to Simulate Behavior
Integration and System Testing
 Integration of Components/Modules into
Subsystems
 Integration of Subsystems into Final Program
Delivery and Maintenance
 System Delivered to Customer/Market
 Bug Fixes and Version Releases Over Time
SW&OO-1.11
Relating Software Engineering and
Computer Science Disciplines

CSE300
SE to Programming Languages
 Modularity for Independent Compilation
 Separation of Design and Implementation
 Migrating Software Engineering Concepts into
Programming Languages
 Classes in C++ (Implementation of ADTs)
 Packages in Java/Ada95 (Modularization)

Programming Languages to SE
 Precise Description of Requirements and
Design
 Compiler Tools that Enhance D & D
 Advanced Compilers and Libraries to Improve
Productivity and Facilitate Reuse
SW&OO-1.12
Relating Software Engineering and
Computer Science Disciplines

CSE300

SE to Operating Systems
 Relationship Between Components and
Versions
 Protected/Non-Protected Portions of OS
 Vehicle Through Which Programs Developed
Operating Systems to SE
 Virtual Machines - Evolving to Platform
Independence with Java
 Levels of Abstraction Offered by OS
 Device Driver through GUI of OS
 Java Offers Strong OS Interactions

Separation of Design and Implementation
SW&OO-1.13
Relating Software Engineering and
Computer Science Disciplines

CSE300
SE to Databases/Security
 Every Application Contains Database and
Requires Access Control





Storage of Large, Unstructured Objects
Incorporation of Multi-Media and Web Based Data
Versioning and Long-Term Transations
Tracking Who Can Use/See What When
Databases/Security to SE
 Promoting Data Independence
 De-coupling Data Definition from Usage
 Databases as Expected Components in
Applications
 Security in Applications and Across Networks
SW&OO-1.14
Relating Software Engineering and
Computer Science Disciplines

CSE300

AI to SE
 Exploratory Development and Scenarios
 Declarative Approach
 Natural Language and Voice Interfaces
Theoretical Models to SE
 Finite State Machines for Program Behavior
 Queueing and Simulation Models
 Petri Nets for Resource Behavior
 Regular and Context Free Grammars for
Programming Languages/Compilers
 NP vs. P: Computational Complexity
SW&OO-1.15
Relating Software Engineering
to Other Disciplines

CSE300



SE and Management
 Management/Team Models Applied to
Software Project Management/Process Control
 Important Test Domain to Test New Models
and Theories for Management
SE and ESE, ME, ChemE, CivilE, etc.
 Job Growth in Engineering Specific Software
SE and Biology, Chemistry, Medicine, etc.
 Medical Research and Informatics, Genome
SE and Financial Sector
 Banking, ATM Networks, Electronic
Commerce, Funds Transfers, Program Trading,
Stock and Brokerage Houses, etc.
SW&OO-1.16
Information Sources

CSE300 



Motivation and Background Concepts
 CSE 327 Adv. SW Engineering Class Notes
Software Engineering Qualities and Principles
 Fundamentals of Software Engineering, Ghezzi
et al., Prentice-Hall, 1991.
Revisiting Core Object-Oriented Concepts
 An Introduction to Object-Oriented
Programming, Budd, Addison-Wesley, 1997.
Advanced Object-Oriented Concepts
 Readings in Object-Oriented Databases,
Zdonik/Maier (eds.), Morgan-Kaufman, 1990
OO Design, Programming, and Databases
 Prof. Heidi J.C. Ellis, RPI at Hartford, UConn
PhD, 1994, www.hgc.edu/~heidic
SW&OO-1.17
Motivation and Background Concepts

CSE300

Information Engineering for 21st Century
 Creation of Information
 Generation of Information
 Utilization of Information
 Software, Database, Security, Performance
Requirements for Application D & D
Abstract Data Type and Object-Oriented Class
 Introduce the Core Concepts
 Abstract Data Types (ADTs) - 1970s
 Object-Oriented Paradigm - 1980s
 Relevance of ADTs and OO Classes when
Discussing Software Qualities/Principles
SW&OO-1.18
Information Engineering
Challenge for 21st Century

CSE300

Timely and Efficient Utilization of Information
 Significantly Impacts on Productivity
 Key to Many (All?) Companies Future
 Supports and Promotes Collaboration for
Competitive Advantage
 Individual/Companies Use Information in New
and Different Ways
Collection, Synthesis, Analyses of Information
 Better Understanding of Processes, Sales,
Productivity, etc.
 Dissemination of Only Relevant/Significant
Information - Reduce Overload
SW&OO-1.19
How is Information Engineered?


CSE300




Careful Thought to its Definition/Purpose
Thorough Understanding of its Intended Usage
and Potential Impact
Insure and Maintain its Consistency
 Quality, Correctness, and Relevance
Protect and Control its Availability
 Who can Access What Information in Which
Location and at What Time?
Long-Term Persistent Storage/Recoverability
 Cost, Reusability, Longitudinal, and
Cumulative Experience
Integration of Past, Present and Future Information
via Intranet and Internet Access
SW&OO-1.20
Future Design Emphasis


CSE300
Focus on Information and its Behavior
Answer the Following Questions
 What are Different Kinds of Information?
 How is Information Manipulated?
 Is Same Information Stored in Different Ways?
 What are Information Interdependencies?
 Will Information Persist? Long-Term DB?
Versions of Information?
 What Past Info. is Needed from Legacy DBs or
Applications?
 Who Needs Access to What Info. When?
 What Information is Available Across WWW?
SW&OO-1.21
Abstract Data Types (ADTs)


CSE300



Proposed by B. Liskov (MIT) for CLU in 1975
ADTs Promote Application Development From
Perspective of Information and its Usage
ADT Design Process:
 Identify “Kinds” or “Types” of Information
 Encapsulate Information and Provide a
Public Interface of Methods
 Hide Information and Method Code in the
Private Implementation
ADTs Correspond to User-Defined Data Types
Analogous to Integer Data Type and +, -, *, etc.
SW&OO-1.22
Abstract Data Types (ADTs)

Consider the following Example Stack ADT:
Public
Interface
CSE300
Private Implementation
Head: Int;
ST: Array[100] of Int;
User
PUSH
POP
TOP
EMPTY
Designer
Push(X Int)
…
End;
Int Pop()
…
End;
PUSH
5
10
15
20
20 15
10
5
ST
5
TOP
20
15
10
5
SW&OO-1.23
ADT Design Guidelines

CSE300 



Separation of Concerns and Modularity
 Problem Decomposable into Components
Abstraction and Representation Independence
 Hiding Implementation of Components
 Changing without Impacting External View
Incrementality and Anticipation of Change
 Components are Changed, Added, Refined,
etc., as Needed to Support Evolving
Requirements
Cohesion: Well-Defined Component Performs a
Single Task or has a Single Objective
Coupling: Component Interactions are Known and
Minimal
SW&OO-1.24
Object-Oriented Paradigm

CSE300


Object-Oriented Decomposition
 Decompose Problem into Agents which
Perform Operations
 Emphasize Agents that Cause Actions
Agents Comprised of Two Parts
 Hidden Implementation: Data and Operations
only Available to Agent
 Public Interface: Operations Available to
Clients of Agent
An Agent Can Only be Modified by Operations
Defined in either the Hidden Implementation or
Public Interface
SW&OO-1.25
Core Object-Oriented Concepts

CSE300



Class
 The Type of an Agent
 Describes the Behavior
Object
 The Instance of a Class
 Represents Actual Data Manipulated by Agents
 Maintains the State of Object
Method
 Operation Defined on a Class
 Operates on ALL Instances of the Class
Message
 Indicates that an Object’s Method Invoked
SW&OO-1.26
An Example Employee Class
CSE300
Class Employee
{
//Hidden Implementation
Private: //Instance Vars
char[30] name;
float
salary;
//Public Interface
Public:
void print_name();
void print_salary();
void update_salary(float i);
Employee(char *n, float s);
}
What’s Output of Main()?
Steve
100.0
Lois
130.0
Main()
{
//Declare Objects
Employee emp1(Steve,100.0);
Employee emp2(Lois, 120.0);
//Pass Messages
//Invoke Methods
emp1.print_name();
emp1.print_salary();
emp2.update_salary(10);
emp2.print_name();
emp2.print_salary();
}
Conclusion:
Each Object (emp1,emp2) has
Own Independent State that
is Accessible via Shared
Public Interface of Class
SW&OO-1.27
Modules vs. ADTs/Classes

CSE300


Module
 Describes Both State and Behavior
 Module Employee Includes Instance Variables,
Operations, and Program Variables
 Single Instance Shared by All Users
Class
 Describes Only the Behavior
 Class Employee Omits Program Variables
 Multiple Independent Instances Share Same
Class Declaration but have Separate States
Key Difference: Dynamic Nature of Classes
Allows Instances to be Created as Needed
SW&OO-1.28
Advanced Object-Oriented Concepts

CSE300


Inheritance
 Controlled Sharing of Between Classes
Generalization and Specialization
 Treat Instances of Different Classes in Uniform
Fashion - Leading to …
Polymorphism/Dynamic Binding
 Run-Time Choice of the Method to be Invoked
Based on the Type of the Calling Instance
 Message Passed is Type Dependent
Generic: A Type Parameterizable Class
 Stack has Parameter for Type of Element
 Creation of Program Variable Binds Stack Data
and Methods to Specific Type of Element
 Stack(Real), Stack(Int), Stack(Employee)
SW&OO-1.29
A Quick Look at Inheritance
Specialization
CSE300
Person
Name, SSN
Print_Info()
Employee::Person
Dept, Salary
Update_Salary()
Faculty::Employee
Rank
Promote_Fac()
Generalization
Student::Person
Dorm, GPA
Print_Transcript
Dean::Employee
School
Supertype, Superclass, Parent Class, Base Class
Subtype, Subclass, Child Class, Derived Class
Descendants, Ancestors, Siblings
SW&OO-1.30
What Can Be a Class?
Private Data
CSE300
Public Interface
Chunk of Information
Employee
Class
Name
Address
SSN
...
Create_Employee()
Give_Raise(Amount)
Change_Address(New_Addr)
...
Functional Component
ATM_Log
Class
Acct_Name
PIN_Number
...
Check_Database(Name)
Verify_PIN(PIN)
Log_on_Actions(Name, PIN)
Reject()
...
SW&OO-1.31
What Can Be a Class?
Private Data
CSE300
Public Interface
User Interface
ATM_User
Class
Action
Balance
WD_Amt
...
Log_on_Steps()
Acct_WithD(Amt)
Check_Balance(Number)
Deposit_Check()
...
Or --- Anything that you Want!
SW&OO-1.32
Client/Server Concepts and Classes


CSE300




Client C and Servers S1, S2, S3, etc …
A Client Request Services to Carry Out Functions
 Client C Imports Services from S1, S2, …
 Client C Utilizes Public Interfaces of Si’s
A Server Provides Services for Use by Other
Clients and Servers
 Server Si Exports Services for Use
 Server Si Imports Services from Other Servers
Pure Client: No Public Interface, Imports Services
Pure Server: Only Exports Services
Mixed:
 Gravitate Towards “Mostly” Client or Server
 50-50 Split (40-60, etc.) also Likely
SW&OO-1.33
Benefits of OO Paradigm

CSE300


Supports Reusable Software Components
 Creation and Testing in Isolation
 Integration of Working Components
 Designers/Developers View Problem at Higher
Level of Abstraction
Controls Information Consistency
 Public Interface Limits Access to Data
 Private Implementation Unavailable
Promotes/Facilitates Software Evolution/Reuse
 Inheritance to Extend Design/Class Library
 Multiple Instances of Same Class
SW&OO-1.34
Software Engineering Qualities

CSE300 

Software is a Malleable Product that is Human
Intensive (High People to Machine Ratio)
A Software Quality is a Characteristic to be
Attained throughout an Application’s Lifetime
 Correctness and Reliability
 Robustness and Performance
 Maintenance and Reusability
 Repairability and Evolvability
 Portability and Interoperability
Types of Software Qualities
 Internal vs. External
 Process vs. Product
SW&OO-1.35
What is a Software Quality?

CSE300 


A Software Quality is a Characteristic to be
Attained throughout an Application’s Lifetime
Software Qualities are the Goals of Product and
Process
Types of Software Qualities
 Internal - within the Software - Developers
 External - Look-and-Feel of Software - Users
 Process - related to a Software’s Production
 Product - Artifacts Produced during Process
Software Quality Assurance: Assess and Evaluate
the Attainment of Qualities by Finished Product
SW&OO-1.36
The Correctness Software Quality

CSE300 


Functional Correctness: Software Behaves
According to Requirements Specification
Assessing Correctness - Potential Problems
 Assumes Requirements Specifications are
Available and Up-to-Date
 Assumes Correctness Testing is Possible
 Assumes Mathematical Properties can be
Established Between Software and Specs
Correctness - Absolute Quality (Yes/No)
Correctness and OO Paradigm
 Focus on Correctness of Components at
Varying Levels
 Addressed via Public Interface, Private
Implementation, and Testing of Classes
SW&OO-1.37
The Reliability Software Quality


CSE300 

Software Performs as User Expects
User Can Depend on Software
Different Reliability Requirements per Domain
 Computer Games: Low?
 Flight Control Software (Mars): High?
 Banking, Insurance, Stocks, …: High?
Correct Software is Reliable but Reliable Software
May Not be Correct, that is …
Reliability
Correctness

For OO, Focus on Reliability of Components
(Classes) and their Composition into Systems
SW&OO-1.38
The Robustness Software Quality

CSE300 



Software Behaves Reasonably, Even in
Unexpected Circumstances
Different Robustness Requirements per Domain
 Computer Games: Low or High?
 ATM Machine: High - Hard to Break
May Include Hardware Robustness (ATM Story)
Incorrect Behaviors Acceptable, as Long as a
Consistent, Workable Outcome Occurs
Robustness and OO Paradigm
 Focus on Robustness of Classes
 Java Provides Exception Handling that Can be
Easily Built into Each Class for Robustness
 Robustness Transcends D & D Paradigm
SW&OO-1.39
The Performance Software Quality

CSE300 



Performance is Equated with Efficiency,
Scalability, Reliability, User-Acceptance, etc.
Growing Problem Impacts Strongly on Software
 Varied OS Platforms (NT, Win95/98, Solaris)
 Different HW Capabilities (Memory Size,
Pentium 166 vs. 200 vs. 300 vs. 400, Display)
Measurement vs. Queuing Analysis vs. Simulation
Impact from Specification through Delivery
Performance and OO Paradigm
 Identify Key Classes with Hard Performance
Constraints
 Versions of Classes for OS/HW Platforms?
SW&OO-1.40
The Maintenance Software Quality

CSE300 


Modifications and Enhancements Made to Product
After Release - 60% of Total Software Cost
Three Types of Maintenance
 Corrective: Remove Errors Post Delivery(20%)
 Adaptive: Adjust Per OS/HW Changes(20%)
 Perfective: Improve Qualities/Features(50%)
Modification to Legacy Software for Major
Improvement or Software Evolution
Maintenance and OO Paradigm
 Can OO Reduce Corrective Maintenance?
 Can OO Facilitate Adaptive and Perfective
Maintenance?
SW&OO-1.41
The Reusability Software Quality

CSE300 



Strive for Domain-and-Organization Specific
Reuse
Products Most Likely to be Developed in Future
Focused on Software Components
 Scientific Math and String Libraries
 Windowing and GUI Building Blocks
 Java APIs for Enterprise, Embedded, etc.
Reusability Evolving to Larger Components (e.g.,
Java Beans) and Subsystems
Reusability and OO Paradigm
 Achieved via Inheritance and Generics
 Defined and Controlled by Designers and
Developers
SW&OO-1.42
The Repairability Software Quality

CSE300





Ability to Correct Problems with Limited Amount
of Work and a Minimal Impact
A Well Modularized Product is Easier to Modify
than a Monolithic Project
Programming Language Role in Repairability
What is Classic Repairability Problem Today?
Repairability Related to Reusability/Evolvability
Repairability and OO Paradigm
 Repairs Focused on Class or Classes
 If Public Interface Remains Unchanged
Then No Impact as a Result of Repair
SW&OO-1.43
The Evolvability Software Quality


CSE300



Field of Dreams: If you Build it, it Will Change!
Key Evolvability Issues
 Ease of Modifications - Add New Features and
Change Existing Features
 Function of System Size
 Modularization vs. Monolithic
Over Time, Evolvability Reduces as Subsequent
Versions of Same Software are Released
Reach of Limit of Change w.r.t. Look-and-Feel
Evolvability and OO Paradigm
 Achieved via Inheritance and Polymorphism
 Public Interface Must Remain Unchanged!
SW&OO-1.44
The Portability Software Quality


CSE300 


Software Works on Different Platforms
Origins and Popularity of C and Unix
Hard in Practice - All C++’s Not Created Equal
 Borland C++ vs. Visual C++ vs. Sun C++
 16 vs. 32 vs. 64 bits
 Core Language Same? (Operator Precedence)
 Compiler/Product Specific Libraries
Newer Languages (Ada95, Java) Stress Ability to
Port without Rewriting Any Code
Portability and OO Paradigm
 Isolate Specifics into Dedicated Classes
 Portability Transcends D & D Paradigm
SW&OO-1.45
The Interoperability Software Quality

CSE300 



Enterprise Computing: The Problem of Today
and Future!
New Products Must Coexist and Cooperate with
Legacy, COTS, Databases, etc.
Success in Interoperability Traced to …
 Programming Interface for COTS/Legacy
 DCOM/OLE, CORBA, DCE
 Emerging Languages: Java, Active-X
Open Systems, Standards, Multiple Vendors, etc.
Interoperability and OO Paradigm
 Focus on Public Interface Concept
 Interoperability Transcends D & D Paradigm
SW&OO-1.46
Software Engineering Principles

CSE300
Principles Involve Software Engineering Process
and its Product
 Methods and Techniques: Systematic
Approaches for Modeling Software
 Methodology: Methods/Techniques Organized
into a Process that Assists in Problem Solving
 Pressman’s Process Advisor
 CMU’s Software Engineering Institute (SEI)

Software Engineering Principles
 Separation of Concerns and Modularity
 Abstraction and Anticipation of Change
 Generality and Incrementality
SW&OO-1.47
What are Software Principles?

CSE300 
Software Principles are the Guiding Factors that
Govern any and all Software Design/Development
Software Principles Transcend the Application to
Focus on Software Engineering Process/Product
Tools
Methodologies
Methods &
Techniques
Software
Principles
SW&OO-1.48
Separation of Concerns


CSE300


Divide and Conquer Problem Solving Technique
Identify the Different Aspects of Problem
 Time Considerations - Scheduling
 Focus on Qualities of Primary Concern
 Alternate Views of Problem - Data vs. Control
 Size-Oriented Decomposition
Today’s Applications involve Interoperability of
 New C/S, Legacy, COTS, Databases, etc.
 Multiple Prog. Languages (C, C++, Java, etc.)
 Heterogeneous Hardware/OS Platforms
Separation of Concerns is Critical!
SW&OO-1.49
Modularity


CSE300



Compose and Design Systems as Set of Modules
Two-Phase Application of Separation of Concerns
 Define Details of Individual Modules
 Characterize Interactions Among All Modules
Three Goals of Modularity
 Decomposability: Problem to Subproblems
 Composability: Combine to Solution
 Abstraction: Capability of Understanding
Levels of Modules in Programming
 C: “.h/.c” Pairs - Ad-hoc Modularity
 C++: “.h/.c” Pairs for Classes
 Ada95/Java: Adds the Package Concept
Maximize Cohesion and Minimize Coupling
SW&OO-1.50
Abstraction

CSE300 



Remove/Hide Unimportant Details to Allow more
Important Aspects of a Product to be Considered
Widely Utilized to Reduce Complexity
Abstractions Dominate Computing
 Paradigms (OO, Top-Down, Functional, etc.)
 Design Models (CRC, OMT, UML, etc.)
 Programming Languages (C, C++, Java, etc.)
People Think and Learn in Abstractions
Goals of Advances in Design and Programming
 Provide Robust Sets of Abstractions
 Allow Modeling to Occur Close to Real World
SW&OO-1.51
Anticipation of Change

CSE300 





Software Changes and Evolves Throughout All
Stages from Specification Onward
Key is to Anticipate Future Changes
Once Anticipated, Encapsulate Areas for Potential
Changes into Targeted Portions of Product
Is Anticipation of Change Unique to Computing?
Handling Anticipation of Change
 Basis of Evolvability and Reusability
 Requires Automated Support (SCCS, etc.)
 Impacts Software Production Process
Can Future Products be Predicted?
Is Planning Cycle 5 or More Years?
SW&OO-1.52
Generality

CSE300




For a Given Problem, Look for a General Problem
and Solve
 Supermarket System vs. Inventory Control
 Hospital Application vs. Health Care Product
Adapt General Solution to Specific Problem
 Inventory Control for Supermarket, Auto Parts,
Video Tape Rental, etc.
 Health Care Product for Hospital, MD Office,
Dental Office, etc.
Domain-and-Organization Specific Reuse
What Products will be Developed in Future?
Leverage Additional Short-Term Effort with LongTerm Gains w.r.t. Maintenance, Reuse, …
SW&OO-1.53
Incrementality

CSE300



Products are Built in Increments
 Quicker to Market
 Focused, Less Errors in Smaller Increments
 Phased Prototypes with Increasing Functions
Difficulty in Constructing Solutions to Complex
Computing Problems
 Utilize Rapid Prototyping to Discern
Requirements from Users
 Allow Designers/Developers to Learn Domain
An Engineering Approach to Problem Solving
Incrementality Ideal Companion to OO Paradigm
 Add Classes for Successive Prototypes
 Include New Functionality in Existing Classes
SW&OO-1.54
Principles and OO Paradigm

CSE300 




Separation of Concerns
 Define Classes at Different Abstraction Levels
Modularity
 Classes are Components of Solution
Abstraction
 Public Interface and Private Implementation
Anticipation of Change
 Design Classes for Change
Generality
 Generics and Solving General Problems
Incrementality
 New and Expanded Classes over Time
SW&OO-1.55
Object-Oriented Concepts

CSE300


Background and Motivation
 Transitional Design & Silver Bullet (Brooks)
 Law of Demeter/Responsibility-Driven Design
Object-Oriented Design Issues
 The High-Tech Supermarket System (HTSS)
 Choosing Objects and Classes
 Inheritance and Overloading
 Polymorphism/Dynamic Binding
 Generic: A Type Parameterizable Class
“Software Design,” Demurjian, Chapter 108, The
Computer Science & Engineering Handbook,
Tucker (ed.), CRC Press, 1997.
SW&OO-1.56
Abstraction and Complexity

CSE300 


As Software has Become more Complex, it
Requires more Software Engineers
F. Brooks - Mythical Man Month - 1970s
 Work done in 2 months by 1 Software Engineer
> Work done in 1 month by 2 SEs!
 “Adding Software Engineers to a Late Project
will only Make it Later!” WHY?
Interconnectedness: Interdependencies in Code
 Individual Portions can’t be Written in
Isolation
 Information Exchange Needed Between SEs
Complexity Historically Controlled by Abstracting
Away Less Important Details
SW&OO-1.57
History of Abstraction
Procedures and Modules

CSE300

Procedures
 The “First” Abstraction Mechanism
 Repeated Execution of Same Code without
Duplication
 Inefficient at Information Hiding
Modules: Managing Name Spaces
 Public: Portion Accessible Outside Module
 Private: Portion Accessible Inside Module
 Users can Only “See” Information Needed to
Utilize Module
 SE can Only “See” Information Needed to
Code Module
 Supports Information Hiding
SW&OO-1.58
Abstract Data Types (ADTs)


CSE300



Proposed by B. Liskov (MIT) for CLU in 1975
ADTs Promote Application Development From
Perspective of Information and its Usage
ADT Design Process:
 Identify “Kinds” or “Types” of Information
 Encapsulate Information and Provide a
Public Interface of Methods
 Hide Information and Method Code in the
Private Implementation
ADTs Correspond to User-Defined Data Types
Analogous to Integer Data Type and +, -, *, etc.
SW&OO-1.59
Abstract Data Types (ADTs)

Consider the following Example Stack ADT:
Public
Interface
CSE300
Private Implementation
Head: Int;
ST: Array[100] of Int;
User
PUSH
POP
TOP
EMPTY
Designer
Push(X Int)
…
End;
Int Pop()
…
End;
PUSH
5
10
15
20
20 15
10
5
ST
5
TOP
20
15
10
5
SW&OO-1.60
ADT Design Guidelines

CSE300 



Separation of Concerns and Modularity
 Problem Decomposable into Components
Abstraction and Representation Independence
 Hiding Implementation of Components
 Changing without Impacting External View
Incrementality and Anticipation of Change
 Components are Changed, Added, Refined,
etc., as Needed to Support Evolving
Requirements
Cohesion: Well-Defined Component Performs a
Single Task or has a Single Objective
Coupling: Component Interactions are Known and
Minimal
SW&OO-1.61
Object-Oriented Paradigm

CSE300


Object-Oriented Decomposition
 Decompose Problem into Agents which
Perform Operations
 Emphasize Agents that Cause Actions
Agents Comprised of Two Parts
 Hidden Implementation: Data and Operations
only Available to Agent
 Public Interface: Operations Available to
Clients of Agent
An Agent Can Only be Modified by Operations
Defined in either the Hidden Implementation or
Public Interface
SW&OO-1.62
Core Object-Oriented Concepts

CSE300



Class
 The Type of an Agent
 Describes the Behavior
Object
 The Instance of a Class
 Represents Actual Data Manipulated by Agents
 Maintains the State of Object
Method
 Operation Defined on a Class
 Operates on ALL Instances of the Class
Message
 Indicates that an Object’s Method Invoked
SW&OO-1.63
An Example Employee Class
CSE300
Class Employee
{
//Hidden Implementation
Private: //Instance Vars
char[30] name;
float
salary;
//Public Interface
Public:
void print_name();
void print_salary();
void update_salary(float i);
Employee(char *n, float s);
}
What’s Output of Main()?
Steve
100.0
Lois
130.0
Main()
{
//Declare Objects
Employee emp1(Steve,100.0);
Employee emp2(Lois, 120.0);
//Pass Messages
//Invoke Methods
emp1.print_name();
emp1.print_salary();
emp2.update_salary(10);
emp2.print_name();
emp2.print_salary();
}
Conclusion:
Each Object (emp1,emp2) has
Own Independent State that
is Accessible via Shared
Public Interface of Class
SW&OO-1.64
Modules vs. ADTs/Classes

CSE300


Module
 Describes Both State and Behavior
 Module Employee Includes Instance Variables,
Operations, and Program Variables
 Single Instance Shared by All Users
Class
 Describes Only the Behavior
 Class Employee Omits Program Variables
 Multiple Independent Instances Share Same
Class Declaration but have Separate States
Key Difference: Dynamic Nature of Classes
Allows Instances to be Created as Needed
SW&OO-1.65
Concepts of Transitional Design

CSE300 


What Does Customer Want?
What Does Designer Need?
Comprehensive Object-Oriented Design Must:
 Characterize Classes and Inheritance
 Understand Relationships Among Classes
 Design for Today and Tomorrow
 Talk to Customer!
KEY: Define the Problem and Understand its
Domain and Scope
SW&OO-1.66
Transitional Design - Practice


CSE300


Focus on Encapsulation, Hiding, and Inheritance
Emphasize a Behavioral Perspective:
 What's Encapsulated/Hidden?
 Actions/Responsibilities are Key!
 Interdependencies are Critical!
While Encapsulation and Hiding Typically Imply
an Independence Among “Classes” (other than
Inheritance), Our Claim is that Such a View is
Artificial and Unrealistic!
Represent “World” as it Occurs, Not as we
Would Like it to Occur!
SW&OO-1.67
Thoughts From Fred Brooks


CSE300


“No Silver Bullet”, IEEE Computer, Apr. 1987
Common Motivation:
 “Hardest Part is Deciding What to Build”
 “Most Important Functions is Iterative
Extraction and Refinement of the Product
Requirements”
 “Impossible - Completeness, Preciseness,
Correctness”
Focus on the Identification, Cultivation,
Recognition and Reward of “Great Designers”
“Biting the Silver Bullet”, D. Harel, IEEE
Computer, Jan. 1992
SW&OO-1.68
Law of Demeter
(Leiberherr, Northeastern University)

CSE300 




Stress Encapsulation by Reducing
Interdependencies Between Classes (Objects)
High Cohesion and No Coupling
A Class Cannot Directly Manipulate (via Method)
Internal Representation of Another Class
Classes Developed and Analyzed Independently
Focus on Method Access and Message Sending
 Only Objects in Parameter List of Methods
 Instance Variables of Class but NOT
Superclasses
 Global and Temporary Variables
See Budd, Section 17.1.3, pg. 306.
SW&OO-1.69
Responsibility-Driven Design
(Wirfs-Brock & Wilkerson, OOPSLA89)

CSE300




Approach Emphasizes Responsibilities:
 “What actions is this object responsible for?”
 “What information does this object share?”
Three Perspective Client Model:
 External Clients
 Subclass Clients
 Self Client
Focus on Actions and Behavior
Interactions Inevitable!
Key: Define Required Interactions
SW&OO-1.70
Objects vs. ADTs

CSE300

Objects Extend ADTs as follows:
 Message Passing: Object Activation by a
Request (Method Call) to Perform an Action
 Inheritance: Sharing of Code Among Objects
 Polymorphism: Shared Code Behaves
Differently Based on Object and Context
ADT/OO Benefits:
 Support Creation of Reusable Software
Components
 Creation and Testing in Isolation!
 SEs View Problem at Higher-Level of
Abstraction
SW&OO-1.71
Choosing Objects and Classes

CSE300 

The ‘First’ and Most ‘Often’ Concern for
Newcomers to OO Concepts
Typical Answers:
 High Cohesion, Low Coupling, Encapsulation
 Law of Demeter, Responsibility-Driven Design
 Comes with Experience and Time
Better Answer:
 Choosing Objects/Classes Not a First Step
 Can't Jump to High-Level/Detailed Design
 Choice Guided by Specification - Contains
Intent and Requirements
 DFDs, ERs, Interfaces, User Interactions, etc.
SW&OO-1.72
Choosing Objects for BlackJack

Consider ‘Naïve’Abstraction:
Deck
+---------+
| Shuffle |
| Deal
|
| Hit
|
| ...
|
+---------+
CSE300


Hand
+-------+
| Play |
| Hit
|
| Stand |
| ...
|
+-------+
Game
+-------------------+
| +----+ +----+
|
| |Hand| |Hand| ... |
| +----+ +----+
|
| Operations?
|
+-------------------+
What's Been Ignored?
 Multiple Decks of Cards?
 Modeling of Deck - Suits/Cards?
 Strategy for House?
Moral: Objects/Classes are Not a Panacea for
Comprehensive, Up-Front, Problem Exploration
via a Detailed Specification
SW&OO-1.73
Object-Oriented Design Issues

CSE300




The High-Tech Supermarket System (HTSS)
 Description of Capabilities
 Modules and ADTs for HTSS
Responsibility Driven Design via CRC Cards
 Class Responsibilities Collaborators
 Select Examples to Demonstrate Technique
Categories of Classes
CRC Methodological Issues
Common Design Flaws
SW&OO-1.74
High-Tech Supermarket System (HTSS)

CSE300


Automate the Functions and Actions
 Cashiers and Inventory Updates
 User Friendly Grocery Item Locator
 Fast-Track Deli Orderer
 Inventory Control
User System Interfaces
 Cash Register/UPC Scanner
 GUI for Inventory Control
 Shopper Interfaces Locator and Orderer
 Deli Interface for Deli Workers
We’ll Introduce and Utilize Throughout Course
SW&OO-1.75
The HTSS Software Architecture
IL
CSE300
IL
IL
SDO
EDO
SDO
EDO
Payment
CR
CR
CR
CR
IL:
CR:
IC:
DO:
Item Locator
Cash Register
Invent. Control
Deli Orderer for
Shopper/Employee
Item
IC
Order
IC
Non-Local
Client Int.
CreditCardDB
Inventory
Control
ItemDB
Global
Server
ItemDB
Local
Server
ATM-BanKDB
OrderDB
SupplierDB
SW&OO-1.76
Programming with Modules

CSE300

Modular Design and Development Contains:
 Identification of Major System Tasks
 Each Task Contains Dedicated Set of Data and
Imports Data/Functions from Other Modules
 Each Task Contains a Set of Procedures and/or
Functions to Accomplish Task
 Each Task Exports Subset of Information,
Procedures, and/or Functions to “World”
Versatility in Design Approach:
 Functional Modules for: Cashier, Scanner,
Locator, Orderer, Inventory Controller, etc.
 Informational Modules for Item, DeliItem,
Receipt, Credit/Check.
SW&OO-1.77
Modules in HTSS
CSE300
MODULE Cashier;
IMPORT Get_Item(UPC),
Get_Credit_Info(AcctNum),
Get_Deli_Item(UPC), ...;
EXPORT Display_SubTot(),
Display_Total(),
Generate_Receipt(), ...;
MODULE Scanner;
...
END Scanner;
{code for internal data and for
procedures and functions}
END Cashier;
MODULE Orderer;
...
END Orderer;
MODULE Items;
IMPORT {various I/O routines};
EXPORT Get_Item(UPC),
New_Item(UPC, Name, ...),
Modify_Item(UPC, Integer),
Delete_Item(UPC), ...;
anItem = RECORD
UPC : INTEGER; NAME: STRING;
SIZE: REAL; ...
END;
END Items;
MODULE DeliItems;
...
END DeliItems;
MODULE Locator;
...
END Locator;
MODULE CreditCheck;
...
END CreditCheck;
SW&OO-1.78
Advantages/Drawbacks of Modules

CSE300




Import/Export:
 Concept Similar to Public Interface
 Promotes Controlled Sharing
 Provides Hiding
 Facilitates Concurrent Engineering
Strong Parallels to ADTs
No Concept of “Instances”
But, Still Emphasizes Functional Solution
Like OO/ADT, Supports Representation
Independence
SW&OO-1.79
Programming with ADTs

CSE300


ADTs Promote Applications Development From
Perspective of Information and Its Usage
ADT Design Process and Steps:
 Identify Major “Kinds/Types” of Information
 Describe Purpose Each Kind or Type
 Encapsulate Information
 Define and Characterize Methods
Process Iterates/Cycles from Bottom Up
 Focus on Lowest Level of Info. - Build ADTs
 Next Level of ADTs Use Lowest Level
 Next Level Combines most Recent Levels
 Repeat to Achieve Desired System level
SW&OO-1.80
ADTs in HTSS
CSE300
ADT Item;
PRIVATE DATA: SET OF Item(s), Each Item Contains:
UPC, Name, WCost, RCost, OnShelf,
InStock, Location, ROLimit;
PTR TO Current_Item;
PUBLIC OPS: Create_New_Item(UPC, ...) : RETURN Status;
Get_Item_NameCost(UPC) : RETURNS (STRING, REAL);
Modify_Inventory(UPC, Delta) ;
Get_InStock_Amt(UPC) : RETURN INTEGER;
Get_OnShelf_Amt(UPC) : RETURN INTEGER;
Check_If_On_Shelf(UPC): RETURN BOOLEAN;
Time_To_Reorder(UPC): RETURN BOOLEAN;
Get_Item_Profit(UPC): RETURN REAL;
...
{notes: - OPS span the entire application
- not limited to a single, functional component}
END Item;
ADT DeliItem;
ADT CustomerInfo;
PRIVATE DATA: SET OF (Item, Weight,
...
CostLb, Increm);
END CustomerInfo;
...
END DeliItem;
SW&OO-1.81
ADTs in HTSS
ADT Process_Order; {middle-level ADT}
PRIVATE DATA: {local variables to process an order}
PUBLIC OPS : {what do you think are appropriate?}
CSE300
{this ADT uses the ADT/PUBLIC OPS from Item, Deli_Item,
Receipt, Coupons, and Customer_Info to process and total
an Order.}
END Process_Order;
ADT Sales_Info; {middle-level ADT}
PRIVATE DATA: {local variables to collate sales information}
PUBLIC OPS : {what do you think are appropriate?}
{this ADT uses the ADT/PUBLIC OPS from Receipt so that
the sales information for the store can be maintained.}
END Sales_Info;
ADT Cashier; {high-level ADT}
{this ADT uses the ADT/PUBLIC OPS from the middle-level
ADTs (Process_Order, Sales_Info, etc.).)
END Cashier;
SW&OO-1.82
Advantages/Drawbacks of ADTs

CSE300


Advantages:
 Abstraction is Promoted and Achieved
 Concurrent Engineering is Feasible
 Reuse and Evolution are Attainable
 Emphasizes Static System Behavior
Drawbacks:
 Without Inheritance, Redundancies Likely
 Dynamic System Behavior Still Difficult
 Associations Between ADTs Difficult
 Only Inclusion Association Supported
Do Drawbacks Outweigh Advantages?
SW&OO-1.83
Responsibility-Driven Design
(Wirfs-Brock & Wilkerson, OOPSLA89)

CSE300



Approach Emphasizes Responsibilities:
 “What actions is this object responsible for?”
 “What information does this object share?”
 “What objects does this object collaborate
with?”
Focus on Actions and Behavior
Interactions Inevitable!
Key: Define Required Interactions
SW&OO-1.84
CRC Cards
Class, Responsibility, Collaborators


CSE300
Index Cards - Each Card Defines a Class
Front of Each CRC Card:
 Class - Meaningful Chunk
 Responsibilities
 Well-Chosen Prose Descriptions of Capabilities
 What Actions Does a Class Perform?

Collaborators
 Interactions with Other Classes
 Which Classes does Class Interact with?

Back of Each CRC Card:
 Data - Hidden from Users
SW&OO-1.85
A CRC Card for HTSS
Item: A Product Sold in a Supermarket.
CSE300
Create a New Item
Return an Item's UPC
Return an Item's Name
Return the Quantity of an Item
Return an Item's Reorder Amount
Check the Reorder Status of Item
Display all Info. on an Item
Display an Item's Name and Price
Display an Item's Inventory Data
Update an Item's Price
ItemDB
Hidden Data:
Name: String; UPC: String; Rcost, Wcost: Real;
Quantity, ReorderLevel: Integer; etc...
SW&OO-1.86
Another CRC Card for HTSS
ItemDB: All Item’s in Supermarket - repository.
CSE300
Insert a New Item
Delete an Existing Item
Find/Display Item Based on UPC
Find/Display Item Based on Name
Find/Display Item Based on Qty
Find/Display Item Based on Reorder
Print All Items
Find an Item in Database by UPC
Find an Item in Database by Name
Find the First Item
Find the Next Item
InvControl
Item
Hidden Data:
AllItems: Array[1..MaxItem] of Item;
CurrItem, LastItem: Integer Index; etc...
SW&OO-1.87
Flight Management Example

CSE300



Capabilities Include:
 User Requests a Number of Seats on a Certain
Flight
 System Grants Requests if Possible and Issues
Tickets, or Denies Request
 User Requests a Cancellation of a Number of
Seats on a Certain Flight
 System Grants Cancellation and Issues Refund
For Simplicity, Ignore Overbooking and Attempts
to Cancel Unbooked Flights
Using this Terse Description - Develop a Solution
We’ll Explore Alternatives Shortly
SW&OO-1.88
CRC Cards for Flight Example
One Solution
Agent: Handles Ticketing for Passengers.
CSE300
Display Transaction Menu
Wait for Transaction
Call Apropos Trans. Manager
Reserve
Cancel
Reserve: Actions for Making Reservation.
Ask Schedule if Seats Available
Ask Flight to Reserve Seats
Ask Issue to Generate Tickets
Flight
Schedule
Issue
Cancel: Actions for Canceling Reservation.
Ask Flight to Cancel Seats
Ask Issue to Generate Refund
Flight
Issue
SW&OO-1.89
CRC Cards for Flight Example
One Solution
Schedule: Flight Interactions/Ticketing.
CSE300
Get
Ask
Ask
Ask
No. Seats
Flight if
Flight to
Flight to
and Flight No.
No. Seats Available
Reserve Seats
Cancel Seats
Flight
Flight: Tracks Seat Info. for Flights.
Compare No. Seats with No. Available
Remove Seats from Free List
Return Seat No. to Schedule
Add Cancelled Seat No. to Free List
Issue: Generate Ticket or Cancellation.
Issue Ticket
Issue Refund Check
SW&OO-1.90
CRC Cards for Flight Example
Critiquing First Solution
Design Represents User Perspective
 Highlight Interactions via Collaborators

CSE300
Cancel
Agent
Reserve
Commonalties?
Differences?
Couplings?
Schedule
Flight
Issue
SW&OO-1.91
Another Solution
Combine Reserve, Cancel, and Issue
Agent: Handles Ticketing for Passengers.
CSE300
Display Transaction Menu
Wait for Transaction
Call Apropos Trans. Manager
Reserve
Cancel
Reservations: Making/Canceling Reservations.
Ask Schedule if Seats Available
Ask Flight to Reserve Seats
Ask Issue to Generate Tickets
Ask Flight to Cancel Seats
Ask Issue to Generate Refund
Issue Ticket
Issue Refund Check
Flight
Schedule
Issue
SW&OO-1.92
Yet Another Solution
Combine Schedule and Flight
Schedule: Flight Interactions/Ticketing.
CSE300
Get No. Seats and Flight No.
Ask Flight if No. Seats Available
Ask Flight to Reserve Seats
Ask Flight to Cancel Seats
Compare No. Seats with No. Available
Remove Seats from Free List
Return Seat No. to Schedule
Add Cancelled Seat No. to Free List
Flight
What was Problem with Original Design?
 What has Occurred in Redesign?
 Structuring Solution from Perspective of
Arrival/Departure of Flights Would Likely
Yield Different Set of Classes!!

SW&OO-1.93
CRC Cards for Health Care
Patient: Individual that sees a Physician.
CSE300
Return Personal Information
Request Physician Appointment
Describe Symptoms
Accept Treatment
Pay Bills
Medical_R
Financial_R
Prescript_R
Medical_R: Contains all Medical Info on Patient.
Set/Get Patient Background
Insert/Get Visit
Insert/Get Test
Append Medical History
Get Medical History
Insert/Get Exam
Get All Medications
Patient
Prescription
Visit
Test
Pat_Display
SW&OO-1.94
Categories of Classes
(See Budd, Section 3.2, pg. 48)

CSE300
Data Managers - Maintain Data/State Information
 Contains Functionality for Application
class Item {
private: // Private Data
int
UPC;
char* Name;
int
InStock, OnShelf, ROLimit;
float RetailCost;
public: // Public Methods
Item(int code, char* str, int st1,
int st2, int st3, float cost);
void
CreateNewItem();
int
GetUPC();
char* GetName();
int
GetQuantity();
int
CheckReorderStatus();
void
PrintItem();
void
UpdatePrice(float new_value);
};
SW&OO-1.95
Categories of Classes
(See Budd, Section 3.2, pg. 48)

CSE300
Data Sinks/Data Sources - Produce/Process Data
 Generated on Demand or Maintained
class ItemDB
{private:
int
Num_Items;
int
Curr_Item;
Item* AllItems[Max_Items];
int
int
int
int
public:
void
void
void
void
void
FindFirstItem();
FindNextItem();
FindItemUPC(int code);
FindItemName(char* name);
ItemDB(); // Constructor
InsertNewItem(Item* new_one);
DeleteExistingItem(int code);
FindDisplayItemUPC(int code);
FindDisplayItemName(char* name);
PrintAllItems();
};
SW&OO-1.96
Categories of Classes

Data Manager Class
Item Class Contains the
State of a Single Object
CSE300
Item I1, I2, I3;

Data Source/Sink Class
ItemDB is a Collection
or Set of Items
Item
ItemDB[100];
I1
“milk”
I2
“peas”
I3
“soda”
ItemDB
SW&OO-1.97
Categories of Classes
(See Budd, Section 3.2, pg. 48)

CSE300
View/Observer - Provide an Interface for User
 Often Collects Information via Public Interface
of Multiple Classes
 InvControlGUI Utilizes Item, ItemDB, etc.
class InvControlGUI
{ private:
int
Curr_Option; // Current menu option
public:
InvControl(); // Constructor
void
PrintMenuSetOption();
void
ActivateController();
void
EnterNewItem();
void
RemoveExistingItem();
void
FindItem();
void
InvSearchQuantity();
void
InvSearchReorder();
void
GenerateAnOrder();
};
SW&OO-1.98
Categories of Classes
(See Budd, Section 3.2, pg. 48)

CSE300

Facilitator/Helper - Used to Support Complex
Tasks
 E.g., GUI Libs, Strings, I/O Handler, etc.
For HTSS, Facilitator/Helpers as Follows:
 GUI Classes to Display Windows, Menu
Options, Dialog Boxes, etc., for HTSS GUIs
 Linked List or Collection Classes to Allow
Data to be Stored in ItemDB
 Is UPC Scanner a Facilitator/Helper Class?
SW&OO-1.99
Responsibility-Driven Design
Methodological Issues


CSE300


Utilize CRC/RDD Over Time to Grow Design
Begin by Identifying Classes Vital to Application
Simulate Scenarios of Expected Operation
 Identify New Classes
 Assign/Revise Responsibilities to Classes
 CRC Cards Demonstrate Flow of Control
Experimental Approach to Design - Advantages
 Group Approach to Problem Solving
 Communication between Team Members
 Alternative Design Evaluation
 Completeness of Design
 High-Level yet Means for Details
SW&OO-1.100
Early Stage of CRC Design
CSE300
Class A
Class B
Class D
Class C
Class E
Class A
D
Class C
D
E
Class F
SW&OO-1.101
Responsibility-Driven Design
Methodological Issues

CSE300

From First/Initial Attempts, CRC Cards are
Evolved Towards “Complete” Design
 Addition of New Classes
 Expand with New Responsibilities
 Fine Tune Collaborators
 Add/Refine “Hidden” Data
 Combine “Small/Similar” Classes
 Split “Large/Poorly Abstracted” Classes
As Time Goes on, Include
 Inheritance: One Class is a Specialization of
Another Class
 Aggregation: One Class is a Component of
Another Class
SW&OO-1.102
Later Stage of CRC Design
Class A
D
CSE300
Class C
D
E
Class F
Class A
Resp 1
Resp 2
Resp 3
Class B
D
Resp
Resp
Resp
Resp
Class C
1
2
3
4
Resp 1
Resp 2
Class D
Class E
Int X, Y;
Char Z;
Real M, N;
String S;
D
E
SW&OO-1.103
Common Design Flaws

CSE300

Classes that Directly Modify the Private Data of
Other Classes
 Provide Operations in Public Interface
 Only Change via Operations
 Asking Class to Change Itself
Recall Item from HTSS
class Item {
private: // Private Data
float RetailCost;
public: // Public Methods
void
UpdatePrice(float new_value);
};
Only Change RetailCost via UpdatePrice()
Do not Access RetailCost Directly from Cashier
SW&OO-1.104
Common Design Flaws

CSE300
Too Much Functionality in One Class
 Class Grows Over Time - Not Cohesive
 Split a Class into Two or More Classes
class Item
{ protected: // Attributes as given in earlier examples
public:
// Two constructors for versatility
virtual
virtual
virtual
virtual
virtual
virtual
int
char*
int
int
int
int
float
float
GetUPC();
GetName();
GetInstockAmt();
GetOnShelfAmt();
GetQuantity();
GetReorderAmt();
GetRetailPrice();
GetWholeSaleCost();
void
void
void
void
void
void
UpdateName(char* item_name);
UpdateInstockAmt(int stock_amt);
UpdateOnShelfAmt(int shelf_amt);
UpdateReorderAmt(int reord_amt);
UpdateRetailPrice(float price);
UpdateWholeSaleCost(float wholesale);
void
void
void
void
void
char*
void
void
void
void
void
void
void
void
CreateNewItem();
PrintItem();
PrintPerish();
UpdateItemMenu();
UpdateItem(int portion);
ReturnType();
PrintUPCName();
PrintNamePrice();
PrintInventory();
PrintProfitInfo();
PrintUPC();
PrintName();
PrintInstockAmt();
PrintOnShelfAmt();
}
SW&OO-1.105
Common Design Flaws

CSE300


A Class that Lacks Functionality
 Class Included at Early Design Stage
 Merge Two or More Classes Impact on
Inheritance Hierarchies?
Classes that Have Unused Functionality
 Eliminate Unused Functions and Reevaluate
Their Necessity
Classes that Duplicate Functionality
 Combine with Existing Class
 Add Non-Duplicate Functionality
SW&OO-1.106
Advanced Object-Oriented Concepts

CSE300


Inheritance
 Controlled Sharing of Between Classes
Generalization and Specialization
 Treat Instances of Different Classes in Uniform
Fashion - Leading to …
Polymorphism/Dynamic Binding
 Run-Time Choice of the Method to be Invoked
Based on the Type of the Calling Instance
 Message Passed is Type Dependent
Generic: A Type Parameterizable Class
 Stack has Parameter for Type of Element
 Creation of Program Variable Binds Stack Data
and Methods to Specific Type of Element
 Stack(Real), Stack(Int), Stack(Employee)
SW&OO-1.107
Motivating Inheritance Concepts

CSE300 
Consider a University Application
Four Classes Have Been Identified
Faculty
Name
SSN
Rank
Dept
Yrs

Dean
Name
SSN
School
Dept
Yrs
UnderGrad
Name
SSN
Dorm
Year
GPA
Grad
Name
SSN
Dorm
Program
Degree
GPA
To Successfully Utilize Inheritance
 Distinguish Differences (Specialization)
 Identify Commonalties (Generalization)
SW&OO-1.108
Motivating Inheritance

One Solution:
Person
Name
SSN
CSE300
Faculty:Person
Rank
Dept
Yrs
UnderGrad:Person
Dorm
Year
GPA

Dean:Person
School
Dept
Yrs
Grad:Person
Dorm
Program
Degree
GPA
Pictorially:
Person
Faculty

Dean
UnderGrad
Grad
Is this Solution Adequate?
SW&OO-1.109
Motivating Inheritance

A Better Solution:
Person
Name
SSN
CSE300
Employee
Dept
Yrs
Faculty
Rank



Dean
School
Student
Dorm
GPA
UnderGrad
Year
Grad
Program
Degree
Solution Utilizes Single Inheritance
Exactly One Parent for Each Class
Are we Done?
SW&OO-1.110
Motivating Inheritance

Revising Example:
Person
Name
SSN
CSE300
Employee
Dept
Yrs
Faculty
Rank



Dean
School
Student
Dorm
GPA
UnderGrad
Year
Grad
Program
Degree
Superclass, Supertype, Parent, Base Class
Subclass, Subtype, Child, Derived Class
Descendants, Ancestors, Siblings
SW&OO-1.111
Defining Inheritance

CSE300




Subclass Acquires Information and/or
Operations of a Superclass
Inheritance is a Transitive Operation
Behavior and Information of a Subclass is a
Superset of its Ancestors
Subclass is More Refined than Superclass - its
Specialized
Superclass contains Common Characteristics of
its Subclasses - its Generalized
SW&OO-1.112
Defining Inheritance

CSE300



Inheritance is Utilized when Two or More Classes
are Functionally and/or Informationally Related
In University Example, Common Data Basis of
Inheritance Decision
Other Bases for Inheritance could be:
 Common Methods
 Common Data and Methods
Reuse Occurs from both Informational and
Functional Perspective
 Information - No Replicated Variables
 Function - No Replicated Code
SW&OO-1.113
The Role of Inheritance

CSE300


Develop Inheritance Hierarchies that are
 Extensible
 Reusable
 Evolvable
In Budd, Chapter 7, Excellent Discussion on
 Utilization of Inheritance: How
 Benefits of Inheritance: Why
 Impact of Inheritance: Cost
We’ll Review this Material
SW&OO-1.114
Specialization and Generalization
Inheritance

CSE300

Specialization
 Most Common form of Inheritance to Refine
the Behavior of the SuperClass
 Differences are Pushed Down Hierarchy
 Allows Designers to Customize Classes
Generalization
 Inverse of Specialization
 Commonalities of Multiple Classes are
Abstracted out to Form a SuperClass
SW&OO-1.115
Examples from HTSS
Specialization and Generalization
Item
Generalization
/
\
/
\
NonPItem
PerishItem
/ \
\
/
\
\
DeliItem DairyItem ProduceItem
Specialization
CSE300
class PItem : public Item
{ protected:
food_state Environ;
int
Days;
void
ItemSpecificPrint();
public:
virtual void CreateNewItem();
virtual void PrintItem();
virtual void PrintPerish();
virtual void UpdateItem();
void
PrintDaysFoodState();
};
class DeliItem : public PItem
{protected:
float
Weight;
float
CostPerLb;
void
ItemSpecificPrint();
public:
virtual void CreateNewItem();
virtual void PrintItem();
virtual void PrintPerish();
virtual void UpdateItem();
void
PrintWeightandCost();
};
SW&OO-1.116
Specification Inheritance & Example

CSE300
Specification
 Classes Share Common Interface (Superclass)
 Specification Class: An Abstract Interface
Similar to Java’s Interface
 Designers Construct Unified Interface that is
Sharable by Multiple Team Members
Data-Oriented
Function-Oriented
GraphicalObject
/ \
\
/
\
\
Ball
Wall Hole
Menu
/
\
/
\
PrintMenu SaveMenu
SW&OO-1.117
Construction Inheritance & Example

CSE300
Construction
 Subclass Inherits Majority of Functionality
from its Superclass
 Subclass may Extend, Limit, or Vary the
Functionality of Superclass
Dictionary
/
\
/
\
SymbolTable HashTable
LinkedList
/ \
\
/
\
\
Queue
Set Stack
SW&OO-1.118
Variance Inheritance & Example

CSE300
Variance
 Classes have Similar Implementations but
Unrelated Abstract Views
 Result May Not Directly Aid Designer
PointingDevice
/
\
\
/
\
\
TouchPad
Mouse Tablet
Key Issues
• Share Common Abstraction
• Different Implementations
• Methods in TouchPad,
Mouse, etc., Override
Methods in PointingDevice
SW&OO-1.119
Combination Inheritance & Example

CSE300
Combination
 Use of Multiple Inheritance Combines Two
or More Parents
 Allows Designers to View Design from
Different Perspectives
Faculty
Student
\
/
\
/
TeachingAsst
MeatItem
ProduceItem
\
/
\
/
DelItem
SW&OO-1.120
Extension Inheritance & Example

CSE300
Extension
 New Abilities are Added to Subclass
 Allows Designers to Reuse Prior Designs
 Requires Method(s) of Superclass to be
Overridden
Window
/
\
/
\
FixedColorW
VarColorW
|
Key Issues
BWWindow
• Going from 1 to 2 Colors
FixedColorW - BWWindow
• Expanding Capabilities
SW&OO-1.121
Limitation Inheritance & Example

CSE300
Limitation
 Subclass has more Restricted Behavior
 Typically to Extend Existing Class Library
 Inverse of Extension
 Also Supports Design Reuse
DEQueue
/
\
/
\
Queue
Stack
/ \
LIFO FIFO
Key Issues
• Going from Two-Direction
Queue to Ltd. Abstractions
• Limiting Functionality
SW&OO-1.122
Benefits of Inheritance

CSE300

Software Reusability
 Inherited Characteristics Often Represents
Compiled and Tested Code/Behavior
 Reuse in Future Products
 Design and Program Families
Design and Code Sharing
 Two or More Subclasses of the Same
Superclass Share Code
 Redundancy is Reduced
 Reliability/Testing Enhanced
 Inherit from Existing Subclass that has been
Utilized and Exercised
SW&OO-1.123
Benefits of Inheritance

CSE300


Software Components
 Promotes the Concept of Reusable
Components and Software Factory
 Combine Rather than Construct
 JavaBeans and APIs, Ada95 Packages, etc.
Rapid Prototyping
 Utilization of Reusable Components
 Incremental Design and Development
 Delivery of Multiple Prototypes
 Faster to Market
All Benefits Apply to Design, Development, and
Maintenance!
SW&OO-1.124
The Cost of Inheritance

CSE300


Execution Speed
 Compile-Time Overhead Due to Inheritance
 Many Decisions Related to Inheritance Must
Occur at Runtime
 We’ll Explore this Shortly
Program Size
 Libraries are Large, and if Only Static Linking,
Size Grows
 Good News: Dynamic Linking Techniques are
Improving
 Improve Runtime Environment
Platform Independence (Java) Impacts both
Speed and Size
SW&OO-1.125
The Cost of Inheritance

CSE300

Message Passing Overhead
 An Overuse of Messages is akin to an Overuse
of Procedures/Functions in C or Pascal
 Messages that Pass Arrays Increase Overhead
 To Find “Correct” Method, Must Search
Object, Parent, Grandparent, etc.
 Remote Messages for Distributed Object
Computing (CORBA, Java RMI)
Program Complexity
 For Any New Paradigm, Software Engineers
Must Acquire Appropriate Skills
 Despite HW Increases, Software Size and
Complexity Continues to Grow!
SW&OO-1.126
Overloading

CSE300
The Ability to Define Two or More Methods with
the Same Names and Different Signatures
 A Feature of Programming Language
 Available in OO and Non-OO Languages
 Present in Current Languages, e.g., ‘+’ Means
 Integer Addition
 Real Addition
 Set Union (Pascal)

OO Design and Programming Allows us to Define
our own Types (Classes)
 Overload Operations (+, -, *, ++, etc.)
 Overload Methods
SW&OO-1.127
Overloading in a Stack Example
CSE300
class stack {
private:
char* st, top;
int
size;
public:
void stack(int x) {top = st = new char[x]; size = x;}
void stack() {top = st = new char[100]; size = 100;}
// push, pop, top, etc., Omitted
};
main()
{
stack S1(10); //
stack S2;
//
//
//
}
S1
20
15
10
Creates a char Stack with 10 Slots
Default, no Parameter Supplied
Creates a char Stack with 100 Slots
Size of S2 Might not be Known to User!
5
S2
20
15
10
5
… etc ...
SW&OO-1.128
Overloading in HTS
CSE300
class Item {
private:
int
UPC, OnShelf, InStock, ROLimit;
// Etc... As Previously Given
public:
Item(); // The Constructor
// Etc... Others as Previously Given
Item
operator--(){ this->OnShelf--;
this->InStock--; }
};
main()
{
Item I1;
Status s;
s = I1.Create_New_Item(123, OJ, 10, 30, ...);
I1--; // Reduces I1.OnShelf and I1.InStock
// Now Contain 9 and 29 Respectively
}
SW&OO-1.129
Important Implementation Concepts

CSE300
Message Passing
 Method is a Member Function
 Message Passing: Invoking a Method




receiverObject.MemberFunctionName(
Automatic Variables
 Created within Function/Released at End
 Stack-Based Allocation
 No User Control/Intrevention
Dynamic Variables
 Created on Demand by Explicit Invocation
 Heap-Based Allocation
 May Require Memory Management
Why are A/D Variables Important to Design?
SW&OO-1.130
Important Implementation Concepts

CSE300




Lifetime: Execution Period that Space Must
Remain Allocated to Variable
Scope: Portion of Program in Which Variable May
Appear and be Utilized
Immutable Values: Assigned Once, Can’t Change
 Constants Known at Compile Time
 Immutable Values Set at Runtime (UPC Code)
Typing of Variables
 Static (Compile): C++, Java, Ada95
 Dynamic (Runtime): Smalltalk, Lisp, …
Strongly-Type Languages (Ada95 and Java)
 Language Does Not Allow Variable of One
Type to hold Value of Different Type
SW&OO-1.131
Important Implementation Concepts

CSE300


Static Binding: Method Bound to Message Based
on Characteristics of Variable
 SE Must Track Type of Object
 Method Looked-Up at Compile Time
 Compile Detects Inappropriate Method Calls
Dynamic Binding: Method Bound to Message
Based on Characteristics of Value (Object)
 Runtime Search for Type of Object When
Message is Passed (Method is Invoked)
 May Yield Runtime Error
 May Find/Execute “Inappropriate” Method
Late Binding: Matching Message Invoked to
Correct Method at Runtime
SW&OO-1.132
Remaining Object-Oriented Concepts

CSE300


Polymorphism
 Definition and Illustration
 Attainment and Benefits
Generics
 Type-Parameterizable Classes
 Examples using C++
Concepts that Impact Design and Development
 Substitutability
 Mutability
 Specialization via Constraints
 Material from “Fundamentals of ObjectOriented Databases”, pgs. 1-34, Zdonik/Maier.
SW&OO-1.133
Defining Polymorphism

CSE300
Polymorphism is the Ability of a Variable to
Hold more than One Type of Value, e.g.,
Subtypes of a Common Parent
Variables P: Person;
F: Faculty;
S: Student;
P
F
S
//Supertype can Hold Instance of
//Subtype, but NOT REVERSE!
P = F;
P = S;
// Treat Faculty as Person
// Treat Student as Person
SW&OO-1.134
Definition of Polymorphism/Dispatching

CSE300



Polymorphism via Dispatching Allows a Runtime
or Dynamic Choice of the Method to be Called
based on the Class Type of the Invoking Instance
Concept is only Useful in the Context of
Inheritance
Benefits of Polymorphism/Dispatching:
 Offers More Versatility in Hierarchy and Code
Development
 Promotes Reuse and Evolution of Code
 Makes Code More Generic and Easier to
Develop and Debug
Polymorphism/Dispatching Incurs Cost or
Overhead at both Compile and Runtime!
SW&OO-1.135
Illustrating Polymorphism/Dispatching

Consider Previous Example
Person
Name
SSN
CSE300
Employee
Dept
Yrs
Faculty
Rank


Dean
School
Student
Dorm
GPA
UnderGrad
Year
Grad
Program
Degree
Define Print_Info Method for Each Class
Can Correct Print_Info Method be Called
Automatically Based on Type of Instance
Variable?
SW&OO-1.136
Illustrating Polymorphism/Dispatching
P
CSE300
Person Object Repository
E
F
Steve
“Faculty”
S
D
U
G
Lois
“Graduate”
Ed
“Faculty”
Tom
Mary
“Dean”
“UnderGrad”
What’s True
About Each
Person?
SW&OO-1.137
Illustrating Polymorphism/Dispatching

CSE300
Print_Info Methods Defined as Follows:
Person::Print_Info()
{Prints Name and SSN}
Employee::Print_Info()
{Calls Person::Print_Info();
Prints Dept and Yrs; }
Student::Print_Info()
{Calls Person::Print_Info();
Prints Dorm and GPA; }
Faculty::Print_Info()
{Calls Employee::Print_Info();
Prints Rank; }
Print_Info Also for Dean, UnderGrad, Grad
SW&OO-1.138
Illustrating Polymorphism/Dispatching

Person Object Repository
CSE300

Steve
“Faculty”
Lois

“Graduate”
Ed
Tom
“Faculty”
“UnderGrad”
Mary
“Dean”

Suppose Iterate Through
Instances of Person
Repository
For Each Instance, Call
Method Print_Info()
How Does One
Determine the “Correct”
Method to Call?
What are the
 Compile Time
Checks?
 Compile Time
Guarantee?
 Runtime Checks?
SW&OO-1.139
Achieving Polymorphism/Dispatching

CSE300

Build a Mixed List of Instances of Differing
Types that Share a Common Ancestor
To Begin, Declare Variables:
FA1 = Faculty(Steve, 111, CSE, 7, AssocP);
UG1 = UnderGrad(Rich, 222, Towers, 3.5, Senior);
GR1 = Grad(Don, 333, OffCampus, 3.75, CSE, PhD);

Define a LIST Class of Persons
 LIST is a Collection Class that Allows a Set of
One or More Person Instances to be Stored
 LIST is an OO Version of Linked List
 Define LIST Methods for:
 LIST::Add_Person(Person P);
 LIST::Print_A_Member();
SW&OO-1.140
Achieving Polymorphism/Dispatching

CSE300
LIST Class has the Method Implementation
LIST::Print_A_Member()
{
Calls Print_Info();
}

Augment Variable Declarations with:
PTR
PTR
PTR
PTR
= POINTER TO CLASS FOR A LIST OF Persons;
-> LIST::Add_Person(GR1); //Add ‘Don’
-> LIST::Add_Person(UG1); //Add ‘Rich’
-> LIST::Add_Person(FA1); //Add ‘Steve’

PTR Views All List Elements as Persons

Person is Common (Root) Ancestor Shared by
All Classes in Inheritance Hierarchy!
SW&OO-1.141
Achieving Polymorphism/Dispatching

Pictorially, a LIST of Persons is Created:
+----------+
+----------+
+----------+
| Person |
| Person |
| Person |
PTR ->|
|-->|
|-->|
|
| (Really |
| (Really |
| (Really |
| Steve
|
|
Rich
|
|
Don
|
| Faculty) |
|Undergrad)|
|
Grad) |
+----------+
+----------+
+----------+
CSE300


What Happens when PTR->Print_A_Member()?
 If PTR Referencing ‘Steve’ Instance?
 If PTR Referencing ‘Rich’ Instance?
 If PTR Referencing ‘Don’ Instance?
When PTR->Print_A_Member()is Called, Recall
that the Print_Info() Method is Invoked
SW&OO-1.142
Execution/Runtime Sequence of
Polymorphism/Dispatching

CSE300 


Which Print_Info Method is Invoked?
The Runtime Environment Dynamically Chooses
the Correct Method Based on Instance Type
 When PTR References ‘Steve’/Faculty
Instance then Faculty::Print_Info()
 When PTR References ‘Rich’/UnderGrad
Instance then UnderGrad::Print_Info()
 When PTR References ‘Don’/Grad Instance
then Grad::Print_Info()
Runtime Environment will Also Check Ancestor
Instances In Order to Find the Correct Method
Correct Compilation Guarantees Method Will be
Found at Runtime!
SW&OO-1.143
Benefits of Polymorphism/Dispatching

CSE300 




Focus on Extensibility!
Easily Extend and Evolve the Class/Inheritance
Hierarchy as New Kinds of Items are Needed
Extension/Evolution Occurs without
Recompilation of Person Class Library
For Example:
class Staff : public Employee { … }
class Visitor : public Person { … }
class Transfer : public Student { … }
Previous LIST Code Works without Modification
Application that Creates Person Instances May
Need to be Modified and Recompiled
SW&OO-1.144
Generics

CSE300


Classic Programming Problem
 Develop Stack or List Code in C that Applies
to a Single Type (e.g., List of DeliItems)
 Need Same Code for ProduceItems,
MeatItems, etc., Copy and Edit Original Code
 Minimal Reuse, Error Prone, Time Consuming
What do Generics Offer?
 A Type-Parameterizable Class
 Abstracts Similar Behavior into a Common
Interface
 Reusable and Consistent Class
Illustrate via C++
SW&OO-1.145
A Generic Stack Class
template <class T> stack {
private:
T*
st,
CSE300
int
top;
int
size;
public:
void stack(int x) {st = new T[x]; top = 0; size = x;}
stack() {st = new T[100]; top = 0; size = 100;}
~stack() {delete st;}
push(T entry) { st[top++] = entry;}
};
main()
{
stack<int> S1(10); // Creates int Stack with 10 Slots
stack<char> S2; // Creates char Stack with 100 Slots
stack<Item> ItemDB(10000); // Stack of Grocery Items
}
SW&OO-1.146
A Generic Set Class
CSE300
template <class ItemType> class Set {
DLList<ItemType>* _members;
// Set Templates Uses Double-Linked List Template
public:
Set() { _members = new DLList<ItemType>(); }
void Add(ItemType* member)
{_members->queue(member);}
void Remove(ItemType* member)
{_members->remove(member);}
int Member(ItemType* member)
{return _members->isMember(member);}
int NullSet(){return _members->isEmpty();}
}
main()
{
Set<int> IntSet; // Creates an Integer Set
Set<Item> ItemDB; // Creates an Item Set
}
SW&OO-1.147
Benefits of Generics

CSE300


Strong Promotion of Reuse
 Develop Once, Use Often
 stack and Set Examples
Eliminate Errors and Inconsistencies Between
Similar and Separate Classes
 Simplifies Maintenance Problems
 Focuses on Abstraction and Design
Promotes Correctness and Consistent Program
Behavior
 Once Designed/Developed, Reused with
Consistent Results
 If Problems, Corrections in Single Location
SW&OO-1.148
Fundamentals of OO Databases
Article by Zdonik and Maier

CSE300 





An Excellent Article on the Nature and
Requirements for a Database System to be OO
Discussion from a Combined Programming and
Database View
Essential and Frequent Features - Characterize
Minimal or Typical Database Requirements
The Threshold Model Proposes a Set of Minimum
Requirements to be Characterized as OODBS
To Extend from OODBS to OODBS+PLS, Four
Critical Concepts Must beSupported
Resulting Reference Model Encompasses the
Requirements of both OODBS and OOPLS
Final Comment on Typing Issue
SW&OO-1.149
Essential and Frequent Features

CSE300

Essential Features
 Model and Language for DBS
 Associations Among DB Entities
 Permanence for Creating a Repository
 Sharing to Control Access and Consistency
 Voluminous Storage for Increasing DB Size
Frequent Features
 Integrity Constraints – Info. Consistency
 Authorization - Control Access and Visibility
 Querying - Access to Stored Information
 Separate Schema - Meta-Information
SW&OO-1.150
The Threshold Model


CSE300




Includes Essential & First Two Frequent Features
Requires Object Identity - Each Database Object
Must be Identifyableand Distinguishable
Encapsulation (as We've Discussed) and Types
(Creation of New Types via System Class Library
and User-Defined Type)
Complex State - Objects MUST be Able to Refer
to (or be Referred by) Other Objects (Promotes
Arbitrarily Complex Objects)
Inheritance (Not Included - But We Believe that
Without it, the Threshold Model Really
Characterizes Just an ADT Approach for DBS)
Have Programming Issues Been Considered?
SW&OO-1.151
Four Critical OO Concepts


CSE300 

Dispatching - We've Discussed This Extensively
Polymorphism - Type-Independent Classes
Typing Issues:
 Strong vs. Weak
 Dynamic vs. Static
 OODBS/OOPLS Offer Many Variants
Persistence – When are Instances Stored?
 Upon Creation?
 When Connected to a Persistent Object?
 When Explicitly Placed in a Persistent Store?
 When an Explicit Message is Received?
 Upon Instantiation from Persistent Store?
 Are there Other Cases for this List?
SW&OO-1.152
The Reference Model


CSE300 







Structured Representations for Objects
Persistence by Reachability
Typing of Objects and Variables
3 Hierarchies for Specification of Types,
Implementation of Data/Methods, and
Classification of Objects
Polymorphism
Collections
Name Spaces
Queries and Indexes
Relationships
Versions
SW&OO-1.153
Final Comment on Typing Issues

CSE300

Consider the Four Features of Subtyping:
 Substitutability: If B IS A, then B Can Occur
where A is Expected.
 Static-Type Checking: Everything is Known at
Compile Time
 Mutability: An Instance Changes Type at Run
Time
 Specialization via Constraints: Allows the
Further Restrictions of Instance Characteristics
via Inheritance
Claim: Only Three of Four Can Ever Exist in a
Single Model!
SW&OO-1.154
Final Comment on Typing Issues

CSE300

Consider the Four Features of Subtyping:
 Substitutability: If B IS A, then B Can Occur
where A is Expected.
 Static-Type Checking: Everything is Known at
Compile Time
 Mutability: An Instance Changes Type at Run
Time
 Specialization via Constraints: Allows the
Further Restrictions of Instance Characteristics
via Inheritance
Claim: Only Three of Four Can Ever Exist in a
Single Model!
SW&OO-1.155
Substitutability


CSE300


Recall that Employee is a Subclass of Person
Substitutability Allows Employee to be Utilized in
any Context that Person is Permitted
Implications of Substitutability
 P and E Variables of Person and Employee
 Assignment: P = E;
 Parameter Passing: If P is the type of a
Parameter, E can be Substituted in its Place
Polymorphism/Dispatching Allows
 Faculty, Grad, and UnderGrad to Substitute for
Person
 NonPItem, DeliItem, DairyItem, etc., to
Substitute for Item
SW&OO-1.156
Mutability

CSE300 

Mutability Allows an Instance to Dynamically
Change its Type within an Executing Application
Excellent Conceptual Example from CAD
 Consider Boxes and Thru-Hole
 As Thru-Hole Moves Does Its Type Change?
 Does it Become a Blind Hole?
 Does it Alter its Depth to be a Thru-Hole?
Muting a Powerful Concept that Breaks Rules
SW&OO-1.157
Other Features

CSE300

Static Type Checking – Compilation
 All Types Known
 All Decisions Made
Specialization via Constraints
Person
Faculty
Undergrad (BS)


Student(BS/MS/PHD)
Graduate (MS/PHD)
Only Three out of Four Can Co-Exist….
Adding Fourth Causes Contradiction…
SW&OO-1.158
How Does Contradiction Occur?

CSE300 

Specialization via Constraints with Set_Degree
Method (see Previous Slide)
Assume Static TC, Substitutability, and Mutability
Suppose:
Var S: Student;
U: Undergrad;
S := U; // OK if Subst. and Mutab.
Set_Degree (S, MS); //No Compile Error

Runtime: Unless Static TC Weakend, the Wrong
Set_Degree Operation will be Chosen
SW&OO-1.159
Concluding Remarks

CSE300

Software Engineering has Long History
 Software Qualities
 Software Principles
 ADT and Object-Oriented Concepts
Component Based Design Strongly Influenced by
All of these and
 Inheritance
 Polymorphism
 Dispatching
 Overloading
 Static and Dynamic Type Checking
SW&OO-1.160