Five Step UML, Step 5: Repeat

You might want to model each component within a separate package of the current model. To create a new package in Tablet UML, click the Package Button: .

Or you might even want to model each component within an entirely separate model. To create a new model, click the New Model Button: .

And what do we do with actors when we’re trying to understand requirements? We Define: we put each actor in a use case diagram, and we identify the use cases that it requires. In this case, some of the actors really represent other components; but the same way of thinking applies: pick an actor, identify its requirements and expectations of the system, show these as use cases in a use case diagram, and show other actors – other components of the system and other actors to the system itself and that participate in the use case. Just as before, this diagram provides context: not just what features the component must provide, but also what actors will be requesting those features and what actors will be assisting in carrying them out. The fact that the actors in question are now perhaps other parts of the same system we’re building does not change the basic analysis approach.

Well, once we have actors with use cases to represent requirements, what do we do with the use cases? We Refine: we find the rules for how each one plays out and express those as an activity diagram; and perhaps also, we show state diagrams for how parts of the system change. We’ll start as before, with the activity diagrams.

Now at the design level, activity diagrams reflect the rules as before; but now, the rules that you capture should be much more concerned with implementation issues. What happens if the hard drive fills up? What happens if the network connection fails in the middle of a process? What happens if the user changes the colors of the system? And so on. In these activity diagrams, you’re trying to understand what the behavior is very close to the code itself.

As suggested, we can also add state diagrams at this design stage. In this case, the state diagrams of a component would most likely represent states of its user interface elements and its back end classes; and they might also represent states of individual member fields as various operations take place. Again, state diagrams are useful alternative approach for capturing business rules or in this case capturing implementation rules.

Once we have activity diagrams, what do we do with them? We Assign, of course: we add swimlanes. Or if you prefer, we redraw them with objects, as sequence diagrams or collaboration diagrams. But with any of these approaches, we now want to concentrate on objects that represent classes within the particular solution. Oh, sure, some may still represent the user interface; but most represent deeper classes within the component. Some might even represent individual fields within a single class.

And of course, once we have activity diagrams with swimlanes or sequence diagrams or collaboration diagrams with objects, what do we do with them? We Design: we identify the relationships between those objects or swimlanes. Only in this case the case, most of the objects and swimlanes should represent classes; and so to show the relation between these parts the system, we’ll use the same sort of class diagrams we used to document domain objects, but adding in a lot more programmer level detail: message parameters, return types, etc.. So you add these classes to these class diagrams, and start to really see what the internals of this component looks like. If you repeat this for each component, you should end up with a fairly complete design for each.

We can also repeat in the other direction. In other words, we can discuss where each particular component will be deployed within a network of collaborating in systems.. To do this, we’ll need a deployment diagram. On this diagram, we’ll add nodes: cubes that represent processors where components can be deployed. We’ll also add paths: lines that indicate connections between each individual node and other nodes. And then, we’ll assign each component to a particular node within the system. If two components reside on different nodes and yet communicate via their interfaces, you’ll have to add a path between those nodes.

To add a deployment diagram in Tablet UML, click the Deployment Diagram button: .

To add a node to a deployment diagram, draw a square. Tablet UML will convert it to a cube.

To add a path to a deployment diagram, draw a line connecting two nodes. If Tablet UML has difficulty recognizing your paths, 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 path - 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.