![](bg3.png)
actor, which represents a category of external users,
communicates with the system, i.e. use cases, to ful-
fill its goals. Goals represent functionality required of
the system, which can be used to categorize users into
actors. Between two actors, there is only one rela-
tionship: specialization. Each use case has a precon-
dition and postcondition, which demarcates the scope
of the use case. A use case is a description of a cohe-
sive set of dialogues that actor communicates with the
system. There are five kinds of relationships between
two use cases, and two kinds of relationships are dif-
ferent from the UML (OMG, 2002). The Precede re-
lationship defines that one use case is sequenced (ap-
pended) to the behavior of the preceding use case. It
is very useful in some application. The EqualTo re-
lationship defines that one use case’s behavior is the
same as the other use case. It can be very useful for
requirement eliciting. Episode can be used to struc-
ture use case. It represents a coherent part of the use
case. Episode can be referenced by different use cases
or other episodes. The control flow is added to de-
scribe more complex dialogues. Condition is used to
describe the status of actor or the property of the en-
vironment and the target system that needs to be ful-
filled in order to invoke dialogues. There are three
kinds of events: message, action, and timer. The ”In”
message and ”Out” message always appear as a pair.
The ”Out” message is earlier than the correspondent
”In” message. The action event is an internal event of
actor. The timer events: SetTimer and KillTimer, are
used to describe time constraints.
Our use case metamodel incorporates B. Regnell’s
work (Regnell, 1999) as well as other people’s work
in use case modeling. There are three different lev-
els of abstraction. At the use case level, use case
is related to the external entities, i.e. actors. At the
episode level, the internal episode structure of the use
case is described together with its different variants
and parts by defining sequences, alternatives, loops,
and concurrencies. At the event level, episode is de-
scribed in further detail in term of events that occurred
in each episode.
4 TOOL DESIGN AND
IMPLEMENTATION
4.1 OVERVIEW
In our use case refactoring tool, there are two subsys-
tems (see Figure 4): the refactoring framework and
the prototype tool. The refactoring framework is inde-
pendent to the prototype tool. Two subsystems com-
municate through the Facade design pattern (Gamma,
1994).
Figure 4: Overview Of Use Case Refactoring Tool.
In the refactoring framework, the Refactoring pack-
age conducts the whole refactoring process. Each
refactoring has a precondition, which is an object of
the Condition package. At the beginning of the refac-
toring, the precondition is checked. During the check-
ing process, the condition object communicates with
the code model object. The code model object an-
alyzes the use case model, and determines whether
the precondition is met or not. If the precondition is
met, the refactoring object generates a change object
to modify the use case model. The change object will
communicate with the code model object to complete
the corresponding change, and return a change object
which is used to undo the change. The Tool Interface
package is utilized to communicate with the proto-
type tool subsystem. We will describe these packages
in detail in following sections.
We also use the prototype tool to evaluate the
refactoring framework. It contains two packages: a
Refactoring Tool GUI and a Use Case Diagrammer.
Through the Refactoring Tool GUI, user can initi-
ate a refactoring and input corresponding information.
Then Refactoring Tool GUI will send the requirement
to the refactoring framework Tool Interface package
to complete the refactoring. After refactoring, user
can view the result through the Use Case Diagram-
mer.
4.2 STORAGE
XML is widely accepted for storage and information
exchange (Yamane, 2000). It provides a number of
positive attributes, such as tractability, extensibility,
structure, openness, and independence between data
and style. Document Type Definition (DTD) provide
a grammar for creating XML document structure. We
store use case model using the XML format. Figure
5 shows the DTD that is used to structure the storage
of our use case model.
In our DTD, there are four major entities: Actor,
Usecase, Episode, and Extend. An Actor entity con-
tains the actor information, such as name, communi-
A PROTOTYPE TOOL FOR USE CASE REFACTORING
175