fuzzy logic based quality of service models relatório final · fuzzy logic based quality of...

Fuzzy Logic Based Quality of Service Models

Relatório Final

João Negrão Antunes

Dissertação para obtenção do Grau de Mestre em

Engenharia Informática e de Computadores

Júri

Presidente: Prof. José Carlos Monteiro

Orientador: Prof. José Tribolet

Co-Orientador: Prof. André Vasconcelos

Vogal: Prof. Paulo D’Almeida Pereira

Acompanhante: Eng. José Alegria

Outubro de 2011

Dedico este trabalho a todos os que directa ou indirectamente, mais ou menos,

me ajudaram e apoiaram a atingir este objectivo.

Muito obrigado.

i

AbstractThe continuous monitoring of information systems’ quality of service increases importance as business

becomes more and more dependent of those systems. In order to evaluate the quality of service of systems,

models need to be defined, so the definition of quality is documented and shared by all relevant stakeholders.

Because of their complexity and today modelling frameworks, quality of service models tend to result in

a poor reality representation, mainly because of their lack of ability to represent imprecision. Since the

ability to represent reality is a fundamental property of models, only when a solution is found to this

problem, better models will appear. In this work, we investigate the creation of quality of service models,

for information systems, using as motivation the general structure of a fuzzy logic controller, the most

successful application of fuzzy logic. The objective is to obtain models that are a better representation of

reality, and by consequence easier to create and understand. This thesis also presents the investigation on

related topics to support the identified problem and motivations, followed by the solution details proposal.

Finally, the solution is applied in real world systems, from the collaboration with PT-Comunicações, to

validate the given hypothesis.

Keywords: Fuzzy Logic, Fuzzy Logic Controllers, Modelling, Quality of Service Models, Complex Infor-

mation Systems, Enterprise Architectures, CEO Framework

iii

ResumoA monitorização contínua sobre a qualidade de serviço dos sistemas de informação ganha cada vez

maior importância, consequência da uma cada vez maior dependência nesses sistemas, por parte do

negócio. Para que essa monitorização seja possível é necessária a definição de modelos de qualidade

de serviço, com o objectivo de criar uma definição de qualidade, e que essa possa ser documentada e

partilha por todos os actores relevantes. Devido à complexidade presente nos conceitos de qualidade e

às frameworks disponíveis, os modelos criados hoje em dia não reflectem com exactidão as propriedades

do mundo real. Isto é consequência da sua generalizada incapacidade de lidar com imprecisão. Como a

capacidade de representação da realidade é uma das mais importantes propriedades dos modelos, apenas

quando uma solução for proposta para resolver este problema, modelos de maior qualidade irão surgir.

Esta investigação é focada na criação de modelos de qualidade de serviço, para sistemas de informação,

tendo por base a estrutura geral de sistemas de controlo difuso, os quais são as aplicações de mais sucesso

da lógica difusa. O objectivo é a obtenção de modelos que representem a realidade com maior fidelidade, e

como consequência de mais fácil compreensão e desenvolvimento. Neste trabalho, é apresentada também a

investigação nas áreas relevantes, para melhor suportar o problema e motivação identificados, seguida de

uma proposta de solução detalhada. Finalmente a solução apresentada foi aplicada sobre sistemas reais,

através da colaboração com a PT-Comunicações, para fins de validação das hipóteses estabelecidas.

Palavras-chave: Lógica Difusa, Sistemas de Controlo Difuso, Modelação, Modelos de Qualidade de

Serviço, Sistemas de Informação Complexos, Arquitecturas Empresariais, Framework CEO

v

Index

Abstract iii

Resumo v

List of Figures x

List of Tables xi

Acronyms xiii

1 Introduction 1

1.1 Quality Context on Provided Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Fuzziness of Real Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.3 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.4 Investigation Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.5 Following Chapters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Related Work 5

2.1 The Art and Science of Modelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1.1 Quality Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1.2 Quality of Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2 Enterprise Architectures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2.1 Framework CEO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.3 Fuzzy Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.3.1 Linguistic Variables and If-Then Rules . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.3.2 Fuzzy Controllers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.4 Building models for better Quality of Service . . . . . . . . . . . . . . . . . . . . . . . . . 11

3 Solution 13

3.1 Understanding Fuzzy Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.1.1 From Numbers to Words . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.1.2 Using Words to Create Phrases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.1.3 Phrases into Knowledge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.2 CEO Framework extension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.2.1 Measurable Dimension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.2.2 Quality Factor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.2.3 Classification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.2.4 Correlation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.2.5 System Quality of Service View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.2.6 Quality View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

vii

3.2.7 Dimension View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4 Validation 23

4.1 Pulso Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.1.1 Quality of Service Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.2 Developing Quality of Service Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.2.1 Using State Of The Art Knowledge . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.2.2 Creating Knowledge Based On Scenarios . . . . . . . . . . . . . . . . . . . . . . . . 30

4.3 Evaluating Quality of Service Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.3.1 Results from Example 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33



4.3.4 Integration with an Enterprise Architecture Framework . . . . . . . . . . . . . . . 35

4.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

5 Conclusion 39

5.1 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

5.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Bibliography 41

6 Appendices 43

6.1 Appendix A - Simplified Quality Views and System Quality of Service Views . . . . . . . 43

viii

List of Figures

2.1 UML Metamodel of the CEO Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2 Information System CEO Framework metamodel . . . . . . . . . . . . . . . . . . . . . . . 8

2.3 Adapted example with two type of sets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.4 Adapted demonstration of a fuzzy control systems inference. . . . . . . . . . . . . . . . . . 10

2.5 Basic structure of a fuzzy controller [Fen06] . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.1 Generic structure for fuzzy QoS models, adapted from fuzzy controllers generic structure. 13

3.2 Example of defined values for a linguistic variable. . . . . . . . . . . . . . . . . . . . . . . 14

3.3 Partial CEO Framework metamodel extension proposal. . . . . . . . . . . . . . . . . . . . 16

3.4 UML definition for the Measurable Dimension primitive. . . . . . . . . . . . . . . . . . . . 17

3.5 Measurable Dimension example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.6 UML definition for the Quality Factor primitive. . . . . . . . . . . . . . . . . . . . . . . . 18

3.7 Quality Factor example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.8 UML definition for the Classification primitive. . . . . . . . . . . . . . . . . . . . . . . . . 19

3.9 Classification example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.10 UML definition for the Correlation primitive. . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.11 Correlation example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.12 System Quality of Service view example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.13 Quality view example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.14 Dimension view example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.1 Pulso Platform Indexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.2 Membership functions for Performance’s values. . . . . . . . . . . . . . . . . . . . . . . . 25

4.3 Membership functions for Availability ’s values. . . . . . . . . . . . . . . . . . . . . . . . . 26

4.4 Thresholds list used to classify dimension BatchRequests. . . . . . . . . . . . . . . . . . . . 26

4.5 Equivalent membership functions to variable BatchRequests. . . . . . . . . . . . . . . . . . 27

4.6 Matlab Fuzzy Logic Toolbox functions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.7 Membership function for L1LogSizeMatch dimension of example 2. . . . . . . . . . . . . . 29

4.8 Visualization of Performance and respective dimensions. . . . . . . . . . . . . . . . . . . . 33

4.9 Quality factors assessment visualizations. . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.10 Quality factors assessment visualizations. . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.11 Visualization of Performance and respective dimension. . . . . . . . . . . . . . . . . . . . 35

4.12 Visualization of Availability quality factor and influential dimensions. . . . . . . . . . . . . 35

4.13 Dimension view of model from example 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.14 Quality view of model from example 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.15 System Quality of Service view of model from example 3. . . . . . . . . . . . . . . . . . . 37

6.1 Simplified Quality View, of example 1, for Performance. . . . . . . . . . . . . . . . . . . . 43

6.2 Simplified Quality View, of example 1, for Error. . . . . . . . . . . . . . . . . . . . . . . . 43

ix

6.3 Simplified Quality View, of example 1, for Availability. . . . . . . . . . . . . . . . . . . . . 44

6.4 Simplified Quality View, of example 1, for Load. . . . . . . . . . . . . . . . . . . . . . . . 44

6.5 Simplified Quality View, of example 2, for Performance. . . . . . . . . . . . . . . . . . . . 45

6.6 Simplified Quality View, of example 2, for Error. . . . . . . . . . . . . . . . . . . . . . . . 45








x

List of Tables

4.1 Example 1 measurable dimensions and their properties. . . . . . . . . . . . . . . . . . . . 27

4.2 Performance quality factor analysis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28



xi

AcronymsCEP Complex Event Processing

CODE Center for Organizational Design and Engineering

DBA Database Administrator

EDS Eficiência, Disponibilidade e Segurança

FCEO Framework CEO

ISA Information Systems Architecture

PT Portugal Telecom

PT-C PT - Comunicações

QoS Quality of Service

xiii

1 Introduction"There is nothing worse than a sharp image of a fuzzy concept."

Ansel Adams, Photographer

1.1 Quality Context on Provided Services

The continuous measurement and evaluation of conditions of information systems is nowadays an impor-

tant goal in large companies, especially those with heavily automatized business processes, so a faster

response time to stimulus can be achieved.

Specific patterns of events are already known to mean the beginning of problems and, if not immedi-

ately resolved can affect company’s performance causing long periods of services’ downtime.

In the area where this investigation is being validated - telecommunications - such consequences could

mean even greater losses as most of the offered services rely completely on those systems. Also, the ability

of the company to provide its services with high quality is an important factor to the user when choosing

his supplier.

To avoid the mentioned consequences, several quality models have already been proposed, both for the

implementation of information systems as for the evaluation of its performance [SEF+10]. These models

describe the quality requirements for a system, linking together metrics and measurement techniques,

and are known as quality of service (QoS) models.

1.2 Fuzziness of Real Systems

The main goal when building a quality of service model is about finding the answer to the following

question: "what is quality?". As a multi-dimensional concept, quality is defined by the correlation of

those same dimensions, also known as quality factors. The used quality factors are those considered

important to exist in a service, according to the relevant stakeholders [ISO01].

However, that does not answer the initial question, because those quality factors are still vague

concepts.

In the case of performance evaluation on information systems, there are also multiple dimensions

available, which can be quantified. From those measurable dimensions, the definitions of quality factors

can be created, and therefore define what quality is for a system. These definitions are built from

correlation of the measurable dimensions values to the different quality factors levels, created from the

knowledge and experience of experts [KKH04].

As systems increase in complexity, so does the correlation rules that reason about its state, or in other

words, the quality of service model becomes more complex and harder to understand. In addition, the

quantitative values obtained from monitoring specific dimensions, from a system, are usually modelled

using boolean like logics, where elements are handled in absolute terms (e.g. in or out, belongs or not,

etc), ignoring properties like uncertainty or imprecision [Zad73].

In very large information systems, concluding on the quality of service level carries much uncertainty

and by forcing absolute terms when classifying quantitative values, causes the model to no longer represent

1

the reality, where for some range of values the conclusion about the correspondent level of quality can be

fuzzy [CCAH96].

Properties like those affect negatively the confidence of stakeholders on the conclusions given through

the model. So, the following list presents some of the existing challenges in this area of investigation,

which also gives some of the motivation for the thesis.

• Can QoS models be created that provide a more accurate view of reality?

• Can the effort, required to develop a QoS model of complex information systems, be reduced?

• Can the confidence of stakeholders on the created QoS models be increased, be making them easier

to understand?

1.3 Motivation

Human reasoning is known for its ability to process incomplete and vague information in order to infer

results or make decisions. As said in the previous section, that property posses serious challenges when

creating a model to represent it. That is especially true if logics that work with absolute terms are used.

A alternative to such logics is Fuzzy logic [Zad73]. As the name suggests, it handles uncertainty, while

providing strong mathematical foundations. Its use in real world applications already counts with many

successful case studies, mainly in control and expert systems [SK92].

By making use of fuzzy logic to create quality of service models, we expected to address some of the

challenges stated in the previous section. One specific concept of fuzzy logic, the if-then rules, was in our

opinion a great contribution to improve both the creation and the comprehension of models, because it

follows more closely the reasoning process of the human mind.

The if-then rules make use of another important concept, the linguistic variables. These variables are

composed by values which are words. The words themselves correspond to propositions that instead of

dealing in terms of true or false, the notion of degree of believe is used to describe the certainty in which

a proposition is believed to be true.

So, by combining the paradigm of the if-then rules with the descriptive capacity of the linguistic

variables, more comprehensive models could arise, improving its final quality.

1.4 Investigation Guidelines

The effort in this thesis was focused on the problem of creating quality of service models which

can capture the uncertainty associated with large information systems. In order to achieve

that, the following hypotheses were formulated to guide the investigation:

• H1: It’s possible to create a definition of quality of service for information systems, based on the

generic structure of a fuzzy logic controllers.

• H2: It’s possible to extend an existing Enterprise Architecture framework to represent quality of

service for information systems, based on the generic structure of a fuzzy logic controller.

• H3: Models for quality of service of a information system can be constructed by the description of

target system snapshots and its respective assessment.

2

Being this investigation under the scope of the Center for Organizational Design and Engineering

(CODE) the preferred enterprise architecture framework for this task will be the CEO Framework (FCEO)

[VST07]. Because FCEO does not consider fuzzy logic and some quality related concepts, an extension

proposal will be presented in order to enable the creation of the models required to this investigation.

1.5 Following Chapters

In chapter 2 we investigate the related work considered relevant for this investigation, regarding the areas

of Quality of Service, Enterprise Architectures and Fuzzy Logic. The investigation on those previous

topics covers both empirical and practical studies.

After presenting the state of the art knowledge on related topics, and with the identified problem in

mind, our solution proposal is presented in chapter 3, and is divided in two sections. In the first section,

the concept of the fuzzy quality of service model is demonstrated with some simple examples. For the

second section, we present the extension to FCEO, which will be used to document these new quality of

service models.

With the proposed solution already presented, we enter in chapter 4 where it will be validated using

real world examples, which were developed in collaboration with PT-Comunicações (PT-C). Finally, in

section 5, the investigation conclusions are presented.

3

2 Related Work

This chapter will cover the investigation made on related topics, such as Quality of Service, Enterprise

Architectures and Fuzzy Logic. This information was very important to correctly identify and define the

problem in this thesis, because it allowed the identification of the state of the art knowledge and what

problems were already solved and which were still open.

In the first part of this section, we start by presenting quality of service concepts and other related

notions. From that we present Enterprise Architectures, and in more detail the CEO Framework which

was used to document the necessary models. The rest of this section will describe all the investigation

considered relevant about Fuzzy Logic.

2.1 The Art and Science of Modelling

To have models, we perform modeling. According to [SV01] modeling is both an art and a science, and

a model is the interpretation of a subset from the real world. Through the simplification of the reality

down to a set of concepts and relations, different languages can be used to describe the model according

to the audience expectations, knowledge or objectives. Models are of key importance for communication

between stakeholders, since they contribute to important tasks as visualizing and structuring a system

or documenting decisions.

As principles of modeling it’s argued that, the choosing of models affects the solving of a problem,

a model should have different levels of detail, models should reflect reality and no model is sufficient to

represent all necessary properties.

2.1.1 Quality Modeling

In [KKH04] authors define quality as a multidimensional concept, constructed throughout the model. This

defines the quality model, which objective is to answer the question "What is quality?" using various

metrics, result from measuring the available dimensions. Quality can be decomposed through implicit or

explicit attributes, which are called "quality factors". These factors are used in literature for a while now

and even the International Standard ISO 9126 is defined based on them.

Authors in [NSJ+08] present an extension for ArchiMate modelling language to enable system quality

analyses. This analyses is based on Bayesian statistics, and focuses on quality of service evaluation

for applications and their supporting infrastructure, more specifically on the following quality factors:

Availability, accuracy, confidentiality and integrity. It’s argued that by using Bayesian networks, the

uncertainty present in the real world will be better represented. This approach however is based on

probabilistic data, which doesn’t necessarily stands for uncertainty, but instead randomness.

2.1.2 Quality of Service

In the domain of service-oriented architectures and enterprise architectures, the term service refers to a

set of functionalities. In [Ope06] service is defined as a mechanism that provides access to capabilities,

5

through an interface with specifics on how that access if performed. The term is also associated with a

service provider, who provides those capabilities, and to a set of constrains and policies.

On a different perspective, the authors in [PZB85] argue that service quality can be defined as a

comparison between customer’s expectations and what is actually offered. Then for service evaluation

both service outcomes and the process to obtain them must be taken into account. This adds qualitative

and subjective elements in service quality measurement, which makes quality specification a complex

task.

In the field of networking, the notion of quality of service is associated with the guarantees of perfor-

mance transporting a flow of information, measured mostly through metrics like delay, jitter or through-

put. Quality of service can also be described as the ability to provide levels of priority, for applications

or users, or the guarantee of maintaining certain metrics above (or below) a defined threshold.

A broad review of quality of service investigation is presented in [CCAH96], which defends that QoS

investigation is mostly focused on individual layers, instead of addressing the overall QoS Architecture.

Also, a generalised QoS framework is described, to include principles about its construction, specification

and mechanism to handle the system’s behaviour.

QoS specification is described as the capturing of quality level requirements and management policies,

which will be different for each architectural layer. As for QoS Mechanisms, it will vary according to the

specification and can be separated in three groups.

• In provision mechanisms, resources are committed according to the needs expressed in the specifi-

cation.

• Control mechanisms provide traffic control of flows of information in real-time, based on levels

specified on provision operations.

• Management mechanisms operate in similar way to control, but in slower time scales, ensuring that

the contracted QoS levels are being sustained.

On the topic of QoS specification, [SEF+10] presents a survey of models, according to a classification

set. The authors conclude that performance is itself subjective and open to different interpretations.

Also, most models were found to be limited by their inability of handle uncertainty and imprecision.

Some approaches, like the probabilistic models, which can handle vagueness, are however not adequate

to handle information expressed in natural language.

2.2 Enterprise Architectures

Based on [Lan05] to manage the complexity of large systems it’s necessary to have an architecture, which

captures all the components, their relationships with each other and their surrounding environment. An

architecture also provides a common language to describe the system, it’s components and their relations,

improving overall communication between the stakeholders.

This notion was extended to the field of enterprise engineering and from that originated the term

of Enterprise Architecture (EA). An enterprise is seen as a complex system where through a "whole of

principles, methods and models" it can be decomposed in individual functional parts with respective

6

relations.

The goals of EA focus on capturing the essence of business and how the IT assets support it. By

capturing only essential aspects it promotes flexibility, so the company can adapt to new market forces

or to new opportunities, and provides models to correctly align the IT infrastructure with the business

objectives.

2.2.1 Framework CEO

CEO framework [VST07] originated in CODE investigation group, and its goal was set to describe

organizational knowledge as its various levels and the dependency between them. FCEO decomposes

an organization on three separate levels, each with adequate forms of representation according to the

concepts in question.

• Goal: This levels describes the organization goals that drive business operations. These goals are

achieved through various business process, that compose the level below.

• Process: In this level all the business processes are specified and must relate to one or more

organizational goals.

• System: In the last level, the organizational resources are described, which function is to support

the realization of business processes.

FCEO uses the Unified Modelling Language (UML) for implementation, with the help of stereotypes

for introducing the required concepts. The metamodel of FCEO can be seen in figure 2.1.

Figure 2.1: UML Metamodel of the CEO Framework

In order to represent the information systems architecture’s concepts, the CEO framework extended

its metamodel, as seen in figure 2.2.

7

Figure 2.2: Information System CEO Framework metamodel

2.3 Fuzzy Logic

As stated by Zadeh in [Zad10], "fuzzy logic is not fuzzy". Its name, responsible for some misconceptions,

comes from the capacity of manipulation of imprecision. So, fuzzy logic is described as a precise logic

that deals with information that belongs to sets with no rigid boundaries, also known as Fuzzy Sets.

Fuzzy Sets were originally defined in [Zad65]. An example of two sets, one fuzzy set and a correspondent

one with strict boundaries, can be seen on figure 2.3.

Figure 2.3: Adapted example with two type of sets.

In another important milestone in fuzzy logic [Zad73], Zadeh defends that complex systems, such as

an human brain, should not be modeled like if they were machines ruled by equations, but instead take

advantage of fuzzy logic’s ability to manipulate partial truths, imprecise information and uncertainty,

which already exist in the real world, to find better and easier to implement solutions. In this work

Zadeh also introduces the notions that eventually would support the mainstream application of fuzzy

logic, fuzzy controllers.

Fuzzy logic can be seen as a generalization of multivalued logics, which are themselves generalizations

of bivalent logics. While in bivalent logics no degree of truth (or membership) is allowed, only true or

8

false, in multivalued logics is possible to define intermediate values. Other definition for fuzzy logic,

described in [Zad08], says that it is an attempt to formalize the capacity of the human brain to reason

and make decisions based on incomplete information.

With the rapid growth of fuzzy logic’s application [SK92] [Fen06] some sceptical reactions emerge, like

in [Elk93], where Elkan argues that many of the applications of fuzzy logic can be reduced mathematically

to problems solved by bivalent logics, questioning the necessity for fuzzy logic, and defends that fuzzy

reasoning has critical faults that, in his opinion, will become important bottlenecks in developing solutions

to more complex problems.

Uncertainty manipulation property is also discussed in [Elk93], where Elkan argues that fuzzy logic is

not capable of capturing all kinds of uncertainty, e. g. imprecision, incompleteness, vagueness, ambiguity

or randomness. For the purpose of this work, we’ll refer to uncertainty as described in [Cro96], as the

belief in which we consider a proposition to be true.

2.3.1 Linguistic Variables and If-Then Rules

In [Zad73] Zadeh presented two concepts that shaped the future applications of fuzzy logic. The first, lin-

guistic variables, gave us the ability to express formally some common used measures in natural language.

When calling "tall" to someone, a value for the variable "height" is being assigned. Because the value

"tall" is vague, and could mean different things to different people, membership functions are defined.

These functions will map each exact (numerical) value of height into linguistic values. In other words,

for each possible height exact value, the membership function will express the belief in which that value

is considered, following with the example, a "tall" height. Each linguistic value will have its membership

function.

The second important concept, If-then rules, by making use of linguistic variables, provide a way to

describe desired behaviours according with situations that have associated imprecision. Through this,

the knowledge required to deal with known situation can be modelled in order to automatize the process

of decision. A knowledge database is usually the description given to a set of if-then rules, because

it describes, using natural language, all the reactions that a system should have when facing specific

situations. An example of define variables and rules for a simple system, can be seen in figure 2.4, where

a concrete input scenario is demonstrated.

2.3.2 Fuzzy Controllers

According to [SK02] designing systems that could perform tasks normally done by humans was a goal of

human research for many centuries, but only in the last one significant advances were achieved due to use

of mathematical description and analysis of such systems. Before those were built only from experience

with no formal support, that resulted in limited solutions, if any.

The appearance of measurement systems was also an important milestone in building control systems,

by enabling feedback controllers. These analyze the measurements of sensors and the outputs of the

process to infer the necessary control actions to achieve the desired goals, repetitively.

Two methods to design feedback controllers are identified in the book:

9

Figure 2.4: Adapted demonstration of a fuzzy control systems inference.

• Signal-based control: Only the measurements from sensors and the outputs of the process are

used in determining the necessary control actions. The knowledge from the process’ model is only

used at the design stage.

• Model-based control: In this approach, the parameters for each iteration of the controller are

based on the model, which specifies the desired response for the process, and on sensors’ measure-

ments.

In fuzzy control systems, by application of fuzzy set theory it’s possible to model non-linear processes,

where heuristics exist, in form of if-then rules, about what should be the correct behaviour of the system.

Fuzzy logic is used as the tool for establishing the link between those rules, in natural language, to a

formal mathematical model, that could be automatized. Figure 2.5 shows the basic structure of a fuzzy

controller, which is composed by four main components:

Figure 2.5: Basic structure of a fuzzy controller [Fen06]

1. Fuzzification: This component is responsible by translating the input information into the fuzzy

domain, numerical information to linguistic variables.

2. Defuzzification: As the final component in the controller, its responsibility is the opposite of the

previous, translating the output information from fuzzy domain back to their numerical represen-

tation.

10

3. Knowledge Base: In this component, the rules for determining the behaviour of the controller

are described.

4. Inference Engine: Using the translated input, from the fuzzification component, and the rules,

from the knowledge base, this component will infer the output to be delivered to defuzzification.

Regarding defuzzification, several methods exist [LK99], each with its own properties making them

suitable for specific situations. This is an important step, because it’s where the results from the rules

are summarized into crisp values, removing uncertainty and imprecision.

Fuzzy logic controllers can also be signal-based or model-based. In signal-based fuzzy controllers, the

more usual ones, an expert knowledge database, in the form of if-then rules, is created using linguistic

variables to infer the results from the input variables. The tuning of such controllers is mostly done by

trial-and-error, a method with many drawbacks, like economical or safety ones. This type of controller

also follows the work of an operator, not being possible to improve its performance beyond what the

operator itself can perform, only guarantee its homogeneity.

In model-based fuzzy controllers [Fen06], the creation of the controller follows the classic notion of

model-based controller, where the process is modeled choosing its specifications and criteria, followed by

the design of the controller itself, that will behave according to the model. The definition of model-based

fuzzy controller is not a very specific one and leaves way to three different variations, in where to use

fuzzy set theory, designing these controllers. It can be either on the model, the performance criteria or

the control elements.

2.4 Building models for better Quality of Service

In this section we have revisited the quality of service topic, to conclude that still today there are

difficulties in creating definitions about it. In those investigations, the imprecision and uncertainty

present in the real world, is identified as a cause for such difficulties. That is because most models force

the removal of those properties, which creates models that turn out as poor representations of reality.

As seen in the enterprise architectures section, an important property of models is its ability to

represent the reality, using a subset of the reality concepts, removing unnecessary details. To date, those

imprecisions referred before were seen as removable details, but that has been a mistake because the

uncertainty that experts have when assessing on QoS is real and has a relevant impact on the conclusions

about the system status.

That is where fuzzy logic stands as a solution to those problems, by offering a formal methodology

to deal with the imprecision of natural language. As stated in this chapter, fuzzy logic in itself does not

enable anything that could not be already constructed, but instead permits that it can be done more

naturally, i.e. with less effort.

11

3 SolutionIn this chapter, a solution to the identified problem will be presented and explained. As said previously,

the creation of quality of service models is surrounded with uncertainty and the overall models that are

nowadays used, force certainty. From that alone we concluded that models don’t represent reality as

close as they should. Also, by forcing that change, the complexity of modelling systems is increased

and by consequence of the model itself. If we consider very large information systems it’s obvious that

models will be very complex and hard to trust and understand by stakeholders. Since the context of this

investigation is on information systems, by system we consider any element of the infrastructure, software

or hardware.

3.1 Understanding Fuzzy Models

Our solution is focused at reducing some of that complexity by creating models that don’t force the

removal of uncertainty, which is part of the knowledge acquired by experts. That was achieved through

the use of concepts from fuzzy logic, to enable an abstraction layer to the system, so new QoS models

could be described using natural language instead of dealing only with a rigid domain of numbers.

Figure 3.1: Generic structure for fuzzy QoS models, adapted from fuzzy controllers generic structure.

The fuzzy controller, as the most successful application of fuzzy logic, was used to guide the devel-

opment of the new quality of service models. Those controllers, as explain in the previous chapter, are

composed of four components and each of them was matched with a specific component of the new models

as seen in figure 3.1. In the Measurable Dimensions component, the system dimensions that can be

quantifiable, are modelled as linguistic variables. In the same way, the Quality Factors to be monitored

in the target system, are also modelled using linguistic variables. These two will correspond to the input

and output variables, respectively, used to conclude on the quality of service of an information system.

The Scenario Database is where the knowledge about quality of service assessment is defined, which

uses the previously defined input and output variables. Since those are linguistic variables, words and not

numbers are its values, meaning that this component knowledge is entirely developed in natural language.

The fuzzy if-then rules, explained in previous chapter, will compose rules of correlation between system

dimensions, and how each quality factor is constructed.

Finally, the Fuzzy Logic Engine component corresponds to the deterministic process that obtains

crisp numerical results, according to the defined rules, variables and measurements corresponding to the

13

system dimensions. How the results are obtained is described in greater detail in [Zad73].

So, the construction of the models will be composed in three major steps:

1. Numbers to Words: This step is where the abstraction from the numerical domain is created by

creating the linguistic variables for each dimension and quality being monitored on a target system.

2. Words to create Phrases: Using with the created variables, if-then rules are created to define

concrete scenarios, where for a specific correlation of values of dimensions, the impact on the values

of quality factors are established.

3. Phrases into Knowledge: Finally, both with the defined linguistic variables and the if-then rules,

the knowledge about the QoS assessment is integrated into the enterprise architecture, using an

extended framework to handle all required concepts.

3.1.1 From Numbers to Words

The first step is where numbers are converted into words by the definition of linguistic variables. Each

variable will correspond to either a measurable dimension or a quality factor, and its values will match

the levels that are used to classify them both regarding its state. If for instance, assuming a quality factor

Availability, its possible states were Available or Stopped, the created linguistic variable would have the

same name, and its values would be the same as the possible states.

In order to define each value, for the linguistic variables of dimensions, a membership function is used

that will specify the degree of believe corresponding to each numerical input. In the case of values for

quality factors, membership functions will be used to specify how, from the overall result of degree of

believes on each value, a numerical value is obtained.

Figure 3.2: Example of defined values for a linguistic variable.

This step accomplishes the objective of handling the uncertainty and imprecision of human reasoning,

by using words but still maintaining a formal mathematical foundation, as explained in chapter 2.

An example of defined values for a linguistic variable can be seen in figure 3.2, where its also possible to

see how each numerical value reflects the degree of believe on the different linguistic variable’s values. As

the appropriate method for obtaining a crisp value from a linguistic variable’s value will depend heavily

on the problem at hand, no specific defuzzification method will be apart of the solution description, in

the same way that no specific membership functions are established.

14

3.1.2 Using Words to Create Phrases

After all the variables are defined, along with the values and respective membership functions, a rules

database can be constructed. To do this, the if-then rules are used to capture the expertise of the relevant

stakeholders. Each rule will establish a correlation between a set of measurable dimensions, and how they

come together to define a specific quality scenario.

This method presents some important properties that in the context of information systems’ quality

of service assessment can introduce significant advantages. Those properties are the following:

1. The quality model is described as a set of concrete scenarios, each of them describing the quality

of service assessment corresponding to the occurrence of specific inputs values.

2. Defined scenarios are independent from each other, in the way that adding, removing or modifying

any rule will not impact the remaining knowledge, enabling an iterative construction of models.

Instead of creating a generic formula that can conclude on the quality of service, which is the standard

method for quality of service assessment, we propose that it should be created by focusing on independent

and concrete scenarios. By doing so, it also enables independence between the system’s experts, as each

can work on his set of rules and afterwards combine them to compose the QoS model.

Also, after the initial modelling, if any other scenario is found to be missing, all that its necessary to

update the model, is to add the if-then rule to the existing database. As it is expected that quality of

service models evolve over time, the ability to modify them is important. In our solution, because of the

rules’ independence, any developed rule can modified or deleted, and new rules added without affecting

the remaining knowledge.

The created rules should then follow the following structure:

• Rule = IF Dimension IS [NOT] Value [ (AND|OR) Dimension IS [NOT] Value ]*

THEN Quality IS [NOT] Value

3.1.3 Phrases into Knowledge

In this final step, the constructed knowledge is integrated in an enterprise architecture, so it can be

related with the remaining environment. Some new concepts were created to enable the representation

of QoS models based on fuzzy logic. Also, different views are defined to provide different perspectives on

QoS regarding a system.

The extension is based on the Information Systems Architecture (ISA), creating new elements to

represent QoS and Fuzzy Logic concepts. The connection of these new concepts with the remaining

architecture is made using the Block and Service elements. The Block element represents a target system

whose dimensions are measured, and the Service element is monitored through one or more quality

factors.

The proposed extension to the CEO framework is further detailed in the next section.

15

Figure 3.3: Partial CEO Framework metamodel extension proposal.

3.2 CEO Framework extension

In order to represent these new quality of service models, an extension to the CEO framework is proposed,

so it can handle concepts both from fuzzy logic and from quality of service assessment. This set of new

concepts has the objective of forming a concise list of terms necessary to describe the details of this new

approach of creating QoS models. The new concepts are described according to the following structure:

• Description: Brief description about the element.

• Attributes: Identification of attributes relative to the new element.

• Relations: Identification of associations of the new concept with different elements.

• Motivation: Explained motivation for the definition of the new element.

• UML Definition: Definition of the architectural primitive.

• Example: Simple example of an instance of this new element.

So, using those elements, the new models can be represented in order to document or share between

stakeholders. A visual representation of the extension proposed to the metamodel can be seen in figure

3.3. As different stakeholders may have different perspectives over a model, we also propose a set of

views, each with unique focused on a subset of QoS elements.

3.2.1 Measurable Dimension

Description

This refers to a system’s measurable dimension that may be observed and quantified, and can also be

known simply as dimension or metric.

Attributes

This concept has no specific attributes.

16

Relations

• Block : This relation associates the dimensions to a target system in which exists that quantifiable

characteristic.

• Classification : This relation creates a possible classification level for the measured value of the

dimension.

Motivation

In the field of QoS, information systems are traditionally monitored through the observation of certain

dimensions. Those dimension must be quantifiable to enable a precise evaluation [CCAH96].

UML Definition

(a) Partial Diagram (b) Notation

Figure 3.4: UML definition for the Measurable Dimension primitive.

Example

Figure 3.5: Measurable Dimension example.

3.2.2 Quality Factor

Description

Specifies a relevant characteristic for the definition of quality in a service, which is provided by a infor-

mation system. This enables the definition of quality, for a specific service, through a set of factors.

17

Attributes

• Defuzzification method : Its necessary to define which method will be used to obtain the numerical

value from the degree of believes on the different variable’s values. For more information about

defuzzification methods refer to [LK99].

Relations

• Service : This relation associates the quality factor being monitored to a specific service.

• Classification : This relation creates a possible classification level for the quality factor.

Motivation

Quality is defined as a multi-dimensional concept [KKH04], so to define it, a set of attributes must be

created. According to the International Standard ISO 9126, these attributes are called quality factors.

UML Definition


Figure 3.6: UML definition for the Quality Factor primitive.

Example

Figure 3.7: Quality Factor example.

18

3.2.3 Classification

Description

Corresponds to a value of a linguistic variable, defining its membership function. Considering Measurable

Dimension and Quality Factor as linguistic variables, each one will be composed by values. By connecting

two different values, one from aMeasurable Dimension and other from a Quality Factor, we define a if-then

rule.

Attributes

• Membership function : Each classification corresponds to a value of a linguistic value, and its

definition is created through a membership function, that associates a degree of believe, from 0 to

1, to each input value.

Relations

• Measurable Dimension : This relation defines a value for the Measurable Dimension linguistic

variable.

• Quality Factor : This relation defines a value for the Quality Factor linguistic variable.

• Correlation : This association define the Classification has one of the values in one Correlation.

Motivation

Because both the Measurable Dimensions and the Quality Factors are modelled as linguistic variables,

its necessary also to define their values [Zad73].

UML Definition


Figure 3.8: UML definition for the Classification primitive.

19

Example

Figure 3.9: Classification example.

3.2.4 Correlation

Description

This concept represents an correlation in a if-then rule, relating two or more Classifications. This concept

is used to compose more complex if-then rules.

Attributes

• Operation : This attribute can have one of two values: AND, OR. The first represents the union

of the Classifications related to this Correlation, and the second represents the disjunction.

Relations

• Classification : This association define the Classification has one of the values in the Correlation.

Motivation

Because on QoS assessment the individual dimension state cannot always be enough to conclude on the

QoS level, the correlation between different dimensions is necessary. This concept will allow the definition

of more complex scenarios, so quality can be defined to more complex situations.

UML Definition


Figure 3.10: UML definition for the Correlation primitive.

20

Example

Figure 3.11: Correlation example.

3.2.5 System Quality of Service View

Figure 3.12: System Quality of Service view example.

This view is an high level overview of the QoS model, where for a specific system and service, only

the available Measurable Mimensions and Quality Factors are showed. A dimension and a quality factor

are connected if the dimension is present in some evaluation scenario that causes impact on that quality.

An example of a System Quality view can be seen in figure 3.12. The elements present in this view are

the following: Block, Service, Measurable Dimensions and Quality Factor.

3.2.6 Quality View

This view focus on a specific Quality Factor, relating it to all Measurable Dimensions that cause some

impact, and also the Classifications and Correlations involved. This view provides an overview on a

quality attribute, presenting all the rules that cause an impact on it. An example of a System Quality

view can be seen in figure 3.13. The elements present in this view are the following: Quality Factor,

Measurable Dimensions, Classification and Correlation.

3.2.7 Dimension View

In this view the focus is on a Measurable Dimension, showing all quality factors that are influenced by it.

As in the Dimension view, an overview is provided to all the rules, where the dimension is a participant

and possible correlations, that causes an impact on some quality attribute. An example of a Dimension

view can be seen in figure 3.14. The elements present in this view are the following: Quality Factor,

Measurable Dimensions, Classification and Correlation.

21

Figure 3.13: Quality view example.

Figure 3.14: Dimension view example.

3.3 Summary

In this chapter we presented the necessary steps to build quality of service models based on fuzzy logic

controllers. The two main components for developing these models were detailed, first the process of

turning numbers to words, and with that the creation of knowledge by defining scenarios using if-then

rules. This information enables the creation of a fuzzy logic controller that can assess the quality of

service of a information system, given any input on the monitored dimensions.

Also, the extension for the CEO framework was present in detail, which provides the tools needed to

integrate the knowledge within a enterprise architecture. By using the new elements, all the necessary

information is correctly documented, and the new set of views provide different perspectives on the final

model, to address the objectives of different stakeholders.

22

4 Validation

In this chapter the validation process for the proposed solution will be explained. This validation was

based on the application of the developed solution on real world systems. This validation was developed

in collaboration with PT-Comunicações, more specifically with the Pulso Platform, which provided the

necessary conditions and information to finish this step.

We will begin by describing the available enterprise environment that enabled us to validate our

solution. Then, the steps taken in each of the use cases will be described in detail, followed by some

conclusions about the hypothesis established in chapter 1.

4.1 Pulso Platform

PT-C created the Pulso platform [ACR05] because of a growing concern on its information systems’

conditions. One of its goals was to monitor performance, availability and errors of their IT assets with

near real-time precision, to determine the quality of service being provided to application’s users. To

achieve that, a network of agents, attached to relevant system’s components, provides basic metrics that

by correlation and aggregation, result in indicators. Those are displayed in a portal, where managers can

obtain feedback on systems’ conditions that their responsible for.

The correlation and aggregation of metrics is performed in a complex event processing (CEP) envi-

ronment. There, a stream of events receives the metric’s values and through defined rules, representing

their quality model, determines all the required indicators. Those indicators are updated every minute

to achieve the near real-time monitoring.

However, the creation of indicators is still surrounded by uncertainty as the composition rules for

creating indicators don’t translate with precision the expert’s knowledge, that know how to evaluate

the system’s global conditions based on available metrics. These evaluations may differ from expert to

expert according to each one’s level of experience, but its important that a coherent version is correctly

translated to a model, for use in the monitoring platform.

The EDS1 division of PT-C, responsible for this platform provided the necessary conditions and access

to information that enabled this work to be validated.

4.1.1 Quality of Service Models

The solution presented previously was used to create QoS models, which obtained indexes, specifically

those seen in figure 4.1. The Availability, Performance and Errors indexes reflect the qualities factors

monitored on each system, which are then summarized in a Quality of Service index (QosIdx). The

Demand Load index represents the application load at the time and stands side by side with the quality

of service index to comparison ends. For instance, if the application load is too high, it can be expected

that its quality of service may decay in some degree.

Those indexes are meant to provide an overview over an system, which is built from subsystems, e.

g. Databases or Web Servers. These subsystems are themselves distributed in clusters of machines. In

1Eficiência, Disponibilidade e Segurança de TI/SI

23

Figure 4.1: Pulso Platform Indexes

this machines, the previously mentioned agents are placed, some at the level of the operating system and

some inside a subsystem’ component, in order to provide the metrics that in the end will result in the

indexes from figure 4.1.

Nowadays, the quality of service models used in Pulso Platform are constructed from crisp values,

forcing certainty, with all the downfalls already discussed in previous chapters. Also, these models are built

based on a generalization principle, where all scenarios are resumed using weighted averages approaches.

This approaches hide the specificities of some scenarios and make the knowledge management a difficult

task. In order to add, remove or alter some part of the knowledge in the model, all of it must be taken

into account because any small change may have collateral damage in the remaining knowledge.

Another problem also reported about these models is its large development time and the difficulty

to understand them. Because so many models need to be defined, to all deployed applications in Pulso

Platform, the development effort for each cannot extend to large periods of time. This is especially

important if we consider that any modification on already developed models can effect all of it, making

the effort to manage it an vital requirement.

4.2 Developing Quality of Service Models

In this section we describe the development of new QoS models using the solution described in 3. In the

first two examples, current models assessment were replicated, in order to validate that current models

in Pulso can also be described by our solution. In the third and last example, with the help of an expert

from PT-C, the concept of scenarios description to build an quality of service model was put to validation.

Different tools exist that enable the construction and evaluation of fuzzy logic control systems, and

for this investigation the toolbox for MATLAB software, the Fuzzy Logic Toolbox2, was used. This tool

provides the described features, and so enables the evaluation of constructed models. Although its a

very complete tool for analysis of fuzzy systems, it had some limitations, as it will be explained when

necessary, in the next sections. All defaults configurations for this tool are considered in use, except

otherwise specified.

2http://www.mathworks.com/products/fuzzylogic/

24

4.2.1 Using State Of The Art Knowledge

This first scenario used the knowledge already developed at Pulso Platform regarding the state of the

art on quality of service assessment of their systems. In order to use this knowledge, fuzzy quality of

service models were developed to match the behaviour of current models. Each specific model has its

own details, but some principles hold for every developed model, as the following:

• P1 : Systems are characterized by four different quality factors: Availability, Performance, Error

and Load.

• P2 : Each measurable dimension is only assigned to one quality factor, of a particular system.

• P3 : Any measurable dimension, or quality factor, is classified by one, out of six, possible ordinal

levels: Good, Fair, Mediocre, Poor, Bad or Down. Or 1 to 6, respectively.

• P4 : Measurable dimension are classified according to a list of thresholds. These lists are composed

of five values, which separate the input domain in six intervals, corresponding to the six different

classifications. Additionally, another property, AggregationDirection, sets the order in which the

classifications are associated with the intervals. If set to "Max" the first interval is associated with

the first classification, and equally for the remaining, and if set to "Min" the association is inverted,

meaning that the first interval is associated with the last classification and so on.

• P5 : In order to classify a quality factor there are two separate methods.

1. The first relates to the Availability, which uses the Criticality property of the measurable

dimensions, which has a value in the interval of 0 to 100. The dimensions are group by their

classification, and if some group sum of Criticality ’s value is equal or greater than 100, its

assigned that same classification. If more than one group has a sum greater than 100, the

classification to assigned should be the higher.

2. For the others quality factors, the Weight property of measurable dimensions are used, which

can have any value starting from 0. Using a standard weighted average, according to each

dimension weight and classification, the classification for the quality factor is obtained.

Following those guidelines, two real systems serve as use cases for the development of the new QoS

definition. The first example is of a database system and the second of a web server system. Both had

already been modelled, without the fuzzy concepts, and so their models were used in comparison with

the new developed models.

Figure 4.2: Membership functions for Performance’s values.

25

As the values for the used quality factors are the same in all systems, we began by defining them.

The result can be seen in figure 4.2, for Performance quality factor, but also applies for Error and Load.

For Availability, since it only considers three of the possible six values, the membership functions were

defined as seen in figure 4.3.

Figure 4.3: Membership functions for Availability ’s values.

4.2.1.1 Example 1 - Database system

Figure 4.4: Thresholds list used to classify dimension BatchRequests.

In this case, the system used for the validation was a database system, part of a application in Portugal

Telecom (PT). After gathering all the necessary information, the first step was to model the available

dimensions into linguistic variables. Because in the previous models the numerical input values were

classified according to a list of strict thresholds, an equivalent set of membership functions were defined.

In figure 4.4 a dimension of the system is presented, showing how classification is attributed using the

following list of thresholds: 110.000; 165000; 209000; 330000; 440000.

In order to replicate that knowledge the membership functions were developed in order to intersect,

i.e. when both functions have the same degree of believe, in the same value that was in the previous

thresholds list. So, the equivalent set of membership functions, to the thresholds list in figure 4.4, can be

seen in figure 4.5.

To define the membership functions the Generalized Bell-shaped (built-in the Fuzzy Logic Toolbox,

figure 4.6a) was used, except for two cases. Those cases correspond the domain extremities, where the

S-shaped and the Z-shaped functions were used (figure 4.6b and 4.6c).

The Generalized Bell-shaped function was found to represent what could be a reasonable degree of

26

Figure 4.5: Equivalent membership functions to variable BatchRequests.

(a) Generalized Bell-shaped (b) S-shaped (c) Z-shaped

Figure 4.6: Matlab Fuzzy Logic Toolbox functions.

believe, where the middle values between two defined thresholds have stronger believe to be part of the

corresponding linguistic value. As we move away from middle values that believe will decrease to zero.

Dimension Name Assigned Quality Criticality Weight Thresholds

ProcessCount Availability 100 - 0; 0; 0; 0; 0

ProcessPcpu Performance - 1 1000; 1400; 1900; 2300; 3000

ErrorQuantity Error - 5 110000; 165000; 209000; 330000; 440000

BatchRequests Load - 5 40; 60; 70; 80; 90

TimeExecRefQuery Performance - 5 400; 600; 900; 1300; 1800

Table 4.1: Example 1 measurable dimensions and their properties.

For this example we had five available dimensions, as described in table 4.1. With that information

from the previous models, the membership functions for the fuzzy model were developed, using the

method explained above. Next, with just the linguistic variables and their values, the if-then rules were

defined in order to complete the QoS definition.

Regarding Availability, since it had only one dimension associated, it would be the only needed to

infer the result. Considering that the Criticality property was set to 100, the dimension was considered

critical, so the relation between dimension and quality was proportional. That means whatever value the

dimension had, the quality factor would have the same. This translated into the following rules:

• IF ProcessCount IS Good THEN Availability IS Good

• IF ProcessCount IS Down THEN Availability IS Down

27

For Performance, we already had two available dimensions, with different weight values, meaning that

one had more impact than the other. In the following table all the possible inputs are listed with the

respective result, according to the previous model.

ProcessPcpu TimeExecRefQuery Performance

1 Good|Fair|Mediocre Good Good

2 Poor|Bad|Down Good Fair

3 Good|Fair|Mediocre|Poor Fair Fair

4 Bad|Down Fair Mediocre

5 Good|Fair|Mediocre|Poor|Bad Mediocre Mediocre

6 Down Mediocre Poor

7 Good|Fair|Mediocre|Poor|Bad|Down Poor Poor

8 Good Bad Poor

9 Fair|Mediocre|Poor|Bad|Down Bad Bad

10 Good|Fair Down Bad

11 Mediocre|Poor|Bad|Down Down Down

Table 4.2: Performance quality factor analysis.

From this table, the rules for the model can be extracted very naturally, as each row can be translate

directly into if-then rules. To follow the defined rule’s structure, some rows could not be translated to

just one line. In the case of row 4, two different rules were created, because one dimension could have

one of two possible values.

• IF ProcessPcpu IS Bad AND TimeExecRefQuery IS Fair THEN Performance IS Mediocre

• IF ProcessPcpu IS Down AND TimeExecRefQuery IS Fair THEN Performance IS Mediocre

Also, to avoid creating many rules, to translate row 5, the NOT operator can be used, like in the

following rule:

• IF ProcessPcpu IS NOT Down AND TimeExecRefQuery IS Mediocre

THEN Performance IS Mediocre

And in a third case, where all possible values of a dimension are considered, it can just be removed.

An example of this is row 7, which translates to the following rule:

• IF TimeExecRefQuery IS Poor THEN Performance IS Poor

To define the Error quality factor, only one dimension was also available, so its weight value, since it

was greater than zero, did not influence the result by being any specific value. Like for the Availability,

this quality factor was defined as proportional to the available dimension.

• IF ErrorQuantity IS Good THEN Error IS Good

• IF ErrorQuantity IS Fair THEN Error IS Fair

• IF ErrorQuantity IS Mediocre THEN Error IS Mediocre

• IF ErrorQuantity IS Poor THEN Error IS Poor

• IF ErrorQuantity IS Bad THEN Error IS Bad

• IF ErrorQuantity IS Down THEN Error IS Down

28

Finally, for the Load quality factor, the necessary rules are equivalent to those of Error, but using its

respective dimension.

• IF BatchRequests IS Good THEN Load IS Good

• IF BatchRequests IS Fair THEN Load IS Fair

• IF BatchRequests IS Mediocre THEN Load IS Mediocre

• IF BatchRequests IS Poor THEN Load IS Poor

• IF BatchRequests IS Bad THEN Load IS Bad

• IF BatchRequests IS Down THEN Load IS Down

4.2.1.2 Example 2 - Web Server system

Figure 4.7: Membership function for L1LogSizeMatch dimension of example 2.

In the second case, a web server system was used, also part of another PT application. As the

previous example, the necessary dimensions were defined, by following the method explained before, with

the exception of two dimensions, one of which can be seen in figure 4.7.

Dimension Name Assigned Quality Criticality Weight Thresholds

ProcessCount Availability 100 - 0; 0; 0; 0; 0

ProcessPcpu Performance - 1 40; 60; 70; 80; 90

DiskSpaceFree Availability 100 - 1; 2.5; 5; 7.5; 10

L1LogSizeMatchCount Error - 5 0; 0; 1; 4; 5

L2LogSizeMatchCount Error - 5 0; 0; 1; 4; 5

L1LogSizeLines Load - 1 2000; 3000; 3800; 6000; 8000

L2LogSizeLines Load - 1 1500; 2250; 2850; 4500; 6000


In the two cases, the domain of input values was very limited and only dealt with discrete values, which

removes much of the uncertainty generally associated. Because of that, the need for a membership function

that would translate a gradual increasing and decreasing of the degree of believe was not necessary, and

instead a membership function that associates each specific input with a absolute degree of believe was

created. All the available dimensions for this example are described in table 4.3.

Regarding the if-then rules, starting with Performance, and since that only one dimension defined

that quality factor, the same principle of being proportional like in some qualities from previous example,

was used. So, the rules that define Performance are the following:

• IF ProcessPcpu IS Good THEN Performance IS Good

29

• IF ProcessPcpu IS Fair THEN Performance IS Fair

• IF ProcessPcpu IS Mediocre THEN Performance IS Mediocre

• IF ProcessPcpu IS Poor THEN Performance IS Poor

• IF ProcessPcpu IS Bad THEN Performance IS Bad

• IF ProcessPcpu IS Down THEN Performance IS Down

For the remaining quality factors, all of them had two assigned dimensions, both with the same weight,

or same criticality in the case of the dimensions assigned to Availability. Since the criticality of those

dimensions was 100, both were considered critical, and as such, the worst case should be the value of

Availability. For Error and Load, to replicate the previous assessment on QoS based on a weighted average,

and since weights were the same between the dimensions, the quality factor was classified according each

dimension’s own classification and through the defuzzification method, the average was obtained. So, the

following list of rules define all the remaining qualities:

• IF ProcessCount IS Good AND DiskSpaceFree IS Good THEN Availability is Good

• IF ProcessCount IS Good AND DiskSpaceFree IS Fair THEN Availability is Good

• IF ProcessCount IS Good AND DiskSpaceFree IS Mediocre THEN Availability is Good

• IF ProcessCount IS Good AND DiskSpaceFree IS Poor THEN Availability is Good

• IF ProcessCount IS Good AND DiskSpaceFree IS Bad THEN Availability is Bad

• IF ProcessCount IS Down OR DiskSpaceFree IS Down THEN Availability is Down

• IF L1LogSizeMatchCount IS Good OR L2LogSizeMatchCount IS Good THEN Error IS Good

• IF L1LogSizeMatchCount IS Fair OR L2LogSizeMatchCount IS Fair THEN Error IS Fair

• IF L1LogSizeMatchCount IS Mediocre OR L2LogSizeMatchCount IS Mediocre

THEN Error IS Mediocre

• IF L1LogSizeMatchCount IS Poor OR L2LogSizeMatchCount IS Poor THEN Error IS Poor

• IF L1LogSizeMatchCount IS Bad OR L2LogSizeMatchCount IS Bad THEN Error IS Bad

• IF L1LogSizeMatchCount IS Down OR L2LogSizeMatchCount IS Down THEN Error IS Down

• IF L1LogSizeLines IS Good OR L2LogSizeLines IS Good THEN Load IS Good

• IF L1LogSizeLines IS Fair OR L2LogSizeLines IS Fair THEN Load IS Fair

• IF L1LogSizeLines IS Mediocre OR L2LogSizeLines IS Mediocre THEN Load IS Mediocre

• IF L1LogSizeLines IS Poor OR L2LogSizeLines IS Poor THEN Load IS Poor

• IF L1LogSizeLines IS Bad OR L2LogSizeLines IS Bad THEN Load IS Bad

• IF L1LogSizeLines IS Down OR L2LogSizeLines IS Down THEN Load IS Down

4.2.2 Creating Knowledge Based On Scenarios

In this part of the validation a new quality of service definition was developed without replicating the

developed model for the target system. That system was also a database like in the first example, and

the new model was developed with the direct contributions of an database administrator (DBA), from

PT-C.

The purpose for this validation was to compare the resulting model with previous ones, constructed

following the properties described in the previous section. By creating a quality of service definition

30

based on concrete snapshots of the system and handling uncertainty in a formal way, better models were

expected, which would better represent reality. The feedback from the expert would also be considered

to the definition evaluation.

Dimension Name

TimeWaitEvent

CountBlockingLocks

CountSessions

CountUserCalls

CpuTime

TimeStatistics

FullTableIndexScan


The available dimensions to conclude on quality of service in this system are present in table 4.4.

None of them had a defined threshold list or assigned quality factor, in this use case, and such properties

were left to define by the DBA, by using the membership functions and the if-then rules. The quality

factors to monitor in this system were only the following: Availability, Performance and Load.

4.2.2.1 Example 3 - Defining Thresholds

To define the necessary membership functions, in a first approach, it was asked to the DBA to drawn on

paper the lines that he consider to be most correct approach to his degree of believe, according to the

input numerical values, to each Classification value.

After the necessary variables and respective values were defined, the Fuzzy Logic Toolbox was used to

create again the variables in order to replicate what was on paper, in the most approximated way possible.

After the defined functions were corrected and finally validated by the expert, the step of creating the

abstraction from the numbers domain was complete.

4.2.2.2 Example 3 - Constructing Scenarios

In the second step of creating the QoS definition, the necessary if-then rules were developed. For each

quality factor, it was asked to the DBA what were the possible causes that would constitute each Classi-

fication. Through the use of the Fuzzy Logic Toolbox, it was possible to evaluate the constructed model,

to observe its behaviour. After some iterations, to add missing scenarios or to resolve conflicts, the set

of rules that defined the model were validated by the expert. The resulting list of rules is the following:

• IF FullTableIndexScan IS Good,Fair AND CountSessions IS Good AND CountUserCalls IS Good

THEN Load IS Good

• IF FullTableIndexScan IS Mediocre AND CountSessions IS Fair,Mediocre AND

CountUserCalls IS Fair,Mediocre THEN Load IS Fair

• IF FullTableIndexScan IS Mediocre,Poor AND CountSessions IS Mediocre,Poor AND

CountUserCalls IS Mediocre,Poor THEN Load IS Mediocre

31

• IF FullTableIndexScan IS Poor,Bad AND CountSessions IS Poor,Bad AND

CountUserCalls IS Poor,Bad THEN Load IS Poor

• IF FullTableIndexScan IS Bad AND CountSessions IS Bad AND CountUserCalls IS Bad

THEN Load IS Bad

• IF FullTableIndexScan IS Bad,Down AND CountSessions IS Down AND CountUserCalls IS Down

THEN Load IS Down

• IF CountSessions IS Poor,Bad AND CountUserCalls IS Poor,Bad THEN Load IS Poor

• IF FullTableIndexScan IS Mediocre,Poor,Bad,Down THEN Load IS Poor

• IF CountSessions IS Fair AND CountUserCalls IS Fair THEN Load IS Fair

• IF TimeWaitEvent IS Good AND CpuTime IS Fair,Mediocre AND TimeStatistics IS Good

THEN Performance IS Good

• IF TimeWaitEvent IS Fair AND CpuTime IS Fair,Mediocre AND TimeStatistics IS Fair

THEN Performance IS Fair

• IF TimeWaitEvent IS Mediocre,Poor AND CpuTime IS Mediocre AND TimeStatistics IS Mediocre

THEN Performance IS Mediocre

• IF TimeWaitEvent IS Poor AND CpuTime IS Poor,Bad AND TimeStatistics IS Poor

THEN Performance IS Poor

• IF TimeWaitEvent IS Bad,Down AND CpuTime IS Bad AND TimeStatistics IS Bad

THEN Performance IS Bad

• IF TimeWaitEvent IS Down AND CpuTime IS Down AND TimeStatistics IS Down

THEN Performance IS Down

• IF TimeWaitEvent ISMediocre,Poor,Bad,Down AND FullTableIndexScan ISMediocre,Poor,Bad,Down

THEN Performance IS Poor

• IF TimeWaitEvent IS Mediocre,Poor,Bad,Down THEN Performance IS Poor

• IF TimeWaitEvent IS Good,Fair THEN Performance IS Fair

• IF TimeStatistics IS Good,Fair THEN Performance IS Fair

• IF CountBlockingLocks IS Good,Fair THEN Availability IS Good

• IF CountBlockingLocks IS Mediocre,Poor,Bad THEN Availability IS Bad

• IF CountBlockingLocks IS Down THEN Availability IS Down

These rules do not follow exactly the structure presented in the solution, in order to simplify the

capture of scenarios described by the DBA. However they can be decomposed into the proposed structure

as showed in the example below:

• IF BlockingLocks IS Good,Fair THEN Availability IS Good

– IF BlockingLocks IS Good THEN Availability IS Good

– IF BlockingLocks IS Fair THEN Availability IS Good

32

4.3 Evaluating Quality of Service Models

In the previous section the process of creating the QoS definition for a information system was explained

and demonstrated. In the first two cases the objective was to replicate the assessment knowledge already

present in different models, and in the third example a system expert was asked to develop a model

according to our solution. This section presents the evaluation on the created models to conclude on the

proposed hypotheses.

4.3.1 Results from Example 1

Figure 4.8: Visualization of Performance and respective dimensions.

With the help of the Fuzzy Logic Toolbox, different views on the quality factors assessment were

available to evaluate the model. In figure 4.8 the Performance quality factor can be seen related with the

dimensions that impact in any way its classification. Remembering that the two dimensions used to infer

about Performance had different weights, it was expected that the one with most weight would cause

greater impact, just as showed in the figure.

Regarding the remaining quality factors, the assessment results are shown in figure 4.9. As only one

dimension affects each quality factor, respectively, the visualization is composed only of 2D graphics. It

can be seen that the define scenarios are reflected in the curve as expected.

With the use of these visualizations, for each quality factor, that show how numerical input values

are translated into quantifications for quality of service, it can be argued that the hypothesis H1 present

in chapter 1 is validated, as the created definition for QoS has the expected properties.


In example 2 we had two quality factors defined by the weighted average of two dimensions, each, and

both had equal weights. The expected behaviour of those quality factors was then to be equally influenced

by either dimension. That behaviour is observed in figure 4.10, both for Error and Load quality factors.

For Performance, since it had only one influential dimension, the expect result would be that the

quality factor classification reflected the dimension’s own classification, as observed in figure 4.11. For

Availability, the expected results would be:

33

(a) Availability (b) Error (c) Load

Figure 4.9: Quality factors assessment visualizations.

(a) Error (b) Load

Figure 4.10: Quality factors assessment visualizations.

• A Down classification, when any of the dimension is Down;

• If any dimension is classified as Bad, the second is not Down, then the quality factor should also

be Bad ;

• Otherwise classified as Good.

In figure 4.12 its possible to see that those three expected results are respected. As in the first

example, the proposed hypothesis H1 is validated as a QoS definition could be developed using a fuzzy

logic controller approach.


In this example the resulting behaviour was evaluated by the expert himself. By making use of the tool,

for evaluating Fuzzy Logic controllers, several input scenarios were simulated to verify if the obtained

output corresponded to expected value. After several simulations, iterating over to the definition of

if-then rules in case of not expected results, the model was considered complete.

We are confident to say that hypothesisH3 was also validated, since the model was created as specified

by the expert’s defined scenarios. Also, it allowed him to develop the model iteratively, evaluating and

then adding, removing or changing rules to correct the evaluation cases that he did not consider correct.

It was argued by the expert himself that this method could improve models’ quality according to the

time spent iterating on the set of rules, because it maintains independent rules that are not affected by

the rest.

34

Figure 4.11: Visualization of Performance and respective dimension.

Figure 4.12: Visualization of Availability quality factor and influential dimensions.

4.3.4 Integration with an Enterprise Architecture Framework

In chapter 1 the hypothesis H2 was presented. It stated that an Enterprise Architecture framework

could be extended in order to represent a quality of service model, based on fuzzy logic controllers, of

information systems. Proposed at chapter 3, the extension to FCEO was applied to the three examples

describe previously, in order to validate that hypothesis.

Figure 4.13: Dimension view of model from example 1.

Regarding example 1, we present a Dimension view in figure 4.13, refering to the dimension Process-

Count. In this view is possible to see the two rules in which this dimension is participating, and also the

35

quality factor that is impacted, in this case just one.

Figure 4.14: Quality view of model from example 2.

For example 2, we use a Quality Factor view, to show how the Availability factor is classified ac-

cording to the assigned dimensions. In figure 4.14, the rules and correlation between ProcessCount and

DiskSpaceFree, which compose the definition for Availability, can be observed.

Finally, for example 3, the System Quality of Service view is presented in figure 4.15. In this view

its possible to obtain a overview of how quality of service is defined for the target system, displaying

all quality factors and each dimension that has impact on it. In this case its also easy to identify the

dimension that has impact on two different quality factors, the FullTableIndexScan.

So, regarding the presented hypothesis H2, we have validated it using three real systems, modelled

according to our solution. To a complete overview on those examples, quality views for all quality factors

can be viewed in appendix 6.1, and also the system quality of service views in appendix ??.

4.4 Summary

In this section, the solution proposed in the previous chapter was applied to three different information

systems. The first two were meant to replicate the knowledge already created at PT-C about quality

of service assessment. The third and final one was developed with the help of a DBA from PT-C, with

the objective of evaluating the use of system snapshots to capture experts’ knowledge, in the creation of

36

Figure 4.15: System Quality of Service view of model from example 3.

quality of service definition.

In a second part, the evaluation of the models were performed to verify if the presented hypothesis

could be validated.

37

5 ConclusionIn this thesis we parted from a general consensus on the lack of tools and methods to create quality of

service models that could capture the uncertainty and imprecision that experts experience when defining

quality for an information systems. Also, from research we learned that fuzzy logic controllers were on

the rise as a successful application to solve control problems that handle with uncertainty, and so the

creation of models was adapted to the general structure of the controllers.

Through the application of this solution to three cases, using real world information systems, we have

validated our hypothesis. Quality of Service models can be modelled following the structure of a fuzzy

logic controller, and also its properties, like the if-then rules, represents an improved method for capturing

the knowledge from experts, as showed in the last example. Its was also possible to extend the FCEO

framework with the minimal and necessary set of concepts, enabling the integration of these developed

models with an enterprise architecture.

The collaboration with PT-C was most important because it gave access to real world systems, part

of very large information systems. With the contribution of one of those systems’ expert it was also

possible to evaluate the acceptance of the proposed solution to create the QoS models.

5.1 Limitations

Regarding some possible limitations, we have identified the following:

• An hierarchy of quality factors could not be developed using the proposed solution. However, the

necessary concepts to represent such structure are already present, but no relation between different

qualities has been defined. Once the relation between different quality factors is clearly defined and

established, the fuzzy if-then rules could be used to define values for a quality factor, by correlation

of values from other qualities.

• This solution is not applicable for quality of service assessment over a period of time, since it defines

what quality is for concrete snapshots of the system.

5.2 Future Work

Many investigation possibilities are still open for further work. Regarding membership functions, in this

investigation they were not investigated into their full potential as modelling tools for the uncertainty

and imprecision. Also, as experts are most used to model variables using threshold points in their given

domain of values, membership functions may still represent uncovered advantages.

For the if-then rules, the possibilities are even greater. For once the possibility of static analysis of

rules, uncovering conflicts, duplications or even scenarios not covered. This analyses can also be used to

assess the own quality of models, enable comparison between them.

Finally, investigation on the defuzzification methods may reveal other potential benefits, as the ex-

amples used here were created with the most simplistic method, the center of area. This represents an

important component of a possible QoS model because it can modify the resulting assessments completely

from just changing methods..

39

Bibliography

[ACR05] José Alegria, Tiago Carvalho, and Ricardo Ramalho. Uma experiência open source para

“tomar o pulso” e “ter pulso” sobre a função sistemas e tecnologias de informação. Technical

report, Portugal Telecom, 2005.

[CCAH96] Andrew Campbell, Andrew Campbell, Cristina Aurrecoechea, and Linda" Hauw. A review

of qos architectures. MULTIMEDIA SYSTEMS, 6:138–151, 1996.

[Cro96] Valerie Cross. Towards a unifying framework for a fuzzy object model. Fifth IEEE Interna-

tional Conference on Fuzzy Systems, 1:85–92, September 1996.

[Elk93] Charles Elkan. The paradoxical success of fuzzy logic. In IEEE Expert, pages 698–703, 1993.

[Fen06] Gang Feng. A survey on analysis and design of model-based fuzzy control systems. IEEE

Transactions on Fuzzy Systems, 14(5):676–697, October 2006.

[ISO01] ISO. ISO/IEC 9126-1:2001, Software engineering – Product quality – Part 1: Quality model,

2001.

[KKH04] Souheil Khaddaj, Souheil Khaddaj, and G" Horgan. The evaluation of software quality factors

in very large information systems. Electronic Journal of Information Systems Evaluation,

pages 43–48, 2004.

[Lan05] Marc Lankhorst. Enterprise Architecture at Work: Modelling, Communication and Analysis.

Springer, December 2005.

[LK99] Van Leekwijck and Kerre. Defuzzification: criteria and classification. Fuzzy Sets and Systems,

108:159–178, 1999.

[NSJ+08] Per Närman, Marten Schönherr, Pontus Johnson, Mathias Ekstedt, and Moustafa Chenine.

Using enterprise architecture models for system quality analysis. In Proceedings of the 2008

12th International IEEE Enterprise Distributed Object Computing Conference, pages 14–23,

Washington, DC, USA, 2008. IEEE Computer Society.

[Ope06] OASIS Open. Reference model for service oriented architecture 1.0. Technical report, OASIS

Open, August 2006.

[PZB85] A. Parasuraman, Valarie A. Zeithaml, and Leonard L. Berry. A conceptual model of servce

quality and its implications for future research. Journal of Marketing, 49:41–50, 1985.

[SEF+10] Olabiyisi S.O., Omidiora E.O, Uzoka F.M.E, Victor Mbarika, and Akinnuwesi B.A. A survey

of performance evaluation models for distributed software system architecture. Proceedings

of the World Congress on Engineering and Computer Science 2010, 1:35–43, October 2010.

[SK92] DG Schwartz and GJ Klir. Fuzzy logic flowers in japan. Spectrum, IEEE, 29(7):32–35, 1992.

41

[SK02] Joao M. C. Sousa and Uzay Kaymak. Fuzzy Decision Making in Modeling and Control. World

Scientific Publishing Company, December 2002.

[SV01] A.M.R. Silva and C.A.E. Videira. UML - METODOLOGIAS E FERRAMENTAS CASE.

Centro Atlântico, 2001.

[VST07] A Vasconcelos, P Sousa, and J Tribolet. Information system architecture metrics: An enter-

prise engineering evaluation approach. Electronic Journal of Information Systems Evaluation,

10(1):91–122, 2007.

[Zad65] Lotfi A. Zadeh. Fuzzy sets. Information Control, 8:338–353, 1965.

[Zad73] LA Zadeh. Outline of a new approach to the analysis of complex systems and decision

processes. IEEE Trans. on Systems, Man, and Cybernetics, SMC-3:28–44, 1973.

[Zad08] Lotfi A. Zadeh. Is there a need for fuzzy logic? Fuzzy Information Processing Society,

NAFIPS, pages 1–3, May 2008.

[Zad10] Lotfi A. Zadeh. A summary and update of "fuzzy logic". IEEE International Conference on

Granular Computing, pages 42–44, 2010.

42

6 Appendices

6.1 Appendix A - Simplified Quality Views and System Quality of Service

Views

Figure 6.1: Simplified Quality View, of example 1, for Performance.

Figure 6.2: Simplified Quality View, of example 1, for Error.

43

Figure 6.3: Simplified Quality View, of example 1, for Availability.

Figure 6.4: Simplified Quality View, of example 1, for Load.

44

Figure 6.5: Simplified Quality View, of example 2, for Performance.

Figure 6.6: Simplified Quality View, of example 2, for Error.

45



46


47

Figure 6.10: Simplified Quality View, of example 3, for Load.48



49


50

fuzzy logic based quality of service models relatório final · fuzzy logic based quality of...

Documents