SW&OO-1.1 CSE300 Software Engineering and Object-Oriented Design and Development Prof. Steven A. Demurjian, Sr. Computer Science & Engineering Department.

SW&OO-1.1

CSE300

Software Engineering andSoftware Engineering andObject-Oriented Design and DevelopmentObject-Oriented Design and Development

Prof. Steven A. Demurjian, Sr.Computer Science & Engineering Department

The University of Connecticut371 Fairfield Road, Box U-255

Storrs, CT 06269-2155

[email protected]://www.engr.uconn.edu/

~steve(860) 486 - 4818

Copyright © 2000 by S. Demurjian, Storrs, CT.

SW&OO-1.2

CSE300

Overview of PresentationOverview of Presentation

Motivation and Background ConceptsMotivation and Background Concepts Software Engineering Qualities and PrinciplesSoftware Engineering Qualities and Principles

Extensibility, Correctness, Reliability, etc. Abstraction, Modularity, Incrementality, etc.

Revisiting Core Object-Oriented ConceptsRevisiting Core Object-Oriented Concepts Encapsulation, Hiding, Inheritance, etc.

Advanced Object-Oriented ConceptsAdvanced Object-Oriented Concepts Polymorphism, Dispatching, Generics, etc.

OO Design, Programming, and DatabasesOO Design, Programming, and Databases Assessing Available Technologies Predicting the Future

Summary and DiscussionSummary and Discussion

SW&OO-1.3

CSE300

What is Software?What is Software?

Software is the Definition and Organization of a Software is the Definition and Organization of a Set of Tasks and Functionality Encapsulated into a Set of Tasks and Functionality Encapsulated into a Form that is Executable on a Computer Form that is Executable on a Computer

What are Different Types of Software?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.4

CSE300

What is Software Engineering?What is Software Engineering?

Engineering: The Application of Science to the Engineering: The Application of Science to the Solution of Practical ProblemsSolution of Practical Problems

Software Engineering: The Application of CS to Software Engineering: The Application of CS to Building Practical Software Systems Building Practical Software Systems

ProgrammingProgramming Individual Writes Complete Program One Person, One Computer Well-Defined Problem Programming-in-the-Small

Software EngineeringSoftware Engineering Individuals Write Program Components Team Assembles Complete Program Programming-in-the-Large

SW&OO-1.5

CSE300

Why Software Engineering?Why Software Engineering?

Program Complexity Transcends Individual or Program Complexity Transcends Individual or Lone ProgrammerLone Programmer

Software Engineering Targeted forSoftware 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 Software Engineering must Evolve to be an Engineering DisciplineEngineering Discipline

Software Engineering Must Promote and Support Software Engineering Must Promote and Support Multi-Person Construction of Multi-Version Multi-Person Construction of Multi-Version SoftwareSoftware

SW&OO-1.6

CSE300

Software EngineeringSoftware EngineeringA Historical PerspectiveA Historical Perspective

““Early Days”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 DisciplineTowards a Software Engineering Discipline Individuals Couldn’t see “Big Picture” Increase in Communication Time Personnel Changes Impact on Productivity

SE: Management, Organization, Tools, Theories, SE: Management, Organization, Tools, Theories, Methodologies, Techniques, etc.Methodologies, Techniques, etc.

SW&OO-1.7

CSE300

Influences on Software EngineeringInfluences on Software Engineering

Cost of Software Continues to Increase, Requiring Cost of Software Continues to Increase, Requiring More Efficient Software ProductionMore Efficient Software Production Software Acquisition vs. Outsourcing Software Reuse vs. Build-from-Scratch

Complexity of Large Software Altered the View Complexity of Large Software Altered the View from Development Perspectivefrom Development PerspectiveConceptionConception DesignDesign DevelopmentDevelopmentIntegrationIntegration DistributionDistribution Documentation DocumentationMaintenanceMaintenance EvolutionEvolution Extension Extension

Software Engineering/Computer Science GrowthSoftware Engineering/Computer Science Growth 350,000 Information Technology Jobs Open 100,000 New Jobs per Year for 10 Years

SW&OO-1.8

CSE300

Programmer vs. Software EngineerProgrammer vs. Software Engineer

Individual with Good Individual with Good SkillsSkills

Programming-in-the-SmallProgramming-in-the-Small Knowledge onKnowledge on

Data Structures Algorithms

Fluent in Several Fluent in Several Programming LanguagesProgramming Languages

May Lack Formal May Lack Formal TrainingTraining

Minimal Exposure to CSMinimal Exposure to CS

Part of a TeamPart of a Team Programming-in-the-Programming-in-the-

LargeLarge Design ApproachesDesign Approaches

OO, Modules, etc. Top-Down/Bottm-Up

Translates Requirements Translates Requirements into Specificationsinto Specifications

Familiarity in Multiple Familiarity in Multiple Application AreasApplication Areas

Converses with UsersConverses with Users Sees “Big Picture”Sees “Big Picture” Can Model ApplicationCan Model Application Good Communication Good Communication

and Interpersonal Skillsand Interpersonal Skills

SW&OO-1.9

CSE300

How is Software Engineered?How is Software Engineered?Waterfall Process ModelWaterfall Process Model

Requirements Analysis andSpecification

Design andSpecification

Coding andModule Testing

Integration andSystem Testing

Delivery and Maintenance

50 %50 %

50 %50 %

What is Major Disadvantage?

SW&OO-1.10

CSE300

Software Lifecycle of Waterfall ModelSoftware Lifecycle of Waterfall Model

Requirements Analysis and SpecificationRequirements 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 SpecificationDesign 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.11

CSE300

Software Lifecycle of Waterfall ModelSoftware Lifecycle of Waterfall Model

Coding and Module TestingCoding 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 TestingIntegration and System Testing Integration of Components/Modules into

Subsystems Integration of Subsystems into Final Program

Delivery and MaintenanceDelivery and Maintenance System Delivered to Customer/Market Bug Fixes and Version Releases Over Time

SW&OO-1.12

CSE300

Relating Software Engineering and Relating Software Engineering and Computer Science DisciplinesComputer Science Disciplines

SE to Programming LanguagesSE 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 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.13

CSE300


SE to Operating Systems SE to Operating Systems Relationship Between Components and

Versions Protected/Non-Protected Portions of OS Vehicle Through Which Programs Developed

Operating Systems to SE 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.14

CSE300


SE to Databases/Security 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 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.15

CSE300


AI to SE AI to SE Exploratory Development and Scenarios Declarative Approach Natural Language and Voice Interfaces

Theoretical Models to SE 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.16

CSE300

Relating Software Engineering Relating Software Engineering to Other Disciplinesto Other Disciplines

SE and ManagementSE 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. SE and ESE, ME, ChemE, CivilE, etc.

Job Growth in Engineering Specific Software SE and Biology, Chemistry, Medicine, etc.SE and Biology, Chemistry, Medicine, etc.

Medical Research and Informatics, Genome SE and Financial SectorSE and Financial Sector

Banking, ATM Networks, Electronic Commerce, Funds Transfers, Program Trading, Stock and Brokerage Houses, etc.

SW&OO-1.17

CSE300

Information SourcesInformation Sources

Motivation and Background ConceptsMotivation and Background Concepts CSE 327 Adv. SW Engineering Class Notes

Software Engineering Qualities and PrinciplesSoftware Engineering Qualities and Principles Fundamentals of Software Engineering, Ghezzi

et al., Prentice-Hall, 1991. Revisiting Core Object-Oriented ConceptsRevisiting Core Object-Oriented Concepts

An Introduction to Object-Oriented Programming, Budd, Addison-Wesley, 1997.

Advanced Object-Oriented ConceptsAdvanced Object-Oriented Concepts Readings in Object-Oriented Databases,

Zdonik/Maier (eds.), Morgan-Kaufman, 1990 OO Design, Programming, and DatabasesOO Design, Programming, and Databases

Prof. Heidi J.C. Ellis, RPI at Hartford, UConn PhD, 1994, www.hgc.edu/~heidic

SW&OO-1.18

CSE300

Motivation and Background ConceptsMotivation and Background Concepts

Information Engineering for 21st CenturyInformation 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 ClassAbstract 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.19

CSE300

Timely and Efficient Utilization of InformationTimely 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 InformationCollection, Synthesis, Analyses of Information

Better Understanding of Processes, Sales, Productivity, etc.

Dissemination of Only Relevant/Significant Information - Reduce Overload

Information EngineeringInformation Engineering Challenge for 21st Century Challenge for 21st Century

SW&OO-1.20

CSE300

Careful Thought to its Definition/PurposeCareful Thought to its Definition/Purpose Thorough Understanding of its Intended Usage Thorough Understanding of its Intended Usage

and Potential Impactand Potential Impact Insure and Maintain its ConsistencyInsure and Maintain its Consistency

Quality, Correctness, and Relevance Protect and Control its AvailabilityProtect and Control its Availability

Who can Access What Information in Which Location and at What Time?

Long-Term Persistent Storage/RecoverabilityLong-Term Persistent Storage/Recoverability Cost, Reusability, Longitudinal, and

Cumulative Experience Integration of Past, Present and Future Information Integration of Past, Present and Future Information

via Intranet and Internet Accessvia Intranet and Internet Access

How is Information Engineered?How is Information Engineered?

SW&OO-1.21

CSE300

Focus on Information and its BehaviorFocus on Information and its Behavior Answer the Following QuestionsAnswer 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?

Future Design EmphasisFuture Design Emphasis

SW&OO-1.22

CSE300

Proposed by B. Liskov (MIT) for CLU in 1975Proposed by B. Liskov (MIT) for CLU in 1975 ADTs Promote Application Development From ADTs Promote Application Development From

Perspective of Information and its UsagePerspective of Information and its Usage ADT Design Process: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 TypesADTs Correspond to User-Defined Data Types Analogous to Integer Data Type and +, -, *, etc.Analogous to Integer Data Type and +, -, *, etc.

Abstract Data Types (ADTs)Abstract Data Types (ADTs)

SW&OO-1.23

CSE300

Consider the following Example Consider the following Example StackStack ADT: ADT:


PublicInterface

User

PUSHPOPTOPEMPTY

Private Implementation

DesignerHead: Int;ST: Array[100] of Int;

Push(X Int)…End;

Int Pop()…End;

TOP

5

1015

20

PUSH

5

20 15 10 5

20 15 10 5

ST

SW&OO-1.24

CSE300

Separation of Concerns and Modularity Separation of Concerns and Modularity Problem Decomposable into Components

Abstraction and Representation IndependenceAbstraction and Representation Independence Hiding Implementation of Components Changing without Impacting External View

Incrementality and Anticipation of ChangeIncrementality and Anticipation of Change Components are Changed, Added, Refined,

etc., as Needed to Support Evolving Requirements

CohesionCohesion: Well-Defined Component Performs a : Well-Defined Component Performs a Single Task or has a Single ObjectiveSingle Task or has a Single Objective

CouplingCoupling: Component Interactions are Known and : Component Interactions are Known and MinimalMinimal

ADT Design GuidelinesADT Design Guidelines

SW&OO-1.25

CSE300

Object-Oriented DecompositionObject-Oriented Decomposition Decompose Problem into Agents which

Perform Operations Emphasize Agents that Cause Actions

Agents Comprised of Two PartsAgents 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 An Agent Can Only be Modified by Operations

Defined in either the Defined in either the Hidden ImplementationHidden Implementation or or PublicPublic InterfaceInterface

Object-Oriented ParadigmObject-Oriented Paradigm

SW&OO-1.26

CSE300

Class Class The Type of an Agent Describes the Behavior

Object Object The Instance of a Class Represents Actual Data Manipulated by Agents Maintains the State of Object

MethodMethod Operation Defined on a Class Operates on ALL Instances of the Class

MessageMessage Indicates that an Object’s Method Invoked

Core Object-Oriented ConceptsCore Object-Oriented Concepts

SW&OO-1.27

CSE300

An Example Employee ClassAn Example Employee Class

Class Employee {

}

//Hidden ImplementationPrivate: //Instance Vars char[30] name; float salary;//Public InterfacePublic: void print_name(); void print_salary(); void update_salary(float i); Employee(char *n, float s);

Main(){//Declare ObjectsEmployee emp1(Steve,100.0);Employee emp2(Lois, 120.0);

//Pass Messages//Invoke Methodsemp1.print_name();emp1.print_salary();emp2.update_salary(10);emp2.print_name();emp2.print_salary();}

What’s Output of Main()?

Steve100.0Lois130.0

Conclusion: Each Object (emp1,emp2) has Own Independent State that is Accessible via Shared Public Interface of Class

SW&OO-1.28

CSE300

Module Module Describes Both State and Behavior Module Employee Includes Instance

Variables, Operations, and Program Variables Single Instance Shared by All Users

Class Class Describes Only the Behavior Class Employee Omits Program Variables Multiple Independent Instances Share Same

Class Declaration but have Separate States Key Difference: Key Difference: Dynamic NatureDynamic Nature of Classes of Classes

Allows Instances to be Created as NeededAllows Instances to be Created as Needed

Modules vs. ADTs/ClassesModules vs. ADTs/Classes

SW&OO-1.29

CSE300

InheritanceInheritance Controlled Sharing of Between Classes

Generalization and Specialization Treat Instances of Different Classes in Uniform

Fashion - Leading to … Polymorphism/Dynamic BindingPolymorphism/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 ClassGeneric: 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)

Advanced Object-Oriented Concepts Advanced Object-Oriented Concepts

SW&OO-1.30

CSE300

A Quick Look at InheritanceA Quick Look at Inheritance

Person Name, SSN Print_Info()

Faculty::Employee Rank Promote_Fac()

Dean::Employee School

Employee::Person Dept, Salary Update_Salary()

Student::Person Dorm, GPA Print_Transcript

GeneralizationSpecialization

Supertype, Superclass, Parent Class, Base ClassSubtype, Subclass, Child Class, Derived Class

Descendants, Ancestors, Siblings

SW&OO-1.31

CSE300

What Can Be a Class?What Can Be a Class?

Private Data Public Interface

Chunk of Information

Employee Name Create_Employee() Class Address Give_Raise(Amount) SSN Change_Address(New_Addr) ... ...

Functional Component

ATM_Log Acct_Name Check_Database(Name) Class PIN_Number Verify_PIN(PIN) ... Log_on_Actions(Name, PIN) Reject() ...

SW&OO-1.32

CSE300

What Can Be a Class?What Can Be a Class?

Private Data Public Interface

User Interface

ATM_User Action Log_on_Steps() Class Balance Acct_WithD(Amt) WD_Amt Check_Balance(Number) ... Deposit_Check() ...

Or --- Anything that you Want!

SW&OO-1.33

CSE300

Client C and Servers S1, S2, S3, etc … Client C and Servers S1, S2, S3, etc … A Client Request Services to Carry Out FunctionsA 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 A Server Provides Services for Use by Other Clients and ServersClients and Servers Server Si Exports Services for Use Server Si Imports Services from Other Servers

Pure Client: No Public Interface, Imports ServicesPure Client: No Public Interface, Imports Services Pure Server: Only Exports ServicesPure Server: Only Exports Services Mixed: Mixed:

Gravitate Towards “Mostly” Client or Server 50-50 Split (40-60, etc.) also Likely

Client/Server Concepts and ClassesClient/Server Concepts and Classes

SW&OO-1.34

CSE300

Supports Reusable Software ComponentsSupports Reusable Software Components Creation and Testing in Isolation Integration of Working Components Designers/Developers View Problem at Higher

Level of Abstraction Controls Information ConsistencyControls Information Consistency

Public Interface Limits Access to Data Private Implementation Unavailable

Promotes/Facilitates Software Evolution/ReusePromotes/Facilitates Software Evolution/Reuse Inheritance to Extend Design/Class Library Multiple Instances of Same Class

Benefits of OO ParadigmBenefits of OO Paradigm

SW&OO-1.35

CSE300

Software Engineering QualitiesSoftware Engineering Qualities

Software is a Malleable Product that is Human Software is a Malleable Product that is Human Intensive (High People to Machine Ratio)Intensive (High People to Machine Ratio)

A A Software QualitySoftware Quality is a Characteristic to be is a Characteristic to be Attained throughout an Application’s LifetimeAttained throughout an Application’s Lifetime Correctness and Reliability Robustness and Performance Maintenance and Reusability Repairability and Evolvability Portability and Interoperability

Types of Software QualitiesTypes of Software Qualities Internal vs. External Process vs. Product

SW&OO-1.36

CSE300

What is a Software Quality?What is a Software Quality?

A A Software QualitySoftware Quality is a Characteristic to be is a Characteristic to be Attained throughout an Application’s LifetimeAttained throughout an Application’s Lifetime

Software Qualities are the Goals of Product and Software Qualities are the Goals of Product and ProcessProcess

Types of Software QualitiesTypes 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 Software Quality Assurance: Assess and Evaluate the Attainment of Qualities by Finished Productthe Attainment of Qualities by Finished Product

SW&OO-1.37

CSE300

The Correctness Software QualityThe Correctness Software Quality

Functional Correctness: Software Behaves Functional Correctness: Software Behaves According to Requirements SpecificationAccording to Requirements Specification

Assessing Correctness - Potential ProblemsAssessing 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 - Absolute Quality (Yes/No) Correctness and OO ParadigmCorrectness and OO Paradigm

Focus on Correctness of Components at Varying Levels

Addressed via Public Interface, Private Implementation, and Testing of Classes

SW&OO-1.38

CSE300

The Reliability Software QualityThe Reliability Software Quality

Software Performs as User Expects Software Performs as User Expects User Can Depend on SoftwareUser Can Depend on Software Different Reliability Requirements per DomainDifferent Reliability Requirements per Domain

Computer Games: Low? Flight Control Software (Mars): High? Banking, Insurance, Stocks, …: High?

Correct Software is Reliable but Reliable Software Correct Software is Reliable but Reliable Software May Not be Correct, that is … May Not be Correct, that is …

For OO, Focus on For OO, Focus on Reliability of Components Reliability of Components (Classes)(Classes) and their and their Composition into SystemsComposition into Systems

Correctness

Reliability

SW&OO-1.39

CSE300

The Robustness Software QualityThe Robustness Software Quality

Software Behaves Reasonably, Even in Software Behaves Reasonably, Even in Unexpected CircumstancesUnexpected Circumstances

Different Robustness Requirements per DomainDifferent Robustness Requirements per Domain Computer Games: Low or High? ATM Machine: High - Hard to Break

May Include Hardware Robustness (ATM Story)May Include Hardware Robustness (ATM Story) Incorrect Behaviors Acceptable, as Long as a Incorrect Behaviors Acceptable, as Long as a

Consistent, Workable Outcome Occurs Consistent, Workable Outcome Occurs Robustness and OO ParadigmRobustness 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.40

CSE300

The Performance Software QualityThe Performance Software Quality

Performance is Equated with Efficiency, Performance is Equated with Efficiency, Scalability, Reliability, User-Acceptance, etc.Scalability, Reliability, User-Acceptance, etc.

Growing Problem Impacts Strongly on SoftwareGrowing 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. SimulationMeasurement vs. Queuing Analysis vs. Simulation Impact from Specification through Delivery Impact from Specification through Delivery Performance and OO ParadigmPerformance and OO Paradigm

Identify Key Classes with Hard Performance Constraints

Versions of Classes for OS/HW Platforms?

SW&OO-1.41

CSE300

The Maintenance Software QualityThe Maintenance Software Quality

Modifications and Enhancements Made to Product Modifications and Enhancements Made to Product After Release - After Release - 60% of Total Software Cost60% of Total Software Cost

Three Types of MaintenanceThree 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 Modification to Legacy Software for Major Improvement or Improvement or Software EvolutionSoftware Evolution

Maintenance and OO ParadigmMaintenance and OO Paradigm Can OO Reduce Corrective Maintenance? Can OO Facilitate Adaptive and Perfective

Maintenance?

SW&OO-1.42

CSE300

The Reusability Software QualityThe Reusability Software Quality

Strive for Strive for Domain-and-Organization SpecificDomain-and-Organization Specific ReuseReuse

Products Most Likely to be Developed in FutureProducts Most Likely to be Developed in Future Focused on Software ComponentsFocused 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., Reusability Evolving to Larger Components (e.g., Java Beans) and SubsystemsJava Beans) and Subsystems

Reusability and OO ParadigmReusability and OO Paradigm Achieved via Inheritance and Generics Defined and Controlled by Designers and

Developers

SW&OO-1.43

CSE300

The Repairability Software QualityThe Repairability Software Quality

Ability to Correct Problems with Limited Amount Ability to Correct Problems with Limited Amount of Work and a Minimal Impactof Work and a Minimal Impact

A Well Modularized Product is Easier to Modify A Well Modularized Product is Easier to Modify than a Monolithic Projectthan a Monolithic Project

Programming Language Role in RepairabilityProgramming Language Role in Repairability What is Classic Repairability Problem Today?What is Classic Repairability Problem Today? Repairability Related to Reusability/Evolvability Repairability Related to Reusability/Evolvability Repairability and OO ParadigmRepairability 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.44

CSE300

The Evolvability Software QualityThe Evolvability Software Quality

Field of Dreams: Field of Dreams: If you Build it, it Will Change!If you Build it, it Will Change! Key Evolvability IssuesKey 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 Over Time, Evolvability Reduces as Subsequent Versions of Same Software are ReleasedVersions of Same Software are Released

Reach of Limit of Change w.r.t. Look-and-FeelReach of Limit of Change w.r.t. Look-and-Feel Evolvability and OO ParadigmEvolvability and OO Paradigm

Achieved via Inheritance and Polymorphism Public Interface Must Remain Unchanged!

SW&OO-1.45

CSE300

The Portability Software QualityThe Portability Software Quality

Software Works on Different PlatformsSoftware Works on Different Platforms Origins and Popularity of C and Unix Origins and Popularity of C and Unix Hard in Practice - All C++’s Not Created EqualHard 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 Newer Languages (Ada95, Java) Stress Ability to Port Port without Rewriting Any Codewithout Rewriting Any Code

Portability and OO ParadigmPortability and OO Paradigm Isolate Specifics into Dedicated Classes Portability Transcends D & D Paradigm

SW&OO-1.46

CSE300

The Interoperability Software QualityThe Interoperability Software Quality

Enterprise Computing: Enterprise Computing: The Problem of Today The Problem of Today and Future!and Future!

New Products Must Coexist and Cooperate with New Products Must Coexist and Cooperate with Legacy, COTS, Databases, etc.Legacy, COTS, Databases, etc.

Success in Interoperability Traced to … 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.Open Systems, Standards, Multiple Vendors, etc. Interoperability and OO ParadigmInteroperability and OO Paradigm

Focus on Public Interface Concept Interoperability Transcends D & D Paradigm

SW&OO-1.47

CSE300

Software Engineering PrinciplesSoftware Engineering Principles

Principles Involve Software Engineering Process Principles Involve Software Engineering Process and its Product 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 PrinciplesSoftware Engineering Principles Separation of Concerns and Modularity Abstraction and Anticipation of Change Generality and Incrementality

SW&OO-1.48

CSE300

What are Software Principles?What are Software Principles?

Software PrinciplesSoftware Principles are the Guiding Factors that are the Guiding Factors that Govern any and all Software Design/DevelopmentGovern any and all Software Design/Development

Software Principles Transcend the Application to Software Principles Transcend the Application to Focus on Software Engineering Process/ProductFocus on Software Engineering Process/Product

SoftwarePrinciples

Methods &Techniques

Methodologies

Tools

SW&OO-1.49

CSE300

Separation of ConcernsSeparation of Concerns

Divide and Conquer Problem Solving Technique Divide and Conquer Problem Solving Technique Identify the Different Aspects of ProblemIdentify 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 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!Separation of Concerns is Critical!

SW&OO-1.50

CSE300

ModularityModularity

Compose and Design Systems as Set of Modules Compose and Design Systems as Set of Modules Two-Phase Application of Separation of ConcernsTwo-Phase Application of Separation of Concerns

Define Details of Individual Modules Characterize Interactions Among All Modules

Three Goals of Modularity Three Goals of Modularity Decomposability: Problem to Subproblems Composability: Combine to Solution Abstraction: Capability of Understanding

Levels of Modules in ProgrammingLevels of Modules in Programming C: “.h/.c” Pairs - Ad-hoc Modularity C++: “.h/.c” Pairs for Classes Ada95/Java: Adds the Package Concept

Maximize CohesionMaximize Cohesion and and Minimize CouplingMinimize Coupling

SW&OO-1.51

CSE300

AbstractionAbstraction

Remove/Hide Unimportant Details to Allow more Remove/Hide Unimportant Details to Allow more Important Aspects of a Product to be Considered Important Aspects of a Product to be Considered

Widely Utilized to Reduce ComplexityWidely Utilized to Reduce Complexity Abstractions Dominate ComputingAbstractions 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 AbstractionsPeople Think and Learn in Abstractions Goals of Advances in Design and Programming Goals of Advances in Design and Programming

Provide Robust Sets of Abstractions Allow Modeling to Occur Close to Real World

SW&OO-1.52

CSE300

Anticipation of ChangeAnticipation of Change

Software Changes and Evolves Throughout All Software Changes and Evolves Throughout All Stages from Specification Onward Stages from Specification Onward

Key is to Anticipate Future ChangesKey is to Anticipate Future Changes Once Anticipated, Encapsulate Areas for Potential Once Anticipated, Encapsulate Areas for Potential

Changes into Targeted Portions of ProductChanges into Targeted Portions of Product Is Anticipation of Change Unique to Computing?Is Anticipation of Change Unique to Computing? Handling Anticipation of ChangeHandling Anticipation of Change

Basis of Evolvability and Reusability Requires Automated Support (SCCS, etc.) Impacts Software Production Process

Can Future Products be Predicted?Can Future Products be Predicted? Is Planning Cycle 5 or More Years?Is Planning Cycle 5 or More Years?

SW&OO-1.53

CSE300

GeneralityGenerality

For a Given Problem, Look for a General Problem For a Given Problem, Look for a General Problem and Solveand Solve Supermarket System vs. Inventory Control Hospital Application vs. Health Care Product

Adapt General Solution to Specific ProblemAdapt 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 ReuseDomain-and-Organization Specific Reuse What Products will be Developed in Future?What Products will be Developed in Future? Leverage Additional Short-Term Effort with Leverage Additional Short-Term Effort with

Long-Term Gains w.r.t. Maintenance, Reuse, … Long-Term Gains w.r.t. Maintenance, Reuse, …

SW&OO-1.54

CSE300

IncrementalityIncrementality

Products are Built in IncrementsProducts are Built in Increments Quicker to Market Focused, Less Errors in Smaller Increments Phased Prototypes with Increasing Functions

Difficulty in Constructing Solutions to Complex Difficulty in Constructing Solutions to Complex Computing ProblemsComputing Problems Utilize Rapid Prototyping to Discern

Requirements from Users Allow Designers/Developers to Learn Domain

An Engineering Approach to Problem SolvingAn Engineering Approach to Problem Solving Incrementality Ideal Companion to OO ParadigmIncrementality Ideal Companion to OO Paradigm

Add Classes for Successive Prototypes Include New Functionality in Existing Classes

SW&OO-1.55

CSE300

Principles and OO ParadigmPrinciples and OO Paradigm

Separation of ConcernsSeparation of Concerns Define Classes at Different Abstraction Levels

Modularity Modularity Classes are Components of Solution

Abstraction Abstraction Public Interface and Private Implementation

Anticipation of ChangeAnticipation of Change Design Classes for Change

GeneralityGenerality Generics and Solving General Problems

IncrementalityIncrementality New and Expanded Classes over Time

SW&OO-1.56

CSE300

Background and MotivationBackground and Motivation Transitional Design & Silver Bullet (Brooks) Law of Demeter/Responsibility-Driven Design

Object-Oriented Design IssuesObject-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, Software Design,” Demurjian, Chapter 108, The The Computer Science & Engineering HandbookComputer Science & Engineering Handbook, , Tucker (ed.), CRC Press, 1997.Tucker (ed.), CRC Press, 1997.

Object-Oriented ConceptsObject-Oriented Concepts

SW&OO-1.57

CSE300

As Software has Become more Complex, it As Software has Become more Complex, it Requires more Software EngineersRequires more Software Engineers

F. Brooks - Mythical Man Month - 1970sF. 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?WHY? Interconnectedness: Interdependencies in CodeInterconnectedness: Interdependencies in Code

Individual Portions can’t be Written in Isolation

Information Exchange Needed Between SEs Complexity Historically Controlled by Abstracting Complexity Historically Controlled by Abstracting

Away Less Important DetailsAway Less Important Details

Abstraction and ComplexityAbstraction and Complexity

SW&OO-1.58

CSE300

ProceduresProcedures The “First” Abstraction Mechanism Repeated Execution of Same Code without

Duplication Inefficient at Information Hiding

Modules: Managing Name SpacesModules: 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

History of Abstraction History of Abstraction Procedures and ModulesProcedures and Modules

SW&OO-1.59

CSE300

Proposed by B. Liskov (MIT) for CLU in 1975Proposed by B. Liskov (MIT) for CLU in 1975 ADTs Promote Application Development From ADTs Promote Application Development From

Perspective of Information and its UsagePerspective of Information and its Usage ADT Design Process: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 TypesADTs Correspond to User-Defined Data Types Analogous to Integer Data Type and +, -, *, etc.Analogous to Integer Data Type and +, -, *, etc.


SW&OO-1.60

CSE300

Consider the following Example Consider the following Example StackStack ADT: ADT:


PublicInterface

User

PUSHPOPTOPEMPTY

Private Implementation

DesignerHead: Int;ST: Array[100] of Int;

Push(X Int)…End;

Int Pop()…End;

TOP

5

1015

20

PUSH

5

20 15 10 5

20 15 10 5

ST

SW&OO-1.61

CSE300

Separation of Concerns and Modularity Separation of Concerns and Modularity Problem Decomposable into Components

Abstraction and Representation IndependenceAbstraction and Representation Independence Hiding Implementation of Components Changing without Impacting External View

Incrementality and Anticipation of ChangeIncrementality and Anticipation of Change Components are Changed, Added, Refined,

etc., as Needed to Support Evolving Requirements

CohesionCohesion: Well-Defined Component Performs a : Well-Defined Component Performs a Single Task or has a Single ObjectiveSingle Task or has a Single Objective

CouplingCoupling: Component Interactions are Known and : Component Interactions are Known and MinimalMinimal

ADT Design GuidelinesADT Design Guidelines

SW&OO-1.62

CSE300

Object-Oriented DecompositionObject-Oriented Decomposition Decompose Problem into Agents which

Perform Operations Emphasize Agents that Cause Actions

Agents Comprised of Two PartsAgents 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 An Agent Can Only be Modified by Operations

Defined in either the Defined in either the Hidden ImplementationHidden Implementation or or PublicPublic InterfaceInterface

Object-Oriented ParadigmObject-Oriented Paradigm

SW&OO-1.63

CSE300

Class Class The Type of an Agent Describes the Behavior

Object Object The Instance of a Class Represents Actual Data Manipulated by Agents Maintains the State of Object

MethodMethod Operation Defined on a Class Operates on ALL Instances of the Class

MessageMessage Indicates that an Object’s Method Invoked

Core Object-Oriented ConceptsCore Object-Oriented Concepts

SW&OO-1.64

CSE300

An Example Employee ClassAn Example Employee Class

Class Employee {

}

//Hidden ImplementationPrivate: //Instance Vars char[30] name; float salary;//Public InterfacePublic: void print_name(); void print_salary(); void update_salary(float i); Employee(char *n, float s);

Main(){//Declare ObjectsEmployee emp1(Steve,100.0);Employee emp2(Lois, 120.0);

//Pass Messages//Invoke Methodsemp1.print_name();emp1.print_salary();emp2.update_salary(10);emp2.print_name();emp2.print_salary();}

What’s Output of Main()?

Steve100.0Lois130.0

Conclusion: Each Object (emp1,emp2) has Own Independent State that is Accessible via Shared Public Interface of Class

SW&OO-1.65

CSE300

Module Module Describes Both State and Behavior Module Employee Includes Instance

Variables, Operations, and Program Variables Single Instance Shared by All Users

Class Class Describes Only the Behavior Class Employee Omits Program Variables Multiple Independent Instances Share Same

Class Declaration but have Separate States Key Difference: Key Difference: Dynamic NatureDynamic Nature of Classes of Classes

Allows Instances to be Created as NeededAllows Instances to be Created as Needed

Modules vs. ADTs/ClassesModules vs. ADTs/Classes

SW&OO-1.66

CSE300

What Does What Does Customer WantCustomer Want? ? What Does What Does Designer NeedDesigner Need? ? Comprehensive Object-Oriented Design Must: 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 KEY: Define the Problem and Understand its Domain and ScopeDomain and Scope

Concepts of Transitional DesignConcepts of Transitional Design

SW&OO-1.67

CSE300

Transitional Design - PracticeTransitional Design - Practice

Focus on Encapsulation, Hiding, and Inheritance Focus on Encapsulation, Hiding, and Inheritance Emphasize a Behavioral Perspective:Emphasize a Behavioral Perspective:

What's Encapsulated/Hidden? Actions/Responsibilities are Key! Interdependencies are Critical!

While Encapsulation and Hiding Typically Imply While Encapsulation and Hiding Typically Imply an Independence Among “Classes” (other than an Independence Among “Classes” (other than Inheritance), Our Claim is that Such a View is Inheritance), Our Claim is that Such a View is Artificial and Unrealistic!Artificial and Unrealistic!

Represent Represent “World” as it Occurs“World” as it Occurs, Not as we , Not as we Would Like it to Occur!Would Like it to Occur!

SW&OO-1.68

CSE300

Thoughts From Fred BrooksThoughts From Fred Brooks

““No Silver Bullet”, No Silver Bullet”, IEEE ComputerIEEE Computer, Apr. 1987, Apr. 1987 Common MotivationCommon 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, Focus on the Identification, Cultivation, Recognition and Reward of “Great Designers”Recognition and Reward of “Great Designers”

““Biting the Silver Bullet”, D. Harel, Biting the Silver Bullet”, D. Harel, IEEE IEEE ComputerComputer, Jan. 1992, Jan. 1992

SW&OO-1.69

CSE300

Law of DemeterLaw of Demeter(Leiberherr, Northeastern University)(Leiberherr, Northeastern University)

Stress Encapsulation by Reducing Stress Encapsulation by Reducing Interdependencies Between Classes (Objects) Interdependencies Between Classes (Objects)

High Cohesion and No Coupling High Cohesion and No Coupling A Class Cannot Directly Manipulate (via Method) A Class Cannot Directly Manipulate (via Method)

Internal Representation of Another Class Internal Representation of Another Class Classes Developed and Analyzed Independently Classes Developed and Analyzed Independently Focus on Method Access and Message SendingFocus 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.See Budd, Section 17.1.3, pg. 306.

SW&OO-1.70

CSE300

Responsibility-Driven DesignResponsibility-Driven Design(Wirfs-Brock & Wilkerson, OOPSLA89)(Wirfs-Brock & Wilkerson, OOPSLA89)

Approach Emphasizes Responsibilities: Approach Emphasizes Responsibilities: “What actions is this object responsible for?” “What information does this object share?”

Three Perspective Client Model:Three Perspective Client Model: External Clients Subclass Clients Self Client

Focus on Actions and Behavior Focus on Actions and Behavior Interactions Inevitable! Interactions Inevitable! Key: Define Required InteractionsKey: Define Required Interactions

SW&OO-1.71

CSE300

Objects vs. ADTsObjects vs. ADTs

Objects Extend ADTs as follows: 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 BenefitsADT/OO Benefits:

Support Creation of Reusable Software Components

Creation and Testing in Isolation! SEs View Problem at Higher-Level of

Abstraction

SW&OO-1.72

CSE300

Choosing Objects and Classes Choosing Objects and Classes

The ‘First’ and Most ‘Often’ Concern for The ‘First’ and Most ‘Often’ Concern for Newcomers to OO Concepts Newcomers to OO Concepts

Typical Answers: Typical Answers: High Cohesion, Low Coupling, Encapsulation Law of Demeter, Responsibility-Driven Design Comes with Experience and Time

Better Answer: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.73

CSE300

Choosing Objects for BlackJackChoosing Objects for BlackJack

Consider ‘Naïve’Abstraction:Consider ‘Naïve’Abstraction:

Deck Hand Game+---------+ +-------+ +-------------------+| Shuffle | | Play | | +----+ +----+ || Deal | | Hit | | |Hand| |Hand| ... || Hit | | Stand | | +----+ +----+ || ... | | ... | | Operations? |+---------+ +-------+ +-------------------+

What's Been Ignored? What's Been Ignored? Multiple Decks of Cards? Modeling of Deck - Suits/Cards? Strategy for House?

Moral: Objects/Classes are Moral: Objects/Classes are Not a PanaceaNot a Panacea for for Comprehensive, Up-Front, Problem Exploration via Comprehensive, Up-Front, Problem Exploration via a Detailed Specificationa Detailed Specification

SW&OO-1.74

CSE300

The High-Tech Supermarket System (HTSS)The High-Tech Supermarket System (HTSS) Description of Capabilities Modules and ADTs for HTSS

Responsibility Driven Design via CRC CardsResponsibility Driven Design via CRC Cards CClass RResponsibilities CCollaborators Select Examples to Demonstrate Technique

Categories of ClassesCategories of Classes CRC Methodological IssuesCRC Methodological Issues Common Design FlawsCommon Design Flaws

Object-Oriented Design IssuesObject-Oriented Design Issues

SW&OO-1.75

CSE300

High-Tech Supermarket System (HTSS)High-Tech Supermarket System (HTSS)

Automate the Functions and ActionsAutomate the Functions and Actions Cashiers and Inventory Updates User Friendly Grocery Item Locator Fast-Track Deli Orderer Inventory Control

User System Interfaces 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.76

CSE300

The HTSS Software ArchitectureThe HTSS Software Architecture

ICICICIC

CRCRCRCR

CRCR

CRCR

ILILILIL

ILIL

SDOSDO

SDOSDO EDOEDO

EDOEDO

OrderOrder

PaymentPayment

ItemItemItemDBItemDBLocalLocalServerServer

Non-LocalClient Int.

InventoryInventoryControlControl

ItemDBItemDBGlobalGlobalServerServer

OrderDBOrderDB

SupplierDBSupplierDB

CreditCardDBCreditCardDB

ATM-BanKDBATM-BanKDB

IL: Item LocatorIL: Item LocatorCR: Cash RegisterCR: Cash RegisterIC: Invent. ControlIC: Invent. ControlDO: Deli Orderer forDO: Deli Orderer for Shopper/EmployeeShopper/Employee

SW&OO-1.77

CSE300

Programming with ModulesProgramming with Modules

Modular Design and Development Contains: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: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.78

CSE300

Modules in HTSSModules in HTSS

MODULE Cashier; MODULE Scanner; IMPORT Get_Item(UPC), ... Get_Credit_Info(AcctNum), END Scanner; Get_Deli_Item(UPC), ...; EXPORT Display_SubTot(), MODULE Locator; Display_Total(), ... Generate_Receipt(), ...; END Locator; {code for internal data and for MODULE Orderer; procedures and functions} ... END Cashier; END Orderer; MODULE Items; MODULE DeliItems; IMPORT {various I/O routines}; ... EXPORT Get_Item(UPC), END DeliItems; New_Item(UPC, Name, ...), Modify_Item(UPC, Integer), MODULE CreditCheck; Delete_Item(UPC), ...; ... anItem = RECORD END CreditCheck; UPC : INTEGER; NAME: STRING; SIZE: REAL; ... END;END Items;

SW&OO-1.79

CSE300

Advantages/Drawbacks of ModulesAdvantages/Drawbacks of Modules

Import/Export:Import/Export: Concept Similar to Public Interface Promotes Controlled Sharing Provides Hiding Facilitates Concurrent Engineering

Strong Parallels to ADTsStrong Parallels to ADTs No Concept of “No Concept of “InstancesInstances”” But, Still Emphasizes Functional SolutionBut, Still Emphasizes Functional Solution Like OO/ADT, Supports Representation Like OO/ADT, Supports Representation

IndependenceIndependence

SW&OO-1.80

CSE300

Programming with ADTsProgramming with ADTs

ADTs Promote Applications Development From ADTs Promote Applications Development From Perspective of Information and Its UsagePerspective of Information and Its Usage

ADT Design Process and Steps: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 UpProcess 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.81

CSE300

ADTs in HTSSADTs in HTSS

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

CSE300

ADTs in HTSSADTs in HTSS

ADT Process_Order; {middle-level ADT} PRIVATE DATA: {local variables to process an order} PUBLIC OPS : {what do you think are appropriate?}

{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.83

CSE300

Advantages/Drawbacks of ADTsAdvantages/Drawbacks of ADTs

Advantages:Advantages: Abstraction is Promoted and Achieved Concurrent Engineering is Feasible Reuse and Evolution are Attainable Emphasizes Static System Behavior

Drawbacks:Drawbacks: Without Inheritance, Redundancies Likely Dynamic System Behavior Still Difficult Associations Between ADTs Difficult Only Inclusion Association Supported

Do Drawbacks Outweigh Advantages?Do Drawbacks Outweigh Advantages?

SW&OO-1.84

CSE300

Responsibility-Driven DesignResponsibility-Driven Design(Wirfs-Brock & Wilkerson, OOPSLA89)(Wirfs-Brock & Wilkerson, OOPSLA89)

Approach Emphasizes Responsibilities: 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 Focus on Actions and Behavior Interactions Inevitable! Interactions Inevitable! Key: Define Required InteractionsKey: Define Required Interactions

SW&OO-1.85

CSE300

CRC CardsCRC CardsClass, Responsibility, CollaboratorsClass, Responsibility, Collaborators

Index Cards - Each Card Defines a ClassIndex Cards - Each Card Defines a Class Front of Each CRC Card: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:Back of Each CRC Card:

Data - Hidden from Users

SW&OO-1.86

CSE300

A CRC Card for HTSSA CRC Card for HTSS

Item: A Product Sold in a Supermarket.

ItemDBCreate a New Item Return an Item's UPC Return an Item's NameReturn 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

Hidden Data:Name: String; UPC: String; Rcost, Wcost: Real;Quantity, ReorderLevel: Integer; etc...

SW&OO-1.87

CSE300

Another CRC Card for HTSSAnother CRC Card for HTSS

ItemDB: All Item’s in Supermarket - repository.

InvControlItem

Insert a New Item Delete an Existing Item Find/Display Item Based on UPCFind/Display Item Based on NameFind/Display Item Based on QtyFind/Display Item Based on ReorderPrint All Items Find an Item in Database by UPCFind an Item in Database by NameFind the First ItemFind the Next Item

Hidden Data:AllItems: Array[1..MaxItem] of Item;CurrItem, LastItem: Integer Index; etc...

SW&OO-1.88

CSE300

Flight Management ExampleFlight Management Example

Capabilities Include: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 For Simplicity, Ignore Overbooking and Attempts to Cancel Unbooked Flightsto Cancel Unbooked Flights

Using this Terse Description - Develop a SolutionUsing this Terse Description - Develop a Solution We’ll Explore Alternatives ShortlyWe’ll Explore Alternatives Shortly

SW&OO-1.89

CSE300

CRC Cards for Flight Example CRC Cards for Flight Example One SolutionOne Solution

Agent: Handles Ticketing for Passengers.

ReserveCancel

Display Transaction Menu Wait for TransactionCall Apropos Trans. Manager

Reserve: Actions for Making Reservation.

FlightScheduleIssue

Ask Schedule if Seats AvailableAsk Flight to Reserve SeatsAsk Issue to Generate Tickets

Cancel: Actions for Canceling Reservation.

FlightIssue

Ask Flight to Cancel SeatsAsk Issue to Generate Refund

SW&OO-1.90

CSE300

CRC Cards for Flight Example CRC Cards for Flight Example One SolutionOne Solution

Schedule: Flight Interactions/Ticketing.

FlightGet No. Seats and Flight No. Ask Flight if No. Seats AvailableAsk Flight to Reserve Seats Ask Flight to Cancel Seats

Issue: Generate Ticket or Cancellation.

Issue TicketIssue Refund Check

Flight: Tracks Seat Info. for Flights.Compare No. Seats with No. AvailableRemove Seats from Free ListReturn Seat No. to Schedule Add Cancelled Seat No. to Free List

SW&OO-1.91

CSE300

CRC Cards for Flight Example CRC Cards for Flight Example Critiquing First SolutionCritiquing First Solution

Schedule Flight Issue

Agent

Cancel

Reserve

Design Represents User PerspectiveDesign Represents User Perspective Highlight Interactions via CollaboratorsHighlight Interactions via Collaborators

Commonalties?Commonalties?Differences?Differences?Couplings?Couplings?

SW&OO-1.92

CSE300

Another SolutionAnother SolutionCombine Reserve, Cancel, and IssueCombine Reserve, Cancel, and Issue

Agent: Handles Ticketing for Passengers.

ReserveCancel

Display Transaction Menu Wait for TransactionCall Apropos Trans. Manager

Reservations: Making/Canceling Reservations.

FlightScheduleIssue

Ask Schedule if Seats AvailableAsk Flight to Reserve SeatsAsk Issue to Generate TicketsAsk Flight to Cancel SeatsAsk Issue to Generate RefundIssue TicketIssue Refund Check

SW&OO-1.93

CSE300

Yet Another SolutionYet Another SolutionCombine Schedule and FlightCombine Schedule and Flight

Schedule: Flight Interactions/Ticketing.

FlightGet No. Seats and Flight No. Ask Flight if No. Seats AvailableAsk Flight to Reserve Seats Ask Flight to Cancel SeatsCompare No. Seats with No. AvailableRemove Seats from Free ListReturn Seat No. to Schedule Add Cancelled Seat No. to Free List

What was Problem with Original Design?What was Problem with Original Design? What has Occurred in Redesign?What has Occurred in Redesign? Structuring Solution from Perspective of Structuring Solution from Perspective of Arrival/Departure of Flights Would Likely Arrival/Departure of Flights Would Likely Yield Different Set of Classes!! Yield Different Set of Classes!!

SW&OO-1.94

CSE300

CRC Cards for Health CareCRC Cards for Health Care

Medical_R: Contains all Medical Info on Patient.

PatientPrescriptionVisitTestPat_Display

Set/Get Patient BackgroundInsert/Get VisitInsert/Get TestAppend Medical HistoryGet Medical HistoryInsert/Get ExamGet All Medications

Patient: Individual that sees a Physician.

Medical_RFinancial_RPrescript_R

Return Personal InformationRequest Physician AppointmentDescribe SymptomsAccept TreatmentPay Bills

SW&OO-1.95

CSE300

Categories of ClassesCategories of Classes((See Budd, Section 3.2, pg. 48))

Data Managers -Data Managers - Maintain Data/State Information 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.96

CSE300


Data Sinks/Data SourcesData Sinks/Data Sources - Produce/Process Data - Produce/Process Data Generated on Demand or Maintained

class ItemDB {private: int Num_Items; int Curr_Item; Item* AllItems[Max_Items];

int FindFirstItem(); int FindNextItem(); int FindItemUPC(int code); int FindItemName(char* name); public: ItemDB(); // Constructor void InsertNewItem(Item* new_one); void DeleteExistingItem(int code); void FindDisplayItemUPC(int code); void FindDisplayItemName(char* name); void PrintAllItems(); };

SW&OO-1.97

CSE300

Categories of ClassesCategories of Classes

Data Manager Class Data Manager Class

ItemItem Class Contains the Class Contains the State of a Single ObjectState of a Single Object

Item I1, I2, I3;

Data Source/Sink Class Data Source/Sink Class

ItemDBItemDB is a Collection is a Collection or Set of Itemsor Set of Items

Item ItemDB[100];

I1“milk”

I2“peas”

I3“soda”

ItemDB

SW&OO-1.98

CSE300


View/ObserverView/Observer - Provide an Interface for User - 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.99

CSE300


Facilitator/HelperFacilitator/Helper - Used to Support Complex - Used to Support Complex TasksTasks E.g., GUI Libs, Strings, I/O Handler, etc.

For HTSS, Facilitator/Helpers as Follows: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.100

CSE300

Responsibility-Driven DesignResponsibility-Driven DesignMethodological IssuesMethodological Issues

Utilize CRC/RDD Over Time to Grow Design Utilize CRC/RDD Over Time to Grow Design Begin by Identifying Classes Vital to ApplicationBegin by Identifying Classes Vital to Application Simulate Scenarios of Expected OperationSimulate Scenarios of Expected Operation

Identify New Classes Assign/Revise Responsibilities to Classes CRC Cards Demonstrate Flow of Control

Experimental Approach to Design - AdvantagesExperimental 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.101

CSE300

Early Stage of CRC DesignEarly Stage of CRC Design

Class AClass A Class BClass B Class CClass C

Class DClass D Class EClass E

Class AClass A

DD

Class CClass C

DDEE

Class FClass F

SW&OO-1.102

CSE300

Responsibility-Driven DesignResponsibility-Driven DesignMethodological IssuesMethodological Issues

From First/Initial Attempts, CRC Cards are From First/Initial Attempts, CRC Cards are Evolved Towards “Complete” DesignEvolved 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, IncludeAs 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.103

CSE300

Later Stage of CRC DesignLater Stage of CRC Design

Class AClass A

DD Class CClass C

DDEEClass FClass F

Class AClass AClass BClass B

Class CClass C

DDDDEE

Resp 1Resp 1Resp 2Resp 2Resp 3Resp 3

Resp 1Resp 1Resp 2Resp 2Resp 3Resp 3Resp 4Resp 4

Resp 1Resp 1Resp 2Resp 2

Class DClass D Class EClass E

Int X, Y;Int X, Y;Char Z;Char Z;

Real M, N;Real M, N;String S;String S;

SW&OO-1.104

CSE300

Common Design FlawsCommon Design Flaws

Classes that Directly Modify the Private Data of Classes that Directly Modify the Private Data of Other ClassesOther Classes Provide Operations in Public Interface Only Change via Operations Asking Class to Change Itself

Recall Item from HTSSRecall Item from HTSS

Only Change RetailCost via UpdatePrice()Only Change RetailCost via UpdatePrice()Do not Access RetailCost Directly from CashierDo not Access RetailCost Directly from Cashier

class Item { private: // Private Data float RetailCost; public: // Public Methods void UpdatePrice(float new_value); };

SW&OO-1.105

CSE300


Too Much Functionality in One ClassToo 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

int GetUPC(); char* GetName(); int GetInstockAmt(); int GetOnShelfAmt(); int GetQuantity(); int GetReorderAmt(); float GetRetailPrice(); float GetWholeSaleCost();

void UpdateName(char* item_name); void UpdateInstockAmt(int stock_amt); void UpdateOnShelfAmt(int shelf_amt); void UpdateReorderAmt(int reord_amt); void UpdateRetailPrice(float price); void UpdateWholeSaleCost(float wholesale); }

virtual void CreateNewItem(); virtual void PrintItem(); virtual void PrintPerish(); virtual void UpdateItemMenu(); virtual void UpdateItem(int portion); virtual char* ReturnType();

void PrintUPCName(); void PrintNamePrice(); void PrintInventory(); void PrintProfitInfo(); void PrintUPC(); void PrintName(); void PrintInstockAmt(); void PrintOnShelfAmt();

SW&OO-1.106

CSE300


A Class that Lacks FunctionalityA Class that Lacks Functionality Class Included at Early Design Stage Merge Two or More Classes Impact on

Inheritance Hierarchies? Classes that Have Unused FunctionalityClasses that Have Unused Functionality

Eliminate Unused Functions and Reevaluate Their Necessity

Classes that Duplicate FunctionalityClasses that Duplicate Functionality Combine with Existing Class Add Non-Duplicate Functionality

SW&OO-1.107

CSE300

InheritanceInheritance Controlled Sharing of Between Classes

Generalization and Specialization Treat Instances of Different Classes in Uniform

Fashion - Leading to … Polymorphism/Dynamic BindingPolymorphism/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 ClassGeneric: 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)

Advanced Object-Oriented Concepts Advanced Object-Oriented Concepts

SW&OO-1.108

CSE300

Consider a University ApplicationConsider a University Application Four Classes Have Been IdentifiedFour Classes Have Been Identified

Faculty Dean UnderGrad Grad Name Name Name Name SSN SSN SSN SSN Rank School Dorm Dorm Dept Dept Year Program Yrs Yrs GPA Degree GPA

To Successfully Utilize InheritanceTo Successfully Utilize Inheritance Distinguish Differences (Specialization) Identify Commonalties (Generalization)

Motivating Inheritance ConceptsMotivating Inheritance Concepts

SW&OO-1.109

CSE300

One Solution:One Solution:Person Faculty:Person Dean:Person Name Rank School SSN Dept Dept Yrs Yrs

UnderGrad:Person Grad:Person Dorm Dorm Year Program GPA Degree GPA

Pictorially:Pictorially: Person

Faculty Dean UnderGrad Grad

Is this Solution Adequate?Is this Solution Adequate?

Motivating InheritanceMotivating Inheritance

SW&OO-1.110

CSE300

A Better Solution:A Better Solution: Person Name SSN

Employee Student Dept Dorm Yrs GPA

Faculty Dean UnderGrad Grad Rank School Year Program Degree

Solution Utilizes Single InheritanceSolution Utilizes Single Inheritance Exactly One Parent for Each ClassExactly One Parent for Each Class Are we Done?Are we Done?


SW&OO-1.111

CSE300

Revising Example:Revising Example: Person Name SSN



Superclass,Superclass, Supertype, Parent, Base Class Supertype, Parent, Base Class Subclass,Subclass, Subtype, Child, Derived Class Subtype, Child, Derived Class Descendants, Ancestors, SiblingsDescendants, Ancestors, Siblings


SW&OO-1.112

CSE300

Subclass Acquires Subclass Acquires InformationInformation and/or and/or OperationsOperations of a Superclass of a Superclass

Inheritance is a Transitive Operation Inheritance is a Transitive Operation Behavior and Information of a Subclass is a Behavior and Information of a Subclass is a

Superset of its Ancestors Superset of its Ancestors SubclassSubclass is More Refined than Superclass - is More Refined than Superclass - its its

SpecializedSpecialized SuperclassSuperclass contains Common Characteristics of contains Common Characteristics of

its Subclasses - its Subclasses - its Generalizedits Generalized

Defining InheritanceDefining Inheritance

SW&OO-1.113

CSE300

Inheritance is Utilized when Two or More Classes Inheritance is Utilized when Two or More Classes are are Functionally and/or Informationally RelatedFunctionally and/or Informationally Related

In University Example, Common Data Basis of In University Example, Common Data Basis of Inheritance DecisionInheritance Decision

Other Bases for Inheritance could be:Other Bases for Inheritance could be: Common Methods Common Data and Methods

ReuseReuse Occurs from both Informational and Occurs from both Informational and Functional PerspectiveFunctional Perspective Information - No Replicated Variables Function - No Replicated Code

Defining InheritanceDefining Inheritance

SW&OO-1.114

CSE300

Develop Inheritance Hierarchies that areDevelop Inheritance Hierarchies that are Extensible Reusable Evolvable

In Budd, Chapter 7, Excellent Discussion onIn Budd, Chapter 7, Excellent Discussion on Utilization of Inheritance: How Benefits of Inheritance: Why Impact of Inheritance: Cost

We’ll Review this MaterialWe’ll Review this Material

The Role of InheritanceThe Role of Inheritance

SW&OO-1.115

CSE300

SpecializationSpecialization Most Common form of Inheritance to Refine

the Behavior of the SuperClass Differences are Pushed Down Hierarchy Allows Designers to Customize Classes

GeneralizationGeneralization Inverse of Specialization Commonalities of Multiple Classes are

Abstracted out to Form a SuperClass

Specialization and Generalization Specialization and Generalization InheritanceInheritance

SW&OO-1.116

CSE300

Examples from HTSSExamples from HTSSSpecialization and GeneralizationSpecialization and Generalization

Item / \ / \ NonPItem PerishItem / \ \ / \ \ DeliItem DairyItem ProduceItem

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(); };

GeneralizationSpecialization

SW&OO-1.117

CSE300

SpecificationSpecification 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

Specification Inheritance & ExampleSpecification Inheritance & Example

GraphicalObject / \ \ / \ \ Ball Wall Hole

Data-Oriented

Menu / \ / \PrintMenu SaveMenu

Function-Oriented

SW&OO-1.118

CSE300

ConstructionConstruction Subclass Inherits Majority of Functionality

from its Superclass Subclass may Extend, Limit, or Vary the

Functionality of Superclass

Construction Inheritance & ExampleConstruction Inheritance & Example

Dictionary / \ / \SymbolTable HashTable

LinkedList / \ \ / \ \Queue Set Stack

SW&OO-1.119

CSE300

VarianceVariance Classes have Similar Implementations but

Unrelated Abstract Views Result May Not Directly Aid Designer

Variance Inheritance & ExampleVariance Inheritance & Example

PointingDevice / \ \ / \ \TouchPad Mouse Tablet Key Issues

• Share Common Abstraction• Different Implementations• Methods in TouchPad, Mouse, etc., Override Methods in PointingDevice

SW&OO-1.120

CSE300

CombinationCombination Use of Multiple Inheritance Combines Two

or More Parents Allows Designers to View Design from

Different Perspectives

Combination Inheritance & ExampleCombination Inheritance & Example

Faculty Student \ / \ / TeachingAsst

MeatItem ProduceItem \ / \ / DelItem

SW&OO-1.121

CSE300

ExtensionExtension New Abilities are Added to Subclass Allows Designers to Reuse Prior Designs Requires Method(s) of Superclass to be

Overridden

Extension Inheritance & ExampleExtension Inheritance & Example

Window / \ / \FixedColorW VarColorW |BWWindow Key Issues

• Going from 1 to 2 Colors FixedColorW - BWWindow• Expanding Capabilities

SW&OO-1.122

CSE300

LimitationLimitation Subclass has more Restricted Behavior Typically to Extend Existing Class Library Inverse of Extension Also Supports Design Reuse

Limitation Inheritance & ExampleLimitation Inheritance & Example

Key Issues• Going from Two-Direction Queue to Ltd. Abstractions• Limiting Functionality

DEQueue / \ / \ Queue Stack / \LIFO FIFO

SW&OO-1.123

CSE300

Software ReusabilitySoftware Reusability Inherited Characteristics Often Represents

Compiled and Tested Code/Behavior Reuse in Future Products Design and Program Families

Design and Code SharingDesign 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

Benefits of InheritanceBenefits of Inheritance

SW&OO-1.124

CSE300

Software ComponentsSoftware Components Promotes the Concept of Reusable

Components and Software Factory Combine Rather than Construct JavaBeans and APIs, Ada95 Packages, etc.

Rapid PrototypingRapid Prototyping Utilization of Reusable Components Incremental Design and Development Delivery of Multiple Prototypes Faster to Market

All Benefits Apply to Design, Development, and All Benefits Apply to Design, Development, and Maintenance! Maintenance!

Benefits of InheritanceBenefits of Inheritance

SW&OO-1.125

CSE300

Execution SpeedExecution Speed Compile-Time Overhead Due to Inheritance Many Decisions Related to Inheritance Must

Occur at Runtime We’ll Explore this Shortly

Program SizeProgram Size Libraries are Large, and if Only Static Linking,

Size Grows Good News: Dynamic Linking Techniques are

Improving Improve Runtime Environment

Platform IndependencePlatform Independence (Java) Impacts both (Java) Impacts both Speed and Size Speed and Size

The Cost of InheritanceThe Cost of Inheritance

SW&OO-1.126

CSE300

Message Passing OverheadMessage 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 Program Complexity

For Any New Paradigm, Software Engineers Must Acquire Appropriate Skills

Despite HW Increases, Software Size and Complexity Continues to Grow!

The Cost of InheritanceThe Cost of Inheritance

SW&OO-1.127

CSE300

The Ability to Define Two or More Methods with The Ability to Define Two or More Methods with the Same Names and Different Signaturesthe 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 OO Design and Programming Allows us to Define our own Types (Classes) our own Types (Classes) Overload Operations (+, -, *, ++, etc.) Overload Methods

OverloadingOverloading

SW&OO-1.128

CSE300

Overloading in a Stack ExampleOverloading in a Stack Example

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); // Creates a char Stack with 10 Slots stack S2; // Default, no Parameter Supplied // Creates a char Stack with 100 Slots // Size of S2 Might not be Known to User!}

20 15 10 5

20 15 10 5

S1S1

S2S2 … etc ...

SW&OO-1.129

CSE300

Overloading in HTSOverloading in HTS

class Item { private: int UPC, OnShelf, InStock, ROLimit; // Etc... As Previously Givenpublic: 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.130

CSE300

Message PassingMessage Passing Method is a Member Function Message Passing: Invoking a Method receiverObject.MemberFunctionName(

Automatic VariablesAutomatic Variables Created within Function/Released at End Stack-Based Allocation No User Control/Intrevention

Dynamic VariablesDynamic Variables Created on Demand by Explicit Invocation Heap-Based Allocation May Require Memory Management

Why are A/D Variables Important to Design?Why are A/D Variables Important to Design?

Important Implementation ConceptsImportant Implementation Concepts

SW&OO-1.131

CSE300

LifetimeLifetime: Execution Period that Space Must : Execution Period that Space Must Remain Allocated to VariableRemain Allocated to Variable

ScopeScope: Portion of Program in Which Variable May : Portion of Program in Which Variable May Appear and be UtilizedAppear and be Utilized

Immutable ValuesImmutable Values: Assigned Once, Can’t Change: Assigned Once, Can’t Change Constants Known at Compile Time Immutable Values Set at Runtime (UPC Code)

Typing of VariablesTyping of Variables Static (Compile): C++, Java, Ada95 Dynamic (Runtime): Smalltalk, Lisp, …

Strongly-Type LanguagesStrongly-Type Languages (Ada95 and Java) (Ada95 and Java) Language Does Not Allow Variable of One

Type to hold Value of Different Type


SW&OO-1.132

CSE300

Static Binding:Static Binding: Method Bound to Message Based Method Bound to Message Based on Characteristics of Variableon Characteristics of Variable SE Must Track Type of Object Method Looked-Up at Compile Time Compile Detects Inappropriate Method Calls

Dynamic Binding:Dynamic Binding: Method Bound to Message Method Bound to Message Based on Characteristics of Value (Object)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 BindingLate Binding: Matching Message Invoked to : Matching Message Invoked to Correct Method at RuntimeCorrect Method at Runtime


SW&OO-1.133

CSE300

Remaining Object-Oriented ConceptsRemaining Object-Oriented Concepts

PolymorphismPolymorphism Definition and Illustration Attainment and Benefits

GenericsGenerics Type-Parameterizable Classes Examples using C++

Concepts that Impact Design and DevelopmentConcepts that Impact Design and Development Substitutability Mutability Specialization via Constraints Material from “Fundamentals of Object-

Oriented Databases”, pgs. 1-34, Zdonik/Maier.

SW&OO-1.134

CSE300

Polymorphism is the Ability of a Variable to Polymorphism is the Ability of a Variable to Hold more than One Type of Value, e.g., Hold more than One Type of Value, e.g., Subtypes of a Common Parent Subtypes of a Common Parent

Defining PolymorphismDefining Polymorphism

Variables P: Person; F: Faculty; S: Student;

//Supertype can Hold Instance of//Subtype, but NOT REVERSE!

P = F; // Treat Faculty as PersonP = S; // Treat Student as Person

P

F S

SW&OO-1.135

CSE300

Polymorphism via Dispatching Allows a Polymorphism via Dispatching Allows a Runtime Runtime oror Dynamic Choice Dynamic Choice of the Method to be Called of the Method to be Called based on the Class based on the Class TypeType of the Invoking Instance of the Invoking Instance

Concept is only Useful in the Context of Concept is only Useful in the Context of Inheritance Inheritance

Benefits of Polymorphism/Dispatching: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

OverheadOverhead at both Compile and Runtime! at both Compile and Runtime!

Definition of Polymorphism/DispatchingDefinition of Polymorphism/Dispatching

SW&OO-1.136

CSE300

Consider Previous ExampleConsider Previous Example Person Name SSN



Define Define Print_InfoPrint_Info Method for Each Class Method for Each Class Can CorrectCan Correct Print_InfoPrint_Info MethodMethod be Called be Called

Automatically Based on Automatically Based on Type of Instance Type of Instance VariableVariable?

Illustrating Polymorphism/DispatchingIllustrating Polymorphism/Dispatching

SW&OO-1.137

CSE300


P

E S

F D U G

What’s TrueWhat’s TrueAbout EachAbout Each

Person?Person?

SteveSteveLoisLois

TomTom MaryMary

EdEd

Person Object RepositoryPerson Object Repository

““Faculty”Faculty”

“ “Dean”Dean”““UnderGrad”UnderGrad”

““Graduate”Graduate”


SW&OO-1.138

CSE300

Print_InfoPrint_Info Methods Defined as Follows: 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.139

CSE300


Suppose Iterate Through Suppose Iterate Through Instances of Person Instances of Person RepositoryRepository

For Each Instance, Call For Each Instance, Call Method Method Print_Info()Print_Info()

How Does One How Does One Determine the “Correct” Determine the “Correct” Method to Call?Method to Call?

What are the What are the Compile Time

Checks? Compile Time

Guarantee? Runtime Checks?

SteveSteveLoisLois

TomTom

MaryMary

EdEd

Person Object RepositoryPerson Object Repository


“ “Dean”Dean”

““UnderGrad”UnderGrad”

““Graduate”Graduate”


SW&OO-1.140

CSE300

Build a Build a Mixed List of InstancesMixed List of Instances of Differing of Differing Types that Share a Common Ancestor Types that Share a Common Ancestor

To Begin, Declare Variables: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 Define a LISTLIST Class of Class of PersonsPersons LISTLIST is a Collection Class that Allows a Set of

One or More Person Instances to be Stored LISTLIST is an OO Version of Linked List Define LISTLIST Methods for:

LIST::Add_Person(Person P);LIST::Add_Person(Person P); LIST::Print_A_Member();LIST::Print_A_Member();

Achieving Polymorphism/DispatchingAchieving Polymorphism/Dispatching

SW&OO-1.141

CSE300

LISTLIST Class has the Method Implementation Class has the Method Implementation

LIST::Print_A_Member(){ Calls Print_Info();}

Augment Variable Declarations with:Augment Variable Declarations with:PTR = POINTER TO CLASS FOR A LIST OF Persons;PTR -> LIST::Add_Person(GR1); //Add ‘Don’PTR -> LIST::Add_Person(UG1); //Add ‘Rich’PTR -> LIST::Add_Person(FA1); //Add ‘Steve’

PTRPTR Views All List Elements as PersonsViews All List Elements as Persons PersonPerson is is Common (Root) AncestorCommon (Root) Ancestor Shared by Shared by

All Classes in Inheritance Hierarchy!All Classes in Inheritance Hierarchy!


SW&OO-1.142

CSE300

Pictorially, a LIST of Persons is Created:Pictorially, a LIST of Persons is Created: +----------+ +----------+ +----------++----------+ +----------+ +----------+ | Person | | Person | | Person || Person | | Person | | Person | PTR PTR ->| |-->| |-->| |->| |-->| |-->| | | (Really | | (Really | | (Really || (Really | | (Really | | (Really | | | SteveSteve | | | | RichRich | | | | DonDon | | | | FacultyFaculty) | |) | |UndergradUndergrad)| |)| | Grad Grad) |) | +----------+ +----------+ +----------+

What Happens when What Happens when PTR->Print_A_Member()PTR->Print_A_Member()?? If PTRPTR Referencing ‘Steve’ Instance? If PTRPTR Referencing ‘Rich’ Instance? If PTRPTR Referencing ‘Don’ Instance?

When When PTR->Print_A_Member()PTR->Print_A_Member()is Called, Recall is Called, Recall that the that the Print_Info()Print_Info() Method is Invoked Method is Invoked


SW&OO-1.143

CSE300

Which Which Print_InfoPrint_Info Method is Invoked? Method is Invoked? The Runtime Environment Dynamically Chooses The Runtime Environment Dynamically Chooses

the Correct Method Based on Instance Typethe Correct Method Based on Instance Type When PTRPTR References ‘Steve’/Faculty

Instance then Faculty::Print_Info() When PTRPTR References ‘Rich’/UnderGrad

Instance then UnderGrad::Print_Info() When PTRPTR References ‘Don’/Grad Instance

then Grad::Print_Info() Runtime Environment will Also Check Ancestor Runtime Environment will Also Check Ancestor

Instances In Order to Find the Correct MethodInstances In Order to Find the Correct Method Correct Compilation Guarantees Method Will be Correct Compilation Guarantees Method Will be

Found at Runtime!Found at Runtime!

Execution/Runtime Sequence of Execution/Runtime Sequence of Polymorphism/DispatchingPolymorphism/Dispatching

SW&OO-1.144

CSE300

Focus on Extensibility!Focus on Extensibility! Easily Extend and Evolve the Class/Inheritance Easily Extend and Evolve the Class/Inheritance

Hierarchy as New Kinds of Items are NeededHierarchy as New Kinds of Items are Needed Extension/Evolution Occurs without Extension/Evolution Occurs without

Recompilation of Recompilation of PersonPerson Class Library Class Library For Example:For Example:

class Staff : public Employee { … } class Visitor : public Person { … } class Transfer : public Student { … }

Previous Previous LISTLIST Code Works without Modification Code Works without Modification Application that Creates Application that Creates PersonPerson Instances May Instances May

Need to be Modified and RecompiledNeed to be Modified and Recompiled

Benefits of Polymorphism/DispatchingBenefits of Polymorphism/Dispatching

SW&OO-1.145

CSE300

Classic Programming ProblemClassic 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?What do Generics Offer? A Type-Parameterizable Class Abstracts Similar Behavior into a Common

Interface Reusable and Consistent Class

Illustrate via C++ Illustrate via C++

GenericsGenerics

SW&OO-1.146

CSE300

A Generic Stack ClassA Generic Stack Class

template <class T> stack { private: T* st, 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 Slotsstack<char> S2; // Creates char Stack with 100 Slotsstack<Item> ItemDB(10000); // Stack of Grocery Items}

SW&OO-1.147

CSE300

A Generic Set ClassA Generic Set Class

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 SetSet<Item> ItemDB; // Creates an Item Set}

SW&OO-1.148

CSE300

Strong Strong Promotion of ReusePromotion of Reuse Develop Once, Use Often stackstack and SetSet Examples

Eliminate Errors and Inconsistencies Between Eliminate Errors and Inconsistencies Between Similar and Separate ClassesSimilar and Separate Classes Simplifies Maintenance Problems Focuses on Abstraction and Design

Promotes Correctness and Consistent Program Promotes Correctness and Consistent Program BehaviorBehavior Once Designed/Developed, Reused with

Consistent Results If Problems, Corrections in Single Location

Benefits of GenericsBenefits of Generics

SW&OO-1.149

CSE300

Fundamentals of OO DatabasesFundamentals of OO DatabasesArticle by Zdonik and MaierArticle by Zdonik and Maier

An Excellent Article on the Nature and An Excellent Article on the Nature and Requirements for a Database System to be OORequirements for a Database System to be OO

Discussion from a Combined Programming and Discussion from a Combined Programming and Database ViewDatabase View

Essential and Frequent Features - Characterize Essential and Frequent Features - Characterize Minimal or Typical Database RequirementsMinimal or Typical Database Requirements

The Threshold Model Proposes a Set of Minimum The Threshold Model Proposes a Set of Minimum Requirements to be Characterized as OODBSRequirements to be Characterized as OODBS

To Extend from OODBS to OODBS+PLS, Four To Extend from OODBS to OODBS+PLS, Four Critical Concepts Must beSupportedCritical Concepts Must beSupported

Resulting Reference Model Encompasses the Resulting Reference Model Encompasses the Requirements of both OODBS and OOPLSRequirements of both OODBS and OOPLS

Final Comment on Typing IssueFinal Comment on Typing Issue

SW&OO-1.150

CSE300

Essential and Frequent FeaturesEssential and Frequent Features

Essential FeaturesEssential 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 FeaturesFrequent Features Integrity Constraints – Info. Consistency Authorization - Control Access and Visibility Querying - Access to Stored Information Separate Schema - Meta-Information

SW&OO-1.151

CSE300

The Threshold ModelThe Threshold Model

Includes Essential & First Two Frequent FeaturesIncludes Essential & First Two Frequent Features Requires Object Identity - Each Database Object Requires Object Identity - Each Database Object

Must be Identifyableand Distinguishable Must be Identifyableand Distinguishable Encapsulation (as We've Discussed) and Types Encapsulation (as We've Discussed) and Types

(Creation of New Types via System Class Library (Creation of New Types via System Class Library and User-Defined Type)and User-Defined Type)

Complex State - Objects MUST be Able to Refer Complex State - Objects MUST be Able to Refer to (or be Referred by) Other Objects (Promotes to (or be Referred by) Other Objects (Promotes Arbitrarily Complex Objects)Arbitrarily Complex Objects)

Inheritance (Not Included - But We Believe that Inheritance (Not Included - But We Believe that Without it, the Threshold Model Really Without it, the Threshold Model Really Characterizes Just an ADT Approach for DBS)Characterizes Just an ADT Approach for DBS)

Have Programming Issues Been Considered?Have Programming Issues Been Considered?

SW&OO-1.152

CSE300

Four Critical OO ConceptsFour Critical OO Concepts

Dispatching - We've Discussed This ExtensivelyDispatching - We've Discussed This Extensively Polymorphism - Type-Independent ClassesPolymorphism - Type-Independent Classes Typing Issues:Typing Issues:

Strong vs. Weak Dynamic vs. Static OODBS/OOPLS Offer Many Variants

Persistence – When are Instances Stored?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.153

CSE300

The Reference ModelThe Reference Model

Structured Representations for ObjectsStructured Representations for Objects Persistence by ReachabilityPersistence by Reachability Typing of Objects and VariablesTyping of Objects and Variables 3 Hierarchies for Specification of Types, 3 Hierarchies for Specification of Types,

Implementation of Data/Methods, and Implementation of Data/Methods, and Classification of ObjectsClassification of Objects

PolymorphismPolymorphism CollectionsCollections Name SpacesName Spaces Queries and IndexesQueries and Indexes RelationshipsRelationships VersionsVersions

SW&OO-1.154

CSE300

Final Comment on Typing IssuesFinal Comment on Typing Issues

Consider the Four Features of Subtyping: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 Claim: Only Three of Four Can Ever Exist in a Single Model!Single Model!

SW&OO-1.155

CSE300

Final Comment on Typing IssuesFinal Comment on Typing Issues

Consider the Four Features of Subtyping: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 Claim: Only Three of Four Can Ever Exist in a Single Model!Single Model!

SW&OO-1.156

CSE300

Recall that Recall that EmployeeEmployee is a Subclass of is a Subclass of PersonPerson Substitutability Allows Substitutability Allows EmployeeEmployee to be Utilized in to be Utilized in

any Context that any Context that PersonPerson is Permitted is Permitted Implications of SubstitutabilityImplications 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 AllowsPolymorphism/Dispatching Allows

Faculty, Grad, and UnderGrad to Substitute for Person

NonPItem, DeliItem, DairyItem, etc., to Substitute for Item

SubstitutabilitySubstitutability

SW&OO-1.157

CSE300

Mutability Allows an Instance to Dynamically Mutability Allows an Instance to Dynamically Change its Type within an Executing Application Change its Type within an Executing Application

Excellent Conceptual Example from CADExcellent 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 RulesMuting a Powerful Concept that Breaks Rules

MutabilityMutability

SW&OO-1.158

CSE300

Other FeaturesOther Features

Static Type Checking – CompilationStatic Type Checking – Compilation All Types Known All Decisions Made

Specialization via ConstraintsSpecialization via Constraints

Only Three out of Four Can Co-Exist….Only Three out of Four Can Co-Exist…. Adding Fourth Causes Contradiction…Adding Fourth Causes Contradiction…

PersonPerson

FacultyFaculty Student(BS/MS/PHD)Student(BS/MS/PHD)

Undergrad (BS)Undergrad (BS) Graduate (MS/PHD)Graduate (MS/PHD)

SW&OO-1.159

CSE300

How Does Contradiction Occur?How Does Contradiction Occur?

Specialization via Constraints with Set_Degree Specialization via Constraints with Set_Degree Method (see Previous Slide)Method (see Previous Slide)

Assume Static TC, Substitutability, and MutabilityAssume Static TC, Substitutability, and Mutability Suppose:Suppose:

Var S: Student;Var S: Student; U: Undergrad; U: Undergrad;S := U; // OK if Subst. and Mutab.S := U; // OK if Subst. and Mutab.Set_Degree (S, MS); //No Compile ErrorSet_Degree (S, MS); //No Compile Error

Runtime: Unless Static TC Weakend, the Wrong Runtime: Unless Static TC Weakend, the Wrong Set_Degree Operation will be ChosenSet_Degree Operation will be Chosen

SW&OO-1.160

CSE300

Concluding RemarksConcluding Remarks

Software Engineering has Long HistorySoftware Engineering has Long History Software Qualities Software Principles ADT and Object-Oriented Concepts

Component Based Design Strongly Influenced by Component Based Design Strongly Influenced by All of these andAll of these and Inheritance Polymorphism Dispatching Overloading Static and Dynamic Type Checking

SW&OO-1.1 CSE300 Software Engineering and Object-Oriented Design and Development Prof. Steven A. Demurjian, Sr. Computer Science & Engineering Department.

Documents

cse300 software engineering

term software engineering

large software applications

large software projects

outsourcing software

different types of software

customized new software

large slide