Use Case Diagrams Explained
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 :
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.