A Reuse Definition, Assessment, and Analysis Framework for UML †

This chapter examines a formal framework for reusability assessment of developmenttime components and classes via metrics, refactoring guidelines, and algorithms. It argues that software engineers seeking to improve design reusability stand to benefit from tools that precisely measure the potential and actual reuse of software artifacts to achieve domain-specific reuse for an organization’s current and future products. The authors consider the reuse definition, assessment, and analysis of a UML design prior to the existence of source code, and include dependency tracking for use case and class diagrams in support of reusability analysis and refactoring for UML. The integration of these extensions into the UML tool Together Control Center to support reusability measurement from design to development is also considered. IDEA GROUP PUBLISHING This chapter appears in the book, Advances in UML and XML-Based Software Evolution edited by Hongji Yang © 2005, Idea Group Inc. 701 E. Chocolate Avenue, Suite 200, Hershey PA 17033-1240, USA Tel: 717/533-8845; Fax 717/533-8661; URL-http://www.idea-group.com ITB11246


Introduction
Reusable software components have been touted for over 30 years [5], but their benefits (reduce risk, limit costs, improve time to market, increase quality, support rapid prototyping, etc.) [3,4,12,14,16] are difficult to prove in practice. Today's component-based programming languages and their robust APIs support actual reuse of standard components (e.g., GUI, communication, database, etc.), but are less successful with future reusability or reuse potential of components [15], a target of domainand-organization-specific reuse [6,7]. Domain-andorganization-specific reuse represents a long-term investment in reuse [13] to support entire product families. Towards that end, there must be reuse guidelines, standards, models, and metrics [8].
To support reuse potential, we have developed an integrated reusability metric, framework, and tool [9][10][11] with formal underpinnings [1] that is currently targeted at reusability definition, assessment, and analysis of software (code). In this work, we provide techniques that mark components/classes to indicate the reusability level, which can range from the general (able to solve problems in multiple contexts) to the specific (single use -will not be reused). For example, in a retailing application, a supplier would have a general Item (reusable in many business contexts), an auto-parts supplier would have a less general AutomotiveItem (reusable in that context only), and individual retailers would have a specific WalmartItem (useable only by a specific company). Given a marking of an application's classes/components, our reuse metrics can objectively classify and measure dependencies (couplings) within and among classes/components, identifying couplings that promote and hinder future reuse, which can be input to an algorithm that automates reusability assessment and refactoring [1]. This framework [9][10][11] is supported by the Design Reusability Evaluation (DRE) tool (see http://www.engr.uconn.edu/˜steve/DRE/dre.html).
However, while our current work has been applied at development time (code exists) or on existing software repositories to assess reuse potential, reuse must be treated as a first class citizen and be considered at early and all stages of the design, development, and maintenance. Towards that end, in this paper, we investigate reusability definition, assessment, and analysis for the unified modeling language (UML), focusing on using UML via a tool (e.g., Rational Rose, Together Control Center, etc.) prior to the development of software (code). Thus, this work concentrates on reusing a "design model" and monitoring reuse as the model evolves. Specifically, we investigate the ability to design "reusable" UML components, allowing these components to be easily incorporated into other products of a family (i.e., domain-andorganization specific reuse), while simultaneously tracking reuse assessments made at the design level into the development and maintenance stages. As in our prior work, we provide quantitative metrics/techniques that objectively measure design-level reuse in UML, thereby providing some authoritative reasonable assurances that reuse requirements have been met.
Our approach to reusability definition, assessment, and analysis in UML focuses on use case and class diagram views. In practice, software engineers tend to start the process by defining use cases, followed by classes, and eventually the various activity views (sequence and collaboration diagrams), iterating back and forth across the various diagrams over time as the design evolves. Our approach augments marking of classes to marking of use cases with varying levels of generality, and tracking and enforcing this marking as a software engineer modifies the design. For example, as a software engineer starts with UML, and defines use cases, these use cases are marked with reuse levels that range from the general to the specific. As use cases interact with one another, and interact with new and existing classes that are defined, our proposed reuse model automatically notifies the software engineer when conflicts that hinder reuse are detected, so that they can be refactored. Further, as the design evolves, the reuse model tracks the couplings that are defined (via class, sequence, and collaboration diagrams), to track the impact on reuse of existing components, which may result in the need to refactor. To facilitate this activity and process, the reuse definition, assessment, and analysis have been integrated into a working UML tool, in our case, Together Control Center (TCC), to provide a seamless environment for design and reuse assessment.
In the remainder of this paper, Section 2 provides background on our existing reuse and refactoring framework [1,[9][10][11]. Section 3 presents the reuse definition, assessment, and analysis framework for UML, providing a set of reuse properties for UML and associated refactoring guidelines. Section 4 contains a brief discussion of our ongoing prototyping effort to integrate the UML reuse framework into TCC. Finally, Section 5 presents the conclusions, and ongoing and future research.

Background: Reuse Model
In this section, we review the component reuse framework proposed in [9,10], extended in [11], and formalized in [1], based on two characteristics: class generality assessment and relations among classes. As proposed in [9,10], a class may be marked as either general or specific. A general class is one that is expected to be reused in future applications, while a specific class is only intended for one application. For example, in a retail application, an Item class to track products is general to all retail applications, while a WalmartItem class descendant has store specific characteristics. In a later publication [11], the model was extended to accommodate levels of generality to better exploit the reuse potential of classes. This leads to: Definition 1: The generality level of a class C i is denoted by G i , where G i = 0 when C i is the most general class in the application, and G i = N (N > 0) when C i is the most specific class in the application. For example, generalities for classes range from Item (G 0 ) to DeptStoreItem (G 1 ) to DiscountStoreItem (G 2 ) to Wal-martItem (G 3 ), demonstrating four different levels.
Relations among classes is a characterization by the software engineer of classes that are expected to be reused together in a future application, e.g., an ItemCollection class (set of all Items) is related to the Item class. More often than not, related classes are coupled, leading to: Definition 2: Class C p is related to class C q if C p must use C q in all future reuse. Related classes have dependencies in the direction of the relation in the form of attribute inclusion, method invocation, object inclusion, etc.

Definition 3:
Each time any member of class C p references any member of class C q , a Coupling is said to exist from C p to C q . Couplings among unrelated classes prohibit proper reuse, while couplings among related classes may improve, hinder, or have no influence on the reuse of the classes. Class generality and relations among classes are an important part of our framework for reusability analysis, clarified by the following properties: Property 1. In an inheritance hierarchy, the parent class is equally general or more general than its children, meaning that children have at least the reusability level of the parent, plus optional specific (less general) attribute(s) and/or method(s). For example, WalmartItem is less general than its ancestor Item. Property 2. The generality level of a class is equal to the generality level of the least reusable related class. Given two classes, C p and C q with generality levels G p and G q there are two cases: C p is more specific than C q ( G p > G q ), in which case C p is the least reusable class; and C p is more general than C q ( G p < G q ). If there is a relation from C p to C q , C p may be dependent on specific features of C q that will condition the reusability of C p to situations when C q is reusable, i.e., the generality level of C p must be equal to or greater than the reusability level of C q . Property 3. Couplings between unrelated classes are undesirable and hinder reuse, since unrelated classes are not intended to be reused together in future applications. If there are dependencies among unrelated classes, the coupled classes must be brought along to the reusing application in order for the system to function properly, which contradicts the intent of not reusing the components together. Software engineers label or mark their classes with a generality level, that denotes the reuse expectancy of the class. To simplify, assume that there are only two levels of generality, G and S; if there are multiple levels, one can focus on only two levels at a time. Between these two generality levels there are four types of couplings: a G class can depend on another G class, a G class can depend on a S class, a S class can depend on a G class, and a S class can depend on another S class. These dependencies take the form of a method call, an instance variable reference, etc. As classes may also be related or unrelated, there exist fully 8 separate types of coupling [9][10][11]. Type 1. G → G among related classes is an asset to reuse, the two classes are expected to be reused together, and the objective is to increase these couplings. Type 2. G → G among unrelated classes is undesirable since the source and destination are not expected to be reused together. Refactor by moving both the source and destination to Specific descendant classes or making the classes related. Type 3. G → S among related classes is undesirable, since the General class (to be reused) depends on a class which is not expected to be reused. Refactor by moving the source to a Specific descendant or the destination to a General ancestor. Type 4. G → S among unrelated classes is undesirable since the source is expected to be reused while the destination is not. Refactor by moving the source to a Specific descendant class. Type 5. S → G among related classes does not hinder reuse since the source of the coupling is not expected to be reused at all. Refactor to improve reuse by moving the source to a General ancestor. Type 6. S → G among unrelated classes does not hinder reuse since the source of the coupling is not expected to be reused. There is no need to refactor in this case. Type 7. S → S among related classes does not hinder reuse since the source of coupling is not expected to be reused. Refactor to improve reuse if both source and destination are moved to their General ancestors. Type 8. S → S among unrelated classes represents the desired situation for couplings between unrelated classes; they need to be among the Specific classes. Given the eight different coupling types, we refactor to improve reuse, which requires the tracking of couplings to assess the impact on reuse when a coupling is moved from one class to another, e.g., a coupling transitioned from Type 3 to Type 1 moves a coupling that hinders reuse (Type 3) to one that promotes reuse (Type 1).

Reuse Definition, Assessment, and Analysis in UML
In this section, we examine reuse definition, assessment, and analysis in UML [2], from the perspective of use cases (Section 3.1), classes (Section 3.2), behavior modeling diagrams (Section 3.3), and component diagrams (Section 3.4). We concentrate on the steps that a software engineers take as they create and evolve their design, and we provide properties and associated refactoring guidelines to facilitate reuse improvement. While the presentation is sequential, clearly a software engineer cycles among the various UML diagrams during design.

Use Case Diagrams
Use case diagrams are typically made up of three different types of elements, namely actors, systems, and use cases, as shown in Figure 1. A UML system collects connected units that are organized to accomplish some purpose, e.g., the Sales system in Figure 1. From a reuse perspective, we are interested in the couplings between systems, e.g., in Figure 1, to reuse Sales, one must also use the Credit Institute Visa and the Credit Institute MC systems. Conversely, Credit Institute Visa or Credit Institute MC can be reused without reusing Sales. For our purposes, the reuse at the system level will not be supported at this time; our focus will be on understanding the reusability of the use cases so that when a use case is reused, we only reuse what is absolutely necessary for supporting that use case. Actors, as shown in Figure 1, represent a set of roles for interacting with use cases. Assigning generalities (ala Section 2) to actors is unworkable, since we cannot conclude anything on an actor's reusability depending solely upon its own level of generality. We may, however, be able to conclude that if an actor is dependent only upon general use cases, then the actor is likely to be reusable. Use cases, as given in Figure 1, provide us with the first UML construct to begin to define a reuse definition, assessment, and measurement framework for UML. In the initial stages, as a software engineer defines use cases, the generality level can be assigned in a similar fashion to classes (see Section 2 and [9-11]). The assigned generality level of a use case measures its reuse potential and allows comparison against other use cases, in an effort to track the couplings among use cases.
To assist in the discussion, recall the properties in Section 2 that delineated reuse definition requirements: Property 1: generality of a parent class vs. its child classes; Property 2: generality of a class is equal to generality of the least reusable coupled class; and Property 3: unrelated classes with dependencies between them hinder reuse. To augment these properties, we define properties that focus on the reusability requirements for UML that must be enforced by the reuse framework in order to "design" reusable UML applications. At initial design stages, with only use cases defined, the emphasis on reuse definition and analysis is on a). the assignment of generality level, and b). the impact of these assignments by the different types of relations between use cases in UML, namely <extend>, <include> and <generalization>.
Relations between use cases are transitive in the direction of the relation arrows. An exception to this is that when a use case is marked as abstract, the generalization links are followed against the arrow direction. The first link in a relation chain always sets the type of the relation to all transitive related use cases (e.g., if the first link is an <include>, all transitive related use cases are included). Transitivity of relations is important to allows the tracking of indirect dependencies that can hinder reuse.

Figure 2: Transitivity in Use Case relations
In the example in Figure 2, we have the relations: • "Place Order" includes: "Supply Customer Data", "Get Person Info", "Arrange Payment". As "Arrange Payment" is abstract it also includes "Pay Cash" and "Arrange Credit".
• "Arrange Credit" inherits from "Arrange Payment". <generalization> links are followed in the opposite direction if the use case is abstract, but only if the use case was reached by an <include> or <extend>. If not, sub-use cases of abstract use cases would be incoherently related (e.g., "Pay Cash" would be related to "Arrange Credit" Violating these properties yield bad couplings between the use cases, which must be corrected. This is facilitated by refactoring guidelines (RG) for software engineers which enumerate the possibilities available for correcting the violations. For Properties 4, 5, and 6, RG1, RG2, and RG3, respectively, are: RG1, 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 B more specific) so that G UC-A ≤ G UC-B or by removing the generalization. The use-case-to-use-case reuse assessment can utilize the refactoring guidelines for Types 1, 3, 5, and 7 couplings for related classes (see Section 2 again), which also apply to extend, include, or generalize use cases. When the generalities differ by one level, then the refactoring guidelines as given in [9] and for Types 1, 3, 5, and 7 in Section 2 apply. When the generalities differ by two or more levels, then the refactoring guidelines as given in [11] apply. The change of generality of either or both of the two use cases, may result in conflicts with other use cases that are connected to UC A and UC B via extend, include, or generalize relations. Use cases that are not related at initial design stages do not have dependencies, since they are not linked by either extend, include, or generalize. However, as we will discuss in Section 3.2, when classes are considered, the unrelated use cases that have dependencies to classes that are not related to the use case, must be checked, tracked, and corrected. Figure 3 is a use case diagram, with the generality level of each use case assigned by a software engineer. In Figure 3, the level of generality of each use case follows the name of the use case. As currently marked, use case "Order Product" violates Property 5 for <include>, by being more specific than use case "Place Order", and use case "Pay Cash" violates Property 6 for <generalize>, by being more general than "Arrange Payment".
Refactoring this design is essential for maintaining the reusability dependencies that adhere to Properties 1 to 6, in order to reuse use cases in future domain-andorganization specific applications. By utilizing RG2, "Place Order" <includes> "Order Product" can be refactored by: making the generality of "Order Product" G 1 (more general) or by making the generality of "Place Order" G 2 (more specific) or by removing the <include>. Either of these three choices is at the discretion of the software engineer. Similarly, by utilizing RG3, the generality of "Pay Cash" can be changed to G 1 , the generality of "Arrange Payment" can be changed to G 0 , or the generalization between the use cases can be deleted. For the purposes of the discussion, assume that both "Order Product" and "Pay Cash" are changed to G 1 .The prototype in Section 4.2 supports these refactoring actions.

Class Diagrams
Once the use cases have been initially defined, the software engineer can then begin to model classes. The reuse potential of class diagrams is evaluated according to our earlier metrics [9][10][11] that measure class-to-class couplings. However, this effort assumes detailed couplings (e.g., method calls, attribute inclusions, etc.) exist, which will not be true at initial stages of the design process. Rather, we assume that a software engineer is defining use cases and classes (initially by name only), assigning generality levels to use cases (Section 3.1) and classes (see Section 2 again), and establishing relations between use cases and classes, and among classes, all of which have the potential to impact reuse. Recall that classes are related to other classes if they expect to use and reuse those other classes in present implementations and future applications. In a UML design, there can be relations between use cases and classes as follows: Definition 4: A use case UC A is related to a set of classes A = {C 1 , C 2 , …, C n } for some n, if UC A relies on A for its functionality. It is left to the developer of the application to determine which classes implement the use case and belong to A .
Reusing UC A means reusing all classes in the set A . We specify the sets for each use case in the example as: Given this definition, we can now examine use case generality when a use case is related to a set of classes, assuming that both the use cases and the classes related to them have been assigned generality levels. The software engineer can then redefine the generality level of any class as part of an iterative design process. Intuitively, a class C is at least as general as any use case UC related to it, or stated another way, a use case UC is no more general than the most specific (least general) class C to which it is related, which leads to the Property 7 and guideline RG4. Property 7. Suppose that UC A is related to a set of classes A = {C 1 , C 2 , …, C n } for some 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- To enforce Property 7, the refactoring rule is: generality change of UC A or one or more C i Note that the changes that are made in this situation may impact elsewhere, and the prototype of Section 4.2 will automatically detect and alter the software designer. Figure 4 contains a class diagram with generality levels next to each class name. Note that we have also shown the various relations among the classes, but have not identified the type of each relation (e.g., dependencies, associations, generalizations), since it is not needed for our purposes. Figure 4 contains two violations of Property 7 as a result of dependencies among classes: • Use case "Place Order" is related to a more specific class, "Item DB", than itself.
• Use case "Order Car" is related to a more specific class, "Cars", than itself.
which can be refactored according to RG4 as follows: • Change "Item DB" to be more general with a level G 1 , "Place Order" to be more specific with a level of G 2 , or remove "Item DB" from "Place Order".
• Change "Cars" to be more general with a level G 1 , change "Order Car" to be more specific with a level G 3 , or remove "Cars" from "Order Car". Since changing relations between use cases and classes may also affect the generality levels elsewhere in the design, the reuse must be constantly reanalyzed. The prototype in Section 4.2 supports this by warnings and alerts.

6
In addition to Property 7, we must also track dependencies that can impact reuse among use cases that are related and unrelated, and between use cases and classes. Use-case-to-use case dependencies involves both related (expected to be reused together) and unrelated (not expected to be reused together) situations. The use-case-touse-case dependencies related situation, as given in Property 8 and RG5, assumes that there are two use cases that are related to one another, which must be mirrored by a relation at the class level.

Property 8. 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 -see Section 3.1), 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 RG5 maintains dependencies among use cases to allow their reuse in future settings.
In the use-case-to-use-case dependencies unrelated situation, given in Property 9, since the two use cases are not related, any class dependency between them requires an alert to the software engineer to correct via RG6.

Property 9. 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 , that is, there is not an extend, include, or generalize relation. Then, if at least one C i £ A is related directly (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 . The use-case-to-class dependencies situation involves a use case related to a class, which in turn is related to another class which is not in the set of the use case. To satisfy reuse requirements, a use case must be related to all other classes, both direct (in ) and inferred (via a relation). This situation is handled by Property 10/RG7.

Property 10. Suppose that UC A is related to
if there exists 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: RG7 maintains dependencies among use cases to allow their reuse in future settings.
To explore Properties 8 to 10, and RG5 to RG7, we continue our example as established in Figures 2 and 3, with the sets as given after Definition 3. There are two violations of Property 8 and 10, which can be refactored according to RG5 and RG7, and one problem with the design corrected with additional relations: • Use case "Place Order" in Figure 3 includes use case "Supply Customer Data", but there are no relations between ¡ Place Order and ¡ Supply Customer Data in Figure 3. Use RG5 to add a relation from class "Order" to class "Customer" in Figure 3.
• Use case "Place Order" is related to class "Item DB", and "Item DB" is related to class "Catalog". "Place Order" should therefore be related to "Catalog" or some use case that is related to it (like "Request Catalog"). Use RG7 to add an <extend> relation from "Place Order" and "Request Catalog" in Figure 5. Note that with this action, Property 5 is now violated; since use case "Request Catalog" extends use case "Place Order" it should be at least as specific as "Place Order". Our prototype in Section 4.2 automatically tracks these new violations.

•
The software engineer should consider relating classes from Figure 4 to use case "Pay Cash" and use case "Pay Credit" in Figure 2, as these use cases are not yet related to any classes. Add relations from use case "Pay Cash" to class "Cash Payment" and from use case "Arrange Credit" to class "Credit Payment". Refactoring using RG5 to RG7 to maintain Properties 8 to 10 is not a simple task, but requires a deep understanding of application content and semantics in order to be successful. Relations can be added or removed at will; but relations should only be changed if they make sense for the system. A reuse UML tool can correctly identify situations that require change, but the software engineer must use his/her own knowledge and experience and understanding of the domain to make appropriate changes. In the remainder of this section, we focus on the impact on the UML reuse framework as software engineers start to add details to their designs, including, attributes, member functions, associations, and inheritance. The addition of attributes and member functions provides the opportunity to identify new dependencies between classes that impact reuse. An attribute or member function argument whose type is that of another class may reveal a dependency that impacts Properties 8, 9, or 10, which would need resolution via RG5, RG6, or RG7. For example, in Figure  3, suppose an attribute "Last Payment Made" of type "Payment" is added to class "Customer", which is a new dependency. This new dependency has a direct impact on use case "Supply Customer Data", since ¡ Supply Customer Data = {Customer, DB Access } does not contain "Payment", which violates Property 10, and must be corrected by RG7. Associations and inheritance may also impact properties. For example, defining a new association or inheritance between classes can impact Properties 8, 9, or 10, in a similar fashion to the example just given for attributes. For new inheritance relations, a derived class can't be more general than its parent (Property 1).
Lastly, as the design continues to evolve with "code", the actual count of couplings between classes can begin to be more carefully tracked, which is supported in our current reuse framework [1,[9][10][11] and the design reusability evaluation (DRE) tool. Coupling counts help the software engineer make reusability-related decisions about the overall design. For example, if the coupling count for one class to another is high, and there is no relation defined between them, the engineer might want to add a relation showing that these components are intended to be used together. On the other hand, if the coupling count is low, the engineer might consider changing his design such that the classes are not dependent. As a UML design evolves towards code, the transition to the DRE tool is seamlessly handled (see Section 4.1).

Behavior Modeling
In addition to use case and class diagrams, UML provides for the modeling of behavior (state/activity diagrams) and for modeling the interactions between objects (collaboration and sequence diagrams), which are both of interest to this work since they have the potential to impact on the reuse as defined in Sections 3.1 and 3.2. Sequence and collaboration diagrams that model interactions between objects, by their very nature, have the potential to introduce dependencies that can impact Properties 8, 9, and 10. Thus, the prototype as described in Section 4.2 alerts software engineers when there is a new dependency as a result of a sequence or collaboration diagram that would violate Properties 8, 9, or 10. For example, a sequence diagram could have a new dependency via a method "Store Payment in Database" from the class "Payment" to the class "DB Access", which violates Property 10 since the class set ¡ Arrange Payment = {Payment} does not contain the class "DB Access", and must be refactored according to RG7. Likewise, if a collaboration diagram revealed a similar dependency (in fact, it could reveal the same one for the sequence diagram case), it would be necessary to refactor. Finally, at this time, we have yet to find a relevance of state/activity diagrams for reusability definition, analyses, and assessment, since there is no obvious way to link the states and activities of these diagrams to classes. Note that our work on the impact of other UML constructs on reuse is ongoing.

Component Diagrams
Component diagrams offer another opportunity to assess reuse potential. Component diagrams allow a software engineer to model components, the interfaces they implement and the dependencies between them. In general, UML components do not have to contain classes or code, but can represent physical units of a system. For our approach, we consider components as a collaboration of classes, which together provide a coherent functionality. Definition 5: A component is related to a set of classes ¡ , which implement its functionality and behavior.
As components are self-contained physical units, it should be easy to replace one component with another. To achieve this, we need to have a low coupling between components. Therefore, components should only be accessed through the interfaces they implement, or through classes that act as façades for the component.

Definition 6: Each component is assigned a set of classes
ℑ, which act as its façade and hides its implementation details.
Finally, since UML does not define relations between class-interfaces (i.e., code-based interfaces or abstract classes) and component-interfaces, we define following: Definition 7: Each component-interface is assigned a set of class-interfaces ¢ , which are the interfaces and abstract classes that provide access to the classes that are used to define the component. Since components are supposed to be easily replaceable and plug-able, it makes no real sense to assign generalities to them; by definition a component is general in a context.
Based on the definitions above, we can specify the following properties and respective refactoring guidelines:

Prototyping in Together Control Center
In this section, we describe the ongoing prototyping of our original reuse framework [9][10][11] and the extensions to support reuse of UML (see Section 3) into Together Control Center, TCC (http://www.togethersoft.com). In Section 4.1, we report on our existing code-based design reusability evaluation (DRE) tool. In Section 4.2, we describe the support of the reuse definition, assessment, and analysis framework for UML, with properties and refactoring guidelines (Section 3). For both efforts, we report on future plans.

Integration of DRE into Together Control Center
The DRE tool has been developed to measure and report reuse potential of Java software according to our original reuse framework [9][10][11], and the formal model and associated extensions that support automated refactoring [1]. The software engineer can analyze code by specifying the two reuse dimensions (generality, relation) on and between the classes and components that comprise an application. DRE analyzes the Java code of an application and tabulates the coupling counts for the eight coupling types as given in Section 2. A report of these coupling counts is presented to the user, along with refactoring guidelines for improving couplings that prevent proper reuse. The DRE prototype is a standalone tool that can be downloaded with full instructions from the web at (http://www.engr.uconn.edu/~steve/DRE/dre.html).
Over the past year, we have been integrating DRE into Together Control Center (TCC) with a focus on reuse assessment of the software produced using TCC, rather than of UML designs (the focus of this paper). TCC offers a selection of software audits and metrics that a software engineer can employ to measure different aspects of code. We integrated our reuse framework and metrics as a userdefined metric to be consistent with TCC. TCC provides a rich set of Open APIs and a plug-in structure that has facilitated the integration of DRE and our reuse framework into TCC. Using TCCs OpenAPIs, functions, and objects, we crafted a bridge between our standalone DRE application and the TCC editor, providing the ability to apply our reuse evaluations to any TCC Java project. A TCC property window pane for classes was extended, as shown in Figure 6, for the generality and relation information of each of the classes. This information can be accessed and updated through the standard Togetherdefined window to view property information, as shown in Figure 6.
Once the generality levels of classes and relations among classes have been established by the software engineer, our reuse metric can be run via TCC by activating the standard DRE tool to parse through the source files (stored under the control of TCC) and determine and classify all couplings that exist. Whereas the standard metrics and audits of TCC display themselves in a TCC results pane, the complete DRE tool opens as a new application for use by the software engineer. In fact, changes made to code within the DRE environment propagate back to TCC, and vice versa (i.e., round trip engineering with respect to reuse). The generalities of classes and relations among classes are persistently stored into Javadoc-style comments for the methods/data members, which can be parsed by DRE, so that future reuses of classes can automatically initialize the generalities/relations. Note, due to space limits, we have omitted a DRE figure -please see the web page for multiple examples.
Continuing work in this area will focus on a tighter integration of DRE and TCC. Specifically, TCC has a commercial grade parser of Java source code, and since parsing is a major function of DRE to identify couplings between classes, using TCC would avoid the errors that DRE can generate. Further, we are exploring a stronger coupling of DRE measurements with the Together Ope-nAPI, which we believe is robust enough to capture the majority of DRE's capabilities, to yield a full TCC extension that runs the DRE metrics as any other metrics in TCC. We will still continue to maintain the DRE "plugin" development, enabling us to make available the latest changes of the standalone DRE in a timely fashion.

UML Reuse in Together Control Center
This section focuses on describing the integration of our reuse definition, assessment, and analysis framework for UML (see Section 3) into Together Control Center (TCC). This effort provides direct support to the properties and refactoring guidelines for UML designs in order to allow software engineers utilizing TCC to define, track, and manage reuse at all stages of design and development. This is inclusive from initial/early design through detailed design and implementation, supported by the integration of DRE and TCC (Section 4.1). Since TCC is a full concept-to-code CASE tool, the incorporation of our reuse framework methodology to span the entire software lifecycle is a logical approach. Support for the UML reuse framework as presented in Section 3 must be at the definitional stage, to allow generalities to be set, and at the assessment/analysis stages, for Properties 4 to 13 to be dynamically enforced and for refactoring guidelines RG1 to RG10 to be available. As use cases are created, they will be marked with generality levels by the software engineer, and if any properties are violated, our extended TCC will issue alerts and warnings. The generality markings are stored persistently in TCC, so that such markings are retrievable and/or alterable in the future. Figure 7 demonstrates the modifications to the use case property window of TCC to support generality and related, in a manner that is consistent to the class property window in Figure 6. As use cases are defined and related to one-another (e.g., see Figure 4 again), our enhancements to TCC to support reuse will enforce Properties 4, 5, and 6, issue alerts and warnings, and provide RG1, RG2, and RG3 for refactoring to correct violations.
As an application's design continues to evolve, the software engineer will follow the use cases with creating class diagrams to give application functions more detail, and can employ the class diagram property windows as given in Figure 6 to define both the generality and relations among classes. After these class diagrams are created and marked, the use cases that comprise an application can be related to the classes (via Definition 3 in Section 3.2). At this stage of design, Property 7 regarding the generality of the use case vs. the generality of the classes related to the use case comes into play, and will be enforced with refactoring via RG4 as needed for violations. Also, Properties 8, 9, and 10, for use-case-to-use-case and use-case-to-class dependencies, and Properties 11, 12, and 13 for components, will be tracked, enforced, and refactored (via RG5 to RG10) as needed. To track and analyze considerations for all properties, a reuse assessment pane for TCC has been prototyped, as shown in Figure 8. There are four windows in Figure 8 that track the current warnings and violations (first window), the affected elements for a selected warning (second window), and for a selected affected element, a description of the problem (third window), and the refactoring guidelines (fourth window). This organization is consistent with the properties and refactoring guidelines as presented in Section 3. Using these various windows, the software engineer can explore the reuse problems with a UML design, make changes, and view the impact of the changes. Note also that the information that is displayed in these windows is affected by the various actions of a software engineer utilizing TCC/UML, namely, defining attributes and methods, associations, and generalizations (see the end of Section 3.2), and constructing sequence/collaboration diagrams (see Sections 3.3 and 3.4), which all may result in violations of properties and require corrective actions.

Conclusion and Ongoing Research
In this paper, we have presented a reuse definition, assessment, and analysis framework for UML that elevates reuse to a first class partner in early and all stages of the design and development process. Our focus was on future reusability or reuse potential, that extended our prior work at the class/component/software level (see Section 2 and [9][10][11]) to consider reuse within UML. Specifically, in Section 3, we proposed a robust set of formal properties and associated refactoring guidelines for reuse definition, assessment, and analysis for use case diagrams (Section 3.1), class diagrams (Section 3.2), behavior modeling diagrams (Section 3.3), and component diagrams (Section 3.4). We have transitioned both the original reuse framework [9][10][11] and the UML extensions (see Section 3) into Together Control Center (see Section 4). Overall, we believe our research and prototyping efforts are a major step forward for seamlessly supporting reuse in UML and Java for software designers, engineers, and developers.
In our ongoing, we are exploring a formal model for reuse [1] as a basis for automated reusability assessment and refactoring, supplemented by a genetic algorithm to assign generality levels. For reuse in UML, over the next year, we plan on expanding and evolving the UML framework as given in Section 3, and on applying our formal model concepts [1] for automated refactoring to UML designs.