josias paes d a silva junior
TRANSCRIPT
“AGI
J
Pós-Grad
LE: UmAutomá
Josias
Dis
uação em
ma Abordática de
P
s Paes d
sertação
Universidade Fposgradu
www.cin.ufp
RECIFE, F
Ciência d
dagem e Lingua
Por
da Silv
o de Mes
Federal de [email protected]/~posgradua
FEVEREIRO/
a Computa
para Geagens i
va Juni
strado
mbuco br acao
/2011
ação
eração *”
ior
UNIVERSIDADE FEDERAL DE PERNAMBUCO
CENTRO DE INFORMÁTICA
PÓS‐GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO
JOSIAS PAES DA SILVA JUNIOR
“AGILE: Uma Abordagem para Geração Automática de Linguagens i*"
ESTE TRABALHO FOI APRESENTADO À PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO DO CENTRO DE INFORMÁTICA DA UNIVERSIDADE FEDERAL DE PERNAMBUCO COMO REQUISITO PARCIAL PARA OBTENÇÃO DO GRAU DE MESTRE EM CIÊNCIA DA COMPUTAÇÃO.
ORIENTADOR(A): Prof. Dr. Jaelson Freire Brelaz de Castro CO-ORIENTADOR(A): Prof. Dr. Carla Taciana Lima Lourenço Silva
RECIFE, FEVEREIRO/2011
Catalogação na fonte Bibliotecária Jane Souto Maior, CRB4-571 Silva Junior, Josias Paes da AGILE: uma abordagem para geração automática de linguagens i* / Josias Paes da Silva Junior - Recife: O Autor, 2011. xv, 131 folhas: il., fig., tab. Orientador: Jaelson Freire Brelaz de Castro. Dissertação (mestrado) - Universidade Federal de Pernambuco. CIn, Ciência da computação, 2011. Inclui bibliografia e anexo. 1. Engenharia de software. 2. Engenharia de requisitos. 3. Linhas de produto de software. I. Castro, Jaelson Freire Brelaz de (orientador). II. Título. 005.1 CDD (22. ed.) MEI2011 – 072
pude
realid
como
bem
mesm
mom
cami
traba
traba
comp
AGRADECIMENTOS
Agradeç
esse se orgu
dade. Tenh
o estivesse a
Agradeç
como à min
mo em vida
À minha
mentos aleg
inhada. Te a
À Jaelso
alhos, sempr
À Carla
alho.
Aos am
panheirismo
o a minha
ulhar. Esper
o certeza q
ao meu lado
o ao meu p
nha irmã, A
não serei c
a noiva e co
res e triste
amo!
on Castro,
re buscando
a Silva pel
migos do L
os, amizade
mãe, Mari
ro que mais
que você est
o. Te amo e
pai, Josias, p
Ana Helena e
apaz de retr
ompanheira,
es. Sem vo
pela comp
o o melhor p
a paciência
Laboratório
e, aprendizad
ia José, por
s este passo
teve a todo
e sempre te
pelo carinh
e a Maria d
ribuir o que
, Tatyanna N
ocê eu não
petência e
para seus al
a e compe
o de Enge
do e apoio r
r sempre d
o torne cad
o o moment
amarei!
ho e apoio s
as Neves pe
e vocês fizer
Nadabia, qu
teria tanta
dedicação
lunos.
tência para
enharia de
recebido.
esejar ter u
da vez mais
to iluminand
sempre con
elos cuidado
ram por mim
ue sempre e
a força par
com que
a com o d
Requisito
um filho de
s o seu sonh
ndo os meus
nstante em m
os maternos
m. Amo voc
esteve ao m
ra concluir
sempre ori
desenvolvim
os - LER,
ii
e quem ela
ho em uma
s passos tal
minha vida,
s. Acho que
cês!
eu lado nos
esta longa
ientou seus
mento deste
por todo
i
a
a
l
,
e
s
a
s
e
o
iii
"É bom saber que se eu for suficientemente
estranho a sociedade vai me aceitar e tomar
conta de mim." (Ashleigh Brilliant)
RESUMO
acade
depe
funci
empr
foram
atend
mode
desta
lingu
custo
ident
lingu
possí
mode
fim d
desen
tem
lingu
Lang
criad
de So
O frame
emia. Seu
ndências so
ionais e nã
regado, um
m propostas
der as suas n
elagem surg
as linguagen
uagens. Em
o elevado p
tificar um
uagens base
ível desenv
elagem com
de definir o
nvolviment
como princ
uagens de m
guages), e
das.
Palavras
oftware, Va
ework i* é
reconhecim
ociais e int
ão funcion
m dos princi
s tendo com
necessidade
giram. Nest
ns foi realiz
outros caso
pra o seu
conjunto co
eadas i*, be
olver um nú
muns e sepa
o metamode
o da ferram
cipal contri
modelagem
geração au
s-chave – E
ariabilidade,
uma abord
mento se dá
tencionais
nais de um
ipais desafi
mo base o
es específica
te cenário, o
zado de form
os, não há s
desenvolvi
omum de c
em como um
úcleo comu
arando os q
elo de uma
menta de mo
ibuição a d
baseadas n
utomática d
Engenharia
, Metamode
dagem orie
á pela sua
entre atore
m software
fios é a div
i* e defini
as. Como re
o desenvolv
ma distinta
suporte ferr
imento. Co
característic
m conjunto
um entre est
que são var
a nova lingu
odelagem (e
definição de
no i*, cham
de editores
de Requisit
elagem, Edi
entada a ob
rica capaci
s organizac
em desenv
versidade de
idas por dif
esultado, no
vimento do
entre os gru
ramental pa
onsiderando
cas (elemen
de caracter
tas linguage
iáveis, para
uagem base
editor gráfic
e um proce
ado de AG
gráficos q
tos Orientad
itores Gráfic
bjetivos amp
idade semâ
cionais, bem
volvimento.
e linguagen
ferentes gru
ovas linguag
suporte ferr
upos de pes
ara algumas
as variaçõ
ntos de mo
rísticas vari
ens, identific
a, posteriorm
eada no i*e
co) correspo
esso autom
ILE (Autom
que dêem s
da a Objetiv
cos
mplamente u
ântica de d
m como os
. Embora
ns de mode
upos de pe
gens e/ou el
ramental pa
squisa que c
s linguagens
ões do i*,
odelagem),
iáveis. A pa
cando os el
mente, conf
e reduzir o
ondente. Es
matizado de
matic Gener
suporte às
vos, Linha d
iv
utilizada na
escrever as
s requisitos
vastamente
elagem que
squisa para
lementos de
ara algumas
criaram tais
s devido ao
é possível
afinal, são
artir disto é
lementos de
figurá-los a
esforço do
ste trabalho
criação de
ration of i*
linguagens
de Produtos
v
a
s
s
e
e
a
e
s
s
o
l
o
é
e
a
o
o
e
*
s
s
ABSTRACT
given
amon
wide
based
new
supp
that
langu
possi
langu
betw
varia
on i*
This
mode
autom
Varia
The i *
n for its ri
ng actors a
ely employe
d on i* and
languages a
ort tooling
have creat
uages due
ible to iden
uages i*, a
ween these l
ables, to sub
* and reduc
paper has
eling langua
matic gener
Keywor
ability, Met
framework
ich semanti
as well as f
ed, a key ch
defined by
and/or mod
for some of
ted such la
to high co
ntify a comm
s well as a
languages,
bsequently s
ce the deve
as main co
ages based
ration of gra
ds - Goal
tamodel, Gr
k is a goal-o
ic capabilit
functional a
hallenge is t
different re
deling eleme
f these lang
anguages. I
st for their
mon set of
a set of var
identifying
set them in
elopment ef
ontribution
on i*, calle
aphical edito
Oriented
raphical Edi
oriented ap
ty for desc
and nonfunc
the diversity
esearch grou
ents have em
guages has b
In other ca
r developm
characterist
riables. Fro
the comm
order to de
ffort of mo
to the defi
ed AGILE (
ors that sup
Requireme
itors
pproach use
cribing soci
ctional requ
y of modeli
ups to atten
merged. In
been done s
ases, there
ment. Consid
tics (modeli
om this is p
on element
fine the me
deling tool
finition of a
Automatic
pport the lan
ents Engine
d in academ
ial and inte
uirements o
ing languag
d their spec
this scenari
separately a
is no tooli
dering the
ing element
possible dev
ts modeling
etamodel of
s (graphic
an automate
Generation
nguages crea
eering, Sof
mia. Its rec
entional de
of a system
ges that wer
cific needs.
io, the deve
among resea
ing support
variations
ts), anyway
velop a com
g and separ
f a new lang
editor) corr
ed process
of i* Lang
ated.
ftware Prod
v
cognition is
ependencies
m. Although
re proposed
As a result,
elopment of
arch groups
t for some
of i*, it is
y, are based
mmon core
rating those
guage based
responding.
of creating
uages), and
duct Lines,
v
s
s
h
d
,
f
s
e
s
d
e
e
d
.
g
d
,
vi
SUMÁRIO
Agradecimentos .............................................................................................................. ii
Resumo .......................................................................................................................... iv
Abstract ........................................................................................................................... v
Sumário .......................................................................................................................... vi
Lista de Figuras .............................................................................................................. ix
Lista de Tabelas ............................................................................................................ xii
Lista de legendas .......................................................................................................... xiv
Lista de Abreviaturas e Siglas ...................................................................................... xv
1 Introdução ................................................................................................................ 1
1.1 Contextualização ............................................................................................... 2
1.2 Motivação ......................................................................................................... 3
1.3 Objetivos ........................................................................................................... 4
1.4 Metodologia ...................................................................................................... 5
1.5 Organização da dissertação ............................................................................... 6
2 Engenharia de Requisitos Orientada a Objetivos ..................................................... 8
2.1 Engenharia de requisitos – uma visão geral ...................................................... 9
2.2 Engenharia de requisitos orientada a objetivos ............................................... 10
2.2.1 KAOS ........................................................................................................ 11
2.2.2 NFR Framework ....................................................................................... 13
2.2.3 V-graph ..................................................................................................... 15
2.2.4 O Original framework i* ........................................................................... 16
2.3 Algumas variações do i* ................................................................................. 27
2.3.1 i* Wiki ....................................................................................................... 28
vii
2.3.2 Tropos ....................................................................................................... 28
2.3.3 GRL ........................................................................................................... 28
2.3.4 i*-c ............................................................................................................ 29
2.3.5 i* Aspectual ............................................................................................... 29
2.4 Considerações finais ....................................................................................... 29
3 Engenharia de Linhas de Produto de Software ...................................................... 31
3.1 Linhas de produto de software ........................................................................ 32
3.1.1 Engenharia de domínio ............................................................................. 34
3.1.2 Engenharia de aplicação ............................................................................ 36
3.1.3 Gerenciamento .......................................................................................... 38
3.2 Variabilidade em linhas de produto de software............................................. 39
3.2.1 Modelos de features .................................................................................. 40
3.2.2 Restrições de variabilidade ....................................................................... 42
3.3 Considerações finais ....................................................................................... 44
4 Comparando e Identificando as Variações do Framework i* ................................ 46
4.1 Introdução ....................................................................................................... 47
4.2 i* original versus i* Wiki ................................................................................ 47
4.3 i* original versus Tropos ................................................................................ 49
4.4 i* original versus GRL .................................................................................... 52
4.5 i* original versus i*-c ..................................................................................... 55
4.6 i* original versus i* Aspectual ........................................................................ 58
4.7 Identificando os construtores comuns ............................................................. 61
4.7.1 Representação da variabilidade no modelo de features ............................ 63
4.8 Considerações finais ....................................................................................... 68
5 Metamodelo para a Familia de Linguagens i* ....................................................... 70
5.1 O metamodelo núcleo ..................................................................................... 71
5.2 Estrategias PARA EXTENSÃO DE METAMODELOS ............................... 80
viii
5.3 Considerações finais ....................................................................................... 83
6 AGILE – Automatic Generation of i* Languages ................................................. 85
6.1 Introdução ....................................................................................................... 86
6.2 O processo de Criação de Editores Gráficos com o GMF .............................. 88
6.3 O processo de Criação de Editores Gráficos com a abordagem AGILE ........ 92
6.3.1 Configuração da base i* ............................................................................ 93
6.3.2 Criação e configuração dos novos elementos de modelagem ................. 103
6.3.3 Geração automática dos modelos de configuração do GMF .................. 111
6.4 Considerações finais ..................................................................................... 114
7 Conclusões e Trabalhos Futuros .......................................................................... 116
7.1 Principais Contribuições ............................................................................... 118
7.2 Trabalhos futuros .......................................................................................... 119
Referências ................................................................................................................. 122
ANEXO A – Detalhando a Ferramenta AGILE Tool ................................................ 127
A.1 Reuso estrategico de elementos de modelagem ............................................... 128
A.2 Criação, configuração e inserção de características específicas ...................... 129
A.3 Geração automática de código OCL ................................................................ 130
LISTA DE FIGURAS
Figur
Figur
de (L
Figur
Figur
Figur
Figur
Figur
Figur
Figur
Figur
Figur
Figur
Figur
Figur
2010
Figur
Figur
Figur
Figur
Figur
outro
Figur
o i* W
Figur
Figur
entre
ra 2.1 – Pro
ra 2.2 – Ex
LAMSWEE
ra 2.3 – Exe
ra 2.4 – Exe
ra 2.5 – Esp
ra 2.6 – Ass
ra 2.7 – Dep
ra 2.8 – Tip
ra 2.9 – Gra
ra 2.10 – At
ra 2.11 – Ti
ra 2.12 – Ti
ra 2.13 – Li
ra 3.1 – Vi
0) ................
ra 3.2 – O p
ra 3.3 – O p
ra 3.4 – Foc
ra 3.5 – Exe
ra 3.6 – Me
os (2005) ...
ra 4.1 – Dif
Wiki ..........
ra 4.2 – Ele
ra 4.3 – Di
e o i* Origin
ocesso de En
xemplo de m
ERDE, 2000
emplo de m
emplo de m
pecializaçõe
sociação en
pendência e
pos de relaci
aus de depe
tor e sua fro
ipos de liga
ipos de deco
igações de c
isão da Eng
..................
processo de
processo de
co da variab
emplo de m
etamodelo d
..................
ferenças exi
..................
ementos de m
iferenças ex
nal e o Trop
ngenharia d
modelagem
0) de inglês
modelagem d
modelagem d
es de atores
ntre atores ...
entre atores
ionamentos
ndência em
onteira........
ções meio-f
omposição
contribuiçõe
genharia de
..................
engenharia
engenharia
bilidade na e
modelo de fe
de restriçõe
..................
istentes entr
..................
modelagem
xistentes en
pos ..............
de Requisito
de requisito
para portug
de requisito
de requisito
e relaciona
...................
..................
s de dependê
m i* .............
...................
fim .............
de tarefa ....
es para softg
e Linhas de
...................
a de domínio
a da aplicaçã
engenharia
eatures (CET
es de depen
...................
re as restriçõ
...................
m do Tropos
ntre as restr
...................
os (KOTON
os utilizand
guês. ...........
s utilizando
s utilizando
amento entre
...................
...................
ência entre
...................
...................
...................
...................
goals. .........
e Produtos
...................
o. Adaptado
ão. Adaptad
de domínio
TINA et al.
dência de v
...................
ões da ligaç
...................
..................
rições da lig
...................
NYA; SOMM
do a abordag
...................
o a abordage
o a abordage
e atores ......
...................
...................
atores no i*
...................
...................
...................
...................
...................
de Softwar
...................
o de Pohl e
do de Pohl e
o ..................
, 2009) .......
variabilidade
...................
ção Meio-fim
...................
...................
gação Meio
...................
MERVILLE
gem KAOS
..................
em NFR. ...
em V-graph
..................
..................
..................
* ................
..................
..................
..................
..................
..................
re. Adaptad
..................
outros(2005
e outros (20
..................
..................
de. Adaptado
..................
m entre o i*
..................
..................
o-fim e Dec
..................
ix
E, 1998) 10
S. Adaptado
.............. 13
.............. 14
h. ............ 15
.............. 18
.............. 19
.............. 20
.............. 20
.............. 21
.............. 22
.............. 23
.............. 23
.............. 24
do de (SEI,
.............. 34
5) .......... 35
005) ........ 36
.............. 39
.............. 42
o de Pohl e
.............. 44
* Original e
.............. 48
.............. 50
composição
.............. 50
x
0
o
4
9
0
0
2
4
,
4
6
9
2
e
4
e
0
o
0
x
Figura 4.4 – Relacionamentos existentes no GRL ................................................................... 53
Figura 4.5 – Diferenças existentes entre as restrições da ligação Meio-fim, Decomposição,
Correlação e Representação Qualitativa e Quantitativa entre o i* Original e o GRL .............. 53
Figura 4.6 – Elementos de modelagem com cardinalidade existentes no i*-c ......................... 56
Figura 4.7 – Diferenças existentes entre as restrições da ligação Meio-fim, Meio-fim com
cardinalidade e Decomposição entre o i* Original e o i*-c ...................................................... 56
Figura 4.8 – Principais elementos de modelagem presentes da linguagem i* Aspectual ........ 59
Figura 4.9 – Diferenças existentes entre as restrições da ligação Meio-fim de entrecorte,
Decomposição de entrecorte e Contribuição de entrecorte entre o i* Original e o i*-c ........... 59
Figura 4.10 – Modelo de feature da linguagem i* original ...................................................... 64
Figura 5.1 – Diagrama representativo dos quatro níveis de abstração de modelos propostos
pela OMG. Adaptado de Kleppe e outros (2003) ..................................................................... 71
Figura 5.2 – Metamodelo núcleo com suporte a variabilidade ................................................. 73
Figura 5.3 – Exemplo de variações do Compartment no metamodelo núcleo ......................... 74
Figura 5.4 – Exemplo de variações do Compartment com atributo no metamodelo núcleo .... 74
Figura 5.5 – Exemplo concreto da representação sintática apresentado na Figura 5.3 ............ 75
Figura 5.6 – Exemplo de variações do ElementMC no metamodelo núcleo ........................... 75
Figura 5.7 - Exemplo concreto da representação sintática apresentado na Figura 5.6 ............. 76
Figura 5.8 – Exemplo de variações de elementos intencionais no metamodelo núcleo ........... 77
Figura 5.9 - Exemplo concreto da representação sintática de um elemento intencional
existentes apenas nos compartimentos. Baseado no i* Aspectual (ALENCAR et al., 2010) .. 78
Figura 5.10 - Exemplo concreto da representação sintática de um elemento intencional
existentes apenas nos compartimentos (SIENA et al., 2010) ................................................... 78
Figura 5.11 – Exemplo de variações de elementos com atributos no metamodelo núcleo ...... 78
Figura 5.12 - Exemplo concreto da representação sintática de um elemento intencional com
característica específica (BORBA, 2010) ................................................................................. 79
Figura 5.13 – Exemplo de variação de relacionamentos no metamodelo núcleo..................... 80
Figura 5.14 - Exemplo concreto da representação sintática de uma ligação de dependência do
i* original (YU, E. 1995) apresentado na Figura 5.13 ............................................................. 80
Figura 5.15 – Exemplo de configuração de sources e targets sem a metaclasse NodeObject . 82
Figura 5.16 – Exemplo de configuração de sources e targets com a metaclasse NodeObject 83
Figura 6.1 – Framework GMF e dependências. Adaptado de Venkatesan (2006) ................... 88
Figura 6.2 – Modelos do GMF (GFM. 2010) ........................................................................... 89
xi
Figura 6.3 – Processo de criação de uma editor gráfico como framework GMF utilizando a
notação BPMN ......................................................................................................................... 90
Figura 6.4 – Processo de criação de um editor gráfico utilizando a abordagem AGILE ......... 93
Figura 6.5 – Tela Principal da AGILE Tool para configuração de uma base i* ...................... 94
Figura 6.6 – Modelo de feature da linguagem i* original ........................................................ 95
Figura 6.7 – Exemplo de tratamento automático de restrições de dependência entre features 96
Figura 6.8 – Metamodelo base utilizado pela linguagem i* Aspectual (i* original)................ 97
Figura 6.9 – Ligações de dependência que o metamodelo permite ........................................ 100
Figura 6.10 – Tela de configuração de restrições e geração automática de código OCL ...... 101
Figura 6.11 – Modelo de feature para configuração de um novo elemento de modelagem .. 104
Figura 6.12 – Tela de configuração dos novos elementos de modelagem ............................. 105
Figura 6.13 – Metamodelo do i* Aspectual gerado automaticamente pela AGILE Tool ...... 106
Figura 6.14 – Criando o ator aspectual da linguagem i* Aspectual e configurando suas
restrições ................................................................................................................................. 107
Figura 6.15 – Criando os Crosscutting concerns da linguagem i* Aspectual ........................ 109
Figura 6.16 – Criando o crosscuttingME e definindo suas restrições .................................... 110
Figura 6.17 – Criando os relacionamentos transversais do i* aspectual e definindo suas
restrições ................................................................................................................................. 111
Figura 6.18 – Processo de criação de um editor gráfico utilizando a abordagem AGILE ..... 112
Figura 6.19 – Atividade complementares para geração do código fonte referentes ao editor
gráfico alvo ............................................................................................................................. 113
Figura 6.20 – Editor gráfico do i* Aspectual finalizado ........................................................ 114
Figura A1 – Diagrama de classes resumido sobre o reuso estratégico de elementos de
modelagem ............................................................................................................................. 129
Figura A2 – Diagrama de classes resumido para a criação de novos elementos de modelagem
................................................................................................................................................ 130
Figura A3 – Exemplo da estrutura de uma ligação no modelo de mapeamento sem definição
de restrições ............................................................................................................................ 131
Figura A4 – Exemplo da estrutura de uma ligação no modelo de mapeamento com a definição
das restrições .......................................................................................................................... 131
LISTA DE TABELAS
Tabe
Tabe
Tabe
Tabe
Tabe
Tabe
Tabe
(GRA
Tabe
restri
Tabe
i* W
Tabe
al., 2
Tabe
restri
Tabe
(SUS
Tabe
al., 2
Tabe
restri
Tabe
GRL
Tabe
2009
ela 2.1 – Re
ela 2.2 – Re
ela 2.3 – Re
ela 2.4 – Re
ela 2.5 – Re
ela 3.1 – Ex
ela 4.1 – C
AU et al., 2
ela 4.2 – I
ições entre
ela 4.3 – Di
Wiki (GRAU
ela 4.4 – Di
2005) ..........
ela 4.5 – I
ições entre
ela 4.6 – Di
SI et al., 200
ela 4.7 – Di
2009) ..........
ela 4.8 – I
ições entre
ela 4.9 – Di
L (AMYOT
ela 4.10 – D
9) ................
strições da
strições das
strições da
strições da
strições da
emplo de re
Comparação
008) ..........
Identificaçã
o i* origina
ferenças de
U et al., 2008
iferenças de
..................
Identificaçã
o i* origina
ferenças de
05) .............
ferenças de
..................
Identificaçã
o i* origina
ferenças de
et al., 2009
Diferença d
..................
Ligação de
s Ligações d
Ligação Me
Ligação de
Ligação de
estrição de d
de constru
..................
ão dos sím
al e o i* Wik
e Restrições
8) ...............
e construtor
..................
ão dos sím
al e o Tropo
Restrições
..................
e construtore
..................
ão dos sím
al e o GRL..
e Restrições
9) ................
de construto
..................
Dependênc
de Ator .......
eio-fim .......
Decompos
Contribuiç
dependência
utores entre
...................
mbolos utili
ki ...............
dos relacio
...................
res entre o
...................
mbolos utili
os ................
dos relacio
...................
es entre o i
...................
mbolos utili
...................
dos relacio
...................
ores entre o
...................
cia ..............
...................
...................
ição de Tar
ão ..............
a entre featu
e o i* orig
...................
zados nas
...................
onamentos e
...................
i* original
...................
zados nas
...................
onamentos i
...................
* original (
...................
zados nas
...................
onamentos e
...................
o i* origina
...................
...................
...................
...................
efas ............
...................
ures ............
inal (YU, E
...................
comparaçõ
...................
entre o i* or
...................
(YU, 1995
...................
comparaçõ
...................
i* original (
...................
(YU, 1995)
...................
comparaçõ
...................
entre o i* or
...................
al (YU, 199
...................
..................
..................
..................
..................
..................
..................
E. 1995) e
..................
ões de con
..................
riginal (YU
..................
) e o Tropo
..................
ões de con
..................
(YU, 1995)
..................
e o GRL (A
..................
ões de con
..................
riginal (YU
..................
95) e o i*-c
..................
xii
.............. 25
.............. 26
.............. 26
.............. 27
.............. 27
.............. 44
o i* Wiki
.............. 48
nstrutores e
.............. 48
U, 1995) e o
.............. 49
os (SUSI et
.............. 50
nstrutores e
.............. 51
e o Tropos
.............. 51
AMYOT et
.............. 54
nstrutores e
.............. 54
U, 1995) e o
.............. 55
c (BORBA,
.............. 57
i
6
6
7
7
4
i
e
o
9
t
0
e
s
t
4
e
4
o
,
7
xiii
Tabela 4.11 – Identificação dos símbolos utilizados nas comparações de construtores e
restrições entre o i* original e o i*-c ........................................................................................ 57
Tabela 4.12 – Restrições dos relacionamentos entre o i* original (YU, 1995) e o i*-c
(BORBA, 2009) ........................................................................................................................ 57
Tabela 4.13 – Diferença de construtores entre o i* original (YU, 1995) e o i* Aspectual
(ALENCAR et al., 2010) .......................................................................................................... 60
Tabela 4.14 – Identificação dos símbolos utilizados nas comparações de construtores e
restrições entre o i* original e o i* Aspectual .......................................................................... 60
Tabela 4.15 – Restrições dos relacionamentos entre o i* original (YU, 1995) e o i* Aspectual
(ALENCAR et al., 2010) .......................................................................................................... 61
Tabela 4.16 – Pontos de Variação e Variantes identificados na análise de construtores ......... 62
Tabela 4.17 – Exemplos de variantes sendo tratadas como pontos de variação ...................... 62
Tabela 4.18 – Tratamento de restrição de dependência da feature ISA ................................... 66
Tabela 4.19 – Tratamento de restrição de dependência da feature Plays ................................. 66
Tabela 4.20 – Tratamento de restrição de dependência da feature Covers .............................. 66
Tabela 4.21 – Tratamento de restrição de dependência da feature Occupies ........................... 67
Tabela 4.22 – Tratamento de restrição de dependência da feature Dependency Link ............. 67
Tabela 4.23 – Tratamento de restrição de dependência da feature Contribution Link ............ 67
Tabela 4.24 – Tratamento de restrição de dependência da feature Decomposition Task ........ 68
Tabela 4.25 – Tratamento de restrição de dependência da feature Means-End ....................... 68
Tabela 6.1 – Exemplo de código OCL usado no GMF .......................................................... 102
Tabela 6.2 – Estrutura do código OCL ................................................................................... 103
LISTA DE LEGENDAS
Lege
Lege
enda 1 – No
enda 2 – No
otação das fe
otação das fe
eatures utili
eatures utili
izadas no m
izadas nesta
método FOD
a dissertação
DA (KANG
o .................
et al., 2002
..................
xiv
2) ............ 41
.............. 41
v
LISTA DE ABREVIATUR
AGIL
CAS
ELPS
EMF
FOD
GEF
GMF
GOR
GRL
i*-C
IDE
KAO
LPS
MDD
MOF
NFR
OCL
OMG
SD –
SR –
UML
PDE
XML
RAS E SIGLAS
LE – Autom
SE – Compu
S – Engenh
F – Eclipse M
DA – Feature
– Graphica
F – Graphic
RE – Goal-O
L – Goal-ori
– i* com ca
- Integrated
OS – Keep A
– Linhas de
D – Model-D
F – Meta Ob
R – Non-Fun
L – Object C
G – Object M
– Strategic D
– Strategic R
L – Unified
– Plug-in D
L – eXtensib
matic Gener
uter-Aided S
haria de Linh
Modeling F
e-Oriented D
al Editing F
cal Modeling
Oriented Re
iented Requ
ardinalidade
d Developm
All Objectiv
e Produto d
Driven Dev
bject Facilit
nctional Req
Constraint L
Managemen
Dependency
Rationale
Modeling L
Developmen
ble Markup
ration of i* L
Software En
has de Prod
Framework
Domain An
ramework
g Framewor
quirements
uirement Lan
e
ment Environ
ves Satisfied
e Software
velopment
ty
quirement
Language
nt Group
y
Language
nt Environm
p Language
Languages
ngineering
dutos de Sof
nalysis
rk
Engineerin
nguage
nment
d
ment
ftware
ng
xvv
INTRODUÇÃO
Este
além
capítulo ap
m de apresen
presenta as
ntar a estrutu
principais m
ura do docu
motivações
umento.
e objetivoss para a realalização des
1
te trabalho,
,
2
1.1 CONTEXTUALIZAÇÃO
Cada vez mais existe a necessidade de aumentar a ênfase nas fases iniciais (análise e
especificação de requisitos) no âmbito do desenvolvimento de sistemas de software para se ter
maiores chances de realizar um projeto de software com sucesso. Nos últimos anos foram
propostas algumas metodologias (tal como Tropos) e linguagens (tal como i*) centradas em
requisitos que têm como foco principal desenvolver sistemas compatíveis com o seu ambiente
organizacional.
Tropos (CASTRO, MYLOPOULOS, 2000) é uma abordagem que se preocupa em
capturar e analisar os aspectos sociais em ambientes organizacionais no início do ciclo de
desenvolvimento do sistema. Tropos provê uma das metodologias mais completas,
abrangendo cinco fases do ciclo de desenvolvimento de sistemas multiagentes, que cobrem as
fases de requisitos iniciais e finais, arquitetura, projeto detalhado e codificação. Os modelos e
conceitos utilizados nas fases iniciais do Tropos são fornecidos pelo Framework i* (YU, E.
1995), que possui uma estrutura conceitual rica, capaz de representar motivações, intenções e
raciocínios sobre as características do sistema. Fato que facilita os esforços nas atividades da
Engenharia de Requisitos.
A Engenharia de Requisitos que tem como principal objetivo descobrir as reais
necessidades dos stakeholders1 no mundo real. Para isto é preciso entender o problema,
elicitar os requisitos necessários para o sistema, analisá-los, documentá-los e validá-los, a fim
de prover um desenvolvimento de sistemas de software cada vez mais sistemático e
disciplinado, diminuindo assim os riscos de falhas no desenvolvimento da solução (software)
(KOTONYA; SOMMERVILLE, 1998).
A Engenharia de Requisitos Orientada a Objetivos (do inglês, Goal-Oriented
Requirements Enginering ou GORE) (LAMSWEERDE, 2000) tem como foco a identificação
e entendimento do problema através da captura das reais necessidades do stakesholders,
focando nos objetivos que eles pretendem satisfazer com o desenvolvimento do sistema de
software.
Existem atualmente diversas linguagens de modelagem propostas para especificação
de requisitos orientada a objetivos, tais como KAOS (LAMSWEERDE, 2000), o NFR
1 São pessoas ou organizações que serão afetadas pelo sistema e tem influência, direta ou indireta, sobre os requisitos do sistema – usuários finais, gerentes e outros envolvidos no processo organizacional influenciados pelo sistema, engenheiros (KOTONYA; SOMMERVILLE, 1998).
3
Framework (CHUNG et al., 1999), o V-graph (YU, Y. et al., 2004) e o Framework i* (YU, E.
1995). O Framework i*, em especial, é uma abordagem GORE destinada a modelagem
organizacional onde é possível modelar e analisar sistemas sob uma visão estratégica e
intencional de processos que englobam diversos participantes (atores).
O i* é amplamente utilizado por diversos grupos de pesquisa espalhados pelo mundo
(Toronto, Itália, Espanha, Brasil etc.). Cada um desses grupos utiliza o i* em diferentes
domínios de aplicação ou para contextos específicos. Em meio disto, diversas novas versões
do i* surgiram a fim de satisfazer necessidades específicas desses grupos de pesquisa. Essas
versões do i* incluem o GRL (AMYOT et al., 2009), i* Wiki (GRAU et al., 2008), i*-C
(BORBA, 2009), i* Aspectual (ALENCAR et al., 2010), Tropos (SUSI et al., 2005), dentre
outras.
Para cada variação do i* proposta, uma nova ferramenta CASE (Computer-Aided
Software Engineering) de apoio a modelagem gráfica deve ser desenvolvida. Além do alto
custo de desenvolvimento de cada ferramenta de modelagem, as plataformas e tecnologias
utilizadas para desenvolvê-las são diferentes, o que dificulta, por exemplo, a integração entre
elas.
Através de uma análise comparativa entre várias linguagens baseadas no i*, observou-
se que elas formam uma família de linguagens i*. Isto implica dizer que cada variação herda
ou reusa conceitos pertencentes à linguagem de modelagem do i* original. Percebeu-se
também que a definição de novas linguagens de modelagem baseadas no i*, bem como a
criação das respectivas ferramentas de modelagem, poderia beneficiar-se dos princípios
presentes no desenvolvimento de Linhas de Produtos de Software (LPSs) de forma a
aumentar o reuso e a produtividade, além de diminuir os custos envolvidos neste processo.
Uma linha de produtos de software é um conjunto de sistemas de software, que
compartilham um conjunto de características em comum, e satisfazem necessidades
específicas de um determinado segmento de mercado (SEI, 2010).
1.2 MOTIVAÇÃO
Dentre as linguagens orientadas a objetivos (GORE) uma das que possui maior
destaque é a i* devido a sua capacidade de representar os atores envolvidos no ambiente o
4
qual o sistema existirá, suas intenções bem como representar os requisitos funcionais e não
funcionais do sistema.
É fato que diversas linguagens foram propostas baseadas no i* original (YU, E. 1995).
Esses dialetos do i* satisfazem necessidades específicas e demandam suporte ferramental
específico para modelagem gráfica. Percebeu-se que cada um destas ferramentas de
modelagem foi desenvolvida exclusivamente para satisfazer a necessidade de especificação
gráfica da linguagem alvo (dialeto). Cada um dos grupos de pesquisa responsável pelo
desenvolvimento utilizou plataformas e tecnologias que lhes convinham para satisfazer as
suas necessidades. É possível então afirmar que o maior problema existente está relacionado a
ferramenta de apoio a modelagem gráfica que deve ser desenvolvida cada nova de linguagem
baseada no i* proposta. Isto implica dizer que novos esforços para o desenvolvimento de uma
nova ferramenta de modelagem devem ser empenhados acarretando o aumento de custo de
desenvolvimento, interoperabilidade entre ferramentas dentre outros.
A partir da identificação de que as linguagens baseadas no i* poderiam fazer parte de
uma mesma família de linguagens, que herdam ou reusam um conjunto comum de conceitos
do i* original, idealizou-se uma abordagem para a definição de novas linguagens para esta
família. Através desta abordagem será possível definir a estrutura sintática e semântica de
uma nova linguagem, tendo como base o reuso de um conjunto de conceitos do i* original.
Para atingir este fim, princípios do paradigma de LPS serão utilizados, a fim de organizar o
gerenciamento das características comuns compartilhadas por cada linguagem da família,
como também dos conceitos específicos de cada uma destas linguagens. A criação de
linguagens baseadas no i* será realizada através da definição de metamodelos, com o apoio de
uma ferramenta que irá aumentar o nível de abstração das etapas envolvidas neste processo.
Os princípios envolvidos na engenharia de LPS auxiliarão no desenvolvido desta
ferramenta de suporte a abordagem, que também será responsável pela geração automática da
ferramenta de modelagem (editor gráfico) correspondente à linguagem criada.
1.3 OBJETIVOS
Motivados pelo problema exposto na seção anterior, esta seção apresenta o objetivo
geral e os objetivos específicos que este trabalho pretende alcançar. O objetivo geral sintetiza
5
o principal propósito deste trabalho. Os objetivos específicos tornam o objetivo geral
operacional e indica o que será realizado especificamente na pesquisa.
Este trabalho tem como objetivo geral o desenvolvimento de uma abordagem
automatizada para a definição estrutural de linguagens baseadas no i* e a geração automática
das ferramentas CASE de modelagem correspondentes.
A partir desse objetivo geral, definimos os seguintes objetivos específicos:
Realizar uma comparação entre algumas variações da linguagem de modelagem
definida no framework i* (i* Wiki (GRAU et al., 2008), Tropos (SUSI et al.,
2005), GRL (AMYOT et al., 2009), i*-C (BORBA, 2009) e i* Aspectual
(ALENCAR et al., 2010));
Identificar construtores comuns e variáveis entre as linguagens baseadas no i*
comparadas, utilizando-se dos princípios e técnicas do desenvolvimento de LPSs;
Definir um metamodelo núcleo com base nos construtores comuns identificados e
com suporte a variabilidade para especificação sintática da nova linguagem;
Propor uma abordagem de configuração do metamodelo núcleo, de forma a
definir novas linguagens da família i*;
Desenvolver uma ferramenta que automatize a definição de metamodelos de
linguagens da família i* e a geração automática de editores gráficos que dêem
suporte à modelagem com estas linguagens.
1.4 METODOLOGIA
Este trabalho de pesquisa seguiu o método de engenharia que é 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.
Inicialmente foi feito um estudo sobre as duas principais sub-áreas envolvidas neste
trabalho: a Engenharia de Requisitos Orientada a Objetivos e a Engenharia de Linhas de
Produto de Software (ELPS). Na área da Engenharia de Requisitos Orientada a Objetivos
foram pesquisadas algumas abordagens existentes, tais como o KAOS (LAMSWEERDE,
2000), o NFR Framework (CHUNG et al., 1999), o V-graph (YU, Y. et al., 2004) e o
Framework i* (YU, E. 1995). Foi dado um maior foco no framework i* por ser a abordagem
principal deste trabalho devido a sua representatividade e por ser uma das linguagens mais
6
adotadas na comunidade de engenharia de software. Na área de Engenharia de Linhas de
Produtos de Software (CLEMENTS; NORTHROP, 2001) (POHL et al., 2005) foram
apresentadas as principais atividades envolvidas no processo e o modelo de features (KANG
et al., 1990), artefato central usado nestas atividades e ao longo desta dissertação.
O passo seguinte foi fazer uma comparação sobre os elementos de modelagem e as
restrições nos relacionamento presentes nas linguagens baseadas no i* que foram analisadas,
que incluem o i* Wiki (GRAU et al., 2008), Tropos (SUSI et al., 2005), GRL (AMYOT et al.,
2009), i*-C (BORBA, 2009) e o i* Aspectual (ALENCAR et al., 2010)).
Tendo feito isso, concluiu-se que entre essas linguagens existe um conjunto de
características comuns herdadas ou reusadas do i* original. O resultado desta comparação
proporcionou a definição de um metamodelo núcleo criado tanto para representar as
características comuns, como para suportar a inserção da variabilidade existente nas diversas
linguagens baseadas no i*.
Para que isto fosse possível, percebeu-se a necessidade de definir um processo que
permitisse a criação de linguagens baseadas no i* em um nível mais alto de abstração. Para
tanto, este processo possui o apoio de uma ferramenta CASE que auxilia na definição do
metamodelo da linguagem e na geração automática do editor gráfico que dá suporte a
modelagem. Essa abordagem foi denominada AGILE (do inglês, Automatic Generation of i*
Languages ou Geração Automática de Linguagens i*).
Por fim, com o objetivo de avaliar a abordagem AGILE, realizamos um estudo de caso
no qual aplicamos o processo e a ferramenta AGILE Tool na criação do metamodelo da
linguagem i* Aspectual, bem como na geração do seu editor de modelagem gráfica.
1.5 ORGANIZAÇÃO DA DISSERTAÇÃO
Além deste capítulo introdutório, este trabalho encontra-se estruturado da seguinte
forma:
Capítulo 2 – Engenharia de Requisitos Orientada a Objetivos: apresenta o estado
da arte na área da engenharia de requisitos orientada a objetivos, contextualizando brevemente
o processo de engenharia de requisitos e as principais linguagens de modelagem existentes,
tendo como foco principal a linguagem i*;
7
Capítulo 3 – Engenharia de Linhas de Produto de Software: apresenta os
principais conceitos e princípios envolvidos na engenharia de LPSs, focando principalmente
nos três processos envolvidos na engenharia de linhas de produto de software (gerenciamento,
engenharia de domino e engenharia da aplicação), como também no modelo de features;
Capítulo 4 – Comparando e Identificando as Variações do Framework i*:
apresenta uma comparação sobre os elementos de modelagem e as restrições dos
relacionamentos presentes nas principais variações do i*, a fim de apresentar a identificação
das características comuns e variáveis entre estas linguagens;
Capítulo 5 – Metamodelo para a Familia de Linguagens i*: apresenta a proposta de
um metamodelo núcleo, com suporte à variabilidade, para a criação de novas linguagens
baseadas no i*.
Capítulo 6 – AGILE – Automatic Generation of i* Languages: apresenta detalhes
da abordagem AGILE, utilizando o i* Aspectual como estudo de caso.
Capítulo 7 – Conclusão: apresenta as conclusões finais acerca do trabalho
apresentado e as considerações para o desenvolvimento de trabalhos futuros.
Referências – são apresentadas as referências bibliográficas utilizadas na realização
deste trabalho.
2 E
Este
Enge
Engi
técni
objet
algum
serão
ENGENHARIA DE REQUISITOS ORIENTADA A OBJETIVO
capítulo ap
enharia de
ineering –
icos necessá
tivos que s
mas aborda
o apresentad
OS
presenta uma
e Requisito
GORE) par
ários bem c
serão apres
agens GORE
das as consi
a visão gera
os Orienta
ra que nos
como os det
sentados e
E existentes
iderações fin
al da Engen
ada a Obj
s próximos
talhes da es
utilizados
s, focando p
nais.
nharia de Re
jetivos (ou
capítulos s
strutura sint
ao longo
principalme
equisitos e d
u Goal-Or
seja possíve
tática das li
do trabalho
ente no fram
discute os c
riented Re
el entender
inguagens o
o. Serão ap
mework i*.
8
conceitos da
equirements
r os termos
orientadas a
presentadas
Por último,
8
a
s
s
a
s
,
9
2.1 ENGENHARIA DE REQUISITOS – UMA VISÃO GERAL
De acordo com Kotonya e Sommerville (1998) a engenharia de requisitos é um ramo
da engenharia de software que tem como principal objetivo descobrir as reais necessidades
dos stakeholders no mundo real. Através destes destas necessidades é seja possível tornar o
desenvolvimento de sistemas de softwares cada vez mais sistemático e disciplinado.
O processo de Engenharia de Requisitos (Figura 2.1) tem a finalidade de cobrir todas
as atividades envolvidas nas fases de descoberta, análise, documentação e validação dos
requisitos de um sistema (KOTONYA; SOMMERVILLE, 1998).
No processo proposto por Kotonya e Sommerville (1998), as atividades envolvidas são
(Figura 2.1):
Elicitação de Requisitos: os requisitos são descobertos através de consultas aos
stakeholders. Como resultado dessas consultas é gerado uma lista com a
identificação dos requisitos identificados.
Análise e Negociação de Requisitos: os requisitos são analisados em detalhe por
diferentes stakeholders e, a partir desta análise, tomam-se decisões sobre quais
requisitos serão aceitos. Seu principal papel é evitar problemas de conflito,
incompletude, ambigüidade e inconsistência de requisitos.
Documentação de Requisitos: Os requisitos devem ser documentados usando
linguagem natural e/ou diagramas de representação de requisitos, gerando um
documento compreensível a todos os stakeholders.
Validação de Requisitos: cada requisito deve ser checado cuidadosamente para
confirmar sua consistência e completude. É utilizado para detectar problemas no
documento de requisitos antes de executar as próximas atividades do ciclo de
desenvolvimento. Essa etapa é realizada conjuntamente com o cliente.
A aplicação desse processo é realizada, sobretudo, nas etapas iniciais do
desenvolvimento de software. Seus artefatos (por exemplo, o documento de requisitos do
sistema) são vistos como o estabelecimento de um contrato entre todas as partes envolvidas
em um projeto de software. Os diversos modelos e descrições geradas (e.g. um diagrama de
casos de uso, descrição de cenários, diagramas i*) são considerados como meios facilitadores
da comunicação, principalmente no atendimento das necessidades dos clientes e quanto à
satisfação das expectativas dos usuários.
algum
abord
repre
(YU,
orien
2.2
produ
nece
enge
intro
Requ
pergu
funci
2 Segu
Figura 2.1
A aprese
ma linguage
dagem de m
esenta os re
, E. 1995).
Na próx
ntada a obje
ENGENH
Como de
ução de um
ssidades do
nharia de
duzidos na
uirements E
untas do “p
ionalidade p
undo Lawswe
1 – Processo d
entação des
em de descr
modelagem
equisitos fun
xima Seção
etivos para e
HARIA DE R
escrito anter
m conjunto
os stakehold
requisitos,
Engenhari
Enginering o
“porquê” d
pode ser im
eerde (2001), u
de Engenhari
sas descriçõ
rição de req
m de requis
ncionais e n
o serão apr
entender a e
REQUISIT
riormente, a
de especif
ders e que p
que pergu
a de Requi
ou GORE),
e uma dete
mplementada
um objetivo é
ia de Requisi
ões em arte
quisitos expr
itos orienta
não-funcion
resentados
essência prin
TOS ORIEN
a Engenhari
ficações pa
possam ser
gunta “o q
isitos Orien
, compleme
erminada f
a da melhor
aquilo que o
itos (KOTON
efatos pode
ressa em m
ada a objet
nais por me
os conceit
ncipal do fr
NTADA A O
ia de Requi
ara sistemas
r implement
ue“ um si
ntada a Obje
enta o enten
funcionalida
forma (LA
sistema dever
NYA; SOMM
ser realizad
odelos, tais
tivos chama
eio da decom
tos da eng
amework i*
OBJETIVOS
isitos (RE) e
s de softwa
tadas, impla
istema dev
etivos2 (do
ndimento do
ade é nece
MSWEERD
rá atingir.
MERVILLE, 1
da com a ut
s como, por
ada i* (i-es
mposição d
genharia de
*.
S
está preocup
are que sat
antadas e m
ve fazer, o
inglês, Goa
o problema
essária e “c
DE, 2001).
10
1998)
tilização de
exemplo, a
strela), que
de objetivos
e requisitos
pada com a
tisfaçam as
mantidas. A
os métodos
al-Oriented
a através de
como” esta
0
e
a
e
s
s
a
s
A
s
d
e
a
11
O GORE considera tanto os Requisitos Funcionais, como também os Requisitos Não-
Funcionais3 (do inglês, Non-Functional Requirements – NFRs) (CHUNG et al., 1999) para
responder os questionamentos descritos anteriormente. Assim, torna-se possível visualizar os
objetivos existentes no ambiente em que o sistema será inserido, de modo que o sistema a ser
desenvolvido corresponda ao que realmente os stakeholders necessitam.
O crescimento do uso de objetivos na Engenharia de Requisitos e as necessidades
enfrentadas pelos diversos grupos de pesquisas espalhados pelo mundo incentivaram o
desenvolvimento de várias propostas de abordagens GORE. Alguns exemplos são o KAOS
(LAMSWEERDE, 2000), o NFR Framework (CHUNG et al., 1999), o V-graph (YU, Y. et
al., 2004) e o Framework i* (YU, 1995).
2.2.1 KAOS
O KAOS (do inglês, Keep All Objectives Satisfied) é um método para elicitação de
requisitos baseados em objetivos, agentes e restrições. Os conceitos são apresentados em um
grafo onde os nós representam uma abstração (ação, restrição, e objeto) e os arcos capturaram
a semântica de seus relacionamentos. Segue o processo top-down como estratégia para a
elicitação de requisitos a partir de objetivos abstratos que vão sendo refinados até que um
nível operacional seja atingido. (LAMSWEERDE, 2000).
Com KAOS os requisitos operacionais de software são derivados gradualmente a
partir dos objetivos básicos do sistema. A derivação prossegue de acordo com as seguintes
etapas (LAMSWEERDE, 2000):
Modelagem de objetivos: um grafo de refinamento de objetivos é elaborado
através da identificação de objetivos relevantes a partir do material de entrada
(tais como transcrições de entrevistas e documentos disponíveis) - normalmente,
procurando por palavras-chave intencionais descritas em linguagem natural;
sempre focando no questionamento do porque e como.
3 Requisitos Funcionais são as funcionalidades do sistema e os requisitos não-funcionais são requisitos qualitativos (como segurança, confiabilidade, disponibilidade, tempo de resposta), ou seja, é desejável que o sistema tenha, mas não é especificado como esses requisitos serão satisfeitos. Às vezes, conflitos são gerados com a escolha de dois ou mais requisitos não-funcionais incompatíveis na sua satisfação simultânea (por exemplo, deseja-se que o sistema seja seguro como também tenha um tempo de resposta reduzido) (KOTONYA; SOMMERVILLE, 1998).
12
Modelagem de objetos: classes UML (Unified Modeling Language), atributos e
associações são derivados sistematicamente a partir das especificações dos
objetivos;
Modelagem de agentes: os agentes são identificados e as suas capacidades de
monitoramento e de controle são elicitadas.
Operacionalização: operações e seu domínio de pré e pós-condições são
identificados a partir das especificações dos objetivos.
No exemplo do modelo KAOS representado na Figura 2.2, temos o objetivo principal
que o sistema deverá atingir: Evitar [colisão de trens]. Para atingi-lo, é necessário satisfazer
o requisito de Manter [distância entre os trens]. Contudo, para satisfazer este requisito
precisamos atingir três objetivos: Manter [Aceleração segura/Controlar comando de
aceleração], Manter [Segurança do comando da resposta com o trem] e Manter
[controle de paradas súbitas]. Alguns destes objetivos são atingidos através de agentes
envolvidos no problema que podem ser agentes reais e/ou agentes de software. No caso do
objetivo Manter o [Segurança do comando da resposta com o trem] é responsabilidade do
controlador a bordo do trem. Por sua vez, Manter [Aceleração segura/Controlar comando
de aceleração] é refinado em outros dois objetivos: Manter [Precisão da
velocidade/Estimativa da posição atual] que tem como agente responsável o Sistema de
rastreamento e Manter [Segurança do comando de partida baseado na
velocidade/Estimativa da posição atual], que por sua vez é refinado em mais três objetivos
e um requisito para serem atingidos: o objetivo Efetuar [Mensagem enviada em tempo de
comando] e o requisito Manter [Segurança do comando de mensagem] que é
responsabilidade do sistema de controle de velocidade, os objetivos Efetuar [Entrega da
mensagem em tempo de comando] que é responsabilidade da equipe de infra-estrutura de
comunicação e Manter [Exercer a entrega de mensagem de comando] que tem como
agente responsável o controlador abordo do trem.
Enfim, KAOS é um método orientado a objetivos para a engenharia de requisitos que
tem a intenção de exportar as virtudes da orientação a objetivos como guia aos arquitetos de
software para a realização de suas tarefas de planejamento. Ele mistura a argumentação
qualitativa e formal dos requisitos para a realização de arquiteturas de software que satisfaçam
os requisitos funcionais e não funcionais do sistema.
2.2.2
em o
basea
são
passí
não p
4 Não
Figura 2.2 –
2 NFR Fr
O NFR F
objetivos us
ada em soft
objetivos o
íveis à nego
precisam es
existe uma tr
Exemplo de (LA
amework
Framework
sados para m
ftgoals4 (Fig
onde os cri
ociação e in
star comple
radução aceitá
modelagem dAMSWEERD
k (do inglês
modelar e a
gura 2.3). D
itérios de a
nterpretação
tamente sat
ável para portu
de requisitos DE, 2000) de
, Non-Func
analisar req
Diferente do
aceitação n
o. Para que
tisfeitos, po
uguês. Por est
utilizando a inglês para p
ctional Requ
quisitos não
os Objetivos
não são cla
e exista um
odendo assim
e motivo o ter
abordagem Kportuguês.
uirements F
-funcionais
s (do inglês
aramente de
ma interação
m ocorrer u
rmo será mant
KAOS. Adap
Framework)
s. Toda a ab
s, Goals), o
efinidos, ou
o entre softg
uma satisfaç
tido do origin13
tado de
) é baseado
bordagem é
os Softgoals
u seja, são
goals, estes
ção parcial.
al. 3
o
é
s
o
s
.
O NF
segur
exem
pelos
espes
semp
realiz
funci
corre
Segu
requi
quali
os se
NFR Framew
rança, perfo
Figur
No NFR
mplo, repres
s requisitos
ssa represen
pre dispon
zação de D
ional de I
elaciona po
urança afeta
O NFR
isitos não f
itativa dos i
eus requisito
work provê
ormance, di
ra 2.3 – Exem
R framework
sentado na
não-funcio
ntam a ope
nível é uma
isponibilid
Integridade
ositivamente
a positivam
framework
funcionais
impactos de
os não funci
ê suporte à
sponibilidad
mplo de mode
k os requisit
Figura 2.3
onais de Di
eracionaliza
a operacion
dade. Sistem
ser satisf
e com o d
mente e indir
k deve ser
a fim de ju
estas decisõ
ionais.
à modelage
de, dentre o
elagem de req
tos não-fun
, o requisit
isponibilida
ação dos re
nalização q
ma robusto
feito. O r
de Confiab
retamente n
utilizado p
ustificar as
ões é possív
em de requ
outros (CHU
quisitos utiliz
ncionais são
to não-func
ade e Integ
quisitos rel
que está co
o e Verifica
requisito n
bilidade, ou
a satisfação
para gerenc
s decisões d
el visualiza
uisitos não-
UNG et al.,
zando a abord
o representa
cional de Se
gridade. As
lacionados
ontribuindo
ar dados aj
ão-funciona
u seja, a s
o do softgoa
ciar os rela
de projeto.
ar o quão be
funcionais,
1999).
dagem NFR.
ados por nuv
egurança é
s nuvens co
a ele. Entã
positivame
judam o req
al de Seg
satisfação d
al Confiabil
acionamento
Através da
em um siste
14
tais como
vens. Neste
é composto
om a borda
ão, Sistema
ente para a
quisito não-
urança se
do softgoal
lidade.
os entre os
a avaliação
ema satisfez
4
o
e
o
a
a
a
-
e
l
s
o
z
2.2.3
nós i
tido
meio
aspec
(KIC
mem
um r
contr
3 V-graph
O V-grap
intencionais
como uma
o de identifi
ctos norma
CZALES et
mória”. Os n
elacioname
Figura
De acord
ribuição en
h
ph (YU, Y.
s (objetivos
abordagem
ficação de c
almente são
al., 1997),
nós operaci
ento entre ob
a 2.4 – Exemp
do com Silv
ntre os soft
et al., 2004
e softgoals
simplificad
candidatos a
o unidades
como “o a
onais (taref
bjetivos e so
plo de modela
va (2006), n
ftgoals Con
4) é um mo
s), nós oper
da do Fram
a aspectos
de decomp
acesso não
fas) existen
oftgoals.
agem de requ
na Figura 2
nfidencialid
odelo de obj
racionais (ta
mework i* (Y
em requisit
posição do
autorizado
ntes nos mo
uisitos utilizan
2.4(a) está r
dade, Integ
etivos que p
arefas) e se
YU, E. 1995
tos (RASHI
sistema qu
aos dados”
odelos semp
ndo a aborda
representado
gridade e
permite a d
eus relacion
5) para dem
ID et al., 2
ue não são
” ou “eficie
pre serão as
agem V-graph
o o relacion
Disponibil
15
descrição de
namentos. É
monstrar um
003). Estes
funcionais
ente uso da
ssociados a
h.
namento de
lidade e o
5
e
É
m
s
s
a
a
e
o
16
softgoal de Segurança, indicando uma contribuição positiva através do link + (ajuda). Na
Figura 2.4(b) temos que a representação do relacionamento de correlação entre o objetivo
Persistência e o softgoal Segurança, indicando interferência negativa, e entre o objetivo
Persistência e o softgoal Confidencialidade, indicando uma interferência positiva. O
objetivo Persistência é decomposto em outros dois objetivos, um sendo a Persistência em
Banco de Dados ou Persistência em Arquivo. O objetivo de Persistência em Banco de
Dados por sua vez pode ser decomposto em três tarefas (Inicia [BD], Conecta [BD] e
Desconecta [BD]) que devem ser executadas para satisfazê-lo.
Os elementos do V-graph nos possibilitam a extração de várias visões (Figura 2.4):
visão de dados, através dos tópicos; visão de objetos, através dos tópicos e tipos; influencia
direta ou indireta que uma característica exerce sobre as outras, através dos relacionamentos;
visão funcional, através de tipos; dentre outras.
2.2.4 O Original framework i*
O framework i* (YU, E. 1995) (i-estrela, que significa Intencionalmente Distribuído) é
uma abordagem GORE destinada a modelagem organizacional. Através deste framework é
possível modelar e analisar sistemas sob uma visão estratégica e intencional de processos que
englobam diversos participantes. Ele é centrado na representação dos relacionamentos ou
dependências entre atores estratégicos, sendo esses, representações dos stakeholders
envolvidos no sistema. Cada um dos atores envolvidos possui intenções que são representadas
como objetivos. Cada objetivo deve ser analisado, partindo do ponto de vista do ator, para que
seja possível identificar as dependências existentes entre atores. Desta forma, atores
dependem uns dos outros para que seus objetivos sejam atingidos, suas tarefas realizadas e os
recursos necessários sejam fornecidos. Essas dependências existentes entre os atores formam
uma rede social que representa o sistema e o seu ambiente.
A estrutura conceitual do i* deve ser utilizada para obter uma compreensão mais
apurada sobre os relacionamentos da organização, de acordo com os diversos atores do
sistema e compreender as razões envolvidas nos processos de decisões (YU, E. 1997).
De acordo com o descrito anteriormente, elencamos algumas potencialidades do i*
(YU, E. 1995):
17
i. a modelagem do ambiente organizacional em termos de relacionamentos
intencionais provê uma modelagem de ambiente mais rica em comparação aos
frameworks de requisitos existentes, que produzem modelos em termos de
entidades e atividades;
ii. a modelagem explícita das razões (do inglês, Rationales) proporcionam uma
compreensão mais profunda sobre o porquê de um determinado sistema ser
implantado em uma organização, bem como a maneira que ele será incorporado;
iii. suporte a análise dos sistemas propostos e configurações organizacionais em
relação aos interesses estratégicos dos atores. Interdependências entre atores são
analisadas em termos de oportunidades e vulnerabilidades. Atores são analisados
pela aplicabilidade, viabilidade e credibilidade.
O framework i* inicialmente proposto por (YU, E. 1995), muitas vezes não provê
soluções satisfatórias para problemas particulares enfrentados por diversos grupos de
pesquisa. Para suprir as dificuldades encontradas, cada um destes grupos desenvolveu
extensões da abordagem, com o intuito de obter soluções para os seus problemas. De acordo
com Lucena e outros (2008), a existência de várias extensões do i* pode ocasionar em:
i. cada variação pode apresentar diferenças sintáticas e semânticas;
ii. divisão do esforço, ao passo que cada grupo irá focar no desenvolvimento de
uma ferramenta que dê suporte a sua própria versão do i*;
iii. inibição da adoção do i* por parte de novos usuários.
Diante disso, na próxima seção serão apresentados os conceitos principais do
framework i*, detalhando os dois modelos de representações suportados por ele, bem como os
componentes de cada um desses modelos. Em seguida, serão apresentadas as extensões mais
relevantes do i* e, finalmente, será apresentada uma comparação entre essas versões.
2.2.4.1 Conceitos i*
O framework i* é formado basicamente por dois tipos de modelos responsáveis por
representar diferentes níveis de abstração sobre um ambiente organizacional. Estes são: o
modelo de Dependência Estratégica ou SD (do inglês, Strategic Dependency) e o modelo de
Razão Estratégica ou SR (do inglês, Strategic Rationale).
realiz
unida
difer
Exist
Independ
za ações pa
ade para a
renciados em
Age
conc
agen
Pap
um
pelo
Posi
agen
agen
orga
Os atore
tem seis tip
ISA
espe
Is-p
pode
parte
dente dos t
ara atingir s
qual depen
m três espec
ente (do in
cretas. Pode
nte pode ocu
pel (do inglê
ator inserid
os agentes d
ição (do i
ntes e os p
nte, ou sej
anização, na
Figura 2.5 –
es podem s
os de relaci
: esta ass
ecializado d
art-of: ness
em conter s
es;
ipos de mo
eus objetivo
ndências int
cializações (
nglês, Age
em represen
upar uma P
ês, Role): re
das em det
a organizaç
inglês, Pos
apéis. Uma
eja, represe
a qual o age
– Especializa
se relaciona
ionamento e
ociação re
de outro ator
sa associaçã
sub-partes. E
odelos, um
os. É utiliza
tencionais p
(Figura 2.5)
ent): são a
ntar humano
Posição, que
epresenta c
terminados
ção.
sition): rep
a posição é
enta uma
ente pode de
ações de atore
ar entre si,
entre atores
epresenta u
r;
ão as especi
Existe uma
ator é con
ado para re
possam ser
) (YU, 1995
atores que
os ou agent
e cobre um p
aracterística
contextos
presenta en
é um conjun
posição oc
esempenhar
es e relaciona
, como pod
(Figura 2.6
uma genera
ializações d
dependênc
siderado um
ferenciar ge
atribuídas.
5):
possuem
tes de softw
papel, ou at
as abstratas
sociais. Es
ntidades int
nto de papé
cupada pel
r várias funç
mento entre
de ser obse
6) (YU, E. 1
alização, co
de atores (ag
cia intencion
ma entidade
enericamen
. Os atores
manifestaç
ware ou har
té realizar u
do compor
ste pode se
termediària
éis realizad
lo agente
ções (papéis
atores
ervado na
1995):
omo um
gente, papel
nal entre o
18
e ativa que
nte qualquer
podem ser
ões físicas
rdware. Um
m Papel.
rtamento de
er realizado
as entre os
dos por um
dentro da
s).
Figura 2.5.
ator sendo
l e posição)
todo e suas
8
e
r
r
s
m
e
o
s
m
a
.
o
)
s
2.2.4
de um
inten
vulne
conju
os en
ligaç
ator
aque
depe
possa
Play
Cov
cobr
Occ
posi
ocup
INS
gera
4.1.1 O Mo
O model
ma organiz
nções por trá
Esse mo
erabilidades
unto de nós
nvolvidos n
ção entre ato
que depend
le que sati
ender é o at
a ser realiza
ys: é usada e
ers: é usada
re;
upies: esta
ição, ou sej
pada por ele
S: é utilizad
al.
odelo de Dep
lo SD forne
ação. Um
ás das ativid
odelo pode
s dentro de
s (nodes) e u
no processo
ores indica q
de de outro
isfaz a dep
tor que dep
ado, conform
entre um ag
a para descr
a associação
a, o agente
e;
da para repr
Figura 2
pendências
ce uma des
modelo de
dades e flux
ajudar a id
e um mode
um conjunt
o e os seus
que um ator
para satisfa
pendência e
pende de um
me pode ser
gente e um p
rever uma r
o é utilizad
executa to
resentar um
2.6 – Associaç
s Estratégica
scrição inten
processo in
xos envolvid
dentificar o
elo de proc
to de ligaçõ
s relacionam
r depende d
azer seus ob
entre dois a
m dependee
r observado
papel realiz
relação entre
da para mo
dos os papé
a instância
ção entre ato
a (SD)
ncional sobr
ntencional p
dos (YU, E.
os stakehold
cesso intenc
es (links) q
mentos. Cad
de outro ato
bjetivos é d
atores é de
e para que u
o na Figura 2
ado pelo ag
e uma posiç
strar que u
éis que são
específica
res
re as depend
procura cap
. 1995).
ders, analis
cional. Para
ue são utili
da nó repre
r para satisf
enominado
enominado
um acordo
2.7.
gente;
ção e os pap
um agente
cobertos p
de uma ent
dências ent
pturar as m
sar as oport
a isto, é ut
izados para
esenta um a
fazer seus o
depender,
dependee.
(dependum
19
peis que ela
ocupa uma
ela posição
tidade mais
re os atores
otivações e
tunidades e
tilizado um
representar
ator e cada
objetivos. O
enquanto o
Então, um
) entre eles
9
a
a
o
s
s
e
e
m
r
a
O
o
m
s
(o tip
(reso
um r
depe
finali
(YU,
Já os rela
po do depe
ources) e sof
recurso, ex
ndente, ou
izado. A Fig
F
Será apr
, E. 1995):
Na
para
satis
estad
acionament
endum) e po
oftgoal. Qua
xecutar uma
realizar alg
gura 2.8 apr
Figura 2.8 – T
resentada um
dependênci
a que um d
sfação será
do do mund
Figura 2.
tos de depen
odem ser d
ando, em um
a tarefa de
guma tarefa
resenta os ti
Tipos de relac
ma breve d
ia de objeti
determinado
alcançada. U
do que um a
.7 – Dependên
ndência util
de quatro tip
m relacionam
sua respon
a para alcan
ipos de liga
cionamentos
descrição so
ivo, um ato
o objetivo
Um objetiv
ator gostaria
ncia entre ato
lizados no i*
pos: objetiv
mento entre
nsabilidade,
nçar um sof
ações de dep
de dependên
obre as liga
or (depende
seja satisfe
vo pode ser
a de alcança
ores
* descrevem
vo (goal), t
e atores, o d
, atender a
ftgoal, o aco
pendência.
cia entre ator
ções repres
er) depende
eito, não im
entendido c
ar.
m a natureza
tarefas (task
dependee dis
a um objeti
ordo será s
res no i*
sentadas na
e de outro
mportando
como uma c
20
a do acordo
k), recursos
sponibilizar
ivo do ator
atisfeito ou
Figura 2.8
(dependee)
como esta
condição ou
0
o
s
r
r
u
8
)
a
u
depe
Na d
Em
solic
Con
nece
Na d
uma
tudo
pess
Na
func
outr
Nestes r
ndência ou
Abe
atore
repr
Com
depe
sem
Crít
depe
toda
“X”
dependência
conjunto c
citação. Tar
ntudo, tarefa
essários par
dependênci
a entidade f
o o que pod
soas, bens, e
dependênci
cional (gera
o ator (depe
relacioname
vulnerabili
erta (open)
es, o ator d
esentada po
mpromissad
endência en
conseqüên
tica (critica
ender são a
a a rede de
.
a de tarefa,
com a req
refas podem
fas em i* n
a sua execu
a de recurs
física ou um
de ser utiliz
etc.
ia de softgo
almente refe
endee).
entos entre
dades, conf
: em uma
depender nã
or “O”.
da (comm
ntre os atore
cias graves.
al): na falh
afetadas gra
relacionam
Figura 2.9
, o ator (dep
quisição, se
m ser vistas
não possuem
ução.
so, um ator
ma informa
zado para at
oal, um ato
ferente à qu
atores, aind
forme apres
possível fa
ão será afe
mited): em
es, as intenç
. Graficame
ha da rela
avemente, s
mentos e dep
– Graus de d
pendee) é r
egue inform
s como solu
m uma esp
r (depender
ação. Um r
tingir um o
or (depende
ualidade de
da é possív
entado graf
alha na sat
etado. A de
uma pos
ções do ato
ente não pos
ção de dep
sendo neces
pendências.
dependência
equisitado a
mações sob
uções, oper
pecificação
r) depende
ecurso pod
bjetivo: est
er) espera q
um serviç
vel identific
ficamente na
isfação da
ependência
ssível falh
r depender
ssui sinal re
pendência,
ssário geren
Graficamen
em i*
a executar
bre como s
rações, pro
completa
da disponi
de ser enten
tratégias, ex
que um req
ço) seja alc
car diferente
a Figura 2.9
dependênc
aberta é gr
ha na sati
serão afeta
elacionado.
as intençõ
nciar a via
nte é repres
21
uma tarefa.
satisfazer a
cessos, etc.
dos passos
bilidade de
ndido como
xperiências,
quisito não-
ançado por
es graus de
9:
cia entre os
raficamente
isfação da
adas, porém
ões do ator
bilidade de
sentada por
.
a
.
s
e
o
,
-
r
e
s
e
a
m
r
e
r
2.2.4
em t
mant
utiliz
sobre
inten
diver
estru
cada
(task
relac
Mean
Link)
um o
softg
form
expre
como
4.1.2 O Mo
O model
termos de e
tém um nív
zado para d
e os atores
nções existe
rsos tipos d
utural, a fim
ator são ide
Assim co
ks), recursos
cionamentos
ns-End Lin
) e as ligaçõ
As ligaç
objetivo a s
goal a ser s
ma de uma t
esso atravé
o pode ser
odelo Estrat
lo SR (Stra
elementos d
vel de abstr
escrever os
estratégicos
ntes por trá
de nós e liga
m de expres
entificadas
omo no SD
s (resources
s, pois o mo
k), as ligaç
ões de contr
ões meio-fi
ser satisfeito
satisfeito - e
tarefa, mas
s de uma t
r visualizad
tégico da Ra
ategic Ratio
de processo
ração apen
relacionam
s do process
ás das depen
ações, que t
sar as razõe
e representa
Figura
D, o SR pos
s) e softgoa
odelo SR di
ções de dec
ribuição (do
im indicam
o, uma tare
e um “meio
também po
tarefa o “fi
do na Figur
azão (SR)
onale) apres
o e as razõ
as sobre as
mentos inter
so através d
ndências ent
trabalham e
es existente
adas dentro
a 2.10 – Ator e
ssui os mes
als. Entretan
spõe de ma
composição
o inglês, Con
m um relacio
efa a ser ex
o” de ating
ode ser um
im” pode s
ra 2.11(a).
senta uma d
ões por trás
s relações e
rnos a fim d
da investiga
tre os atores
m conjunto
es em um p
da fronteira
e sua fronteir
smos tipos
nto existe u
ais três tipos
de tarefas
ntribution L
onamento en
xecutada, um
gi-lo. Um “
m objetivo o
er um obje
Caso o “m
descrição es
s deles. En
externas en
de prover um
ação mais de
s. O SR é um
o para forne
processo. A
a de cada at
ra
de nós: obj
m diferenci
s: as ligaçõe
(do inglês
Link).
ntre um nó
m recurso a
meio” é us
ou um softg
etivo, tarefa
meio” seja
stratégica d
nquanto o m
ntre os ator
m maior en
etalhada da
m modelo g
ecer uma rep
As intencion
tor (Figura
jetivos (goa
ial quanto a
es meio-fim
s, Task Dec
“fim” – qu
a ser produz
sualmente e
goal. Se um
a, recurso o
representa
22
do processo
modelo SD
res, o SR é
ntendimento
as razões ou
gráfico com
presentação
nalidades de
2.10).
als), tarefas
aos tipos de
m (do inglês,
composition
ue pode ser
zido ou um
expresso na
m “meio” é
ou softgoal,
do por um
2
o
D
é
o
u
m
o
e
s
e
,
n
r
m
a
é
,
m
objet
2.11(
softg
2.11(
que,
Pode
tarefa
forem
contr
tivo o “fim
(b). Também
goals seja sa
(c).
Já as lig
segundo Y
endo existir
fa decompos
m realizado
As ligaç
ribui para a
Os tipos
Mak
m” também
m é possíve
atisfeito po
ações de de
Yu, E. (199
diversos el
sta só poder
s ou satisfei
F
ões de con
satisfação d
de contribu
ke: é uma co
deverá ser
el existir a
r uma taref
Figura 2.1
ecomposiçã
95), podem
ementos co
rá ser consid
itos. Esta lig
Figura 2.12 –
tribuição m
de um deter
uições são (F
ontribuição
r um objet
ligação me
fa (YU, E.
11 – Tipos de
ão de tarefa
m ser outra
onectados po
derada com
gação é rep
– Tipos de dec
modelam a f
rminado sof
Figura 2.13
positiva fo
tivo, como
eio-fim entre
1995) com
ligações meio
s, ligam um
as tarefas, o
or uma ligaç
mpleta quand
resentada n
composição d
forma que u
ftgoal.
3):
rte o suficie
pode ser v
e softgoals,
mo pode ser
o-fim
m nó tarefa
objetivos, r
ção de deco
do todos os
a Figura 2.1
de tarefa
um element
ente para sa
visualizado
, desde que
visualizada
a outros co
recursos ou
omposição d
seus nós co
12.
nto (tarefa o
atisfazer um
23
o na Figura
algum dos
a na Figura
omponentes
u softgoals.
de tarefas, a
omponentes
ou softgoal)
m softgoal;
3
a
s
a
s
.
a
s
)
2.2.4
exist
apres
Som
desc
Help
um s
Unk
Som
desc
Hur
com
Or:
for s
And
fore
Brea
softg
4.1.3 Restr
Em resu
tentes no i*
sentado no C
me +: é um
conhecido;
p: é uma co
softgoal soz
known: é um
me -: é uma
conhecido;
rt: é uma
mprometer um
é uma con
satisfeito;
d: é uma co
m satisfeito
ak: é uma
goal.
Figu
ições dos re
umo, as tab
*. Estas rest
Capítulo 4.
ma contribui
ontribuição
zinha;
ma contribu
a contribuiç
contribuiç
m softgoal
tribuição cu
ontribuição
os;
contribuiç
ra 2.13 – Lig
elacionamen
belas a segu
trições serã
ição positiv
parcialmen
uição cuja in
ção negativ
ção parcial
sozinha;
ujo destino
cujo destin
ão negativa
gações de cont
ntos
uir apresen
ão utilizadas
va, entretant
nte positiva,
nfluência é d
va, entretant
lmente neg
é satisfeito
no é satisfei
a forte o s
tribuições pa
tam todas
s futuramen
to possui u
, pois ela nã
desconhecid
to possui u
gativa, poi
o se algum
ito se todos
suficiente p
ara softgoals.
as restriçõe
nte para com
um nível de
ão consegu
da;
um nível de
is ela não
dos elemen
s os elemen
para compr
es de relac
mpreensão
24
e satisfação
ue satisfazer
e satisfação
o consegue
ntos origem
ntos origem
rometer um
ionamentos
do contúdo
4
o
r
o
e
m
m
m
s
o
pela
ligaç
todos
uma
inten
Lig(Open
atore
entre
espec
2.2.4
repre
agen
execu
agen
anter
utiliz
tamb
por ú
seja o
A Tabela
linguagem
ções de depe
s os atores (
relação b
ncional) e de
Relacionam
gação de Depen, Critical e C
A Tabel
es, sendo es
e atores do
cífico, pape
4.1. A mesm
esenta um p
nte ocupand
uta um det
nte.
A Tabe
riormente n
zando uma t
bém pode se
último um s
outro softgo
a 2.1 aprese
entre os ato
endência: O
(Ator, Agen
inária: dep
ependee (qu
Tabmento
endência Committed)
la 2.2 most
stas: ISA, Is
o mesmo ti
el, posição
ma regra da
papel que é
do uma posi
terminado p
ela 2.3 apr
na Seção de
tarefa. Nest
er um meio
softgoal pod
oal e que o m
enta todas a
ores e os el
Open, Critica
nte, Posição
pender (qua
ualquer tipo
bela 2.1 – Re
tra todas as
s part of, C
ipo como,
e agente po
ligação ISA
é “coberto”
ição na org
papel. Por
resenta as
e modelage
te caso o fim
desde que,
de ser utiliz
meio seja sa
as possíveis
lementos in
al e Commi
o e Papel) d
alquer tipo
o de ator), co
estrições da L
s combinaç
Covers, Occ
por exemp
odem ser u
A é aplicad
” por uma p
ganização. A
fim a ligaç
restrições
em estratégi
m pode ser
, obrigatoria
zado como
atisfeito por
combinaçõ
ntencionais.
itted. É poss
desde que, p
o de ator),
omo detalha
Ligação de DeRest
ões possíve
cupies, Play
plo, agente-
um (ISA) at
da para a lig
posição. A
A ligação P
ção INS ac
da ligaçã
ica (2.2.4.1
qualquer el
amente, o fi
um meio d
r uma tarefa
ões de relaci
A figura p
sível aconte
ara o eleme
dependum
ado na Seçã
ependência trição
eis de cada
ys e INS. A
-agente, en
tor, bem co
gação Is par
ligação Oc
Plays aconte
ontece de u
ão Meio-fim
.2) geralme
lemento int
fim também
desde que, o
a.
ionamentos
ermite os tr
ecer combin
ento intenci
m (qualquer
ão 2.2.4.1.1
a uma das l
A ligação IS
ntretanto em
omo descrit
rt of. A liga
ccupies rep
ece quando
um agente
m como j
ente como
tencional. U
m seja outro
obrigatoriam
25
s permitidas
rês tipos de
nações entre
onal, exista
r elemento
.
ligações de
SA acontece
m um caso
o na Seção
ação covers
presenta um
um agente
para outro
já descrito
um meio é
Um objetivo
objetivo. E
mente o fim
5
s
e
e
a
o
e
e
o
o
s
m
e
o
o
é
o
E
m
Taref
Lig
Ligaçã
Liga
Ligaç
Liga
Lig
Já a Tab
fas também
Relacionamen
gação de Ator
ão de Ator – I
ação de Ator –
ão de Ator – O
ação de Ator –
gação de Ator
Relacionamen
Meio-fim
bela 2.4 ap
m descritas
Tabela 2.2 –nto
- ISA
Is Part Of
– Covers
Occupies
– Plays
– INS
Tabela 2.3 –nto
presenta as
anteriormen
– Restrições d
– Restrições d
restrições a
nte na Seç
das Ligações d
da Ligação M
atribuídas à
ão de mod
de Ator Restriç
eio-fim Restri
às ligações
elagem estr
ição
ição
de Decom
ratégica (2.
26
mposição de
.2.4.1.2). A
6
e
A
tarefa
inten
pode
regra
2.3
nece
a de
muito
criad
As s
aprof
fa é o único
ncional atrav
E por úl
em ocorrer
a pode ser a
Deco
Liga
ALGUMA
Várias l
ssidades esp
senvolver e
os dos caso
dos e/ou mo
subseções a
fundados so
o elemento i
vés desta lig
ltimo a Ta
de uma tar
aplicada a qu
Tabela 2.Relacionamen
omposição de
TabRelacionamen
ação de Contr
AS VARIAÇ
inguagens
pecíficas en
estratégias
os novos d
odificaram a
a seguir ap
obre estas p
intencional
gação.
abela 2.5 ap
efa para um
ualquer um
4 – Restriçõento
Tarefas
bela 2.5 – Resnto
ibuição
ÇÕES DO I
foram con
nfrentadas.
para que o
dialetos ou
as restrições
presentam r
odem ser en
que pode s
presenta as
m softgoal o
dos tipos d
es da Ligação
strições da L
I*
struídas ba
Tais necess
o i* pudess
simplesmen
s de relacion
resumidame
ncontrado n
ser decomp
restrições
ou de um s
de contribuiç
o de Decompo
igação de Co
(Make, BrU
aseadas no
sidades leva
se suportar
nte, novos
namentos d
ente algum
no Capítulo
osto em qu
da ligação
softgoal par
ção apresen
osição de TarRestriç
ontribuição Restriç
reak, SomePluUnknown, Hur
i* Origina
aram divers
tais neces
elementos
e elementos
mas destas l
4.
ualquer outr
o de Contri
ra outro sof
ntados na Fi
refas ição
ição
us, SomeMinusrt,Or e And)
al a fim de
sos grupos d
sidades. Pa
de modela
s de modela
linguagens
27
ro elemento
buição que
ftgoal. Esta
gura 2.13.
s, Help,
e satisfazer
de pesquisa
ara isto em
agem foram
agem do i*.
e detalhes
7
o
e
a
r
a
m
m
.
s
28
2.3.1 i* Wiki
O i* Wiki (GRAU et al., 2008) é uma versão simplificada do framework i* original.
Esta versão é voltada especialmente aos novos usuários como guia de estudo, mas também
serve como guia para os usuários mais experientes. São abordados os conceitos fundamentais
do i*, tais como os modelos SD e SR, bem como seus elementos e ligações. Entretanto, por
ser uma versão mais leve que a proposta original do i*, uma de suas restrições
(especificamente a ligação meio-fim) sofreu alterações a fim de prover maior usabilidade aos
usuários. Mais detalhes sobre as diferenças com a i* original serão tratados no Capítulo 4.
2.3.2 Tropos
O projeto Tropos (CASTRO, MYLOPOULOS, 2000) propõe uma metodologia para o
desenvolvimento de softwares orientados a agentes, que possui as seguintes atividades:
engenharia de requisitos (iniciais e finais), projeto arquitetural, projeto detalhado e
implementação. É centrada na engenharia de requisitos a fim de reduzir a incompatibilidade
entre o sistema e o seu ambiente. Os conceitos e modelos do framework i* (YU, E. 1995) são
utilizados nas fases de requisitos, arquitetura e projeto detalhado. Além da versão proposta
por Castro e outros (2000 e 2002), outras versões do Tropos foram surgindo com o tempo
(BRESCIANI et al., 2004) (SUSI et al., 2005).
2.3.3 GRL
O GRL (do inglês, Goal-oriented Requirement Language) (AMYOT et al., 2009) foi
desenvolvido especificamente com o propósito de amadurecer a modelagem dos requisitos
não-funcionais representados nos modelos i*. O autor afirma que é importante o engenheiro
de requisitos estar preocupado com o “porquê” da escolha de inserir certos comportamentos e
de seguir certas restrições. Isto é chamado de posição estratégica, onde o engenheiro de
requisitos trabalha em um nível mais elevado, obtendo a oportunidade de considerar as reais
necessidades dos stakeholders e/ou de tentar evitar vulnerabilidades no seu ambiente.
29
2.3.4 i*-c
O i*-c é uma abordagem baseada no i* Wiki que tem como objetivo ajustar os
modelos i* para que os mesmos pudessem ser usados para representar Linhas de Produtos de
Software. Dessa forma, Borba (2009) propôs uma extensão da linguagem i*, denominada i*-c
(i* with cardinality), onde adicionou cardinalidade em alguns elementos de modelagem,
permitindo capturar mais informações sobre a variabilidade de uma LPS, de forma semelhante
aos modelos de features propostos por Czarnecki e Eisenecker (2000).
2.3.5 i* Aspectual
Alencar e outros (2010) propôs uma variação do i* original com conceitos e métodos
da orientação a aspectos (RASHID et al., 2003), com a finalidade de aumentar a modularidade
e diminuir a complexidade visual dos modelos i*. Para isto os autores do i* Aspectual
perceberam a necessidade de separar os interesses transversais (do inglês, Crosscutting
Concerns) do resto dos elementos do modelo. Interesses são considerados transversais quando
seu comportamento pode ter impacto em (ou influenciar) múltiplos compartimentos ou
componentes do sistema. Estes interesses transversais foram tratados como novos elementos
de modelagem a fim de facilitar a definição dos novos relacionamentos que foram inseridos.
2.4 CONSIDERAÇÕES FINAIS
Neste capítulo foi apresentada uma visão geral sobre a Engenharia de Requisitos e,
especificamente, sobre a Engenharia de Requisitos Orientada a Objetivos. Foram descritas
algumas propostas de abordagens para modelagem de requisitos orientada a objetivos: o
método KAOS, o NFR Framework, o V-graph e o Framework i*.
Dentre as abordagens apresentadas, este trabalho tem como foco principal o
framework i*. O principal motivo pela qual foi escolhida é que existe uma grande variação de
linguagens que foram construídas baseadas no i*. A partir disso percebeu-se que muitas
destas linguagens não possuíam e/ou ainda não possuem suporte ferramental de modelagem e
30
assim a linguagem tornou-se o foco principal deste trabalho. Para isto foram apresentados os
seus elementos de modelagem bem como as restrições de relacionamento que ocorrem entre
eles.
Algumas das variações citadas foram apresentadas resumidamente a caráter de
conhecimento. Tais linguagens serão apresentadas em mais detalhes no Capítulo 4.
Sendo assim, no próximo capítulo será apresentado os conceitos do paradigma da
Engenharia de Linhas de Produto de Software a fim de prover o embasamento necessário para
identificar as diferenças entre as linguagens baseadas no i* e, assim, capturar variabilidade
existente entre elas.
3 E
Este
como
basea
desta
ativid
ativid
ENGENHARIA DE LINHAS DE PRODUTO DE SOFTWARE
capítulo di
o subsídio
adas no i*,
as bem com
dades realiz
dades e por
iscute os co
a identific
sejam esta
mo as restriçõ
zadas para
último, ser
onceitos da
cação das
as referente
ões de relac
a ELPS e
rão apresent
Engenharia
variações
s aos eleme
cionamento
e o modelo
tadas as con
a de Linhas
existentes
entos de m
s existentes
o de feature
nsiderações
s de Produto
entre as li
odelagem p
. Serão apre
es, artefato
finais.
o de Softw
inguagens
presente em
esentadas a
o central us
31
are (ELPS)
construídas
m cada uma
s principais
sado nestas
)
s
a
s
s
32
3.1 LINHAS DE PRODUTO DE SOFTWARE
Uma Linha de Produtos de Software (LPS) é um conjunto de sistemas de software que
compartilham características comuns e gerenciam um conjunto de características particulares
que satisfaçam necessidades específicas dos clientes (SEI, 2010). Esse paradigma vem
ganhando cada vez importância para as empresas de desenvolvimento de software por
proporcionar redução de tempo e custo e aumento na produtividade e qualidade de seus
produtos, permitindo assim uma entrada rápida destes produtos no mercado. De acordo com
Nascimento (2008) os pontos mais relevantes sobre os benefícios de LPS são:
Aumento da qualidade: uma vez que os artefatos numa LPS serão reutilizados
em outros produtos e, conseqüentemente revisados e testados temos maiores
chances da detecção de falhas e correções aumentando, assim, a qualidade de
todos os produtos.
Redução do esforço de manutenção: uma vez que os artefatos da linha possuem
maior qualidade, eles podem ser reutilizados com maior eficiência. Uma vez
queas mudanças serão propagadas em todos os produtos em que estes artefatos
sejam utilizados e, conseqüentemente, os produtos apresentarão uma redução de
defeitos.
Redução dos custos de desenvolvimento: devido às potencialidades propiciadas
pelo reuso, as preocupações de desenvolvimento envolverão a evolução do
produto e o melhoramento das funcionalidades. Uma visão baseada no
crescimento, em novos investimentos, não na manutenção ou “reinvenção da
roda”.
Redução do tempo para o produto chegar ao mercado: uma vez que depois de
certo tempo a base de artefatos reutilizáveis dará suporte à criação dos produtos da
linha;
Aprimorar estimativas de custo: boa parte do núcleo comum às aplicações
encontra-se construído e mensurado, assim fica mais fácil avaliar o custo daquilo
que resta ser feito.
Benefícios aos clientes: inclui a minimização do preço das aplicações; a
facilidade de uso, e adaptação aos novos produtos (uma vez que os clientes já
estão acostumados a utilizar uma determinada plataforma na qual o seu novo
33
produto é baseado); e, o menor número de falhas devido à qualidade dos
componentes adicionados.
De acordo com Alves (ALVES, 2007), as concepções preliminares sobre uma Linha
de Produto de Software (LPS) derivam de estudos realizados por Dijkstra (1976) e Parnas
(1972) a respeito da Variabilidade de Software (Software Variability). Nesses estudos são
avaliadas algumas questões importantes sobre: (i) as decisões em nível de projeto, até que
sejam definidos os membros individuais de uma família de produtos; (ii) e o gerenciamento
da variabilidade.
No momento em que se abrangem esses conceitos, pode-se definir uma sistemática de
construção de aplicações a partir da seleção de funcionalidades desejáveis, definidas dentro de
um domínio de atuação (por exemplo, jogos, e-commerce, etc.) e a partir de artefatos que
podem ser reutilizados (artefatos básicos ou core assets).
Nesse contexto, surge a LPS, que é um conjunto de produtos de software derivados a
partir de uma base compartilhada de artefatos, onde se procura reutilizar o máximo do esforço
já empreendido, sem esquecer as peculiaridades de cada aplicação. Também se emprega, para
designar uma LPS, o termo Família de Produtos de Software.
A LPS é apoiada pela Engenharia de Linhas de Produto de Software (ELPS) que,
segundo Pohl e outros (2005), diz respeito ao conjunto de atividades de desenvolvimento de
software que dão apoio à criação sistematizada de artefatos de software, legíveis, controlados
e modulares, a fim de que se possa identificar um grupo de componentes comuns, assim como
tratar a parcela de características particularidades (ou variabilidades) dos produtos de
software.
De acordo com o Software Engineering Institute (SEI, 2010), as atividades da ELPS
são (Figura 3.1):
Engenharia do Domínio: engloba a fase de desenvolvimento de core assets5,
onde são estabelecidas as características comuns da LPS.
Engenharia da Aplicação: é responsável por derivar aplicações de uma linha de
produtos com base nos core assets pré-definidos. Essa atividade depende tanto
dos artefatos gerados na atividade anterior, como dos requisitos do produto a ser
desenvolvido.
5 São os fundamentos comuns a um mesmo produto, por exemplo: arquiteturas, planos de teste, casos de teste, documentação de projeto, especificação de requisitos, modelos de domínio, etc (POHL et al., 2005).
desen
um c
qualq
3.1.1
ELPS
nece
dos p
padrõ
Ger
dese
capa
para
orga
dese
orga
Cada c
nvolviment
constante m
quer ordem
Figura 3.1 –
1 Engenha
Segundo
S no qual o
ssário ter at
produtos (en
ões organiz
renciamento
envolviment
acitação pro
a a mudança
anizacional
envolviment
anizacional
írculo da
o de uma li
movimento,
.
Visão da En
aria de dom
o Pohl e out
os pontos c
tenção para
nxergar as v
zacionais a s
o: essa at
to de uma l
ofissional d
a e lideranç
como t
to dos cor
trata da pró
Figura 3
inha de pro
, mostrando
genharia de L
mínio
tros (2005),
omuns e va
alguns aspe
variabilidad
serem segui
tividade tem
linha de pro
dos envolvid
ça voltadas
técnico. O
re assets e
ópria organi
3.1 represe
odutos. Toda
o que são
Linhas de Pr
, a Engenha
ariáveis da
ectos releva
des); (ii) rest
idos, leis ou
m um pap
odutos. É res
dos e por p
para a LPS
O gerenc
e do prod
zação.
enta uma
as elas estã
altamente
rodutos de So
aria de Dom
linha de pr
antes na cria
trições da p
u regulamen
pel fundam
sponsável p
rover empe
. O gerenci
iamento t
uto, enqua
das ativid
o relaciona
iterativas
ftware. Adap
mínio (Figur
rodutos são
ação dos cor
rodução (po
ntos); (iii) e
mental no s
pelo aperfei
enho e disp
iamento pod
técnico e
anto o ger
dades esse
adas e as set
e podem o
ptado de (SEI
ra 3.2) é o p
o definidos.
re assets: (i
or exemplo,
estratégias d
34
sucesso do
çoamento e
ponibilidade
de ser tanto
engloba o
enciamento
enciais do
tas indicam
ocorrer em
I, 2010)
processo da
Por isso, é
i) restrições
, considerar
de produção
4
o
e
e
o
o
o
o
m
m
a
é
s
r
o
(por
consi
exemplo, d
ideração de
Figura
Os subpr
Ger
dese
inve
técn
linha
Eng
requ
da L
Proj
cont
esca
arqu
aplic
definir o esc
e artefatos p
a 3.2 – O proc
rocessos da
renciamento
envolviment
estimento e
nicas objetiv
a de produto
genharia de
uisitos e par
LPS.
jeto de Do
tém os pon
ala de ben
uitetura de r
cações da li
copo da linh
reexistentes
cesso de engen
Engenharia
o de Prod
to, da prod
e satisfazer
vas para def
os;
e Requisito
ra isso é feit
omínio: é
ntos de vari
ns adequad
referência f
inha de prod
ha de produ
s na organiz
nharia de dom
a de Domín
duto: tem
dução e do
as necess
finir o que
os de Domín
ta a análise
a arquitetu
iação, a pla
dos às nec
fornece um
dutos;
utos, criar o
zação.
mínio. Adapt
nio são descr
como prin
o marketing
sidades dos
faz parte e
nio: nesta at
de pontos c
ura de refer
ataforma de
cessidades
a estrutura
o plano de p
tado de Pohl
ritos resumi
ncipal obje
g de produt
s clientes.
o que não
tividade pre
comuns e va
rência da li
e suporte e
individuais
de alto nív
produção, e
e outros(2005
idamente a
etivo a inte
tos para m
Esta ativid
faz do esco
etende-se id
ariáveis ent
inha de pr
a produçã
s dos clie
vel, comum
35
etc.); e, (iv)
5)
seguir:
egração do
maximizar o
dade utiliza
opo de uma
dentificar os
tre produtos
odutos que
ão em larga
entes. Essa
m a todas as
5
)
o
o
a
a
s
s
e
a
a
s
realiz
3.1.2
ELPS
pela
resul
Rea
impl
Test
evita
Os result
zação da En
2 Engenha
Segundo
S no qual a
exploração
ltados dos v
Figura 3
Os subpr
Eng
requ
alização de
lementação
tes de Dom
ando que os
tados desse
ngenharia d
aria de apl
o Pohl e outr
s aplicações
o da variab
vários subpr
3.3 – O proce
rocessos da
genharia de
uisitos dos s
Domínio: n
dos compo
mínio: consi
s erros sejam
es cinco sub
e Aplicação
icação
ros (2005),
s são constr
ilidade da
rocessos da
esso de engen
Engenharia
e Requisito
stakeholder
nesta ativid
onentes reut
iste em vali
m propagad
bprocessos s
o.
a Engenhar
ruídas atrav
linha de pr
Engenharia
nharia da apli
a de Aplicaç
os de Aplic
rs para a ap
dade são tra
tilizáveis de
idar e verifi
dos para o pr
supracitado
ria de Aplic
vés da reutil
rodutos. Es
a de Domíni
icação. Adap
ção são des
ação: tem c
plicação. É n
atados os de
e software;
icar os com
rocesso de t
s são impor
cação (Figur
ização dos
sses artefato
io, vistos an
tado de Pohl
critos resum
como objeti
necessário f
etalhes do p
mponentes re
testes de ap
rtantes para
ra 3.3) é o p
artefatos de
os de domí
nteriormente
e outros (200
midamente a
ivo a identi
fazer um m36
projeto e da
eutilizáveis,
licação.
a a eficiente
processo da
e domínio e
ínio são os
e.
05)
a seguir:
ficação dos
mapeamento6
a
,
e
a
e
s
s
o
37
entre os requisitos da aplicação e os requisitos resultantes do processo de
Engenharia de Domínio. A principal preocupação dessa atividade é detectar
diferenças entre requisitos de aplicação e os produzidos na engenharia de
requisitos de domínio, para que se possa reutilizar o máximo possível dos
requisitos de domínio. É feita a documentação que contém o modelo de
variabilidade de domínio com os dados correspondentes aos pontos que a
aplicação reutiliza.
Projeto de Aplicação: este subprocesso contém as atividades de produção da
arquitetura da aplicação que é semelhante ao projeto de software de um sistema
único. A arquitetura da aplicação determina toda a estrutura de uma aplicação
específica e tem que satisfazer os requisitos dessa aplicação.
Realização de Aplicação: são tratados todos os detalhes de projeto,
implementação e configuração de componentes. É produzida a aplicação desejada
de acordo com a seleção e configuração dos componentes de software
reutilizáveis e com as características específicas da aplicação. Após a junção de
todos os componentes, a aplicação poderá ser testada.
Testes de Aplicação: consistem em atividades necessárias para validar e verificar
uma aplicação de acordo com a sua especificação. É necessário definir um
conjunto de testes que se apliquem adequadamente à aplicação a ser testada.
Também é útil ter uma documentação dos testes para que se possa repetir o
processo de teste da aplicação.
Para produzir uma linha de produtos é importante analisar as similaridades e
variabilidades de forma a produzir produtos com as mesmas características base, mas com
diferenças que ajudam a dar maior resposta às necessidades individuais dos clientes. As
similaridades e variabilidades podem ser capturadas com modelos de features (KANG et al.,
2002). Esses modelos são apresentados mais detalhadamente na Seção 3.2.1.
Com base no modelo de features, a Engenharia da Aplicação poderá realizar a criação
dos diversos tipos de aplicação através, por exemplo, da escolha de requisitos que devem ou
não existir num determinado artefato.
38
3.1.3 Gerenciamento
A atividade de Gerenciamento deve ser executada para permear e controlar todo o
processo. Os processos dentro de uma LPS não podem ser constituídos de maneira ad hoc,
uma vez que a dependência de artefatos entre os produtos da linha é bastante elevada.
Responsabilidades devem ser distribuídas de maneira eficiente. É necessário que alguém
esteja monitorando as diversas atividades para dar: as diretrizes básicas para a realização das
atividades; identificar e mitigar os riscos inerentes a inserção ou retirada de novos produtos da
linha; e, finalmente, realizar a comunicação com o cliente e com os fornecedores dos insumos.
Alguns outros requisitos gerais devem ser atendidos para o estabelecimento, dentro da
organização, das atividades de ELPS (Figura 3.1), a fim de que se obtenha o grau de reuso
esperado, com a qualidade final desejada para os produtos da linha.
De acordo com (ALVES, 2007) podemos relacionar algumas qualidades desejáveis de
uma LPS: (i) a Família de Produtos deve ser claramente identificada; (ii) a Família deve ser
definida e projetada como uma Linha de Produtos, ou seja, não apenas através da aplicação de
boas práticas de desenvolvimento de software e implementação de padrões de projeto, na fase
de desenvolvimento do sistema. A especificação de uma LPS envolve todas as disciplinas da
Engenharia de Software, cada qual com a sua contribuição específica; (iii) a Família de
Produtos deve ser instanciada para a geração de produtos com características particulares.
Fato que não poderá reduzir o potencial de utilização de boas práticas e técnicas de reuso no
aproveitamento do esforço já empregado na organização; e, (iv) a documentação da Família
de Produtos deve ser clara, incluindo requisitos bem estabelecidos, análise e projeto
adequados, implementação padronizada e testes.
Para produzir uma linha de produtos é importante analisar as similaridades e
variabilidades entre os produtos da linha, de forma a produzir produtos com as mesmas
características base e com as necessidades específicas dos clientes bem definidas. Para isto, na
próxima Seção serão apresentados os conceitos de variabilidade (WEISS; LAI, 1999) e dos
modelos de features (KANG et al., 1990).
3.2
geren
varia
mem
essen
de do
um lo
seja,
que s
al., 2
deter
uma
NOR
VARIABI
Segundo
nciados em
abilidades.
mbros de um
ncial da eng
omínio, requ
A variab
ocal específ
um ponto
são necessá
2005). Cad
rminada var
ou mais va
RTHROP, 2
ILIDADE E
o Clements
m uma LP
De acordo
ma família
genharia de
uisitos, arqu
Figura 3
bilidade é de
fico de um
de variação
árias para re
da variante
riabilidade.
riantes de u
2001).
EM LINHA
e Northrop
S, estão a
com (WE
de produto
e domínio (S
uitetura, com
3.4 – Foco da
escrita por p
artefato em
o representa
ealizar uma
correspond
A resoluçã
um conjunto
AS DE PROD
p (2001), d
as diferença
EISS; LAI,
os podem s
Seção 3.1.1
mponentes
a variabilidad
pontos de v
m que uma d
a um subco
a linha de p
de a uma
ão de um po
o de variant
DUTO DE
dentre os pr
as entre se
1999), va
se diferenci
1), que é uti
e testes (Fig
de na engenha
variação e v
decisão de p
onjunto de v
produto de
alternativa
onto de var
es relaciona
SOFTWAR
rincipais asp
eus produto
ariabilidade
ar entre si
ilizada para
gura 3.4).
aria de domín
variantes. U
projeto aind
variantes co
software em
de projeto
iação se dá
ado com o p
RE
pectos que
tos, conhec
é a forma
e é uma p
a capturar a
nio
Um ponto de
da não foi re
ontidas no m
m particular
o para insta
á através da
produto (CL
39
devem ser
cidas como
a como os
propriedade
as variações
e variação é
esolvida, ou
mundo real
r (POHL et
anciar uma
escolha de
LEMENTS;
9
r
o
s
e
s
é
u
l
t
a
e
;
40
As similaridades e variabilidades existentes em um sistema são capturadas utilizando
os modelos de features. Esses modelos são apresentados mais detalhadamente na próxima
seção.
3.2.1 Modelos de features
Segundo Kang e outros (1990), as variabilidades podem ser inicialmente identificadas
por meio do conceito de características (do inglês, feature). Uma feature pode ser vista como
uma propriedade de sistema ou funcionalidade que é relevante para alguns stakeholders e
usada para capturar características comuns e variáveis entre produtos de uma mesma família
(CZARNECKI; EISENECKER, 2000). As features estão organizadas num diagrama,
geralmente na forma de uma árvore com a raiz representando um conceito (e.g. um sistema de
software) que pode ser refinado em features e estas em subfeatures. Um modelo de features é
constituído por um ou mais diagramas de features que as organiza hierarquicamente.
De acordo com Kang e outros (1990), as features podem ser classificadas como sendo:
Obrigatórias: são funcionalidades que sempre estarão presentes nas linhas do
produto e identificam explicitamente o produto;
Opcionais: podem ou não estar presentes em um produto. Quando estão
presentes, adicionam algum valor às features obrigatórias de um produto;
Variáveis: possuem um conjunto de features relacionadas em que zero ou mais
dessas features podem ser selecionadas para estarem presentes em um produto;
Existem diversas notações que representam os modelos de features. Em FODA (do
inglês, Feature-Oriented Domain Analysis) (KANG et al., 2002), uma feature do tipo
obrigatória (Legenda 1(a)) é representada por uma linha simples, enquanto que uma feature
do tipo opcional (Legenda 1(b)) é representada por um círculo aberto. As decomposições
deste método podem ser: and (todas as sub-features devem estar presentes em um produto
concreto, Legenda 1(c)), or (dentre as sub-features uma ou mais podem estar presentes no
produto, Legenda 1(d)) e xor (ou-exclusivo, Legenda 1(e)), representadas com traços e arcos,
respectivamente.
(CZA
com
abert
agrup
(Leg
2 (ar
Eisen
etc.),
veze
aplic
Legen
Nessa d
ARNECKI;
círculo fech
to (Legenda
padas, pode
genda 2(d)) o
rcos preenc
necker (200
, onde a car
s que uma f
cação.
nda 1 – Notaç
dissertação
EISENEC
hado (Lege
a 2(b)) e fea
e-se ainda f
ou xor com
chido, aber
00), feature
rdinalidade
feature, com
Legenda
ção das featur
é utilizada
KER, 2000
nda 2(a)), u
atures agrup
fazer a sepa
m cardinalida
rto e aberto
es podem se
de uma fea
m as suas su
a 2 – Notação
res utilizadas
a a notaçã
0) onde um
uma feature
padas são re
aração entre
ade (Legend
o com card
er represen
ature signifi
ub-features,
o das features
no método F
ão de feat
a feature d
e do tipo op
epresentada
e xor (ou-ex
da 2(e)), con
dinalidade).
ntadas com
fica um inte
, podem est
s utilizadas ne
FODA (KANG
tures basea
do tipo obri
cional é rep
as com arco
xclusivo) (L
nforme pod
Na aborda
cardinalida
rvalo que d
ar presentes
esta dissertaç
G et al., 2002
ada em ca
igatória é re
presentada c
os. No caso
Legenda 2(
de ser visto n
agem de C
ade (e.g., [1
denota a qua
s em uma d
ção
41
)
ardinalidade
epresentada
com círculo
de features
c)), or (ou)
na Legenda
Czarnecki e
1..*], [3..3],
antidade de
determinada
e
a
o
s
)
a
e
,
e
a
dispo
featu
símb
Fron
obrig
o cir
segur
obrig
prese
obrig
de ra
que u
estar
Sixty
ramif
3.2.2
relac
depe
featu
entre
A Figur
ositivos mó
ures: Servi
bolo com o
nt Door C
gatoriament
rculo abert
rança, ou s
gatórias (R
entes em tod
gatória (Inh
amificação (
uma ou ma
rem presente
y Seconds q
ficação abe
2 Restriçõ
De acor
cionamentos
ndência apr
ures) em um
e features é
a 3.5 apres
óveis em ca
ces, Access
círculo pre
Controller
te em cada
to indicand
seja, esta f
Register Inh
das as aplic
habitant Au
(ou arco) pr
is de suas s
es em um d
que estão ag
rta apenas u
Figura 3.5
ões de varia
do com Po
s de depen
resentam co
m modelo d
é important
senta um m
sas intelige
s Controlle
enchido ind
são obrigat
aplicação. A
do que cad
feature é op
habitant e
cações. A fe
uthorizatio
reenchido, q
sub-features
determinado
grupadas so
uma entre a
– Exemplo d
abilidade
ohl e outro
ndência en
omo determ
de features.
te que exist
modelo de f
entes. A fea
er, Front D
dica que as
tórias, sign
A feature S
da aplicação
pcional. A
Entrance
eature Entr
on) e uma o
que se enco
s (Passwor
o produto. Já
ob a feature
as duas pode
de modelo de f
os (2005), n
ntre as fea
minadas feat
Na existê
ta um trata
features re
ature raiz (S
Door Contr
sub-feature
nificando q
Security Me
o pode ou
feature Se
Authoriza
rance Auth
opcional (G
ontra sob a f
d e Finger
á no caso d
Time to C
e ser selecio
features (CE
nos modelo
atures cont
tures se rel
ncia destes
amento de r
elacionado a
Smart Hom
oller e Sec
es Services,
que estas fe
echanisms
não conte
ervices pos
ation) que
orization p
Guest Autho
feature Acc
print) pode
as sub-featu
lose, estão r
onada.
TINA et al., 2
os de featu
tidas. Estes
acionam (re
relacionam
restrições p
a uma apli
me) possui
curity Mech
, Access C
features dev
possui o sí
er um mec
ssui duas s
também d
possui uma
orization).
cess Contro
em ser esco
ures Thirty
representad
2009)
ures sempre
s relaciona
equer ou ex
mentos de d
para que se
42
icação para
quatro sub-
hanisms. O
ontroller e
vem existir
mbolo com
canismo de
ub-features
devem estar
sub-feature
O símbolo
oller, indica
olhidas para
y Seconds e
das por uma
e existiram
amentos de
xclui outras
dependência
eja possível
2
a
-
O
e
r
m
e
s
r
e
o
a
a
e
a
m
e
s
a
l
43
satisfazer as variabilidades presentes. Os tipos de restrições que podem existir na modelagem
das variabilidades são representadas no metamodelo proposto por Pohl e outros (2005)
(Figura 3.6):
Requer V_V: quando existir a necessidade de expressar que uma variante (V1)
requer outra variante (V2) para satisfazer corretamente a variação independente
dos pontos de variação que estão associadas. Consequentemente, se V1 requer V2
isto implica dizer que, se V1 for selecionada V2 também será selecionada;
Exclui V_V: quando existir a necessidade de expressar que uma variante (V1)
exclui outra variante (V2) para satisfazer corretamente a variação independente
dos pontos de variação que estão associadas. Consequentemente, se V1 exclui V2
isto implica dizer que, se V1 for selecionada V2 não poderá ser selecionada para
configuração;
Requer V_VP: quando existir a necessidade de expressar que um ponto de
variação (VP2) deve ser parte de uma configuração dependendo da seleção de uma
variante (V1) particular presente em outro ponto de variação. Consequentemente,
se V1 requer VP2, se V1 for selecionada VP2 também será selecionada;
Exclui V_VP: quando existir a necessidade de expressar que um ponto de
variação (VP2) não deve ser parte de uma configuração dependendo da seleção de
uma variante (V1) particular presente em outro ponto de variação.
Consequentemente, se V1 exclui VP2 isto implica dizer que, se V1 for selecionada
VP2 não poderá ser selecionada para configuração;
Requer VP_VP: quando existir a necessidade de expressar que um ponto de
variação (VP1) requer outro ponto de variação (VP2) para satisfazer corretamente
a variação. Consequentemente, se VP1 requer VP2 isto implica dizer que, se VP1
for selecionada VP2 também será selecionada;
Exclui VP_VP: quando existir a necessidade de expressar que um ponto de
variação (VP1) exclui outro ponto de variação (VP2) para satisfazer corretamente a
variação. Consequentemente, se VP1 exclui VP2 isto implica dizer que, se VP1 for
selecionada VP2 não poderá ser selecionada para configuração;
Na Figura 3.5 apresentada na Seção anterior é possível apresentar um exemplo de
relacionamento de dependência entre features. A aplicação Smart Home necessita que exista
uma política de segurança de permissão de entrada. Podemos definir que se a feature
Fingerprint for selecionada, para que se tenha maior segurança ela requer que o tempo de
fecha
depe
F
P
co
po
S
se
Figur
3.3
Linh
domí
ar a porta
ndência ent
Feature: Fin
ara que se
omo meio
orta se fech
endo assim
elecionada p
ra 3.6 – Meta
CONSIDE
Neste ca
has de Produ
ínio, engenh
de entrada
tre features
Tabela 3.1ngerprint
tenha maio
para prover
he deve ser d
m a feature F
para prover
amodelo de re
ERAÇÕES
apítulo fora
uto de Softw
haria de apl
a seja de t
é do tipo R
1 – Exemplo
Requer Fi
or segurança
r controle d
de trinta seg
Fingerprin
maior segu
estrições de d
FINAIS
am apresen
ware. Foram
licação e o g
trinta segun
Requer V_V
de restrição d
T
ingerprint_
a na casa in
de acesso e
gundos.
t requer qu
urança à cas
dependência d
ntados os c
m descritos s
gerenciamen
ndos. Send
V (Tabela 3.
de dependêncTipo de Res
_Thirty Sec
nteligente d
e consequen
ue a feature
sa inteligent
de variabilida
conceitos d
sobre o ciclo
nto), sua ap
do assim se
.1).
cia entre featstrição: Req
conds
deve-se ter a
ntemente o
Thirty Sec
te.
ade. Adaptad
do paradigm
o de vida da
plicação e se
eu relacion
tures quer V_V
a impressão
tempo par
conds tamb
do de Pohl e o
ma da Eng
a ELPS (eng
eus benefíci
44
namento de
o digital
ra que a
bém seja
outros (2005)
genharia de
genharia de
ios.
4
e
e
e
45
Apresentou os conceitos de variabilidade em LPS e o método de modelagem de
features utilizado para identificar e representar as features comuns e variáveis de uma LPS
cujos membros são ferramentas de edição de modelos baseados nas variações do framework
i*. Também foi descrito os métodos utilizados para tratar o relacionamento de dependência
entre features.
Provido destes conceitos, no próximo capítulo será apresentado uma comparação entre
diversas linguagens que foram construídas baseadas no i* a fim de identificar as
características comuns e variáveis entre elas. A partir do resultado produzido será possível
construir o metamodelo núcleo para construção de linguagens baseadas no i*.
4 C
Este
de L
const
basea
const
restri
finai
COMPARANDO E IDENTIFICANDO AS VARIAÇÕES DO FR
capítulo se
Linhas de P
trutores com
adas no i*
truídas bas
ições de re
s.
RAMEWORK I*
refere a pr
Produto de
muns e var
*. Para isto
seadas no i
elacionamen
rimeira cont
Software
riáveis para
o será apre
i* com foc
ntos impos
tribuição de
apresentado
a a definiçã
esentada um
co principa
stas. Por úl
este trabalho
os no capí
ão dos core
ma compar
al em seus
ltimo, serão
o onde será
ítulo anterio
e assets da
ração entre
elementos
o apresenta
á utilizado o
or para ide
família de
e algumas
s de model
adas as con
46
os conceitos
entificar os
linguagens
linguagens
lagem e as
nsiderações
6
s
s
s
s
s
s
47
4.1 INTRODUÇÃO
Diversas extensões do i* foram propostas devido às necessidades específicas dos
grupos de pesquisa da comunidade do i* (Toronto, Itália, Espanha, Brasil etc.). Cada uma
destas variações possui características particulares que são representadas através de novos
construtores (elementos de modelagem). Como resultado, uma nova ferramenta deve ser
construída para prover suporte à nova linguagem. Por outro lado, é possível perceber que na
diversidade das linguagens baseadas no i*, existe um núcleo comum de construtores entre
elas, já que utilizaram como base para suas concepções o framework i*. Deste modo,
podemos afirmar que cada uma das diversas linguagens baseadas no i* pode ser reconhecida
como produtos de uma família de linguagens i*. Identificando o núcleo comum dos
construtores e os construtores variáveis dentre essas linguagens, o esforço do
desenvolvimento de ferramentas de suporte para elas pode ser reduzido através do uso de
técnicas da ELPS.
Sendo assim será apresentada uma comparação entre algumas linguagens propostas
baseadas no i* (i* original (YU, 1995), i* Wiki (GRAU et al., 2008), Tropos (SUSI et al.,
2005), GRL (AMYOT et al., 2009), i*-c (BORBA, 2009) e Aspectual i* (ALENCAR et al.,
2010)) a fim de identificar a variabilidade existente entre elas. A pretensão é a identificação
das características comuns e variáveis existentes para que seja possível definir uma estratégia
de reuso dessas características na construção de ferramentas de modelagem destinada a novas
linguagens baseadas no i*. Através das características comuns será definido um metamodelo
núcleo capaz de representá-las e de suportar o tratamento de configurações diversificadas a
fim de conceber a família de linguagens i*.
Nas próximas seções serão apresentadas as comparações do i* original com as
seguintes linguagens: i* Wiki, Tropos, GRL, i*-c e Aspectual i*.
4.2 I* ORIGINAL VERSUS I* WIKI
As diferenças existentes a linguagem i* Wiki e a i* Original estão relacionada à
ligação meio-fim encontrada nos modelos SR. Nesta variação do i*, o “meio” é
exclusivamente expresso na forma de uma tarefa e o “fim” é exclusivamente expresso na
form
(Figu
Figu
lingu
Tabe
relac
Tabe
dos r
ma de um ob
ura 4.1).
ura 4.1 – Dife
Na Tabe
uagens i* Or
ela 4.1 – Com
A
Elementos
Relacio
Para fa
cionamentos
ela 4.2 – Iden
AAPP
Na Figur
relacioname
bjetivo, deix
erenças existe
ela 4.1 en
riginal e i*
paração de c
Atores
s Intencionais
onamentos
cilitar a
s, adotaremo
ntificação dos
AT Ator AG AgentePO PosiçãPA Papel O Objetiv
ra 4.1 bem
entos presen
xando assim
entes entre as
contram-se
Wiki, onde
onstrutores e
AtorOb
LiLigDec
Li
apresentaçã
os a notação
símbolos uti
e ão
vo
como na T
ntes no i* or
m de existir l
s restrições d
a compar
e foi constat
entre o i* origi* origin
r, Agente, Posbjetivo, Tarefa
Softgoal e Bigação de Depgação de Ator,composição digação de Con
ão das co
o apresenta
ilizados nas coriginal e o i
SímboloT R S ● ○
abela 4.3 en
riginal e o i
ligações me
da ligação Me
ração entre
tado não exi
ginal (YU, E.nal sição e Papela, Recurso, Belief pendência, , Meio-fim,
de Tarefas e ntribuição
omparações
da na Tabel
comparações i* Wiki os
Tarefa Recurso Softgoal Todos os eTodos os ti
ncontram-se
* Wiki.
eio-fim entr
io-fim entre o
e os princip
istir diferen
1995) e o i* W
Ator, AgObjetiv
SoLigaçã
LigaçãoDecomp
Ligaçã
das restr
la 4.2.
de construtor
elementos inteipos de atores
e as diferen
re objetivos
o i* Original
ipais constr
nças.
Wiki (GRAUi* Wiki
gente, Posiçãovo, Tarefa, Reoftgoal e Belieão de Dependêo de Ator, Meposição de Taão de Contrib
rições pos
res e restriçõ
encionais s
nças entre a
48
e softgoals
e o i* Wiki
rutores das
U et al., 2008)
o e Papel ecurso, ef ência, io-fim,
arefas e uição
ssíveis dos
ões entre o i*
as restrições
8
s
s
s
s
49
Tabela 4.3 – Diferenças de Restrições dos relacionamentos entre o i* original (YU, 1995) e o i* Wiki (GRAU et al., 2008)
i* original i* Wiki Ligação de Dependência
(Open, Critical e Committed) ○●, ●○ e ●● ○●, ●○ e ●●
Ligação de Ator - ISA ATAT, AGAG, POPO e
PAPA ATAT, AGAG, POPO e
PAPA
Ligação de Ator – Is Part Of ATAT, AGAG, POPO e
PAPA ATAT, AGAG, POPO e
PAPA Ligação de Ator – Covers POPA POPA
Ligação de Ator – Occupies AGPO AGPO Ligação de Ator – Plays AGPA AGPA Ligação de Ator – INS AGAG AGAG
Meio-fim T●, OO e SGSG TO Decomposição de Tarefas T● T●
Ligação de Contribuição
SGSG e TSG
(Make, Break, SomePlus,
SomeMinus, Help, Unknown, Hurt,Or e And)
SGSG, TSG e OSG
(Make, Break, SomePlus,
SomeMinus, Help, Unknown, Hurt,Or e And)
Na comparação de restrições dos relacionamentos entre o i* original e o i* Wiki é
possível destacar apenas a ligação meio-fim e as ligações de contribuição (Tabela 4.3). A
ligação meio-fim no i* original pode acontecer de uma tarefa para qualquer elemento
intencional, de um objetivo para outro e de uma softgoal para outro. No i* Wiki acontece
apenas entre uma tarefa (como sendo “meio”) e um objetivo (como sendo um “fim”). As
ligações de contribuição do i* Wiki possuem restrições diferenciadas do i* original. No i*
Wiki pode acontecer de existir o relacionamento de contribuição de um objetivo para um
softgoal enquanto que o i* original não permite.
4.3 I* ORIGINAL VERSUS TROPOS
Na versão mais atual do Tropos, proposta por Susi (2005), criou-se um metamodelo
específico que apresenta algumas mudanças em relação ao i* original. Modificou-se os nomes
dos elementos Tarefa (Task) para Plano (Plan) e Objetivo (Goal) para Hardgoal (Figura 4.2).
Além disso, as restrições da ligação meio-fim foram modificadas (Figura 4.3(a)) e
acrescentaram-se novos tipos de decomposição: a decomposição-OR e a decomposição-AND
(Figura 4.3(b)).
Fi
lingu
T
igura 4.3 – D
Na Tabe
uagens i* or
abela 4.4 – D
A
Elementos
Relacio
Fi
iferenças exis
ela 4.4 enc
riginal e o T
Diferenças de
Atores
s Intencionais
onamentos
igura 4.2 – El
stentes entre
ontram-se a
Tropos.
construtores
AtorOb
LiLigDec
Li
(MSom
lementos de m
as restriçõesOriginal e o
as diferenç
s entre o i* ori* origin
r, Agente, Posbjetivo, Tarefa
Softgoal e Bigação de Depgação de Ator,composição digação de Con
Make, Break, SmeMinus, Help
Hurt,Or e
modelagem d
s da ligação MTropos
as entre os
riginal (YU, 1nal sição e Papela, Recurso, Belief pendência, , Meio-fim,
de Tarefas e ntribuição
SomePlus, p, Unknown, And)
do Tropos
Meio-fim e De
s principais
1995) e o Trop
Actor, APlano, H
LigaçãLigação d
DecoDecomp
C
+(Help), +
ecomposição
s construtor
pos (SUSI et Tropos
Agent, PositionHardgoal, Rec
Softgoal ão de Dependêde Ator, Meioomposition, Aposition e LigaContribuição
++(Make), - (
( Break)
50
entre o i*
res entre as
al., 2005)
n e Role curso e
ência, -fim, OR
AND ação de
Hurt) e --
0
s
51
Para facilitar a apresentação das comparações das restrições possíveis dos
relacionamentos, adotaremos a notação apresentada na Tabela 4.5.
Tabela 4.5 – Identificação dos símbolos utilizados nas comparações de construtores e restrições entre o i* original e o Tropos
Símbolos AT Ator R Recurso AG Agente S Softgoal PO Posição P Plano PA Papel HG Hardgoal O Objetivo ● Todos os elementos intencionais T Tarefa ○ Todos os tipos de atores
Na Figura 4.3, bem como na Tabela 4.6, encontram-se as diferenças entre as restrições
dos relacionamentos presentes no i* original e o Tropos.
Tabela 4.6 – Diferenças de Restrições dos relacionamentos i* original (YU, 1995) e o Tropos (SUSI et al., 2005)
i* original Tropos Ligação de Dependência
(Open, Critical e Committed) ○●, ●○ e ●● ○●, ●○ e ●●
Ligação de Ator - ISA ATAT, AGAG, POPO e
PAPA ATAT, AGAG, POPO e
PAPA
Ligação de Ator – Is Part Of ATAT, AGAG, POPO e
PAPA ATAT, AGAG, POPO e
PAPA Ligação de Ator – Covers POPA POPA
Ligação de Ator – Occupies AGPO AGPO Ligação de Ator – Plays AGPA AGPA Ligação de Ator – INS AGAG AGAG
Meio-fim T●, OO e SGSG PHG, PSG, RHG,
RSG, HGHG, HGSG, SGHG e SGSG
Decomposição de Tarefas ●T - Decomposição - OR - HGHG, SGSG e PP
Decomposição - AND - HGHG, SGSG e PP
Ligação de Contribuição
SGSG e TSG
(Make, Break, SomePlus,
SomeMinus, Help, Unknown, Hurt,Or e And)
HGHG, HGSG, PHG, PSG, SGSG e SGHG
+(Help), ++(Make), - (Hurt) e -
-( Break)
Dentre as diferenças de restrições dos relacionamentos entre o i* original e o Tropos é
possível destacar a ligação meio-fim, as decomposições e as ligações de contribuição (Tabela
4.6). A ligação de meio-fim do Tropos possui elementos de relacionamento diferentes em
relação a ligação meio-fim do i* original. Este relacionamento acontece entre os novos
elementos de modelagem contidos no Tropos (Plano, Recurso e Hardgoal). A principal
52
diferença é que além de um plano (tarefa) ou um hardgoal (objetivo), um recurso também
pode ser considerado como meio.
Quanto as ligações de decomposição, a ligação de decomposição de tarefas não é
contemplada no Tropos. Além disto, outros dois tipos de decomposição foram inseridos,
Decomposição-OR e Decomposição-AND. Em ambas as decomposições podem existir o
relacionamento de hardgoal para hardgoal, softgoal para softgoal e plano para plano.
Por último, as ligações de contribuição do Tropos possuem restrições diferenciadas do
i* original. O metamodelo (SUSI et al., 2005) permite que aconteça relacionamentos tais
como: hardgoal para hardgoal, plano para hardgoal, softgoal para hardgoal, além das
ligações tradicionais, plano para softgoal, hardgoal para softgoal e softgoal para softgoal.
Outra diferença acontece nos tipos de contribuição que são reduzidos contendo apenas os
tipos Help, Make, Hurt e Break.
4.4 I* ORIGINAL VERSUS GRL
Como descrito anteriormente na Seção 2.3.3, o GRL (AMYOT et al., 2009) foi criado
para amadurecer a representação dos requisitos não-funcionais nos modelos i*. Para
contemplar esta necessidade o autor inseriu no i* uma nova ligação denominada Correlação,
apresentada na Figura 4.4(a) e Figura 4.5(c). A ligação de Correlação permite expressar o
conhecimento sobre as interações entre os elementos intencionais. Ela é semelhante a uma
ligação de contribuição, exceto pelo fato de que a correlação não é uma influência esperada,
mas um efeito colateral. As ligações Meio-fim (Figura 4.5(a)) e Decomposição (conceito
herdado do Tropos)(Figura 4.5(b)) sofreram algumas alterações quanto as restrições
detalhadas logo mais.
Além deste novo construtor, também é possível realizar análises sobre o nível de
satisfação das ligações GRL (Figura 4.4(b)) e analisar a representação qualitativa e
quantitativa das contribuições (Figura 4.4(c) e Figura 4.5(d)).
Fig
gura 4.5 – Dif
Fi
ferenças existRepresentaç
igura 4.4 – R
entes entre ação Qualitativ
Relacionamen
as restrições dva e Quantita
tos existentes
da ligação Meativa entre o i
s no GRL
eio-fim, Decoi* Original e
omposição, Coo GRL
53
orrelação e
3
54
Na Tabela 4.7 encontram-se as diferenças entre os principais construtores entre as
linguagens i* original e o GRL.
Tabela 4.7 – Diferenças de construtores entre o i* original (YU, 1995) e o GRL (AMYOT et al., 2009) i* original GRL
Atores Ator, Agente, Posição e Papel Ator
Elementos Intencionais Objetivo, Tarefa, Recurso,
Softgoal e Belief Objetivo, Tarefa, Recurso,
Softgoal e Belief
Relacionamentos
Ligação de Dependência, Ligação de Ator, Meio-fim, Decomposição de Tarefas e
Ligação de Contribuição
Ligação de Dependência, Ligação de Ator, Meio-fim, Decomposição, Ligação de Contribuição e Ligação de
Correlação
Para facilitar a apresentação das comparações das restrições possíveis dos
relacionamentos, adotaremos a notação apresentada na Tabela 4.8.
Tabela 4.8 – Identificação dos símbolos utilizados nas comparações de construtores e restrições entre o i*
original e o GRL Símbolo
AT Ator T Tarefa AG Agente R Recurso PO Posição S Softgoal PA Papel ● Todos os elementos intencionais O Objetivo ○ Todos os tipos de atores
Na Figura 4.5 bem como na Tabela 4.9 encontram-se as diferenças entre as restrições
dos relacionamentos presentes no i* original e o GRL.
Dentre as diferenças de restrições dos relacionamentos entre o i* original e o GRL é
possível destacar as ligações de ator, ligação meio-fim, as decomposições e as ligações de
correlação (Tabela 4.9). No GRL não existe ligações de atores, pelo fato de o mesmo conter
apenas um tipo de ator (Tabela 4.7). As restrições da ligação meio-fim acontecem de tarefa
para objetivo e de tarefa para tarefa, diferentemente do i* original que acontece de tarefa para
qualquer elemento intencional, objetivo para objetivo e softgoal para softgoal.
Quanto às ligações de decomposição, a ligação de decomposição de tarefas não é
contemplada no GRL. Além disto, outro tipo de ligação de decomposição foi inserido,
denominado decomposição. Esta ligação acontece de uma tarefa para qualquer elemento
intencional e de um objetivo para outro.
Por último, as ligações de correlação. Esta ligação não existe no i* original, sendo
assim uma característica particular do GRL. Correlações possuem as mesmas restrições das
ligações de contribuição tanto do i* original quanto do próprio GRL.
55
Tabela 4.9 – Diferenças de Restrições dos relacionamentos entre o i* original (YU, 1995) e o GRL (AMYOT et al., 2009)
i* original GRL Ligação de Dependência
(Open, Critical e Committed) ○●, ●○ e ●● AT●, ●AT e ●●
Ligação de Ator - ISA ATAT, AGAG, POPO e
PAPA -
Ligação de Ator – Is Part Of ATAT, AGAG, POPO e
PAPA -
Ligação de Ator – Covers POPA - Ligação de Ator – Occupies AGPO -
Ligação de Ator – Plays AGPA - Ligação de Ator – INS AGAG -
Meio-fim T●, OO e SGSG TO e TT Decomposição de Tarefas ●T -
Decomposição - T● e OO
Ligação de Contribuição
SGSG e TSG
(Make, Break, SomePlus,
SomeMinus, Help, Unknown, Hurt,Or e And)
SGSG e TSG
(Make, Break, SomePlus,
SomeMinus, Help, Unknown, Hurt)
Ligação de Correlação -
SGSG e TSG
(Make, Break, SomePlus,
SomeMinus, Help, Unknown, Hurt)
Representação Qualitativa e Quantitativa das Contribuições
-
SGSG e TSG
(Make, Break, SomePlus,
SomeMinus, Help, Unknown, Hurt)
4.5 I* ORIGINAL VERSUS I*-C
A Seção 2.3.4 apresentou rapidamente a linguagem i*-c que foi construída para que
fosse possível capturar variabilidades utilizando modelos i*. Nesta abordagem, os elementos
do tipo tarefa e recurso (Figura 4.6(a)) são considerados como os elementos intencionais do
modelo SR a terem cardinalidade, já que determinam funcionalidades e características do
sistema, ou seja, as suas features. Esses elementos não sofrem alterações em suas notações
gráficas, contudo, recebem um novo atributo para representação da cardinalidade. O atributo
de cardinalidade também foi inserido nas ligações meio-fim (Figura 4.6(b)), a fim de
representarem features agrupadas com cardinalidade.
Figu
lingu
Fi
ura 4.7 – Dife
Na Tabe
uagens i* or
igura 4.6 – El
erenças existe
ela 4.10 en
riginal e i*-c
lementos de m
entes entre asDecomposi
ncontram-se
c.
modelagem co
s restrições daição entre o i
e as difere
om cardinali
a ligação Meii* Original e
enças entre
dade existent
io-fim, Meio-o i*-c
e os princi
tes no i*-c
-fim com card
ipais constr
56
dinalidade e
rutores das
6
s
57
Tabela 4.10 – Diferença de construtores entre o i* original (YU, 1995) e o i*-c (BORBA, 2009) i* original i*-c
Atores Ator, Agente, Posição e Papel Ator, Agente, Posição e Papel
Elementos Intencionais Objetivo, Tarefa, Recurso,
Softgoal e Belief
Objetivo, Tarefa, Recurso, Softgoal, Tarefa com
Cardinalidade, Recurso com Cardinalidade e Belief
Relacionamentos
Ligação de Dependência, Ligação de Ator, Meio-fim, Decomposição de Tarefas e
Ligação de Contribuição
Ligação de Dependência, Ligação de Ator, Meio-fim,
Meio-fim com Cardinalidade, Decomposição de Tarefas e
Ligação de Contribuição
Para facilitar a apresentação das comparações das restrições possíveis dos
relacionamentos, adotaremos a notação apresentada na Tabela 4.11.
Tabela 4.11 – Identificação dos símbolos utilizados nas comparações de construtores e restrições entre o i* original e o i*-c
Símbolos AT Ator R Recurso AG Agente S Softgoal PO Posição TC Tarefa com Cardinalidade PA Papel RC Recurso com Cardinalidade O Objetivo ● Todos os elementos intencionais T Tarefa ○ Todos os tipos de atores
Na Figura 4.7 bem como na Tabela 4.12 encontram-se as diferenças entre as restrições
dos relacionamentos presentes no i* original e o i*-c.
Tabela 4.12 – Restrições dos relacionamentos entre o i* original (YU, 1995) e o i*-c (BORBA, 2009)
i* original i*-c Ligação de Dependência
(Open, Critical e Committed) ○●, ●○ e ●● ○●, ●○ e ●●
Ligação de Ator - ISA ATAT, AGAG, POPO e
PAPA ATAT, AGAG, POPO e
PAPA
Ligação de Ator – Is Part Of ATAT, AGAG, POPO e
PAPA ATAT, AGAG, POPO e
PAPA Ligação de Ator – Covers POPA POPA
Ligação de Ator – Occupies AGPO AGPO Ligação de Ator – Plays AGPA AGPA Ligação de Ator – INS AGAG AGAG
Meio-fim T●, OO e SGSG TO e TCO Meio-fim com Cardinalidade - OO e TO
Decomposição de Tarefas ●T TCTC e ●TC
Ligação de Contribuição
SGSG e TSG
(Make, Break, SomePlus,
SomeMinus, Help, Unknown, Hurt,Or e And)
SGSG, TSG e OSG
(Make, Break, SomePlus,
SomeMinus, Help, Unknown, Hurt,Or e And)
58
Dentre as diferenças de restrições dos relacionamentos entre o i* original e o i*-c é
possível destacar as ligações meio-fim, decomposição de tarefas e as ligações de contribuição
(Tabela 4.12). As restrições da ligação meio-fim do i*-c acontecem de forma diferente do i*
original. É possível que aconteça de uma tarefa para um objetivo e de uma tarefa com
cardinalidade para um objetivo, enquanto no i* original acontece de uma tarefa para qualquer
elemento intencional, objetivo para objetivo e softgoal para softgoal.
A ligação meio-fim com cardinalidade existe apenas no i*-c. As suas restrições
acontecem de um objetivo para outro objetivo e de uma tarefa para um objetivo. A ligação de
decomposição de tarefas no i* original acontece de qualquer elemento intencional para uma
tarefa, enquanto no i*-c acontece de uma tarefa com cardinalidade para uma tarefa, tarefa com
cardinalidade para outra tarefa com cardinalidade e de qualquer elemento intencional para
uma tarefa com cardinalidade.
Por último, as ligações de contribuição do i*-c possuem restrições diferenciadas do i*
original. No i*-c pode acontecer de existir o relacionamento de contribuição de um objetivo
para um softgoal enquanto que o i* original não permite.
4.6 I* ORIGINAL VERSUS I* ASPECTUAL
No i* Aspectual (ALENCAR et al., 2010) foi inserido um novo compartimento
denominado Ator Aspectual (Figura 4.8(a)) para separar os interesses transversais (do inglês,
Crosscutting Concerns) do resto dos elementos do modelo. Interesses são considerados
transversais quando seu comportamento pode ter impacto em (ou influenciar) múltiplos
compartimentos ou componentes do sistema (Figura 4.8(b)). Em nossa comparação, esses
interesses transversais foram tratados como novos elementos de modelagem a fim de facilitar
a definição dos novos relacionamentos que foram inseridos.
Portanto, em um modelo de objetivos, os interesses transversais podem estar
entrelaçados e espalhados em qualquer parte do modelo e devem ser separados a fim de
facilitar a manutenção e evolução dos modelos. O i* Aspectual também inseriu o
Relacionamento de Entrecorte (do inglês, Crosscrutting Relationship) com objetivo de fazer a
composição dos Atores Aspectuais com o restante dos elementos no modelo (Figura 4.8(c)).
Figu
Figura
ra 4.9 – Difer
4.8 – Princip
renças existenentrecorte
pais elementos
ntes entre as e Contribuiç
s de modelag
restrições dação de entrec
gem presentes
a ligação Meioorte entre o i
s da linguage
o-fim de entri* Original e o
em i* Aspectu
recorte, Decoo i*-c
59
ual
mposição de
9
60
Na Tabela 4.13 encontram-se as diferenças entre os principais construtores das
linguagens i* original e i* Aspectual.
Tabela 4.13 – Diferença de construtores entre o i* original (YU, 1995) e o i* Aspectual (ALENCAR et al., 2010)
i* original i* Aspectual
Atores Ator, Agente, Posição e Papel Ator, Agente, Posição e Papel e
Ator Aspectual
Elementos Intencionais Objetivo, Tarefa, Recurso,
Softgoal e Belief Objetivo, Tarefa, Recurso,
Softgoal e Belief
Interesses Transversais - Objetivo, Tarefa, Recurso,
Softgoal
Relacionamentos
Ligação de Dependência, Ligação de Ator, Meio-fim, Decomposição de Tarefas e
Ligação de Contribuição
Ligação de Dependência, Ligação de Ator, Meio-fim,
Meio-fim de Entrecorte, Decomposição de Tarefas de Entrecorte, Decomposição de
Tarefas, Ligação de Contribuição e Ligação de Contribuição de Entrecorte
Para facilitar a apresentação das comparações das restrições possíveis dos
relacionamentos, adotaremos a notação apresentada na Tabela 4.14.
Tabela 4.14 – Identificação dos símbolos utilizados nas comparações de construtores e restrições entre o i* original e o i* Aspectual
Símbolos AT Ator CCO Crosscutting Concern Objetivo AG Agente CCT Crosscutting Concern Tarefa PO Posição CCR Crosscutting Concern Recurso PA Papel CCSG Crosscutting Concern Softgoal O Objetivo ● Todos os elementos intencionais T Tarefa ○ Todos os tipos de atores
R Recurso * Todos os elementos intencionais dentro do ator aspectual
S Softgoal AA Ator Aspectual
Na Figura 4.9 bem como na Tabela 4.15 encontram-se as diferenças entre as restrições
dos relacionamentos presentes no i* original e o i* Aspectual.
Dentre as diferenças de restrições dos relacionamentos entre o i* original e o i*
Aspectual é possível destacar as ligações meio-fim, meio-fim de entrecorte, decomposição de
tarefa de entrecorte, ligações de contribuição de entrecorte e as ligações de contribuição
(Tabela 4.15). As restrições da ligação meio-fim do i* Aspectual acontecem apenas entre uma
tarefa para um objetivo. A ligação de meio-fim de entrecorte não existe no i* original. Suas
restrições acontecem entre os elementos denominados Interesses Transversais (Crosscutting
61
Concerns) que se dão por: Crosscutting Concerns Tarefa para objetivo, Crosscutting
Concerns Tarefa para Crosscutting Concerns Objetivo.
A ligação de decomposição de tarefa de entrecorte também existe apenas no i*
Aspectual. Suas restrições acontecem de todo elementos intencional dentro dos atores
aspectuais para uma tarefa e de todo elementos intencional dentro dos atores aspectuais para
um Crosscutting Concerns Tarefa.
As ligações de contribuição de entrecorte acontecem de Crosscutting Concerns Tarefa
para um softgoal e de Crosscutting Concerns Tarefa para um Crosscutting Concerns Softgoal.
Tabela 4.15 – Restrições dos relacionamentos entre o i* original (YU, 1995) e o i* Aspectual (ALENCAR et al., 2010)
i* original i* Aspectual Ligação de Dependência
(Open, Critical e Committed) ○●, ●○ e ●● ○●, ●○ e ●●
Ligação de Ator - ISA ATAT, AGAG, POPO e
PAPA ATAT, AGAG, POPO e
PAPA
Ligação de Ator – Is Part Of ATAT, AGAG, POPO e
PAPA ATAT, AGAG, POPO e
PAPA Ligação de Ator – Covers POPA POPA
Ligação de Ator – Occupies AGPO AGPO Ligação de Ator – Plays AGPA AGPA Ligação de Ator – INS AGAG AGAG
Meio-fim T●, OO e SGSG T●, OO e SGSG Decomposição de Tarefas ●T ●T
Meio-fim de Entrecorte - AAAA, AAO, CCTO e
CCTCCO Decomposição de Tarefas de
Entrecorte -
AAAA, TAA, *T e *CCT
Ligação de Contribuição
SGSG e TSG
(Make, Break, SomePlus,
SomeMinus, Help, Unknown, Hurt,Or e And)
SGSG e TSG
(Make, Break, SomePlus,
SomeMinus, Help, Unknown, Hurt,Or e And)
Ligação de Contribuição de Entrecorte
-
CCTSG, CCTCCSG,
CCSGSG e CCSGCCSG
(Make, Break, SomePlus, SomeMinus, Help, Unknown,
Hurt,Or e And)
4.7 IDENTIFICANDO OS CONSTRUTORES COMUNS
A partir da análise comparativa entre os construtores das várias linguagens baseadas
no i*, é possível concluir que dentre as linguagens analisadas, todas possuem como
62
construtores comuns os atores, os elementos intencionais e os relacionamentos. Entretanto,
cada uma das linguagens possui construtores específicos e restrições diferentes para os
relacionamentos.
Levando em consideração os conceitos de LPS, os construtores identificados como
comuns entre as linguagens, devem ser tratados como sendo os pontos de variação do nosso
domínio (linguagens baseadas em i*). Pontos de variação, em nosso caso, são pontos onde
ocorrem especializações de um construtor, como, por exemplo, na linguagem i* original
existem três especializações de Ator: Agente, Posição e Papel. Já na linguagem i* Aspectual,
existe uma nova especialização denominada Ator Aspectual. Então é possível perceber que o
construtor Ator é um ponto de variação entre as duas linguagens, já que, entre estas, existe
uma variação de especialidades do elemento Atores, ou seja, as linguagens possuem tipos
diferentes de atores.
Desta maneira, na Tabela 4.16 foi elencado os pontos de variação e as variantes
identificadas a partir dos resultados obtidos na análise comparativa realizada.
Tabela 4.16 – Pontos de Variação e Variantes identificados na análise de construtores Pontos de Variação Variantes
Atores Ator, Agente, Posição, Papel e Ator Aspectual
Elementos Intencionais Objetivo, Tarefa, Softgoal, Recurso, Belief, Plano, Hardgoal, Tarefa
com Cardinalidade e Recurso com Cardinalidade
Relacionamentos
Ligação de Dependência, Ligação de Ator, Meio-fim, Decomposição de Tarefas, Ligação de Contribuição,
Decomposição, OR Decomposition, AND Decomposition, Ligação de Correlação, Meio-fim com Cardinalidade, Meio-fim de
Entrecorte, Decomposição de Tarefas de Entrecorte e Ligação de Contribuição de Entrecorte
Em algumas extensões do i*, os próprios elementos variantes também podem ser
tratados com pontos de variação, como, por exemplo, no caso do relacionamento de
contribuição, pelo fato deste possuir seus próprios graus de contribuição. Neste caso o
relacionamento de contribuição torna-se variante do ponto de variação Relacionamentos e, ao
mesmo tempo, torna-se ponto de variação para os tipos de contribuições existentes (Tabela
4.17).
Tabela 4.17 – Exemplos de variantes sendo tratadas como pontos de variação
Pontos de Variação Variantes ... …
Relacionamentos
Ligação de Dependência, Ligação de Ator, Meio-fim, Decomposição de Tarefas, Ligação de Contribuição,
Decomposição, OR Decomposition, AND Decomposition, Ligação de Correlação, Meio-fim com Cardinalidade, Meio-fim de Entrecorte,
Decomposição de Tarefas de Entrecorte e Ligação de Contribuição de
63
Entrecorte Ligação de Contribuição Make, Break, SomePlus, SomeMinus, Help, Unknown, Hurt,Or e And
4.7.1 Representação da variabilidade no modelo de features
Com o modelo de features é possível representar, de forma estruturada, a variabilidade
identificada na comparação realizada anteriomente. O modelo apresentado na Figura 4.10
representa todos os elementos da linguagem do i* original. Quando uma linguagem é
construída baseada no i*, é preciso inicialmente escolher quais os elementos que serão
herdados (por exemplo, pode-se construir uma linguagem que contenha apenas objetivos e
tarefas como elementos intencionais). Isto implica dizer que este modelo de features permite
apenas a criação de linguagens baseadas apenas no i* original e também no i* Wiki, visto que
ambas possuem os mesmo elementos de modelagem e diferenciação apenas em nível de
restrições. Observe que apenas os conceitos de atores, elementos intencionais, e
relacionamentos serão obrigatoriamente herdados na criação de uma nova linguagem.
Além disso, todos os outros elementos que não fazem parte do conceito do i* original
foram omitidos no modelo de features. Esta decisão foi tomada pelo fato de existir a
necessidade de identificar o que será herdado inicialmente de uma linguagem para a outra, ou
seja, o que uma nova linguagem realmente herdará do i* original. Outro motivo está
relacionado às características peculiares necessárias em uma nova linguagem. Essas
características são necessidades específicas criadas para solucionar problemas particulares em
um determinado contexto e por isso são totalmente imprevisíveis. Isso implica dizer que,
todas as variabilidades presentes nas outras linguagens só poderão de ser configuradas após a
decisão sob quais elementos serão herdados do i* original para que então, seja possível inserí-
las no modelo de features e logo após no metamodelo núcleo. Então é possível concluir que
todos os elementos identificados na comparação anterior que não fazem parte do i* original
serão tratados como características específicas que deverão ser configuradas posteriormente a
criação de uma base i*.
mode
Mod
é um
nodo
Node
pode
Elem
ser e
New
lingu
A ca
novo
um n
A config
elo de feat
del e Relatio
ma abstração
os ou nós.
eObject. M
em ser inser
A featur
ment e Com
escolhidas (
w Modeling
uagem. Ela
ardinalidade
os elemento
novo elemen
F
guração sob
tures aprese
onship são
o de todos
Sendo ass
Model é a
idos.
re NodeObj
mpartment.
(Goal, Task
g Element
está present
e imposta so
s de modela
nto de mode
igura 4.10 – M
b quais elem
entado na
característic
os element
sim, atores
representaç
ject é subd
Na feature
k, Resourc
é respons
te em cada u
obre esta fe
agem de aco
elagem acon
Modelo de fe
mentos serã
Figura 4.1
cas obrigató
tos de mod
s e elemen
ção do rep
divida em ou
e Intentiona
ce, Softgoal
sável por
um dos pon
eature impl
ordo com o
ntece em um
eature da ling
ão herdados
0. Neste m
órias para u
delagem que
ntos intenci
ositório on
utras duas f
al Element
l e New M
criar as ne
ntos de varia
lica dizer qu
s seus ponto
m segundo m
uagem i* orig
do i* origi
modelo de f
uma nova lin
e podem se
onais são
nde os elem
features obr
, uma ou m
Modeling El
ecessidades
ações identi
ue é possív
os de variaç
momento (v
ginal
inal é dada
features No
nguagem. N
er represent
tratados co
mentos de m
rigatórias, I
mais subfeatu
lement). A
s específica
ificados na
vel configur
ção. A confi
vide Capítul
64
a através do
odeObject,
NodeObject
tados como
omo sendo
modelagem
Intentional
ures podem
subfeature
as de uma
Tabela 4.6.
rar diversos
figuração de
lo 6).
4
o
,
t
o
o
m
l
m
e
a
.
s
e
65
Em Intentional Element também é possível selecionar duas subfeatures opcionais
(Element-Model e Element-Compartment). Estas features devem ser escolhidas quando
existir a necessidade de criar elementos de modelagem que possam ou devam ser compostos
somente ao modelo (Element-Model) ou elementos de modelagem que só possam ou devam
ser compostos aos compartimentos (Element-Compartment). Se uma feature opcional for
selecionada isto implica dizer que um ou mais elementos de modelagem devem ser
configurados através da feature New Modeling Element (mais detalhes sobre esta
característica pode ser encontra na Seção 6.3.2).
Os atores serão representados pela feature Compartment pelo fato de ser um
componente que possui a característica de armazenar elementos tais como um contêiner6.
Sendo assim, na feature Compartment uma ou mais subfeatures podem ser escolhidas
(Actor, Agent, Position, Role e New Modeling Element). Em Relationship uma ou mais
subfeatures podem ser escolhidas (Actor Link, Task Decomposition Link, Contribution
Link, Means-End Link, Dependency Link e New Modeling Element). Caso
Constribution Link seja escolhida uma ou mais de suas subfeatures pode ser escolhida
(Make, Break, Unknown, Hurt, Help, SomePlus, SomeMinus, Or e And). Caso a feature
Dependency Link seja escolhida uma ou mais de suas subfeatures podem ser escolhidas
(Commited, Open e Critical). Por fim, caso Actor Link seja selecionada um ou mais
subfeatures pode ser escolhida (ISA, Covers, INS, Occupies, Plays e Is Part Of).
É fato que neste modelo existem relacionamentos de dependência entre features.
Sendo assim faz-se necessário o tratamento destes relacionamentos utilizando o conceito de
restrições de variabilidade (POHL et al., 2005) apresentada na Seção 3.2.2.
A própria linguagem i* define as restrições existentes entre seus elementos de
modelagem e, assim, é possível mapeá-las para o tratamento de relacionamento de
dependência entre as features presentes no modelo de features. Dentre elas as que possuem
relacionamento de dependência são:
Relationship (Relacionamento) – a linguagem i* contém vários conceitos de
relacionamentos. Cada um desses possui restrições particulares (Seção 2.2.4).
Sendo assim ao mapear as restrições dos relacionamentos da linguagem para o
modelo de feature temos:
6 Recipiente destinado ao acondicionamento de materiais (PRIBERAM, 2010). No contexto deste trabalho, contêineres são elementos de modelagem capaz de armazenar outros elementos de modelagem.
66
o Actor Link – são relacionamentos entre os próprios atores, entretanto
cada uma das ligações possui uma restrição distinta (Tabela 4.18, 4.19,
4.20 e 4.21).
Tabela 4.18 – Tratamento de restrição de dependência da feature ISA Feature: ISA Tipo de Restrição: Requer V_V
Relacionamento entre atores que representa uma generalização.
Requer ISA_Actor
Sempre que a feature ISA for selecionada requer que todas as subfeature de Actor
estejam selecionadas.
Requer ISA_Agent
Sempre que a feature ISA for selecionada requer que todas as subfeature de Agent
estejam selecionadas.
Requer ISA_Position
Sempre que a feature ISA for selecionada requer que todas as subfeature de
Position estejam selecionadas.
Requer ISA_Role
Sempre que a feature ISA for selecionada requer que todas as subfeature de Role
estejam selecionadas.
Tabela 4.19 – Tratamento de restrição de dependência da feature Plays
Feature: Plays Tipo de Restrição: Requer V_V
Relacionamento que informa o papel que um agente deve realizar.
Requer Plays_Agent
Sempre que a feature Plays for selecionada requer que a feature Agent esteja
selecionada.
Requer Plays_Role
Sempre que a feature Plays for selecionada requer que a feature Role esteja
selecionada.
Tabela 4.20 – Tratamento de restrição de dependência da feature Covers Feature: Covers Tipo de Restrição: Requer V_V
Relacionamento que descreve a relação entre uma posição e os papeis que ela
cobre.
Requer Covers_Position
Sempre que a feature Covers for selecionada requer que a feature Position esteja
selecionada.
Requer Covers_Role
67
Sempre que a feature Covers for selecionada requer que a feature Role esteja
selecionada.
Tabela 4.21 – Tratamento de restrição de dependência da feature Occupies Feature: Occupies Tipo de Restrição: Requer V_V
Relacionamento que descreve a relação entre uma posição e os papeis que ela
cobre.
Requer Occupies_Agent
Sempre que a feature Covers for selecionada requer que a feature Agent esteja
selecionada.
Requer Occupies_Position
Sempre que a feature Covers for selecionada requer que a feature Position esteja
selecionada.
o Dependency Link – descrevem a natureza do acordo (dependência)
entre atores (Tabela 4.22).
Tabela 4.22 – Tratamento de restrição de dependência da feature Dependency Link Feature: Dependency Link Tipo de Restrição: Requer V_VP
Requer Dependency Link _Compartment
Sempre que a feature Dependency Link for selecionada requer que as subfeature
de Compartment estejam selecionadas.
o Contribution Link – são relacionamentos que expressam a forma de
como um elemento contribui para a satisfação de softgoals (Tabela
4.23).
Tabela 4.23 – Tratamento de restrição de dependência da feature Contribution Link Feature: Contribution Link Tipo de Restrição: Requer V_V
Requer Contribution Link _Softgoal
Sempre que a feature Contribution Link for selecionada requer que a feature
Softgoal esteja selecionada.
o Decomposition Task – é um relacionamento decompõe um elemento
tarefa em quaisquer outros elementos intencionais da linguagem (4.24).
68
Tabela 4.24 – Tratamento de restrição de dependência da feature Decomposition Task Feature: Decomposition Task Tipo de Restrição: Requer V_V
Requer Decomposition Task _Task
Sempre que a feature Decomposition Task for selecionada requer que a feature
Task esteja selecionada.
o Means-end – o relacionamento meio-fim indica um relacionamento
entre um nó “fim” – que deve ser satisfeito – e um “meio” de atingi-lo
(um “meio” é expresso na forma de uma tarefa) (Tabela 4.25).
Tabela 4.25 – Tratamento de restrição de dependência da feature Means-End Feature: Means-end Tipo de Restrição: Requer V_V
Requer Means-end _Task
Sempre que a feature Decomposition Task for selecionada requer que a feature
Task esteja selecionada.
4.8 CONSIDERAÇÕES FINAIS
Neste capítulo foi apresentada uma comparação entre linguagens baseada no i*. Esta
comparação teve como foco identificar a variabilidade existente entre essas variações da
linguagem. Através dessa identificação também foi possível capturar as características
comuns entre elas.
A linguagem i* original foi comparada com as linguagens i* Wiki, Tropos, GRL, i*-c
e i* Aspectual. Nesta comparação foi possível capturar as diferenças entre os elementos de
modelagem existentes em cada linguagem, seus relacionamentos e suas restrições. O resultado
desta comparação será útil para a definição do metamodelo núcleo com suporte a
variabilidade que será apresentada no próximo capítulo.
Com as características comuns identificadas também foi possível descrever o modelo
de features para configuração das famílias de linguagens baseadas no i*. Neste modelo foi
descrito todas as features necessárias para a configuração de uma nova linguagem e definido
todo o tratamento de restrições de dependência entre as features do modelo.
Deste modo, como resultado desta análise, será apresentado no próximo capítulo o
metamodelo para a família de linguagens baseadas em i* que foi construído com base nos
pontos de variação identificados em nossa comparação. Este metamodelo será utilizado para
69
configurar metamodelos específicos de linguagens baseadas em i* e gerar as ferramentas
CASE correspondentes.
5 M
Com
varia
varia
que d
const
lingu
núcle
apres
METAMODELO PARA A FAMILIA DE LINGUAGENS I*
m a compar
ação existen
ação foi ess
dá suporte a
trução de
uagem é def
eo bem com
sentadas as
ração realiz
ntes entre al
sencial para
a inserção d
novas lingu
finida e por
mo a estraté
consideraçõ
zada no ca
gumas lingu
a a construç
dos elemento
uagens. É
r isto, neste
égia de con
ões finais.
apítulo ante
uagens base
ção do meta
os variantes
através do
e capítulo, s
nfiguração p
erior, foi p
eadas em i*
amodelo nú
s também id
o metamode
será apresen
para uma no
ossível ide
. A identific
úcleo da fam
dentificados
elo que a
ntada a cria
ova linguag
entificar os
cação deste
mília de lin
s na compar
estrutura s
ação deste m
gem. Por úl
70
pontos de
es pontos de
nguagens i*
ração para a
sintática da
metamodelo
ltimo, serão
0
e
e
*
a
a
o
o
5.1
mode
estru
(Met
tamb
que
meta
restri
(STE
meta
meta
elem
mode
meta
Figu
lingu
O METAM
De acor
elagem bem
utura é defin
ta Object Fa
bém conheci
são utiliza
amodelo util
ições herd
EINBERG e
Para des
amodelagem
amodelos pa
mentos de m
elagem. As
amodelo est
ura 5.1 – Dia
Através
uagem de m
MODELO N
rdo com K
m definida,
nida através
acility) (OM
idas como m
ados na co
liza os conc
dados da
et al., 2008)
screver a lin
m. Metamod
ara a defin
modelagem
ssim, um m
ar em confo
agrama repre
de um meta
modelagem.
NÚCLEO
Kleppe e ou
, é preciso
de outra lin
MG, 2010a)
meta-metam
oncepção e
ceitos de cla
linguagem
.
nguagem pr
delagem é
nição de me
e possíveis
modelo dev
ormidade co
esentativo dosAdaptad
amodelo tam
Restrições
utros (2003
o definir in
nguagem em
) ou EMF C
modelo, pos
estrutural d
asse, atribut
UML es
ropriamente
o ato de
etamodelos
relacionam
ve estar em
om um meta
s quatro nívedo de Kleppe
mbém é po
podem ser
3), para qu
nicialmente
m mais alto
Core (Ecore
suem uma g
de linguage
to, operação
specificame
e dita, é uti
utilizar a
. Metamod
mentos, ou
m conformid
a-metamode
eis de abstraçe e outros (200
ssível defin
entendidas
ue tenhamo
a estrutura
nível, como
) (EMF, 20
gama de ele
ens de mo
o, parâmetro
nte dos d
lizado o m
estrutura o
elo por sua
seja, a sinta
dade com
elo (Figura
ão de modelo03)
nir as restriç
como um c
os uma ling
a da lingua
o por exemp
010). Essas
ementos bem
odelagem.
o de relacio
diagramas
mecanismo c
oferecida p
a vez defin
axe das lin
o metamod
5.1).
os propostos p
ções impost
conjunto de
71
guagem de
agem. Essa
plo, o MOF
linguagens,
m definidos
Um meta-
onamento, e
de classe
chamado de
pelos meta-
ne todos os
guagens de
delo, e um
pela OMG.
tas em uma
e regras que
e
a
F
,
s
-
e
e
e
-
s
e
m
a
e
72
expressam como elementos de modelagem de uma determinada linguagem podem se
relacionar (OMG, 2010b), ou seja, é através da representação das restrições que a estruturação
bem definida de uma linguagem é concebida em um metamodelo.
Com a pretensão de construir uma família de linguagens baseadas no i*, faz-se
necessário a definição de um metamodelo que represente a estrutura básica desta família.
Entretanto, como se pode observar na Seção 4.7, existe uma variabilidade nas características
de cada uma das linguagens analisadas. A captura desta variabilidade possibilitou a
identificação das características comuns e diferentes entre elas. As características comuns
entre estas linguagens podem ser entendidas como sendo uma base compartilhada entre elas e
é preciso definir a sintaxe desta base através do mecanismo de metamodelagem.
O metamodelo proposto na Figura 5.2 representa apenas os elementos comuns
identificados na comparação feita no capítulo anterior. Ele representa o núcleo que uma nova
linguagem baseada no i* deve obrigatoriamente possuir (herdar). Neste metamodelo, os
pontos de variação (Atores, Elementos Intencionais e Relacionamentos) tornam-se
metaclasses (Compartment, ElementMC e Relationship) que possibilitam diferenciados tipos
de especialização. Particularmente, Compartment e ElementMC podem ser especializados
através de um tipo especial de metaclasse chamada de Enumeration 7 (e.g.
CompartmentType e ElementMCType). Este mecanismo de extensão permite definir as
possíveis especializações (tipos) que estes elementos de modelagem podem ter. A metaclasse
Relationship possui uma variação de características um pouco mais difícil de ser
representada no metamodelo. Como descrito na Seção 3.2, uma variante de relacionamento
pode ser também um ponto de variação (por exemplo, uma ligação contribuição pode ser uma
variante de relacionamentos, mas também pode ser um ponto de variação já que possui
diversos tipos específicos tais como Make, Break, Help e etc). A representação deste tipo de
variação na definição do metamodelo implica em metaclasses distintas para cada tipo de
relacionamento. Como alguns destes relacionamentos podem possuir pontos de variação, a
metaclasse de Enumeração poderá ser utilizada para representar estas especializações.
Por representar apenas o núcleo de características entre as linguagens baseadas no i*
analisadas, este metamodelo proporciona um grau de flexibilidade suficiente para inserir as
peculiaridades de qualquer nova linguagem baseada no i*. Foi construído para suportar a
7 São estruturas de dados enumeradas de constantes organizados em ordem de declaração. A funcionalidade principal de enum é agrupar valores com o mesmo sentido dentro de uma única estrutura, como por exemplo, meses, dias da semana, cores, tabela periódica, etc. e também limitar ou determinar um número de valores que podem ser usados na programação (PILONE; PITMAN, 2005).
inclu
lingu
LPS
meta
no m
usão de nov
uagem pode
para a co
amodelos di
Sendo as
metamodelo
Mod
(Nod
um r
Com
poss
mod
meta
com
Inte
inse
um a
um
exis
ser i
um
vas caracter
e ter. Isto im
oncepção d
stintos base
Figura 5
ssim, abaixo
núcleo:
del (Mode
deObject e
repositório
mpartment
suem a car
delagem tais
aclasse Co
mpartimento
entionalEle
ridos tanto
atributo den
enumeratio
tentes (Figu
inserido den
compartim
rísticas, a fi
mplica dize
de famílias
eados no i*.
5.2 – Metamo
o encontram
lo) – repre
e Relationsh
de atores, e
(Compart
racterística
s como elem
ompartmen
s podem
ments (do
no Compa
nominado ty
on que é ut
ura 5.3). Ist
ntro do enum
mento com
fim de satis
er que o me
de metam
.
odelo núcleo
m-se as des
esenta o “
hip) podem
elementos in
timento) –
de armaze
mentos inte
nt represen
ser ins
tipo Elem
artment be
ype do tipo
utilizado par
to implica d
meration C
m atributo
sfazer as ne
etamodelo n
modelos, qu
com suporte
crições deta
palco” ond
m ser inserid
ntencionais
– atores são
enar em se
encionais e r
nta os ato
eridos em
mentMC, e
em como no
Compartm
ra represen
dizer que u
ompartme
os específi
ecessidades
núcleo obed
ue tem com
a variabilida
alhadas de c
de os elem
os, ou seja,
e relacionam
o elemento
eu interior
relacioname
ores da li
m um M
explicados
o Model. E
mentType.
ntar todas a
um novo ato
ntType. Ta
cos e di
particulare
dece aos pr
mo produto
ade
cada eleme
mentos de m
, a metaclas
mentos.
os de mode
outros ele
entos, e sen
inguagem.
Model e
a seguir)
Esta metacl
Compartm
as variações
or quando c
ambém é po
iferentes d
73
es que cada
rincípios de
o resultante
nto contido
modelagem
se Model é
elagem que
ementos de
ndo assim a
Diferentes
diferentes
podem ser
asse possui
mentType é
s de atores
criado deve
ossível criar
dos outros
3
a
e
e
o
m
é
e
e
a
s
s
r
i
é
s
e
r
s
com
com
meta
Com
acon
Com
tais
exem
espe
Fig
Figura 5.
mpartimento
mpartimento
aclasse de
mpartment
ntece pelo
mpartment
característ
mplificar a c
ecificamente
gura 5.3 – Ex
4 – Exemplo
s existentes
deve ser t
ve existir
e então os
fato de qu
, pois isto o
ticas. A Fi
concretizaçã
e a criação d
xemplo de var
de variações
s na lingu
tratado de
para rep
s seus atrib
ue atributo
obrigaria qu
igura 5.5
ão dos conc
de atores no
riações do Co
s do Compart
agem (Figu
forma dife
presentá-lo
butos espec
s não pod
ue todos os o
representa
ceitos apres
o modelo.
ompartment
tment com at
ura 5.4). N
erenciada e
e deve h
cíficos pode
erem ser c
outros comp
um mode
entados na F
no metamode
ributo no me
Neste caso,
em sua cr
herdar a
em ser defi
criados na
partimentos
elo i* resu
Figura 5.3.
elo núcleo
etamodelo nú
74
este novo
riação uma
metaclasse
finidos. Isto
metaclasse
s herdassem
umido para
Representa
úcleo
4
o
a
e
o
e
m
a
a
Figura
Elem
inten
noss
pode
a m
meta
um
inten
Figu
dos
elem
com
F
5.5 – Exemp
mentMC –
ncionais sem
so metamod
erem ser cri
metaclasse E
aclasse pos
enumeratio
ncionais qu
ura 5.7 repr
conceitos
mento intenc
mo no compa
Figura 5.6 – E
A
plo concreto d
em todas a
mpre estão
delo núcleo
iados tanto
ElementMC
sui um atrib
on utilizado
ue possam e
resenta um
apresentado
cional deno
artimento (C
Exemplo de va
ACTOR
da representa
as linguage
presentes e
o. Todos es
no Model q
C foi comp
buto denom
o para rep
existir no M
modelo i*
os na Figur
ominado Go
Compartm
ariações do E
ação sintática
ens compara
e, por este m
stes elemen
quanto no C
posta em M
minado type
presentar to
Model e no
resumido p
ra 5.6. Rep
oal pode ser
ent).
ElementMC n
a apresentado
adas anterio
motivo, est
ntos possue
Compartme
Model e em
do tipo El
odas as var
o Compart
para exempl
presenta esp
r criado tant
no metamodel
o na Figura 5
ormente, os
ta classe foi
em a carac
ent e, por e
m Compart
lementMCT
ariações de
tment (Figu
lificar a co
pecificamen
nto no mode
elo núcleo
75
.3
s elementos
i criada em
terística de
este motivo,
ment. Esta
Type que é
elementos
ura 5.6). A
ncretização
nte que um
elo (Model)
5
s
m
e
,
a
é
s
A
o
m
)
Figura
In
a in
meta
repr
(Ele
i*,
Com
nova
exem
no M
ser i
Inte
inten
defin
Elem
para
no M
Elem
resu
inten
liter
um
esta
para
a 5.7 - Exemp
ntentionalE
nclusão de
amodelo nú
esenta os e
ementMC).
é possível
mpartment
a metaclass
mplo, Elem
Model ou E
inseridos no
entionalEle
ncionais, m
nido para
mentComp
a representa
Model (qua
mentComp
umido do i
ncional sen
al TASK n
modelo res
linguagem
a identifica
lo concreto d
Element – é
e novos ti
úcleo, esta
elementos q
No entanto
existir ele
ou no Mo
se de eleme
mentModel p
ElementCom
o Compart
ment para
mas incluirá u
cada nov
partmentTy
ar todas as v
ando for El
partmentTy
* Aspectua
ndo criado a
na enumeraç
sumido do i
não foi util
ação de ou
da representa
é uma meta
ipos de el
metaclasse
que podem
o, percebeu-
ementos int
odel. Desta
entos intenc
para elemen
mpartment
tment. Cad
a poder
um atributo
va metaclas
ype, respect
variações d
lementMod
ype) (Figur
al como ex
apenas no
ção Elemen
i* Law (SI
lizada em n
utras carac
ação sintática
aclasse abst
lementos i
e é estendi
ser criados
-se que, em
tencionais q
forma, se
cionais dev
ntos intenci
t para elem
da uma dest
herdar as
o denominad
sse criada
tivamente).
de elemento
delType) ou
a 5.8). A F
xemplo de
compartime
ntCompart
ENA et al.
nossas comp
cterísticas
GOA
apresentado
rata que tem
intencionais
ida apenas
s no Mode
m uma nova
que só pod
um destes
ve ser criad
ionais que s
mentos inten
as metaclas
caracterís
do type, que
(e.g., Ele
Os enume
s intenciona
u no Comp
Figura 5.9
concretiza
ento. Neste
Type. Já a
, 2010) (im
parações, ma
específicas)
AL
o na Figura 5
m a função
s na lingu
pela meta
el e no Com
linguagem
dem ser in
casos exis
da para cada
só podem se
ncionais que
sses estende
sticas de
e será um en
ementMode
erations são
ais que pos
partment (
apresenta u
ação de um
e caso foi in
Figura 5.1
mportante re
as foi toma
) como ex
76
.6
de permitir
uagem. No
aclasse que
mpartment
baseada no
nseridos no
stirem, uma
a caso. Por
er inseridos
e só podem
erá a classe
elementos
numeration
elType ou
o utilizados
ssam existir
(quando for
um modelo
m elemento
nserido um
0 apresenta
essaltar que
da por base
xemplo de
6
r
o
e
t
o
o
a
r
s
m
e
s
n
u
s
r
r
o
o
m
a
e
e
e
conc
dos
Elem
atrib
lingu
e em
meta
defin
meta
inten
com
amb
exem
espe
com
Figura
cretização d
compartim
mentModel
butos especí
uagem. Nes
m sua cria
aclasse Inte
nidos. Isto
aclasse Inte
ncionais he
mposto no m
bos (Figura
mplo de c
ecíficas (atr
mpartimento
a 5.8 – Exemp
de um elem
entos). Nes
lType. Tam
íficos e dife
ste caso, est
ção uma m
encionalEle
acontece p
encionalEle
erdassem t
modelo (M
5.11). A Fi
concretizaçã
ributo card
.
plo de variaçõ
mento intenc
ste caso foi
mbém é po
ferentes dos
te novo elem
metaclasse
ement e en
pelo fato de
ement, pois
tais caracte
Model), nos
igura 5.12 a
ão de um
dinalidade n
ões de elemen
cional send
i inserido u
ossível cria
outros elem
mento deve
deve existi
ntão os seus
e que atribu
s isto obriga
erísticas. E
s compartim
apresenta um
elemento
no interior
ntos intencion
o criado ap
um literal N
r um elem
mentos inte
ser tratado
ir para rep
s atributos e
utos não po
aria que todo
Este novo
mentos (Co
m modelo re
intenciona
do elemen
nais no metam
penas no m
NORM na e
mento intenc
encionais ex
de forma d
presentá-lo
específicos
oderem ser
os os outros
elemento
ompartmen
resumido do
al com car
nto) sendo
modelo núcle
77
modelo (fora
enumeração
cional com
xistentes na
diferenciada
e herdar a
podem ser
criados na
s elementos
poderá ser
nt) ou em
o i*-c como
racterísticas
criado no
eo
7
a
o
m
a
a
a
r
a
s
r
m
o
s
o
Figu
Figu
ura 5.9 - Exe
ura 5.10 - Exe
Figura 5
mplo concretnos comparti
emplo concre
5.11 – Exemp
to da represeimentos. Base
eto da represenos compa
plo de variaçõ
entação sintáteado no i* As
entação sintáartimentos (S
ões de elemen
tica de um elespectual (ALE
ática de um elIENA et al., 2
ntos com atrib
emento intencENCAR et al
lemento inten2010)
butos no meta
cional existenl., 2010)
ncional existe
amodelo núc
78
ntes apenas
entes apenas
leo
8
Figu
ra 5.12 - Exe
Rela
cara
relac
de c
ser
relac
do M
assim
inclu
relac
a cla
men
amb
relac
entre
de l
com
mod
mplo concret
ationship –
acterísticas q
cionamento
contribuição
dentro ou
cionamento
Model, por
m como a
usão de n
cionamento
asse Relati
nos um dos
bos. É nec
cionamento
e a metacla
ligação (Fig
mo exemplo
delo (fora do
to da represeesp
– os diverso
que devem
os podem po
o) e, particu
u fora do
o pode exist
exemplo. S
a metaclass
novos tipo
o deverá ser
onship e d
s repositório
essário tam
o (source e t
asse que rep
gura 5.13).
de concret
os comparti
entação sintátpecífica (BOR
os relaciona
ser represe
ossuir atribu
ularmente, s
os compart
tir ou ser cr
Sendo assim
se Intentio
os de rela
criado com
deverá ter u
os do meta
mbém defin
target) e, pa
presenta o re
A Figura
tização da l
imentos).
tica de um eleRBA, 2010)
amentos exi
entadas dist
utos diferen
ão compost
timentos).
riado, se de
m, Relations
nalElemen
acionamento
mo uma nov
um relaciona
amodelo, is
nir os poss
ara isto, dev
elacioname
5.14 aprese
ligação de
emento intenc
istentes no
tintamente n
nciados (com
tos em luga
A compo
ntro do Co
ship é uma
nt, tem a f
os na ling
a metaclass
amento de
sto é, Mod
síveis elem
ve-se criar l
nto e os do
enta um mo
dependênci
cional com ca
i* possuem
no metamo
mo é o caso
ares distinto
osição diz
ompartmen
metaclasse
função de
guagem. C
se, que deve
composição
del, Compa
mentos de
ligações de
ois possíveis
modelo resum
ia existindo
79
aracterística
m diferentes
odelo. Estes
o da ligação
os (podendo
onde um
nt ou dentro
e abstrata e,
permitir a
Cada novo
erá estender
o com pelo
artment ou
ligação do
associação
s elementos
mido do i*
o apenas no
9
s
s
o
o
m
o
,
a
o
r
o
u
o
o
s
*
o
Figu
5.2
meta
comp
seria
Figu
ura 5.14 - Exe
ESTRATE
No de
amodelagem
posição.
O princip
am criadas
ura 5.13 – Ex
emplo concre
EGIAS PAR
senvolvime
m na tentativ
pal problem
para repr
xemplo de var
eto da represe(YU, E. 199
RA EXTEN
ento desta
va de reduz
ma encontra
resentar os
riação de rela
entação sintá95) apresenta
NSÃO DE M
as soluçõe
zir a comple
ado estava r
s novos e
acionamentos
ática de uma lado na Figura
METAMOD
es aplicam
exidade do m
relacionado
lementos d
s no metamod
ligação de dea 5.13
DELOS
mos algum
metamodelo
à quantida
de modela
delo núcleo
ependência do
mas estra
o resultante
ade de meta
agem, bem
80
o i* original
atégias de
e após a sua
aclasses que
como os
0
e
a
e
s
81
relacionamentos envolvidos nelas, ou seja, onde seriam compostas, possíveis heranças,
relacionamentos com outros elementos de modelagem e etc.
Como soluções para este tipo problema (PILONE; PITMAN, 2005), é possível citar
algumas mais tais como:
Tagged Values – é uma combinação entre uma tag e um valor que fornece
informações complementares que é anexado a um elemento modelo. É utilizada
para adicionar propriedades a qualquer elemento de modelagem da linguagem
Esta estratégia pode ser utilizada apenas nos diagramas de classes da UML.
Stereotypes – estereótipos permitem a criação de novo vocabulários na
linguagem a fim de criar novos elementos de modelagem derivando características
dos que já existem, mas com propriedades especificas que são adequadas ao
domínio do problema. Esta estratégia pode ser utilizada nos diagramas de classes
da UML.
Enumeration – são classes que representam tipos específicos definidos pelo
usuário. Contém um conjunto de identificadores de chamada que representam os
valores da enumeração. São conhecidos como literais. Esta estratégia pode ser
utilizada nos diagramas de classes da UML que é representada como um
Stereotype e também pode ser utilizada nos diagramas Ecore.
Para criação dos metamodelos a estratégia mais utilizada foi a de enumeração. Com
ela conseguimos reduzir a criação excessiva de metaclasses para representação dos novos
elementos de modelagem compostos no metamodelo. Através da representação em forma de
literais, uma metaclasse mais abstrata é criada para representar um tipo de um elemento de
modelagem e, por conseqüência, todos os elementos de modelagem que forem criados com
esse mesmo tipo são tratados com um literal de uma enumeração. As metaclasses do
metamodelo núcleo, que foram tratadas com essa estratégia, foram: Compartment e
ElementMC
Em particular, a metaclasse do metamodelo núcleo denominada NodeObject foi
criada a fim de diminuir a complexidade dos relacionamentos entre algumas metaclasses do
metamodelo núcleo. Ela é uma metaclasse abstrata que foi criada baseada no padrão de
projeto Strategy (GAMMA et al., 2000) com a finalidade de representar todos os nós de uma
linguagem. Com o uso desta estratégia é possível atingir dois objetivos principais. O primeiro
está relacionado a ajudar a reduzir a complexidade do metamodelo, visto que a criação desta
metaclasse reduz o número de ligações entre os nós que precisam se relacionar. No exemplo
exist
New
lingu
repre
sour
elem
ligar
elem
inten
ser c
lingu
(Com
tente na Fig
wRelationsh
uagem (Co
esentação fo
rceElement
mento de mo
apenas à
mentos que
ncionais. Pa
criada e herd
uagem. Este
mpartment
Figura 5.
gura 5.9, é
hip existe
mpartmen
ossem dupli
e targetEl
odelagem qu
ela (Figura
especificam
ara que isto
dar a metac
e novo elem
t) ou em am
15 – Exemplo
possível ob
a represent
t e Eleme
icadas para
lement). Um
ue precise m
a 5.8). O
mente não
seja possív
classe Node
mento poder
mbos (Figura
o de configur
bservar que
tação de s
entMC). Pa
a cada nó (s
ma vez que
manter um
segundo ob
possem int
vel, uma me
eObject, pa
rá ser contid
a 5.10).
ração de sour
e na existên
seu relacion
ara isto foi
sourceCom
e a metacla
relacionam
bjetivo está
tencionalida
taclasse que
ara que seja
do no mode
rces e targets s
ncia de um
namento co
i necessário
partment,
asse NodeO
ento com to
á relacionad
ade, ou sej
e represente
considerad
elo (Model)
sem a metacl
ma ligação d
om todos
o que as l
targetCom
Object exist
odos os nós
do com a
a, não são
e estes elem
do com um
l), nos comp
lasse NodeOb
82
denominada
os nós da
ligações de
mpartment,
ta, qualquer
s, deverá se
criação de
o elementos
mentos deve
novo nó da
partimentos
bject
2
a
a
e
,
r
e
e
s
e
a
s
5.3
que é
qualq
novo
princ
conc
ser c
comp
repre
entre
meta
dos
relac
carac
prese
Figura 5.
CONSIDE
Neste Ca
é proposta
quer linguag
os elemento
cípios de L
eitos princi
configurado
pleta da ling
É impor
esentação da
e os elemen
amodelo. A
elementos
cionamentos
cterísticas c
entes no m
16 – Exemplo
ERAÇÕES
apítulo foi a
neste trabal
gem basead
os de mod
LPS. Isto im
ipais do i*
os e incluíd
guagem.
rtante ress
as restriçõe
ntos de mo
definição d
de modelag
s das ling
comuns. En
metamodelo
o de configur
FINAIS
apresentado
lho. Por rep
da no i*, est
elagem par
mplica dizer
serão reusa
dos neste m
saltar que
s que envol
odelagem nã
de restriçõe
gem. Na T
guagens fo
ntão é pos
núcleo e
ração de sour
o o metamod
presentar ap
te metamod
ra criar um
r que, semp
ados (metam
metamodelo
o metamo
lvem os ele
ão foram r
es é atribuíd
Tabela 4.11
oram tratad
ssível conc
assim as
rces e targets c
delo núcleo
penas os el
delo é flexív
ma nova li
pre que um
modelo núcl
o, a fim de
odelo núcle
ementos con
representado
da através d
da Seção
dos como
luir que se
restrições
com a metacl
o que será u
ementos co
vel o suficie
nguagem o
ma nova ling
leo) e os no
e representa
eo possui
ntidos. Muit
os entre os
da definição
4.7 é poss
variantes
e os relaci
impostas n
lasse NodeOb
utilizado na
omuns obrig
ente para a
obedecendo
guagem for
ovos elemen
ar fielmente
limitações
tas restriçõe
elementos
o dos relac
sível obser
e não co
ionamentos
nelas não
83
bject
abordagem
gatórios em
inserção de
o assim, os
r criada, os
ntos devem
e a sintaxe
quanto a
es impostas
núcleo no
ionamentos
rvar que os
omo sendo
não estão
podem ser
3
m
m
e
s
s
m
e
a
s
o
s
s
o
o
r
84
representadas. Contudo, na abordagem proposta neste trabalho serão apresentadas técnicas
que serão utilizadas para solucionar estas lacunas.
Para cada elemento existente no metamodelo núcleo, apresentou-se algumas regras de
como um novo elemento de modelagem de determinados tipos podem ser inseridos (e.g.,
novos compartimentos, elementos intencionais ou relacionamentos). A partir de tais regras
percebeu-se que o nível de abstração quanto à metamodelagem poderia ser aumentado
através de uma abordagem de configuração automática de metamodelos. O aumento do nível
de abstração para metamodelagem para se tornar automática reduz o esforço empenhado em
sua construção diminuindo assim o tempo de desenvolvimento agregado e promovendo
aumento de produtividade no projeto.
Assim no próximo capítulo será apresentado a abordagem AGILE que foi construída
para proporcionar a geração automática de metamodelos bem como, a geração de outros
artefatos para a criação de editores gráficos utilizando a tecnologia GMF (Graphical
Modeling Framework).
6 A
Previ
atrav
i*. E
proce
ferra
autom
Lang
Engi
lingu
apres
desen
AGILE – AUTOMATIC GENERATION OF I* LANGUAGES
iamente foi
vés de uma e
Entretanto id
esso de co
amenta de
mática. Ass
guages) que
ineering) co
uagens base
sentadas a
nvolviment
i discutida a
estratégia d
dentificou-s
onfiguração
apoio para
sim, este cap
e propõe um
onstruída pa
eadas no i*
s motivaçõ
o da mesma
a construção
de configura
se a necessi
o dos meta
a executar
pítulo apres
m processo
ara permitir
e a geração
ões e obj
a.
o de um me
ação de met
idade de es
amodelos e
as princip
senta a abor
o e uma fe
a configura
o automática
etivos da
etamodelo n
amodelos p
specificar um
e consequen
pais ativida
rdagem AG
rramenta C
ação do me
a de seus re
abordagem
núcleo para
ara novas li
ma abordag
ntemente a
ades deste
GILE (Autom
CASE (Com
etamodelo n
spectivos e
m, bem co
suportar va
inguagens b
gem para d
a construçã
processo d
matic Gene
mputer-Aide
núcleo de fo
editores gráf
omo o pr
85
ariabilidade
baseadas no
efinição do
ão de uma
de maneira
ration of i*
ed Software
orma a criar
ficos. Serão
rocesso de
5
e
o
o
a
a
*
e
r
o
e
86
6.1 INTRODUÇÃO
O framework i* é uma abordagem orientada a objetivos amplamente utilizada na
academia (PIMENTEL et al., 2010) (MAIDEN et al., 2010) (ANNOSI et al., 2008)
(CARVALHO; FRANCH, 2009). Seu reconhecimento se dá pela sua rica capacidade
semântica de descrever diferentes dependências sociais e intencionais entre os atores e o seu
ambiente organizacional, bem como os requisitos funcionais e não funcionais de um sistema.
Embora amplamente utilizado, um dos principais desafios em trabalhar com ele, é a
diversidade de variantes de linguagem de modelagem baseadas i* que foram propostas por
diferentes grupos de pesquisa para atingir suas necessidades específicas.
Como resultado, novos elementos de modelagem da linguagem i* surgiram. Esses
elementos fazem parte das diferentes variações do i* como, por exemplo, i* Wiki (GRAU et
al., 2008), Tropos (SUSI et al., 2005), GRL (AMYOT et al., 2009), i*-c (BORBA, 2009) e
Aspectual i* (ALENCAR et al., 2010), entre outras. Neste cenário, o desenvolvimento do
suporte ferramental para cada uma destas linguagens foi realizado de forma distinta entre os
grupos de pesquisa a fim de satisfazer as suas necessidades. Contudo, o apoio ferramental
adequado para cada variante tem alto custo de desenvolvimento, bem como há um
considerado tempo para a sua entrega. Algumas linguagens ainda não possuem suporte
ferramental justamente devido ao custo elevado de desenvolvimento. Além disso, de acordo
com Lucena (2008) essas variações de linguagens baseada no i* podem causar:
1. Divisão de esforço, já que cada grupo de pesquisa se concentrará no
desenvolvimento de ferramentas para apoiar o seu próprio dialeto;
2. Incompatibilidade semântica entre os escritores e leitores de um determinado
modelo i*;
3. A inibição da adoção i * por novos usuários devido a grande variação de
linguagens. Este problema também pode ocorrer com qualquer linguagem de
modelagem que não tem uma versão padrão.
Considerando essas variações, foi possível identificar um conjunto comum de
características, afinal, são linguagens baseadas i*, bem como um conjunto de características
variáveis. A partir disso identificou-se um núcleo comum entre estas linguagens (vide
Capítulo 5), identificando os elementos de modelagem comum e separando os elementos de
modelagem variáveis, para posteriormente configurá-los a fim de reduzir o esforço para
desenvolver suportes ferramentais para as variações do i*. Para que isto seja possível é
87
necessário a definição de uma abordagem de configuração a fim de prover um suporte
consistente na criação de editores gráficos (ou suporte ferramental) de maneira mais ágil e
eficiente.
Assim surgiu a abordagem AGILE (Automatic Generation of i* Languages). Esta
abordagem oferece uma ferramenta CASE (Computer-Aided Software Engineering) de
geração automática de editores gráficos para linguagens baseadas no i*. A ferramenta CASE é
integrada ao GMF (Graphical Modelling Framework) (GMF, 2010) que é um framework para
o Eclipse8 que provê maior simplicidade e agilidade no desenvolvimento de editores gráficos.
Para isto o GMF (GMF, 2010) utiliza uma metodologia de desenvolvimento de software que
se concentra na criação de modelos ao invés da produção em baixo nível (algoritmo)
denominada MDD (Model Driven Development) (OMG, 2010c).
Os metamodelos são de extrema importância no processo de desenvolvimento de
editores gráficos usando o framework GMF, pois são neles que definem a sintaxe da
linguagem e do próprio editor gráfico. A definição do metamodelo é realizada manualmente
pelos desenvolvedores e, para isto, faz-se necessário o real entendimento e experiência sobre
como o Ecore (EMF, 2010) e o GMF funcionam. Da mesma forma é necessário conhecer a
sintaxe da linguagem a ser representada. Isso foi identificado como um ponto crítico do
processo de criação de editores gráficos pelo fato de existir a necessidade de empenhar a
maior parte do tempo de desenvolvimento na construção dos metamodelos. Esta etapa do
processo pode ser automatizada para alcançar uma maior produtividade na construção de
editores gráficos.
Sendo assim, a abordagem AGILE tem como objetivos prover um aumento do nível de
abstração para construção de metamodelos, através da instanciação do metamodelo núcleo
proposto no Capítulo 5 e da definição de técnicas para composição do mesmo. Assim como,
prover um aumento do nível de abstração para a construção dos modelos de configuração do
GMF necessários para o desenvolvimento de editores gráficos.
A seção a seguir apresenta detalhes sobre o GMF, para que seja possível entender o
seu uso na criação de editores gráficos.
8 Eclipse é uma IDE (Integrated Development Environment) para desenvolvimento de projetos software com código aberto para a construção de sistemas (ECLIPSE, 2010).
6.2
(GM
uma
tamb
espec
Java
de ed
ambi
execu
de f
aplic
const
edito
Ferra
(Gen
9 APIrotinaaplicaque p2009)
O PROCE
O frame
MF, 2010) é
infra-estrut
bém do Ecl
cificação de
respectivo,
ditores gráfi
A Figura
iente de exe
utando usan
Figu
GMF (G
ferramentas
cados a um
trução de q
or. Estes m
amental (To
nerator Mo
, Application
as e padrões ativos. De mopermitem utili).
ESSO DE C
ework de m
um projeto
tura para o
lipse – EM
e metamode
, e GEF (Gr
icos genéric
a 6.1 ilustra
ecução do G
ndo a plataf
ura 6.1 – Fram
GMF, 2010)
para a pr
m determina
quatro mode
modelos sã
ools Model)
del). Cada
n Programmin
estabelecidodo geral, a APizar caracterís
CRIAÇÃO D
modelagem
da Eclipse
desenvolvi
MF (Eclipse
elos e provê
raphical Ec
cos.
a o ambien
GMF e comp
forma Eclips
mework GMF
é um plug-
rodução au
ado domínio
elos que são
ão (Figura
), Modelo d
um desses
ng Interface (s por um soPI é compostasticas do softw
DE EDITOR
gráfica (G
Foundation
imento de e
e Modeling
ê funcional
clipse Fram
nte onde um
mponentes di
se.
F e dependên
-in para o E
utomática d
o. Este fra
o utilizados
6.2): Mod
de Mapeam
s modelos
(ou Interface oftware para a por uma sértware menos
RES GRÁF
Graphical M
n (ECLIPSE
editores grá
g Framewo
lidades para
mework) (GE
m editor, co
isponibiliza
ncias. Adapta
Eclipse, que
de editores
mework de
s para repre
delo Gráfic
mento (Mapp
é compost
de Programautilização de
rie de funçõesevidentes ao
ICOS COM
Modelling F
E, 2010) cuj
ficos basea
rk) (EMF,
a a geração
EF, 2010) u
nstruído se
dos pelo EM
do de Venkat
fornece um
(baseados
e desenvolv
esentar difer
co (Graphi
ping Model)
to de class
ação de Aplice suas funcios acessíveis sousuário tradic
M O GMF
Framew or
jo propósito
ados nos fra
2010), que
automática
utilizado par
egundo o G
MF e GEF,
tesan (2006)
ma API9 e u
em mode
vimento é d
erentes aspe
ical Model
l) e o Mode
ses e assoc
cativos) é umonalidades poomente por pricional (SIER
88
rk – GMF)
o é fornecer
ameworks –
e auxilia a
a do código
ra a criação
MF, opera:
todos estes
um conjunto
elos Ecore)
dividido na
ectos de um
l), Modelo
elo Gerador
ciações que
m conjunto deor programasrogramação, eRA; BATES,
8
)
r
–
a
o
o
:
s
o
)
a
m
o
r
e
e s e ,
repre
tradu
(Figu
proje
gráfi
Mode
Ecor
Esse
Mod
do m
defin
códig
desej
forne
esentam alg
uzido em có
Para a c
ura 6.2 e/ou
eto será cri
co a ser con
del) na Figur
re (EMF, 2
s três mode
delo de Map
modelo gráfi
nidos aprop
go executáv
jada para o
ecer a persis
gum elemen
ódigo GEF q
onstrução d
u Figura 6.
ado o meta
nstruído. Es
ra 6.2, é de
010). Em s
elos formam
peamento é
fico e aos el
priadamente
vel do edito
s elementos
stência e a s
to do diagra
que implem
Figura 6.2 –
do editor, a
.3). Esse pr
amodelo qu
ste metamod
escrito usan
seguida, são
m a base pa
criado para
lementos do
, o GMF f
or gráfico. E
s da lingua
sincronizaçã
ama da ling
menta o edito
– Modelos do
alguns passo
rocesso é i
ue define a
delo, també
ndo a lingua
o criados o
ara a criaçã
a relacionar
o modelo f
fornece um
Esse código
agem e o m
ão entre ele
guagem dest
or.
GMF (GFM
os devem s
niciado cria
linguagem
m chamado
agem de des
o Modelo G
ão do editor
os elemento
ferramental.
Modelo G
o fará a liga
metamodelo
s.
tino que, qu
. 2010)
er seguidos
ando-se um
m para a qu
o de Modelo
scrição de m
Gráfico e o
r gráfico e
os do metam
Uma vez q
Gerador que
ação entre a
que define
uando proce
s utilizando
m projeto G
ual se destin
o de Domín
metamodelo
o Modelo F
é a partir d
modelo, aos
que os mod
é usado p
a representa
a linguagem
89
essado, será
-se o GMF
GMF. Neste
na o editor
io (Domain
os chamada
Ferramental.
deles que o
s elementos
delos foram
ara gerar o
ação gráfica
m, além de
9
á
F
e
r
n
a
.
o
s
m
o
a
e
Figur
acon
meto
na g
perce
autom
ra 6.3 – Proce
Como d
ntece de m
odologia foi
geração de
eberam-se
mática com
Cria
realiz
Cria
autom
é real
Cria
possu
armaz
Confi
manu
Cria
mode
exibiç
esso de criaçã
descrito ante
maneira aut
i empregada
editores g
alguns pro
mo, por exem
o modelo
ada manual
definição
maticamente
izada manu
o modelo
uem a cara
zenar outro
igurações
ualmente no
o modelo
lagem poss
ção dos elem
ão de uma edi
eriormente,
tomática ut
a a fim de p
gráficos pa
oblemas esp
mplo:
de domín
lmente;
o gráfica:
e, entretanto
ualmente;
de mapeam
acterística
os elemento
relacionada
artefato ger
gerador: n
sam ser inc
mentos dent
itor gráfico c
a geração
tilizando o
prover agili
ara linguag
pecíficos q
nio: a criaç
a estrut
o a forma g
mento: a d
de ser um
os em seu
as a este
rado pela at
necessário re
cluídos nos
tro de um co
como framew
o dos artefa
os conceito
idade, eficiê
gens de m
que compro
ão do mod
tura dos
gráfica de ca
definição do
m compartim
u interior)
exemplo
tividade Cr
ealizar conf
compartim
ompartimen
work GMF uti
atos represe
os da meto
ência e aum
modelagem.
ometem o
delo de dom
elementos
ada dos elem
os elemento
mento (ele
é realizad
também
ia definição
figurações p
mentos, por
nto.
ilizando a no
entados na
odologia M
mento na pro
Entretanto
conceito d
mínio (meta
gráficos
mentos de m
os de mode
emento que
da de form
deve ser
o gráfica (.
para que el
exemplo, o
90
tação BPMN
Figura 6.3
MDD. Esta
odutividade
o, em uso,
de geração
amodelo) é
é gerada
modelagem
elagem que
e consegue
ma manual.
r realizada
gmfgraph);
ementos de
o layout de
0
N
3
a
e
,
o
é
a
m
e
e
.
a
;
e
e
91
É fato que se torna necessário que os desenvolvedores detenham o conhecimento
necessário sobre como a metodologia MDD foi implantado no framework bem com, o seu
funcionamento para que seja possível utilizá-lo da maneira correta e assim obter o alto índice
de produtividade oferecido. Neste caso existe um problema que está relacionado com a curva
de aprendizagem dos desenvolvedores para com a tecnologia, e com o tempo para que isso
seja realizado. Isso acontece pelo fato de existir o envolvimento de muitos novos conceitos
(tais como a própria metodologia MDD) e tecnologias envolvidas a serem compreendidas. No
caso de uma equipe experiente com o uso do framework existiria uma redução no tempo de
desenvolvimento da aplicação, visto que o esforço para deter o conhecimento sobre a
tecnologia não seria necessário.
Um problema importante a ser apresentado está diretamente relacionado com o
primeiro artefato que deve ser criado no processo (Figura 6.3, Criação do modelo de
domínio), o metamodelo. Esta atividade em particular não é criada ou executada
automaticamente pelo GMF diferentemente dos outros modelos de configuração, ou seja, este
artefato é criado manualmente pelos desenvolvedores. É a partir do metamodelo que todos os
outros artefatos serão gerados. Isto pode se tornar um problema quando a equipe de
desenvolvimento não detém o conhecimento sobre como realizar metamodelagem. É
necessário conhecer bem as tecnologias envolvidas (tais como EMF e GEF) assim como, ter
experiência sobre como realizar a captura de informações sobre a estrutura semântica e
sintática da linguagem alvo. Faz-se necessário que o metamodelo construído seja bem
definido para que não ocorram problemas nas próximas etapas automáticas do processo. Este
problema (criação manual do metamodelo) está relacionado com o tempo necessário para se
adquirir experiência com metamodelagem e/ou com o tempo necessário para capturar as
informações peculiares de uma linguagem e expressá-la em nível de metamodelo. Isto pode
impactar no tempo de desenvolvimento da aplicação.
Com um metamodelo bem definido, seguindo o processo, os artefatos ou modelos de
configuração podem ser gerados automaticamente utilizando os recursos disponíveis para
realização de transformações de modelos10. Ou seja, a partir do metamodelo, os modelos de
definição gráfica, modelos de definição ferramental e o modelo de mapeamento podem ser
10 Ato de utilizar um modelo de entrada para que resulte em outro modelo com especificações diferenciadas realizadas através das regras de transformação. O modelo resultante pode continuar no mesmo nível de abstração do modelo de entrada (denominada como transformações horizontais) bem como pode alterar no nível de abstração (denominada como transformações verticais) (KLEPPE et al., 2003).
92
gerados automaticamente. Entretanto algumas considerações devem ser ressaltadas sobre
essas gerações automáticas.
Não só uma boa definição estrutural de uma linguagem no metamodelo será o fator
principal para a geração correta dos modelos de configuração de um editor gráfico. Alguns
problemas podem acontecer dependendo do grau de complexidade que o metamodelo foi
construído. Por exemplo, o uso da estratégia enumeração não é suportada na geração
automática dos modelos de configuração do GMF. Isto pode se tornar um problema grave
quando existir a real necessidade de se utilizar esta estratégia, visto que os modelos não serão
gerados com o suporte necessário para que estejam de acordo com a estrutura do metamodelo.
Isto resulta em artefatos inconsistentes que deverão ser corrigidos manualmente e mais uma
vez pode surgir impactos no tempo de desenvolvimento da aplicação.
6.3 O PROCESSO DE CRIAÇÃO DE EDITORES GRÁFICOS COM A ABORDAGEM
AGILE
Na seção anterior, observou-se que problemas podem acontecer na geração automática
dos modelos de configuração (Metamodelo, Modelo Gráfico, Modelo Ferramental e o Modelo
de Mapeamento) pelo fato de as transformações de modelos não suportarem algumas
estratégias utilizadas na metamodelagem (e.g., enumeração). Uma vez que um metamodelo
seja construído utilizando estas estratégias (e.g., o metamodelo proposto no Capítulo 5), a
execução das transformações resultaram em modelos que não estarão em conformidade com a
estrutura do metamodelo. A solução é corrigir manualmente as lacunas impostas pelo
problema, entretanto, e é fato que esta não é uma tarefa simples de ser realizada. Visando
automatizar as atividades do processo de criação de editores gráficos para as linguagens
baseadas no i* com o GMF, além de aumentar a produtividade e diminuir os custos de
desenvolvimento, esta dissertação propõe a abordagem AGILE. Como pode ser observado na
Figura 6.4, as atividades de criação do modelo de domínio, modelo de definição gráfica,
modelo de definição ferramental e o modelo de mapeamento presentes na Figura 6.3 foram
excluídas do processo e três novas atividades semi-automatizadas foram inseridas: (i)
Configuração da base i*; (ii) Criação e Configuração de novos elementos de modelagem; e
(iii) Geração automática dos modelos GMF. Para automatizar o processo, foi desenvolvida
uma ferramenta denominada AGILE Tool (mais detalhes no Anexo A).
nas p
escol
abord
do i*
elem
Usan
conc
inclu
6.3.1
assim
suas
Capí
não
Figura 6
As ativid
próximas se
lha desta li
dagem, já q
* original.
mentos de m
ndo o i* A
eitos do i*,
uindo o trata
1 Configu
Um met
m, para cada
característi
tulo 5, entr
representa
6.4 – Process
dades do pr
eções, utiliz
inguagem s
que é uma li
De fato, a
modelagem d
spectual co
a criação,
amento de s
uração da b
tamodelo é
a linguagem
icas. Um m
retanto, o m
completam
o de criação
rocesso apr
zando um ex
se atribui à
inguagem q
Seção 4.6
de todos os
omo exemp
configuraçã
suas restriçõ
base i*
um artefat
m que for pr
metamodelo
mesmo ainda
mente as ca
de um editor
resentado n
xemplo de
à possibilida
que incluiu v
mostrou q
s tipos (com
lo de execu
ão e inserçã
ões.
to crucial p
roposta, pre
núcleo par
a não é util
aracterística
r gráfico utiliz
a Figura 6.
execução c
ade de exp
vários elem
que nesta li
mpartimento
ução, será
ão das pecul
para criação
ecisaremos
ra linguagen
lizável na c
as de uma
zando a abor
4 serão des
com a lingu
plorar várias
mentos à ling
inguagem f
os, elemento
possível de
liaridades d
o de um ed
de um meta
ns baseada
criação de u
linguagem.
rdagem AGIL
scritas deta
uagem i* A
s situações
guagem de m
foram inclu
os e relacio
emonstrar o
da linguagem
ditor gráfic
amodelo qu
no i* foi p
um editor g
. Sendo as
93
LE
lhadamente
spectual. A
de uso da
modelagem
uídos novos
onamentos).
o reuso dos
m desejada,
co e, sendo
ue defina as
proposto no
ráfico, pois
sim, faz-se
3
e
A
a
m
s
.
s
,
o
s
o
s
e
nece
carac
const
de um
se po
as pa
6.5).
itens
que s
autom
com
defin
mode
elem
mode
ssário aplic
cterísticas p
Mais um
truída basea
ma linguage
ossível expr
articularidad
Esta con
É possível
desejados.
sejam herda
mática. O re
os element
nida. É imp
elo de featu
mentos que s
elo de featu
Figu
ar a estratég
particulares
ma vez é p
ada no i* é
em para out
ressar os ele
des da lingu
nfiguração p
selecionar
Com esta s
ados pela su
esultado de
tos encontr
portante en
ures da lin
serão herdad
ures sendo r
ura 6.5 – Tela
gia de confi
da nova ling
possível pe
natural que
tra e por iss
ementos qu
uagem sejam
pode ser rea
os element
seleção, o de
ua linguagem
esta configu
ados na lin
nfatizar que
nguagem i*
dos do i* pa
ealizado.
a Principal d
iguração, ta
guagem e a
erceber na
e haja heran
so esta etapa
ue serão her
m inseridas.
alizada atrav
tos que serã
esenvolvedo
m e, então,
uração é um
nguagem i*
e esta tela
construído
ara uma nov
da AGILE To
ambém prop
assim realiza
Seção 4.7
nça de algun
a foi inclusa
rdados a par
vés da tela p
ão herdados
or informa
estes são in
m metamode
e herdado
principal (F
o anteriorme
va linguagem
ool para confi
posta no Cap
ar a criação
que quand
ns elemento
a no process
rtir do i* pa
principal da
da linguag
apenas quai
nseridos no
lo construíd
s pela lingu
Figura 6.5)
ente (Figur
m é justame
iguração de u
pítulo 5, par
do seu edit
ndo uma lin
os de model
so. Através
ara que post
a AGILE T
gem i* selec
is elemento
metamodel
do (Figura
uagem que
) é uma ab
ra 6.6). A s
ente a confi
uma base i*
94
ra inserir as
tor gráfico.
nguagem é
lagem do i*
dela torna-
teriormente
Tool (Figura
cionando os
s ele deseja
lo de forma
6.8) apenas
está sendo
bstração do
seleção dos
iguração do
4
s
é
*
-
e
a
s
a
a
s
o
o
s
o
featu
dos c
elem
depe
seleç
_Sof
contr
obrig
todas
softg
nenh
Através
ures, aprese
componente
mento selec
ndências e
ção dos com
ftgoal (Tabe
ribuição fo
gatoriament
s as ligaçõ
goal deverá
huma ligação
Figur
desta tela
ntada na Se
es de interf
cionado) o
entre os ele
mponentes
ela 4.18 da
or selecion
te e esta sel
es de contr
á ser desab
o de contrib
ra 6.6 – Mode
a ferramen
eção 3.2.2.
face (Check
o sistema
ementos se
de interfac
a Seção 4.7.
nada, o e
leção ocorre
ribuições e
bilitado, ou
buição estej
elo de feature
nta também
A escolha d
kbox). Para
trata auto
elecionados
ce. Utilizan
.1) como ex
elemento s
erá automat
estiverem de
u seja, um
a marcada (
e da linguagem
m insere as
dos elemen
a cada even
omaticamen
através da
do a restriç
xemplo, se
softgoal tam
ticamente (
esabilitadas
softgoal p
(Figura 6.7(
m i* original
restrições
tos é realiz
nto disparad
nte as pos
a habilitaçã
ção Requer
ao menos u
mbém dev
Figura 6.7(
s isto não i
pode ser h
(b)).
l
de depend
zada através
do (ou seja
ssíveis res
ão e desab
r Contribu
um tipo de
verá ser s
(a)). Por ou
implica diz
habilitado m
95
ência entre
s da seleção
, para cada
strições de
bilitação da
ution Link
e ligação de
selecionado
tro lado, se
zer que um
mesmo que
5
e
o
a
e
a
k
e
o
e
m
e
Send
Tool
(Figu
Figura 6.7
Como di
do assim, a p
l, a configu
ura 6.8):
Ator
6.8(
fora
Elem
fora
(Com
Elem
Enu
sobr
(e.g.
deve
elem
novo
– Exemplo d
ito anteriorm
partir das es
uração do m
res – com
a)) represen
m seleciona
mentos inte
m selecio
mpartment
mentMC (F
meration E
re as caract
., um objet
e ser seleci
mento possu
o elemento
de tratamento
mente, a lin
scolhas feita
metamodelo
mo descrito
nta os atore
ados e inser
encionais –
onados e
t) bem c
Figura 6.8(b
ElementMC
terísticas em
tivo ou goa
ionado prev
ui característ
de modela
o automático
nguagem i*
as através d
núcleo par
anteriorm
es da lingua
ridos no Enu
– todos os ti
podem s
omo no
b)). Desta f
CType. Se
m alguns d
al ser criado
viamente ne
ticas distint
agem. Esta
de restrições
Aspectual
da tela de co
ra a linguag
ente, a me
gem e, send
umeration C
ipos de elem
ser criado
Modelo (M
forma todos
existir a n
dos element
o apenas no
esta etapa d
tas do i* ori
regra se a
s de dependên
foi criada b
onfiguração
gem do i* A
etaclasse C
do assim, to
Compartme
mentos inten
s tanto n
Model) atr
os element
ecessidade
tos pré-defi
o Compart
do processo
iginal e dev
aplica a tod
ncia entre fea
baseada no
da ferrame
Aspectual r
Compartme
odos os tipo
entType.
ncionais do
nos Comp
ravés da
tos foram in
de realizar
inidos no m
tment), o m
o. Isto sign
ve ser tratad
dos os elem
96
atures
i* original.
enta AGILE
resultou em
ent (Figura
os de atores
o i* original
partimentos
metaclasse
nseridos no
r mudanças
metamodelo
mesmo não
nifica que o
do como um
mentos pré-
6
.
E
m
a
s
l
s
e
o
s
o
o
o
m
-
defin
do p
Figur
Rela
meta
parti
meta
deno
pelo
varie
utili
está
relac
gene
sour
nidos no m
processo (Se
ra 6.8 – Meta
acionament
aclasse dev
iculares. Se
aclasse deno
ominado typ
o fato de q
edade utili
zada apena
composta
cionamento
eralização c
rce (elemen
metamodelo
eção 6.3.2).
amodelo base
to de dep
ve ser criad
endo assim
ominada De
pe do tipo
que existem
zando um
s dentro de
a na meta
o, a meta
com a meta
nto de onde
e o tratame
e utilizado pel
pendência
da para que
m, para inse
ependencyL
DepLinkT
m vários tip
Enumerat
um modelo
aclasse Mo
aclasse De
aclasse Rela
e a ligação
ento para cr
la linguagem
– para in
e possamos
rir a ligaçã
Link (Figu
Type, que é
pos de depe
ion. A lig
o e, por isso
odel. Além
ependencyL
ationship. T
parte ou te
riação acon
i* Aspectual
nserir um
s representa
ão de depen
ra 6.8(c)), q
é um Enum
endência e,
gação de d
o, a metacla
m disto, p
Link possu
Todo relaci
em início) e
ntece na etap
l (i* original)
relacionam
ar suas car
ndência, cr
que possui u
meration. Ist
, assim, tra
dependência
asse Depen
por ser um
ui uma l
ionamento
e um target
97
pa seguinte
mento, uma
racterísticas
riamos uma
um atributo
to acontece
atamos esta
a pode ser
dencyLink
m tipo de
ligação de
contém um
t (elemento
7
e
a
s
a
o
e
a
r
k
e
e
m
o
98
para onde a ligação chega como destino). No caso da ligação de dependência, um
source e um target podem ser tanto um dos tipos de atores (metaclasse
Compartment) como um dos tipos de elementos intencionais (metaclasse
ElementMC). Diante disto, as ligações que representam o source e target de uma
ligação de dependência estão associadas à metaclasse NodeObject (que é a
generalização das metaclasses Compartment e ElementMC, conforme visto na
seção 5.1). O uso desta estratégia abre possibilidade de uso incorreto da ligação de
dependência e por isso a mesma deve ser restringida através de regras OCL. O
tratamento sobre este problema será descrito mais adiante desta Seção.
Relacionamento de atores – ao se selecionar este relacionamento, será criada
uma metaclasse denominada ActorLink (Figura 6.8(d)), que especializa a
metaclasse Relationship. ActorLink está composta na metaclasse Model, visto
que sua utilização é feita apenas entre elementos contidos no modelo. A
metaclasse possui um atributo type do tipo ActorLinkType, para representar os
tipos de relacionamentos existentes entre atores. Entretanto, as ligações que
representam o source e o target de uma ligação de atores estão associadas à
metaclasse Compartment, já que este tipo de relacionamento só acontece entre
atores.
Relacionamento de contribuição – a mesma regra aplicada no relacionamento de
dependência e no relacionamento de atores também se aplica ao relacionamento
de contribuição. Ao selecionar-se pelo menos um tipo ligação de contribuição,
será criada uma metaclasse denominada ContributionLink (Figura 6.8(e)) que
especializa a metaclasse Relationship. ContributionLink possui um atributo
type do tipo ContribType, para representar os tipos selecionados de contribuições
existentes. Sua composição acontece na metaclasse Compartment, já que uma
contribuição só pode ser usada dentro dos limites de um ator. As ligações que
representam o source e o target de uma ligação de contribuição estão associadas à
metaclasse IntentionalElement, que a ligação de contribuição só relaciona
elementos intencionais. O uso desta estratégia abre possibilidade de uso incorreto
da ligação de contribuição e por isso a mesma deve ser restringida através de
regras OCL. O tratamento sobre este problema será descrito mais adiante desta
Seção.
99
Relacionamento Means-End e Task-Decomposition – Para cada um destes
relacionamentos foi criada uma metaclasse distinta: MeansEndLink e
TaskDecompositionLink (Figura 6.8(f)). Visto que nenhuma destas ligações
possui algum tipo especialização, não existiu a necessidade da criação de
atributos. Ambas são compostas na metaclasse Compartment por se
relacionarem apenas com elementos intencionais contidos nos limites dos atores.
Estas metaclasses especializam Relationship e os seus respectivos sources e
targets estão diretamente ligados à metaclasse IntentionalElement, visto que são
relacionamentos entre elementos intencionais. O uso desta estratégia abre
possibilidade de uso incorreto destas ligações e por isso a mesma deve ser
restringida através de regras OCL. O tratamento sobre este problema será descrito
mais adiante desta Seção.
Este metamodelo ainda não está completo. Ainda é necessário definir as restrições
discutidas anteriormente. Por exemplo, o metamodelo define que uma ligação de dependência
(Dependency Link) pode ter qualquer nó da linguagem (atores ou elementos intencionais)
como sendo seu source ou target (associações entre DependencyLink e NodeObject). A
linguagem i* define que ligações de dependência podem acontecer (Figura 6.9(a)): (i) de
atores para elementos intencionais; (ii) de elementos intencionais para atores; (iii) e de
elementos intencionais para elementos intencionais. O metamodelo apresentado na Figura 6.8
permite a criação de uma ligação de dependência entre atores (Figura 6.9(b)) e entre
elementos intencionais que fazem parte da dependência entre atores (Figura 6.9(c)). Estas
situações não devem ser permitidas e devem ser tratadas através das restrições. Para isto será
utilizada a linguagem definição de restrições denominada OCL (Object Constraint Language)
(OMG, 2010b). OCL é uma linguagem formal usada para descrever as expressões de
especificação de restrições sobre modelos. Com ela é possível descrever regras que não estão
representadas no metamodelo a fim de aumentar a consistência da representação semântica de
sintática em um determinado modelo.
las a
Assim
lingu
apren
no m
bene
apen
acaba
as re
abord
restri
acord
possí
Como di
através do
m, optou-se
uagem OCL
ndizado par
metamodelo
Além de
fício: visto
nas nas rest
a por herda
strições da
Diante
dagem tamb
ições. Send
do com as
ível definir
Figura 6.9
iscutido ant
metamodel
e por omitir
L para rep
ra o uso da a
serão repre
e diminuir a
que as dife
trições, com
ar elementos
linguagem
da necessi
bém poderi
o assim, a A
configuraçõ
as restriçõe
9 – Ligações d
teriormente,
lo iria aum
as restriçõe
presentá-las.
abordagem
sentadas em
a complexid
erenças entr
m a não inc
s ou da ling
escolhida p
dade de i
ia permitir a
AGILE Too
ões do dese
es para os re
de dependênc
, existem vá
mentar cons
es mais críti
. Esta deci
AGILE. As
m regras OC
dade do met
re as lingua
clusão de a
guagem i* o
para ser herd
incluir rest
a geração a
ol provê sup
envolvedor
elacionamen
cia que o met
árias restriç
sideravelme
icas da lingu
isão, por o
s restrições
CL associad
tamodelo, e
gens i* orig
algumas de
original ou
dada sejam
trições ao
automática d
porte a geraç
. Ainda na
ntos present
tamodelo per
ções na ling
nte a comp
uagem no m
outro lado,
que poderia
das ao metam
sta decisão
ginal e i* W
estas, o me
da linguage
incluídas.
metamodel
de código O
ção automát
tela princip
tes na lingu
rmite
guagem i* e
mplexidade d
metamodelo
aumenta a
am estar rep
modelo.
também of
Wiki são car
etamodelo c
em i* Wiki
lo, decidiu
OCL para d
tica de códi
pal da AGI
uagem. Atra
100
e apresentá-
do mesmo.
o e utilizar a
a curva de
presentadas
ferece outro
racterizadas
configurado
, desde que
u-se que a
definição de
igo OCL de
ILE Tool é
avés de uma
0
-
.
a
e
s
o
s
o
e
a
e
e
é
a
interf
relac
usuár
na Fi
restri
possa
targe
OCL
depe
inten
face gráfica
cionamento
rio tem livr
igura 6.10,
ições. Inicia
a seleciona
ets e à medi
L é gerado a
Figura 6.1
O exemp
ndência, em
ncionais (Fi
a o desenvo
e o código
re acesso pa
é possível
almente o d
ar seus pos
ida que os p
automaticam
10 – Tela de c
plo a seguir
m que cada
gura 6.10(a
olvedor será
o OCL cor
ara realizar
visualizar u
desenvolved
síveis alvo
pares de rest
mente.
configuração
r mostra os
um dos tip
a)), todos o
á capaz de s
rrespondent
alterações s
um exempl
dor deve se
s (target),
trições são
de restrições
s possíveis r
pos de atore
os tipos de e
selecionar o
te será gera
se existir a
o de config
elecionar um
ou seja, ca
adicionados
s e geração au
relacioname
es se relacio
elementos i
s possíveis
ado automa
necessidade
guração e g
ma fonte (s
ada source
s (através do
utomática de
entos de ele
ona com tod
intencionais
source e ta
aticamente,
de (Figura 6
geração auto
source) para
poderá ter
do botão Ad
e código OCL
ementos da
dos os tipos
s se relacio
101
arget de um
contudo o
.10). Ainda
omática das
a que então
r diferentes
d) o código
L
a ligação de
s elementos
onando com
m
o
a
s
o
s
o
e
s
m
102
todos os tipos de atores (Figura 6.10(b)) e com todos os tipos de elementos intencionais
(Figura 6.10(c)), de acordo com as regras descritas anteriormente (Figura 6.9). As caixas de
texto Source Constraint e Target Constraint armazenam os sources e targets selecionados
em formato OCL e a caixa de texto Constraint armazena o código OCL que representa as
configurações em nível de interface realizadas anteriormente. Ambos os códigos de texto são
gerados automaticamente quando o usuário adiciona novos pares de source de target.
É possível perceber no exemplo presente na Figura 6.10 e Tabela 6.1 que os códigos
gerados não obedecem estritamente as expressões OCL tais como deveriam ser. As
expressões OCL obedecem a uma estrutura de expressões declarativas geralmente
introduzidas pela palavra context, que introduz o contexto da expressão seguida do estereótipo
da restrição, podendo estes ser do tipo invariante (invariant), pré-condição (precondition) e
pós-condição (poscondition) e só depois a expressão em si é descrita (Tabela 6.2). Isto
acontece porque o próprio modelo de mapeamento do GMF define automaticamente o seu
contexto e seu estereótipo. Neste caso, não se faz necessário o uso de expressões completas.
Assim, as expressões são montadas apenas utilizando a palavra-chave self, como forma de
capturar o contexto utilizado (Tabela 6.1).
Tabela 6.1 – Exemplo de código OCL usado no GMF
if self.source.oclAsType(Compartment).type= CompartmentType::ACTOR then
self.target.oclAsType(ElementMC).type= ElementMCType::GOAL
or self.target.oclAsType(ElementMC).type= ElementMCType::TASK
or self.target.oclAsType(ElementMC).type= ElementMCType::RESOURCE
or self.target.oclAsType(ElementMC).type= ElementMCType::SOFTGOAL
else
if self.source.oclAsType(Compartment).type= CompartmentType::AGENT then
self.target.oclAsType(ElementMC).type= ElementMCType::GOAL
or self.target.oclAsType(ElementMC).type= ElementMCType::TASK
or self.target.oclAsType(ElementMC).type= ElementMCType::RESOURCE
or self.target.oclAsType(ElementMC).type= ElementMCType::SOFTGOAL
else
…
endif
…
Endif
103
Tabela 6.2 – Estrutura do código OCL context TypeName inv:
'expressão OCL com estereótipos no contexto de TypeName'
Finalizando a configuração da base i*, ou seja, a configuração dos elementos que
serão reusados, a próxima etapa do processo é a criação e configuração dos novos elementos
de modelagem. Será esta etapa onde a configuração e inserção das características específicas
das linguagens será contemplada. Esta atividade será detalhada na próxima seção.
6.3.2 Criação e configuração dos novos elementos de modelagem
A próxima atividade do processo (Figura 6.4) é a criação e configuração dos novos
elementos de modelagem da linguagem que está sendo definida. Esta etapa possibilita definir
as características mais importantes de um novo elemento de modelagem, tais como: onde o
elemento será composto, sua classificação, seus atributos (se possuir), dentre outras. Cada
novo elemento criado e configurado será incluído no metamodelo. Para isto faz-se necessário
que uma base i* esteja configurada, conforme apresentado na seção anterior. Na Seção 4.7.1
foi apresentado o modelo de features para configuração de uma base i* e neste, existe uma
feature responsável pela criação e configuração de um novo elemento de modelagem (New
Modeling Element). Esta feature está representada por outro modelo de feature (Figura
6.11).
Este modelo de features expressa como uma nova característica deve ser inserida para
definir uma nova linguagem. Um novo elemento de modelagem deve obrigatoriamente conter
informações sobre onde será composto (Composition) e qual a sua classificação
(Classification). Opcionalmente, um novo elemento de modelagem poderá possuir atributos
(Attribute).
nos
apen
ou R
(Com
elem
elem
e, ob
cardi
escol
Tamb
possí
disso
O at
Elem
com
possí
mode
anter
Figura 6
A compo
compartime
nas uma clas
Relationship
mpartment
mento intenc
mento de mo
brigatoriam
inalidade (C
lher uma o
bém se dev
íveis sub-fe
o, é possível
tributo pod
ments).
A criaçã
a base i*
ível de ser
elagem (Fig
riormente (F
6.11 – Modelo
osição do n
entos (Com
ssificação e
p. No caso d
t e Non Co
cional, a fea
odelagem se
mente, deve
Cardinality
ou mais d
ve escolher
eature de C
l adicionar
de ser simp
ão de um no
configurad
realizada a
gura 6.12(a)
Figura 6.11
o de feature p
novo elemen
mpartment)
e, desta form
de um Com
ompartmen
ature Elem
er um relaci
-se definir
y) do relacio
e suas sub
r a cardinal
Cardinality
quantos atri
ples (Simp
ovo elemen
da também
través da te
)). Esta tela
1). Depende
para configur
nto pode ac
) ou em am
ma, deve-se
mpartment,
nt). Se o n
ment deve s
ionamento,
os elemen
onamento. C
bfeatures (C
lidade sobre
y (0..1, 0..*
ibutos (Attr
ple Attribu
nto de mod
é suportad
ela de criaç
a atende exa
endo da sel
ação de um n
contecer ap
mbos. Um
e escolher en
uma das su
novo elemen
ser selecion
a feature R
ntos fonte
Como elem
Compartm
e a criação
*, 1..* ou 1
ribute) fore
ute) ou um
elagem e a
da pela AG
ção e config
atamente ao
leção da cla
novo elemento
enas no mo
elemento d
ntre um Co
uas subfeatu
nto de mod
nada. E, por
Relationship
(Source)
entos Sourc
ment, Elem
de uma lig
1..1) deve s
em necessár
ma lista de
sua compo
GILE Tool.
guração de
o modelo de
assificação
o de modelag
odelo (Mod
de modelag
ompartmen
ures deve se
delagem fo
or fim, no c
p deve ser s
e alvo (Ta
ce e Target
ment e Rel
gação. Um
ser selecion
rios ao novo
e elemento
osição no m
. Esta conf
um novo e
e features a
do novo e
104
gem
del), apenas
gem possui
nt, Element
er escolhida
or um novo
caso de um
selecionada
arget) e a
t é possível
lationship).
a dentre as
nada. Além
o elemento.
os (List of
metamodelo
figuração é
elemento de
apresentado
lemento de
4
s
i
t
a
o
m
a
a
l
.
s
m
.
f
o
é
e
o
e
mode
exem
habil
Elem
realiz
espec
etc)
confi
para
confi
apres
ator
relac
atrav
(Figu
elagem, alg
mplo, se a
litado para
ment ou C
zadas. Nest
cíficos pode
bem como
figuração de
Na seção
a posterior
figuração d
sentou deta
aspectual;
cionamentos
vés da AGI
ura 6.13).
guns dos c
classificaçã
que seja po
Compartme
ta tela tam
endo estes s
o, atributos
e enumeraçõ
Figura 6.12 –
o anterior,
r definição
dos elemen
alhadamente
; (ii) os
s transversa
ILE Tool p
componente
ão do tipo
ossível a co
ent for sel
mbém é pos
ser de um d
s que sejam
ões através d
– Tela de con
o metamod
da linguag
tos de mo
e as caracte
interesses
ais. Cada um
ara se obte
es da inter
Link for
onfiguração
lecionada c
ssível reali
dos tipos trad
m enumera
de uma jane
nfiguração do
delo núcleo
gem i* Asp
odelagem d
erísticas na
transversa
ma destas c
er o metam
rface são
selecionad
da nova li
configuraçã
izar a criaç
dicionais (S
ações. Nest
ela de apoio
os novos elem
o foi config
pectual. Es
desta lingu
linguagem
ais (Cross
característic
modelo comp
habilitados
da, o quadr
gação. Se a
o específic
ção de elem
String, Integ
te caso, tam
o (Figura 6.1
entos de mod
urado com
ta seção va
uagem espe
i* Aspectu
scutting co
cas deve ser
pleto da lin
e desabili
ro Configu
a classificaç
cas não pr
mentos com
ger, Double
mbém é s
12(b)).
delagem
a base do
ai ilustrar a
ecífica. A
ual, que inc
oncerns); e
r criada e c
nguagem i*
105
itados. Por
ure Link é
ção do tipo
recisam ser
m atributos
e, Boolean e
uportado a
i* original
a criação e
Seção 4.6
cluem: (i) o
e (iii) os
configurada
* Aspectual
5
r
é
o
r
s
e
a
l
e
6
o
s
a
l
descr
Figura 6
A compo
rita a seguir
Asp
de m
com
sem
mod
com
meta
enum
com
relac
restr
6.13 – Metam
osição de c
r:
pectual Act
modelagem
mpartimento
elhante aos
delagem d
mpartimento
amodelo, d
maration C
mpartimento
cionamento
rições é imp
modelo do i* A
cada um de
or– este ele
m em seu
ou contêin
atores da li
enominado
(Figura 6
de acordo c
Compartme
s. Inserido
os e restriçõ
portante res
Aspectual ger
stes novos
emento é ca
interior, ou
ner, o qual
inguagem i*
Aspectua
6.13(a)). D
com a abor
entType, u
neste, ele
ões) atrelad
ssaltar que n
rado automa
elementos
apaz de rec
u seja, ele
l é capaz
*. A partir d
al Actor
Desta form
rdagem AG
utilizado p
herdará to
das a metac
na linguagem
ticamente pel
de modelag
ceber variad
possui a
de receber
desta caract
foi criado
ma, para s
GILE, o m
ara especif
odas as car
classe Com
m i* Aspec
ela AGILE To
gem no me
dos tipos de
característ
elementos
terística, o e
do como
sua represe
mesmo foi i
ficação do
racterísticas
mpartment.
ctual os ator
106
ool
etamodelo é
e elementos
ica de um
, de forma
elemento de
sendo um
entação no
inserido no
s tipos de
(atributos,
Quanto as
r aspectuais
6
é
s
m
a
e
m
o
o
e
,
s
s
F
não
(Fig
quai
sour
Nod
para
poss
send
mod
ligaç
satis
relac
pode
aspe
Figura 6.14 –
Cro
Cros
apen
tipos
impo
podem ser
gura 6.13) d
isquer tipos
rce e targ
deObject. A
a que não pe
sível observ
do um com
delo (Mode
ção de dep
sfazer a res
cionados a
eriam foram
ectual não p
– Criando o a
osscutting C
sscutting C
nas no inte
s são: Obje
ortante ress
interligados
descreve qu
s de compar
get que ac
Assim, deve
ermita relac
var a criação
mpartimento
el). Logo ap
pendência (
strição desc
uma ligaçã
m excluídos
poderá existi
ator aspectual
Concerns –
Concerns) s
rior de um
etivos (Goal
saltar que es
s através de
ue uma lig
rtimentos e
contece en
em existir r
cionamento
o do ator as
o (Compar
após é reali
(essa defini
crita anteri
ão de depe
da seleção
ir em uma l
l da linguage
– os elemen
são element
m compartim
l), Tarefas
stes novos
e uma ligaçã
gação de de
elementos
tre as me
estrições at
s com os at
spectual. Su
rtment) e s
izada a con
ição ocorre
iormente os
endência fo
como o cas
ligação de d
em i* Aspectu
ntos denomi
tos de mod
mento (Asp
(Task), Rec
elementos f
ão de depen
ependência
intencionai
etaclasses D
treladas a li
tores aspect
ua classifica
sua compos
nfiguração
através da
s elementos
oram selecio
so do ator a
dependência
ual e configur
inados inter
delagem qu
ectual Acto
cursos (Reso
foram criad
ndência. O m
pode acon
is através d
Dependenc
igação de d
tuais. Na Fi
ação foi mar
sição acont
das restriç
a tela princ
s que pode
onados, e o
aspectual. A
a.
rando suas re
resses trans
ue podem
or). Os seu
ources) e S
dos a fim de
107
metamodelo
ntecer entre
das ligações
cyLink e
dependência
gura 6.14 é
rcada como
tecendo no
ções para a
cipal). Para
eriam estar
os que não
Assim o ator
estrições
sversais (ou
ser criados
us possíveis
Softgoals. É
e facilitar a
7
o
e
s
e
a
é
o
o
a
a
r
o
r
u
s
s
É
a
108
definição das restrições do i* Aspectual. Portanto, há a necessidade de se criar
uma metaclasse específica para representá-los no metamodelo, visto que tanto o
metamodelo núcleo como o metamodelo configurado com a base i* representam
apenas os elementos que podem estar contidos tanto no compartimento como no
modelo. Sendo assim, uma nova metaclasse será criada para representar os
elementos que devem ser criados apenas nos compartimentos (especificamente no
ElementCompartment) (vide Seção 5.1 para mais detalhes). A metaclasse
ElementCompartment possui um atributo do tipo type que representa um
enumaration (ElementCompartmentType). Este enumaration irá conter todos os
tipos de elementos que poderão ser criados apenas em compartimentos. A partir
disto, os elementos considerados interesses transversais na abordagem i*
Aspectual foram inseridos neste enumeration e, assim, representados no
metamodelo. Quanto às restrições, na linguagem i* Aspectual os elementos
transversais só podem existir dentro de um ator aspectual e sendo assim faz-se
necessário configurar a restrição para que isto aconteça. Na Figura 6.15 é possível
observar a criação de um interesse transversal tendo como classificação um
elemento (Element) e sendo composto apenas nos compartimentos
(Compartment). Na tela de restrições (Goal Constraint) é configurado os
compartimentos onde este elemento poderá existir.
Fi
Cro
relac
(Cro
meta
igura 6.15 – C
osscutting R
cionamento
osscutting
amodelo ser
o Cros
Cros
Task
como
ator
aspec
mode
abord
relac
comp
relac
meta
pode
sourc
Criando os C
Relationshi
os, todas
Relations
rá descrita a
sscuttingM
sscutting M
k Decompo
o sources um
aspectual e
ctuais e ele
elo SD qu
dagem AG
cionamentos
postas na
cionamentos
aclasse Rel
em se relac
ce e targe
Crosscutting co
ip – a lin
as especi
ship). A r
a seguir:
ME e Cro
Means-End
osition) (Fi
um interesse
e pode ter
ementos do
uanto o Mo
GILE, criou
s (Crosscut
metaclass
s, cada me
lationship.
cionar quai
et acontece
oncerns da lin
nguagem i*
alizações
representaç
osscuttingT
d) e o Cro
igura 6.13(c
e transversal
como targ
s demais at
odelo SR).
-se uma m
ttingME e
se Compa
etaclasse c
Os dois ti
isquer node
na metac
nguagem i* A
Aspectual
do relacio
ão destes
TD – C
osscuttingT
c)) são rela
l (ElementC
get interesse
tores (satisf
Desta form
metaclasse p
Crosscuttin
artment. P
criada é um
ipos de rel
e ou nó d
lasse Node
Aspectual
l define vá
onamento
relacionam
Crosscuttin
TD (ou Cr
acionamento
Compartm
es transver
fazendo ass
ma, de aco
para cada u
ngTD) e am
Por serem
ma especia
lacionamen
da linguage
eObject). A
109
ários novos
transversal
mentos no
ngME (ou
rosscutting
os que tem
ment) ou um
sais, atores
sim tanto o
ordo com a
uma destes
mbas foram
tipos de
alização da
tos criados
m (ligação
Através da
9
s
l
o
u
g
m
m
s
o
a
s
m
e
a
s
o
a
defin
estas
deste
Cros
comp
cardi
Logo
botão
abert
entre
Figura 6.16
o
(Figu
dentr
para
(Cro
segu
Cros
contr
estar
nição das re
s ligações po
es relacio
sscuttingM
posta apen
inalidade m
o após é re
o Constrain
ta para sele
e os element
6 – Criando o
Crosscut
ura 6.13(d)
ro de um a
represen
osscuttingC
indo as me
sscutingTD
ribuição (H
r contempla
estrições é
odem se rel
onamentos
ME é classi
nas nos
múltipla, e s
ealizada a
nts New Re
eção das re
tos.
o crosscutting
tting Cont
)) também
ator aspectu
ntação de
Contributio
esmas razõe
D. Esta liga
Help, Hurt,
ados no me
possível de
lacionar. A
utilizando
ficada com
compartim
eus sources
configuraçã
elationship.
spectivas p
gME e definin
tribution –
é um rela
ual. Desta f
e cada
on) e compo
es usadas n
ação possu
, Break, M
etamodelo.
efinir quais
Figura 6.16
o a ferra
mo sendo u
mentos (Co
s e targets
ão de suas
Com isso
possibilidade
ndo suas rest
– o Crossc
cionamento
forma, uma
especializa
osta na meta
na criação
ui alguns ti
Make e etc)
Para isto f
são os elem
6 exemplific
amenta. A
uma ligação
ompartmen
são apenas
restrições
uma nova
es de relac
trições
cutting Co
o que só p
metaclasse
ação desta
aclasse Com
do Crosscu
ipos difere
) que tamb
foi criado u
110
mentos que
ca a criação
A ligação
o (Link), é
nt), possui
elementos.
através do
janela será
ionamentos
ontribution
pode existir
e foi criada
a ligação
mpartment
utingME e
nciados de
bém devem
um atributo
0
e
o
o
é
i
.
o
á
s
n
r
a
o
t
e
e
m
o
F
6.3.3
na ge
proje
descr
confi
base
Figura 6.17 –
3 Geração
Esta é a
eração auto
eto de criaç
reva a sin
figuração (*
i* e novos
type
Cont
relac
como
comp
sourc
confi
Rela
respe
– Criando os r
o automátic
última etap
omática dos
ção de um e
ntaxe da li
*.gmfgraph,
elementos f
que repr
tributionTy
cionamento.
o sendo
partimentos
ces e targ
figuração d
tionship. C
ectivas poss
relacionamen
ca dos mod
pa de config
modelos de
editor gráfic
inguagem p
*.gmftool,
foram inclu
resenta um
ype. A F
. A ligação
uma liga
s (Compartm
gets são ap
de suas res
Com isso um
sibilidades d
ntos transver
delos de con
guração do
e configura
co que utiliz
para que s
, *.gmfmap
uídos nas du
m enumera
Figura 6.17
o Crosscut
ação (Link
ment), poss
penas eleme
trições atra
ma nova jan
de relaciona
sais do i* asp
nfiguração
processo d
ação GMF. D
ze o GMF
seja possív
p). Este me
uas etapas an
tion denom
7 exemplif
ttingContri
k), é com
sui cardinal
entos. Logo
avés do bo
nela será ab
amentos ent
pectual e defin
do GMF
da abordagem
De acordo c
necessita de
vel a geraç
tamodelo f
nteriores.
minado Cr
fica a cria
ibution é c
mposta ap
lidade múlti
o após é r
otão Constr
berta para s
tre os eleme
nindo suas re
m AGILE.
com a Seçã
e um metam
ção dos m
foi configur
111
rosscutting
ação deste
classificada
penas nos
ipla, e seus
realizada a
raints New
seleção das
entos.
estrições
Resume-se
ão 6.2, todo
modelo que
modelos de
rado com a
g
e
a
s
s
a
w
s
e
o
e
e
a
é ver
confi
exem
tecno
propó
de m
sendo
lingu
elem
(,gm
a for
atual
comp
versõ
gerad
Depo
fram
Mesmo c
rdade que n
figurações d
mplo, defini
ologia, tal c
Visto qu
ósito gerar
modelagem
o realizadas
É import
uagem i* é s
mento de m
fgraph) é ge
rma gráfica
l da ferram
plexidade. E
ões da ferram
Com a fi
dos com ap
ois disto, o
ework GMF
Figura 6
com um me
no uso da tec
de projeto
ição das re
omo, o map
ue alterações
automatica
vão sendo
s nos respec
tante ressal
suportada p
modelagem
erada autom
a do elemen
menta por u
Esta uma lim
menta.
inalização d
penas um cli
o processo
F até que o
6.18 – Process
etamodelo b
cnologia GM
devem ser
estrições, c
peamos dos
s manuais n
mente a con
incluídas p
ctivos mode
ltar que a f
ela AGILE
é criado
maticamente
nto manualm
ultrapassar o
mitação ide
da definição
ique no bot
(Figura 6.1
editor gráfi
so de criação
bem definid
MF para o d
r realizadas
configuraçõ
modelos e
não são tare
nfiguração
para a criaç
elos que são
forma gráfic
Tool e gera
toda sua e
e. Contudo,
mente. Esta
os limites
entificada n
o do metam
tão Create F
16) segue
ico seja gera
o de um editor
do e toda a e
desenvolvim
s manualme
es de algu
etc).
efas triviais,
destes mod
ção do meta
o gerados au
ca dos elem
ada automa
estrutura n
neste caso
a funcional
do escopo
a abordagem
odelo, enfim
Files da int
adiante com
ado (Figura
r gráfico utili
estrutura qu
mento de ed
ente pelos
umas particu
esta etapa
delos. À me
amodelo, su
utomaticame
mentos de m
ticamente, e
no modelo
específico,
idade não f
do trabalh
m que será
m os model
terface apre
m as confi
6.18).
izando a abor
ue o GMF p
ditores gráfi
desenvolve
cularidades
do processo
edida que os
uas configu
ente
modelagem
entretanto,
de definiç
o usuário t
foi inserida
ho devido a
incluída na
los do GMF
esentada na
igurações re
rdagem AGI
112
roporciona,
icos, muitas
edores (por
da própria
o tem como
s elementos
urações vão
básicos da
se um novo
ção gráfica
terá de criar
a na versão
ao nível de
as próximas
F podem ser
Figura 6.5.
estantes do
LE
2
,
s
r
a
o
s
o
a
o
a
r
o
e
s
r
.
o
refer
nível
elem
novo
Eclip
mode
Figu
É criado
rentes ao me
l de código
mentos de mo
Após a g
os elemento
pse (Figura
elagem (Fig
ura 6.19 – At
o modelo g
etamodelo s
(Figura 6.1
odelagem d
geração do
s de modela
6.19(b)). C
gura 20).
tividade comp
gerador (Cr
sejam gerad
19(a)). Apó
deve ser real
código fon
agem a últim
Com o plug
plementares p
riação do m
dos, ou seja
ós esta ativid
lizada utiliz
nte referent
ma atividad
g-in gerado
para geração
modelo ger
a, representa
dade a defin
zando os me
te ao metam
de a ser real
é possível
o do código fo
rador) para
am a estrutu
nição da for
ecanismos o
modelo e a
lizada é cria
enfim utili
onte referente
que os cód
ura do meta
rma gráfica
oferecidos p
definição
ação do plu
izar a ferra
es ao editor g
113
digos fontes
amodelo em
a dos novos
pelo GMF.
gráfica dos
ug-in para o
amenta para
gráfico alvo
3
s
m
s
s
o
a
6.4
contr
inicia
integ
apres
do pr
com
abord
aos p
6.3)
atrav
realiz
CONSIDE
O foco p
ribuição pr
almente fo
grada na ab
sentadas sua
rocesso de c
Fundame
o GMF, foi
dagem AGI
problemas e
era gerado
vés da confi
zada autom
Figu
ERAÇÕES
principal de
rincipal des
i apresenta
bordagem p
as caracterí
criação de u
entado nos
i proposto o
ILE. A abor
encontrados
o manualme
guração do
maticamente;
ra 6.20 – Edi
FINAIS
este capítulo
ste trabalho
ada detalhe
para a ger
sticas princ
um plug-in d
problemas
o novo proc
rdagem em
s, tais como
ente, com
usuário; de
; e a geração
itor gráfico d
o foi a apre
o. Para qu
s sobre a
ração das f
cipais bem c
de modelag
encontrado
cesso destin
si visa o m
o: a atividad
a abordage
efinição das
o automátic
do i* Aspectua
sentação da
ue fosse p
tecnologia
ferramentas
como os pro
gem para o E
s no proces
nado a lingu
melhoramen
de de criaçã
em este mo
característi
ca das restri
al finalizado
a abordagem
possível ent
GMF. O
de model
oblemas enc
Eclipse utili
so de criaçã
agens i* sen
to do proce
ão do mode
odelo é ger
icas de com
ções dos rel
m AGILE s
ntende-la co
GMF é a
lagem gráf
contrados n
izando a tec
ão de editor
ndo este o p
esso do GM
elo de domí
rado autom
mpartimento
lacionamen
114
endo esta a
orretamente
tecnologia
fica. Foram
na execução
cnologia.
res gráficos
processo da
MF referente
nio (Figura
maticamente
s também é
ntos.
4
a
e
a
m
o
s
a
e
a
e
é
115
Para prover estas automações foi desenvolvida uma ferramenta de apoio denominada
AGILE Tool. Esta ferramenta auxilia o usuário a idealizar a estrutura da nova linguagem
através de simples funcionalidades utilizando apenas a interface gráfica reduzindo
consideravelmente a intervenção manual e direta na estrutura do GMF.
Para demonstrar a utilização da abordagem foi utilizada como estudo de caso a
linguagem i* Aspectual. Através dela foi possível mostrar a capacidade da ferramenta bem
como da abordagem na geração automática da estrutura de uma linguagem além da geração
do seu suporte ferramental.
CONCLUSÕES E TRABA
Neste
objet
ALHOS FUTUROS
e capítulo s
tivamente a
será feito u
as principais
um sumário
s contribuiçõ
do trabalho
ões deste tr
o realizado
abalho e os
. Em seguid
trabalhos fu
da, serão ap
futuros.
116
presentadas
6
s
117
Mesmo com um grande número de linguagens baseadas em i* existentes, acredita-se
que novas linguagens baseadas no i* surgirão ao longo dos próximos anos para atender às
necessidades específicas tanto dos grupos de pesquisas dedicados à área de Engenharia de
Requisitos Orientada a Objetivos como também, futuramente, da indústria.
As várias linguagens baseadas no i* existentes acarretam em dois problemas críticos
que devem ser levados em consideração, sendo estes:
1. O surgimento de novos dialetos pode elevar não só a inibição para adoção do i*
por parte de novos usuários devido a grande variação de linguagens que pode
levar à incompatibilidade semântica entre os escritores e leitores dos modelos i*
(LUCENA et al., 2008);
2. Há uma divisão do esforço para o desenvolvimento de ferramentas de apoio a
cada um dos dialetos do i* existentes, visto que cada grupo de pesquisa se
concentrará no desenvolvimento de seu suporte ferramental para o seu próprio
dialeto. Inclusive, utilizado plataformas e tecnologias diferentes de outros grupos
de pesquisa. Esta divisão de esforço e a diferença entre as plataformas utilizadas
acarreta alto custo de desenvolvimento para a comunidade do i*, além da falta de
interoperabilidade entre as ferramentas construídas pelos vários grupos de
pesquisa presentes na comunidade.
Sendo assim, o foco principal desta dissertação aponta para o problema relacionado ao
esforço que deve ser empenhado para o desenvolvimento de ferramentas de apoio a
modelagem. A idéia principal é reduzir a divisão deste esforço a fim de minimizar o alto custo
de desenvolvimento empregado em cada uma dos distintos projetos. A geração de linguagens
propriamente dita esta relacionado a definição estrutural da linguagem para a geração da
ferramenta.
Para isto, primeiramente foi discutido o estado da arte das duas principais subáreas
envolvidas neste trabalho: a Engenharia de Requisitos Orientada a Objetivos com destaque
para o framework i* e a Engenharia de Linhas de Produto de Software por acreditarmos desde
o início que, com a utilização deste paradigma, seria possível atingir o objetivo deste trabalho.
Assim, os princípios de LPS foram utilizados para realizar uma comparação entre
várias linguagens baseadas no i* propostas, a fim de identificar se entre elas existia um núcleo
comum de características (core assets) e, consequentemente, identificar as suas características
variáveis. Essa identificação era importante para atingir o objetivo do trabalho devido à
necessidade de definir um metamodelo, chamado de metamodelo núcleo, capaz de suportar a
118
configuração de distintas de linguagens baseadas no i*. Através do metamodelo núcleo é
possível definir a estrutura da linguagem e, consequentemente, desenvolver a ferramenta de
suporte a modelagem (editores gráficos).
O metamodelo núcleo foi apresentado, bem como o processo da abordagem AGILE
para a configuração de novas linguagens, tomando por base o reuso das características do i*
contemplados no metamodelo e a inserção de novas características no mesmo. O processo é
apoiado pela ferramenta AGILE Tool, também apresentada nesta dissertação.
Com a abordagem AGILE foi possível sistematizar e automatizar a estratégia de
configuração de metamodelos e, através destes, gerar editores gráficos automaticamente com
o apoio da tecnologia GMF. Com o AGILE fomos capazes de aumentar o nível de abstração
do processo de construção de metamodelos, através da automatização dos passos do processo
com a ferramenta AGILE Tool. A AGILE Tool é responsável pela construção de modelos de
configuração do GMF necessários para a geração automática dos editores gráficos.
6.5 PRINCIPAIS CONTRIBUIÇÕES
O escopo da abordagem apresentada neste trabalho cobre a definição da sintaxe de
uma linguagem baseada no i* (metamodelo), bem como a geração do seu respectivo editor
gráfico, ambos apoiados por uma ferramenta CASE. Para desenvolver tal abordagem, várias
atividades foram realizadas anteriormente, tornando-se também contribuições deste trabalho:
Comparação entre diversas variações do i*: foi apresentada uma comparação
entre diversas linguagens baseadas no i* (GRL (AMYOT et al., 2009), i* Wiki
(GRAU et al., 2008), i*-C (BORBA, 2009), i* Aspectual (ALENCAR et al.,
2010), Tropos (SUSI et al., 2005)) a fim de identificar a existência de
características compartilhadas entre estas linguagens (características comuns),
bem como suas diferenças (características variáveis). Com esta comparação,
concluiu-se que é verídica a existência de uma base compartilhada entre as
linguagens e, assim, estas foram entendidas como uma família de linguagens i*.
Criação de um metamodelo núcleo: através dos resultados obtidos na
comparação, foi possível criar um metamodelo núcleo para representação das
características comuns entre as linguagens. Além disso, este metamodelo foi
definido de forma a ser flexível o suficiente para permitir a inserção de elementos
119
de modelagem que fazem parte das características variáveis das linguagens
comparadas. Assim, com este metamodelo é possível configurar novas linguagens
baseadas no i*, onde o usuário poderá especificar quais das características comuns
ele deseja reutilizar, bem como inserir novos elementos de modelagem.
Definição de um novo processo para criação de editores gráficos utilizando a
tecnologia GMF: para tornar possível a configuração de novos elementos de
modelagem no metamodelo núcleo foi preciso definir uma estratégia de
configuração para sistematizar e garantir a corretude quanto ao uso das
tecnologias envolvidas bem como na estruturação da linguagem. Assim um novo
processo de desenvolvimento foi proposto para diminuir a complexidade presente
na criação de editores gráficos através da substituição e automação de algumas
atividades contidas no processo da tecnologia GMF.
Ferramenta de apoio – AGILE Tool: em paralelo ao desenvolvimento da
abordagem AGILE, a ferramenta de apoio denominada AGILE Tool foi
desenvolvida, a fim de realizar a automação das atividades propostas no processo
de criação do metamodelo e do editor gráfico para uma linguagem baseada no i*.
Para este fim, a AGILE Tool foi integrada ao framework GMF.
Publicação em evento: este trabalho foi aceito para publicação como um short
paper no Congresso Ibero-americano em Engenharia de Software (CIbSE 2011).
A taxa de aceite do evento para short papers foi de apenas 11%, mostrando assim
a importância que este trabalho pode trazer as comunidades de engenharia de
requisitos e LPS.
6.6 TRABALHOS FUTUROS
Apesar de ter atingindo o objetivo inicialmente estabelecido neste trabalho que
corresponde a definição de uma abordagem para a criação automatizada de linguagens
baseadas no i*, ainda existe uma gama de atividades que podem ser desenvolvidas utilizando-
se dos resultados obtidos neste trabalho. Assim, como trabalhos futuros é possível listar:
Realizar outros estudos de caso com a abordagem AGILE: para que seja
possível identificar limitações existentes na abordagem não identificadas com a
realização do estudo de caso apresentado neste documento. Com a realização de
120
novos estudos de casos, será possível identificar possíveis falhas para geração de
novas linguagens. É possível que existam ou que venham a existir características
distintas das obtidas na comparação entre as linguagens realizada neste trabalho.
Esta limitação surge devido à impossibilidade de prever as necessidades que
surgirão ao longo do tempo e, assim, é preciso verificar a flexibilidade da
ferramenta para a criação de características não presentes nas linguagens
comparadas neste trabalho;
Reutilizar as lições aprendidas com a criação da abordagem AGILE para o
suporte a outras linguagens: é possível idealizar uma nova abordagem para a
geração automatizada de metamodelos e editores gráficos para outras linguagens
de modelagem que já possuam muitas variantes ou que venham a ser estendidas,
tal como acontece com o i*.
Melhoria continua na AGILE Tool:
o Para suportar a criação das formas gráficas de novos elementos de
modelagem através de interface gráfica de alto nível na
ferramenta: como descrito anteriormente esta é uma tarefa complexa
de ser realizadas e por isso a versão atual da ferramenta não foi possível
contemplá-la. É importante ressaltar que esta é uma limitação apenas
para os novos elementos de modelagem criados pelo usuário. Os
elementos de modelagem reusados do i* são gerados automaticamente
inclusive com as suas formas gráficas.
o Para adicionar a funcionalidade de transformações de modelos SD
em SR e vice-versa: com a versão atual da ferramenta é possível criar
editores gráficos que suportam tanto os modelos SD como os modelos
SR, entretanto estes devem ser criados em arquivos diferentes. O ideal
seria a existência de uma funcionalidade capaz de transformar um
modelo SD em um SR (e vice-versa) a fim de reduzir a probabilidade
de erros e atividades repetitivas na modelagem. A solução é tornar
possível a expansão dos atores presentes no modelo e
consequentemente reformular as suas ligações de dependência para
satisfazer corretamente as restrições impostas pelo modelo;
o Prover integração entre os editores gráficos gerados: o GMF prover
o benefício de criar os modelos nos editores gráficos baseados na
121
tecnologia XML, assim idealizou-se a possibilidade de realizar
transformações de modelos entre as variadas linguagens que forem
criadas utilizando a abordagem.
Do exposto, é possível concluir que ainda há trabalhos que precisam ser realizados
alcançarmos uma certa maturidade tanto da abordagem, como da ferramenta. Todavia,
acreditamos que o trabalho apresentado neste documento representa um grande passo nesta
direção, demonstrando ser uma base sólida para os desdobramentos vindouros.
REFERÊNCIAS
ALEMORComsymp
ALVUniv
AMYfor i*
ANNAlignAnalWork
BORde PCent
BRETROAgen
CARMethvol. 3
CASDeveState
ENCAR, F.;REIRA, A.
mputing (SAposium on A
VES, V. Imversidade Fe
YOT, D.; H* Modeling
NOSI, M.Cnment withlysis Technikshop Proce
RBA, C. C. UProdutos detro de Inform
ESCIANI, POPOS: An Ants and Mul
RVALLO, Jhod and an 39, 2009
STRO, J.; Melopment”. e of the Art
; CASTRO. Towards
AC 2010), 2Applied Com
mplementingederal de Pe
HORKOFF, . In: Procee
C.; DE PASh Organizaique - an Exeedings, p.
Uma Abord Software. mática, Bra
P.; GIORGAgent-Orienlti-Agent Sy
J.P.; FRANEvaluation
MYLOPOULBrinkkempand Resear
, J.; LUCEModular i
2010, Sierrmputing, 20
g Software Pernambuco,
J.; GROSSedings of RI
SCALE, Aational Busxperience R322, 2008.
dagem OrienDissertação
sil, 2009.
GINI, P.; Gnted Softwaystems. Klu
NCH, X.: On Report. In
LOS, J. “Trper, J. and Sch Themes,
ENA, M.; Si* Models.re, Suiça. P010. v. 1. p.
Product LinCentro de I
S, D.; MUSIGIM 2009.
A.; GROSS,siness StratReport. In: P
ntada a Objo (Mestrad
GIUNCHIGLare Developuwer Academ
On the use n: Procs. 2n
ropos: A FrSolvberg, A, Springer-V
SANTOS, E. In: 25th Proceedings 292-297
ne AdoptioInformática
SSBACHER. p.254-264
, D.; YU, tegies usingProcs. 3rd i
jetivos parado) - Unive
LIA, F.; Mpment Methmic Publish
of i* for And PoEM In
amework foA. (eds.), InVerlag, page
E. B.; SILVACM Sym
Proceedin
n Strategiea, Brasil, 20
R, G. A Lig. 2009.
E. Analyzig an Agen* Internatio
a as Fases deersidade Fed
MYLOPOULhodology. Johers, 2004.
Architectingnternational
or Requiremnformation es 261-273.
VA, C.; ARmposium o
ngs of the 2
es. Tese (D07.
ghtweight G
zing Softwant- and Goonal Worksh
e Requisitoderal de Pe
LOS, J.; Pournal of A
ng Hybrid Sal Conferenc
ments-DriveSystems E 2000.
122
RAUJO, J.;on Applied2010 ACM
outorado) -
GRL Profile
are Processoal-orientedhop, CEUR
s de Linhasernambuco,
PERINI, A.Autonomous
Systems: Ace. LNBIP,
en Softwarengineering:
2
; d
M
-
e
s d R
s ,
. s
A ,
e :
123
CASTRO, J; KOLP, M; MYLOPOULOS, J. Towards requirements-driven information systems engineering: the Tropos project. Information Systems (Oxford), Holanda, v. 27, n. 6, p. 365-389, 2002.v. 27, n. 6, p. 365-389. Elsevier, 2002.
CETINA, C.; GINER, P.; FONS, J.; V. Using Feature Models for Developing Self-Configuring Smart Homes. In: Proceedings of the 2009 Fifth International Conference on Autonomic and Autonomous Systems. p.179-188. 2009.
CHUNG, L.; NIXON, B.; YU, E.; MYLOPOULOS, J. Non-Functional Requirements in Software Engineering. 1. ed. [S.l.]: Springer, 1999.
CLEMENTS, P; NORTHROP, L. Software Product Lines: Practices and Patterns. 3 ed. [S.l.]: Addison-Wesley Professional, 2001.
CZARNECKI, K.; EISENECKER, U. W. Generative Programming: methods tools and applications. New York, NY, USA: ACM Press/Addison-Wesley Publishing Co., 2000.
DIJKSTRA, E. A Discipline of Programming. Prentice-Hall, 1976.
ECLIPSE, The Eclipse Foundation. 2010. Web-site. Disponível em: <http://www.eclipse.org>. Último acesso em: 07 de Outubro de 2010.
EMF - Eclipse Modeling Framework. Web-site. Disponível em: <http://www.eclipse.org/emf>. Último acesso em: 07 de Outubro de 2010.
GAMMA. E.; HELM. R.; JOHNSON. R. Padrões de Projeto. Bookman. 2000
GEF - Graphical Editing Framework. Web-site. Disponível em: <http://www.eclipse.org/gef/>. Último acesso em: 07 de Outubro de 2010.
GMF - Graphical Modelling Framework. Web-site. Disponível em: < http://www.eclipse. org/modeling/ gmp/>. Último acesso em: 07 de Outubro de 2010.
GRAU, G.; HORKOFF, J.; YU, E.; ABDULHADI, S. i* Guide. 2008. Web-site. Disponível em: <http://istar.rwth-aachen.de>. Último acesso em: 28 de Fevereiro de 2010.
KANG, K. C.; COHEN, S.; HESS, J.; NOWAK , W.; PETERSON , S.; Feature-oriented domain analysis (FODA) feasibility study. Technical Report CMU/SEI-90-TR-21, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA, Nov.1990.
KANG, K. C.; LEE, J.; DONOHOE, P. Feature Oriented Product Line Engineering. IEEE Software, v. 19, p. 58-65, 2002.
KICZALES, G.; LAMPING, J.; MENDHEKAR, A.; MAEDA, C.; LOPES, C.; LOINGTIER, J.M.; IRWIN, J.; Aspect oriented programming. LNCS, 1241:220–242, Oct. 1997.
124
KLEPPE, A.; WARMER, J.; BAST, W. MDA explained: the model driven architecture: practice and promise. Addison-Wesley Longman Publishing Co., Inc. Boston, MA, USA. 2003.
KOTONYA, G.; SOMMERVILLE, I. Requirements Engineering: Processes and Techniques. 1 ed. [S.l.]: John Wiley & Sons, 1998.
LAMSWEERDE, A. V. Requirements Engineering in the Year 00: A Research Perspective. In: Keynote paper, Proc. ICSE’2000 - 22nd Intl. Conference on Software Engineering. IEEE Computer Society Press, 2000.
LAMSWEERDE, A. V. Goal-Oriented Requirements Engineering: A Guided Tour. In: RE '01: Proceedings of the Fifth IEEE International Symposium on Requirements Engineering. Washington, DC, USA: IEEE Computer Society, p.249-263, 2001.
LUCENA, M. ; SANTOS, E.; SILVA, C.; ALENCAR, F.; SILVA, M.; CASTRO, J. Towards a unified metamodel for i*. In: RCIS´08- Second IEEE International Conference on Research Challenges in Information Science, 2008, Marrakech, Marrocos. Proceedings of Second IEEE International Conference on Research Challenges in Information Science, 2008. RCIS 2008, p. 237-246, 2008.
MAIDEN, N.A.M.; JONES, S.; NCUBE, C.; LOCKERBIE, J. Using i* in Requirements Projects: Some Experiences and Lessons Learned. In: Yu, E., Giorgini, P., Maiden, N.A.M.,
Mylopoulos, J. (eds.) Social Modeling for Requirements Engineering. The MIT Press, Cambridge, 2010
NASCIMENTO, L. M. Core Assets Development in Software Product Lines - Towards a Practical Approach for the Mobile Game Domain. Dissertação (Mestrado), Universidade Federal de Pernambuco, Centro de Informática, Brasil, 2008.
OMG, The Object Management Group. OMG's Meta Object Facility. Disponível em: < http://www.omg.org/mof/>. Último acesso em: 17 de Outubro de 2010a.
OMG, The Object Management Group. Object Constraint Language. Disponível em: < http://www.omg.org/spec/OCL/>. Último acesso em: 28 de Outubro de 2010b.
OMG, The Object Management Group. OMG Model Driven Architecture. Disponível em: < http://www.omg.org/spec/OCL/>. Último acesso em: 02 de Novembro de 2010c.
PARNAS, D. L.; MORRIS, R. On the Criteria To Be Used in Decomposing Systems into Compartments. Communications of the ACM, 1972.
PILONE, D.; PITMAN, N. UML 2.0 in a Nutshell. O'Reilly, 2005.
125
PIMENTEL, J.; ET AL. Using i* and Tropos in a Software Engineering Contest: Lessons Learnt and Some Key Challenges. Proceedings of the 4th International i* Workshop. 2010.
POHL, K.; BOCKLE, G.; LINDEN, F. V. Software product line engineering. Communications of the ACM. v. 49. Springer - Verlag Berlin Heidelberg, 2005.
PRIBERAM. Dicionário da língua portuguesa. Web-site. Disponível em: < http://www.priberam.pt/dlpo/>. Último acesso em: 06 de Dezembro de 2010.
RASHID, A.; MOREIRA, A.; ARAÚJO, J. Modularisation and Composition of Aspectual Requirements. In: 2nd Intl. Conf. on Aspect- Oriented Soft. Develop. USA, pp. 11-20, 2003.
SEI, Software Engineering Institute. A Framework for Software Product Line Practice. v. 5. Web-site. Disponível em: < http://www.sei.cmu.edu/productlines/frame_report/>. Último acesso em: 19 de Maio de 2010.
SIENA, A.; MYLOPOULOS, J.; PERINI, A.; SUSI, A. From Law to Requirement. 1st International Workshop on Requirements Engineering and Law (Relaw'08). 2008
SIERRA. K.; BATES. B. Head First Java. v. 2. O'Reilly. 2009
SILVA, L. F. Uma Estratégia Orientada a Aspectos para Modelagem de Requisitos. Tese (Doutorado) – Pontifícia Universidade Católica do Rio de Janeiro, 2006.
STEINBERG, D.; BUDINSKY, F.; PATERNOSTRO, M.; MERKS, E. EMF: Eclipse Modeling Framework, Addison-Wesley Professional, 2008.
SUSI, A.; PERINI, A.; MYLOPOULOS, J. The Tropos metamodel and its use. Informatical journal, v. 29, n. 4, p. 401–408. Citeseer. 2005.
TRAVASSOS, G.; GUROV, D.; AMARAL, E. Introdução à Engenharia de Software Experimental. Relatório Técnico, RTES-590/02, Rio de Janeiro, 2002.
VENKATESAN, M. D.: Generation of Diagram Editors, Taking the Enterprise Application Integration Patterns as Case Study. Dissertação (Mestrado). Hamburg, Alemanha. 2006.
WEISS, D.; LAI, C. Software Product-Line Engineering: a Family-Based Software Development Process. Addison-Wesley, 1999.
WOHLIN, C.; RUNESON, P.; HOST, M.; OHLSSON, M.; REGNELL, B.; WESSLEN, A. Experimentation in Software Engineering: an Introduction. Kluwer Academic Publishers, USA, 2000.
WOOLDRIDGE, M. An Introduction to MultiAgent Systems. John Wiley & Sons, 2002.
126
YU, E. Modelling Strategic Relationships for Process Reengineering. Tese (Doutorado) - University of Toronto, Department of Computer Science, Canadá, 1995.
YU, E. Towards modelling and reasoning support for early-phase requirements engineering. Requirements Engineering, Proceedings of the Third IEEE International Symposium on, 1997.
YU, E. GRL - Goal-oriented Requirement Language. Web-site. Disponível em: < http://www.cs.toronto.edu/km/GRL/>. Último acesso em: 11 de Janeiro de 2011.
YU, Y.; LEITE, J. C.; MYLOPOULOS, J. From goals to aspects: Discovering aspects from requirements goal models. In: 12th Intl. Conf. on Requirements Engineering. p.38-47, 2004.
ANEXO A – DETALHAND
supo
proce
amig
desen
das p
(Plug
ferra
Eclip
conju
meta
acim
NDO A FERRAMENTA AGILE TOOL
A AGIL
rte ferrame
esso de cri
gáveis que
nvolviment
principais t
g-in Develo
amentas par
pse. Isto im
unto com ou
É possív
amodelo de
1. Reu
conf
2. Cria
criaç
meta
3. Ger
auto
lingu
As próxi
ma foram des
LE Tool é u
ental para u
iação de um
facilitam
o foi utiliza
tecnologias
opment Envi
ra criar, de
mplica dizer
utro plug-in
vel definir
uma lingua
uso estraté
figuração de
ação, confi
ção, config
amodelo ob
ração auto
omática de
uagem.
imas seções
senvolvidas
uma ferrame
uso da abo
ma linguag
a definição
ada a lingua
oferecidas
ironment) (
esenvolver,
que a AGI
n, o GMF.
três etapa
agem basead
égico de e
e uma base
iguração e
guração e
btido realiza
omática de
código O
s descrevem
s.
enta que fo
ordagem A
gem basead
o da sintax
agem de pro
s pela Ecli
(PDE, 2010
testar, dep
ILE Tool é
as diferenc
da no i*:
elementos
i* para uma
e inserção
inserção
adas na etap
e código
OCL aplicá
m, em detalh
oi desenvolv
GILE. Ela
da no i* (F
xe da lingu
ogramação
pse Founda
) e o GMF
urar, comp
um plug-in
ciadas na f
de modela
a nova lingu
de caracte
de novos
pa anterior.
OCL – e
ável a cad
hes, como c
vida especi
suporta as
Figura 6.4)
uagem bas
orientada a
ation (ECL
F. O PDE fo
pilar e impl
n para o Ec
ferramenta
agem – et
uagem.
erísticas es
elementos
etapa respo
da relacion
cada uma da
ificamente p
s principais
através de
seada no i
a objetivos J
LIPSE, 201
ornece um c
lantar plug-
clipse que t
para a de
tapa respon
specíficas –
s de mode
onsável pe
namento ex
as etapas ap
127
para prover
s etapas do
e interfaces
*. Em seu
Java e duas
0): o PDE
conjunto de
-ins para o
trabalha em
efinição do
nsável pela
– suporte a
elagem no
ela geração
xistente na
presentados
7
r
o
s
u
s
E
e
o
m
o
a
a
o
o
a
s
128
A.1 REUSO ESTRATEGICO DE ELEMENTOS DE MODELAGEM
De acordo com os conceitos de Linhas de Produtos de Software descritos no Capítulo
3, esta etapa foi desenvolvida para que fosse possível realizar o máximo de reaproveitamento
sobre as características comuns identificadas na comparação entre linguagens baseadas no i*
realizada no Capítulo 4. Nesta comparação foi possível perceber que uma linguagem tomada
por base pode ter seus elementos totalmente ou parcialmente herdados de outra linguagem.
Assim, é possível concluir que, obrigatoriamente, todos os elementos do i* original devem ser
implementados na ferramenta para que seja possível prover a máxima abrangência sob os
elementos para reuso na definição de uma nova linguagem. Este reuso poderá ser alcançado
através da configuração do modelo de features realizado na tela de configuração da base i* na
AGILE Tool (Figuras 4.10 e 6.5, respectivamente).
Cada um dos elementos de modelagem existentes no i* original foi mapeado e
implementado como uma entidade, como pode ser observado no diagrama de classes
representado na Figura A.1 (pacote beans.coreelements). Em cada uma destas classes existe a
codificação prévia de como cada um destes elementos deve ser mapeado para os modelos do
GMF através dos métodos: ecoreInjection(), gmfgraphInjection(), gmftoolInjection() e
gmfmapInjection() que é dada através da implementação das suas respectivas interfaces (por
exemplo, a classe Ator implementa a interface Compartment). Estes métodos são
responsáveis por gerar trechos de códigos XML (eXtensible Markup Language) de acordo
com o GMF para definição dos modelos. As classes responsáveis pela geração dos códigos
XML são: ParserXML_Metamodel, ParserXML_GMFGraph, ParserXML_GMFTool,
Parser XML_GMFMap.
A classe ConfigIstarBase (Figura A.1) é responsável por implementar o mecanismo
de reuso dos elementos do i* original. É importante ressaltar que o produto resultante desta
etapa é um arquivo de código em XML que representa o metamodelo configurado apenas com
os elementos selecionados para o reuso.
Utilizou-se como mecanismo de implementação o tratamento de eventos oferecidos
pela própria linguagem Java (Listeners). Com isso foi possível tratar a seleção dos elementos
de modelo do i* a partir da interface gráfica e realizar a escrita dos arquivos XML dos
modelos necessários. A partir da seleção dos elementos em nível de interface gráfica, os
eventos são disparados e criam os objetos das respectivas classes que representam os
elementos selecionados. Logo após os métodos para geração de código XML são executados
crian
de có
interf
Figur
A.2
elem
anter
base
ndo assim o
ódigo XML
face gráfica
ra A1 – Diagr
CRIAÇÃ
ESPECÍFI
Este mód
mentos de m
riormente, u
i* que será
o arquivo X
L a partir de
a.
rama de class
ÃO, CON
ICAS
dulo da AG
modelagem
um novo ele
á utilizada (m
XML. Resum
e uma defin
ses resumido
FIGURAÇÃ
GILE Tool é
m específico
emento de m
mais detalhe
midamente,
nição prévia
sobre o reuso
ÃO E
é responsáv
os para a
modelagem
es na Seção
a primeira
a do metam
o estratégico
INSERÇÃO
vel pela cria
linguagem
m só pode se
o 6.3.2)
etapa é res
modelo da li
de elementos
O DE C
ação, config
a ser defi
er criado log
sponsável p
inguagem e
s de modelag
CARACTE
guração e in
finida. Com
go após a d
129
ela geração
em nível de
em
ERÍSTICAS
nserção dos
mo descrito
definição da
9
o
e
S
s
o
a
realiz
A.2)
newe
bean
respo
exclu
elem
Figur
A.3 G
relac
Os novo
zada previa
: NewMod
elements. E
ns.coreeleme
onsáveis po
usivamente
mentos de mo
ra A.2 – Diag
GERAÇÃO
Nesta úl
cionamentos
os element
amente na e
dule, New
Estas classes
ents, repres
or gerar có
da configu
odelagem (F
rama de clas
O AUTOMÁ
ltima etapa
s entre os
os de mod
etapa anterio
wIntentiona
s possuem
sentado na
digos XML
uração do n
Figura 6.12
ses resumido
ÁTICA DE
acontece a
elementos
delagem sã
or. Para ist
alElement
os mesmos
Figura A.2
L. A execu
novo eleme
2).
o para a criaç
CÓDIGO O
a geração au
de modela
ão inserido
o foram cri
e NewRe
s métodos c
2. Os méto
ução de cad
ento realiza
ção de novos e
OCL
utomática d
agem semp
os na defin
iadas as seg
lationship
contidos na
odos destas
da uma des
da na tela
elementos de
de código O
pre é realiz
nição do m
guintes clas
contidas
as interfaces
s classes ta
stas classes
de inclusão
e modelagem
OCL. As re
zada na AG
130
metamodelo
sses (Figura
no pacote
s do pacote
ambém são
dependerá
o de novos
estrições de
GILE Tool
0
o
a
e
e
o
á
s
e
l
quan
criad
qual
pela
autom
Neste
nenh
Tool
A.4)
Figur
F
ndo uma lig
da.
A defini
oferece fun
AGILE To
mática pela
Na Figur
e modelo,
huma restriç
l a geração
.
ra A.3 – Exem
Figura A.4 – E
gação do i*
ção das res
ncionalidad
ool é comp
ferramenta
ra A.3 é pos
para a liga
ção de relac
do código
mplo da estru
Exemplo da e
original é
trições do G
des necessár
osto no mo
a como pode
ssível obser
ação de dep
ionamento
OCL e in
utura de uma
estrutura de u
selecionada
GMF acont
rias para is
odelo de m
e ser observ
rvar o mode
pendência e
foi definida
nserido auto
a ligação no m
uma ligação nrestriçõ
a para reuso
ece no mod
sto. O códig
mapeamento
vado nas Fig
elo de mape
especificam
a (campos c
omaticamen
modelo de ma
no modelo deões
o ou quand
delo de map
go OCL ge
que també
guras A.3 e
eamento ger
mente (desta
constraint).
nte nos cam
apeamento se
e mapeamento
do uma nov
peamento (.
erado autom
ém é gerado
A.4.
rado autom
acada na F
Com o uso
mpos contra
em definição d
to com a defin
131
va ligação é
.gmfmap) o
maticamente
o de forma
aticamente.
igura A.3),
o da AGILE
aint (Figura
de restrições
nição das
é
o
e
a
.
,
E
a