Two Object Oriented Methodologies Booch And Rambaugh Information Technology Essay

Two Object Oriented Methodologies Booch And Rambaugh Information Technology Essay In this paper Object-oriented System development methodologies i-e Booch, Rambaugh, are reviewed and compared with each other with a focus on their development processes. We have developed a framework based on a set of criteria to compare the two methods. The aim of this comparison is to better understand the core philosophies and processes of each method, and internal activities that each method provides. The aim of this descriptions and comparisons are not to criticize the philosophies of theses methodologies, but to give a description of the two methodologies that will facilitate the readers to better understand each methodology, and to what extent the two methodologies are object oriented. And also this comparison provides an ease in selecting and evaluating each methodologys process. (doc1)The software engineering field has been evolving over the past thirty years, but it has never completely solved the software crisis. Software development methodologies, as an essential element of the discipline of software engineering, have also evolved from the shallow and informal methodologies of the late 1960s to the object-oriented methodologies of the 1990s and the new millennium (doc1). There is a rapid development in the object oriented paradigm during the past years and the important reasons for such rapidness are that the real world applications are modeled in a better way as well as the object oriented paradigm enables the reusability of different artifacts during the development of a software system. Object oriented system development approach facilitates the re-use of software components. A system developed with Object Oriented Methodology (OOM) on component basis can re-use the existing components effectively, and as well as its components can be shared by some other systems too. One can achieve higher productivity, better quality and low maintenance cost by adopting the OOM. Since, the object-oriented methodologies (OOM) are still growing and continue to evolve, and there are a number of popular OOMs circulating around, but none of them is widely accepted. The software community is yet not agreed upon several fundamental issues. (1) A methodology is a systematic collection of techniques guidelines for how to build, buy, maintain and/or enhance software products. A methodology provides a basis for communication, a toolkit of techniques and a basis for repeatable, reliable software engineering. The term, method, refers to an approach to activities generally adhering to common principles [14]. Object-oriented software development methodologies, starts from the appearance of hybrid methodologies, then move to seminal methodologies, and the development of integrated (third-generation/heavyweight) methodologies and their agile (lightweight) counterparts. The following are the categories of Object oriented methodologies [15]: Seminal: Shlaer-Mellor, Coad-Yourdon, RDD, Booch, OMT, OSA, OOSE, BON,Hodge-Mock, Syntropy, Fusion; Integrated: OPM, Catalysis, OPEN, RUP/USDP, EUP, FOOM; Agile: DSDM, Scrum, XP, ASD, dX, Crystal, FDD; Although the promises, that the object-oriented software development provides, are based on solid grounds but still there is a confusion among the organization on when and how to invest in this new technology and also whether to invest or not. One of the reason for such confusion is that a great number of methodologies have been evolved during the last years. The other reason for confusion is closely related to the attractiveness of object-oriented software: Many vendors sticks the label object-oriented to their products without delivering important features as King (1989, p. 24) states: If I were trying to sell (my cat) I would argue that he is object-oriented. Research Problem The research question we are going to answer is: To what extent the two Object Oriented Methodologies: Booch and Rambaugh methodologies are Object Oriented and to what extent the methodologies help the software development organizations?. The selection cretaria for the the above two OOM is mentioned in the section 1.4.2. Since the object oriented paradigm evolved in different areas of the software development simultaneously, therefore fundamental concepts were different in different methodologies and were not completely standardized. Each OOM developed in a particular software domain such as real time systems and Information systems, although some cross-over exists in some concepts among the methodologies. Therefore, some methodologies are best in the development of applications that belong to the domain for which the methodology is evolved, while other can be used more generally. Even though OOM that evolved in the same domain may differ enough in different concepts such as process and notation and as a result can effect the software engineering goals. Motivation In the recent years, an overwhelming popularity of object oriented analysis and design has been witnessed. This phenomenon is evidenced by the number of papers and articles that are published in various conference proceedings, journals, books, and other forms. But There are still a large part of the business world that uses traditional software development approach for applications development. And on the technology side, there is an extensive development in the area of Object-Oriented technologies that promises better quality and productivity through reusability, and also encourages team work. The following observation is made in a survey [] about the organizations that uses OOM, performed by Sumit: A recent survey of IS managers revealed that 39% of organizations have adopted OO technology in some form. Nonetheless, OO development methodologies are used in only 5% of IS projects are developed in OO methodologies (Glass, 1999). For a specific application the first task is to decide which methodology is most appropriate for its development. Sometimes we may have to adapt different methodologies. Therefore an organization, that wants to switch to object oriented technology, faces one important question: which OOM is appropriate and should be chosen? A systematic comparison of available OOMs can answer such a question in a better way before selecting one of them. There are number of papers and articles that compare different aspects of the OOMs such as the reusability, documentation and others. So there is a need for the comparison which considers their system development core philosophy including all the concepts that methodologies provide in their development process. Unfortunately, the comparison of these methodologies is complicated because each OOM has its own set of definitions of the techniques, concepts, notations and are composed of informal descriptions, therefore the comparison of the methodologies depends largely on the interpretations and perceptions of the person who performs the comparison[10]. Such a comparison facilitate the organization that are developing software with traditional approach and now these organizations want to switch from the traditional software development approach to object oriented approach.. We also want to improve the understanding of these methodologies through this comparison, and to provide an ease in selecting, and evaluating the methodologies. The other purpose is to provide knowledge to the individuals that are interested to get the knowledge about object-oriented concepts, to what extent the two methods are object oriented, and how they relate to one another. Such interest in some cases is academic (e.g., students). Similarly individuals in companies or organizations want to evaluate and select a methodology to be used in software development process. We believe that sometime these groups are given short time and resources to make this decision, therefore comparisons like this will provide a shortcut means of selection. Research Methodology and comparison issues First we will review the existing software development methodologies (seminal methodology) that are object-oriented. We will study their system development processes to get a knowledge base about the object oriented technology. The purpose of this study is to understand their system development processes and internal activities involved in these development processes. Then we will review the two methods using a process-centered template, where we will summarize the two methodologies, and the activities and techniques discuss in the two methodologies will be highlighted. In the second step we will evaluate and compare Booch and Rumbaugh Object Oriented. We will use books, journals, proceedings, and internet sources as the data sources about the object oriented methodologies and ongoing research to gain the knowledge base. This report compares the two object oriented methodologies: Booch method and Rambaugh method, by considering their system development core philosophy. A research has been done in Hewlett Packard Laboratories by Arnold and his colleagues [1], in which several comparing criteria are defined in the form of questions for comparing Object oriented Methodologies. These comparing criteria are based on the concepts, notations, process, and pragmatics of the OOM methodology. Influenced by the above research, this report presents a framework to compare the two selected methodologies using the same set of criteria form the above research. The framework uses these set of comparing criteria for comparing the concepts, notations, process, and pragmatics of the two selected methodology which are defined in the section 1.5.1 under the heading of comparison variables. Using such framework helps us to avoid misunderstanding and misinterpretation of the two methods during the comparison process. Based on this framework, the two methods are extensively compared. The results are presented in a set of tables. Since the results are in tabular form so the similarities and differences as well as the strengths and weaknesses of the two methods can easily be seen. Comparison Variables As mentioned above, this report uses four main categories of the two methodologies in the comparison which are defined as follows: Concepts: Concepts are related to the conceptual underpinnings of the methodology that makes it object-oriented, and explians how the concepts such as object, class, state, inheritance, aggregation, and information hiding are defined and dealt by the methodology? Process: The methodology describes what steps to be taken and in what order to accomplish certain task in develoment process. How well the methodology specifies the process varies largly from methodology to methodology. Notation: The methodology describes tecniques (textual, and /or graphical) to capture and represent information within the development process. Some methodologies describe graphical techniques only, while others specify the form and content of whole documents. Pragmatics: The pragmatic criteria concentrate on nontechnical features. Pragmatics covers issues like needed resources, language suitability, learning of the CASE tools, required expertise, and domain applicability.(8) Comparison variables are listed in Table 1 under each category. The selection criterion for these variables is objectiveness. The aim of this report is to do the objective comparison of methodologies. That is, hard facts are produced by these variables about a methodology showing that a methodology either supports or does not support these variables. This selection criterion has one limitation. That is, no fine grained information regarding a variable is provided in this report for the comparison. Typically, the degree to which a methodology supports a variable is not answered in this comparison. In order to alleviate this shortfall for some variables, the report distinguishes explicit methodology support from implicit methodology support in the comparison and provide fine grained information if appropriate. The definitions of these variables in Table I are delayed until Section 3 when the selected OOADMs are compared. Table 1: Comparison variables Category Variables Concepts Class/Object, Abstract Classes, Meta-Classes, Encapsulation, Inheritance, Association, Aggregation, Methods/Messages, Type of Communications between objects and classes, Concurrency Process Development Process Deliverables, Development Context, Aspects of the Development Life-Cycle, Partitioning Mechanism, The Life-Cycle of the Methodologies Notations Static Concepts, Dynamic Concepts, Explicit Rules for Notations Symbols Pragmatics System Size, Programming Languages Support Selection of OOMs As mentioned above that this report compare the following two OOM for comparison. Object-Oriented Modeling and Techniques by J. Rumbaugh, et al. [Rumbaugh 91] Object-Oriented Analysis and Design by G. Booch [Booch 94] The selection of OOMs is based on three criteria. First the Object Oriented Methodologies (OOM) must be published in text book form so that adequate information is available for our comparison; which narrowed down our selection to those OOMs that are available in the text book form. Second the OOMs should be well-known and must be accepted by the software development community as real object-oriented methodologies. Third the methodologies must be supportred by CASE tools. The two OOM, selected in this report for camparison, fulfill and satisfy the three criteria [1, 10]. Both Booch, and Rumbaugh, which are the most widely used OOM, have evolved either from the real time domain or information processing domain and also are used in general. The two methodologies has gained significant attention so far in the software development community and are well documented at the same time. These criteria might exclude some well-known OOMs or recent developments in the OOM, but sufficiency, maturity and general acceptance of methodologies are the primary requirements for software development practice. Literature review Limitation This paper evaluates the aforementioned methods by scoring them against a set of criteria. It is not the goal of the paper to answer the question which one is the best? But rather to show the differences between methods and to allow conclusions be drawn as to their applicability. Remaining of report is divided into four sections. Section 2 provides a brief introduction of the two methodologies. Section 3 contains the comparison of the two methodologies. Section 4 presents the conclusion for the comparison of the two OOMs. Finally, section 5 contains the references to the literature used for this research. Brief introduction Of the Booch And Rambaugh (OMT) Methods Booch (1991, 1994) Booch introduced object oriented methodology in his book published in 1991. He was the first one to give the idea of the object-oriented approach in software development process, which he called system design [2][3]. He was popular at that for his landmark paper [Booch 1986] and for the work on Ada program design. He then introduced the analysis methodology to his design and extended his design model as a repeating process which he called The Micro Process) within a development process which is referred as The Macro Process. The macro process is shown in the figure 1 below as prescribed by Booch which is a self-iterative process Figure 1- The Macro Process -Booch [1994] These two processes are discussed in the next sections. The Macro Process The macro process consists of the following steps [2] [3] [4]. 1. Establish core requirements for software (conceptualization). 2. Develop a model of the systems desired behavior (analysis). 3. Create architecture for the implementation (design). 4. Evolve the implementation through successive refinements (evolution). 5. Post-delivery evolution management (maintenance). The Micro Process The micro process consists of the following activities as shown in figure 2 below [2] [3] [4]: The classes and objects are identified at a given abstraction level. Figure 2-The Micro Process Booch [1994] 2. Previously identified classes and objects meanings are established by defining the Semantics for every class and object, as well as the behavior of the system and its components are determined. 3. The interface of classes and objects as well as their implementation are specified. Decisions about the representation of the classes and objects are made in design model. Rambaugh OMT (1991) Rumbaugh introduced Object Modeling Technique (OMT) in 1991.OMT consists of following three major models and then it defines a method for integrating them [11] [12]. 1. The Object Model 2. The Dynamic Model 3. The Functional Model The object model In this model, Objects static structure and relationships among these objects are determined within a system. The following are the main concepts used in this model: object class operation attribute association aggregation Inheritance Dynamic model This model gives a description about the dynamics of the objects and their changes in states. This model shows the essential characteristics that change over time in a system by observing the objects behavior over time, and by exploring control and events flow among the objects. The control aspects of a system are specified and implemented in this model. The following are the main concepts in this model: state sub/super state event activity action Functional model This model shows information about the data flow within a system and the outside world. The following are then main concepts of this model: process data flow data store actor (source/sink) control flow OMT consists of five phases. 1. Analysis 2. System Design 3. Object Design 4. Implementation (coding) 5. Testing OMT processes considers the primary features in the first three phases of development (i-e Analysis, System Design and Object Design) and are explained in following sections. The following figure 3 shows these processes. Figure 3.-The OMT process- Derr [1995]. 1. Analysis this phase goal is to build a comprehensible and correct model according to the real world situation. The initial problem statement is developed from the requirements of the users and information that are provided by developers and managers. The analysis phase produces the following deliverables [11] [12]: Problem Statement Object Model, which consists of Object Model Diagram and data dictionary Dynamic Model, which consists of State Diagrams and Global Event Flow Diagram Functional Model, which consists of Data Flow Diagram and constraints 2. System design on the bases of architectural design of the system and problem domain, the system is partitioned into subsystems. The following are the system design phase deliverables: System Design Document: consists of architectural design of the system and high-level strategic decisions for implementing data stores in the form of data structures, files, and databases. 3. Object design based on the analysis model, the goal of this phase to provide Implementation details that include the domain infrastructure classes along with the internal objects needed for implementation. The following are the object design phase deliverables: Detailed Object Model Detailed Dynamic Model Detailed Functional Model 4. Implementation in this phase the system that is designed so far is translated into programming language code and hardware. 5. Test The entire System that is developed is verified in this phase. Testing includes system level and scenario based tests. Comparison Of Booch and Rambaugh methods The framework used in this paper is considering the following major areas of each methodology for comparison: Concepts Process Notations Pragmatics 3.1 Concepts A method to be consider as object oriented, it should support concepts that are related to the object oriented methologies. This comparison provides help in evaluating the method to the extent it is is object oriented. Therefore , in this paper we are comparing object oriented concepts of the two methodologies, Booch and Rambaugh, in the following categories. Concepts, such as Class, Object, etc. The relationships such as Inheritance and Aggregation Types of communications between objects and classes. Concurrency mechanisms Object is the fundamental concept of every object-oriented method, that must be supported by the method. An object encapsulates its internal state (or attributes) and provides a set of operations (methods/messeges) as an interface for manipulating the state. Whereas a class is a template which describes the attributes and interface of a set of objects. Object instances are produced by defining class variables.[5] Table 1 lists comparison of the object oreinted concepts that both methodology provides. A Y in the box for each concept represents that an artifact is provided by the coresponding methodology. Table 1. Object Oriented concepts Method Rumbaugh Booch classes/objects Y Y abstract classes Y Y meta-classes Y Y Encapsulation Y Y single inheritance Y Y multiple inheritance Y Y Aggregation Y Y Association Y Y methods/messages Y Y Total 9 9 Real world is concurrent, so object oriented methods often uses concurrent objects in the analysis phase to model it. Objects remain in passive mode, until an operation is invoked by another object to bring them in active mode. If there are more than one thread of control associated with active object, then it is called internally concurrent object. Therefore object oriented methods should support ways to access the shared data in concurrent systems.[5] Table 2. Concurrency Method Passive Active internally concurrent Rumbaugh Y Y Y Booch Y Y Communiication provides information flow and synchronization between objects that are involved in the communication. In Synchronous communication the sender object send a messege to the reciever object and suspend execution until it receives an aknowlegment message from the reciever, whereas in asynchronous communication the sender does not wait for the aknowlegment and continues its execution. Sequential systems uses procedural call whereas concurrent object systems uses remote procedure Call for communication. Table 3. Communication Method Synchronous Asynchronous Procedural Remote procedure Rumbaugh Y Y Y Booch Y Y Y Process 3.2.1. Deliverables that are produced during the Development Process: A number of different types of deliverables are generated during the development process of a system. These include a number of specifications likely requirements, analysis, design, subsystem, and test cases. Particularly, in object-oriented development process, object and classes specifications are very important. Following criteria is used to find out the deliverables that each methodology generates during the development process: 0 shows no deliverable is generated. 1 shows deliverable is generated, but details are not provided. 2 shows deliverable is generated and also well defined. 3 shows deliverable is generated, a definition is provided, and an example is given. 4 shows deliverable is generated, a definition is provided, and an example is given, and a definition for the process is provided. 5 shows deliverable is generated, a definition is supplied, an example is given, a definition for the process is provided, and heuristics are provided. The following table 4 represents the results of this evaluation: Table 4: Development process deliverables Method Rumbaugh Booch Requirement Specification 2 1 Design Specification 2 2 Test Cases 0 0 Object/Class Specification 5 1 Subsystem Specification 0 1 Totals 9 5 3.2.2. Development Contexts A set of constraints occur during the development process which are established by development context. The following criteria are used to evaluate that whether each methodology explicitly discusses the constraints that are established by the development context, or not within the method. A Y in the With Prototyping column shows that prototyping is discussed explicitly in the methodology. A Y in the As Prototyping indicates that prototypes iteratively deliver the system and methodology produces prototypes into production. A Y in the With Reuse shows that the methodology explicitly incorporate the reuse products into the method The For Reuse indicates whether the methodology delivers reusable products for other processes or not. Table 5: Development Context Method Rumbaugh Booch With Prototype Y As Prototype With Reuse Y Y For Reuse Partial Y Aspects of the Development Life-Cycle The whole development life cycle of a methodology gives us a suggestion about the completeness and consistency of the methodology. If a methodology covers all aspects of the development lifecycle during the development process then it ensures the completeness and the consistency of the methodology and it is useful to the organization as a complete and consistent methodology. Therefore, complete life cycle coverage is very important to a life cycle with a limited coverage. Following table 6 values shows these aspects: 0 shows this feature is not covered. 1 shows this feature is covered, but with no details. 2 show this feature is covered with definition. 3 shows this feature is covered, a definition is given with an example (at least one). 4 shows this feature is covered, a definition is given with an example (at least one) and with defined process. 5 shows this feature is covered, a definition is given with an example (at least one) and with defined process, and heuristics are provided. Table 6: Development process life cycle coverage Method Rumbaugh Booch Domain Analysis 0 4 Requirement Analysis 5 2 Enterprise Modeling 0 0 Design 5 5 Implement 3 4 Test 2 0 Total 15 15 In software engineering Extensibility of the system design is a systematic measure of the ability to last or continue. A level of efforts is required to extend a system in range or scope. Table 7: Extensibility Method Completeness Consistency Extensibility Rumbaugh Y Y Y Booch N N N Table 8: Process properties Method Well-defined steps(process) Pure or hybrid Traceable across lifecycle Rumbaugh Y H Y Booch Partial P Partitioning Mechanism When system size increases, then at a particular time, the visibility of certain information about the objects of interest is very crucial and to limit this visibility a partitioning mechanism is required. Each methodology was studied carefully to seek such mechanisms it provides. So the information in the table below was the outcome. Table 9: Partition mechanism Method Partitioning Mechanism Rumbaugh Subsystems Booch Subsystems The Life-Cycle of the Methodologies The development life-cycle of each methodology was carefully reviewed so as to determine that whether the methodology follows a sequential (i-e Waterfall), iterative or recursive strategy because it is the crucial requirement for project planning. Otherwise it will yield unexpected results with high risk and would lead to total failure. The following table 10 shows that which methodology follows what strategy. Table 10: life cycle property Method Recursive Iterative Sequential Rumbaugh Y Booch Y 3.3 Notations 3.3.1. Static Concepts Each methodology was reviewed to determine that how each methodology represents the following concepts: Aggregation: what are the components an object is a composed of. Communication: How the classes or objects communicate with each other(i-e by sending message to one another) Specialization: An object is represented as a generalization, or specialization, of another class or object? Module Interfaces: The physical implementations of objects Qualifications for Reuse: How much each methodology encourages the reuse of different components of development process. These concepts within each methodology indicates that how the models are used. The table 11 below shows the notations for these concepts. Table 11: Static Concepts Method Rumbaugh Booch Aggregation Object Model Class Diagram Specialization Object Model Class Diagram Communication Scenario Class Diagram Module Interfaces Module Qualifications f