Click here to view the complete list of archived articles

This article was originally published in the Spring 2006 issue of Methods & Tools

---

Using UML Use Cases to Implement Application Lifecycle Management (ALM) Systems

Paul Bowden, MKS Systems, http://www.mks.com

Abstract

The UML technique of Use Cases provides a powerful tool to elicit and document stakeholder requirements. While usually used in a traditional development context, use cases can be deployed with good effect when implementing an enterprise scale Application Lifecycle Management (ALM) system.

Application Lifecycle Management encompasses the processes and tools employed at all stages of development: from project inception and requirements gathering to deployment and maintenance. With this much broader scope we must take care when planning and deploying several complex interacting systems.

This article describes how use cases can help us plan and implement ALM processes and tools.

Introduction

Implementing an enterprise application lifecycle management system is very different from giving your developers a new version control system to put their source code in. Enterprise ALM affects processes that control the whole software development lifecycle and very likely other areas of the business. For instance an application that supports the financial management of the business will most likely be subject to corporate governance regulations and our systems must be able to demonstrate compliance. Enterprise ALM is always driven by the goal of delivering value to the business and alignment with business strategy, so we should be clear about our scope, the business stakeholders we are going to impact and how we can measure our success.

As with all activities, planning is key. What tools and techniques can we apply to reduce risk and ensure a timely implementation that delivers value? This paper will focus on an important technique in UML, use cases, which can help when eliciting requirements, documenting and planning the implementation and validating we have the systems we need.

Use Cases in an ALM context

A use case is a sequence of actions a person takes to achieve a specific goal. In more detail we can say:

We identify a set of activities, performed in a certain order

We know who performs the actions. The "doer" is usually referred to as an actor. This acknowledges the fact that we may be interested in a class of people, a particular role or indeed another system.

• There is a defined result to the actions: a goal.
• The use case has a descriptive name.
• The use case is usually summarised in a diagram linking the actors to the use cases they perform.

Use cases, being descriptive text within a more or less formal framework, we can develop, discuss and manage them with any of our stakeholders.

By way of a very simple example, thinking in terms of ALM, we can quickly come up with: Check out file. Our actor will be something like Developer, and we can describe the use case thus.

The second paragraph in our use case identifies the "post-conditions", that is, the state of the system after the use case has been completed. Where important, we can also specify pre-conditions for the use case. Pre-conditions specify things that must be true before the actor can execute the use case; for example they have logged on.

The use case can also explore alternate sequences of action or "paths". The non-exceptional path through the use case is sometimes called the happy path. It will often be instructive to explore alternate paths through the use case. The Check Out use case above provides a good illustration. What happens if the actor tries to check out the file and another developer already has it locked?

Alternate path Another user has a lock on the revision that the actor is trying to checkout. The actor branches the file and locks the branched revision. The actor must later merge their changes into the modified file.

This use case expresses an important policy we will implement: developers won’t wait for the lock to be released or make changes locally; they will branch around the lock. Of course, we could choose another policy but the path through the use case has forced us to make the decision explicit.

The use cases are usually illustrated with a simple diagram showing the actors and the use cases they execute.

The diagram complements the detailed text of the use cases by giving a visual representation of the use cases we are considering. This can be useful in workshops where we want to focus discussion on a particular area of the implementation. For instance, how and when we will branch the codebase to support post-release maintenance.

Templates

There are many templates for use cases available as part of methodologies or from various web sites documenting best practice or as part of paid-for consulting. The precise form use cases take is a hotly debated topic and the best advice offered seems to be to do what works for you. However, since we are likely involving a broad range of stakeholders our guiding principles should be clarity to a wide non-technical audience.

Use cases and requirements<

Use cases capture functional requirements but situations may a rise where the development of requirements is separate from that of the use cases. For instance requirements may be prepared in advance by the (internal or external) customer. In this case the requirements map to use cases. This mapping will form a traceability matrix where all requirements are fulfilled by the use cases allowing us to demonstrate that we have satisfied the requirements.

Use cases and functional specifications

Use cases and functional specifications are complementary and can be used together if the need arises. It is obviously important that they are consistent. A functional specification can capture much more detailed information (for instance all the field definitions in a workflow) that would simply cloud a use case and negate its usefulness.

Page 2    Back to the archive list