Transcript A Framework, Methodology and Tool for Reusable Software Components*

A Framework, Methodology and Tool
for Reusable Software Components*
Prof. Steven A. Demurjian†
Computer Science & Engineering Department
The University of Connecticut
371 Fairfield Road, Box U-2155
Storrs, CT 06269-2155
[email protected]
http://www.engr.uconn.edu/~steve
(860) 486 - 4818
† Special Thanks to Jeff Ellis, Rodrigo Caballero, Margie Price, Donald
Needham for providing portions of this material.
*Work supported in part by a grant from Electric Boat, Inc., Groton CT.
REUSE--1
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 Software
Reused in Other Programs of Same Domain
 Application-Specific (15%): Uniqueness
Unlikely to Be Reused
REUSE--2
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
REUSE--3
Motivation
Three Classes of Software
in a Typical Software Application
Domain-Independent
20%
Domain-Specific
65%
Application-Specific
15%
REUSE--4
Motivation
Why 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
REUSE--5
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
REUSE--6
Overview of Presentation – Part 1



Cultural and Social Reuse Issues
Component-Based Design - History & Perspective
Component-Based 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

Detailed Reuse Guidelines
 Methodological Basis for Increasing Reuse
 Iterative Improvement in Reusability

Prototyping: DRE Tool Family/Examples
REUSE--7
Cultural and Social Reuse Issues
Management 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
REUSE--8
Cultural and Social Reuse Issues
High Initial Cost



Reports have Indicated
 High Start Up Costs
 Slow Return on Investment (> 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
REUSE--9
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 We’ve Seen
 Emergence of Java
 Emergence of Java Beans
 Component-Based Development Tools
REUSE--10
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
REUSE--11
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
REUSE--12
Cultural and Social Reuse Issues
Reuse 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
 We’ll Concentrate on Technical Reuse Issues
 Superior Techniques Will Remain Unpopular
and Unused without Associated Support
REUSE--13
Components vs. Objects

Components

Objects
 Technology-Oriented

Business Oriented

Coarse Grained

Fine Grained

Standards Based

Language Based

Multiple Interfaces

Single Interface

Provide Services

Provide Operations

Fully
Encapsulated

Use Inheritance

Understood by
Developers

Understood by
Everyone
REUSE--14
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
REUSE--15
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.
REUSE--16
CBD: Component-Based Development
REUSE--17
Supplier /Consumer Model
SUPPLY
Build New
Wrap Existing
Buy
CONSUME
Assemble
Applications
MANAGE
Publish
Subscribe
Catalog
Browse
REUSE--18
Component
Specification
Interfaces
Implementation
Executable
REUSE--19
Complexity of Component
Components as Assets can Grow
REUSE--20
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?
REUSE--21
Component-Based Tools/Web Sites of Note









Software
Composition
Workbench
JavaBeans
Visual Café
Visual J++
Sun’s Forte
Enabler, Softlab
Microsoft
Repository
UREP, Unisys
Select Software
Tools, Select

Reusable Software Research Group,
West Virginia University


Reusable Software Research Group,
Ohio State University


http://www.selectst.com/
Software Reuse Executive Primer,
DOD


http://www.cis.ohiostate.edu/rsrg/index.html
Select Software Tools


http://www.csee.wvu.edu/~resolve/scw/rs
rg-brochure-nov-98.html
http://dii-sw.ncr.disa.mil/ReuseIC/polhist/primer/
Model-Driven Software Reuse,
Extended Intelligence Inc.
REUSE--22
Component Repository
Repository
Browser
Hierarchy
REUSE--23
Multiple Support
Multiple Repository Support
REUSE--24
CBD life cycle
Business
Direction
General Business
Requirements
Component
Requirements
Harvest
Business and
Data services
User
Services
User, Business
and Data services
REUSE--25
IDC forecast CBD market
1996: $652 million
2001: $12 billion
REUSE--26
Web-Site References

Reusable Software Research Group, West
Virginia University


Reusable Software Research Group, Ohio
State University


http://www.selectst.com/
Software Reuse Executive Primer, DOD


http://www.cis.ohio-state.edu/rsrg/index.html
Select Software Tools


http://www.csee.wvu.edu/~resolve/scw/rsrg-brochurenov-98.html
http://dii-sw.ncr.disa.mil/ReuseIC/pol-hist/primer/
Model-Driven Software Reuse, Extended
Intelligence Inc.
REUSE--27
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
See: http://www.engr.uconn.edu/~steve/DRE/dre.html
REUSE--28
A Framework, Methodology, and Tool for
Reusable Software Components
Store &
Document
Designs
5
1
Re(Design)
a System
Reusability
Evaluation
3
6
Store &
Document
Implemens.
2
4
Implement
the System
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
REUSE--29
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.
REUSE--30
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 Organization’s Future Systems
 Dependencies from General to Specific are both
Non-Reusable and Hinder Reuse
REUSE--31
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?
REUSE--32
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
We’ll Introduce and Utilize Throughout Lecture
REUSE--33
The HTSS Software Architecture
IL: Item
Locator
IL
IL
IL
SDO
EDO
SDO
EDO
CR
CR
Item
Payment
CR
CR
DO: Deli Orderer for
Shopper/Employee
IC
Order
IC
CR: Cash Register
IC: Invent. Control
Non-Local
Client Int.
CreditCardDB
Inventory
Control
ItemDB
Global
Server
ItemDB
Local
Server
ATM-BanKDB
OrderDB
SupplierDB
REUSE--34
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);
};
REUSE--35
Another General Class in HTSS

Collection Classes of General Classes are General
class ItemDB
{private:
int
Num_Items;
int
Curr_Item;
Item* AllItems[Max_Items];
int
int
int
int
public:
void
void
void
void
void
FindFirstItem();
FindNextItem();
FindItemUPC(int code);
FindItemName(char* name);
ItemDB(); // Constructor
InsertNewItem(Item* new_one);
DeleteExistingItem(int code);
FindDisplayItemUPC(int code);
FindDisplayItemName(char* name);
PrintAllItems();
};
REUSE--36
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();
};
REUSE--37
Specific Classes in HTSS

General Classes are Refined to Represent
Particular Items, Yielding Specific Classes
Item
ProduceItem
DairyItem
DeliItem
...
OrdererGUI
DeliOrdererGUI
REUSE--38
Levels of General Classes


Not All General Classes Created Equally
Level of Generality Based on Role in Application
G0
G0
G0
G1
G2
S
G1
G2

G 0 , G1 , G 2 ,..., S
S
G i views G j as General
if i  j
i views G j as Specific
G
if i < j
Purposes
 Accommodate Large Systems with Multiple,
Different Reusable Components
 Reusable Components can Overlap, but Still be
Distinct Reusable Units
REUSE--39
Can you Identify Different Levels
of General Classes?
Item
1
NonPerishItem (G )
ProduceItem
(G 0 )
1
PerishItem (G )
DairyItem
DeliItem
...
REUSE--40
Can we Identify Different Levels
of General Classes?
Where can Item
be Reused?
Item
1
(G
)
NonPerishItem
(G 0 )
Where can
NonPerishItem
and PerishItem
be Reused?
1
(G
)
PerishItem
Where can ProduceItem and
DairyItem be Reused?
2
(G
ProduceItem )
BigYProdItem
DoleProdItem
2
(G
) DeliItem
DairyItem
BigYDairyItem
...
HoodDairyItem
Are DoleProdItem and HoodDairyItem Specific?
REUSE--41
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
G0
G0
G 0 , G1 , G 2 ,..., S
G0
G1
G2
S
G1
G2
S
G i views G j as General
if i  j
i views G j as Specific
G
if i < j
REUSE--42
Generality and Specificity
within One Inheritance Hierarchy
G
G
G
G
S
S
S
G
S
S
S
Fig. General (G) / Specific (S) Classes of a Hierarchy
REUSE--43
Generality/Specificity/Dependencies
Across Multiple Hierarchies
G
1
G
G
G
G
G
4
G
S
S
2
S
S
S
S
G
S
S
3
S
S
S
S
Fig. Types of Couplings between Class Hierarchies
REUSE--44
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 Markets
E.g., Auto parts, Clothing, Toy, etc.
REUSE--45
Reusability in HTSS Domain
Root classes for Items, ItemDB,
etc., which are Most General.
(G 0 )
Inventory Control/Other Components.
(G1 )
Classes Specific to Grocery Store Domain.
(G 2 )
Specific Applications for Big Y or Shaw’s or Stop/Shop (S)

Where do Changes for Other Domains Occur?
REUSE--46
Reusability in HTSS Domain
Root classes for Items, ItemDB,
etc., which are Most General.
(G 0 )
Inventory Control
Tool for Ordering
Items from Suppliers
Inventory Control
Other Components.
(G1 )
Cost Accounting Tool
for Tracking Net and
Gross Profit
Classes Specific to Grocery Store Domain. (G 2 )
Specific Applications for Big Y or Shaw’s or Stop/Shop (S)
REUSE--47
Reusability in HTSS Domain
Root classes for Items, ItemDB,
etc., which are Most General.
(G 0 )
Inventory Control/Other Components.
Classes Specific
to Grocery
Store Domain.
(G 2 )
(G1 )
Classes for
Large
Supermarket
Classes for
Specialty
Supermarket
Classes for
24 Hour
Convenience
Specific Applications for Big Y or Shaw’s or Stop/Shop (S)
REUSE--48
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
FinancialFrame’s 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
REUSE--49
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 FinancialFrame’s
Reuse Potential
REUSE--50
General and Specific Classes in
FinancialFrame
CashFlowAnalyzer (G 0 )
1
IndexBond (G )
YieldModel (G 0 )
1
Discount (G )
...
1
Bill (G )
2
FinancialCompDesk (G )
2
FinancialCompTrader (G )
2
FinancialCompAccount (G )
FinancialCompMain (G 2 )
SpecificFCMain (S)
Main (G 0 )
OtherMain (G 2 )
...
SpecificOtherMain (S)
REUSE--51
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 X’s Descendants are Related to
Y and All of Y’s Ancestors
 Thus, to Reuse X or X’s Descendants, you Must
Reuse Y and All of Y’s 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
REUSE--52
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
G0
G0
A
G0
Sub-Hierarchies
G0
B
G0
S
R
G0

S
S
Reusable Component: A Set of Related Classes that
are Expected to be Reused as a Group
REUSE--53
Related Characterization in
Levels of Components - HTSS
0
Item (G )
1
(G
)
NonPerishItem
ProduceItem


1
(G
)
PerishItem
DairyItem
DeliItem
R
1
(G
Environ )
SubZero
RTemp
Does R from Environ to PerishItem Make Sense?
Should R be from PerishItem to Environ?
REUSE--54
Related Characterizations in
Levels of Components - HTSS
Root classes for Items, ItemDB,
etc., which are Most General.
(G 0 )
Inventory Control/Other Components.
(G1 )
Classes Specific to Grocery Store Domain.
(G 2 )
Specific Applications for Big Y or Shaw’s or Stop/Shop (S)

Where do Changes for Other Domains Occur?
REUSE--55
Related Characterization in
Levels of Components - FinancialFrame
1
(G
)
Bond
0
YieldModel (G )
R
1
(G
)
IndexBond



1
(G
)
Discount
1
(G
)
Bill
...
Bond is Related to IndexBond
When Bond is Reused, so Must IndexBond and
YieldModel
Hence, IndexBond and its Ancestor (YieldModel)
are Reused!
REUSE--56
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)
(G 0 )
Bond or other strategy Components
(G1 )
Classes specific to FinancialComp
(G 2 )
Specific applications at FinancialComp (S)
REUSE--57
What are Dependencies Among Classes?


Three Types of Dependencies:
 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
Inheritance is NOT a Dependency
 Yes – it’s a Relationship – but it is for Reuse
 However, Represents Shared Behavior
 Instance X with Parent Y and Grandparent Z is
Created as a Single Instance that Includes Y+Z
REUSE--58
Goals of the Research





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
These Four Actions (Change, Move, Split, Merge)
and Others Represent Refactoring
Key Issues:
 Refactoring Maintains Original Functionality
 Process Should Not Introduce Problems
REUSE--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 Supermarket Companies
Item
NonPerishItem
PerishItem
ProduceItem
DairyItem
DeliItem
...
REUSE--60
Reusing Sub-Hierarchies in
Different Components - FinancialFrame

Dependencies Among General Related Classes
 Not a Hindrance to Reuse
 Represents Valuable Design Knowledge
Will be reused with Components
utilizing FinancialComp’s database
Main (G 0 )
2
OtherMain (G )
SpecificOtherMain (S)
Will be reused with Components
utilizing another company’s databases
2
(G
)
FinancialCompMain
SpecificFCMain (S)
REUSE--61
Transitivity in Inheritance and
Related Relationships
Base Case: Related Characterization is Transitive,
but not Commutative
A
R
B
Case 1: A is not related to X
Dependencies from A to X
are not Desirable
R
C
A
X
R
B
Recall: We Reuse X and All
of Its Ancestors, But Not
B’s Ancestors to Reuse A
C
REUSE--62
An Example of Case 1 in FinancialFrame



FinancialCompMain R FinancialCompTrader
Thus, Dependencies Between are Desirable
Main is not R to FinancialCompTrader
Thus, Dependencies Between Hinder Reuse
For “Blue” Component, we Don’t Want to Have to
Reuse FinancialCompTrader with Main!
FinancialCompTrader(G
2
)
)
R
0
(G
)
Main
OtherMain(G
2
FinancialCompMain
(G 2 )
REUSE--63
Transitivity in Inheritance and
Related Relationships
A

X

R
B

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!
C
REUSE--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!
1
Bond (G )
0
YieldModel (G )
R
1
IndexBond (G )
1
Discount (G )
1
Bill (G )
...
REUSE--65
Evaluative Metrics and Methodology
Objective 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
REUSE--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
Good (1)
G
G
Bad (3)
Okay (5)
S
S
Okay (7)
REUSE--67
Sample Dependencies in HTSS

Good (1)
Item
InvCont


Bad (3)
Okay (5)
DeliIC
DeliItem
Okay (7)

InvCont and Item are Related
Classes
InvCont to Item Dependencies
are Good: Reused Together
Dependency from InvCont to
DeliItem is Problem
 Don’t Want to Reuse
InvCont with DeliItem
 ManagerGUI with InvCont
Includes Useless DeliItem
Dependencies from DeliIC to
Item and/or DeliItem
 Don’t Impact Reuse
 Can Reuse Item and
DeliItem w/o DeliIC
REUSE--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
Bad (2)
G
G
Bad (4)
Okay (6)
S
S
Okay (8)
REUSE--69
Sample Dependencies in HTSS

Bad(2)
Person
InvCont

Bad (4)
Okay (6)
DeliIC
Shopper
Okay (8)

InvCont and Person are Classes
that are Not Related
InvCont to Person or Shopper
Dependencies are Bad
 Don’t Want to Reuse
Person/Shopper with
InvCont
 Must Reuse - Problem!
Dependencies from DeliIC to
Person and/or Shopper
 Don’t Impact Reuse
 Can Reuse Person and
Shopper w/o DeliIC
 However, Poor Design if
DeliIC Needs Person or
Shopper!
REUSE--70
Summarizing Couplings of
Related 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 – Refactoring
Guideline (RG)
Types 5/7: Okay for Reuse
 No Impact
 Specific Classes Not Reused in New
Application
 May Improve Reuse if Changed to Type 1- RG
REUSE--71
Summarizing Couplings of
Non-Related Classes



Type 2: Bad for Reuse - Two General Classes
 Not Expected to be Reused Together since Not
Related
 Change to Type 6/8 – Refactoring Guideline
Type 4: Bad for Reuse
 General to Specific
 To Reuse, Specific Must be Included
 Added Functionality with No Purpose
 Change to Type 6/8 – RG
Types 6/8: Okay for Reuse
 No Impact
 Specific Classes Not Reused in New
Application
REUSE--72
Dependencies in Levels of Components
Summarizing Related Classes
G
0
(1)
G0
G0
(3)
G1
G0
(5)
G1
G1
G1
(7)
G2
G2
G2
G Related to G
0
G1
(1)
G2
(7)
0
G0
(1)
G1
(3)
G2
G0
G2
(1)
Related to
G2
G2
REUSE--73
Dependencies in Levels of Components
Summarizing Non-Related Classes
G
0
(2)
G0
G0
G0
G0
(6)
G
1
(4)
G1
G2
G1
G1
(8)
G2
G2
G1
(2)
G2
(8)

(2)
G1
(4)
G0
G2
(2)
G2
Dependencies Among Unrelated Classes Always
 Bad for Reuse
 No Impact on Reuse
REUSE--74
Sample Actions to Improve Reusability
Changes are Refactorings!
Coupling
Among Related
Among Unrelated
GG
Type (1)
Good for Reuse
Type (2)
Bad for Reuse
Move Src./Dst. to Specific
GS
Type (3)
Bad for Reuse
Move Dst. to General
Type (4)
Bad for Reuse
Move Src. To Specific
SG
Type (5)
Can Improve if Move
Src. to General
Type (6)
No Impact on Reuse
SS
Type (7) - Can Improve Type (8)
if Move Src./Dst. to Gen. No Impact on Reuse
REUSE--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 Refactor Couplings
 Considers Impact of Refactorings on Design
Goal: Iterative Improvement in Reusability while
Maintaining Application Functionality
REUSE--76
Core Refactoring Guidelines to Move
Couplings to Increase Reuse Potential
Type 1
Type 1
G
G
G
G
G
S
S
S
S
S
Type 3
G
Type 1
G
S
Type 7
Type 5
G
Type 2
S
G
G
G
Type 4 G
S
S
S
S
S
Type 7
Type 8
Type 8
REUSE--77
Extended Refactoring Guidelines for
Improving Reusability





Core Refactoring Guidelines Emphasize Local
Behavior
To Remove “Bad” or Improve “Okay” Coupling,
Refactor 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 Refactoring Guidelines: Menu of Choices
REUSE--78
Extended Refactoring Guidelines to
Improve Reuse - Identifying the Problem
Suppose
G
G
m() Type 3 G
Recall
G
Type 3 G
S
S
S
S
Type 7
G
What has Occurred?
G
G
S Type 7
m()
S
REUSE--79
Extended Refactoring Guidelines to
Improve Reuse - Identifying the Problem
Suppose
Recall
Type 1
G
G
S
S
Type 5
G
G
G
Type 5
S
m()
S
Type 1
G
What has Occurred?
G
m()
G
S
S
REUSE--80
Problem and Solution




Focus on Core RGs 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
 We’ve 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
 We’ve Introduced a “Bad” Coupling
Solution: Extended Refactoring Guidelines to
Govern all Potential Scenarios for Removing
“Bad” Couplings
REUSE--81
Extended RGs for Type 3 Couplings





Move Coupling Dst. to General Class
or Change Dst. To a General Class
 Type 3 to Type 1
 May Introduce Couplings from G
Dst. to Specific Classes
G Type 3 G
Move Coupling Src. to Specific Class
or Change Src. To a Specific Class
 Type 3 to Type 7
S
S
 May Introduce Couplings from
General Classes to Specific Src.
Change to Non-Related/Follow Type 4 Among Related
Detailed Evaluation of Implementation
Key Concerns
 Local Changes with Global Impact
 “Wrong” Choice Degrades Reuse
REUSE--82
Removing Type 3 Couplings in HTSS
Which Changes Make Sense?

InvCont
Type 1
Item

Type 3
DeliIC
DeliItem
Type 7



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
REUSE--83
Extended RGs for Type 2 Couplings





Move Coupling Src. to Specific Class
or 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 Class
or Change Dst. To a Specific Class
 Follow Type 4 Guidelines
Change to Related/Type 1/Design
Impact Must be Evaluated!
Detailed Evaluation of Implementation
Type 2
G
G
S
S
Non-Related
REUSE--84
Extended RGs for Type 4 Couplings




Move Coupling Dst. to General Class
or Change Dst. To a General Class
 Type 4 to Type 2 - No Help
Move Coupling Src. to Specific Class
or 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
G
Type 4 G
S
S
Non-Related
REUSE--85
Summary on Extended
Refactoring 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
But: Refactoring 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 Java Applications/Libraries
REUSE--86
Utilizing Reuse Methodology
Evaluate Evolving Design/Implementation



Constructing New Applications
 Software Design Proceeds in Stages
 Today’s 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 Identify and Refactor
“Problems” in Application
Video Rental System Test-Bed
REUSE--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
REUSE--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
REUSE--89
General and Specific Classes in VRS-1
CustomerDB (G)
StoreInterface (G)
Customer (G)
HistoryList (G)
VideoStoreInterface (S)
VideoCustomer (S)
Transaction (G)
CustomerInterface (G)
VideoCustomerInterface (S)
RentedTape (S)
Item (G)
VideoTape (S)
RentedTapeDB (S)
ItemDB (G)
VideoTapeDB (S)
REUSE--90
DRE and VRS-1
Tracking 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
REUSE--91
Final General/Specific Classes in VRS-2
and Some Related Characterizations
Item (G)
Video (S)
Transaction (G)
Customer (G)
VideoTransaction (S)
CustomerList (G)
ItemList (G)
ReportGenerator (S)
VideoCustList (S)
VideoItemList (S)
StoreInterface (G)
CustomerInterface (G)
VideoStoreInterface (S)
REUSE--92
DRE and VRS-2
Tracking 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
LOC 17
Cls. 5/1
32
5/1
30
7/6
30
7/6
G/S
REUSE--93
One Type 3 Coupling: G to S Dependency
Customer (G)
take_item( )
Transaction (G)
...
tr->calculate_currentdate()
tr->calculate_duedate()
tr->write_to_historyfile()
tr->write_to_checkoutfile()
...
calculate_currentdate()
calculate_duedate()
write_to_historyfile()
VideoTransaction (S)
• What is the Problem?
• How is it Resolved?
write_to_checkoutfile()
REUSE--94
Resolving Type 3 G to S Dependency
with a Refactoring
Transaction (G)
Customer (G)
take_item( )
...
tr->calculate_currentdate()
tr->calculate_duedate()
tr->write_to_historyfile()
take_item_specific()
...
calculate_currentdate()
calculate_duedate()
write_to_historyfile()
VideoTransaction (S)
VideoCustomer(S)
write_to_checkoutfile()
take_item_specific()
((VideoTransaction *) tr)
-> write_to_checkoutfile()
REUSE--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
REUSE--96
The FinancialFrame Application
Initial 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 (G 0 )
YieldModel (G 0 )
1
IndexBond (G )
1
Discount (G )
1
Bill (G )
...
REUSE--97
Evaluation of FinancialFrame
Possible Scenarios

Dependencies from G 0 to G1 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 (G 0 )
YieldModel (G 0 )
1
IndexBond (G )
1
Discount (G )
1
Bill (G )
...
REUSE--98
Revising FinancialFrame Application
YieldModel (G 0 )
1
Bond (G )
R
1
(G
)
IndexBond
1
(G
)
Discount
1
(G
)
Bill
...
0
1
G
G
 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
REUSE--99
Evaluation of FinancialFrame
Possible Scenarios
YieldModel (G 0 )
1
Bond (G )

R
1
(G
)
IndexBond
1
(G
)
Discount
1
(G
)
Bill
...
Dependencies fromG1 to G1 Classes
 Occurring from a Specific Class to Other
Classes Specific & Unrelated to a Component
 Bond Related to G1 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)
REUSE--100
Reusability of FinancialFrame
Components




Undesirable Couplings Identified via Scenarios can
be Refactored (Removed) to Increase Reuse
Results of Such Actions w.r.t. FinancialFrame
0
1
 G Classes can be Reused with G Classes
1
G
 When a
Class is Modified, Only Users of
Particular Component(s) are Notified
Bad 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
REUSE--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
Refactor “Bad” or “Okay” Couplings to
Improve Reusability
DRE can be Utilized in Different Ways
 Evaluate Evolving Design/Implementation
 Investigate the Reusability of Legacy Code
REUSE--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
REUSE--103
SDRE - Main Application Window
REUSE--104
SDRE - Main Window – Setting
Generality
REUSE--105
SDRE - Main Window – Setting Relations
REUSE--106
SDRE - Main Window – Choosing
Simulation Options
REUSE--107
SDRE - Help Subsystem

HTML-based Documents Describe Tool & Theory
REUSE--108
SDRE - Graphical Representation
Generality Set for Design
REUSE--109
SDRE - Graphical Representation
Setting Related Classes
REUSE--110
SDRE - Graphical Icons for Classes
Inheritance Edge Base
Relative Edge Base
Generality Base
Base Rectangle
Source File Name
Select Base
Inheritance Edge
Related Edge
REUSE--111
SDRE - Graphical Representation
REUSE--112
SDRE - Editing Source Code
Enabled When Doubling Clicking
REUSE--113
SDRE - Editing Source Code
Editor Appears with Line Highlighted
REUSE--114
SDRE - Editing Source Code
Source Editor Features
REUSE--115
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 RealWorld Computing Environment


REUSE--116
CDRE – DRE Client
REUSE--117
CDRE – Client Login
REUSE--118
CDRE – Project Selection
REUSE--119
CDRE – Remote Class Selection
REUSE--120
Together DRE (TDRE)



Integrating DRE into Together
 Ongoing Prototyping Integrate SDRE
 Utilization of Together Extension Capabilities
to Allow Generality and Related to be Set
 Initiation of Complete SDRE tool via Plug-In
Capabilities of Together
Single Integrated Design/Development
Environment with Reusability Assessment
Leverage Together 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 Together
REUSE--121
Reusability in Together
REUSE--122
Reusability in Together
REUSE--123
Reusability in Together
REUSE--124
Reusability in Together
REUSE--125
Overview of Presentation – Part 2

Reusability in OMT and UML
 Exploring OMT Reuse Concepts (Predecessor
to UML)
 Integrating Reuse into the Design Process
 Extending UML to Support Reuse w/Refactoring
 Realizing Changes in Together via RGs


Exploring Reusability Assessment Automation
 Towards the Formalization of a Reusability
Framework for Refactoring, ICSR 7
 A Graph-Based Algorithm for Automated
Refactoring, JIISIC 2003
Reusability Modeling – Considering Reuse from a
Different Perspective
REUSE--126
UML and Software Reuse



Revisiting OO Reuse Framework/Methodology
Examine M. Price’s Work on Subject:
 Inserting Reusability Evaluations in OO
Methodologies
 Case Study of OMT (Predecessor of UML)
Premise and Assumptions
 Three Stage Process in OMT
Analysis, System Design, Object Design
 Produces: Object, Dynamic, Functional Models
 Company X Working on ATM Software with
Future Product Automated Gas Pump (AGP)
REUSE--127
Example Domain and Future Product



ATM Example from Rumbaugh
Computerized Banking Network of ATMs
 ATM Accepts Card, Interacts with User,
Communicates with Central Computer,
Dispenses Cash, and Prints Receipt
 Each Bank has its own Computer System
 Design Software for ATMs and Network
Future Product of Company X
 Reuse and Exploit ATM/Network Solution
 Design/Develop Automated Gas Pump (AGP)
REUSE--128
Stage 1: Domain/Problem Analysis

Specification of Problem Requirements
 Limits/Capabilities of ATM/Network
 Current and Future Objectives/Applications
 What Products will be Developed in Future?






ATM/Network for all Banks
ATM/Network for Specific Banks
ATM/Network for Retail Store Access
Pay-at-the-Pump System for Gas Stations
Don’t work in Vacuum
Anticipate and Detail Future Products
REUSE--129
Sample Problem Analysis
ATM vs. AGP



Difference in Usage
 ATM: Bank Employs Cashiers and Owns ATM
 AGP: Pay Inside or at Pump - Not Bank Empl.
Differences in UI
 AGP: Limited Options w.r.t. Use of ATM Card
Other Options for Credit, Debit, etc.
Other Services, e.g., Car Wash at Discount
 ATM: Deposits, Withdrawals, Transfers,
Account Queries
Leverage Similarities and Differences to Organize
Software for Reuse
REUSE--130
Construct an Object Model


General/Specific Classes and Related Components
Some Examples in ATM
Bank
EMPLOYS
Bank
Cashier
Customer
name
address
HAS
Account
balance
type
Bank
Cashier
Bank
EMPLOYS
ATM
Bank
REUSE--131
Dynamic Model, Functional Model,
Verification/Iteration




State Diagrams for Dynamic Behavior of Classes
 Generate Additional Classes and Operations
 General/Specific/Related and Impact
Construct a Functional Model of Behavior
 Inputs and Outputs via DFDs
 Recall OMT Emphasis!
Verify, Iterate, and Refine
 Object, Dynamic, Functional Models
 Reapply Metrics to Evolving Design
What are Implications re. UML?
REUSE--132
Stage 2: System Design




Facets of System Design
 Organize System into Subsystems
 Identify Concurrency
 Allocate Subsystems to Processors/Tasks
Which is Most Relevant for OO Reuse?
What do Facets Resemble in UML?
Goal:
 Identify Modules and Components
 Develop a Component Hierarchy
 Recall HTSS Component Breakdown
REUSE--133
Stage 3: Object Design


From Design Towards Implementation
 New Classes, Attributes, Operations
 Impact on Existing Reuse Characterizations
Example - Bi-directional Related Classes:
Consortium
ATM
What is Potential Problem with ATM?
OWNS
ATM
Consortium
req_password
verify_account
dispense_cash
print_receipt
verify_card
process_trans
OWNS
REUSE--134
Resolving via Redesign
Reusability from ATP to AGP
Auto Machine
Consortium
req_password
verify_account
print_receipt
verify_card
process_trans
OWNS
ATM
Attendant
dispense_cash
process_manual_trans
monitor_transactions
COMMUNICATES
WITH
REUSE--135
From OMT to UML



Prior Work Concentrated on Reuse Framework and
Integration with OMT
UML has Succeeded OMT
What are Implications re. Reuse Framework?
 Class and Object Diagrams
Can Reuse be Tightly Integrated?
 How can Use-Case Diagrams be Utilized?
 Are Statechart, Activity, or Collaboration
Diagrams Relevant?
 What is Role of Component Diagrams?
 Is there a Role for Deployment Diagrams?
REUSE--136
Reusability and UML
Eickhoff, Ellis, Demurjian, Needham




Extend Our Reuse Model Framework to UML
 Establishing Generality and Related in UseCase 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)?
 Incorporate into Together/Transition to DRE
Build and Extend the Formal Model (Caballero)
Appearing in Advances in UML and XML-Based
Software Evolution
REUSE--137
Recall Three Key Definitions
REUSE--138
Revisiting Reuse Properties
Implementation of X is more
Specific than that of Y.
X.F Might Contain Couplings to
Classes Marked Specific.
However, per Property 2, Y
Must be at Least as General
as X
REUSE--139
Revisiting Reuse Properties
REUSE--140
Revisiting Reuse Types
REUSE--141
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
Define Additional Properties
Introduce Refactoring Guidelines that Enforce the
Properties of Reuse for UML Diagrams
REUSE--142
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
REUSE--143
Use Cases with
Include, Extend, and Inheritance


Dependencies Among Use Cases
Dependencies are Transitive w.r.t. Generalities
REUSE--144
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.

REUSE--145
Corresponding Refactoring Guidelines


RG1 or RG2 to Enforce Property 4 or Property 5:
 The refactoring rule is: If GUC-B > 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 > GUC-B then
refactor by making UCA more general (or UCA
more specific) so GUC-A  GUC-B or or by
removing the generalization.
REUSE--146
Identifying Problems
RG3 for Pay Cash


RG2 for Place Order: to G2 or Remove <include>
RG3 for Pay Cash: to G1 or Arrange Payment to
G0 or Remove <generalization>
REUSE--147
UML Reuse and Class Diagrams


Definition 3: UCA is related to ℭA = {C1 , C2 , …,
Cn } for some n, if UCA relies on ℭA for
functionality.
Property 7: UCs and Classes - Generality


Suppose UCA has ℭA = {C1 , C2 , …, Cn }. Then, the
generality of UCA must be as specific as the most
specific class in ℭA , and may be more specific, i.e.,
GUC-A = max{generality  Ci  ℭA }.
RG4 to Enforce Property 7

The refactoring rule is: generality change of UCA or
one or more Ci in ℭA until GUC-A = max{generality 
Ci  ℭA }, or the removal of all classes in ℭA that cause
the GUC-A = max{generality  Ci  ℭA } to be
violated.
REUSE--148
Classes and Generality Levels
CPlace Order ={Order Container, Order, ItemDB } COrder Product = {Item }
COrder Computer ={Computers } C- Order Car = {Cars } CRequest Catalog ={Catalog }
CSupply Customer Data = {Customer, DB Access } CArrange Payment = {Payment }
REUSE--149
UML Reuse and Class Diagrams


Property 8: UCs and Classes - Related
 Suppose that UCA is related to ℭA and UCB is
related to ℭB . If UCA is related to UCB (extend,
include, or generalize), then there has to be at
least one transitive relation chain from one Ci
 ℭA to one Cj  ℭB.
RG5 to Enforce Property 8
 The refactoring rule is: Add one or more
dependencies between class(es) Ci  ℭA and
class(es) Cj  ℭB, or remove the relation
between UCA and UCB
REUSE--150
UML Reuse and Class Diagrams


Property 9: UCs to UCs - Related
 Suppose that UCA is related to ℭA and UCB is
related to ℭB , and that UCA is not related to
UCB (no extend, include, or generalize). Then,
if at least one Ci  ℭA is directly related to at
least one Cj  ℭB, there must be a refactoring.
RG6 to Enforce Property 9
 The refactoring rule is: make UCA related to
UCB or remove all dependencies between all Ci
 ℭA and all Cj  ℭB.
REUSE--151
UML Reuse and Class Diagrams


Property 10: UCs and Classes - Related
 Suppose that UCA is related to ℭA. Then for all
Ci  ℭA , if there is a transitive relation chain
from Ci to some Cj  ℭA, then UCA must also
be related to Cj in some manner. UCA can be
either related directly to Cj or it can be related
to some UCB, to which Cj is related
RG7 to Enforce Property 10
 The refactoring rule is:  Ci  ℭA related to
some Cj  ℭA include Cj in ℭA (ℭA= ℭA  Cj),
or relate UCA to some UCB where Cj  ℭB, or
unrelate UCA to Ci (ℭA= ℭA - Cj).
REUSE--152
Refactored UC Diagram
from Earlier Slide
REUSE--153
UML Reuse and Behavior Diagrams


Sequence and Collaboration Diagrams Can Also
Impact on Reuse - Why?
 Both Alter Dependencies
 Introduce/Remove Associations
For Example:
 Sequence Diagram Can Introduce New
Dependencies Among Classes (ℭ Sets)
 Collaboration Diagram Could Also Introduce
Similar Dependencies that Require Refactoring
 See Paper for Details
REUSE--154
UML Reuse and Component Diagrams



Definitions for UML Components
 Definition 4: Component and Classes that
Implement it
 Definition 5: Component and Façade that hides
Implementation Details
 Definition 6: Component and Abstract
Classes/Interfaces
Accompanying Properties/Refactoring Guidelines
 Property 11/RG8 - Components vs. Classes
 Property 12/RG9 - Component vs. Component
 Property 13/RG10 - Component vs. Façade
See Section 3.4 of Paper for Further Details
REUSE--155
Modifications to Together




Leverage Open APIs and Plug In Structure to
Incorporate Reuse Model for UML into Together
Multi-Phase Approach
 Directly Extend Property Windows of Use
Cases and Classes for Generality Definition
 Augment with new Window for Related
 Add New Metrics Pane that Supports Analysis
as Presented (Definitions, Properties, and RGs)
Briefly, we’ll Review Modifications
Please See Web Site for Full Details
REUSE--156
Setting Project Options
REUSE--157
UC: Generality and Related
REUSE--158
Classes: Generality and Related
REUSE--159
Components and Facades
REUSE--160
Class Screen with Reuse Pane
REUSE--161
Use Case Screen with Reuse Pane
REUSE--162
Use Case Screen with Reuse Pane
REUSE--163
Class Screen with Reuse Pane
REUSE--164
Running DRE and Metrics
REUSE--165
Analyzing Reuse and Refactoring



Affected Elements: Elements affected by
warning.
Description: Provides a description of the warning
Refactoring Guideline: One or more refactoring
guidelines for the currently selected warning
REUSE--166
Together: DRE-UML Warnings




Use Case Diagrams:
 Generalities and Related Classes
 Dependencies to other Use Cases (include,
extend, generalize)
Class Diagrams:
 Generalities and Related Classes
 Dependencies to other Classes (association,
dependency, generalization)
Sequence/Collaboration Diagrams: Method Calls
Component Diagrams:
 Related and Façade Classes
 Implemented Interfaces
 Dependencies of Components and Interfaces
REUSE--167
Towards the Formalization of a
Reusability Framework for Refactoring


Formal Definitions of Reuse Model to Allow
Automatic and Algorithmic Analysis of Couplings
 Cabellero and Demurjian at ICSR-7, 2002
 OO Application Model
 Reuse Framework
 Automatically Refactors to “Improve” Reuse
Introduce Coupling Type Transition Matrix
 Defines Loss, Gain, or Steady State Between
the Various Coupling Types
 +1 Going from G-->S to G-->G for Related Classes
 -1 Going from G-->G to G-->S for Related Classes
 0 Going from S-->G to S-->S for Related Classes
REUSE--168
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
See: http://www.engr.uconn.edu/~steve/DRE/dre.html
REUSE--169
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
REUSE--170
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
m4
m9
Cq
m1
mi
m20
mj
m9
m5
m18
REUSE--171
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
REUSE--172
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 Organization’s Future Systems
REUSE--173
Model - Class Reusability


Definition 3: The Reusability Level of Class Ci is
Denoted by Gci
 Gci=0  Ci is the Most General Class in the
Application
 Gci=N (N>0)  Ci is the Most Specific Class
in the Application
 Lower N, More General Class
 GC 
Class Generality Vector
  

 
G   GCi 


  
GCn 
1
REUSE--174
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
Aside:
 Unrelated Classes are NOT Expected to be
Reused Together
 Dependencies Among them Hinder Reuse
REUSE--175
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 Don’t Contribute to Functionality
of Component have Negative Impact on Reuse
Property 4: Generality and Unrelated Classes
 Couplings Between Unrelated Classes Hinder
Reuse
REUSE--176
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
REUSE--177
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
Bad (Type 3)
Okay (Type 5)
S
S
Okay (Type 7)
REUSE--178
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)
G
G
Bad (Type 4)
Okay (Type 6)
S
S
Okay (Type 8)
REUSE--179
Sample Actions to Improve Reusability
Coupling
Among Related
Among Unrelated
GG
Type (1)
Good for Reuse
Type (2)
Bad for Reuse
Move Src./Dst. to Specific
GS
Type (3)
Bad for Reuse
Move Dst. to General
Type (4)
Bad for Reuse
Move Src. To Specific
SG
Type (5)
Can Improve if Move
Src. to General
Type (6)
No Impact on Reuse
SS
Type (7) - Can Improve Type (8)
if Move Src./Dst. to Gen. No Impact on Reuse
REUSE--180
Core Guidelines to Move Couplings to
Increase Reuse Potential
Type 1
G
S
Type 3
Type 1
G
G
G
G
S
S
S
S
Type 1
G
S
Type 7
Type 5
Type 2
G
Type 3 G
G
G
G
Type 4 G
S
S
S
S
S
S
Type 7
Type 8
Type 8
REUSE--181
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
REUSE--182
Coupling Transitions
Related Classes
Unrelated Classes
REUSE--183
Reuse Improvement Factor


Metric of the Loss, Gain, or Steady State Between
the Various Coupling Types After the Refactoring
Defined by
n
n
   [tij ][ ~tij ]
i 0 j 0
where  is the Matrix for all Transitions Among the
Eight Coupling Types in One Step
 If  > 0  Refactoring had Negative Reuse
Impact
 If  < 0  Refactoring had Positive Reuse
Impact
 If  = 0  Refactoring had No Impact on
Reuse
REUSE--184
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
REUSE--185
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
n
n
   [tij ][ ~tij ]
i 0 j 0
Step 8: If Reuse Factor <= 0 Goto Step 6 Else Goto
Step 5 or Terminate Based on Condition
REUSE--186
Additional Slides

Augment Slides from Main Portion of Talk

Replace Slide 143 on Refactoring Algorithm

Note: All Material in in ICSR Paper!
REUSE--187
Graph Content and Matrix
REUSE--188
Algorithm Steps
REUSE--189
Algorithm Steps
REUSE--190
Algorithm Steps
REUSE--191
Algorithm Steps
REUSE--192
Algorithm Steps
REUSE--193
Algorithm Steps
REUSE--194
Algorithm Steps
REUSE--195
Algorithm Steps
REUSE--196
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
REUSE--197
Example - Generality and Related
Steps 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
G
G
G
G
S
S
S
REUSE--198
Example - Determine Coupling Types
Step 4 of Algorithm
G
G
G
G
S
S
S
REUSE--199
Example - Identify Undesirable Couplings
Step 5 of Algorithm
G
G
G
G
S
S
S
REUSE--200
Example - Refactor the Application
Step 6 of Algorithm
m3

For (m3,m5) Try to Move Source Method Down
0

0
0

~ 0
T 
0
0

0
0

0 3 0 0 0 0 0

0 0 0 0 0 0 0
0 0 0 7 0 0 0

1 0 0 0 3 0 3
0 0 0 0 0 5 0 
0 0 0 0 0 0 0

0 0 0 0 0 0 0
0 0 0 0 0 0 0 
  1  1  0
No Improvement!
REUSE--201
Example - Refactor the Application
Step 6 of Algorithm
m4

For (m4,m6) Try to Move Source Method Down
0

0
0

~ 0
T 
0
0

0
0

0 1 0 0 0 0 0

0 0 0 0 0 0 0
0 0 0 3 0 0 0

5 0 0 0 7 0 7
0 0 0 0 0 5 0 
0 0 0 0 0 0 0

0 0 0 0 0 0 0
0 0 0 0 0 0 0 
  1  1  1  1
Commit the Changes
~
Set T=T
REUSE--202
Example - Refactor the Application
Step 6 of Algorithm
m5
m4

For (m5,m7) try to Move Source Method Up
0

0
0

~ 0
T 
0
0

0
0

0 1 0 0 0 0 0

0 0 0 0 0 0 0
0 0 0 1 0 0 0

5 0 0 0 7 0 7
0 0 0 0 0 1 0 
0 0 0 0 0 0 0

0 0 0 0 0 0 0
0 0 0 0 0 0 0 
  1  1  2
Commit the Changes
~
Set T=T
REUSE--203
Example - Refactored Class Diagram
G
G
G
G
S
S
S
REUSE--204
Future: Formal Reuse Model




Future Work
 Exploring Weightings (+2, +3, -3, etc.) for
Transitions Among Coupling Types
Explore and Refine the Reuse Model
 Theoretical Verification of Reuse Model
 Use of Genetic Algorithm to Obtain “Near”
Optimal Marking
Practical Perspective
 Integrating Metric and Model in SDRE
 Testing with “Real” Examples and Prior
Examples
Extend Model to Apply to UML Reuse (see Next
Group of Slides)
REUSE--205
A Graph-Based Algorithm
for Automated Refactoring


Extending the Formal Definitions of Reuse Model
to Allow Automatic and Algorithmic Refactoring
 Cabellero and Demurjian at JIISIC 2003
 Automatically Refactors to “Improve” Reuse
Model Couplings as a Directed Acyclic Graphy
 Graph Represents Dependencies
 Nodes Represent Classes
 Edges Represent Couplings



Assign Generalities to Subject of Graph
Induce Remaining Generalities
Employ Topological Sort and Refactoring
Algorithms
REUSE--206
Goal



Reuse Metric, Framework and Tool
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
Applications to
 Newly Created OO Designs
 Evaluation of the Reuse Potential of Legacy
Code
REUSE--207
Class Reusability



Idea: “Best Estimate” on Potential Utility of Class
Purpose: Identify the Classes with Highest Reuse
Potential for Organization’s Future Systems
General Classes
 Application Classes that Facilitate Domainand-Organization Specific Reuse
 Expected to be Reused in Future Applications
 Abstract Classes/Root Classes/Non-Leaf
Classes in Inheritance Hierarchies
 Domain Independent/Domain Specific
REUSE--208
Class Reusability



Specific Classes
 Application Classes that are Limited to use in a
Single Application
 Only Applicable in Current Applications
 Unlikely to be Reused in Future Applications
 Application Specific
Reusability Level of Class C is GC{0,1,…N}
 GC = N  C is the most general class in the
application
 GC = 0  C is the most specific class in the
application
Retail Application : Class Item is General, While
Class WalmartItem is More Specific.
REUSE--209
Relations Among Classes




Idea: Grouping of Classes that are Expected to Be
Reused Together in Future Applications
 Related Classes Promote Reuse, Since They are
Expected to be Reused Together
 Subjectively Assigned by Software Engineer
(Producer)
Related Classes Assist in Reusability Assessment
If Class X is Related to Class Y then
 When X is “Reused”, Y is Brought Along and
Dependencies from X to Y are Encouraged
 When Y is “Reused”, X in Not Brought Along
and Dependencies from Y to X Hinder Reuse
Unidirectional
REUSE--210
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
Inheritance Relations
etc…
REUSE--211
Quantifying Reuse Properties



Generality and Inheritance
 Parent of a Class is Equally General or More
General than is Direct Children
Generality and Related Classes
 Reuse Level of Class is Equal to the Reuse
Level of the Least Reusable Coupled Class
Generality and Unrelated Classes
 Couplings Between Unrelated Classes Hinder
Reuse
REUSE--212
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
Bad (Type 3)
Ok (Type 5)
S
S
Ok (Type 7)
REUSE--213
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)
G
G
Bad (Type 4)
Ok (Type 6)
S
S
Ok (Type 8)
REUSE--214
Sample Actions to Improve Reusability
Coupling
Among Related
Among Unrelated
GG
Type (1)
Good for Reuse
Type (2)
Bad for Reuse
Move Src./Dst. to Specific
GS
Type (3)
Bad for Reuse
Move Dst. to General
Type (4)
Bad for Reuse
Move Src. To Specific
SG
Type (5)
Can Improve if Move
Src. to General
Type (6)
No Impact on Reuse
SS
Type (7) - Can Improve Type (8)
if Move Src./Dst. to Gen. No Impact on Reuse
REUSE--215
Graph Based Refactoring



Classes are Modeled as a Directed Graph
 Nodes Represent Classes
 Edges Represent Couplings
Topological Sorting Arranges of a Directed
Acyclic Graph into a Precedence Order
 G=(V,E) is a DAG
 If (u,v)E then u appears before v in ordering
Reference Vertices
 Set of Vertices of G Such that have been
Assigned a Generality Level
 Starting Point of the Analysis
 Set of Classes Intended as General or Specific
REUSE--216
Consistency
The Topological Ordering of a Graph is Consistent
with the Generality Level of the Reference
Vertices
 IF for all Reference Vertices u,v such that ru<rv,
and there is no Directed Path from v to u in the
Graph
 THEN u appears before v in the Topological
Ordering 5
2
R= {1,3,8,9}

4
8
1
6
3
9
7
r1=S, r3=G, r8=G, r9=S
r1=S, r3=G, r8=G, r9=G
r1=S, r3=S, r8=G, r9=S
r1=G, r3=G, r8=S, r9=G
r1=G, r3=G, r8=G, r9=S
REUSE--217
Consistent Topological Order
R= {1,3,8,9}
r1=S, r3=G, r8=G, r9=S
2
5
4
8
1
6
3
9
7
T=(1,3,2,4,6,5,8,9,7)
T=(1,3,7,2,4,5,9,6,8)
T=(1,2,4,5,9,6,8,3,7)
T=(1,2,4,3,7,6,9,5,8)
T=(1,3,2,6,4,9,7,5,8)
…
T=(1,2,3,6,7,4,5,8,9)
REUSE--218
Topological Sort Consistent With Reference Vertices
REUSE--219
Induced Generality Level


Generality Level Assignment is Induced from the
Graph Topology and the Reference Vertices
Algorithm Shows Conflicts Between Assignment
to the Reference Vertices and Topological Order
REUSE--220
Refactoring Algorithm




1 Assign Generality Level to Reference Classes
2 For Each Connected Sub-Graph Find the Induced
Generality Level
3 For Each Class where Induced Generality Level is in
Conflict with Generality Assigned by SWE
 Apply Refactoring
 If the Sub-Graph Changed as a Result of the
Refactoring Re-Calculate the Induced Generality
Levels
 If There Are Still Remaining Conflicts, Reassign
Generality Levels to Reference Vertices and Goto 2
Re-Asses the Induced Generality Levels, if They Are
Consistent With the Design Objectives Terminate.
Otherwise Goto 2.
REUSE--221
Algorithm Steps
REUSE--222
Algorithm Steps
REUSE--223
Algorithm Steps
REUSE--224
Algorithm Steps
REUSE--225
Algorithm Steps
REUSE--226
Pull Up Method/Pull Up Field

Conditions:
Cp
Cp
Cj
C<
Ci
Cj
Ck
Ci
Ck
C>
REUSE--227
Push Up Method/Push Up Field

Conditions:
Cu
C'<
Cj
Cq
Cu
Cv
Ci
C'>
Cj
Cv
Cq
Ci
REUSE--228
Example
REUSE--229
Example
G
S

Reference Vertices

Topological Sorting

Induced Generality
Level
REUSE--230
Example
G
G
S
S

Reference Vertices

Topological Sorting

Induced Generality Level
REUSE--231
Refactoring
Push-Up m4
Push-Down m3
REUSE--232
Class Diagram After Refactoring
G
G
G
G
S
S

S
Re-Calculate Induced Generality
REUSE--233
Conclusions



Extended Reusability Framework Proposed by
Price and Demurjian
Proposed a New Refactoring Algorithm
 Uses Graph Theory Elements
 Guides Refactoring Process
 Improves Software Structure From Reuse
Perspective
Algorithm Based On
 Topological Sorting of the Class Diagram
 Calculation of Induced Generality Levels for
all Nodes
 Provides Guidelines for Refactoring
REUSE--234
Ongoing and Future Work


Shortfalls
 No Empirical Evidence that the Proposed
Algorithm Works on Real Designs!
 Software Engineer Strongly Involved in
Refactoring
Related to Presented Work:
 Extend/Refine/Reformulate Reusability Model
 Incorporate Refactoring Algorithm into Tool
 More Realistic Examples to Gather Empirical
Evidence of the Utility of Our Algorithm
REUSE--235
Reusability Model, Layers, & Framework



Application is Designed with Abstractions (Class,
Interface, Package, Component)
Apply the Reuse Framework to the Classes,
Interfaces, Packages, and Components
 Assign Generality Levels
 Determine Related Classes, Components
 Iterate Until Obtain Marking that is Consistent
with the Goals/Objectives of Application
Problem: Is it Possible to Organize or
Compartmentalize the Application’s Classes,
Interfaces, Packages, and Components From
Different Perspectives Based on Requirements?
 Compartments - Previously Called Layers
 Represent Chunks of Functionality
REUSE--236
Reuse Model Issues from Last Meeting


Clarify/Redefine “Related” Characterization
 Transitivity of “Related”
 W R to A, B, and C vs. W R to A, B, or C
Common Definitions for Package/Component
 How is Marking of Package/Component
Determined?
 “Least” General Class Sets Package/Component
Generality
Packages/Components Must Obey All
Generality Rules of the Model/Framework
Inclusion of Interfaces into Model/Framework
Design Patterns and Impact on Reuse
Layering and the Reuse Model (Our Focus)




REUSE--237
Problem Domain Layering

Notion of General/Specific Impacted by Layering?
Layer
Component
Common
Person
Manufacturing
Part
Shipbuilding
Not OK
Company-Specific
Piping-Part
OK
Sub-Piping-Part
REUSE--238
Recall Levels of Generality
Root classes for Items, ItemDB,
etc., which are Most General.
(G 0 )
Inventory Control/Other Components.
(G1 )
Classes Specific to Grocery Store Domain.
(G 2 )
Specific Applications for Big Y or Shaw’s or Stop/Shop (S)

Dependencies Encouraged Up Through the Layers
 From S to G(0) or G(1)
REUSE--239
Transition to Layers of Generality
Root classes for
Items, ItemDB,
(G 0 )
Inventory Control
Other Components.
(G1 )


Classes Specific to (G 2 )
Grocery Store Domain.
Limit Interactions Among
Layers
 Only Adjacent Layer
Allowed
 Impose Strong Reuse
Penalty Otherwise
Issues
 Can Layer Contain
Multiple Levels of G?
 Red Class with
 G(1), G(2), G(3)
Within Level, Established
Reuse Principles Apply
Can There be Layers within
Layers?

Big Y or Shaw’s
or Stop/Shop (S)

REUSE--240
Another Example of Levels of Generality

Root classes for
Items, ItemDB,

Inventory Control
Other Components.
Classes for
Large
Supermarket
Big Y or Shaw’s
or Stop/Shop
Classes for
Specialty
Supermarket

Assume: Each Layer Can
Contain Multiple Levels
What Happens When Different
Groupings within Layers?
 Can Groups Interact?
 What are Dependency
Issues?
Classes for
24 Hour
Convenience
Do We have Lattice Rather
Than a Layers and Levels?
REUSE--241
Recall the Different Abstractions


Classes and Hierarchies
 Building Blocks of
Application
 Independent Classes
of All Types
 Generalization and
Specialization
Interfaces
 “Specification” of
Behavior
 Never Instantiated
Note: We Must Reconcile “Our”
and EB Abstraction Definitions


Packages
 Organize Classes and/or
Hierarchies into Named
Conceptual Units
Components
 Application-Oriented
 Logical and Physical
Associations of
Interfaces, Classes,
Packages
 Purpose: Represent a
“Meaningful” Chunk of
Functionality
 This is a Design Time
Component (e.g., a
Non-Instantiated Bean)!
REUSE--242
Relating the Different Abstractions
Interface
Class
Component
Package
Contains - Type Level
Uses - Instance Level
REUSE--243
Abstractions and Application
INT_1
CL6
CL1
INT_2
Package A
INT_3
CL9
CL3
CL2
CL4
CL5
Component X
INT_4
Package B
Component Y
CL7
Package C
INT_6
INT_5
CL8
REUSE--244
Abstractions and Compartments
Some Sample Compartments?
INT_1
CL6
CL1
INT_2
Package A
INT_3
CL9
CL3
CL2
CL4
CL5
Component X
INT_4
Package B
Component Y
CL7
Package C
INT_6
INT_5
CL8
REUSE--245
Proposed Problem Solution





Define “Reusability Node” to Represent the
Different Compartments of Application’s Classes,
Interfaces, Packages, and Components
Specify the Rules for:
 Composition of a Reusability Node
 Dependencies Among Reusability Nodes
With these Rules, Result is a Reusability Graph of
Reusability Nodes with Reusability Dependencies
Reusability Graph can be Layered
Objectives:
 Formally Define Reusability Node,
Dependency, Graph, and Layer
 Can we Automate the Process When Given
Source Code for Application?
REUSE--246
Definition 1: Reusability Node




A Reusability Node (RN) is a Set of Classes (Cl),
Packages (P), Interfaces (I), and Components (Co)
Marked With Varying Levels of Generality
Entities in RN Must Satisfy Current Reuse
Analysis w.r.t. General/Specific/Related, Coupling
Counts, etc.
RNx INT_1
CL1
RNx as Shown on Right
CL3
Classes, Packages,
CL2
INT_2
INT_3
Interfaces, Components
CL4
are Labeled as follows:
Component X
CL5
Package B
 G xi for i = 1 …nx
are nx Generality levels
REUSE--247
Assumptions: Reusability Node




Is the Makeup and Content of a RN Constrained?
What are Possible Constraints on RNx ?
Levels of Generality
 At Most 3 Different Generality Levels
Replication
 Classes in Exactly One RN
 Can Packages/Components
RNx INT_1
CL1
be in Multiple RNs?
CL3
CL2
 Interfaces Can be in One
INT_2
INT_3
or More Different RNs
CL4
Component X
 Do Components/Packages
CL5
Package B
have Generality Level?
REUSE--248
Objective: Reusability Node



Given Source Code (Classes, Interfaces, Packages,
and Components) for Application, is it Possible to
Dynamically/Automatically Determine all RNs?
What is Needed for this to Occur?
 Each Class, Interface,
Package, Component
RNx INT_1
CL1
Must be Marked with
CL3
Generality Level
CL2
INT_2
INT_3
 Related Dependencies
CL4
for Reuse are Defined
Component X
CL5
Package B
 Parser that Synthesizes
All of the Source Code
Dependencies
Is this Problem NP Hard? Complete?
REUSE--249
Aside: Marking Components/Packages




A Component/Package can Contain Components,
Classes, and Interfaces
 Remember, Class CL1 can be Defined in
Package B and Used in Component X
 Or, Component X can be Used in Package B
Components/Packages Must Run Through Reuse
Metrics/Analysis to Eliminate Bad Dependencies
Package not Marked Since Utilize Portions of the
Package and Not Package Itself
Components not Marked or Assumed Most
General
Package B
Component X
REUSE--250
Definition 2: Reusability Dependency


A Reusability Dependency (RD) is a directed
arrow between two Reusability Nodes, RNx and
RNy , which satisfies the following:
 G x for i = 1 …nx < G for j = 1 …ny
yj
i
 RNx is Most General, RNy is Least General
 Arrow from RNy to Rnx
Issues:
 Should it be <= Rather than <?
 < is Preferable, Since it Allows for a Cleaner
Ordering Among Different RNs
 Eliminates Ambiguity in Ordering
REUSE--251
Definition 2: Reusability Dependency

Issues:
 Should Interfaces be Excluded from Ordering?
 If Interfaces Replicated, Same Generality Level?
 If Interfaces Non-Replicated, Include in Ordering?
 Must Support Replicated Interfaces since Different
Classes can Implement Same Interface Differently

Proposal regarding Interfaces
 Interfaces are Not Marked
 When Class “Implements” Interface, the Marking
of the Interface is the Same as the Marking of Class
 Hence, Interface Can have Different Markings in
Different Classes
REUSE--252
Definition 2: Reusability Dependency

Issues:
 Should the Dependencies Between G xi and G y j
be Limited Such That
G x1 Can Only be Dependent on G y n ?
j
 Yes, this Constrains the Constructive Requirements
of the Reusability Graph (See Defn. 3)
 This Constraint with Assumptions of RN (Slide 5)
May Assist in Automated Determination of RDs
 If Both RNs and RDs can be Automated, from
Source Code, Create Reusability Graph (Defn. 3)

That is, Highest Level of Generality in RNy
Can only Dependent on Lowest Level in RNx
REUSE--253
Quantifying a Reusability Dependency
Suppose RNx has Generality Levels of: G0 G1 G2
Suppose RNy has Generality Levels of : G3 G4
Should Dependencies (Class, Method, Attr, etc.) be
Limited to from G3 in RNy to G2 in RNx ?
Or, are Limits Unnecessary?




RNx
CL1
CL3
CL2
INT_1
INT_2
INT_3
CL8
CL7
INT_1
INT_4
Package B
CL4
Package B
RNy
CL6
CL5
Component X
Package C
Component Y
REUSE--254
Definition 3: Reusability Graph

A Reusability Graph (RG) is a Directed Graph
with Reusability Nodes (Defn. 1) as Vertices
which are Connected by Reusability Dependencies
(Defn. 2)
RNA
RNC
RND
RNG
RNH
RNF
Issue: Are Cycles Allowed?
RNB
RNE
RNJ
RNI
REUSE--255
Issues: Reusability Graph


Cycles:
 A Cycle Indicates Co-Dependency Among
Multiple Reusability Nodes - D, E, and H
 Does this Imply All Must be Reused Together?
Automation
 Assume that Reusability Nodes can be
Automatically (Algorithmically) Determined
When Given Application’s Source Code
 Can Reusability Graph be Automatically
Derived? Is this NP Hard? Complete?
 Can we Use Genetic Algorithms for Problem?
REUSE--256
Definition 4: Reusability Layer

A Reusability Layer (RL) is a Subset of the RG
that Represents a Grouping of RNs to Satisfy a
Particular Domain or Organization Requirement
RNA
RNC
RNB
RND
RNG
RNH
RNF
RNE
RNJ
RNI
REUSE--257
Issue: What is Scope of a Layer?

Since RNA Depends on RND which Depends on
RNE which Depends on RNH which Depends on
RNB, Should all Form the Layer?
RNA
RNC
RNB
RND
RNG
RNH
RNF
RNE
RNJ
RNI
REUSE--258
Issues: Reusability Layer

Cycles:
 Recall a Cycle Means Co-Dependency Among
Multiple Reusability Nodes - D, E, and H
 If All Must be Reused Together then …
 Will this Impact Layering - Must Layer Always
Contain all Nodes in Cycle?
 Can Layer Contain only Part of Cycle?

Automation
 Intuitively, Automating Layers Doesn’t Make
Sense
 Layer is Domain Specific and Dictated by
Designer
REUSE--259
Future Work
Issues for Layering and Reusability





What are Limitations Across Layers? None???
How are Dependencies Tracked?
 Defn. of RN and RD
Can There be Different Layered Perspectives for
“Same” Design? Can All Layerings Coexist
Together? Are Layerings Application Specific?
 Yes to all Three - As shown on Previous Slide?
What are Issues to Develop a Reuse Model for
Levels and Layers?
 Formal Model and Analysis
 Inter-Layer vs. Intra-Layer Reuse
 Inter-Level vs. Intra-Level Reuse
Is there an EB Example to Demonstrate Ideas?
REUSE--260
Conclusions


Comprehensive Reusability Model and Evaluation
 General/Specific/Related Characterizations
 Capture/Analyze Reusability of OO Software
 Design Level (UML) and Code Level (DRE)
 Achieve Highest Gain Through Early
Identification and Reusability Evaluations!
Methodology and Empirical Verification
 Guidelines to Encourage Reuse
 Applicable to Reuse of Designs and Code
 DRE Tool Family: SDRE, CDRE, TDRE
 Strong Demonstration of
Domain-and-Organization-Specific Reuse
REUSE--261