Excerpts

Practical Object-Oriented Development with UML and Java is for busy professional software analysts and developers who work on large systems. If you do not have time to take a class and need to get up-to-speed on object-oriented technology using unified modeling language (UML) and Java, then this book is a self-teaching guide for you. It will help you understand the differences between object-oriented analysis, object-oriented design, and object-oriented programming. Our goals are to Teach you to build an object-oriented application using Java and make the right trade-off decisions to meet your business needs Clarify the basic concepts associated with object-oriented technology Supply sufficient depth in coverage for students and practitioners entering the field to get them up-to-speed Expose some of the myths surrounding object-oriented technology while focusing on its practicality as a software engineering tool Provide a practical approach to analysis, design, and programming in object-oriented technology Show how to implement object-oriented technology using Java Balance theory with application practices in the existing literature You do not have to know computer science or advanced mathematics to understand the important object-oriented concepts and issues in depth. Even the programming chapters do not require a background in Java; they illustrate how working code in Java is produced. OBJECT-ORIENTED TECHNOLOGY We are software developers of large systems. We have delivered code written in several dozen programming languages representing a half-dozen software technologies. There have been few software revolutions that we have not experienced over the last 30 years. So it is from some nontrivial perspective that we say that it is our belief that object-oriented technology is the most important software technology with which we have worked. Why do we say this? Well, object-orientation has changed the way we build software and the way applications intercommunicate over worldwide networks and across mufti-vendor computers. Moreover, the object model is changing the way we design business processes and the way we think about an enterprise. Most enterprises are in the process of redesigning themselves to meet current business challenges introduced by the Internet. Object-orientation is playing a major role in this effort by providing a model that captures the business processes, procedures, policies, and rules that facilitate design. The use of tools that translate the model into an operational system speeds implementation of the redesign. As-market or business conditions change, these systems should be regenerated to reflect these changes by updating the model and using these tools. Solid software engineering practices have taken us farther and faster than any other approach in previous decades. It is a common belief that object-oriented technology has put a dent in the software crisis, meaning that the mechanisms of object-oriented technology are becoming for software what the bolts and beams are for construction design and what the chip is for computer hardware design. This belief stems from the following: The proficiency of a higher-level object-oriented model provides the software designer with real-world, programmable components, thereby reducing software development costs. Its capability to share and reuse code with object-oriented techniques reduce time to develop an application. Its capability to localize and minimize the effects of modifications through programming abstraction mechanisms allows for faster enhancement development and provides more reliable and more robust software. Its capability to manage complexity allows developers to address more difficult applications. The collection of object-oriented concepts is a tool set for modeling reality. This object-oriented tool set gives developers the best means of managing the complexity. Certain object-oriented concepts help developers produce flexible and maintainable software. WHY UNIFIED MODELING LANGUAGE? As practitioners of object-oriented technology, we know that all the methods, if practiced properly, result in the same or a similar model. Different modeling language notations, however, can be impediments to progress. The unified modeling language (UML) has become an industrial standard that has integrated different modeling notations into a single modeling language notation. This is reason enough to have chosen the UML. UML is a language for documenting our analysis and design models. It gives us all the drawing icons necessary to capture most of the concepts or mechanisms that we find valuable in solving real business problems. Also, it provides all the necessary diagrams that are vital for documenting our models. Finally, it is a living language that gives us the ability to extend the notation for mechanisms not yet defined by the distinguished group of Grady Booch, James Rumbaugh, and Ivor Jacobson at Rational Software Corporation. UML is not the central subject of this book. It is presented as a means of documenting the analysis and design models that are developed as a result of the methods that are the central subject of this book. All of the figures of UML are presented and discussed in terms of what information is captured within them and how that information is captured. WHY JAVA? It is true that Java is exclusively an object-oriented programming language and that this exclusivity tends to limit its use compared to the multi-paradigm programming language C++. Yet Java has one benefit that far outweighs any general limitations. In particular, Java runs on the Java Virtual Machine (Java VM). This allows a Java program to run on any machine that has an implementation of the Java VM running on it. This frees developers from having to design and implement the same functionality for several different combinations of hardware and operating systems. There are positive consequences to the use of the virtual machine that may not be apparent at first glance. For one, vendors can now focus on development of tools and products knowing that they have to invest development dollars on only one implementation and not five or six. This means that they can emphasize the realization of greater functionality (read that as greater business value). This impacts reuse efforts as well. One can develop libraries on any hardware running any operating system and reuse the code without modification for platform differences. Programming errors will not appear in one version of the code for a given platform and not in another. The broader base of reuse of the same code means that greater reliability of components can be achieved in less time and cost. Analysis can focus on business value; design can focus on greater flexibility and maintainability; and implementation and testing can now focus on quality, reliability, and performance. The net result of this change in focus is better code for less money. These benefits are seen when one looks at the large number of Java libraries (frameworks) that are now available from Sun. There is now a good set of general utility libraries, a high-performance graphical user interface library (e.g., SWING), and libraries of special-purpose business classes available to developers. Compared to the C++ versions of these libraries, they are far more sophisticated, provide much greater functionality, and are more easily incorporated into a final product. Because these libraries are available across all projects and are well documented in other books, they are widely used. Hence, expertise in their use is readily available. This is to be compared to the C++ versions that have entirely different application programming interfaces (APIs). In the C++ world, a developer may be an expert for one product on one platform and know nothing about other products for other platforms. Few programmers have actually written code for the PC, Mac, and Unix platforms. The direct incorporation of the Java VM in modern web browsers makes it possible for Java programs to be downloaded from the Internet and run from within the browser. This has helped provide greater functionality within the browser environment and has spawned a new class of applications. It is safe to say that it would have been impossible for us to have achieved the recent gains in functionality, being delivered to users via the Internet without Java. Java programs now appear as both client and server applications. The widespread use of Java in the modern World Wide Web is unlikely to diminish until a new (as yet unrecognized) technology provides a greater set of abstractions and the same broad platform support. OUR APPROACH TO OBJECT-ORIENTED TECHNOLOGY We are not object-oriented purists, and neither are we theorists. We are developers willing to use any good idea that will help us achieve two very critical business goals: lower development cost and reduced time-to-market for enhancements. We believe that these technical objectives--reliability, maintainability, and flexibility--are critical to meeting these business goals. Our approach to using object-oriented technology is to mange the complexity of developing software so it is reliable, maintainable, and flexible. Managing complexity is the key to achieving these objectives and, thus, our business goals. To manage complexity in complex problem domains, we find that the developers are required to know how objects, classes, relationships, and rules fit into the object paradigm. When we model most complex problem domains, we find objects, classes, and many relationships among objects. In addition, we need to capture the rules (policies) within that domain. Thus, we have to use very rich static modeling techniques to capture the data (object) relationships. Many object-oriented experts consider relationships as "bad" because they violate the encapsulation principle. From our perspective, it helps us manage the complexity of the problem domain and helps us to achieve our business goals. We gladly use it, and we look for more mechanisms and language support in this area. In Chapter 9 on declarative semantics we write that rules and policies should be captured as an integral part of our model and not in special subsystem extensions. Using mechanisms to help us model complex problem domains is consistent with our choice of UML as our modeling language and Java as our programming language. Both UML and Java allow us to define any needed mechanism that helps us to build more manageable software. We discuss behaviors (dynamic and static) and polymorphism for capturing the procedural aspects of the model. The use of finite state machine or some other state model helps us manage procedural complexity while addressing timing, synchronization, and interrupts. We also present exceptions for managing error recovery (an important topic because error recovery can comprise half of a programs logic). These areas are generally ignored or overlooked by most object-oriented books. We believe the key to success in building large object-oriented systems requires that developers and programmers know more than what is taught in most object-oriented books. Building large systems requires using mechanisms promoted by some object-oriented experts but not accepted by all. Professional developers need to at least understand how these aspects of the problem domain can be handled before they can be productive team members. This book will not make you an expert. You still need experts or consultants to develop the system. By applying the 80/20 rule, this book provides the 80 percent that can make you productive and understand how the experts solve the difficult 20 percent. In this book we do not cover the latest trends or fads in object-oriented technology, including object design patterns, the standard template library, and distributed object computing. Although they are interesting, we are not convinced that they contribute significantly to our goal of providing a practical framework for enabling developers new to object-oriented programming to get up-to-speed as soon as possible. Finally, we do not agree with most experts that object-oriented technology is a mature technology. We believe it is maturing. Object-oriented technology has the enormous potential to help us manage complexity that did not exist with the earlier technologies (procedural, functional, rule-based, etc.). We see in object-oriented technology and Java many different abstraction mechanisms merging (integrating) into a truly powerful technology. This merging is not yet complete, but it is far more complete in Java than in any other endeavor in object-oriented technology. ORGANIZATION OF THE BOOK We take the reader through our rational in applying object-oriented techniques and methods. These are not a set of absolute laws. Our goal is to make you think about good object-oriented concepts and good design principles when developing software and programming in Java. We have written and designed this book to be a self-teaching guide that should be read in sequential order. We have adopted a method that Richard has used for years teaching object-oriented concepts and basic skills; however, we do not advocate this as a method for building object-oriented systems. Each chapter discusses a major step of our approach to object-oriented technology. Most chapters conclude with a step-by-step guide or recipe. We hope the reader will use these steps only as a guide; always rely on common sense rather than following prescribed steps blindly. Chapter 1 introduces abstraction as a mechanism for controlling complexity and establishes object-orientation as the modern inheritor of the long line of abstraction mechanisms. Chapter 2 presents the basic principles of object-orientation. Chapter 3 begins the process of development by using the use-case approach to develop a specification model. Chapter 4 begins the process of developing an analysis model by identifying objects/classes/interfaces. Chapter 5 describes how to differentiate between "real" objects and' "false" objects by identifying attributes (data) and services associated with the object. Chapter 6 demonstrates how to capture objects' behavior. Chapter 7 describes how to identify and describe dynamic behavior. Chapter 8 describes the various relationships (generalization/specialization, link, object aggregation, etc.) that are available for organizing all the objects in the system. Chapter 9 describes how to incorporate declarative facts into the object-oriented model about object knowledge and a rule-based mechanism for their implementation. Chapter 10 reviews the analysis model and restructures it to take into account helper classes. Chapter 11 addresses some elements of developing the design model. Chapter 12 presents programming in the Java language. Chapter 13 introduces how classes and interfaces are implemented using Java. Chapter 14 describes how static behavior can be implemented. Chapter 15 describes how dynamic behavior can be implemented. Chapter 16 describes how generalization/specialization can be implemented. Chapter 17 describes how additional relations can be implemented. Appendix A presents a summary guide of the unified modeling language. Appendix B presents a summary of Java. Appendix C presents a comparison of Java and C++. USING THIS BOOK This book is primarily targeted at experienced software developers and upper-level college students. It is based on the material taught in industrial courses attended by competent programmers. The material of this book is presented in two courses of one-week duration. The first week covers the first 11 chapters while the second week covers the remainder of the book. This course has always been taught utilizing a project in which the students develop a computer game rather than a homework-based approach. At the end of the first course, students have a design for a game. At the end of the second course, students have a fully functional implementation of their design. We have chosen the project-based approach for several reasons. First, we have found that homework problems either are too trivial to effectively communicate the significance of the concepts or are too complex to be performed in a reasonable period of time. Second, the value of this paradigm is best learned from the consistent application of the concepts that can only be achieved via a project. Third, a substantial project gives a sense of real accomplishment as the projects are not simple little programs that can be finished in a single day of programming. Fourth, the project is developed in a team context with the periods of discussion, decision making, and reversals of decisions that actually occur when developing a program. Fifth, for most university students this will be the first program of substantial size that they will have to specify, analyze, and design. Finally, the selection of a project of suitable scale enables the student to master all of the key concepts. The typical project that is employed inn a university environment is a large adventure game in which characters explore some virtual world picking up treasures, fighting monsters or villains, and achieving some final objective. These games typically incorporate a hundred classes and just as many relationships. These games include many different kinds of terrain, weapons, monsters, treasures, and characters. With the widespread use of networked games, many project teams have chosen to develop multiplayer games. In most cases, the games developed by project teams have the same levels of complexity as many commercially developed products. A reasonable project team consists of three or four students. A larger team spends too much time coming to agreement and a smaller team tends to become overwhelmed. The team works on the project during class time so that the instructor can review progress and answer questions concerning the application of the concepts, so class size is kept to a manageable size. The students have to work on the project weekly so as to complete the project on time, and activities are scheduled to correspond with lectures. Following is a suggested schedule of course activities. It assumes a standard 15week schedule with the final exam given in week 15. A key feature of this schedule is that it allows generous time early in the semester to define the game and develop the use cases. Lectures occasionally precede the activities performed by the team by as much as three weeks. This has been found to be advantageous because it prevents students from making common mistakes, such as confusing attributes and associations or object state with object attributes. Excerpted from Practical Object-Oriented Development with UML and Java by Richard C. Lee, William M. Tepfenhart All rights reserved by the original copyright owners. Excerpts are provided for display purposes only and may not be reproduced, reprinted or distributed without the written permission of the publisher.