Reducing Quantization Error and Contextual Bias Problems in Object-Oriented Methods by Applying Fuzzy-Logic Techniques

Transcription

1 Reducing Quantization Error and Contextual Bias Problems in Object-Oriented Methods by Applying Fuzzy-Logic Techniques Mehmet Aksit and Francesco Marcelloni TRESE project, Department of Computer Science, University of Twente, P.O. Box 217, 7500 AE Enschede, The Netherlands. www server: Department of Information Engineering, University of Pisa, Via Diotisalvi, , Pisa, Italy. Abstract Object-oriented methods define a considerable number of rules which are generally expressed using two-valued logic. For example, an entity in a requirement specification is either accepted or rejected as a class. There are two major problems how rules are defined and applied in current methods. Firstly, twovalued logic cannot effectively express the approximate and inexact nature of a typical software development process. Secondly, the influence of contextual factors on rules is generally not modeled explicitly. This article terms these problems as quantization error and contextual bias problems, respectively. To reduce these problems, fuzzy-logic techniques are proposed. This approach is method independent and is useful for evaluating and enhancing current methods. In addition, fuzzy-logic based techniques increase the adaptability and reusability of design models. Quantization error and contextual bias problems, and the usefulness of the fuzzy-logic based approach in reducing these problems are illustrated first formally, and then intuitively through a simple example. The fuzzylogic based method is implemented and tested by using our fuzzy-logic based experimental CASE environment. Index terms: Object-oriented methods, fuzzy-logic based reasoning, quantization error, adaptable design models, development environments, reuse Correspondance address: Mehmet Aksit, University of Twente, P.O. Box. 217, 7500 AE, Enschede, The Netherlands. aksit@cs.utwente.nl Fax: Tel:

2 1. Introduction During the last several years, a considerable number of object-oriented methods [5, 9, 15, 21] have been introduced to create robust, reusable and adaptable software systems. Object-oriented methods create software artifacts by exploiting object-oriented concepts 1 through the application of a large number of rules. For example, OMT [21] introduces rules for identifying and discarding classes, associations, part-of and inheritance relations, statetransition and data-flow diagrams. Basically, these rules are based on two-valued logic. For example, a candidate class is generally identified by applying the rule: If an entity in a requirement specification is relevant then select it as a candidate class. We consider two major problems, termed as quantization error and contextual bias problems, in the way how rules are defined and applied in current object-oriented methods. Firstly, two-valued logic does not provide an effective means for capturing the approximate and inexact nature of a typical software development process. For example, to identify a class, the software engineer has to determine whether the entity being considered is relevant or not for the application domain. The software engineer may conclude that the entity partially fulfils the relevance criterion, and may prefer to use expressions like the entity is 70 percent, or substantially relevant. However, two-valued logic forces the software engineer to take abrupt decisions, such as accepting or rejecting the entity as a class. 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. Secondly, the validity of a rule may largely depend on contextual factors such as the application domain, changes in user s interest and technological advances. Unless the contextual factors that influence a given rule are defined explicitly, the applicability of that rule cannot be determined and controlled effectively. This article has three contributions. Firstly, it introduces the notion and mathematical formulation of the quantization error problem which can be used to analyze, compare and improve current object-oriented methods. Secondly, a new fuzzy-logic based objectoriented software development technique is introduced to reduce quantization errors. This technique is not specific to a particular object-oriented method. In addition, the fuzzy-logic based technique increases the adaptability and reusability of design models. Finally, the influence of contextual factors on rules is explicitly modeled and controlled by dynamically adapting the domain of contextual variables. Quantization error and contextual bias problems, and the usefulness of the fuzzy-logic based approach in reducing these problems are illustrated first formally, and then intuitively through a simple example. The fuzzy-logic based method is implemented and tested by using our experimental CASE environment [7]. 1 The term concept refers to the types of software artifacts of object-oriented development process. Typical examples of object-oriented concepts are Class, Object, Association, Part-of relation, Inheritance relation, Attribute, Operation, State-transition diagram. 2

3 This paper is organized as follows. The next section introduces the notion and the formulation of quantization errors in object-oriented methods. Further this section illustrates the quantization error problem by the help of a simple example. Section 3 defines the contextual bias problem. Section 4 identifies the requirements to reduce quantization error and contextual bias problems. Section 5 introduces the fuzzy-logic based software development technique and illustrates its applicability by using a simple example. Evaluation of the approach is presented in section 6. Section 7 summarizes the related work. The future work is described in section 8. Finally, section 9 gives conclusions. 2. The Quantization Error Problem This section defines the quantization error problem in current object-oriented methods. The application of two-valued logic in software development is explained in section 2.1. Most methods adopt this kind of reasoning, generally in an informal way. Section 2.2 explains the quantization error problem in signal processing as an analogy to software development process. Section 2.3 models the quantization error in two-valued logic based methods. An evaluation of the accuracy of the formulas is presented in section 2.4. Section 2.5 illustrates the effect of the quantization error by means of a simple example. 2.1 Two-valued Logic Based Rules Assume that the following rule is used to identify candidate classes: 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, an entity in a requirement specification and a candidate class are the two objectoriented concepts to be reasoned. The term THEN separates the antecedent and the consequent of the rule. The antecedent consists of two conditions composed by the connective AND. Relevant and Autonomously are the input values for the first and second conditions, respectively. In two-valued logic, a consequent is true if its antecedent is true. If the consequent is true, then the result of this rule is the classification of an entity in a requirement specification as a candidate class. For illustration purposes, we will refer to similar rules which are commonly adopted by object-oriented methods. After identifying candidate classes, redundant classes can be eliminated for instance by using rule 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. In general, application of a rule quantizes a set of object-oriented 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 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 rule Redundant Class Elimination. Of course, a rejected entity can be 3

4 considered by another rule which applies to the entities in a requirement specification. Consider, for example, rule 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. This rule can be applied to the entities in a requirement specification which are rejected by 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. 2.2 An Analogy: Quantization Process of a Sampled Signal We think that the quantization process as defined by current methods is problematic and generates a high quantization error. To make this clear, we refer to the area of digital signal processing because quantization errors have been extensively studied in this field [22]. In digital signal processing, the quantization process assigns the amplitudes of a sampled analog signal to a prescribed number of discrete quantization levels. This results in a loss of information because the quantized signal is an approximation of the analog signal. The quantization error is defined as the difference between an analog and the corresponding quantized signal sample. Figure 1(a) shows a sampled signal before the quantization process. The Y axis indicates the amplitude of the signal which varies between 0 and A. The X axis shows the signal samples. In digital signal processing, the X axis typically indicates time. Figure 1(b) shows the signal after the quantization process. Here, there are eight uniformly separated quantization levels. The amplitude of signal samples is approximated to the levels that are considered most appropriate. Signal A Signal A Samples 0 (a) (b) Samples Fig. 1. Quantization process: (a) sampled signal (b) quantized signal. In the following, we will formulate the error in the quantization process of a sampled signal. In the next section, we will use these formulas as a basis to calculate quantization errors in object-oriented methods. The quantization error is directly related to the difference between adjacent discrete amplitude levels. The error can be reduced to any desired grade by choosing the difference between levels small enough. Figure 2 shows an example of a quantization process. Here, A j is the amplitude of level j, and U j and L j are the upper and lower threshold values of level j, respectively. 4

5 Signal A N=A U j A j L j d/2 d/2 ε ε threshold level threshold A= Samples Fig. 2. Quantization error with N quantization levels. Now assume that the amplitude of a signal which varies in the range of uncertainty between L j and U j is approximated to level j. In digital signal processing, the root mean square value of the quantization error is generally considered as a good index to compare different quantization processes. If the amplitude distribution of the signal is known, the root mean square value of the quantization error generated by quantizing the amplitude to a generic level j can be computed by using formula (1): ( ) ( ) da (1) 2 ε j = a A j pd a Output = A j Dj where a is the amplitude of the signal, Dj = Uj Lj is the domain of the signal when the output of the quantization process is A j, pd( a output = Aj) is the probability density function of a conditioned upon the event output of quantization process = A j. Suppose that over a long period of time all possible amplitude values of the signal appear 1 the same number of times. Then, pd( a Output = Aj ) =. Formula (1) then becomes U L U j 2 ε j = ( a A j ) Lj j j 1 U L da 1 = 3 ( U L ) j j j j 3 3 (( Uj Aj) ( Lj Aj) ) Let us assume that N is the number of quantization levels and A is the maximum value of the signal. If the quantization levels are uniformly separated, then the distance d between two adjacent levels is equal to A/(N-1). For each quantization level j, U j - L j is equal to d. Then formula (2) can be reduced to (2) 1 d A ε j = = 3 2 2( N 1) (3) It is clear from (3) that root mean square value of the quantization error decreases with the increase of the number of quantization levels. The global root mean square value of the signal can be computed as 2 ( ε poutput Aj ) N 1 j j= 0 ε = ( = ) (4) where p(output = A j ) is the probability to have A j as output of the quantization process. 5

6 If the amplitude of the signal is uniformly distributed, then ε = ε = j A 2( N 1) Quantization Error in Two-Valued Logic Based Methods In two-valued logic based software development methods, high quantization errors arise from the fact that rules adopt only two quantization levels. For example, rule Candidate Class Identification requires from the software engineer to decide whether an entity in a requirement specification is relevant or not. The software engineer may, however, conclude that an entity partially fulfils the relevance criterion, and may prefer to use expressions like the entity is substantially relevant, or the entity is 70 percent relevant. This is quite similar to the quantization error in signal processing. If we adopt, for instance, Figure 2 in representing the quantization process of object-oriented methods, then the Y axis represents the relevance of an entity and the X axis indicates the entities being considered. We suppose that the relevance can assume values between 0 and 1. If for example, the software engineer concludes that an entity in a requirement specification is 70 percent relevant, then 0.70 has to be approximated to 0 or 1. If 1 is selected, then the value of the quantization error will be 0.3. This means that there is a loss of information about the relevance of the entity. We call this the quantization error problem of object-oriented methods. Assume that if the relevance value is between 0 and 1/2, and 1/2 and 1, it is approximated to 0 and 1, respectively. Suppose that over a long period of time all possible relevance values appear the same number of times. We can compute the root mean square value of relevance by applying formula (3). This computation results in As methods are composed of a set of rules, we are also interested in calculating quantization errors which affect the result of rules. In calculating the quantization error, we suppose that the truth value of a condition varies between 0 (false) and 1 (true), and the truth value of the consequent increases linearly with the increase of the product among the truth values of the conditions. Consider a rule whose antecedent is composed of n conditions. Let c i be the truth value of the condition i and let pd(c 1, c 2,..., c n ) be the joint probability density of c 1, c 2,..., c n. We can calculate the root mean square value of the quantization error when the result is approximated to A j as ε c A 2 j = c Output A j = j Dj ( ) pd( ( )) dc (5) where D j indicates the domain on which the truth values of conditions vary when the result of the rule is A j, and c, pd( c Output = A j ) and dc denote c 1 c 2... c n, pd( c 1 (Output = A j), c 2 (Output = A j),..., c n (Output = Aj)) and dc 1 dc 2... dc n, respectively. Let us suppose that random variables c 1, c 2,..., c n are independent. Then, n pd( c (Output = A j )) = pd( ci ( Output = Aj)). i= 1 6

7 We observe that for most rules the truth values of conditions and consequent increase linearly with the increase of input values and result, respectively. Further, for simplicity, we assume that over a long period of time all possible truth values of the conditions appear the 1 same number of times. Then, pd( ci ( Output = Aj)) =, where i i U i j L i j is the domain Uj Lj of the truth value of condition i when the output is A j [20]. In two-valued logic, the consequent of a rule is true if the conditions in the antecedent of the rule are true. This means that the truth value of the consequent is approximated to 1 when all the conditions have the truth values between 1/2 and 1. In case A j = 1, 1 2 D D D D n 1 = , where D i = [ 1 1 2, 1] is the domain of c i when the output is 1. We can n now compute ε 1 by applying formula (5). Here, pd( c (Output = 1)) = 2. We obtain 7 3 = 2... ( 1) dc = (6) n 2 ε c Formula (6) shows that when the result is quantized to 1 (true), the root mean square value of the quantization error increases with the increase of the number of conditions in a rule and approaches to 1 when n. As an example, let us calculate the root mean square value of the quantization error which affects the result of rule Candidate Class Identification by using formula (6) when an entity is accepted as a candidate class. By substituting n=2 in formula (6), we obtain n n ε 1 = =. 4 It follows that each entity in the requirement specification identified as a candidate class in average matches only the 53.6 percent of the definition of an ideal candidate class. Now, we calculate the quantization error in case A j = 0. Theoretically, if the antecedent of a rule is false, it is not possible to infer that the consequent of the rule is false. Anyway, it can be often appropriate to make use of the closed-world assumption. This assumption means that anything which cannot be inferred as true from the given facts and the available rules is false. We can easily compute ε 0 from formula (5) by considering D0 = D D1, 1 2 where D= D D... D n and D i = [ 01, ]. Thus, 7 1 n 1 = = 0 = 0 = 8 c pd( c Output ) dc c pd( c Output ) dc n 3 1 D D1 1 n (7) 2 ε as pd( c Output = 0) =. 1 1 n 2 7

8 Formula (7) shows that, when the result is quantized to 0 (false), the root mean square value of the quantization error decreases with the increase of the number of conditions in a rule and approaches to 0 when n. As an example, let us calculate the root mean square value of the quantization error which affects the result of rule Candidate Class Identification when an entity is discarded as a candidate class. By substituting n = 2 in formula (7), we obtain ε 0 = Now, we can calculate the global root mean square value of the quantization error which affects the result of a rule by applying formula (4): ε = ε1 p( Output = 1) + ε0 p( Output = 0) = (8) n n 3 2 For instance, the root mean square value of the quantization error which affects the result of rule Candidate Class Identification is ε = Also coupling of rules with multiple conditions affects the quantization error. Consider, for example, rules Rule 1 and Rule 2 whose antecedents are composed by n and m conditions, respectively. Suppose that Rule 1 is coupled to Rule 2, i.e., the consequent of Rule 1 matches a condition of Rule 2. This is like having the antecedent of rule Rule 2 composed by n+m-1 conditions. 2.4 Evaluation of the Accuracy of the Formulas In this section we will evaluate the accuracy of the quantization error formulas from the following five perspectives: effect of quantization errors, validity of the formulas, interpretation of the formulas, effect of quantization policy and possible use of metrics. Effect of quantization errors The formulas presented in the previous section determine the root mean square value of the quantization error. However, they do not indicate that the resulting object-oriented model will have the same percentage of error. The measurement of error in the resulting object model requires detailed semantic analysis of the requirement specification and the object model 2. It is however expected that loss of information will eventually cause errors in the resulting object-oriented model. In section 2.5, a possible effect of the quantization error will be illustrated by using a simple example. Validity of the formulas Formulas (4) and (5) are based on some general assumptions and therefore they are applicable to a large category of rules. Validity of formulas (6), (7) and (8) depends on the assumptions made about the relations between the input value and the truth value of the conditions, and the output value and the truth value of the consequent. In addition, assumptions made about the uniform distribution of the input values also affect these formulas. Obviously, other distribution functions could be used rather than the uniform n n n 2 This issue is not the aim of this paper. 8

9 distribution. Further, since formulas are based on statistical assumptions, their validity increases after a long run and for applications with a large number of entities. We believe that the formulation of the quantization error is particularly useful in analyzing, comparing and for relatively improving methods. For this purpose, we consider that these assumptions are acceptable. Interpretation of the formulas If the coupling between rules is through the accepted subsets, the root mean square value of the quantization error can be computed by formula (6). This formula shows that the error value increases with the increase of number of couplings between rules whose antecedents are composed by two or more conditions and approaches to 1 when this number approaches to. If the coupling occurs always through the rejected subsets, the error value can be computed by formula (7). This formula shows that the error value decreases with the increase of number of couplings between rules whose antecedents are composed by two or more conditions and approaches to 0 when this number approaches to. In most methods, design models are created by classifying artifacts in accepted sets. In this case, the quantization error will increase with the number of couplings. If all the rules reject the entities, then the error will be less, but there will be no object model in the end. Therefore, it may not be meaningful to define object-oriented methods solely based on the quantization error calculations. The objectives of the design method must be considered as the main goal. However, design methods can be improved by reorganizing design rules. For example, it may be better to defer the elimination of an artifact until all the relevant information is collected. In such a way, the elimination is affected by a lower quantization error than an earlier elimination. Another observation is that classifying an entity to a rejected set does not only mean to classify that entity to the level 0, but generally it also means discarding that entity. As a result, the discarded entity cannot be considered anymore by the subsequent rules. Effect of quantization policy In the quantization process of a sampled signal, if a value is between two quantization levels, a quantization policy must be adopted to classify the signal into one of the adjacent levels. If the difference between these levels is too large, then the policy becomes more crucial for the quality of the quantization process. Since two-valued logic based objectoriented methods have two quantization levels, the quantization policy should be as accurate and precise as possible. The quantization policy of a rule is determined by the conditions of the rule which establish a threshold value to quantize object-oriented artifacts into accepted or rejected sets. It is not always easy to define an ideal threshold value especially in the early phases of software development. In addition, during the interpretation of conditions, the software engineer may be requested to provide some information which is already quantized. For instance, in rule Candidate Class Identification, the condition IF AN ENTITY IN A REQUIREMENT SPECIFICATION IS RELEVANT requires from the software engineer to quantize the relevance of an entity as relevant and not relevant. Relevance of an entity depends on the intuition and experience of the software engineer. Since both the threshold value and the response of the software 9

10 engineer may be very subjective, it is a difficult task to define a very accurate and precise quantization policy. In practice, quantization policy can be improved by defining fine-grained dedicated rules for the targeted application domain. Possible use of metrics Using metrics in the conditions of rules may eliminate the necessity to have input quantized by the software engineer. Most object-oriented metrics aim at measuring the artifacts of an object-oriented development process in an objective way. For example, in [6] and [8], a number of metrics are defined to quantify a set of design artifacts such as operation inheritance and coupling. In general, the metrics of an artifact are computed by using a formula and result in numbers. A rule then must establish a threshold value to determine whether the measured artifact is acceptable or not. The quality of metrics and threshold value determine the quality of a quantization policy. A satisfactory metrics-based quantization policy may be too difficult or even impossible to determine. It is very hard to formulate accurate and precise metrics especially for the early phases of software development. Moreover, even if a satisfactory metrics-based quantization policy exists, the result of a rule remains a two-level quantization. 2.5 An Example for Illustrating the Quantization Error Problem To illustrate the quantization error problem in two-valued logic based object-oriented methods, we will first present a simple object-oriented method and then apply it to an example Description of a Simple Object-Oriented Method Our method consists of the following rules: 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. R(2) Redundant Class Elimination: IF TWO CANDIDATE CLASSES EXPRESS THE SAME INFORMATION THEN DISCARD THE LEAST DESCRIPTIVE ONE. 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: IF A CANDIDATE 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: IF CLASS A IS A KIND OF CLASS B, THEN CLASS A INHERITS FROM CLASS B. R(7) Inheritance Modification: IN THE CLASS HIERARCHY, IF THE NUMBER OF IMMEDIATE SUBCLASSES SUBORDINATED TO A CLASS IS LARGER THAN 5, THEN THE INHERITANCE HIERARCHY IS COMPLEX. 10

11 The dependencies between these rules are shown in Figure 3. Fig. 3. The dependencies between the rules of example analysis method. This method takes the requirement specification as input and produces classes, attributes, and inheritance and aggregation relations as output. The method has to evaluate various rules before generating a model. For example, to identify an entity in a requirement specification as a class, the corresponding rules must be evaluated in the following order. First, rule Candidate Class Identification must accept the entity. Second, rules Redundant Class Elimination and Class to Attribute Conversion must reject the entity. To consider an 11

12 entity as an attribute, rule Attribute Identification must accept the entity. An attribute can also be identified by applying rule Class to Attribute Conversion which transforms candidate classes into attributes. To identify aggregation and inheritance relations, the entities involved in these relations must be first accepted as classes. Then, possible contains and is-a-kind-of relations between these classes have to be converted to aggregation and inheritance relations, respectively. Rules R(1) to R(6) are adopted by most object-oriented methods. Rule R(7) is taken from [8]. If this rule concludes that the inheritance hierarchy is complex, then the hierarchy may be modified 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 rule Candidate Class Identification: Graphics-Application, Tool, Graphic-Element, Point, Line, Rectangle, Circle, Square, Coordinate, Reference-Point, Diagonal-Line, Center, Radius and Color. Rule Candidate Class Identification rejects entities Graphics-Application and Tool because they are not considered relevant for the application. 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 rule Attribute Identification. This rule accepts Color as an attribute because Color qualifies the graphic elements, but the rule rejects Graphics-Application and Tools. The following groups of candidate classes express similar information: (Square, Rectangle), (Line, Diagonal-Line, Radius), (Point, Reference-Point, Center). 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. Rule Class to Attribute Conversion 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 rule Aggregation Identification, the following aggregation relations are identified: Line, Rectangle and Circle aggregate Point. Rectangle and Circle aggregate Line. 12

13 Rule Inheritance Identification identifies a candidate inheritance relation between Graphic- Element, and Point, Line, Rectangle and Circle. Rule Inheritance Modification does not affect the inheritance hierarchy. The object diagram of our graphics application is shown in Figure 4 using the OMT notation [21]. Inheritance relation: Graphic-Element Color Point Rectangle Line Circle Coordinate Aggregation relation: Rectangle Circle Line 2 Point Line Point Line Point Fig. 4. The object diagram of the graphics application using the OMT notation Possible Quantization Error Problems in the Example If the software engineer realizes that the resulting object model is not satisfactory, then there are two possible options: improving the model by applying subsequent rules and/or by iterating the process. The application of subsequent rules may not adequately improve the model because of the loss of information due to quantization errors. The iteration of the process still suffers from the quantization error problem. Moreover, managing an iteration remains as a difficult task. In the following section, we evaluate the object model of our graphics application. We focus on the desired changes necessary to improve the model. In particular, two kinds of changes are perceived: reincarnation of eliminated artifacts and conversion of artifacts. Reincarnation of eliminated artifacts Some artifacts which were discarded during the analysis process may be found out to be relevant artifacts in the later phases. Suppose that later in the design process, we realize that sometimes an explicit representation of square shapes may be necessary. For instance, in pattern recognition systems or in tutoring systems used for teaching geometry, it may be desirable to represent square shapes as a class. However, candidate class Square was considered redundant by the quantization process carried out by rule Redundant Class Elimination. Iteration of the process seems to be the only means to identify and reconsider class Square 3. 3 One may claim that an experienced designer should not eliminate Square from the class repository. The purpose of this example is to illustrate the possibility of eliminating artifacts of the object-oriented development which could be considered relevant in the later phases. Since not all the entities in a realistic requirement specification can be 13

14 Conversion of artifacts Application of an object-oriented method classifies entities in a requirement specification into object-oriented concepts such as classes, attributes, operations. During the development process, the software engineer may discover that an entity could have been better classified into a different concept than the current concept. This requires conversion of entities from one concept 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 is classified as an attribute. 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. To do this, the software engineer is forced to convert Color from an attribute to a class and iterate the process starting from rule Candidate Class Identification. Similar problems can occur with relations. Consider, for example, the aggregation relation between classes Rectangle, and Point and Line. By inspecting the interface operations of these classes, one can deduce that Rectangle shares some of its operations with Point and Line. To improve reusability, instead of using an aggregation relation, we could have defined an inheritance relation between Rectangle, and Point and Line 4. In case of inheritance, Point and Line correspond to the reference point and the diagonal line of Rectangle, respectively. In case of aggregation, however, Rectangle has to explicitly declare all the operations of Point and Line, since inheritance provides transitive reuse of the inherited operations whereas aggregated parts are normally encapsulated within the aggregating class. Similar conversions can be applied to other aggregation relations. For example, class Line might inherit from class Point, and class Circle might inherit from classes Point and Line. During the analysis process, the inheritance relation between class Rectangle and classes Point and Line was discarded by the quantization process implemented by rule Inheritance Identification. Again, iteration of the analysis phase is necessary to convert the aggregation relation into inheritance. (or should be) included in the object model, unwanted elimination of artifacts in two-valued logic based methods is, in principle, inevitable; a decision for elimination or acceptance is regularly an intuitive decision. 4 One may claim that conceptually Rectangle must not inherit from Point because Point is-a-part-of Rectangle and Rectangle is-not-a-kind-of Point. While we agree on this statement from a conceptual modeling point of view, such an inheritance relation can be considered valid from a reuse point of view: If a class C 1 includes a part p of class C 2, and if the operations of C 2 are visible at the interface of C 1, then semantically C 1 inherits from C 2. The visibility of the operations of p can be realized in three ways. The first approach is to declare all the operations of C 2 at the interface of C 1. C 1 can then forward the corresponding requests to p of class C 2. This approach is used, for example in the Bridge Pattern [10]. The second approach is to use a delegation mechanism as adopted by the languages Self [23] and Sina [2]. If the whole object delegates to its part, then semantically the whole object inherits from its part. The third option is to consider is-a-part-of relation as a conceptual specification, and use inheritance relation as an implementation of this is-a-part-of relation. Concluding, conversion of relations in two-valued logic based methods will be likely to occur because sometimes part-of relations may be converted to inheritance relations for reusability purposes. Moreover, the semantics of a relation can be context dependent and/or the exact semantics of a relation may not be completely understood at the time when it is defined. 14

15 3. The Contextual Bias Problem Contextual factors may influence validity of the result of a rule in two ways. Firstly, the input of a rule can be largely context dependent. In rule Redundant Class Elimination, for instance, the elimination of a class is based on the perception of the software engineer whether he or she finds a candidate class more descriptive than an equivalent class. Secondly, validity of a rule may largely depend on contextual factors such as application domain, changes in user s interest and technological advances. Assume that in our graphics application, new graphic elements are introduced such as Ellipse, Triangle, Trapezoid. Each graphic element inherits from class Point. However, rule Inheritance Modification advises against this solution because a superclass must not have more than five subclasses. The problem is that the success of this rule heavily depends on the type of application. For example, in graphics applications, it appears natural that many classes inherit directly from class Point. This is because class Point represents a very basic abstraction in a graphic processing system. Using metrics based rules may not eliminate the effects of context either. As some authors indicate [4], metrics must be associated with some interpretation to determine the threshold of a design rule. But this interpretation must be given in a context. Only when the variables which can influence the measure are fixed, the interpretation of the metrics becomes univocal. Otherwise, the result is either an improper interpretation or a large amount of possible interpretations. As an example, let us consider the Chidamber and Kemerer's [8] interpretations of the experimental results obtained by collecting their metrics in two different software organizations. They observe that contingency factors are responsible for some marked differences of the values obtained by the two different samples. But they do not quantify how much and how these factors influence the metrics. We term the effects of context to the development process as the contextual bias problem. 4. Requirements for Reducing Quantization Error and Contextual Bias Problems In section 2.4, it was stated that the quantization error could be reduced by defining finegrained dedicated rules for the targeted application domain. In addition, in this section we propose the following four requirements in reducing the quantization error and contextual bias problems: Increase the number of quantization levels: As shown in section 2, the quantization error can be lowered by increasing the number of quantization levels. Consider, for example, rule R(1) of section 2.5.1: IF AN ENTITY IN A REQUIREMENT SPECIFICATION IS RELEVANT AND CAN EXIST AUTONOMOUSLY IN THE APPLICATION DOMAIN, THEN SELECT IT AS A CANDIDATE CLASS. In two-valued logic based methods, the relevance of an entity can be expressed only as relevant or not relevant. To increase the number of quantization levels, we have to split the range of relevance into more levels such as weakly, slightly, fairly, substantially and strongly relevant. Having more levels decreases the quantization error and makes the method less sensitive to the quantization policy. Avoid early elimination of artifacts: As shown in section 2.5.3, too early elimination of artifacts may cause undesired effects on the resulting object model. Each decision taken 15

16 by a rule is based on the available information up to that phase. For the early phases, there may not be sufficient amount of information available to take abrupt decisions like discarding an entity. Such an abrupt decision must be taken only if there is a sufficient evidence that the entity is indeed irrelevant. In most object-oriented methods, however, each identification process is followed by an elimination process. For example, the OMT method [21] proposes a process that includes class identification and elimination, association identification and elimination, aggregation identification and elimination, and so on. Now, assume that a software engineer discards an entity because it is considered nonrelevant. The discarded entity, however, could have been included as a candidate class, if the software engineer had gathered more information about its structure and operations. During the later phases this would be practically impossible because the discarded entity could not be considered any further. Early elimination of artifacts in two-valued based methods is practically inevitable. Explicit modeling of the influence of the context: To reduce the contextual bias problem, a method must consider the influence of context. Only when the context variables which can influence the result of a rule are fixed, the application of that rule produces reliable results. Quality versus cost: Designing a signal processing system basically deals with finding a trade-off between cost and precision. This enables designers to tune the system architecture with respect to the cost-quality requirements. For example, in practice 128 levels are used for telephone speech transmission, whereas 65,536 levels are used for CD digital audio system. In current object-oriented methods, however, the relation between the cost and quality of a method is not clear. Therefore, unlike digital signal processing systems, there is no leverage for the software engineer to have more quality in expense of higher costs. If the number of quantization levels is increased, then the cost of having multiple levels with respect to the quality of the method must be estimable. 5. Using Fuzzy-Logic in Object-Oriented Methods This section explains the use of fuzzy-logic in object-oriented methods. Section 5.1 defines a model to represent multiple quantization levels. Section 5.2 describes the use of fuzzylogic based rules in object-oriented methods. A formulation of the quantization error in fuzzy-logic based methods is given in section 5.3. Section 5.4 illustrates the applicability of a simple fuzzy-logic based method by using an example. Section 5.5 explains how fuzzylogic based techniques can be used to model the effect of context on rules. 5.1 Multiple Quantization Levels Assume that each concept (artifact type) is defined as [C, (P 1, D 1 ), (P 2, D 2 ),...,(P n, D n )] where C is the concept name, P i is a property of C and D i is the definition domain of P i. An example of a concept is [Entity, (Relevance, {True, False}), (Autonomy, {True, False})]. Here, True and False are the two values that Relevance and Autonomy can assume. A software artifact is an instantiation of its concept and can be expressed as [C, id, (P 1 : V 1 ), (P 2 : 16

17 V 2 ),...,(P n : V n )], where C is the concept of the artifact, id is the unique identifier of the artifact, and V i is a value defined in domain D i of property P i. Artifacts can be also named. In the following example, Rectangle is the name of the artifact: Rectangle [Entity, id, (Relevance: True), (Autonomy: True)] The number of quantization levels can be increased by introducing more values than True and False. For example, the software engineer may select Relevance and Autonomy values from a number of alternatives as illustrated by the following example: [Entity, (Relevance, {Weakly, Slightly, Fairly, Substantially, Strongly}), (Autonomy, {Dependently, Partially Dependently, FullyAutonomously})] To represent multiple levels conveniently, rules defined in section have to be modified. 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 concepts to be reasoned, Relevance and Autonomy are the properties, and relevance value and autonomy value indicate the domains of these properties. Now, assume that relevance value represents the set of values {Weakly, Slightly, Fairly, Substantially, Strongly}, and autonomy value represents the set of values {Dependently, Partially Dependently, Fully Autonomously}. Using these values, rule Candidate Class Identification can be represented in the following way: P [Entity, id 1, (Relevance: V 1 {Weakly, Slightly, Fairly, Substantially, Strongly}), (Autonomy: V 2 {Dependently, Partially Dependently, Fully Autonomously})] P [CandidateClass, id 2, (Relevance: V 3 {Weakly, Slightly, Fairly, Substantially, Strongly})] Here, P and symbol indicate a generic artifact name and the implication operator, respectively. Each combination of relevance and autonomy values of an entity has to be mapped into one of the five candidate class relevance values. This requires in total 3 5= 15 rules. We call these sub-rules. The following is an example of a sub-rule: P [Entity, id 1, (Relevance: Strongly), (Autonomy: Fully Autonomously)] P [CandidateClass, id 2, (Relevance: Strongly)] 5.2 Fuzzy-Logic Based Rules In two-valued logic, each property value corresponds to a crisp (disjoint) set resulting in an abrupt separation of elements between different sets. For example, the relevance values Weakly, Slightly, Fairly, Substantially, Strongly of an entity in requirement specification correspond to crisp sets. One of the major problems of two-valued logic is that it does not provide an effective means for capturing the approximate, inexact nature of the software development process. Consider, for example, rule Inheritance Modification in section P 1 [Class, id 1, (ImmediateSubclasses: V 1 {Low, Medium, High})] P 2 [Inheritance, id 2, (Complexity: V 2 {Low, Medium, High})] This rule has to be decomposed into 3 sub-rules: 17

18 P 1 [Class, id 11, (ImmediateSubclasses: High)] P 2 [Inheritance, id 21, (Complexity: High)] P 1 [Class, id 12, (ImmediateSubclasses: Medium)] P 2 [Inheritance, id 22, (Complexity: Medium)] P 1 [Class, id 13, (ImmediateSubclasses: Low] P 2 [Inheritance, id 23, (Complexity: Low)] It is practically impossible to define crisp boundaries when the number of immediate subclasses is Low, Medium or High. If, for example, we assert that the number of subclasses is High if it is larger than 10, then we should admit that if the number of immediate subclasses is 9, the complexity of inheritance is not High. But a difference of 1 does not look as a distinguishing characteristic. The transition between membership and non-membership appears gradual rather than abrupt. On the other hand, in two-valued logic defining this crisp boundary is necessary because a proposition can be either true or false. Hence, an inheritance hierarchy must be characterized by either Low, Medium or High Complexity. It is therefore worth to investigate other forms of logic than two-valued logic. 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 µ S : U [ 01, ] 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 in S [25]. Based on the definition of fuzzy sets, the concept of linguistic variables is introduced to represent a language typically adopted by a human expert. A linguistic variable is a variable whose values, called linguistic values, have the form of phrases or sentences in a natural language [25]. For instance, property Relevance of an entity in requirement specification can be modeled as a linguistic variable which might assume linguistic values Weakly, Slightly, Fairly, Substantially and Strongly. Each linguistic value is associated with a fuzzy set that represents its meaning. Figure 5 shows a possible definition of these linguistic values. Here, the X and Y axes indicate the entities and their relevance values, respectively. In this figure, each linguistic value is shown as a different line type. Notice that in contrast to crisp sets, linguistic values are defined as partially overlapping membership functions. 18

19 Strongly Substantially Fairly Slightly Weakly Fully Autonomously Partially Dependently Dependently Relevance A 4 = A 3 = A 2 = A 1 = A 0 =0 Entity i Samples Fig. 5. Five linguistic values defined by membership functions. Each membership function is shown as a different line type. For example, Weakly is drawn as a dashed line, Fairly as a solid line, etc. Figure 6 shows the definition of linguistic values Dependently, Partially Dependently, Fully Autonomously of property Autonomy. The X and Y axes indicate the entities and the Autonomy value, respectively. Similar to Figure 5, each membership function is drawn as a different line type. Autonomy Entity i Samples Fig. 6. Membership functions of Dependently, Partially Dependent and Fully Autonomously. Consider the following rule expressed in fuzzy logic: IF X IS A THEN Y IS B, where X and Y are linguistic variables and A and B are linguistic values. The evaluation of this rule may result in intermediate values between 0 and 1 rather than Boolean values 0 or 1. Here, the implication of this rule is a fuzzy relation between the fuzzy sets corresponding to the propositions X IS A and Y IS B, rather than a connective defined by a truth table. If a crisp value is required as a result of a rule, the corresponding fuzzy set has to be defuzzified by using a defuzzification operation. Consider, for example, fuzzy rule Candidate Class Identification: P [Entity, id 1, (Relevance: V 1 {Weakly, Slightly, Fairly, Substantially, Strongly}) (Autonomy: V 2 {Dependently, Partially Dependently, Fully Autonomously})] f P [CandidateClass, id 2, (Relevance: V 3 {Weakly, Slightly, Fairly, Substantially, Strongly})] The definition of linguistic values Weakly, Slightly, Fairly, Substantially, Strongly are shown in Figure 5. The definition of linguistic values Dependently, Partially Dependently, Fully Autonomously are given in Figure 6. The symbol f indicates a fuzzy-implication operator. This rule is composed of 15 fuzzy sub-rules, which are shown by table 1. 19