Supporting the Consideration of Dependencies in Use Case
Specifications
John Kanyaru and Keith Phalp
Karl Cox and Anju Jha
Empirical Software Engineering
Research Group
Bournemouth University, UK
{jkanyaru, kphalp}@bournemouth.ac.uk
National ICT Australia
Sydney, Australia
{karl.cox, anju.jha}@nicta.com.au
Abstract
This paper describes a mechanism to analyse the dependencies among events within use case specifications. The paper
presents an argument for forcing explicit consideration of dependencies, by using an augmented use case description,
which forces the modeller to add pre and post conditions on events. The argument is demonstrated using an industrial
case study involving the specification of real-time monitoring software. The study compares initial use case
descriptions with those where dependency information has been considered. The conclusion is that consideration of
dependencies helps ‘tease’ out hidden issues regarding the problem domain and that appropriate (simple to use) tool
support is vital for industrial application.
1. Introduction
Use cases (and scenarios) have attracted considerable interest as a means of validating requirements
specifications ([1],[2] and [3]). Despite the description of two ways (include and extend) in which use cases
can be related (see[4]), a problem with the use case description (and the diagram) still remains their
inability to represent state-dependent requirements explicitly. There are no provisions in the UML
specification for describing interdependencies amongst use case events. That is, intra-use case
dependencies such as “event E requires that event Q has been previously executed” cannot be expressed in
UML. Moreover (and more worryingly), inter-use case dependencies such as “use case A requires that use
case X has been previously executed” cannot be formally expressed in UML either. In reality, however, use
cases and use case elements do interact. Given the emphasis and the centrality of the use case notation
within the Rational Unified Process [5], it is our position that specification of system behaviour with use
cases must address dependencies amongst constituent events. Indeed, other authors have noted that the
independence rule is often flouted in industrial practice ([6],[7]).
A typical approach to forcing the consideration of dependencies is the construction of behaviour models
based on a process algebra suited to the specification task in hand. For example, [8] uses a process algebra,
Finite Sequential Process to model desired behaviour of components for concurrent systems. The
automated environment, Labelled Transition Systems Analyser, is used to support the construction of
concurrent state models which are animated to visualise implied behaviour. A similar approach within
business process modelling is adopted where process modellers construct state-based process models
showing role interactions (e.g. [9], [10]). In [9], the process modelling language RolEnact is used to
produce business process descriptions that are enacted within an automated environment. By forcing
clients (or users) to step through the logic of their processes, enaction has been shown to enable
clarification of business goals and requirements.
Within UML modelling (and especially use case specifications), mere inspection of the description (or
the diagram [5]) is becoming accepted (see [11], [12]) as a means of determining the accuracy of
specification against users’ expectations. Within business process reengineering, the i* framework
proposes requirement models where the relationship between functional requirements and agent goals can
be established by inspecting strategic dependency and rationale models that show goals, agents, tasks and
dependency relationships [13]. Whereas support tools for i* do provide some model checking support for
assessing dependencies, most validation still requires human expertise. Part of the CREWS project
investigates dependencies in socio-technical systems in terms of dependencies between tasks performed by
roles within the problem context. This is done by modelling the flow of events between the system and the
users [14]. To achieve a reasonable order of events, sequence diagrams are used to delineate the flow of
events within use cases. Thus both the i* framework and the efforts by CREWS do not explicitly address
issues concerning dependencies amongst UML use cases directly.
This paper proposes a rigorous approach similar to the state-based approach of [9] where the detail of
each use case event to occur is explicitly considered. Indeed, one of the authors undertook a study (see
[15]) to evaluate the efficacy of applying a process modelling approach to use case validation. Enaction of
the state-based use case equivalents of process models was found to provide insight into the dependencies
amongst uses case events. However, the problem with the approach was that the effort needed (on the part
of the users) to construct use case descriptions using a formal language (RolEnact), curtailed the uptake of
this approach. Thus, it became necessary to provide further support for authoring descriptions with minimal
effort. An initial prototype tool for minimal effort is described in [15]. The prototype tool was used by
Masters students (in Software Engineering) to specify their software for group projects, has been used by
other researchers - within and outside the group - and has evolved over the last year or two. However, the
arguments for such a tool were always based on industrial needs. Hence, this paper describes an industrial
study. The rest of the paper is organised as follows. Section 2 discusses the consideration of dependency
issues by use of a case study. Section 3 discusses the lessons learned from the study (authoring and
enacting state-based use case descriptions, and additional tool support that resulted from the study). Section
4 offers some conclusions.
2. Dependencies in use case specifications-A Case study
The organisation concerned realised that they needed to improve upon the specification for its existing
software, for maintenance purposes, and then wished to put-in place an improved specification regime for
on-going and new developments. The company (based in the UK), offers third party monitoring and
administration for a variety of real-time control systems across a variety of domains. For example,
refrigeration systems in stores, boiler systems and the like, all need to be monitored and controlled. Hence,
although there are a variety of domains involved, they share many generic properties and processes. On our
part (the authors), this became an opportunity to gain real-world application of the use case tool, by using it
to describe the behaviour of the various subsystems and how they synchronise to perform different tasks.
The study involved five visits (by the authors) to the company offices where interviews were conducted.
The staff that participated in the interviews included two software developers, one applications manager,
one operations manager, and the managing director. Our first interview was with both the applications and
operations manager who provided an overview of the existing systems, associated databases, the nature of
the customers supported.
For each customer’s site, the organisation installs the main monitoring application which has the
following subsystems: alarm receiver, alarm display, network controller drivers, scheduler (a middleware
for inter-component communication), a web-client for data display, database builder, and a file editor; the
databases (created automatically by database builder sub-system) are: Logs database, Alarms database, and
User Tracking database.
A central subsystem providing a connection service to these processes is Scheduler (a type of
middleware for inter-component communication). Essentially, a client application (e.g., an alarm receiver)
accesses fixtures’ current data (e.g. temperature) via Scheduler. Thus, understanding how clients establish
connection with Scheduler is vital to comprehending how most subsystems work. Whereas we were
involved in the specification and validation of other subsystems, we illustrate our approach with reference
to this aspect of the case study.
Initial discussions led to the following use case for a ‘typical’ Client connection process:
1.
2.
3.
4.
5.
6.
Client requests connection via Schedule
Scheduler acknowledges connection
Client sends network layout
Scheduler creates network handler
Scheduler registers network handler with client
Client starts executing its tasks
Figure 1: Client connection use case
Figure 1 is an outline of the typical sequence of events that a client application (e.g. AlarmReceiver)
follows in order to gain network access to poll for data (e.g. request alarm information) or send data to
another application.
Jacobson [4] and Cockburn [16] recognise the need for clarity regarding the condition that must be true
before a use case starts (precondition), and the condition that must hold after a use case completes (postcondition). The problem with this limited dependency description is that it does not explicate the
relationship amongst constituent events. A general presumption when writing use case specifications is that
the events follow a time-order dependency ([15], [17]). That is, event 4 follows from 3, which follows from
event 2, and so on. Furthermore, if the domain is familiar and the problem is simple, it might be possible to
outline the sequence of events in a use case like the one above with confidence. However, many controlsystem applications are complex (e.g. [18]) and involve many interacting functional parts. Thus, we may
not be certain of the interconnectedness nor the dependencies of the tasks where different modules
synchronise [19].
2.1 Intra-use case dependencies
Consider the dependencies amongst the events for the use case in Figure 1 above. We do this by examining
the pre and post conditions for each event to occur and whether an event requires an interaction between
the initiating actor and a secondary actor. This scheme is supported by an automated environment,
Educator, which requires the inclusion of state-based information in use cases descriptions. Crucially,
during the revision of the description in Figure 1 with the help of the support tool, the developers provided
information regarding the states of Scheduler and a Client for each event of the use case. (The resultant use
case – within the tool – is shown if figure 2).
Figure 2: State-based version of Client connection
For an actor to initiate an event (or participate in its execution), it must be in that event’s pre-condition. For
instance, the pre-condition for event 1 to happen is initial. That is, a Client is at initial state prior to
initiating event 1, and Scheduler is in the waiting state as shown in the enaction window (figure 3)
Figure 3: Client and Scheduler states before first event
The post-condition for event 1 is connectionRequested. Thus, the Client application moves to the
connectionRequested state after executing event 1. Since Scheduler must ‘know’ that a connection has been
requested, an interaction occurs in this event. The next available event must be one whose pre-condition is
connectionRequested (following the end state of last enacted event). However, the engineer pointed out that
event 2 of Figure 1 has a pre-condition that a network handle must be registered with the Client prior to a
connection acknowledgement being made by Scheduler. Thus, with a pre-condition of handleRegistered,
event 2 of Figure 1 is not dependent on event 1. Clearly, the transitive dependency assumption of Figure 1
is erroneous and dangerous. For example, where the client application is an alarm receiver, lack of handle
registration (hence no connection is granted by scheduler) means incidents of fire or intruder are not
monitored nor detected. The developers further advised that many clients can make connection requests
simultaneously, but only the client whose network layout has been received by Scheduler can have their
network handle created and subsequently registered. [The finer details regarding network layout
information for client applications is outside the scope of this paper]. This therefore led us (the authors) to
argue that the event whose pre-condition is connectionRequested is event 3 of Figure 1. This allows a
Client to send its network layout following a connection request. This makes event 3 of Figure 1 the next
plausible event as opposed to what Figure 1 implies.
After going through the entire use case producing behavioural prototypes as shown above, we arrived at a
different sequence of events which one of the operators also enacted and agreed were a correct sequence as
opposed to that in Figure 1. The output of the enaction for the state-based use case is shown in figure 4.
Figure 4: Enaction output
The inclusion of state-based information for each event and the enaction provided an interactive
mechanism that increased rigour and reduced communication gap (between the authors and the
developers). This was important when reasoning about the appropriate behaviour for this use case and
many others and helped revise descriptions to arrive at correct ones.
2.2 Inter-use case dependencies
Inter-relating distinct use cases is important for the same reason that inter-relating events of the same use
case is important. For instance, in the use case of Figure 1, network layout information is obtained by
clients from site-based project files. These files are created by a site-based operator by defining the
attributes of various fixtures whose operations are being monitored. Thus, the process of creating these files
is a separate process, supported by a distinct subsystem. Hence, the CreateProjectFiles use case is a
precondition for successful synchronisation of any Client and Scheduler. In other words,
CreateProjectFiles use case must occur before Client can connect successfully to Scheduler. The
developers argued quite candidly that project files must be created (to ensure fixtures settings are ready,
and network properties are set for the client) prior to Client connection being executed. Educator provides
functionality to declare a description as a precondition for another description.
Consequently, an attempt to start the Client Connection use case will automatically call the
CreateProjectFiles use case, which in turn ensures the setting of network layout information for the Client.
After this use case completes, the Client Connection becomes available. Another way of associating use
cases is by identifying a specific event in one description where another use case’s computation is needed.
For instance, one of the developers argued that the design should be changed so that CreateProjectFiles is
only invoked at the event where a Client sends its network layout to Scheduler. That means
CreateProjectFiles use case is invoked upon a Client’s network information being received and found to be
missing some crucial detail. Educator provides functionality for making such an association by allowing the
selected event to be associated with the appropriate use case. This level of flexibility is crucial as
determining the correct sequence of events normally involves many permutations of different behaviour
models.
3. Lessons learned
Educator has been developed incrementally with feedback from group members, colleagues and MSc
students. These users indicated that Educator was easy to use but it was not always straightforward when it
comes to examining intra/inter- use case dependencies. We noted that description authors rarely went
beyond the more obvious global pre and post condition for a use case. However, the clarity and accuracy of
resulting specifications when our approach was adopted in entirety was found to be higher than when such
considerations were not made.
The case study at the Control Systems engineering company provided greater insight into the efficacy of
this approach and tool support. The developers had no difficulties elaborating the states of each involved
actor (subsystem) and the appropriate ways in which they should interact. However, these further thoughts
were made explicit due to the requirement by Educator to construct descriptions in the state-based fashion.
The subtle assumptions that the developers had made came to light and revisions were made to correct the
flaws.
Additionally, other parts of the case study highlighted the need to provide extra capability to ensure
different modes of dependency consideration can be made. For instance, the developers pointed out that
some processes (e.g. creation of databases) are controlled such that their execution is automatic and must
precede any other process. User data logging then takes place after the databases where this data will be
logged has been created. Thus, these two processes are sequential regardless of the state of their internal
events. It became necessary to provide functionality for specifying use cases that can be enacted
sequentially. Moreover, a version of an alarm receiver subsystem runs at each customer site and at the
Control Centre office. A communication link between sites and the Control Centre enables Control
engineers to resolve alarms for customers if the customers leave them for too long, or are unable to resolve
them (e.g. an alarm due to software fault). Thus, a developer (or requirements engineer) needs the
capability to specify processes that are alternate to each other such that a user just chooses the process to
execute. It became necessary to provide this capability too. A further issue that came to light was that of
specifying a process so that it executes every so often (iteratively). This is because some subsystems such
as the Alarms Collection Service (at the Control Centre) must fetch alarm text files (every 15 seconds) and
suggest appropriate course of action to a support engineer. Some other subsystems are allowed to execute
their tasks concurrently. For example, data logging can proceed while alarms are being obtained by the
Alarm Receiver. Thus providing enactable capability for these combinations of behaviour became an
additional interesting outcome of the case study and the functionality has since been incorporated into
Educator.
4. Conclusions
This paper describes the issue of implicit treatment of dependencies in use case specifications and
demonstrates the subtle errors that can be made and their ramifications. Based on the use cases constructed,
we note that requirements engineers and other stakeholders seldom consider dependencies amongst use
case events, nor do they go beyond the typical include and extend relationship in considering inter-use case
dependencies. However, investigation of dependency issues is a task that benefits the understanding of the
problem domain and, in many cases, informs design ([20]).
Production of state-based formal models is a common proposal for forcing consideration of these issues.
We have pointed out that a problem with this approach (except where the target is a set of engineers), is
that many domain experts are non-technical and would find such models difficult to read. Our solution to
this problem is the use of enactable models, which provide rigour during authoring, and support
communication by enacting the description. The use case tool deployed in the case study above affords
these benefits. Indeed, the approach worked well in indicating to the domain experts (the developers and
incidents operators), the implication of their statements, and affording functionality to revise the
descriptions accordingly.
Given the importance of involving domain experts in requirements validation, the potential benefits of
enaction are obvious. However, developers (let alone non-technical stakeholders), do not usually devote
much effort to requirements activities. Hence, tools that provide automated support for requirements
prototyping with minimal effort provide great promise for industrial uptake. It is our position therefore that
consideration of dependency issues is crucial during requirements specification and validation. Tool
support is equally important in forcing consideration of such issues.
References
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
Kulak, D. and E. Guiney, Use Cases: Requirements in Context. 2000: Addison-Wesley.
J.B. Jørgensen and C. Bossen. Executable Use Cases as Links Between Application Domain
Requirements and Machine Specifications. in 3rd International workshop on Scenarios and State
Machines (at ICSE04). 2004. Edinburgh, Scotland.
Glinz, M. A Lightweight Approach to Consistency of Scenarios and Class Models. in International
Conference on Requirements Engineering. 2000. Schaumburg, Illinois.
Jacobson, I., ed. The Use Case construct in object-oriented software engineering. Scenario-based
design: envisioning work and technology in system development, ed. C. J.M. 1995, Wiley: New
York.
Quatrani, T., Visual Modelling With Rational Rose 2000 and UML. The Addison-Wesley Object
Technology Series, ed. J.R.a.I.J. Grady Booch. 2000, London: Addison-Wesley.
Kavakli E. and P. Loucopoulos. Goal Driven Requirements Engineering: Evaluation of Current
Methods. in Eighth International Workshop on Evaluation of Modeling Methods in Systems
Analysis and Design. 2003. Klagenfurt/ Velden, Austria.
Heimdahl, M.P. and N. Leveson, Completeness and Consistency Analysis of State-Based
Requirements. IEEE Transactions on Software Engineering, 1996. 22(6): p. 363–377.
Uchitel S., Kramer J., and J. Magee, Synthesis of Behavioural Models from Scenarios. IEEE
Transactions on Software Engineering, 2003. 29(2).
Phalp, K., et al., RolEnact: role-based enactable models of business processes. Information and
software Technology journal, 1998.
Walters, R.J. A Graphically Based Language for Constructing, Executing and Analysing Models
of Software Systems. in 26th Annual International Computer Software and Applications
Conference. 2002. Oxford, England.
Potts, C. ScenIC: A Strategy for Inquiry-Driven Requirements Determination. in Proceedings of
the 4th IEEE International Symposium on Requirements Engineering. 1999. Los Alamitos, CA:
IEEE Computer Society press.
Tveito A. and P. Hasvold, Requirements in the Medical Domain: Experiences and Prescriptions.
IEEE Software, 2002. 19.
Yu, E. and J. Mylopoulos. Towards Modelling Strategic Actor Relationships for Information
Systems Development -- With Examples from Business Process Reengineering. in 4th Workshop
on Information Technologies and Systems. 1994. Vancouver, B.C., Canada.
Sutcliffe, A. and S. Minocha. Analysing Socio-Technical System Requirements. in 4th
International Symposium on Requirements Engineering. 1999. University of Limerick, Ireland.
Phalp, K. and K. Cox. Using Enactable Models to Enhance Use Case Descriptions. in Proc. of
ProSim'03, Int. Workshop on Software Process Simulation Modelling (in conjunction with ICSE
2003). 2003. Portland, USA.
Cockburn, A., Writing effective Use cases. 2001: Addison-Wesley.
Maiden N and D. Corrall, Scenario-driven systems engineering. 2000, IEE Seminar: London.
Leveson, N.G., et al., Requirements Specification for Process-Control Systems. IEEE Transactions
on Software Engineering, 1994. 20(9).
Dahlstedt A. and A. Persson. Requirements Interdependencies-Moulding the State of Research
into a Research Agenda. in Ninth International workshop on Requirements Engineering:
Foundation for Software Quality. 2002. Velden, Austria.
Harel, D. and R. Marelly, Capturing and Executing Behavioral Requirements: The Play-In/PlayOut Approach. 2001, The Weizmann Institute of Science: Rehovot, Israel.