Five Step UML, Step 4: Design

First, we want to add all of our interfaces and user interfaces to the component diagram. In UML, an interface on a component diagram is depicted as a circle. Remember how we defined interfaces: a set of services to be provided, with no indication in the interface itself of how those services are implemented. An interface is a contract: one piece of code agrees to provide these services, and another piece of code agrees to use the contract to tell that code what to do. So we will add a new interface icon for every interface that we’ve discovered so far.

To add a component diagram in Tablet UML, click the Component Diagram button: .

To add an interface to a component diagram, draw a circle. Tablet UML will convert it to an interface.

And then we must ask: is a user interface an interface? While the question’s a little odd, it’s a very important question. Traditionally, the answer is no; but I find that it’s very convenient in UML to think of a user interface as an interface through which external actors interact with the system. If an actor was another computer, you would let that actor talk to your system through an interface. You might even show that other computer participating in the component diagram that you’re building. Well, why should human actors be any different? So by modeling a user interface as just another kind of interface (with a <<user interface >> stereotype), you make it more consistent when it comes to figuring out what lies behind each of your swimlanes in an activity diagram, or behind your objects in a sequence or collaboration diagram. So I would also add each user interface to the component diagram.

Now each interface has responsibilities: the activities that reside within its swimlane in an activity diagram, or the messages sent to it within a sequence diagram or a collaboration diagram. Each of these will represent one operation of that interface. If the interface is in fact a user interface, then each message for each activity may correspond to something that the user tells the system: a button click or a keyboard input or something similar. So next, you can add these operations to each interface by listing them underneath the interface itself. However, that may clutter up the component diagram, where you’re more concerned with which component provides each interface and which component uses each interface. So I recommend that you not show these operations on the component diagram. Instead, you can describe them inside of the model where each element for each interface and user interface exists. If you’re modeling by paper and pencil, then I recommend a separate sheet of paper for each individual interface.

To add attributes and operations to an interface in Tablet UML: right-click the interface to show its context menu, select the interface name in the menu, and then select Edit Attributes... or Edit Operations....

To show or hide attributes and operations of an interface, right-click the interface to show its context menu, select the interface name in the menu, and then select:

• Show All Attributes
• Hide All Attributes
• Show Selected Attributes...: Provides a check list of attributes. Check to show, uncheck to hide.
• Show All Operations
• Hide All Operations
• Show Selected Operations...: Provides a check list of operation. Check to show, uncheck to hide.

So now you have the interfaces on your component diagram. Next, you need to identify which components within the system will provide each interface. In this case, a component represents one deployable unit of code: an application, or a DLL, or a data file, or a database, or any other chunk of information and behavior that you create and deploy to a system. So for instance, if you’re building a desktop application, then most likely, each user interface is provided by a single app. So you would add the app to the diagram as a rectangle with two rectangular attachments on its left edge. And you show that a component realizes (i.e., provides) a particular interface or user interface, draw a solid line from the component to the interface or user interface.

To add a component to a component diagram in Tablet UML, draw a rectangle. Tablet UML will add the attachment decorations.

To name the component, tap on the name, and a naming window will appear, including a pen input panel. This will allow you write or type the component name.

(You may also select another content editing mode to edit the name directly within the diagram.)

So now you need to look at each interface and user interface and decide what component provides each one. There are many strategies, and none is correct in all cases. This is where you’ll have to make some architectural decisions. One strategy is The Monolith: every interface and user interface is provided by a single application. Well, if you choose this strategy, then interfaces and even component diagrams aren’t helping you that much. Go straight to Step 5. But a Monolith is not very easy to maintain as system needs change and as the system demand increases. There are better, more maintainable designs. In general, these consists of a number of components communicating with each other, some links direct and some simply sending messages through some sort of a message passing protocol. In this sort of architecture, you’ll find a lot of use for component diagrams to show how the pieces are tie together. These other strategies consist largely of layers and nets. In a net, each component is connected to a certain number of other components, with no particular rules for how components can be connected. This can be flexible, but it can again be difficult to scale and maintain. A more constrained but more maintainable approach is layers: each component resides in a layer; multiple components may reside in the same layer; other components may reside in other layers; and a given component may only make calls within its layer or below its layer. In strict layering, a component may only make requests to the next layer immediately below. If your code needs access to something further down then the next layer down, then an intermediary component has to sit in the next layer down to pass the request along.

Regardless of the architectural style you choose, it’s important to identify dependencies of your components: the ways in which one component uses the interfaces of another component (or less commonly, uses another component directly). We show a dependency of a component on an interface by drawing a dependence arrow: a dashed arrow from the component to the interface. And how do we identify dependency is? Well, by looking at our collaboration diagrams from before, of course. Whenever you see a message start in a swimlane and end in another, find the component that provides the interface or user interface represented by that swim line. That’s where the dependency starts. Then find the swimlane where the transition ends, find the corresponding interface or user interface, and draw the dependence from the component to that interface on the component diagram.

To add a dependency from a component to an interface in Tablet UML, draw an arrow. Tablet UML will convert it to a dashed arrow. If Tablet UML has difficulty recognizing your dependencies, it may be because the Tablet PC API doesn't recognize diagonal lines, only horizontal or vertical. You should try to draw connectors in Tablet UML as close to horizontal or vertical as possible. But if a transition - or anything in a diagram - isn't recognized, you can manually recognize it. Switch to selection mode; select the item; and select the right element type from the manual recognition dropdown list.

You can also perform a manual recognition without switching modes. You can do this via the context menu. Right-click the stroke that you want to recognize, and a menu of possible element types will appear. If your Tablet PC pen does not have a barrel button, you can "right-click" via the press-and-hold gesture. If your Tablet PC pen does have a barrel button, you can "right-click" by holding down the barrel button as you tap the screen. (See your Tablet PC help for details on how to "right-click" with a pen.)

If your Tablet PC pen has a barrel button, there's an even easier way to ensure that Tablet UML recognizes what you draw: hold down the barrel button as you draw. When you lift the Tablet PC pen, the recognition menu will appear, and will let you decide how to recognize what you drew.

And it really is that simple. You can identify your dependencies among components largely through your interaction diagrams: either swimlane to swimlane in an activity diagram, or object object in a sequence diagram or a collaboration diagram. When you have added all of the interfaces and user interfaces and all of the components in all of the realizations and all of the dependencies, you have your component architecture. You probably also have quite a bit of a mess. To this point you had to worry about faithfully representing what came in earlier diagrams, while also making hard decisions about what your architecture would look like as captured in this diagram. So now, you may want to clean this diagram up a bit. Rearrange the icons (this is this is an example another example where a good tool makes the job a lot easier) and lines to try to avoid any more crossings that are necessary. Generally, rearrange to make a neater diagram. You may also find it convenient to break this up into several smaller diagrams, perhaps with one big everything diagram as the reference, but with smaller diagrams focused on particular neighborhoods within the architectural solution.