Five-Step UML: OOAD for Short Attention Spans - Design, Repeat (Page 1 of 13 ) Step 4: Design - Show the relations

among the elements with Component Diagrams. Add other diagrams where they shed light on the components. In this step, youll assign the interfaces and user interfaces discovered in Step 3 to components, and then show the relationships between components and interfaces in Component Diagrams. Youll try to identify existing components and interfaces that can be reused, along with new components that will support the new interfaces. UML Notation A Component Diagram is a way of depicting the executables and other components that form the logical architecture of your system. At its core, a simple Component Diagram consists of four elements: components, interfaces, realizations, and dependencies. Each of these elements is described in the following sections. Components A component depicts a deployable part of your system: an executable, a library, a data store, etc. Its a physical representation of a group of related classes and objects within your design.

In a Component Diagram, a component icon appears as a rectangle with two rectangular attachment points (which are purely decorative; nothing actually attaches to them). Components: A .NET Perspective In a .NET solution, a component is any chunk of code or data that you deploy and maintain. Some examples include

An EXE that represents a console app, a WinForms app, or a Windows service A DLL that represents a code library, a WinForms custom control library, or an ASP.NET control library The ASPX files that define the Web pages in an ASP.NET site

Some UML practices and tools go even farther, modeling components for the source files that make up your solution as well. Interfaces

An interface represents one or more related services realized (i.e., provided or implemented) by a component. One component may realize multiple interfaces; and multiple components may realize a given interface. In a Component Diagram, an interface icon appears as a circle. An interface should also include documentation of its attributes and operations. These might be depicted in a Class Diagram, using the standard class notation with the UML interface stereotype; or you might simply list them. Interfaces: A .NET Perspective It is important to remember that UML is conceptual, not technological: it isnt tied to a particular technology; rather, its concepts can be used to represent a range of technologies. When people name things, unfortunately, they have a tendency to reuse and overload terms; and thus, the names are potentially confusing when different speakers come from different backgrounds. So from a UML perspective, any mechanism that two components use to communicate is an interface: socket messages, HTTP messages, .NET Remoting calls, SQL calls, etc. But in .NET, interface has a very specific meaning: a precise protocol by which you can specify a set of operations and attributes that may be used by multiple client classes and provided by multiple server classes. A .NET interface may certainly be modeled as an interface in UML; but not every UML interface is a .NET interface. (You may find it useful to use stereotypes to distinguish various kinds of interfaces.) Realizations A realization indicates that a component realizes a given interface. Its indicated via a solid line connecting the component to the interface.

Dependencies In general, a dependency in your model indicates that one element makes use of or depends upon another; and thus changes in the source element will necessitate changes in the dependent element.

In Component Diagrams specifically, dependencies are drawn from components to the interfaces they make use of. A dependency appears as a dashed arrow. Component Diagrams Given these elements, then, a Component Diagram depicts components, interfaces realized by them, and dependencies from components to interfaces. Figure 2-18 is a Component Diagram that depicts the interfaces and components discovered in the Kennel Management System so far.

Figure 2-18. Component Diagram for the Kennel Management System So how do you arrive at this diagram? Ill discuss that shortly, in the section Step 4: Process in Detail, where youll also see how to extend the diagram to more completely reflect your architecture; but first lets take a quick look at .NET components. Components: A (Further) .NET Perspective Now the .NET developers have to make some specific technology choices, based on the interface technology choices from Step 3. ASP.NET pages and Web services have to be assigned to URLs and deployed to one or more Web sites. Each WinForm needs to be assigned to a component. Does one component provide all forms, or do you have forms distributed among multiple components? If youre using interfaces or .NET Remoting, which components provide these services? If youre using ADO.NET, which databases and tables and queries and views will you access? These and many more questions are part of designing a .NET architecture. Exercise 204: Assign Interfaces to Components with Component Diagrams: Build Component Diagrams based on the work youve already completed in previous exercises. Work with your team to pick out the interfaces from your swimlaned Activity Diagrams from the last step, define components, and create dependencies between them. The next section explains the process in detail.

Five-Step UML: OOAD for Short Attention Spans - Design, Repeat - Example (Page 3 of 13 ) Lets start of with an interface for the Owner Info swimlane (which appeared on many of the diagrams we examined in Step 3). Owner Info Interface Well put a corresponding interface on the (currently trivial) Component Diagram, depicted in Figure 2-19.

Figure 2-19. Initial Component Diagram for the Kennel Management System At the same time, well add the interface to a Class Diagram. Then, looking at the swimlaned Activity Diagrams shown earlier in this chapter, we can pick out the operations of Owner Info. Youll find that we need two operations: Get or Add Owner and Validate ID. (Some other possible operations are Look Up Owner and Add Owner Record; but because these have been converted to activities inside Get or Add Owner and are no longer called from other swimlanes, we can skip these as operations. We could choose to make them operations, giving us flexibility in the future; but so far, nothing in our architecture requires them to be operations.) So our initial Class Diagram for our interfaces looks like Figure 2-20.

Figure 2-20. Initial interface Class Diagram for the Kennel Management System Kennel Management Engine Component Lets assume that the Owner Info interface will be provided by the Kennel Management Engine, which weve just defined. The Kennel Management Engine shall provide a wide range of data management and validation services. It is essentially the middle tier between presentation and storage. Well add this as a component to our Component Diagram, which should now look like Figure 2-21.

Figure 2-21. Revised Component Diagram for the Kennel Management System

Other interfaces we can define from our swimlanes (in the earlier Activity Diagrams) are Pet Info and Vital Stats Info. Adding these, our interface Class Diagram looks like Figure 2-22.

Figure 2-22. Revised interface Class Diagram for the Kennel Management System Both of the new services really belong in our middle tier, and thus belong to the Kennel Management Engine. So our revised Component Diagram looks like Figure 2-23.

Figure 2-23. Component Diagram for the Kennel Management System, second revision Hmmm . . . not very informative yet, is it? Well, it is, a little: it tells us three sets of things that we can ask the Kennel Management Engine to do. But it will tell us a lot more when we add dependencies. When we look at our swimlaned Activity Diagrams, however, we see that almost all of our calls to our interfaces come from user interface swimlanes, not interface swimlanes. The only

exception, as shown in Figure 2-13, is that the Pet Info swimlane has a transition to the Vital Stats Info swimlane. The provider of the Pet Info interface is the Kennel Management Engine; so this implies that the Kennel Management Engine is dependent on the Vital Stats Info interface, as shown in Figure 2-24.

Figure 2-24. Component Diagram for the Kennel Management System, third revision Although this is legal UML, is it meaningful? Perhaps. Perhaps we believe that components yet to be defined will need the Vital Stats Info interface, so we need it in our architecture; and then Figure 2-23 would indicate both that the interface exists and that the Kennel Management Engine accesses vital stats through the interface, not through its internal mechanisms. (We might choose this approach so that we may change the architecture to add a separate vital stats component without having to significantly rewrite the Kennel Management Engine.) On the other hand, we could decide that vital stats will only ever be accessed by the Kennel Management Engine. In that case, we can collapse the Vital Stats Info interface, demoting it to a mere class within the Kennel Management Engine. Dont be afraid to collapse interfaces: discovering superfluous interfaces is a natural part of an evolving architecture. Similarly, dont be afraid to preserve a seemingly superfluous interface: modularizing and exposing your internal services gives you a wide range of architectural choices down the road. You have to select your own balance between simplicity and flexibility; and whichever choice you make, you can always change your mind later. It just may entail some work maybe a lot of work . . . In this example, well collapse the interface to yield the diagram shown in Figure 2-25.

Figure 2-25. Component Diagram for the Kennel Management System, fourth revision OK, so weve resolved the vital stats issue; but in the process, were back to a pretty simplistic Component Diagram. Looking at our Activity Diagrams, we can see some dependencies that are pretty clearly implied: our user interface swim-lanes have transitions to our interface swimlanes, so some sort of user interface components must lie behind those swimlanes. We just need to define them. Looking at the swimlanes, it appears we need some sort of Check In Form and some sort of Check Out Form. We can add these to the Component Diagram as components,

add the dependencies implied by the Activity Diagrams, and voil! We have the Component Diagram shown earlier in Figure 2-18. Did that last step bother you? It bothers me: some of the swimlanes correspond to interfaces, but others correspond to actual components. Now this is legal UML. (In fact, its irrelevant UML: UML doesnt require any mapping from interfaces or components to swimlanes, though the mapping is allowed. We use the mapping here as a useful convention of the Five-Step UML process.) But its inconsistent UML. That bugs me. I had a nice, linear process: look at a swimlane; make it into an interface; assign it to a component; look at a component and its swimlanes; draw the dependencies. Now theres a bump in my process. In fact, there are two bumps: we also have swimlanes that correspond to users of the system, and those dont show up on the Component Diagram at all. Even worse, those end users are represented in the model as actors; and so are other computer systems with which our system must interact. Yet we interact with those systems via interfaces, which do appear on the Component Diagrams. So we have two kinds of actors and two kinds of swimlanes that are similar in nature (within our model, anyway); but one is represented on the Component Diagram, and one isnt. Traditional architecture diagrams dont actually represent the end user; but if architecture is about . . .the selection of structural elements and the interfaces through which they are connected, the large-scale organization of structural elements and the topology of their connection, [and] their behavior as specified in the collaborations among their elements . . .,9 then I believe it is a mistake not to include the end user in relevant architectural diagrams. Users are connected to the system through user interfaces; the topology of elements is shaped in part by the users with which it must be connected; and users collaborate with the system to do work (witness the fact that actors can appear as collaborators in Sequence Diagrams). We can smooth out both of these bumps by adopting a new stereotype, user interface, which may be applied to interfaces. The attributes of a user interface element represent the data fields displayed by the UI; and the operations of a user interface element represent the actions a user may take through the UI. Besides defining this stereotype, I find it useful to define a custom icon that looks somewhat like a computer monitor. Its square shape makes it easy to distinguish from regular interfaces.

Then we can add user interface elements to the Component Diagram the same way we added regular interfaces: look at a swimlane that represents a user interface, and add the corresponding user interface element. Then document the user interface element in a Class Diagram to depict its data fields and actions. So, for our example, the user interfaces we have defined so far could be modeled in a Class Diagram as shown in Figure 2-26.

Figure 2-26. User Interfaces for the Kennel Management System 9. James Rumbaugh, Ivar Jacobson, and Grady Booch. The Unified Modeling Language Reference Manual (Addison-Wesley, 1999), p. 151 And then we can select or define a user interface component to realize the user interface element. Following this procedure (and ignoring that whole vital stats controversywhat was I thinking when I put that in the architecture?), the diagram in Figure 2-23 would now look like the one in Figure 2-27.

Figure 2-27. Component Diagram for the Kennel Management System, fifth revision Note how we assign one component for each user interface. This is a common practice for modeling ASPX pages: each page is a component in its own right. In this sense, we can think of the user interface as the HTML delivered to the users browser, and the component as the codebehind component that creates the HTML and processes the response. Although this approach can be useful, it can also be cumbersome, as youll see in Chapter 9. Note also how, by adding user interface elements and corresponding components, we pick up something we had missed in our architecture earlier: the Paging System to notify the Care Giver when the pet needs to be retrieved. This is certainly an improvement in our architecture; but it also reveals another problem. In Figure 2-17, we have one user interface swimlane (Check Out UI) calling another (Care Giver UI). Now this is legal, because a form can certainly launch another form; but its clearly not what we meant: we wanted an interprocess communication that would cause the Care Giver UI to notify the Care Giver. Interprocess communication implies a new interface, one we didnt capture correctly in Figure 2-17. Well call it Care Giver Notify, and add the corresponding swimlane to the diagram in Figure 2-17, producing the one shown in Figure 2-28.

Figure 2-28. Activity Diagram for Locate Pet use case (architectural view, revised) Note the use here of a new stereotype, display, applied to a transition to a user interface to indicate that it must display information for the users response. From this diagram, we can add the Care Giver Notify interface to the diagram in Figure 2-27, producing the one in Figure 2-29.

Figure 2-29. Component Diagram for the Kennel Management System, sixth revision Next we can add dependencies the same way we did before. Recall that in order to add dependencies, we examine each swimlane, and look at the swimlanes that have transitions into it, converting those into dependencies. By following this procedure and rearranging for legibility, we get the diagram in Figure 2-30.

Figure 2-30. Component Diagram for the Kennel Management System eighth revision Now that weve gone this far, we might as well go all the way: adding the actors corresponding to swimlanes, and adding dependencies from the actors to the user interfaces they use. This will give us a complete picture of the roles that users play within the architecture, as shown in Figure 2-31.

Figure 2-31. Component Diagram for the Kennel Management System, eighth revision If you would rather stick with formally correct UML notation, you could define a new stereotype for components: user. You could then add a new component with that stereotype wherever you want to show a user interacting with a user interface. But even though its not standard UML, I find it easier and clearer to just put the actors on the Component Diagrams, as shown above. And again, if it helps you to communicate, its useful UML, even if its not perfect.

So What About Those Names? Here in Step 4, were stepping out of analysis and into design (architectural design, to be precise). That means the programmers in the crowd are starting to think about implementation (because we programmers have a nasty habit of running ahead of where were supposed to be). And that means that some of you reading this right now are saying, Hey, those names arent legal identifiers in my implementation language. Whats up with that? And youre right, of course: Kernel Management Engine, Owner Info, and Get or Add Owner arent legal identifiers in any programming language I know. And if you start talking corporate naming standards and coding conventions, the situation only gets worse. So what is up with that? Well, in my practice, I usually try to share my architecture with my stakeholders as it evolves, so that they can give me an outside perspective. (OK, I really only share selected, simplified views. I dont want to bury them in technical details.) So I prefer human-readable names. andIfYouThinkThisIsHumanReadable, youHaveBeenProgrammingTooLong, and youNeedToGetOutIntoTheRealWorld. So how do I deal with this disconnection between readable names in my model and legal identifiers in my code? I have three suggestions: 1. If youre not generating code from your model automatically, you have to translate your model into code by hand. While youre doing so, translate the names into legal identifiers. 2. If you are generating code from your model automatically, most modeling tools will automatically translate the names into legal identifiers. Some will even let you define the

translation rules, such as Convert all spaces to underscores or just Remove all spaces. You can even specify common conventions such as All class names begin with C and All interface names begin with I. 3. If youre not worried about communicating with nonprogrammers (and why not, eh?), follow your naming rules and conventions in the model. Of these approaches, I personally prefer the second choice. UML Notation The only particularly new elements in this step are those related to Class Diagrams: classes, associations, and dependencies. Classes A class represents the operations and attributes of one or more objects within your system. It binds attributes and operations to completely define the behavior of the objects. Thus a class definition serves the same purpose for an object that an interface definition serves for a component: it describes the ways in which client elements may use the given element.

In a Class Diagram, a class appears as a rectangle broken into three sections. The top section identifies the name of the class, the middle lists the attributes of the class, and the bottom section lists the operations of the class. If it makes the diagram less cluttered and thus more clear, you may hide the attributes or operations for any class in the diagram. You may even hide some of the attributes and operations, while showing others. But I usually discourage thisunless the class definition is really large and overwhelms the rest of the diagrambecause readers tend to assume that a partial list is a full list. Classes: A.NET Perspective Now youre moving from domain classes to code classes. You need to consider the precise .NET mechanisms for implementing each class. What is its base class? What are its attributes, including types and initial values? What are its operations, including parameters and return types? What kind of class is it: a class, a structure, an enumeration, a delegate? Associations An association represents an object of one class making use of an object of another class. It is indicated simply by a solid line connecting the two class icons. An association indicates a persistent, identifiable connection between two classes. If class A is associated with class B, that

means that given an object of class A, you can always find an object of class B, or you can find that no B object has been assigned to the association yet. But in either case, there is always an identifiable path from A to B. Class A uses the services of class B or vice versa. Associations: A .NET Perspective In .NET code, an association is most probably implemented as one class containing anotheror to be more precise, containing a reference to the other, since all .NET classes other than structures are always contained by reference. For some designs, each class might contain a reference to the other. These concepts are discussed further in Chapter 4. Dependence In Class Diagrams, a dependence represents an object of one class making use of or somehow knowing about an object of another class; but unlike association, dependence is a transitory relationship. If class X is dependent on class Y, then there is no particular Y object associated with an X object; but if the X object finds a Y objectperhaps it is passed as a parameter, or it receives one as the return from an operation that it calls, or it accesses some globally accessible Y object, or it creates one when it needs onethen it knows what it can do with the Y object. Object X is potentially affected by a change in Object Y. As in other diagrams, dependence is indicated by a dashed arrow connecting the two class icons. Dependence: A. NET Perspective In .NET code, dependence has become almost a nonentity. In old C++ code, for example, dependence could be implemented as one class #includeing the header file for another class. That #include statement indicated that the first class knew what to do with the second class. But in .NET, most classes are visible to other classes. The closest things to dependence in .NET are

The using directive, indicating that all code in a file can use all classes in a particular namespace Assembly references, indicating that a project can use all classes in a particular assembly

But both of these uses are package specific, or perhaps component specific. You may choose to avoid dependence for this reason; but I still prefer to model dependence among classes, because it indicates that one class may create or otherwise manipulate objects of another class. Class Diagrams Given these elements, then, a Class Diagram depicts classes and associations between them. Figure 2-33 is a Class Diagram that depicts the classes and associations that may be useful in the Kennel Management System.

Figure 2-33. Class Diagram for the Kennel Management System Classes: A (Further) .NET Perspective The .NET Framework contains over 3,300 classes for common infrastructure operations. Before you design your own classes, you might save time to see if .NET gives you classes that provide the functionality you need, or at least a large chunk of it.