A framework methodology and tool for reusable software components
This presentation is the property of its rightful owner.
Sponsored Links
1 / 261

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


  • 73 Views
  • Uploaded on
  • Presentation posted in: General

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

Download Presentation

A Framework, Methodology and Tool for Reusable Software Components*

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

  • 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

  • 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


Motivation why software reuse

MotivationWhy Software Reuse?

  • Increase Software Productivity

  • Shorten Software Development Time

  • Improve Software System Interoperability

  • Develop Software With Fewer People

  • Move Personnel More Easily From Project to Project

  • Reduce Software Development and Maintenance Costs

  • Produce More Standardized Software

  • Produce Better Quality Software

  • Provide a Powerful Competitive Advantage


Objectives

Objectives

  • Reuse as Equal Partner Starting with Design

    • Iterative Reusability Evaluations at Early and All Stages of Design and Development

    • Production of Large Reusable Components

  • Capabilities of Evaluation Techniques

    • Identify the Reusable Portions of Design

    • Estimate/Measure Reusability Automatically

    • Provide Guidelines on Improving Reusability

    • Usable for

      • Newly Created Designs

      • Evaluation of Legacy Code for Reuse Potential

    • Integrated in a Design/Development Environment


Overview of presentation part 1

Overview of Presentation – Part 1

  • Cultural and Social Reuse Issues

  • Component-Based Design - History & Perspective

  • Component-Based Reuse Framework and Methodology

    • Subjective Identification of Components

      • General vs. Specific Classes

      • Related Hierarchies to Quantify Components

    • Objective Measure of Dependencies

      • Classifying Dependencies

      • Measuring Reuse Potential

    • Detailed Reuse Guidelines

      • Methodological Basis for Increasing Reuse

      • Iterative Improvement in Reusability

  • Prototyping: DRE Tool Family/Examples


Cultural and social reuse issues management support

Cultural and Social Reuse IssuesManagement Support

  • Motorola Study: A New Reuse Program there must have Strong/Unequivocal Management Support

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

  • Why? Increased

    • Cost Associated with Constructing Reusable Components

    • Communication, Coordination

    • Education, Training

  • Motorola and Raytheon Facilitate by Incentives

    • Both Producer and Consumer Benefits

    • Awards Provided for Demonstrated Efforts


Cultural and social reuse issues high initial cost

Cultural and Social Reuse IssuesHigh 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?

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

  • 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

  • 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 IssuesReuse and Software Design/Development

  • Lesson Learned

    • Reuse Often Avoided by SW Engineers due to Fear of Configuration Management Problems

  • How is Fear Minimized?

    • Reuse as Integral Part of Development Process

    • Reuse Early and Often

    • Tools that Facilitate Producer Logging Component and Consumer Finding Component

  • Summary

    • We’ll Concentrate on Technical Reuse Issues

    • Superior Techniques Will Remain Unpopular and Unused without Associated Support


Components vs objects

Components

Business Oriented

Coarse Grained

Standards Based

Multiple Interfaces

Provide Services

Fully Encapsulated

Understood by Everyone

Objects

Technology-Oriented

Fine Grained

Language Based

Single Interface

Provide Operations

Use Inheritance

Understood by Developers

Components vs. Objects


Reusable components types benefits

Application Template

Data Model

Data Structure

System Architecture

Process Model

Process Definition

Prototype

Plan Skeleton

User Interface Skeleton/GUI

Process Skeleton

Utility Components

Organizational Perspective

Shorten Development Time

Reduce Costs

Increase Competitiveness

Personnel Perspective

Increase Productivity

Customer Perspective

Achieve Greater User Satisfaction Through the Production of More Flexible Products

Reusable Components Types & Benefits


Component based development process

Component-Based Development Process

TOP-DOWN:

To determine what is needed to satisfy this need.

OTHERS:

Consider the similarity among concurrent projects.

FUTURE:

Consider the possibility of reusing in future projects.

BOTTOM-UP:

To determine what is available to satisfy this need.


A framework methodology and tool for reusable software components

CBD: Component-Based Development


A framework methodology and tool for reusable software components

SUPPLY

Build New

Wrap Existing

Buy

CONSUME

Assemble

Applications

MANAGE

Publish

Subscribe

Catalog

Browse

Supplier /Consumer Model


A framework methodology and tool for reusable software components

Component

Specification

Interfaces

Implementation

Executable


A framework methodology and tool for reusable software components

Complexity of Component

Components as Assets can Grow


What are component dependencies

What are Component Dependencies?

  • Dependency Type of Components

    • Versions

    • Aggregations

    • Functional

    • Inheritance

    • Association

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


Component based tools web sites of note

Software Composition Workbench

JavaBeans

Visual Café

Visual J++

Sun’s Forte

Enabler, Softlab

Microsoft Repository

UREP, Unisys

Select Software Tools, Select

Reusable Software Research Group, West Virginia University

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


A framework methodology and tool for reusable software components

Component Repository

Repository

Browser

Hierarchy


A framework methodology and tool for reusable software components

Multiple Support

Multiple Repository Support


A framework methodology and tool for reusable software components

CBD life cycle

Business

Direction

General Business

Requirements

Component

Requirements

User

Services

Harvest

Business and

Data services

User, Business

and Data services


A framework methodology and tool for reusable software components

IDC forecast CBD market

1996: $652 million

2001: $12 billion


Web site references

Web-Site References

  • Reusable Software Research Group, West Virginia University

    • http://www.csee.wvu.edu/~resolve/scw/rsrg-brochure-nov-98.html

  • Reusable Software Research Group, Ohio State University

    • http://www.cis.ohio-state.edu/rsrg/index.html

  • Select Software Tools

    • http://www.selectst.com/

  • Software Reuse Executive Primer, DOD

    • http://dii-sw.ncr.disa.mil/ReuseIC/pol-hist/primer/

  • Model-Driven Software Reuse, Extended Intelligence Inc.


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 IdentificationofComponents

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

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

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

  • 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

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

  • 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

  • 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

  • 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

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

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 of General Classes?

Item

NonPerishItem

PerishItem

ProduceItem

DairyItem

DeliItem

...


Can we identify different levels of general classes

Can we Identify Different Levels of 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

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 within One Inheritance Hierarchy


Generality specificity dependencies across multiple hierarchies

Generality/Specificity/DependenciesAcross Multiple Hierarchies


General specific paradigm in htss

General/Specific Paradigm in HTSS

  • Abstraction from HTSS to Domain Independent Inventory Control Application

  • Separation of Supermarket Domain Specifics

  • Leverage Commonalties for

    • Focused, Independent Design/Development

    • Future Products

  • Relevance

    • Domain-and-Organization-Specific Reuse

    • Expand to 24 hour Mom & Pop Stores

    • Expand to Other Retail MarketsE.g., Auto parts, Clothing, Toy, etc.


Reusability in htss domain

Reusability in HTSS Domain

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

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

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

  • 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

  • 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

CashFlowAnalyzer

YieldModel

...

IndexBond

Discount

Bill

FinancialCompDesk

FinancialCompTrader

Main

FinancialCompAccount

...

FinancialCompMain

OtherMain

SpecificOtherMain(S)

SpecificFCMain(S)


Related classes and hierarchies

Related Classes and Hierarchies

  • 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

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 Levels 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 Levels 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 Levels 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 Levels of Components - FinancialFrame

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

Root classes of strategies and

other most General classes (Main)

Bond or other strategy Components

Classes specific to FinancialComp

Specific applications at FinancialComp (S)


What are dependencies among classes

What are Dependencies Among Classes?

  • Three Types of Dependencies:

    • Object Inclusion: Class Contains a Instance of Another Object

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

    • Method Invocation: Class Invokes a Method Defined on Another Object

  • Inheritance is NOT a Dependency

    • Yes – it’s a Relationship – but it is for Reuse

    • However, Represents Shared Behavior

    • Instance X with Parent Y and Grandparent Z is Created as a Single Instance that Includes Y+Z


Goals of the research

Goals of the Research

  • Classify and Understand Dependencies

  • Assess “Good” vs. “Bad” Dependencies

  • Change “Bad” to “Good” by

    • Changing Class from S to G or G to S

    • Moving Code and/or Method Calls

    • Splitting a Class into Two Classes

    • Merging Two Classes

  • These Four Actions (Change, Move, Split, Merge) and Others Represent Refactoring

  • Key Issues:

    • Refactoring Maintains Original Functionality

    • Process Should Not Introduce Problems


Reusing sub hierarchies in different components htss

Reusing Sub-Hierarchies in Different 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 Different 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 Related 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

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

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 MethodologyObjective Measures of Dependencies

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

  • Recall Dependencies Among Classes

    • Object Inclusion: Another Instance within Class

    • Attribute Defn.: Attribute Type of Class

    • Method Invocation: Defined on Another Class

  • Quantify Dependencies for Reuse

    • Good: Promotes Reuse - Leave Alone

    • Bad: Hinders Reuse - Try to Change

    • Okay: No Impact on Reuse - Can be Improved

  • Goals

    • Classify and Understand Dependencies

    • Measure Reuse Potential


Dependencies among related classes

Dependencies Among Related Classes

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

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

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

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 ofRelated Classes

  • Type 1: Good for Reuse

    • Two General Classes are Reused Together

  • Type 3: Bad for Reuse

    • General to Specific

    • To Reuse, Specific Must be Included

    • Added Functionality with No Purpose

    • Change to Type 1 or 5/7 – 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 ofNon-Related Classes

  • Type 2: Bad for Reuse - Two General Classes

    • Not Expected to be Reused Together since Not Related

    • Change to Type 6/8 – 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 ComponentsSummarizing 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 ComponentsSummarizing 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 ReusabilityChanges are Refactorings!


Reuse guidelines

Reuse Guidelines

  • Methodological Basis for Increasing Reuse

    • Designer Supplies General/Specific/Related for the Classes/Hierarchies in Application

    • Reuse Analysis Tool Calculates Couplings and Identifies Types of Reuse (Good, Bad, Okay)

  • Ideal Result: Maximize Reuse via Couplings

    • Type 1: G to G for Related Classes

    • Type 8: S to S for Non-Related Classes

  • Extended Guidelines: Menu of Choices

    • Different Ways to Refactor Couplings

    • Considers Impact of Refactorings on Design

  • Goal: Iterative Improvement in Reusability while Maintaining Application Functionality


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 Improving Reusability

  • Core Refactoring Guidelines Emphasize Local Behavior

  • To Remove “Bad” or Improve “Okay” Coupling, Refactor Cause of the Coupling (e.g., Method Call)

    • Moving a General Method to Specific Class

    • Moving a Specific Method to General Class

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

  • Expand the Analyses to Other Couplings of the Source and Destination of the Bad Coupling

    • Couplings to Source when Moving Down

    • Couplings to Destination when Moving Up

  • Extended Refactoring Guidelines: Menu of Choices


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

  • 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 Type 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 Type 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 Type 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 Type 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 Refactoring Guidelines

  • Total Alternatives for Removing “Bad” Couplings:

    • Type 2, 3, 4: Seven Possibilities Each: 21 Total

    • Type 5, 7: 3 Total

  • Changing from G to S or Movement of Coupling Potential to Impact:

    • Couplings to Source

    • Couplings from Destination

  • But: Refactoring May Decrease Reuse Potential!

  • Two-Fold Solution:

    • Design Support for OO Reuse Metrics and Evaluation within UML, Design Patterns, etc.

    • Analytical Tool for Evaluating Reuse Potential of Java Applications/Libraries


Utilizing reuse methodology evaluate evolving design implementation

Utilizing Reuse MethodologyEvaluate 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 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)

  • 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

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-1Tracking Incremental Versions


Final general specific classes in vrs 2 and some related characterizations

Final General/Specific Classes in VRS-2and 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-2Tracking Incremental Versions


One type 3 coupling g to s dependency

One Type 3 Coupling: G to S Dependency

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 with 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 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 ApplicationInitial Assumptions on G/S and Related

  • FinancialFrame Composed of Multiple Algorithm Familites

  • All Root Classes are G(0) with Subclasses G(1)

  • All Other Classes are G(0)

  • Use Actual Couplings in Code to Define Related Characterization

Bond

YieldModel

...

IndexBond

Discount

Bill


Evaluation of financialframe possible scenarios

Evaluation of FinancialFramePossible Scenarios

  • Dependencies from to Classes

    • Occurring from a General Class (Bond) to Classes Specific to a Component (IndexBond)

    • Such Couplings Require a Specific Class that is Not Needed to be Reused with the General Root

    • Reported as Undesirable Couplings (Type 3/4)

Bond

YieldModel

...

IndexBond

Discount

Bill


Revising financialframe application

Revising FinancialFrame Application

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

  • 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

  • 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

  • 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


Sdre main window setting generality

SDRE - Main Window – Setting Generality


Sdre main window setting relations

SDRE - Main Window – Setting Relations


Sdre main window choosing simulation options

SDRE - Main Window – Choosing Simulation Options


Sdre help subsystem

SDRE - Help Subsystem

  • HTML-based Documents Describe Tool & Theory


Sdre graphical representation generality set for design

SDRE - Graphical RepresentationGenerality Set for Design


Sdre graphical representation setting related classes

SDRE - Graphical RepresentationSetting Related Classes


Sdre graphical icons for classes

SDRE - Graphical Icons for Classes

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


Sdre editing source code enabled when doubling clicking

SDRE - Editing Source Code Enabled When Doubling Clicking


Sdre editing source code editor appears with line highlighted

SDRE - Editing Source CodeEditor Appears with Line Highlighted


Sdre editing source code source editor features

SDRE - Editing Source CodeSource Editor Features


Collaborative dre cdre

Collaborative DRE (CDRE)

  • CDRE Purposes

    • Enable Teams to Collaborate on Metrics Measurement

      • Utilize Client/Server Architecture

      • Share Data Between Users

      • Separate Project Information From Class Markings

      • Store Source Code Centrally

      • Execute Metrics on “Powerful” Server

      • Use Same DRE Interface as Control Client

    • Utilize XML in Redesign Efforts

  • CDRE is Intended to Bring SDRE into a Real-World Computing Environment


Cdre dre client

CDRE – DRE Client


Cdre client login

CDRE – Client Login


Cdre project selection

CDRE – Project Selection


Cdre remote class selection

CDRE – Remote Class Selection


Together dre tdre

Together DRE (TDRE)

  • Integrating DRE into Together

    • Ongoing Prototyping Integrate SDRE

    • Utilization of Together Extension Capabilities to Allow Generality and Related to be Set

    • Initiation of Complete SDRE tool via Plug-In Capabilities of Together

  • Single Integrated Design/Development Environment with Reusability Assessment

  • Leverage Together to Support Reusability

    • Incorporate G/S and Related at UML Level

    • Users can Execute Plug Ins for Each

    • Actual Properties for UML Classes Modified

    • Invoke SDRE Directly from Together


Reusability in together

Reusability in Together


Reusability in together1

Reusability in Together


Reusability in together2

Reusability in Together


Reusability in together3

Reusability in Together


Overview of presentation part 2

Overview of Presentation – Part 2

  • Reusability in OMT and UML

    • Exploring OMT Reuse Concepts (Predecessor to UML)

    • Integrating Reuse into the Design Process

      • Extending UML to Support Reuse w/Refactoring

      • Realizing Changes in Together via RGs

  • Exploring Reusability Assessment Automation

    • Towards the Formalization of a Reusability Framework for Refactoring, ICSR 7

    • A Graph-Based Algorithm for Automated Refactoring, JIISIC 2003

  • Reusability Modeling – Considering Reuse from a Different Perspective


Uml and software reuse

UML and Software Reuse

  • Revisiting OO Reuse Framework/Methodology

  • Examine M. Price’s Work on Subject:

    • Inserting Reusability Evaluations in OO Methodologies

    • Case Study of OMT (Predecessor of UML)

  • Premise and Assumptions

    • Three Stage Process in 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

  • 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

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

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

  • 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

  • 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

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

  • 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 UMLEickhoff, 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


Revisiting reuse properties

Revisiting Reuse Properties

Implementation of X is more

Specific than that of Y.

X.F Might Contain Couplings to

Classes Marked Specific.

However, per Property 2, Y

Must be at Least as General

as X


Revisiting reuse properties1

Revisiting Reuse Properties


Revisiting reuse types

Revisiting Reuse Types


Reuse definition assessment and analysis in uml

Reuse Definition, Assessment, and Analysis in UML

  • Examination of Reuse in …

    • Use Case Diagrams

    • Class Diagrams

    • Behavior Modeling Diagrams

    • Component Diagrams

  • Reuse Improvement During Design

  • Transition from Design into Development

  • Consistency of Approach with Existing Reuse Model and Formal Refactoring Guidelines

  • Define Additional Properties

  • Introduce Refactoring Guidelines that Enforce the Properties of Reuse for UML Diagrams


Use cases with generalities

Application has Three Systems

Each System with One or More Use Case

Each Use Case has Generality Level

Relationships Among Use Cases are:

Extend

Include

Generalize

Generalities Must be Consistent within Systems and Between UCs Given Relationships

Use Cases with Generalities


Use cases with include extend and inheritance

Use Cases with Include, Extend, and Inheritance

  • Dependencies Among Use Cases

  • Dependencies are Transitive w.r.t. Generalities


Properties for use cases

Properties for Use Cases

  • Property 4: UCA extends UCB means UCA adds behavior to UCB, so UCA is at most as general as UCB or GUC-B  GUC-A

  • Property 5: UCA includes UCB is a relation of the behavior sequence of supplier UCB to the interaction sequence UCA. Thus, UCA is at most as general as UCB or GUC-B  GUC-A.

  • Property 6: UCA generalizes UCB relates child UCB to parent UCA, meaning that UCB is at most as general as UCA or GUC-A GUC-B.


Corresponding refactoring guidelines

Corresponding Refactoring Guidelines

  • RG1 or RG2 to Enforce Property 4 or Property 5:

    • The refactoring rule is: If GUC-B > GUC-A then refactor by making UCB more general (or 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 ProblemsRG3 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

  • 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


Uml reuse and class diagrams1

UML Reuse and Class Diagrams

  • Property 8: UCs and Classes - Related

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

  • 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

  • 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 from Earlier Slide


Uml reuse and behavior diagrams

UML Reuse and Behavior Diagrams

  • Sequence and Collaboration Diagrams Can Also Impact on Reuse - Why?

    • Both Alter Dependencies

    • Introduce/Remove Associations

  • For Example:

    • Sequence Diagram Can Introduce New Dependencies Among Classes (ℭ Sets)

    • Collaboration Diagram Could Also Introduce Similar Dependencies that Require Refactoring

    • See Paper for Details


Uml reuse and component diagrams

UML Reuse and Component Diagrams

  • Definitions for UML Components

    • Definition 4: Component and Classes that Implement it

    • Definition 5: Component and Façade that hides Implementation Details

    • Definition 6: Component and Abstract Classes/Interfaces

  • Accompanying Properties/Refactoring Guidelines

    • Property 11/RG8 - Components vs. Classes

    • Property 12/RG9 - Component vs. Component

    • Property 13/RG10 - Component vs. Façade

  • See Section 3.4 of Paper for Further Details


Modifications to together

Modifications to Together

  • Leverage Open APIs and Plug In Structure to Incorporate Reuse Model for UML into Together

  • Multi-Phase Approach

    • Directly Extend Property Windows of Use Cases and Classes for Generality Definition

    • Augment with new Window for Related

    • Add New Metrics Pane that Supports Analysis as Presented (Definitions, Properties, and RGs)

  • Briefly, we’ll Review Modifications

  • Please See Web Site for Full Details


Setting project options

Setting Project Options


Uc generality and related

UC: Generality and Related


Classes generality and related

Classes: Generality and Related


Components and facades

Components and Facades


Class screen with reuse pane

Class Screen with Reuse Pane


Use case screen with reuse pane

Use Case Screen with Reuse Pane


Use case screen with reuse pane1

Use Case Screen with Reuse Pane


Class screen with reuse pane1

Class Screen with Reuse Pane


Running dre and metrics

Running DRE and Metrics


Analyzing reuse and refactoring

Analyzing Reuse and Refactoring

  • Affected Elements: Elements affected by warning.

  • Description: Provides a description of the warning

  • Refactoring Guideline: One or more refactoring guidelines for the currently selected warning


Together dre uml warnings

Together: DRE-UML Warnings

  • Use Case Diagrams:

    • Generalities and Related Classes

    • Dependencies to other Use Cases (include, extend, generalize)

  • Class Diagrams:

    • Generalities and Related Classes

    • Dependencies to other Classes (association, dependency, generalization)

  • Sequence/Collaboration Diagrams: Method Calls

  • Component Diagrams:

    • Related and Façade Classes

    • Implemented Interfaces

    • Dependencies of Components and Interfaces


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


A framework methodology and tool for reusable software components

Goal

  • Increase Reuse Potential by Understanding Classes, Components, and their Role within Applications

    • Identify the Reusable Portions of Design

    • Estimate/Measure Reusability Automatically

    • Provide Guidelines on Improving Reusability

    • Usable for

      • Newly Created Designs

      • Evaluation of Legacy Code for Reuse Potential

    • Independent Tool/Integrated in Together

    • See: http://www.engr.uconn.edu/~steve/DRE/dre.html


Model of oo application

Model of OO Application

  • Definition 1: Object-Oriented Application S is Modeled As a 3-tuple (C, i, m)

    • C is the Set of Classes, Where Each Class Cp Contains a Set Cpm of Methods Mim Such that Each Method Mi Belongs to Only One Class

    • I is the Set of Pair-wise Inheritance Relations of Classes in C

    • M is the Set of Pair-wise Coupling Among Methods


Model pair wise couplings

Model - Pair-wise Couplings

  • Definition 2: Pair-wise Coupling

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

Cp

Cq

m1

m5

m4

mj

mi

m9

m18

m9

m20


Basis of reuse framework

Basis of Reuse Framework

  • Class Reusability

    • Best Estimate on Potential Utility of Class

    • General: Application Classes that Facilitate Domain-and-Organization Specific Reuse

    • Specific: Application Classes that are Limited to use in a Single Application

  • Relations Among Classes

    • Grouping of Classes that Are Expected to Be Reused Together in Future Applications


Class reusability

Class Reusability

  • General Classes

    • Expected to be Reused in Future Applications

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

    • Domain Independent/Domain Specific

  • Specific Classes

    • Only Applicable in Current Applications

    • Unlikely to be Reused in Future Applications

    • Application Specific

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


Model class reusability

Model - Class Reusability

  • Definition 3: The Reusability Level of Class Ci is Denoted by Gci

    • Gci=0  Ci is the Most General Class in the Application

    • Gci=N (N>0)  Ci is the Most Specific Class in the Application

    • Lower N, More General Class

  • Class Generality Vector


Model relations among classes

Model - Relations Among Classes

  • Related Classes Promote Reuse, Since They are Expected to be Reused Together

    • Class Ci is Related to Class Cj if Expected to be Reused Together in Future Systems

    • Class Ci Related to Class Cj is Subjectively Assigned by Software Engineer (Producer)

  • Related Classes Assist in Reusability Assessment

  • Aside:

    • Unrelated Classes are NOT Expected to be Reused Together

    • Dependencies Among them Hinder Reuse


Quantifying reuse properties

Quantifying Reuse Properties

  • Property 1: Generality and Inheritance

    • Parent of a Class is Equally General or More General than is Direct Children

  • Property 2: Generality and Related Classes

    • Reuse Level of Class is Equal to the Reuse Level of the Least Reusable Coupled Class

  • Property 3: Extraneous Functionality

    • Classes that Don’t Contribute to Functionality of Component have Negative Impact on Reuse

  • Property 4: Generality and Unrelated Classes

    • Couplings Between Unrelated Classes Hinder Reuse


Dependencies among classes

Dependencies Among Classes

  • Object Inclusion: Class Contains a Instance of Another Object

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

  • Method Invocation: Class Invokes a Method Defined on Another Object

  • Goals

    • Classify and Understand Dependencies

    • Assess “Good” vs. “Bad” Dependencies

    • Change “Bad” to “Good” by

      • Changing Class from S to G or G to S

      • Moving Code and/or Method Calls

      • Splitting a Class into Two Classes

      • Merging Two Classes


Dependencies related classes

Dependencies: Related Classes

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

  • The Two G classes are Related

  • Related Classes are Intended to be Reused Together

Good (Type 1)

G

G

Bad (Type 3)

Okay (Type 5)

S

S

Okay (Type 7)


Dependencies non related classes

Dependencies: Non-Related Classes

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)


Sample actions to improve reusability

Sample Actions to Improve Reusability


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

  • 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

Related Classes

Unrelated Classes


Reuse improvement factor

Reuse Improvement Factor

  • Metric of the Loss, Gain, or Steady State Between the Various Coupling Types After the Refactoring

  • Defined by

    where  is the Matrix for all Transitions Among the Eight Coupling Types in One Step

    • If  > 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

  • 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

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

  • Augment Slides from Main Portion of Talk

  • Replace Slide 143 on Refactoring Algorithm

  • Note: All Material in in ICSR Paper!


Graph content and matrix

Graph Content and Matrix


Algorithm steps

Algorithm Steps


Algorithm steps1

Algorithm Steps


Algorithm steps2

Algorithm Steps


Algorithm steps3

Algorithm Steps


Algorithm steps4

Algorithm Steps


Algorithm steps5

Algorithm Steps


Algorithm steps6

Algorithm Steps


Algorithm steps7

Algorithm Steps


Example assumptions

Example - Assumptions

  • Assume Classes: C1, C2, C3, C4, C5, C6, C7

  • Methods: m1, m2, m3, m4, m5, m6, m7, m8

  • Dependencies Among Methods (Couplings) Shown with Arrows


Example generality and related steps 1 2 3 of algorithm

Example - Generality and RelatedSteps 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 TypesStep 4 of Algorithm

G

G

G

G

S

S

S


Example identify undesirable couplings step 5 of algorithm

Example - Identify Undesirable Couplings Step 5 of Algorithm

G

G

G

G

S

S

S


Example refactor the application step 6 of algorithm

Example - Refactor the Application 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 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 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

G

G

G

G

S

S

S


Future formal reuse model

Future: Formal Reuse Model

  • Future Work

    • Exploring Weightings (+2, +3, -3, etc.) for Transitions Among Coupling Types

  • Explore and Refine the Reuse Model

    • Theoretical Verification of Reuse Model

    • Use of Genetic Algorithm to Obtain “Near” Optimal Marking

  • Practical Perspective

    • Integrating Metric and Model in SDRE

    • Testing with “Real” Examples and Prior Examples

  • Extend Model to Apply to UML Reuse (see Next Group of Slides)


A graph based algorithm for automated refactoring

A Graph-Based Algorithm for Automated Refactoring

  • Extending the Formal Definitions of Reuse Model to Allow Automatic and Algorithmic Refactoring

    • Cabellero and Demurjian at JIISIC 2003

    • Automatically Refactors to “Improve” Reuse

  • Model Couplings as a Directed Acyclic Graphy

    • Graph Represents Dependencies

      • Nodes Represent Classes

      • Edges Represent Couplings

    • Assign Generalities to Subject of Graph

    • Induce Remaining Generalities

    • Employ Topological Sort and Refactoring Algorithms


A framework methodology and tool for reusable software components

Goal

  • Reuse Metric, Framework and Tool

  • Increase Reuse Potential by Understanding Classes, Components, and their Role within Applications

    • Identify the Reusable Portions of Design

    • Estimate/Measure Reusability Automatically

    • Provide Guidelines on Improving Reusability

  • Applications to

    • Newly Created OO Designs

    • Evaluation of the Reuse Potential of Legacy Code


Class reusability1

Class Reusability

  • Idea: “Best Estimate” on Potential Utility of Class

  • Purpose: Identify the Classes with Highest Reuse Potential for Organization’s Future Systems

  • General Classes

    • Application Classes that Facilitate 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

  • 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

  • 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

  • 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

  • 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

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

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


Sample actions to improve reusability1

Sample Actions to Improve Reusability


Graph based refactoring

Graph Based Refactoring

  • Classes are Modeled as a Directed Graph

    • Nodes Represent Classes

    • Edges Represent Couplings

  • Topological Sorting Arranges of a Directed Acyclic Graph into a Precedence Order

    • G=(V,E) is a DAG

    • If (u,v)E then u appears before v in ordering

  • Reference Vertices

    • Set of Vertices of G Such that have been Assigned a Generality Level

    • Starting Point of the Analysis

    • Set of Classes Intended as General or Specific


Consistency

Consistency

  • The Topological Ordering of a Graph is Consistent with the Generality Level of the Reference Vertices

    • IF for all Reference Vertices u,v such that ru<rv, and there is no Directed Path from v to u in the Graph

    • THEN u appears before v in the Topological Ordering

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

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)


Topological sort consistent with reference vertices

Topological Sort Consistent With Reference Vertices


Induced generality level

Induced Generality Level

  • Generality Level Assignment is Induced from the Graph Topology and the Reference Vertices

  • Algorithm Shows Conflicts Between Assignment to the Reference Vertices and Topological Order


Refactoring algorithm1

Refactoring Algorithm

  • 1 Assign Generality Level to Reference Classes

  • 2 For Each Connected Sub-Graph Find the Induced Generality Level

  • 3 For Each Class where Induced Generality Level is in Conflict with Generality Assigned by SWE

    • Apply Refactoring

    • If the Sub-Graph Changed as a Result of the Refactoring Re-Calculate the Induced Generality Levels

    • If There Are Still Remaining Conflicts, Reassign Generality Levels to Reference Vertices and Goto 2

  • Re-Asses the Induced Generality Levels, if They Are Consistent With the Design Objectives Terminate. Otherwise Goto 2.


Algorithm steps8

Algorithm Steps


Algorithm steps9

Algorithm Steps


Algorithm steps10

Algorithm Steps


Algorithm steps11

Algorithm Steps


Algorithm steps12

Algorithm Steps


Pull up method pull up field

Pull Up Method/Pull Up Field

  • Conditions:


Push up method push up field

Push Up Method/Push Up Field

  • Conditions:


Example

Example


Example1

Example

  • Reference Vertices

  • Topological Sorting

  • Induced Generality Level

G

S


Example2

Example

  • Reference Vertices

  • Topological Sorting

  • Induced Generality Level

G

G

S

S


Refactoring

Refactoring

Push-Up m4

Push-Down m3


Class diagram after refactoring

Class Diagram After Refactoring

G

G

G

G

S

S

S

  • Re-Calculate Induced Generality


Conclusions

Conclusions

  • Extended Reusability Framework Proposed by Price and Demurjian

  • Proposed a New Refactoring Algorithm

    • Uses Graph Theory Elements

    • Guides Refactoring Process

    • Improves Software Structure From Reuse Perspective

  • Algorithm Based On

    • Topological Sorting of the Class Diagram

    • Calculation of Induced Generality Levels for all Nodes

    • Provides Guidelines for Refactoring


Ongoing and future work

Ongoing and Future Work

  • Shortfalls

    • No Empirical Evidence that the Proposed Algorithm Works on Real Designs!

    • Software Engineer Strongly Involved in Refactoring

  • Related to Presented Work:

    • Extend/Refine/Reformulate Reusability Model

    • Incorporate Refactoring Algorithm into Tool

    • More Realistic Examples to Gather Empirical Evidence of the Utility of Our Algorithm


Reusability model layers framework

Reusability Model, Layers, & Framework

  • Application is Designed with Abstractions (Class, Interface, Package, Component)

  • Apply the Reuse Framework to the Classes, Interfaces, Packages, and Components

    • Assign Generality Levels

    • Determine Related Classes, Components

    • Iterate Until Obtain Marking that is Consistent with the Goals/Objectives of Application

  • Problem: Is it Possible to Organize or Compartmentalize the Application’s Classes, Interfaces, Packages, and Components From Different Perspectives Based on Requirements?

    • Compartments - Previously Called Layers

    • Represent Chunks of Functionality


Reuse model issues from last meeting

Reuse Model Issues from Last Meeting

  • Clarify/Redefine “Related” Characterization

    • Transitivity of “Related”

    • W R to A, B, and C vs. W R to A, B, or C

  • Common Definitions for Package/Component

    • How is Marking of Package/Component Determined?

      • “Least” General Class Sets Package/Component Generality

    • Packages/Components Must Obey All Generality Rules of the Model/Framework

  • Inclusion of Interfaces into Model/Framework

  • Design Patterns and Impact on Reuse

  • Layering and the Reuse Model (Our Focus)


Problem domain layering

Problem Domain Layering

  • Notion of General/Specific Impacted by Layering?

    LayerComponent

    CommonPerson

    ManufacturingPart

    ShipbuildingPiping-Part

    Company-SpecificSub-Piping-Part

Not OK

OK


Recall levels of generality

Recall Levels of Generality

  • 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

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

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

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

Contains - Type Level

Uses - Instance Level

Interface

Class

Component

Package


Abstractions and application

Abstractions and Application

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

  • 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

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

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

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

  • 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

  • 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

  • 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

  • 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

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

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

  • 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

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?

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

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

  • 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


  • Login