a framework, methodology and tool for reusable software components*
DESCRIPTION
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 - PowerPoint PPT PresentationTRANSCRIPT
REUSE--1
A Framework, Methodology and Tool A Framework, Methodology and Tool for Reusable Software Components*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 ConnecticutProf. Donald M. Needham
Computer Science DepartmentU.S. Naval Academy
[email protected]@[email protected]
http://www.engr.uconn.edu/~steve(860) 486 - 4818
*Work supported in part by a grant from Electric Boat, Inc., Groton, CT.
REUSE--2
MotivationMotivation Reuse Afterthought in OO Design/DevelopmentReuse Afterthought in OO Design/Development Majority of Reuse Focuses on “Small” Majority of Reuse Focuses on “Small”
Components with Minimal SavingsComponents with Minimal Savings String Functions, Utility Routines, GUI, etc. Easy to Understand - Easy to Reuse
““Beans” Have Improved Reuse - Still LaggingBeans” Have Improved Reuse - Still Lagging Three Classes of Software Three Classes of Software
Domain-Independent (20%) : Libraries, Utilities, etc. Most Likely to Be Reused
Domain-Specific (65%) : Dedicated SoftwareReused in Other Programs of Same Domain
Application-Specific (15%): UniquenessUnlikely to Be Reused
REUSE--3
MotivationMotivation Popular OO Design Methodologies Omit and Popular OO Design Methodologies Omit and
Ignore Reuse GuidelinesIgnore Reuse Guidelines Unified Modeling Language - UML Design Patterns - Reuse Pattern/Not Software
Current Research Concentrates on Current Research Concentrates on ConsumerConsumer (Reuser) and Not (Reuser) and Not ProducerProducer (Creator) (Creator) Measure Savings from Reuse Calculate Return on Investment
Two-Fold GoalTwo-Fold Goal Elevate Reuse to Equal Partner Starting with
Design Focus on Domain-and-Organization Specific
Reuse
REUSE--4
MotivationMotivation
Three Classes of Softwarein a Typical Software Application
Domain-Independent20% Domain-Specific
65%
Application-Specific15%
REUSE--5
MotivationMotivationWhy Software Reuse?Why Software Reuse?
Increase Software Productivity Increase Software Productivity Shorten Software Development Time Shorten Software Development Time Improve Software System Interoperability Improve Software System Interoperability Develop Software With Fewer People Develop Software With Fewer People Move Personnel More Easily From Project to Move Personnel More Easily From Project to
Project Project Reduce Software Development and Maintenance Reduce Software Development and Maintenance
Costs Costs Produce More Standardized Software Produce More Standardized Software Produce Better Quality Software Produce Better Quality Software Provide a Powerful Competitive AdvantageProvide a Powerful Competitive Advantage
REUSE--6
ObjectivesObjectives Reuse as Equal Partner Starting with DesignReuse 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 TechniquesCapabilities 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 PresentationOverview of Presentation Cultural and Social Reuse IssuesCultural and Social Reuse Issues Component-Based Design - History & PerspectiveComponent-Based Design - History & Perspective Reuse Framework and MethodologyReuse 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/ExamplesPrototyping: DRE Tool Family/Examples Conclusions and Future ResearchConclusions and Future Research
REUSE--8
Cultural and Social Reuse IssuesCultural and Social Reuse IssuesManagement SupportManagement Support
Motorola Study:Motorola Study: A New Reuse Program there must A New Reuse Program there must have Strong/Unequivocal Management Supporthave Strong/Unequivocal Management Support
Raytheon Report:Raytheon Report: Support from Upper Support from Upper Management Most Important for Successful ReuseManagement Most Important for Successful Reuse
Why? IncreasedWhy? Increased Cost Associated with Constructing Reusable
Components Communication, Coordination Education, Training
Motorola and Raytheon Facilitate by IncentivesMotorola and Raytheon Facilitate by Incentives Both Producer and Consumer Benefits Awards Provided for Demonstrated Efforts
REUSE--9
Cultural and Social Reuse IssuesCultural and Social Reuse IssuesHigh Initial CostHigh Initial Cost
Reports have IndicatedReports have Indicated High Start Up Costs Slow Return on Investment (> 3 years)
Best Success inBest Success in Starting with Small Projects Distributing Components for Reuse Opportunistic Reuse
Reuse Must be Supported byReuse Must be Supported by Libraries to Collect, Classify, and Disseminate
Components Ease of use for Producer and Consumer
REUSE--10
What are Components?What are Components? ADTs as Unit of Abstraction/ConceptualizationADTs as Unit of Abstraction/Conceptualization Classes are OO Equivalent of ADTsClasses are OO Equivalent of ADTs However, in Past 10 YearsHowever, 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 SeenIn Past 2-3 Years We’ve Seen
Emergence of Java Emergence of Java Beans Component-Based Development Tools
REUSE--11
What are Components?What are Components? How are Applications Conceptualized?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?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 ConceptsDefining Component Concepts A A ComponentComponent is Composed of One or More is Composed of One or More
Classes (or Other Components) and is Intended to Classes (or Other Components) and is Intended to Support a “Constructed” Unit of Functionality Support a “Constructed” Unit of Functionality
ClassesClasses Can be Utilized in Can be Utilized in Multiple ComponentsMultiple Components A Class Utilized in Multiple Components A Class Utilized in Multiple Components
Maintains the “Maintains the “SameSame” ” SemanticsSemantics in All of its in All of its ContextsContexts
Our Interest Involves: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 IssuesCultural and Social Reuse IssuesReuse and Software Design/DevelopmentReuse and Software Design/Development Lesson LearnedLesson Learned
Reuse Often Avoided by SW Engineers due to Fear of Configuration Management Problems
How is Fear Minimized?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 SummarySummary
We’ll Concentrate on Technical Reuse Issues Superior Techniques Will Remain Unpopular
and Unused without Associated Support
REUSE--14
Components vs. ObjectsComponents vs. Objects ComponentsComponents
Business Oriented Coarse Grained Standards Based Multiple Interfaces Provide Services Fully Encapsulated Understood by
Everyone
ObjectsObjects Technology-Oriented Fine Grained Language Based Single Interface Provide Operations Use Inheritance Understood by
Developers
REUSE--15
Reusable Components Reusable Components Types & BenefitsTypes & Benefits
Application Template Application Template Data Model Data Model Data Structure Data Structure System Architecture System Architecture Process Model Process Model Process Definition Process Definition Prototype Prototype Plan Skeleton Plan Skeleton User Interface User Interface
Skeleton/GUISkeleton/GUI Process SkeletonProcess Skeleton Utility ComponentsUtility Components
Organizational Organizational PerspectivePerspective Shorten Development
Time Reduce Costs Increase
Competitiveness Personnel PerspectivePersonnel Perspective
Increase Productivity Customer Perspective Customer Perspective
Achieve Greater User Satisfaction Through the Production of More Flexible Products
REUSE--16
Component-Based Development ProcessComponent-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 DevelopmentCBD: Component-Based Development
REUSE--18
Supplier /Consumer ModelSupplier /Consumer Model
SUPPLY Build New Wrap Existing Buy
CONSUME Assemble Applications
MANAGE Publish Subscribe Catalog Browse
REUSE--19
SpecificationSpecification
ImplementationImplementation
ExecutableExecutable
InterfacesInterfaces
ComponentComponent
REUSE--20
Components as Assets can GrowComponents as Assets can Grow
Complexity of ComponentComplexity of Component
REUSE--21
What are Component Dependencies?What are Component Dependencies?
Dependency Type of ComponentsDependency Type of Components VersionsVersions AggregationsAggregations FunctionalFunctional InheritanceInheritance AssociationAssociation
What is Impact of Each Dependency on the What is Impact of Each Dependency on the Reusability of a Component?Reusability of a Component?
REUSE--22
Component-Based Tools/Web Sites of NoteComponent-Based Tools/Web Sites of Note
Software Software Composition Composition WorkbenchWorkbench
JavaBeansJavaBeans Visual CaféVisual Café Visual J++Visual J++ Sun’s ForteSun’s Forte Enabler, SoftlabEnabler, Softlab Microsoft Microsoft
RepositoryRepository UREP, UnisysUREP, Unisys Select Software Select Software
Tools, SelectTools, Select
Reusable Software Research Group, Reusable Software Research Group, West Virginia University West Virginia University http://www.csee.wvu.edu/~resolve/scw/rsrg
-brochure-nov-98.html Reusable Software Research Group, Reusable Software Research Group,
Ohio State UniversityOhio State University http://www.cis.ohio-state.edu/rsrg
/index.html Select Software ToolsSelect Software Tools
http://www.selectst.com/ Software Reuse Executive Primer, Software Reuse Executive Primer,
DODDOD http://dii-sw.ncr.disa.mil/ReuseIC/pol-
hist/primer/ Model-Driven Software Reuse, Model-Driven Software Reuse,
Extended Intelligence Inc.Extended Intelligence Inc.
REUSE--23
RepositoryRepositoryBrowserBrowser
HierarchyHierarchy
Component RepositoryComponent Repository
REUSE--24
Multiple Repository SupportMultiple Repository Support
Multiple SupportMultiple Support
REUSE--25
CBD life cycleCBD life cycle
BusinessBusinessDirectionDirection
General BusinessGeneral BusinessRequirementsRequirements
User, BusinessUser, Businessand Data servicesand Data services
Business andBusiness andData servicesData services
ComponentComponentRequirementsRequirements
UserUserServicesServicesHarvestHarvest
REUSE--26
1996: $652 million1996: $652 million 2001: $12 billion2001: $12 billion
IDC forecast CBD marketIDC forecast CBD market
REUSE--27
Web-Site ReferencesWeb-Site References Reusable Software Research Group, West Reusable Software Research Group, West
Virginia UniversityVirginia University http://www.csee.wvu.edu/~resolve/scw/rsrg-brochure-
nov-98.html Reusable Software Research Group, Ohio Reusable Software Research Group, Ohio
State UniversityState University http://www.cis.ohio-state.edu/rsrg/index.html
Select Software ToolsSelect Software Tools http://www.selectst.com/
Software Reuse Executive Primer, DODSoftware Reuse Executive Primer, DOD http://dii-sw.ncr.disa.mil/ReuseIC/pol-hist/primer/
Model-Driven Software Reuse, Extended Model-Driven Software Reuse, Extended Intelligence Inc.Intelligence Inc.
REUSE--28
A Framework, Methodology, and Tool for A Framework, Methodology, and Tool for Reusable Software ComponentsReusable Software Components
Reuse as Equal Partner Starting with DesignReuse 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 TechniquesCapabilities 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
REUSE--29
A Framework, Methodology, and Tool for A Framework, Methodology, and Tool for Reusable Software ComponentsReusable Software Components
1. Define Components, Their 1. Define Components, Their Interactions, and Analyze Interactions, and Analyze Their ReusabilityTheir Reusability
2. Store an Iteration of Design2. Store an Iteration of Design3. Implement an Iteration3. Implement an Iteration4. Store and Document 4. Store and Document
Iteration of ImplemenIteration of Implemen..5. Reevaluate an Existing 5. Reevaluate an Existing
Design forDesign for Correcting Errors New Reuse Potential
6. Reuse Existing Design with 6. Reuse Existing Design with a New Implementationa New Implementation
Store &DocumentDesigns
ReusabilityEvaluation
Implementthe System
Re(Design)a System
Store &DocumentImplemens.
11
55
4466 33
22
REUSE--30
Subjective IdentificationSubjective Identification ofof ComponentComponentss Reuse Historically Occurs at Class LevelReuse Historically Occurs at Class Level Class as “Atomic” Component only Scratches Surface Class as “Atomic” Component only Scratches Surface
in Reuse Potential for OOin Reuse Potential for OO But, Classes InteractBut, Classes Interact
If Reuse One, Often Need Others Thus, Reuse Set of Classes
Expand Reuse from Class to Component LevelExpand Reuse from Class to Component Level Establish Framework for Promoting Design ReuseEstablish 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 Goal: Increase Reuse Potential by Understanding
Classes, Components, and their Role within Appl.Classes, Components, and their Role within Appl.
REUSE--31
General/Specific ClassGeneral/Specific Class CharacterizationCharacterization Subjective Characterization by Software DesignerSubjective Characterization by Software Designer Best Estimate on Potential Utility of ClassBest Estimate on Potential Utility of Class General Class (G)General Class (G)
Those Application Classes that Facilitate Domain-and-Organization Specific Reuse
Specific Class (S)Specific Class (S) Those Application Classes that are Limited to
use in a Single Application PurposesPurposes
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 ClassGeneral/Specific Class CharacterizationCharacterization General Class (G)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)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)High-Tech Supermarket System (HTSS)
Automate the Functions and ActionsAutomate the Functions and Actions Cashiers and Inventory Updates User Friendly Grocery Item Locator Fast-Track Deli Orderer Inventory Control
User System Interfaces 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 ArchitectureThe HTSS Software Architecture
ICICICIC
CRCRCRCR
CRCR
CRCR
ILILILIL
ILILSDOSDO
SDOSDO EDOEDO
EDOEDO
OrderOrder
PaymentPayment
ItemItemItemDBItemDBLocalLocalServerServer
Non-LocalClient Int.
InventoryInventoryControlControl
ItemDBItemDBGlobalGlobalServerServer
OrderDBOrderDB
SupplierDBSupplierDB
CreditCardDBCreditCardDB
ATM-BanKDBATM-BanKDB
IL: Item IL: Item LocatorLocator
CR: Cash RegisterCR: Cash RegisterIC: Invent. ControlIC: Invent. Control
DO: Deli Orderer forDO: Deli Orderer for Shopper/EmployeeShopper/Employee
REUSE--35
A General Class in HTSSA General Class in HTSS Why is Why is ItemItem General? General? What is Applicability of What is Applicability of ItemItem??
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 HTSSAnother General Class in HTSS Collection Classes of General Classes are General 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 HTSSYet Another General Class in HTSS GUI-Based Class for Supporting Inventory GUI-Based Class for Supporting Inventory
Control Actions Can be Domain IndependentControl 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 HTSSSpecific Classes in HTSS
General Classes are Refined to Represent General Classes are Refined to Represent Particular Items, Yielding Specific ClassesParticular Items, Yielding Specific Classes
...
Item
DairyItemProduceItem DeliItem
DeliOrdererGUI
OrdererGUI
REUSE--39
Levels of General ClassesLevels of General Classes Not All General Classes Created EquallyNot All General Classes Created Equally Level of Generality Based on Role in ApplicationLevel of Generality Based on Role in Application
PurposesPurposes Accommodate Large Systems with Multiple,
Different Reusable Components Reusable Components can Overlap, but Still be
Distinct Reusable Units
S,...,G,G,G 2100G
2G0G 0G
1G
2G S
S1G views as General if i j views as Specific if i < j
iG jG
jGiG
REUSE--40
...
Can you Identify Different Levels Can you Identify Different Levels of General Classes?of General Classes?
Item
DairyItemProduceItem DeliItem
NonPerishItem PerishItem
)(G0
)(G1 )(G1
REUSE--41
...
Can we Identify Different Levels Can we Identify Different Levels of General Classes?of General Classes?
DairyItem DeliItem
Item
ProduceItem
NonPerishItem PerishItem
)(G0
)(G1 )(G1
)(G2)(G2
BigYProdItem DoleProdItem BigYDairyItem HoodDairyItem
Where can ItemWhere can Itembe Reused?be Reused? Where can Where can
NonPerishItem NonPerishItem and PerishItemand PerishItembe Reused?be Reused?
Where can ProduceItem and Where can ProduceItem and DairyItem be Reused?DairyItem be Reused?
Are DoleProdItem and HoodDairyItem Specific?Are DoleProdItem and HoodDairyItem Specific?
REUSE--42
Properties of General/Specific ClassesProperties of General/Specific Classes Level of Generality Strictly Ordered in HierarchyLevel of Generality Strictly Ordered in Hierarchy A Descendant of a General Class Must have an A Descendant of a General Class Must have an
Index Greater Than or Equal to Itself or be SpecificIndex Greater Than or Equal to Itself or be Specific A Specific Class Can only have Specific A Specific Class Can only have Specific
DescendantsDescendants
S,...,G,G,G 2100G
2G0G 0G
1G
2G S
S1G views as General if i j views as Specific if i < j
iG jG
jGiG
REUSE--43
Generality and Specificity Generality and Specificity within One Inheritance Hierarchywithin One Inheritance Hierarchy
G
GG
S
G
G
SS
S
SS
Fi g . G e n e r a l ( G ) / S p e c i f i c ( S ) C l a s s e s o f a H i e r a r c h y
REUSE--44
Generality/Specificity/DependenciesGenerality/Specificity/DependenciesAcross Multiple HierarchiesAcross Multiple Hierarchies
G
SG
GS
S
S
SS
G
GG
S
G
G
SS
S
SS
Fi g . Ty p e s o f C o u p l i n g s b e t w e e n C l a s s H i e r a r c h i e s
REUSE--45
General/Specific Paradigm in HTSSGeneral/Specific Paradigm in HTSS
Abstraction from Abstraction from HTSSHTSS to to Domain IndependentDomain Independent Inventory Control ApplicationInventory Control Application
Separation of Supermarket Domain SpecificsSeparation of Supermarket Domain Specifics Leverage Commonalties for Leverage Commonalties for
Focused, Independent Design/Development Future Products
RelevanceRelevance 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 DomainReusability in HTSS Domain
Where do Changes for Other Domains Occur?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.
)(G0
)(G1
)(G2
REUSE--47
Reusability in HTSS DomainReusability 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 ControlOther Components.
Classes Specific to Grocery Store Domain.
)(G0
)(G1
)(G2
Inventory Control Tool for Ordering Items from Suppliers
Cost Accounting Tool for Tracking Net and Gross Profit
REUSE--48
Reusability in HTSS DomainReusability 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.)(G0
)(G1)(G2
Classes forLargeSupermarket
Classes forSpecialtySupermarket
Classes for24 HourConvenience
REUSE--49
The FinancialFrame ApplicationThe FinancialFrame Application
A Commercial C++ Framework Containing 441 A Commercial C++ Framework Containing 441 Classes, Proprietary of FinancialCompClasses, Proprietary of FinancialComp
Designed for Reuse in Various Financial Apps.Designed for Reuse in Various Financial Apps. Provides Basic Functionalities of Financial SystemProvides Basic Functionalities of Financial System FinancialFrame’s Challenge - Manage ChangesFinancialFrame’s Challenge - Manage Changes
Framework Constantly Evolving New Functions and Modify Existing Functions
Conceptual Relevance:Conceptual Relevance: Provide Realistic Context for Our Approach Domain-and-Organization-Specific Reuse
REUSE--50
The FinancialFrame ApplicationThe FinancialFrame Application
Our Purpose: Work with Existing CodeOur 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: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 General and Specific Classes in FinancialFrameFinancialFrame
FinancialCompTrader )(G2
FinancialCompAccount )(G2
FinancialCompDesk )(G2
)(G0Main
FinancialCompMain OtherMain
SpecificFCMain (S) SpecificOtherMain (S)
)(G2 )(G2 ...
)(G0YieldModel
DiscountIndexBond )(G1 )(G1 Bill )(G1
)(G0CashFlowAnalyzer
...
REUSE--52
Related Classes and HierarchiesRelated Classes and Hierarchies Class X is Related to Class YClass X is Related to Class Y if they are Related if they are Related
and Concept and are and Concept and are Expected to be ReusedExpected to be Reused TogetherTogether in Future Systems in Future Systems
Class X Related to Class Y is Class X Related to Class Y is Subjectively Subjectively AssignedAssigned by Software Engineer (Producer) by Software Engineer (Producer)
When Class X is Related to Class YWhen 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 Related Classes Promote Reuse, Since They are
Expected to be Reused TogetherExpected to be Reused Together
REUSE--53
Related Hierarchies/Reusable Related Hierarchies/Reusable ComponentsComponents
Two Sub-Hierarchies are Related if to Reuse One, Two Sub-Hierarchies are Related if to Reuse One, you Must Reuse the Otheryou Must Reuse the Other
Purpose: Purpose: Identify Reusable Dependencies Among Identify Reusable Dependencies Among Related ClassesRelated Classes
Reusable Component: Reusable Component: A Set of Related Classes that A Set of Related Classes that are Expected to be Reused as a Groupare Expected to be Reused as a Group
0G
0G 0G
S0G
0G
S0G
S
A Sub-Hierarchies BA Sub-Hierarchies B
RR
REUSE--54
Related Characterization in Related Characterization in Levels of Components - HTSSLevels of Components - HTSS
Item
NonPerishItem PerishItem
)(G0
)(G1 )(G1 Environ )(G1RR
DairyItemProduceItem DeliItem SubZero RTemp
Does Does RR from Environ to PerishItem Make Sense? from Environ to PerishItem Make Sense? Should Should RR be from PerishItem to Environ? be from PerishItem to Environ?
REUSE--55
Related Characterizations in Related Characterizations in Levels of Components - HTSSLevels of Components - HTSS
Where do Changes for Other Domains Occur?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.
)(G0
)(G1
)(G2
REUSE--56
Related Characterization in Related Characterization in Levels of Components - FinancialFrameLevels of Components - FinancialFrame
...
)(G0YieldModel
DiscountIndexBond )(G1 )(G1 Bill )(G1
Bond )(G1
R
Bond is Related to IndexBondBond is Related to IndexBond When Bond is Reused, so Must IndexBond and When Bond is Reused, so Must IndexBond and
YieldModel YieldModel Hence, IndexBond and its Ancestor (YieldModel) are Hence, IndexBond and its Ancestor (YieldModel) are
Reused!Reused!
REUSE--57
Related Characterizations in Related Characterizations in Levels of Components - FinancialFrameLevels of Components - FinancialFrame
Classes/Sub-Hierarchies can be Related if and only Classes/Sub-Hierarchies can be Related if and only if Classes (or Sub-Hierarchy Roots) are General if Classes (or Sub-Hierarchy Roots) are General and at the Same or Higher Leveland at the Same or Higher Level
Specific applications at FinancialComp (S)
Root classes of strategies andother most General classes (Main)
Bond or other strategy Components
Classes specific to FinancialComp
)(G0
)(G1
)(G2
REUSE--58
What are Dependencies Among Classes?What are Dependencies Among Classes?
Object Inclusion: Object Inclusion: Class Contains a Instance of Class Contains a Instance of Another ObjectAnother Object
Attribute Definition: Attribute Definition: Class Contains Attribute that Class Contains Attribute that is the Type of Another Objectis the Type of Another Object
Method Invocation: Method Invocation: Class Invokes a Method Class Invokes a Method Defined on Another ObjectDefined on Another Object
GoalsGoals 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--59
Reusing Sub-Hierarchies in Reusing Sub-Hierarchies in Different Components - HTSSDifferent Components - HTSS
Will be reused with Componentsfor another domain,e.g., Toy Store
Will be reused with Componentsfor different Super-market Companies
Item
...DairyItemProduceItem DeliItem
NonPerishItem PerishItem
REUSE--60
Reusing Sub-Hierarchies in Reusing Sub-Hierarchies in Different Components - FinancialFrameDifferent Components - FinancialFrame
Dependencies Among General Related ClassesDependencies Among General Related Classes Not a Hindrance to Reuse Represents Valuable Design Knowledge
)(G0Main
FinancialCompMainOtherMain
SpecificFCMain (S)SpecificOtherMain (S)
)(G2)(G2
Will be reused with Componentsutilizing another company’s databases
Will be reused with Componentsutilizing FinancialComp’s database
REUSE--61
Transitivity in Inheritance and Transitivity in Inheritance and Related RelationshipsRelated Relationships
Base CaseBase Case: Related Characterization is : Related Characterization is TransitiveTransitive, , but not but not CommutativeCommutative
A B CR R
Case 1Case 1: A is : A is notnot related to X related to X Dependencies from A to X Dependencies from A to X are are notnot Desirable Desirable
Recall: We Reuse X and AllRecall: We Reuse X and All of Its Ancestors, But Not of Its Ancestors, But Not B’s Ancestors to Reuse AB’s Ancestors to Reuse A
A
B
C
XR
REUSE--62
An Example of Case 1 in FinancialFrameAn Example of Case 1 in FinancialFrame FinancialCompMain FinancialCompMain RR FinancialCompTrader FinancialCompTrader
Thus, Dependencies Between are DesirableThus, Dependencies Between are Desirable Main is Main is not Rnot R to FinancialCompTrader to FinancialCompTrader
Thus, Dependencies Between Hinder ReuseThus, Dependencies Between Hinder Reuse For For “Blue” “Blue” Component, we Don’t Want to Have to Component, we Don’t Want to Have to
Reuse FinancialCompTrader with Main!Reuse FinancialCompTrader with Main!
)(G0Main
FinancialCompMainOtherMain )(G2)(G2
FinancialCompTrader )(G2
R
REUSE--63
Transitivity in Inheritance and Transitivity in Inheritance and Related RelationshipsRelated Relationships
B
A
C
X
R
Case 2Case 2: X is Related to A : X is Related to A Dependencies from X to Dependencies from X to Both A and B are Both A and B are DesirableDesirable
When Reuse X, Since X When Reuse X, Since X Related to B, we Reuse B and Related to B, we Reuse B and All of Its Ancestors (A)All of Its Ancestors (A)
Thus, Dependencies Between Thus, Dependencies Between X and A are Okay!X and A are Okay!
REUSE--64
An Example of Case 2 in FinancialFrameAn Example of Case 2 in FinancialFrame
...
)(G0YieldModel
DiscountIndexBond )(G1 )(G1 Bill )(G1
Bond )(G1
R
Class Bond Class Bond RR to both IndexBond and YieldModel to both IndexBond and YieldModel Thus, Dependencies from Bond to IndexBond and Thus, Dependencies from Bond to IndexBond and
YieldModel are Desirable and Reusable!YieldModel are Desirable and Reusable! When Bond is Reused, So is IndexBond and When Bond is Reused, So is IndexBond and
YieldModel!YieldModel!
REUSE--65
Evaluative Metrics and MethodologyEvaluative Metrics and MethodologyObjective Measures of DependenciesObjective Measures of Dependencies
Object-Oriented Design: Object-Oriented Design: Collection of General and Specific Classes, with Related Characterizations
Recall Dependencies Among ClassesRecall Dependencies Among Classes Object Inclusion: Another Instance within Class Attribute Defn.: Attribute Type of Class Method Invocation: Defined on Another Class
Quantify Dependencies for ReuseQuantify Dependencies for Reuse Good: Promotes Reuse - Leave Alone Bad: Hinders Reuse - Try to Change Okay: No Impact on Reuse - Can be Improved
GoalsGoals Classify and Understand Dependencies Measure Reuse Potential
REUSE--66
Dependencies Among Related ClassesDependencies Among Related Classes Remember, G/S are Subjectively Assigned by Remember, G/S are Subjectively Assigned by
Software DesignerSoftware Designer The Two G classes are Related The Two G classes are Related Related Classes are Intended to be Reused Related Classes are Intended to be Reused
TogetherTogetherGood (1)
G
S
G
SOkay (5)
Okay (7)
Bad (3)
REUSE--67
Sample Dependencies in HTSSSample Dependencies in HTSS
InvCont
DeliIC
Item
DeliItem
Good (1)
Okay (5)
Okay (7)
Bad (3)
InvCont and Item are Related InvCont and Item are Related ClassesClasses
InvCont to Item Dependencies InvCont to Item Dependencies are Good: Reused Togetherare Good: Reused Together
Dependency from InvCont to Dependency from InvCont to DeliItem is ProblemDeliItem is Problem Don’t Want to Reuse
InvCont with DeliItem ManagerGUI with InvCont
Includes Useless DeliItem Dependencies from DeliIC to Dependencies from DeliIC to
Item and/or DeliItemItem and/or DeliItem Don’t Impact Reuse Can Reuse Item and
DeliItem w/o DeliIC
REUSE--68
Dependencies Among Non-Related Dependencies Among Non-Related ClassesClasses
Remember, G/S are Subjectively Assigned by Remember, G/S are Subjectively Assigned by Software DesignerSoftware Designer
The Two G Classes are Not RelatedThe Two G Classes are Not Related Non-Related Classes are Non-Related Classes are NOT NOT Intended to be Intended to be
Reused TogetherReused Together
Okay (6)
Okay (8)
G
S
G
S
Bad (2)
Bad (4)
REUSE--69
Sample Dependencies in HTSSSample Dependencies in HTSS
InvCont
DeliIC
Person
Shopper
Bad(2)
Okay (6)
Okay (8)
Bad (4)
InvCont and Person are Classes InvCont and Person are Classes that are Not Relatedthat are Not Related
InvCont to Person or Shopper InvCont to Person or Shopper Dependencies are BadDependencies are Bad Don’t Want to Reuse
Person/Shopper with InvCont
Must Reuse - Problem! Dependencies from DeliIC to Dependencies from DeliIC to
Person and/or ShopperPerson and/or Shopper Don’t Impact Reuse Can Reuse Person and
Shopper w/o DeliIC However, Poor Design if
DeliIC Needs Person or Shopper!
REUSE--70
Summarizing Couplings ofSummarizing Couplings ofRelated ClassesRelated Classes
Type 1: Good for ReuseType 1: Good for Reuse Two General Classes are Reused Together
Type 3: Bad for ReuseType 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 ReuseTypes 5/7: Okay for Reuse No Impact Specific Classes Not Reused in New
Application May Improve Reuse if Changed to Type 1
REUSE--71
Summarizing Couplings ofSummarizing Couplings ofNon-Related ClassesNon-Related Classes
Type 2: Bad for Reuse - Two General 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 ReuseType 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 ReuseTypes 6/8: Okay for Reuse No Impact Specific Classes Not Reused in New Application
REUSE--72
Dependencies in Levels of ComponentsDependencies in Levels of ComponentsSummarizing Related ClassesSummarizing Related Classes
0G
1G
2G
0G
1G
2G
(1)
(3)
(3)
0G
1G
2G
0G
1G
2G
(5)
(7)
(7)
0G
1G
2G
0G
1G
2G (1)
(1)
(1)
0G 0GRelated to2G 2GRelated to
REUSE--73
Dependencies in Levels of ComponentsDependencies in Levels of ComponentsSummarizing Non-Related ClassesSummarizing Non-Related Classes
0G
1G
2G
0G
1G
2G
(2)
(4)
(4)
0G
1G
2G
0G
1G
2G
(6)
(8)
(8)
0G
1G
2G
0G
1G
2G (2)
(2)
(2)
Dependencies Among Unrelated Classes AlwaysDependencies Among Unrelated Classes Always Bad for Reuse No Impact on Reuse
REUSE--74
Sample Actions to Improve ReusabilitySample Actions to Improve Reusability
Coupling Among Related Among Unrelated
G G Type (1)Good for Reuse
Type (2)Bad for ReuseMove Src./Dst. to Specific
G S Type (3)Bad for ReuseMove Dst. to General
Type (4)Bad for ReuseMove Src. To Specific
S G Type (5)Can Improve if MoveSrc. to General
Type (6)No Impact on Reuse
S S Type (7) - Can Improveif Move Src./Dst. to Gen.
Type (8)No Impact on Reuse
REUSE--75
Reuse GuidelinesReuse Guidelines Methodological Basis for Increasing ReuseMethodological 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 CouplingsIdeal 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 ChoicesExtended Guidelines: Menu of Choices Different Ways to Move Couplings Considers Impact of Movement on Design
Goal: Iterative Improvement in ReusabilityGoal: Iterative Improvement in Reusability
REUSE--76
Core Guidelines to Move Couplings to Core Guidelines to Move Couplings to Increase Reuse PotentialIncrease Reuse Potential
G
S
G
S
Type 2
Type 8
G
S
G
S
Type 4
Type 8
G
S
G
SType 5
Type 1 G
S
G
SType 7
Type 1
Type 1G
S
G
SType 3
G
S
G
SType 7
REUSE--77
Extended Guidelines for Extended Guidelines for Improving ReusabilityImproving Reusability
Core Guidelines Emphasize Local BehaviorCore Guidelines Emphasize Local Behavior To Remove “Bad” or Improve “Okay” Coupling, To Remove “Bad” or Improve “Okay” Coupling,
Move Cause of the Coupling (e.g., Method Call)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 Moving Method Up/Down a Hierarchy, Which Alters the Coupling, Alters the Coupling, Can Impact ElsewhereCan Impact Elsewhere
Expand the Analyses to Other Couplings of the Expand the Analyses to Other Couplings of the Source and Destination of the Bad Coupling Source and Destination of the Bad Coupling Couplings to Source when Moving Down Couplings to Destination when Moving Up
Extended Guidelines: Menu of ChoicesExtended Guidelines: Menu of Choices
REUSE--78
Extended Guidelines to Improve ReuseExtended Guidelines to Improve ReuseIdentifying the ProblemIdentifying 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--79
Extended Guidelines to Improve ReuseExtended Guidelines to Improve ReuseIdentifying the ProblemIdentifying 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
SType 5
Type 1
Recall
REUSE--80
Problem and SolutionProblem and Solution Focus on Core Guidelines May Ignore the Impact Focus on Core Guidelines May Ignore the Impact
of a Change for Other Related and Coupled Classesof a Change for Other Related and Coupled Classes When a Coupling is Moved from a G to S ClassWhen 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 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 Solution: Extended Guidelines to Govern all Potential Scenarios for Removing “Bad” CouplingsPotential Scenarios for Removing “Bad” Couplings
REUSE--81
Extended Guidelines for Extended Guidelines for Type 3Type 3 Couplings Couplings
Move Coupling Dst. to General ClassMove Coupling Dst. to General Classor Change Dst. To a General Classor Change Dst. To a General Class Type 3 to Type 1 May Introduce Couplings from G
Dst. to Specific Classes Move Coupling Src. to Specific ClassMove Coupling Src. to Specific Class
or Change Src. To a Specific Classor Change Src. To a Specific Class Type 3 to Type 7 May Introduce Couplings from
General Classes to Specific Src. Change to Non-Related/Follow Change to Non-Related/Follow Type 4Type 4 Detailed Evaluation of ImplementationDetailed Evaluation of Implementation Key ConcernsKey Concerns
Local Changes with Global Impact “Wrong” Choice Degrades Reuse
G
S
G
S
Type 3
Among Related
REUSE--82
Removing Removing Type 3Type 3 Couplings in HTSS Couplings in HTSSWhich Changes Make Sense?Which Changes Make Sense?
InvCont
DeliIC
Item
DeliItem
Type 3
Change InvCont to S or DeliItem to GChange InvCont to S or DeliItem to G Neither Makes Sense Against Design Intent!
Move Coupling Dst. to General ClassMove 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 ClassMove 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 ImplementationDetailed Evaluation of Implementation Note: Maintain Application SemanticsNote: Maintain Application Semantics
Type 1
Type 7
REUSE--83
Extended Guidelines for Extended Guidelines for Type 2Type 2 Couplings Couplings
Move Coupling Src. to Specific ClassMove Coupling Src. to Specific Classor Change Src. To a Specific Classor Change Src. To a Specific Class Type 2 to Type 6 May Introduce Couplings from
General Classes to Specific Src. Move Src. and Dst. to Specific ClassesMove 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 ClassMove Coupling Dst. to Specific Class
or Change Dst. To a Specific Classor Change Dst. To a Specific Class Follow Type 4 Guidelines
Change to Related/Change to Related/Type 1Type 1/Design /Design Impact Must be Evaluated!Impact Must be Evaluated!
Detailed Evaluation of ImplementationDetailed Evaluation of Implementation
G
S
G
S
Type 2
Non-Related
REUSE--84
Extended Guidelines for Extended Guidelines for Type 4Type 4 Couplings Couplings
Move Coupling Dst. to General ClassMove Coupling Dst. to General Classor Change Dst. To a General Classor Change Dst. To a General Class Type 4 to Type 2 - No Help
Move Coupling Src. to Specific ClassMove Coupling Src. to Specific Classor Change Src. To a Specific Classor Change Src. To a Specific Class Type 4 to Type 8 May Introduce Couplings from
General Classes to Specific Src. Change to Related/Follow Change to Related/Follow Type 3Type 3 Detailed Evaluation of ImplementationDetailed Evaluation of Implementation
G
S
G
S
Type 4
Non-Related
REUSE--85
Summary on Extended GuidelinesSummary on Extended Guidelines Total Alternatives for Removing “Bad” Couplings: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 Changing from G to S or Movement of Coupling Potential to Impact: Potential to Impact: Couplings to Source Couplings from Destination
Result: Movement May Result: Movement May DecreaseDecrease Reuse Potential! Reuse Potential! Two-Fold Solution: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
REUSE--86
Utilizing Reuse MethodologyUtilizing Reuse MethodologyEvaluate Evolving Design/ImplementationEvaluate Evolving Design/Implementation Constructing New ApplicationsConstructing New Applications
Software Design Proceeds in Stages Today’s Norm: Incremental Development and
Rapid Prototyping General/Specific Classes/Related ComponentsGeneral/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 Video Rental System Test-Bed
REUSE--87
Utilizing Reuse MethodologyUtilizing Reuse Methodology Investigate Reusability of Legacy Code Investigate Reusability of Legacy Code
Reusability of Legacy CodeReusability of Legacy Code Examine Legacy Code in Detail Talk/Contact Domain Experts with Corporate
Knowledge of Code General/Specific Classes/Related ComponentsGeneral/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 FinancialFrameSee Web Site for Example in FinancialFrame
REUSE--88
The Video Rental System (VRS)The Video Rental System (VRS) VRS is for On-Line (Browser) Rental TapesVRS 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:Goals: Demonstrate General/Specific/Related Ideas Incorporate/Reuse Design in Future System Study Effectiveness Approach in Identifying and
Removing Non-Reusable Dependencies
REUSE--89
General and Specific Classes in VRS-1General 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--90
DRE and VRS-1DRE and VRS-1Tracking Incremental VersionsTracking Incremental Versions
Type Metr I II III IV V VI VIIGood CC1 8 54 79 109 166 167 193Bad CC2 0 0 0 0 0 0 0Bad CC3 6 0 0 0 4 4 0Bad CC4 0 0 1 1 0 0 0Impr CC5 0 19 28 39 94 92 75Impr CC6 0 6 6 18 28 30 25Okay CC7 0 0 0 0 0 5 0Okay CC8 0 0 11 11 21 22 26
LOC 410 1386 2088 2695 3784 3824 3867
REUSE--91
Final General/Specific Classes in VRS-2Final General/Specific Classes in VRS-2and Some Related Characterizationsand 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--92
DRE and VRS-2DRE and VRS-2Tracking Incremental VersionsTracking Incremental Versions
Type Metr I II III IVGood CC1 17 28 26 26Bad CC2 0 0 0 0Bad CC3 0 0 1 0Bad CC4 0 0 0 0Impr CC5 0 0 2 2Impr CC6 0 0 3 4Okay CC7 0 4 3 3Okay CC8 0 0 0 0
G/SLOCCls.
175/1
325/1
307/6
307/6
REUSE--93
One Type 3 Coupling: G to S DependencyOne 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--94
Resolving Type 3 G to S DependencyResolving 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()
REUSE--95
Utilizing Reuse MethodologyUtilizing Reuse Methodology Investigate Reusability of Legacy Code Investigate Reusability of Legacy Code
Reusability of Legacy CodeReusability of Legacy Code Examine Legacy Code in Detail Talk/Contact Domain Experts with Corporate
Knowledge of Code General/Specific Classes/Related ComponentsGeneral/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-BedFinancialFrame as a Test-Bed
REUSE--96
The FinancialFrame ApplicationThe FinancialFrame ApplicationInitial Assumptions on G/S and RelatedInitial Assumptions on G/S and Related
...
)(G0YieldModel
DiscountIndexBond )(G1 )(G1Bill )(G1
Bond )(G0
FinancialFrame Composed of Multiple Algorithm FinancialFrame Composed of Multiple Algorithm FamilitesFamilites
All Root Classes are G(0) with Subclasses G(1)All Root Classes are G(0) with Subclasses G(1) All Other Classes are G(0)All Other Classes are G(0) Use Actual Couplings in Code to Define Related Use Actual Couplings in Code to Define Related
CharacterizationCharacterization
REUSE--97
Evaluation of FinancialFrameEvaluation of FinancialFramePossible ScenariosPossible Scenarios
Dependencies from to ClassesDependencies 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)
0G 1G
...
)(G0YieldModel
DiscountIndexBond )(G1 )(G1Bill )(G1
Bond )(G0
REUSE--98
Revising FinancialFrame ApplicationRevising FinancialFrame Application
...
)(G0YieldModel
DiscountIndexBond )(G1 )(G1Bill )(G1
Bond )(G1 R
Bond is Changed from to Bond is Changed from to A Component Consisting of Bond, IndexBond, A Component Consisting of Bond, IndexBond,
and YieldModel is Definedand YieldModel is Defined When Bond Reused, So Must IndexBond and When Bond Reused, So Must IndexBond and
YieldModel - Other Classes Not NeededYieldModel - Other Classes Not Needed However, YieldModel can Be Reused in IsolationHowever, YieldModel can Be Reused in Isolation Thus, Modifications to Component Only Affect Thus, Modifications to Component Only Affect
Reusers of ComponentReusers of Component
0G 1G
REUSE--99
Evaluation of FinancialFrameEvaluation of FinancialFramePossible ScenariosPossible Scenarios
Dependencies from to Classes 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)
1G 1G
...
)(G0YieldModel
DiscountIndexBond )(G1 )(G1Bill )(G1
Bond )(G1 R
1G
REUSE--100
Reusability of FinancialFrame Reusability of FinancialFrame ComponentsComponents
Undesirable Couplings Identified via Either Undesirable Couplings Identified via Either Scenario can be Removed to Increase ReuseScenario can be Removed to Increase Reuse
Results of Such Actions w.r.t. FinancialFrameResults of Such Actions w.r.t. FinancialFrame Classes can be Reused with Classes When a Class is Modified, Only Users of
Particular Component(s) are NotifiedBad Coupling No Longer Present!Bad Coupling No Longer Present!
Each Component Can be Reused “As is” Classes Outside of Component No Longer
Needed Cannot Illustrate Due to Proprietary SoftwareCannot Illustrate Due to Proprietary Software Similar Changes to VRS-2 OccurSimilar Changes to VRS-2 Occur
1G1G
0G
REUSE--101
Design Reusability Evaluation (DRE) ToolDesign Reusability Evaluation (DRE) Tool What is DRE?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 WaysDRE can be Utilized in Different Ways
Evaluate Evolving Design/Implementation Investigate the Reusability of Legacy Code
REUSE--102
The DRE Tool FamilyThe DRE Tool Family
Standard DRE (SDRE)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)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)Together DRE (TDRE) Integrated via Plug-Ins into UML Tool
REUSE--103
Utilizing Reuse MethodologyUtilizing Reuse MethodologyEvaluate Evolving Design/ImplementationEvaluate Evolving Design/Implementation Constructing New ApplicationsConstructing New Applications
Software Design Proceeds in Stages Today’s Norm: Incremental Development and
Rapid Prototyping General/Specific Classes/Related ComponentsGeneral/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 Video Rental System Test-Bed
REUSE--104
Utilizing Reuse MethodologyUtilizing Reuse Methodology Investigate Reusability of Legacy Code Investigate Reusability of Legacy Code
Reusability of Legacy CodeReusability of Legacy Code Examine Legacy Code in Detail Talk/Contact Domain Experts with Corporate
Knowledge of Code General/Specific Classes/Related ComponentsGeneral/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-BedFinancialFrame as a Test-Bed
REUSE--105
SDRE - Main Application Window SDRE - Main Application Window
REUSE--106
SDRE - SDRE - Main Window – Setting Main Window – Setting GeneralityGenerality
REUSE--107
SDRE - SDRE - Main Window – Setting RelationsMain Window – Setting Relations
REUSE--108
SDRE - SDRE - Main Window – Choosing Main Window – Choosing Simulation OptionsSimulation Options
REUSE--109
SDRE - Help SubsystemSDRE - Help Subsystem
HTML-based Documents Describe Tool & TheoryHTML-based Documents Describe Tool & Theory
REUSE--110
SDRE - Graphical RepresentationSDRE - Graphical RepresentationGenerality Set for DesignGenerality Set for Design
REUSE--111
SDRE - Graphical RepresentationSDRE - Graphical RepresentationSetting Related ClassesSetting Related Classes
REUSE--112
SDRE - Graphical Icons for ClassesSDRE - Graphical Icons for Classes
Relative Edge Base
Inheritance Edge BaseGenerality Base
Base Rectangle
Source File Name
Select Base
Inheritance Edge
Related Edge
REUSE--113
SDRE - Graphical RepresentationSDRE - Graphical Representation
REUSE--114
SDRE - SDRE - Editing Source Code Editing Source Code Enabled When Doubling ClickingEnabled When Doubling Clicking
REUSE--115
SDRE - SDRE - Editing Source CodeEditing Source CodeEditor Appears with Line HighlightedEditor Appears with Line Highlighted
REUSE--116
SDRE - SDRE - Editing Source CodeEditing Source CodeSource Editor FeaturesSource Editor Features
REUSE--117
Collaborative DRE (CDRE)Collaborative DRE (CDRE)
CDRE PurposesCDRE 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-CDRE is Intended to Bring SDRE into a Real-
World Computing EnvironmentWorld Computing Environment
REUSE--118
CDRE – DRE ClientCDRE – DRE Client
REUSE--119
CDRE – Client LoginCDRE – Client Login
REUSE--120
CDRE – Project SelectionCDRE – Project Selection
REUSE--121
CDRE – Remote Class SelectionCDRE – Remote Class Selection
REUSE--122
Together DRE (TDRE)Together DRE (TDRE)
Integrating DRE into TCCIntegrating 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 Single Integrated Design/Development
Environment with Reusability AssessmentEnvironment with Reusability Assessment Leverage TCC to Support ReusabilityLeverage 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
REUSE--123
Reusability in Together CCReusability in Together CC
REUSE--124
Reusability in Together CCReusability in Together CC
REUSE--125
Reusability in Together CCReusability in Together CC
REUSE--126
Reusability in Together CCReusability in Together CC
REUSE--127
Towards the Formalization of a Towards the Formalization of a Reusability Framework for RefactoringReusability Framework for Refactoring
Formal Definitions of Reuse Model to Allow Formal Definitions of Reuse Model to Allow Automatic and Algorithmic Analysis of CouplingsAutomatic and Algorithmic Analysis of Couplings Paper by Cabellero and Demurjian at ICSR-7 OO Application Model Reuse Framework
Coupling Type Transition MatrixCoupling 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--128
GoalGoal
Increase Reuse Potential by Understanding Increase Reuse Potential by Understanding Classes, Components, and their Role within Classes, Components, and their Role within ApplicationsApplications 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
REUSE--129
Model of OO ApplicationModel of OO Application
Definition 1: Object-Oriented Application Definition 1: Object-Oriented Application SS is is Modeled As a 3-tuple (Modeled As a 3-tuple (CC, , ii, , mm)) C is the Set of Classes, Where Each
Class Cp Contains a Set Cpm of Methods
Mim Such that Each Method Mi Belongs to Only One Class
I is the Set of Pair-wise Inheritance Relations of Classes in C
M is the Set of Pair-wise Coupling Among Methods
REUSE--130
Model - Pair-wise CouplingsModel - Pair-wise Couplings
Definition 2: Pair-wise CouplingDefinition 2: Pair-wise Coupling Two classes Cp and Cq are Pair-Wise Coupled
when there is at Least One Method miCpM that
Invokes a Method mjCqM .
Cp
m4mim9
m1
m20
Cq
mj
m18m9
m5
REUSE--131
Basis of Reuse FrameworkBasis of Reuse Framework
Class ReusabilityClass 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 ClassesRelations Among Classes
Grouping of Classes that Are Expected to Be Reused Together in Future Applications
REUSE--132
Class ReusabilityClass Reusability
General ClassesGeneral Classes Expected to be Reused in Future Applications Abstract Classes/Root Classes/Non-Leaf
Classes in Inheritance Hierarchies Domain Independent/Domain Specific
Specific ClassesSpecific Classes Only Applicable in Current Applications Unlikely to be Reused in Future Applications Application Specific
Purpose: Determine Classes with Highest Reuse Purpose: Determine Classes with Highest Reuse Potential for Organization’s Future SystemsPotential for Organization’s Future Systems
REUSE--133
Model - Class ReusabilityModel - Class Reusability
Definition 3: The Definition 3: The Reusability LevelReusability Level of Class of Class CCii is is Denoted by Denoted by GGccii
Gci=0 Ci is the Most General Class in the Application
Gci=N (N>0) Ci is the Most Specific Class in the Application
Lower N, More General Class Class Generality VectorClass Generality Vector
Cn
Ci
C
G
G
G
G
1
REUSE--134
Model - Relations Among ClassesModel - Relations Among Classes
Related Classes Promote Reuse, Since They are Related Classes Promote Reuse, Since They are Expected to be Reused Together Expected to be Reused Together Class Ci is Related to Class Cj if Expected to be
Reused Together in Future Systems Class Ci Related to Class Cj is Subjectively
Assigned by Software Engineer (Producer) Related Classes Assist in Reusability AssessmentRelated Classes Assist in Reusability Assessment
REUSE--135
Quantifying Reuse PropertiesQuantifying Reuse Properties
Property 1: Generality and InheritanceProperty 1: Generality and Inheritance Parent of a Class is Equally General or More
General than is Direct Children Property 2: Generality and Related ClassesProperty 2: Generality and Related Classes
Reuse Level of Class is Equal to the Reuse Level of the Least Reusable Coupled Class
Property 3: Extraneous FunctionalityProperty 3: Extraneous Functionality Classes that Don’t Contribute to Functionality
of Component have Negative Impact on Reuse Property 4: Generality and Unrelated ClassesProperty 4: Generality and Unrelated Classes
Couplings Between Unrelated Classes Hinder Reuse
REUSE--136
Dependencies Among ClassesDependencies Among Classes
Object Inclusion: Object Inclusion: Class Contains a Instance of Class Contains a Instance of Another ObjectAnother Object
Attribute Definition: Attribute Definition: Class Contains Attribute that Class Contains Attribute that is the Type of Another Objectis the Type of Another Object
Method Invocation: Method Invocation: Class Invokes a Method Class Invokes a Method Defined on Another ObjectDefined on Another Object
GoalsGoals 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--137
Dependencies: Related ClassesDependencies: Related Classes Remember, G/S are Subjectively Assigned by Remember, G/S are Subjectively Assigned by
Software DesignerSoftware Designer The Two G classes are Related The Two G classes are Related Related Classes are Intended to be Reused Related Classes are Intended to be Reused
TogetherTogether
Good (Type 1)G
S
G
S
Okay (Type 5)
Okay (Type 7)
Bad (Type 3)
REUSE--138
Dependencies: Non-Related ClassesDependencies: Non-Related Classes G/S are Subjectively Assigned by DesignerG/S are Subjectively Assigned by Designer The Two G Classes are Not RelatedThe Two G Classes are Not Related Non-Related Classes are Non-Related Classes are NOT NOT Intended to be Intended to be
Reused TogetherReused Together
Okay (Type 6)
Okay (Type 8)
G
S
G
S
Bad (Type 2)
Bad (Type 4)
REUSE--139
Sample Actions to Improve ReusabilitySample Actions to Improve Reusability
Coupling Among Related Among Unrelated
G G Type (1)Good for Reuse
Type (2)Bad for ReuseMove Src./Dst. to Specific
G S Type (3)Bad for ReuseMove Dst. to General
Type (4)Bad for ReuseMove Src. To Specific
S G Type (5)Can Improve if MoveSrc. to General
Type (6)No Impact on Reuse
S S Type (7) - Can Improveif Move Src./Dst. to Gen.
Type (8)No Impact on Reuse
REUSE--140
Core Guidelines to Move Couplings to Core Guidelines to Move Couplings to Increase Reuse PotentialIncrease Reuse Potential
G
S
G
S
Type 2
Type 8
G
S
G
S
Type 4
Type 8
G
S
G
SType 5
Type 1 G
S
G
SType 7
Type 1
Type 3G
S
G
SType 7
Type 1G
S
G
SType 3
REUSE--141
Coupling Type TransitionsCoupling Type Transitions
Defines Loss, Gain, or Steady State Between the Defines Loss, Gain, or Steady State Between the Various Coupling TypesVarious Coupling Types
For Example, For Example, Going from a GS to a GG Coupling Type
for Related Classes is a +1 Going from a GG to a GS Coupling Type
for Related Classes is a -1 Going from a SG to a SS Coupling Type
for Related Classes is a 0 Define a Matrix for all Transitions Among the Define a Matrix for all Transitions Among the
Eight Coupling Types in One StepEight Coupling Types in One Step Distinguish Related from Unrelated TransitionsDistinguish Related from Unrelated Transitions
REUSE--142
Coupling TransitionsCoupling Transitions
Related Classes
Unrelated Classes
REUSE--143
Reuse Improvement FactorReuse Improvement Factor
Metric of the Loss, Gain, or Steady State Between Metric of the Loss, Gain, or Steady State Between the Various Coupling Types After the Refactoringthe Various Coupling Types After the Refactoring
Defined byDefined by
where where is the Matrix for all Transitions Among the is the Matrix for all Transitions Among the Eight Coupling Types in One StepEight 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
n
i
n
jtt ijij
0 0]~][[
REUSE--144
Motivation of Refactoring AlgorithmMotivation of Refactoring Algorithm
Goal: Improve the Reuse Potential of an Goal: Improve the Reuse Potential of an ApplicationApplication
Formalizes Guidelines to Increase Reusability Formalizes Guidelines to Increase Reusability Introduced by M. Price and S. DemurjianIntroduced by M. Price and S. Demurjian
Basic IdeaBasic 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--145
Refactoring AlgorithmRefactoring Algorithm
Step 1: Step 1: Identify Reuse Potential - Mark GeneralitiesIdentify Reuse Potential - Mark GeneralitiesStep 2: Step 2: Calculate CouplingsCalculate CouplingsStep 3: Step 3: Identify Related ClassesIdentify Related ClassesStep 4: Step 4: Determine Coupling TypesDetermine Coupling TypesStep 5: Step 5: Identify Undesirable CouplingsIdentify Undesirable CouplingsStep 6: Step 6: Refactor: Move Source or Destination Method, Refactor: Move Source or Destination Method,
Change Reuse Level, Related to UnrelatedChange Reuse Level, Related to UnrelatedStep 7: Step 7: Recalculate Reuse Improvement FactorRecalculate Reuse Improvement Factor
Step 8: Step 8: If Reuse Factor <= 0 Goto If Reuse Factor <= 0 Goto Step 6Step 6 Else Goto Else Goto Step Step 55 or Terminate Based on Condition or Terminate Based on Condition
n
i
n
jtt ijij
0 0]~][[
REUSE--146
Example - AssumptionsExample - Assumptions
Assume Classes: CAssume Classes: C11, C, C22, C, C33, C, C44, C, C55, C, C66, C, C77 Methods: mMethods: m11, m, m22, m, m33, m, m44, m, m55, m, m66, m, m77, m, m88 Dependencies Among Methods (Couplings) Dependencies Among Methods (Couplings)
Shown with ArrowsShown with Arrows
REUSE--147
Example - Generality and RelatedExample - Generality and RelatedSteps 1, 2, 3 of AlgorithmSteps 1, 2, 3 of Algorithm
G G G G
S
SS
Establish Class ReusabilityEstablish Class Reusability C1, C2, C4, C6 General C3, C5, C7 Specific
Calculate CouplingsCalculate Couplings Assume all Classes are Related Classes to One Assume all Classes are Related Classes to One
AnotherAnother
REUSE--148
G G G G
S
SS
Example - Determine Coupling TypesExample - Determine Coupling TypesStep 4 of AlgorithmStep 4 of Algorithm
REUSE--149
G G G G
S
SS
Example - Identify Undesirable CouplingsExample - Identify Undesirable Couplings Step 5 of Algorithm Step 5 of Algorithm
REUSE--150
Example - Refactor the ApplicationExample - Refactor the Application Step 6 of Algorithm Step 6 of Algorithm
For (mFor (m33,m,m55) Try to Move Source Method Down) Try to Move Source Method Down
m3
0000000000000000000000000500000030300010000700000000000000000300
~T 011 No Improvement!
REUSE--151
Example - Refactor the ApplicationExample - Refactor the Application Step 6 of Algorithm Step 6 of Algorithm
For (mFor (m44,m,m66) Try to Move Source Method Down) Try to Move Source Method Down
m4
0000000000000000000000000500000070700050000300000000000000000100
~T 1111 Commit the ChangesSet T=T
~
REUSE--152
Example - Refactor the ApplicationExample - Refactor the Application Step 6 of Algorithm Step 6 of Algorithm
For (mFor (m55,m,m77) try to Move Source Method Down) try to Move Source Method Down
m4
0000000000000000000000000100000070700050000100000000000000000100
~T 211
m5
Commit the ChangesSet T=T
~
REUSE--153
Example - Refactored Class DiagramExample - Refactored Class Diagram
G G G G
SS
S
REUSE--154
Reusability and UMLReusability and UML Investigation of Our Reuse Model and Framework Investigation of Our Reuse Model and Framework
at Design Level via UMLat Design Level via UML Establishing Generality and Related in Use-
Case and Class Diagrams Counting and Tracking Dependencies in
Behavior Modeling and Component Diagrams Key QuestionsKey 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)Build and Extend the Formal Model (Caballero)
REUSE--155
Revisiting Reuse PropertiesRevisiting Reuse Properties
Property 1: Generality and InheritanceProperty 1: Generality and Inheritance Parent of a Class is Equally General or More
General than is Direct Children Property 2: Generality and Related ClassesProperty 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 ClassesProperty 3: Generality and Unrelated Classes Couplings Between Unrelated Classes Hinder
Reuse
REUSE--156
Reuse Definition, Assessment, and Reuse Definition, Assessment, and Analysis in UMLAnalysis in UML
Examination of Reuse in …Examination of Reuse in … Use Case Diagrams Class Diagrams Behavior Modeling Diagrams Component Diagrams
Reuse Improvement During DesignReuse Improvement During Design Transition from Design into DevelopmentTransition from Design into Development Consistency of Approach with Existing Reuse Consistency of Approach with Existing Reuse
Model and Formal Refactoring GuidelinesModel and Formal Refactoring Guidelines Definite Additional Properties (see Previous Slide)Definite Additional Properties (see Previous Slide) Introduce Introduce Refactoring Guidelines Refactoring Guidelines that Enforce the that Enforce the
Properties of Reuse for UML DiagramsProperties of Reuse for UML Diagrams
REUSE--157
Reuse Definition, Assessment, and Reuse Definition, Assessment, and Analysis in UMLAnalysis in UML
Examination of Reuse in …Examination of Reuse in … Use Case Diagrams Class Diagrams Behavior Modeling Diagrams Component Diagrams
Reuse Improvement During DesignReuse Improvement During Design Transition from Design into DevelopmentTransition from Design into Development Consistency of Approach with Existing Reuse Consistency of Approach with Existing Reuse
Model and Formal Refactoring GuidelinesModel and Formal Refactoring Guidelines Definite Additional Properties (see Previous Slide)Definite Additional Properties (see Previous Slide) Introduce Introduce Refactoring Guidelines Refactoring Guidelines that Enforce the that Enforce the
Properties of Reuse for UML DiagramsProperties of Reuse for UML Diagrams
REUSE--158
Use Cases with GeneralitiesUse Cases with Generalities Application has Three Application has Three
Systems Systems Each System with One or Each System with One or
More Use CaseMore Use Case Each Use Case has Each Use Case has
Generality LevelGenerality Level Relationships Among Relationships Among
Use Cases are:Use Cases are: Extend Include Generalize
Generalities Must be Generalities Must be Consistent within Consistent within Systems and Between Systems and Between UCs Given RelationshipsUCs Given Relationships
REUSE--159
Use Cases with Use Cases with Include, Extend, and InheritanceInclude, Extend, and Inheritance
Dependencies Among Use CasesDependencies Among Use Cases Dependencies are Transitive w.r.t. GeneralitiesDependencies are Transitive w.r.t. Generalities
REUSE--160
Properties for Use CasesProperties for Use Cases
Property 4: Property 4: UCUCAA extends UC extends UCBB means UC means UCAA adds adds behavior to UCbehavior to UCBB, so UC, so UCAA is at most as general as UC is at most as general as UCBB or Gor GUC-B UC-B G GUC-AUC-A
Property 5: Property 5: UCUCAA includes UC includes UCBB is a relation of the is a relation of the
behavior sequence of supplier UCbehavior sequence of supplier UCBB to the interaction to the interaction
sequence UCsequence UCAA. Thus, UC. Thus, UCAA is at most as general as is at most as general as
UCUCBB or G or GUC-B UC-B G GUC-AUC-A.. Property 6: Property 6: UCUCAA generalizes UC generalizes UCBB relates child UC relates child UCBB to to
parent UCparent UCAA, meaning that UC, meaning that UCBB is at most as general as is at most as general as UCUCAA or G or GUC-AUC-A G GUC-BUC-B..
REUSE--161
Corresponding Refactoring GuidelinesCorresponding Refactoring Guidelines
RG1 or RG2 to Enforce Property 4 or Property 5:RG1 or RG2 to Enforce Property 4 or Property 5: The refactoring rule is: If GUC-B > GUC-A then
refactor by making UCB more general (or UCA more specific) so GUC-B GUC-A or by removing the extend/include.
RG3 to Enforce Property 6:RG3 to Enforce Property 6: The refactoring rule is: If GUC-A > GUC-B then
refactor by making UCA more general (or UCA more specific) so GUC-A GUC-B or or by removing the generalization.
REUSE--162
Identifying ProblemsIdentifying ProblemsRG3 for Pay CashRG3 for Pay Cash
RG2 for Place Order: to G2 or Remove <include>RG2 for Place Order: to G2 or Remove <include> RG3 for Pay Cash: to G1 or Arrange Payment to RG3 for Pay Cash: to G1 or Arrange Payment to
G0 or Remove <generalization>G0 or Remove <generalization>
REUSE--163
UML Reuse and Class DiagramsUML Reuse and Class Diagrams Definition 3:Definition 3:
UCA is related to ℭA = {C1 , C2 , …, Cn } for some n, if UCA relies on ℭA for functionality.
Property 7: UCs and Classes - GeneralityProperty 7: UCs and Classes - Generality Suppose UCA has ℭA = {C1 , C2 , …, Cn }. Then, the generality
of UCA must be as specific as the most specific class in ℭA , and may be more specific, i.e., GUC-A = max{generality Ci ℭA }.
RG4 to Enforce Property 7RG4 to Enforce Property 7 The refactoring rule is: generality change of UCA or one or
more Ci in ℭA until GUC-A = max{generality Ci ℭA }, or the removal of all classes in ℭA that cause the GUC-A = max{generality Ci ℭA } to be violated.
REUSE--164
Classes and Generality Levels Classes and Generality Levels
CPlace Order ={Order Container, Order, ItemDB } COrder Product = {Item }COrder Computer ={Computers } C- Order Car = {Cars } CRequest Catalog ={Catalog }CSupply Customer Data = {Customer, DB Access } CArrange Payment = {Payment }
REUSE--165
UML Reuse and Class DiagramsUML Reuse and Class Diagrams
Property 8: UCs and Classes - RelatedProperty 8: UCs and Classes - Related Suppose that UCA is related to ℭA and UCB is
related to ℭB . If UCA is related to UCB (extend, include, or generalize), then there has to be at least one transitive relation chain from one Ci ℭA to one Cj ℭB.
RG5 to Enforce Property 8RG5 to Enforce Property 8 The refactoring rule is: Add one or more
dependencies between class(es) Ci ℭA and class(es) Cj ℭB, or remove the relation between UCA and UCB
REUSE--166
UML Reuse and Class DiagramsUML Reuse and Class Diagrams Property 9: UCs to UCs - RelatedProperty 9: UCs to UCs - Related
Suppose that UCA is related to ℭA and UCB is related to ℭB , and that UCA is not related to UCB (there is not an extend, include, or generalize). Then, if at least one Ci ℭA is directly related (meaning not by transitive relation chain) to at least one Cj ℭB, there must be a refactoring to correct the problem.
RG6 to Enforce Property 9RG6 to Enforce Property 9 The refactoring rule is: make UCA related to UCB or
remove all dependencies between all Ci ℭA and all Cj ℭB.
REUSE--167
UML Reuse and Class DiagramsUML Reuse and Class Diagrams Property 10: UCs and Classes - RelatedProperty 10: UCs and Classes - Related
Suppose that UCA is related to ℭA. Then for all Ci ℭA , if there is a transitive relation chain from Ci to some Cj ℭA, then UCA must also be related to Cj in some manner. UCA can be either related directly to Cj or it can be related to some UCB, to which Cj is related
RG7 to Enforce Property 10RG7 to Enforce Property 10 The refactoring rule is: Ci ℭA related to some Cj ℭA include Cj in ℭA (ℭA= ℭA Cj), or relate UCA to some UCB where Cj ℭB, or unrelate UCA to Ci (ℭA= ℭA - Cj).
REUSE--168
Refactored UC Diagram Refactored UC Diagram from Earlier Slide from Earlier Slide
REUSE--169
UML Reuse and Behavior DiagramsUML Reuse and Behavior Diagrams
Sequence and Collaboration Diagrams Can Sequence and Collaboration Diagrams Can Also Impact on Reuse - Why?Also Impact on Reuse - Why? Both Alter Dependencies Introduce/Remove Associations
For Example: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--170
UML Reuse and Component DiagramsUML Reuse and Component Diagrams
Definitions for UML ComponentsDefinitions 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 GuidelinesAccompanying 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 See Section 3.4 of Paper for Further Details
REUSE--171
Modifications to Together CCModifications to Together CC
Leverage Open APIs and Plug In Structure to Leverage Open APIs and Plug In Structure to Incorporate Reuse Model for UML into TCCIncorporate Reuse Model for UML into TCC
Multi-Phase ApproachMulti-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 ModificationsBriefly, we’ll Review Modifications Please See Web Site for Full DetailsPlease See Web Site for Full Details
REUSE--172
Setting Project OptionsSetting Project Options
REUSE--173
UC: Generality and RelatedUC: Generality and Related
REUSE--174
Classes: Generality and Related Classes: Generality and Related
REUSE--175
Components and FacadesComponents and Facades
REUSE--176
Running DRE and MetricsRunning DRE and Metrics
REUSE--177
Analyzing Reuse and RefactoringAnalyzing Reuse and Refactoring Affected ElementsAffected Elements: Elements affected by warning. : Elements affected by warning. Description: Provides a description of the warning Refactoring Guideline: One or more refactoring
guidelines for the currently selected warning
REUSE--178
TCC: DRE-UML WarningsTCC: 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--179
ConclusionsConclusions
Comprehensive Reusability Model and EvaluationComprehensive 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 VerificationMethodology 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--180
Future Work - Reusability - SummaryFuture Work - Reusability - Summary
Possible Short/Long-Term ResearchPossible 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
REUSE--181
Genetic Algorithm and ReuseGenetic Algorithm and Reuse
Towards Towards Guided Software Reusability AssessmentGuided Software Reusability Assessment Multi-Step Iterative Process:Multi-Step Iterative Process:
Determine Set of Assumptions Regarding Generality Levels of Generality that are Required Related Implied by Dependencies or Set by User
Key Issue is to Define Constraints that Will Underlie the GA Fitness Function
Run the Genetic Algorithm on Code for Fixed Population and Number of Generations
Evaluation of Results - Potential to Rerun with Changed Assumptions, Population, Generations
Converge Towards “Reasonable” Marking
REUSE--182
Future: Formal Reuse ModelFuture: Formal Reuse Model
Future Work Future Work Exploring Weightings (+2, +3, -3, etc.) for
Transitions Among Coupling Types Explore and Refine the Reuse ModelExplore and Refine the Reuse Model
Theoretical Verification of Reuse Model Use of GA to Obtain “Near” Optimal Marking
Practical PerspectivePractical Perspective Integrating Metric and Model in SDRE Testing with “Real” Examples and Prior
Examples