Deferring Elimination of Design Alternatives in Object- Oriented Methods

Transcription

1 Deferring Elimination of Design Alternatives in Object- Oriented Methods Mehmet Aksit and Francesco Marcelloni TRESE project, Department of Computer Science, University of Twente, P.O. Box 217, 7500 AE Enschede, The Netherlands. www server: Dipartimento di Ingegneria della Informazione, Università di Pisa, Via Diotisalvi, , Pisa, Italy. Abstract While developing systems, software engineers generally have to deal with a large number of design alternatives. Current object-oriented methods aim to eliminate design alternatives whenever they are generated. Alternatives, however, should be eliminated only when sufficient information to take such a decision is available. Otherwise, alternatives have to be preserved to allow further refinements along the development process. Too early elimination of alternatives results in loss of information and excessive restriction of the design space. This paper aims to enhance the current object-oriented methods by modeling and controlling the design alternatives through the application of fuzzy-logic based techniques. By using an example method, it is shown that the proposed approach increases the adaptability and reusability of design models. The method has been implemented and tested in our experimental CASE environment. Index terms: design alternatives, object-oriented methods, fuzzy logic, adaptable design models, CASE environments and software artifacts. Correspondence address: Mehmet Aksit, University of Twente, P.O. Box. 217, 7500 AE, Enschede, The Netherlands. aksit@cs.utwente.nl Tel: Fax:

2 1. Introduction During the last decade, a considerable number of object-oriented methods have been introduced [4][29]. Methods create software artifacts 1 through the application of a number of heuristics. For example, the method OMT [29] introduces heuristics for identifying and discarding object-oriented artifacts such as classes, associations, aggregations and inheritance relations. Current methods aim to eliminate design alternatives as early as possible. Assume that a software engineer has to identify classes. Typically, classes are identified by applying the rule If an entity in a requirement specification is relevant then select it as a class. The software engineer may conclude that the entity being reasoned partially fulfils the relevance criterion. This means that the entity partially matches the class concept. The rule, however, forces the software engineer to classify the input values into two categories: relevant and not relevant. This results in loss of information because the information about the partial relevance of the entity is not modeled and therefore in the subsequent phases cannot be considered explicitly. The partial relevance value has to be preserved to allow further refinements along the development process. Elimination of alternatives should be deferred until sufficient information has been collected. This article introduces a new method-independent approach based on fuzzy-logic techniques for deferring the elimination of alternatives and thereby increasing the adaptability and reusability of design models. Based on the introduced approach, a simple object-oriented method has been implemented and tested [5]. This paper is organized as follows. The next section introduces a simple method and describes its application to an example problem. Section 3 analyzes the problems that may be experienced due to the elimination of alternatives. Further, this section defines a list of requirements. Section 4 introduces the fuzzy-logic based software development technique 1 Artifacts are also called products of software engineering. 1

3 and illustrates its applicability. Section 5 describes our CASE environment. Evaluation of the approach is presented in section 6. Section 7 summarizes the related work. Finally, section 8 gives conclusions. 2. Object-Oriented Methods In general, a software development method can be characterized in terms of three major components: artifacts, heuristics and software process [6]. Classes, attributes, operations, and inheritance and part-of relations are examples of object-oriented artifacts. To identify or eliminate an artifact, and relate an artifact to other artifacts, methods provide heuristics. In most methods, heuristics are defined informally using textual forms in a natural language (see, for instance, [16][28][29]). For example, a candidate class can be identified by applying the following heuristic: If an entity is relevant in the problem domain and can exist autonomously then it is a candidate class. Artifacts may have some casual order among each other. The heuristics implicitly express how an artifact is casually related to other artifacts. For example, to define a candidate class, first an entity must be identified. The software process of a method specifies the order in which the phases of that method have to be executed. In the least restricted case, the software process is only determined by the casual dependencies among the artifacts. This may, however, generate a large amount of possible development paths. Several methods therefore introduce additional constraints on the application of heuristics. For instance, in OMT to define the so-called object model, the following sequence of activities is recommended: requirement specification, noun extraction, and class, association, attribute, and inheritance identification and refinement. 2.1 Description of a Simple Object-Oriented Method To exemplify the problems addressed in this paper, we will present a simple method and apply it to an example problem. The heuristics used in this method are extracted from OMT [29]. 2

4 Defining the heuristics of a method is a special case of knowledge acquisition as described in traditional knowledge engineering techniques [10]. The domain for knowledge engineering hereby is the software development method. The heuristics of most methods can be derived from the existing documentation with a reasonable effort [30]. In the example method, heuristics are expressed using conditional statements in the form IF <antecedent> THEN <consequent>. Assume that the following rule is used to identify candidate classes: R(1) Candidate Class Identification: IF AN ENTITY IN A REQUIREMENT SPECIFICATION IS RELEVANT AND CAN EXIST AUTONOMOUSLY IN THE APPLICATION DOMAIN THEN SELECT IT AS A CANDIDATE CLASS. Here, Entity and Candidate Class are the artifact types to be reasoned and relevant and autonomously are two property values of artifact Entity. After identifying candidate classes, redundant classes can be eliminated for instance by using the following rule: R(2) Redundant Class Elimination: IF TWO CANDIDATE CLASSES EXPRESS THE SAME INFORMATION THEN DISCARD THE LEAST DESCRIPTIVE ONE. Here, rule Candidate Class Identification is coupled to rule Redundant Class Elimination; two rules are coupled if the result of one rule is the input of another rule. To complete our simple method, we introduce the following 6 rules: R(3) Attribute Identification: IF AN ENTITY IN A REQUIREMENT SPECIFICATION IS RELEVANT AND CANNOT EXIST AUTONOMOUSLY IN THE APPLICATION DOMAIN THEN IDENTIFY IT AS AN ATTRIBUTE. R(4) Class to Attribute Conversion (conceptual): IF A CLASS QUALIFIES ANOTHER CLASS THEN IDENTIFY IT AS AN ATTRIBUTE OF THAT CLASS. R(5) Aggregation Identification: IF CLASS A CONTAINS CLASS B THEN CLASS A AGGREGATES CLASS B. R(6) Inheritance Identification (conceptual): IF CLASS A IS A KIND OF CLASS B THEN CLASS A INHERITS FROM CLASS B. R(7) Class to Attribute Conversion (functional): IF NO OPERATIONS BELONG TO A CLASS THEN RECONSIDER IT AS AN ATTRIBUTE. R(8) Inheritance Identification (functional): IF OPERATIONS DEFINED IN CLASS B ARE A SUBSET OF OPERATIONS DEFINED IN CLASS A THEN CLASS A INHERITS FROM CLASS B. 3

5 FIG. 1. The casual dependencies between the rules of the example method. The casual dependencies between these rules are shown in Figure 1. This method takes the requirement specification as input and produces classes, attributes, and inheritance and aggregation relations as output. The method has to evaluate various rules before 4

6 generating a model. For example, to identify an entity in a requirement specification as a class, the corresponding rules must be evaluated in the following order. First, the rule Candidate Class Identification must accept the entity. Second, the rules Redundant Class Elimination and Class to Attribute Conversion (both conceptual and functional) must reject the entity. To consider an entity as an attribute, the rule Attribute Identification must accept the entity. An attribute can also be identified by applying the rules Class to Attribute Conversion, which transform candidate classes into attributes. 2.2 Application of the Method Our example problem is described in the following: A graphics application provides tools for drawing a set of graphic elements such as points, lines, rectangles, circles, and squares. A point is defined by its coordinates. A line has two reference points. A rectangle can be defined by a reference point and a diagonal line. A circle can be characterized by its center and radius. A square can be defined by a reference point and a diagonal line. Each element has a color. For brevity, we will not describe the detailed properties of all the graphical elements. After inspecting the requirement specification and using noun extraction, the following entities are provided to the rule Candidate Class Identification: Graphics-Application, Tool, Graphic-Element, Point, Line, Rectangle, Circle, Square, Coordinate, Reference-Point, Diagonal-Line, Center, Radius and Color. The rule Candidate Class Identification rejects entities Graphics-Application and Tool because they are not considered relevant for the application. The entity Color is rejected because Color qualifies other graphical objects and therefore is not considered as an autonomously existing entity. All other entities are selected as candidate classes. The rejected entities are evaluated by the rule Attribute Identification. This rule accepts Color as an attribute because Color qualifies the graphic elements, but the rule rejects Graphics- Application and Tools. 5

7 The following groups of candidate classes express similar information: (Square, Rectangle), (Line, Diagonal-Line, Radius), (Point, Reference-Point, Center). The rule Redundant Class Elimination eliminates Square, Diagonal-Line, Radius, Reference-Point and Center because they are considered less expressive than their equivalent candidate classes. Candidate classes Graphic-Element, Circle and Coordinate are not eliminated because there are no other candidate classes which express similar information. The rule Class to Attribute Conversion (conceptual) converts candidate class Coordinate to an attribute because Coordinate qualifies Point. Further, this rule selects Graphic-Element, Point, Line, Rectangle and Circle as classes. After the application of the rule Aggregation Identification, the following aggregation relations are identified: Line, Rectangle and Circle aggregate Point. Rectangle and Circle aggregate Line. The rule Inheritance Identification (conceptual) identifies a candidate inheritance relation between Graphic-Element, and Point, Line, Rectangle and Circle. All the selected classes have meaningful operations and therefore they are not converted to attributes by the rule Class to Attribute Conversion (functional). The operations of classes Point and Line are a subset of the operations defined by Rectangle and Circle. The rule Inheritance Identification (functional) determines that Rectangle and Circle inherit from Point and Line. Concerning the aggregation and inheritance relations between Rectangle, and Point and Line, the software engineer may consider two possibilities. The conceptual viewpoint suggests that Rectangle aggregates Point and Line. The functional viewpoint suggests that Rectangle inherits from Point and Line. Similar considerations can be applied to the relations between Circle, and Point and Line. The object diagram of the graphics application is shown in Figure 2. Here aggregation relation is selected between Rectangle and Point and Line. 6

8 FIG. 2. The object diagram of the graphics application in the OMT notation. 3. Elimination of Design Alternatives Application of a rule classifies a set of artifacts into two subsets: accepted or rejected. Once an artifact has been classified, for instance into the rejected set of a rule, it is not considered anymore by the rules that apply to the accepted set of that rule. For example, after applying the rule Candidate Class Identification, if an entity in a requirement specification is not selected as a candidate class, then this entity will not be considered by the rule Redundant Class Elimination. Of course, a rejected entity can be considered by another rule, which applies to the entities in a requirement specification. For instance, the rule Attribute Identification can be applied to the entities, which are rejected by the rule Candidate Class Identification. If all the rules, which are applicable to an entity in a requirement specification reject that entity, then the entity is practically discarded. Especially in the early phases, however, there may not be sufficient amount of information available to take abrupt decisions like discarding an entity. Therefore, software engineers should be enabled to preserve the alternatives and select the most appropriate one only when it is necessary. 7

9 3.1 Problems Caused by Elimination of Alternatives In the following section, we evaluate the object model of our graphics application. We focus on the changes necessary to improve the model. In particular, two kinds of changes are perceived: reincarnation of eliminated artifacts and conversion of artifacts Reincarnation of eliminated artifacts Some artifacts, which are discarded during the analysis process, may be found to be relevant artifacts in the later phases. Suppose that later in the design process, we realize that some specific operations could be associated with square. It would be quite reasonable that square had been identified as a class. However, the candidate class Square was considered redundant and therefore eliminated by the early elimination of alternatives carried out by the rule Redundant Class Elimination Conversion of artifacts Application of an object-oriented method classifies entities in a requirement specification into object-oriented artifact types such as classes, attributes, and operations. During the development process, the software engineer may discover that an entity could have been better classified into a different artifact type than the current artifact type. This requires conversion of entities from one artifact type to another. Assume that the operation to display a graphic element is based on a set of sophisticated color processing operations. In our object model, Color was classified as an attribute and not as a class. A practical implementation of this attribute will probably be an instance of class String. However, color-processing operations demand a more complex object structure. Therefore, it would be quite reasonable to define Color as a class. Since Color was selected as an attribute, however, the software engineer is misguided to associate the 2 One may claim that an experienced designer should not eliminate Square from the class repository. Since not all the entities in a realistic requirement specification can be (or should be) considered relevant to be included in the object model, unwanted elimination of artifacts in current methods is, in principle, inevitable; a decision for elimination or acceptance is regularly an intuitive decision. 8

10 color processing operations with the objects that incorporate the attribute Color. This would result in objects with improper responsibility. Consider the possible relations between classes Rectangle, and Point and Line. If the software engineer adopts the conceptual viewpoint, he/she selects an aggregation relation between Rectangle, and Point and Line. On the other hand, if he/she adopts the functional viewpoint, inheritance relation seems to be more appropriate. It is likely that during the analysis phase, the software engineer adopts the conceptual viewpoint. However, during the design phase, inheritance might be more appropriate to improve reuse. This requires a conversion from one relation to another. Since in current methods no measures are associated with alternatives, it is difficult to evaluate if a conversion can effectively improve the development process. 3.2 Requirements To overcome the problems identified in the previous section, the following requirements are defined: Preserve alternatives: If alternative solutions exist for the same problem, these should be preserved to allow further refinements along the development process. Elimination of alternatives results in loss of information and may consequently degrade the quality of the process. The software engineer should be enabled to preserve alternatives and select the most appropriate whenever it is necessary, for example, before compiling a program. Provide a measure for alternatives: Preserving alternative solutions does not mean that all the alternatives are equally valid. To be able to reason about alternatives, there is a need to provide a measure for each alternative. The software engineer, for instance, may classify an entity more like a class than an attribute and may assign a higher measure to the class than the attribute. Adopt the heuristic rules of popular object-oriented methods: The concern of this paper is not to introduce a new method but extend current methods in such a way that alternatives can be managed. 9

11 CASE environment: To support the software engineer in managing alternatives, appropriate tools are desirable. Preferably, these tools have to be integrated with existing CASE environments. 4. Using Fuzzy-Logic in Deferring Elimination of Alternatives Consider the method presented in section 2.1. The rules Candidate Class Identification and Attribute Identification force the software engineer to decide if either the entity being considered is relevant and can exist autonomously, or not. Based on this decision, the entity can be either discarded, or classified as a candidate class or classified as an attribute. The selection of one of these alternatives may have a considerable impact on the resulting object model. In practice, the software engineer may find it difficult to decide if the entity is relevant or not relevant, and autonomous or not autonomous. The software engineer may perceive, for example, that the entity is partially relevant and/or autonomous and may desire to express this gradation in perception using expressions like the entity is fairly relevant. This allows the software engineer to defer the elimination of the alternatives until more information is gathered. In the following sections, we will define an artifact model for expressing partial classifications and deferring the elimination of alternatives. 4.1 Modeling Artifacts Assume that each artifact type is defined as [T, (P 1, D 1 ), (P 2, D 2 ),...,(P n, D n )] where T is the type name, P i is a property and D i is the definition domain of P i. An example artifact type is [Entity, (Relevance, {relevant, not relevant}), (Autonomy, {autonomous, not autonomous})]. Here, relevant and not relevant, and autonomous and not autonomous are the pairs of values that Relevance and Autonomy can assume. The linguistic values of a property can be easily extracted from the heuristic rules of the method. For example, from the rules Candidate Class Identification and Attribute Identification it is possible to extract the definition domain of the properties Relevance and Autonomy. Typically, in the current methods, the definition domains are composed by two values because the heuristics are generally represented using rules based on two-valued logic. 10

12 A software artifact is an instantiation of its type and can be expressed as [T, id, (P 1 : V 1 ), (P 2 : V 2 ),...,(P n : V n )], where T is the name of the artifact type, id is the unique identifier of the artifact, and V i is a value defined in domain D i of property P i. Artifacts can be also named. In the following example, Color is the name of the artifact: Color [Entity, id, (Relevance: relevant), (Autonomy: not autonomous)] To express grading, we consider the possible linguistic expressions used by the software engineer. For instance, the values weakly, slightly, fairly, substantially and strongly can describe the gradation of the property Relevance. [Entity, (Relevance, {weakly, slightly, fairly, substantially, strongly}), (Autonomy, {dependently, partially dependently, fully autonomously})] Autonomy is expressed using the linguistic values dependently, partially dependently and fully autonomously. The rules defined in section 2.1 have to be extended to reason over multiple values. Of course, the intuition captured by the heuristics has to be maintained. Consider, for example, the modified rule Candidate Class Identification: IF AN ENTITY IN A REQUIREMENT SPECIFICATION IS RELEVANCE VALUE RELEVANT AND CAN EXIST AUTONOMY VALUE AUTONOMOUS IN THE APPLICATION DOMAIN, THEN SELECT IT AS A RELEVANCE VALUE RELEVANT CANDIDATE CLASS. Here, an entity and a candidate class are the artifact types to be reasoned, Relevance and Autonomy are the properties, and relevance value and autonomy value indicate the set of values of these properties. Using these values, rule Candidate Class Identification can be represented in the following way: P P [Entity, id 1, (Relevance: V 1 {weakly, slightly, fairly, substantially, strongly}), (Autonomy: V 2 {dependently, partially dependently, fully autonomously})] [Candidate Class, id 2, (Relevance:V 3 {weakly, slightly, fairly, substantially, strongly})] Here, P and symbol indicate a generic artifact name and the implication operator, respectively. Each combination of relevance and autonomy values of an entity has to be mapped into one of the five relevance values of candidate classes. This requires in total 3 5 = 15 rules. We call these sub-rules. The following is an example of a sub-rule: 11

13 P P [Entity, id 1, (Relevance: strongly), (Autonomy: fully autonomously)] [Candidate Class, id 2, (Relevance: strongly)] Table 1 shows the 15 sub-rules. TABLE 1. Relation between the input variables and the result of rule Candidate Class Identification. P Entity, Relevance: P CandidateClass, weakly slightly fairly substantially strongly Relevance: dependently weakly weakly weakly weakly slightly partially dependently weakly slightly slightly fairly fairly fully autonomously weakly slightly fairly substantially strongly P Entity, Autonomy: Here, columns and rows represent the input values of the properties Relevance and Autonomy, respectively. Each element of the table, shown in Italics, represents the output value of a sub-rule, which is the relevance value of the candidate class being considered. For example, if the relevance and autonomy values are respectively strongly and fully autonomously, then the candidate class relevance value is strongly. We selected these output values based on the following intuition captured by rule Candidate Class Identification: the more relevant and autonomous an entity is, the more this entity is a candidate class. When the software engineer applies this rule, he/she selects the linguistic value considered the closest to his/her grade of perception. This selection is based on comparative evaluation of the linguistic values used in the rules. For example, intuitively, weakly, slightly, fairly, substantially and strongly are ordered according to increasing grades of Relevance. In the literature, definition of linguistic values has been extensively studied within the context of fuzzy-logic [35]. Fuzzy logic provides a sound framework to define a language and associate a meaning with each expression of the language [36]. The basic concept in fuzzy-logic is the notion of fuzzy set. A fuzzy set S of a universe of discourse U is characterized by a membership function :U [ 0,1] µ which associates with each element S y of U a number µ S ( y) in the interval [0,1] which represents the grade of membership of y 12

14 in S [35]. Fuzzy sets are used to express the meaning of linguistic values (see Appendix A for more details about fuzzy logic). Assume that the property Relevance is defined between 0 and 1. The meaning of the linguistic values weakly, slightly, fairly, substantially and strongly may be defined by the fuzzy sets shown in Figure 3. Here, the X and Y-axes indicate the relevance values and the grade of membership, respectively. The membership function, which characterizes each linguistic value, is shown in a different line. Notice that the definition of the linguistic values is based on partially overlapping membership functions, because the meaning of these values cannot be completely separated from each other. FIG. 3. Five linguistic values defined by membership functions. Each membership function is shown as a different line type. For example, weakly is drawn as a dashed line, fairly as a solid line, etc. Figure 4 shows the definition of linguistic values dependently, partially dependently, fully autonomously of the property Autonomy. The X and Y-axes indicate the Autonomy value and the grade of membership, respectively. Similar to Figure 3, each membership function is drawn as a different line. 13

15 FIG. 4. Membership functions of dependently, partially dependently and fully autonomously. 4.2 Fuzzy-Logic Based Rules Fuzzy logic provides a framework to reason about the extended heuristic rules. In fuzzy logic, rules are expressed in the form: IF X IS A THEN Y IS B, where X and Y are linguistic variables and A and B are linguistic values. In our case, linguistic variables are the properties of the artifacts, such as Relevance. The evaluation of the truth of the rule may result in intermediate values between 0 and 1 rather than Boolean values 0 and 1. An extension of the modus ponens, denotes generalized modus ponens, is generally used to infer a conclusion given a fact and a rule [21]. Conclusions are expressed in terms of fuzzy sets. If a crisp value is required, the fuzzy set has to be defuzzified by using a defuzzification operation [19]. While applying a rule, the software engineer has to provide the required values. For example, the rule Candidate Class Identification requires the relevance and autonomy values from the software engineer. If the software engineer provides linguistic values, then the reasoning might be implemented using a simple table look-up operation. This solution, however, cannot cope with all possible input values. For instance, if the software engineer prefers to express his/her intuition by means of a crisp value such as 0.85, the table look-up approach is not applicable. This value does not exactly match any linguistic value defined in Figure 3 and therefore does not correspond to any entry in Table 1. Certain rules may even require crisp values as input. Consider, for example, the following rule, which is presented in [7]: 14

16 IF THE NUMBER OF IMMEDIATE SUBCLASSES SUBORDINATED TO A CLASS IS SUBCLASSES VALUE THEN THE INHERITANCE HIERARCHY IS COMPLEXITY VALUE. The model of this rule is: P 1 [Class, id 1, (ImmediateSubclasses: V 1 {low, medium, high})] P 2 [Inheritance, id 2, (Complexity: V 2 {low, medium, high})] The rule aims to reconsider inheritance hierarchies when the number of subclasses subordinated to a class is too high. In this case, the software engineer can count the subclasses and provide a numeric value. Fortunately, fuzzy logic based reasoning allows inferring a conclusion also if the input values do not match the antecedent part of the rule. 4.3 Deferring Elimination of Alternatives Using Fuzzy Logic In the following, the rules of the example method presented in section 2.1 are extended by using fuzzy logic. Here, for the sake of simplicity, we present only the linguistic definition of each rule. Each sub-rule is modeled and defined in Appendix B. F(1) Candidate Class Identification: This rule was defined in section 4.2. F(2) Redundant Class Elimination: IF CANDIDATE CLASS P 1 IS RELEVANCE VALUE RELEVANT AND CANDIDATE CLASS P 2 IS RELEVANCE VALUE RELEVANT AND INFORMATION OF P 1 IS EQUIVALENCE VALUE EQUIVALENT TO INFORMATION OF P 2 AND P 1 IS EXPRESSIVENESS VALUE MORE DESCRIPTIVE THAN P 2 THEN SELECT P 1 AS A RELEVANCE VALUE NON-REDUNDANT CANDIDATE CLASS. F(3) Attribute Identification: IF AN ENTITY IN A REQUIREMENT SPECIFICATION IS RELEVANCE VALUE RELEVANT AND CAN EXIST AUTONOMY VALUE AUTONOMOUS IN THE APPLICATION DOMAIN, THEN SELECT IT AS A RELEVANCE VALUE RELEVANT ATTRIBUTE. F(4) Class to Attribute Conversion (conceptual): IF NON-REDUNDANT CANDIDATE CLASS P 1 IS RELEVANCE VALUE RELEVANT AND NON-REDUNDANT CANDIDATE CLASS P 2 IS RELEVANCE VALUE RELEVANT AND P 1 QUALIFICATION VALUE QUALIFIES P 2 THEN SELECT P 1 AS A RELEVANCE VALUE RELEVANT ATTRIBUTE AND SELECT P 1 AS A RELEVANCE VALUE RELEVANT CLASS. F(5) Aggregation Identification: IF CLASS P 1 IS RELEVANCE VALUE RELEVANT AND CLASS P 2 IS RELEVANCE VALUE RELEVANT AND P 1 CONTAIN VALUE CONTAINS P 2 THEN AGGREGATION BETWEEN P 1 AND P 2 IS RELEVANCE VALUE RELEVANT. F(6) Inheritance Identification (conceptual): IF CLASS P 1 IS RELEVANCE VALUE RELEVANT AND CLASS P 2 IS RELEVANCE VALUE RELEVANT AND P 2 IS-A-KIND-OF VALUE IS-A-KIND-OF P 1 THEN INHERITANCE BETWEEN P 1 AND P 2 IS RELEVANCE VALUE RELEVANT. 15

17 F(7) Class to Attribute Conversion (functional): IF OPERATIONS BELONG TO A CLASS P COHESION VALUE THEN SELECT P AS A RELEVANCE VALUE RELEVANT CLASS AND AS A RELEVANCE VALUE RELEVANT ATTRIBUTE. F(8) Inheritance Identification (functional): IF CLASS P 1 IS RELEVANCE VALUE RELEVANT AND CLASS P 2 IS RELEVANCE VALUE RELEVANT AND THE OPERATIONS DEFINED IN P 1 ARE DEGREE SUBSET OF THE OPERATIONS DEFINED IN P 2 THEN INHERITANCE BETWEEN P 1 AND P 2 IS RELEVANCE VALUE RELEVANT. Figure 5 displays the dependencies among the fuzzy-logic based rules. Structures of the two-valued and fuzzy-logic based methods, shown respectively in Figure 1 and Figure 5, are quite similar to each other. There are, however, a number of important differences. Each rule in the two-valued logic based method classifies the artifacts into two subsets: accepted or rejected. If an entity in a requirement specification is rejected, for instance by rule Candidate Class Identification, it is not considered any more by rule Redundant Class Elimination. If an entity is rejected by rules Candidate Class Identification and Attribute Identification, then it is practically discarded. In the fuzzy-logic based method, however, each rule gives various grades of property values to a set of artifacts. For example, if an entity is accepted as a weakly relevant candidate class by the fuzzy rule Candidate Class Identification, it is still considered by the fuzzy rule Redundant Class Elimination. In other words, in the fuzzy-logic based method, none of the entities are fully accepted or rejected; each entity is forwarded to the coupled rules with a grade of property values. As a consequence, each entity is stored in both the class and attribute repositories with possibly different property values. Hence, alternative object models can be obtained for the same problem. Unlike the fuzzy-logic based method, the two-valued logic based method generates only a single object model for a given problem because it eliminates alternatives when each rule is applied. In addition, in the fuzzy-logic based method, it is possible to tune the effects of the individual rules by applying weighting factors to the results of the rules. In Figure 5, the weighting factors are represented by W i. Typically, the weighting factors used in later phases of software development are higher than the ones in the earlier phases. This is because more accurate and precise information is expected in the later phases. 16

18 FIG. 5. The casual dependencies between the rules of the fuzzy-logic based method. 17

19 4.4 Application of the Fuzzy-Logic Based Method We have implemented and tested the fuzzy-logic based method in our experimental CASE environment. We will now illustrate the features of this approach using the graphics application given in section 2.2. The entities provided to the fuzzy rule F(1) are the same as the ones provided to the twovalued logic based method illustrated in section 2.1. These are Graphics-Application, Tool, Graphic-Element, Point, Line, Rectangle, Circle, Square, Coordinate, Reference-Point, Diagonal-Line, Center, Radius, and Color. Using Table 1, the fuzzy rule F(1) qualifies entities Graphics-Application and Tool as weakly relevant candidate classes because they are considered as weakly relevant entities and they can exist fully autonomously in the application domain. Entity Color is selected as a slightly candidate class because Color is a strongly relevant entity and can exist dependently. All the other entities are selected as strongly relevant candidate classes because they are all strongly relevant and can exist fully autonomously. Candidate classes Square, Rectangle, Line, Diagonal-Line, Radius, Point, Reference-Point and Center are all strongly relevant candidate classes. The group of classes whose information contents are strongly equivalent are the following: (Square, Rectangle), (Line, Diagonal-Line, Radius) and (Point, Reference-Point, Center). Here, classes Rectangle, Line and Point are considered substantially descriptive with respect to their pair classes and referring to Table B-1, they are selected as substantially non-redundant candidate classes by the fuzzy rule F(2). Their pair classes are selected as slightly non-redundant candidate classes because they are slightly descriptive with respect to their pair classes. The candidate classes whose information contents are weakly equivalent are selected as non-redundant candidate classes with the same relevance values as they had before applying this rule. The fuzzy rule F(3), as defined by Table B-2, qualifies Color as a strongly relevant attribute since Color is strongly relevant and can exist dependently. Graphics-Application and Tool 18

20 are considered weakly relevant attributes. Further, this rule qualifies all the other entities in the requirement specification as slightly relevant attributes. Class Coordinate strongly qualifies -substantially relevant non-redundant candidate class- Point and therefore is selected as a substantially relevant attribute and as a slightly relevant class by the fuzzy rule F(4) as defined in Table B-3. All the remaining classes except Color are considered as weakly relevant attributes and they become classes with the same relevance values that they had as non-redundant candidate classes. Color remains as a strongly relevant attribute and becomes a weakly relevant class. The results of rules F(3) and F(4) show that a name can refer to more than one artifact of the same artifact type. Therefore, the result obtained by rule F(4) must be combined with the result obtained by applying F(3). If we consider equal weighting factors associated with rules F(3) and F(4), we obtain the following: Color is a strongly relevant attribute, the relevance of Coordinate as an attribute is defined by the composition of the membership functions slightly and substantially, and the relevance of all the remaining entities as an attribute is defined by the composition of the membership functions weakly and slightly. The composition of linguistic values slightly and substantially, and weakly and slightly are represented in Figures 6(a) and 6(b), respectively. Classes Graphic-Element and Circle are strongly relevant classes and they are considered strongly contain -substantially relevant class- Point, and therefore according to Table B-4, the aggregate relations between them and Point are substantially relevant. Classes Rectangle and Line are substantially relevant classes and they are considered strongly contain Point and therefore the aggregate relations between them and Point are substantially relevant. Further, Circle and Rectangle strongly contain Line, and therefore the aggregate relations between them and Line is substantially relevant. Classes Square, Reference-Point, Diagonal-Line, Center Radius are slightly relevant classes and therefore the aggregation relations between them and Point are slightly relevant. Similarly, the aggregation relation between Square and Line is slightly relevant. All the remaining possible aggregation relations are considered to be weakly relevant. 19

21 FIG. 6. Composition of values: (a) slightly and substantially, and (b) weakly and slightly. Class Circle is a strongly relevant class and it is considered to be a strongly is-a-kind-of Graphic-Element. Since Graphic-Element is a strongly relevant class, the inheritance relation between Circle and Graphic-Element is considered to be strongly relevant. Classes Point, Line and Rectangle are substantially relevant classes and they are considered to be strongly is-a-kind-of Graphic-Element. Therefore, according to Table B-4, the inheritance relations between these classes and Graphic-Element are substantially relevant. Classes Square, Reference-Point, Diagonal-Line, Center, Radius are slightly relevant classes and they are considered to be strongly is-a-kind-of Graphic-Element. Therefore, the inheritance relations between these classes and Graphic-Element are slightly relevant. All the remaining possible inheritance relations are considered to be weakly relevant. The rules F(7) and F(8) can be applied after the identification of the operations of objects. Before applying these rules, let us summarize the class and attribute relevance values in Table 2. The result of the application of the fuzzy rules F(5) and F(6) in identifying aggregation and inheritance relations is shown in Table 3. Learning more about Square: During the application of the two-valued logic based method, Square was discarded by rule Redundant Class Elimination because Rectangle was considered more descriptive than Square. In the fuzzy-logic based method, Square was accepted as a slightly relevant class 20

22 and also as an attribute with a relevance value determined by the composition of weakly and slightly. TABLE 2. Current class and attribute relevance values of the entities. Entities Class, Relevance: Attribute, Relevance: Graphics- Tool Graphic- Point Line Rectangle Application Element weakly weakly strongly substantially substantially substantially weakly weakly weakly, slightly weakly, slightly weakly, slightly weakly, slightly Entities: Circle Square Coordinate Reference- Diagonal- Center Radius Color Point Line Class, strongly slightly slightly slightly slightly slightly slightly weakly Relevance: Attribute, Relevance: weakly, slightly weakly, slightly slightly, substantially weakly, slightly weakly, slightly weakly, slightly weakly, slightly strongly TABLE 3. Relevance of aggregation and inheritance relations between the classes. Aggregated Superclass Aggregation, Point Line Inheritance, Graphic-Element Relevance: Relevance: Graphic-Element substantially weakly Point substantially Circle substantially substantially Circle sstrongly Rectangle substantially substantially Rectangle substantially Line substantially - Line substantially Square slightly slightly Square slightly Reference-Point slightly - Reference-Point slightly Diagonal-Line slightly - Diagonal-Line slightly Center slightly - Center slightly Radius slightly - Radius slightly Aggregator Subclass Now assume that during the operation identification phase, we identify a set of operations which can be associated with Square with the cohesion value strongly. After the application of rule F(7) as illustrated by Tables B-5 and B-6, Square becomes a substantially relevant class and a weakly relevant attribute. This result must be combined with the previous one obtained by rule F(4). As the input values of rule F(7) appear less subjective than the ones of rule F(4), we weight the result of rule F(7) twice as the result of rule F(4). Figures 7(a) and 7(b) show the relevance of Square as a class after applying rules F(4) and F(7), respectively. It is clear that the relevance value of Square is revalued as a class after the application of rule F(7). The crisp value obtained by defuzzifying the fuzzy set in Figure 21

23 7(b) by the center of area strategy is 0.58, whereas the defuzzified value for Figure 7(a) is FIG. 7. Changes to the relevance value of Square as a class: (a) after applying F(4) and (b) F(7). Learning more about Color: During the application of the two-valued logic based method, Color was considered as an attribute and was discarded from being a class. In the fuzzy-logic based method, Color was accepted as a weakly relevant class by rule F(4) and as a strongly relevant attribute by rules F(3) and F(4). Rules F(3) and F(4) have equal weighting factors. Now let us assume that during the operations identification phase we realize that a number of color processing operations are needed. These operations are associated with Color with cohesion value strongly, and using Tables B-5 and B-6, Color is now concluded to be a substantially relevant class and a weakly relevant attribute. The result obtained by rule F(7) has to be combined with the results obtained by the previous rules. We assume that the weighting factor associated with rule F(7) is 1. Figures 8(a) and 8(b) show the grade of relevance of Color as a class after the application of rules F(4) and F(7), respectively. Similarly, Figure 9 shows the grade of relevance of Color as an attribute. If we defuzzify the relevance values of Color, we obtain 0.6 relevance as a class and 0.36 relevance as an attribute. Color is revalued as a class but devalued as an attribute. 22

24 FIG. 8. Grade of relevance of Color as a class: (a) after applying F(4) and (b) F(7). FIG. 9. Grade of relevance of Color as an attribute: (a) after applying F(4) and (b) F(7). Learning more about Coordinate: In the two-valued logic based method, Coordinate was selected as an attribute of class Point. In the fuzzy-logic based method, however, the application of the rules F(3) and F(4) made Coordinate a slightly relevant class and an attribute with a relevance value determined by the composition of linguistic values slightly and substantially. The application of rule F(7) effects the grade of relevance of Coordinate. Now assume that we identify a set of operations to process coordinate values. These operations, however, are associated with the graphical elements but not with Coordinate. Therefore, the cohesion value of Coordinate is weakly. As a result of rule F(7), Coordinate is now qualified as a weakly relevant class and a strongly relevant attribute. Figures 10(a) and 10(b) show the grades of relevance of Coordinate as a class and an attribute, respectively. Assuming that the weighting factors are 0.5 for rules F(3) and F(4), and 1 for rule F(7), then the 23

25 defuzzified values of grade of relevance as a class and attribute are 0.16 and 0.64, respectively. Clearly, Coordinate is now devalued as a class but revalued as an attribute. Learning more about relations: In the two-valued logic based method, Point and Line were considered parts of Rectangle. Possible inheritance relations between Rectangle, and Point and Line were discarded. In case of the fuzzy-logic based method, the aggregation relation between Rectangle, and Point and Line was considered to be substantially relevant. Further, the inheritance relation between Rectangle, and Point and Line was considered to be weakly relevant. By the fuzzy-logic based method, Point, Line and Rectangle were qualified as substantially relevant classes. FIG. 10. Grade of relevance of Coordinate: (a) as a class and (b) as an attribute. Now assume that, during the operation identification phase, we realize that the operations defined for classes Point and Line are fully a subset of the operations defined for Rectangle. After the application of rule F(8), using Table B-7, the inheritance relation between Rectangle, and Point and Line is now revalued to substantially relevant. Since there is now more information available, we associate with this rule 2 as a weighting factor. The grade of relevance for the aggregation and inheritance relations are presented in Figure 11. The defuzzified relevance values for aggregation and inheritance relations are 0.75 and 0.67, respectively. 24

26 After the application of rules F(7) and F(8), the following artifacts have a defuzzified value of grade of relevance as a class higher than 0.5: Graphic-Element, Point, Line, Rectangle, Circle, Square and Color. Concerning relations among classes, either Rectangle aggregates Point and Line with a defuzzified value of grade of relevance 0.75, or Rectangle inherits from Line and Point with a defuzzified grade of relevance The same results are obtained for Circle. FIG. 11. Grade of relevance of relations between Rectangle, Point and Line: (a) Rectangle aggregates Point and Line and (b) Rectangle inherits from Point and Line. 4.5 Selection from the Alternatives By analyzing the casual dependencies among the rules shown in Figure 5 possible alternatives can be detected. For example, in our experimental tool, the artifact types Candidate Class and Attribute are identified as two possible alternatives for the artifact type Entity. When it is required, an alternative can be selected automatically by the CASE tool by comparing the defuzzified linguistic values and selecting the alternative corresponding to the highest value. Before the selection is made, the software engineer may be consulted. In our CASE tool, this consulting is activated if the compared values are close to each other. It is also possible to set a threshold value for the automatic elimination of alternatives. For instance, assume that a and b are the defuzzified values associated with the alternatives. If a - b is larger than a threshold value, then the alternative associated with b is automatically eliminated. When the automatic elimination is disabled all the alternatives are preserved. 25

27 The software engineer may obtain a list of alternatives at any time and then decide to eliminate alternatives. In the graphics application, Square and Color are selected as classes because their defuzzified relevance values as a class are 0.58 and 0.6 respectively. These values are higher than the defuzzified attribute values. Coordinate is selected as an attribute since its defuzzified relevance value as an attribute is 0.64, whereas its defuzzified relevance value as a class is As shown by Figure 11, the selection between inheritance or aggregation relation is less obvious. Since the defuzzified values of these alternative relations are quite close to each other, the software engineer is consulted. If conceptual modeling is considered important, then the software engineer may select the aggregation relation. If reusability is the main concern, then the inheritance relation can be the choice. In the case of two-valued logic based method, no measure is provided to help the software engineer deciding if the aggregation relation should convert to an inheritance relation. In the case of fuzzy-logic based method, however, the software engineer may realize that the two solutions are approximately equivalent. In Figure 12, the resulting object model is shown. In this figure, to increase reusability, inheritance relation is selected between Rectangle, and Point and Line. Based on the same consideration, Square and Circle inherit from Point and Line. 5. CASE Environment Our CASE environment is based on Rational Rose [27] because of its availability in our laboratory. We developed a separate repository to store the extended artifacts. We linked these artifacts to the Rational Rose environment using the OLE technology. A version of this tool is presented in [30]. 26

28 FIG. 12. The resulting object model with an emphasis on reuse. We built tools to support method engineers in extending the artifacts with linguistic values and in defining fuzzy rules. The rule editor is shown in Figure 13. Here, the definition of the fuzzy rule Candidate Class Identification is illustrated. A rule is defined by providing its name, the table that describes the sub-rules, and the parameters to select an appropriate implementation of fuzzy reasoning. The fuzzy reasoning system is implemented as an object-oriented framework [2][21]. During the execution of the rules, the software engineer interacts with the tool, which is shown in Figure 14. Here, the software engineer is requested to provide the qualification degree used in the fuzzy rule Candidate Class to Attribute Conversion (conceptual). The tool shows the definition of the linguistic values so that the software engineer can relatively compare the possible input values. 27

29 FIG. 13. Tool for defining the fuzzy-rules. FIG. 14. Tool for providing the linguistic values. 6. Evaluation with Respect to the Requirements In this section we evaluate our approach with respect to the requirements presented in section 3.2. Preserve alternatives: Current methods eliminate alternatives during the application of each rule. As discussed in section 3.1, the resulting object model is less adaptable to new information available during the software development process. In the fuzzy-logic based method, alternatives may be left and therefore, in principle no alternatives have to be eliminated. During the application of the first four fuzzy rules, for instance, Square became first a strongly relevant candidate class, then a slightly non- 28