Projeto

Sistemas de Informação 1
Período 2006.2

Rede de Relacionamentos Jackut Este semestre, desenvolveremos uma rede de relacionamentos, o . Nesta disciplina, a análise é dada pronta para vocês, através desse documento (leiam com bastante atenção) e, principalmente, através dos artefatos de análise executáveis representados pelos testes de aceitação automáticos que serão fornecidos (se você não entendeu essa frase, comece a assistir às aulas). Um dos objetivos desse projeto é fazer com que vocês consigam construir um sistema que passe 100% dos testes de aceitação. Se conseguirem, significa que vocês atingiram o objetivo mais importante no desenvolvimento de software de qualidade: atender aos requisitos do cliente.

Os testes de aceitação acessam apenas a lógica do negócio, não a interface com o usuário. Em um sistema qualquer, interfaces bonitas e fáceis de usar são uma característica muito importante. Entretanto, para facilitar a vida de vocês, só implementaremos a lógica de negócio do sistema, sem implementação alguma de interface com o usuário. Também é uma regra importante separar a interface com o usuário da lógica de negócio e fazer com que seu projeto não tenha interface com o usuário é uma forma de você sacar esse ponto arquitetural importante.

Vocês terão que projetar e implementar o sistema de uma forma incremental. Haverá alguns milestones e, em cada um, novas funcionalidades serão adicionadas ao sistema. As funcionalidades estão descritas dentro de User Stories. Uma User Story consiste de duas partes: 1) uma descrição informal do que se deseja em termos de funcionalidade e das interações que o sistema deve suportar; 2) um conjunto formal de testes de aceitação que, se executarem direitinho, comprovam que a funcionalidade foi implementada como desejada. Em cada um dos milestones, haverá um conjunto de user stories que deverá ser implementado. Aqui você encontra os testes de aceitação para cada user story, e as instruções de como rodá-los. Antes de entregar um milestone, sempre leia as recomendações e a listagem do que deve ser entregue.

Descrição do Projeto (em poucas palavras)

O sistema será construído em etapas (chamadas iterações). Em cada iteração, certas User Stories serão desenvolvidas. Veja os detalhes da análise nas descrições das user stories (há também um glossário dos termos usados no sistema).

Descrição geral

O é um sistema que mantém uma rede de relacionamentos, nos moldes de uma série de outras que há na internet hoje em dia (Orkut, Friendster, etc.). Ele é particularmente inspirado no Orkut (www.orkut.com), mas não é uma cópia deste (é bem mais simples, na verdade).

A funcionalidade desejada do Jackut está descrita em User Stories (Use Cases informais). Cada Story descreve uma interação que o sistema deve suportar. As User Stories receberam prioridades (pelo cliente interessado) e devem ser implementadas de acordo com tais prioridades. Em geral o jackut deve ser capaz de:

·          Manter um cadastro de informações dos usuários (perfis, álbuns, etc.)

·          Manter uma série de informações de relacionamentos entre os usuários (agrupamentos em comunidades, redes de amizade, de fãs, listas de paqueras, etc.)

·          Manter o fluxo de mensagens entre os usuários do sistema.

Detalhes

User stories
Milestones
Testes de aceitação
Linguagem de script
Glossário
Modelo conceitual

As User Stories

As User Stories (plural de User Story) levantadas inicialmente para o sistema estão mostradas abaixo. User Stories são uma forma de expressar requisitos funcionais desejados para o sistema (o que o sistema deve fazer). Observe que, no mundo real, o cliente poderá mudar de idéia com respeito a esses requisitos funcionais ao longo do tempo. É até possível que o professor (danado que é) altere os requisitos no meio do semestre. As User Stories foram priorizadas pelo cliente conforme podem ver na descrição dos milestones.

User Story	Título	Breve Descrição
1	Criação de conta	Permita a um usuário criar uma conta no Jackut . Deve ser fornecido um login, uma senha e um nome com o qual o usuário será conhecido na rede.
2	Criação/Edição de perfil	Permita a um usuário cadastrado do Jackut criar/editar atributos de seu perfil. Ele deve poder modificar qualquer atributo do perfil ou preencher um atributo inexistente.
3	Adição de amigos	Permita a um usuário cadastrado do Jackut adicionar outro usuário como amigo, o que faz o sistema enviar-lhe um convite. O relacionamento só é efetivado quando o outro usuário o adicionar de volta.
4	Envio de recados	Permita a um usuário cadastrado do Jackut enviar um recado a qualquer outro usuário cadastrado.
5	Criação de comunidades	Permita a um usuário cadastrado do Jackut criar uma comunidade. Deve ser fornecido um nome e uma descrição. O usuário passa a ser o dono da comunidade e é o responsável por gerenciar os membros.
6	Adição de comunidades	Permita a um usuário cadastrado do Jackut se adicionar a uma comunidade.
7	Envio de mensagens a comunidades	Permita a um usuário cadastrado do Jackut enviar uma mensagem a uma comunidade. Todos os usuários da comunidade a recebem.
8	Criação de novos relacionamentos	Permita a um usuário cadastrado do Jackut estabelecer outros tipos de relacionamentos dentro da rede, além de amizade; novos tipos incluem relação de fã-ídolo, paqueras e inimizades. Cada uma tem regras específicas, explicitadas nos testes de aceitação.
9	Remoção de conta	Permita a um usuário encerrar sua conta no Jackut. Todas as suas informações devem sumir do sistema: relacionamentos, mensagens enviadas, perfil.

Testes de Aceitação

Aqui você pode baixar os testes de aceitação que você deve rodar para saber se o seu sistema está atendendo direitinho os requisitos. Você usará o EasyAccept para rodar os testes. Veja aqui. Para poder rodar os testes, vocês precisarão criar uma Façade que acessa a business logic do seu sistema segundo uma linguagem de script que foi criada para os testes de aceitação.

Detalhe: num sistema de informação real, a persistência de dados usaria provavelmente um banco de dados. Não faremos isso aqui. A informação persistente pode ser feita em arquivo com XML (vejam java.beans.XMLEncoder e java.beans.XMLDecoder).

Linguagem de Script

Para acessar a business logic de seu programa e poder realizar os testes de aceitação, você precisará implementar uma linguagem de script que consiste nos comandos abaixo. Esses são os comandos usados nos testes de aceitação (us1.txt, us2.txt, etc.). Cada um deles deve corresponder a um método na sua façade.

• zerarSistema
  Apaga todos os dados mantidos no sistema.
• criarUsuario login=<String> senha=<String> nome=<String>
  Cria um usuário com os dados da conta fornecidos.
• abrirSessao login=<String> senha=<String>
  Abre uma sessão para um usuário com o login e a senha fornecidos, e retorna uma id para esta sessão.
• getAtributoUsuario login=<String> atributo=<String>
  Retorna o valor do atributo de um usuário, armazenado em seu perfil
• editarPerfil id=<String> atributo=<String> valor=<String>
  Modifica o valor de um atributo do perfil de um usuário para o valor especificado. Uma sessão válida (identificada por id) deve estar aberta para o usuário cujo perfil se quer editar.
• adicionarAmigo id=<String> amigo=<String>
  Adiciona um amigo ao usuário aberto na sessão especificada através de id.
• ehAmigo login=<String> amigo=<String>
  Retorna true se os dois usuários são amigos.
• getAmigos login=<String>
  Retorna a lista de amigos do usuário especificado (codificado em uma String)
• enviarRecado id=<String> destinatario=<String> mensagem=<String>
  Envia o recado especificado ao destinatário especificado. Uma sessão válida (identificada por id) deve estar aberta para o usuário que deseja enviar o recado.
• lerRecado id=<String>
  Retorna o primeiro recado da fila de recados do usuário com a sessão aberta identificada por id.
• encerrarSistema
  Grava o cadastro em arquivo e encerra o programa. Atingir o final de um script (final de arquivo) é equivalente a encontrar este comando.

Milestones

Teremos 3 milestones. Vejam abaixo.

Vocês vão observar que não pedi interface gráfica (Swing ou Web). Tem dois motivos:

• Não quero que você gaste tempo com GUI
• Não haverá perigo de colocar lógica de negócio na interface se não tiver GUI!

Primeiro milestone

Implemente as user stories 1 a 4.

Recomendações para a entrega:

Coisas que devem ser entregues:

• Código-fonte documentado
• Javadoc do código-fonte (rode o javadoc antes de mandar)

Lembre dos seguintes pontos ao entregar o resultado:

• Entregue um único arquivo zip (ou rar). O nome do arquivo zip deve ser "milestone1-joao-maria.zipx" (ou.rarx) e assim por diante (identificando o milestone e o nome dos membros da equipe). Use a terminação zipx (ou rarx) e não zip (rar) para driblar o gmail que não entrega mails com attachments contendo arquivos executáveis (ele olha dentro de attachments zip/rar). Pode mandar mail para jacques@dsc.ufcg.edu.br.
• Ao extrair do arquivo zip(rar), tudo deve cair no lugar certo para ajudar minha tarefa de testar e verificar seu trabalho.
• Posso extrair do arquivo em qualquer diretório que eu quiser na minha máquina.
• Use apenas nomes de arquivos relativos, pois nomes absolutos que poderão existir na sua máquina poderão não existir na minha máquina.
• Use ant com os seguintes alvos: limpa, compila, doc, testa. Só garanto que o PATH de minha máquina permite executar ant, e os comandos java (javac, java, javadoc, ...).        
• O arquivo build.xml deve estar na raiz do seu zip(rar)
• O comando "ant testa" deve chamar testa.bat. Esse comando executa todos os testes de aceitação. Para poder testar a persistência corretamente, os testes devem ser chamados individualmente. Use esse template para criar seu testa.bat. Se preferir, pode fazer no Linux e entregar um testa.sh equivalente, mas eu testarei no Windows, então entregue um testa.bat.
• Para testar seu programa, usarei os seguintes comandos:
• ant limpa compila doc testa
• Lembre que vou brincar testar seu sistema com meus próprios testes adicionais, hehehe...
• Para ter certeza que tudo funcione adequadamente, teste os passos acima numa máquina diferente daquela onde você desenvolveu o software.
• Se seu projeto não compilar, há penalidade equivalente a 4 dias de atraso (isto é, 20%). Portanto, teste bem e em várias máquinas!
• Estarei testando seu software com o JDK 1.5.0 ou superior. Não peça para que eu use uma versão velha de Java.
• Não topo editar build.xml ou arquivos .bats para acertar o classpath ou qualquer outra coisa.
• Entregue um relatório (chamado relatorio-milestone1.doc - ou txt, ou html, ou pdf, ...) descrevendo seu design e indicando os patterns usados e onde os usou. Seu relatório deve conter:
• Um diagrama de classes, como modelo de design.
• Uma lista dos patterns usados e onde foram usados.
• Eis um exemplo de um bom relatório.
• O projeto será avaliado de acordo com os seguintes pesos:
• Compilação (0% - se não compilar, não aceito o projeto)
• Execução dos testes de aceitação (50%)
• Qualidade da documentação (20%)
• Qualidade do design (20%)
• Qualidade do relatório (10%)
• Eis as instruções dadas a quem vai corrigir os projetos:
• Compilação: extraia os arquivo do zip(rar) e faça "ant limpa compila". O programa deve compilar. Se não compilar, os alunos (e o professor) devem ser avisados imediatamente do fato. A correção desse projeto pára. O projeto receberá uma penalidade, mesmo se for entregue depois para corrigir o problema.
• Testes de aceitação: Execute “ant testa”. Observe se todos os testes de aceitação executam. Para a user story 1, os testes estão em us1.txt e assim por diante. Retire 1 ponto (sobre 10) para cada testes de aceitação que não funciona. No milestone 1, apenas us1, us2, us3 são testadas. A partir do milestone 2, os testes das user stories de milestones anteriores devem ser retestadas.
• Relatório: leia o relatório e dê uma nota de 0 a 10 sobre a qualidade. Deve haver duas seções (ver acima).
• Documentação: verifique a qualidade do javadoc. Deve-se ter uma descrição de cada pacote, cada classe, cada método, cada parâmetro, cada valor de retorno e cada exceção. Não precisa verificar todo o código. Basta fazer um scan rápido. Dê nota de 0 a 10.
• Design: Avalie a qualidade do design examinando o código e/ou o relatório (diagrama de classes). Verifique as entidades principais e seus métodos. As entidades principais fazem sentido? Estão desempenhando responsabilidades adequadas (seus atributos e métodos fazem sentido)? os relacionamentos criados fazem sentido? Dê nota de 0 a 10.

Segundo milestone

Agora, vamos brincar! Você vai receber o projeto de outro grupo e deverá implementar o resto das user stories. Mude o mínimo necessário no programa que você recebeu para implementar a User Story. Você deve avaliar os pontos abaixo (incluir sua avaliação no relatório). Organize seu relatório exatamente usando as seções abaixo. Seja específico e forneça detalhes em cada seção.

• Virtudes: Comente as virtudes do design que você recebeu.
• Fraquezas: Comente as fraquezas do design que você recebeu e as consequentes dificuldades que você teve para implementar as user stories desse milestone.
• Refatoramento: Descrever o refatoramento que você efetuou.
• Avaliação objetiva: Dê uma nota de 0 a 10 para cada uma das áreas abaixo:
• Qualidade da documentação
• Qualidade do design
• Qualidade do código

Terceiro milestone

Agora vamos mexer no código do EasyAccept (baixe o código fonte do EasyAccept  aqui.).

Vocês terão que implementar os comandos abaixo.

Vamos atribuir 50% para a qualidade dos testes e 50% para a correta execução dos testes. Para a User Story M3.4, você pode testar usando o próprio EasyAccept ou usando JUNIT. Já que não forneceremos testes para M3.4, tire suas dúvidas com Osório via email. Você deve descrever os testes que você vai realizar de alguma forma (em português, scripts, etc.) e enviar a descrição até uma data (ver aqui). Mais adiante, você deve entregar o código do easyaccept com os testes funcionando. Seus testes devem rodar através do build.xml do easyaccept. 

User Story	Título	Breve Descrição
M3.1	Comando restart	Implemente um novo comando no EasyAccept chamado restart. Esse comando serve para reiniciar o EasyAccept. A execução continua na linha seguinte com uma nova instanciação da Façade. Queremos esse comando para evitar no futuro termos que usar mais de um script para testar persistência.
M3.2	Comando differentFiles	Implemente no EasyAccept o comando differentFiles. A sintaxe é:   differentFiles <arquivo1> <arquivo2> O comando deve resultar em erro se os arquivos forem iguais.
M3.3	Comando expectAnyError	Implemente o comando expectAnyError, que espera um erro qualquer lançado pelo programa, independente da mensagem. O teste passa se qualquer erro for lançado pelo comando. A sintaxe é: expectAnyError <comando> Note que é diferente de expectError <mensagem> <comando>.
M3.4	Processamento de tabelas simples	Implemente no EasyAccept o comando processThisLoop, para execução de tabelas simples. O comando processThisLoop aparece isolado em uma linha do script. É seguido por uma série de linhas com comandos usuais de um script para EasyAccept (é a “descrição” da tabela). Em seguida, deve aparecer uma linha começando com a palavra reservada forThisData, seguida na mesma linha por uma série de variáveis do EasyAccept que serão usadas como cabeçalho das colunas da tabela. Após essa linha, aparecem no script uma série de linhas com valores das “células” das tabelas. A ordem escolhida para os cabeçalhos deve corresponder à ordem dos valores encontrados nas células. Cada linha da tabela corresponde a uma execução do loop. Cada célula de uma linha contém o valor do cabeçalho correspondente para a execução da linha. O caracter “!”, quando antecede o conteúdo de uma célula, sinaliza que o comando correspondente no loop deve ser um expectError para a mensagem que segue, ou expectAnyError se não houver mensagem na seqüência.  O processamento da tabela termina com uma linha contendo a string endLoop. Veja um exemplo abaixo: processThisLoop     expect ${placeName} getPlaceName ${placeId}     expect ${placeGroup} getPlaceGroup ${placeId}     expect ${placeOwner} getPlaceOwner ${placeId}     expect ${propertyRent} getPropertyRent ${placeId}     expect ${placePrice} getPlacePrice ${placeId} forThisData placeId placeName placeGroup placeOwner propertyRent placePrice     1 "Mediterranean Avenue" purple bank 2 60     2 "Community Chest 1" chest !"Can't be owned" !"Doesn't have a rent" !"Can't be sold"     3 "Baltic Avenue" purple bank 4 60     4 "Income Tax" tax !"Can't be owned" !"Doesn't have a rent" !"Can't be sold"     5 "Reading Railroad" railroad bank !"Doesn't have a rent" 200     6 "Oriental Avenue" "light blue" bank 6 100 endLoop A tabela substitui um script que ficaria bem maior, com 30 linhas (6 linhas da tabela x 5 comandos na descrição da tabela).

Modelo Conceitual

Lembrem que o modelo de design (que será implementado em software) não precisa seguir o modelo conceitual entidade-por-entidade.

Glossário

• Álbum: Conjunto de fotos armazenado no perfil de um usuário do Jackut.
• Amigo: Relacionamento bidirecional entre usuários do Jackut que autoriza a visualização mútua de perfil por inteiro.
• Atributo: Uma informação sobre um usuário, incluída em seu perfil. Um atributo tem um nome e um valor. Os valores são strings. Atributos podem ser adicionados e removidos.
• Comunidade: Um conjunto de usuários do Jackut, reunidos em torno de um tema comum. Usuários participam de uma comunidade enviando mensagens.
• Fã: Relacionamento unidirecional entre usuários do Jackut em que um usuário é adicionado à lista de fãs do outro para visualização em seu perfil.
• Membro: Usuário que está cadastrado em uma comunidade (membro da comuniadade).
• Mensagem: Dentro do sistema Jackut, é aquela enviada de um usuário para uma comunidade (todos os seus membros).
• Paquera: Relacionamento unidirecional entre dois usuários do Jackut que, quando estabelecido por ambos, faz o sistema enviar uma mensagem-cupido para ambos os usuários.
• Perfil: Um conjunto de informações sobre um usuário do Jackut. Inclui dados pessoais, profissionais, interesses ou o que mais o usuário quiser informar sobre si mesmo.
• Recado: Tipo especial de mensagem, enviada entre usuários cadastrados do Jackut.
• Relacionamento: Denominação entre dois usuários do Jackut. Podem ser unidirecionais (um usuário em relação com outro) ou bidirecionais (dois usuários mutuamente recebem a mesma denominação). Cada tipo de relacionamento permite ações específicas dentro do sistema.