Visual Glossary

The following glossary shows how several important object-oriented concepts are shown in the UML and how they can be implemented in Java. Each section describes a concept, provides a sample UML diagram that uses the concept, implements the UML in Java, and offers some guidance on the proper use of the concept.

Generalization One or more subclasses may share the attributes and behavior that are defined for the base class. There are two ways to describe this relationship in proper object-oriented terminology. First, a class inherits all of the attributes and behaviors from a superclass or base class. From the opposite perspective, the superclass is a generalization of the attributes and behaviors that are common to all of its subclasses. In UML, the relationship is described as a generalization and is denoted by a solid line with a hollow arrow pointing to the base class.

UML Example Consider a brief example of generalization. Vehicle is a generalization of both Car and Truck. The two subclasses, Truck and Car, inherit all of the attributes and behavior

419

420

Appendix A

from the base class. Figure A.I shows the two subclasses, with generalization arrows pointing to the base class. In this case, there is no default go behavior for vehicles, so the base class must be abstract. Each concrete subclass of Vehicle must provide an implementation of the go method. Each concrete subclass may accept the default behavior for startEngine, stopEngine, and isEngineOn. If the default implementation is inappropriate, the subclass may override the default implementation by providing its In UML, rendering the abstract class name in italics indicates that the class is abstract. Showing a method in both the base class and in the subclass indicates that the subclass overrides that method.

Java Example The following Java files show how the UML model in Figure A.I can be implemented

Vehide.java Vehicle.java is the abstract base class in Figure A.I. This is reflected in the source code, as the class and the go method are both abstract. The other methods have implementations, but are not final, so they may be overridden by subclasses.

Appendix A

Car.java Car.java is a subclass of Vehicle, which in Java is indicated by the reserved word "extends." Car overrides the go method and uses the base class implementation of the isEngineOn method.

421

422

Appendix A

Truckjava Truck.java is a subclass of Vehicle, which in Java is indicated by the reserved word "extends." Truck overrides the go method and uses the base class implementation of the isEngineOn method. Truck is almost identical to Car, with a different implementation of the go method.

Guidelines It is extremely important for the generalization relationship to be an accurate description of the underlying reality that you are modeling. Each subclass must really be a refinement of the superclass. Do not subclass a class just to get useful behavior or attributes. Doing so makes the system significantly more difficult to understand, and may result in strange errors as the system evolves.

Realization A class realizes an interface by implementing each method that is defined in the interface. By realizing the interface, the class is promising to make the interface real, hi UML, the realization relationship is denoted by a dashed line, with a hollow arrow pointing to the interface.

Appendix A

UML Example Continuing the earlier example, some Vehicles can carry cargo, some cannot. Also, some classes that are not "normal" vehicles may also carry cargo. So, rather than introducing a separate subclass for all cargo-carrying vehicles, we introduce an interface, ICargoTransport. Our design allows any class to realize the ICargoTransport by providing an implementation for the loadCargo method. Figure A.2 shows Truck realizing the ICargoTransport interface, while Car does not.

Java Example The following Java files show how the UML model in Figure A.2 can be implemented in Java. Only the files that have changed from the generalization example are shown. Truck.java Truck.java is a subclass of Vehicle, which in Java is indicated by the reserved word "extends." Truck overrides the go method and uses the base class implementation of the isEngineOn method. Truck also realizes the ICargoTransport interface, as indicated by the "implements" reserved word in the class definition.

Figure A.2 Realization example.

423

424

Appendix A

ICargoTransport.java ICargoTransport.java simply defines the name and signature for the loadCargo method. As an interface, it is precluded from providing an implementation.

Guidelines All of the methods in an interface must combine to describe a coherent responsibility.

Association An association is a long-term relationship between objects, hi an association, an object keeps a reference to another object, and can call the object's methods as it needs them. Real life is replete with association relationships. Consider a person with his or her own automobile. As long as he or she remembers where it is parked, the car will let the

Appendix A person in to drive to his or her destination. In the UML, a solid line between the two classes represents an association. In some cases, an object may instantiate another object and keep a reference to it for future use. An object may also receive an object as a parameter to a configuration method and keep a reference to the object.

UML Example Consider an association relationship in which each Person object knows about zero or more Vehicle objects. Figure A.3 shows this relationship in a class diagram. The relationship is read as "every Person object is associated with zero or more Vehicle objects," and "every Vehicle object is associated with one or more Person objects." It may help to think of this as a "knows-about-a" relationship, as in "each Person object knows about some Vehicle objects."

Java Example Person.java shows how the association relationship shown in Figure A.3 between Person and Vehicle can be implemented in Java. Each reference to a Vehicle object is kept in a Vector.

Person.java The Person class simply holds the vehicles for a person.

Guidelines Association is the default long-term relationship between objects. If you are in doubt a to which long-term relationship to use, use association.

425

AppendnA

Aggregation Aggregation indicates a long-term relationship, with the additional restriction that some of the objects are part of another object. It is this whole-part nature of the relationship that distinguishes aggregation from association.

UML Example To continue the example, each Vehicle object may contain zero or one Engine objects. There is a clear whole-part relationship, as the engine is part of the car or truck. Figure A.4 shows a modified association from Vehicle to Engine, with the hollow diamond at the Vehicle indicating aggregation. The hollow diamond is always drawn next to the enclosing whole.

Java Example The following Java files show how the UML model in Figure A.4 can be implemented in Java. Only the files that have changed from the previous running example are shown. Vehicle.java Vehicle no longer determines whether it is running or not. Instead, this behavior is delegated to an Engine object.

427

Figure A.4 Aggregation example.

Appendix

A 429

Engine.java Engine.java provides very simple behavior for starting, stopping, and checking the current value.

430

Appendix A

Guidelines Aggregation requires a clear whole-part relationship. Any uncertainty about the need for aggregation or ambiguity over which object is the whole and which is the part should lead you to use association instead.

Composition Composition is an even stronger relationship, with one object essentially owning the other object or objects. The subordinate objects are created when the whole is created, and are destroyed when the whole is destroyed. Also, an object cannot play the role of a subordinate part in two composition relationships.

UML Example Every engine contains many wheels, cogs, and gears that are integral and indivisible parts of the greater whole. Figure A.5 shows that each Engine object contains zero or many Cog objects. The filled-in diamond next to the enclosing class indicates the composition relationship.

Java Example The following Java files show how the UML model in Figure A.5 can be implemented in Java. Only the files that have changed from the previous running example are shown. Engine.java The Cog objects are created when the Engine is created, and become eligible for garbage collection along with their enclosing Engine.

432

Appendix A

Guidelines As with aggregation, when in doubt, do not use composition.

Dependency Objects often need to use another object. An object may receive a reference as a parameter to a method, or it may create the object, use it, and lose it before the end of the current method. The key idea is that the dependent object acquires, uses, and forgets the object within a single method.

UML Example Continuing the example, people use gas pumps to get gas, but most people do not keep track of every pump that they have used. The Person object receives a reference to a GasPump object as a parameter to the purchaseGas method. The reference is used within the method; it is not kept. The resulting dependency relationship can be seen as the dashed line from Person to GasPump in Figure A.6.

434

Appendix A

Java Example Person.java shows how the dependency relationship between Person and GasPump can be implemented in Java. Person.java Now, the Person class has a puichaseGas method that accepts a reference to a GasPump object as a parameter.

Guidelines Dependency should be used whenever an object is used and forgotten within a single method.

Additional Resources

This appendix describes additional resources for several categories.

Object-Oriented Analysis and Design Booch, Grady. Object-Oriented Analysis and Design with Applications. Reading, MA: Addison-Wesley-Longman, Inc., 1994. This is still the classic text for OO analysis and design. It has a unique combination of academic precision and clear explanations. Booch, Grady, James Rumbaugh, and Ivar Jacobson. The Unified Modeling Language User Guide. Reading, MA: Addison-Wesley-Longman, Inc., 1999. Excellent reference for the UML and its application. Coad, Peter, and Mark Mayfield. Java Design. Upper Saddle River, NJ: Prentice-Hall PTR, 1997. A very concise and readable book that stresses design by composition. Fowler, Martin, with Kendall Scott. UML Distilled: Applying the Standard Object Modeling Language. Reading, MA: Addison-Wesley-Longman, Inc., 1997. A very concise guide to the UML.

435

436

Appendix B

Patterns Buschmann, Frank, Regine Meunier, Harts Rohnert, Peter Sommerlad, and Michael Stal. Pattern-Oriented Software Architecture: A System of Patterns. West Sussex, England: John Wiley & Sons, Ltd., 1996. Introduces several important architectural patterns, including MVC and layers. Fowler, Martin. Analysis Patterns: Reusable Object Models. Reading, MA: AddisonWesley-Longman, Inc., 1997. Very interesting book on analysis and domain modeling. Contains a lot of examples and clear explanations of the author's thought process as he creates his designs. Gamma, Erich, Richard Helm, Ralph Johnson, and John Vlissides. Design Patterns Elements of Reusable Object-Oriented Software. Reading, MA: Addison-WesleyLongman, Inc., 1995. The book for design patterns. Invaluable resource.

Software Development Process Jacobson, Ivar, Grady Booch, and James Rumbaugh. The Unified Software Development Process. Reading, MA: Addison-Wesley-Longman, Inc., 1999. Excellent reference for the proprietary process and for OO software engineering in general. Kruchten, Philippe. The Rational Unified Process: An Introduction. Reading, MA: Addison-Wesley-Longman, Inc., 1999. Concise guide to the RUP. McConnell, Steve. Rapid Development. Redmond, WA: Microsoft Press, 1996. Incredibly easy-to-read coverage of some difficult and important topics. This is not an OO book, rather the definitive software engineering book for the practitioner. McConnell, Steve. Software Project Survival Guide. Redmond, WA: Microsoft Press, 1998. Contains a lot of the same material as Rapid Development, above, but in a convenient easy-to-gift-wrap size. Makes a great gift for your favorite unenlightened manager or customer. Webster, Bruce F. Pitfalls of Object-Oriented Development. New York: M&T Books, 1995. A clearly organized and easy-to-read guide to the dangers inherent in OO software development. It contains excellent advice for both managers and developers as they adopt OO technology.

Appendix B 437

XML Megginson, David. Structuring XML Documents. Upper Saddle River, NJ: PrenticeHall, Inc., 1998. Goes way beyond the basics for a complete discussion of XML DTDs and how to construct them. St. Laurent, Simon. XML: A Primer. Foster City, CA: MIS Press, 1998. Concise guide to creating XML DTDs and documents.

Java Asbury, Stephen, and Scott R. Weiner. Developing Java Enterprise Applications. New York: John Wiley & Sons, Inc., 1999. An excellent introduction to Sun's Enterprise Java class libraries. Chan, Patrick, Rosanna Lee, and Douglas Kramer. The Java Class Libraries Second Edition, Volumes 1, 2, and Supplemental edition for the Java 2 Platform. Reading, MA: Addison-Wesley-Lortgman, Inc., 1998. An amazing series of books, with the best low-level explanations of the packages and classes that make up the core class libraries for Java. Eckstein, Robert, Marc Loy, and Dave Wood. Java Swing. Sebastopol, CA: O'Reilly & Associates, Inc., 1998. Very readable explanations of a complex topic. Exhaustive and evenly written coverage of a huge amount of material. Flanagan, David. Java in a Nutshell. Sebastopol, CA: O'Reilly & Associates, Inc., 1996. Excellent guide and reference for the language, tools, and basic classes. Hamilton, Graham, Rick Cattell, and Maydene Fisher. JDBC Database Access with Java: A Tutorial and Annotated Reference. Reading, MA: Addison-Wesley-Longman,

Inc., 1997. Thorough coverage of JDBC, but a little heavy on the reprinted JavaDocs for my taste. Hunter, Jason, with William Crawford. Java Serutet Programming. Sebastopol, CA: O'Reilly & Associates, Inc., 1998. Solid coverage of servlets, from fundamentals to advanced topics. Oaks, Scott, and Henry Wong. Java Threads. Sebastopol, CA: O'Reilly & Associates,

Inc., 1997. Excellent coverage of multi-threaded programming in Java, with a good balance of theory and details. Reese, George. Database Programming with JDBC and JAVA. Sebastopol, CA: O'Reilly & Associates, Inc., 1997.

438

Appendix B Excellent coverage of JDBC, and a thought-provoking introduction to the design of object-to-relational frameworks. Roman, Ed. Mastering Enterprise javaBeans and the Java 2 Platform, Enterprise Edition. New York: John Wiley & Sons, Inc., 1999. Excellent coverage of a wide range of enterprise technologies.

The CD-ROM

The CD-ROM contains a read-only HTML version of the UML design model for the ' -. . ' • .ion, as well as the Java source code and deployment instructions that can be used to deploy the application. If the model fails to load in your browser, please try the Netscape version. Also, your browser must be configured to support Java applets in order to view the model. The model file was created by using Rational Rose "Web Publisher" feature to produce a read-only HTML version of the model. This is a great way to distribute your designs to a larger audience, such as customers who do not have a copy of Rose. The model is intended to provide a coherent picture of the design that was developed over many chapters in the book. Some figures that are in the book are not in the model, and vice versa. fn order to view the contents of the model, simply use the tree control on the left. If you are in the frames version, the main view frame on the right will display the selected diagram. Otherwise, the selected diagram will appear in a second browser window. For example, click on the plus sign to the left of the Logical view folder. Double-click on the "main" diagram symbol. The Java source code and deployment instructions allow the reader to see one possible implementation of the design and to experiment with various alternatives. These instructions guide you as you install the required software and deploy the Timecard application. The instructions are broken into several sections, with each section shown in its own table. The leftmost column of the table shows the major steps required for

439

440

Appendix C

the section. The middle column describes the details for each step. Finally, the rightmost column describes any expected results. If your interest and patience are high, you may wish to deploy the Enterprise JavaBeans from, scratch. An additional page of custom installation instructions guides you through this tedious process. You can also view the deployment instructions or the custom installation instructions as Word documents.

Hardware Requirements To use this CD-ROM, your system must meet the following requirements: Platform/processor/operating system: Windows NT or 2000 RAM: 128 MB Hard drive space: 120 MB Processor: 300 Mhz Pentium or equivalent

Installing the Software To install the software, follow these steps: 1. Start Windows on your computer. 2. Place the CD-ROM in your CD-ROM drive. 3. You can browse the model from the CD-ROM by opening X:\Models\Design\index.htm in Internet Explorer or X:\Models\Design\contents.html in Netscape Navigator. 4. If you want to deploy the application, open X:\INDEX.HTM file on the CDROM for detailed instructions (where X is the correct letter of your CD-ROM drive).

User Assistance and Information The software accompanying this book is being provided as is without warranty or support of any kind. Should you require basic installation assistance, or if your media is defective, please call our product support number at (212) 850-6194 weekdays between 9AM and 4PM Eastern Standard Time. Or, we can be reached via e-mail at: [email protected]. To place additional orders or to request information about other Wiley products, please call (800) 879-4539.