Multi-Application Use Case Analysis
Using the RSI Approach to Use Cases
Mark Collins-Cope

PDF version


1. Introduction

Traditional use case analysis focuses on documenting business processes in order to drive the development of a system. Whilst clearly beneficial, this approach is of limited benefit when the functionality required to support business processes spans multiple but related applications (application product lines) – some of which already exist (legacy applications), and some of which may not (new developments). The difficulty in these circumstances is that the business process orientation of traditional use case analysis does not help in assigning functionality to the new and existing systems.

In this paper I’m going to explore how the Requirement/Services/Interface (RSI) approach to use case analysis can assist in dividing the functionality required to support a number of business processes across multiple applications.

2. RSI Use Cases

When engineers first undertake use case analysis, a number of issues are raised for which easy answers can't be found in the textbooks. These include: what is the appropriate level of granularity for use cases? If large grained use cases are used, should they decomposed into 'lower level' use cases? If so, at what point should this decomposition stop, and how should these sub-use cases be used? Should user or external system interface functionality be described in use case text? Where do report layouts go? Should interchange file formats form part of the use case analysis process?

The RSI approach to use cases answers these questions by structuring use cases into one of three categories, shown by the UML stereotypes: «business requirement» (R), «service» (S) and «application interface» (I):

3. An example scenario

I’m going to use an example scenario to explaining how multi-application use case analysis works. Although constraints of space mean this is a little simplistic, it does provide a good illustration of some real-life scenarios we have encountered in our consultancy work at Ratio Group.

We’re working as senior developers/software architects in the development team at Video Stores Ltd., a high street video rental chain. With over a hundred outlets in the London area, we’ve have realised our computer systems are not quite up to scratch!

Our existing head-office centralised system – which records stock delivery and allocation of stock to stores - is fairly old, and has become somewhat unmaintainable over the years. We intend to replace this system at some point in the future, but the inevitable financial constraints mean that the existing system will have to stay in place for a while at least. Our business imperatives at this moment are to let customers search for films on the web, to automate in-store recording of rentals and returns, and also to try and clamp down on to-store delivery discrepancies (these have been causing concern for a while - stock levels aren’t quite what they should be!).

Summary of new system objectives
  • to enable customers to browse and search for films we stock on the Internet,
  • to smooth the stock delivery process by informing stores electronically of expected deliveries (thus enabling any delivery discrepancies to be caught), and
  • to enable automated in-store recording of video rentals and returns;

4. Business process modelling

We have identified three main business processes the new system needs to support: video delivery and stock allocation (underlined text indicates use case names), browsing for videos, and renting out and return of videos. So we begin the RSI use case analysis process by documenting these as requirement use cases (see figures 1 - 4).

A note on terminology (system vs. application)
A brief note on terminology here, when I use the term system I mean the overall system to be implemented within Video Stores Ltd. When I use the term application, I’m referring to a part of the overall system which, although it may co-operate with other applications, stands alone (and is generally deployed on its own hardware). In other words, the system (as a whole) is actually realised using multiple co-operating applications.


figure1
Figure 1



Requirement use cases can be documented in a variety of formats. The format shown here is my personal favourite, and is based on a combination of Constantine and Lockwood’s work on “essential” use cases, and Alistair Cockburn’s work on “goal oriented” use cases (see the further information section below).

Requirement use case: video deliveries and stock allocation
Initiating Actor: Administrator
Step Who (Actor) Intent System Responsibilities
1. Administrator Record video deliveries onto system.

For all delivered items, record:

  • Video title
  • Number of videos
  • Supplier

Make any new videos available for web browsing.
2. Administrator Allocate deliveries to appropriate stores

Record:

  • Which videos allocated to which store
  • Stock level allocated
  • Expected delivery date
3. Administrator Initiate the delivery process

Print delivery request reports detailing

  • Store
  • Videos to be delivered
  • Number of each video
  • Delivery due date
  • Warehouse foreman responsible for delivery

Inform stores of expected delivery.
4. Shop Assistant Record delivery of videos to the store

Validation of number of videos delivered against expected delivery.
  Exceptions    
4a    

There is a discrepancy in expected and actual delivery.
4a1 System  

Flag the discrepancy to the user, who will then report it to head office.

Figure 2



Requirement use case: browsing for videos
Initiating Actor: Customer
Step Who (Actor) Intent System Responsibilities
1. Customer Find out what videos we stock using a full or partial title.

Search for and display any video matching the title.

Figure 3



Requirement use case: renting out and return of videos
Initiating Actor: Customer
Step Who (Actor) Intent System Responsibilities
1. Customer Wants to rent out a particular video. None
2. Shop assistant Record that the video has been rented out by the customer.

Record:

  • Date of rental
  • Customer

Indicate and record

  • Required return date
  • Cost of rental
3. Customer Watch the video!

None
4. Shop assistant Record return of video.

Record:

  • rental return

Record and indicate:

  • any late return charges.

Figure 4



So far so good. Our requirement use cases give us a good overview of how our system should work as a whole, and how it should support our business processes. What they don’t do, however, is help in working out which aspects of functionality should be resident on which application at which location. Neither do they help us in determining how our applications need to communicate, nor how our existing legacy system fits into all this.

5. Non-functional concerns

As is the case in most serious developments, we are operating under a number of non-functional constraints - sometimes called ‘quality requirements’ or system ‘-ilities’ (as in ‘scalability’, ‘reliability’, etc) The most important of these, with respect to multi-application use case analysis at least, are those relating to the geographical locations of and communications between the different parts of our system:

Examining these constraints, we can see that our new system will have to be broken down into three co-operating applications:

The problem we face here is that it’s not possible to begin a detailed design of the individual applications until we’ve worked out what functionality lives where.

6. Understanding legacy functionality

As a starting point to solving this we are going to analyse the functionality provided by our legacy system and develop a service use case model to describe it. This result of this analysis (largely undertaken by sitting down and using the old system) is shown in figure 5.


figure5
Figure 5


Examining this model in conjunction with our requirement use cases, it soon becomes apparent that some parts of video deliveries and stock allocation can be implemented using the existing legacy system:

Now we know what the legacy application can do for us, the way is clear to start working out how to implement the unsupported functions.

7. Supporting new functionality

The functionality required to support browsing for videos is assigned to the web-application. To do this, we define a new service use case - find video by title (see figure 8). Renting out and return of videos requires two new services: record rental of video to customer, and record return of video from customer – which we allocate to the in-store system (see figure 8). This enables us to start to document our services.

Service use cases can be documented in a variety of fashions, some very informal (free format text description) and some very formal (using OCL – UML’s Object Constraint Language). I like to use the semi-formal type of description shown in figure 7. This form of description cross references a specification type model (very similar to what is known in OO circles as a domain model, and in database circles as an entity relationship diagram). Figure 6 shows the model referenced by the service description.


figure6
Figure 6 - Partial specification model for web/in-store applications.


Service use case: record rental of video to customer

Inputs: [what information will the UI need to collect before this service can be ‘run’?]
            aStore [which store is the video being rented from]
            aCustomer [the person renting the video]
            aVideo [which video is being rented]

Outputs: [what information will be shown on the UI at the end of the service?]
            aReturnDate [the date on which the video must be returned to the store]

Pre-conditions: [these are effectively translated into checks a UI would perform]
            aStore is in Chain.stores [i.e. it’s a valid store]
            aCustomer is in aStore.customers [ i.e. the customer is a customer of the store]
            aVideo is in aStore.videos [i.e. the store stocks the video being rented]

Post-conditions: [what changes will occur to the applications state at the end of the service?]
            aRentalRecord will be created linking aCustomer to aVideo.
            aRentalRecord.returnDate will be set to 2 days from the date of rental.
            aReturnDate [the output] will be set similarly.

Figure 7

One benefit of developing the specification type model is that it makes clear the need for basic maintenance services (add/update/delete) (see add video to store in figure 8). The requirement use cases don’t actually spell out the need for these services, so the specification type model is providing us with a useful cross-check for completeness.

8. Defining application interfaces

The next issue we need to sort out is what interfaces we want our applications to have. Interfaces come in two flavours – user interfaces and external application interfaces. To find out how to approach user interface specification using RSI take a look at the further information section below. For the purposes of this paper, however, I’m going to focus solely on the external application interfaces.

Both the in-store and the web applications need to get their data from somewhere, and it would be wasteful – to say the least – to duplicate data entry at every location - in hundreds of stores! What we need to do is access the information stored in the legacy application database, and use this to create the relevant video/stock records, etc. in our other applications. We’ll do this by using an asynchronous file transfer between the applications. Common file formats are shown using the stereotype «application interface format» on service/interface use case diagrams – see figure 8 for examples of these. The format of these files will most likely be documented using XML schemas.

We’ll also need a number of interfaces to initiate the transfers at one end, and read files at the other. To get the data out of the legacy application two interfaces - triggered by a timer to run to run automatically at pre-defined times in the day – are required. See update store delivery information and update web systems in figure 8. The two ‘reading’ interfaces, record video to store allocation (in-store application), and update video catalogue (web application), will read the agreed file format and use the pre-defined ‘add’ services to enter the relevant information into the systems.

NOTE: Enlarge the diagram below by clicking on the picture.
figure8
Figure 8 – Service/Interface diagram resulting from multi-application use case process


9. Final service check

The one remaining task facing us is to undertake a final check of our use case model, focusing on making sure the we have all the services needed by our interface use cases. In this instance, we note that we’re going to need two further query services to extract data from the legacy application database (get video catalogue and get store delivery information).

Adding these, we are lead to the final interface/service diagram shown in figure 8. This diagram, with the associated documentation, provides a clear description of what each application does, and how the applications will communicate – clearly defining the functional architecture of our system.

10. Process Summary

Figure 9 shows a summary of the multi-application use case process I’ve just been through.

Step Activity Rationale (with respect to multi-application use case analysis)
1a Develop requirement use case model To get a good understanding of the business processes our new system must support.
1b Develop an understanding of the non-functional requirements of the system [can be in parallel with 1a] To understand the constraints we must adhere to in structuring our application(s).
2. Get a grip on the services already provided by our legacy application (this can be documented as a service use case model. To understand what services our legacy application offers.
3. Allocate requirement use case steps to legacy system This makes clear which parts of our requirement use cases we’ll need to develop new functionality for.
4. Determine the functional structure of our new application(s), and develop a service use case model of them. We need to understand how many applications we’re actually developing, and what they do!
5. Develop an interface use case model of our applications. We need to understand what information must flow between our Systems, and how we’ll achieve this.
6 Final services check. Make sure we’ve got all the services we need. The need for query services (those that do not change system state), in particular, often only becomes apparent once the interface use case model has been developed.

Figure 9



11. Design and Implementation

Having defined the services our applications needs to implement, we may well have uncovered some common functionality - for example the in-store and web systems might well both share the get films by partial title service. This gives us a strong hint that we may be able to identify one or more common business-oriented components during implementation - but that really is another story…

12. Further information