JosiasPaes dissertação final

“AGI

J

LE: Um

Automá

Josias

ma Abord

ática de

s Paes d

dagem

e Lingua

da Silv

para Ge

agens i

va Juni

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

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.

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

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 

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 

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 

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 

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

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

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 d AMSWEERD 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 K portuguê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 origin 13 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 Depe n, 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 Tab mento 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 De Rest õ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