Você está na página 1de 114

Incorporating Non-Functional Requirements

with UML Models

by

Subrina Anjum Tonu

A thesis

presented to the University of Waterloo

in fulfilment of the

thesis requirement for the degree of

Master of Applied Science

in

Electrical and Computer Engineering

Waterloo, Ontario, Canada, 2006

c
°Subrina Anjum Tonu 2006
I hereby declare that I am the sole author of this thesis.

I authorize the University of Waterloo to lend this thesis to other institutions or

individuals for the purpose of scholarly research.

Subrina Anjum Tonu

I further authorize the University of Waterloo to reproduce this thesis by photocopying

or by other means, in total or in part, at the request of other institutions or individuals

for the purpose of scholarly research.

Subrina Anjum Tonu

ii
The University of Waterloo requires the signatures of all persons using or photocopying

this thesis. Please sign below, and give address and date.

iii
Abstract

The way requirements should drive the rest of the software development process has

been a subject of many research projects in the past. Customers are demanding quality

software which can only be achieved by considering Non-Functional Requirements (NFR)

as early as possible. Since errors due to NFRs are the most expensive and difficult to

correct, improperly dealing with NFRs can lead to more expensive software and a longer

time to the market. If the NFRs are not considered at the early stage of the software

development process, it may be difficult and expensive to address them in final product.

Despite this, a common industrial practice is to specify only Functional Requirements

at the design phase and the NFRs at the implementation phase. As a result, the design

of a software system may not reflect the NFRs properly and may lead to a failed product.

This research work tries to fill this gap in software development by proposing a unified

modeling framework that addresses both Functional and Non-Functional Requirements.

The proposed framework aims at incorporating the NFRs into the conceptual models.

This integration can be used in the early stages of software development with ongoing

projects or to enhance even legacy systems with NFRs. We rely on the NFR Framework

to propose a solution, while defining a High Level Language for mapping that solution to

the corresponding UML (Unified Modeling Language) diagrams. The proposed approach

uses standard XMI representation of UML models without proposing any extension to it.

We validate our approach by performing two case studies.

iv
Acknowledgments

I would like to thank my excellent supervisor Professor Ladan Tahvildari for her guidance

and co-operation throughout my research. Her spontaneous encouragement has been a

driving force for me. She is more than a supervisor to me.

Special thanks goes to Professor Gordon B. Agnew and Professor Kostas Kontogiannis

for their valuable time spent to read the thesis.

I would like to thank all the member of Software Technologies and Applied Research

(STAR) Group for their valuable feedback about my thesis. I feel really lucky to have

such friends in my life.

I would also like to thank my parents and my sister. Their encouragement and best

wishes made every step of my life easier.

Lastly, I express my gratitude to my beloved husband for his inspiration and moral

support.

v
Contents

1 Introduction 1

1.1 Problem Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.3 Thesis Contribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.4 Outline of the Thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2 Related Works 9

2.1 Integrating Non-Functional Requirements in Forward Engineering . . . . . 9

2.1.1 NFR-Based Forward Engineering . . . . . . . . . . . . . . . . . . . 10

2.1.2 Aspect-Based Forward Engineering . . . . . . . . . . . . . . . . . . 15

2.2 Non-Functional Requirements in Reverse Engineering . . . . . . . . . . . 20

2.3 A Comparison among Different Approaches . . . . . . . . . . . . . . . . . 21

2.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3 A Unified Modeling Framework 24

3.1 The Unified Modeling Framework . . . . . . . . . . . . . . . . . . . . . . 26

3.1.1 Identifying Requirements . . . . . . . . . . . . . . . . . . . . . . . 27

3.1.2 Modeling Requirements . . . . . . . . . . . . . . . . . . . . . . . . 28

3.1.3 Integrating Requirements . . . . . . . . . . . . . . . . . . . . . . . 30

vi
3.2 Architecture of the Framework . . . . . . . . . . . . . . . . . . . . . . . . 33

3.3 UML Model Without Extension . . . . . . . . . . . . . . . . . . . . . . . . 34

3.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4 A Formal Language for Modeling NFRs 36

4.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.2 Primitive Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.2.1 Specialized Primitive Operations . . . . . . . . . . . . . . . . . . . 41

4.2.2 Non-Specialized Primitive Operations . . . . . . . . . . . . . . . . 43

4.3 Supportive Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4.3.1 Description of the Supportive Operations . . . . . . . . . . . . . . 45

4.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

5 Implementation Architecture 48

5.1 Detailed Process of the Prototype . . . . . . . . . . . . . . . . . . . . . . . 49

5.2 Major Components of the Prototype . . . . . . . . . . . . . . . . . . . . . 51

5.2.1 Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

5.2.2 Loader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

5.2.3 Model Serializer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

5.2.4 NFR Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

5.2.5 Visualization Engine . . . . . . . . . . . . . . . . . . . . . . . . . . 61

5.3 Implementation Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

5.3.1 Dynamic Class Loading . . . . . . . . . . . . . . . . . . . . . . . . 62

5.3.2 Java Component . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

5.4 Evaluation of the Prototype . . . . . . . . . . . . . . . . . . . . . . . . . . 63

5.4.1 DOM Time and Space Complexity . . . . . . . . . . . . . . . . . . 63

5.4.2 Input Time and Space Complexity . . . . . . . . . . . . . . . . . . 64

vii
5.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

6 Case Study 66

6.1 Identifying Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

6.2 Modeling FRs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

6.3 Modeling NFR: Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

6.3.1 Overview of Security Softgoal Graph . . . . . . . . . . . . . . . . . 71

6.3.2 Evaluated SIG for Security from NFR Framework . . . . . . . . . 73

6.3.3 A Unified Model for NFR Internal Security . . . . . . . . . . . . . 74

6.3.4 NFR Template for NFR Security . . . . . . . . . . . . . . . . . . . 75

6.3.5 Integration of NFR Security . . . . . . . . . . . . . . . . . . . . . . 77

6.4 Modeling NFR: Performance . . . . . . . . . . . . . . . . . . . . . . . . . 80

6.4.1 Overview of Performance Softgoal Graph . . . . . . . . . . . . . . 80

6.4.2 A Unified Model for Achieving FastResponseTime . . . . . . . . . 83

6.4.3 NFR Template for FastResponseTime . . . . . . . . . . . . . . . . 85

6.4.4 Integration of NFR Performance(FastResponseTime) . . . . . . . . 86

6.5 Time Complexity to Integrate NFRs in our Prototype . . . . . . . . . . . 88

6.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

7 Conclusion and Future Direction 90

7.1 Critical Review of the Thesis . . . . . . . . . . . . . . . . . . . . . . . . . 91

7.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

7.2.1 Building Reusable Aspects . . . . . . . . . . . . . . . . . . . . . . 92

7.2.2 Building Reusable Functional Requirements . . . . . . . . . . . . 93

7.2.3 Specifying Design Patterns at Design Level . . . . . . . . . . . . . 93

7.2.4 Building Components in Component Based Software Engineering

(CBSE) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

viii
7.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

Bibliography 95

ix
List of Figures

2.1 A Soft-Goal Interdependency graph . . . . . . . . . . . . . . . . . . . . . 11

2.2 NFR Association Points in Use-Case Diagram . . . . . . . . . . . . . . . 12

2.3 Conceptual Design Model with One Architecture . . . . . . . . . . . . . . 15

2.4 Notation of the Aspect and Aspect-Class Relationship . . . . . . . . . . . 17

2.5 Specifying Binding for Composition . . . . . . . . . . . . . . . . . . . . . . 18

2.6 The Aspect-Oriented Requirements Engineering Model . . . . . . . . . . 19

2.7 The Block Diagram of the Quality-Based Re-engineering Process. . . . . . 21

3.1 The Architecture of the Framework . . . . . . . . . . . . . . . . . . . . . . 26

5.1 Architecture of the Prototype . . . . . . . . . . . . . . . . . . . . . . . . . 51

5.2 The Snapshot of Parsed DOM Tree From XML Schema of UML Model . 54

5.3 The screenshot of Input Model . . . . . . . . . . . . . . . . . . . . . . . . 55

5.4 The Snapshot of the NFR Template Builder . . . . . . . . . . . . . . . . . 59

5.5 The Snapshot of the NFR Editor . . . . . . . . . . . . . . . . . . . . . . . 60

5.6 The Snapshot of A Model with A NFR Attached to it . . . . . . . . . . . 61

5.7 Graph of Parsing Time of Several Input Models . . . . . . . . . . . . . . . 64

6.1 A Partial Class and Activity Diagram for the Case Study System . . . . . 68

6.2 A Partial SoftGoal Interdependency Graph for Security Quality Attribute 71

x
6.3 A Catalogue of Security Operationalization Methods . . . . . . . . . . . . 72

6.4 SIG for a Confidential Account . . . . . . . . . . . . . . . . . . . . . . . . 74

6.5 Add NFR Security Algorithm. . . . . . . . . . . . . . . . . . . . . . . . . 76

6.6 NFR Template for Achieving Internal Security . . . . . . . . . . . . . . . 78

6.7 UML Diagrams After Weaving Internal Security . . . . . . . . . . . . . . 79

6.8 A SoftGoal Interdependency Graph for Performance Quality Attribute . . 81

6.9 A SIG Performance for Credit Card System . . . . . . . . . . . . . . . . . 82

6.10 Add NFR FastResponseTime Algorithm. . . . . . . . . . . . . . . . . . . . 84

6.11 NFR Template for FastResponseTime . . . . . . . . . . . . . . . . . . . . 85

6.12 UML Diagrams after weaving FastResponseTime . . . . . . . . . . . . . . 87

xi
List of Tables

2.1 A Comparison Among Several Related Research Works . . . . . . . . . . 22

4.1 A List of Primitive Operations . . . . . . . . . . . . . . . . . . . . . . . . 40

4.2 A List of Supportive Operations . . . . . . . . . . . . . . . . . . . . . . . 47

5.1 Time and Space Complexity for Generating DOM Tree . . . . . . . . . . . 63

5.2 Time and Space Complexity for Interpreting Input Models . . . . . . . . . 64

6.1 Time Complexity for Integrating NFRs . . . . . . . . . . . . . . . . . . . 88

xii
Chapter 1

Introduction

The core of a successful product is the clear understanding its requirements [25, 26, 40, 59].

Such requirements should be solicited early and reflected throughout the life cycle of the

development process of the product.

Non-Functional Requirements (NFR), along with Functional Requirements (FR) play

a significant role in software development. If the NFRs are not considered at the early

stage of software development, it may be very difficult and expensive to address them in

final product. Some cases, redesign of the system may be required [38].

IEEE defines Non-Functional Requirements as:

Non Functional Requirement in software system engineering is a software re-

quirement that describes not what the software will do, but how the software

will do it, for example, software performance requirements, software exter-

nal interface requirements, design constraints, and software quality attributes.

Non Functional Requirements are difficult to test; therefore, they are usually

evaluated subjectively.

Because of their subjective nature, NFRs are often achieved not in an absolute sense,

1
CHAPTER 1. INTRODUCTION 2

but a sufficient or satisfactory extent. Sometimes it becomes difficult to specify the

NFRs in the implementation level if they are not considered in the design level of a

software system. NFRs have some conflicting impact over several modules of the system.

For example, some techniques for achieving NFRs (such as, uncompressed format of file

organization) may have a positive impact on time performance. However, they may have

a negative impact on space performance.

To reflect the FRs and NFRs properly, a solid architectural foundation is needed.

Modeling is the best way to achieve such a goal. Modeling is like developing the blueprints;

it helps to capture various structural and behavioral aspects of the system. It not only

gives the developers a template that guides them in constructing the system, but it also

documents the decisions that are made during software development [14]. In the object-

oriented paradigm, OMG (Object Management Group) has specified Unified Modeling

Language (UML) which is the most popular language for modeling purposes [6]. Using

UML tools can help to automatically generate code from model specifications.

In this context, we have built a unified modeling framework that aims at incorporating

the NFRs into the UML representation of a software system. The framework proposes a

novel process:

• To systematically design reusable NFRs.

• To add them with the FRs of a system in the design phase.

This research work is noteworthy for two reasons. First, it addresses a problem that

challenge the research community for several years, namely to design NFRs systematically

and to build reusable NFRs. Second, it devises a framework which can be used both in

forward engineering with ongoing projects and in reverse engineering to enhance Non-

Functional Requirements of a legacy system while preserving its behavior.


CHAPTER 1. INTRODUCTION 3

1.1 Problem Description

Over the past few years, the subject of many research projects is to determine how require-

ments should drive the rest of the software development process. Researchers proposed

several frameworks and requirements specification languages to express requirements at

the early stage of the software life cycle [13, 15, 18, 25, 26, 28, 29].

Customers are demanding quality software which can only be achieved by considering

NFRs as early as possible. Since errors due to NFRs are the most expensive and difficult to

correct, improperly dealing with NFRs can lead to more expensive software and a longer

time to the market. Spite of this importance, in most cases a common industrial practice

is to specify only FRs at the design phase, and to add NFRs at the implementation phase

of a software system. As a result, the design of a software system does not reflect the

NFRs properly, which may lead to a failed product.

It is not trivial to verify whether a specific NFR is satisfied by the final product

or not [18]. Very often NFRs conflict with each other (for example, in space and time

performance). They are usually very abstract and stated only informally; rarely supported

by tools, methodologies or languages. In some cases, developers specify some fundamental

NFRs at the design level, but in most cases the joint-points (where the NFRs touch the

target model) of such NFRs are defined as a part of the NFR design itself [33]. In this way,

the NFRs become a hard-coded design with some pre-defined and fixed parameters. As a

result, the NFRs can not be reused. However, the NFRs from the same domain may have

common features so that the same design can be used with some variation of parameter

values for different systems. This can help to save design time. In such a restricted

environment, it is necessary to have a comprehensive framework to systematically add

NFRs with the FRs at the design level and to have a mechanism to reuse NFRs, rather

than designing them from scratch.


CHAPTER 1. INTRODUCTION 4

1.2 Motivation

To reflect the NFRs properly in the implementation of a software system, it is necessary

to specify them at design level. Modeling helps the developers to work in a higher level

of abstraction by hiding the details. The model representation of a system provides a

high-level view, where the developers can focus on different aspects of a software sys-

tem. We use UML models to represent FRs and NFRs of the system because UML has

emerged as the industry standard for software modelling notations. Various diagrams

are available in UML models, and using several types of diagrams, several views of a

system can be captured. Another major advantage of using UML is that many UML

tools are available in the market. According to the OMG [4], some UML tools can an-

alyze source code and some even can reverse engineer it to UML diagrams. Some tools

can execute the UML model interpretively in such a way that it works as a prototype

which confirms stakeholder product expectations. However, the execution is without the

scalability and speed that stakeholders need in their deployed application. Other tools,

which are typically designed to work only within a restricted application domain such

as telecommunications or finance, can generate program-language code from UML and

can produce a mostly bug-free, deployable application. This application runs quickly

if the code generator can incorporate best-practice scalable patterns, e.g., transactional

database operations or other common program tasks. In such an environment, UML can

be a very efficient way to express the big picture of a model by specifying the Functional

and Non-Functional Requirements properly.

We use NFR Framework to achieve a solution for a particular Non-Functional Require-

ment [18]. The NFR Framework provides a detailed process for refining a Non-Functional

Requirements from a very high-level abstraction to a design-level decision. This refine-

ment is done through an AND/OR graph where the leaf nodes represent the design
CHAPTER 1. INTRODUCTION 5

decisions which need to be implemented for achieving a particular NFR. Any ancestor

node can be fulfilled by satisfying any of the descendant nodes for an “OR” relation, or

all of the descendant nodes for an “AND” relation. For the UML representation of the

solution of the NFR Framework, our research work also proposes a High Level Language.

The motivation behind the language is to design NFRs in a reusable manner.

In a typical UML tool, users need to specify all the necessary parameters for a par-

ticular diagram during design time creating a UML diagram, . In this way, any UML

diagram created in a visual tool becomes a hard-coded design with a set of fixed parame-

ters. Our language removes this obstacle by providing a textual format of the instructions

for designing any UML diagram. The language aims to create/delete the UML entities

and to find the ancestor/descendant for a given entity. The instructions provided in our

proposed language for creating any UML diagram can build a template of a UML diagram

where the necessary parameters are taken during runtime. The actual UML representa-

tion is created after dynamically specifying those parameters needed to build for a UML

model. As the parameters of a UML diagram are not a part of the template for that

UML diagram, the same template can be used with the variation of the parameters in

another design.

Our framework is based on a knowledge-based concepts where we maintain a Li-

brary/Repository of reusable NFRs templates. For tool compatibility, we use standard

XMI of UML model.

1.3 Thesis Contribution

The contributions of the framework proposed in this thesis are two fold: i) it addresses

the problem of building a high-quality object-oriented software by proper elicitation of

its Non-Functional Requirements and ii) it addresses the problem of re-engineering an


CHAPTER 1. INTRODUCTION 6

object-oriented legacy system. Specifically, the major contributions of the framework

proposed in this thesis are as follows:

• The framework does a mapping from an Operationalizing softgoal of NFR Frame-

work to a development technique in the target model, expressed in standard UML

notation [18]. NFR Framework has categorized Non-Functional Requirements as

“Softgoals”: subjective and achievable only in part. The Operationalizing softgoals

of NFR Framework represent the development techniques that can be implemented

in the target model. As a result, Operationalizing softgoals can be expressed as

Functional Requirements or specifications. Functional requirements or specifica-

tions in turn can be represented in standard UML notation. These Operationalizing

softgoals can be represented as development techniques in standard UML notations,

as well.

• The framework proposes a High Level Language to model NFRs with standard

UML notation. Details of the language are elaborated further in Chapter 4. In

addition to NFR modeling, we also focus on the reusability of the specified NFRs

by dynamically instantiating the necessary input parameters and join-points of the

NFRs with the target model.

• The framework does not propose any extension to UML model. Most other research

works extend to UML models, introducing some new notation to represent and

identify NFRs. Unless OMG adopts these special notations, other tools can not

interpret the output of those frameworks. We specify the NFRs with the standard

UML model, which is one of the novelty of our framework.

• The framework adds the NFRs as a standard “ADD” component of the XMI to

UML model for representing them as a unit and separating them from the main
CHAPTER 1. INTRODUCTION 7

design. As a result, any modification of the NFRs will not affect the main design.

The “ADD” component is an advantage of XMI, where it can differentiate the added

components from main components. In this way addition, modification, and even

deletion of these added components do not effect the main design.

• The framework can be applied both in forward and re-engineering perspectives.

Most of the research work focus is on specifying NFRs in forward engineering pro-

cess. Some are capable adding NFRs during re-engineering of legacy systems [54].

Our work is a complete one in the sense that it includes on both engineering pro-

cesses, rather than focusing on a particular one.

1.4 Outline of the Thesis

The rest of the thesis is organized as follows:

• Chapter 2 presents a survey on the related research works. It covers two research

fields, namely: i) Non-Functional Requirements during forward engineering, and ii)

Non-Functional Requirements during reverse engineering.

• Chapter 3 proposes a unified modeling framework to integrate Non-Functional Re-

quirements with the model of a software system. The framework uses UML model

to represent a software system. It also describes an approach where the framework

can be used to add NFRs to a software system during both forward engineering and

reverse engineering of it.

• Chapter 4 proposes a High Level Language for specifying the NFRs in UML dia-

grams. The proposed language also specifies the NFRs as a re-usable component.

• Chapter 5 presents the prototype implementation of the proposed framework. The


CHAPTER 1. INTRODUCTION 8

chapter also presents the implementation architecture in terms of the major com-

ponents, and the detailed steps of the process of applying the framework on the

case studies.

• Chapter 6 shows the implementation of the framework on some case studies. The

performance, and security of a credit card system are presented as a proof of concept.

• Finally, Chapter 7 presents the conclusions, and discusses the future research direc-

tions.
Chapter 2

Related Works

This chapter covers Non-Functional Requirements in forward engineering and Non-Functional

Requirements in reverse engineering. The section on Non-Functional Requirements in

forward engineering discusses approaches to specify NFRs during software development

and to add them in design phase of a software system. The section on Non-Functional

Requirements in reverse engineering discusses approaches to specify NFRs during the

re-engineering of a legacy system while adding them to the extracted representation of

the source code.

2.1 Integrating Non-Functional Requirements in Forward

Engineering

The idea of integrating NFRs with FRs at design level is not a new one. A survey of

the approaches found that most of the research works use the UML model to represent a

system and these works propose some extensions in order to add NFRs during the design

phase with the model representation of the FRs. Also, there are some research works that

interpret quality attributes (NFRs) of a system as “aspect”. Aspect is the cross-cutting

9
CHAPTER 2. RELATED WORKS 10

behavior of the system which has the similar nature as NFRs as NFRs also crosscut

the system globally. In this context, we classified the research works related to Non-

Functional Requirements in Forward Engineering as: i) NFR-Based Forward Engineering,

and ii) Aspect-Based Forward Engineering.

2.1.1 NFR-Based Forward Engineering

Chung proposed the NFR framework [20] which was discussed in [18]. The framework

represents information about different software qualities and their interdependencies. The

NFR framework starts with an initial set of high-level Non-Functional Requirements as

NFR softgoals, along with an initial set of functional requirements. The NFR softgoals

are refined into more specific ones iteratively while establishing interdependencies. These

include relationships among softgoals, and relationships between softgoals and interde-

pendencies. Along with these, priorities are identified, operationalizations are considered,

tradeoffs are made and design rationale is provided. The visualization of the operations

of the framework is done in terms of the incremental and interactive construction, elab-

oration, analysis, and revision of a Softgoal interdependency graph (SIG).

Figure 2.1 shows a Softgoal interdependency graph (SIG) for achieving NFRs: i) good

performance, ii) security, and iii) user-friendliness of an account. In this Figure, the

single arc represents an AND relation and the double arc represents an OR relation.

The NFR softgoals represent the high level NFR goal that needs to be achieved. The

Op (Operationalization) softgoals represent the development techniques which need to

be implemented in the final system to achieve the NFR softgoals. The Claim softgoals

represent the design rational for choosing any particular design technique. The NFR

softgoals need to be clarified and prioritized by decomposing them to more specific ones.

The decomposition can be related either by an AND relation or by an OR relation.

For example, in Figure 2.1, to achieve “good performance”, both “space” and “time
CHAPTER 2. RELATED WORKS 11

User−friendly Legend
Secure
Good Performance access to accounts
accounts
for accounts NFR softgoal

Op softgoal

Confidentiality Claim softgoal


Intigrity of account
of accounts Availability Contribution Link
+ of accounts
Response Satisfied
Space for
accounts time for Authoroze X Denied
accounts Accurate access to account
+ accounts information − + Positive Contribution
+ Complete − negative Contribution
− accounts + Authenticate
user access
Claim
Use indexing !Accurate "Accuracy
Use uncompressed accounts
is vital"
format +

Identity
users
X

Use P.I.N Compare Required


Signature aditional
Claim ID
"Optimized validation
will not hurt response time
much"
Validate access
against eligibility rules

Figure 2.1: A Soft-Goal Interdependency graph

performance” need to be satisfied. However, to achieve “access authorization” to an

account, any of the “Use P.I.N”, “Compare Signature” and “Required Additional ID”

techniques can be used. Again a particular design decision may have a positive or negative

impact towards it’s ancestors. For example, if the “Use Uncompressed Format” is chosen

as the development technique, it will have a positive impact on time performance, but

have a negative impact on the space performance. Any design decision is evaluated by

considering the positive and negative impacts towards the ancestors. In this way the

NFR Framework provides a detailed process to achieve a solution for a particular Non-

Functional Requirement.

Supakkul et al. propose a use case and goal-driven approach to integrate FRs and

NFRs in [51]. They use the UML use case model to capture functionality of the system

and they also use the NFR Framework [18] to represent NFRs. They propose to associate

the NFRs with four use case model elements: actor, use case, actor-use case association

and the system boundary . They name these associations “Actor Association Point”,
CHAPTER 2. RELATED WORKS 12

“Use Case Association Point”, “Actor-Use Case Association (AU-A) Point”, and “System

Boundary Association Point” respectively. Having such an extension to the UML use

case model, NFRs can be integrated at the design level with FRs and can provide better

understanding of the requirements model. Figure 2.2 shows the proposed NFR association

points in the UML use case model. In Figure 2.2, cloud A represents the NFRs related

to an actor of use case model. These NFRs are related to actor by “Actor Association

Point”. Cloud B represents the NFRs related to use case of use case model. These NFRs

are related to use case by “Use Case Association Point”. Cloud C represents the NFRs

related to actor-use case association of use case model. These NFRs are related to this

association by “Actor-Use Case Association (AU-A) Point”. Finally, cloud D represents

the NFRs related to system boundary of use case model. These NFRs are related to this

boundary by “System Boundary Association Point”. These four NFRs association points

are their proposed extensions to UML use case model.


System Boundary
D
System, C
development, or Access,
software process communication, or
exchanged info
related NFRs related NFRs
B

Functional
requirements
related NFRs
Enternal
entity related
A NFRs

Use Case
Actor

Figure 2.2: NFR Association Points in Use-Case Diagram

Later in [52], Supakkul et al. propose an integrating modelling language by extending

UML with the NFR Framework using the standard extension mechanism called UML

Profile. They define a metamodel to represent the concepts in the NFR Framework and
CHAPTER 2. RELATED WORKS 13

they identify the extension points for integrating the two notations.

Moreira et al. propose a model for integrating crosscutting quality attributes with

FRs by the UML use case diagram and interaction diagram [39]. They adopt NFR

Framework’s goal analysis Framework (without visual notations and diagrams) to analyze

NFRs textually for cross-cutting relevance to one or more use cases. They propose a

template for quality attributes with specific fields, including description, focus, source,

decomposition, priority, obligation, and influence. Then, they integrate those quality

attributes with FRs using standard UML diagrammatic representations (e.g. use case

diagram, interaction diagrams) extended with some special notations.

Cysneiros et al. also propose a systematic approach to assure that conceptual models

will reflect the NFRs elicited [25, 26]. According to them, the software development

process is carried out through two independent cycles, one focusing the functional aspects

of the system and the other on the non-functional aspects of the system. They also

define a convergence point between the functional view and non-functional view where

the functional view includes some of the artifacts commonly used in software development

(such as use case diagram, class diagram, sequence diagram and collaboration diagram)

and the non-functional view includes the NFR framework [18].

Cysneiros et al. use the Language Extended Lexicon (LEL) driven approach to de-

scribe the application domain in LEL to provide context for both FRs and NFRs. This

policy assures that a common and controlled vocabulary will be used in both functional

and nonfunctional representations. Later they analyze those domains separately and

build the functional view of the system using UML diagrams. Then they build the non-

functional view of the system using NFR framework. They extend the NFR framework to

adopt their notations. Finally, they integrate the NFRs with the functional representation

of the system by proposing some extensions to UML models.

Dimitrov et al. describe three approaches for UML-based performance engineering [27].
CHAPTER 2. RELATED WORKS 14

The three approaches are: 1) Direct representation of performance aspects using UML, 2)

Expanding UML to deal with performance aspects and 3) Combining UML with formal

description techniques.

In the first approach, they propose some methods for specifying performance aspects

with some of the UML models with standard UML notations. For the use case model,

they define a load- and time-weighted use case diagram for specifying performance aspects

with the standard UML notations. For the interaction diagram, they propose to add some

additional time information by labelling the messages with relative constraints such as

assigning time attributes to the messages and to the method executions. According to this

approach the labelling of messages with time will be interpreted as latency and labelling of

methods with time will be interpreted as time for method execution. For state transition

diagram, they proposed to assign a thinking time along with the probability assigned to

each transition.

In the second approach, they expand the UML for supporting Real-time Object-

Oriented Modeling methods for supporting performance aspect. They use UML tailoring

mechanism which are based on stereotypes, tagged values, and constraints to convert the

Real-time Object-Oriented Modeling constructs to UML.

In the third approach they combine UML with Message Sequence Charts (MSC) and

SDL type formal description techniques to support performance of a software system.

Berenbach proposes a homogenous UML use case model to connect usecases, func-

tional and non-functional requirements all together [11]. He proposes some new notations

to UML model to express functional requirements, non-functional requirements and the

risks (hazard) involved with the use case diagram of the UML model.

Xu et al. propose a conceptual architectural design model, where traditional archi-

tecture model of a software program represents one layer and the NFRs are presented

as aspectual components in another layer [58]. Figure 2.3 shows their conceptual design
CHAPTER 2. RELATED WORKS 15

Aspectual Aspectual Aspectual


Component Component Component

NFR1 NFR2 NFR3

NFR Layer

XML Binder 1 XML Binder 2 XML Binder 3

Architecture Layer

Figure 2.3: Conceptual Design Model with One Architecture

model to add NFRs. They propose to use the aspectual components to represent the

semantics of the operationalized NFRs. These components correspond to advice tasks

in the aspect-oriented world. The connectors between the software architecture layer

and the NFR layer describe binding rules, thus corresponding to the pointcut from the

aspectual component to the normal components. They also define a connector, namely

XML Binder, to bind the NFRs to the target model. They propose to use the same

XML Binders in the Aspect Markup Language (AML). Their XML Binders are there-

fore XML-based binding specifications that provide weaving instructions to determine

how aspectual components and the traditional software architecture are to be composed

together.

2.1.2 Aspect-Based Forward Engineering

Recently, Aspect-Oriented Programming (AOP) has been offered as a promising abstrac-

tion principle to reduce the problem of code tangling and making software structure clean

and configurable. Some research works used the concept of AOP for the quality attributes

of a software system. The major advantage of AOP is that the “Aspects” can be imple-
CHAPTER 2. RELATED WORKS 16

mented by AspectJ [2] in java. AspectJ is a very well established approach to implement

AOP by providing a special unit called “aspect” which encapsulates cross-cutting code.

But for implementing those aspects, it is necessary to specify them in the design phase.

Here some modelling language can be used for the design purpose. Some researchers have

proposed some approaches to show how the design of AspectJ programs can be expressed

by using UML model.

Suzuki et al. propose some extension of the UML metamodel [53]. They propose to

add “aspect” as a new component in the UML model as an extension to it. A classifier

element describes behavioral and structural features. Class, Interface and Component

are examples of classifier elements. According to Suzuki et al. aspect is a construct

derived from Classifier element. So, like other classifier elements, “aspect” can have

attributes, operations and relationships. Here, attributes of an aspect are used by its

set of weave definition, operations of an aspect are considered as its weave declarations,

and relationships of an aspect include generalization, association and dependency. If

the aspect weaver introduces and advices weaves in AspectJ [2], they specify it as an

constraint for the corresponding weave (operation) declaration. They express an aspect

as a class rectangle with stereotype “hhaspectii” as shown in Figure 2.4. The operation list

compartment of the rectangle represents the list of weave declarations. Then they define

the aspect-class relationship as the abstraction dependency with stereotype realization,

“hhrealizeii”. Finally, they merge the aspect and class code by aspect weaver and generate

woven class structure. They also propose a XML-based aspect definition language format

named “UXF/a” to express aspect information.

Clarke et al. propose to implement an aspect as a “composition pattern” [24]. A

composition pattern is a design model that specifies the design of a cross-cutting re-

quirement independently from any design it may potentially cross-cut, and it defines how

that design may be re-used wherever it may be required. For expressing the composition
CHAPTER 2. RELATED WORKS 17

<<aspect>>
SubjectObserverProtocol

−Subject.observers :Vector=new Vector()


−Observer.subject: Subject=null

+Subject.attach(obs : Observer): void


+Subject.detach(obs: Observer): void
+Subject.getData(): Object
+Observer.update(): void

<<realize>> <<realize>>

<<interface>> <<interface>>
Subject Observer

+update(): void
+attach(): void
+detach(): void
+getData(): Object

Figure 2.4: Notation of the Aspect and Aspect-Class Relationship

pattern they use the convention of UML’s defined template as a parameterized model

element. They specify the cross-cutting behavior of the system by an interaction dia-

gram of the UML model within the composition pattern model. So, where there is a

cross-cutting behavior in the system, this can be specified by their composition pattern.

However, this kind of template can not be used directly in the design model. For this

purpose, they use the “Binding” dependency relationship to specify it with the design

model. UML restricts binding to template parameters for instantiation as one-to-one.

They propose an extension of the standard UML “Binding” relationship bind [ ] attach-

ment that defines the (potentially multiple) elements that replace the templates within

the composition pattern. Figure 2.5 shows how the composition is specified by binding.

Here, “<<Subject>> Trace” is the parameterized template for the composition pattern

to specify a cross-cutting behavior and bind is the proposed extended multiple depen-

dency relationship of UML which has been used to specify the composition pattern with

the main design model “<<Subject>>”.


CHAPTER 2. RELATED WORKS 18

<<subject>>
<<subject>>
S1
Trace
<TracedClass,_tracedOp(..)> X

+foo()

Proposed Bind[] relation

Figure 2.5: Specifying Binding for Composition

Rashid et al. propose an Aspect-Oriented Requirements Engineering model to support

the separation of crosscutting functional and non-functional properties at the require-

ments level in [47]. Their proposed model is composed of six activities, namely:

• Identifying concerns by analyzing the initial requirements.

• Specifying the concerns in terms of requirements.

• Discovering viewpoints and relating them to corresponding concerns.

• Identifying candidate aspects by analyzing whether a concern may influence or

constrain more than one viewpoint.

• Specifying and prioritizing aspects by refining aspects, making them more concrete

and identifying interactions and conflicts between them.

• Specifying aspect dimensions.

Figure 2.6 shows the proposed Aspect-Oriented Requirements Engineering model.

Here, rectangles A, B, C, D, E, and F represents the above activities respectively.

Later Rashid et al. presented their AORE model in the context of the UML model

in [10]. This research work manipulates the separation of cross-cutting concerns at the

requirement level using UML. They partitioned their approach vertically in three main

parts, namely:
CHAPTER 2. RELATED WORKS 19

Identify Identify Viewpoints,


A discover requirements C
Concerns
and relate to concerns

B Specify
Concerns

Identify E Specify Specify F


D candidate and aspect
aspects prioritise dimentions
aspects

Figure 2.6: The Aspect-Oriented Requirements Engineering Model

• Crosscutting Concerns: These handle the non-functional requirements and iden-

tify which of them are crosscutting (candidate aspects). Then they specify those

candidate concerns using a template description with such parameters as: name

of the concern, description of the concern, priority level of that concern, list of

requirements for the concern and list of appropriate UML models for the concern.

• Functional Concerns: These handle the specification of functional requirements

using a UML-like approach. They use the UML use-case model as the main speci-

fication technique for this part.

• Composed Requirements: These handle both functional requirements and non-

functional aspects. To build the composed requirements they use the concept de-

scribed in [3, 9, 12, 24].

Finally, Rashid et al. apply their approach in a case study which is a simplified version

of the real system implemented in the Portuguese motorways network [23]

Ho et al. propose an extendible UML transformation Framework called UMLAUT

to generate detailed design models from high level, aspect-oriented UML models [32,

31, 33]. They propose to organize non-functional and cross-cutting behavior in UML
CHAPTER 2. RELATED WORKS 20

model around the central notions of quality of service contracts (for specifying non-

functional properties) and aspects. They describe how these contracts and aspects can be

implemented. They propose to model contracts in UML with a small set of stereotypes.

They also propose to represent contracts using parameterized collaborations equipped

with transformation rules expressed with meta-level OCL2. They implement a design

level aspect weaver(UMLAUT) which is actually a meta-level OCL2 interpreter.

2.2 Non-Functional Requirements in Reverse Engineering

The production of a highly organized software system requires the separation of con-

cerns [30]. This is one of the basic engineering principles. On the other hand, production

of a high quality software requires the implementation of all functional and non-functional

requirements starting from the design phase to the end of the software life cycle.

All these requirements are changing during the maintenance phase of any software

system. The re-engineering of such software systems have gained significant attention in

today’s software industry. A few research works provide a re-engineering process which

addresses such problems in order to incorporate any new or modified Non-Functional

Requirements. Existing reverse engineering processes can extract the architectural design

of legacy systems which can be presented in the UML models. UML tools also exist to

automatically generate deployable source code from UML model specifications. In such

an environment, the legacy systems can be modified by adding the NFRs to the extracted

UML model from the legacy system while source code can be re-generated automatically.

Tahvildari et al. propose a quality-driven re-engineering (QDR) framework which

allows specific quality requirements for the migrant systems to be modelled as a collection

of soft-goal graphs, and provides a selection of the transformational steps that need to

be applied at the source code level of the legacy system being re-engineered [54, 56].
CHAPTER 2. RELATED WORKS 21

They represent the extracted model of a legacy system in Abstract Syntax Tree (AST)

format. Their approach is an iterative and incremental process to systematically add

NFRs to the legacy system until the desired goals are achieved. Tahvildari et al. extend

their work and propose a framework of transformations that aims to improve error-prone

design properties and assist in enhancing specific qualities of a software system using a

catalogue of OO software metrics [55]. Figure 2.7 shows the quality-driven re-engineering

framework.

Non-Functional Transformation
Goal-Driven Requirements Rules

High-Level New
Source Code Source Code Code Evaluation Final System
Representation

ASG, AST, RSF, ...


UML Diagrams

Figure 2.7: The Block Diagram of the Quality-Based Re-engineering Process.

Recently, we presented a framework to incorporate NFRs with legacy systems [57].

We presented the extracted model of the legacy system in UML notations and propose

a mechanism to add NFRs to this extracted model. We used the NFR framework [18]

to get the solution of a particular NFR. Our framework is also applicable in forward

engineering.

2.3 A Comparison among Different Approaches

Table 2.1 shows a comparison among the several research works in terms of the UML

model used and each approach to handle the quality attributes of a system. The research
CHAPTER 2. RELATED WORKS 22

Research Class Use-case Sequence Collaboration State Extension Approach


Work Diagram Diagram Diagram Diagram Diagram Needed
Aspect √ Aspect
support in Based
design phase
[53]
NFR NFR
Framework N/A N/A N/A N/A N/A N/A Based
[18]
Composition
pattern in √ √ Aspect
design phase Based
[24]
Model for
early quality √ √ √ √ NFR
attribute [39] Based
UML-Based
Performance √ √ √ NFR
Engineering Based
[27]
AORE √ √ Aspect
Model [47] Based
UMLAUT √ √ Aspect
Framework Based
[32, 31, 33]
QDR NFR
Framework N/A N/A N/A N/A N/A N/A Based
[54, 56]
A use-case
and √ √ NFR
goal-driven Based
approach [51]
NFR in
conceptual √ √ √ √ √ NFR
model [25, 26] Based
Homogeneous
UML use-case √ √ NFR
Model [11] Based
Extending √ √ NFR
UML with Based
UML profile
[52]
NFRs in NFR
software N/A N/A N/A N/A N/A N/A Based
architecture
[58]

Table 2.1: A Comparison Among Several Related Research Works


CHAPTER 2. RELATED WORKS 23

works are presented in chronological order.

Table 2.1 shows that the research works that use the UML model to specify NFRs,

propose extensions to it. Most of the works use the UML use-case model to specify

the Functional Requirements of the system and they also use some extensions to the

use-case model to specify Non-Functional Requirements. Again, each of the work uses

some specific UML diagrams rather than providing the flexibility to use any type of UML

diagram.

2.4 Summary

This chapter presents a survey of related works. We classify each works by how they

specify Non-Functional Requirements in terms of forward and reverse engineering. The

goal is to provide a background knowledge of the existing and ongoing projects related

to this area. Most of the research works provide mechanisms to specify Non-Functional

Requirements in the design phase during forward engineering, but very few research works

apply their approach in re-engineering perspective. Again, the research works that use the

UML model to specify the NFRs, propose some extensions to UML model for this purpose.

We apply our framework both in forward and reverse engineering perspective using the

UML model, without proposing extensions to it. Following chapters will elaborate further

on our approach and its contributions.


Chapter 3

A Unified Modeling Framework

Generating high quality software requires the proper elicitation of its Non-Functional

Requirements with the Functional Requirements. If the NFRs are not reflected properly

in the design phase, the quality of the software will suffer. Researchers consider the design

phase of a software as the basic foundation of building a high quality product.

NFRs can be built into the design phase during forward engineering a software, but

there exist some legacy systems which may lack key NFRs. Here, the re-engineering

of these systems can play a significant role to add those NFRs which the system lacks,

rather than to rebuild the system from scratch at higher cost. Over the last few years,

the re-engineering of the legacy systems has gained a significant attention to the soft-

ware engineering community. Chikofsky defines re-engineering as “both renovation and

reclamation, the examination and alternation of a subject system to reconstitute it in a

new form and subsequent implementation of that form” [17]. The new implemented form

should be easier to maintain than the original one.

One of the advantages of applying software re-engineering techniques is to add some

non-functional properties which the legacy system lacks. The steps of re-engineering pro-

cess are i) reverse engineering, ii) modification of the extracted model, and iii) forward

24
CHAPTER 3. A UNIFIED MODELING FRAMEWORK 25

engineering. Reverse engineering extracts the legacy system in a higher level of abstrac-

tion (for example, from source code to architecture level), then the extracted model is

revised and modified with some new functional and/or non-functional requirements that

are absent in the existing system. In addition to that, sometimes the obsolete functional-

ity is removed from the legacy system. At the last stage, the upgraded model is forward

engineered.

To specify NFRs properly in both forward and reverse engineering, modeling can work

as the best way to achieve such goal. A model is a generation of potential configurations

of systems, including their extent and values. The model of a system captures and states

requirements and domain knowledge precisely, so that all stakeholder may understand

and agree on them [48].

In addition to that, modeling helps developers to work at a higher level of abstraction

by hiding the details of the system, focus on individual aspects of a system rather than

focusing on the whole, and think about the design of a system. In this thesis, we are

interested in developing a framework to integrate non-functional requirements with the

model of a software system. For this purpose, we choose the OMG specified UML model

for the modeling purpose of our framework [6]. The reasons for choosing UML models

are as follows:

• It’s the industry standard for software modeling notations.

• Various types of UML diagrams are available to capture several views of a system.

• Lots of UML tools are available in the market these days for analyzing source code,

executing UML models and generating code from UML model specifications.

We propose to apply the framework both in the forward and reverse engineering process.

In forward engineering, we model a system using UML diagrams. During reverse engi-
CHAPTER 3. A UNIFIED MODELING FRAMEWORK 26

neering we assume that a legacy system will be extracted in UML model specifications.

The next section describes the steps of the framework.

3.1 The Unified Modeling Framework

Our proposed framework is composed of three phases: i) Identifying Requirements ii)

Modeling Requirements and iii) Integrating Requirements. All the three phases share

a common repository which is a reusable NFR Library/Repository. The repository of

NFRs will evolve in time and give the developers more flexibility to add NFRs in less

time without designing them from the scratch. Figure 3.1 shows the architecture of the

framework.
Legend
Process
Optional Process
Design Documents Control Flow
User Requirements Data Flow
Design Specifications NFR Library/Repository
Extracted UML model
Repository
in XMI Format

Identification of Requirements Specification of Requirements Integration of Requirements


XMI FR Specifying FR using UML Diagram Integrating NFR with
Pre−Processor XMI
FR of the system as Post−Processor
Specify NFR using NFR Framework
NFR ‘‘ADD’’ component of XMI
and the proposed high level language

Figure 3.1: The Architecture of the Framework

In Figure 3.1, the rectangles represent the phases of the framework while the ovals

represent the process within the the each phase. The dotted ovals represent the optional

process of the framework which may or may not be needed to execute. The execution

of these processes depends on the available input/output of the framework. During

the application of the framework in the reverse engineering context, we assume that an

extracted UML model in standard XMI format will be available . In case the model is not

in standard XMI format, the developers need to run the preprocessor to transform that
CHAPTER 3. A UNIFIED MODELING FRAMEWORK 27

input to a standard one to feed into our framework. Again, the output of our framework

is standard XMI. If the developers want some other formats of output other than XMI,

they need to run the postprocessor to transform the output.

The repository of the framework represents the NFR Library, the single arrows rep-

resent the control flow among processes, and the double arrows represent the data flow

between each phase and the repository. Further explanations about the each of the phases

of the framework can be found in the following subsections.

3.1.1 Identifying Requirements

The first step of our framework is to identify the requirements of a system. During forward

engineering, user requirements, design documents and design specifications can be used

to identify the Functional and Non-Functional Requirements of a system. From reverse

engineering perspective, the extracted UML model of a legacy system can be used to check

which requirements are already applied in the system and which are still needed to be

applied. Some new requirements may also arise in this case. In the Identification phase,

the NFR Library/Repository can also be used to identify NFRs which the repository

already contains. In this case, the developers do not need to model these NFRs in the

next phase of the framework. They can just reuse the NFRs from the repository to save

time. However, in some cases NFRs contained by the repository may only partially satisfy

the requirements of the new NFRs. In this case, the required modifications of the NFRs

can be identified so that the NFRs satisfy the new requirements. Here the advantage

of the repository is that it works as a knowledge-base for the NFRs. As a result, the

developers can avoid designing the required NFRs from scratch.


CHAPTER 3. A UNIFIED MODELING FRAMEWORK 28

3.1.2 Modeling Requirements

After identifying the FRs and NFRs, the next step is to model the requirements. The Mod-

eling phase of our framework consists of two parts: to model the Functional-Requirements

of the system and to model the Non-Functional Requirements of the system.

To model the Functional-Requirements, we use the proper UML diagrams which are

necessary to express the functionality of a system. For example, in some cases class

diagrams with some other interaction diagrams would be appropriate to describe the

object oriented view and functionality of system, while in some other cases, use case

diagrams would describe a system properly. It is up to the developers which diagrams

they think are appropriate to describe the system functionality. For this thesis, we select

the UML class diagram as the primary representation of the functional model and the

activity diagram to show the control flow from one activity to another among several

operations of the class diagrams. The reasons behind choosing class diagram are twofold:

first, class provides a nice abstraction of entities that is a part of the vocabulary of a

system, and second, many programming languages directly support the concept of a class

where automatically deployable source code can be generated from model specifications.

We select the activity diagram as it is essentially a flowchart which provides a mechanism

to describe the activity of a work flow of a specification.

The modeling of NFRs starts with the use of the NFR Framework. The reason behind

choosing the NFR framework is that it offers a structured goal-oriented process for stating

and refining requirements, selecting implementation techniques, and evaluating whether

the target system will meet the requirements [18]. All of these design alternatives and

decisions are captured in a graphical format called the soft-goal-interdependency graph

(SIG).

The framework defines the NFRs as softgoal. SIG is actually an AND/OR graph
CHAPTER 3. A UNIFIED MODELING FRAMEWORK 29

where the root represents the main NFR (main softgoal ) and the descendants of the root

represents the decomposition of that softgoal to sub softgoals where by satisfying the

sub softgoals one can achieve the target main softgoal. The leaf nodes of SIG actually

represent the design decisions which can be taken to implement a NFR. Any decision

can be evaluated by considering the positive/negative impact of that node toward it’s

ancestor nodes. Details of the SIG with an example are further elaborated in Chapter 2

in subsection 2.1.1.

After the evaluation of SIG, the resulting subgraph provides a solution for achieving a

particular NFR that needs to be integrated with the Functional Requirements of the target

model. This is a general solution for achieving the particular NFR without considering

the modeling language used to design the software system. As we use UML diagrams for

modeling the Functional Requirements of the target system, the solution from the NFR

framework needs to be mapped to proper UML representation to incorporate it with

them. For this purpose, we propose a High Level Language to model the solution of the

NFRs from the NFR framework using UML diagrams. The particulars of this language

is elaborated further in Chapter 4. In addition to NFR modeling, the proposed language

also focus on the reusability of the NFRs by dynamically instantiating the necessary input

parameters and join-points of the NFRs with the target model.

For example, suppose one of the NFR solutions need to insert a method inside a

class. If we just insert the method with the necessary parameters in the appropriate class

diagram, the design will be hard coded. Instead, we propose to build a template of a

method with the proposed language. The actual method will be built after the developers

specify all the necessary parameters during attaching the NFR with the target model.

The advantage of this template mechanism is that we can use the same template of the

NFR in other target models by dynamically generating another set of parameters.

The Modeling phase stores the NFR templates to the NFR Library/Repository for
CHAPTER 3. A UNIFIED MODELING FRAMEWORK 30

future use. The template consists of a ordered set of instructions written in our High

Level Language. The instructions set is actually the commands to build UML entities to

model the NFRs in the target system. the actual UML entities are created during the

integration phase which is discussed in the following subsection.

3.1.3 Integrating Requirements

After modeling the Non-Functional Requirements, the Integration phase becomes a NFR

weaver that weaves those desired NFRs with the Functional Requirements of the target

system. The weaver interprets the NFR templates written in our High Level Language.

The weaver weaves the UML representation of the NFRs after the developers specify all

the necessary parameters for building that UML diagram. For example, developers may

need to specify any constraints, guard conditions, and so on for the NFRs to join them

with the target model. The output is generated in XMI format for tool compatibility.

We integrate the NFRs with the UML model of the target system as an XMI “ADD”

component.

The “ADD” component is called the “differences” of XMI. The differences information

has three types of available operations: i) to add an object as a descendant of some other

objects of the main model, ii) to delete an object from the main model, and iii) to replace

an object with another object of the main model. If we want to add a method as an NFR

implementation inside a class of the main model, we insert this NFR related method as

an “Add” component rather than inserting it in the main model. Inside the syntax of

the “ADD” component, we can refer to the class of the main model, where we can add

the method. For example, suppose there is a class in the main model with id ”xmi.1”.

Now we want to insert a method (operation in XMI context) with id “xmi.2” as an NFR

implementation inside the class “xmi.1”. By inserting it as an “Add” component, we can

separate it from the main model. According to the extended XMI version 1.1 specification
CHAPTER 3. A UNIFIED MODELING FRAMEWORK 31

(OMG Document ad/2001-03-10 [4]), the syntax to add a component is as follows:

<difference>

<add addition=“xmi.2”>

<target xmi.idref=“xmi.1”/ >

</add>

<Operation xmi.id= “xmi.2”>

description of the operation

...

...

</diffrence>

The target is the join point of the NFR with the main model(here a class), where the

new component (here a method) will be added. By deleting the “ADD” component, we

can delete the NFR related method.

Again for example, suppose as an NFR implementation, we need to delete an at-

tribute, with id xmi.3 from a class of the main model. If we just discard the attribute,

the main model will be changed. We can not restore the attribute if the NFR is deleted,

unless we insert that attribute again. However, if we want to do this operation as an

”Add” component, we can use the delete operation of the “ADD” component to perform

the job. Again, according to the extended XMI version 1.1 specification (OMG Doc-

ument ad/2001-03-10 [4]), the syntax to delete a component inside “ADD” component

specification is as follows:

<difference>

<delete>

<target xmi.idref=“xmi.3”/ >

</diffrence>

Here, the main model still contains the attribute with id xmi.3. However, as there is
CHAPTER 3. A UNIFIED MODELING FRAMEWORK 32

a delete command whose target is this attribute, it will appear in the final model (NFR

attached to it) as deleted. Now, if any one wants to delete the NFR, deleting the “ADD”

component will not effect the main design, as the attribute will be restored there.

In this way, by using the “add”, “delete” and “replace” operation of “ADD” compo-

nents we can integrate the NFR with the main model. However, any modification and

deletion of the NFRs will not effect the main model.

However, a component in the main design may also appear as an “ADD” component.

Here we need a mechanism to distinguish the NFR “ADD” components from the “ADD”

components of the main design. For this purpose, we use the some special tag inside the

comment of the XMI of a NFR related “ADD” component. This “commenting” technique

is a common practice in visual IDEs. An “Add” component, related to any particular

NFR, starts with a special tag. In our framework, we can identify these NFRs from these

special comments. For the earlier example where we insert a method inside a class of the

main model, the XMI syntax with comments would be:

<annotation>

<documentation>%NFR%: $NFR Name$

</documentation>

</annotation>

<difference>

<add addition=“xmi.2”>

<target xmi.idref=“xmi.1”\ >

<\add>

<Operation xmi.id= “xmi.2”>

...

<\diffrence>

Here the documentation provides the flexibility to keep comment inside the XMI.
CHAPTER 3. A UNIFIED MODELING FRAMEWORK 33

3.2 Architecture of the Framework

Figure 3.1 shows that our framework has a combination of blackboard as well as pipe and

filter architecture. The Modeling phase (filter) is the core of our framework. However,

the Identification and the Integration filters are replaceable. Earlier, we noted that our

framework can be used both in forward and re-engineering perspectives. This can be

done by using the proper Identification filter for that two engineering context. In forward

engineering, where there is no legacy systems, the only concern of the Identification phase

is to identify the requirements. In that case the Modeling phase starts by specifying the

new FRs and NFRs in standard XMI format of UML model. During the re-engineering a

legacy system, the system needs to be extracted in the XMI format to feed that input into

our framework. For this purpose, the developers may use the preprocessor filter to get

the XMI of the model before starting the Identification phase. As long as the system can

be extracted in XMI format, it does not violate our framework. However, if the legacy

system is in another format other than the UML model, the preprocessor can be a series

of consecutive steps of several filters to convert that format to the XMI format.

Finally, if the OMG decides to use some other standards for a UML model other than

the XMI, the core part of our framework (the Modeling phase) will not be effected as our

proposed language has a generic format which aims to create/delete the UML entities,

and do some basic operations on them. Detailed discussion about the proposed language

will occur in chapter 4. However, the Identification filter for re-engineering context and

the Integration filter needs to be replaced by the new filters supporting that new standard

of the UML model.


CHAPTER 3. A UNIFIED MODELING FRAMEWORK 34

3.3 UML Model Without Extension

As mentioned earlier, our framework does the mapping from an Operationalizing softgoal

of an NFR Framework [18] to a development technique in the target model, expressed in

standard UML notation.

Most of the research works propose some extension to UML models to introduce some

new notations to represent and identify NFRs. Their work is only at the visualization

level of UML models. For example, the research works presented in [51, 52, 39, 25, 27,

11, 53, 24] propose some extensions of the UML model to adopt their newly introduced

notations of the UML model to express NFR related UML entities. However, unless these

extensions are adopted by OMG, the output of such integration becomes incompatible

with other UML tools. Again, in standard XMI format, they can not express those NFRs

as there are no semantics available for their newly introduced symbols in standard XMI.

Our proposed framework overcomes this problem. Our work is at the level of XMI

with the standard UML notations. Instead of proposing new notations at the visualization

level of UML diagrams, we use some special comments to identify the NFRs at the XMI

level which was discussed further in subsection 3.1.3. Again, the output of our framework

will appear as standard XMI to other UML tools, if they want to interpret the UML

model from XMI specifications. However, other tools won’t be able to distinguish the

part of the NFR related “ADD” component from the “ADD” component of the main

design. Still, those tools will be able to interpret those UML entities as ordinary “ADD”

components as we are specifying them with the standard UML notations.

3.4 Summary

We propose a unified modeling framework for specifying Non-Functional Requirements

in the design of a software system. The framework works in an incremental process by


CHAPTER 3. A UNIFIED MODELING FRAMEWORK 35

consecutively identifying NFRs, modeling them and integrating them with the target

model. The framework specifies the NFRs as reusable components without hard coding

the necessary parameters for the UML representation of the NFRs to be integrated with

the target model. The architecture of the framework is designed in such a way that it

has the flexibility to adopt any changes in the standardization of the format of the input

and the output of the framework.


Chapter 4

A Formal Language for Modeling


NFRs

Based on the importance of elicitation of requirements in software development, many

researchers proposed several frameworks and requirement languages to express require-

ments clearly at the early stage of a software life cycle [13, 15, 28, 29]. We propose a

High Level Language (HLL) to map the Operationalizing softgoals to UML diagrams.

The motivation is twofold: we want to map the solutions from the NFR framework into

target models in a formal way, and we want to construct a repository of reusable NFR

templates. The template is not executed at this point, but becomes an ordered set of

instructions/commands (similar to a script in UNIX). While the framework is attaching

the NFR to the Functional Requirements of the system, the template commands are ex-

ecuted (in order) to construct the proper UML representation of the NFR. The proposed

HLL is based on standard UML and is tailored to facilitate the achievement of the second

goal.

36
CHAPTER 4. A FORMAL LANGUAGE FOR MODELING NFRS 37

4.1 Terminology

The basic operands and operations in the HLL are closely related to the vocabulary

and semantics of standard UML. The vocabulary of UML consists of a set of elements

(class, attribute, state, activity and so on) to represent discrete concepts in software

systems. The vocabulary also contains a set of relationships (association, aggregation,

generalization, transition and so on) to relate the elements. The basic operand types in

the HLL are defined as follows.

Definition 4.1 An Object corresponds to an element in the UML vocabulary.

Definition 4.2 A Link corresponds to a relationship in the UML vocabulary. Thus a

Link relates two objects.

Definition 4.3 A Property of an Object or a Link corresponds to a property of the

associated UML element or UML relationship.

A Link between two Objects can be directed. Examples of directed Links are state

transitions, generalizations, dependencies, realizations and so on. We distinguish between

the Objects associated with a directed Link based on their role with respect to the Link.

Definition 4.4 The Source of a Link is the Object from which the Link originates (as

given by the direction of the Link).

Definition 4.5 The Target of a Link is the Object where the Link terminates (as given

by the direction of the Link).

For example, the Target of a dependency Link is the corresponding independent

Object while the dependent Object is the associated Source. The Source and Target of

a generalization Link between two classes are the associated subclass and superclass,
CHAPTER 4. A FORMAL LANGUAGE FOR MODELING NFRS 38

respectively. For undirected Links, any of the associated Objects can play the role of a

Source or a Target. Association is an example of an undirected Link.

UML requires that each Object or Link is contained in certain other Objects. For

example, each Operation or Attribute must be contained in a Class which in turn may

be contained in a package. Likewise, each State or Transition must be contained in a

State Diagram. Thus, a software system is typically modelled in UML as a hierarchical

structure. A set of semantic rules governs the hierarchical relationships among Objects

and Links.

Definition 4.6 If an Object or Link x is contained in another Object y, we say that x

is a Descendent of y and y is an Ancestor of x.

Using the terminology defined above, we can formalize UML as (O, L, P, Rp , Rst , Ra , Rd )

where,

- O is the set of Objects (Definition 4.1),

- L is the set of Links (Definition 4.2) and O ∩ L is empty,

- P is the set of Properties (Definition 4.3),

- Rp ⊆ {O ∪ L} × P is a relation that associates any

Object or Link x ∈ {O ∪ L} with corresponding

Properties px ∈ P ,

- Rst ⊆ L × O × O associates each Link l ∈ L with the

corresponding Source (Definition 4.4) sl ∈ O and Target (Definition 4.5) tl ∈ O.

- Ra ⊆ {O ∪ L} × O, where hx, yi ∈ Ra

indicates that y is an Ancestor (Definition 4.6) of x.

- Rd ⊆ O × {O ∪ L}, where hx, yi ∈ Rd

indicates that y is a Descendent (Definition 4.6) of x.


CHAPTER 4. A FORMAL LANGUAGE FOR MODELING NFRS 39

Here, the relations Rp , Rst , Ra and Rd are standard Property, Source-Target, Ancestor,

and Descendent relations which OMG has defined for UML models [48]. This formal

representation will be the basis for the construction of the HLL. The Objects, Links, and

the Properties are the operands of the HLL. The operations of the HLL are categorized

into primitive operations and supportive operations. The set of primitive HLL operations

consists of:

• creation and deletion of instances of Objects and Links,

• retrieval and modification of Properties of instantiated Objects and Links, and

• identification of instantiated Objects or Links related (as an Ancestor or a Descen-

dent) to a given Object instance.

The HLL supportive operations allow repeating a set of operations, performing a

conditional branching, and reading user inputs. In the rest of the thesis, we will use the

words operation and command interchangeably. The operations are described in detail

below.

4.2 Primitive Operations

In our proposed language, each element (either Object or Link ) of a UML model is

like a primitive data element in a programming language. We propose some primitive

operations to manipulate these elements. Some of these primitive operations are special-

ized for each particular type of UML element. Using these operations, any element of the

standard UML notation can be created or deleted and any Property of an Object or Link

can be retrieved or updated. In addition, given an element, any related element can be

identified. The primitive operations are summarized in Table 4.1.


CHAPTER 4. A FORMAL LANGUAGE FOR MODELING NFRS 40

Name Parameters Description

Specialized Primitive Operations


CreateObjectx Input: Creates an instance of
x∈O – Namespace/Owner y ∈ O, y is a Object x as a child of
valid Namespace/Owner of x Namespace/Owner with
– Set of Properties {Px }, the set of Properties
hx, Px i ∈ P
Output:
– An instance of Object x
CreateLinkx Input: Creates an instance of
x∈L – Namespace/Owner y ∈ O, y is a Link x as a child of
valid Namespace/Owner of x Namespace/Owner with
– Set of Properties {Px }, the set of Properties
hx, Px i ∈ P
Output:
– An instance of Link x
FindAncestora Input: Finds the ancestor
a∈O – Object or Link x ∈ O ∪ L Object a of the given
Output: Object or Link
– The instance of appropriate
ancestor Object a of x
FindDescendantd Input: Finds the descendant
d∈O∪L – Object x ∈ O Object d (or Link d )
Output: of the given Object
– The instance of appropriate
descendent Object d (or Link d )
of x
Non-Specialized Primitive Operations
Delete Input: Deletes the given
– Object or Link x ∈ O ∪ L Object or Link
Output:
– None
getProperty Input: Returns a particular
– Object or Link x ∈ O ∪ L Property value of the
– Property Name p ∈ P given Object/Link
Output:
– The value of property p of x
setProperty Input: Sets a particular
– Object or Link x ∈ O ∪ L Property of the given
– Property Name p ∈ P Object/Link
– New Property value is a string v as the new value
Output:
– None

Table 4.1: A List of Primitive Operations


CHAPTER 4. A FORMAL LANGUAGE FOR MODELING NFRS 41

4.2.1 Specialized Primitive Operations

The primitive operations are related to the UML Model. The XML documents are tree-

based structures of matched tag pairs containing nested tags and data. XMI is the OMG

defined XML schema for representing UML models.

The primitive operations and the parameters of the operations are chosen accord-

ing to this XML schema of UML model [7]. According to the tree-based structure

of the schema, each element is created as a descendent of some other element, where

“Model Management” is the root of all elements defined in the schema. Two important

things are the owner and namespace of an element. Every element may own zero or

more elements and the valid owners of the elements are defined in XML schema. The

namespace is the visibility of an element describing what scope a particular element is

visible, similar to the visibility of a variable declaration in a programming language. Con-

ceptually the owner and the namespace have the same meaning. We describe the set of

primitive operations below:

• CreateObject(Namespace/Owner, Set of Properties): This command is to

create an Object instance as a descendant of some other instantiated Object. The

set of Properties are defined by the XML schema. Although we mentioned earlier

that the owner and the namespace have conceptually the same meaning, we still

have the option of creating an Object either by defining namespace or owner. The

reason is that the XML schema for UML model has defined some Objects as owned

elements of other Objects while some Objects do not have any owner. Rather they

are created within the namespace of other Objects. The set of properties is actually

the set of attributes of an Object.

The proposed language includes specializations of the CreateObject command. The

specialized forms are as follows:


CHAPTER 4. A FORMAL LANGUAGE FOR MODELING NFRS 42

∀x ∈ O, CreateObjectx (y, {px }), such that hx, px i ∈ Rp . Here y can be any

element from O such that hx, yi ∈ Ra .

The input/output parameters and the functionality of the command is specified

in Table 4.1. To illustrate its functionality consider the following example: the

specialized form of the command for creating the Object Class inside a Package

would be CreateClass(Owner Package of the Class, {name, namespace, isSpecifica-

tion, isRoot, isLeaf, visibility . . . }) where the class will be created with the set of

Properties {name, isSpecification, isRoot, isLeaf, visibility . . .}, as a descendent of

the owner Package. Again, to create the Object Operation, this command would be

CreateOperation(Owner Class of the Operation, {name, namespace, . . . }) where

the Operation will be created as a descendent of the owner class with its predefined

set of Properties.

• CreateLink(Namespace/Owner, Source, Target , Set of Properties): This

command is to create an instance of Link between the instantiated Source and

Target Object with the set of Properties. The reason for keeping both the namespace

and owner option is the same as for creating Object: the Source and Target Object

are the valid source and target for a particular Link defined in XML schema. Again,

the set of properties is the set of attributes for a particular Link.

The specialized forms of the general command CreateLink are obtained as follows.

∀l ∈ L, ∀s ∈ O, ∀t ∈ O, hl, s, ti ∈ Rst

CreateLinkl (y, s, t, {pl }) , such that hl, pl i ∈ Rp . Here y can be any element from O

such that hl, yi ∈ Ra .

For example, for Link association, this command would be CreateAssociation(Owner

of association, Source Class, Target Class, {name, . . . , associationEnd1, assiciatio-

nEnd2, Role1, Role2, Multiplicity1, Multiplicity2 . . .}) where the association will
CHAPTER 4. A FORMAL LANGUAGE FOR MODELING NFRS 43

be created between the source and target class with its defined set of Properties.

Table 4.1 describes the input/output parameters and the functionality of the Cre-

ateLink command.

• FindAncestor(Object/Link ): This command is to find the ancestor Object in-

stance, given a particular Object/Link instance. The ancestor may be the direct

owner or parent of an Object/Link instance, or it may be the visibility scope (names-

pace) of that Object/Link instance.

The specialized forms of the FindAncestor command are obtained as follows.

∀x ∈ O, ∀a ∈ O, hx, ai ∈ Ra , FindAncestora (x).

For example, to find the parent class of a particular operation, the command would

be FindAncestorClass(Operation). Further details can be found in Table 4.1.

• FindDescendant(Object): This command is to find the descendant element,

given an Object. The FindDescendant command is needed only to find the de-

scendant of an Object. According to the XML schema, Link does not have any

descendant element.

The specialization of the FindDescendent command is performed as follows.

∀x ∈ O, ∀d ∈ O, hx, di ∈ Rd , FindDescendentd (x).

For example, to find an attribute of a class the command would be FindDescendent-

Attribute(Class). Table 4.1 shows a summary of this primitive operation in terms

of input parameters and functionality.

4.2.2 Non-Specialized Primitive Operations

The Non-specialized primitive operations include getProperty, setProperty, and Delete.

We categorize them as non-specialized commands because they can be used in the general
CHAPTER 4. A FORMAL LANGUAGE FOR MODELING NFRS 44

form for all Objects and Links. Table 4.1 gives a summary of all the non-specialized

commands. The details of the commands are given below.

• getProperty(Object/Link, Property Name): This command grabs the Prop-

erty value of the particular Property Name of an Object/Link instance. This allows

developers to know a particular Property value of an Object/Link instance during

run-time. This command will give them the flexibility to know the desired Property

value dynamically.

• setProperty(Object/Link, Property Name, New Property Value): This

command dynamically changes the value of a particular Property of an Object/Link

instance to a new Property value.

• Delete(Object/Link ): This command deletes any Object/Link instance. The

goal of this command is to delete the Object/Link instance with all of its Properties

and owned elements.

We do not specialize the operations Delete(Object/Link ), getProperty(Object/Link,

Property Name), and setProperty(Object/Link, Property Name, New Property Value) for

any specific UML element. Rather, we use them as primitive operations. Like other prim-

itive operations, these will not vary for each type of UML Element. For example, one of

the possible Links between two classes may be Association, or one of the possible Links

between two states may be Transition. As a result, the CreateLink operation should be

specialized for CreateAssociation type Link and CreateTransition type Link. Same rule

applies for other specialized operations. However, for deleting Association Link or Transi-

tion Link, we do not need to distinguish between these two types of Links. Rather we just

need to identify the Link. The specialized forms of this command like “DeleteAssociation”

and “DeleteTransition” will be redundant where only “Delete” command can satisfy the
CHAPTER 4. A FORMAL LANGUAGE FOR MODELING NFRS 45

deleting purpose. The same rule applies for deleting any type of UML Element. Again,

the getProperty(Object/Link, Property Name), and setProperty(Object/Link, Property

Name, New Property Value) do not distinguish among the UML Elements, so do not

specialize them.

4.3 Supportive Operations

In addition to the primitive operations, we also propose additional operations which

are not specific to any UML diagram, but are general commands which will be needed

to build the NFR templates. We call them “Supportive Operations”. The supportive

operations are categorized as Selection Statement, Choice Statement, Iteration Statement

and Conditional Statement. These are general criteria for any programming language

operations.

4.3.1 Description of the Supportive Operations

The aim of the supportive operations is to provide the developers with the programming

language commands to control the sequence of operations and to dynamically take and/or

change the input value of the NFRs. Our aim is to make the command set small and easy

to understand. A summary of all the supportive commands can be found in Table 4.2.

• getSelectedInput({Object/Link }): This command falls into the “Selection”

statement category. The aim of this operation is to select some of the values from

an Object/Link set. This command allows a developer to manipulate a subset of

Objects/Links from a list of Objects/Links. For example, a class may have a set

of attributes. If the developers want to select some of the attributes from that

attribute list and modify them, they can use this command to select the subset of

the attribute list.


CHAPTER 4. A FORMAL LANGUAGE FOR MODELING NFRS 46

• getDynamicInput(): This command falls into the “Choice” statement category.

The aim of this command is to dynamically take some necessary inputs for the

NFRs. For example, the command gives the flexibility to dynamically take the

name of some class, its Properties and so on, and then, by CreateClass command,

the corresponding class may be created with these dynamically taken name and

Property values.

• For Each Element X in {Set of elements} do

Statements

End Statement: This command falls into the “Iteration” statement category to

provide some mechanism for looping. It provides the flexibility for repeating any

statements using a loop. According to the definition of the Iteration Statement

as discussed in [46], iteration consists of a head and a body. The head controls

the number of times that the body will be executed, whereas the body is usually a

(compound) statement that provides the action of the statement. Here, the head

means “for each of the element in the set of elements the body (statement) will be

executed”.

• If (Condition = True)

Statement

[Else Statement]

End If: This command falls into the “Conditional” statement category. A con-

ditional statement is one that expresses an alternation of two or more statements,

or an optional execution of a single statement, where statement means either a

single basic statement or a compound statement [46]. The choice of alternatives

is controlled by a test on some condition. Here, we consider a simple expression


CHAPTER 4. A FORMAL LANGUAGE FOR MODELING NFRS 47

Type Name(Parameters) Parameter Purpose


Description

Selection getSelectedInput({Object/Link }) Object∈ O or Provides the flexibility


Link ∈ L to select some of the
values from the given set
of Objects or Links
Choice getDynamicInput() No Parameters Provides the flexibility
to specify some
values at run-time
Iteration For Each Element X in {Set of elements} do No Parameters Provides the flexibility of
Statement Statements looping
End For
Conditional If (Condition = True) No Parameter Provides the flexibility for
Statement Statement conditional statements
[Else Statement]
End If

Table 4.2: A List of Supportive Operations

for condition checking. We choose the if-then-else conditional statement for our

proposed language. The else part is optional.

Table 4.2 shows a summary of these supportive operations.

4.4 Summary

In this chapter, we have formalized our proposed language for specifying Non-Functional

Requirements. The language is based on the XML schema defined by OMG for UML

diagrams. The language provides textual notations for specifying the UML diagrams. The

textual format removes the obstacle to specify the UML diagrams with fixed parameter

values. By dynamically instantiating the parameter values, the same UML design can be

re-used.
Chapter 5

Implementation Architecture

A prototype has been developed in Java programming language on the Windows XP plat-

form to implement the proposed framework in a semi-automated manner. The prototype

provides functionality for:

• loading and visualizing a UML model represented in standard XMI,

• incorporating new functional requirements into the model,

• incorporating (solutions of) nonfunctional requirements, available in the prototype’s

NFR library/repository, into the model,

• storing the updated model with newly added functional and nonfunctional require-

ments in standard XMI, and

• adding new NFRs into the NFR library/repository using a SIG builder and a tem-

plate builder.

The prototype implements an interpreter for the High Level Language (HLL) pro-

posed in Chapter 4. The NFR Library/Repository is a collection of Java classes, each

48
CHAPTER 5. IMPLEMENTATION ARCHITECTURE 49

corresponding to an NFR template specified in the HLL. When the NFR template is

attached to the target model, the template is executed by the interpreter. This process

generates the actual UML representation of the NFR solution based on the parameters

provided by the model. The components of the prototype, as well as its functionality, are

discussed in detail in this chapter.

5.1 Detailed Process of the Prototype

We start with a detailed description of the functionality of the prototype. We describe

the process in the context of the unified modelling framework described in Chapter 3

(Figure 3.1). To add any particular NFR, we apply the proposed framework using the

steps described below. Here, we relate each of the steps with the framework proposed in

Chapter 3.

• Step 1: Input to the Identification phase of the framework. We inter-

pret the XMI representation of the input model, generated by a UML tool, like

ArgoUML [1]. The UML tool is an example of a preprocessor depicted in Figure

3.1. We present the UML model of the system in a tree hierarchy where each entity

is denoted by a separate icon. We also present the visual representation of the class

diagram and the activity diagram by using UML notation of class diagrams and

activity diagrams respectively.

• Step 2: Identification of NFR phase of the framework. This step is require-

ment analysis process. The prototype’s role is to provide a visual representation of

the model to facilitate the requirement analysis process. Let us assume that the

requirements of the system suggest that certain NFRs have to be fulfilled by the

system at hand. For the sake of describing the prototype’s functionality, we also
CHAPTER 5. IMPLEMENTATION ARCHITECTURE 50

assume that the input model does not fulfil the identified NFRs. If the required

NFRs are available in the NFR library/repository of the prototype, we go to Step

5 directly. Otherwise, we continue to Step 3.

• Step 3: Modelling the NFRs phase of the framework. Once we identify the

NFRs, we use the NFR Framework [18] to get a solution for those NFRs. After the

evaluation, we draw the evaluated SIG in the SIG Builder/Editor provided in the

prototype. After drawing the SIG, we start to build the NFR template according

to the solution of the NFR framework in the NFR Template Builder/Editor of

the prototype using our proposed High Level Language. Once we specify the NFR

templates, we compile the templates to generate the corresponding Java commands

of the UML commands specified in our High Level Language. After the compilation,

a Java class is generated for each of the NFR and they are stored in the NFR

Library/Repository.

• Step 4: Integration phase of the framework. After determining the NFRs in

the NFR library/repository that should be incorporated into the model, the next

step of the framework is to integrate the NFRs with the model. For this integration

purpose, we select the proper UML entities of the input model (the join point of the

NFR) and the NFR which we want to attach to the entity. During the integration

process, the users are asked to supply the necessary parameters (for example, name

of any UML entity, any constraints or guard conditions and so on) and with these

parameters the weaver generates the proper UML diagram for the NFRs. The

output is generated in XMI format for internal storage. The visualization of the

input model with the NFR attached to it is shown by a tree hierarchy in the UML

model and also with UML notation in the UML diagrams.

• Step 5: Output from the Integration phase of the framework.


CHAPTER 5. IMPLEMENTATION ARCHITECTURE 51

The final output of the Integration phase (which is also the output of the framework)

is generated in standard XMI. The final XMI representation includes the newly

added nonfunctional requirements in the original UML model.

Legend

Module
Permanent storage Visualization Engine
DOM Repository

SIG Class Diagram Data Flow


Control Flow
State Diagram
DOM Loader
Activity Diagram

Model Loader
Model

NFR Manager
Controller
Validity Checker
SIG Builder
Loader
NFR Template Builder

NFR NFR Compiler


Model Serializer Reposiroty
External user
NFR Integrator

Permenant storage NFR Parser

Figure 5.1: Architecture of the Prototype

5.2 Major Components of the Prototype

The major components of the prototype are: the Controller, the Loader, the Model Seri-

alizer, the Visualization Engine and the NFR Manager. Figure 5.1 shows the architecture

of the prototype. The loader reads the UML models represented in standard XMI and

provides input to the framework (Step 1 in Section 5.1). The model serializer stores the

output of the framework on some permanent storage, such as a disk (Step 6 in Section
CHAPTER 5. IMPLEMENTATION ARCHITECTURE 52

5.1), while the visualization engine deals with the visual representation of the loaded

model. This helps in the identification of functional and nonfunctional requirements

for the system (Step 2 in Section 5.1). The specification of new NFR solutions in the

proposed High Level Language, the maintenance of the NFR library/repository, and the

integration of NFRs with the model are all carried out by the NFR manager (Steps 3, 4,

and 5 in Section 5.1, respectively). The controller interacts with the user and activates

the appropriate component to serve user requests. The next subsections describe each

component and its relations to the other components.

5.2.1 Controller

The controller component is responsible for communicating with the user and dispatching

user commands to the appropriate command processor module. The controller can be

considered as the core engine of the prototype which actually handles everything. For

example, if the commands for visualizing SIG or the UML representation of any of the

NFRs comes to the controller, it dispatches the command to the visualization engine.

Again, for handling any NFR specification related operations, it dispatches the commands

to the NFR Manager.

5.2.2 Loader

The primary job of the loader component is to load UML models into our framework.

Our framework accepts UML models represented in standard XMI. This component also

performs validity checking to ensure that the input represents a valid UML model. For

this purpose, the loader uses a document object model (DOM) which is essentially the

XMI specification defined by OMG. The loader performs its tasks with the help of the

following major submodules:


CHAPTER 5. IMPLEMENTATION ARCHITECTURE 53

DOM (Document Object Model) Loader

Input: XML Schema of XMI (defined by OMG).

Output: A DOM tree.

Process: Constructing an internal representation of the document object model

provided.

Validity Checker

Input: An internal representation of an UML model represented in XMI.

Output: Valid/invalid.

Process: Checking the validity of the given model against the document object

model already loaded. Outputs valid if the given model is valid and outputs invalid

otherwise.

Model Loader

Input: A designer-provided UML model represented in standard XMI.

Output: An internal representation of the input UML model.

Process: Constructing an internal representation of the input UML model.

Usage: Validity Checker.

The Document Object Model (DOM) is actually an application programming inter-

face (API) for valid HTML and well-formed XML documents [8]. It defines the logical

structure of documents and the way a document is accessed and manipulated. In the

DOM specification, the term “document” is interpreted as data rather than a document.

XML presents this data as documents, and the DOM may be used to manage this data.

With the Document Object Model, programmers can build documents, navigate their

structure, and add, modify, or delete elements and content. The DOM loader parses the
CHAPTER 5. IMPLEMENTATION ARCHITECTURE 54

XMI schema specification (as defined by OMG) to construct a DOM tree at the beginning

of the program. The DOM tree is used later by the validity checker. Figure 5.2 shows a

snapshot of the parsed XML schema in a DOM Tree representation of our prototype.

Figure 5.2: The Snapshot of Parsed DOM Tree From XML Schema of UML Model

When designers want to load a model into the framework, the controller sends the

request to the model loader. The model loader reads the input model from permanent

storage and constructs an internal representation of the input model. The model loader

then sends the internal representation to the validity checker which validates the model

description against the DOM to ensure the validity of the input model description. The

validity checker notifies the model loader whether the input model is valid or not. In

case the validity checking fails, the model loader notifies the designer with an appropriate

error message. Otherwise, the internal representation of the model is displayed as a

hierarchical structure and also in a visual format using UML notation. The display
CHAPTER 5. IMPLEMENTATION ARCHITECTURE 55

operation is delegated to the visualization engine (described later). Figure 5.3 shows

an interpretation of a UML model both in Tree hierarchy and in visual format. The

tree shown in the upper left panel describes the model as a hierarchical structure. The

associated class diagram is displayed in the upper right panel using UML notation. The

DOM tree is displayed in the lower rightmost panel.

Figure 5.3: The screenshot of Input Model


CHAPTER 5. IMPLEMENTATION ARCHITECTURE 56

5.2.3 Model Serializer

This component deals with storing the updated UML models into permanent storage. Our

framework stores the models (with NFRs incorporated) in standard XMI. The output is

generated based on the document object model provided (i.e. XML schema of XMI). Thus

any tool that works with standard XMI will be able to interpret the output generated by

our framework. The details of the model serializer is given below.

Input: The internal representation of the UML model being designed/updated in

the framework.

Output: A standard XMI representation of the UML model provided.

Process: Generating a standard XMI representation of the UML model from its

internal representation. The generated XMI representation is stored in some per-

manent storage.

Usage: The internal representation of the document object model.

When the designer instructs the controller to save the updated model, the controller

requests model serializer to perform the task. The model serializer reads the internal

representation of the model and generates the corresponding XMI representation based

on the content of the DOM tree. The generated XMI representation is then stored in the

permanent storage.

5.2.4 NFR Manager

This component is the most important part of our framework. The NFR manager provides

all of the mechanisms for working with our proposed language. The module allows a

designer to specify new NFR templates and SIGs, to store them in NFR repository, and
CHAPTER 5. IMPLEMENTATION ARCHITECTURE 57

to incorporate NFRs into a UML model. The important submodules of the NFR manager

are described below.

NFR Template Builder/Editor

Input: An existing NFR template from repository or None.

Output: A reusable NFR template specified in our proposed language.

Process: Providing an interactive visual template builder which designers can use

to construct new NFR templates. If an existing template is provided as input, this

module can work as a template editor.

SIG Builder/Editor

Input: An existing SIG or None.

Output: An internal representation of a SIG.

Process: Providing an interactive visual builder which designers can use to con-

struct new SIGs. If an existing SIG is given as input, this module can work as a

SIG editor.

Usage: NFR template builder/editor.

NFR Repository Manager

Input: A request for action (ususally from controller).

Output: None.

Process: Providing access to the repository of reusable NFR templates and per-

forming actions as requested. Typical actions include adding, deleting or updating

NFR templates.

Usage: SIG builder/editor.


CHAPTER 5. IMPLEMENTATION ARCHITECTURE 58

NFR Parser

Input: An internal representation of a UML model.

Output: An (updated) internal representation of the input model with NFRs spe-

cially marked.

Process: Identifying incorporated NFRs in the input model and mark them ac-

cordingly.

NFR Integrator

Input: An internal representation of a UML model, the joining point and the NFR

to join.

Output: An updated internal representation of the input model with the specified

NFR incorporated appropriately.

Process: Incorporating the specified NFR into the input model at the specified

joining point. This involves interpreting the NFR template specification.

Usage: Internal representation of DOM tree.

NFR Template Compiler

Input: An NFR template represented in the proposed High Level Language.

Output: A Java class corresponding to the specified NFR.

Process: Compiling the NFR template to generate a corresponding Java class and

store the class in the NFR Library/Repository.

Once the necessary NFRs for the input model have been identified, most of the sub-

sequent operations are carried out by the NFR manager. If the NFR is available in the

NFR Library, the designer can use the NFR Integrator to incorporate the NFR into the
CHAPTER 5. IMPLEMENTATION ARCHITECTURE 59

model. Otherwise the designer can use the NFR template builder and the SIG builder to

construct the new NFR. Figure 5.4 gives a snapshot of the NFR template builder. The

lower left panel lists the commands in the template while the upper left panel lists the

expected parameters. The lower right panel represents the entire template with com-

plete description of each command. The menu assists the template designer to specify

individual commands by providing the relevant information.

Figure 5.4: The Snapshot of the NFR Template Builder


CHAPTER 5. IMPLEMENTATION ARCHITECTURE 60

Figure 5.5 shows a snapshot of the SIG Builder/Editor. The constructed SIG is

displayed as a hierarchical structure as well as in a visual representation.

Figure 5.5: The Snapshot of the NFR Editor

The newly constructed NFR specification is then compiled by the NFR template

compiler to produce the corresponding Java class. The newly constructed NFR appears

in the NFR Library/ Repository. The designer can now integrate the NFR into the model

by using the NFR integrator (via the controller ).


CHAPTER 5. IMPLEMENTATION ARCHITECTURE 61

5.2.5 Visualization Engine

The visualization engine is responsible for all kinds of visualization operation. For exam-

ple, it does the visualization of a Soft-goal interdependency graph and any type of UML

diagrams implemented in the framework. The visualization of each type of the UML

diagram is done by inserting a separate component for that purpose. For this thesis, the

implemented UML diagrams are class and activity diagram. We use different colors for

expressing the NFR representation of the UML model with the main UML model. In

the hierarchical representation of the model, we use a separate notation (NFR cloud) to

denote the NFR with the main model. Figure 5.6 shows a snapshot of a class diagram

with one NFR attached to it. For the visualization of the SIG we use the notations used

in the NFR Framework [18].

NFR
related
Class

NFR in
hierarchical
representation
of the model

Figure 5.6: The Snapshot of A Model with A NFR Attached to it


CHAPTER 5. IMPLEMENTATION ARCHITECTURE 62

Further details of this component are given below.

Input: Internal representation of a UML model (or any component of it), or a SIG.

Output: None.

Process: Rendering the input component(s) in a visually understandable format

and allowing manipulation of the components.

5.3 Implementation Issues

We noted earlier that we use Java Programming language to implement the prototype.

Here are some features of Java which we use extensively in the implementation.

5.3.1 Dynamic Class Loading

To support the Plug-in architecture, Java offers the dynamic class loading where the

program loads the available Plug-ins during start up. For this purpose, each of the Plug-

ins needs to implement a common interface to be loaded during run-time. We provide a

public interface for the Plug-ins. We implement each of the NFRs as a separate class where

those classes need to implement that published interface provided by our prototype. This

actually offers the advantage of adding other NFRs in the NFR library by implementing

the interface.

5.3.2 Java Component

Each of the components of our prototype are separate Java classes. The major advantage

of this is that if we change any class, we do not need to change other classes and re-

compile the whole program. Where, in C/C++ or other programming languages, the
CHAPTER 5. IMPLEMENTATION ARCHITECTURE 63

Size of XML Schema (KB) Parsing Time (ms) Number of Nodes in DOM Tree
185 844 8023

Table 5.1: Time and Space Complexity for Generating DOM Tree

whole program comes into one exe file and changing any of the component, requires to

re-compile the whole program.

5.4 Evaluation of the Prototype

In this section, we evaluate the time and space complexity of the prototype. The prototype

is built with JBuilder 4.0 with J2SDK1.4.2 06 on a Pentium 4, 1.60 GHz Machine with

256 MB RAM. We categorize the time and space complexity into DOM time and space

complexity and Input time and space complexity. In addition to these, we also measure

the integration time complexity of two NFRs with a UML model. The data is presented

in section 6.5 of Chapter 6. The following subsections describes them further.

5.4.1 DOM Time and Space Complexity

As we mentioned earlier, we parse the XML schema of UML model to get the DOM

(Document Object Model) tree for the validity checking of the input of the framework.

The size of the XML schema, provided by OMG, is 185 kb. We measure the time and

space that is required to parse the XML schema and to store it, respectively. The time

required to parse the schema is 844 ms. We store the DOM tree using the JTree data

structure of Java. The parsed DOM tree has 8023 nodes in total. Table 5.1 shows a

summary of the result of parsing the XML schema.


CHAPTER 5. IMPLEMENTATION ARCHITECTURE 64

Size of Input XMI File (KB) Number of Classes Parsing Time (ms)
12 20 47
20 40 63
32 60 94
40 80 109
52 100 125

Table 5.2: Time and Space Complexity for Interpreting Input Models

5.4.2 Input Time and Space Complexity

We measure the time and space complexity of some input models as a function of the

number of classes. We started with a model containing 20 classes. We parse several

models containing up to 100 classes. Table 5.2 shows a summary of the size of the input

files and time to parse them.

140
120
Parsing Time(ms)

100
80
60
40
20
0
20 40 60 80 100
Num ber of Classes

Figure 5.7: Graph of Parsing Time of Several Input Models

In terms of time requirements, we also graph the relationship between size of the input

files in terms of number of classes and the parsing time. Figure 5.7 shows the graph.
CHAPTER 5. IMPLEMENTATION ARCHITECTURE 65

5.5 Summary

This chapter presents the implementation architecture of the framework. We implement

the UML class and activity diagram as a proof of concept of the framework. The prototype

also validates the proposed language for building the UML representation of the NFRs.

Finally, we present some time and space complexity of the prototype to evaluate the

framework.
Chapter 6

Case Study

The case study we have chosen is a part of the Credit Card System described in [18].

Here is short summary of this system:

“We consider an information system for a credit card company. A body of

information on cardholders and merchants is maintained. The system must

meet security requirements properly to ensure both external and internal secu-

rity of the system. Besides, in this highly competitive market, it is important

to provide fast response time for sales authorization. To reduce losses due to

fraud, lost and stolen cards must be invalidated as soon as the bank is notified.”

Here, we present two NFRs: security and performance of that system. The rational for

choosing these two NFRs is threefold: i) these two NFRs are very important for the Credit

Card System, ii) the NFR framework provides the evaluated SIG for achieving these two

NFRs [18], and iii) the solutions for these NFRs demonstrate the use of operations from

most categories in our High Level Language (HLL) described in Chapter 4.

As described in Chapter 3, we start to apply our framework on the above Case

Study System by: identifying the requirements for the system (both Functional and

66
CHAPTER 6. CASE STUDY 67

Non-Functional Requirements), modeling the Functional Requirements using UML dia-

grams and modeling the Non-Functional Requirements using NFR Framework and our

proposed HLL, and integrating the Non-Functional Requirements with the Functional

Requirements of the system. The next sections describe how we apply our framework on

this case study.

6.1 Identifying Requirements

We identify some Functional and Non-Functional Requirements of the case study system

after a thorough review of literature [19, 20, 21, 41, 43]. A subset of identified FRs are:

i) maintaining information on sales, card holders, merchants, ii) authorizing transactions,

iii) updating accounts, iv) cancelling stolen cards, v) calculating reward points per card,

vi) calculating air miles per card if the card has such offering, vii) calculating percentage

of cash back and so on. A subset of identified NFRs are: i) security of the transaction,

and ii) quickly cancelling the card if it is reported as stolen. The system may have other

FRs and NFRs. However, we select these subsets of FRs and NFRs for this particular

case study.

6.2 Modeling FRs

We mentioned in Chapter 3 in section 3.1.2 that we use class diagrams as the primary

representation of the Functional Requirements and activity diagrams to show the flow of

control of activities of several operations of the class diagram. Figure 6.1 shows a partial

class and activity diagram of the case study system.

Here are descriptions of the several classes of Figure 6.1:


CHAPTER 6. CASE STUDY 68

CardHolder Transaction
CreditCard
−.....
−Name: String
...... −CardType: String
−Address: String
−PhoneNumber: int 1 * − ExpiryDate: date +Cancle−Card(c : CreditCard)
−CustomerID: long −CreditLimit: int ....
+Do−Transaction(c: CreditCard): void
−.... −CardNumber: String +...
−AnnualFee: int
+.... −Status−of−card: int
−CustomerID: long
−...

+.....

GoldCard RegularCard

−RewardPoints: int −PercentageofCashBack: float


−AirMiles: long
−... −TotalCashBack: float
−...
+CalculateRewardPoints(): int
+CalculateAirMiles(): long +CalculateCashBack(): float
+....
+...

Activity Diagram for Do−Transaction(c:CreditCard) Activity Diagram for Cancel−Card(c:CreditCard)

A card is reported as sloten


or lost
Validate Sender

Validate CardNumber from


CreditCard Information
Yes No

Yes No

Validate Card Info

Invalid Card Status


as early as possible
Yes No

Send negative acknowledgement


Update Info to sender

Send acknowledgement
to sender

Figure 6.1: A Partial Class and Activity Diagram for the Case Study System
CHAPTER 6. CASE STUDY 69

• Class “CreditCard”: the class“CreditCard” is a generalization of two types of

cards, namely: i) Gold card, and ii) Regular card. This Class also has some at-

tributes such as card number, customer ID, and card types(either gold or regular).

In addition to these, it also keeps the information of the expiry date, credit limit,

annual fee, and status (either active or inactive) of a card.

• Class “CardHolder”: The class “CardHolder” keeps the necessary information

of a particular card holder. this class keeps the information of name, address, phone

number, customer ID and so on for a particular card holder. The class “CardHolder”

has a one-to-many association with the class “CreditCard”. It means that a card

holder can have several credit cards where a particular credit card is assigned to a

specific card holder.

• Class “GoldCard”: The class “GoldCard” keeps the information related to a

gold type card. In addition to the information of class “CreditCard” it also keeps

the information of reward points and air miles of a particular gold card.

• Class “RegularCard”: The class “RegularCard” keeps the information related

to a regular type card. In addition to the information of class “CreditCard” it also

keeps the information of percentage of cash back of a particular regular card.

• Class “Transaction”: The class “Transaction” handles the operations related to

any transaction of the card. It has an operation “Cancel-Card(c:CreditCard)” to

invalidate the card status, if the card is reported as stolen or lost. The opera-

tion “Cancel-Card(c:CreditCard)” uses the class “CreditCard” as an argument in

the signature of it. It causes the dependency relation between the class “Trans-

action” and “CreditCard”. The class “Transaction” has another operation “Do-

Transaction(c:CreditCard)” which handles the transaction for a particular card.


CHAPTER 6. CASE STUDY 70

We only show the activity diagrams of the major operations like “Do-Transaction(c:CreditCard)”

and “Cancel-Card(c:CreditCard)”. The description of the activity diagrams are as fol-

lows:

• Activity Diagram for Operation Do-Transaction(c:CreditCard): This op-

erations will first validate a sender on a transaction request. If it is a valid sender,

it will validate the card information using the class “CreditCard”. Otherwise the

process will terminate. If the card is a valid one, it will update the card information

according to the transaction and will send an acknowledgement to the sender about

the transaction. If the card is not valid, it will send an negative acknowledgement

to the sender and will terminate the process.

• Activity Diagram for Operation Cancel-Card(c:CreditCard): If a card is

reported as stolen or lost, this operation will first validate the card information

using the information stored in class “CreditCard”. If it is a valid card, it will

invalidate the attribute status-of-card. Otherwise, the process will terminate.

6.3 Modeling NFR: Security

Security is a big concern in building an information system. Like money or any other

form of property, it is an asset of an enterprise. An information system may be useless if

it does not satisfy security constraints property. The lack of security in a software system

may cause a violation of privacy, financial loss or even, in extreme case the loss of human

life.
CHAPTER 6. CASE STUDY 71

6.3.1 Overview of Security Softgoal Graph

Figure 6.2 shows a softgoal Interdependency Graph for achieving NFR security. The graph

represents a comprehensive set of software attributes that relate to system security. The

graph was compiled after a thorough review of the literature [5, 18, 19, 22, 44, 50]. In

Figure 6.2, single arc represents AND relation.


Security

Availability Integrity Confidentiality

Completeness Accuracy
Internal External
Confidenciality Confidentiality

InternalCinsistency ExternalConsistency

Figure 6.2: A Partial SoftGoal Interdependency Graph for Security Quality Attribute

Figure 6.2 shows that security can be achieved by ensuring “availability”, “integrity”,

and “confidentiality”. “Availability” means guarding against the interruption of service

while “integrity” means guarding against unauthorized updates or other tampering. How-

ever, “confidentiality” means guarding against unauthorized disclosure. “Integrity” can

be further achieved by ensuring the “completeness” and “accuracy” of information where

“accuracy” can be further decomposed into internal and external consistency. Again,

“confidentiality” can be achieved by ensuring both internal and external confidentiality.

To achieve security, the NFR framework refines the security softgoal into a set of

operationalizing softgoals by applying operationalization methods. Each of the opera-

tionalizing softgoals appears as a technique in the target design. Figure 6.3 shows a pos-

sible set of security operationalizing methods in a softgoal interdependency graph. The

graph was compiled after a through review of literature [22, 35, 37, 45]. In Figure 6.3,
CHAPTER 6. CASE STUDY 72

a single arc represents an AND relation while a double arc represents an OR relation.

For example, to protect against malicious access to important information on the system,

“alarm” can be used to notify the proper authorities of such access. Here “alarm” can

work as a triggering method to notify of any unwanted situation. Again, “alarm” can be

implemented either by a physical device (a physical alarm) or by a program generating

messages to the proper authorities (a soft alarm).

To ensure authentication, any of the “Biometrics”, “Card key” or “Password” meth-

ods can be used. “Biometric” can be implemented either by “finger print verification” or

by “voice recognition”. Again “password” technique can be used either for single sided

authentication (single login-time authentication from agent side) or for mutual authenti-

cation (ensuring mutually the identity of both agent and system).

Security Operationalization Methods

Perturbation VirusFilter AccessAuthorization Auditing Alarm Encryption RapidPosting

AcessRuleValidation
Identification
Authentication PhysicalAlarm SoftAlarm

Subsystem Manual
AuditTrailBased NoiseRemoval NoiseAddition
Simple

Biometrics
Password

CardKey

FingerPrintVerification
VoiceRecognition
OneSided Mutual
Authentication Authentication

Figure 6.3: A Catalogue of Security Operationalization Methods

Once the developers agree on a particular technique to apply to a system, they need to

reflect the technique in the design of the system. We assume, in our unified model-based
CHAPTER 6. CASE STUDY 73

approach, that there would be methods that would need to be very secure. The security

techniques will be added as Non-Functional Requirements (NFR) with these methods.

Upon some guard condition or other constraints based on the type of the system, these

methods will use these security techniques to satisfy the NFR security of the system.

These newly added security methods will perform extra security checking of the original

function.

6.3.2 Evaluated SIG for Security from NFR Framework

Now, we focus on how the NFR framework [18] evaluates the SIG for security on the

particular Credit Card System. In the case study system, the money transactions are

categorized into transactions in large amount and transactions in small amount. The

security of the gold account is more important than the regular account. To ensure the

internal security of the Credit Card Company, whenever there would be a transaction

with a large amount of money from gold account, a notification (either physical or soft

alarm) should be given to the higher level authority to authenticate the transaction. In

particular, the operation “Do-Transaction(c:CreditCard)” should be very secured for gold

accounts.

After analyzing all the positive and negative impacts of design decisions, NFR frame-

work [18] gives us a solution for achieving internal security for gold accounts which is

shown in Figure 6.4. According to the solution, a soft alarm method can be attached

with the “Do-Transaction(c:CreditCard)” to check the proper authorization of the trans-

action of gold accounts with high spending. Now, we need to map this solution to the

design level using UML diagrams.


CHAPTER 6. CASE STUDY 74
SIG
Legend
InternalConfidentiality
[Account] NFR Softgoal
Do−Transaction(c:CreditCard)
+
Accuracy Subclass Op Softgoal
[Account]
+ Claim Softgoal
AccessAuthorozation InternalConfidentiality
[Account] [GoldAccount] Contribution Link
InternalConfidentiality + Satisfied
[RegularAccount] W Claim
["Design Guidelines: X Denied
Identification
++ Gold accounts are important"] Target

AccessRule Prioritization Functional


Validation + Requirements
Authentication !InternalConfidentiality
[GoldAccount] + Positive Contribution
{Critical} ++ More Positive Contribution
Individual Attributes ! Critical softgoal

Password !InternalConfidentiality
X [Account] [GoldAccount.lowSpending]
Biometrics {Critical}
!InternalConfidentiality
CardKey [GoldAccount.highSpending]
+ {Critical}
Claim
++ ["Design Guidelines:
SinglePassword + +
[Account] High Spending is very critical"]
!!InternalConfidentiality
+ + [GoldAccount.highSpending]
+ {veryCritical}
++ Security Level
MultiplePassword
[GoldAccount !!InternalConfidentiality
[GoldAccount.highSpending]
.highSpending] {SecurityLevel=mandatory}
Identification,Password
&AccessRuleValidation
SoftAlarm
X PhysicalAlarm

CommunicationScriptWithTrigger
Transaction

Figure 6.4: SIG for a Confidential Account

6.3.3 A Unified Model for NFR Internal Security

One of the possible ways to reflect the solution of achieving security in the UML represen-

tation of the system may be to add a new operation for particular security techniques(for

example, Generate-Alarm()) as a supportive operation for “Do-Transaction(c:CreditCard)”.

An activity diagram is needed to describe the flow of activity for both operations. “Do-

Transaction(c:CreditCard)” may already have an activity diagram. There may be two

approaches here:

• One way may be to modify the activity diagram. One disadvantage of this approach

is that, if other operations use the operation “Do-Transaction(c:CreditCard)”, the

change of the activity diagram should also be propagated to those operations.

• The other way may be to rename the original “Do-Transaction(c:CreditCard)” oper-

ation as “UnSecured-Do-Transaction(c:CreditCard)”) and insert another operation


CHAPTER 6. CASE STUDY 75

named Do-Transaction(c:CreditCard) which calls the “UnSecured-Do-Transaction”

(the old Do-Transaction(c:CreditCard) operation). However, if the amount of the

transaction is large and the card type is gold, it calls the Generate-Alarm() to

notify the higher level authority. In this way we are keeping the original activ-

ity diagram of the Do-Transaction(c:CreditCard) by renaming the operation as

Unsecured-Do-Transaction(c:CreditCard) and creating a new activity diagram for

the Do-Transaction(c:CreditCard) which will now assure the security of the account

by applying “alarm” technique.

For this case study, we apply the the second approach. However, our framework

provides the flexibility to support any of the approaches.

6.3.4 NFR Template for NFR Security

Once we have a unified model for the NFR representation, we need to build the template

proposed in our High Level Language, discussed in Chapter 4, for creating the corre-

sponding UML representation of that NFR. As described in subsection 6.3.3, the general

approach for achieving internal security may be to insert a new method for applying

the security techniques as supportive functionality for the operations which need to be

secured. Activity diagrams can also be created for each of these security methods to

describe the functionality. For example, there may be a method “X ” in the class diagram

of a system which needs to be more secured upon some constraints.

For that security purpose, whenever the developers decide to use any of the security

techniques as shown in Figure 6.4, they can insert a new operation “Y ” for applying that

security technique in the same class that contains the operation “X ”. The operation X

needs to be renamed as Z and another operation needs to be inserted with the same name

as X where the newly created “X ” will perform the same operation as the previous one,
CHAPTER 6. CASE STUDY 76

AlgorithmAddSecurity(O) =
Input :
O : An operation of Class C where O needs to be secured
Output :
Class C with NFR Security attached as combination of new inserted operations
with activity diagrams.
Variables :
G: The constraints for security.
Method :

1. Create an Operation O1 in C for implementing the selected security technique

2. Rename the operation O as O2

3. Create a new operation O in C where O will now use O1 in addition to its own
functionality if G is satisfied

4. Create an activity diagram A1 for O1

5. Create an activity diagram A2 for new O

Figure 6.5: Add NFR Security Algorithm.

except it will now also use method “Y ” for the security checking upon some constraints

of the transaction. Also activity diagrams need to be created for the methods “Y ” and

“X ” to show the flow of activity for describing the security technique.

Based on this general approach, we describe an algorithm to add NFR security. We

call it AddInternalSecurity(O). The algorithm can be informally described as shown in

Figure 6.5

Figure 6.6 shows the commands according to algorithm AddInternalSecurity(O) in

our proposed High Level Language to create a template to securing any method by gen-

erating a soft alarm technique.

The developers need to save this template in the NFR repository for future use. This
CHAPTER 6. CASE STUDY 77

is actually the reusable NFR in our framework. The template described in Figure 6.6

is an ordered set of commands for building two operations inside a class of the main

model, and two activity diagrams for these operations. However, the necessary parameters

for creating these operations and activity diagrams need to be supplied during weaving

process. The actual operations and the diagrams will be created after specifying all those

parameters which is described in the next section.

6.3.5 Integration of NFR Security

Now that the NFR Library/Repository contains the NFR internal security, if the devel-

opers want to integrate this NFR with an operation that needs to be secured, they can

integrate the NFR by supplying all the parameters dynamically for creating the diagrams.

During integration process, the template works in the following way:

• Developers specify the input i.e the join-point for the NFR (Step 0,1). Here the

expected join-point is an operation of the main model. Then the owner class of this

operations is determined in Step 2 to create other security related operations in the

same class.

• In Step 4 an operation is created with the given name that the developers specify

dynamically at Step 3. Suppose the developers specify this operation name as

Generate-Alarm() in this case. Then the activity diagram for Generate-Alarm()

will be created for which commands are specified from Step 8 to Step 13.

• Again, the original Do-Transaction(c:CreditCard) operation is renamed as Unsecured-

Do-Transaction(c:CreditCard) in Step 6 by setting it’s name property to the new

value. Another operation with the same name as Do-Transaction(c:CreditCard) is

created in the previous class at Step 7.


CHAPTER 6. CASE STUDY 78

0. Input := Operation
1. param0 := Operation

2. result0 := FindAncestorClass(param0)
3. result1 := getDynamicInput
4. result2 := CreateOperation(result0,{<name, result1>, . . .})
5. result3 := getProperty(param0,”name”)
6. result4 := setproperty(param0, ”name”,unsecured- + result3”)
7. result5 := CreateOperation(result0,{<name,result3>,. . .})

(Commands for creating activity graph for method Generate-Alarm())

8. result6 := CreateActivityGraph(result0,{. . .})


9. result7 := CreateStartActivity(result6,{. . .})
10. result8 := CreateActivityState(result6,{”Generate message
to notify manager”,. . .})
11. CreateActivityTransition(result6, result7,,result8,{. . .})
12. result9 := CreateActivityEnd(result6,{. . .})
13. result10 :=CreateActivityTransition(result6,result9,result10)

(Commands for creating activity graph for method


new Do-Transaction(c:CreditCard) with security )

14. result11 := CreateActivityGraph(result0,{. . .})


15. result12 := CreateStartActivity(result11,{. . .})
16. result13 := CreateActivityState(result11,{”Call method + result3”})
17. CreateActivityTransition(result11, result12,result13,{. . .})
18. result14 := CreateBranch(result11,{. . .})
19. CreateActivityTransition(result11,result13,result14,{. . .})
20. result15 := CreateActivityState(result11,{”Call Operation+ result2”,. . .})
21. result16 := CreateMerge(result11,{. . .})
22. result17 := getDynamicInput(”Condition for branching”)
23. CreateActivityTransition(result11,result15,result16,{”[result17]”,. . .})
24. CreateActivityTransition(result11,result14,result16,{”[else]”,. . .})
25. result18 := CreateActivityEnd(result11,{. . .})
26. result19 := CreateActivityTransition(result11,result16,result18)

27: Output := result2, result5,result6, result11

Figure 6.6: NFR Template for Achieving Internal Security


CHAPTER 6. CASE STUDY 79

• The activity diagram for this new Do-Transaction(c:CreditCard) is created at Step

11-26 after developers specify the guard condition dynamically at Step 22.

Transaction

−......

+Cancel−Card(c:CreditCard)
+Do−Transaction(c:CreditCard): void
+Generate−Alarm(): void New inserted methods
+UnSecured−Do−Transaction(c:CreditCard): void Re−named Do−Transaction(c:CreditCard)
+....

Activity Diagram for Generate−Alarm() Activity Diagram for


new Do−Transaction(c:CreditCard)

Notify manager by generating a message


Call UnSecured−Do−Transaction(c:CreditCard)

[Account is Gold and


spending is high] [else]

Call
Generate_Alarm()

Figure 6.7: UML Diagrams After Weaving Internal Security

Figure 6.7 shows the new class diagram with two new methods inserted and two

activity diagrams describing the operations of these two methods. The activity diagrams

for the operations “Do-Transaction(c:CreditCard)” and “Cancel-Card(c:CreditCard)” are

omitted for simplicity.

As shown in Figure 6.7, the method “Generate-Alarm()” is inserted, Do-Transaction(c:CreditCard)

is renamed “UnSecured-Do-Transaction(c:CreditCard)”, and a new Do-Transaction(c:CreditCard)

is created in the class “Transaction”. Two activity diagrams are created for these two

operations. The activity diagram for “Generate-Alarm” describes generating a message

to the proper authorities (Soft-Alarm). The activity diagram of the newly inserted “Do-

Transaction(c:CreditCard)” depicts that this method will first call the Unsecured-Do-
CHAPTER 6. CASE STUDY 80

Transaction(c:CreditCard) which is the original “Do-Transaction(c:CreditCard)”. How-

ever, if the transaction is with the gold account, with large amount of money, it will notify

the manager by calling the operation named “Generate-Alarm”.

6.4 Modeling NFR: Performance

Generally the performance measurement is done when the product is near to being com-

pleted, which may lead to a major redesign to correct eventual performance problems [38].

That is why we consider performance a major concern. In literature, we find several clas-

sifications of attributes of performance requirement. Daniel [38] et al. described the

attributes of performance as response time, throughput, availability, reliability, security,

scalability and extensibility. Jain [34] defined the attributes of performance as response

time, throughput, utilization, reliability and availability.

Performance cross-cuts the whole system globally. Due to this global nature, perfor-

mance requirement is quite difficult to achieve [42]. While we can add the security require-

ment as an extra module to the system (where the module does the necessary checking

to ensure the security of the system), performance needs to be considered throughout the

entire design phases.

6.4.1 Overview of Performance Softgoal Graph

Figure 6.8 shows a softgoal interdependency graph of several alternatives for achieving

the performance softgoal. The graph was compiled after a thorough review of the litera-

ture [18, 42, 49]. In the Figure 6.8, a double arc represents an OR relation. This shows

that performance can be achieved by applying any of the “Early Fixing”, “Late Fixing”

or “Execution Ordering” techniques, each of which are elaborated on below:

• Early Fixing: Making an early connection (e.g, at compilation time) between an


CHAPTER 6. CASE STUDY 81

SPE−Based Performance Operationalization Methods

Early Fixing Late Fixing Execution Ordering

PerformFirst
CompressedFormat
Indexing PerformLater
DynamicOffsetDetermination
UncompressedFormat
StaticOffsetDetermination PerformLast
ReducedRunTimeOrganization

Figure 6.8: A SoftGoal Interdependency Graph for Performance Quality Attribute

action and the instructions that achieve it. “Early Fixing” helps time performance,

while negatively impacting space performance. The techniques for achieving “Early

Fixing” may be: i) StatisOffsetDetermination( determines offset statically rather

than at execution time), ii) Indexing, and iii) UncompressedFormat. All these three

techniques help in time performance while “Indexing” and “UncompressedFormat”

effects the space performance negatively.

• Late Fixing: The opposite of ”Early Fixing”, making connection run-times be-

tween an action and the instructions that achieve it. The techniques for achieving

“Late Fixing” may be: i) DynamicOffsetDetermination, ii) CompressedFormat, and

iii) ReduceRunTimeReorganization. “Late Fixing” techniques help space perfor-

mance, but negatively impact time performance.

• Execution Ordering: Making an ordering among the tasks based on the priority

of them. To satisfy time performance, a developer may selectively state the relative

order for the execution of a set of tasks. The idea is to perform the critical and

dominant tasks first and to perform the rest later.


CHAPTER 6. CASE STUDY 82

Layer 3 Legend
ResponseTime Cancel(Card)
Transaction Operation
[Cancel(card),3] NFR Softgoal

+ Claim Softgoal
ResponseTime
Components(Cancel(card)),3] Op Softgoal
Operation
Components ResponseTime
ResponseTime [OtherOperations(Cancle),3] Op target Link
[access(attributes(card),3] −−
Claim ++ X Claim
["Access imp for cancellation",3] ["Other Ops not imp for cancellation"] Target
++
!ResponseTime U ResponseTime Functional
[access(attributes(card),3]{critical} [otherops(Cancle),3]{non−critical}
Requirement
Individual ResponseTime
Attributes ResponseTime Satisfied
[access(Card.otherattrs),3]
[access(Card.Status),3]
++ −− Claim U Undecided
Claim + X
["Status imp for Cancellation"] ++ ["Otherattrs not imp"]
U ResponseTime Contribution
!ResponseTime [OtherOperations(Cancel),3]
[access(Card.Status),3]{critical}
Entity Management X Denied
ResponseTime
[update(Card.Status),3]{critical} ResponseTime
[retrieve(Card.Status),3]
Claim["Updating status is ++ Claim["Retrieve status is not
imp for cancellation",3] ++ X −−
imp for cancellation",3]
!ResponseTime X ResponseTime
[Update(Crad.Status),3] [retrieve(Card.Status),3]{non−critical}
{critical} + −−
PerformLater
PerformFirst [retrieve(Card.Status),3]
[Update(Card.Status,3] ++
Update done in Cancellation(Card)

Layer2 ResponseTime
(Attributes) [Update(Card.Status),2] Storage of
+
ResponseTime Card Status
[implementation Components(Update
(Card.Status)),2]

ResponseTime ResponseTime
(findOffset(Card.Status),2] [access(attributes(card),2]
+ +
Implementation
Components FewAttrPerTuples
StaticOffsetDetermination
[Card.Status,2] [Card.Status,2]

Selective Attribute Grouping of Card Status

Figure 6.9: A SIG Performance for Credit Card System


CHAPTER 6. CASE STUDY 83

To ensure high performance, one or more of these techniques shown in Figure 6.8 can

be applied. For this particular case study, we focus on the Execution Ordering technique.

Here performance requirements state that, if the card is stolen, the Cancel(Card) oper-

ation must update the card status as “invalidated” as soon as possible to disallow all

unauthorized purchases. Figure 6.9 shows an evaluated SIG for achieving fast response

time for Cancel(Card) operation.

Figure 6.9 shows that to achieve the fast response time of the Cancel(Card) operation,

the NFR framework may use the ”Perform First” technique to cancel card status and the

”Perform Later” technique for other tasks (such as updating other attributes, printing a

transaction log and so on).

In addition to the “Perform First” technique, the NFR framework also suggests using

“SelectiveAttributeGrouping” to achieve fast response time for Cancel(card) operation in

the second layer of decomposition of the NFR performance. The idea is to store fewer

attributes per tuple by constructing a smaller data structure to reduce the time required

to access the data. Here the response time can be made faster if the status values of all

cards can be stored together in a separate place with few other attributes (for example

with Card Number as primary key to search the database) instead of storing them with

all other attributes (for example, customer name, address, and so on). As a result the

search space will be reduced and the status of card can be found quickly to perform the

Cancel(Card) operation.

6.4.2 A Unified Model for Achieving FastResponseTime

One of the ways to reflect the solution from the NFR framework may be to make a

smaller version of the class “CreditCard” for “Cancel-Card(c:CreditCard)()” as this op-

eration only needs the status of card information. The attribute “Status-of-Card” can be

separated and it can be inserted to a new class featuring “Card-Number” as its primary
CHAPTER 6. CASE STUDY 84

Algorithm AddF astResponseT ime(O, C) =


Input :

O : An operation of a class C1 where the response time of O should be very high

C : A class that O is dependent on


Output :

A smaller version C2 of class C to reduce search spaces.

Variables :
A1: A list of attributes to separate from C
A2: A list of attributes to use in C2 without separating them from C.

Method :

1. Create a new class C2

2. Select group of attributes A1 from C

3. For each attribute a1 ∈ A1 do


Insert Attribute a1 in C2
Delete Attribute a1 from C
End for

4. Select Other Attributes A2 from C

5. For each attribute a2 ∈ A2 do


Insert attribute a2 in C2
End for

6. Create a dependency from class C1 to C2

7. Change the parameter for O as O will now depend on C2 instead of C

Figure 6.10: Add NFR FastResponseTime Algorithm.


CHAPTER 6. CASE STUDY 85

key to uniquely find the status of a particular card. The parameter of operation “Cancel-

Card(c:CreditCard)()” can be changed to “Cancel-Card(c:Reduced-CreditCard)()” to

force it to use the smaller class.

6.4.3 NFR Template for FastResponseTime

Now we describe an algorithm to add NFR FastResponseTime.

We call it AddF astResponseT ime(O, C). The algorithm can be informally described

as shown in Figure 6.10.

0. expect parameter := method, class


1. param0 := method, param1 = class

2. result0 := getProperty(param1, ”name” )


3. result1 := FindAncestorPackage(param1)
4. result2 := CreateClass(result1, {Reduced- + result0, public...})
5. result3 := FindAncestorAttribute(param1)
6. result4 := getSelectedInput(result3, ”Attributes to separate”)
7. result5 := getSelectedInput(result3, ”Attributes to use as primary key”)
8. For Each Element X in result4 do
9. result6 := getProperty(X)
10. result7 := CreateAttribute(result2, {result6})
11. Delete(X)
12. End For

13. For Each Element X in result5 do


14. result8 := getProperty(X)
15. result9 := CreateAttribute(result2, {result8})
16. End For

17. setProperty(param0, ”parameter class”, result2)


18. result10 := FindAncestorClass(param0)
19. result11 := CreateDependency(result2, result10, result2,{. . . }
20. Output: result2, result11

Figure 6.11: NFR Template for FastResponseTime


Here it is important to note that we did not delete the original dependency relation of

class Transaction with class CreditCard while creating new dependency relation with the

new class Reduced-CreditCard. We assume that other operations of class Transaction

may use class CreditCard. However, if the developers find that no other operation except
CHAPTER 6. CASE STUDY 86

Cancer-Card(c:CreditCard) uses class CreditCard, they can delete this dependency.

Figure 6.11 shows the commands in our proposed high level language for creating a

template for achieving fast response time. The developers need to save this template in

the NFR Library/Repository.

6.4.4 Integration of NFR Performance(FastResponseTime)

Once the developers have the solution in the Repository for achieving FastResponseTime,

they need to integrate the NFR with the operation for which they want to achieve such

a goal. During the integration process, the template works in the following way:

• First, the developers specify the input i.e the join point of the NFR at Step 0 and 1.

In this case the expected input would be an operation which needs to operate very

fast. The developers also need to specify the class which is used by this operation for

its functionality as a smaller version of this class will be created after the integration

of the NFR FastResponseTime.

• A new class is created at Step 2-4 with the same name of the used class of the

operation (which needs to work fast) but with a prefix “Reduced-” attached to it.

• All the attributes from the used class are extracted at Step 5 and the developers

specify which attributes they want to separate from that class at Step 6. The

developers also specify which attributes they want to use in the smaller version of

the class without separating them from the parent class at Step 7.

• Each of the selected attributes at Step 6 is inserted in the smaller class and is

deleted from the old class at Steps 8-12.

• Each of the selected attributes at Step 7 is inserted in the smaller class. However,

they are not deleted from the old class at Steps 12-16.
CHAPTER 6. CASE STUDY 87

• The parameter of the operation which needs to have FastResponseTime is changed

so that it now uses the smaller class at Step 17.

• Finally a dependency is created between the smaller class and the parent class of

the operation with FastResponseTime at Step 18-19.

Figure 6.12 shows the new class diagram after weaving in NFR FastResponseTime.

The activity diagrams for the operations “Do-Transaction(c:CreditCard)” and “Cancel-

Card(c:CreditCard)” are omitted for simplicity. As shown in Figure 6.12, a new class

named “Reduced-CreditCard” is created to represent a smaller version of class “Cred-

itCard”. The attribute “Status-of-Card” is separated from class “CreditCard” and is

inserted in the new class “Reduced-CreditCard”. Although the attribute ”CardNumber”

is inserted in the class “Reduced-CreditCard”, it is not separated from the parent class

“CreditCard” (as specified in the template). The signature of the operation ”Cancel-

Card(c:CreditCard)” is changed to ”Cancel-Card(c:Reduced-CreditCard)” as this opera-

tion will now use the class “Reduced-CreditCard”. A dependency is also created between

class “Transaction” and “Reduced-Credit-Card”.


CardHolder Transaction
CreditCard

−.....
−Name: String
...... −CardType: String
−Address: String
−PhoneNumber: int 1 * − ExpiryDate: date +Cancle−Card(c : Reduced−CreditCard)
−CustomerID: long −CreditLimit: int ....
+Do−Transaction(c:CreditCard): void
−.... −CardNumber: String +...
−AnnualFee: int
+.... −CustomerID: long
−...

+.....
Reduced−CreditCard

−CardNumber: String
GoldCard RegularCard −Status−of−card: int

−RewardPoints: int −PercentageofCashBack: float


−AirMiles: long
−... −TotalCashBack: float
−...
+CalculateRewardPoints(): int
+CalculateAirMiles(): long +CalculateCashBack(): float
+....
+...

Figure 6.12: UML Diagrams after weaving FastResponseTime


CHAPTER 6. CASE STUDY 88

Name of the NFR Integration Time(ms)


FastResponseTime 63
Security 16

Table 6.1: Time Complexity for Integrating NFRs

6.5 Time Complexity to Integrate NFRs in our Prototype

We measure the time to integrate the performance and security NFRs of our case study

system with the target model. As the NFRs need some dynamic parameters from users

for the integration purpose, we start to calculate the integration time after specifying all

those necessary parameters. Table 6.1 shows a summary of the integration time of the

performance and security NFRs of the Credit Card System.

6.6 Summary

In this chapter we apply our framework in such a way that it covers both the forward

and reverse engineering context. We apply the framework on two NFRs, the performance

and security of a Credit Card System. In the first phase, we designed the UML model of

the Credit Card System with a tool named ArgoUML and generated the XMI from the

model (forward Engineering) [1]. In our framework, we interpreted the UML model of

a Credit Card System from XMI (Reverse Engineering) and identified the performance

and security NFRs which needed to be incorporated into the system. This comprises the

“Identifying Requirements” phase of our framework . Then, we used the NFR frame-

work [18] to decompose these high level NFRs and get the design level solutions for them.

Once we finalized the solutions, we used our proposed High Level Language to transform

these solutions into the proper UML representations. The UML representations of these

solutions are re-usable components which can be further used if other systems need sim-
CHAPTER 6. CASE STUDY 89

ilar UML representations of those NFRs. All these are the steps of the phase “Modeling

Requirements” in our framework. Finally, we integrated the performance and security

NFRs with the target UML model of the Credit Card System, fulfilling the “Integrating

Requirements” phase of our framework.


Chapter 7

Conclusion and Future Direction

Despite the fact that Non-Functional Requirements (NFRs) are very difficult to achieve

and at the same time are expensive to deal with, few research works have focused on them

as first class requirements in a development process. Developers have primarily focused

on the Functional Requirements of the system during the design phase. However, the

key point behind the success of a software system lies in specifying the Non-Functional

Requirements along with the Functional Requirements during the design phase.

Researchers are trying to find ways to specify the NFRs easily during the design

of a software system. Many frameworks and requirements specification languages were

proposed earlier in [13, 15, 28, 29, 54]. Most of the research analyze the problem of

specifying the NFRs in forward engineering context (i.e during software development

process), but, some have focused on the re-engineering perspective (i.e during software

maintenance process [54]). Researchers are also trying to make requirements specification

re-usable to facilitate the software development process and also to make it less time

consuming. Based on our research, we have found no work which provides a mechanism

to make the requirements re-usable in both the forward and re-engineering perspectives

of specifying NFRs.

90
CHAPTER 7. CONCLUSION AND FUTURE DIRECTION 91

We propose a unified modeling framework for specifying Non-Functional Require-

ments and integrating them with the UML representation of a model. The framework

provides a high level language to systematically design re-usable NFRs and to add them

with the FRs of a system in the design phase. As the framework is based on the stan-

dard XMI of the UML model, the advantage of the framework is that it can be used

both for forward engineering and reverse engineering [57]. From this, we have built a

prototype of the whole framework where the weaver supports the NFR design with class

diagrams and activity diagrams. The prototype also provides the advantage of drawing

the Softgoal-Interdependency graph (SIG) and storing the NFR templates in the NFR

library/repository along with the NFR information that comes from the NFR frame-

work. As a proof of concept, we specify two NFRs, namely performance and security, of a

Credit Card System as re-usable components and we integrate them with the Functional

Requirements of the Credit Card System.

7.1 Critical Review of the Thesis

Our approach does has some limitations:

• We apply our framework on two evaluated NFRs: performance and security. We

need to apply the framework for other NFRs, as well. For this purpose we need

more evaluated SIG from the NFR framework to incorporate the solution with the

UML representation of a software system.

• Our framework is heavily dependent on the UML standard. If OMG changes the

standard for the UML model, we need to change our framework accordingly.

• Finally, our proposed High Level Language is heavily based on UML vocabulary. A

major change in UML entities may effect the language.


CHAPTER 7. CONCLUSION AND FUTURE DIRECTION 92

7.2 Future Work

Our current research focuses on incorporating non-functional requirements into the design

of a system represented in standard XMI. However, the operations of the framework do not

rely on any specific property of non-functional requirements. This observation suggests

that the framework can be adapted for other scenarios. Our framework requires that:

• The component to be incorporated is expressible in standard UML notation

• The necessary information for incorporating the component can either be expressed

as a parameter or provided by the designer at the time of incorporating the com-

ponent.

For this thesis, we focused on incorporating the NFRs with the target model. However,

some change propagation analysis can be done in future. For example, an NFR may be

used by several entities of a UML diagram. Deleting such an NFR may make the design

inconsistent. We need to analyze the impact of deleting and inserting an NFR. These

are all implementation issues for the framework that need to be considered in future. In

addition, the following subsections outline some directions possible future research could

go.

7.2.1 Building Reusable Aspects

Aspect is a behavior that cross-cuts several modules of a system [36]. The examples of

aspects may be synchronization, real-time constraints, error checking, object interaction,

memory management, structure and representation of data, and so on. As the aspects can

be expressed using UML, we can make them re-usable components using our framework.
CHAPTER 7. CONCLUSION AND FUTURE DIRECTION 93

7.2.2 Building Reusable Functional Requirements

For this thesis, we focused on the Non-Functional Requirements. However, UML is mainly

used for specifying Functional Requirements. As a result, the same functionality of sim-

ilar systems can be designed as re-usable components using the framework. Examples

for these FRs could include generating a log of events (Audit Trail), performing access

authentication, implementation of triggering and so on. By building such components for

FRs, the previous knowledge of a system can be re-used, saving time for developers.

7.2.3 Specifying Design Patterns at Design Level

Design pattern is defined in [16] as “A design pattern provides a scheme for rening the

subsystems or components of a software system, or the relationships between them. It de-

scribes commonly recurring structure of communicating components that solves a general

design problem within a particular context”. As the design patterns have some common

features, they can be designed as re-usable components. In this context, our framework

can be used to specify the re-usable design patterns using UML models. In particular,

the design patterns that are applicable to existing components of a given model are good

candidates.

7.2.4 Building Components in Component Based Software Engineering


(CBSE)

Over the last few years, Component Based Software Engineering has gained much atten-

tion from the software engineering community. The main concerns of component based

softwares are: i) Developing software systems from pre-existing parts, ii) Reusing those

parts in other applications, and iii) Easily maintaining and customizing those parts to

produce new features. The first challenge for this is to make a high quality reusable com-
CHAPTER 7. CONCLUSION AND FUTURE DIRECTION 94

ponent. Once we have the necessary reusable components with desired non-functional

properties, we can build a highly structured good quality software with these pre-existing

components. Ensuring that the NFRs of the components have been achieved is a pre-

condition for the development of a good quality software system out of those compo-

nents. To build these components with appropriate NFRs, it is essential to attach the

non-functional properties along with the functional properties in the design phase of the

component. Thus, NFRs play a significant role in making good quality components. Our

framework can be used to build quality components by specifying those quality attributes

at the design phase.

7.3 Conclusion

We propose a unified modeling framework for incorporating reusable Non-Functional Re-

quirements at the design phase of a software system. For this incorporation purpose,

we propose a High Level Language which provides a textual notation for visual repre-

sentations of UML diagrams. The framework can be extended to design any re-usable

component which can be specified using UML diagrams.


Bibliography

[1] ArgoUML- a UML Tool. Available at: http://argouml.tigris.org/.

[2] Aspectj. Available at: http://www.aspectj.org.

[3] IBM Research. MDSOC: Software Engineering Using Hyperspaces. Available at:

http://www.research.ibm.com/hyperspace/.

[4] OMG Web Site. Available at: http://www.omg.org/.

[5] Trusted computer systems evaluation criteria. Technical Report DOD 5200.28-STD,

U.S. Department of Defence, December 1985.

[6] Object Management Group. Unified Modeling Language Specification Version 1.3,

1999. Available at: http://uml.shl.com.

[7] XML Schema, 1999-2005. Available at: http://www.w3schools.com/schema.

[8] Document Object Model, November 2000. Available at:

http://www.w3.org/TR/DOM-Level-2-Core/introduction.html.

[9] Xerox Parc, Aspectj home page, Technical Report, 2000. Available at:

http://www.aspectj.org/.

95
BIBLIOGRAPHY 96

[10] João Araújo, Ana Moreira, Isabel Brito, and Awais Rashid. Aspect-oriented

requirements with UML. In Proceedings of the Workshop on Aspect-Oriented

Modelling with UML, Dresden, Germany, September 2002. Available at:

http://lgl.epfl.ch/workshops/uml2002/papers/Rashid.pdf.

[11] Brian Berenbach. Towards a unified model for requirements engineering. In Proceed-

ings of the 4th International Workshop on Adoption-Centric Software Engineering

(ACSE), pages 26–29, Edinburgh, Scotland, May 2004.

[12] Lodewijk Bergmans and Mehmet Aksit. Composing software from multiple con-

cerns: A model and composition anomalies. In Proceedings of ICSE Workshop on

Multi-Dimensional Separation of Concerns in Software Engineering, page 8, Limer-

ick, Ireland, June 2000.

[13] Philippe Du Bois. On the Design and the Use of a Formal Specification Language for

Requirements Analysis. PhD Thesis, Department of Computer Science,University of

Namur, 1995.

[14] Grady Booch, James Rumbaugh, and Ivar Jacobson. The Unified Modeling Language

User Guide. Addison-Wesley, 1999.

[15] Jenis Bubenko. Information modeling in the context of system development. In Pro-

ceedings of International Federation for Information, pages 395–411, North-Holland,

1980.

[16] Frank Buschmann et al. Pattern-Oriented Software Architecture : A System of Pat-

terns. John Wiley and Sons, 1999.

[17] Elliot J. Chikofsky and James H. Cross II. Reverse engineering and design recovery:

A taxonomy. IEEE Software, 7(1):13–17, January 1990.


BIBLIOGRAPHY 97

[18] L. Chung, B. A. Nixon, E. Yu, and J. Mylopoulos. Non-Functional Requirements in

Software Engineering. Kluwer Academic Publishing, 2000.

[19] Lawrence Chung. Dealing with security requirements during the development of

information systems. In Proceedings of Advanced Information Systems Engineering,

pages 234–251, London, UK, 1993.

[20] Lawrence Chung. Representing and Using Non-Functional Requirements: A Process

Oriented Approach. PhD Thesis, Department of Computer Science. University of

Toronto, June 1993.

[21] Lawrence Chung and Brian A. Nixon. Dealing with non-functional requirements:

Three experimental studies of a process-oriented approach. In Proceedings of Inter-

national Conference on Software Engineering (ICSE), pages 25–37, Seattle, Wash-

ington, USA, June 1995.

[22] David D. Clark and David R. Wilson. A comparison of commercial and military

computer security policies. In Proceedings of IEEE Symposium on Security and

Privacy, pages 184–194, Oakland, California, USA, April 1987.

[23] Robert G. Clark and Ana D. Moreira. Constructing formal specifications from infor-

mal requirements. In Proceedings of Software Technology and Engineering Practice,

8th IEEE International Workshop on incorporating Computer Aided Software Engi-

neering, pages 68–75, London, UK, July 1997.

[24] Siobhán Clarke and Robert J. Walker. Composition patterns: An approach to de-

signing reusable aspects. In Proceedings of the 23rd International Conference on

Software Engineering (ICSE), pages 5–14, Toronto, Canada, May 2001.

[25] Luiz Marcio Cysneiros and Julio César Sampaio do Prado Leite. Nonfunctional
BIBLIOGRAPHY 98

requirements: From elicitation to conceptual models. IEEE Trans. Softw. Eng.,

30(5):328–350, May 2004.

[26] Luiz Marcio Cysneiros, Julio César Sampaio do Prado Leite, and Jaime de Melo

Sabat Neto. A framework for integrating non-functional requirements into conceptual

models. Requirements Engineering Journal, 6(2):97–115, April 2001.

[27] Evgeni Dimitrov, Andreas Schmietendorf, and Reiner Dumke. UML-based perfor-

mance engineering possibilities and techniques. IEEE Software, 19(1):74–83, Jan-

uary/February 2002.

[28] Eric Dubois, Jacques Hagelstein, Eugene Lahou, Frank Ponsaert, and Andre Rifaut.

A knowledge representation language for requirements engineering. In Proceedings of

the IEEE Special Issue on Knowledge Representation, volume 74, pages 1431–1444,

October 1986.

[29] Sol J. Greenspan, John Mylopoulos, and Alexander Borgida. Capturing more world

knowledge in the requirements specification. In Proceedings of International Con-

ference on Software Engineering (ICSE), pages 225–235, Tokyo, Japan, September

1982.

[30] Walter Hürsch and Cristina Videira Lopes. Separation of concerns. Technical Report

NU-CCS-95-03, Northeastern University, February 1995.

[31] Wai Ming Ho, Jean-Marc Jézéquel, Alain Le Guennec, and François Pennaneaćh.

UMLAUT: An extendible UML transformation framework. In Proceedings of the

14th IEEE International Conference on Automated Software Engineering (ASE),

pages 275–278, Cocoa Beach, Florida, USA, October 1999.

[32] Wai-Ming Ho, Jean-Marc Jézéquel, François Pennaneaćh, and Noël Plouzeau. A
BIBLIOGRAPHY 99

toolkit for weaving aspect oriented UML designs. In Proceedings of the 1st interna-

tional conference on Aspect-oriented software development, pages 99–105, Enschede,

The Netherlands, April 2002.

[33] Jean-Marc Jézéquel, Noël Plouzeau, Torben Weis, and Kurt Geihs. From contracts to

aspects in UML designs. In Aspect-Oriented Modeling with UML, AOSD Workshop,

Enschede, Netherlands, April 2002. Available at: http://lgl.epfl.ch/workshops/aosd-

uml/Allsubs/jean.pdf.

[34] Raj Jain. The Art of Computer System Performance Analysis. New York: John

Wiley & Sons, 1991.

[35] Paul A. Karger. Implementing commercial data integrity with secure capabilities.

In Proceedings of IEEE Symposium on Security and Privacy, pages 130–139, April

1988.

[36] Gregor Kiczales, John Lamping, Anurag Menhdhekar, Chris Maeda, Cristina Lopes,

Jean-Marc Loingtier, and John Irwin. Aspect-oriented programming. In Proceedings

of the European Conference on Object-Oriented Programming (ECOOP), volume

1241, pages 220–242. Springer-Verlag, Berlin, Heidelberg, and New York, 1997.

[37] Norman S. Matloff. Another look at the use of noise addition for database security.

In Proceedings of the IEEE Symposium on Security and Privacy, pages 173–180,

Oakland, California, USA, April 1986.

[38] Daniel A. Menascé, Virgilio A. F. Almeida, and Larry W. Dowdy. Performance by

Design: Computer Capacity Planning by Example. Prentice Hall, 2004.

[39] Ana Moreira, Joäo Araújo, and Isabel Brito. Crosscutting quality attributes for

requirements engineering. In Proceedings of the 14th International Conference on


BIBLIOGRAPHY 100

Software Engineering and Knowledge Engineering (SEKE), pages 167–174, Ischia,

Italy, July 2002.

[40] J. Mylopoulos, L. Chung, and B. Nixon. Representing and using nonfunctional

requirements: a process-oriented approach. IEEE Transactions on Software Engi-

neering, 8(6):483–497, June 1992.

[41] Brian A. Nixon. Dealing with performance requirements during the development

of information systems. In Proceedings of the IEEE International Symposium on

Requirements Engineering (RE), pages 42–49, Los Alamitos,CA, January 1992.

[42] Brian A. Nixon. Managing performance requirements for information systems. In

Proceedings of the 1st International Workshop on Software and Performance, pages

131–144, Santa Fe, New Mexico, United States, October 1998.

[43] Brian Andrew Nixon. Performance Requirementsfor Information Systems. PhD

Thesis, Department of Computer Science. University of Toronto, 1997.

[44] Donn B. Parker. Restating the foundation of information security. In Proceedings of

the 8th International Conference on Information Security, pages 139–151, Singapore,

May 1992.

[45] Jeffrey Piccioto. The design of an effective auditing subsystem. In Proceedings of the

IEEE Symposium on Security and Privacy, pages 13–22, Oakland, California, USA,

April 1987.

[46] Terrence W. Pratt and Marvin V. Zelkowitz. Programming Languages Design and

Implementation. Prientice Hall, 2001.

[47] Awais Rashid, Peter Sawyer, Ana Moreira, and Joäo Araújo. Early aspects: a

model for aspect-oriented requirements engineering. In Proceedings of the IEEE


BIBLIOGRAPHY 101

Joint International Conference on Requirements Engineering, pages 199–202, Essen,

Germany, September 2002.

[48] James RumBaugh, Ivar Jacobson, and Grady Booch. The Unified Modeling Language

Reference Manual. Addison-Wesley, 1999.

[49] Connie U. Smith. Independent general principles for constructing responsive software

systems. ACM Trans. Comput. Syst., 4(1):1–31, 1986.

[50] Daniel Sterne. On the buzzword “security policy”. In Proceedings of the IEEE

Computer Society Symposium on Research In Security And Privacy, pages 219–230,

Oakland, California, May 1991.

[51] Sam Supakkul and Lawrence Chung. Integrating FRs and NFRs: A use case and

goal driven approach. In Proceedings of the 2nd International Conference on Soft-

ware Engineering Research, Management and Applications (SERA), pages 30–37,

Los Angeles, CA, May 2004.

[52] Sam Supakkul and Lawrence Chung. A UML profile for goal-oriented and use case-

driven representation of NFRs and FRs. In Proceedings of the 3rd International

Conference on Software Engineering Research, Management and Applications, pages

112–121, Mt. Pleasant, MI, August 2005.

[53] Junichi Suzuki and Yoshikazu Yamamoto. Extending UML with aspects: Aspect

support in the design phase. In Proceedings of the Workshop on Object-Oriented

Technology, volume 1743 of Lecture Notes in Computer Science(LNCS), pages 299–

300, Lisbon, Portugal, June 1999.

[54] Ladan Tahvildari. Quality-Drive Object-Oriented Re-engineering Framework. PhD


BIBLIOGRAPHY 102

Thesis, Department of Electrical and Computer Engineering, University of Waterloo,

Ontario, Canada, August 2003.

[55] Ladan Tahvildari and Kostas Kontogiannis. Improving design quality using meta-

pattern transformations: a metric-based approach. Journal of Software Maintenance

and Evolution, 16(4-5):331–361, 2004.

[56] Ladan Tahvildari, Kostas Kontogiannis, and John Mylopoulos. Quality-driven soft-

ware re-engineering. Journal of Systems and Software (JSS), 66(3):225–239, 2003.

[57] Subrina Tonu and Ladan Tahvildari. Towards a framework to incorporate NFRs

into UML models. In Proceedings of the 1st International Workshop on Reverse

Engineering to Requirements (RETR), pages 13–18, Pittsburgh, Pennsylvania, USA,

November 2005.

[58] Lihua Xu, Hadar Ziv, Debra Richardson, and Zhixiong Liu. To-

wards modeling nonfunctional requirements in software architecture. In

Proceedings of Aspect-Oriented Software Design, Workshop on Aspect-

Oriented Requirements Engineering and Architecture Design, Chicago, Illi-

nois, March 2005. Available at: http://trese.cs.utwente.nl/early-aspects-

AOSD2005/Papers/12 XuZivRichardsonLiu UCIrvineCSFullerton.pdf.

[59] Eric Yu. Towards modeling and reasoning support for early-phase requirements en-

gineering. In Proceedings of the 3rd IEEE International Symposium on Requirements

Engineering, pages 226–235, Washington, DC, USA, January 1997.