Professional Documents
Culture Documents
Abstract also Test. In the Analysis & Design discipline the use
cases are refined by use case realizations. The essential
In this paper we present a concept for automated part of a use case realization always consists of one or
testing of object-oriented applications and a tool called more interaction diagrams, i.e. sequence and/or
SeDiTeC that implements these concepts for Java collaboration diagrams. Those diagrams are then used to
applications. SeDiTeC uses UML sequence diagrams, analyze which objects are needed to implement the
that are complemented by test case data sets consisting of functionality of the use case, which methods the objects
parameters and return values for the method calls, as test need to expose, and how the objects need to interact. A
specification and therefore can easily be integrated into detailed description how to create and use sequence
the development process as soon as the design phase diagrams as use case realizations is given in [17].
starts. SeDiTeC supports specification of several test case When it comes to testing (covered by the Test
data sets for each sequence diagram as well as to discipline) the instructions given by the RUP are on a
combine several sequence diagrams to so-called quite abstract level. Relevant in this context is the remark
combined sequence diagrams thus reducing the number of in [11] that typically black box tests are derived from use
diagrams needed. For classes and their methods whose cases whereas white box tests are derived from use case
behavior is specified in sequence diagrams and the realizations.
corresponding test case data sets SeDiTeC can
automatically generate test stubs thus enabling testing 1.2 Sequence Diagrams in FDD
right from the beginning of the implementation phase.
Validation is not restricted to comparing the test case As the name suggests FDD is not use case driven but
data sets with the observed data, but can also include feature driven. A feature is defined [5] as a small (can be
validation of pre- and postconditions. implemented in less than two man weeks), client-valued
function expressed in the form: <action><result><object>
(e.g. calculate the total of a sale).
1 Introduction Figure 1 shows the five processes of FDD that are
themselves further divided into tasks. In the first process a
This paper describes an approach to testing that uses domain object model is created in cooperation with
UML sequence diagrams as test specification. In modern domain experts. Using the information of this model and
software development processes like Rational Unified information gathered from any other requirements
Process (RUP) or Feature Driven Development (FDD) activities (outside FDD) the developers create a list of
sequence diagrams already play an important role in features to be implemented. The third process consists of
design activities. First we would like to shortly discuss creating an overall plan and assigning responsibilities.
this role to show the context sequence diagrams are The processes “Design by Feature” and “Build by
currently used in. Feature” make up the actual iterative part of FDD where
small sets of features are designed and implemented in
iterations that last two weeks or less.
1.1 Sequence Diagrams in RUP