elizabeth suescún monsalve - puc-riojulio/elizabeth-ds.pdf · elizabeth suescún monsalve...
Post on 22-Sep-2020
2 Views
Preview:
TRANSCRIPT
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Capítulo 6 – Construindo o SimulES-W 134
PU
C-R
io -
Cert
ific
ação D
igital N
º 0812549/C
A
Capítulo 6 – Construindo o SimulES-W 135
PU
C-R
io -
Cert
ific
ação D
igital N
º 0812549/C
A
Capítulo 6 – Construindo o SimulES-W 136
PU
C-R
io -
Cert
ific
ação D
igital N
º 0812549/C
A
Capítulo 6 – Construindo o SimulES-W 137
PU
C-R
io -
Cert
ific
ação D
igital N
º 0812549/C
A
Capítulo 6 – Construindo o SimulES-W 138
PU
C-R
io -
Cert
ific
ação D
igital N
º 0812549/C
A
Capítulo 6 – Construindo o SimulES-W 139
PU
C-R
io -
Cert
ific
ação D
igital N
º 0812549/C
A
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
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
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
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
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
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
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
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
Capítulo 6 – Construindo o SimulES-W 148
PU
C-R
io -
Cert
ific
ação D
igital N
º 0812549/C
A
Capítulo 6 – Construindo o SimulES-W 149
PU
C-R
io -
Cert
ific
ação D
igital N
º 0812549/C
A
Capítulo 6 – Construindo o SimulES-W 150
PU
C-R
io -
Cert
ific
ação D
igital N
º 0812549/C
A
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Capítulo 6 – Construindo o SimulES-W 181
PU
C-R
io -
Cert
ific
ação D
igital N
º 0812549/C
A
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
top related