 Practices Page 3 - Five-Step UML: OOAD for Short Attention Spans - Define, Refine, Assign |
Step 1: Define - PracticesThis article introduces the concepts of Five-Step UML, working from beginning to end. It introduces UML notation and goes into great detail. This article covers the first three of five steps. It is from chapter 2 of UML Applied A .NET Perspective, written by Martin L. Shoemaker (Apress, 2004; ISBN: 1590590872).
print this article SEARCH DEV SHED |
Step 1: Define Identify the requirements of your system via Use Case Diagrams. Add other diagrams where they shed light on the use cases. In this step, you’ll describe what your system will do for each external user of the system, as well as what it will require from the users. These requirements shall be captured in Use Case Diagrams. A Use Case Diagram is a way of depicting the interaction between your system and the outside world: your users, other systems, devices, etc. It’s a picture of the things your system will do—and more important, why it does them. At its core, a Use Case Diagram consists of three elements: actors, use cases, and communications. First, I’ll make a quick tour of the UML notation that you need for these three elements, and show you how they fit together to form UML diagrams. After that, I’ll describe in more detail what needs to be done as part of this first step of Five-Step UML.
Isn’t That Just a Feature? More than likely, you’ve used the use case concept in designing systems all along—perhaps even without recognizing it. As I discuss later, a Use Case Diagram is a way of discussing requirements in context. It’s that context—the actors and communications that relate to the use cases—that make them an expressive way of explaining and understanding a system. Actors and use cases are one example of how UML is unified. These concepts were formalized in Jacobson’s work on the Objectory process, and were adopted in UML because they filled a great need for a way to model requirements, not just structure and behavior. UML Notation In this section, we’ll look at the definitions and UML notation for actors, communications, use cases, and domain objects, and see how they all work together in Use Case Diagrams. Actors 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. An actor can be a person; but it may also be another system, or perhaps a device such as a printer. An actor may even be a signal or event to which you must respond. From a component design perspective, you might model the clients of your component as actors, even though those are “the system” from the perspective of the designers of those components. (And conversely, of course, your component is an actor from their perspectives.)
In a Use Case Diagram, an actor usually appears as a stick figure icon (whether it represents a person or not). Other icons are allowed if they communicate the point of a diagram more clearly. Actors: A .NET PerspectiveIf an actor is “any outside entity that interacts with your system,” then in .NET, that covers a lot of territory:
Any person or system that requests that your .NET solution perform a task or does work as requested by your solution is an actor to your solution. Communications No, this isn’t the “communication” that I’ve been harping on since the start of this book. In this usage, a communication is a request or other sort of message between your system and your actors. While you are in the definition phase (Step 1), you don’t usually specify the mechanism by which the communication is transferred: it is enough to know that the transfer occurs. During design (Step 4), you should specify the mechanism in detail, either in the Use Case Diagram or in a Scenario Diagram. As you add detail, you may also describe what information (expressed as parameters) is included in the communication. In a Use Case Diagram, a communication appears as a line or an arrow connecting an actor and a use case. The arrow is used to indicate the direction of a request for service: from an actor to the system, or from the system to an actor. Use a simple line to indicate an actor collaborating with the system without specifying where the request originates. Communications: A .NET PerspectiveGiven the actors described earlier, some communications for .NET solutions include the following:
Any message or event to which your .NET solution responds or which it sends can be represented as a communication. Use Cases 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. In a Use Case Diagram, a use case appears as an ellipse with a name inside or underneath. (Underneath is usually easier when you’re drawing diagrams by hand, because you don’t have to fit the ellipse to the name.) Use Case Diagrams Given these elements, then, a Use Case Diagram depicts the relationships between one or more actors and one or more use cases through one or more communications. Figure 2-1 is a Use Case Diagram that depicts the use cases required by the Pet Owner actor, from the Kennel Management System, introduced in the last chapter.
In this example, the actors are the Pet Owner, the Reservation Agent, the Care Giver, and the Accountant. They interact with the KMS in the following ways:
Notice how, in analyzing the requirements of the Pet Owner actor, we’ve identified a number of other actors. You can thus use Use Case Diagrams as a means to discover additional actors that will use the system.
Who Needs Use Cases? The first time you sit down to draw Use Case Diagrams, you may find yourself— how can I say this?—unimpressed. “Stick figures and bubbles. So what?” I know that was my reaction. It takes a little practice and experience to appreciate the benefit of use cases. After all, you might look at Figure 2-1 and feel that the same information could be conveyed in a simple functional spec, perhaps in bullet-list fashion:
So what do use cases tell you that you couldn’t get from a functional spec? Well, I found two great quotes that, together, really convey the benefit of use cases: A functional specification can be said to answer the question, What is the system supposed to do? The use case strategy can be characterized by adding three words to the end of this question: for each user? —The Three Amigos22 The focus on what the users need to do with the system is much more powerful than the traditional elicitation approach of asking users what they want the system to do. —Karl E. Wiegers33 Who needs use cases? The end users! This is why I feel no Use Case Diagram is complete unless for every use case on it, the actor that initiates it is shown on the diagram and shown to be initiating it. The benefit of use cases is that they tie your model to well-defined user needs. Does that mean I don’t believe in functional specs? Not at all! I like functional specs, for a very simple reason: text isn’t pictures. Not the most stunning of observations, but it’s important. The brain processes text through different channels and in different ways from pictures. That means that text and pictures will involve more brain cells than either would alone. More brain cells is a good thing. Furthermore, different reviewers and different stakeholders have different ways of thinking: some are more verbally oriented, while others are more visually oriented. So by having both text (functional spec) and pictures (Use Case Diagrams), you can more fully involve more brains. More brains is also a good thing. In fact, use cases are more than just a pictorial strategy. Many use case practitioners document their use cases in very structured, very detailed text documents. This subject is beyond the scope of this book (for more information, see Wiegers,4 the Three Amigos,5 Schneider and Winters,6 and Cockburn7); but you could easily structure a functional spec not around bullet lists, but around use case docu ments. And depending on your UML tool, you might even be able to tie use case documents directly to use cases in the diagrams. But if time is short and you can only have diagrams or text, but not both, which one should you choose? I would go with Use Case Diagrams pretty much every time.
Domain Objects Often as you model requirements, you’ll discover things that your system must maintain or represent: bills, schedules, reports, inventories, contacts, etc. You may want to indicate when and how these domain objects—objects within the problem domain—are modified or accessed by your system. You can do this by defining domain classes for these things, and then by adding the classes to existing Use Case Diagrams or by creating new Use Case Diagrams that focus on these classes. A class represents the operations and attributes of one or more objects within your system. An attribute is a characteristic that describes objects of the class, while an operation describes something an object of the class can do. In UML, a class appears as a rectangle broken into three sections. The top section identifies the name of the class, the middle section lists the attributes of the class, and the bottom section lists the operations of the class. In Use Case Diagrams, you can add communications from use cases to the classes they affect, indicating how the system interacts with the objects, such as in Figure 2-2.
By adding Use Case Diagrams with classes, you can see how the actor requirements affect domain objects. This can help you to understand and prioritize requirements related to these domain objects. Analyzing vs. DesigningWhen I begin adding classes to a Use Case Diagram, some students start getting nervous. “Wait a minute!” they say. “We’re gathering requirements, not designing the system. It’s too early to start talking about classes.” And they’re absolutely right that it’s too soon to talk about design; but classes are not just a design issue: they’re a way of categorizing the things around us, whether in the code or in the real world. Real-world things can be categorized. Real-world things can be described. Real-world things can do things. From the perspective of a model, real-world things and software things are very similar in nature, and can be modeled with a very similar notation. So here, you’re using classes and objects to represent the problem domain, not the code. At design and implementation time, you’ll decide which of these real-world classes must become classes in the software, as well as which additional classes are needed to support the system operations. If you’re still troubled by classes on a Use Case Diagram, consider that actors were originally modeled in UML as a special sort of class. After all, actors have attributes (names, IDs, etc.) and can perform operations (authorize actions, acknowledge tasks, etc.). So in essence, when there’s an actor on a Use Case Diagram, there’s a type of class on the diagram. Domain object classes are just another way of describing the interaction of the system with the problem domain. And if you’re still unconvinced, read the first guideline in Chapter 3, Do What Works. If classes help you to understand the point of a Use Case Diagram, then classes are a good thing; and if not having classes makes the diagram less clear, then classes are a must. Exercise 201: Define Your System with Use Case Diagrams:
blog comments powered by Disqus |
|
|
|
|
|
|
|
/ 21 
