O artigo de refactoring "Evolving Object-Oriented Designs with Refactorings" de Tokuda e Batory pode ser encontrado aqui.
Estou um pouco atrasado com a Versão 1.0, mas amanhã (Terça) ela
estará disponível.
segunda-feira, maio 29, 2006
segunda-feira, maio 22, 2006
Versão 0.0
Regras do Jogo
Objetivo do jogo:
Os jogadores competem para terminar um projeto de software. É vencedor quem consegue completar o projeto primeiro.
Através do jogo os jogadores aprendem conceitos de engenharia de software, sob a ótica de evolução.
Peças do Jogo:
Cartas, tabuleiro, projeto, dado.
São os seguintes os tipos de cartas:
1. engenheiros de software (cartas que descrevem típicos engenheiros de software). Essas cartas são o principal recurso que o jogador terá para terminar o jogo. São os engenheiros de software que produzem os artefatos, que são necessários para se cumprir o projeto.
2. problemas, cartas que descrevem problemas clássicos de engenharia de software resultantes de falhas no processo de produção. Essas cartas são utilizadas, para criar obstáculos ao progresso dos engenheiros de software dos outros jogadores.
3. conceitos, cartas que descrevem boas práticas de engenharia de software. Essas cartas podem ser utilizadas pelos jogadores para avançarem face ao seu objetivo.
4. artefatos, cartas que simbolizam os artefatos produzidos. Esses artefatos podem variar em graus de qualidade. Através da composição dos artefatos um jogador será o vencedor assim que cumprir o determinado no projeto.
O tabuleiro é uma área onde cada jogador coloca seus engenheiros de software em colunas.
O projeto é escolhido aleatoriamente de uma série de projetos padrão, que determinam uma série de condições sobre como compor o produto final, bem como descrevem os recursos disponíveis.
Visão Geral:
Podem jogar de 4 a 9 jogadores.
Os jogadores sentam-se na mesa de jogo. Cada jogador deve ter um espaço próximo a si para montar seu tabuleiro de jogo. Um projeto é sorteado do conjunto de projetos. As informações desse projeto devem ficar visíveis a todos os jogadores (sugere-se que o projeto fique no centro da mesa).
As cartas são separadas em três montes: um para as cartas engenheiros de software, outro para as cartas de problemas e conceitos e outro para as cartas de artefatos. Essas cartas deverão estar viradas.
Com o dado escolhe-se quem começa o jogo. O jogo deve prosseguir no sentido horário.
O jogador da vez joga o dado e de acordo com o número tirado retira tantas cartas quantas as indicadas pelo dado de dois dos montes a sua escolha. Dessas, o jogador seleciona 2 de cada monte e descarta as outras. O descarte significa que as cartas rejeitadas retornam ao monte na parte inferior. Caso o jogador tenha tirado o número 1 ele joga o dado novamente. Caso o jogador tenha tirado o número 2, não haverá descarte.
Exemplo: É a vez de Maria. Ela joga o dado. O número tirado é 4. Maria seleciona dois montes; que podem ser: engenheiros e artefatos ou engenheiros e problemas/conceitos ou artefatos e problemas/conceitos. De cada um ela retira 4 cartas (já que o dado indicou 4). Escolhe, segundo sua estratégia de jogo e os limites impostos pelo projeto, duas cartas de cada monte. Se as cartas forem de problemas/conceitos, ela as guarda na sua mão. Se as cartas forem de engenheiros ela coloca-os no tabuleiro. Se as cartas forem de artefatos ela coloca-as na coluna do engenheiro de software escolhido para ser o responsável por aquele artefato. Claro que Maria só pode descartar as cartas de artefatos se tiver colocado no tabuleiro seus engenheiros de software.
Ao fim de sua jogada. O jogador está apto a receber dos seus adversários as cartas de problemas. Ele pode receber cartas de problemas dos 3 jogadores que jogaram imediatamente antes dele. Claro, que na primeira jogada esse caso não ocorrerá, já que ninguém jogou ainda. Cada um dos 3 jogadores pode colocar um obstáculo para o jogador da vez. As cartas de problemas recebidas, ou alteram diretamente o estado do tabuleiro do jogador ou devem ser guardadas. O conteúdo das cartas deve ser lido em voz alta pelo jogador que coloca o obstáculo. Cabe a todos os outros jogadores prestarem atenção aos efeitos do problema ocorrido.
As cartas de conceito devem ficar na mão do jogador e podem ser utilizadas quando lhe convier, segundo sua estratégia. Elas poderão ser utilizadas, por exemplo, para evitar uma carta de problema, ou poderão ser usadas para aumentar a produtividade da equipe de engenheiros de software.
Abaixo, vai uma primeira tentativa de mostrar a dinâmica do jogo usando a técnica de léxico e cenários (parcialmente). Vide mais informações aqui e aqui.
Título: Primeira jogada
Objetivo: Dar início ao jogo
Contexto: Informações do projeto no centro da mesa
Primeiro jogador já foi escolhido
Atores: jogadores
Recursos: dado, cartas, informações do projeto
Episódio:
Jogador lança dado.
Se dado igual a 1, então jogador lança dado. Restrição: jogador só prossegue após tirar número diferente de 1.
Jogador escolhe combinação de montes.
Jogador escolhe 2 cartas de cada monte. Restrição: jogador deve respeitar as condições do projeto e usar estratégia de jogo.
Se carta é do tipo engenheiros de software então jogador monta tabuleiro.
Se carta é do tipo conceitos ou problemas jogador guarda cartas.
Se carta é do tipo artefato então jogador atribui artefato a um engenheiro de software. Restrição: jogador só pode fazer isso se tiver o tabuleiro com os engenheiros de software.
Jogo
Noção: Entretenimento entre jogadores.
Objetiva simular um projeto de software com caráter educativo.
É composto de tabuleiro, dado, cartas, mesa e informações de projeto
Impacto: Jogam de 4 a 9 jogadores.
O jogo é iniciado com a escolha do primeiro jogador.
O jogo termina quando um jogador completa o projeto.
Informações do projeto (...)
Mesa (...)
Jogador / Jogadores (...)
Dado (...)
Objetivo do jogo:
Os jogadores competem para terminar um projeto de software. É vencedor quem consegue completar o projeto primeiro.
Através do jogo os jogadores aprendem conceitos de engenharia de software, sob a ótica de evolução.
Peças do Jogo:
Cartas, tabuleiro, projeto, dado.
São os seguintes os tipos de cartas:
1. engenheiros de software (cartas que descrevem típicos engenheiros de software). Essas cartas são o principal recurso que o jogador terá para terminar o jogo. São os engenheiros de software que produzem os artefatos, que são necessários para se cumprir o projeto.
2. problemas, cartas que descrevem problemas clássicos de engenharia de software resultantes de falhas no processo de produção. Essas cartas são utilizadas, para criar obstáculos ao progresso dos engenheiros de software dos outros jogadores.
3. conceitos, cartas que descrevem boas práticas de engenharia de software. Essas cartas podem ser utilizadas pelos jogadores para avançarem face ao seu objetivo.
4. artefatos, cartas que simbolizam os artefatos produzidos. Esses artefatos podem variar em graus de qualidade. Através da composição dos artefatos um jogador será o vencedor assim que cumprir o determinado no projeto.
O tabuleiro é uma área onde cada jogador coloca seus engenheiros de software em colunas.
O projeto é escolhido aleatoriamente de uma série de projetos padrão, que determinam uma série de condições sobre como compor o produto final, bem como descrevem os recursos disponíveis.
Visão Geral:
Podem jogar de 4 a 9 jogadores.
Os jogadores sentam-se na mesa de jogo. Cada jogador deve ter um espaço próximo a si para montar seu tabuleiro de jogo. Um projeto é sorteado do conjunto de projetos. As informações desse projeto devem ficar visíveis a todos os jogadores (sugere-se que o projeto fique no centro da mesa).
As cartas são separadas em três montes: um para as cartas engenheiros de software, outro para as cartas de problemas e conceitos e outro para as cartas de artefatos. Essas cartas deverão estar viradas.
Com o dado escolhe-se quem começa o jogo. O jogo deve prosseguir no sentido horário.
O jogador da vez joga o dado e de acordo com o número tirado retira tantas cartas quantas as indicadas pelo dado de dois dos montes a sua escolha. Dessas, o jogador seleciona 2 de cada monte e descarta as outras. O descarte significa que as cartas rejeitadas retornam ao monte na parte inferior. Caso o jogador tenha tirado o número 1 ele joga o dado novamente. Caso o jogador tenha tirado o número 2, não haverá descarte.
Exemplo: É a vez de Maria. Ela joga o dado. O número tirado é 4. Maria seleciona dois montes; que podem ser: engenheiros e artefatos ou engenheiros e problemas/conceitos ou artefatos e problemas/conceitos. De cada um ela retira 4 cartas (já que o dado indicou 4). Escolhe, segundo sua estratégia de jogo e os limites impostos pelo projeto, duas cartas de cada monte. Se as cartas forem de problemas/conceitos, ela as guarda na sua mão. Se as cartas forem de engenheiros ela coloca-os no tabuleiro. Se as cartas forem de artefatos ela coloca-as na coluna do engenheiro de software escolhido para ser o responsável por aquele artefato. Claro que Maria só pode descartar as cartas de artefatos se tiver colocado no tabuleiro seus engenheiros de software.
Ao fim de sua jogada. O jogador está apto a receber dos seus adversários as cartas de problemas. Ele pode receber cartas de problemas dos 3 jogadores que jogaram imediatamente antes dele. Claro, que na primeira jogada esse caso não ocorrerá, já que ninguém jogou ainda. Cada um dos 3 jogadores pode colocar um obstáculo para o jogador da vez. As cartas de problemas recebidas, ou alteram diretamente o estado do tabuleiro do jogador ou devem ser guardadas. O conteúdo das cartas deve ser lido em voz alta pelo jogador que coloca o obstáculo. Cabe a todos os outros jogadores prestarem atenção aos efeitos do problema ocorrido.
As cartas de conceito devem ficar na mão do jogador e podem ser utilizadas quando lhe convier, segundo sua estratégia. Elas poderão ser utilizadas, por exemplo, para evitar uma carta de problema, ou poderão ser usadas para aumentar a produtividade da equipe de engenheiros de software.
Abaixo, vai uma primeira tentativa de mostrar a dinâmica do jogo usando a técnica de léxico e cenários (parcialmente). Vide mais informações aqui e aqui.
Título: Primeira jogada
Objetivo: Dar início ao jogo
Contexto: Informações do projeto no centro da mesa
Primeiro jogador já foi escolhido
Atores: jogadores
Recursos: dado, cartas, informações do projeto
Episódio:
Jogador lança dado.
Se dado igual a 1, então jogador lança dado. Restrição: jogador só prossegue após tirar número diferente de 1.
Jogador escolhe combinação de montes.
Jogador escolhe 2 cartas de cada monte. Restrição: jogador deve respeitar as condições do projeto e usar estratégia de jogo.
Se carta é do tipo engenheiros de software então jogador monta tabuleiro.
Se carta é do tipo conceitos ou problemas jogador guarda cartas.
Se carta é do tipo artefato então jogador atribui artefato a um engenheiro de software. Restrição: jogador só pode fazer isso se tiver o tabuleiro com os engenheiros de software.
Jogo
Noção: Entretenimento entre jogadores.
Objetiva simular um projeto de software com caráter educativo.
É composto de tabuleiro, dado, cartas, mesa e informações de projeto
Impacto: Jogam de 4 a 9 jogadores.
O jogo é iniciado com a escolha do primeiro jogador.
O jogo termina quando um jogador completa o projeto.
Informações do projeto (...)
Mesa (...)
Jogador / Jogadores (...)
Dado (...)
Regras do Jogo
Estou um pouco atrasado com a versão 0.0. Devo postar ainda hoje.
No entanto, o Eduardo avançou no trabalho. Por favor, dêem uma olhada no blog dele (aí do lado).
Obrigado.
No entanto, o Eduardo avançou no trabalho. Por favor, dêem uma olhada no blog dele (aí do lado).
Obrigado.
quinta-feira, maio 11, 2006
Nova versão das Instruções
Temos uma versão 3.0 das instruções. Creio que podemos congela-la, tendo em vista que agora vamos partir
para as instruções do novo jogo.
Lembrem do combinado. Vamos utilizar o "blog" para colocarmos nossas idéias sobre como deveria ser o novo jogo.
Na próxima Segunda vamos ter como objetivo sair com uma versão 0.0 do novo jogo. Estaremos trabalhando em um nível mais alto de abstração, isto é estaremos tratando das regras gerais e da dinâmica do jogo.
Creio que ficou concordado que o jogo teria de 4 a 9 participantes. Certo?
para as instruções do novo jogo.
Lembrem do combinado. Vamos utilizar o "blog" para colocarmos nossas idéias sobre como deveria ser o novo jogo.
Na próxima Segunda vamos ter como objetivo sair com uma versão 0.0 do novo jogo. Estaremos trabalhando em um nível mais alto de abstração, isto é estaremos tratando das regras gerais e da dinâmica do jogo.
Creio que ficou concordado que o jogo teria de 4 a 9 participantes. Certo?
Novo Artigo para Leitura
Aqui vai um artigo recente do Journal of Software Maintenance and Evolution, seu título é Towards a taxonomy of software change.
Vejamos o quanto ele pode ser útil no nosso trabalho.
Vejamos o quanto ele pode ser útil no nosso trabalho.
Espaço de Produto x Espaço de Versão
O artigo que recomendei centra sua análise no espaço de produto e no espaço de versão. Comentei na última reunião que a gerência de configuração é uma combinação desses espaços.
Nessa combinação influem diversos fatores, mas principalmente:
a) a base representacional do espaço de produto: o que efetivamente é guardado na configuração, o esquema proposto no artigo é simples, apesar de bastante eficaz (árvores E/OU). Lembrei que pode haver necessidade de outros tipos de esquema, como por exemplo, quando é necessário anotações extras como a justificativa de porque uma ligação existe.
b) a versão é normalmente um conceito aplicado a um elemento, mas a agregação desses elementos, um produto, também é alvo de diferentes versões.
c) a granularidade do que está sob controle, e
d) a transformação de elementos que podem deixar de existir ou agregar-se, total ou parcialmente, a outros elementos.
O sistema de informação para tratar da gerência de configuração é um sistema não trivial, e é tanto mais complexo, quanto maior for o nível de granularidade e do controle necessário.
Portanto, não deixem de ler o referido artigo. Se acharem um melhor, me digam, mas esse é o que me parece tratar de maneira mais detalhada dos princípios básicos de um sistema desse tipo.
Nessa combinação influem diversos fatores, mas principalmente:
a) a base representacional do espaço de produto: o que efetivamente é guardado na configuração, o esquema proposto no artigo é simples, apesar de bastante eficaz (árvores E/OU). Lembrei que pode haver necessidade de outros tipos de esquema, como por exemplo, quando é necessário anotações extras como a justificativa de porque uma ligação existe.
b) a versão é normalmente um conceito aplicado a um elemento, mas a agregação desses elementos, um produto, também é alvo de diferentes versões.
c) a granularidade do que está sob controle, e
d) a transformação de elementos que podem deixar de existir ou agregar-se, total ou parcialmente, a outros elementos.
O sistema de informação para tratar da gerência de configuração é um sistema não trivial, e é tanto mais complexo, quanto maior for o nível de granularidade e do controle necessário.
Portanto, não deixem de ler o referido artigo. Se acharem um melhor, me digam, mas esse é o que me parece tratar de maneira mais detalhada dos princípios básicos de um sistema desse tipo.
sexta-feira, maio 05, 2006
Versão 2.0 das Regras
Desculpem o atraso. Aqui vai a versão 2.o. Leiam e comentem até Terça (no máximo até as 12 horas), para que eu possa gerar a versão 3.0.
Vale lembrar que é bom ir pensando sobre os cartões e sobre o que queremos mudar. Por exemplo: para evolução documentos são importantes, e devem estar claros, mas principalmente eles devem poder ser "rastreados", isto é devem deixar uma trilha.
Lembrem das leis de evolução e das noções de gerencia de configuração (mudanças).
Vale lembrar que é bom ir pensando sobre os cartões e sobre o que queremos mudar. Por exemplo: para evolução documentos são importantes, e devem estar claros, mas principalmente eles devem poder ser "rastreados", isto é devem deixar uma trilha.
Lembrem das leis de evolução e das noções de gerencia de configuração (mudanças).
Assinar:
Postagens (Atom)