REUSE--1 A Framework, Methodology and Tool for Reusable Software Components* † Special Thanks to Jeff Ellis, Rodrigo Caballero, Margie Price, Donald Needham.

REUSE--1 A Framework, Methodology and Tool for Reusable Software Components* † 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. Prof. Steven A. Demurjian† Computer Science & Engineering Department The University of Connecticut 371 Fairfield Road, Box U-2155 Storrs, CT 06269-2155 steve@engr.uconn.edu http://www.engr.uconn.edu/~steve (860) 486 - 4818

REUSE--2Motivation  Reuse Afterthought in OO Design/Development  Majority of Reuse Focuses on “Small” Components with Minimal Savings  String Functions, Utility Routines, GUI, etc.  Easy to Understand - Easy to Reuse  “Beans” Have Improved Reuse - Still Lagging  Three Classes of Software  Domain-Independent (20%) : Libraries, Utilities, etc. Most Likely to Be Reused  Domain-Specific (65%) : Dedicated Software Reused in Other Programs of Same Domain  Application-Specific (15%): Uniqueness Unlikely to Be Reused

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

REUSE--4Motivation

REUSE--5 Motivation Why Software Reuse?  Increase Software Productivity  Shorten Software Development Time  Improve Software System Interoperability  Develop Software With Fewer People  Move Personnel More Easily From Project to Project  Reduce Software Development and Maintenance Costs  Produce More Standardized Software  Produce Better Quality Software  Provide a Powerful Competitive Advantage

REUSE--6Objectives  Reuse as Equal Partner Starting with Design  Iterative Reusability Evaluations at Early and All Stages of Design and Development  Production of Large Reusable Components  Capabilities of Evaluation Techniques  Identify the Reusable Portions of Design  Estimate/Measure Reusability Automatically  Provide Guidelines on Improving Reusability  Usable for  Newly Created Designs  Evaluation of Legacy Code for Reuse Potential  Integrated in a Design/Development Environment

REUSE--7 Overview of Presentation – Part 1  Cultural and Social Reuse Issues  Component-Based Design - History & Perspective  Component-Based Reuse Framework and Methodology  Subjective Identification of Components  General vs. Specific Classes  Related Hierarchies to Quantify Components  Objective Measure of Dependencies  Classifying Dependencies  Measuring Reuse Potential  Detailed Reuse Guidelines  Methodological Basis for Increasing Reuse  Iterative Improvement in Reusability  Prototyping: DRE Tool Family/Examples

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

REUSE--9 Cultural and Social Reuse Issues High Initial Cost  Reports have Indicated  High Start Up Costs  Slow Return on Investment (> 3 years)  Best Success in  Starting with Small Projects  Distributing Components for Reuse  Opportunistic Reuse  Reuse Must be Supported by  Libraries to Collect, Classify, and Disseminate Components  Ease of use for Producer and Consumer

REUSE--10 What are Components?  ADTs as Unit of Abstraction/Conceptualization  Classes are OO Equivalent of ADTs  However, in Past 10 Years  Computing Power has Exploded  Application Complexity has Increased  Classes are Part of Inheritance Hierarchy  Inheritance Hierarchy Part of Application Class Library  In Past 2-3 Years We’ve Seen  Emergence of Java  Emergence of Java Beans  Component-Based Development Tools

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

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

REUSE--13 Cultural and Social Reuse Issues Reuse and Software Design/Development  Lesson Learned  Reuse Often Avoided by SW Engineers due to Fear of Configuration Management Problems  How is Fear Minimized?  Reuse as Integral Part of Development Process  Reuse Early and Often  Tools that Facilitate Producer Logging Component and Consumer Finding Component  Summary  We’ll Concentrate on Technical Reuse Issues  Superior Techniques Will Remain Unpopular and Unused without Associated Support

REUSE--14 Components vs. Objects  Components  Business Oriented  Coarse Grained  Standards Based  Multiple Interfaces  Provide Services  Fully Encapsulated  Understood by Everyone  Objects  Technology-Oriented  Fine Grained  Language Based  Single Interface  Provide Operations  Use Inheritance  Understood by Developers

REUSE--15 Reusable Components Types & Benefits Reusable Components Types & Benefits  Application Template  Data Model  Data Structure  System Architecture  Process Model  Process Definition  Prototype  Plan Skeleton  User Interface Skeleton/GUI  Process Skeleton  Utility Components  Organizational Perspective  Shorten Development Time  Reduce Costs  Increase Competitiveness  Personnel Perspective  Increase Productivity  Customer Perspective  Achieve Greater User Satisfaction Through the Production of More Flexible Products

REUSE--16 Component-Based Development Process TOP-DOWN: To determine what is needed to satisfy this need. BOTTOM-UP: To determine what is available to satisfy this need. OTHERS: Consider the similarity among concurrent projects. FUTURE: Consider the possibility of reusing in future projects.

REUSE--17 CBD: Component-Based Development

REUSE--18 Supplier /Consumer Model SUPPLY Build New Wrap Existing Buy CONSUME Assemble Applications MANAGE Publish Subscribe Catalog Browse

REUSE--19 Specification Implementation Executable Interfaces Component

REUSE--20 Components as Assets can Grow Complexity of Component

REUSE--21 What are Component Dependencies?  Dependency Type of Components  Versions  Aggregations  Functional  Inheritance  Association  What is Impact of Each Dependency on the Reusability of a Component?

REUSE--22 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/rs rg-brochure-nov-98.html http://www.csee.wvu.edu/~resolve/scw/rs rg-brochure-nov-98.html  Reusable Software Research Group, Ohio State University  http://www.cis.ohio- state.edu/rsrg/index.html http://www.cis.ohio- state.edu/rsrg/index.html  Select Software Tools  http://www.selectst.com/ http://www.selectst.com/  Software Reuse Executive Primer, DOD  http://dii-sw.ncr.disa.mil/ReuseIC/pol- hist/primer/ http://dii-sw.ncr.disa.mil/ReuseIC/pol- hist/primer/  Model-Driven Software Reuse, Extended Intelligence Inc.

REUSE--23 RepositoryBrowserHierarchy Component Repository

REUSE--24 Multiple Repository Support Multiple Support

REUSE--25 CBD life cycle BusinessDirection General Business Requirements User, Business and Data services Business and Data services ComponentRequirements UserServices Harvest

REUSE--26 1996: $652 million 2001: $12 billion IDC forecast CBD market

REUSE--27 Web-Site References  Reusable Software Research Group, West Virginia University  http://www.csee.wvu.edu/~resolve/scw/rsrg-brochure- nov-98.html 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 http://www.cis.ohio-state.edu/rsrg/index.html  Select Software Tools  http://www.selectst.com/ http://www.selectst.com/  Software Reuse Executive Primer, DOD  http://dii-sw.ncr.disa.mil/ReuseIC/pol-hist/primer/ http://dii-sw.ncr.disa.mil/ReuseIC/pol-hist/primer/  Model-Driven Software Reuse, Extended Intelligence Inc.

REUSE--28 A Framework, Methodology, and Tool for Reusable Software Components  Reuse as Equal Partner Starting with Design  Iterative Reusability Evaluations at Early and All Stages of Design and Development  Production of Large Reusable Components  Capabilities of Evaluation Techniques  Identify the Reusable Portions of Design  Estimate/Measure Reusability Automatically  Provide Guidelines on Improving Reusability  Usable for  Newly Created Designs  Evaluation of Legacy Code for Reuse Potential  Independent Tool/Integrated in Together  See: http://www.engr.uconn.edu/~steve/DRE/dre.html

REUSE--29 A Framework, Methodology, and Tool for Reusable Software Components 1. Define Components, Their Interactions, and Analyze Their Reusability 2. Store an Iteration of Design 3. Implement an Iteration 4. Store and Document Iteration of Implemen. 5. Reevaluate an Existing Design for  Correcting Errors  New Reuse Potential 6. Reuse Existing Design with a New Implementation Store & Document Designs Reusability Evaluation Implement the System Re(Design) a System Store & Document Implemens. 1 5 4 6 3 2

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

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

REUSE--32 General/Specific Class Characterization  General Class (G)  Expected to be Reused in Future Applications  Abstract Classes/Root Classes/Non-Leaf Classes in Inheritance Hierarchies  Domain Independent/Domain Specific  What are Some Examples?  Specific Class (S)  Only Applicable in Current Applications  Unlikely to be Reused in Future Applications  Classes that Retrieve from Company Database  Application Specific  What are Some Examples?

REUSE--33 High-Tech Supermarket System (HTSS)  Automate the Functions and Actions  Cashiers and Inventory Updates  User Friendly Grocery Item Locator  Fast-Track Deli Orderer  Inventory Control  User System Interfaces  Cash Register/UPC Scanner  GUI for Inventory Control  Shopper Interfaces Locator and Orderer  Deli Interface for Deli Workers   We’ll Introduce and Utilize Throughout Lecture

REUSE--34 The HTSS Software Architecture IC IC CR CR CR CR IL IL IL SDO SDOEDO EDO Order Payment Item ItemDBLocalServer Non-Local Client Int.InventoryControl ItemDBGlobalServerOrderDB SupplierDB CreditCardDB ATM-BanKDB IL: Item Locator CR: Cash Register IC: Invent. Control DO: Deli Orderer for Shopper/Employee Shopper/Employee

REUSE--35 A General Class in HTSS  Why is Item General?  What is Applicability of Item? class Item { private: // Private Data int UPC; char* Name; int InStock, OnShelf, ROLimit; float RetailCost; public: // Public Methods Item(int code, char* str, int st1, int st2, int st3, float cost); void CreateNewItem(); int GetUPC(); char* GetName(); int GetQuantity(); int CheckReorderStatus(); void PrintItem(); void UpdatePrice(float new_value); };

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

REUSE--37 Yet Another General Class in HTSS  GUI-Based Class for Supporting Inventory Control Actions Can be Domain Independent class InvControlGUI { private: int Curr_Option; // Current menu option public: InvControl(); // Constructor void PrintMenuSetOption(); void ActivateController(); void EnterNewItem(); void RemoveExistingItem(); void FindItem(); void InvSearchQuantity(); void InvSearchReorder(); void GenerateAnOrder(); };

REUSE--38 Specific Classes in HTSS  General Classes are Refined to Represent Particular Items, Yielding Specific Classes... Item DairyItemProduceItemDeliItem DeliOrdererGUI OrdererGUI

REUSE--39 Levels of General Classes  Not All General Classes Created Equally  Level of Generality Based on Role in Application  Purposes  Accommodate Large Systems with Multiple, Different Reusable Components  Reusable Components can Overlap, but Still be Distinct Reusable Units S S S S views as General if i j views as Specific if i < j

REUSE--40... Can you Identify Different Levels of General Classes? Item DairyItemProduceItemDeliItem NonPerishItemPerishItem

REUSE--41... Can we Identify Different Levels of General Classes? DairyItemDeliItem Item ProduceItem NonPerishItemPerishItem BigYProdItemDoleProdItemBigYDairyItemHoodDairyItem Where can Item be Reused? Where can NonPerishItem and PerishItem be Reused? Where can ProduceItem and DairyItem be Reused? Are DoleProdItem and HoodDairyItem Specific?

REUSE--42 Properties of General/Specific Classes  Level of Generality Strictly Ordered in Hierarchy  A Descendant of a General Class Must have an Index Greater Than or Equal to Itself or be Specific  A Specific Class Can only have Specific Descendants S S S S views as General if i j views as Specific if i < j

REUSE--43 Generality and Specificity within One Inheritance Hierarchy

REUSE--44 Generality/Specificity/Dependencies Across Multiple Hierarchies

REUSE--45 General/Specific Paradigm in HTSS  Abstraction from HTSS to Domain Independent Inventory Control Application  Separation of Supermarket Domain Specifics  Leverage Commonalties for  Focused, Independent Design/Development  Future Products  Relevance  Domain-and-Organization-Specific Reuse  Expand to 24 hour Mom & Pop Stores  Expand to Other Retail Markets E.g., Auto parts, Clothing, Toy, etc.

REUSE--46 Reusability in HTSS Domain  Where do Changes for Other Domains Occur? Specific Applications for Big Y or Shaw’s or Stop/Shop (S) Root classes for Items, ItemDB, etc., which are Most General. Inventory Control/Other Components. Classes Specific to Grocery Store Domain.

REUSE--47 Reusability in HTSS Domain Specific Applications for Big Y or Shaw’s or Stop/Shop (S) Root classes for Items, ItemDB, etc., which are Most General. Inventory Control Other Components. Classes Specific to Grocery Store Domain. Inventory Control Tool for Ordering Items from Suppliers Cost Accounting Tool for Tracking Net and Gross Profit

REUSE--48 Reusability in HTSS Domain Specific Applications for Big Y or Shaw’s or Stop/Shop (S) Root classes for Items, ItemDB, etc., which are Most General. Inventory Control/Other Components. Classes Specific to Grocery Store Domain. Classes for Large Supermarket Classes for Specialty Supermarket Classes for 24 Hour Convenience

REUSE--49 The FinancialFrame Application  A Commercial C++ Framework Containing 441 Classes, Proprietary of FinancialComp  Designed for Reuse in Various Financial Apps.  Provides Basic Functionalities of Financial System  FinancialFrame’s Challenge - Manage Changes  Framework Constantly Evolving  New Functions and Modify Existing Functions  Conceptual Relevance:  Provide Realistic Context for Our Approach  Domain-and-Organization-Specific Reuse

REUSE--50 The FinancialFrame Application  Our Purpose: Work with Existing Code  Establish General and Specific Classes  Characterize Related Components  Evaluate the Goodness of G/S Characterization and Identify Potential Problem Areas  General Components that are Specific  Specific Components that are General  Problematic Relevance:  Demonstrate Ability of Approach to Localize Effect of Changes  Describe Ways to Increase FinancialFrame’s Reuse Potential

REUSE--51 General and Specific Classes in FinancialFrame FinancialCompTrader FinancialCompAccount FinancialCompDesk Main FinancialCompMainOtherMain SpecificFCMain (S) SpecificOtherMain (S)... YieldModel DiscountIndexBondBill CashFlowAnalyzer...

REUSE--52 Related Classes and Hierarchies  Class X is Related to Class Y if they are Related and Concept and are Expected to be Reused Together in Future Systems  Class X Related to Class Y is Subjectively Assigned by Software Engineer (Producer)  When Class X is Related to Class Y  X and All of X’s Descendants are Related to Y and All of Y’s Ancestors  Thus, to Reuse X or X’s Descendants, you Must Reuse Y and All of Y’s Ancestors  Class X Related to Y if Y at Same or Higher Level!  Related Classes Promote Reuse, Since They are Expected to be Reused Together

REUSE--53 Related Hierarchies/Reusable Components  Two Sub-Hierarchies are Related if to Reuse One, you Must Reuse the Other  Purpose: Identify Reusable Dependencies Among Related Classes  Reusable Component: A Set of Related Classes that are Expected to be Reused as a Group S S S S S S A Sub-Hierarchies B R

REUSE--54 Related Characterization in Levels of Components - HTSS Item NonPerishItemPerishItemEnviron R DairyItemProduceItemDeliItemSubZeroRTemp  Does R from Environ to PerishItem Make Sense?  Should R be from PerishItem to Environ?

REUSE--55 Related Characterizations in Levels of Components - HTSS  Where do Changes for Other Domains Occur? Specific Applications for Big Y or Shaw’s or Stop/Shop (S) Root classes for Items, ItemDB, etc., which are Most General. Inventory Control/Other Components. Classes Specific to Grocery Store Domain.

REUSE--56 Related Characterization in Levels of Components - FinancialFrame... YieldModel DiscountIndexBondBill Bond R  Bond is Related to IndexBond  When Bond is Reused, so Must IndexBond and YieldModel  Hence, IndexBond and its Ancestor (YieldModel) are Reused!

REUSE--57 Related Characterizations in Levels of Components - FinancialFrame  Classes/Sub-Hierarchies can be Related if and only if Classes (or Sub-Hierarchy Roots) are General and at the Same or Higher Level Specific applications at FinancialComp (S) Root classes of strategies and other most General classes (Main) Bond or other strategy Components Classes specific to FinancialComp

REUSE--58 What are Dependencies Among Classes?  Three Types of Dependencies:  Object Inclusion: Class Contains a Instance of Another Object  Attribute Definition: Class Contains Attribute that is the Type of Another Object  Method Invocation: Class Invokes a Method Defined on Another Object  Inheritance is NOT a Dependency  Yes – it’s a Relationship – but it is for Reuse  However, Represents Shared Behavior  Instance X with Parent Y and Grandparent Z is Created as a Single Instance that Includes Y+Z

REUSE--59 Goals of the Research  Classify and Understand Dependencies  Assess “Good” vs. “Bad” Dependencies  Change “Bad” to “Good” by  Changing Class from S to G or G to S  Moving Code and/or Method Calls  Splitting a Class into Two Classes  Merging Two Classes  These Four Actions (Change, Move, Split, Merge) and Others Represent Refactoring  Key Issues:  Refactoring Maintains Original Functionality  Process Should Not Introduce Problems

REUSE--60 Reusing Sub-Hierarchies in Different Components - HTSS Will be reused with Components for another domain, e.g., Toy Store Will be reused with Components for different Super- market Companies Item... DairyItemProduceItemDeliItem NonPerishItemPerishItem

REUSE--61 Reusing Sub-Hierarchies in Different Components - FinancialFrame  Dependencies Among General Related Classes  Not a Hindrance to Reuse  Represents Valuable Design Knowledge Main FinancialCompMainOtherMain SpecificFCMain (S) SpecificOtherMain (S) Will be reused with Components utilizing another company’s databases Will be reused with Components utilizing FinancialComp’s database

REUSE--62 Transitivity in Inheritance and Related Relationships Base Case: Related Characterization is Transitive, but not Commutative but not Commutative A A B B C C R R Case 1: A is not related to X Dependencies from A to X Dependencies from A to X are not Desirable are not Desirable Recall: We Reuse X and All Recall: We Reuse X and All of Its Ancestors, But Not of Its Ancestors, But Not B’s Ancestors to Reuse A B’s Ancestors to Reuse A A A B B C C X X R

REUSE--63 An Example of Case 1 in FinancialFrame  FinancialCompMain R FinancialCompTrader Thus, Dependencies Between are Desirable  Main is not R to FinancialCompTrader Thus, Dependencies Between Hinder Reuse  For “Blue” Component, we Don’t Want to Have to Reuse FinancialCompTrader with Main! Main FinancialCompMainOtherMain FinancialCompTrader R

REUSE--64 Transitivity in Inheritance and Related Relationships B B A A C C X X R  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!

REUSE--65 An Example of Case 2 in FinancialFrame... YieldModel DiscountIndexBondBill Bond R  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!

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

REUSE--67 Dependencies Among Related Classes  Remember, G/S are Subjectively Assigned by Software Designer  The Two G classes are Related  Related Classes are Intended to be Reused Together Good (1) G S G S Okay (5) Okay (7) Bad (3)

REUSE--68 Sample Dependencies in HTSS InvCont DeliIC Item DeliItem Good (1) Okay (5) Okay (7) Bad (3)  InvCont and Item are Related Classes  InvCont to Item Dependencies are Good: Reused Together  Dependency from InvCont to DeliItem is Problem  Don’t Want to Reuse InvCont with DeliItem  ManagerGUI with InvCont Includes Useless DeliItem  Dependencies from DeliIC to Item and/or DeliItem  Don’t Impact Reuse  Can Reuse Item and DeliItem w/o DeliIC

REUSE--69 Dependencies Among Non-Related Classes  Remember, G/S are Subjectively Assigned by Software Designer  The Two G Classes are Not Related  Non-Related Classes are NOT Intended to be Reused Together Okay (6) Okay (8) G S G S Bad (2) Bad (4)

REUSE--70 Sample Dependencies in HTSS InvCont DeliIC Person Shopper Bad(2) Okay (6) Okay (8) Bad (4)  InvCont and Person are Classes that are Not Related  InvCont to Person or Shopper Dependencies are Bad  Don’t Want to Reuse Person/Shopper with InvCont  Must Reuse - Problem!  Dependencies from DeliIC to Person and/or Shopper  Don’t Impact Reuse  Can Reuse Person and Shopper w/o DeliIC  However, Poor Design if DeliIC Needs Person or Shopper!

REUSE--71 Summarizing Couplings of Related Classes  Type 1: Good for Reuse  Two General Classes are Reused Together  Type 3: Bad for Reuse  General to Specific  To Reuse, Specific Must be Included  Added Functionality with No Purpose  Change to Type 1 or 5/7 – Refactoring Guideline (RG)  Types 5/7: Okay for Reuse  No Impact  Specific Classes Not Reused in New Application  May Improve Reuse if Changed to Type 1- RG

REUSE--72 Summarizing Couplings of Non-Related Classes  Type 2: Bad for Reuse - Two General Classes  Not Expected to be Reused Together since Not Related  Change to Type 6/8 – Refactoring Guideline  Type 4: Bad for Reuse  General to Specific  To Reuse, Specific Must be Included  Added Functionality with No Purpose  Change to Type 6/8 – RG  Types 6/8: Okay for Reuse  No Impact  Specific Classes Not Reused in New Application

REUSE--73 Dependencies in Levels of Components Summarizing Related Classes (1) (3) (5) (7) (7) (1) (1) Related to

REUSE--74 Dependencies in Levels of Components Summarizing Non-Related Classes (2) (4) (4) (6) (8) (2) (2)  Dependencies Among Unrelated Classes Always  Bad for Reuse  No Impact on Reuse

REUSE--75 Sample Actions to Improve Reusability Changes are Refactorings!

REUSE--76 Reuse Guidelines  Methodological Basis for Increasing Reuse  Designer Supplies General/Specific/Related for the Classes/Hierarchies in Application  Reuse Analysis Tool Calculates Couplings and Identifies Types of Reuse (Good, Bad, Okay)  Ideal Result: Maximize Reuse via Couplings  Type 1: G to G for Related Classes  Type 8: S to S for Non-Related Classes  Extended Guidelines: Menu of Choices  Different Ways to Refactor Couplings  Considers Impact of Refactorings on Design  Goal: Iterative Improvement in Reusability while Maintaining Application Functionality

REUSE--77 Core Refactoring Guidelines to Move Couplings to Increase Reuse Potential G S G S Type 2 Type 8 G S G S Type 4 Type 8 G S G S Type 5 Type 1 G S G S Type 7 Type 1 G S G S Type 3 G S G S Type 7

REUSE--78 Extended Refactoring Guidelines for Improving Reusability  Core Refactoring Guidelines Emphasize Local Behavior  To Remove “Bad” or Improve “Okay” Coupling, Refactor Cause of the Coupling (e.g., Method Call)  Moving a General Method to Specific Class  Moving a Specific Method to General Class  Moving Method Up/Down a Hierarchy, Which Alters the Coupling, Can Impact Elsewhere  Expand the Analyses to Other Couplings of the Source and Destination of the Bad Coupling  Couplings to Source when Moving Down  Couplings to Destination when Moving Up  Extended Refactoring Guidelines: Menu of Choices

REUSE--79 Extended Refactoring Guidelines to Improve Reuse - Identifying the Problem S G S m() G G Type 7 G S G S Type 3 Type 7 Recall G S G S m() G Type 3 Suppose What has Occurred?

REUSE--80 Extended Refactoring Guidelines to Improve Reuse - Identifying the Problem S G S m() G G Type 5 Suppose What has Occurred? G S G S m() G Type 1 G S G S Type 5 Type 1 Recall

REUSE--81 Problem and Solution  Focus on Core RGs May Ignore the Impact of a Change for Other Related and Coupled Classes  When a Coupling is Moved from a G to S Class  Examine All Existing Coupling to G Class  G to G Coupling Now G to S  We’ve Introduced a “Bad” Coupling  Likewise, When a Coupling Moved from S to G  Examine All Existing Coupling to S Class  S to S Coupling Now S to G  We’ve Introduced a “Bad” Coupling  Solution: Extended Refactoring Guidelines to Govern all Potential Scenarios for Removing “Bad” Couplings

REUSE--82 Extended RGs for Type 3 Couplings  Move Coupling Dst. to General Class or Change Dst. To a General Class  Type 3 to Type 1  May Introduce Couplings from G Dst. to Specific Classes  Move Coupling Src. to Specific Class or 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 G S G S Type 3 Among Related

REUSE--83 Removing Type 3 Couplings in HTSS Which Changes Make Sense? InvCont DeliIC Item DeliItem Type 3  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 Type 1 Type 7

REUSE--84 Extended RGs for Type 2 Couplings  Move Coupling Src. to Specific Class or Change Src. To a Specific Class  Type 2 to Type 6  May Introduce Couplings from General Classes to Specific Src.  Move Src. and Dst. to Specific Classes  Type 2 to Type 8  May Introduce Couplings from G Src. to Specific Dst.  Move Coupling Dst. to Specific Class or Change Dst. To a Specific Class  Follow Type 4 Guidelines  Change to Related/Type 1/Design Impact Must be Evaluated!  Detailed Evaluation of Implementation G S G S Type 2 Non-Related

REUSE--85 Extended RGs for Type 4 Couplings  Move Coupling Dst. to General Class or Change Dst. To a General Class  Type 4 to Type 2 - No Help  Move Coupling Src. to Specific Class or Change Src. To a Specific Class  Type 4 to Type 8  May Introduce Couplings from General Classes to Specific Src.  Change to Related/Follow Type 3  Detailed Evaluation of Implementation G S G S Type 4 Non-Related

REUSE--86 Summary on Extended Refactoring Guidelines  Total Alternatives for Removing “Bad” Couplings:  Type 2, 3, 4: Seven Possibilities Each: 21 Total  Type 5, 7: 3 Total  Changing from G to S or Movement of Coupling Potential to Impact:  Couplings to Source  Couplings from Destination  But: Refactoring May Decrease Reuse Potential!  Two-Fold Solution:  Design Support for OO Reuse Metrics and Evaluation within UML, Design Patterns, etc.  Analytical Tool for Evaluating Reuse Potential of Java Applications/Libraries

REUSE--87 Utilizing Reuse Methodology Evaluate Evolving Design/Implementation  Constructing New Applications  Software Design Proceeds in Stages  Today’s Norm: Incremental Development and Rapid Prototyping  General/Specific Classes/Related Components  Assigned Initially as Classes are Generated  Refined Throughout Increments/Versions  G to S, S to G, etc.  Related Components as Design Begins to Mature with Additional Details  Use Methodology to Identify and Refactor “Problems” in Application  Video Rental System Test-Bed

REUSE--88 Utilizing Reuse Methodology Investigate Reusability of Legacy Code  Reusability of Legacy Code  Examine Legacy Code in Detail  Talk/Contact Domain Experts with Corporate Knowledge of Code  General/Specific Classes/Related Components  Take “Educated Guess” for G/S Classes and Related Components  Run DRE and Find/Correct Problems  Re-evaluate Legacy Code with Different “Educated Guesses”  Compare/Contrast Results to Identify the “Best” way to Characterize Classes/Components  See Web Site for Example in FinancialFrame

REUSE--89 The Video Rental System (VRS)  VRS is for On-Line (Browser) Rental Tapes  Maintains Customer and Video Databases  Tracks Borrowing/Returning of Tapes  Logs Rented Tapes  CGI, C++, Netscape/Explorer  From Video Rental to Auto Parts  Undergraduate Project: Spring 1997 - VRS-1  Repeated as Grad Project: Fall 1998 - VRS-2  Goals:  Demonstrate General/Specific/Related Ideas  Incorporate/Reuse Design in Future System  Study Effectiveness Approach in Identifying and Removing Non-Reusable Dependencies

REUSE--90 General and Specific Classes in VRS-1 VideoStoreInterface (S) StoreInterface (G) VideoCustomer (S) Customer (G) VideoCustomerInterface (S) CustomerInterface (G) VideoTape (S) Item (G) VideoTapeDB (S) ItemDB (G) RentedTapeDB (S)RentedTape (S) CustomerDB (G)HistoryList (G)Transaction (G)

REUSE--91 DRE and VRS-1 Tracking Incremental Versions

REUSE--92 Final General/Specific Classes in VRS-2 and Some Related Characterizations VideoStoreInterface (S) StoreInterface (G) Customer (G) CustomerInterface (G) Video (S) Item (G) VideoItemList (S) ItemList (G) ReportGenerator (S) Transaction (G) VideoTransaction (S) CustomerList (G) VideoCustList (S)

REUSE--93 DRE and VRS-2 Tracking Incremental Versions

REUSE--94 One Type 3 Coupling: G to S Dependency Transaction (G) write_to_checkoutfile() VideoTransaction (S) Customer (G) take_item( )... tr->calculate_currentdate() tr->calculate_duedate() tr->write_to_historyfile() tr->write_to_checkoutfile()... calculate_currentdate() calculate_duedate() write_to_historyfile() What is the Problem? What is the Problem? How is it Resolved? How is it Resolved?

REUSE--95 Resolving Type 3 G to S Dependency with a Refactoring Customer (G) take_item( ) Transaction (G) write_to_checkoutfile() VideoTransaction (S) calculate_currentdate() calculate_duedate() write_to_historyfile()... tr->calculate_currentdate() tr->calculate_duedate() tr->write_to_historyfile() take_item_specific()... take_item_specific() VideoCustomer(S) ((VideoTransaction *) tr) -> write_to_checkoutfile()

REUSE--96 Utilizing Reuse Methodology Investigate Reusability of Legacy Code  Reusability of Legacy Code  Examine Legacy Code in Detail  Talk/Contact Domain Experts with Corporate Knowledge of Code  General/Specific Classes/Related Components  Take “Educated Guess” for G/S Classes and Related Components  Run DRE and Find/Correct Problems  Re-evaluate Legacy Code with Different “Educated Guesses”  Compare/Contrast Results to Identify the “Best” way to Characterize Classes/Components  FinancialFrame as a Test-Bed

REUSE--97 The FinancialFrame Application Initial Assumptions on G/S and Related... YieldModel DiscountIndexBondBill Bond  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

REUSE--98 Evaluation of FinancialFrame Possible 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)... YieldModel DiscountIndexBondBill Bond

REUSE--99 Revising FinancialFrame Application... YieldModel DiscountIndexBondBill Bond R  Bond is Changed from to  A Component Consisting of Bond, IndexBond, and YieldModel is Defined  When Bond Reused, So Must IndexBond and YieldModel - Other Classes Not Needed  However, YieldModel can Be Reused in Isolation  Thus, Modifications to Component Only Affect Reusers of Component

REUSE--100 Evaluation of FinancialFrame Possible Scenarios  Dependencies from to Classes  Occurring from a Specific Class to Other Classes Specific & Unrelated to a Component  Bond Related to Class Outside Component  Such Couplings Require a Specific Class in One Component to be Reused in Another Component, Where it is Not Needed  Reported as Undesirable Couplings (Type 2)... YieldModel DiscountIndexBondBill Bond R

REUSE--101 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 Bad Coupling No Longer Present!  When a Class is Modified, Only Users of Particular Component(s) are Notified Bad Coupling No Longer Present!  Each Component Can be Reused “As is”  Classes Outside of Component No Longer Needed  Cannot Illustrate Due to Proprietary Software  Similar Changes to VRS-2 Occur

REUSE--102 Design Reusability Evaluation (DRE) Tool  What is DRE?  Java-Based Tool for Analyzing Reusability  Takes Java Software as Input  Works with General/Specific/Related as Subjectively Defined by Software Designer  Analyzes Couplings to Identify, for Each Type (1 to 8), the Number of Couplings  Allows Designer to Investigate Cause of and Refactor “Bad” or “Okay” Couplings to Improve Reusability  DRE can be Utilized in Different Ways  Evaluate Evolving Design/Implementation  Investigate the Reusability of Legacy Code

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

REUSE--104 SDRE - Main Application Window

REUSE--105 SDRE - Main Window – Setting Generality

REUSE--106 SDRE - Main Window – Setting Relations

REUSE--107 SDRE - Main Window – Choosing Simulation Options

REUSE--108 SDRE - Help Subsystem  HTML-based Documents Describe Tool & Theory

REUSE--109 SDRE - Graphical Representation Generality Set for Design

REUSE--110 SDRE - Graphical Representation Setting Related Classes

REUSE--111 SDRE - Graphical Icons for Classes Relative Edge Base Inheritance Edge Base Generality Base Base Rectangle Source File Name Select Base Inheritance Edge Related Edge

REUSE--112 SDRE - Graphical Representation

REUSE--113 SDRE - Editing Source Code Enabled When Doubling Clicking

REUSE--114 SDRE - Editing Source Code Editor Appears with Line Highlighted

REUSE--115 SDRE - Editing Source Code Source Editor Features

REUSE--116 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

REUSE--117 CDRE – DRE Client

REUSE--118 CDRE – Client Login

REUSE--119 CDRE – Project Selection

REUSE--120 CDRE – Remote Class Selection

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

REUSE--122 Reusability in Together

REUSE--126 Overview of Presentation – Part 2  Reusability in OMT and UML  Exploring OMT Reuse Concepts (Predecessor to UML)  Integrating Reuse into the Design Process  Extending UML to Support Reuse w/Refactoring  Realizing Changes in Together via RGs  Exploring Reusability Assessment Automation  Towards the Formalization of a Reusability Framework for Refactoring, ICSR 7  A Graph-Based Algorithm for Automated Refactoring, JIISIC 2003  Reusability Modeling – Considering Reuse from a Different Perspective

REUSE--127  Revisiting OO Reuse Framework/Methodology  Examine M. Price’s Work on Subject:  Inserting Reusability Evaluations in OO Methodologies  Case Study of OMT (Predecessor of UML)  Premise and Assumptions  Three Stage Process in OMT Analysis, System Design, Object Design  Produces: Object, Dynamic, Functional Models  Company X Working on ATM Software with Future Product Automated Gas Pump (AGP) UML and Software Reuse

REUSE--128  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) Example Domain and Future Product

REUSE--129  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 Stage 1: Domain/Problem Analysis

REUSE--130  Difference in Usage  ATM: Bank Employs Cashiers and Owns ATM  AGP: Pay Inside or at Pump - Not Bank Empl.  Differences in UI  AGP: Limited Options w.r.t. Use of ATM Card Other Options for Credit, Debit, etc. Other Services, e.g., Car Wash at Discount  ATM: Deposits, Withdrawals, Transfers, Account Queries  Leverage Similarities and Differences to Organize Software for Reuse Sample Problem Analysis ATM vs. AGP

REUSE--131  General/Specific Classes and Related Components  Some Examples in ATM Construct an Object Model Bank Cashier Bank EMPLOYS Cashier Bank ATM Bank EMPLOYS Account balance type Customer name address HAS

REUSE--132  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? Dynamic Model, Functional Model, Verification/Iteration

REUSE--133  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 2: System Design

REUSE--134  From Design Towards Implementation  New Classes, Attributes, Operations  Impact on Existing Reuse Characterizations  Example - Bi-directional Related Classes: Stage 3: Object Design Consortium ATM OWNS Consortium verify_card process_trans ATM req_password verify_account dispense_cash print_receipt OWNS What is Potential Problem with ATM?

REUSE--135 Resolving via Redesign Reusability from ATP to AGP Consortium verify_card process_trans Auto Machine req_password verify_account print_receipt OWNS ATM dispense_cash COMMUNICATES WITH Attendant process_manual_trans monitor_transactions

REUSE--136  Prior Work Concentrated on Reuse Framework and Integration with OMT  UML has Succeeded OMT  What are Implications re. Reuse Framework?  Class and Object Diagrams Can Reuse be Tightly Integrated?  How can Use-Case Diagrams be Utilized?  Are Statechart, Activity, or Collaboration Diagrams Relevant?  What is Role of Component Diagrams?  Is there a Role for Deployment Diagrams? From OMT to UML

REUSE--137 Reusability and UML Eickhoff, 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

REUSE--138 Recall Three Key Definitions

REUSE--139 Revisiting Reuse Properties Implementation of X is more Specific than that of Y. X.F Might Contain Couplings to Classes Marked Specific. However, per Property 2, Y Must be at Least as General as X

REUSE--140 Revisiting Reuse Properties

REUSE--141 Revisiting Reuse Types

REUSE--142 Reuse Definition, Assessment, and Analysis in UML  Examination of Reuse in …  Use Case Diagrams  Class Diagrams  Behavior Modeling Diagrams  Component Diagrams  Reuse Improvement During Design  Transition from Design into Development  Consistency of Approach with Existing Reuse Model and Formal Refactoring Guidelines  Define Additional Properties  Introduce Refactoring Guidelines that Enforce the Properties of Reuse for UML Diagrams

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

REUSE--144 Use Cases with Include, Extend, and Inheritance  Dependencies Among Use Cases  Dependencies are Transitive w.r.t. Generalities

REUSE--145 Properties for Use Cases  Property 4: UC A extends UC B means UC A adds behavior to UC B, so UC A is at most as general as UC B or G UC-B  G UC-A  Property 5: UC A includes UC B is a relation of the behavior sequence of supplier UC B to the interaction sequence UC A. Thus, UC A is at most as general as UC B or G UC-B  G UC-A.  Property 6: UC A generalizes UC B relates child UC B to parent UC A, meaning that UC B is at most as general as UC A or G UC-A  G UC-B.

REUSE--146 Corresponding Refactoring Guidelines  RG1 or RG2 to Enforce Property 4 or Property 5:  The refactoring rule is: If G UC-B > G UC-A then refactor by making UC B more general (or UC A more specific) so G UC-B  G UC-A or by removing the extend/include.  RG3 to Enforce Property 6:  The refactoring rule is: If G UC-A > G UC-B then refactor by making UC A more general (or UC A more specific) so G UC-A  G UC-B or or by removing the generalization.

REUSE--147 Identifying Problems RG3 for Pay Cash  RG2 for Place Order: to G2 or Remove  RG2 for Place Order: to G2 or Remove  RG3 for Pay Cash: to G1 or Arrange Payment to G0 or Remove  RG3 for Pay Cash: to G1 or Arrange Payment to G0 or Remove

REUSE--148 UML Reuse and Class Diagrams  Definition 3: UC A is related to ℭ A = {C 1, C 2, …, C n } for some n, if UC A relies on ℭ A for functionality.  Property 7: UCs and Classes - Generality  Suppose UC A has ℭ A = {C 1, C 2, …, C n }. Then, the generality of UC A must be as specific as the most specific class in ℭ A, and may be more specific, i.e., G UC-A = max{generality  C i  ℭ A }.  RG4 to Enforce Property 7  The refactoring rule is: generality change of UC A or one or more C i in ℭ A until G UC-A = max{generality  C i  ℭ A }, or the removal of all classes in ℭ A that cause the G UC-A = max{generality  C i  ℭ A } to be violated.

REUSE--149 Classes and Generality Levels

REUSE--150 UML Reuse and Class Diagrams  Property 8: UCs and Classes - Related  Suppose that UC A is related to ℭ A and UC B is related to ℭ B. If UC A is related to UC B (extend, include, or generalize), then there has to be at least one transitive relation chain from one C i  ℭ A to one C j  ℭ B.  RG5 to Enforce Property 8  The refactoring rule is: Add one or more dependencies between class(es) C i  ℭ A and class(es) C j  ℭ B, or remove the relation between UC A and UC B

REUSE--151 UML Reuse and Class Diagrams  Property 9: UCs to UCs - Related  Suppose that UC A is related to ℭ A and UC B is related to ℭ B, and that UC A is not related to UC B (no extend, include, or generalize). Then, if at least one C i  ℭ A is directly related to at least one C j  ℭ B, there must be a refactoring.  RG6 to Enforce Property 9  The refactoring rule is: make UC A related to UC B or remove all dependencies between all C i  ℭ A and all C j  ℭ B.

REUSE--152 UML Reuse and Class Diagrams  Property 10: UCs and Classes - Related  Suppose that UC A is related to ℭ A. Then for all C i  ℭ A, if there is a transitive relation chain from C i to some C j  ℭ A, then UC A must also be related to C j in some manner. UC A can be either related directly to C j or it can be related to some UC B, to which C j is related  RG7 to Enforce Property 10  The refactoring rule is:  C i  ℭ A related to some C j  ℭ A include C j in ℭ A ( ℭ A = ℭ A  C j ), or relate UC A to some UC B where C j  ℭ B, or unrelate UC A to C i ( ℭ A = ℭ A - C j ).

REUSE--153 Refactored UC Diagram from Earlier Slide

REUSE--154 UML Reuse and Behavior Diagrams  Sequence and Collaboration Diagrams Can Also Impact on Reuse - Why?  Both Alter Dependencies  Introduce/Remove Associations  For Example:  Sequence Diagram Can Introduce New Dependencies Among Classes ( ℭ Sets)  Collaboration Diagram Could Also Introduce Similar Dependencies that Require Refactoring  See Paper for Details

REUSE--155 UML Reuse and Component Diagrams  Definitions for UML Components  Definition 4: Component and Classes that Implement it  Definition 5: Component and Façade that hides Implementation Details  Definition 6: Component and Abstract Classes/Interfaces  Accompanying Properties/Refactoring Guidelines  Property 11/RG8 - Components vs. Classes  Property 12/RG9 - Component vs. Component  Property 13/RG10 - Component vs. Façade  See Section 3.4 of Paper for Further Details

REUSE--156 Modifications to Together  Leverage Open APIs and Plug In Structure to Incorporate Reuse Model for UML into Together  Multi-Phase Approach  Directly Extend Property Windows of Use Cases and Classes for Generality Definition  Augment with new Window for Related  Add New Metrics Pane that Supports Analysis as Presented (Definitions, Properties, and RGs)  Briefly, we’ll Review Modifications  Please See Web Site for Full Details

REUSE--157 Setting Project Options

REUSE--158 UC: Generality and Related

REUSE--159 Classes: Generality and Related

REUSE--160 Components and Facades

REUSE--161 Class Screen with Reuse Pane

REUSE--162 Use Case Screen with Reuse Pane

REUSE--163 Use Case Screen with Reuse Pane

REUSE--164 Class Screen with Reuse Pane

REUSE--165 Running DRE and Metrics

REUSE--166 Analyzing Reuse and Refactoring  Affected Elements: Elements affected by warning.   Description: Provides a description of the warning   Refactoring Guideline: One or more refactoring guidelines for the currently selected warning

REUSE--167 Together: DRE-UML Warnings   Use Case Diagrams:  Generalities and Related Classes  Dependencies to other Use Cases (include, extend, generalize)   Class Diagrams:  Generalities and Related Classes  Dependencies to other Classes (association, dependency, generalization)   Sequence/Collaboration Diagrams: Method Calls   Component Diagrams:  Related and Façade Classes  Implemented Interfaces  Dependencies of Components and Interfaces

REUSE--168 Towards the Formalization of a Reusability Framework for Refactoring  Formal Definitions of Reuse Model to Allow Automatic and Algorithmic Analysis of Couplings  Cabellero and Demurjian at ICSR-7, 2002  OO Application Model  Reuse Framework  Automatically Refactors to “Improve” Reuse  Introduce Coupling Type Transition Matrix  Defines Loss, Gain, or Steady State Between the Various Coupling Types  +1 Going from G-->S to G-->G for Related Classes  -1 Going from G-->G to G-->S for Related Classes  0 Going from S-->G to S-->S for Related Classes

REUSE--169Goal  Increase Reuse Potential by Understanding Classes, Components, and their Role within Applications  Identify the Reusable Portions of Design  Estimate/Measure Reusability Automatically  Provide Guidelines on Improving Reusability  Usable for  Newly Created Designs  Evaluation of Legacy Code for Reuse Potential  Independent Tool/Integrated in Together  See: http://www.engr.uconn.edu/~steve/DRE/dre.html

REUSE--170 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 C p m of Methods M i  m Such that Each Method M i Belongs to Only One Class   I is the Set of Pair-wise Inheritance Relations of Classes in C   M is the Set of Pair-wise Coupling Among Methods

REUSE--171 Model - Pair-wise Couplings  Definition 2: Pair-wise Coupling  Two classes C p and C q are Pair-Wise Coupled when there is at Least One Method m i  C p M that Invokes a Method m j  C q M. CpCp m4m4 mimi m9m9 m1m1 m 20 CqCq mjmj m 18 m9m9 m5m5

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

REUSE--173 Class Reusability  General Classes  Expected to be Reused in Future Applications  Abstract Classes/Root Classes/Non-Leaf Classes in Inheritance Hierarchies  Domain Independent/Domain Specific  Specific Classes  Only Applicable in Current Applications  Unlikely to be Reused in Future Applications  Application Specific  Purpose: Determine Classes with Highest Reuse Potential for Organization’s Future Systems

REUSE--174 Model - Class Reusability  Definition 3: The Reusability Level of Class C i is Denoted by G c i  G c i =0  C i is the Most General Class in the Application  G c i =N (N>0)  C i is the Most Specific Class in the Application  Lower N, More General Class  Class Generality Vector

REUSE--175 Model - Relations Among Classes  Related Classes Promote Reuse, Since They are Expected to be Reused Together  Class C i is Related to Class C j if Expected to be Reused Together in Future Systems  Class C i Related to Class C j is Subjectively Assigned by Software Engineer (Producer)  Related Classes Assist in Reusability Assessment  Aside:  Unrelated Classes are NOT Expected to be Reused Together  Dependencies Among them Hinder Reuse

REUSE--176 Quantifying Reuse Properties  Property 1: Generality and Inheritance  Parent of a Class is Equally General or More General than is Direct Children  Property 2: Generality and Related Classes  Reuse Level of Class is Equal to the Reuse Level of the Least Reusable Coupled Class  Property 3: Extraneous Functionality  Classes that Don’t Contribute to Functionality of Component have Negative Impact on Reuse  Property 4: Generality and Unrelated Classes  Couplings Between Unrelated Classes Hinder Reuse

REUSE--177 Dependencies Among Classes  Object Inclusion: Class Contains a Instance of Another Object  Attribute Definition: Class Contains Attribute that is the Type of Another Object  Method Invocation: Class Invokes a Method Defined on Another Object  Goals  Classify and Understand Dependencies  Assess “Good” vs. “Bad” Dependencies  Change “Bad” to “Good” by  Changing Class from S to G or G to S  Moving Code and/or Method Calls  Splitting a Class into Two Classes  Merging Two Classes

REUSE--178 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 S G S Okay (Type 5) Okay (Type 7) Bad (Type 3)

REUSE--179 Dependencies: Non-Related Classes  G/S are Subjectively Assigned by Designer  The Two G Classes are Not Related  Non-Related Classes are NOT Intended to be Reused Together Okay (Type 6) Okay (Type 8) G S G S Bad (Type 2) Bad (Type 4)

REUSE--180 Sample Actions to Improve Reusability

REUSE--181 Core Guidelines to Move Couplings to Increase Reuse Potential G S G S Type 2 Type 8 G S G S Type 4 Type 8 G S G S Type 5 Type 1 G S G S Type 7 Type 1 Type 3G S G S Type 7 Type 1 G S G S Type 3

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

REUSE--183 Coupling Transitions Related Classes Unrelated Classes

REUSE--184 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

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

REUSE--186 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

REUSE--187 Additional Slides  Augment Slides from Main Portion of Talk  Replace Slide 143 on Refactoring Algorithm  Note: All Material in in ICSR Paper!

REUSE--188 Graph Content and Matrix

REUSE--189 Algorithm Steps

REUSE--197 Example - Assumptions  Assume Classes: C 1, C 2, C 3, C 4, C 5, C 6, C 7  Methods: m 1, m 2, m 3, m 4, m 5, m 6, m 7, m 8  Dependencies Among Methods (Couplings) Shown with Arrows

REUSE--198 Example - Generality and Related Steps 1, 2, 3 of Algorithm GGGG S S S  Establish Class Reusability   C 1, C 2, C 4, C 6  General   C 3, C 5, C 7  Specific  Calculate Couplings  Assume all Classes are Related Classes to One Another

REUSE--199 GGGG S S S Example - Determine Coupling Types Step 4 of Algorithm

REUSE--200 GGGG S S S Example - Identify Undesirable Couplings Step 5 of Algorithm

REUSE--201 Example - Refactor the Application Step 6 of Algorithm  For (m 3,m 5 ) Try to Move Source Method Down m3m3 No Improvement!

REUSE--202 Example - Refactor the Application Step 6 of Algorithm  For (m 4,m 6 ) Try to Move Source Method Down m4m4 Commit the Changes Set T=T ~

REUSE--203 Example - Refactor the Application Step 6 of Algorithm  For (m 5,m 7 ) try to Move Source Method Up m4m4 m5m5 Commit the Changes Set T=T ~

REUSE--204 Example - Refactored Class Diagram GGGG SS S

REUSE--205 Future: Formal Reuse Model  Future Work  Exploring Weightings (+2, +3, -3, etc.) for Transitions Among Coupling Types  Explore and Refine the Reuse Model  Theoretical Verification of Reuse Model  Use of Genetic Algorithm to Obtain “Near” Optimal Marking  Practical Perspective  Integrating Metric and Model in SDRE  Testing with “Real” Examples and Prior Examples  Extend Model to Apply to UML Reuse (see Next Group of Slides)

REUSE--206 A Graph-Based Algorithm for Automated Refactoring  Extending the Formal Definitions of Reuse Model to Allow Automatic and Algorithmic Refactoring  Cabellero and Demurjian at JIISIC 2003  Automatically Refactors to “Improve” Reuse  Model Couplings as a Directed Acyclic Graphy  Graph Represents Dependencies  Nodes Represent Classes  Edges Represent Couplings  Assign Generalities to Subject of Graph  Induce Remaining Generalities  Employ Topological Sort and Refactoring Algorithms

REUSE--207Goal  Reuse Metric, Framework and Tool  Increase Reuse Potential by Understanding Classes, Components, and their Role within Applications  Identify the Reusable Portions of Design  Estimate/Measure Reusability Automatically  Provide Guidelines on Improving Reusability  Applications to  Newly Created OO Designs  Evaluation of the Reuse Potential of Legacy Code

REUSE--208 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

REUSE--209 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 G C  {0,1,…N}  G C = N  C is the most general class in the application  G C = 0  C is the most specific class in the application  Retail Application : Class Item is General, While Class WalmartItem is More Specific.

REUSE--210 Relations Among Classes  Idea: Grouping of Classes that are Expected to Be Reused Together in Future Applications  Related Classes Promote Reuse, Since They are Expected to be Reused Together  Subjectively Assigned by Software Engineer (Producer)  Related Classes Assist in Reusability Assessment  If Class X is Related to Class Y then  When X is “Reused”, Y is Brought Along and Dependencies from X to Y are Encouraged  When Y is “Reused”, X in Not Brought Along and Dependencies from Y to X Hinder Reuse  Unidirectional

REUSE--211 Dependencies Among Classes  Object Inclusion  Class Contains a Instance of Another Object  Attribute Definition  Class Contains Attribute that is the Type of Another Object  Method Invocation  Class Invokes a Method Defined on Another Object  Inheritance Relations  etc…

REUSE--212 Quantifying Reuse Properties  Generality and Inheritance  Parent of a Class is Equally General or More General than is Direct Children  Generality and Related Classes  Reuse Level of Class is Equal to the Reuse Level of the Least Reusable Coupled Class  Generality and Unrelated Classes  Couplings Between Unrelated Classes Hinder Reuse

REUSE--213 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 S G S Ok (Type 5) Ok (Type 7) Bad (Type 3)

REUSE--214 Dependencies: Non-Related Classes  G/S are Subjectively Assigned by Designer  The Two G Classes are Not Related  Non-Related Classes are NOT Intended to be Reused Together Ok (Type 6) Ok (Type 8) G S G S Bad (Type 2) Bad (Type 4)

REUSE--215 Sample Actions to Improve Reusability

REUSE--216 Graph Based Refactoring  Classes are Modeled as a Directed Graph  Nodes Represent Classes  Edges Represent Couplings  Topological Sorting Arranges of a Directed Acyclic Graph into a Precedence Order  G=(V,E) is a DAG  If (u,v)  E then u appears before v in ordering  Reference Vertices  Set of Vertices of G Such that have been Assigned a Generality Level  Starting Point of the Analysis  Set of Classes Intended as General or Specific

REUSE--217Consistency  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 r u <r v, 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} r 1 =S, r 3 =G, r 8 =G, r 9 =S r 1 =S, r 3 =G, r 8 =G, r 9 =G r 1 =S, r 3 =S, r 8 =G, r 9 =S r 1 =G, r 3 =G, r 8 =S, r 9 =G r 1 =G, r 3 =G, r 8 =G, r 9 =S

REUSE--218 Consistent Topological Order R= {1,3,8,9} r 1 =S, r 3 =G, r 8 =G, r 9 =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)

REUSE--219 Topological Sort Consistent With Reference Vertices

REUSE--220 Induced Generality Level  Generality Level Assignment is Induced from the Graph Topology and the Reference Vertices  Algorithm Shows Conflicts Between Assignment to the Reference Vertices and Topological Order

REUSE--221 Refactoring Algorithm  1 Assign Generality Level to Reference Classes  2 For Each Connected Sub-Graph Find the Induced Generality Level  3 For Each Class where Induced Generality Level is in Conflict with Generality Assigned by SWE  Apply Refactoring  If the Sub-Graph Changed as a Result of the Refactoring Re-Calculate the Induced Generality Levels  If There Are Still Remaining Conflicts, Reassign Generality Levels to Reference Vertices and Goto 2  Re-Asses the Induced Generality Levels, if They Are Consistent With the Design Objectives Terminate. Otherwise Goto 2.

REUSE--227 Pull Up Method/Pull Up Field  Conditions:

REUSE--228 Push Up Method/Push Up Field  Conditions:

REUSE--229Example

REUSE--230Example G S  Reference Vertices  Topological Sorting  Induced Generality Level

REUSE--231Example G S G S  Reference Vertices  Topological Sorting  Induced Generality Level

REUSE--232Refactoring Push-Up m 4 Push-Down m 3

REUSE--233 Class Diagram After Refactoring  Re-Calculate Induced Generality GGGG S S S

REUSE--234Conclusions  Extended Reusability Framework Proposed by Price and Demurjian  Proposed a New Refactoring Algorithm  Uses Graph Theory Elements  Guides Refactoring Process  Improves Software Structure From Reuse Perspective  Algorithm Based On  Topological Sorting of the Class Diagram  Calculation of Induced Generality Levels for all Nodes  Provides Guidelines for Refactoring

REUSE--235 Ongoing and Future Work  Shortfalls  No Empirical Evidence that the Proposed Algorithm Works on Real Designs!  Software Engineer Strongly Involved in Refactoring  Related to Presented Work:  Extend/Refine/Reformulate Reusability Model  Incorporate Refactoring Algorithm into Tool  More Realistic Examples to Gather Empirical Evidence of the Utility of Our Algorithm

REUSE--236 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--237 Reuse Model Issues from Last Meeting  Clarify/Redefine “Related” Characterization  Transitivity of “Related” RR  W R to A, B, and C vs. W R to A, B, or C  Common Definitions for Package/Component  How is Marking of Package/Component Determined?  “Least” General Class Sets Package/Component Generality  Packages/Components Must Obey All Generality Rules of the Model/Framework  Inclusion of Interfaces into Model/Framework  Design Patterns and Impact on Reuse  Layering and the Reuse Model (Our Focus)

REUSE--238 Problem Domain Layering  Notion of General/Specific Impacted by Layering? Layer Component Layer Component CommonPerson ManufacturingPart ShipbuildingPiping-Part Company-SpecificSub-Piping-Part OKNot OK

REUSE--239 Recall Levels of Generality  Dependencies Encouraged Up Through the Layers  From S to G(0) or G(1) Specific Applications for Big Y or Shaw’s or Stop/Shop (S) Root classes for Items, ItemDB, etc., which are Most General. Inventory Control/Other Components. Classes Specific to Grocery Store Domain.

REUSE--240 Transition to Layers of Generality Big Y or Shaw’s or Stop/Shop (S) Root classes for Items, ItemDB, Inventory Control Other Components. Classes Specific to Grocery Store Domain.  Limit Interactions Among Layers  Only Adjacent Layer Allowed  Impose Strong Reuse Penalty Otherwise  Issues  Can Layer Contain Multiple Levels of G?  Red Class with  G(1), G(2), G(3)  Within Level, Established Reuse Principles Apply  Can There be Layers within Layers?

REUSE--241 Another Example of Levels of Generality Classes for Large Supermarket Classes for Specialty Supermarket Classes for 24 Hour Convenience Big Y or Shaw’s or Stop/Shop Root classes for Items, ItemDB, Inventory Control Other Components.  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?

REUSE--242 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)! Note: We Must Reconcile “Our” and EB Abstraction Definitions

REUSE--243 Relating the Different Abstractions Interface Package Component Class Contains - Type Level Uses - Instance Level

REUSE--244 Abstractions and Application CL2 CL3 CL4 CL7 CL6 CL8 CL5 CL1 CL9 INT_1 INT_3 INT_4 INT_5 INT_2 INT_6 Package A Package B Package C Component Y Component X

REUSE--245 Abstractions and Compartments Some Sample Compartments? CL2 CL3 CL4 CL7 CL6 CL8 CL5 CL1 CL9 INT_1 INT_3 INT_4 INT_5 INT_2 INT_6 Package A Package B Package C Component Y Component X

REUSE--246 Proposed Problem Solution  Define “Reusability Node” to Represent the Different Compartments of Application’s Classes, Interfaces, Packages, and Components  Specify the Rules for:  Composition of a Reusability Node  Dependencies Among Reusability Nodes  With these Rules, Result is a Reusability Graph of Reusability Nodes with Reusability Dependencies  Reusability Graph can be Layered  Objectives:  Formally Define Reusability Node, Dependency, Graph, and Layer  Can we Automate the Process When Given Source Code for Application?

REUSE--247 Definition 1: Reusability Node  A Reusability Node (RN) is a Set of Classes (Cl), Packages (P), Interfaces (I), and Components (Co) Marked With Varying Levels of Generality  Entities in RN Must Satisfy Current Reuse Analysis w.r.t. General/Specific/Related, Coupling Counts, etc.   RN x as Shown on Right   Classes, Packages, Interfaces, Components are Labeled as follows:  for i = 1 …n x are n x Generality levels CL2 CL3 CL4 CL5 CL1 INT_1 INT_3INT_2 Package B Component X RN x

REUSE--248 Assumptions: Reusability Node  Is the Makeup and Content of a RN Constrained?  What are Possible Constraints on  What are Possible Constraints on RN x ?  Levels of Generality  At Most 3 Different Generality Levels  Replication  Classes in Exactly One RN  Can Packages/Components be in Multiple RNs?  Interfaces Can be in One or More Different RNs  Do Components/Packages have Generality Level? CL2 CL3 CL4 CL5 CL1 INT_1 INT_3INT_2 Package B Component X RN x

REUSE--249 Objective: Reusability Node  Given Source Code (Classes, Interfaces, Packages, and Components) for Application, is it Possible to Dynamically/Automatically Determine all RNs?  What is Needed for this to Occur?  Each Class, Interface, Package, Component Must be Marked with Generality Level  Related Dependencies for Reuse are Defined  Parser that Synthesizes All of the Source Code Dependencies  Is this Problem NP Hard? Complete? CL2 CL3 CL4 CL5 CL1 INT_1 INT_3INT_2 Package B Component X RN x

REUSE--250 Aside: Marking Components/Packages  A Component/Package can Contain Components, Classes, and Interfaces  Remember, Class CL1 can be Defined in Package B and Used in Component X  Or, Component X can be Used in Package B  Components/Packages Must Run Through Reuse Metrics/Analysis to Eliminate Bad Dependencies  Package not Marked Since Utilize Portions of the Package and Not Package Itself  Components not Marked or Assumed Most General Package B Component X

REUSE--251 Definition 2: Reusability Dependency  A Reusability Dependency (RD) is a directed arrow between two Reusability Nodes, and, which satisfies the following:  A Reusability Dependency (RD) is a directed arrow between two Reusability Nodes, RN x and RN y, which satisfies the following:  for i = 1 …n x < for j = 1 …n y  RN x is Most General, RN y is Least General  Arrow from RN y to Rn x  Issues:  Should it be <= Rather than <?  < is Preferable, Since it Allows for a Cleaner Ordering Among Different RNs  Eliminates Ambiguity in Ordering

REUSE--252 Definition 2: Reusability Dependency  Issues:  Should Interfaces be Excluded from Ordering?  If Interfaces Replicated, Same Generality Level?  If Interfaces Non-Replicated, Include in Ordering?  Must Support Replicated Interfaces since Different Classes can Implement Same Interface Differently  Proposal regarding Interfaces  Interfaces are Not Marked  When Class “Implements” Interface, the Marking of the Interface is the Same as the Marking of Class  Hence, Interface Can have Different Markings in Different Classes

REUSE--253 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 RN y Can only Dependent on Lowest Level in RN x

REUSE--254 CL2 CL3 CL4 CL5 CL1 INT_1 INT_3INT_2 Package B Component X RN x CL7 CL8 CL6 INT_1 Package B Component Y RN y Package C INT_4 Quantifying a Reusability Dependency  Suppose RN x has Generality Levels of: G 0 G 1 G 2  Suppose RN y has Generality Levels of : G 3 G 4  Should Dependencies (Class, Method, Attr, etc.) be Limited to from G 3 in RN y to G 2 in RN x ?  Or, are Limits Unnecessary?

REUSE--255 Definition 3: Reusability Graph  A Reusability Graph (RG) is a Directed Graph with Reusability Nodes (Defn. 1) as Vertices which are Connected by Reusability Dependencies (Defn. 2) RN A RN H RN E RN D RN C RN B RN G RN F RN I RN J Issue: Are Cycles Allowed?

REUSE--256 Issues: Reusability Graph  Cycles:  A Cycle Indicates Co-Dependency Among Multiple Reusability Nodes - D, E, and H  Does this Imply All Must be Reused Together?  Automation  Assume that Reusability Nodes can be Automatically (Algorithmically) Determined When Given Application’s Source Code  Can Reusability Graph be Automatically Derived? Is this NP Hard? Complete?  Can we Use Genetic Algorithms for Problem?

REUSE--257 Definition 4: Reusability Layer  A Reusability Layer (RL) is a Subset of the RG that Represents a Grouping of RNs to Satisfy a Particular Domain or Organization Requirement RN A RN H RN E RN D RN C RN B RN G RN F RN I RN J

REUSE--258 Issue: What is Scope of a Layer?  Since RN A Depends on RN D which Depends on RN E which Depends on RN H which Depends on RN B, Should all Form the Layer? RN A RN H RN E RN D RN C RN B RN G RN F RN I RN J

REUSE--259 Issues: Reusability Layer  Cycles:  Recall a Cycle Means Co-Dependency Among Multiple Reusability Nodes - D, E, and H  If All Must be Reused Together then …  Will this Impact Layering - Must Layer Always Contain all Nodes in Cycle?  Can Layer Contain only Part of Cycle?  Automation  Intuitively, Automating Layers Doesn’t Make Sense  Layer is Domain Specific and Dictated by Designer

REUSE--260 Future Work Issues for Layering and Reusability  What are Limitations Across Layers? None???  How are Dependencies Tracked?  Defn. of RN and RD  Can There be Different Layered Perspectives for “Same” Design? Can All Layerings Coexist Together? Are Layerings Application Specific?  Yes to all Three - As shown on Previous Slide?  What are Issues to Develop a Reuse Model for Levels and Layers?  Formal Model and Analysis  Inter-Layer vs. Intra-Layer Reuse  Inter-Level vs. Intra-Level Reuse  Is there an EB Example to Demonstrate Ideas?

REUSE--261Conclusions  Comprehensive Reusability Model and Evaluation  General/Specific/Related Characterizations  Capture/Analyze Reusability of OO Software  Design Level (UML) and Code Level (DRE)  Achieve Highest Gain Through Early Identification and Reusability Evaluations!  Methodology and Empirical Verification  Guidelines to Encourage Reuse  Applicable to Reuse of Designs and Code  DRE Tool Family: SDRE, CDRE, TDRE  Strong Demonstration of Domain-and-Organization-Specific Reuse

REUSE--1 A Framework, Methodology and Tool for Reusable Software Components* † Special Thanks to Jeff Ellis, Rodrigo Caballero, Margie Price, Donald Needham.

Similar presentations

Presentation on theme: "REUSE--1 A Framework, Methodology and Tool for Reusable Software Components* † Special Thanks to Jeff Ellis, Rodrigo Caballero, Margie Price, Donald Needham."— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

REUSE--1 A Framework, Methodology and Tool for Reusable Software Components* † Special Thanks to Jeff Ellis, Rodrigo Caballero, Margie Price, Donald Needham.

Similar presentations

Presentation on theme: "REUSE--1 A Framework, Methodology and Tool for Reusable Software Components* † Special Thanks to Jeff Ellis, Rodrigo Caballero, Margie Price, Donald Needham."— Presentation transcript:

Similar presentations

About project

Feedback