Constructing Logical Pieces


Your first major step in designing a system is called “system decomposition.” In this step you take the big-picture point of view and break your system up into “logical” pieces. You use a package diagram to group classes that must work together. (See Chapter 7 and Chapter 20 for more details on the package diagram.) You build component diagrams showing subsystems to present a consistent concept of how your system is put together. Later on you create real physical artifacts such as program code, Java scripts, or Web pages for each of these logical parts of your system.

Packing up your classes

You create subsystems to group classes together in a conceptual (logical) way for your design. The basic notation for a subsystem is a rectangle with the name of the subsystem at the top of the rectangle with a stereo type of «subsystem» and optionally a small fork icon in the upper-right corner of the rectangle. We use the fork icon to help the developer quickly pick out the subsystems from a complex diagram. Subsystems are a kind of package. The idea here is that just like packages that hold classes, subsystems can hold classes for your design. Take a look at Chapter 7 for more information on how and when you can put packages to work. Each subsystem in your system owns the classes within it. You cannot have the same class owned by two different subsystems. However you can import classes into a subsystem from another subsystem or package. (You can find more details on importing in Chapter 20.)

Figure 19-1 shows a simple subsystem labeled Reservations Business Logic. The subsystem contains the Person, Room, and CreditCard classes. The reservations business logic subsystem also contains the reserves association and the pays-with association. You can think of the Reservations Business Logic subsystem as a logical grouping with some of the classes required by the hotel reservation system.


Figure 19-1: A subsystem and its components.

 Warning   Your design classes should be owned by one—and only one—subsystem. The idea is to treat subsystems just as you would UML packages: Make sure you don’t put the same class into more than one subsystem. If you do, you find their definition mutates into something different in the different subsystems, and confusion will follow. A frazzled developer may grab the wrong definition of the class, use it in an application, and break the system.

 Tip   You don’t have to put the same class in more than one subsystem, because a subsystem can import and reuse classes from other subsystems. (We explain importing classes in Chapter 20.)

Decomposing your system

You can think of your system as being one large package with all the classes contained inside—but that gets confusing. It’s easier (and saner) to organize your system so that it’s composed of groups of classes. You group your system’s classes so that each group of classes must handle the behavior of only a part of your system—for example, realizing a use case or accessing a database. These groupings are what we’ve been calling subsystems. Each subsystem is capable of dealing with one important part of the overall problem your system is designed to solve.

 Warning   We see projects get out of hand when they have just one package holding all the classes. The developers get confused and the system implementation is disorganized. You can get away with just one package if the software applications are small. If you build a large system, however (like a hotel-reservation management system), then sooner or later you’ll have to break it up into smaller, more manageable pieces.

 Tip   Use the following major techniques to identify subsystems and get started with system decomposition:

  • Establish subsystems: Split your system into three major subsystems:

    • Presentation: The presentation subsystem is responsible for all interaction with the users.

    • Application: The application subsystem is responsible for handling all the business logic.

    • Data: The data subsystem is responsible for storing data making sure your objects persist.

  • Use aggregation: If you have a large aggregation in your domain model, think about making a subsystem that contains the aggregate and all its parts.

  • Use case: Create a subsystem that contains all the classes for your application that are necessary for making the use case work properly. You may want to combine several similar use cases into one subsystem. (You can find more details on grouping use cases into subsystems in Chapter 20. For more on classes that help your use case come alive see Chapter 7.)

  • Group domain classes: Consider making a subsystem that holds all your domain classes. Domain classes reflect the domain or language of the user. These domain classes appear in various use cases in your application—and they must persist. Having all the domain classes in one place makes it easier to enforce a common definition and provide a common way to store these classes in a database.

 Warning   Not all of these techniques mentioned above are compatible with each other. For example the three tier approach (group by presentation, application, and data) is not really compatible with use case approaches (group by functionality), although a very large system may use a combination of approaches.

If your system is really complex, you can break up any subsystem into lower-level subsystems. There are two ways you can show the subsystems inside your system:

  • Showing subsystems within a package: Figure 19-2 illustrates the subsystem within a package technique for showing system decomposition. The Hotel Reservation System as a package contains three subsystems, Web Presentation, Reservations Business Logic, and Persistent Store(DB). Notice that each subsystem has the small fork icon. The Hotel Reservation System package could have also been shown as a subsystem with a «system» stereotype.


    Figure 19-2: A package diagram showing internal subsystems.

  • Membership notation: You can also use membership notation to show system decomposition. You show the containing package at the top of the diagram. Attach a circle (with a plus sign inside) to the bottom of the package. Then draw a line from the circle-with-a-plus to each of the subsystems. Figure 19-3 shows this alternative notation using the package membership notation. The package diagrams in Figures 19-2 and 19-3 mean the same thing. Normally we prefer showing subsystems inside the main system package—that way it’s easier to understand the containment visually.


    Figure 19-3: Packages diagram using membership notation.

Developing subsystem responsibilities

As you get these logical subsystems in place, you should ask yourself, Just what is each subsystem responsible for? Your subsystem is an aggregate or whole and the classes inside are the parts. Just as your system has major operations it must perform (use cases), each subsystem has a group of major operations for which it’s responsible.

To help you understand what each subsystem must do, we recommend you create a simple class diagram that shows each of your subsystems as classes—and each subsystem’s major responsibilities as operations.

As an example, the hotel reservation system has a Reservations Business Logic subsystem. This subsystem is responsible for making room reservations, canceling reservations, guaranteeing a reservation, finding a room, checking its availability, and getting a price for the room. Figure 19-4 shows the major operations for the Web Presentation, Reservations Business Logic and Persistent Store(DB) subsystems.


Figure 19-4: Subsystems with major operations as possible responsibilities.

 Tip   You can focus on each subsystem, one at a time, and show its responsibilities as use cases and the other subsystems as actors. An example of this approach is given in Chapter 8.




UML 2 for Dummies
UML 2 For Dummies
ISBN: 0764526146
EAN: 2147483647
Year: 2006
Pages: 193

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