Deferring Elimination of Design Alternatives in Object- Oriented Methods

Save this PDF as:
 WORD  PNG  TXT  JPG

Size: px
Start display at page:

Download "Deferring Elimination of Design Alternatives in Object- Oriented Methods"

Transcription

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Automating Software Development Process Using Fuzzy Logic

Automating Software Development Process Using Fuzzy Logic Automating Software Development Process Using Fuzzy Logic Francesco Marcelloni 1 and Mehmet Aksit 2 1 Dipartimento di Ingegneria dell Informazione, University of Pisa, Via Diotisalvi, 2-56122, Pisa, Italy,

More information

USE OF FUZZY LOGIC IN SOFTWARE DEVELOPMENT

USE OF FUZZY LOGIC IN SOFTWARE DEVELOPMENT USE OF FUZZY LOGIC IN SOFTWARE DEVELOPMENT Shradhanand, shardha_nand@yahoo.co.in, NSIT(Formerly Delhi Institute of Technology) Amarjeet Kaur, uppalz_amar@yahoo.com, NSIT(Formerly Delhi Institute of Technology)

More information

Fuzzy Implication Rules. Adnan Yazıcı Dept. of Computer Engineering, Middle East Technical University Ankara/Turkey

Fuzzy Implication Rules. Adnan Yazıcı Dept. of Computer Engineering, Middle East Technical University Ankara/Turkey Fuzzy Implication Rules Adnan Yazıcı Dept. of Computer Engineering, Middle East Technical University Ankara/Turkey Fuzzy If-Then Rules Remember: The difference between the semantics of fuzzy mapping rules

More information

LAB 3: Introduction to Domain Modeling and Class Diagram

LAB 3: Introduction to Domain Modeling and Class Diagram LAB 3: Introduction to Domain Modeling and Class Diagram OBJECTIVES Use the UML notation to represent classes and their properties. Perform domain analysis to develop domain class models. Model the structural

More information

Consistency in Multi-Viewpoint Architectural Design of Enterprise Information Systems

Consistency in Multi-Viewpoint Architectural Design of Enterprise Information Systems Consistency in Multi-Viewpoint Architectural Design of Enterprise Information Systems Remco M. Dijkman 1,2, Dick A.C. Quartel 2, Marten J. van Sinderen 2 1 Eindhoven University of Technology, Eindhoven,

More information

Robust Object Oriented System Analysis

Robust Object Oriented System Analysis Robust Object Oriented System Analysis Dr Jie Zhao, Dunstan Thomas Consulting Summary Uses cases are widely accepted as the best approach to capturing system requirements, in particular, functional requirements.

More information

The Language of Mathematics

The Language of Mathematics CHPTER 2 The Language of Mathematics 2.1. Set Theory 2.1.1. Sets. set is a collection of objects, called elements of the set. set can be represented by listing its elements between braces: = {1, 2, 3,

More information

DATABASE DESIGN. - Developing database and information systems is performed using a development lifecycle, which consists of a series of steps.

DATABASE DESIGN. - Developing database and information systems is performed using a development lifecycle, which consists of a series of steps. DATABASE DESIGN - The ability to design databases and associated applications is critical to the success of the modern enterprise. - Database design requires understanding both the operational and business

More information

Chapter 8 The Enhanced Entity- Relationship (EER) Model

Chapter 8 The Enhanced Entity- Relationship (EER) Model Chapter 8 The Enhanced Entity- Relationship (EER) Model Copyright 2011 Pearson Education, Inc. Publishing as Pearson Addison-Wesley Chapter 8 Outline Subclasses, Superclasses, and Inheritance Specialization

More information

Case studies: Outline. Requirement Engineering. Case Study: Automated Banking System. UML and Case Studies ITNP090 - Object Oriented Software Design

Case studies: Outline. Requirement Engineering. Case Study: Automated Banking System. UML and Case Studies ITNP090 - Object Oriented Software Design I. Automated Banking System Case studies: Outline Requirements Engineering: OO and incremental software development 1. case study: withdraw money a. use cases b. identifying class/object (class diagram)

More information

Data Modeling Basics

Data Modeling Basics Information Technology Standard Commonwealth of Pennsylvania Governor's Office of Administration/Office for Information Technology STD Number: STD-INF003B STD Title: Data Modeling Basics Issued by: Deputy

More information

COMP 378 Database Systems Notes for Chapter 7 of Database System Concepts Database Design and the Entity-Relationship Model

COMP 378 Database Systems Notes for Chapter 7 of Database System Concepts Database Design and the Entity-Relationship Model COMP 378 Database Systems Notes for Chapter 7 of Database System Concepts Database Design and the Entity-Relationship Model The entity-relationship (E-R) model is a a data model in which information stored

More information

Chapter 2: Entity-Relationship Model. Entity Sets. " Example: specific person, company, event, plant

Chapter 2: Entity-Relationship Model. Entity Sets.  Example: specific person, company, event, plant Chapter 2: Entity-Relationship Model! Entity Sets! Relationship Sets! Design Issues! Mapping Constraints! Keys! E-R Diagram! Extended E-R Features! Design of an E-R Database Schema! Reduction of an E-R

More information

The Entity-Relationship Model. Steps in Database Design

The Entity-Relationship Model. Steps in Database Design The Entity-Relationship Model Steps in Database Design 1) Requirement Analysis Identify the data that needs to be stored data requirements Identify the operations that need to be executed on the data functional

More information

A SYSTEMATIC APPROACH FOR COMPONENT-BASED SOFTWARE DEVELOPMENT

A SYSTEMATIC APPROACH FOR COMPONENT-BASED SOFTWARE DEVELOPMENT A SYSTEMATIC APPROACH FOR COMPONENT-BASED SOFTWARE DEVELOPMENT Cléver Ricardo Guareis de Farias, Marten van Sinderen and Luís Ferreira Pires Centre for Telematics and Information Technology (CTIT) PO Box

More information

Software Design. Design (I) Software Design Data Design. Relationships between the Analysis Model and the Design Model

Software Design. Design (I) Software Design Data Design. Relationships between the Analysis Model and the Design Model Software Design Design (I) Software Design is a process through which requirements are translated into a representation of software. Peter Lo CS213 Peter Lo 2005 1 CS213 Peter Lo 2005 2 Relationships between

More information

Software Engineering. System Models. Based on Software Engineering, 7 th Edition by Ian Sommerville

Software Engineering. System Models. Based on Software Engineering, 7 th Edition by Ian Sommerville Software Engineering System Models Based on Software Engineering, 7 th Edition by Ian Sommerville Objectives To explain why the context of a system should be modeled as part of the RE process To describe

More information

V3 Technical Editorial Services. For HL7 Contract Work Announcement V3 Technical Editor

V3 Technical Editorial Services. For HL7 Contract Work Announcement V3 Technical Editor 1 1 1 1 1 1 1 1 0 1 0 1 V Technical Editorial Services For HL Contract Work Announcement V Technical Editor RIM Document Editorial Assessment June 00 Ockham Information Services LLC 0 Adams Street Decatur,

More information

Chapter 10 Practical Database Design Methodology and Use of UML Diagrams

Chapter 10 Practical Database Design Methodology and Use of UML Diagrams Chapter 10 Practical Database Design Methodology and Use of UML Diagrams Copyright 2011 Pearson Education, Inc. Publishing as Pearson Addison-Wesley Chapter 10 Outline The Role of Information Systems in

More information

Object Oriented Design

Object Oriented Design Object Oriented Design Kenneth M. Anderson Lecture 20 CSCI 5828: Foundations of Software Engineering OO Design 1 Object-Oriented Design Traditional procedural systems separate data and procedures, and

More information

Questions? Assignment. Techniques for Gathering Requirements. Gathering and Analysing Requirements

Questions? Assignment. Techniques for Gathering Requirements. Gathering and Analysing Requirements Questions? Assignment Why is proper project management important? What is goal of domain analysis? What is the difference between functional and non- functional requirements? Why is it important for requirements

More information

Johannes Sametinger. C. Doppler Laboratory for Software Engineering Johannes Kepler University of Linz A-4040 Linz, Austria

Johannes Sametinger. C. Doppler Laboratory for Software Engineering Johannes Kepler University of Linz A-4040 Linz, Austria OBJECT-ORIENTED DOCUMENTATION C. Doppler Laboratory for Software Engineering Johannes Kepler University of Linz A-4040 Linz, Austria Abstract Object-oriented programming improves the reusability of software

More information

A Workbench for Prototyping XML Data Exchange (extended abstract)

A Workbench for Prototyping XML Data Exchange (extended abstract) A Workbench for Prototyping XML Data Exchange (extended abstract) Renzo Orsini and Augusto Celentano Università Ca Foscari di Venezia, Dipartimento di Informatica via Torino 155, 30172 Mestre (VE), Italy

More information

Unit 2.1. Data Analysis 1 - V2.0 1. Data Analysis 1. Dr Gordon Russell, Copyright @ Napier University

Unit 2.1. Data Analysis 1 - V2.0 1. Data Analysis 1. Dr Gordon Russell, Copyright @ Napier University Data Analysis 1 Unit 2.1 Data Analysis 1 - V2.0 1 Entity Relationship Modelling Overview Database Analysis Life Cycle Components of an Entity Relationship Diagram What is a relationship? Entities, attributes,

More information

Using UML Part One Structural Modeling Diagrams

Using UML Part One Structural Modeling Diagrams UML Tutorials Using UML Part One Structural Modeling Diagrams by Sparx Systems All material Sparx Systems 2007 Sparx Systems 2007 Page 1 Trademarks Object Management Group, OMG, Unified Modeling Language,

More information

Extending the Sugiyama Algorithm for Drawing. UML Class Diagrams: Towards Automatic. Layout of Object-Oriented Software Diagrams.

Extending the Sugiyama Algorithm for Drawing. UML Class Diagrams: Towards Automatic. Layout of Object-Oriented Software Diagrams. Extending the Sugiyama Algorithm for Drawing UML Class Diagrams: Towards Automatic Layout of Object-Oriented Software Diagrams Jochen Seemann Institut fur Informatik, Am Hubland, 97074 Wurzburg, seemann@informatik.uni-wuerzburg.de

More information

Generation of Website Templates Based on UML Modeling

Generation of Website Templates Based on UML Modeling Generation of Website Templates Based on UML Modeling Wesley Harris, Department of English Bogdan D. Czejdo, Department of Mathematics and Computer Science Loyola University New Orleans, LA, 70118 Abstract

More information

Rose/Architect: a tool to visualize architecture

Rose/Architect: a tool to visualize architecture Published in the Proceedings of the 32 nd Annual Hawaii International Conference on Systems Sciences (HICSS 99) Rose/Architect: a tool to visualize architecture Alexander Egyed University of Southern California

More information

NRS Business Process Standards and Guidelines using BPMN

NRS Business Process Standards and Guidelines using BPMN Corporate Services for the Natural Resource Sector Information Management Branch NRS Business Process Standards and Guidelines using BPMN Last Updated: June 21, 2016 Version: 1.0.1 Document: NRS Business

More information

In this Lecture you will Learn: Systems Development Methodologies. Why Methodology? Why Methodology?

In this Lecture you will Learn: Systems Development Methodologies. Why Methodology? Why Methodology? In this Lecture you will Learn: Systems Development Methodologies What a systems development methodology is Why methodologies are used The need for different methodologies The main features of one methodology

More information

Introduction to Fuzzy Control

Introduction to Fuzzy Control Introduction to Fuzzy Control Marcelo Godoy Simoes Colorado School of Mines Engineering Division 1610 Illinois Street Golden, Colorado 80401-1887 USA Abstract In the last few years the applications of

More information

GOAL-BASED INTELLIGENT AGENTS

GOAL-BASED INTELLIGENT AGENTS International Journal of Information Technology, Vol. 9 No. 1 GOAL-BASED INTELLIGENT AGENTS Zhiqi Shen, Robert Gay and Xuehong Tao ICIS, School of EEE, Nanyang Technological University, Singapore 639798

More information

Chapter 3. Cartesian Products and Relations. 3.1 Cartesian Products

Chapter 3. Cartesian Products and Relations. 3.1 Cartesian Products Chapter 3 Cartesian Products and Relations The material in this chapter is the first real encounter with abstraction. Relations are very general thing they are a special type of subset. After introducing

More information

Object Oriented Software Models

Object Oriented Software Models Software Engineering CSC 342/ Dr Ghazy Assassa Page 1 Object Oriented Software Models Use case diagram and use case description 1. Draw a use case diagram for a student-course-registration system. Show

More information

DEVELOPMENT OF FUZZY LOGIC MODEL FOR LEADERSHIP COMPETENCIES ASSESSMENT CASE STUDY: KHOUZESTAN STEEL COMPANY

DEVELOPMENT OF FUZZY LOGIC MODEL FOR LEADERSHIP COMPETENCIES ASSESSMENT CASE STUDY: KHOUZESTAN STEEL COMPANY DEVELOPMENT OF FUZZY LOGIC MODEL FOR LEADERSHIP COMPETENCIES ASSESSMENT CASE STUDY: KHOUZESTAN STEEL COMPANY 1 MOHAMMAD-ALI AFSHARKAZEMI, 2 DARIUSH GHOLAMZADEH, 3 AZADEH TAHVILDAR KHAZANEH 1 Department

More information

BUSINESS RULES AND GAP ANALYSIS

BUSINESS RULES AND GAP ANALYSIS Leading the Evolution WHITE PAPER BUSINESS RULES AND GAP ANALYSIS Discovery and management of business rules avoids business disruptions WHITE PAPER BUSINESS RULES AND GAP ANALYSIS Business Situation More

More information

Foundations of Business Intelligence: Databases and Information Management

Foundations of Business Intelligence: Databases and Information Management Foundations of Business Intelligence: Databases and Information Management Content Problems of managing data resources in a traditional file environment Capabilities and value of a database management

More information

CSC 742 Database Management Systems

CSC 742 Database Management Systems CSC 742 Database Management Systems Topic #4: Data Modeling Spring 2002 CSC 742: DBMS by Dr. Peng Ning 1 Phases of Database Design Requirement Collection/Analysis Functional Requirements Functional Analysis

More information

AGILE METHODOLOGY AND SOFTWARE REUSE A COMMON APPROCH TO SOFTWARE DEVELOPMENT

AGILE METHODOLOGY AND SOFTWARE REUSE A COMMON APPROCH TO SOFTWARE DEVELOPMENT AGILE METHODOLOGY AND SOFTWARE REUSE A COMMON APPROCH TO SOFTWARE DEVELOPMENT Manjot Singh Ahuja, Neha Sadana CSE Department Shivalik Institute of Engineering and Technology, Aliyaspur, Haryana, India

More information

A FUZZY LOGIC APPROACH FOR SALES FORECASTING

A FUZZY LOGIC APPROACH FOR SALES FORECASTING A FUZZY LOGIC APPROACH FOR SALES FORECASTING ABSTRACT Sales forecasting proved to be very important in marketing where managers need to learn from historical data. Many methods have become available for

More information

Modern Systems Analysis and Design

Modern Systems Analysis and Design Modern Systems Analysis and Design Prof. David Gadish Structuring System Data Requirements Learning Objectives Concisely define each of the following key data modeling terms: entity type, attribute, multivalued

More information

Visualizing Relationships and Connections in Complex Data Using Network Diagrams in SAS Visual Analytics

Visualizing Relationships and Connections in Complex Data Using Network Diagrams in SAS Visual Analytics Paper 3323-2015 Visualizing Relationships and Connections in Complex Data Using Network Diagrams in SAS Visual Analytics ABSTRACT Stephen Overton, Ben Zenick, Zencos Consulting Network diagrams in SAS

More information

Chapter 10 Practical Database Design Methodology and Use of UML Diagrams

Chapter 10 Practical Database Design Methodology and Use of UML Diagrams Chapter 10 Practical Database Design Methodology and Use of UML Diagrams Copyright 2011 Pearson Education, Inc. Publishing as Pearson Addison-Wesley Chapter 10 Outline The Role of Information Systems in

More information

INTERNATIONAL JOURNAL FOR ENGINEERING APPLICATIONS AND TECHNOLOGY. Ameet.D.Shah 1, Dr.S.A.Ladhake 2. ameetshah1981@gmail.com

INTERNATIONAL JOURNAL FOR ENGINEERING APPLICATIONS AND TECHNOLOGY. Ameet.D.Shah 1, Dr.S.A.Ladhake 2. ameetshah1981@gmail.com IJFEAT INTERNATIONAL JOURNAL FOR ENGINEERING APPLICATIONS AND TECHNOLOGY Multi User feedback System based on performance and Appraisal using Fuzzy logic decision support system Ameet.D.Shah 1, Dr.S.A.Ladhake

More information

Baseline Code Analysis Using McCabe IQ

Baseline Code Analysis Using McCabe IQ White Paper Table of Contents What is Baseline Code Analysis?.....2 Importance of Baseline Code Analysis...2 The Objectives of Baseline Code Analysis...4 Best Practices for Baseline Code Analysis...4 Challenges

More information

Database Design. October 24, 2008. Database Design

Database Design. October 24, 2008. Database Design October 24, 2008 Outline E-R diagrams Represent logical structure simply, clearly Rectangles: entity sets Ellipses: attributes Diamonds: relationship sets Lines: linking elements Double ellipse: multi-valued

More information

Sudoku puzzles and how to solve them

Sudoku puzzles and how to solve them Sudoku puzzles and how to solve them Andries E. Brouwer 2006-05-31 1 Sudoku Figure 1: Two puzzles the second one is difficult A Sudoku puzzle (of classical type ) consists of a 9-by-9 matrix partitioned

More information

Collated Food Requirements. Received orders. Resolved orders. 4 Check for discrepancies * Unmatched orders

Collated Food Requirements. Received orders. Resolved orders. 4 Check for discrepancies * Unmatched orders Introduction to Data Flow Diagrams What are Data Flow Diagrams? Data Flow Diagrams (DFDs) model that perspective of the system that is most readily understood by users the flow of information around the

More information

Why & How: Business Data Modelling. It should be a requirement of the job that business analysts document process AND data requirements

Why & How: Business Data Modelling. It should be a requirement of the job that business analysts document process AND data requirements Introduction It should be a requirement of the job that business analysts document process AND data requirements Process create, read, update and delete data they manipulate data. Process that aren t manipulating

More information

GRASP Design Principles. By Danya Rao

GRASP Design Principles. By Danya Rao GRASP Design Principles By Danya Rao GRASP stands for General Responsibility Assignment Software Patterns guides in assigning responsibilities to collaborating objects. 9 GRASP patterns Creator Information

More information

1 Class Diagrams and Entity Relationship Diagrams (ERD)

1 Class Diagrams and Entity Relationship Diagrams (ERD) 1 Class Diagrams and Entity Relationship Diagrams (ERD) Class diagrams and ERDs both model the structure of a system. Class diagrams represent the dynamic aspects of a system: both the structural and behavioural

More information

3. Mathematical Induction

3. Mathematical Induction 3. MATHEMATICAL INDUCTION 83 3. Mathematical Induction 3.1. First Principle of Mathematical Induction. Let P (n) be a predicate with domain of discourse (over) the natural numbers N = {0, 1,,...}. If (1)

More information

Consistency in multi-viewpoint design of enterprise information systems

Consistency in multi-viewpoint design of enterprise information systems Information and Software Technology xxx (2007) xxx xxx www.elsevier.com/locate/infsof Consistency in multi-viewpoint design of enterprise information systems Remco M. Dijkman a,b,, Dick A.C. Quartel b,

More information

Formal Languages and Automata Theory - Regular Expressions and Finite Automata -

Formal Languages and Automata Theory - Regular Expressions and Finite Automata - Formal Languages and Automata Theory - Regular Expressions and Finite Automata - Samarjit Chakraborty Computer Engineering and Networks Laboratory Swiss Federal Institute of Technology (ETH) Zürich March

More information

Likewise, we have contradictions: formulas that can only be false, e.g. (p p).

Likewise, we have contradictions: formulas that can only be false, e.g. (p p). CHAPTER 4. STATEMENT LOGIC 59 The rightmost column of this truth table contains instances of T and instances of F. Notice that there are no degrees of contingency. If both values are possible, the formula

More information

A Business Process Services Portal

A Business Process Services Portal A Business Process Services Portal IBM Research Report RZ 3782 Cédric Favre 1, Zohar Feldman 3, Beat Gfeller 1, Thomas Gschwind 1, Jana Koehler 1, Jochen M. Küster 1, Oleksandr Maistrenko 1, Alexandru

More information

Managing Variability in Software Architectures 1 Felix Bachmann*

Managing Variability in Software Architectures 1 Felix Bachmann* Managing Variability in Software Architectures Felix Bachmann* Carnegie Bosch Institute Carnegie Mellon University Pittsburgh, Pa 523, USA fb@sei.cmu.edu Len Bass Software Engineering Institute Carnegie

More information

A FUZZY BASED APPROACH TO TEXT MINING AND DOCUMENT CLUSTERING

A FUZZY BASED APPROACH TO TEXT MINING AND DOCUMENT CLUSTERING A FUZZY BASED APPROACH TO TEXT MINING AND DOCUMENT CLUSTERING Sumit Goswami 1 and Mayank Singh Shishodia 2 1 Indian Institute of Technology-Kharagpur, Kharagpur, India sumit_13@yahoo.com 2 School of Computer

More information

Software Engineering Prof. N.L. Sarda Computer Science & Engineering Indian Institute of Technology, Bombay Lecture-4 Overview of Phases (Part - II)

Software Engineering Prof. N.L. Sarda Computer Science & Engineering Indian Institute of Technology, Bombay Lecture-4 Overview of Phases (Part - II) Software Engineering Prof. N.L. Sarda Computer Science & Engineering Indian Institute of Technology, Bombay Lecture-4 Overview of Phases (Part - II) We studied the problem definition phase, with which

More information

Chapter 3. Data Flow Diagrams

Chapter 3. Data Flow Diagrams Chapter 3. Data Flow Diagrams Table of Contents Objectives... 1 Introduction to Data Flow Diagrams... 2 What are Data Flow Diagrams?... 2 An example Data Flow Diagram... 2 The benefits of Data Flow Diagrams...

More information

Five High Order Thinking Skills

Five High Order Thinking Skills Five High Order Introduction The high technology like computers and calculators has profoundly changed the world of mathematics education. It is not only what aspects of mathematics are essential for learning,

More information

Chapter 6 FOUNDATIONS OF BUSINESS INTELLIGENCE: DATABASES AND INFORMATION MANAGEMENT Learning Objectives

Chapter 6 FOUNDATIONS OF BUSINESS INTELLIGENCE: DATABASES AND INFORMATION MANAGEMENT Learning Objectives Chapter 6 FOUNDATIONS OF BUSINESS INTELLIGENCE: DATABASES AND INFORMATION MANAGEMENT Learning Objectives Describe how the problems of managing data resources in a traditional file environment are solved

More information

Using Dataflow Diagrams. Learning Objectives. Data Flow Diagrams. Major Topics. Basic Symbols. Advantages of the Data Flow Approach 2/17/2008

Using Dataflow Diagrams. Learning Objectives. Data Flow Diagrams. Major Topics. Basic Symbols. Advantages of the Data Flow Approach 2/17/2008 Using Dataflow Systems Analysis and Design, 7e Kendall & Kendall 7 Learning Objectives Comprehend the importance of using logical and physical data flow diagrams (DFDs) to graphically depict movement for

More information

Transaction-Typed Points TTPoints

Transaction-Typed Points TTPoints Transaction-Typed Points TTPoints version: 1.0 Technical Report RA-8/2011 Mirosław Ochodek Institute of Computing Science Poznan University of Technology Project operated within the Foundation for Polish

More information

How to Make a Domain Model. Tutorial

How to Make a Domain Model. Tutorial How to Make a Domain Model Tutorial What is a Domain Model? Illustrates meaningful conceptual classes in problem domain Represents real-world concepts, not software components Software-oriented class diagrams

More information

ONTOLOGIES A short tutorial with references to YAGO Cosmina CROITORU

ONTOLOGIES A short tutorial with references to YAGO Cosmina CROITORU ONTOLOGIES p. 1/40 ONTOLOGIES A short tutorial with references to YAGO Cosmina CROITORU Unlocking the Secrets of the Past: Text Mining for Historical Documents Blockseminar, 21.2.-11.3.2011 ONTOLOGIES

More information

Mathematics for Computer Science

Mathematics for Computer Science Mathematics for Computer Science Lecture 2: Functions and equinumerous sets Areces, Blackburn and Figueira TALARIS team INRIA Nancy Grand Est Contact: patrick.blackburn@loria.fr Course website: http://www.loria.fr/~blackbur/courses/math

More information

RUP Design Workflow. Michael Fourman Cs2 Software Engineering

RUP Design Workflow. Michael Fourman Cs2 Software Engineering RUP Design Workflow Michael Fourman Introduction Design architecture that can meet all requirements Understand non-functional requirements and constraints related to technologies Identify subsystems (overall

More information

Algorithms, Flowcharts & Program Design. ComPro

Algorithms, Flowcharts & Program Design. ComPro Algorithms, Flowcharts & Program Design ComPro Definition Algorithm: o sequence of steps to be performed in order to solve a problem by the computer. Flowchart: o graphical or symbolic representation of

More information

Applications of Methods of Proof

Applications of Methods of Proof CHAPTER 4 Applications of Methods of Proof 1. Set Operations 1.1. Set Operations. The set-theoretic operations, intersection, union, and complementation, defined in Chapter 1.1 Introduction to Sets are

More information

A terminology model approach for defining and managing statistical metadata

A terminology model approach for defining and managing statistical metadata A terminology model approach for defining and managing statistical metadata Comments to : R. Karge (49) 30-6576 2791 mail reinhard.karge@run-software.com Content 1 Introduction... 4 2 Knowledge presentation...

More information

DESIGN AND STRUCTURE OF FUZZY LOGIC USING ADAPTIVE ONLINE LEARNING SYSTEMS

DESIGN AND STRUCTURE OF FUZZY LOGIC USING ADAPTIVE ONLINE LEARNING SYSTEMS Abstract: Fuzzy logic has rapidly become one of the most successful of today s technologies for developing sophisticated control systems. The reason for which is very simple. Fuzzy logic addresses such

More information

Java (12 Weeks) Introduction to Java Programming Language

Java (12 Weeks) Introduction to Java Programming Language Java (12 Weeks) Topic Lecture No. Introduction to Java Programming Language 1 An Introduction to Java o Java as a Programming Platform, The Java "White Paper" Buzzwords, Java and the Internet, A Short

More information

Entity-Relationship Model. Purpose of E/R Model. Entity Sets

Entity-Relationship Model. Purpose of E/R Model. Entity Sets Entity-Relationship Model Diagrams Class hierarchies Weak entity sets 1 Purpose of E/R Model The E/R model allows us to sketch the design of a database informally. Designs are pictures called entityrelationship

More information

Tool Support for Software Variability Management and Product Derivation in Software Product Lines

Tool Support for Software Variability Management and Product Derivation in Software Product Lines Tool Support for Software Variability Management and Product Derivation in Software s Hassan Gomaa 1, Michael E. Shin 2 1 Dept. of Information and Software Engineering, George Mason University, Fairfax,

More information

Umbrello UML Modeller Handbook

Umbrello UML Modeller Handbook 2 Contents 1 Introduction 7 2 UML Basics 8 2.1 About UML......................................... 8 2.2 UML Elements........................................ 9 2.2.1 Use Case Diagram.................................

More information

Course 103402 MIS. Foundations of Business Intelligence

Course 103402 MIS. Foundations of Business Intelligence Oman College of Management and Technology Course 103402 MIS Topic 5 Foundations of Business Intelligence CS/MIS Department Organizing Data in a Traditional File Environment File organization concepts Database:

More information

Database Design and the ER model

Database Design and the ER model Database Design and the ER model 1. Database design Database design: Description of the data environment An abstraction, driven by anticipated applications Database model: A formalism for specifying database

More information

Reusable Knowledge-based Components for Building Software. Applications: A Knowledge Modelling Approach

Reusable Knowledge-based Components for Building Software. Applications: A Knowledge Modelling Approach Reusable Knowledge-based Components for Building Software Applications: A Knowledge Modelling Approach Martin Molina, Jose L. Sierra, Jose Cuena Department of Artificial Intelligence, Technical University

More information

Carroll County Public Schools Elementary Mathematics Instructional Guide (5 th Grade) August-September (12 days) Unit #1 : Geometry

Carroll County Public Schools Elementary Mathematics Instructional Guide (5 th Grade) August-September (12 days) Unit #1 : Geometry Carroll County Public Schools Elementary Mathematics Instructional Guide (5 th Grade) Common Core and Research from the CCSS Progression Documents Geometry Students learn to analyze and relate categories

More information

In mathematics, there are four attainment targets: using and applying mathematics; number and algebra; shape, space and measures, and handling data.

In mathematics, there are four attainment targets: using and applying mathematics; number and algebra; shape, space and measures, and handling data. MATHEMATICS: THE LEVEL DESCRIPTIONS In mathematics, there are four attainment targets: using and applying mathematics; number and algebra; shape, space and measures, and handling data. Attainment target

More information

BCS THE CHARTERED INSTITUTE FOR IT BCS HIGHER EDUCATION QUALIFICATIONS BCS Level 5 Diploma in IT. September 2013 EXAMINERS REPORT

BCS THE CHARTERED INSTITUTE FOR IT BCS HIGHER EDUCATION QUALIFICATIONS BCS Level 5 Diploma in IT. September 2013 EXAMINERS REPORT BCS THE CHARTERED INSTITUTE FOR IT BCS HIGHER EDUCATION QUALIFICATIONS BCS Level 5 Diploma in IT September 2013 EXAMINERS REPORT Systems Analysis and Design Section A General Comments Candidates in general

More information

Lecture 12: Entity Relationship Modelling

Lecture 12: Entity Relationship Modelling Lecture 12: Entity Relationship Modelling The Entity-Relationship Model Entities Relationships Attributes Constraining the instances Cardinalities Identifiers Generalization 2004-5 Steve Easterbrook. This

More information

Chapter 7 Application Protocol Reference Architecture

Chapter 7 Application Protocol Reference Architecture Application Protocol Reference Architecture Chapter 7 Application Protocol Reference Architecture This chapter proposes an alternative reference architecture for application protocols. The proposed reference

More information

Analysis and Design with UML

Analysis and Design with UML Analysis and Design with UML Page 1 Agenda Benefits of Visual Modeling History of the UML Visual Modeling with UML The Rational Iterative Development Process Page 2 What is Visual Modeling? Item Order

More information

Data Analysis 1. SET08104 Database Systems. Copyright @ Napier University

Data Analysis 1. SET08104 Database Systems. Copyright @ Napier University Data Analysis 1 SET08104 Database Systems Copyright @ Napier University Entity Relationship Modelling Overview Database Analysis Life Cycle Components of an Entity Relationship Diagram What is a relationship?

More information

1-04-10 Configuration Management: An Object-Based Method Barbara Dumas

1-04-10 Configuration Management: An Object-Based Method Barbara Dumas 1-04-10 Configuration Management: An Object-Based Method Barbara Dumas Payoff Configuration management (CM) helps an organization maintain an inventory of its software assets. In traditional CM systems,

More information

Classnotes 5: 1. Design and Information Flow A data flow diagram (DFD) is a graphical technique that is used to depict information flow, i.e.

Classnotes 5: 1. Design and Information Flow A data flow diagram (DFD) is a graphical technique that is used to depict information flow, i.e. Classnotes 5: 1. Design and Information Flow A data flow diagram (DFD) is a graphical technique that is used to depict information flow, i.e., a representation of information as a continuous flow that

More information

Database Design Methodology

Database Design Methodology Database Design Methodology Three phases Database Design Methodology Logical database Physical database Constructing a model of the information used in an enterprise on a specific data model but independent

More information

Chapter 10. Practical Database Design Methodology. The Role of Information Systems in Organizations. Practical Database Design Methodology

Chapter 10. Practical Database Design Methodology. The Role of Information Systems in Organizations. Practical Database Design Methodology Chapter 10 Practical Database Design Methodology Practical Database Design Methodology Design methodology Target database managed by some type of database management system Various design methodologies

More information

CHAPTER 2. Set, Whole Numbers, and Numeration

CHAPTER 2. Set, Whole Numbers, and Numeration CHAPTER 2 Set, Whole Numbers, and Numeration 2.1. Sets as a Basis for Whole Numbers A set is a collection of objects, called the elements or members of the set. Three common ways to define sets: (1) A

More information

Modular and Composable Extensions to Smalltalk using Composition Filters

Modular and Composable Extensions to Smalltalk using Composition Filters Modular and Composable Extensions to Smalltalk using Composition Filters Lodewijk Bergmans, Bedir Tekinerdoðan & Mehmet Akþit TRESE Project, Department of Computer Science, University of Twente, P.O. Box

More information

Announcements. HW due today, 2 to grade this week Welcome back from Spring Break!

Announcements. HW due today, 2 to grade this week Welcome back from Spring Break! Announcements HW due today, 2 to grade this week Welcome back from Spring Break! Analysis (Domain) Modeling: Introduction Reading: Arlow and Neustadt chaps. 8, 9 (& 7) Also see Larman Chapter 10 (2 nd

More information

Diagram Definition Third OMG/Eclipse Symposium 25 March 2012

Diagram Definition Third OMG/Eclipse Symposium 25 March 2012 Diagram Definition Third OMG/Eclipse Symposium 25 March 2012 Maged Elaasar, melaasar@ca.ibm.com Senior Software Engineer IBM Rational Modelling Tools Outline The Need for Diagram Definition Existing Diagram

More information

11 November 2015. www.isbe.tue.nl. www.isbe.tue.nl

11 November 2015. www.isbe.tue.nl. www.isbe.tue.nl UML Class Diagrams 11 November 2015 UML Class Diagrams The class diagram provides a static structure of all the classes that exist within the system. Classes are arranged in hierarchies sharing common

More information

Part 1 Foundations of object orientation

Part 1 Foundations of object orientation OFWJ_C01.QXD 2/3/06 2:14 pm Page 1 Part 1 Foundations of object orientation OFWJ_C01.QXD 2/3/06 2:14 pm Page 2 1 OFWJ_C01.QXD 2/3/06 2:14 pm Page 3 CHAPTER 1 Objects and classes Main concepts discussed

More information

Data Modeling. Relationships within the Relational Database:

Data Modeling. Relationships within the Relational Database: Data Modeling Relationships within the Relational Database: A relationship describes association among entities. For example, a relationship exists between customers and an agent, in that an agent can

More information

Object Oriented Programming. Risk Management

Object Oriented Programming. Risk Management Section V: Object Oriented Programming Risk Management In theory, there is no difference between theory and practice. But, in practice, there is. - Jan van de Snepscheut 427 Chapter 21: Unified Modeling

More information

USING UML FOR OBJECT-RELATIONAL DATABASE SYSTEMS DEVELOPMENT: A FRAMEWORK

USING UML FOR OBJECT-RELATIONAL DATABASE SYSTEMS DEVELOPMENT: A FRAMEWORK USING UML FOR OBJECT-RELATIONAL DATABASE SYSTEMS DEVELOPMENT: A FRAMEWORK Ming Wang, California State University, ming.wang@calstatela.edu ABSTRACT Data model of object-relational databases (ORDBs) is

More information

Patterns in. Lecture 2 GoF Design Patterns Creational. Sharif University of Technology. Department of Computer Engineering

Patterns in. Lecture 2 GoF Design Patterns Creational. Sharif University of Technology. Department of Computer Engineering Patterns in Software Engineering Lecturer: Raman Ramsin Lecture 2 GoF Design Patterns Creational 1 GoF Design Patterns Principles Emphasis on flexibility and reuse through decoupling of classes. The underlying

More information