Content uploaded by Reiko Heckel
Author content
All content in this area was uploaded by Reiko Heckel on Aug 14, 2014
Content may be subject to copyright.
Content uploaded by Reiko Heckel
Author content
All content in this area was uploaded by Reiko Heckel on Jan 29, 2013
Content may be subject to copyright.
Use Cases as Views: A formal approach to Requirements
Engineering in the Unified Process
Jan Hendrik Hausmann and Reiko Heckel
Dept. of Mathematics and Computer Science
University of Paderborn, Germany
Abstract
In Requirements Engineering structural and functional
requirements for a new software system are gathered, an-
alyzed, and manifested. Unfortunately the connection be-
tween these aspects gets lost in the standard object ori-
ented methodology and has to be re-established later on.
Not only is this tedious work but the detection of conflicts
and inconsistencies in early phases is hindered by the sep-
aration of static and dynamic aspects. We propose the use
of graph transformations to specify the connection be-
tween these aspects. Based on what we call an integrated
business model, consistency analysis at the requirements
model level becomes possible.
Keywords: UML, Unified Process, functional specifi-
cations, integrated business model, graph transformation
1 Introduction
At the beginning of each software development there are
several ideas or visions of what the system to be build
should achieve. The techniques developed in the area of
requirements engineering are concerned with gathering,
structuring and integrating these different ideas for the
new system. It is the goal of this process to achieve a
set of reasonable and consistent requirements for the fur-
ther development process. The main problem is the de-
tection and resolution of inconsistencies and conflicts be-
tween competing requirements. The application of formal
methods and notations promises to support this task by
enabling automated analysis. Although multiple formal
methods have been proposed by scientists (see e.g. [7] for
a survey), the standard methodologies in object oriented
software engineering still use very informal and impre-
cise techniques in this phase of the development process.
In particular, what is missing is a coupling between the
structural (data) description (captured in class diagrams)
and the behavior of the system (captured in activity and
use case diagrams). In this paper we will show how to im-
prove this situation by giving use cases a precise descrip-
tion, thus achieving a coupling of the dynamic and static
parts of the model. This allows to apply formal techniques
of consistency analysis.
The paper is organized as follows: Section 2 gives
an introduction to the requirements analysis phase in the
Unified Process (UP) and points out some weak points of
this approach. We will advance the basic ideas presented
in the UP by further elaborating the ideas of a business
model and formalizing their notion in Section 3. Section 4
introduces use case diagrams and their new role in the
context of the integrated business model. Section 5 ex-
tends the notion of views to structure the whole require-
ments model and the concluding Section 6gives perspec-
tives toward furtherwork on this topic.
2 Requirements Capture in the Uni-
fied Process
The Rational Unified Process [6] specifies an object ori-
ented software developmentprocess consisting of a series
of core workflows starting with the Requirements Cap-
ture workflow. Artifacts of this workflow may either be a
domain model and a use case diagram, or an integrated
business model. The domain model captures all relevant
objects existing in the context of the forthcoming system
as well as the relations between them. It is expressed in
the form of an UML class diagram. Accompanying the
domain model, a description of the main workflows of the
system is given in terms of activity diagrams structured
into use cases. A use case is a grouping of actions from
the viewpoint of an actor. An important observation at this
point is that no tight connection exists between the ele-
ments in the domain model and the workflows happening
on them. Neither activities nor use cases contain explicit
links to the objects involvedin their execution, nor do el-
ements of domain models contain operations that would
1
Card
cash
Good
price
Receipt
Item
price
Bill
total
1
to
for
0..1
1..*
Figure 1: Class diagram of the shop example
indicate their behavior.Thus, these models do not support
the basic object-oriented paradigm of coupling structure
and behavior. Later phases of the development process
(analysis) will be needed to reconnect the behavior to the
components. The information for this re-connection is ei-
ther passed on implicitly or additional use case annota-
tions are required [1]. In these annotations e.g. pre- and
post conditions are defined in natural language [2]. We
feel that this information connecting the behavior to the
structure of the system is important and should be speci-
fied in a unambiguous way. Furthermore there is the prob-
lem that without a common underlying domain model,
inconsistencies and conflicts between different activities
in use cases are hard to spot and automated checks are
impossible. It would thus be advisable to obtain a model
which integrates (even at this early stage) the structural
and the behavioral results of the Requirements Capture
workflow. The Unified Process already notes this problem
and introduces the term business model for an integrated
model in which the connections between use cases and the
objects realizing them are displayed. Unfortunately these
business models are not a mandatory part of the UP so
that later phases always build on the weaker notionof do-
main models. Moreover, business models are never for-
mally defined. It is our intention to present an approach
in which the use of graph transformations is employed to
achieve the necessary integrationof the structural and be-
havioral aspect of requirements.
3 The Integrated Business Model
We will introduce a simple example to illustrate our ap-
proach: A shop requests the development of an electronic
cash box system. Typically a customer will choose her or
his goods in the shop and advance towards the exit where
a shop clerk will enter the prizes of the good into the cash
box. The customer will pay the goods, e.g., by using a
credit card. After the payment is completed, a receipt for
the customer is issued.
Collect Goods
Enter Item
Display Total
Create Bill
Client Clerk
Cash Box System
[goods
remaining] [finished]
Figure 2: Activity diagram of the shop example
The relevant classes of this scenario and their rela-
tions are depicted in Figure 1. While a Good represents
the physical object selected by the customer, the Item is
merely its representation on the Bill. The main activities
of the workflow are given in Figure 2. Activities are de-
picted in rectangles with rounded sides. The arrows be-
tween them indicate the flow of control. The diamond on
the right side represents a choice. Depending on the con-
dition (given in square brackets) either the loop into the
enter item activity is selected or the exit towards the Dis-
play Total activity. This activity diagram is already struc-
tured by swimlanes according to the actors performing
the actions. Furthermore a system border (shaded grey)
has already been defined, leaving the activity of selecting
the goods outside the scope of the cash box system.
In addition to this static and the dynamic diagram of
the model we now introduce the functional specification.
While the dynamic aspect focuses on the general flow of
control between the activities, the functional aspect will
describe the pre- and post condition of a single activity in
the form of a graph transformation rule. Figure 3 depicts
the functional aspect of the activity Enter Item. The left
side of the diagram represents the precondition of the ac-
tivity. The right side shows the effect of the execution of
the activity on the objects involved. As the result of the
activity, the Bill is extended by a new Item and its prize
(which should be identical to that of the good) is added
on the amount of the bill.
This specification of the functional aspect can be given
the form of an UML diagram as well, as graph transfor-
mations can be denoted as UML collaboration diagrams
[4]. For the sake of simplicity we do not perform this
2
:Good
prize=p
:Good
prize=p
:Bill
total=f
:Bill
total=f+p
:Item
prize=p
enter item
Figure 3: Functional Specification of the activity Enter
Item
transformation in this paper but stick to the presentation
as shown in Figure 3.
The advantage of specifying this functional aspect of
the model is that it connects the activities to the objects
underlying them. Thus an integration between the static
and the behavioral aspect of the specification is given in
terms of a graph transformation. We will call a model that
contains diagrams to represent all three aspects an inte-
grated business model.
Notice, that we still do not have an integration of struc-
ture and dynamics like in object orientation as we do not
associate the actions to the objects they belong to, but
rather associate a set of objects with a single action. Thus,
the integration of the static and dynamic aspect towards an
object oriented system still remains a task for later stages
in the development process. But with the specification of
the functional aspect, a verification of this object oriented
integration becomes possible.
4 Defining Use Cases
Once the domain model and the workflows are defined,
the Unified Process proposes the definition of use cases.
A use case should group parts of an overall workflow
from the viewpoint of a user. The grouping should be per-
formed in a way that the execution of the use case satis-
fies some user goal. It abstracts from the tasks to reach
this goal and is thus able to present more (in some cases
all) behavioral requirements of a software system in a sin-
gle diagram. When defining use cases on the basis of the
integrated business model introduced in Section 3, a use
case becomes a view on the underlying model. We will
demonstrate this by defining the use cases of our exam-
ple.
We identify two actors in the scope of the Cash Box
system: A Client and a Clerk (which may turn out to be
the same person if a clerks buys something at work).The
whole workflow shown in Figure 2 is reduced to two use
cases. On the one hand, there is the creation of the bill
which is something the actor Client is not really involved
Client
Cash Box System
Clerk
Billing
Pay Bi ll
Figure 4: Use case diagram of the shop example
Enter Item
displa y Total
Create Bill
[goods
remaining] [finished]
Figure 5: View on the behavioral model as defined by use
case Billing
nor interested in. But the payment of the bill is something
both actors participate in (the Client by presenting his
card, the Clerk by printing and handing out the receipt).
This participation is shown as a connecting line between
actor and use case. It should be stressed that only those
activities are grouped into use cases that fall inside the
system border that was established in the definition of the
domain model. Activities outside this border(like collect-
ing the goods) are not considered for the definition of use
cases. Therefore, the more abstract goal of the client ’Buy
goods’is not visible in this model since it contains parts
that are not supported by the Cash Box System.
When defining use cases out of an integrated business
model, use cases acquire a more formal meaning. By se-
lecting the activities included in the use case, it becomes
a view on the overall workflow. As each of the activities
is described by a functional specification in the form of a
graph transformation, the use case specifies a view on the
functional diagrams as well as on the static parts by iden-
tifying the objects related to the activity described. This
interpretation of a use case is shown in Figures 5-7. Here,
the view of the use case Pay Bill on the diagrams of the
shopping example is presented.
The behavioral view of the use case contains the ele-
ments of the workflow that are included in the use case
Billing. As only three of the six activities of the workflow
are present, only a subset of the functional requirements
3
:Good
prize=p
:Good
prize=p
:Bill
total=f
:Bill
total=f
:Bill
total=f
:Bill
total=0
:Bill
total=f+p
:Item
prize=p
enter item
create Bill
display Total
Figure 6: View on the functional model as defined by use
case Billing
Good
price
Item
price
Bill
total
1
0..1
1..*
Figure 7: View on the static model as defined by use case
Billing
Billing
Clerk
\
Billing
oo
Client CashBox Clerk
Client
\
PayBill
OO
//PayBill
OO
Clerk
\
PayBill
OO
oo
Figure 8: Views and view relations identified by the use
case diagram in Figure 4
applies to the use case (see Figure 6). With these func-
tional requirements we are now able to identify the ele-
ments of the static model that are relevantto this use case.
We say that the use case specifies a view on the static
model (Figure 7) as well as on the behavioral and func-
tional model.
5 Identifying Further Views
While the use case Billing could be established by regard-
ing the actions of a single actor, the definition of the use
case Pay Bill represents a more general situation: The card,
which is central to the customer, is irrelevant from the
viewpoint of the clerk, who hands out the receipt. As the
use case involves both objects, they should appear in the
static view of the use case. Thus, both actors define their
own views on the common use case they are participating
in. Furthermore, the system border is a view on the busi-
ness model given by the union of the views of all relevant
use cases.
Figure 8 shows the identified views and their relations.
All views are based on the integrated business model
which provides a common context for the requirement
specification, but is not shown in the diagram.Each of the
view relations (depicted as arrows from the smaller to the
larger view) represents an inclusion of all three aspects of
the model. Each view has to be consistent in itself, e.g.,
not contain objects in the functional model that are not
defined in its static model. Finally, all viewrelations have
to be compatible with the inclusion of their source and
target view in the business model.1
As these relations are formally defined, the consistency
between views can be analyzed, see [3]. In the example
shown above, it might, e.g., be unclear whether the class
Goods is part of the business model. As the activity of
collecting goods is not part of the system, it might seem
1Formally, the diagram is interpreted in the category of views over
the integrated business model and view relations among them, which
can be built as a comma category in a category of graph transformation
systems and view morphisms as defined, for example, in [5].
4
right to leave the class outside as well. On the other hand,
the functional specification of Add Item requires the pres-
ence of a good. Thus, it must be represented in the model.
At this point further investigations on the nature of the
good, its meaning in the context of an automated cash box
and its representation inside or outside the systems can be
triggered.
6 Conclusion and Perspective
In this paper, we have introduced an integration of the dy-
namic and the structural aspect of the business model in
the Unified Process, based on a specification of the func-
tional requirements. By supplying graph transformations
to describe the pre/post conditions of actions, a relation
between the elements of the static and dynamic model
is established. Using this integrated business model, we
were able to define further artefacts of the modeling pro-
cess as views on a common underlying model, making
automated consistency checks and further analysis possi-
ble.
This is a step towards a more formal methodology for
the treatment of requirements in the Unified Process or
other OO development processes. Further work is needed
to assess the usability of the approach as well as its re-
lation with other techniques in requirements engineering.
The potential for automated analysis, especially in view
of the semantic consistency between the requirements of
different actors has to be explored.
References
[1] A. Cockburn. Writing Effective Use Cases. Addison-
Wesley, Reading, MA, 2000.
[2] D. D’Souza and A. Wills. Components and Frame-
works with UML: The Catalysis Approach. Addison-
Wesley, 1998.
[3] G. Engels, R. Heckel, G. Taentzer, and H. Ehrig. A
combined reference model- and view-based approach
to system specification. Int. Journal of Software
and Knowledge Engeneering, 7(4):457–477, 1997.
Preprint at
http://tfs.cs.tu-berlin.de
[4] T. Fischer, J. Niere, L. Torunski, and A. Z¨undorf.
Story diagrams: A new graph transformation lan-
guage based on UML and Java. In H. Ehrig, G. En-
gels, H.-J. Kreowski, and G. Rozenberg, editors,
Proc. 6th Int. Workshop on Theory and Applica-
tion of Graph Transformation (TAGT’98), Paderborn,
November 1998, volume 1764 of LNCS. Springer-
Verlag, 2000.
[5] R. Heckel, M. Llabr´es, H. Ehrig, and F. Orejas. Con-
currency and loose semantics of open graph transfor-
mation systems. Mathematical Structures in Com-
puter Science, 2001. To appear.
[6] I. Jacobson, G. Booch, and J. Rumbaugh. The Uni-
fied Software Development Process. Addison Wesley,
1999.
[7] A. Lamsweerde. Requirements engineering in the
year 00: A research perspective. In Proc. Interna-
tional Conference on Software Engineering (ICSE
2000), Limerick (Ireland), 2000.
5
