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 designmodels, 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.nlTel: +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