A framework methodology and tool for reusable software components
Download
1 / 261

A Framework, Methodology and Tool for Reusable Software Components* - PowerPoint PPT Presentation


  • 101 Views
  • Uploaded on

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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' A Framework, Methodology and Tool for Reusable Software Components*' - daktari


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation 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.


Motivation
Motivation Components*

  • 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


Motivation1
Motivation Components*

  • 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


Motivation2
Motivation Components*


Motivation why software reuse
Motivation Components*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


Objectives
Objectives 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

    • Integrated in a Design/Development Environment


Overview of presentation part 1
Overview of Presentation – Part 1 Components*

  • 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


Cultural and social reuse issues management support
Cultural and Social Reuse Issues Components*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


Cultural and social reuse issues high initial cost
Cultural and Social Reuse Issues Components*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


What are components
What are Components? 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


What are components1
What are Components? 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


Defining component concepts
Defining Component Concepts Components*

  • 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


Cultural and social reuse issues reuse and software design development
Cultural and Social Reuse Issues Components*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


Components vs objects

Components 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

Components vs. Objects


Reusable components types benefits

Application Template Components*

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

Reusable Components Types & Benefits


Component based development process
Component-Based Development Process Components*

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.



SUPPLY Components*

Build New

Wrap Existing

Buy

CONSUME

Assemble

Applications

MANAGE

Publish

Subscribe

Catalog

Browse

Supplier /Consumer Model


Component Components*

Specification

Interfaces

Implementation

Executable


Complexity of Component Components*

Components as Assets can Grow


What are component dependencies
What are Component Dependencies? Components*

  • Dependency Type of Components

    • Versions

    • Aggregations

    • Functional

    • Inheritance

    • Association

  • What is Impact of Each Dependency on the Reusability of a Component?


Component based tools web sites of note

Software Composition Workbench Components*

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

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.

Component-Based Tools/Web Sites of Note


Component Repository Components*

Repository

Browser

Hierarchy


Multiple Support Components*

Multiple Repository Support


CBD life cycle Components*

Business

Direction

General Business

Requirements

Component

Requirements

User

Services

Harvest

Business and

Data services

User, Business

and Data services


IDC forecast CBD market Components*

1996: $652 million

2001: $12 billion


Web site references
Web-Site References Components*

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


A framework methodology and tool for reusable software components1
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


A framework methodology and tool for reusable software components2

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

A Framework, Methodology, and Tool for Reusable Software Components

Store &

Document

Designs

Re(Design)

a System

Reusability

Evaluation

Store &

Document

Implemens.

Implement

the System

5

2

1

3

6

4


Subjective identification of component s
Subjective Identification ReusabilityofComponents

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


General specific class characterization
General/Specific Class ReusabilityCharacterization

  • 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


General specific class characterization1
General/Specific Class ReusabilityCharacterization

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


High tech supermarket system htss
High-Tech Supermarket System (HTSS) Reusability

  • 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


The htss software architecture
The HTSS Software Architecture Reusability

EDO

EDO

SDO

SDO

IL

IL

IL

IC

IC

CR

CR

CR

CR

Payment

Item

ItemDB

Local

Server

Order

OrderDB

SupplierDB

CreditCardDB

ATM-BanKDB

ItemDB

Global

Server

Inventory

Control

IL: Item

Locator

DO: Deli Orderer for

Shopper/Employee

Non-Local

Client Int.

CR: Cash Register

IC: Invent. Control


A general class in htss
A General Class in HTSS Reusability

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

};


Another general class in htss
Another General Class in HTSS Reusability

  • Collection Classes of General Classes are General

class ItemDB

{private:

int Num_Items;

int Curr_Item;

Item* AllItems[Max_Items];

int FindFirstItem();

int FindNextItem();

int FindItemUPC(int code);

int FindItemName(char* name);

public:

ItemDB(); // Constructor

void InsertNewItem(Item* new_one);

void DeleteExistingItem(int code);

void FindDisplayItemUPC(int code);

void FindDisplayItemName(char* name);

void PrintAllItems();

};


Yet another general class in htss
Yet Another General Class in HTSS Reusability

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

};


Specific classes in htss
Specific Classes in HTSS Reusability

Item

...

ProduceItem

DairyItem

DeliItem

DeliOrdererGUI

OrdererGUI

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


Levels of general classes
Levels of General Classes Reusability

views as General

if i j

views as Specific

if i < j

S

S

  • 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


Can you identify different levels of general classes
Can you Identify Different Levels Reusabilityof General Classes?

Item

NonPerishItem

PerishItem

ProduceItem

DairyItem

DeliItem

...


Can we identify different levels of general classes
Can we Identify Different Levels Reusabilityof General Classes?

Item

NonPerishItem

PerishItem

ProduceItem

DairyItem

DeliItem

BigYProdItem

DoleProdItem

BigYDairyItem

HoodDairyItem

Where can Item

be Reused?

Where can NonPerishItem and PerishItem

be Reused?

Where can ProduceItem and DairyItem be Reused?

...

Are DoleProdItem and HoodDairyItem Specific?


Properties of general specific classes
Properties of General/Specific Classes Reusability

views as General

if i j

views as Specific

if i < j

S

S

  • 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


Generality and specificity within one inheritance hierarchy
Generality and Specificity Reusabilitywithin One Inheritance Hierarchy


Generality specificity dependencies across multiple hierarchies
Generality/Specificity/Dependencies ReusabilityAcross Multiple Hierarchies


General specific paradigm in htss
General/Specific Paradigm in HTSS Reusability

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


Reusability in htss domain
Reusability in HTSS Domain Reusability

Root classes for Items, ItemDB,

etc., which are Most General.

Inventory Control/Other Components.

Classes Specific to Grocery Store Domain.

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

  • Where do Changes for Other Domains Occur?


Reusability in htss domain1
Reusability in HTSS Domain Reusability

Root classes for Items, ItemDB,

etc., which are Most General.

Inventory Control

Other Components.

Inventory Control Tool for Ordering Items from Suppliers

Cost Accounting Tool for Tracking Net and Gross Profit

Classes Specific to Grocery Store Domain.

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


Reusability in htss domain2
Reusability in HTSS Domain Reusability

Root classes for Items, ItemDB,

etc., which are Most General.

Classes Specific

to Grocery

Store Domain.

Inventory Control/Other Components.

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)


The financialframe application
The FinancialFrame Application Reusability

  • 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


The financialframe application1
The FinancialFrame Application Reusability

  • 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


General and specific classes in financialframe
General and Specific Classes in FinancialFrame Reusability

CashFlowAnalyzer

YieldModel

...

IndexBond

Discount

Bill

FinancialCompDesk

FinancialCompTrader

Main

FinancialCompAccount

...

FinancialCompMain

OtherMain

SpecificOtherMain(S)

SpecificFCMain(S)


Related classes and hierarchies
Related Classes and Hierarchies Reusability

  • Class X is Related to Class Y if they are Related and Concept and are Expected to be ReusedTogether 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 toY 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


Related hierarchies reusable components
Related Hierarchies/Reusable Components Reusability

A Sub-Hierarchies B

S

R

S

S

  • 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


Related characterization in levels of components htss
Related Characterization in ReusabilityLevels of Components - HTSS

Item

NonPerishItem

PerishItem

Environ

R

ProduceItem

DairyItem

DeliItem

SubZero

RTemp

  • Does R from Environ to PerishItem Make Sense?

  • Should R be from PerishItem to Environ?


Related characterizations in levels of components htss
Related Characterizations in ReusabilityLevels of Components - HTSS

Root classes for Items, ItemDB,

etc., which are Most General.

Inventory Control/Other Components.

Classes Specific to Grocery Store Domain.

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

  • Where do Changes for Other Domains Occur?


Related characterization in levels of components financialframe
Related Characterization in ReusabilityLevels of Components - FinancialFrame

Bond

YieldModel

R

...

IndexBond

Discount

Bill

  • Bond is Related to IndexBond

  • When Bond is Reused, so Must IndexBond and YieldModel

  • Hence, IndexBond and its Ancestor (YieldModel) are Reused!


Related characterizations in levels of components financialframe
Related Characterizations in ReusabilityLevels 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)


What are dependencies among classes
What are Dependencies Among Classes? Reusability

  • 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


Goals of the research
Goals of the Research Reusability

  • 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


Reusing sub hierarchies in different components htss
Reusing Sub-Hierarchies in ReusabilityDifferent Components - HTSS

NonPerishItem

PerishItem

Will be reused

with Components

for another domain,

e.g., Toy Store

Will be reused

with Components

for different Super-

market Companies

Item

...

ProduceItem

DairyItem

DeliItem


Reusing sub hierarchies in different components financialframe
Reusing Sub-Hierarchies in ReusabilityDifferent Components - FinancialFrame

Will be reused with Components

utilizing FinancialComp’s database

Main

OtherMain

FinancialCompMain

SpecificOtherMain (S)

SpecificFCMain (S)

Will be reused with Components

utilizing another company’s databases

  • Dependencies Among General Related Classes

    • Not a Hindrance to Reuse

    • Represents Valuable Design Knowledge


Transitivity in inheritance and related relationships
Transitivity in Inheritance and ReusabilityRelated Relationships

R

R

A

B

C

A

X

R

B

C

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

B’s Ancestors to Reuse A


An example of case 1 in financialframe
An Example of Case 1 in FinancialFrame Reusability

FinancialCompTrader

R

Main

OtherMain

FinancialCompMain

  • FinancialCompMain R FinancialCompTraderThus, Dependencies Between are Desirable

  • Main is not R to FinancialCompTraderThus, Dependencies Between Hinder Reuse

  • For “Blue” Component, we Don’t Want to Have to Reuse FinancialCompTrader with Main!


Transitivity in inheritance and related relationships1

Case 2 Reusability: 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!

Transitivity in Inheritance and Related Relationships

A

X

R

B

C


An example of case 2 in financialframe
An Example of Case 2 in FinancialFrame Reusability

Bond

YieldModel

R

...

IndexBond

Discount

Bill

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


Evaluative metrics and methodology objective measures of dependencies
Evaluative Metrics and Methodology ReusabilityObjective 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


Dependencies among related classes
Dependencies Among Related Classes Reusability

Good (1)

G

G

Bad (3)

Okay (5)

S

S

Okay (7)

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

  • The Two G classes are Related

  • Related Classes are Intended to be Reused Together


Sample dependencies in htss
Sample Dependencies in HTSS Reusability

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


Dependencies among non related classes
Dependencies Among Non-Related Classes Reusability

Bad (2)

G

G

Bad (4)

Okay (6)

S

S

Okay (8)

  • 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


Sample dependencies in htss1
Sample Dependencies in HTSS Reusability

InvCont

DeliIC

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

Bad(2)

Person

Bad (4)

Okay (6)

Shopper

Okay (8)


Summarizing couplings of related classes
Summarizing Couplings of ReusabilityRelated 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


Summarizing couplings of non related classes
Summarizing Couplings of ReusabilityNon-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


Dependencies in levels of components summarizing related classes
Dependencies in Levels of Components ReusabilitySummarizing Related Classes

Related to

(1)

(3)

(5)

(1)

(7)

(1)

(3)

(1)

(7)

Related to


Dependencies in levels of components summarizing non related classes
Dependencies in Levels of Components ReusabilitySummarizing Non-Related Classes

(2)

(4)

(4)

  • Dependencies Among Unrelated Classes Always

    • Bad for Reuse

    • No Impact on Reuse

(6)

(2)

(8)

(2)

(2)

(8)


Sample actions to improve reusability changes are refactorings
Sample Actions to Improve Reusability ReusabilityChanges are Refactorings!


Reuse guidelines
Reuse Guidelines Reusability

  • 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


Core refactoring guidelines to move couplings to increase reuse potential
Core Refactoring Guidelines to Move Couplings to Increase Reuse Potential

Type 2

Type 1

G

G

G

G

S

S

S

S

Type 8

Type 3

G

G

Type 1

Type 1

G

G

Type 4

G

G

G

G

S

S

Type 7

S

S

S

S

S

S

Type 5

Type 7

Type 8


Extended refactoring guidelines for improving reusability
Extended Refactoring Guidelines for Reuse PotentialImproving 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


Extended refactoring guidelines to improve reuse identifying the problem
Extended Refactoring Guidelines to Improve Reuse - Identifying the Problem

Suppose

G

G

G

m()

Type 3

Recall

G

Type 3

G

S

S

S

S

G

G

G

Type 7

S

Type 7

m()

S

What has Occurred?


Extended refactoring guidelines to improve reuse identifying the problem1
Extended Refactoring Guidelines to Improve Reuse - Identifying the Problem

Suppose

G

G

G

Recall

S

Type 5

m()

S

Type 1

Type 1

G

G

G

G

G

m()

S

S

S

S

Type 5

What has Occurred?


Problem and solution
Problem and Solution Identifying the Problem

  • 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


Extended rgs for type 3 couplings
Extended RGs for Identifying the ProblemType 3 Couplings

G

Type 3

G

S

S

Among Related

  • 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


Removing type 3 couplings in htss which changes make sense
Removing Identifying the ProblemType 3 Couplings in HTSSWhich Changes Make Sense?

Type 1

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

Item

InvCont

Type 3

DeliIC

DeliItem


Extended rgs for type 2 couplings
Extended RGs for Identifying the ProblemType 2 Couplings

Type 2

G

G

S

S

Non-Related

  • 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


Extended rgs for type 4 couplings
Extended RGs for Identifying the ProblemType 4 Couplings

G

Type 4

G

S

S

Non-Related

  • 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


Summary on extended refactoring guidelines
Summary on Extended Identifying the ProblemRefactoring 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


Utilizing reuse methodology evaluate evolving design implementation
Utilizing Reuse Methodology Identifying the ProblemEvaluate 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


Utilizing reuse methodology investigate reusability of legacy code
Utilizing Reuse Methodology Identifying the Problem 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


The video rental system vrs
The Video Rental System (VRS) Identifying the Problem

  • 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


General and specific classes in vrs 1
General and Specific Classes in VRS-1 Identifying the Problem

CustomerDB (G)

HistoryList (G)

Transaction (G)

StoreInterface (G)

VideoStoreInterface(S)

RentedTapeDB(S)

RentedTape(S)

Item (G)

ItemDB (G)

VideoTape(S)

VideoTapeDB(S)

Customer (G)

VideoCustomer(S)

CustomerInterface (G)

VideoCustomerInterface(S)


Dre and vrs 1 tracking incremental versions
DRE and VRS-1 Identifying the ProblemTracking Incremental Versions


Final general specific classes in vrs 2 and some related characterizations
Final General/Specific Classes in VRS-2 Identifying the Problemand Some Related Characterizations

Transaction (G)

CustomerList (G)

Item (G)

StoreInterface (G)

Customer (G)

Video(S)

VideoStoreInterface(S)

VideoTransaction(S)

ReportGenerator(S)

ItemList (G)

CustomerInterface (G)

VideoCustList(S)

VideoItemList(S)


Dre and vrs 2 tracking incremental versions
DRE and VRS-2 Identifying the ProblemTracking Incremental Versions


One type 3 coupling g to s dependency
One Type 3 Coupling: G to S Dependency Identifying the Problem

Transaction (G)

Customer (G)

take_item( )

...

tr->calculate_currentdate()

tr->calculate_duedate()

tr->write_to_historyfile()

tr->write_to_checkoutfile()

...

calculate_currentdate()

calculate_duedate()

write_to_historyfile()

VideoTransaction(S)

write_to_checkoutfile()

  • What is the Problem?

  • How is it Resolved?


Resolving type 3 g to s dependency with a refactoring
Resolving Type 3 G to S Dependency Identifying the Problemwith a Refactoring

Transaction (G)

Customer (G)

take_item( )

calculate_currentdate()

calculate_duedate()

write_to_historyfile()

...

tr->calculate_currentdate()

tr->calculate_duedate()

tr->write_to_historyfile()

take_item_specific()

...

write_to_checkoutfile()

VideoTransaction (S)

VideoCustomer(S)

take_item_specific()

((VideoTransaction *) tr)

-> write_to_checkoutfile()


Utilizing reuse methodology investigate reusability of legacy code1
Utilizing Reuse Methodology Identifying the Problem 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


The financialframe application initial assumptions on g s and related
The FinancialFrame Application Identifying the ProblemInitial 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

...

IndexBond

Discount

Bill


Evaluation of financialframe possible scenarios
Evaluation of FinancialFrame Identifying the ProblemPossible 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

...

IndexBond

Discount

Bill


Revising financialframe application
Revising FinancialFrame Application Identifying the Problem

YieldModel

...

R

IndexBond

Discount

Bill

Bond

  • 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


Evaluation of financialframe possible scenarios1
Evaluation of FinancialFrame Identifying the ProblemPossible Scenarios

YieldModel

...

R

IndexBond

Discount

Bill

Bond

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


Reusability of financialframe components
Reusability of FinancialFrame Components Identifying the Problem

  • Undesirable Couplings Identified via Scenarios can be Refactored (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


Design reusability evaluation dre tool
Design Reusability Evaluation (DRE) Tool Identifying the Problem

  • 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


The dre tool family
The DRE Tool Family Identifying the Problem

  • 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


Sdre main application window
SDRE - Main Application Window Identifying the Problem


Sdre main window setting generality
SDRE - Identifying the ProblemMain Window – Setting Generality


Sdre main window setting relations
SDRE - Identifying the ProblemMain Window – Setting Relations


Sdre main window choosing simulation options
SDRE - Identifying the ProblemMain Window – Choosing Simulation Options


Sdre help subsystem
SDRE - Help Subsystem Identifying the Problem

  • HTML-based Documents Describe Tool & Theory


Sdre graphical representation generality set for design
SDRE - Graphical Representation Identifying the ProblemGenerality Set for Design


Sdre graphical representation setting related classes
SDRE - Graphical Representation Identifying the ProblemSetting Related Classes


Sdre graphical icons for classes
SDRE - Graphical Icons for Classes Identifying the Problem

Inheritance Edge Base

Generality Base

Relative Edge Base

Base Rectangle

Source File Name

Select Base

Inheritance Edge

Related Edge


Sdre graphical representation
SDRE - Graphical Representation Identifying the Problem


Sdre editing source code enabled when doubling clicking
SDRE - Identifying the ProblemEditing Source Code Enabled When Doubling Clicking


Sdre editing source code editor appears with line highlighted
SDRE - Identifying the ProblemEditing Source CodeEditor Appears with Line Highlighted


Sdre editing source code source editor features
SDRE - Identifying the ProblemEditing Source CodeSource Editor Features


Collaborative dre cdre
Collaborative DRE (CDRE) Identifying the Problem

  • 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


Cdre dre client
CDRE – DRE Client Identifying the Problem


Cdre client login
CDRE – Client Login Identifying the Problem


Cdre project selection
CDRE – Project Selection Identifying the Problem


Cdre remote class selection
CDRE – Remote Class Selection Identifying the Problem


Together dre tdre
Together DRE (TDRE) Identifying the Problem

  • 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


Reusability in together
Reusability in Together Identifying the Problem


Reusability in together1
Reusability in Together Identifying the Problem


Reusability in together2
Reusability in Together Identifying the Problem


Reusability in together3
Reusability in Together Identifying the Problem


Overview of presentation part 2
Overview of Presentation – Part 2 Identifying the Problem

  • 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


Uml and software reuse
UML and Software Reuse Identifying the Problem

  • 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 OMTAnalysis, System Design, Object Design

    • Produces: Object, Dynamic, Functional Models

    • Company X Working on ATM Software with Future Product Automated Gas Pump (AGP)


Example domain and future product
Example Domain and Future Product Identifying the Problem

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


Stage 1 domain problem analysis
Stage 1: Domain/Problem Analysis Identifying the Problem

  • 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


Sample problem analysis atm vs agp
Sample Problem Analysis Identifying the ProblemATM 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 CardOther 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


Construct an object model
Construct an Object Model Identifying the Problem

EMPLOYS

Bank

HAS

Customer

name

address

Bank

Cashier

Bank

Cashier

Account

balance

type

Bank

EMPLOYS

ATM

Bank

  • General/Specific Classes and Related Components

  • Some Examples in ATM


Dynamic model functional model verification iteration
Dynamic Model, Functional Model, Verification/Iteration Identifying the Problem

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


Stage 2 system design
Stage 2: System Design Identifying the Problem

  • 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


Stage 3 object design
Stage 3: Object Design Identifying the Problem

ATM

Consortium

Consortium

verify_card

process_trans

OWNS

ATM

req_password

verify_account

dispense_cash

print_receipt

OWNS

  • From Design Towards Implementation

    • New Classes, Attributes, Operations

    • Impact on Existing Reuse Characterizations

  • Example - Bi-directional Related Classes:

What is Potential Problem with ATM?


Resolving via redesign reusability from atp to agp
Resolving via Redesign Identifying the ProblemReusability from ATP to AGP

Auto Machine

req_password

verify_account

print_receipt

OWNS

Consortium

verify_card

process_trans

Attendant

process_manual_trans

monitor_transactions

ATM

dispense_cash

COMMUNICATES WITH


From omt to uml
From OMT to UML Identifying the Problem

  • Prior Work Concentrated on Reuse Framework and Integration with OMT

  • UML has Succeeded OMT

  • What are Implications re. Reuse Framework?

    • Class and Object DiagramsCan 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?


Reusability and uml eickhoff ellis demurjian needham
Reusability and UML Identifying the ProblemEickhoff, Ellis, Demurjian, Needham

  • Extend Our Reuse Model Framework to 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)?

    • Incorporate into Together/Transition to DRE

  • Build and Extend the Formal Model (Caballero)

  • Appearing in Advances in UML and XML-Based Software Evolution


Recall three key definitions
Recall Three Key Definitions Identifying the Problem


Revisiting reuse properties
Revisiting Reuse Properties Identifying the Problem

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


Revisiting reuse properties1
Revisiting Reuse Properties Identifying the Problem


Revisiting reuse types
Revisiting Reuse Types Identifying the Problem


Reuse definition assessment and analysis in uml
Reuse Definition, Assessment, and Analysis in UML Identifying the Problem

  • 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


Use cases with generalities

Application has Three Systems Identifying the Problem

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

Use Cases with Generalities


Use cases with include extend and inheritance
Use Cases with Identifying the ProblemInclude, Extend, and Inheritance

  • Dependencies Among Use Cases

  • Dependencies are Transitive w.r.t. Generalities


Properties for use cases
Properties for Use Cases Identifying the Problem

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


Corresponding refactoring guidelines
Corresponding Refactoring Guidelines Identifying the Problem

  • 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 UCAmore 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 UCAmore specific) so GUC-A GUC-B or or by removing the generalization.


Identifying problems rg3 for pay cash
Identifying Problems Identifying the ProblemRG3 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>


Uml reuse and class diagrams
UML Reuse and Class Diagrams Identifying the Problem

  • 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 Ciinℭ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.


Classes and generality levels
Classes and Generality Levels Identifying the Problem


Uml reuse and class diagrams1
UML Reuse and Class Diagrams Identifying the Problem

  • Property 8: UCs and Classes - Related

    • Suppose that UCA is related to ℭA and UCB is related to ℭB . If UCAis 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


Uml reuse and class diagrams2
UML Reuse and Class Diagrams Identifying the Problem

  • Property 9: UCs to UCs - Related

    • Suppose that UCA is related to ℭA and UCB is related to ℭB , and that UCAis not related to UCB (noextend, 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.


Uml reuse and class diagrams3
UML Reuse and Class Diagrams Identifying the Problem

  • 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).


Refactored uc diagram from earlier slide
Refactored UC Diagram Identifying the Problemfrom Earlier Slide


Uml reuse and behavior diagrams
UML Reuse and Behavior Diagrams Identifying the Problem

  • 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


Uml reuse and component diagrams
UML Reuse and Component Diagrams Identifying the Problem

  • 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


Modifications to together
Modifications to Together Identifying the Problem

  • 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


Setting project options
Setting Project Options Identifying the Problem


Uc generality and related
UC: Generality and Related Identifying the Problem


Classes generality and related
Classes: Generality and Related Identifying the Problem


Components and facades
Components and Facades Identifying the Problem


Class screen with reuse pane
Class Screen with Reuse Pane Identifying the Problem


Use case screen with reuse pane
Use Case Screen with Reuse Pane Identifying the Problem


Use case screen with reuse pane1
Use Case Screen with Reuse Pane Identifying the Problem


Class screen with reuse pane1
Class Screen with Reuse Pane Identifying the Problem


Running dre and metrics
Running DRE and Metrics Identifying the Problem


Analyzing reuse and refactoring
Analyzing Reuse and Refactoring Identifying the Problem

  • 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


Together dre uml warnings
Together: DRE-UML Warnings Identifying the Problem

  • 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


Towards the formalization of a reusability framework for refactoring
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


Goal Refactoring

  • 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


Model of oo application
Model of OO Application Refactoring

  • 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


Model pair wise couplings
Model - Pair-wise Couplings Refactoring

  • 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


Basis of reuse framework
Basis of Reuse Framework Refactoring

  • 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


Class reusability
Class Reusability Refactoring

  • 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


Model class reusability
Model - Class Reusability Refactoring

  • 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

  • Class Generality Vector


Model relations among classes
Model - Relations Among Classes Refactoring

  • 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


Quantifying reuse properties
Quantifying Reuse Properties Refactoring

  • 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


Dependencies among classes
Dependencies Among Classes Refactoring

  • 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


Dependencies related classes
Dependencies: Related Classes Refactoring

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


Dependencies non related classes
Dependencies: Non-Related Classes Refactoring

G

G

S

S

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



Core guidelines to move couplings to increase reuse potential
Core Guidelines to Move Couplings to Increase Reuse Potential

Type 2

Type 1

G

G

G

G

S

S

S

S

Type 3

Type 8

G

G

Type 3

Type 1

Type 1

G

G

Type 4

G

G

G

G

S

S

Type 7

S

S

S

S

S

S

Type 5

Type 7

Type 8


Coupling type transitions
Coupling Type Transitions Potential

  • 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


Coupling transitions
Coupling Transitions Potential

Related Classes

Unrelated Classes


Reuse improvement factor
Reuse Improvement Factor Potential

  • 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  > 0  Refactoring had Negative Reuse Impact

    • If  < 0  Refactoring had Positive Reuse Impact

    • If  = 0  Refactoring had No Impact on Reuse


Motivation of refactoring algorithm
Motivation of Refactoring Algorithm Potential

  • 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


Refactoring algorithm
Refactoring Algorithm Potential

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 <= 0 Goto Step 6 Else Goto Step 5 or Terminate Based on Condition


Additional slides
Additional Slides Potential

  • Augment Slides from Main Portion of Talk

  • Replace Slide 143 on Refactoring Algorithm

  • Note: All Material in in ICSR Paper!



Algorithm steps
Algorithm Steps Potential


Algorithm steps1
Algorithm Steps Potential


Algorithm steps2
Algorithm Steps Potential


Algorithm steps3
Algorithm Steps Potential


Algorithm steps4
Algorithm Steps Potential


Algorithm steps5
Algorithm Steps Potential


Algorithm steps6
Algorithm Steps Potential


Algorithm steps7
Algorithm Steps Potential


Example assumptions
Example - Assumptions Potential

  • 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


Example generality and related steps 1 2 3 of algorithm
Example - Generality and Related PotentialSteps 1, 2, 3 of Algorithm

G

G

G

G

S

S

S

  • Establish Class Reusability

    • C1, C2, C4, C6 General

    • C3, C5, C7  Specific

  • Calculate Couplings

  • Assume all Classes are Related Classes to One Another


Example determine coupling types step 4 of algorithm
Example - Determine Coupling Types PotentialStep 4 of Algorithm

G

G

G

G

S

S

S


Example identify undesirable couplings step 5 of algorithm
Example - Identify Undesirable Couplings Potential Step 5 of Algorithm

G

G

G

G

S

S

S


Example refactor the application step 6 of algorithm
Example - Refactor the Application Potential Step 6 of Algorithm

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

m3

No Improvement!


Example refactor the application step 6 of algorithm1
Example - Refactor the Application Potential Step 6 of Algorithm

Commit the Changes

Set T=T

~

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

m4


Example refactor the application step 6 of algorithm2
Example - Refactor the Application Potential Step 6 of Algorithm

Commit the Changes

Set T=T

~

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

m5

m4


Example refactored class diagram
Example - Refactored Class Diagram Potential

G

G

G

G

S

S

S


Future formal reuse model
Future: Formal Reuse Model Potential

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


A graph based algorithm for automated refactoring
A Graph-Based Algorithm Potentialfor 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


Goal Potential

  • 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


Class reusability1
Class Reusability Potential

  • 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 Domain-and-Organization Specific Reuse

    • Expected to be Reused in Future Applications

    • Abstract Classes/Root Classes/Non-Leaf Classes in Inheritance Hierarchies

    • Domain Independent/Domain Specific


Class reusability2
Class Reusability Potential

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


Relations among classes
Relations Among Classes Potential

  • 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


Dependencies among classes1
Dependencies Among Classes Potential

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


Quantifying reuse properties1
Quantifying Reuse Properties Potential

  • 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


Dependencies related classes1
Dependencies: Related Classes Potential

Good (Type 1)

G

G

Bad (Type 3)

Ok (Type 5)

S

S

Ok (Type 7)

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

  • The Two G classes are Related

  • Related Classes are Intended to be Reused Together


Dependencies non related classes1
Dependencies: Non-Related Classes Potential

Bad (Type 2)

G

G

Bad (Type 4)

Ok (Type 6)

S

S

Ok (Type 8)

  • G/S are Subjectively Assigned by Designer

  • The Two G Classes are Not Related

  • Non-Related Classes are NOT Intended to be Reused Together



Graph based refactoring
Graph Based Refactoring Potential

  • 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


Consistency
Consistency Potential

  • 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

R= {1,3,8,9}

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


Consistent topological order
Consistent Topological Order Potential

R= {1,3,8,9}

r1=S, r3=G, r8=G, r9=S

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)



Induced generality level
Induced Generality Level Potential

  • 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


Refactoring algorithm1
Refactoring Algorithm Potential

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


Algorithm steps8
Algorithm Steps Potential


Algorithm steps9
Algorithm Steps Potential


Algorithm steps10
Algorithm Steps Potential


Algorithm steps11
Algorithm Steps Potential


Algorithm steps12
Algorithm Steps Potential


Pull up method pull up field
Pull Up Method/Pull Up Field Potential

  • Conditions:


Push up method push up field
Push Up Method/Push Up Field Potential

  • Conditions:


Example
Example Potential


Example1
Example Potential

  • Reference Vertices

  • Topological Sorting

  • Induced Generality Level

G

S


Example2
Example Potential

  • Reference Vertices

  • Topological Sorting

  • Induced Generality Level

G

G

S

S


Refactoring
Refactoring Potential

Push-Up m4

Push-Down m3


Class diagram after refactoring
Class Diagram After Refactoring Potential

G

G

G

G

S

S

S

  • Re-Calculate Induced Generality


Conclusions
Conclusions Potential

  • 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


Ongoing and future work
Ongoing and Future Work Potential

  • 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


Reusability model layers framework
Reusability Model, Layers, & Framework Potential

  • 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 model issues from last meeting
Reuse Model Issues from Last Meeting Potential

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


Problem domain layering
Problem Domain Layering Potential

  • Notion of General/Specific Impacted by Layering?

    LayerComponent

    Common Person

    Manufacturing Part

    Shipbuilding Piping-Part

    Company-Specific Sub-Piping-Part

Not OK

OK


Recall levels of generality
Recall Levels of Generality Potential

  • Dependencies Encouraged Up Through the Layers

    • From S to G(0) or G(1)

Root classes for Items, ItemDB,

etc., which are Most General.

Inventory Control/Other Components.

Classes Specific to Grocery Store Domain.

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


Transition to layers of generality
Transition to Layers of Generality Potential

Root classes for

Items, ItemDB,

Inventory Control

Other Components.

Classes Specific to

Grocery Store Domain.

Big Y or Shaw’s

or Stop/Shop (S)

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


Another example of levels of generality
Another Example of Levels of Generality Potential

Classes for

Large

Supermarket

Classes for

Specialty

Supermarket

Classes for

24 Hour

Convenience

  • Assume: Each Layer Can Contain Multiple Levels

  • What Happens When Different Groupings within Layers?

    • Can Groups Interact?

    • What are Dependency Issues?

  • Do We have Lattice Rather Than a Layers and Levels?

Root classes for

Items, ItemDB,

Inventory Control

Other Components.

Big Y or Shaw’s

or Stop/Shop


Recall the different abstractions

Classes and Hierarchies Potential

Building Blocks of Application

Independent Classes of All Types

Generalization and Specialization

Interfaces

“Specification” of Behavior

Never Instantiated

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)!

Recall the Different Abstractions

Note: We Must Reconcile “Our”

and EB Abstraction Definitions


Relating the different abstractions
Relating the Different Abstractions Potential

Contains - Type Level

Uses - Instance Level

Interface

Class

Component

Package


Abstractions and application
Abstractions and Application Potential

INT_1

CL6

CL1

CL9

INT_2

INT_3

Package A

CL3

CL2

CL4

CL5

Component X

INT_4

Package B

Component Y

CL7

Package C

INT_5

INT_6

CL8


Abstractions and compartments some sample compartments
Abstractions and Compartments PotentialSome Sample Compartments?

INT_1

CL6

CL1

CL9

INT_2

INT_3

Package A

CL3

CL2

CL4

CL5

Component X

INT_4

Package B

Component Y

CL7

Package C

INT_5

INT_6

CL8


Proposed problem solution
Proposed Problem Solution Potential

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


Definition 1 reusability node
Definition 1: Reusability Node Potential

RNx

CL1

INT_1

CL3

CL2

INT_2

INT_3

CL4

Component X

CL5

Package B

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

  • RNxas Shown on Right

  • Classes, Packages, Interfaces, Components are Labeled as follows:

    • for i = 1 …nxare nx Generality levels


Assumptions reusability node
Assumptions: Reusability Node Potential

RNx

CL1

INT_1

CL3

CL2

INT_2

INT_3

CL4

Component X

CL5

Package B

  • 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/Componentsbe in Multiple RNs?

    • Interfaces Can be in One or More Different RNs

    • Do Components/Packageshave Generality Level?


Objective reusability node
Objective: Reusability Node Potential

RNx

CL1

INT_1

CL3

CL2

INT_2

INT_3

CL4

Component X

CL5

Package B

  • 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 Must be Marked with Generality Level

    • Related Dependencies for Reuse are Defined

    • Parser that SynthesizesAll of the Source CodeDependencies

  • Is this Problem NP Hard? Complete?


Aside marking components packages
Aside: Marking Components/Packages Potential

  • 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

Component X

Package B


Definition 2 reusability dependency
Definition 2: Reusability Dependency Potential

  • A Reusability Dependency (RD) is a directed arrow between two Reusability Nodes, RNxand RNy, which satisfies the following:

    • for i = 1 …nx < for j = 1 …ny

    • RNxis Most General, RNyis Least General

    • Arrow from RNyto Rnx

  • Issues:

    • Should it be <= Rather than <?

      • < is Preferable, Since it Allows for a Cleaner Ordering Among Different RNs

      • Eliminates Ambiguity in Ordering


Definition 2 reusability dependency1
Definition 2: Reusability Dependency Potential

  • 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


Definition 2 reusability dependency2
Definition 2: Reusability Dependency Potential

  • Issues:

    • Should the Dependencies Between and be Limited Such That Can Only be Dependent on ?

      • 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 RNyCan only Dependent on Lowest Level in RNx


Quantifying a reusability dependency
Quantifying a Reusability Dependency Potential

RNx

CL1

INT_1

CL3

CL2

INT_2

INT_3

RNy

CL6

INT_1

CL4

Component X

CL8

CL7

CL5

INT_4

Package B

Package B

Component Y

Package C

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


Definition 3 reusability graph
Definition 3: Reusability Graph Potential

RNA

RNH

RNE

RND

RNC

RNB

RNG

RNF

RNI

RNJ

  • A Reusability Graph (RG) is a Directed Graph with Reusability Nodes (Defn. 1) as Vertices which are Connected by Reusability Dependencies (Defn. 2)

Issue: Are Cycles Allowed?


Issues reusability graph
Issues: Reusability Graph Potential

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


Definition 4 reusability layer
Definition 4: Reusability Layer Potential

RNA

RNH

RNE

RND

RNC

RNB

RNG

RNF

RNI

RNJ

  • A Reusability Layer (RL) is a Subset of the RG that Represents a Grouping of RNs to Satisfy a Particular Domain or Organization Requirement


Issue what is scope of a layer
Issue: What is Scope of a Layer? Potential

RNA

RNH

RNE

RND

RNC

RNB

RNG

RNF

RNI

RNJ

  • Since RNA Depends on RND which Depends on RNE which Depends on RNH which Depends on RNB, Should all Form the Layer?


Issues reusability layer
Issues: Reusability Layer Potential

  • 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


Future work issues for layering and reusability
Future Work PotentialIssues 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?


Conclusions1
Conclusions Potential

  • 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 ofDomain-and-Organization-Specific Reuse


ad