Background

Object technology has had one of the most profound impacts on the Information Technology industry in the last few years. The development and growth of the Internet has complemented this naturally. Most modern software systems are built along the principles of object technology. At the same time, older computer systems show no signs of either dying or becoming Object Oriented (OO). This goes on to show that this parallel movement of OO and non-OO systems is likely to continue for several decades.

One had learned about C, among other computing basics and programming languages in 1994, when the idea of OO technology was really hitting the computing world in a big way. Learning OO technology was fascinating on one hand, but it also raised many questions on the other. For instance, it was difficult to believe that whatever OO technology had to offer was not possible with the existing technologies. As an example, one kept asking as to why we need to make attributes of a class private, when one already had the idea of local and global variables in C. In a nutshell, the point was that for people with non-OO background, it was perhaps slightly difficult to appreciate what it had brought forth. However, looking at the new crop of IT professionals, it appears that this barrier no longer holds, perhaps because they start their careers with the OO technology itself. This is good in one way, and not so good in another way; as the ability to question whether something is really needed is not seen as much as one hopes it to be seen.

Object technology is quite a good concept. It does make some aspects of analysis, design, development, and testing easier. More specifically, it makes the overall process a lot more uniform as compared to the traditional model of software development. However, I also believe that like many other technologies, it is over-hyped and is perceived as the ultimate solution to all the problems in software development. This is the thought that surprisingly leads OO technology to some problems. People hope that just by following OO principles, they would achieve complete success in a software project. Clearly, this is an incorrect expectation, which is not realized until the project goes into a crisis mode. The other mistake people often make is to use the OO technology only in parts. For example, in some cases, the analysis and design is done in the traditional way, but only the development is done by using an OO language, such as C++ or Java. This is also a likely recipe for disaster. Either OO technology should be applied right from the beginning, or not at all. A haphazard method is more often that not a road with bumpy rides.

Motivation

Personally, one is also amazed to see the extent to which the benefits of OO technology in terms of reuse are touted. It is claimed that anything and everything that is created by using the OO principles is always going to be reusable automatically. This fallacy is further compounded by almost all books and reading materials on the subject of OO technology. I would strongly resist the temptation of agreeing with this simplistic view and instead, argue that to make something reusable, it is not important whether it is OO-based or otherwise. However, what is significant is how much of conscious effort has gone in to make it reusable. It is a bonus if it is in OO technology, which would help make the reuse more likely a success. But just because something is created in OO does not necessarily qualify it to become reusable.

This book, therefore, is not an effort to glorify the OO technology, but to try and put it in the right perspective. The main aim is to try and simplify, rather than to compound or unreasonably elevate the status of the OO world. Instead, a serious attempt is made to explain the how’s and the why’s of OO technology, along with all the jargon and buzzwords associated with this technology.

The approach taken by the book in terms of the organization of its content is also quite different from most other books on the subject. Many books start with UML, and then introduce the areas in OO technology with reference to UML. I strongly feel that this is not how one should learn about the OO technology. Instead, one must know what exactly OO technology is, and how it works; before one learns how to apply UML to it. This is the reason why the chapter on UML in this book is featured towards the end of the book, more as a reference to the material introduced in the earlier chapters.

Features

The features and aims of this book are as follows.

• Simplicity: The book avoids, and in fact, explains jargon. It uses several examples from our daily life to explain the key concepts and terminologies.
• Language: A serious attempt has been made to keep the language simple. Jargon, keywords and important terms/concepts are explained in detail.
• Visual Approach: The book contains 413 diagrams, more than one per page. This makes it highly visual which further helps the understanding of the subject .
• Coverage: The book covers all the key aspects of Object technology, including OOAD, OOP, OO Testing, OODBMS, UML, Unified Process Model, and Design Patterns. It also discusses the methodologies of Booch, Rumbaugh, and Jacobson.
• Appeal: The book is written in a manner that would appeal the students, the teachers, as well as the practitioners of OOAD. Even people who do not know this technology but want to know about it would find it simple and yet detailed enough to understand it.
• Pedagogy: Every chapter has a chapter summary followed by a section listing the important terms and concepts introduced in that chapter, and then a question-answer section that contains true/false questions, multiple-choice questions, and questions that need detailed answers.

Organization

Overall, the organization of the book is as follows.

Chapter 1 introduces the concept of Object Technology. More specifically, it explains the history behind the progression of OO concepts, and why they have gained prominence. The chapter also explains the key terms in the area of Object technology. The chapter clearly distinguishes between the traditional approach to software development and the OO approach.

Chapter 2 deals with the idea of modeling. It explains what modeling means in the first place, and why it is needed. Further, the various models used in the context of OO systems, viz. Object model, Dynamic model, and Functional model, are discussed. This chapter is written with a clear focus on the OOAD methodology as proposed by James Rumbaugh. (As an aside, personally I like the style and technique of Rumbaugh as compared to those of Booch and Jacobson because of its simplicity and clarity.) We also use modeling to introduce the important concepts such as inheritance, interfaces, and polymorphism.

Chapter 3 deals with the analysis phase of an OO project. It explains why the analysis phase is needed, and what exactly is involved in this phase. After detailing the steps in the analysis phase, a simple case study is discussed to understand how this works in real life. This practical example would go a long way explaining the concepts of analysis, specially in the context of OO systems.

Chapter 4 moves to the next logical step, which is OO design. It explains the aims, steps, and processes in the design phase and then uses a case study to illustrate these concepts. Subtle use of UML is also made so that the reader is not puzzled to see these notations towards the end of the book in the chapter on UML.

Chapter 5 talks about the most commonly used OO phase, i.e. Object Oriented Programming (OOP). This chapter introduces the key concepts in OOP and explains how OO technology can be programmed in the best possible manner. It identifies the key OOP concepts, and then takes code examples from three significant OOP languages (Java, C++, and C#) to illustrate them. The syntactical differences are pointed out as and when appropriate.

Chapter 6 deals with the idea of OO testing. It begins with the concept of testability followed by the description of testing in OO systems. A comparison of testing of traditional systems and that of testing OO systems is made throughout to gain a perspective of what is involved. Designing test cases and performing actual testing in OO systems can be significantly different from testing non-OO software. All such areas are identified and explained.

Chapter 7 discusses the key concept of Database Management Systems (DBMS) in the context of OO systems. Starting with the basics of DBMS technology, it moves on to the various concepts in Relational Database Management Systems (RDBMS). How and where OO and RDBMS can marry each other, and where they cannot is explained. Further the interesting topic of Object Oriented Database Management Systems (OODBMS) is dealt with. The similarities and differences between OODBMS and RDBMS are also listed.

Chapter 8 takes a look at a completely different topic of OO technology in connection with the Internet. The various aspects of the Internet technology, such as the different kinds of Web pages, are dealt with and how to program them. Then the aspects of the Internet related to the OO technology, such as the middleware technology with reference to CORBA and COM; Transaction Processing (TP) monitors with reference to EJB and MTS; and Web services are examined.

Chapter 9 deals with the Unified Modeling Language (UML). It begins with the UML terminology and then explains things, relationships, and diagrams in UML. Several examples are taken to focus on the key terms and concepts of UML. The chapter presents all the diagrams discussed earlier in the book at one place.

Chapter 10 focuses on the Unified Process Model. This model is a joint effort of all the pioneers of the OO technology. This model modifies the traditional software development methodology to suit the needs of OO systems. The key concepts in this model are use-case driven approach, architecture-centric view, and iterative and incremental methodology.

Chapter 11 covers the topic of Design Patterns. The concept of patterns has been gaining prominence over the last few years. Design patterns are proven standardized models that can be used for designing software, rather than reinventing the wheel every time. There are several categories of patterns, and the original list of patterns is getting longer all the time. We cover the original patterns in detail.

The book ends with several useful appendices, as follows:

Appendix A discusses the concepts in algorithms and flow charts. Any software project, regardless of what methodology it follows, uses these concepts heavily. This appendix discusses what these mean, their usefulness and relevance to the software projects with simple examples and several illustrations.

Appendix B covers the topics in Software engineering and methodology. This covers the topics related to the basic methodologies, and standards such as SEI/CMM and ISO.

Appendix C deals with the basics of programming languages. Readers who are not familiar with the basics of programming and with the different types of programming languages are recommended to read this appendix first.

Appendix D details a case study on OO systems. This case study clearly demystifies how a non-OO technology views a particular application, and how an OO-based technology deals with it.

Acknowledgements

This is my tenth book on IT, and all have been possible simply because of the tremendous love and help that I receive from my family and friends. My parents and in-laws are always there to support me. My wife Anita besides being my best friend, is also a very constructive critic and reviewer. My little bundles of joy: Jui and Harsh teach me the meaning of life in a new way everyday.

It is difficult to list all my friends and colleagues, who constantly offer help, suggestions, and support. I would like to thank everybody at i-flex to make my every working day something to look forward to.

I would like to thank Vibha Mahajan, Biju Ganesan, Mini Narayanan and Somomita of Tata McGraw-Hill for their constant encouragement, and contributions to this project. Without them, the book would not have seen the light of the day.

Finally, I would like to thank Mr. Nandu Kulkarni for writing the foreword to this book.

Recommendation

It is recommended that the readers who do not have any background in programming, should first read Appendix C to get themselves familiar with the basics of programming and its relation to the object technology. Otherwise, the reader can skip Chapter 5 altogether without any loss of continuity.

Suggestions/Comments

You are welcome to write to me at akahate@indiatimes.com with your suggestions or comments about this book. Your feedback would help in making this book better when we revise it for the next edition.

ATUL KAHATE