69
Universidade Federal do Rio Grande do Norte Centro de Ciências Exatas e da Terra Departamento de Informática e Matemática Aplicada Bacharelado em Engenharia de Software SMiLeCompiler: Um Analisador Sintático e Semântico para Notação Textual de Modelos iStar Andreza da Costa Medeiros Natal-RN Junho de 2017

SMiLeCompiler: Um Analisador Sintático e Semântico para

  • Upload
    others

  • View
    9

  • Download
    0

Embed Size (px)

Citation preview

Page 1: SMiLeCompiler: Um Analisador Sintático e Semântico para

Universidade Federal do Rio Grande do NorteCentro de Ciências Exatas e da Terra

Departamento de Informática e Matemática AplicadaBacharelado em Engenharia de Software

SMiLeCompiler: Um Analisador Sintático eSemântico para Notação Textual de Modelos

iStar

Andreza da Costa Medeiros

Natal-RN

Junho de 2017

Page 2: SMiLeCompiler: Um Analisador Sintático e Semântico para

Andreza da Costa Medeiros

SMiLeCompiler: Um Analisador Sintático e Semânticopara Notação Textual de Modelos iStar

Monografia de Graduação apresentada aoDepartamento de Informática e MatemáticaAplicada do Centro de Ciências Exatas e daTerra da Universidade Federal do Rio Grandedo Norte como requisito parcial para a ob-tenção do grau de bacharel em Engenhariade Software.

Orientador

Profa. Dra. Marcia Jacyntha Nunes Rodrigues Lucena

Coorientador

Prof. Fábio Fernandes Penha

Universidade Federal do Rio Grande do Norte – UFRNDepartamento de Informática e Matemática Aplicada – DIMAp

Natal-RN

Junho de 2017

Page 3: SMiLeCompiler: Um Analisador Sintático e Semântico para

Catalogação da Publicação na Fonte. UFRN / SISBI / Biblioteca Setorial

Centro de Ciências Exatas e da Terra – CCET.

Medeiros, Andreza da Costa.

SMiLeCompiler: um analisador sintático e semântico para notação textual de

modelos iStar / Andreza da Costa Medeiros. - Natal, 2017.

67f.: il.

Orientadora: Profa. Dra. Marcia Jacyntha Nunes Rodrigues Lucena.

Coorientador: Prof. Fábio Fernandes Penha.

Monografia (Graduação) – Universidade Federal do Rio Grande do Norte.

Centro de Ciências Exatas e da Terra. Departamento de Informática e Matemática

Aplicada. Bacharelado em Engenharia de Software.

1. Engenharia de software – Monografia. 2. Análise de requisitos – Monografia.

3. Framework iStar – Monografia. 4. SMiLe – Monografia. 5. Analisador sintático

– Monografia. 6. Analisador semântico – Monografia. I. Lucena, Marcia Jacyntha

Nunes Rodrigues. II. Penha, Fábio Fernandes. III. Título.

RN/UF/BSE-CCET CDU: 004.41

Page 4: SMiLeCompiler: Um Analisador Sintático e Semântico para

Monografia de Graduação sob o título SMiLeCompiler: Um Analisador Sintático e Semân-

tico para Notação Textual de Modelos iStar apresentada por Andreza da Costa Medeiros

e aceita pelo Departamento de Informática e Matemática Aplicada do Centro de Ciências

Exatas e da Terra da Universidade Federal do Rio Grande do Norte, sendo aprovada por

todos os membros da banca examinadora abaixo especificada:

Profa. Dra. Marcia Jacyntha Nunes Rodrigues LucenaOrientador

Departamento de Informática e Matemática AplicadaUFRN

Prof. MSc. Leonardo Reis LucenaDiretoria Acadêmica de Gestão e Tecnologia da Informação

IFRN

Profa. Dra. Lyrene Fernandes da SilvaDepartamento de Informática e Matemática Aplicada

UFRN

Natal-RN, dezenove de junho de dois mil e dezessete

Page 5: SMiLeCompiler: Um Analisador Sintático e Semântico para

A minha mãe Eridian e meu irmão Anderson por todo amor, apoio e paciência.

Ao meu amigo Rafael por toda a força e inspiração.

Page 6: SMiLeCompiler: Um Analisador Sintático e Semântico para

Agradecimentos

Durante esse tempo na UFRN aproveitei várias oportunidades que me fizeram apren-

der e amadurecer. Pude estagiar dentro e fora da universidade, participei de monitoria,

de iniciação científica, junto com alguns amigos fundei uma empresa júnior e pude fazer

um intercâmbio incrível. Portanto, gostaria de agradecer a UFRN por ter me dado a pos-

sibilidade de participar de todos esses projetos que foram de grande importância no meu

crescimento intelectual e profissional.

Obrigada a minha família, por me aturarem e me apoiarem durante esses anos. A

minha mãe por ser essa mulher maravilhosa e guerreira que me inspira todos os dias

a continuar. Ao meu irmão por me fazer sentir tão importante e querida, e sempre me

fazendo rir até quando não deveria. Muito obrigada pelo apoio que vocês me dão.

Obrigada, Rafael, por ser a pessoa mais incrível que conheci, por me inspirar e me

ajudar nos momentos em que quis desistir.

Obrigada aos meus amigos que me incentivaram durante todo essa jornada.

Um agradecimento especial a todos que fizeram parte da 4Soft, foram os melhores anos

de universidade. E aos meus companheiros de curso que, vezes rindo, vezes chorando, me

ajudaram nesse caminho e fizeram os dias na universidade mais divertidos: Obrigada

Bernardo, Iago, Igor, Jonathan, Lucas, Luiz Rogério, Thiago e Waldyr.

Gostaria de agradecer também a Professora Márcia pela orientação e por ter acredi-

tado em mim, ao Fábio por ter me incentivado e me ajudado tanto nesse trabalho, sem

eles nada disso seria possível, muito obrigada.

Obrigada também a Professora Lyrene e o Professor Leonardo por terem aceitado

participar da banca avaliadora.

Obrigada a todos que fizeram isso possível.

Obrigada.

Page 7: SMiLeCompiler: Um Analisador Sintático e Semântico para

Take these broken wings and learn to fly. All your life, you were only waiting for this

moment to arise.

John Lennon / Paul Mccartney

Page 8: SMiLeCompiler: Um Analisador Sintático e Semântico para

SMiLeCompiler: Um Analisador Sintático e Semânticopara Notação Textual de Modelos iStar

Autor: Andreza da Costa Medeiros

Orientador(a): Profa. Dra. Marcia Jacyntha Nunes Rodrigues Lucena

Coorientador(a): Prof. Fábio Fernandes Penha

Resumo

A atividade de análise de requisitos pode tornar-se um tanto difícil dado o tamanho e

complexidade da descrição do contexto em que o software está inserido. Com o objetivo

de contornar essas dificuldades, várias estratégias e ferramentas vem sido desenvolvidas

pela comunidade. Uma delas é a proposta SMiLe que apresenta uma notação textual com

uma abordagem modular para os modelos gráficos do framework iStar, essa abstração

modular permite o manuseio e construção de diagramas de acordo com a necessidade do

Analista de Requisitos.

Este trabalho propõe uma ferramenta de suporte à notação textual SMiLe com o

objetivo de apoiar a atividade do Analista de Requisitos, automatizando o processo de

verificação dos modelos SMiLe e validação dos modelos iStar descritos nessa notação.

O SMiLeCompiler faz: (i) uma analise sintática e semântica de acordo com as regras

definidas na proposta SMiLe e no framework iStar, (ii) fornece informações quantitativas

sobre a modelagem em analise e (iii) traduz os modelos para o formato iStarML. Este

trabalho também faz uma avaliação da ferramenta a partir de um cenário especificado,

os resultados obtidos demonstram que a o SMiLeCompiler foi bem sucedido em atender

as expectativas definidas, apesar de suas limitações. Os estudos realizados nesse trabalho

e a ferramenta implementada servem como base para trabalhos futuros de melhorias e

extensão da ferramenta, bem como para orientação de desenvolvedores que pretendem

utilizar o pacote SMiLeCompiler em suas soluções.

Palavras-chave: análise de requisitos, framework iStar, SMiLe, analisador sintático, ana-

lisador semântico

Page 9: SMiLeCompiler: Um Analisador Sintático e Semântico para

SMiLeCompiler: A Syntax and Semantic Analyzer toiStar Models Textual Notation

Author: Andreza da Costa Medeiros

Advisor: Profa. Dra. Marcia Jacyntha Nunes Rodrigues Lucena

Co-advisor: Prof. Fábio Fernandes Penha

Abstract

The size and complexity of a software context could make the requirements analysis

difficult. In order to make tasks of a Requirements Analyst easier, strategies and tools

have been proposed and developed by the Software Engineering community. One of those

proposals is the SMiLe textual notation that have a modular approach to iStar framework

graphic models.

This work proposes a support tool for the SMiLe language. The goal of this tool is

to make the SMiLe models analysis and verification process of iStar models automatic.

The SMiLeCompiler achieve: (i) syntax and semantics analysis according with the SMiLe

and iStar framework rules, (ii) provides quantitative information about the context in

analysis, and (iii) translate SMiLe models to iStarML language. In addition, this work

evaluate the SMiLeCompiler in a stated context. Despite limitations, the obtained results

shows that the tool was successful in meeting its expectations. The studies related in this

work and the tool developed serve as a basis for future improvements and extensions, as

well as a guideline for developers that wants to use the SMiLeCompiler package.

Keywords : requirements analysis, iStar framework, SMiLe, syntax analyzer, semantic

analyzer

Page 10: SMiLeCompiler: Um Analisador Sintático e Semântico para

Lista de figuras

1 Concepção do SMiLe . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 17

2 Representação de um Modelo SD . . . . . . . . . . . . . . . . . . . . . p. 20

3 Representação de um Modelo SR . . . . . . . . . . . . . . . . . . . . . p. 21

4 Uma representação do modelo SR no iStarML . . . . . . . . . . . . . . p. 22

5 (a) Schema parcial de iStarJSON e (b) uma representação do modelo SD. p. 23

6 Exemplo de modelo SD descrito em SMiLe. . . . . . . . . . . . . . . . . p. 23

7 Exemplo de um arquivo SMiLe contendo a definição do ator, suas asso-

ciações com outros atores e as declarações de relacionamentos externos. p. 24

8 Um compilador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 26

9 As fases de um compilador . . . . . . . . . . . . . . . . . . . . . . . . . p. 28

10 Exemplo de fases de um compilador . . . . . . . . . . . . . . . . . . . . p. 29

11 ANTLR, reconhecendo uma linguagem . . . . . . . . . . . . . . . . . . p. 30

12 Modelo SD da Concepção SMiLe com ênfase no SMiLeCompiler . . . . p. 32

13 Entradas e saídas processadas pelo SMiLeCompiler . . . . . . . . . . . p. 33

14 Proposta arquitetural do SMiLeCompiler . . . . . . . . . . . . . . . . . p. 34

15 Definição da interface de comunicação com o SMiLeCompiler . . . . . . p. 34

16 Estrutura do pacote domain . . . . . . . . . . . . . . . . . . . . . . . . p. 35

17 Estrutura do pacote services . . . . . . . . . . . . . . . . . . . . . . . . p. 35

18 Estrutura do pacote listeners . . . . . . . . . . . . . . . . . . . . . . . p. 36

19 As fases do SMiLeCompiler . . . . . . . . . . . . . . . . . . . . . . . . p. 38

20 Diagrama de classe das principais classes de domínio da aplicação . . . p. 39

21 Modelo SD de um cenário de desenvolvimento de software . . . . . . . p. 46

Page 11: SMiLeCompiler: Um Analisador Sintático e Semântico para

22 Modelo SD parcial do cenário de desenvolvimento de software em SMiLe p. 47

23 Parte do arquivo resultante da tradução para iStarML . . . . . . . . . p. 50

Page 12: SMiLeCompiler: Um Analisador Sintático e Semântico para

Lista de tabelas

1 Cenário: informações quantitativas totais . . . . . . . . . . . . . . . . . p. 48

2 Cenário: informações quantitativas específicas por ator . . . . . . . . . p. 48

3 Cenário: número máximo de associações e relacionamentos externos . . p. 49

Page 13: SMiLeCompiler: Um Analisador Sintático e Semântico para

Lista de códigos

2.1 Gramática condizente a Figura 11 . . . . . . . . . . . . . . . . . . . . . p. 30

3.1 Instanciando SMiLeCompiler e definindo diretório alvo . . . . . . . . . p. 40

3.2 Compilando os arquivos SMiLe . . . . . . . . . . . . . . . . . . . . . . p. 40

3.3 Especificando os limites máximos . . . . . . . . . . . . . . . . . . . . . p. 43

3.4 Acessando informações quantitativas totais do ambiente em análise . . p. 43

3.5 Acessando informações quantitativas de cada ator . . . . . . . . . . . . p. 44

3.6 Acessando os erros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 44

3.7 Acessando os alertas . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 45

3.8 Acessando iStarML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 45

4.1 Cenário: análise quantitativa de limites máximos . . . . . . . . . . . . . p. 49

4.2 iStarML: associação inválida . . . . . . . . . . . . . . . . . . . . . . . . p. 52

4.3 iStarML: ator não definido . . . . . . . . . . . . . . . . . . . . . . . . . p. 52

4.4 iStarML: tipo de ator inválido . . . . . . . . . . . . . . . . . . . . . . . p. 53

A.1 Smile.g4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 58

B.1 Andreza.smile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 61

B.2 Cliente.smile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 61

B.3 Desenvolvedor.smile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 61

B.4 Diretor.smile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 61

B.5 DiretorQA.smile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 62

B.6 EspecialistaQA.smile . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 62

B.7 GerenteDeProjeto.smile . . . . . . . . . . . . . . . . . . . . . . . . . . p. 62

B.8 Monitoramento.smile . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 63

B.9 PerfilDiretoria.smile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 63

B.10 PerfilTecnico.smile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 63

B.11 Planejamento.smile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 63

B.12 ProfissionalDeSoftware.smile . . . . . . . . . . . . . . . . . . . . . . . . p. 64

B.13 Testador.smile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 64

C.1 iStarML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 65

Page 14: SMiLeCompiler: Um Analisador Sintático e Semântico para

Sumário

1 Introdução p. 14

1.1 Apresentação do problema . . . . . . . . . . . . . . . . . . . . . . . . . p. 15

1.2 Objetivo geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 15

1.3 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 16

1.4 Abordagem da proposta . . . . . . . . . . . . . . . . . . . . . . . . . . p. 17

1.5 Estrutura do trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 18

2 Fundamentação Teórica p. 19

2.1 Framework iStar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 19

2.1.1 Modelo de Dependência Estratégica - SD . . . . . . . . . . . . . p. 20

2.1.2 Modelo de Raciocínio Estratégico - SR . . . . . . . . . . . . . . p. 20

2.1.3 Notações textuais para framework iStar . . . . . . . . . . . . . p. 21

2.2 Compiladores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 25

2.2.1 O compilador . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 25

2.2.2 A estrutura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 26

2.3 ANTLR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 30

3 SMiLeCompiler: Um Analisador Sintático e Semântico p. 32

3.1 Proposta arquitetural . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 33

3.2 Modelo semântico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 38

3.3 Funcionalidades e modo de uso . . . . . . . . . . . . . . . . . . . . . . p. 39

4 Aplicação do SMiLeCompiler p. 46

Page 15: SMiLeCompiler: Um Analisador Sintático e Semântico para

4.1 Apresentação do cenário . . . . . . . . . . . . . . . . . . . . . . . . . . p. 46

4.2 Informações quantitativas . . . . . . . . . . . . . . . . . . . . . . . . . p. 47

4.2.1 Informações quantitativas totais . . . . . . . . . . . . . . . . . . p. 48

4.2.2 Informações quantitativas específicas . . . . . . . . . . . . . . . p. 48

4.2.3 Limites de relacionamentos e associações . . . . . . . . . . . . . p. 49

4.3 Transformação para iStarML . . . . . . . . . . . . . . . . . . . . . . . . p. 50

4.4 Comparação com outras ferramentas . . . . . . . . . . . . . . . . . . . p. 51

4.4.1 Casos avaliados . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 51

5 Conclusão p. 54

5.1 Limitações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 54

5.2 Trabalhos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 54

Referências p. 56

Apêndice A -- Gramática p. 58

Apêndice B -- Arquivos SMiLe p. 61

Apêndice C -- Arquivo iStarML p. 65

Page 16: SMiLeCompiler: Um Analisador Sintático e Semântico para

14

1 Introdução

A linguagem natural é muito utilizada no processo de elicitação de requisitos para

expressar as necessidades que motivam o desenvolvimento, a compreensão do contexto

no qual está inserido e as soluções que irão direcionar a construção do software. Porém,

a linguagem natural pode oferecer desafios que podem dificultar as atividades realizadas

durante o processo de desenvolvimento.

Um dos maiores desafios encontrados na utilização da linguagem natural, além da

ambiguidade e incompletude, é a impossibilidade de obter uma visão geral do problema,

dificultando a compreensão e, dessa forma, implicando em todas as tarefas do processo

de desenvolvimento de software (ANNERVAZ et al., 2013). Essas dificuldades crescem di-

retamente proporcionais a complexidade do problema, ficando cada vez mais inviável de

utilizar apenas a linguagem natural para descrevê-lo.

Com o objetivo de contornar essas dificuldades, algumas estratégias e ferramentas

vem sendo propostas e desenvolvidas pela comunidade de Engenharia de Software. Uma

delas é a abordagem proporcionada pelo framework iStar que busca, por meio de uma

notação gráfica, representar uma visão mais geral e concisa do problema através de as-

pectos da modelagem social e raciocínio estratégico. No entanto, assim como a linguagem

natural, o framework iStar tem suas limitações. Quanto maior a quantidade de entidades

e relacionamentos entre elas, maior e mais complexa é a representação visual do problema

utilizando esta abordagem.

A fim de solucionar esses obstáculos, a linguagem SMiLe foi criada como uma notação

textual próxima a linguagem natural, com regras precisas para uma descrição modular

dos modelos iStar. A linguagem SMiLe apresenta uma notação textual para dar suporte a

uma abordagem híbrida (textual e gráfica) para manusear as entidades e relacionamentos

do framework iStar de maneira modular, de uma forma que uma representação complexa

possa ser dividida em partes menores e interdependente.

Um Analista de Requisitos que pretende utilizar a abordagem SMiLe enfrentará o

Page 17: SMiLeCompiler: Um Analisador Sintático e Semântico para

15

trabalho de analisar a corretude dos arquivos SMiLe manualmente, isso pode ser conside-

rado uma ameaça a proposta. Com o objetivo de automatizar essa tarefa, este trabalho

apresenta a primeira versão do SMiLeCompiler, uma ferramenta de análise sintática e

semântica para a notação textual de modelos iStar.

1.1 Apresentação do problema

A SMiLe (Scalable Modular iStar Language) é uma definição textual com regras pre-

cisas para descrever as informações sociais que estão representadas nos modelos gráficos

do framework iStar. Estas representações textuais se dão através da complexidade social

do ator, uma abstração de bloco extraída dos próprios modelos iStar (PENHA, 2017). Para

essa notação, até o momento, não existe nenhuma proposta de ferramenta implementada

para automatizar o processo de consistência dos modelos descrito na SMiLe. A ausên-

cia desse processo automatizado exige um esforço ainda maior do Analista

de Requisitos para não incluir erros e inconsistências, pois as atividades de es-

crita, verificação, validação e manutenção dos modelos serão apenas de responsabilidade

humana.

Embora a proposta SMiLe tenha como fim uma abordagem híbrida –textual e gráfica–

o processo manual da notação textual pode se tornar ainda mais complexo devido a decisão

estratégica de adicionar as informações da modelagem em módulos.

1.2 Objetivo geral

Uma ferramenta de suporte a atividade de análise do Analista de Requisito, quando

esses estiverem utilizando alguma abordagem que envolva a notação textual SMiLe. A

ferramenta apresentada neste trabalho poderá contribuir positivamente com a proposta

SMiLe para sua aceitação perante a comunidade iStar, pois os processos de verificação

e validação auxiliarão no manuseio da notação textual, além de oferecer informações

quantitativas sobre o modelo em análise. Para que isso seja possível, este trabalho deverá

satisfazer alguns objetivos específicos, são eles:

• Relizar um levantamento bibliográfico sobre análise sintática e semântica das des-

crições textuais do framework iStar;

• Analisar as definições estruturais da notação SMiLe;

Page 18: SMiLeCompiler: Um Analisador Sintático e Semântico para

16

• Modelar o problema utilizando o framework iStar;

• Apresentar um esboço arquitetural para o desenvolvimento da ferramenta a partir

dos requisitos não-funcionais extraídos da modelagem;

• Desenvolver uma ferramenta de suporte aos modelos de dependência estratégica do

framework iStar baseada nos requisitos funcionais;

• Realizar uma avaliação da ferramenta com um estudo de caso.

1.3 Metodologia

Com base no estudo bibliográfico e no levantamento de requisitos funcionais e não fun-

cionais, observou-se a necessidade de compreender conceitos e técnicas sobre compilado-

res. Os conceitos e técnicas foram explorados na literatura disponível sobre compiladores,

descritos na fundamentação teórica e aplicados no desenvolvimento da ferramenta.

O processo de desenvolvimento do SMiLeCompiler se deu através de encontros se-

manais seguindo o processo iterativo e incremental. Em cada encontro apresentava-se o

que havia sido feito durante a semana e definia-se os próximos passos. As primeiras ite-

rações foram focadas na compreensão do contexto no qual esse trabalho está inserido e

na definição de uma proposta arquitetural para a ferramenta. A cada iteração, refinava-se

o entendimento do contexto através de uma modelagem do problema com o framework

iStar. Em posse de uma modelagem mais robusta, os requisitos não-funcionais foram ex-

traídos para propor uma arquitetura juntamente com os requisitos funcionais e a definição

das entradas e saídas da ferramenta.

Com o intuíto de facilitar o desenvolvimento do SMiLeCompiler, foi escolhida uma

ferramenta para abstrair parte da complexidade que envolve a implementação de um

compilador. O ANTLR é um gerador de parsers (PARR, 2013) amplamente utilizado na

comunidade de engenharia de software para o desenvolvimento de compiladores, interpre-

tadores, tradutores e parsers.

Concluído o desenvolvimento da ferramenta, foi feita uma avaliação a partir de um

cenário definido e executado no SMiLeCompiler. Além disso, esse cenário foi utilizado em

outras ferramentas e foram induzidos alguns casos de erro com o intuíto de fazer uma

comparação com as ferramentas executadas e o SMiLeCompiler.

Toda verificação relacionada com as regras dos modelos de dependência estratégica

Page 19: SMiLeCompiler: Um Analisador Sintático e Semântico para

17

realizada pelo SMiLeCompiler foi estabelecida a partir do entendimento das instruções

indicadas nos guias do iStar Wiki1.

1.4 Abordagem da proposta

Este trabalho apresenta uma ferramenta, chamada SMiLeCompiler, cujo objetivo é

aplicar técnicas de análise sintática e semântica nos modelos de dependência estratégica do

framework iStar descritos na notação textual SMiLe (PENHA, 2017). Ademais, ajudar os

Analistas de Requisito e/ou stakeholders envolvidos na análise desses modelos através de

informações quantitativas da modelagem social e propor um mecanismo de transformação

para os modelos iStar.

A ferramenta foi elaborada no contexto da proposta SMiLe, na qual ela já existia como

uma abstração relevante (PENHA, 2017). A proposta SMiLe contém uma base estruturada

de informações sociais. Esse conjunto de informações indicam como as entidades se re-

lacionam, por exemplo: um professor depende da secretaria para conhecer as suas

turmas.

Figura 1: Concepção do SMiLe

Fonte: (PENHA, 2017)

Na Figura 1 observa-se que a proposta SMiLe pretende proporcionar ambientes que

contemplem os benefícios de ambos estilo de modelagem, textual e gráfica. É proposto um1http://istar.rwth-aachen.de

Page 20: SMiLeCompiler: Um Analisador Sintático e Semântico para

18

ambiente para ser utilizado pelos Analistas de Requisitos com uma IDE para visualização

e manipulação dos modelos gráficos e edição e gerência dos arquivos da notação. Na

proposta de Penha (PENHA, 2017), o SMiLeCompiler se enquadra no intermédio entre o

ambiente para dar suporte a atividade de análise de requisitos e os arquivos da notação

textual SMiLe.

A ferramenta proposta neste trabalho visa oferecer os seguintes benefícios: (i) verifica-

ção dos modelos descritos e definidos pela notação textual SMiLe; (ii) realizar a validação

dos modelos de dependência estratégica descritos de acordo com as definições do fra-

mework iStar; (iii) oferecer informações quantitativas para auxiliar a análise do ambiente;

(iv) oferecer um mecanismo de transformação dos modelos SMiLe.

1.5 Estrutura do trabalho

Este trabalho está organizado como segue: o Capítulo 2 reúne os principais concei-

tos necessários para o entendimento do trabalho, tais como o framework iStar, algumas

notações textuais já propostas pela comunidade iStar, conceitos de compiladores e a ferra-

menta de que o SMiLeCompiler é dependente. O Capítulo 3 apresenta a solução proposta,

a arquitetura, requisitos não-funcionais que nortearam a modelagem da arquitetura, os

requisitos funcionais da ferramenta e como utilizá-la. O Capítulo 4 apresenta o cenário

empregado para a demonstração da ferramenta, mostra os resultados obtidos e faz uma

comparação com as ferramentas que apoiam outras notações textuais já propostas para o

framework iStar. Por fim, o Capítulo 5 finaliza este trabalho com as últimas considerações,

as limitações do projeto e possíveis oportunidades de melhorias e evolução.

Page 21: SMiLeCompiler: Um Analisador Sintático e Semântico para

19

2 Fundamentação Teórica

Este capítulo faz explanações sobre conceitos essenciais para o entendimento da fer-

ramenta proposta. Para tanto, a fundamentação teórica está dividida na seguinte forma:

a Seção 2.1 apresenta o framework iStar e algumas notações textuais já propostas pela

comunidade, a Seção 2.2 elucida de uma maneira geral os compiladores e conclui com a

Seção 2.3 apresentando a ferramenta utilizada no desenvolvimento da aplicação.

2.1 Framework iStar

Atualmente, a modelagem social tem se tornado mais relevante do que nunca (YU,

2009). A abordagem proporcionada pelo framework iStar tenta introduzir alguns aspectos

da modelagem social e do raciocínio estratégico em métodos de engenharia de sistemas

de informação, especialmente a nível de requisitos (YU, 2009). Esta abordagem trouxe al-

guns atrativos que, nos últimos anos, vem servindo como incentivo para muitos trabalhos.

Franch identifica esses atrativos como sendo: (i) a abordagem que consegue combinar os

paradigmas de orientação a meta e agente; (ii) tem como foco as propriedades intencio-

nais do ambiente e nos seus relacionamentos ao invés dar atenção aos comportamentos

imediatos (FRANCH, 2012). Por causa disso, o Framework provê uma rica expressividade

que é apropriada para os conceitos sociais do mundo.

O framework iStar articula uma notação de intencionalidades distribuídas em dois

modelos: modelo de Dependência Estratégica (SD) que descreve os relacionamentos de

dependências entre os atores da organização e o modelo de Raciocínio Estratégico (SR)

que descreve as motivações que o ator tem sobre adotar uma ou outra configuração para

atender uma demanda. Através destes modelos é possível delinear, analisar e reconfigurar

as relações com o intuíto de aproveitar os benefícios da abordagem (YU, 1996).

Page 22: SMiLeCompiler: Um Analisador Sintático e Semântico para

20

2.1.1 Modelo de Dependência Estratégica - SD

A Figura 2 apresenta um modelo de Dependência Estratégica que descreve as intenções

do ambiente/processo em termos de uma rede de dependência entre atores (humanos

e/ou dispositivos). Esse modelo intencional captura as intenções através do fluxo e das

atividades evidentes no ambiente. O significado semântico de uma dependência, capturada

neste modelo, é de que um ator (depender) depende de outro ator (dependee) para

alguma coisa (dependum). No momento da definição dessa relação, se o dependee

falhar para entregar o dependum, o depender sofrerá um impacto negativo (YU, 1996).

Figura 2: Representação de um Modelo SD

Fonte: (YU, 1996)

2.1.2 Modelo de Raciocínio Estratégico - SR

O modelo de Raciocínio Estratégico, Figura 3, descreve qual o raciocínio estratégico

do ator através dos elementos intencionais internos. Enquanto o modelo SD mantém um

nível de abstração por revelar os elementos das relações externas entre atores, o modelo

SR realça os elementos internos do ator a fim de permitir um profundo entendimento do

seu raciocínio sobre como pretende atender a alguma relação externa ou a sua motivação

(YU, 1996). Ao expandir um ator que esteja em uma relação de dependência com outro

ator, pode-se observar um conjunto de elementos (goal , task , resource e softgoal)

relacionando-se com a intenção de apresentar as suas motivações. Os principais tipos de

relacionamentos são representados pelas associações means-end e task-decomposition

(YU, 1996).

Com as propostas iStarML, iStarJSON e SMiLe (CARES et al., 2008; BEDOYA et al.,

Page 23: SMiLeCompiler: Um Analisador Sintático e Semântico para

21

Figura 3: Representação de um Modelo SR

Fonte: (YU, 1996)

2016; PENHA et al., 2017), a comunidade iStar vem reconhecendo a necessidade e impor-

tância de uma notação textual para favorecer a abordagem iStar, seja para desempenhar

um papel de apoio na compreensão dos modelos ou assumir uma responsabilidade em

auxiliar no fluxo ferramental. Além da linguagem SMiLe, notação de interesse deste tra-

balho, encontrou-se mais duas notações que buscam, guardada as suas especificidades,

a interoperabilidade entre as extensões dos modelos iStar: iStarML e iStarJSON. Para

melhor esclarecer a motivação deste trabalho, estas notações serão expostas de forma

sucinta.

2.1.3 Notações textuais para framework iStar

iStarML é uma linguagem de marcação baseada em XML que visa a interoperabili-

dade dos modelos iStar com o objetivo de representar as diferenças e semelhanças entre

variações dos modelos iStar. Ou seja, um conjunto comum de conceitos com pontos de

extensão que permite uma conversa entre diferentes dialetos dos modelos iStar (CARES

et al., 2008). Para aumentar as chances de adesão da comunidade, além da interopera-

bilidade, foi orientada por tais requisitos: expressividade, extensibilidade, flexibilidade,

simplicidade, minimidade, estabilidade e filtrabilidade (CARES et al., 2011). Como pode

ser visto na Figura 4, a proposta mistura informações conceituais com dados referentes a

Page 24: SMiLeCompiler: Um Analisador Sintático e Semântico para

22

representação gráfica.

Figura 4: Uma representação do modelo SR no iStarML

Fonte: (CARES et al., 2007)

iStarJSON surge com objetivo de: (i) manter o framework iStar atualizado com

as novas tendências no desenvolvimento de software e (ii) facilitar o desenvolvimento,

contendo um formato de dados flexível e leve para modelos iStar. A iStarJSON foi in-

troduzida como uma linguagem leve de intercâmbio entre modelos iStar e sua notação

foi estruturada para melhor compreender um grafo, permitindo o uso de uma variedade

de ferramentas e algoritmos para sua manipulação (por exemplo, centralidade de nó e

caminho mais curto) (BEDOYA et al., 2016). A Figura 5 apresenta o schema parcial de

iStarJSON e um modelo SD no formato proposto.

SMiLe é uma notação textual de descrição modular dos modelos iStar. Na proposta

SMiLe, a abordagem realiza, através dos próprios modelos do framework iStar, uma abs-

tração modular. Essa abstração é compreendida como complexidade social do ator, com-

posta pelo próprio ator, seus relacionamentos internos e seus relacionamentos externos, e

como um bloco de construção (parte) que compõe uma modelagem social (todo) (PENHA

et al., 2016, 2017).

Diferente das propostas textuais anteriores que tiveram sua enfase em proporcionar

Page 25: SMiLeCompiler: Um Analisador Sintático e Semântico para

23

Figura 5: (a) Schema parcial de iStarJSON e (b) uma representação do modelo SD.

Uma adaptação de: (BEDOYA et al., 2016)

um apoio ferramental, a proposta SMiLe busca oferecer uma alternativa para melhorar

a compreensão dos modelos iStar através dos seguintes requisitos: (i) uma modelagem

composta por blocos inter-relacionados; (ii) uma alternativa textual complementar aos

modelos gráficos; (iii) uma notação textual compreensível por humanos e (iv) estruturada

para máquina (PENHA et al., 2017). A Figura 6 apresenta três complexidades sociais dos

seguintes atores: (a) Paciente, (b) Médico e (c) Plano de Saúde.

Figura 6: Exemplo de modelo SD descrito em SMiLe.

Uma adaptação do: (PENHA et al., 2017)

A notação SMiLe é composta pelo conjunto de arquivos smile que contém a descrição

da complexidade social do ator, nas quais estão diluídas as informações dos modelos SD

e SR do framework iStar. A estrutura da notação se divide em: (i) definição do ator e

as suas associações organizacionais com outros atores; (ii) declarações das dependências

externas na perspectiva depender e dependee; (iii) as definições de como o ator utiliza

os elementos intencionais para atender alguma necessidade (PENHA et al., 2017). Como

a ferramenta descrita nesse trabalho tem como objetivo o suporte aos modelos SD, a

descrição da estrutura da notação terá enfoque na descrições dos itens (i) e (ii) que são

relacionados com esse modelo em questão.

Page 26: SMiLeCompiler: Um Analisador Sintático e Semântico para

24

Figura 7: Exemplo de um arquivo SMiLe contendo a definição do ator, suas associaçõescom outros atores e as declarações de relacionamentos externos.

A Figura 7 mostra um arquivo com a estrutura correta da complexidade social do ator

GerenteDeProjeto. A primeira linha do arquivo contém a definição do ator, com o tipo

position e nome GerenteDeProjeto. O nome do ator deve ser composto por uma string e

o tipo pode conter as palavras: actor, agent, role e position.

A linha seguinte é a definição da associação do ator GerenteDeProjeto com os atores

Monitoramento e Planejamento. A primeira palavra representa o tipo da associação segui-

damente do conjunto (tipo ator) a que ela se refere. Os tipos das associações podem ser:

instanceOf, isPartOf, ocupies, covers, plays e isA. E, devem obedecer as seguintes

regras: isA e isPartOf só devem acontecer entre atores de tipos iguais; instanceOf só deve

ocorrer entre atores com os tipos agent ; apenas o ator do tipo agent pode ter associações

plays e occupies, desde que os atores associados sejam dos tipos role, para a primeira, e

position, para a segunda; apenas o ator do tipo position pode ter uma associação covers

e o ator associado deve ser do tipo role.

Após as associações, dá-se início a descrições das relações externas a partir da palavra

reservada ExternalRelationships. As linhas 5 e 6 definem as relações externas do ator

GerenteDeProjeto na perspectiva depender, ou seja, o ator em questão depende do Diretor

e do DiretorQA para obter reconhecimento e manutenibilidade, respectivamente. Já as

linhas 7, 8 e 9 definem as relações externas na perspectiva dependee, em outras palavras, o

GerenteDeProjeto alcança os itens ProdutoDesenvolvido e entregasRapidas para o Cliente

e o item semExcessoDeGastos para o Diretor.

A estrutura das relações da perspectiva depender deve sempre começar com a palavra

dependesOn seguida do ator e seu tipo, da palavra reservada for e do elemento intencio-

nal. Já a estrutura da perspectiva dependee deve começar com objetivo da relação, seguido

do elemento intencional, da palavra reservada to e de um ator com seu tipo. Os elementos

intencionais são compostos do nome e do tipo, que podem ser: goal, softgoal, task e

resource. Como a perspectiva dependee é um reflexo da perspectiva depender (PENHA

et al., 2017), os objetivos são reflexo do elemento intencional contido na relação e segue

Page 27: SMiLeCompiler: Um Analisador Sintático e Semântico para

25

as seguintes regras: reaches atende aos elementos intencionais dos tipos goal e softgoal ;

provides atente ao elemento intencional do tipo resource; e task atente ao elemento

carriesOut.

2.2 Compiladores

Linguagens de programação são notações que descrevem computação para pessoas e

máquinas. Todo software em execução em qualquer computador foi escrito em alguma

linguagem de programação. No entanto, antes de um programa poder executar, deve ser

traduzido em uma forma na qual pode ser compreendido pelo computador. O sistema de

software que faz essa tradução é chamado compilador (AHO et al., 2007).

O termo compilador foi originalmente cunhado no início dos anos 50 por Grace Murray

Hopper. A tradução era então vista como a compilação de uma sequência de subprogra-

mas de linguagem de máquina selecionados de uma biblioteca. Nessa época, compilação

era chamada programação automática e havia um grande ceticismo de que um dia seria

bem sucedida. Atualmente, a tradução automática de linguagens de programação é um

fato consumado e os tradutores ainda são chamados de compiladores (FISCHER; CYTRON;

LEBLANC, 2009).

Dentre os primeiros compiladores reais na contemporaneidade, estão os compiladores

de Fortran do final dos anos 50. Estes compiladores apresentaram ao usuário uma lin-

guagem de origem orientada a problema e amplamente independente de máquina. Além

do mais, realizaram algumas otimizações com o objetivo de produzir código de máquina

eficiente, uma vez que produzir um código eficiente era considerado um requisito essencial

para que Fortran pudesse competir com Assembly. Linguagens independentes de máquina,

como Fortran, provaram a viabilidade de linguagens de alto nível compiladas e abriram

caminho para a profusão de linguagens e compiladores que vieram a seguir (FISCHER;

CYTRON; LEBLANC, 2009).

2.2.1 O compilador

A rotina de compilação executa todos os serviços necessários para a produção de um

programa final (HOPPER, 1952). De forma simples, um compilador é um programa que

pode ler um programa em uma linguagem – a linguagem de origem – e faz a tradução

para um programa equivalente em outra linguagem – a linguagem de destino. Uma outra

função importante do compilador é de reportar qualquer erro no programa de origem

Page 28: SMiLeCompiler: Um Analisador Sintático e Semântico para

26

detectado durante o processo de tradução. (AHO; SETHI; ULLMAN, 1986)

Figura 8: Um compilador

Fonte: (AHO; SETHI; ULLMAN, 1986)

Na Figura 8 podemos ver o compilador no centro recebendo como input o programa

de origem e reportando como output o programa de destino e as mensagens de erro

processados durante a tradução.

A Figura 8 e sua descrição sugerem que todos os compiladores fazem fundamental-

mente a mesma coisa, sendo a principal diferença a escolha da linguagem de origem e de

destino. No entanto, a situação é um pouco mais complexa. Enquanto a questão do código

de origem aceito ser, de fato, simples, existem várias alternativas em descrever o output

de um compilador. Estas questões vão além de simplesmente nomear um computador es-

pecífico para ser o destinatário. Compiladores podem ser distintos pelo tipo de código de

máquina que geram e pelo formato do código de destino (FISCHER; CYTRON; LEBLANC,

2009).

A compilação é geralmente implementada como uma sequência de transformações

(LO, L1), (L1, L2), ..., (Lk, LD), onde LO é a linguagem de origem e LD a linguagem de

destino. Linguagens intermediárias são ferramentas conceituais usadas na decomposição

da tarefa de compilação a partir da linguagem de origem para a linguagem de destino.

A arquitetura de um compilador em particular determina quais, se houverem, programas

de linguagem intermediária podem aparecer como texto concreto ou estrutura de dados

durante a compilação (WAITE; GOOS, 1985).

2.2.2 A estrutura

Até este ponto, o compilador vem sido tratado como uma simples caixa que faz um

mapeamento do programa de origem em um programa de destino semanticamente equiva-

lente. Mas, observando essa caixa mais de perto, é possível ver que o processo de compila-

Page 29: SMiLeCompiler: Um Analisador Sintático e Semântico para

27

ção é dividido em duas grandes tasks, chamadas análise e síntese (AHO; SETHI; ULLMAN,

1986; WAITE; GOOS, 1985; FISCHER; CYTRON; LEBLANC, 2009).

A parte de análise divide o programa de origem em partes e impõe uma estrutura

gramatical sobre elas. A análise usa essa estrutura para criar uma representação interme-

diária do programa de origem. Se a parte de análise detectar que o programa de origem é

sintática ou semanticamente mal formulado, então deverá fornecer mensagens informati-

vas para que o usuário possa tomar medidas corretivas. A parte de análise também coleta

informações sobre o programa de origem e registra em uma estrutura de dados chamada

de tabela de símbolos, que é passada juntamente com a representação intermediária

para a parte de síntese. A parte de síntese constrói o programa de destino a partir da

representação intermediária e das informações presentes na tabela de símbolos (AHO et

al., 2007).

Se examinarmos o processo de compilação em mais detalhes, podemos ver que o

processo opera em uma sequência de fases sendo, cada uma delas, transformações de uma

representação do programa de origem em outro. A decomposição de um compilador em

fases é mostrada na Figura 9. Na prática, algumas destas fases podem ser agrupadas e

a representação intermediária que ocorre entre estas fases não precisam ser construídas

explicitamente. A tabela de símbolos é usada por todas as fases do compilador. Como

a otimização não é uma tarefa obrigatória, as fases de otimização Otimizador de Código

Independente de Máquina e Otimizador de Código Dependente de Máquina podem não

estar presentes em um compilador (AHO et al., 2007).

• Análise Léxica. A primeira fase é chamada análise léxica ou escaneamento. O

analisador léxico, ou lexer, lê a stream de caracteres que constitui o programa de

origem e agrupa esses caracteres em sequencias significativas chamadas lexemes.

Para cada lexeme, o analisador léxico produz uma token no formado chave-valor.

• Análise Sintática. A segunda fase é chamada de análise sintática ou parseamento.

O parser usa as tokens produzidas pelo analisador léxico para criar uma representa-

ção intermediária em formato de árvore que descreve a sua estrutura gramática. Uma

representação comum é a árvore de sintaxe, cada nó representa uma operação e

o nó filho os argumentos desta operação.

• Análise Semântica. O analisador semântico usa a árvore de sintaxe e a tabela

de símbolos para checar a consistência semântica do programa de origem com a

definição da linguagem. Também reúne informações de tipo e salva na árvore de

Page 30: SMiLeCompiler: Um Analisador Sintático e Semântico para

28

Figura 9: As fases de um compilador

Fonte: (AHO et al., 2007)

sintaxe ou na tabela de símbolos. Uma importante parte dessa fase é a checagem de

tipo (type checking).

• Gerador de Código Intermediário. Durante o processo de tradução de um pro-

grama de origem em um programa de destino, o compilador pode construir uma ou

mais representações intermediárias que podem ter diferentes formatos. As árvores

de sintaxe são uma forma de representação intermediária.

• Otimização de Código. A fase Otimizador de Código Independente de Máquina

procura melhorar o código intermediário, de modo que o compilador possa gerar

código final melhorado. Geralmente, melhor quer dizer mais rápido, mas outros

objetivos podem ser desejáveis, como um código menor (com menos linhas) ou que

consume menos recursos. Já a fase Otimizador de Código Dependente de Máquina

tenta aplicar alguma dessas melhorias já embasado no código de máquina, ou código

final.

Page 31: SMiLeCompiler: Um Analisador Sintático e Semântico para

29

• Geração de Código. O gerador de código recebe como entrada uma representa-

ção intermediária do programa de origem e faz o mapeamento para a linguagem de

destino. Se a linguagem de destino é código de máquina, por exemplo, o compila-

dor vai selecionar registradores ou locais de memória para cada uma das varáveis

usadas pelo programa. Desta forma, as instruções intermediárias são traduzidas em

sequencias de instrução de máquina que performam as mesmas tarefas.

A Figura 10 apresenta todas as fases de uma compilação e seus códigos intermediários

a partir de uma declaração de variável (programa de origem) e o código de máquina

(programa de destino).

position = initial + rate ∗ 6 (2.1)

Figura 10: Exemplo de fases de um compilador

Fonte: (AHO et al., 2007)

Page 32: SMiLeCompiler: Um Analisador Sintático e Semântico para

30

2.3 ANTLR

Atualmente, um desenvolvedor de software pode usar ambientes de desenvolvimento

que contém diversas ferramentas, como editores de linguagem, debuggers, controladores

de versão, etc. Mas, além dessas, outras ferramentas mais especializadas tem sido criadas

para ajudar na implementação das diferentes fases de um compilador. As ferramentas

mais usadas na construção de um compilador incluem: geradores de parser, geradores de

scanner, engines de tradução sintaxe-direcionada, geradores de código, engines de análise

de fluxo de dados e toolkits de construção de compilador (AHO et al., 2007).

Para o desenvolvimento do SMiLeCompiler, foi utilizado a ferramenta ANTLR, com

o objetivo de facilitar a implementação. ANTLR é um gerador de parser que pode ser

usado para ler, processar, executar ou traduzir textos ou arquivos binários.

A partir de uma descrição formal da linguagem, chamada gramática, o ANTLR

gera um parser para a linguagem, esse parser é capaz de construir parse trees, que são

a estrutura de dados que representam como a gramática corresponde com o input. Em

outras palavras, o parser constrói a árvore de sintaxe. Além do mais, o ANTLR gera

automaticamente tree walkers que podem ser usados para visitar os nós das árvores de

sintaxe (PARR, 2013).

Figura 11: ANTLR, reconhecendo uma linguagem

Fonte: (PARR, 2013)

A Figura 11 ilustra o fluxo de dados para reconhecer a linguagem especificada a partir

de um input. Logo abaixo está a gramática que condiz com a sub árvore assign monstrada

na imagem:

Código 2.1: Gramática condizente a Figura 11

1 a s s i gn : ID ’=’ expr ’ ; ’ ; // corresponde a " sp = 100;"

2 expr : INT ; // expressao d e f i n i d a por INT

3 ID : [ a−z ]+ ; // um ou mais ca ra c t e r e s de a−z

4 INT : [0−9]+ ; // um ou mais i n t e i r o s de 0−9

Page 33: SMiLeCompiler: Um Analisador Sintático e Semântico para

31

A gramática definida corresponde a uma declaração de atribuição como sp = 100;.

A partir da especificação da estrutura da frase e uma lista de regras é gerada a árvore de

sintaxe, a sub árvore da raiz corresponde aos nomes das regras da gramática.

Page 34: SMiLeCompiler: Um Analisador Sintático e Semântico para

32

3 SMiLeCompiler: Um AnalisadorSintático e Semântico

A ferramenta proposta neste trabalho está inserida dentro do contexto SMiLe. O

SMiLeCompiler é um compilador de arquivos no formato SMiLe que foi definido por

Penha (PENHA, 2017). Este compilador assume um papel fundamental para garantir a

corretude das informações nas abordagens que venham a utilizar a definição SMiLe como

base para desenvolver os modelos gráficos do framework iStar.

Neste trabalho, a análise sintática se refere a análise de corretude da gramática da

notação textual SMiLe, já a validação das regras da notação iStar descritas na notação

SMiLe são realizadas na análise semântica.

Para melhor compreender a responsabilidade fundamental desse papel assumido pelo

SMiLeCompiler, o trabalho realizou uma análise do contexto no qual o compilador está

inserido.

Figura 12: Modelo SD da Concepção SMiLe com ênfase no SMiLeCompiler

A Figura 12 apresenta um dos modelos do framework iStar baseado na proposta de

Page 35: SMiLeCompiler: Um Analisador Sintático e Semântico para

33

Yu (YU, 1996). Este modelo SD apresenta as relações dos elementos diante da concep-

ção SMiLe apresentada por Penha (PENHA, 2017), com enfoque no SMiLeCompiler que

engloba o lado direito da imagem dividida pela linha. Neste sentido, os atores IDE e De-

senvolvedor relacionam-se com o SMiLeC (SMiLeCompiler) motivados pelos elementos

que desejam, como análise quantitativa e usabilidade. Por sua vez, o SMiLeC relaciona-

se com o ANTLR para abstrair a complexidade de algumas das fases realizadas em um

compilador, e relaciona-se também com a IDE para obter os arquivos SMiLe.

Figura 13: Entradas e saídas processadas pelo SMiLeCompiler

O SMiLeCompiler, observado na Figura 13, é um pacote java de código aberto que uti-

liza técnicas de compiladores para realizar análise sintática e semântica de arquivos SMiLe

com o propósito gerar as seguintes saídas do modelo apresentado: (i) uma transformação

para a iStarML, (ii) uma análise quantitativa dos elementos existentes e (iii) obter in-

formes sobre erros e avisos. Código e licensa podem ser encontrados em seu repositório

público1. Neste pacote está compreendido o conjunto de funcionalidades e características

que foram extraídas da modelagem observada na Figura 12, intitulado SMiLeCompiler, é

apresentado neste capítulo com mais detalhes nas seguintes seções: a Seção 3.1 apresenta

a proposta arquitetural e os requisitos não funcionais que guiaram o desenvolvimento; na

Seção 3.3 são apresentados os requisitos funcionais e são feitas demonstrações de uso para

cada funcionalidade.

3.1 Proposta arquitetural

A arquitetura de software é uma lista das principais decisões de design feitas durante

o desenvolvimento de software e sua evolução (TAYLOR; MEDVIDOVIC; DASHOFY, 2009).

Segundo Lawrence Chung, a complexidade de um software é determinada parte por seus

requisitos funcionais e parte por seus requisitos globais de desenvolvimento, como custo

operacional, performance, confiabilidade, manutenibilidade, portabilidade, robustez, e as-

sim em diante. Esses requisitos globais, compreendidos também como não funcionais,1https://github.com/andrezacm/smile-compiler

Page 36: SMiLeCompiler: Um Analisador Sintático e Semântico para

34

representam uma função crítica no desenvolvimento do sistema, servindo como critério de

seleção para as decisões de design (CHUNG et al., 2012). Sommerville reforça esse enten-

dimento ao afirmar que a produção de um software de qualidade depende das escolhas

realizadas durante o desenvolvimento que são diretamente influenciadas pelos requisitos

não funcionais (SOMMERVILLE, 2011).

Figura 14: Proposta arquitetural do SMiLeCompiler

A Figura 14 apresenta a arquitetura, que é composta por três pacotes internos –

domain, services e listeners – com responsabilidades bem definidas, pelo ANTLR e por

uma interface chamada SmileCompiler.

Figura 15: Definição da interface de comunicação com o SMiLeCompiler

A interface do SMiLeCompiler tem como objetivo a comunicação com o usuário, é

através dela que é possível fornecer as entradas para a ferramenta processar e obter as

saídas. A Figura 15 apresenta a definição da API dessa interface, é possível ver a assinatura

de todos os métodos utilizáveis pelo usuário, os parâmetros e o retorno de cada um deles.

Os detalhes sobre a utilização da interface e suas as funcionalidades são descritos na Seção

3.3.

Page 37: SMiLeCompiler: Um Analisador Sintático e Semântico para

35

O pacote domain é responsável pela definição do domínio da aplicação. É nesse pa-

cote que podemos ver toda a estrutura da representação intermediária da linguagem que

o compilador vai gerar, permitindo que as validações semânticas sejam possíveis, mais

detalhes sobre o domínio serão apresentados na Seção 3.2. A Figura 16 mostra todas as

classes do domínio e as factories do sistema com seus relacionamentos.

Figura 16: Estrutura do pacote domain

O pacote services contém todas as classes que são responsáveis por executar alguma

tarefa específica para o SMiLeCompiler. Como é mostrado na Figura 17, é nele que estão

as classes responsáveis pelas validações semânticas do domínio, as classes de verificação

dos limites máximos do modelo, as classes de gerência das mensagens de erros e alertas,

o tradutor para iStarML, além de algumas outras classes de suporte como o IDHandler

que gerencia os IDs dos atores referenciados no modelo.

Figura 17: Estrutura do pacote services

O pacote listeners é responsável pela comunicação entre o ANTLR e a ferramenta. O

ANTLR gera um lexer e um parser a partir das regras definidas na gramática, que pode

ser encontrada no Apêndice A, que vão transformar o texto em uma árvore de sintaxe.

Page 38: SMiLeCompiler: Um Analisador Sintático e Semântico para

36

Conforme o ANTLR percorre a árvore de sintaxe ele notifica os listeners toda vez que

encontra uma regra correspondente. Quando notificado, um listener executa alguma ação

relacionada com a informação recebida do ANTLR com o objetivo de criar a representação

intermediária do modelo como, por exemplo, instanciar um novo ator. Na Figura 18

podemos ver a estrutura do pacote com todos os listeners que ele contém.

Figura 18: Estrutura do pacote listeners

Esta proposta arquitetural foi conduzida por cinco requisitos não funcionais que são

explicados logo em seguidas através dos seus conceitos e de como a arquitetura os supor-

tam.

RNF1. Portabilidade

A portabilidade de um sistema é relacionada ao esforço aplicado durante a sua migra-

ção de um sistema operacional, ou ambiente de desenvolvimento, para outro (WIEGERS;

BEATTY, 2013). Algumas das formas de medir a portabilidade de software pode dar-se

através da quantidade de dependências externas e o número de sistemas alvo para os quais

o software é desenvolvido (SOMMERVILLE, 2011).

Com o objetivo de ter um sistema portável, o SMiLeCompiler foi desenvolvido uti-

lizando a linguagem Java2, tornando o software independente de plataformas e sistemas

operacionais. Além disso, o sistema possui apenas uma dependência de softwares de ter-

ceiros (ANTLR3), e utiliza o Gradle4 como ferramenta de automação de build.

RNF2. Usabilidade

A usabilidade de um sistema se reflete em o quão fácil de usar ele é. Fazer um sistema

de fácil uso significa provê uma simples interface que seja de fácil entendimento. A usabi-

lidade é afetada por fatores subjetivos, como a experiencia do usuário, de modo que não

podem facilmente ser medidos de forma objetiva (SOMMERVILLE, 2011).2https://www.oracle.com/java/index.html3www.antlr.org4https://gradle.org/

Page 39: SMiLeCompiler: Um Analisador Sintático e Semântico para

37

Para tornar o SMiLeCompiler um pacote de fácil uso para os desenvolvedores que

pretendem utilizá-lo, uma interface simples e concisa foi projetada para o desenvolvedor

instanciá-la e ter acesso a suas funcionalidades informando apenas o diretório de origem

dos arquivos SMiLe.

RNF3. Manutenibilidade

Manutenibilidade se refere a um software que é de fácil manutenção. Novos requisitos

podem emergir de acordo com o uso de um sistema, e é importante que o sistema possa

manter suas funcionalidades em funcionamento enquanto é alterado para acomodar esses

novos requisitos. Um software é considerado de fácil manutenção quando é economica-

mente adaptável a novos requisitos e, além disso, existe uma pequena probabilidade de

que as mudanças inseridas possam introduzir novos erros (SOMMERVILLE, 2011). Assim

como a usabilidade, a manutenibilidade não pode ser medida de forma objetiva, depen-

dendo de medidas de atributos internos relacionados com suas características, como a

complexidade.

Para facilitar a tarefa de manutenção do SMiLeCompiler, como já visto, o sistema foi

dividido em três pacotes com responsabilidades bem específicas.

RNF4. Tolerância a erros

Tolerância a erros é uma propriedade que pode ser considerada como parte da pro-

priedade de usabilidade e reflete a modo com que o sistema foi planejado para que erros

inseridos por input de usuário possam ser evitados e tolerados. De modo que, quando

um erro de usuário acontecer o sistema possa detectá-lo e corrigi-lo ou indicar ao usuário

o erro e solicitar que este reinsira os dados sem que esses erros resultem em falhas do

sistema (SOMMERVILLE, 2011).

Com o intuito de fazer um sistema com tolerância a erros, foi desenvolvido um serviço

chamado ErrorHandler. Todos os erros identificados nos arquivos SMiLe, tanto durante

a análise sintática quanto na análise semântica, são reportados para o ErrorHandler de

modo que a aplicação possa continuar sua análise e devolver esses erros para o usuário

sem que a aplicação falhe.

RNF5. Reusabilidade

O reuso de um software é relacionado ao quão fácil ele pode ser usado por outros

softwares, ou o quão fácil é converter este sistema para uso em outro sistema (CHUNG et

al., 2012). Também é considerado como um atributo que não pode ser medido de forma

objetiva.

Page 40: SMiLeCompiler: Um Analisador Sintático e Semântico para

38

Um dos principais objetivos do SMiLeCompiler é que possa ser utilizado futuramente

no desenvolvimento de outras ferramentas que darão suporte a linguagem SMiLe. Então, é

de suma importância que atenda o requisito de reusabilidade. Para que isso fosse possível,

o SMiLeCompiler foi desenvolvido como um pacote, podendo ser facilmente incorporado

em qualquer aplicação que deseje utilizá-lo.

Figura 19: As fases do SMiLeCompiler

Assim como um compilador comum, como vimos na Seção 2.2 e na Figura 9, o SMi-

LeCompiler opera em uma sequência de fases que realizam transformações como podemos

ver na Figura 19. Tendo como ponto de partida o diretório com os arquivos SMiLe, pas-

sando pelo leitor de arquivos, pelas análises léxica, sintática e semântica, pelo tradutor, e

finalizando na geração de código iStarML.

3.2 Modelo semântico

O modelo semântico é representado no SMiLeCompiler pelas classes de domínio de-

finidas dentro do pacote domain. A Figura 20 apresenta as principais classes de domínio

que compõem o modelo semântico. A entidade principal é o Ator que pode ser dos tipos

actor, agent, position e role. O Ator pode ter várias relações de Associação com outros

Page 41: SMiLeCompiler: Um Analisador Sintático e Semântico para

39

Atores, essas Associações podem ser dos tipos covers, isA, instanceOf, accupies e plays.

O Ator também pode ter várias Relações Externas que são constituídas de Dependências

com outros Atores. Essas Dependências podem ser dos tipos goal, resource, softgoal e task,

tendo as perspectivas carriesOut, dependsOn, provides, e reaches.

Figura 20: Diagrama de classe das principais classes de domínio da aplicação

3.3 Funcionalidades e modo de uso

Requisitos funcionais são declarações de serviços que o sistema deve prover, como

o sistema deve reagir dado um determinado input e como deve se comportar em uma

situação em particular. Os requisitos não especificam apenas os serviços ou as features

que foram solicitados, especificam também funcionalidades necessárias que garantem que

os serviços e as features serão entregues apropriadamente (SOMMERVILLE, 2011).

Page 42: SMiLeCompiler: Um Analisador Sintático e Semântico para

40

De acordo com os objetivos do SMiLeCompiler, foram definidos requisitos funcionais

que o sistema deve alcançar para resolver o problema apresentado na seção 1.1. Com

base nesses requisitos, foram desenvolvidas funcionalidades para garantir que o sistema

atingisse seus objetivos. Essa seção irá apresentar os requisitos que foram levantados, as

funcionalidades geradas a partir destes e a forma de utilização.

RF1. O sistema deve ser capaz de trabalhar com diversos arquivos SMiLe

de uma vez, sem que o usuário tenha que informar o nome e a localização de

cada um desses arquivos.

- Leitura de arquivos

O SMiLeCompiler irá realizar a leitura de vários arquivos SMiLe que estiverem pre-

sentes em um mesmo diretório. Este diretório deverá ser informado pelo usuário. Para

tanto, deve-se criar uma nova instância do SMiLeCompiler informando em qual diretório

se encontram os arquivos SMiLe que deseja compilar.

Código 3.1: Instanciando SMiLeCompiler e definindo diretório alvo

1 // Def inindo o d i r e t o r i o

2 St r ing path = "/User/ user /workspace/ sm i l e_ f i l e s /"

3

4 // Ins tanc iando o compi lador

5 SmileCompiler compi le r = new SmileCompiler ( path ) ;

Para utilizar qualquer recurso de análise e verificação, ou qualquer uma das funciona-

lidades definidas a seguir, o usuário deve instruir ao SMiLeCompiler que faça a compilação

dos arquivos SMiLe. Esta função executará todas as fases do compilador que foram apre-

sentadas na Figura 19.

Código 3.2: Compilando os arquivos SMiLe

1 // Compilando os arqu i vos SMiLe

2 compi le r . compi le ( ) ;

RF2. O sistema deve ter um método de controle de elementos, de modo

que este não deve permitir a inserção de atores repetidos e atores diferentes

não devem ter o mesmo nome de identificação.

- Verificação do nome do arquivo

Page 43: SMiLeCompiler: Um Analisador Sintático e Semântico para

41

Cada arquivo SMiLe contém a descrição de apenas um ator, sendo assim, o nome

do arquivo deve ser representativo contendo o nome do ator e a extensão .smile. Dessa

forma, o próprio sistema operacional não permitirá que arquivos diferentes tenham o

mesmo nome. No caso do nome do arquivo não ser igual ao nome do ator representado

por ele, o sistema adiciona uma mensagem na lista de erros para este caso.

Exemplo:

Um arquivo com a definição position DiretorQA e com o nome Diretor.smile irá

apresentar a seguinte mensagem de erro:

the file Diretor.smile should have the

same name as the actor on it: DiretorQA

RF3. O sistema deve indicar qualquer inconsistência entre os arquivos SMiLe

informados pelo usuário e a estrutura definida de um arquivo SMiLe correto.

- Análise Léxica e Sintática

O sistema irá realizar uma análise léxica e sintática para identificar erros na estrutura

do arquivo e erros de gramática na escrita da notação SMiLe. Todos os erros identificados

serão inseridos na lista de erros.

Exemplo:

O erro de sintaxe inserido pelo texto isartOf ( agent ProfissionalDeSoftware )

no arquivo irá mostrar a seguinte mensagem de erro:

error on [actorStatement] line 3:1 at [@9,51:57=’isartOf’,<25>,3:1]:

extraneous input ’isartOf’ expecting

{’covers’, ’isA’, ’instanceOf’, ’isPartOf’, ’occupies’, ’plays’, NL}

RF4. O sistema deve verificar se as relações dos elementos fazem sentido,

seguindo as regras definidas pelo iStar.

- Análise semântica

Todas as verificações que fogem do escopo da notação textual SMiLe e entram no

escopo do iStar são consideradas como parte da análise semântica nessa ferramenta. Pen-

sando nisso, a análise semântica irá verificar a validade das associação e das relações

externas de cada ator, para cada erro identificado o sistema irá adicionar uma mensa-

gem na lista de erros. Para que isso seja possível, a análise semântica foi divida em três

funcionalidades menores que serão descritas a seguir.

Page 44: SMiLeCompiler: Um Analisador Sintático e Semântico para

42

- Verificação de erros nas associações

Verifica a validade das associações dos atores, checando o tipo da associação e o atores

a que ela se refere.

Exemplo:

A associação definida no agent Testador por isA ( position Diretor ) irá mos-

trar a mensagem de erro:

failed association on Testador.smile:

isA ( position Diretor ) at line 2:1 till line 2:43

- Verificação de erros nas relações externas

Verifica a validade das relações externas percorrendo as relações na entidade depen-

dente procurando sua relação equivalente nos atores em que este depende, checando tam-

bém o tipo das dependências.

Exemplo:

A dependência declarada nas relações externas do position Diretor por dependsOn

( position GerenteDeProjeto ) for ( softgoal semExecessoDeGastos ) e atendida

pelo position GerenteDeProjeto por provides ( softgoal semExecessoDeGastos)

to ( position Diretor ) vai mostrar a mensagem de erro:

failed dependency on Diretor.smile:

dependsOn (GerenteDeProjeto) for (softgoal semExecessoDeGastos)

at line 7:1 till line 7:51

- Verificação da existência de um ator

Esta checagem ocorre durante as verificações de associações e relações externas. Para

cada associação ou relação externa, o ator a quem ela se refere tem sua existência ave-

riguada, de modo que este ator deve estar presente no domínio da aplicação e ter um

arquivo com sua definição descrita.

Exemplo:

A associação descrita por isA ( agent ProfissionalDeSoftware ) na descrição do

ator Testador faz uma referência ao ator ProfissionalDeSoftware que não possui um

arquivo SMiLe contendo sua descrição, vai mostrar a mensagem de erro:

missing actor definition on Testador.smile:

agent ProfissionalDeSoftware at line 2:25 till line 2:31

Page 45: SMiLeCompiler: Um Analisador Sintático e Semântico para

43

RF5. O sistema deve oferecer ferramentas para que o usuário possa reali-

zar uma análise quantitativa. Além de uma possibilidade de configuração que

determine a quantidade de relacionamentos que fogem o padrão do ambiente

em análise.

- Verificação dos limites máximos

O sistema permite que o usuário, antes de compilar os arquivos, determine um número

de limite máximo que um ator pode ter para as suas associações, para as suas dependências

externas com outros atores e para as dependências que esse ator pode atender para outros

atores. O sistema irá verificar, para cada ator, se esses limites são respeitados. Para cada

limite ultrapassado o sistema adiciona um alerta.

Antes da compilação, o usuário pode especificar os limites máximos que preferir, sendo

estes os parâmetros: número máximo de associações, número máximo de dependências com

outros atores e número máximo de dependências que pode atender para outros atores,

respectivamente. Esta configuração não é obrigatória.

Código 3.3: Especificando os limites máximos

1 // Espec i f i cando os l im i t e s maximos

2 compi le r . s e tCon f i gu ra t i on (5 , 3 , 2) ;

Exemplo:

Com o limite de associações especificado como três, o agent ProfissionalDeSoftware

tendo em sua definição um total de quatro associações, irá resultar na mensagem de alerta:

number of associations on ProfissionalDeSoftware exceeded the limit of 3

- Gerenciamento de informações quantitativas totais

O usuário pode recuperar as informações quantitativas totais do ambiente em análise,

que são a quantidade de todos os atores presentes, a soma da quantidade de associações

entre os atores e a soma da quantidade de relações externas de cada ator.

Código 3.4: Acessando informações quantitativas totais do ambiente em análise

1 // Acessando informacoes q u an t i t a t i v a s t o t a i s

2

3 // Tota l de a to r e s compi lados

4 compi le r . getNumberOfActors ( ) ;

5

6 // Tota l de a s soc i a coe s para todos os a to r e s compi lados

Page 46: SMiLeCompiler: Um Analisador Sintático e Semântico para

44

7 compi le r . getNumberOfAssociations ( ) ;

8

9 // Tota l de r e l a c o e s ex t e rnas para todos os a to r e s compi lados

10 compi le r . getNumberOfExternalRelat ionships ( ) ;

- Gerenciamento de informações quantitativas por ator

O usuário pode recuperar as informações quantitativas de cada ator do ambiente em

análise. Os dados disponíveis são: quantidade de associações, quantidade de dependências

que esse ator tem com outros atores, e quantidade de dependências que esse ator atende

para outros atores.

Código 3.5: Acessando informações quantitativas de cada ator

1 // Acessando informacoes q u an t i t a t i v a s de cada ator

2

3 // Acessando cada ator

4 compi le r . getActors ( ) . forEach ( ac to r −> {

5

6 // Numero de a s soc i a coe s

7 ac to r . getNumberOfAssociations ( ) ;

8

9 // Numero de dependencias com outros a to r e s

10 ac to r . getNumberOfDependerRelationships ( ) ;

11

12 // Numero de dependencias que e s s e a tor atende

13 ac to r . getNumberOfDependeeRelationships ( ) ;

14 }) ;

RF6. O sistema deve disponibilizar ao usuário uma forma de verificar as

mensagens de erro.

- Gerenciamento das mensagens de erro

O SMiLeCompiler gerencia as mensagens de erro de modo que o sistema não falhe

durante sua execução. Todos os erros que ocorrerem durante a execução do compilador

ou forem identificados durante as análises dos arquivos SMiLe são inseridos em uma lista

que pode ser recuperada pelo usuário.

Código 3.6: Acessando os erros

Page 47: SMiLeCompiler: Um Analisador Sintático e Semântico para

45

1 // Acessando os er ros

2 compi le r . g e tEr ro r s ( ) ;

- Gerenciamento das mensagens de alerta

Além das mensagens de erro, o SMiLeCompiler gerencia as mensagens de alerta que o

sistema identifica durante a verificação dos limites máximos. Todos os alertas encontrados

nessa verificação são inseridos em uma lista que pode ser recuperada pelo usuário.

Código 3.7: Acessando os alertas

1 // Acessando os a l e r t a s

2 compi le r . getWarnings ( ) ;

RF7. O sistema deve ser facilmente integrado a ferramentas da comunidade

iStar.

- Transformação para iStarML

Transforma as informações fornecidas no formato SMiLe para o formato iStarmML.

Código 3.8: Acessando iStarML

1 // Acessando iStarML

2 compi le r . toXML( ) ;

Page 48: SMiLeCompiler: Um Analisador Sintático e Semântico para

46

4 Aplicação do SMiLeCompiler

Com o objetivo de avaliar o SMiLeCompiler, esse capítulo apresenta um cenário para

demonstração da ferramenta, expõe os resultados coletados na execução desse cenário e,

para concluir, faz uma comparação com duas ferramentas existentes que apoiam outras

notações textuais presentes na comunidade iStar.

4.1 Apresentação do cenário

Figura 21: Modelo SD de um cenário de desenvolvimento de software

Uma adaptação de: (YU, 1996)

Page 49: SMiLeCompiler: Um Analisador Sintático e Semântico para

47

Para demonstrar a realização do SMiLeCompiler, esta proposta adaptou uma mode-

lagem organizacional de um processo de software apresentado na tese de Yu (YU, 1996).

Na Figura 21 a modelagem é observada através de um conjunto de atores organizacionais

que estão trabalhando em um desenvolvimento cooperativo. Estes atores dependem uns

dos outros para alcançar uma meta (goal), executar uma tarefa (task) e/ou prover um

determinado recurso (resource).

Para exemplificar o modelo SD apresentado na Figura 21 descrito na notação textual

SMiLe, a proposta optou por apresentar na Figura 22 apenas três atores com as suas

relações e associações de acordo com o que foi modelado. Em ambos os estilos, notação

gráfica e textual, é possível identificar detalhes sobre as relações, como por exemplo: (i) a

posição Diretor depende do Cliente para obter o recurso necessário para a realização

do projeto, (ii) o ator Cliente dependente do GerenteDeProjeto para alcançar entregas

rápidas e (iii) o GerenteDeProjeto depende do Diretor para ter o seu trabalho reco-

nhecido. E sobre as associações, como: (i) a posição GerenteDeProjeto cobre as regras

Monitoramento e Planejamento. Baseado nessa modelagem, o SMiLeCompiler faz uma

análise de corretude entre as associações e as relações dos atores.

Figura 22: Modelo SD parcial do cenário de desenvolvimento de software em SMiLe

Todos os arquivos SMiLe utilizados na modelagem desse cenário podem ser visualiza-

dos no Apêndice B.

4.2 Informações quantitativas

Além de analisar as relações e associações dos atores no sentido sintático e semântico,

o SMiLeCompiler também oferece informações quantitativas gerais e específicas sobre o

objeto de estudo para o usuário. De posse desses dados, o Analista de Requisitos pode

pode realizar uma analise quantitativa do ambiente em questão. Por exemplo, de posse

desses dados o analista pode ver quais atores possuem mais associações, quais atore pos-

Page 50: SMiLeCompiler: Um Analisador Sintático e Semântico para

48

suem muitas dependências, ou até identificar atores que possuem muitas responsabilidades

(muitas relações na perspectiva dependee).

4.2.1 Informações quantitativas totais

Tabela 1: Cenário: informações quantitativas totais

Quantidade total de atores 13Quantidade total de associações 8Quantidade total de relacionamentos externos 10

O sistema fornece ao usuário a possibilidade de acessar as informações quantitativas

totais do ambiente, sendo elas: a quantidade total de atores descritos, a quantidade total

de associações definidas nesses atores e a quantidade total de relacionamentos externos

nas quais esses atores estão envolvidos. É apresentado na Tabela 1 os valores retornados

pelo sistema para o cenário apresentado na Seção 4.1.

4.2.2 Informações quantitativas específicas

Da mesma maneira que o sistema oferece informações quantitativas totais sobre o

ambiente em análise, também fornece informações quantitativas específicas sobre cada

ator descrito, correspondendo a: quantidade de associações, quantidade de relações em

que este ator depende de outros e quantidade de relações que esse ator atende para

outros. Na Tabela 2 podemos observar os dados coletados durante a análise pelo sistema

para o cenário definido na Seção 4.1.

Tabela 2: Cenário: informações quantitativas específicas por ator

Associações Depender DependeeEspecialistaQA 1 1 0GerenteDeProjeto 2 2 3Planejamento 0 0 2ProfissionalDeSoftware 1 0 0DiretorQA 0 0 3PerfilDiretoria 1 0 0Andreza 1 0 0PerfilTecnico 0 1 1Diretor 0 2 1Desenvolvedor 1 0 0Testador 1 0 0Cliente 0 2 2Monitoramento 0 2 0

Page 51: SMiLeCompiler: Um Analisador Sintático e Semântico para

49

4.2.3 Limites de relacionamentos e associações

Para o cenário definido na Seção 4.1 foram definidos os limites máximos como apre-

sentados na Tabela 3.

Tabela 3: Cenário: número máximo de associações e relacionamentos externos

Número máximoAssociações por ator 1Relações de dependência com outros atores 2Relações de dependência que atende para outros atores 2

Com os limites especificados, o sistema pôde fazer uma verificação e apontar os atores

que não obedecem o comportamento indicado. Como podemos ver nos resultados mos-

trados no Código 4.1, o número de associações no GerenteDeProjeto excedeu o limite

determinado, o número de relacionamentos externos do GerenteDeProjeto na perspectiva

dependee também excedeu o limite, assim como o DiretorQA.

Código 4.1: Cenário: análise quantitativa de limites máximos

1 number o f a s s o c i a t i o n s on GerenteDeProjeto exceeded the l im i t

o f 1

2 number o f dependee r e l a t i o n s h i p s on GerenteDeProjeto exceeded

the l im i t o f 2

3 number o f dependee r e l a t i o n s h i p s on DiretorQA exceeded the

l im i t o f 2

Essas configurações podem ser úteis para o Analista de Requisitos de maneira que,

para o cenário em análise e com posse dos dados quantitativos, o Analista identificou

que um ator com mais de um determinado número de relações externas na perspectiva

dependee é provavelmente um ator que está sendo sobrecarregado de responsabilidades e

deseja ser notificado quando o sistema identificar algum ator nessa situação. Da mesma

forma, o Analista pode identificar que a partir de um número específico de relações na

perspectiva depender o ator é muito dependente de outros atores e quer que o sistema

o notifique nesses casos para que, por exemplo, possa refatorar esse ator. Essa mesma

estratégia pode ser também utilizada para a quantidade de associações entre atores.

Page 52: SMiLeCompiler: Um Analisador Sintático e Semântico para

50

4.3 Transformação para iStarML

Assim como é esperado que um compilador comum realize a tradução de uma lin-

guagem de origem para uma linguagem de destino, o SMiLeCompiler faz a tradução dos

modelos em SMiLe para iStarML.

A escolha da notação iStarML como linguagem de destino para tradução dos modelos

SMiLe se deu pelos seguintes motivos: (i) iStarML está consolidada na comunidade, isso

proporcionou o desenvolvimento de um conjunto de ferramentas que trabalham com essa

notação; (ii) iStarML Resources1 oferece um suporte oficial com um guia de referência

da notação, um plugin para integração com jUCMNav e um pacote Java para criação,

importação e manipulação dos arquivos iStarML de acordo com a versão 1.0 do iStarML;

(iii) a sua estrutura suporta informações gráficas, como por exemplo: posição na tela,

tamanho e formato, e permite a especificação de mais de um diagrama.

Figura 23: Parte do arquivo resultante da tradução para iStarML

O processo de tradução se dá a partir da representação intermediária dos modelos

SMiLe mapeados no pacote domain. As entidades presentes no domínio da aplicação são

processadas pelo tradutor e transformadas na notação iStarML. A Figura 23 mostra parte1http://www.upc.edu/gessi/istar/tools/istarml/resources.html

Page 53: SMiLeCompiler: Um Analisador Sintático e Semântico para

51

do documento iStarML gerado na tradução dos modelos SMiLe especificados no cenário

de estudo. É possível visualizar o arquivo completo no Apêndice C.

4.4 Comparação com outras ferramentas

Assim como existem diferentes notações textuais para o framework iStar, existem

ferramentas desenvolvidas pela comunidade para o suporte dessas notações, no contexto

desse trabalho, foram discutidas, além da SMiLe, as notações iStarML e iStarJSON,

mostrado no Capítulo 2. As ferramentas são ccistarml e iStarJSON que, respectivamente,

funcionam como validadores dos modelos iStarML e iStarJSON Project.

Com o objetivo de fazer um estudo comparativo entre essas ferramentas e o SMiLe-

Compiler, foi feito o download do código de ccistarml(v0.7)2 e foi utilizado o serviço web

da ferramenta iStarJSON Project3. A execução de ambas as ferramentas se deu de acordo

com as instruções de cada uma, respectivamente, o tutorial disponível na página oficial4

e o arquivo README.md na página do repositório5. Além disso, foi feita uma análise

superficial dos códigos disponíveis e o contexto do estudo comparativo foi realizado com

o modelo proposto neste Capítulo.

• ccistarml. O pacote Java ccistarml permite a checagem da sintaxe XML e da sintaxe

iStarML. Também possibilita a manipulação e criação de uma estrutura iStarML

usando um conjunto de classes Java (CARES, 2010).

• iStarJSON Project. É um serviço que tem como principais funcionalidades a vali-

dação de um documento JSON de acordo com a estrutura definida e cria documentos

iStarJSON a partir de um arquivo iStarML (BEDOYA et al., 2016).

4.4.1 Casos avaliados

Para a avaliação de cada um dos casos retratados nessa seção, foram descritos arqui-

vos iStarML com erros sintáticos e semânticos e passados para uma instancia do ccistarml

com o intuíto de avaliar o seu comportamento. Para avaliar o SMiLeCompiler foram cri-

ados arquivos SMiLe equivalentes e utilizados como entrada para a ferramenta. Por fim,2http://www.upc.edu/gessi/istar/tools/istarml/resources/ccistarml_v0.7.rar3http://testoneosseco.azurewebsites.net/iStarJSONServiceREST/4http://www.essi.upc.edu/~ccares/papers/ccistarml_v0.6.pdf5https://github.com/UPC-gessi-oscar-franco/iStarJson

Page 54: SMiLeCompiler: Um Analisador Sintático e Semântico para

52

para o iStarJSON Project foi utilizado os serviços iStarJsonConverter para converter o ar-

quivo iStarML em iStarJSON, em seguida foi utilizado o serviço iStarJSONValidator para

validar o arquivo gerado. O serviço iStarJSONConverter utiliza a ferramenta ccistarml du-

rante a conversão da estrutura da notação textual, sem fazer alterações nos valores dos

atributos.

Caso 1. Associação inválida

O arquivo iStarML apresentado no Código 4.2 possui uma associação inválida do tipo

instanceOf entre os atores agent Andreza e role Desenvolvedor. De acordo com as

regras do framework iStar, a associação instanceOf só deve acontecer entre atores do

tipo agent. Ambas as ferramentas indicaram que o arquivo era válido. O SMiLeCompiler

apresentou uma mensagem de erro indicando que a associação é falha.

Código 4.2: iStarML: associação inválida

1 <?xml version=" 1 .0 " encoding="UTF−8" standalone="no"?>

2 <i s t a rm l>

3 <actor id="1" name="Andreza" type="agent ">

4 <actorLink a r e f="2" type=" instance_of "/>

5 </ acto r>

6 <actor id="2" name="Desenvolvedor " type=" r o l e ">

7 </ i s t a rm l>

Caso 2. Ator não definido

O Código 4.3 mostra um arquivo iStarML com um ator position DiretorQA que tem

um relacionamento externo de dependência softgoal progressaoNaCarreira com um

ator que não existe. As ferramentas deram esse arquivo como válido e o SMiLeCompiler

mostrou uma mensagem informando que o ator do relacionamento em questão não foi

definido.

Código 4.3: iStarML: ator não definido

1 <?xml version=" 1 .0 " encoding="UTF−8" standalone="no"?>

2 <i s t a rm l>

3 <actor id="8" name="DiretorQA" type=" po s i t i o n "/>

4 <ie l ement name=" progres saoNaCarre i ra " type=" s o f t g o a l ">

5 <dependency>

6 <depender a r e f="8"/>

Page 55: SMiLeCompiler: Um Analisador Sintático e Semântico para

53

7 <dependee a r e f="7"/>

8 </dependency>

9 </ ie l ement>

10 </ i s t a rm l>

Caso 3. Tipo de ator inválido

O arquivo mostrado no Código 4.4 contém a definição de dois atores agent PerfilDiretoria

e position Diretor com uma associação com erro de escrita no tipo do ator da asso-

ciação occupies ( positio Diretor ). Novamente esse erro não foi notado pelas fer-

ramentas que consideraram este arquivo válido, já o SMiLeCompiler apresentou um erro

na associação incluindo a seguinte mensagem mismatched input ’positio’ expecting

’actor’, ’agent’, ’position’, ’role’.

Código 4.4: iStarML: tipo de ator inválido

1 <?xml version=" 1 .0 " encoding="UTF−8" standalone="no"?>

2 <i s t a rm l>

3 <actor id="12" name=" P e r f i l D i r e t o r i a " type="agent ">

4 <actorLink a r e f="5" type=" occup i e s "/>

5 </ acto r>

6 <actor id="5" name="Di re to r " type=" p o s i t i o "/>

7 </ i s t a rm l>

Como foi visto nos casos apresentados e é definido nas especificações das ferramentas,

tanto o ccistarml como o iStarJSON Project fazem duas verificações: (i) se o arquivo

possui uma estrutura da linguagem válida, e (ii) se os elementos no arquivo possuem os

atributos específicos da notação, mas sem se preocupar com os valores atribuídos. Essas

verificações são realizadas de acordo com as linguagens especificas da ferramenta, que são,

respectivamente, XML e JSON. Em outras palavras, diferentemente do SMiLeCompiler,

as ferramentas em questão não fazem uma análise semântica dos modelos iStar.

Page 56: SMiLeCompiler: Um Analisador Sintático e Semântico para

54

5 Conclusão

A ferramenta SMiLeCompiler foi primeiramente abordada como uma abstração e foi

idealizada como ferramenta de apoio para o ambiente de análise de informações sociais na

abordagem SMiLe proposta por Penha (PENHA, 2017). Concluída a primeira versão do

SMiLeCompiler, baseada em um cenário organizacional de processo de desenvolvimento

de software foi realizado uma avaliação que mostrou que os objetivos almejados foram

atingidos. Em outras palavras, a ferramenta fornece uma análise sintática e semântica,

um conjunto de dados importantes para o Analista de Requisitos e aponta possíveis atores

problemáticos de acordo com as configurações selecionadas. Também foi feita uma com-

paração com as ferramentas ccistarml e iStarJSON Project com a intenção de assegurar

que ambas ferramentas fazem apenas uma análise sintática de suas respectivas notações.

5.1 Limitações

Apesar do bom desempenho demonstrado na avaliação, o SMiLeCompiler tem suas

limitações. Atualmente, o domínio da aplicação é todo guardado em memória. O que pode

tornar a compilação um tanto pesada no caso de uma modelagem com muitos arquivos. A

cobertura de testes do SMiLeCompiler é bastante limitada, os testes da ferramenta foram

focados nos testes unitários dos validadores semânticos. Além disso, o SMiLeCompiler foi

avaliado de acordo com um cenário controlado e erros induzidos, não foram utilizados

usuários reais com arquivos SMiLe escritos por eles com erros de gramática e de descrição

do modelo.

5.2 Trabalhos futuros

Para trabalhos futuros, o SMiLeCompiler pode ser estendido para suportar os modelos

de raciocício estratégico. Podem ser realizadas melhorias na cobertura de testes e no

consumo de memória, para este caso pode ser adicionar uma abstração que possa realizar o

Page 57: SMiLeCompiler: Um Analisador Sintático e Semântico para

55

controle de informações que precisariam ser guardadas em cada uma das fases do processo

de compilação.

Outras sugestões para trabalhos futuros podem ser a implementação de outros tradu-

tores para outras notações, por exemplo, um tradutor para iStarJSON, ou a implemen-

tação de uma tradução inversa, de iStarML para SMiLe. Também podem ser realizados

testes com usuários reais e melhorias nas mensagens de erro para deixá-las mais próximas

da linguagem do usuário.

Para finalizar, o SMiLeCompiler pode ser estendido para englobar uma nova funci-

onalidade que realize uma análise qualitativa nos modelos SMiLe, como identificação de

má utilização de um ator ou um relacionamento que não se encaixa com o contexto do

ambiente em modelagem.

Page 58: SMiLeCompiler: Um Analisador Sintático e Semântico para

56

Referências

AHO, A. V. et al. Compilers: Principles, techniques, and tools (2’“1 edition). PearsonEducation, 2007.

AHO, A. V.; SETHI, R.; ULLMAN, J. D. Compilers, Principles, Techniques. [S.l.]:Addison wesley Boston, 1986.

ANNERVAZ, K. et al. Natural language requirements quality analysis based on businessdomain models. In: IEEE. Automated Software Engineering (ASE), 2013 IEEE/ACM28th International Conference on. [S.l.], 2013. p. 676–681.

BEDOYA, F. et al. istarjson: a lightweight data-format for i* models. In: CEUR-WS.ORG. iStar 2016: Proceedings of the Ninth International i* Workshop, co-located withthe 24rd International Requirements Engineering Conference (RE 2016): Beijing, China,September 12-13, 2016. [S.l.], 2016. p. 37–42.

CARES, C. Ccistarml(v0.6): A java package for handling istarml files. 2010.

CARES, C. et al. Reference’s guide. 2007.

CARES, C. et al. IStarML: An XML-based interchange format for i* models. In: . [S.l.:s.n.], 2008. v. 322, p. 13–16. ISBN 16130073.

CARES, C. et al. Towards interoperability of i* models using istarml. ComputerStandards & Interfaces, Elsevier, v. 33, n. 1, p. 69–79, 2011.

CHUNG, L. et al. Non-functional requirements in software engineering. [S.l.]: SpringerScience & Business Media, 2012.

FISCHER, C. N.; CYTRON, R. K.; LEBLANC, R. J. Crafting a compiler. [S.l.]:Addison-Wesley Publishing Company, 2009.

FRANCH, X. The i * framework: The way ahead (presentation). Research Challenges inInformation Science (RCIS), 2012 Sixth International Conference on, n. May, p. 1–3,2012. ISSN 2151-1349.

HOPPER, G. M. The education of a computer. In: Proceedings of the 1952 ACMNational Meeting (Pittsburgh). New York, NY, USA: ACM, 1952. (ACM ’52), p. 243–249.Disponível em: <http://doi.acm.org/10.1145/609784.609818>.

PARR, T. The definitive ANTLR 4 reference. [S.l.]: Pragmatic Bookshelf, 2013.

PENHA, F. SMILe: Uma Notação Textual para Descrição e Definição Modular dosAtores e suas Relações nos Modelos Gráficos do iStar. Wer, v. 45, p. 289–302, 2017.

Page 59: SMiLeCompiler: Um Analisador Sintático e Semântico para

57

PENHA, F. et al. A proposed textual model for i-star. In: . [S.l.: s.n.], 2016. v. 1674, p.7–12. ISSN 16130073.

PENHA, F. et al. Uma Notação Textual Modular e Escalável para Modelos de RequisitosIStar. Wer, v. 45, p. 289–302, 2017.

SOMMERVILLE, I. Engenharia de software. [S.l.]: PEARSON BRASIL, 2011. ISBN9788579361081.

TAYLOR, R. N.; MEDVIDOVIC, N.; DASHOFY, E. M. Software Architecture:Foundations, Theory, and Practice. [S.l.]: Wiley Publishing, 2009. ISBN 0470167742,9780470167748.

WAITE, W.; GOOS, G. Compiler construction. Springer-Verlag New York, Inc., 1985.

WIEGERS, K.; BEATTY, J. Software requirements. [S.l.]: Pearson Education, 2013.

YU, E. S. Social modeling and i*. Lecture Notes in Computer Science (includingsubseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics),v. 5600 LNCS, n. c, p. 99–121, 2009. ISSN 03029743.

YU, E. S.-K. Modelling Strategic Relationships for Process Reengineering. Tese(Doutorado), Toronto, Ont., Canada, Canada, 1996. UMI Order No. GAXNN-02887(Canadian dissertation).

Page 60: SMiLeCompiler: Um Analisador Sintático e Semântico para

58

APÊNDICE A -- Gramática

Código A.1: Smile.g4

1 grammar Smile ;

2

3 actorStatement : a c t o rDec l a ra t i on NL

4 ( a s s o c i a t i o nDe c l a r a t i o n )∗5 NL

6 ex t e rna lRe l a t i on sh i p s

7 EOF;

8

9 ac to rDec l a r a t i on : actorType actorName ( ’ , ’ ) ? ;

10 actorType : ACTOR | AGENT | POSITION | ROLE ;

11 actorName : ID ;

12

13 a s s o c i a t i o nDe c l a r a t i o n : a s soc ia t ionType ’ ( ’

( a c to rDec l a r a t i on )+ ’ ) ’ NL? ;

14 as soc ia t ionType : COVERS | ISA | INSTANCEOF | ISPARTOF |

OCCUPIES | PLAYS ;

15

16 ex t e r na lRe l a t i on sh i p s : ’ Ext e rna lRe l a t i on sh ip s ’ NL

17 ( dependerPerspect ive )∗18 ( dependeePerspect ive )∗ ;

19

20 dependerPerspect ive : dependencyDependerPerspect ive

dependerDependencyDeclaration NL? ;

21 dependeePerspect ive : dependencyDependeePerspective

dependeeDependencyDeclaration NL? ;

22

Page 61: SMiLeCompiler: Um Analisador Sintático e Semântico para

59

23 dependerDependencyDeclaration : ’ ( ’ a c t o rDec l a r a t i on ’ ) ’ ’ f o r ’

’ ( ’ dependencyType dependencyName ’ ) ’ ;

24 dependeeDependencyDeclaration : ’ ( ’ dependencyType

dependencyName ’ ) ’ ’ to ’ ’ ( ’ a c t o rDec l a r a t i on ’ ) ’ ;

25

26 dependencyDependerPerspect ive : DEPENDSON ;

27 dependencyDependeePerspective : CARRIESOUT | PROVIDES | REACHES

;

28 dependencyType : GOAL | RESOURCE | SOFTGOAL | TASK ;

29 dependencyName : ID ;

30

31 // Actor types

32 ACTOR : ’ ac to r ’ ;

33 AGENT : ’ agent ’ ;

34 POSITION : ’ p o s i t i o n ’ ;

35 ROLE : ’ r o l e ’ ;

36

37 // Assoc i a t i on types

38 COVERS : ’ cove r s ’ ;

39 ISA : ’ isA ’ ;

40 INSTANCEOF : ’ ins tanceOf ’ ;

41 ISPARTOF : ’ i sPartOf ’ ;

42 OCCUPIES : ’ o ccup i e s ’ ;

43 PLAYS : ’ p lays ’ ;

44

45 // Dependency types

46 GOAL : ’ goa l ’ ;

47 RESOURCE : ’ r e s ou r c e ’ ;

48 SOFTGOAL : ’ s o f t g o a l ’ ;

49 TASK : ’ task ’ ;

50

51 // Dependency pe r sp e c t i v e f o r depender and dependee

52 CARRIESOUT : ’ ca r r i e sOut ’ ;

53 DEPENDSON : ’ dependsOn ’ ;

54 PROVIDES : ’ p rov ide s ’ ;

Page 62: SMiLeCompiler: Um Analisador Sintático e Semântico para

60

55 REACHES : ’ r eaches ’ ;

56

57 ID : [ a−zA−Z]+ ;

58 WS : [ \ t ]+ −> sk ip ;

59 NL : [ \ r \n ] ;

60 COMMENT : ’ /∗ ’ .∗? ’ ∗/ ’ −> sk ip ;

Page 63: SMiLeCompiler: Um Analisador Sintático e Semântico para

61

APÊNDICE B -- Arquivos SMiLe

Código B.1: Andreza.smile

1 agent Andreza

2 ins tanceOf ( agent Desenvolvedor )

3

4 Exte rna lRe l a t i on sh ip s

Código B.2: Cliente.smile

1 ac to r C l i en t e

2

3 Exte rna lRe l a t i on sh ip s

4 dependsOn ( po s i t i o n GerenteDeProjeto ) for ( goa l

produtoDesenvolvido )

5 dependsOn ( po s i t i o n GerenteDeProjeto ) for ( s o f t g o a l

entregasRapidas )

6 prov ide s ( r e s ou r c e pagamentos ) to ( p o s i t i o n Di r e to r )

7 reaches ( s o f t g o a l bomRelacionamento ) to ( p o s i t i o n

Di r e to r )

Código B.3: Desenvolvedor.smile

1 agent Desenvolvedor

2 isA ( agent Pro f i s s i ona lDeSo f twar e )

3

4 Exte rna lRe l a t i on sh ip s

Código B.4: Diretor.smile

1 po s i t i o n Di r e to r

2

Page 64: SMiLeCompiler: Um Analisador Sintático e Semântico para

62

3 Exte rna lRe l a t i on sh ip s

4 dependsOn ( po s i t i o n GerenteDeProjeto ) for ( s o f t g o a l

semExecessoDeGastos )

5 dependsOn ( po s i t i o n DiretorQA ) for ( s o f t g o a l

a ltaQual idadeDoSoftware )

6 reaches ( s o f t g o a l reconhecimento ) to ( p o s i t i o n

GerenteDeProjeto )

Código B.5: DiretorQA.smile

1 po s i t i o n DiretorQA

2

3 Exte rna lRe l a t i on sh ip s

4 reaches ( s o f t g o a l a ltaQual idadeDoSoftware ) to (

p o s i t i o n Di r e to r )

5 reaches ( s o f t g o a l manutenebi l idade ) to ( p o s i t i o n

GerenteDeProjeto )

6 reaches ( s o f t g o a l progres saoNaCarre i ra ) to ( agent

Espec ia l i s taQA )

Código B.6: EspecialistaQA.smile

1 agent Espec ia l i s taQA

2 isA ( agent Pro f i s s i ona lDeSo f twar e )

3

4 Exte rna lRe l a t i on sh ip s

5 dependsOn ( po s i t i o n DiretorQA ) for ( s o f t g o a l

progressaoNaCarre i ra )

Código B.7: GerenteDeProjeto.smile

1 po s i t i o n GerenteDeProjeto

2 cover s ( r o l e Monitoramento , r o l e Planejamento )

3

4 Exte rna lRe l a t i on sh ip s

5 dependsOn ( po s i t i o n Di r e to r ) for ( s o f t g o a l

reconhecimento )

6 dependsOn ( po s i t i o n DiretorQA ) for ( s o f t g o a l

manutenebi l idade )

Page 65: SMiLeCompiler: Um Analisador Sintático e Semântico para

63

7 reaches ( goa l produtoDesenvolvido ) to ( p o s i t i o n

C l i en t e )

8 reaches ( s o f t g o a l entregasRapidas ) to ( p o s i t i o n

C l i en t e )

9 reaches ( s o f t g o a l semExecessoDeGastos ) to ( p o s i t i o n

Di r e to r )

Código B.8: Monitoramento.smile

1 r o l e Monitoramento

2

3 Exte rna lRe l a t i on sh ip s

4 dependsOn ( r o l e Planejamento ) for ( r e s ou r c e

planoAtual izado )

5 dependsOn ( r o l e Pe r f i lT e cn i c o ) for ( r e s ou r c e

not i f i c a caoDaS i tuacao )

Código B.9: PerfilDiretoria.smile

1 agent P e r f i l D i r e t o r i a

2 occup i e s ( p o s i t i o n Di r e to r )

3

4 Exte rna lRe l a t i on sh ip s

Código B.10: PerfilTecnico.smile

1 r o l e Pe r f i lT e cn i c o

2

3 Exte rna lRe l a t i on sh ip s

4 dependsOn ( r o l e Planejamento ) for ( r e s ou r c e

planoDeTarefas )

5 prov ide s ( r e s ou r c e not i f i c a caoDaS i tuacao ) to ( r o l e

Monitoramento )

Código B.11: Planejamento.smile

1 r o l e Planejamento

2

3 Exte rna lRe l a t i on sh ip s

Page 66: SMiLeCompiler: Um Analisador Sintático e Semântico para

64

4 prov ide s ( r e s ou r c e planoAtual izado ) to ( r o l e

Monitoramento )

5 prov ide s ( r e s ou r c e planoDeTarefas ) to ( r o l e

Pe r f i lT e cn i c o )

Código B.12: ProfissionalDeSoftware.smile

1 agent Pro f i s s i ona lDeSo f twar e

2 p lays ( r o l e Pe r f i lT e cn i c o )

3

4 Exte rna lRe l a t i on sh ip s

Código B.13: Testador.smile

1 agent Testador

2 isA ( agent Pro f i s s i ona lDeSo f twar e )

3

4 Exte rna lRe l a t i on sh ip s

Page 67: SMiLeCompiler: Um Analisador Sintático e Semântico para

65

APÊNDICE C -- Arquivo iStarML

Código C.1: iStarML

1 <?xml version=" 1 .0 " encoding="UTF−8" standalone="no"?>

2 <i s t a rm l>

3 <actor id="8" name="Espec ia l i s taQA" type="agent ">

4 <actorLink a r e f="6" type=" isA"/>

5 </ acto r>

6 <actor id="4" name="GerenteDeProjeto " type=" po s i t i o n ">

7 <actorLink a r e f="9" type=" cover s "/>

8 <actorLink a r e f="10" type=" cover s "/>

9 </ acto r>

10 <actor id="10" name="Planejamento" type=" r o l e "/>

11 <actor id="6" name="Pro f i s s i ona lDeSo f twar e " type="agent ">

12 <actorLink a r e f="11" type=" plays "/>

13 </ acto r>

14 <actor id="7" name="DiretorQA" type=" po s i t i o n "/>

15 <actor id="12" name=" P e r f i l D i r e t o r i a " type="agent ">

16 <actorLink a r e f="5" type=" occup i e s "/>

17 </ acto r>

18 <actor id="1" name="Andreza" type="agent ">

19 <actorLink a r e f="2" type=" instanceOf "/>

20 </ acto r>

21 <actor id="11" name=" Pe r f i lT e cn i c o " type=" r o l e "/>

22 <actor id="5" name="Di re to r " type=" po s i t i o n "/>

23 <actor id="2" name="Desenvolvedor " type="agent ">

24 <actorLink a r e f="6" type=" isA"/>

25 </ acto r>

26 <actor id="13" name="Testador " type="agent ">

Page 68: SMiLeCompiler: Um Analisador Sintático e Semântico para

66

27 <actorLink a r e f="6" type=" isA"/>

28 </ acto r>

29 <actor id="3" name="Cl i en t e " type=" acto r "/>

30 <actor id="9" name="Monitoramento" type=" r o l e "/>

31 <ie l ement name=" progres saoNaCarre i ra " type=" s o f t g o a l ">

32 <dependency>

33 <depender a r e f="8"/>

34 <dependee a r e f="7"/>

35 </dependency>

36 </ ie l ement>

37 <ie l ement name=" reconhecimento " type=" s o f t g o a l ">

38 <dependency>

39 <depender a r e f="4"/>

40 <dependee a r e f="5"/>

41 </dependency>

42 </ ie l ement>

43 <ie l ement name="manutenebi l idade " type=" s o f t g o a l ">

44 <dependency>

45 <depender a r e f="4"/>

46 <dependee a r e f="7"/>

47 </dependency>

48 </ ie l ement>

49 <ie l ement name="planoDeTarefas " type=" re sou r c e ">

50 <dependency>

51 <depender a r e f="11"/>

52 <dependee a r e f="10"/>

53 </dependency>

54 </ ie l ement>

55 <ie l ement name="semExecessoDeGastos" type=" s o f t g o a l ">

56 <dependency>

57 <depender a r e f="5"/>

58 <dependee a r e f="4"/>

59 </dependency>

60 </ ie l ement>

61 <ie l ement name="altaQual idadeDoSoftware " type=" s o f t g o a l ">

Page 69: SMiLeCompiler: Um Analisador Sintático e Semântico para

67

62 <dependency>

63 <depender a r e f="5"/>

64 <dependee a r e f="7"/>

65 </dependency>

66 </ ie l ement>

67 <ie l ement name="produtoDesenvolvido " type=" goa l ">

68 <dependency>

69 <depender a r e f="3"/>

70 <dependee a r e f="4"/>

71 </dependency>

72 </ ie l ement>

73 <ie l ement name=" entregasRapidas " type=" s o f t g o a l ">

74 <dependency>

75 <depender a r e f="3"/>

76 <dependee a r e f="4"/>

77 </dependency>

78 </ ie l ement>

79 <ie l ement name="planoAtual izado " type=" re sou r c e ">

80 <dependency>

81 <depender a r e f="9"/>

82 <dependee a r e f="10"/>

83 </dependency>

84 </ ie l ement>

85 <ie l ement name=" not i f i c a caoDaS i tuacao " type=" re sou r c e ">

86 <dependency>

87 <depender a r e f="9"/>

88 <dependee a r e f="11"/>

89 </dependency>

90 </ ie l ement>

91 </ i s t a rm l>