Defining Your System | UML 2 For Dummies

Once you have some requirements, it’s a good idea to start describing how your system is going to work. Gone are the days of simple applications that work on one computer. These days you’re likelier to build applications that are split across many different computers. Take, for example, a hotel reservation system that works over the World Wide Web. In our travels, we often use a Web browser to access a hotel reservation system. We look for room availability, make the reservation and specify how we’ll pay for the room. These reservation systems include our computer, its Web browser, an http Web server, server-side programs, the hotel’s own reservation system, a database management system, and access to a credit card authorization system. In the face of this system complexity, you need a way to come up with the right design—and a way to describe that design using UML.

Tip During design, we recommend you think about designing the total system first before diving into the details. When you build complex applications, make some high-level decisions before you focus on designing individual classes. By making decisions about architecture, hardware, networking, software interfaces, components, and databases, you limit the number of possible designs. By looking at the big picture first, you make sure your requirements are handled—and you end up adding classes that your users need, but could never tell you they need. Once you have your system organized and you know you have all the big pieces, then you can focus on the details of designing your classes.

The number of potential designs for the hotel reservation system is almost limitless. Just think of the many possible technologies, network configurations, hardware platforms, class definitions, programming languages, vendor software, middleware techniques, remote communications protocols, and database techniques you could use. (Stop! The room is spinning.) Let’s consider the big picture first to “get our arms around” this system.

The process for designing the big picture involves the following steps and considerations:

Consider the design priorities.

Of course you want to build a system that meets the needs of your users. But, there are other competing factors you must consider in your design, such as the following:
- Functional requirements: Each use case represents required functionality of your system. (For more on use cases see Chapter 8.) Some use cases may be more important than others, and given your budget and schedule you may have to choose which use cases to implement and which to leave for another day. Perhaps the first version of the hotel reservation system implements the basics: making and canceling reservations. The next version will handle marketing features such as surveys and upgrading reservations with earned points.
- Flexibility: You can design your system to be modular. That way when users change their mind (never happens), your design is easy to change. However, the more flexible you make your design, the longer it takes to design—and the more it will cost to build. You could design the system to handle reservations for anything—trucks, videotapes, crash dummies, or theater tickets—not just rooms. But if you do so, don’t be surprised if it takes longer to develop the complete reservation system.
- The “ilities”: Really great designs consider scalability, reliability, and availability to name a few. A design for the hotel reservation system that handles one hotel in version one and can be expanded to handle a whole chain of hotels—without major design changes—is a scalable design. If your design consistently makes and cancels reservations—no matter how may users are connected—then it’s considered a reliable design. If you decide to make the reservation system available 24-7, you must design in enough redundancy to make sure the system stays up even in the event of a failure.
- Performance: Your chosen design has an impact on system speed. If it’s not fast enough, users waste time waiting. If the system is way too fast, you probably spent more money than necessary to develop it. To design the hotel reservation system, we have to ask, How fast is fast enough?
- Cost: Most, but not all, systems that we design have a budget. The design must not cost more than what the stakeholder is willing to pay for the system. For $100 million, we could build a fancy, fast, flexible, modular, scalable reservation system. But, the return on investment for that system would be a long time coming.
- Schedule: Like cost, schedule is a factor in our designs. Usually, market forces such as competition require that a system be designed and built by some date. Otherwise the competition wins with a product that gets market share. Building a hotel reservation system should not take so long that the company looses potential guests to other hotels.
Each of these priorities affects your design. First, we speak with project stakeholders about these design issues to get a sense of priority. If performance is the overriding design priority, then we design our system to achieve high levels of speed through hardware choices and parallel processing. If cost and schedule are the top priorities, we look for ways to minimize the required hardware (because that takes money) and the required functionality (because that takes time and money).

Warning Unfortunately, these design issues are not compatible with each other. Designing to one will impede your design in another. For instance designing for performance usually increases your costs. Designing your system to meet the all the needs of users impedes your ability to meet your schedule. Because of these design trade-offs, we recommend you get these priorities straight first before launching into the hard work of designing a complex system.
Review current system.

If your new system is a replacement or an addition to some existing system, take a look at how the old system is designed. Choices that made sense for an older system (such as that of the database vendor) or for a specific hardware platform may limit your “new” design. In our reservation system example, the older hotel reservation system is built on a simple client-server model. We can reuse the hotel’s current room reservation management server as part of the new reservation system.
Decompose the system.

Take your system and break it up into smaller subsystems. This is what engineers have always done—take a big problem and break it into lots of smaller problems. If we can solve each of the smaller problems, then combining the solutions should solve the bigger problem. We would break up the hotel reservation system into conceptual pieces such as user presentation, the business logic behind making reservations, persistent storage, and credit-card processing. Now, if we can define these simpler pieces known as subsystems, the new hotel reservation system is as good as designed.
Define an architecture.

Once you define your subsystems, you have to describe how those subsystems relate to each other—and the hardware that supports those subsystems. Our presentation subsystem runs on the machines belonging to potential guests who visit the Web site. The business-logic subsystem runs on a combination of hardware, including a machine running Linux as well as our existing reservation-management server. Credit-card processing starts on the same machine as the reservation management server and utilizes a B2B (business-to-business) server across the Internet.
Choose object persistence.

Some of your objects must persist. If your system is turned off, you have to preserve your objects so they don’t get lost. During this step, you have to decide how you will preserve those objects. Some of your options include relational database management, object-oriented database management, and plain old files. Your choice has a significant impact on the design of a persistence subsystem, and on how other subsystems can use it. If a guest makes a reservation using the hotel reservation system today—and the system goes down tomorrow—that reservation had better be there when the system comes back up. Often designers use an existing relational database to hold hotel-reservation information.
Define subsystem interfaces.

Treat subsystems just like classes. Each subsystem is responsible for some major operations. During this step, you decide what those operations are and describe them as interfaces. The credit-card processing subsystem is responsible for checking the validity of a guest’s card. And the subsystem must authorize any charges against a guest’s credit card.
Select Components.

Building today’s systems for maximum flexibility means designing with components. A component is a modular, self-sufficient, replaceable unit that works like a black box in your system. In this step, you select which parts of your system you want to act as replaceable or reusable units (that is, as components). The CreditCardAuthorization subsystem, the Reservation class, and the Room class are good candidates for modular components.
Pick system strategies.

You have to consider how your system starts up and how it shuts down. You must have a design strategy for handling errors and system failures. Regrettably (in this day and age), your system also must consider information security, data integrity, and customer privacy. These concerns may add use cases, classes, and subsystems to the overall systems design. The hotel reservation system must protect guest credit-card numbers and people’s addresses from prying eyes. The system must not allow hackers to modify any reservations.

Warning The first time you perform Steps 1 through 8 on a project, don’t make any hard and fast design decisions. Just review the issues because each decision you make at each step has an impact on decisions you could make during the other system design steps. For instance, when you decide to use a certain vendor’s relational database-management system, doing so imposes limits on how you define your interfaces—and on exactly how you could decompose your system into subsystems.
Iterate Steps 2 to 8.

Now, having visited the design issues presented in Steps 1 through 8, revisit each step and make some tentative decisions based on the design priorities you chose in Step 1. Use UML diagrams such as a package diagram and a deployment diagram to capture your design choices.
Iterate again.

We find that a good system design emerges after going through Steps 2 through 8 two or three times.

Designing your system involves a lot of steps. Luckily, UML provides you with notation and diagrams to help. Table 19-1 lists the major design elements that need defining during systems design and the UML diagrams that help you.

Table 19-1: Systems Design Diagrams
Design Element	UML Diagram	Description
System Decomposition	Package Diagram and Component Diagram	Take your system and break it up into more manageable pieces known as subsystems. Show the subsystems and show their dependencies.
Interfaces	Class Diagram	Explore and then describe the contractual obligations of each subsystem. Treat each subsystem as if it were a class and describe the operations for that subsystem.
Hardware	Deployment Diagram	Describe the hardware you will use to run your software. And show how the hardware is connected together. Show the physical hardware architecture for your system as nodes with communication paths between them.
Components	Component Diagram	Show which parts of your system are really replaceable units also known as components. Show the structure of your system as black boxes with their interfaces, ready for replacement or reuse.
Deployment	Deployment Diagram	Indicate how your components and subsystems are realized as physical artifacts. In addition, show the hardware on which those artifacts are deployed.