Click here to view the complete list of archived articles

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

Use Cases and Implementing Application Lifecycle Management Systems

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

Documentation and training

A very important aspect of the use case model we develop is that it is in non-technical language and uses the vocabulary of the businessdomain. As such they can be understood by everyone involved in the project.

• Stakeholders. Does the implementation fulfil the requirements of the stakeholders?
• Training materials. The key use cases usually express the more complex aspects of the system from an actor’s point of view. This feeds into the development of training materials. A technical author can elaborate the use case model to explain the system as individual interactions and as a whole.
• Technical documentation. A use case model is a central part of the development model within UML (see the 4+1 views of the Unified Process where the +1 is the use case model).

During the elaboration of our use cases we will gain a better understanding of technical and organisational complexities. This can lead us to identify risks in several areas:

• People.
  This may involve the reluctance to implement processes or the ability two groups of actors to come to a consensus.
• Process.
  We could have difficulty in reconciling the requirements of the actors or integrating new processes with existing ones.
• System.
  This can be any technical risk, for instance the integration of systems or the automation of processes.
• Time.
  A particular use case may be required by a certain date to meet regulatory requirements or a business opportunity.
• External.
  A use case may depend on the delivery of functionality within a new version of a tool. Slipping of the third-party release will introduce delay.

The use case is the focus of discussion and the mechanism to record and track the risks. The use cases can also be fed into established processes for risk management used by the business.

Execution and Testing

Armed with our use case model we understand the functions of the system that are the most important as far as delivering business value and/or the most complex in terms of implementation. The customer and other stakeholders understand the system in terms of the key use cases and can see concrete progress as each use case is demonstrated.

The implementation of the system will usually consist of system configuration and customisation, and maybe the development of custom code to integrate with other business systems. Consequently, it may be the case that a use case contains enough information to allow it to be implemented. This is rarely the case in a traditional development scenario where most of the functionality to implement the use case will have to be coded from scratch. In the situation we are describing most, if not all, of the functionality will be available in the toolset we are implementing.

Where this is not the case we need an additional level of detail to provide confidence in the technical solution; confidence in our estimates and documentation for future maintenance.

Drilling into the use cases

Again, we can look to UML to show how we can take a use case and develop its implementation. This is a large subject and it will only be explored briefly here. There are many resources available in the literature and on the web. It is common practice to decompose use cases into Sequence Diagrams. These diagrams show the interaction between system components in terms of the messages they send to each other. A Collaboration Diagram is a different way of expressing the same information. You may find one or the other more useful depending on personal preference. Sequence diagrams focus on the chronology of events and are useful when considering the synchronous or asynchronous processing of messages.

In sequence diagrams objects, subsystems or systems are represented by dashed vertical lines. The messages between systems are shown ashorizontal arrows that may be annotated with message details. Time runs from the top to bottom. The left of the diagram can contain explanatory text.

The two help desk use cases above will illustrate the use of sequence diagrams.

Classify as Development Problem

Here, the Support Representative performs the operation to classify the help desk request as a development problem, probably by setting thevalue of a field. The help desk system (via a trigger) must then invoke anintegration script that creates a corresponding issue in the developmenttracking system. The unique identifier of the development defect is passed back by the script to the help desk system.

This quickly identifies the tasks and deliverables to implement the use case.

• Create a trigger in the help desk system that fires when the classification field is set.
• Create an integration script to create the development task.
• The integration script must have a mechanism to update the help desk issue with the ID of the development task.

Close Defect

When the developer closes the task we have a similar sequence of operations. Note that in the previous integration we have recorded theidentifier of the help desk issue in the development task so the second integration script can invoke the set state operation on the correct issue.

For simplicity the diagram does not explore the failure path.

Conclusions

Although traditionally used within software development projects we can use the technique of use cases when we come to deployApplication Lifecycle Management systems. ALM systems usually touch many partsof the business within and beyond the development sphere so it is important weunderstand the scope of the implementation and prioritise its activities in terms of business value.

The non-technical, problem domain vocabulary used means all the stakeholders can understand and contribute to their development aidingcommunication and removing ambiguity. The model also feeds into other aspects ofthe implementation such as the detailed design, planning, training and documentation.

References

Use Case Driven Object Modelling with UML. Doug Rosenberg & Kendall Scott. Addison Wesley. ISBN 0-201-43289-7

Developing Software with UML. Bernd Oestereich. Addison Wesley. ISBN 0-201-75603-X

Software Configuration Management Patterns. Stephen P. Berczuk, Brad Appleton. Addison Wesley. ISBM 0-201-74117-2

Page 2   Back to the archive list