UTECA 3/26/99 CSE.RU-1.1 Object-Oriented Design Methodology to Facilitate Reuse Prof. Steven A....

UTECA

3/26/99

CSE.RU-1.1

Object-Oriented Design Methodology to Object-Oriented Design Methodology to Facilitate ReuseFacilitate Reuse

Prof. Steven A. Demurjian and Dr. Margaretha W. Price†

Computer Science & Engineering DepartmentThe University of Connecticut

191 Auditorium Road, Box U-155Storrs, CT 06269-3155

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

~steve(860) 486 - 4818

† M. Price is a Senior Engineer at Raytheon Electronic Systems in RI.

UTECA

3/26/99

CSE.RU-1.2

MotivationMotivation

Reuse Afterthought in OO Design/DevelopmentReuse Afterthought in OO Design/Development Majority of Reuse Focuses on “Small” Majority of Reuse Focuses on “Small”

ComponentsComponents String Functions, Utility Routines, GUI, etc. Easy to Understand - Easy to Reuse Minimal Savings

Three Classes of Software Three Classes of Software Domain-Independent (20%): Libraries,

Utilities, etc. Most Likely to Be Reused Domain-Specific (65%): Dedicated Software

Reused in Other Programs of Same Domain Application-Specific (15%): Uniqueness

Unlikely to Be Reused

UTECA

3/26/99

CSE.RU-1.3

MotivationMotivation

Popular OO Design Methodologies Omit and Popular OO Design Methodologies Omit and Ignore Reuse GuidelinesIgnore Reuse Guidelines OMT and UML Design Patterns

Current Research Concentrates on Current Research Concentrates on ConsumerConsumer (Reuser) and Not (Reuser) and Not ProducerProducer (Creator) (Creator) Measure Savings from Reuse Calculate Return on Investment

Two-Fold GoalTwo-Fold Goal Elevate Reuse to Equal Partner Starting with

Design Focus on Domain-and-Organization Specific

Reuse

UTECA

3/26/99

CSE.RU-1.4

ObjectivesObjectives

Reuse as Equal Partner Starting with DesignReuse as Equal Partner Starting with Design Iterative Reusability Evaluations at Early and

All Stages of Design and Development Production of Large Reusable Components

Capabilities of Evaluation TechniquesCapabilities of Evaluation Techniques Identify the Reusable Portions of Design Estimate/Measure Reusability Automatically Provide Guidelines on Improving Reusability Usable for

Newly Created Designs Evaluation of Legacy Code for Reuse Potential

Integrated in a Design/Development Environment

UTECA

3/26/99

CSE.RU-1.5

ObjectivesObjectivesDesign and Implementation ProcessDesign and Implementation Process

1. Define Components, Their 1. Define Components, Their Interactions, and Analyze Interactions, and Analyze Their ReusabilityTheir Reusability

2. Store an Iteration of Design2. Store an Iteration of Design3. Implement an Iteration3. Implement an Iteration4. Store and Document 4. Store and Document

Iteration of ImplemenIteration of Implemen..5. Reevaluate an Existing 5. Reevaluate an Existing

Design forDesign for Correcting Errors New Reuse Potential

6. Reuse Existing Design with 6. Reuse Existing Design with a New Implementationa New Implementation

Store &DocumentDesigns

ReusabilityEvaluation

Implementthe System

Re(Design)a System

Store &DocumentImplemens.

11

55

44

66 33

22

UTECA

3/26/99

CSE.RU-1.6

Overview of PresentationOverview of Presentation

Cultural and Social Reuse IssuesCultural and Social Reuse Issues Subjective Identification of ComponentsSubjective Identification of Components

General vs. Specific Classes Related Hierarchies to Quantify Components Financial Frame and HTSS Applications

Objective Measure of DependenciesObjective Measure of Dependencies Classifying Dependencies Measuring Reuse Potential

Reuse GuidelinesReuse Guidelines Methodological Basis for Increasing Reuse Iterative Improvement in Reusability

Evaluation and Analysis: Evaluation and Analysis: DRE Tool/ExamplesDRE Tool/Examples Conclusions and Future ResearchConclusions and Future Research

UTECA

3/26/99

CSE.RU-1.7

Cultural and Social Reuse IssuesCultural and Social Reuse IssuesManagement SupportManagement Support

Motorola Study: A New Reuse Program Must have Motorola Study: A New Reuse Program Must have Strong/Unequivocal Management SupportStrong/Unequivocal Management Support

Raytheon Report: Support from Upper Raytheon Report: Support from Upper Management Most Important for Successful ReuseManagement Most Important for Successful Reuse

Why? Increased...Why? Increased... Cost Associated with Constructing Reusable

Components Communication and Coordination Education and Training

Motorola and Raytheon Facilitate by IncentivesMotorola and Raytheon Facilitate by Incentives Both Producer and Consumer Benefits Awards Provided for Demonstrated Efforts

UTECA

3/26/99

CSE.RU-1.8

Cultural and Social Reuse IssuesCultural and Social Reuse IssuesHigh Initial CostHigh Initial Cost

Reports have IndicatedReports have Indicated High Start Up Costs Slow Return on Investment (> 3 years)

Best Success inBest Success in Starting with Small Projects Distributing Components for Reuse Opportunistic Reuse

Reuse Must be Supported byReuse Must be Supported by Libraries to Collect, Classify, and Disseminate

Components Ease of Use for Producer and Consumer

UTECA

3/26/99

CSE.RU-1.9

General/Specific ClassGeneral/Specific Class CharacterizationCharacterization

Subjective Characterization by Software DesignerSubjective Characterization by Software Designer Best Estimate on Potential Utility of ClassBest Estimate on Potential Utility of Class General Class (G)General Class (G)

Those Application Classes that Facilitate Domain-and-Organization Specific Reuse

Specific Class (S)Specific Class (S) Those Application Classes that are Limited to

use in a Single Application PurposesPurposes

Determine Classes with Highest Reuse Potential for Organization’s Future Systems

Dependencies from General to Specific are both Non-Reusable and Hinder Reuse

UTECA

3/26/99

CSE.RU-1.10

General/Specific ClassGeneral/Specific Class CharacterizationCharacterization

General Class (G)General Class (G) Expected to be Reused in Future Applications Abstract Classes/Root Classes/Non-Leaf

Classes in Inheritance Hierarchies Domain Independent/Domain Specific What are Some Examples?

Specific Class (S)Specific Class (S) Only Applicable in Current Applications Unlikely to be Reused in Future Applications Classes that Retrieve from Company Database Application Specific What are Some Examples?

UTECA

3/26/99

CSE.RU-1.11

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 Lecture

UTECA

3/26/99

CSE.RU-1.12

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 IL: Item LocatorLocator

CR: Cash RegisterCR: Cash RegisterIC: Invent. ControlIC: Invent. Control

DO: Deli Orderer forDO: Deli Orderer for Shopper/EmployeeShopper/Employee

UTECA

3/26/99

CSE.RU-1.13

A General Class in HTSSA General Class in HTSS

Why is Why is ItemItem General? General? What is Applicability of What is Applicability of ItemItem??

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

UTECA

3/26/99

CSE.RU-1.14

Another General Class in HTSSAnother General Class in HTSS

Collection Classes of General Classes are General Collection Classes of General Classes are General

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

UTECA

3/26/99

CSE.RU-1.15

Yet Another General Class in HTSSYet Another General Class in HTSS

GUI-Based Class for Supporting Inventory GUI-Based Class for Supporting Inventory Control Actions Can be Domain IndependentControl Actions Can be Domain Independent

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

UTECA

3/26/99

CSE.RU-1.16

Specific Classes in HTSSSpecific Classes in HTSS

General Classes are Refined to Represent General Classes are Refined to Represent Particular Items, Yielding Specific ClassesParticular Items, Yielding Specific Classes

...

Item

DairyItemProduceItem DeliItem

DeliOrdererGUI

OrdererGUI

UTECA

3/26/99

CSE.RU-1.17

Levels of General ClassesLevels of General Classes

Not All General Classes Created EquallyNot All General Classes Created Equally Level of Generality Based on Role in ApplicationLevel of Generality Based on Role in Application

PurposesPurposes Accommodate Large Systems with Multiple,

Different Reusable Components Reusable Components can Overlap, but Still be

Distinct Reusable Units

S,...,G,G,G 2100G

2G0G 0G

1G

2G SS

SS1G

views as General if i j views as Specific if i < j

iG jG

jGiG

UTECA

3/26/99

CSE.RU-1.18

...

Extended Hierarchy with Extended Hierarchy with More Levels of GeneralityMore Levels of Generality

DairyItem DeliItem

Item

ProduceItem

NonPerishItem PerishItem

)(G0

)(G1 )(G1

)(G2)(G2

BigYProdItem DoleProdItem BigYDairyItem HoodDairyItem

Where can ItemWhere can Itembe Reused?be Reused? Where can Where can

NonPerishItem NonPerishItem and PerishItemand PerishItembe Reused?be Reused?

Where can ProduceItem and Where can ProduceItem and DairyItem be Reused?DairyItem be Reused?

Are DoleProdItem and HoodDairyItem Specific?Are DoleProdItem and HoodDairyItem Specific?

UTECA

3/26/99

CSE.RU-1.19

General/Specific Paradigm in HTSSGeneral/Specific Paradigm in HTSS

Abstraction from Abstraction from HTSSHTSS to to Domain IndependentDomain Independent Inventory Control ApplicationInventory Control Application

Separation of Supermarket Domain SpecificsSeparation of Supermarket Domain Specifics Leverage Commonalties for Leverage Commonalties for

Focused, Independent Design/Development Future Products

RelevanceRelevance Domain-and-Organization-Specific Reuse Expand to 24 hour Mom & Pop Stores Expand to Other Retail Markets

E.g., Auto parts, Clothing, Toy, etc.

UTECA

3/26/99

CSE.RU-1.20

Defining Component ConceptsDefining Component Concepts

A A ComponentComponent is Composed of One or More is Composed of One or More Classes (or Other Components) and is Intended to Classes (or Other Components) and is Intended to Support a “Constructed” Unit of Functionality Support a “Constructed” Unit of Functionality

ClassesClasses Can be Utilized in Can be Utilized in Multiple ComponentsMultiple Components A Class Utilized in Multiple Components A Class Utilized in Multiple Components

Maintains the “Maintains the “SameSame” ” SemanticsSemantics in All of its in All of its ContextsContexts

Our Interest Involves:Our Interest Involves: Reusable Classes Thru Reusable Components A Reusable Component Consists of Classes

and/or Other Components that are Expected to be Reused Together in Future Applications

UTECA

3/26/99

CSE.RU-1.21

Related Classes and HierarchiesRelated Classes and Hierarchies

Class X is Related to Class YClass X is Related to Class Y if they are Related if they are Related and Concept and are and Concept and are Expected to be ReusedExpected to be Reused TogetherTogether in Future Systems in Future Systems

Class X Related to Class Y is Class X Related to Class Y is Subjectively Subjectively AssignedAssigned by Software Engineer (Producer) by Software Engineer (Producer)

When Class X is Related to Class YWhen Class X is Related to Class Y X and All of X’s Descendants are Related to

Y and All of Y’s Ancestors Thus, to Reuse X or X’s Descendants, you

Must Reuse B and All of B’s Ancestors Class X Related to Y if Y at Same or Higher

Level! Related Classes Promote Reuse, Since They are Related Classes Promote Reuse, Since They are

Expected to be Reused TogetherExpected to be Reused Together

UTECA

3/26/99

CSE.RU-1.22

Related Hierarchies/Reusable Related Hierarchies/Reusable ComponentsComponents

Two Sub-Hierarchies are Related if to Reuse One, you Must Reuse the OtherTwo Sub-Hierarchies are Related if to Reuse One, you Must Reuse the Other Purpose: Purpose: Identify Reusable Dependencies Among Related ClassesIdentify Reusable Dependencies Among Related Classes

Reusable Component: Reusable Component: A Set of Related Classes that are Expected to be Reused as a GroupA Set of Related Classes that are Expected to be Reused as a Group A Related BA Related B Defines Reusable Component! Defines Reusable Component!

0G

0G 0G

SS0G

0G

SS0G

SS

A Sub-Hierarchies BA Sub-Hierarchies B

RR

UTECA

3/26/99

CSE.RU-1.23

Related Characterization in Related Characterization in Levels of Components - HTSSLevels of Components - HTSS

Item


)(G0

)(G1 )(G1

Environ )(G1RR

DairyItemProduceItem DeliItem SubZero RTemp

What is Related Given What is Related Given RR as Shown? as Shown? PerishItem and Item (All Ancestors) Environ, SubZero, and Rtemp (All Descends.)

Does Does RR from Environ to PerishItem Make Sense? from Environ to PerishItem Make Sense? Should Should RR be from PerishItem to Environ? be from PerishItem to Environ?

UTECA

3/26/99

CSE.RU-1.24

Related Characterizations in Related Characterizations in Levels of Components - HTSSLevels of Components - HTSS

Where do Changes for Other Domains Occur?Where do Changes for Other Domains Occur?

Specific Applications for Big Y or Shaw’s or Stop/Shop (S)

Root classes for Items, ItemDB, etc., which are Most General.

Inventory Control/Other Components.

Classes Specific to Grocery Store Domain.

)(G0

)(G1

)(G2

UTECA

3/26/99

CSE.RU-1.25

Reusability in HTSS DomainReusability in HTSS Domain



Inventory ControlOther Components.

Classes Specific to Grocery Store Domain.

)(G0

)(G1

)(G2

Inventory Control Tool for Ordering Items from Suppliers

Cost Accounting Tool for Tracking Net and Gross Profit

UTECA

3/26/99

CSE.RU-1.26

Reusability in HTSS DomainReusability in HTSS Domain



Inventory Control/Other Components.

Classes Specific to Grocery Store Domain.)(G0

)(G1)(G2

Classes forLargeSupermarket

Classes forSpecialtySupermarket

Classes for24 HourConvenience

UTECA

3/26/99

CSE.RU-1.27

What are Dependencies Among Classes?What are Dependencies Among Classes?

Object InclusionObject Inclusion: : Class Contains a Instance of Class Contains a Instance of Another ObjectAnother Object

Attribute DefinitionAttribute Definition: : Class Contains Attribute that Class Contains Attribute that is the Type of Another Objectis the Type of Another Object

Method InvocationMethod Invocation: : Class Invokes a Method Class Invokes a Method Defined on Another ObjectDefined on Another Object

GoalsGoals Classify and Understand Dependencies Assess “Good” vs. “Bad” Dependencies Change “Bad” to “Good” by

Changing Class from S to G or G to S Moving Code and/or Method Calls Splitting a Class into Two Classes Merging Two Classes

UTECA

3/26/99

CSE.RU-1.28

Reusing Sub-Hierarchies in Reusing Sub-Hierarchies in Different Components - HTSSDifferent Components - HTSS

Will be reused with Componentsfor another domain,e.g., Toy Store

Will be reused with Componentsfor different Super-market Companies

Item

...DairyItemProduceItem DeliItem


Dependencies Among General Related Classes Dependencies Among General Related Classes Represents Valuable Design KnowledgeRepresents Valuable Design Knowledge

UTECA

3/26/99

CSE.RU-1.29

Which Dependencies in HTSSWhich Dependencies in HTSSare Problematic?are Problematic?

Environ )(G1

RRItem

DairyItemProduceItem DeliItem


Impact of Dependencies from Impact of Dependencies from ItemItem to to EnvironEnviron?? Must Reuse Environ When Reuse Item Must Reuse Environ in “Blue” Component!

UTECA

3/26/99

CSE.RU-1.30

Evaluative Metrics and MethodologyEvaluative Metrics and MethodologyObjective Measures of DependenciesObjective Measures of Dependencies

Object-Oriented Design: Object-Oriented Design: Collection of General and Specific Classes, with Related Characterizations

Quantify Dependencies for ReuseQuantify Dependencies for Reuse Good: Promotes Reuse - Leave Alone Bad: Hinders Reuse - Try to Change Okay: No Impact on Reuse

Goals:Goals: Given General/Specific Components and

Related Components Classify and Understand Dependencies Measure Reuse Potential Revise Design in Iterative Manner Use Throughout Design/Development Process

UTECA

3/26/99

CSE.RU-1.31

Dependencies Among Related ClassesDependencies Among Related Classes

Remember, G/S are Subjectively Assigned by Remember, G/S are Subjectively Assigned by Software DesignerSoftware Designer

The Two G classes are Related The Two G classes are Related Related Classes are Intended to be Reused Related Classes are Intended to be Reused

TogetherTogetherGood (1)

G

S

G

SOkay (5)

Okay (7)

Bad (3)

UTECA

3/26/99

CSE.RU-1.32

Sample Dependencies in HTSSSample Dependencies in HTSS

InvCont

DeliIC

Item

DeliItem

Good (1)

Okay (5)

Okay (7)

Bad (3)

InvCont and Item are Related InvCont and Item are Related ClassesClasses

InvCont to Item Dependencies InvCont to Item Dependencies are Good: Reused Togetherare Good: Reused Together

Dependency from InvCont to Dependency from InvCont to DeliItem is ProblemDeliItem is Problem Don’t Want to Reuse

DeliItem with InvCont ManagerGUI with InvCont

Includes Useless DeliItem Dependencies from DeliIC to Dependencies from DeliIC to

Item and/or DeliItemItem and/or DeliItem Don’t Impact Reuse Can Reuse Item and

DeliItem w/o DeliIC

UTECA

3/26/99

CSE.RU-1.33

Dependencies Among Non-Related Dependencies Among Non-Related ClassesClasses

Remember, G/S are Subjectively Assigned by Remember, G/S are Subjectively Assigned by Software DesignerSoftware Designer

The Two G Classes are Not RelatedThe Two G Classes are Not Related Non-Related ClassesNon-Related Classes are are NOT NOT Intended to be Intended to be

Reused TogetherReused Together

Okay (6)

Okay (8)

G

S

G

S

Bad (2)

Bad (4)

UTECA

3/26/99

CSE.RU-1.34

Sample Dependencies in HTSSSample Dependencies in HTSS

InvCont

DeliIC

Person

Shopper

Bad(2)

Okay (6)

Okay (8)

Bad (4)

InvCont and Person are Classes InvCont and Person are Classes that are Not Relatedthat are Not Related

InvCont to Person or Shopper InvCont to Person or Shopper Dependencies are BadDependencies are Bad Don’t Want to Reuse

Person/Shopper with InvCont

Must Reuse - Problem! Dependencies from DeliIC to Dependencies from DeliIC to

Person and/or ShopperPerson and/or Shopper Don’t Impact Reuse Can Reuse Person and

Shopper w/o DeliIC However, Poor Design if

DeliIC Needs Person or Shopper!

UTECA

3/26/99

CSE.RU-1.35

Summarizing Dependencies andSummarizing Dependencies andActions to Improve ReusabilityActions to Improve Reusability

Coupling Among Related Among Unrelated

G G Type (1)Good for Reuse

Type (2)Bad for ReuseMove Src./Dst. to Specific

G S Type (3)Bad for ReuseMove Dst. to General

Type (4)Bad for ReuseMove Src. To Specific

S G Type (5)Can Improve if MoveSrc. to General

Type (6)No Impact on Reuse

S S Type (7) - Can Improveif Move Src./Dst. to Gen.

Type (8)No Impact on Reuse

UTECA

3/26/99

CSE.RU-1.36

Dependencies in Levels of ComponentsDependencies in Levels of ComponentsSummarizing Related ClassesSummarizing Related Classes

0G

1G

2G

0G

1G

2G

(1)

(3)

(3)

0G

1G

2G

0G

1G

2G

(5)

(7)

(7)

0G

1G

2G

0G

1G

2G (1)

(1)

(1)

0G 0GRelated to2G 2GRelated to

Similar Diagram for Dependencies Among Similar Diagram for Dependencies Among Unrelated ClassesUnrelated Classes

UTECA

3/26/99

CSE.RU-1.37

Reuse GuidelinesReuse Guidelines

Methodological Basis for Increasing ReuseMethodological Basis for Increasing Reuse Designer Supplies General/Specific/Related for

the Classes/Hierarchies in Application Reuse Analysis Tool Calculates Couplings and

Identifies Types of Reuse (Good, Bad, Okay) Ideal Result: Maximize Reuse via CouplingsIdeal Result: Maximize Reuse via Couplings

Type 1: G to G for Related Classes Type 8: S to S for Non-Related Classes

Extended Guidelines: Menu of ChoicesExtended Guidelines: Menu of Choices Different Ways to Move Couplings Considers Impact of Movement on Design

Goal: Iterative Improvement in ReusabilityGoal: Iterative Improvement in Reusability

UTECA

3/26/99

CSE.RU-1.38

Core Guidelines to Move Couplings to Core Guidelines to Move Couplings to Increase Reuse PotentialIncrease Reuse Potential

G

S

G

S

Type 2

Type 8

G

S

G

S

Type 4

Type 8

G

S

G

S

Type 5

Type 1 G

S

G

SType 7

Type 1

Type 1G

S

G

S

Type 3

G

S

G

SType 7

UTECA

3/26/99

CSE.RU-1.39

Extended Guidelines for Extended Guidelines for Improving ReusabilityImproving Reusability

Core Guidelines Emphasize Local BehaviorCore Guidelines Emphasize Local Behavior To Remove “Bad” or Improve “Okay” Coupling, To Remove “Bad” or Improve “Okay” Coupling,

Move Cause of the Coupling (e.g., Method Call)Move Cause of the Coupling (e.g., Method Call) Moving a General Method to Specific Class Moving a Specific Method to General Class

Moving Method Up/Down a Hierarchy, Which Moving Method Up/Down a Hierarchy, Which Alters the Coupling, Alters the Coupling, Can Impact ElsewhereCan Impact Elsewhere

Expand the Analyses to Other Couplings of the Expand the Analyses to Other Couplings of the Source and Destination of the Bad Coupling Source and Destination of the Bad Coupling Couplings to Source when Moving Down Couplings to Destination when Moving Up

Extended Guidelines: Menu of ChoicesExtended Guidelines: Menu of Choices

UTECA

3/26/99

CSE.RU-1.40

Extended Guidelines to Improve ReuseExtended Guidelines to Improve ReuseIdentifying the ProblemIdentifying the Problem

S

G

S m()

G G

Type 7

G

S

G

S

Type 3

Type 7

Recall

G

S

G

S

m()G Type 3

Suppose

What has Occurred?

UTECA

3/26/99

CSE.RU-1.41

Extended Guidelines to Improve ReuseExtended Guidelines to Improve ReuseIdentifying the ProblemIdentifying the Problem

S

G

S m()

G G

Type 5

Suppose

What has Occurred?

G

S

G

S

m()G

Type 1

G

S

G

S

Type 5

Type 1

Recall

Type 3

UTECA

3/26/99

CSE.RU-1.42

Problem and SolutionProblem and Solution

Focus on Core Guidelines May Ignore the Impact Focus on Core Guidelines May Ignore the Impact of a Change for Other Related and Coupled Classesof a Change for Other Related and Coupled Classes

When a Coupling is Moved from a G to S ClassWhen a Coupling is Moved from a G to S Class Examine All Existing Coupling to G Class G to G Coupling Now G to S

Likewise, When a Coupling Moved from S to G Likewise, When a Coupling Moved from S to G Examine All Existing Coupling to S Class S to S Coupling Now S to G

Both Cases Introduce “Bad” Coupling!Both Cases Introduce “Bad” Coupling! Solution: Extended Guidelines to Govern all Solution: Extended Guidelines to Govern all

Potential Scenarios for Removing “Bad” CouplingsPotential Scenarios for Removing “Bad” Couplings We’ll Example Type 3 Couplings Only!We’ll Example Type 3 Couplings Only!

UTECA

3/26/99

CSE.RU-1.43

Extended Guidelines for Extended Guidelines for Type 3Type 3 Couplings Couplings

Move Coupling Dst. to General ClassMove Coupling Dst. to General Classor Change Dst. To a General Classor Change Dst. To a General Class Type 3 to Type 1 May Introduce Couplings from G

Dst. to Specific Classes Move Coupling Src. to Specific ClassMove Coupling Src. to Specific Class

or Change Src. To a Specific Classor Change Src. To a Specific Class Type 3 to Type 7 May Introduce Couplings from

General Classes to Specific Src. Change to Non-Related/Follow Change to Non-Related/Follow Type 4Type 4 Detailed Evaluation of ImplementationDetailed Evaluation of Implementation Key ConcernsKey Concerns

Local Changes with Global Impact “Wrong” Choice Degrades Reuse

G

S

G

S

Type 3

Among Related

UTECA

3/26/99

CSE.RU-1.44

Removing Removing Type 3Type 3 Couplings in HTSS Couplings in HTSSWhich Changes Make Sense?Which Changes Make Sense?

InvCont

DeliIC

Item

DeliItem

Type 3

Change InvCont to S or DeliItem to GChange InvCont to S or DeliItem to G Neither Makes Sense Against Design Intent!

Move Coupling Dst. to General ClassMove Coupling Dst. to General Class Find Problem Method Call,

Attribute Access, Object Inclusion Move from DeliItem and Item Type 3 to Type 1

Move Coupling Src. to Specific ClassMove Coupling Src. to Specific Class Find Problem Method Call,

Attribute Access, Object Inclusion Move from InvCont and DeliIC Type 3 to Type 7

Detailed Evaluation of ImplementationDetailed Evaluation of Implementation Note: Maintain Application SemanticsNote: Maintain Application Semantics

Type 1

Type 7

UTECA

3/26/99

CSE.RU-1.45

Evaluation and AnalysisEvaluation and Analysis

Design Reusability Evaluation (DRE) ToolDesign Reusability Evaluation (DRE) Tool Java-Based Tool for Analyzing Reusability Takes C++, Ada95, and Java Code as Input Works with General/Specific/Related as

Subjectively Defined by Software Designer Analyzes Couplings to Identify, for Each Type

(1 to 8), the Number of Couplings Allows Designer to Investigate Cause of and

Correct “Bad” or Improve “Okay” Couplings DRE can be Utilized in Different WaysDRE can be Utilized in Different Ways

Evaluate Evolving Design/Implementation Investigate the Reusability of Legacy Code

Examples of Video Rental System/FinancialFrameExamples of Video Rental System/FinancialFrame

UTECA

3/26/99

CSE.RU-1.46

Utilizing Reuse MethodologyUtilizing Reuse MethodologyEvaluate Evolving Design/ImplementationEvaluate Evolving Design/Implementation Constructing New ApplicationsConstructing New Applications

Software Design Proceeds in Stages Today’s Norm: Incremental Development and

Rapid Prototyping General/Specific Classes/Related ComponentsGeneral/Specific Classes/Related Components

Assigned Initially as Classes are Generated Refined Throughout Increments/Versions G to S, S to G, etc. Related Components as Design Begins to

Mature with Additional Details Use Methodology to Find/Correct “Problems”

Video Rental System Test-Bed Video Rental System Test-Bed

UTECA

3/26/99

CSE.RU-1.47

Utilizing Reuse MethodologyUtilizing Reuse Methodology Investigate Reusability of Legacy Code Investigate Reusability of Legacy Code

Reusability of Legacy CodeReusability of Legacy Code Examine Legacy Code in Detail Talk/Contact Domain Experts with Corporate

Knowledge of Code General/Specific Classes/Related ComponentsGeneral/Specific Classes/Related Components

Take “Educated Guess” for G/S Classes and Related Components

Run DRE and Find/Correct Problems Re-evaluate Legacy Code with Different

“Educated Guesses” Compare/Contrast Results to Identify the “Best”

way to Characterize Classes/Components FinancialFrame as a Test-BedFinancialFrame as a Test-Bed

UTECA

3/26/99

CSE.RU-1.48

The Video Rental System (VRS)The Video Rental System (VRS)

VRS is for On-Line (Browser) Rental TapesVRS is for On-Line (Browser) Rental Tapes Maintains Customer and Video Databases Tracks Borrowing/Returning of Tapes Logs Rented Tapes CGI, C++, Netscape/Explorer From Video Rental to Auto Parts Undergraduate Project: Spring 1997 - VRS-1 Repeated as Grad Project: Fall 1998 - VRS-2

Goals:Goals: Demonstrate General/Specific/Related Ideas Incorporate/Reuse Design in Future System Study Effectiveness Approach in Identifying

and Removing Non-Reusable Dependencies

UTECA

3/26/99

CSE.RU-1.49

General and Specific Classes in VRS-1General and Specific Classes in VRS-1

VideoStoreInterface (S)

StoreInterface (G)

VideoCustomer (S)

Customer (G)

VideoCustomerInterface (S)

CustomerInterface (G)

VideoTape (S)

Item (G)

VideoTapeDB (S)

ItemDB (G)

RentedTapeDB (S)RentedTape (S)

CustomerDB (G)

HistoryList (G)

Transaction (G)

UTECA

3/26/99

CSE.RU-1.50

DRE DRE

UTECA

3/26/99

CSE.RU-1.51

DRE DRE

UTECA

3/26/99

CSE.RU-1.52

DRE DRE

UTECA

3/26/99

CSE.RU-1.53

DRE and VRS-1DRE and VRS-1Tracking Incremental VersionsTracking Incremental Versions

Type Metr I II III IV V VI VII

Good CC1 8 54 79 109 166 167 193

Bad CC2 0 0 0 0 0 0 0

Bad CC3 6 0 0 0 4 4 0

Bad CC4 0 0 1 1 0 0 0

Impr CC5 0 19 28 39 94 92 75

Impr CC6 0 6 6 18 28 30 25

Okay CC7 0 0 0 0 0 5 0

Okay CC8 0 0 11 11 21 22 26

LOC 410 1386 2088 2695 3784 3824 3867

UTECA

3/26/99

CSE.RU-1.54

General/Specific Classes in VRS-2General/Specific Classes in VRS-2and Related Characterizationsand Related Characterizations

VideoStoreInterface (S)

StoreInterface (G)

Customer (G)

CustomerInterface (G)

Video (S)

Item (G)

VideoItemList (S)

ItemList (G) ReportGenerator (S)

Transaction (G)

VideoTransaction (S)

CustomerList (G)

VideoCustList (S)

UTECA

3/26/99

CSE.RU-1.55

DRE and VRS-2DRE and VRS-2Tracking Incremental VersionsTracking Incremental Versions

Type Metr I II III IV

Good CC1 17 28 26 26

Bad CC2 0 0 0 0

Bad CC3 0 0 1 0

Bad CC4 0 0 0 0

Impr CC5 0 0 2 2

Impr CC6 0 0 3 4

Okay CC7 0 4 3 3

Okay CC8 0 0 0 0

G/STTLCls.

175/1

325/1

307/6

307/6

UTECA

3/26/99

CSE.RU-1.56

One Type 3 Coupling: G to S DependencyOne Type 3 Coupling: G to S Dependency

Transaction (G)

write_to_checkoutfile()write_to_checkoutfile()


Customer (G)

take_item( )

...tr->calculate_currentdate()tr->calculate_duedate()tr->write_to_historyfile()tr->write_to_checkoutfile()...

calculate_currentdate()calculate_duedate()write_to_historyfile()

• What is the Problem?What is the Problem?• How is it Resolved?How is it Resolved?

UTECA

3/26/99

CSE.RU-1.57

Resolving Type 3 G to S DependencyResolving Type 3 G to S Dependency

Customer (G)

take_item( )

Transaction (G)

write_to_checkoutfile()write_to_checkoutfile()


calculate_currentdate()calculate_duedate()write_to_historyfile()

...tr->calculate_currentdate()tr->calculate_duedate()tr->write_to_historyfile()take_item_specific()...

take_item_specific()take_item_specific()

VideoCustomer(S)

((VideoTransaction *) tr) -> write_to_checkoutfile()

UTECA

3/26/99

CSE.RU-1.58

The FinancialFrame ApplicationThe FinancialFrame Application

A Commercial C++ Framework Containing 441 A Commercial C++ Framework Containing 441 Classes, Proprietary of FinancialCompClasses, Proprietary of FinancialComp

Designed for Reuse in Various Financial Apps.Designed for Reuse in Various Financial Apps. Provides Basic Functionalities of Financial SystemProvides Basic Functionalities of Financial System FinancialFrame’s Challenge - Manage ChangesFinancialFrame’s Challenge - Manage Changes

Framework Constantly Evolving New Functions and Modify Existing Functions

Conceptual Relevance:Conceptual Relevance: Provide Realistic Context for Our Approach Domain-and-Organization-Specific Reuse

UTECA

3/26/99

CSE.RU-1.59

The FinancialFrame ApplicationThe FinancialFrame Application

Our Purpose: Work with Existing CodeOur Purpose: Work with Existing Code Establish General and Specific Classes Characterize Related Components Evaluate the Goodness of G/S Characterization

and Identify Potential Problem Areas General Components that are Specific Specific Components that are General

Problematic Relevance:Problematic Relevance: Demonstrate Ability of Approach to Localize

Effect of Changes Describe Ways to Increase FinancialFrame’s

Reuse Potential

UTECA

3/26/99

CSE.RU-1.60

General and Specific Classes in General and Specific Classes in FinancialFrameFinancialFrame

FinancialCompTrader )(G2

FinancialCompAccount )(G2

FinancialCompDesk )(G2

)(G0Main

FinancialCompMain OtherMain

SpecificFCMain (S) SpecificOtherMain (S)

)(G2 )(G2 ...

)(G0YieldModel

DiscountIndexBond )(G1 )(G1 Bill )(G1

)(G0CashFlowAnalyzer

...

UTECA

3/26/99

CSE.RU-1.61

ConclusionsConclusions

Comprehensive Reusability Model and EvaluationComprehensive Reusability Model and Evaluation General/Specific/Related Characterizations Capture/Analyze Reusability of OO Software Achieve Highest Gain Through Early

Identification and Reusability Evaluations! Methodology and Empirical VerificationMethodology and Empirical Verification

Guidelines to Encourage Reuse Applicable to Reuse of Designs and Code DRE Tool for C++, Ada95, Java Strong Demonstration of

Domain-and-Organization-Specific Reuse

UTECA

3/26/99

CSE.RU-1.62

Future ResearchFuture Research

The Future Directions of ReuseThe Future Directions of Reuse Changing Company Culture to Encourage Providing Sufficient Rewards for Utilization Cost and Time in Establishing Reuse Program Short-Term Costs vs. Long-Range Benefits

Future/Ongoing ResearchFuture/Ongoing Research Collaboration on Large-Scale “Real” Examples Integration of OO Reuse into UML and

Associated OO Design/CASE Tools Improvements and Enhancements to DRE Investigation of Reusable Component Tools/

Libraries that Log and Find “Best” Component

UTECA

3/26/99

CSE.RU-1.63

Related Research at UConnRelated Research at UConn

Enterprise Computing and InteroperabilityEnterprise Computing and Interoperability (Demurjian)(Demurjian)

Security Issues for Distributed and Agent-Based Security Issues for Distributed and Agent-Based ComputingComputing (Demurjian) (Demurjian)

Optimal Deployment of Distributed ObjectsOptimal Deployment of Distributed Objects (Demurjian/Shvartsman)(Demurjian/Shvartsman)

Risks and Benefits of JavaRisks and Benefits of Java (Demurjian/Shin) (Demurjian/Shin) Frameworks for Scalable Distributed ApplicationsFrameworks for Scalable Distributed Applications

(Shvartsman)(Shvartsman) Interoperability of Heterogeneous DatabasesInteroperability of Heterogeneous Databases (Shin) (Shin) Joint: Joint: Intelligent Distributed Component Appls.

Frameworks (Shvartsman, Demurjian, Santos)

UTECA

3/26/99

CSE.RU-1.64

Final Remarks and DiscussionFinal Remarks and Discussion

CSE Faculty Interested in Industrial InteractionsCSE Faculty Interested in Industrial Interactions Engineering MS Program Undergraduate Semester Projects

Storrs Senior Design Projects Graduate Student Research Assistantships Cooperative Research Funding Faculty Presentations and Seminars Industry Presentations (CSE Courses) Faculty Consulting (Summers/Sabbaticals)

UConn CSE Web Page:UConn CSE Web Page: www.engr.uconn.edu/cse

UTECA 3/26/99 CSE.RU-1.1 Object-Oriented Design Methodology to Facilitate Reuse Prof. Steven A....

Documents

Transcript of UTECA 3/26/99 CSE.RU-1.1 Object-Oriented Design Methodology to Facilitate Reuse Prof. Steven A....