UML For Non Functional Reqs

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.

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.

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
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

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
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 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
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”,
“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
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].
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
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-
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
<<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>>”.

<<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:
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
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].
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
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

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-
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
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.

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
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
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
(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
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.
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.

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

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,
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.

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.

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

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:

∀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
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
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
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.

• 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

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
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.

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
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:

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
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
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

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
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.

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
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

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 ).

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

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
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.

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.
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:

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
• 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.

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.
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,
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
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.

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

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,
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
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.

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

• 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-
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

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.

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

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
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.

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
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.
• 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

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-
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.

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.
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-
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] João Araú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] Siobhá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 Cé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 Cé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 Hürsch and Cristina Videira Lopes. Separation of concerns. Technical Report
NU-CCS-95-03, Northeastern University, February 1995.
[31] Wai Ming Ho, Jean-Marc Jézéquel, Alain Le Guennec, and François Pennaneać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 Jézéquel, François Pennaneaćh, and Noë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 Jézéquel, Noë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. Menascé, Virgilio A. F. Almeida, and Larry W. Dowdy. Performance by
Design: Computer Capacity Planning by Example. Prentice Hall, 2004.
[39] Ana Moreira, Joäo Araú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 Joäo Araú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.

UML For Non Functional Reqs

Transféré par

Informations du document

Description originale:

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

UML For Non Functional Reqs

Transféré par

Droits d'auteur :

Formats disponibles

Incorporating Non-Functional Requirements

with UML Models

Subrina Anjum Tonu

presented to the University of Waterloo

thesis requirement for the degree of

Master of Applied Science

Electrical and Computer Engineering

Waterloo, Ontario, Canada, 2006

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

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

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

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

We validate our approach by performing two case studies.

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

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

for their valuable time spent to read the thesis.

such friends in my life.

wishes made every step of my life easier.

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

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

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

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

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

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

4 A Formal Language for Modeling NFRs 36

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

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

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

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

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