Why UML and Java
When modeling elements, our goal is to sketch the application's framework with a keen eye toward using sound object-oriented principles. For this reason, UML, as an object-oriented notation, is a nice fit for any project using Java as its implementation language. Java was built from the ground up with the necessary “object plumbing” to benefit from the design elements of UML models. More importantly, when UML is combined with a sound software process such as the Unified Process, the chances for the project's success increase dramatically.
James Rumbaugh once said, “You can't expect a method to tell you everything to do. Writing software is a creative process, like painting, writing, or architectural design. There are principles of painting, for example, that give guidelines on composition, color selection, and perspective, but they won't make you a Picasso.” You will see what he means when later in the book the UML elements are presented in a workable context during the development of an application using Java. At that time, artifacts will be chosen that add the most value to the problem. We will still need a sound process to be successful, however—and a little luck wouldn't hurt, either.
All of the UML artifacts used in this book will cumulatively lead to better-built Java applications. However, some of the UML deliverables will have a much closer counterpart to the actual Java code produced. For example, use-cases are technology neutral. Actually, use-cases would benefit any project, regardless of the software implementation technology employed, because they capture the application's essential requirements. All subsequent UML deliverables will derive from the foundations built in the use-cases.
For core business and commercial applications, three UML diagrams most heavily affect the Java deliverable: use-case, class, and sequence (or collaboration). Now, I run the risk already of having you think the other diagrams are never used; they are, depending on a project's characteristics and requirements. Yes, the project may also benefit, on the basis of its unique characteristics, from other diagrams, such as state and activity diagrams. In my experience, however, the previously mentioned three diagrams, along with their supporting documentation, are the pivotal models that will be most heavily used. Table 2-1 maps the UML diagrams to Java.
Class Diagram
The king of UML diagrams is the class diagram. This diagram is used to generate Java code with a visual modeling tool (in this book, Rational Software's Rose). In addition, everything learned from all of the other diagrams will in one way or another influence this diagram. For example, the key class diagram components are represented in Java as follows:
| UML Diagram | Specific Element | Java Counterpart |
|---|---|---|
| Package | Instance of | Java packages |
| Use-case | Instance of | User interface artifacts (downplayed early on) in the form of pathways that will eventually become sequence diagrams |
| Class | Operations | Operations/methods |
| Attributes | Member variables and related accessor operations | |
| Associations | Member variables and related accessor operations | |
| Sequence | Instance of | Operation in a controller class to coordinate flow |
| Message target | Operation in the target class | |
| Collaboration | Instance of | Operation in a controller class to coordinate flow |
| Message target | Operation in the target class | |
| State | Actions/activities | Operations in the class being lifecycled |
| Events | Operations in the class being lifecycled or in another collaborating class | |
| State variables | Attributes in the class being lifecycled | |
| Activity | Action states | Method code to implement a complex operation or to coordinate the messaging of a use-case pathway |
| Component | Components | Typically one .java and/or one .class file |
| Deployment | Nodes | Physical, deployable install sets destined for client and/or server hosting |
Classes: The classes identified will end up as automatically generated .java class files.
Attributes: The attributes identified in the class will be generated as private (optionally public or protected) member variables in the class module. At the option of the designer, the generation process will also automatically generate the necessary accessor operations (i.e., get and set).
Interface: Through the messaging patterns uncovered in the sequence diagrams, the interface of the class—that is, its public operations—will begin to take shape as operations are added to the class.
Operations: Every operation defined for a class will end up as a public, private, or protected operation within the class. The operations initially will lack the complete signature specification (operation name only), but eventually they will contain fully specified signatures.
Associations: The associations identified between classes will end up as attributes of the classes to enable messaging patterns as detailed by sequence diagrams.
Finalized classes: Finalized classes can often be used to generate first-cut database schemas (assuming a relational database as the persistence store) in the form of Data Definition Language (DDL).
The UML class diagram and its Java counterpart, the class .java file, are the core of what drives the application's implementation.
Sequence Diagram
The tasks required to satisfy an application's goals are specified as pathways through a use-case. For a banking environment, one use-case might be Handle Deposits. A pathway through this use-case, one of many, might be deposits processed at the teller window. In most cases, each major pathway will have a sequence diagram created for it. Each, although logically stated in the use-case, will eventually end up as a dynamic collaboration between runtime objects, all sending messages to one another.
For example, when the Customer object wants each of its Order objects to perform the operation calcTotalValue(), it sends a message. Each message requires the receiver object (the Order) to have an operation defined to honor the request. Operations all end up in a class somewhere. These classes eventually are used to generate code in the Java environment.
The project team uses the sequence diagram to “walk through” the application. Once the project team has become comfortable with UML, and the accompanying Unified Process, it will no longer need to walk through code. Once the sequence diagram has passed inspection, the method-level coding can be implemented.
Eventually the sequence diagram walk-throughs will be the primary confirmation of whether a use-case pathway is correct. Most visual modeling tools, at present, do not generate Java code from the message patterns outlined in the sequence diagram (Together Control Center from TogetherSoft will reverse engineer sequence diagrams from Java code). However, I contend that this wouldn't be difficult for all visual modeling tools, and the next version of these products likely will support this ability. Having it would certainly differentiate competitors.
Component Diagram
The fully developed classes are assigned to components in the visual modeling tool's component diagrams. Many will fit a variety of possible physical manifestations:
Graphical forms (applets and/or applications)
Business-level rule components
Transaction or persistence components
These component choices will be reflected in .java files.
Deployment Diagram
Components defined in the visual modeling tool are deployed on nodes specified in the deployment diagrams. These diagrams depict the physical machines that will house the components specified as components previously. These deployment strategies may be Web-based solutions, multitier solutions, or standalone Java applications.
Visual Modeling Tool Support
The UML and Java fit together well. The value that UML adds is enhanced by the use of a visual modeling tool that supports both forward and reverse engineering (creating code from models and creating models from code). The use of a visual modeling tool also aids traceability and cross-checking of the model components.
A project that combines an effective software process model and a robust modeling language such as UML nevertheless will be hindered if it lacks a visual modeling tool. Without such a tool, the project will produce paper models that won't be updated or, worse, that will be lost in the shuffle of day-to-day project activity. Many excellent products are available, and they continue to evolve. Pick a tool and make it part of your process. Personally, I wouldn't be caught dead without one.