Product Description
The Unified Modeling Language (UML) is one of the most important languages for anyone in the software industry to know. The UML is a visual language enabling architects, designers, and developers to communicate about design. Seemingly simple on the surface, the UML is a rich and expressive language, with many visual syntactical elements.
It's next to impossible to memorize all aspects of the UML. Just as a writer might require a dictionary to work with the spoken word, so too do UML practitioners require a dictionary of sorts. In this book, you'll find information on UML usage, and also on the symbols, line-endings, and syntax used for the following diagram types:
- Class diagrams
- Component diagrams
- Behavioral diagrams
- Sequence diagrams
- Statechart diagrams
- Object diagrams
- Deployment diagrams
- Use case diagrams
- Collaboration diagrams
- Activity diagrams
O'Reilly's Pocket References have become a favorite among programmers everywhere. By providing a wealth of important details in a concise, well-organized format, these handy books deliver just what you need to complete the task at hand. When you need to get to a solution quickly, the new UML Pocket Reference is the book you'll want to have.
From the Publisher
About the Author
Dan Pilone is Rational Certified in OOAD, RUP, and Rose. His previous employer was a Rational Partner and Dan has taught (formally as well as informally) quite a few UML classes for Hughes, ARINC, UPS, Georgia Systems Operation Center (GSOC), and the Naval Research Laboratory (NRL). As a software architect for clients, Dan has made extensive use of UML (in all views of the architecture) to help convey information to management, developers, team leads, and requirement folks (doing use case analysis in a UML-like fashion). Dan is also Sun J2EE Enterprise Architect certified, which required him to submit his own EJB designs using UML sequence, class, and collaboration diagrams. Dan has worked at Hughes Inc. developing a satellite communication system for which they did real-time UML modeling, and also large numbers of State Diagrams to model the acquisition/control stages.
Excerpted from UML Pocket Reference by Dan Pilone. Copyright © 2003. Reprinted by permission. All rights reserved.
Use case diagrams are used to capture the requirements of a system. The term use case is often used to refer to a document that describes a particular piece of functionality a system must provide. Strictly speaking, however, a use case is a UML element, and the document describing a use case is a use case document. Throughout this section, the term use case refers to the UML notion of a use case and not to the document.
Use Cases
Typically, use cases are short phrases or sentences that sum up a distinct piece of functionality a system offers a user. Like other UML elements, use cases are often grouped into packages and can be referenced using their fully qualified name. Along with the name of a use case, there is a sequence of events that describe the behavior of the system when the use case is invoked. UML does not define a notation for recording the sequence of events for a use case, so the sequence is often described in a separate use case document, which is simply a text document created using any wordprocessing program. A use case is represented in a use case diagram by an ellipse.
Use cases are at a higher level of abstraction than other UML elements and describe, from the user’s perspective, functionality a system must provide. Use cases do not specify how the system actually implements the functionality. Use cases are intended to communicate desired functionality from end users to project managers and actual developers.
Actors
Use cases are associated with one or more actors. An actor is a role a user takes when invoking a use case. Since a user can fulfill multiple roles, a single user can be represented by multiple actors. Likewise, a single actor can represent multiple users. An actor is represented as a stick figure with the name of the actor written underneath.
Actors do not always need to represent human users. Actors can be used to represent external systems with which a modeled system interacts. For example, you might model a robotictape subsystem as an actor. Actors help draw the boundary between what needs to be implemented as part of the system being modeled and what exists outside of the system.
Use cases and actors are connected using associations. When using associations on use case diagrams, the directionality of the association indicates only who initiates the interaction, not the direction of information flow. For example, Figure 59 shows both human and machine systems interacting with a use case from an ATM system. Obviously, there is interaction with the customer while the withdrawal takes place; however, the ATM never initiates a withdrawal by contacting the user.
A bidirectional association indicates functionality that can be invoked by either the system or the actor.
