In this step, you simply take each component identified in the last step, and repeat the whole process from beginning to end, as if the component were a system in its own right. For each interface of the component, you break out the detail into Activity Diagrams and then, by adding swimlanes, identify the classes that are responsible for each action. By examining how calls are made between swimlanes, you can work out the associations and dependencies between classes.
Let’s see how this process works in more detail.
Collect together all of your components by adding a component to your model for each interface to your component. Treat your component like an actor and repeat the requirements definition process, as if each method of an interface were a use case for the (component) actor. If an earlier diagram indicates that a method uses another interface from some component, add that other interface as a collaborating actor, and label the communication to that actor with the name of the requested method.
If you’re working through this process as an exercise, then I recommend that you do at least two component Use Case Diagrams for practice, and more if you wish.
You should also think about user interfaces at this stage. If your component provides any user interfaces, add the actors that use those interfaces to your model; and add the actions supported by that user interface as use cases for that actor. If an earlier diagram indicates that an action uses another interface from some component, add that other interface as a collaborating actor, and label the communication to that actor with the name of the requested method.
Take each component use case, and repeat the requirements refinement process by creating a thorough component Activity Diagram for the use case. (If you’re working through this as an exercise, do at least two component Activity Diagrams for practice, and more if you wish.) Define your Primary Scenario for each Activity Diagram, and then define your Exception Scenarios.
Recall that during analysis, you were supposed to concentrate on business rule exceptions (e.g., “What happens if the user isn’t authorized to use the system?”). Now is the time to concentrate on implementation exceptions (e.g., “What happens if the hard drive fills up?”). These component Activity Diagrams aid you in preplanning how to detect and handle exceptions.
Note that, if you used subactivity states in Step 2 or Step 3 to simplify your requirements Activity Diagrams, you may have given yourself a head start in designing your component Activity Diagrams. If a subactivity state represents one method of an interface or one action of a user interface, then its constituent activities capture some important business rules that must be implemented.
Finally, examine your Activity Diagrams to see whether subactivity states might simplify any complex logic.
Add swimlanes to each component Activity Diagram. Within a component Activity Diagram, the swimlanes will represent component actors (either true actors or interfaces related to the class) and objects of classes. As you add swim-lanes for new objects, add the corresponding class icons on a separate Class Diagram. As you assign activities to each object, make them into operations documented in the class icon.
It is common to have some sort of “gateway class” that serves as the entry to the component for the interface. For a user interface, the gateway class will be the form or dialog box that provides the user input. For a component interface, the gateway class will be a class that realizes the interface, providing the same attributes and operations as the interface (plus others as needed). The gateway provides the surface implementation of the responsibilities specified in the interface. (This isn’t the only way to implement an interface, but it is a very natural approach in any OO language.) You depict a class realizing an interface much as you show a component realizing an interface: a circle for the interface, connected to the class via a solid line.
Now revise the component Class Diagram to depict the associations required by the component Activity Diagrams. Your swimlanes in this step reflect interfaces, user interfaces, and classes. Select one of the interfaces from the swimlanes, and put an icon for it in a Class Diagram. Then, if the interface is realized by one of your classes, add that class, with the realization line connecting them. (If the interface is external to your component, just show the interface.) Repeat for each interface swimlane. (Don’t add «user interface» elements, because they’re entirely described by the classes that provide them.)
Next add classes for the remaining swimlanes. Also add classes for the object flow states in your Activity Diagrams. Think about what attributes each class will need to support its operations. Add these to its class icon.
Needless to say, all of this takes a lot longer to do than it does to say. Let’s see how all this works out in an example.
As part of our example in Step 4, we saw that the Kennel Management Engine component will realize two interfaces: Pet Info (the interface for manipulating Pet information) and Owner Info (the interface for manipulating Pet Owner information). Pet Info and Owner Info both require simple edit and query methods.Pet Info and Owner Info Interfaces
For the Pet Info interface, this results in the component Use Case Diagram shown in Figure 2-34.
Note the communication from the Write Vital Stats use case to the Vital Stats Info interface, with a Create Vital Stats Record label. This corresponds to the information in our earlier swimlaned Activity Diagram shown in Figure 2-13, and tells the designers and implementers of Write Vital Stats how they are expected to carry out this responsibility.
Now, I know I told you to design one component at a time (on a real project, you might have one team designing each component simultaneously); but for the sake of this example, I’d like to turn to another component, one that has a user interface. We’ll choose Check In Form because it’s most interesting. Because they provide complementary examples, we’ll look at both Kennel Management Engine and Check In Form for the rest of this example.
So looking at Check In Form, what was the next step again? Ah, yes:
Well, by examining the Check In Form component that we diagrammed in the last step, we can see that it provides a user interface, Check In UI; and that it has three actions, as indicated in Figure 2-26: Get Owner Name, Get Pet Name, and Get Vital Stats. These become component use cases for Check In Form; and the actor interacting with those use cases is the Pet Owner, as indicated by Figure 2-30. Combining this information, we end up with Figure 2-35.
Note how, based on our swimlaned Activity Diagram for the Get Pet Info use case shown in Figure 2-12, we add one communication to the Owner Info interface and two to the Pet Info interface.
blog comments powered by Disqus