Design

Design is where the abstraction of the business takes its first step into the reality of software. Anything can be expressed in requirements and analysis models; I've even got a technical manual on the inner workings of the starship Enterprise's Transporter System.[1] Yet even these well thought-out requirements and specifications are not likely to be implemented any time soon: what a shame! Design can be a humbling experience.

[1] Rick Sternbach and Michael Okuda, Star Trek: The Next Generation Technical Manual, Reissue Edition (New York: Pocket Books, 1991).

Design starts with the analysis model, the user experience model, and the software architecture document as the major inputs. The principal activity of design is to refine the analysis model such that it can be implemented with the components that obey the rules of the architecture. Even though this sounds straightforward, it can be the most complex phase of a development project, especially when significant advances in software technology are happening so quickly.

As with analysis, design activities revolve around the class and interaction diagrams. Classes become more defined, with fully qualified propertiesname and typeand operationscomplete signatures. As this happens, the level of abstraction of the class shifts from analysis to design. Additional classes, mostly helper and implementation classes, are often added during design. In the end, the resulting design model is something that can be mapped directly into code. This is the link between the abstractions of the business and the realities of software.

During analysis, we were content to work with only class diagrams and interaction diagrams. During design, a new viewthe component viewand diagram are introduced. This view of the model expresses the physicalif anything in software can be considered physicalmodules and executables that will be distributed as the system.

A component typically maps to executable files or files that are distributed as part of the runtime system, such as Java class files,[2] JAR files, static libraries, and dynamic link libraries (DLLs). A component is something that realizes a set of interfaces. An interface is a bridge between the logical view of the system and the physical view. Simply put, interfaces are public functions that can be called by outside components. An interface defines the name of the function, its parameters, and their data types, whether they are optional, whether they are input or output, and the function's return value type. A component can realize multiple interfaces.

[2] We treat Java class files as components only if they are individually distributed as separate files. If the class files are part of a Java Archive (JAR), it is the JAR file that maps to a component, and it is not necessary to treat the class files like a component.

The realization of a component is done with the classes and collaborations expressed in the logical view. Every class in the logical view is implemented by at least one component; abstract classes defining interfaces may be implemented by many components.

Component diagrams visualize components, interfaces, and their relationships. Components are rendered in a diagram with a set of rectangles (see Figure 11-1). Interfaces are rendered with a "lollipop," or a circle on a stick. Dependencies are expressed with dashed lines and arrowheads.

Figure 11-1. Component diagram

Class icons can be represented in component diagrams to express dependencies and realizations. Components realize classes, and this relationship is shown with a dashed line and an arrowhead. Figure 11-2 shows that the Shopping Cart component realizes the ShoppingCart and ShoppingCartItem classes.

Figure 11-2. Shopping Cart component realizes ShoppingCart classes

During analysis, we were content to leave the interface between the actor and the systemas expressed in the interaction diagramsas user interface. During design, the interface needs to be elaborated into a set of specific interfaces capable of handling the communication between the actors and the system, as well as supporting the flow of activity of business processes. In addition to elaborating the classes and collaborations, design activities include

• Partitioning objects into client, server, and other tiers
• Separating and defining user interfaces, or Web pages

When we partition objects into their tiers, we need to know what tiers are available for objects. This depends on the specifics of the architecture. For example, a Web application that uses only the thin Web client architectural pattern is not capable of supporting user-defined objects on the client. Therefore, all objects must exist somewhere in the server's tier; of course, depending on the complexity of the system, they may exist in many different "tiers" behind the Web server.

The basic architectural patterns of Web applications all involve Web pages. Web pages act as generalized user interface containers; Web pages are the glue that connects the browser with the rest of the system. Because one of the greatest uses of modeling is capturing all the elements of a software system and their collaborations so that they answer questions about the system, it is vital to capture Web pages as first-class elements in the model and to represent them alongside the classes and components that make up the rest of the model.

Representing Web pages in the model, however, is not as straightforward as we would like. It should be clear that Web pages are objects, just like any other user interface in a system. The modeling problem occurs when you consider a Web page that has scripts to be executed on the server. This type of Web page interacts with server-side resources before being sent to the client as a completed user interface. To complicate matters, this page can contain a separate set of scripts that execute on the client as well. When processed by the server, the page does one thing; when processed by the client, it does a completely different thing.

As they come out of the box, the building blocks of UML are not sufficient to express the necessary subtleties of scripted Web pages as objects in a class diagram. Yet because they perform important business operations and act as real objects of the system, they need to coexist with the classes and the objects of the system. The only solution is to modify UML.

Doing so may seem like a drastic solution, but the UML creators have built in a way to extend the language in a controllable way. They knew that in order for UML to last, it would have to adapt to the rapid pace of technology change in an orderly manner. They also understood that there will always be unique situations, especially in vertical markets, where tools right out the box might not be appropriate. To accommodate this need for flexibility, the UML creators defined an extension mechanism for UML.