U Ca Description of Requirements for Product Lines
A. Bertolino^, A. Fantechi*, S. Gnesi^, G. Lami^ , A. Maccari+
琼中*Dip. di Sistemi e Informatica - Università di Firenze - Italy
^Istituto di Elaborazione della Informazione - C.N.R. - Area della Ricerca C.N.R. - Pisa - Italy
+ Nokia Rearch Center, Software Architecture Group - Finland
Abstract
Capturing the variations characterizing the t of products belonging to a product line is a key
issue for the requirements engineering of this development philosophy. This paper describes ways
to extend the well-known U Ca formalism in order to make possible the reprentation of
the variations, in the perspective to make them suitable for an automatic analysis.
1. Introduction
The development of industrial software systems may benefit from the adoption of a development cycle bad on the so called system-families or product lines approach [2,5]. This approach aims at lowering production costs when the products share the overall architecture and conception, but differ with respect to particular characteristics. The variations reprent the customisation of the product with respect to the other members of a family of systems. The production process is therefore organized in product lines with the aim of maximizing the commonalities of the product family and minimizing the cost of variations.
In the first stage of a software project, called usually requirements elicitation, the knowledge of the system under construction is acquired. Inside a product line, both problems of capturing requirements common to all members of the product family, on one side, and of specializing the general product family requirements into tho ones of a single product, on the other side, have to be addresd.
To deal with the problems, a clo look to the nature of the relations between family and product requirements should be given: in the relations the concepts of parameterisation, specialization and generalization can play a major role.
On the other hand, the problems are not easily formalized, due to the nature of requirements, which are often given in a natural language pro. Without sacrificing the immediateness of the natural language, at least a notation that adds structure to the requirements should be adopted.
U Cas are a powerful tool to capture functional requirements for software systems. They allow for structuring the requirements documents according to ur goals and provide a means to specify the interactions between a certain software system and its environment. In his book on how to write U Cas [1], Alistair Cockburn prents an effective technique for specifying the interactions between a software system and its environment. The technique is bad on natural language specifications (i.e., phras in plain English language) for scenarios and extensions. This makes requirements documents easy to understand and communicate even to non-technical people.
The purpo of this paper is to prent how to extend U Cas in the direction of addressing Product Line requirements, including some specific constructs to deal with variability.
This paper is structured as follows: in ction 2 we describe the principal characteristics of U Cas, in ction 3 we discuss the impact of variability on the Product Line requirements. In ction 4, possible extensions to U Cas to face variability are discusd; finally in ction 5, conclusions and future rearch directions are prented.
2. Background: U Cas
A U Ca describes the interaction (triggered by an external actor in order to achieve a goal) between a system and its environment. A U Ca defines a goal-oriented t of interactions between external actors and the system under consideration. The term actor is ud to describe the person or system that has a goal against the system under discussion. A primary actor triggers the system behaviour in order to achieve a certain goal. A condary actor interacts with the system but does not trigger the U Ca.
A U Ca is completed successfully when that goal is satisfied. U Ca descriptions also include possible extensions to this quence, e.g., alternative quences that may also satisfy the goal, as well as quences
that may lead to failure in completing the rvice in ca of exceptional behaviour, error handling, etc.. The system is treated as a "black box”, thus, U Cas capture who (actor) does what (interaction) with the system, for what purpo (goal), without dealing with system internals. A complete t of U Cas specifies all the different ways to u the system, and therefore defines the whole required behaviour of the system. Generally, U Ca steps are written in an easy-to-und
erstand, structured narrative using the vocabulary of the domain. A scenario is an instance of a U Ca, and reprents a single path through the U Ca. Thus, there exists a scenario for the main flow through the U Ca, and as many other scenarios as the possible variations of flow through the U Ca (e.g., triggered by options, error conditions, curity breaches, etc.). Scenarios may also be depicted in a graphical form using UML Sequence Diagrams.
Figure 1 shows the template of the Cockburn’s U Ca taken from [1]. In this textual notation, the main flow is expresd, in the “Description” ction, by an indexed quence of natural language ntences, describing a quence of actions of the system. Variations are expresd (in the "Extensions" ction) as alternatives to the main flow, linked by their index to the point of the main flow from which they branch as a variation.
Figure 1. U Ca template
3. Variability in PF Requirements
Following the System Family Engineering Process Reference Model defined in the CAFÉ project [6], and shown in Figure 2, product family development is characterized by two process: Application engineering and Domain engineering. Domain engineering is the process aiming at developing the general concept of a family together with all the asts which are common to the products of the family, whereas Application engineering is intended the process aiming at designing a specific product. During Application engineering a customer specific application will be defined. However, differently from the usual single product development, the definition process of the customer specific application is not only influenced by the requirements of the customer but also by the capabilities of the product family.
This diagram shows that it is possible to move from the family level (by means of the system family engineering activity) to the product level and vice versa (by means of the system family rever engineering activity).
用四面八方造句
和狗狗做Going upwards, applications are developed considering the capabilities of the product family speciali
sing, extending and adding family requirements. Conquently, software product families need more sophisticated requirement processing and requirements should deal with some variability notion.
In particular, product family requirements can be considered in general as compod of a constant and a variable part. The constant part includes all tho requirements dealing with features or functionalities common to all the products belonging to the family and that, for this reason, do not need to be modified. The variable part reprents tho functionalities that can be changed to differentiate a product from another.
Figure 2. The CAFÉ-PRM reference framework
Following the above process we can e variability from two different perspectives: the first is the product perspective where each variability has to be considered as an aspect to be instantiated. Whereas, from the family perspective a variability is a goal to be reached by abstracting all the instances related to the existing products belonging to a product line.
It is possible to move down from the family level to the product level by an instantiation process and on the contrary from the product level up to the family level by an abstraction process. In the two different process the main objects to pay attention on are variations.
We therefore aim at identifying needed extensions to express variability during requirements engineering.
Natural Language (NL) processing techniques, such as tho propod in [4] for evaluating requirement documents, can be fruitfully employed to this aim. Usually the techniques are ud to detect and then remove ambiguity and vagueness in a requirements document becau in traditional development process it is an undesirable side effect of the u of NL; in the context of Product Lines, on the contrary, we want to u them to identify automatically the necessary generic parts in order to speciali them into the specific product features (e the following examples):
Example 1
Req 34: the system shall simulate different vehicles
Different is a vague word, detected by the tools propod in [4]
In a family description different could be considered as pointing at a variability to be specialized in the derived products:
Req A.34: the system shall simulate cars
Req B.34: the system shall simulate trains
Example 2
Req 217: the system shall be such that the mission can be pursued, possibly without performance degradation
Possibly is a word indicating optionality .
In a family description possibly could be considered as pointing at an optionality differentiating among products:
Req A-217: the system shall be such that the mission can be pursued, without performance degradation Req B-217: the system shall be such that the mission can be pursued (performance degradation is admitted)
Notice that this is not the only interpretation of the optionality: the family requirement can be read also as imposing that any product will make its best effort to avoid performance degradation, if this is possible under adver conditions. Hence, this kind of linguistic analysis can be uful to point out potential variability.
4. Extensions of U Cas for Product Lines
When adopting U Cas description of requirements for Product Families, variations can be addresd in U Cas by adopting two complementary approaches:
1. Structuring the U Ca requirements as having two levels: the family level and the product level. In
this way product-related U Cas should be derived from the family-related U Cas by an instantiation process;
Domain Engineering
2. Incorporation of the application level U Cas into the domain level U Ca, in this way both the
product and the family level requirements will stand at the same level into the same, all inclusive, U Cas document.
4.1 Two levels U Cas
The solution for capturing variability we discuss in this ction is bad on the inclusion of tags into the scenarios (both main scenario and extensions) that identify and specify variations. The tags can be of three kinds: Optional, Alternative, Parametric.
When a product is derived from the family, the variable parts must be instantiated in different ways according to the type of variability:
1. Alternative components: they express the possibility to instantiate the requirement by lecting an
instance among a predefined t of possible choices, each of them depending on the occurrence of a condition;
2. Parametric components: their instantiation is connected to the actual value of a parameter in the
requirements for the specific product;鲍鱼最简单的做法
3. Optional components: their instantiation can be done by lecting indifferently among a t of values
which are optional features for a product instantiation.
The instantiation of the types of variability will lead to a t of different product-related instantiated U Cas. Figure 3 express this situation as a UML class diagram.
Figure 3. A UML model of two levels U Cas Document
Example 3. Primary Actor: the {[V0] 33-rie} mobile phone (the system) Goal: play a game on a {[V0] 33-rie} mobile phone and record score Main Success Scenario:
- The system displays the list of the {[V1] available} games
- The ur lect a game
- The system displays the logo of the lected game
- The ur lects the difficulty level by following the {[V2] appropriate}
procedure and press YES
- The system starts the game and plays it until it goes over
- The ur records the score achieved and {[V3] possibly} nd the score to Club
Nokia via WAP
- The system displays the list of the {[V1] available} games
- The ur press NO
V0: alternative
V0: 1. Nokia 3310 model
2. Nokia 3330 model
V1: optional
if V0=1 then game1 or game2
el if V0=2 then game1 or game2 or game3
V2: parametric
if V0=1 then procedure-A: - press Select
- scroll to Options and press YES
- scroll to Difficulty Level and press YES
-
lect the desired difficulty level, press YES
el if V0=2 then procedure-B: - press Select
- scroll to Level and press YES
- lect the desired difficulty level, press YES V3: parametric
if V0=1 then function not available
el if V0=2 then function available
4.2 One level U Cas
The cond way to manage variations in U Cas is to include all the alternatives that can occur when a product will be considered in each U Ca. In this way the canonical structure of the U Ca should be modified in order to be suitable to include all the particular features that the whole product family t of instances can have. Figure 4 shows, again by a UML class diagram, that each U Ca includes all the possible alternatives due to the specialization of the generic U Ca.
Figure 4. A UML model of one level U Cas Document
Example 4.
Primary Actor: The 3310 – 3330 mobile phone
Goal: play a game on a 3310 – 3330 mobile phone and record score
Preconditions: the function GAME has been lected from the main MENU
Main Success Scenario:
- 3310 model: The system displays game1 or game2
3330 model: The system displays game1 or game2 or game3
开学说说
- The ur lect a game
- The system displays the logo of the lected game
- The ur lects the difficulty level by following the procedure below: 3310 model: press Select
scroll to Level and press YES
lect the desired difficulty level and press YES 3330 model: press Select
scroll to Options and press YES
scroll to Difficulty Level and press YES
lect the desired difficulty level and press YES
-
The system starts the game and plays it until it goes over
- The ur records the score achieved
- 3330 model: nd the score to Club Nokia via WAP
- 3310 model: The system displays game1 or game2
3330 model: The system displays game1 or game2 or game3
- The ur press NO
4.3 Discussion手指游戏小班教案
The extensions prented in the previous ctions reflect different perspectives from which variability can be en. The first approach considers the variations implicitly enclod into the components of the U Cas. The variations are then reprented by tags that indicate tho parts of the family requirements needing to be instantiated for a specific product in a product-related document. On the contrary, the other extension explicitly includes all the possible variations into a unique, all inclusive, document.
The tagged extension, becau its dynamic structure, allows modifications to be faced more easily in terms of new functions or products in the product line. The flat, all inclusive approach is more static and, since it provides plenty of information at the same level.
By considering the nature of the two approaches, the flat reprentation of the u cas ems suitable for functionalities that are already mature and almost stable; while the tagged reprentation is more suitable when the functionalities related to the u ca are still in the way to be precily defined.
In reference to the CAFÉ-PRM reference framework, the considerations imply that the tagged extension is more uful during Application Engineering, in which variations are introduced on top of already existing products. During Domain Engineering the comprehensiveness of the flat extension allows to develop the general concept of a family.
The trade-offs between the two approaches have anyway to be better investigated. In fact, the two approaches may co-exist into the same U Ca document, where some parts may be expresd by using the tagged way and some other by using the flat way.
5. Conclusions and Future Works
In this paper we prented two possible ways to define extensions on the canonical U Ca structure in order to make them suitable to manage the variations of the product line requirements. The impact of the two approaches on the structure of the u cas and the conquent extensions to be made have been discusd in the paper.
The propod U Ca extensions em to be suitable to perform linguistic analysis to find ambiguity, inconsistency and incompleteness defects by means of automatic tools. Next work on this argument will deal on the application of existing linguistic techniques [3], [4] for evaluation and defects detection in u cas-bad product line requirements. Furthermore, we intend to explore the respective pros and cons of the two approaches in practice.
6. References
[1] A. Cockburn. Writing Effective U Cas, Addison-Wesley, 2000
[2] P. Clements, L.Northrop. Software Product Lines: Practice and Patterns, SEI Series in Software
月亮太阳
Engineering Addison Wesley, 2001.
[3] F.Fabbrini, M.Fusani, S.Gnesi, G.Lami. The Linguistic Approach to the Natural Language Require
ments
Quality: Benefits of the u of an Automatic Tool, 26th Annual IEEE Computer Society - NASA GSFC Software Engineering Workshop, Greenbelt, MA, November 27-29 2001.
[4] A.Fantechi, S.Gnesi, G.Lami, A.Maccari. Linguistic Techniques for U Cas Analysis, Proceedings of
the IEEE Joint International Requirements Engineering Conference - RE02. Esn, Germany, September
9 -13 2002.
[5] M. Jazayeri, A. Ran, F. van der Linden. Software Architecture for Product Families: Principles and
Practice, Publishers: Addison-Wesley, Reading, Mass. and London, 1998.
[6] F. van der Linden Software Product Families in Europe: The ESAPS & Café Projects, IEEE Software
July/August 2002
>无忧雅思
