Hierarchical Dependence Diagram Literature Review for Bachelor of Computing (Honours) Jie G. Qiao Department of software Development Faculty of Computing and Information Technology Monash University Melbourne, Australia Supervisor: Jian Chen August 8, 1996 Table of Contents 1. Introduction 1 2. The BON Method 2 2.1 Overview of the BON Method 2 2.2 BON Modeling Charts 2 2.2.1 System Chart 3 2.2.2 Cluster Chart 4 2.2.3 Class Chart 4 2.3 Typed Class Interfaces 4 2.3.1 Class Interfaces 5 2.3.2 Class Clustering 6 2.4 Static Relations 7 2.4.1 Inheritance Relations 7 Graphical representation of inheritance relations 7 Inheritance relations involving clusters 7 2.4.2 Client Relations 8 Graphical Representation 9 Client relations involving clusters 10 2.5 Discussion 10 3. Unified Method 12 3.1 Overview of the Unified Method 12 3.2 Class Diagram 13 3.2.1 Classes 13 3.2.2 Templates 13 3.2.3 Associations 14 3.2.4 Inheritance 15 3.2.5 Categories 16 3.3 Discussion 17 4. Formal Methods Applied to Reuse 18 4.1 Lower-Level Hierarchy 18 4.2 Higher-Level Hierarchy 19 4.3 Search for Reusable Candidates 19 4.4 Graphical Browser 20 4.5 Discussion 20 5. Hierarchical Dependence Diagram (HDD) 21 5.1 Overview of HDD 21 5.2 Four Levels of HDD 21 5.2.1 The Class Level (level 3) 22 5.2.2 The Cluster Level (Level 2) 23 5.2.3 The Library Level (Level 1) 24 5.2.4 The Platform Level (Level 0) 24 5.3 The HDD Maintenance Algorithms 25 5.3.1 Add A New Class 25 5.3.2 Modify A Class 25 5.3.3 Delete A Class 26 5.4 Design Guidelines of the HDD 26 5.4.1 Reusable Components 27 5.4.2 Hierarchical Independence Design Guidelines 28 5.5 Discussion 29 6. Other Related Works 31 7. Conclusion 32 1. Introduction Higher reusability is regarded as one of the potential benefits provided by the object-oriented paradigm. Reuse can be defined as the ability of using part of components created from the original application in another application (Wasserman 1991). This literature review will be reviewing the reusability in the Object-oriented paradigm. Reuse can be categorized into two aspects: design with reuse and design for reuse. Design with reuse aims to collect as many existing reusable components as possible and make best of their reuse. Whereas, design for reuse aims to produce highly reusable components for future software development. (Chau 1995). This review will be focusing on the design for reuse. There has been existing guidelines used for design for reuse. This review will be emphasizing on the dependencies issues. The two main dependencies are the client/supplier dependency and the inheritance dependency. This review will be discussing the dependence issues addressed in the existing Object-Oriented methodologies, as well as the dependence representations and the dependence analysis in those methodologies. This literature review will be describing in details the BON Method, which presents a set of concepts for modeling object-oriented software, and a set of rules and guidelines to be used in producing the models; the Unified Method, which is developed by Booch and Rumbaugh, used for specifying, visualising and documenting the artefacts of an object-oriented system under development, and representing the unification of the Booch and OMT methods as well as the best ideas from a number of other methodologists; the Formal Methods Applied to Reuse, which is based on formal methods to achieve the classification, organization and retrieval of reusable software components; and the Hierarchical Dependence Diagram, which is based on the hierarchical dependence analysis of the software components, to help the software developers to design the reusable components. Although there have been some existing mechanisms and methodologies supporting reuse, reuse is not as simple as inheritance or association. Care must be taken from the beginning of software development in order to achieve higher reusability. The Hierarchical Dependence Diagram has been approved to be a useful tool providing the design guidelines for the software developers, by means of Hierarchical Dependence Analysis. If the Hierarchical Dependence Diagram is enhanced with more sophisticated analysis measurement, and supporting diagram tool, it can be a very power method for software developers to design high reusable systems. Besides the dependence analysis method should also be useful to other related issues in object-oriented software development such as re-engineering, testing and maintenance. The contents of this literature review are divided into several sections. Section 2 describes the static model of the BON Method. Section 3 describes the Unified Method, followed by section 4 describing the formal Methods Applied to Reuse. Then section 5 describes the Hierarchical Dependence Diagram. Finally, in section 6 some other related works are also discussed. 2. The BON Method 2.1 Overview of the BON Method BON stands for Business Object Notation. It presents a set of concepts for modeling object- oriented software, and a set of rules and guidelines to be used in producing the models. BON focuses on the fundamental elements of analysis and design, and the method is meant to be integrated with and adapted to the various development frameworks and standards that may apply in different organizations (Walden & Nerson 1995). Two main ways to describe a software system are the static and dynamic. Static descriptions show what classes make up the system, how those classes relate to each other, and how they are grouped into clusters. Dynamic descriptions show how the system will behave over time, ie. how objects interact at execution time, how they invoke operations on each other (passing messages), and how those operations change the object status. As this review focuses on design for reuse, we are interested in the static model. Because an object-oriented system is best viewed as a structured collection of classes, and the classes constitute the blueprints specifying the behaviour of each object (class instance) created during a system session. Each object will behave as prescribed by its class. It is the static model that contains formal descriptions of class interfaces, their grouping into clusters as well as client and inheritance relations between them, showing the system structure and reusability. There are two parts in the static model. The first part is a collection of very high-level untyped modeling charts, which can be used in the analysis process to enhance the communication between the domain experts and end users; the second part is a structured description containing fully typed class interfaces and formal specification of software contracts. BON has two variants notation. They are the graphical BON and the textual BON. The graphical BON is intended for use with automatic tool support to convey information. The textual form is intended for communication BON descriptions in environments that lack dedicated BON case tools. The following sections will describe the static model of BON in details. 2.2 BON Modeling Charts There are three types of modeling chart in the static model: system chart cluster chart class chart The layout of the charts look very much like the physical cards, so that the modeling charts can be printed in fixed format as templates and then filled in manually during modeling processes. The information can later be transferred to modeling tools. 2.2.1 System Chart In BON, there is exactly one system chart of each system, containing a brief description of each top-level clusters, each of which contains a number of classes and/or subclusters. BON does not allow classes at the topmost level, so each class belongs to exactly one enclosing cluster. An example of a system chart for a retail banking system is shown in Figure 2.1. SYSTEM RETAIL BANKING SYSTEM Part: 1/1 PURPOSE System keeping track of all the on-line retail banking services and transactions INDEXING author: George Qiao keywords: Banking, Retail Banking Cluster Description Customer and Account Provide services for customers and accounts Lending Provide loan facilities Authority Management Provide various of authorities to banking functions Periodic Process Processes that needs to be performed periodically Figure 2.1 System chart for a retail banking system The header of the chart is separated from its body by a double line. The first row shows the type of the chart (`system' in this case), followed by the system name and the sequence number. The second row has a purpose clause to the left and has an index clause to the right. The index clause contains the author field and the keyword field, which can record the interest properties and can be used for browsing. The body section of the chart shows the top level clusters and their descriptions. CLUSTER CUSTOMER AND ACCOUNT Part: 1/1 PURPOSE Provide services for customers and accounts INDEXING author: George Qiao keywords: Customer, Account Class/(Cluster) Description Customer Customer data and operations performed on the customer Direct Entry Handle transactions with external banks (Account Services) Provide account services CLUSTER ACCOUNT SERVICES Part: 1/1 PURPOSE Provide account services INDEXING cluster: Customer and Account author: George Qiao keywords: Account, Saving, Investment, Loan, Signatory Class/(Cluster) Description Account Root class of Account Saving Account Inherit from Account Class Investment Account Inherit from Account Class Loan Account Inherit from Account Class Signatory A signatory(access) to an account Figure 2.2 Cluster chart 2.2.2 Cluster Chart A Cluster chart contains a brief description of each class and subcluster in the cluster. By convention, classes are list first, followed by the subclusters. In BON, subcluster can be nested to any depth. An example of Cluster Chart is shown in Figure 2.2. The Cluster chart has the same layout and clauses as the system chart. If it is a nested cluster, the Index clause will also contain a cluster clause showing its nearest enclosing cluster, as well as the author and keyword field. 2.2.3 Class Chart The class charts model individual classes. The information in the class charts is the answer of the following questions: Who is the direct parent of this class (inheritance) ? What information can other classes ask from this class (queries) ? What services can this class provide to other classes (command) ? What rules must be obeyed by this class and its clients (constraints) ? An example of class charts is shown in Figure 2.3. The class chart has the similar header layout as the cluster chart, instead of having the purpose clause, the class chart has the TYPE OF OBJECT clause indicating the purpose of the class. The body of the class chart describes the inheritance, queries, commands and constraints of the class. CLASS ACCOUNT Part: 1/1 TYPE OF OBJECT Root class of Account INDEXING cluster: Account Services author: George Qiao keywords: Account Queries Actual Balance, Available Balance, Signatory Commands Deposit, Withdraw, Accrue Interest, Post Interest Constraints Actual Balance >= Available Balance CLASS INVESTMENT ACCOUNT Part: 1/1 TYPE OF OBJECT Root class of Account INDEXING cluster: Account Services author: George Qiao keywords: Investment Account Inherits From Account Queries Term Length, Maturity Date, Maturity Instructions Commands Deposit (Redefined), Change Maturity Instructions, Change Term Length Constraints Actual Balance >= 0 and Available Balance >= 0 Figure 2.3 Class Charts 2.3 Typed Class Interfaces Using modeling charts is good for analysis, particularly when non-technical people are involved, but the analyst/designer will soon need something more expressive. This leads us to the main part of BON: the structured static diagrams with typing and software contracts. Class interfaces will be described first, followed by the class clustering. Static relations will be discussed last. 2.3.1 Class Interfaces A Class Interface consists of following sections, some of which are optional: Class header Indexing clause Inheritance clause Class features Class invariant Class interfaces may be described either textually or graphically. Each graphical class interface can have two representations: one expanded form and one compressed form. Figure 2.4 shows an example of an expanded version of class interface. Except the class header, each section in the class interface may be compressed (empty or not), which means they may be hidden. Depending on the level of details you want to view, you can compress or expand each section as you wish. For instance, the indexing section is usually hidden unless explicitly requested. The whole class interface may also be compressed. In this case, it is represented by its header enclosed in an ellipse. Refer to Walden & Nerson (1995) for detailed notations of compress class headers. CLASS_NAME Indexing information Inherits: PARENT CLASSES Public features A, B, C Features only visible to classes A, B, C Invariant Class invariant Figure 2.4 Class interface: expanded sections The class header consists of the class name. The indexing clause contains general information about a class to be used for browsing and configuration management purposes. Figure 2.5 shows an example of Indexing Clause of class Saving Account. The inheritance clause lists all the direct parent classes. It should be consistent to the "Inherits from" entry in the class modeling chart. Class Features are grouped into public features and restricted features. Public features are visible to any other classes, where restricted features are only visible to a group of other classes. Restricted features are normally implementation oriented, so those features are provided to other classes whose implementation are depending on them. synonyms: Deposit Account application_domain: Retail Banking Transactions author: George Qiao version: 1.1 revision_date: 18/07/1996 keywords: deposit, withdrawal, cheque, interest Figure 2.5 Indexing clause for a SAVING ACCOUNT class Class invariant clause specifies the consistency constraints for the whole class as an abstraction. They must always be satisfied both before a visible feature is called by a client and after feature execution, just before returning to the client. 2.3.2 Class Clustering A cluster represents a group of related classes and sub-clusters according to certain criteria. Possible criteria are subsystem functionality, user categories, application-domain-dependent factors, reuse versus new development, hardware or software platforms, license restrictions versus public domain, abstraction level, and cohesion grouping or factorization. The system group all the classes into clusters, and in BON, every class must belong to one and only one cluster. Different group criteria may be used for different clusters in one system. ie. Some clusters may represent the subsystem, and some clusters may represent a functionality, etc. In BON, one cluster can also contain nested subclusters. This makes it possible to group classes that are reusable locally. The nested clusters can go any depth, which allows to layer very large systems before any classes appear. Graphically, a cluster is drawn as a box with the name in a separate box (the cluster tag). Figure 2.6 shows an example of a cluster containing a nested cluster. Figure 2.6 A nested data structure cluster 2.4 Static Relations BON has two kinds of relations in the static model. They are the Inheritance Relations and the Client Relations. By combining them in various ways and letting the resulting network of classes be guided by well-defined software contracts, almost any type of semantic modeling needed can be achieved. 2.4.1 Inheritance Relations A class may inherit from one or more parent classes. Through inheritance, the child class can access all the features and services that are available in the parent classes, so as to achieve the reusability. Graphical representation of inheritance relations Graphically, inheritance is represented by a solid line pointing from the child to the parent. This is called an inheritance link. Figure 2.7 shows an example of Single inheritance (left) and Multiple inheritance (right). Figure 2.7 Inheritance Diagram Inheritance relations involving clusters Since classes are grouped into clusters, inheritance of classes will also involve the inheritance of clusters. BON uses three rules to deal with cluster inheritance: 1. If all elements (classes or clusters) in a cluster X inherit (directly or indirectly) from an element A outside of X, the cluster X is said to inherit from A. All direct inheritance links from elements in X to A can then be compressed into one inheritance link from X to A. 2. If an element A outside a cluster Y inherits (directly or indirectly) from all elements in Y, then A is said to inherit from Y. All direct inheritance links from A to elements in Y can then be compressed into one link from A to Y. 3. An inheritance link between two elements can be compressed into being hidden (not shown in a diagram). Note the word "element" mentioned above can be either a class or a cluster. Rule 1 & 2 basically say that in order for a cluster to be child or parent of another element, all elements inside the cluster must be a corresponding inheritance relation to this element. Rule 3 makes further simplification by presenting less information. Figure 2.8 Cluster Inheritance Figure 2.8 shows some examples of cluster inheritance. The leftmost diagram shows a cluster inheritance after application of rule 1. We can infer that classes B, C, D, E are the children (directly or indirectly) of class A. The middle diagram hides the inheritance link inside the cluster by the application of rule 3. This is based on the assumption that the developer knows enough about the system structure to rule out such esoteric possibilities, and then diagrams containing a large number of inheritance links can often be greatly simplified without losing information. The rightmost diagram shows a cluster inheritance after application of rule 2. Note in Figure 2.8, class A can also be replaced with a cluster. ie. one cluster inherits from another cluster. When such a relation exists, it can be obtained by repeated application of rules 1 and 2. eg. if all the elements in cluster X directly or indirectly inherit from all the elements in cluster Y, by repeated application of rules 1 and 2, we can derive that cluster X inherits from cluster Y. 2.4.2 Client Relations A client/supplier relation between a client class A and a supplier class B means that A uses services supplied by B. This leads to a class dependency between A and B, indicating that if the specification of B is changed, then the specification and/or implementation of A may have to be changed too. It may also lead to a potential object dependency between instances of A and B when the system is executed. In BON, contrary to other methods, there is no direct notation for expressing static dependencies between objects, but only between classes. The main reason is that an object- oriented system is specified as a structured collection of classes with precisely defined interfaces. It is through the classes and only through them that object behaviour is defined. There are three types of client relation (Walden and Nerson 1995). They are association shared association aggregation Each of them plays a particular role in the client/supplier relation. An association relation means that some instances of the client class may be attached to one or more instances of the supplier class. A particular instance of the supplier class may take part in many such attachments, thus permitting supplier objects to be shared by different clients. A shared association relation is a special case meaning that whenever an instance of the client class is attached to an instance of the supplier class, it will always be to the same supplier instance. This permits specific instances to be shared by all client objects of a certain type. An aggregation relation means that each client instance may be attached to one or more supplier instances which represent "integral parts" of the client instance. Graphical Representation Graphically, association relation is represented by a double line with an arrowhead pointing from the client class to the supplier class. This is called the client link. See figure 2.9. O Figure 2.9 Association Relation Similar to the association link, shared association link is also represented with a double line and an arrowhead. In addition to that, a special sharing marker (small circle) is placed on the client link. Figure 2.10 shows a HOCKEY_PLAYER class whose instances all share the same instance of the class PUCK. 1 O Figure 2.10 Shared Association Relation Aggregation links end with an open brace, as in Figure 2.11. { Figure 2.11 Aggregation Relation If the supplier is a parameterised class (generic class), it can be represented as Figure 2.12. O Figure 2.12 Indirect client dependency through generic derivation The directions for class relations are very important for signalling dependencies. A child depends on its parents and needs to know about them, but not the reverse. Similarly, a client depends on its suppliers and needs to know about them, but not the reverse. A client link from A to B may correspond to one or more of the following cases: A public feature in A returns a value of type B or a type derived from B, if B is generic). An input argument of a public feature in A is of type B. An actual parameter in a generic type derivation specified in A as part of the public interface is of type B. The implementation of A uses an entity of type B. This includes the signatures of private features, as well as state variables and local variables used inside features. Client relations involving clusters The semantics of client relations involving clusters is different from the corresponding semantics of inheritance relations. As described early, an inheritance relation having a cluster at either end carries over to relations with all classes in the cluster. However, client relation only refer to at least one class in each cluster. In contrast to the three rules applied on the cluster inheritance relations, cluster client relations also have three rules. They are: If one or more elements (classes or clusters) in a cluster X are clients of an element A outside of X, then the cluster X is said to be a client of A. All the corresponding client links can then be compressed into one client link from X to A. If an element A outside a cluster Y is a client of one or more elements in Y, then A is said to be a client of Y. All the client links can then be compressed into one link form A to Y. A client link between two elements can be compressed into being hidden (not shown in a diagram). The main reason for such a difference between the client cluster relations and the inheritance cluster relations is quite straightforward. The general semantics of inheritance is that of "all or nothing", ie. either you are the child and then you have all my genes, or you are not my child at all. A child can not select the operations to inherit from its parent. On the other hand, the general semantics of the client relation is that of "free choice", ie. a client can request any service provided by a supplier class, but is not obliged to use everything. 2.5 Discussion BON supports general software development with no special application types in mind. The concepts and notations are designed to encourage a reusability approach by emphasizing the seamlessness, reversibility and software contracting. The static model of BON represents a very clear view of an Object-Oriented system. It contains different charts at the different levels for the different users. It groups classes into three layers (system, cluster, class), and thus shows the different levels of abstraction of the system. The class charts can clearly define the class attributes and behaviours, with the flexibility of compressing and decompressing the charts. Combined with the software formal specifications, users can easily identify the queries, commands and constraints of those classes, so that the reusable components can be recognized. The class relation diagrams (client relation and inheritance relation) provide very sophisticated notations, showing the dependencies among classes and clusters. However the main purpose of those class relation diagrams is merely to show users how classes are related to each other. Not too much focus and guidelines have been put on to those diagrams to show users how to achieve higher reusability from them. The clustering is a great idea to group certain classes together into clusters, and give users different levels of abstractions. However there are no particular guidelines designed to help users how to cluster classes in order to achieve higher reusability, therefore clustering may be practised according to the individual user experience. In general, BON is an excellent methodology for designing and developing an Object- Oriented system. If it is combined with some additional design guidelines, it can result in a very well defined system with high reusability. The next section describes the Unified Method. 3. Unified Method 3.1 Overview of the Unified Method The Unified Method, developed by Booch and Rumbaugh, is used for specifying, visualising and documenting the artefacts of an object-oriented system under development. The Unified Method represents the unification of the Booch and OMT methods as well as the best ideas from a number of other methodologists. It is aimed to provide the basis for a defacto standard in the domain of objet-oriented analysis and design founded on a wide base of user experience (Booch and Rumbaugh 1995). A diagram is a projection upon the elements of a model. diagrams are the primary artefacts that developers use when manipulating models. In the Unified Method, there are a number of diagrams that are central: Class Diagram. The class diagram is the core of a Unified Model. It shows the logical static structure of a system, ie. its contents and their relationships to each other. It also shows the elements composing the state of a system. Use case diagram. A use case is a generic description of an entire transaction involving several objects. A use case can also describe the behaviour of a set of objects. Thus, a use case model presents a collection of use cases and is typically used to specify or characterize the behaviour of a whole application system together with one or more external actors that interact with that system. Message trace diagram. The message trace diagram shows a particular series of interactions among objects in a single execution of a system. Object message diagram. An object message diagram is a scenario diagram that shows the sequence of messages that implement an operation or transaction. Whereas message trace diagrams emphasize the temporal flow of behaviour, object message diagrams emphasize relationships. State diagram. The state diagram describes the temporal evolution of an object of a given class in response to interactions with their objects inside or outside the system. Each class may have a state diagram to describe its dynamic behaviour. Module diagram. The development view of a system may be specified and visualised in module diagrams, which represent the physical modules that provide the defining occurrence of the elements in the system's logical model. Modules may be distinguished as either specifications or implementations. Platform diagram. The physical topology upon which a software system executes may be specified and visualized in a platform diagram. Such a diagram (of which there is most often one for the system) includes processors and devices all united by connections along which information may pass. We are interested in the Class Diagram, especially in the area of class relations and class categories. Following sections will describe them in details. 3.2 Class Diagram The class diagram is the core of a Unified Model. It shows the logical static structure of a system, ie. its contents and their relationships to each other. It also shows the elements composing the state of a system. 3.2.1 Classes A class is drawn as a solid-outline rectangular box with 3 parts, with the class name in the top part, a list of attributes (with optional types an initial values) in the middle part, and a list of operations (with optional argument lists an return types) in the bottom part. (See left part of Figure 3.1). The attribute and operation parts of the class box can also be suppressed to reduce detail in an overview. (See right part of Figure 3.1). Polygon center: Point vertices: List of Point borderColor: Color fillColor: Color display (on: Surface) rotate (angel: Integer) erase () destroy () select (p: Point): Boolean Figure 3.1: Class An attribute has a name and type specified in the format name: type=initialValue. The name and type are strings that are ultimately language-dependent. An operation has the format name (parameter:type=defaultValue, ...): resultType. The operation parts are strings that are language-dependent. Tools may provide alternate formats for displaying attributes and operations, such as C++ or Smalltalk formats. Tools may also provide filters for suppressing various constituents of each element. For example, a user might want to see simply a list of attributes without types. Similarly, a user might wish to visualize the responsibilities associaciated with a particular class. 3.2.2 Templates Parameterized classes can be specified by impacting the class box with a small dashed box in the upper right corner. The template name is placed in the class box. The dashed box contains a list of formal template parameters and their types in attribute form: arg:type (Figure 3.2). Classes instantiated from templates are drawn as ordinary class boxes but the instantiation is indicated lexically in the class name string in the format: templateName. The classname is the name of the template. Instantiated template classes can be connected to their templates by dashed arrows, although it is usually unnecessary to draw instantiated classes on class diagrams, since they usually appear only as variable and parameters types. (Figure 3.2). Figure 3.2: Parameterized classes 3.2.3 Associations Associations (Figure 3.3) represent structural relationships between objects of different classes, information that must be preserved for some duration and not simply procedural dependency relationships. The individual instances of an association are called links. Most associations are binary, drawn as solid lines between pairs of classes. Figure 3.3: Association notation An association may have a name with an optional small "direction arrow" showing which way it is read. These name could be different in each direction. Each end of an association is a role. Each role may have a unique name showing how its class is viewed by the other class. Each role indicates the multiplicity of its class, ie. how many instances of the class can be associated with one instance of the other class. The multiplicity is expressed in the format n1..n2, where n1 is the lower limit and n2 is the higher limit. Symbol "*" indicates "many", ie. an unlimited number of objects. keyword "{ordered}" indicates that the elements have an explicit order. Self-associations and multiple associations between a pair of classes are possible and common. It is important to use association names or role names to tell them apart. Role names are essential on self-associations. Note that drawing two associations between class A and class B does not mean that the same A and B objects are related twice. A given A object may be linked to different B objects through each association. Each association is independent. Sometimes one class can participate in two associations, but each object can only participate in one of the associations at a time. This situation can be expressed by an Or-association. Figure 3.4 shows such an example. In this case, both associations have the same role name since they both can not hold simultaneously. Figure 3.4: Or-association Aggregation is a special form of association with the connotation of "whole-part" relationship. It indicates that the lifetimes of the parts are dependent on the lifetime of the whole. It is indicated by placing a diamond on the role attached to the whole object. Figure 3.5 shows an example of an aggregation relation. Figure 3.5: Aggregation notation 3.2.4 Inheritance Inheritance is the taxonomic relationship between a superclass and its subclasses. It is often called generalization or specialization depending on whether one is going from the subclasses to the superclass or from the superclass to the subclasses. It is drawn as a solid link from subclass to superclass with a large filled triangular arrowhead on the superclass end (Figure 3.6). All attributes, operations, and associations are inherited by all subclasses. Figure 3.6: Inheritance 3.2.5 Categories Large models require internal organization. Each category owns some of the classes, associations, and generalizations of the model. Categories are purely organizational and they have no logical semantics, although they may be organized along semantic along semantic lines. Category can be nested. The category for the entire system is the root of the model tree. Each class has a "home" category where its internal details are defined; this category owns the class. A class can also appear in the context of another category as an imported occurrence. The annotation "CategoryName::ClassName" can be used to signify a class owned by a different category. A category is drawn as a rectangular box with a double outline. Dependencies between categories are shown by dashed arrows between them, pointing from the client (dependent) category to the supplier (independent) category ( Figure 3.7). A category diagram is a kind of class diagram showing only categories (the classes are suppressed). Large categories can be decomposed into smaller categories by nesting ( Figure 3.7). Figure 3.7: Categories (nested form) 3.3 Discussion Similar to the BON method, the class diagram of the Unified Method shows a clear view of an Object-Oriented system, the class relations, the object relations, the system operations and the system behaviours. The class relation diagrams (association, aggregation and inheritance relation) also provide comprehensive notations, showing the dependencies among classes. Again, the main purpose of those class relation diagrams is merely to show users how classes are related to each other. Not too much focus and guidelines have been put on to those diagrams to show users how to achieve higher reusability from them. There is no clustering in the Unified Method. Although class category provides a way to group certain related classes and sub-categories together, there are no semantics or guidelines defined to help users how to organize those components, ie. the organization of categories and classes may be purely relied on the users' own experiences. The dependencies among categories have also not been clearly defined, therefore we could not know the reusabilities of the categories. In general, the Unified Method is a methodology for designing and developing an Object- Oriented system. If it is combined with some additional design guidelines to focus on design for reuse, it can result in a very well defined system with high reusability. The next section describes an approach to retrieving the reusable components by using subsumption test algorithm and the hierarchical clustering algorithm. 4. Formal Methods Applied to Reuse This approach was proposed by Betty Cheng and Jun-jang Jeng. The approach is based on formal methods to achieve the classification, organization and retrieval of reusable software components. Two tiered hierarchy of software components is constructed from a set of formal specifications. The lower-level hierarchy is created by a subsumption test algorithm that determines whether one component is more general than another. The higher-level hierarchy is constructed by applying a hierarchical clustering algorithm to the most general components from the lower-level hierarchy, so as to determine the reusable candidates (Cheng and Jeng 1992). 4.1 Lower-Level Hierarchy The lower-level hierarchy is created by a subsumption test algorithm that determines whether one component is more general than another. Logical reasoning techniques are applied at this level for a find grained, exact determination of reusable candidates. The modified subsumption test algorithm (MST) derived from the traditional subsumption test algorithm, can be used to partition into equivalence classes into a number of related components. After applying the MST algorithm to the existing components, a set of graphs (ASG) that contains lattices or trees is obtained, there nodes are the software components and the directed edges represent the generality relationship. Figure 4.1: Sample application of subsumption test algorithm Figure 4.1 shows an example of sample applications of the subsumption test algorithm. Originally, there were fifteen components in the library. Applying the subsumption test algorithm results the lower-level hierarchy displayed in Figure 4.1. Each diagram in the figure is one cluster. The arrow line indicates the specific to general relationship. 4.2 Higher-Level Hierarchy The higher-level hierarchy is constructed from the results of the lower-level hierarchy construction process. Some software components may not be related, so the lower-level hierarchy may be made up of a disjoint set of hierarchically organized clusters. In order to form a connected hierarchy of software components, a conventional clustering algorithm is applied to the most general components obtained from the MST, ie. the roots of trees and the top elements of the lattices in the ASG. The clustering algothrim is performed iteratively for handling the similarity values between specifications of software components. Each iteration contains two steps. First, if two clusters have the greatest value of similarity, then these two clusters are to be merged. Second, after the two clusters are merged, the similarity values between clusters are updated, thus defining the partition for the next iteration of the clustering algorithm. The number of such iterations can be defined by users. This flexibility allows users to incorporate background experience in order to get the best result of the higher-level hierarchy. Thus, the higher-level hierarchy provides a coarse-grained determination of reusable candidates, based on the specification of the software components. Figure 4.2: Sample application of clustering algorithm Figure 4.2 shows an example of the application of the clustering algorithm. The algorithm is invoked upon the lower-level hierarchy, ie. four clusters displayed in Figure 4.1. At this stage, the inputs to the clustering algorithm are only those roots of the ASG. In this example, components classTree and classSet are merged and the hierarchical clustering algorithm yields a meta-node class1 for them. Class2 and class3 also represent the newly created meta- nodes. The user may choose to rename meta-nodes to more descriptive names. 4.3 Search for Reusable Candidates The construction of hierarchy is performed from the lower-level to the higher-level hierarchy. On the other hand, the search and retrieve of reusable components are proceeded from the higher-level hierarchy to the lower-level hierarchy. At the higher-level hierarchy, a query is mapped to some index that indicates the search starting nodes within the hierarchy. After performing the coarse-grained search, the search space may be greatly reduced. The corresponding lower-level hierarchy is then searched using formal reasoning techniques, thus providing an exact determination method. 4.4 Graphical Browser A prototype browser has been developed to provide a graphical framework for the algorithms. The browser enables a user to traverse the hierarchically organized specifications of software components. By making information about class hierarchies and method specifications more accessible, the browser facilitates the iterative process of developing and accessing reusable specifications. In searching for a reusable candidate, the user may select the node to begin the search, or the system will select the root node based on the syntactical components of the query. 4.5 Discussion Both the lower-level test algorithm and the higher-level clustering algorithm have demonstrated a solid method to retrieve the reusable candidates. Clustering is again a good idea to group related components together to form a higher level abstraction. While this method mainly concentrates on the specific to general relationship, it has not put too much focus on the client & supplier relationship which is another major dependence relation in the Object-Oriented paradigm. Although this method is an excellent tool for retrieving the reusable components, it does not provide any guidelines for designing a high reusable system. The next section describes the Hierarchical Dependence Diagram. 5. Hierarchical Dependence Diagram (HDD) 5.1 Overview of HDD Class dependence analysis is one of the most important forms of analysis to build highly reusable object-oriented software components. The underlying theory is that the less a component is dependent on other components, the more reusable the component is (Chao 1994). HDD, developed by Iwan Chao and Jian Chen, is a tool that can be used to perform class dependence analysis from the beginning of the design stage to the end of the development process. HDD reveals the two most important class dependence issues in object-oriented paradigm: Association dependence Inheritance dependence Inheritance is argued to be the strongest dependence among classes, because if you modify a parent class, then all its children classes may have to be modified. Association is considered weaker, as classes having this particular relationship only depend on other class public interfaces, not their internal implementation. ie. if you modify the implementation of the supplier class, as long as the public interface is not changed, you do not have to change the client class. In HDD, inheritance dependence is represented by a solid arrow line pointing from the child to the parent; association dependence is represented by a dashed arrow line pointing from the client to the supplier. 5.2 Four Levels of HDD A completed HDD consists of four levels. Each level of HDD shows different abstraction level of dependence relationships. The four levels are: Platform Level (Level 0) The Platform Level is the highest level of the HDD. It shows dependencies of one platform on another. In one completed HDD, there should be one and only one platform. Library Level (Level 1) This is the next level below the Platform Level. It shows dependencies of one library on another in a platform. Cluster Level (Level 2) This is the next level below the Library Level. It shows dependencies of one cluster on another in a library. Class Level (Level 3) This is the next level below the Cluster Level. It shows dependencies of one class on another in a cluster. Dependence at the class level is considered to be the weakest type of dependence. Dependence is getting stronger as the level goes up, and dependence at the platform level is considered to be the strongest type of dependence. Figure 5.1 shows this four level structured HDD. Platform P1 has two libraries L1 and L2. Libraries L1 and L2 have their own clusters, and the clusters have their classes respectively. Figure 5.1 The Four Levels of HDD The following sections discuss the four levels o the HDD in more details. 5.2.1 The Class Level (level 3) This is the lowest level of HDD and it has the most detailed dependence representation. The dependence at the level is called "class dependence". The basic notation of the class level HDD is that all the classes belong to the same cluster are represented in ellipses. Classes in other clusters are not represented in ellipses, but the links show what are the other cluster names where those external classes exist. Figure 5.2 shows an example of the class level HDD. The diagram indicates that class CL1, CL2 and CL3 are all in cluster CU1, so they are represented in ellipses. Class CL1 has inheritance dependence on class CL2, and Class CL3 has association dependence on class CL2. Meanwhile, class CL2 has inheritance dependence on an external class CL4 which locates in cluster CU2. Figure 5.2: Class Level (Level 3) Diagram 5.2.2 The Cluster Level (Level 2) Cluster groups certain classes together. The dependence at this level is called "cluster dependence". If one or more classes in cluster CU1 have association/inheritance dependencies on one or more classes in another cluster CU2, then we can say that cluster CU1 has association/inheritance dependence on cluster CU2. Cluster dependence abstracts the class dependence details, and shows dependence relations among clusters. The basic notation of the cluster level HDD is that all the clusters belong to the same library are represented in rounded rectangles. Clusters in other libraries are not represented in rounded rectangles, but the links show what are the other library names where those external clusters exist. If there are more than one classes in one cluster have dependence relations with classes in another cluster, then link will also show the "weight" indicating the number of dependencies. Figure 5.3 shows an example of the cluster level HDD. The diagram indicates that cluster CU1, CU2 and CU3 are all in library L1, so they are represented in rounded rectangles. Cluster CU1 has inheritance dependence on cluster CU2, and cluster CU3 has association dependence on cluster CU2. Meanwhile, cluster CU2 has inheritance dependence on an external cluster CU4 which locates in library L2. The diagram also indicates that there are three classes in cluster CU1 have inheritance dependencies on two classes in cluster CU2. Figure 5.3: Cluster Level (Level 2) Diagram 5.2.3 The Library Level (Level 1) Library groups certain clusters together. The dependence at this level is called "library dependence". If one or more clusters in library L1 have association/inheritance dependencies on one or more clusters in another library L2, then we can say that library L1 has association/inheritance dependence on library L2. Library dependence abstracts the cluster dependence details, and shows dependence relations among libraries. The basic notation of the library level HDD is that all the libraries belong to the same platform are represented in diamonds. Libraries in other platforms are not represented in diamonds, but the links show what are the other platform names where those external libraries exist. If there are more than one clusters in one library have dependence relations with clusters in another library, then link will also show the "weight" indicating the number of dependencies. Figure 5.4 shows an example of the library level HDD. The diagram indicates that library L1, L2 and L3 are all in Platform P1, so they are represented in diamonds. Library L1 has inheritance dependence on library L2, and library L3 has no any dependence relations with other libraries. Figure 5.4: Library Level (Level 1) diagram 5.2.4 The Platform Level (Level 0) This is the toppest level of HDD and it has the least detailed dependence representation. In one HDD, there is only one platform. Platform groups certain libraries together. The dependence at this level is called "platform dependence". If one or more libraries in platform P1 have association/inheritance dependencies on one or more libraries in another platform P2, then we can say that platform P1 has association/inheritance dependence on platform P2. Platform dependence abstracts the library dependence details, and shows dependence relations among platforms in different HDD. The basic notation of the platform level HDD is that the platform belong to the current HDD are represented in a circle. Platforms in other HDD are represented without circles. If there are more than one libraries in one platform have dependence relations with libraries in another platform, then link will also show the "weight" indicating the number of dependencies. Figure 5.5 shows an example of platform level HDD. The diagram indicates that the platform in this HDD is named as P1, and it has no any dependence relations with other platforms in other HDDs. Figure 5.5: Platform Level (Level 0) Diagram 5.3 The HDD Maintenance Algorithms The four level HDD gives a very clear hierarchical view of the dependence relations within the system. However in order to maintain the HDD accurately and consistently, algorithms are necessary to maintain the HDD. In Chao's thesis (Chao 1994), he developed a complete set of algorithms for adding, modifying and deleting a class in the HDD. Followings are the summary of those algorithms. 5.3.1 Add A New Class To add new class, not just the class level diagram needs to be modified, but also all other levels of diagrams need to be updated. The steps of adding a class are: 1) Select the platform from the Platform Level. 2) Select the library from the Library Level. 3) Select the cluster from the Cluster Level. 4) Store the new class at the Class Level. 5) Establish the class dependencies at the Class Level. a) Establish the inheritance class dependence. b) Establish the association class dependence. 6) Establish the cluster dependencies at the Cluster Level. a) Establish the inheritance cluster dependence. b) Establish the association cluster dependence. 7) Establish the library dependencies at the Library Level. a) Establish the inheritance library dependence. b) Establish the association library dependence. 8) Establish the platform dependencies at the Platform Level. a) Establish the inheritance platform dependence. b) Establish the association platform dependence. 9) Resolve the temporary libraries at the Library Level. 10) Resolve the temporary clusters at the Cluster Level. 11) Include the cluster names of the external classes at the Class Level. 5.3.2 Modify A Class To modify the existing class in HDD, the steps to maintain the HDD are as follows: 1) Select the platform from the Platform Level. 2) Select the library from the Library Level. 3) Select the cluster from the Cluster Level. 4) Retrieve the class to be modified from the Class Level. 5) Collect the class dependencies of the class to be modified at the Class Level. 6) Modify the implementation of the class. 7) Re-establish the class dependencies at the Class Level. a) Re-establish the inheritance class dependence. b) Re-establish the association class dependence. 8) Remove the unnecessary class dependencies at the Class Level. 9) Remove the unnecessary cluster dependencies at the Cluster Level. 10) Re-establish the cluster dependencies at the Cluster Level. a) Re-establish the inheritance cluster dependence. b) Re-establish the association cluster dependence. 11) Remove the unnecessary library dependencies at the Library Level. 12) Re-establish the library dependencies at the Library Level. a) Re-establish the inheritance library dependence. b) Re-establish the association library dependence. 13) Remove the unnecessary platform dependencies at the Platform 14) Re-establish the platform dependencies at the Platform Level. a) Re-establish the inheritance platform dependence. b) Re-establish the association platform dependence. 15) Resolve the temporary libraries at the Library Level. 16) Resolve the temporary libraries at the Cluster Level. 17) Include the cluster names of the external classes at the Class Level. 5.3.3 Delete A Class To modify the existing class in HDD, the steps to maintain the HDD are as follows: 1) Select the platform from the Platform Level. 2) Select the library from the Library Level. 3) Select the cluster from the Cluster Level. 4) Select the class to be removed at the Class Level. 5) Collect the class dependencies of the class to be removed at the Class Level. 6) Remove the class dependencies. 7) Remove the class the Class Level. 8) Remove the cluster dependencies. 9) Remove the library dependencies. 10) Remove the platform dependencies. 5.4 Design Guidelines of the HDD HDD is a very useful tool showing the dependencies of an object-oriented system, so that we can know what are the reusable components and how we can reuse them. However, HDD itself is just a diagram tool. It does not provide intelligent guidelines to tell how to organise the reusable components into the four level system. Therefore the HDD tool is not much beneficial without having some useful design guidelines to support it. The purpose of these design guidelines is to organise classes, clusters, libraries, and platforms in such a way that the system will have the least dependencies to achieve the highest reusability, and in the mean time, it will not violate other software development guidelines. There are some important concepts that we need to keep in mind. The HDD tool is used for us to study the dependencies in the system. It is believed that the less dependence the system has, the more reusability it is. Inheritance dependence is argued to be more stronger than the association dependence. 5.4.1 Reusable Components There are four levels of reusable components. They are the class level, cluster level, library level and platform level. As stated earlier, when the level goes higher, the strength the dependencies becomes stronger. Figure 5.6 illustrates this situation. Figure 5.6: Hierarchical Independence Concept There are four types of reuse in HDD, which can be illustrated using Figure 5.7. Figure 5.7: Class, Cluster, Library, and Platform Reuse Class Reuse. This is the smallest abstraction in object oriented paradigm that can be reused. Class reuse can only be applied to classes that have no dependence on other classes. Some examples of class reuse from Figure 5.7 are classes CL1, CL2, and CL4. Cluster Reuse. If reusing one or more classes in a cluster needs to include all other classes in that cluster, because of the class dependence, then this particular reuse is called "cluster reuse". In Figure 5.7, if reusing CL3 in cluster CU1, then CL1 and CL2 will have to be reused as well because of the association/inheritance dependencies. Therefore the whole cluster CU1 will have to be reused. Library Reuse. If reusing all the clusters in a library directly or indirectly because of the cluster dependencies in that library, then this particular reuse is called "library reuse". In Figure 5.7, if reusing CL5 in cluster CU2, then CU1 will also have to be reused, and as a result library L1 will have to reused as well. Platform Reuse. If reusing all the libraries in a platform directly or indirectly because of the library dependencies in the platform, then this particular reuse is called "platform reuse". In Figure 5.7, if reusing either CL6 or CL7 in cluster CU3, then library L1 will have to be reused, and as a result the whole platform P1 will have to be reused. 5.4.2 Hierarchical Independence Design Guidelines Having the purpose of HDD tool in mind, the followings are some design guidelines for producing highly reusable components. Classify reusable components in the hierarchical repository (class, cluster, library and platform). The classification can be based on the functionalities, the component characteristics etc. Minimize hierarchical dependencies. The less the hierarchical dependence a component has, the more reusable it is. Components just having class dependence are more reusable than those having platform dependence. Minimize dependence in the same repository. If cluster A and cluster B have the same number of classes, then classes in A are regarded to be better design for reuse, if dependence among those classes is less than dependence among classes in B. Implement components through association, if possible, rather than through inheritance. As stated early, dependence of components through association is weaker than those through inheritance. Considering the left diagram in Figure 5.8, initially both CL1 and CL2 in cluster CU1 have inheritance dependencies on CL3 in cluster CU2. This dependence can be minimized by moving class CL3 into cluster CU1 (as shown in the right part of Figure 5.8). The latter design improves the components reusability as the two clusters are now less dependent than the initial design, ie. CU2 now has association dependence on CU1, rather than the inheritance dependence. Figure 5.8: Guideline Example: Minimizing Cluster Dependence 5.5 Discussion The Hierarchical Dependence Diagram provides clear notations representing the dependence relationships within the system. It is a very useful tool for software developers to perform dependence analysis on an Object-Oriented system. The four level HDD is particular useful for large systems with thousands of classes, because each level of HDD shows different level of abstractions. The Hierarchical Independence Design Guideline has also given some ideas to the software developers how to organize the reusable components into HDD to achieve the highest reusability. Currently, the HDD only provides notations for association and inheritance dependence relations. Although these are the two main dependence relations in the Object-Oriented paradigms, notations for other dependence relations would also be preferable. The measurement of a dependence relation might needs to be improved. Currently, the notation only shows how many components in one repository have the dependence relations with another repository, without knowing the actual number of components in that repository. eg. From Figure 5.3, we only know that there are three classes in cluster CU1 have inheritance dependencies with two classes in cluster CU2, but we do not know how many total classes in cluster CU1. There could be only three classes in cluster CU1 in which case the rate is very high; there also could be one hundred classes in cluster CU1 in which case the rate is very low. More sophisticated measurement is necessary to measure the dependencies. The current HDD notation represents a language independent system, which is good for general type of HDD notation. When HDD is actually put into practice, it is useful to have some language specific notations to represent the more detailed dependence relations of the system. While HDD is useful for users to perform dependence analysis, a HDD tool may be necessary to ease this process. The tool should firstly contain a parser which can parse an Object- Oriented language and load classes into proper repository. The tool should also have a HDD maintainer which allow users to add/modify/delete components in the different levels of repositories. Preferably the tool should have a dependence analyser which can tell users how to organize the reusable components to achieve the lowest dependencies and highest reusability, according to the built in design guidelines. 6. Other Related Works There have been other related methods that can be used by the software developers to design reusable systems and retrieve reusable components. They are: Interactive-Design Model for Reusable Object-Oriented Software. Gossain and Anderson (1990) have developed An Interative-Design Model for Reusable Object- Oriented Software. This is an iterative-design approach for reusable object-oriented software that augments existing deign methods by incorporating iteration into the design methodology and focuses on the set of problems within the domain, encouraging reuse of existing design information. There are five main stages to the design model, each of which has substages of varying complexity. The five stages are Domain Analysis, Abstraction, Specialization, Evaluation and Revision, and Implementation. Each stage can highlight design drawbacks in any of the previous stages and as such can mean iterating back to the cause of the problem. An example design has been performed using this model with sample code constructs in C++. The results have shown a high degree of code reuse when using the model. On the Retrieval of Reusable Software Components. Base on the principle of software reusability through formal specifications, Chen and Hennicker (1993) have suggested a model for the retrieval of reusable components utilizing the search techniques in the database management systems. The formal specification language of software components is ASL. Component specifications will be translated into a specification written in the knowledge representation language Telos for storage and other manipulation. The retrieval of software components is based on signature matching between the signatures of goal specifications and those of reusable components. The retrieval mechanism is supported by the Database Management System ConceptBase. Reusing objects with Object Graph. Morley and Chiu (1991) have proposed an approach to object graph understanding, organization, and management through grouping objects into "object complexes" for a variety of purposes, foremost of which are object persistence and reuse. These reusable objects are large scale "pluggable" components which embody both state and behaviour. The underlying idea for this approach is that in an object-oriented system, most individual objects are not very reusable by themselves, but are reusable only as part of a larger "complex" of objects which comprise the programmer's idea of the object being modelled. Individual objects are usually just a bundle of pointers to other objects. Most of the potentially reusable information (and behaviour) is contained in the structure of the larger complex, not just in the atomic data at the "leaves" of the complex. 7. Conclusion In order to achieve higher reusability of an Object-Oriented system, care must be taken from the beginning of the software development. Design for reuse is important, because only if the system is designed with the reusability in mind right from the beginning, then we can get a higher reusable system. Besides, it is also easier for other tools (design with reuse) to retrieve those reusable components. Dependence analysis is a quite solid method to achieve design for reuse. Through the dependence analysis, we can know what are the reusable components. Existing methodologies such BON and Unified Method are useful for modeling an entire Object-Oriented system. Although they have notations representing the dependence relations, little focus has been put on the dependence analysis issues. Hierarchical Dependence Diagram is particularly designed for dependence analysis. It has all the notations available for dependence analysis at four different levels, so that we can also achieve different levels of reusabilities, ie. Class Reuse, Cluster Reuse, Library Reuse and Platform Reuse. If the Hierarchical Dependence Diagram is enhanced with more language specific notations, more sophisticated dependence analysis measurement, and supporting tool for maintaining the HDD, it can be a very power method for software developers to design high reusable systems. Besides the dependence analysis method should also be useful to other related issues in object-oriented software development such as testing, maintenance and re-engineering OO Software Maintenance. When we have to change, say a class, in a system, what is the impact of this change to other classes? What is a safe and minimal portion of system must be retested? OO System Testing. Much effort has been put on class level testing but less on cluster, library and system levels. OO Re-engineering. Given a (flat) class hierarchy, how should we restructure or group up it into appropriate components, either for a particular application or for improving the reusability? Bibliography Armstrong, J. and Mitchell, R. (1994, January). Object-Oriented Design with Applications. The Benjamin/cummings Publishing Company, Inc. Booch, G. (1991). object-Oriented Design with Applications. USA: The Benjamin/Cummings Publishing Company, Inc. Booch, G. and Rumbaugh, J. (1995). Unified Method for Object-Oriented Development. Version 8. Rational Software Corporation. Chau, I (1995). The Hierarchical Dependence Diagram: Improving Design for Reuse in Object-Oriented Systems. Honours Thesis, Department of Software Development, Moansh University. Chen, J. and Chau, I. (1996). The Hierarchical Dependence Diagram: Improving Design for Reuse in Object-Oriented Software Development. Technical Report TR96-7, Department of Software Development, Monash University. Chen, P. and Hennicker, R. (1993). On the Retrieval of Reusable Software components. IEEE, 99-107. Cheng, B. and Jeng, J. (1992). Formal Methods Applied to Reuse. Department of Computer Science, Michigan State University. Coad, P. and Yourdon E. (1991a). Object-Oriented Analysis. Yourdon Press Computing Series. New Jersey, USA: Prentice-Hall, Inc. Firesmith, D. (1994, June). Using parameterized classes to achieve reusability while maintaining the coupling of application-specific objects. Journal of Object-Oriented Programming 7(3), 45-47. Gossain, S. and Anderson, B. (1990, October). An Iterative-Design Model for Reusable Object-Oriented Software. ECOOP/OOPSLA `90 Proceedings, 12-26. Johnson, R. and Foote, B. (1988, June/July). Designing Reusable Classes. . Journal of Object-Oriented Programming 23-35. Kennedy, B. (1992, July/August). Design for object-oriented reuse in the oath library. Li, W. and Henry, S. (1995, July/August). Measuring object-oriented desgin. Journal of Object-Oriented Programming, 48-54. McGregor, J. and Sykes, D. (192). Object-Oriented Software Development: Engineering Software for Reuse. Van Nostrand Reinhold. Meyer, B. (1994). Reusable Software: the Base Object-Oriented Component Libraries. Prentice Hall International (UK) Ltd. Morley, D. and Chiu, S. (1991). Reusable Objects. TOOLS/SOL, 237-248. Mitchell, R. and Howse, J. (1995, July/August). As-a: a relationship to support code reuse. Journal of Object-Oriented Programming, 25-33. Murry, B. and Robson, A. (1995, September). On behavior, inheritance, and evolution. Journal of Object-Oriented Programming, 38-42 Rumbaugh, J. e. a. (1991). Object-Oriented Modeling and Design. USA: Prentice Hall, Inc. Thrampoulidis, K. and Agavanakis, K. (1995, June). Object interaction diagram: a new technique in object-oriented analysis and design. Journal of Object-Oriented Programming, 25-32 Walden, K. and Nerson, J. (1995). Seamless Object-Oriented Software Architecture. Prentice Hall. Wasserman, A. (1991, May). Object-oriented software development: issues in reuse. Journal of Object-Oriented Programming 4 (2), 55-57. Wirfs-Brock, R. and Johnson, R. (1990, September). Surveying current research in object- oriented design. Communications of the ACM, 33(9), 104-124. 34