Long-living software systems keep evolving to satisfy changes in their working environment. New requirements may arise, while current requirements may become obsoleted. Such requirements evolution fortunately could be foreseen at some level of (un)certainty. The paper presents UNICORN, a CASE tool for modeling and reasoning on the uncertainty of requirements evolution. The tool provides graphical constructs as well as di erent views of requirements evolution to assist users to model requirements evolution. The tool also supports the evolution analysis in which facilitate the selection of design alternative.
Long-living software systems keep evolving as they need to continue to satisfy changing business needs, new regulations and standards, and the introduction of new technologies. Some of future requirements may be known to be possible, but it is unknown whether they would actually be needed: the known unknown. The nal standardization of two competing alternatives is a simple example of such phenomenon. Unfortunately, a company who ship or buy software cannot wait until all unknowns become known. The process of tendering and organizational restructuring requires a signi cant amount of time and planning. Therefore, when having a number of possible design alternatives for the system-to-be, decision makers at high-level need to choose a viable design alternative that is evolution-resilient (i.e. minimize the risks that it cannot satisfy evolving requirements and thus needs replacement). Obviously, implementing a new design to replace for an obsoleted one may be more expensive than having a design that still be applicable when new requirements arise.
In this paper we present a CASE tool which aims to support an RE approach
to model and reason on requirements evolution (previously proposed in [
NoE-NESSOS
\alternative designs" for the future state [
This paper is organized as follows. In §2 we give an overview about the RE
approach [
Our approach [
The observable rule captures the way requirements evolve. Requirements
evolution might be either intentional (e.g., planned changes) or unintentional (e.g.,
changes dues to new business needs). Both may be uncertain because when
mentioning about future, \the only certainty is that nothing is certain"(Pliny the
Elder 1). Concretely, the unintentional evolution is uncertain because we do not
know whether it happens. The intentional evolution is planned, but it is still
not 100% for sure because some expected reasons might impact the future plan,
e.g., nancial issues, introduction of new standards. Therefore, intentional
evolution is also uncertain. The uncertainty of evolution is captured by the evolution
probability which is the belief that evolution might materialize in future. The
semantic of such belief could be accounted by using the game-theoretic approach
described in [
Let RM be the original requirements model, and RMi be one of the evolution possibilities that RM may evolve to. For sake of simplicity, all RMi are complete and mutual exclusive, i.e. one and only one RMi materializes. The observable rule (ro) is as follows.
( ro(RM) =
RM p!i RMi n X pi = 1 i=1 ) where pi is the evolution probability for which RM evolves to RMi; n is the number of all evolution possibilities of RM. The sum of all pi equals to one.
The controllable rule captures the way how requirements are satis ed. A requirements model usually have di erent design alternatives whose implementation will satisfy the requirements. This is described in a controllable rule. Let RM be a requirements model, and DAj be a design alternative (i.e. set of elements satisfying all mandatory requirements) of RM. The controllable rule (rc) is as follows.
rc(RM) = fRM ! DAj jj = 1::mg where m is the number of design alternatives of RM. Here we abuse the arrow notation (!) to express both observable and controllable rules. 1 Gaius Plinius Secundus (23 { 79), a Roman naturalist, and natural philosopher. (1) (2)
Our analysis on design alternatives relies on two quantitative metrics namely
Max Belief and Deferral Belief 2. The former indicates the maximum belief that
a design alternative will still be applicable when evolution happens. The latter is
the belief that a design alternative turns out to be not applicable when evolution
happens. The criterion to justify among design alternatives in terms of evolution
resilience is that: \Higher max belief, lower deferral belief". Interested readers
are referred to [
Features Overview
UNICORN is an Eclipse-based tool which aims to support the approach
described in [
The modeling support includes features necessary to model requirements
evolution. Important features in this category are as follows:
{ Support requirements evolution modeling. UNICORN provides several
constructs to capture evolution rules in a requirements model. Di erent
evolution possibilities and di erent design alternatives are supported. Evolution is
supported in di erent levels: from high level requirements to low level ones.
{ Support di erent views. Several views are supported to assist designers. In
particular, Normal View shows the complete requirements with evolution
rules; Evolution View presents only evolving parts of the model; and Original
View displays the requirements model without any evolution.
{ Support large model. A large requirements model can be partitioned into
several sub models. Sub models are edited in separated windows. Each model
can reference to other models. Changes in a model will be automatically
re ected to other models.
{ Support customization and extension. The graphical constructs of
UNICORN are highly customizable. Adding a new constructs with custom
gures and attributes, or modifying existing constructs can be done without
changing the UNICORN source code.
2 We rename the Residual Risk metric in [
In Fig. 1, the original requirements model RM has three requirements: RQ1, RQ-2, and RQ-3. RQ-1 is re ned to RQ-2 and RQ-3. Therefore, RM has one design alternative which is fRQ-2; RQ-3g. RM might evolve to a possibility RM1 in which RQ-4 is re ned to either RQ-5 or RQ-6. The evolution probability for this evolution is 0:6. Besides, RM might remain unchanged with the probability of 0:4. The observable and controllable rules captured by this gure are as follows. ro(RM) = nRM 0:!6 RM1; RM 0:!4 RM
o rc(RM) = fRM ! fRQ-2; RQ-3gg rc(RM1) = fRM1 ! fRQ-5g ; RM1 ! fRQ-6gg
The reasoning support provides an environment for developing automated analyses on requirements models. For example, the graphical models could be transformed into a data structure that facilitates the analysis. The traceability between the modeling constructs and transformed data structure is also maintained. Currently, we have implemented following analysis: { Evolution analysis : This analysis walks through the entire requirements models and calculate quantitative metrics (Max Belief, Deferral Belief ) for each design alternative. The analysis can incrementally update the metric values with respect to changes in the model as soon as the user changes the models. 3.2
Architectural Overview The tool architecture is specially designed to support a high level of customization and extension. Fig. 2 presents the overall architecture of the UNICORN tool. In this gure, components are depicted by rectangles. The headed-arrow connections denote the interaction between components where the source components invoke (or use) the target ones. These components are brie y described as follows: { The Universal Data Model is a common storage for the constructs of all models. Since graphical constructs could be de ned by users (e.g., add new
Custom GUI Figures Themes
...
Layouts GUI Service
Data Service Universal Data Model
Model Conversion Engine Incremental Converter Converter Tracer Language Registry Construct Definitions ModelConversion Rules
Reasoning Support
Custom Analysis EAvnoalluytsiiosn Visualizer Analysis 2nd Visualizer
...
Analysis nth Visualizer construct with custom attributes, or add new attributes to existing constructs), the Universal Data Model is a meta-meta model (see Fig. 3). { The Language Registry maintains de nitions of graphical constructs in requirements models, as well as conversion rules to transform the data model to other data structures used by analysis. The construct de nitions and conversion rules are de ned in con guration les which are fully customizable. { The Data Service uses the construct de nitions in the Language Registry to allow other components to manipulate the data stored in the data model. { The GUI Service is in charge of manipulating graphical objects and data model. It employs the Custom GUI components to create several GUI objects (e.g., construct gures, themes, and so on) consumed by the GUI Editor, which is a front-end graphical editor. { The Model Conversion Engine uses the conversion rules stored in the Language Registry to convert the requirements model to the underlying data structures used by the custom analysis. { The Custom Analysis is a set of analyses run on the editing requirements model. Each custom analysis has a Visualizer to show the analysis result. with a keyword language followed by an ID which is the language name and a set of elements. An element is either an entity or a relation. Each element has a set of attributes which has name, data type (optional), and initial value.
Fig. 5 exhibits an example where the requirement construct is de ned with respect to the grammar denoted in Fig. 4. The requirement construct is an entity whose graphical representation is a round rectangle with a label inside. The label is to show and edit the name and the description of this requirement. There is one text eld Actor in requirement. The initial value of this eld is a blank. 4
We demonstrate the features supported by our tool in a scenario taken from
an industrial project: the System Wide Information Management (SWIM) [
Table 1 reports the list of requirements, and their design alternatives. The table is divided into two parts: design alternatives on top, and requirements on bottom. The check mark (X) in the cross join of a design alternative and a requirement indicates that this design alternative satis es the corresponding requirement. Both design alternatives and requirements have unique identi ers, and short descriptions.
Modeling requirements evolution. Fig. 6 illustrates the requirements model with evolution rules of the scenario. The model says that the requirement RQ-0 is re ned to both RQ-1 and RQ-2. RQ-1 is later re ned to RQ-3, and so on. RQ-1 has an evolution rule where RQ-1 might remain unchanged with probability 0:4, or might evolve such that RQ-1 will be re ned, in a new way, into RQ-3, RQ-4, and RQ-5. The rest of the diagram can be read in the similar manner. Due to space limit, some screen shots (e.g., di erent views) are not provided. Interested readers are referred to the web site of the tool 3. 3 http://disi.unitn.it/~tran/pmwiki/pmwiki.php/Main/Unicorn
Reasoning on requirements evolution. Fig. 7 shows the evolution analysis on the requirements model of the scenario, in which the evolution metrics for each design alternative are calculated. The analysis result is shown in two tabs. The rst tab reports possible alternatives derived from the model and their corresponding evolution metrics. The second tab displays the DAT which is an internal structure stored at every node in the model to calculate the evolution metrics. Additionally, users can specify their own alternative, and have its evolution metrics calculated.
Any changes in the diagram will be automatically re ected in the analysis result. Since the analysis on requirements evolution is incremental, only changed nodes in the model are recalculated. This improves the overall performance of the tool.
We have presented UNICORN, a tool for modeling and reasoning on requirements evolution. By modeling support, UNICORN provides several customizable graphical constructs to model the requirements evolution. By reasoning support, UNICORN provides an environment where the graphical notation could be transformed to a data structure facilitating the analysis. UNICORN demonstrates this by implementing an analysis for requirements evolution.
As a part of future work, we will develop some plug-ins that allow our tool to read requirements models drawn by other tools (for example Si*4 models). These models could then be referenced in the evolution rules. 4 http://www.sistar.disi.unitn.it