Deferring Elimination of Design Alternatives in Object- Oriented ...
Transcript of Deferring Elimination of Design Alternatives in Object- Oriented ...
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: [email protected], www server: http://wwwtrese.cs.utwente.nl
��Dipartimento di Ingegneria della Informazione, Università di Pisa,Via Diotisalvi, 2-56126, Pisa, Italy.
email: [email protected]
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 designmodels, CASE environments and software artifacts.
Correspondence address: Mehmet Aksit, University of Twente, P.O. Box. 217,7500 AE, Enschede, The Netherlands.
E-mail: [email protected]: +31-53-4892638Fax: +31-53-4893503
1
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.
2
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].
3
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 AINHERITS FROM CLASS B.
4
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
5
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.
6
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.
7
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.
8
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.
3.1.1 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 Elimination2.
3.1.2 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 allthe entities in a realistic requirement specification can be (or should be) considered relevant to be included in theobject model, unwanted elimination of artifacts in current methods is, in principle, inevitable; a decision forelimination or acceptance is regularly an intuitive decision.
9
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.
10
• 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, (P1, D1), (P2, D2),...,(Pn, Dn)] where T is the
type name, Pi is a property and Di is the definition domain of Pi. 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.
11
A software artifact is an instantiation of its type and can be expressed as [T, id, (P1: V1), (P2:
V2),...,(Pn: Vn)], where T is the name of the artifact type, id is the unique identifier of the
artifact, and Vi is a value defined in domain Di of property Pi. 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 ← [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
1553 =× rules. We call these sub-rules. The following is an example of a sub-rule:
12
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.
P ← Entity, Relevance:
P ← Entity, Autonomy:
P ← CandidateClass,Relevance:
weakly slightly fairly substantially strongly
dependently weakly weakly weakly weakly slightly
partially dependently weakly slightly slightly fairly fairly
fully autonomously weakly slightly fairly substantially strongly
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 [ ]1,0U:S ⇒µ which associates with each element
y of U a number µ S y( ) in the interval [0,1] which represents the grade of membership of y
13
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 adifferent 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.
14
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]:
15
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:
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.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 P1 IS RELEVANCE VALUE RELEVANT AND
CANDIDATE CLASS P2 IS RELEVANCE VALUE RELEVANT AND
INFORMATION OF P1 IS EQUIVALENCE VALUE EQUIVALENT TO INFORMATION OF P2 AND
P1 IS EXPRESSIVENESS VALUE MORE DESCRIPTIVE THAN P2 THEN
SELECT P1 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 P1 IS RELEVANCE VALUE RELEVANT AND
NON-REDUNDANT CANDIDATE CLASS P2 IS RELEVANCE VALUE RELEVANT AND
P1 QUALIFICATION VALUE QUALIFIES P2 THEN
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 P2 THEN
AGGREGATION BETWEEN P1 AND 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 P1 THEN
INHERITANCE BETWEEN P1 AND P2 IS RELEVANCE VALUE RELEVANT.
16
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 P2 THEN
INHERITANCE BETWEEN P1 AND 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 Wi. 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.
17
FIG. 5. The casual dependencies between the rules of the fuzzy-logic based method.
18
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 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
19
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.
20
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
21
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 Graphics-Application
Tool Graphic-Element
Point Line Rectangle
Class,Relevance:
weakly weakly strongly substantially substantially substantially
Attribute,Relevance:
weakly weakly weakly,slightly
weakly,slightly
weakly,slightly
weakly,slightly
Entities: Circle Square Coordinate Reference-Point
Diagonal-Line
Center Radius Color
Class,Relevance:
strongly slightly slightly slightly slightly slightly slightly weakly
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.
SubclassAggregator
SuperclassAggregated
Aggregation,Relevance:
Point Line Inheritance,Relevance:
Graphic-Element
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
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
22
7(b) by the center of area strategy is 0.58, whereas the defuzzified value for Figure 7(a) is
0.25.
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.
23
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
24
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.
25
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 0.67. The same results are
obtained for Circle.
FIG. 11. Grade of relevance of relations between Rectangle, Point and Line: (a) Rectangle aggregates Pointand 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.
26
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 0.16. 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].
27
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.
28
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-
29
redundant class, and finally a slightly relevant class. Square was also selected as an
attribute whose relevance was determined by the composition of weakly and slightly. In
the two-valued logic based method, however, Square was eliminated and therefore was
not included in the final object model shown in Figure 2.
The fuzzy-logic based method can be considered as a learning process; a new aspect of
the problem being considered is learned after the application of each rule. Obviously, a
new aspect can modify the previously gathered property values. The fuzzy-logic theory
provides techniques to reason and compose the results of the rules. For example, as
shown by Figure 7, after applying rule F(7), Square was revalued as a class although
first it was considered as slightly relevant class. Similarly, during the analysis process, as
shown by Figures 8 and 9, Color was revalued as a class but devalued as an attribute.
Further, Figure 10 illustrates how Coordinate was revalued as an attribute. Finally,
Figure 11 shows the devaluation of aggregation and the revaluation of inheritance
relations. Clearly, as illustrated by section 4.4, software development through learning,
as exemplified by the fuzzy-logic based method, creates very adaptable and reusable
design models.
• Provide a measure for the alternatives: The fuzzy-logic based method allows
preserving alternatives and associating a measure for each alternative. Measures can be
expressed as linguistic or crisp values and are useful when the alternatives have to be
eliminated. The use of measures was practically illustrated during the analysis process
of the graphics application in section 4.4. Several entities such as Square, Color and
Coordinate, and relations such as aggregation and inheritance, were expressed and
processed using linguistic values. Measures could be adapted through the various
phases. In the end, these measures were used to eliminate alternatives.
• Adopt the heuristic rules of popular object-oriented methods: As illustrated in section
4, the fuzzy-logic technique can be conveniently applied to extend current methods.
The software engineer’s perception can be expressed by using linguistic values such as
weakly, slightly, fairly, substantially and strongly. These values can be easily derived
30
from the heuristics of current methods. Consider for example, the two-valued logic
based rule Candidate Class Identification as defined in 2.1. The linguistic values used
in this rule are relevant and not relevant, and autonomous and not autonomous. While
defining the fuzzy-version of this rule, we extended these values with the commonly
used expressions weakly, slightly, fairly, substantially and strongly. The meaning of the
values shown in Figures 3 and 4 can be improved through experimentation. In the
literature [19], it has been shown that linguistic values can be defined in reasonable
accuracy. Nevertheless, the fuzzy-logic based rules are more expressive than the ones
defined by current methods, since the value domain of the properties are not restricted
to two values.
• CASE environment: Integration with the Rational Rose™ environment was largely
successful. The OLE™ technology allows client-server communication between our
system and Rational Rose™. However, we had a difficulty to implement an efficient
triggering mechanism into Rational Rose™ to automatically update the extended
artifacts when a model is changed within the Rational Rose™ repository. We are
currently experimenting with this environment to improve the definition of the linguistic
values and weighting factors.
7. Related Work
In the following, we briefly present the related work in inconsistency management, fuzzy
logic and CASE environments.
Deferring Elimination of Alternatives
The Demeter system [24] aims to create adaptable software systems by deferring certain
design decisions so that software may be adapted to the changing context. For example,
functionality of software can be developed independent of the class structure. Only when
the executable software has to be generated, the operations are allocated with the
appropriate classes. Similar to our approach, the Demeter system defers the selection of
31
certain design alternatives, such as allocating responsibilities to classes, until a selection is
necessary.
Several researchers have investigated means to tolerate inconsistent alternatives. The need
of tolerating inconsistencies during software development has been pioneered in [3]. Here,
inconsistent data are automatically marked by means of pollution markers. A pollution
marker makes the inconsistent data known to procedures or human agents, which are
responsible for solving the inconsistency. Further, it protects the inconsistent data from the
action of other procedures sensitive to the inconsistency.
In [9], inconsistency handling in multi-perspective specifications is studied by using the
ViewPoint framework [26]. In this framework, each developer specifies the system by
using a representation language and a development process according to his/her own
viewpoint. The consistency rules are expressed in terms of classical logic and represent
some of the implicit assumptions and integrity constraints used in controlling and
coordinating a set of viewpoints. A meta-language based on linear-time temporal logic is
used to specify the actions necessary to cope with inconsistency. In [14] [15], the approach
of inconsistency handling shown in [9] is further developed by introducing quasi-classical
logic. On the contrary of classical logic, quasi-classical logic allows the derivation of non-
trivial inferences from inconsistent information. In the presence of inconsistencies, this
allows limited reasoning and consequently the possibility of analyzing such inconsistencies.
The analysis may identify the sources of inconsistency and may also qualify the inconsistent
information.
In [8], inconsistencies which occur between definition and actual instance of a development
process have been studied in human-centered systems. It is argued that processes defining
the interaction between humans and computerized tools have to tolerate, control and
support inconsistencies and deviations of real-world behaviors with respect to the process
model. This is necessary to maintain an effective flexibility and adaptability to the evolving
needs and preferences of the humans. They propose a framework for formally defining the
concepts of inconsistency and deviation between a human-centered-system and its process
32
support system. Deviations are tolerated as long as they do not affect the correctness of the
system. Then, a reconciling sequence of feasible events starting from an inconsistent state
and terminating in a consistent state has to be executed.
A number of papers published in the ICSE’97 workshop on “Living with Inconsistency” are
related to our work. In particular, the work presented in [32] aims at leaving inconsistency
to allow further elicitation of requirements.
Our work is similar to the related work presented in this section in that tolerating and
coping with alternative solutions, possibly inconsistent, are considered important in creating
flexible software systems. This paper analyses how alternatives are eliminated in current
software development methods. Further, alternatives are modeled and managed by means
of fuzzy-logic techniques.
Applications of fuzzy-logic and fuzzy sets
Application of fuzzy-logic to various areas is becoming more and more common. There
have been, for example, fuzzy databases which manage fuzzy information [33], fuzzy
pattern recognition systems which recognize audio and visual signals [13], fuzzy decision
support systems which are based on uncertain information [18], fuzzy control systems
which use heuristic rules to control complex structures [22]. Similarly to our approach, in
architectural and mechanical design, the use of fuzzy logic and fuzzy sets has been
investigated to cope with changing requirements. In [25], fuzzy models are used to study
the transformations of architectural objects during design. In [20], imprecise preliminary
design information is modeled and manipulated by fuzzy sets. Further, a method is provided
to map design imprecision alternatives (design variables) into design’s performance aspects
(performance variables).
Similar to our approach, in [34] fuzzy-logic techniques are used to manage inconsistent
requirements, which are expressed using fuzzy sets. By using the so-called satisfaction
functions, alternatives are evaluated and selected. This approach is useful in evaluating and
conflicting approaches. Our approach is, however, different in that we model the heuristic
33
rules as defined in well-known object-oriented methods. Fuzzy-values are generated and
evaluated by fuzzy-logic based production rules. This provides a better integration with the
current methods and CASE environments, which are defined around artifacts, rules and
processes. To the best of our knowledge, fuzzy-logic based reasoning was not applied to
software development methods before.
Fuzzy object-oriented models
In [11], the notion of fuzzy objects has been introduced. Fuzzy objects can have attributes
that contain fuzzy sets as values and there may be a partial inheritance relation between
classes. For example, class ToyVehicle can be defined to inherit the property Cost with a
grade of 0.9 from class Toy and with a grade of 0.3 from class Vehicle. In class ToyVehicle
the property Cost is initialized to Low, whereas in class Vehicle it is initialized to High. By
using the fuzzy union of the fuzzy sets determined by Low and High, the value of property
Cost of class ToyCar can be obtained. This is an interesting approach to object modeling,
but it does not propose fuzzy-logic based techniques for software development. On the
contrary, our approach focuses on the application of fuzzy-logic based reasoning to
software development methods for reducing the resolution error, and enhancing
adaptability and reusability of design models.
In [33], fuzzy objects are defined to represent complex objects with uncertainty in the
attribute values. Further, the operator merge is introduced to combine two objects into a
single object, provided that the predefined value levels are achieved. In relational databases,
such a merge operator makes it possible to retrieve data based on uncertain information.
CASE environments
In [1], fuzzy logic is applied to evaluate object-oriented CASE tools. Here, the ISO
software product quality evaluation process model has been extended using fuzzy-logic
based rules.
Recently, there has been a considerable amount of interest in formalizing software
processes. Among many experimental systems, MARVEL [12] and Merlin [17] are related
34
to our approach since they are based on a rule-based expert system. These systems,
however, adopt two-valued logic based reasoning in modeling software processes. In
addition, our emphasis is not to model software processes, but heuristic rules. Our
approach can be integrated with any of these process-programming languages.
The ALMA environment described in [31] models software artifacts. Here, the
development, analysis, documentation and maintenance of software artifacts are supported
during the entire lifecycle. Software artifacts are stored in a project database and are
managed by special tools.
8. Conclusions
Object-oriented methods in general do not provide means to manage alternative solutions
and therefore force the software engineer to select one of the alternatives at every step of
the development process. Eliminating alternatives, however, may result in loss of
information and excessive restriction of the design space. In this paper we proposed a
fuzzy-logic based approach to defer elimination of alternatives. By the help of a simple
method and example, we showed that fuzzy-logic techniques can model alternative
solutions effectively. Further, fuzzy-logic techniques provide a means for the software
engineer to evaluate and select one among the alternatives, if needed. The proposed fuzzy-
logic based method has been implemented in our experimental CASE environment.
Acknowledgments
This work was carried out when the second author visited the University of Twente in 1996
and 1997. We thank Pim van den Broek and Klaas van den Berg for his comments on an
earlier version of this paper.
References
[1] Agavanakis, K., Antonakopoulus, T., and Makios, V.(1995). On Applying Fuzzy Sets in theEvaluation Process of Object-Oriented Supporting CASE Tool. In Proc. of EUROMICRO 95, Como,Italy, pp. 564-570.
[2] Aksit, M., Tekinerdogan, B., Marcelloni, F., and Bergmans, L.(1998). Deriving Object-OrientedFrameworks From Domain Knowledge. In Object-Oriented Frameworks, Fayad, M. and Schmidt, D.(eds), John Wiley & Sons, Inc., New York.
35
[3] Balzer, R.(1991). Tolerating Inconsistency. In Proceedings of 13th International Conference onSoftware Engineering, Austin, Texas, pp. 158-163.
[4] Booch, G.(1991). Object Oriented Design With Applications. The Bejamin/Cummings PublishingCompany, Redwood City, California.
[5] Broekhuizen, P.(1994). FLuent: A fuzzy-Logic User Environment for an Object Oriented Fuzzy LogicReasoning Framework, M.Sc. Thesis, University of Twente, The Netherlands.
[6] Budgen, D.(1994). Software Design, Addison-Wesley.
[7] Chidamber, S.R., and Kemerer, C.F.(1994). A Metrics Suite for Object-Oriented Design. IEEETransactions on Software Engineering, 20 (6), pp. 476-492.
[8] Cugola, G., Di Nitto, E., Fuggetta, A., and Ghezzi, C.(1996). A Framework for FormalizingInconsistencies and Deviations in Human-Centered Systems. ACM Transactions on SoftwareEngineering and Methodology, 5 (3), pp. 191-230.
[9] Finkelstein, A.C.W., Gabbay, D., Hunter, A., Kramer, J., and Nuseibeh, B.(1994). InconsistencyHandling in Multiperspective Specifications. IEEE Transactions on Software Engineer, 20 (8), pp.569-578.
[10] Gonzales, A.J., and Dankel, D.D.(1993). The Engineering of Knowledge-Based Systems. PrenticeHall.
[11] Graham, I.(1994). Object-Oriented Methods, 2nd. Edition, Addison-Wesley.
[12] Heineman, G.T., Keiser, G.E., Barghouti, N. S., and Shaul, B.(1992). Rule-Chaining in Marvel:Dynamic Binding of Parameters. IEEE Expert, 7 (6), pp. 26-82.
[13] Hudson, D.L., Cohen, M.E. and Deedwania, P.C.(1985). Emerge - An Expert System for Chest PainAnalysis. In Approximate Reasoning in Expert Systems, Gupta, M.M., Kandel, A., Bandler, W., andKiszka, J.B. (eds), Elsevier Science Publishers B.V., North-Holland, pp. 705-717.
[14] Hunter, A.(1996). Uncertainty in Information Systems. Mc Graw-Hill.
[15] Hunter, A., and Nuseibeh, B.(1997). Analysing Inconsistent Specifications. In Proceedings of 3rd
International Symposium on Requirements Engineering. IEEE CS Press, Annapolis, USA.
[16] Johnson, R., and Foote, B.(1988). Designing Reusable Classes. Journal of Object-OrientedProgramming. June/July, pp. 23-35.
[17] Junkermann, G., Peuschel, B., Schafer, W. and Wolf, S.(1994). MERLIN: Supporting Cooperation inSoftware Development Through a Knowledge-Based Environment. In Software Processing andTechnology, Finkelstein et al. (eds), John Wiley & Sons, Inc., New York, pp. 103-109.
[18] Kacprzyk, J., Zadrozny, S., and Fedrizzi, M.(1988). An Interactive User-Friendly Decision SupportSystem for Consensus Reaching Based on Fuzzy Logic with Linguistic Quantifiers. In FuzzyComputing, Gupta, M.M. and Yamakawa, T. (eds), Elsevier Science Publishers B.V., North-Holland,pp. 307-322,.
[19] Klir, G. J., and Yuan, B.(1995). Fuzzy sets and fuzzy logic : theory and applications. Prentice Hall,Upper Saddle River, NJ.
[20] Law, W.S., and Antonsson, E.K.(1996). Multi-Dimensional Mapping of Design Imprecision. InProceedings of the 1996 ASME Design Engineering Technical Conference and Computers inEngineering Conference, Irvine, California, pp. 18-22.
[21] Lazzerini, B., and Marcelloni, F.(1998). Some Considerations on Input and Output Partitions toProduce Meaningful Conclusions in Fuzzy Inference. Fuzzy Sets and Systems, North Holland, to bepublished.
[22] Lee, C.C.(1990). Fuzzy Logic in Control Systems: Fuzzy Logic Controller, Part II. IEEE Transactionson Systems, Man, and Cybernetics, 20 (2), pp. 419-435.
[23] Li, H.X., and Yen, V.C.(1995). Fuzzy sets and fuzzy decision-making, CRC Press.
36
[24] Lieberherr, K. (1996). Adaptive Object-Oriented Software: The Demeter Method, PWS PublishingCompany.
[25] Mudri, L., Perny, P., and Chauvel, P.(1994). An Approach to Design Support using Fuzzy Models ofArchitectural Objects. In Artificial Intelligence in Design, Gero, J.S., and Sudweeks, F. (eds.), pp.697-714.
[26] Nuseibeh, B., Kramer, J., and Finkelstein, A.C.W.(1994). A Framework for Expressing theRelationships Between Multiple Views in Requirements Specifications. IEEE Transactions onSoftware Engineer, 20 (10), pp. 760-773.
[27] Rational Rose, url: http://www.rational.com/products/rose/.
[28] Riel, A.(1996). Object Oriented Design Heuristics. Addison-Wesley.
[29] Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F., and Lorensen, W.(1991). Object-OrientedModeling and Design. Prentice-Hall.
[30] Tekinerdogan, B., and Aksit, M.(1998). Modeling Heuristic Rules of Methods. Department ofComputer Science, University of Twente.
[31] Lamsweerde, A. van, Delcourt, B., Delor, E., Schayes, M. and Champagne, R.(1988). GenericLifecycle Support in the Alma Environment. IEEE Transactions on Software Engineering, 14 (6), pp.720-741.
[32] Lamsweerde, A. van, Letier, E., and Ponsard, C.(1997). Leaving Inconsistency. In ICSE’97 Workshopon Living with Inconsistency, http://www.cs.uoregon.edu/~fickas/icse-workshop/.
[33] Yazici, A., George, R., Buckles, B.P., and Petry, F.E.(1992). A survey of conceptual and logical datamodels for uncertainty, In Fuzzy Logic for the Management of Uncertainty, Zadeh, L.A., andKacprzyk, J. (eds), John Wiley & Sons, Inc., pp. 281-295.
[34] Yen, J., and Tiao, W. A.(1997). A Systematic Trade-off Analysis for Conflicting ImpreciseRequirement. In Proc. of the 3rd IEE Symposium on Requirement Engineering, pp. 87-96.
[35] Zadeh, L.A.(1973). Outline of a New Approach to the Analysis of Complex Systems and DecisionProcesses. IEEE Transactions on Systems, Man, and Cybernetics, SMC-3 (1), pp. 28-44.
[36] Zadeh, L.A.(1996). Fuzzy Logic = Computing with Word. IEEE Transactions on Fuzzy Systems, 4 (2),pp. 103-111.
Appendix A. Fuzzy-Logic Based Reasoning
In fuzzy-logic, the concept of vagueness is introduced by the definition of fuzzy set. A fuzzy
set S of a universe of discourse U is characterized by a membership function [ ]1,0: →USµ
which associates with each element y of U a number )y(Sµ in the interval [0,1] which
represents the grade of membership of y in S [35]. Given two fuzzy sets A and B in a
universe of discourse U, some basic operations on fuzzy sets are the following:
yyA AU
/))(1( µ∫ −=¬ ; yyyTBA BAU
/))(),(( µµ∫=∩ ; yyyTBA BAU
/))(),(( µµ∫ ∗=∪
where the integral sign yyU
/)(∫ µ stands for the union of the points y at which )(yµ is
positive and T and ∗T identify a triangular norm and conorm, respectively. A triangular
norm is a function T from ]1,0[]1,0[ × to [0,1] such that the properties of symmetry,
37
associativity and monotonicity, and for ]1,0[∈a the boundary condition T(a,1) = a holds.
Unlike a triangular norm, the boundary condition for a triangular conorm is T*(a,0) = a.
Based on the definition of fuzzy set, the concept of linguistic variables is introduced to
represent languages typically adopted by experts. A linguistic variable is a variable whose
values, called linguistic values, have the form of phrases or sentences in a natural language
[35]. For instance, linguistic variable height might assume the values tall, very tall, more or
less tall, etc.
In contrast with classical logic, for instance in the rule IF X IS A THEN Y IS B, the
propositions X IS A and Y IS B may return values between 0 and 1 rather than Boolean
values. In addition, the implication operator is a fuzzy relation rather than a connective
defined by a truth table. A fuzzy relation R, from a set X to a set Y, is defined as a fuzzy set
of the Cartesian product YX × . R is characterized by a membership function ),( yxRµ and
is expressed by ),/(),( yxyxRYX
R∫×
= µ . Based on this definition a large amount of fuzzy
implication operators have been proposed and their properties have been studied. In
particular, their behavior on generalized modus ponens has widely been analyzed. The
generalized modus ponens is the most used mechanism of fuzzy reasoning.
In its most general form, this extension of the modus ponens may be expressed as:
IF X IS A THEN Y IS BX IS A’
------------------------------Y IS B’
where the conclusion B’ is defined as ))()(),(’(sup)(’ vBuAuATvB fUu ⇒= ∈ , with T a
triangular norm and f⇒ a fuzzy implication operator. The TUu∈sup operator is called
compositional operator and the generalized modus ponens is also named compositional
rule of inference [35]. Notice that the generalized modus ponens allows inferring
conclusions also if the facts, in this case X IS A’, match only approximately the antecedent
part of the rule.
A conclusion is expressed as a fuzzy set. If we are interested in a crisp value, we must
defuzzify the conclusion by a defuzzification strategy. A defuzzification strategy is aimed at
38
producing the crisp value, which best represents the linguistic value. At present, the
commonly used strategies may be described as the mean of maxima and the center of area
[23]. The crisp value produced by the mean of maxima strategy represents the mean value
of the elements, which belong to the fuzzy set characterizing the conclusion with maximum
grade. The center of area strategy produces the center of gravity of the fuzzy set
characterizing the conclusion.
Appendix B. Fuzzy-Logic Based Rules
F(1) Candidate Class Identification:
This rule was defined in section 4.2.
F(2) Redundant Class Elimination:
P1 ← [CandidateClass, id1, (Relevance: V1 ∈ {weakly, slightly, fairly, substantially, strongly})] ∧f
P2 ← [CandidateClass, id2, (Relevance: V2 ∈ {weakly, slightly, fairly, substantially, strongly})] ∧f
P3 ← [InformationEquivalence, id3, (Between: id1 ∈ CandidateClass), (And: id2 ∈CandidateClass), (Relevance: V1 ∈ {weakly, slightly, fairly, substantially, strongly})] ∧f
P4 ← [Descriptive, id4, (More: id1 ∈ CandidateClass), (Than: id2 ∈ CandidateClass),(Relevance: V1 ∈ {weakly, slightly, fairly, substantially, strongly})] ⇒f
P1 ← [Non-RedundantCandidateClass, id5, (Relevance: V1 ∈ {weakly, slightly, fairly, substantially, strongly})]
Here, symbol ∧f represents a fuzzy AND connective. This rule has to be decomposed into
sub-rules and requires a four dimensional representation because it has four input variables.
We present only the sub-rules which are used in the example. Table B-1 shows the sub-
rules when [InformationEquivalence, id3, (Between: id1), (And: id2), (Relevance: strongly)]
∧f [CandidateClass, id2, (Relevance: strongly)]. Further, if [InformationEquivalence, id3,
(Between: id1), (And: id2), (Relevance: weakly)], candidate class P1 is selected as a non-
redundant candidate class with the same relevance value as it had before applying this rule.
39
TABLE B - 1. Relation between the input variables and the result of F(2).
P4 ←Descriptive,Relevance:
P1 ← CandidateClass, Relevance:
P1 ← Non-Redundant
CandidateClass,Relevance:
weakly slightly fairly substantially strongly
weakly weakly weakly weakly weakly weaklyslightly weakly weakly weakly slightly slightlyfairly weakly weakly slightly slightly fairly
substantially weakly slightly slightly fairly substantiallystrongly weakly slightly fairly substantially strongly
F(3) Attribute Identification:
P ← [Entity, id1, (Relevance: V1 ∈ {weakly, slightly, fairly, substantially, strongly}),(Autonomy: V2 ∈ {dependently, partially dependently, fully autonomously})] ⇒f
P ← [Attribute, id2, (Relevance: V3 ∈ {weakly, slightly, fairly, substantially, strongly})]
Table B-2 shows the sub-rules of F(3).
TABLE B - 2. Relation between the input variables and the result of F(3).
P ← Entity, Autonomy:
P ← Entity, Relevance:
P ← Attribute,Relevance:
weakly slightly fairly substantially strongly
fully autonomously weakly weakly weakly weakly slightlypartially dependently weakly slightly slightly fairly fairly
dependently weakly slightly fairly substantially strongly
F(4) Class to Attribute Conversion (conceptual):
P1 ← [Non-RedundantCandidateClass, id1, (Relevance: V1 ∈ {weakly, slightly, fairly, substantially, strongly})] ∧f
P2 ← [Non-RedundantCandidateClass, id2, (Relevance: V2 ∈ {weakly, slightly, fairly, substantially, strongly})] ∧f
P3 ← [Qualification, id3, (Qualifier: id1 ∈ Non-RedundantCandidateClass),(Qualified: id2 ∈ Non-RedundantCandidateClass),(Relevance: V3 ∈ {weakly, slightly, fairly, substantially, strongly})] ⇒f
P1 ← [Attribute, id4, (Relevance: V4 ∈ {weakly, slightly, fairly, substantially, strongly})] ∧f
P1 ← [Class, id5, (Relevance: V5 ∈ {weakly, slightly, fairly, substantially, strongly})]
Table B-3 shows the sub-rules of the rule Candidate Class Attribute Conversion
(conceptual) when [Non-RedundantCandidateClass, id1, (Relevance: strongly})] and the output
artifact is an attribute. When the output artifact is a class, the sub-rules can be obtained by
40
replacing respectively weakly, slightly, fairly, substantially and strongly with strongly,
substantially, fairly, slightly and weakly in the table.
TABLE B - 3. Relation between the input variables and the result of F(4).
P3 ←Qualification,
Relevance:
P2 ← Non-RedundantCandidateClass, Relevance
P1 ←Attribute,
Relevance:
weakly slightly fairly substantially strongly
weakly weakly weakly weakly weakly weakly
slightly weakly weakly weakly slightly slightly
fairly weakly weakly slightly slightly fairly
substantially weakly slightly slightly fairly substantially
strongly weakly slightly fairly substantially strongly
F(5) Aggregation Identification:
P1 ← [Class, id1, (Relevance: V1 ∈ {weakly, slightly, fairly, substantially, strongly})] ∧f
P2 ← [Class, id2, (Relevance: V2 ∈ {weakly, slightly, fairly, substantially, strongly})] ∧f
P3 ← [Containment, id3, (Container: id1 ∈ Class), (Contained: id2 ∈ Class),(Relevance: V3 ∈ {weakly, slightly, fairly, substantially, strongly})] ⇒f
P4 ← [Aggregation, id4, (Aggregator: id1 ∈ Class), (Aggregated: id2 ∈ Class),(Relevance: V4 ∈ {weakly, slightly, fairly, substantially, strongly})]
This rule requires a three dimensional representation because it has three input variables.
Table B-4 shows the sub-rules in case [Class, id2, (Relevance: substantially)].
TABLE B - 4. Relation between the input variables and the result of F(5).
P3 ← Containment,Degree:
P1 ← Class, Relevance:
P4 ←Aggregation,Relevance:
weakly slightly fairly substantially strongly
weakly weakly weakly weakly weakly weakly
slightly weakly weakly weakly slightly slightly
fairly weakly weakly slightly slightly fairly
substantially weakly slightly slightly fairly substantially
strongly weakly slightly fairly substantially substantially
F(6) Inheritance Identification (conceptual):
P1 ← [Class, id1, (Relevance: V1 ∈ {weakly, slightly, fairly, substantially, strongly})] ∧f
P2 ← [Class, id2, (Relevance: V2 ∈ {weakly, slightly, fairly, substantially, strongly})] ∧f
P3 ← [Is-a-kind-of, id3, (General: id1 ∈ Class), (Special: id2 ∈ Class),
41
(Relevance: V3 ∈ {weakly, slightly, fairly, substantially, strongly})] ⇒f
P4 ← [Inheritance, id4, (SuperClass: id1 ∈ Class), (SubClass: id2 ∈ Class),(Relevance: V4 ∈ {weakly, slightly, fairly, substantially, strongly})]
Definition of this rule is similar to F(5); the output values of the sub-rules are the same as
the ones of Table B-4. Here, the rows and columns indicate the degree of a is-a-kind-of
relation between P1 and P2, and the possible relevance values of class P1, respectively.
F(7) Class to Attribute Conversion (functional):
P ← [Class, id1, (OperationCohesion:V1 ∈ {weakly, slightly, fairly, substantially, strongly})]⇒f
P ← [Class, id2, (Relevance:V2 ∈ {weakly, slightly, fairly, substantially, strongly})] ∧f
P ← [Attribute, id3, (Relevance:V3 ∈ {weakly, slightly, fairly, substantially, strongly})]
Tables B-5 and B-6 show the sub-rules of rule F(7) respectively when P indicates a class
and an attribute:
TABLE B - 5. Relation between operation cohesion and class relevance.
P ← Class,OperationCohesion:
weakly slightly fairly substantially strongly
P ← Class,Relevance:
weakly slightly fairly substantially strongly
TABLE B - 6. Relation between operation cohesion and attribute relevance.
P ← Class,OperationCohesion:
weakly slightly fairly substantially strongly
P ← Attribute,Relevance:
strongly substantially fairly slightly weakly
F(8) Inheritance Identification (functional):
P1 ← [Class, id1, (Relevance: V1 ∈ {weakly, slightly, fairly, substantially, strongly})] ∧f
P2 ← [Class, id2, (Relevance: V2 ∈ {weakly, slightly, fairly, substantially, strongly})] ∧f
P3 ← [OperationSubset, id3, (SubSet: id1 ∈ Class), (SuperSet: id2 ∈ Class),(Degree: V3 ∈ {roughly, partially, fully})] ⇒f
P4 ← [Inheritance, id4, (SuperClass: id1 ∈ Class), (SubClass: id2 ∈ Class),(Relevance: V4 ∈ {weakly, slightly, fairly, substantially, strongly})]
This rule requires a three dimensional representation because it has three input variables.
Table B-7 shows the sub-rules when [Class, id2, (Relevance: Substantially)].
42
TABLE B - 7. Relation between the input variables and the result of F(8).
P3 ← OperationSubset, Degree:
P1 ← Class, Relevance:
P4 ←Inheritance,Relevance:
weakly slightly fairly substantially strongly
roughly weakly weakly weakly weakly weaklypartially weakly weakly slightly slightly fairly
fully weakly slightly fairly fairly substantially