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.
email: aksit@cs.utwente.nl, www server: http://wwwtrese.cs.utwente.nl
Dipartimento di Ingegneria della Informazione, Università di Pisa,
Via Diotisalvi, 2-56126, Pisa, Italy.
email: france@iet.unipi.it
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.
E-mail:aksit@cs.utwente.nl
Tel:+31-53-4892638
Fax:+31-53-4893503
1.Introduction
During the last decade, a considerable number of object-oriented methods have been introduced [4][29]. Methods create software artifacts1 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.
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.1Description 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].
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
R(1)Candidate Class Identification:
I F 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:
I F 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:
I F 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):
I F A CLASS QUALIFIES ANOTHER CLASS THEN IDENTIFY IT AS AN ATTRIBUTE OF THAT CLASS.
R(5)Aggregation Identification:
I F CLASS A CONTAINS CLASS B THEN CLASS A AGGREGATES CLASS B.
R(6)Inheritance Identification (conceptual):
I F CLASS A IS A KIND OF CLASS B THEN CLASS A INHERITS FROM CLASS B.
R(7)Class to Attribute Conversion (functional):
I F 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.
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
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.2Application 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.
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.
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.
3.1Problems 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.
3.1.1Reincarnation 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 Elimination2.
3.1.2Conversion 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
2One 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.
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.2Requirements
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.
?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.
https://www.doczj.com/doc/f7711088.html,ing 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.1Modeling Artifacts
Assume that each artifact type is defined as [T, (P1, D1), (P2, D2),...,(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.
A software artifact is an instantiation of its type and can be expressed as [T, id, (P1: V1), (P2: V2),...,(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:
I F 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 ←[Entity, id1, (Relevance: V1∈ {weakly, slightly, fairly, substantially, strongly}), (Autonomy: V2∈ {dependently, partially dependently, fully autonomously})] ?P ←[Candidate Class, id2, (Relevance:V3∈{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 × rules. We call these sub-rules. The following is an example of a sub-rule:
3=
5
15
P ←[Entity, id1, (Relevance: strongly), (Autonomy: fully autonomously)]?
P ←[Candidate Class, id2, (Relevance: strongly)]
Table 1 shows the 15 sub-rules.
TABLE 1. Relation between the input variables and the result of rule Candidate Class Identification.
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
μ which associates with each element characterized by a membership function []1,0
:S?
U
y() in the interval [0,1] which represents the grade of membership of y y of U a number μ
S
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.
FIG. 4. Membership functions of dependently, partially dependently and fully autonomously.
4.2Fuzzy-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]:
I F 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:
P1← [Class, id1, (ImmediateSubclasses: V1∈ {low, medium, high})] ?
P2← [Inheritance, id2, (Complexity: V2∈ {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.3Deferring 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 P1 IS RELEVANCE VALUE RELEVANT AND
CANDIDATE CLASS P2 IS RELEVANCE VALUE RELEVANT AND
INFORMATION OF P1 IS EQUIVALENCE VALUE EQUIVALENT TO INFORMATION OF P2AND
P1 IS EXPRESSIVENESS VALUE MORE DESCRIPTIVE THAN P2THEN
SELECT P1 AS A RELEVANCE VALUE NON-REDUNDANT CANDIDATE CLASS.
F(3)Attribute Identification:
I F 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 P1 IS RELEVANCE VALUE RELEVANT AND
NON-REDUNDANT CANDIDATE CLASS P2 IS RELEVANCE VALUE RELEVANT AND
P1 QUALIFICATION VALUE QUALIFIES P2THEN
SELECT P1 AS A RELEVANCE VALUE RELEVANT ATTRIBUTE AND
SELECT P1 AS A RELEVANCE VALUE RELEVANT CLASS.
F(5)Aggregation Identification:
IF CLASS P1 IS RELEVANCE VALUE RELEVANT AND CLASS P2 IS RELEVANCE VALUE RELEVANT AND
P1 CONTAIN VALUE CONTAINS P2THEN
AGGREGATION BETWEEN P1AND P2 IS RELEVANCE VALUE RELEVANT.
F(6)Inheritance Identification (conceptual):
IF CLASS P1 IS RELEVANCE VALUE RELEVANT AND CLASS P2 IS RELEVANCE VALUE RELEVANT AND
P2 IS-A-KIND-OF VALUE IS-A-KIND-OF P1THEN
INHERITANCE BETWEEN P1AND P2 IS RELEVANCE VALUE RELEVANT.
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 P1 IS RELEVANCE VALUE RELEVANT AND CLASS P2 IS RELEVANCE VALUE RELEVANT AND
THE OPERATIONS DEFINED IN P1 ARE DEGREE SUBSET OF THE OPERATIONS DEFINED IN P2THEN
INHERITANCE BETWEEN P1AND P2 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.
FIG. 5. The casual dependencies between the rules of the fuzzy-logic based method.
4.4Application 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 two-valued 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
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.