Welcome To The Business Library Framework    
Use Case Diagrams Explained
   

OVERVIEW

NEWS

ARTICLES

WHITE PAPERS


RESOURCES LINKS

CONTACT US
  Use Cases are typically used to describe the typically visible interactions that the system will have with users and external systems. Typically, they are used to describe how a user would perform their role using the system, and as such form an essential part of the development process.

However, Use cases don't simply form the basis of the requirements capture process. Once defined, they can be used to help define test plans, user guides, and schedules of work, and as such are usable throughout the entire development process.

Use cases are easily accessible for the business, and for the development team, and should be used as a common reference point throughout the project. The business like them because they are easy to link to the relevant business issue or process that is being addressed, and developers like them as they provide a simple structure for understanding the requirements that their software is required to satisfy.

The use case model uses a concept known as actors to visualise what is deemed to be outside of the system ( for example, an Operator, an Administrator, a Customer, or your Accountancy Package ). The use case then defines how this external entity will interact with the system., and the tasks that the system will need to perform.

   
  Documenting A Use Case

Once the architecture has been created, the next step is to build up a profile of how many transactions can be processed, simultaneous objects created and in memory, and bytes of data transferred both in and out of the architecture that the system can cope with.

This then needs to be extended to give figures for different hard-ware configurations. This information is essential in matching the architecture to a project's requirements.

Don't be afraid to be pro-active with this. Even if you don't currently have a project that requires your application to support 25% more of any or all of these profiles, then it is still a worthwhile task to divert internal resources to look at improving the performance characteristics of the architecture.

Keep It Abstract

There's one more key concept that is critical for the success of the layer - and that is to minimise any direct relationship with the business application layer. Try to ensure that this is handled by an abstract interface - allowing you to change the underlying architecture with minimal impact to the system as a whole.

Documenting The Solution

The simplest way of understanding a use case is to look at an example. The example we've chosen here is a simple appointments model, looking at the steps a system may need to perform to support an online booking system for a hotel. In our simple model, we are looking to define a system that allows bookings to be either taken via the web or from the front desk.



The diagram shows both the receptionist and the customer following the same process of making a booking, with the system then checking availability and confirming the booking. In the initial stages of the requirements capture process, this would be sufficient detail. As the overall development continues, then each of the use cases in this diagram ( for example "Send Confirmation Details" ) would be documented in more detail.

Beneath the diagram is the actual use case itself :

Use Case Name   DM001 - Process Bookings
Use Case Description   This use case starts when a booking is initiated either from the company's web site or via the receptionist on the front desk.
Use Case Authors   ARNSYS ( Demonstration Only )
Actors :   Customer
  Receptionist
Locations   Various; Central Hotel, Plymouth
Status   Initial Requirements Capture
Priority   1
Assumptions   The actors have been able to successfully log onto the application
Pre-Conditions   [ A list of all the steps or events that have to have occurred to lead to this use case. ]
Postconditions   - Booking has been taken
  - Client details have been logged
  - Confirmation has been dispatched to client
Primary Path
User System
User enters required booking details System receives booking details, and runs query to determine if the required room is available on the dated in question

The system confirms the booking and issues documentation to confirm booking to the client.
Client reads booking confirmation, and exits system  
Alternative Paths :   [ This section would identify any alternative paths - for example if the customer required child facilities, or sea view or so forth. These would be documented in a similar format to the above ]
Exception Paths :   [ This section would document how the system should behave if the dates were unavailable, or if an error occurs in the process - such as the database not being available ]
Business Rules   [ This section defines any constraints or triggers that relate to the process that is being modelled here ]
Associated Use Cases   DM0123 - Make Booking
  DM0125 - Check Availability
  And so on…


This gives a very brief overview of what a use case is, and how it helps the development and requirements capture process. As you can see, it is accessible to both the client and the development team, and it is capable of storing a wealth of detail.
   
       


overview . news . articles . white papers . resources . links . contacts

All enquiries to architecture@arnsys.co.uk

© ARNSYS 2002. All Rights Reserved