Table of Contents
- J2SE: Standard Java
- Java Windows NT Services
- Apache Velocity
- Advanced J2SE
- Bytecode Instrumentation
- Dynamic Languages and the JVM
- J2SE 1.5.0: "Tiger"
- Java SE 6
- Java 7
- Core Computer Science Principles in Java (Data Structures)
- Java Generics
- Java New I/O
- Java Sound
- Java Applets
- Java SE Threading
- Resource Management Using Semaphores
- Java Atomic Operations
- JavaTemplate Pages
- Executing Templates with the JtpExecutor
- Java Cryptography Extensions (JCE)
- Java Database Connectivity (JDBC) API
- Jakarta Commons - Net Class Library
- Jakarta Commons HttpClient
- Apache POI
- Regular Expressions
- Cool Tools
- Building an Really Simple Syndication (RSS) Java App
- Logging with Log4J
- Inside Swing
- Swing Components
- Swing Styled Documents
- Web Rendering in Java Swing Applications
- Java Look-and-Feel Graphics Repository
- Java Media Framework
- Quicktime for Java
- Media in Java Review 2008
- External Multimedia in Java
- Graphs and Charts
- Holiday Special: Electronic Greeting Card
- Media Framework: Presenter Application
- Standard Widget Toolkit
- Java Performance Tuning
- J2EE Performance Tuning
- Caches and Pools
- Java Caching System
- Java Compression and Decompression
- Obfuscating Java Applications
- Continuous Integration
- Load Testing
- Tomcat Clustering
- High Scalability with Terracotta
- Troubleshooting Production Performance Issues
- Enterprise Java Testing
- Automated Unit Testing with JUnit and Ant
- Unit Testing: Tips From The Trenches
- Custom Ant Tasks
- Extensible Markup Language (XML)
- Java Web Technologies
- Web Frameworks
- Struts 2
- JavaServer Faces
- Distributed Programming / RMI
- Behavior Tracking Servlet Filter
- Servlet Filters
- Building a Robust Java Server
- J2EE: Enterprise Java
- Spring 3
- Java Design Patterns
- Model-Driven Architecture
- Enterprise Messaging with ActiveMQ
- Event-Driven Architecture
- Developing Standalone Database Applications with Hypersonic DB
- Project Backup
- J2EE Project: Hands-On
- Enterprise Java Beans (EJB) 3.0
- Disaster Recovery
- Java Management Extensions (JMX)
- Service-Oriented Architecture
- Web Services
- RESTful Web Services
- Web Services with Apache CXF
- Atom Syndication
- Project: Building a Web Photo Gallery
- J2ME: Micro Java
- Specialized J2ME
- Optional Packages
- Other Java Technologies
- Derivatives and Competitors
- Java, Engineered for Integration
- The World of Java Tools
- Building Java Applications with Ant
- Managing Java Build Lifecycles with Maven
- Acceptance Testing with FitNesse
- Source Control with Subversion
- Inversion of Control and Dependency Injection
- Roadmap: Becoming an Enterprise Java Developer
- Roadmap: Becoming an Enterprise Java Developer in 2007
- The Business of Enterprise Software
- JavaOne 2006
- JavaOne 2007
- JavaOne 2008 Wrap-Up
- JavaOne 2009 Wrap-Up
- JavaOne 2010
- JavaOne 2011
- How to Survive in a Turbulent Job Market
- How to Hire the Best Talent
- Unified Modeling Language (UML)
- Cloud Computing
- Amazon EC2 and Java
- Enterprise Java in 2008 and Beyond
- Predictions for 2018
Use Case Diagrams
Last updated Mar 14, 2003.
When modeling a system, a good place to start is with use cases. Use cases define how external "actors," which may be people or other systems, are expected to use your system to accomplish a business objective. Defining use cases involves a couple steps:
- Defining your actors
- Defining the interactions that you expect your actors to perform
Actors can be users, external systems, or even local processes that trigger some action in your system. If you were building an online book store, you might identify actors such as users that purchase books, administrators that add new books to your inventory, book distributors that send your system a manifest of books that are being shipped to you, an external book seller that sends you an order for books, an automated trigger such as a cron job or scheduled task that reconciles inventory at 2:00am every morning, and so forth. The point is that you need to identify all external "things" that will interact with your system and group them into roles that you'll call actors.
Once you have identified your actors, the next step is to outline, from a high-level, how you expect those actors to interact with your system. A use case defines, from a user perspective, a complete use of your system. This means that use cases are written with verbiage that is very business-centric. For example, a use case might be "Create a new account," "Add a book to a shopping cart," "Order an out-of-stock book," "Reserve a new book," "Checkout and pay for my books," and so forth. The point is to think about how your actors will use your system in terms of the objectives they are trying to obtain and what they will need to do to obtain those objectives.
Actors can be represented in UML in one of two ways:
- A stick figure with the actor's name below the stick figure
- A box with the <<actor>> stereotype added to it
Figure 1 shows two actors (User and Administrator) in MagicDraw.
Figure 1. UML Representations of Use Case Actors
In most cases people opt to present actors using the stick figure notation, but you should be aware of the alternate notation in case you see it in a diagram.
Actors can be defined individually or using an inheritance relationship if you have actors that truly are specialized cases of other actors. Consider the example of a user and an administrator: you would expect an administrator to be able to do everything that a user could do, but with added functionality, such as the ability to add books to the database. Figure 2 shows how specialization is depicted between actors.
Figure 2. Use Case Actor Inheritance
In figure 2, the Administrator actor is a specialization of the User actor, or put another way, the administrator is a special type of user.
Once you have your actors identified, it is time to analyze your system with the intent of determining what actions you expect your users to perform with your system. In UML, use cases are represented with an oval with the name of the use case inside. This is shown in figure 3.
Figure 3. Use Case Bubble
A use case oval alone is not very interesting, what makes it more interesting is when you include actors and use cases together and show which actors perform which use cases. Figure 4 shows a use case diagram that contains use cases, actors, and associations between actors and use cases.
Figure 4. Use Case Diagram
Figure 4 shows five use cases executed by the User actor and two executed by the Administrator actor. Use cases themselves are more than a singe statement and contain things like:
- Goal in Context: a description of what the use case is attempting to achieve
- Preconditions: things that are required before the use case can run
- Successful End Condition: what you expect the system to accomplish if the action is successful, such as "New account created"
- Failed End Condition: the behavior of the system if the use case fails, such as "Account creation is rejected"
- Primary Actors: the primary actors expected to execute this use case
- Secondary Actors: actors that might be involved in the use case, but are not the ones that instigate the use case
- Trigger: the behavior performed by the actor to start the use case, such as "User asks the system to create a new account" (and note that this is very generic verbiage that does not include implementation details like "User enters a username and password on the create new user page and presses the create account button." We want to keep this as abstract as we can.)
- Main flow: the steps that the system performs to accomplish the use case
- Extensions (or alternate scenarios): different behaviors that might occur in the use case based on different conditions. For example, an alternate scenario to the create user account might define a failure condition when a user tries to create an account with an existing username
As you define the details of your use case you might start to notice that some steps are repeated between use cases. For example, you might need to validate that the user has an active account before allowing him to add books to a shopping cart or check out. If that is the case, you can define another use case that contains that specific set of steps and then include it into your other use cases. This is accomplished in UML by defining the new use case and drawing a dashed arrow to it with the stereotype "<<include>>" on the line. This is shown in figure 5.
Figure 5. Use Case Diagram with <<include>> stereotype
This visually shows that the bottom four use cases include the "Validate that the user has an account" use case. In the detailed flows of the use case (main and secondary) you would simply add an "include: Validate that the user has an account" statement where belongs in the flow.
The include stereotype allows you to include a specific set of steps in your flows, but what happens if you want to take an existing use case and create a new one that modifies some part of its behavior? The include stereotype requires that each step be included in the new use case verbatim, but UML supports the notion of use case inheritance by using the generalization arrow. Figure 6 shows an example of use case inheritance.
Figure 6. Use Case Diagram showing use case inheritance
If figure 6, the "Create a new user account" and "Create a new administrator account" use cases are specializations of the "Create a new account" use case. When defining the steps in the flows you can show the steps that are different between the general use case and the specialized use case.
The final use case relationship concept that you should be familiar with is the "extends" relationship. Unfortunately, extends has nothing to do with inheritance, as Java programmers would think, but rather it means that one use case may or may not include the entirety of another use case based on some condition. For example, you might define an auditing use case and optionally include it if account creation fails.
Figure 7 shows an example of the extends stereotype.
Figure 7. Use Case Diagram showing the extends stereotype
In figure 7, if an error occurs then the "Record Errors" use case is executed.
Use case diagrams are a good way of presenting the actors that use your system as well as the actions that your system performs, with support for componentizing use cases with the include stereotype, creating specialization use cases with the generalization arrow, and identifying optional includes using the extends stereotype.