A Framework, Methodology and Tool for Reusable Software Components

1
A Framework, Methodology and Tool for Reusable
Software Components
Prof. Steven A. Demurjian, Sr., Jeffrey R. Ellis,
Rodrigo Caballero, Felix Eickhoff, Shaikit Das,
and Xiaopei Wang Computer Science Engineering
Department The University of Connecticut Prof.
Donald M. Needham Computer Science
Department U.S. Naval Academy
steve_at_engr.uconn.edu jre95001_at_yahoo.com needham_at_us
na.edu http//www.engr.uconn.edu/steve (860) 486
- 4818
Work supported in part by a grant from Electric
Boat, Inc., Groton, CT.
2
Motivation

• Reuse Afterthought in OO Design/Development
• Majority of Reuse Focuses on Small Components
  with Minimal Savings
• String Functions, Utility Routines, GUI, etc.
• Easy to Understand - Easy to Reuse
• Beans Have Improved Reuse - Still Lagging
• Three Classes of Software
• Domain-Independent (20) Libraries, Utilities,
  etc. Most Likely to Be Reused
• Domain-Specific (65) Dedicated SoftwareReused
  in Other Programs of Same Domain
• Application-Specific (15) UniquenessUnlikely
  to Be Reused

3
Motivation

• Popular OO Design Methodologies Omit and Ignore
  Reuse Guidelines
• Unified Modeling Language - UML
• Design Patterns - Reuse Pattern/Not Software
• Current Research Concentrates on Consumer
  (Reuser) and Not Producer (Creator)
• Measure Savings from Reuse
• Calculate Return on Investment
• Two-Fold Goal
• Elevate Reuse to Equal Partner Starting with
  Design
• Focus on Domain-and-Organization Specific Reuse

4
Motivation
5
MotivationWhy Software Reuse?

• Increase Software Productivity
• Shorten Software Development Time
• Improve Software System Interoperability
• Develop Software With Fewer People
• Move Personnel More Easily From Project to
  Project
• Reduce Software Development and Maintenance Costs
  
• Produce More Standardized Software
• Produce Better Quality Software
• Provide a Powerful Competitive Advantage

6
Objectives

• Reuse 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 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

7
Overview of Presentation

• Cultural and Social Reuse Issues
• Component-Based Design - History Perspective
• Reuse Framework and Methodology
• Subjective Identification of Components
• General vs. Specific Classes
• Related Hierarchies to Quantify Components
• Objective Measure of Dependencies
• Classifying Dependencies
• Measuring Reuse Potential
• Reuse Guidelines
• Methodological Basis for Increasing Reuse
• Iterative Improvement in Reusability
• Prototyping DRE Tool Family/Examples
• Conclusions and Future Research

8
Cultural and Social Reuse IssuesManagement
Support

• Motorola Study A New Reuse Program there must
  have Strong/Unequivocal Management Support
• Raytheon Report Support from Upper Management
  Most Important for Successful Reuse
• Why? Increased
• Cost Associated with Constructing Reusable
  Components
• Communication, Coordination
• Education, Training
• Motorola and Raytheon Facilitate by Incentives
• Both Producer and Consumer Benefits
• Awards Provided for Demonstrated Efforts

9
Cultural and Social Reuse IssuesHigh Initial Cost

• Reports have Indicated
• High Start Up Costs
• Slow Return on Investment (gt 3 years)
• Best Success in
• Starting with Small Projects
• Distributing Components for Reuse
• Opportunistic Reuse
• Reuse Must be Supported by
• Libraries to Collect, Classify, and Disseminate
  Components
• Ease of use for Producer and Consumer

10
What are Components?

• ADTs as Unit of Abstraction/Conceptualization
• Classes are OO Equivalent of ADTs
• However, in Past 10 Years
• Computing Power has Exploded
• Application Complexity has Increased
• Classes are Part of Inheritance Hierarchy
• Inheritance Hierarchy Part of Application Class
  Library
• In Past 2-3 Years Weve Seen
• Emergence of Java
• Emergence of Java Beans
• Component-Based Development Tools

11
What are Components?

• How are Applications Conceptualized?
• Inheritance Hierarchies Partition Domain
• Packages as Collections or Related Classes
• Collections of Classes, Packages, Inheritance
  Hierarchies form Application Class Library
• How are Class Libraries Utilized?
• Use Individual Classes
• Use Package or Subset of Package
• Use Major Portions of Inheritance Hierarchies
• Tools Use at Most a Few Select Packages and/or
  Hierarchies
• Tools that Span Application Classes Represent
  Poorly Designed Software

12
Defining Component Concepts

• A Component is Composed of One or More Classes
  (or Other Components) and is Intended to Support
  a Constructed Unit of Functionality
• Classes Can be Utilized in Multiple Components
• A Class Utilized in Multiple Components Maintains
  the Same Semantics in All of its Contexts
• Our Interest Involves
• Reusable Classes
• Reusable Components
• A Reusable Component Consists of Classes and/or
  Other Components that are Expected to be Reused
  Together in Future Applications

13
Cultural and Social Reuse IssuesReuse and
Software Design/Development

• Lesson Learned
• Reuse Often Avoided by SW Engineers due to Fear
  of Configuration Management Problems
• How is Fear Minimized?
• Reuse as Integral Part of Development Process
• Reuse Early and Often
• Tools that Facilitate Producer Logging Component
  and Consumer Finding Component
• Summary
• Well Concentrate on Technical Reuse Issues
• Superior Techniques Will Remain Unpopular and
  Unused without Associated Support

14
Components vs. Objects

• Components
• Business Oriented
• Coarse Grained
• Standards Based
• Multiple Interfaces
• Provide Services
• Fully Encapsulated
• Understood by Everyone

• Objects
• Technology-Oriented
• Fine Grained
• Language Based
• Single Interface
• Provide Operations
• Use Inheritance
• Understood by Developers

15
Reusable Components Types
Benefits

• Application Template
• Data Model
• Data Structure
• System Architecture
• Process Model
• Process Definition
• Prototype
• Plan Skeleton
• User Interface Skeleton/GUI
• Process Skeleton
• Utility Components

• Organizational Perspective
• Shorten Development Time
• Reduce Costs
• Increase Competitiveness
• Personnel Perspective
• Increase Productivity
• Customer Perspective
• Achieve Greater User Satisfaction Through the
  Production of More Flexible Products

16
Component-Based Development Process
TOP-DOWN To determine what is needed to satisfy
this need.
OTHERS Consider the similarity among concurrent
projects.
FUTURE Consider the possibility of reusing in
future projects.
BOTTOM-UP To determine what is available to
satisfy this need.
17
CBD Component-Based Development
18
Supplier /Consumer Model
19
Component
Specification
Interfaces
Implementation
Executable
20
Complexity of Component
Components as Assets can Grow
21
What are Component Dependencies?

• Dependency Type of Components
• Versions
• Aggregations
• Functional
• Inheritance
• Association
• What is Impact of Each Dependency on the
  Reusability of a Component?

22
Component-Based Tools/Web Sites of Note

• Software Composition Workbench
• JavaBeans
• Visual Café
• Visual J
• Suns Forte
• Enabler, Softlab
• Microsoft Repository
• UREP, Unisys
• Select Software Tools, Select

• Reusable Software Research Group, West
  Virginia University
• http//www.csee.wvu.edu/resolve/scw/rsrg-brochure
  -nov-98.html
• Reusable Software Research Group, Ohio State
  University
• http//www.cis.ohio-state.edu/rsrg/index.html
• Select Software Tools
• http//www.selectst.com/
• Software Reuse Executive Primer, DOD
• http//dii-sw.ncr.disa.mil/ReuseIC/pol-hist/primer
  /
• Model-Driven Software Reuse, Extended
  Intelligence Inc.

23
Component Repository
Repository Browser Hierarchy
24
Multiple Support
Multiple Repository Support
25
CBD life cycle
Business Direction
General Business Requirements
Component Requirements
User Services
Harvest
Business and Data services
User, Business and Data services
26
IDC forecast CBD market
1996 652 million
2001 12 billion
27
Web-Site References

• Reusable Software Research Group, West
  Virginia University
• http//www.csee.wvu.edu/resolve/scw/rsrg-brochure
  -nov-98.html
• Reusable Software Research Group, Ohio State
  University
• http//www.cis.ohio-state.edu/rsrg/index.html
• Select Software Tools
• http//www.selectst.com/
• Software Reuse Executive Primer, DOD
• http//dii-sw.ncr.disa.mil/ReuseIC/pol-hist/primer
  /
• Model-Driven Software Reuse, Extended
  Intelligence Inc.

28
A Framework, Methodology, and Tool for Reusable
Software Components

• Reuse 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 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
• Independent Tool/Integrated in Together CC
• See http//www.engr.uconn.edu/steve/DRE/dre.html

29
A Framework, Methodology, and Tool for Reusable
Software Components

• 1. Define Components, Their Interactions, and
  Analyze Their Reusability
• 2. Store an Iteration of Design
• 3. Implement an Iteration
• 4. Store and Document Iteration of Implemen.
• 5. Reevaluate an Existing Design for
• Correcting Errors
• New Reuse Potential
• 6. Reuse Existing Design with a New Implementation

5
2
1
3
6
4
30
Subjective Identification of Components

• Reuse Historically Occurs at Class Level
• Class as Atomic Component only Scratches
  Surface in Reuse Potential for OO
• But, Classes Interact
• If Reuse One, Often Need Others
• Thus, Reuse Set of Classes
• Expand Reuse from Class to Component Level
• Establish Framework for Promoting Design Reuse
• Characterize General vs. Specific Classes
• Quantify Related Components
• Illustrate via HTSS and Financial Frame
  Applications
• Goal Increase Reuse Potential by Understanding
  Classes, Components, and their Role within Appl.

31
General/Specific Class Characterization

• Subjective Characterization by Software Designer
• Best Estimate on Potential Utility of Class
• General Class (G)
• Those Application Classes that Facilitate
  Domain-and-Organization Specific Reuse
• Specific Class (S)
• Those Application Classes that are Limited to use
  in a Single Application
• Purposes
• Determine Classes with Highest Reuse Potential
  for Organizations Future Systems
• Dependencies from General to Specific are both
  Non-Reusable and Hinder Reuse

32
General/Specific Class Characterization

• 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)
• Only Applicable in Current Applications
• Unlikely to be Reused in Future Applications
• Classes that Retrieve from Company Database
• Application Specific
• What are Some Examples?

33
High-Tech Supermarket System (HTSS)

• Automate the Functions and Actions
• Cashiers and Inventory Updates
• User Friendly Grocery Item Locator
• Fast-Track Deli Orderer
• Inventory Control
• User System Interfaces
• Cash Register/UPC Scanner
• GUI for Inventory Control
• Shopper Interfaces Locator and Orderer
• Deli Interface for Deli Workers
• Well Introduce and Utilize Throughout Lecture

34
The HTSS Software Architecture
IL Item Locator
DO Deli Orderer for Shopper/Employee
Non-Local Client Int.
CR Cash Register
IC Invent. Control
35
A General Class in HTSS

• Why is Item General?
• What is Applicability of Item?

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)
36
Another General Class in HTSS

• Collection Classes of General Classes are General

class ItemDB private int Num_Items
int Curr_Item
Item AllItemsMax_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()
37
Yet Another General Class in HTSS

• GUI-Based Class for Supporting Inventory Control
  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()
38
Specific Classes in HTSS

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

39
Levels of General Classes

• Not All General Classes Created Equally
• Level of Generality Based on Role in Application
• Purposes
• Accommodate Large Systems with Multiple,
  Different Reusable Components
• Reusable Components can Overlap, but Still be
  Distinct Reusable Units

40
Can you Identify Different Levels of General
Classes?
...
41
Can we Identify Different Levels of General
Classes?
Where can Item be Reused?
Where can NonPerishItem and PerishItem be Reused?
Where can ProduceItem and DairyItem be Reused?
...
Are DoleProdItem and HoodDairyItem Specific?
42
Properties of General/Specific Classes

• Level of Generality Strictly Ordered in Hierarchy
• A Descendant of a General Class Must have an
  Index Greater Than or Equal to Itself or be
  Specific
• A Specific Class Can only have Specific
  Descendants

43
Generality and Specificity within One
Inheritance Hierarchy
44
Generality/Specificity/DependenciesAcross
Multiple Hierarchies
45
General/Specific Paradigm in HTSS

• Abstraction from HTSS to Domain Independent
  Inventory Control Application
• Separation of Supermarket Domain Specifics
• Leverage Commonalties for
• Focused, Independent Design/Development
• Future Products
• Relevance
• Domain-and-Organization-Specific Reuse
• Expand to 24 hour Mom Pop Stores
• Expand to Other Retail MarketsE.g., Auto parts,
  Clothing, Toy, etc.

46
Reusability in HTSS Domain

• Where do Changes for Other Domains Occur?

47
Reusability in HTSS Domain
48
Reusability in HTSS Domain
49
The FinancialFrame Application

• A Commercial C Framework Containing 441
  Classes, Proprietary of FinancialComp
• Designed for Reuse in Various Financial Apps.
• Provides Basic Functionalities of Financial
  System
• FinancialFrames Challenge - Manage Changes
• Framework Constantly Evolving
• New Functions and Modify Existing Functions
• Conceptual Relevance
• Provide Realistic Context for Our Approach
• Domain-and-Organization-Specific Reuse

50
The FinancialFrame Application

• Our 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
• Demonstrate Ability of Approach to Localize
  Effect of Changes
• Describe Ways to Increase FinancialFrames Reuse
  Potential

51
General and Specific Classes in FinancialFrame
52
Related Classes and Hierarchies

• Class X is Related to Class Y if they are Related
  and Concept and are Expected to be Reused
  Together in Future Systems
• Class X Related to Class Y is Subjectively
  Assigned by Software Engineer (Producer)
• When Class X is Related to Class Y
• X and All of Xs Descendants are Related toY and
  All of Ys Ancestors
• Thus, to Reuse X or Xs Descendants, you Must
  Reuse Y and All of Ys Ancestors
• Class X Related to Y if Y at Same or Higher
  Level!
• Related Classes Promote Reuse, Since They are
  Expected to be Reused Together

53
Related Hierarchies/Reusable Components

• Two Sub-Hierarchies are Related if to Reuse One,
  you Must Reuse the Other
• Purpose Identify Reusable Dependencies Among
  Related Classes
• Reusable Component A Set of Related Classes that
  are Expected to be Reused as a Group

54
Related Characterization in Levels of Components
- HTSS

• Does R from Environ to PerishItem Make Sense?
• Should R be from PerishItem to Environ?

55
Related Characterizations in Levels of
Components - HTSS

• Where do Changes for Other Domains Occur?

56
Related Characterization in Levels of Components
- FinancialFrame

• Bond is Related to IndexBond
• When Bond is Reused, so Must IndexBond and
  YieldModel
• Hence, IndexBond and its Ancestor (YieldModel)
  are Reused!

57
Related Characterizations in Levels of
Components - FinancialFrame

• Classes/Sub-Hierarchies can be Related if and
  only if Classes (or Sub-Hierarchy Roots) are
  General and at the Same or Higher Level

Root classes of strategies and other most
General classes (Main)
Bond or other strategy Components
Classes specific to FinancialComp
Specific applications at FinancialComp (S)
58
What are Dependencies Among Classes?

• Object Inclusion Class Contains a Instance of
  Another Object
• Attribute Definition Class Contains Attribute
  that is the Type of Another Object
• Method Invocation Class Invokes a Method Defined
  on Another Object
• Goals
• 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

59
Reusing Sub-Hierarchies in Different Components
- HTSS
Will be reused with Components for another
domain, e.g., Toy Store
Will be reused with Components for different
Super- market Companies
Item
...
DairyItem
ProduceItem
DeliItem
60
Reusing Sub-Hierarchies in Different Components
- FinancialFrame

• Dependencies Among General Related Classes
• Not a Hindrance to Reuse
• Represents Valuable Design Knowledge

61
Transitivity in Inheritance and Related
Relationships
Base Case Related Characterization is
Transitive, but not
Commutative
Case 1 A is not related to X
Dependencies from A to X
are not Desirable Recall We Reuse X
and All of Its Ancestors, But Not
Bs Ancestors to Reuse A
62
An Example of Case 1 in FinancialFrame

• FinancialCompMain R FinancialCompTraderThus,
  Dependencies Between are Desirable
• Main is not R to FinancialCompTraderThus,
  Dependencies Between Hinder Reuse
• For Blue Component, we Dont Want to Have to
  Reuse FinancialCompTrader with Main!

63
Transitivity in Inheritance and Related
Relationships

• Case 2 X is Related to A Dependencies from X
  to Both A and B are Desirable
• When Reuse X, Since X Related to B, we Reuse B
  and All of Its Ancestors (A)
• Thus, Dependencies Between X and A are Okay!

A
X
R
B
C
64
An Example of Case 2 in FinancialFrame

• Class Bond R to both IndexBond and YieldModel
• Thus, Dependencies from Bond to IndexBond and
  YieldModel are Desirable and Reusable!
• When Bond is Reused, So is IndexBond and
  YieldModel!

65
Evaluative Metrics and MethodologyObjective
Measures of Dependencies

• Object-Oriented Design Collection of General and
  Specific Classes, with Related Characterizations
• Recall Dependencies Among Classes
• Object Inclusion Another Instance within Class
• Attribute Defn. Attribute Type of Class
• Method Invocation Defined on Another Class
• Quantify Dependencies for Reuse
• Good Promotes Reuse - Leave Alone
• Bad Hinders Reuse - Try to Change
• Okay No Impact on Reuse - Can be Improved
• Goals
• Classify and Understand Dependencies
• Measure Reuse Potential

66
Dependencies Among Related Classes

• Remember, G/S are Subjectively Assigned by
  Software Designer
• The Two G classes are Related
• Related Classes are Intended to be Reused Together

67
Sample Dependencies in HTSS

• InvCont and Item are Related Classes
• InvCont to Item Dependencies are Good Reused
  Together
• Dependency from InvCont to DeliItem is Problem
• Dont Want to Reuse InvCont with DeliItem
• ManagerGUI with InvCont Includes Useless DeliItem
• Dependencies from DeliIC to Item and/or DeliItem
• Dont Impact Reuse
• Can Reuse Item and DeliItem w/o DeliIC

68
Dependencies Among Non-Related Classes

• Remember, G/S are Subjectively Assigned by
  Software Designer
• The Two G Classes are Not Related
• Non-Related Classes are NOT Intended to be Reused
  Together

69
Sample Dependencies in HTSS

• InvCont and Person are Classes that are Not
  Related
• InvCont to Person or Shopper Dependencies are Bad
• Dont Want to Reuse Person/Shopper with InvCont
• Must Reuse - Problem!
• Dependencies from DeliIC to Person and/or Shopper
• Dont Impact Reuse
• Can Reuse Person and Shopper w/o DeliIC
• However, Poor Design if DeliIC Needs Person or
  Shopper!

Bad(2)
Person
Bad (4)
Okay (6)
Shopper
Okay (8)
70
Summarizing Couplings ofRelated Classes

• Type 1 Good for Reuse
• Two General Classes are Reused Together
• Type 3 Bad for Reuse
• General to Specific
• To Reuse, Specific Must be Included
• Added Functionality with No Purpose
• Change to Type 1 or 5/7
• Types 5/7 Okay for Reuse
• No Impact
• Specific Classes Not Reused in New Application
• May Improve Reuse if Changed to Type 1

71
Summarizing Couplings ofNon-Related Classes

• Type 2 Bad for Reuse - Two General Classes
• Not Expected to be Reused Together since Not
  Related
• Change to Type 6/8
• Type 4 Bad for Reuse
• General to Specific
• To Reuse, Specific Must be Included
• Added Functionality with No Purpose
• Change to Type 6/8
• Types 6/8 Okay for Reuse
• No Impact
• Specific Classes Not Reused in New Application

72
Dependencies in Levels of ComponentsSummarizing
Related Classes
(1)
(3)
(5)
(1)
(7)
(1)
(3)
(1)
(7)
Related to
73
Dependencies in Levels of ComponentsSummarizing
Non-Related Classes
(6)
(2)
(8)
(2)
(2)
(8)

• Dependencies Among Unrelated Classes Always
• Bad for Reuse
• No Impact on Reuse

74
Sample Actions to Improve Reusability
75
Reuse Guidelines

• Methodological 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 Couplings
• Type 1 G to G for Related Classes
• Type 8 S to S for Non-Related Classes
• Extended Guidelines Menu of Choices
• Different Ways to Move Couplings
• Considers Impact of Movement on Design
• Goal Iterative Improvement in Reusability

76
Core Guidelines to Move Couplings to Increase
Reuse Potential
77
Extended Guidelines for Improving Reusability

• Core Guidelines Emphasize Local Behavior
• To Remove Bad or Improve Okay Coupling, 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 Alters
  the Coupling, Can Impact Elsewhere
• Expand the Analyses to Other Couplings of the
  Source and Destination of the Bad Coupling
• Couplings to Source when Moving Down
• Couplings to Destination when Moving Up
• Extended Guidelines Menu of Choices

78
Extended Guidelines to Improve ReuseIdentifying
the Problem
What has Occurred?
79
Extended Guidelines to Improve ReuseIdentifying
the Problem
What has Occurred?
80
Problem and Solution

• Focus on Core Guidelines May Ignore the Impact of
  a Change for Other Related and Coupled Classes
• When 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
• Weve Introduced a Bad Coupling
• Likewise, When a Coupling Moved from S to G
• Examine All Existing Coupling to S Class
• S to S Coupling Now S to G
• Weve Introduced a Bad Coupling
• Solution Extended Guidelines to Govern all
  Potential Scenarios for Removing Bad Couplings

81
Extended Guidelines for Type 3 Couplings

• Move Coupling Dst. to 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 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 Type 4
• Detailed Evaluation of Implementation
• Key Concerns
• Local Changes with Global Impact
• Wrong Choice Degrades Reuse

82
Removing Type 3 Couplings in HTSSWhich Changes
Make Sense?

• Change InvCont to S or DeliItem to G
• Neither Makes Sense
• Against Design Intent!
• Move 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 Class
• Find Problem Method Call, Attribute Access,
  Object Inclusion
• Move from InvCont and DeliIC
• Type 3 to Type 7
• Detailed Evaluation of Implementation
• Note Maintain Application Semantics

Item
InvCont
Type 3
DeliIC
DeliItem
83
Extended Guidelines for Type 2 Couplings

• Move Coupling Src. to Specific Classor Change
  Src. To a Specific Class
• Type 2 to Type 6
• May Introduce Couplings from General Classes to
  Specific Src.
• Move Src. and Dst. to Specific Classes
• Type 2 to Type 8
• May Introduce Couplings from G Src. to Specific
  Dst.
• Move Coupling Dst. to Specific Classor Change
  Dst. To a Specific Class
• Follow Type 4 Guidelines
• Change to Related/Type 1/Design Impact Must be
  Evaluated!
• Detailed Evaluation of Implementation

84
Extended Guidelines for Type 4 Couplings

• Move Coupling Dst. to General Classor Change
  Dst. To a General Class
• Type 4 to Type 2 - No Help
• Move Coupling Src. to Specific Classor Change
  Src. To a Specific Class
• Type 4 to Type 8
• May Introduce Couplings from General Classes to
  Specific Src.
• Change to Related/Follow Type 3
• Detailed Evaluation of Implementation

85
Summary on Extended Guidelines

• Total Alternatives for Removing Bad Couplings
• Type 2, 3, 4 Seven Possibilities Each 21 Total
• Type 5, 7 3 Total
• Changing from G to S or Movement of Coupling
  Potential to Impact
• Couplings to Source
• Couplings from Destination
• Result Movement May Decrease Reuse Potential!
• Two-Fold Solution
• Design Support for OO Reuse Metrics and
  Evaluation within UML, Design Patterns, etc.
• Analytical Tool for Evaluating Reuse Potential of
  C, Ada95, or Java Applications/Libraries

86
Utilizing Reuse MethodologyEvaluate Evolving
Design/Implementation

• Constructing New Applications
• Software Design Proceeds in Stages
• Todays Norm Incremental Development and Rapid
  Prototyping
• General/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

87
Utilizing Reuse Methodology Investigate
Reusability of Legacy Code

• Reusability of Legacy Code
• Examine Legacy Code in Detail
• Talk/Contact Domain Experts with Corporate
  Knowledge of Code
• General/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
• See Web Site for Example in FinancialFrame

88
The Video Rental System (VRS)

• VRS 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
• Demonstrate General/Specific/Related Ideas
• Incorporate/Reuse Design in Future System
• Study Effectiveness Approach in Identifying and
  Removing Non-Reusable Dependencies

89
General and Specific Classes in VRS-1
Customer (G)
VideoCustomer (S)
CustomerInterface (G)
VideoCustomerInterface (S)
90
DRE and VRS-1Tracking Incremental Versions
91
Final General/Specific Classes in VRS-2and Some
Related Characterizations
92
DRE and VRS-2Tracking Incremental Versions
93
One Type 3 Coupling G to S Dependency
calculate_currentdate() calculate_duedate() write_
to_historyfile()
VideoTransaction (S)
write_to_checkoutfile()

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

94
Resolving Type 3 G to S Dependency
VideoCustomer(S)
take_item_specific()
((VideoTransaction ) tr) -gt write_to_checkoutfil
e()
95
Utilizing Reuse Methodology Investigate
Reusability of Legacy Code

• Reusability of Legacy Code
• Examine Legacy Code in Detail
• Talk/Contact Domain Experts with Corporate
  Knowledge of Code
• General/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-Bed

96
The FinancialFrame ApplicationInitial
Assumptions on G/S and Related

• FinancialFrame Composed of Multiple Algorithm
  Familites
• All Root Classes are G(0) with Subclasses G(1)
• All Other Classes are G(0)
• Use Actual Couplings in Code to Define Related
  Characterization

Bond
YieldModel
...
Discount
IndexBond
Bill
97
Evaluation of FinancialFramePossible Scenarios

• Dependencies from to Classes
• Occurring from a General Class (Bond) to Classes
  Specific to a Component (IndexBond)
• Such Couplings Require a Specific Class that is
  Not Needed to be Reused with the General Root
• Reported as Undesirable Couplings (Type 3/4)

Bond
YieldModel
...
Discount
IndexBond
Bill
98
Revising FinancialFrame Application

• Bond is Changed from to
• A Component Consisting of Bond, IndexBond, and
  YieldModel is Defined
• When Bond Reused, So Must IndexBond and
  YieldModel - Other Classes Not Needed
• However, YieldModel can Be Reused in Isolation
• Thus, Modifications to Component Only Affect
  Reusers of Component

99
Evaluation of FinancialFramePossible Scenarios

• Dependencies from to Classes
• Occurring from a Specific Class to Other Classes
  Specific Unrelated to a Component
• Bond Related to Class Outside Component
• Such Couplings Require a Specific Class in One
  Component to be Reused in Another Component,
  Where it is Not Needed
• Reported as Undesirable Couplings (Type 2)

100
Reusability of FinancialFrame Components

• Undesirable Couplings Identified via Either
  Scenario can be Removed to Increase Reuse
• Results of Such Actions w.r.t. FinancialFrame
• Classes can be Reused with Classes
• When a Class is Modified, Only Users of
  Particular Component(s) are NotifiedBad Coupling
  No Longer Present!
• Each Component Can be Reused As is
• Classes Outside of Component No Longer Needed
• Cannot Illustrate Due to Proprietary Software
• Similar Changes to VRS-2 Occur

101
Design Reusability Evaluation (DRE) Tool

• What is DRE?
• Java-Based Tool for Analyzing Reusability
• Takes Java Software 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 Ways
• Evaluate Evolving Design/Implementation
• Investigate the Reusability of Legacy Code

102
The DRE Tool Family

• Standard DRE (SDRE)
• Allows Generality and Related to be Set, and
  Metric to be Fired, and Dependencies to be
  Classified and Analyzed
• Directly Edit Source Code for Dependencies
• Collaborative DRE (CDRE)
• XML Interoperability to Allow DRE Marking to be
  Saved and Restored via XML
• CDRE Supports Multiple Clients Working on Same
  Project Simultaneously
• Together DRE (TDRE)
• Integrated via Plug-Ins into UML Tool

103
Utilizing Reuse MethodologyEvaluate Evolving
Design/Implementation

• Constructing New Applications
• Software Design Proceeds in Stages
• Todays Norm Incremental Development and Rapid
  Prototyping
• General/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

104
Utilizing Reuse Methodology Investigate
Reusability of Legacy Code

• Reusability of Legacy Code
• Examine Legacy Code in Detail
• Talk/Contact Domain Experts with Corporate
  Knowledge of Code
• General/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-Bed

105
SDRE - Main Application Window
106
SDRE - Main Window Setting Generality
107
SDRE - Main Window Setting Relations
108
SDRE - Main Window Choosing Simulation Options
109
SDRE - Help Subsystem

• HTML-based Documents Describe Tool Theory

110
SDRE - Graphical RepresentationGenerality Set
for Design
111
SDRE - Graphical RepresentationSetting Related
Classes
112
SDRE - Graphical Icons for Classes
Inheritance Edge Base
Generality Base
Relative Edge Base
Base Rectangle
Source File Name
Select Base
Inheritance Edge
Related Edge
113
SDRE - Graphical Representation
114
SDRE - Editing Source Code Enabled When Doubling
Clicking
115
SDRE - Editing Source CodeEditor Appears with
Line Highlighted
116
SDRE - Editing Source CodeSource Editor Features
117
Collaborative DRE (CDRE)

• CDRE Purposes
• Enable Teams to Collaborate on Metrics
  Measurement
• Utilize Client/Server Architecture
• Share Data Between Users
• Separate Project Information From Class Markings
• Store Source Code Centrally
• Execute Metrics on Powerful Server
• Use Same DRE Interface as Control Client
• Utilize XML in Redesign Efforts
• CDRE is Intended to Bring SDRE into a Real-World
  Computing Environment

118
CDRE DRE Client
119
CDRE Client Login
120
CDRE Project Selection
121
CDRE Remote Class Selection
122
Together DRE (TDRE)

• Integrating DRE into TCC
• Ongoing Prototyping Integrate SDRE into TCC
• Utilization of TCC Extension Capabilities to
  Allow Generality and Related to be Set
• Initiation of Complete SDRE tool via Plug-In
  Capabilities of TCC
• Single Integrated Design/Development Environment
  with Reusability Assessment
• Leverage TCC to Support Reusability
• Incorporate G/S and Related at UML Level
• Users can Execute Plug Ins for Each
• Actual Properties for UML Classes Modified
• Invoke SDRE Directly from TCC

123
Reusability in Together CC
124
Reusability in Together CC
125
Reusability in Together CC
126
Reusability in Together CC
127
Towards the Formalization of a Reusability
Framework for Refactoring

• Formal Definitions of Reuse Model to Allow
  Automatic and Algorithmic Analysis of Couplings
• Paper by Cabellero and Demurjian at ICSR-7
• OO Application Model
• Reuse Framework
• Coupling Type Transition Matrix
• Defines Loss, Gain, or Steady State Between the
  Various Coupling Types
• 1 Going from G--gtS to G--gtG for Related Classes
• -1 Going from G--gtG to G--gtS for Related Classes
• 0 Going from S--gtG to S--gtS for Related Classes

128
Goal

• Increase Reuse Potential by Understanding
  Classes, Components, and their Role within
  Applications
• 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
• Independent Tool/Integrated in Together CC
• See http//www.engr.uconn.edu/steve/DRE/dre.html

129
Model of OO Application

• Definition 1 Object-Oriented Application S is
  Modeled As a 3-tuple (C, ?i, ?m)
• C is the Set of Classes, Where Each Class Cp
  Contains a Set Cpm of Methods Mi?m Such that Each
  Method Mi Belongs to Only One Class
• ?I is the Set of Pair-wise Inheritance Relations
  of Classes in C
• ?M is the Set of Pair-wise Coupling Among Methods

130
Model - Pair-wise Couplings

• Definition 2 Pair-wise Coupling
• Two classes Cp and Cq are Pair-Wise Coupled when
  there is at Least One Method mi?CpM that Invokes
  a Method mj?CqM .

Cp
Cq
m1
m5
m4
mj
mi
m9
m18
m9
m20
131
Basis of Reuse Framework

• Class Reusability
• Best Estimate on Potential Utility of Class
• General Application Classes that Facilitate
  Domain-and-Organization Specific Reuse
• Specific Application Classes that are Limited to
  use in a Single Application
• Relations Among Classes
• Grouping of Classes that Are Expected to Be
  Reused Together in Future Applications

132
Class Reusability

• General Classes
• Expected to be Reused in Future Applications
• Abstract Classes/Root Classes/Non-Leaf Classes in
  Inheritance Hierarchies
• Domain Independent/Domain Specific
• Specific Classes
• Only Applicable in Current Applications
• Unlikely to be Reused in Future Applications
• Application Specific
• Purpose Determine Classes with Highest Reuse
  Potential for Organizations Future Systems

133
Model - Class Reusability

• Definition 3 The Reusability Level of Class Ci
  is Denoted by Gci
• Gci0 ? Ci is the Most General Class in the
  Application
• GciN (Ngt0) ? Ci is the Most Specific Class in
  the Application
• Lower N, More General Class
• Class Generality Vector

134
Model - Relations Among Classes

• Related Classes Promote Reuse, Since They are
  Expected to be Reused Together
• Class Ci is Related to Class Cj if Expected to be
  Reused Together in Future Systems
• Class Ci Related to Class Cj is Subjectively
  Assigned by Software Engineer (Producer)
• Related Classes Assist in Reusability Assessment

135
Quantifying Reuse Properties

• Property 1 Generality and Inheritance
• Parent of a Class is Equally General or More
  General than is Direct Children
• Property 2 Generality and Related Classes
• Reuse Level of Class is Equal to the Reuse Level
  of the Least Reusable Coupled Class
• Property 3 Extraneous Functionality
• Classes that Dont Contribute to Functionality of
  Component have Negative Impact on Reuse
• Property 4 Generality and Unrelated Classes
• Couplings Between Unrelated Classes Hinder Reuse

136
Dependencies Among Classes

• Object Inclusion Class Contains a Instance of
  Another Object
• Attribute Definition Class Contains Attribute
  that is the Type of Another Object
• Method Invocation Class Invokes a Method Defined
  on Another Object
• Goals
• 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

137
Dependencies Related Classes

• Remember, G/S are Subjectively Assigned by
  Software Designer
• The Two G classes are Related
• Related Classes are Intended to be Reused Together

Good (Type 1)
G
G
Okay (Type 5)
Bad (Type 3)
S
S
Okay (Type 7)
138
Dependencies Non-Related Classes

• G/S are Subjectively Assigned by Designer
• The Two G Classes are Not Related
• Non-Related Classes are NOT Intended to be Reused
  Together

Bad (Type 2)
Okay (Type 6)
Bad (Type 4)
Okay (Type 8)
139
Sample Actions to Improve Reusability
140
Core Guidelines to Move Couplings to Increase
Reuse Potential
141
Coupling Type Transitions

• Defines Loss, Gain, or Steady State Between the
  Various Coupling Types
• For Example,
• Going from a G?S to a G?G Coupling Type for
  Related Classes is a 1
• Going from a G?G to a G?S Coupling Type for
  Related Classes is a -1
• Going from a S?G to a S?S Coupling Type for
  Related Classes is a 0
• Define a Matrix for all Transitions Among the
  Eight Coupling Types in One Step
• Distinguish Related from Unrelated Transitions

142
Coupling Transitions
Related Classes
Unrelated Classes
143
Reuse Improvement Factor

• Metric of the Loss, Gain, or Steady State Between
  the Various Coupling Types After the Refactoring
• Defined by
• where ? is the Matrix for all Transitions Among
  the Eight Coupling Types in One Step
• If ?? gt 0 ? Refactoring had Negative Reuse Impact
• If ?? lt 0 ? Refactoring had Positive Reuse Impact
• If ?? 0 ? Refactoring had No Impact on Reuse

144
Motivation of Refactoring Algorithm

• Goal Improve the Reuse Potential of an
  Application
• Formalizes Guidelines to Increase Reusability
  Introduced by M. Price and S. Demurjian
• Basic Idea
• Analyze All Couplings that Can be Improved
• Refactor Application Automatically
• Evaluate the Impact on Reuse of Refactoring
• Commit if Reuse Improvement Factor is Positive
• Undo if Reuse Improvement Factor is Negative
• Iterate until All Appropriate Couplings Considered

145
Refactoring Algorithm

• Step 1 Identify Reuse Potential - Mark
  Generalities
• Step 2 Calculate Couplings
• Step 3 Identify Related Classes
• Step 4 Determine Coupling Types
• Step 5 Identify Undesirable Couplings
• Step 6 Refactor Move Source or Destination
  Method, Change Reuse Level, Related to Unrelated
• Step 7 Recalculate Reuse Improvement Factor
• Step 8 If Reuse Factor lt 0 Goto Step 6 Else
  Goto Step 5 or Terminate Based on Condition

146
Example - Assumptions

• Assume Classes C1, C2, C3, C4, C5, C6, C7
• Methods m1, m2, m3, m4, m5, m6, m7, m8
• Dependencies Among Methods (Couplings) Shown with
  Arrows

147
Example - Generality and RelatedSteps 1, 2, 3 of
Algorithm

• Establish Class Reusability
• C1, C2, C4, C6 ? General
• C3, C5, C7 ? Specific
• Calculate Couplings
• Assume all Classes are Related Classes to One
  Another

148
Example - Determine Coupling TypesStep 4 of
Algorithm
149
Example - Identify Undesirable Couplings Step 5
of Algorithm
150
Example - Refactor the Application Step 6 of
Algorithm
m3

• For (m3,m5) Try to Move Source Method Down

No Improvement!
151
Example - Refactor the Application Step 6 of
Algorithm
m4

• For (m4,m6) Try to Move Source Method Down

152
Example - Refactor the Application Step 6 of
Algorithm
m5
m4

• For (m5,m7) try to Move Source Method Down

153
Example - Refactored Class Diagram
154
Reusability and UML

• Investigation of Our Reuse Model and Framework at
  Design Level via UML
• Establishing Generality and Related in Use-Case
  and Class Diagrams
• Counting and Tracking Dependencies in Behavior
  Modeling and Component Diagrams
• Key Questions
• Can Use Cases have Generality Levels?
• How Do UC Generalities Relate to Classes?
• What Dependencies Can be Tracked for Either
  Warning or Counting (Metrics)?
• Incorporation into TCC and Transition to DRE
• Build and Extend the Formal Model (Caballero)

155
Revisiting Reuse Properties

• Property 1 Generality and Inheritance
• Parent of a Class is Equally General or More
  General than is Direct Children
• Property 2 Generality and Related Classes
• Reuse Level of Class is Equal to the Reuse Level
  of the Least Reusable Coupled Class
• Property 3 Generality and Unrelated Classes
• Couplings Between Unrelated Classes Hinder Reuse

156
Reuse Definition, Assessment, and Analysis in UML

• Examination of Reuse in
• Use Case Diagrams
• Class Diagrams
• Behavior Modeling Diagrams
• Component Diagrams
• Reuse Improvement During Design
• Transition from Design into Development
• Consistency of Approach with Existing Reuse Model
  and Formal Refactoring Guidelines
• Definite Additional Properties (see Previous
  Slide)
• Introduce Refactoring Guidelines that Enforce the
  Properties of Reuse for UML Diagrams

157
Reuse Definition, Assessment, and Analysis in UML

• Examination of Reuse in
• Use Case Diagrams
• Class Diagrams
• Behavior Modeling Diagrams
• Component Diagrams
• Reuse Improvement During Design
• Transition from Design into Development
• Consistency of Approach with Existing Reuse Model
  and Formal Refactoring Guidelines
• Definite Additional Properties (see Previous
  Slide)
• Introduce Refactoring Guidelines that Enforce the
  Properties of Reuse for UML Diagrams

158
Use Cases with Generalities

• Application has Three Systems
• Each System with One or More Use Case
• Each Use Case has Generality Level
• Relationships Among Use Cases are
• Extend
• Include
• Generalize
• Generalities Must be Consistent within Systems
  and Between UCs Given Relationships

159
Use Cases with Include, Extend, and Inheritance

• Dependencies Among Use Cases
• Dependencies are Transitive w.r.t. Generalities

160
Properties for Use Cases

• Property 4 UCA extends UCB means UCA adds
  behavior to UCB, so UCA is at most as general as
  UCB or GUC-B ? GUC-A
• Property 5 UCA includes UCB is a relation of the
  behavior sequence of supplier UCB to the
  interaction sequence UCA. Thus, UCA is at most
  as general as UCB or GUC-B ? GUC-A.
• Property 6 UCA generalizes UCB relates child UCB
  to parent UCA, meaning that UCB is at most as
  general as UCA or GUC-A ? GUC-B.

161
Corresponding Refactoring Guidelines

• RG1 or RG2 to Enforce Property 4 or Property 5
• The refactoring rule is If GUC-B gt GUC-A then
  refactor by making UCB more general (or UCA more
  specific) so GUC-B ? GUC-A or by removing the
  extend/include.
• RG3 to Enforce Property 6
• The refactoring rule is If GUC-A gt GUC-B then
  refactor by making UCA more general (or UCA more
  specific) so GUC-A ? GUC-B or or by removing the
  generalization.

162
Identifying ProblemsRG3 for Pay Cash

• RG2 for Place Order to G2 or Remove ltincludegt
• RG3 for Pay Cash to G1 or Arrange Payment to G0
  or Remove ltgeneralizationgt

163
UML Reuse and Class Diagrams

• Definition 3
• UCA is related to CA C1 , C2 , , Cn for
  some n, if UCA relies on CA for functionality.
• Property 7 UCs and Classes - Generality
• Suppose UCA has CA C1 , C2 , , Cn . Then,
  the generality of UCA must be as specific as the
  most specific class in CA , and may be more
  specific, i.e., GUC-A maxgenerality ? Ci ? CA
  .
• RG4 to Enforce Property 7
• The refactoring rule is generality change of UCA
  or one or more Ci in CA until GUC-A
  maxgenerality ? Ci ? CA , or the removal of all
  classes in CA that cause the GUC-A
  maxgenerality ? Ci ? CA to be violated.

164
Classes and Generality Levels
165
UML Reuse and Class Diagrams

• Property 8 UCs and Classes - Related
• Suppose that UCA is related to CA and UCB is
  related to CB . If UCA is related to UCB (extend,
  include, or generalize), then there has to be at
  least one transitive relati