196
Elizabeth Suescún Monsalve Construindo um Jogo Educacional com Modelagem Intencional Apoiado em Princípios de Transparência Dissertação de Mestrado Dissertação apresentada ao Programa de Pós- Graduação em Informática da PUC-Rio como requisito parcial para obtenção do título de Mestre em Informática. Orientador: Prof. Julio Cesar Sampaio do Prado Leite Rio de Janeiro Março de 2010 PUC-Rio - Certificação Digital Nº 0812549/CA

Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

  • Upload
    others

  • View
    2

  • Download
    0

Embed Size (px)

Citation preview

Page 1: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Elizabeth Suescún Monsalve

Construindo um Jogo Educacional com Modelagem

Intencional Apoiado em Princípios de Transparência

Dissertação de Mestrado

Dissertação apresentada ao Programa de Pós-Graduação em Informática da PUC-Rio como requisito parcial para obtenção do título de Mestre em Informática.

Orientador: Prof. Julio Cesar Sampaio do Prado Leite

Rio de Janeiro Março de 2010

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 2: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Elizabeth Suescún Monsalve

Construindo um Jogo Educacional com Modelagem

Intencional Apoiado em Princípios de Transparência

Dissertação apresentada como requisito parcial para obtenção do grau de Mestre pelo Programa de Pós-Graduação em Informática do Departamento de Informática do Centro Técnico e Científico da PUC-Rio. Aprovada pela Comissão Examinadora abaixo assinada.

Prof. Julio Cesar Sampaio do Prado Leite Orientador

Departamento de Informática – PUC–Rio

Prof. Carlos José Pereira de Lucena Departamento de Informática – PUC–Rio

Profª Vera Maria Benjamim Werneck Departamento de Informática – UERJ–Rio

Prof. José Eugênio Leal Coordenador Setorial do Centro Técnico Científico – PUC–Rio

Rio de Janeiro, 25 de março de 2010

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 3: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Todos os direitos reservados. É proibida a reprodução total ou parcial do trabalho sem autorização da universidade, do autor e do orientador.

Elizabeth Suescún Monsalve

Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em setembro de 2004. Área de interesse acadêmico: Engenharia de Software, mais especificamente em Engenharia de Requisitos.

Ficha Catalográfica

Monsalve, Elizabeth Suescún

Construindo um jogo educacional com modelagem intencional apoiado em princípios de transparência / Elizabeth Suescún Monsalve; orientador: Julio Cesar Sampaio do Prado Leite – 2010

196 f ; 30 cm

Dissertação (Mestrado em Informática) – Pontifícia Universidade Católica do Rio de Janeiro, Rio de Janeiro, 2010.

Inclui bibliografia.

1. Informática – Teses. 2. Engenharia de Requisitos. 3. Jogos Educacionais. 4. Framework i*. 5. Modelagem Intencional. 6. Transparência de Software I. Leite, Julio César Sampaio do Prado. II. Pontifícia Universidade Católica do Rio de Janeiro. Departamento de Informática. III. Título.

CDD: 004

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 4: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Este trabalho é dedicado a minha Mãe e Carlos com todo meu amor.

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 5: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Agradecimentos

Primeiramente, agradeço a Deus.

Agradeço ao órgão de financiamento CAPES pela bolsa oferecida a qual

viabilizou esta pesquisa.

Ao meu orientador, professor Julio Cesar Sampaio do Prado Leite, pela confiança

depositada em mim, pela paciência e por todas as orientações durante este

trabalho.

À professora Vera Maria Benjamim Werneck, pelos aportes e colaboração durante

este trabalho.

À minha querida mãe, pela fé, a confiança e por esse amor incondicional.

A Zammis pela alegria que cada dia da a minha vida.

A Giba por todo esse amor y carinho que me entregou, e que agora desde o céu

continua vivo.

Aos amigos do grupo de Engenharia de Requisitos e aos alunos voluntários, pelas

valiosas contribuições a este trabalho.

A meus amigos Edy, Sandra, Kátia, Paola, Andréia, Marcio, Antonio, Juan Pablo

e Bruno que longe ou perto sempre estiveram me apoiando e me acompanhando.

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 6: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Resumo

Monsalve, Elizabeth Suescún; Leite, Julio Cesar Sampaio do Prado. Construindo um Jogo Educacional com Modelagem Intencional Apoiado em Princípios de Transparência. Rio de Janeiro, 2010. 196p. Dissertação de Mestrado – Departamento de Informática, Pontifícia Universidade Católica do Rio de Janeiro.

Jogos educacionais vêm sendo propostos no ensino de ciências da

computação, e também no ensino de a engenharia de software. Neste trabalho,

apresentamos uma abordagem de modelagem intencional apoiada em conceitos de

transparência para a implementação do jogo educacional SimulES. SimulES é um

jogo para apoiar o ensino de engenharia de software. A abordagem é inovadora

neste contexto. Acreditamos que a modelagem intencional é pertinente para

modelar jogos, já que ela permite representar a interação e colaboração entre os

atores, além de apoiar conceitos de transparência. Essa modelagem foi usada no

desenvolvimento do software SimulES-W que implementa o jogo num ambiente

Web.

Palavras–chave

Engenharia de Requisitos; Jogos Educacionais; Framework i*; Modelado

Intencional; Transparência de Software

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 7: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Abstract

Monsalve, Elizabeth Suescún; Leite, Julio Cesar Sampaio do Prado (Advisor). Building an Educational Game with Intentional Modeling Supported with Principles of Transparency. Rio de Janeiro, 2010. 196p. MSc. Dissertation – Departamento de Informática, Pontifícia Universidade Católica do Rio de Janeiro.

Educational games have been proposed for teaching computer science, and

software engineering as well. This work presents an approach for intentional

modeling supported by concepts of transparency towards the implementation of

the educational game SimulES. SimulES is a game for helping software

engineering teaching. The approach is innovative in that context. We believe that

intentional modeling is akin to game modeling, since it allows us to represent the

interaction and collaboration among the actors as well concepts of transparency.

The intentional model we produced was used to develop the software that

implements SimulES-W, a Web based version of the game.

Keywords

Requirements Engineering; Educational Game; Framework I*; Intentional

Modeling; Software Transparency

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 8: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Sumário

1 Introdução 17

1.1. Motivação 17

1.2. Objetivos 18

1.3. Conceitos 18

1.3.1. Léxico Ampliado da Linguagem (LAL) 18

1.3.2. Cenários 19

1.3.3. Visão Geral do Framework i* 20

1.4. Organização da Dissertação 31

2 Jogos Educacionais 32

2.1. Visão Geral de Jogos Educacionais 32

2.1.1. O Jogo Problems and Programmers (PnP) 32

2.1.2. O Jogo SESAM 34

2.1.3. O Jogo SimVBSE 35

2.1.4. O Jogo SimSE 37

2.1.5. O Jogo Planager 39

2.1.6. O Jogo Scrumming 40

2.1.7. O Jogo X-MED v1.0 41

2.1.8. O Jogo SimulES 42

2.2. Resumo das Características dos Jogos 43

2.3. Considerações Sobre Jogos Educacionais 43

3 Procurando Elementos de Evolução do SimulES 45

3.1. Contextualização 46

3.1.1. O SimulES 46

3.1.2. Técnicas Utilizadas para Identificar Elementos de Evolução

para o SimulES 54

3.1.3. Usando as Técnicas de Elicitação para a Evolução do SimulES 55

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 9: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

4 Uso das Representações 64

4.1. Contextualização 64

4.2. Representação de Requisitos em Linguagem Natural 65

4.2.1. Léxico Ampliado da Linguagem (LAL) 65

4.2.2. Cenários 66

4.2.3. C&L 67

4.3. Representação Intencional dos Requisitos 67

4.3.1. Framework i* 68

4.3.2. O Método ERi*c 68

4.3.3. Modelagem Intencional do SimulES 70

4.4. Análise das Representações de Requisitos Usadas 80

5 Trabalhos Relacionados 81

5.1. Modelagem Intencional Casos Práticos 81

5.1.1. Estendendo Tropos para uma Implementação em Prolog: um

Estudo de Caso Usando o Problema do Agente Coletor de Alimentos

(FCAP) [49] 81

5.1.2. “Tropos: uma Metodologia de Desenvolvimento de Software

Orientada a Agentes” [50] 84

5.1.3. “Uma Abordagem para Modelagem Intencional de Avaliação de

Riscos de Segurança em Web Services” [51] 89

5.2. Transparência de Software 93

5.2.1. “Uma Análise Inicial sobre como Transparência Software e

Confiança se Influenciam Mutuamente” [52] 94

5.2.2. Transparência e Pureza do Software [54] 94

5.2.3. Explorando as Características de i* que

Apóiem a Transparência do Software [53] 96

5.3. Análise dos Trabalhos Relacionados 97

6 Construindo o SimulES-W 100

6.1. Background 100

6.2. Arquitetura do SimulES-W e Tecnologias Utilizadas 102

6.3. Método Usado na Construção do SimulES -W 103

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 10: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

6.3.1. Primeira Etapa 103

6.3.2. Segunda Etapa 105

6.4. Incorporando Elementos em cada uma das Camadas 106

6.4.1. Identificar as SDsituations Principais 107

6.4.2. SDsituations Auxiliares 126

6.4.3. Descrição das SDsituations do Sistema Através de Cenários 133

6.4.4. Refinamento das SDsituations e dos Cenários 146

6.5. Cenários do Sistema 155

6.5.1. Cenários da Camada de Controle 155

6.5.2. Cenários da Camada de Modelo 160

6.5.3. Cenários da Camada de Visão 164

6.6. Operacionalização das SDsituations 164

6.6.1. Frameworks de Desenvolvimento Web 165

6.6.2. Ferramentas de Desenvolvimento 165

6.6.3. Desenvolvimento do SimulES-W 166

6.7. Rastreabilidade em SimulES-W 182

6.8. Avaliação dos Atributos da Transparência 184

7 Conclusão 187

7.1. Comparação com Trabalhos Relacionados 189

7.2. Dificuldades Encontradas 189

7.3. Trabalhos Futuros 190

8 Referências Bibliográficas 192

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 11: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Lista de figuras

Figura 1 – Ilustração da dependência entre atores utilizada em modelos SD. 23

Figura 2 – Decomposição de tarefas. 24

Figura 3 – Elos meios-fim. 25

Figura 4 – Ilustração de um modelo SA [11]. 28

Figura 5 – Variantes de interdependência lógica das SDsituations [11]. 29

Figura 6 – Ilustração de um painel de intencionalidade adaptado de [11]. 31

Figura 7 – Tela principal do jogo SESAM [2]. 35

Figura 8 – Fluxo do jogo SimVBSE [3]. 37

Figura 9 – Tela principal do jogo SimSE tomado de [13]. 38

Figura 10 – SADT para SimulES-W. 45

Figura 11 – Dinâmica do jogo SimulES v 2.0. 47

Figura 12 – Exemplo de cartão de projeto SimulES v 2.0 [4]. 49

Figura 13 – Tabuleiro individual SimulES v 2.0 [4]. 49

Figura 14 – Exemplo de uma carta problema do jogo SimulES v 2.0 [4]. 50

Figura 15 – Exemplo de carta conceito do jogo SimulES v 2.0 [4]. 51

Figura 16 – Exemplo de cartas de engenheiros de software SimulES v 2.0 [4]. 51

Figura 17 – Artefatos (a) brancos com ou sem erro e

(b) cinzas com ou sem erro SimulES v 2.0 [4]. 52

Figura 18 – Tabuleiro principal de SimulES v 2.0 [4]. 53

Figura 19 – Exemplo de cenário SimulES v 2.0 [4]. 55

Figura 20 – Representação gráfica dos resultados das questões fechadas. 58

Figura 21 – Representação no CEL do léxico

usando a palavra chave “Jogador” v 2.0 [4]. 65

Figura 22 – Representação no CEL do léxico usando a palavra chave

“Jogador” v 3.0 [44]. 66

Figura 23 – Exemplo do comportamento dos cenários do jogo v 2.0 [4]. 66

Figura 24 – Interface do C&L usado para modelar elemento do jogo SimulES. 67

Figura 25 – Visão geral do método ERi*c [11]. 69

Figura 26 – Exemplo de símbolo do LAL para SimulES v 3.0 [44]. 71

Figura 27 – Símbolos tipo sujeito v 3.0 [44]. 71

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 12: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Figura 28 – Diagrama de SDsituations do SimulES v 3.0 [44]. 75

Figura 29 – modelo SA para SimulES v 3.0 [44]. 76

Figura 30 – Diagrama IP – Joga Rodada de Início do SimulES v 3.0

adaptado de [44]. 77

Figura 31 – Modelo SD – Joga Rodada de Início do SimulES v 3.0 [44]. 78

Figura 32 – Modelo SR – Joga Rodada de Início do SimulES v 3.0 [44]. 79

Figura 33 – Descrição através de cenários de SDsituation

Inspeção de Artefato do Simules v 3.0 [44]. 80

Figura 34 – Identificação de atores genéricos para FCAP [49]. 82

Figura 35 – Descrevendo papéis de agentes em FCAP [49]. 83

Figura 36 – Decomposição de cada agente FCAP [49]. 83

Figura 37 – Diagrama de atores, modelando os stakeholders

do projeto eCulture [50]. 85

Figura 38 – Diagrama de metas para Cidadão e Visitante.

Observe se a meta e plano de decomposição,

a análise meios-fim e a contribuição positiva à meta flexível [50]. 86

Figura 39 – Segmento do diagrama de atores incluindo PAT

e o sistema eCulture e o diagrama de metas do sistema eCulture [50]. 87

Figura 40 – Ambiente de desenvolvimento JACK para projeto eCulture. 88

Figura 41 – Diagrama SD para o Web Service baseado em

cartões de pagamento. 90

Figura 42 – Tipos de atores do Web Service baseado em

cartões de pagamento [51]. 91

Figura 43 – Diagrama SR para o Web Service baseado em

cartões de pagamento [51]. 92

Figura 44 – Representação de ataques para o Web Service baseado em

cartões de pagamento [51]. 92

Figura 45 – Escada da Transparência tomada de [53]. 96

Figura 46 – Arquitetura projetada para o SimulES-W. 103

Figura 47 – Primeira versão do modelo de classes para SimulES-W. 104

Figura 48 – Símbolo SimulES analisado para sua conversão

a classe do sistema. 104

Figura 49 – SDSituations candidata a página no SimulES-W. 105

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 13: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Figura 50 – Modelo de navegabilidade da aplicação Web para o SimulES-W. 106

Figura 51 – Diagrama SDsituations refinado para o SimulES-W. 107

Figura 52 – Modelo SA SimulES-W refinado. 107

Figura 53 – Modelo SD – Joga Rodada de Início. 108

Figura 54 – Modelo SR – Joga Rodada de Início. 109

Figura 55 – Modelo SD – Joga Rodada de Ações. 110

Figura 56 – Modelo SR – Joga Rodada de Ações. 111

Figura 57 – Modelo SD – Construção de Artefato. 112

Figura 58 – Modelo SD – Construção de Artefato. 113

Figura 59 – Modelo SD – Inspeção de Artefato. 114

Figura 60 – Modelo SD – Inspeção de Artefato. 115

Figura 61 – Modelo SD – Correção de Artefato. 116

Figura 62 – Modelo SD – Correção de Artefato. 117

Figura 63 – Modelo SD – Joga Rodada de Conceitos. 118

Figura 64 – Modelo SR – Joga Rodada de Conceitos. 119

Figura 65 – Modelo SD – Tratamento de Problema. 120

Figura 66 – Modelo SR – Tratamento de Problema. 121

Figura 67 – Modelo SD – Submissão de Produto. 122

Figura 68 – Modelo SR – Submissão de Produto. 123

Figura 69 – Modelo SD – Integração de Artefato em Módulo. 124

Figura 70 – Modelo SR – Integração de Artefato em Módulo. 125

Figura 71 – Modelo SD – Apresentar Dinâmica do Jogo. 127

Figura 72 – Modelo SR – Apresentar Dinâmica do Jogo. 128

Figura 73 – Modelo SD – Gestão de Material de Apoio. 129

Figura 74 – Modelo SR – Gestão de Material de Apoio. 130

Figura 75 – Modelo SD – Gestão do Jogo. 131

Figura 76 – Modelo SR – Gestão do Jogo. 132

Figura 77 – Modelo SD – Apresentar Dinâmica do Jogo

com atributos da Transparência. 152

Figura 78 – Modelo SR – Apresentar Dinâmica do Jogo

com atributos da Transparência. 153

Figura 79 – MVC para aplicações Web [63]. 164

Figura 80 – Tela da SDsituation Apresentar Dinâmica do Jogo. 167

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 14: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Figura 81 – Parte do código da SDsituation Apresentar Dinâmica do Jogo. 168

Figura 82 – Tela da SDsituation Joga Rodada de Inicio. 168

Figura 83 – Tela da SDsituation Joga Rodada de Ações. 169

Figura 84 – Tela da SDsituation Construção de Artefatos. 170

Figura 85 – Tela da SDsituation Inspeção de Artefato. 170

Figura 86 – Tela da SDsituation Correção de Artefato. 171

Figura 87 – Tela da SDsituation Joga Rodada de Conceitos

ações sobre os Engenheiros de Software. 171

Figura 88 – Tela da SDsituation Joga Rodada de Conceitos ação

de Descartar Cartas. 172

Figura 89 – Tela da SDsituation Joga Rodada de Conceitos

ação de Submeter Problema. 172

Figura 90 – Tela da SDsituation Tratamento de Problema,

problemas por jogador. 173

Figura 91 – Tela da SDsituation Tratamento de Problema,

tratamento com Carta Conceito. 173

Figura 92 – Tela da SDsituation Tratamento de Problema,

tratamento com penalidade. 174

Figura 93 – Tela da SDsituation Tratamento de Problema,

aceitação de tratamento problema pelos jogadores. 174

Figura 94 – Tela das SDsituations

Integração de Artefatos no Módulo e Submissão de Produto. 175

Figura 95 – Tela da SDsituation Gestão de Material de Apoio,

criar material de apoio. 175

Figura 96 – Tela da SDsituation Gestão de Material de Apoio,

operações sobre Cartas Conceito e Cartas Problema. 176

Figura 97 – Tela da SDsituation Gestão do Jogo. 176

Figura 98 – Operacionalização dos cenários da camada do modelo. 178

Figura 99 – Parte de código do cenário Tabuleiro Individual

na camada modelo. 179

Figura 100 – Operacionalização dos cenários da camada do controle. 180

Figura 101 – Parte de código do cenário controlador

de rondas da camada controle. 182

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 15: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Figura 102 – Segmento da SDsituation Dinâmica do Jogo

para ilustrar Rastreabilidade. 183

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 16: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Lista de tabelas

Tabela 1 – Estrutura de cenário adaptada de [59] 19

Tabela 2 – Resumo das características dos jogos. 43

Tabela 3 – Questionário SimulES aplicado a estudantes da UERJ. 56

Tabela 4 – Regras gerais para definição de símbolos [22]. 70

Tabela 5 – Template preenchido com metas dos símbolos do tipo sujeito [44]. 72

Tabela 6 – Template com metas concretas do símbolo do tipo objeto [44]. 73

Tabela 7 – Template com metas flexíveis do símbolo do tipo objeto [44]. 73

Tabela 8 – Template com metas do símbolo do tipo verbo [44]. 73

Tabela 9 – Template com metas do símbolo do tipo estado [44]. 73

Tabela 10 – Template para agrupar e organizar metas por ator

cronologicamente [44]. 74

Tabela 11 – SimulES-W e os termos da Transparência. 184

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 17: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

1 Introdução

O objetivo deste capítulo é estabelecer o contexto da pesquisa realizada. Ao

longo deste capítulo serão apresentadas: a motivação para a pesquisa, os objetivos

do trabalho, os conceitos utilizados e a organização desta dissertação.

Motivação

Jogos educacionais vêm sendo propostos no ensino de ciências da

computação, e também no ensino de engenharia de software [1], [2], [3]. Nesta

pesquisa abordaremos um destes jogos educacionais, o SimulES [4], [5] [6]. Ele é

um jogo de cartas educacional concebido como uma evolução do jogo Problems

and Programmers [1], tendo origem no grupo de engenharia de requisitos da

PUC-Rio. SimulES permite a simulação do processo de desenvolvimento de

software, onde o estudante assume diferentes papéis em uma equipe de software e

desta forma enfrenta problemas típicos da construção de software.

SimulES será implementado usando uma modelagem que utiliza a

perspectiva intencional[7]. Este tipo de modelagem é geralmente usado para

modelar contextos organizacionais com base nos relacionamento entre atores e

suas dependências. Um de nossos objetivos é demonstrar que modelos iniciais em

jogos devem levar em conta a interação entre atores (jogadores) e, portanto, um

modelo intencional é apropriado para este fim. Acreditamos que os modelos

intencionais, além de proporcionar uma visão mais ampla da colaboração entre

atores, também podem ser apropriados para apoiar conceitos de transparência [8],

sendo a transparência uma qualidade que se torna importante no momento em que

queremos descrever o que o software está fazendo para aqueles que usam ou são

afetados por ele, em outras palavras, a transparência de software está relacionada

com características de qualidade que o software deve ter para que seja de fácil

compreensão para estes usuários.

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 18: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 1 – Introdução 18

Objetivos

Com nosso trabalho queremos mostrar que modelos iniciais de jogos devem

levar em conta a interação entre atores. Para tal interação, o modelo intencional é

apropriado, como também incorpora elementos de qualidade próprios da

transparência [9]. Queremos mostrar o enfoque do desenvolvimento de software

fundamentado nestes elementos, pois acreditamos que artefatos de software

baseados no modelo intencional (i*) torna o modelo mais perto da implementação

e assim, mais transparente. Nosso principal objetivo foi o de automatizar o jogo

SimulES partindo de uma modelagem intencional. Com isso estaremos

demonstrando através de um exemplo (SimulES-W), como desenvolver um

software de maneira mais transparente. Além da visão dos modelos, utilizamos

estratégias de elicitação de requisitos para melhorar o entendimento do jogo e sua

interação com os jogadores.

Conceitos

No decorrer deste trabalho serão utilizados alguns conceitos importantes,

que serão descritos a seguir:

Léxico Ampliado da Linguagem (LAL)

O LAL (Léxico Ampliado da Linguagem) [10] é uma técnica que permite

descrever os símbolos de uma linguagem. Sua idéia central é permitir que sejam

identificadas as palavras ou frases do entorno social da aplicação em estudo,

também conhecido como Universo de Informação (UdI)1.

No LAL do UdI, cada entrada está associada a um símbolo (palavra ou frase

do UdI), e pode ser classificada como sujeito, objeto, verbo ou estado. Cada

símbolo pode possuir sinônimos e é descrito por noções e impactos [13]. Noção é

a descrição do significado do símbolo. Impacto descreve os efeitos do uso do

símbolo ou sua ocorrência no UdI. A utilização do LAL será apresentada no

Capítulo 3.

1 O Universo de Informações (ou Universo de Discurso – UofD) inclui todas as fontes de informação e todas as pessoas relacionadas ao software.

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 19: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 1 – Introdução 19

Cenários

Os cenários [18] são descrições de situações em linguagem natural semi-

estruturada que permitem entender, unificar, analisar, e rastrear relacionamentos

do sistema a serem construídos. Eles também permitem descrever as interações

entre componentes de um sistema. O uso de cenários é uma boa prática, pois

permite elicitar e especificar o comportamento do sistema como se fossem

descrições de situações em um ambiente particular. É importante ressaltar que os

cenários estão associados diretamente com o LAL [10], já que usam os símbolos

ali definidos.

Tabela 1 – Estrutura de cenário adaptada de [59]

Título Identificador do cenário. Deve ser único.

Objetivo Descrição da finalidade do cenário. Deve ser descrito também como

este objetivo é alcançado.

Contexto Descrição do estado inicial do cenário. Deve ser descrito através de

pré-condições, localização geográfica e/ou temporal.

Atores São entidades envolvidas diretamente com a situação. Um ator, para

ser válido, deve aparecer em pelo menos um dos episódios.

Recursos São entidades passivas utilizadas na situação. Um Recurso, para ser

válido, deve aparecer em pelo menos um dos episódios.

Episódios Sentenças (seqüência / paralelismo / seleção) que correspondem a

ações e decisões com participação dos atores e utilização de recursos. A

estrutura de controle básica é a seqüência, mas pode-se utilizar seleção

opcional idade e paralelismo

Restrições São aspectos não funcionais que qualificam/restringem o que está

sendo descrito pelo cenário. Estes aspectos podem estar relacionados ao

contexto, recursos ou episódios.

Exceções Situações que impedem que o objetivo do cenário seja alcançado. O

tratamento para tais situações deve ser descrito por outro cenário.

Segundo [18] os cenários são descrições de situações comuns ou cotidianas.

Eles devem ter aspetos de usabilidade e permitir aprofundar no conhecimento do

problema e unificar critérios, além de explicitar a obtenção de compromissos entre

os clientes e usuários como também os detalhes da organização.

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 20: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 1 – Introdução 20

Neste trabalho, será utilizada a abordagem apresentada em [24], onde sua

estrutura está composta pelas entidades: título, objetivo, contexto, recursos,

atores, episódios, exceções e restrições conforme [59]. A Tabela 1 apresenta as

entidades e suas descrições.

Visão Geral do Framework i*

O framework i* (i de intencional- estrela de distribuída) [7] permite modelar

contextos organizacionais baseado nos relacionamentos de dependência

intencional entre os atores. Este framework é usado para obter um melhor

entendimento dos relacionamentos organizacionais com base na interação entre

atores.

Identificar estes relacionamentos entre os atores ajuda para que engenheiros

de requisitos possam elicitar metas nas fases iniciais. Estas metas serão

identificadas respondendo a questionamentos sobre por que os atores têm estas

dependências organizacionais. O foco do framework i* é possibilitar a

compreensão das razões tanto internas dos atores como aquelas que são

compartilhadas entre eles, uma vez que as mesmas são expressas explicitamente,

auxiliando na escolha de alternativas durante a etapa de modelagem do software.

Neste framework os participantes do contexto organizacional são chamados de

atores. Conforme Yu [7], atores são entidades ativas que efetuam ações para

alcançar metas através do exercício de suas habilidades e conhecimentos, podendo

ter dependências intencionais entre eles. Uma dependência intencional ocorre

quando dois ou mais atores compartilham algum elemento de dependência

definido no framework i*. A seguir uma descrição geral dos elementos de

dependência:

(i) Meta concreta: é uma condição ou estados de desejos no mundo

que o ator deseja alcançar. Não é especificado como a meta deve

ser alcançada, isso possibilita que várias alternativas sejam

consideradas.

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 21: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 1 – Introdução 21

(ii) Tarefa: especifica um modo especial de fazer alguma coisa.

Quando uma tarefa é definida como sub-tarefa de outra tarefa ela

restringe esta outra tarefa a um curso de ação em particular,

especificado pela tarefa sub-tarefa.

(iii) Recurso: é uma entidade (física ou informacional) para satisfazer

uma necessidade que não é considerada problemática pelo ator.

Suas principais características são quem o disponibiliza e se

efetivamente está disponível.

(iv) Meta flexível: condição ou estado no mundo que o ator deseja

alcançar. É diferente de uma meta concreta, pois a condição para

ser alcançada não é definida desde o inicio, além disso, ela pode

estar sujeita a interpretação. Conforme [12] quando uma meta

flexível é um componente em uma decomposição de tarefa, ela

serve como uma meta de qualidade para aquela tarefa, guiando (ou

restringindo) a seleção entre as alternativas para a decomposição da

tarefa.

Conforme [7], Yu usou dois modelos dentro do Framework i*: o modelo SD

(siglas em inglês de Strategic Dependency) e o modelo SR (siglas em inglês de

Strategic Rationale), descritos a seguir.

O Modelo SD – Strategic Dependency

O modelo SD descreve os relacionamentos de dependência estratégica entre

os atores da organização, utilizando para isso uma rede de nós, para representar

atores e arestas para representar as dependências entre os mesmos.

No modelo SD, um relacionamento baseado em cooperação entre dois

atores representa a dependência que existe entre eles, onde o primeiro é designado

“depender” ou “dependente” e o segundo “dependee” ou “de quem se depende”,

unidos por um elo de dependência, designado como “dependum”, está relação de

dependência ou dependum pode representar uma meta a ser atingida, uma tarefa a

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 22: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 1 – Introdução 22

ser executada, um recurso a ser fornecido ou uma meta flexível a ser satisfeita. A

seguir as definições do dependum segundo [7]:

(i) Dependência por meta: acontece quando o depender depende do

dependee para que certo estado do mundo seja alcançado. Como

acontece na Figura 1, ao dependee é dada a liberdade de execução da

meta. Por tanto, com uma dependência por meta, o depender ganha a

habilidade de assumir que a condição ou estado do mundo será

alcançado, é assim que o depender se torna vulnerável, pois o

dependee pode falhar ou não realizar tal condição;

(ii) Dependência por tarefa: acontece quando o depender depende de do

dependee para que este último realize uma tarefa. Este tipo de

relação especifica “como” a tarefa deve ser realizada, mas não

menciona “porquê”. Como na Figura 1, o Jogador vai depender do

SimulES para que os recursos sejam disponibilizados. Isso faz com

que o depender (Jogador) seja vulnerável, pois o dependee

(SimulES) pode falhar ou não executar a tarefa.

(iii) Dependência por recurso: acontece quando depender depende de

outro, o dependee, para que uma entidade (física ou computacional)

seja disponibilizada. Como mostrado na Figura 1 o depender

(jogador) ganha a habilidade de usar a entidade (Cartão do projeto)

como um recurso, este fato faz que este fique vulnerável, pois a

entidade ou recurso pode tornar-se indisponível.

(iv) Dependência por meta flexível: acontece quando o depender

depende do dependee para que certo estado do mundo seja

alcançado, porém diferentemente de uma meta (rígida ou concreta),

pois o critério para a condição de ser alcançada não é definido a

princípio, estando sujeito à interpretação. Quer dizer que para metas

flexíveis, são usados os termos “satisfeita a contento” conforme [48]

ou “razoavelmente satisfeita”. Esta subjetividade faz com que a

satisfação de metas flexíveis seja inerente a requisitos não

funcionais, por se tratar de aspectos de qualidade [12]; como é

ilustrado na Figura 1 não se possuem critérios claramente definidos

para sua satisfação, além disso, o depender (Jogador) será

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 23: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 1 – Introdução 23

vulnerável, pois o dependee (SimulES) pode falhar em realizar tal

condição.

“dependee” ator “dependum” “depender” ator

(i)

(ii)

(iii)

(iv)

Figura 1 – Ilustração da dependência entre atores utilizada em modelos SD.

O Modelo SR – Strategic Rationale

O modelo SR tem como objetivo representar as estratégias internas de cada

ator, fornecendo uma descrição intencional do processo em termos dos elementos

e das decisões e escolhas por trás dele. O raciocínio (rationale) dos atores é

representado explicitamente no modelo SR proporcionando um entendimento

detalhado do processo. Além disso, são elaborados de modo a expressarem o

processo pelo qual: as metas são alcançadas, as tarefas são executadas, os recursos

são disponibilizados e as metas flexíveis são refinadas (decompostas) e

operacionalizadas. A representação destes relacionamentos intencionais que são

internos aos atores são conhecidos como “meios-fim”, fornecendo uma

representação explícita do ‘porque’, do ‘como’ e de alternativas.

O modelo SR é um grafo com quatro tipos de nós, idênticos aos tipos de

dependum em um modelo SD: meta, tarefa, recurso e meta flexível. O modelo SR

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 24: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 1 – Introdução 24

possui duas classes principais de elos: elos de decomposição de tarefa e elos

“meios-fim”.

(i) Elos de decomposição de tarefa: Uma tarefa (cuja noção está

associada a ‘como fazer alguma coisa’) é modelada em termos de

sua decomposição em suas subcomponentes, que podem ser: metas,

tarefas, recursos e/ou metas flexíveis (os quatro tipos de nós). Na

representação com elos de decomposição de tarefa apresentado na

Figura 2, a tarefa “B” é decomposta em uma (sub) meta: “submeta

M”; uma (sub) tarefa: “subtarefa S”; e uma meta flexível: “meta

flexível F”.

Figura 2 – Decomposição de tarefas.

(ii) Elos Meios-Fim: os elos do tipo meios-fim segundo [12]

representam relacionamentos do tipo uma meta a ser alcançada, uma

tarefa a ser feita, um recurso a ser produzido, ou uma meta flexível a

ser razoavelmente satisfeita (satisficed) nomeado como “fim” e os

“meios” alternativos para alcançá-los. Na Figura 2 a “Tarefa B”

representa o “meio” pois a noção de tarefa está associada a ‘uma

atividade que tem que ser feita’. Além disso, a notação gráfica do i*

apresentada na Figura 3 indica-nos que uma cabeça de seta aponta

dos meios para o fim. Os tipos de elos meios-fim estão descritos a

seguir:

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 25: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 1 – Introdução 25

Elo Meta–Tarefa – nesta ocorrência, o “fim” é especificado como uma meta

e o “meio” como uma tarefa. A tarefa especificada “como” através da

decomposição em seus componentes.

Elo Recurso–Tarefa – nesta ocorrência, o “fim” é especificado como

recurso e o “meio” como uma tarefa.

Elo Meta Flexível–Tarefa – nesta ocorrência, o “fim” é especificado como

uma meta flexível, e o “meio” é especificado como uma tarefa.

Elo Meta Flexível – Meta Flexível – nos elos deste tipo, tanto o “fim”

quanto o “meio” são metas flexíveis, permitindo o desenvolvimento de uma

hierarquia meios–fim de metas flexíveis. Isso permite que as metas flexíveis

sejam cada vez mais refinadas, até chegar a metas flexíveis mais fáceis de

operacionalizar [12].

Figura 3 – Elos meios-fim.

Na Figura 3 se representa o elo do tipo Meta–Tarefa, onde a meta “fim” tem

duas tarefas “meio” “A” e “B”.

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 26: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 1 – Introdução 26

Extensões do Framework i*

Este trabalho fará referência a algumas extensões sobre o framework i*

original: o modelo SA (Strategic Actor) [15]; situações de dependências

estratégicas (SDsituations) [16]; e painéis de intencionalidade (Diagramas IP)

[11]. Essas extensões serão detalhadas a seguir.

O Modelo SA – Strategic Actor

O objetivo do modelo SA [6] é modelar atores em i*. Ele auxilia no

entendimento dos atores e seus relacionamentos, do ponto de vista estrutural [3].

O modelo SA usa os conceitos de agente, posição e papel, definidos em [7],

para refinamento de atores e seus relacionamentos. A seguir serão descritos alguns

conceitos conforme [7]:

Ator - um ator é uma entidade ativa que executa atividades para atingir suas

metas conforme o exercício de seu conhecimento (know-how) e habilidades [7]. O

termo ator é usado para fazer referência a qualquer unidade à qual se possa

atribuir dependências intencionais [7], [12].

Posição - uma posição é formada por um conjunto de papéis

desempenhados por um agente [11]. Ele se localiza em um nível intermediário de

abstração entre um papel e um agente.

Papel: um papel é uma caracterização abstrata do comportamento de um

ator social em algum contexto especializado [7]. Onde suas características podem

eventualmente ser transferidas para outros atores sociais.

Agente - um agente é um ator com manifestações físicas concretas, tal qual

um ser humano [7]. O termo agente pode fazer referência tanto para humanos

quanto para agentes artificiais (hardware/software). Suas características

geralmente são intransferíveis para outros indivíduos, como habilidades,

limitações e experiências [7].

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 27: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 1 – Introdução 27

Conforme [15] um novo tipo de ator foi proposto para o relacionamento de

instanciação entre agentes: o agente real. Assim, é mais específico que o agente,

um agente genérico, e pode ser identificado, como por exemplo, uma pessoa

específica ou um software específico.

Um resumo dos relacionamentos descritos por Leite et al. em [15] os quais

fazem uso das definições e exemplos de [7] são descritos a seguir:

É um (IS A): relação de especialização de ator para ator, papel para papel,

posição para posição e/ou agente para agente.

Instância (INS): relacionamento de agente real para agente. Ou seja, Um

agente pode ter diferentes agentes reais como instancia.

Ocupa (OCCUPIES): relacionamento de agente para posição. Um agente

pode ocupar mais de uma posição e uma posição pode ser ocupada por mais de

um agente [12].

Cobre (COVERS): relacionamento de posição para papel. Uma posição

cobre mais de um papel e um papel pode ser coberto por mais de uma posição.

Desempenha (PLAYS) – relacionamento de agente para papel. Um agente

pode desempenhar mais de um papel e um papel pode ser desempenhado por mais

de um agente.

Parte de (is–Part–of): relacionamento de agente para agente, posição para

posição e de papel para papel. Agentes, posições e papéis podem ser ou podem ter

mais de uma sub-parte. Conforme [12] há uma restrição para este relacionamento

entre posições. Uma posição é parte de outra se todos os papéis desta posição

também são cobertos pela outra posição.

A Figura seguinte mostra um exemplo de um modelo de atores estratégicos

e seus relacionamentos.

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 28: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 1 – Introdução 28

Figura 4 – Ilustração de um modelo SA [11].

Situação de Dependência Estratégica – SDsituations

As SDsituations foram propostas por Oliveira et al. em [16] como uma

representação estruturada de situações de dependência estratégica entre atores

dentro de um contexto organizacional. Conforme [11] uma SDsituation reúne um

bloco de situações que compartilham um objetivo em comum.

Segundo [16] elementos de dependência como meta, tarefa, recurso ou meta

flexível os quais envolvem atores não estão isolados, por tanto, é uma situação

bem definida de colaboração que é conhecida como “situação de dependência

estratégica”. Além disso, uma SDsituation pode ser identificada separadamente

das outras SDsituations, formando uma cadeia de interdependências entre elas.

Conforme por Oliveira et al. em [16] existem três tipos de interdependências

entre SDsituations: física, lógica e temporal. Entretanto mais de um tipo de

interdependência pode ocorrer simultaneamente. Os três tipos de

interdependências serão descritos a seguir [11]:

Física – ocorre quando um recurso é preparado por uma SDsituation e é

solicitado por outra SDsituation.

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 29: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 1 – Introdução 29

Lógica – ocorre quando uma ou mais SDsituations necessita da conclusão

de outra SDsituation para sua iniciação, ou quando uma ou mais SDsituations

dependem da conclusão de outra SDsituation para sua conclusão.

Temporal – ocorre quando uma ou mais SDsituations necessitam esperar

algum tempo após o início de outra SDsituation ou quando uma ou mais

SDsituations necessitam esperar algum tempo após a conclusão de outra

SDsituation.

Figura 5 – Variantes de interdependência lógica das SDsituations [11].

Painel de Intencionalidade – Diagrama IP

Conforme [11], um “Painel de Intencionalidade” ou diagrama IP é um

modelo SR reduzido, onde são considerados os atores somente como proprietários

das metas, sendo que estas metas podem ser concretas e flexíveis e tem relações

entre elas. Toda a intencionalidade é representada em um único diagrama que é

guiado na sua construção pelas SDsituations, visando principalmente diminuir a

dificuldade de entendimento do diagrama SR, que é complexo por natureza.

Um diagrama IP possui nós e arestas. Os nós representam as metas

concretas ou as metas flexíveis, enquanto as arestas representam os tipos de

relações entre metas (Correlação, Contribuição, Equivalência, Dependência). Os

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 30: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 1 – Introdução 30

atores estão presentes no diagrama para indicar os responsáveis pelas metas. A

seguir, serão descritos os tipos de relações [2]:

Correlação: esta relação ocorre entre duas metas de um mesmo ator. Como

na Figura 6 a “meta w” é uma meta inicial que pode ser um subcomponente de

uma tarefa, sendo esta o meio para alcançar a meta principal “meta t”. Ou seja, o

sucesso da meta principal é determinado pelo alcance da meta inicial.

Contribuição: esta relação que ocorre ente duas metas flexíveis de um

mesmo ator. Na Figura 6 a meta flexível “Tipo 1 [tópico 2]” e chamada de meta

inicial, e contribui de forma negativa (“–”) para a outra meta flexível “Tipo 3

[tópico 1]”, em contraste, a meta flexível “Tipo 2 [tópico 2]” e uma meta inicial, e

contribui de forma positiva (“+”) para a outra meta flexível “Tipo 1 [tópico 2]” .

Dependência: esta relação ocorre entre duas metas de atores diferentes. Ela

representa a necessidade de satisfazer uma dependência entre dois atores, fazendo

uso da mesma semântica do diagrama SD. As dependências podem representar

uma tarefa, um recurso, uma meta flexível ou uma meta concreta que devem ser

descobertas no diagrama SD, ilustrado na Figura 6 por a “meta concreta w” e

“meta concreta r”.

Equivalência: relação entre metas concretas ou metas flexíveis.

Representam simplesmente que o relacionamento existe, as metas concretas ou

flexíveis são equivalentes para atores diferentes, na Figura 6 é representada esta

relação entre “meta concreta t” e “meta concreta y”.

Conforme [11] é recomendado que cada diagrama IP retrate apenas uma

SDsituation para manter o controle da complexidade.

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 31: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 1 – Introdução 31

Correlação

Equivalência

Dependência

Contribuição +

Contribuição -

Figura 6 – Ilustração de um painel de intencionalidade adaptado de [11].

Organização da Dissertação

Esta dissertação apresenta a construção de um jogo educacional com

modelagem intencional apoiado em conceitos de transparência. Seus capítulos

estão organizados da seguinte forma:

O Capítulo 2 apresenta um resumo dos jogos educacionais e principalmente

aqueles jogos para ensino na engenharia de software O Capítulo 3 apresenta a

descrição dos requisitos para a evolução do SimulES. O Capítulo 4 apresenta as

representações utilizadas para a modelagem do jogo e a nossa proposta de

modelagem intencional. O Capítulo 5 apresenta os trabalhos relacionados com a

modelagem intencional.

O Capítulo 6 detalha passo a passo a aplicação do mapeamento do modelo

até o código.

O Capítulo 7 apresenta as conclusões e contribuições deste trabalho, além de

sugestões para trabalhos futuros.

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 32: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

2 Jogos Educacionais

Jogos estão presentes como uma prática habitual, eles tem sido concebidos

como uma atividade lúdica que é bastante motivadora no processo de ensino-

aprendizado. É assim que jogos educacionais podem se transformar em uma

alternativa importante neste processo. Os jogos escolhidos apresentados a seguir

são uma pequena amostra de jogos educacionais para ensino na engenharia de

software que têm sido integrados em atividades curriculares, assim como também

temos identificado em alguns deles sua melhora ou evolução como ferramentas de

ensino tradicional em leituras, provas, tarefas e simulações. A idéia central é

analisar seus objetivos, atividades que realiza e métodos usados para suas

modelagens. Estes jogos possuem uma semelhança com o jogo SimulES, além de

serem jogos para o ensino na engenharia de software.

2.1.Visão Geral de Jogos Educacionais

Dentro dos métodos de ensino da engenharia de software em geral, se tem

aulas teóricas e trabalhos práticos. Há outros métodos menos explorados como os

jogos que podem completar o ensino tradicional. Em muitas áreas da tecnologia,

os jogos são usados como uma ferramenta de ensino, mas isso é raro no ensino de

engenharia de software. Na literatura encontramos alguns exemplos para ensinar

engenharia de software que serão apresentados a seguir. Os jogos escolhidos, além

de nos ajudar na contextualização de jogos educacionais, também serviram como

exemplo para entendermos como jogos educacionais estão sendo modelados:

2.1.1. O Jogo Problems and Programmers (PnP)

i. Objetivo do Jogo

É jogo de cartas educacional direcionado para o ensino de engenharia de

software [1], foi desenvolvido no Departamento de Informática e Ciências da

Computação da Universidade da Califórnia, Irvine (UCI). Alguns dos problemas e

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 33: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 2 – Jogos Educacionais

33

conceitos de engenharia de software que são abordados neste jogo são: a) Falta de

dedicar um tempo adequado para a documentação no início do projeto vai gerar

problemas mais tarde, b) quando se tem uma codificação precipitada o projeto

muitas vezes pode demorar mais tempo, c) quanto mais cedo os erros são

encontrados seus impactos serão menos negativos para o projeto, d) inspeções de

código reduzem tempo e quantidade de ciclos, além de permitir a detecção

precoce de erros, e) desenvolvedores habilidosos podem causar problemas se eles

são irresponsáveis ou se eles não seguem as boas práticas da engenharia de

software, f) adicionar mais desenvolvedores para um projeto muitas vezes pode

atrasá-lo.

ii. Objetivo no Jogo:

Seu objetivo é simular o processo de desenvolvimento de sistemas desde a

concepção até a fase de entrega do software de uma maneira competitiva entre

jogadores.

iii. Atividades realizadas no Jogo

No PnP os jogadores competem para terminar um projeto (carta projeto)

usando cartas de conceito, evitando os perigos potenciais da engenharia de

software (cartas problema). Com isso os jogadores irão aprender rapidamente que

as estratégias que vão deixá-los ganhar o jogo podem ser as mesmas que irão

ajudá-los no mundo real.

iv. Representações utilizadas para modelar o Jogo

Este jogo não possui implementação nem modelagem, seus artefatos, que

são impressos em papel e podem ser baixados da página oficial do jogo [1], foram

refinados com as retroalimentações recebidas. O PnP é importante para nós pois é

a base de alguns dos jogos apresentados neste capítulo, além do jogo SimulES,

nosso foco principal nesta pesquisa. Tanto o PnP como os jogos derivados dele

vem sendo utilizados e alguns deles já foram implementados como

apresentaremos a seguir.

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 34: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 2 – Jogos Educacionais

34

2.1.2. O Jogo SESAM

i. Objetivo do Jogo

SESAM (Software Engineering Simulation by Animated Models, por sua

sigla em Inglês) [2] é focado no ensino de gestão de projetos através de uma

simulação na qual se pretende:

• Demonstrar e explicar como os recursos utilizados, ou a abordagem

de gestão adotada em um projeto podem influenciar seus resultados

globais.

• Examinar as conseqüências da mudança do processo ou os recursos.

• Permitir treinar futuros gerentes de projeto, expondo-os à realidade

sobre problemas e situações típicas nos projetos.

• Permitir adaptação para ambientes de desenvolvimento específicos, a

fim de apoiar o planejamento do projeto e controle do projeto.

ii. Objetivo no Jogo

A idéia básica do jogo é criar um modelo do processo de desenvolvimento

de software e executá-lo usando um sistema de simulação. O modelo é

complementado por um cenário do projeto inicial. Assim, projetos de software

com uma determinada tarefa, ou determinados recursos ou restrições podem ser

simulados. O progresso do projeto simulado se reflete quantitativamente

utilizando vários processos e atributos do produto. Após a conclusão da simulação

tanto o processo como também os produtos resultantes podem ser analisados.

iii. Atividades realizadas no Jogo

Na Figura 7 ilustramos a tela principal do jogo, aqui podemos ver que no

menu principal do lado esquerdo estão descritas as ações possíveis dentro do jogo,

que são: carregar o modelo e os estados, salvar os estados e imprimir os estados e

as configurações. Tendo as informações prontas o jogador inicia a simulação.

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 35: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 2 – Jogos Educacionais

35

Figura 7 – Tela principal do jogo SESAM [2].

iv. Representações utilizadas para modelar o Jogo

Para sua modelagem foram criadas regras dentro da linguagem, ou seja,

regras que após de ser codificadas e executadas implementarão a simulação,

dividido em três partes: esquema, as condições e regras. Estudantes da

Universidade de Stuttgart foram responsáveis pelo desenvolvimento do software e

criação de documentos, incluindo: especificação, arquitetura, desenho e definição

e implementação de ambiente de trabalho, entre outros. Este projeto foi focado em

orientação a objetos e para sua implementação foi utilizado ADA95.

2.1.3. O Jogo SimVBSE

i. Objetivo do Jogo

Este jogo está focado no ensino do valor da engenharia de software [3], seus

autores justificam-se na premissa de que grande parte da engenharia de software

atual, tanto prática como de pesquisa, é feita ou baseada em um valor de definição

neutra. Assim:

• Todo requisito, caso de uso, objeto, caso de teste e defeito são

tratados como igualmente importantes.

• Métodos são apresentados e praticados amplamente como atividades

lógicas que envolvem mapeamentos e transformações (por exemplo,

desenvolvimento orientado a objeto).

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 36: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 2 – Jogos Educacionais

36

• O “valor ganho” é relacionado ao custo do sistema e do cronograma,

e não das partes interessadas ou do valor do negócio;

• Uma "separação de interesses" é praticada. As responsabilidades

dos engenheiros de software são limitadas em transformar os

requisitos do software em código verificado.

A maioria dos estudos do conceito “fator crítico de sucesso” são centrados

em descobrir qual é o valor básico e o que os interessados identificam como

predominante para o sucesso de um software. O objetivo deste jogo é integrar esse

valor considerando-lo nos princípios e práticas de engenharia de software.

ii. Objetivo no Jogo

Como jogo está focado no ensino do que eles definem como Valor crítico

de sucesso num processo de engenharia de software [3], os jogadores devem

identificar os interessados no sistema com aquilo que eles entendem como fatores

críticos de sucesso e/ou valores de preferência dentro de uma configuração

simulada. Do mesmo modo, deve-se determinar uma estratégia para equilibrar

esses valores definidos com os interessados identificados.

iii. Atividades realizadas no Jogo

Envolve principalmente identificar os interessados e seus valores de

preferência; raciocinar sobre as compensações e os diferentes aspectos do projeto

e do produto utilizando os valores considerados, e identificar um equilíbrio que

satisfaça os valores de preferência junto com os interessados.

iv. Representações utilizadas para modelar o Jogo

Seu desenvolvimento é baseado em protótipos, as informações são extraídas

de projetos, especificações e desenho de produto e se criam cenários no ambiente.

Os estudantes envolvidos do projeto SimVBSE se encarregam de evoluir cada um

dos protótipos criados.

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 37: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 2 – Jogos Educacionais

37

Figura 8 – Fluxo do jogo SimVBSE [3].

Na Figura 8 proporciona-nos uma ilustração de alto nível da estrutura

dinâmica do jogo. Fazer um movimento no jogo envolve visitar diferentes salas

que são mostradas na Figura na parte direita, e habilitar as opções que aparecem

na parte esquerda da Figura. Para o jogador, visitar as salas não consome recursos,

porém cada opção na esquerda pode custar uma quantia fixa de recursos.

2.1.4. O Jogo SimSE

i. Objetivo do Jogo

Permitir aos alunos praticar de forma “virtual” o processo de engenharia de

software (ou seus sub-processos) de uma forma totalmente gráfica [13], além

disso, permite saber a causa e efeito das complexas relações que permeiam os

processos da engenharia de software.

ii. Objetivo no Jogo

Completar um projeto de engenharia de software, no qual o jogador assume

o papel de gerente de projeto de uma equipe de desenvolvedores, O jogador tem

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 38: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 2 – Jogos Educacionais

38

por objetivo concluir o processo de produção, assim, ele pode contratar e demitir

engenheiros, atribuir tarefas, acompanhar seu progresso e comprar ferramentas.

iii. Atividades realizadas no Jogo:

Os alunos são orientados através da simulação e têm que lidar com o

orçamento, o tempo e as dificuldades típicas de um projeto na medida em que a

simulação está rodando, para isso os estudantes devem tomar decisões que podem

afetar positiva ou negativamente o projeto. No progresso desta simulação o aluno

pode ver os elementos do ambiente, bem como as informações sobre os

engenheiros (produtividade, tarefa atual e nível de energia), artefatos (tamanho,

integridade e precisão), clientes (nível de satisfação), projetos (orçamento e

tempo), ferramentas (numero de usuários, fator de aumento da produtividade). A

interação do jogador com os engenheiros é através de mensagem que o sistema

apresenta aleatoriamente. Estas informações servem para que o jogador tome

decisões e ações. No final do jogo o jogador recebe uma pontuação que indica

quão bem foram realizadas as atividades. Além de toda esta informação, uma

ferramenta explicativa fornece ao jogador mais informações sobre o seu jogo,

incluindo regras que foram desencadeadas, rastro dos eventos, e informações de

código versus tempo. Além disso, o jogador pode executar vários ramos paralelos

de um jogo e retornar a qualquer ponto anterior, gerar uma nova simulação ou

continuar com a simulação anterior.

Figura 9 – Tela principal do jogo SimSE tomado de [13].

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 39: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 2 – Jogos Educacionais

39

A Figura 9 mostra a tela principal do jogo SimSE, na parte direita ficam os

engenheiros de software que podem ser contratados durante a simulação, na parte

superior esquerda são apresentadas as condições iniciais e na parte inferior direita

os elementos para executar a simulação.

iv. Representações utilizadas para modelar o Jogo

SimSE tem diferentes versões as quais estão relacionadas a diferentes

processos de desenvolvimento de software, ele possui versões baseados nos

processos espiral, cascata, prototipagem e RUP, ou seja, cada versão ensina um

processo que também foi usado para criar seus modelos.

2.1.5. O Jogo Planager

i. Objetivo do Jogo

É um jogo para apoiar o ensino de conceitos de gerência de projetos [30]

de uma forma prática e iterativa focado para alunos de graduação.

ii. Objetivo no Jogo

Simular alguns dos processos utilizados na gerência de projetos,

principalmente processos de planejamento. Como gerenciamento do escopo e

gerenciamento do tempo. Na gerência de escopo foram escolhidos os processos de

definição do escopo e criação da EAP (Estrutura Analítica do Projeto). Na

gerência de tempo foram escolhidos os processos de definição da atividade,

seqüenciamento de atividades e desenvolvimento do cronograma (com foco no

cálculo do caminho crítico).

iii. Atividades realizadas no Jogo

Segundo [30] o jogador pode usar o modulo tutorial para aprender gerencia

de projetos ou pode jogar em diferentes cenários cadastrados na base de dados do

jogo, estes cenários são representações de projetos e cada um tem uma descrição e

cinco fases: fase escopo, fase EAP, fase definição de atividades, fase de

seqüenciamento de atividades e fase de caminho crítico. Os cenários são

seqüenciais onde cada cenário ou fase utiliza as informações dos cenários

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 40: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 2 – Jogos Educacionais

40

anteriores. A seqüência destas fases é a mesma utilizada pelos gerentes de projetos

quando planejam o escopo e tempo de um projeto.

iv. Representações utilizadas para modelar o Jogo

Para a sua modelagem foi utilizado UML. O sistema a ser construído foi

representado em casos de uso, diagramas de atividades, cenários e diagrama de

classes. É uma aplicação desktop de arquitetura cliente/servidor desenvolvida

usando JAVA JDK 5, possui dos tipos de usuários onde o usuário administrador

pode configurar novos cenários para serem executados na simulação.

2.1.6. O Jogo Scrumming

i. Objetivo do Jogo

Ensinar, através de simulação, as práticas ágeis de gerenciamento de

projetos, principalmente o SCRUM. Segundo [29] SCRUM é “um processo ágil

que permite manter o foco na entrega de maior valor de negócio, no menor tempo

possível. Isto permite a rápida e contínua inspeção do software em produção (em

intervalos de duas a quatro semanas conhecidos como sprints).”

ii. Objetivo no Jogo

Durante a simulação o jogador age como se fosse um SCRUM Master,

realizando tarefas como definir um sprint, monitorar o andamento do sprint

através do taskboard, visualizar o gráfico de burndown, adicionar ou remover

atividades do backlog, entre outras.

iii. Atividades realizadas no Jogo

O Scrum Master que se encarrega de aplicar os valores e práticas do Scrum,

remover obstáculos, garantir a plena funcionalidade e produtividade da equipe, e

garantir a colaboração entre os diversos papéis e funções.

iv. Representações utilizadas para modelar o Jogo

Para a sua modelagem foi utilizado UML, o sistema a ser construído foi

representado em casos de uso, diagramas de atividades e modelo entidade-

relacionamento. É uma aplicação desktop de arquitetura cliente/servidor

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 41: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 2 – Jogos Educacionais

41

desenvolvida usando JAVA JDK 6 e base de dados MySQL 5.0. Possui dos tipos

de usuários, o usuário administrador é um Scrum Master.

2.1.7. O Jogo X-MED v1.0

i. Objetivo do Jogo

Ensinar a medição de software [31]. Para alunos de pós-graduação em

cursos de computação e/ou profissionais da Engenharia de software.

ii. Objetivo no Jogo

Simular um programa de medição voltado a gerência de projetos alinhado

ao nível de maturidade 2 do CMMI-DEV [68].

Através da seleção de soluções adequadas de tarefas de medição, os alunos

são incentivados a aprender como desenvolver ou selecionar objetivos de

medição. O estudante assume o papel de um analista de medição e segue

seqüencialmente todas as tarefas de definir e aplicar um programa de medição.

iii. Atividades realizadas no Jogo

O jogo é composto das seguintes fases: fase 1 introdução ao jogo, fase 2

execução do jogo contendo os passos: passo 1 caracterização de contexto, passo 2

identificação do objetivo de medição, passo 3 desenvolvimento do plano GQM,

passo 4 Desenvolvimento do plano de coleta de dados, passo 5 Verificação de

dados, passo 6 Análise de dados, passo 7 interpretação de dados e por último, na

fase 3, temos a finalização do jogo. Em conclusão, o aluno não compete por

ganhar o jogo a idéia do jogo é a interpretação e análise dos dados gerados pela

simulação.

iv. Representações utilizadas para modelar o Jogo

Para sua representação basicamente foram usadas as classes do sistema,

Segundo [31] o jogo foi desenvolvido a partir de uma arquitetura em camadas,

utilizando classes de limite (interface com o usuário), classes de controle (regras

de negócio e fluxos de controle do programa) e classes de entidade

(armazenamento dos dados). É uma aplicação desktop de arquitetura

cliente/servidor desenvolvida usando JAVA JDK 6.

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 42: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 2 – Jogos Educacionais

42

2.1.8.O Jogo SimulES

i. Objetivo do Jogo

Jogo de tabuleiro educacional direcionado para o ensino de engenharia de

software, este jogo foi concebido a partir da evolução do jogo "Problems and

Programmers" (PnP) [1], que é também é a base de alguns dos jogos acima

referidos nas seções 2.1.2, 2.1.3 e 2.1.4. Na sua evolução foram acrescentados

conceitos de evolução do software, rastreabilidade e documentação de ajuda.

ii. Objetivo no Jogo

Construir um produto de software, onde o aluno assume o papel de gerente

de projeto e deve lidar com o orçamento do projeto, contratação e demissão de

engenheiros, e construção de diversos artefatos necessários para a culminação de

um projeto de software, entre muitas outras atividades. O jogador deve criar uma

estratégia que irá melhorar o seu jogo em relação à dos seus adversários, ao

mesmo tempo deve fazer jogadas que desestabilizem os jogos de seus adversários.

Mas eles podem responder com conceitos de engenharia de software e bloquear o

ataque do jogador. O primeiro jogador a construir todos os módulos ganha a

partida.

iii. Atividades realizadas no Jogo

Os jogadores executam uma serie de ações chamadas “Rodadas”, estas

rodadas estão dispostas seqüencialmente e todos os jogadores devem participar

delas de forma ordenada. O jogo possui as seguintes rodadas: inicio, ações,

conceitos, tratamento de problemas e submeter produto. Informações mais

detalhadas das rodadas estão presentes no Capítulo 3.

iv. Representações utilizadas para modelar o Jogo

Técnica de léxicos e cenários foram usadas para modelar as diferentes

evoluções de SimulES. No Capítulo 4 detalharemos essas representações.

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 43: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 2 – Jogos Educacionais

43

2.2. Resumo das Características dos Jogos

Na tabela 2 fazemos uma sínteses dos elementos mais importantes dos jogos

aqui apresentados, ressaltado o jogo PnP por ser a base do SimulES além de

outros jogos. O jogo SimSE também tem algumas semelhanças com o SimulES

como o objetivo dentro do jogo e o objetivo do jogo, somente que SimSE foi

projetado para um só jogador. Este jogo também possui uma documentação

detalhada sobre os diferentes modelos criados.

Tabela 2 – Resumo das características dos jogos.

Nome do Jogo Objetivo do jogo Objetivo no Jogo Modelagem do jogo

1. Problems and

Programmers (PnP)

Ensinar engenharia de

software.

Simular o processo de desenvolvimento

de software em cascata.

Não contém

2. SESAM Ensinar de gestão de

projetos.

Criar um modelo do processo de

desenvolvimento de software e

executá-lo usando um sistema de

simulação.

Documentação de

especificação, arquitetura,

desenho e definição e

implementação de ambiente

de trabalho.

3. SimVBSE Ensinar do valor da

engenharia de software.

Identificar os interessados no sistema

com aquilo que eles entendem como

fatores críticos de sucesso e valores de

preferência dentro de uma configuração

simulada.

Desenvolvimento baseado em

protótipos.

4. SimSE Ensinar processo de

engenharia de software.

Completar um projeto de engenharia de

software.

Possui diferentes modelagens

conforme à versão do jogo.

5. Planager Ensinar de conceitos de

gerência de projetos.

Simular alguns dos processos utilizados

na gerência de projetos, principalmente

processos de planejamento.

Orientada a objetos com UML.

6. Scrumming Ensinar através de

simulação as práticas

ágeis de gerenciamento

de projetos,

principalmente o SCRUM.

Fazer uma simulação assumindo o

papel de SCRUM Master.

Orientada a objetos com UML.

7. X-MED v1.0 Ensinar a medição de

software.

Simular um programa de medição

voltado a gerência de projetos alinhado

ao nível de maturidade 2 do CMMI-DEV.

Baseada na sua arquitetura,

ou seja, foi desenvolvido a

partir de uma arquitetura em

camadas.

2.3. Considerações Sobre Jogos Educacionais

Acreditamos que jogos podem despertar maior interesse por parte do aluno e

ajudar no aprendizado. Pesquisas cognitivas também sugerem que a percepção

humana e a ação estão profundamente interconectadas [32]. Desta forma, o uso de

jogos para treinar, aprender e executar atividades que imitam a realidade pode

melhorar o desempenho dos alunos, pois possibilita a vivência de experiências de

aprendizagem que não são fornecidas de forma teórica.

Os jogos explorados neste Capítulo nos dão uma idéia de como são os jogos

propostos para serem parte das atividades curriculares, ajudando a melhorar as

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 44: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 2 – Jogos Educacionais

44

ferramentas tradicionais de ensino, como leituras, provas, tarefas, simulações

entre outras. Estes jogos refletem distintos modelos pedagógicos, gêneros de

jogos, plataformas e usos.

Além disso, estes jogos representam de modo geral o feito até agora na

tecnologia de jogos educacionais para ensino na engenharia de software e as

abordagens atuais de modelagem e desenho.

Com a revisão desta literatura alguns questionamentos além dos

apresentados neste capítulo surgem, como por exemplo: econômicos (qual seria o

papel do software livre?), sociais (como entregaremos estes produtos, quem serão

os encarregados de treinar e como os professores integraram estes de forma

significativa a suas atividades curriculares?) e políticos (como serão incorporados

os jogos nos ambientes de aprendizado?), em resposta a estas oportunidades, esta

dissertação pretende evoluir o Jogo SimulES, utilizando uma modelagem

intencional apoiado em conceitos de transparência, e assim explorar estas

perspectivas e estes questionamentos e de algum modo criar uma experiência que

possa servir de base para futuras pesquisas.

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 45: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

3 Procurando Elementos de Evolução do SimulES

Aqui, é necessária uma explicação sobre o processo utilizado.

Figura 10 – SADT para SimulES-W.

Na Figura 10 descrevemos o processo seguido para a construção da versão

do SimulES v 4.0 ou SimulES-W apresentada neste trabalho.

Nós começamos com o estudo do SimulES, para isso procuramos as

informações disponíveis do jogo na versão 1.0 [6] e na versão 2.0 [4]. Da versão

2.0 utilizamos os léxicos e cenários e os elementos físicos para jogar e lograr um

melhor entendimento do jogo. Estes mesmos elementos serviram de base para

criação da primeira modelagem intencional do jogo apresentada no trabalho [44] e

que também foi utilizada para a realização da atividade detalhada neste capítulo.

Na Figura 10 correspondem as atividades Estudar, Jogar e Modelar.

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 46: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 3 – Procurando Elementos de Evolução do SimulES

46

A modelagem do trabalho [44] foi nosso primeiro insumo para começar a

prototipar a SimulES-W, o primeiro protótipo criado do jogo foi apresentado na

como Projeto Final de Programação, atividade prototipar da Figura 10.

Continuando com a implementação do SimulES-W tivemos a oportunidade de

realizar uma atividade de experimentação para identificar elementos de evolução

no SimulES além de avaliar a aceitação do jogo por parte dos estudantes, isso

aparece na Figura 10 como a atividade Experimentar. Finalmente foram

implementadas todas as SDSitutations identificadas e modeladas apresentadas no

Capítulo 6 deste trabalho e que corresponde na Figura 10 a atividade Implementar.

3.1. Contextualização

A diferença entre desenvolvimento e evolução é cada vez menos relevante.

Hoje, poucos sistemas são novos, o que tem maior sentido focar desenvolvimento

e evolução como atividades conjuntas e contínuas. Além disso, é pertinente

considerar a engenharia de software como um processo evolutivo, no qual o

software muda continuamente, como resposta a mudanças no universo de

informações (contexto).

A nossa perspectiva frente à evolução do SimulES é de potencializar seu

uso, além de propormos modelar-lo e implementar-lo de modo que facilite futuras

evoluções. Para complementar aquilo que se tinha feito até esta instancia

(modelagem intencional e começo da implementação), uma experiência realizada

na UERJ (Universidade do Estado do Rio de Janeiro) permitiu identificar as

expectativas que poderiam ter os usuários frente ao jogo. Para isso utilizamos

técnicas de elicitação de requisitos que nos ajudaram a descobrir estas

expectativas além de identificar elementos de evolução para incorporar na

evolução do SimulES.

Como já se mencionou, o objetivo desta atividade era de recolher

informações e elementos para a versão digital do SimulES, como também, para

avaliar, in situ, a participação dos jogadores. Isso será detalhado a seguir.

3.1.1. O SimulES

Antes de relatar o processo de elicitação aplicado neste trabalho para a

evolução de SimulES se faz necessário contextualizar nos conceitos mais

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 47: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 3 – Procurando Elementos de Evolução do SimulES

47

relevantes do jogo, conceitos que foram utilizados com os estudantes na

experiência realizada.

O texto apresentado nessa seção é fortemente baseado na monografia

documentada em [4] que corresponde com a versão 2.0 do SimulES. E nas

informações sobre o entendimento do Jogo de aqueles que de alguma ou outra

forma tem interagido com ele.

Na Figura 11 é ilustrado o processo que é seguido durante uma partida,

segundo o entendimento do jogo na versão 2.0 do SimulES. Na jogada de inicio é

escolhido o projeto que deverá ser tratado durante todo o jogo, aqui também é

escolhido o primeiro engenheiro de software para cada um dos jogadores. Na

jogada de ações deve se tratar os artefatos dispostos no tabuleiro individual (aqui

é possível construir artefato, inspecionar artefato, corrigir artefato ou integrar

artefatos em modulo). Na jogada de conceitos e tratamento de problemas serão

usadas aquelas cartas relacionadas com conceitos e problemas típicos da

engenharia de software, além disso, os jogadores serão atacados e atacarão seus

adversários e por ultimo temos submeter produto, o primeiro jogador que chegue

nesta instância e que satisfaça o critério de qualidade do software e que não tenha

penalidade alguma a ser resolvida, ganhará o jogo.

Figura 11 – Dinâmica do jogo SimulES v 2.0.

3.1.1.1. Recursos do Jogo

• Cartões do projeto:

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 48: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 3 – Procurando Elementos de Evolução do SimulES

48

São recursos dispostos no tabuleiro principal que apresentam as principais

informações do projeto a ser desenvolvido pelos jogadores ao longo do jogo. Um

exemplo de cartão de projeto é apresentado na Figura 12.

A seguir é feita uma breve descrição das informações contidas neste

recurso:

Descrição: texto em linguagem natural que descreve as principais

características do projeto. Esta descrição torna o jogo mais realista e ajuda o

jogador a compreender os principais requisitos do projeto a ser construído. Como

informação completar temos abaixo da descrição as referências para artigos e

livros relacionadas ao projeto ou seus principais conceitos.

Complexidade: indica quantos pontos de tempo um engenheiro de software

precisa gastar para construir um bom artefato, ou seja, nos informa qual é o valor

da carta branca. Artefatos de menor qualidade (carta cinza) custam metade deste

valor. A complexidade do projeto varia entre dois e quatro.

Tamanho: indica quantos módulos devem ser construídos e integrados para

que o produto software seja completado. O número máximo de módulos que um

projeto pode ter é seis. O cartão indica também a forma que os módulos devem ser

construídos. Por exemplo, o projeto “Expert Committee”, apresentado na Figura

5, é composto de cinco módulos, sendo o primeiro formado de duas cartas de

requisitos (RQ), uma de desenho (DS) e uma de código (CD).

Qualidade: representa o quão livre de defeitos (bugs) deve estar o produto

final. O valor varia entre um e cinco. Essa informação indica o número mínimo de

módulos sem defeitos necessários para submeter o produto e vencer o jogo. A

qualidade do sistema é verificada na fase de submissão do produto, após a

integração de todos os módulos especificados no cartão de projeto.

Orçamento: determina a quantidade de dinheiro disponível para gastar com

o projeto e representa também uma restrição para contratação de engenheiros de

software e para o uso de cartas de conceitos. Durante qualquer momento do jogo

os valores dos salários de todos os engenheiros somados aos custos das cartas de

conceito (caso estas tenham valor) não devem ultrapassar o orçamento do projeto.

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 49: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 3 – Procurando Elementos de Evolução do SimulES

49

Figura 12 – Exemplo de cartão de projeto SimulES v 2.0 [4].

• Tabuleiro Individual

Este recurso é uma área ou folha de papel na qual cada jogador coloca seus

engenheiros de software em colunas e os artefatos que vai construindo em linhas,

ela deve ficar em frente ao jogador a que pertence e suas informações são públicas

para os demais jogadores. Os artefatos podem ser dos seguintes tipos: requisito,

desenho, código, rastro e ajuda. A quantidade e tipos de artefatos a construir

dependeram do projeto escolhido no inicio do jogo. A Figura 13 apresenta o

tabuleiro do jogo SimulES, na ilustração os dois engenheiros de software

contratados já construíram vários artefatos. Como pode ser observado, as cartas

brancas e cinzas são colocadas nas células do tabuleiro, abaixo do engenheiro que

as construíram e nas linhas referentes aos seus tipos.

Figura 13 – Tabuleiro individual SimulES v 2.0 [4].

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 50: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 3 – Procurando Elementos de Evolução do SimulES

50

• Cartas de Problema e Conceito

Cartas de Problema: descrevem problemas clássicos de Engenharia de

Software resultantes de falhas no Processo de Desenvolvimento de Software.

Essas cartas são utilizadas para que os jogadores criem obstáculos ao progresso

dos jogos de outros jogadores. Além das informações de nome e um código, as

cartas de problema possuem outros atributos como (i) restrições ou condições a

serem satisfeitas por um jogador para que seu adversário lhe jogue o problema;

(ii) opcionalmente podem ter referências relacionadas; e (iii) efeito ou repercussão

que a carta vai dar ao jogo quando for utilizada. Um exemplo desse tipo de carta

é apresentado na Figura 14.

Figura 14 – Exemplo de uma carta problema do jogo SimulES v 2.0 [4].

Cartas de Conceito: descrevem boas práticas de Engenharia de Software e

podem ser utilizadas pelo jogador para neutralizar uma carta problema se as

condições de ambas cartas estão relacionadas. Os principais atributos das cartas de

conceito são: (i) uma literatura de apoio ou referência; (ii) efeito: minimiza ou

bloqueia as conseqüências das cartas de problema ou mesmo melhorar a

características do próprio jogo; e (iii) custo (nem sempre presente na carta) que

incorre em gastos após o conceito ser aplicado. Um exemplo desse tipo de carta é

apresentado na Figura 15.

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 51: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 3 – Procurando Elementos de Evolução do SimulES

51

Figura 15 – Exemplo de carta conceito do jogo SimulES v 2.0 [4].

Cartas de Engenheiro de Software: Com elas o jogador pode executar as

atividades referentes ao tabuleiro individual. Os engenheiros constroem,

inspecionam e corrigem artefatos que são necessários para o produto software ser

completado. Estas cartas apresentam os seguintes atributos: (i) nome; (ii) breve

descrição das características do engenheiro; (iii) salário a ser pago ao engenheiro.

É necessário verificar que a soma dos salários dos engenheiros de software

colocados no tabuleiro individual deve respeitar o limite de orçamento do projeto;

(iv) habilidade ou “pontos de tempo” que um engenheiro possui a cada rodada

para desempenhar ações no jogo, esta deve respeitar a complexidade do projeto; e

(v) maturidade que reflete a tendência do engenheiro de software em trabalhar

bem em equipe. A habilidade e a maturidade são medidas em uma escala de um a

cinco. Figura 16 nos ilustra duas cartas desse tipo.

Figura 16 – Exemplo de cartas de engenheiros de software SimulES v 2.0 [4].

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 52: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 3 – Procurando Elementos de Evolução do SimulES

52

Cartas de Artefato: simbolizam os produtos construídos pelos engenheiros

de software que podem ou não conter defeitos (erros ou bugs). Além disso, as

cartas de artefato podem ser de duas cores, branca ou cinza, de acordo com a sua

qualidade. Cartas brancas custam “pontos de tempo” segundo a complexidade do

projeto (Figura 12) para serem compradas e as cartas cinza custam a metade, as

cartas de cor branca contêm defeitos na proporção de 5 cartas para 1 defeito;

enquanto nas cartas de cor cinza esta proporção é de 3 para 2. Ou seja, sendo mais

custoso construir com carta branca pode trazer maior benefício na hora de fazer

inspeção nos artefatos, já que sua proporção de erro é menor.

Para vencer o jogo, é preciso completar os módulos do projeto definidos no

cartão de projeto selecionado no início do jogo. Após serem construídos, os

artefatos devem ser integrados e depois submetidos. A Figura 17 é um exemplo

desse tipo de carta (artefato).

Figura 17 – Artefatos (a) brancos com ou sem erro e (b) cinzas com ou sem erro

SimulES v 2.0 [4].

• Tabuleiro principal

Este recurso é a área ou folha de papel colocado no centro da mesa do Jogo,

em ele estão arranjados os recursos descritos acima, cartões de projeto, cartas

brancas e cinzas, cartas conceito e cartas problemas, assim como também os

engenheiros de software. O projeto escolhido deve ficar desvirado neste lugar para

que todos os jogadores possam vê-lo. Os lançamentos do dado também são

efetuados nesta área, como é mostrado na Figura 18.

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 53: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 3 – Procurando Elementos de Evolução do SimulES

53

Figura 18 – Tabuleiro principal de SimulES v 2.0 [4].

3.1.1.2. Papéis dos Jogadores

Jogador é um participante do jogo que tem por objetivo vencer o jogo. Em

uma partida ele pode desempenhar dois papéis:

Jogador da vez: participante ativo de todos os cenários do jogo, quando

através de seus engenheiros de software ele constrói, corrige e inspeciona

artefatos. Ou quando integra artefato ou submete produto.

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 54: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 3 – Procurando Elementos de Evolução do SimulES

54

Adversário: oponente do jogador da vez, principalmente, na rodada de

conceitos, no tratamento de problemas e na submissão de produtos. Este jogador

recebe cartas de problemas do jogador da vez.

3.1.2. Técnicas Utilizadas para Identificar Elementos de Evolução para o SimulES

A engenharia de requisitos é um processo sistemático de desenvolvimento

de requisitos. Esta atividade é feita através de um processo iterativo e cooperativo

de entendimento do problema, documentação das observações resultantes em

vários formatos de representação e análise da precisão do conhecimento obtido

[40]. As técnicas de elicitação escolhidas para a evolução do SimulES proposta

neste trabalho foram observação e questionário.

3.1.2.1. Observação

É uma técnica amplamente utilizada porque permite que o engenheiro de

requisitos esteja em uma posição passiva no contexto observado [41]. Esta técnica

é considerada importante, pois permite que o engenheiro de requisitos tenha um

contato suficientemente estreito com o fenômeno sob pesquisa. Assim, esta

técnica nos ajudou a fazer anotações da atividade e sobre as interações dos

jogadores como também o vocabulário utilizado.

3.1.2.2. Questionário

Permite ter uma idéia clara de certos aspectos do sistema ou contexto,

abrange um maior numero pessoas, além de permitir análise estatística [41]. Os

questionários são utilizados para avaliar os sistemas de podendo usar grande

número de respondentes, como é o caso de questionários para avaliação de sítios

Web [9], onde uma série de perguntas pode ponderar conceitos de transparência

que contribuem com a qualidade do software. Os questionários são um

instrumento útil naqueles casos onde usar reuniões ou entrevistas para fazer o

levantamento de requisitos é difícil [42], este foi o nosso caso uma vez que só

tínhamos um espaço de tempo fixo com todos os envolvidos no experimento que

efetuamos.

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 55: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 3 – Procurando Elementos de Evolução do SimulES

55

3.1.3. Usando as Técnicas de Elicitação para a Evolução do SimulES

Foi considerado adequado fazer um laboratório didático-pedagógico para os

estudantes, e principalmente aqueles que estão iniciando seus estudos na área da

computação.

Foi escolhido um grupo de 8 estudantes do mestrado em Geomática2 da

UERJ (Universidade do Estado do Rio de Janeiro) que conta com estudantes

formados em áreas como a estatística, cartografia, biologia, matemática além dos

alunos das ciências da computação. A idéia principal deste experimento foi o de

fortalecer o ensino de engenharia de software em os estudantes através do jogo

SimulES além de identificar os pontos fortes e fracos do jogo.

Foram distribuídos em formato impresso os cenários e um diagrama de

atividades para contextualizar aos participantes. Os cenários [18] são descrições

de situações em linguagem natural semi-estruturado, que nos permitem

compreender, padronizar, analisar, rastrear relacionamento de um sistema, como

também nos permite descrever as interações entre seus componentes. Nós

consideramos o cenário como uma notação adequada como material de apoio no

entendimento do jogo.

Na Figura 19 apresentamos um dos cenários que foram utilizados na

atividade feita com estes estudantes. Estes cenários pertencem à versão 2.0 de

SimulES [4].

Figura 19 – Exemplo de cenário SimulES v 2.0 [4].

2 http://www.geomatica.eng.uerj.br/

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 56: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 3 – Procurando Elementos de Evolução do SimulES

56

Ao distribuir todos os recursos e dar explicações básicas estávamos prontos

para jogar. Os alunos foram guiados através das diversas fases do processo de

desenvolvimento de software para a criação de artefatos de requisitos, desenho,

código, rastro e ajuda. Durante a construção dos diferentes artefatos os jogadores

foram alvo de cartas de problemas jogadas por os outros jogadores. Igualmente, o

jogador podia utilizar este mecanismo dentro do jogo para enfraquecer o jogo dos

outros. Com estas ações foram testados conhecimentos relacionados à engenharia

de software dos jogadores. Eles também foram aprendendo como usar as cartas

conceito que podiam neutralizar certas cartas problemas. Estas cartas são uma

compilação de problemas típicos de engenharia de software já testados em outras

aulas onde o jogo havia sido jogado.

Depois da experiência do jogo, um questionário foi aplicado. Isso permitiu

junto com as informações coletadas através da observação, identificar elementos

de evolução do jogo SimulES.

Tabela 3 – Questionário SimulES aplicado a estudantes da UERJ.

A Tabela 2 mostra o questionário e seu conteúdo. No total, foram 8

questões, 3 do tipo abertas e 5 fechadas. As questões abertas permitiram que os

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 57: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 3 – Procurando Elementos de Evolução do SimulES

57

alunos expressarem suas opiniões livremente e as fechadas permitiram um

tratamento estatístico.

O objetivo específico de cada uma das perguntas foi: (i) na primeira questão

queríamos identificar qual era a formação acadêmica dos jogadores, e assim

conhecer quão familiarizados eles estavam com conceitos de engenharia de

software e processos. (ii) a segunda questão nos permitiu saber, independente da

formação os jogadores, quanto envolvidos estavam ou participavam em atividades

relacionadas com a área. (iii) com a terceira questão pretendíamos determinar a

opinião dos estudantes com respeito a atividades práticas e iterativas, e se estas

podiam captar o interesse entre os jogadores. (iv) com a quarta questão a idéia era

identificar se uma abordagem mais prática e interativa realmente podia apoiar o

ensino tradicional. (v) na quinta questão, pretendíamos saber os pontos fortes do

jogo como um método de ensino. (vi) na sexta questão, pretendíamos identificar

problemas identificados pelos jogadores. (vii) na sétima questão queríamos

conhecer, sob a perspectiva dos alunos, quais eram os elementos que poderiam ser

melhorados dentro do jogo. (viii) e na oitava e última questão desejávamos avaliar

o nível de aceitação do jogo.

3.1.3.1. Análise das Perguntas Fechadas

Observe-se a seguinte análise na Figura 20: (i) na pergunta um (1) pode-se

observar que a grande maioria dos alunos não tinha formação em informática, por

serem estudantes de Geomática, aplicam conceitos de computação desde a

perspectiva de processamento digital de imagens, banco de dados, registros de

técnicas, sistemas SIG, cartografia digital e sistemas de posicionamento. Em

muitos casos, eles não estão familiarizados com os conceitos de engenharia de

software. (ii) do resultado da pergunta dois (2), pudemos determinar que a

participação dos alunos em áreas relacionadas à informática é o suficientemente

significativa (75%), onde, se sugere que a informação fornecida através da

atividade foi de utilidade dos alunos, pois a grande maioria dos estudantes atua na

área de informática como usuário, embora não conheçam os processos de

desenvolvimento de software (iii) com a pergunta três identificamos que o jogo

cumpria com as expectativas dos alunos. Um resultado motivador para continuar

com o projeto SimulES. (iv) a pergunta quatro indicou que a maioria dos

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 58: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 3 – Procurando Elementos de Evolução do SimulES

58

estudantes (75%) considerou o jogo como um mecanismo gerador de

conhecimento novo em tópicos de engenharia de software. (v) na avaliação final

do jogo SimulES os alunos acharam que era bom, sendo que metade deu o grau

máximo, ou seja, consideraram o jogo ótimo.

Figura 20 – Representação gráfica dos resultados das questões fechadas.

3.1.3.2. Análise das Perguntas Abertas

Os pontos positivos relacionados com as perguntas abertas estiveram entre

as informações mais destacadas fornecidas pelos alunos, assim: o jogo promove a

capacidade de desenvolver artefatos, atendendo sempre critérios de requisitos,

projeto, acompanhamento e testes, ele também incentiva a interação entre os

jogadores e trabalho em equipe e gera uma concorrência saudável.

Como pontos fracos os alunos relataram que o jogo foi confuso no início, só

após a segunda rodada eles conseguiram melhorar o entendimento, além disso,

relataram que a organização da atividade precisava de um planejamento melhor

com respeito à distribuição previa da informação do jogo, e que uma explicação

mais detalhada no inicio do jogo deve estar presente.

Como sugestões de melhora os alunos expressaram que o jogo deveria ter

menos variáveis e regras mais claras.

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 59: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 3 – Procurando Elementos de Evolução do SimulES

59

3.1.3.3. Utilizando a Técnica de Observação

Interação dos estudantes com o jogo: os estudantes estiveram atentos às

instruções iniciais do jogo, a informação impressa foi distribuída contendo

instruções e detalhes do jogo, mas não foi suficientemente atraente para os alunos.

Neste aspecto podemos tirar como lição aprendida que o material impresso deve

conter informações concisas, de fácil leitura e atraente para captar a atenção dos

estudantes, além disso, o pessoal envolvido na atividade deve ser informado

previamente.

Os termos contidos no jogo: os alunos foram guiados durante atividade

toda, o entendimento geral do jogo veio após da realização da primeira rodada.

- Na execução da jogada de conceitos e problemas os alunos sentiam se

inseguros para realizar suas jogadas principalmente aqueles que tinham pouco

conhecimento sobre os conceitos de engenharia de software, ou seja, as

informações contidas nas cartas conceito e problema em alguns casos não foram

entendidas pelos participantes ou não sabiam como podiam aplicar tanto conceitos

como problemas. Nós identificamos que o papel de instrutor é sempre importante

para orientar os estudantes principalmente nesta atividade, além disso, é

importante destacar que o jogo por si só não permitirá o desenvolvimento e a

aprendizagem. O instrutor deve se encarregar de reforçar os conceitos e

informações a que o jogo está se referindo, se a ação de jogar desenvolve a

compreensão, o instrutor servirá de guia durante todo o processo de aprendizado.

- Identificou-se que cartas problemas e cartas conceito podem ser

classificadas de acordo com o tipo de aluno que estarão envolvidos na atividade,

ou seja, as cartas podem ser tipificadas para reforçar conceitos de testes,

desenvolvimento de software, engenharia de software e assim por diante,

Dependendo das necessidades do grupo onde a atividade será aplicada.

- Uma análise do conteúdo das cartas problema e conceito deve ser

realizada para determinar se eles são o suficientemente claros, compreensíveis e

legíveis para os usuários que interagem com elas (cartas problema e conceito),

pois notamos que alguns não conseguiam entender os conceitos. Existem

mecanismos que permitem avaliar a transparência da informação [43] e qualidade

no conteúdo pode ser avaliados em atributos como: simplicidade, clareza,

uniformidade, intuitividade, corretude entre outros.

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 60: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 3 – Procurando Elementos de Evolução do SimulES

60

SimulES como um ambiente de fácil entendimento: Basicamente nós

identificamos duas questões que foram foco de difícil compreensão para os

participantes:

i) A jogada de conceitos consiste em duas atividades principais. Na primeira

temos envolvido o tabuleiro individual e os artefatos. Lá pode se construir

artefato, inspecionar artefato, corrigir e / ou integrar artefatos em um módulo. Na

segunda atividade se faz o lançamento do dado para a compra de cartas de

engenheiros de software e cartas de conceitos e problemas. Tudo isso dentro da

mesma jogada. As duas atividades que não têm uma aparente relação geraram

confusão entre os jogadores, portanto deve ser analisada uma maior desagregação

dos cenários, para aqueles casos em que as atividades não estão relacionadas umas

com as outras.

ii) A complexidade do projeto está diretamente relacionada à habilidade do

engenheiro de software para a construção de artefatos dentro do jogo. Por

exemplo: se a complexidade de um projeto é de 2, isso indica que os custos de

cada carta branca é de dois (2) “pontos de tempo” da mesma maneira, cada carta

cinza custará 1 ponto. Portanto, se o engenheiro de software tem habilidade de

quatro (4) só pode obter por jogada duas (2) cartas brancas ou quatro (4) cartas

cinza, de modo que cada vez que o jogador faz este movimento deve ter em sua

mente este cálculo, coisa que não foi assimilado prontamente no jogo.

Deste item surgiram duas importantes contribuições a nosso trabalho: na

primeira identificamos que a modelagem intencional pode ser pertinente quando

queremos modelar interação entre os jogadores, ou seja, partir do modelo

situacional com o qual contamos [4] para uma modelagem intencional que permita

representar elementos de interação. Segundo [7] modelagem intencional é

geralmente usada para modelar contextos organizacionais baseados nas relações

entre os atores. Os atores na modelagem intencional são participantes ativos deste

contexto organizacional, eles são entidades que estão obrigadas a ter e

alcançar objetivos através do exercício das suas competências e

conhecimentos. Estas metas podem ter dependências intencionais entre si, que

ocorrem quando existe uma relação entre os atores, assim nós acreditamos que é

pertinente para o contexto que pretende ser representado. Modelos intencionais

preliminares já foram desenvolvidos após esta atividade [44].

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 61: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 3 – Procurando Elementos de Evolução do SimulES

61

Outra importante contribuição que surgiu a partir desta experiência foi a

possibilidade de identificar situações e controles próprios do jogo suscetíveis de

sistematização. Assim delegando estas atividades ao sistema o estudante ou

jogador não teriam que lidar com elas e poderia concentrar-se nas atividades do

jogo que são relacionadas com os conceitos de engenharia de software. Portanto,

delegar ao sistema as tarefas de validação e controle poderia potencializar a

aprendizagem em engenharia de software dos estudantes durante o jogo.

3.1.3.4. Considerações Finais da Atividade

Nosso experimento demonstrou que técnicas de elicitação são importantes

não apenas para começar um novo software. Elas também são úteis sempre que há

necessidade de captar novos conhecimentos e no nosso caso, esse conhecimento

foi importante para a melhora e a evolução do SimulES.

A elicitação de requisitos é a primeira atividade que deve ser considerada ao

abordar o desenvolvimento de software. Apesar de ser a primeira atividade não

significa que isto aconteça uma vez, ele deve ser um processo iterativo e presente

em todas as etapas do software, por isso acreditamos que em todas as etapas da

evolução de SimulES se faz pertinente novos levantamentos para melhorar e

aperfeiçoar o produto final.

Para elicitar e modelar jogos é necessário levar em consideração a interação

entre atores e os elementos de seu ambiente. Modelar jogos usando uma

abordagem intencional é inovador, isso foi identificado com a literatura revisada,

pois nenhum dos jogos aqui descritos utiliza este tipo de abordagem.

Lembremos que o foco desta abordagem se baseia na análise das

dependências estratégicas entre os atores de um sistema. Portanto, seria então

possível representar as responsabilidades dos atores dentro do jogo.

Do mesmo modo, o jogo possui as seguintes características que

pretendemos sejam representadas: (i) regras já que o jogo tem organização e

coordenação que o inserem num quadro de natureza lógica, (ii) o jogo envolve

operações entre pessoas e contato social, o tratamento de problemas e a

utilização de conceitos que o jogo oferece dão ao participante oportunidade de

empregar procedimentos cooperativos para alcançar o objetivo que é ganhar o

jogo. (iii) o jogo assume um significado funcional onde a realidade é

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 62: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 3 – Procurando Elementos de Evolução do SimulES

62

incorporada e transformada no ambiente onde este é inserido. (iv) o jogo tem

natureza estrutural além das intenções e objetivos por trás dos jogadores. (v) os

jogadores possuem estratégias que são incorporadas ao jogo (vi) jogadores

possuem motivações, intenções e razões para executar as atividades. A utilizarmos

a modelagem intencional para evidenciar estes elementos que acreditamos de vital

importância, estaremos mais próximos de uma boa modelagem, importante para o

entendimento do contexto e futuras evoluções.

Se a tendência é que os jogos sejam considerados como um ambiente de

aprendizagem em determinadas áreas do conhecimento (exemplo, engenharia de

software) onde esta tendência crescente é abastecida por recursos tecnológicos

cada vez mais sofisticados, queremos responder a esta tendência visando melhoras

no ambiente do jogo SimulES. Para isso esperamos evoluí-lo com base nos

modelos intencionais gerados, além de explorar mecanismos que tornem mais

próximas modelagem e implementação.

3.1.3.5. Evolução do SimulES a Software

Na revisão da literatura identificamos que a modelagem de jogos

educacionais não considera a interação entre jogadores. Além disso, identificamos

que para o desenvolvimento de jogos educacionais na engenharia de software não

é prioritário usar modelos, em vários casos modelos foram omitidos ou tratados

superficialmente.

Outro motivo para o uso da modelagem intencional nesta evolução do

SimulES é a utilização destes modelos como insumo para a criação do protótipo

como uma forma de passar de forma mais transparente de modelos à

implementação. Essa modelagem evoluirá os léxicos e cenários previamente

definidos em [44]

Na criação do protótipo de SimulES-W estamos incorporando elementos de

transparência de software aqueles que permitiram descrição do que o software está

fazendo, levando em consideração o nível de compreensão do usuário.

Dentro desta evolução do SimulES exploramos aspectos pedagógicos como

incorporação de hipertexto como imagens e animações, interação entre nodos,

reprodução de situações reais em cenários por médio de interfaces, internet como

um mecanismo de comunicação, software em rede que permite trabalho

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 63: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 3 – Procurando Elementos de Evolução do SimulES

63

colaborativo e e-learning. Acreditamos que o uso das tecnologias e a rede podem

melhorar as estratégias de aprendizado.

Dentro dos aspetos de melhora reportados pelos usuários temos a

complexidade de regras e manejo de variáveis dentro do jogo. Como resposta a

estas observações feitas achamos que mecanismos de controle dentro do jogo

auxiliariam para que certas regras sejam validadas pelo sistema.

A versão do SimulES-W apresentada neste trabalho é projetada baseada

em modelos, métodos, técnicas e padrões de arquitetura e projeto para dar suporte

ao desenvolvimento de software com qualidade, com ênfase em sua natureza

evolutiva [46]. Além disso, projetamos o SimulES-W para que atenda diferente

tipos de usuários e para isso as cartas conceito e problema podem ser

customizadas como será apresentado no Capítulo 6.

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 64: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

4 Uso das Representações

Este Capítulo descreve as diferentes representações na modelagem do

SimulES ao longo das diferentes evoluções e versões que o jogo já teve; umas

abordagens baseadas em linguagem natural de léxicos e cenários e outra

abordagem de orientação a metas através do framework i*, base para a

representação das intencionalidade dos atores. Ao longo do Capítulo, será

apresentada a visão do uso de léxicos e cenários nas primeiras versões do jogo e

sua evolução e uso na segunda representação com o framework i*, apresentaremos

seus modelos SD e SR, além de novas técnicas, métodos e conceitos que

estendem o supracitado framework: o modelo SA (Strategic Actor), situações de

dependências estratégicas (SDsituations) e painéis de intencionalidade (diagramas

IP).

4.1. Contextualização

O jogo SimulES conta com diferentes versões que estão acompanhadas com

sua respectiva representação ao longo de sua vida, a primeira versão do jogo

proposta aparece no trabalho de Figueiredo [5]. Esta versão é identificada como a

versão 1.0 do jogo, para a representação do jogo foi utilizado léxicos e cenários.

A versão 1.0 foi a base para a evolução do SimulES apresentada em [4]

léxicos e cenários propostos nesta versão (versão 2.0) foram utilizados para

realizar nossa atividade na UERJ como foi descrito no Capítulo 3, além disso, esta

versão também foi utilizada para o entendimento do domínio e análise da

representação de léxicos e cenários ao longo deste trabalho. Finalmente esta

versão foi base dos primeiros modelos intencionais do jogo apresentados por

Napolitano em [44], sendo esta última a versão 3.0 do jogo.

Nosso trabalho apresenta a versão 4.0 do jogo que também será chamada de

SimulES-W.

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 65: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 4 – Uso das Representações

65

4.2. Representação de Requisitos em Linguagem Natural

4.2.1. Léxico Ampliado da Linguagem (LAL)

LAL (Language Extended Lexicon) [23] é uma técnica para descrever os

símbolos de uma linguagem. Usada nas diferentes evoluções do SimulES, é útil

pois permite a identificação de palavras ou frases do contexto social, conhecido

como o Universo de Informação (UdI).

Conforme [23], para o SimulES o LAL, na fase de requisitos, tem fornecido

uma organização explícita de conceitos e relações de contexto, o fator crítico de

sucesso na elicitação, modelagem e validação dos conceitos relacionados ao UDI.

Ao longo das evoluções do SimulES [5],[4],[44] tem sido utilizados léxicos

para descrever os símbolos do contexto do jogo.

Conforme o ilustrado na Figura 21 que corresponde à versão 2.0 do

SimulES, por exemplo, o símbolo jogador é considerada uma palavra chave

dentro do ambiente de SimulES, nesta versão do LAL o jogador pode assumir

dois papéis o jogador da vez e adversário.

Figura 21 – Representação no CEL do léxico usando a palavra chave “Jogador” v

2.0 [4].

Na terceira versão do jogo SimulES apresentada no trabalho [44] novamente

as palavras foram analisadas, classificadas em sujeito, verbo, estado e objeto, e

uma nova versão foi apresentada, isso deu origem a um léxico mais depurado.

Na Figura 22 é ilustrado o refinamento do símbolo jogador (versão 3.0 do

SimulES), além de apresentar papéis do jogador eles foram detalhados ainda mais

para dar maior entendimento ao símbolo, que é vital no desenvolvimento do jogo,

pois ele é um ator na maioria dos cenários.

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 66: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 4 – Uso das Representações

66

O LAL apresentado no trabalho [44] serviu de base para o inicio da

implementação do protótipo, já o léxico evoluído após do desenvolvimento do

SimulES-W está detalhado.

Figura 22 – Representação no CEL do léxico usando a palavra chave “Jogador” v

3.0 [44].

4.2.2. Cenários

Cenários tem sido empregados especificar o comportamento do SimulES

[5], [4], [44], pois sua estrutura permite a descrição das diferentes situações do

jogo com a vantagem que os cenários estão ligados diretamente ao LAL usando os

símbolos nele definidos.

Na Figura 23 podemos ver os cenários definidos para o jogo na versão 2.0

[4], uma seqüência de execução foi determinada e um cenário que estabelece essa

seqüência foi estabelecido, esse cenário é nomeado como Dinâmica do SimulES e

é conhecido como cenário integrador.

Figura 23 – Exemplo do comportamento dos cenários do jogo v 2.0 [4].

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 67: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 4 – Uso das Representações

67

4.2.3. C&L

O C&L é um software para edição de símbolos de léxico e de descrição de

cenários [22]. Sendo um software que disponibiliza um ambiente em que usuários

podem interagir para construir, manter, evoluir e gerenciar projetos contendo

cenários e símbolos do léxico. Tem sido possível usá-lo para modelar os

diferentes elementos do jogo SimulES.

O primeiro protótipo do C&L foi construído pela PUC-Rio no 2002 e

atualmente é o resultado da evolução de protótipos construídos por estudantes da

graduação, mestrado e doutorado do Departamento de Informática da PUC-Rio ao

longo destes anos. O C&L foi desenvolvido desde o início com a filosofia de

software livre e seu código fonte está disponível de forma aberta.

A Figura 24 representa a interface gráfica da ferramenta C&L utilizada nas

diferentes etapas de modelagem do SimulES.

Figura 24 – Interface do C&L usado para modelar elemento do jogo SimulES.

4.3. Representação Intencional dos Requisitos

A intencionalidade pode ser definida como a motivação ou interesses dos

atores em uma organização. Essas motivações ou interesses são representados e

modelados através de metas. A modelagem intencional baseia-se na visualização

do contexto organizacional e das relações de dependência entre os atores. Além

disso, esta modelagem permite-nos ver como os atores dependem uns dos outros

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 68: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 4 – Uso das Representações

68

para que os objetivos destas organizações sejam alcançados, os recursos sejam

disponíveis, as tarefas sejam feitas e as metas flexíveis cumpridas razoavelmente.

4.3.1. Framework i*

Como foi apresentado no capítulo de introdução o framework i* é

habitualmente usado para modelar contextos organizacionais baseados nos

relacionamentos entre os atores. Portanto, modelar em i* tem permitido obter uma

melhor compreensão dos relacionamentos dos jogadores e demais atores do jogo

nas etapas iniciais de desenvolvimento.

Atores em i* são participantes ativos do contexto organizacional, em nosso

caso o ambiente do jogo, além disso, em i* é possível representar como os atores

estão obrigados a alcançar objetivos através do exercício das suas competências e

conhecimentos, este último um dos motivos da escolha desta modelagem, pois

queremos criar modelos que refletem a interação entre os jogadores.

O framework i* propõe dois modelos, o modelo SD (por sua sigla em inglês

Strategic Dependency) e o modelo SR (por sua sigla em inglês Strategic

Rationale), modelos intencionais iniciais do SimulES são apresentados no

trabalho [44] e foram obtidos através do uso do método ERi*c [11].

4.3.2. O Método ERi*c

O método Engenharia de Requisitos Intencional – ERi*c [11] assim como o

framework i* está baseado no conceito de intencionalidade. O método propõe a

construção dos modelos i* através de seis etapas. Este método fornece algumas

contribuições importantes para processo de construção, como as situações de

dependência estratégica (SDsituations), a técnica AGFL (Agent Goals From

Lexicon) para elicitar metas dos atores, painéis de intencionalidade (diagramas

IP), entre outras contribuições.

Além disso, é um método simples de empregar no qual o engenheiro de

requisitos é auxiliado através das etapas para criar os modelos i* ocultando um

pouco a sua complexidade para que pessoas menos familiarizadas com este tipo

de modelagem também possam fazer uso dele, baseado no conceito de

intencionalidade também reflete as motivações e interesse dos atores.

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 69: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 4 – Uso das Representações

69

Para explicar as etapas do método ERi*c, esta dissertação irá utilizar os

modelos iniciais da modelagem intencional proposta para o jogo SimulES em [44]

que corresponde à versão 3.0 do jogo. A Figura 25 apresenta um esquema

simplificado do método.

Figura 25 – Visão geral do método ERi*c [11].

A Figura 25 ilustra as etapas do método, que foram seguidas para a primeira

versão dos modelos intencionais [44]. (i) Na primeira etapa, elicitar metas dos

atores, usando a técnica AGFL, é feita a elicitação a partir do LAL. (ii) Na

segunda etapa, identificar as SDsituations, define blocos de dependência que

compartilham intencionalidade situacional. (iii) Na etapa três, modelar as metas

dos atores, apresenta os painéis de intencionalidade, ou diagramas IP, modelando

em um diagrama apenas metas concretas e flexíveis e suas relações para cada um

das SDsituations identificadas. (iv) Na quarta etapa do método, modelar a

racionalização das metas dos atores, acontece o detalhamento de metas concretas

e flexíveis o que deriva na criação de modelos SR tomando como base os

diagramas IP, assim como também os modelos SD. A quinta etapa, especificar as

SDsituations, descreve as situações de dependência estratégica através da técnica

de cenários [18]. E a sexta etapa usa a técnica da análise i* diagnoses para

verificar modelos SD e SR.

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 70: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 4 – Uso das Representações

70

4.3.3. Modelagem Intencional do SimulES

Procurávamos uma modelagem para a representação da elicitação e

validação posterior onde fosse possível ganhar em rastreabilidade além de poder

aplicar conceitos de transparência. O uso da modelagem intencional auxilia a

transparência. A análise das representações usadas nos outros jogos nos mostra

que o uso da modelagem intencional é inovador.

4.3.3.1. Elicitar as Metas de Atores

A primeira etapa proposta pelo método divide–se em três atividades:

(i) Preparar o LAL – léxico estendido da linguagem

(ii) Definir AGFL – metas dos agentes vindas do léxico

(iii) Refinar as metas

4.3.3.1.1.Preparar o Léxico Ampliado da Linguagem

Para construir o LAL, identificaram-se as fontes disponíveis (pessoas e

documentos), segundo [11]. Para a refatoração do léxico foram seguidos os passos

recomendados em [11] construção do léxico. A tabela a seguir, presente em [22],

exibe as regras gerais para a definição de símbolos.

Tabela 4 – Regras gerais para definição de símbolos [22].

Noção Impacto

Sujeito Quem é o sujeito Quais ações ele executa

Verbo Quem realiza, quando acontece

e quais os procedimentos

envolvidos

Quais os reflexos da ação no ambiente

(outras ações que devem ocorrer) e

quais os novos estados decorrentes

Objeto Definir o objeto e identificar

outros objetos com os quais se

relaciona

Ações que podem ser aplicadas ao

objeto

Estado O que significa e quais ações

levaram a este estado

Identificar outros estados e ações que

podem ocorrer a partir do estado que se

descreve

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 71: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 4 – Uso das Representações

71

Esta prática melhora o entendimento do contexto e ajuda no refinamento do

vocabulário, a Figura 26 apresenta um exemplo do léxico do SimulES revisto em

[44] a partir de [4].

Figura 26 – Exemplo de símbolo do LAL para SimulES v 3.0 [44].

O foco desta atividade é descobrir a motivação (o porquê) de cada ação.

Segundo [2], quando uma ação muda de estado, esta ação define metas concretas.

Quando uma ação fornece uma “qualidade” a um estado, esta ação define metas

flexíveis. Nesta atividade foram identificados os atores e as metas relativas a eles

a partir dos impactos dos símbolos pertencentes ao LAL.

Segundo [23] no LAL os símbolos do tipo sujeito ou aqueles que praticam

ações sobre objetos são bons candidatos a atores. Na versão 2.0 de SimulES em

[4] somente havia o ator: Jogador, já na versão 3.0 do SimulES apresentada em

[44] incorpora o Jogador, Engenheiro de Software e SimulES como atores como é

mostrado na Figura 27.

Figura 27 – Símbolos tipo sujeito v 3.0 [44].

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 72: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 4 – Uso das Representações

72

4.3.3.1.2.Definir AGFL – Metas dos Agentes Vindas do Léxico

Uma vez identificados os atores (resultado mostrado na Figura 29), o passo

seguinte é de capturar as metas dos atores a partir do LAL. Sugere [11] o uso de

templates diferentes para símbolos do tipo sujeito, objeto, verbo e estado, levando

também em consideração metas concretas e metas flexíveis. Para descobrir cada

uma das metas é preciso responder o porquê.

Nas Tabelas 5, 6,7,8 e 9 mostramos alguns dos templates preenchidos, para

ações concretas e flexíveis do SimulES. E se pode observar a motivação

descoberta em cada impacto a partir da análise do “porquê”. Pode-se identificar

uma ação concreta quando esta é descrita por verbos pouco precisos como

(controlar, avaliar, apurar, por exemplo.). Já ações flexíveis são pouco concretas e

não se pode identificar um resultado concreto a princípio.

No caso de SimulES Tabela 5, o impacto do símbolo fornece recursos para

os jogadores ao ser analisado o “porquê” descobrimos metas que ele tem que

cumprir a cada rodada. Estas metas se fazem necessárias para que ele (SimulES)

efetivamente possa fornecer os recursos aos jogadores. Esta mesma heurística tem

que ser aplicada aos demais símbolos.

Tabela 5 – Template preenchido com metas dos símbolos do tipo sujeito [44].

TIPO: SUJEITO <meta concreta> ATOR –– impacto resposta ao porquê? <sujeito /

objeto LAL> seja / esteja

<verbo> <sujeito LAL>

SIMULES

–– fornece recursos para os jogadores.

Porque simules deseja que rodada de início

seja iniciada

Porque simules deseja que rodada de ações

seja iniciada

Porque simules deseja que rodada de conceitos

seja iniciada

Porque simules deseja que recursos sejam disponibilizados

Porque simules deseja que artefatos sejam comprados

Porque simules deseja que cartas sejam compradas

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 73: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 4 – Uso das Representações

73

Tabela 6 – Template com metas concretas do símbolo do tipo objeto [44].

TIPO: OBJETO <meta> ATOR –– impacto resposta ao por quê? <sujeito /

objeto LAL> seja/ esteja

<verbo> <sujeito LAL>

ARTEFATO

–– Engenheiro de software constrói artefato.

Para que produto seja construído por Engenheiro de

Software

Para que produto seja empacotado por Jogador da vez

–– Engenheiro de software inspeciona artefato.

Para que artefato seja livre de defeitos

Para que produto seja construído por Engenheiro de Software

–– Engenheiro de software corrige artefato.

Para que artefato seja corrigido por Engenheiro de

software

Para que produto seja construído por Engenheiro de Software

Tabela 7 – Template com metas flexíveis do símbolo do tipo objeto [44].

<meta flexível> –– impacto

resposta ao por quê? <TIPO

atributo de qualidade

[TOPICO]> sujeito/objeto

LAL

<meta concreta associada> <ator>

–– Engenheiro de software inspeciona artefato

ação flexível

Porque qualidade [artefato] Artefato seja inspecionado Engenheiro de Software

–– Engenheiro de software corrige artefato

ação flexível

Porque qualidade [artefato] Artefato seja corrigido Engenheiro de Software

–– jogador usa qualidade do projeto

ação flexível

Porque qualidade [projeto] produto seja concluído jogador da vez

Tabela 8 – Template com metas do símbolo do tipo verbo [44].

TIPO: VERBO <meta flexível> –– impacto

resposta ao por quê? <TIPO

atributo de qualidade

[TOPICO]> sujeito/objeto

LAL

<meta concreta associada> <ator>

APLICAR CONCEITO

–– jogador da vez neutraliza problema

ação concreta Conceito seja aplicado Jogador da vez

Tabela 9 – Template com metas do símbolo do tipo estado [44].

TIPO: ESTADO <meta flexível> –– impacto

resposta ao por quê? <TIPO

atributo de qualidade

[TOPICO]> sujeito/objeto

LAL

<meta concreta associada> <ator>

ARTEFATO DEFEITUOSO

–– Engenheiro de software pode corrigir artefato

ação concreta artefato seja corrigido Engenheiro de Software

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 74: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 4 – Uso das Representações

74

4.3.3.1.3. Refinar Metas

Conforme [11] após definir as metas dos agentes vindas do léxico, com o

fim de facilitar seu entendimento é necessário organizá–las, para facilitar a

identificação de situações de dependência.

A Tabela 10 mostra o template preenchido para o refinamento das metas

concretas e flexíveis agrupadas pelo ator o ator SimulES, as repetições são

excluídas e as metas são ordenadas cronologicamente, segundo [11].

Tabela 10 – Template para agrupar e organizar metas por ator cronologicamente

[44].

DEPENDER DEPENDEE

SIMULES

rodada de início seja iniciada

rodada de ações seja iniciada

rodada de conceitos

seja iniciada

recursos sejam disponibilizados

cartas sejam compradas por jogador da vez

artefatos

sejam comprados por jogador da vez

4.3.3.2.Identificar as Situações de Dependência Estratégica

Esta etapa tem três atividades:

1. Distinguir SDsituations

2. Reconhecer interdependências entre SDsituations

3. Construir diagrama de SDsituations

4.3.3.2.1.Distinguir SDsituations

Conforme [11], as SDsituations ou situações de dependência estratégia são

uma forma de representação estruturada de uma situação, e estão formadas por um

ou mais elementos de dependência no qual os atores participam através da

colaboração. Ou seja, uma situação é um bloco que faz parte de um modelo

intencional maior que através dos relacionamentos recíprocos de dependência

estratégica entre os atores têm a capacidade de concluir uma meta situacional.

Neste ponto, o objetivo em SimulES era identificar as metas que se inter-

relacionavam ou que formavam uma situação bem definida [11] isto é que

apresentem forte coesão de intencionalidade.

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 75: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 4 – Uso das Representações

75

4.3.3.2.2.Reconhecer Interdependências entre SDsituations

Ao observar as SDsituations se determinou suas interdependências físicas,

lógicas ou temporais. Ou seja, neste ponto se decidiu como as situações estavam

relacionadas dentro do processo, qual acontecia primeiro que outras e suas

condições necessárias.

4.3.3.2.3.Construir Diagramas de SDsituations

O resultado desta atividade é a representação gráfica de todas as situações

de dependência estratégica em um único diagrama [11], identificando o fator

tempo e as interdependências.

A Figura 28 mostra o diagrama de SDsituations para SimulES v 3.0. Na

Figura temos o seguinte: na atividade Joga Rodada de Inicio, a qual se executa

uma só vez ocorre no tempo T1, após é executada Joga Rodada de Ações a qual

está acompanhada de situações derivadas dela que podem ou não serem

executadas, tudo isso acontece no tempo T2, já para o tempo T3 as atividades

definidas foram Joga Rodada de Conceitos e de forma opcional Tratamento de

Problema, finalmente temos Submissão de Produto, neste ponto se o produto é

submetido a contento por algum jogador o jogo termina, caso contrario o jogo

volta para a SDsituation Joga Rodada de Ações.

Figura 28 – Diagrama de SDsituations do SimulES v 3.0 [44].

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 76: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 4 – Uso das Representações

76

4.3.3.3.Modelar as Metas dos Atores

A terceira etapa do método ERi*c propõe duas atividades:

1. Identificar agentes, posições e papéis

2. Criar painéis de intencionalidade

4.3.3.3.1.Identificar Agentes, Posições e Papéis

Quando as SDsituations são modeladas também identifica-se os atores que

trabalham ou colaboram para atingir as metas ou meta daquela situação, podendo

para isso, assumir posições e desempenhar papéis. Todas as metas elicitadas para

cada ator dentro de cada situação estratégica devem ser examinadas para verificar

se existem posições ou papéis que possam ser definidos. A Figura 29 de SimulES

3.0 apresenta aqueles símbolos tipo sujeito que foram identificados na etapa

Preparar o Léxico Ampliado da Linguagem, podemos observar que o SimulES

como fornecedor de recursos se encarrega de coordenar os recursos durante o

jogo, o jogador, que são alunos participantes do jogo, pode assumir a posição de

jogador da vez quando é a sua jogada e tem que executar o papel de gerente de

projeto ou adversário quando está recebendo um problema, escolhendo ou

inspecionando modulo de outro jogador, neste último, seu papel é de auditor e por

ultimo temos os engenheiros de software que são as cartas dispostas por SimulES

e que se encarregam de produzir o produto.

Figura 29 – modelo SA para SimulES v 3.0 [44].

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 77: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 4 – Uso das Representações

77

4.3.3.3.2.Criar Painéis de Intencionalidade

Cada painel de intencionalidade ou diagrama IP representa uma SDsituation.

Cada ator em um diagrama IP possui um eixo com a ordenação das metas nas

quais participa, de baixo para cima, de modo que as metas iniciais fiquem na parte

de baixo do eixo finais fiquem na de cima.

A Figura 30 apresenta o diagrama IP da SDsituation Joga Rodada de Inicio

do SimulES 3.0. Na construção deste tipo de diagrama é importante fazer a análise

com um ator de cada vez, progressivamente, representando primeiramente as

relações de contribuição (entre metas flexíveis), seguidas das correlações (entre

metas flexíveis e metas concretas) e por fim, devem–se representar as relações de

dependência entre as metas concretas dos atores. Porém na Figura 30 podemos ver

que meta a ser cumprida é rodada de inicio seja iniciada e como responsável

temos SimulES, mas esta meta somente é alcançada se SimulES disponibiliza os

recursos, após vemos o Jogador da vez que é o encarregado de iniciar o jogo,

quando jogada de dado é executada, sendo esta última uma precondição para que

o projeto seja escolhido e projeto seja aceito, depois cada jogador contrata seu

engenheiro de software.

Figura 30 – Diagrama IP – Joga Rodada de Início do SimulES v 3.0 adaptado de

[44].

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 78: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 4 – Uso das Representações

78

4.3.3.4.Modelar a Racionalização das Metas dos Atores

(i) Construir Modelos SD

(ii) Construir Modelos SR

4.3.3.4.1.Construir Modelos SD

Para usar o método nesta atividade, se retomam os artefatos elaborados

previamente, bem como diagramas IP, AS e SDsituations. Ressaltado que para

cada SDsituations se deve construir um diagrama SD. É preciso analisar cada

SDsituations e seu correspondente diagrama IP identificar entre os quatro tipos de

dependência disponível, ou seja, por meta concreta, por meta flexível, por recurso

ou por tarefa e identificar os “dependee” (de quem se depende) e os “depender”

(que depende), dependendo do grau de liberdade na relação de colaboração. Como

mostra a Figura 31 com esta análise, se deriva na criação do diagrama SD com os

atores e as dependências modeladas, é importante ressaltar que o principal insumo

para a criação deste diagrama é o diagrama IP do qual se extraem a maioria das

metas aqui representadas.

Figura 31 – Modelo SD – Joga Rodada de Início do SimulES v 3.0 [44].

Como é ilustrado na Figura 32 do SimulES 3.0 o modelo SR tem como

objetivo representar as estratégias internas de cada ator, neste caso SimulES,

Jogador da vez e Adversário. O modelo SR fornece uma descrição intencional do

processo que é realizado para que a situação Rodada de Inicio seja realizada. O

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 79: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 4 – Uso das Representações

79

modelo SR permite representar explicitamente o entendimento detalhado do

raciocínio dos atores envolvidos no processo.

Figura 32 – Modelo SR – Joga Rodada de Início do SimulES v 3.0 [44].

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 80: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 4 – Uso das Representações

80

4.3.3.5.Especificar as SDsituations

Maximizando o uso do LAL na descrição de cada SDsituation como é

sugerido em [11], observa-se que cada símbolo é destacado em azul e a sintaxe

própria da técnica de cenários foi usada para descrever e detalhar cada

SDsitutations [44] veja um exemplo na Figura 33.

Figura 33 – Descrição através de cenários de SDsituation Inspeção de Artefato do

Simules v 3.0 [44].

4.4. Análise das Representações de Requisitos Usadas

Como foi apresentado ao longo do capítulo diferentes abordagens tem sido

usadas para modelar SimulES, a modelagem situacional de léxico e cenários dos

trabalhos [5] e [4] e outra intencional baseada no framework i* [44]. Estes

trabalhos trazem pontos interessantes que foram explorados como base desta

dissertação e que são considerados relevantes na estruturação da implementação

do protótipo de SimulES-W ou versão 4.0 do jogo. O trabalho [4] correspondente

à versão 2.0 foi o ponto de partida para o entendimento do contexto e foram base

para a realização de atividades de elicitação de requisitos mencionadas no

Capítulo 3 na versão 3.0, que apresenta os modelos intencionais iniciais do

SimulES [44], conseguimos identificar maior detalhamento e a possibilidade de

representar intencionalidade. A efetividade destes modelos será detalhada no

Capítulo 6 onde mostraremos como foi aproveitada a modelagem intencional para

a criação de SimulES-W e detalharemos o refinamento da mesma.

A seguir exploraremos trabalhos relacionados ao uso da modelagem

intencional, como também trabalhos relacionados com a transparência de

software. A finalidade é focar a evolução do SimulES em uma combinação de

modelagem intencional apoiado em conceitos de transparência.

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 81: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

5 Trabalhos Relacionados

Este capítulo apresenta uma análise de algumas propostas sobre a

modelagem intencional e a transparência de software base de nosso trabalho.

5.1.Modelagem Intencional Casos Práticos

Dentro de nosso trabalho temos como proposta a criação de um protótipo

baseado nos modelos intencionais, portanto tivemos a necessidade de pesquisar

trabalhos que utilizaram este tipo de modelagem e os mecanismos que eles

utilizaram para passar dos modelos até a implementação. No Capítulo 2

apresentamos as diferentes abordagens de modelagens usadas em jogos

educacionais para ensino na engenharia de software, identificamos que alguns

casos não foi usado nenhum método ou não possuíam suficiente informação

relacionada com esta parte do processo. Nosso foco nesta sessão é explorar a

metodologia intencional e identificar aspectos uteis das experiências aqui relatadas

para o nosso trabalho no SimulES.

5.1.1.Estendendo Tropos para uma Implementação em Prolog: um Estudo de Caso Usando o Problema do Agente Coletor de Alimentos (FCAP) [49]

A metodologia Tropos é centrada nos requisitos e no Framework i* que

permite reduzir incompatibilidade entre o sistema e seu ambiente. Esta possui

ator, agente, posição, papel e as dependências entre eles; permitindo dependências

por metas, tarefas e recursos.

Estes conceitos não somente são usados na produção de requisitos, mas

também são usados nas fases de arquitetura e desenho detalhado.

A abordagem do artigo é orientada ao Tropos e para a implementação

utiliza-se Prolog.

As fases do método Tropos são descritos de forma geral:

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 82: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 5 – Trabalhos Relacionados

82

(i) Requisitos iniciais: cujo objetivo é o entendimento do problema a

partir da análise da organização. Nesta fase se faz o modelo de

dependência estratégica (SD) para descrever os relacionamentos

entre atores e o modelo de raciocínio estratégico (SR) para

identificar as estratégias internas de cada ator. Para o caso FCAP

(pelas siglas em inglês de Food Collecting Agent Problem) esta fase

é omitida, pois não se tem um contexto social.

(ii) Requisitos finais: onde é incluído explicitamente o sistema com o

seu ambiente operacional, a partir dos requisitos funcionais (metas)

relevantes e requisitos de qualidade (metas flexíveis), nesta fase

também se identificaram os agentes do grupo coletor e provedor de

alimentos, suas dependências são restrições de comportamento como

se mostra na seguinte Figura.

Figura 34 – Identificação de atores genéricos para FCAP [49].

(iii) Arquitetura: o objetivo desta fase é a definição global da

arquitetura em termos de subsistemas e suas dependências, modelo

da arquitetura do sistema e modelagem em partes pequenas para que

sejam facilmente gerenciáveis, desta forma se descreve como os

agentes funcionam através de seus papéis. Nesta fase para FCAP

identificaram-se novos agentes, suas principais capacidades e cada

um dos papéis para os agentes. Também foi definida a posição

teamMember para representar todos os membros da equipe.

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 83: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 5 – Trabalhos Relacionados

83

Figura 35 – Descrevendo papéis de agentes em FCAP [49].

(iv) Desenho: é refinado cada componente arquitetural através de

comunicação entre agentes, mecanismo de transporte de mensagens,

ontologias e protocolos. Produz-se o diagrama de classes de agentes,

diagrama de interações, diagrama de capacidades e diagrama de

planos.

Para FCAP cada agente foi decomposto e foram especificadas suas

capacidades como também suas crenças, foram também atualizadas

as dependências para FCAP (omitiu-se as contribuições de metas

flexíveis entre os atores para dar simplicidade a o diagrama).

Figura 36 – Decomposição de cada agente FCAP [49].

(v) Implementação: Tropos propõe um diagrama de atividades, mas

para FCAP, foram usadas seqüências de cenários.

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 84: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 5 – Trabalhos Relacionados

84

Em Prolog foram implementadas as seqüências acima citadas, pois

provém metas lógicas e raízes de planos, também se propuseram

quatro atributos de implementação chamados begin, at end, at call

and always.

O mapeamento do desenho até a implementação foi feito através da

instanciação dos predicados (agentes, papéis, posições), ou seja, os

relacionamentos definidos em Tropos.

Este método mostra explicitamente o levantamento de requisitos

feito através do framework i*.

A solução proposta utiliza uma técnica de levantamento de requisitos

através de cenários, sendo esta uma boa prática que permite justificar os

elementos que estariam presentes tanto na modelagem como na implementação.

Alem disso, este trabalho mostra a instanciação dos elementos modelados até a

implementação.

5.1.2.“Tropos: uma Metodologia de Desenvolvimento de Software Orientada a Agentes” [50]

Baseado em Tropos foi desenvolvida uma aplicação nomeada eCulture para

o governo de Trentino (Provincia Autónoma de Trento, o PAT) na qual um agente

Web fornece informações e serviços culturais da PAT para cidadãos e turistas que

procuram coisas para fazer, e para os estudantes que procuram material relevante

relacionado a estudos. As informações fornecidas são obtidas de museus,

exposições, organizações culturais entre outros.

(i) Requisitos iniciais: neste ponto se identificou e analisou as partes

interessadas (interessados) e suas intenções. Os interessados foram

modelados como atores sociais. As dependências entre eles foram

modelados visando que: objetivos sejam alcançados, tarefas sejam

realizadas e recursos utilizados. As intenções modeladas nesta etapa

através de uma análise orientado a metas serão decompostas ou

refinadas em fases posteriores.

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 85: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 5 – Trabalhos Relacionados

85

Como resultado desta atividade na Figura 37 é apresentado o

diagrama de atores do contexto de eCulture. O ator cidadão é

associado a uma meta concreta “obter informações culturais” e

turistas tem associada a meta flexível “desfrutar da visita”. No

mesmo sentido, PAT quer aumentar o uso da internet enquanto o

museu pretende oferecer serviços culturais. Finalmente o diagrama

ilustra a dependência da meta flexível onde o cidadão depende de

PAT para que impostos sejam bem gastos.

Figura 37 – Diagrama de atores, modelando os stakeholders do projeto eCulture

[50].

Já na Figura 38 os autores descrevem que a meta “obter informação

cultural” do ator Cidadão é descomposta em “visitar instituições culturais” e

“visitar sitios Web culturais”. Estas duas sub-metas podem ser vistas como

maneiras alternativas do cumprimento da meta principal.

A decomposição de uma meta pode ser feita através do relacionamento

meios-fim e sua análise tem como objetivo identificar as tarefas, recursos e metas

flexíveis que fornecem meios para atingir a meta. Neste trabalho, a tarefa “visitar

o sistema eCulture” é um meio para cumprir a meta “visitar sítios Web culturais”

esta tarefa é decomposta em dois sub-tarefas nomeadas “usar sistema eCulture” e

“acesso à internet” os quais são as razões para o conjunto de dependências entre

cidadão e PAT: “Sistema eCulture esteja disponível”, “infra-estrutura da internet

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 86: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 5 – Trabalhos Relacionados

86

esteja disponível” e “Sistema eCulture esteja usável”. A análise do visitante pode

ser mais simples “o plano para visitar” pode dar uma contribuição positiva para a

meta flexível “desfrutar a visita” e para isso o visitante precisa que o “Sistema

eCulture esteja disponível”.

Figura 38 – Diagrama de metas para Cidadão e Visitante. Observe se a meta e

plano de decomposição, a análise meios-fim e a contribuição positiva à meta

flexível [50].

(ii) Requisitos finais: incide sobre o que o sistema a ser ou system-to-

be, ou seja, o sistema eCulture no seu ambiente operacional, junto

com suas funções e qualidade relevante. Por tanto, sistema a ser é

representado como um ator que tem dependências com os atores da

organização, estas dependências são as que definirão os requisitos

funcionais e não funcionais do sistema.

O diagrama de atores na Figura 39 representa o sistema eCultura e

apresenta um conjunto de metas concretas e metas flexíveis que PAT

(Provincia Autónoma de Trento) delega para ele.

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 87: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 5 – Trabalhos Relacionados

87

Figura 39 – Segmento do diagrama de atores incluindo PAT e o sistema eCulture e

o diagrama de metas do sistema eCulture [50].

(iii) Arquitetura: nesta fase é definida a arquitetura global do sistema

em termos de subsistemas (atores) interligados através dos dados e

os fluxos de controle (dependências).

Esta fase é decomposta em três etapas. Na primeira etapa foram

identificados novos atores após uma análise das metas do sistema, da

escolha da arquitetura, padrões e estilo, e da inclusão de atores que

contribuem positivamente para a realização dos requisitos funcionais

e não funcionais. Após finalizada a primeira etapa o diagrama de

atores é estendido, onde, o diagrama de atores produzido é analisado

em detalhe para identificar as capacidades necessitadas pelos atores

para exercer suas metas e tarefas. O último passo consiste em definir

um conjunto de tipos de agentes e atribuir a cada um eles um ou

mais recursos diferentes.

(iv) Desenho: nesta fase se lida com a especificação a nível micro dos

agentes. Ou seja, metas, crenças e capacidades dos agentes assim

como também a comunicação entre eles são especificadas. Além

disso, segundo descrevem os autores em [50] esta etapa está

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 88: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 5 – Trabalhos Relacionados

88

relacionada com as escolhas da implementação. Eles representaram

as capacidades e planos dos agentes usando diagramas de atividades

UML e diagramas AUML [69] para especificar os protocolos dos

agentes.

(v) Implementação: o ambiente de desenvolvimento orientado a agente

usado foi JACK e está integrado à linguagem Java. Os agentes em

JACK são componentes de software autônomos com metas

explicitas a serem executadas, além disso, são programados com um

conjunto de tarefas (planos) a fim de tornar-los capazes de atingir as

metas. Conforme os autores, as especificações de seções anteriores

tem correspondência com a implementação em JACK, pois neste

ambiente de programação é possível definir agentes, capacidades,

crenças, eventos e tarefas (planos) segundo é apresentado na Figura

40 que ilustra um fragmento do ambiente Jack para o sistema

eCulture.

Figura 40 – Ambiente de desenvolvimento JACK para projeto eCulture.

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 89: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 5 – Trabalhos Relacionados

89

5.1.3.“Uma Abordagem para Modelagem Intencional de Avaliação de Riscos de Segurança em Web Services” [51]

O aumento nos últimos anos do comércio eletrônico e serviços bancários

eletrônicos estão levando com que os principais fornecedores de pagamentos

eletrônicos fiquem preocupados com oferecer a seus clientes garantia e segurança

de suas informações pessoais as quais são fornecidas pelos clientes de forma

online. É neste contexto que os autores deste trabalho usam um exemplo de uma

empresa X que tem que proteger seu negócio on-line de venda do produto Y.

Os conceitos associados com a modelagem de dependências de atores têm

suas raízes na Engenharia de Requisitos (RE por suas siglas em inglês). Os

métodos de RE podem ser usados para modelar as metas organizacionais,

processos, relações e atores e executar uma avaliação de risco com boa qualidade,

o qual é necessário para compreender a organização de uma forma clara. Estas são

as justificativas conforme [51] para a escolha da modelagem intencional.

Conforme [51] i* é baseado na Engenharia de Requisitos (RE) e pode ser

considerada uma poderosa ferramenta que auxilia na modelagem de tarefas

organizacionais, processos, atores e metas. Assim como também permite que os

engenheiros de requisitos modelem, em detalhe, processos atuais para modificá-

los, a fim de aperfeiçoar, melhorar e aumentar a produtividade da empresa. Todos

esses benefícios podem ser obtidos muito cedo, mesmo quando o projeto ainda

esteja por começar. i* explora "porquê" os processos são realizados na forma

existente. O Comportamento esperado do software e sua razão de ser também

podem ser modelados usando i *. No entanto, i* não “leva diretamente” em conta

a precisão, integralidade e consistência como UML faz. Em contraste, i* leva em

consideração principalmente os interesses dos atores, suas metas, razões, tarefas e

preocupações.

Este trabalho usa i* para a modelagem dos requisitos e elementos de gestão

de riscos para ajudar aos gestores de riscos a identificar, monitorar, analisar e

controlar os riscos, tudo desde um ponto de vista de metas. i* fornece uma análise

qualitativa da viabilidade do projeto sob vários cenários. No contexto deste

trabalho, essa análise permitiu verificar as ações necessárias para controlar os

riscos. Ou seja, se as metas do projeto podem ser satisfeitas nos cenários

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 90: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 5 – Trabalhos Relacionados

90

estudados. Para cada projeto, os requisitos podem ser modelados como metas

concretas e metas flexíveis a serem alcançadas.

Figura 41 – Diagrama SD para o Web Service baseado em cartões de pagamento.

A Figura 41 representa as dependências entre os atores do sistema

inteligente de cartões de pagamento que suporta os Web Services. A dependência

por meta "Conta seja gerenciada" indica que o titular do cartão (Cardholder)

precisa do proprietário dos dados (Data Owner) para gerenciar a conta. O

Proprietário dos dados, por outro lado, espera pagamento do titular do cartão que

é representada pela dependência por recurso pagamento (Payment). Além disso, a

meta flexível “Ler/Escrever no cartão corretamente” é uma dependência difícil de

determinar pelo significado qualitativo de "corretamente". A dependência por

tarefa "Transmissão de Dados" indica que o proprietário dos dados que precisa do

proprietário do terminal (Terminal Owner) para transmitir dados; proprietário do

terminal tem que executar a transmissão como definida pelo proprietário dos

dados (Data Owner).

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 91: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 5 – Trabalhos Relacionados

91

Figura 42 – Tipos de atores do Web Service baseado em cartões de pagamento

[51].

Na Figura 42 são ilustrados os diferentes tipos de atores identificados para o

sistema. A Figura 43 ilustra o diagrama de SR para papéis do sistema de

pagamento. O titular do cartão tem uma meta interna “Comprar bens com o

cartão inteligente.” Se titular do cartão usa cartão para fazer isso, então, titular do

cartão tem que efetuar a tarefa interna "Usar o cartão.". A meta “Comprar bens

com o cartão inteligente.” e a tarefa "Usar o cartão." estão ligadas com um

relacionamento meios-fim. O Proprietário do Terminal tem a tarefa “Processar

transação” a qual está subdividida em duas sub-tarefas "Ler / escrever no cartão" e

"Ler / escrever na Base de Dados" relacionada com a tarefa “Processar transação”

através do relacionamento de decomposição de tarefa. A tarefa "Ler / escrever

sobre cartão" está associada com o titular do cartão que a sua vez está relacionada

com a meta flexível externa “Ler / escrever no cartão corretamente”. A tarefa

externa “Ler / escrever na base de dados central” assim como também a meta

flexível “Enviar dados corretamente” estão em uma dependência indo do

proprietário de dados para proprietário do terminal. Contudo, uma visão mais

detalhada apresenta-nos que tanto “Ler / escrever na base de dados central” e

“Enviar dados corretamente” depende da tarefa interna de proprietário de

terminal “Ler escrever sobre a base de dados”. As dependências entre elementos

internos e externos do diagrama SR possibilitam a realização de uma modelagem

mais detalhada.

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 92: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 5 – Trabalhos Relacionados

92

Figura 43 – Diagrama SR para o Web Service baseado em cartões de pagamento

[51].

Na Figura 44 se representa um ataque ao sistema. Para realizar um ataque,

um invasor deve explorar as vulnerabilidades; estes aproveitamentos de

vulnerabilidades são representados por sub-tarefas da tarefa associada ao ataque, e

que estão ligadas através da relação de decomposição de tarefas. Notamos que os

elementos da tarefa correspondente à exploração de vulnerabilidades possuem

uma letra "V" no lado direito do elemento, como mostrado na Figura 44.

Figura 44 – Representação de ataques para o Web Service baseado em cartões de

pagamento [51].

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 93: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 5 – Trabalhos Relacionados

93

Analisando esta situação, se um ator depende de outro ator que é um

atacante, o atacante pode valer-se de uma dependência vulnerável. Na Figura 42

as tarefas marcadas com V levam a que a dependência de proprietário de terminal

com titular do cartão seja “quebrada” (break) e faze a vulnerabilidade existente.

5.2. Transparência de Software

Um fenômeno está ganhando momento em nossa sociedade: a

Transparência e seu impacto direto, o direito a ser informado, está ocupando

parte dos esforços da sociedade moderna para seu estudo e aplicação. Este fato

reflete um requisito geral para sociedades democráticas, cada vez mais

demandantes na solicitude de seus direitos.

E por que de sua importância? Destacados estudiosos do tema [9], [55],

[56], [57], [58] concordam que a tendência a nível mundial fará com que a

transparência seja destaque nos âmbitos sociais, governamentais e públicos,

portanto, sendo o software um elemento que permeia vários destes aspectos os

engenheiros de software terão que estar preparados para esta demanda. Segundo

[8] se vislumbra que engenheiros terão que possuir métodos, técnicas e

ferramentas para ajudar a fazer software transparente.

Focando o nosso trabalho neste contexto e ententendo que o aumento da

demanda por transparência é um fato, pretendemos fazer deste trabalho com o

SimulES-W um caso de estudo de como aplicar os conceitos de transparência.

O mundo está cada vez mais dependente de software. No entanto, o

conhecimento embutido no software é pouco ou nada transparente. Acreditamos

que uma abordagem intencional da Engenharia de Requisitos apresentada neste

trabalho é a melhor maneira para elicitar, modelar e analisar (verificar e validar)

requisitos, pois permite o conhecimento sobre o “porquê” de cada requisito.

A seguir analisaremos trabalhos com uma abordagem na transparência de

software, pois concordamos com a frase enviada pelo professor John Mylopoulos

“Transparency is an interesting quality because it makes it necessary to attach

requirements models to software” [70].

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 94: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 5 – Trabalhos Relacionados

94

5.2.1.“Uma Análise Inicial sobre como Transparência Software e Confiança se Influenciam Mutuamente” [52].

Neste trabalho seus autores começam explicando como foi feita uma

pesquisa na internet na procura por uma definição de transparência, eles acharam

que muitas definições de diferentes óticas foram propostas, mas todas coincidiam

na seguinte noção, que transparência é aquilo que é o suficientemente aberto para

permitir que as coisas sejam profundamente observadas a partir de diferentes

perspectivas [52].

5.2.1.1.Confiança como uma Característica da Transparência

É um fato que o software já é o suficientemente pervasivo, onde a internet

está conectando indivíduos globalmente e os autores deste trabalho concordam

com outros trabalhos antes mencionados [9], [55], [56], [57], [58] onde a

transparência parece não ser apenas uma possibilidade remota, mas algo que

teremos de entregar mais cedo do que muitos pensaram.

O que este trabalho apresenta é o conceito de confiança como uma das

características importante da transparência, embora esta confiança

às vezes pode ser enganosa.

Para um cliente a confiança pode ser um componente importante para

assegurar a transparência. Segundo [52] a transparência é indispensável, pois

permite que se possa melhorar o relacionamento com os clientes já que fornece

retroalimentação que visa na melhora do produto. No entanto, o nível de

transparência tem que ser gerida para assegurar a confiança.

Este trabalho não faz um detalhamento exaustivo sobre estes dois tópicos,

embora ele busque incentivar a procura de uma compreensão mais profunda sobre

a forma como a confiança e a transparências podem ser utilizadas em benefício da

sociedade.

5.2.2.Transparência e Pureza do Software [54].

Este artigo faz uma introdução sobre software que contém funcionalidades

as quais não são anunciadas ou conhecidas pelos usuários e que transtornam ou

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 95: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 5 – Trabalhos Relacionados

95

distorcem a usabilidade do produto. Embora estas funcionalidades não sejam

erros, mas sim operações destinadas pelos desenvolvedores para serem

desconhecidas aos usuários finais. O autor exemplifica com o caso dos cavalos de

Tróia (Trojan horses) e os ovos de Páscoa (Easter eggs) que a cada vez são mais

comuns e tem se convertido em uma fonte de muitos riscos.

5.2.2.1. Enfoque da Transparência

Meunier define a transparência de software como uma condição para que

todas as funções do software sejam divulgadas para os usuários. Além disso, a

transparência é necessária para a gestão adequada dos riscos. O termo

"transparência" segundo ele deve ser usado em vez de "Plenamente divulgado" ou

(fully disclosed) para evitar confusão com “a plena divulgação” de

vulnerabilidades.

5.2.2.2.Software Puro

Essa liberdade de ser “plenamente divulgado” deve ser nomeada de alguma

forma, e o autor propõe o conceito de “Pureza”. Embora software puro

teoricamente possa existir sem divulgação, mas a divulgação seria um forte

incentivo. Pureza não significa livre de erros ou inalterada desde a sua liberação.

É possível que o software puro possua erros ou esteja corrompido. O autor cita um

caso relacionado a um serviço de vídeo americano que coletou informações de

quem viu uma cena de televisão várias vezes. Essa informação, de que haveria

coleta de informações do padrão do uso, foi pouco clara e os usuários ficaram

pouco informados sobre essa característica do sistema.

Esse caso ajuda a entender porque a pureza do software é uma propriedade

desejável que visa a proteger o usuário de funcionalidades indesejadas do

software, tendo este a capacidade de remover estas. É assim que transparência de

software e pureza são freqüentemente avaliados, mas não explicitamente

identificados. E de fato um software opaco pode ter riscos de segurança para as

informações dos usuários além de riscos de negocio a sob a forma de perda da

reputação, confiança, vendas e contratos. E é neste contexto que o autor enfatiza

que a transparência só não é suficiente, em alguns casos se deve exigir pureza do

software como um requisito explicito necessário para diminuir os riscos.

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 96: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 5 – Trabalhos Relacionados

96

5.2.3.Explorando as Características de i* que Apóiem a Transparência do Software [53].

Neste trabalho se apresenta que transparência do software deve ser

fundamentada em requisitos, e que esta será a base tanto para rastreabilidade

ascendente quando para rastreabilidade descendente. Conforme este contexto, os

modelos i* são importantes porque deixam claros os requisitos não-funcionais que

impactam a transparência de software.

5.2.3.1.Definindo Transparência de Software

Conforme [53] o software é considerado transparente, se torna as

informações das quais ele trata também de forma transparente (transparência da

informação) e se ele mesmo é transparente, ou seja, ele mesmo informa sobre

como ele funciona, o que ele faz e as justificativas do “por que” (a transparência

do processo). Os autores abordam a problemática na transparência de software

propondo a idéia de requisitos que sejam legíveis para ambas partes tanto para

os interessados em geral quanto para os desenvolvedores.

A Figura 45 apresenta a proposta da escada da transparência, onde cada um

dos níveis nos ilustra que atributos de qualidade devem ser atingidos até à

transparência.

Figura 45 – Escada da Transparência tomada de [53].

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 97: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 5 – Trabalhos Relacionados

97

5.2.3.2. Como os Modelos i* Apóiam a Transparência

Nos modelos i* é possível representar a intencionalidade dos atores,

explicitar metas flexíveis, alternativas e intencionalidade detalhada. Ao descrever

a intencionalidade dos atores estamos atingindo os requisitos não funcionais de

rastreabilidade e de verificabilidade que conforme [53] contribuem para a

auditabilidade (auditability). Do mesmo modo com explicitar metas flexíveis nós

estamos atingindo os requisitos não funcionais de completeza, clareza e acurácia

os quais contribuem para o requisito de ser informativo (informativeness). Com a

abordagem da intencionalidade detalhada se está atingindo os NFRs de

decomposição e composição atributos que contribuem para o entendimento

(understandability) e finalmente a descrição de alternativas são importantes para

integridade, extensibilidade e validade, os quais estão contribuindo em diferentes

níveis da escada da transparência (ver Figura 44).

5.3. Análise dos Trabalhos Relacionados

A seguir apresentamos um resumo das principais características dos

trabalhos citados neste capítulo: eles são frutos de um esforço relativamente recente

e que aportaram, desde seus diferentes focos, elementos para a elaboração desta

dissertação.

Na proposta “Estendendo Tropos para uma Implementação em Prolog: um

Estudo de Caso Usando o Problema do Agente Coletor de Alimentos (FCAP)”

[49] se faz uso da metodologia Tropos, metodologia está baseada nos requisitos e

em no framework i* para criar os modelos intencionais, tendo similitude com o

nosso caso já que a idéia é focar-nos nos requisitos e evoluir os modelos

intencionais. Além disso, o trabalho explica que foram usados diagramas de

seqüência de cenários para a implementação e no caso do SimulES pretendemos

usar o diagrama SDsituations; também para a implementação fizeram uso dos

predicados para instanciação de agentes, papéis e posições e nosso caso variou,

guiar-nos através do modelo SA para SimulES (Figura 28), além do léxico para a

descrição do contexto. Finalmente, os autores fazem uso de cenários como uma

boa prática que permite justificar os elementos que estariam presentes tanto na

modelagem como na implementação, esta parte é bastante importante, pois o

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 98: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 5 – Trabalhos Relacionados

98

nosso trabalho também está fortemente baseado em cenários e a nossa idéia é que

cenários servirão de mecanismo para mapear modelos até o código.

O trabalho “Tropos: uma Metodologia de Desenvolvimento de Software

Orientada a Agentes” [50] também faz uso de Tropos como metodologia de

modelagem. Na primeira atividade descrita os atores são identificados e

representados no diagrama de atores do contexto eCulture (Figura 37) nesta

dissertação temos o modelo SA para SimulES (Figura 29) junto com o léxico para

esta atividade. Embora este trabalho seja um desenvolvimento para agentes possui

itens de interesse para nosso trabalho. Bem que usem o método Tropos

identificamos que a modelagem está centrada nos atores. A evolução dos modelos

surge com a análise e refinamento dos atores, nesta análise dependências são

descobertas e metas são geradas, é assim que isso acontece nas diferentes etapas

do Tropos onde novos atores também podem ser descobertos. As dependências

identificadas são, segundo os autores aquelas que definirão os requisitos

funcionais e não funcionais. Neste trabalho o mapeamento dos modelos até a

implementação foi feito usando os diagramas AUML [69] e a ferramenta de

desenvolvimento JACK [71], onde planos e metas são programadas para os

agentes do sistema.

Continuando com os trabalhos relacionados com a modelagem intencional,

a proposta do trabalho “Uma Abordagem para Modelagem Intencional de

Avaliação de Riscos de Segurança em Web Services” [51] na medida em que se

explica como foi feita a modelagem sugere a potencialidade do uso desta, pois

acredita que através dela é fácil obter necessidades reais além de fornecer uma

análise qualitativa da viabilidade do projeto sob vários cenários. Neste ponto nos

acreditamos que uma análise baseada em transparência de software pode avaliar

aspectos importantes da implementação que tenha como foco os diferentes

usuários. Outro aspecto importante neste trabalho é a modelagem dos ataques ao

sistema, isso pode ser levado em consideração em nosso trabalho para representar

exceções do sistema (jogo SimulES) ou comportamentos indesejados.

Passando a outro âmbito de nosso trabalho nesta dissertação temos os

tópicos relacionados com transparência de software. No primeiro trabalho temos

“Uma Análise Inicial sobre como Transparência Software e Confiança se

Influenciam mutuamente” [52]. Neste trabalho encontramos novamente a

premissa sobre a importância da transparência de software como um requisito que

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 99: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 5 – Trabalhos Relacionados

99

temos que disponibilizar aos diferentes usuários do software. Aqui é apresentado

um conceito novo “Confiança” como um requisito para assegurar a transparência.

Se levamos este conceito ao SimulES podemos pensar nele como um atributo não

funcional que pode garantir o funcionamento com sucesso do jogo no seu

ambiente e durante o tempo que seja determinado. Ao ser um atributo não

funcional pode ser qualitativamente definido e analisado além de ser relacionado

com outros atributos como custo e desempenho.

A proposta “Transparência e Pureza do Software” [53] analisa as

funcionalidades e comportamentos que os usuários esperam que os produtos de

software tenham, não obstante, se estes produtos possuem funcionalidades

indesejadas criará nos usuários a sensação de incerteza sobre o uso deste. O texto

dá ênfase no fato de que as funções do software têm que ser divulgadas para os

usuários. Neste contexto acreditamos que a propriedade de “pureza de software”

deve aportar ao nosso trabalho em aspetos de divulgação sobre o que o software

realmente faz visando a proteção do usuário.

Finalmente no trabalho “Explorando as Características de i* que Apóiem a

Transparência de Software” [54] são apresentados modelos i* visando representar

os requisitos não funcionais que impactam a transparência de software. Este

aporte é diretamente ligado a nossa proposta a qual combina modelos intencionais

com transparência de software. Além disso, este trabalho enfatiza que os

requisitos têm que ser legíveis para que as partes interessadas (interessados em

geral e desenvolvedores). Concordamos com essa proposta, já que software deve

informar sobre aquilo que faz a seus usuários e desenvolvedores. Se o SimulES é

concebido como um produto de software com perspectiva de evolução deve ser o

suficientemente transparente. Finalmente o uso de modelos intencionais atingem

requisitos não funcionais como auditabilidade, completeza, clareza, acurácia,

entendimento, integridade, extensibilidade e validade atributos próprios da

transparência que pretendemos explorar neste trabalho.

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 100: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

6 Construindo o SimulES-W

6.1.Background

Neste capítulo detalharemos o método de desenvolvimento proposto para o

SimulES-W uma implementação em plataforma Web do jogo antes só disponível

na versão do tabuleiro. Como temos apresentado ao longo desta dissertação varias

etapas tem acontecido até chegar neste ponto. Nas primeiras etapas para alcançar

o entendimento do contexto do SimulES foram analisadas as diferentes fontes de

informação, algumas já mencionadas nesta dissertação, a monografia [4] e o

trabalho de dissertação [44], além das diferentes versões de léxicos e cenários

disponíveis em [22] produto das evoluções do jogo.

Lembremos que para obter um entendimento razoável da dinâmica do jogo,

foram analisados os elementos físicos criados e apresentados no trabalho [4], além

disso, foram planejadas reuniões no grupo de Engenharia de Requisitos da PUC-

Rio para revisar o conteúdo das cartas conceito e problema. Depois, varias sessões

para jogar SimulES foram programadas para receber treinamento pratico do jogo e

fortalecer os conceitos de rodadas e jogadas possíveis no jogo.

Visando uma evolução do SimulES incluindo a implementação do mesmo,

partimos na procura de literatura sobre jogos educacionais na engenharia de

software (Capítulo 2), com o foco de entender o objetivo de cada um e identificar

os métodos usados para suas modelagens e posteriores implementações.

Identificamos nesta parte do trabalho que as descrições sobre as modelagens eram

vagas ou inexistentes. Identificamos que a iteração entre usuários não era levada

em consideração na literatura pesquisada, mas identificamos que a modelagem

intencional usada para modelagem de processos organizacionais levava em

consideração iteração entre usuários. Porem, nós propusemos trabalhar no

entendimento da modelagem intencional, além disso, vimos que nenhum dos

jogos pesquisados usava a modelagem intencional como insumo para

implementação dos jogos.

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 101: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 6 – Construindo o SimulES-W 101

Acreditávamos na potencialidade da modelagem intencional para

representação do jogo e como insumo útil para afrontar uma implementação, é

assim, que para facilitar a criação dos modelos iniciais foi usado o método ERi*c,

modelos que foram apresentados e validados segundo a proposta de validação de

modelos i* proposta em [44]. Estes modelos foram indispensáveis na

implementação de SimulES-W.

Como precisávamos saber se a modelagem que estávamos usando era

adequada e suficiente para abordar uma implementação, buscamos literatura sobre

experiências de modelagem intencional que derivaram na criação de algum

protótipo. Encontramos algumas propostas, as quais são descritas no Capítulo 5 e

que aportaram idéias importantes para esta dissertação. Além disso, procuramos

literatura relacionada com a transparência de software que nos auxiliará na

procura de conceitos sobre como combinar a nossa modelagem com atributos de

transparência de software e que estes elementos fossem refletidos nossa

implementação.

O protótipo começou a ser desenvolvido e suas primeiras funcionalidades

foram apresentadas como Projeto Final de Programação, na medida em que o

protótipo foi desenvolvido, os modelos foram sendo refinados. Tivemos a

oportunidade de validar e incorporar novo conhecimento a nosso trabalho a partir

de uma experiência real com o jogo de mesa e estudantes na UERJ, estudantes que

pertencia à área de geomática. Destes estudantes alguns não tinham conhecimento

sobre um processo de desenvolvimento de software embora trabalhassem em

áreas afins à informática (Capítulo 3). Precisávamos de um grupo desta natureza

que fosse imparcial. Pois, as sessões ou reuniões anteriores para jogar o SimulES

foram realizadas com grupos da área da comparação.

O resultado destas atividades derivaram em uma nova versão do SimulES

que incorpora uma versão digital chamada SimulES-W a qual será detalhada a

seguir.

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 102: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 6 – Construindo o SimulES-W 102

6.2.Arquitetura do SimulES-W

SimulES-W como uma aplicação Web:

O protótipo de SimulES é uma aplicação Web que utiliza software livre. O

foco deste tipo de aplicações é proporcionar valor real e oferecer uma experiência

positiva para o usuário ou jogador.

As vantagens das aplicações Web é que estas não exigem compra física, não

precisam downloads, instalações e configurações, funcionam diretamente em

qualquer computador sendo mais confiáveis que outras aplicações disponíveis

para download. Além disso, as páginas Web são usadas como as interfaces de

usuário. Estas vantagens foram as motivações pelas quais foi escolhida este tipo

de plataforma para nossa implementação.

O SimulES-W tem um desenho amigável, simples e fácil de usar,

cumprindo com as características de uma boa aplicação Web. Além disso, procura

implementar requisitos não funcionais de transparência. Estes atributos serão

analisados desde a perspectiva Transparência de Software mais adiante neste

documento.

Ferramentas usadas:

Como linguagem de programação foi escolhida a linguagem Java [60]. A

primeira vantagem do Java é a independência de plataforma e facilidade de acesso

para os usuários por ser de fonte aberta. Java é orientada a objetos e foi projetada

para servir como uma nova forma de gerir a complexidade de software.

Além disso, precisávamos de uma base de dados para gerenciar as

informações utilizadas numa sessão do jogo. Nossa escolha foi por MySQL,

conforme [61] MySQL tornou-se a base de dados de código aberto mais popular

do mundo principalmente em desenvolvimentos Web.

Padrões e Estilos:

O padrão de desenho escolhido foi o MVC (Model-View-Controller) Este

padrão é usado para separar a lógica de negocio, a interface e o controle. É

baseado nas boa práticas sugeridas pela Sun MicroSystems [60] para o uso do

framework Hibernate [64]. No trabalho de Almentero [59] também se faz uso

deste padrão em conjunto com programação modular. Nosso caso é diferente, pois

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 103: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 6 – Construindo o SimulES-W 103

a arquitetura é baseada em orientação a objetos, do trabalho de Almentero nós

adotamos a descrição baseada em cenários proposta para a descrição de código.

Na Figura 46 se representa a arquitetura, que desacopla a vista do modelo,

com a finalidade de melhorar a re-usabilidade. É desta forma que as modificações

nas vistas impactam em menor medida a lógica de negocio ou de dados. Os

elementos do padrão são: o Modelo que contem dados e regras de negocio, a

Vista que apresenta a informação do modelo para o usuário e o Controlador que

gerencia as entradas do usuário.

Petição

Atu

aliz

ação

Figura 46 – Arquitetura projetada para o SimulES-W.

A idéia de usar este padrão na implementação do protótipo de SimulES é

que o modelo possa ter diversas vistas, cada um com seu correspondente

controlador. As responsabilidades identificadas são:

- Modelo: será o encarregado de acessar à camada de persistência e

implantar as regras de negocio (funcionalidade do sistema), levar um registro das

vistas e controles do sistema.

- Controlador: será o encarregado de receber os eventos de entrada, além de

conter as regras de gestão dos eventos.

- Vistas: encarregadas de receber os dados do modelo e mostrar-los aos

usuários.

6.3.Método Usado na Construção do SimulES -W

6.3.1. Primeira Etapa

Para a modelagem do SimulES-W foram analisados em conjunto: Léxicos,

Cenários, Diagrama SDsituations, Modelo SA e os Diagramas SD e Diagramas

SR. Com estes elementos construímos o primeiro diagrama de classes do Jogo.

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 104: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 6 – Construindo o SimulES-W 104

class Conceptual Model

SoftwareEngineerProject

Status

Player Card

CardType

Game

Module

Figura 47 – Primeira versão do modelo de classes para SimulES-W.

Na Figura 47 representamos as primeiras classes que foram identificadas

para o jogo, para isso utilizamos a seguinte heurística, todos os símbolos do LAL

foram analisados prestando especial atenção aqueles símbolos tipo objeto, aqueles

que reuniram as propriedades básicas de uma classe tais como:

- As classes são descritas por substantivos: então analisamos os símbolos

nomeados por substantivos.

- Atributos são propriedades nas classes: alguns símbolos possuíam

descrições que nos indicavam as suas propriedades. Como na Figura 47 vemos

que o símbolo Projeto tem características de complexidade, tamanho, qualidade e

orçamento candidatos a serem propriedades da classe.

- Classes são susceptíveis de ter operações: que na sua vez são serviços

prestados pela classe quando um objeto é solicitado para modificar seu

comportamento. Identificamos que os impactos dos símbolos nos auxiliariam

nesta tarefa.

- Além disso, identificamos que símbolos tipo verbo podiam representar

operações das classes. Mais adiante utilizaremos esta heurística para identificar

comportamentos das classes.

Figura 48 – Símbolo SimulES analisado para sua conversão a classe do sistema.

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 105: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 6 – Construindo o SimulES-W 105

Se bem o léxico foi nossa primeira fonte de informação para identificar

candidatos a classe, foi a análise destes símbolos nos diagramas SR e SD o que

nos afiançou na nossa premissa, pois estes símbolos representados na modelagem

intencional como recursos cumpriam as características de uma classe.

6.3.2.Segunda Etapa

Tendo a primeira versão do modelo do SimulES (Figura 47) e visando o

SimulES como uma aplicação Web passamos a analisar as SDsituations (Figura

27) do jogo, estas SDSituations descritas tanto nos diagramas SD e SR do trabalho

[44] possuíam uma descrição em cenários. Em nossa análise identificamos que

cada uma delas podia ser representada em uma tela do sistema (página Web),

então criamos a primeira versão do modelo conceitual da aplicação Web (Figura

49). A página principal ou Main foi identificada como um ponto de entrada para

todos os jogadores e a página gestão do jogo seria uma página para gerir

elementos de controle que somente um administrador podia manipular. Já as

páginas Rodada de inicio, Rodada de Ações e Rodada de conceitos que

pertenciam às SDsituations seriam denominadas como as páginas núcleo do jogo.

Como vemos na Figura 49, os episódios descrevem comportamentos que

são sensíveis a implementação, além disso, cada SDsituations está totalmente

desacoplada, o que faz razoável a análise de implementar separadamente cada

uma delas.

Figura 49 – SDSituations candidata a página no SimulES-W.

SDSituations candidata a página no SimulES

Com estas heurísticas, o modelo inicial da Figura 46 e o modelo de

navegabilidade da aplicação, Figura 50, foram insumos para a criação do primeiro

protótipo.

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 106: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 6 – Construindo o SimulES-W 106

ui Conceptual Web Model

Main

Rodada de Inicio Rodada de Ações Rodada de Conceitos

Gestão do Jogo

«Navega»

«Navega» «Navega» «Navega»

Figura 50 – Modelo de navegabilidade da aplicação Web para o SimulES-W.

6.4. Incorporando Elementos em cada uma das Camadas

Com a implementação das classes identificadas dos recursos e atores na

modelagem intencional, que no C&L aparecem como símbolo tipo objeto e

sujeito, nós começamos a análise detalhada para a implementação dos

comportamentos tanto nas páginas como nas classes. Para isso analisávamos

novamente os diagramas SD e SR procurando os comportamentos

(intencionalidades) e os objetivos que procuravam cada um dos atores. As

informações destes elementos estariam presentes na modelagem como metas e

tarefas e seu detalhamento estaria presente no Léxico, o que significa,

identificamos que metas e tarefas as quais estão representadas no C&L como

símbolos tipo verbo e estado tinham que ser incorporadas no sistema para dar a

este o comportamento esperado e ficariam na camada de controle. As

SDsituations identificadas foram incorporadas na camada de visão porque

possuíam características que nos permitiram implementar-las nesta camada, pois,

constituíam cenários bem delimitados com um objetivo identificado, e o

cumprimento dos objetivos em cada SDsituation era independente das outras.

Além disso, possuíam uma correlação em tempo de execução, ou seja,

identificamos quais tinham que ser executadas antes e depois. E na medida em

que íamos implementando refinamos os modelos i* e também os léxicos e

cenários.

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 107: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 6 – Construindo o SimulES-W 107

6.4.1.Identificar as SDsituations Principais

As SDsituations nomeadas como principais foram aquelas que faziam parte

do núcleo do jogo ou seja as que estão representadas na Figura 51, as

SDSituations ressaltadas em amarelo foram aquelas refinadas e implementadas

nas primeiras etapas.

Construção

artefatos

Figura 51 – Diagrama SDsituations refinado para o SimulES-W.

Figura 52 – Modelo SA SimulES-W refinado.

Uma nova posição para jogador foi descoberta Administrador, ele é

instanciado naqueles casos onde é preciso fazer atividades de gestão dentro do

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 108: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 6 – Construindo o SimulES-W 108

jogo. Porém, seu papel neste caso particular será de Coordenador de Recursos e o

SimulES atuara como Orquestrador dos mesmos dentro do sistema, na Figura 51

podemos ver estas mudanças dentro do Modelo SA.

A seguir vamos ver o refinamento dos modelos segundo a implementação,

alguns dos modelos intencionais apresentados a seguir foram tomados de [44] e

refinados conforme a implementação, outros foram criados porque pertencem a

SDsituations auxiliares.

SDsituation: Joga Rodada de Início

Nesta SDsituation podemos ver que um novo ator entrou na cena do jogo, o

Administrador, que é um jogador que se encarregará de gerir elementos dentro do

jogo e solicitar recursos e atividades de controle para o SimulES, Figura 53,

vemos que o Administrador é o encarregado de fechar a entrada de jogadores, mas

é SimulES como o orquestrador o encarregado de executar a atividade dentro do

sistema como vemos na Figura 54. Outra questão importante a ressaltar é a meta

jogador seja registrado. Para controlar jogadores em uma partida o SimulES deve

saber que jogadores estão registrados, além disso as atividades e movimentos on-

line efetuados pelos jogadores serão publicados para que todos os jogadores

fiquem informados sobre detalhes da partida.

Figura 53 – Modelo SD – Joga Rodada de Início.

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 109: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 6 – Construindo o SimulES-W 109

Figura 54 – Modelo SR – Joga Rodada de Início.

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 110: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 6 – Construindo o SimulES-W 110

SDsituation: Joga Rodada de Ações

Nesta SDsituations temos que o jogador e o SimulES são os atores

principais da situação, o engenheiro de software entrará na cena se ações do

tabuleiro são escolhidas (Figura 55). O jogador administrador não participa nesta

situação, contudo SimulES executará tarefas de controle ao calcular o lançamento

do dado e ceder as cartas ao jogador, além de publicar os movimentos e as

informações do jogo.

Figura 55 – Modelo SD – Joga Rodada de Ações.

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 111: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 6 – Construindo o SimulES-W 111

Figura 56 – Modelo SR – Joga Rodada de Ações.

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 112: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 6 – Construindo o SimulES-W 112

SDsituation: Construção de Artefato

Desta SDsituations podemos resaltar que o jogador, junto com seu

engenheiro ou engenheiros, construi os artefatos como vemos na Figura 57 e

depois ele os submete. O SimulES se encarregara de guardar a configuração do

tabuleiro individual e publica-la depois para ser visto por outros jogadores. Além

disso, o SimulES se encarregará de gestionar as mensagens onde apresentará o

resumo dos movimentos feitos pelos jogadores (Figura 58).

Figura 57 – Modelo SD – Construção de Artefato.

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 113: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 6 – Construindo o SimulES-W 113

Figura 58 – Modelo SD – Construção de Artefato.

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 114: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 6 – Construindo o SimulES-W 114

SDsituation: Inspeção de Artefato

Na inspeção de artefato interagem o SimulES, o jogador e o Engenheiro ou

Engenheiros de Software. SimulES faz a gestão e fornece os recursos para a

inspeção (Figura 59), a inspeção é feita baseada na relação entre o jogador e

engenheiro. Já quando a inspeção é finalizada o jogador deve submeter para que o

SimulES guarde a configuração (Figura 60) e outros jogadores possam conhecer o

resultado da inspeção. Embora algumas metas flexíveis começam a ser

identificadas nesta etapa, elas serão tratadas e ou refinadas em etapas posteriores

da modelagem com o foco de requisitos não funcionais.

Figura 59 – Modelo SD – Inspeção de Artefato.

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 115: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 6 – Construindo o SimulES-W 115

Figura 60 – Modelo SD – Inspeção de Artefato.

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 116: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 6 – Construindo o SimulES-W 116

SDsituation: Correção de Artefatos

O SimulES deve fornecer o tabuleiro individual com a construção dos

artefatos no tabuleiro individual feito previamente pelo jogador. A condição para

realizar a correção é que o jogador tenha cartas brancas ou cartas cinzas com

defeito e estará condicionado à habilidade dos engenheiros contratados.

Figura 61 – Modelo SD – Correção de Artefato.

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 117: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 6 – Construindo o SimulES-W 117

Figura 62 – Modelo SD – Correção de Artefato.

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 118: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 6 – Construindo o SimulES-W 118

SDsituation: Joga Rodada de Conceitos

Nesta rodada do jogo os jogadores aplicam seus conceitos e jogam

problemas a seus adversários como estratégia para ganhar o jogo e danificar o

jogo dos outros. Caso não sejam permanentes, o jogador pode livrar-se

eventualmente de problemas impostos. Ele pode avaliar a conveniência da

participação de seus engenheiros dentro do jogo além de descartar aquelas cartas

que não sejam úteis para seu jogo.

Figura 63 – Modelo SD – Joga Rodada de Conceitos.

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 119: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 6 – Construindo o SimulES-W 119

Figura 64 – Modelo SR – Joga Rodada de Conceitos.

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 120: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 6 – Construindo o SimulES-W 120

SDsituation: Tratamento de Problema

Esta SDsituations retrata um novo ator, o SimulES encarregado de

disponibilizar os recursos (Figura 65) e informar para todos os jogadores quando

os problemas são tratados. Além disso, vemos na Figura 66 que o jogador em seu

papel de adversário deve aceitar o tratamento que o jogador da vez dá aos

problemas, isso para que o fluxo do jogo continue.

Figura 65 – Modelo SD – Tratamento de Problema.

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 121: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 6 – Construindo o SimulES-W 121

Figura 66 – Modelo SR – Tratamento de Problema.

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 122: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 6 – Construindo o SimulES-W 122

SDsituation Submissão de Produto

Esta é a ultima SDsituations tratada dentro do núcleo do jogo, porém nela é

possível tomar a decisão de finalizar o jogo (Figura 67). Se no momento de

solicitar a submissão do produto o jogador da vez não fizer nenhuma tarefa de

inspeção o SimulES, ou outro jogador no papel de adversário, pode realizar a

tarefa de inspeção. Além disso, como vemos na Figura 68 um jogador no papel de

administrador será quem define se o jogo finaliza e assim o sistema fechara todos

os recursos e informara que a partida terminou e, como conseqüência, o jogador

que submeteu o produto ganhará a partida.

Figura 67 – Modelo SD – Submissão de Produto.

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 123: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 6 – Construindo o SimulES-W 123

Figura 68 – Modelo SR – Submissão de Produto.

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 124: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 6 – Construindo o SimulES-W 124

SDsituation: Integração de Artefatos em Módulo

Se bem que esta atividade pertence ao tempo 2 na ordem de execução das

SDsituations (Figura 51) ela é uma atividade que está sendo realizada pelo

SimulES como vemos na Figura 69, isso porque no momento de submeter o

produto o SimulES realiza uma verificação de que todos os módulos estejam

construídos e separa internamente os artefatos de cada um. Ele envia uma

mensagem do resultado desta integração (Figura 70) para que o produto

efetivamente possa ser submetido.

Figura 69 – Modelo SD – Integração de Artefato em Módulo.

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 125: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 6 – Construindo o SimulES-W 125

Figura 70 – Modelo SR – Integração de Artefato em Módulo.

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 126: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 6 – Construindo o SimulES-W 126

6.4.2. SDsituations Auxiliares

Outras SDsituations que não pertencem ao núcleo do jogo mas ajudam na

execução do mesmo e que tiveram sua origem na análise dos símbolos tipo objeto

e que demandam comportamento dentro do SimulES-W, são apresentadas a

seguir.

SDsituation: Apresentar Dinâmica do Jogo

Esta SDsituations surgiu como resposta a análise do comportamento do

tabuleiro principal. Na primeira modelagem do SimulES [4] o tabuleiro individual

é apresentado como um símbolo tipo objeto, já em [44] nos modelos intencionais

preliminares aparece como um recurso. Em nossa análise encontramos que o

tabuleiro individual tinha que ter comportamentos e funcionalidades próprias. E

um ponto centralizador de informações relevantes do jogo além de ser o

encarregado da troca de mensagens entre os jogadores pois jogadores não estariam

no mesmo espaço físico.

Assim o tabuleiro central que era descrito no léxico em [44] como “Área

central da mesa definida por um papel impresso”, na versão do léxico para

SimulES-W temos uma nova definição “Página principal do jogo onde são

disponibilizadas as informações de cartão do projeto escolhido, mensagens dos

jogadores, informação dos movimentos do jogo, jogadores on-line.”. Como

também está associado à SDSituation Apresentar Dinâmica do Jogo, onde jogador

e SimulES são os atores desta interação (Figura 71). SimulES fornece os recursos

e as informações do jogo, as quais serão administradas conforme às mensagens

trocadas pelos jogadores e suas jogadas nas diferentes rodadas do jogo (Figura

72).

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 127: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 6 – Construindo o SimulES-W 127

Figura 71 – Modelo SD – Apresentar Dinâmica do Jogo.

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 128: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 6 – Construindo o SimulES-W 128

Figura 72 – Modelo SR – Apresentar Dinâmica do Jogo.

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 129: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 6 – Construindo o SimulES-W 129

SDsituation: Gestão de Material de Apoio

O material de apoio permitirá tipificar o material que será usado durante o

jogo, ou seja, se o interesse do instrutor é que temas específicos da área da

engenharia de software sejam tratados no jogo ele pode criar o material de apoio

e escolher este no inicio do jogo, para que as cartas a serem apresentadas sejam

especializadas e relacionadas com o tópico escolhido. Como apresentamos nas

Figuras 73 e 74 os atores relacionados nesta SDsituation são SimulES e Jogador

no seu papel de administrador.

Figura 73 – Modelo SD – Gestão de Material de Apoio.

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 130: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 6 – Construindo o SimulES-W 130

Figura 74 – Modelo SR – Gestão de Material de Apoio.

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 131: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 6 – Construindo o SimulES-W 131

SDsituation: Gestão do Jogo

Esta SDsituation auxilia nos relacionamentos de colaboração entre o

SimulES e o Jogador no seu papel de Administrador (Figura 75) onde são

mostradas as atividades que levam tanto a dar inicio à sessão do jogo como ao

fechamento do mesmo. Mas para que essas atividades sejam possíveis é

necessário ter disponíveis todos os recursos a ser inicializados no inicio e no fim

do jogo, além disso, o administrador deve decidir quando fechar a entrada de

jogadores e fazer a solicitação ao SimulES. Outra atividade é escolher que tipo de

material de apoio deve ser usado no decorrer do jogo todo isso é representado na

Figura 76.

Figura 75 – Modelo SD – Gestão do Jogo.

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 132: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 6 – Construindo o SimulES-W 132

Figura 76 – Modelo SR – Gestão do Jogo.

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 133: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 6 – Construindo o SimulES-W 133

6.4.3.Descrição das SDsituations do Sistema Através de Cenários

Com cenários podemos fazer a descrição passo a passo da operação do jogo

e sua interação com os diferentes atores. Estes cenários constituem a descrição dos

aspectos relevantes em quanto ao comportamento e o ambiente do SimulES-W,

isso é feito através dos episódios, a vantagem e que é usada a linguagem natural

semi-estruturada que facilita a leitura e o entendimento.

A evolução do SimulES que inclui modelos intencionais e a criação de um

protótipo baseado nestes modelos, refinou o Léxico e descreveu as SDSituations

(apresentar dinâmica do jogo, construção de artefatos, correção de artefato, gestão

de material de apoio, gestão do jogo, inspeção de artefato, integração de artefatos

no módulo, joga rodada de ações, joga rodada de conceitos, joga rodada de inicio,

submissão de produto e tratamento de problema) em cenários segundo à

implementação. Portanto estaremos primeiro mostrando o léxico do SimulES-W

(Sub-seção 6.4.3.1) seguidos dos cenários do SimulES-W (Sub-seção 6.4.3.2).

6.4.3.1. Léxico do SimulES-W

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 134: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 6 – Construindo o SimulES-W 134

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 135: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 6 – Construindo o SimulES-W 135

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 136: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 6 – Construindo o SimulES-W 136

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 137: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 6 – Construindo o SimulES-W 137

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 138: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 6 – Construindo o SimulES-W 138

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 139: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 6 – Construindo o SimulES-W 139

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 140: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 6 – Construindo o SimulES-W 140

6.4.3.2. Descrevendo as SDsituations através de Cenários

Segundo [11] para descrever SDsituations através da técnica de cenários é

preciso o uso do Diagrama SDsituations e dos Modelos SR procurando-se

maximizar o uso do LAL[10]. Foram utilizadas as SDsituations da Sub-seção

6.4.1. (Identificar as SDsituations Principais) e da Sub-seção 6.4.2. (SDsituations

auxiliares).

Nesta descrição damos ênfase aos elementos, regras e dinâmica do jogo

através da narrativa oferecida pelos cenários. Conforme [59] o uso de cenários

para descrever o sistema torna este mais transparente o que ajuda nosso propósito

neste trabalho.

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 141: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 6 – Construindo o SimulES-W 141

SDsituations principais

Titulo: SDsituations joga rodada de inicio Objetivo: Descrever os preparativos para inicio do jogo. Contexto: Ubicação geográfica: Web Ubicação temporal: Java PlayStartRoundPage Precondição: - cenário executado no inicio do jogo somente - Variáveis do jogo inicializadas - Sessão do jogo estabelecida Pos-condição: - jogadores registrados. - A ordem das jogadas dos jogadores já foi definida dentro do jogo. - Projeto escolhido. - executar cenário joga rodada de ações, construção de artefatos Atores: jogador, SimulES Recursos: dado, cartas engenheiro, informações do projeto. Episódios: 1- Os jogadores se cadastram no jogo 2- SimulES registra os jogares 3- SimulES anuncia os jogadores cadastrados 4- O jogador administrador fecha a entrada de jogadores 5- O jogador lança o dado. Restrição: jogador que tirar o maior número no dado, escolhe o projeto 6- SimulES valida a escolha do projeto 7- SimulES anuncia o projeto escolhido 8- Cada jogador compra uma carta de engenheiro de software 9- SimulES registra o engenheiro de software escolhido Restrição: a ordem na qual os jogadores jogam será acorde com a ordem na qual os jogadores se cadastraram.

Titulo: SDsituations joga rodada de ações Objetivo: Descrever as regras da rodada de ações. Contexto: Ubicação geográfica: Web Ubicação temporal: IndividualBoardPage e PlayConceptsRoundPage Pre-condição: - projeto escolhido - um engenheiro de software por cada jogador Pos-condição: - Jogadas registradas no jogo Atores: jogador Recursos: dado, cartas, informações do projeto, página tabuleiro individual e página principal do jogo. Episódios: 1- jogador usa seus engenheiros de software em CONSTRÓI artefato ou INSPECIONA artefato ou CORRIGE artefato e joga lançamento do dado. 2- jogador lança o dado. 3- Se dado igual a 1,ou 2 ou 3, então jogador pega 1, 2 ou 3 cartas do monte de problemas e conceitos. Restrição: jogador não pode pegar cartas do monte de engenheiros de software. 4- Se dado igual a 4 ou 5 ou 6, então jogador pega 3 cartas do monte de problemas e conceitos e x cartas do monte de engenheiro de software, onde x é o valor do dado menos 3. Restrição: o primeiro episodio é executado de acordo com a habilidade de cada engenheiro de software. Restrição: Habilidades e o custo dessas ações podem ser afetados por cartas de conceitos ou cartas de problemas. Restrição: Se jogador não usou engenheiros de software e nem jogou o dado, então INTEGRA artefatos EM UM módulo.

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 142: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 6 – Construindo o SimulES-W 142

Titulo: SDsituations construção de artefatos Objetivo: Descrever as regras da construção de artefatos. Contexto: Localização geográfica: Web Localização temporal: Java IndividualBoardPage Pre-Condição: Pelo menos um engenheiro no tabuleiro Pos-condição: artefatos construídos no tabuleiro do jogador. Atores: jogador da vez e engenheiro de software Recursos: cartão de projeto na página principal do jogo, engenheiros de software no tabuleiro individual, jogador com cartas brancas e cartas cinzas disponíveis Exceção: jogador penalizado para executar a jogada Metas flexíveis: qualidade[artefato], completeza[artefato] Restrições: A quantidade de artefatos construídos depende da habilidade do engenheiro de software, do tipo de artefato escolhido e da complexidade do projeto. Cartas brancas custam valor da complexidade do projeto. Cartas cinzas custam a metade da complexidade do projeto Episódios: 1- jogador da vez compra cartas brancas ou cartas cinza 2- jogador da vez disponibiliza no tabuleiro individual as cartas brancas ou cartas cinza compradas 3- engenheiro de software constrói produto 4- O jogador submete a jogada realizada 5- SimulES guarda as informações de tabuleiro individual criada pelo jogador 6- Informações do tabuleiro individual podem ser vistas por todos os jogadores

Titulo: SDsituations inspeção de artefato Objetivo: Descrever as regras da inspeção de artefatos. Contexto: Ubicação geográfica: Web Ubicação temporal: Java IndividualBoardPage Pre-condição: - Cenário construção de artefatos já executado - informações do projeto na página central do projeto. - jogador tem cartas brancas e/ou cartas cinzas no tabuleiro. Pos-condição: - artefatos com o resultado da inspeção Atores: jogador, engenheiro de software Recursos: cartas brancas, cartas cinzas, informações do projeto na página principal do jogo, tabuleiro individual. Episódios: 1- jogador escolhe artefato do tabuleiro. 2- Se o engenheiro de software responsável pelo artefato faz a inspeção, então o mesmo gasta um ponto de tempo. 3- Se outro engenheiro de software faz a inspeção, então ele gasta dois pontos de tempo. 4- O resultado da inspeção é fornecido pelo SimulES 5- O usuário submete sua inspeção 6- artefatos inspecionados são visíveis para todos os jogadores

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 143: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 6 – Construindo o SimulES-W 143

Titulo: SDsituations correção de artefato Objetivo: Descrever as regras da correção de artefatos. Contexto: Localização geográfica: Web Localização temporal: Java IndividualBoardPage Pre-condição: - informações do projeto a página principal do jogo. - jogador tem artefatos inspecionados com defeito (INSPECIONA artefato) no tabuleiro individual. Pos-condição: SimulES fornece para todos os jogadores o resultado da inspeção Atores: jogador, engenheiro de software Recursos: Cartas inspecionadas com defeito, informações do projeto Episódios: 1- jogador escolhe artefato com defeito do tabuleiro. 2- jogador descarta carta do tabuleiro individual. 3- SimulES apaga a carta do tabuleiro individual do jogador. 4- Se o engenheiro de software responsável pelo artefato faz a correção, então o mesmo gasta um ponto de tempo. 5- Se outro engenheiro de software faz a correção, então ele gasta três pontos de tempo. 6- artefato inspecionado é substituído por artefato da mesma cor não inspecionada. 7- jogador submete o resultado da correção. 8- SimulES guarda as informações submetidas pelo jogador. 9- SimulES fornece as informações da correção

Titulo: integração de artefatos no módulo Objetivo: Descrever as regras da integração de artefatos. Contexto: Localização geográfica: Web Localização temporal: Java IndividualBoardPage Pre-condição: - informações do projeto na página central do jogo. -jogador tem artefatos no tabuleiro individual. Pos-condição: -jogador pode submeter produto. Atores: SimulES, jogador da vez Recursos: cartas brancas e/ou cartas cinza, informações do projeto na página principal do jogo. Episódios: 1- jogador escolhe submissão de produto 2- SimulES escolhe módulo ou módulos do projeto. 3- SimulES seleciona artefatos do tabuleiro, independente do responsável (engenheiro de software) de acordo com as informações de projeto. 4- SimulES integra o módulo 5- SimulES informa integração no modulo.

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 144: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 6 – Construindo o SimulES-W 144

Titulo: joga rodada de conceitos Objetivo: Descrever as regras da rodada de conceitos. Contexto: Localização geográfica: Web Localização temporal: Java PlayConceptsRoundPage. Pre-Condição: apos de terminada joga rodada de ações. Atores: jogador, adversário Recursos: cartão de projeto na página principal do jogo, engenheiros de software que pertence ao jogador, jogador com cartas conceito e cartas problema pertence ao jogador Episódios: 1- jogador aplica conceitos caso sejam permanentes, colocando-os ao lado do tabuleiro. Restrição: Não pode exceder o orçamento disponível no projeto. 2- Se jogador tem cartas de engenheiro de software, então jogador contrata engenheiro de software de acordo com o orçamento disponível (que consta nas informações do projeto), a contratação será reflexa no tabuleiro individual. 3- jogador descarta cartas, SimulES retorna estas aos montes apropriados. 4- jogador escolhe até 3 concorrentes e pode submeter para cada um uma carta de problema. Restrição: concorrente não pode ter mais de 2 cartas de problemas permanentes e mais de 3 cartas de problemas temporários. 5- problema que submete aos demais concorrentes são visíveis para todos os jogadores. Restrição: Quem escolhe as cartas do concorrente afetadas pelos problemas impostos é o próprio jogador.

Titulo: tratamento de problema Objetivo: Descrever as regras do tratamento de problemas. Contexto: Localização geográfica: Web Localização temporal: Java PlayConceptsRoundPage. Pre-condição: - informações do projeto na página principal do jogo. - Todos os jogadores terminaram joga rodada de conceitos. - jogador recebeu cartas problema. - O tratamento de problema é visível para todos os jogadores Pós-condição: - problemas tratados. Atores: jogador, SimulES, adversário. Recursos: Cartas conceito, cartas problema, tabuleiro individual, engenheiro de software Episódios: 1- jogador estuda como atender a demanda da carta de problema colocada pelo concorrente. 2- jogador atende a demanda da carta de problema, escolhendo as opções que tenha para tratar o problema. Restrição: A carta problema pode ser uma penalidade, ou seja, se o problema é temporário então jogador descarta a carta de problema. Restrição: carta de problema pode ser contraposta por carta de conceito. Restrição: Se o problema é permanente então jogador mantém carta de problema. Restrição: se carta de problema pode ser contraposta por carta de conceito. jogador pode demitir um engenheiro de software, descartando-o. 3- O jogador submete seu tratamento de problema. 4- SimulES atualiza as informações de tratamento de problema. 5- jogadores aceitam o rejeitam o tratamento dado por o jogador ao problema em questão. 6- SimulES informa sobre o conceito dos jogadores sobre o problema tratado

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 145: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 6 – Construindo o SimulES-W 145

Titulo: submissão de produto Objetivo: Descrever as regras da submissão de produto. Contexto: Localização geográfica: Web Localização temporal: Java IndividualBoardPage Pre-condição: - informações do projeto na página principal do jogo. -construção do produto - execução do cenário integração de artefatos no módulo. Pos-condição: - pode se ganhar o jogo - pode se terminar a partida Atores: jogador, SimulES, adversário. Recursos: cartas brancas, cartas cinzas, informações do projeto na página principal do jogo, módulos. Episódios: 1- jogador mostra que produziu todos os módulos, de acordo com as informações de projeto. 2- SimulES verifica todos os artefatos de x módulos, onde x é o nível de qualidade do projeto. Restrição: concorrente não pode selecionar módulo protegido por carta conceito do jogador. 3- SimulES fornece as informações da inspeção aleatória feita. 4- concorrente pode inspecionar aleatoriamente artefatos. Pos-condição: Se artefatos escolhidos (desvirados) forem livres de defeito, então jogador ganha o jogo. Se artefatos escolhidos (desvirados) forem defeituosos, então jogador pode corrigir um por turno de jogo

SDsituations Auxiliares

Titulo: SDsituations apresentar dinâmica do jogo Objetivo: Descrever e disponibilizar as informações gerais do jogo. Contexto: Localização geografica: Web Localização temporal: Java index Precondições: Serviços Web disponíveis Poscondições: Informações gerais do jogo disponíveis Atores: jogador, SimulES Recursos: informações do projeto, informações dos jogadores, informações dos movimentos e mensageira Episódios: 1 – jogador entra no jogo 2 – jogador pode trocar mensagens com os jogadores; 3 – SimulES disponibiliza as informações do projeto escolhido; 4 – SimulES disponibiliza as informações de aceitação de movimentos; 5 – SimulES disponibiliza as mensagens trocadas entre os jogadores; 6 – SimulES disponibiliza as informações dos movimentos do jogo; Restrições: tempo de resposta adequado

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 146: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 6 – Construindo o SimulES-W 146

Titulo: SDsituations gestão de material de apoio Objetivo: Descrever as regras do material de apoio. Contexto: Localização: Web Java: AdminPage. jogador administrador cria tipos de material de apoio e fornece as informações do material de apoio que serão utilizadas nas cartas conceito cartas problema. Atores: jogador administrador Recursos: informações do projeto, cartas brancas, cartas cinzas, engenheiros de software, jogadores, movimentos do jogo. Episódios: 1- jogador administrador solicita a SimulES inicializar as variáveis do jogo. 2- SimulES inicializa todas a variáveis do jogo. 3- SimulES fornece o resultado a inicialização. 4- jogador administrador estabelece uma nova sessão de jogo. 5- jogador administrador fecha a entrada de novos jogadores na sessão Precondição: jogadores cadastrassem no jogo (joga rodada de inicio). 6- jogador administrador escolhe o material de suporte para o jogo. 7- SimulES cadastra material de apoio que será utilizado no jogo. 8- jogador solicita que jogo seja fechado Precondição: jogador submete produto e gana o jogo (submissão de produto). 9- SimulES fecha o jogo. 10-Informa para todos os jogadores que jogo foi finalizado.

Titulo: gestão do jogo Objetivo: Descrever as regras da gestão do jogo. Contexto: Localização: Web Java: AdminPage. jogador administrador inicializa as variáveis do jogo e fecha a entrada de jogadores para iniciar o jogo. Atores: jogador administrador Recursos: informações do projeto, cartas brancas, cartas cinzas, engenheiros de software, jogadores, movimentos do jogo. Episódios: 1- jogador administrador solicita a SimulES inicializar as variáveis do jogo. 2- SimulES inicializa todas a variáveis do jogo. 3- SimulES fornece o resultado a inicialização. 4- jogador administrador estabelece uma nova sessão de jogo. 5- jogador administrador fecha a entrada de novos jogadores na sessão Precondição: jogadores cadastrassem no jogo (joga rodada de inicio). 6- jogador administrador escolhe o material de suporte para o jogo. 7- SimulES cadastra material de apoio que será utilizado no jogo. 8- jogador solicita que jogo seja fechado Precondição: jogador submete produto e gana o jogo. 9- SimulES fecha o jogo 10- SimulES zera as variáveis do jogo 11-Informa para todos os jogadores que jogo tem finalizado

6.4.4.Refinamento das SDsituations e dos Cenários

Para o refinamento das SDsituations e cenários começamos pela análise dos

atributos de transparência que deviam estar presentes nos modelos e refletidos na

implementação, para isso fizemos uma análise dos atributos da transparência

propostos em [53] e que se encontram detalhados em [22]. Estes foram tratados

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 147: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 6 – Construindo o SimulES-W 147

conjuntamente com os atributos de qualidade para aplicações Web propostos em

[66] como atributos mais importantes a serem levados em consideração no

momento de abordar um desenvolvimento Web. Segundo [66] estes atributos são:

confiabilidade, usabilidade, segurança, disponibilidade, escalabilidade,

manutenção e tempo para o mercado, atributos que de uma ou outra maneira são

tratados pela transparência de software, como resultado desta análise

apresentamos os termos da transparência extraídos do LEL para o SimulES-W:

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 148: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 6 – Construindo o SimulES-W 148

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 149: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 6 – Construindo o SimulES-W 149

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 150: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 6 – Construindo o SimulES-W 150

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 151: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 6 – Construindo o SimulES-W 151

Com o jogo focado nos atributos de transparência, retomamos os modelos

SD e modelos SR e identificamos a pertinência de incorporar alguns dos termos

da transparência acima descritos nesta etapa da modelagem.

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 152: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 6 – Construindo o SimulES-W 152

Como os atributos de transparência são tratados como requisitos não

funcionais eles geralmente estão presentes no sistema todo de forma transversal,

porém apresentamos um modelo indicando como eles foram incorporados após a

análise.

Figura 77 – Modelo SD – Apresentar Dinâmica do Jogo com atributos da

Transparência.

Como ilustramos na Figura 77 alguns elementos de transparência foram

acrescentados no modelo SD Completeza, Corretude, Explicação e Concisão

ajudando atingir os objetivos do jogo e o entendimento do mesmo. Eles são

expressos como requisitos não funcionais dentro da modelagem.

Como vemos na Figura 78 a usabilidade é um item importante dentro da

transparência de software do nosso produto, ele cria a ligação produto e usuário,

onde usuário (jogador) será quem avaliará o produto (SimulES) segundo seu uso.

Os atributos de transparência são importantes em nosso empreendimento já

que eles contribuem para atingir a facilidade do aprendizado, facilidade para

realizar as tarefas, rapidez ao desenvolver as tarefas para o qual o produto foi

desenvolvido, e o mais importante a satisfação do usuário a ser informado sobre o

que o jogo faz, retomando a premissa da transparência de software.

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 153: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 6 – Construindo o SimulES-W 153

Figura 78 – Modelo SR – Apresentar Dinâmica do Jogo com atributos da

Transparência.

A seguir mostramos a descrição mediante cenários da SDsituation

Apresentar Dinâmica do Jogo (relacionada à Figura 78) refinada segundo a

análise dos atributos de transparência. Acreditamos na pertinência da

incorporação dos atributos da transparência em nosso trabalho, pois elas ajudam a

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 154: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 6 – Construindo o SimulES-W 154

garantir um produto de software que satisfaze as expectativas expressas pelos

usuários. Concordamos com [11] quando expõe que “as metas flexíveis

qualificam os elementos da dependência, como conseqüência os elementos desta

dependência não podem ser considerados sem aquela qualificação. Como

resultado a meta flexível indica que uma operacionalização deve ser

desenvolvida”.

Operacionalizações das metas flexíveis serão considerados no item

Operacionalização das SDsituations (6.6).

Titulo: SDsituation apresentar dinâmica do jogo Objetivo: Descrever e disponibilizar as informações gerais do jogo. Contexto: Localização geográfica: Web Localização temporal: Java index Pre-condições: Serviços Web disponíveis Pós-condições: Informações gerais do jogo disponíveis Atores: simules, jogador Recursos: informações do projeto, informações dos jogadores, informações dos movimentos e mensageira Episódios: 1 – jogador entra no jogo 2 – jogador pode trocar mensagens com os jogadores; 3 - jogador executa jogadas no jogo; 4 – simules disponibiliza as informações do projeto escolhido; 5 - simules da nome às atividades do jogo; 6 - simules decompõe as atividades do jogo; 7 - simules valida seqüência das jogadas; 8 – simules disponibiliza as informações de aceitação de movimentos; 9 – simules disponibiliza as mensagens trocadas entre os jogadores; 10 – simules disponibiliza as informações dos movimentos do jogo; Restrições: tempo de resposta adequado Metas flexíveis: completeza [Jogadas] corretude [jogadas disponíveis] explicação [Dinâmica jogo] concisão [Mensagens] detalhamento [Informações] dependência [jogadas] divisibilidade [Rodadas do jogo] simplicidade [mensagens] composição [jogo] intuitividade [gráfica] operabilidade [gráfica] simplicidade [Recursos disponibilizados] corretude [jogadas] consistência [informações] uniformidade [Recursos disponibilizados] acurácia [jogadas aceitas] clareza [jogo] desempenho [jogo] integridade [jogadas x jogador]

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 155: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 6 – Construindo o SimulES-W 155

6.5.Cenários do Sistema

A escolha do MVC como arquitetura para O SimulES permitiu a seguinte

divisão:

Cada SDsituations tem seu correspondente modelo SR que também possui

sua representação em cenário, sua operacionalização situa-se na camada de visão.

Metas e tarefas têm sua representação nos modelos SR que também

possuem sua representação como símbolos tipo verbo, e suas operacionalizações

estão na camada de controle.

Recursos têm sua representação nos modelos SR e também possuem sua

representação como símbolos tipo Sujeito, suas operacionalizações estão na

camada de modelo.

6.5.1.Cenários da Camada de Controle

Aqui estão representados os cenários intermediários entre os cenários da

camada de visão e os cenários da camada modelo, estes cenários se encarregam da

parte lógica responsável do processamento e o comportamento de acordo com às

demandas do usuário, constrói o modelo apropriado e o envia para a camada de

visão para sua adequada visualização.

Titulo: Aceitar Movimentos Objetivo: Descrever as ações necessárias para aceitar movimentos. Localização geográfica: Web Localização temporal: Java AcceptmoveController Pre-condições: Serviços Web disponíveis, Jogada de conceitos em execução Pós-condições: Informações gerais do jogo disponíveis Atores: jogador, simules Recursos: informações do projeto, informações dos jogadores, informações dos movimentos e mensageira Episódios:

- obter todos os movimentos aceitados - obter movimento aceitado - valida que jogador não aceita seu próprio movimento - adicionar avaliação do movimento realizado - apagar movimento

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 156: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 6 – Construindo o SimulES-W 156

Titulo: Controlador de cartas Objetivo: Descrever as operações de controle nas cartas. Localização geográfica: Web Localização temporal: Java CardController Pre-condições: Serviços Web disponíveis, rodada de inicio já foi executada Pós-condições: Atualizar estado das cartas no jogo e para jogador. Atores: jogador, simules Recursos: informações do projeto, informações dos jogadores, informações dos movimentos e mensageira Episódios:

- obter cartas disponíveis - obter carta especifica - obter cartas livres por material de apoio - obter todas as cartas - apagar todas as cartas do repositório - adicionar cartas no repositório - atualizar cartas

Titulo: Controlador de tabuleiro individual Objetivo: Descrever as operações de controle no tabuleiro individual. Localização geográfica: Web Localização temporal: Java IndividualboardController Pre-condições: Serviços Web disponíveis, rodada de ações em execução Pós-condições: Atualizar o tabuleiro individual do jogador. Atores: jogador, simules Recursos: informações do projeto, informações dos jogadores, informações dos movimentos e mensageira Episódios:

- criar o tabuleiro individual para o jogador - obter os tabuleiros individuais dos jogador - obter a configuração do tabuleiro individual do jogador - validar se jogador está registrado no jogo para disponibilizar - atualiza a configuração do tabuleiro do jogador - obter o tabuleiro individual por jogador - apaga os tabuleiros individuais dos jogadores

Titulo: Controlador dos módulos do projeto Objetivo: Descrever as operações de controle nos módulos do projeto. Localização geográfica: Web Localização temporal: Java ModulesProjectController Pre-condições: Serviços Web disponíveis, projeto para o jogo já escolhido Pós-condições: Atores: jogador, simules Recursos: informações do projeto, informações dos jogadores, informações dos movimentos e mensageira Episódios:

- obter os módulos de um projeto especificado - obter os módulos do projeto com estado escolhido - obter os módulos de um projeto organizados em um arranjo - inspecionar módulos especificados - obter os módulos por um identificador

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 157: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 6 – Construindo o SimulES-W 157

Titulo: Controlador de movimentos no jogo Objetivo: Descrever as operações de controle nos movimentos do jogo. Localização geográfica: Web Localização temporal: Java MoveController Pre-condições: Serviços Web disponíveis, rodada de conceitos em execução Pós-condições: Atores: jogador, simules Recursos: informações do projeto, informações dos jogadores, informações dos movimentos e mensageira Episódios:

- obter todos os movimentos - atualizar o movimento para o jogador - atualizar o próximo movimento - obter um movimento especifico - obter o movimento ativo no sistema - obter o mínimo movimento ativo no sistema - reiniciar os movimentos - obter o primeiro movimento no sistema - fechar um movimento - habilitar o próximo movimento - habilitar próximo movimento para o jogador

Titulo: Controlador de cartas por jogador Objetivo: Descrever as operações de controle nos módulos do projeto. Localização geográfica: Web Localização temporal: Java PlayerCardController Pre-condições: Serviços Web disponíveis Pós-condições: Atores: jogador, simules Recursos: informações do projeto, informações dos jogadores, informações dos movimentos e mensageira Episódios:

- obter todas as cartas por jogador - apagar todas as cartas por jogador - adicionar cartas para um jogador - obter cartas de um jogador especifico - obter as cartas problemas submetidas a um jogador especifico - obter as cartas problemas do jogador - obter as cartas conceito por jogador - apagar carta especifica do repositório - obter cartas por jogador

Titulo: Controlador de cartas tipo Objetivo: Descrever as operações de controle nos tipos de cartas. Localização geográfica: Web Localização temporal: Java CardtypeController Pre-condições: Serviços Web disponíveis, rodada de inicio já foi executada Pós-condições: Atualizar estado das cartas no jogo e para jogador. Recursos: informações do projeto, informações dos jogadores, informações dos movimentos e mensageira Atores: simules, jogador Episódios:

- obter os tipos de cartas

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 158: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 6 – Construindo o SimulES-W 158

Titulo: Controlador do jogador Objetivo: Descrever as operações de controle para o jogador. Localização geográfica: Web Localização temporal: Java PlayerController Pre-condições: Serviços Web disponíveis Pós-condições: Atores: jogador, simules Recursos: informações do projeto, informações dos jogadores, informações dos movimentos e mensageira Episódios:

- criar jogador - validar se jogador existe - obter identificador do jogador - obter nome do jogador - obter jogador por nome - obter jogador por identificador - obter todos os jogadores - obter quantidade de jogadores - apagar jogadores - obter o Maximo lançamento do dado dos jogadores - atualizar o valor do lançamento do dado dos jogadores - obter um rango de jogadores - obter o ultimo jogador registrado - obter o primeiro jogador registrado

Titulo: Controlador engenheiros de software por jogador Objetivo: Descrever as operações de controle entre o jogador e seus engenheiros de software. Localização geográfica: Web Localização temporal: Java PlayerSoftengineerController Pre-condições: Serviços Web disponíveis Pós-condições: Atores: jogador, simules Recursos: informações do projeto, informações dos jogadores, informações dos movimentos e mensageira Episódios:

- criar a relação entre engenheiro de software e jogador - obter todas as relações jogador e engenheiros de software - obter uma relação engenheiro de software jogador especifica - obter uma relação engenheiro de software jogador especifica onde engenheiro está em

estado contratado - apagar todas as relações engenheiro de software e jogador - apagar uma relação engenheiro de software e jogador especifica - obter um engenheiro de software especifico - apagar um engenheiro de software de uma relação, especificando engenheiro

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 159: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 6 – Construindo o SimulES-W 159

Titulo: Controlador problemas por jogador Objetivo: Descrever as operações de controle entre o jogador e os problemas submetidos. Localização geográfica: Web Localização temporal: Java PlayersproblemsController Pre-condições: Serviços Web disponíveis Pós-condições: Atores: jogador, simules Recursos: informações do projeto, informações dos jogadores, informações dos movimentos e mensageira Episódios:

- adicionar problema a jogador - obter os problemas de um jogador especifico - obter todos os problemas submetidos - atualizar as observações dos problemas submetidos - aceitar tratamento de um problema submetido - rejeitar tratamento de um problema submetido - atualizar o tratamento dos problemas - obter todos as cartas problemas dos jogadores -obter uma carta problema especifica - apagar todas as relações cartas problemas x jogador

Titulo: Controlador de projeto Objetivo: Descrever as operações de controle do projeto do jogo. Localização geográfica: Web Localização temporal: Java ProjectController Pre-condições: Serviços Web disponíveis Pós-condições: operações sobre o cartão do projeto disponíveis Atores: jogador, simules Recursos: informações do projeto, informações dos jogadores, informações dos movimentos e mensageira Episódios:

- obter todos os projetos do repositório - obter um projeto especifico - obter um projeto por identificador - atualizar o estado do projeto a escolhido - reiniciar estado dos projetos - obter a quantidade de módulos a serem construídos por projeto - obter projeto escolhido - obter a qualidade do projeto escolhido

Titulo: Controlador de estados dos engenheiros de software Objetivo: Descrever as operações de controle sobre os estados dos engenheiros de software. Localização geográfica: Web Localização temporal: Java SoftwareEngineerStatusController Pre-condições: repositório com engenheiros de software Pós-condições: operações com os diferentes estados dos engenheiros de software Atores: simules, engenheiros de software Recursos: informações do projeto, informações dos jogadores, informações dos movimentos e mensageira Episódios:

- obter todos os estados dos engenheiros de software - obter estado de um engenheiro de software especifico

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 160: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 6 – Construindo o SimulES-W 160

Titulo: Controlador de rondas do jogo Objetivo: Descrever as operações de controle das rondas do jogo. Localização geográfica: Web Localização temporal: Java RoundController Pre-condições: Serviços Web disponíveis, fechar a entrada de jogadores já executada Pós-condições: rondas do jogo controladas pelo SimulES Atores: jogador, simules Recursos: informações do projeto, informações dos jogadores, informações dos movimentos e mensageira Episódios:

- obter todas as rondas do jogo - reiniciar todas as rondas do jogo - fechar uma ronda especifica - obter uma ronda especifica - habilitar a seguinte ronda

Titulo: Controlador de engenheiros de software Objetivo: Descrever as operações de controle dos engenheiros de software. Localização geográfica: Web Localização temporal: Java SoftEngineerController Pre-condições: Serviços Web disponíveis Pós-condições: operações com engenheiros de software disponíveis Atores: jogador, simules, engenheiros de software Recursos: informações do projeto, informações dos jogadores, informações dos movimentos e mensageira Episódios:

- obter todos os engenheiros de software - obter um engenheiro de software especifico - obter engenheiros de software disponíveis - atualizar o estado dos engenheiros de software para disponíveis - obter engenheiro de software se está disponível - empregar engenheiro de software - reiniciar engenheiros de software

Titulo: Controlador de material de apoio Objetivo: Descrever as operações de controle sobre o material de apoio. Localização geográfica: Web Localização temporal: Java SourceofcardsController Pre-condições: Pós-condições: operações com os materiais de apoio disponíveis Atores: simules, jogador administrador Recursos: mensageira Episódios:

- obter todos os materiais de apoio - apagar material de apoio - adicionar material de apoio - atualizar material de apoio - obter material de apoio por identificador - obter o Maximo identificador do material de apoio

6.5.2.Cenários da Camada de Modelo

Estes cenários tratam dos objetos ou recursos com os quais o sistema opera.

Lembrando que nós representamos aqueles elementos identificados dentro da

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 161: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 6 – Construindo o SimulES-W 161

modelagem como recurso e que se encontravam dentro do léxico como símbolos

tipo sujeito como candidatos a classe e conseqüentemente parte do modelo. Eles

ganharam representação em cenários, pois eles apresentam comportamentos como

a materialização em objeto e operações com a camada de persistência.

Titulo: Aceitar movimento Objetivo: Descrever as operações para obter o objeto aceitar movimento. Localização geográfica: Web Localização temporal: Java Acceptmove Pre-condições: Banco de dados deve estar disponível Pós-condições: Objeto disponível Atores: simules Recursos: movimentos Episódios: 1- receber objeto da camada de controle 2- conectar ao banco de dado 3- enviar objeto à base de dados 4- receber objeto da base de dados

Titulo: Carta Objetivo: Descrever as operações para obter o objeto carta. Localização geográfica: Web Localização temporal: Java Card Pre-condições: Banco de dados deve estar disponível Pós-condições: Objeto disponível Atores: simules Recursos: carta (identificador, nome, referência, descrição, regra, link), material de apoio, tipo de carta. Episódios: 1- receber objeto da camada de controle 2- conectar ao banco de dado 3- enviar objeto à base de dados 4- receber objeto da base de dados

Titulo: Tipo de Carta Objetivo: Descrever as operações para obter o objeto tipo de carta. Localização geográfica: Web Localização temporal: Java CardType Pre-condições: Banco de dados deve estar disponível Pós-condições: Objeto disponível Atores: simules Recursos: tipo de carta(identificador, descrição). Episódios: 1- receber objeto da camada de controle 2- conectar ao banco de dado 3- enviar objeto à base de dados 4- receber objeto da base de dados

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 162: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 6 – Construindo o SimulES-W 162

Titulo: Tabuleiro Individual Objetivo: Descrever as operações para obter o tabuleiro individual. Localização geográfica: Web Localização temporal: Java Individualboard Pre-condições: Banco de dados deve estar disponível Pós-condições: Objeto disponível Atores: simules Recursos: Tabuleiro Individual (identificador, configuração) Episódios: 1- receber objeto da camada de controle 2- conectar ao banco de dado 3- enviar objeto à base de dados 4- receber objeto da base de dados

Titulo: Módulos do projeto Objetivo: Descrever as operações para obter os módulos de um projeto. Localização geográfica: Web Localização temporal: Java Modulesproject Pre-condições: Banco de dados deve estar disponível Pós-condições: Objeto disponível Atores: simules Recursos: Módulos (identificador, requisitos, desenho, código, rastro, ajuda), projeto Episódios: 1- receber objeto da camada de controle 2- conectar ao banco de dado 3- enviar objeto à base de dados 4- receber objeto da base de dados

Titulo: Módulos do projeto Objetivo: Descrever as operações para obter os módulos de um projeto. Localização geográfica: Web Localização temporal: Java Modulesproject Pre-condições: Banco de dados deve estar disponível Pós-condições: Objeto disponível Atores: simules Recursos: Módulos (identificador, requisitos, desenho, código, rastro, ajuda), projeto Episódios: 1- receber objeto da camada de controle 2- conectar ao banco de dado 3- enviar objeto à base de dados 4- receber objeto da base de dados

Titulo: Movimento Objetivo: Descrever as operações para obter os movimentos no jogo. Localização geográfica: Web Localização temporal: Java Move Pre-condições: Banco de dados deve estar disponível Pós-condições: Objeto disponível Atores: simules Recursos: Movimentos (identificador, descrição, precondição, estado), ronda, jogador Episódios: 1- receber objeto da camada de controle 2- conectar ao banco de dado 3- enviar objeto à base de dados 4- receber objeto da base de dados

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 163: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 6 – Construindo o SimulES-W 163

Titulo: Jogador Objetivo: Descrever as operações para obter os jogadores. Localização geográfica: Web Localização temporal: Java Player Pre-condições: Banco de dados deve estar disponível Pós-condições: Objeto disponível Atores: simules Recursos: Jogador (identificador, nome), dado Episódios: 1- receber objeto da camada de controle 2- conectar ao banco de dado 3- enviar objeto à base de dados 4- receber objeto da base de dados

Titulo: Projeto Objetivo: Descrever as operações para obter os projetos. Localização geográfica: Web Localização temporal: Java Project Pre-condições: Banco de dados deve estar disponível Pós-condições: Objeto disponível Atores: simules Recursos: Projeto (identificador, nome, descrição, complexidade, orçamento, status, tamanho, qualidade) Episódios: 1- receber objeto da camada de controle 2- conectar ao banco de dado 3- enviar objeto à base de dados 4- receber objeto da base de dados

Titulo: Ronda Objetivo: Descrever as operações para obter as rondas do jogo. Localização geográfica: Web Localização temporal: Java Round Pre-condições: Banco de dados deve estar disponível Pós-condições: Objeto disponível Atores: simules Recursos: Ronda (identificador, descrição, status) Episódios: 1- receber objeto da camada de controle 2- conectar ao banco de dado 3- enviar objeto à base de dados 4- receber objeto da base de dados

Titulo: Engenheiro de Software Objetivo: Descrever as operações para obter os engenheiros de software do jogo. Localização geográfica: Web Localização temporal: Java Softengineer Pre-condições: Banco de dados deve estar disponível Pós-condições: Objeto disponível Atores: simules Recursos: Engenheiro de Software (identificador, nome, descrição, salário, habilidade, maturidade), Status. Episódios: 1- receber objeto da camada de controle 2- conectar ao banco de dado 3- enviar objeto à base de dados 4- receber objeto da base de dados

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 164: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 6 – Construindo o SimulES-W 164

Titulo: Material de apoio Objetivo: Descrever as operações para obter material de apoio. Localização geográfica: Web Localização temporal: Java Sourceofcards Pre-condições: Banco de dados deve estar disponível Pós-condições: Objeto disponível Atores: simules Recursos: Material de apoio (identificador, descrição), cartas Episódios: 1- receber objeto da camada de controle 2- conectar ao banco de dado 3- enviar objeto à base de dados 4- receber objeto da base de dados

6.5.3.Cenários da Camada de Visão

Usualmente está relacionada com a interface do usuário, e se encarrega de

transformar o modelo para que possa ser visualizado, ou seja, converte os dados

para que sejam significativos para o usuário e de fácil interpretação. Além disso,

se encarrega da interação com o usuário, por isso, os elementos modelados e

implementados para esta camada são aqueles que apresentamos em sessões

anteriores como os correspondentes às seguintes: apresentar dinâmica do jogo,

construção de artefatos, correção de artefato, gestão de material de apoio, gestão

do jogo, inspeção de artefato, integração de artefatos no módulo, joga rodada de

ações, joga rodada de conceitos, joga rodada de inicio, submissão de produto e

tratamento de problema.

6.6.Operacionalização das SDsituations

No modelo MVC existe uma separação clara entre controlador e a visão. O

controlador é quem recebe o pedido. O modelo trata das operações básicas e a

visão apresenta a interface. Na Figura 79 é mostrada esta arquitetura MVC

refinada e usada para aplicações Web e escolhida para o SimulES-W.

Figura 79 – MVC para aplicações Web [63].

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 165: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 6 – Construindo o SimulES-W 165

6.6.1.Frameworks de Desenvolvimento Web

O termo Framework tornou-se popular nos últimos anos dentro do ambiente

de desenvolvimento de software. É comum encontrar essa palavra em várias

circunstâncias: informações sobre linguagens de programação, informações sobre

novas tecnologias Web, evolução de software, qualidade de software entre outras.

• JavaServer Faces (JSF)

É um framework de interface do usuário do lado do servidor para aplicações

Web baseadas na tecnologia Java e no padrão MVC (Modelo Visão Controlador)

[63].

• Visual Web JavaServer Faces

É um framework de J2EE baseado em JSF. Com este framework é possível

criar páginas Web visualmente. Visual JSF introduz algumas bibliotecas de

extensão para dar suporte ao desenvolvimento de aplicações JSF [63].

• jMaki Ajax Framework

É um framework de Ajax que fornece um modelo para widgets de Ajax

reutilizáveis que podem ser desenhados ou estendidos de ferramentas existentes.

jMaki facilita a passagem de parâmetros para os widgets e fornece os meios para

uma conexão melhor dos widgets com recursos do servidor usando XML ou

JSON. Atualmente, o jMaki runtime do lado do servidor é fornecido como uma

biblioteca de tags JSP ou um componente JSF [63].

• Hibernate 3.2.5

Framework de mapeamento de objetos para o modelo relacional. Hibernate

pode expressar consultas tanto em sua linguagem de consulta chamada HQL

(Hibernate Query Languaje) como em SQL [64].

6.6.2.Ferramentas de Desenvolvimento

• Netbeans 6.5

Ambiente de desenvolvimento integrado de software livre propriedade da Sun

Microsystems com estrutura modular que permite trabalhar com diferentes

linguagens de desenvolvimento.

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 166: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 6 – Construindo o SimulES-W 166

• Servidor de aplicações GlassFish 3.0

Aponta a camada Web para o serviço de aplicações Web e tem um desenho

modular e sua característica principal é que ocupa poucos recursos. Alem disso, é um

servidor Web com suporte a servlets y JSPs.

• MySQL 5.1

É um sistema de gestão de bases de dados relacional, multithreading e

multiusuário. Desenvolvido pela MySQL AB e comprado pela Sun MicroSystems.

6.6.3.Desenvolvimento do SimulES-W

6.6.3.1.Operacionalização dos Cenários da Camada de Visão

Como se falou em sessões anteriores os cenários da camada de visão foram

aqueles mapeados das SDsituations, eles apresentam aos jogadores as

funcionalidades principais do jogo através das telas.

SDsituation apresentar dinâmica do jogo

Esta SDsituations é um caso particular pois ela surgiu em resposta à

operacionalização do tabuleiro individual, ele passou de ser um recurso a ser um

cenário, pois, na implementação ele precisava ter comportamento para atender a

troca de mensagens entre jogadores além de fornecer as informações de interesse

geral.

Na Figura 80 se tem as mensagens dos jogadores, mensagens do jogo, o

projeto escolhido e seus módulos, jogadores on-line e jogadas aceitas que foram

recursos identificados na modelagem.

Finalmente, como esta é a tela principal com as informações de interesse

para todos os jogadores, serve de tabuleiro principal, onde são centralizadas as

informações gerais do jogo.

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 167: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 6 – Construindo o SimulES-W 167

Figura 80 – Tela da SDsituation Apresentar Dinâmica do Jogo.

Lembrando que SDsituations foram descritas usando técnicas de cenários,

na Figura 81 é mostrado como essa descrição chega ao nível do código.

Usaremos a SDsitutions apresentar dinâmica do jogo para ilustrar a

operacionalização na camada de visão e sua descrição usando cenários.

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 168: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 6 – Construindo o SimulES-W 168

Figura 81 – Parte do código da SDsituation Apresentar Dinâmica do Jogo.

SDsituation joga rodada de inicio

Para esta SDsituation a interação sistema jogador é maior, na Figura 82

vemos os principais episódios que são executados pelo jogador e processados pelo

SimulES, também recursos (dado, projeto, engenheiro de software, mensagens)

identificados no modelagem são apresentados aos usuários.

Figura 82 – Tela da SDsituation Joga Rodada de Inicio.

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 169: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 6 – Construindo o SimulES-W 169

SDsituation joga rodada de ações

Em rodada de ações como é apresentado na Figura 83 tem-se o lançamento

do dado como um dos episódios a serem executados, o sistema escolhe

aleatoriamente um valor entre 1 e 6, depois o resultado é apresentado pelo

SimulES para o jogador. Com este resultado o SimulES fornece as cartas conceito

e problema e os engenheiros de software que são apresentados nas tabelas para ao

jogador.

Figura 83 – Tela da SDsituation Joga Rodada de Ações.

SDsituation construção de artefatos

A Figura 84 ilustra o tabuleiro individual na SDsituation construção de

artefato, nesta tela o jogador tem os engenheiros de software contratados para a

construção dos diferentes artefatos, cada um deles com um elo que apresenta as

informações dos engenheiros de software. A Figura representa as cartas brancas e

as cartas cinza sem terem sido desviradas ainda. Também na parte inferior da tela

aparecem as operações possíveis dentro do tabuleiro.

A Figura nos mostra que o jogador escolheu construir artefato, para que

ação seja finalizada, ele tem que submeter a jogada usando o botão Submit.

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 170: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 6 – Construindo o SimulES-W 170

Figura 84 – Tela da SDsituation Construção de Artefatos.

SDsituation inspeção de artefato

Quando o jogador já construiu o artefato ele pode inspecioná-lo. Na Figura

85 ilustramos o resultado de uma inspeção quando o artefato tem erro e quando

não tem. SimulES aleatoriamente escolhe a qualidade da carta branca ou carta

cinza , sendo que as cartas brancas tem menos possibilidades de ter erro que as

cartas cinzas.

Figura 85 – Tela da SDsituation Inspeção de Artefato.

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 171: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 6 – Construindo o SimulES-W 171

SDsituation correção de artefato

Quando é a vez de corrigir algum artefato defeituoso o jogador leva-o para a

caixa de apagar carta (Trash Card) e escolhe do monte de cartas brancas ou cinza

a carta a substituir, como é ilustrado na Figura 86.

Figura 86 – Tela da SDsituation Correção de Artefato.

SDsituation joga rodada de conceitos

A jogada de conceito tem três ações possíveis, como representadas nas Figuras 87,

88, 89. Na primeira (Figura 87) temos as ações com os engenheiros de software.

Se jogador escolhe contratar ele aparecera no tabuleiro individual ou se ele

escolhe demitir o engenheiro voltara para o repositório ficando disponível para

que outro jogador possa contratá-lo.

Figura 87 – Tela da SDsituation Joga Rodada de Conceitos ações sobre os

Engenheiros de Software.

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 172: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 6 – Construindo o SimulES-W 172

Na Figura 88 ilustramos as cartas conceito e problema que o jogador tem

disponível e onde ele pode selecionar para descartar algumas delas, para que estas

voltem a ficar disponíveis para que outros jogadores possam escolhê-las.

Figura 88 – Tela da SDsituation Joga Rodada de Conceitos ação de Descartar

Cartas.

A Figura 89 ilustra como o jogador pode submeter problema para outros

jogadores, ele escolhe um dos jogadores on-line para submeter à carta problema,

com isso, o jogador escolhido recebe a notificação que uma carta problema foi

jogada para ele.

Figura 89 – Tela da SDsituation Joga Rodada de Conceitos ação de Submeter

Problema.

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 173: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 6 – Construindo o SimulES-W 173

SDsituation tratamento de problema

Para tratar uma carta problema existem duas opções que estão relacionadas

com o conteúdo da carta problema, se tem cartas onde o jogador deve pagar uma

penalidade ou se tem cartas que somente podem ser tratadas com cartas conceito.

Na Figura 90 ilustramos os problemas que um jogador tem para serem

tratados, ele escolhe um destes e executa a ação tratar problema.

Figura 90 – Tela da SDsituation Tratamento de Problema, problemas por jogador.

Na Figura 91 ilustramos o caso no qual o jogador escolhe o tratamento do

problema com uma carta conceito, ele submete sua operação para que seja visível

para outros jogadores e estes aceitem seu tratamento, caso contrario a carta

problema volta para o jogador.

Figura 91 – Tela da SDsituation Tratamento de Problema, tratamento com Carta

Conceito.

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 174: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 6 – Construindo o SimulES-W 174

Têm-se os casos no qual o jogador deve pagar uma penalidade com a carta

problema imposta. Aqui o jogador deve explicar como a penalidade foi executada

e submeter. Igual ao caso anterior, os demais jogadores devem aceitar ou rejeitar o

tratamento dado à carta.

Figura 92 – Tela da SDsituation Tratamento de Problema, tratamento com

penalidade.

Na Figura 93 ilustramos os problemas tratados e que aguardam aprovação

dos jogadores. Se o tratamento é aceito o jogador fica liberado da carta, caso

contrario, ela retorna para que o jogador de o tratamento adequado.

Figura 93 – Tela da SDsituation Tratamento de Problema, aceitação de tratamento

problema pelos jogadores.

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 175: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 6 – Construindo o SimulES-W 175

SDsituation integração de artefatos no módulo e submissão de produto

Quando o jogador chega nesta parte do jogo ele tem duas opções ilustradas

na Figura 94, submeter o produto sem ter sido inspecionado (o SimulES realiza a

inspeção aleatoriamente ou os jogadores inspecionaram o produto do jogador

também aleatoriamente) ou submeter quando todos os artefatos tenham sido

inspecionados nas diferentes rodadas do jogo.

Figura 94 – Tela das SDsituations Integração de Artefatos no Módulo e Submissão

de Produto.

SDsituation gestão de material de apoio

As cartas conceito e cartas problemas apresentadas no jogo pertencem a um

grupo ou material de apoio. Antes do jogo começar, um jogador administrador

escolhe o material de apoio e o sistema disponibiliza as cartas que tenham sido

configuradas no sistema para o material de apoio escolhido. Na Figura 95 vemos

as operações que são possíveis realizar na tela para este fim.

Figura 95 – Tela da SDsituation Gestão de Material de Apoio, criar material de

apoio.

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 176: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 6 – Construindo o SimulES-W 176

Cartas problema e cartas conceito que são apresentadas no jogo são geridas

nesta tela (Figura 96), esta ilustra as diferentes operações sobre as cartas além de

configurar a referência ou origem da carta. A Figura 96 nos apresenta as cartas

configuradas para o material de apoio padrão.

Figura 96 – Tela da SDsituation Gestão de Material de Apoio, operações sobre

Cartas Conceito e Cartas Problema.

SDsituation gestão do jogo

Finalmente, a Figura 97 ilustra todas as atividades a fazer antes, durante e no final

do jogo. Estas atividades devem ser realizadas pelo jogador administrador e

garante o correto funcionamento dos recursos. Através das solicitações feitas pelo

jogador administrador o SimulES-W deve fornecer os recursos do jogo.

Figura 97 – Tela da SDsituation Gestão do Jogo.

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 177: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 6 – Construindo o SimulES-W 177

6.6.3.2.Operacionalização dos Cenários da Camada do Modelo

Os elementos identificados como recursos e modelados nos diagramas SR e

diagramas SD foram representados na camada do modelo (Figura 98), além disso,

foram descritos como cenários, pois na implementação apresentaram

comportamentos. A Figura 98 apresenta as propriedades e métodos de cada um

deles.

class Camada Modelo2

java.lang.Object

java.io.Serializable

Cardtype

- cards: Set

- cardtypeId: Integer

- description: String

+ Cardtype() : void

+ Cardtype(String) : void

+ Cardtype(String, Set) : void

+ getCards() : Set

+ getCardtypeId() : Integer

+ getDescription() : String

+ setCards(Set) : void

+ setCardtypeId(Integer) : void

+ setDescription(String) : void

java.lang.Object

java.io.Serializable

Indiv idualboard

- configuration: String

- player: short

+ getConfiguration() : String

+ getPlayer() : short

+ Individualboard() : void

+ Individualboard(short, String) : void

+ setConfiguration(String) : void

+ setPlayer(short) : void

java.lang.Object

java.io.Serial izable

Playercard

- card: Card

- description: String

- id: PlayercardId

- player: Player

+ getCard() : Card

+ getDescription() : String

+ getId() : PlayercardId

+ getPlayer() : Player

+ Playercard() : void

+ Playercard(PlayercardId, Card, Player) : void

+ Playercard(PlayercardId, Card, Player, String) : void

+ setCard(Card) : void

+ setDescription(String) : void

+ setId(PlayercardId) : void

+ setPlayer(Player) : void

java.lang.Object

java.io.Serial izable

PlayersoftengineerId

- playerId: short

- softengineerId: short

+ equals(Object) : boolean

+ getPlayerId() : short

+ getSoftengineerId() : short

+ hashCode() : int

+ PlayersoftengineerId() : void

+ PlayersoftengineerId(short, short) : void

+ setPlayerId(short) : void

+ setSoftengineerId(short) : void

java.lang.Object

java.io.Serializable

PlayersproblemsId

- cardId: short

- playerId: short

+ equals(Object) : boolean

+ getCardId() : short

+ getPlayerId() : short

+ hashCode() : int

+ PlayersproblemsId() : void

+ PlayersproblemsId(short, short) : void

+ setCardId(short) : void

+ setPlayerId(short) : void

java.lang.Object

java.io.Serializable

Round

- description: String

- moves: Set

- roundId: short

- state: String

+ getDescription() : String

+ getMoves() : Set

+ getRoundId() : short

+ getState() : String

+ Round() : void

+ Round(short, String, String) : void

+ Round(short, String, String, Set) : void

+ setDescription(String) : void

+ setMoves(Set) : void

+ setRoundId(short) : void

+ setState(String) : void

java.lang.Object

java.io.Serializable

Softwareengineerstatus

- description: String

- softengineers: Set

- statusId: Short

+ getDescription() : String

+ getSoftengineers() : Set

+ getStatusId() : Short

+ setDescription(String) : void

+ setSoftengineers(Set) : void

+ setStatusId(Short) : void

+ Softwareengineerstatus() : void

+ Softwareengineerstatus(String) : void

+ Softwareengineerstatus(String, Set) : void

java.lang.Object

java.io.Serializable

Sourceofcards

- cards: Set

- description: String

- sourceofcardsId: Short

+ getCards() : Set

+ getDescription() : String

+ getSourceofcardsId() : Short

+ setCards(Set) : void

+ setDescription(String) : void

+ setSourceofcardsId(Short) : void

+ Sourceofcards() : void

+ Sourceofcards(String) : void

+ Sourceofcards(String, Set) : void

java.lang.Object

java.io.Serializable

Playersproblems

- cardByCardId: Card

- cardByCardTreatment: Card

- id: PlayersproblemsId

- observation: String

- player: Player

- state: int

+ getCardByCardId() : Card

+ getCardByCardTreatment() : Card

+ getId() : PlayersproblemsId

+ getObservation() : String

+ getPlayer() : Player

+ getState() : int

+ Playersproblems() : void

+ Playersproblems(PlayersproblemsId, Card, Player, int) : void

+ Playersproblems(PlayersproblemsId, Card, Player, Card, int, String) : void

+ setCardByCardId(Card) : void

+ setCardByCardTreatment(Card) : void

+ setId(PlayersproblemsId) : void

+ setObservation(String) : void

+ setPlayer(Player) : void

+ setState(int) : void

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 178: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 6 – Construindo o SimulES-W 178

class Camada Modelo1

java.lang.Object

java.io.Serializable

Acceptmove

- card: Card

- description: String

- id: AcceptmoveId

- move: Move

- player: Player

+ Acceptmove() : void

+ Acceptmove(AcceptmoveId, Card, Player, Move, String) : void

+ getCard() : Card

+ getDescription() : String

+ getId() : AcceptmoveId

+ getMove() : Move

+ getPlayer() : Player

+ setCard(Card) : void

+ setDescription(String) : void

+ setId(AcceptmoveId) : void

+ setMove(Move) : void

+ setPlayer(Player) : void

java.lang.Object

java.io.Serializable

Card

- acceptmoves: Set

- cardId: Short

- cardtype: Cardtype

- description: String

- name: String

- reference: String

- referencel ink: String

- rule: String

- sourceofcards: Sourceofcards

+ Card() : void

+ Card(Sourceofcards, Cardtype, String, String, String, String) : void

+ Card(Sourceofcards, Cardtype, String, String, String, String, String, Set) : void

+ getAcceptmoves() : Set

+ getCardId() : Short

+ getCardtype() : Cardtype

+ getDescription() : String

+ getName() : String

+ getReference() : String

+ getReferencel ink() : String

+ getRule() : String

+ getSourceofcards() : Sourceofcards

+ setAcceptmoves(Set) : void

+ setCardId(Short) : void

+ setCardtype(Cardtype) : void

+ setDescription(String) : void

+ setName(String) : void

+ setReference(String) : void

+ setReferencel ink(String) : void

+ setRule(String) : void

+ setSourceofcards(Sourceofcards) : void

java.lang.Object

java.io.Serial izable

Modulesproject

- code: Integer

- design: Integer

- help: Integer

- id: ModulesprojectId

- project: Project

- requirement: Integer

- traceabil ity: Integer

+ getCode() : Integer

+ getDesign() : Integer

+ getHelp() : Integer

+ getId() : ModulesprojectId

+ getProject() : Project

+ getRequirement() : Integer

+ getTraceabil ity() : Integer

+ Modulesproject() : void

+ Modulesproject(ModulesprojectId, Project) : void

+ Modulesproject(ModulesprojectId, Project, Integer, Integer, Integer, Integer, Integer) : void

+ setCode(Integer) : void

+ setDesign(Integer) : void

+ setHelp(Integer) : void

+ setId(ModulesprojectId) : void

+ setProject(Project) : void

+ setRequirement(Integer) : void

+ setTraceabi l ity(Integer) : void

java.lang.Object

java.io.Serializable

Move

- acceptmoves: Set

- description: String

- moveId: Short

- player: Player

- precondition: String

- round: Round

- state: String

+ getAcceptmoves() : Set

+ getDescription() : String

+ getMoveId() : Short

+ getPlayer() : Player

+ getPrecondition() : String

+ getRound() : Round

+ getState() : String

+ Move() : void

+ Move(Round, String, String) : void

+ Move(Player, Round, String, String, String, Set) : void

+ setAcceptmoves(Set) : void

+ setDescription(String) : void

+ setMoveId(Short) : void

+ setPlayer(Player) : void

+ setPrecondition(String) : void

+ setRound(Round) : void

+ setState(String) : void

java.lang.Object

java.io.Serial izable

Player

- acceptmoves: Set

- dice: Integer

- moves: Set

- nickname: String

- playerId: Short

+ getAcceptmoves() : Set

+ getDice() : Integer

+ getMoves() : Set

+ getNickname() : String

+ getPlayerId() : Short

+ Player() : void

+ Player(String) : void

+ Player(String, Integer, Set, Set) : void

+ setAcceptmoves(Set) : void

+ setDice(Integer) : void

+ setMoves(Set) : void

+ setNickname(String) : void

+ setPlayerId(Short) : void

java.lang.Object

java.io.Serializable

Playersoftengineer

- description: String

- id: PlayersoftengineerId

- player: Player

- softengineer: Softengineer

+ getDescription() : String

+ getId() : PlayersoftengineerId

+ getPlayer() : Player

+ getSoftengineer() : Softengineer

+ Playersoftengineer() : void

+ Playersoftengineer(PlayersoftengineerId, Softengineer, Player, String) : void

+ setDescription(String) : void

+ setId(PlayersoftengineerId) : void

+ setPlayer(Player) : void

+ setSoftengineer(Softengineer) : void

java.lang.Object

java.io.Serial izable

Project

- budget: int

- complexity: int

- description: String

- modulesprojects: Set

- name: String

- projectId: Short

- qual ity: int

- size: int

- status: int

+ getBudget() : int

+ getComplexity() : int

+ getDescription() : String

+ getModulesprojects() : Set

+ getName() : String

+ getProjectId() : Short

+ getQual ity() : int

+ getSize() : int

+ getStatus() : int

+ Project() : void

+ Project(String, String, int, int, int, int, int) : void

+ Project(String, String, int, int, int, int, int, Set) : void

+ setBudget(int) : void

+ setComplexity(int) : void

+ setDescription(String) : void

+ setModulesprojects(Set) : void

+ setName(String) : void

+ setProjectId(Short) : void

+ setQual ity(int) : void

+ setSize(int) : void

+ setStatus(int) : void

java.lang.Object

java.io.Serial izable

Softengineer

- description: String

- habi l ity: int

- maturi ty: int

- name: String

- salary: int

- softengineerId: Short

- softwareengineerstatus: Softwareengineerstatus

+ getDescription() : String

+ getHabi li ty() : int

+ getMaturity() : int

+ getName() : String

+ getSalary() : int

+ getSoftengineerId() : Short

+ getSoftwareengineerstatus() : Softwareengineerstatus

+ setDescription(String) : void

+ setHabil ity(int) : void

+ setMaturi ty(int) : void

+ setName(String) : void

+ setSalary(int) : void

+ setSoftengineerId(Short) : void

+ setSoftwareengineerstatus(Softwareengineerstatus) : void

+ Softengineer() : void

+ Softengineer(Softwareengineerstatus, String, String, int, int, int) : void

Figura 98 – Operacionalização dos cenários da camada do modelo.

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 179: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 6 – Construindo o SimulES-W 179

Cada uma das classes na camada de modelo foi descrita usando a técnica de

cenários como ilustramos na Figura 99 que representa a classe tabuleiro

individual.

Figura 99 – Parte de código do cenário Tabuleiro Individual na camada modelo.

6.6.3.3.Operacionalização dos Cenários da Camada de Controle

As metas e tarefas que são comportamentos dentro do sistema realizadas

por atores para um adequado fluxo do jogo estão na camada de controle.

As classes da camada de controle, Figura 100 se encarregam de receber as

requisições da camada de visão, processando-as, depois a camada de visão

apresenta o que a camada de controle requisitou.

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 180: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 6 – Construindo o SimulES-W 180

class Camada do Controle

java.lang.Object

AcceptmoveController

~ session: Session

+ AcceptmoveController() : void

+ addConceptPlayer(Player, Move, Card, String) : boolean

+ deleteMove() : boolean

+ existPlayerConcept(Player, Card) : boolean

+ getAcceptmove() : List

+ getAcceptMove(int) : List

java.lang.Object

CardController

~ session: Session

+ addCard(Card) : boolean

+ addCards(Card) : boolean

+ CardController() : void

+ deleteCard(Card) : boolean

+ getCardByID(int) : Card

+ getCards() : List

+ getCardsFree() : List

+ getCardsFree(int) : List

+ updateCard(Card) : boolean

java.lang.Object

CardtypeController

~ session: Session

+ CardtypeController() : void

+ getCardtype(int) : Cardtype

java.lang.Object

Indiv idualboardController

~ session: Session

+ createPlayer(int, String) : boolean

+ deleteIndividualboard() : boolean

+ getIndividualboard() : List

+ getIndividualBoard(int) : Individualboard

+ getPlayerConfiguration(int) : String

+ IndividualboardController() : void

+ playerExist(int) : boolean

+ updateConfigurationByPlayer(int, String) : boolean

java.lang.Object

ModulesProjectController

~ session: Session

+ getModuleById(int) : Modulesproject

+ getModulesProject(int) : List

+ getModulesProjectChose() : List

+ getModulesToInspect(int) : int[]

+ getSumModulesByProject() : int[]

+ ModulesProjectController() : void

java.lang.Object

MoveController

~ session: Session

+ closeMove(int) : boolean

+ enableMoveToPlayer(int, Player) : boolean

+ enableNextMove(int) : boolean

+ firstMoveToStartGame() : boolean

+ getMinMoveActive() : Move

+ getMove(int) : Move

+ getMoveActive() : Move

+ getMovements() : List

+ MoveController() : void

+ restartMove() : boolean

+ updateNextPlayerToMove() : boolean

+ updatePlayerByMove(Player, int) : boolean

java.lang.Object

PlayerCardController

~ session: Session

+ addPlayerCard(Player, Card) : boolean

+ deletePlayerCard() : boolean

+ deletePlayerCard(Card) : boolean

+ getCardsByPlayer(int) : List

+ getCardsConceptByPlayer(int) : List

+ getCardsProblemsByPlayer(int) : List

+ getCardsProByPlayerToSubmit(int) : List

+ getPlayerCard() : List

+ getPlayerCard(Card) : Playercard

+ PlayerCardController() : void

java.lang.Object

PlayerController

~ session: Session

+ createPlayer(String) : boolean

+ deletePlayers() : boolean

+ getMaxDicetByPlayer() : Player

+ getMaxIdPlayer() : Player

+ getMinIdPlayer() : Player

+ getPlayer(String) : Player

+ getPlayer(int) : Player

+ getPlayer() : List

+ getPlayerByNicname(String) : Player

+ getPlayerId(String) : short

+ getPlayerName(int) : String

+ getPlayerNicname(int, int) : List

+ getSizeListPlayer() : int

+ PlayerController() : void

+ playerExist(String) : boolean

+ updatePlayerByDice(Player, int) : boolean

java.lang.Object

PlayerSoftengineerController

~ session: Session

+ addPlayerSoftengineer(short, short) : boolean

+ addPlayerSoftengineer(Player, Softengineer) : boolean

+ addPlayerSoftengineer(short, Softengineer) : boolean

+ addPlayerSoftengineer(int, int) : boolean

+ deletePlayerSoftEng() : boolean

+ deleteRel(Softengineer) : boolean

+ deleteSoftEngPlayerRel(Softengineer) : boolean

+ getPlayerSofteng(Softengineer) : Playersoftengineer

+ getPlayerSoftEngineer() : List

+ getSoftEngByPlayer(int) : List

+ getSoftEngEmployedByPlayer(int) : List

+ PlayerSoftengineerController() : void

java.lang.Object

PlayersproblemsController

~ session: Session

+ acceptProblemTreated(Card, Card) : boolean

+ acceptProblemTreated(Card) : boolean

+ addPlayerProblemCard(Player, Card) : boolean

+ deletePlayersProblems() : boolean

+ getAllCardsProblemsSubmit() : List

+ getCardProblems(Card) : Playersproblems

+ getCardsProblemsByPlayer(int) : List

+ getCardsProblemsList() : List

+ PlayersproblemsController() : void

+ rejectProblemTreated(Card) : boolean

+ updateObsCardsProblems(Card, String) : boolean

+ updateTreatmentCardsProblems(Card, Card) : boolean

java.lang.Object

ProjectController

~ session: Session

+ getProject() : List

+ getProject(int) : List

+ getProjectByID(int) : Project

+ getProjectChoose() : List

+ getQualityProject() : int

+ getSumModulesByProject() : int

+ ProjectController() : void

+ restartProjects() : boolean

+ updateProject(Project) : boolean

java.lang.Object

RoundController

~ session: Session

+ closeRound(int) : boolean

+ enableNextRound(int) : boolean

+ getRound(int) : Round

+ getRounds() : List

+ restartRounds() : boolean

+ RoundController() : void

java.lang.Object

SoftEngineerController

~ session: Session

+ employSoftwareEngineer(Softengineer) : boolean

+ getSoftEngineer() : List

+ getSoftEngineer(int) : Softengineer

+ getSoftEngineerFree() : List

+ getSoftEngineerFree(int) : boolean

+ restartSoftEngineer() : boolean

+ SoftEngineerController() : void

+ updateSoftwareEngineer(Softengineer) : boolean

java.lang.Object

SoftwareEngineerStatusController

~ session: Session

+ getAllSoftEngStatus() : List

+ getSoftEngStatus(int) : Softwareengineerstatus

+ SoftwareEngineerStatusController() : void

java.lang.Object

SourceofcardsController

~ session: Session

+ addSourceofcards(Sourceofcards) : boolean

+ deleteSourceofcards(Sourceofcards) : boolean

+ getMaxSourceofcards() : Sourceofcards

+ getSourceofcards() : List

+ getSourceOfCards(int) : Sourceofcards

+ SourceofcardsController() : void

+ updateSourceofcards(Sourceofcards) : boolean

Figura 100 – Operacionalização dos cenários da camada do controle.

Os elementos da camada de controle também foram descritos usando a

técnica de cenários como é mostrado na Figura 101.

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 181: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 6 – Construindo o SimulES-W 181

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 182: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 6 – Construindo o SimulES-W 182

Figura 101 – Parte de código do cenário controlador de rondas da camada

controle.

6.7.Rastreabilidade em SimulES-W

Para uma adequada gestão dos requisitos é necessário possuir algum

mecanismo de rastreabilidade, que permita identificar a localização e trajetória

dos requisitos até o produto software.

Conforme [67] a rastreabilidade de requisitos visa dar qualidade ao processo

de desenvolvimento do software tanto no processo mesmo de desenvolvimento

quando a evolução de sistema de software. O nosso caso, na Figura 102

apresentamos um fragmento da SDsituation Apresentar Dinâmica do Jogo, onde

ilustramos a localização dos elementos no modelo e dentro da implementação. Por

exemplo, o projeto que é escolhido para ser tratado dentro do jogo é representado

como tarefa dentro do diagrama e vemos sua operacionalização na camada de

controle através do método getProjectChoose, igualmente vemos que um dos

recursos a serem fornecidos nesta SDsituation são os jogadores on-line e eles são

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 183: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 6 – Construindo o SimulES-W 183

obtidos através do tipo objeto jogadores, Portanto, metas e tarefas podem ser

encontradas na camada de controle, recursos e atores na camada de modelo e na

camada de visão as SDsituations de SimulES-W.

Figura 102 – Segmento da SDsituation Dinâmica do Jogo para ilustrar

Rastreabilidade.

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 184: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 6 – Construindo o SimulES-W 184

6.8.Avaliação dos Atributos da Transparência

O SimulES-W, a versão 4.0, surgiu como uma evolução baseada em

modelos intencionais. A idéia é que SimulES-W, pela natureza de sua

implementação, seja uma aplicação Web centrada nos usuários e principalmente

que proporcione uma experiência positiva para os jogadores que buscam em

SimulES um meio para aprendizado de engenharia de software. Esta abordagem

enfatiza a importância de compreender as necessidades do usuário, as ferramentas

e tecnologias utilizadas, e seu contexto social e organizacional.

Acreditamos que um desenvolvimento que esteja centrado no usuário deve

seguir diretrizes baseadas na Transparência de Software, que permita avaliar a

facilidade de uso, rendimento, satisfação e conteúdo, e que por sua vez também

são atributos de qualidade do software.

Embora os atributos fossem tidos em conta na modelagem e representados

como requisitos não funcionais eles precisam ser avaliados desde a perspectiva do

usuário.

Na tabela 11 é apresentado um breve resumo de como os atributos da

transparência foram atendidos na modelagem e na implementação do SimulES-W

desde a perspectiva do desenvolvedor.

Tabela 11 – SimulES-W e os termos da Transparência.

Características

NFR Framework

Operacionalização

Acessibilidade

Portabilidade SimulES tem a capacidade de rodar em qualquer ambiente por ser uma aplicação Web.

Disponibilidade SimulES tem a capacidade de estar disponível por ser uma aplicação Web, dependendo

do servidor onde este alojado e dos serviços de internet dos usuários.

Publicidade SimulES é software livre e execução aberta.

Usabilidade

Simplicidade Modelagem, código e interface projetados para serem simples, usando léxicos e cenários

para explicar os modelos e para explicar o código.

Uniformidade Modelagem, interfaces e código foram projetadas seguindo padrões. O primeiro

modelagem intencional e léxicos e cenários, o segundo o framework Visual Web

JavaServer Faces e o terceiro o padrão de desenho MVC.

Intuitividade Foi focada conforme à terminologia usada no jogo manual, telas e controles levam nomes

alusivos ao processo, telas são executadas conforme a seqüência do jogo original.

Operabilidade Implementação baseada nos modelos, com diferentes níveis de aceso, pode ser

validados nas tarefas descritas na modelagem.

Adaptabilidade Focado na evolução com uma arquitetura MVC que permite fazer mudanças de baixo

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 185: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 6 – Construindo o SimulES-W 185

impacto.

Desempenho Testes de desempenho básicas foram realizadas.

Amigabilidade Modelos descritos em léxicos e cenários o que reduz a complexidade na modelagem.

Desenho simples da interface com navegabilidade em todas as telas.

Informativo

Clareza Desenho visando o entendimento do usuário. Modelagem e implementação que incluem

léxicos e cenários e descrição nas telas conforme terminologia do jogo.

Completeza Itens descritos na modelagem e representados na implementação.

Atualidade A implementação do jogo segue a tendência Web.

Corretude Testes foram realizados, é preciso realizar mais testes.

Comparabilidade Análise comparativo de modelagens em jogos educacionais, além trabalhos práticos de

implementação baseadas na mesma modelagem do SimulES.

Consistência Testes de primeiro nível foram executadas para avaliar resultados esperados.

Integridade Gerenciador de erros, definição de precondições e pós-condições

Acurácia Gerenciador de erros e exceções

Entendimento

Compositividade Baseados nas SDsitiations é possível identificar e reunir as partes na implementação, camada de

visão e camada de controle conforme o descrito nos léxicos e cenários.

Concisão Gestão de mensagens da aplicação com terminologia usada no jogo manual e de forma

concisa.

Dependência A dependência das partes está representada nas SDsituations e implementada conforme

a maquina de estados do jogo.

Divisibilidade Modelagem por partes mediante SDsituations e implementado na arquitetura MVC onde a

camada de visão representa as SDsituations do modelo.

Detalhamento Detalhamento das SDsituations em modelos intencionais e descrição por cenários,

refinamento de cenários conforme a implementação.

Auditabilidade

Controlabilidade Execução com acompanhamento da implementação.

Rastreabilidade Aplicação de técnicas de gestão de configuração na implementação e versionamento da

evolução da modelagem.

Validade Testes executados, com a possibilidade de execução de testes especializados.

Verificabilidade Testes executados, com a possibilidade de execução de testes especializados.

Explicação Ajudas incorporadas na implementação e gerenciamento de mensagens de erros

Para complementar este trabalho se fez necessário a análise desde a

perspectiva do usuário. Fizemos um teste do SimulES-W no LES (Laboratório de

Engenharia de Software) com dois participantes, dessa experiência coletamos

algumas observações:

Observações positivas:

• Jogo útil para o ensino dos conceitos da engenharia de software

• Interface limpa que facilita a jogabilidade

• Cartas problema e conceito estimulam a aprender melhor os

conceitos da engenharia de software

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 186: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

Capítulo 6 – Construindo o SimulES-W 186

• Cores e desenhos adequados da interface.

• Jogo em linha para ensino da engenharia de software.

Pontos de melhora:

• Melhorar as ajudas do jogo

• Confuso no uso dos artefatos

• As cartas brancas e cartas cinzas deveriam mostrar os conceitos para

construção de artefatos, ou seja, as cartas brancas e cinzas deveriam

ter informação e não somente o valor de ter ou não ter erro.

O objetivo da transparência de software é garantir o direito dos usuários a

serem informados sobre aquilo que o software faz, porém, é necessário uma

análise detalhada de cada um dos atributos de transparência desde a perspectiva

do usuário. O trabalho [65] propõe uma método de avaliação de aplicações Web

que poderia servir de base para projetar uma avaliação formal do SimulES-W.

Trataremos disso no próximo capítulo.

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 187: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

7 Conclusão

O conceito de transparência que já se consolidou nos contextos políticos e

empresariais e está se tornando uma força para as mudanças no mundo do

software. Os usuários demandam cada vez mais conhecer e entender aquilo que se

tem por trás dos produtos e serviços que estão adquirindo.

A transparência é um fenômeno social que vai muito além de regulamentos

sobre as informações. Vimos que o conceito de transparência significa ter acesso à

informação independente do perfil de usuário que esteja interessado nos

conteúdos, serviços ou produtos. A transparência levará a que os usuários

avaliem o verdadeiro valor do software que estão consumindo. É claro, então, que

devemos fornecer produtos e software que cumpram esta condição. É neste

contexto que abordamos o trabalho do SimulES, procuramos uma modelagem que

expressa mais claramente a intencionalidade dos jogadores e do software de

apoio. E que também permitisse direcionar-nos até a implementação. Nossa idéia

com isso era deixar a modelagem mais perto da implementação para reduzir os

níveis de complexidade e impacto em futuras evoluções. Vimos que passamos dos

modelos intencionais à criação do modelo de classe que foi base para nossa

implementação, além disso, é possível fazer o mapeamento da modelagem até a

implementação.

Quando procuramos jogos para ensino na engenharia de software queríamos

saber como eles foram modelados, encontramos que este não foi um requisito

relevante no desenvolvimento desses jogos, alguns casos este requisito não foi

atendido ou possuía descrições muito vagas.

Também pesquisamos outros trabalhos para identificar a pertinência da

modelagem intencional como insumo para nossa implementação. Nesses trabalhos

a escolha se fundamentava em que a modelagem intencional permite reduzir a

incompatibilidade entre o sistema e seu ambiente e também consegue representar

os comportamentos da organização.

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 188: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

7 – Conclusão

188

Uma contribuição deste trabalho é a utilização de modelos intencionais

como base para a implementação do SimulES-W. Acreditamos que é uma opção

inovadora, pois nos trabalhos pesquisados sobre jogos a modelagem intencional

não foi utilizada. Os modelos resultantes da elicitação de requisitos foram

utilizados para o entendimento e representação do contexto do jogo assim como

também foram o insumo principal para a implementação do mesmo.

Ênfase especial foi dada ao o processo de passar dos modelos intencionais à

arquitetura MVC e à orientação a objetos. As SDsituations do jogo foram

operacionalizadas na camada de visão pelas características de comportamento

descritas em cada um delas. Os recursos e atores foram operacionalizados na

camada do modelo, já que possuíam características próprias das classes tais como:

objetos, atributos que descreviam suas propriedades, métodos que definiam suas

ações e eventos que definiam suas repostas. As tarefas e metas foram

operacionalizadas na camada de controle, como aquelas atividades a serem

realizadas. Além disso, as técnicas de cenários que foram usadas para descrever os

modelos SR também serviram de técnica para explicar o código.

Consolidamos também a observação de que o uso de cenários para

descrever o código ajuda à transparência de software, concordando com [59].

Finalmente, nossa principal contribuição foi a implementação

computacional do primeiro protótipo do jogo SimulES. Passar de um jogo de

tabuleiro (manual) para um jogo digital na web (SimulES-W) foi um grande

desafio que certamente vai trazer vantagens para os diferentes interessados no

jogo, tanto aqueles que pretendam usar-lo como mecanismo de ensino quanto

aqueles que este interessados no desenvolvimento dele e/ou sua evolução.

Contudo, a principal característica implementada em SimulES-W e que

acreditamos é uma de suas maiores fortalezas é a possibilidade de customizar

características do jogo fazendo com que o professor possa enfatizar tópicos

específicos. Além disso, os jogadores ou estudantes vão ter a possibilidade de

serem direcionados para as fontes dos tópicos que o professor está ensinando, pois

SimulES-W será altamente disponível, característica própria das aplicações Web,

onde consultas poderão ser realizadas em qualquer lugar do mundo e em qualquer

momento, tudo isso feito através da aplicação, dando com isso a possibilidade

reforçar e/ou fortalecer os conceitos ensinados.

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 189: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

7 – Conclusão

189

7.1.Comparação com Trabalhos Relacionados

Dos trabalhos pesquisados na literatura relacionados com jogos

educacionais não encontramos algum que fosse abordado desde a perspectiva

intencional nem que levasse em consideração a interação entre usuários. Nos

trabalhos citados no Capítulo 2 identificamos que em alguns casos não era usado

método algum para modelar os jogos a implementar ou o método não era usado de

forma rigorosa. Acreditamos que em nosso trabalho a modelagem foi uma das

partes mais relevantes não somente para entender o contexto do sistema, mas

também como insumo real para a implementação. Se bem que os trabalhos citados

neste capítulo são software livre, eles não apresentam como foi o mapeamento dos

modelos até o código.

Na segunda parte dos trabalhos relacionados, que listamos no Capítulo 5,

eles refletem que a modelagem intencional é útil para passar de modelos à

implementação e foi assim que na implementação do SimulES-W focamos nesta

mesma prática dando como resultado um protótipo que se baseou diretamente nos

modelos.

Assim como os trabalhos citados no Capítulo 5, nós também acreditamos na

transparência como um fenômeno social que vai provocar profundas mudanças na

engenharia de software como já está acontecendo em outros âmbitos. Porém

precisamos estar preparados procurando modelos e software mais transparente.

7.2.Dificuldades Encontradas

Dentro da modelagem encontramos algumas situações ou episódios que para

serem executadas tinham que ter condicionais. Como exemplo: no diagrama de

SDsituations fica claro a antecedência e descendência de cada uma das

SDsituations, mas dentro delas, ou seja, quando são modeladas nos diagramas SR

isso fica opaco.

Bem parecido ao caso acima, as restrições do sistema não foram possíveis

de modelar nos diagramas SR. Uma solução proposta no trabalho [51] é criar um

novo modelo com aquilo que o software não deveria fazer, mas isso teria maior

complexidade, pois se tem que acrescentar um modelo a mais a cada vez que

aconteça uma restrição.

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 190: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

7 – Conclusão

190

Em nosso trabalho encontramos SDsituations que são derivadas de outras

SDsituations como no caso de cenários que tem subcenários, mas no caso dos

modelos SR, não é possível representar essa derivação. Se bem que o diagrama

SDsituations tem pré-condições não é possível apresentar isso para o leitor em

cada um dos modelos, pois todas as SDsituations ficam no mesmo nível.

As ferramentas utilizadas para criação não possuem gerenciamento de

versões o que dificulta a gerência dos modelos. Além disso, esta mesma

ferramenta não possui navegabilidade dentro dos modelos SR e SD gerando

lentidão quando se trabalha sobre ela.

O problema de gerenciamento de versão também foi evidenciado no CEL

(Editor de léxico e cenários) porque o gerenciamento de versões no CEL é feito

parcialmente.

7.3.Trabalhos Futuros

Em nossos planos está estabilizar a versão hoje disponível do SimulES-W e

empacota-lá para disponibilizar como software livre. Isso vai permitir que aqueles

interessados no jogo tenham disponíveis tanto o código fonte para continuar sua

evolução quanto o “executável” como um serviço Web rodando num servidor e

com interfaces feitas no navegador possibilitando seu uso.

Realizar o refinamento da modelagem do jogo, pois é necessário analisar e

incorporar requisitos não funcionais que ainda não estão representados nos

modelos. Além disso, uma dificuldade encontrada foi manter a integridade entre

os diferentes artefatos gerados, porem este refinamento possibilitará a avaliações

de qualidade na aplicação entre elas a consistência e concordância entre os

diferentes artefatos.

Melhoras nas características do software já foram visadas para SimulES-W.

Entre elas temos: a renderização da tela jogada de conceitos que precisa ser

otimizada para que o usuário não tenha que fazer refresh a cada vez que surge

uma atualização, sugere-se a utilização de Ajax nesta tarefa. A criação de uma tela

que permita a visualização de todos os tabuleiros dos jogadores on-line, com isso

o jogador teria maior controle espacial do jogo e acesso rápido aos diferentes

tabuleiros. A tela de gerenciamento das cartas conceito e cartas problemas precisa

ter uma paginação para melhorar a visualização das mesmas. E finalmente, é

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 191: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

7 – Conclusão

191

preciso criar um mecanismo de controle para cada ronda de jogadas. Isso para

identificar os tempos e quantidade de rodadas em media para que o jogador ganhe

a partida.

Sugerimos também a realização de estudos de caso que procurem o

balanceamento das cartas conceito e cartas problemas, além do balanceamento nos

erros nos artefatos brancos e artefatos cinza visando a otimização do tempo e

dinâmica do jogo, e com isso verificar o grau de facilidade de aplicação do

mesmo.

Experimentos de validação que permitam melhor avaliar a

eficiência/eficácia do SimulES-W tanto desde o foco do ensino da engenharia de

software, quanto da experiência de uso da interface gráfica precisam ser levados

adiante, além disso, testes mais rigorosos sobre a qualidade do SimulES-W como

produto software também devem ser aplicados.

Acreditamos, também, que os atributos de transparência devem ser

avaliados sob a perspectiva da iteração entre o SimulES-W e seus usuários. Varias

abordagens podem servir de apoio a este enfoque. No caso, vamos nos basear na

proposta apresentada em [65]. Este trabalho propõe a avaliação de aplicações Web

tanto no foco da interação, qualidade externa da aplicação Web como no foco da

construção, a qualidade interna do software. O interessante deste trabalho é que

permite avaliar atributos próprios de qualidade como Usabilidade,

Funcionalidade, Confiabilidade, Eficiência, Manutenibilidade, Portabilidade,

Segurança. Vale lembrar que alguns desses atributos são também de interesse na

perspectiva de transparência [9]. Entende-se que esses atributos podem ser

aplicados para uma avaliação do SimulES-W no que concerne a qualidade externa

e visando o atendimento de requisitos de transparência. A abordagem proposta

em [65] propõe a utilização de formulários que mediante a medição quantitativa

do grau de importância do requisito, nível de atendimento ao requisito e

qualidade da solução implementada avalia a qualidade da aplicação Web.

Além dessa avaliação ortogonal, é possível, também, avaliar como

determinadas aplicações são entendidas como aderentes aos atributos de

transparência [9]. Esse processo foi utilizado em [66] com o uso de questionário,

implementado na Web, que procura aquilatar o nível de atendimento de cada

subcritério do grafo de transparência com base nas respostas de avaliação que

podem ser feitas por diferentes pessoas.

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 192: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

8 Referências Bibliográficas

1 BAKER, A.; Hoek, A. van der. Problems and Programmers. Honors Thesis, 2003.

2 Software Engineering Simulation by Animated Models (SESAM) – Stuttgart–Alemanha. Disponível em: <http://www.iste.uni-stuttgart.de/se/research/sesam/overview/index_e.html> acesso em 7 de abril.

3 JAIN, A.; BOEHM, B. SimVBSE: Developing a Game for Value-Based Software Engineering. Proceedings 19th Conference on Software Engineering Education and Training, 2006, pp. 103 -114.

4 SERRANO, M.; SERRANO, M.; NAPOLITANO, B.; SOARES, B. Evolução do SimulES Versão 2.0. . Monografia em Ciências da Computação, Departamento de Informática. PUC–Rio, 2007.

5 FIGUEIREDO, E. M. L.; LOBATO, C. A.; DIAS, K. L.; LEITE, J. C. S. P.; LUCENA, C. J. P. SimulES: Um Jogo para o Ensino de Engenharia de Software. Monografia em Ciência da Computação, Departamento de Informática. PUC–Rio, 2006.

6 FIGUEIREDO, E. M. L.; LOBATO, C. A.; DIAS K. L.; LEITE, J.C.S.P.; LUCENA, C. J. P. Um Jogo para o Ensino de Engenharia de Software Centrado na Perspectiva de Evolução. XV Workshop sobre Educação em Computação (WEI), Rio de janeiro. co–alocado ao XXVII Congresso da SBC, 2007. pp. 37–46.

7 YU, E. Modeling Strategic Relationships for Process Reengineering. Ph.D. Thesis, Graduate Dept. of Comp. Science, University of Toronto, 1995.

8 LEITE, J.C.S.P. Sistemas de software Transparentes. Palestra convidada en el 20 Simposio Brasilero de Ingeniería de Software Octubre de 2006 (http://www-di.inf.puc-rio.br/~julio/Slct-pub/transp-sbes.pdf).

9 CAPPELI, C.; OLIVEIRA, P.; LEITE, J.C.S.P. Exploring Business Process Transparency Concepts, 15th IEEE International Requirements Engineering Conference, RE 2007, pp. 389-390.

10 LEITE, J.C.S.P. A Strategy for Conceptual Model Acquisition, Proceedings of IEEE International Symposium on Requirements Engineering, IEEE, San Diego, Ca, USA, 1993, pp. 243-246.

11 OLIVEIRA, A. P. A. Engenharia de Requisitos Intencional: Um Método de Elicitação, Modelagem e Análise de Requisitos. Tese de Doutorado. PUC–Rio, Março de 2008.

12 CUNHA, H. S. Uso de Estratégias Orientadas a Metas para Modelagem de Requisitos de Segurança. Dissertação de Mestrado, PUC–Rio, Março de 2000.

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 193: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

8 – Referências Bibliográficas

193

13 BIRKHOELZER, T.; NAVARRO, E.; VAN DER HOEK, A. Teaching by Modeling instead of by Models, Proceedings of the 6th International Workshop on Software Process Simulation and Modeling, St. Louis, MO, 2005, pp. 4.

14 CHUNG, L.; NIXON, B.; YU, E.; MYLOPOULOS, J. Non–Functional Requirements in Software Engineering. Kluwer Academic Publishers, 1999.

15 LEITE, J.C.S.P.; WERNECK, V.; OLIVEIRA, A.; CAPPELLI, C.; CERQUEIRA, A.; CUNHA, H.; GONZALEZ–BAIXAULI, B. Understanding the Strategic Actor Diagram: An Exercise of Meta Modeling. 10th Workshop on Requirements Engineering – WER 07, Toronto, Canada, 2007.

16 OLIVEIRA, A.; CYSNEIROS, L. Defining Strategic Dependency Situations in Requirements Elicitation. Proceedings of IX Workshop on Requirements Engineering (WER’2006). Rio de Janeiro, Brasil, Julho 2006. pp. 12–23

17 ROSS, D.; SCHOMAN, A. Structured Analysis for Requirements Definition. IEEE Transactions on Software Engineering, 3(1): 6–15, 1977.

18 LEITE, J. C. S. P.; HADAD, G. D. S.; DOORN, J. H.; KAPLAN, G. N. A Scenario Construction Process. Requirements Engineering Journal 5(1): 38–61, 2000.

19 CYSNEIROS, L. M. Requisitos Não Funcionais: da Elicitação ao Modelo Conceitual. Tese de Doutorado, PUC–Rio, Fevereiro de 2001.

20 NETO, J. S. M. Integrando Requisitos Não Funcionais ao Modelo de Objetos. Disserteção de Mestrado, PUC–Rio, Março de 2000.

21 LEITE, J. C. S. P.; DOORN, J. H.; HADAD, G. D. S.; KAPLAN, G. N. Scenario Inspections. Requirements Engineering Journal 10: 1–21, 2005.

22 Cenários e Léxicos (C&L) – PUC–Rio. Disponível em: <http://pes.inf.puc–rio.br/cel/ >. Acesso em: junho de 2009.

23 LEITE, J.C.S.P.; FRANCO, A. P. M. A Strategy for Conceptual Model Acquisition. In Proceedings of 1th IEEE International Symposium on Requirements Engineering. San Diego, Ca. IEEE Computer Society Press, pp 243–246, 1993.

24 LEITE, J.C.S.P.; ROSSI, G.; BALAGUER, F.; MAIORANA, V.; KAPLAN, G.; HADAD, G.; OLIVEROS, A. Enhancing a Requirements Baseline with Scenarios. Requirements Engineering Journal, 1997; 2(4): 184–198.

25 BREITMAN, K. K.; LEITE, J. C. S. P. A Framework for Scenario Evolution. In Proc. of the Third IEEE Inter. Conference on Requirementes Engineering. IEEE Computer Society Press, Los Alamitos, CA, 1998, pp. 214–221.

26 PASTOR, O.; ESTRADA, H.; MARTÍNEZ, A.; The Strengths and Weaknesses of the i* Framework: an experimental evaluation i*, its Applications, Variations and Extensions. Eric Yu et al. (eds.). MIT Press (accepted for publication in 2006).

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 194: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

8 – Referências Bibliográficas

194

27 ESTRADA, H.; MARTÍNEZ, A.; PASTOR, O.; MYLOPOULOS, J. An Empirical Evaluation of the i* Framework in a Model–Based Software Generation Environment. 18th International Conference on Advanced Information Systems Engineering, Luxembourg, 2006.

28 OLIVEIRA, A. P. A.; LEITE, J. C. S. P.; CYSNEIROS, L. M.; LUCENA, C. J. P. i* Diagnoses: A Quality Process for Building i* Models. Proceedings of the Forum at the CAiSE’08, Montpellier, France, June 18–20, 2008.

29 ISOTTON, E. Ferramenta Educacional para Apoio ao Ensino de Práticas de SCRUM, Monografia de Trabalho de Conclusão de Curso de Graduação, Sistemas de Informação, FACIN, PUCRS, Porto Alegre, 2008.

30 KIELING, E.; ROSA, R. Planager - Um Jogo para Apoio ao Ensino de Conceitos de Gerência de Projetos de Software. Monografia de Trabalho de Conclusão de Curso de Graduação, Ciência da Computação, FACIN, PUCRS, Porto Alegre, 2006.

31 LINO, J. I. Proposta de um Jogo Educacional para Medição e Análise de Software. Trabalho de Conclusão de Curso, Sistemas de Informação, Universidade Federal de Santa Catarina, Florianópolis, 2007.

32 GEE, J. P. Learning by design: Games as learning machines. Anais da Game Developers Conference. San Jose, CA, 2004. pp. 15-23.

33 PRESSMAN, R. Software Engineering: A Practitioner's Approach, sétima edição, 7, Mc Graw Hill, 2006.

34 CLAYPOOL, K.; CLAYPOOL, M. Teaching software engineering through game design, ACM SIGCSE Bulletin, v.37 n.3, September 2005, pp. 123-127.

35 SWEEDYK, E.; KELLER, R. Fun and games: a new software engineering course, ACM SIGCSE Bulletin, v.37 n.3, September 2005, pp. 138-142.

36 BARROS, M. O.; ARAÚJO, R. M. Ensinando Construção de Software Aplicada a Sistemas de Informação do Mundo Real. In: I Fórum de Educação em Engenharia de Software, 2008, Campinas. Anais do I Fórum de Educação em Engenharia de Software, 2008.

37 EBNER, M.; HOLZINGER, A. Successful implementation of user-centered game based learning in higher education: An example from civil engineering, Elsevier, Volume 49, Issue 3, November 2007, pp. 873-890.

38 ROUBIDOUX, M. A.; CHAPMAN, C. M.; PIONTEK, M. E. Development and Evaluation of an Interactive Web based Breast Imaging Game for Medical Students, Elsevier, Volume 9, Issue 10, October 2002, p. 1169-1178.

39 OLIVEIRA, S. S.; NETO, H. B.; GOMES, A. S. Avaliação de software educativo para o ensino de Matemática, WIE, Florianópolis, Brasil, 2002.

40 CHRISTEL, M. G.; KANG K. C. Issues in Requirements Elicitation. Technical Report CMU/SEI–92–TR–12, Software Engineering Institute, Carnegie Mellon University, 1992.

41 Livro Vivo PUC-Rio, Disponível em: <http://livrodeengenhariaderequisitos.blogspot.com/2007/09/entrevistas.html> ultimo acesso em 2 de abril de 2009.

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 195: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

8 – Referências Bibliográficas

195

42 OLIVERA, P. Elicitação de Requisitos de Software Através da Utilização de Questionários, Dissertação de Mestrado, PUC–Rio, Marco de 2005.

43 Transparência PUC-Rio Disponível em: <http://transparencia.les.inf.puc-rio.br/> ultimo acceso 15 de noviembre de 2009.

44 NAPOLITANO, F. M. Uma Estratégia Baseada em Simulação para Validação de Modelos em i*. Dissertação de Mestrado, PUC–Rio, Março de 2009.

45 GRAMIGMA, M. R. M. Jogos de empresa e técnicas vivenciais. Primeira edição, 1, São Paulo: Makron Books, 1994.

46 LEHMAN, M. M. Programs, Cities, Students, Limits to Growth?, Springer, Verlag, 1978, pp. 42–62.

47 LEHMAN, M.M. Laws of Software Evolution Revisited, Springer Verlag, 1997, pp. 108-124.

48 SIMON, H. A. The Sciences of the Artificial. Second Edition. Cambridge MA, The MIT Press, 1981.

49 CARES, C.; FRANCH X.; MAYOL E. Extending Tropos for a Prolog Implementation: A Case Study Using the Food Collecting Agent Problem, Springer, Volume 3900/2006, April 12, 2006, pp. 396-405.

50 BRECIANI, P.; PERINI, A.; GIORGINI, P.; GIUNCHIGLIA, F.; MYLOPOULOS, J. Tropos: An Agent Oriented Software Development Methodology, Volume 8, Issue 3, May 2004, pp. 203–236.

51 RADHAMANI G.; RADHA KRISHNA RAO, G.S.V. An Approach for Intentional Modeling of Web Services Security Risk Assessment. In: Web Services Security and E-Business. 1. ed. Idea Group Inc, 2007. Cap. 20, pp. 363-379.

52 CYSNEIROS, L. M.; WERNECK, V. An Initial Analysis on How Software Transparency and Trust Influence each other. 12th Workshop on Requirements Engineering – WER 09, Valparaíso, Chile, 2009. pp. 27-32.

53 LEITE, J.C.S.P.; CAPELLI, C. Exploring i* Characteristics that Support Software Transparency, in Proc. Of the 3rd International i* Workshop, CEUR Workshop Proceedings Volume 322, 2008 pp. 51-54.

54 MEUNIER, P. Software Transparency and Purity Communications of the ACM, Vol. 51 Issue 2, Feb 2008, pp. 104-104.

55 HOLZNER, B.; HOLZNER L. Transparency in Global Change: The Vanguard of the Open Society. University of Pittsburgh Press; 1 edition, 2006.

56 HENRIQUES, A. Corporate Truth The Limits to Transparency, First Edition, Earthscan, UK, 2007.

57 Lord K. M., The Perils and Promise of Global Transparency, State University of New York Press, 2006.

58 Fung A., Graham M., Weil D., Full Disclosure, the Perils and Promise of Transparency, Cambridge University Press, 2007.

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A

Page 196: Elizabeth Suescún Monsalve - PUC-Riojulio/Elizabeth-ds.pdf · Elizabeth Suescún Monsalve Graduou–se em Engenharia de Informática pelo PCJIC – Institición Universitaria, em

8 – Referências Bibliográficas

196

59 ALMENTERO, E. K. Re-engenharia do software C&L para plataforma Lua-Kepler utilizando princípios de transparência. Dissertação de Mestrado, PUC–Rio, Março de 2009.

60 JAVA, Disponível em <http://java.com/en/>, acesso em: fevereiro de 2010.

61 MySQL, 2008. MySQL 5.1 Reference Manual. Disponível em <http://dev.mysql.com/doc/>, acesso em: fevereiro de 2010.

62 HIBERNATE, 2008. Relational Persistence for Java and .Net. Disponível em <http://www.hibernate.org/>, acesso em: fevereiro de 2010.

63 NETBEANS 6.5, 2008. NetBeans IDE 6.5 Release Candidate Information. Disponível em <http://www.netbeans.org/community/releases/65/>, acesso em: fevereiro de 2010.

64 DOJO, 2010. Documentation. Disponível em <http://dojotoolkit.org/docs>, acesso em: fevereiro de 2010.

65 DE MORAES, E.; WERNECK, V. Uma Abordagem de Avaliação de

Qualidade de Aplicações Web. Cadernos do Ime Série Informática, v. 14, 2003, pp. 71-78.

66 OFFUTT, J. Quality Attributes of Web Software Applications, IEEE Software, vol. 19, no. 2, March/April, 2002, pp. 25-32.

67 SAYÃO, M.; LEITE, J.C.S.P.. Rastreabilidade de Requisitos. . Monografia em Ciências da Computação, Departamento de Informática. PUC–Rio, 2005.

68 CMMI-DEV, 2010. Documentation, Disponível em <http://www.sei.cmu.edu/library/abstracts/reports/06tr008.cfm>, acesso em: fevereiro de 2010.

69 Agent UML, Disponível em <http://www.auml.org/>, acesso em: fevereiro de 2010.

70 LEITE, J.C.S.P.; CAPELLI, C. Software Transparency, Business & Information Systems Engineering (BISE), 2010, Volume 2, Number 3, pp. 127-139.

71 JACK Intelligent Agents, Disponível em <http://www.agent-software.com.au/products/jack/>, acesso em: fevereiro de 2010.

72 CAPPELI, C. Uma Abordagem para Transparência em Processos

Organizacionais Utilizando Aspectos. Tese de Doutorado. PUC–Rio, Agosto de 2009.

PU

C-R

io -

Cert

ific

ação D

igital N

º 0812549/C

A