Date post: | 22-Dec-2015 |
Category: |
Documents |
View: | 219 times |
Download: | 2 times |
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
Relating Software Engineering and Relating Software Engineering and Computer Science DisciplinesComputer Science Disciplines
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
Relating Software Engineering and Relating Software Engineering and Computer Science DisciplinesComputer Science Disciplines
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
Relating Software Engineering and Relating Software Engineering and Computer Science DisciplinesComputer Science Disciplines
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:
Abstract Data Types (ADTs)Abstract Data Types (ADTs)
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.
Abstract Data Types (ADTs)Abstract Data Types (ADTs)
SW&OO-1.60
CSE300
Consider the following Example Consider the following Example StackStack ADT: ADT:
Abstract Data Types (ADTs)Abstract Data Types (ADTs)
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
Categories of ClassesCategories of Classes((See Budd, Section 3.2, pg. 48))
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
Categories of ClassesCategories of Classes((See Budd, Section 3.2, pg. 48))
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
Categories of ClassesCategories of Classes((See Budd, Section 3.2, pg. 48))
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
Common Design FlawsCommon Design Flaws
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
Common Design FlawsCommon Design Flaws
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?
Motivating InheritanceMotivating Inheritance
SW&OO-1.111
CSE300
Revising Example:Revising Example: Person Name SSN
Employee Student Dept Dorm Yrs GPA
Faculty Dean UnderGrad Grad Rank School Year Program Degree
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
Motivating InheritanceMotivating Inheritance
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
Important Implementation ConceptsImportant Implementation Concepts
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
Important Implementation ConceptsImportant Implementation Concepts
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
Employee Student Dept Dorm Yrs GPA
Faculty Dean UnderGrad Grad Rank School Year Program Degree
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
Illustrating Polymorphism/DispatchingIllustrating Polymorphism/Dispatching
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”
““Faculty”Faculty”
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
Illustrating Polymorphism/DispatchingIllustrating Polymorphism/Dispatching
SW&OO-1.139
CSE300
Illustrating Polymorphism/DispatchingIllustrating Polymorphism/Dispatching
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
““Faculty”Faculty”
“ “Dean”Dean”
““UnderGrad”UnderGrad”
““Graduate”Graduate”
““Faculty”Faculty”
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!
Achieving Polymorphism/DispatchingAchieving Polymorphism/Dispatching
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
Achieving Polymorphism/DispatchingAchieving Polymorphism/Dispatching
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