Download PDF
ads:
LUCIANA DE PAIVA SILVA
A ENGENHARIA DE REQUISITOS ORIENTADA A
ASPECTOS: A ABORDAGEM DAORE
MARINGÁ
2007
ads:
Livros Grátis
http://www.livrosgratis.com.br
Milhares de livros grátis para download.
ii
Dados Internacionais de Cataloga
çã
o
-
na
-
Publica
çã
o (CIP)
Biblioteca Central do Campus de Cascavel
-
Unioest
e
S581e
Silva, Luciana de Paiva
A engenharia de requisitos orientada a aspectos: a abordagem
DAORE. / Luciana de Paiva Silva.
—
Maring
á
, PR: UEM, 2007.
233 f. ; 30 cm
Orientadora: Profa Dra. Tania F. Calvi Tait
Disserta
çã
o (Mestrado)
–
Universi
dade Estadual de Maring
á
.
Programa
de Pós
-
Graduação em Ciência da Computação.
Bibliografia.
1. Sistemas de informa
çã
o. 2. Orienta
çã
o a aspectos. 3. Engenharia
de requisitos. I. Tait, Tania F. Calvi. II. Universidade Estadual de
Maring
á
. III. T
í
tulo.
CDD 21ed. 005.1
CIP
–
NBR 12899
Ficha catalogr
á
fica elaborada por Jeanine Barros CRB
-
9/1362
ads:
iii
LUCIANA DE PAIVA SILVA
A ENGENHARIA DE REQUISITOS ORIENTADA A
ASPECTOS: A ABORDAGEM DAORE
Dissertação apresentada ao Programa de
P
ós
-
Graduação em Ciência da Computação
da Universidade Estadual de Maringá, como
requisito parcial para obtenção do grau de
Mestre em Ciência da Computação.
Orientadora: Profa. Dra. Tania Fatima Calvi
Tait
MARINGÁ
2007
iv
Ao que foi
e que sempre será
meu apoio, meu amigo, meu cúmplice e
meu marido: Sérgio.
v
A
GRADECIMENTOS
“
Nada é mais difícil, e por isso mais precioso, do que ser capaz de decidir
.”
Napoleão
Apoiar
do Latim Appodiare
significa ajudar, confirmar
,
dar apoio, fundar
-
se
.
.
Todas as conquistas são repletas de dificuldades e, para vencê
-
las, é necessário
apoio em
todas as formas
.
O
apoio
recebido
ajuda
n
o desenvolvimento de um
projeto
, seja ele pessoal ou comunitário
.
As pessoas aqui listada
s ofereceram um tipo de apoio, que é imprescindível a qualquer
projeto, a força que move montanhas... o apoio que vence barreiras de distâncias, de oceanos
e até mesmo espiritual.
Gostar
i
a de agradecer a todos que de alguma forma
me ajud
aram
a
realizar est
e desafio.
Sem
o apoio recebido jamais teria conseguido.
Muito obri
g
ado:
·
A Nossa Senhora, pela
força espiritual
que inspira,
protege e ilumina constantemente a minha vida;
·
Aos meus amados pais, Antonio e Francisca, por me
tornarem quem eu sou, pelo amor, pela dedicação, por todos
os sacrifícios para que eu chegasse até aqui, sacrificando
sua antiga morada e seus amigos, no Rio de Janeiro, para
uma cidade estranha, apenas para
me
ajudar e por terem
sido
fortes
, mesmo quando a minha distância os fazia
sofrer
;
·
Ao meu filho Thyago, por ser meu amigo e me incentivar no
caminho do saber;
·
A minha filha Julia, que com seu sorriso e seu jeitinho
meigo de ser, me f
i
ze
ram
vivenciar momentos de alegrias
durante minha jornada;
·
Ao meu amigo,
meu cúmplice e meu companheir
o de sempre,
Sergio, que com seu amor incondicional me impulsionaram a
buscar mais uma realização, mais uma conquista, e por
despertar em mim uma admiração crescente e constante;
·
A minha avó Nina, seu apoio espiritual foi imprescindível
para a realização dos meus sonhos;
·
A minha amiga Aline, por ser minha irmã e minha
companheira dos momentos felizes e infelizes em nossa
estada em Maringá;
vi
·
A minha orientadora
T
â
nia
, pelo incentivo, confiança e
pela parceria nas idéias e discursões, alem de agüentar
minhas
reclamações;
·
A professora Elisa, por ter me propiciado o primeiro
contato com a orientação a aspectos e pelas importantes
contribuições para o enriquecimento desta dissertação;
·
Aos pesquisadores com os quais me correspondi,
especialmente a
Awais Ra
s
hid
,
E
ric SK Yu, Marcio
Cysneiros
,
Silvio Meira, Jaelson Castro, Julio Leite,
Karin Breitman
e
John
Mylopoulos
;
·
Ao
prof. André
Luiz de Medeiros
Santos, meu orientador do
doutorado,
do Cin
-
UFPE, pela
paciência e bom humor
durante
esta fase
do mestrado
;
·
Ao
Depa
rtamento de I
nformática
da UEM
, pelo suporte
técnico e acadêmico
durante minha estada
;
e
·
A todos aqueles que torceram e acreditaram em mim e neste
trabalho.
Agradecimentos
vii
“Há duas formas para viver sua vi
da:
uma é acreditar que não existe milagre;
a outra é acreditar que todas as coisas são um milagre“.
Albert Einstein
“Porque para Deus nada é impossível”.
Lucas 1,37
viii
Resumo
S
ILVA
,
Luciana de Paiva
.
A
Engenharia de Requisitos Orientada a Aspectos: A Abor
dagem
DAORE
.
23
3
f. Dissertação (Mestrado em Ciência da Computação)
–
Programa de Pós
-
Graduação em Ciência
da Computação, U
EM,Maringá
.
Ao desenvolvermos um projeto de sistemas de informação, geralmente não
modelamos os chamados
crosscuting concerns
, tend
emos a modelar algumas características
isoladas e não realizamos a separação e composição destas características.
A orientação a aspectos permite a modelagem destas características nos projetos,
possibilitando a identificação de características comuns em
várias partes do sistema.
Inicialmente voltada para a implementação e agora com várias pesquisas relacionadas às fases
iniciais do desenvolvimento do processo de software, a orientação a aspectos permite que se
obtenha muitas vezes os requisitos aspectuais
, ou seja, os aspectos identificados nas fases
iniciais do processo de desenvolvimento, que são fatores importantes e imprescindíveis desde
o início do projeto de sistemas.
Assim, e
ste projeto
de dissertação
insere
-
se num tema que tem recebido crescente
a
tenção no processo de desenvolvimento de sistemas: a aplicação da orientação a aspectos nas
fases iniciais do
processo de desenvolvimento
, ou como é conhecida na linguagem aspectos:
early
aspects.
Este trabalho
realiza um estudo e análise
de algumas
das
abordagens existentes na fase
de engenharia de requisitos por meio da introdução de uma nova abordagem, denominada
DAORE
– Distributed
Aspect Oriented
A
pproach for
R
equirements
E
ngineering
, como
solução para aplicação
do LEL
– Léxico Extendido da Linguagem
e
da metodologia
MDSODI
-
Methodology for Development of Distributed Software
, permitindo a definição destes
conceitos nos projetos e requisitos elucidados a serem desenvolvidos no projeto DiSEN
-
Distributed Software Engineering Environment
e em outros p
rojetos a serem desenvolvidos
utilizando esta metodologia.
Para avaliar nossa abordagem aplicamo
-
la em um sistema de controle de eventos.
ix
Abstract
SILVA, Luciana de Paiva.
A
Engenharia de Requisitos Orientada a Aspectos: A Abordagem
DAORE
.
23
3
f. Di
ssertação (Mestrado em Ciência da Computação)
–
Programa de Pós
-
Graduação em Ciência
da Computação, U
EM,
Maringá
.
When
we
develop a
information systems
project, generally we do not shape the calls
crosscut
t
ing concerns, we tend shape it some isolated ch
aracteristics and we do not carry
through the separation and composition of these characteristics.
The aspects orient
ed approach
allows the modeling of these characteristics in the
projects, allowing
to identify
common characteristics in some parts of the
system are
identified. Initially come back toward the implementation and now with some related research
the initial phases of the project, the orientation the aspects allows that if it gets many times the
aspects
, that they are important and essential factors since the beginning of the project of
systems.
Thus, this project is inserted in a subject that has received increasing attention in the
process from development of systems: the application of the
aspects
orient
ed
in the initial
phases of the development process, or as it is known in the language aspects: early aspects.
The considered
work
search to carry through a study and analysis of the existing
approaches
in the phase of
the
requirements
engineering by means of the introduction of a
new
approac
h
, called
DAORE
-
Distributed Aspect Oriented
A
pproach for
R
equirements
E
ngineering
, as solution for application of
the LEL
–
Language Extended Lexicon
and the
methodology MDSODI
-
Methodology for Development of Distributed Software
, allowing to
the defini
tion of these concepts in the projects and elucidated requirements to be developed in
the project
DiSEN
-
Distributed Software Engineering Environment
and in
other projects to
be developed using this methodology.
To evaluate the use of our approach, we ap
ply it in the context of an
events manager
system
.
x
Lista de Abreviaturas
AOD
Aspect Oriented Development
AORE
Aspects Oriented Requirement
Eng
ineering
DiSEN Distributed Software Engineering Environment
DAORE
Distributed
Aspect Oriented Approach for Requirements Engineering
I*
Distributed Intentionality
LAL Léxico Ampliado da Linguagem
LEL
Language Extended Lexicon ou Léxico Extendido da Linguagem
MDSODI Methodology for Development of Distributed Software
NFR
N
on
-
functional Requirement
s
POA Programação orientada a aspectos
POO Programação orientada a objetos
UML
Unified Modeling Language
RE
Engenharia de Requisitos
RF
Requisitos Funcionais
RNF Requisitos não
-
funcionais
RO
Requisitos organizacionais
XML
Extensible Markup Language
xi
Lista de Figuras
C
APÍTULO
1
F
IGURA
1.1
E
STRUTURA DA
P
ESQUISA A SER SEGUID
A
..........................................
9
C
APÍTULO
2
F
IGURA
2.1
M
ODELO DE
S
EPARAÇÃO
A
VANÇADA DE
C
ONCERNS
.........................
18
F
IGURA
2.2
P
ROCESSO DE C
OMBINAÇÃO DE ASPECTOS E CLASSES PARA GER
AR O
SISTEMA
.............................................................................................
23
F
IGURA
2.3
E
STRUTURA DE UMA ENTI
DADE
A
SPECT EM
A
SPECT
J.......................
25
F
IGURA
2.4
E
XEMPLO DE CÓDIGO EM
A
SPECTJ....................................................
25
F
IGURA
2.5
MODELO DE PROCESSO
AORE...........................................................
27
F
IGURA
2.6
E
XEMPLO DE
C
ASO DE
U
SO COM
A
SPECTO
C
ANDIDATO....................
34
F
IGUR
A
2.7
U
SE
C
ASE DE OVERLAP DO AS
PECTO SEGURANÇA
..............................
35
F
IGURA
2.8
E
XEMPLO DE
R
EGRA DE
C
OMPOSIÇÃO
...............................................
37
F
IGURA
2.9
O
GRÁFICO
V
-
G
RAPH E SUA COMPOSIÇÃ
O
..........................................
38
F
IGURA
2.10
O
GRÁFICO
V
-
G
RAPH E SUA REPRESENT
AÇÃO
...................................
38
F
IGURA
2.11
A
VISÃO GERAL DA
A
BORDAGEM
G
OAL
.............................................
39
F
IGURA
2.12
A
TUALIZAÇÃO DOS MODELOS NO DESENVOLVIMENT
O
.......................
42
F
IGURA
2.13
E
FEITOS DE DISPERSÃO E ENROLAÇÃO QUANDO R
EALIZAMOS PEERS
..
43
F
IGURA
2.14
E
XEMPLO DE
E
XTENSION
...................................................................
44
F
IGURA
2.15
E
STRUTURA DOS ELEMENT
OS E CASOS DE USO
SLICES
........................
45
F
IGURA
2.16
C
OMPOSIÇÃO DA REALIZA
ÇÃO DE CASOS DE USO
PEER
COM CASOS
DE USO
SLICES
....................................................................................
45
F
IGURA
2.17
R
EPRESENTAÇÃO DE
C
ASOS DE
U
SO
..................................................
46
F
IGURA
2.18
E
STRUTURANDO
C
ASOS DE
U
SO DE INFRA
-
ESTRUTURA
.....................
46
F
IGURA
2.19
A
E
SPECIFICAÇÃO DO
CA
SO DE USO
<PERFORM TRANSACTION>.......
47
F
IGURA
2.20
O
P
ROCESSO
T
HEME...........................................................................
49
F
IGURA
2.21
E
XEMPLO
A
BSTRATO DO
G
RÁFICO DE
V
ISÃO DE
A
ÇÕES
....................
52
F
IGURA
2.22
E
XEMPLO
A
BSTRATO DO
G
RÁFICO DE
A
ÇÕES
L
IGADAS.....................
53
F
IGURA
2.23
E
XEMPLO
A
BSTRATO DO
G
RÁFICO DE
T
HEME
V
IEW
..........................
54
C
APÍTULO
3
F
IGURA
3.1
C
ICLO DE VIDA DO
MDSODI.............................................................
66
F
IGURA
3.2
O
AMBIENTE
D
I
SEN
E SUA ESTRUTURA EM
CAMADAS.......................
70
F
IGURA
3.3
R
EPRESE
NTAÇÃO DO
G
ERENCIADOR DE W
ORSPACE
..........................
72
F
IGURA
3.4
M
ODELO DE
P
ROCESSO UTILIZADO NA
REQUISITE.........................
73
F
IGURA
3.5
D
IAGRAMA
U
SE
C
ASE DA FERRAMENTA
REQUISITE.......................
74
F
IGURA
3.6
A
RQUITETURA DETALH
ADA DA FERRAMENTA
REQUISITE..............
77
F
IGURA
3.7
E
SQUEMA DE
I
NSTÂNCIAS DA FERRAME
NTA
REQUISITE.......
.........
79
F
IGURA
3.8
R
EPRESENTAÇÃO DA
A
RQUITETURA DO
D
I
SEN
.................................
80
C
APÍTULO
4
F
IGURA
4.1
M
ODELO DE
P
ROCESSO D
A
A
BORDAGEM
DAORE.....................................
89
F
IGURA
4.2
P
ROCESSO
G
ERAL DE COSNTRUÇÃO D
E
REQUISITOS..................................
90
F
IGURA
4.3
U
MA
T
AXONOMIA PARA RNF
S
.
.................................................................
93
F
IGURA
4.4
M
ODELO DE
P
ROCESSO DE
C
ONSTRUÇÃO DO
LEL
NA
A
BORDAGEM
DAORE......................................................................................................
101
xii
C
APÍTULO
5
F
IGURA
5.1
M
ENU
P
RINCIPAL DA FERRAMEN
TA
CALEL
118
F
IG
URA
5.2
T
ELA DE INCLUSÃO DO
LEL
119
F
IGURA
5.3
O
P
ROCESSO DE
M
APEAMENTO LEL
–
O
NTOLOGIAS
147
F
IGURA
5.4
MAPEAMENTO DOS SÍMBO
LOS
DO TIPO ESTADO
153
F
IGURA
5.5
E
STRUTURA HIERÁRQUICA
DA ONTOLOGIA
E
VENTOS
154
F
IGURA
5.6
T
RECHO DO
A
RQUIVO DO
LEL
DOS
S
ÍMBOLO
S EM
XML
155
F
IGURA
5.7
T
RECHO DO
A
RQUIVO DO
LEL
DOS
C
ENÁRIOS EM
XML
155
F
IGURA
5.8
T
RECHO DO
A
RQUIVO DE
A
SPECTOS
XML
156
F
IGURA
5.9
T
RECHO DO
A
RQUIVO DE
O
NTOLOGIAS XML
156
C
APÍTULO
6
F
IGURA
6.1
M
ENU
P
RINCIPAL DA FERRAMEN
TA
R
EQUISITE
160
F
IGURA
6.2
N
ET
B
EANS E A FERRAMENTA
R
EQUISITE
161
F
IGURA
6.3
B
ORLAND
T
OGETHER
A
RCHITECT E A
R
EQUISITE
162
F
IGURA
6.4
D
IAGRAMA DE
C
ASOS DE
U
SO DA
R
EQUISITE PROPOSTO
163
F
IGURA
6.5
D
IAGRAMA DE
C
LASSES
P
ROPOSTO DA NOVA VERS
ÃO DA
R
EQUISITE
165
F
IGURA
6.6
T
ELA DE
A
CESSO AO
R
EQUISITE
166
F
IGURA
6.7
N
OVO
M
ENU
P
RINCIPAL DA
F
ERRAMENTA
R
EQUISITE
167
F
IGURA
6.8
S
UB
-
M
ENU DE
P
ROJECT
167
F
IGURA
6.9
N
EW
P
ROJECT
168
F
IGURA
6.10
S
UB
-
M
ENU DA
O
PÇÃO
LEL
169
F
IGURA
6.11
N
EW
/
U
PDATE
LEL
170
F
IGURA
6.12
S
UB
-
M
ENU DA OPÇÃO
U
SE
C
ASE
171
Lista de Figuras
xiii
Lista de Tabelas
CAPÍTULO
2
T
ABELA 2.1
R
ELACIONANDO
P
ROPRIEDADES
COM REQUISITOS DOS
STAKEHOLDERS
.....................................................................................
28
T
ABELA 2.2
MAPEAMENTO ENTRE ASPE
CTOS CANDIDATOS
......................................
29
T
ABELA 2.3
E
XEMPLO DE UMA
E
SPECIFICAÇÃO DA
D
IMENSÃO DO
A
SPECTO
...........
30
T
ABELA 2.4
T
EMPLATE PARA ATRIBUT
OS DE QUALIDADE
.........................................
31
T
ABELA 2.5
T
EMPLATE PARA REQUISI
TOS NÃO FUNCIO
NAIS
.....................................
32
T
ABELA 2.6
I
DENTIFICAÇÃO DE M
ATCH
P
OINTS.......................................................
36
T
ABELA 2.7
C
ONTRIBUIÇÃO E
C
ORRELAÇÃO
............................................................
39
T
ABELA 2.8
C
ARACTERÍSTICAS DE
Q
UALIDADE
ISO/IEC
9126................................
41
T
ABELA 2.9
A
DAPTAÇÃO DOS
C
ONCEITOS DAS
C
ARACTERÍSTICAS DE
Q
UALIDADE
ISO/IEC
9126.......................................................................................
55
T
AB
ELA
2.10
S
UB
-C
ARACTERÍSTICAS DE
C
OMPARAÇÃO
............................................
56
T
ABELA 2.11
C
RITÉRIOS DE
P
ADRÕES
U
TILIZADOS NA
C
OMPARAÇÃO
.......................
57
T
ABELA 2.12
COMPARAÇÃO DAS
A
BORDAGENS
AORE..............................................
59
T
ABELA 2.13
R
ESUMO DA COMPARAÇÃO
–
A
BORDAGEM
V
IEWPOINT
........................
60
T
ABELA 2.14
R
ESUMO DA COMPARAÇÃO
–
A
BORDAGEM
G
OALS
...............................
61
T
ABELA 2.15
R
ESUMO DA COMPARAÇÃO
–
A
BORDAGEM
U
SE
C
ASE
..........................
62
T
ABELA 2.16
R
ESUMO DA COMPARAÇÃO
–
A
BORDAGEM
THEME/DOC...................
63
T
ABELA 2.17
R
ESUMO
G
ERAL DA
C
OMPARAÇÃO
.......................................................
63
CAPÍTULO
3
T
ABELA 3.1
E
SPECIFICAÇÃO DOS ELE
MENTOS UTILIZADOS NA
MDSODI
68
CAPÍTULO
4
T
ABELA 4.1
C
ONCEITOS E ARTEFATOS
USADOS NA
DAORE
....................................
84
T
ABELA 4.2
R
ELAÇÃO ENTRE
D
IRETRIZES DA
DAORE
E AS
C
ARACTERÍSTICAS DE
Q
UALIDADE
..........................................................................................
86
T
ABELA 4.3
RNF
S E ESTRATÉGIAS DE S
ATISFAÇÃO..................................................
94
T
ABELA 4.4
MAPEAMENTO DOS
R
EQUISITOS
N
ÃO
F
UNCIONAIS
E
FUNCIONAIS
.......
98
T
ABELA 4.5
M
APEAMENTO DOS
R
EQUISITOS
O
RGANIZACI
ONAIS EM
R
EQUISITOS
F
UNCIONAIS
E NÃO FUNCIONAIS
............................................................
100
T
ABELA 4.6
C
ONTRIBUIÇÕES DOS ASP
ECTOS
............................................................
104
T
ABELA 4.7
C
OMPOSIÇÃO DOS
A
SPECTOS
I
DEN
TIFICADOS
.......................................
105
T
ABELA 4.8
E
XEMPLO DE
P
REENCHIMENTO DA
T
ABELA DE
C
ONFLITOS
..................
106
T
ABELA 4.9
M
APEAMENTO DOS ELEMEN
TOS DO
LEL
PARA OS
E
LEMENTOS DA
O
NTOLOGIA
...........................................................................................
107
T
ABELA 4.10
E
XEMPLO DE HIERARQUIA
DE CLASSES
..................................................
108
T
ABELA 4.11
DAORE
E OS
O
BJETIVOS
P
ROPOSTOS
...................................................
110
CA
PÍTULO
5
T
ABELA 5.1
R
EQUISITOS DO SISTEMA.......................................................................
117
T
ABELA 5.2
R
EQUISITOS
N
ÃO
F
UNCIONAIS E
O
RGANIZACIONAIS DO SI
STEMA.........
117
T
ABELA 5.3
S
ÍMBOLOS DO
LEL ENCONTRADOS NOS REQ
UISITOS FUN
CIONAIS
.........
119
T
ABELA 5.4
S
ÍMBOLOS DO
LEL DETALHADO
............................................................
120
T
ABELA 5.5
I
NCLUSÃO DOS REQUISIT
OS NÃO FUNCIONAIS
........................................
128
xiv
T
ABELA 5.6
I
NCLUSÃO DOS REQUISIT
OS
ORGANIZACIONAIS
.....................................
128
T
ABELA 5.7
MAPEAMENTO ENTRE OS T
ERMOS DO
LEL............................................
129
T
ABELA 5.8
C
ENÁRIOS DO
LEL
................................................................................
130
T
ABELA 5.9
C
ONTRIBUIÇÕES DOS
A
SPECTOS
............................................................
141
T
ABELA 5.10
C
OMPOSIÇÃO DOS
A
SPECTOS
I
DENTIFICADOS
.......................................
142
T
ABELA 5.11
R
ESOLUÇÃO DE CONFLITO
S
...................................................................
146
T
ABELA 5.12
T
ERMOS DO
LEL
LISTADOS SEGUNDO O
SEU TIPO
.................................
149
T
ABELA 5.13
M
APEAMENTO REALIZADO
....................................................................
150
CAPÍTULO
6
T
ABELA 6.1
M
APEAMENTO ENTRE AS V
ERSÕES DA
R
EQUISITE
.................................
172
Lista de Tabelas
xv
Índice
AGRADECIMENTOS................................................................................................
i
v
RESUMO....................................................................................................................
vi
i
ABSTRACT................................................................................................................
vii
i
LISTA DE ABREVIAT
URAS..
.................................................................................
ix
LISTA DE FIGURAS.................................................................................................
x
LISTA DE TABELAS................................................................................................
x
iii
1.
INTRODUÇÃO..................................................................................................
1
1.1
C
ONTEXTO
...............................................................................................
1
1.2
P
ROBLEMA
...............................................................................................
4
1.3
C
ONTRIBUIÇÕES
.......................................................................................
6
1.4
O
BJETIVOS
...............................................................................................
6
1.5
J
USTIFICATIVA
..........................................................................................
7
1.6
E
SCOPO DA
D
ISSERTAÇÃO
........................................................................
7
1.7
METODOLOGIA
.........................................................................................
8
1.8
O
RGANIZAÇÃO DA
D
ISSERTAÇÃO
.............................................................
10
2.
DESENVOLVIMENTO DE SOFTWARE ORIENTADO A ASPECTOS.......
12
2.1
C
ONCEITOS
G
ERAIS DE
AOSD...
..............................................................
13
2.1.1
C
ONCEITOS DE ASPECTOS
,
CONCERN E CROSSCUTT
ING
CONCER
NS
.................................................................................
14
2.1.2
S
EPARAÇÃO DE
P
ROPRIEDADES
.................................................
15
2.1.3
C
OMPOSIÇÃO DE
P
ROPRIEDADES
..............................................
20
2.1.4
A
P
ROGRAMAÇÃO
O
RIENTADA A
A
SPECTOS E A
L
INGUAGEM
A
SPECT
J
...................................................................................
22
2.2
F
ASE DE
R
EQUISITOS
...............................................................................
26
2.2.1
A
BORDAGEM DE
V
IEWPOINT
.....................................................
26
2.2.2
A
BORDAGEM AORE
UTILIZANDO
UML
...................................
30
2.2.3
A
BORDAGEM
GOALS...............................................................
37
2.2.4
A
BORDAGEM COM
C
ASOS DE
U
SO
.............................................
42
2.2.5
A
BORDAGEM
T
HEME
/DOC......................................................
48
2.3
C
OMPARAÇÃO DAS ABORDAGENS APRESENTADAS
..................................
54
2.4
R
ESUMO DO
C
APÍTULO
............................................................................
64
3
A METODOLOGIA MDSODI E O AMBIENTE DISEN.................................
65
3.1
A
M
ETODOLOGIA
MDSODI.....................................................................
66
3.2
O
A
MBIENTE
D
I
SEN
................................................................................
70
3.3
A
F
ERRAMENTA
REQUISITE.................................................................
72
3.3.1
A
SPECTOS
F
UNCIONAIS
.............................................................
74
3.3.2
A
ARQUITETURA DA
REQUISITE.............................................
76
3.3.3
E
XEMPLO DE
I
NSTÂNCIAS DA
REQUISITE
NO
D
I
SEN
.............
79
3.4
R
ESUMO DO
C
APÍTULO
.............................................................................
81
4.
A ABORDAGEM DAORE................................................................................
82
4.1
O
BJETIVOS E
D
IRETRIZES
P
RINCIPAIS
.......................................................
83
4.2
O P
ROCESSO DE
D
ESENVOLVIMENTO
P
ROPOSTO
......................................
89
4.2.1
F
ASE
1
–
CONSTRUÇÃO
D
OS
REQUISITOS
..................................
90
xvi
4.2.1.1
L
EVANTAMENTO DOS REQU
ISITOS
..............................
90
4.2.1.2
C
ONSTRUÇÃO DE REQUISI
TOS FUNCIONAIS
.................
91
4.2.1.3
C
ONSTRUÇÃO DE REQUISI
TOS NÃO FUNCIONAIS
.........
91
4.2.1.4
C
ONSTRUÇÃO
DE REQUISITOS ORGAN
IZACIONAIS
......
98
4.2.2
F
ASE
2
–
C
ONSTRUÇÃO DO
LEL...............................................
100
4.2.3
F
ASE
3
–
D
EFININDO ASPECTOS
C
ANDIDATOS
...........................
102
4.2.3.1
I
DENTIFICANDO
C
ONTRIBUIÇÕES
............................
103
4.2.3.2
D
EFININDO
C
OMPOSIÇÃO
........................................
104
4.2.3.3
I
DENTIFICANDO
C
ONFLITOS
....................................
105
4.2.4
F
ASE
4
-
M
APEAMENTO DE
O
NTOLOGIAS
.................................
107
4.2.5
G
ERAÇÃO DE
A
RQUIVOS PARA
E
XPORTAÇÃO...........................
108
4.3
C
O
NSIDERAÇÕES SOBRE A ABORDAGEM
DAORE....................................
109
4.3.1
C
OM
R
ELAÇÃO AOS
O
BJETIVOS
P
ROPOSTOS
.............................
109
4.3.2
U
SO NA
R
EQUISITE E NO
P
ROJETO
D
I
SEN
.................................
110
4.3.3
D
IFERENÇAS
COM AS
A
BORDAGENS
E
STUDADAS......................
111
4.4
R
ESUMO DO
C
APÍTULO
.............................................................................
111
5.
EXPERIMENTAÇÃO: CONTROLE DE EVENTOS.......................................
113
5.1
O
B
JETIVOS
...............................................................................................
114
5.2
A
ESCOLHA DA
F
ERRAMENTA DE
I
MPLEMENTAÇÃO
.................................
114
5.3
O
SISTEMA
P
ROPOSTO
..............................................................................
115
5.4
F
ASE
1
-
I
DENTIFICA
NDO
OS
R
EQUISITOS
................................................
116
5.5
F
ASE
2
–
C
ONSTRUINDO O
L
ÉXICO
...........................................................
118
5.5.1
A
NALISAND
O INTERDEPENDÊNCIAS
E RESOLVENDO CONFLIT
OS
129
5.5.2
C
ONSTRUINDO OS CENÁRI
OS
.....................................................
129
5.5.3
A
NALISANDO OS CENÁRIO
S
.......................................................
139
5.6
F
ASE
3
-
D
EFINIÇÃO DE
A
SPECTOS
C
ANDIDATOS
.....................................
139
5.7
F
ASE
4
-
M
APEAMENTO DE
O
NTOLOGIAS
.................................................
147
5.8
G
ERAÇÃO DE
A
RQUIVOS PARA
E
XPORTAÇÃO..........................................
154
5.9
R
ESUMO D
O
C
APITULO
.............................................................................
157
6
A FERRAMENTA REQUISITE E A ABORDAGEM DAO
RE.......
................
158
6.1
S
ITUAÇÃO
A
TUAL
....................................................................................
158
6.1.1
M
ENU
P
RINCIPAL DA
R
EQUISITE
159
6.2
S
ITUAÇÃO
F
UTURA
............................................................................
.......
161
6.2.1
P
ROJETO D
I
SEN........................................................................
161
6.2.2
M
UDANÇAS
P
REVISTAS NA
R
EQUISITE
......................................
162
6.2.3
ANÁLISE DO
I
MPACTO DAS
M
UDANÇAS
.....................................
171
6.3
R
ESUMO DO
C
APÍTULO
.............................................................................
176
7
CONCLUSÃO....................................................................................................
177
7.1
C
ONTRIBUIÇÕES
.......................................................................................
177
7.2
L
IMITAÇÕES E
T
RABALHOS
F
UTUROS
......................................................
178
7.3
C
ONSIDERAÇÕES
F
INAIS
...........................................................................
179
7.4
T
RABALHOS SUBMETIDOS
........................................................................
180
REFERÊNCIAS
BILBIOGRÁFICAS................................................................
182
ANEXOS............................................................................................................
189
Índice
1. Introdução
1
C
APÍTULO
1
1
I
NTRODUÇÃO
The best preparation for good work
tomorrow is to do good work today.
Elbert Hubbard
N
N
e
e
s
s
t
t
e
e
c
c
a
a
p
p
í
í
t
t
u
u
l
l
o
o
a
a
p
p
r
r
e
e
s
s
e
e
n
n
t
t
a
a
m
m
o
o
s
s
u
u
m
m
a
a
v
v
i
i
s
s
ã
ã
o
o
g
g
e
e
r
r
a
a
l
l
d
d
a
a
p
p
r
r
o
o
p
p
o
o
s
s
t
t
a
a
d
d
e
e
d
d
i
i
s
s
s
s
e
e
r
r
t
t
a
a
ç
ç
ã
ã
o
o
.
.
I
I
n
n
i
i
c
c
i
i
a
a
l
l
m
m
e
e
n
n
t
t
e
e
,
,
d
d
e
e
s
s
c
c
r
r
e
e
v
v
e
e
m
m
o
o
s
s
o
o
c
c
o
o
n
n
t
t
e
e
x
x
t
t
o
o
n
n
o
o
q
q
u
u
a
a
l
l
e
e
s
s
t
t
e
e
t
t
r
r
a
a
b
b
a
a
l
l
h
h
o
o
d
d
e
e
p
p
e
e
s
s
q
q
u
u
i
i
s
s
a
a
s
s
e
e
i
i
n
n
s
s
e
e
r
r
e
e
.
.
A
A
s
s
e
e
g
g
u
u
i
i
r
r
,
,
d
d
i
i
s
s
c
c
u
u
t
t
i
i
m
m
o
o
s
s
q
q
u
u
a
a
l
l
o
o
p
p
r
r
o
o
b
b
l
l
e
e
m
m
a
a
q
q
u
u
e
e
p
p
r
r
e
e
t
t
e
e
n
n
d
d
e
e
m
m
o
o
s
s
r
r
e
e
s
s
o
o
l
l
v
v
e
e
r
r
e
e
q
q
u
u
a
a
i
i
s
s
o
o
s
s
o
o
b
b
j
j
e
e
t
t
i
i
v
v
o
o
s
s
e
e
f
f
i
i
n
n
a
a
l
l
i
i
d
d
a
a
d
d
e
e
s
s
d
d
a
a
p
p
e
e
s
s
q
q
u
u
i
i
s
s
a
a
,
,
p
p
o
o
r
r
f
f
i
i
m
m
a
a
p
p
r
r
e
e
s
s
e
e
n
n
t
t
a
a
m
m
o
o
s
s
a
a
m
m
e
e
t
t
o
o
d
d
o
o
l
l
o
o
g
g
i
i
a
a
d
d
e
e
p
p
e
e
s
s
q
q
u
u
i
i
s
s
a
a
q
q
u
u
e
e
f
f
o
o
i
i
a
a
d
d
o
o
t
t
a
a
d
d
a
a
,
,
d
d
e
e
l
l
i
i
m
m
i
i
t
t
a
a
m
m
o
o
s
s
o
o
e
e
s
s
c
c
o
o
p
p
o
o
d
d
a
a
p
p
r
r
o
o
p
p
o
o
s
s
t
t
a
a
d
d
e
e
d
d
i
i
s
s
s
s
e
e
r
r
t
t
a
a
ç
ç
ã
ã
o
o
e
e
d
d
e
e
s
s
c
c
r
r
e
e
v
v
e
e
m
m
o
o
s
s
a
a
e
e
s
s
t
t
r
r
u
u
t
t
u
u
r
r
a
a
d
d
o
o
s
s
c
c
a
a
p
p
í
í
t
t
u
u
l
l
o
o
s
s
d
d
e
e
s
s
t
t
e
e
t
t
r
r
a
a
b
b
a
a
l
l
h
h
o
o
.
.
1
1
.
.
1
1
C
C
o
o
n
n
t
t
e
e
x
x
t
t
o
o
O processo de desenvolvimento de sistemas de informação sofreu uma quebra de
paradigma com o surgimento da orientação a objetos na década de 80
(
SHAELER
&
MELLOR
, 19
90)
. Até então, os sistemas eram desen
volvidos de forma procedural e
estruturada, isso quando eram desenvolvidos seguindo um processo de desenvolvimento, pois
a maioria ignorava os conceitos propostos ou até mesmo desconheciam o processo em si.
Infelizmente, os conceitos advindos com a orienta
ção a objetos
não eram fáceis de
se
incorporar ao cotidiano, mesmo que os defensores da orientação a objetos afirmassem que
“
a
orientação a objetos é uma
coisa natural
,
pois o mundo
é
orientado a objetos
”
1. Introdução
2
(
www.forumweb.com.br/artigos/artigos.php?
action=file&id=535
).
Muitas vezes, estas dificuldades
na assimilação dos conceitos se deviam à formação
acadêmica, por esta
ser de base
estruturada e
,
por outra
,
ser uma maneira completamente diferente de abstrair conceitos do
mundo real.
Atualmente, uma nova abord
agem no desenvolvimento de sistemas tem sido
pesquisada e utilizada: o
D
esenvolvimento de
S
istemas baseado na
O
rientação a
A
spectos
-
AOSD
.
Esta abordagem, em parte, segue os conceitos de
(
DIJKSTRA, 1976
)
, que
apresenta o princípio da separação de
concerns
1
, onde para superar a complexidade, deve
-
se
resolver um
concern
importante por vez. Em engenharia de software, esse princípio está
relacionado à
modularização
e à
decomposição
de sistemas
(
PARNAS, 1972
)
. Os sistemas de
software complexos devem ser decompo
stos em unidades modulares menores e claramente
separados, cada uma lidando
com um único
concern
. Se bem realizada, a separação de
concerns
pode oferecer muitos benefícios cruciais
(
DIJKSTRA, 1976
)
(
TARR, 1999
)
. Ela
oferece suporte a uma melhor manutenibilidade com alterações aditivas, em vez de evasivas,
melhor compreensão e redução da complexidade, melhor reusabilidade e uma integração de
componentes simplificada.
Para
(
ELRAD
et al.,
2001
apud
SOUZA
,
2004), assim c
omo o paradigma
orientado a objetos (POO)
não descarta as idéias de dados e operações do paradigma
estrutural, o paradigma orientado a aspectos (POA) não rejeita a tecnologia existente. O
paradigma orientado a aspectos complementa o paradigma orientado a objetos a fim de
auxiliar na separação daq
uelas preocupações que o POO manipula deselegantemente
(não
possuindo recursos para fazer tal tarefa, necessitando de outras formas que tornam o código
mais
difícil de
entender e manutenir)
. Para isso, o paradigma orientado a aspectos provê
mecanismos para localizar e compor
os
crosscutting concern
s
2
(ou aspectos)
c
om as unidades
que el
es
afeta
m
de maneira não invasiva, ou seja, evitando que fiquem explicitamente
espalhad
os nos artefatos de software ou misturados com as preocupações específicas desses
artef
atos.
Esse é um paradigma emergente
(
ELRAD et al., 2001
apud SOUZA, 2004)
e, o
estado atual da pesquisa nessa área pode ser comparado ao estado da pesquisa em orientação a
1
Um concern pode ser definido como: questão, característica ou preocupação. Porém, neste trabalho
utilizaremos o termo em inglês.
2
Crosscutting concerns podem ser traduzidos como preocupações ou caracterís
ticas transversais.
Em
Piveta
(2004) foi proposto que se utilizasse o termo concerns transversais, p
orém, neste trabalho, utilizaremos o termo
em inglês.
1. Introdução 3
objetos há vinte anos atrás: os conceitos básicos estão se formando e um grupo cresc
ente de
pesquisadores está usando esses conceitos em seus trabalhos sobre orientação a aspectos.
As pesquisas realizadas em
Early Aspects têm evoluído
muito desde 2002
(
RASHID et al, 2002
). Por conseqüência, várias abordagens têm se preocupado com a
identi
ficação de aspectos nas fases iniciais do desenvolvimento, principalmente na fase de
requisitos, como a Abordagem
Viewpoint
(
RASHID
et al
.
, 2002
) (
RASHID
et al.
, 2003
)
,
Metas
(
YU
et al.
, 2004
) (
S
ILVA&LEITE, 2005
b)
, Casos de Uso
(
JACOBSON
&NG
, 2005
)
(
SOUZA, 2004
)
e
Theme/DOC
(
CLARKE&BANIASSAD, 2005
). Estas abordagens tiveram
início na orientação não aspectos e foram adaptadas e desenvolvidas a fim de se moldar ao
novo paradigma da orientação a aspectos.
Ainda se tratando da abordagem
orientada a objetos
, muit
os projetos se
desenvolveram utilizando esta abordagem em Universidades Brasileiras (UFPE, UEM, UFRJ,
PUC
-
Rio, entre outras) e ainda estão em desenvolvimento, mesmo porque, a abordagem de
aspectos não chega a ser uma quebra de paradigmas, mas sim uma exten
são da abordagem
que está sendo utilizada (JACOBSON
&NG
, 2005).
No Paraná, mais especificamente na Universidade Estadual de Maringá (UEM)
,
membros do Grupo de Estudos e Pesquisa de Sistemas de Software Distribuídos
(
GESSD
),
desenvolvem vários trabalhos rel
acionados à Metodologia de Desenvolvimento de Software
Distribuído
– MDSODI (GRAVENA, 2000) (HUZITA, 1999) .
A
MDSODI
é uma metodologia de desenvolvimento de software que oferece
suporte à especificação de alguns aspectos relacionados a sistemas distribuíd
os desde as fases
iniciais de projeto. A notação desta metodologia baseia
-
se na
Unified Modeling Language
–
UML (
UML
, 200
6), mas adota também algumas extensões para a representação de sistemas
distribuídos. Dessa forma é possível abordar de forma clara os
aspectos relacionados à
distribuição do sistema desde, as fases iniciais do processo de desenvolvimento de software.
Como a MDSODI é uma metodologia que cobre todo o processo de
desenvolvimento de software, é natural imaginar
-
se um cenário onde serão utili
zadas várias
ferramentas de apoio ao desenvolvimento de software cada qual criando e, possibilitando a
manutenção necessária dos vários artefatos relativos às diversas fases do processo. Estas
ferramentas poderão ter sido criadas especialmente para esta me
todologia, ou então serem
ferramentas já existentes no mercado, produzidas por terceiros, cada uma com sua
especialidade e potencialidade.
Na mesma universidade, existe também o projeto de um
ambiente distribuído de
desenvolvimento de software, denominado
Distributed Software Engineering Environment
-
1. Introdução 4
DiSEN (PASCUTTI, 2002)
(HUZITA,2004)
.
O ambiente
DiSEN foi concebido com vistas à
utilização da metodologia MDSODI, enquanto que na sua arquitetura, pode
-
se observar que o
mesmo oferece suporte a agentes. Ente
nde
-
se, que neste ambiente, estarão sendo utilizadas
várias ferramentas de desenvolvimento de software, onde cada uma delas estará produzindo
artefatos como resultados do trabalho do desenvolvedor de software.
No ambiente
do projeto
DiSEN a preocupação com
o gerenciamento d
e requisitos
surgiu com a elaboração de uma ferramenta própria a REQUISITE
(
BATISTA, 2003
)
. Esta
ferramenta
foi desenvolvida baseada nos conceitos de orientação a objetos, seguindo ainda a
metodologia MDSODI para ambientes distribuídos, p
orém não considera os
crosscutting
concerns
, tanto em nível de desenvolvimento da ferramenta em si como em nível de projeto
dos requisitos inseridos.
A elaboração de uma nova abordagem que contemple a identificação e composição
dos crosscutting concerns e
que esteja inserida no contexto da metodologia MDSODI
permitirá a atualização dos projetos a serem desenvolvidos e os que estão atualmente sendo
desenvolvidos, como o projeto do ambiente DiSEN e suas ferramentas
de apoio
.
1
1
.
.
2
2
P
P
r
r
o
o
b
b
l
l
e
e
m
m
a
a
As motivações para
o surgimento do paradigma orientado a aspectos originaram
-
se, principalmente, a partir de problemas encontrados na codificação de sistemas. Por isso, a
maior parte da pesquisa nessa área tem sido focada nas atividades orientadas
à
implementação. Atualment
e, a orientação a aspectos vem sendo utilizada
,
quase
que
exclusivamente, na codificação de sistemas através de linguagens como AspectJ
(
KICZALES,
2001
)
e Hyper/J
(
OSSHER
&TARR, 2000
)
.
Recentemente, a comunidade de Engenharia de Software tem se interessado
em
propagar a utilização dos fundamentos e práticas desse paradigma para as atividades iniciais
do ciclo de desenvolvimento
(
SOUZA
, 2004
)
. Algumas das razões que impulsionam essa área
de pesquisa são:
·
Antecipar a identificação e a modelagem de aspectos;
·
A
ntecipar o raciocínio sobre qu
ais
unidades devem ser afetadas por um aspecto e
como a composição entre o aspecto e as unidades afetadas por ele deve ser realizada;
·
Permitir que os benefícios da utilização do paradigma orientado a aspectos sejam
obtidos ao
longo de todo processo de desenvolvimento e não apenas nos artefatos de
implementação;
1. Introdução 5
·
Possibilitar que o entendimento de um sistema implementado com uma linguagem
orientada a aspectos possa ser obtido através de modelos de análise e projeto, ao invés
de e
xigir que ele dependa da análise do código do sistema.
Desde 2002
, algumas abordagens iniciais vêm sendo propostas nesse sentido.
Alguns trabalhos já se preocupam com outras fases do desenvolvimento, desde requisitos até
a implementação, (SOUZA, 2004)
(JAC
OBSON
&
NG
, 2005)
(CLARKE
&
BANIASSAD
,
2005)
. Porém, todos os trabalhos pesquisados não possuem uma maneira clara e objetiva de
tratar alguns problemas relacionados à fase de requisitos
. Alguns problemas gerais
encontrados foram:
·
A identificação e tratamento de requisitos organizacionais;
·
A identificação de
crosscutting concerns
(sendo estes funcionais, não
-
funcionais ou
até mesmo organizacionais);
·
Representação gráfica do modelo, em muitos casos o modelo não é adequado ou a
ferramenta para tal não está dis
ponível, como podemos observar no Capítulo 3, onde
realizamos um estudo comparativo das abordagens existentes; e
·
Em algumas abordagens, a representação dos requisitos não funcionais (RNF)
(CHUNG
et al.
, 2000) se confunde com características adicionais do s
istema, como no
trabalho de Jacobson & Ng
(200
5
).
Adicionalmente podemos citar alguns problemas específicos ligados a
o
nosso
projeto no ambiente DISEN:
·
Inserção no contexto da metodologia MDSODI;
·
Exportação d
e
modelo
s
no padrão XM
L
,
u
sando XML
3
Schema
par
a
definir padrões
a serem utilizados. Estes modelos englobam: Léxico Extendido da Linguagem
4
(LEL),
aspectos candidatos
5
, cenários
6
e ontologias
7
.
Algumas abordagens
estudadas, relativas à fase de requisitos,
como:
como a
Abordagem Viewpoint
(
RASHID
et al., 2002
) (
RASHID
et al., 2003
)
, Metas
(
YU
et al.
, 2004
)
(
S
ILVA & LEITE
, 2005
b)
, Casos de Uso
(
JACOBSON
& NG
, 2005
) (
SOUZA,
2004
)
e
Theme
/
DOC
(
CLARKE
& BANIASSAD
, 2005
)
,
possuem vantagens e desvantagens em
relação a outras. Esse fato foi a principal motivação para o desenvolvimento desta
proposta de
3
Uma definição de XML Schema e seus conceitos principais
podem ser encontrados em XML (2006)
.
4
LEL
–
Léxico Extendido da Linguagem (Language Extended Lexicon), técnica que auxilia a descrição de
cenários utilizando linguagem natural
–
encontramos também o termo LAL (Léxico Ampliado da Linguagem)
que significa a mesma coisa
(Leite, 1997)
5
Veremos os con
ceitos de aspectos candidatos no Capítulo 3.
6
Conceitos de cenários e sua relação com o LEL
podem ser encontrados em Leite (1997)
.
7
Conceitos de ontologias pode ser
encontradas em Breitman (2005)
.
1. Introdução 6
dissertação (veremos mais no Capítulo 3, item 3.5
-
Análise Comparativa das Abordagens em
AORE)
.
1
1
.
.
3
3
C
C
o
o
n
n
t
t
r
r
i
i
b
b
u
u
i
i
ç
ç
õ
õ
e
e
s
s
A principal contribuição deste trabalho é integrar a metodologia MDSODI ao
desenvolvimento de software orientado a aspectos.
Esta contribuição é baseada na técnica do LEL utilizada pelo ambiente DISEN na
elicitação dos requisitos através da ferramenta Requisite.
Com o desenvolvimento de uma
nova abordagem que possa integrar o LEL na orientação a
aspectos, de forma a facilitar a
identificação dos aspectos candidatos nas fases iniciais do processo de desenvolvimento, irá
contribuir para aumentar o reuso de componentes especificados.
1
1
.
.
4
4
O
O
b
b
j
j
e
e
t
t
i
i
v
v
o
o
s
s
O objetivo geral desta dissertação é apresentar
uma
nova abordage
m de o
rientação
a aspectos
para
a fase
de engenharia de requisitos
, que se utilize do LEL,
para que possa
facilitar a identificação e
a separação de
concerns
nos projetos
elaborados com base na
metodologia MDSODI.
A partir desse objetivo geral, definimos os seguintes objetivos específicos:
-
Compreender os fundamentos do Desenvolvimento de Sistemas baseado na
Orientação a Aspectos nas fases iniciais do processo de desenvolvimento;
-
Propor uma nova
abordagem através da análise e seleção de pontos
de vantagens
oferecidas pelas abordagens existentes, permitindo uma abordagem mais flexível
que
possibilite o suporte tanto na adaptação de projetos existe
ntes
(por se utilizar do LEL)
quanto para novos projetos; e
-
Realizar
a validação
utilizando a aborda
gem proposta através da experimentação,
onde
o projeto a ser desenvolvido
será o mesmo apresentado pela ferramenta REQUISITE
para que se possa avaliar o impacto das mudanças propostas na ferramenta e no
ambiente DISEN.
1. Introdução
7
1
1
.
.
5
5
J
J
u
u
s
s
t
t
i
i
f
f
i
i
c
c
a
a
t
t
i
i
v
v
a
a
Os fundamentos do paradigma orientado a aspectos podem ser usados de
maneira
complementar aos do paradigma orientado a objetos
8
(SOUZA
, 200
4)
.
Por isso, o paradigma
orientado a aspectos pode ser considerado uma evolução, não
uma revolução, em relação ao
paradigma orientado a objetos e pode ser usado para melhorar técnicas existentes.
A quebra de paradigmas sempre foi um grande problema na área de
desenvolvimento de sistemas, em particular na década de 80 com o surgimento da orientação
a objetos. Podemos dizer que foi u
ma grande revolução, pois apresentava conceitos até então
desconhecidos e completamente diferentes dos usados na época.
A orientação a aspectos, por outro lado, não apresenta conceitos tão diferentes
assim, pois ela apenas agrega alguns conceitos
à
aborda
gens que já existem. Desde o seu
surgimento, no fim da década de 90, voltada apenas para a implementação, é um exemplo
disso, uma vez que adicionava construções e mecanismos específicos para o tratamento de
aspectos em linguagens de programação, como
Aspec
tJ (
KICZALES., 2001
), que estende a
linguagem orientada a objetos Java (GOSLING et al., 2000
).
Atualmente, as abordagens existentes em orientação a aspectos possuem algumas
vantagens, como:
(i)
Descrição detalhada das fases principais do desenvolvimento;
(ii)
Carac
terísticas próprias definidas pelo tipo de abordagem considerada;
Porém, todas possuem uma característica negativa: não
oferece
apoio
à
identificação de aspectos.
Pelos motivos acima descritos, a direção que escolhemos para alcançar o
objetivo
geral deste
trabalho
foi o de propor
uma
nova
abordagem que
facilite a identificação de
aspectos nas fases in
iciais do processo
de desenvolvimento utilizando a metodologia
MDSODI para sistemas distribuídos, que estejam inseridas no contexto de cenários utilizando
o LE
L.
1
1
.
.
6
6
E
E
s
s
c
c
o
o
p
p
o
o
d
d
a
a
D
D
i
i
s
s
s
s
e
e
r
r
t
t
a
a
ç
ç
ã
ã
o
o
Conforme mencionado anteriormente, para alcançar o objetivo geral desta
dissertação,
decidimos adaptar algumas características das abordagens existentes para as fases
iniciais do processo de desenvolvimento.
8
Mas não se limita ao paradigma orientado a objetos, pod
endo ser usado também em conjunto com outros
paradigmas como o estruturado e o funcional
(
CONSTANTINIDES & HASSOUN, 2002
)
.
1. Introdução 8
Nosso trabalho fo
cará a fase de requisitos, uma vez que as abordagens estudadas
se referem, principalmente,
à
fase de requisitos e que nosso objetivo é identificar os aspectos
nesta fase. Assim, deixaremos de abordar o tratamento de projeto, implementação e testes,
sendo um trabalho a ser feito futuramente.
1
1
.
.
7
7
M
M
e
e
t
t
o
o
d
d
o
o
l
l
o
o
g
g
i
i
a
a
d
d
e
e
D
D
e
e
s
s
e
e
n
n
v
v
o
o
l
l
v
v
i
i
m
m
e
e
n
n
t
t
o
o
d
d
a
a
P
P
e
e
s
s
q
q
u
u
i
i
s
s
a
a
A pesquisa em Engenharia de
Software
pode ser conduzida através de quatro
métodos: o científico, o de engenharia, o experimental e o analítico
(
WOHLIN, 2000 apud
TRAVASSOS, 2002
)
.
O método científico foca na observação de um ambiente e na tentativa de extrair
dele algum modelo ou teoria que possa explicar o fenômeno estudado. O método de
engenharia, por sua vez, é baseado na observação de soluções existentes, na identificaç
ão de
problemas nessas soluções e na sugestão de abordagens para melhorar as soluções analisadas.
Já o método experimental pretende fornecer um modelo novo para solução de um problema e
tenta estudar o impacto desse modelo. Por fim, o método analítico ofer
ece uma base analítica
(ou matemática) para o desenvolvimento de modelos.
Este trabalho de pesquisa segui
u
o método de engenharia (baseado na Figura 1.1).
1. Introdução 9
1
-
Revisão
Bibliográfica
2
-
Análise das
Abordagens
4
-
Elaboração
da Nova
Abordagem
5
-
Aplicação
na nova
Abordagem
6
-
Validação
7
-
Apresentação
-
AOSD
-
MDSODI, DISEN e REQUISITE
-
Abordagens existentes em
AORE
-
Análise Comparativa
;
-
Definição de pontos principais
a serem considerados
-
Nova abordagem a partir dos
pontos considerados
-
através da experimentação
-
Análise do impacto das
mudanças no ambiente DISEN
e
na ferramenta REQUISITE
-
Apresentação da dissertação
3 –
Exame de
Qualificação
-
Apresentação da proposta de
qualificação
F
IGURA
1.1
–
E
STRUTURA DA
P
ESQUISA SEGUIDA
.
Na Figura 1.1 temos a estrutura de pesquisa que foi seguida:
1.
Inicialmente
foi
feit
a
um
a revisão bibliográfica sobre os conceitos de
AOSD, a metodologia MDSODI, o ambiente DISEN e a ferramenta
REQUISITE. Após isso,
foi elaborado
um
estudo sobre
algumas
abordagens existentes pa
ra a
AORE
:
Viewpoint
(
RASHID
et al.
, 2002
)
(
RASHID
et al.,
2003
)
, Metas
(
YU
et al.
,
2004
) (
S
ILVA & LEITE,
2005
b)
,
Casos de Uso
(
JACOBSON
& NG
, 2005
) (
SOUZA,
2004
)
e
Theme
/
DOC
(
CLARKE
& BANIASSAD,
2005
)
;
1. Introdução
10
2.
Nesta fase foi
realizada
uma análise comparativa da
s abordagens
para
identificar os conceitos, vantagens e desvantagens de cada uma
, ou seja, os
elementos relevantes foram identificados e mapeados;
3.
Foi
apresentada
a proposta de qualificação para o mestrado;
4.
Baseado nos pontos considerados no passo 2
foi elaborad
a
a nova
abordagem
de forma a apresentar características identificadas em algumas
das abordagens estudadas, além de possuir características próprias
;
5.
A
plicação da nova abordagem em um estudo de caso
para validar a mesma.
Este estudo de caso foi o mes
mo realizado por ocasião da validação da
ferramenta REQUISITE, a fim de se obter um comparativo de avaliação
utilizando duas abordagens diferentes
;
6.
A
nálise das mudanças para avaliar o impacto n
a ferramenta REQUISITE e
no
projeto
DISEN
, com o objetivo de s
ugerir mudanças e pontos críticos
para a validação da nova abordagem, ou seja
,
o quanto esta mudança foi
benéfica para o projeto
;
e
7.
A
presentação do trabalho.
1
1
.
.
8
8
O
O
r
r
g
g
a
a
n
n
i
i
z
z
a
a
ç
ç
ã
ã
o
o
d
d
a
a
D
D
i
i
s
s
s
s
e
e
r
r
t
t
a
a
ç
ç
ã
ã
o
o
Além deste
capítulo
introdutório e de um glossário
e um anexo
que
incluímos no
final da
dissertação, este trabalho é composto pelos seguintes capítulos:
·
Capítulo
2
:
a
presen
t
a uma visão geral do
Desenvolvimento Orientado a Aspectos
e
descreve
algumas
abordagens utilizadas para
a
fase d
e Requisitos.
Ao final do capítulo
é apresentado um comparativo entre as abordagens. Este estudo comparativo foi
utilizad
o como base da confecção da
nova
abordagem
;
·
Capítulo
3
: apresenta uma visão geral sobre
a metodologia MDSODI, o ambiente
DiSEN e a ferramenta REQUISITE e como se relacionam;
·
Capítulo
4
:
detalha
a
nova abordagem, descrevendo em cada fase o que dever ser feito;
·
Capítulo
5
:
descreve a utilização da abordagem apresentada no Capítulo 4
em um
a
experimentação
. O objetivo principal é propiciar a validação da nova abordagem, de
man
eira que se possa avaliar o impacto sobre
a ferramenta REQUISITE e
o projeto
DiSEN
;
1. Introdução 11
·
Capítulo
6
:
a
presenta o impacto da abordagem DAORE na ferramenta Requisite, suas
principais implicações, análises e comparações; e
·
Capítulo
7
:
a
presenta as conclusões, enum
era as contribuições e propõe trabalhos
futuros
.
2.Desenvolvimento de Software Orientado a Aspectos 12
C
APÍTULO
2
2
DESENVOLVIMENTO DE
S
OFTWARE
O
RIENTADO A
A
SPECTOS
O que sabemos é uma gota, o que ignoramos é um oceano.
Isaac
Newton
O
O
d
d
e
e
s
s
e
e
n
n
v
v
o
o
l
l
v
v
i
i
m
m
e
e
n
n
t
t
o
o
d
d
e
e
s
s
o
o
f
f
t
t
w
w
a
a
r
r
e
e
t
t
e
e
m
m
s
s
i
i
d
d
o
o
a
a
l
l
v
v
o
o
d
d
e
e
e
e
s
s
t
t
u
u
d
d
o
o
s
s
(
(
C
C
H
H
I
I
T
T
C
C
H
H
Y
Y
A
A
N
N
e
e
t
t
a
a
l
l
,
,
2
2
0
0
0
0
5
5
b
b
)
)
(
(
S
S
I
I
L
L
V
V
A
A
,
,
2
2
0
0
0
0
4
4
)
)
a
a
f
f
i
i
m
m
d
d
e
e
g
g
a
a
r
r
a
a
n
n
t
t
i
i
r
r
a
a
q
q
u
u
a
a
l
l
i
i
d
d
a
a
d
d
e
e
d
d
o
o
p
p
r
r
o
o
d
d
u
u
t
t
o
o
f
f
i
i
n
n
a
a
l
l
,
,
o
o
u
u
s
s
e
e
j
j
a
a
,
,
o
o
s
s
o
o
f
f
t
t
w
w
a
a
r
r
e
e
e
e
m
m
s
s
i
i
,
,
e
e
d
d
o
o
p
p
r
r
ó
ó
p
p
r
r
i
i
o
o
p
p
r
r
o
o
c
c
e
e
s
s
s
s
o
o
d
d
e
e
d
d
e
e
s
s
e
e
n
n
v
v
o
o
l
l
v
v
i
i
m
m
e
e
n
n
t
t
o
o
q
q
u
u
e
e
o
o
d
d
e
e
f
f
i
i
n
n
i
i
u
u
.
.
I
I
s
s
t
t
o
o
t
t
e
e
m
m
o
o
c
c
o
o
r
r
r
r
i
i
d
d
o
o
d
d
e
e
s
s
d
d
e
e
m
m
e
e
a
a
d
d
o
o
s
s
d
d
a
a
d
d
é
é
c
c
a
a
d
d
a
a
d
d
e
e
7
7
0
0
c
c
o
o
m
m
o
o
d
d
e
e
s
s
e
e
n
n
v
v
o
o
l
l
v
v
i
i
m
m
e
e
n
n
t
t
o
o
e
e
s
s
t
t
r
r
u
u
t
t
u
u
r
r
a
a
d
d
o
o
,
,
s
s
e
e
n
n
d
d
o
o
a
a
A
A
n
n
á
á
l
l
i
i
s
s
e
e
E
E
s
s
t
t
r
r
u
u
t
t
u
u
r
r
a
a
d
d
a
a
d
d
e
e
S
S
i
i
s
s
t
t
e
e
m
m
a
a
s
s
o
o
r
r
i
i
u
u
n
n
d
d
a
a
d
d
a
a
p
p
r
r
o
o
g
g
r
r
a
a
m
m
a
a
ç
ç
ã
ã
o
o
e
e
s
s
t
t
r
r
u
u
t
t
u
u
r
r
a
a
d
d
a
a
.
.
O
O
D
D
e
e
s
s
e
e
n
n
v
v
o
o
l
l
v
v
i
i
m
m
e
e
n
n
t
t
o
o
d
d
e
e
S
S
o
o
f
f
t
t
w
w
a
a
r
r
e
e
O
O
r
r
i
i
e
e
n
n
t
t
a
a
d
d
o
o
a
a
A
A
s
s
p
p
e
e
c
c
t
t
o
o
s
s
(
(
A
A
O
O
S
S
D
D
)
)
é
é
a
a
d
d
v
v
i
i
n
n
d
d
o
o
d
d
a
a
p
p
r
r
o
o
g
g
r
r
a
a
m
m
a
a
ç
ç
ã
ã
o
o
o
o
r
r
i
i
e
e
n
n
t
t
a
a
d
d
a
a
a
a
a
a
s
s
p
p
e
e
c
c
t
t
o
o
s
s
,
,
a
a
s
s
s
s
i
i
m
m
c
c
o
o
m
m
o
o
f
f
o
o
i
i
n
n
a
a
é
é
p
p
o
o
c
c
a
a
d
d
o
o
d
d
e
e
s
s
e
e
n
n
v
v
o
o
l
l
v
v
i
i
m
m
e
e
n
n
t
t
o
o
e
e
s
s
t
t
r
r
u
u
t
t
u
u
r
r
a
a
d
d
o
o
d
d
e
e
s
s
i
i
s
s
t
t
e
e
m
m
a
a
s
s
.
.
A
A
s
s
t
t
é
é
c
c
n
n
i
i
c
c
a
a
s
s
e
e
x
x
i
i
s
s
t
t
e
e
n
n
t
t
e
e
s
s
d
d
e
e
A
A
O
O
S
S
D
D
p
p
r
r
o
o
v
v
ê
ê
m
m
u
u
m
m
a
a
f
f
o
o
r
r
m
m
a
a
s
s
i
i
s
s
t
t
e
e
m
m
á
á
t
t
i
i
c
c
a
a
d
d
e
e
i
i
d
d
e
e
n
n
t
t
i
i
f
f
i
i
c
c
a
a
r
r
,
,
m
m
o
o
d
d
u
u
l
l
a
a
r
r
i
i
z
z
a
a
r
r
,
,
r
r
e
e
p
p
r
r
e
e
s
s
e
e
n
n
t
t
a
a
r
r
e
e
c
c
o
o
m
m
p
p
o
o
r
r
o
o
s
s
c
c
r
r
o
o
s
s
s
s
c
c
u
u
t
t
t
t
i
i
n
n
g
g
c
c
o
o
n
n
c
c
e
e
r
r
n
n
s
s
(
(
p
p
r
r
o
o
p
p
r
r
i
i
e
e
d
d
a
a
d
d
e
e
s
s
t
t
r
r
a
a
n
n
s
s
v
v
e
e
r
r
s
s
a
a
i
i
s
s
)
)
c
c
o
o
m
m
o
o
:
:
s
s
e
e
g
g
u
u
r
r
a
a
n
n
ç
ç
a
a
,
,
m
m
o
o
b
b
i
i
l
l
i
i
d
d
a
a
d
d
e
e
e
e
r
r
e
e
g
g
r
r
a
a
s
s
d
d
e
e
t
t
e
e
m
m
p
p
o
o
r
r
e
e
a
a
l
l
(
(
C
C
H
H
I
I
T
T
C
C
H
H
Y
Y
A
A
N
N
e
e
t
t
a
a
l
l
.
.
,
,
2
2
0
0
0
0
5
5
)
)
.
.
2.Desenvolvimento de Software Orientado a Aspectos 13
E
E
m
m
1
1
9
9
9
9
9
9
,
,
e
e
m
m
u
u
m
m
c
c
o
o
n
n
g
g
r
r
e
e
s
s
s
s
o
o
d
d
e
e
E
E
n
n
g
g
e
e
n
n
h
h
a
a
r
r
i
i
a
a
d
d
e
e
R
R
e
e
q
q
u
u
i
i
s
s
i
i
t
t
o
o
s
s
e
e
m
m
L
L
y
y
m
m
e
e
r
r
i
i
c
c
k
k
–
–
I
I
r
r
e
e
l
l
a
a
n
n
d
d
,
,
f
f
o
o
i
i
u
u
t
t
i
i
l
l
i
i
z
z
a
a
d
d
o
o
p
p
e
e
l
l
a
a
p
p
r
r
i
i
m
m
e
e
i
i
r
r
a
a
v
v
e
e
z
z
o
o
t
t
e
e
r
r
m
m
o
o
“
“
A
A
s
s
p
p
e
e
c
c
t
t
-
-
o
o
r
r
i
i
e
e
n
n
t
t
e
e
d
d
R
R
e
e
q
q
u
u
i
i
r
r
e
e
m
m
e
e
n
n
t
t
s
s
E
E
n
n
g
g
i
i
n
n
e
e
e
e
r
r
i
i
n
n
g
g
”
”
o
o
u
u
A
A
O
O
R
R
E
E
(
(
G
G
R
R
U
U
N
N
D
D
Y
Y
,
,
1
1
9
9
9
9
9
9
)
)
,
,
d
d
e
e
m
m
o
o
n
n
s
s
t
t
r
r
a
a
n
n
d
d
o
o
o
o
i
i
n
n
t
t
e
e
r
r
e
e
s
s
s
s
e
e
e
e
a
a
p
p
r
r
e
e
o
o
c
c
u
u
p
p
a
a
ç
ç
ã
ã
o
o
e
e
m
m
t
t
r
r
a
a
t
t
a
a
r
r
e
e
s
s
t
t
e
e
s
s
c
c
r
r
o
o
s
s
s
s
c
c
u
u
t
t
t
t
i
i
n
n
g
g
c
c
o
o
n
n
c
c
e
e
r
r
n
n
s
s
j
j
á
á
n
n
a
a
f
f
a
a
s
s
e
e
d
d
e
e
r
r
e
e
q
q
u
u
i
i
s
s
i
i
t
t
o
o
s
s
.
.
E
E
m
m
2
2
0
0
0
0
2
2
,
,
e
e
m
m
E
E
s
s
s
s
e
e
n
n
-
-
A
A
l
l
e
e
m
m
a
a
n
n
h
h
a
a
,
,
i
i
g
g
u
u
a
a
l
l
m
m
e
e
n
n
t
t
e
e
n
n
o
o
c
c
o
o
n
n
g
g
r
r
e
e
s
s
s
s
o
o
d
d
e
e
E
E
n
n
g
g
e
e
n
n
h
h
a
a
r
r
i
i
a
a
d
d
e
e
R
R
e
e
q
q
u
u
i
i
s
s
i
i
t
t
o
o
s
s
o
o
t
t
e
e
r
r
m
m
o
o
E
E
a
a
r
r
l
l
y
y
A
A
s
s
p
p
e
e
c
c
t
t
s
s
(
(
R
R
A
A
S
S
H
H
I
I
D
D
e
e
t
t
a
a
l
l
,
,
2
2
0
0
0
0
2
2
)
)
f
f
o
o
i
i
u
u
s
s
a
a
d
d
o
o
p
p
e
e
l
l
a
a
p
p
r
r
i
i
m
m
e
e
i
i
r
r
a
a
v
v
e
e
z
z
.
E
E
a
a
r
r
l
l
y
y
A
A
s
s
p
p
e
e
c
c
t
t
s
s
t
t
e
e
m
m
c
c
o
o
m
m
o
o
f
f
o
o
c
c
o
o
p
p
r
r
i
i
n
n
c
c
i
i
p
p
a
a
l
l
a
a
g
g
e
e
r
r
ê
ê
n
n
c
c
i
i
a
a
d
d
a
a
s
s
p
p
r
r
o
o
p
p
r
r
i
i
e
e
d
d
a
a
d
d
e
e
s
s
t
t
r
r
a
a
n
n
s
s
v
v
e
e
r
r
s
s
a
a
i
i
s
s
n
n
o
o
s
s
e
e
s
s
t
t
á
á
g
g
i
i
o
o
s
s
i
i
n
n
i
i
c
c
i
i
a
a
i
i
s
s
d
d
o
o
d
d
e
e
s
s
e
e
n
n
v
v
o
o
l
l
v
v
i
i
m
m
e
e
n
n
t
t
o
o
,
,
e
e
n
n
g
g
l
l
o
o
b
b
a
a
n
n
d
d
o
o
d
d
e
e
s
s
d
d
e
e
a
a
e
e
n
n
g
g
e
e
n
n
h
h
a
a
r
r
i
i
a
a
d
d
e
e
r
r
e
e
q
q
u
u
i
i
s
s
i
i
t
t
o
o
s
s
a
a
t
t
é
é
o
o
d
d
e
e
s
s
i
i
g
g
n
n
d
d
e
e
a
a
r
r
q
q
u
u
i
i
t
t
e
e
t
t
u
u
r
r
a
a
.
.
N
N
e
e
s
s
t
t
e
e
c
c
a
a
p
p
í
í
t
t
u
u
l
l
o
o
é
é
a
a
p
p
r
r
e
e
s
s
e
e
n
n
t
t
a
a
d
d
o
o
u
u
m
m
a
a
v
v
i
i
s
s
ã
ã
o
o
g
g
e
e
r
r
a
a
l
l
d
d
o
o
s
s
p
p
r
r
i
i
n
n
c
c
i
i
p
p
a
a
i
i
s
s
c
c
o
o
n
n
c
c
e
e
i
i
t
t
o
o
s
s
d
d
o
o
d
d
e
e
s
s
e
e
n
n
v
v
o
o
l
l
v
v
i
i
m
m
e
e
n
n
t
t
o
o
d
d
e
e
s
s
o
o
f
f
t
t
w
w
a
a
r
r
e
e
o
o
r
r
i
i
e
e
n
n
t
t
a
a
d
d
o
o
a
a
a
a
s
s
p
p
e
e
c
c
t
t
o
o
s
s
e
e
a
a
l
l
g
g
u
u
m
m
a
a
s
s
a
a
b
b
o
o
r
r
d
d
a
a
g
g
e
e
n
n
s
s
e
e
x
x
i
i
s
s
t
t
e
e
n
n
t
t
e
e
s
s
e
e
m
m
A
A
O
O
S
S
D
D
.
.
I
I
n
n
i
i
c
c
i
i
a
a
l
l
m
m
e
e
n
n
t
t
e
e
,
,
d
d
e
e
s
s
c
c
r
r
e
e
v
v
e
e
-
-
s
s
e
e
o
o
s
s
c
c
o
o
n
n
c
c
e
e
i
i
t
t
o
o
s
s
b
b
á
á
s
s
i
i
c
c
o
o
s
s
d
d
a
a
o
o
r
r
i
i
e
e
n
n
t
t
a
a
ç
ç
ã
ã
o
o
a
a
a
a
s
s
p
p
e
e
c
c
t
t
o
o
s
s
,
,
c
c
o
o
m
m
o
o
a
a
s
s
e
e
p
p
a
a
r
r
a
a
ç
ç
ã
ã
o
o
d
d
e
e
p
p
r
r
o
o
p
p
r
r
i
i
e
e
d
d
a
a
d
d
e
e
s
s
,
,
p
p
o
o
r
r
e
e
x
x
e
e
m
m
p
p
l
l
o
o
.
.
E
E
m
m
s
s
e
e
g
g
u
u
i
i
d
d
a
a
,
,
é
é
d
d
e
e
t
t
a
a
l
l
h
h
a
a
d
d
o
o
a
a
s
s
m
m
o
o
t
t
i
i
v
v
a
a
ç
ç
õ
õ
e
e
s
s
p
p
a
a
r
r
a
a
o
o
s
s
u
u
r
r
g
g
i
i
m
m
e
e
n
n
t
t
o
o
d
d
e
e
s
s
s
s
e
e
p
p
a
a
r
r
a
a
d
d
i
i
g
g
m
m
a
a
d
d
e
e
d
d
e
e
s
s
e
e
n
n
v
v
o
o
l
l
v
v
i
i
m
m
e
e
n
n
t
t
o
o
,
,
d
d
e
e
s
s
c
c
r
r
e
e
v
v
e
e
n
n
d
d
o
o
o
o
s
s
p
p
r
r
o
o
b
b
l
l
e
e
m
m
a
a
s
s
q
q
u
u
e
e
e
e
l
l
e
e
s
s
e
e
p
p
r
r
o
o
p
p
õ
õ
e
e
a
a
s
s
o
o
l
l
u
u
c
c
i
i
o
o
n
n
a
a
r
r
e
e
a
a
l
l
g
g
u
u
m
m
a
a
s
s
a
a
b
b
o
o
r
r
d
d
a
a
g
g
e
e
n
n
s
s
e
e
x
x
i
i
s
s
t
t
e
e
n
n
t
t
e
e
s
s
e
e
m
m
A
A
O
O
R
R
E
E
.
.
P
P
o
o
r
r
f
f
i
i
m
m
,
,
é
é
r
r
e
e
a
a
l
l
i
i
z
z
a
a
d
d
a
a
u
u
m
m
a
a
c
c
o
o
m
m
p
p
a
a
r
r
a
a
ç
ç
ã
ã
o
o
e
e
n
n
t
t
r
r
e
e
a
a
s
s
a
a
b
b
o
o
r
r
d
d
a
a
g
g
e
e
n
n
s
s
a
a
p
p
r
r
e
e
s
s
e
e
n
n
t
t
a
a
d
d
a
a
s
s
,
,
e
e
n
n
f
f
a
a
t
t
i
i
z
z
a
a
n
n
d
d
o
o
s
s
e
e
u
u
s
s
p
p
o
o
n
n
t
t
o
o
s
s
f
f
o
o
r
r
t
t
e
e
s
s
e
e
f
f
r
r
a
a
c
c
o
o
s
s
n
n
a
a
s
s
c
c
o
o
n
n
s
s
i
i
d
d
e
e
r
r
a
a
ç
ç
õ
õ
e
e
s
s
f
f
i
i
n
n
a
a
i
i
s
s
,
,
a
a
q
q
u
u
a
a
l
l
s
s
e
e
r
r
á
á
o
o
p
p
o
o
n
n
t
t
o
o
d
d
e
e
p
p
a
a
r
r
t
t
i
i
d
d
a
a
p
p
a
a
r
r
a
a
o
o
p
p
r
r
ó
ó
x
x
i
i
m
m
o
o
c
c
a
a
p
p
í
í
t
t
u
u
l
l
o
o
.
.
2
2
.
.
1
1
C
C
o
o
n
n
c
c
e
e
i
i
t
t
o
o
s
s
G
G
e
e
r
r
a
a
i
i
s
s
d
d
e
e
D
D
e
e
s
s
e
e
n
n
v
v
o
o
l
l
v
v
i
i
m
m
e
e
n
n
t
t
o
o
O
O
r
r
i
i
e
e
n
n
t
t
a
a
d
d
o
o
a
a
A
A
s
s
p
p
e
e
c
c
t
t
o
o
s
s
(
(
A
A
O
O
S
S
D
D
)
)
Alguns conceitos relacionados
à
AOSD são muito importantes para o perfeito
entendimento deste paradigma, pois são a partir destes que todo o processo é baseado.
Assim, veremos alguns destes conceitos a seguir.
2.Desenvolvimento de Software Orientado a Aspectos 14
2
2
.
.
1
1
.
.
1
1
C
C
o
o
n
n
c
c
e
e
i
i
t
t
o
o
d
d
e
e
a
a
s
s
p
p
e
e
c
c
t
t
o
o
s
s
,
,
c
c
o
o
n
n
c
c
e
e
r
r
n
n
e
e
c
c
r
r
o
o
s
s
s
s
c
c
u
u
t
t
t
t
i
i
n
n
g
g
c
c
o
o
n
n
c
c
e
e
r
r
n
n
Encontramos algumas definições de aspectos na literatura pesquisada, que se
segue:
Segundo Jr (2003) a
spectos são representações de
conce
r
ns
que atravessam as
representações de outros
concerns
.
Para Clarke & Baniassad (2004, 2005) os aspec
tos são comportamentos que
estão misturados e espalhados através do sistema e é um tipo particular de
concern
.
Brito & Moreira (2003)
definem um
concern
como sendo u
ma questão ou
assunto de interesse no sistema de software
,
exemplificando ainda que
concern
pode
ser
um objetivo ou um conjunto de propriedades que o sistema deve satisfazer.
Segundo Tekinerdogan (2004) u
m
concern
é um subproblema.
Para Mili et al. (2004) um
concern
é um conjunto de requisitos relacionados.
Para Silva & Leite (2005) um
concern
é
uma característica do sistema ou do
domínio que seja interessante analisar quer isoladamente quer em conjunto com outras.
Figueiredo et al. (2005) argumenta que um
concern
está
crosscutting
se está
atravessado em outros
concerns
em um módulo ou em múltiplos módulos do sistema.
Para Chitchyan et al. (2005a) o termo crosscutting concerns
se refere a fatores
de qualidade ou funcionalidades do software que não podem ser eficientemente
modularizados usando técnicas existentes de desenvolvimento de software (a
abordagem
orientada a objetos).
Nesse trabalho
será
u
tiliza
do
o
conceito de que
um
concern
é um
a propriedade,
sendo esta
propriedade
um requisito funcional ou não funcional
(
YU et al, 2004
)
e que um
crosscutting
concern
é uma propriedade transversal, ou s
eja
, um requisito (ou
propriedade
)
que
está
tra
nsversal em relação a outros requisitos
é
um forte candidato a ser um aspecto.
Existem vários exemplos de comportamentos que podem ser citados
como
aspectos
e que possuem
este comportamento ou
funcionalidade d
e precisar ser carregada
em diferentes módulos de um código orientado a objeto
, como segurança, persistência e
sincronização, entre outros.
Atualmente há uma preocupação crescente em conseguir identificar aspectos
nas fases iniciais do processo de desenvo
lvimento,
sendo alvo de
estudos comparativos de
2.Desenvolvimento de Software Orientado a Aspectos 15
abordagens que tratam da fase de requisitos
(
CHITCHYAN et al, 2005a
)
(
BAKKER et al,
2005
)
.
Assim, temos o termo
early aspects
que define os
crosscutting concerns
ou as
propriedades transversais
identificad
a
s
nas fases iniciais do ciclo de desenvolvimento de
software
(
RASHID et al, 2002
)
(
A
RAUJO
et al
, 2005
)
. Estas fases incluem a análise de
requisitos,
análise de
domínio e a fase de projeto da arquitetura.
As técnicas de AOSD provêm uma maneira sistemática de
identificar,
modularizar, representar e
compor os
crosscutting concerns
, ou seja, separação e
composição de propriedades
(
CHITCHYAN et al, 2005
a
)
.
A seguir
é descrito
estes dois conceitos, que são os pilares da orientação a
aspectos.
2
2
.
.
1
1
.
.
2
2
S
S
e
e
p
p
a
a
r
r
a
a
ç
ç
ã
ã
o
o
d
d
e
e
P
P
r
r
o
o
p
p
r
r
i
i
e
e
d
d
a
a
d
d
e
e
s
s
Produzir software com qualidade sempre foi um dos objetivos
de todo o
desenvolvedor de software
. P
ressman (
2005
)
alega que além de produzir software de
qualidade deve
-
se tentar faz
ê
-
lo em um menor espaço de tempo possível, sendo esse um
dos principais objetivos da Engenharia de Software.
Para alcançar tal objetivo, diversas abordagens foram propostas ao longo dos
anos
:
A
nálise
E
struturada de
S
istemas
(
GANE
& SARSON
, 1977
)
,
A
nálise
E
ssencial de
S
istemas
(
MCMENAMIN
& PALMER
, 1984
)
,
A
nálise
O
rienta
da a
O
bjetos
(
SHLAER
&
MELLOR
, 1990
)
, Processo
Catalysis
(
SOUZA
& WILLS
, 1995
)
, Processo
Unificado/UML
(
BOOCH et al, 1999
)
(
JACOBSON
et al.
, 1999
)
(
SCOTT, 2003
)
e o
D
esenvolvimento
O
rientado a
A
spectos
(
JACOBSON
& NG
, 2005
)
(
CLARKE &
BANIASSAD, 2005
)
.
G
uez
zi
apud
S
ouza
(
2004
)
estabeleceu alguns princípios que devem ser
aplicados ao longo do processo de desenvolvimento e nos artefatos de software: separação
de
propriedades
, modularidade, rigor e formalidade, incrementalidade, abstração,
generalidade e antecipação de mudanças.
O objetivo
d
a separação de
propriedades
é identificar e modularizar as partes
do software que são relevantes para um conceito em particular, meta ou propósito
(
BRITO
& MOREIRA, 2003
)
.
2.Desenvolvimento de Software Orientado a Aspectos 16
Com isso, este princ
í
pio permite que se reduza o rac
iocínio a uma quantidade
factível
(
DIJKSTRA, 1976
)
. Esse princípio estabelece que um problema
possa
ser
decomposto em unidades menores, claramente separadas, de maneira que cada uma delas
represente uma única preocupação
(
AKSIT et al
. apud SOUZA
, 200
4
)
. A
idéia básica é
manipular com uma preocupação do sistema de cada vez, ou seja, o velho e bom “dividir
para conquistar”. Como conseqüência, a aplicação desse princípio possibilita:
·
Diminuir
a complexidade do desenvolvimento de software, concentrando
-
se em diferentes preocupações separadamente;
·
Raciocinar
sobre diferentes preocupações de maneira relativamente
independente;
·
Facilitar
a inserção/remoção de preocupações na aplicação;
·
Dividir
esforços e separar responsabilidades entre membros da equipe de
desenvol
vimento; e
·
Melhorar
a modularidade de artefatos de software.
S
ouza (
2004
)
aponta ainda que
quando os artefatos de software possuem a
capacidade
de
separação de
propriedades,
elas
tendem a ser similares
(forte coesão) e a
dependência entre os artefatos é minimizada (fraco acoplamento).
Conseqüentemente, mudanças em artefatos relacionadas a um
a propriedade
,
tendem a ter um efeito limitado ou até mesmo nenhum efeito em artefatos relacionados a
outr
a
s
propriedades
. Isso facilita a compreensão,
evolução, adaptaç
ão, customização e
reuso dos artefatos de software.
Para implementar este princípio o engenheiro de software deverá se basear no
paradigma de programação adotado (objetos, estruturado ou aspectos).
De maneira geral, os métodos para separação de
propriedad
es
envolvem as
seguintes atividades
(
AKSIT et al. 2001
)
:
·
Identificação
de
propriedades
: seleção de
propriedades
que o sistema vai
incluir;
·
Representação
de
propriedades separadamente: especificação de
propriedades
em unidades ou num conjunto de unidades qu
e concretizam a
realização de
cada uma
d
a
s
propriedades
; e
2.Desenvolvimento de Software Orientado a Aspectos 17
·
Composição
de
propriedades
: integração de unidades separadas a fim de dar
a elas alguma coerência para formar o conjunto do sistema.
As abordagens tradicionais de desenvolvimento de software
(
orien
tação a objetos e
métodos estruturados
)
foram
criada
s
com este princípio
geral
em mente
. Entretanto
,
elas
possuem limitações no tratamento dos requisitos não
-
funcionais. Assim
,
não consideram a
natureza de
transversal
dest
a
s
propriedades
.
Para tentar solu
cionar essas limitações, foram
propostas
algumas abordagens na literatura,
tais como:
Programação Adaptativa
(
LIEBERHERR, 1996
)
, Filtros de Composição
(
BERGMANS & AKSIT, 2001; BERGMANS
et al., 2001
)
, Separação Multidimensional de Preocupações
(
TARR et al.,
1999; OSSHER &
TARR, 2000
)
e Programação Orientada
a Aspectos
(
KICZALES et al., 1997
)
. Essas propostas
pertencem a uma área de pesquisa denominada de Separação Avançada de
Preocupações
(
Advanced Separation of Concerns
).
Um modelo genérico para tratar a se
paração avançada de
propriedades
1
foi
proposto por B
rito
& Moreira
(
2003
)
e é baseado nas atividades citadas anteriormente
propostas por
A
ksit
(
2001
)
, conforme pode ser observado na figura 3.1.
1
o termo preocupações é utilizada na tradu
ção em alguns artigos, porém iremos utilizar
propriedades.
2.Desenvolvimento de Software Orientado a Aspectos 18
F
IGURA
2
.1
–
M
ODELO DE
S
EPARAÇÃO
A
VANÇADA DE
PROPRI
EDADES
.
A
DAPTADO DE
(
BRITO
&
MOREIRA,
2003
).
A seguir segue
-
se uma breve descrição das tarefas a serem realizadas na Figura
2
.1
:
·
Tarefa 1
–
Identificar
Concern
s
2
–
a identificação de
propriedades
é uma tarefa
extremamente importante, pois
é acompanhada por
um entendimento completo e
exaustivo do sistema
por meio
da análise da documentação e qualquer outra
informação fornecida pelos
stakeholders
3
do sistema.
Segundo
Brito &Moreira
(
2003
)
ainda é uma atividade dependente principalmente da experiência do
engenheiro de software.
·
Tarefa 2
–
Especificar
Concerns
–
esta tarefa é subdividida em três sub
-
tarefas:
aplicar a abordagem que melhor especifica cada
propriedade
; identificar
2
O term
o
concern
é utilizado por Brito & Moreira (2003)
.
Assim, será utilizado apenas nos títulos das
tarefas explicitadas por eles.
3
Stakeholder
pode ser qualquer pessoa que tem uma influência d
ireta ou indireta no
projeto
(
BRITO &
MOREIRA, 2003
)
.
2.Desenvolvimento de Software Orientado a Aspectos 19
contribuições entre
propriedades
de tal forma que os
conflitos possam ser
detectados
e
identificar prioridades e inter
-
relacionamentos.
·
Tarefa 2.1 –
Especificar
concerns
usando a melhor abordagem
– podemos
utilizar qualquer técnica para a especificação de requisitos. Em certos casos, a
escolha deve ser feita durante a Tarefa 1, especialme
nte se uma técnica particular
foi usada para auxiliar o processo de elicitação.
Se for
assim, podemos construir
qualquer modelo ou outra documentação proposta por estas técnicas.
·
Ta
ref
a 2.2
–
Identificar contribuições entre
concerns
–
o r
elacionamento de
c
ontribuição entre d
ua
s
propriedades
define a maneira pela qual um
a propriedade
afeta o outro. Esta contribuição pode ser colaborativa (ou positiva, quando auxilia
o
propriedade
afetad
a
)
e
sua representação é feita por um “+”, ou perigosa (ou
negativa, obst
ruindo
a propriedade afetad
a
) e sua representação é feita por um “
-
“.
·
Tarefa 2.3
–
Identificar prioridades e inter
-
relacionamentos –
uma prioridade
proporciona um grau de importância a um
a propriedade
no sistema. A prioridade
d
a propriedade
é um contexto d
e dependência, por exemplo, um
a
mesm
a
propriedade
pode ser classificad
a
com diferentes prioridades pelo
stakeholder
dependendo do domínio de neg
ó
cio.
Os inter
-
relacionamentos fornecem uma lista
de
propriedades e suas necessidades.
·
Tarefa 3
– Identificar
C
rosscutting
Concerns –
um
a propriedade
está
transversal
se precisa de mais de um
a
outr
a propriedade, identificado na Tarefa 2.3.
·
Tarefa 4
–
Compor
Concerns –
o objetivo desta tarefa é compor tod
a
s
a
s
propriedades
para formar todo o sistema. Esta tarefa é c
omposta de quatro sub
-
tarefas.
·
Tarefa 4.1
–
Identificar
match points
–
Identificar os pontos onde a composição
será realizada. Um
match point
indica qual
propriedade transversal
deve ser
compost
a
com um
a
dad
a propriedade.
·
Tarefa 4.2
–
Identificar conflito
s
–
identificar as situações de conflito entre
propriedades
. Para um dado
match point
precisamos analisar se
as propriedades
transversais
envolvid
a
s contribuem negativamente para outr
a
s quaisquer.
Se
contribuírem positivamente não há problema.
2.Desenvolvimento de Software Orientado a Aspectos 20
·
Tarefa 4.3
–
Identificar
concerns
dominantes
–
Esta sub
-
tarefa ajuda a resolver
os conflitos identificados na tarefa anterior
e é baseado nas prioridades
atribuídas.
Se a prioridade atribuída a cada
propriedade
é diferente, o problema não é tão
difícil de resolver, e
a propriedade
dominante é aquele com
a maior prioridade
.
Entretanto, se no mínimo d
uas propriedades transversais
possuem a mesma
prioridade, um
trade
-
off
4
devem ser negociado entre os usuários.
A identificação
d
a
propriedade dominante é importante para guiar a regra de composição.
·
Tarefa 4.4
–
Definindo regras de composição
–
a regra de composição define a
ordem na qual
a
s
propriedades
devem ser aplicad
a
s em um particular
match point
.
(
BRITO & MOREIRA, 2003
)
indica o seguinte formato: <
concern
> <operador>
<
concern
>. Os operadores irão depender da linguagem a ser utilizada.
E
sta regra
expressa a ordem seqüencial na qual o aspecto deve ser combinado com a(s)
unidade(s) que ele afeta, ou seja, especifica como o comportamento do asp
e
cto
deve ser aplicado no(s)
m
atch point
ou ponto(s) de junção.
2
2
.
.
1
1
.
.
3
3
C
C
o
o
m
m
p
p
o
o
s
s
i
i
ç
ç
ã
ã
o
o
d
d
e
e
P
P
r
r
o
o
p
p
r
r
i
i
e
e
d
d
a
a
d
d
e
e
s
s
Na Figura 2
.1 a composição de
propriedades
é realizada através da Tarefa 4 ( e
suas sub
-
tarefas)
, como explicado anteriormente.
J
acobson (
2005
)
argumenta que a composição de aspectos, p
rincipalmente se
for feita em um nível mais alto de modelos de pontos de junção não é uma tarefa trivial.
Realizar a composição de aspectos dinamicamente tem seus próprios desafios, tornando
esta tarefa complicada na fase de programação. Porém, isto não im
plica que a composição
em nível de requisitos seja trivial.
Sem dúvida, são problemas diferentes
, mas
possuem desafios em ambas as
situações. Na programação pelo menos um modelo estruturado do sistema já está definido
(
JACOBSON, 2005
)
. Já na fase de requis
itos, a situação é diferente, pois requisitos
tendem a estar em pedaços de textos os quais, geralmente, são difíceis de serem
interpretados
e
possuem informações ambíguas e incompletas (muitas das vezes).
4
Trade
-
off não pode ser traduzido literalmente pois perderá o sentido, porém neste contexto se refere a um
ponto de equilíbrio ou uma troca, a fim de achar um ponto neutro.
2.Desenvolvimento de Software Orientado a Aspectos 21
Assim o trabalho de especificação de regras de com
posição (pointcuts
) é muito
mais complicado do que aparenta.
De maneira geral, o paradigma orientado a aspectos
complementa
paradigmas
anteriores (estruturado e orientado a objetos) em dois sentidos
(
ELRAD
, 2001
)
:
(i)
Localizando propriedades transversais
em
unidades separadas, denominadas de
aspectos; e
(ii)
Provendo
mecanismos para fazer a composição de
propriedades transversais
com as unidades de decomposição do sistema que elas afetam (também
denominadas de unidades base). Para que um aspecto seja combinado co
m a(s)
unidade(s) que ele afeta, são necessárias algumas informações:
(a)
Ponto
(s) de junção: indica em que ponto(s) na especificação da(s)
unidade(s) base o comportamento do aspecto deve ser incluído
(
BRITO
& MOREIRA,
2003
)
;
(b)
Regra
de composição: expressa a o
rdem seqüencial na qual o aspecto
deve ser
combinado com a(s) unidade(s) que ele afeta
(
MOREIRA et
al., 2002
)
, ou
seja, especifica como o comportamento do aspecto deve
ser aplicado no(s)
ponto(s) de junção. As regras de composição mais
comuns são: “antes”,
“depois”, e “ao invés de”;
Exemplificando:
quando dito que o aspecto de autenticação de senha deve ser
aplicado
antes da execução de transações bancárias, o termo antes corresponde a
uma
regra de composição e a sentença execução de transações
bancárias corresponde ao ponto de junção
(
SOUZA, 2004
)
Existem quatro possibilidades de especificar a composição entre um aspecto e
unidades base
(
KERSTEN & MURPHY, 1999
)
:
·
Fechada
: o aspecto e a unidade base não “
têm
conhecimento” sobre a
existência um do outro, ou seja, eles não se referenciam diretamente;
·
Aberta: aspecto e a unidade base “têm conhecimento” sobre a existência
um
do outro, ou seja, eles se referenciam mutuamente;
·
Dirigida
ao componente
: somente o aspecto referencia a unidade base; e
·
Dirigida
ao aspec
to
: somente a unidade base referencia o aspecto.
2.Desenvolvimento de Software Orientado a Aspectos 22
Segundo
(
SOUZA, 2004
)
a
associação do tipo fechada é a preferencial, visto
que permite a
independência tanto das unidades base quanto do aspecto, promovendo,
então, melhor
potencial para que os artefatos en
volvidos possuam qualidades como
reusabilidade,
compreensibilidade e manutenibilidade. A associação do tipo aberta deve
ser evitada,
pois resulta em acoplamento entre os dois tipos de artefatos e,
conseqüentemente, compromete o alcance da separação de
prop
riedades
e seus benefícios.
Por sua vez, as
associações do tipo dirigida ao componente e dirigida ao aspecto,
promovem as
qualidades já citadas apenas com relação
à
unidade base e ao aspecto,
respectivamente.
Ainda segundo (SOUZA, 2004) o
s tipos de associa
ções mais comuns nas
abordagens orientadas a aspectos são
as
fechada
s
e dirigida
s
ao componente
.
2
2
.
.
1
1
.
.
4
4
A
A
P
P
r
r
o
o
g
g
r
r
a
a
m
m
a
a
ç
ç
ã
ã
o
o
O
O
r
r
i
i
e
e
n
n
t
t
a
a
d
d
a
a
a
a
A
A
s
s
p
p
e
e
c
c
t
t
o
o
s
s
e
e
a
a
L
L
i
i
n
n
g
g
u
u
a
a
g
g
e
e
m
m
A
A
s
s
p
p
e
e
c
c
t
t
J
J
O termo “programação orientada a aspectos” é atribuído ao grupo de pesquisa
da Xerox PARC lid
erado por Gregor Kiczales e corresponde a uma técnica de
programação que possibilita a separação de preocupações transversais na implementação
de sistemas
(
KICZALES et al., 1997
)
.
Essa abordagem denomina de maneira distinta dois tipos de preocupações: as
q
ue conseguem ser adequadamente modularizadas pelos paradigmas estruturado ou
orientado a objetos são chamadas de componentes; e aquelas que não conseguem, ou seja,
as preocupações transversais, são denominadas de aspectos
(
KICZALES et al., 1997
)
.
Na Progra
mação Orientada a Aspectos, assume
-
se que existe uma
decomposição dominante do sistema (ex: em classes ou módulos) para os componentes, e
que os aspectos representam outra unidade de decomposição do sistema. Dessa maneira,
componentes são implementados num
a linguagem procedural ou orientada a objetos,
enquanto aspectos são codificados em uma linguagem especialmente designada para esse
propósito
(
SOUZA, 2004
)
. Linguagens orientadas a aspectos utilizam cinco elementos
para permitir a modularização de preocupa
ções transversais
(
ELRAD et al., 2001
)
:
2.Desenvolvimento de Software Orientado a Aspectos 23
(i) um modelo de pontos de junção descrevendo os possíveis pontos onde o
comportamento do aspecto pode ser adicionado;
(ii) um meio de identificar esses pontos de junção;
(iii) um meio de especificar o comportamento adicional nesses pontos;
(iv) unidades que encapsulam a especificação dos pontos de junção e as
melhorias comportamentais providas pelo aspecto; e
(v) um mecanismo para combinar o comportamento transversal do aspecto
com
o comportamento do(s) componente(s) que ele afeta.
Em resumo, na Programação Orientada a Aspectos,
propriedades
transversais
são encapsuladas em unidades denominadas aspectos, nas quais são especificados os
pontos de execução nos componentes que a
propriedade
transversal afetará e o
com
portamento/propriedade que devem ser adicionados nesses pontos. Como ilustrado
pela Figura
2
.2, o sistema final é formado a partir da combinação de aspectos e
componentes, num processo denominado de
weaving
.
F
I
GURA
2
.2
-
P
ROCESSO DE COMBINAÇÃ
O
DE ASPECTOS E CLASS
ES PARA GERAR O SIST
EMA
.
F
ONTE
:
(
SOUZA,
2004
)
A linguagem AspectJ
(
KICZALES et al., 2001
)
é um superconjunto
ou uma
extensão
da linguagem Java
5
(
GOSLING et al., 2000
)
para ser usado na Programação
Orientada a Aspectos. Em uma aplicação
orientada a aspectos em AspectJ, os
5
Neste trabalho trataremos
exclusivamente da linguagem Java e AspectJ, por ser Java a linguagem de
utilizada no desenvolvimento do projeto DiSEN e da ferramenta REQUISITE.
Aspecto
Aspectos
Combinador de
aspectos
(
weaver
)
Sistema
Classe
Componentes
2.Desenvolvimento de Software Orientado a Aspectos 24
componentes são implementados usando a sintaxe padrão de Java, e os aspectos são
implementados usando uma sintaxe específica de AspectJ. Essa linguagem utiliza um
processador de aspectos —
denominado de
weaver
— para com
binar o código do aspecto
com o código
dos componentes e conseqüentemente produzir o sistema executável. Após a
compilação e o processo de
weaving
, o código objeto gerado pode ser executado em
qualquer máquina virtual Java.
Em AspectJ, o código referente
a
uma
propriedade
transversal é especificado
numa unidade de codificação denominada aspect
(veja Figura 3.3). Dentro da unidade
do
tipo
aspect
, o código relacionado à
propriedade
transversal utiliza construtores lingüísticos
especiais:
·
o construtor
pointcut
é utilizado para capturar ou identificar pontos de
junção
no fluxo do programa sobre os quais o aspecto atua. Exemplos de
possíveis
pontos de junção incluem inicialização de objetos, chamadas de
métodos e
acesso a campos;
·
advices
são blocos de código no
quais devem ser definidos as regras de
composição e o comportamento a ser executado pelo aspecto. Para
determinar as regras de composição nos pontos de junção identificados,
utilizam
-
se as regras de composição
before, after e around
. Essas regras
indicam q
ue o comportamento do aspecto deve ser executado,
respectivamente, antes, após, ou ao invés de cada ponto de junção definido
pelo
pointcut
associado.
·
inter
-
type declarations
possibilita que classes presentes no sistema sejam
modificadas estruturalmente: (i
) acrescentando métodos, atributos e classes
internas; e (ii) alterando a hierarquia de herança de classes e interfaces.
2.Desenvolvimento de Software Orientado a Aspectos 25
F
IGURA
2
.3
–
E
STRUTURA DE UMA ENTI
DADE
A
SPECT
EM
A
SPECT
J
.
A
DAPTADO DE
(
SOUZA,
2004
).
Conforme ilustra a Figu
ra
2.3, além dos construtores próprios de AspectJ, uma
unidade do tipo aspect pode conter membros de dados e métodos, assim como uma classe.
A Figura 2.4 apresenta um exemplo de código em AspectJ que implementa um
aspecto de
logging
para rastrear a execuçã
o de métodos. A princípio, é definido um
ponto
de junção
loggedMethod (linha 3), incluindo todas as chamadas de métodos.
Entre a linha 5 e a 11 são definidos dois
advices
para que sejam exibidas
mensagens
imediatamente antes da execução e imediatamente apó
s o retorno do ponto de
junção.
F
IGURA
2
.4
-
E
XEMPLO DE CÓDIGO EM
A
SPECT
J
.
A
DAPTADO DE
(
SOUZA,
2004
).
Para
que se
compreend
a
o
processo de desenvolvimento de sistemas utilizando
a orientação a aspectos
é preciso conhecer os conceitos de algumas das abor
dagens de
desenvolvimento utilizadas na Fase de Requis
i
tos.
Atributos
Métodos
Pointcuts ou pontos
de corte
Advices ou
informações
Declarações inter
-
type
Parte comum a
classes
Construtores
específicos de
AspectJ
1
public aspect Logging {
2
3
Pointcut LoggedMethod(): call (* *(..));
4
5
Before(): loggedMethod() {
6
System.out.println
(“--
ANTES DA EXECUÇÃO DA CHAMADA DE UM MÉTODO
--
“);
7
}
8
9
after(): loggedMethod() {
10
System.ou
t.println
(“--
DEPOIS DO RETORNO DA CHAMADA DE UM MÉTODO
--
“)
;
11
}
12
}
2.Desenvolvimento de Software Orientado a Aspectos 26
3
3
.
.
2
2
F
F
a
a
s
s
e
e
d
d
e
e
R
R
e
e
q
q
u
u
i
i
s
s
i
i
t
t
o
o
s
s
A abordagem da Engenharia de Requisitos Orientada a Aspectos (AORE), tem
como objetivo o tratamento sistemático e modular, na argumentação, composição e
subseqüente rast
reamento d
a
s
propriedades transversais
funcionais e não funcionais
através de uma adequada abstração, representação e mecanismos de composição próprios
para o domínio da engenharia de requisitos
(
CHITCHYAN et al, 2005
a
)
.
A seguir
serão
apresentadas as prin
cipais abordagens existentes para esta fase,
que servirão de ponto de partida para a definição da
nova
abordagem
, a ser apresentada no
presente trabalho.
2
2
.
.
2
2
.
.
1
1
A
A
b
b
o
o
r
r
d
d
a
a
g
g
e
e
m
m
V
V
i
i
e
e
w
w
p
p
o
o
i
i
n
n
t
t
A abordagem da Engenharia de Requisitos Orientada a
Viewpoint
consider
a
a
informação do problema relacionado a partir de vários agentes ao ser estabelecido o que é
requerido para a resolução de determinado problema, os quais podem ter perspectivas
incompletas e igualmente válidas
(
CHITCHYAN et al, 2005
a
)
.
A combinação entre age
ntes e as visões dos agentes é chamado de
viewpoint
.
(
CHITCHYAN et al, 2005b
)
. Em
(
SOMMERVILLE & SAWYER
, 1998
)
é apresentado o
PRE
V
iew
, sendo uma abordagem não orientada a aspectos, onde é uma generalização da
noção de metas, que inclui
tanto
as metas orga
nizacionais que restringem o sistema
como
o processo a ser analisado. Esta abordagem não identifica qualquer propriedade transversal
separadamente: tod
a
s el
a
s são tratad
a
s como parte de um ponto de vista
. Embora
os pontos
de vista ou
viewpoints
possam sobr
epor e transpor as outras, esta é
tratado
como questão
de resolução de inconsistência, mais do que um problema de separação de propriedades.
Em
(
RASHID et al 2002
)
e
sta abordagem recebeu o nome de AORE, porém
como este conceito é geral
,
está sendo utilizad
o o nome da ferramenta
(
ARCADE
)
que
utiliza esta abordagem
, assim como no trabalho apresentado em
(
CHITCHYAN et al,
2005
a
)
.
Em
(
RASHID et al, 2003
)
é
apresentada
uma instanciaç
ão do modelo geral do
processo de requisitos
,
conforme pode ser observado na
Fig
ura
3.5
. Esta instanciação é
similar ao utilizado no PREview. Entretanto, no Arcade, seu objetivo está em modularizar
e compor
propriedades
no nível de
requisitos
e
não apenas na produção de um documento
de especificação de requisitos.
2.Desenvolvimento de Software Orientado a Aspectos 27
Podemos observar que
a Figura
2
.5 é muito similar a
F
igura
2
.1. Na verdade, a
Figura
2.5
foi uma adaptação e refina
mento
desta última. Suas fases e descrições são
similares à
apresentada na
Figura
2.1.
F
IGURA
2
.5
–
M
ODELO DE PROCESSO
AORE.
A
DAPTADO DO
(
RASHID ET AL
,
2003
)
(
RASHID et al, 2002
)
define
m
que
,
inicialmente
,
é necessário identificar
requisitos funcionais e
propriedades
, porém a ordem não é definida pelo modelo: ela
Identificar
concerns
Identificar
requisitos
Especificar
concerns
Especificar
requisitos
Relacionar concerns e
requisitos
Identificar aspectos
candidatos
Definir regras
de composição
compor aspectos
candidatos e requisitos
elaborar tabelas de
contribuição
atribuir medidas para
aspectos conflitantes
Resolver
conflitos
composição
Gerenciar
conflitos
especificar dimensões
do aspecto
Revisar
especificações
de requisitos
2.Desenvolvimento de Software Orientado a Aspectos 28
dependerá da interação entre os engenheiros e os usuários do sistema
, mesmo porque esta
atividade ainda é uma atividade que depende da experiência do engenheiro de requisitos.
Após esta fase,
na qual
foram
identificado
s
os requisitos e
propriedades
pertinentes ao domínio do sistema a ser desenvolvido, deve
-
se
relacionar
as
propriedades
a
requisitos funcionais em uma matriz, de acordo com a
t
abela
2.1.
TABELA
2
.1
–
R
ELACIONANDO
PROPRIEDADES
COM REQUISITOS DOS
STAKEHOLDERS
.
A
DAPTADO DO
(
RASHID
ET AL
,
2003
).
Requisitos dos Stakeholders
Propriedades
R1
R2
....
Rn
propriedades 1
X
X
propriedades 2
X
...
propriedades
n
X
X
Observando a matriz formada pela Tabela
2
.1 podemos constatar quais
propriedades
cruzam com os módulos encapsulados pelos requisitos dos
stakeholders.
E
st
a
s
propriedades
são
qualificadas como aspectos candidatos.
Segundo
(
S
OUZA, 2004
)
, um aspecto candidato é quando um
a
propriedade
pode influenciar ou restringir mais de um requisito funcional.
Rashid et al (2003) argumenta que a
pós serem identificados os aspectos
candidatos
são necessários
detalhar as regras de composição. Es
tas regras operam na
granularidade
dos requisitos individualmente e, não apenas nos módulos que as
encapsulam. Assim é possível especificar como um requisito aspectual
influencia ou
restringe o comportamento de um conjunto de requisitos não aspectuais nos
vários
módulos. Ao mesmo tempo, aspectos
trade
-
offs
podem ser observados em uma
granularidade menor. Isto exclui a necessidade de negociações entre stakeholders
para os
casos onde podem existir um aparente
trade
-
off
entre dois ou mais aspectos mas de fato
requisitos diferentes e isolados podem ser influenciados por eles. Também facilita a
identificação de conflitos individuais dos requisitos aspectuais com respeito a qual
negociação deve ser cumprida e o equilíbrio estabelecido.
2.Desenvolvimento de Software Orientado a Aspectos 29
A próxima atividade é resp
onsável por analisar aspectos candidatos em mais
detalhes, identificando conflitos entre eles e estabelecendo prioridades.
Para esta atividade
deve ser feita uma tabela de acordo com o exemplo fornecido pela
t
abela
2.2.
TABELA
2
.2
–
M
APEAMENTO ENTRE ASPECT
OS CANDIDATOS
.
A
DAPTADO DO
(
RASHID ET AL
,
2003
).
Aspecto 1
Aspecto 2
...
Aspecto n
Aspecto 1
+
Aspecto 2
_
...
Aspecto n
Na
t
abela
2
.2 podemos observar que o Aspecto 1 contribui positivamente (
+
)
com o Aspecto 2 e o Aspecto 2 contribu
i negativamente (
-
) com o Aspecto n.
As células
em branco significam que não tem contribuição
Após preencher esta tabela devemos atribuir pesos para os aspectos que
contribuem negativamente com outro em relação ao conjunto de requisitos do usuário.
Cada p
eso é um número real em um intervalo de 0
a
1 e representa a prioridade de um
aspecto em relação ao conjunto de requisitos dos stakeholders.
Após atribuir os pesos aos aspectos
devem
-
se
resolver os conflitos com os
stakeholders, usando a priorização acima descrita para auxiliar a comunicação.
Por fim, deve
-
se especificar o impacto de aspectos candidatos em termos de
duas dimensões: mapeamento e influência. A dimensão de mapeamento especifica como
cada aspecto candidato será manipulado nos estágios seguintes do desenvolvimento. Nesta
dimensão o aspecto candidato pode ser mapeado em uma função, decisão arquitetural ou
num aspecto.
Por outro lado, a dimensão de influência estabelece quais os pontos do ciclo de
desenvolvimento que o aspecto candidato afetará. A
t
abela
2.3
m
ostra um exemplo de
saída dessa atividade.
2.Desenvolvimento de Software Orientado a Aspectos 30
TABELA
2
.3
–
E
XEMPLO DE UMA
E
SPECIFICAÇÃO DA
D
IMENSÃO DO
A
SPECTO
.
F
ONTE
:
(
RASHID
ET AL
,
2002
).
Aspecto Candidato
Influência
Mapeamento
Compatibilidade
Especificação, arquitetura, design, evolução
F
unção
Tempo de Resposta
Arquitetura, design
Aspecto
Restrições Legais
Especificação
Função
Corretude
Especificação, design
Função
Segurança
Arquitetura, design
Aspecto
Disponibilidade
Arquitetura
Decisão
Sistema Multi
-
usuário
Arquitetura, design
Asp
ecto
Por sua vez, M
oreira
et al. (2002), A
raujo
et al. (2002) e B
rito
& M
oreira
(2003) usam uma instância simplificada do modelo AORE baseada em UML
(
BOOCH et
al., 1999
)
.
S
ouza
(
2004
)
detalha este trabalho como sendo uma extensão do processo
anterior e
C
hitchyan
et al
(
2005b
)
apresenta
m
como sendo uma extensão da abordagem
viewpoint
e apenas cita os trabalhos. Porém, vamos tratar este trabalho em separado, pois
apesar de se utilizar do modelo AORE detalhado anteriormente possui
algumas
características diferentes.
2
2
.
.
2
2
.
.
2
2
A
A
b
b
o
o
r
r
d
d
a
a
g
g
e
e
m
m
A
A
O
O
R
R
E
E
u
u
t
t
i
i
l
l
i
i
z
z
a
a
n
n
d
d
o
o
U
U
M
M
L
L
Esta abordagem teve início em
M
oreira
et al. (2002),
Araújo
et al. (2002) e
B
rito
& M
oreira (200
2
)
e é
composta de três atividades principais, descritas a seguir:
a)
Identificar
concern
s
6
-
em
(
BRITO &
MOREIRA
,
2002
)
esta atividade é limitada
a identificar os requisitos do sistema e selecionar os requisitos de qualidade que
são relevantes para o domínio da aplicação. Não especifica como identificar os
requisitos, especifica
m
ainda
que esta atividade deve identif
icar tod
a
s
a
s
propriedades
do sistema, ou seja, os requisitos funcionais e não
-
funcionais.
Os
autores d
iz
em
ainda que diferentes técnicas podem ser utilizadas para identificar os
requisitos e particularmente escolheu a técnica de casos de uso. Porém
,
salie
nta
m
que a identificação de
propriedades
funcionais e não funcionais irá depender da
6
O termo
concern
foi utilizado apenas no título da atividade, porém será utilizado propriedade em outras
oport
unidades.
2.Desenvolvimento de Software Orientado a Aspectos 31
visão dos
stakeholders
em relação ao sistema e
à
dinâmica de comunicação entre
os desenvolvedores e clientes.
b)
Especificar
concerns
e
identificar
qua
is
deles
são
transversa
is
(
aspectos
candidatos
)
– esta atividade pode ser dividida em duas partes principais:
b.1) especificar requisitos funcionais usando a abordagem de casos de uso
; e
b.2) descrever atributos de qualidade usando
templates
especiais (Tabela
2
.4) e
identificar
aqueles que atravessam os requisitos funcionais (atributos de qualidade).
T
ABELA
2
.4
–
T
EMPLATE PARA ATRIBUTOS DE QUALIDADE
.
F
ONTE
:
(
BRITO
&
MOREIRA,
200
2
)
Nome
Nome do atributo de qualidade
Descrição
Descrição sucinta
Focus
O atributo de qualidade pode
afetar o sistema (produto final) ou
o desenvolvimento do processo
Fonte
Fonte da informação (documentos, stakeholders
)
Decomposição
Os atributos de qualidade podem ser decompostos em outros
mais simples
. Quando todos (sub) atributos de qualidade são
nec
essários para
obter o atributo de qualidade, temos um
relacionamento
AND
,
c
aso contrário
, temos
um relacionamento
OR.
Prioridade
Expressa a importância do atributo de qualidade para os
stakeholders.
A prioridade pode ser
MAX,
HIGH
,
LOW
e
MIN
.
Obrigação
P
ode ser opcional ou obrigatória.
Influencia
Atividades do processo afetadas pelos atributos de qualidade
Onde
Lista dos atores influenciados pelos atributos de qualidade e
uma lista de modelos (casos de uso, diagramas de seqüência)
que necessitam do atributo de qualidade.
Requisitos
Requisitos descrevendo o atributo de qualidade.
Contribuição
Representa como o atributo de qualidade afeta outros atributos.
A contribuição pode ser positiva (+) ou negativa (
-
).
2.Desenvolvimento de Software Orientado a Aspectos 32
b.3) propor um conjunto de modelos para re
presentar a integração de atributos de
qualidade transversais e requisitos funcionais.
Para
B
rito
& M
oreira
(
200
3
)
esta atividade deve especificar
propriedades
e
finalizar pela identificação dos aspectos candidatos.
A
s
propriedades
funcionais são
especificada
s através de um conjunto de cenários e diagramas de seqüência.
A
s
propriedades
não funcionais através de um
template
especial
, conforme verificado na
Tabela
2.5.
(muito parecido com o trabalho anterior em
(
BRITO & MOREIRA,
2002
)
).
T
ABELA
2
.5
–
T
EMPLATE
PARA REQUISITOS NÃO FUNCIONAIS
.
F
ONTE
:
(
BRITO
&
MOREIRA,
2003
)
Nome
Nome d
a propriedade não funcional
Descrição
Descrição sucinta
Prioridade
Expressa a importância d
a propriedade
. A prioridade pode ser
Muito Importante, importante, médio, baixo e muito
baixo.
Decomposição
A
s
propriedades
podem ser decompostos em outros mais
simples.
Onde
Lista de modelos e seus elementos (casos de uso, classes,
diagramas de seqüência) que necessitam da propriedade
Requisitos
Requisitos descrevendo a propriedade
Co
ntribuição
Representa a maneira como um
a propriedade
afeta outr
a
s
propriedades
. A contribuição pode ser positiva (+) ou negativa
(
-
).
B
rito
& M
oreira
(
2003
)
deixa
m
claro que as informações na tabela
(Tabela
2
.5)
devem ser preenchidas gradativamente, pois
parte de um
a propriedade
pode ser
dependente da especificação de outr
a
.
Ambos os trabalho
s
deixam claro que a identificação de
propriedades transversais
deve ser
definida nas linhas
“Onde” e “Requisitos”.
Est
a
s serão
os
aspectos
candidatos.
c)
C
ompor aspecto
s candidatos com outros
concerns
–
o objetivo é integrar os
aspectos candidatos com
outras propriedades
que atravessam para obter todo o
2.Desenvolvimento de Software Orientado a Aspectos 33
sistema.
B
rito
& M
oreira
(
200
2
)
especifica
m
alguns passos para guiar esta
composição:
c.1) identificar como cada aspecto candidato afeta a propriedade que atravessa;
c.2) identificar os
match point
, baseados na linha”Onde” da Tabela 2.4 e 2
.5;
c.3) Identificar conflitos entre os aspectos c
a
ndidatos baseados na linha
“Contribuição” da Tabela 2
.4 e
2
.5;
c.4) identificar o aspecto dominante, baseado na linha “Prioridade” da Tabela 2
.4 e
2
.5; e
c.5) defin
i
r a regra de composição, baseado nos quatro passos acima.
Para o passo (c.1) foi adotado os conceitos de
overlap, override, wrap.
O
verlap
é
quando o aspecto candidato é
aplicado antes ou depois d
a propriedade
que atravessa.
Override
é
quando o aspecto candid
a
t
o sobrepõe
a propriedade
que atravessa, ou seja,
o comportamento descrito pelo aspecto candidato substitui o comportamento definido
pel
a propriedade
.
Wrap
é quando
o aspecto candidato encapsula
a propriedade
que
atravessa, ou seja, o comportamento descrito pel
a propriedade
a
f
etad
a
está envolvido
pelo comportamento descrito pelo aspecto candidato.
Para exemplificar graficamente o passo (c.1) é utilizado um diagrama de
casos
de uso, Figura 2.6.
2.Desenvolvimento de Software Orientado a Aspectos 34
Proprietário do
Veículo
Motorista
cruzar pedagio
sair da rodovia
entrar na rodovia
tempo de resposta
pagar fatura
segurança
registrar veiculo
Banco
<<overlapBy>>
<<overlapBy>>
<<wrappedBy>>
<<wrappedBy>>
<<wrappedBy>>
<<wrappedBy>>
F
IGURA
2
.6
–
E
XEMPLO DE
C
ASO DE
U
SO COM
A
SPECTO
C
ANDIDATO
– P
ASSO
(
C
.1)
.
A
DAPTADO DO
(
BRITO
&
MOREIRA,
200
3
).
Um exemplo de composição em diagrama de caso de uso, usando esses
operadores de composição num sistema de cobrança de pedágio é mostrado na Figura 3
.6.
Nesse exemplo
, de B
rito
& M
oreira
(
200
4
)
,
o aspecto de
segurança
afeta os casos de uso
Pagar fatura
e
Registrar veículo
com o operador
overlap
; e o aspecto de
tempo de
resposta
afeta os casos de uso
Registrar veículo, E
ntrar na rodovia, Sair da rodovia e
Cruzar
pedágio
. Entretanto, não é indicado em que pontos do fluxo dos casos de uso esses
aspectos devem ser aplicados; nem tão pouco é especificado como as preocupações de
segurança e tempo de resposta serão operacionalizadas no sistema de cobrança de pedágio.
No
trabalho anterior,
B
rito
& M
or
e
ira
(
200
2
)
i
ndica
m
que o aspecto de
segurança é decomposto em d
uas
sub
-
propriedades
: confidencia
bi
lidade e integridade,
podendo demonstrar isso através de um diagrama de composição
de
sub
-
propriedades
,
conforme a Figura 2.7.
2.Desenvolvimento de Software Orientado a Aspectos 35
F
IGURA
2
.7
–
U
SE
C
ASE DE OVERLAP DO AS
PECTO SEGURANÇA
.
A
DAPTADO DO
(
BRITO
&
MOREIRA,
2002
).
Para o Passo (c.2)
–
A i
dentificação de
match points
é
feita
utiliza
n
do uma
tabela entre atores e ca
sos de uso (Tabela
2.6). Para cada intersecção da célula listamos os
aspectos candidatos que podem ser afetados tanto pelos atores quanto pelos casos de uso.
Esta tabela servirá para identificar os aspectos conflitantes.
Proprietário do
Veículo
pagar fatura
registrar veiculo
Banco
<<after>>
<<before>>
Confidenciabilidade
Integridade
Segurança
AND
2.Desenvolvimento de Software Orientado a Aspectos 36
T
ABELA
2
.6
–
I
DENTIFICAÇÃO DE
M
ATCH
P
OINTS
.
A
DAPTADO DO
(
BRITO
&
MOREIRA,
2003
).
Casos de Uso
Atores
Registrar
veículo
Pagar fatura
Entrar rodovia
Sair rodovia
Cruzar pedágio
Banco
Tempo de
resposta,
segurança,
corretude
.
(A)
Compatibilidade,
segurança
.
(B)
Proprietário
do veíc
ulo
Tempo de
resposta,
segurança,
corretude
.
(
C
)
Regras legais,
segurança
.
(
D
)
Motorista
Compatibilidade
, tempo de
resposta,
corretude
.
(
E
)
Compatibilidade,
regras legais,
corretude
.
(
F
)
Compatibilidade,
tempo de
resposta,
corretude
.
(
G
)
Na Tabela
2
.6 nomeamos as interseções das células em
A, B, C, D, E, F
e
G
.
Em (A)
, por exemplo, temos três aspectos candidatos, Para simplificar vamos considerar
apenas os dois primeiros. Para verificarmos se existe um conflito que deve ser
considerado, temos que olhar a especificação dos dois aspectos
, Tabela
2
.4 ou Tabela
2
.5
na linha “Contribuição”,
e verificar se eles contribuem negativamente para o outro, esta
atividade seria o Passo
(
c.3
).
Para tentar resolver uma provável situação entre aspectos conflitantes
é
necessário verificar a prioridade de cada aspecto envolvido. Para isso, deve
-
se observar a
linha “Prioridade” na Tabela
2
.4 ou
2
.5. No caso do exemplo acima,
poderíamos
classificá
-
los
como “muito importante”, logo teríamos as mesmas prioridades. Assim,
n
este caso (quando os aspectos possuem a mesma prioridade) precisamos negociar um
trade
-
of
f
com o cliente ou determinar o aspecto dominante (Passo c.4).
Vamos supor que o ator Banco decida que o aspecto candidato dominante seja
a Segurança. No Passo (c.5)
vamos definir as regras de composição usando a informação
obtida até agora.
2.Desenvolvimento de Software Orientado a Aspectos 37
Assim, a regra de composição da célula
(A)
poderia ficar definida como se
segue:
Segurança.confidenciabilidade
overlaps
.before RegistrarVeiculo;
TempoResposta
wraps
RegistrarVeicu
lo;
Segurança.integridade
overlaps
.
after RegistrarVeiculo
F
IGURA
2
.8
–
E
XEMPLO DE
R
EGRA DE
C
OMPOSIÇÃO
.
F
ONTE
:
(
BRITO
&
MOREIRA,
200
3
).
A regra de composição da Figura 2
.8
expressa a ordem seqüencial na qual cada
aspecto candidato pode ser composto. Assim
, podemos definir qual
a
sub
-
propriedade
deve ser satisfeito antes do outro. No exemplo acima, vemos que a confidenciabilidade
(descrita como
segurança.confidenciabilidade)
deve ser satisfeita antes do caso de uso
Registrar Veículo.
Os
match point
s
identif
icados na Tabela
2
.6 devem ser resolvidos de
forma similar.
2
2
.
.
2
2
.
.
3
3
A
A
b
b
o
o
r
r
d
d
a
a
g
g
e
e
m
m
G
G
o
o
a
a
l
l
s
s
A abordagem GOALS ou metas utiliza alguns conceitos
relacionados
à
diagramação
do modelo i*
(
LIU et al, YU & MYLOPOULOS
apud
YU et
al, 2004)
. O
principal propósito desta a
bordagem é a identificação de aspectos através do
relacionamento entre
metas
funcionais e não
-
funcionais.
Yu et al
(
2004
)
apresenta
m
um trabalho fundamentado na análise do modelo de
metas (Giornini
apud
AORE
, 2005
)
. O modelo gráfico utilizado é chamado de
V
-
Graph
(Figura
2
.9).
2.Desenvolvimento de Software Orientado a Aspectos 38
Hard goals (objetivos ou metas) softgoals
Tarefas
F
IGURA
2
.9
–
O
GRÁFICO
V
-
G
RAPH E SUA COMPOSIÇÃ
O
.
F
ONTE
:
TRADUZIDO DE
(
AORE
,
2005
).
O
V
-
Graph
apresentado na Figura
2
.9 apresenta no topo dois vértices
,
hard
goals e soft goals
, que respectivamente são os requisitos funcionais e não funcionais em
termos de modelo de metas. A representação é baseada no modelo proposto por
(
MYLOPOULOS et al, 1992
)
.
F
IGURA
2
.10
–
O
GRÁFICO
V
-
G
RA
PH E SUA REPRESENTAÇ
ÃO
.
F
ONTE
:
TRADUZIDO DE
(
YU
ET AL
,
2004
).
Na Figura
2
.10 vemos a representação gráfica de
Objetivo/Meta (
goals
ou
requisitos funcionais),
S
oft
G
oal
(requisitos não funcionais) e
T
arefas
(
task
).
Existe uma relação de contribuição entre
as
Task
e os
Goal
e
SoftGoal
,
ou seja,
uma tarefa contribui (de alguma forma) para que os requisitos funcionais ou não
funcionais sejam satisfeitos. De forma similar existe uma correlação entre Goal
e
SofGoal
.
Objetivo/
Meta
Tarefa
SofGoal
Correlação
Contribuição
Contribuição
Contribuições
e correlações
2.Desenvolvimento de Software Orientado a Aspectos 39
T
ABELA
2
.7
–
C
ONTRIBUIÇÃO E
C
ORRELAÇÃO
.
A
DAPT
ADO DO
(
YU
ET AL
,
2004
).
Tipo de Link
e
ou
faz
ajuda
prejudica
Quebra
Contribuição
Y
Y
Y
Y
Y
Y
correlação
N
N
Y
Y
Y
Y
A Tabela
2
.7 demonstra os tipos de relação que podem existir entre os
elementos do
V
-
Graph
,
onde podemos observar
os tipos de
link
e as
relações que podem
existir entre
Task , Goal e SoftGoal
.
O processo de construção e descoberta de aspectos consiste principalmente
no
refinamento sistemático do
V
-
Graph
.
O processo termina quando todos os objetivos
(
goals
) principais e todos os
softgoals
são satisfeitos. Nesta etapa estamos aptos a
identificar aspectos candidatos através das tarefas que possuem um alto
fan
-
in
7
.
F
IGURA
2
.11
–
A
VISÃO GERAL DA
A
BORDAGEM
G
OAL
.
F
ONTE
:
TRADUZIDO DE
(
YU
ET AL
,
2004
).
7
Fan
-
in
–
número de módulos que chamam (ou usam); Fan
-
out
–
número de módulos que são chamados (ou
usados) . Fonte: Constantine e Yourdon (1979
)
decom
posto
Lista de objetivos
softgoals
correlacionado
Objetivo
principal
Objetivos
softgoals
tarefas
Resolver
conflitos
Não
Objetivos
tarefas
Sem conflitos
Sim
Não
Consistente
Sim
Não
Satisfeito
Sim
Correlação
d
ecomposição
Objetivos
softgoals
tarefas
Lista de aspectos
Aspectos
V
-
Graph
softgoals
2.Desenvolvimento de Software Orientado a Aspectos 40
A Figura
2
.11 mostra uma visão do processo
de modelagem do
V
-
Graph
.
Inicialmente um conjunto de objetivos, incluindo um ou mais objetivos funcionais e
alguns não funcionais, são listados. Depois o engenheiro de requisitos e o especialista de
domínio decompõe os objetivos (metas ou
goals
) e softgoa
ls em sub
-
objetivos (submetas
ou
subgoals
) e
subsof
t
goals
ou tarefas, e correlaciona os objetivos/tarefas da perspectiva
funcional para o
softgoal
operacionalizações
8
de um não funcional.
O refinamento do
processo pode ser sem deteriorações e os conflitos
podem ser resolvidos através de uma
análise formal dos objetivos (
goals
)
,
até que os objetivos (goals) e os
softgoals
estejam
satisfeitos.
Assim como Yu et al (2004), M
artinez
et al (2004) utiliza
m
a abordagem
GOALS. Contudo, o enfoque baseia
-
se nos padrõe
s ISO/IEC 9126 como ponto de partida
para estabelecer metas e requisitos; e as recomendações IEEE 830
-
1998 (IEEE, 1998) para
a definição de especificação de requisitos. O principal argumento utilizado por
MARTINEZ et al é que a utilização dos padrões de qu
alidade ISO/IEC 9126 facilitam a
identificação dos requisitos não funcionais e, por conseqüência, a identificação das metas
a serem utilizadas no sistema a ser desenvolvido.
A norma ISO/IEC 9126 (ISO, 1994)
, utilizada por MARTINEZ et al.
define
um conjunto
de critérios ou características desejáveis referentes ao software e sua
estrutura
. Esta norma foi definida para
os documentos técnicos durante o último encontro
Internacional do SC7, em junho/
1994
e
possui 3 ramificações
: ISO/IEC 9126
-
1
-
Características
e sub
-
características de qualidade, ISO/IEC 9126
-
2
-
Métricas externas ,
ISO/IEC 9126
-
3
-
Métricas internas
.
A
Tabela
2.8 apresenta as características de qualidade ISO/IEC 9126.
8
Operacionalizações se referem a um conjunto de tarefas (tasks) (AORE, 2005).
2.Desenvolvimento de Software Orientado a Aspectos 41
T
ABELA
2
.8
–
C
ARACTERÍSTICAS DE
Q
UALIDADE
ISO/IEC
9126.
A
DAPTADO DO
(
M
ARTINEZ
ET AL
,
2004
)
.
Tipo de qualidade
Característica
Sub
-
característica
Adequação;
Acurácia;
Interoperabilidade;
Conformidade;
funcionalidade
Segurança de acesso.
Maturidade;
Tolerân
cia a falhas
Recuperabilidade
Confiabilidade
Flexibilidade
Inteligibilidade;
Apreensibilidade
Operacionabilidade
Atratividade
Usabilidade
Flexibilidade
Comportamento em relação ao tempo
Comportamento em relação aos
recursos
Eficiência
flexibil
idade
Analisabilidade
Modificabilidade
Estabilidade
Testabilidade
Manutenibilidade
Flexibilidade
Adaptabilidade
Capacidade para ser instalado
Conformidade
Capacidade para substituir
Qualidade do produto de
software
Portabilidade
Flexibilidade
Efetividade
Produtividade
Segurança
Qualidade em Uso
Satisfação
A abordagem de
(
MARTINEZ et al, 2004
)
é útil ao se definir um ponto de
partida para os requisitos não funcionais, porém, não considera o trabalho elaborado por
Yu et al
(
2004
)
, que também explora a Ab
ordagem
Goals
. Além disso
,
argumenta que as
outras propostas
existentes
(
RASHID et al, 2002
)
(
BRITO et al, 2004
)
não
oferece
m ao
analista um framework o qual possa auxiliar a identificação de
propriedades
do sistema,
2.Desenvolvimento de Software Orientado a Aspectos 42
além de fazerem uma distinção entre req
uisitos funcionais e não
-
funcionais através do
emprego de diferentes técnicas para descrever os tipos de requisitos.
Neste trabalho, a
autora a
credita ser
necessária
uma diferenciação dos tipos
de
requisitos
, uma vez que são tratados de forma diferente
, as
sim como no trabalho de
Martinez (2004)
. Porém sem esquecermos que aspectos podem ser requisitos funcionais.
Este é um ponto
que
a abordagem de
Goals não
possui uma definição mais clara,
pois
apresenta aspectos
como sendo
os
requisitos não
-
funcionais
, argu
mentando que em sua
maioria o são
.
2
2
.
.
2
2
.
.
4
4
A
A
b
b
o
o
r
r
d
d
a
a
g
g
e
e
m
m
C
C
o
o
m
m
C
C
a
a
s
s
o
o
s
s
d
d
e
e
U
U
s
s
o
o
A abordagem dirigida a casos de uso provê um método para desenvolver
aplicações através da concentração na realização d
a
s
propriedades
dos stakeholders.
J
acobson
& NG
(
2005
)
argumenta
que os casos de uso são transversais por natureza, uma
vez que sua realização pode afetar outras classes.
A principal dificuldade estava em manter
as propriedades transversais
separadas
durante todo o processo, porém isso foi conseguido através do conceit
o de casos
de uso
slices
(que veremos mais a seguir).
Seu método consiste em realizar a atualização do modelo continuamente
durante o processo.
F
IGURA
2
.12
–
A
TUALIZAÇÃO DOS MODELOS NO DESENVOLVIMENT
O
.
A
DAPTADO DE
(
JACOBSON
&
NG,
2005
).
A abordagem identifica dois tipos de
propriedades transversais
:
peers
e
extensions
. Os do tipo
peers
não precisam um do outro para sua existência, podendo ser
Especificando
casos de uso
Analisando
casos de uso
Design e Implementando
casos de uso
atualizações
atualizações
atualizações
Modelo de
casos de uso
Modelo de
análise
Modelo de
design
Modelo de
implementação
2.Desenvolvimento de Software Orientado a Aspectos 43
desenvolvidos sistemas em separado para cada um deles, como por exemplo, transferên
cia
de fundos, reserva de quarto e
check
-
in
. Porém, quando começamos a implementar os
peers
no mesmo sistema, encontramos sobreposições significantes entre eles.
F
IGURA
2
.13
–
E
FEITOS DE DISPERSÃO
E
ENROLAÇÃO
QUANDO REALIZAMOS PEERS
.
A
DAPTADO DE
(
JACOBSON
&
NG,
2005
).
A limitação em manter os do tipo
peers
separados causam dois efeitos
conhecidos na linguagem aspectos como enrolação
9
e dispersão
10
.
Na enrolação podemos
encontrar
um
componente que contem a implementação para sat
isfazer outro
s
componente
s
, ou seja, um caso de uso tipo
peers
possui na sua realização uma alteração ou
implementação de um comportamento de uma outra classe
(s)
. Na Figura
2
.13 observamos
que o componente
Quarto
está envolvido na realização de
d
ua
s
difer
entes
propriedades
.
Na dispersão podemos encontrar códigos que realizam um
a
propriedade
em particular que
está espalhado através de múltiplos componentes. Na Figura
2
.13 observamos que a
realização de
Check in
Clientes impõe comportamento adicional em
três
outros
componentes.
Um outro tipo de
propriedade transversal
é chamado de
extensions
. Os
extensions
são componentes que definimos no topo da base, representam serviços ou
características adicionais. Embora seja natu
r
al descrever
a base (ou o caso de uso b
ase)
separada da extensão, existe um problema quando implementamos a extensão.
9
Tradução literal de
tangling
.
10
Tradução literal de
scattering
.
Propriedades
Reserva de
Quarto
Check in
Clientes
Check out
Clientes
Component
es
Tela do cliente
Reserva quarto
reserva
Check in
Tela staff
Check out
quarto
2.Desenvolvimento de Software Orientado a Aspectos 44
F
IGURA
2
.14
–
E
XEMPLO DE
E
XTEN
SÃO
.
A
DAPTADO DE
(
JACOBSON
&
NG,
2005
).
Na figura
2.14 observamos que a
extension
é inserida de forma intrusiva
(com
o
é conhecida na linguagem aspectos) no código base.
Este fragmento de código que chama
a
extension
é conhecido como pontos de extensão
11
.
Nesta abordagem são utilizados alguns conceitos da linguagem AspectJ, como
po
i
ntcuts
, que identificam um ponto de exec
ução no código base e
advice
, que descrevem
o comportamento adicional que será executado ao chegar neste ponto.
Nas Figuras 2.13 e 2.14 fica evidente a necessidade de preservar a separação de
propriedades
através do
design
e implementação, para evitar os
problemas de dispersão e
enrolação já citados. Assim, é necessário colecionar a especificação dos casos de uso
durante o
design
em uma unidade modular, denominada
use
case
slic
e
12
. Cada
use case
slice
possui partes de classes, operações, e assim por diante, que especificam o
caso de uso
no modelo (J
acobson
& N
g
(
2005
)
argumenta
m
que deve ser feito um caso de uso
slice
para cada caso de uso do sistema).
Na verdade, quando realizamos o caso de uso, identificamos classe, atributos,
operações e relacionamentos d
estas classes. Algumas destas classes e suas características
são espec
í
ficas da realização do caso de uso, outras são necessárias, porém são de outros
casos de uso. Cada use case
slice
cont
é
m a especificação da realização do caso de uso em
um modelo. A par
te genérica e reusável
são mantidas
em casos de uso específicos não
slices
. Todos estes
slices
são então agrupados
para formar
tod
o o
modelo
de
design
.
11
Tradução literal de
extension points
.
12
A tradução para o termo utilizado ficaria: pedaços de casos de uso. Porém iremos utilizar o termo em
inglês.
Base
Extension
Reserva
de Quarto
Lista de
Espera
Fragmento de código adicionado para chamar o
componente de lista de espera
2.Desenvolvimento de Software Orientado a Aspectos 45
Camada
aplicação
Camada
domínio
Estrut
ura casos de uso
Estrutura de elementos
composição
composição
F
IGURA
2
.15
–
E
STRUTURA DOS ELEMENT
OS E CASOS DE USO
SLICES
.
A
DAPTADO DE
(
JACOBSON
&
NG,
2005
).
Na Figura
2.15 podemos observar que a estrutura dos elementos é apenas uma
forma de identificar onde os elementos residem no modelo. Tratamos estes elementos,
como classes, como caixas vazias. Seu conteúdo (comportamento) será preenchido através
dos casos
de uso
slices
através do mecanismo de composição.
Ou seja,
os casos de uso
slice
não contêm
a classe completa, possui apenas
parte delas, chamadas de extensão da classe.
As extensões da classe contêm
apenas as
características necessárias para concretizar o caso de uso.
F
IGURA
2
.16
–
C
OMPOSIÇÃO DA REALIZA
ÇÃO DE CASOS DE USO
PEER COM CASOS DE USO
SLICES
.
A
DAPTADO DE
(
JACOBSON
&
NG,
2005
).
Casos de Uso
Reserva Quarto
Check in
Check out
Reserva Quarto
+Check in +
C
heck out
Comportamento da extensão da classe
espec
í
f
i
co da realizaç
ão do caso de uso
slices
Reserva Quarto
Check in
Check out
Tela
cliente
Tela
Staff
Reserva
Quarto
Check
in
Check
out
Reserva
Quarto
Classes
2.Desenvolvimento de Software Orientado a Aspectos 46
A figura
2.16 demonstra um exemplo dos casos de uso base e seus slices, com
as partes das classes e onde elas são atualizadas.
J
acobson
& N
g
(
2005
)
também argumentam que a representação tradicional de
casos de uso pode não ser clara o suficiente quando queremos especificar as sub
-
rotinas ou
extensões existentes no fluxo.
F
IGURA
2
.17
–
R
EPRESEN
TAÇÃO DE
C
ASOS DE
U
SO
.
A
DAPTADO DE
(
JACOBSON
&
NG,
2005
).
Embora a representação (B) da Figura
2
.17 seja mais clara, pois especifica os
fluxos existentes, não possui ferramenta case para con
s
truí
-
la
.
A representação dos
r
equisitos não
-
funcionais é
realiz
ada
através de um caso
de uso especial chamado de
perform transaction
e os requisitos funcionais (os tradicionais
e usuais) chamamos de casos de uso de aplicação.
F
IGURA
2
.18
–
E
STRUTURANDO
C
ASOS DE
U
SO DE INFRA
-
ESTRUTURA
.
A
DAPTADO DE
(
JACOBSON
&
NG,
2005
).
A Figura
2.18 demonstra a utilização de um exemplo de casos de uso de infra
-
estrutura
(não funcionais)
. Apesar dos requisitos não
-
funcionais serem tratados como
extends
, eles fazem parte de um
caso de uso único, o
<
perform transaction
> que é
requisita
do
para
executar os requisitos não
-
funcionais.
Reserva de Quarto
Reserva de
Quarto
Flows
{basic} Reserva quarto
{alt}submissão duplicada
{sub}checar custo do quarto
(A)
(B)
<ator>
<perform transaction>
tratar autorização
realizar auditoria transações
rastrear preferências
<<extend>>
<<extend>>
<<extend>>
2.Desenvolvimento de Software Orientado a Aspectos 47
Ao lidar com um requisito de tempo de resposta de 2 segundos, por exemplo,
devemos modelar e expressar este tipo de requisito como declarações na seção especial do
use case <
perform transaction>, como demonstra a Figura 2.19.
F
IGURA
2
.19
–
A
E
SPECIFICAÇÃO DO
C
ASO DE USO
<
PERFORM TRANSACTION
>.
A
DAPTADO DE
(
JACOBSON
&
NG,
2005
).
S
ouza
(
2004
)
argument
ou em seu trabalho
que nesta abordagem não se pod
ia
manter a separação de propriedades durante
o ciclo de vida do
processo
, sendo ineficiente
.
Porém, seu trabalho não incluiu o trabalho atual do J
acobson
& N
g
(2004), pois sua
publicação foi posterior a dissertação de Souza. Assim, com o ultimo trabalho de J
acobson
Especificação d
e Caso de Uso: <perform transaction>
Fluxo Básico
O caso de uso começa quando um ator instancia a execução de uma transação
para visualizar valores de uma instância de uma entidade.
1. O sistema indica a instância do ator que identifica a instância da ent
idade
desejada.
2. A instância do ator entra com valores e submete sua requisição.
3. O sistema resgata a instância da entidade (seus dados) e mostra os valores.
4. O caso de uso termina.
Fluxo alternativo
A1. Controle de Acesso
Se no passo 3 do fluxo básico a requisição requer autorização, o sistema checa
os direitos da instancia do ator.
1.
Se a instancia do ator não possui direitos de acesso a requisição é
rejeitada. O caso de uso termina.
2.
Caso contrario, o caso de uso continua.
A
2. Preferência do Usuário
No passo 1 do fluxo básico, se a prioridade principal é definida, o sistema
carrega a preferência e usa aqueles valores como padrão para a requisição da
instancia do ator. O caso de uso reinicia.
No passo 2 do fluxo básico, se o usuário indica que o valor
submetido será
usado como padrão, o sistema armazena como uma preferência do usuário.
A
3. Logging
No passo 2 do fluxo básico, a requisição deve ser logada; o sistema armazena a
requisição solicitada no arquivo de log.
Requisitos especiais
Todos as chamadas não devem demorar mais do que 2 segundos.
2.Desenvolvimento de Software Orientado a Aspectos 48
& N
g
(2004)
, agora
isto
já pode ser feito, uma vez qu
e adicionando recursos novos, como
o casos de uso
slices
, podemos separar
as propriedades transversais
peers
, ponto crucial
para
esta abordagem.
Na definição do trabalho de Souza (2004) com os casos de uso, é
utilizada
uma
tabela de composição para identificar o tipo de composição do aspecto em relação ao caso
de uso afetado, bem como uma tabela de resolução de conflitos para o caso em que dois
aspectos diferentes devem ser incluídos no mesmo ponto de junção do caso de uso afetado.
Jacobson
& N
g
(
2004
)
acre
dita
m
que o desenvolvimento de software se resume
a construir modelos. Começamos com o modelo de casos de uso para capturar
a
s
propriedades
dos
stakeholders
, refinamos este modelo no modelo de análise, o qual
também formula uma visão de alto nível do siste
ma, preparamos a estratégia de como o
sistema executará na plataforma com o modelo de
design
, e no modelo de implementação,
temos
os códigos atuais e binários.
Isto é previsto por qualquer processo de desenvolvimento existente, porém na
abordagem com casos
de uso isto é feito caso de uso por caso de uso através do
refinamento e realização.
Quando este trabalho é terminado (com o caso de uso) temos todos os artefatos
associados com o caso de uso em um simples pacote
13
, o qual é chamado de m
ó
dulo de
caso de us
o. Este m
ó
dulo compreende os
use
-
case slices
de cada modelo. Os módulos de
casos de uso são desenvolvidos separadamente e depois compostos para formar o sistema
como um todo.
2
2
.
.
2
2
.
.
5
5
A
A
b
b
o
o
r
r
d
d
a
a
g
g
e
e
m
m
T
T
h
h
e
e
m
m
e
e
/
/
D
D
O
O
C
C
A Abordagem
Theme
é constituída de duas partes:
The
me/Doc
e
Theme
/UML.
Elas representam
themes
em diferentes fases do ciclo de vida
(
BANIASSAD & CLARKE,
2004b
)
(
CLARKE & BANIASSAD, 2005
)
.
B
aniassad
& C
larke
(
2004b
)
apresentam o
theme
como sendo um elemento de
design
, uma coleção de estruturas e comportamentos que representam uma característica.
13
Tradução literal de package
2.Desenvolvimento de Software Orientado a Aspectos 49
Na Figura 2.20 é apresentado um conjunto de atividades a serem realizadas por
cada uma das partes, tanto o Theme/Doc
quanto o
Theme
/UML.
F
IGURA
2
.20
–
.
O
P
ROCESSO
T
HEME
.
A
DAPTADO DE
(
CLA
RKE
&
BANIASSAD,
2005
).
ANÁLISE
Requisitos
Themes
Relacionamentos
escolher
visão
rede
Base
Aspectos
DESIGN
Base
Aspectos
Aspectos
(surgidos do
baixo
níve
l design)
modelos
COMPOSIÇÃO
Design
da
composição
Especificação da
composição
verificar
mostrar
visão
retrabalho
retrabalho
retrabalho
escrever
automático
Theme/Doc
Theme/UML
2.Desenvolvimento de Software Orientado a Aspectos 50
Na Figura 2.20 podemos observar que a representação
Theme
/Doc é usad
a
para
visualizar e analisar requisitos e
Theme
/UML é usad
a
na aplicação de
projeto
. De maneira
geral o processo
Theme
é dividido em três atividades principais:
a)
An
álise
–
onde é realizado a análise dos requisitos para identificação dos
themes
. Esta atividade envolve o mapeamento dos requisitos para
propriedades
no sistema.
Theme
/Doc
permite a visualização dos
relacionamentos entre os comportamentos. Estes relaciona
mentos expõem
a
s
propriedades
enrolados
14
e permite a identificação dos aspectos.
b)
Design
–
O design dos
themes
é feito utilizando o
Theme
/UML. No
Theme
/Doc identificamos classes e métodos em potencial, depois
preenchemos os detalhes de
desi
gn
e realizamos m
udanças que são
necessárias para o benefício do design. Outros aspectos
aparecem durante o
detalhamento técnico do design.
c)
Composição –
Nesta fase especificamos como os modelos
Theme/UML
devem ser combinados. Em muitos casos, algumas visões do
Theme/Doc
au
xiliam na determinação de como os
themes
se relacionam com outro: se
eles se sobrepõem
ou se eles atravessam
15
o outro.
Na Figura
2
.20 observamos que temos algumas setas com a indicação de
automático, isto é devido a ferramenta citada por
B
aniassad
& C
larke
(
2004b
)
, porém
,
não
está disponível para download
(
THEME, 2006
)
.
Veremos com mais atenção a abordagem Theme/Doc, por se tratar da análise
de requisitos.
B
aniassad
& C
larke (
2004b
)
definem que aspectos são comportamentos que
estão espalhados pelo sistema e
,
no documento de requisitos
,
eles se manifestam como
d
escrições
de comportamentos que estão interconectados e entrelaçados por todo o tempo.
Um ponto interessante nesta abordagem é que não se pode identificar aspectos
em requisitos com termos de ação únic
os, ou seja, as ações (ou verbos de ação na
sentença) são considerados como
themes
. Assim, se todos os requisitos são únicos (se
referem a um único verbo de ação) não possuem aspectos. Neste caso é necessário, muitas
vezes, refazer os requisitos.
14
Tradução literal de tangled
15
Tradução literal de crosscut
2.Desenvolvimento de Software Orientado a Aspectos 51
Um outro
ponto a considerar são os requisitos não funcionais. Nestes casos não
há palavras de ação, porém
, eles
são transversais por natureza e a solução, nestes casos, é
igualmente refazer os requisitos para incluir tais características.
O modelo
Theme
/Doc possui
dois tipos (observados na Figura 2
.20):
a) Base
Themes – podem compartilhar estruturas e comportamentos com outros
base
themes
.
b)
Crosscutting Themes
(Aspectos)
–
possui comportamentos que sobrepõe a
funcionalidades dos base
themes
.
O processo
theme
/Doc
possui as seguintes atividades a serem desenvolvidas:
1)
Identificar
themes
em potencial
–
a identificação é feita a partir
de ações ch
aves no
documento de requisitos. Na realidade é feita uma análise do documento de requisitos
e identificados entidades ch
aves e
propriedades
chaves. Em um próximo passo, é feito
uma iteração sobre o conjunto para decidir se
:
acrescenta, deleta, divide ou agrupa os
themes
.
C
larke
& B
aniassad
(
2005
)
argumenta que podemos começar com a escolha
de nomes de características, serviços, ou casos de uso do sistema para chegar no ponto
inicial de
themes
.
B
aniassad
& C
larke
(
2004b
)
indica a escolha dos verbos de ação
para o ponto inicial dos
themes
e a partir daí ir refinando para encontrar os
themes
exatos para o sistema.
Um ponto a co
nsiderar é que nem todas as características serão
themes
, porém esta tarefa de escolha das entidades e palavras de ação ainda é manual
na ferramenta
(
THEME, 2006
)
e depende da experiência do engenheiro de requisitos.
É importante observar que palavras sinônimas que se referem a mesma ação devem ser
agrupadas sobre uma única palavra de ação. Com esta atividade realizada a ferramenta
gera o gráfico de Visão de Ações
–
Figura
2
.21. Onde a elipse é um
theme
e um
retângulo se refere ao requisito.
2.Desenvolvimento de Software Orientado a Aspectos 52
F
IGURA
2
.21
–
.
E
XEMPLO
A
BSTRATO DO
G
RÁFICO DE
V
ISÃO DE
A
ÇÕES
16
.
A
DAPTADO DE
(
CLARKE
&
BANIASSAD,
2005
).
2) Refinar o conjunto de
themes
-
Se um requisito (Requisito 1 da Figura 2
.21) é ligado a
mais de uma palavra de ação
,
está caracterizado
um comportamento enrolado
17
ou
complicado. Este relacionamento deve ser analisado para verificar se é uma má
especificação de requisitos ou se existe um comportamento
crosscutting
. No caso de
muitas ligações entre os requisitos a palavras de ação, onde a v
erificação foi feita e foi
decidido que é do jeito que está especificado, a ação predominante para o requisito
deve ser definida (e assim selecionada como
base), e
a segunda ação deve ser ligada a
primeira, indicando que a segunda aç
ão /comportamento atrav
essa o comportamento
base. Após todos os requisitos compartilhados serem ligados ao seu comportamento
secundário
o gráfico de Visão de Ações Ligadas é obtido, conforme a Figura
2
.22.
Nesta figura a linha pontilhada indica que não houve decisão a ser tomad
a com
respeito ao requisito 3, a linha cinza indica que o primeiro
theme crosscutt
o segundo
theme
.
Podemos observar ainda que o primeiro
theme
domina o requisito 1. Assim,
neste gráfico
a
linha cinza indica o relacionamento de
crosscutting
.
16
BANIASSAD&CLARKE
(
200
4b)
.
chamam este gráfico de Action Views e em
CLARKE &
BANIASSAD
(
2005
) este mesmo gráfico é chamado de Relationship view, porém são idênticos nos
conceitos
.
17
Tradução literal de tangling
Primeiro
Theme
Segundo
Theme
Terceiro
Theme
Requisito 1: se refere
ao primeiro e segundo
theme
Requisito 2: se refere
ao terceiro theme
2.Desenvolvimento de Software Orientado a Aspectos 53
F
I
GURA
2.22
–.
E
XEMPLO
A
BSTRATO DO
G
RÁFICO DE
A
ÇÕES
L
IGADAS
18
.
A
DAPTADO DE
(
CLARKE
&
BANIASSAD,
2005
)
.
3) Preparar para
design
–
O gráfico theme view
é usado para planejar o
design
e a
modelagem dos
themes
identificados no passo anterior. Este gráfico difere
do gráfico de
visão de ações no sentido de que não apenas mostrar os requisitos e as ações, mas também
mostrar os elementos do sistema necessários a serem considerados para cada
theme design
no
Theme
/UML. Para construir esta visão o desenvolvedor/engenhei
ro de requisitos deve
fornecer um conjunto adicional de informações, as entidades chave.
A figura
2
.23 mostra
um exemplo deste gráfico
. Usamos o
theme
view
para planejar as classes e métodos no
Theme
/UML. Ao modelarmos usamos as práticas de design de orien
tação a objetos para
auxiliar na determinação de quais classes e métodos são descritos.
N
a maior parte dos
casos os métodos
são as ações e as classes são as entidades, porém podemos acrescentar
outras entidades e métodos como decisões de design.
Assim, to
rna
-
se claro que apesar de endereçar quase todos os requisitos ainda
não é
suficiente
se este
endereçamento
irá suprir todas as necessidades
(de classes e
entidades)
, uma vez que pode ser acrescido de elementos não identificados inicialmente.
18
BANIASSAD&C
LARKE
(
200
4b)
.
chama este gráfico de Clipped Views e em
CLARKE & BANIASSAD
(
2005
) chama este gráfico de Crosscutting view, porém os conceitos são os mesmos.
Primeiro
Theme
Segundo
Theme
Terceiro
Theme
Requisito 1: se
refere ao primeiro e
segundo theme
Requisito 3: se refere
ao terceiro theme
2.Desenvolvimento de Software Orientado a Aspectos 54
F
IGURA
2
.2
3
–
.
E
XEMPLO
A
BSTRATO DO
G
RÁFICO DE
T
HEME
V
IEW
.
A
DAPTADO DE
(
CLARKE
&
BANIASSAD,
2005
).
2
2
.
.
3
3
C
C
o
o
m
m
p
p
a
a
r
r
a
a
ç
ç
ã
ã
o
o
e
e
n
n
t
t
r
r
e
e
A
A
b
b
o
o
r
r
d
d
a
a
g
g
e
e
n
n
s
s
A
A
p
p
r
r
e
e
s
s
e
e
n
n
t
t
a
a
d
d
a
a
s
s
Todas as abordagens possuem um ponto em comum quando afirmam que com
a identificação de
propriedades transve
rsais
nas fases iniciais do processo de
desenvolvimento pode
-
se obter benefícios da sua utilização nos artefatos de requisitos,
análise e projeto, e não apenas na implementação, como era feito logo no início da
orientação a aspectos.
Partindo desta premiss
a e baseado nas características de qualidade elaboradas
pela ISO/IEC 9126
, definimos
algumas características
a serem consideradas para a
comparação entre as abordagens, que definimos de acordo com a Tabela 2.9 e 2.10
A Tabela
2
.9 apresenta as característi
cas gerais e seus conceitos, de acordo
com a norma
ISO/IEC 9126
e adaptadas para o nosso propósito
, e a Tabela
2
.10 apresenta
as sub
-
características que servirão de base
à
comparação efetuada, apresentada na Tabela
2.12.
Primeiro
Theme
Segundo
Theme
Terceiro
Theme
Requisito 1: se
refere ao primeiro e
segundo
theme
Requisito 3: se refere
ao primeiro theme e ao
terceiro theme
Requisito 1: se
refere ao primeiro e
segundo theme
Primeiro
elemento
Segundo
elemento
2.Desenvolvimento de Software Orientado a Aspectos 55
Vale observar que as sub
-
caracterís
ticas listadas na Tabela
2
.10 correspondem
a uma adaptação das sub
-
características originais, apresentadas nas normas ISO/IEC 9126.
As sub
-
características em fundo amarelo foram incluídas para realizar a comparação e não
existia originalmente. As outras fo
ram adaptadas em seus conceitos para realizar tal
comparação
T
ABE
LA
2
.
9 –
A
DAPTAÇÃO DOS
C
ONCEITOS DAS
C
ARACTERÍSTICAS DE
Q
UALIDADE ISO/IEC
9126
Características de Qualidade
Funcionalidade
Evidencia que o conjunto de funções atende às necessidades
explícitas e implícitas para a finalidade a que se destina
a
abordagem
.
Confiabilidade
Evidencia que o desempenho se mantém ao longo do
ciclo ou
fase a que se destina e em condições estabelecidas.
Usabilidade
Evidencia a facilidade para a utilização d
a abordag
em
.
Eficiência
Evidencia que os recursos e os tempos envolvidos
para a
aplicação da abordagem são compatíveis com o níve
l de
desempenho requerido para a aplicação da abordagem.
Manutenibilidade
Evid
e
ncia que há facilidades para correções, atualizações e
a
lterações
durante a sua aplicação.
Portabilidade
Evidencia que é possível utilizar a abordagem
em diversas
plataformas (utilizando sua ferramenta Case)
com pequeno
esforço de adaptação.
2.Desenvolvimento de Software Orientado a Aspectos 56
T
ABELA
2
.10
– S
UB
-
C
ARACTERÍSTICAS PARA
C
OMPARAÇÃO DAS
ABORDAGENS
Caracteristica
Sub
-
caracteristica
Conceito
Abrangência
Indica qual a fase do processo de
desenvolvimento é considerada na abordagem
Adequação
A abordagem deve ter um conjunto de
funções/passos apropriados para a separação e
composição de
propriedade
Acurácia
Geração de resultados satisfatórios. (indicar
ponto fraco)
Interoperabilidade
Capacidade de interagir com outros produtos
Funcionalidade
Conformidade
Estar de acordo com normas, convenções e
regulamentações.
Origem
Ano do primeiro trabalho publicado da
proposta
Confiabilidade
Maturidade
Grau de maturidade da proposta
Artefatos
Principal artefato utilizado para a elucidação
dos aspectos e
propriedades
Apoio Case
Indica se a abordagem possui ferramenta Case
de Apoio
Inteligibilidade
Facilidade oferecida ao usuário em entender
os conceitos utilizados
Usabilidade
Apreensibilidade
Facilidade de aprendizado
Resolução de Conflitos
Indica se a abordagem possui mecanismos ( e
seu nível) bem definidos para a resolução
de
conflitos
Tratamento de
Requisitos
Organizacionais
Indica se a abordagem possui estratégia de
tratamento para requisitos organizacionais.
Requisitos funcionais
–
aspectos
Indica se a abordagem considera que
requisitos funcionais possam ser aspectos
Requisitos não
funcionais
–
aspectos
Indica se a abordagem considera que
requisitos não funcionais possam ser aspectos;
Eficiência
Comportamento em
relação aos recursos
Quantidade de recursos (artefatos) utilizados
para a execução das tarefas
R
astreabilidade
Indica se a abordagem oferece um método
para realizar o rastreamento de aspectos
durante o ciclo de vida de desenvolvimento
Analisabilidade
Facilidade de diagnosticar deficiências e
causas de falhas
Modificabilidade
Facilidade de modifi
cação e remoção de
defeitos
Manutenibilidade
Testabilidade
Facilidade da abordagem ser testada e
validada
Adaptabilidade
Capacidade de ser adaptada a ambientes
diferentes
Capacidade para ser
instalada
Facilidade para executar a instalação em
ambientes específicos (ao possuir ferramenta
que a implemente)
Portabilidade
Capacidade para
substituir
Facilidade em substituir outra abordagem
utilizada pelos desenvolvedores
2.Desenvolvimento de Software Orientado a Aspectos 57
Para os
critérios
utilizados
para a
comparação efetuada entre as abordagens
adotou
-
se
três níveis d
e avaliação: fraca, regular e boa. A especificação de cada uma
encontra
-
se na Tabela
2
.11. Este critério foi utilizado na comparação efetuada na tabela
2.12.
T
ABELA
2
.11
–
C
RITÉRIOS DE PADRÕES UTILIZADOS NA COMPAR
AÇÃO
Critérios
Característica
Bo
a
Regular
Frac
a
Abrangência
Abrange a todas as fases
do desenvolvimento de
software
Abrange mais que uma
fase do desenvolvimento
de software.
Abrange apenas uma
fase do desenvolvimento
de software.
Adequação
Conjunto de artefatos e
fases bem definidas
Um ou mais
artefatos
com pouca ou nenhuma
definição ou uma ou
mais fases com pouca ou
nenhuma definição
Um ou mais artefatos
com pouca ou nenhuma
definição e uma ou mais
fases com pouca ou
nenhuma definição
Acurácia
Gera todos os artefatos
de forma satisfatória e
co
m objetividade
Deixa de gerar um
artefato de forma
satisfatória ou com
pouca objetividade
Deixa de gerar mais de
um artefato de forma
satisfatória ou com
pouca objetividade
Interoperabilidade
Feita através de uma
especificação para a
exportação em format
o
padrão (XML, MOF,
etc.)
Possui exportação para
alguns formatos, porém
dentro da própria família
do fabricante.
Não possui
Conformidade
Segue padrões
conhecidos (UML, etc)
Segue padrão da própria
família do fabricante.
Não possui padrão
Origem*
Não po
ssui critério. Apenas indica o ano da primeira publicação da abordagem.
Maturidade
Possui várias
publicações (mais de 3)
e/ou livro da abordagem
Possui publicações (até
três) , porém não há
livro sobre o assunto.
Possui até duas
publicações.
Artefatos
Po
ssui mais de
três
artefatos (gráficos,
tabelas, etc) para apoiar
a abordagem
Possui até
três
artefatos.
Possui um artefato
principal.
Apoio Case
Possui ferramenta case
disponível para apoiar o
desenvolvimento
Possui ferramenta, mas
não se encontra
disponí
vel para
download
Não possui ferramenta
case.
Inteligibilidade
Artefatos simples e bem
definidos
Possui artefatos simples
e
alguns
complexos
Artefatos complexos e
difíceis de entender
Apreensabilidade
Objetiva e fácil de
entender os conceitos
Conceitos
mais
complexos, porém não
apresenta dificuldade
alta.
Conceitos complexos e
com grau de dificuldade
médio para alto
Resolução de Conflitos
Apresenta mecanismos
simples e bem definidos
Apresenta mecanismos
complexos para
resolução de conflitos
Não apresen
ta
mecanismos
Tratamento de
Requisitos
organizacionais
Possui tratamento de
forma diferenciada
Possui tratamento de
forma unificada com
RNF
Não possui
Requisitos funcionais
–
aspectos
Considera e possui
tratamento específico
Considera, mas não pos
-
sui tr
atamento diferenci
-
ado ou não explica como
Não considera
Continua
na próxima página
2.Desenvolvimento de Software Orientado a Aspectos 58
Continuação da Tabela
2
.11
Critérios
Característica
Boa
Regular
Fraca
Requisitos
não
funcionais
–
aspectos
Considera e possui
tratamento específico
Considera, mas não
pos
-
sui tratamento diferenci
-
ado ou não explica como
Não considera
Comportamento em
relação aos recursos
Não possui quantidade
definida (ou possui sem
o rigor da
obrigatoriedade), porem
todos são bem objetivos
e simples
Possui quantidade
definida e todos
são
necessários
Possui quantidade bem
definida, porém alguns
não são bem
objetivos
Rastreabilidade
Possui mecanismos para
rastrear aspectos de
forma simples e direta
Possui mecanismos,
porém sem
rastreabilidade durante a
fase inicial
Não possui
Analisa
bilidade
Facilmente detectável,
mesmo que de forma
manual
detectável, porem com o
uso de ferramenta
própria
Não possui ou possui de
forma complexa e pouco
usual
Modificabilidade
Facilmente modificável
(com ajuda de
ferramenta case)
Modificação complexa
N
ão possui
Testabilidade
Facilmente testável
Dificuldade maior
(depende de aprovação)
Não possui
Adaptabilidade
Independente de
ambiente
Com adaptações
Não possui
Capacidade para ser
instalada
Linguagem
independente de
plataforma
Diferentes versões para
plataformas distintas
Não disponível
Capacidade para
substituição
Sem problema, apenas
incorporar novos
conceitos
Alguns conceitos
complexos com a
mudança porém
utilizando a mesma base
da abordagem
Mudanças complexas e
totais no
desenvolvimento
A Tab
ela
2.12
apresenta a comparação entre as abordagens estudadas neste
capítulo. Alguns estudos comparativos entre as abordagens utilizam outros critérios de
avaliação, como o tipo de regra de composição utilizada, por exemplo. Porém utilizamos
os critérios de qualidade das normas ISO/IEC 9126 por ter maior abrangência, de forma a
evidenciar as diferenças e dificuldades entre cada abordagem.
2.Desenvolvimento de Software Orientado a Aspectos 59
T
ABELA
2
.12
–
C
OMPARAÇÃO DAS
A
BORDAGENS
AORE
Abordagem
F
ATORES
Viewpoint
Goals
Use Case
Theme /Doc
A
brangência
fraca
fraca
boa
boa
Adequação
fraca
fraca
regular
regular
Acurácia
fraca.
identificação
dos
pr
o
priedades
s
fraca. refinação
de objetivos
regular
regular
Interoperabilidade
regular.
fraca
fraca
fraca
Funcionalidade
Conformidade
regular
Boa (
i*
com
adap
tações
)
Boa (
UML
com
adaptações
)
regular
Origem
2002
2004
2003
2004
C
onfiabi
-
lidade
Maturidade
regular
regular
boa
boa
Artefatos
Boa (XML)
Boa (V
-
GRAPH
refinados)
Boa (Casos
de Uso)
Boa (Gráfico
Theme
-
Doc )
Apoio Case
Regular
(ARCADE)
Boa
(OPENOME)
fraca
Fraca
(Theme/DOC
Tool)
Inteligibilidade
regular
Boa
regular
regular
Usabilidade
Apreensabilidade
regular
regular
regular
regular
Resolução de Conflitos
boa
boa
regular
regular
Tratamento de Requisitos
organizacionais
fraca
fraca
fraca
fraca
Requisitos funcionais
–
aspectos
fraca
fraca
regular
Boa
Requisitos não funcionais
–
aspectos
Boa
Boa
Boa
Boa
Eficiência
Comportamento em relação aos
recursos
regular
Boa
Boa
regular
Rastreabilidade
boa
boa
boa
boa
Analisabilidade
bo
a
boa
Regular
(sem
ferramenta)
Regular (não
disponível)
Modificabilidade
Boa (com
restrições)
Boa
regular
Boa (com
restrições)
Manutenibilidade
Testabilidade
regular
boa
fraca
regular
Adaptabilidade
boa
Regular
regular
fraca
Capacidade para ser insta
lada
Boa (com
restrições)
Boa
fraca
fraca
Portabilidade
Capacidade para substituição
Boa (se
anterior for
Viewpoint,
senão será
regular)
Boa (se anterior
for Goals
–
senão
será regular)
regular
fraca
2.Desenvolvimento de Software Orientado a Aspectos 60
A
s
t
abela
s
2.13, 2.14, 2.15 e 2.16
apresenta
m
um resumo das cara
cterísticas de
qualidade
, apresentando os principais problemas encontrados. Este resumo foi baseado nas
respostas apresentadas e proporciona uma visão geral da Tabela 2.12.
T
ABELA
2
.13
–
R
ESUMO DA C
O
MPARAÇÃO
–
A
BORDAGEM
V
IEWPOINT
Abordage
m
Viewpoint
Funci
onalidade
:
Fraca
Sua principal dificuldade está na identificação d
a
s
propriedades, onde esta atividade não está definida
objetivamente. Deixando a cargo da “experiência” do
engenheiro de requisitos.
Confiabilidade
:
Fraca
Apesar de ter sua origem na orientação a objetos, esta
abordagem ainda não possui a maturidade necessária para
ser considerada regular. Esta classificação deve
-
se ao fato
de estar particularmente focada em uma universidade e não
ter vasto material de pesquisa disponível.
Usabilidade
regul
ar
Apesar de possuir fases bem objetivas e definidas com seus
artefatos, a primeira fase não é bem definida (sendo a mais
importante). Seus artefatos possuem facilidade de
aprendizado e são bem simples no seu conteúdo, o que
garantiu uma classificação regu
lar.
Eficiência
regular
Apesar de não tratar requisitos organizacionais e não
considerar requisitos funcionais como aspectos, esta
abordagem possui um bom método para tratamento de
conflitos e tratamento para requisitos não funcionais de
forma bem específica, o que garantiu uma classificação
regular
Manutenibilidade
boa
Esta classificação se deve ao fato de que esta abordagem
possui um bom nível de rastreabilidade,
mesmo que
manual
, porém com um pouco mais de trabalho
e uma boa
manutenção (se estiver com a ferramenta).
Portabilidade
B
oa
A substituição para esta abordagem será mais simples se a
abordagem anterior for a OO para Viewpoint, senão será um
pouco mais complicado. Possui ferramenta para auxílio
feita em Java, porem sem possibilidade de download
. O que
dificulta um pouco a avaliação como um todo.
2.Desenvolvimento de Software Orientado a Aspectos 61
T
ABELA
3.14
–
R
ESUMO DA C
O
MPARAÇÃO
–
A
BORDAGEM
GOALS
Abordage
m
GOALS
Funcionalidade
:
Fraca
Sua principal dificuldade está no refinamento sucessivo dos
objetivos e suas operacionalizações, uma vez que
esta
atividade não está definida claramente, d
eixando a cargo da
“experiência” do engenheiro de requisitos.
Confiabilidade
:
Regular
Apesar de ter sua origem na orientação a objetos
com a
modelagem i*
, esta abordagem ainda não possui a
maturidade necessária para ser considerada
boa
. Esta
classificação deve
-
se ao fato de estar sendo utilizada por
algumas faculdades (inclusive em cursos de especialização
– UNIOESTE no Paraná) e ter vasto material de pesquisa
disponível.
Usabilidade
Boa
O método em si é bem simples, pois baseia
-
se no
refinamento sucessivo de objetivos, o que garante a
classificação atual.
Eficiência
regular
Conceitualmente a modelagem i* pode tratar requisitos
organizacionais (em trabalhos adicionais como em
SANTANDER (2002)), porém não especifica este assunto,
tratando apenas das operacionalizações dos requisitos não
funcionais.
Manutenibilidade
Boa
Possui uma boa rastreabilidade (através do refinamento
sucessivo dos objetivos) e uma boa analisabilidade (através
das tarefas que satisfazem os objetivos).
Portabilidade
Boa
A
substituição da visão OO
(i*)
para a visão de aspectos é
bem simples
, pois os conceitos são praticamente os
mesmos
, caso contrario fica mais complexo o processo de
substituição
, porém os conceitos são simples. A fer
ramenta
possui várias versões diferentes e está disponível para
download.
2.Desenvolvimento de Software Orientado a Aspectos 62
T
ABELA
2
.1
5 –
R
ESUMO DA C
O
MPARAÇÃO
–
A
BORDAGEM
USE
CASE
Abordage
m
USE CASE
Funcionalidade
:
Regular
Sua principal dificuldade está na definição dos casos de uso
como um todo,
iniciar o processo de desenvolvimento com
a definição dos casos de uso não é uma tarefa trivial. Suas
fases são completas e complexas, o que garante uma
classificação regular.
Confiabilidade
:
Boa
Uma das únicas abordagens conhecidas que possuem
definição para todas as fases do processo de
desenvolvimento. O que garante uma classificação boa.
Usabilidade
Regular
Mesmo para quem utiliza os casos de uso, são muitos
conceitos novos e complexos, o que garante a classificação
atual.
Eficiência
R
egular
Conceit
ualmente
os casos de uso tratam apenas de
funcionalidades do sistema. Com esta abordagem eles
passam a tratar dos requisitos não funcionais, sem abordar
os requisitos organizacionais..
Manutenibilidade
Regular
Não possuindo uma ferramenta case para auxil
iar o
processo, fica complexo e demanda tempo a tarefa de
manutenção, analisabilidade e rastreamento.
Portabilidade
Regular
A substituição da visão OO para a de aspectos não é
simples, pois abrange vários conceitos novos e complexos,
o que garantiu a classificação regular.
2.Desenvolvimento de Software Orientado a Aspectos 63
T
ABELA
2
.16
–
R
ESUMO DA C
O
MPARAÇÃO
–
A
BORDAGEM
THEME/DOC
Abordage
m
THEME/DOC
Funcionalidade
:
Regular
Sua principal dificuldade está na definição dos themes, pois é uma
tarefa manual, porém o processo de construção dos requi
sitos na
abordagem é bem simples, o que garante a classificação atual.
Confiabilidade
:
Boa
Uma das únicas abordagens conhecidas que possuem definição para
todas as fases do processo de desenvolvimento. O que garante uma
classificação boa.
Usabilidade
Reg
ular
Mesmo sendo uma abordagem completamente diferente e recente,
garante esta classificação por ser bem simples. É fácil de ser
compreendida e de ser usada, apesar da ferramenta case não estar
disponível. É a que mais se aproxima da especificação do LEL
(mesmo que nem cite o mesmo)
Eficiência
Regular
Consegue tratar requisitos funcionais e não funcionais com
simplicidade, apesar de ter regras rígidas para a composição dos
mesmos. A identificação dos aspectos é bem simples e possui
tratamento para a resolução de conflitos.
Manutenibilidade
Regular
Não possuindo uma ferramenta case disponível para download
para
auxiliar o processo fica compl
icado
a tarefa de manutenção,
analisabilidade e rastreamento.
Portabilidade
Fraca
A substituição para esta abordagem não é simples, uma vez que é
completamente diferente das outras e de um padrão já existente em
OO
. Não há informação sobre a ferramenta e sua implementação, o
que dificulta o processo de análise.
T
ABELA
2
.1
7 –
R
ESUMO
G
ERAL
DA C
O
MPARAÇÃO
Abordagem
Fatores
Viewpoint
Goals
Use Case
Theme /Doc
Funcionalidade
Fraca
Fraca.
Regular
Regular.
Confiabilidade
Fraca
Regula
Boa
Boa
Usabilidade
regular
Boa
Regular
Regular
Eficiência
regular
regular
Regular
Regular
Manutenibilidade
boa
Boa
Regular
Regula
r
Portabilidade
Boa
Boa.
Regular
Fraca
2.Desenvolvimento de Software Orientado a Aspectos 64
A Tabela
2.17
demonstra que apesar dos esforços oriundos dos estudos das
abordagens, muitos atributos são frágeis em relação ao que se propõem. Assim, um estudo
mais aprofundado, englobando estudos de caso
em ca
da abordagem
é imprescindível para
avaliar melhor o impacto
de
cada uma
das abordagens
apresentadas
, ficando de sugestão
como
trabalho futuro a ser apresentado.
2
2
.
.
4
4
R
R
e
e
s
s
u
u
m
m
o
o
d
d
o
o
C
C
a
a
p
p
í
í
t
t
u
u
l
l
o
o
Neste capítulo foram
apresentados os principais conceitos do desenvolvi
mento
orientado a aspectos e as principais abordagens apresentadas na Engenharia de Requisitos.
Ao final apresentamos uma comparação entre as abordagens com o intuito de evidenciar
as diferenças (vantagens e desvantagens) entre cada uma.
Esta comparação
é importante a partir d
o
que
será a base para o
desenvolvimento da nova abordagem.
Neste capítulo identificamos que uma das principais dificuldades apresentadas
pelas abordagens está em como identificar
propriedades, propriedades transversais
e, por
conse
qüência, aspectos. De maneira geral, as abordagens
definem estes conceitos, porém
não nos dizem como fazer
e, sabemos que este é o ponto principal
de dificuldade
apresentada na maioria das abordagens e metodologias existentes, o
de
como fazer.
Deste modo,
fica evidente o porquê de tantas pesquisas e abordagens para
tentar minimizar os problemas encontrados.
No próximo capítulo veremos alguns conceitos gerais da MDSODI, do
ambiente DISEN e da ferramenta Requisite.
3.A Metodologia MDSODI e o Ambiente DiSEN 65
C
APÍTULO
3
3
A
M
ETODOGIA
MDSODI
E O
A
MBIENTE D
I
SEN
Eu não consigo entender por que as pessoas têm medo das novas idéias, eu tenho medo das
velhas.
John Cage
D
D
e
e
s
s
d
d
e
e
m
m
e
e
a
a
d
d
o
o
s
s
d
d
a
a
d
d
é
é
c
c
a
a
d
d
a
a
d
d
e
e
7
7
0
0
c
c
o
o
m
m
a
a
A
A
n
n
á
á
l
l
i
i
s
s
e
e
E
E
s
s
t
t
r
r
u
u
t
t
u
u
r
r
a
a
d
d
a
a
,
,
o
o
s
s
d
d
e
e
s
s
e
e
n
n
v
v
o
o
l
l
v
v
e
e
d
d
o
o
r
r
e
e
s
s
t
t
e
e
m
m
s
s
e
e
d
d
e
e
p
p
a
a
r
r
a
a
d
d
o
o
c
c
o
o
m
m
s
s
i
i
s
s
t
t
e
e
m
m
a
a
s
s
c
c
a
a
d
d
a
a
v
v
e
e
z
z
m
m
a
a
i
i
s
s
c
c
o
o
m
m
p
p
l
l
e
e
x
x
o
o
s
s
e
e
d
d
i
i
f
f
í
í
c
c
e
e
i
i
s
s
d
d
e
e
m
m
e
e
n
n
s
s
u
u
r
r
a
a
r
r
e
e
e
e
n
n
t
t
e
e
n
n
d
d
e
e
r
r
d
d
e
e
u
u
m
m
a
a
m
m
a
a
n
n
e
e
i
i
r
r
a
a
m
m
a
a
i
i
s
s
s
s
i
i
m
m
p
p
l
l
e
e
s
s
e
e
c
c
o
o
m
m
p
p
l
l
e
e
t
t
a
a
,
,
d
d
a
a
í
í
t
t
e
e
m
m
s
s
u
u
r
r
g
g
i
i
d
d
o
o
t
t
a
a
n
n
t
t
a
a
s
s
m
m
e
e
t
t
o
o
d
d
o
o
l
l
o
o
g
g
i
i
a
a
s
s
e
e
a
a
b
b
o
o
r
r
d
d
a
a
g
g
e
e
n
n
s
s
d
d
i
i
f
f
e
e
r
r
e
e
n
n
t
t
e
e
s
s
p
p
a
a
r
r
a
a
e
e
s
s
p
p
e
e
c
c
i
i
f
f
i
i
c
c
a
a
ç
ç
ã
ã
o
o
d
d
e
e
s
s
i
i
s
s
t
t
e
e
m
m
a
a
s
s
.
.
P
P
r
r
e
e
s
s
s
s
m
m
a
a
n
n
(
(
2
2
0
0
0
0
5
5
)
)
,
,
m
m
u
u
i
i
t
t
o
o
s
s
a
a
b
b
i
i
a
a
m
m
e
e
n
n
t
t
e
e
,
,
j
j
á
á
d
d
i
i
z
z
i
i
a
a
q
q
u
u
e
e
n
n
ó
ó
s
s
n
n
o
o
s
s
c
c
e
e
r
r
c
c
a
a
m
m
o
o
s
s
d
d
e
e
v
v
á
á
r
r
i
i
a
a
s
s
m
m
e
e
t
t
o
o
d
d
o
o
l
l
o
o
g
g
i
i
a
a
s
s
e
e
e
e
s
s
p
p
e
e
c
c
i
i
f
f
i
i
c
c
a
a
ç
ç
õ
õ
e
e
s
s
a
a
p
p
e
e
n
n
a
a
s
s
p
p
a
a
r
r
a
a
g
g
a
a
r
r
a
a
n
n
t
t
i
i
r
r
q
q
u
u
e
e
e
e
s
s
t
t
a
a
m
m
o
o
s
s
c
c
o
o
m
m
p
p
r
r
e
e
e
e
n
n
d
d
e
e
n
n
d
d
o
o
o
o
q
q
u
u
e
e
e
e
s
s
t
t
a
a
m
m
o
o
s
s
f
f
a
a
z
z
e
e
n
n
d
d
o
o
.
.
A
A
v
v
e
e
r
r
d
d
a
a
d
d
e
e
é
é
q
q
u
u
e
e
c
c
o
o
m
m
o
o
a
a
v
v
a
a
n
n
ç
ç
o
o
d
d
a
a
t
t
e
e
c
c
n
n
o
o
l
l
o
o
g
g
i
i
a
a
,
,
a
a
t
t
e
e
n
n
d
d
ê
ê
n
n
c
c
i
i
a
a
é
é
q
q
u
u
e
e
t
t
e
e
n
n
h
h
a
a
m
m
o
o
s
s
s
s
i
i
s
s
t
t
e
e
m
m
a
a
s
s
c
c
a
a
d
d
a
a
v
v
e
e
z
z
m
m
a
a
i
i
s
s
c
c
o
o
m
m
p
p
l
l
e
e
x
x
o
o
s
s
.
.
P
P
o
o
r
r
t
t
a
a
n
n
t
t
o
o
,
,
o
o
s
s
u
u
r
r
g
g
i
i
m
m
e
e
n
n
t
t
o
o
d
d
e
e
n
n
o
o
v
v
o
o
s
s
m
m
é
é
t
t
o
o
d
d
o
o
s
s
e
e
t
t
é
é
c
c
n
n
i
i
c
c
a
a
s
s
d
d
e
e
d
d
e
e
s
s
e
e
n
n
v
v
o
o
l
l
v
v
i
i
m
m
e
e
n
n
t
t
o
o
s
s
ã
ã
o
o
p
p
l
l
e
e
n
n
a
a
m
m
e
e
n
n
t
t
e
e
c
c
o
o
m
m
p
p
r
r
e
e
e
e
n
n
s
s
í
í
v
v
e
e
i
i
s
s
,
,
t
t
a
a
n
n
t
t
o
o
n
n
o
o
q
q
u
u
e
e
d
d
i
i
z
z
r
r
e
e
s
s
p
p
e
e
i
i
t
t
o
o
à
à
n
n
o
o
s
s
s
s
a
a
c
c
o
o
m
m
p
p
r
r
e
e
e
e
n
n
s
s
ã
ã
o
o
q
q
u
u
a
a
n
n
t
t
o
o
n
n
o
o
q
q
u
u
e
e
d
d
i
i
z
z
r
r
e
e
s
s
p
p
e
e
i
i
t
t
o
o
à
à
t
t
e
e
c
c
n
n
o
o
l
l
o
o
g
g
i
i
a
a
e
e
s
s
e
e
u
u
a
a
v
v
a
a
n
n
ç
ç
o
o
.
.
3.A Metodologia MDSODI e o Ambiente DiSEN 66
N
N
e
e
s
s
t
t
e
e
p
p
o
o
n
n
t
t
o
o
e
e
n
n
t
t
r
r
a
a
a
a
M
M
e
e
t
t
o
o
d
d
o
o
l
l
o
o
g
g
i
i
a
a
d
d
e
e
D
D
e
e
s
s
e
e
n
n
v
v
o
o
l
l
v
v
i
i
m
m
e
e
n
n
t
t
o
o
d
d
e
e
S
S
o
o
f
f
t
t
w
w
a
a
r
r
e
e
o
o
u
u
S
S
i
i
s
s
t
t
e
e
m
m
a
a
s
s
D
D
i
i
s
s
t
t
r
r
i
i
b
b
u
u
í
í
d
d
o
o
s
s
–
–
M
M
D
D
S
S
O
O
D
D
I
I
1
1
(
(
G
G
R
R
A
A
V
V
E
E
N
N
A
A
,
,
2
2
0
0
0
0
0
0
)
)
,
,
q
q
u
u
e
e
l
l
e
e
v
v
a
a
e
e
m
m
c
c
o
o
n
n
s
s
i
i
d
d
e
e
r
r
a
a
ç
ç
ã
ã
o
o
a
a
l
l
g
g
u
u
m
m
a
a
s
s
c
c
a
a
r
r
a
a
c
c
t
t
e
e
r
r
í
í
s
s
t
t
i
i
c
c
a
a
s
s
i
i
d
d
e
e
n
n
t
t
i
i
f
f
i
i
c
c
a
a
d
d
a
a
s
s
e
e
m
m
t
t
a
a
i
i
s
s
s
s
i
i
s
s
t
t
e
e
m
m
a
a
s
s
,
,
c
c
o
o
m
m
o
o
:
:
p
p
a
a
r
r
a
a
l
l
e
e
l
l
i
i
s
s
m
m
o
o
/
/
c
c
o
o
n
n
c
c
o
o
r
r
r
r
ê
ê
n
n
c
c
i
i
a
a
,
,
c
c
o
o
m
m
u
u
n
n
i
i
c
c
a
a
ç
ç
ã
ã
o
o
,
,
s
s
i
i
n
n
c
c
r
r
o
o
n
n
i
i
z
z
a
a
ç
ç
ã
ã
o
o
e
e
d
d
i
i
s
s
t
t
r
r
i
i
b
b
u
u
i
i
ç
ç
ã
ã
o
o
,
,
j
j
á
á
n
n
a
a
s
s
f
f
a
a
s
s
e
e
s
s
i
i
n
n
i
i
c
c
i
i
a
a
i
i
s
s
d
d
o
o
p
p
r
r
o
o
j
j
e
e
t
t
o
o
.
.
E
E
s
s
t
t
e
e
c
c
a
a
p
p
í
í
t
t
u
u
l
l
o
o
t
t
e
e
m
m
p
p
o
o
r
r
o
o
b
b
j
j
e
e
t
t
i
i
v
v
o
o
a
a
p
p
r
r
e
e
s
s
e
e
n
n
t
t
a
a
r
r
e
e
d
d
e
e
s
s
c
c
r
r
e
e
v
v
e
e
r
r
a
a
M
M
D
D
S
S
O
O
D
D
I
I
,
,
a
a
p
p
r
r
e
e
s
s
e
e
n
n
t
t
a
a
r
r
o
o
A
A
m
m
b
b
i
i
e
e
n
n
t
t
e
e
d
d
e
e
D
D
e
e
s
s
e
e
n
n
v
v
o
o
l
l
v
v
i
i
m
m
e
e
n
n
t
t
o
o
d
d
e
e
S
S
o
o
f
f
t
t
w
w
a
a
r
r
e
e
D
D
i
i
s
s
t
t
r
r
i
i
b
b
u
u
í
í
d
d
o
o
–
–
D
D
i
i
S
S
E
E
N
N
(
(
P
P
A
A
S
S
C
C
U
U
T
T
T
T
I
I
,
,
2
2
0
0
0
0
2
2
)
)
e
e
a
a
f
f
e
e
r
r
r
r
a
a
m
m
e
e
n
n
t
t
a
a
R
R
E
E
Q
Q
U
U
I
I
S
S
I
I
T
T
E
E
(
(
B
B
A
A
T
T
I
I
S
S
T
T
A
A
,
,
2
2
0
0
0
0
3
3
)
)
e
e
m
m
s
s
e
e
u
u
e
e
s
s
t
t
a
a
d
d
o
o
a
a
t
t
u
u
a
a
l
l
.
.
3
3
.
.
1
1
A
A
M
M
e
e
t
t
o
o
d
d
o
o
l
l
o
o
g
g
i
i
a
a
M
M
D
D
S
S
O
O
D
D
I
I
A MDSODI é uma metodologia para desenvolvimento
de software distribuído e
foi proposta por G
ravena
(2000). Esta metodologia considera aspectos de
concorrência/paralelismo, comunicação, sincronização e distribuição no seu desenvolvimento
em todas as fases do desenvolvimento de software. Estes aspectos sã
o representados através
da extensão UML (GRAVENA, 2000) (HUZITA, 1999
).
O modelo do ciclo de vida da MDSODI e suas fases podem ser visto na Figura 3.1.
F
IGURA
3
.1
–
C
ICLO DE
V
IDA DO
MDSODI
.
F
ONTE
:
(GRAVENA,
2000)
1
E
E
s
s
t
t
a
a
m
m
e
e
t
t
o
o
d
d
o
o
l
l
o
o
g
g
i
i
a
a
f
f
o
o
i
i
d
d
e
e
s
s
e
e
n
n
v
v
o
o
l
l
v
v
i
i
d
d
a
a
a
a
t
t
r
r
a
a
v
v
é
é
s
s
d
d
e
e
u
u
m
m
p
p
r
r
o
o
j
j
e
e
t
t
o
o
d
d
e
e
p
p
e
e
s
s
q
q
u
u
i
i
s
s
a
a
e
e
m
m
1
1
9
9
9
9
9
9
(
(
H
H
U
U
Z
Z
I
I
T
T
A
A
,
,
1
1
9
9
9
9
9
9
)
)
n
n
o
o
L
L
a
a
b
b
o
o
r
r
a
a
t
t
ó
ó
r
r
i
i
o
o
d
d
e
e
E
E
n
n
g
g
e
e
n
n
h
h
a
a
r
r
i
i
a
a
d
d
e
e
S
S
o
o
f
f
t
t
w
w
a
a
r
r
e
e
(
(
L
L
E
E
S
S
)
)
d
d
o
o
D
D
e
e
p
p
a
a
r
r
t
t
a
a
m
m
e
e
n
n
t
t
o
o
d
d
e
e
I
I
n
n
f
f
o
o
r
r
m
m
á
á
t
t
i
i
c
c
a
a
(
(
D
D
I
I
N
N
)
)
d
d
a
a
U
U
n
n
i
i
v
v
e
e
r
r
s
s
i
i
d
d
a
a
d
d
e
e
E
E
s
s
t
t
a
a
d
d
u
u
a
a
l
l
d
d
e
e
M
M
a
a
r
r
i
i
n
n
g
g
á
á
(
(
U
U
E
E
M
M
)
)
.
.
GERENCIAMENTO
Inc #1
Inc #1
Inc #1
Inc #1
...
Requisitos
Análise
Projeto
Implementação
Teste
3.A Metodologia MDSODI e o Ambiente DiSEN 67
Cada incremen
to é composto das fases de requisitos, análise, projeto,
implementação e teste, conforme observado na Figura
3
.1. Cada fase possui os seguintes
objetivos:
1.
Fase de Requisitos
– Identificar as funcionalidades necessárias para o desenvolvimento
do sistema de
uma forma adequada e eficiente a
partir das necessidades do usuário.
Nesta fase,
devem
-
se
entender os requisitos funcionais e não funcionais e elaborar o
diagrama de casos de uso
considerando os aspectos de paralelismo/concorrência e
distribuição. Os artef
atos produzidos são: modelo de negócio, diagrama de use case e
descrição de requisitos.
2.
Fase
Análise
–
Com base nos requisitos identificados na fase anterior, bem como os
diagramas de casos de uso, definem
-
se as classes e objetos do sistema, identificando
aspectos de concorrência/paralelismo, distribuição e comunicação entre as classes.
Devem
-
se também identificar os aspectos de concorrência/paralelismo e a distribuição
entre pacotes através de descrição textual, quando necessário, e elaborar o diagrama de
pacotes considerando estes aspectos. Nesta fase são produzidos os artefatos: diagramas
de classe, diagrama de colaboração, diagrama de estado, diagrama de pacotes e
descrição arquitetural do modelo de análise.
3.
Fase de Projeto
–
Nesta fase
é
elaborado o dia
grama de classes de projeto, definição de
aspectos da arquitetura do sistema, identificando a alocação dos pacotes nas camadas, e
detalhamento de algoritmos, todos
considerando os aspectos de paralelismo e
distribuição. Nesta fase são produzidos os artefat
os: diagrama de seqüência
(paralelismo, distribuição e comunicação), lista com os requisitos de implementação
(linguagem e ambiente de programação escolhidos), localização física e questões de
concorrência (entre métodos), diagrama de subsistema (considera
ndo sincronização,
paralelismo, distribuição e comunicação), divisão do sistema em camadas, aspectos
arquiteturais do projeto, averiguação de componentes disponíveis para reutilização e
detalhamento dos métodos.
4.
Fase de Implementação
–
esta fase tem como o
bjetivo a construção e implementação do
sistema, tendo como base aspectos identificados nas fases anteriores. Nesta fase devem
ser definidas as interfaces entre os subsistemas
identificad
o
s
na fase de projeto e
detalhar e implementar os métodos das classes
. Os mecanismos de sincronização e os
que tratam do balanceamento de carga entre os nós
do processamento, considerando os
requisitos de distribuição, paralelismo, sincronização e comunicação devem ser tratados.
3.A Metodologia MDSODI e o Ambiente DiSEN 68
5.
Fase de teste –
constitui
-
se em um trabalho a ser desenvolvido (GRAVENA, 2000).
A MDSODI propõe também uma definição de notação para a especificação de
seus elementos nos artefatos
(Casos de uso, atores, classes e objetos, e relacionamentos)
. A
tabela
3.1 ilustra esta especificação adotada.
T
ABELA
3
.1
–
E
SPECIFICAÇÃO DOS ELE
MENTOS UTILIZADOS NA
MDSODI.
F
ONTE
:
(GRAVENA,
2000)
Tipos de Casos de Uso
Casos de Uso
Notação
Casos de Uso Seqüenciais
: agrupam um conjunto de funcionalidades que
devem ser executadas seqüencialmente.
Casos de Uso Paralelos
: agrupam um conjunto de funcionalidades que
devem ser executadas em paralelo.
Casos de Uso Distribuídos: podem estar em diferentes locais do sistema.
Casos de Uso Par
alelos e Distribuídos
: podem estar em diferentes locais
do sistema e devem ser executados em paralelo.
Tipos de Atores
Atores
Notação
Atores Exclusivos
:
atores envolvidos com casos de uso seqüenciais.
Atores Paralelos: atores envolvidos com casos de uso paralelos.
Atores Distribuídos: atores que se encontram localizados em diferentes nós
no sistema.
Atores Paralelos e Distribuídos
: atores que s
ão, ao mesmo tempo,
paralelos e
distribuídos.
Tipos de Classes/Objetos
Classes/Objetos
Notação
Classes e Objetos Exclusivos
: Todos os seus métodos são executados
sequencialmente.
Classes e Objetos Parcialmente Paralelos: alguns métodos sã
o executados
sequencialmente enquanto outros concorrentemente.
3.A Metodologia MDSODI e o Ambiente DiSEN 69
Classes e Objetos Totalmente Paralelos
: todos os métodos são executados
concorrentemente.
Classes e Objetos Distribuídos
: os métodos
podem ser executados em
diferentes nós do sistema.
Tipos de Relacionamentos – poderão ser utilizados também os relacionamentos convencionais
da orientação a objetos como, a agregação e generalização.
Relacionamento
Notação
R
elacionamento entre casos de uso exclusivos
: casos de uso que são
executados sequencialmente (requisitos).
Relacionamento entre casos de uso paralelos
: casos de uso que são
executados concorrentemente com outros casos de uso (requisitos).
Relacionamento entre pacotes exclusivos
: pacotes que são executados
sequencialmente (análise).
Relacionamento entre pacotes parcialmente paralelos
: são pacot
es que
possuem classes executadas de forma concorrente com outras classes de
outro pacote (análise).
Relacionamento entre pacotes totalmente paralelos
: são pacotes que todas
as classes são executadas de forma concorrente com outras classes de outro
pacote (análise).
Relacionamento entre pacotes distribuídos
: são pacotes localizados em
diferentes nós do sistema (análise).
Relacionamento entre
módulos/subsistemas exclusi
vos
:
subsistemas/módulos que são executados sequencialmente (projeto).
Relacionamento entre módulos/subsistemas parcialmente paralelos
:
subsistemas/módulos que tem algumas classes executadas de forma
concorrente com outras classes de outro subsistema (projeto).
Relacionamento entre módulos/subsistemas totalmente paralelos
:
subsistemas/módulos que todas as classes são executadas de forma
concorrente com outras classes de outro subsistema (análise).
Relacionamento entre módulos/subsistemas distribuídos
:
subsistemas/módulos localizados em diferentes nós dentro do sistema
(projeto).
Relacionamento entre objetos exclusivos
: objetos que tem seus
métodos
executados sequencialmente.
Relacionamento entre objetos parcialmente paralelos
: objetos que tem
alguns métodos executados concorrentemente.
Relacionamento entre objetos totalmente paralel
os
: objetos que tem todos
os seus métodos executados concorrentemente.
Relacionamento entre objetos distribuídos
: objetos que se encontram
localizados em diferentes nós do sistema.
3.A Metodologia MDSODI e o Ambiente DiSEN 70
3
3
.
.
2
2
O
O
A
A
m
m
b
b
i
i
e
e
n
n
t
t
e
e
D
D
i
i
S
S
E
E
N
N
P
ascutti
(2002) define o DiSEN como sendo um ambiente distribuído de
desenvolvimento de software, no qual a MDSODI está inserida
. O DiSEN
tem como um de
seus objetivos o de permitir que vários desenvolvedores, atuando em locais distintos, po
ssam
trabalhar de forma cooperativa no desenvolvimento de software, permitindo a interação de
profissionais geograficamente dispersos, resultando em uma melhor
qualidade dos produtos
desenvolvidos.
A arquitetura do DiSEN é baseada em camadas
(ver
f
igura
3.
2
)
onde possui uma
camada dinâmica que é a responsável pelo gerenciamento da configuração e reconfiguração
do ambiente em tempo de execução; uma camada de aplicação que tem como um dos
elementos constituintes o suporte à MDSODI, e a camada da infra
-
estrutu
ra, que provê
suporte às tarefas de persistência, nomeação e concorrência e, além disso, incorpora o canal
de comunicação.
F
IGURA
3
.2
–
O
AMBIENTE
D
I
SEN
E SUA ESTRUTURA EM
CAMADAS
.
F
ONTE
(
PASCUTTI,
2002
).
Abaixo d
o canal de comunicação
, existe uma camada de software básico do
sistema, que irá conter interfaces para hardware específico, sistema operacional, memória
compartilhada e comunicação.
O canal de comunicação é um elemento fundamental desta arq
uitetura,
pois toda a
comunicação entre os elementos constituintes da camada de aplicação e da camada de infra
-
estrutura será realizada através deste canal. É
constituído pelo
middleware
e pelo
middle
-
agent
, sendo que, quando a comunicação envolver soment
e objetos, esta será feita pelo
Supervisor de Configuração Dinâmica
Repositório
Gerenciador
de Objetos
Gerenciado
r
de Workspace
Gerenciador
de Agentes
Canal de Comunicação
Suporte à
Tarefa de
Persistência
Suporte à
Tarefa de
Nomeação
Suporte à
Tarefa de
Concorrência
Camada
dinâmica
Camada de
Aplicação
Camada de
Infra
-
Estrutura
middleware
Middle
-
agent
3.A Metodologia MDSODI e o Ambiente DiSEN 71
middleware
e, quando os agentes estiverem envolvidos, devido
à
s suas propriedades, a
comunicação deverá ser gerenciada pelo
middle
-
agent
.
O
Supervisor de Configuração Dinâmica
é o responsável pelo controle e
gerenciamento da
configuração do ambiente, bem como dos serviços que podem ser
acrescentados ao ambiente em tempo de execução.
O
Gerenciador de Objetos é responsável pelo controle e gerenciamento do ciclo
de vida dos artefatos, que pode ser um diagrama, modelo, manual, có
digo fonte, entre outros.
O Gerenciador de objetos é constituído por gerenciador de acesso, de atividades, de recursos,
de artefatos, de projetos, de processos
e
de versões e configurações.
Por ser de interesse para o REQUISITE
e
,
por conseguinte
,
para o n
osso trabalho,
descreveremos com mais detalhes o gerenciador de recursos. Este é o responsável pelo
controle e gerenciamento de recursos para a execução de uma atividade. Os recursos
necessários para a realização das atividades podem ser materiais (computa
dor, impressora,
sala de reunião) ou ferramentas (programas de computador destinados ao suporte ou
automação de parte do trabalho relacionado a uma atividade). Para o DiSEN, a ferramenta
REQUISITE é considerada como um de seus recursos.
O
Gerenciador de
Workspace
é responsável pelo controle e gerenciamento da
edição cooperativa de documentos e itens de software e também por administrar um conjunto
de
workspaces.
P
ascutti
(2002) define ainda que o gerenciador de
workspace
prove
funcionalidades para criar um
ou mais
workspaces
(isto seria feito através do canal de
comunicação e do suporte à tarefa de persistência, conforme a
f
igura
3
.3). No caso mais
simples consistiria na cópia de um arquivo, porém poderia ser copiada toda uma configuração
do repositório
para
o
workspace
, possibilitando o desenvolvedor ter todos os módulos e
documentos necessários para o funcionamento do sistema a sua disposição localmente.
Uma das principais vantagens é a de que o desenvolvedor está isolado das
alterações das outras pessoas para o repositório, ou seja, possui um controle sobre seu mundo,
sabendo o que foi alterado e por que foi alterado.
Quando o desenvolvedor
de software
termina de efetuar suas modificações, ele
precisa adicionar os módulos e documentos modificados no reposit
ório. Esta operação
consiste
em adicioná
-
las ao repositório (no caso mais simples), usando a funcionalidade do
gerenciador de controle de versão. Entretanto, sabemos que nem sempre será preciso
adicionar todos os arquivos ao repositório, deste modo, o gerenciador de workspaces
deve ser
3.A Metodologia MDSODI e o Ambiente DiSEN 72
capaz de descobrir quais arquivos foram alterados e ter certeza de que somente
estes serão
adicionados.
F
IGURA
3
.3
–
R
EPRESENTAÇÃO DO
G
ERENCIADOR DE
W
ORSPACE
(
PASCUTTI,
2002
)
O
Gerenciador de
Ag
entes
é responsável pel
a criação, registro, localização,
migração e destruição de agentes.
O
Repositório
é responsável pel
o armazenamento dos objetos, versões dos
documentos, produtos de software, dados das aplicações geradas pelo ADS (Ambiente de
Desenvol
vimento de Software), bem como o conhecimento necessário para a
comunicação
entre os agentes.
3
3
.
.
3
3
A
A
F
F
e
e
r
r
r
r
a
a
m
m
e
e
n
n
t
t
a
a
R
R
E
E
Q
Q
U
U
I
I
S
S
I
I
T
T
E
E
A ferramenta REQUISITE fornece suporte à
MDSODI
, no ambiente distribuído de
desenvolvimento DiSEN, na fase de requisitos, consideran
do aspectos de
concorrência/paralelismo, distribuição, sincronização e comunicação. Esta ferramenta auxilia
a concluir com êxito um acordo entre quem solicita e quem desenvolve software,
estabelecendo, clara e rigorosamente o que deverá ser produzido
(
BATI
STA, 2003
)
.
Segundo
B
atista
(2003) um dos pontos positivos da REQUISITE é o uso de
técnicas baseadas em cenários. O conceito de cenários é facilmente compreendido pelos
diversos
stakeholders
2
(
BREITMAN, 2003, 2004
).
Deste modo, auxilia no trabalho de
ente
ndimento, negociação e validação dos requisitos de sistemas.
2
O termo stakeholder é utilizado para identificar qualquer pessoa que tenha interesse pelo sistema
(
ROBERTSON & ROBERTSO
N
, 1999). Também conhecido como clientes potenciais
(SANTANDER, 2002).
Workspace
B
Workspace
C
Workspace
A
Gerenciador
de Worspace
Canal de Comunicação
Repositório
Suporte à tarefa de
persistência
3.A Metodologia MDSODI e o Ambiente DiSEN 73
Elicitação de
Requi
sitos
Gerenciamento
dos Requisitos
Validação dos
Requisitos
Análise e
Negociação dos
Requisitos
Documentação dos
Requisitos
A REQUISITE completa o comportamento do
U
niverso de
I
nformações do
S
istema (UdI), proporcionando um aumento de qualidade e redução no tempo e cus
t
o da
atividade de definição de requisitos.
F
IGURA
3
.4
–
M
ODELO DE
P
ROCESSO UTILIZADO NA
REQUISITE.
F
ONTE
(
BATISTA
,
2003
).
A Figura
3.4
apresenta o modelo de processo utilizado na construção da
ferramenta REQUISITE que é baseado no modelo de processo proposto por K
otonya
&
S
ommerville
apud
B
atista (2003
)
.
A elicitação dos requisitos é a fase inicial do processo, responsável por descobrir
os requisitos do sistema.
As técnicas de modelagem de casos de uso, cenários e
o Léxico
Extendido da Linguagem
-
LEL
(LEITE, 1997)
fornecerão um modelo das info
rmações no
UdI. Nesta etapa, serão identificados os atores, os casos de uso, os cenários e LEL.
Na análise e na negociação dos requisitos são analisados os requisitos a fim de se
detectarem incompletudes, omissões e redundâncias.
A documentação de requisit
os permite descrever as restrições quanto às
características do software, ao processo de desenvolvimento, a interface com outras
aplicações, a descrição sobre o domínio e as informações de suporte ao conhecimento do
problema. Serão produzidos o diagrama de casos de uso, cenário e LEL.
Na fase de validação de requisitos, será certificado se o documento de requisitos é
consistente com as necessidades dos usuários. Descrever os requisitos de forma expl
í
cita é
3.A Metodologia MDSODI e o Ambiente DiSEN 74
uma condição necessária
não somente para validar os
requisitos, mas também para resolver
conflitos entre usuários.
Gerenciar os requisitos diz respeito a poder escrever e acompanhar um requisito ao
longo de todo o processo de desenvolvimento, enquanto esse existir. Isso garante documentos
de requisitos mai
s confiáveis e gerenciáveis, aspectos importantes para a obtenção de
produtos de software de qualidade. Algumas das atividades da gerência de requisitos incluem
rastreamento de requisitos que podem ser executados através da exploração dos modelos,
utilizan
do
-
se, por exemplo, hipertexto.
3
3
.
.
3
3
.
.
1
1
A
A
s
s
p
p
e
e
c
c
t
t
o
o
s
s
F
F
u
u
n
n
c
c
i
i
o
o
n
n
a
a
i
i
s
s
A ferramenta apóia a modelagem de requisitos para a MDSODI, permitindo ao
engenheiro de requisitos criar e editar diagramas de casos de uso, cenários e LEL, bem como
rastrear requisitos. A Figura
3
.5 apresenta o diagrama de casos de uso da ferramenta
REQUISITE.
F
IGURA
3
.5
–
D
IAGRAMA DE CASOS DE USO
DA FERRAMENTA
REQUISITE.
F
ONTE
(
BATISTA
,
2003
).
De acordo com a
f
igura
3
.5 observamos as principais funcionalidades da
ferramenta REQUISITE:
construir hipertexto
construir cenário
<<include>>
salvar modelo
recuperar modelo
construir diagrama use case
construir LEL
<<include>>
explorar modelo
criar ator
Engenheiro de
requisitos
criar use case
3.A Metodologia MDSODI e o Ambiente DiSEN 75
a)
Recup
erar modelo
–
permite ao engenheiro de requisitos recuperar um
modelo localmente
(workspace)
ou no ambiente distribuído;
b)
S
alvar modelo
-
permite ao engenheiro de requisitos salvar
um modelo
localmente
(workspace)
ou no ambiente distribuído
DiSEN;
c)
Cri
ar casos de uso
-
permite ao engenheiro de requisitos adicionar,
modificar, consultar e remover um caso de uso
ao modela. Os casos de uso
previstos
pela
MDSODI
são aqueles descritos na Tabela
3
.1
;
d)
Criar ator
-
permite ao engenheiro de requisitos adicion
ar, modificar,
consultar e remover um ator ao modelo. Os atores previstos pela notação da
MDSODI
são aqueles descritos na Tabela
3
.1
;
e)
E
x
plorar modelo
-
esta funcionalidade permite ao engenheiro de
requisitos rastrear os cenários, entradas do
LEL
,
atores
, casos de uso
e diagramas de
casos de uso
;
f)
C
onstruir
LEL
-
a engenheiro de requisitos, através desta funcionalidade,
poderá criar modificar, remover e consultar uma entrada na
LEL
do modela. A
primeira operação diz respeita à criação. de uma nova entra
da na
LEL
,
isto. é, a
identificação
de um símbolo usada na linguagem da
UdI
.
As operações de modificação e
remoção de uma entrada na
LEL
dizem respeita ao processo de construção do
LEL
que
é continuado;
g)
Construir diagrama de casos de uso
-
permite ao en
genheiro de
requisitos criar, construir
, modificar, consultar ou remover um diagrama de casos de uso
ao
modelo.
Os
relaci
o
nament
o
s
previstos pela notação da
MDSODI
são aqueles descritos
na Tabela
3
.1
.
h
)
C
onstruir cenário
-
esta
funcionalidade
permite ao engenheiro de
requisitos criar, modificar, consultar ou remover um cenário ao modelo.
A primeira operação diz respeito à criação e à introdução de um novo
cenário. De um modo geral, é o resultado
da
fase de elicitação e que acontece com
mais freqüência dura
nte as etapas iniciais do
processo
. Não obstante, novos cenários
podem surgir
em qualquer fase de desenvolvimento, pois lembramos que um sistema de
3.A Metodologia MDSODI e o Ambiente DiSEN 76
software
faz parte de um sistema maior e dessa forma, estará sempre sujeita às
mudanças da ambiente ande est
á inserido.
A operação de modificação pode ser definida c
omo
um processo de
refinamento da informação codificada em um cenário. À medida que
progride
o
desenvolvimento de um sistema, aumenta a compreensão d
o
ambiente
o
nde este será
inserido e de seus requi
sitos. Durante esse process
o
, a informação capturada nas fases
iniciais
vai sendo refinada de modo a refletir, mais precisamente, as necessidades do sistema.
Em conseqüência, o conteúdo dos cenários associados sofre modificações.
A
o
peraçã
o de retirada c
o
nsiste na exclusão de um cenário do modelo.
3
3
.
.
3
3
.
.
2
2
A
A
A
A
r
r
q
q
u
u
i
i
t
t
e
e
t
t
u
u
r
r
a
a
d
d
a
a
R
R
E
E
Q
Q
U
U
I
I
S
S
I
I
T
T
E
E
A arquitetura da ferramenta REQUISITE está apoiada em três camadas: interface,
software base e repositório. Na camada superior temos o software que faz a interface com os
engenh
eiros de requisitos. Através dessa camada, todas as interações com o sistema são
realizadas. Na camada base, temos o software responsável pelo processamento das
informações, ou seja, a lógica da aplicação. Na camada inferior temos o repositório que é o
res
ponsável pelo armazenamento das informações, tais como diagrama
de casos de uso
,
atores, cenários e LEL.
3.A Metodologia MDSODI e o Ambiente DiSEN 77
A arquitetura detalhada da REQUISITE está representada na Figura 3
.6 e as partes
constituintes da ferramenta são descritas a seguir:
F
IGURA
3
.6
–
A
RQUITETURA DETALHADA DA
FERRAMENTA
REQUISITE.
F
ONTE
(
BATISTA
,
2003
)
.
a)
Interface
com o Engenheiro de Requisitos
-
é a responsável pela comunicação entre o
engenheiro de requisitos e a ferramenta, permitindo, com isso, o apoio no processo de
requisitos.
b)
Co
nstrução
Cenários
-
permite as operações de inclusão, modificação e retirada de
um cenário de um modelo.
c) Construção
LEL
-
permite as operações de inclusão, modificação e retirada
de uma
entrada no LEL.
Interface com Engenheiro de Requisitos
Construção
Cenários
Construção
Hipertexto
Construção
LEL
Integração
Casos de
uso/cenários
Suporte a
persistência
de artefatos
Criação
Casos de
uso
Criação
Relacio
-
n
am
ento
Criação
Ator
Explorar Modelo
Construção
Diagrama de
Casos de uso
Suporte a
o
trabalho
cooperativo
Software base
Repositório
3.A Metodologia MDSODI e o Ambiente DiSEN 78
d)
ConstruçãoHipertexto
-
gera elos de hipertexto e
ntre o LEL e os cenários. Gera
também hipertexto entre um termo utilizado no LEL e uma entrada no LEL
(princípio
da circularidade). Esta construção permite a rastreabilidade entre os modelos.
e) Criação
de Caso de Uso
-
permite a adição, a remoção e a modi
ficação de um
caso
de uso
.
f)
Criação Ator
-
permite a adição, a remoção e a modificação de um ator.
g)
Criação
do
Relacionamento
-
permite a adição, a remoção e a modificação de um
relacionamento em um diagrama de casos de uso. Os relacionamentos podem ser entre
casos de uso
ou entre ator e
caso de uso
.
h)
Construção Diagrama de Casos de Uso
-
cria e edita diagramas de use case. Isso
significa criação, a inclusão, a remoção,
a modificação e a manipulação de atores, de
casos de uso
e de relacionamentos no d
iagrama.
i)
Integração de Casos de Uso / Cenário
-
cria, remove e modifica uma ligação entre
um caso de uso e um cenário. Através desta ligação, pode
-
se rastrear o cenário ligado
ao caso de uso.
j)
Explorar Modelo
-
explora o modelo através de uma visão em
forma de
á
rvore
(
TreeExplorer
).
l)
Suporte à Persistência de Artefatos
-
o suporte à persistência de artefatos
pe
rmite
que um engenheiro de requisitos possa
:
armazenar, recuperar e remover
artefatos
de
um repositó
ri
o de forma transparente. O suporte à per
si
s
tência torna
pos
sível
disponibilizar um repositório de
metadados
3
no ambiente distribuído de
des
envolvimento de software DiSEN, considerando requisitos que dizem respeito a
o
acesso
aos dados, disponibilidade, controle de versões, escalabilidade, transpa
rência
de
localização, recuperação de falhas, desempenho, sincronização, atomicidade das
operações e balanceamento de carga entre outros.
m)
Suporte ao Trabalho Cooperativo
-
o suporte ao trabalho cooperativo é
forn
ecido
através de elementos de percepção q
ue capturam e condensam as
informações
3
Metadados são considerados dados
sobre dados. Podemos encontrar referencias a dados e metadados em Souza
(2006).
3.A Metodologia MDSODI e o Ambiente DiSEN 79
coletadas
durante a interação entre os participantes. O suporte ao
trab
alho cooperativo
fornece serviços de colaboração, o que torna possível a
comunica
ção entre os
membros do grupo.
3
3
.
.
3
3
.
.
3
3
E
E
x
x
e
e
m
m
p
p
l
l
o
o
d
d
e
e
I
I
n
n
s
s
t
t
â
â
n
n
c
c
i
i
a
a
s
s
d
d
a
a
R
R
E
E
Q
Q
U
U
I
I
S
S
I
I
T
T
E
E
n
n
o
o
D
D
i
i
S
S
E
E
N
N
A seguir, mostramos, na
f
igura
3.7
, um exemplo do funcionamento da ferramenta
REQUISITE, no ambiente DiSEN.
F
IGURA
3
.7
–
E
SQUEMA DE
I
NSTÂNCIAS DA FERRAME
NTA
REQUISITE.
F
ONTE
(
BATISTA
,
2003
).
No
Workspace
A
, temos o
Engenheiro de Requi
sitos X
, com duas instâncias da
ferramenta
REQUISITE
em execução no DiSEN. No
Workspace
B
, ternos
o
Engenheiro de
Requisitos Y
, com uma instância da fe
rr
amenta REQUISITE em execução no DiSEN. Cada
instância da fe
rr
amenta REQUISITE utiliza um repositório d
e
artefato local no seu
workspace
e pode acessar, quando desejar, artefatos
de
um
rep
ositório de artefato distribuído no DiSEN.
Quando, por exemplo, o
Engenheiro de Requisitos Y
desejar alterar um
artefato
que está no repositório distribuído, no caso mais simples, os serviços de
suporte à persistência
do DiSEN faz
em
uma cópia deste modelo e
o
transfere para o
repositório loca1
.
Após o
Enge
nheiro de Requisitos X
Engenheiro de Requisitos
Y
Workspace A
Workspace
B
Ferramenta
REQUISITE
Ferramenta REQUISITE
Ferramenta
REQUISITE
Interface
Interface
Interface
Lógica aplicação
Lógica aplicação
Lógica aplicação
Repositório local
de artefatos
Repositório local
d
e artefatos
Repositório local
de artefatos
Repositório Distribuído de
Artefatos
Transfere
/atualiza
Transfere
/atualiza
Acessa/
Modifica
Acessa/
Modifica
Acessa/ Modifica
3.A Metodologia MDSODI e o Ambiente DiSEN 80
té
rm
ino de seu trabalho, quando desejar, no caso mais
simples, o
Engenheiro de Requisitos
Y
ativa os serviços de suporte à persistência do DiSEN e este atualiza o modelo no repositório
distribuído.
Desse modo, um grupo de
stakeholders
podem agregar diferentes tipos de
conhecimentos, habilidades e soluções e contribuir para que as atividades, sejam
finalizadas
com um
desempenho
positiv
o.
F
IG
URA
3
.8
–
R
EPRESENTAÇÃO DA
A
RQUITETURA DO
D
I
SEN.
F
ONTE
(
BATISTA
,
2003
).
Na representação d
os elementos da arquitetura do DiSEN, ilustrado na
f
igura
3
.8,
destacamos que, em um
workspace
, na Camada de Aplicação, podem ser
executada
s
várias
apli
cações. Como exemplo, podemos citar: a
própria
ferramenta
REQUISITE, o Distributed
Software
Manager
-
DIMANAGER
(
PEDRAS, 2003
)
e/ou várias instâncias da mesma
aplicação como
m
ostrado acima
n
a
F
igura
3.7.
Camada de Aplicação (ferramentas)
Camada de Gerenciamento de Aplicação (distribuição/coordenação)
Camada de Abstração de Middleware
Middleware
Plataforma (Sistema Operacional, Computadores, Equipamentos de Rede)
Workspace 1
Workspace
N
Aplicações
Aplicações
Gerenciador
de Objetos
Gerenciador
de Agentes
Supervisor de
Configuraçã
o
dinâmica
Repositório
Gerenciador
de
Workspace
Suporte à
persistência
Suporte à
nomeação
Suporte à
transação
Suporte à
Agentes
CORBA
JINI
RMI
3.A Metodologia MDSODI e o Ambiente DiSEN 81
3
3
.
.
4
4
R
R
e
e
s
s
u
u
m
m
o
o
d
d
o
o
C
C
a
a
p
p
í
í
t
t
u
u
l
l
o
o
Este capítulo apresentou a metodologia MDSODI e o ambiente DiSEN, como base
para o desenvolvimento da ferramenta REQUISITE.
Esta ferramenta identifica
propriedades
em um projeto de software, porém, é
importante salientar que
propriedades
é
a principal característica que buscamos
obter ao
desenvolvermos um projeto de software, ou seja, sempre esteve presente em nossos projetos.
Porém
as propriedades transversais eram impossíveis de se mapear com as técnicas existentes
até então
(
CHITCHYAN et al, 2005
)
.
Por
este motivo
, a ferrament
a REQUISITE não está apta a identificar e representar
est
a
s
propriedades transversais (ou aspectos) utilizando a metodologia e a abordagem aplicada
a ela
.
No próximo capítulo
será apresentado
uma nova abordagem para a Engenharia de
requisitos: a DAORE –
Di
stributed
A
spect Oriented Approach
for
Requirements
Engineering
.
4. A Abordagem DAORE 82
C
APÍTULO
4
4
A
ABORDAGEM
DAORE
A melhor forma de prever o futuro é criá
-
lo
.
Peter Drucker
É
É
i
i
n
n
t
t
e
e
r
r
e
e
s
s
s
s
a
a
n
n
t
t
e
e
o
o
b
b
s
s
e
e
r
r
v
v
a
a
r
r
c
c
o
o
m
m
o
o
a
a
s
s
m
m
e
e
l
l
h
h
o
o
r
r
e
e
s
s
i
i
d
d
é
é
i
i
a
a
s
s
s
s
u
u
r
r
g
g
e
e
m
m
d
d
e
e
r
r
e
e
p
p
e
e
n
n
t
t
e
e
,
,
f
f
o
o
i
i
a
a
s
s
s
s
i
i
m
m
c
c
o
o
m
m
a
a
l
l
g
g
u
u
m
m
a
a
s
s
i
i
n
n
v
v
e
e
n
n
ç
ç
õ
õ
e
e
s
s
e
e
o
o
u
u
t
t
r
r
a
a
s
s
f
f
o
o
r
r
a
a
m
m
a
a
t
t
r
r
a
a
v
v
é
é
s
s
d
d
e
e
t
t
e
e
n
n
t
t
a
a
t
t
i
i
v
v
a
a
e
e
e
e
r
r
r
r
o
o
.
.
R
R
e
e
z
z
a
a
a
a
l
l
e
e
n
n
d
d
a
a
q
q
u
u
e
e
T
T
h
h
o
o
m
m
a
a
s
s
A
A
l
l
v
v
a
a
E
E
d
d
s
s
o
o
n
n
,
,
o
o
i
i
n
n
v
v
e
e
n
n
t
t
o
o
r
r
d
d
e
e
v
v
á
á
r
r
i
i
a
a
s
s
c
c
o
o
i
i
s
s
a
a
s
s
,
,
d
d
e
e
n
n
t
t
r
r
e
e
e
e
l
l
a
a
s
s
a
a
l
l
â
â
m
m
p
p
a
a
d
d
a
a
,
,
c
c
e
e
r
r
t
t
a
a
f
f
e
e
i
i
t
t
a
a
r
r
e
e
u
u
n
n
i
i
u
u
s
s
e
e
u
u
s
s
c
c
o
o
l
l
a
a
b
b
o
o
r
r
a
a
d
d
o
o
r
r
e
e
s
s
p
p
a
a
r
r
a
a
u
u
m
m
a
a
f
f
e
e
s
s
t
t
a
a
.
.
A
A
o
o
c
c
h
h
e
e
g
g
a
a
r
r
e
e
m
m
,
,
e
e
s
s
e
e
m
m
s
s
a
a
b
b
e
e
r
r
e
e
m
m
q
q
u
u
a
a
l
l
a
a
r
r
a
a
z
z
ã
ã
o
o
d
d
a
a
c
c
o
o
m
m
e
e
m
m
o
o
r
r
a
a
ç
ç
ã
ã
o
o
,
,
p
p
e
e
r
r
g
g
u
u
n
n
t
t
a
a
r
r
a
a
m
m
a
a
e
e
l
l
e
e
q
q
u
u
e
e
m
m
o
o
t
t
i
i
v
v
o
o
s
s
t
t
i
i
n
n
h
h
a
a
p
p
a
a
r
r
a
a
f
f
a
a
z
z
e
e
r
r
u
u
m
m
a
a
c
c
o
o
m
m
e
e
m
m
o
o
r
r
a
a
ç
ç
ã
ã
o
o
,
,
a
a
o
o
q
q
u
u
e
e
E
E
d
d
s
s
o
o
n
n
r
r
e
e
s
s
p
p
o
o
n
n
d
d
e
e
u
u
:
:
"
"
c
c
o
o
m
m
e
e
m
m
o
o
r
r
o
o
o
o
d
d
é
é
c
c
i
i
m
m
o
o
m
m
i
i
l
l
é
é
s
s
i
i
m
m
o
o
f
f
r
r
a
a
c
c
a
a
s
s
s
s
o
o
n
n
a
a
m
m
i
i
n
n
h
h
a
a
t
t
e
e
n
n
t
t
a
a
t
t
i
i
v
v
a
a
d
d
e
e
i
i
n
n
v
v
e
e
n
n
t
t
a
a
r
r
a
a
l
l
â
â
m
m
p
p
a
a
d
d
a
a
"
"
.
.
“
“
C
C
o
o
m
m
o
o
a
a
s
s
s
s
i
i
m
m
?
?
”
”
P
P
e
e
r
r
g
g
u
u
n
n
t
t
a
a
r
r
a
a
m
m
o
o
s
s
p
p
r
r
e
e
s
s
e
e
n
n
t
t
e
e
s
s
.
.
“
“
C
C
o
o
m
m
o
o
p
p
o
o
d
d
e
e
a
a
l
l
g
g
u
u
é
é
m
m
c
c
o
o
m
m
e
e
m
m
o
o
r
r
a
a
r
r
d
d
e
e
z
z
m
m
i
i
l
l
f
f
r
r
a
a
c
c
a
a
s
s
s
s
o
o
s
s
?
?
”
”
“
“
S
S
i
i
m
m
p
p
l
l
e
e
s
s
,
,
m
m
e
e
u
u
s
s
c
c
a
a
r
r
o
o
s
s
”
”
,
,
r
r
e
e
s
s
p
p
o
o
n
n
d
d
e
e
u
u
E
E
d
d
s
s
o
o
n
n
:
:
"
"
S
S
o
o
u
u
a
a
ú
ú
n
n
i
i
c
c
a
a
p
p
e
e
s
s
s
s
o
o
a
a
n
n
o
o
m
m
u
u
n
n
d
d
o
o
q
q
u
u
e
e
c
c
o
o
n
n
h
h
e
e
c
c
e
e
d
d
e
e
z
z
m
m
i
i
l
l
m
m
a
a
n
n
e
e
i
i
r
r
a
a
s
s
d
d
i
i
f
f
e
e
r
r
e
e
n
n
t
t
e
e
s
s
d
d
e
e
c
c
o
o
m
m
o
o
n
n
ã
ã
o
o
f
f
a
a
z
z
e
e
r
r
u
u
m
m
a
a
l
l
â
â
m
m
p
p
a
a
d
d
a
a
!
!
I
I
s
s
s
s
o
o
m
m
e
e
r
r
e
e
c
c
e
e
u
u
m
m
a
a
c
c
o
o
m
m
e
e
m
m
o
o
r
r
a
a
ç
ç
ã
ã
o
o
!
!
"
"
.
.
N
N
a
a
d
d
é
é
c
c
i
i
m
m
a
a
m
m
i
i
l
l
é
é
s
s
i
i
m
m
a
a
p
p
r
r
i
i
m
m
e
e
i
i
r
r
a
a
t
t
e
e
n
n
t
t
a
a
t
t
i
i
v
v
a
a
e
e
l
l
e
e
i
i
n
n
v
v
e
e
n
n
t
t
o
o
u
u
a
a
l
l
â
â
m
m
p
p
a
a
d
d
a
a
!
!
4. A Abordagem DAORE 83
A
A
n
n
a
a
l
l
o
o
g
g
a
a
m
m
e
e
n
n
t
t
e
e
a
a
o
o
d
d
e
e
s
s
e
e
n
n
v
v
o
o
l
l
v
v
i
i
m
m
e
e
n
n
t
t
o
o
d
d
e
e
s
s
i
i
s
s
t
t
e
e
m
m
a
a
s
s
,
,
t
t
e
e
m
m
o
o
s
s
p
p
r
r
o
o
c
c
u
u
r
r
a
a
d
d
o
o
o
o
b
b
s
s
e
e
r
r
v
v
a
a
r
r
o
o
u
u
t
t
r
r
a
a
s
s
c
c
i
i
ê
ê
n
n
c
c
i
i
a
a
s
s
e
e
t
t
r
r
a
a
z
z
e
e
r
r
a
a
l
l
g
g
u
u
n
n
s
s
c
c
o
o
n
n
c
c
e
e
i
i
t
t
o
o
s
s
p
p
a
a
r
r
a
a
,
,
n
n
o
o
m
m
í
í
n
n
i
i
m
m
o
o
,
,
f
f
a
a
c
c
i
i
l
l
i
i
t
t
a
a
r
r
n
n
o
o
s
s
s
s
a
a
c
c
o
o
m
m
p
p
r
r
e
e
e
e
n
n
s
s
ã
ã
o
o
s
s
o
o
b
b
r
r
e
e
o
o
p
p
r
r
o
o
b
b
l
l
e
e
m
m
a
a
e
e
f
f
o
o
r
r
m
m
u
u
l
l
a
a
r
r
s
s
o
o
l
l
u
u
ç
ç
õ
õ
e
e
s
s
.
.
P
P
o
o
r
r
é
é
m
m
,
,
s
s
a
a
b
b
e
e
m
m
o
o
s
s
q
q
u
u
e
e
u
u
m
m
m
m
e
e
s
s
m
m
o
o
s
s
i
i
s
s
t
t
e
e
m
m
a
a
d
d
e
e
s
s
o
o
f
f
t
t
w
w
a
a
r
r
e
e
p
p
a
a
r
r
a
a
e
e
m
m
p
p
r
r
e
e
s
s
a
a
s
s
d
d
i
i
f
f
e
e
r
r
e
e
n
n
t
t
e
e
s
s
r
r
e
e
q
q
u
u
e
e
r
r
p
p
e
e
q
q
u
u
e
e
n
n
a
a
s
s
m
m
o
o
d
d
i
i
f
f
i
i
c
c
a
a
ç
ç
õ
õ
e
e
s
s
(
(
n
n
o
o
s
s
c
c
a
a
s
s
o
o
s
s
m
m
a
a
i
i
s
s
s
s
i
i
m
m
p
p
l
l
e
e
s
s
)
)
e
e
,
,
à
à
s
s
v
v
e
e
z
z
e
e
s
s
,
,
g
g
r
r
a
a
n
n
d
d
e
e
s
s
m
m
u
u
d
d
a
a
n
n
ç
ç
a
a
s
s
.
.
D
D
e
e
s
s
t
t
e
e
m
m
o
o
d
d
o
o
,
,
o
o
d
d
e
e
s
s
e
e
n
n
v
v
o
o
l
l
v
v
i
i
m
m
e
e
n
n
t
t
o
o
d
d
e
e
s
s
i
i
s
s
t
t
e
e
m
m
a
a
s
s
d
d
e
e
s
s
o
o
f
f
t
t
w
w
a
a
r
r
e
e
,
,
m
m
a
a
i
i
s
s
p
p
a
a
r
r
t
t
i
i
c
c
u
u
l
l
a
a
r
r
m
m
e
e
n
n
t
t
e
e
o
o
q
q
u
u
e
e
c
c
h
h
a
a
m
m
a
a
m
m
o
o
s
s
d
d
e
e
E
E
n
n
g
g
e
e
n
n
h
h
a
a
r
r
i
i
a
a
d
d
e
e
R
R
e
e
q
q
u
u
i
i
s
s
i
i
t
t
o
o
s
s
c
c
o
o
m
m
p
p
r
r
e
e
e
e
n
n
d
d
e
e
u
u
m
m
a
a
d
d
a
a
s
s
m
m
a
a
i
i
s
s
c
c
o
o
m
m
p
p
l
l
e
e
x
x
a
a
s
s
a
a
t
t
i
i
v
v
i
i
d
d
a
a
d
d
e
e
s
s
d
d
a
a
E
E
n
n
g
g
e
e
n
n
h
h
a
a
r
r
i
i
a
a
d
d
e
e
S
S
o
o
f
f
t
t
w
w
a
a
r
r
e
e
.
.
D
D
u
u
r
r
a
a
n
n
t
t
e
e
o
o
p
p
r
r
o
o
c
c
e
e
s
s
s
s
o
o
f
f
o
o
r
r
a
a
m
m
p
p
e
e
s
s
q
q
u
u
i
i
s
s
a
a
d
d
a
a
s
s
e
e
u
u
t
t
i
i
l
l
i
i
z
z
a
a
d
d
a
a
s
s
v
v
á
á
r
r
i
i
a
a
s
s
s
s
o
o
l
l
u
u
ç
ç
õ
õ
e
e
s
s
,
,
p
p
o
o
r
r
é
é
m
m
s
s
e
e
m
m
p
p
r
r
e
e
h
h
a
a
v
v
e
e
r
r
á
á
o
o
a
a
p
p
e
e
r
r
f
f
e
e
i
i
ç
ç
o
o
a
a
m
m
e
e
n
n
t
t
o
o
d
d
e
e
m
m
é
é
t
t
o
o
d
d
o
o
s
s
,
,
b
b
u
u
s
s
c
c
a
a
n
n
d
d
o
o
u
u
m
m
a
a
m
m
e
e
l
l
h
h
o
o
r
r
i
i
a
a
c
c
o
o
n
n
t
t
í
í
n
n
u
u
a
a
.
.
A
A
a
a
b
b
o
o
r
r
d
d
a
a
g
g
e
e
m
m
p
p
r
r
o
o
p
p
o
o
s
s
t
t
a
a
a
a
s
s
e
e
g
g
u
u
i
i
r
r
b
b
u
u
s
s
c
c
a
a
e
e
x
x
a
a
t
t
a
a
m
m
e
e
n
n
t
t
e
e
i
i
s
s
s
s
o
o
:
:
u
u
m
m
a
a
s
s
o
o
l
l
u
u
ç
ç
ã
ã
o
o
p
p
a
a
r
r
a
a
a
a
l
l
g
g
u
u
n
n
s
s
p
p
r
r
o
o
b
b
l
l
e
e
m
m
a
a
s
s
(
(
d
d
e
e
n
n
t
t
r
r
e
e
o
o
s
s
m
m
u
u
i
i
t
t
o
o
s
s
)
)
d
d
a
a
á
á
r
r
e
e
a
a
d
d
e
e
E
E
n
n
g
g
e
e
n
n
h
h
a
a
r
r
i
i
a
a
d
d
e
e
R
R
e
e
q
q
u
u
i
i
s
s
i
i
t
t
o
o
s
s
O
O
r
r
i
i
e
e
n
n
t
t
a
a
d
d
a
a
a
a
A
A
s
s
p
p
e
e
c
c
t
t
o
o
s
s
.
.
4
4
.
.
1
1
O
O
b
b
j
j
e
e
t
t
i
i
v
v
o
o
s
s
e
e
D
D
i
i
r
r
e
e
t
t
r
r
i
i
z
z
e
e
s
s
P
P
r
r
i
i
n
n
c
c
i
i
p
p
a
a
i
i
s
s
A Abordagem
D
AO
RE
–
Distributed
Aspect Oriented
A
pproach for
R
equirements
E
ngineering
,
tem como principal objetivo facilitar a identificação de
aspectos candidatos
nas fases iniciais do processo de desenvolvimento de sis
temas. Para
isso, se utiliza de conceitos e ferramentas gráficas de algumas abordagens existentes (as
estudadas no Capítulo
2
)
, além de propor um novo modelo de processo.
A tabela 4.1 apresenta os conceitos e ferramentas utilizadas das abordagens
anterior
es na abordagem
DAORE
.
4. A Abordagem DAORE 84
T
ABELA
4.1
–
.
C
ONCEITOS E ARTEFATOS
USADOS NA
DAORE
Abordagens AORE Estudadas
Características
Viewpoint
Goals
Use Case
Theme/Doc
Relacionamento
entre aspectos e
re
q
uisitos
funcionais
Adaptado
para
requisitos
não
funcionais e
fu
ncionais
Operacionalizações
de requisitos não
funcionais
Adaptado para
estratégias de
satis
f
ação.
Utiliza
-
se este
conceito
também nos
requisitos
organizacionais
.
Identificação dos
aspectos
Adaptado de
Clarke&Baniassad
(2005)
Composição dos
aspe
ctos
Utiliza
-
se o
modelo
proposto por
Souza
(2004)
Resolução de
conflitos nos
aspectos
Utiliza
-
se o
modelo
proposto por
Souza
(2004)
No cap
í
tulo
2 foi feita uma comparação entre estas abordagens e partindo desta
premissa definimos algumas diretriz
es que a
DAORE
deve possuir:
·
A
-
Suporte a metodologia MDSODI
na definição
dos cenários e
d
a
s
propriedades transversais
–
pois esta metodologia é a utilizada pelo ambiente
DISEN e pela ferramenta REQUISITE
, por este motivo a abordagem recebeu
em sua defini
ção o nome de
Distributed
;
o
Para tornar esta correlação mais clara nos projetos foi identificado nos
cenários o seu tipo de acordo com a proposta da MDSODI
; e
o
Esta identificação facilita a forma de tratamento dos cenários nas fases
seguintes ao desenvolvime
nto.
·
B -
Permitir um alto grau de usabilidade (de acordo com o conceito introduzido
pela Tabela 3.9 do Capítulo 3);
4. A Abordagem DAORE 85
·
C
-
Boa adequação quanto à identificação de propriedades transversais
;
·
D
-
Facilitar a identificação de
propriedades transversais
não
-
funcio
nais
,
derivados de requisitos não funcionais, a partir do trabalho do Cysneiros (2001
)
e da
s normas ISO/IEC 9126;
·
E
-
Identificar e mo
delar requisitos organizacionais
,
através de suas
operacionalizações (quando pertinentes ao domínio
)
;
·
F
-
Aumentar a apree
nsabilidade através da identificação d
a
s
propriedades
transversais
;
·
G
–
Especificar XML Schema
s
1
para
auxiliar na
exportação de documento
s
padrão
no formato
XML
(
símbolos do LEL, cenários, aspectos e ontologias
)
, a
fim de aumentar a interoperabilidade entr
e ferramentas utilizadas pela
MDSODI;
·
H
-
Facilitar a resolução de conflitos manualmente através de padrões de
domínio pré
-
estabelecidos
–
reuso de especificações
e ontologias
2
de requisitos
utilizando o LEL
, e
·
I
–
Facilitar o
rastreamento de requisitos
a
través do principio de circularidade
(utilizado no LEL) e vocabulário mínimo
.
A
Tabela
4.
2
apresenta a
relação
das diretrizes em relação
às
características de
qualidade apresentadas na Tabela 2.8
e
2.9 do Capítulo 2.
O seu preenchimento está de acordo com
as definições apresentadas
anteriormente. Assim foi feito
à
atribuição das diretrizes onde
elas melhor se
aproximavam
da definição.
1
Alguns XML Schemas estão especificados pela W3C em
www.w3c.org
, porém não há e
specificação para
requisitos e o LEL.
2
Alguns conceitos de ontologias podem ser encontrados em Breitman (2005).
4. A Abordagem DAORE 86
T
ABELA
4.
2 –
.
R
ELAÇÃO ENTRE
D
IRETRIZES DA
DAORE
E AS
C
ARACTERÍSTICAS DE
Q
UALIDADE
Característica
Sub
-
caracter
í
stica
Diret
riz
Abrangência
A
Adequação
C
Acurácia
D, G
Interoperabilidade
G
Funcionalidade
Conformidade
D, G, H
Confiabilidade
Maturidade
F
Artefatos
A
, D,G
Apoio Case
A
, B,C,D e G
Inteligibilidade
A, B, D, E, H
Usabilidade
Apreensibilidade
F
Resolução de Conflitos
H
Tratamento de Requisitos
Organizacionais
E
Requisitos funcionais –
aspectos
F
Efici
ência
Requisitos não funcionais –
aspectos
D, F
Rastreabilidade
I
Analisabilidade
H
Modificabilidade
I
Manutenibilidade
Testabilidade
A
Adaptabilidade
G
Capacidade para ser instalada
G
P
ortabilidade
Capacidade para substituir
A
Como podemos observar na tabela 4.2, no
s
ite
ns:
·
Abrangência
:
foi atribuíd
a
a diretriz A, pois como a abordagem deve
apoiar a MDSODI na fase de requisitos.
·
Ad
equação
:
foi atribuíd
a
a diretriz C, pois deve possuir boa adequação
quanto a identificação e composição de propriedades transversais.
·
Acurácia
:
foram atribuídas
a
s
diretriz
es
D e G, pois deve
facilitar a
identificação de propriedades e dos requisitos não
funcionais através de
ontologias sugeridas por Cysneiros (2001), além de definir padrões
para permitir a importação de documentos.
·
Interoperabilidade
:
foi atribuíd
a
a diretriz G, pois deve possuir
a
capacidade de interagir com ferramentas diferentes atra
vés da
importação de documentos seguindo uma padronização.
4. A Abordagem DAORE 87
·
Conformidade
:
foram atribuídas as diretrizes
D,G e H, pois
a
conformidade diz respeito a padrões e, sendo assim, deve estar de
acordo com o estabelecido.
·
Maturidade
:
foi atribuíd
a
a diretriz F, poi
s
o aprendizado através do
auxilio da identificação de propriedades proporcionada pela abordagem
permite o aumento de maturidade uma vez que pode ser feito de forma
semi
-
automática.
·
Artefatos
:
foram atribuídas as diretrizes
A
,D e G
, pois
contém os
artefato
s previstos para a definição do LEL, além de ontologias de
requisitos não funcionais e de documentos XML.
·
Apoio Case
:
foram atribuídas as diretrizes
A
,B,C,D e G
, pois deve
oferecer suporte a metodologia MDSODI na construção dos cenários,
na especificação d
os
propriedades transversais
, nos requisitos não
funcionais, na utilização da abordagem e na confecção de documentos
XML.
·
I
nteligibilidade
:
foram atribuídas as diretrizes
A,B,D,E e H
, pois
os
conceitos e definições da abordagem serão mais consistentes e ma
is
fáceis de compreender se for feito de forma semi
-
automática (de
preferência de forma automática), assim está ligada ao item anterior
também.
·
Apreensibilidade
:
foi atribuída
a diretriz
F
, pois
o objetivo principal da
abordagem está na facilidade de ident
ificação dos
propriedades
transversais, porém podemos atribuir o item anterior também.
·
Resolução de Conflitos
:
foi atribuída a
diretriz
H
. Infelizmente a
resolução de conflitos deve ser realizada de forma manual, mas
podemos identificar os conflitos de for
ma automática.
·
Tratamento de Requisitos Organizacionais
:
foi atribuída
a diretriz
E
,
pois deve
permitir a integração dos requisitos organizacionais com os
requisitos funcionais através de suas operacionalizações.
4. A Abordagem DAORE 88
·
Requisitos funcionais –
aspectos
:
foi atrib
uída
a diretriz F, pois deve
possuir
diretrizes para nortear a identificação dos requisitos funcionais
como
propriedades transversais.
·
Requisitos não funcionais –
aspectos
:
foram atribuídas as diretrizes
D e
F
, pois deve possuir
diretrizes para nortear a i
dentificação dos
requisitos não funcionais como propriedades transversais.
·
Rastreabilidade
:
foi atribuída
a diretriz
I
, pois
através do principio de
circularidade do LEL podemos realizar o rastreamento de requisitos.
·
Analisabilidade
:
foi atribuída
a diretr
iz H
, pois
através da resolução de
conflitos podemos identificar possíveis “falhas” na composição d
a
s
propriedades transversais.
·
Modificabilidade
:
foi atribuída
a diretriz
I
, pois
através do
rastreamento permitido pelo principio de circularidade do LEL
podemos identificar e atualizar mais rapidamente as informações, bem
como analisar e detectar possíveis erros.
·
Testabilidade
:
foi
atribuída a diretriz
A
, pois deve
estar de acordo com
a MDSODI na definição dos cenários a fim de permitir
o seu uso.
Podemos também identificar uma forte ligação com o Apoio Case para
o cumprimento desta característica.
·
Adaptabilidade
:
foi atribuíd
a
a diretriz
G
. A adaptabilidade diz respeito
a instalação, mas como estamos lidando com abordagem podemos
dizer que esta deve ser capaz
de se adaptar a novos ambientes com o
mínimo de esforço. Este princ
í
pio pode ser
satisfeito
com a exportação
de documentos em XML.
·
Capacidade para ser instalada
:
foi atribuíd
a
a diretriz
G
, pois
pode ser
exportado o documento XML para ser importado em outro ambiente.
·
Capacidade para substituir
:
foi atribuíd
a
a diretriz
A
, pois deve
possuir integração com a MDSODI com o mínimo esforço na mudança
ocorrida.
4. A Abordagem DAORE 89
4
4
.
.
2
2
O
O
P
P
r
r
o
o
c
c
e
e
s
s
s
s
o
o
d
d
e
e
D
D
e
e
s
s
e
e
n
n
v
v
o
o
l
l
v
v
i
i
m
m
e
e
n
n
t
t
o
o
P
P
r
r
o
o
p
p
o
o
s
s
t
t
o
o
A
DAORE
possui o modelo de processo de desenvolvimento basea
do na Figura
4.1. Este modelo de processo procura seguir o modelo geral da Engenharia de Requisitos
proposto por
(K
OTONYA
et al
apud
SANTANDER
,
2002), porém com algumas
adaptações
para incorporar os trabalhos de C
ysneiros
(200
1
) e B
reitman
(2003
,
2005),
al
ém de incorporar
a
definição de aspectos candidatos
para abranger as diretrizes
propostas anteriormente.
F
IGURA
4.1
–
.
M
ODELO DE
P
ROCESSO DA
A
BORDAGEM
DAORE
De modo geral a
s fases de desenvolvimento do processo
especificadas na
figura 4.1
estão descritas
como se segue
:
Fase 1
-
Construção de Requisitos
–
deve
-
se seguir a construção dos requisitos
funcionais, não funcionais e organizacionais
;
Fase 2
-
Constru
ção d
o LEL
–
deve
-
se seguir a construção dos
termos do LEL
e dos cenários elicitados
;
Fase 3
–
Defi
nição dos Aspectos Candidatos
– deve
-
se
definir os aspectos
candidatos baseados em algumas diretrizes propostas
;
e
Fase 4
–
Mapeamento de Ontologias
–
deve
-
se
realizar o mapeamento de
ontologias seguindo um padrão proposto por Bre
i
tman (2005).
As fases 3 e
4 independem uma da outra, podendo ser construídas em
paralelo.A seguir
descreveremos o processo de construção de cada fase.
Construção
de Requisitos
Construção do LEL
Definição de Aspectos
Candidatos
Mapeamento de Ontologias
4. A Abordagem DAORE 90
Levantamento
dos requisitos
Utilização de
técnicas
tradicionais
Análise e Negociação
Lista
Requisitos
iniciais
Lista
Requisitos
Refinados
Refinamento dos
Requisitos e
Entendimento do
Problema
Requisitos
do Sistema
Está
satisfeito
Validação
com
cliente
4
4
.
.
2
2
.
.
1
1
F
F
a
a
s
s
e
e
1
1
–
–
C
C
o
o
n
n
s
s
t
t
r
r
u
u
ç
ç
ã
ã
o
o
d
d
e
e
R
R
e
e
q
q
u
u
i
i
s
s
i
i
t
t
o
o
s
s
De um modo geral na construção dos requisitos devemos
identifica
r
os
re
quisitos organiz
acionais (dizem respeito a metas da empresa, suas políticas estratégicas
adotadas, os relacionamentos entre os seus atores junto com seus respectivos objetivos),
requisitos funcionais (definem a funcionalidade do sistema)
e
requisitos não funcionais
(dizem
respeito a questões de qualidade e segurança, de maneira geral).
4.2.1.1
-
Levantamento dos
R
equisitos
A construção de requisitos segue
o modelo proposto por Kotonya et al apud
Santander (2002),
figura 4.
2.
F
IGURA
4.
2 – P
ROCESSO
G
ERAL DE CONSTRUÇÃO D
E
R
EQUISITOS
Podemos observar que o processo geral de construção de requisitos (figura 4.2
)
inicia
-
se com o levantamento dos mesmos através de técnicas tradicionais como
entrevistas,
cenários (H
ADAD
et al. 1999) (
HAUMER
et al. 1998) (
LEITE
et al. 1997)
(
BREI
TMAN
et al. 1998); observação e análise social (
GOGUEN
et al. 1993); etnografia
(
SOMMERVILLE et al. 1999); entre outras. Toda técnica de elicitação deve descrever os
requisitos através de uma representação facilmente entendida por todos os s
takeholders
(SA
NTANDER, 2002).
4. A Abordagem DAORE 91
A
pós a elicitação dos requisitos eles
devem ser analisados para detectar
incompletudes, omissões ou redundâncias. Na análise, a preocupação está em
descobrir
os
requisitos que realmente são necessários e que o
stakeholder
deseja. Santander
(2002)
descreve ainda algumas técnicas utilizadas para realizar análise dos requisitos.
Santander (2002) define a negociação dos requisitos como sendo
uma atividade
que visa solucionar problemas advindos de conflitos entre os diversos
stakeholders
, os
quai
s podem atribuir diferentes prioridades aos requisitos. A negociação consiste em que
todos os
stakeholders
entrem em consenso em relação a um conjunto de requisitos
definidos, bem como em relação às prioridades definidas para os mesmos.
A atividade de vali
dação de requisitos é a última atividade para certificar
-
se
que o documento final de requisitos satisfaz em todos os aspectos o que o usuário deseja
do sistema. Santander (2002) descreve técnicas de validação onde são refinados os
requisitos até que tenham
os uma
lista dos requisitos acordados.
Em nosso trabalho exploraremos um pouco mais os conceitos referentes aos
requisitos não funcionais e organizacionais, uma vez que os requisitos funcionais são mais
simples de serem
identificados, mesmo porque,
é
a raz
ão de existência do projeto a ser
desenvolvido.
4.2.1.2
-
Construção de Requisitos Funcionais
Os
requisitos funcionais dizem respeito à definição das funções que um sistema
ou um componente de sistema deve fazer. Eles descrevem as transformações a serem
re
alizadas nas entradas de um sistema ou em um de seus componentes, a fim de que se
produzam saídas (SANTANDER, 2002).
A identificação dos requisitos funcionais
pode ser
realizada seguindo técnicas
existentes para a elicitação de requisitos: entrevistas, cen
ários
(LEITE et al., 1997)
(HADAD et al.
,
1999) (HAUMER et al
., 1998
)
(BREITMAN
& LEITE, 1998),
observação e análise social, entre outras.
Neste trabalho segue a técnica de cenários
proposto por (LEITE et al., 1997).
4.2.1.3
-
Construção de Requisitos
não
-
Funcionais
A identificação de requisitos não funcionais diz respeito, geralmente, a
questões de qualidade e segurança. A sua identificação pode ser realizada tendo por base
as características de qualidade do software, definidos
por meio da
ISO/IEC 9126
(IS
O,
4. A Abordagem DAORE 92
2006)
. Assim podemos definir para nossos projetos, baseados no domínio da aplicação,
características afins e sub
-
características, perfazendo um banco de ontologias de domínio
para requisitos não funcionais.
A autora deste trabalho acredita
que, por exe
mplo,
se definirmos inicialmente
um conjunto de requisitos não funcionais baseados em um domínio de uma aplicação
médica, é bem provável que
sejam
utiliza
dos
em um
a
outr
a
aplicação de um mesmo
domínio.
Assim, o trabalho do Engenheiro de Requisitos pode se
r apoiado por este
poderoso aliado na elucidação de requisitos não funcionais.
Algumas classificações dos RNFs podem ser encontradas na literatura:
(
MAMANI, 19
99), (
SOMMERVILLE
, 92)
e (
CYSNEIROS
, 2001
). Neste trabalho iremos
utilizar a classificação do Cys
neiros, por se utilizar do Chung (2000) e das normas
ISO/IEC 9126, para construção de nosso banco de requisitos não funcionais.
Um fator muito importante na elicitação dos requisitos não funcionais é que
são geralmente muito abrangentes, como nos trabalho
s das abordagens anteriores, como
(BRITO & MOREIRA, 2003) (JACOBSON
& NG, 200
5
) (RASHID et al
.
, 2002)
(ARAUJO et al
.
, 2002). Assim, a classificação proposta por Cysneiros
elaborando a
decomposição dos RNF em operacionalizações resulta em um trabalho mais
minucioso
.
Cysneiros (200
1
) propõe uma taxonomia que classifica os RNFs em primários
e específicos
(ver figura 4.
3
)
. RNFs primários são aqueles mais abstratos que representam
propriedades como: Confiabilidade, Rastreabilidade, Precisão, Segurança. Já os RN
Fs
específicos são decomposições que se seguem aos RNFs primários e tendem a diminuir o
nível de abstração de um determinado RNF, e portanto, atingir um nível de granularidade
no tratamento da informação mais detalhado.
Um exemplo desta classificação seria o RNF Primário Confiabilidade
que pode
ser decomposto em validação, autorização e entrega do software.
RNFs primários podem ser decompostos em outros RNFs secundários até que
se chegue ao que Chung
(CHUNG, 2000)
chama de operacionalização dos RNFs. Uma
operacionalização de um RNF é uma ação ou informação que irá garantir a satisfação do
RNF.
4. A Abordagem DAORE 93
Cysneiros (2001) exemplifica
o caso de um sistema de informação para
laboratórios de análises clínicas
. A
entrega do laudo ao paciente possui um RNF de
confidencialidade
que seria seu RNF primário. Para que possamos detalhar o que isso
implica, temos de decompor este RNF em um RNF específico de
segurança operacional
que por sua vez poderia ser decomposto na operacionalização
solicitar carteira de
identidade
. Ou seja, p
ara satisfazer o RNF
confidencialidade
teríamos de prever uma ação
no sistema, que garantisse que o funcionário que entregou o laudo solicitou a carteira de
identidade ao paciente antes de entregar
-
lhe o laudo.
F
IGURA
4.
3 –
U
MA
T
AXONOMIA PARA
RNF
S
.
F
ONTE
:
CYSNEIROS(200
1
)
RNFs
Dinamicos
Tempo real
Performance
*
*
Restrições de tempo
Outras
Clareza da Informação
Custo
Seguro
Qualidade
Restrições Operacionais
Restrições Físicas
Fácil de achar onde está um erro
Manutenabilidade
**
Fácil de modificar
Estáve
Fácil de testar
Portabilidade
**
Adaptabilidade
Fácil de migrar
por
plataformas
Usabilidade
**
Fácil de aprender
Fácil de Usar (interface adequada)
Confiabilidade
**
Equipamento/Informação
dispnível
quando
necessário
Integridade
Maturidade
RNF Estático
Numerica
Precisão
Informação
correta sempre disponível
Rastreabilidade
Confidencialidade
Identidade confirmada
Dados privados não
espostos
Qualidade
Validação
Confiabilidade
Autoriazação
Entrega
Permissão para consultar/atualizar
informação
Segurança
Confidencialidade de dados
RNF Primário
RNF Específico
**
ISO 9126
Caminho feito
por
algo/alguém
Qual o estado no momento
Tipo de equipamento a ser utilizado
Ordens de exibição específicas
4. A Abordagem DAORE 94
De acordo com a figura 4.3,
Cysneiros separa os RNFs em estáticos e
dinâmicos. RNFs estáticos são aqueles que, quando presentes,
normalmente requerem o
uso de dados para validá
-
los como, por exemplo:
segurança
, precisão
e rastreabilidade.
RNFs dinâmicos, por outro lado, usualmente representam conceitos mais abstratos,
que
normalmente envolvem ações ou critérios de qualidade
como, por exemplo:
Qualidade, performance,
manutenibilidade
, restrições operacionais. Alguns RNFs
podem
ser tanto estáticos quanto dinâmicos dependendo do contexto do domínio que estejam
inseridos. A Figura 4.
3
mostra um resumo desta taxonomia que também pode ser utilizada
como um
checklist
para a elicitação de RNFs.
Utilizaremos
a Tabela 4.
3
, adapta
da
da ferramenta OORNF, desenvolvida no
trabalho
de Cysneiros (2001)
para identificar
uma ontologia de RNF inicial. Esta tabela
possui
os
requisitos primários
e
secundários
do sistema, bem como sua
estratégia de
satisfação,
I
nfluência
(I)
e uma
observação
indicando o porque da influencia positiva(+)
ou negativa (
-
) da estratégia de satisfação no RNF.
Cysneiros (2001) afirma ainda que e
sta li
sta não pretende ser completa, mas
sim, um ponto de partida para cada desenvolvedor
gerar
seu próprio conhecimento a
respeito de RNFs, podendo inclusive adicionar outros.
T
ABELA
4.
3 –
RNF
S E ESTRATÉGIAS DE S
ATISFAÇÃO
.
F
ONTE
:
C
YSNEIROS
(2001).
RNF
Primário
RNF
E
specífico
Estratégia
S
atisfação
I
Observações
Informação de
apoio
+
caso as infor
mações de apoio sejam
utilizadas para a obtenção de precisão de
valor de outros itens de informação.
validação
+
pois a inspeção das informações por uma
pessoa diferente do emissor aumenta a
possibilidade de descobrir valores incorretos
destas informaçõ
es.
Precisão
-
auditoria
+
caso os itens de informação recuperados e
verificados tenham uma precisão de valor
duvidosa.
Validação
automática
+
pois inspeciona itens de informação em
relação a informações de apoio para verificar
se estão corretos.
Faixa de valores
+
caso sejam adotados procedimentos para
impedir que itens de informação assumam
valores fora da faixa ou para autorizar que
itens de informação tenham valores fora da
faixa.
Aviso
-
Valor
impreciso
+
caso o aviso chame atenção sobre it
ens de
informação com valor duvidoso.
PRECISÃO
PRECISÃO DE VALOR
autorização
+
pois a presença de um autorizador dificulta
4. A Abordagem DAORE 95
que itens de informação incorretos sejam
transmitidos para o sistema de informação.
Capacidade de
executar tarefa
+
pois a capacidade/nível de confiança d
o ator
do UdI aumenta a precisão de valor dos
itens de informação que manipula
confirmação
+
pois os itens de informação indicados são
comparados para verificar sua correção.
Pré
-
aviso de
valor impreciso
+
caso se indique ações que possibilitam
evit
ar valores incorretos
Validação na
fonte
+
pois os itens de informação com precisão de
valor duvidosa são verificados em suas
fontes
Checar
consistência
+
caso as restrições de integridade estejam
relacionadas com precisão de valor de itens
de inform
ação.
Apoio a
informação
+
caso as informações de apoio sejam
utilizadas para a obtenção de precisão de
valor de outros itens de informação.
validação
-
caso seja necessário um tempo excessivo
para a validação.
Precisão
-
a
uditoria
+
caso os itens recuperados e verificados
tenham uma precisão de oportunidade
duvidosa.
Validação
automática
+
pois é mais rápida do que a validação
convencional.
Validação de
acesso
-
caso a validação das regras de acesso seja
demorada.
Aviso de valor
impreciso
+
caso aviso chame atenção sobre itens de
informação que estão atrasados para serem
divulgados ou repassados
autorização
-
caso o processo de autorização sejam
demorado ou o autorizador não esteja
sempre disponível para realizar
a
autorização.
calendário
+
pois a definição de prazos aumenta a
probabilidade dos itens de informação serem
indicados no tempo correto.
Precisão de oportunidade
Pré
-
aviso de
valor impreciso
+
caso se indiquem ações que possibilitem
evitar atrasos na indicação de itens de
informação
Apoio a
informação
+
caso as informações de apoio sejam
utilizadas para a obtenção de precisão de
propriedade de outros itens de informação.
validação
+
pois a inspeção das informações por uma
pessoa diferente do emi
ssor aumenta a
possibilidade de descobrir propriedades
desejadas destas informações, que não
estão presentes.
Precisão
-
auditoria
+
caso os itens de informação recuperados e
verificados tenham uma precisão de
propriedade duvidosa.
Validação
automáti
ca
+
pois inspeciona itens de informação,
utilizando informações de apoio, para
verificar se possuem determinadas
propriedades.
Precisão de propriedade
Faixa de valores
+
caso sejam adotados procedimentos, como
por exemplo autorização, para garantir
certas propriedades de iten
s de info
r
mação
que estejam fora da faixa.
4. A Abordagem DAORE 96
autorização
+
pois a presença de um autorizador dificulta
que itens de informação, que não possuem
uma propriedade desejada, sejam
transmitidos para o sistema de informação.
Capacidade de
executar tarefa
+
p
ois a capacidade/nível de confiança do ator
do UdI aumenta a precisão de propriedade
dos itens de informação que manipula
Pré
-
aviso de
valor impreciso
+
caso se indiquem ações que possibilitem
evitar que certas propriedades não estejam
presentes em itens de informação
Validação na
fonte
+
pois os itens de informação com precisão de
propriedade duvidosa são verificados em
suas fontes
Checar
consistência
+
caso as restrições de integridade estejam
relacionadas com alguma(s)
propriedade
(s)
de itens d
e informação que se deseja
alcançar
Qualidade
impressão
+
onde a propriedade desejada é qualidade de
impressão de itens de informação.
Consistência
externa
Pré
-
aviso de
valor impreciso
+
caso se indique ações que possibilitem
evitar que os itens de i
nformação não
estejam refletindo seus valores do mundo
real
validação
-
caso o validador não possa ter acesso às
informações validadas.
Identificação/auto
rização
+
pois, com a identificação e autenticação das
identidades d
os atores do UdI, pode
-
se
permitir o acesso às informações, recursos,
e/ou atores do UdI apenas para os atores
que tem permissão para tal.
Precisão
-
auditoria
-
caso os auditores não possam ter acesso às
informações recuperadas e verificadas.
Tempo
limitado
de acesso
+
pois limita o tempo para acessar itens de
informação
Histórico de
acesso
+
pois permite identificar acessos não
autorizados a itens de informação.
alarme
+
pois permite a detecção de acessos não
autorizados a itens de informação.
Validação de
acesso
+
pois os itens de informação são acessados
apenas por quem tem direito para tal.
Segurança
-
auditoria
+
pois permite detectar acessos não
autorizados a itens de informação.
identificação
+
pois, com a identificação, é possív
el permitir
o acesso às informações, recursos e/ou
atores do UdI apenas para os atores que
tem permissão para tal
confidenciabilidade
autenticação
+
pois, com a autenticação, pode
-
se permitir
acesso às informações, recursos e/ou atores
do UdI apenas para os atores do UdI q
ue
tem permissão para tal e asseguram suas
identidades
Identificação/
autorização
+
pois, com a identificação e autenticação das
identidades dos atores do UdI, pode
-
se
permitir a alteração de informações apenas
para os atores que tem permissã
o para tal.
Tempo limitado
de acesso
+
pois limita o tempo para alterar itens de
informação.
segurança
integridade
Histórico de
acesso
+
pois permite identificar alterações não
autorizadas a itens de informação.
4. A Abordagem DAORE 97
Alarme
+
pois ajuda na detecção de alterações não
autoriz
adas de itens de informação.
Validação de
acesso
+
pois os itens de informação são alterados
somente por quem tem direito para tal.
Segurança
-
auditoria
+
pois permite detectar alterações não
autorizadas de itens de informação.
identificação
+
po
is, com a identificação, pode
-
se permitir a
alteração de itens de informação apenas
para atores do UdI que tem permissão para
tal
autenticação
+
pois, com a autenticação, pode
-
se permitir
alteração de informações apenas para os
atores do UdI que tem per
missão para tal e
asseguram suas identidades
D
isponibilida
-
de
Tempo limitado
de acesso
-
pois os serviços do sistema de informação
são suspensos após um determinado tempo.
Identificação/
autorização
-
caso sejam necessárias várias id
entificações
e autenticações.
Aviso de
imprecisão
-
caso os avisos sejam
freqüentes
,
atrapalhando a utilização dos serviços do
sistema de informação por atores do
universo de informações.
confirmação
-
caso o mesmo ator do UdI deva informar
duas veze
s o mesmo item de informação.
identificação
-
caso seja necessário realizar a identificação
várias vezes.
rapidez
autenticação
-
caso seja necessário realizar a autenticação
várias vezes.
Usabilidade
Taxa baixa
de erros
Faixa de valores
+
caso sejam adotados procedime
ntos que
avisem que valores de itens de informação
digitados estão fora da faixa.
confiabilidad
e
Confiabilida
-
de na
execução de
tarefas
Habilidade na
execução de
tarefas
+
pois o ator do universo de informações tem
conhecimento e/ou nível de confiança par
a
executar ação.
auditoria
-
caso seja necessário a contratação de
pessoas para realizar a auditoria.
autorização
-
caso seja necessário a contratação de
pessoas para realizarem o papel de
autorizadores.
Capacidade na
execuçã
o
-
caso seja necessário contratar mais pessoas
que tenham o conhecimento e/ou confiança
para executar as ações.
confirmação
-
Validação na
fonte
-
caso o contato com a fonte dos itens de
informação seja caro
custo
Custo operacional
Qualidade na
impressão
-
caso os recu
rsos, utilizados para atingir
qualidade de impressão, sejam caros.
Histórico de
acesso
-
caso seja demorado o registro das
informações do histórico.
Tempo de
performance
Segurança
-
auditoria
-
caso a manutenção do histórico acarrete
uma
diminuição na rapidez dos serviços
prestados pelo sistema de informações.
Espaço
-
performance
Apoio a
informação
-
caso as informações de apoio sejam
numerosas.
performance
Tempo e
local
–
rastreabilida
-
de
Histórico de
acesso
+
pois registra o autor de consultas
e
alterações de itens de informação, bem
como quando aconteceram as consultas e
alterações
4. A Abordagem DAORE 98
A tabela 4.
3 apresentou uma ontologia de requisitos não funcionais, indicando
a
influência da estratégia de satisfação utilizada para atender ao requisito
de forma
geral
,
ou seja, se possui uma influência negativa (
-
) ou positiva (+).
Se houver a necessidade, ao
final das operacionalizações dos requisitos não
funcionais,
uma tabela pode servir de apoio para o mapeamento dos requisitos não
funcionais e funcionais, conforme pode ser verificado na Tabela 4.4.
T
ABELA
4.
4 –
.
M
APEAMENTO DOS
R
EQUISITOS
N
ÃO
F
UNCIONAIS
E
R
EQUISITOS
F
UNCIONAIS
Requisitos Funcionais
R
equisitos Não Funcionais
RF1
RF2
...
RFn
R
NF
1
X
R
NF2
X
...
R
NFn
C
ysneiros
(200
1) relaciona as operacionalizações dos requisitos não funcionais
ao LEL a partir de seus símbolos (ou termos)
, porém relacionaremos ao construirmos os
cenários, pois na construção dos cenários isso é repetido.
Esta tarefa será explicada com
mais detalhes ao verificar
mos a
fase 3
– Construção do LEL.
4.2.1.4
-
Construção de Requisitos
Organizacionais
Geralmente a
Identificação de Requisitos Organizacionais
é descartada, porém
já se tem trabalhos salientando a importância de sua elaboração e integração na
modelagem funcional (SANTANDER, 2002).
O conhecimento do ambiente organizacional permite definir como o sistema de
software pretendido irá satisfazer os objetivos da organização, porque ele é necessário,
quais as alternativas existentes e quais as implicações das alte
rnativas para as várias partes
interessadas, entre outros aspectos (SANTANDER, 2002).
T
oranzo
(2002) expõe que os objetivos dos modelos organizacionais são:
1) Entender a estrutura e a dinâmica da organização que hospedará o sistema;
2) Entender os probl
emas da organização e identificar as suas soluções;
4. A Abordagem DAORE 99
3) Obter uma única e melhor compreensão da organização;
4) Contribuir para derivar requisitos do sistema para apoiar a organização.
Portanto, uma
cuidadosa
atenção aos aspectos organizacionais é cruc
ial para o
sucesso do sistema de informação de uma organização (Y
U
, 1997).
A inclusão da modelagem organizacional
torna explícito o fato de que podem
existir alguns conceitos organizacionais que são importantes para identificar e conhecer as
implicações so
bre
os requisitos dos sistemas.
S
antander
(2002) argumenta que a visão tradicional em L
oucopoulos
&
Karakostas (1995) esquece aspectos importantes que influenciam diretamente no sistema
que se deseja especificar, tais como: objetivos do sistema e seu relac
ionamento com os
objetivos da organização e outras propriedades relacionadas com o desempenho,
segurança e restrições.
De qualquer forma, os requisitos organizacionais são importantes porque
auxiliam a compreensão de interações complexas entre as organizaç
ões e pessoas
envolvidas.
No
RUP – Rational Unified Process, a modelagem organizacional está definida
no Workflow de
Modelagem de Negócio
, cujo objetivo principal está em modelar a
organização. Para isso define o modelo de casos de uso de negó
cio e o mode
lo de objetos
de neg
ó
cio.
O modelo de casos de uso de negócio representa as funções de neg
ó
cio
desejadas. Consiste de atores e casos de uso no nível de negócio. Os atores representam
papeis externos em relação a um negócio e casos de uso de negócio são processos.
O modelo de objetos de negócio inclui realizações de casos de uso, as quais
mostram como casos de uso de negócio são executados, em termo de interações de
trabalhadores de negócio e entidades de negócio.
O modelo de negócios e o modelo de casos de
uso de negócio podem auxiliar
na identificação da relevância destes aspectos.
Algumas situações são mais visíveis para identificar quando um requisito
organizacional é relevante para o sistema de software a ser desenvolvido.
Por exemplo, a
gerência de um
supermercado pode decidir que o sistema de venda de produtos
4. A Abordagem DAORE 100
implantado, deverá incluir um processo de atribuição de
pontos aos clientes que possuam
o cartão de fidelidade do supermercado.
Assim, identificar os requisitos organizacionais, suas prioridade
s, suas
expectativas em relação ao sistema podem levar
à
definição de algu
mas funcionalidades
na qual o sistema deve atender para que possa satisfazer estes requisitos organizacionais.
Est
as funcionalidades
dizem respeito a
uma
restrição ou influ
ência em r
elação
a uma funcionalidade básica.
Uma maneira mais simples de identificação seria após a identificação dos
requisitos organizacionais (e sua possível decomposição) formula
r
algumas perguntas
chaves, como:
1) Este requisito influencia outros requisitos?
Quais?
2) Ele é possível de implementação?
Assim, ao determinar os requisitos organizacionais do sistema e sua possível
operacionalização fica mais fácil identificar
quais
requisitos serão afetados se existir um
mapeamento dos requisitos organizacionais com os requisitos funcionais
e não funcionais
,
como podemos observar na tabela 4.5.
T
ABELA
4.
5 –
M
APEAMENTO DOS
R
EQUISITOS
O
RGANIZACIONAIS EM
R
EQUISITOS
F
UNCIONAIS
E NÃO
FUNCIONAIS
Requisitos Funcionais
Requisitos não
funcionais
R
equisitos Organizacionais
RF1
RF2
...
RFn
R1
R2
...
Rn
R
O
1
X
R
O2
X
X
...
R
On
4
4
.
.
2
2
.
.
2
2
F
F
a
a
s
s
e
e
2
2
–
–
C
C
o
o
n
n
s
s
t
t
r
r
u
u
ç
ç
ã
ã
o
o
d
d
o
o
L
L
E
E
L
L
Este recurso
foi implementado
na ferramenta REQUISITE e
será, igualmente,
utilizado na abordagem
DAORE
.
O principal objetivo do Léxico
Ampliado da Linguagem (LAL)
ou Léxico
Extendido da linguagem (LEL) é o de registrar a linguagem utilizada pelos atores do UdI,
4. A Abordagem DAORE 101
Sim
Não
Não
Sim
Formatar texto
Identificação dos símbolos
Texto
formatado
Inclusão,
Classificação e
desc
rição dos
símbolos
Requisitos
do Sistema
Verificar
consistência
Verificar
consistência
Analisar Interdependências
e Resolver conflitos
Não
Sim
I
ncluir
Restrições?
Acabou
cenários
Incluir Cenários
sem contudo se preocupar com a funcionalidade
(
FRANCO
&LEITE
, 19
92
)
(
LEITE
&FRANCO
, 1993
)
.
De modo geral o L
E
L define os seguintes passos a serem realizados:
1)
Elicitação de requisitos
–
separar períodos compostos em orações simples,
transformar orações na voz passiva para voz ativa e formas substantivas de
verbos para formas verbais correspondentes.
2)
Identificação dos símbolos
–
palav
ras ou frases com significado especial,
procurando por sujeitos, verbos, objetos e estados (predicativos).
3)
Classificação dos símbolos identificados
4)
Descrição dos símbolos
–
criar entradas no L
E
L referentes aos símbolos
identificados.
O
modelo de processo do LEL é apresentado na Figura 4.4.
F
IGURA
4.
4 –
M
ODELO DE
P
ROCESSO DE
C
ONSTRUÇÃO DO
LEL
NA ABORDAGEM
DAORE
Seguindo o processo proposto na construção do LEL n
a figura 4.
4
podemos
observar que:
4. A Abordagem DAORE 102
1.
O processo se inicia com a formatação dos requisitos elicitados;
2.
É feito a identificação dos símbolos do LEL de acordo com o modelo
proposto por (L
EITE
, 1997);
3.
A inclusão de cenários é feita de forma trivial seguindo orientação de
construção de cenários a partir do LEL da linguagem (L
EITE
, 1997);
4.
A incl
usão de restrições
3
: (RNF e RO) é realizada após a construção de
cenários. Porém, podemos incluir estas restrições durante a sua
construção
;
5.
Adaptamos
a proposta de
Cysneiros
(200
1
)
inclui
ndo
os requisitos não
funcionais
(que fazem parte das restrições
de
qualidade
do sistema)
após a inclusão de todos os cenários ou em conjunto com eles
;
6.
A
verificação de consistência
é necessária para conseguir buscar uma
otimização dos
cenários
e
restrições
gerad
a
s. Prevê
ainda
que
possamos minimizar o uso de estratégias
de satisfação (tabela 4.3)
que
podem trazer conseqüências negativas para o projeto e verificar a
dependência entre RNF gerados.
4
4
.
.
2
2
.
.
3
3
F
F
a
a
s
s
e
e
3
3
–
–
D
D
e
e
f
f
i
i
n
n
i
i
ç
ç
ã
ã
o
o
d
d
e
e
A
A
s
s
p
p
e
e
c
c
t
t
o
o
s
s
C
C
a
a
n
n
d
d
i
i
d
d
a
a
t
t
o
o
s
s
Segundo Souza (2004)
, que se utiliza de casos de uso,
o aspecto ou requisito
aspectual possui as seguintes características:
a) representa uma preocupação que deve ser inserida num caso de uso base,
alterando o fluxo de execução desse caso de uso, mas cujo propósito
não está diretamente
associado ao objetivo do caso de uso base;
b)
pode ser desvinculado do caso de uso base sem que isso impeça a realização
do objetivo do caso de uso;
c) ele é (ou pode vir a ser) aplicado em vários casos de uso e não apenas num
caso de uso específico.
3
Na implementação da ferramenta para validar a abordagem foi incluído restrições OCL na construção de
cenários.
4. A Abordagem DAORE 103
Neste trabalho é utilizado a técnica de cenários, l
ogo
, a identificação dos
aspectos candidatos deve ser realizada após a inclusão dos cenários no LEL, isto porque
irá facilitar o processo de identificação.
O processo de abstrair símbolos ou especificações que possam representar uma
preocupação que está
at
ravessada
no projeto, ou seja
,
um possível aspecto candidato,
pode ser identificado na abordagem através das seguintes diretrizes
:
D
1)
RNFs
– a identificação de requisitos não funcionais é um forte candidato a
ser um aspecto, pois como sabemos os RNFs são transversais por natureza (Yu et al 2004).
Deste modo, todos os RNF serão mapeados como aspectos candidatos.
D
2)
Um cenário incluído pode ser um aspecto candidato a partir das seguintes
características:
a) n
ão está associado diretamente a um Ator
;
b) apar
ece como uma restrição
ou e
x
ten
s
ão de um cenário principal ou
base (o que possui a funcionalidade principal);
c) é (ou pode vir a ser) aplicado em vários cenários base; e
d) se o retirarmos não alt
era
a funcionalidade do cenário base.
Este
aspecto candidato terá alguns campos especiais:
·
Tipo de contribuição
-
Esta contribuição pode ser negativa (quando irá
influenciar negativamente para o entendimento e complexidade do
cenário
base) ou positiva (ele contribui de forma a auxiliar na
compreensão do cenário
)
, de acordo com a tabela 4.3.
·
Tipo de Composição
–
Esta composição segue o padrão proposto por
Souza (2004).
4.2.3.1
-
Identificando Contribuições dos Aspectos Candidatos
As contribuições dos aspectos candidatos em relação aos cenários devem ser
identificad
as, ou seja, o quanto um aspecto irá restringir ou influenciar o cenário. Esta
contribuição poderá definir se existe
m
aspectos que não serão implementados, devido
à
alta contribuição negativa em relação ao sistema. Esta decisão é fator exclusivamente de
ge
rência de projeto e deve ser feita em conjunto com os usuários envolvidos.
4. A Abordagem DAORE 104
De forma geral, quando restringe de forma negativa, deve
-
se levar em conta
que estamos lidando com usuários e, estes, não gostam de perda de tempo em determinada
tarefa, por exemplo
. Assim, se temos um aspecto que demanda em determinado cenário
que este irá demorar um pouco mais para ser satisfeito, devemos tomar cuidados para
avaliar a situação caso a caso.
As contribuições podem ser determinadas através da tabela 4.6.
T
ABELA
4.
6–
C
ONTRIBUIÇÕES DOS
A
SPECTOS
Aspectos Candidatos
Aspecto 1
Aspecto 2
...
Aspecto n
Cenário
-
+
-
+
-
+
-
+
Cenário 1
X
X
Cenário 2
X
X
X
...
Cenário N
4.2.3.2
-
Definindo a Composição dos Aspectos Candidatos
Em linguagem
mais simples a definição de composição é realizada para
identificar como será a chamada para a execução do aspecto. Para isso
utilizaremos
o
modelo proposto por Souza (2004), com adaptações para cenários.
Devem ser
determinadas informações a respeito da c
omposição
entre um
requisito aspectual e os
cenários
afetados por ele e, devem ser definidas num artefato à parte,
conforme verificado na Tabela 4.
7
.
Esta tabela deve ser especificada para cada requisito aspectual de acordo com o
roteiro apresentado a segu
ir.
T
ABELA
4.7
–.
C
OMPOSIÇÃO DOS
A
SPECTOS
I
DENTIFICADOS
ASPECT
O CANDIDATO
:
#
ID
<
NOME
>
CENARIO
AFETADO
CONDIÇÃO
R
EGRA DE COMPOSIÇÃO
P
ONTO DE
JUNÇÃO
I
NFORMAÇÕES
ADICIONAIS
#
ID
<
NOME
>
CONDIÇÃO DA
EXTENSÃO
{
overlap.after|
overlap.before|
override.wrap}
PAS
SO DO
CENÁRIO
INFORMAÇÕES
RELATIVAS A
COMPOSIÇÃO
Para
preencher
a tabela 4.7 deve ser seguido o seguinte roteiro:
4. A Abordagem DAORE 105
1
)
Para cada ponto que um requisito aspectual precisar afetar num c
enário
, haverá
uma
entrada na tabela de composição nível 1 cujas colunas
devem ser
preenchidas da seguinte
maneira:
a. C
ENARIO
AFETADO: preencha com o nome do c
enário
no qual o
comportamento do
aspecto candidato
deve ser inserido.
b.
CONDIÇÃO (OPCIONAL): preencha essa coluna caso haja alguma condição
que deve ser
satisfeita p
ara que o comportamento do
aspecto candidato
seja
inserido no
cenário
.
c.
REGRA DE COMPOSIÇÃO: preencha com algum dos seguintes operadores
de composição
(
MOREIRA et al., 2002
)
:
overlap (before ou after), override e
wrap
. A escolha entre esses
operadores d
ependerá de como o comportamento do
aspecto candidato
deve ser aplicado
no ponto de junção (ver descrição dos
operadores n
o Capítulo
2
).
A definição de qual operador utilizar deve ser feita
em conjunto com os
stakeholders
(em conjunto com o engenheiro de r
equisitos).
d.
PONTO DE JUNÇÃO: preencha com o passo do cenário no qual o
comportamento do aspecto candidato
deve ser aplicado.
e.
INFORMAÇÕES ADICIONAIS (OPCIONAL): preencha com alguma outra
informação que deseje
acrescentar sobre a composição do
aspecto
candidato
.
4.2.3.3
-
Identificando Conflitos
Como estamos trabalhando com a tabela de composição utilizada por Souza
(2004), a resolução de conflitos segue o mesmo padrão.
Neste caso, os conflitos são identificados q
uando diferentes
aspectos
candidatos
de
vem ser aplicados em um mesmo ponto de junção de um cenário.
Quando temos
operadores de composição diferentes, a ordem de execução dos
aspectos deve seguir a ordem de precedência dos seus respectivos operadores de
composição. Entretanto, se dois ou mais as
pectos devem ser aplicados num mesmo ponto
de junção de um c
enário
com o mesmo operador de composição, então existe um conflito,
e a ordem de precedência deve ser decidida pelo analista e definida numa tabela de
conflitos (Tabela 4.8
).
4. A Abordagem DAORE 106
Existirá apenas uma
tabela de conflitos para todo o sistema, na qual todos os
c
enários
são listados nas linhas e os requisitos aspectuais nas colunas. Caso exista um
conflito de um requisito aspectual num passo de um cenário, a ordem de precedência desse
aspecto em relação ao
s aspectos com que ele conflita deve ser especificada na célula de
interseção entre o c
enário
e o aspecto da seguinte forma:
P[
numPassoConfl
]
-
[
siglaOperador
]=[
ordemPreced
], onde:
·
numPassoConfl deve ser substituído pelo número do passo do cenário
onde exis
te o
conflito;
·
siglaOperador
deve ser substituído por: (i) “OB”, caso o conflito ocorra
com o
operador overlap.before; (ii) “OA”, caso o conflito ocorra com o
operador
overlap.after
; (iii) “O”, caso o conflito ocorra com o operador
override
; ou “W”,
caso
o conflito ocorra com o operador wrap; e
·
ordemPreced deve ser substituído pela ordem de precedência do aspecto candidato.
Vamos s
upo
r que
, além do
aspecto candidato
A
C
#01
-
Verificação de débito,
um outro aspecto candidato
cujo identificador é A
C
#03 prec
isasse ser aplicado no passo 3
do
cenário CN
#05
-
Fazer matrícula em disciplina com o operador
wrap
; e que a
prioridade de execução fosse concedida para o aspecto
A
C
#03. Então, a tabela de conflitos
deveria ser preenchida conforme apresentado na Tabela 4.8.
T
ABELA
4.
8 –
E
XEMPLO DE PREENCHIME
NTO DA TABELA DE CON
FLITOS
AC#1
AC#2
AC#3
AC#4
CN#1
CN#2
CN#3
CN#4
CN#5
P3
-
W =2º
P3
-
W=1º
Á medida que os pontos de junção vão sendo refinados nos fluxos seguintes,
esses conflitos podem deixar
de existir. Contudo, essas prioridades definidas na tabela
de
conflitos serão úteis não somente caso o conflito persista nos fluxos de análise e
projeto,
mas também para auxiliar na definição dos pontos de junção nesses fluxos.
4. A Abordagem DAORE 107
4
4
.
.
2
2
.
.
4
4
F
F
a
a
s
s
e
e
4
4
–
–
M
M
a
a
p
p
e
e
a
a
m
m
e
e
n
n
t
t
o
o
d
d
e
e
O
O
n
n
t
t
o
o
l
l
o
o
g
g
i
i
a
a
s
s
Segundo G
ruber
(2006) ontologias são especificações formais e explicitas de
conceitualizações compartilhadas, ou seja, são modelos conceituais que capturam e
explicitam o vocabulário nas aplicações semânticas.
B
reitman
(200
5
) destaca que
ontologias servem como base para garantir uma
comunicação livre de ambigüidades.
O consorcio W3C
(2006)
define uma ontologia como: “a definição dos termos
utilizados na descrição e na representação de uma área do conhecimento. Devem prover
descrições para os seguintes tipos de conceito: classes, relacionamentos e propriedades”.
Inicialmente o processo de mapeamento de ontologias foi proposto por
Breitman & Leite (2003) e incorporado ao processo
de construção do léxico existente na
DAORE
.
T
ABELA
4.
9 –
.
M
APE
AMENTO
DOS
E
LEMENTOS DO
LEL
PARA OS
E
LEMENTOS DA
O
NTOLOGIA
.
F
ONTE
:
B
REITMAN
&L
EITE
(200
3
).
Elementos do LEL
Elementos da Ontologia
Objeto e Sujeito
Classes
Estado
Classe ou propriedade
Verbo
Propriedade
Noção
Descrição
Impacto
–
verbo
Propriedade
Impa
cto
– predicado(termos)
Classes ou axiomas
No mapeamento descrito na tabela 4.9
podemos observar que os elementos ou
termos classificados como do tipo
objeto
e
sujeito
são mapeados em
classes
da ontologia;
os elementos classificados como do tipo
verbo
são
mapeados para
propriedades
. Os
termos classificados como do tipo
estado para
classes
ou
propriedades
, dependendo de
sua importância relativa para a ontologia; a noção
de cada termo é mapeada na
descrição
da respectiva classe; e através da lista de
impacto
s
de cada termo do léxico mapeia
-
se o
verbo em
propriedades e o predicado
em
restrições (axiomas) das classes.
Breitman (2005) argumenta ainda que este processo de mapeamento é
indepe
n
dente da linguagem de implementação da ontologia, como , por exemplo
a
O
WL
4
,
entre outras.
4
Disponível em http://www.co
-
ode.org/resources/tutorials/protegeowltutorial.pdf
4. A Abordagem DAORE 108
Nossa proposta realiza a conversão de acordo com a tabela 4.9
. No cap
í
tulo 5
veremos na prática como irá funcionar.
O processo de mapeamento de ontologias inclui também a
construção da
hierarquia de classes e consiste na análise da ontologia de modo a identificar conceitos que
possam estar relacionados hierarquicamente.
Breitman (2005) argumenta que as classes de uma ontologia se relacionam,
estruturalmente, através do relacionamento de especialização, ou seja, no topo da
ontologia fica
o elemento mais genérico, e nas suas folhas os mais específicos.
Para facilitar o entendimento vamos expor o exemplo apresentado por
Breitman (2005), onde apresenta termos referentes a um domínio de sobremesas.
A construção da hierarquia de classes sugerid
a tem como resultado a tabela
4.10.
T
ABELA
4.10
–
.
E
XEMPLO DE HIERARQUIA
DE CLASSES
.
F
ONTE
:
B
REITMAN
(2005).
Classe Pai
Classes relacionadas
Torta
Torta de coco
Petit
-
gateau
Torta de limão
Pudim
Pudim de chocolate
Pudim de laranja
Manjar de coco
Mousse
Mousse de maracujá
Mousse de cupuaçu
Mousse de limão
A tabela 4.
8
apresenta a
classe pai
criada para conter as classes filho
relacionadas.
4
4
.
.
2
2
.
.
5
5
G
G
e
e
r
r
a
a
ç
ç
ã
ã
o
o
d
d
e
e
a
a
r
r
q
q
u
u
i
i
v
v
o
o
s
s
p
p
a
a
r
r
a
a
E
E
x
x
p
p
o
o
r
r
t
t
a
a
ç
ç
ã
ã
o
o
Apesar de não estar no modelo de processo proposto (figura 4.1) a ex
portação
do modelo LEL, ontologias e
aspectos
através de um documento XML
são muito
importantes a fim de permitir uma interoperabilidade entre ferramentas.
O trabalho de W
iese
(2006) aborda a questão de interoperabilidade entre as
ferramentas de desenvolvimento, realizando um trabalho de transformação entre modelos
de casos de uso, entre as ferramentas:
Poseidon
5
, Enterprise Architect
6
e a
Requisite
.
5
Disponível para download em:
http://www.gentleware.com/
.
4. A Abordagem DAORE 109
LELCenario.xsd
LELSimbolos.xsd
Porém,
este trabalho
não
l
ida
com
casos de uso, mas sim do
LEL
, aspectos e
ontologias.
Deste modo, a defin
ição de
padrões de documentos XML Schema
é importante
no sentido de que eles servem para
validar arquivo
s
XML e permitir
em
uma organização
da nomenclatura a ser utilizada.
Os documentos XML Schema foram gerados através da ferramenta Stylus
Studio 6 XML Enterprise Edition
7
e são organizados como se segue:
1) Padronizando os termos usados nos símbolos do LEL
2) Padronizando os termos usados nos cenários do LEL;
3) Padronizando os termos usados nos elementos da
ontologia;
4) Padronizando os termos com as classes pai e seus filhos da
ontologia
5) Padronizando os termos usados nos aspectos candidatos;
Os
arquivos XML
Schemas propostos estão na
í
ntegra no anexo A.
4
4
.
.
3
3
C
C
o
o
n
n
s
s
i
i
d
d
e
e
r
r
a
a
ç
ç
õ
õ
e
e
s
s
s
s
o
o
b
b
r
r
e
e
a
a
a
a
b
b
o
o
r
r
d
d
a
a
g
g
e
e
m
m
D
D
A
A
O
O
R
R
E
E
Serão apresentadas algumas considerações
sobre a abordagem DAORE,
proposta neste capítulo, em relação aos objetivos propostos e abordagens estudadas no
capítulo
2.
4
4
.
.
3
3
.
.
1
1
C
C
o
o
m
m
R
R
e
e
l
l
a
a
ç
ç
ã
ã
o
o
a
a
o
o
s
s
O
O
b
b
j
j
e
e
t
t
i
i
v
v
o
o
s
s
P
P
r
r
o
o
p
p
o
o
s
s
t
t
o
o
s
s
A tabela 4.
11
apresenta as considerações da abordagem DAORE com relação
aos objetivos pr
opostos.
6
Disponível para download em:
http://www.sparxsystems.com/
7
Esta ferramenta se encontra disponível para download em:
www.
stylusstudio
.com/.
ontologia.xsd
ontohierarquia.xsd
AspectosLEL.xsd
4. A Abordagem DAORE 110
A coluna Objetivo Proposto apresenta o que se deseja, a coluna abordagem
DAORE apresenta como foi realizada na abordagem e a coluna considerações apresenta
observações julgadas pertinentes.
T
ABELA
4.
11 –
DAORE
E OS
O
BJETIVOS
P
ROPOSTOS
Objetivo Pro
posto
Abordagem DAORE
Considerações
Utilizar o LE
L
e permitir a
identificação de
propriedades transversais
do
projeto
Através de diretrizes para
este fim.
A
s
propriedades
transversais
são obtidos
após a especificação dos
cenários.
Suporte a metodologia
M
DSODI na definição dos
cenários e d
a
s
propriedades
transversais
Através da definição do tipo
do cenário especificado.
Para o ator envolvido no
cenário, seu tipo será
definido de acordo com o
mesmo.
Permitir um alto grau de
usabilidade
Permite uma rápida
compreensão e
entendimento do método,
uma vez que utiliza de
conceitos já existentes
(LEL)
A forma de elaboração do
LEL não foi alterada.
Apenas acrescentou
-
se
novas características
(restrições)
Boa adequação quanto à
identificação de
propriedades transv
ersais
A identificação de
propriedades transversais
é
feita de forma semi
-
automática
Através
das diretrizes
propostas
Identificar requisitos
organizacionais, através de
suas
operacionalizações
Através da inclusão de
restrições nos cenários.
Especificar XML Schemas
para auxiliar na exportação
de documentos padrão no
formato XML
Foi criado XML Schemas
para este fim
Utilizou
-
se de
símbolos do
LEL, cenários, aspectos e
ontologias
, tanto dos termos
quanto
da hierarquia de
classes.
Facilitar a resolução de
conflitos
Através de padrão existente
definido por Souza (2004)
Pode ser gerado
automaticamente.
Facilitar o
rastreamento
de
requisitos
Através do principio do
LEL de circularidade e
vocabulário mínimo.
Este princ
í
pio não foi
alterado.
4
4
.
.
3
3
.
.
2
2
U
U
s
s
o
o
n
n
a
a
R
R
e
e
q
q
u
u
i
i
s
s
i
i
t
t
e
e
e
e
n
n
o
o
P
P
r
r
o
o
j
j
e
e
t
t
o
o
D
D
i
i
S
S
E
E
N
N
No capítulo 6
será
apresentado em detalhes as mudanças a realizadas
(e as que
podem ser realizadas)
na ferramenta Requisite a fim de prover as características
determinadas na DAORE, bem como no projeto DiSEN.
4. A Abordagem DAORE 111
4
4
.
.
3
3
.
.
3
3
D
D
i
i
f
f
e
e
r
r
e
e
n
n
ç
ç
a
a
s
s
c
c
o
o
m
m
a
a
s
s
A
A
b
b
o
o
r
r
d
d
a
a
g
g
e
e
n
n
s
s
E
E
s
s
t
t
u
u
d
d
a
a
d
d
a
a
s
s
Por definir os cenários através do LEL, a abordagem DAORE já é única em sua
concepção, uma vez que
não foi encontrada uma abordagem que se utiliza do LEL e
aspectos
. Por outro lado, a DAORE conseguiu buscar algumas característ
icas das
abordagens estudadas que facilitam o seu entendimento (como pode ser verificado na
tabela 4.1).
A
abordagem DAORE
em seu objetivo básico “
facilitar a identificação d
a
s
propriedades transversais
”
consegue minimizar o problema de identificação comum
na
maioria das abordagens.
Assim, seu diferencial principal está em aliar a praticidade e
a maturidade
do
LEL nos projetos com a identificação d
a
s
propriedades transversais
a partir deste LEL.
Aliado a isso, podemos incluir o tipo de cenário utilizado a p
artir da metodologia
MDSODI, o que a torna integrada a metodologia.
4
4
.
.
4
4
R
R
e
e
s
s
u
u
m
m
o
o
d
d
o
o
C
C
a
a
p
p
í
í
t
t
u
u
l
l
o
o
Neste capítulo foram
apresentadas as diretrizes
para a abordagem
DA
O
RE, o
que ela propõe e suas fases para o desenvolvimento na fase de requisitos.
As regras def
inidas pela abordagem perfazem um conjunto de conceitos
integrados das abordagens estudadas no Capítulo 3 com algumas adaptações e inserções
novas (como a utilização de padrões de qualidade para a definição dos requisitos não
funcionais e a identificação e integração dos requisitos organizacionais na modelagem).
Outro aspecto importante da
DAORE é o de
permitir a portabilidade e
interoperabilidade entre plataformas e ferramentas, através do padrão XML
, de acordo
com o
XML
Schema elaborado para este fim
, des
de o LEL proposto para o projeto
até os
elementos da ontologia dos projetos, sem esquecer dos aspectos candidatos.
Neste capítulo
procuramos dar uma atenção especial na elicitação dos
requisitos e como identificar os aspectos (uma preocupação constante em
todas as
abordagens estudadas) utilizando nossa abordagem, de forma semi
-
automática.
Assim, procuramos minimizar um dos principais problemas existentes na
separação de
propriedades
: a sua efetiva identificação.
4. A Abordagem DAORE 112
No próximo capítulo
faremos a experimentação
da a
bordagem e
será
realiza
do
uma análise do impacto das mudanças a serem efetuadas n
a ferramenta
Requisite
,
apresentadas no capítulo 6.
5.
Experimentação
: Controle de Eventos Científicos 113
C
APÍTULO
5
5
E
XPERIMENTAÇÃO
:
CONTROLE DE
E
VENTOS
CIENTÍFICOS
As palavras que não são seguidas de fatos não servem para nada.
Demóstenes
S
S
e
e
g
g
u
u
n
n
d
d
o
o
T
T
R
R
A
A
V
V
A
A
S
S
S
S
O
O
S
S
e
e
t
t
a
a
l
l
(
(
2
2
0
0
0
0
2
2
)
)
e
e
x
x
i
i
s
s
t
t
e
e
m
m
d
d
u
u
a
a
s
s
t
t
é
é
c
c
n
n
i
i
c
c
a
a
s
s
p
p
a
a
r
r
a
a
a
a
v
v
a
a
l
l
i
i
a
a
r
r
u
u
m
m
a
a
a
a
b
b
o
o
r
r
d
d
a
a
g
g
e
e
m
m
:
:
e
e
x
x
p
p
e
e
r
r
i
i
m
m
e
e
n
n
t
t
o
o
s
s
e
e
e
e
s
s
t
t
u
u
d
d
o
o
s
s
d
d
e
e
c
c
a
a
s
s
o
o
.
.
A
A
r
r
e
e
a
a
l
l
i
i
z
z
a
a
ç
ç
ã
ã
o
o
d
d
e
e
e
e
x
x
p
p
e
e
r
r
i
i
m
m
e
e
n
n
t
t
o
o
s
s
p
p
r
r
o
o
v
v
ê
ê
u
u
m
m
a
a
m
m
a
a
n
n
e
e
i
i
r
r
a
a
d
d
e
e
a
a
v
v
a
a
l
l
i
i
a
a
ç
ç
ã
ã
o
o
b
b
a
a
s
s
e
e
a
a
d
d
a
a
e
e
m
m
c
c
o
o
m
m
p
p
a
a
r
r
a
a
ç
ç
ã
ã
o
o
d
d
i
i
r
r
e
e
t
t
a
a
,
,
p
p
e
e
r
r
m
m
i
i
t
t
i
i
n
n
d
d
o
o
a
a
o
o
s
s
p
p
e
e
s
s
q
q
u
u
i
i
s
s
a
a
d
d
o
o
r
r
e
e
s
s
i
i
n
n
v
v
e
e
s
s
t
t
i
i
g
g
a
a
r
r
q
q
u
u
a
a
l
l
o
o
i
i
m
m
p
p
a
a
c
c
t
t
o
o
d
d
a
a
t
t
e
e
c
c
n
n
o
o
l
l
o
o
g
g
i
i
a
a
n
n
o
o
p
p
r
r
o
o
c
c
e
e
s
s
s
s
o
o
d
d
e
e
m
m
a
a
n
n
e
e
i
i
r
r
a
a
d
d
e
e
t
t
a
a
l
l
h
h
a
a
d
d
a
a
.
.
O
O
e
e
s
s
t
t
u
u
d
d
o
o
d
d
e
e
c
c
a
a
s
s
o
o
s
s
e
e
s
s
t
t
á
á
p
p
r
r
e
e
o
o
c
c
u
u
p
p
a
a
d
d
o
o
e
e
m
m
a
a
v
v
a
a
l
l
i
i
a
a
r
r
o
o
s
s
b
b
e
e
n
n
e
e
f
f
í
í
c
c
i
i
o
o
s
s
d
d
e
e
u
u
m
m
a
a
a
a
b
b
o
o
r
r
d
d
a
a
g
g
e
e
m
m
p
p
a
a
r
r
a
a
v
v
e
e
r
r
i
i
f
f
i
i
c
c
a
a
r
r
s
s
e
e
a
a
s
s
m
m
u
u
d
d
a
a
n
n
ç
ç
a
a
s
s
n
n
o
o
p
p
r
r
o
o
c
c
e
e
s
s
s
s
o
o
p
p
r
r
o
o
p
p
o
o
r
r
c
c
i
i
o
o
n
n
a
a
r
r
a
a
m
m
o
o
r
r
e
e
s
s
u
u
l
l
t
t
a
a
d
d
o
o
e
e
s
s
p
p
e
e
r
r
a
a
d
d
o
o
.
.
A
A
t
t
é
é
c
c
n
n
i
i
c
c
a
a
e
e
s
s
c
c
o
o
l
l
h
h
i
i
d
d
a
a
p
p
a
a
r
r
a
a
e
e
s
s
t
t
e
e
t
t
r
r
a
a
b
b
a
a
l
l
h
h
o
o
f
f
o
o
i
i
o
o
d
d
e
e
e
e
x
x
p
p
e
e
r
r
i
i
m
m
e
e
n
n
t
t
a
a
ç
ç
ã
ã
o
o
.
.
A
A
p
p
l
l
i
i
c
c
a
a
r
r
e
e
m
m
o
o
s
s
a
a
a
a
b
b
o
o
r
r
d
d
a
a
g
g
e
e
m
m
D
D
A
A
O
O
R
R
E
E
e
e
m
m
u
u
m
m
s
s
i
i
s
s
t
t
e
e
m
m
a
a
d
d
e
e
s
s
o
o
f
f
t
t
w
w
a
a
r
r
e
e
f
f
i
i
c
c
t
t
í
í
c
c
i
i
o
o
d
d
e
e
u
u
m
m
a
a
e
e
m
m
p
p
r
r
e
e
s
s
a
a
q
q
u
u
e
e
r
r
e
e
a
a
l
l
i
i
z
z
a
a
e
e
v
v
e
e
n
n
t
t
o
o
s
s
c
c
i
i
e
e
n
n
t
t
í
í
f
f
i
i
c
c
o
o
s
s
,
,
o
o
m
m
e
e
s
s
m
m
o
o
a
a
p
p
r
r
e
e
s
s
e
e
n
n
t
t
a
a
d
d
o
o
p
p
o
o
r
r
B
B
a
a
t
t
i
i
s
s
t
t
a
a
(
(
2
2
0
0
0
0
3
3
)
)
,
,
p
p
o
o
r
r
é
é
m
m
c
c
o
o
m
m
o
o
a
a
c
c
r
r
é
é
s
s
c
c
i
i
m
m
o
o
d
d
e
e
o
o
u
u
t
t
r
r
a
a
s
s
c
c
a
a
r
r
a
a
c
c
t
t
e
e
r
r
í
í
s
s
t
t
i
i
c
c
a
a
s
s
.
.
I
I
n
n
i
i
c
c
i
i
a
a
l
l
m
m
e
e
n
n
t
t
e
e
a
a
p
p
r
r
e
e
s
s
e
e
n
n
t
t
a
a
r
r
e
e
m
m
o
o
s
s
o
o
s
s
i
i
s
s
t
t
e
e
m
m
a
a
p
p
r
r
o
o
p
p
o
o
s
s
t
t
o
o
,
,
s
s
e
e
u
u
s
s
r
r
e
e
q
q
u
u
i
i
s
s
i
i
t
t
o
o
s
s
f
f
u
u
n
n
c
c
i
i
o
o
n
n
a
a
i
i
s
s
,
,
n
n
ã
ã
o
o
f
f
u
u
n
n
c
c
i
i
o
o
n
n
a
a
i
i
s
s
e
e
o
o
r
r
g
g
a
a
n
n
i
i
z
z
a
a
c
c
i
i
o
o
n
n
a
a
i
i
s
s
.
.
A
A
p
p
a
a
r
r
t
t
i
i
r
r
d
d
e
e
s
s
t
t
a
a
b
b
a
a
s
s
e
e
l
l
i
i
n
n
e
e
5.
Experimentação
: Controle de Eventos Científicos 114
d
d
e
e
s
s
e
e
n
n
v
v
o
o
l
l
v
v
e
e
r
r
e
e
m
m
o
o
s
s
n
n
o
o
s
s
s
s
o
o
p
p
r
r
o
o
j
j
e
e
t
t
o
o
a
a
f
f
i
i
m
m
d
d
e
e
c
c
o
o
m
m
p
p
a
a
r
r
a
a
r
r
m
m
o
o
s
s
c
c
o
o
m
m
o
o
a
a
n
n
t
t
e
e
r
r
i
i
o
o
r
r
(
(
r
r
e
e
a
a
l
l
i
i
z
z
a
a
d
d
o
o
n
n
o
o
c
c
a
a
p
p
i
i
t
t
u
u
l
l
o
o
6
6
)
)
.
.
5
5
.
.
1
1
O
O
b
b
j
j
e
e
t
t
i
i
v
v
o
o
s
s
Este estudo de caso tem o propósito de: (
i
) mostrar como a DAORE pode ser
usada para melhorar o entendimento e identificação dos crosscutting concerns em um
processo
de engenharia de requisitos; e (
ii
) avaliar se
a DAORE contribuirá para
reusabilidade, manutenibilidade e compreensibilidade dos crosscutting concerns sobre os
projetos desenvolvidos utilizando a MDSODI.
Este estudo de caso é o mesmo elaborado para a valid
ação da ferramenta
Requisite, escolhemos o mesmo para facilitar o processo de comparação e análise do
impacto do uso da abordagem DAORE para o processo de desenvolvimento.
A seguir descreveremos o contexto do sistema proposto para realizar nossa
avaliação
final.
5
5
.
.
2
2
A
A
E
E
s
s
c
c
o
o
l
l
h
h
a
a
d
d
a
a
F
F
e
e
r
r
r
r
a
a
m
m
e
e
n
n
t
t
a
a
d
d
e
e
I
I
m
m
p
p
l
l
e
e
m
m
e
e
n
n
t
t
a
a
ç
ç
ã
ã
o
o
A escolha da ferramenta OORNF para apoiar a abordagem proposta se deve a
algumas considerações:
a) A ferramenta Requisite estava sendo analisada e alterada por Wiese (2006) para
seu projeto, de modo qu
e somente após o t
é
rmino deste trabalho poderia ser analisado o
quanto foi alterada, pois inicialmente nem mesmo possuía persistência em seus dados
e
identificação de seus termos (elementos do LEL)
;
b) Foram feit
a
s algumas análises de outras ferramentas existentes que utilizassem o
LEL da linguagem, como a OORNF
1
e a C&L
2
, onde foi constatado:
b.1) A ferramenta OORNF
possui persistência, identificação dos símbolos
do LEL e
possui integrado os requisitos não funcionais na definição do LEL,
foi
desenvolvida
em Delphi.
1
(CYSNEIROS, 2002)
d
esenvolvida no trabalho do prof. Cysneiros da Universidade de York, Toronto
-
Canadá, que disponibilizou o código fonte.
2
Disponível no site
http://139.82.24.189/cel/
, onde possui inclusive o código fonte.
5.
Experimentação
: Controle de Eventos Científicos 115
b.2) A ferramenta C&L
possui persistência, identificação dos símbolos do
LEL e
possui integrado a construção de ontologias do LEL, foi desenvolvida em PHP.
c)
O objetivo principal da DAORE é o de facilitar a identificação de aspectos
candidato
s, onde podemos primeiramente salientar os derivados dos requisitos não
funcionais.
Baseado, principalmente no item C
, foi escolhida a ferramenta OORNF para a
alteração
, por já ter integrado os requisitos não funcionais, mesmo que fosse feita alteração
na
forma da integração, pois facilitaria a identificação dos aspectos candidatos.
A nova versão da OORNF passou a chamar
-
se
CALEL
– Candidates Aspects from
LEL
, aprovado pelo prof. Cysneiros
. Alterada no sentido de prover recursos para a
inclusão de ontologia
s, requisitos organizacionais e a exportação nos padrões
especificados no Capítulo 4, suas telas estão no anexo B.
Porém, a alteração prevista da ferramenta Requisite está descrita em detalhes no
Capítulo 6. O uso da CALEL foi apenas para fins de estudo d
e caso.
5
5
.
.
3
3
O
O
S
S
i
i
s
s
t
t
e
e
m
m
a
a
P
P
r
r
o
o
p
p
o
o
s
s
t
t
o
o
Uma empresa presta serviços de gerenciamento de eventos.
O cliente ou também chamado de cliente em potencial pode consultar os
eventos que estão com para acontecer e os eventos que já ocorreram. Caso goste de algum
event
o poderá solicitar seu cadastro como cliente cadastrado, assim, poderá fazer sua
inscrição para os eventos que irão ocorrer. Seu cadastro será analisado e caso seja
aprovado (depende de consulta do CPF e órgãos compententes), poderá inscrever
-
se como
ouvin
te, para assistir as palestras, apresentações e cursos do evento ou poderá enviar
trabalhos (short
paper
, long paper ou
pôster), sendo a aceitação do trabalho condicionada
à
avaliação
por comitê cientifico. Em qualquer dos dois casos (ouvinte ou participan
te)
deverá pagar a inscrição.
Os clientes cadastrados também podem participar do evento como pales
trante
ou
ministrante. O palestrante é convidado pela comissão organizadora para realizar uma
ou mais palestras durante o evento. O ministrante é convidado pela comissão organizadora
para ministrar um ou mais cursos durante o evento.
Nestes casos o participante estará
isento da taxa de inscrição.
5.
Experimentação
: Controle de Eventos Científicos 116
O participante deverá enviar os slides nos prazos estabelecidos para tal, bem
como o ministrante deverá enviar o mat
erial do curso a ser ministrado, bem como a
requisição de recursos necessários para a sua execução nos prazos estabelecidos.
A
comissão organizadora elaborará a programação do evento com base nos
trabalhos, cursos e palestras.
A comissão também é responsáv
el
por
cadastrar os parceiros
do evento (fornecedores, patrocinadores).
Os recursos financeiros são providos pelos patrocinadores e
irão
servir para
pagar os fornecedores do evento (de recursos materiais e humanos).
A secretaria é
responsável por distribuir os recursos financeiros recebidos.
Mesmo os clientes já cadastrados deve
m
se
preocupa
r
em verificar sua situação
junto aos órgãos competentes quando da sua inscrição para um novo evento. Caso sua
situação não esteja em ordem sua inscrição dever
á
ocorrer
apenas se o pagamento for em
débito em conta.
Não serão convidados (palestrantes e ministrantes) pessoas com problemas
com os órgãos competentes.
Crachás de identificação devem ser entregues
a todos os participantes do
evento.
Só
será permitido o acesso ao evento aos portadores de crachás.
Para comprovar a participação no evento, os participantes receberão
certificados de participação. Os certificados só deverão ser emitidos para os participantes
com, no mínimo 85% de presença.
A empresa deseja conseguir o maior número de clientes
VIP. Um
cliente
VIP
é
aquele que
solicita
mais de três eventos anuais. A este
cliente
é concedido
um desconto
especial de 3
0%
nos serviços prestados. Para os participantes que são freqüentes (mais de
três eventos anuais) também é
oferecido
descontos especiais em hotéis, restaurantes e
outros patrocinadores, possuindo um cartão de
C
liente
VIP da empresa.
5
5
.
.
4
4
F
F
a
a
s
s
e
e
1
1
-
-
I
I
d
d
e
e
n
n
t
t
i
i
f
f
i
i
c
c
a
a
n
n
d
d
o
o
o
o
s
s
R
R
e
e
q
q
u
u
i
i
s
s
i
i
t
t
o
o
s
s
Seguindo o modelo proposto por Toranzo (2002) e já colocando os requisitos
de acordo
com as regras estabelecidas para o LEL, construímos a tabela 5.1 e 5.2.
5.
Experimentação
: Controle de Eventos Científicos 117
T
ABELA
5.1
–
R
EQUISITOS DO SISTEMA
R
R
e
e
q
q
u
u
i
i
s
s
i
i
t
t
o
o
s
s
f
f
u
u
n
n
c
c
i
i
o
o
n
n
a
a
i
i
s
s
S
S
e
e
c
c
r
r
e
e
t
t
á
á
r
r
i
i
a
a
c
c
a
a
d
d
a
a
s
s
t
t
r
r
a
a
c
c
l
l
i
i
e
e
n
n
t
t
e
e
P
P
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
n
n
t
t
e
e
c
c
o
o
n
n
s
s
u
u
l
l
t
t
a
a
e
e
v
v
e
e
n
n
t
t
o
o
s
s
e
e
m
m
a
a
b
b
e
e
r
r
t
t
o
o
P
P
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
n
n
t
t
e
e
c
c
o
o
n
n
s
s
u
u
l
l
t
t
a
a
e
e
v
v
e
e
n
n
t
t
o
o
s
s
f
f
e
e
c
c
h
h
a
a
d
d
o
o
s
s
S
S
e
e
c
c
r
r
e
e
t
t
á
á
r
r
i
i
a
a
c
c
o
o
n
n
s
s
u
u
l
l
t
t
a
a
e
e
v
v
e
e
n
n
t
t
o
o
s
s
e
e
m
m
a
a
b
b
e
e
r
r
t
t
o
o
S
S
e
e
c
c
r
r
e
e
t
t
á
á
r
r
i
i
a
a
c
c
a
a
d
d
a
a
s
s
t
t
r
r
a
a
o
o
u
u
v
v
i
i
n
n
t
t
e
e
e
e
m
m
u
u
m
m
e
e
v
v
e
e
n
n
t
t
o
o
e
e
m
m
a
a
b
b
e
e
r
r
t
t
o
o
O
O
u
u
v
v
i
i
n
n
t
t
e
e
s
s
e
e
c
c
a
a
d
d
a
a
s
s
t
t
r
r
a
a
e
e
m
m
u
u
m
m
e
e
v
v
e
e
n
n
t
t
o
o
e
e
m
m
a
a
b
b
e
e
r
r
t
t
o
o
P
P
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
n
n
t
t
e
e
s
s
e
e
c
c
a
a
d
d
a
a
s
s
t
t
r
r
a
a
e
e
m
m
u
u
m
m
e
e
v
v
e
e
n
n
t
t
o
o
e
e
m
m
a
a
b
b
e
e
r
r
t
t
o
o
P
P
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
n
n
t
t
e
e
e
e
n
n
v
v
i
i
a
a
t
t
r
r
a
a
b
b
a
a
l
l
h
h
o
o
s
s
S
S
e
e
c
c
r
r
e
e
t
t
á
á
r
r
i
i
a
a
o
o
u
u
a
a
c
c
o
o
m
m
i
i
s
s
s
s
ã
ã
o
o
a
a
l
l
t
t
e
e
r
r
a
a
o
o
p
p
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
n
n
t
t
e
e
e
e
m
m
u
u
m
m
e
e
v
v
e
e
n
n
t
t
o
o
e
e
m
m
a
a
b
b
e
e
r
r
t
t
o
o
c
c
o
o
m
m
n
n
o
o
m
m
í
í
n
n
i
i
m
m
o
o
2
2
4
4
h
h
o
o
r
r
a
a
s
s
d
d
e
e
a
a
n
n
t
t
e
e
c
c
e
e
d
d
ê
ê
n
n
c
c
i
i
a
a
S
S
e
e
c
c
r
r
e
e
t
t
á
á
r
r
i
i
a
a
o
o
u
u
o
o
c
c
o
o
m
m
i
i
t
t
ê
ê
e
e
x
x
c
c
l
l
u
u
e
e
m
m
o
o
p
p
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
n
n
t
t
e
e
e
e
m
m
u
u
m
m
e
e
v
v
e
e
n
n
t
t
o
o
e
e
m
m
a
a
b
b
e
e
r
r
t
t
o
o
c
c
o
o
m
m
n
n
o
o
m
m
í
í
n
n
i
i
m
m
o
o
7
7
d
d
i
i
a
a
s
s
ú
ú
t
t
e
e
i
i
s
s
d
d
e
e
a
a
n
n
t
t
e
e
c
c
e
e
d
d
ê
ê
n
n
c
c
i
i
a
a
S
S
e
e
c
c
r
r
e
e
t
t
á
á
r
r
i
i
a
a
c
c
o
o
n
n
s
s
u
u
l
l
t
t
a
a
p
p
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
n
n
t
t
e
e
s
s
e
e
m
m
u
u
m
m
e
e
v
v
e
e
n
n
t
t
o
o
S
S
e
e
c
c
r
r
e
e
t
t
á
á
r
r
i
i
a
a
c
c
a
a
d
d
a
a
s
s
t
t
r
r
a
a
e
e
v
v
e
e
n
n
t
t
o
o
S
S
e
e
c
c
r
r
e
e
t
t
á
á
r
r
i
i
a
a
c
c
a
a
d
d
a
a
s
s
t
t
r
r
a
a
c
c
o
o
m
m
i
i
s
s
s
s
ã
ã
o
o
o
o
r
r
g
g
a
a
n
n
i
i
z
z
a
a
d
d
o
o
r
r
a
a
d
d
o
o
e
e
v
v
e
e
n
n
t
t
o
o
S
S
e
e
c
c
r
r
e
e
t
t
á
á
r
r
i
i
a
a
c
c
a
a
d
d
a
a
s
s
t
t
r
r
a
a
c
c
o
o
m
m
i
i
t
t
ê
ê
c
c
i
i
e
e
n
n
t
t
í
í
f
f
i
i
c
c
o
o
d
d
o
o
e
e
v
v
e
e
n
n
t
t
o
o
C
C
o
o
m
m
i
i
t
t
ê
ê
c
c
i
i
e
e
n
n
t
t
í
í
f
f
i
i
c
c
o
o
s
s
e
e
l
l
e
e
c
c
i
i
o
o
n
n
a
a
t
t
r
r
a
a
b
b
a
a
l
l
h
h
o
o
s
s
C
C
o
o
m
m
i
i
s
s
s
s
ã
ã
o
o
o
o
r
r
g
g
a
a
n
n
i
i
z
z
a
a
d
d
o
o
r
r
a
a
c
c
a
a
d
d
a
a
s
s
t
t
r
r
a
a
p
p
r
r
o
o
g
g
r
r
a
a
m
m
a
a
ç
ç
ã
ã
o
o
d
d
o
o
e
e
v
v
e
e
n
n
t
t
o
o
C
C
o
o
m
m
i
i
s
s
s
s
ã
ã
o
o
c
c
o
o
n
n
f
f
e
e
c
c
c
c
i
i
o
o
n
n
a
a
c
c
r
r
a
a
c
c
h
h
á
á
s
s
d
d
o
o
e
e
v
v
e
e
n
n
t
t
o
o
P
P
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
n
n
t
t
e
e
r
r
e
e
c
c
e
e
b
b
e
e
c
c
r
r
a
a
c
c
h
h
á
á
C
C
o
o
m
m
i
i
s
s
s
s
ã
ã
o
o
e
e
l
l
a
a
b
b
o
o
r
r
a
a
c
c
e
e
r
r
t
t
i
i
f
f
i
i
c
c
a
a
d
d
o
o
s
s
d
d
e
e
p
p
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
ç
ç
ã
ã
o
o
p
p
a
a
r
r
a
a
o
o
s
s
p
p
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
n
n
t
t
e
e
s
s
c
c
o
o
m
m
,
,
n
n
o
o
m
m
í
í
n
n
i
i
m
m
o
o
,
,
8
8
5
5
%
%
d
d
e
e
p
p
r
r
e
e
s
s
e
e
n
n
ç
ç
a
a
C
C
o
o
m
m
i
i
s
s
s
s
ã
ã
o
o
c
c
a
a
d
d
a
a
s
s
t
t
r
r
a
a
m
m
i
i
n
n
i
i
s
s
t
t
r
r
a
a
n
n
t
t
e
e
C
C
o
o
m
m
i
i
s
s
s
s
ã
ã
o
o
c
c
a
a
d
d
a
a
s
s
t
t
r
r
a
a
p
p
a
a
l
l
e
e
s
s
t
t
r
r
a
a
n
n
t
t
e
e
M
M
i
i
n
n
i
i
s
s
t
t
r
r
a
a
n
n
t
t
e
e
a
a
p
p
r
r
e
e
s
s
e
e
n
n
t
t
a
a
c
c
u
u
r
r
s
s
o
o
s
s
a
a
p
p
r
r
e
e
s
s
e
e
n
n
t
t
a
a
d
d
o
o
r
r
a
a
p
p
r
r
e
e
s
s
e
e
n
n
t
t
a
a
t
t
r
r
a
a
b
b
a
a
l
l
h
h
o
o
s
s
P
P
a
a
l
l
e
e
s
s
t
t
r
r
a
a
n
n
t
t
e
e
a
a
p
p
r
r
e
e
s
s
e
e
n
n
t
t
a
a
p
p
a
a
l
l
e
e
s
s
t
t
r
r
a
a
P
P
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
n
n
t
t
e
e
r
r
e
e
c
c
e
e
b
b
e
e
c
c
e
e
r
r
t
t
i
i
f
f
i
i
c
c
a
a
d
d
o
o
s
s
d
d
e
e
p
p
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
ç
ç
ã
ã
o
o
C
C
o
o
m
m
i
i
s
s
s
s
ã
ã
o
o
c
c
a
a
d
d
a
a
s
s
t
t
r
r
a
a
p
p
a
a
t
t
r
r
o
o
c
c
i
i
n
n
a
a
d
d
o
o
r
r
e
e
s
s
d
d
o
o
e
e
v
v
e
e
n
n
t
t
o
o
O
O
u
u
v
v
i
i
n
n
t
t
e
e
e
e
/
/
o
o
u
u
a
a
p
p
r
r
e
e
s
s
e
e
n
n
t
t
a
a
d
d
o
o
r
r
e
e
f
f
e
e
t
t
u
u
a
a
p
p
a
a
g
g
a
a
m
m
e
e
n
n
t
t
o
o
d
d
o
o
e
e
v
v
e
e
n
n
t
t
o
o
T
ABELA
5.2
–
R
EQUISITOS
N
ÃO
F
UNCIONAIS E
O
RGANIZACIONAIS DO SI
STEMA
R
R
e
e
q
q
u
u
i
i
s
s
i
i
t
t
o
o
s
s
n
n
ã
ã
o
o
f
f
u
u
n
n
c
c
i
i
o
o
n
n
a
a
i
i
s
s
A
A
c
c
e
e
s
s
s
s
o
o
l
l
o
o
c
c
a
a
l
l
S
S
e
e
g
g
u
u
r
r
a
a
n
n
ç
ç
a
a
A
A
c
c
e
e
s
s
s
s
o
o
i
i
n
n
t
t
e
e
r
r
n
n
e
e
t
t
A
A
t
t
r
r
a
a
v
v
é
é
s
s
d
d
e
e
s
s
e
e
n
n
h
h
a
a
e
e
f
f
i
i
r
r
e
e
w
w
a
a
l
l
l
l
R
R
e
e
q
q
u
u
i
i
s
s
i
i
t
t
o
o
s
s
o
o
r
r
g
g
a
a
n
n
i
i
z
z
a
a
c
c
i
i
o
o
n
n
a
a
i
i
s
s
G
G
e
e
r
r
e
e
n
n
c
c
i
i
a
a
r
r
c
c
l
l
i
i
e
e
n
n
t
t
e
e
s
s
V
V
I
I
P
P
F
F
a
a
c
c
i
i
l
l
i
i
t
t
a
a
r
r
o
o
a
a
c
c
e
e
s
s
s
s
o
o
d
d
e
e
e
e
v
v
e
e
n
n
t
t
o
o
s
s
a
a
c
c
l
l
i
i
e
e
n
n
t
t
e
e
s
s
V
V
I
I
P
P
E
E
m
m
i
i
t
t
i
i
r
r
c
c
a
a
r
r
t
t
ã
ã
o
o
p
p
r
r
e
e
f
f
e
e
r
r
e
e
n
n
c
c
i
i
a
a
l
l
O
O
p
p
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
n
n
t
t
e
e
a
a
o
o
s
s
e
e
c
c
a
a
d
d
a
a
s
s
t
t
r
r
a
a
r
r
e
e
m
m
u
u
m
m
e
e
v
v
e
e
n
n
t
t
o
o
o
o
s
s
i
i
s
s
t
t
e
e
m
m
a
a
v
v
e
e
r
r
á
á
s
s
e
e
e
e
l
l
e
e
é
é
u
u
m
m
c
c
l
l
i
i
e
e
n
n
t
t
e
e
V
V
I
I
P
P
o
o
u
u
s
s
e
e
t
t
e
e
m
m
p
p
o
o
t
t
e
e
n
n
c
c
i
i
a
a
l
l
p
p
a
a
r
r
a
a
s
s
e
e
r
r
u
u
m
m
c
c
l
l
i
i
e
e
n
n
t
t
e
e
V
V
I
I
P
P
P
P
a
a
r
r
a
a
o
o
s
s
n
n
o
o
v
v
o
o
s
s
c
c
l
l
i
i
e
e
n
n
t
t
e
e
s
s
V
V
I
I
P
P
s
s
e
e
r
r
á
á
e
e
m
m
i
i
t
t
i
i
d
d
o
o
u
u
m
m
c
c
a
a
r
r
t
t
ã
ã
o
o
p
p
r
r
e
e
f
f
e
e
r
r
e
e
n
n
c
c
i
i
a
a
l
l
Nem sempre observamos os requisitos não funcionais e muitas vezes eles não
estão explícitos. A
tabela 4.
3
apresentada no Capitulo 4
pode servir de base para que
5.
Experimentação
: Controle de Eventos Científicos 118
possamos incluir os requisitos não funcionais de uma forma mais natural, uma vez que
grande parte dos requisitos não funcionais já estão listados.
Veremos
mais adiante que nossos requisitos não funcionais e organizacionais
ser
ão incluídos de maneira distintas dos requisitos funcionais.
No Anexo E demonstramos a inclusão do Léxico através da ferramenta
CALEL
, cuja Figura 5.1 demonstra a tela
:
F
IGURA
5.1
–
M
ENU
P
RINCIPAL DA FERRAMEN
TA
CALEL
.
5
5
.
.
4
4
F
F
a
a
s
s
e
e
2
2
-
-
C
C
o
o
n
n
s
s
t
t
r
r
u
u
i
i
n
n
d
d
o
o
o
o
l
l
é
é
x
x
i
i
c
c
o
o
Para a construção do léxico iremos, primeiramente incluir os requisitos
funcionais do sistema. A Figura 5.2 apresenta a tela de inclusão do léxico.
5.
Experimentação
: Controle de Eventos Científicos 119
F
IGURA
5.2
–
T
ELA DE INCLUSÃO DO
LEL
Para a construção do léxico, primeiramente
incluímos
os r
equisitos funcionais
do sistema. A Figura 5.2 apresenta a tela de inclusão do léxico.
Os símbolos
apresentados na Tabela 5.
3
foram identificados nos requisitos
funcionais para a inclusão no LEL.
T
ABELA
5.
3 – S
ÍMBOLOS DO
LEL
ENCONTRADOS NOS REQ
UISITOS FUN
CIONAIS
tipo
Descrição
Sujeito
Secretária/Auxiliar, Participante, ouvinte, ministrante, palestrante,
apresentador, fornecedor/patrocinador/parceiro
, comissão
organizadora/comissão, comitê científico/comitê
, cliente inscrito
/cliente
cadastrado
, cliente
/cliente em potencial
Estado
Em aberto
/aberto/abertos
, fechado
/fechados
Objeto
Evento, trabalhos/trabalho,
programação/programa, crachá/crachás,
certificado/certificados/certificado de participação, pagamento,
recursos/recurso, material de aula, slides/palestra, inscrição
Verbo
Incluir cliente/cadastrar cliente/cliente cadastrado, consultar eventos em
aberto, consultar eventos fechados, alterar participante, excluir participante,
consultar participante, cadastrar comissão, cadastrar comitê, receber
recur
sos, distribuir recursos, pagar fornecedor,
efetuar
inscrição,
efetuar
pagamento, enviar material, enviar requisição, enviar trabalho,
enviar
palestra,
fornecer recursos, receber pagamento
, s
elecionar ministrante,
selecionar palestrante, emitir crachás, em
itir certificados, elaborar
programação,
c
adastrar parceiros, solicitar inscrição
5.
Experimentação
: Controle de Eventos Científicos 120
A tabela 5.
4
possui em detalhes as entradas do LEL correspondente aos
símbolos encontrados na tabela 5.
3
, vale observar que o termo sublinhado indica que faz
parte do própr
io léxico.
T
ABELA
5.
4 – S
ÍMBOLOS DO
LEL
DETALHADO
R
R
e
e
q
q
u
u
i
i
s
s
i
i
t
t
o
o
s
s
f
f
u
u
n
n
c
c
i
i
o
o
n
n
a
a
i
i
s
s
S
S
í
í
m
m
b
b
o
o
l
l
o
o
S
S
e
e
c
c
r
r
e
e
t
t
a
a
r
r
i
i
a
a
/
/
A
A
u
u
x
x
i
i
l
l
i
i
a
a
r
r
C
C
a
a
t
t
e
e
g
g
o
o
r
r
i
i
a
a
S
S
u
u
j
j
e
e
i
i
t
t
o
o
N
N
o
o
ç
ç
ã
ã
o
o
P
P
e
e
s
s
s
s
o
o
a
a
q
q
u
u
e
e
a
a
u
u
x
x
i
i
l
l
i
i
a
a
n
n
o
o
g
g
e
e
r
r
e
e
n
n
c
c
i
i
a
a
m
m
e
e
n
n
t
t
o
o
d
d
o
o
e
e
v
v
e
e
n
n
t
t
o
o
I
I
m
m
p
p
a
a
c
c
t
t
o
o
A
A
ç
ç
õ
õ
e
e
s
s
q
q
u
u
e
e
e
e
x
x
e
e
c
c
u
u
t
t
a
a
:
:
1
1
.
.
c
c
a
a
d
d
a
a
s
s
t
t
r
r
a
a
r
r
c
c
l
l
i
i
e
e
n
n
t
t
e
e
,
,
2
2
.
.
c
c
o
o
n
n
s
s
u
u
l
l
t
t
a
a
r
r
e
e
v
v
e
e
n
n
t
t
o
o
s
s
e
e
m
m
a
a
b
b
e
e
r
r
t
t
o
o
3
3
.
.
c
c
o
o
n
n
s
s
u
u
l
l
t
t
a
a
r
r
e
e
v
v
e
e
n
n
t
t
o
o
s
s
f
f
e
e
c
c
h
h
a
a
d
d
o
o
s
s
4
4
.
.
a
a
l
l
t
t
e
e
r
r
a
a
r
r
p
p
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
n
n
t
t
e
e
5
5
.
.
e
e
x
x
c
c
l
l
u
u
i
i
r
r
p
p
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
n
n
t
t
e
e
6
6
.
.
c
c
o
o
n
n
s
s
u
u
l
l
t
t
a
a
r
r
p
p
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
n
n
t
t
e
e
s
s
7
7
.
.
c
c
a
a
d
d
a
a
s
s
t
t
r
r
a
a
r
r
e
e
v
v
e
e
n
n
t
t
o
o
8
8
.
.
c
c
a
a
d
d
a
a
s
s
t
t
r
r
a
a
r
r
c
c
o
o
m
m
i
i
s
s
s
s
ã
ã
o
o
9
9
.
.
c
c
a
a
d
d
a
a
s
s
t
t
r
r
a
a
r
r
c
c
o
o
m
m
i
i
t
t
ê
ê
1
1
0
0
.
.
r
r
e
e
c
c
e
e
b
b
e
e
r
r
r
r
e
e
c
c
u
u
r
r
s
s
o
o
s
s
1
1
1
1
.
.
p
p
a
a
g
g
a
a
r
r
f
f
o
o
r
r
n
n
e
e
c
c
e
e
d
d
o
o
r
r
1
1
2
2
.
.
d
d
i
i
s
s
t
t
r
r
i
i
b
b
u
u
i
i
r
r
r
r
e
e
c
c
u
u
r
r
s
s
o
o
s
s
1
1
3
3
.
.
r
r
e
e
c
c
e
e
b
b
e
e
r
r
p
p
a
a
g
g
a
a
m
m
e
e
n
n
t
t
o
o
S
S
í
í
m
m
b
b
o
o
l
l
o
o
P
P
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
n
n
t
t
e
e
C
C
a
a
t
t
e
e
g
g
o
o
r
r
i
i
a
a
S
S
u
u
j
j
e
e
i
i
t
t
o
o
N
N
o
o
ç
ç
ã
ã
o
o
P
P
e
e
s
s
s
s
o
o
a
a
q
q
u
u
e
e
p
p
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
d
d
e
e
u
u
m
m
e
e
v
v
e
e
n
n
t
t
o
o
c
c
o
o
m
m
o
o
:
:
o
o
u
u
v
v
i
i
n
n
t
t
e
e
,
,
a
a
p
p
r
r
e
e
s
s
e
e
n
n
t
t
a
a
d
d
o
o
r
r
,
,
p
p
a
a
l
l
e
e
s
s
t
t
r
r
a
a
n
n
t
t
e
e
,
,
m
m
i
i
n
n
i
i
s
s
t
t
r
r
a
a
n
n
t
t
e
e
I
I
m
m
p
p
a
a
c
c
t
t
o
o
A
A
ç
ç
õ
õ
e
e
s
s
q
q
u
u
e
e
e
e
x
x
e
e
c
c
u
u
t
t
a
a
:
:
1
1
.
.
c
c
o
o
n
n
s
s
u
u
l
l
t
t
a
a
r
r
e
e
v
v
e
e
n
n
t
t
o
o
s
s
e
e
m
m
a
a
b
b
e
e
r
r
t
t
o
o
2
2
.
.
c
c
o
o
n
n
s
s
u
u
l
l
t
t
a
a
r
r
e
e
v
v
e
e
n
n
t
t
o
o
s
s
f
f
e
e
c
c
h
h
a
a
d
d
o
o
s
s
3
3
.
.
c
c
o
o
n
n
s
s
u
u
l
l
t
t
a
a
r
r
p
p
r
r
o
o
g
g
r
r
a
a
m
m
a
a
ç
ç
ã
ã
o
o
S
S
í
í
m
m
b
b
o
o
l
l
o
o
o
o
u
u
v
v
i
i
n
n
t
t
e
e
C
C
a
a
t
t
e
e
g
g
o
o
r
r
i
i
a
a
S
S
u
u
j
j
e
e
i
i
t
t
o
o
N
N
o
o
ç
ç
ã
ã
o
o
Cliente inscrito para assistir aos cursos, palestras
e
apresentações do
evento
I
I
m
m
p
p
a
a
c
c
t
t
o
o
A
A
ç
ç
õ
õ
e
e
s
s
q
q
u
u
e
e
e
e
x
x
e
e
c
c
u
u
t
t
a
a
:
:
1
1
.
.
e
e
f
f
e
e
t
t
u
u
a
a
r
r
p
p
a
a
g
g
a
a
m
m
e
e
n
n
t
t
o
o
S
S
í
í
m
m
b
b
o
o
l
l
o
o
C
C
l
l
i
i
e
e
n
n
t
t
e
e
i
i
n
n
s
s
c
c
r
r
i
i
t
t
o
o
/
/
c
c
l
l
i
i
e
e
n
n
t
t
e
e
c
c
a
a
d
d
a
a
s
s
t
t
r
r
a
a
d
d
o
o
C
C
a
a
t
t
e
e
g
g
o
o
r
r
i
i
a
a
S
S
u
u
j
j
e
e
i
i
t
t
o
o
N
N
o
o
ç
ç
ã
ã
o
o
P
P
e
e
s
s
s
s
o
o
a
a
q
q
u
u
e
e
s
s
o
o
l
l
i
i
c
c
i
i
t
t
o
o
u
u
o
o
c
c
a
a
d
d
a
a
s
s
t
t
r
r
o
o
e
e
f
f
o
o
i
i
a
a
p
p
r
r
o
o
v
v
a
a
d
d
a
a
,
,
r
r
e
e
c
c
e
e
b
b
e
e
n
n
d
d
o
o
o
o
s
s
e
e
u
u
l
l
o
o
g
g
i
i
n
n
e
e
s
s
e
e
n
n
h
h
a
a
I
I
m
m
p
p
a
a
c
c
t
t
o
o
A
A
ç
ç
õ
õ
e
e
s
s
q
q
u
u
e
e
e
e
x
x
e
e
c
c
u
u
t
t
a
a
:
:
1
1
.
.
i
i
n
n
s
s
c
c
r
r
e
e
v
v
e
e
-
-
s
s
e
e
e
e
m
m
e
e
v
v
e
e
n
n
t
t
o
o
s
s
2
2
.
.
c
c
o
o
n
n
s
s
u
u
l
l
t
t
a
a
r
r
e
e
v
v
e
e
n
n
t
t
o
o
s
s
a
a
b
b
e
e
r
r
t
t
o
o
s
s
3
3
.
.
c
c
o
o
n
n
s
s
u
u
l
l
t
t
a
a
r
r
e
e
v
v
e
e
n
n
t
t
o
o
s
s
f
f
e
e
c
c
h
h
a
a
d
d
o
o
s
s
4
4
.
.
c
c
o
o
n
n
s
s
u
u
l
l
t
t
a
a
r
r
p
p
r
r
o
o
g
g
r
r
a
a
m
m
a
a
ç
ç
ã
ã
o
o
5
5
.
.
e
e
n
n
v
v
i
i
a
a
r
r
t
t
r
r
a
a
b
b
a
a
l
l
h
h
o
o
s
s
6
6
.
.
e
e
f
f
e
e
t
t
u
u
a
a
r
r
p
p
a
a
g
g
a
a
m
m
e
e
n
n
t
t
o
o
S
S
í
í
m
m
b
b
o
o
l
l
o
o
P
P
a
a
l
l
e
e
s
s
t
t
r
r
a
a
n
n
t
t
e
e
C
C
a
a
t
t
e
e
g
g
o
o
r
r
i
i
a
a
S
S
u
u
j
j
e
e
i
i
t
t
o
o
N
N
o
o
ç
ç
ã
ã
o
o
Cliente inscrito
para ministrar
palestra
I
I
m
m
p
p
a
a
c
c
t
t
o
o
A
A
ç
ç
õ
õ
e
e
s
s
q
q
u
u
e
e
e
e
x
x
e
e
c
c
u
u
t
t
a
a
:
:
5.
Experimentação
: Controle de Eventos Científicos 121
1
1
.
.
e
e
n
n
v
v
i
i
a
a
r
r
p
p
a
a
l
l
e
e
s
s
t
t
r
r
a
a
S
S
í
í
m
m
b
b
o
o
l
l
o
o
M
M
i
i
n
n
i
i
s
s
t
t
r
r
a
a
n
n
t
t
e
e
C
C
a
a
t
t
e
e
g
g
o
o
r
r
i
i
a
a
S
S
u
u
j
j
e
e
i
i
t
t
o
o
N
N
o
o
ç
ç
ã
ã
o
o
Cliente inscrito
para ministrar
curso
I
I
m
m
p
p
a
a
c
c
t
t
o
o
A
A
ç
ç
õ
õ
e
e
s
s
q
q
u
u
e
e
e
e
x
x
e
e
c
c
u
u
t
t
a
a
:
:
1
1
.
.
e
e
n
n
v
v
i
i
a
a
r
r
m
m
a
a
t
t
e
e
r
r
i
i
a
a
l
l
2
2
.
.
e
e
n
n
v
v
i
i
a
a
r
r
r
r
e
e
q
q
u
u
i
i
s
s
i
i
ç
ç
ã
ã
o
o
S
S
í
í
m
m
b
b
o
o
l
l
o
o
A
A
p
p
r
r
e
e
s
s
e
e
n
n
t
t
a
a
d
d
o
o
r
r
C
C
a
a
t
t
e
e
g
g
o
o
r
r
i
i
a
a
S
S
u
u
j
j
e
e
i
i
t
t
o
o
N
N
o
o
ç
ç
ã
ã
o
o
Cliente inscrito
par
a
apresentar trabalho
I
I
m
m
p
p
a
a
c
c
t
t
o
o
A
A
ç
ç
õ
õ
e
e
s
s
q
q
u
u
e
e
e
e
x
x
e
e
c
c
u
u
t
t
a
a
:
:
1
1
.
.
e
e
n
n
v
v
i
i
a
a
r
r
t
t
r
r
a
a
b
b
a
a
l
l
h
h
o
o
S
S
í
í
m
m
b
b
o
o
l
l
o
o
C
C
o
o
m
m
i
i
s
s
s
s
ã
ã
o
o
/
/
c
c
o
o
m
m
i
i
s
s
s
s
ã
ã
o
o
o
o
r
r
g
g
a
a
n
n
i
i
z
z
a
a
d
d
o
o
r
r
a
a
C
C
a
a
t
t
e
e
g
g
o
o
r
r
i
i
a
a
S
S
u
u
j
j
e
e
i
i
t
t
o
o
N
N
o
o
ç
ç
ã
ã
o
o
G
G
r
r
u
u
p
p
o
o
d
d
e
e
p
p
e
e
s
s
s
s
o
o
a
a
s
s
s
s
e
e
l
l
e
e
c
c
i
i
o
o
n
n
a
a
d
d
a
a
s
s
p
p
a
a
r
r
a
a
g
g
e
e
r
r
e
e
n
n
c
c
i
i
a
a
r
r
o
o
e
e
v
v
e
e
n
n
t
t
o
o
.
.
I
I
m
m
p
p
a
a
c
c
t
t
o
o
A
A
ç
ç
õ
õ
e
e
s
s
q
q
u
u
e
e
e
e
x
x
e
e
c
c
u
u
t
t
a
a
:
:
1
1
.
.
S
S
e
e
l
l
e
e
c
c
i
i
o
o
n
n
a
a
r
r
m
m
i
i
n
n
i
i
s
s
t
t
r
r
a
a
n
n
t
t
e
e
,
,
2
2
.
.
S
S
e
e
l
l
e
e
c
c
i
i
o
o
n
n
a
a
r
r
p
p
a
a
l
l
e
e
s
s
t
t
r
r
a
a
n
n
t
t
e
e
,
,
3
3
.
.
E
E
m
m
i
i
t
t
i
i
r
r
c
c
r
r
a
a
c
c
h
h
á
á
s
s
,
,
4
4
.
.
E
E
m
m
i
i
t
t
i
i
r
r
c
c
e
e
r
r
t
t
i
i
f
f
i
i
c
c
a
a
d
d
o
o
s
s
5
5
.
.
C
C
o
o
n
n
s
s
u
u
l
l
t
t
a
a
r
r
p
p
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
n
n
t
t
e
e
s
s
6
6
.
.
E
E
l
l
a
a
b
b
o
o
r
r
a
a
r
r
p
p
r
r
o
o
g
g
r
r
a
a
m
m
a
a
ç
ç
ã
ã
o
o
7
7
.
.
C
C
a
a
d
d
a
a
s
s
t
t
r
r
a
a
r
r
p
p
a
a
r
r
c
c
e
e
i
i
r
r
o
o
s
s
S
S
í
í
m
m
b
b
o
o
l
l
o
o
C
C
o
o
m
m
i
i
t
t
ê
ê
/
/
c
c
o
o
m
m
i
i
t
t
ê
ê
c
c
i
i
e
e
n
n
t
t
í
í
f
f
i
i
c
c
o
o
C
C
a
a
t
t
e
e
g
g
o
o
r
r
i
i
a
a
S
S
u
u
j
j
e
e
i
i
t
t
o
o
N
N
o
o
ç
ç
ã
ã
o
o
G
G
r
r
u
u
p
p
o
o
d
d
e
e
p
p
e
e
s
s
s
s
o
o
a
a
s
s
s
s
e
e
l
l
e
e
c
c
i
i
o
o
n
n
a
a
d
d
a
a
s
s
p
p
a
a
r
r
a
a
s
s
e
e
l
l
e
e
c
c
i
i
o
o
n
n
a
a
r
r
o
o
s
s
t
t
r
r
a
a
b
b
a
a
l
l
h
h
o
o
s
s
a
a
p
p
r
r
e
e
s
s
e
e
n
n
t
t
a
a
d
d
o
o
s
s
n
n
o
o
e
e
v
v
e
e
n
n
t
t
o
o
.
.
I
I
m
m
p
p
a
a
c
c
t
t
o
o
A
A
ç
ç
õ
õ
e
e
s
s
q
q
u
u
e
e
e
e
x
x
e
e
c
c
u
u
t
t
a
a
:
:
1
1
.
.
S
S
e
e
l
l
e
e
c
c
i
i
o
o
n
n
a
a
r
r
t
t
r
r
a
a
b
b
a
a
l
l
h
h
o
o
s
s
2
2
.
.
A
A
l
l
t
t
e
e
r
r
a
a
r
r
p
p
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
n
n
t
t
e
e
S
S
í
í
m
m
b
b
o
o
l
l
o
o
P
P
a
a
r
r
c
c
e
e
i
i
r
r
o
o
s
s
/
/
P
P
a
a
r
r
c
c
e
e
i
i
r
r
o
o
/
/
F
F
o
o
r
r
n
n
e
e
c
c
e
e
d
d
o
o
r
r
/
/
P
P
a
a
t
t
r
r
o
o
c
c
i
i
n
n
a
a
d
d
o
o
r
r
C
C
a
a
t
t
e
e
g
g
o
o
r
r
i
i
a
a
S
S
u
u
j
j
e
e
i
i
t
t
o
o
N
N
o
o
ç
ç
ã
ã
o
o
E
E
m
m
p
p
r
r
e
e
s
s
a
a
s
s
q
q
u
u
e
e
f
f
o
o
r
r
n
n
e
e
c
c
e
e
m
m
r
r
e
e
c
c
u
u
r
r
s
s
o
o
s
s
(
(
m
m
a
a
t
t
e
e
r
r
i
i
a
a
i
i
s
s
,
,
f
f
i
i
n
n
a
a
n
n
c
c
e
e
i
i
r
r
o
o
s
s
o
o
u
u
h
h
u
u
m
m
a
a
n
n
o
o
s
s
)
)
p
p
a
a
r
r
a
a
a
a
r
r
e
e
a
a
l
l
i
i
z
z
a
a
ç
ç
ã
ã
o
o
d
d
o
o
e
e
v
v
e
e
n
n
t
t
o
o
I
I
m
m
p
p
a
a
c
c
t
t
o
o
A
A
ç
ç
õ
õ
e
e
s
s
q
q
u
u
e
e
e
e
x
x
e
e
c
c
u
u
t
t
a
a
:
:
1
1
.
.
F
F
o
o
r
r
n
n
e
e
c
c
e
e
r
r
r
r
e
e
c
c
u
u
r
r
s
s
o
o
s
s
2
2
.
.
c
c
o
o
n
n
s
s
u
u
l
l
t
t
a
a
r
r
e
e
v
v
e
e
n
n
t
t
o
o
s
s
3
3
.
.
c
c
o
o
n
n
s
s
u
u
l
l
t
t
a
a
r
r
p
p
r
r
o
o
g
g
r
r
a
a
m
m
a
a
ç
ç
ã
ã
o
o
S
S
í
í
m
m
b
b
o
o
l
l
o
o
F
F
o
o
r
r
n
n
e
e
c
c
e
e
d
d
o
o
r
r
C
C
a
a
t
t
e
e
g
g
o
o
r
r
i
i
a
a
S
S
u
u
j
j
e
e
i
i
t
t
o
o
N
N
o
o
ç
ç
ã
ã
o
o
E
E
m
m
p
p
r
r
e
e
s
s
a
a
s
s
q
q
u
u
e
e
f
f
o
o
r
r
n
n
e
e
c
c
e
e
m
m
r
r
e
e
c
c
u
u
r
r
s
s
o
o
s
s
m
m
a
a
t
t
e
e
r
r
i
i
a
a
i
i
s
s
e
e
/
/
o
o
u
u
h
h
u
u
m
m
a
a
n
n
o
o
s
s
p
p
a
a
r
r
a
a
a
a
r
r
e
e
a
a
l
l
i
i
z
z
a
a
ç
ç
ã
ã
o
o
d
d
o
o
e
e
v
v
e
e
n
n
t
t
o
o
I
I
m
m
p
p
a
a
c
c
t
t
o
o
A
A
ç
ç
õ
õ
e
e
s
s
q
q
u
u
e
e
e
e
x
x
e
e
c
c
u
u
t
t
a
a
:
:
1
1
.
.
r
r
e
e
c
c
e
e
b
b
e
e
r
r
p
p
a
a
g
g
a
a
m
m
e
e
n
n
t
t
o
o
_
_
r
r
e
e
c
c
u
u
r
r
s
s
o
o
S
S
í
í
m
m
b
b
o
o
l
l
o
o
E
E
v
v
e
e
n
n
t
t
o
o
/
/
e
e
v
v
e
e
n
n
t
t
o
o
s
s
C
C
a
a
t
t
e
e
g
g
o
o
r
r
i
i
a
a
O
O
b
b
j
j
e
e
t
t
o
o
N
N
o
o
ç
ç
ã
ã
o
o
C
C
o
o
n
n
f
f
e
e
r
r
e
e
n
n
c
c
i
i
a
a
o
o
u
u
W
W
o
o
r
r
k
k
s
s
h
h
o
o
p
p
a
a
s
s
e
e
r
r
g
g
e
e
r
r
e
e
n
n
c
c
i
i
a
a
d
d
o
o
p
p
e
e
l
l
a
a
e
e
m
m
p
p
r
r
e
e
s
s
a
a
.
.
C
C
a
a
d
d
a
a
e
e
v
v
e
e
n
n
t
t
o
o
p
p
o
o
s
s
s
s
u
u
i
i
u
u
m
m
p
p
e
e
r
r
í
í
o
o
d
d
o
o
d
d
e
e
r
r
e
e
a
a
l
l
i
i
z
z
a
a
ç
ç
ã
ã
o
o
.
.
É
É
c
c
o
o
m
m
p
p
o
o
s
s
t
t
o
o
d
d
e
e
u
u
m
m
a
a
o
o
u
u
m
m
a
a
i
i
s
s
p
p
a
a
l
l
e
e
s
s
t
t
r
r
a
a
s
s
,
,
c
c
u
u
r
r
s
s
o
o
s
s
e
e
t
t
r
r
a
a
b
b
a
a
l
l
h
h
o
o
s
s
I
I
m
m
p
p
a
a
c
c
t
t
o
o
1
1
.
.
C
C
l
l
i
i
e
e
n
n
t
t
e
e
i
i
n
n
s
s
c
c
r
r
i
i
t
t
o
o
p
p
o
o
d
d
e
e
i
i
n
n
s
s
c
c
r
r
e
e
v
v
e
e
r
r
-
-
s
s
e
e
e
e
m
m
e
e
v
v
e
e
n
n
t
t
o
o
2
2
.
.
O
O
e
e
v
v
e
e
n
n
t
t
o
o
e
e
s
s
t
t
á
á
a
a
b
b
e
e
r
r
t
t
o
o
o
o
u
u
f
f
e
e
c
c
h
h
a
a
d
d
o
o
S
S
í
í
m
m
b
b
o
o
l
l
o
o
T
T
r
r
a
a
b
b
a
a
l
l
h
h
o
o
s
s
/
/
t
t
r
r
a
a
b
b
a
a
l
l
h
h
o
o
C
C
a
a
t
t
e
e
g
g
o
o
r
r
i
i
a
a
O
O
b
b
j
j
e
e
t
t
o
o
N
N
o
o
ç
ç
ã
ã
o
o
A
A
r
r
t
t
i
i
g
g
o
o
s
s
a
a
s
s
e
e
r
r
e
e
m
m
a
a
p
p
r
r
e
e
s
s
e
e
n
n
t
t
a
a
d
d
o
o
s
s
e
e
m
m
u
u
m
m
e
e
v
v
e
e
n
n
t
t
o
o
5.
Experimentação
: Controle de Eventos Científicos 122
P
P
o
o
d
d
e
e
s
s
e
e
r
r
:
:
s
s
h
h
o
o
r
r
t
t
p
p
a
a
p
p
e
e
r
r
,
,
f
f
u
u
l
l
l
l
p
p
a
a
p
p
e
e
r
r
e
e
p
p
o
o
s
s
t
t
e
e
r
r
I
I
m
m
p
p
a
a
c
c
t
t
o
o
1
1
.
.
A
A
p
p
r
r
e
e
s
s
e
e
n
n
t
t
a
a
d
d
o
o
r
r
e
e
n
n
v
v
i
i
a
a
u
u
m
m
o
o
u
u
m
m
a
a
i
i
s
s
t
t
r
r
a
a
b
b
a
a
l
l
h
h
o
o
s
s
2
2
.
.
O
O
t
t
r
r
a
a
b
b
a
a
l
l
h
h
o
o
p
p
o
o
d
d
e
e
s
s
e
e
r
r
s
s
e
e
l
l
e
e
c
c
i
i
o
o
n
n
a
a
d
d
o
o
p
p
a
a
r
r
a
a
s
s
e
e
r
r
a
a
p
p
r
r
e
e
s
s
e
e
n
n
t
t
a
a
d
d
o
o
p
p
o
o
r
r
u
u
m
m
c
c
o
o
m
m
i
i
t
t
ê
ê
S
S
í
í
m
m
b
b
o
o
l
l
o
o
P
P
r
r
o
o
g
g
r
r
a
a
m
m
a
a
ç
ç
ã
ã
o
o
/
/
p
p
r
r
o
o
g
g
r
r
a
a
m
m
a
a
C
C
a
a
t
t
e
e
g
g
o
o
r
r
i
i
a
a
O
O
b
b
j
j
e
e
t
t
o
o
N
N
o
o
ç
ç
ã
ã
o
o
C
C
r
r
o
o
n
n
o
o
g
g
r
r
a
a
m
m
a
a
a
a
s
s
e
e
r
r
c
c
u
u
m
m
p
p
r
r
i
i
d
d
o
o
d
d
o
o
e
e
v
v
e
e
n
n
t
t
o
o
C
C
o
o
n
n
t
t
e
e
m
m
a
a
s
s
p
p
a
a
l
l
e
e
s
s
t
t
r
r
a
a
s
s
,
,
t
t
r
r
a
a
b
b
a
a
l
l
h
h
o
o
s
s
e
e
c
c
u
u
r
r
s
s
o
o
s
s
a
a
s
s
e
e
r
r
e
e
m
m
a
a
p
p
r
r
e
e
s
s
e
e
n
n
t
t
a
a
d
d
o
o
s
s
n
n
o
o
e
e
v
v
e
e
n
n
t
t
o
o
I
I
m
m
p
p
a
a
c
c
t
t
o
o
1
1
.
.
C
C
o
o
m
m
i
i
s
s
s
s
ã
ã
o
o
e
e
l
l
a
a
b
b
o
o
r
r
a
a
p
p
r
r
o
o
g
g
r
r
a
a
m
m
a
a
ç
ç
ã
ã
o
o
p
p
r
r
e
e
v
v
i
i
s
s
t
t
a
a
d
d
o
o
e
e
v
v
e
e
n
n
t
t
o
o
2
2
.
.
A
A
p
p
r
r
o
o
g
g
r
r
a
a
m
m
a
a
ç
ç
ã
ã
o
o
p
p
o
o
d
d
e
e
s
s
e
e
r
r
a
a
l
l
t
t
e
e
r
r
a
a
d
d
a
a
c
c
a
a
s
s
o
o
o
o
c
c
o
o
r
r
r
r
a
a
a
a
l
l
g
g
u
u
m
m
i
i
m
m
p
p
r
r
e
e
v
v
i
i
s
s
t
t
o
o
S
S
í
í
m
m
b
b
o
o
l
l
o
o
C
C
e
e
r
r
t
t
i
i
f
f
i
i
c
c
a
a
d
d
o
o
/
/
c
c
e
e
r
r
t
t
i
i
f
f
i
i
c
c
a
a
d
d
o
o
p
p
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
ç
ç
ã
ã
o
o
C
C
a
a
t
t
e
e
g
g
o
o
r
r
i
i
a
a
O
O
b
b
j
j
e
e
t
t
o
o
N
N
o
o
ç
ç
ã
ã
o
o
C
C
o
o
m
m
p
p
r
r
o
o
v
v
a
a
n
n
t
t
e
e
d
d
e
e
p
p
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
ç
ç
ã
ã
o
o
d
d
o
o
e
e
v
v
e
e
n
n
t
t
o
o
I
I
m
m
p
p
a
a
c
c
t
t
o
o
1
1
.
.
C
C
o
o
m
m
i
i
s
s
s
s
ã
ã
o
o
e
e
l
l
a
a
b
b
o
o
r
r
a
a
c
c
e
e
r
r
t
t
i
i
f
f
i
i
c
c
a
a
d
d
o
o
s
s
p
p
a
a
r
r
a
a
o
o
s
s
p
p
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
n
n
t
t
e
e
s
s
2
2
.
.
C
C
e
e
r
r
t
t
i
i
f
f
i
i
c
c
a
a
d
d
o
o
s
s
s
s
e
e
r
r
ã
ã
o
o
e
e
n
n
t
t
r
r
e
e
g
g
u
u
e
e
s
s
n
n
o
o
u
u
l
l
t
t
i
i
m
m
o
o
d
d
i
i
a
a
d
d
o
o
e
e
v
v
e
e
n
n
t
t
o
o
o
o
u
u
v
v
i
i
a
a
c
c
o
o
r
r
r
r
e
e
i
i
o
o
S
S
í
í
m
m
b
b
o
o
l
l
o
o
C
C
r
r
a
a
c
c
h
h
á
á
s
s
/
/
c
c
r
r
a
a
c
c
h
h
á
á
C
C
a
a
t
t
e
e
g
g
o
o
r
r
i
i
a
a
O
O
b
b
j
j
e
e
t
t
o
o
N
N
o
o
ç
ç
ã
ã
o
o
I
I
d
d
e
e
n
n
t
t
i
i
f
f
i
i
c
c
a
a
ç
ç
ã
ã
o
o
d
d
o
o
p
p
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
n
n
t
t
e
e
d
d
o
o
e
e
v
v
e
e
n
n
t
t
o
o
I
I
m
m
p
p
a
a
c
c
t
t
o
o
1
1
.
.
C
C
o
o
m
m
i
i
s
s
s
s
ã
ã
o
o
e
e
m
m
i
i
t
t
e
e
c
c
r
r
a
a
c
c
h
h
á
á
s
s
p
p
a
a
r
r
a
a
o
o
s
s
p
p
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
n
n
t
t
e
e
s
s
2
2
.
.
C
C
r
r
a
a
c
c
h
h
á
á
s
s
s
s
e
e
r
r
ã
ã
o
o
e
e
n
n
t
t
r
r
e
e
g
g
u
u
e
e
s
s
n
n
o
o
p
p
r
r
i
i
m
m
e
e
i
i
r
r
o
o
d
d
i
i
a
a
d
d
o
o
e
e
v
v
e
e
n
n
t
t
o
o
3
3
.
.
C
C
r
r
a
a
c
c
h
h
á
á
s
s
s
s
ã
ã
o
o
r
r
e
e
c
c
e
e
b
b
i
i
d
d
o
o
s
s
p
p
e
e
l
l
o
o
s
s
p
p
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
n
n
t
t
e
e
s
s
S
S
í
í
m
m
b
b
o
o
l
l
o
o
P
P
a
a
g
g
a
a
m
m
e
e
n
n
t
t
o
o
C
C
a
a
t
t
e
e
g
g
o
o
r
r
i
i
a
a
O
O
b
b
j
j
e
e
t
t
o
o
N
N
o
o
ç
ç
ã
ã
o
o
Comprovante de quitação com o
evento
I
I
m
m
p
p
a
a
c
c
t
t
o
o
1
1
.
.
O
O
u
u
v
v
i
i
n
n
t
t
e
e
/
/
p
p
a
a
l
l
e
e
s
s
t
t
r
r
a
a
n
n
t
t
e
e
e
e
n
n
t
t
r
r
e
e
g
g
a
a
c
c
o
o
p
p
i
i
a
a
d
d
o
o
p
p
a
a
g
g
a
a
m
m
e
e
n
n
t
t
o
o
e
e
f
f
e
e
t
t
u
u
a
a
d
d
o
o
v
v
i
i
a
a
e
e
-
-
m
m
a
a
i
i
l
l
,
,
c
c
o
o
r
r
r
r
e
e
i
i
o
o
,
,
o
o
u
u
n
n
o
o
p
p
r
r
i
i
m
m
e
e
i
i
r
r
o
o
d
d
i
i
a
a
d
d
o
o
e
e
v
v
e
e
n
n
t
t
o
o
S
S
í
í
m
m
b
b
o
o
l
l
o
o
R
R
e
e
c
c
u
u
r
r
s
s
o
o
s
s
/
/
r
r
e
e
c
c
u
u
r
r
s
s
o
o
C
C
a
a
t
t
e
e
g
g
o
o
r
r
i
i
a
a
O
O
b
b
j
j
e
e
t
t
o
o
N
N
o
o
ç
ç
ã
ã
o
o
São materiais necessários para a realização e elaboração do
evento
.
Podem ser: financeiro, humano e material
I
I
m
m
p
p
a
a
c
c
t
t
o
o
O
O
s
s
r
r
e
e
c
c
u
u
r
r
s
s
o
o
s
s
f
f
i
i
n
n
a
a
n
n
c
c
e
e
i
i
r
r
o
o
s
s
s
s
ã
ã
o
o
d
d
i
i
s
s
p
p
o
o
n
n
i
i
b
b
i
i
l
l
i
i
z
z
a
a
d
d
o
o
s
s
a
a
n
n
t
t
e
e
s
s
d
d
o
o
s
s
r
r
e
e
c
c
u
u
r
r
s
s
o
o
s
s
m
m
a
a
t
t
e
e
r
r
i
i
a
a
i
i
s
s
e
e
h
h
u
u
m
m
a
a
n
n
o
o
s
s
S
S
í
í
m
m
b
b
o
o
l
l
o
o
M
M
a
a
t
t
e
e
r
r
i
i
a
a
l
l
/
/
m
m
a
a
t
t
e
e
r
r
i
i
a
a
i
i
s
s
C
C
a
a
t
t
e
e
g
g
o
o
r
r
i
i
a
a
O
O
b
b
j
j
e
e
t
t
o
o
N
N
o
o
ç
ç
ã
ã
o
o
O
O
m
m
a
a
t
t
e
e
r
r
i
i
a
a
l
l
r
r
e
e
f
f
e
e
r
r
e
e
n
n
t
t
e
e
a
a
o
o
c
c
u
u
r
r
s
s
o
o
a
a
s
s
e
e
r
r
m
m
i
i
n
n
i
i
s
s
t
t
r
r
a
a
d
d
o
o
e
e
m
m
u
u
m
m
e
e
v
v
e
e
n
n
t
t
o
o
I
I
m
m
p
p
a
a
c
c
t
t
o
o
1
1
.
.
M
M
i
i
n
n
i
i
s
s
t
t
r
r
a
a
n
n
t
t
e
e
e
e
n
n
v
v
i
i
a
a
u
u
m
m
o
o
u
u
m
m
a
a
i
i
s
s
m
m
a
a
t
t
e
e
r
r
i
i
a
a
i
i
s
s
2
2
.
.
O
O
m
m
a
a
t
t
e
e
r
r
i
i
a
a
l
l
p
p
o
o
d
d
e
e
s
s
e
e
r
r
s
s
e
e
l
l
e
e
c
c
i
i
o
o
n
n
a
a
d
d
o
o
p
p
o
o
r
r
u
u
m
m
c
c
o
o
m
m
i
i
t
t
ê
ê
S
S
í
í
m
m
b
b
o
o
l
l
o
o
P
P
a
a
l
l
e
e
s
s
t
t
r
r
a
a
C
C
a
a
t
t
e
e
g
g
o
o
r
r
i
i
a
a
O
O
b
b
j
j
e
e
t
t
o
o
N
N
o
o
ç
ç
ã
ã
o
o
Slides referentes a um assunto a ser apresentado no evento
I
I
m
m
p
p
a
a
c
c
t
t
o
o
1
1
.
.
P
P
a
a
l
l
e
e
s
s
t
t
r
r
a
a
n
n
t
t
e
e
e
e
n
n
v
v
i
i
a
a
u
u
m
m
a
a
o
o
u
u
m
m
a
a
i
i
s
s
p
p
a
a
l
l
e
e
s
s
t
t
r
r
a
a
s
s
2
2
.
.
A
A
p
p
a
a
l
l
e
e
s
s
t
t
r
r
a
a
p
p
o
o
d
d
e
e
s
s
e
e
r
r
s
s
e
e
l
l
e
e
c
c
i
i
o
o
n
n
a
a
d
d
a
a
p
p
o
o
r
r
u
u
m
m
c
c
o
o
m
m
i
i
t
t
ê
ê
S
S
í
í
m
m
b
b
o
o
l
l
o
o
R
R
e
e
q
q
u
u
i
i
s
s
i
i
ç
ç
ã
ã
o
o
C
C
a
a
t
t
e
e
g
g
o
o
r
r
i
i
a
a
O
O
b
b
j
j
e
e
t
t
o
o
N
N
o
o
ç
ç
ã
ã
o
o
Documento que contem referencias aos recursos materiais necessários para
r
ealizar a tarefa
I
I
m
m
p
p
a
a
c
c
t
t
o
o
1
1
.
.
M
M
i
i
n
n
i
i
s
s
t
t
r
r
a
a
n
n
t
t
e
e
e
e
n
n
v
v
i
i
a
a
a
a
p
p
e
e
n
n
a
a
s
s
u
u
m
m
a
a
r
r
e
e
q
q
u
u
i
i
s
s
i
i
ç
ç
ã
ã
o
o
S
S
í
í
m
m
b
b
o
o
l
l
o
o
C
C
a
a
d
d
a
a
s
s
t
t
r
r
a
a
r
r
c
c
l
l
i
i
e
e
n
n
t
t
e
e
C
C
a
a
t
t
e
e
g
g
o
o
r
r
i
i
a
a
V
V
e
e
r
r
b
b
o
o
N
N
o
o
ç
ç
ã
ã
o
o
A
A
ç
ç
ã
ã
o
o
r
r
e
e
a
a
l
l
i
i
z
z
a
a
d
d
a
a
p
p
e
e
l
l
a
a
s
s
e
e
c
c
r
r
e
e
t
t
á
á
r
r
i
i
a
a
A
A
c
c
o
o
n
n
t
t
e
e
c
c
e
e
q
q
u
u
a
a
n
n
d
d
o
o
:
:
a
a
p
p
e
e
s
s
s
s
o
o
a
a
s
s
o
o
l
l
i
i
c
c
i
i
t
t
a
a
s
s
e
e
u
u
c
c
a
a
d
d
a
a
s
s
t
t
r
r
o
o
c
c
o
o
m
m
o
o
c
c
l
l
i
i
e
e
n
n
t
t
e
e
i
i
n
n
s
s
c
c
r
r
i
i
t
t
o
o
P
P
r
r
é
é
-
-
c
c
o
o
n
n
d
d
:
:
1
1
.
.
P
P
e
e
s
s
s
s
o
o
a
a
i
i
n
n
t
t
e
e
r
r
e
e
s
s
s
s
a
a
d
d
a
a
e
e
n
n
v
v
i
i
a
a
s
s
e
e
u
u
s
s
d
d
a
a
d
d
o
o
s
s
c
c
a
a
d
d
a
a
s
s
t
t
r
r
a
a
i
i
s
s
2
2
.
.
S
S
e
e
c
c
r
r
e
e
t
t
á
á
r
r
i
i
a
a
r
r
e
e
c
c
e
e
b
b
e
e
o
o
s
s
d
d
a
a
d
d
o
o
s
s
e
e
r
r
e
e
a
a
l
l
i
i
z
z
a
a
a
a
n
n
á
á
l
l
i
i
s
s
e
e
.
.
I
I
n
n
f
f
o
o
r
r
m
m
a
a
ç
ç
õ
õ
e
e
s
s
s
s
ã
ã
o
o
a
a
p
p
r
r
o
o
v
v
a
a
d
d
a
a
s
s
I
I
m
m
p
p
a
a
c
c
t
t
o
o
1
1
.
.
C
C
l
l
i
i
e
e
n
n
t
t
e
e
e
e
s
s
t
t
á
á
c
c
a
a
d
d
a
a
s
s
t
t
r
r
a
a
d
d
o
o
2
2
.
.
S
S
e
e
o
o
c
c
l
l
i
i
e
e
n
n
t
t
e
e
e
e
s
s
t
t
á
á
c
c
a
a
d
d
a
a
s
s
t
t
r
r
a
a
d
d
o
o
a
a
s
s
e
e
c
c
r
r
e
e
t
t
á
á
r
r
i
i
a
a
n
n
ã
ã
o
o
p
p
o
o
d
d
e
e
c
c
a
a
d
d
a
a
s
s
t
t
r
r
á
á
-
-
l
l
o
o
.
.
5.
Experimentação
: Controle de Eventos Científicos 123
P
P
ó
ó
s
s
-
-
c
c
o
o
n
n
d
d
:
:
1
1
.
.
S
S
e
e
c
c
r
r
e
e
t
t
á
á
r
r
i
i
a
a
e
e
n
n
v
v
i
i
a
a
l
l
o
o
g
g
i
i
n
n
e
e
s
s
e
e
n
n
h
h
a
a
p
p
a
a
r
r
a
a
o
o
c
c
l
l
i
i
e
e
n
n
t
t
e
e
i
i
n
n
s
s
c
c
r
r
i
i
t
t
o
o
.
.
S
S
í
í
m
m
b
b
o
o
l
l
o
o
C
C
o
o
n
n
s
s
u
u
l
l
t
t
a
a
r
r
e
e
v
v
e
e
n
n
t
t
o
o
s
s
e
e
m
m
a
a
b
b
e
e
r
r
t
t
o
o
/
/
e
e
v
v
e
e
n
n
t
t
o
o
s
s
e
e
m
m
a
a
b
b
e
e
r
r
t
t
o
o
s
s
ã
ã
o
o
c
c
o
o
n
n
s
s
u
u
l
l
t
t
a
a
d
d
o
o
s
s
C
C
a
a
t
t
e
e
g
g
o
o
r
r
i
i
a
a
V
V
e
e
r
r
b
b
o
o
N
N
o
o
ç
ç
ã
ã
o
o
A
A
ç
ç
ã
ã
o
o
r
r
e
e
a
a
l
l
i
i
z
z
a
a
d
d
a
a
p
p
e
e
l
l
a
a
s
s
e
e
c
c
r
r
e
e
t
t
á
á
r
r
i
i
a
a
,
,
p
p
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
n
n
t
t
e
e
,
,
p
p
a
a
r
r
c
c
e
e
i
i
r
r
o
o
s
s
,
,
c
c
l
l
i
i
e
e
n
n
t
t
e
e
s
s
c
c
a
a
d
d
a
a
s
s
t
t
r
r
a
a
d
d
o
o
s
s
,
,
c
c
l
l
i
i
e
e
n
n
t
t
e
e
s
s
A
A
c
c
o
o
n
n
t
t
e
e
c
c
e
e
q
q
u
u
a
a
n
n
d
d
o
o
:
:
a
a
p
p
e
e
s
s
s
s
o
o
a
a
/
/
e
e
m
m
p
p
r
r
e
e
s
s
a
a
d
d
e
e
s
s
e
e
j
j
a
a
s
s
a
a
b
b
e
e
r
r
q
q
u
u
a
a
i
i
s
s
o
o
s
s
e
e
v
v
e
e
n
n
t
t
o
o
s
s
e
e
s
s
t
t
ã
ã
o
o
a
a
a
a
c
c
o
o
n
n
t
t
e
e
c
c
e
e
r
r
I
I
m
m
p
p
a
a
c
c
t
t
o
o
1
1
.
.
E
E
v
v
e
e
n
n
t
t
o
o
s
s
f
f
o
o
r
r
a
a
m
m
c
c
o
o
n
n
s
s
u
u
l
l
t
t
a
a
d
d
o
o
s
s
.
.
P
P
ó
ó
s
s
-
-
c
c
o
o
n
n
d
d
:
:
S
S
í
í
m
m
b
b
o
o
l
l
o
o
C
C
o
o
n
n
s
s
u
u
l
l
t
t
a
a
r
r
e
e
v
v
e
e
n
n
t
t
o
o
s
s
f
f
e
e
c
c
h
h
a
a
d
d
o
o
s
s
/
/
e
e
v
v
e
e
n
n
t
t
o
o
s
s
f
f
e
e
c
c
h
h
a
a
d
d
o
o
s
s
s
s
ã
ã
o
o
c
c
o
o
n
n
s
s
u
u
l
l
t
t
a
a
d
d
o
o
s
s
C
C
a
a
t
t
e
e
g
g
o
o
r
r
i
i
a
a
V
V
e
e
r
r
b
b
o
o
N
N
o
o
ç
ç
ã
ã
o
o
A
A
ç
ç
ã
ã
o
o
r
r
e
e
a
a
l
l
i
i
z
z
a
a
d
d
a
a
p
p
e
e
l
l
a
a
s
s
e
e
c
c
r
r
e
e
t
t
á
á
r
r
i
i
a
a
,
,
p
p
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
n
n
t
t
e
e
,
,
p
p
a
a
r
r
c
c
e
e
i
i
r
r
o
o
s
s
,
,
c
c
l
l
i
i
e
e
n
n
t
t
e
e
s
s
c
c
a
a
d
d
a
a
s
s
t
t
r
r
a
a
d
d
o
o
s
s
,
,
c
c
l
l
i
i
e
e
n
n
t
t
e
e
s
s
A
A
c
c
o
o
n
n
t
t
e
e
c
c
e
e
q
q
u
u
a
a
n
n
d
d
o
o
:
:
a
a
p
p
e
e
s
s
s
s
o
o
a
a
/
/
e
e
m
m
p
p
r
r
e
e
s
s
a
a
d
d
e
e
s
s
e
e
j
j
a
a
s
s
a
a
b
b
e
e
r
r
q
q
u
u
a
a
i
i
s
s
o
o
s
s
e
e
v
v
e
e
n
n
t
t
o
o
s
s
a
a
c
c
o
o
n
n
t
t
e
e
c
c
e
e
r
r
a
a
m
m
I
I
m
m
p
p
a
a
c
c
t
t
o
o
1
1
.
.
E
E
v
v
e
e
n
n
t
t
o
o
s
s
f
f
o
o
r
r
a
a
m
m
c
c
o
o
n
n
s
s
u
u
l
l
t
t
a
a
d
d
o
o
s
s
.
.
S
S
í
í
m
m
b
b
o
o
l
l
o
o
A
A
l
l
t
t
e
e
r
r
a
a
r
r
p
p
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
n
n
t
t
e
e
/
/
p
p
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
n
n
t
t
e
e
a
a
l
l
t
t
e
e
r
r
a
a
d
d
o
o
C
C
a
a
t
t
e
e
g
g
o
o
r
r
i
i
a
a
V
V
e
e
r
r
b
b
o
o
N
N
o
o
ç
ç
ã
ã
o
o
A
A
ç
ç
ã
ã
o
o
r
r
e
e
a
a
l
l
i
i
z
z
a
a
d
d
a
a
p
p
e
e
l
l
a
a
s
s
e
e
c
c
r
r
e
e
t
t
á
á
r
r
i
i
a
a
,
,
c
c
o
o
m
m
i
i
t
t
ê
ê
A
A
c
c
o
o
n
n
t
t
e
e
c
c
e
e
q
q
u
u
a
a
n
n
d
d
o
o
:
:
o
o
p
p
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
n
n
t
t
e
e
d
d
e
e
o
o
u
u
v
v
i
i
n
n
t
t
e
e
p
p
a
a
s
s
s
s
a
a
a
a
s
s
e
e
r
r
u
u
m
m
a
a
p
p
r
r
e
e
s
s
e
e
n
n
t
t
a
a
d
d
o
o
r
r
P
P
r
r
é
é
-
-
c
c
o
o
n
n
d
d
:
:
1
1
.
.
P
P
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
n
n
t
t
e
e
e
e
s
s
t
t
á
á
c
c
a
a
d
d
a
a
s
s
t
t
r
r
a
a
d
d
o
o
n
n
o
o
e
e
v
v
e
e
n
n
t
t
o
o
c
c
o
o
m
m
o
o
o
o
u
u
v
v
i
i
n
n
t
t
e
e
2
2
.
.
C
C
o
o
m
m
i
i
t
t
ê
ê
s
s
e
e
l
l
e
e
c
c
i
i
o
o
n
n
a
a
t
t
r
r
a
a
b
b
a
a
l
l
h
h
o
o
d
d
o
o
o
o
u
u
v
v
i
i
n
n
t
t
e
e
I
I
m
m
p
p
a
a
c
c
t
t
o
o
1
1
.
.
p
p
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
n
n
t
t
e
e
e
e
s
s
t
t
á
á
a
a
l
l
t
t
e
e
r
r
a
a
d
d
o
o
.
.
S
S
í
í
m
m
b
b
o
o
l
l
o
o
E
E
x
x
c
c
l
l
u
u
i
i
r
r
p
p
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
n
n
t
t
e
e
/
/
p
p
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
n
n
t
t
e
e
e
e
x
x
c
c
l
l
u
u
i
i
d
d
o
o
C
C
a
a
t
t
e
e
g
g
o
o
r
r
i
i
a
a
V
V
e
e
r
r
b
b
o
o
N
N
o
o
ç
ç
ã
ã
o
o
A
A
ç
ç
ã
ã
o
o
r
r
e
e
a
a
l
l
i
i
z
z
a
a
d
d
a
a
p
p
e
e
l
l
a
a
s
s
e
e
c
c
r
r
e
e
t
t
á
á
r
r
i
i
a
a
A
A
c
c
o
o
n
n
t
t
e
e
c
c
e
e
q
q
u
u
a
a
n
n
d
d
o
o
:
:
o
o
p
p
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
n
n
t
t
e
e
n
n
ã
ã
o
o
p
p
o
o
d
d
e
e
e
e
s
s
t
t
a
a
r
r
n
n
o
o
e
e
v
v
e
e
n
n
t
t
o
o
P
P
r
r
é
é
-
-
c
c
o
o
n
n
d
d
:
:
1
1
.
.
P
P
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
n
n
t
t
e
e
i
i
n
n
f
f
o
o
r
r
m
m
a
a
a
a
s
s
e
e
c
c
r
r
e
e
t
t
á
á
r
r
i
i
a
a
s
s
u
u
a
a
p
p
r
r
o
o
v
v
á
á
v
v
e
e
l
l
a
a
u
u
s
s
ê
ê
n
n
c
c
i
i
a
a
I
I
m
m
p
p
a
a
c
c
t
t
o
o
1
1
.
.
P
P
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
n
n
t
t
e
e
e
e
s
s
t
t
á
á
e
e
x
x
c
c
l
l
u
u
í
í
d
d
o
o
.
.
P
P
ó
ó
s
s
-
-
c
c
o
o
n
n
d
d
:
:
1
1
.
.
S
S
e
e
o
o
p
p
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
n
n
t
t
e
e
f
f
o
o
r
r
u
u
m
m
o
o
u
u
v
v
i
i
n
n
t
t
e
e
o
o
u
u
a
a
p
p
r
r
e
e
s
s
e
e
n
n
t
t
a
a
d
d
o
o
r
r
e
e
o
o
p
p
r
r
a
a
z
z
o
o
d
d
a
a
e
e
x
x
c
c
l
l
u
u
s
s
ã
ã
o
o
f
f
o
o
r
r
m
m
a
a
i
i
o
o
r
r
q
q
u
u
e
e
5
5
d
d
i
i
a
a
s
s
ú
ú
t
t
e
e
i
i
s
s
,
,
o
o
v
v
a
a
l
l
o
o
r
r
d
d
e
e
v
v
o
o
l
l
v
v
i
i
d
d
o
o
s
s
e
e
r
r
á
á
d
d
e
e
8
8
0
0
%
%
2
2
.
.
C
C
o
o
m
m
e
e
x
x
c
c
e
e
ç
ç
ã
ã
o
o
d
d
o
o
p
p
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
n
n
t
t
e
e
s
s
e
e
r
r
u
u
m
m
o
o
u
u
v
v
i
i
n
n
t
t
e
e
,
,
s
s
e
e
r
r
á
á
e
e
n
n
v
v
i
i
a
a
d
d
o
o
e
e
-
-
m
m
a
a
i
i
l
l
p
p
a
a
r
r
a
a
o
o
s
s
o
o
u
u
v
v
i
i
n
n
t
t
e
e
s
s
s
s
o
o
b
b
r
r
e
e
a
a
a
a
l
l
t
t
e
e
r
r
a
a
ç
ç
ã
ã
o
o
e
e
f
f
e
e
t
t
u
u
a
a
d
d
a
a
.
.
S
S
í
í
m
m
b
b
o
o
l
l
o
o
C
C
o
o
n
n
s
s
u
u
l
l
t
t
a
a
r
r
p
p
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
n
n
t
t
e
e
s
s
/
/
p
p
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
n
n
t
t
e
e
c
c
o
o
n
n
s
s
u
u
l
l
t
t
a
a
d
d
o
o
C
C
a
a
t
t
e
e
g
g
o
o
r
r
i
i
a
a
V
V
e
e
r
r
b
b
o
o
N
N
o
o
ç
ç
ã
ã
o
o
A
A
ç
ç
ã
ã
o
o
r
r
e
e
a
a
l
l
i
i
z
z
a
a
d
d
a
a
p
p
e
e
l
l
a
a
s
s
e
e
c
c
r
r
e
e
t
t
á
á
r
r
i
i
a
a
,
,
c
c
o
o
m
m
i
i
s
s
s
s
ã
ã
o
o
A
A
c
c
o
o
n
n
t
t
e
e
c
c
e
e
q
q
u
u
a
a
n
n
d
d
o
o
:
:
d
d
e
e
s
s
e
e
j
j
a
a
-
-
s
s
e
e
c
c
o
o
n
n
h
h
e
e
c
c
e
e
r
r
o
o
s
s
p
p
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
n
n
t
t
e
e
s
s
d
d
e
e
u
u
m
m
e
e
v
v
e
e
n
n
t
t
o
o
e
e
m
m
a
a
b
b
e
e
r
r
t
t
o
o
o
o
u
u
f
f
e
e
c
c
h
h
a
a
d
d
o
o
I
I
m
m
p
p
a
a
c
c
t
t
o
o
1
1
.
.
P
P
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
n
n
t
t
e
e
s
s
f
f
o
o
r
r
a
a
m
m
c
c
o
o
n
n
s
s
u
u
l
l
t
t
a
a
d
d
o
o
s
s
.
.
P
P
ó
ó
s
s
-
-
c
c
o
o
n
n
d
d
:
:
S
S
í
í
m
m
b
b
o
o
l
l
o
o
C
C
a
a
d
d
a
a
s
s
t
t
r
r
a
a
r
r
e
e
v
v
e
e
n
n
t
t
o
o
/
/
e
e
v
v
e
e
n
n
t
t
o
o
c
c
a
a
d
d
a
a
s
s
t
t
r
r
a
a
d
d
o
o
C
C
a
a
t
t
e
e
g
g
o
o
r
r
i
i
a
a
V
V
e
e
r
r
b
b
o
o
N
N
o
o
ç
ç
ã
ã
o
o
A
A
ç
ç
ã
ã
o
o
r
r
e
e
a
a
l
l
i
i
z
z
a
a
d
d
a
a
p
p
e
e
l
l
a
a
s
s
e
e
c
c
r
r
e
e
t
t
á
á
r
r
i
i
a
a
A
A
c
c
o
o
n
n
t
t
e
e
c
c
e
e
q
q
u
u
a
a
n
n
d
d
o
o
:
:
a
a
e
e
m
m
p
p
r
r
e
e
s
s
a
a
r
r
e
e
c
c
e
e
b
b
e
e
u
u
m
m
e
e
v
v
e
e
n
n
t
t
o
o
p
p
a
a
r
r
a
a
g
g
e
e
r
r
e
e
n
n
c
c
i
i
a
a
r
r
I
I
m
m
p
p
a
a
c
c
t
t
o
o
1
1
.
.
E
E
v
v
e
e
n
n
t
t
o
o
e
e
s
s
t
t
á
á
c
c
a
a
d
d
a
a
s
s
t
t
r
r
a
a
d
d
o
o
.
.
S
S
í
í
m
m
b
b
o
o
l
l
o
o
C
C
a
a
d
d
a
a
s
s
t
t
r
r
a
a
r
r
c
c
o
o
m
m
i
i
s
s
s
s
ã
ã
o
o
/
/
c
c
o
o
m
m
i
i
s
s
s
s
ã
ã
o
o
c
c
a
a
d
d
a
a
s
s
t
t
r
r
a
a
d
d
a
a
C
C
a
a
t
t
e
e
g
g
o
o
r
r
i
i
a
a
V
V
e
e
r
r
b
b
o
o
N
N
o
o
ç
ç
ã
ã
o
o
A
A
ç
ç
ã
ã
o
o
r
r
e
e
a
a
l
l
i
i
z
z
a
a
d
d
a
a
p
p
e
e
l
l
a
a
s
s
e
e
c
c
r
r
e
e
t
t
á
á
r
r
i
i
a
a
A
A
c
c
o
o
n
n
t
t
e
e
c
c
e
e
q
q
u
u
a
a
n
n
d
d
o
o
:
:
o
o
e
e
v
v
e
e
n
n
t
t
o
o
n
n
ã
ã
o
o
p
p
o
o
s
s
s
s
u
u
i
i
c
c
o
o
m
m
i
i
s
s
s
s
ã
ã
o
o
5.
Experimentação
: Controle de Eventos Científicos 124
I
I
m
m
p
p
a
a
c
c
t
t
o
o
1
1
.
.
C
C
o
o
m
m
i
i
s
s
s
s
ã
ã
o
o
e
e
s
s
t
t
á
á
c
c
a
a
d
d
a
a
s
s
t
t
r
r
a
a
d
d
a
a
.
.
S
S
í
í
m
m
b
b
o
o
l
l
o
o
C
C
a
a
d
d
a
a
s
s
t
t
r
r
a
a
r
r
c
c
o
o
m
m
i
i
t
t
ê
ê
/
/
c
c
o
o
m
m
i
i
t
t
ê
ê
c
c
a
a
d
d
a
a
s
s
t
t
r
r
a
a
d
d
o
o
C
C
a
a
t
t
e
e
g
g
o
o
r
r
i
i
a
a
V
V
e
e
r
r
b
b
o
o
N
N
o
o
ç
ç
ã
ã
o
o
A
A
ç
ç
ã
ã
o
o
r
r
e
e
a
a
l
l
i
i
z
z
a
a
d
d
a
a
p
p
e
e
l
l
a
a
s
s
e
e
c
c
r
r
e
e
t
t
á
á
r
r
i
i
a
a
A
A
c
c
o
o
n
n
t
t
e
e
c
c
e
e
q
q
u
u
a
a
n
n
d
d
o
o
:
:
o
o
e
e
v
v
e
e
n
n
t
t
o
o
n
n
ã
ã
o
o
p
p
o
o
s
s
s
s
u
u
i
i
c
c
o
o
m
m
i
i
t
t
ê
ê
o
o
r
r
g
g
a
a
n
n
i
i
z
z
a
a
d
d
o
o
r
r
I
I
m
m
p
p
a
a
c
c
t
t
o
o
1
1
.
.
C
C
o
o
m
m
i
i
t
t
ê
ê
e
e
s
s
t
t
á
á
c
c
a
a
d
d
a
a
s
s
t
t
r
r
a
a
d
d
o
o
.
.
P
P
ó
ó
s
s
-
-
c
c
o
o
n
n
d
d
:
:
S
S
í
í
m
m
b
b
o
o
l
l
o
o
R
R
e
e
c
c
e
e
b
b
e
e
r
r
r
r
e
e
c
c
u
u
r
r
s
s
o
o
s
s
/
/
r
r
e
e
c
c
u
u
r
r
s
s
o
o
s
s
r
r
e
e
c
c
e
e
b
b
i
i
d
d
o
o
s
s
C
C
a
a
t
t
e
e
g
g
o
o
r
r
i
i
a
a
V
V
e
e
r
r
b
b
o
o
N
N
o
o
ç
ç
ã
ã
o
o
A
A
ç
ç
ã
ã
o
o
s
s
o
o
f
f
r
r
i
i
d
d
a
a
p
p
e
e
l
l
a
a
s
s
e
e
c
c
r
r
e
e
t
t
á
á
r
r
i
i
a
a
A
A
c
c
o
o
n
n
t
t
e
e
c
c
e
e
q
q
u
u
a
a
n
n
d
d
o
o
:
:
o
o
e
e
v
v
e
e
n
n
t
t
o
o
n
n
ã
ã
o
o
p
p
o
o
s
s
s
s
u
u
i
i
r
r
e
e
c
c
u
u
r
r
s
s
o
o
s
s
P
P
r
r
é
é
-
-
c
c
o
o
n
n
d
d
:
:
1
1
.
.
P
P
a
a
r
r
c
c
e
e
i
i
r
r
o
o
s
s
f
f
o
o
r
r
n
n
e
e
c
c
e
e
m
m
r
r
e
e
c
c
u
u
r
r
s
s
o
o
s
s
I
I
m
m
p
p
a
a
c
c
t
t
o
o
1
1
.
.
R
R
e
e
c
c
u
u
r
r
s
s
o
o
s
s
f
f
o
o
r
r
a
a
m
m
r
r
e
e
c
c
e
e
b
b
i
i
d
d
o
o
s
s
.
.
P
P
ó
ó
s
s
-
-
c
c
o
o
n
n
d
d
:
:
S
S
í
í
m
m
b
b
o
o
l
l
o
o
D
D
i
i
s
s
t
t
r
r
i
i
b
b
u
u
i
i
r
r
r
r
e
e
c
c
u
u
r
r
s
s
o
o
s
s
/
/
r
r
e
e
c
c
u
u
r
r
s
s
o
o
s
s
d
d
i
i
s
s
t
t
r
r
i
i
b
b
u
u
i
i
d
d
o
o
s
s
C
C
a
a
t
t
e
e
g
g
o
o
r
r
i
i
a
a
V
V
e
e
r
r
b
b
o
o
N
N
o
o
ç
ç
ã
ã
o
o
A
A
ç
ç
ã
ã
o
o
r
r
e
e
a
a
l
l
i
i
z
z
a
a
d
d
a
a
p
p
e
e
l
l
a
a
s
s
e
e
c
c
r
r
e
e
t
t
á
á
r
r
i
i
a
a
A
A
c
c
o
o
n
n
t
t
e
e
c
c
e
e
q
q
u
u
a
a
n
n
d
d
o
o
:
:
o
o
e
e
v
v
e
e
n
n
t
t
o
o
n
n
ã
ã
o
o
p
p
o
o
s
s
s
s
u
u
i
i
r
r
e
e
c
c
u
u
r
r
s
s
o
o
s
s
P
P
r
r
é
é
-
-
c
c
o
o
n
n
d
d
:
:
1
1
.
.
R
R
e
e
c
c
u
u
r
r
s
s
o
o
s
s
f
f
o
o
r
r
a
a
m
m
r
r
e
e
c
c
e
e
b
b
i
i
d
d
o
o
s
s
2
2
.
.
E
E
v
v
e
e
n
n
t
t
o
o
p
p
o
o
s
s
s
s
u
u
i
i
r
r
n
n
e
e
c
c
e
e
s
s
s
s
i
i
d
d
a
a
d
d
e
e
d
d
e
e
r
r
e
e
c
c
u
u
r
r
s
s
o
o
s
s
I
I
m
m
p
p
a
a
c
c
t
t
o
o
1
1
.
.
R
R
e
e
c
c
u
u
r
r
s
s
o
o
s
s
f
f
o
o
r
r
a
a
m
m
r
r
e
e
c
c
e
e
b
b
i
i
d
d
o
o
s
s
.
.
S
S
í
í
m
m
b
b
o
o
l
l
o
o
P
P
a
a
g
g
a
a
r
r
f
f
o
o
r
r
n
n
e
e
c
c
e
e
d
d
o
o
r
r
/
/
f
f
o
o
r
r
n
n
e
e
c
c
e
e
d
d
o
o
r
r
e
e
s
s
p
p
a
a
g
g
o
o
s
s
C
C
a
a
t
t
e
e
g
g
o
o
r
r
i
i
a
a
V
V
e
e
r
r
b
b
o
o
N
N
o
o
ç
ç
ã
ã
o
o
A
A
ç
ç
ã
ã
o
o
r
r
e
e
a
a
l
l
i
i
z
z
a
a
d
d
a
a
p
p
e
e
l
l
a
a
s
s
e
e
c
c
r
r
e
e
t
t
á
á
r
r
i
i
a
a
A
A
c
c
o
o
n
n
t
t
e
e
c
c
e
e
q
q
u
u
a
a
n
n
d
d
o
o
:
:
o
o
e
e
v
v
e
e
n
n
t
t
o
o
p
p
o
o
s
s
s
s
u
u
i
i
r
r
e
e
c
c
u
u
r
r
s
s
o
o
s
s
p
p
a
a
r
r
a
a
p
p
a
a
g
g
a
a
m
m
e
e
n
n
t
t
o
o
d
d
e
e
f
f
o
o
r
r
n
n
e
e
c
c
e
e
d
d
o
o
r
r
P
P
r
r
é
é
-
-
c
c
o
o
n
n
d
d
:
:
1
1
.
.
f
f
o
o
r
r
n
n
e
e
c
c
e
e
d
d
o
o
r
r
f
f
o
o
r
r
n
n
e
e
c
c
e
e
u
u
r
r
e
e
c
c
u
u
r
r
s
s
o
o
s
s
2
2
.
.
f
f
o
o
r
r
n
n
e
e
c
c
e
e
d
d
o
o
r
r
n
n
ã
ã
o
o
f
f
o
o
i
i
p
p
a
a
g
g
o
o
I
I
m
m
p
p
a
a
c
c
t
t
o
o
1
1
.
.
F
F
o
o
r
r
n
n
e
e
c
c
e
e
d
d
o
o
r
r
f
f
o
o
i
i
p
p
a
a
g
g
o
o
.
.
P
P
ó
ó
s
s
-
-
c
c
o
o
n
n
d
d
:
:
1
1
.
.
F
F
o
o
r
r
n
n
e
e
c
c
e
e
d
d
o
o
r
r
r
r
e
e
c
c
e
e
b
b
e
e
p
p
a
a
g
g
a
a
m
m
e
e
n
n
t
t
o
o
_
_
r
r
e
e
c
c
u
u
r
r
s
s
o
o
S
S
í
í
m
m
b
b
o
o
l
l
o
o
R
R
e
e
c
c
e
e
b
b
e
e
r
r
p
p
a
a
g
g
a
a
m
m
e
e
n
n
t
t
o
o
/
/
p
p
a
a
g
g
a
a
m
m
e
e
n
n
t
t
o
o
r
r
e
e
c
c
e
e
b
b
i
i
d
d
o
o
C
C
a
a
t
t
e
e
g
g
o
o
r
r
i
i
a
a
V
V
e
e
r
r
b
b
o
o
N
N
o
o
ç
ç
ã
ã
o
o
A
A
ç
ç
ã
ã
o
o
s
s
o
o
f
f
r
r
i
i
d
d
a
a
p
p
e
e
l
l
a
a
s
s
e
e
c
c
r
r
e
e
t
t
á
á
r
r
i
i
a
a
A
A
c
c
o
o
n
n
t
t
e
e
c
c
e
e
q
q
u
u
a
a
n
n
d
d
o
o
:
:
a
a
s
s
e
e
c
c
r
r
e
e
t
t
á
á
r
r
i
i
a
a
r
r
e
e
c
c
e
e
b
b
e
e
u
u
o
o
p
p
a
a
g
g
a
a
m
m
e
e
n
n
t
t
o
o
d
d
o
o
o
o
u
u
v
v
i
i
n
n
t
t
e
e
e
e
/
/
o
o
u
u
a
a
p
p
r
r
e
e
s
s
e
e
n
n
t
t
a
a
d
d
o
o
r
r
P
P
r
r
é
é
-
-
c
c
o
o
n
n
d
d
:
:
1
1
.
.
O
O
u
u
v
v
i
i
n
n
t
t
e
e
e
e
/
/
o
o
u
u
a
a
p
p
r
r
e
e
s
s
e
e
n
n
t
t
a
a
d
d
o
o
r
r
e
e
s
s
t
t
ã
ã
o
o
i
i
n
n
s
s
c
c
r
r
i
i
t
t
o
o
s
s
n
n
o
o
e
e
v
v
e
e
n
n
t
t
o
o
2
2
.
.
O
O
u
u
v
v
i
i
n
n
t
t
e
e
e
e
/
/
o
o
u
u
a
a
p
p
r
r
e
e
s
s
e
e
n
n
t
t
a
a
d
d
o
o
r
r
e
e
f
f
e
e
t
t
u
u
o
o
u
u
p
p
a
a
g
g
a
a
m
m
e
e
n
n
t
t
o
o
I
I
m
m
p
p
a
a
c
c
t
t
o
o
1
1
.
.
P
P
a
a
g
g
a
a
m
m
e
e
n
n
t
t
o
o
f
f
o
o
i
i
r
r
e
e
c
c
e
e
b
b
i
i
d
d
o
o
.
.
S
S
í
í
m
m
b
b
o
o
l
l
o
o
C
C
o
o
n
n
s
s
u
u
l
l
t
t
a
a
r
r
p
p
r
r
o
o
g
g
r
r
a
a
m
m
a
a
ç
ç
ã
ã
o
o
/
/
p
p
r
r
o
o
g
g
r
r
a
a
m
m
a
a
ç
ç
ã
ã
o
o
c
c
o
o
n
n
s
s
u
u
l
l
t
t
a
a
d
d
a
a
C
C
a
a
t
t
e
e
g
g
o
o
r
r
i
i
a
a
V
V
e
e
r
r
b
b
o
o
N
N
o
o
ç
ç
ã
ã
o
o
A
A
ç
ç
ã
ã
o
o
r
r
e
e
a
a
l
l
i
i
z
z
a
a
d
d
a
a
p
p
e
e
l
l
o
o
s
s
p
p
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
n
n
t
t
e
e
s
s
,
,
p
p
a
a
r
r
c
c
e
e
i
i
r
r
o
o
s
s
,
,
c
c
l
l
i
i
e
e
n
n
t
t
e
e
s
s
i
i
n
n
s
s
c
c
r
r
i
i
t
t
o
o
s
s
,
,
c
c
l
l
i
i
e
e
n
n
t
t
e
e
s
s
A
A
c
c
o
o
n
n
t
t
e
e
c
c
e
e
q
q
u
u
a
a
n
n
d
d
o
o
:
:
d
d
e
e
s
s
e
e
j
j
a
a
-
-
s
s
e
e
c
c
o
o
n
n
h
h
e
e
c
c
e
e
r
r
a
a
p
p
r
r
o
o
g
g
r
r
a
a
m
m
a
a
ç
ç
ã
ã
o
o
d
d
e
e
u
u
m
m
e
e
v
v
e
e
n
n
t
t
o
o
P
P
r
r
é
é
-
-
c
c
o
o
n
n
d
d
:
:
1
1
.
.
E
E
v
v
e
e
n
n
t
t
o
o
s
s
e
e
m
m
a
a
b
b
e
e
r
r
t
t
o
o
s
s
ã
ã
o
o
c
c
o
o
n
n
s
s
u
u
l
l
t
t
a
a
d
d
o
o
s
s
2
2
.
.
E
E
v
v
e
e
n
n
t
t
o
o
é
é
s
s
e
e
l
l
e
e
c
c
i
i
o
o
n
n
a
a
d
d
o
o
I
I
m
m
p
p
a
a
c
c
t
t
o
o
1
1
.
.
P
P
r
r
o
o
g
g
r
r
a
a
m
m
a
a
ç
ç
ã
ã
o
o
c
c
o
o
n
n
s
s
u
u
l
l
t
t
a
a
d
d
a
a
.
.
S
S
í
í
m
m
b
b
o
o
l
l
o
o
I
I
n
n
s
s
c
c
r
r
e
e
v
v
e
e
r
r
-
-
s
s
e
e
e
e
m
m
e
e
v
v
e
e
n
n
t
t
o
o
/
/
i
i
n
n
s
s
c
c
r
r
i
i
ç
ç
ã
ã
o
o
e
e
f
f
e
e
t
t
u
u
a
a
d
d
a
a
C
C
a
a
t
t
e
e
g
g
o
o
r
r
i
i
a
a
V
V
e
e
r
r
b
b
o
o
N
N
o
o
ç
ç
ã
ã
o
o
A
A
ç
ç
ã
ã
o
o
r
r
e
e
a
a
l
l
i
i
z
z
a
a
d
d
a
a
p
p
e
e
l
l
o
o
c
c
l
l
i
i
e
e
n
n
t
t
e
e
i
i
n
n
s
s
c
c
r
r
i
i
t
t
o
o
A
A
c
c
o
o
n
n
t
t
e
e
c
c
e
e
q
q
u
u
a
a
n
n
d
d
o
o
:
:
d
d
e
e
s
s
e
e
j
j
a
a
-
-
s
s
e
e
i
i
n
n
s
s
c
c
r
r
e
e
v
v
e
e
r
r
-
-
s
s
e
e
p
p
a
a
r
r
a
a
u
u
m
m
e
e
v
v
e
e
n
n
t
t
o
o
e
e
m
m
a
a
b
b
e
e
r
r
t
t
o
o
P
P
r
r
é
é
-
-
c
c
o
o
n
n
d
d
:
:
5.
Experimentação
: Controle de Eventos Científicos 125
3
3
.
.
E
E
v
v
e
e
n
n
t
t
o
o
s
s
e
e
m
m
a
a
b
b
e
e
r
r
t
t
o
o
s
s
ã
ã
o
o
c
c
o
o
n
n
s
s
u
u
l
l
t
t
a
a
d
d
o
o
s
s
4
4
.
.
E
E
v
v
e
e
n
n
t
t
o
o
é
é
s
s
e
e
l
l
e
e
c
c
i
i
o
o
n
n
a
a
d
d
o
o
I
I
m
m
p
p
a
a
c
c
t
t
o
o
1
1
.
.
I
I
n
n
s
s
c
c
r
r
i
i
ç
ç
ã
ã
o
o
é
é
e
e
f
f
e
e
t
t
u
u
a
a
d
d
a
a
.
.
S
S
í
í
m
m
b
b
o
o
l
l
o
o
E
E
n
n
v
v
i
i
a
a
r
r
t
t
r
r
a
a
b
b
a
a
l
l
h
h
o
o
/
/
t
t
r
r
a
a
b
b
a
a
l
l
h
h
o
o
e
e
n
n
v
v
i
i
a
a
d
d
o
o
C
C
a
a
t
t
e
e
g
g
o
o
r
r
i
i
a
a
V
V
e
e
r
r
b
b
o
o
N
N
o
o
ç
ç
ã
ã
o
o
A
A
ç
ç
ã
ã
o
o
r
r
e
e
a
a
l
l
i
i
z
z
a
a
d
d
a
a
p
p
e
e
l
l
o
o
a
a
p
p
r
r
e
e
s
s
e
e
n
n
t
t
a
a
d
d
o
o
r
r
A
A
c
c
o
o
n
n
t
t
e
e
c
c
e
e
q
q
u
u
a
a
n
n
d
d
o
o
:
:
o
o
c
c
l
l
i
i
e
e
n
n
t
t
e
e
i
i
n
n
s
s
c
c
r
r
i
i
t
t
o
o
d
d
e
e
s
s
e
e
j
j
a
a
e
e
n
n
v
v
i
i
a
a
r
r
u
u
m
m
t
t
r
r
a
a
b
b
a
a
l
l
h
h
o
o
p
p
a
a
r
r
a
a
a
a
p
p
r
r
e
e
s
s
e
e
n
n
t
t
a
a
ç
ç
ã
ã
o
o
P
P
r
r
é
é
-
-
c
c
o
o
n
n
d
d
:
:
1
1
.
.
C
C
l
l
i
i
e
e
n
n
t
t
e
e
i
i
n
n
s
s
c
c
r
r
i
i
t
t
o
o
e
e
s
s
t
t
á
á
c
c
a
a
d
d
a
a
s
s
t
t
r
r
a
a
d
d
o
o
n
n
o
o
e
e
v
v
e
e
n
n
t
t
o
o
e
e
m
m
a
a
b
b
e
e
r
r
t
t
o
o
c
c
o
o
m
m
o
o
a
a
p
p
r
r
e
e
s
s
e
e
n
n
t
t
a
a
d
d
o
o
r
r
P
P
r
r
a
a
z
z
o
o
d
d
e
e
s
s
u
u
b
b
m
m
i
i
s
s
s
s
ã
ã
o
o
d
d
e
e
t
t
r
r
a
a
b
b
a
a
l
l
h
h
o
o
s
s
e
e
s
s
t
t
á
á
v
v
a
a
l
l
e
e
n
n
d
d
o
o
I
I
m
m
p
p
a
a
c
c
t
t
o
o
1
1
.
.
t
t
r
r
a
a
b
b
a
a
l
l
h
h
o
o
é
é
e
e
n
n
v
v
i
i
a
a
d
d
o
o
.
.
P
P
ó
ó
s
s
-
-
c
c
o
o
n
n
d
d
:
:
S
S
í
í
m
m
b
b
o
o
l
l
o
o
E
E
f
f
e
e
t
t
u
u
a
a
r
r
p
p
a
a
g
g
a
a
m
m
e
e
n
n
t
t
o
o
/
/
p
p
a
a
g
g
a
a
m
m
e
e
n
n
t
t
o
o
e
e
f
f
e
e
t
t
u
u
a
a
d
d
o
o
C
C
a
a
t
t
e
e
g
g
o
o
r
r
i
i
a
a
V
V
e
e
r
r
b
b
o
o
N
N
o
o
ç
ç
ã
ã
o
o
A
A
ç
ç
ã
ã
o
o
r
r
e
e
a
a
l
l
i
i
z
z
a
a
d
d
a
a
p
p
e
e
l
l
o
o
o
o
u
u
v
v
i
i
n
n
t
t
e
e
e
e
/
/
o
o
u
u
a
a
p
p
r
r
e
e
s
s
e
e
n
n
t
t
a
a
d
d
o
o
r
r
A
A
c
c
o
o
n
n
t
t
e
e
c
c
e
e
q
q
u
u
a
a
n
n
d
d
o
o
:
:
o
o
o
o
u
u
v
v
i
i
n
n
t
t
e
e
e
e
/
/
o
o
u
u
a
a
p
p
r
r
e
e
s
s
e
e
n
n
t
t
a
a
d
d
o
o
r
r
p
p
o
o
s
s
s
s
u
u
i
i
p
p
a
a
g
g
a
a
m
m
e
e
n
n
t
t
o
o
a
a
f
f
a
a
z
z
e
e
r
r
d
d
o
o
e
e
v
v
e
e
n
n
t
t
o
o
P
P
r
r
é
é
-
-
c
c
o
o
n
n
d
d
:
:
1
1
.
.
o
o
u
u
v
v
i
i
n
n
t
t
e
e
e
e
/
/
o
o
u
u
a
a
p
p
r
r
e
e
s
s
e
e
n
n
t
t
a
a
d
d
o
o
r
r
e
e
s
s
t
t
ã
ã
o
o
i
i
n
n
s
s
c
c
r
r
i
i
t
t
o
o
s
s
n
n
o
o
e
e
v
v
e
e
n
n
t
t
o
o
I
I
m
m
p
p
a
a
c
c
t
t
o
o
1
1
.
.
p
p
a
a
g
g
a
a
m
m
e
e
n
n
t
t
o
o
é
é
e
e
f
f
e
e
t
t
u
u
a
a
d
d
o
o
.
.
P
P
ó
ó
s
s
-
-
c
c
o
o
n
n
d
d
:
:
1
1
.
.
P
P
a
a
g
g
a
a
m
m
e
e
n
n
t
t
o
o
é
é
r
r
e
e
c
c
e
e
b
b
i
i
d
d
o
o
p
p
e
e
l
l
a
a
s
s
e
e
c
c
r
r
e
e
t
t
a
a
r
r
i
i
a
a
S
S
í
í
m
m
b
b
o
o
l
l
o
o
E
E
n
n
v
v
i
i
a
a
r
r
p
p
a
a
l
l
e
e
s
s
t
t
r
r
a
a
/
/
p
p
a
a
l
l
e
e
s
s
t
t
r
r
a
a
e
e
n
n
v
v
i
i
a
a
d
d
a
a
C
C
a
a
t
t
e
e
g
g
o
o
r
r
i
i
a
a
V
V
e
e
r
r
b
b
o
o
N
N
o
o
ç
ç
ã
ã
o
o
A
A
ç
ç
ã
ã
o
o
r
r
e
e
a
a
l
l
i
i
z
z
a
a
d
d
a
a
p
p
e
e
l
l
o
o
p
p
a
a
l
l
e
e
s
s
t
t
r
r
a
a
n
n
t
t
e
e
A
A
c
c
o
o
n
n
t
t
e
e
c
c
e
e
q
q
u
u
a
a
n
n
d
d
o
o
:
:
o
o
p
p
a
a
l
l
e
e
s
s
t
t
r
r
a
a
n
n
t
t
e
e
d
d
e
e
s
s
e
e
j
j
a
a
e
e
n
n
v
v
i
i
a
a
r
r
a
a
p
p
a
a
l
l
e
e
s
s
t
t
r
r
a
a
p
p
a
a
r
r
a
a
o
o
e
e
v
v
e
e
n
n
t
t
o
o
P
P
r
r
é
é
-
-
c
c
o
o
n
n
d
d
:
:
1
1
.
.
C
C
l
l
i
i
e
e
n
n
t
t
e
e
i
i
n
n
s
s
c
c
r
r
i
i
t
t
o
o
e
e
s
s
t
t
á
á
c
c
a
a
d
d
a
a
s
s
t
t
r
r
a
a
d
d
o
o
n
n
o
o
e
e
v
v
e
e
n
n
t
t
o
o
e
e
m
m
a
a
b
b
e
e
r
r
t
t
o
o
c
c
o
o
m
m
o
o
p
p
a
a
l
l
e
e
s
s
t
t
r
r
a
a
n
n
t
t
e
e
2
2
.
.
P
P
r
r
a
a
z
z
o
o
d
d
e
e
e
e
n
n
v
v
i
i
o
o
d
d
a
a
s
s
p
p
a
a
l
l
e
e
s
s
t
t
r
r
a
a
s
s
e
e
s
s
t
t
á
á
v
v
a
a
l
l
e
e
n
n
d
d
o
o
I
I
m
m
p
p
a
a
c
c
t
t
o
o
1
1
.
.
p
p
a
a
l
l
e
e
s
s
t
t
r
r
a
a
é
é
e
e
n
n
v
v
i
i
a
a
d
d
a
a
.
.
P
P
ó
ó
s
s
-
-
c
c
o
o
n
n
d
d
:
:
S
S
í
í
m
m
b
b
o
o
l
l
o
o
E
E
n
n
v
v
i
i
a
a
r
r
m
m
a
a
t
t
e
e
r
r
i
i
a
a
l
l
/
/
m
m
a
a
t
t
e
e
r
r
i
i
a
a
l
l
e
e
n
n
v
v
i
i
a
a
d
d
o
o
C
C
a
a
t
t
e
e
g
g
o
o
r
r
i
i
a
a
V
V
e
e
r
r
b
b
o
o
N
N
o
o
ç
ç
ã
ã
o
o
A
A
ç
ç
ã
ã
o
o
r
r
e
e
a
a
l
l
i
i
z
z
a
a
d
d
a
a
p
p
e
e
l
l
o
o
m
m
i
i
n
n
i
i
s
s
t
t
r
r
a
a
n
n
t
t
e
e
A
A
c
c
o
o
n
n
t
t
e
e
c
c
e
e
q
q
u
u
a
a
n
n
d
d
o
o
:
:
o
o
m
m
i
i
n
n
i
i
s
s
t
t
r
r
a
a
n
n
t
t
e
e
d
d
e
e
s
s
e
e
j
j
a
a
e
e
n
n
v
v
i
i
a
a
r
r
o
o
m
m
a
a
t
t
e
e
r
r
i
i
a
a
l
l
d
d
o
o
c
c
u
u
r
r
s
s
o
o
p
p
a
a
r
r
a
a
o
o
e
e
v
v
e
e
n
n
t
t
o
o
P
P
r
r
é
é
-
-
c
c
o
o
n
n
d
d
:
:
1
1
.
.
C
C
l
l
i
i
e
e
n
n
t
t
e
e
i
i
n
n
s
s
c
c
r
r
i
i
t
t
o
o
e
e
s
s
t
t
á
á
c
c
a
a
d
d
a
a
s
s
t
t
r
r
a
a
d
d
o
o
n
n
o
o
e
e
v
v
e
e
n
n
t
t
o
o
e
e
m
m
a
a
b
b
e
e
r
r
t
t
o
o
c
c
o
o
m
m
o
o
m
m
i
i
n
n
i
i
s
s
t
t
r
r
a
a
n
n
t
t
e
e
2
2
.
.
P
P
r
r
a
a
z
z
o
o
d
d
e
e
e
e
n
n
v
v
i
i
o
o
d
d
o
o
m
m
a
a
t
t
e
e
r
r
i
i
a
a
l
l
e
e
s
s
t
t
á
á
v
v
a
a
l
l
e
e
n
n
d
d
o
o
I
I
m
m
p
p
a
a
c
c
t
t
o
o
1
1
.
.
m
m
a
a
t
t
e
e
r
r
i
i
a
a
l
l
é
é
e
e
n
n
v
v
i
i
a
a
d
d
o
o
.
.
S
S
í
í
m
m
b
b
o
o
l
l
o
o
E
E
n
n
v
v
i
i
a
a
r
r
r
r
e
e
q
q
u
u
i
i
s
s
i
i
ç
ç
ã
ã
o
o
/
/
r
r
e
e
q
q
u
u
i
i
s
s
i
i
ç
ç
ã
ã
o
o
e
e
n
n
v
v
i
i
a
a
d
d
a
a
C
C
a
a
t
t
e
e
g
g
o
o
r
r
i
i
a
a
V
V
e
e
r
r
b
b
o
o
N
N
o
o
ç
ç
ã
ã
o
o
A
A
ç
ç
ã
ã
o
o
r
r
e
e
a
a
l
l
i
i
z
z
a
a
d
d
a
a
p
p
e
e
l
l
o
o
m
m
i
i
n
n
i
i
s
s
t
t
r
r
a
a
n
n
t
t
e
e
A
A
c
c
o
o
n
n
t
t
e
e
c
c
e
e
q
q
u
u
a
a
n
n
d
d
o
o
:
:
o
o
m
m
i
i
n
n
i
i
s
s
t
t
r
r
a
a
n
n
t
t
e
e
d
d
e
e
s
s
e
e
j
j
a
a
e
e
n
n
v
v
i
i
a
a
r
r
a
a
r
r
e
e
q
q
u
u
i
i
s
s
i
i
ç
ç
ã
ã
o
o
d
d
o
o
m
m
a
a
t
t
e
e
r
r
i
i
a
a
l
l
d
d
o
o
c
c
u
u
r
r
s
s
o
o
p
p
a
a
r
r
a
a
o
o
e
e
v
v
e
e
n
n
t
t
o
o
P
P
r
r
é
é
-
-
c
c
o
o
n
n
d
d
:
:
1
1
.
.
C
C
l
l
i
i
e
e
n
n
t
t
e
e
i
i
n
n
s
s
c
c
r
r
i
i
t
t
o
o
e
e
s
s
t
t
á
á
c
c
a
a
d
d
a
a
s
s
t
t
r
r
a
a
d
d
o
o
n
n
o
o
e
e
v
v
e
e
n
n
t
t
o
o
e
e
m
m
a
a
b
b
e
e
r
r
t
t
o
o
c
c
o
o
m
m
o
o
m
m
i
i
n
n
i
i
s
s
t
t
r
r
a
a
n
n
t
t
e
e
2
2
.
.
P
P
r
r
a
a
z
z
o
o
d
d
e
e
e
e
n
n
v
v
i
i
o
o
d
d
o
o
m
m
a
a
t
t
e
e
r
r
i
i
a
a
l
l
e
e
s
s
t
t
á
á
v
v
a
a
l
l
e
e
n
n
d
d
o
o
I
I
m
m
p
p
a
a
c
c
t
t
o
o
1
1
.
.
r
r
e
e
q
q
u
u
i
i
s
s
i
i
ç
ç
ã
ã
o
o
é
é
e
e
n
n
v
v
i
i
a
a
d
d
a
a
.
.
S
S
í
í
m
m
b
b
o
o
l
l
o
o
S
S
e
e
l
l
e
e
c
c
i
i
o
o
n
n
a
a
r
r
m
m
i
i
n
n
i
i
s
s
t
t
r
r
a
a
n
n
t
t
e
e
/
/
m
m
i
i
n
n
i
i
s
s
t
t
r
r
a
a
n
n
t
t
e
e
s
s
e
e
l
l
e
e
c
c
i
i
o
o
n
n
a
a
d
d
o
o
C
C
a
a
t
t
e
e
g
g
o
o
r
r
i
i
a
a
V
V
e
e
r
r
b
b
o
o
N
N
o
o
ç
ç
ã
ã
o
o
A
A
ç
ç
ã
ã
o
o
r
r
e
e
a
a
l
l
i
i
z
z
a
a
d
d
a
a
p
p
e
e
l
l
o
o
c
c
o
o
m
m
i
i
s
s
s
s
ã
ã
o
o
5.
Experimentação
: Controle de Eventos Científicos 126
A
A
c
c
o
o
n
n
t
t
e
e
c
c
e
e
q
q
u
u
a
a
n
n
d
d
o
o
:
:
o
o
c
c
o
o
m
m
i
i
s
s
s
s
ã
ã
o
o
d
d
e
e
s
s
e
e
j
j
a
a
s
s
e
e
l
l
e
e
c
c
i
i
o
o
n
n
a
a
r
r
o
o
(
(
s
s
)
)
m
m
i
i
n
n
i
i
s
s
t
t
r
r
a
a
n
n
t
t
e
e
(
(
e
e
)
)
p
p
a
a
r
r
a
a
o
o
e
e
v
v
e
e
n
n
t
t
o
o
P
P
r
r
é
é
-
-
c
c
o
o
n
n
d
d
:
:
E
E
v
v
e
e
n
n
t
t
o
o
p
p
o
o
s
s
s
s
u
u
i
i
v
v
a
a
g
g
a
a
s
s
n
n
o
o
s
s
h
h
o
o
r
r
á
á
r
r
i
i
o
o
s
s
d
d
e
e
p
p
r
r
o
o
g
g
r
r
a
a
m
m
a
a
ç
ç
ã
ã
o
o
I
I
m
m
p
p
a
a
c
c
t
t
o
o
1
1
.
.
m
m
i
i
n
n
i
i
s
s
t
t
r
r
a
a
n
n
t
t
e
e
é
é
s
s
e
e
l
l
e
e
c
c
i
i
o
o
n
n
a
a
d
d
o
o
.
.
P
P
ó
ó
s
s
-
-
c
c
o
o
n
n
d
d
:
:
1
1
.
.
É
É
e
e
n
n
v
v
i
i
a
a
d
d
o
o
e
e
-
-
m
m
a
a
i
i
l
l
p
p
a
a
r
r
a
a
o
o
m
m
i
i
n
n
i
i
s
s
t
t
r
r
a
a
n
n
t
t
e
e
c
c
o
o
m
m
o
o
c
c
o
o
n
n
v
v
i
i
t
t
e
e
d
d
o
o
e
e
v
v
e
e
n
n
t
t
o
o
c
c
o
o
n
n
t
t
e
e
n
n
d
d
o
o
:
:
a
a
s
s
s
s
u
u
n
n
t
t
o
o
d
d
e
e
i
i
n
n
t
t
e
e
r
r
e
e
s
s
s
s
e
e
d
d
o
o
c
c
u
u
r
r
s
s
o
o
,
,
p
p
r
r
a
a
z
z
o
o
e
e
s
s
t
t
i
i
m
m
a
a
d
d
o
o
p
p
a
a
r
r
a
a
o
o
e
e
n
n
v
v
i
i
o
o
d
d
o
o
m
m
a
a
t
t
e
e
r
r
i
i
a
a
l
l
e
e
r
r
e
e
q
q
u
u
i
i
s
s
i
i
ç
ç
ã
ã
o
o
e
e
i
i
n
n
f
f
o
o
r
r
m
m
a
a
ç
ç
õ
õ
e
e
s
s
g
g
e
e
r
r
a
a
i
i
s
s
s
s
o
o
b
b
r
r
e
e
o
o
e
e
v
v
e
e
n
n
t
t
o
o
.
.
S
S
í
í
m
m
b
b
o
o
l
l
o
o
S
S
e
e
l
l
e
e
c
c
i
i
o
o
n
n
a
a
r
r
p
p
a
a
l
l
e
e
s
s
t
t
r
r
a
a
n
n
t
t
e
e
/
/
p
p
a
a
l
l
e
e
s
s
t
t
r
r
a
a
n
n
t
t
e
e
s
s
e
e
l
l
e
e
c
c
i
i
o
o
n
n
a
a
d
d
o
o
C
C
a
a
t
t
e
e
g
g
o
o
r
r
i
i
a
a
V
V
e
e
r
r
b
b
o
o
N
N
o
o
ç
ç
ã
ã
o
o
A
A
ç
ç
ã
ã
o
o
r
r
e
e
a
a
l
l
i
i
z
z
a
a
d
d
a
a
p
p
e
e
l
l
o
o
c
c
o
o
m
m
i
i
s
s
s
s
ã
ã
o
o
A
A
c
c
o
o
n
n
t
t
e
e
c
c
e
e
q
q
u
u
a
a
n
n
d
d
o
o
:
:
o
o
c
c
o
o
m
m
i
i
s
s
s
s
ã
ã
o
o
d
d
e
e
s
s
e
e
j
j
a
a
s
s
e
e
l
l
e
e
c
c
i
i
o
o
n
n
a
a
r
r
o
o
(
(
s
s
)
)
p
p
a
a
l
l
e
e
s
s
t
t
r
r
a
a
n
n
t
t
e
e
(
(
e
e
)
)
p
p
a
a
r
r
a
a
o
o
e
e
v
v
e
e
n
n
t
t
o
o
P
P
r
r
é
é
-
-
c
c
o
o
n
n
d
d
:
:
1
1
.
.
E
E
v
v
e
e
n
n
t
t
o
o
p
p
o
o
s
s
s
s
u
u
i
i
v
v
a
a
g
g
a
a
s
s
n
n
o
o
s
s
h
h
o
o
r
r
á
á
r
r
i
i
o
o
s
s
d
d
e
e
p
p
r
r
o
o
g
g
r
r
a
a
m
m
a
a
ç
ç
ã
ã
o
o
I
I
m
m
p
p
a
a
c
c
t
t
o
o
1
1
.
.
p
p
a
a
l
l
e
e
s
s
t
t
r
r
a
a
n
n
t
t
e
e
é
é
s
s
e
e
l
l
e
e
c
c
i
i
o
o
n
n
a
a
d
d
o
o
.
.
P
P
ó
ó
s
s
-
-
c
c
o
o
n
n
d
d
:
:
1
1
.
.
É
É
e
e
n
n
v
v
i
i
a
a
d
d
o
o
e
e
-
-
m
m
a
a
i
i
l
l
p
p
a
a
r
r
a
a
o
o
p
p
a
a
l
l
e
e
s
s
t
t
r
r
a
a
n
n
t
t
e
e
c
c
o
o
m
m
o
o
c
c
o
o
n
n
v
v
i
i
t
t
e
e
d
d
o
o
e
e
v
v
e
e
n
n
t
t
o
o
c
c
o
o
n
n
t
t
e
e
n
n
d
d
o
o
:
:
a
a
s
s
s
s
u
u
n
n
t
t
o
o
d
d
e
e
i
i
n
n
t
t
e
e
r
r
e
e
s
s
s
s
e
e
d
d
a
a
p
p
a
a
l
l
e
e
s
s
t
t
r
r
a
a
,
,
p
p
r
r
a
a
z
z
o
o
e
e
s
s
t
t
i
i
m
m
a
a
d
d
o
o
p
p
a
a
r
r
a
a
o
o
e
e
n
n
v
v
i
i
o
o
d
d
o
o
s
s
s
s
l
l
i
i
d
d
e
e
s
s
e
e
i
i
n
n
f
f
o
o
r
r
m
m
a
a
ç
ç
õ
õ
e
e
s
s
g
g
e
e
r
r
a
a
i
i
s
s
s
s
o
o
b
b
r
r
e
e
o
o
e
e
v
v
e
e
n
n
t
t
o
o
.
.
S
S
í
í
m
m
b
b
o
o
l
l
o
o
E
E
m
m
i
i
t
t
i
i
r
r
c
c
r
r
a
a
c
c
h
h
á
á
s
s
/
/
c
c
r
r
a
a
c
c
h
h
á
á
s
s
e
e
m
m
i
i
t
t
i
i
d
d
o
o
s
s
C
C
a
a
t
t
e
e
g
g
o
o
r
r
i
i
a
a
V
V
e
e
r
r
b
b
o
o
N
N
o
o
ç
ç
ã
ã
o
o
A
A
ç
ç
ã
ã
o
o
r
r
e
e
a
a
l
l
i
i
z
z
a
a
d
d
a
a
p
p
e
e
l
l
a
a
c
c
o
o
m
m
i
i
s
s
s
s
ã
ã
o
o
A
A
c
c
o
o
n
n
t
t
e
e
c
c
e
e
q
q
u
u
a
a
n
n
d
d
o
o
:
:
f
f
a
a
l
l
t
t
a
a
m
m
t
t
r
r
ê
ê
s
s
d
d
i
i
a
a
s
s
p
p
a
a
r
r
a
a
o
o
i
i
n
n
i
i
c
c
i
i
o
o
d
d
o
o
e
e
v
v
e
e
n
n
t
t
o
o
I
I
m
m
p
p
a
a
c
c
t
t
o
o
1
1
.
.
c
c
r
r
a
a
c
c
h
h
á
á
s
s
f
f
o
o
r
r
a
a
m
m
e
e
m
m
i
i
t
t
i
i
d
d
o
o
s
s
.
.
P
P
ó
ó
s
s
-
-
c
c
o
o
n
n
d
d
:
:
1
1
.
.
c
c
r
r
a
a
c
c
h
h
á
á
s
s
s
s
ã
ã
o
o
r
r
e
e
c
c
e
e
b
b
i
i
d
d
o
o
s
s
p
p
e
e
l
l
o
o
s
s
p
p
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
n
n
t
t
e
e
s
s
S
S
í
í
m
m
b
b
o
o
l
l
o
o
E
E
m
m
i
i
t
t
i
i
r
r
c
c
e
e
r
r
t
t
i
i
f
f
i
i
c
c
a
a
d
d
o
o
s
s
/
/
c
c
e
e
r
r
t
t
i
i
f
f
i
i
c
c
a
a
d
d
o
o
s
s
e
e
m
m
i
i
t
t
i
i
d
d
o
o
s
s
C
C
a
a
t
t
e
e
g
g
o
o
r
r
i
i
a
a
V
V
e
e
r
r
b
b
o
o
N
N
o
o
ç
ç
ã
ã
o
o
A
A
ç
ç
ã
ã
o
o
r
r
e
e
a
a
l
l
i
i
z
z
a
a
d
d
a
a
p
p
e
e
l
l
a
a
c
c
o
o
m
m
i
i
s
s
s
s
ã
ã
o
o
A
A
c
c
o
o
n
n
t
t
e
e
c
c
e
e
q
q
u
u
a
a
n
n
d
d
o
o
:
:
f
f
a
a
l
l
t
t
a
a
u
u
m
m
d
d
i
i
a
a
p
p
a
a
r
r
a
a
o
o
t
t
e
e
r
r
m
m
i
i
n
n
o
o
d
d
o
o
e
e
v
v
e
e
n
n
t
t
o
o
I
I
m
m
p
p
a
a
c
c
t
t
o
o
1
1
.
.
c
c
e
e
r
r
t
t
i
i
f
f
i
i
c
c
a
a
d
d
o
o
s
s
f
f
o
o
r
r
a
a
m
m
e
e
m
m
i
i
t
t
i
i
d
d
o
o
s
s
.
.
S
S
í
í
m
m
b
b
o
o
l
l
o
o
E
E
l
l
a
a
b
b
o
o
r
r
a
a
r
r
p
p
r
r
o
o
g
g
r
r
a
a
m
m
a
a
ç
ç
ã
ã
o
o
/
/
p
p
r
r
o
o
g
g
r
r
a
a
m
m
a
a
ç
ç
ã
ã
o
o
e
e
l
l
a
a
b
b
o
o
r
r
a
a
d
d
a
a
/
/
a
a
t
t
u
u
a
a
l
l
i
i
z
z
a
a
r
r
p
p
r
r
o
o
g
g
r
r
a
a
m
m
a
a
ç
ç
ã
ã
o
o
/
/
p
p
r
r
o
o
g
g
r
r
a
a
m
m
a
a
ç
ç
ã
ã
o
o
a
a
t
t
u
u
a
a
l
l
i
i
z
z
a
a
d
d
a
a
C
C
a
a
t
t
e
e
g
g
o
o
r
r
i
i
a
a
V
V
e
e
r
r
b
b
o
o
N
N
o
o
ç
ç
ã
ã
o
o
A
A
ç
ç
ã
ã
o
o
r
r
e
e
a
a
l
l
i
i
z
z
a
a
d
d
a
a
p
p
e
e
l
l
a
a
c
c
o
o
m
m
i
i
s
s
s
s
ã
ã
o
o
A
A
c
c
o
o
n
n
t
t
e
e
c
c
e
e
q
q
u
u
a
a
n
n
d
d
o
o
a
a
c
c
o
o
m
m
i
i
s
s
s
s
ã
ã
o
o
p
p
o
o
s
s
s
s
u
u
i
i
p
p
a
a
l
l
e
e
s
s
t
t
r
r
a
a
n
n
t
t
e
e
(
(
s
s
)
)
e
e
/
/
o
o
u
u
m
m
i
i
n
n
i
i
s
s
t
t
r
r
a
a
n
n
t
t
e
e
e
e
/
/
o
o
u
u
a
a
p
p
r
r
e
e
s
s
e
e
n
n
t
t
a
a
d
d
o
o
r
r
a
a
s
s
e
e
r
r
i
i
n
n
c
c
l
l
u
u
í
í
d
d
o
o
n
n
a
a
p
p
r
r
o
o
g
g
r
r
a
a
m
m
a
a
ç
ç
ã
ã
o
o
P
P
r
r
é
é
-
-
c
c
o
o
n
n
d
d
:
:
I
I
m
m
p
p
a
a
c
c
t
t
o
o
1
1
.
.
p
p
r
r
o
o
g
g
r
r
a
a
m
m
a
a
ç
ç
ã
ã
o
o
f
f
o
o
i
i
a
a
t
t
u
u
a
a
l
l
i
i
z
z
a
a
d
d
a
a
.
.
S
S
í
í
m
m
b
b
o
o
l
l
o
o
C
C
a
a
d
d
a
a
s
s
t
t
r
r
a
a
r
r
p
p
a
a
r
r
c
c
e
e
i
i
r
r
o
o
s
s
/
/
p
p
a
a
r
r
c
c
e
e
i
i
r
r
o
o
s
s
c
c
a
a
d
d
a
a
s
s
t
t
r
r
a
a
d
d
o
o
s
s
C
C
a
a
t
t
e
e
g
g
o
o
r
r
i
i
a
a
V
V
e
e
r
r
b
b
o
o
N
N
o
o
ç
ç
ã
ã
o
o
A
A
ç
ç
ã
ã
o
o
r
r
e
e
a
a
l
l
i
i
z
z
a
a
d
d
a
a
p
p
e
e
l
l
a
a
c
c
o
o
m
m
i
i
s
s
s
s
ã
ã
o
o
A
A
c
c
o
o
n
n
t
t
e
e
c
c
e
e
q
q
u
u
a
a
n
n
d
d
o
o
a
a
c
c
o
o
m
m
i
i
s
s
s
s
ã
ã
o
o
p
p
o
o
s
s
s
s
u
u
i
i
p
p
a
a
r
r
c
c
e
e
i
i
r
r
o
o
s
s
a
a
s
s
e
e
r
r
e
e
m
m
i
i
n
n
c
c
l
l
u
u
í
í
d
d
o
o
s
s
p
p
a
a
r
r
a
a
u
u
m
m
e
e
v
v
e
e
n
n
t
t
o
o
P
P
r
r
é
é
-
-
c
c
o
o
n
n
d
d
:
:
1
1
.
.
O
O
e
e
v
v
e
e
n
n
t
t
o
o
e
e
s
s
t
t
á
á
a
a
b
b
e
e
r
r
t
t
o
o
I
I
m
m
p
p
a
a
c
c
t
t
o
o
1
1
.
.
p
p
a
a
r
r
c
c
e
e
i
i
r
r
o
o
f
f
o
o
i
i
c
c
a
a
d
d
a
a
s
s
t
t
r
r
a
a
d
d
o
o
.
.
S
S
í
í
m
m
b
b
o
o
l
l
o
o
S
S
e
e
l
l
e
e
c
c
i
i
o
o
n
n
a
a
r
r
t
t
r
r
a
a
b
b
a
a
l
l
h
h
o
o
/
/
t
t
r
r
a
a
b
b
a
a
l
l
h
h
o
o
s
s
e
e
l
l
e
e
c
c
i
i
o
o
n
n
a
a
d
d
o
o
C
C
a
a
t
t
e
e
g
g
o
o
r
r
i
i
a
a
V
V
e
e
r
r
b
b
o
o
N
N
o
o
ç
ç
ã
ã
o
o
A
A
ç
ç
ã
ã
o
o
r
r
e
e
a
a
l
l
i
i
z
z
a
a
d
d
a
a
p
p
e
e
l
l
o
o
c
c
o
o
m
m
i
i
t
t
ê
ê
A
A
c
c
o
o
n
n
t
t
e
e
c
c
e
e
q
q
u
u
a
a
n
n
d
d
o
o
a
a
c
c
o
o
m
m
i
i
t
t
ê
ê
p
p
o
o
s
s
s
s
u
u
i
i
t
t
r
r
a
a
b
b
a
a
l
l
h
h
o
o
s
s
a
a
s
s
e
e
r
r
e
e
m
m
s
s
e
e
l
l
e
e
c
c
i
i
o
o
n
n
a
a
d
d
o
o
s
s
p
p
a
a
r
r
a
a
u
u
m
m
5.
Experimentação
: Controle de Eventos Científicos 127
e
e
v
v
e
e
n
n
t
t
o
o
P
P
r
r
é
é
-
-
c
c
o
o
n
n
d
d
:
:
E
E
v
v
e
e
n
n
t
t
o
o
p
p
o
o
s
s
s
s
u
u
i
i
v
v
a
a
g
g
a
a
s
s
n
n
o
o
s
s
h
h
o
o
r
r
á
á
r
r
i
i
o
o
s
s
d
d
e
e
p
p
r
r
o
o
g
g
r
r
a
a
m
m
a
a
ç
ç
ã
ã
o
o
I
I
m
m
p
p
a
a
c
c
t
t
o
o
1
1
.
.
t
t
r
r
a
a
b
b
a
a
l
l
h
h
o
o
f
f
o
o
i
i
s
s
e
e
l
l
e
e
c
c
i
i
o
o
n
n
a
a
d
d
o
o
.
.
S
S
í
í
m
m
b
b
o
o
l
l
o
o
F
F
o
o
r
r
n
n
e
e
c
c
e
e
r
r
r
r
e
e
c
c
u
u
r
r
s
s
o
o
s
s
/
/
r
r
e
e
c
c
u
u
r
r
s
s
o
o
s
s
f
f
o
o
r
r
n
n
e
e
c
c
i
i
d
d
o
o
s
s
C
C
a
a
t
t
e
e
g
g
o
o
r
r
i
i
a
a
V
V
e
e
r
r
b
b
o
o
N
N
o
o
ç
ç
ã
ã
o
o
A
A
ç
ç
ã
ã
o
o
r
r
e
e
a
a
l
l
i
i
z
z
a
a
d
d
a
a
p
p
e
e
l
l
o
o
s
s
p
p
a
a
r
r
c
c
e
e
i
i
r
r
o
o
s
s
A
A
c
c
o
o
n
n
t
t
e
e
c
c
e
e
q
q
u
u
a
a
n
n
d
d
o
o
o
o
p
p
a
a
r
r
c
c
e
e
i
i
r
r
o
o
p
p
o
o
s
s
s
s
u
u
i
i
r
r
e
e
c
c
u
u
r
r
s
s
o
o
s
s
p
p
a
a
r
r
a
a
o
o
e
e
v
v
e
e
n
n
t
t
o
o
P
P
r
r
é
é
-
-
c
c
o
o
n
n
d
d
:
:
1
1
.
.
p
p
a
a
r
r
c
c
e
e
i
i
r
r
o
o
e
e
s
s
t
t
á
á
c
c
a
a
d
d
a
a
s
s
t
t
r
r
a
a
d
d
o
o
p
p
a
a
r
r
a
a
o
o
e
e
v
v
e
e
n
n
t
t
o
o
e
e
v
v
e
e
n
n
t
t
o
o
e
e
s
s
t
t
á
á
e
e
m
m
a
a
b
b
e
e
r
r
t
t
o
o
I
I
m
m
p
p
a
a
c
c
t
t
o
o
1
1
.
.
r
r
e
e
c
c
u
u
r
r
s
s
o
o
s
s
f
f
o
o
r
r
a
a
m
m
f
f
o
o
r
r
n
n
e
e
c
c
i
i
d
d
o
o
s
s
.
.
S
S
í
í
m
m
b
b
o
o
l
l
o
o
R
R
e
e
c
c
e
e
b
b
e
e
r
r
p
p
a
a
g
g
a
a
m
m
e
e
n
n
t
t
o
o
_
_
r
r
e
e
c
c
u
u
r
r
s
s
o
o
/
/
p
p
a
a
g
g
a
a
m
m
e
e
n
n
t
t
o
o
_
_
r
r
e
e
c
c
u
u
r
r
s
s
o
o
r
r
e
e
c
c
e
e
b
b
i
i
d
d
o
o
C
C
a
a
t
t
e
e
g
g
o
o
r
r
i
i
a
a
V
V
e
e
r
r
b
b
o
o
N
N
o
o
ç
ç
ã
ã
o
o
A
A
ç
ç
ã
ã
o
o
s
s
o
o
f
f
r
r
i
i
d
d
a
a
p
p
e
e
l
l
o
o
s
s
p
p
a
a
r
r
c
c
e
e
i
i
r
r
o
o
s
s
A
A
c
c
o
o
n
n
t
t
e
e
c
c
e
e
q
q
u
u
a
a
n
n
d
d
o
o
o
o
p
p
a
a
r
r
c
c
e
e
i
i
r
r
o
o
t
t
e
e
m
m
c
c
r
r
e
e
d
d
i
i
t
t
o
o
a
a
r
r
e
e
c
c
e
e
b
b
e
e
r
r
P
P
r
r
é
é
-
-
c
c
o
o
n
n
d
d
:
:
s
s
e
e
c
c
r
r
e
e
t
t
á
á
r
r
i
i
a
a
e
e
f
f
e
e
t
t
u
u
a
a
p
p
a
a
g
g
a
a
m
m
e
e
n
n
t
t
o
o
a
a
o
o
f
f
o
o
r
r
n
n
e
e
c
c
e
e
d
d
o
o
r
r
I
I
m
m
p
p
a
a
c
c
t
t
o
o
1
1
.
.
p
p
a
a
g
g
a
a
m
m
e
e
n
n
t
t
o
o
_
_
r
r
e
e
c
c
u
u
r
r
s
s
o
o
f
f
o
o
i
i
r
r
e
e
c
c
e
e
b
b
i
i
d
d
o
o
.
.
P
P
ó
ó
s
s
-
-
c
c
o
o
n
n
d
d
:
:
S
S
í
í
m
m
b
b
o
o
l
l
o
o
C
C
l
l
i
i
e
e
n
n
t
t
e
e
/
/
c
c
l
l
i
i
e
e
n
n
t
t
e
e
e
e
m
m
p
p
o
o
t
t
e
e
n
n
c
c
i
i
a
a
l
l
C
C
a
a
t
t
e
e
g
g
o
o
r
r
i
i
a
a
S
S
u
u
j
j
e
e
i
i
t
t
o
o
N
N
o
o
ç
ç
ã
ã
o
o
P
P
e
e
s
s
s
s
o
o
a
a
q
q
u
u
e
e
a
a
i
i
n
n
d
d
a
a
n
n
ã
ã
o
o
s
s
o
o
l
l
i
i
c
c
i
i
t
t
o
o
u
u
o
o
c
c
a
a
d
d
a
a
s
s
t
t
r
r
o
o
,
,
a
a
p
p
e
e
n
n
a
a
s
s
c
c
l
l
i
i
e
e
n
n
t
t
e
e
e
e
m
m
p
p
o
o
t
t
e
e
n
n
c
c
i
i
a
a
l
l
I
I
m
m
p
p
a
a
c
c
t
t
o
o
A
A
ç
ç
õ
õ
e
e
s
s
q
q
u
u
e
e
e
e
x
x
e
e
c
c
u
u
t
t
a
a
:
:
1
1
.
.
c
c
o
o
n
n
s
s
u
u
l
l
t
t
a
a
r
r
e
e
v
v
e
e
n
n
t
t
o
o
s
s
a
a
b
b
e
e
r
r
t
t
o
o
s
s
2
2
.
.
c
c
o
o
n
n
s
s
u
u
l
l
t
t
a
a
r
r
e
e
v
v
e
e
n
n
t
t
o
o
s
s
f
f
e
e
c
c
h
h
a
a
d
d
o
o
s
s
3
3
.
.
c
c
o
o
n
n
s
s
u
u
l
l
t
t
a
a
r
r
p
p
r
r
o
o
g
g
r
r
a
a
m
m
a
a
ç
ç
ã
ã
o
o
4
4
.
.
s
s
o
o
l
l
i
i
c
c
i
i
t
t
a
a
i
i
n
n
s
s
c
c
r
r
i
i
ç
ç
ã
ã
o
o
S
S
í
í
m
m
b
b
o
o
l
l
o
o
i
i
n
n
s
s
c
c
r
r
i
i
ç
ç
ã
ã
o
o
C
C
a
a
t
t
e
e
g
g
o
o
r
r
i
i
a
a
O
O
b
b
j
j
e
e
t
t
o
o
N
N
o
o
ç
ç
ã
ã
o
o
I
I
d
d
e
e
n
n
t
t
i
i
f
f
i
i
c
c
a
a
ç
ç
ã
ã
o
o
d
d
e
e
u
u
m
m
c
c
l
l
i
i
e
e
n
n
t
t
e
e
q
q
u
u
a
a
n
n
d
d
o
o
d
d
e
e
s
s
e
e
j
j
a
a
f
f
a
a
z
z
e
e
r
r
s
s
e
e
u
u
c
c
a
a
d
d
a
a
s
s
t
t
r
r
o
o
I
I
m
m
p
p
a
a
c
c
t
t
o
o
1
1
.
.
a
a
i
i
n
n
s
s
c
c
r
r
i
i
ç
ç
ã
ã
o
o
é
é
s
s
o
o
l
l
i
i
c
c
i
i
t
t
a
a
d
d
a
a
p
p
e
e
l
l
o
o
c
c
l
l
i
i
e
e
n
n
t
t
e
e
a
a
i
i
n
n
d
d
a
a
n
n
ã
ã
o
o
i
i
n
n
s
s
c
c
r
r
i
i
t
t
o
o
S
S
í
í
m
m
b
b
o
o
l
l
o
o
S
S
o
o
l
l
i
i
c
c
i
i
t
t
a
a
r
r
i
i
n
n
s
s
c
c
r
r
i
i
c
c
a
a
o
o
/
/
i
i
n
n
s
s
c
c
r
r
i
i
ç
ç
ã
ã
o
o
s
s
o
o
l
l
i
i
c
c
i
i
t
t
a
a
d
d
a
a
C
C
a
a
t
t
e
e
g
g
o
o
r
r
i
i
a
a
V
V
e
e
r
r
b
b
o
o
N
N
o
o
ç
ç
ã
ã
o
o
A
A
ç
ç
ã
ã
o
o
e
e
x
x
e
e
c
c
u
u
t
t
a
a
d
d
a
a
p
p
e
e
l
l
o
o
s
s
c
c
l
l
i
i
e
e
n
n
t
t
e
e
A
A
c
c
o
o
n
n
t
t
e
e
c
c
e
e
q
q
u
u
a
a
n
n
d
d
o
o
o
o
c
c
l
l
i
i
e
e
n
n
t
t
e
e
t
t
e
e
m
m
i
i
n
n
t
t
e
e
r
r
e
e
s
s
s
s
e
e
e
e
m
m
s
s
e
e
c
c
a
a
d
d
a
a
s
s
t
t
r
r
a
a
r
r
e
e
m
m
u
u
m
m
c
c
u
u
r
r
s
s
o
o
I
I
m
m
p
p
a
a
c
c
t
t
o
o
1
1
.
.
i
i
n
n
s
s
c
c
r
r
i
i
ç
ç
ã
ã
o
o
f
f
o
o
i
i
s
s
o
o
l
l
i
i
c
c
i
i
t
t
a
a
d
d
a
a
.
.
:
:
S
S
í
í
m
m
b
b
o
o
l
l
o
o
A
A
b
b
e
e
r
r
t
t
o
o
/
/
e
e
m
m
a
a
b
b
e
e
r
r
t
t
o
o
/
/
a
a
b
b
e
e
r
r
t
t
o
o
s
s
/
/
e
e
m
m
a
a
b
b
e
e
r
r
t
t
o
o
s
s
C
C
a
a
t
t
e
e
g
g
o
o
r
r
i
i
a
a
E
E
s
s
t
t
a
a
d
d
o
o
N
N
o
o
ç
ç
ã
ã
o
o
S
S
ã
ã
o
o
e
e
v
v
e
e
n
n
t
t
o
o
s
s
q
q
u
u
e
e
e
e
s
s
t
t
ã
ã
o
o
a
a
c
c
o
o
n
n
t
t
e
e
c
c
e
e
n
n
d
d
o
o
o
o
u
u
p
p
o
o
r
r
a
a
c
c
o
o
n
n
t
t
e
e
c
c
e
e
r
r
I
I
m
m
p
p
a
a
c
c
t
t
o
o
S
S
e
e
a
a
p
p
l
l
i
i
c
c
a
a
a
a
o
o
s
s
e
e
v
v
e
e
n
n
t
t
o
o
s
s
c
c
o
o
m
m
p
p
e
e
r
r
í
í
o
o
d
d
o
o
d
d
e
e
r
r
e
e
a
a
l
l
i
i
z
z
a
a
ç
ç
ã
ã
o
o
m
m
a
a
i
i
o
o
r
r
o
o
u
u
i
i
g
g
u
u
a
a
l
l
a
a
d
d
a
a
t
t
a
a
a
a
t
t
u
u
a
a
l
l
S
S
í
í
m
m
b
b
o
o
l
l
o
o
F
F
e
e
c
c
h
h
a
a
d
d
o
o
s
s
/
/
f
f
e
e
c
c
h
h
a
a
d
d
o
o
C
C
a
a
t
t
e
e
g
g
o
o
r
r
i
i
a
a
e
e
s
s
t
t
a
a
d
d
o
o
N
N
o
o
ç
ç
ã
ã
o
o
S
S
ã
ã
o
o
e
e
v
v
e
e
n
n
t
t
o
o
s
s
q
q
u
u
e
e
a
a
c
c
o
o
n
n
t
t
e
e
c
c
e
e
r
r
a
a
m
m
I
I
m
m
p
p
a
a
c
c
t
t
o
o
S
S
e
e
a
a
p
p
l
l
i
i
c
c
a
a
a
a
o
o
s
s
e
e
v
v
e
e
n
n
t
t
o
o
s
s
c
c
o
o
m
m
p
p
e
e
r
r
í
í
o
o
d
d
o
o
d
d
e
e
r
r
e
e
a
a
l
l
i
i
z
z
a
a
ç
ç
ã
ã
o
o
m
m
e
e
n
n
o
o
r
r
d
d
o
o
q
q
u
u
e
e
a
a
d
d
a
a
t
t
a
a
a
a
t
t
u
u
a
a
l
l
Vale salientar que os termos ou símbolos do LEL foram incluídos observando
-
se o principio do vocabulário mínimo e
de
circularidade.
Pode
-
se
verificar também
que algumas restrições
existentes nos requisitos
funcionais
não foram incluídas (restrições de tempo
–
mínimo
de 24 horas de
5.
Experimentação
: Controle de Eventos Científicos 128
antecedência,
sete
dias de antecedência, entre outros)
-
. Estas restrições serão incluída
s
à
parte
, como uma restrição OCL a ser incluída no LEL correspondente
.
Este tipo de
informação torna
-
se útil na confecção do diagrama, fazendo uma refer
ê
ncia expl
í
cita de
restrições
a serem incluídas.
A seguir foram incluídos os requisitos
não
funcionais
de acordo com a tabela
5.5.
T
ABELA
5.
5 –
I
NCLUSÃO DOS REQUISIT
OS NÃO FUNCIONAIS
R
R
e
e
q
q
u
u
i
i
s
s
i
i
t
t
o
o
s
s
n
n
ã
ã
o
o
f
f
u
u
n
n
c
c
i
i
o
o
n
n
a
a
i
i
s
s
R
R
e
e
q
q
u
u
i
i
s
s
i
i
t
t
o
o
f
f
u
u
n
n
c
c
i
i
o
o
n
n
a
a
l
l
p
p
r
r
i
i
m
m
á
á
r
r
i
i
o
o
R
R
e
e
q
q
u
u
i
i
s
s
i
i
t
t
o
o
e
e
s
s
p
p
e
e
c
c
í
í
f
f
i
i
c
c
o
o
E
E
s
s
t
t
r
r
a
a
t
t
é
é
g
g
i
i
a
a
d
d
e
e
s
s
a
a
t
t
i
i
s
s
f
f
a
a
ç
ç
ã
ã
o
o
S
S
í
í
m
m
b
b
o
o
l
l
o
o
d
d
o
o
L
L
E
E
L
L
a
a
f
f
e
e
t
t
a
a
d
d
o
o
Identificação
T
T
o
o
d
d
a
a
s
s
a
a
s
s
a
a
ç
ç
õ
õ
e
e
s
s
S
S
e
e
g
g
u
u
r
r
a
a
n
n
ç
ç
a
a
c
c
o
o
n
n
f
f
i
i
d
d
e
e
n
n
c
c
i
i
a
a
b
b
i
i
l
l
i
i
d
d
a
a
d
d
e
e
a
a
u
u
t
t
e
e
n
n
t
t
i
i
c
c
a
a
ç
ç
ã
ã
o
o
P
P
a
a
r
r
a
a
t
t
o
o
d
d
o
o
s
s
o
o
s
s
a
a
c
c
e
e
s
s
s
s
o
o
s
s
Identificação
T
T
o
o
d
d
a
a
s
s
a
a
s
s
a
a
ç
ç
õ
õ
e
e
s
s
d
d
e
e
a
a
t
t
u
u
a
a
l
l
i
i
z
z
a
a
ç
ç
ã
ã
o
o
S
S
e
e
g
g
u
u
r
r
a
a
n
n
ç
ç
a
a
i
i
n
n
t
t
e
e
g
g
r
r
i
i
d
d
a
a
d
d
e
e
a
a
u
u
t
t
e
e
n
n
t
t
i
i
c
c
a
a
ç
ç
ã
ã
o
o
P
P
a
a
r
r
a
a
t
t
o
o
d
d
o
o
s
s
o
o
s
s
a
a
c
c
e
e
s
s
s
s
o
o
s
s
d
d
e
e
a
a
t
t
u
u
a
a
l
l
i
i
z
z
a
a
ç
ç
ã
ã
o
o
O
bserva
ndo
a tabela 4.
3 do capítulo 4
,
pode
-
se verificar
que vários requisitos
não fun
cionais, apesar de não explicitados no contexto, poderiam ser aplicados ao projeto,
como: integridade, disponibilidade, usabilidade, entre outros. Porém,
para exemplificação,
foi utilizado
apenas o requisito não funcional que diz respeito à autorização de
acesso e
autenticação
(para acesso e atualização dos dados).
A seguir
é
apresentado os requisitos organizacionais
a serem incluídos no LEL
através da tabela 5.6.
T
ABELA
5.
6 –
I
NCLUSÃO DOS REQUISIT
OS ORGANIZACIONAIS
R
R
e
e
q
q
u
u
i
i
s
s
i
i
t
t
o
o
s
s
o
o
r
r
g
g
a
a
n
n
i
i
z
z
a
a
c
c
i
i
o
o
n
n
a
a
i
i
s
s
R
R
e
e
q
q
u
u
i
i
s
s
i
i
t
t
o
o
o
o
r
r
g
g
a
a
n
n
i
i
z
z
a
a
c
c
i
i
o
o
n
n
a
a
l
l
E
E
s
s
t
t
r
r
a
a
t
t
é
é
g
g
i
i
a
a
d
d
e
e
s
s
a
a
t
t
i
i
s
s
f
f
a
a
ç
ç
ã
ã
o
o
S
S
í
í
m
m
b
b
o
o
l
l
o
o
d
d
o
o
L
L
E
E
L
L
a
a
f
f
e
e
t
t
a
a
d
d
o
o
Verificar potencial
I
I
n
n
s
s
c
c
r
r
i
i
ç
ç
ã
ã
o
o
e
e
v
v
e
e
n
n
t
t
o
o
I
I
n
n
s
s
c
c
r
r
i
i
ç
ç
ã
ã
o
o
e
e
v
v
e
e
n
n
t
t
o
o
Validar
situação
E
E
f
f
e
e
t
t
u
u
a
a
r
r
P
P
a
a
g
g
a
a
m
m
e
e
n
n
t
t
o
o
A
A
p
p
l
l
i
i
c
c
a
a
r
r
d
d
e
e
s
s
c
c
o
o
n
n
t
t
o
o
E
E
f
f
e
e
t
t
u
u
a
a
r
r
p
p
a
a
g
g
a
a
m
m
e
e
n
n
t
t
o
o
C
C
l
l
i
i
e
e
n
n
t
t
e
e
s
s
V
V
I
I
P
P
E
E
m
m
i
i
t
t
i
i
r
r
c
c
a
a
r
r
t
t
ã
ã
o
o
-
-
C
C
l
l
i
i
e
e
n
n
t
t
e
e
V
V
I
I
P
P
I
I
n
n
s
s
c
c
r
r
i
i
ç
ç
ã
ã
o
o
e
e
v
v
e
e
n
n
t
t
o
o
5.
Experimentação
: Controle de Eventos Científicos 129
5
5
.
.
5
5
.
.
1
1
A
A
n
n
a
a
l
l
i
i
s
s
a
a
n
n
d
d
o
o
i
i
n
n
t
t
e
e
r
r
d
d
e
e
p
p
e
e
n
n
d
d
ê
ê
n
n
c
c
i
i
a
a
s
s
e
e
r
r
e
e
s
s
o
o
l
l
v
v
e
e
n
n
d
d
o
o
c
c
o
o
n
n
f
f
l
l
i
i
t
t
o
o
s
s
No nosso projeto, por termos poucos Requisitos não funcionais a serem
satisfeitos e poucos requisitos organizacionais foi mais simples.
Para cada requisito não funcional foi observado se a estratégia
de satisfação era
suficiente para operacionalizar o RNF e se ela contribuía positivamente ou negativamente
para isso. Esta informação é muito útil quando temos um sistema maior que envolve várias
autenticações diferentes ou dupla confirmação, por exemplo.
Apesar de ser uma influencia
negativa sob o ponto de vista do usuário, deve ser levado em conta o desejo do cliente e a
integridade do sistema como um todo.
Da mesma forma o requisito organizacional foi observado em termos de
satisfação e
influência nos
o
utros termos do LEL.
No nosso caso, não houve influencia
negativa, pois as checagens requisitadas são mais simples.
5
5
.
.
5
5
.
.
2
2
C
C
o
o
n
n
s
s
t
t
r
r
u
u
i
i
n
n
d
d
o
o
o
o
s
s
c
c
e
e
n
n
á
á
r
r
i
i
o
o
s
s
Para a construção de cenários
foi
segui
do
o padrão
estabelecido por
HADAD
(
1997
),
onde pode ser verificado
com mais detalhes no anexo C. Porém, de forma geral
apresenta como diretrizes principais o mapeamento da tabela 5.7.
T
ABELA
5.
7 –
M
APEAMENTO ENTRE OS T
ERMOS DO
LEL
Termos do LEL
Cenários
verbo
Cenário candidato
sujeito
Ator
objeto
R
ecurso
Assim, ao fi
nal do processo
o
s cenários
apresentados na tabela 5.
8
,
são
elaborados
com a
incorpora
ção
dos requisitos não funcionais
–
em azul,
e organizacionais
–
em
verde e restrições OCL – em rosa.
Em todos os impactos existentes devem ser tratados os requisitos não
funcionais. De acordo com as regras definidas por Cysneiros (2002) este tratamento é
verificado a cada passo existente nos episódios. Porém, para facilitar o entendimento
e a
leitura,
foi aplicada
a restrição uma única vez
. Porém,
caso seja necessário
, de
ve ser
coloca
do
a restrição extra no passo que a requer
(como pode ser observado em alguns
exemplos)
.
5.
Experimentação
: Controle de Eventos Científicos 130
T
ABELA
5.
8 –
C
ENÁRIOS DO
LEL
Título
C
C
o
o
n
n
s
s
u
u
l
l
t
t
a
a
r
r
e
e
v
v
e
e
n
n
t
t
o
o
s
s
e
e
m
m
a
a
b
b
e
e
r
r
t
t
o
o
Objetivo
P
P
r
r
o
o
c
c
e
e
d
d
i
i
m
m
e
e
n
n
t
t
o
o
p
p
a
a
r
r
a
a
q
q
u
u
a
a
n
n
d
d
o
o
d
d
e
e
s
s
e
e
j
j
a
a
-
-
s
s
e
e
c
c
o
o
n
n
h
h
e
e
c
c
e
e
r
r
t
t
o
o
d
d
o
o
s
s
o
o
s
s
e
e
v
v
e
e
n
n
t
t
o
o
s
s
q
q
u
u
e
e
e
e
s
s
t
t
ã
ã
o
o
e
e
m
m
a
a
b
b
e
e
r
r
t
t
o
o
Contexto
S
S
i
i
s
s
t
t
e
e
m
m
a
a
e
e
m
m
i
i
t
t
i
i
n
n
d
d
o
o
c
c
o
o
n
n
s
s
u
u
l
l
t
t
a
a
d
d
e
e
e
e
v
v
e
e
n
n
t
t
o
o
s
s
e
e
m
m
a
a
b
b
e
e
r
r
t
t
o
o
S
S
e
e
c
c
r
r
e
e
t
t
á
á
r
r
i
i
a
a
T
T
i
i
p
p
o
o
A
A
t
t
o
o
r
r
P
P
r
r
i
i
m
m
á
á
r
r
i
i
o
o
P
P
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
n
n
t
t
e
e
T
T
i
i
p
p
o
o
A
A
t
t
o
o
r
r
P
P
r
r
i
i
m
m
á
á
r
r
i
i
o
o
P
P
a
a
r
r
c
c
e
e
i
i
r
r
o
o
s
s
T
T
i
i
p
p
o
o
A
A
t
t
o
o
r
r
S
S
e
e
c
c
u
u
n
n
d
d
á
á
r
r
i
i
o
o
C
C
l
l
i
i
e
e
n
n
t
t
e
e
s
s
i
i
n
n
c
c
l
l
u
u
i
i
d
d
o
o
s
s
T
T
i
i
p
p
o
o
A
A
t
t
o
o
r
r
P
P
r
r
i
i
m
m
á
á
r
r
i
i
o
o
Atores
C
C
l
l
i
i
e
e
n
n
t
t
e
e
s
s
T
T
i
i
p
p
o
o
A
A
t
t
o
o
r
r
S
S
e
e
c
c
u
u
n
n
d
d
á
á
r
r
i
i
o
o
Recursos
e
e
v
v
e
e
n
n
t
t
o
o
Ep
isódios
1
1
.
.
S
S
i
i
s
s
t
t
e
e
m
m
a
a
e
e
x
x
i
i
b
b
e
e
e
e
v
v
e
e
n
n
t
t
o
o
s
s
e
e
m
m
a
a
b
b
e
e
r
r
t
t
o
o
2
2
.
.
E
E
v
v
e
e
n
n
t
t
o
o
s
s
e
e
m
m
a
a
b
b
e
e
r
r
t
t
o
o
s
s
ã
ã
o
o
c
c
o
o
n
n
s
s
u
u
l
l
t
t
a
a
d
d
o
o
s
s
.
.
Título
C
C
o
o
n
n
s
s
u
u
l
l
t
t
a
a
r
r
e
e
v
v
e
e
n
n
t
t
o
o
s
s
f
f
e
e
c
c
h
h
a
a
d
d
o
o
s
s
Objetivo
P
P
r
r
o
o
c
c
e
e
d
d
i
i
m
m
e
e
n
n
t
t
o
o
p
p
a
a
r
r
a
a
q
q
u
u
a
a
n
n
d
d
o
o
d
d
e
e
s
s
e
e
j
j
a
a
-
-
s
s
e
e
c
c
o
o
n
n
h
h
e
e
c
c
e
e
r
r
t
t
o
o
d
d
o
o
s
s
o
o
s
s
e
e
v
v
e
e
n
n
t
t
o
o
s
s
q
q
u
u
e
e
j
j
á
á
o
o
c
c
o
o
r
r
r
r
e
e
r
r
a
a
m
m
Contexto
S
S
i
i
s
s
t
t
e
e
m
m
a
a
e
e
m
m
i
i
t
t
i
i
n
n
d
d
o
o
c
c
o
o
n
n
s
s
u
u
l
l
t
t
a
a
d
d
e
e
e
e
v
v
e
e
n
n
t
t
o
o
s
s
f
f
e
e
c
c
h
h
a
a
d
d
o
o
s
s
S
S
e
e
c
c
r
r
e
e
t
t
á
á
r
r
i
i
a
a
T
T
i
i
p
p
o
o
A
A
t
t
o
o
r
r
P
P
r
r
i
i
m
m
á
á
r
r
i
i
o
o
P
P
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
n
n
t
t
e
e
T
T
i
i
p
p
o
o
A
A
t
t
o
o
r
r
P
P
r
r
i
i
m
m
á
á
r
r
i
i
o
o
P
P
a
a
r
r
c
c
e
e
i
i
r
r
o
o
s
s
T
T
i
i
p
p
o
o
A
A
t
t
o
o
r
r
S
S
e
e
c
c
u
u
n
n
d
d
á
á
r
r
i
i
o
o
C
C
l
l
i
i
e
e
n
n
t
t
e
e
s
s
i
i
n
n
c
c
l
l
u
u
i
i
d
d
o
o
s
s
T
T
i
i
p
p
o
o
A
A
t
t
o
o
r
r
P
P
r
r
i
i
m
m
á
á
r
r
i
i
o
o
Atores
C
C
l
l
i
i
e
e
n
n
t
t
e
e
s
s
T
T
i
i
p
p
o
o
A
A
t
t
o
o
r
r
S
S
e
e
c
c
u
u
n
n
d
d
á
á
r
r
i
i
o
o
Recursos
e
e
v
v
e
e
n
n
t
t
o
o
Episódios
1
1
.
.
S
S
i
i
s
s
t
t
e
e
m
m
a
a
e
e
x
x
i
i
b
b
e
e
e
e
v
v
e
e
n
n
t
t
o
o
s
s
f
f
e
e
c
c
h
h
a
a
d
d
o
o
s
s
2
2
.
.
E
E
v
v
e
e
n
n
t
t
o
o
s
s
f
f
e
e
c
c
h
h
a
a
d
d
o
o
s
s
s
s
ã
ã
o
o
c
c
o
o
n
n
s
s
u
u
l
l
t
t
a
a
d
d
o
o
s
s
.
.
Título
A
A
l
l
t
t
e
e
r
r
a
a
r
r
p
p
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
n
n
t
t
e
e
Objetivo
P
P
r
r
o
o
c
c
e
e
d
d
i
i
m
m
e
e
n
n
t
t
o
o
p
p
a
a
r
r
a
a
q
q
u
u
a
a
n
n
d
d
o
o
d
d
e
e
s
s
e
e
j
j
a
a
-
-
s
s
e
e
a
a
l
l
t
t
e
e
r
r
a
a
r
r
o
o
t
t
i
i
p
p
o
o
d
d
e
e
p
p
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
n
n
t
t
e
e
Contexto
S
S
i
i
s
s
t
t
e
e
m
m
a
a
e
e
m
m
i
i
t
t
i
i
n
n
d
d
o
o
a
a
l
l
t
t
e
e
r
r
a
a
ç
ç
ã
ã
o
o
d
d
e
e
p
p
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
n
n
t
t
e
e
d
d
o
o
e
e
v
v
e
e
n
n
t
t
o
o
S
S
e
e
c
c
r
r
e
e
t
t
á
á
r
r
i
i
a
a
T
T
i
i
p
p
o
o
A
A
t
t
o
o
r
r
P
P
r
r
i
i
m
m
á
á
r
r
i
i
o
o
Atores
C
C
o
o
m
m
i
i
t
t
ê
ê
T
T
i
i
p
p
o
o
A
A
t
t
o
o
r
r
P
P
r
r
i
i
m
m
á
á
r
r
i
i
o
o
Recursos
E
E
v
v
e
e
n
n
t
t
o
o
Episódios
R
R
e
e
s
s
t
t
r
r
i
i
ç
ç
ã
ã
o
o
:
:
D
D
e
e
v
v
e
e
t
t
e
e
r
r
c
c
o
o
n
n
f
f
i
i
d
d
e
e
n
n
c
c
i
i
a
a
b
b
i
i
l
l
i
i
d
d
a
a
d
d
e
e
,
,
s
s
e
e
n
n
d
d
o
o
a
a
e
e
s
s
t
t
r
r
a
a
t
t
é
é
g
g
i
i
a
a
d
d
e
e
s
s
a
a
t
t
i
i
s
s
f
f
a
a
ç
ç
ã
ã
o
o
:
:
i
i
d
d
e
e
n
n
t
t
i
i
f
f
i
i
c
c
a
a
ç
ç
ã
ã
o
o
,
,
a
a
u
u
t
t
e
e
n
n
t
t
i
i
c
c
a
a
ç
ç
ã
ã
o
o
.
.
1
1
.
.
S
S
e
e
c
c
r
r
e
e
t
t
á
á
r
r
i
i
a
a
/
/
c
c
o
o
m
m
i
i
t
t
ê
ê
i
i
d
d
e
e
n
n
t
t
i
i
f
f
i
i
c
c
a
a
o
o
p
p
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
n
n
t
t
e
e
.
.
2
2
.
.
s
s
e
e
c
c
r
r
e
e
t
t
á
á
r
r
i
i
a
a
/
/
c
c
o
o
m
m
i
i
t
t
ê
ê
s
s
e
e
l
l
e
e
c
c
i
i
o
o
n
n
a
a
o
o
e
e
v
v
e
e
n
n
t
t
o
o
n
n
o
o
q
q
u
u
a
a
l
l
o
o
p
p
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
n
n
t
t
e
e
d
d
e
e
v
v
e
e
s
s
e
e
r
r
a
a
l
l
t
t
e
e
r
r
a
a
d
d
o
o
.
.
3
3
.
.
s
s
e
e
c
c
r
r
e
e
t
t
á
á
r
r
i
i
a
a
/
/
c
c
o
o
m
m
i
i
t
t
ê
ê
a
a
l
l
t
t
e
e
r
r
a
a
o
o
p
p
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
n
n
t
t
e
e
.
.
R
R
e
e
s
s
t
t
r
r
i
i
ç
ç
ã
ã
o
o
:
:
D
D
e
e
v
v
e
e
t
t
e
e
r
r
i
i
n
n
t
t
e
e
g
g
r
r
i
i
d
d
a
a
d
d
e
e
,
,
s
s
e
e
n
n
d
d
o
o
a
a
e
e
s
s
t
t
r
r
a
a
t
t
é
é
g
g
i
i
a
a
d
d
e
e
s
s
a
a
t
t
i
i
s
s
f
f
a
a
ç
ç
ã
ã
o
o
:
:
i
i
d
d
e
e
n
n
t
t
i
i
f
f
i
i
c
c
a
a
ç
ç
ã
ã
o
o
,
,
a
a
u
u
t
t
e
e
n
n
t
t
i
i
c
c
a
a
ç
ç
ã
ã
o
o
.
.
R
R
e
e
s
s
t
t
r
r
i
i
ç
ç
ã
ã
o
o
:
:
m
m
i
i
n
n
d
d
e
e
2
2
4
4
h
h
o
o
r
r
a
a
s
s
d
d
e
e
a
a
n
n
t
t
e
e
c
c
e
e
d
d
ê
ê
n
n
c
c
i
i
a
a
d
d
a
a
d
d
a
a
t
t
a
a
i
i
n
n
i
i
c
c
i
i
o
o
d
d
o
o
e
e
v
v
e
e
n
n
t
t
o
o
4
4
.
.
p
p
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
n
n
t
t
e
e
é
é
a
a
l
l
t
t
e
e
r
r
a
a
d
d
o
o
.
.
5.
Experimentação
: Controle de Eventos Científicos 131
Título
E
E
x
x
c
c
l
l
u
u
i
i
r
r
p
p
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
n
n
t
t
e
e
Objetivo
P
P
r
r
o
o
c
c
e
e
d
d
i
i
m
m
e
e
n
n
t
t
o
o
p
p
a
a
r
r
a
a
q
q
u
u
a
a
n
n
d
d
o
o
d
d
e
e
s
s
e
e
j
j
a
a
-
-
s
s
e
e
e
e
x
x
c
c
l
l
u
u
i
i
r
r
o
o
p
p
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
n
n
t
t
e
e
d
d
e
e
u
u
m
m
e
e
v
v
e
e
n
n
t
t
o
o
Contexto
S
S
i
i
s
s
t
t
e
e
m
m
a
a
e
e
m
m
i
i
t
t
i
i
n
n
d
d
o
o
e
e
x
x
c
c
l
l
u
u
s
s
ã
ã
o
o
d
d
e
e
p
p
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
n
n
t
t
e
e
n
n
o
o
e
e
v
v
e
e
n
n
t
t
o
o
P
P
r
r
é
é
c
c
o
o
n
n
d
d
:
:
P
P
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
n
n
t
t
e
e
i
i
n
n
f
f
o
o
r
r
m
m
a
a
p
p
o
o
r
r
e
e
-
-
m
m
a
a
i
i
l
l
s
s
u
u
a
a
a
a
u
u
s
s
ê
ê
n
n
c
c
i
i
a
a
Atores
S
S
e
e
c
c
r
r
e
e
t
t
á
á
r
r
i
i
a
a
T
T
i
i
p
p
o
o
A
A
t
t
o
o
r
r
P
P
r
r
i
i
m
m
á
á
r
r
i
i
o
o
R
ecursos
E
E
v
v
e
e
n
n
t
t
o
o
Episódios
.
.
R
R
e
e
s
s
t
t
r
r
i
i
ç
ç
ã
ã
o
o
:
:
D
D
e
e
v
v
e
e
t
t
e
e
r
r
c
c
o
o
n
n
f
f
i
i
d
d
e
e
n
n
c
c
i
i
a
a
b
b
i
i
l
l
i
i
d
d
a
a
d
d
e
e
,
,
s
s
e
e
n
n
d
d
o
o
a
a
e
e
s
s
t
t
r
r
a
a
t
t
é
é
g
g
i
i
a
a
d
d
e
e
s
s
a
a
t
t
i
i
s
s
f
f
a
a
ç
ç
ã
ã
o
o
:
:
i
i
d
d
e
e
n
n
t
t
i
i
f
f
i
i
c
c
a
a
ç
ç
ã
ã
o
o
,
,
a
a
u
u
t
t
e
e
n
n
t
t
i
i
c
c
a
a
ç
ç
ã
ã
o
o
.
.
1
1
.
.
S
S
e
e
c
c
r
r
e
e
t
t
á
á
r
r
i
i
a
a
i
i
d
d
e
e
n
n
t
t
i
i
f
f
i
i
c
c
a
a
o
o
p
p
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
n
n
t
t
e
e
2
2
.
.
s
s
e
e
c
c
r
r
e
e
t
t
á
á
r
r
i
i
a
a
s
s
e
e
l
l
e
e
c
c
i
i
o
o
n
n
a
a
o
o
e
e
v
v
e
e
n
n
t
t
o
o
e
e
m
m
a
a
b
b
e
e
r
r
t
t
o
o
n
n
o
o
q
q
u
u
a
a
l
l
o
o
p
p
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
n
n
t
t
e
e
d
d
e
e
v
v
e
e
s
s
e
e
r
r
e
e
x
x
c
c
l
l
u
u
i
i
d
d
o
o
.
.
3
3
.
.
s
s
e
e
c
c
r
r
e
e
t
t
á
á
r
r
i
i
a
a
/
/
c
c
o
o
m
m
i
i
t
t
ê
ê
e
e
x
x
c
c
l
l
u
u
i
i
o
o
p
p
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
n
n
t
t
e
e
.
.
R
R
e
e
s
s
t
t
r
r
i
i
ç
ç
ã
ã
o
o
:
:
D
D
e
e
v
v
e
e
t
t
e
e
r
r
i
i
n
n
t
t
e
e
g
g
r
r
i
i
d
d
a
a
d
d
e
e
,
,
s
s
e
e
n
n
d
d
o
o
a
a
e
e
s
s
t
t
r
r
a
a
t
t
é
é
g
g
i
i
a
a
d
d
e
e
s
s
a
a
t
t
i
i
s
s
f
f
a
a
ç
ç
ã
ã
o
o
:
:
i
i
d
d
e
e
n
n
t
t
i
i
f
f
i
i
c
c
a
a
ç
ç
ã
ã
o
o
,
,
a
a
u
u
t
t
e
e
n
n
t
t
i
i
c
c
a
a
ç
ç
ã
ã
o
o
.
.
R
R
e
e
s
s
t
t
r
r
i
i
ç
ç
ã
ã
o
o
:
:
m
m
i
i
n
n
d
d
e
e
7
7
d
d
i
i
a
a
s
s
ú
ú
t
t
e
e
i
i
s
s
d
d
a
a
d
d
a
a
t
t
a
a
i
i
n
n
i
i
c
c
i
i
o
o
d
d
o
o
e
e
v
v
e
e
n
n
t
t
o
o
4
4
.
.
p
p
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
n
n
t
t
e
e
é
é
e
e
x
x
c
c
l
l
u
u
i
i
d
d
o
o
P
P
ó
ó
s
s
-
-
C
C
o
o
n
n
d
d
:
:
-
-
C
C
o
o
m
m
e
e
x
x
c
c
e
e
ç
ç
ã
ã
o
o
d
d
o
o
p
p
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
n
n
t
t
e
e
s
s
e
e
r
r
u
u
m
m
o
o
u
u
v
v
i
i
n
n
t
t
e
e
,
,
s
s
e
e
r
r
á
á
e
e
n
n
v
v
i
i
a
a
d
d
o
o
e
e
-
-
m
m
a
a
i
i
l
l
p
p
a
a
r
r
a
a
o
o
s
s
o
o
u
u
v
v
i
i
n
n
t
t
e
e
s
s
s
s
o
o
b
b
r
r
e
e
a
a
a
a
l
l
t
t
e
e
r
r
a
a
ç
ç
ã
ã
o
o
e
e
f
f
e
e
t
t
u
u
a
a
d
d
a
a
.
.
-
-
R
R
e
e
s
s
t
t
i
i
t
t
u
u
i
i
r
r
v
v
a
a
l
l
o
o
r
r
d
d
e
e
i
i
n
n
s
s
c
c
r
r
i
i
ç
ç
ã
ã
o
o
p
p
a
a
r
r
a
a
o
o
s
s
o
o
u
u
v
v
i
i
n
n
t
t
e
e
s
s
e
e
/
/
o
o
u
u
a
a
p
p
r
r
e
e
s
s
e
e
n
n
t
t
a
a
d
d
o
o
r
r
.
.
S
S
e
e
p
p
r
r
a
a
z
z
o
o
d
d
a
a
e
e
x
x
c
c
l
l
u
u
s
s
ã
ã
o
o
f
f
o
o
r
r
m
m
a
a
i
i
o
o
r
r
q
q
u
u
e
e
5
5
d
d
i
i
a
a
s
s
ú
ú
t
t
e
e
i
i
s
s
,
,
o
o
v
v
a
a
l
l
o
o
r
r
a
a
s
s
e
e
r
r
r
r
e
e
s
s
t
t
i
i
t
t
u
u
í
í
d
d
o
o
s
s
e
e
r
r
á
á
d
d
e
e
8
8
0
0
%
%
Título
C
C
o
o
n
n
s
s
u
u
l
l
t
t
a
a
r
r
p
p
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
n
n
t
t
e
e
s
s
Objetivo
P
P
r
r
o
o
c
c
e
e
d
d
i
i
m
m
e
e
n
n
t
t
o
o
p
p
a
a
r
r
a
a
q
q
u
u
a
a
n
n
d
d
o
o
d
d
e
e
s
s
e
e
j
j
a
a
-
-
s
s
e
e
c
c
o
o
n
n
h
h
e
e
c
c
e
e
r
r
o
o
s
s
p
p
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
n
n
t
t
e
e
s
s
d
d
e
e
u
u
m
m
e
e
v
v
e
e
n
n
t
t
o
o
e
e
m
m
a
a
b
b
e
e
r
r
t
t
o
o
o
o
u
u
f
f
e
e
c
c
h
h
a
a
d
d
o
o
Contexto
S
S
i
i
s
s
t
t
e
e
m
m
a
a
e
e
m
m
i
i
t
t
i
i
n
n
d
d
o
o
c
c
o
o
n
n
s
s
u
u
l
l
t
t
a
a
d
d
e
e
p
p
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
n
n
t
t
e
e
n
n
o
o
e
e
v
v
e
e
n
n
t
t
o
o
P
P
r
r
é
é
c
c
o
o
n
n
d
d
:
:
S
S
e
e
c
c
r
r
e
e
t
t
á
á
r
r
i
i
a
a
T
T
i
i
p
p
o
o
A
A
t
t
o
o
r
r
P
P
r
r
i
i
m
m
á
á
r
r
i
i
o
o
Atores
C
C
o
o
m
m
i
i
s
s
s
s
ã
ã
o
o
T
T
i
i
p
p
o
o
A
A
t
t
o
o
r
r
P
P
r
r
i
i
m
m
á
á
r
r
i
i
o
o
Recursos
E
E
v
v
e
e
n
n
t
t
o
o
Episódios
R
R
e
e
s
s
t
t
r
r
i
i
ç
ç
ã
ã
o
o
:
:
D
D
e
e
v
v
e
e
t
t
e
e
r
r
c
c
o
o
n
n
f
f
i
i
d
d
e
e
n
n
c
c
i
i
a
a
b
b
i
i
l
l
i
i
d
d
a
a
d
d
e
e
,
,
s
s
e
e
n
n
d
d
o
o
a
a
e
e
s
s
t
t
r
r
a
a
t
t
é
é
g
g
i
i
a
a
d
d
e
e
s
s
a
a
t
t
i
i
s
s
f
f
a
a
ç
ç
ã
ã
o
o
:
:
i
i
d
d
e
e
n
n
t
t
i
i
f
f
i
i
c
c
a
a
ç
ç
ã
ã
o
o
,
,
a
a
u
u
t
t
e
e
n
n
t
t
i
i
c
c
a
a
ç
ç
ã
ã
o
o
.
.
1
1
.
.
S
S
e
e
S
S
e
e
c
c
r
r
e
e
t
t
á
á
r
r
i
i
a
a
/
/
C
C
o
o
m
m
i
i
s
s
s
s
ã
ã
o
o
i
i
d
d
e
e
n
n
t
t
i
i
f
f
i
i
c
c
a
a
o
o
p
p
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
n
n
t
t
e
e
.
.
E
E
n
n
t
t
ã
ã
o
o
S
S
e
e
S
S
e
e
c
c
r
r
e
e
t
t
á
á
r
r
i
i
a
a
/
/
c
c
o
o
m
m
i
i
s
s
s
s
ã
ã
o
o
s
s
e
e
l
l
e
e
c
c
i
i
o
o
n
n
a
a
t
t
i
i
p
p
o
o
d
d
e
e
e
e
v
v
e
e
n
n
t
t
o
o
E
E
n
n
t
t
ã
ã
o
o
c
c
o
o
n
n
s
s
u
u
l
l
t
t
a
a
e
e
v
v
e
e
n
n
t
t
o
o
s
s
e
e
s
s
p
p
e
e
c
c
í
í
f
f
i
i
c
c
o
o
s
s
c
c
o
o
m
m
p
p
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
n
n
t
t
e
e
S
S
e
e
n
n
ã
ã
o
o
c
c
o
o
n
n
s
s
u
u
l
l
t
t
a
a
e
e
v
v
e
e
n
n
t
t
o
o
s
s
c
c
o
o
m
m
p
p
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
n
n
t
t
e
e
.
.
S
S
e
e
n
n
ã
ã
o
o
S
S
e
e
S
S
e
e
c
c
r
r
e
e
t
t
á
á
r
r
i
i
a
a
/
/
c
c
o
o
m
m
i
i
s
s
s
s
ã
ã
o
o
s
s
e
e
l
l
e
e
c
c
i
i
o
o
n
n
a
a
t
t
i
i
p
p
o
o
d
d
e
e
e
e
v
v
e
e
n
n
t
t
o
o
E
E
n
n
t
t
ã
ã
o
o
c
c
o
o
n
n
s
s
u
u
l
l
t
t
a
a
t
t
o
o
d
d
o
o
s
s
o
o
s
s
p
p
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
n
n
t
t
e
e
s
s
d
d
o
o
e
e
v
v
e
e
n
n
t
t
o
o
s
s
e
e
l
l
e
e
c
c
i
i
o
o
n
n
a
a
d
d
o
o
S
S
e
e
n
n
ã
ã
o
o
c
c
o
o
n
n
s
s
u
u
l
l
t
t
a
a
t
t
o
o
d
d
o
o
s
s
o
o
s
s
p
p
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
n
n
t
t
e
e
s
s
e
e
m
m
t
t
o
o
d
d
o
o
s
s
o
o
s
s
e
e
v
v
e
e
n
n
t
t
o
o
s
s
2
2
.
.
p
p
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
n
n
t
t
e
e
s
s
s
s
ã
ã
o
o
c
c
o
o
n
n
s
s
u
u
l
l
t
t
a
a
d
d
o
o
s
s
.
.
Título
C
C
a
a
d
d
a
a
s
s
t
t
r
r
a
a
r
r
e
e
v
v
e
e
n
n
t
t
o
o
Objetivo
P
P
r
r
o
o
c
c
e
e
d
d
i
i
m
m
e
e
n
n
t
t
o
o
p
p
a
a
r
r
a
a
q
q
u
u
a
a
n
n
d
d
o
o
é
é
r
r
e
e
c
c
e
e
b
b
i
i
d
d
o
o
p
p
e
e
l
l
a
a
e
e
m
m
p
p
r
r
e
e
s
s
a
a
u
u
m
m
e
e
v
v
e
e
n
n
t
t
o
o
p
p
a
a
r
r
a
a
g
g
e
e
r
r
e
e
n
n
c
c
i
i
a
a
r
r
Contexto
S
S
i
i
s
s
t
t
e
e
m
m
a
a
e
e
m
m
i
i
t
t
i
i
n
n
d
d
o
o
c
c
a
a
d
d
a
a
s
s
t
t
r
r
o
o
d
d
o
o
e
e
v
v
e
e
n
n
t
t
o
o
P
P
r
r
é
é
c
c
o
o
n
n
d
d
:
:
Atores
S
S
e
e
c
c
r
r
e
e
t
t
á
á
r
r
i
i
a
a
T
T
i
i
p
p
o
o
A
A
t
t
o
o
r
r
P
P
r
r
i
i
m
m
á
á
r
r
i
i
o
o
Recursos
E
E
v
v
e
e
n
n
t
t
o
o
Episódios
R
R
e
e
s
s
t
t
r
r
i
i
ç
ç
ã
ã
o
o
:
:
D
D
e
e
v
v
e
e
t
t
e
e
r
r
c
c
o
o
n
n
f
f
i
i
d
d
e
e
n
n
c
c
i
i
a
a
b
b
i
i
l
l
i
i
d
d
a
a
d
d
e
e
,
,
s
s
e
e
n
n
d
d
o
o
a
a
e
e
s
s
t
t
r
r
a
a
t
t
é
é
g
g
i
i
a
a
d
d
e
e
s
s
a
a
t
t
i
i
s
s
f
f
a
a
ç
ç
ã
ã
o
o
:
:
i
i
d
d
e
e
n
n
t
t
i
i
f
f
i
i
c
c
a
a
ç
ç
ã
ã
o
o
,
,
a
a
u
u
t
t
e
e
n
n
t
t
i
i
c
c
a
a
ç
ç
ã
ã
o
o
.
.
5.
Experimentação
: Controle de Eventos Científicos 132
1
1
.
.
S
S
e
e
c
c
r
r
e
e
t
t
á
á
r
r
i
i
a
a
f
f
o
o
r
r
n
n
e
e
c
c
e
e
i
i
n
n
f
f
o
o
r
r
m
m
a
a
ç
ç
õ
õ
e
e
s
s
s
s
o
o
b
b
r
r
e
e
o
o
e
e
v
v
e
e
n
n
t
t
o
o
.
.
2
2
.
.
S
S
e
e
c
c
r
r
e
e
t
t
á
á
r
r
i
i
a
a
c
c
a
a
d
d
a
a
s
s
t
t
r
r
a
a
e
e
v
v
e
e
n
n
t
t
o
o
.
.
R
R
e
e
s
s
t
t
r
r
i
i
ç
ç
ã
ã
o
o
:
:
D
D
e
e
v
v
e
e
t
t
e
e
r
r
i
i
n
n
t
t
e
e
g
g
r
r
i
i
d
d
a
a
d
d
e
e
,
,
s
s
e
e
n
n
d
d
o
o
a
a
e
e
s
s
t
t
r
r
a
a
t
t
é
é
g
g
i
i
a
a
d
d
e
e
s
s
a
a
t
t
i
i
s
s
f
f
a
a
ç
ç
ã
ã
o
o
:
:
i
i
d
d
e
e
n
n
t
t
i
i
f
f
i
i
c
c
a
a
ç
ç
ã
ã
o
o
,
,
a
a
u
u
t
t
e
e
n
n
t
t
i
i
c
c
a
a
ç
ç
ã
ã
o
o
.
.
3
3
.
.
e
e
v
v
e
e
n
n
t
t
o
o
é
é
c
c
a
a
d
d
a
a
s
s
t
t
r
r
a
a
d
d
o
o
Título
C
C
a
a
d
d
a
a
s
s
t
t
r
r
a
a
r
r
c
c
o
o
m
m
i
i
s
s
s
s
ã
ã
o
o
Objetivo
P
P
r
r
o
o
c
c
e
e
d
d
i
i
m
m
e
e
n
n
t
t
o
o
p
p
a
a
r
r
a
a
q
q
u
u
a
a
n
n
d
d
o
o
d
d
e
e
s
s
e
e
j
j
a
a
-
-
s
s
e
e
c
c
a
a
d
d
a
a
s
s
t
t
r
r
a
a
r
r
a
a
c
c
o
o
m
m
i
i
s
s
s
s
ã
ã
o
o
o
o
r
r
g
g
a
a
n
n
i
i
z
z
a
a
d
d
o
o
r
r
a
a
d
d
o
o
e
e
v
v
e
e
n
n
t
t
o
o
Contexto
S
S
i
i
s
s
t
t
e
e
m
m
a
a
e
e
m
m
i
i
t
t
i
i
n
n
d
d
o
o
c
c
a
a
d
d
a
a
s
s
t
t
r
r
o
o
d
d
a
a
c
c
o
o
m
m
i
i
s
s
s
s
ã
ã
o
o
P
P
r
r
é
é
c
c
o
o
n
n
d
d
:
:
Atores
S
S
e
e
c
c
r
r
e
e
t
t
á
á
r
r
i
i
a
a
T
T
i
i
p
p
o
o
A
A
t
t
o
o
r
r
P
P
r
r
i
i
m
m
á
á
r
r
i
i
o
o
Recursos
E
E
v
v
e
e
n
n
t
t
o
o
Episódios
R
R
e
e
s
s
t
t
r
r
i
i
ç
ç
ã
ã
o
o
:
:
D
D
e
e
v
v
e
e
t
t
e
e
r
r
c
c
o
o
n
n
f
f
i
i
d
d
e
e
n
n
c
c
i
i
a
a
b
b
i
i
l
l
i
i
d
d
a
a
d
d
e
e
,
,
s
s
e
e
n
n
d
d
o
o
a
a
e
e
s
s
t
t
r
r
a
a
t
t
é
é
g
g
i
i
a
a
d
d
e
e
s
s
a
a
t
t
i
i
s
s
f
f
a
a
ç
ç
ã
ã
o
o
:
:
i
i
d
d
e
e
n
n
t
t
i
i
f
f
i
i
c
c
a
a
ç
ç
ã
ã
o
o
,
,
a
a
u
u
t
t
e
e
n
n
t
t
i
i
c
c
a
a
ç
ç
ã
ã
o
o
.
.
1
1
.
.
S
S
e
e
c
c
r
r
e
e
t
t
á
á
r
r
i
i
a
a
s
s
e
e
l
l
e
e
c
c
i
i
o
o
n
n
a
a
e
e
v
v
e
e
n
n
t
t
o
o
e
e
m
m
a
a
b
b
e
e
r
r
t
t
o
o
.
.
2
2
.
.
S
S
e
e
c
c
r
r
e
e
t
t
á
á
r
r
i
i
a
a
f
f
o
o
r
r
n
n
e
e
c
c
e
e
i
i
n
n
f
f
o
o
r
r
m
m
a
a
ç
ç
õ
õ
e
e
s
s
s
s
o
o
b
b
r
r
e
e
a
a
c
c
o
o
m
m
i
i
s
s
s
s
ã
ã
o
o
.
.
3
3
.
.
S
S
e
e
c
c
r
r
e
e
t
t
á
á
r
r
i
i
a
a
c
c
a
a
d
d
a
a
s
s
t
t
r
r
a
a
a
a
c
c
o
o
m
m
i
i
s
s
s
s
ã
ã
o
o
.
.
R
R
e
e
s
s
t
t
r
r
i
i
ç
ç
ã
ã
o
o
:
:
D
D
e
e
v
v
e
e
t
t
e
e
r
r
i
i
n
n
t
t
e
e
g
g
r
r
i
i
d
d
a
a
d
d
e
e
,
,
s
s
e
e
n
n
d
d
o
o
a
a
e
e
s
s
t
t
r
r
a
a
t
t
é
é
g
g
i
i
a
a
d
d
e
e
s
s
a
a
t
t
i
i
s
s
f
f
a
a
ç
ç
ã
ã
o
o
:
:
i
i
d
d
e
e
n
n
t
t
i
i
f
f
i
i
c
c
a
a
ç
ç
ã
ã
o
o
,
,
a
a
u
u
t
t
e
e
n
n
t
t
i
i
c
c
a
a
ç
ç
ã
ã
o
o
.
.
4
4
.
.
C
C
o
o
m
m
i
i
s
s
s
s
ã
ã
o
o
é
é
c
c
a
a
d
d
a
a
s
s
t
t
r
r
a
a
d
d
a
a
Título
C
C
a
a
d
d
a
a
s
s
t
t
r
r
a
a
r
r
c
c
o
o
m
m
i
i
t
t
ê
ê
O
bjetivo
P
P
r
r
o
o
c
c
e
e
d
d
i
i
m
m
e
e
n
n
t
t
o
o
p
p
a
a
r
r
a
a
q
q
u
u
a
a
n
n
d
d
o
o
d
d
e
e
s
s
e
e
j
j
a
a
-
-
s
s
e
e
c
c
a
a
d
d
a
a
s
s
t
t
r
r
a
a
r
r
o
o
c
c
o
o
m
m
i
i
t
t
ê
ê
c
c
i
i
e
e
n
n
t
t
í
í
f
f
i
i
c
c
o
o
d
d
o
o
e
e
v
v
e
e
n
n
t
t
o
o
Contexto
S
S
i
i
s
s
t
t
e
e
m
m
a
a
e
e
m
m
i
i
t
t
i
i
n
n
d
d
o
o
c
c
a
a
d
d
a
a
s
s
t
t
r
r
o
o
d
d
o
o
c
c
o
o
m
m
i
i
t
t
ê
ê
P
P
r
r
é
é
c
c
o
o
n
n
d
d
:
:
Atores
S
S
e
e
c
c
r
r
e
e
t
t
á
á
r
r
i
i
a
a
T
T
i
i
p
p
o
o
A
A
t
t
o
o
r
r
P
P
r
r
i
i
m
m
á
á
r
r
i
i
o
o
Recursos
E
E
v
v
e
e
n
n
t
t
o
o
Episódios
R
R
e
e
s
s
t
t
r
r
i
i
ç
ç
ã
ã
o
o
:
:
D
D
e
e
v
v
e
e
t
t
e
e
r
r
c
c
o
o
n
n
f
f
i
i
d
d
e
e
n
n
c
c
i
i
a
a
b
b
i
i
l
l
i
i
d
d
a
a
d
d
e
e
,
,
s
s
e
e
n
n
d
d
o
o
a
a
e
e
s
s
t
t
r
r
a
a
t
t
é
é
g
g
i
i
a
a
d
d
e
e
s
s
a
a
t
t
i
i
s
s
f
f
a
a
ç
ç
ã
ã
o
o
:
:
i
i
d
d
e
e
n
n
t
t
i
i
f
f
i
i
c
c
a
a
ç
ç
ã
ã
o
o
,
,
a
a
u
u
t
t
e
e
n
n
t
t
i
i
c
c
a
a
ç
ç
ã
ã
o
o
.
.
1
1
.
.
S
S
e
e
c
c
r
r
e
e
t
t
á
á
r
r
i
i
a
a
s
s
e
e
l
l
e
e
c
c
i
i
o
o
n
n
a
a
e
e
v
v
e
e
n
n
t
t
o
o
e
e
m
m
a
a
b
b
e
e
r
r
t
t
o
o
.
.
2
2
.
.
S
S
e
e
c
c
r
r
e
e
t
t
á
á
r
r
i
i
a
a
f
f
o
o
r
r
n
n
e
e
c
c
e
e
i
i
n
n
f
f
o
o
r
r
m
m
a
a
ç
ç
õ
õ
e
e
s
s
s
s
o
o
b
b
r
r
e
e
o
o
c
c
o
o
m
m
i
i
t
t
ê
ê
.
.
3
3
.
.
S
S
e
e
c
c
r
r
e
e
t
t
á
á
r
r
i
i
a
a
c
c
a
a
d
d
a
a
s
s
t
t
r
r
a
a
o
o
c
c
o
o
m
m
i
i
t
t
ê
ê
.
.
R
R
e
e
s
s
t
t
r
r
i
i
ç
ç
ã
ã
o
o
:
:
D
D
e
e
v
v
e
e
t
t
e
e
r
r
i
i
n
n
t
t
e
e
g
g
r
r
i
i
d
d
a
a
d
d
e
e
,
,
s
s
e
e
n
n
d
d
o
o
a
a
e
e
s
s
t
t
r
r
a
a
t
t
é
é
g
g
i
i
a
a
d
d
e
e
s
s
a
a
t
t
i
i
s
s
f
f
a
a
ç
ç
ã
ã
o
o
:
:
i
i
d
d
e
e
n
n
t
t
i
i
f
f
i
i
c
c
a
a
ç
ç
ã
ã
o
o
,
,
a
a
u
u
t
t
e
e
n
n
t
t
i
i
c
c
a
a
ç
ç
ã
ã
o
o
.
.
4
4
.
.
c
c
o
o
m
m
i
i
t
t
ê
ê
é
é
c
c
a
a
d
d
a
a
s
s
t
t
r
r
a
a
d
d
o
o
Título
R
R
e
e
c
c
e
e
b
b
e
e
r
r
r
r
e
e
c
c
u
u
r
r
s
s
o
o
s
s
Objetivo
P
P
r
r
o
o
c
c
e
e
d
d
i
i
m
m
e
e
n
n
t
t
o
o
p
p
a
a
r
r
a
a
q
q
u
u
a
a
n
n
d
d
o
o
é
é
f
f
o
o
r
r
n
n
e
e
c
c
i
i
d
d
o
o
r
r
e
e
c
c
u
u
r
r
s
s
o
o
s
s
p
p
e
e
l
l
o
o
s
s
p
p
a
a
r
r
c
c
e
e
i
i
r
r
o
o
s
s
p
p
a
a
r
r
a
a
o
o
e
e
v
v
e
e
n
n
t
t
o
o
Contexto
S
S
i
i
s
s
t
t
e
e
m
m
a
a
e
e
m
m
i
i
t
t
i
i
n
n
d
d
o
o
c
c
a
a
d
d
a
a
s
s
t
t
r
r
o
o
d
d
e
e
r
r
e
e
c
c
u
u
r
r
s
s
o
o
s
s
r
r
e
e
c
c
e
e
b
b
i
i
d
d
o
o
s
s
P
P
r
r
é
é
c
c
o
o
n
n
d
d
:
:
1
1
.
.
r
r
e
e
c
c
u
u
r
r
s
s
o
o
s
s
f
f
o
o
r
r
a
a
m
m
f
f
o
o
r
r
n
n
e
e
c
c
i
i
d
d
o
o
s
s
Atores
S
S
e
e
c
c
r
r
e
e
t
t
á
á
r
r
i
i
a
a
T
T
i
i
p
p
o
o
A
A
t
t
o
o
r
r
P
P
r
r
i
i
m
m
á
á
r
r
i
i
o
o
Recursos
E
E
v
v
e
e
n
n
t
t
o
o
,
,
r
r
e
e
c
c
u
u
r
r
s
s
o
o
s
s
Episódios
R
R
e
e
s
s
t
t
r
r
i
i
ç
ç
ã
ã
o
o
:
:
D
D
e
e
v
v
e
e
t
t
e
e
r
r
c
c
o
o
n
n
f
f
i
i
d
d
e
e
n
n
c
c
i
i
a
a
b
b
i
i
l
l
i
i
d
d
a
a
d
d
e
e
,
,
s
s
e
e
n
n
d
d
o
o
a
a
e
e
s
s
t
t
r
r
a
a
t
t
é
é
g
g
i
i
a
a
d
d
e
e
s
s
a
a
t
t
i
i
s
s
f
f
a
a
ç
ç
ã
ã
o
o
:
:
i
i
d
d
e
e
n
n
t
t
i
i
f
f
i
i
c
c
a
a
ç
ç
ã
ã
o
o
,
,
a
a
u
u
t
t
e
e
n
n
t
t
i
i
c
c
a
a
ç
ç
ã
ã
o
o
.
.
1
1
.
.
s
s
e
e
c
c
r
r
e
e
t
t
á
á
r
r
i
i
a
a
s
s
e
e
l
l
e
e
c
c
i
i
o
o
n
n
a
a
e
e
v
v
e
e
n
n
t
t
o
o
a
a
b
b
e
e
r
r
t
t
o
o
q
q
u
u
e
e
p
p
o
o
s
s
s
s
u
u
i
i
r
r
e
e
c
c
u
u
r
r
s
s
o
o
a
a
r
r
e
e
c
c
e
e
b
b
e
e
r
r
.
.
2
2
.
.
s
s
e
e
c
c
r
r
e
e
t
t
a
a
r
r
i
i
a
a
s
s
e
e
l
l
e
e
c
c
i
i
o
o
n
n
a
a
r
r
e
e
c
c
u
u
r
r
s
s
o
o
a
a
r
r
e
e
c
c
e
e
b
b
e
e
r
r
.
.
R
R
e
e
s
s
t
t
r
r
i
i
ç
ç
ã
ã
o
o
:
:
D
D
e
e
v
v
e
e
t
t
e
e
r
r
i
i
n
n
t
t
e
e
g
g
r
r
i
i
d
d
a
a
d
d
e
e
,
,
s
s
e
e
n
n
d
d
o
o
a
a
e
e
s
s
t
t
r
r
a
a
t
t
é
é
g
g
i
i
a
a
d
d
e
e
s
s
a
a
t
t
i
i
s
s
f
f
a
a
ç
ç
ã
ã
o
o
:
:
i
i
d
d
e
e
n
n
t
t
i
i
f
f
i
i
c
c
a
a
ç
ç
ã
ã
o
o
,
,
a
a
u
u
t
t
e
e
n
n
t
t
i
i
c
c
a
a
ç
ç
ã
ã
o
o
.
.
3
3
.
.
r
r
e
e
c
c
u
u
r
r
s
s
o
o
é
é
r
r
e
e
c
c
e
e
b
b
i
i
d
d
o
o
.
.
Título
D
D
i
i
s
s
t
t
r
r
i
i
b
b
u
u
i
i
r
r
r
r
e
e
c
c
u
u
r
r
s
s
o
o
s
s
Objetivo
P
P
r
r
o
o
c
c
e
e
d
d
i
i
m
m
e
e
n
n
t
t
o
o
p
p
a
a
r
r
a
a
q
q
u
u
a
a
n
n
d
d
o
o
é
é
d
d
i
i
s
s
t
t
r
r
i
i
b
b
u
u
í
í
d
d
o
o
o
o
s
s
r
r
e
e
c
c
u
u
r
r
s
s
o
o
s
s
p
p
a
a
r
r
a
a
o
o
s
s
e
e
v
v
e
e
n
n
t
t
o
o
s
s
5.
Experimentação
: Controle de Eventos Científicos 133
Contexto
S
S
i
i
s
s
t
t
e
e
m
m
a
a
e
e
m
m
i
i
t
t
i
i
n
n
d
d
o
o
d
d
i
i
s
s
t
t
r
r
i
i
b
b
u
u
i
i
ç
ç
ã
ã
o
o
d
d
e
e
r
r
e
e
c
c
u
u
r
r
s
s
o
o
s
s
p
p
a
a
r
r
a
a
o
o
s
s
e
e
v
v
e
e
n
n
t
t
o
o
s
s
P
P
r
r
é
é
c
c
o
o
n
n
d
d
:
:
1
1
.
.
r
r
e
e
c
c
u
u
r
r
s
s
o
o
s
s
f
f
o
o
r
r
a
a
m
m
r
r
e
e
c
c
e
e
b
b
i
i
d
d
o
o
s
s
p
p
e
e
l
l
a
a
s
s
e
e
c
c
r
r
e
e
t
t
a
a
r
r
i
i
a
a
Atores
S
S
e
e
c
c
r
r
e
e
t
t
á
á
r
r
i
i
a
a
T
T
i
i
p
p
o
o
A
A
t
t
o
o
r
r
P
P
r
r
i
i
m
m
á
á
r
r
i
i
o
o
Recursos
E
E
v
v
e
e
n
n
t
t
o
o
,
,
r
r
e
e
c
c
u
u
r
r
s
s
o
o
s
s
Episódios
R
R
e
e
s
s
t
t
r
r
i
i
ç
ç
ã
ã
o
o
:
:
D
D
e
e
v
v
e
e
t
t
e
e
r
r
c
c
o
o
n
n
f
f
i
i
d
d
e
e
n
n
c
c
i
i
a
a
b
b
i
i
l
l
i
i
d
d
a
a
d
d
e
e
,
,
s
s
e
e
n
n
d
d
o
o
a
a
e
e
s
s
t
t
r
r
a
a
t
t
é
é
g
g
i
i
a
a
d
d
e
e
s
s
a
a
t
t
i
i
s
s
f
f
a
a
ç
ç
ã
ã
o
o
:
:
i
i
d
d
e
e
n
n
t
t
i
i
f
f
i
i
c
c
a
a
ç
ç
ã
ã
o
o
,
,
a
a
u
u
t
t
e
e
n
n
t
t
i
i
c
c
a
a
ç
ç
ã
ã
o
o
.
.
1
1
.
.
s
s
e
e
c
c
r
r
e
e
t
t
á
á
r
r
i
i
a
a
s
s
e
e
l
l
e
e
c
c
i
i
o
o
n
n
a
a
r
r
e
e
c
c
u
u
r
r
s
s
o
o
r
r
e
e
c
c
e
e
b
b
i
i
d
d
o
o
e
e
n
n
ã
ã
o
o
d
d
i
i
s
s
t
t
r
r
i
i
b
b
u
u
i
i
d
d
o
o
2
2
.
.
s
s
e
e
c
c
r
r
e
e
t
t
a
a
r
r
i
i
a
a
s
s
e
e
l
l
e
e
c
c
i
i
o
o
n
n
a
a
a
a
t
t
i
i
v
v
i
i
d
d
a
a
d
d
e
e
(
(
s
s
)
)
d
d
o
o
e
e
v
v
e
e
n
n
t
t
o
o
a
a
s
s
e
e
r
r
r
r
e
e
l
l
a
a
c
c
i
i
o
o
n
n
a
a
d
d
a
a
c
c
o
o
m
m
r
r
e
e
c
c
u
u
r
r
s
s
o
o
.
.
R
R
e
e
s
s
t
t
r
r
i
i
ç
ç
ã
ã
o
o
:
:
D
D
e
e
v
v
e
e
t
t
e
e
r
r
i
i
n
n
t
t
e
e
g
g
r
r
i
i
d
d
a
a
d
d
e
e
,
,
s
s
e
e
n
n
d
d
o
o
a
a
e
e
s
s
t
t
r
r
a
a
t
t
é
é
g
g
i
i
a
a
d
d
e
e
s
s
a
a
t
t
i
i
s
s
f
f
a
a
ç
ç
ã
ã
o
o
:
:
i
i
d
d
e
e
n
n
t
t
i
i
f
f
i
i
c
c
a
a
ç
ç
ã
ã
o
o
,
,
a
a
u
u
t
t
e
e
n
n
t
t
i
i
c
c
a
a
ç
ç
ã
ã
o
o
.
.
3
3
.
.
r
r
e
e
c
c
u
u
r
r
s
s
o
o
é
é
d
d
i
i
s
s
t
t
r
r
i
i
b
b
u
u
i
i
d
d
o
o
.
.
Título
P
P
a
a
g
g
a
a
r
r
f
f
o
o
r
r
n
n
e
e
c
c
e
e
d
d
o
o
r
r
Objetivo
P
P
r
r
o
o
c
c
e
e
d
d
i
i
m
m
e
e
n
n
t
t
o
o
p
p
a
a
r
r
a
a
q
q
u
u
a
a
n
n
d
d
o
o
o
o
f
f
o
o
r
r
n
n
e
e
c
c
e
e
d
d
o
o
r
r
a
a
i
i
n
n
d
d
a
a
n
n
ã
ã
o
o
f
f
o
o
i
i
p
p
a
a
g
g
o
o
p
p
e
e
l
l
o
o
r
r
e
e
c
c
u
u
r
r
s
s
o
o
f
f
o
o
r
r
n
n
e
e
c
c
i
i
d
d
o
o
p
p
a
a
r
r
a
a
o
o
e
e
v
v
e
e
n
n
t
t
o
o
Contexto
S
S
i
i
s
s
t
t
e
e
m
m
a
a
e
e
m
m
i
i
t
t
i
i
n
n
d
d
o
o
p
p
a
a
g
g
a
a
m
m
e
e
n
n
t
t
o
o
p
p
o
o
r
r
r
r
e
e
c
c
u
u
r
r
s
s
o
o
r
r
e
e
c
c
e
e
b
b
i
i
d
d
o
o
d
d
o
o
s
s
e
e
v
v
e
e
n
n
t
t
o
o
s
s
P
P
r
r
é
é
c
c
o
o
n
n
d
d
:
:
1
1
.
.
r
r
e
e
c
c
u
u
r
r
s
s
o
o
s
s
f
f
o
o
r
r
a
a
m
m
r
r
e
e
c
c
e
e
b
b
i
i
d
d
o
o
s
s
p
p
e
e
l
l
a
a
s
s
e
e
c
c
r
r
e
e
t
t
a
a
r
r
i
i
a
a
Atores
S
S
e
e
c
c
r
r
e
e
t
t
á
á
r
r
i
i
a
a
T
T
i
i
p
p
o
o
A
A
t
t
o
o
r
r
P
P
r
r
i
i
m
m
á
á
r
r
i
i
o
o
Recursos
E
E
v
v
e
e
n
n
t
t
o
o
,
,
r
r
e
e
c
c
u
u
r
r
s
s
o
o
Episódios
R
R
e
e
s
s
t
t
r
r
i
i
ç
ç
ã
ã
o
o
:
:
D
D
e
e
v
v
e
e
t
t
e
e
r
r
c
c
o
o
n
n
f
f
i
i
d
d
e
e
n
n
c
c
i
i
a
a
b
b
i
i
l
l
i
i
d
d
a
a
d
d
e
e
,
,
s
s
e
e
n
n
d
d
o
o
a
a
e
e
s
s
t
t
r
r
a
a
t
t
é
é
g
g
i
i
a
a
d
d
e
e
s
s
a
a
t
t
i
i
s
s
f
f
a
a
ç
ç
ã
ã
o
o
:
:
i
i
d
d
e
e
n
n
t
t
i
i
f
f
i
i
c
c
a
a
ç
ç
ã
ã
o
o
,
,
a
a
u
u
t
t
e
e
n
n
t
t
i
i
c
c
a
a
ç
ç
ã
ã
o
o
.
.
1
1
.
.
s
s
e
e
c
c
r
r
e
e
t
t
á
á
r
r
i
i
a
a
s
s
e
e
l
l
e
e
c
c
i
i
o
o
n
n
a
a
r
r
e
e
c
c
u
u
r
r
s
s
o
o
r
r
e
e
c
c
e
e
b
b
i
i
d
d
o
o
e
e
n
n
ã
ã
o
o
p
p
a
a
g
g
o
o
2
2
.
.
s
s
e
e
c
c
r
r
e
e
t
t
a
a
r
r
i
i
a
a
p
p
a
a
g
g
a
a
f
f
o
o
r
r
n
n
e
e
c
c
e
e
d
d
o
o
r
r
d
d
o
o
r
r
e
e
c
c
u
u
r
r
s
s
o
o
.
.
R
R
e
e
s
s
t
t
r
r
i
i
ç
ç
ã
ã
o
o
:
:
D
D
e
e
v
v
e
e
t
t
e
e
r
r
i
i
n
n
t
t
e
e
g
g
r
r
i
i
d
d
a
a
d
d
e
e
,
,
s
s
e
e
n
n
d
d
o
o
a
a
e
e
s
s
t
t
r
r
a
a
t
t
é
é
g
g
i
i
a
a
d
d
e
e
s
s
a
a
t
t
i
i
s
s
f
f
a
a
ç
ç
ã
ã
o
o
:
:
i
i
d
d
e
e
n
n
t
t
i
i
f
f
i
i
c
c
a
a
ç
ç
ã
ã
o
o
,
,
a
a
u
u
t
t
e
e
n
n
t
t
i
i
c
c
a
a
ç
ç
ã
ã
o
o
.
.
3
3
.
.
f
f
o
o
r
r
n
n
e
e
c
c
e
e
d
d
o
o
r
r
é
é
p
p
a
a
g
g
o
o
.
.
P
P
ó
ó
s
s
-
-
c
c
o
o
n
n
d
d
:
:
1
1
.
.
F
F
o
o
r
r
n
n
e
e
c
c
e
e
d
d
o
o
r
r
r
r
e
e
c
c
e
e
b
b
e
e
p
p
a
a
g
g
a
a
m
m
e
e
n
n
t
t
o
o
_
_
r
r
e
e
c
c
u
u
r
r
s
s
o
o
Tít
ulo
R
R
e
e
c
c
e
e
b
b
e
e
r
r
p
p
a
a
g
g
a
a
m
m
e
e
n
n
t
t
o
o
Objetivo
P
P
r
r
o
o
c
c
e
e
d
d
i
i
m
m
e
e
n
n
t
t
o
o
p
p
a
a
r
r
a
a
q
q
u
u
a
a
n
n
d
d
o
o
a
a
s
s
e
e
c
c
r
r
e
e
t
t
a
a
r
r
i
i
a
a
a
a
i
i
n
n
d
d
a
a
n
n
ã
ã
o
o
r
r
e
e
c
c
e
e
b
b
e
e
u
u
p
p
a
a
g
g
a
a
m
m
e
e
n
n
t
t
o
o
r
r
e
e
f
f
e
e
r
r
e
e
n
n
t
t
e
e
a
a
i
i
n
n
s
s
c
c
r
r
i
i
ç
ç
ã
ã
o
o
d
d
o
o
o
o
u
u
v
v
i
i
n
n
t
t
e
e
e
e
/
/
o
o
u
u
a
a
p
p
r
r
e
e
s
s
e
e
n
n
t
t
a
a
d
d
o
o
r
r
Contexto
S
S
i
i
s
s
t
t
e
e
m
m
a
a
e
e
m
m
i
i
t
t
i
i
n
n
d
d
o
o
p
p
a
a
g
g
a
a
m
m
e
e
n
n
t
t
o
o
d
d
e
e
i
i
n
n
s
s
c
c
r
r
i
i
ç
ç
ã
ã
o
o
P
P
r
r
é
é
c
c
o
o
n
n
d
d
:
:
1
1
.
.
O
O
u
u
v
v
i
i
n
n
t
t
e
e
e
e
/
/
o
o
u
u
a
a
p
p
r
r
e
e
s
s
e
e
n
n
t
t
a
a
d
d
o
o
r
r
e
e
s
s
t
t
ã
ã
o
o
i
i
n
n
s
s
c
c
r
r
i
i
t
t
o
o
s
s
n
n
o
o
e
e
v
v
e
e
n
n
t
t
o
o
2
2
.
.
O
O
u
u
v
v
i
i
n
n
t
t
e
e
e
e
/
/
o
o
u
u
a
a
p
p
r
r
e
e
s
s
e
e
n
n
t
t
a
a
d
d
o
o
r
r
e
e
f
f
e
e
t
t
u
u
o
o
u
u
p
p
a
a
g
g
a
a
m
m
e
e
n
n
t
t
o
o
Atores
S
S
e
e
c
c
r
r
e
e
t
t
á
á
r
r
i
i
a
a
T
T
i
i
p
p
o
o
A
A
t
t
o
o
r
r
P
P
r
r
i
i
m
m
á
á
r
r
i
i
o
o
Recursos
E
E
v
v
e
e
n
n
t
t
o
o
,
,
r
r
e
e
c
c
u
u
r
r
s
s
o
o
Episódios
R
R
e
e
s
s
t
t
r
r
i
i
ç
ç
ã
ã
o
o
:
:
D
D
e
e
v
v
e
e
t
t
e
e
r
r
c
c
o
o
n
n
f
f
i
i
d
d
e
e
n
n
c
c
i
i
a
a
b
b
i
i
l
l
i
i
d
d
a
a
d
d
e
e
,
,
s
s
e
e
n
n
d
d
o
o
a
a
e
e
s
s
t
t
r
r
a
a
t
t
é
é
g
g
i
i
a
a
d
d
e
e
s
s
a
a
t
t
i
i
s
s
f
f
a
a
ç
ç
ã
ã
o
o
:
:
i
i
d
d
e
e
n
n
t
t
i
i
f
f
i
i
c
c
a
a
ç
ç
ã
ã
o
o
,
,
a
a
u
u
t
t
e
e
n
n
t
t
i
i
c
c
a
a
ç
ç
ã
ã
o
o
.
.
1
1
.
.
s
s
e
e
c
c
r
r
e
e
t
t
á
á
r
r
i
i
a
a
i
i
d
d
e
e
n
n
t
t
i
i
f
f
i
i
c
c
a
a
o
o
u
u
v
v
i
i
n
n
t
t
e
e
/
/
a
a
p
p
r
r
e
e
s
s
e
e
n
n
t
t
a
a
d
d
o
o
r
r
2
2
.
.
s
s
e
e
c
c
r
r
e
e
t
t
a
a
r
r
i
i
a
a
r
r
e
e
c
c
e
e
b
b
e
e
p
p
a
a
g
g
a
a
m
m
e
e
n
n
t
t
o
o
.
.
R
R
e
e
s
s
t
t
r
r
i
i
ç
ç
ã
ã
o
o
:
:
D
D
e
e
v
v
e
e
t
t
e
e
r
r
i
i
n
n
t
t
e
e
g
g
r
r
i
i
d
d
a
a
d
d
e
e
,
,
s
s
e
e
n
n
d
d
o
o
a
a
e
e
s
s
t
t
r
r
a
a
t
t
é
é
g
g
i
i
a
a
d
d
e
e
s
s
a
a
t
t
i
i
s
s
f
f
a
a
ç
ç
ã
ã
o
o
:
:
i
i
d
d
e
e
n
n
t
t
i
i
f
f
i
i
c
c
a
a
ç
ç
ã
ã
o
o
,
,
a
a
u
u
t
t
e
e
n
n
t
t
i
i
c
c
a
a
ç
ç
ã
ã
o
o
.
.
3
3
.
.
p
p
a
a
g
g
a
a
m
m
e
e
n
n
t
t
o
o
é
é
r
r
e
e
c
c
e
e
b
b
i
i
d
d
o
o
.
.
Título
C
C
o
o
n
n
s
s
u
u
l
l
t
t
a
a
r
r
p
p
r
r
o
o
g
g
r
r
a
a
m
m
a
a
ç
ç
ã
ã
o
o
Objetivo
P
P
r
r
o
o
c
c
e
e
d
d
i
i
m
m
e
e
n
n
t
t
o
o
p
p
a
a
r
r
a
a
q
q
u
u
a
a
n
n
d
d
o
o
d
d
e
e
s
s
e
e
j
j
a
a
-
-
s
s
e
e
c
c
o
o
n
n
h
h
e
e
c
c
e
e
r
r
a
a
p
p
r
r
o
o
g
g
r
r
a
a
m
m
a
a
ç
ç
ã
ã
o
o
d
d
o
o
e
e
v
v
e
e
n
n
t
t
o
o
5.
Experimentação
: Controle de Eventos Científicos 134
Contexto
S
S
i
i
s
s
t
t
e
e
m
m
a
a
e
e
m
m
i
i
t
t
i
i
n
n
d
d
o
o
c
c
o
o
n
n
s
s
u
u
l
l
t
t
a
a
d
d
e
e
p
p
r
r
o
o
g
g
r
r
a
a
m
m
a
a
ç
ç
ã
ã
o
o
d
d
o
o
e
e
v
v
e
e
n
n
t
t
o
o
p
p
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
n
n
t
t
e
e
T
T
i
i
p
p
o
o
A
A
t
t
o
o
r
r
P
P
r
r
i
i
m
m
á
á
r
r
i
i
o
o
p
p
a
a
r
r
c
c
e
e
i
i
r
r
o
o
s
s
T
T
i
i
p
p
o
o
a
a
t
t
o
o
r
r
p
p
r
r
i
i
m
m
a
a
r
r
i
i
o
o
c
c
l
l
i
i
e
e
n
n
t
t
e
e
T
T
i
i
p
p
o
o
a
a
t
t
o
o
r
r
s
s
e
e
c
c
u
u
n
n
d
d
a
a
r
r
i
i
o
o
Atores
C
C
l
l
i
i
e
e
n
n
t
t
e
e
i
i
n
n
s
s
c
c
r
r
i
i
t
t
o
o
T
T
i
i
p
p
o
o
a
a
t
t
o
o
r
r
p
p
r
r
i
i
m
m
a
a
r
r
i
i
o
o
Recursos
E
E
v
v
e
e
n
n
t
t
o
o
,
,
p
p
r
r
o
o
g
g
r
r
a
a
m
m
a
a
ç
ç
ã
ã
o
o
Episódios
1
1
.
.
p
p
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
n
n
t
t
e
e
/
/
p
p
a
a
r
r
c
c
e
e
i
i
r
r
o
o
s
s
/
/
c
c
l
l
i
i
e
e
n
n
t
t
e
e
/
/
c
c
l
l
i
i
e
e
n
n
t
t
e
e
i
i
n
n
s
s
c
c
r
r
i
i
t
t
o
o
s
s
e
e
l
l
e
e
c
c
i
i
o
o
n
n
a
a
e
e
v
v
e
e
n
n
t
t
o
o
2
2
.
.
p
p
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
n
n
t
t
e
e
/
/
p
p
a
a
r
r
c
c
e
e
i
i
r
r
o
o
s
s
/
/
c
c
l
l
i
i
e
e
n
n
t
t
e
e
/
/
c
c
l
l
i
i
e
e
n
n
t
t
e
e
i
i
n
n
s
s
c
c
r
r
i
i
t
t
o
o
c
c
o
o
n
n
s
s
u
u
l
l
t
t
a
a
p
p
r
r
o
o
g
g
r
r
a
a
m
m
a
a
ç
ç
ã
ã
o
o
d
d
o
o
e
e
v
v
e
e
n
n
t
t
o
o
.
.
3
3
.
.
p
p
r
r
o
o
g
g
r
r
a
a
m
m
a
a
ç
ç
ã
ã
o
o
é
é
c
c
o
o
n
n
s
s
u
u
l
l
t
t
a
a
d
d
a
a
.
.
Título
I
I
n
n
s
s
c
c
r
r
e
e
v
v
e
e
r
r
-
-
s
s
e
e
e
e
m
m
e
e
v
v
e
e
n
n
t
t
o
o
Objetivo
P
P
r
r
o
o
c
c
e
e
d
d
i
i
m
m
e
e
n
n
t
t
o
o
p
p
a
a
r
r
a
a
q
q
u
u
a
a
n
n
d
d
o
o
o
o
c
c
l
l
i
i
e
e
n
n
t
t
e
e
i
i
n
n
s
s
c
c
r
r
i
i
t
t
o
o
d
d
e
e
s
s
e
e
j
j
a
a
s
s
e
e
c
c
a
a
d
d
a
a
s
s
t
t
r
r
a
a
r
r
e
e
m
m
u
u
m
m
e
e
v
v
e
e
n
n
t
t
o
o
Contexto
S
S
i
i
s
s
t
t
e
e
m
m
a
a
e
e
m
m
i
i
t
t
i
i
n
n
d
d
o
o
c
c
a
a
d
d
a
a
s
s
t
t
r
r
o
o
d
d
e
e
i
i
n
n
s
s
c
c
r
r
i
i
ç
ç
ã
ã
o
o
n
n
o
o
e
e
v
v
e
e
n
n
t
t
o
o
Atores
C
C
l
l
i
i
e
e
n
n
t
t
e
e
i
i
n
n
s
s
c
c
r
r
i
i
t
t
o
o
T
T
i
i
p
p
o
o
a
a
t
t
o
o
r
r
p
p
r
r
i
i
m
m
a
a
r
r
i
i
o
o
Recursos
E
E
v
v
e
e
n
n
t
t
o
o
,
,
i
i
n
n
s
s
c
c
r
r
i
i
ç
ç
ã
ã
o
o
Episódios
R
R
e
e
s
s
t
t
r
r
i
i
ç
ç
ã
ã
o
o
:
:
D
D
e
e
v
v
e
e
t
t
e
e
r
r
c
c
o
o
n
n
f
f
i
i
d
d
e
e
n
n
c
c
i
i
a
a
b
b
i
i
l
l
i
i
d
d
a
a
d
d
e
e
,
,
s
s
e
e
n
n
d
d
o
o
a
a
e
e
s
s
t
t
r
r
a
a
t
t
é
é
g
g
i
i
a
a
d
d
e
e
s
s
a
a
t
t
i
i
s
s
f
f
a
a
ç
ç
ã
ã
o
o
:
:
i
i
d
d
e
e
n
n
t
t
i
i
f
f
i
i
c
c
a
a
ç
ç
ã
ã
o
o
,
,
a
a
u
u
t
t
e
e
n
n
t
t
i
i
c
c
a
a
ç
ç
ã
ã
o
o
.
.
1
1
.
.
c
c
l
l
i
i
e
e
n
n
t
t
e
e
i
i
n
n
s
s
c
c
r
r
i
i
t
t
o
o
s
s
e
e
l
l
e
e
c
c
i
i
o
o
n
n
a
a
e
e
v
v
e
e
n
n
t
t
o
o
e
e
m
m
a
a
b
b
e
e
r
r
t
t
o
o
2
2
.
.
c
c
l
l
i
i
e
e
n
n
t
t
e
e
s
s
o
o
l
l
i
i
c
c
i
i
t
t
a
a
i
i
n
n
s
s
c
c
r
r
i
i
ç
ç
ã
ã
o
o
.
.
R
R
e
e
s
s
t
t
r
r
i
i
ç
ç
ã
ã
o
o
:
:
D
D
e
e
v
v
e
e
t
t
e
e
r
r
i
i
n
n
t
t
e
e
g
g
r
r
i
i
d
d
a
a
d
d
e
e
,
,
s
s
e
e
n
n
d
d
o
o
a
a
e
e
s
s
t
t
r
r
a
a
t
t
é
é
g
g
i
i
a
a
d
d
e
e
s
s
a
a
t
t
i
i
s
s
f
f
a
a
ç
ç
ã
ã
o
o
:
:
i
i
d
d
e
e
n
n
t
t
i
i
f
f
i
i
c
c
a
a
ç
ç
ã
ã
o
o
,
,
a
a
u
u
t
t
e
e
n
n
t
t
i
i
c
c
a
a
ç
ç
ã
ã
o
o
3
3
.
.
S
S
e
e
C
C
P
P
F
F
_
_
c
c
l
l
i
i
e
e
n
n
t
t
e
e
e
e
n
n
t
t
ã
ã
o
o
i
i
n
n
s
s
c
c
r
r
i
i
ç
ç
ã
ã
o
o
é
é
c
c
a
a
d
d
a
a
s
s
t
t
r
r
a
a
d
d
a
a
.
.
.
.
R
R
e
e
s
s
t
t
r
r
i
i
ç
ç
ã
ã
o
o
:
:
S
S
e
e
V
V
a
a
l
l
i
i
d
d
a
a
r
r
s
s
i
i
t
t
u
u
a
a
ç
ç
ã
ã
o
o
e
e
n
n
t
t
ã
ã
o
o
a
a
p
p
l
l
i
i
c
c
a
a
r
r
d
d
e
e
s
s
c
c
o
o
n
n
t
t
o
o
s
s
e
e
n
n
ã
ã
o
o
s
s
e
e
v
v
e
e
r
r
i
i
f
f
i
i
c
c
a
a
r
r
p
p
o
o
t
t
e
e
n
n
c
c
i
i
a
a
l
l
e
e
n
n
t
t
ã
ã
o
o
e
e
m
m
i
i
t
t
i
i
r
r
c
c
a
a
r
r
t
t
ã
ã
o
o
.
.
P
P
o
o
s
s
c
c
o
o
n
n
d
d
:
:
1
1
.
.
e
e
f
f
e
e
t
t
u
u
a
a
r
r
p
p
a
a
g
g
a
a
m
m
e
e
n
n
t
t
o
o
d
d
e
e
i
i
n
n
s
s
c
c
r
r
i
i
ç
ç
ã
ã
o
o
Título
E
E
n
n
v
v
i
i
a
a
r
r
t
t
r
r
a
a
b
b
a
a
l
l
h
h
o
o
Objetivo
P
P
r
r
o
o
c
c
e
e
d
d
i
i
m
m
e
e
n
n
t
t
o
o
p
p
a
a
r
r
a
a
q
q
u
u
a
a
n
n
d
d
o
o
o
o
a
a
p
p
r
r
e
e
s
s
e
e
n
n
t
t
a
a
d
d
o
o
r
r
d
d
e
e
s
s
e
e
j
j
a
a
e
e
n
n
v
v
i
i
a
a
r
r
t
t
r
r
a
a
b
b
a
a
l
l
h
h
o
o
p
p
a
a
r
r
a
a
s
s
e
e
l
l
e
e
ç
ç
ã
ã
o
o
e
e
m
m
e
e
v
v
e
e
n
n
t
t
o
o
Contexto
S
S
i
i
s
s
t
t
e
e
m
m
a
a
e
e
m
m
i
i
t
t
i
i
n
n
d
d
o
o
c
c
a
a
d
d
a
a
s
s
t
t
r
r
o
o
d
d
e
e
t
t
r
r
a
a
b
b
a
a
l
l
h
h
o
o
Ator
a
a
p
p
r
r
e
e
s
s
e
e
n
n
t
t
a
a
d
d
o
o
r
r
T
T
i
i
p
p
o
o
a
a
t
t
o
o
r
r
p
p
r
r
i
i
m
m
a
a
r
r
i
i
o
o
Recursos
E
E
v
v
e
e
n
n
t
t
o
o
,
,
t
t
r
r
a
a
b
b
a
a
l
l
h
h
o
o
Episódios
R
R
e
e
s
s
t
t
r
r
i
i
ç
ç
ã
ã
o
o
:
:
D
D
e
e
v
v
e
e
t
t
e
e
r
r
c
c
o
o
n
n
f
f
i
i
d
d
e
e
n
n
c
c
i
i
a
a
b
b
i
i
l
l
i
i
d
d
a
a
d
d
e
e
,
,
s
s
e
e
n
n
d
d
o
o
a
a
e
e
s
s
t
t
r
r
a
a
t
t
é
é
g
g
i
i
a
a
d
d
e
e
s
s
a
a
t
t
i
i
s
s
f
f
a
a
ç
ç
ã
ã
o
o
:
:
i
i
d
d
e
e
n
n
t
t
i
i
f
f
i
i
c
c
a
a
ç
ç
ã
ã
o
o
,
,
a
a
u
u
t
t
e
e
n
n
t
t
i
i
c
c
a
a
ç
ç
ã
ã
o
o
.
.
1
1
.
.
a
a
p
p
r
r
e
e
s
s
e
e
n
n
t
t
a
a
d
d
o
o
r
r
s
s
e
e
l
l
e
e
c
c
i
i
o
o
n
n
a
a
e
e
v
v
e
e
n
n
t
t
o
o
e
e
m
m
a
a
b
b
e
e
r
r
t
t
o
o
2
2
.
.
a
a
p
p
r
r
e
e
s
s
e
e
n
n
t
t
a
a
d
d
o
o
r
r
i
i
d
d
e
e
n
n
t
t
i
i
f
f
i
i
c
c
a
a
t
t
r
r
a
a
b
b
a
a
l
l
h
h
o
o
.
.
R
R
e
e
s
s
t
t
r
r
i
i
ç
ç
ã
ã
o
o
:
:
D
D
e
e
v
v
e
e
t
t
e
e
r
r
i
i
n
n
t
t
e
e
g
g
r
r
i
i
d
d
a
a
d
d
e
e
,
,
s
s
e
e
n
n
d
d
o
o
a
a
e
e
s
s
t
t
r
r
a
a
t
t
é
é
g
g
i
i
a
a
d
d
e
e
s
s
a
a
t
t
i
i
s
s
f
f
a
a
ç
ç
ã
ã
o
o
:
:
i
i
d
d
e
e
n
n
t
t
i
i
f
f
i
i
c
c
a
a
ç
ç
ã
ã
o
o
,
,
a
a
u
u
t
t
e
e
n
n
t
t
i
i
c
c
a
a
ç
ç
ã
ã
o
o
.
.
3
3
.
.
a
a
p
p
r
r
e
e
s
s
e
e
n
n
t
t
a
a
d
d
o
o
r
r
c
c
a
a
d
d
a
a
s
s
t
t
r
r
a
a
t
t
r
r
a
a
b
b
a
a
l
l
h
h
o
o
4
4
.
.
t
t
r
r
a
a
b
b
a
a
l
l
h
h
o
o
é
é
e
e
n
n
v
v
i
i
a
a
d
d
o
o
.
.
Títu
lo
E
E
f
f
e
e
t
t
u
u
a
a
r
r
p
p
a
a
g
g
a
a
m
m
e
e
n
n
t
t
o
o
Objetivo
P
P
r
r
o
o
c
c
e
e
d
d
i
i
m
m
e
e
n
n
t
t
o
o
p
p
a
a
r
r
a
a
q
q
u
u
a
a
n
n
d
d
o
o
o
o
o
o
u
u
v
v
i
i
n
n
t
t
e
e
o
o
u
u
a
a
p
p
r
r
e
e
s
s
e
e
n
n
t
t
a
a
d
d
o
o
r
r
d
d
e
e
s
s
e
e
j
j
a
a
m
m
p
p
a
a
g
g
a
a
r
r
a
a
i
i
n
n
s
s
c
c
r
r
i
i
ç
ç
ã
ã
o
o
e
e
m
m
u
u
m
m
e
e
v
v
e
e
n
n
t
t
o
o
Contexto
S
S
i
i
s
s
t
t
e
e
m
m
a
a
e
e
f
f
e
e
t
t
u
u
a
a
n
n
d
d
o
o
p
p
a
a
g
g
a
a
m
m
e
e
n
n
t
t
o
o
d
d
e
e
i
i
n
n
s
s
c
c
r
r
i
i
ç
ç
ã
ã
o
o
n
n
o
o
e
e
v
v
e
e
n
n
t
t
o
o
a
a
p
p
r
r
e
e
s
s
e
e
n
n
t
t
a
a
d
d
o
o
r
r
T
T
i
i
p
p
o
o
a
a
t
t
o
o
r
r
p
p
r
r
i
i
m
m
a
a
r
r
i
i
o
o
Atores
o
o
u
u
v
v
i
i
n
n
t
t
e
e
T
T
i
i
p
p
o
o
a
a
t
t
o
o
r
r
p
p
r
r
i
i
m
m
a
a
r
r
i
i
o
o
Recursos
E
E
v
v
e
e
n
n
t
t
o
o
,
,
p
p
a
a
g
g
a
a
m
m
e
e
n
n
t
t
o
o
Episódios
R
R
e
e
s
s
t
t
r
r
i
i
ç
ç
ã
ã
o
o
:
:
D
D
e
e
v
v
e
e
t
t
e
e
r
r
c
c
o
o
n
n
f
f
i
i
d
d
e
e
n
n
c
c
i
i
a
a
b
b
i
i
l
l
i
i
d
d
a
a
d
d
e
e
,
,
s
s
e
e
n
n
d
d
o
o
a
a
e
e
s
s
t
t
r
r
a
a
t
t
é
é
g
g
i
i
a
a
d
d
e
e
s
s
a
a
t
t
i
i
s
s
f
f
a
a
ç
ç
ã
ã
o
o
:
:
i
i
d
d
e
e
n
n
t
t
i
i
f
f
i
i
c
c
a
a
ç
ç
ã
ã
o
o
,
,
a
a
u
u
t
t
e
e
n
n
t
t
i
i
c
c
a
a
ç
ç
ã
ã
o
o
.
.
1
1
.
.
a
a
p
p
r
r
e
e
s
s
e
e
n
n
t
t
a
a
d
d
o
o
r
r
/
/
o
o
u
u
v
v
i
i
n
n
t
t
e
e
s
s
e
e
l
l
e
e
c
c
i
i
o
o
n
n
a
a
e
e
v
v
e
e
n
n
t
t
o
o
e
e
m
m
a
a
b
b
e
e
r
r
t
t
o
o
n
n
o
o
q
q
u
u
a
a
l
l
e
e
s
s
t
t
a
a
i
i
n
n
s
s
c
c
r
r
i
i
t
t
o
o
2
2
.
.
a
a
p
p
r
r
e
e
s
s
e
e
n
n
t
t
a
a
d
d
o
o
r
r
/
/
o
o
u
u
v
v
i
i
n
n
t
t
e
e
e
e
f
f
e
e
t
t
u
u
a
a
p
p
a
a
g
g
a
a
m
m
e
e
n
n
t
t
o
o
.
.
R
R
e
e
s
s
t
t
r
r
i
i
ç
ç
ã
ã
o
o
:
:
D
D
e
e
v
v
e
e
t
t
e
e
r
r
i
i
n
n
t
t
e
e
g
g
r
r
i
i
d
d
a
a
d
d
e
e
,
,
s
s
e
e
n
n
d
d
o
o
a
a
5.
Experimentação
: Controle de Eventos Científicos 135
e
e
s
s
t
t
r
r
a
a
t
t
é
é
g
g
i
i
a
a
d
d
e
e
s
s
a
a
t
t
i
i
s
s
f
f
a
a
ç
ç
ã
ã
o
o
:
:
i
i
d
d
e
e
n
n
t
t
i
i
f
f
i
i
c
c
a
a
ç
ç
ã
ã
o
o
,
,
a
a
u
u
t
t
e
e
n
n
t
t
i
i
c
c
a
a
ç
ç
ã
ã
o
o
.
.
R
R
e
e
s
s
t
t
r
r
i
i
ç
ç
ã
ã
o
o
:
:
S
S
e
e
v
v
a
a
l
l
i
i
d
d
a
a
r
r
c
c
l
l
i
i
e
e
n
n
t
t
e
e
e
e
n
n
t
t
ã
ã
o
o
a
a
p
p
l
l
i
i
c
c
a
a
r
r
d
d
e
e
s
s
c
c
o
o
n
n
t
t
o
o
.
.
4
4
.
.
p
p
a
a
g
g
a
a
m
m
e
e
n
n
t
t
o
o
é
é
e
e
f
f
e
e
t
t
u
u
a
a
d
d
o
o
.
.
P
P
o
o
s
s
c
c
o
o
n
n
d
d
:
:
1
1
.
.
p
p
a
a
g
g
a
a
m
m
e
e
n
n
t
t
o
o
é
é
r
r
e
e
c
c
e
e
b
b
i
i
d
d
o
o
p
p
e
e
l
l
a
a
s
s
e
e
c
c
r
r
e
e
t
t
á
á
r
r
i
i
a
a
Título
E
E
n
n
v
v
i
i
a
a
r
r
p
p
a
a
l
l
e
e
s
s
t
t
r
r
a
a
Objet
ivo
P
P
r
r
o
o
c
c
e
e
d
d
i
i
m
m
e
e
n
n
t
t
o
o
p
p
a
a
r
r
a
a
q
q
u
u
a
a
n
n
d
d
o
o
o
o
p
p
a
a
l
l
e
e
s
s
t
t
r
r
a
a
n
n
t
t
e
e
d
d
e
e
s
s
e
e
j
j
a
a
e
e
n
n
v
v
i
i
a
a
r
r
p
p
a
a
l
l
e
e
s
s
t
t
r
r
a
a
p
p
a
a
r
r
a
a
s
s
e
e
l
l
e
e
ç
ç
ã
ã
o
o
e
e
m
m
e
e
v
v
e
e
n
n
t
t
o
o
Contexto
S
S
i
i
s
s
t
t
e
e
m
m
a
a
e
e
m
m
i
i
t
t
i
i
n
n
d
d
o
o
c
c
a
a
d
d
a
a
s
s
t
t
r
r
o
o
d
d
e
e
i
i
n
n
s
s
c
c
r
r
i
i
ç
ç
ã
ã
o
o
n
n
o
o
e
e
v
v
e
e
n
n
t
t
o
o
Atores
p
p
a
a
l
l
e
e
s
s
t
t
r
r
a
a
n
n
t
t
e
e
T
T
i
i
p
p
o
o
a
a
t
t
o
o
r
r
p
p
r
r
i
i
m
m
a
a
r
r
i
i
o
o
Recursos
E
E
v
v
e
e
n
n
t
t
o
o
,
,
p
p
a
a
l
l
e
e
s
s
t
t
r
r
a
a
Episódios
R
R
e
e
s
s
t
t
r
r
i
i
ç
ç
ã
ã
o
o
:
:
D
D
e
e
v
v
e
e
t
t
e
e
r
r
c
c
o
o
n
n
f
f
i
i
d
d
e
e
n
n
c
c
i
i
a
a
b
b
i
i
l
l
i
i
d
d
a
a
d
d
e
e
,
,
s
s
e
e
n
n
d
d
o
o
a
a
e
e
s
s
t
t
r
r
a
a
t
t
é
é
g
g
i
i
a
a
d
d
e
e
s
s
a
a
t
t
i
i
s
s
f
f
a
a
ç
ç
ã
ã
o
o
:
:
i
i
d
d
e
e
n
n
t
t
i
i
f
f
i
i
c
c
a
a
ç
ç
ã
ã
o
o
,
,
a
a
u
u
t
t
e
e
n
n
t
t
i
i
c
c
a
a
ç
ç
ã
ã
o
o
.
.
1
1
.
.
p
p
a
a
l
l
e
e
s
s
t
t
r
r
a
a
n
n
t
t
e
e
s
s
e
e
l
l
e
e
c
c
i
i
o
o
n
n
a
a
e
e
v
v
e
e
n
n
t
t
o
o
e
e
m
m
a
a
b
b
e
e
r
r
t
t
o
o
2
2
.
.
p
p
a
a
l
l
e
e
s
s
t
t
r
r
a
a
n
n
t
t
e
e
i
i
d
d
e
e
n
n
t
t
i
i
f
f
i
i
c
c
a
a
p
p
a
a
l
l
e
e
s
s
t
t
r
r
a
a
.
.
R
R
e
e
s
s
t
t
r
r
i
i
ç
ç
ã
ã
o
o
:
:
D
D
e
e
v
v
e
e
t
t
e
e
r
r
i
i
n
n
t
t
e
e
g
g
r
r
i
i
d
d
a
a
d
d
e
e
,
,
s
s
e
e
n
n
d
d
o
o
a
a
e
e
s
s
t
t
r
r
a
a
t
t
é
é
g
g
i
i
a
a
d
d
e
e
s
s
a
a
t
t
i
i
s
s
f
f
a
a
ç
ç
ã
ã
o
o
:
:
i
i
d
d
e
e
n
n
t
t
i
i
f
f
i
i
c
c
a
a
ç
ç
ã
ã
o
o
,
,
a
a
u
u
t
t
e
e
n
n
t
t
i
i
c
c
a
a
ç
ç
ã
ã
o
o
.
.
3
3
.
.
p
p
a
a
l
l
e
e
s
s
t
t
r
r
a
a
n
n
t
t
e
e
c
c
a
a
d
d
a
a
s
s
t
t
r
r
a
a
p
p
a
a
l
l
e
e
s
s
t
t
r
r
a
a
4
4
.
.
p
p
a
a
l
l
e
e
s
s
t
t
r
r
a
a
é
é
e
e
n
n
v
v
i
i
a
a
d
d
o
o
.
.
Título
E
E
n
n
v
v
i
i
a
a
r
r
m
m
a
a
t
t
e
e
r
r
i
i
a
a
l
l
Objetivo
P
P
r
r
o
o
c
c
e
e
d
d
i
i
m
m
e
e
n
n
t
t
o
o
p
p
a
a
r
r
a
a
q
q
u
u
a
a
n
n
d
d
o
o
o
o
m
m
i
i
n
n
i
i
s
s
t
t
r
r
a
a
n
n
t
t
e
e
d
d
e
e
s
s
e
e
j
j
a
a
e
e
n
n
v
v
i
i
a
a
r
r
m
m
a
a
t
t
e
e
r
r
i
i
a
a
l
l
p
p
a
a
r
r
a
a
s
s
e
e
l
l
e
e
ç
ç
ã
ã
o
o
e
e
m
m
e
e
v
v
e
e
n
n
t
t
o
o
Contexto
S
S
i
i
s
s
t
t
e
e
m
m
a
a
e
e
m
m
i
i
t
t
i
i
n
n
d
d
o
o
c
c
a
a
d
d
a
a
s
s
t
t
r
r
o
o
d
d
e
e
i
i
n
n
s
s
c
c
r
r
i
i
ç
ç
ã
ã
o
o
n
n
o
o
e
e
v
v
e
e
n
n
t
t
o
o
Atores
m
m
i
i
n
n
i
i
s
s
t
t
r
r
a
a
n
n
t
t
e
e
T
T
i
i
p
p
o
o
a
a
t
t
o
o
r
r
p
p
r
r
i
i
m
m
a
a
r
r
i
i
o
o
Recursos
E
E
v
v
e
e
n
n
t
t
o
o
,
,
m
m
a
a
t
t
e
e
r
r
i
i
a
a
l
l
Episódios
R
R
e
e
s
s
t
t
r
r
i
i
ç
ç
ã
ã
o
o
:
:
D
D
e
e
v
v
e
e
t
t
e
e
r
r
c
c
o
o
n
n
f
f
i
i
d
d
e
e
n
n
c
c
i
i
a
a
b
b
i
i
l
l
i
i
d
d
a
a
d
d
e
e
,
,
s
s
e
e
n
n
d
d
o
o
a
a
e
e
s
s
t
t
r
r
a
a
t
t
é
é
g
g
i
i
a
a
d
d
e
e
s
s
a
a
t
t
i
i
s
s
f
f
a
a
ç
ç
ã
ã
o
o
:
:
i
i
d
d
e
e
n
n
t
t
i
i
f
f
i
i
c
c
a
a
ç
ç
ã
ã
o
o
,
,
a
a
u
u
t
t
e
e
n
n
t
t
i
i
c
c
a
a
ç
ç
ã
ã
o
o
.
.
1
1
.
.
m
m
i
i
n
n
i
i
s
s
t
t
r
r
a
a
n
n
t
t
e
e
s
s
e
e
l
l
e
e
c
c
i
i
o
o
n
n
a
a
e
e
v
v
e
e
n
n
t
t
o
o
e
e
m
m
a
a
b
b
e
e
r
r
t
t
o
o
2
2
.
.
m
m
i
i
n
n
i
i
s
s
t
t
r
r
a
a
n
n
t
t
e
e
i
i
d
d
e
e
n
n
t
t
i
i
f
f
i
i
c
c
a
a
m
m
a
a
t
t
e
e
r
r
i
i
a
a
l
l
.
.
R
R
e
e
s
s
t
t
r
r
i
i
ç
ç
ã
ã
o
o
:
:
D
D
e
e
v
v
e
e
t
t
e
e
r
r
i
i
n
n
t
t
e
e
g
g
r
r
i
i
d
d
a
a
d
d
e
e
,
,
s
s
e
e
n
n
d
d
o
o
a
a
e
e
s
s
t
t
r
r
a
a
t
t
é
é
g
g
i
i
a
a
d
d
e
e
s
s
a
a
t
t
i
i
s
s
f
f
a
a
ç
ç
ã
ã
o
o
:
:
i
i
d
d
e
e
n
n
t
t
i
i
f
f
i
i
c
c
a
a
ç
ç
ã
ã
o
o
,
,
a
a
u
u
t
t
e
e
n
n
t
t
i
i
c
c
a
a
ç
ç
ã
ã
o
o
.
.
3
3
.
.
m
m
i
i
n
n
i
i
s
s
t
t
r
r
a
a
n
n
t
t
e
e
c
c
a
a
d
d
a
a
s
s
t
t
r
r
a
a
m
m
a
a
t
t
e
e
r
r
i
i
a
a
l
l
4
4
.
.
m
m
a
a
t
t
e
e
r
r
i
i
a
a
l
l
é
é
e
e
n
n
v
v
i
i
a
a
d
d
o
o
.
.
Título
E
E
n
n
v
v
i
i
a
a
r
r
r
r
e
e
q
q
u
u
i
i
s
s
i
i
ç
ç
ã
ã
o
o
Objetivo
P
P
r
r
o
o
c
c
e
e
d
d
i
i
m
m
e
e
n
n
t
t
o
o
p
p
a
a
r
r
a
a
q
q
u
u
a
a
n
n
d
d
o
o
o
o
m
m
i
i
n
n
i
i
s
s
t
t
r
r
a
a
n
n
t
t
e
e
d
d
e
e
s
s
e
e
j
j
a
a
e
e
n
n
v
v
i
i
a
a
r
r
r
r
e
e
q
q
u
u
i
i
s
s
i
i
ç
ç
a
a
o
o
e
e
m
m
e
e
v
v
e
e
n
n
t
t
o
o
Contexto
S
S
i
i
s
s
t
t
e
e
m
m
a
a
e
e
m
m
i
i
t
t
i
i
n
n
d
d
o
o
c
c
a
a
d
d
a
a
s
s
t
t
r
r
o
o
d
d
e
e
r
r
e
e
q
q
u
u
i
i
s
s
i
i
ç
ç
a
a
o
o
n
n
o
o
e
e
v
v
e
e
n
n
t
t
o
o
Atores
m
m
i
i
n
n
i
i
s
s
t
t
r
r
a
a
n
n
t
t
e
e
T
T
i
i
p
p
o
o
a
a
t
t
o
o
r
r
p
p
r
r
i
i
m
m
a
a
r
r
i
i
o
o
Recursos
E
E
v
v
e
e
n
n
t
t
o
o
,
,
r
r
e
e
q
q
u
u
i
i
s
s
i
i
ç
ç
a
a
o
o
Episódios
R
R
e
e
s
s
t
t
r
r
i
i
ç
ç
ã
ã
o
o
:
:
D
D
e
e
v
v
e
e
t
t
e
e
r
r
c
c
o
o
n
n
f
f
i
i
d
d
e
e
n
n
c
c
i
i
a
a
b
b
i
i
l
l
i
i
d
d
a
a
d
d
e
e
,
,
s
s
e
e
n
n
d
d
o
o
a
a
e
e
s
s
t
t
r
r
a
a
t
t
é
é
g
g
i
i
a
a
d
d
e
e
s
s
a
a
t
t
i
i
s
s
f
f
a
a
ç
ç
ã
ã
o
o
:
:
i
i
d
d
e
e
n
n
t
t
i
i
f
f
i
i
c
c
a
a
ç
ç
ã
ã
o
o
,
,
a
a
u
u
t
t
e
e
n
n
t
t
i
i
c
c
a
a
ç
ç
ã
ã
o
o
.
.
1
1
.
.
m
m
i
i
n
n
i
i
s
s
t
t
r
r
a
a
n
n
t
t
e
e
s
s
e
e
l
l
e
e
c
c
i
i
o
o
n
n
a
a
e
e
v
v
e
e
n
n
t
t
o
o
e
e
m
m
a
a
b
b
e
e
r
r
t
t
o
o
2
2
.
.
m
m
i
i
n
n
i
i
s
s
t
t
r
r
a
a
n
n
t
t
e
e
i
i
d
d
e
e
n
n
t
t
i
i
f
f
i
i
c
c
a
a
r
r
e
e
q
q
u
u
i
i
s
s
i
i
ç
ç
ã
ã
o
o
.
.
R
R
e
e
s
s
t
t
r
r
i
i
ç
ç
ã
ã
o
o
:
:
D
D
e
e
v
v
e
e
t
t
e
e
r
r
i
i
n
n
t
t
e
e
g
g
r
r
i
i
d
d
a
a
d
d
e
e
,
,
s
s
e
e
n
n
d
d
o
o
a
a
e
e
s
s
t
t
r
r
a
a
t
t
é
é
g
g
i
i
a
a
d
d
e
e
s
s
a
a
t
t
i
i
s
s
f
f
a
a
ç
ç
ã
ã
o
o
:
:
i
i
d
d
e
e
n
n
t
t
i
i
f
f
i
i
c
c
a
a
ç
ç
ã
ã
o
o
,
,
a
a
u
u
t
t
e
e
n
n
t
t
i
i
c
c
a
a
ç
ç
ã
ã
o
o
.
.
3
3
.
.
m
m
i
i
n
n
i
i
s
s
t
t
r
r
a
a
n
n
t
t
e
e
c
c
a
a
d
d
a
a
s
s
t
t
r
r
a
a
r
r
e
e
q
q
u
u
i
i
s
s
i
i
ç
ç
ã
ã
o
o
4
4
.
.
r
r
e
e
q
q
u
u
i
i
s
s
i
i
ç
ç
ã
ã
o
o
é
é
e
e
n
n
v
v
i
i
a
a
d
d
a
a
.
.
Título
S
S
e
e
l
l
e
e
c
c
i
i
o
o
n
n
a
a
r
r
m
m
i
i
n
n
i
i
s
s
t
t
r
r
a
a
n
n
t
t
e
e
Objetivo
P
P
r
r
o
o
c
c
e
e
d
d
i
i
m
m
e
e
n
n
t
t
o
o
p
p
a
a
r
r
a
a
q
q
u
u
a
a
n
n
d
d
o
o
d
d
e
e
s
s
e
e
j
j
a
a
-
-
s
s
e
e
s
s
e
e
l
l
e
e
c
c
i
i
o
o
n
n
a
a
r
r
o
o
m
m
i
i
n
n
i
i
s
s
t
t
r
r
a
a
n
n
t
t
e
e
p
p
a
a
r
r
a
a
o
o
e
e
v
v
e
e
n
n
t
t
o
o
Contexto
S
S
i
i
s
s
t
t
e
e
m
m
a
a
e
e
m
m
i
i
t
t
i
i
n
n
d
d
o
o
s
s
e
e
l
l
e
e
ç
ç
ã
ã
o
o
d
d
e
e
m
m
i
i
n
n
i
i
s
s
t
t
r
r
a
a
n
n
t
t
e
e
5.
Experimentação
: Controle de Eventos Científicos 136
Atores
c
c
o
o
m
m
i
i
s
s
s
s
ã
ã
o
o
T
T
i
i
p
p
o
o
a
a
t
t
o
o
r
r
p
p
r
r
i
i
m
m
a
a
r
r
i
i
o
o
Recursos
E
E
v
v
e
e
n
n
t
t
o
o
Episódios
R
R
e
e
s
s
t
t
r
r
i
i
ç
ç
ã
ã
o
o
:
:
D
D
e
e
v
v
e
e
t
t
e
e
r
r
c
c
o
o
n
n
f
f
i
i
d
d
e
e
n
n
c
c
i
i
a
a
b
b
i
i
l
l
i
i
d
d
a
a
d
d
e
e
,
,
s
s
e
e
n
n
d
d
o
o
a
a
e
e
s
s
t
t
r
r
a
a
t
t
é
é
g
g
i
i
a
a
d
d
e
e
s
s
a
a
t
t
i
i
s
s
f
f
a
a
ç
ç
ã
ã
o
o
:
:
i
i
d
d
e
e
n
n
t
t
i
i
f
f
i
i
c
c
a
a
ç
ç
ã
ã
o
o
,
,
a
a
u
u
t
t
e
e
n
n
t
t
i
i
c
c
a
a
ç
ç
ã
ã
o
o
.
.
1
1
.
.
c
c
o
o
m
m
i
i
s
s
s
s
ã
ã
o
o
s
s
e
e
l
l
e
e
c
c
i
i
o
o
n
n
a
a
v
v
a
a
g
g
a
a
s
s
n
n
o
o
s
s
h
h
o
o
r
r
á
á
r
r
i
i
o
o
s
s
d
d
e
e
p
p
r
r
o
o
g
g
r
r
a
a
m
m
a
a
ç
ç
ã
ã
o
o
d
d
o
o
e
e
v
v
e
e
n
n
t
t
o
o
e
e
m
m
a
a
b
b
e
e
r
r
t
t
o
o
2
2
.
.
c
c
o
o
m
m
i
i
s
s
s
s
ã
ã
o
o
i
i
d
d
e
e
n
n
t
t
i
i
f
f
i
i
c
c
a
a
m
m
i
i
n
n
i
i
s
s
t
t
r
r
a
a
n
n
t
t
e
e
.
.
R
R
e
e
s
s
t
t
r
r
i
i
ç
ç
ã
ã
o
o
:
:
D
D
e
e
v
v
e
e
t
t
e
e
r
r
i
i
n
n
t
t
e
e
g
g
r
r
i
i
d
d
a
a
d
d
e
e
,
,
s
s
e
e
n
n
d
d
o
o
a
a
e
e
s
s
t
t
r
r
a
a
t
t
é
é
g
g
i
i
a
a
d
d
e
e
s
s
a
a
t
t
i
i
s
s
f
f
a
a
ç
ç
ã
ã
o
o
:
:
i
i
d
d
e
e
n
n
t
t
i
i
f
f
i
i
c
c
a
a
ç
ç
ã
ã
o
o
,
,
a
a
u
u
t
t
e
e
n
n
t
t
i
i
c
c
a
a
ç
ç
ã
ã
o
o
.
.
3
3
.
.
c
c
o
o
m
m
i
i
s
s
s
s
ã
ã
o
o
c
c
a
a
d
d
a
a
s
s
t
t
r
r
a
a
m
m
i
i
n
n
i
i
s
s
t
t
r
r
a
a
n
n
t
t
e
e
4
4
.
.
m
m
i
i
n
n
i
i
s
s
t
t
r
r
a
a
n
n
t
t
e
e
é
é
s
s
e
e
l
l
e
e
c
c
i
i
o
o
n
n
a
a
d
d
o
o
.
.
P
P
o
o
s
s
c
c
o
o
n
n
d
d
:
:
1
1
.
.
É
É
e
e
n
n
v
v
i
i
a
a
d
d
o
o
e
e
-
-
m
m
a
a
i
i
l
l
p
p
a
a
r
r
a
a
o
o
m
m
i
i
n
n
i
i
s
s
t
t
r
r
a
a
n
n
t
t
e
e
c
c
o
o
m
m
o
o
c
c
o
o
n
n
v
v
i
i
t
t
e
e
d
d
o
o
e
e
v
v
e
e
n
n
t
t
o
o
c
c
o
o
n
n
t
t
e
e
n
n
d
d
o
o
:
:
a
a
s
s
s
s
u
u
n
n
t
t
o
o
d
d
e
e
i
i
n
n
t
t
e
e
r
r
e
e
s
s
s
s
e
e
d
d
o
o
c
c
u
u
r
r
s
s
o
o
,
,
p
p
r
r
a
a
z
z
o
o
e
e
s
s
t
t
i
i
m
m
a
a
d
d
o
o
p
p
a
a
r
r
a
a
o
o
e
e
n
n
v
v
i
i
o
o
d
d
o
o
m
m
a
a
t
t
e
e
r
r
i
i
a
a
l
l
e
e
a
a
c
c
e
e
i
i
t
t
a
a
ç
ç
ã
ã
o
o
d
d
o
o
c
c
o
o
n
n
v
v
i
i
t
t
e
e
e
e
i
i
n
n
f
f
o
o
r
r
m
m
a
a
ç
ç
õ
õ
e
e
s
s
g
g
e
e
r
r
a
a
i
i
s
s
s
s
o
o
b
b
r
r
e
e
o
o
e
e
v
v
e
e
n
n
t
t
o
o
Título
S
S
e
e
l
l
e
e
c
c
i
i
o
o
n
n
a
a
r
r
p
p
a
a
l
l
e
e
s
s
t
t
r
r
a
a
n
n
t
t
e
e
Objetivo
P
P
r
r
o
o
c
c
e
e
d
d
i
i
m
m
e
e
n
n
t
t
o
o
p
p
a
a
r
r
a
a
q
q
u
u
a
a
n
n
d
d
o
o
d
d
e
e
s
s
e
e
j
j
a
a
-
-
s
s
e
e
s
s
e
e
l
l
e
e
c
c
i
i
o
o
n
n
a
a
r
r
o
o
p
p
a
a
l
l
e
e
s
s
t
t
r
r
a
a
n
n
t
t
e
e
p
p
a
a
r
r
a
a
o
o
e
e
v
v
e
e
n
n
t
t
o
o
Contexto
S
S
i
i
s
s
t
t
e
e
m
m
a
a
e
e
m
m
i
i
t
t
i
i
n
n
d
d
o
o
s
s
e
e
l
l
e
e
ç
ç
ã
ã
o
o
d
d
e
e
p
p
a
a
l
l
e
e
s
s
t
t
r
r
a
a
n
n
t
t
e
e
Atores
c
c
o
o
m
m
i
i
s
s
s
s
ã
ã
o
o
T
T
i
i
p
p
o
o
a
a
t
t
o
o
r
r
p
p
r
r
i
i
m
m
a
a
r
r
i
i
o
o
Recursos
E
E
v
v
e
e
n
n
t
t
o
o
Episódios
R
R
e
e
s
s
t
t
r
r
i
i
ç
ç
ã
ã
o
o
:
:
D
D
e
e
v
v
e
e
t
t
e
e
r
r
c
c
o
o
n
n
f
f
i
i
d
d
e
e
n
n
c
c
i
i
a
a
b
b
i
i
l
l
i
i
d
d
a
a
d
d
e
e
,
,
s
s
e
e
n
n
d
d
o
o
a
a
e
e
s
s
t
t
r
r
a
a
t
t
é
é
g
g
i
i
a
a
d
d
e
e
s
s
a
a
t
t
i
i
s
s
f
f
a
a
ç
ç
ã
ã
o
o
:
:
i
i
d
d
e
e
n
n
t
t
i
i
f
f
i
i
c
c
a
a
ç
ç
ã
ã
o
o
,
,
a
a
u
u
t
t
e
e
n
n
t
t
i
i
c
c
a
a
ç
ç
ã
ã
o
o
.
.
1
1
.
.
c
c
o
o
m
m
i
i
s
s
s
s
ã
ã
o
o
s
s
e
e
l
l
e
e
c
c
i
i
o
o
n
n
a
a
v
v
a
a
g
g
a
a
s
s
n
n
o
o
s
s
h
h
o
o
r
r
á
á
r
r
i
i
o
o
s
s
d
d
e
e
p
p
r
r
o
o
g
g
r
r
a
a
m
m
a
a
ç
ç
ã
ã
o
o
d
d
o
o
e
e
v
v
e
e
n
n
t
t
o
o
e
e
m
m
a
a
b
b
e
e
r
r
t
t
o
o
2
2
.
.
c
c
o
o
m
m
i
i
s
s
s
s
ã
ã
o
o
i
i
d
d
e
e
n
n
t
t
i
i
f
f
i
i
c
c
a
a
p
p
a
a
l
l
e
e
s
s
t
t
r
r
a
a
n
n
t
t
e
e
.
.
R
R
e
e
s
s
t
t
r
r
i
i
ç
ç
ã
ã
o
o
:
:
D
D
e
e
v
v
e
e
t
t
e
e
r
r
i
i
n
n
t
t
e
e
g
g
r
r
i
i
d
d
a
a
d
d
e
e
,
,
s
s
e
e
n
n
d
d
o
o
a
a
e
e
s
s
t
t
r
r
a
a
t
t
é
é
g
g
i
i
a
a
d
d
e
e
s
s
a
a
t
t
i
i
s
s
f
f
a
a
ç
ç
ã
ã
o
o
:
:
i
i
d
d
e
e
n
n
t
t
i
i
f
f
i
i
c
c
a
a
ç
ç
ã
ã
o
o
,
,
a
a
u
u
t
t
e
e
n
n
t
t
i
i
c
c
a
a
ç
ç
ã
ã
o
o
.
.
3
3
.
.
c
c
o
o
m
m
i
i
s
s
s
s
ã
ã
o
o
c
c
a
a
d
d
a
a
s
s
t
t
r
r
a
a
p
p
a
a
l
l
e
e
s
s
t
t
r
r
a
a
n
n
t
t
e
e
4
4
.
.
p
p
a
a
l
l
e
e
s
s
t
t
r
r
a
a
n
n
t
t
e
e
é
é
s
s
e
e
l
l
e
e
c
c
i
i
o
o
n
n
a
a
d
d
o
o
.
.
P
P
o
o
s
s
c
c
o
o
n
n
d
d
:
:
1
1
.
.
É
É
e
e
n
n
v
v
i
i
a
a
d
d
o
o
e
e
-
-
m
m
a
a
i
i
l
l
p
p
a
a
r
r
a
a
o
o
p
p
a
a
l
l
e
e
s
s
t
t
r
r
a
a
n
n
t
t
e
e
c
c
o
o
m
m
o
o
c
c
o
o
n
n
v
v
i
i
t
t
e
e
d
d
o
o
e
e
v
v
e
e
n
n
t
t
o
o
c
c
o
o
n
n
t
t
e
e
n
n
d
d
o
o
:
:
a
a
s
s
s
s
u
u
n
n
t
t
o
o
d
d
e
e
i
i
n
n
t
t
e
e
r
r
e
e
s
s
s
s
e
e
d
d
o
o
c
c
u
u
r
r
s
s
o
o
,
,
p
p
r
r
a
a
z
z
o
o
e
e
s
s
t
t
i
i
m
m
a
a
d
d
o
o
p
p
a
a
r
r
a
a
o
o
e
e
n
n
v
v
i
i
o
o
d
d
a
a
p
p
a
a
l
l
e
e
s
s
t
t
r
r
a
a
e
e
a
a
c
c
e
e
i
i
t
t
a
a
ç
ç
ã
ã
o
o
d
d
o
o
c
c
o
o
n
n
v
v
i
i
t
t
e
e
e
e
r
r
e
e
q
q
u
u
i
i
s
s
i
i
ç
ç
ã
ã
o
o
e
e
i
i
n
n
f
f
o
o
r
r
m
m
a
a
ç
ç
õ
õ
e
e
s
s
g
g
e
e
r
r
a
a
i
i
s
s
s
s
o
o
b
b
r
r
e
e
o
o
e
e
v
v
e
e
n
n
t
t
o
o
Título
E
E
m
m
i
i
t
t
i
i
r
r
c
c
r
r
a
a
c
c
h
h
á
á
s
s
Objetivo
P
P
r
r
o
o
c
c
e
e
d
d
i
i
m
m
e
e
n
n
t
t
o
o
p
p
a
a
r
r
a
a
q
q
u
u
a
a
n
n
d
d
o
o
d
d
e
e
s
s
e
e
j
j
a
a
-
-
s
s
e
e
e
e
m
m
i
i
t
t
i
i
r
r
c
c
r
r
a
a
c
c
h
h
á
á
s
s
p
p
a
a
r
r
a
a
o
o
s
s
p
p
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
n
n
t
t
e
e
s
s
d
d
o
o
e
e
v
v
e
e
n
n
t
t
o
o
Contexto
S
S
i
i
s
s
t
t
e
e
m
m
a
a
e
e
m
m
i
i
t
t
i
i
n
n
d
d
o
o
c
c
r
r
a
a
c
c
h
h
á
á
s
s
p
p
a
a
r
r
a
a
p
p
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
n
n
t
t
e
e
s
s
Atores
c
c
o
o
m
m
i
i
s
s
s
s
ã
ã
o
o
T
T
i
i
p
p
o
o
a
a
t
t
o
o
r
r
p
p
r
r
i
i
m
m
a
a
r
r
i
i
o
o
Recursos
E
E
v
v
e
e
n
n
t
t
o
o
,
,
c
c
r
r
a
a
c
c
h
h
á
á
Episódios
R
R
e
e
s
s
t
t
r
r
i
i
ç
ç
ã
ã
o
o
:
:
D
D
e
e
v
v
e
e
t
t
e
e
r
r
c
c
o
o
n
n
f
f
i
i
d
d
e
e
n
n
c
c
i
i
a
a
b
b
i
i
l
l
i
i
d
d
a
a
d
d
e
e
,
,
s
s
e
e
n
n
d
d
o
o
a
a
e
e
s
s
t
t
r
r
a
a
t
t
é
é
g
g
i
i
a
a
d
d
e
e
s
s
a
a
t
t
i
i
s
s
f
f
a
a
ç
ç
ã
ã
o
o
:
:
i
i
d
d
e
e
n
n
t
t
i
i
f
f
i
i
c
c
a
a
ç
ç
ã
ã
o
o
,
,
a
a
u
u
t
t
e
e
n
n
t
t
i
i
c
c
a
a
ç
ç
ã
ã
o
o
.
.
1
1
.
.
c
c
o
o
m
m
i
i
s
s
s
s
ã
ã
o
o
s
s
e
e
l
l
e
e
c
c
i
i
o
o
n
n
a
a
e
e
v
v
e
e
n
n
t
t
o
o
e
e
m
m
a
a
b
b
e
e
r
r
t
t
o
o
2
2
.
.
c
c
o
o
m
m
i
i
s
s
s
s
ã
ã
o
o
s
s
e
e
l
l
e
e
c
c
i
i
o
o
n
n
a
a
p
p
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
n
n
t
t
e
e
s
s
d
d
o
o
e
e
v
v
e
e
n
n
t
t
o
o
3
3
.
.
c
c
o
o
m
m
i
i
s
s
s
s
ã
ã
o
o
s
s
o
o
l
l
i
i
c
c
i
i
t
t
a
a
i
i
m
m
p
p
r
r
e
e
s
s
s
s
ã
ã
o
o
d
d
o
o
c
c
r
r
a
a
c
c
h
h
á
á
4
4
.
.
c
c
r
r
a
a
c
c
h
h
á
á
é
é
e
e
m
m
i
i
t
t
i
i
d
d
o
o
.
.
P
P
o
o
s
s
c
c
o
o
n
n
d
d
:
:
1
1
.
.
c
c
r
r
a
a
c
c
h
h
á
á
é
é
e
e
n
n
v
v
i
i
a
a
d
d
o
o
a
a
o
o
p
p
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
n
n
t
t
e
e
Título
E
E
m
m
i
i
t
t
i
i
r
r
c
c
e
e
r
r
t
t
i
i
f
f
i
i
c
c
a
a
d
d
o
o
s
s
Objetivo
P
P
r
r
o
o
c
c
e
e
d
d
i
i
m
m
e
e
n
n
t
t
o
o
p
p
a
a
r
r
a
a
q
q
u
u
a
a
n
n
d
d
o
o
d
d
e
e
s
s
e
e
j
j
a
a
-
-
s
s
e
e
e
e
m
m
i
i
t
t
i
i
r
r
c
c
e
e
r
r
t
t
i
i
f
f
i
i
c
c
a
a
d
d
o
o
d
d
e
e
p
p
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
ç
ç
ã
ã
o
o
p
p
a
a
r
r
a
a
o
o
s
s
p
p
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
n
n
t
t
e
e
s
s
d
d
o
o
e
e
v
v
e
e
n
n
t
t
o
o
Contexto
S
S
i
i
s
s
t
t
e
e
m
m
a
a
e
e
m
m
i
i
t
t
i
i
n
n
d
d
o
o
c
c
r
r
a
a
c
c
h
h
á
á
s
s
p
p
a
a
r
r
a
a
p
p
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
n
n
t
t
e
e
s
s
Atores
c
c
o
o
m
m
i
i
s
s
s
s
ã
ã
o
o
T
T
i
i
p
p
o
o
a
a
t
t
o
o
r
r
p
p
r
r
i
i
m
m
a
a
r
r
i
i
o
o
Recursos
E
E
v
v
e
e
n
n
t
t
o
o
,
,
c
c
e
e
r
r
t
t
i
i
f
f
i
i
c
c
a
a
d
d
o
o
Episódios
R
R
e
e
s
s
t
t
r
r
i
i
ç
ç
ã
ã
o
o
:
:
D
D
e
e
v
v
e
e
t
t
e
e
r
r
c
c
o
o
n
n
f
f
i
i
d
d
e
e
n
n
c
c
i
i
a
a
b
b
i
i
l
l
i
i
d
d
a
a
d
d
e
e
,
,
s
s
e
e
n
n
d
d
o
o
a
a
e
e
s
s
t
t
r
r
a
a
t
t
é
é
g
g
i
i
a
a
d
d
e
e
s
s
a
a
t
t
i
i
s
s
f
f
a
a
ç
ç
ã
ã
o
o
:
:
5.
Experimentação
: Controle de Eventos Científicos 137
i
i
d
d
e
e
n
n
t
t
i
i
f
f
i
i
c
c
a
a
ç
ç
ã
ã
o
o
,
,
a
a
u
u
t
t
e
e
n
n
t
t
i
i
c
c
a
a
ç
ç
ã
ã
o
o
.
.
1
1
.
.
c
c
o
o
m
m
i
i
s
s
s
s
ã
ã
o
o
s
s
e
e
l
l
e
e
c
c
i
i
o
o
n
n
a
a
e
e
v
v
e
e
n
n
t
t
o
o
f
f
e
e
c
c
h
h
a
a
d
d
o
o
.
.
2
2
.
.
c
c
o
o
m
m
i
i
s
s
s
s
ã
ã
o
o
s
s
e
e
l
l
e
e
c
c
i
i
o
o
n
n
a
a
p
p
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
n
n
t
t
e
e
s
s
d
d
o
o
e
e
v
v
e
e
n
n
t
t
o
o
.
.
C
C
o
o
m
m
n
n
o
o
m
m
í
í
n
n
i
i
m
m
o
o
8
8
5
5
%
%
p
p
r
r
e
e
s
s
e
e
n
n
ç
ç
a
a
.
.
3
3
.
.
c
c
o
o
m
m
i
i
s
s
s
s
ã
ã
o
o
s
s
o
o
l
l
i
i
c
c
i
i
t
t
a
a
i
i
m
m
p
p
r
r
e
e
s
s
s
s
ã
ã
o
o
d
d
o
o
c
c
e
e
r
r
t
t
i
i
f
f
i
i
c
c
a
a
d
d
o
o
4
4
.
.
c
c
e
e
r
r
t
t
i
i
f
f
i
i
c
c
a
a
d
d
o
o
é
é
e
e
m
m
i
i
t
t
i
i
d
d
o
o
.
.
P
P
o
o
s
s
c
c
o
o
n
n
d
d
:
:
1
1
.
.
c
c
e
e
r
r
t
t
i
i
f
f
i
i
c
c
a
a
d
d
o
o
é
é
e
e
n
n
v
v
i
i
a
a
d
d
o
o
a
a
o
o
p
p
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
n
n
t
t
e
e
Título
A
A
t
t
u
u
a
a
l
l
i
i
z
z
a
a
r
r
p
p
r
r
o
o
g
g
r
r
a
a
m
m
a
a
ç
ç
ã
ã
o
o
Objetivo
P
P
r
r
o
o
c
c
e
e
d
d
i
i
m
m
e
e
n
n
t
t
o
o
p
p
a
a
r
r
a
a
q
q
u
u
a
a
n
n
d
d
o
o
d
d
e
e
s
s
e
e
j
j
a
a
-
-
s
s
e
e
e
e
l
l
a
a
b
b
o
o
r
r
a
a
r
r
a
a
p
p
r
r
o
o
g
g
r
r
a
a
m
m
a
a
ç
ç
ã
ã
o
o
d
d
o
o
e
e
v
v
e
e
n
n
t
t
o
o
Contexto
S
S
i
i
s
s
t
t
e
e
m
m
a
a
e
e
m
m
i
i
t
t
i
i
n
n
d
d
o
o
a
a
t
t
u
u
a
a
l
l
i
i
z
z
a
a
ç
ç
ã
ã
o
o
d
d
a
a
p
p
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
n
n
t
t
e
e
s
s
Atores
c
c
o
o
m
m
i
i
s
s
s
s
ã
ã
o
o
T
T
i
i
p
p
o
o
a
a
t
t
o
o
r
r
p
p
r
r
i
i
m
m
a
a
r
r
i
i
o
o
Recursos
E
E
v
v
e
e
n
n
t
t
o
o
,
,
p
p
r
r
o
o
g
g
r
r
a
a
m
m
a
a
ç
ç
ã
ã
o
o
Episódios
R
R
e
e
s
s
t
t
r
r
i
i
ç
ç
ã
ã
o
o
:
:
D
D
e
e
v
v
e
e
t
t
e
e
r
r
c
c
o
o
n
n
f
f
i
i
d
d
e
e
n
n
c
c
i
i
a
a
b
b
i
i
l
l
i
i
d
d
a
a
d
d
e
e
,
,
s
s
e
e
n
n
d
d
o
o
a
a
e
e
s
s
t
t
r
r
a
a
t
t
é
é
g
g
i
i
a
a
d
d
e
e
s
s
a
a
t
t
i
i
s
s
f
f
a
a
ç
ç
ã
ã
o
o
:
:
i
i
d
d
e
e
n
n
t
t
i
i
f
f
i
i
c
c
a
a
ç
ç
ã
ã
o
o
,
,
a
a
u
u
t
t
e
e
n
n
t
t
i
i
c
c
a
a
ç
ç
ã
ã
o
o
.
.
1
1
.
.
c
c
o
o
m
m
i
i
s
s
s
s
ã
ã
o
o
s
s
e
e
l
l
e
e
c
c
i
i
o
o
n
n
a
a
e
e
v
v
e
e
n
n
t
t
o
o
e
e
m
m
a
a
b
b
e
e
r
r
t
t
o
o
.
.
2
2
.
.
c
c
o
o
m
m
i
i
s
s
s
s
ã
ã
o
o
i
i
d
d
e
e
n
n
t
t
i
i
f
f
i
i
c
c
a
a
p
p
r
r
o
o
g
g
r
r
a
a
m
m
a
a
ç
ç
ã
ã
o
o
.
.
3
3
.
.
c
c
o
o
m
m
i
i
s
s
s
s
ã
ã
o
o
a
a
t
t
u
u
a
a
l
l
i
i
z
z
a
a
p
p
r
r
o
o
g
g
r
r
a
a
m
m
a
a
ç
ç
ã
ã
o
o
.
.
R
R
e
e
s
s
t
t
r
r
i
i
ç
ç
ã
ã
o
o
:
:
D
D
e
e
v
v
e
e
t
t
e
e
r
r
i
i
n
n
t
t
e
e
g
g
r
r
i
i
d
d
a
a
d
d
e
e
,
,
s
s
e
e
n
n
d
d
o
o
a
a
e
e
s
s
t
t
r
r
a
a
t
t
é
é
g
g
i
i
a
a
d
d
e
e
s
s
a
a
t
t
i
i
s
s
f
f
a
a
ç
ç
ã
ã
o
o
:
:
i
i
d
d
e
e
n
n
t
t
i
i
f
f
i
i
c
c
a
a
ç
ç
ã
ã
o
o
,
,
a
a
u
u
t
t
e
e
n
n
t
t
i
i
c
c
a
a
ç
ç
ã
ã
o
o
.
.
4
4
.
.
p
p
r
r
o
o
g
g
r
r
a
a
m
m
a
a
ç
ç
ã
ã
o
o
é
é
a
a
t
t
u
u
a
a
l
l
i
i
z
z
a
a
d
d
a
a
.
.
Título
C
C
a
a
d
d
a
a
s
s
t
t
r
r
a
a
r
r
p
p
a
a
r
r
c
c
e
e
i
i
r
r
o
o
s
s
Objetivo
P
P
r
r
o
o
c
c
e
e
d
d
i
i
m
m
e
e
n
n
t
t
o
o
p
p
a
a
r
r
a
a
q
q
u
u
a
a
n
n
d
d
o
o
d
d
e
e
s
s
e
e
j
j
a
a
-
-
s
s
e
e
c
c
a
a
d
d
a
a
s
s
t
t
r
r
a
a
r
r
p
p
a
a
r
r
c
c
e
e
i
i
r
r
o
o
s
s
n
n
o
o
s
s
e
e
v
v
e
e
n
n
t
t
o
o
s
s
Contexto
S
S
i
i
s
s
t
t
e
e
m
m
a
a
e
e
m
m
i
i
t
t
i
i
n
n
d
d
o
o
o
o
c
c
a
a
d
d
a
a
s
s
t
t
r
r
o
o
d
d
e
e
p
p
a
a
r
r
c
c
e
e
i
i
r
r
o
o
s
s
Atores
c
c
o
o
m
m
i
i
s
s
s
s
ã
ã
o
o
T
T
i
i
p
p
o
o
a
a
t
t
o
o
r
r
p
p
r
r
i
i
m
m
a
a
r
r
i
i
o
o
Recursos
E
E
v
v
e
e
n
n
t
t
o
o
Episódios
R
R
e
e
s
s
t
t
r
r
i
i
ç
ç
ã
ã
o
o
:
:
D
D
e
e
v
v
e
e
t
t
e
e
r
r
c
c
o
o
n
n
f
f
i
i
d
d
e
e
n
n
c
c
i
i
a
a
b
b
i
i
l
l
i
i
d
d
a
a
d
d
e
e
,
,
s
s
e
e
n
n
d
d
o
o
a
a
e
e
s
s
t
t
r
r
a
a
t
t
é
é
g
g
i
i
a
a
d
d
e
e
s
s
a
a
t
t
i
i
s
s
f
f
a
a
ç
ç
ã
ã
o
o
:
:
i
i
d
d
e
e
n
n
t
t
i
i
f
f
i
i
c
c
a
a
ç
ç
ã
ã
o
o
,
,
a
a
u
u
t
t
e
e
n
n
t
t
i
i
c
c
a
a
ç
ç
ã
ã
o
o
.
.
1
1
.
.
c
c
o
o
m
m
i
i
s
s
s
s
ã
ã
o
o
s
s
e
e
l
l
e
e
c
c
i
i
o
o
n
n
a
a
e
e
v
v
e
e
n
n
t
t
o
o
e
e
m
m
a
a
b
b
e
e
r
r
t
t
o
o
.
.
2
2
.
.
c
c
o
o
m
m
i
i
s
s
s
s
ã
ã
o
o
i
i
d
d
e
e
n
n
t
t
i
i
f
f
i
i
c
c
a
a
p
p
a
a
r
r
c
c
e
e
i
i
r
r
o
o
s
s
.
.
R
R
e
e
s
s
t
t
r
r
i
i
ç
ç
ã
ã
o
o
:
:
D
D
e
e
v
v
e
e
t
t
e
e
r
r
i
i
n
n
t
t
e
e
g
g
r
r
i
i
d
d
a
a
d
d
e
e
,
,
s
s
e
e
n
n
d
d
o
o
a
a
e
e
s
s
t
t
r
r
a
a
t
t
é
é
g
g
i
i
a
a
d
d
e
e
s
s
a
a
t
t
i
i
s
s
f
f
a
a
ç
ç
ã
ã
o
o
:
:
i
i
d
d
e
e
n
n
t
t
i
i
f
f
i
i
c
c
a
a
ç
ç
ã
ã
o
o
,
,
a
a
u
u
t
t
e
e
n
n
t
t
i
i
c
c
a
a
ç
ç
ã
ã
o
o
.
.
3
3
.
.
p
p
a
a
r
r
c
c
e
e
i
i
r
r
o
o
s
s
s
s
ã
ã
o
o
c
c
a
a
d
d
a
a
s
s
t
t
r
r
a
a
d
d
o
o
s
s
.
.
Título
S
S
e
e
l
l
e
e
c
c
i
i
o
o
n
n
a
a
r
r
t
t
r
r
a
a
b
b
a
a
l
l
h
h
o
o
Objetivo
P
P
r
r
o
o
c
c
e
e
d
d
i
i
m
m
e
e
n
n
t
t
o
o
p
p
a
a
r
r
a
a
q
q
u
u
a
a
n
n
d
d
o
o
d
d
e
e
s
s
e
e
j
j
a
a
-
-
s
s
e
e
s
s
e
e
l
l
e
e
c
c
i
i
o
o
n
n
a
a
r
r
t
t
r
r
a
a
b
b
a
a
l
l
h
h
o
o
s
s
a
a
s
s
e
e
r
r
e
e
m
m
a
a
p
p
r
r
e
e
s
s
e
e
n
n
t
t
a
a
d
d
o
o
s
s
n
n
o
o
e
e
v
v
e
e
n
n
t
t
o
o
Contexto
S
S
i
i
s
s
t
t
e
e
m
m
a
a
e
e
m
m
i
i
t
t
i
i
n
n
d
d
o
o
a
a
s
s
e
e
l
l
e
e
ç
ç
ã
ã
o
o
d
d
e
e
t
t
r
r
a
a
b
b
a
a
l
l
h
h
o
o
s
s
Atores
c
c
o
o
m
m
i
i
t
t
ê
ê
T
T
i
i
p
p
o
o
a
a
t
t
o
o
r
r
p
p
r
r
i
i
m
m
a
a
r
r
i
i
o
o
Recursos
E
E
v
v
e
e
n
n
t
t
o
o
,
,
p
p
r
r
o
o
g
g
r
r
a
a
m
m
a
a
ç
ç
ã
ã
o
o
,
,
t
t
r
r
a
a
b
b
a
a
l
l
h
h
o
o
s
s
Episódios
R
R
e
e
s
s
t
t
r
r
i
i
ç
ç
ã
ã
o
o
:
:
D
D
e
e
v
v
e
e
t
t
e
e
r
r
c
c
o
o
n
n
f
f
i
i
d
d
e
e
n
n
c
c
i
i
a
a
b
b
i
i
l
l
i
i
d
d
a
a
d
d
e
e
,
,
s
s
e
e
n
n
d
d
o
o
a
a
e
e
s
s
t
t
r
r
a
a
t
t
é
é
g
g
i
i
a
a
d
d
e
e
s
s
a
a
t
t
i
i
s
s
f
f
a
a
ç
ç
ã
ã
o
o
:
:
i
i
d
d
e
e
n
n
t
t
i
i
f
f
i
i
c
c
a
a
ç
ç
ã
ã
o
o
,
,
a
a
u
u
t
t
e
e
n
n
t
t
i
i
c
c
a
a
ç
ç
ã
ã
o
o
.
.
1
1
.
.
c
c
o
o
m
m
i
i
t
t
ê
ê
s
s
e
e
l
l
e
e
c
c
i
i
o
o
n
n
a
a
e
e
v
v
e
e
n
n
t
t
o
o
e
e
m
m
a
a
b
b
e
e
r
r
t
t
o
o
.
.
2
2
.
.
C
C
o
o
m
m
i
i
t
t
ê
ê
s
s
e
e
l
l
e
e
c
c
i
i
o
o
n
n
a
a
p
p
r
r
o
o
g
g
r
r
a
a
m
m
a
a
ç
ç
ã
ã
o
o
2
2
.
.
c
c
o
o
m
m
i
i
t
t
ê
ê
i
i
d
d
e
e
n
n
t
t
i
i
f
f
i
i
c
c
a
a
t
t
r
r
a
a
b
b
a
a
l
l
h
h
o
o
.
.
R
R
e
e
s
s
t
t
r
r
i
i
ç
ç
ã
ã
o
o
:
:
D
D
e
e
v
v
e
e
t
t
e
e
r
r
i
i
n
n
t
t
e
e
g
g
r
r
i
i
d
d
a
a
d
d
e
e
,
,
s
s
e
e
n
n
d
d
o
o
a
a
e
e
s
s
t
t
r
r
a
a
t
t
é
é
g
g
i
i
a
a
d
d
e
e
s
s
a
a
t
t
i
i
s
s
f
f
a
a
ç
ç
ã
ã
o
o
:
:
i
i
d
d
e
e
n
n
t
t
i
i
f
f
i
i
c
c
a
a
ç
ç
ã
ã
o
o
,
,
a
a
u
u
t
t
e
e
n
n
t
t
i
i
c
c
a
a
ç
ç
ã
ã
o
o
.
.
3
3
.
.
t
t
r
r
a
a
b
b
a
a
l
l
h
h
o
o
é
é
s
s
e
e
l
l
e
e
c
c
i
i
o
o
n
n
a
a
d
d
o
o
.
.
P
P
o
o
s
s
c
c
o
o
n
n
d
d
:
:
1
1
.
.
É
É
e
e
n
n
v
v
i
i
a
a
d
d
o
o
e
e
-
-
m
m
a
a
i
i
l
l
p
p
a
a
r
r
a
a
o
o
a
a
p
p
r
r
e
e
s
s
e
e
n
n
t
t
a
a
d
d
o
o
r
r
p
p
a
a
r
r
a
a
b
b
e
e
n
n
i
i
z
z
a
a
n
n
d
d
o
o
p
p
e
e
l
l
o
o
t
t
r
r
a
a
b
b
a
a
l
l
h
h
o
o
s
s
e
e
l
l
e
e
c
c
i
i
o
o
n
n
a
a
d
d
o
o
e
e
s
s
e
e
u
u
h
h
o
o
r
r
á
á
r
r
i
i
o
o
p
p
r
r
e
e
v
v
i
i
s
s
t
t
o
o
d
d
e
e
a
a
p
p
r
r
e
e
s
s
e
e
n
n
t
t
a
a
ç
ç
ã
ã
o
o
e
e
s
s
o
o
l
l
i
i
c
c
i
i
t
t
a
a
ç
ç
ã
ã
o
o
d
d
o
o
p
p
a
a
g
g
a
a
m
m
e
e
n
n
t
t
o
o
d
d
a
a
i
i
n
n
s
s
c
c
r
r
i
i
ç
ç
ã
ã
o
o
n
n
o
o
e
e
v
v
e
e
n
n
t
t
o
o
Título
F
F
o
o
r
r
n
n
e
e
c
c
e
e
r
r
r
r
e
e
c
c
u
u
r
r
s
s
o
o
s
s
5.
Experimentação
: Controle de Eventos Científicos 138
Objetivo
P
P
r
r
o
o
c
c
e
e
d
d
i
i
m
m
e
e
n
n
t
t
o
o
p
p
a
a
r
r
a
a
q
q
u
u
a
a
n
n
d
d
o
o
d
d
e
e
s
s
e
e
j
j
a
a
-
-
s
s
e
e
c
c
a
a
d
d
a
a
s
s
t
t
r
r
a
a
r
r
r
r
e
e
c
c
u
u
r
r
s
s
o
o
s
s
p
p
a
a
r
r
a
a
o
o
e
e
v
v
e
e
n
n
t
t
o
o
Contexto
S
S
i
i
s
s
t
t
e
e
m
m
a
a
e
e
m
m
i
i
t
t
i
i
n
n
d
d
o
o
c
c
a
a
d
d
a
a
s
s
t
t
r
r
o
o
d
d
e
e
r
r
e
e
c
c
u
u
r
r
s
s
o
o
s
s
Atores
p
p
a
a
r
r
c
c
e
e
i
i
r
r
o
o
s
s
T
T
i
i
p
p
o
o
a
a
t
t
o
o
r
r
p
p
r
r
i
i
m
m
a
a
r
r
i
i
o
o
Recursos
E
E
v
v
e
e
n
n
t
t
o
o
Episódios
R
R
e
e
s
s
t
t
r
r
i
i
ç
ç
ã
ã
o
o
:
:
D
D
e
e
v
v
e
e
t
t
e
e
r
r
c
c
o
o
n
n
f
f
i
i
d
d
e
e
n
n
c
c
i
i
a
a
b
b
i
i
l
l
i
i
d
d
a
a
d
d
e
e
,
,
s
s
e
e
n
n
d
d
o
o
a
a
e
e
s
s
t
t
r
r
a
a
t
t
é
é
g
g
i
i
a
a
d
d
e
e
s
s
a
a
t
t
i
i
s
s
f
f
a
a
ç
ç
ã
ã
o
o
:
:
i
i
d
d
e
e
n
n
t
t
i
i
f
f
i
i
c
c
a
a
ç
ç
ã
ã
o
o
,
,
a
a
u
u
t
t
e
e
n
n
t
t
i
i
c
c
a
a
ç
ç
ã
ã
o
o
.
.
1
1
.
.
p
p
a
a
r
r
c
c
e
e
i
i
r
r
o
o
s
s
s
s
e
e
l
l
e
e
c
c
i
i
o
o
n
n
a
a
e
e
v
v
e
e
n
n
t
t
o
o
e
e
m
m
a
a
b
b
e
e
r
r
t
t
o
o
c
c
o
o
m
m
r
r
e
e
c
c
u
u
r
r
s
s
o
o
s
s
a
a
r
r
e
e
c
c
e
e
b
b
e
e
r
r
p
p
o
o
r
r
e
e
l
l
e
e
.
.
2
2
.
.
p
p
a
a
r
r
c
c
e
e
i
i
r
r
o
o
i
i
d
d
e
e
n
n
t
t
i
i
f
f
i
i
c
c
a
a
r
r
e
e
c
c
u
u
r
r
s
s
o
o
.
.
R
R
e
e
s
s
t
t
r
r
i
i
ç
ç
ã
ã
o
o
:
:
D
D
e
e
v
v
e
e
t
t
e
e
r
r
i
i
n
n
t
t
e
e
g
g
r
r
i
i
d
d
a
a
d
d
e
e
,
,
s
s
e
e
n
n
d
d
o
o
a
a
e
e
s
s
t
t
r
r
a
a
t
t
é
é
g
g
i
i
a
a
d
d
e
e
s
s
a
a
t
t
i
i
s
s
f
f
a
a
ç
ç
ã
ã
o
o
:
:
i
i
d
d
e
e
n
n
t
t
i
i
f
f
i
i
c
c
a
a
ç
ç
ã
ã
o
o
,
,
a
a
u
u
t
t
e
e
n
n
t
t
i
i
c
c
a
a
ç
ç
ã
ã
o
o
.
.
3
3
.
.
r
r
e
e
c
c
u
u
r
r
s
s
o
o
é
é
f
f
o
o
r
r
n
n
e
e
c
c
i
i
d
d
o
o
.
.
P
P
o
o
s
s
c
c
o
o
n
n
d
d
:
:
1
1
.
.
s
s
e
e
c
c
r
r
e
e
t
t
a
a
r
r
i
i
a
a
r
r
e
e
c
c
e
e
b
b
e
e
r
r
e
e
c
c
u
u
r
r
s
s
o
o
s
s
Título
V
V
a
a
l
l
i
i
d
d
a
a
r
r
s
s
i
i
t
t
u
u
a
a
ç
ç
ã
ã
o
o
Objetivo
P
P
r
r
o
o
c
c
e
e
d
d
i
i
m
m
e
e
n
n
t
t
o
o
p
p
a
a
r
r
a
a
q
q
u
u
a
a
n
n
d
d
o
o
d
d
e
e
s
s
e
e
j
j
a
a
-
-
s
s
e
e
v
v
e
e
r
r
i
i
f
f
i
i
c
c
a
a
r
r
s
s
i
i
t
t
u
u
a
a
ç
ç
ã
ã
o
o
d
d
o
o
c
c
l
l
i
i
e
e
n
n
t
t
e
e
i
i
n
n
s
s
c
c
r
r
i
i
t
t
o
o
Contexto
S
S
i
i
s
s
t
t
e
e
m
m
a
a
r
r
e
e
t
t
o
o
r
r
n
n
a
a
t
t
r
r
u
u
e
e
p
p
a
a
r
r
a
a
o
o
c
c
a
a
s
s
o
o
d
d
e
e
s
s
e
e
r
r
u
u
m
m
c
c
l
l
i
i
e
e
n
n
t
t
e
e
v
v
i
i
p
p
,
,
c
c
a
a
s
s
o
o
c
c
o
o
n
n
t
t
r
r
a
a
r
r
i
i
o
o
r
r
e
e
t
t
o
o
r
r
n
n
a
a
f
f
a
a
l
l
s
s
e
e
P
P
r
r
é
é
-
-
c
c
o
o
n
n
d
d
:
:
1
1
.
.
r
r
e
e
c
c
e
e
b
b
e
e
c
c
o
o
m
m
o
o
e
e
n
n
t
t
r
r
a
a
d
d
a
a
a
a
i
i
d
d
e
e
n
n
t
t
i
i
f
f
i
i
c
c
a
a
ç
ç
ã
ã
o
o
d
d
o
o
c
c
l
l
i
i
e
e
n
n
t
t
e
e
i
i
n
n
s
s
c
c
r
r
i
i
t
t
o
o
Atores
R
R
O
O
T
T
i
i
p
p
o
o
a
a
t
t
o
o
r
r
Recursos
Episódios
1
1
.
.
s
s
e
e
l
l
e
e
c
c
i
i
o
o
n
n
a
a
r
r
t
t
i
i
p
p
o
o
c
c
l
l
i
i
e
e
n
n
t
t
e
e
2
2
.
.
S
S
e
e
t
t
i
i
p
p
o
o
_
_
c
c
l
l
i
i
e
e
n
n
t
t
e
e
=
=
v
v
i
i
p
p
e
e
n
n
t
t
ã
ã
o
o
r
r
e
e
t
t
o
o
r
r
n
n
a
a
t
t
r
r
u
u
e
e
s
s
e
e
n
n
ã
ã
o
o
r
r
e
e
t
t
o
o
r
r
n
n
a
a
f
f
a
a
l
l
s
s
e
e
Título
A
A
p
p
l
l
i
i
c
c
a
a
r
r
d
d
e
e
s
s
c
c
o
o
n
n
t
t
o
o
Objetivo
P
P
r
r
o
o
c
c
e
e
d
d
i
i
m
m
e
e
n
n
t
t
o
o
p
p
a
a
r
r
a
a
q
q
u
u
a
a
n
n
d
d
o
o
d
d
e
e
s
s
e
e
j
j
a
a
-
-
s
s
e
e
v
v
e
e
r
r
i
i
f
f
i
i
c
c
a
a
r
r
s
s
i
i
t
t
u
u
a
a
ç
ç
ã
ã
o
o
d
d
o
o
c
c
l
l
i
i
e
e
n
n
t
t
e
e
i
i
n
n
s
s
c
c
r
r
i
i
t
t
o
o
Contexto
S
S
i
i
s
s
t
t
e
e
m
m
a
a
r
r
e
e
t
t
o
o
r
r
n
n
a
a
v
v
a
a
l
l
o
o
r
r
i
i
n
n
s
s
c
c
r
r
i
i
ç
ç
ã
ã
o
o
c
c
o
o
m
m
d
d
e
e
s
s
c
c
o
o
n
n
t
t
o
o
a
a
p
p
l
l
i
i
c
c
a
a
d
d
o
o
d
d
e
e
3
3
0
0
%
%
1
1
.
.
r
r
e
e
c
c
e
e
b
b
e
e
c
c
o
o
m
m
o
o
e
e
n
n
t
t
r
r
a
a
d
d
a
a
v
v
a
a
l
l
o
o
r
r
i
i
n
n
s
s
c
c
r
r
i
i
ç
ç
a
a
o
o
Atores
R
R
O
O
T
T
i
i
p
p
o
o
a
a
t
t
o
o
r
r
Re
cursos
Episódios
1
1
.
.
r
r
e
e
t
t
o
o
r
r
n
n
a
a
v
v
a
a
l
l
o
o
r
r
i
i
n
n
s
s
c
c
r
r
i
i
ç
ç
ã
ã
o
o
:
:
=
=
v
v
a
a
l
l
o
o
r
r
i
i
n
n
s
s
c
c
r
r
i
i
ç
ç
ã
ã
o
o
-
-
3
3
0
0
%
%
Título
V
V
e
e
r
r
i
i
f
f
i
i
c
c
a
a
r
r
p
p
o
o
t
t
e
e
n
n
c
c
i
i
a
a
l
l
Objetivo
P
P
r
r
o
o
c
c
e
e
d
d
i
i
m
m
e
e
n
n
t
t
o
o
p
p
a
a
r
r
a
a
q
q
u
u
a
a
n
n
d
d
o
o
d
d
e
e
s
s
e
e
j
j
a
a
-
-
s
s
e
e
v
v
e
e
r
r
i
i
f
f
i
i
c
c
a
a
r
r
o
o
p
p
o
o
t
t
e
e
n
n
c
c
i
i
a
a
l
l
d
d
o
o
c
c
l
l
i
i
e
e
n
n
t
t
e
e
i
i
n
n
s
s
c
c
r
r
i
i
t
t
o
o
Contexto
S
S
i
i
s
s
t
t
e
e
m
m
a
a
r
r
e
e
t
t
o
o
r
r
n
n
a
a
t
t
r
r
u
u
e
e
p
p
a
a
r
r
a
a
o
o
c
c
a
a
s
s
o
o
d
d
e
e
s
s
e
e
r
r
u
u
m
m
c
c
l
l
i
i
e
e
n
n
t
t
e
e
v
v
i
i
p
p
e
e
m
m
p
p
o
o
t
t
e
e
n
n
c
c
i
i
a
a
l
l
,
,
c
c
a
a
s
s
o
o
c
c
o
o
n
n
t
t
r
r
a
a
r
r
i
i
o
o
r
r
e
e
t
t
o
o
r
r
n
n
a
a
f
f
a
a
l
l
s
s
e
e
P
P
r
r
é
é
-
-
c
c
o
o
n
n
d
d
:
:
1
1
.
.
r
r
e
e
c
c
e
e
b
b
e
e
c
c
o
o
m
m
o
o
e
e
n
n
t
t
r
r
a
a
d
d
a
a
a
a
i
i
d
d
e
e
n
n
t
t
i
i
f
f
i
i
c
c
a
a
ç
ç
ã
ã
o
o
d
d
o
o
c
c
l
l
i
i
e
e
n
n
t
t
e
e
i
i
n
n
s
s
c
c
r
r
i
i
t
t
o
o
Atores
R
R
O
O
T
T
i
i
p
p
o
o
a
a
t
t
o
o
r
r
Recursos
Episódios
1
1
.
.
s
s
e
e
l
l
e
e
c
c
i
i
o
o
n
n
a
a
r
r
t
t
o
o
t
t
a
a
l
l
d
d
e
e
e
e
v
v
e
e
n
n
t
t
o
o
s
s
a
a
n
n
u
u
a
a
i
i
s
s
n
n
o
o
s
s
q
q
u
u
a
a
i
i
s
s
o
o
c
c
l
l
i
i
e
e
n
n
t
t
e
e
i
i
n
n
s
s
c
c
r
r
i
i
t
t
o
o
p
p
a
a
r
r
t
t
i
i
c
c
i
i
p
p
o
o
u
u
2
2
.
.
S
S
e
e
t
t
o
o
t
t
a
a
l
l
>
>
3
3
e
e
n
n
t
t
ã
ã
o
o
r
r
e
e
t
t
o
o
r
r
n
n
a
a
t
t
r
r
u
u
e
e
s
s
e
e
n
n
ã
ã
o
o
r
r
e
e
t
t
o
o
r
r
n
n
a
a
f
f
a
a
l
l
s
s
e
e
Título
E
E
m
m
i
i
t
t
i
i
r
r
c
c
a
a
r
r
t
t
ã
ã
o
o
Objetivo
P
P
r
r
o
o
c
c
e
e
d
d
i
i
m
m
e
e
n
n
t
t
o
o
p
p
a
a
r
r
a
a
q
q
u
u
a
a
n
n
d
d
o
o
d
d
e
e
s
s
e
e
j
j
a
a
-
-
s
s
e
e
e
e
m
m
i
i
t
t
r
r
c
c
a
a
r
r
t
t
ã
ã
o
o
v
v
i
i
p
p
Contexto
S
S
i
i
s
s
t
t
e
e
m
m
a
a
e
e
m
m
i
i
t
t
i
i
n
n
d
d
o
o
c
c
a
a
r
r
t
t
ã
ã
o
o
V
V
I
I
P
P
P
P
r
r
é
é
-
-
c
c
o
o
n
n
d
d
:
:
1
1
.
.
r
r
e
e
c
c
e
e
b
b
e
e
c
c
o
o
m
m
o
o
e
e
n
n
t
t
r
r
a
a
d
d
a
a
a
a
i
i
d
d
e
e
n
n
t
t
i
i
f
f
i
i
c
c
a
a
ç
ç
ã
ã
o
o
d
d
o
o
c
c
l
l
i
i
e
e
n
n
t
t
e
e
i
i
n
n
s
s
c
c
r
r
i
i
t
t
o
o
Atores
R
R
O
O
T
T
i
i
p
p
o
o
a
a
t
t
o
o
r
r
Recursos
Episód
ios
1
1
.
.
C
C
a
a
r
r
t
t
ã
ã
o
o
é
é
i
i
m
m
p
p
r
r
e
e
s
s
s
s
o
o
5.
Experimentação
: Controle de Eventos Científicos 139
Título
C
C
P
P
F
F
_
_
c
c
l
l
i
i
e
e
n
n
t
t
e
e
Objetivo
P
P
r
r
o
o
c
c
e
e
d
d
i
i
m
m
e
e
n
n
t
t
o
o
p
p
a
a
r
r
a
a
q
q
u
u
a
a
n
n
d
d
o
o
d
d
e
e
s
s
e
e
j
j
a
a
-
-
s
s
e
e
s
s
a
a
b
b
e
e
r
r
a
a
s
s
i
i
t
t
u
u
a
a
ç
ç
ã
ã
o
o
j
j
u
u
n
n
t
t
o
o
a
a
o
o
s
s
ó
ó
r
r
g
g
ã
ã
o
o
s
s
c
c
o
o
m
m
p
p
e
e
t
t
e
e
n
n
t
t
e
e
s
s
s
s
o
o
b
b
r
r
e
e
a
a
s
s
i
i
t
t
u
u
a
a
ç
ç
ã
ã
o
o
d
d
o
o
c
c
l
l
i
i
e
e
n
n
t
t
e
e
Contexto
S
S
i
i
s
s
t
t
e
e
m
m
a
a
e
e
m
m
i
i
t
t
i
i
n
n
d
d
o
o
C
C
P
P
F
F
_
_
C
C
l
l
i
i
e
e
n
n
t
t
e
e
P
P
r
r
é
é
-
-
c
c
o
o
n
n
d
d
:
:
1
1
.
.
r
r
e
e
c
c
e
e
b
b
e
e
c
c
o
o
m
m
o
o
e
e
n
n
t
t
r
r
a
a
d
d
a
a
o
o
C
C
P
P
F
F
d
d
o
o
c
c
l
l
i
i
e
e
n
n
t
t
e
e
Ator
es
s
s
i
i
s
s
t
t
e
e
m
m
a
a
T
T
i
i
p
p
o
o
a
a
t
t
o
o
r
r
Recursos
Episódios
1
1
.
.
C
C
o
o
n
n
s
s
u
u
l
l
t
t
a
a
ó
ó
r
r
g
g
ã
ã
o
o
s
s
c
c
o
o
m
m
p
p
e
e
t
t
e
e
n
n
t
t
e
e
s
s
2
2
.
.
r
r
e
e
t
t
o
o
r
r
n
n
a
a
t
t
r
r
u
u
e
e
s
s
e
e
s
s
i
i
t
t
u
u
a
a
ç
ç
ã
ã
o
o
o
o
k
k
,
,
s
s
e
e
n
n
ã
ã
o
o
r
r
e
e
t
t
o
o
r
r
n
n
a
a
f
f
a
a
l
l
s
s
e
e
5
5
.
.
5
5
.
.
3
3
A
A
n
n
a
a
l
l
i
i
s
s
a
a
n
n
d
d
o
o
o
o
s
s
c
c
e
e
n
n
á
á
r
r
i
i
o
o
s
s
Vale observar que muitos cenários serão incluídos nesta fase, pois nem todos
os cenários identificado
s ao se descrever os episódios
3
foram definidos no LEL como
verbo
,
observando
-
se as regras para construção de cenários
de acordo com o LEL (Leite,
1997)
.
Um outro ponto interessante foi a inclusão das estratégias de satisfação dos
requisitos organizacionais como cenários.
A análise dos cenários está ligada ao fato de que precisamos validar e verificar
os cenários com os clientes a fim de identificar erros, omissões e/ou ampliar informações
de episódios. Seguindo os passos para a construção de cenários deve
-
se
unificar os
cenários se eles possuírem o mesmo objetivo ou mesmos episódios.
5
5
.
.
6
6
F
F
a
a
s
s
e
e
3
3
–
–
D
D
e
e
f
f
i
i
n
n
i
i
ç
ç
ã
ã
o
o
d
d
e
e
A
A
s
s
p
p
e
e
c
c
t
t
o
o
s
s
C
C
a
a
n
n
d
d
i
i
d
d
a
a
t
t
o
o
s
s
A definição dos aspectos candidatos foi realizada seguindo as diretrizes
propostas no capítulo 4.
Assim, primeiramente, iden
tificamos os requisitos não funcionais como
aspectos candidatos, outros aspectos podem ser identificados levando
-
se em consideração
os outros passos das diretrizes apontadas na fase 3.
3
Cysneiros (2002) realiza a descrição dos cenários de forma bem sucinta, sendo de poucas palavras,
utilizando
-
se o principio do vocabulário mínimo, não sendo
portanto, rico em detalhes. Breitman (2000)
descreve os cenários de forma bem detalhada, inclusive fazendo referencias as telas usadas no acesso.
Usaremos o meio termo, não seremos tão detalhistas e nem tão vagos nas nossas descrições. Quando a
situação f
or julgada necessária, seremos mais detalhistas.
5.
Experimentação
: Controle de Eventos Científicos 140
Deste modo, foram identificados quatro aspectos candidatos no nosso es
tudo de
caso:
·
Confidenciabilidade – Requisito não funcional requisitado pela maioria
dos cenários;
·
Integridade
-
Requisito não funcional requisitado por todos os cenários
onde exige a atualização;
·
CPF_Cliente – foi definido como aspecto por se tratar de um
a restrição
que pode ser aplicada em outros cenários e outros projetos, sem que a
funcionalidade básica seja alterada caso venha a ser retirado;
·
Validar Situação
–
foi definido como aspecto por se tratar de uma
constraint organizacional que pode ser aplica
da em outros cenários e
em outros projetos.
A tabela 5.
9
relaciona os aspectos encontrados com os cenários
correspondentes e sua influência sobre eles.
5.
Experimentação
: Controle de Eventos Científicos 141
T
ABELA
5.
9–
C
ONTRIBUIÇÕES DOS
A
SPECTOS
Aspectos Candidatos
Confidenciabilidade
Integridade
CPF_Cliente
Validar
Situação
identificador
Cenário
-
+
-
+
-
+
-
+
1
1
A
A
l
l
t
t
e
e
r
r
a
a
r
r
p
p
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
n
n
t
t
e
e
X
X
2
2
E
E
x
x
c
c
l
l
u
u
i
i
r
r
p
p
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
n
n
t
t
e
e
X
X
3
3
C
C
o
o
n
n
s
s
u
u
l
l
t
t
a
a
r
r
p
p
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
n
n
t
t
e
e
s
s
X
4
4
C
C
a
a
d
d
a
a
s
s
t
t
r
r
a
a
r
r
e
e
v
v
e
e
n
n
t
t
o
o
X
X
5
5
C
C
a
a
d
d
a
a
s
s
t
t
r
r
a
a
r
r
c
c
o
o
m
m
i
i
s
s
s
s
ã
ã
o
o
X
X
6
6
C
C
a
a
d
d
a
a
s
s
t
t
r
r
a
a
r
r
c
c
o
o
m
m
i
i
t
t
ê
ê
X
X
7
7
R
R
e
e
c
c
e
e
b
b
e
e
r
r
r
r
e
e
c
c
u
u
r
r
s
s
o
o
s
s
X
X
8
8
D
D
i
i
s
s
t
t
r
r
i
i
b
b
u
u
i
i
r
r
r
r
e
e
c
c
u
u
r
r
s
s
o
o
s
s
X
X
9
9
P
P
a
a
g
g
a
a
r
r
f
f
o
o
r
r
n
n
e
e
c
c
e
e
d
d
o
o
r
r
X
X
1
1
0
0
R
R
e
e
c
c
e
e
b
b
e
e
r
r
p
p
a
a
g
g
a
a
m
m
e
e
n
n
t
t
o
o
X
X
1
1
1
1
C
C
o
o
n
n
s
s
u
u
l
l
t
t
a
a
r
r
p
p
r
r
o
o
g
g
r
r
a
a
m
m
a
a
ç
ç
ã
ã
o
o
X
1
1
2
2
I
I
n
n
s
s
c
c
r
r
e
e
v
v
e
e
r
r
-
-
s
s
e
e
e
e
m
m
e
e
v
v
e
e
n
n
t
t
o
o
X
X
X
X
1
1
3
3
E
E
n
n
v
v
i
i
a
a
r
r
t
t
r
r
a
a
b
b
a
a
l
l
h
h
o
o
X
X
1
1
4
4
E
E
f
f
e
e
t
t
u
u
a
a
r
r
p
p
a
a
g
g
a
a
m
m
e
e
n
n
t
t
o
o
X
X
X
1
1
5
5
E
E
n
n
v
v
i
i
a
a
r
r
p
p
a
a
l
l
e
e
s
s
t
t
r
r
a
a
X
X
1
1
6
6
C
C
a
a
d
d
a
a
s
s
t
t
r
r
a
a
r
r
p
p
a
a
r
r
c
c
e
e
i
i
r
r
o
o
s
s
X
X
1
1
7
7
E
E
n
n
v
v
i
i
a
a
r
r
m
m
a
a
t
t
e
e
r
r
i
i
a
a
l
l
X
X
1
1
8
8
E
E
m
m
i
i
t
t
i
i
r
r
c
c
e
e
r
r
t
t
i
i
f
f
i
i
c
c
a
a
d
d
o
o
s
s
X
X
1
1
9
9
A
A
t
t
u
u
a
a
l
l
i
i
z
z
a
a
p
p
r
r
o
o
g
g
r
r
a
a
m
m
a
a
ç
ç
ã
ã
o
o
X
X
2
2
0
0
S
S
e
e
l
l
e
e
c
c
i
i
o
o
n
n
a
a
r
r
t
t
r
r
a
a
b
b
a
a
l
l
h
h
o
o
X
X
2
2
1
1
F
F
o
o
r
r
n
n
e
e
c
c
e
e
r
r
r
r
e
e
c
c
u
u
r
r
s
s
o
o
s
s
X
X
2
2
2
2
S
S
e
e
l
l
e
e
c
c
i
i
o
o
n
n
a
a
r
r
m
m
i
i
n
n
i
i
s
s
t
t
r
r
a
a
n
n
t
t
e
e
X
X
2
2
3
3
S
S
e
e
l
l
e
e
c
c
i
i
o
o
n
n
a
a
r
r
p
p
a
a
l
l
e
e
s
s
t
t
r
r
a
a
n
n
t
t
e
e
X
X
2
2
4
4
E
E
m
m
i
i
t
t
i
i
r
r
c
c
r
r
a
a
c
c
h
h
á
á
s
s
X
X
2
2
5
5
E
E
n
n
v
v
i
i
a
a
r
r
r
r
e
e
q
q
u
u
i
i
s
s
i
i
ç
ç
ã
ã
o
o
X
X
5.
Experimentação
: Controle de Eventos Científicos 142
O aspecto CPF_Cliente apesar de inicialmente se tratar de uma restrição onde o
usuário seja o prejudicado em termos de tempo (pois pode
demorar um pouco mais para
ser verificado), foi definido como positivo pois garante uma confiabilidade das
informações que estão sendo prestadas, ou seja, o cliente é fidedigno.
Para definir a composição entre os aspectos, ou seja, como será realizada a
c
hamada para a execução do aspecto, usa
-
se
o modelo proposto na Fase 3 do Capitulo 4.
A tabela 5.
10
foi especificada para cada aspecto candidato de acordo com o
proposto pela DAORE.
T
ABELA
5.1
0 –
.
C
OMPOSIÇÃO DOS
A
SPECTOS
I
DENTIFICADOS
A
SPECTO CANDIDATO
:
AC#1
-
Confidenciabilidade
CENARIO
AFETADO
CONDIÇÃO
R
EGRA DE
COMPOSIÇÃO
P
ONTO DE
JUNÇÃO
I
NFORMAÇÕES ADICIONAI
S
C
C
N
N
#
#
1
1
-
-
A
A
l
l
t
t
e
e
r
r
a
a
r
r
p
p
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
n
n
t
t
e
e
-
WRAP
1
Se situaçãoOK então
executa(ponto junção)
Senão exibe(msgErro)
C
C
N
N
#
#
2
2
-
-
E
E
x
x
c
c
l
l
u
u
i
i
r
r
p
p
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
n
n
t
t
e
e
-
WRAP
1
Se situaçãoOK então
executa(ponto junção)
Senão exibe(msgErro)
C
C
N
N
#
#
3
3
-
-
C
C
o
o
n
n
s
s
u
u
l
l
t
t
a
a
r
r
p
p
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
n
n
t
t
e
e
s
s
-
WRAP
1
Se situaçãoOK então
executa(ponto junção)
Senão exibe(msgErro)
C
C
N
N
#
#
4
4
-
-
C
C
a
a
d
d
a
a
s
s
t
t
r
r
a
a
r
r
e
e
v
v
e
e
n
n
t
t
o
o
-
WRAP
1
Se situaçãoOK então
executa(ponto junção)
Senão ex
ibe(msgErro)
C
C
N
N
#
#
5
5
-
-
C
C
a
a
d
d
a
a
s
s
t
t
r
r
a
a
r
r
c
c
o
o
m
m
i
i
s
s
s
s
ã
ã
o
o
-
WRAP
1
Se situaçãoOK então
executa(ponto junção)
Senão exibe(msgErro)
C
C
N
N
#
#
6
6
-
-
C
C
a
a
d
d
a
a
s
s
t
t
r
r
a
a
r
r
c
c
o
o
m
m
i
i
t
t
ê
ê
-
WRAP
1
Se situaçãoOK então
executa(ponto junção)
Senão exibe(msgErro)
C
C
N
N
#
#
7
7
-
-
R
R
e
e
c
c
e
e
b
b
e
e
r
r
r
r
e
e
c
c
u
u
r
r
s
s
o
o
s
s
-
WRAP
1
Se situ
açãoOK então
executa(ponto junção)
Senão exibe(msgErro)
C
C
N
N
#
#
8
8
-
-
D
D
i
i
s
s
t
t
r
r
i
i
b
b
u
u
i
i
r
r
r
r
e
e
c
c
u
u
r
r
s
s
o
o
s
s
-
WRAP
1
Se situaçãoOK então
executa(ponto junção)
Senão exibe(msgErro)
C
C
N
N
#
#
9
9
-
-
P
P
a
a
g
g
a
a
r
r
f
f
o
o
r
r
n
n
e
e
c
c
e
e
d
d
o
o
r
r
-
WRAP
1
Se situaçãoOK então
executa(ponto junção)
Senão exibe(msgErro)
C
C
N
N
#
#
1
1
0
0
-
-
R
R
e
e
c
c
e
e
b
b
e
e
r
r
p
p
a
a
g
g
a
a
m
m
e
e
n
n
t
t
o
o
-
WRAP
1
Se situaçãoOK então
executa(ponto junção)
Senão exibe(msgErro)
5.
Experimentação
: Controle de Eventos Científicos 143
C
C
N
N
#
#
1
1
1
1
-
-
C
C
o
o
n
n
s
s
u
u
l
l
t
t
a
a
r
r
p
p
r
r
o
o
g
g
r
r
a
a
m
m
a
a
ç
ç
ã
ã
o
o
-
WRAP
1
Se situaçãoOK então
executa(ponto junção)
Senão exibe(msgErro)
C
C
N
N
#
#
1
1
2
2
-
-
I
I
n
n
s
s
c
c
r
r
e
e
v
v
e
e
r
r
-
-
s
s
e
e
e
e
m
m
e
e
v
v
e
e
n
n
t
t
o
o
-
WRAP
1
Se sit
uaçãoOK então
executa(ponto junção)
Senão exibe(msgErro)
C
C
N
N
#
#
1
1
3
3
-
-
E
E
n
n
v
v
i
i
a
a
r
r
t
t
r
r
a
a
b
b
a
a
l
l
h
h
o
o
-
WRAP
1
Se situaçãoOK então
executa(ponto junção)
Senão exibe(msgErro)
C
C
N
N
#
#
1
1
4
4
-
-
E
E
f
f
e
e
t
t
u
u
a
a
r
r
p
p
a
a
g
g
a
a
m
m
e
e
n
n
t
t
o
o
-
WRAP
1
Se situaçãoOK então
executa(ponto junção)
Senão exibe(msgErro)
C
C
N
N
#
#
1
1
5
5
-
-
E
E
n
n
v
v
i
i
a
a
r
r
p
p
a
a
l
l
e
e
s
s
t
t
r
r
a
a
-
WRAP
1
Se situaçãoOK então
executa(ponto junção)
Senão exibe(msgErro)
C
C
N
N
#
#
1
1
6
6
-
-
C
C
a
a
d
d
a
a
s
s
t
t
r
r
a
a
r
r
p
p
a
a
r
r
c
c
e
e
i
i
r
r
o
o
s
s
-
WRAP
1
Se situaçãoOK então
executa(ponto junção)
Senão exibe(msgErro)
C
C
N
N
#
#
1
1
7
7
-
-
E
E
n
n
v
v
i
i
a
a
r
r
m
m
a
a
t
t
e
e
r
r
i
i
a
a
l
l
-
WRAP
1
Se situaçãoOK ent
ão
executa(ponto junção)
Senão exibe(msgErro)
C
C
N
N
#
#
1
1
8
8
-
-
E
E
m
m
i
i
t
t
i
i
r
r
c
c
e
e
r
r
t
t
i
i
f
f
i
i
c
c
a
a
d
d
o
o
s
s
-
WRAP
1
Se situaçãoOK então
executa(ponto junção)
Senão exibe(msgErro)
C
C
N
N
#
#
1
1
9
9
-
-
A
A
t
t
u
u
a
a
l
l
i
i
z
z
a
a
p
p
r
r
o
o
g
g
r
r
a
a
m
m
a
a
ç
ç
ã
ã
o
o
-
WRAP
1
Se situaçãoOK então
executa(ponto junção)
Senão exibe(msgErro)
C
C
N
N
#
#
2
2
0
0
-
-
S
S
e
e
l
l
e
e
c
c
i
i
o
o
n
n
a
a
r
r
t
t
r
r
a
a
b
b
a
a
l
l
h
h
o
o
-
WRAP
1
Se situaçãoOK então
executa(ponto junção)
Senão exibe(msgErro)
C
C
N
N
#
#
2
2
1
1
-
-
F
F
o
o
r
r
n
n
e
e
c
c
e
e
r
r
r
r
e
e
c
c
u
u
r
r
s
s
o
o
s
s
-
WRAP
1
Se situaçãoOK então
executa(ponto junção)
Senão exibe(msgErro)
C
C
N
N
#
#
2
2
2
2
-
-
S
S
e
e
l
l
e
e
c
c
i
i
o
o
n
n
a
a
r
r
m
m
i
i
n
n
i
i
s
s
t
t
r
r
a
a
n
n
t
t
e
e
-
WRAP
1
Se situaçãoO
K então
executa(ponto junção)
Senão exibe(msgErro)
C
C
N
N
#
#
2
2
3
3
-
-
S
S
e
e
l
l
e
e
c
c
i
i
o
o
n
n
a
a
r
r
p
p
a
a
l
l
e
e
s
s
t
t
r
r
a
a
n
n
t
t
e
e
-
WRAP
1
Se situaçãoOK então
executa(ponto junção)
Senão exibe(msgErro)
C
C
N
N
#
#
2
2
4
4
-
-
E
E
m
m
i
i
t
t
i
i
r
r
c
c
r
r
a
a
c
c
h
h
á
á
s
s
-
WRAP
1
Se situaçãoOK então
executa(ponto junção)
Senão exibe(msgErro)
C
C
N
N
#
#
2
2
5
5
-
-
E
E
n
n
v
v
i
i
a
a
r
r
r
r
e
e
q
q
u
u
i
i
s
s
i
i
ç
ç
ã
ã
o
o
-
WRAP
1
Se situaçãoOK então
executa(ponto junção)
Senão exibe(msgErro)
5.
Experimentação
: Controle de Eventos Científicos 144
A
SPECTO CANDIDATO
:
AC#2
-
Integridade
CENARIO
AFETADO
CONDIÇÃO
R
EGRA DE
COMPOSIÇÃO
P
ONTO DE
JUNÇÃO
I
NFORMAÇÕES ADICIONAI
S
C
C
N
N
#
#
1
1
-
-
A
A
l
l
t
t
e
e
r
r
a
a
r
r
p
p
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
n
n
t
t
e
e
-
WRAP
1
Se situaçãoOK então
executa(ponto junção)
Senão exibe(msgErro)
C
C
N
N
#
#
2
2
-
-
E
E
x
x
c
c
l
l
u
u
i
i
r
r
p
p
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
n
n
t
t
e
e
-
WRAP
1
Se situaçãoOK então
executa(ponto junção)
Senão exibe(msgErro)
C
C
N
N
#
#
4
4
-
-
C
C
a
a
d
d
a
a
s
s
t
t
r
r
a
a
r
r
e
e
v
v
e
e
n
n
t
t
o
o
-
WRAP
1
Se situaçãoOK então
executa(ponto junção)
Se
não exibe(msgErro)
C
C
N
N
#
#
5
5
-
-
C
C
a
a
d
d
a
a
s
s
t
t
r
r
a
a
r
r
c
c
o
o
m
m
i
i
s
s
s
s
ã
ã
o
o
-
WRAP
1
Se situaçãoOK então
executa(ponto junção)
Senão exibe(msgErro)
C
C
N
N
#
#
6
6
-
-
C
C
a
a
d
d
a
a
s
s
t
t
r
r
a
a
r
r
c
c
o
o
m
m
i
i
t
t
ê
ê
-
WRAP
1
Se situaçãoOK então
executa(ponto junção)
Senão exibe(msgErro)
C
C
N
N
#
#
7
7
-
-
R
R
e
e
c
c
e
e
b
b
e
e
r
r
r
r
e
e
c
c
u
u
r
r
s
s
o
o
s
s
-
WRAP
1
Se
situaçãoOK então
executa(ponto junção)
Senão exibe(msgErro)
C
C
N
N
#
#
8
8
-
-
D
D
i
i
s
s
t
t
r
r
i
i
b
b
u
u
i
i
r
r
r
r
e
e
c
c
u
u
r
r
s
s
o
o
s
s
-
WRAP
1
Se situaçãoOK então
executa(ponto junção)
Senão exibe(msgErro)
C
C
N
N
#
#
9
9
-
-
P
P
a
a
g
g
a
a
r
r
f
f
o
o
r
r
n
n
e
e
c
c
e
e
d
d
o
o
r
r
-
WRAP
1
Se situaçãoOK então
executa(ponto junção)
Senão exibe(ms
gErro)
C
C
N
N
#
#
1
1
0
0
-
-
R
R
e
e
c
c
e
e
b
b
e
e
r
r
p
p
a
a
g
g
a
a
m
m
e
e
n
n
t
t
o
o
-
WRAP
1
Se situaçãoOK então
executa(ponto junção)
Senão exibe(msgErro)
C
C
N
N
#
#
1
1
2
2
-
-
I
I
n
n
s
s
c
c
r
r
e
e
v
v
e
e
r
r
-
-
s
s
e
e
e
e
m
m
e
e
v
v
e
e
n
n
t
t
o
o
-
WRAP
1
Se situaçãoOK então
executa(ponto junção)
Senão exibe(msgErro)
C
C
N
N
#
#
1
1
3
3
-
-
E
E
n
n
v
v
i
i
a
a
r
r
t
t
r
r
a
a
b
b
a
a
l
l
h
h
o
o
-
WRAP
1
Se sit
uaçãoOK então
executa(ponto junção)
Senão exibe(msgErro)
C
C
N
N
#
#
1
1
4
4
-
-
E
E
f
f
e
e
t
t
u
u
a
a
r
r
p
p
a
a
g
g
a
a
m
m
e
e
n
n
t
t
o
o
-
WRAP
1
Se situaçãoOK então
executa(ponto junção)
Senão exibe(msgErro)
C
C
N
N
#
#
1
1
5
5
-
-
E
E
n
n
v
v
i
i
a
a
r
r
p
p
a
a
l
l
e
e
s
s
t
t
r
r
a
a
-
WRAP
1
Se situaçãoOK então
executa(ponto junção)
Senão exibe(msgErro)
5.
Experimentação
: Controle de Eventos Científicos 145
C
C
N
N
#
#
1
1
6
6
-
-
C
C
a
a
d
d
a
a
s
s
t
t
r
r
a
a
r
r
p
p
a
a
r
r
c
c
e
e
i
i
r
r
o
o
s
s
-
WRAP
1
Se situaçãoOK então
executa(ponto junção)
Senão exibe(msgErro)
C
C
N
N
#
#
1
1
7
7
-
-
E
E
n
n
v
v
i
i
a
a
r
r
m
m
a
a
t
t
e
e
r
r
i
i
a
a
l
l
-
WRAP
1
Se situaçãoOK então
executa(ponto junção)
Senão exibe(msgErro)
C
C
N
N
#
#
1
1
8
8
-
-
E
E
m
m
i
i
t
t
i
i
r
r
c
c
e
e
r
r
t
t
i
i
f
f
i
i
c
c
a
a
d
d
o
o
s
s
-
WRAP
1
Se situaçãoOK
então
executa(ponto junção)
Senão exibe(msgErro)
C
C
N
N
#
#
1
1
9
9
-
-
A
A
t
t
u
u
a
a
l
l
i
i
z
z
a
a
p
p
r
r
o
o
g
g
r
r
a
a
m
m
a
a
ç
ç
ã
ã
o
o
-
WRAP
1
Se situaçãoOK então
executa(ponto junção)
Senão exibe(msgErro)
C
C
N
N
#
#
2
2
0
0
-
-
S
S
e
e
l
l
e
e
c
c
i
i
o
o
n
n
a
a
r
r
t
t
r
r
a
a
b
b
a
a
l
l
h
h
o
o
-
WRAP
1
Se situaçãoOK então
executa(ponto junção)
Senão exibe(msgErro)
C
C
N
N
#
#
2
2
1
1
-
-
F
F
o
o
r
r
n
n
e
e
c
c
e
e
r
r
r
r
e
e
c
c
u
u
r
r
s
s
o
o
s
s
-
WRAP
1
Se situaçãoOK então
executa(ponto junção)
Senão exibe(msgErro)
C
C
N
N
#
#
2
2
2
2
-
-
S
S
e
e
l
l
e
e
c
c
i
i
o
o
n
n
a
a
r
r
m
m
i
i
n
n
i
i
s
s
t
t
r
r
a
a
n
n
t
t
e
e
-
WRAP
1
Se situaçãoOK então
executa(ponto junção)
Senão exibe(msgErro)
C
C
N
N
#
#
2
2
3
3
-
-
S
S
e
e
l
l
e
e
c
c
i
i
o
o
n
n
a
a
r
r
p
p
a
a
l
l
e
e
s
s
t
t
r
r
a
a
n
n
t
t
e
e
-
WRAP
1
Se si
tuaçãoOK então
executa(ponto junção)
Senão exibe(msgErro)
C
C
N
N
#
#
2
2
4
4
-
-
E
E
m
m
i
i
t
t
i
i
r
r
c
c
r
r
a
a
c
c
h
h
á
á
s
s
-
WRAP
1
Se situaçãoOK então
executa(ponto junção)
Senão exibe(msgErro)
C
C
N
N
#
#
2
2
5
5
-
-
E
E
n
n
v
v
i
i
a
a
r
r
r
r
e
e
q
q
u
u
i
i
s
s
i
i
ç
ç
ã
ã
o
o
-
WRAP
1
Se situaçãoOK então
executa(ponto junção)
Senão exibe(msgErro)
A
SPECTO CANDIDATO
:
AC#3
-
CPF_
CLIENTE
CENARIO
AFETADO
CONDIÇÃO
R
EGRA DE
COMPOSIÇÃO
P
ONTO DE
JUNÇÃO
I
NFORMAÇÕES ADICIONAI
S
C
C
N
N
#
#
1
1
2
2
-
-
I
I
n
n
s
s
c
c
r
r
e
e
v
v
e
e
r
r
-
-
s
s
e
e
e
e
m
m
e
e
v
v
e
e
n
n
t
t
o
o
-
wrap
3
Se situaçãoOK então
executa(ponto junção)
Senão exibe(msgErro)
A
SPECTO CANDIDATO
:
AC#
4
-
V
ALIDAR SITUAÇÃO
CENARIO
AFETADO
CONDIÇÃO
R
EGRA DE
COMPOSIÇÃO
P
ONTO DE
JUNÇÃO
I
NFORMAÇÕES ADICIONAI
S
5.
Experimentação
: Controle de Eventos Científicos 146
C
C
N
N
#
#
1
1
2
2
-
-
I
I
n
n
s
s
c
c
r
r
e
e
v
v
e
e
r
r
-
-
s
s
e
e
e
e
m
m
e
e
v
v
e
e
n
n
t
t
o
o
-
overlap.after|
3
Se situaçãoOK então
executa(ponto junção)
Senão exibe(msgErro)
C
C
N
N
#
#
1
1
4
4
-
-
E
E
f
f
e
e
t
t
u
u
a
a
r
r
p
p
a
a
g
g
a
a
m
m
e
e
n
n
t
t
o
o
-
o
verlap.
before
|
2
S
E SITUAÇÃO
OK
ENTÃO
EXECUTA
(
PONTO JUNÇÃO
)
S
ENÃO EXIBE
(
MSG
E
RRO
)
Agora
se deve
verificar se não há conflitos entre os aspectos candidatos. Eles
são identificados q
uando diferentes
aspectos candidatos
devem ser aplicados num mesmo
ponto de
junção de um cenário
com
os mesmos operadores de composição.
Neste projeto
, os aspectos relacionados
à
confiabilidade e integridade
estão
com os mesmos operadores e mesmo pontos de junção
. Assim, deve
-
se
aplicar uma ordem
de precedência para definir qual
será executado primeiro. No capitulo 4 descreve
-
se
com
mais detalhes como fazer esta operação.
A tabela 5.11 apresenta a resolução dos conflitos.
T
ABELA
5.1
1
–
R
ESOLUÇÃO DE CONFLITO
S
Cenários
AC#1
AC#2
C
C
N
N
#
#
1
1
-
-
A
A
l
l
t
t
e
e
r
r
a
a
r
r
p
p
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
n
n
t
t
e
e
P1
-
W =1º
P1
-
W =2º
C
C
N
N
#
#
2
2
-
-
E
E
x
x
c
c
l
l
u
u
i
i
r
r
p
p
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
n
n
t
t
e
e
P1
-
W =1º
P1
-
W =2º
C
C
N
N
#
#
4
4
-
-
C
C
a
a
d
d
a
a
s
s
t
t
r
r
a
a
r
r
e
e
v
v
e
e
n
n
t
t
o
o
P1
-
W =1º
P1
-
W =2º
C
C
N
N
#
#
5
5
-
-
C
C
a
a
d
d
a
a
s
s
t
t
r
r
a
a
r
r
c
c
o
o
m
m
i
i
s
s
s
s
ã
ã
o
o
P1
-
W =1º
P1
-
W =2º
C
C
N
N
#
#
6
6
-
-
C
C
a
a
d
d
a
a
s
s
t
t
r
r
a
a
r
r
c
c
o
o
m
m
i
i
t
t
ê
ê
P1
-
W =1º
P1
-
W =2º
C
C
N
N
#
#
7
7
-
-
R
R
e
e
c
c
e
e
b
b
e
e
r
r
r
r
e
e
c
c
u
u
r
r
s
s
o
o
s
s
P1
-
W =1º
P1
-
W =2º
C
C
N
N
#
#
8
8
-
-
D
D
i
i
s
s
t
t
r
r
i
i
b
b
u
u
i
i
r
r
r
r
e
e
c
c
u
u
r
r
s
s
o
o
s
s
P1
-
W
=1º
P1
-
W =2º
C
C
N
N
#
#
9
9
-
-
P
P
a
a
g
g
a
a
r
r
f
f
o
o
r
r
n
n
e
e
c
c
e
e
d
d
o
o
r
r
P1
-
W =1º
P1
-
W =2º
C
C
N
N
#
#
1
1
0
0
-
-
R
R
e
e
c
c
e
e
b
b
e
e
r
r
p
p
a
a
g
g
a
a
m
m
e
e
n
n
t
t
o
o
P1
-
W =1º
P1
-
W =2º
C
C
N
N
#
#
1
1
2
2
-
-
I
I
n
n
s
s
c
c
r
r
e
e
v
v
e
e
r
r
-
-
s
s
e
e
e
e
m
m
e
e
v
v
e
e
n
n
t
t
o
o
P1
-
W =1º
P1
-
W =2º
C
C
N
N
#
#
1
1
3
3
-
-
E
E
n
n
v
v
i
i
a
a
r
r
t
t
r
r
a
a
b
b
a
a
l
l
h
h
o
o
P1
-
W =1º
P1
-
W =2º
C
C
N
N
#
#
1
1
4
4
-
-
E
E
f
f
e
e
t
t
u
u
a
a
r
r
p
p
a
a
g
g
a
a
m
m
e
e
n
n
t
t
o
o
P1
-
W =1º
P1
-
W =2º
C
C
N
N
#
#
1
1
5
5
-
-
E
E
n
n
v
v
i
i
a
a
r
r
p
p
a
a
l
l
e
e
s
s
t
t
r
r
a
a
P1
-
W =1º
P1
-
W =2º
C
C
N
N
#
#
1
1
6
6
-
-
C
C
a
a
d
d
a
a
s
s
t
t
r
r
a
a
r
r
p
p
a
a
r
r
c
c
e
e
i
i
r
r
o
o
s
s
P1
-
W =1º
P1
-
W =2º
C
C
N
N
#
#
1
1
7
7
-
-
E
E
n
n
v
v
i
i
a
a
r
r
m
m
a
a
t
t
e
e
r
r
i
i
a
a
l
l
P1
-
W =1º
P1
-
W =2º
C
C
N
N
#
#
1
1
8
8
-
-
E
E
m
m
i
i
t
t
i
i
r
r
c
c
e
e
r
r
t
t
i
i
f
f
i
i
c
c
a
a
d
d
o
o
s
s
P1
-
W =1º
P1
-
W =2º
C
C
N
N
#
#
1
1
9
9
-
-
A
A
t
t
u
u
a
a
l
l
i
i
z
z
a
a
p
p
r
r
o
o
g
g
r
r
a
a
m
m
a
a
ç
ç
ã
ã
o
o
P1
-
W =1º
P1
-
W =2º
C
C
N
N
#
#
2
2
0
0
-
-
S
S
e
e
l
l
e
e
c
c
i
i
o
o
n
n
a
a
r
r
t
t
r
r
a
a
b
b
a
a
l
l
h
h
o
o
P1
-
W
=1º
P1
-
W =2º
C
C
N
N
#
#
2
2
1
1
-
-
F
F
o
o
r
r
n
n
e
e
c
c
e
e
r
r
r
r
e
e
c
c
u
u
r
r
s
s
o
o
s
s
P1
-
W =1º
P1
-
W =2º
C
C
N
N
#
#
2
2
2
2
-
-
S
S
e
e
l
l
e
e
c
c
i
i
o
o
n
n
a
a
r
r
m
m
i
i
n
n
i
i
s
s
t
t
r
r
a
a
n
n
t
t
e
e
P1
-
W =1º
P1
-
W =2º
C
C
N
N
#
#
2
2
3
3
-
-
S
S
e
e
l
l
e
e
c
c
i
i
o
o
n
n
a
a
r
r
p
p
a
a
l
l
e
e
s
s
t
t
r
r
a
a
n
n
t
t
e
e
P1
-
W =1º
P1
-
W =2º
C
C
N
N
#
#
2
2
4
4
-
-
E
E
m
m
i
i
t
t
i
i
r
r
c
c
r
r
a
a
c
c
h
h
á
á
s
s
P1
-
W =1º
P1
-
W =2º
C
C
N
N
#
#
2
2
5
5
-
-
E
E
n
n
v
v
i
i
a
a
r
r
r
r
e
e
q
q
u
u
i
i
s
s
i
i
ç
ç
ã
ã
o
o
P1
-
W =1º
P1
-
W =2º
5.
Experimentação
: Controle de Eventos Científicos 147
Obse
rvando a tabela 5.1
1
podemos deduzir que o aspecto candidato AC #1
-
Confiabilidade será executado antes do aspecto candidato AC #2 –
Integridade. Decisões
como estas devem ocorrer com vários aspectos a serem incluídos nos projetos. É
importante que seja tom
ado uma decisão por parte do gerente de projeto, clientes e
engenheiro de requisitos.
5
5
.
.
7
7
F
F
a
a
s
s
e
e
4
4
–
–
M
M
a
a
p
p
e
e
a
a
m
m
e
e
n
n
t
t
o
o
d
d
e
e
O
O
n
n
t
t
o
o
l
l
o
o
g
g
i
i
a
a
s
s
Nesta fase aplicaremos o método proposto por Breitman (2003).
Neste método, os termos do léxico classificados como do tipo obje
to e sujeito
serão mapeados em classes da ontologia; os termos classificados em verbo serão
mapeados para propriedades; os termos classificados como do tipo estado serão mapeados
para classes ou propriedades, dependendo de sua importância relativa para a o
ntologia; a
noção de cada termo é mapeada na descrição da respectiva classe; e através da lista de
impactos de cada termo do léxico mapeia
-
se o verbo em propriedades e o predicado em
restrições das classes.
A tabela 4.
9
, apresentada no Capítulo 4 apresent
a um resumo das ações
realizadas durante o processo de mapeamento dos termos do LEL para ontologia.
Breitman (2003) define alguns passos (Figura 5.3) para o processo de
mapeamento e assim, seguiremos estes passos para a construção de ontologia do
gerenciam
ento de eventos.
5.
Experimentação
: Controle de Eventos Científicos 148
F
IGURA
5.3
–
O
P
ROCESSO DE
M
APEAMENTO
LEL
–
O
NTOLOGIAS
.
B
REITMAN
(2003)
1
–
Listar os termos alfabeticamente de acordo com seu tipo (verbo, objeto, sujeito ou
estado)
2
–
Fazer três listas: Propriedades, classes e axiomas. Na lista de classes cada entrada terá
um nome, descrição (linguagem natural) e uma lista contendo zero ou mais restrições
(função que relaciona a classe em questão a outras, de maneira não
-
taxonômica). As
entradas na lista de axiomas terão nomes (labels) s
omente.
3
–
Utilizando a lista de símbolos do léxico classificados como sujeito ou objeto, para
cada termo:
3.1
–
Adicionar uma nova classe a lista de classes. O nome da classe é o símbolo do
léxico propriamente dito. A descrição da classe é a noção do ter
mo.
3.1.1
–
para cada impacto,
3.1.1.1
–
checar se já não faz parte da lista de propriedades da ontologia
3.1.1.2
-
Caso não faça parte da lista (a propriedade ainda não existe), adicionar
uma nova propriedade na lista (de propriedades). O nome da propriedade deve ser
baseado no verbo utilizado para descrever o impacto.
3.1.1.2.1
–
verificar consistências
3.1.1.3
–
Na lista de classes, adicionar uma nova restrição para a classe em
questão. A restrição é formada pela classe + a propriedade (definida em 3.1.1
.1) + a classe
relacionada (essa classe é o objeto direto/indireto do verbo utilizado no impacto do
símbolo do léxico. Usualmente é um termo do próprio léxico e aparece sublinhado)
3.1.1.4
–
Checar se existem indicativos de negação no vocabulário mínimo qu
e
relacionem duas ou mais classes. Verificar se essas classes possuem um relacionamento
do tipo disjuntos(exemplo: macho e fêmea).
3.1.1.4.1
–
Se verdadeiro, adicionar o
disjoint
a lista de axiomas.
3.2
–
Verificar consistência
4
–
Utilizando a lista de sí
mbolos classificados como tipo verbo, para cada termo:
4.1.1
–
Checar se já faz parte da lista de propriedades da ontologia.
4.1.1.1
–
Caso não faça parte da lista (a propriedade não existe), adicionar uma
nova propriedade a lista (de propriedades). O nome
da propriedade é o símbolo do léxico
propriamente dito.
4.1.1.1.1
-
Verificar consistência
5
–
Utilizando a lista de símbolos classificados como tipo estado, para cada termo:
5.1.1
–
Para cada impacto.
5.1.1.1
–
Tentar identificar a importância relativa
do termo para a ontologia.
Essa estratégia é similar a utilização de questões de competência proposta por Gruninger
(1995). Essas questões são obtidas através do refraseamento dos impactos de cada
símbolo em perguntas iniciadas por quando, onde o que, quem , por que e como.
5..1.1.2
-
Checar se existem indicativos de negação no vocabulário mínimo que
relacionem duas ou mais classes. Verificar se essas classes possuem um relacionamento
do tipo disjunto (exemplo: macho e fêmea).
5.1.1.2.1
–
Se verdadeiro, adi
cionar o
disjoint a lista de axiomas
5.1.1.3
-
Checar se é possível criar uma partição de valor.
5.1.1.3.1
–
Criar uma classe pai para a partição
5.1.1.3.2
-
Fazer com que as classes participantes da partição sejam
disjuntas entre si.
5.1.2
–
Caso o termo seja central a ontologia, classifique
-
o como classe (C).
5.1.3
–
Caso contrario (o temo não é central para a ontologia), classifique
-
o como
propriedade (R).
5.1.4
–
Verificar consistência.
5.
Experimentação
: Controle de Eventos Científicos 149
A seguir vamos elaborar o processo de mapeamento de acordo com o
preconizado na Figura 5.3.
1 – Listar os termos alfabeticamente de acordo com seu tipo (verbo, objeto, sujeito ou
estado)
T
ABELA
5.12
–
T
ERMOS DO
LEL
LISTADOS SEGUNDO O
SEU TIPO
Verbo
Sujeito
Objeto
Estado
alterar participante
cadastrar cliente
cadastrar comissão
cadastrar comitê
cadastrar parceiros
consultar eventos em aberto
consultar eventos fechados
consultar participante
distribuir recursos
efetuar inscrição
efetuar pagamento
elaborar programação
emitir certificados
emitir crachás
enviar material
enviar palestra
enviar requisição
enviar trabalho
excluir
participante
fornecer recursos
pagar fornecedor
receber pagamento
receber recursos
selecionar ministrante
selecionar palestrante,
solicitar inscrição
Apresentador
Cliente
Cliente inscrito
Comissão
Comitê
Fornecedor
Ministrante
Ouvinte
Pal
estrante
Participante
Patrocinador
Secretária
Certificado
Crachá
Evento
Inscrição
Material
Pagamento
Palestra
Programação
Recurso
Trabalho
Aberto
Fechado
2 –
Fazer três listas: Propriedades, classes e axiomas. Na lista de classes cada e
ntrada
terá um nome, descrição (linguagem natural) e uma lista contendo zero ou mais
restrições (função que relaciona a classe em questão a outras, de maneira não
-
taxonômica). As entradas na lista de axiomas terão nomes (labels) somente.
Propriedade
Classe
Axioma
5.
Experimentação
: Controle de Eventos Científicos 150
3 –
Utilizando a lista de símbolos do léxico classificados como
sujeito
ou
objeto
, para
cada termo:
3.1
–
Adicionar uma nova classe a lista de classes. O nome da classe é o símbolo do léxico
propriamente dito. A descrição da classe é a noçã
o do termo.
3.1.1 – para cada impacto,
3.1.1.1 – checar se já não faz parte da lista de propriedades da ontologia
3.1.1.2
-
Caso não faça parte da lista (a propriedade ainda não existe),
adicionar uma nova propriedade na lista (de propriedades). O nome da
propriedade deve ser baseado no verbo utilizado para descrever o
impacto.
3.1.1.2.1 – verificar consistências
3.1.1.3 – Na lista de classes, adicionar uma nova restrição para a classe em
questão. A restrição é formada pela classe + a propriedade (definida
em 3.1.1.1) + a classe relacionada (essa classe é o objeto
direto/indireto do verbo utilizado no impacto do símbolo do léxico.
Usualmente é um termo do próprio léxico e aparece sublinhado)
3.1.1.4 – Checar se existem indicativos de negação no vocabulário m
ínimo que
relacionem duas ou mais classes. Verificar se essas classes possuem
um relacionamento do tipo disjuntos(exemplo: macho e fêmea).
3.1.1.4.1 – Se verdadeiro, adicionar o disjoint a lista de axiomas.
3.2 – Verificar consistência
T
ABELA
5.
13 –
M
APEA
MENTO REALIZADO
Propriedades
é-
enviado
é-
selecionado
é-
apresentado
é-
alterado
é-
consultado
é-
inscrito
é-
elaborado
é-
enviado
é-
emitido
é-
fornecido
é-
pago
é-
solicitado
é-
excluído
é-
distribuído
Axioma
Trabalho pode ser: full, short, poster
Classes
-
Aprese
ntador
Descrição: Cliente inscrito para apresentar trabalho
-
Trabalho
Descrição:
A
A
r
r
t
t
i
i
g
g
o
o
s
s
a
a
s
s
e
e
r
r
e
e
m
m
a
a
p
p
r
r
e
e
s
s
e
e
n
n
t
t
a
a
d
d
o
o
s
s
e
e
m
m
u
u
m
m
e
e
v
v
e
e
n
n
t
t
o
o
-
comitê
Descrição:
G
G
r
r
u
u
p
p
o
o
d
d
e
e
p
p
e
e
s
s
s
s
o
o
a
a
s
s
s
s
e
e
l
l
e
e
c
c
i
i
o
o
n
n
a
a
d
d
a
a
s
s
p
p
a
a
r
r
a
a
s
s
e
e
l
l
e
e
c
c
i
i
o
o
n
n
a
a
r
r
o
o
s
s
t
t
r
r
a
a
b
b
a
a
l
l
h
h
o
o
s
s
a
a
p
p
r
r
e
e
s
s
e
e
n
n
t
t
a
a
d
d
o
o
s
s
n
n
o
o
e
e
v
v
e
e
n
n
t
t
o
o
-
participante:
Descrição:
P
P
e
e
s
s
s
s
o
o
a
a
q
q
u
u
e
e
p
p
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
d
d
e
e
u
u
m
m
e
e
v
v
e
e
n
n
t
t
o
o
c
c
o
o
m
m
o
o
:
:
o
o
u
u
v
v
i
i
n
n
t
t
e
e
,
,
a
a
p
p
r
r
e
e
s
s
e
e
n
n
t
t
a
a
d
d
o
o
r
r
,
,
5.
Experimentação
: Controle de Eventos Científicos 151
p
p
a
a
l
l
e
e
s
s
t
t
r
r
a
a
n
n
t
t
e
e
,
,
m
m
i
i
n
n
i
i
s
s
t
t
r
r
a
a
n
n
t
t
e
e
-
evento:
Descrição:
C
C
o
o
n
n
f
f
e
e
r
r
ê
ê
n
n
c
c
i
i
a
a
o
o
u
u
W
W
o
o
r
r
k
k
s
s
h
h
o
o
p
p
a
a
s
s
e
e
r
r
g
g
e
e
r
r
e
e
n
n
c
c
i
i
a
a
d
d
o
o
p
p
e
e
l
l
a
a
e
e
m
m
p
p
r
r
e
e
s
s
a
a
.
.
C
C
a
a
d
d
a
a
e
e
v
v
e
e
n
n
t
t
o
o
p
p
o
o
s
s
s
s
u
u
i
i
u
u
m
m
p
p
e
e
r
r
í
í
o
o
d
d
o
o
d
d
e
e
r
r
e
e
a
a
l
l
i
i
z
z
a
a
ç
ç
ã
ã
o
o
.
.
-
cliente_inscrito
Descrição:
P
P
e
e
s
s
s
s
o
o
a
a
q
q
u
u
e
e
s
s
o
o
l
l
i
i
c
c
i
i
t
t
o
o
u
u
o
o
c
c
a
a
d
d
a
a
s
s
t
t
r
r
o
o
e
e
f
f
o
o
i
i
a
a
p
p
r
r
o
o
v
v
a
a
d
d
a
a
,
,
r
r
e
e
c
c
e
e
b
b
e
e
n
n
d
d
o
o
o
o
s
s
e
e
u
u
l
l
o
o
g
g
i
i
n
n
e
e
s
s
e
e
n
n
h
h
a
a
-
programação:
Descrição:
C
C
r
r
o
o
n
n
o
o
g
g
r
r
a
a
m
m
a
a
a
a
s
s
e
e
r
r
c
c
u
u
m
m
p
p
r
r
i
i
d
d
o
o
d
d
o
o
e
e
v
v
e
e
n
n
t
t
o
o
C
C
o
o
n
n
t
t
e
e
m
m
a
a
s
s
p
p
a
a
l
l
e
e
s
s
t
t
r
r
a
a
s
s
,
,
t
t
r
r
a
a
b
b
a
a
l
l
h
h
o
o
s
s
e
e
c
c
u
u
r
r
s
s
o
o
s
s
a
a
s
s
e
e
r
r
e
e
m
m
a
a
p
p
r
r
e
e
s
s
e
e
n
n
t
t
a
a
d
d
o
o
s
s
n
n
o
o
e
e
v
v
e
e
n
n
t
t
o
o
-
comissão
Descrição:
G
G
r
r
u
u
p
p
o
o
d
d
e
e
p
p
e
e
s
s
s
s
o
o
a
a
s
s
s
s
e
e
l
l
e
e
c
c
i
i
o
o
n
n
a
a
d
d
a
a
s
s
p
p
a
a
r
r
a
a
g
g
e
e
r
r
e
e
n
n
c
c
i
i
a
a
r
r
o
o
e
e
v
v
e
e
n
n
t
t
o
o
.
.
-
ministrante
Descrição: Cliente inscrito para ministrar curso
-
material
Descrição:
O
O
m
m
a
a
t
t
e
e
r
r
i
i
a
a
l
l
r
r
e
e
f
f
e
e
r
r
e
e
n
n
t
t
e
e
a
a
o
o
c
c
u
u
r
r
s
s
o
o
a
a
s
s
e
e
r
r
m
m
i
i
n
n
i
i
s
s
t
t
r
r
a
a
d
d
o
o
e
e
m
m
u
u
m
m
e
e
v
v
e
e
n
n
t
t
o
o
-
requisição
Descrição:
Documento que contem referencias aos recursos materiais
necessá
rios para realizar a tarefa
-
palestrante
Descrição: Cliente inscrito para ministrar palestra
-
palestra
Descrição:
Slides referentes a um assunto a ser apresentado no evento
-
crachá
Descrição:
I
I
d
d
e
e
n
n
t
t
i
i
f
f
i
i
c
c
a
a
ç
ç
ã
ã
o
o
d
d
o
o
p
p
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
n
n
t
t
e
e
d
d
o
o
e
e
v
v
e
e
n
n
t
t
o
o
-
certificado
Desc
rição:
C
C
o
o
m
m
p
p
r
r
o
o
v
v
a
a
n
n
t
t
e
e
d
d
e
e
p
p
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
ç
ç
ã
ã
o
o
d
d
o
o
e
e
v
v
e
e
n
n
t
t
o
o
-
patrocinador
Descrição:
E
E
m
m
p
p
r
r
e
e
s
s
a
a
q
q
u
u
e
e
f
f
o
o
r
r
n
n
e
e
c
c
e
e
m
m
r
r
e
e
c
c
u
u
r
r
s
s
o
o
s
s
f
f
i
i
n
n
a
a
n
n
c
c
e
e
i
i
r
r
o
o
s
s
p
p
a
a
r
r
a
a
a
a
r
r
e
e
a
a
l
l
i
i
z
z
a
a
ç
ç
ã
ã
o
o
d
d
o
o
e
e
v
v
e
e
n
n
t
t
o
o
-
recursos
Descrição:
São materiais necessários para a realização e elaboração do
evento
.
Podem ser: financeiro, humano e material
-
pagamento
Descrição
Comprovante de quitação com o
evento
-
ouvinte
Descrição: Cliente inscrito para assistir aos cursos, palestras e apresentações do
evento
5.
Experimentação
: Controle de Eventos Científicos 152
-
cliente
Descrição:
P
P
e
e
s
s
s
s
o
o
a
a
q
q
u
u
e
e
a
a
i
i
n
n
d
d
a
a
n
n
ã
ã
o
o
s
s
o
o
l
l
i
i
c
c
i
i
t
t
o
o
u
u
o
o
c
c
a
a
d
d
a
a
s
s
t
t
r
r
o
o
,
,
a
a
p
p
e
e
n
n
a
a
s
s
c
c
l
l
i
i
e
e
n
n
t
t
e
e
e
e
m
m
p
p
o
o
t
t
e
e
n
n
c
c
i
i
a
a
l
l
-
inscrição
Descrição
I
I
d
d
e
e
n
n
t
t
i
i
f
f
i
i
c
c
a
a
ç
ç
ã
ã
o
o
d
d
e
e
u
u
m
m
c
c
l
l
i
i
e
e
n
n
t
t
e
e
q
q
u
u
a
a
n
n
d
d
o
o
d
d
e
e
s
s
e
e
j
j
a
a
f
f
a
a
z
z
e
e
r
r
s
s
e
e
u
u
c
c
a
a
d
d
a
a
s
s
t
t
r
r
o
o
-
secretária
Descrição:
P
P
e
e
s
s
s
s
o
o
a
a
q
q
u
u
e
e
a
a
u
u
x
x
i
i
l
l
i
i
a
a
n
n
o
o
g
g
e
e
r
r
e
e
n
n
c
c
i
i
a
a
m
m
e
e
n
n
t
t
o
o
d
d
o
o
e
e
v
v
e
e
n
n
t
t
o
o
-
fornecedor
Descrição:
E
E
m
m
p
p
r
r
e
e
s
s
a
a
q
q
u
u
e
e
f
f
o
o
r
r
n
n
e
e
c
c
e
e
r
r
e
e
c
c
u
u
r
r
s
s
o
o
s
s
(
(
m
m
a
a
t
t
e
e
r
r
i
i
a
a
i
i
s
s
o
o
u
u
h
h
u
u
m
m
a
a
n
n
o
o
s
s
)
)
p
p
a
a
r
r
a
a
a
a
r
r
e
e
a
a
l
l
i
i
z
z
a
a
ç
ç
ã
ã
o
o
d
d
o
o
e
e
v
v
e
e
n
n
t
t
o
o
4 – Utilizando a lista de símbolos classificados como tipo verbo, para cada termo:
4.1.1 – Checar se já faz parte da lista de propriedades da ontologia.
4.1.1.1 – Caso não faça parte da lista (a propriedade não existe), adicionar u
ma
nova propriedade a lista (de propriedades). O nome da propriedade é o
símbolo do léxico propriamente dito.
4.1.1.1.1
-
Verificar consistência
Todos os verbos foram mapeados.
5 – Utilizando a lista de símbolos classificados como tipo estado, para cada
termo:
5.1.1 – Para cada impacto.
5.1.1.1 – Tentar identificar a importância relativa do termo para a ontologia.
Essa estratégia é similar a utilização de questões de competência
proposta por Gruninger. Essas questões são obtidas através do
refraseamento dos impactos de cada símbolo em perguntas iniciadas
por quando, onde o que, quem , por que e como.
5..1.1.2
-
Checar se existem indicativos de negação no vocabulário mínimo que
relacionem duas ou mais classes. Verificar se essas classes possuem
um relacion
amento do tipo disjunto (exemplo: macho e fêmea).
5.1.1.2.1 – Se verdadeiro, adicionar o disjoint a lista de axiomas
5.1.1.3
-
Checar se é possível criar uma partição de valor.
5.1.1.3.1 – Criar uma classe pai para a partição
5.1.1.3.2
-
Fazer com que as classes participantes da partição sejam
disjuntas entre si.
5.1.2 – Caso o termo seja central a ontologia, classifique
-
o como classe (C).
5.1.3 – Caso contrario (o temo não é central para a ontologia), classifique
-
o como
propriedade (R).
5.1.4 –
Verificar
consistência.
Seguindo
os passos acima criamos duas novas classes referentes ao estado de
aberto e fechado, com restrição de disjunção entre elas.
5.
Experimentação
: Controle de Eventos Científicos 153
Foi
criada uma classe de partição de valor chamada: tipo_evento, onde possui
referencia as outras classes de aberto e fechado.
Assim, ficou conforme demonstra a figura 5.4.
F
IGURA
5.4
–
MAPEAMENTO DOS SÍMBOLOS
DO TIPO
ESTADO
A última etapa do processo de construção de ontologias é a construção de uma
hierarquia de classes, onde identificamos conceitos que possa
m estar relacionados
hierarquicamente.
No topo da ontologia fica o termo mais genérico, e nas suas folhas os mais
específicos.
Assim, baseado nesta premissa, faremos os seguintes passos:
6 – Quando todos os termos tiverem sido adicionados a ontologia
6.1 – Checar se existem conjuntos de classes que podem compartilhar restrições
idênticas ou muito similares.
6.1.1 – para cada conjunto de classes idenfificado, construir uma lista de classes
separada.
6.1.2 – buscar na ontologia outras classes que façam referencia a todos os
membros desta lista
6.1.3 – construir uma hierarquia de classes em que todos os membros da lista de
classes sejam uma subclasse da classe encontrada em 6.1.2
6.1.4 – verificar consistência.
Foram identificadas as seguintes listas:
Classes
Aberto
Definição: são os eventos que possuem o período de realização maior ou igual
do que a data atual
subClasseOf: tipo
-
evento
Fechado
Definição:são os eventos que possuem o período de realização menor do que a
data atual
subClasseOf: tipo
-
evento
Tipo
-
Evento
Definição: conjunto dos estados possíveis em que o evento pode estar no
momento.Partição de valor.
5.
Experimentação
: Controle de Eventos Científicos 154
F
IGURA
5.5
–
E
STRUTURA HIERÁRQUICA
DA ONTOLOGIA
E
VENTOS
5
5
.
.
8
8
G
G
e
e
r
r
a
a
ç
ç
ã
ã
o
o
d
d
e
e
A
A
r
r
q
q
u
u
i
i
v
v
o
o
s
s
p
p
a
a
r
r
a
a
E
E
x
x
p
p
o
o
r
r
t
t
a
a
ç
ç
ã
ã
o
o
Atualmente busca
-
se de um modo geral
uma interoperabilidade entre
ferramentas de desenvolvimento que nem sempre é possível
de se
obter.
A exportação de documentos no padrão XML permite que se obtenha esta
interoperabilidade, mesmo que de forma simples, porém eficiente. Uma vez que tenhamos
o documento XML gerado e o padrão a ser obedecido por ele (seja através de uma DTD
ou de um
XML
Schem
a) podemos garantir a padronização e a leitura do mesmo.
Assim, através do padrão estabelecido no Capitulo 4
através
dos
XML
Schemas, fo
ram
gerado
s
documentos prontos para exportação.
Parceiros
-
fornecedor
-
patrocidador
Cliente
-
cliente inscrito
-
cliente
-
participante (ouvinte, palestrante, apresentador, ministrante)
Recursos
-
materiais ou humanos
-
financeiros
Material_evento
-
palestra
-
curso
-
apr
esentação
-
requisição
Grupo_trabalho
-
secretária
-
comitê
-
comissão
Objetos_evento
-
crachá
-
certificado
-
programação
5.
Experimentação
: Controle de Eventos Científicos 155
Estes documentos na sua
í
ntegra estão no Anexo
C
, por
é
m segue
m
alguns
tr
echos do mesmo:
Figura 5.6
– Trecho do Arquivo do LEL dos Símbolos em
XML
Figura 5.7
– Trecho do Arquivo do LEL dos Cenários em XML
...
<
Projeto
>
<
id_projeto
>1
<do
minio
>
comunicação
<nome_projeto
>
Eventos
<descricao>Controle de Eventos Científicos
<
LEL
>
<
id_simbolo
>1
</
id_simbolo
>
<
nome_simbolo
>
fechado
<
/
nome_simbolo>
<
categoria
>
esta
do<
/
categoria
>
<
sinonimos
>
<
alias
>
fechados
<
/
alias
>
....
...
<
Projeto
>
<
id_projeto
>1
<do
minio
>
comunicação
<nome_projeto
>
Eventos
<descricao>Controle de Eventos Científicos
<
cenarios
>
<
Tipo_mdsodi
> paralelo
</
Tipo_mdsodi">
<cenarioid>1
</
cenarioid
>
<
titulo
>distribuir recursos</
titulo
>
<objetivo>distribuir recursos humanos, financeiros e materiai
s para o
evento</
objetivo
>
...
5.
Experimentação
: Controle de Eventos Científicos 156
Figura 5.
8 – Trecho do Arquivo de Aspectos XML
Figura 5.
9 – Trecho do Arquivo de Ontologias XML
...
<Aspectos>
<
nome
>
validar situação</
nome
>
<
origem
>
RO
<
/
origem>
<
descricao
>
validar situação do cliente inscrito<
/
escricao>
...
...
<
ontologias
>
<
classe
>
<
nome
>comitê</n
ome
>
<descricao>Grupo de pessoas que avaliam os trabalhos para apresentação
no evento
</de
scricao
>
<
restricao
><
/
restricao>
...
5.
Experimentação
: Controle de Eventos Científicos 157
5
5
.
.
9
9
R
R
e
e
s
s
u
u
m
m
o
o
d
d
o
o
C
C
a
a
p
p
í
í
t
t
u
u
l
l
o
o
Neste capítulo realizamos o estudo de caso referente
à
abordagem proposta.
Ficou claro, a partir da análise efetuada, que a abordagem DAORE permite um tratamento
diferenciado para os requisitos funcionais, não
funcionais e organizacionais. Além de
incorporar a identificação dos aspectos candidatos (ponto chave em
Early
Aspects
).
A identificação dos aspectos candidatos facilita o trabalho do engenheiro de
requisitos, pois ele precisaria apenas refinar estes aspe
ctos aceitando
-
os ou rejeitando
-
os
de acordo com suas prioridades.
Um outro ponto bem interessante é a exportação do arquivo em XML baseado
no Schema XML do LEL, ontologias e casos de uso
e aspectos
. Esta especificação
permite a interoperabilidade entre
ferramentas, pois o desenvolvedor pode ter a
flexibilidade de escolha da ferramenta mais apropriada ao seu uso. Em um ambiente
distribuído de desenvolvimento, esta flexibilidade é fundamental, pois a equipe de
desenvolvimento não está presa a uma ferrament
a padrão.
A autora acredita que a geração de um arquivo XML dos casos de uso seguindo
a MDSODI é um facilitador pois mesmo que não possa construir graficamente este recurso
permite a definição dos principais cenários do sistema e de seus atores seguindo a
metodologia MDSODI. Sendo um recurso poderoso e aliado na especificação do domínio
do sistema.
A
ssim, a abordagem DAORE provou que além de facilitar a identificação dos
aspectos candidatos, permite que sejam definidos parâmetros fundamentais para que se
possa atingir a próxima etapa do desenvolvimento, com a elaboração dos casos de uso.
6. A Ferramenta Requisite e a Abordagem DAORE 158
C
APÍTULO
6
6
A
F
ERRAMENTA
R
EQUISITE E A
A
BORDAGEM
DAORE
Termos consciência de que somos ignorantes é um grande passo rumo ao saber.
Disraeli
E
E
s
s
t
t
e
e
c
c
a
a
p
p
í
í
t
t
u
u
l
l
o
o
a
a
p
p
r
r
e
e
s
s
e
e
n
n
t
t
a
a
u
u
m
m
a
a
a
a
n
n
á
á
l
l
i
i
s
s
e
e
d
d
a
a
f
f
e
e
r
r
r
r
a
a
m
m
e
e
n
n
t
t
a
a
R
R
e
e
q
q
u
u
i
i
s
s
i
i
t
t
e
e
e
e
m
m
s
s
u
u
a
a
p
p
r
r
i
i
m
m
e
e
i
i
r
r
a
a
v
v
e
e
r
r
s
s
ã
ã
o
o
e
e
a
a
v
v
e
e
r
r
s
s
ã
ã
o
o
a
a
t
t
u
u
a
a
l
l
,
,
b
b
a
a
s
s
e
e
a
a
d
d
a
a
n
n
a
a
e
e
x
x
p
p
e
e
r
r
i
i
m
m
e
e
n
n
t
t
a
a
ç
ç
ã
ã
o
o
e
e
f
f
e
e
t
t
u
u
a
a
d
d
a
a
.
.
É
É
r
r
e
e
a
a
l
l
i
i
z
z
a
a
d
d
o
o
u
u
m
m
a
a
a
a
n
n
á
á
l
l
i
i
s
s
e
e
d
d
o
o
i
i
m
m
p
p
a
a
c
c
t
t
o
o
q
q
u
u
e
e
e
e
s
s
s
s
a
a
m
m
u
u
d
d
a
a
n
n
ç
ç
a
a
i
i
r
r
á
á
p
p
r
r
o
o
v
v
o
o
c
c
a
a
r
r
n
n
o
o
p
p
r
r
o
o
j
j
e
e
t
t
o
o
D
D
i
i
S
S
E
E
N
N
,
,
s
s
e
e
u
u
s
s
p
p
r
r
o
o
s
s
e
e
c
c
o
o
n
n
t
t
r
r
a
a
s
s
.
.
P
P
o
o
r
r
f
f
i
i
m
m
,
,
a
a
v
v
a
a
l
l
i
i
a
a
m
m
o
o
s
s
s
s
e
e
a
a
s
s
m
m
u
u
d
d
a
a
n
n
ç
ç
a
a
s
s
s
s
ã
ã
o
o
n
n
e
e
c
c
e
e
s
s
s
s
á
á
r
r
i
i
a
a
s
s
p
p
a
a
r
r
a
a
o
o
f
f
u
u
t
t
u
u
r
r
o
o
d
d
o
o
p
p
r
r
o
o
j
j
e
e
t
t
o
o
D
D
i
i
S
S
E
E
N
N
.
.
6
6
.
.
1
1
S
S
i
i
t
t
u
u
a
a
ç
ç
ã
ã
o
o
A
A
t
t
u
u
a
a
l
l
A ferramenta Requisi
te desenvolvida em Java no aplicativo NetBeans, possui
algumas limitações
referentes a orientação a aspectos, mesmo porque, na sua concepção
não havia referencia na literatura sobre o assunto.
Foi desenvolvida usando a orientação a objetos e, como já foi v
isto no capítulo
2, a orientação a objetos não contempla de forma eficiente a identificação e composição
das propriedades transversais de um projeto de software.
Deste modo,
algumas mudanças s
ão necessárias
para que se pudesse
dispor de
algumas facilidades
e contribuições da abordagem
DAORE
, como
:
ontologias, definições
dos requisitos não funcionais e suas operacionalizações,
definição dos
requisitos
organizacionais, importação através de um padrão pré
-
definido destes dados e,
6. A Ferramenta Requisite e a Abordagem DAORE 159
principalmente, a identificaçã
o dos aspectos
candidatos em um projeto a ser desenvolvido
no ambiente DiSEN.
As mudanças seriam bastante significativas justificando, inclusive, em uma
nova versão, como no caso da alteração efetuada na ferramenta OORNF.
O trabalho de Wiese (2006) aborda
a questão de interoperabilidade entre as
ferramentas de desenvolvimento, realizando um trabalho de transformação do modelo de
casos de uso, entre as ferramentas:
Poseidon
1
, Enterprise Architect
2
e a
Requisite
. Seu
trabalho não seria alterado, uma vez que n
ão estamos tratando dos casos de uso, mas sim
dos símbolos do LEL, seus cenários e aspectos relacionados.
A seguir veremos como está a ferramenta
R
equisite após a alteração efetuada
por Wiese (2006) e ainda sem as alterações de acordo com a DAORE.
6.1.1 – O Menu Principal da Requisite
Seu Menu Principal apresenta as opções verificadas na figura
6
.1 e na Opção
File podemos observar que possui um sub
-
menu, que oferece as opções de:
·
New
–
Especifica um novo projeto, por isso, talvez a opção possa ser
renomeada
para Project, ao invés de File.
·
Open Recent
–
especifica os projetos recentes que foram abertos. Esta
opção não pode ser verificada pois não está operacional.
·
Open
–
esta opção só funciona se o usuário abrir um novo projeto,
fecha
-
lo e logo depois tentar
abrir, sem fechar a ferramenta, senão ela
não consegue abrir o projeto.
·
Save
– salva um projeto aberto que já foi salvo.
·
Save as
–
salvar como, para um projeto aberto
esta opção permite a
escolha do nome do projeto e a pasta de localização.
·
Open from DiSEN
–
busca um arquivo .XMI
–
não pode ser testado,
uma vez que não possuía um arquivo XMI do projeto DiSEN (foco do
trabalho de Wiese).
1
Dispon
ível para download em:
http://www.gentleware.com/
.
2
Disponível para download em:
http://www.sparxsystems.com/
6. A Ferramenta Requisite e a Abordagem DAORE 160
·
Save to DiSEN
– salva um arquivo no formato .XMI. Ele cria o arquivo
especificado, porém não pode ser testado (foco do trabalho de Wiese).
·
Close
– Fecha o projeto aberto.
·
Exit
–
Sair da ferramenta.
F
IGURA
6.1
–
M
ENU
P
RINCIPAL DA FERRAMEN
TA
R
EQUISITE
.
As opções
Edit
, Diagrams
e
Windows
, não estão operacionais
sem instanciação
de projeto ou a criação de um novo
. A opção
Help
oferece apenas uma tela sobre
informações gerais do sistema.
Os botões localizados no lado esquerdo e acima são botões rápidos para acessar
determinadas tarefas,
o
s botões
e
permitem que se selecionados,
ao incluirmos
uma associação entre os casos de
uso, estas serão identificadas com o estereotipo
<<
exclusive
>> ou <<
include>>.
A figura 6.2 apresenta o NetBeans
3
e a ferramenta Requisite e seu código a ser
analisado.
3
Disponível em:
http://www.netbeans.org/
. Último acesso em: 22/11/06.
6. A Ferramenta Requisite e a Abordagem DAORE 161
F
IGURA
6.2
–
N
ET
B
EANS E A FERRAMENTA
R
EQUISITE
.
6
6
.
.
2
2
I
I
m
m
p
p
l
l
e
e
m
m
e
e
n
n
t
t
a
a
n
n
d
d
o
o
a
a
D
D
A
A
O
O
R
R
E
E
Cada vez
mais os projetos desenvolvidos requisitam um maior uso de recursos
e até mesmo novas técnicas que permitam que acompanhem e usem a evolução natural da
tecnologia.
Isto se aplica também aos processos de desenvolvimento. Deste modo,
podemos prever que a incl
usão de aspectos candidatos nos projetos desenvolvidos no
ambiente DiSEN
permitem acrescentar novas características que podem ser tratadas desde
o inicio do desenvolvimento.
Assim, podemos afirmar que futuros projetos se beneficiarão com a
implantação das características providas pela
DAORE
.
6
6
.
.
2
2
.
.
1
1
–
–
P
P
r
r
o
o
j
j
e
e
t
t
o
o
D
D
i
i
S
S
E
E
N
N
O projeto
DiSEN
possui como objetivo principal prover um ambiente de
desenvolvimento de software distribuído. Isto implica no uso integrado de várias
ferramentas de desenvolvimento, sejam elas na forma de plugins ou
stand
-
alone
.
Assim,
a exportação de dados, sejam eles no formato XML ou através de
transformações de modelos, como no trabalho de Wiese (2006) para casos de uso, devem
existir no projeto.
Este uso se explica pelo fato de que nem sempr
e há a possibilidade de todos
utilizarem a mesma ferramenta para a mesma fase, mesmo porque,
deve existir uma
customização ou adaptação para as ferramentas utilizadas pela equipe de desenvolvimento.
6. A Ferramenta Requisite e a Abordagem DAORE 162
Deste modo, o projeto
DiSEN
pode ser beneficiado com a im
plementação na
fase de requisitos de uma abordagem que permita e padronize os documentos a serem
gerados
, além de possibilitar a identificação dos aspectos candidatos do projeto.
6
6
.
.
2
2
.
.
2
2
–
–
A
A
N
N
o
o
v
v
a
a
F
F
e
e
r
r
r
r
a
a
m
m
e
e
n
n
t
t
a
a
R
R
e
e
q
q
u
u
i
i
s
s
i
i
t
t
e
e
A modelagem dos diagramas referentes
à
n
ova versão da Requisite foram
elaborados
utilizando o
Borland Together Architect
4
.
Inicialmente, modelamos o diagrama de casos de uso, figuras 6.3 e 6.4.
F
IGURA
6
.3
–
B
ORLAND
T
OGETHER
A
RCHITECT E A
R
EQUISITE
4
Disponível em:
http://www.borland.com/br/products/together/index.html
. Ultimo acesso em: 22/11/06.
6.
A Ferramenta Requisite e a Abordagem DAORE 163
Exportar XML
Construir hierarquia
Construir use case
Gerar Ontologias
gerar cenarios
Gerar Aspectos
Construir Cenarios
Engenheiro de Requisitos
Cosntruir RO
Gerar ator
Gerar recursos
Construir RNF
Criar Projeto
Construir Lexico
<<include>>
<<include>>
<<include>>
<<extend>>
F
IGURA
6.
4 –
D
IAGRAMA DE
C
ASOS DE
U
SO DA
N
OVA
R
EQUISITE
Observando a figura 6.4 podemos concluir que a nova versão da ferramenta
Requisite possui algumas funcionalidades que não existiam na versão anterior (para uma
comparação entre os casos de uso, verifique o capítulo 2, onde está detalhada a f
erramenta
requisite). Estas funcionalidades, previstas na abordagem
DAORE
permitem que a
ferramenta construa requisitos não funcionais, requisitos organizacionais, gere os
elementos dos cenários a partir dos símbolos do LEL, gere aspectos e construa a ontologia
do projeto.
Assim, podemos verificar que além das funcionalidades já existentes na versão
anterior teremos:
a)
Construir RNF
–
permite que se crie, modifique, consulte e remova os
requisitos não funcionais primários e secundários, bem como as suas es
tratégias de
satisfação;
b) C
onstruir RO
–
permite que se crie, modifique, consulte e remova os
requisitos organizacionais ligados ao projeto;
c)
Exportar XML
–
permite que se exporte documentos no formato XML a
partir dos XML Schemas definidos pela DAORE
para símbolos do LEL, cenários,
ontologias e aspectos candidatos;
6. A Ferramenta Requisite e a Abordagem DAORE 164
d)
Gerar Aspectos
–
permite que se possa gerar e atualizar os aspectos
candidatos do projeto a partir dos RNF definidos e das diretrizes propostas;
e) Gerar ontologias
–
permite que se possa
criar e atualizar as ontologias a
partir dos símbolos do LEL definidos para o projeto; e
f) Construir hierarquia
–
permite que se possa criar e atualizar as hierarquias
para as classes de ontologias definidas para o projeto.
A partir do diagrama de casos
de uso da ferramenta Requisite elaboramos o
diagrama de classes de acordo com a figura 6.5.
6. A Ferramenta Requisite e a Abordagem DAORE 165
F
IGURA
6.
5
–
D
IAGRAMA DE
C
LASSES
P
ROPOSTO DA NOVA VERSÃO DA
R
EQUISITE
6.
A Ferramenta Requisite e a Abordagem DAORE 166
O diagrama de classes apresentado na figura 6.5 apresenta as seguintes
características adicionais:
·
Identificação do símbolo do LEL, como
subject, verb, object
ou
state
;
·
Associação do
Behavioral Response
com requisitos não funcionais,
funcionais e organizacionais, além de poder ser introduzido
instruções OCL;
·
Associação dos cenários ao símbolo do
LEL identificado como
verbo;
·
Associação dos símbolos do LEL com os termos da ontologia;
·
Geração de aspectos candidatos automaticamente a partir dos RNF
incluídos no projeto através do Behavioral Response
; e
·
Exportação de arquivos no padrão
XML
através de
X
ML Schemas
definidos.
Deste modo, algumas mudanças nas interfaces foram efetuadas
na ferramenta
Requisite para que possa se adequar a
DAORE
.
Primeiramente na figura
6.6
apresentamos
uma tela inicial que é a entrada do
Requisite, sendo necessário digitar a senha de acesso ao sistema.
F
IGURA
6.
6 –
N
OVA
T
ELA DE
A
CESSO AO
R
EQUISITE
.
O Menu Principal foi alterado de forma a exibir opções abordadas na
abordagem DAORE
, como podemos observar na figura 6.7.
6. A Ferramenta Requisite e a Abordagem DAORE 167
F
IGURA
6.
7 –
N
OVO
M
ENU
P
RINCIPAL DA
F
ERRAMENTA
R
EQUISI
TE
.
Podemos observar que a figura 6.
7
apresenta como opções principais:
Project
,
LEL,
Restrictions, Use Case, Ontology e Help. A opção Project é o antigo File e apresenta
o sub
-
Menu da figura 6.8
F
IGURA
6.
8 – S
UB
-
M
ENU DE
P
ROJECT
.
6. A Ferramenta Requisite e a Abordagem DAORE 168
A
gora, como estamos nos conectando com o banco
POSTGRESQL
,
algumas
opç
ões
foram excluídas, para a incorporação de outras. Assim, a opção
project
passou a
ter
:
·
NEW
–
onde podemos
criar novos projetos, atualiza
-
los e selecionar o projeto que
desejamos trabalhar. Apresenta a
interfa
ce
da figura 6.9
;
F
IGURA
6.
9 –
NEW
-
P
ROJECT
.
Como podemos observar na figura 6.
9
, aparece um
hint
no campo Project ID,
indicando a ação que deve ser realizada. A intenção é de que tenhamos um pequeno help
de ajuda ao usuário. Assim, como neste campo, to
dos os campos inseridos tem essa
característica, bem como os botões inseridos.
·
XML FILES
-
onde podemos gerar o arquivo XML de acordo com os XML Schemas
criados para o LEL, Cenários, Aspectos e Ontologias;
·
Aspects –
Permite que se gere os aspectos, atualize
e gere os conflitos do projeto
selecionado;
·
Exit
–
Sair da ferramenta.
A opção do
M
enu
P
rincipal
LEL
,
apresenta as opções de acordo com a figura
6.10.
6. A Ferramenta Requisite e a Abordagem DAORE 169
F
IGURA
6.
10
– S
UB
-
M
ENU DA OPÇÃO
LEL
Uma das maiores mudanças efetuadas na ferramenta diz respeito a te
la
principal do
LEL
(a opção do sub
-
menu
New
/
Update
). Agora, podemos inserir a
característica principal do léxico, ou seja, qual é o seu tipo. A partir daí podemos realizar
uma série de procedimentos através da ferramenta de forma automática, como: geração
de
atores, recursos e cenários, o que facilita o processo de construção do
LEL
.
Esta tela está de acordo com a interface da figura 6.11.
6. A Ferramenta Requisite e a Abordagem DAORE 170
F
IGURA
6.
11
–
NEW/U
PDATE
LEL
Assim, em cenários poderíamos ter especificado o tipo MDSODI
, conforme na
ferramenta
CALEL
.
No Menu principal
Restrictions
podemos editar os RNF e RO
. Estes seriam
inseridos em cenários, conforme a
CALEL
.
No Menu Principal Use Case seria incluído as opções do Wiese (de importação
e exportação do modelo XMI) e a elaboração dos diagramas de
casos de uso, de acordo
com a figura 6.12.
6. A Ferramenta Requisite e a Abordagem DAORE 171
F
IGURA
6.
12
–
S
UB
-
M
ENU
U
SE
C
ASE
Na seqüência,
há
a geração de ontologias conforme foi elaborado com a
CALEL
.
As alterações efetuadas foram realizadas utilizando o
NetBeans
, conforme a
versão alterada por Wie
se. A
escolha do POSTGRESQL
como banco de dados para a
persistência está de acordo com o que está sendo feito no projeto
DISEN
.
6
6
.
.
2
2
.
.
3
3
–
–
A
A
n
n
á
á
l
l
i
i
s
s
e
e
d
d
o
o
I
I
m
m
p
p
a
a
c
c
t
t
o
o
d
d
a
a
s
s
M
M
u
u
d
d
a
a
n
n
ç
ç
a
a
s
s
As mudanças sugeridas na ferramenta
Requisite
permitem que a abordagem
DAORE
seja incl
uída no seu processo sem afetar o trabalho que já estava sendo realizado.
Na verdade
, houve um acréscimo de informações a serem adicionadas.
Estas informações dizem respeito
às
funcionalidades do projeto a ser
desenvolvido, logo,
adicionam
uma maior clare
za na definição dos requisitos a serem
mapeados.
6. A Ferramenta Requisite e a Abordagem DAORE 172
Porém, precisa
-
se
analisar o impacto de uma mudança efetuada na ferramenta
Requisite e no projeto
DiSEN
a fim de
se
avaliar se a mudança
não será uma quebra de
paradigma.
Para isso precisamos identificar po
ntos a serem analisados e comparados com
as diferentes versões da Requisite, a anterior e a atual. Deste modo, a
fim de definir
parâmetros de comparação para avaliar as duas ferramentas, iremos utilizar a
NBR 13596
-
Tecnologia de Informação: Avaliação de Produto de Software
(
ISO 9126)
e utilizada no
capítulo
2 para realizar a comparação entre as abordagens de desenvolvimento.
Ao levarmos em conta o Requisite na sua versão original e o novo requisite,
podemos mapear uma tabela baseado no estudo de caso real
izado entre ambas, este
mapeamento está descrito na tabela 6.1.
T
ABELA
6.
1 –
M
APEAMENTO ENTRE AS V
ERSÕES D
A
R
EQUISITE
Característica
Sub
-
caracter
í
stica
Requisite Original
Novo Requisite
Adequação
-
Faltava
persist
ê
ncia
-
Identificação dos
RNF e RO
Atendida
Acurácia
Faltava
identificação dos
termos do LEL
Atendida
Interoperabilidade
A partir do trabalho
de Wiese (2006)
possui exportação e
importação de
arquivos XMI
para
casos de uso
Foi acrescida de
exportação de
arquivos XML
seguindo
um padrão
definido no XML
Schema
Conformidade
Faltava identificar
os símbolos do LEL
De acordo com as
especificações de
Leite (1997) para o
LEL
FUNCIONALIDADE
Segurança de
acesso
Não implementado
Através de
identificação por
senha
Maturidade
Não apli
cável
Tolerância a
falhas
CONFIABILIDADE
Recuperabilidade
Não implementado
Aplicado no banco
de dados definido
Inteligibilidade
Apreensibilidade
USABILIDADE
Operacionalidade
Dificultada pela
ausência de help
Help de auxilio
disponível
(
hint
)
EFICIÊNCIA
C
omportamento
em relação ao
Bom tempo de
resposta entre as
Bom tempo de
resposta entre as
6. A Ferramenta Requisite e a Abordagem DAORE 173
tempo
Comportamento
em relação aos
recursos
operações e
recursos utilizados
operações e
recursos utilizados
(Banco de dados)
Continuação da Tabela 6.1
Caracterís
tica
Sub
-
característica
Requisite Original
Novo Requisite
Adaptabilidade
Capacidade para
ser instalado
Desenvolvido em
Java
Desenvolvido em
Java
Capacidade para
substituir
imediata
imediata
PORTABILIDADE
Analisabilidade
circularidade
circularida
de
Modificabilidade
Java
Java
MANUTENIBILIDADE
Estabilidade
Não possui BD
Através de
mecanismos de BD
Ao observarmos a tabela 6.
1
podemos verificar que
a
maturidade
não
é
aplicada
n
a an
á
lise, pois este item deve ser levado em conta quando do uso const
ante em
diversos
projetos
, com algum tempo de uso da ferramenta.
Algumas considerações são necessárias para as características e analise
efetuada na tabela 6.1:
·
Adequação
–
em sua primeira versão a ferramenta Requisite não trata
dos requisitos não funciona
is e organizacionais, sendo assim, deixa de
considerar aspectos importantes no projeto a ser desenvolvido
,
além
disso, a persistência não está sendo feita de forma adequada, conforme
foi visto no inicio deste capítulo.
Com a modificação proposta, a nova
ve
rsão do Requisite irá suportar os RNF e organizacionais, além de
possuir integração com um banco de dados.
·
Acurácia
–
A versão inicial da Requisite não faz identificação dos
termos definidos no LEL, dificultando a geração automática de alguns
elementos usa
dos na especificação de cenários, como os atores e
recursos, al
é
m da própria identificação do cenário. Deste modo, a
geração de resultados satisfatórios ou corretos em relação aos termos do
LEL está comprometida.
·
Interoperabilidade –
com o trabalho de Wiese (2006) podemos exportar
e importar documentos XMI do projeto
, porém apenas em relação aos
casos de uso especificados
.
Com a mudança proposta, a ferramenta
6. A Ferramenta Requisite e a Abordagem DAORE 174
Requisite passaria a incluir a exportação de documentos XML em
padrões especificados através de
XML
Schema
do LEL, cenários,
aspectos e ontologias.
·
Conformidade – a ferramenta Requisite identifica os termos do LEL e a
partir destes, deveria facilitar a identificação e descrição dos cenários,
conforme previsto por Leite (1997). Porém, como não há a
ident
ificação dos termos do LEL (o seu tipo) não podemos gerar de
forma automática os atores, recursos e os próprios cenários.
Assim,
inicialmente não está de acordo com o que se prevê no LEL.
Com a
mudança proposta, a identificação dos termos do LEL é o primei
ro
passo para a geração automática dos cenários.
·
Segurança de Acesso
–
Inicialmente a ferramenta Requisite está
implementada de forma não integrada ao ambiente DiSEN e sendo
assim precisa ter restrições de uso quanto ao projeto e usuários
qualificados. A n
ova versão da Requisite deve ser capaz de gerenciar e
tratar acessos indevidos, podendo ser através de senha de acesso.
·
Tolerância a falhas
e Recuperabilidade
–
geralmente este item está
ligado ao tratamento em relação aos seus dados, por
é
m na primeira
ver
são da
R
equisite não há
persistência e, deste modo, não existe
tratamento de
rollback
. A nova versão da Requisite deve possuir
tratamento com banco de dados, e o próprio mecanismo prevê
tratamentos de
backup
e
recover dos mesmos
(dependendo da versão do
banco de dados).
·
Inteligibilidade, apreensibilidade e operacionalidade –
a ausência de
help on line para determinadas tarefas é um ponto crucial para uma
aprendizagem mais rápida, al
é
m de facilitar a operacionalidade e
inteligibilidade de uma ferramenta. Em sua primeira versão, a Requisite
não possui
help online
, sendo mais uma característica a ser acrescentada
na nova versão.
·
Comportamento em relação ao tempo e aos recursos
–
de um modo
geral a ferramenta
,
na primeira versão
,
apresenta um bom tempo de
6.
A Ferramenta Requisite e a Abordagem DAORE 175
respo
sta, sendo igualmente um fator a ser passado para a próxima
versão.
·
Adaptabilidade e capacidade para ser instalada
–
desenvolvida em
Java, pode ser instalada no Windows ou Linux, não possuindo
restrições.
·
Capacidade para substituir
–
Utilizando o LEL para
auxiliar a definir
os cenários podemos substituir de forma imediata outra qualquer. Tanto
na versão anterior quanto na proposta, devemos manter os conceitos
básicos do LEL, a fim de possibilitar uma transição não traumática
entre ferramentas de desenvolvim
ento.
·
Analisabilidade – a analisabilidade do projeto pode ser feita através dos
seus termos pelo princ
í
pio da circularidade.
·
Modificabilidade –
as duas versões podem ser alteradas utilizando
padrão java, por
é
m sem termos um impacto maior no projeto DiSEN.
·
Estabilidade
–
a primeira versão da ferramenta não possui
implementação em banco de dados
e
portanto,
não possui
a estabilidade
que um banco de dados pode oferecer. A nova versão possui integração
com um banco de dados, oferecendo uma estabilidade maior de
suas
i
nformações.
O impacto no projeto
DiSEN
seria principalmente no que diz respeito a
identificação dos aspectos candidatos do projeto a ser desenvolvido. Pois estes aspectos
irão influir nos passos definidos nos cenários.
6. A Ferramenta Requisite e a Abordagem DAORE 176
6
6
.
.
3
3
R
R
e
e
s
s
u
u
m
m
o
o
d
d
o
o
C
C
a
a
p
p
í
í
t
t
u
u
l
l
o
o
Ne
ste capítulo
procurou
-
se
identificar as principais mudanças a serem
elaboradas na ferramenta Requisite para que integrasse a abordagem
DAORE
e o impacto
destas mudanças no projeto
DiSEN
.
A preocupação maior foi de que o impacto fosse o menor possível, uma
vez
que se refletiria no projeto DiSEN como um todo. Assim, foi verificado que as inclusões
necessárias para a
execução
das mudanças não afet
ou
de forma desastrosa, pois a própria
ferramenta Requisite funciona ainda como uma ferramenta
stand
-
alone
em relaç
ão ao
projeto DiSEN, sendo um projeto futuro a implementação
da mesma como
um
plug
-
in
(WIESE, 2006).
Assim, a possibilidade de gerar aspectos candidatos através do LEL do projeto
é altamente viável a partir das mudanças propostas.
Com isso, as próximas fas
es do processo de desenvolvimento podem usufruir
das facilidades oferecidas pela aplicação direta dos aspectos
candidatos
já elicitados
,
podendo inclusive ser alvo de futuros estudos a extensão da abordagem para as outras
fases do desenvolvimento.
7.
Con
c
lusão 177
C
APÍTULO
7
7
CONCLUSÃO
Termos consciência de que somos ignorantes é um grande passo rumo ao saber.
Disraeli
E
E
s
s
t
t
e
e
c
c
a
a
p
p
í
í
t
t
u
u
l
l
o
o
a
a
p
p
r
r
e
e
s
s
e
e
n
n
t
t
a
a
d
d
e
e
m
m
a
a
n
n
e
e
i
i
r
r
a
a
s
s
i
i
n
n
t
t
é
é
t
t
i
i
c
c
a
a
a
a
s
s
c
c
o
o
n
n
t
t
r
r
i
i
b
b
u
u
i
i
ç
ç
õ
õ
e
e
s
s
d
d
a
a
n
n
o
o
s
s
s
s
a
a
a
a
b
b
o
o
r
r
d
d
a
a
g
g
e
e
m
m
.
.
D
D
e
e
p
p
o
o
i
i
s
s
,
,
s
s
u
u
g
g
e
e
r
r
i
i
m
m
o
o
s
s
a
a
l
l
g
g
u
u
n
n
s
s
t
t
ó
ó
p
p
i
i
c
c
o
o
s
s
p
p
a
a
r
r
a
a
t
t
r
r
a
a
b
b
a
a
l
l
h
h
o
o
s
s
f
f
u
u
t
t
u
u
r
r
o
o
s
s
,
,
b
b
a
a
s
s
e
e
a
a
n
n
d
d
o
o
-
-
n
n
o
o
s
s
n
n
a
a
s
s
l
l
i
i
m
m
i
i
t
t
a
a
ç
ç
õ
õ
e
e
s
s
d
d
a
a
a
a
b
b
o
o
r
r
d
d
a
a
g
g
e
e
m
m
p
p
r
r
o
o
p
p
o
o
s
s
t
t
a
a
.
.
P
P
o
o
r
r
f
f
i
i
m
m
,
,
a
a
p
p
r
r
e
e
s
s
e
e
n
n
t
t
a
a
m
m
o
o
s
s
n
n
o
o
s
s
s
s
a
a
s
s
c
c
o
o
n
n
s
s
i
i
d
d
e
e
r
r
a
a
ç
ç
õ
õ
e
e
s
s
f
f
i
i
n
n
a
a
i
i
s
s
.
.
7
7
.
.
1
1
C
C
o
o
n
n
t
t
r
r
i
i
b
b
u
u
i
i
ç
ç
õ
õ
e
e
s
s
Henry Ford, o genial construtor de automóveis norte
-
americano ficou famoso
(entre outras coisas) por que aplicou um sistema de produção
chamado 'em s
é
rie' para a
fabricação de automóveis. Muitos pensam que Ford descobriu algo novo e revolucionário,
mas é fácil perceber que ele apenas implementou algo que a natureza vem fazendo desde
que a vida surgiu no planeta terra, milhares de milhões d
e anos
atrás.
Neste processo, cada operário da fábrica somente se dedica a realizar uma
única tarefa, bem acabada, no menor tempo possível, dentro de uma chamada 'linha de
montagem'. Como resultado, a f
á
brica como um todo sai ganhando em tempo, qualidade e
preço dos seus produtos. Isto fez de Ford um dos homens mais ricos do seu tempo. Se cada
operário da fábrica construísse o carro completo desde o inicio até o final, demoraria
muitas vezes mais, teria uma qualidade provavelmente inferior, e seria enormeme
nte caro.
7.
Con
c
lusão 178
Fazendo um
a analogia com a engenharia de software
tem
-
se
com o conceito
(também antigo) do famoso “dividir para conquistar”. Com origens em técnicas de
construção de
algoritmos
, permitia que se tivesse a
preocupação
de lidar com um
problema por
vez.
Assim, pode
-
se
observar que a
separação de
propriedades
não é uma técnica
recente
, mesmo porque, ao construirmos um projeto de software
aplica
mos
naturalmente
a
separação de
propriedades, independente da abordagem utilizada.
K
iczales
et al. (1997) apr
esent
ou
vários pontos em que a pesquisa
na separação
de
propriedades poderia avançar, entre eles estão:
(i)
Como
antecipar a modelagem de aspectos para as atividades de
análise e projeto;
e
(ii)
Como
integrar a orientação a aspectos com métodos,
ferramentas e processos de desenvolvimento existentes.
Esta dissertação
oferece contribuições nessas duas direções
apontadas acima
.
Primeiro, porque a abordagem
proposta
permite antecipar a
identificação
de aspectos
candidatos na fase de requisitos
e segundo porque permite
integrar esta identificação com
um processo ou técnica existente, como o LEL.
Além disso,
aborda outras questões já
existentes,
como as de
Cysneiros (2002)
e Breitman (2003) (2005), permitindo
,
inclusive,
a exploração de uma nova faceta ligada
à
ontologia
s para a Web Semântica
, de acordo com a proposta apresentada por Breitman
(2005)
.
7
7
.
.
2
2
L
L
i
i
m
m
i
i
t
t
a
a
ç
ç
õ
õ
e
e
s
s
e
e
T
T
r
r
a
a
b
b
a
a
l
l
h
h
o
o
s
s
F
F
u
u
t
t
u
u
r
r
o
o
s
s
Est
a dissertação
trata do desenvolvimento de software orientado a aspectos na
atividade de requisitos, mas
sua principal limitação está
condicionada a
não an
á
lis
e
de
como seria a transição para a fase de projeto e implementação do sistema.
Assim, podemos listar algumas perspectivas de trabalho futuras:
·
Estender a abordagem DAORE para as outras fases do
desenvolvimento
, especificando a tr
ansição entre as fases e seus
artefatos
.
7.
Con
c
lusão 179
·
Processo de
Datamining
na fase de requisitos com a utilização de
Ontologias
.
·
Implementar uma ferramenta integrada ao DiSEN
(
plug in
)
para suporte
a DAORE.
·
R
ealização de mais estudos de caso nas abordagens existentes
, a fim de
fornecer mais heurísticas e diretrizes para os desenvolvedores.
·
Elaboração de análise
sobre o impacto das adaptações realizadas em
relação a questões arquiteturais e em relação à iteratividade e
incrementalidade do Processo Unificado
em relaçã
o a orientação a
aspectos
.
·
Construção de ferramenta que
possa
gera
r
automaticamente, a partir das
tabelas de composição
e cenários do LEL
, a perspectiva de
especificações de casos de uso e diagramas de interação com a presença
de aspectos que afetam esses artefatos;
e
·
Avaliação
do
LEL
e sua
possível
integração com a
Model
Driven
Architecture
-
MDA
(
MDA, 2003) como proposta de
m
elhoria das
especificações do projeto e aumento de reuso dos componentes.
7
7
.
.
3
3
C
C
o
o
n
n
s
s
i
i
d
d
e
e
r
r
a
a
ç
ç
õ
õ
e
e
s
s
F
F
i
i
n
n
a
a
i
i
s
s
Conforme apresentado
no Capí
tulo 4, o objetivo inicialmente proposto
foi o
de
estabelecer uma abordagem simples para possibilitar a
identificação dos aspectos
candidatos na fase de requisitos do ciclo de desenvolvimento.
E
ste objetivo
foi alcançado por meio da
inser
ção
d
os fundament
os do
paradigma orientado a aspectos
na integração do LEL
, mas sem ocasionar tanto impacto
em como o processo é conduzido, já que as alterações concentram
-
se mais na
contextualização dos cenários no LEL.
Além disso, pelo fato das adaptações não se prendere
m aos mecanismos de
uma linguagem orientada a aspectos específica e sim aos conceitos fundamentais do
paradigma orientado a aspectos, a abordagem
DAORE
oferece
suporte tanto a uma
7.
Con
c
lusão 180
implementação orientada a aspectos
(lidando com os aspectos candidatos)
como
a uma
implementação tradicional (cenários no LEL).
Outra característica positiva da abordagem
DAORE
é que as adaptações
seguem
um raciocínio lógico a partir da especificação dos requisitos. Especificando
-
os
primeiramente e ao longo do desenvolvimento do
processo e incluindo aspectos
relacionados
à
implementação de RNF e RO após a identificação dos símbolos existentes
nos RF.
A implementação dos aspectos através de tabelas de composição, permite
separar as preocupações transversais nos cenários aos quais e
la se apresenta, garantindo
que estas preocupações aspectuais tenham uma definição clara de quando e como será
implementada.
Pelo fato de possibilitar a separa
ção das
propriedades
transversais, os artefatos
que obt
idos
a partir d
a experimentação
realizad
a
possuem
um
melhor potencial de reuso,
manutenção e compreensão, quando comparados com aqueles que seriam obtidos
seguindo uma abordagem tradicional, na qual as
propriedades
transversais, normalmente,
ficariam espalhadas e misturadas nos artefatos.
Outros e
xperimentos são interessantes a fim de avaliar e aprimorar a
abordagem
proposta
, pois este trabalho
representa o primeiro passo para que
seja utilizado
o LEL
no processo de desenvolvimento de software orientado a aspectos.
7
7
.
.
4
4
T
T
r
r
a
a
b
b
a
a
l
l
h
h
o
o
s
s
S
S
u
u
b
b
m
m
e
e
t
t
i
i
d
d
o
o
s
s
Dura
nte a elaboração desta dissertação muitas idéias e soluções foram
apresentadas. Por conseqüência alguns trabalhos (
papers
) tomaram forma, de modo que
foi
submet
ido
a alguns eventos.
Deste modo, segue a lista de trabalhos e eventos submetidos e a submeter:
1.
SOMET 06
-
The 5th International Conference on Software Methodologies, Tools
and Techniques
-
Québec, Canadá. Realizado no período de 25 a 27 de outubro de
2006. Título: Comparing Approaches in AORE through ISO/IEC 9126.
Condição:
Aceito.
2.
RITA
-
Revista de Informática Teórica e Aplicada. Título: Comparing Approaches
in AORE through ISO/IEC 9126.
7.
Con
c
lusão 181
3.
SBES
-
21th Brazilian Symposium on Software Engineering –
2007. Título: AORE
in a Distributed Environment: The DAORE Approach
4.
XXIII Conferência LatinoAmerican
a de Informática
-
9
-
12 Octubre
-
San José
-
Costa Rica
Referencias Bibliográficas 182
Referências Bibliográficas
Só é útil o conhecimento que nos torna melhores.
Sócrates
N
N
e
e
s
s
t
t
a
a
p
p
a
a
r
r
t
t
e
e
a
a
p
p
r
r
e
e
s
s
e
e
n
n
t
t
a
a
m
m
o
o
s
s
a
a
s
s
r
r
e
e
f
f
e
e
r
r
ê
ê
n
n
c
c
i
i
a
a
s
s
b
b
i
i
b
b
l
l
i
i
o
o
g
g
r
r
á
á
f
f
i
i
c
c
a
a
s
s
c
c
o
o
n
n
s
s
u
u
l
l
t
t
a
a
d
d
a
a
s
s
p
p
a
a
r
r
a
a
a
a
e
e
l
l
a
a
b
b
o
o
r
r
a
a
ç
ç
ã
ã
o
o
d
d
a
a
d
d
i
i
s
s
s
s
e
e
r
r
t
t
a
a
ç
ç
ã
ã
o
o
.
.
AKSIT, M.; TEKINERDOGAN, B. and BERGMANS, L.
The Six Concerns f
or Separation of
Concerns
, in Proceedings of ECOOP 2001 Workshop on Advanced Separation of Concerns,
Budapest, Hungary, June 18
-
22, 2001.
AORE
–
Goals
-
overview
. Disponível em:
http://www.cs.toronto.edu/cser/aore.html
. Acesso em
13/01/2006.
ARAUJO,J
. et al.
Aspect
-
Oriented Requirements with UML
. Workshop on Aspect
-
Oriented
Modelling with UML. 2002.
April 22
-
26, Enschede, The Netherlands.
BAKKER, J
.
; Tekinerdoğan, B
.
; Aksit, M
.
;
Characterization o
f Early Aspects Approaches
.
presented at Workshop on
Early Aspects: Aspect
-
Oriented Requirements Engineering and
Architecture Design, held in conjunction with AOSD Conference, 2005.
Vancouv
er, Canada.
BANIASSAD, E.; Clarke,S. Theme: An approach for aspect
-
oriented analysis and design
, 26th
International Conference on Software Engineering (ICSE), IEEE Press, Edinburgh, Scotland, Maio
2004.
BANIASSAD, E.; Clarke,S.
Investigating the Use of Clu
es for Scaling Document
-
Level
Concern Graphs
, Early Aspects 2004: Aspect
-
Oriented Requirements Engineering and
Architecture Design, workshop of the OOPSLA 2004, Vancouver, Canada, Outubro 2004.
BATISTA, S. M.
Uma Ferramenta de Apoio à Definição de Requisit
os da MDSODI no
contexto do ambiente DiSEN. 2002. Dissertação de mestrado 83p –
Departamento de Informática
-
Universidade Estadual de Maringá/Universidade Federal do Paraná. Maringá: 2003.
BERGMANS, L. and AKSIT, M.
Composing Software from Multiple Concer
ns: A Model and
Composition Anomalies
, Multi Dimensional Separation of Concerns in Software Engineering
Workshop, ICSE 2000, Limerick, Ireland, 2000.
Referencias Bibliográficas 183
BERGMANS, L.; AKSIT, M and TEKINERDOGAN, B
.
Aspect Composition Using
Composition Filters, In Software Architectures and Component Technology: The State of the
Art in Research and Practice
, M. Aksit (Ed.), Kluwer Academic0 Publishers, pp. 357
-
382,
October 2001. (ISBN 0
-
7923
-
7576
-
BREITMAN
, K.K.,
LEITE
J.C.S.P,
A Framework for Scenario Evolution.
Proc. of the
Third IEE
inter. Conference on Req. Eng. IEEE Computer Society Press, Los Alamitos, CA, 1998, pp:214
-
221.
BREITMAN
, K.K.,
LEITE
, J.C.S.P.,
BERRY
, D., M.,
Scenario Evolution: A Closer View on
Relationships. ICRE 2000: 95
-
105. Meeting Date: 06/19/2000
-
06/2
3/2000 Schaumburg, IL, USA.
BREITMAN
, K.K.;
LEITE
, J.C.S.P
.
Lexicon Based Ontology Construction. Lecture Notes in
Computer Science
2940
-
Editors:
Carlos Lucena, Alessandro Garcia, Alexander Romanovsky, et
al.
-
ISBN:
3
-
540
-
21182
-
9
-
Springer
-
Verlag Heidelberg, February 2004, pp.19
-
34.
BREITMAN, Karin. Web Semantica: A Internet do Futuro. Rio de Janeiro. LTC. 2005.
BRITO, J and Araújo ,
A. Crosscutting Quality Attributes for Requirements Engineering
, 14th
International Conference on Software Engineering
and Knowledge Engineering (SEKE 2002),
ACM Press, Italy, July 2002.
BRITO
, A.
MOREIRA
e J.
ARAÚJO, A Requirements Model to Quality Attributes
, “Workshop
on Early Aspects: Aspect
-
Oriented Requirements Engineering and Architecture Design”, 1st
International
Conference on Aspect
-
Oriented Software Development (AOSD 2002), 22
-
26 de
Abril de 2002, Holanda.
BRITO, I. ;
MOREIRA
, A
.. Advanced Separation of Concerns for Requirements Engineering
.
VIII Jornadas de Ingeniería de Software y Bases de Datos (JISBD), Alic
ante, Spain, 12
-
14
Novembro 2003.
BRITO,I. and A.
MOREIRA.
Integrating the NFR framework in a RE model.
Early Aspects
2004: Aspect
-
Oriented Requirements Engineering and Architecture Design, workshop of the 3rd
International Conference on Aspect
-
Oriented Software Development, Lancaster, UK, 22
-
26 Março
2004.
BOOCH, G.;
RUMBAUGH
, J.,
JACOBSON
, I
. The Unified Modeling Language
, Addison
-
Wesley,1999.
CHITCHYAN, Ruzanna et al
. Survey of Aspect
-
Oriented Analysis and Design Approaches
.
Survey Lancaster University. May, 2005.
CHITCHYAN, Ruzanna;
RASHID
, Awais;
SAWYER
, Peter.
Comparing requirements
engineering approaches for handling crosscuting concerns
. Workshop on Requirements
Engineering (held with CAiSE), Porto, Portugal, June 12
-
14, 2005.
CHUNG
, L. et al.
Non
-
Functional Requirements in Software Engineering
, Kluwer Academic
Publishing, 2000. 472pp.
ISBN 0
-
7923
-
8666
-
3.
CLARKE, Siobhán; BANIASSAD, Elisa.
Aspect
-
Oriented Analysis and Design
–
the theme
app
roach.
United States. AddisonWesley, March, 2005.
Referencias Bibliográficas 184
CONSTANTINIDES, C. ; HASSOUN, Y.
Beyond objects: Improving the modularity of
complex software. Workshop on Grand Challenges for Computing Research. Edinburgh, Scotland,
November 24
-
26, 2002.
CYSNEIROS, L.M
.
Non
-
Functional Requeirements: From Elicitation to Conceptual Models–
Tese de Doudorado.
PUC_Rio
– Feb 2001
DIJKSTRA
, E.
A Discipline of Programming. Prentice Hall, Englewood Cliffs, NJ, 1976.
ELRAD, T., FILMAN, R. and BADER,
A. Aspect
-
Oriented Programming: Introduction
,
Communications of the ACM, v.44 n.10, p.29
-
32, Oct. 2001
ELRAD, T. et al.
Discussing Aspects of AOP
. Communications of
the ACM, 44(10):33
–
38,
October 2001.
FIGUEIREDO, E. et al
. Assessing Aspect
-
Oriented Artifacts: Towards a Tool
-
Supported
Quantitative Method
. Workshop on Quantitative Approaches in OO Software Engineering
(QAOOSE, held with ECOOP 2005), Glasgow, Scotland,
July 2005
FILHO
, T. L.
Metodologia de Desenvolvimento de Sistemas , Axcel Books, Rio de Janeiro,2003.
FRANCO, A. P. ; LEITE, J.
Uma Estratégia de Suporte à Engenharia de requisitos
. MI
Congresso da Sociedade Brasileira de Computação, Outubro 1992, pp. 200
-
213.
GANE, C.;
SARSON
,Trish.
Structured Systems Analysis
, New York, Improved System
Technologies, 1977.
GRAVENA, J. P.
Aspectos importantes de uma metodologia para desenvolvimento de
software com objetos distribuídos
.
Trabalho de graduação
–
Departamento
de informática
–
Universidade Estadual de Maringá. Maringá: 2000.
GRUNDY
, J.C.
Aspect
-
oriented Requirements Engineering for Component
-
based Software
Systems
, 1999 IEEE Symposium on Requirements Engineering, Limmerick, Ireland, 7
-
11 June,
1999, IEEE CS Pre
ss.
GRUBER
,
T. R..
A translation approach to portable ontology specifications
. Knowledge
Acquisition, 5:199
--
220, 1993.
GOSLING, J.
et al.
The Java Language Specification. Addison
-
Wesley, 2nd Edition, 2000.
HADAD
, Graciela et. al.
Construcción de Escenario
s a partir del Léxico Extendido del
Lenguage
JAIIO'97, Buenos Aires, 1997, pp. 65
-
77.
Haumer
,
Peter
;
POHL
,
Klaus
;
WEIDENHAUPT,
Klaus
.
Requirements Elicitation and
Validation with Real World Scenes. IEEE Trans. Software Eng. 24(12): 1036
-
1054 (1998)
HUZITA
, E. H. M.
Uma Metodologia para Desenvolvimento Baseada em Objetos Distribuídos
Inteligentes
. Projeto de Pesquisa. Universidade Estadual de Maringá, Departamento de Informática.
1999
Referencias Bibliográficas 185
IEEE
.
Qualities of a good software requirements specification
(SRS).
Ver
são traduzida
disponivel em:
www.ieee.org
e
http://www.unoeste.br/fipp/estagio/arquivos/IEEE
-
Std
-
830
-
1998_traducao.pdf
. Acess
o em 13/01/2006.
ISO
, International Standard ISO/IEC 9126: Software Engineering
-
Product Quality.
Disponível em http://www.iso.org/. Acesso em 13/01/2006.
JACOBSON, I.; NG, P.W.
Aspect
-
Oriented Software Development wit
h Use Cases
, Addison
Wesley 2005.
JACOBSON, Ivar.
Aspect composition at requirements
-
level. Blog de discursão sobre
orientação a aspectos. Disponível em
http://early
-
aspects.blogspot.com/. Acesso em 27/1
2/05.
JR, S. M. S.
Concerns in a Requirements Model
–
A Small Case Study. In Proceedings of
Early Aspects 2003: Aspect
-
Oriented Requirements Engineering and Architecture Design,
Workshop, March 17, Boston, USA, 17 Mar. 2003.
KERSTEN, M. and MURPHY, G.
Atla
s: A Case Study in Building a Web
-
Based Learning
Environment using Aspectoriented Programming. In OOPSLA’1999. 1999.
KICZALES, G. et al.
An Overview of AspectJ
. In J. L. Knudsen, editor, 15th European
Conference on Object
-
Oriented Programming, volume 2072
of LNCS, pages 327
–
353, Berlin,
Heidelberg, and New York, Springer Verlag, 2001.
KERZNER
,H.
Project Management: A Systems Approach to Planning, Scheduling, and
Controlling
Publi
sher John Wiley and Sons, 2003.
LEITE
J.C.S.P.;
Franco
, A.P.M.
A
Strategy for Conceptual Model Acquisition
in Proceedings of
the First IEEE International Symposium on Requirements Engineering
, SanDiego, Ca, IEEE
Computer Society Press, 1993 pp. 243
-
246
LEI
TE
,
J. C.S.P.
Enhancing a Requirements Baseline with Scenarios
.
Requir. Eng. 2
(4): 184
-
198 (1997)
LIEBERHERR, K. Adaptive Object
-
Oriented Software: The Demet
er Method with Propagation
Patterns
. PWS Publishing Company, Boston, 1996.
LOUCOPOULOS
, P.;
KARAKOSTAS
, V.
System Requirements Engineering
, McGraw
-
Hill,
1995.
MAMANI
, Nestor A
. Integrando requisitos não funcionais aos requisitos baseados em ações
concerta
s
, Dissertação de mestrado, Departamento de informática, PUC
-
RIO, Maio, 1999.
MARTINEZ,
E. N.;
TORRES,
P. L.;
SALAVERT
,
I. R.
.
Goals and Quality Characteristics:
Separating Concerns
. Early Aspects 2004: Aspect
-
Oriented Requirements Engineering and
Architecture Design Workshop, collocated to OOPSLA 2004, Monday, October 25, 2004,
Vancouver,
Canada (Accepted)
-
2004
MCMENAMIN, S.;
PALMER
,J. F
. Análise Essencial de Sistemas
, Makron Books, São
Paulo,1984.
Referencias Bibliográficas 186
MDA
Guide
.
Disponível em:
http://www.omg.org/docs/omg/03
-
06
-
01.pdf
.
Ultimo acesso
em:04/11/06.
MILI, H. ; Elkharraz, A.; Mcheick, H..
Understanding Separation of Concerns
. In Workshop on
Early Aspects
-
Aspect Oriented Software Development (AOSD'04), pages 411{428, March 2004.
MOREIRA, A.; Araújo, J.; Brito, I
. Crosscutting Quality At
tributes for Requirements
Engineering
. Proceedings of the 14th International Conference on Software Engineering and
Knowledge Engineering (SEKE), Ischia, Italy, ACM Press, pp. 167
-
174, Julho 2002.
MORO, C. F.
Proposta de um Repositório de Metadados para Am
biente de Desenvolvimento
de Software Distribuído. Maringá: DINUEM/ UFPR, 2002. Dissertação de Mestrado.
OSSHER, H. and TARR, P.
Multi
-
Dimensional Separation of Concerns and the Hyperspace
Approach
. In Proceedings of the Symposium on Software Architecture
s and Component
Technology: The State of the Art in Software Development. Kluwer, 2000.
PARNAS
, D.
On the Criteria to be Used in Decomposing Systems into Modules
.
Communications of the ACM, 15 (12), December 1972, pp. 1053
-
1058.
PASCUTTI, M. C. D.
Uma pro
posta de arquitetura de um ambiente de desenvolvimento de
software distribuído baseada em agentes. Dissertação de mestrado – Programa de Pós
-
Graduação
em Ciência da Computação, Instituto de Informática, Universidade Federal do Rio Grande do Sul.
Porto Aleg
re: 2002
PEDRAS, M. E. V.
Uma Ferramenta de Apoio ao Gerenciamento de Desenvolvimento de
Software Distribuído. Maringá: DINUEM/ UFPR, 2002. Dissertação de Mestrado.
PRESSMAN, R. Software Engineering: a Practitioner’s Approach. 6th ed., McGraw
-
Hill, 2001.
R
ASHID
, A. et al. Early Aspects:
A Model for Aspect
-
Oriented Requirements Engineering
.
Proceedings of the IEEE Joint International Conference on Requirements Engineering (RE), Essen,
Germany, IEEE CS Press, pp. 199
-
202, Setembro 2002.
RASHID
, A.;
MOREIRA
, A.;
ARAÚJO
, J.
Modularisation and Composition of Aspectual
Requirements.
Proceedings of the 2nd International Conference on Aspect
-
Oriented Software
Development (AOSD), Boston, USA, ACM Press, pp. 11
-
20, Março 2003.
ROYCE, W.
Software project management: a
unified framework
-
1998
-
Addison
-
Wesley
Longman Publishing Co., Inc. Boston, MA, USA
SANTANDER, Victor Francisco Araya .
Integrando Modelagem Organizacional com
Modelagem Funcional, Tese de Doutorado, CIn
-
UFPE, Recife, Dezembro. 2002.
SCOTT, Kendall. O Processo Unificado Explicado. Bookman,, Porto Alegre,2003
SILVA
, L. et al..
Comparing Approaches in AORE through ISO/IEC 9126
.
The 5th
International Conference on Software Methodologies, Tools and Techniques
, Quebec
–
Canadá,
2006
Referencias Bibliográficas 187
SILVA
, L. de P.
Uma pr
oposta de evolução em sistemas legados
. Monografia
-
Especialização
,
Curso de Pós
-
Graduação em Sistemas de Informação Distribuídos, UNIOESTE, 2004.
SILVA
, Lyrene; Leite, Julio C. Sampaio.
Integração de características transversais durante a
modelagem de re
quisitos
. 19º Simposio Brasileiro de Engenharia de Software. Minas Gerais,
2005.
SHLAER
, S.;
MELLOR
, S.
Análise de Sistemas Orientada para Objetos
, Makron Books, São
Paulo,1990.
SOMMERVILLE
, I.
Software Engineering fourth edition, Addison
-
Wesley, 1992.
SOM
MERVILLE
,
IAN
;
SAWYER
,
PETER
;
VILLER
, STEPHEN, Viewpoints for Requirements
Elicitation: A Practical Approach
, Proceedings of the 3rd International Conference on
Requirements Engineering: Putting Requirements Engineering to Practice, p.74
-
81, April 06
-
10,
1998
SOUZA, D. ; Wills, A..
Objects, Components and Frameworks with UML
: The Catalysis
Approach, USA: Addison
-
Wesley, (1995).
SOUZA, Georgia M. C. Uma Abordagem Direcionada a Casos de Uso para o Desenvolvimento
de Software Orientado a Aspectos. Dissertação de Mestrado, UFPE, 2004.
SOUZA, Michel.
Metadados
.
Disponível em:
http://www.imasters.com.br/artigo/1569/bi/metadados/. Ultimo acesso em 23/10/06.
TARR, P.
et al
. N Degrees of Separati
on: Multidimensional Separation of Concerns
. In
Proceedings of the 21st International Conference on Software Engineering (ICSE'99), 107
–
119,
May 1999.
Los Angeles, California, United States.
TEKINERDOĞAN,
Bedir:
ASAAM:
Aspectual Software Architecture Analysis Method
.
WICSA 2004
: 5
-
14
THEME.
Conceitos Gerais sobre a Abordagem Theme
e ferrame
nta Theme/Doc Disponível em:
http://www.dsg.cs.tcd.ie/index.php .. Acesso em 23/01/06.
TORANZO
, Marco A.,
Uma Proposta para Melhorar o Rastreamento de Requisitos de
Software
, Centro de Informática, Unive
rsidade Federal de Pernambuco, Tese de Doutorado,
Dezembro, (2002).
TRAVASSOS, G. H.
Introdução a Engenharia de Software Experimental
.
Relatório técnico.
Programa de Engenharia de Sistemas e Computação. COPPE/UFRJ, 2002.
UML
-
Unified Modeling Language, v
ersion 2.0.
The Object Management Group. Dispon
í
vel em:
http://www.uml.org/. Ultimo acesso: 26/09/2006.
XML SCHEMA
. D
isponível em: http://www.w3.org/XML/Schema ultimo acesso em 23/10/06.
YU
, E.,
Towards
Modelling and Reasoning Support for Early
-
Phase Requirements
Engineering, Proceedings of IEEE International Symposium on Requirements Engineering
-
RE97,
Jan, (1997), pp.226
-
235.
Referencias Bibliográficas 188
YU
, Y.;
LEITE
, J.;
MYLOPOULOS
, J.
From goals t
o aspects: discovering aspects from
requirements goal models, Proceedings of the 12th IEEE International Requirements Engineering
Conference (RE), pp.38 – 47
.
Kyoto, Japan, IEEE CS Press, Setembro 2004.
WAZLAWICK
, R. S.
Análise e projeto de sistemas de in
formação orientados a objetos
.
São
Paulo.
Elsevier, 2004
W3C.
Web
-
Ontology
(WebOnt) Working Group . Documentos diversos sobre Ontologias.
Disponível em: http://www.w3.org/2001/sw/WebOnt/. Ultimo acesso: 04/11/06.
Anexo
A
189
A
NEXO
A
A
S
CHEMAS
XML
GERADOS
A
A
s
s
e
e
g
g
u
u
i
i
r
r
a
a
p
p
r
r
e
e
s
s
e
e
n
n
t
t
a
a
m
m
o
o
s
s
o
o
s
s
S
S
c
c
h
h
e
e
m
m
a
a
s
s
X
X
M
M
L
L
g
g
e
e
r
r
a
a
d
d
o
o
s
s
p
p
a
a
r
r
a
a
o
o
n
n
o
o
s
s
s
s
o
o
t
t
r
r
a
a
b
b
a
a
l
l
h
h
o
o
.
.
P
P
r
r
i
i
m
m
e
e
i
i
r
r
a
a
m
m
e
e
n
n
t
t
e
e
a
a
p
p
r
r
e
e
s
s
e
e
n
n
t
t
a
a
m
m
o
o
s
s
a
a
v
v
i
i
s
s
u
u
a
a
l
l
i
i
z
z
a
a
ç
ç
ã
ã
o
o
g
g
r
r
á
á
f
f
i
i
c
c
a
a
e
e
d
d
e
e
p
p
o
o
i
i
s
s
o
o
a
a
r
r
q
q
u
u
i
i
v
v
o
o
t
t
e
e
x
x
t
t
o
o
.
.
O
O
s
s
S
S
c
c
h
h
e
e
m
m
a
a
s
s
X
X
M
M
L
L
f
f
o
o
r
r
a
a
m
m
e
e
l
l
a
a
b
b
o
o
r
r
a
a
d
d
o
o
s
s
a
a
t
t
r
r
a
a
v
v
é
é
s
s
d
d
a
a
f
f
e
e
r
r
r
r
a
a
m
m
e
e
n
n
t
t
a
a
S
S
t
t
y
y
l
l
u
u
s
s
S
S
t
t
u
u
d
d
i
i
o
o
2
2
.
.
Anexo
A
190
A
A
s
s
p
p
e
e
c
c
t
t
o
o
s
s
L
L
E
E
L
L
.
.
x
x
s
s
d
d
?xml version="1.0"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<
xsd:element
name=
"Aspectos">
<xsd:complexType>
<
xsd:sequence
>
<
xsd:element
name=
"Projeto"
>
<
xsd:compl
exType>
<
xsd:attribute
name=
"id"
type=
"xsd:integer"
/
>
<
xsd:attribute
name=
"nome"
type=
"xsd:string"
/
>
</xsd:complexType>
</xsd:element>
<
xsd:element
name=
"as
pecto_candidato">
<xsd:complexType>
<
xsd:sequence
>
<
xsd:element
name=
"id"
type=
"xsd:integer"
/
>
<
xsd:element
name=
"nome"
type=
"xsd:string"
/
>
<
xsd:element
name=
"origem">
<
xsd:simpleType
>
<xsd:restriction
base=
"xsd:string"
>
<xsd:enumeration
value=
"RNF"
/
>
<xsd:enumeration
value=
"RF"
/
>
<xsd:enumeration
value="RO"
/
>
</xsd:restriction>
</xsd:simpleType>
</xsd:e
lement
>
<
xsd:element
name=
"descricao"
type=
"xsd:string"
/
>
<
xsd:element
name=
"cenariosafetados"
maxOccurs=
"unbounded"
minOccurs=
"1"
>
<xsd:complexType>
<
xsd:sequence
>
Anexo
A
191
<
xsd:element
name=
"cenarioid"
type=
"xsd:integer"
/
>
<
xsd:element
name=
"nome_cenario"
type=
"xsd:string"
/
>
<
xsd:element
name=
"condicao"
type=
"xsd:string"
/
>
<
xsd:element
name=
"regracomposicao">
<
xsd:simpleType
>
<xsd:restriction
bas
e=
"xsd:string"
>
<xsd:enumeration
value=
"wrap"
/
>
<xsd:enumeration
value=
"overlap.after"
/
>
<xsd:enumeration
value=
"overlap.before"
/
>
<xsd:enumeration
value=
"override"
/
>
</xsd:restriction>
</xsd:simpleType>
</xsd:element>
<
xsd:element
name=
"pontojuncao"
type=
"xsd:integer"
/
>
<
xsd:element
name=
"informacoesadicionais"
type=
"xsd:string"
/
>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<
/
xsd:sequence
>
</xsd:complexType>
</xsd:element>
<
/xsd:schema
>
L
L
E
E
L
L
S
S
i
i
m
m
b
b
o
o
l
l
o
o
s
s
.
.
x
x
s
s
d
d
Anexo
A
192
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<
xsd:element
name=
"Projeto"
>
<xsd:complexType>
<
xsd:sequence
>
<
xsd:element
name=
"id_projeto"
type=
"xsd:integer"
/
>
<
xsd:element
name=
"dominio"
type=
"xsd:string"
/
>
<
xsd:element
name=
"nome_projeto"
type=
"xsd:string"
/
>
<
xsd:element
name=
"descricao"
type=
"xsd:string"
/
>
<
xsd:sequence
>
<
xsd:element
name=
"LEL"
>
<xsd:complexType>
<
xsd:sequence
>
<
xsd:element
name=
"id_simbolo"
type=
"xsd:integer"
minOccurs="1"
/
>
<
xsd:element
name=
"nome_simbolo"
type=
"xsd:string"
/
>
<
xsd:element
name=
"categoria">
<
xsd:simpleType
>
<xsd:restriction
base=
"xsd:string"
>
<xsd:enumeration
value=
"sujeito"
/
>
<xsd:enumeration
value=
"verbo"
/
>
<xsd:enumeration
value=
"estado"
/
>
<xsd:enumeration
value=
"objeto"
/
>
Anexo
A
193
</xsd:restriction>
</xsd:simpleType>
</xsd:element>
<
xsd:element
name=
"sinonimos"
>
<xsd:complexType>
<
xsd:sequence
>
<
xsd:element
name=
"alias"
type=
"xsd:string"
/
>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<
xsd:element
name=
"nocoes">
<xsd:complexType>
<
xsd:sequence
>
<
xsd:element
name=
"id_nocao"
type=
"xsd:integer"
/
>
<
xsd:element
name=
"descricao_nocao"
type=
"xsd:string"
/
>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<
xsd:element
name=
"impactos"
>
<
xsd:c
omplexType>
<
xsd:sequence
>
<
xsd:element
name=
"id_impacto"
type=
"xsd:integer"
/
>
<
xsd:element
name=
"descricao_impacto"
type=
"xsd:s
tring"
/
>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<
/xsd:schema
>
Anexo
A
194
L
L
E
E
L
L
C
C
e
e
n
n
a
a
r
r
i
i
o
o
s
s
.
.
x
x
s
s
d
d
<?xml version="1.0"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<
xsd:element
name=
"Projeto"
>
<xsd:complexType>
<
xsd:sequence
>
<
xsd:element
name=
"id_projeto"
type=
"xsd:integer"
/
>
<
xsd:element
name=
"dominio"
type=
"xsd:string"
/
>
<
xsd:element
name=
"nom
e_projeto"
type=
"xsd:string"
/
>
Anexo
A
195
<
xsd:element
name=
"descricao"
type=
"xsd:string"
/
>
<
xsd:element
name=
"cenarios">
<xsd:complexType>
<
xsd:sequence
>
<xsd:ele
ment
name=
"Tipo_mdsodi">
<
xsd:simpleType
>
<xsd:restriction
base=
"xsd:string"
>
<xsd:enumeration
value=
"sequencial"
/
>
<xsd:enumeration
value=
"paralelo"
/
>
<xsd:enumeration
value=
"distribuido"
/
>
<xsd:enumeration
value=
"paralelo_distribuido"
/
>
<
/xsd:res
triction>
</xsd:simpleType>
</xsd:element>
<
xsd:element
name=
"cenarioid"
type=
"xsd:integer"
/
>
<
xsd:element
name=
"titulo"
type=
"xsd:string"
/
>
<
xsd:element
name=
"objetivo"
type=
"xsd:string"
/
>
<
xsd:element
name=
"contexto"
>
<xsd:complexType>
<
xsd:sequence
>
<
xsd:element
name=
"texto"
type=
"xsd:string"
/
>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<
xsd:element
na
me="atores"
>
<xsd:complexType>
<
xsd:sequence
>
<
xsd:element
name=
"nome"
type=
"xsd:string"
/
>
<
xsd:element
name
=
"tipo_ator"
type=
"xsd:string"
/
>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<
xsd:element
name=
"recursos">
<xsd:complexType>
<
xsd:sequence
>
<
xsd:element
name=
"descricao"
type=
"xsd:string"
/
>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<
xsd:element
name=
"episodios">
<xsd:complexType>
<
xsd:sequence
>
<
xsd:element
name=
"texto"
type=
"xsd:string"
/
>
<
xsd:element
name=
"RNFEspecifico">
<xsd:complexType>
<
xsd:sequence
>
<
xsd:element
name=
"texto"
type=
"xsd:string"
/
>
<
xsd:element
name=
"estrategia"
type=
"xsd:string"
/
>
</xsd:sequence>
</xsd:complexType>
Anexo
A
196
</xsd:element>
<
xsd:element
name=
"ExpressaoOCL">
<xsd:complexType>
<
xsd:sequence
>
<
xsd:element
name=
"texto"
type=
"xsd:string"
/
>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<
xsd:element
name=
"Rorg"
>
<xsd:complexType>
<
xsd:sequence
>
<
xsd:element
name=
"texto"
type=
"xsd:string"
/
>
<
xsd:element
name=
"estrategia"
type=
"xsd:string"
/
>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<
/xsd:schema
>
O
O
n
n
t
t
o
o
l
l
o
o
g
g
i
i
a
a
.
.
x
x
s
s
d
d
Anexo
A
197
<?xml version="1.0"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<
xsd:element
name=
"ontologias">
<xsd:complexType>
<
xsd:sequence
>
<
xsd:element
name=
"projeto"
type=
"xsd:string"
/
>
<
xsd:element
name=
"classe"
>
<xsd:complexType>
<
xsd:sequence
>
<
xsd:element
name=
"nome"
type=
"xsd:string"
/
>
<
xsd:element
name=
"descricao"
type=
"xsd:string"
/
>
<
xsd:sequence
>
<
xsd:element
name=
"restricao"
type=
"xsd:string"
/
>
</xsd:sequence>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<
xsd:element
name=
"proprie
dade"
>
<xsd:complexType>
<
xsd:sequence
>
<
xsd:element
name=
"nome"
type=
"xsd:string"
/
>
</xsd:sequence>
</xsd:complexType>
<
/xs
d:element>
<
xsd:element
name=
"axioma"
>
<xsd:complexType>
<
xsd:sequence
>
<
xsd:element
name=
"descricao"
type=
"xsd:string"
/
>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<
/xsd:schema
>
O
O
n
n
t
t
o
o
h
h
i
i
e
e
r
r
a
a
r
r
q
q
u
u
i
i
a
a
.
.
x
x
s
s
d
d
<?xml version="1.0"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
Anexo
A
198
<
xsd:element
name=
"ontohierarquia">
<xsd:complexType>
<
xsd:sequence
>
<
xsd:element
name=
"projeto"
type=
"xsd:string"
/
>
<
xsd:element
name=
"classepai"
>
<xsd:complexType>
<
xsd:sequence
>
<
xsd:element
name=
"nome"
type=
"xsd:string"
/
>
<
xsd:sequence
>
<
xsd:element
name=
"classefilho"
type=
"xsd:string"
>
</xsd:element>
</xsd:sequence>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<
/xsd:schema
>
Anexo
B
199
A
NEXO
B
B
T
ELAS DO
OORNF
A
A
s
s
e
e
g
g
u
u
i
i
r
r
a
a
p
p
r
r
e
e
s
s
e
e
n
n
t
t
a
a
m
m
o
o
s
s
a
a
s
s
t
t
e
e
l
l
a
a
s
s
d
d
o
o
s
s
i
i
s
s
t
t
e
e
m
m
a
a
O
O
O
O
R
R
N
N
F
F
e
e
m
m
s
s
u
u
a
a
n
n
o
o
v
v
a
a
v
v
e
e
r
r
s
s
ã
ã
o
o
a
a
l
l
t
t
e
e
r
r
a
a
d
d
a
a
,
,
q
q
u
u
e
e
f
f
o
o
i
i
c
c
h
h
a
a
m
m
a
a
d
d
a
a
d
d
e
e
C
C
A
A
L
L
E
E
L
L
,
,
c
c
o
o
m
m
o
o
e
e
s
s
t
t
u
u
d
d
o
o
d
d
e
e
c
c
a
a
s
s
o
o
a
a
p
p
r
r
e
e
s
s
e
e
n
n
t
t
a
a
d
d
o
o
n
n
o
o
C
C
a
a
p
p
í
í
t
t
u
u
l
l
o
o
5
5
.
.
Anexo
B
200
A seguir temos a tela do Menu principal da ferramenta
CALEL
:
Como podemos observar, nem todos os itens do Menu Principal estarão acessíveis em um
primeiro momento, pois devemos escolher um projeto para podermos inserir os símbolos
do LEL, entre outras opções.
Porém, podemos acessar a tela dos RNF, onde podemos realizar as operações básicas nos
Requisitos não funcionais (tela a seguir).
Anexo
B
201
Primeiramente escolhemos
/incluímos
o nome do projeto:
A seguir vemos um exemplo do LEL, aqui tínhamos apenas alguns termos incluídos, e
podemos observar que os termos que aparecem sublinhados são aqueles inclusos
no
projeto.
À medida que inserimos novos símbolos este principio (de circularidade) se torna
mais evidente.
Após a inserção de todos os símbolos, podemos tratar dos cenários. Para isto, podemos
gerar os atores de forma automática, bem como os recursos. A seguir veremos as telas
correspondentes.
Anexo
B
202
Vale observar que todos os atores serão incluídos como sendo primários. A situação será
alterada após a inserção dos atores nos cenários. Para a nomenclatura MDSODI será de
acordo com o cenário tratado.
Anexo
B
203
Anexo
B
204
Após a geração automática dos atores e recursos, podemos gerar também os cenários.
Alguns campos não serão preenchidos de forma automática, devendo existir a intervenção
do ope
rador.
Para isso, ao acessar a tela de cenários Update/View, podemos alterar o
cenário e, inclusive incluir novos cenários.
Na tela anterior, ao inserirmos os episódios podemos inserir restrições e sentenças pré
-
programadas (condicionais e opcionais) – tecla do botão direito no mouse.
Anexo
B
205
A seguir podemos observar a inclusão de uma restrição OCL:
Após os episódios inseridos com suas respectivas restrições podemos gerar os aspectos
candidatos, mostrado
no exemplo
a seguir.
Anexo
B
206
Anexo
B
207
A seguir
mostraremos a tela para atualização dos aspectos e suas regras de composição.
Anexo
B
208
Como podemos observar ele já irá trazer os aspectos relativos aos requisitos não
funcionais, observe o campo ORIGIN indicando RNF. Ao clicarmos nos cenários afetados
obtemos
a opção de atualizarmos os cenários afetados pelo aspecto selecionado. Observe a
tela abaixo:
Anexo
B
209
Como podemos observar alguns campos não são preenchido pela geração automática dos
aspectos, estes campos devem ser atualizados para que possamos depois gerar
a tabela de
conflitos.
Se quisermos adicionar um cenário basta clicar no botão
insert
e ele irá mostrar todos os
cenários do projeto, como mostra a tela abaixo:
Anexo
B
210
Depois basta clicarmos em Select and Insert, para que o cenário seja incluído como
cenário a
fetado.
A tela acima representa a verificação de conflitos entre os aspectos , de acordo com o
especificado no projeto. A resolução destes conflitos é típica de projeto e deve ser efetuada
com muito cuidado.
Mostraremos agora
o exemplo de como
gerar a
o
ntologia
para o projeto selecionado.
Isto é
feito
em algumas etapas, mostradas nas telas a seguir:
Gerando classes:
Anexo
B
211
Após gerar as classes:
Gerando propriedades:
Anexo
B
212
Agora, podemos atualizar as propriedades e classes geradas:
Anexo
B
213
Para ger
ar hierarquias, devemos indicar a classe pai e as classes filhos, de acordo com a
tela abaixo:
Ao indicarmos um nome para a classe pai, podemos ir na página dos filhos descendentes e
colocarmos todas as classes filhos existentes. Conforme tela abaixo:
Anexo
B
214
Finalmente, os arquivos XML gerados a partir dos XML Schema definidos (Anexo A),
estão no anexo C.
Anexo
C
215
A
NEXO
C
C
ARQUIVOS
XML
GERADOS NO
E
STUDO DE
C
ASO
A
A
s
s
e
e
g
g
u
u
i
i
r
r
a
a
p
p
r
r
e
e
s
s
e
e
n
n
t
t
a
a
m
m
o
o
s
s
o
o
s
s
a
a
r
r
q
q
u
u
i
i
v
v
o
o
s
s
X
X
M
M
L
L
g
g
e
e
r
r
a
a
d
d
o
o
s
s
a
a
t
t
r
r
a
a
v
v
é
é
s
s
d
d
o
o
s
s
X
X
M
M
L
L
S
S
c
c
h
h
e
e
m
m
a
a
p
p
r
r
o
o
p
p
o
o
s
s
t
t
o
o
s
s
c
c
o
o
m
m
o
o
e
e
s
s
t
t
u
u
d
d
o
o
d
d
e
e
c
c
a
a
s
s
o
o
a
a
p
p
r
r
e
e
s
s
e
e
n
n
t
t
a
a
d
d
o
o
n
n
o
o
C
C
a
a
p
p
í
í
t
t
u
u
l
l
o
o
5
5
.
.
Anexo
C
216
A
A
s
s
p
p
e
e
c
c
t
t
o
o
s
s
.
.
x
x
m
m
l
l
<?xml version="1.0"?>
<
Aspectos
xmlns:xsi="http://www.w3.org/2001/XMLSchema
-
instance"
xsi:noNamespaceSchemaLocation="file:///f:/Luciana/tese_uem/tese/Monografia/Aspectos
LEL.xsd"
>
<
Projeto
id=
"
-
9223372036854775808"
nome=
"string"
>
<
!
--
Attribute nome is optional
--
>
<
!
--
Attribute id is optional
--
>
<
/Projeto
>
<aspecto_candidato>
<
id
>1<
/id
>
<
nome
> Confidenciabilidade
<
/nome>
<
origem
>
RNF<
/origem
>
<descricao> Garantir a autenticação e validação do usuario <
/descricao
>
<
!
--
Element cenariosafetados, maxOccurs=u
nbounded
--
>
<cenariosafetados>
<cenarioid>
1
1
<
/cenarioid
>
<nome_cenario>
A
A
l
l
t
t
e
e
r
r
a
a
r
r
p
p
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
n
n
t
t
e
e
<
/nome_cenario
>
<
condicao
> </condicao>
<regracomposicao
>
wrap
<
/regracomposicao>
<
pontojuncao
>1
<
/pontojuncao>
<
info
rmacoesadicionais
>
Se situaçãoOK então executa(ponto junção)
Senão exibe
(msgErro)
</informacoesadicionais>
</cenariosafetados> <cenariosafetados>
<cenarioid>
2
2
</cenarioid>
<nome_cenario
>
E
E
x
x
c
c
l
l
u
u
i
i
r
r
p
p
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
n
n
t
t
e
e
<
/nome_cenario
>
<
condicao
> </condicao>
<regracomposicao
>
wrap
<
/regracomposicao>
<
pontojuncao
>1
<
/pontojuncao>
<informacoesadicionais>
Se situaçãoOK então executa(ponto junção)
Senão exibe
(msgErro)
</informacoesadicionais>
</cenariosafetados>
<cenariosafetados>
<cenarioid>
3
3
</cenarioid>
<nome_cenario>
C
C
o
o
n
n
s
s
u
u
l
l
t
t
a
a
r
r
p
p
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
n
n
t
t
e
e
s
s
<
/nome_cenario
>
<
condicao
> </condicao>
<regracomposicao
>
wrap
<
/regracomposicao>
<
pontojuncao
>1
<
/pontojuncao>
<informacoesadicionais>
Se situaçãoOK então executa(ponto junção)
Senão exibe
(msgErro)
</informacoesadicionais>
</cenariosafetados>
<cenariosafetados>
<cenarioid>
4
4
</cenarioid>
<nome_cenario>
-
-
C
C
a
a
d
d
a
a
s
s
t
t
r
r
a
a
r
r
e
e
v
v
e
e
n
n
t
t
o
o
<
/nome_cenario
>
<
condicao
> </condicao>
<regracomposicao
>
wrap
<
/regracomposicao>
<
pontojuncao
>1
<
/pontojuncao>
<informacoesadicionais>
Se situaçãoOK então executa(ponto junção)
Senão exibe
(msgErro)
</informacoesadicionais>
Anexo
C
217
</cenariosafetados>
<
cenariosaf
etados>
<cenarioid>
C
C
N
N
#
#
5
5
<
/cenarioid
>
<nome_cenario>
C
C
a
a
d
d
a
a
s
s
t
t
r
r
a
a
r
r
c
c
o
o
m
m
i
i
s
s
s
s
ã
ã
o
o
<
/nome_cenario
>
<
condicao
> </condicao>
<regracomposicao
>
wrap
<
/regracomposicao>
<
pontojuncao
>1
<
/pontojuncao>
<informacoesadicionais>
Se
situaçãoOK então executa(ponto junção)
Senão exibe
(msgErro)
</informacoesadicionais>
</cenariosafetados>
<cenariosafetados>
<cenarioid>
6
6
</cenarioid>
<nome_cenario>
C
C
a
a
d
d
a
a
s
s
t
t
r
r
a
a
r
r
c
c
o
o
m
m
i
i
t
t
ê
ê
</nome_cenario>
<
condicao
> </condicao>
<regracomposicao
>
wrap
<
/regracomposicao>
<
pontojuncao
>1
<
/pontojuncao>
<informacoesadicionais>
Se situaçãoOK então executa(ponto junção)
Senão exibe
(msgErro)
</informacoesadicionais>
</cenariosafetados>
<cenariosafetados>
<cenarioid>
7
7
</cenarioid>
<nome_cenario>
R
R
e
e
c
c
e
e
b
b
e
e
r
r
r
r
e
e
c
c
u
u
r
r
s
s
o
o
s
s
<
/nome_cenario
>
<
condicao
> </condicao>
<regracomposicao
>
wrap
<
/regracomposicao>
<
pontojuncao
>1
<
/pontojuncao>
<informacoesadicionais>
Se situaçãoOK então exe
cuta(ponto junção)
Senão exibe
(msgErro)
</informacoesadicionais>
</cenariosafetados>
<cenariosafetados>
<cenarioid>
8
8
</cenarioid>
<nome_cenario>
D
D
i
i
s
s
t
t
r
r
i
i
b
b
u
u
i
i
r
r
r
r
e
e
c
c
u
u
r
r
s
s
o
o
s
s
<
/nome_cenario
>
<
condicao
> </condicao>
<regracompos
icao
>
wrap
<
/regracomposicao>
<
pontojuncao
>1
<
/pontojuncao>
<informacoesadicionais>
Se situaçãoOK então executa(ponto junção)
Senão exibe
(msgErro)
</informacoesadicionais>
</cenariosafetados>
<cenariosafetados>
<cenarioid>
9
9
<
/
cenarioid
>
<nome_cenario>
P
P
a
a
g
g
a
a
r
r
f
f
o
o
r
r
n
n
e
e
c
c
e
e
d
d
o
o
r
r
</nome_cenario>
<
condicao
> </condicao>
<regracomposicao
>
wrap
<
/regracomposicao>
<
pontojuncao
>1
<
/pontojuncao>
<informacoesadicionais>
Se situaçãoOK então executa(ponto junção
)
Senão exibe
(msgErro)
</informacoesadicionais>
</cenariosafetados>
<cenariosafetados>
<cenarioid>
1
1
0
0
<
/cenarioid
>
<nome_cenario>
R
R
e
e
c
c
e
e
b
b
e
e
r
r
p
p
a
a
g
g
a
a
m
m
e
e
n
n
t
t
o
o
<
/nome_cenario
>
<
condicao
> </condicao>
Anexo
C
218
<regracomposicao
>
wrap
<
/regraco
mposicao
>
<
pontojuncao
>1
<
/pontojuncao>
<informacoesadicionais>
Se situaçãoOK então executa(ponto junção)
Senão exibe
(msgErro)
</informacoesadicionais>
</cenariosafetados> <cenariosafetados>
<cenarioid>
1
1
2
2
<
/cenarioid
>
<nome_cenario>
-
-
I
I
n
n
s
s
c
c
r
r
e
e
v
v
e
e
r
r
-
-
s
s
e
e
e
e
m
m
e
e
v
v
e
e
n
n
t
t
o
o
<
/nome_cenario
>
<
condicao
> </condicao>
<regracomposicao
>
wrap
<
/regracomposicao>
<
pontojuncao
>1
<
/pontojuncao>
<informacoesadicionais>
Se situaçãoOK então executa(ponto junção)
Senão exi
be
(msgErro)
</informacoesadicionais>
</cenariosafetados> <cenariosafetados>
<cenarioid>
1
1
3
3
<
/cenarioid
>
<nome_cenario>
E
E
n
n
v
v
i
i
a
a
r
r
t
t
r
r
a
a
b
b
a
a
l
l
h
h
o
o
</nome_cenario>
<
condicao
> </condicao>
<regracomposicao
>
wrap
<
/regracomposicao>
<
pontojuncao
>1
<
/pontojuncao>
<informacoesadicionais>
Se situaçãoOK então executa(ponto junção)
Senão exibe
(msgErro)
</informacoesadicionais>
</cenariosafetados>
<cenariosafetados>
<cenarioid>
1
1
4
4
<
/cenarioid
>
<nome_cenario>
E
E
f
f
e
e
t
t
u
u
a
a
r
r
p
p
a
a
g
g
a
a
m
m
e
e
n
n
t
t
o
o
<
/nome_cenario
>
<
condicao
> </condicao>
<regracomposicao
>
wrap
<
/regracomposicao>
<
pontojuncao
>1
<
/pontojuncao>
<informacoesadicionais>
Se situaçãoOK então executa(ponto junção)
Senão exibe
(msgErro)
<
/infor
macoesadicionais>
</cenariosafetados>
<cenariosafetados>
<cenarioid>
1
1
5
5
<
/cenarioid
>
<nome_cenario>
E
E
n
n
v
v
i
i
a
a
r
r
p
p
a
a
l
l
e
e
s
s
t
t
r
r
a
a
</nome_cenario>
<
condicao
> </condicao>
<regracomposicao
>
wrap
<
/regracomposicao>
<
pontojuncao
>1
<
/pontojuncao>
<informacoesadicionais>
Se situaçãoOK então executa(ponto junção)
Senão exibe
(msgErro)
</informacoesadicionais>
</cenariosafetados>
<cenariosafetados>
<cenarioid>
1
1
6
6
<
/cenarioid
>
<nome_cenario>
C
C
a
a
d
d
a
a
s
s
t
t
r
r
a
a
r
r
p
p
a
a
r
r
c
c
e
e
i
i
r
r
o
o
s
s
<
/nome_cenario
>
<
condicao
> </condicao>
<regracomposicao
>
wrap
<
/regracomposicao>
<
pontojuncao
>1
<
/pontojuncao>
<informacoesadicionais>
Se situaçãoOK então executa(ponto junção)
Senão exibe
(msgErro)
</informacoesadicionais>
</cenariosafetados>
<cenariosafetados>
<cenarioid>
C
C
N
N
#
#
1
1
7
7
</cenarioid>
Anexo
C
219
<nome_cenario>
E
E
n
n
v
v
i
i
a
a
r
r
m
m
a
a
t
t
e
e
r
r
i
i
a
a
l
l
</nome_cenario>
<
condicao
> </condicao>
<regracomposicao
>
wrap
<
/regracomposicao>
<
pontojuncao
>1
<
/pontojuncao>
<informacoesadicionais>
Se situaçãoOK então executa(ponto junção)
Senão exibe
(msgErro)
</informacoesadicionais>
</cenariosafetados>
<cenariosafetados>
<cenarioid>
1
1
8
8
<
/cenarioid
>
<nome_cenario>
E
E
m
m
i
i
t
t
i
i
r
r
c
c
e
e
r
r
t
t
i
i
f
f
i
i
c
c
a
a
d
d
o
o
s
s
<
/nome_
cenario>
<
condicao
> </condicao>
<regracomposicao
>
wrap
<
/regracomposicao>
<
pontojuncao
>1
<
/pontojuncao>
<informacoesadicionais>
Se situaçãoOK então executa(ponto junção)
Senão exibe
(msgErro)
</informacoesadicionais>
<
/cena
riosafetados>
<cenariosafetados>
<cenarioid>
1
1
9
9
<
/cenarioid
>
<nome_cenario>
A
A
t
t
u
u
a
a
l
l
i
i
z
z
a
a
r
r
p
p
r
r
o
o
g
g
r
r
a
a
m
m
a
a
ç
ç
ã
ã
o
o
</nome_cenario>
<
condicao
> </condicao>
<regracomposicao
>
wrap
<
/regracomposicao>
<
pontojuncao
>1
<
/pontojuncao>
<informacoesadicionais>
Se situaçãoOK então executa(ponto junção)
Senão exibe
(msgErro)
</informacoesadicionais>
</cenariosafetados>
<cenariosafetados>
<cenarioid>
C
C
N
N
#
#
2
2
0
0
</cenarioid>
<nome_cenario>
S
S
e
e
l
l
e
e
c
c
i
i
o
o
n
n
a
a
r
r
t
t
r
r
a
a
b
b
a
a
l
l
h
h
o
o
</nome_cenario>
<
condicao
> </condicao>
<regracomposicao
>
wrap
<
/regracomposicao>
<
pontojuncao
>1
<
/pontojuncao>
<informacoesadicionais>
Se situaçãoOK então executa(ponto junção)
Senão exibe
(msgErro)
</informacoesadicionais>
<
/cenariosaf
etados>
<cenariosafetados>
<cenarioid>
2
2
1
1
<
/cenarioid
>
<nome_cenario>
F
F
o
o
r
r
n
n
e
e
c
c
e
e
r
r
r
r
e
e
c
c
u
u
r
r
s
s
o
o
s
s
<
/nome_cenario
>
<
condicao
> </condicao>
<regracomposicao
>
wrap
<
/regracomposicao>
<
pontojuncao
>1
<
/pontojuncao>
<
informac
oesadicionais>
Se situaçãoOK então executa(ponto junção)
Senão exibe
(msgErro)
</informacoesadicionais>
</cenariosafetados>
<cenariosafetados>
<cenarioid>
2
2
2
2
<
/cenarioid
>
<nome_cenario>
S
S
e
e
l
l
e
e
c
c
i
i
o
o
n
n
a
a
r
r
m
m
i
i
n
n
i
i
s
s
t
t
r
r
a
a
n
n
t
t
e
e
<
/nome_cenario
>
<
condicao
> </condicao>
<regracomposicao
>
wrap
<
/regracomposicao>
<
pontojuncao
>1
<
/pontojuncao>
<informacoesadicionais>
Se situaçãoOK então executa(ponto junção)
Senão exibe
Anexo
C
220
(msgErro)
</informacoesadicionais>
</cenariosafetados>
<cenariosafetados>
<cenarioid>
2
2
3
3
<
/cenarioid
>
<nome_cenario>
S
S
e
e
l
l
e
e
c
c
i
i
o
o
n
n
a
a
r
r
p
p
a
a
l
l
e
e
s
s
t
t
r
r
a
a
n
n
t
t
e
e
<
/nome_cenario
>
<
condicao
> </condicao>
<regracomposicao
>
wrap
<
/regracomposicao>
<
pontojuncao
>1
<
/pontojuncao>
<informacoesadici
onais
>
Se situaçãoOK então executa(ponto junção)
Senão exibe
(msgErro)
</informacoesadicionais>
</cenariosafetados>
<cenariosafetados>
<cenarioid>
2
2
4
4
<
/cenarioid
>
<nome_cenario>
E
E
m
m
i
i
t
t
i
i
r
r
c
c
r
r
a
a
c
c
h
h
á
á
s
s
<
/nome_cenario
>
<
condicao
> <
/con
dicao
>
<regracomposicao
>
wrap
<
/regracomposicao>
<
pontojuncao
>1
<
/pontojuncao>
<informacoesadicionais>
Se situaçãoOK então executa(ponto junção)
Senão exibe
(msgErro)
</informacoesadicionais>
</cenariosafetados>
<
cenariosafetad
os
>
<cenarioid>
2
2
5
5
<
/cenarioid
>
<nome_cenario>
-
-
E
E
n
n
v
v
i
i
a
a
r
r
r
r
e
e
q
q
u
u
i
i
s
s
i
i
ç
ç
ã
ã
o
o
<
/nome_cenario
>
<
condicao
> </condicao>
<regracomposicao
>
wrap
<
/regracomposicao>
<
pontojuncao
>1
<
/pontojuncao>
<informacoesadicionais>
Se situaçã
oOK então executa(ponto junção)
Senão exibe
(msgErro)
</informacoesadicionais>
</cenariosafetados>
</aspecto_candidato>
<
!
—Novo aspecto
--
>
<aspecto_candidato>
<
id
>2<
/id
>
<
nome
> Integridade </nome>
<
origem
>
RNF<
/ori
gem
>
<descricao> Garantir a atualização através de pessoal autorizado e validado
<
/descricao
>
<
!
--
Element cenariosafetados, maxOccurs=unbounded
--
>
<cenariosafetados>
<cenarioid>
1
1
</cenarioid>
<nome_cenario>
A
A
l
l
t
t
e
e
r
r
a
a
r
r
p
p
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
n
n
t
t
e
e
<
/nome_cenario
>
<
condicao
> </condicao>
<regracomposicao
>
wrap
<
/regracomposicao>
<
pontojuncao
>1
<
/pontojuncao>
<informacoesadicionais
>
Se situaçãoOK então executa(ponto junção)
Senão exibe
(msgErro)
</informacoesadicion
ais
>
</cenariosafetados>
<cenariosafetados>
<cenarioid>
2
2
</cenarioid>
<nome_cenario
>
E
E
x
x
c
c
l
l
u
u
i
i
r
r
p
p
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
n
n
t
t
e
e
<
/nome_cenario
>
Anexo
C
221
<
condicao
> </condicao>
<regracomposicao
>
wrap
<
/regracomposicao>
<
pontojuncao
>1
<
/pontojun
cao
>
<informacoesadicionais>
Se situaçãoOK então executa(ponto junção)
Senão exibe
(msgErro)
</informacoesadicionais>
</cenariosafetados>
<cenariosafetados>
<cenarioid>
2
2
</cenarioid>
<nome_cenario
>
E
E
x
x
c
c
l
l
u
u
i
i
r
r
p
p
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
n
n
t
t
e
e
<
/nome
_cenario>
<
condicao
> </condicao>
<regracomposicao
>
wrap
<
/regracomposicao>
<
pontojuncao
>1
<
/pontojuncao>
<informacoesadicionais>
Se situaçãoOK então executa(ponto junção)
Senão exibe
(msgErro)
</informacoesadicionais>
<
/cen
ariosafetados>
<cenariosafetados>
<cenarioid>
4
4
</cenarioid>
<nome_cenario>
-
-
C
C
a
a
d
d
a
a
s
s
t
t
r
r
a
a
r
r
e
e
v
v
e
e
n
n
t
t
o
o
<
/nome_cenario
>
<
condicao
> </condicao>
<regracomposicao
>
wrap
<
/regracomposicao>
<
pontojuncao
>1
<
/pontojuncao>
<
in
formacoesadicionais>
Se situaçãoOK então executa(ponto junção)
Senão exibe
(msgErro)
</informacoesadicionais>
</cenariosafetados>
<cenariosafetados>
<cenarioid>
5
5
</cenarioid>
<nome_cenario>
C
C
a
a
d
d
a
a
s
s
t
t
r
r
a
a
r
r
c
c
o
o
m
m
i
i
s
s
s
s
ã
ã
o
o
<
/nome_cenario
>
<
condicao
> </condicao>
<regracomposicao
>
wrap
<
/regracomposicao>
<
pontojuncao
>1
<
/pontojuncao>
<informacoesadicionais>
Se situaçãoOK então executa(ponto junção)
Senão exibe
(msgErro)
</informacoesadicionais>
</cenariosafetados>
<cenariosafetados>
<cenarioid>
6
6
</cenarioid>
<nome_cenario>
C
C
a
a
d
d
a
a
s
s
t
t
r
r
a
a
r
r
c
c
o
o
m
m
i
i
t
t
ê
ê
</nome_cenario>
<
condicao
> </condicao>
<regracomposicao
>
wrap
<
/regracomposicao>
<
pontojuncao
>1
<
/pontojuncao>
<informacoesadicionai
s
>
Se situaçãoOK então executa(ponto junção)
Senão exibe
(msgErro)
</informacoesadicionais>
</cenariosafetados>
<cenariosafetados>
<cenarioid>
7
7
</cenarioid>
<nome_cenario>
R
R
e
e
c
c
e
e
b
b
e
e
r
r
r
r
e
e
c
c
u
u
r
r
s
s
o
o
s
s
<
/nome_cenario
>
<
condicao
> </condic
ao
>
<regracomposicao
>
wrap
<
/regracomposicao>
<
pontojuncao
>1
<
/pontojuncao>
<informacoesadicionais>
Se situaçãoOK então executa(ponto junção)
Senão exibe
(msgErro)
</informacoesadicionais>
Anexo
C
222
</cenariosafetados>
<cenariosafetados>
<cenarioid>
8
8
</cenarioid>
<nome_cenario>
D
D
i
i
s
s
t
t
r
r
i
i
b
b
u
u
i
i
r
r
r
r
e
e
c
c
u
u
r
r
s
s
o
o
s
s
<
/nome_cenario
>
<
condicao
> </condicao>
<regracomposicao
>
wrap
<
/regracomposicao>
<
pontojuncao
>1
<
/pontojuncao>
<informacoesadicionais>
Se situaçãoOK
então executa(ponto junção)
Senão exibe
(msgErro)
</informacoesadicionais>
</cenariosafetados>
<cenariosafetados>
<cenarioid>
9
9
</cenarioid>
<nome_cenario>
P
P
a
a
g
g
a
a
r
r
f
f
o
o
r
r
n
n
e
e
c
c
e
e
d
d
o
o
r
r
</nome_cenario>
<
condicao
> </condicao>
<
regr
acomposicao
>
wrap
<
/regracomposicao>
<
pontojuncao
>1
<
/pontojuncao>
<informacoesadicionais>
Se situaçãoOK então executa(ponto junção)
Senão exibe
(msgErro)
</informacoesadicionais>
</cenariosafetados>
<cenariosafetados>
<cenario
id
>
1
1
0
0
<
/cenarioid
>
<nome_cenario>
R
R
e
e
c
c
e
e
b
b
e
e
r
r
p
p
a
a
g
g
a
a
m
m
e
e
n
n
t
t
o
o
<
/nome_cenario
>
<
condicao
> </condicao>
<regracomposicao
>
wrap
<
/regracomposicao>
<
pontojuncao
>1
<
/pontojuncao>
<informacoesadicionais>
Se situaçãoOK então executa(pon
to junção)
Senão exibe
(msgErro)
</informacoesadicionais>
</cenariosafetados> <cenariosafetados>
<cenarioid>
1
1
2
2
<
/cenarioid
>
<nome_cenario>
-
-
I
I
n
n
s
s
c
c
r
r
e
e
v
v
e
e
r
r
-
-
s
s
e
e
e
e
m
m
e
e
v
v
e
e
n
n
t
t
o
o
<
/nome_cenario
>
<
condicao
> </condicao>
<regracomposicao
>
wrap
<
/regracomposicao>
<
pontojuncao
>1
<
/pontojuncao>
<informacoesadicionais>
Se situaçãoOK então executa(ponto junção)
Senão exibe
(msgErro)
</informacoesadicionais>
</cenariosafetados> <cenariosafetados>
<cenarioid>
1
1
3
3
<
/cena
rioid>
<nome_cenario>
E
E
n
n
v
v
i
i
a
a
r
r
t
t
r
r
a
a
b
b
a
a
l
l
h
h
o
o
</nome_cenario>
<
condicao
> </condicao>
<regracomposicao
>
wrap
<
/regracomposicao>
<
pontojuncao
>1
<
/pontojuncao>
<informacoesadicionais>
Se situaçãoOK então executa(ponto junção)
Sen
ão exibe
(msgErro)
</informacoesadicionais>
</cenariosafetados>
<cenariosafetados>
<cenarioid>
1
1
4
4
<
/cenarioid
>
<nome_cenario>
E
E
f
f
e
e
t
t
u
u
a
a
r
r
p
p
a
a
g
g
a
a
m
m
e
e
n
n
t
t
o
o
<
/nome_cenario
>
<
condicao
> </condicao>
<regracomposicao
>
wrap
<
/regracomposi
cao
>
<
pontojuncao
>1
<
/pontojuncao>
Anexo
C
223
<informacoesadicionais>
Se situaçãoOK então executa(ponto junção)
Senão exibe
(msgErro)
</informacoesadicionais>
</cenariosafetados>
<cenariosafetados>
<cenarioid>
1
1
5
5
<
/cenarioid
>
<nome_cenario>
E
E
n
n
v
v
i
i
a
a
r
r
p
p
a
a
l
l
e
e
s
s
t
t
r
r
a
a
</nome_cenario>
<
condicao
> </condicao>
<regracomposicao
>
wrap
<
/regracomposicao>
<
pontojuncao
>1
<
/pontojuncao>
<informacoesadicionais>
Se situaçãoOK então executa(ponto junção)
Senão exibe
(msgErro)
</informacoesadicionais>
</cenariosafetados>
<cenariosafetados>
<cenarioid>
C
C
N
N
#
#
1
1
6
6
</cenarioid>
<nome_cenario>
C
C
a
a
d
d
a
a
s
s
t
t
r
r
a
a
r
r
p
p
a
a
r
r
c
c
e
e
i
i
r
r
o
o
s
s
<
/nome_cenario
>
<
condicao
> </condicao>
<regracomposicao
>
wrap
<
/regracomposicao>
<
pontojuncao
>1
<
/pontojuncao>
<informacoesadicionais>
Se situaçãoOK então executa(ponto junção)
Senão exibe
(msgErro)
</informacoesadicionais>
</cenariosafetados>
<cenariosafetados>
<cenarioid>
1
1
7
7
<
/cenarioid
>
<nome_cenario>
E
E
n
n
v
v
i
i
a
a
r
r
m
m
a
a
t
t
e
e
r
r
i
i
a
a
l
l
</nome_cenario>
<
condicao
> </condicao>
<regracomposicao
>
wrap
<
/regracomposicao>
<
pontojuncao
>1
<
/pontojuncao>
<informacoesadicionais>
Se situaçãoOK então executa(ponto junção)
Senão exibe
(msgErro)
</informacoesadicionais>
</cenariosafetados>
<cenariosafetados>
<cenarioid>
1
1
8
8
<
/cenarioid
>
<nome_cenario>
E
E
m
m
i
i
t
t
i
i
r
r
c
c
e
e
r
r
t
t
i
i
f
f
i
i
c
c
a
a
d
d
o
o
s
s
<
/nome_cenario
>
<
condicao
> </condicao>
<regracomposicao
>
wrap
<
/regracomposicao>
<
pontojuncao
>1
<
/pontojuncao>
<informacoesadicionais>
Se situaçãoOK então executa(ponto junção)
Senão exibe
(msgErro)
</informacoesadicionais>
</cenariosafetados>
<cenariosafetados>
<cenarioid>
1
1
9
9
<
/cenarioid
>
<nome_cenario>
A
A
t
t
u
u
a
a
l
l
i
i
z
z
a
a
r
r
p
p
r
r
o
o
g
g
r
r
a
a
m
m
a
a
ç
ç
ã
ã
o
o
</nome_cenario>
<
condicao
> </condicao>
<regracomposicao
>
wrap
<
/regracomposicao>
<
pontojuncao
>1
<
/pontojuncao>
<informacoesadicionais>
Se situaçãoOK então executa(ponto junção)
Senão exibe
(msgErro)
</informacoesadicionai
s
>
</cenariosafetados>
<cenariosafetados>
<cenarioid>
2
2
0
0
</cenarioid>
Anexo
C
224
<nome_cenario>
S
S
e
e
l
l
e
e
c
c
i
i
o
o
n
n
a
a
r
r
t
t
r
r
a
a
b
b
a
a
l
l
h
h
o
o
</nome_cenario>
<
condicao
> </condicao>
<regracomposicao
>
wrap
<
/regracomposicao>
<
pontojuncao
>1
<
/pontojuncao>
<informacoesadicionais>
Se situaçãoOK então executa(ponto junção)
Senão exibe
(msgErro)
</informacoesadicionais>
</cenariosafetados>
<cenariosafetados>
<cenarioid>
2
2
1
1
<
/cenarioid
>
<nome_cenario>
F
F
o
o
r
r
n
n
e
e
c
c
e
e
r
r
r
r
e
e
c
c
u
u
r
r
s
s
o
o
s
s
</nome_ce
nario
>
<
condicao
> </condicao>
<regracomposicao
>
wrap
<
/regracomposicao>
<
pontojuncao
>1
<
/pontojuncao>
<informacoesadicionais>
Se situaçãoOK então executa(ponto junção)
Senão exibe
(msgErro)
</informacoesadicionais>
<
/cenari
osafetados>
<cenariosafetados>
<cenarioid>
C
C
N
N
#
#
2
2
2
2
</cenarioid>
<nome_cenario>
S
S
e
e
l
l
e
e
c
c
i
i
o
o
n
n
a
a
r
r
m
m
i
i
n
n
i
i
s
s
t
t
r
r
a
a
n
n
t
t
e
e
<
/nome_cenario
>
<
condicao
> </condicao>
<regracomposicao
>
wrap
<
/regracomposicao>
<
pontojuncao
>1
<
/pontojuncao>
<informacoesadicionais>
Se situaçãoOK então executa(ponto junção)
Senão exibe
(msgErro)
</informacoesadicionais>
</cenariosafetados>
<cenariosafetados>
<cenarioid>
2
2
3
3
<
/cenarioid
>
<nome_cenario>
S
S
e
e
l
l
e
e
c
c
i
i
o
o
n
n
a
a
r
r
p
p
a
a
l
l
e
e
s
s
t
t
r
r
a
a
n
n
t
t
e
e
<
/nome_cenari
o>
<
condicao
> </condicao>
<regracomposicao
>
wrap
<
/regracomposicao>
<
pontojuncao
>1
<
/pontojuncao>
<informacoesadicionais>
Se situaçãoOK então executa(ponto junção)
Senão exibe
(msgErro)
</informacoesadicionais>
<
/cenariosaf
etados>
<cenariosafetados>
<cenarioid>
2
2
4
4
<
/cenarioid
>
<nome_cenario>
E
E
m
m
i
i
t
t
i
i
r
r
c
c
r
r
a
a
c
c
h
h
á
á
s
s
<
/nome_cenario
>
<
condicao
> </condicao>
<regracomposicao
>
wrap
<
/regracomposicao>
<
pontojuncao
>1
<
/pontojuncao>
<
informacoes
adicionais>
Se situaçãoOK então executa(ponto junção)
Senão exibe
(msgErro)
</informacoesadicionais>
</cenariosafetados>
<cenariosafetados>
<cenarioid>
2
2
5
5
<
/cenarioid
>
<nome_cenario>
-
-
E
E
n
n
v
v
i
i
a
a
r
r
r
r
e
e
q
q
u
u
i
i
s
s
i
i
ç
ç
ã
ã
o
o
<
/nome_cenario
>
<
condicao
> </condicao>
<regracomposicao
>
wrap
<
/regracomposicao>
<
pontojuncao
>1
<
/pontojuncao>
<informacoesadicionais>
Se situaçãoOK então executa(ponto junção)
Senão exibe
Anexo
C
225
(msgErro)
</informacoesadicionais>
</cenariosafetados>
<
/aspe
cto_candidato>
<
!
—
novo aspecto
--
>
<aspecto_candidato>
<
id
>3<
/id
>
<
nome
> CPF_Cliente
<
/nome
>
<
origem
>
RF
<
/origem
>
<descricao> Verificar se o cliente esta com obrigações em dia
<
/descricao
>
<
!
--
Element cenariosafetados, maxOccurs=unbounded
--
>
<cenariosafetados>
<cenarioid>
1
1
2
2
<
/cenarioid
>
<nome_cenario>
I
I
n
n
s
s
c
c
r
r
e
e
v
v
e
e
r
r
-
-
s
s
e
e
e
e
m
m
e
e
v
v
e
e
n
n
t
t
o
o
<
/nome_cenario
>
<
condicao
> </condicao>
<regracomposicao
>
wrap
</regracomposicao>
<
pontojunca
o>3
<
/pontojuncao>
<informacoesadicionais
>
Se situaçãoOK então executa(ponto junção)
Senão exibe
(msgErro)
</informacoesadicionais>
</cenariosafetados>
</aspecto_candidato>
<
!
—
novo aspecto
--
>
<aspecto_candidato>
<
id
>4<
/i
d>
<
nome
> Validar situaçao
<
/nome
>
<
origem
>
RO
<
/origem
>
<descricao> Verificar se cliente VIP
<
/descricao
>
<
!
--
Element cenariosafetados, maxOccurs=unbounded
--
>
<cenariosafetados>
<cenarioid>
1
1
2
2
<
/cenarioid
>
<nome_cenario>
I
I
n
n
s
s
c
c
r
r
e
e
v
v
e
e
r
r
-
-
s
s
e
e
e
e
m
m
e
e
v
v
e
e
n
n
t
t
o
o
<
/nome_cenario
>
<
condicao
> </condicao>
<regracomposicao
>
overlap.after
</regracomposicao>
<
pontojuncao
>3
<
/pontojuncao>
<informacoesadicionais
>
Se executa(ponto junção)
então
aplicardesc
onto() Senão verificar
potencial()
<
/informacoesadicionais>
</cenariosafetados>
<
!
--
Element cenariosafetados, maxOccurs=unbounded
--
>
<cenariosafetados>
<cenarioid>
1
1
4
4
</cenarioid>
<nome_cenario>
E
E
f
f
e
e
t
t
u
u
a
a
r
r
p
p
a
a
g
g
a
a
m
m
e
e
n
n
t
t
o
o
<
/nome_cenario
>
<
condicao
> </condicao>
<regracomposicao
>
overlap.
before
</regracomposicao>
<
pontojuncao
>3
<
/pontojuncao>
<informacoesadicionais
>
Se executa(ponto junção)
então
aplicardesconto() Senão verificar
potencial()
<
/informacoesadicionais>
</cenariosafetados>
</aspecto_candidato>
<
/Aspectos
>
Anexo
C
226
S
S
i
i
m
m
b
b
o
o
l
l
o
o
s
s
.
.
x
x
m
m
l
l
<?xml version="1.0"?>
<
Projeto
xmlns:xsi=
"http://www.w3.org/2001/XMLSchema
-
instance"
xsi:noNamespaceSchemaLocation="file:///f:/Luciana/tese_uem/tese/Monografia/LELSimb
ol
os.xsd">
<
id_projeto
>1</id_projeto>
<
dominio
>
comunicaçao</dominio>
<nome_projeto
>
Eventos
</nome_projeto>
<
descricao
>Controle e gerencia de eventos cientificos<
/descricao
>
<
LEL
>
<
id_simbolo
>1
<
/id_simbolo>
<
nome_simbolo
>
sec
retaria</nome_simbolo>
<
categoria
>
sujeito
<
/categoria>
<
sinonimos
>
<
alias
>
secretaria<
/alias
>
<
alias
>
auxiliar
<
/alias
>
1.
<
/sinonimos
>
<
nocoes
>
<
id_nocao
>1</id_nocao>
<descricao_nocao>
Pessoa que auxilia na gerencia do evento
</descricao_nocao>
<
/nocoes
>
<
impactos
>
<
id_impacto
>1
<
/id_impacto>
<descricao_impacto>
c
c
a
a
d
d
a
a
s
s
t
t
r
r
a
a
r
r
c
c
l
l
i
i
e
e
n
n
t
t
e
e
<
/descricao_impacto
>
<
id_impacto
>2<
/id_impacto>
<descricao_impacto>
c
c
o
o
n
n
s
s
u
u
l
l
t
t
a
a
e
e
v
v
e
e
n
n
t
t
o
o
s
s
e
e
m
m
a
a
b
b
e
e
r
r
t
t
o
o
<
/descricao_impacto
>
<
id_impacto
>3<
/id_impacto>
<descricao_impacto>
c
c
o
o
n
n
s
s
u
u
l
l
t
t
a
a
e
e
v
v
e
e
n
n
t
t
o
o
s
s
f
f
e
e
c
c
h
h
a
a
d
d
o
o
s
s
<
/descricao_impacto
>
<
id_impacto
>4<
/id_impacto>
<descricao_impacto>
a
a
l
l
t
t
e
e
r
r
a
a
r
r
p
p
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
n
n
t
t
e
e
<
/descricao_impacto
>
<
id_impacto
>5<
/id_impacto>
<descricao_impacto>
e
e
x
x
c
c
l
l
u
u
i
i
r
r
p
p
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
n
n
t
t
e
e
<
/descricao_impacto
>
<
id_impacto
>6<
/id_impacto>
<descricao_impacto>
c
c
o
o
n
n
s
s
u
u
l
l
t
t
a
a
r
r
p
p
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
n
n
t
t
e
e
s
s
<
/desc
ricao_impacto
>
<
id_impacto
>7<
/id_impacto>
<descricao_impacto>
c
c
a
a
d
d
a
a
s
s
t
t
r
r
a
a
r
r
e
e
v
v
e
e
n
n
t
t
o
o
s
s
<
/descricao_impacto
>
<
id_impacto
>8<
/id_impacto>
<descricao_impacto
>
c
c
a
a
d
d
a
a
s
s
t
t
r
r
a
a
r
r
c
c
o
o
m
m
i
i
s
s
s
s
ã
ã
o
o
<
/descricao_impacto
>
<
id_impact
o
>9<
/id_impacto>
<descricao_impacto
>
c
c
a
a
d
d
a
a
s
s
t
t
r
r
a
a
r
r
c
c
o
o
m
m
i
i
t
t
ê
ê
<
/descricao_impacto
>
<
id_impacto
>10<
/id_impacto>
<descricao_impacto>
r
r
e
e
c
c
e
e
b
b
e
e
r
r
r
r
e
e
c
c
u
u
r
r
s
s
o
o
s
s
<
/descricao_impacto
>
<
id_impacto
>11<
/id_impacto>
<
descrica
o_impacto
>
p
p
a
a
g
g
a
a
r
r
f
f
o
o
r
r
n
n
e
e
c
c
e
e
d
d
o
o
r
r
<
/descricao_impacto
>
<
id_impacto
>12<
/id_impacto>
<descricao_impacto>
d
d
i
i
s
s
t
t
r
r
i
i
b
b
u
u
i
i
r
r
r
r
e
e
c
c
u
u
r
r
s
s
o
o
s
s
<
/descricao_impacto
>
<
id_impacto
>13<
/id_impacto>
<descricao_impacto
>
r
r
e
e
c
c
e
e
b
b
e
e
r
r
p
p
a
a
g
g
a
a
m
m
e
e
n
n
t
t
o
o
<
/descr
icao_impacto
>
Anexo
C
227
<
/impactos
>
<
/LEL
>
<
LEL
>
<
id_simbolo
>2
<
/id_simbolo>
<
nome_simbolo
>
participante
</nome_simbolo>
<
categoria
>
sujeito
<
/categoria>
<
sinonimos
>
<
alias
>participantes
<
/alias
>
<
/sinoni
mos
>
<
nocoes
>
<
id_nocao
>1</id_nocao>
<descricao_nocao>
P
P
e
e
s
s
s
s
o
o
a
a
q
q
u
u
e
e
p
p
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
d
d
e
e
u
u
m
m
e
e
v
v
e
e
n
n
t
t
o
o
c
c
o
o
m
m
o
o
:
:
o
o
u
u
v
v
i
i
n
n
t
t
e
e
,
,
a
a
p
p
r
r
e
e
s
s
e
e
n
n
t
t
a
a
d
d
o
o
r
r
,
,
p
p
a
a
l
l
e
e
s
s
t
t
r
r
a
a
n
n
t
t
e
e
,
,
m
m
i
i
n
n
i
i
s
s
t
t
r
r
a
a
n
n
t
t
e
e
</descricao_nocao
>
<
/nocoes
>
<
impactos
>
<
id_impacto
>1
<
/id_impacto>
<descricao_impacto>
c
c
o
o
n
n
s
s
u
u
l
l
t
t
a
a
e
e
v
v
e
e
n
n
t
t
o
o
s
s
e
e
m
m
a
a
b
b
e
e
r
r
t
t
o
o
<
/descricao_impacto
>
<
id_impacto
>2<
/id_impacto>
<descricao_impacto>
c
c
o
o
n
n
s
s
u
u
l
l
t
t
a
a
e
e
v
v
e
e
n
n
t
t
o
o
s
s
f
f
e
e
c
c
h
h
a
a
d
d
o
o
s
s
</descricao_impacto
>
<
id_impacto
>3<
/id_impacto>
<descricao_impacto>
c
c
o
o
n
n
s
s
u
u
l
l
t
t
a
a
r
r
p
p
r
r
o
o
g
g
r
r
a
a
m
m
a
a
ç
ç
a
a
o
o
<
/descricao_impacto
>
</
impactos
>
<
/LEL
>
<
!
—Os outros Elementos
do LEL
foram suprimidos para que ficasse menor o
arquivo
--
>
<
/Projeto
>
Anexo
C
228
C
C
e
e
n
n
a
a
r
r
i
i
o
o
s
s
.
.
x
x
m
m
l
l
<?xml version="1.0"?>
<
Projeto
xmlns:x
si=
"http://www.w3.org/2001/XMLSchema
-
instance"
xsi:noNamespaceSchemaLocation="file:///f:/Luciana/tese_uem/tese/Monografia/LELCena
rio.xsd"
>
<
id_projeto
>1</id_projeto>
<
dominio
>
comunicacao</dominio>
<nome_projeto
>
Eventos
</nome_projeto>
<
descr
icao
>
Controle e gerencia de eventos cientificos <
/descricao
>
<
cenarios
>
<
Tipo_mdsodi
>
paralelo
</Tipo_mdsodi>
<cenarioid>1</cenarioid>
<
titulo
>
C
C
o
o
n
n
s
s
u
u
l
l
t
t
a
a
r
r
e
e
v
v
e
e
n
n
t
t
o
o
s
s
e
e
m
m
a
a
b
b
e
e
r
r
t
t
o
o</titulo>
<objetivo>
P
P
r
r
o
o
c
c
e
e
d
d
i
i
m
m
e
e
n
n
t
t
o
o
p
p
a
a
r
r
a
a
q
q
u
u
a
a
n
n
d
d
o
o
d
d
e
e
s
s
e
e
j
j
a
a
-
-
s
s
e
e
c
c
o
o
n
n
h
h
e
e
c
c
e
e
r
r
t
t
o
o
d
d
o
o
s
s
o
o
s
s
e
e
v
v
e
e
n
n
t
t
o
o
s
s
q
q
u
u
e
e
e
e
s
s
t
t
ã
ã
o
o
e
e
m
m
a
a
b
b
e
e
r
r
t
t
o
o</objetivo>
<
contexto
>
<
texto
>
S
S
i
i
s
s
t
t
e
e
m
m
a
a
e
e
m
m
i
i
t
t
i
i
n
n
d
d
o
o
c
c
o
o
n
n
s
s
u
u
l
l
t
t
a
a
d
d
e
e
e
e
v
v
e
e
n
n
t
t
o
o
s
s
e
e
m
m
a
a
b
b
e
e
r
r
t
t
o
o<
/texto
>
</contexto>
<
atores
>
<
nome
>
s
s
e
e
c
c
r
r
e
e
t
t
á
á
r
r
i
i
a
a
</nome>
<
tipo_ator
>
prim
ario
</tipo_ator>
<
/atores
>
<
atores
>
<
nome
>
p
p
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
n
n
t
t
e
e
<
/nome
>
<
tipo_ator
>primario</tipo_ator>
<
/atores
>
<
atores
>
<
nome
>
p
p
a
a
r
r
c
c
e
e
i
i
r
r
o
o
s
s
<
/nome
>
<
tipo_ator
>secundario
<
/tipo_ator>
<
/atores
>
<
atores
>
<
nome
>
c
c
l
l
i
i
e
e
n
n
t
t
e
e
s
s
i
i
n
n
c
c
l
l
u
u
i
i
d
d
o
o
s
s
<
/nome
>
<
tipo_ator
>primario</tipo_ator>
<
/atores
>
<
atores
>
<
nome
>
c
c
l
l
i
i
e
e
n
n
t
t
e
e
s
s
</nome>
<
tipo_ator
>secundario
<
/tipo_ator>
<
/atores
>
<
recursos
>
<descricao>
evento
<
/descricao
>
<
/recursos
>
<episodios>
<
texto
>
S
S
i
i
s
s
t
t
e
e
m
m
a
a
e
e
x
x
i
i
b
b
e
e
e
e
v
v
e
e
n
n
t
t
o
o
s
s
e
e
m
m
a
a
b
b
e
e
r
r
t
t
o
o <
/texto
>
<RNFEspecifico>
<
texto
><
/texto
>
<
estrategia
><
/es
trategia
>
</RNFEspecifico>
<ExpressaoOCL>
<
texto
> <
/texto
>
Anexo
C
229
<
/ExpressaoOCL
>
<
Rorg
>
<
texto
><
/texto
>
<
estrategia
><
/estrategia
>
<
/Rorg
>
</episod
ios
>
<
/cenarios
>
<
!
—Os outros elementos foram suprimidos
--
>
<
/Projeto
>
Anexo
C
230
O
O
n
n
t
t
o
o
l
l
o
o
g
g
i
i
a
a
.
.
x
x
m
m
l
l
<?xml version="1.0"?>
<ontologias xmlns:xsi="http://www.w3.org/2001/XMLSchema
-
instance"
xsi:noNamespaceSchemaLocation="file:///f:/Luciana/tese_uem/tese/Monografia/ontologia
.xsd"
>
<
projeto
>E
ventos
<
/projeto
>
<
classe
>
<
nome
>apresentador
<
/nome
>
<descricao>
Cliente inscrito para apresentar trabalho </descricao>
<
restricao
><
/restricao>
<
nome
>trabalho
<
/nome
>
<
descr
icao
>
A
A
r
r
t
t
i
i
g
g
o
o
s
s
a
a
s
s
e
e
r
r
e
e
m
m
a
a
p
p
r
r
e
e
s
s
e
e
n
n
t
t
a
a
d
d
o
o
s
s
e
e
m
m
u
u
m
m
e
e
v
v
e
e
n
n
t
t
o
o
<
/descricao
>
<
restricao
><
/restricao>
<
nome
>
comite
<
/nome
>
<descricao>
G
G
r
r
u
u
p
p
o
o
d
d
e
e
p
p
e
e
s
s
s
s
o
o
a
a
s
s
s
s
e
e
l
l
e
e
c
c
i
i
o
o
n
n
a
a
d
d
a
a
s
s
p
p
a
a
r
r
a
a
s
s
e
e
l
l
e
e
c
c
i
i
o
o
n
n
a
a
r
r
o
o
s
s
t
t
r
r
a
a
b
b
a
a
l
l
h
h
o
o
s
s
a
a
p
p
r
r
e
e
s
s
e
e
n
n
t
t
a
a
d
d
o
o
s
s
n
n
o
o
e
e
v
v
e
e
n
n
t
t
o
o
<
/descricao
>
<
restricao
><
/
restricao>
<
nome
>participante<
/nome
>
<descricao>
P
P
e
e
s
s
s
s
o
o
a
a
q
q
u
u
e
e
p
p
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
d
d
e
e
u
u
m
m
e
e
v
v
e
e
n
n
t
t
o
o
c
c
o
o
m
m
o
o
:
:
o
o
u
u
v
v
i
i
n
n
t
t
e
e
,
,
a
a
p
p
r
r
e
e
s
s
e
e
n
n
t
t
a
a
d
d
o
o
r
r
,
,
p
p
a
a
l
l
e
e
s
s
t
t
r
r
a
a
n
n
t
t
e
e
,
,
m
m
i
i
n
n
i
i
s
s
t
t
r
r
a
a
n
n
t
t
e
e
<
/descricao
>
<
restricao
><
/restricao>
<
nome
>
evento
<
/nome
>
<descricao>
C
C
o
o
n
n
f
f
e
e
r
r
e
e
n
n
c
c
i
i
a
a
o
o
u
u
W
W
o
o
r
r
k
k
s
s
h
h
o
o
p
p
a
a
s
s
e
e
r
r
g
g
e
e
r
r
e
e
n
n
c
c
i
i
a
a
d
d
o
o
p
p
e
e
l
l
a
a
e
e
m
m
p
p
r
r
e
e
s
s
a
a
.
.
C
C
a
a
d
d
a
a
e
e
v
v
e
e
n
n
t
t
o
o
p
p
o
o
s
s
s
s
u
u
i
i
u
u
m
m
p
p
e
e
r
r
í
í
o
o
d
d
o
o
d
d
e
e
r
r
e
e
a
a
l
l
i
i
z
z
a
a
ç
ç
ã
ã
o
o
<
/descricao
>
<
restricao
><
/restricao>
<
nome
>cliente inscrito
<
/nome
>
<descricao>
P
P
e
e
s
s
s
s
o
o
a
a
q
q
u
u
e
e
s
s
o
o
l
l
i
i
c
c
i
i
t
t
o
o
u
u
o
o
c
c
a
a
d
d
a
a
s
s
t
t
r
r
o
o
e
e
f
f
o
o
i
i
a
a
p
p
r
r
o
o
v
v
a
a
d
d
a
a
,
,
r
r
e
e
c
c
e
e
b
b
e
e
n
n
d
d
o
o
o
o
s
s
e
e
u
u
l
l
o
o
g
g
i
i
n
n
e
e
s
s
e
e
n
n
h
h
a
a
<
/descricao
>
<
restricao
><
/restricao>
<
nome
>programacao
<
/nome
>
<descricao>
C
C
r
r
o
o
n
n
o
o
g
g
r
r
a
a
m
m
a
a
a
a
s
s
e
e
r
r
c
c
u
u
m
m
p
p
r
r
i
i
d
d
o
o
d
d
o
o
e
e
v
v
e
e
n
n
t
t
o
o
.
.
C
C
o
o
n
n
t
t
e
e
m
m
a
a
s
s
p
p
a
a
l
l
e
e
s
s
t
t
r
r
a
a
s
s
,
,
t
t
r
r
a
a
b
b
a
a
l
l
h
h
o
o
s
s
e
e
c
c
u
u
r
r
s
s
o
o
s
s
a
a
s
s
e
e
r
r
e
e
m
m
a
a
p
p
r
r
e
e
s
s
e
e
n
n
t
t
a
a
d
d
o
o
s
s
n
n
o
o
e
e
v
v
e
e
n
n
t
t
o
o
<
/descricao
>
<
restricao
><
/res
tricao
>
<
nome
>
comissao
<
/nome
>
<descricao>
:
G
G
r
r
u
u
p
p
o
o
d
d
e
e
p
p
e
e
s
s
s
s
o
o
a
a
s
s
s
s
e
e
l
l
e
e
c
c
i
i
o
o
n
n
a
a
d
d
a
a
s
s
p
p
a
a
r
r
a
a
g
g
e
e
r
r
e
e
n
n
c
c
i
i
a
a
r
r
o
o
e
e
v
v
e
e
n
n
t
t
o
o
<
/descricao
>
<
restricao
><
/restricao>
<
nome
>
ministrante
</nome>
<descricao>
Cliente inscrito para ministrar curso <
/desc
ricao
>
<
restricao
><
/restricao>
<
nome
>
material
<
/nome
>
<descricao>
O
O
m
m
a
a
t
t
e
e
r
r
i
i
a
a
l
l
r
r
e
e
f
f
e
e
r
r
e
e
n
n
t
t
e
e
a
a
o
o
c
c
u
u
r
r
s
s
o
o
a
a
s
s
e
e
r
r
m
m
i
i
n
n
i
i
s
s
t
t
r
r
a
a
d
d
o
o
e
e
m
m
u
u
m
m
e
e
v
v
e
e
n
n
t
t
o
o
<
/descricao
>
<
restricao
><
/restricao>
<
nome
>
requisicao
<
/nome
>
<descricao>
Documento que contem referencias aos recursos materiais necessários
para realizar a tarefa
<
/descricao
>
<
restricao
><
/restricao>
<
nome
>palestrante</nome>
<descricao>
Cliente inscrito para ministrar palestra <
/descricao
>
Anexo
C
231
<
restricao
><
/re
stricao
>
<
nome
>
palestra
<
/nome
>
<descricao>Slides referentes a um assunto a ser apresentado no evento
<
/descricao
>
<
restricao
><
/restricao>
<
nome
>
crachá
<
/nome
>
<descricao>
I
I
d
d
e
e
n
n
t
t
i
i
f
f
i
i
c
c
a
a
ç
ç
ã
ã
o
o
d
d
o
o
p
p
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
n
n
t
t
e
e
d
d
o
o
e
e
v
v
e
e
n
n
t
t
o
o <
/desc
ricao>
<
restricao
><
/restricao>
<
nome
>certificado
<
/nome
>
<descricao>
C
C
o
o
m
m
p
p
r
r
o
o
v
v
a
a
n
n
t
t
e
e
d
d
e
e
p
p
a
a
r
r
t
t
i
i
c
c
i
i
p
p
a
a
ç
ç
ã
ã
o
o
d
d
o
o
e
e
v
v
e
e
n
n
t
t
o
o
<
/descricao
>
<
restricao
><
/restricao>
<
nome
>patrocinador</nome>
<descricao>
E
E
m
m
p
p
r
r
e
e
s
s
a
a
q
q
u
u
e
e
f
f
o
o
r
r
n
n
e
e
c
c
e
e
m
m
r
r
e
e
c
c
u
u
r
r
s
s
o
o
s
s
f
f
i
i
n
n
a
a
n
n
c
c
e
e
i
i
r
r
o
o
s
s
p
p
a
a
r
r
a
a
a
a
r
r
e
e
a
a
l
l
i
i
z
z
a
a
ç
ç
ã
ã
o
o
d
d
o
o
e
e
v
v
e
e
n
n
t
t
o
o
<
/descricao
>
<
restricao
><
/restricao>
<
nome
>recursos</nome>
<descricao>
São materiais necessários para a realização e elaboração do
evento
.
<
/descricao
>
<
restricao
><
/restricao>
<
nome
>pagamento</nome>
<descricao>
Comprovante de quitação com o
evento
</descricao>
<
restricao
> Podem ser: financeiro, humano e material </restricao>
<
nome
>ouvinte</nome>
<descricao>
Cliente inscrito para assistir aos cursos, palestras e apresentações do evento
<
/descricao
>
<
restricao
><
/restricao>
<
nome
>
cliente
<
/nome
>
<descricao>
:
P
P
e
e
s
s
s
s
o
o
a
a
q
q
u
u
e
e
a
a
i
i
n
n
d
d
a
a
n
n
ã
ã
o
o
s
s
o
o
l
l
i
i
c
c
i
i
t
t
o
o
u
u
o
o
c
c
a
a
d
d
a
a
s
s
t
t
r
r
o
o
,
,
a
a
p
p
e
e
n
n
a
a
s
s
c
c
l
l
i
i
e
e
n
n
t
t
e
e
e
e
m
m
p
p
o
o
t
t
e
e
n
n
c
c
i
i
a
a
l
l
<
/descricao
>
<
restricao
><
/restricao>
<
nome
>
inscricao
<
/nome
>
<descricao>
I
I
d
d
e
e
n
n
t
t
i
i
f
f
i
i
c
c
a
a
ç
ç
ã
ã
o
o
d
d
e
e
u
u
m
m
c
c
l
l
i
i
e
e
n
n
t
t
e
e
q
q
u
u
a
a
n
n
d
d
o
o
d
d
e
e
s
s
e
e
j
j
a
a
f
f
a
a
z
z
e
e
r
r
s
s
e
e
u
u
c
c
a
a
d
d
a
a
s
s
t
t
r
r
o
o
<
/descricao
>
<
restricao
><
/restricao>
<
nome
>secretaria</nome>
<descricao>
P
P
e
e
s
s
s
s
o
o
a
a
q
q
u
u
e
e
a
a
u
u
x
x
i
i
l
l
i
i
a
a
n
n
o
o
g
g
e
e
r
r
e
e
n
n
c
c
i
i
a
a
m
m
e
e
n
n
t
t
o
o
d
d
o
o
e
e
v
v
e
e
n
n
t
t
o
o
<
/d
escricao>
<
restricao
><
/restricao>
<
nome
>
fornecedor
</nome>
<descricao>
E
E
m
m
p
p
r
r
e
e
s
s
a
a
q
q
u
u
e
e
f
f
o
o
r
r
n
n
e
e
c
c
e
e
r
r
e
e
c
c
u
u
r
r
s
s
o
o
s
s
(
(
m
m
a
a
t
t
e
e
r
r
i
i
a
a
i
i
s
s
o
o
u
u
h
h
u
u
m
m
a
a
n
n
o
o
s
s
)
)
p
p
a
a
r
r
a
a
a
a
r
r
e
e
a
a
l
l
i
i
z
z
a
a
ç
ç
ã
ã
o
o
d
d
o
o
e
e
v
v
e
e
n
n
t
t
o
o
<
/descricao
>
<
restricao
><
/restricao>
<
/classe
>
<
nome
> Aberto<
/
nome
>
<descricao>
são os eventos que possuem o período de realização maior ou igual do
que a data atual
</descricao>
<
restricao
> subClasseOf: tipo
-
evento
</restricao>
<
nome
> fechado</nome>
<descricao>
são os eventos que possuem o período de realização menor do que a data
Anexo
C
232
atual
<
/descricao
>
<
restricao
> subClasseOf: tipo
-
evento
</restricao>
<
nome
> Tipo
-
Evento
</nome>
<descricao>
conjunto dos estados possíveis em que o evento pode estar no
momento.Partição de valor.</descricao>
<
restricao
> <
/restricao>
<propriedade>
<
nome
>
é-
enviado
<
/nome
>
<
nome
>
é-
selecionado
</nome>
<
nome
>
é-
apresentado
<
/nome
>
<
nome
>
é-
alterado
<
/nome
>
<
nome
>
é-
consultado
<
/nome
>
<
nome
>
é-
inscrito
</nome>
<
nome
>
é-
elaborado
</nome>
<
nome
>
é-
enviado
<
/nome
>
<
nome
>
é-
emitido
</nome>
<
nome
>
é-
fornecido
</nome>
<
nome
>
é-
pago
<
/nome
>
<
nome
>
é-
solicitado
</nome>
<
nome
>
é-
excluído
<
/nome
>
<
nome
>
é-
distribuído
<
/nome
>
</propriedade>
<
axioma
>
<descricao> Trabalho pode ser: full, short, poster </descricao>
<
/axioma
>
<
/ontologias
>
Anexo
C
233
h
h
i
i
e
e
r
r
a
a
r
r
q
q
u
u
i
i
a
a
.
.
x
x
m
m
l
l
<?xml version="1.0"?>
<
ontohierarquia
xmlns:xsi=
"http://www.w3.org/2001/XMLSchema
-
instance"
xsi:noNamespaceSchemaLocation="file:///f:/Luciana/tese_uem/tese/Monografia/ontohiera
rquia.xsd">
<
projeto
>
Eventos
</
projeto
>
<
classepai
>
<
nome
> Parceiros </nome>
<classefilho>
fornecedor
</classefilho>
<
c
lassefilho
> patrocidador
<
/classefilho
>
<
nome
> Cliente </nome>
<classefilho> cliente inscrito
<
/classefilho
>
<classefilho>
cliente
<
/classefilho
>
<classefilho> participante (ouvinte, palestrante, apresentador,
ministrante)
<
/
classefilho>
<
nome
>
Recursos
<
/nome
>
<classefilho> materiais ou humanos </classefilho>
<classefilho>
financeiros
</classefilho>
<
nome
> Material_evento</nome>
<classefilho>
palestra
<
/classefilho
>
<classefilho>
curso
<
/classefilho
>
<classefilho> apresentação
<
/classefilho
>
<classefilho>
requisição
<
/classefilho
>
<
nome
> Grupo_trabalho</nome>
<classefilho> secretária </classefilho>
<classefilho>
comitê
<
/classefilho
>
<classefilho>
comissão
<
/classefilho
>
<
nome
> Objetos_evento</nome>
<classefilho>
crachá
<
/classefilho
>
<classefilho> certificado </classefilho>
<classefilho> programação
<
/classefilho
>
<
/classepai
>
</ontohierarquia>
Livros Grátis
( http://www.livrosgratis.com.br )
Milhares de Livros para Download:
Baixar livros de Administração
Baixar livros de Agronomia
Baixar livros de Arquitetura
Baixar livros de Artes
Baixar livros de Astronomia
Baixar livros de Biologia Geral
Baixar livros de Ciência da Computação
Baixar livros de Ciência da Informação
Baixar livros de Ciência Política
Baixar livros de Ciências da Saúde
Baixar livros de Comunicação
Baixar livros do Conselho Nacional de Educação - CNE
Baixar livros de Defesa civil
Baixar livros de Direito
Baixar livros de Direitos humanos
Baixar livros de Economia
Baixar livros de Economia Doméstica
Baixar livros de Educação
Baixar livros de Educação - Trânsito
Baixar livros de Educação Física
Baixar livros de Engenharia Aeroespacial
Baixar livros de Farmácia
Baixar livros de Filosofia
Baixar livros de Física
Baixar livros de Geociências
Baixar livros de Geografia
Baixar livros de História
Baixar livros de Línguas
Baixar livros de Literatura
Baixar livros de Literatura de Cordel
Baixar livros de Literatura Infantil
Baixar livros de Matemática
Baixar livros de Medicina
Baixar livros de Medicina Veterinária
Baixar livros de Meio Ambiente
Baixar livros de Meteorologia
Baixar Monografias e TCC
Baixar livros Multidisciplinar
Baixar livros de Música
Baixar livros de Psicologia
Baixar livros de Química
Baixar livros de Saúde Coletiva
Baixar livros de Serviço Social
Baixar livros de Sociologia
Baixar livros de Teologia
Baixar livros de Trabalho
Baixar livros de Turismo