Upload
others
View
9
Download
0
Embed Size (px)
Citation preview
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
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
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
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
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.
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.
Take these broken wings and learn to fly. All your life, you were only waiting for this
moment to arise.
John Lennon / Paul Mccartney
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
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
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
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
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
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
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
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
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
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;
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
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
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.
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).
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.,
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
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
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.
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
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
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-
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
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.
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)
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
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.
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
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
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.
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.
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/
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.
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
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).
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
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.
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
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
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
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( ) ;
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)
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-
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
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.
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
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
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"/>
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.
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
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.
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.
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).
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
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 ’ ;
60
55 REACHES : ’ r eaches ’ ;
56
57 ID : [ a−zA−Z]+ ;
58 WS : [ \ t ]+ −> sk ip ;
59 NL : [ \ r \n ] ;
60 COMMENT : ’ /∗ ’ .∗? ’ ∗/ ’ −> sk ip ;
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
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 )
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
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
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 ">
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 ">
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>