- Introduction
- The Architectural Process
- Project Communication and the Unified Modeling Language
- The Analytical Process, J2EE Style
- Use Case Analysis
- Managing Use Case Complexity
- Object Types
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Project Communication and the Unified Modeling Language
One of the most important aspects of any architectural development effort is the communication between members of the development team. Careful examination and review of architectural alternatives is critical, and this can be done well only if all team members, both technical and in some cases nontechnical, can understand the design.
The analysis diagram is a visual presentation of a technical concept. As such, analysis diagrams have been around for some time; some have been formally standardized and others are merely arrows and circles used in a logical manner. The UML is an attempt to standardize diagramming for OOAD, which has become the de facto standard for OO analysis.
The UML is based on work done by Grady Booch, James Rumbaugh, and Ivar Jacobson. There are nine diagrams supported by UML, as listed in Table 3–1.
Table 3-1 Nine UML Diagrams
|
Diagram |
Description |
|
Use Case Diagram |
Describes the operation of the system from the user's point of view. |
|
Component Diagram |
Defines how pobjects are grouped into packages. |
|
Sequence diagram |
Object interaction for a set of actions. Indicates order and flow of processing. |
|
Deployment diagram |
Details object deployment across hardware platforms. |
|
State diagram |
Creates a diagram describing object collaboration. |
|
Activity diagram |
Details the process flow of an event. |
|
Object diagram |
Describes instantiations of classes. (Not used often.) |
|
Class diagram |
Describes the design for a class, including class members, instance members, and methods. |
Of these nine diagrams, seven are commonly used:
- use case diagram
- class diagram
- sequence diagram
- activity diagram
- state diagram
- component diagram
- deployment diagram
These diagrams represent the core set you will use to describe the development of the J2EE architecture you create. Additional diagrams may also be used (for example, the process flow diagram to show the flow of data, and an entity-relationship diagram to show the relationship of data entities), but these UML diagrams listed here represent the core, which the following sections will explain.
Use Case Diagram
Use case analysis is used to gather the functional requirements for a system. Consequently, the use case diagram helps to describe this process in a way that is easily understandable to the end user. The use case diagram uses a gender-neutral stick figure to represent the user. The stick figure is referred to as the actor, an individual outside of the system who must interact with the system. The actor initiates an event, and ovals are used to represent the event the actor is initiating. A rectangle can be used to represent an external system, and lines are used to represent relationships between the actors and events. In the example in Figure 3–1, a user initiates events for a login, for reading a message or for creating a new message.
)
Figure
3-1 Use case diagram.
Each use case diagrammed should describe a discrete benefit for the actor. A well-focused use case should be expressed in 30 words or less, and the action taking place should happen within a single session for the actor. Excessive complexity in a use case is probably an indication that the use case should be subdivided into separate use cases. Describing complex use cases and managing these complexities is discussed in further detail in the following sections.
Class Diagram
The class diagram may be the most commonly used of UML diagrams. This diagram describes the composition of an object class, specifically the attributes and behaviors that comprise the class. Boxes are used to represent the class, with the top section reserved for the members of the class and the bottom section reserved for the methods (behaviors) of the class. Multiple classes can be described in the same diagram with lines between the classes used to represent the relationship of the classes, as shown in Figure 3–2.
)
Figure
3-2 UML class diagram.
An arrow going from one class to another represents inheritance: The class to which the arrow points is the superclass, and the class where the arrow originated is the subclass.
A common representation, representing a technique that is an important part of Java object-oriented programming, is the UML stereotype. The UML stereotype indicates that the object will implement specific behavior, but the object diagrammed is not the implementation itself. In Java, the properties of the UML stereotype are provided using the Java interface. An example of this is the Runnable interface, which allows a program to start an independent thread of execution. The Runnable interface does not provide a thread implementation itself; it is up to the class that implements the interface to provide the implementation. This is shown in the UML class diagram with the << characters above the name, as shown in Figure 3–3.
)
Figure
3-3 The UML stereotype.
From a development perspective, the use of interfaces provides a great deal of flexibility. They provide a very clear description of the implementation behavior expected of an object—a clear contract. An object implementing multiple interfaces can participate in multiple relationships for the interface, exhibiting a behavior similar to that of multiple inheritance (something not provided in Java).
The class diagram provides for the grouping of classes into packages, as shown in Figure 3–4. This is an important part of the design process, since the organization of these classes and how they interact can have a significant impact on a system. This is where optimizing cohesion and minimizing coupling are managed. By creating consistent diagrams throughout the development process, excessive coupling can be discerned earlier in the development process rather than later when it is difficult to correct. This topic will be revisited later in this chapter.
)
Figure
3-4 UML sequence diagram.
Sequence Diagram
Once again, it is critical that we understand how our objects interact, how they will work with each other. The UML sequence diagram is an excellent tool for visualizing these types of relationships. Sequence diagrams represent control flow across a series of objects or components and provide a useful visual medium for determining object relationships in the design phase. While the common terminology for the elements in this diagram are objects, with J2EE architectural analysis and design, these objects are more commonly J2EE components: JSPs, servlets, or EJBs.
Using sequence diagrams, it is easy to determine the amount of collaboration between two or more objects. This can help determine how to group objects and whether or not a given object is becoming too complex.
In the example in Figure 3–5, a sequence diagram is used to detail a user login process.
)
Figure
3-5 UML sequence diagram.
As a user logs into the system, the login process in turn executes an authentication process, which then passes control to a flow control process that will decide what the user's next action will be based on his or her authentication.
Activity Diagram
Use case activities can be further analyzed using activity diagrams. Though these diagrams are frighteningly similar to the much maligned programming flow chart (sometimes called "flaw charts"), they are built on distinctly different rules and work at a higher level of detail than the flow chart. As one of the set of diagrams you will use to describe the design of your J2EE system, this is a useful tool for visualizing the processing of an event.
UML activity diagrams break down the activities into a series of events that help provide insights on the processing behind the event. These diagrams, coupled with more detailed textual documents, can help you facilitate discussions with stakeholders. The example shown here Figure 3–6) documents part of a user login.
)
Figure
3-6 UML activity diagram.
As this diagram details, if the user login is valid, then a menu is displayed. If, however, the login is invalid, then a page describing the invalid login is displayed.
State Diagram
Some objects move through various states of activity, often in response to some set of events. The lifecycle of an EJB or servlet is an example of this. For these objects you may find it useful to use a UML state diagram that details the states of that object.
A state diagram shows the various states' existence for an object, thus providing a representation of the lifecycle of an object or component, as shown in Figure 3–7.
)
Figure
3-7 UML state diagram.
This diagram details the lifecycle of an object that processes messages from a message queue. The message queue processor is in a ready state until it is awakened. When it is awakened, the contents of the queue are processed until there are no more contents to process. The queue processor is then put back to sleep until it is needed again.
Component Diagram
As it has no doubt become clear, J2EE involves creating distributed applications, applications where components will run on one or, more than likely, multiple servers on a network. Once you have identified the top-level objects or components of the system becomes clear, you then need to determine how the objects will be distributed across servers. Two UML diagrams help to visualize this process: the component diagram and the deployment diagram.
The UML component diagram represents the relationships of the physical implementation of components and so is sometimes referred to as an implementation diagram, as demonstrated in Figure 3–8.
)
Figure
3-8 UML component diagram.
In this example, a shopping-cart user interface component is shown interacting with a database access component. As the diagram makes clear, both reside on separate network nodes (servers). As part of a more complex architecture, this diagram could help discern excessive coupling or potential bottlenecks between components residing on separate servers where interaction will require network communication and possibly create a performance bottleneck.
Deployment Diagram
Similar to the component diagram, the deployment diagram illustrates the physical deployment of system components. Three-dimensional boxes are drawn to illustrate servers, and components are drawn as boxes with connectors (vaguely similar to an electrical plug), as shown in Figure 3–9.
)
Figure
3-9 UML deployment diagram.
This diagram shows the potential deployment of a shopping cart system across several servers. The lines between components represent associations. As with the component diagram, this visualization of distributed components can help identify potential bottlenecks and excessive coupling between components and modules (groups of components) in the system.