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

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

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

4. REUSE--4Motivation

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

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

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

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

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

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

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

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

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

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

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

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

17. REUSE--17 CBD: Component-Based Development

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

19. REUSE--19 Specification Implementation Executable Interfaces Component

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

21. 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?

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

23. REUSE--23 RepositoryBrowserHierarchy Component Repository

24. REUSE--24 Multiple Repository Support Multiple Support

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

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

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

28. 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 CC  See: http://www.engr.uconn.edu/~steve/DRE/dre.html

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

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

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

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

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

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

35. 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); };

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

37. 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(); };

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

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

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

41. 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?

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

43. REUSE--43 Generality and Specificity within One Inheritance Hierarchy

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

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

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

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

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

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

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

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

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

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

54. 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?

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

56. 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!

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

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

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

60. REUSE--60 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

61. REUSE--61 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

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

63. REUSE--63 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!

64. REUSE--64 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!

65. REUSE--65 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

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

67. REUSE--67 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

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

69. REUSE--69 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!

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

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

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

73. REUSE--73 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

74. REUSE--74 Sample Actions to Improve Reusability

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

76. REUSE--76 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 G S G S Type 3 G S G S Type 7

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

78. REUSE--78 Extended 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?

79. REUSE--79 Extended 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

80. REUSE--80 Problem and Solution  Focus on Core Guidelines May Ignore the Impact of a Change for Other Related and Coupled Classes  When a Coupling is Moved from a G to S Class  Examine All Existing Coupling to G Class  G to G Coupling Now G to S  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 Guidelines to Govern all Potential Scenarios for Removing “Bad” Couplings

81. REUSE--81 Extended Guidelines 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

82. REUSE--82 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

83. REUSE--83 Extended Guidelines 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

84. REUSE--84 Extended Guidelines 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

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

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

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

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

89. REUSE--89 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)

90. REUSE--90 DRE and VRS-1 Tracking Incremental Versions

91. REUSE--91 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)

92. REUSE--92 DRE and VRS-2 Tracking Incremental Versions

93. REUSE--93 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?

94. REUSE--94 Resolving Type 3 G to S Dependency 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()

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

96. REUSE--96 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

97. REUSE--97 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

98. REUSE--98 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

99. REUSE--99 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

100. REUSE--100 Reusability of FinancialFrame Components  Undesirable Couplings Identified via Either Scenario can be Removed to Increase Reuse  Results of Such Actions w.r.t. FinancialFrame  Classes can be Reused with Classes 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

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

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

103. REUSE--103 SDRE - Main Application Window

104. REUSE--104 SDRE - Main Window – Setting Generality

105. REUSE--105 SDRE - Main Window – Setting Relations

106. REUSE--106 SDRE - Main Window – Choosing Simulation Options

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

108. REUSE--108 SDRE - Graphical Representation Generality Set for Design

109. REUSE--109 SDRE - Graphical Representation Setting Related Classes

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

111. REUSE--111 SDRE - Graphical Representation

112. REUSE--112 SDRE - Editing Source Code Enabled When Doubling Clicking

113. REUSE--113 SDRE - Editing Source Code Editor Appears with Line Highlighted

114. REUSE--114 SDRE - Editing Source Code Source Editor Features

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

116. REUSE--116 CDRE – DRE Client

117. REUSE--117 CDRE – Client Login

118. REUSE--118 CDRE – Project Selection

119. REUSE--119 CDRE – Remote Class Selection

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

121. REUSE--121 Reusability in Together CC

122. REUSE--122 Reusability in Together CC

123. REUSE--123 Reusability in Together CC

124. REUSE--124 Reusability in Together CC

125. REUSE--125 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

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

127. REUSE--127 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

128. REUSE--128 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

129. REUSE--129 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

130. REUSE--130 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

131. REUSE--131 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

132. REUSE--132 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

133. REUSE--133 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

134. REUSE--134 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

135. REUSE--135 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)

136. REUSE--136 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)

137. REUSE--137 Sample Actions to Improve Reusability

138. REUSE--138 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

139. REUSE--139 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

140. REUSE--140 Coupling Transitions Related Classes Unrelated Classes

141. REUSE--141 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

142. REUSE--142 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

143. REUSE--143 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

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

145. REUSE--145 Graph Content and Matrix

146. REUSE--146 Algorithm Steps

147. REUSE--147 Algorithm Steps

148. REUSE--148 Algorithm Steps

149. REUSE--149 Algorithm Steps

150. REUSE--150 Algorithm Steps

151. REUSE--151 Algorithm Steps

152. REUSE--152 Algorithm Steps

153. REUSE--153 Algorithm Steps

154. REUSE--154 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

155. REUSE--155 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

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

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

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

159. REUSE--159 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 ~

160. REUSE--160 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 ~

161. REUSE--161 Example - Refactored Class Diagram GGGG SS S

162. REUSE--162 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)

163. REUSE--163 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

164. REUSE--164Goal  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

165. REUSE--165 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

166. REUSE--166 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.

167. REUSE--167 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

168. REUSE--168 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…

169. REUSE--169 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

170. REUSE--170 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)

171. REUSE--171 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)

172. REUSE--172 Sample Actions to Improve Reusability

173. REUSE--173 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

174. REUSE--174Consistency  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

175. REUSE--175 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)

176. REUSE--176 Topological Sort Consistent With Reference Vertices

177. REUSE--177 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

178. REUSE--178 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.

179. REUSE--179 Algorithm Steps

180. REUSE--180 Algorithm Steps

181. REUSE--181 Algorithm Steps

182. REUSE--182 Algorithm Steps

183. REUSE--183 Algorithm Steps

184. REUSE--184 Pull Up Method/Pull Up Field  Conditions:

185. REUSE--185 Push Up Method/Push Up Field  Conditions:

186. REUSE--186Example

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

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

189. REUSE--189Refactoring Push-Up m 4 Push-Down m 3

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

191. REUSE--191Conclusions  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

192. REUSE--192 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 DRE Tool  More Realistic Examples to Gather Empirical Evidence of the Utility of Our Algorithm  Other Research:  Exploration of Reuse at Design within UML  Integration of Reuse Framework & Together CC  See: http://www.engr.uconn.edu/~steve/dre/dre.html

193. REUSE--193 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)?  Incorporation into TCC and Transition to DRE  Build and Extend the Formal Model (Caballero)  Under Submittal to ICSE 2003

194. REUSE--194 Revisiting Reuse Properties  Property 1: Generality and Inheritance  Parent of a Class is Equally General or More General than is Direct Children  Property 2: Generality and Related Classes  Reuse Level of Class is Equal to the Reuse Level of the Least Reusable Coupled Class  Property 3: Generality and Unrelated Classes  Couplings Between Unrelated Classes Hinder Reuse

195. REUSE--195 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

196. REUSE--196 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

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

198. REUSE--198 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.

199. REUSE--199 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.

200. REUSE--200 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

201. REUSE--201 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.

202. REUSE--202 Classes and Generality Levels

203. REUSE--203 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

204. REUSE--204 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 (there is not an extend, include, or generalize). Then, if at least one C i  ℭ A is directly related (meaning not by transitive relation chain) to at least one C j  ℭ B, there must be a refactoring to correct the problem.  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.

205. REUSE--205 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 ).

206. REUSE--206 Refactored UC Diagram from Earlier Slide

207. REUSE--207 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

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

209. REUSE--209 Modifications to Together CC  Leverage Open APIs and Plug In Structure to Incorporate Reuse Model for UML into TCC  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

210. REUSE--210 Setting Project Options

211. REUSE--211 UC: Generality and Related

212. REUSE--212 Classes: Generality and Related

213. REUSE--213 Components and Facades

214. REUSE--214 Running DRE and Metrics

215. REUSE--215 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

216. REUSE--216 TCC: 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

217. REUSE--217Conclusions  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

218. REUSE--218 Future Work - Reusability - Summary  Possible Short/Long-Term Research  Focus on Comprehensive Reuse Framework  Guided Reusability Assessment/GA Analysis  Component Repository with Search Capability  Leverage Domain/Organization Specificity  XML and Java Components