Five-Step UML: OOAD for Short Attention Spans - Design, Repeat - Step 5: Repeat (Page 5 of 13 )
Narrow the scope of your process to individual elements (designed with Class Diagrams). Add other diagrams where they help you understand the system. Repeat Steps 1 through 4 as appropriate for the current scope.
In this step, you’ll narrow your scope to look at a single component (as identified in Step 4). By zooming in to the scope of the component, you can apply the same analysis and design processes to determine the structure of the component.
You’ll begin by playing “Interface Hangman”: treating the interfaces to a component as actors from the perspective of the component, as shown in Figure 2-32.
Figure 2-32. Interface Hangman
If you’re confused about this step, consider this definition of an actor:
An actor represents any outside entity that interacts with your system. It may request services from your system; and it may perform services for your system.
Well, in this step, you narrow your scope so that the only “system” of interest is one particular component (at a time). And “outside” that component lie any actors that interact with it and any other components that interact with it. These all meet the definition of “actors” now that you’ve narrowed your scope; however, one rule for interfaces is that they define everything that is known about the connections between components, both for the source component and for the client component. Thus, from the perspective of the current component, the interfaces and user interfaces that it realizes are all that you know about the actors that make requests of it; and the interfaces on which it depends are all that you know about the actors that provide services to it. So it will have actors that represent the users of any user interfaces it provides; but you’ll also create “component actors” that represent the interfaces related to the current component. (Despite Figure 2-32—which is drawn only to convey the idea of interfaces as actors, not as an example you should follow—you may want to use interface icons to represent these component actors, rather than actor icons. This will emphasize that these are interfaces, not people.)
If the interfaces are component actors, then the methods of interfaces realized by the current component may be treated as component use cases. Again, consider this definition of a use case:
A use case represents what your system does in response to a communication from an actor, and represents how your system carries out a requirement of that actor. It appears in a diagram as a simple descriptive phrase (an action, not an object); but within your model, it’s a placeholder to which you’ll attach additional documentation, more detailed diagrams, and anything you learn about the required behavior.
So if a use case represents behavior required by an actor, then a component actor’s requirements—and thus its component use cases—are defined by the operations of the interface it represents. No other requirements are possible, because the interface completely defines how the component and its client may interact. The only other requirements are those of the end user actors who make use of the component’s user interfaces.
So in this step of Five-Step UML, you’ll perform the following substeps:
- Define the component’s behavior with component Use Case Diagrams, one or more for each interface of the current component, and one or more for each user interface of the current component.
- Refine the behavior by producing a component Activity Diagram for each component use case.
- Assign the activities in the component Activity Diagrams to classes, using swimlanes.
- Design your internal architecture of the component with Class Diagrams (described in the next section).
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 this—unless the class definition is really large and overwhelms the rest of the diagram—because readers tend to assume that a partial list is a full list.
Classes: A.NET Perspective Now you’re 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 another—or 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 object—perhaps 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 one—then 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 #include’ing 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.
TIP: To learn more about Class Diagrams and design, see Chapters 4 and 9.
Exercise 205: Define, Refine, Assign, and Design Within Your Components:
Pick a component to design. (You’ll design all of them eventually.) Then walk through the following procedures to build a design model for that specific component.
Next: Step 5: Process in Detail >>
More Practices Articles
More By Apress Publishing
|
 This article is from chapter 2 of UML Applied A .NET Perspective written by Martin L. Shoemaker (Apress, 2004; ISBN: 1590590872). Check it out at your favorite bookstore. Buy this book now.
|
|
/ 7 
