pontoVista

Prévia do material em texto

1
Identifying Aspectual Use Cases
Using a Viewpoint-Oriented Requirements Method
João Araújo
Departamento de Informática,
FCT, Universidade Nova Lisboa
2829-516 Caparica, Portugal
ja@di.fct.unl.pt
Paulo Coutinho
Departamento de Informática,
FCT, Universidade Nova Lisboa
2829-516 Caparica, Portugal
pacoutinho@dgita.min-financas.pt
Abstract
The success of large-scale software systems depends on
how accurate the huge amount of requirements is
elicited and analysed by software engineers.
Requirements engineering provides suitable approaches
to define requirements of such systems in a systematic
way. For example, viewpoint and object-oriented
approaches have adequate mechanisms to reach these
purposes. Nevertheless, the crosscutting nature of
requirements is not addressed by these approaches, but
this can be managed using aspect-oriented concepts.
This work describes how aspects could be integrated to
Vision, a viewpoint-oriented requirements method that
integrates UML models.
1 Introduction
Large-scale software development involves several
participants. Each participant, or stakeholder, may have
different roles, responsibilities and concerns, which can
change at any time. This situation may generate some
problems. For example, with several stakeholders, it is
likely to appear inconsistencies and conflicts. So it is
crucial identify and resolve them at early stages.
At requirements level, viewpoint-oriented approaches
appeared to address these problems through their
structuring mechanisms. A viewpoint encapsulates
information of a stakeholder, localizing the part of the
specification relevant to his/her interests and
responsibilities.
However, there are situations that are not tackled
properly by viewpoint-oriented approaches. For
example, when a stakeholder provides system
requirements that may crosscut other requirements of a
different stakeholder. This circumstance can lead to
tangled or duplicated representations of requirements.
Therefore, it is essential that the crosscutting nature of
stakeholders’ requirements be considered to avoid
having the same requirements spread over the
specification document, which turns to be more difficult
to maintain.
The aspect-oriented paradigm can be used to answer this
problem as crosscutting requirements can be seen as
aspects. In our approach, functional requirements are
abstracted in use cases (which are related to viewpoints)
and the crosscutting ones will be called aspectual use
cases.
This paper is organised as follows. Section 2 summarises
Vision extended to aspects, section 3 presents a case
study applied to the approach, section 4 discusses some
related work and section 5 presents some conclusions
and future work.
2 Vision and Aspects
Vision [Coutinho, 2002] is a viewpoint-oriented
requirements method based on VORD [Kotonya and
Sommerville, 1992], and Preview [Sommerville et al.,
1998]. What distinguishes Vision from them is that it
incorporates UML models [OMG, 2002] and describes
associations and aggregations among viewpoints. In this
paper, we want to adapt Vision to include aspects.
During the process, templates are created to describe
each viewpoint, a viewpoint diagram (based on a class
diagram) is used to show the relationships among
viewpoint, and sequence diagrams illustrate the
interaction among viewpoints. Figure 1 presents a
process model for Vision.
2
Vision
Identify &
define VPs
Identify &
specify NFR
Identify
actors & UCs
Elicit
requirements
Associate
NFRs with VPs
and UCs
Identify rel.
between VPs
Define
communication
between VPs
Define interaction
between VP and
system
Identify and
solve conflicts
Specify requirements
Identify
aspectual UCs
Identify NF
candidate aspects
Figure 1 – Process model for Vision
Each activity is described as follows.
Elicit requirements
Through interviews, questionnaires, manuals and other
documents the essential requirements are obtained.
Requirements elicitation involves careful capture and
organization of all the system information, and this can
be huge. In our approach, the organization is realised via
templates and diagrams, used in the next activities. The
aim of the elicitation process is to produce a document
with all the requirements of the future system.
Identify and specify non-functional requirements
(NFRs)
This activity identifies NFRs of a system, like security
and performance, through the analysis of the elicited
requirements. Each NFR is described using a template as
shown in table 1. This is based on the approaches
described in [Chung et al., 2000] and [Moreira et al.,
2002].
NFRs can conflict with each other. A conflict is
represented by negative contributions between NFRs.
Table 1 – Template for a NFR
NFR Description
Name Represents the name of the NFR
Description Gives a brief description of the NFR.
Influence
V
P
List of viewpoints affected by the
NFR .
U
C
List of use cases affected by the
NFR .
Contribution
List of positive (+) or negative (-)
contributions (-) in relation to other
NFR .
Priority
Classified from 1 to 5. (1-very low;
2-low; 3-medium; 4-high; 5-very
high)
Identify and define viewpoints
By analysing the elicited requirements, we can identify
the relevant viewpoints to the system and specify each
one by means of its name, sources, actors, use cases,
NFRs, relationships with other viewpoints and history.
The resulting template imports elements from VORD
and Preview and adds others to consider requirements
analysis with UML. Table 2 shows the viewpoint
template and a brief description of its attributes.
3
Table 2 – Template for viewpoint
Viewpoint
attribute Attribute Description
Name This identifies the viewpoint.
Focus This shows the definition of theperspective taken by the viewpoint.
Sources This shows a list of sources of the
viewpoint’s requirements.
Actors This shows a list of actors associated
with the viewpoint.
NFRs This shows a list of the NFRs applied tothe viewpoint.
Use Cases This shows a list of functionalities
relevant to the viewpoint.
Aggregation
This shows a list of aggregations where
the viewpoint is involved, illustrated in
the viewpoint diagram and a specific
template.
Association
This shows a list of associations where
the viewpoint is involved, illustrated in
the viewpoint diagram and a specific
template.
Sub
VP
This shows a list of sub viewpoints,
illustrated in the viewpoint diagram.Gen/
Spec Sup
er
VP
This shows a list of super viewpoints,
illustrated in the viewpoint diagram.
History This keeps the alterations of the
viewpoint information through time.
A viewpoint can also be represented as a UML class
with the stereotype «Viewpoint».
Identify and define actors and use cases for each
viewpoint
By analysing the requirements, we identify actors and
use cases of the system’s viewpoints, and document this
in the viewpoint template. Use cases express the
functionality of a system available to their actors. Actors
and use cases can be associated to more than one
viewpoint. Table 3 shows a template that can be used to
describe a use case in detail.
Table 3 – Template for a use case
Use case Description
Name Represents the name of the use case.
Description Gives a brief description of the use case.
Actors List of actors that use the use case.
Viewpoints List of viewpoints associated with the use
case.
Primary
scenario Specification of the happy day scenario.
Secondary
scenarios
Specification of the other scenarios.
Extends List of use cases that this use case extends.
Includes List of use cases that this use case includes.
NFRs List of NFRs that affect this use case.
Associate NFR with viewpoints and use cases and
identify non-functional candidate aspects
After the identification of NFRs, viewpoints and their
use cases, it is necessary to check which viewpoints and
use cases are influenced by a NFR and for each
viewpoint/use case which NFRs affect it. This can be
realised by using the templates of tables 1, 2 and 3. Here,
we can use a similar approach as in [Rashid et al., 2002]where concerns that affect more than one viewpoint are
called candidate aspects. However, we prefer to call
them non-functional candidate aspects, to differentiate
from the functional ones (aspectual use cases). Also, we
extend that approach by saying that if a NFR crosscuts
several use cases of one or various viewpoints they are
also called non-functional candidate aspects.
Identify aspectual use cases
Having identified and specified use cases, we are able to
check whether there is a use case included by more than
one use case of one or more viewpoints, or if there is a
use case that extends more than one use case. If this is
the case we have an aspectual use case, because it
crosscuts several use cases. This use case may be
designed and implemented as an aspect (using AspectJ,
for example). Moreover, an aspectual use case would be
the one that crosscuts several viewpoints. This is useful
in the identification and resolution of conflicts, described
later.
Identify relationships between viewpoints
Relationships such as aggregation, association and
generalisation/specialisation are powerful structural
concepts that Vision applies to viewpoints.
Generalisation/specialisation is defined similarly as in
Preview and VORD. Viewpoints can be also part of
other viewpoints, characterising viewpoint aggregation.
An association between viewpoints implies the existence
of interaction between the actors of different viewpoints,
which is external to the system. This would be
interesting to document in order to be used during the
evolution of a system: some of these interactions would
become part of the system. A viewpoint diagram (similar
to a class diagram) is used to represent these
relationships.
Define communication between viewpoints and
interaction between viewpoint and system
Communication is described through scenarios that
represent a dialogue between the actors of viewpoints.
Message exchange can be specified using sequence
diagrams. Also, the interaction between viewpoint’s
actors with the system can be illustrated using sequence
diagrams. Here, the approach in [Moreira et al., 2002]
can be used to represent some aspects (seen as
crosscutting quality attributes), such as performance, in
sequence diagrams.
4
Identify and solve conflicts
To identify and resolve conflicts, we adapted the AORE
approach [Rashid et al, 2003]. They use a table to check
the contribution between candidate aspects. Negative
contributions imply conflict if the candidate aspects have
the same priority. We do exactly the same for our non-
functional candidate aspects. We also suggest a similar
table to check conflicts between aspectual use cases,
shown in table 4.
Table 4 - Contributions between aspectual use cases
Note: AUC stands for Aspectual Use Case
AUC
AUC AUC1 AUC2 … AUCn
AUC1 − +
AUC2 −
…
AUCn
The AORE approach uses a table to relate viewpoints
and candidate aspects (which can be also used to relate
use cases to non-functional candidate aspects). For
candidate aspects in conflict with the same viewpoints
(and, in our approach, also use cases), weights are
attributed to them.
We also suggest creating two other similar tables: one to
relate aspectual use cases to viewpoints and another one
to relate aspectual use cases to use cases. Table 5
summarises these tables.
Table 5 - Relating aspectual use cases to viewpoints/use
cases
Note: VP stands for ViewPoint and UC to Use Case
VP/UC
AUC VP1/UC1 VP2/UC2 … VPn/UCn
AUC1
AUC2 0.5
…
AUCn 0.5
Stakeholders should use the tables during the negotiation
process to help solving conflicts.
Specify requirements
In this activity the elaboration of specification document
is carried on considering all the aspects identified and
described. This activity is out of the scope of Vision.
3 Case study
The case study we have chosen is a simplified version of
an accounting system of a public institution. In this
organisation, the accounting department is responsible
for payment of salaries and services (e.g., cleaning),
acquisition of office materials, balance sheets, etc. The
head of the accounting department is helped by
accounting assistants.
Identify and define viewpoints
By analysing the requirements, we identify accounting
department as a viewpoint, described in table 6.
Table 6 – Template for the accounting department
viewpoint
Viewpoint
attribute Attribute Description
Name Accounting department.
Focus It manages payments of salaries,
services, etc.
Sources Accounting manuals, etc.
Actors Head of accounting department,
accounting assistants.
NFRs Security, performance.
Use Cases Payment of salaries, payment of
services, cheque printing, etc.
Identify and specify non-functional requirements
(NFRs)
The NFRs that we identify in our example are security
and performance, through the analysis of the elicited
requirements. They are described in tables 7 and 8.
Security contributes negatively to performance, because
more tests are needed to access the system making it
slower. On the other hand, performance contributes
negatively to security as, to be faster, the system may
become more vulnerable.
Table 7 – Template for security
NFR Description
Name Security.
Description Only authorised people should accessinformation.
Influence VP Accounting dept.
U
C
Payment of salaries, payment of
services.
Contribution Negative (-) to performance.
Priority 5-very high.
Table 8 – Template for performance
NFR Description
Name Performance.
Description Information should be accessed in a
short amount of time.
Influence VP Accounting dept.
U
C
Payment of salaries, payment of
services.
Contribution Negative (-) to security.
Priority 5-very high.
5
Identify and define actors and use cases for each
viewpoint
Table 6 lists the actors and use cases of the accounting
department viewpoint. Table 9 describes the use case
payment of salary.
Table 9 – Template for the use case payment of salary
Use case Description
Name Payment of salary.
Description It calculates the salaries for all the
employees of the institution.
Actors Head of accounting dept., accounting
assistant.
Viewpoints Accounting department.
Primary scenario
1. Get info about employees;
2. Calculate salaries;
3. Print cheque.
Includes Cheque printing.
NFRs Security, performance.
Note that cheque printing is included by payment of
salary and also to payment of service, obviously.
Associate NFR with viewpoints and use cases and
identify non-functional candidate aspects
The NFRs security and performance can be associated
with the accounting department viewpoint and the use
cases payment of salary and payment of service. Since
they crosscut several use cases they are called non-
functional candidate aspects.
Identify aspectual use cases
Cheque printing is used by both payment of salary and
payment of service. Therefore, since it crosscuts several
use cases, it is classified as an aspectual use case.
Identify and solve conflicts
As we can observe from tables 8 and 9, there is conflict
between the non-functional candidate aspects security
and performance, as both contribute negatively to each
other, have very high priority and affect the same use
cases. Table 10 shows possible weights attributed to the
NFRs in relation the use cases.
The stakeholders involved must negotiate the conflicts. It
is out of the scope of this paper to define a mechanism to
deal with negotiation, but the tables provide the
necessary information. A possible solution for this is to
reduce the weights of performance for the two use cases
to have a slower, but a more reliable system. Similarly,
we can be apply the same strategy to solve conflicts
involving aspectual use cases.
Table 10 - Relating NFR aspects and use cases
UC
NFR
Payment of
salaries
Payment of
services …
Security 1 1 …
Performance 1 1 …
… … … …
For space reasons we do not illustrate the identification
of relationships between viewpoints, the definition of
communication between viewpoints and the interaction
between viewpoints and the system.
4 Related workThere are several viewpoint-oriented approaches for
requirements. VORD (Viewpoint-Oriented Requirements
Definition) [Kotonya and Sommerville, 1996] has a
process that includes viewpoint identification,
description of services (which could be our use cases),
and conflict identification and resolution. Also, it has the
concept of indirect viewpoint (i.e. viewpoints that are not
directly related to the system, but influence it), which is
used in Vision. In Preview [Sommerville et al., 1998] a
viewpoint encapsulates information about the system
obtained from the stakeholders. Preview includes
viewpoint focus, concerns and history, which are
adopted by Vision. Moreover, Preview has an elaborated
mechanism to deal with conflict resolution, which could
be considered in later versions of Vision.
Leite and Freeman [Leite and Freeman, 1991] describe a
viewpoint-oriented approach where a viewpoint is a
mental state. One characteristic of this approach is the
automatic verification and error detection provided
during elicitation, not contemplated by Vision.
Nuseibeh et al. [Nuseibeh et al., 1994] propose a flexible
approach, allowing the specification of multiple
viewpoints using no predefined notations. Nuseibeh and
Finkelstein define a viewpoint as a way to encapsulate
representation, development and specification of
knowledge, in a particular problem domain [Nuseibeh
and Finkelstein, 1992].
The approaches above are limited, as they do not address
the crosscutting nature of requirements at early stages.
Nevertheless, there are some aspect-oriented
requirements approaches related to ours. For example,
the approach by Grundy [Grundy, 1999] is committed to
component based software development, where there is a
categorization of various aspects of a system that each
component provides to end users or other components.
This approach is too particular for component
development, not presenting proof of its use in software
development in general.
The aspect-oriented requirements engineering (AORE)
approach, described in [Rashid et al., 2002], proposes a
6
model for aspect-oriented requirements engineering
(from which we adopted some elements). The model
supports separation of crosscutting properties from early
stages of the development and identification of their
mapping and influence on later development stages. A
refinement of this approach, using Preview and XML, is
found in [Rashid et al., 2003], where composition rules
for aspectual requirement are defined and a detailed
conflict resolution strategy is presented. Nevertheless,
the approach has not been instantiated to use cases - a
broadly used requirements technique.
In [Moreira et al., 2002], functional requirements are
specified using a use case based approach, and quality
attributes (NFRs) are also described with templates,
identifying those that crosscut functional requirements.
They propose a set of models (use cases and sequence
diagrams) to represent the integration of crosscutting
quality attributes with functional requirements. A similar
approach is found in [Araújo, 2002].
5 Conclusions and future work
This paper presented a viewpoint-oriented requirements
approach with UML, which was extended to include
aspect-oriented concepts. This is observed during the
definition of both non-functional requirements and use
cases. NFRs that crosscut a number of viewpoints or use
cases are non-functional candidate aspects. Use cases
that are included by or extend more than one use case are
called aspectual use cases. Also, uses cases that crosscut
several viewpoints are also called aspectual use cases.
A process model was presented whose original activities
were adapted to contemplate aspects. The advantages
that we can highlight from the combination of
viewpoints, uses cases and aspects are a better
modularisation, traceability and evolution of system
models at early stages, facilitating the detection and
resolution of conflicts. Moreover, aspectual artefacts,
such as aspectual use cases, promote a homogeneous
software development based on aspects. Furthermore,
the approach integrates UML models in a very simple
and efficient way, making it more attractive to the huge
amount of developers that use UML.
For future work we want to apply the approach to more
case studies and real systems. Also, we intend to develop
a tool to support the approach. Finally, we would like to
represent aspects in other UML models, to have a more
complete approach.
References
[Araújo, 2002] J. Araújo, A. Moreira, I. Brito, A. Rashid,
"Aspect-Oriented Requirements with UML", Workshop:
Aspect-oriented Modelling with UML, UML 2002,
Dresden, Germany, October 2002.
[Chung et al., 2000] L. Chung, B. Nixon, E. Yu, J.
Mylopoulos, Non-Functional Requirements in Software
Engineering, Kluwer Academic Publishers, 2000.
[Coutinho, 2002] P. Coutinho, “Vision: um método de
elicitação e análise de requisitos orientado a viewpoints”,
Master’s thesis (in Portuguese), submitted in December
2002.
[Grundy, 1999] J. Grundy, “Aspect-oriented
Requirements Engineering for Component-based
Software Systems”, 4th IEEE International Symposium
on Requirements Engineering, IEEE Computer Society,
Limerick, Ireland, 1999, pp. 84-91.
[Kotonya and Sommerville, 1992] G. Kotonya, I.
Sommerville, "Viewpoints for Requirements Definition",
Software Engineering Journal, 7 (6), 1992, pp. 375-387.
[Kotonya and Sommerville, 1996] G. Kotonya, I.
Sommerville, "Requirements Engineering With
Viewpoints", BCS/IEE Software Engineering Journal,
11(1), 1996, pp. 5-18.
[Leite and Freeman, 1991] J.C.P. Leite, P.A. Freeman,
“Requirements Validation through Viewpoint
Resolution”, IEEE Transactions on Software
Engineering, 17(12), 1991, pp. 1253-1269.
[Moreira et al., 2002] A. Moreira, J. Araújo, I. Brito,
“Crosscutting Quality Attributes for Requirements
Engineering”, 14th International Conference on
Software Engineering and Knowledge Engineering
(SEKE 2002), ACM Press, Italy, July 2002.
[Nuseibeh and Finkelstein, 1992] B. Nuseibeh, A.
Finkelstein, “Viewpoints: a Vehicle for Method and Tool
Integration”, International Workshop on CASE (CASE
92), Montreal, Canada, 6-10 July 1992, pp.50-60.
[Nuseibeh et al., 1994] B. Nuseibeh, J. Kramer, A.
Finkelstein, “A Framework for Expressing the
Relationships between Multiple Views in Requirements
Specifications, IEEE Transactions on Software
Engineering, 20(10), 1994, pp. 760-773.
[OMG, 2002] Object Management Group, Unified
Modeling Language version 1.4, http://www.omg.org.
[Rashid et al., 2002] A. Rashid, P. Sawyer, A. Moreira,
J. Araújo, "Early Aspects: a Model for Aspect-Oriented
Requirements Engineering", Requirements Engineering
2002 (RE'02), Essen, Germany, 9-13 September 2002.
[Rashid et al., 2003] A. Rashid, A. Moreira, J. Araújo,
"Modularisation and Composition of Aspectual
Requirements", AOSD 2003, Boston, USA, March 2003.
[Sommerville et al., 1998] I. Sommerville, P. Sawyer, S.
Viller, “Viewpoints for requirements elicitation: a
practical approach”, International Conference on
Requirements Engineering, 1998.