A Few Examples

[Previous] [Next]

So far in this book, we've looked at a very small part of a conceived application. In this chapter, we would like to show you at least part of the rest of that application. We won't bore you by going through the entire application, but we want to share at least some of its ideas with you. Let's begin by taking a look at some parts of the use case model that form a framework for the requirement specification.

The Actors

In a use case model, actors are people, organizational units, or systems that act against the system that's being modeled. An actor might be a consumer of data or services from the system, a supplier of data or services, or both a consumer and a supplier of data and services.

Most actors are human and represent people. Yet a personal actor isn't the same as a person but rather an abstraction of one or more persons. An actor represents a role that one or more persons can play in relation to the system. One single person might be the only one to play a certain actor role; several persons together might play other roles. Some persons play one role only; others play multiple roles. In other words, there's a many-to-many relationship between persons and actors.

When in use case analysis you design a use case model, you don't think about the people, departments, or systems that play the different actor roles. You just think about the roles. For each role, you design an actor. The horse racing system we use as the sample application of the book is meant primarily for customers to use. From the viewpoint of this application, a customer is a person interested in information that potentially could help him place better bets on horses. Therefore, for us, Customer is the first actor that comes to mind.

If the customer should be able to browse race information, somebody needs to make that information available. An Administrator should be able to do that. If the customer must pay for the services of the system, an Invoicer should send him or her invoices and then send information about these invoices to the Financial Application, which is the first and only nonhuman actor of our model. Finally, to give good value to customers, we need a Handicapper to measure the quality of races and of the horses' performance in races and to represent that quality in numeric values. Figure 18-1 shows all these actors connected to the system. Use case analysis is under way!

click to view at full size.

Figure 18-1. This diagram shows the different actors in relation to the ADB horse racing application.

Use Cases

When you know that an actor exists, you can start thinking about its use cases. According to Rational Rose's Help system, a use case is a specific way of using the system from the user's (actor's) perspective. A complete use case model specifies all the ways of using the system and thus forms a framework for the system's requirement specification.

The Administrator's use cases

In Unified Modeling Language (UML), you connect use cases to actors. Figure 18-2 gives a picture of all the use cases that an Administrator has.

click to view at full size.

Figure 18-2. All the primary and secondary use cases for an Administrator.

Some use cases are primary. Those are the ones you would directly connect to the actor. In the diagram in Figure 18-2, there are only three primary use cases. One of them is the Maintain Database Content use case. As you can see in the diagram, five other use cases extend the Maintain Database Content use case. These five use cases haven't been connected to the actor; their connections are indirect through the Maintain Database Content use case. Such use cases that are indirectly connected to an actor are often called secondary use cases.

A secondary use case depends on a primary use case. More often than not, there's room for discussion about what is and what isn't a secondary use case. In Figure 18-2, the Maintain Database Content use case, which is a primary use case, is in reality nothing but a collection of secondary use cases. No real work is done in the primary use case; its only purpose is to divide work among a number of secondary use cases. An alternative diagram is possible here. You could scratch the primary use case and connect the secondary ones directly to the Administrator actor. Nobody could accuse you of anything wrong if you did that, just as nobody could say you're wrong if you stay with the diagram in Figure 18-2. It's mostly a matter of taste in structure and of the preferences that you, users-to-be, and project sponsors might have.

The Customer's use cases

The reason to build our sample system in the first place is to allow customers to browse start lists and analyze races by looking at the past performance of horses. Therefore, the most interesting diagram of actors and their use cases is the one in Figure 18-3. It shows the use cases owned by the Customer actor.

click to view at full size.

Figure 18-3. The Customer's use cases.

According to the diagram, the Customer actor has three primary use cases only. One of them is extended by one secondary use case. But the diagram also has a sign that refers to another diagram that's supposed to extend this diagram. In Figure 184, in which this referenced diagram appears, you can see that a customer studying the details of a race might want to branch to several different views of horse racing. A customer might need to filter the data shown in each of these views. The customer might, for instance, want to see races run on grass over middle distance only, or just the races for the last three months.

As the diagram in Figure 18-4 shows, a specific secondary use case—Filter Races—is designed to handle the filtering requirements mentioned in the last paragraph. You can also see that this use case is used by other use cases. So one use case can extend another use case; what's more, one use case can use another use case.

Use case descriptions

This book is certainly not a course in use case modeling, but just the same, we want to stress an opinion that we very clearly hold: if you want to build a good application based on requirements described in use cases, you must describe each use case in much detail. Until you've done that, no use case can act as a requirement specification, and that's just what a use case is supposed to do. Having said that, we're leaving the subject of use case descriptions. If you want to know more about this topic and if you own a copy of Rational Rose or Rational Enterprise Suite, you'll find a lot of information in the documentation of these products. You'll also find several good white papers about use case modeling on the Rational Web site at http://www.rational.com.

click to view at full size.

Figure 18-4. After seeing details about a race, a customer might want to branch to several alternative views.

Facade Classes Serve Use Cases

The way we see it, a facade class is a business services class that's closely bound to the use case it serves. In most cases, one facade class serves one use case only, but in other cases one facade class serves several use cases that are closely related to one another. In this chapter, we'll show you one example of a facade that serves one use case only and another example of a facade that serves several use cases. Conveniently, the two main actor/use case diagrams we've already looked at in this chapter are well suited to this mission.

Separate facades for separate use cases

Let's begin with the Administrator actor's use cases and, more specifically, with the ones that help the Administrator actor maintain different resource lists. One of these use cases has been the main sample for this book: the one that maintains horse lists. The purpose of Figure 18-5 is to show a number of similar use cases, all indirectly connected through the Maintain Database Content use case to the Administrator actor.

click to view at full size.

Figure 18-5. For the Administrator, each secondary use case has its own facade class.

In Figure 18-5, you can see that each secondary use case has been given its own facade class. An alternative design would be to design one larger facade class and have all these use cases share the same facade. In this instance, however, the design chosen (and shown in the figure) is probably very sound. The number of facade classes is higher than would be the case with the alternative design, but each of them is smaller and more fine-grained than the alternative superfacade would have been. Because they're smaller, each facade class is relatively easy to develop, maintain, and enhance. In addition, such a class also loads and unloads faster, and it uses fewer resources. But here's the biggest argument for this multitude of facade classes: the classes don't have much in common because they're all responsible for different types of information. So there's no real profit in combining them into one superfacade.

Common facade for several use cases

It's another story with the use cases held by the Customer actor. Different customers are likely to use different navigation paths when they browse the information resource to find out as much as possible about the horses running in a certain race. It's much the same for this kind of customer as for a customer using an e-commerce application; different customers are interested in different things and navigate differently. So it might make sense to package support for several closely related use cases in the same facade class. Figure 18-6 shows an example, in which two facades together serve seven use cases.

click to view at full size.

Figure 18-6. For the Customer, each facade serves several secondary use cases.

We have one final comment to add to this discussion about when to have a one-to-one relationship between a use case and a facade, as in Figure 18-5, and when to have one facade serve several use cases, as in Figure 18-6. If you'd prefer one facade per use case in Figure 18-6 and one single facade for all the use cases in Figure 185, who could say you're wrong? We could argue about which design is better in each case, but whatever choice you make would work. The most important thing is that modeling, and thinking about your models, helps you bring order to your design and to make reasonable decisions about it. That's all anybody can ask from you, and if you deliver that you deliver something good.

Facades Constitute Requirements of Main Business Classes

One of the jobs of a facade class is to isolate the client from the complexities and intricacies of the inner parts of the server application. Every facade object needs to delegate all its tasks to main business objects for further processing. So it's a good idea for a modeler to show this kind of delegation in separate diagrams for each facade. When you do, you achieve several good things:

  • You force yourself to think through the process of doing a special thing, which probably gives you a clearer perception of the problem area you're supposed to support. For example, when you draw the diagram shown in Figure 18-7, you must carefully consider what it means to add, modify, or delete a horse from the database. When you do, chances are you'll find out that you ought to consider data other than data for horses, such as data for trainers and countries. Users probably prefer to select a trainer or a country by name, rather than enter a code that's difficult to relate to and to remember. Such reasoning makes your facade dependent on a TrainerManager and a CountryManager object, as shown in Figure 18-7.
  • You document your thinking, thus making available valuable information to the people who are going to implement the classes and the mechanisms you're designing.
  • You take another step forward toward the finished functional and architectural specification of your project.
  • In the case of Figure 18-7, your entity managers already use generalized COM+ interfaces to expose their functionality. If this were not the case, drawing such a diagram would have helped you see the need and the opportunity for such generalization. For example, seeing in a diagram three identical or almost identical interfaces with different names should give you the idea to generalize these interfaces, making them into one.

Figure 18-7 is the first of these diagrams. Looking at it, you see that a horse maintenance facade needs services not only from a horse manager but also from a trainer manager and a country manager. You can also see that the horse manager exposes the methods needed by the facade through an IMaintADO interface, whereas both the trainer manager and the country manager expose the methods needed through an IViewerADO interface.

The diagram in Figure 18-7 isn't very detailed. It just shows the delegation path needed to fulfill the facade object's obligations. A sequence diagram—see Figure 18-8—can add immensely to the knowledge required for the design and implementation of a process such as the maintenance of the horse list.

A sequence diagram shows all the messages required to support a certain scenario. In Figure 18-8, the scenarios are so simple that a single diagram can describe more than one scenario. In a more complicated case, you would probably draw one sequence diagram for each scenario:

  • One for the get empty_add new scenario
  • One for the get horse_modify horse scenario
  • One for the get horse_delete horse scenario

click to view at full size.

Figure 18-7. The fcdHorseMaint facade delegates work to three entity management objects, each through a separate interface.

click to view at full size.

Figure 18-8. Sequence of operations and messages involved in maintaining horse information.

New knowledge acquired

We acquired new knowledge when we produced this diagram. When we modeled the Getting Horses part of the scenario, we found that we needed to access the HorseManager object through the IViewerADO as well as the IMaintADO interface. That was because the IMaintADO interface didn't expose a method to get a list. The only interface to the HorseManager object we had included in our class diagram was the IMaintADO interface, so we obviously had to add the IViewerADO interface to the diagram. The diagram in Figure 18-9 now includes this interface. To serve the fcdHorseMaint class, every HorseManager object now exposes the IViewerADO interface as well as the IMaintADO interface.

And we discovered we needed two interfaces even before we started to program the scenario! That's one of the great things about modeling. Rather than taking a chance, programming away without knowing much about the task at hand, you use modeling to find out what you have to do before you commit yourself to a heap of unplanned code that's difficult to modify and replace. Who, after all, would start building a house without a number of drawings?

click to view at full size.

Figure 18-9. The IViewerADO interface for the HorseManager class is now added to this scenario.

A more complex diagram

Figure 18-10 shows a more complex diagram. This diagram hosts one facade class only, but objects of that class delegate work to seven different entity managers, mostly through separate COM+ interfaces. This facade hides more complexity from clients than the other facades we've been looking at. The clients still have just one object—the facade—to communicate with. Hiding server complexity from GUI objects is one good reason for having facade objects, and this aspect is one of two reasons for showing you the diagram in Figure 18-10. The second reason is the extra complexity hidden by the IHistory interface to the HorseManager class in the lower right corner of the diagram.

click to view at full size.

Figure 18-10. Here the facade really does a good job of hiding complexities from the client.

The diagram doesn't show it, but the IHistory interface has methods such as GetHistory and GetStatistics. At first we designed an interface named IHorseHistory, but then we came to understand that history and statistical information about trainers and jockeys was almost as interesting as history about horses. Therefore, we generalized this interface and changed its name to IHistory, which is neutral and indicates reusability.

Incidentally, when we implemented a Microsoft Visual Basic 6.0 webclass application for the Customer's use case, we found it very convenient to use not only Microsoft SQL Server for our data but also the OLAP Services that come with SQL Server 7.0. As you probably know, an OLAP server keeps and delivers multidimensional data sets, which is in contrast to a relational database that keeps and delivers two-dimensional data sets. So we programmed the same standard HTML 3.2 page to display data from three different sources on the same page:

  • An HTML template specifying the main parts of the page
  • SQL Server for data on races, race entrants, and historical information about selected horses
  • Microsoft SQL Server OLAP Services using OLE DB for OLAP and the multidimensional version of ADO (ADO MD) for statistical information about the same selected horses

The diagram in Figure 18-10 formed the basis for the application.



Designing for scalability with Microsoft Windows DNA
Designing for Scalability with Microsoft Windows DNA (DV-MPS Designing)
ISBN: 0735609683
EAN: 2147483647
Year: 2000
Pages: 133

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net