A COMPARISON OF SOFTWARE REUSE SUPPORT IN OBJECT-ORIENTED METHODOLOGIES

Transcription

1 A COMPARISON OF SOFTWARE REUSE SUPPORT IN OBJECT-ORIENTED METHODOLOGIES Shuguang Hong Computer Information Systems Dept. Georgia State University Atlanta, GA , USA Barbara Koelzer Dun & Bradstreet Software 3445 Peachtree Rd., N.E. Atlanta, GA 30326, U.S.A. ABSTRACT Software reusability has been regarded as one of the most important areas for improving software development productivity and quality in the 1990's. The object-oriented approach to information systems development has promised to achieve large-scale software reuse. Objectoriented analysis and design methodologies have aimed at the realization of the promised benefits; however, the degree to which the methodologies support reuse and deliver on this promise is an interesting, open question. This paper investigates how object-oriented analysis and design methodologies support software reusability. It provides an objective comparison of seven object-oriented analysis and design methodologies with respect to the support of software reuse. Several important observations are made based on the comparison. This study provides valuable information to researchers, practitioners and organizations for studying, selection and adoption of object-oriented analysis and design methodologies. 1. INTRODUCTION Reusability is frequently described as one of the keys to enabling the software development industry to meet the increasing demands of the 1990's. Ed Yourdon, in his book The Decline and Fall of the American Programmer, considers reuse to be one of the characteristics of "world class" software development organizations. He states, Software reusability will go down in history as one of the major technical contributors to software productivity and quality in the 1990s. Even though we have talked about reusability since the 1960s (or before), we have rarely practiced it effectively in most organizations. But the DP organizations that survive the decade of the 1990s will be those that have achieved high levels of reusability. [Yourdon 1992] Correspondingly, reusability is consistently presented as one of the key benefits of objectoriented software development. Meyer states, "object-oriented design is the most promising technique now known for attaining the goals of extendibility and reusability." [Meyer 1987]. Other arguments are: The use of the object model encourages the reuse not only of software but of entire designs, leading to the creation of reusable application frameworks [Meyer 88b] [Booch 1994]

2 IRMA 95 1 The motivations and benefits (of object-oriented analysis include)... Reuse of analysis results, accommodating both families of systems and practical tradeoffs within a system. OOA organizes results based upon problem domain constructs, for present reuse and for future reuse. [Coad & Yourdon 1991, OOA] A preeminent goal of OO techniques is achieving massive reusability in the building of software. [Martin & Odell 1992] Object-oriented techniques yield structures that are more readily reused than other design techniques. [McGregor & Sykes 1992] It (object-oriented development) is intended to promote future reuse and reduce downstream errors and maintenance. [Rumbaugh 1991] These authors all present methodologies that claim that, with their use, one will reap the benefits of software reusability. However, the degree to which the methodologies support reuse and deliver on this promise is an interesting, open question. We attempt to conduct an objective comparison of seven well publicized, object-oriented analysis and design methodologies (OOADMs) with respect to software reuse. The questions the study attempts to address are: 1. What concepts or artifacts facilitate software reusability in object-oriented approach in general? 2. How do the seven selected OOADMs support software reusability? 3. What conclusion can be drawn from the comparison? Based on the answers to the questions, we identify the weakness of software reuse support in the seven OOADMs in particular and help researchers improve OOADMs in general. This research also provides valuable information to practitioners and organizations and helps them study, select and adopt OOADMs. We, however, do not attempt to address the managementoriented issues of reusability such as education, training, reward and project management. This study is built on the assumption that reuse does not happen accidentally. Object-oriented techniques provide inherent characteristics that enhance the potential for reuse, but reuse will not happen automatically, even with these techniques. Therefore, this study has been conducted with the assumption that reuse must be an integral part of the analysis and design process, one that is planned for and designed into the software being developed. The remainder of this paper is divided into five sections. Section 2 briefly surveys current literature on software reusability and presents a taxonomy of the types of reusability, including those types available in object-oriented software development. Section 3 presents our research method and issues involved in the comparison. Section 4 contains the comparison of the seven OOADMs and conclusions of the comparison. Finally, section 5 summarizes the comparison and provides a plan for the further research. 2. SOFTWARE REUSABILITY Software reuse can be defined narrowly, encompassing only the reuse of executable code such as code fragments, subroutines or modules. This type of reuse is often called component reuse.

3 IRMA 95 2 Such a narrow definition of reuse, however, limits consideration of the possible benefits of reuse to a relatively small increase in programmer productivity. A broader definition of reuse includes the reuse of aspects of software beyond executable code components. Wegner [Wegner 1987], Krueger [Krueger 1992], Biggerstaff [Biggerstaff 1989] and Freeman [Freeman 1987] define the scope of reuse to encompass concepts, tools, people, analysis, design, specifications, documentation, and domain knowledge in addition to component reuse. In this study, we adopt this broader definition of the scope of reuse. Figure 1 presents a taxonomy of software reusability. This taxonomy is based on Biggerstaff and Richter's framework for categorizing different forms or types of software reuse [Biggerstaff 1989(b), p. 2]. The taxonomy also incorporates the classifications of reuse contributed by other researchers as surveyed by Krueger. [Krueger 1992] The taxonomy is divided into two general categories, composition-based and generation-based. Composition-based techniques are those forms of reuse that result from composing software from component parts, like building blocks. Generation-based systems, however, are systems that generate other systems. These categories will serve as the foundation for this taxonomy of software reuse technologies. Software Reuse Composition-based Generation-based Unplanned Ad hoc - knowledge - experience - code fragments Planned Formalized Languagebased Transformation based Application Generators Component Reuse Design Reuse Architecture Reuse Domain Analysis Reuse Specification Reuse Other - knowledge - people - prototypes - documentation Figure 1: Software Reuse Taxonomy The different types of reuse in Figure 1 are briefly explained as follows: Composition-based techniques are divided into planned (formalized) and unplanned (ad hoc). Most of the reuse in the past, and to a large degree in the present, is of the unplanned, ad hoc type. This paper is an attempt to analyze and describe ways of enhancing the planned development of reusable software, specifically using object-oriented techniques. The formalized or planned types of reuse are divided according to the type of artifact or resource reused.

4 IRMA Component reuse is the direct reuse of the software development product. [Freeman 1987(b), p.11; Biggerstaff 1989(b), p. 8] A component is an implemented abstraction. It differs from code fragments, modules and programs in that a component is general and of a high quality and it is developed and packaged with the aim of reuse. [Jacobson 94, p. 311] 2. Design reuse is reuse of the general design ideas [Freeman 1987(b), p.10], and the knowledge utilized in the generation of the product (the actual code) [Goldberg 1990, p. 108]. See [Krueger 1992, p. 173] and [Biggerstaff 1989(b), p.9] for a detailed discussion. An example of design reuse is that a company developing aircraft guidance systems will have a set of model designs summarizing its experience in this area [Meyer 88b, p. 30]. 3. Architecture reuse is reuse of large-grain software frameworks and subsystems that capture the global structure of a software system design. [Krueger 1992, p. 173]. In this context, architecture can be referred to as the characteristic structure of all systems designed using the approach. [Jacobson 94, p. 2-3]. Examples of architectures include user interface architectures and client/server architecture systems. See [Jones 1987, p. 52] for further discussion. 4. Domain analysis reuse is reuse of knowledge of the problem domain. It is "a generalization of systems analysis in which the objective is to identify the operations and objects needed to specify information processing in a particular application domain." [Freeman 1987(b), p. 18] Domain analysis focuses on the larger domain beyond a single system [Prieto-Diaz 1988, p. 347]. See [Berard 1993, p. 186], [Horowitz 1987, p. 44] and [Biggerstaff 1989, p. xxiii] for a more detailed discussion. 5. Specification reuse may be considered to be the reuse of a set of system requirements specifications used to create a new system in a different environment. This may include specifications for a system similar to one already developed, or it might concern specifications for a new version or a new operating environment for a current system. 6. Other forms of reuse might include the reuse of knowledge and experience, reuse of people from one project to another (a form of reusing knowledge and experience), reuse of the information and concepts learned from a prototype or the executable prototype itself, reuse of development techniques (e.g. methods, quality assurance checklists, etc.), or reuse of documentation. Generation-based Systems are systems that reuse software in the process of generating other systems. 1. Language-based systems may also be called very high-level languages. High-level languages such as C, COBOL and Ada are not often recognized as a form of reuse, however, their compilers reuse assembly language patterns. [Krueger 1992, p. 137] Very high-level languages attempt to achieve the same type of reuse at a higher level of abstraction than the traditional high-level languages, such as at the specification level. 2. Formal specification and transformation systems "focus upon the role, structure, and operation of transformations in the evolution of high-level specifications into operational programs." [Biggerstaff 1989, p. xxii; see also Horowitz 1987, p. 41] 3. Application generators are systems that assist developers in creating applications within a particular domain or type of application. [Krueger 1992, p. 155; Wegner 1987, p. 32]

5 IRMA 95 4 The reusability of object-oriented analysis and design falls into the planned, formalized reuse category. Because analysis and design have promoted systematic ways to develop software systems, object-oriented analysis and design should result in a higher degree of planned reuse as its primary goal. Unplanned, ad hoc software reuse will not be considered in this study. Similarly, object-oriented analysis and design do not deal with implementation, therefore generation-based software reuse is also outside the scope of this study. 3. RESEARCH METHOD AND COMPARISON ISSUES 3.1 The Research Method The comparison has drawn from two research projects. The comparison data are mainly drawn from a research project that compares OOADMs ([Hong 1993], [Goor 1993(b)]). This project has continued since 1992 and produced two reports ([Goor 92], [Bulthuis 94]). The goal of this project is to develop a formal comparison framework using method-data modeling and methodprocess modeling techniques [Brinkkemper 90]. After studying an OOADM, two meta-models are built: method-data model and method-process model. A method-data model captures the meanings of the concepts (constructs) provided by the methodology and represents the concepts using an extended Entity-Relationship model. A method-process model extracts the analysis and design steps (activities) prescribed by the methodology using the task structure model [Wijers 90]. In a task structure model, each analysis and design step is modeled as a task with input, the product (result) produced by this step, and the next analysis/design step(s). The OOADMs to be compared are first translated into those meta-models so that all those methodologies have a same and uniform representation. Based on the uniform representation, the concepts, processes and techniques of each methodology are extracted and compared. Limited by the space, interested readers may refer to [Hong 93], [Goor 93], [Goor 92] and [Bulthuis 94] for detailed discussion. However, this project does not study the methodology support issues of software reusability. The second project was initiated to investigate the reuse issue. The goal of the second project is to understand object-oriented software reusability and try to determine how OOADMs support software reuse. The findings of the second project resulted in a report [Koelzer 93]. This report also assembled a set of guidelines for enhancing software reusability for object-oriented analysis and design. This paper combines the findings in the second project with the comparison results from the first project. The study in the second project formed the foundation of this paper, while the first project helps us to map the findings to the concepts, processes, and techniques of the OOADMs. 3.2 Types of Software Reuse To Be Compared Not all types of planned, formalized software reuse as drawn in Figure 1 are included in this study. We dropped component reuse because it deals with the low level of implementation in a specific programming language. During analysis and design, components are regarded as black boxes. [Jacobson 94, p. 311] Issues related to the implementation of components are beyond the scope of analysis and design. However, in our study, we compared analysis and design steps that

6 IRMA 95 5 attempt to utilize reusable components as well as the steps and design guidelines that aim at making the components of a system under development reusable. We also did not include the last two types of reuse, specification reuse and other reuse. Specification reuse has been excluded from the selected OOADMs. These methodologies do not discuss issues regarding system requirements specification and there is no sufficient data in the methodologies to make the comparison meaningful. On the contrary, all selected methodologies implied the reuse of knowledge and experienced personnel. Several methodologies even proposed a job category similar to Booch s reuse engineer [Booch 94]. Since this study does not deal with management issues, we did not include this type of reuse in our comparison. 3.3 Comparison Variables For the remaining types of software reuse to be studied, we group the methodology support for software reusability into three categories: 1. Concepts - The concepts are constructs from which an application can be built. If a methodology supports software reuse, it should provide concepts that invite and facilitate reuse. The concepts as applied to a specific application generate artifacts that are reusable. 2. Process - The process consists of the steps prescribed by a methodology to perform the analysis and design tasks. Software reusability should be an integral part of the analysis and design process. A methodology should provide explicit steps that guide the user to take advantage of reusable artifacts and to design high quality artifacts that are themselves reusable. 3. Documentation - The documentation of the system is of critical importance to software reusability. Many of the difficulties of reuse relate to problems in the understanding of reusable artifacts. Clear documentation is essential for the understanding required to be able to reuse an artifact. Table 1 lists the comparison variables under each category. The selection criterion for these variables is objectiveness. That is, the variable must produce hard facts that a methodology either supports or does not support it. The selection criterion has limitations. The comparison does not provide fine grained information regarding a variable. Typically, the comparison cannot answer the degree to which a methodology supports an aspect of software reusability. However, answers to such question would be very subjective and would vary dramatically from one reviewer to another. We made the decision to trade subjective for objective comparison criteria. To help alleviate this shortfall, we distinguished explicit methodology support from implicit methodology support in the comparison if appropriate. As shown in Table I, the concepts vary with the type of software reusability because each type of reuse uses different artifacts. For example, the design reuse artifacts are different from architecture reuse artifacts. The former deals with constructs that are the building blocks for the reusability, while the latter deals with a larger scale of structures that can be reused.

7 IRMA 95 6 TABLE 1: COMPARISON VARIABLES Design Reuse Architecture Reuse Domain Analysis Reuse Concepts classes/objects meta-classes generic classes abstract classes encapsulation single inheritance multiple inheritance association aggregation framework modules subsystems transaction-oriented data analysis decision support expert applications numerical applications parallel/concurrent distributed,client/server methods/messages Processes analyze/design using reusable artifacts analyze/design artifacts that are reusable manage reusable artifacts Documentation diagramming notations The variables for comparing processes and documentation are identical among the three reuse types. Regardless of the type of reuse, system analysis and design must deal with these four fundamental issues: thinking reusability, using reusable artifacts during the process, analyzing and designing high quality artifacts that are reusable, and managing the reusable artifacts. Similarly, we attempt to compare the diagramming notations for reusable artifacts for all these reuse types. We did not include the textual documentation in the comparison because all methodologies by default support documentation in textual form. However, every methodology has its own set of diagramming notations. We delay defining these variables in Table I until Section 4 when the selected OOADMs are compared. 3.4 Selection of OOADMs We based the selection of OOADMs on two criteria. One is that the OOADMs must provide sufficient information for our comparison; which narrowed our selection down to those OOADMs that are published in the book form. The second selection criteria is that the OOADMs should be well-known. This selection ensure that our findings are representative and increase the degree of generalization of the findings. As the result, we selected the following seven OOADMs: 1. (C&Y) Object-Oriented Analysis and Object-Oriented Design by Coad and Yourdon. [Coad & Yourdon 91, 91b] 2. (WB) Designing Object Oriented Software by Wirfs-Brock, et al. [Wirfs-Brock 90]

8 IRMA (JR) Object-Oriented Modeling and Design by J. Rumbaugh, et al. [Rumbaugh 91] 4. (GB) Object-Oriented Analysis and Design by G. Booch [Booch 94] 5. (S&M) Object Lifecycles: Modeling the World in States by Shlaer and Mellor [Shaler & Mellor 92] 6. (IJ) Object-Oriented Software Engineering by I. Jacobson, et al. [Jacobson 93] 7. (M&O) Object-Oriented Analysis & Design by Martin and Odell [Martin & Odell 92] The letters in the parentheses are the abbreviations for the methodologies to be used in the comparison tables in Section COMPARISON OF SEVEN OOADMS The comparison of the seven OOADMs is divided into three separate sections; the concepts are compared in Section 4.1. analysis and design processes are in Section 4.2, and documentation is in Section 4.3. Each of these sections share the same organization; we provide brief definitions for the variables to be compared, followed by a table that lists the comparison results, and then discuss the comparison results and draw a conclusion of the comparison. 4.1 Comparison of The Concepts Brief Explanation of Comparison Variables Reusable Artifacts for Design Reuse As discussed earlier, design reuse is the process of reusing the design ideas embedded in the reusable artifacts. [Hodgson 1992, Kennedy 1992, Johnson and Foote 1988, Lee 1991] The concepts listed in Table I are supported by a majority of OOADMs. We deliberately ignored concepts that are only found in specific methodologies. We assumed that the readers are familiar with the basic objectoriented terms. We only provide very brief definitions for the concepts to be compared. 1. Classes (objects) - a set of objects that share the same structures and behavior (methods). 2. Meta-class - a class whose instances are classes [Booch 94]. 3. Abstract class - a class not intended to be used to create instances [Booch 94]. 4. Generic classes - templates from which specific classes can be created by supplying necessary parameters to the templates. 5. Encapsulation - the concept whereby parts of an object are protected from being accessed directly by other objects.

9 IRMA Single/Multiple inheritance (generalization) - a relationship between classes that allows a subclass to inherit superclass structures and behavior. 7. Association - a relationship that links an object to other objects such that they collaborate to accomplish some task. All objects involved in an association relationship are of equal importance and no one object plays a dominate role over others. 8. Aggregation - a relationship that groups objects to form an higher level object (container object). In the relationship, the container object plays a dominate role over the component objects. 9. Method - the behavior of an object 10. Message - a collaboration request sent by an object to another object. Reusable Artifacts for Architecture Reuse Architecture reuse allows a developer to reuse as a whole a large-scale structure that represents a significant design and implementation effort. The different types of reusable architectures are: 1. Framework - a set of classes that embodies an abstract design for solutions to a family of related problems, and supports reuse at a larger granularity than classes. [Johnson and Foote 1988] Wirfs-Brock and Johnson add a further refinement to the definition, A framework is a collection of abstract and concrete classes and the interfaces between them. [Wirfs-Brock and Johnson 1990] For example, a common type of framework available commercially is the graphical user interface (GUI) builder. 2. Module - a logical construct for grouping classes, relationships and generalizations. A module captures one perspective or view of a situation. [Rumbaugh 91. p. 43] A framework differs from a module. The former is a larger skeleton of a design that is reusable ([Jacobson 94, p. 311]) and is a collection of classes that provide a set of services for a particular domain ([Booch 94]). The latter is a view that partitions a system into manageable pieces. For example, electrical, plumbing, and ventilation modules are different views of a building. [Rumbaugh 91, p. 43] 3. Subsystem - a set of modules. A subsystem encompasses aspects of a system that share some common property. For example, a spaceship computer might include subsystems for life support, navigation, etc. [Rumbaugh 91, p. 199] Reusable Artifacts for Domain Analysis Reuse Domain analysis reuse is the reuse of knowledge of specific application domains. We mapped this type of reuse to whether a methodology provides concrete, real-world examples that show the analysis and design of information systems for specific problem domains. There are different ways to classify application domains. Conger provided a classification for business applications [Conger 94, p ]. However, her classification did not highlight other type of applications such as concurrent/parallel, distributed, client/server, etc. We adopted Conger s classification augmented with four other types of applications. One should note that those applications are not

10 IRMA 95 9 mutually exclusive. An example given in a methodology may fall into one or more application domains. 1. Transaction-oriented 2. Data analysis 3. Decision support 4. Expert applications 5. Numerical applications - heavily mathematics oriented and demanding a high degree of computation. 6. Parallel/concurrent - required to handle synchronization and concurrency control. 7. Distributed, client/server - required to handle issues such as data distribution, processing distribution, etc. Obviously, limited by the space, the literature of a methodology usually cannot provide a complete solution to a real-world problem. Nevertheless, the examples of a methodology do provide a sample the reader can emulate with the possibility of reusing the example in a similar real-world situation Comparison of Concepts Table II lists the comparison of the concepts for the three type of reuse. In each box, a check mark means that the corresponding methodology provides the artifact. A blank in a box indicates the absence of the concept from the methodology. The letter I in a box represents that the corresponding concept is not explicitly supported, however the discussion of the methodology seems to imply or suggest the concept. The first row of each type of reuse gives the sums of the number of concepts supported by a methodology; an implied concept is arbitrarily counted as 1/ Conclusion of Concept Comparison From the concept comparison in Table II, we can make several observations. First, a majority of those OOADMs support most of the concepts that contribute to design reuse. Only one methodology ([Shlaer & Mellor 90]) has significantly lower counts. One explanation could be that this methodology concentrates heavily on dynamic modeling that cannot be reused independently of the classes and objects. Dynamic modeling, by itself, does not create reusable artifacts. Classes/objects should be the lowest unit for reuse. The dynamic aspect of the system is only accounted for within one variable within this study, methods/messages. Therefore, our measure penalized this methodology. On the another hand, our measure singled out three methodologies proposed by Rumbaugh, et al., Booch and Jacobson, et al., respectively as providing a higher degree of support for the concepts that enable reuse.

11 IRMA TABLE II: COMPARISON OF CONCEPTS C&Y WB JR GB S&M IJ M&O Design Reuse (7) (7) (9) (10) (5.5) (9) (7) classes/objects meta-classes generic classes abstract classes encapsulation single inheritance multiple inheritance association I aggregation I I methods/messages Architecture Reuse (1) (1.5) (2.5) (3) (2) (3) (1) frameworks I I modules subsystems Domain Analysis Reuse (2) (2) (3) (4) (2) (2) (0) transaction-oriented data analysis decision support expert applications numerical applications parallel/concurrent distributed/client/server The comparison of architecture reuse support points one notable weakness among these OOADMs which is an uneven support of frameworks. Two methodologies have devoted a reasonable amount of discussion on the framework concept and the benefits of reusing frameworks. However, the remainder of the methodologies do not provide the same degree of treatment of the concept that is as adequate as other two concepts: modules and subsystems. The comparison result of domain analysis reuse support is disappointing. The comparison points out the shortage of well thought-out, concrete, real-world examples. There is one hidden fact that cannot be reflected by the counts. As shown in Table II, almost all methodologies used some application examples to demonstrate the usage of their methodologies. However, the

12 IRMA substance of the those examples vary significantly. Some methodologies provide good, simplified real-world applications, while others provide only toy-like examples. As discussed earlier, one explanation is the limitation of space. However, to enhance reusability, it would be useful for methodology writers to demonstrate the application of the methodology to various domains. 4.2 Comparison of Processes Brief Explanation of The Comparison Criteria The comparison criteria for the analysis and design processes (steps or activities) are identical among the three types of reuse studied. We believe that reuse should be integrated into analysis and design processes, and a good methodology should guide the developer to produce reusable artifacts in all levels. Based on this view, we classified the processes that support software reusability into the following categories: 1. Thinking reuse. The methodology reminds the developer to think about incorporating reusable artifacts at some steps during analysis and design but provides no specific guidelines and steps on how to reuse the artifacts. 2. Analyzing/designing from reusable artifacts. The methodology provides some specific steps and guidelines on how to incorporate reusable artifacts into the system to be developed. We divide the reusable artifacts into two categories, components and other artifacts, such as framework, modules and applications. 3. Analyzing/designing artifacts for reusability. The methodology gives some specific steps and guidelines on how to design artifacts so that the artifacts will possess a high quality and can be reused later. Again, we differentiate components from other artifacts. 4. Management of reusable artifacts. The methodology discusses and provides some guidelines for the management of reusable artifacts. The management issues include classification, storing, retrieval, customization, etc. Similarly, we distinguish components from other artifacts in the comparison Comparison of the Processes Table III presents the comparison results of process support for software reuse. The marks in the table are similar to those used in Table II Conclusion for Process Comparison As shown in Table III, the methodologies provide no specific steps on the incorporation, construction and management of reusable artifacts, except for one methodology ([Jacobson 94]). The support given by the other methodologies is in the form of an informal discussion of reuse and a limited set of guidelines. The support by all methodologies focuses exclusively on components. To achieve a higher degree of reusability, the writers of these methodologies should focus on reusable artifacts beyond components. The methodologies should look at reuse in a broader scope and provide necessary steps and guidelines.

13 IRMA think reuse Analyze/design using reusable artifacts TABLE III: COMPARISON OF PROCESSES C&Y WB JR GB S&M IJ M&O reusable components I I I I I I other artifacts Analyze/design artifacts for reusability reusable components I I I I I other artifacts Manage reusable artifacts reusable components other artifacts 4.3 Comparison of Documentation Support of the Seven OOADMs Understandability is a key factor to the successful reuse of an artifact. Diagrammatic notations have been widely accepted as essential both for clear thinking and for human communication. [Martin & Odell 92] We could compare the notations provided by those OOADMs based on a set of criteria such as completeness, rigorous, richness, etc. Unfortunately, there is not a widely accepted diagramming standard to compare against. An attempt to rate the methodologies based on those criteria is subjective. Following the research line we have drawn, we compare whether a methodology provides diagrammatic notations for all the concepts as listed earlier in Table II. Table IV lists the diagramming notations supported by the OOADMs. The marks in the table are similar to those used in Table II. In the last row of the table, the total number of diagramming notations of a methodology is given. Note that, some methodologies provide very fine-grained notations for some concepts. For example, Booch s methodology has several notations for modeling system dynamics. In the table, all notations that fall into a single concept have only one check mark. From Table IV, we can observe that a majority of the methodologies provide satisfactory diagramming notations. However, the difference between methodologies are very wide. This is partly caused by the number of concepts a methodology supports and partly by the grouping of notations of a single concept. The counts do not accurately tell how many diagramming notations are included in a single box in the table. Again, a methodology may be penalized if it has fewer notations for objects, classes and relationships but has extensive notations for a single concept.

14 IRMA TABLE IV: COMPARISON OF DIAGRAMMING NOTATIONS C&Y WB JR GB S&M IJ M&O classes/objects meta-classes generic classes abstract classes encapsulation single inheritance multiple inheritance association aggregation methods/messages frameworks modules subsystems total checker counts: (7) (7) (8) (12) (4) (10) (6) 5. SUMMARY AND CONCLUSION From this study, several observations have been made. All of the object-oriented methodologies compared claim reuse as a major benefit. In addition, the authors of the methodologies acknowledge that reuse does not happen automatically, even using an objectoriented approach. Reuse must be planned for and explicitly addressed. Though the authors acknowledge both of the prior statements, the methodologies provide somewhat limited explicit support for reuse, especially for specific steps and processes. However, a majority of the methodologies supply extensive concepts that provide the inherent characteristics that enhance the reusability of the artifacts developed. The diagramming notations for those concepts seems adequate for most of those methodologies. In the selected methodologies, most software reuse activities are centered around components. However, components are a low level of reuse compared with architecture reuse and domain analysis reuse. The weakness in these methodologies points to the ill-treatment of the following two artifacts: 1. Frameworks. Since frameworks have been regarded as achieving a high degree of software reuse, methodologies should provide necessary support for it, ranging from diagramming notations to the analysis and design steps and guidelines. 2. Well-developed applications. To make reuse happen at the application domain level, methodology writers should apply their methodology to real-world projects and build complete cases from which other developers can benefit.

15 IRMA All those methodologies lack analysis and design steps and guidelines that are specific for incorporating reusable artifacts into a system being developed, for designing reusable artifacts, and for managing reusable artifacts. One positive sign from this study is that the newer methodologies, notably Booch s methodology and Jacobson s methodology, scored higher than other older methodologies. It marks the maturation of this field, though much improvement needs to be done. In these newer methodologies, software reusability begins to be integrated into the methodologies. We expect the trend will continue in the future as the maturing of the object-oriented technology and the increasing demand for high quality and low cost software systems continue. The contribution of this study is to provide an inside view of the software reuse support by the selected OOADMs and to point out the weaknesses of the OOADMs. Because these OOADMs represent a majority of well publicized, highly acclaimed methodologies, our findings are representative. The information we provide here can help researchers improve the research into software reusability, and can benefit practitioners and managers in their studying, selection and adoption of OOADMs. This study, however, has several limitations. One is that the comparison instrument is simple. It provides useful information, but fails to capture complete information. For example, the degree of the reuse support by a methodology cannot be fully described. Future research should build upon the approach and assign weights to the comparison variables to develop better measurements. 6. BIBLIOGRAPHY [Berard 93] Berard, Edward V. "Object-Oriented Domain Analysis." chapter in Essays on Object- Oriented Software Engineering, by Edward V. Berard. Englewood Cliffs, N.J.: Prentice-Hall, 1993, Biggerstaff, T.J. and A.J. Perlis. "Introduction" to Software Reusability: Volume I Concepts and Models, edited by T.J. Biggerstaff and A.J. Perlis. New York: ACM Press, 1989, xv-xxv. Biggerstaff, Ted and Charles Richter. "Reusability Framework, Assessment, and Directions." in Software Reusability: Volume I Concepts and Models, edited by T.J. Biggerstaff and A. J. Perlis. New York: ACM Press, 1989(b), Booch, Grady. Object Oriented Analysis and Design with Applications. 2nd Edition, Redwood City, CA: Benjamin/Cummings Publishing Co., Booch, Grady. Object Oriented Analysis and Design with Applications, Second Edition. Benjamin/Cummings Publishing Co., Brinkkemper, S. Formalisation of Information System Modelling. Thesis Publishers, The Netherlands, Bulthuis, Arjan. A Formalization and Comparison of Ten Object-Oriented Analysis and Design Methods. Unpublished Master Thesis. Department of Computer Science, University of Twente, 1994.

16 IRMA Cardelli, Luca and Peter Wegner. "On Understanding Types, Data Abstraction, and Polymorphism." Computing Surveys, (December 1985): Coad, Peter, and Edward Yourdon. Object-Oriented Analysis. Englewood Cliffs, N.J.: Yourdon Press, Coad, Peter, and Edward Yourdon. Object-Oriented Design. Englewood Cliffs, N.J.: Yourdon Press, 1991(b). Conger, Sue. The New Software Engineering. Wadsworth Publishing Company, Freeman, Peter. "A Perspective on Reusability" in Tutorial: Software Reusability. edited by Peter Freeman. Washington, D.C.: Computer Society Press of the IEEE, 1987, 2-8. Freeman, Peter. "Reusable Software Engineering: Concepts and Research Directions." in Tutorial: Software Reusability. edited by Peter Freeman. Washington, D.C.: Computer Society Press of the IEEE, 1987(b), Goldberg, Allen. "Reusing Software Developments." Software Engineering Notes (December 1990): Goor, Geert van den. A Formalization and Comparison of Six Object-Oriented Analysis and Design Methods. Unpublished Master Thesis. Department of Computer Science, University of Twente, Goor, Geert van den, Brinkkemper, S., Hong, S. Object-georienteerde ontwerpmethoden. Informatie, Jaargan 35, nr. 12, pp , Hodgson, R. "The Impact of Software Reuse on Object-oriented Methods." in Software Reuse and Reverse Engineering in Practice, ed. P.A.V. Hall. London: Chapman & Hall, 1992, Hong, S., Goor, van den, Brinkkemper, S. A Formal Approach to the Comparison of Object-Oriented Analysis and Design Methodologies. Proc. of the 26th Hawaii International Conference on System Sciences, Vol. IV, pp , Horowitz, Ellis and John B. Munson. "An Expansive View of Reusable Software." in Tutorial: Software Reusability. edited by Peter Freeman. Washington, D.C.: Computer Society Press of the IEEE, 1987, Jacobson, I., et al. Object-Oriented Software Engineering: A Use Case Driven Approach. Addison-Wesley Publishing Company, 1993 Johnson, Ralph E. and Brian Foote. "Designing Reusable Classes." Journal of Object-Oriented Programming (June/July 1988): Jones, T. Capers. "Reusability in Programming: A Survey of the State of the Art." in Tutorial: Software Reusability. edited by Peter Freeman. Washington, D.C.: Computer Society Press of the IEEE, 1987, 2-8.

17 IRMA Kennedy, Brian M. "Design for Object-oriented Reuse in the OATH Library." Journal of Object-Oriented Programming (July/August 1992): Koelzer, Barbara A. "Object-Oriented Software Reuse: An Analysis of Methodology Support." research report, Department of Computer Information Systems, Georgia State University, Krueger, Charles W. "Software Reuse." ACM Computing Surveys (June 1992): Lee, Elgin. "The Journey of a Thousand Miles." Computer Language (October 1991): Lewis, John A., Sallie M. Henry, Dennis Kafura, and Robert S. Schulman. "An Empirical Study of the Object-Oriented Paradigm and Software Reuse." in OOPSLA '91 Proceedings, 6-11 October 1991 in Phoenix, Arizona. New York: ACM Press, 1991, Lippman, Stanley B. C++ Primer, 2nd Edition. Reading, Massachusetts: Addison-Wesley, Martin, James, and James J. Odell. Object-Oriented Analysis & Design. Englewood Cliffs, N.J.: Prentice Hall, McGregor, John D., and David A. Sykes. Object Oriented Software Development: Engineering Software for Reuse. New York: Van Nostrand Reinhold, Meyer, Bertrand. "Reusability: The Case for Object-Oriented Design." in Software Reuse: Emerging Technology, ed. Will Tracz. Washington, D.C.: Computer Society Press of the IEEE, 1988, Meyer, Bertrand. Object-Oriented Software Construction. Prentice Hall, 1988(b). Prieto-Diaz, Ruben. "Domain Analysis for Reusability." in Software Reuse: Emerging Technology, ed. Will Tracz. Washington, D.C.: Computer Society Press of the IEEE, 1988, Rumbaugh, James, Michael Blaha, William Premerlani, Frederick Eddy, and William Lorensen. Object- Oriented Modeling and Design. Englewood Cliffs, N.J.: Prentice Hall, Shlaer, S., Mellor, S.J., Object Lifecycles: Modeling the World in States. Prentice-Hall, Tracz, Will. "Where Does Reuse Start?" Software Engineering Notes (April 1990): Wegner, Peter. "Varieties of Reusability." in Tutorial: Software Reusability. edited by Peter Freeman. Washington, D.C.: Computer Society Press of the IEEE, 1987, Wijers, G.M., et al. Representation of Information Modelling Knowledge. Report 90/09, Software Engineering Research Centrum, Netherlands, Novermber Wirfs-Brock, Allen and Brian Wilkerson. "Variables Limit Reusability." Journal of Object-Oriented Programming (May/June 1989): Wirfs-Brock, R., Wilkerson, B. and Wiener, L. Designing Object-Oriented Software. P T R Prentice Hall, 1990.

18 IRMA Wirfs-Brock, Rebecca J. and Ralph E. Johnson. "Surveying Current Research in Object-Oriented Design." Communications of the ACM (September 1990): Yourdon, Edward. Decline & Fall of the American Programmer. Englewood Cliffs, N.J.: PTR Prentice Hall, 1992.