Object-Oriented System Development

Published on June 2017 | Categories: Documents | Downloads: 23 | Comments: 0 | Views: 244
of 8
Download PDF   Embed   Report

Comments

Content

1

Object-Oriented System Development: Will the New Approach Solve Old Problems?
G. Engelsa and G. Kappelb aDept. of Computer Science, Leiden University, P.O. Box 9512, NL-2300 RA Leiden, The Netherlands bDept. of Computer Science, University of Linz, Altenbergerstr. 69, A-4040 Linz, Austria Object-oriented system development is wideley recognized as improving productivity and reducing system maintenance costs. However, existing approaches have not su ciently addressed the following three questions which are equally important to users and researchers. Firstly, what are the bene ts of object-oriented system development compared to traditional approaches? Secondly, what are the essential features of an objectoriented life cycle model to ful ll the bene ts of object-oriented development? And thirdly, what are the pitfalls of object-oriented development and how to cope with them? The paper investigates answers to all three questions in concert.

Abstract

Keyword Codes: D.1.5; D.2.1; D.2.10 Keywords: Programming Techniques, Object-oriented Programming; Software Engineering, Requirements/Speci cation; Software Engineering, Design

1. Introduction
Building quality systems has been the driving goal of all software engineering e orts within the last two decades. Among the key qualities a system should support are maintainability, and reusability. Object-orientation is discussed as new paradigm which helps in building such maintainable, and reusable systems. Object-oriented languages 9] and development environments 6] go already a long way in providing support for building such systems. But, for their own, they are not a panacea for building quality systems. They have to be accompanied by a life cycle model which supports both reusability throughout the whole life cycle and the development of open, i.e., maintainable systems. Reusability of components requires that reusable components have been developed in the rst place. Reusable components comprise analysis results, design results, and software components. Thus, a life cycle model which supports reusability has to support the development of reusable components, too 11]. The development of open systems necessitates the adaptability to changing requirements. Thus, a life cycle model for open system development has to treat maintenance

2 as integrated part of the whole development process 10]. In the following sections we introduce a life cycle model which ful lls the above requirements. We will uncover existing de ciencies of the object-oriented approach, and we'll point to future research directions. As a prerequisite for a deeper understanding of object-oriented development, and to ensure acceptance of the new approach among both developers and clients, the commonalities and di erences between structured and object-oriented development as well as the bene ts of the object-oriented approach are discussed beforehand.

2. From Structured Development to Object-Oriented Development
Structured development has undergone considerable changes since its early beginnings in the seventies. At that time structured development did only take into account the process perspective of a system 2]. Meanwhile, there exist several approaches to structured development modeling the data perspective and the behavior perspective of a system next to the process perspective (e.g., 5,12,13]). These three perspectives are also treated during object-oriented development. Thus, in the next subsection an evolutionary transformation from structured to object-oriented development is exhibited.

2.1. Three Perspectives of a System

It is well-known, that there are three fundamental perspectives of a system, which are data (with whom does something happen?), behavior (when does something happen?), and process (what happens?) 8]. Structured development emphasizes the process perspective. It starts from the required top most functionality of the system and continues top-down with functional decomposition. Data and functions accessing these data are independently analyzed, designed, and implemented. Only in a second step, the events which drive the processes are analyzed. The data perspective plays a minor role compared to the other two. Thus, the hit list of the three system perspectives due to their priority in structured development is rst, process, second, behavior(= events), and third, data. Structured development for real-time systems emphasizes the behavior perspective. This branch of structured development has evolved out of the necessity of modeling event-driven systems, such as real-time systems and interactive systems. It starts out with the analysis of events. In a second step, the data which is accessed in response to the events is modeled. The process perspective plays a minor role compared to the other two. Thus, the hit list of the three system perspectives is rst, behavior, second, data, and third, process. Object-oriented development emphasizes the data, i.e., the object perspective. Only in the very rst step, the system functionality has to be identi ed (similar to structured development), as the user of a system asks for a certain system functionality. He or she is not interested in objects per se! Afterwards, all development steps focus on objects. During these steps, it is investigated which objects and which behavior of these objects are involved to ful ll a system functionality. The main di erence and at the same time the main advantage compared to structured development is the following. The system architecture based on structured development consists of a hierarchy of functions with exactly one function at the top. Any changes to the system functionality might imply severe changes to the system architecture. Contrary, the system architecture based on

3 object-oriented development consists of a set of interacting objects. Changes to the system functionality imply local changes to objects like changing existing operations or adding new operations, but do not impair the underlying system architecture. Events control the behavior of objects. If a message is sent to an object, i.e. an event is raised, the object executes a corresponding operation in turn. Thus, the hit list of the three system perspectives due to their priority in object-oriented development is rst, data, second, behavior, and third, process. Corresponding to the three perspectives, three modeling techniques have been used in structured development. These are Entity/Relationship Diagrams for data modeling, State Diagrams for behavior modeling, and Data Flow Diagrams for process modeling. All three diagram techniques or dialects thereof are also used during object-oriented development. Entity/Relationsip Diagrams are employed for modeling the structural information of objects, and state diagrams for modeling the behavior, i.e. the possible life cycles of objects. Finally, a Data Flow Diagram is used to specify the intrinsics of a single operation. In general, it will consist of calls to other operations on the same or on di erent objects.

2.2. Bene ts of Object-Oriented Development

The main advantages of object-oriented development compared to structured development can be summarized in the following three points. 1. encapsulation of data and functions into object classes 2. same concepts in analysis, design, and implementation 3. database view and application program view grow together

Concerning the rst point, encapsulation is one of the underlying principles of the object-oriented paradigm. Due to the encapsulation of data and functions into object classes some basic consistency constraints are insured, such as there does not exist any function without corresponding data, which has to be insured manually in structured development. Concerning the second point, the object-oriented paradigm is used in all phases during system development. Contrary to structured development, where there is a gap between analysis and design, object-oriented analysis (OOA) and object-oriented design (OOD) are based on the same concepts and modeling techniques. Yet, their aims are di erent. The aim of OOA is to describe the problem domain in terms of an application model . This is done by executing the following steps being essential for any object-oriented analysis independent of a speci c development method. 1. 2. identify the system functionality identify the involved objects identify the object classes identify the classes' exported operations to ful ll the system functionality (= su ered interface of an object class)

4
Real World Problem System Model of Solution Domain - base objects - system objects Appl. Model of Problem Domain - problem domain objects - user interface objects - control objects

OOA

OOD

Figure 1. Relationship between Analysis and Design (after 7]) 3. 4. 5. 6. identify the properties of the object classes identify the life cycles of the object classes identify the partOf and isA relationships identify the operations required from other object classes to ful ll the behavior of a speci c class (= required interface of an object class) identify associations between object classes identify coordination constraints between object classes identify subsystems of functional cohesive classes

The aim of OOD is to describe the solution domain in terms of a system model consisting of the enhanced application model of OOA, enriched with architectural information (concerning hardware platform and system software) and implementation speci c information (concerning performance restrictions and limited concepts in the implementation environment). The input to OOD is the output of OOA plus implementation contraints. The relationship between OOA and OOD is depicted in Figure 1. The system model of OOD includes the application model of OOA, but in general is more. For example, the data management component is part of the solution to some problem but not part of the problem itself. A possible distinction between OOA and OOD is in terms of the objects which are encountered during both phases. During OOA problem domain objects, user interface objects, and control objects are speci ed 3]. Problem domain objects represent real world objects and concepts of the problem domain, such as Client, Account, and Contract of a banking system. Since the output of OOA is not only a domain analysis but a high-level speci cation of the system to be developed, also user interface objects and control objects are speci ed. User interface objects represent the look and feel of the system to be developed, as it is perceived by the user. And control objects represent the system to be developed itself. The operations of the control objects model the requested system functionality. Whereas these three categories of objects are application dependent,

5 base objects and system objects are application independent. They are used during OOD to enhance the application model with implementation speci c information. Base objects represent basic functionality, such as basic data structures, numbers and prede ned user interface objects. System objects represent system functionality of the underlying hardware and system software, such as an interface to a database management system and a debugger window. Concerning the third and last point, the object-oriented paradigm is used both for programming languages and for database systems. The problems of coupling programming languages and database systems based on di erent modeling paradigms are well known as impedance mismatch . This metaphor describes the problems caused by two di erent paradigms, the programming language paradigm and the database paradigm. Whereas traditional programming languages may be characterized as being procedural, supporting record-at-a-time processing and complex structured data types, traditional (relational) database systems can be characterized as being declarative, supporting set-at-a-time processing, and simple data types. The object-oriented paradigm helps to overcome the disadvantages of working with two di erent worlds. The data model of an object-oriented database system is based on similar concepts as the semantic model underlying an objectoriented programming language. The schema of an object-oriented database system consists of a set of objects which are developed in terms of the same analysis and design concepts as object-oriented systems in general. The seaming schism between database view and application program view is resolved due to the same underlying object-oriented modeling paradigm.

3. Object-Oriented Life Cycle Model
We already stated the most important requirements an object-oriented life cycle model should ful ll. These are, rstly, the support of evolutionary software development , i.e., the maintenance phase is an integrated part of this evolution - the rst product version which is shipped to the customer is at the same time the rst maintenance version. And secondly, the development of reusable components as necessary prerequisite for providing reusability throughout all development phases. An additional requirement tightly coupled to the previous one concerns the bootstrap problem of development with reusability. Since it may happen that there are no reusable components the life cycle model should support application development with various degrees of reusability . The state of practice in terms of reusability is focused on reusable class libraries. A class library consists of a set of independent classes, implemented in some object-oriented programming language and providing some basic functionality, such as basic data structures. However, the goal of object-oriented development with reusability is to extend this reuse in the small to a reuse in the large . For the latter, two extensions to class libraries are necessary. Firstly, not only single classes but a set of classes that embodies an abstract design for solutions to a family of related problems should be reused. This set of classes is called an application framework 4]. And secondly, not only code but analysis documents and design documents should be reused. Thus, an application framework for some problem domain should embody the output of all development phases. Subsequently, an object-oriented life cycle model following the above requirements is

6
Problem Statement Product Db 1
Analysis

Problem Statement Framework Db 3 2
Analysis

Design

Design

Implementation

Implementation

4

ork ew nt m e Fra lopm e v De

Figure 2. Life cycle model for object-oriented development introduced. The model distinguishes two kinds of development cycles, one for the development of speci c projects and the other for the development of reusable components. For the former, again three di erent development cycles are o ered depending on the degree of reusability. Each development cycle consists of three phases, namely analysis, design, and implementation, which are iteratively processed. However, the life cycle model does not constrain the underlying development method in terms of which steps have to be processed and which outputs produced. To this extent the life cycle model is also a generic life cycle model. Figure 2 depicts the four kinds of development cycles of the object-oriented life cycle model. During Development from Scratch (1) the object classes of the application at hand are developed from scratch. Descriptions of these classes resulting from analysis, design and implementation are stored as analysis results, design results, and implementation results, respectively, in a con guration management system, called product database. The information stored in the product database serves two purposes. Firstly, it is used for the development of reusable components (see (4) below), and secondly, it eases the iterative processing of the various phases. Since the feedback loops from implementation to design and from design to analysis should be taken with care they are depicted with dashed lines. During Development through Reuse (2) the object classes of the application at hand are all constructed from reusable components of a repository, called framework database . If no component with the required behavior is found in the database the speci cation of the system has to be slightly modi ed to t existing components or the development has to switch to Development with Reuse (see (3) below). Note that reuse covers all development phases. During Development with Reuse (3) the object classes of the application at hand are looked up in the framework database. If no components proper for the current problem can be found, the object classes are newly developed. The results of development with

7 reuse are stored in the product database. Note that development with reuse describes the current state of practice. However, on the long run we should go for development through reuse. As a prerequisite for both (2) and (3) we have to stock the framework database. Thus, during Development of Reusable Components (4) precursor applications of a particular problem domain stored in the product database are analyzed and/or general domain analysis of this problem domain is performed. As a result, application frameworks, i.e. reusable components for the inspected problem domain are developed and stored in the framework database. Development based on reusability has impacts on the project organization of an enterprise. There are at least two new job pro les necessary to put into practice the life cycle model of Figure 2. Firstly, there must be a reuse promotor who motivates members of a particular project to reuse existing components. And secondly, there must exist a project independent reuse administrator responsible for stocking the framework database. The latter task is also known as experience factory in the literature 1].

4. Object-Oriented Development Revisited
Object-oriented development is on its way to ful ll its promises, namely improving productivity and reducing maintenance costs. However, it has to overcome two obstacles, one technical by nature and one organisational, to prove success in the large. The technical obstacle has two reasons. Firstly , we have stated previously that a main advantage of object-oriented development is due to the same concepts employed in all development phases. This is true and false at the same time. On one hand, it is true that the main concern in all development phases are communicating objects and how they have to interact to ful ll the required system functionality. On the other hand, some of the concepts of object-oriented analysis methods and object-oriented programming languages comprise subtle yet severe di erences. Examples are the use of multiple inheritance during analysis and single inheritance during implementation, and the use of associations during the former and inverse references during the latter, to mention just a few. And secondly , the almost exclusive concentration on the concept of an \object" forces that everything has to be expressed in terms of encapsulated objects. However, there are situations which demand further concepts, too. For example, complex symmetric operations involving several object classes should be modeled independently of a particular object class. In today's object-oriented systems each operation has to be assigned to a single object class. Another example concerns the modeling of local object behavior versus the modeling of global system behavior. Whereas the former comprises the possible life cycles of objects the latter should be stated in a exible manner, for example in terms of production rules. In today's object-oriented systems both local object behavior and global system behavior are modeled in terms of objects. A last example concerns the information hiding aspect of objects. To be able to decrease the complexity of an object-oriented system it is necessary to resolve the coupling between objects beforehand. This can be done easily if the required interface, i.e., the operations used from other object classes, is part of the public visible interface of objects. In today's object-oriented systems the information hiding principle prohibits required interfaces of objects next to su ered interfaces. The organisational obstacle is due to a lack of new project management principles. If

8 reuse in the large is more than just a lip service the following organisational principles have to be taken seriously. Firstly, object-oriented development is development by investment . Reusable components have to be developed although no client will pay the initial costs of component development. Secondly, object-oriented development has to go for a no-notinvented-here syndrom . The developers have to be motivated to reuse existing components despite the extra work to learn the contents of the framework database. And thirdly, new metrics like the lines-of-reused-code metric are necessary to take reusability into account. We conjecture that the above mentioned obstacles are resolved in the not-so-distant future, thus making object-oriented development a real alternative for building quality systems. Thanks to Jan Overbeck and Michael Schre , who contributed to the development of the object-oriented life cycle model, and to Stefan Rausch-Schott and Werner Retschitzegger for helpful comments on earlier drafts of the paper.

Acknowledgements REFERENCES

1. V. Basili, The Experience Factory and its Relationship to Other Improvement Paradigms. In I. Sommerville, M. Paul (eds.): Software Engineering (ESEC'93), Springer, LNCS 717, 1993, 68-83. 2. T. DeMarco, Structured Analysis and Systems Speci cation, Prentice-Hall, 1979. 3. I. Jacobson, Object-oriented Software Engineering, Addison-Wesley, 1992. 4. R.E. Johnson, A B. Foote, Designing reusable classes, Journal of Object-Oriented Programming (JOOP), Vol. 1, No. 2, 1988, 22-35. 5. J. Martin, Information Engineering, Prentice Hall, 1990. 6. B. Meyer, Tools for the New Culture: Lessons from the Design of the Ei el Class Library, Communications of the ACM, Vol. 33, No. 9, 1990, 68-88. 7. D.E. Monarchi, G.I. Puhr, A Research Typology for Object-Oriented Analysis and Design, Communications of the ACM, Vol. 35, No. 9, 1992, 35-47. 8. T.W. Olle, J. Hagelstein, I.G. Macdonald, C. Rolland, H.G. Sol, F.J.M. Van Assche, A.A. Verrijn-Stuart, Information Systems Methodologies: A Framework for Understanding, 2nd edition, Addison-Wesley, 1991. 9. O.M. Nierstrasz, A Survey of Object-Oriented Concepts. In W. Kim, F. Lochovsky (eds.): Object-Oriented Concepts, Databases and Applications, ACM Press and Addison-Wesley, 1989. 10. D. Tsichritzis, Object-Oriented Development for Open Systems. In G.X. Ritter(ed.): Information Processing 89 - IFIP World Computer Congress, North-Holland, 1989, 1033-1040. 11. D.C. Tsichritzis, O. Nierstrasz, S. Gibbs, Beyond Objects: Objects, International Journal of Intelligent and Cooperative Information Systems, Vol. 1, No. 1, 1992. 12. P.T. Ward, S. Mellor, Structured Development for Real-time Systems, Prentice-Hall, 1985. 13. E. Yourdon, Modern Structured Analysis, Prentice Hall, 1989.

Sponsor Documents

Or use your account on DocShare.tips

Hide

Forgot your password?

Or register your new account on DocShare.tips

Hide

Lost your password? Please enter your email address. You will receive a link to create a new password.

Back to log-in

Close