5
•
Use case components
To reuse components, start by expressing the specific use cases and features of the
application system in terms of the more generic use cases offered by the reusable
component systems.
-
•
Selected use case components can then be specialized and augmented to create the
use case model.
Problem: most code and class libraries are hard to reuse and yield disappointing
levels of reuse, because they are often searched too late, after the major design
decisions have been established.
- frameworks can improve the reuse situation.
•
An application framework: a skeletal application that can be readily augmented to
produce a complete application.
-
Delivered as a set of concrete and abstract components that are architected and
designed to work together to provide most of the functionality needed by a set of
related applications.
- many architectural and design decisions explicitly reveal themselves in the class
structure.
- reuse by subclassing some classes, directly reusing other classes, or adding some
new classes.
5.1
•
The use case model shapes the rest of the system
Defines what a system should do.
- used during requirements capture.
•
Users of the system are called actors.
- each actor defines a distinct role assumed by a person or a machine interacting with
the system.
- each way an actor uses the system is a distinct use case.
•
Each use case defines a set of interactions with the system.
•
the use case model consists of actors and use cases, together with descriptions of their
interactions and connections.
1
- define how responsibilities are allocated to actors and use cases.
•
a responsibility is something that an actor or use case needs to do or keep track of as
the system is used.
- a contract or an obligation of a class or a type.
•
The use case model is described in number of documents:
- use case description: defines the responsibilities of one use case, the
responsibilities of the actors as they interact with instances of that use case.
•
Input to object modes (analysis and design models) which describe how the system is
architected and designed.
•
Related to the analysis and design models via several mappings which show which
analysis types contribute to which use cases.
•
Instances of several analysis types collaborate to perform instances of a use case,
segment of a use case, or a use case responsiblitity.
-
described using collaboration diagrams or sequence diagrams, collectively called
interaction diagrams.
- see Fig. 5.1: traceability
5.2
Reusing components to build the use case model
•
use case components can be reused during requirements capture by treating the
component systems as a toolbox of reusable model elements.
•
Each use case component defines some system responsibilities in problem-oriented
terms.
-
See Fig. 5.1 and Fig. 5.2.
* each use case component in the component system is traceable to corresponding
reusable type and class components.
•
Reasons to reuse use case components:
- effectiveness: use case components used as a toolbox expressing known system
functionality.
- quality: improve quality of the requirements capture by reusing certified use case
components.
2
- predictability: project estimates can be improved by reusing use cases, since more
will be known about how to implement them.
- uniformity: use case components provide a common shape and set of functionality
for each application system, ensures consistency of terminology and systems.
•
Benefits when developing analysis, design, implementation or testing models:
- design reuse: possible to reuse also the design and implementation of use cases.
- design reuse: possible to reuse also the design and implementation of use cases.
- rapid learning: use cases provide usage-oriented documentation of the component
implementation.
5.3
Design the use case components for effective reuse
•
An easy-to-use set of use case components is critical to (re-)usability of the entire
component system.
•
Terminology used to describe actors and use cases is important:
-
A common and consistent glossary of terms used to describe the problem
requirements and features should be developed.
* avoid many misunderstandings by using standard and well-thought-out terms.
-
Careful use of the terms helps reusers distinguish and relate variants.
* e.g., using the phrases Withdraw Money, Withdraw Cash Variant, and Withdraw
Digicash Variant makes the connections, differences, and roles of the components
obvious.
•
Each component system should have its own glossary of terms.
- e.g., terms like Instrument, Transfer, Monitor, Exchange, and Stock mean different
things in the banking domain, the networking domain, and other domains.
- a subset of the glossary will be described in one of the documents attached to the
façade (domain dictionary).
•
This glossary is also used later when developing object models of a system.
- for system-level component systems, the terms might also reference key
implementation features that reusers might need to understand.
3
•
Some use cases are used only inside the component system, to ensure its coherence
and reliability, while others are explicitly exported for reuse.
5.4
Not all use cases should be reusable components
•
Abstract use case components can often be used to implement common mechanisms,
such as Monetary Transfer, see Fig. 5.3.
•
The more generic the use case component, the more useful it is, but also potentially
more expensive to develop, understand and reuse.
•
Some use cases provide useful mechanisms to reuse only later as application use
cases are designed and implemented.
5.5
Reusing concrete or abstract actor and use case components
•
An actor component is an actor designed and packaged to be reusable in several
systems.
•
A use case component is a use case intended to be reusable in several systems.
•
Actor and use case components can be either:
- concrete and reused as-is, as common components without change, or
* e.g., use case component for User Login.
- abstract, meaning that they need to be specialized before reuse.
•
E.g., when abstract use case and actor components need to be specialized:
-
•
Several application use cases have almost the same description, but with
variations in how user or system errors are dealt with.
Variation points define varying responsibilities and features in the use case
component.
-
when such use case components are reused, they have to be specialized by
attaching use case variants at the variation points.
•
When several application systems have the same actor with the same characteristics,
it is feasible to define a concrete actor component which can be reused as-is.
•
When several application systems have similar actors, it may be feasible to define an
abstract actor component.
4
- each application system can then inherit the component actor, adding to or
specializing its role.
* inheritance can thus be used as the variability mechanism.
- E.g., pp. 121.
•
When several application systems need to offer the same use case, it can be
represented as a concrete use case component.
- can be reused as-is.
- e.g., pp. 121
•
When application systems need to offer similar use cases, the component aspects can
often be represented as abstract use cases.
- offer both common responsibilities and variation points.
* structure the use case to display one or more variation points, and pick an
appropriate variability mechanism.
- have to be specialized by attaching use case variants at the variation points when
reused.
- see Fig. 5.4
5.6
•
Expressing use case variability
Abstract use case components often have associated variants exported along with
them.
- a reuser may then import the abstract component, select among the provided
variants, and import the chosen variant for immediate attachment.
* see Fig. 5.5
•
Several ways of expressing commonality and variability of use case components, and
several different types of variability mechanisms that are useful.
-
•
E.g., use case templates, macros and parameters, use case inheritance (uses), use
case extensions.
Typical reasons to exploit variability in a use case component:
5
- varying user or system interfaces: e.g., different kinds of users, or different
specializations of use cases.
- different entity types referenced: e.g., an Account may be either a checking or a joint
account.
* see Fig. 5.3 and Fig. 3.26.
- alternative and optional functionality: e.g., pp. 124.
- varying constraints and business rules: e.g., pp. 125.
- error-detection: e.g., pp. 125.
- performance and scalability differences: e.g., pp. 125.
•
E.g., different types of use case variability mechanisms, see Fig. 5.6
5.6.1
•
Using use case parameters and templates
A parameterized use case contains use case parameters.
- a parameter, Parameter, will be indicated by the variation point {Parameter} in the
body of the use case description.
- when the use case is specialized and reused, these parameters will be replaced by
some other text or references.
-
Define relatively simple and well-defined variability that is often to be replaced in
multiple places.
- 4 different types of parameters in Fig. 5.6.
•
A more complex form of parameterization is to treat the use case as a template.
- a generator tool would process the use case description or an attached template
specification.
- the “text” associated with each variation point is treated as a procedure invocation or
an executable expression in some scripting language, such as Visual Basic Script.
5.6.2
•
Using use case inheritance
The uses generalization can be used to represent commonalities among several use
cases.
6
- see Fig. 5.7
5.6.3
Using use case extensions
•
A use case extension is a use case that extends another use case.
•
Best used when it is necessary to attach several variants at one variation point in a use
case.
- e.g., pp. 128.
5.6.4
•
Choosing between uses and extends for variability
Extends can be used in 2 different ways:
- add a flow to a use case which is already “complete” in itself.
- add some variant at a carefully selected and designated extension point in a use case
component.
•
The extension provides some specialized behavior that is executed when an instance
of the extended use case is executed.
- the abstract use case component behaves as a kind of “template” or “frame” into
which the extension is inserted.
•
Uses is used to reuse or inherit common behavior definitions, which can then be
augmented
- employed when there is a sequence of common behavior that can be reused by
several other use cases.
7
5.7
•
Packaging and documenting use case components
Actors, use case components, variants, facades, and glossary need to be carefully
packaged and documented for effective reuse.
-
•
independent components and variants need to be organized into an independent
configuration.
Stereotypes of package, «configuration item» and «configuration», are used to
represent configuration items (CI), or items grouped into a configuration.
- see Fig. 5.8
•
Careful use of the glossary terminology and a standardized document format can
highlight the situations in which a certain component or variant should be selected.
- e.g., document could have several standard sections which explain under which
circumstances a certain variant might be preferred, and how to specialize the
component using the variant.
8