Projeto de Sistemas de Informação 1 e 2

Período 2004.1

O Jato: Sistema de Mala Direta

Este semestre, desenvolveremos um sistema de mala direta simples. Como estamos fazendo uma disciplina de Design antes da disciplina de Análise, os artefatos de análise (os mais importantes) serão dados para você. Você deve projetar e implementar o sistema. Lembre que a parte de testes é uma das mais importantes (como ficará claro à frente).

Veja o resultado de alguns passos iniciais de análise, abaixo:

Conceito inicial para o sistema

O Jato (não é "Jato", é "O Jato") é um sistema que mantém um cadastro de clientes e pode enviar-lhes cartas contendo informação customizada. O Jato é o núcleo de um sistema de marketing direto: interage com usuários para configurar campanhas de marketing e trabalha com outros sistemas para realizar o envio dos documentos.

A funcionalidade desejada do Jato 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 jato deve ser capaz de:

·         Manter um cadastro de informações relacionadas a clientes e disponibilizar esta informação para o processo de geração de cartas.

·         Selecionar um grupo de clientes para os quais se deseja enviar uma carta.

·         Gerar cartas a partir de gabaritos que descrevem a informação comum, estática, das cartas e a informação dinâmica que deve ser obtida do cadastro de clientes ou de outra fonte (a data de hoje, por exemplo), e plugada na carta. Um gabarito pode ser usado para gerar cartas apropriadas para milhares de clientes.

·         Entregar as cartas através de um SistemaDeCorreio externo que pode enviar correio eletrônico ou imprimir as cartas para envio pela ECT. Dar suporte à entrega eletrônica é mais importante.

Contexto do Sistema

O Jato deve interagir com dois tipos de atores externos: usuários humanos e SistemasDeCorreio. Usuários interagirão com o Jato para examinar e alterar o cadastro de usuários, gerar cartas, enviá-las ao SistemasDeCorreio. O Jato interage com os SistemasDeCorreio para enviar cartas.

User Stories

User Story 1

  • Nome: Gerar carta
  • Prioridade: 1
  • Descrição: Um usuário seleciona um cliente para o qual deseja enviar uma carta e um gabarito que define o formato da carta. O Jato produz uma carta para cada cliente, usando a informação do gabarito para gera a carta, substituindo a informação "plugável" (chamada tag) que estiver no gabarito pela informação relacionada ao cliente. Há informação plugável não relacionada ao cliente, a data de hoje, por exemplo. O usuário recebe uma visão da expansão da carta para cada cliente para verificação.
  • Notas e Observações:
    • Para esta Story, o seguinte gabarito pode ser usado:
      Campina Grande, <<hoje>>
      Prezad<<terminacao-genero>> <<tratamento>> <<nome-do-cliente>>,
      Agradecemos seu pedido do dia <<data-ultimo-pedido>>. Acabamos de receber do Hawaii um novo lote do ingrediente especial que fornece um sabor tão sui-generis ao nosso produto e podemos lhe oferecer um preço especial de R$99,99 por caixa. Se estiver interessado, ligue para 0800-123-4567 ou clique aqui: www.ojato.com.br/<<PedidoEspecial>>/<<NumeroPedidoEspecial>>/pedido.html
      Se você nos contatar por telefone, favor mencionar o pedido especial <<NumeroPedidoEspecial>> para receber desconto adicional.
      Nós da Jato & Cia. agradecemos novamente e esperamos que curta imensamente o "novo ingrediente" com seu parceiro favorito.
    • Observe que usaremos apenas uma interface textual neste projeto. Portanto, você deve elaborar uma interface com o usuário (comandos de console) para realizar as operações.
    • O cadastro de clientes é mantido em algum arquivo de texto. Sugere-se usar o formato XML para o arquivo. Há formas simples de transformar XML em objetos Java; portanto, guardar o arquivo em XML não vai acarretar muito trabalho. Por exemplo, veja java.beans.XMLEncoder e java.beans.XMLDecoder.
    • Os gabaritos disponíveis são quaisquer arquivos presentes num diretório chamado "gabaritos".
    • Nesta User Story, as cartas devem ser produzidas na saída padrão.
    • Embora, num sistema real, faria mais sentido gerar cartas em formatos mais complexos como HTML ou pdf, neste projeto, basta usar texto simples.
    • Condições de erro devem ser tratadas (usuário não existente, gabarito não existente, tag não existente, ...)

User Story 2

  • Nome: Envio de carta via email
  • Prioridade: 2
  • Descrição: Semelhante à User Story 1, mas as cartas são enviadas via um SistemaDeCorreio. O SistemaDeCorreio usado é diferente para cada cliente e essa informação deve fazer parte do cadastro do cliente.
  • Notas e Observações:
    • Neste momento, vamos supor a existência de dois SistemasDeCorreio: uma que guarda tudo num arquivão (SistemaDeCorreioEmArquivo) e um que envia email (SistemaDeCorreioEMail).
    • User Stories futuras poderão necessitar de um novo SistemaDeCorreio.
    • Lembre que a User Story 1 deve continuar funcionando.
    • Condições de erro devem ser tratadas. (Eu não deveria precisar dizer isso, mas como você são alunos e estão aprendendo, lá vai de forma mais clara: Todas as condições de erro devem sempre ser tratadas!  Todas as condições de erro razoáveis devem ser testadas!

User Story 3

  • Nome: Manutenção de cadastro
  • Prioridade: 3
  • Descrição: As operações de manutenção do cadastro de clientes devem ser fornecidas. Essas operações são CRUD:
    • Create (novo cliente)
    • Read (recupera cadastro de um cliente existente)
    • Update (altera atributos de algum cliente)
    • Delete (remove um cliente)
  • Notas e Observações:
    • Os atributos importantes que devem ser mantidos neste momento são nome, tratamento, endereço, último pedido, e qualquer outra coisa que o Jato precise saber sobre o cliente.
    • Condições de erro devem .... (tá, não preciso dizer mais, certo?)

User Story 4

  • Nome: Seleção de clientes por critérios
  • Prioridade: 4
  • Descrição: O usuário pode selecionar os clientes que receberão uma carta através de um critério. Um critério consiste de um atributo e de uma expressão regular. Se este atributo do cliente casar com a expressão regular, então o cliente receberá a carta. Deve haver uma forma de ver a lista de clientes que satisfazem o critério e deve haver uma forma de enviar a carta. Por exemplo, podemos enviar uma carta para clientes que compraram um certo produto no último pedido, ou que gastaram mais do que R$100,00 no último pedido.
  • Notas e Observações:

User Story 5

  • Nome: Atributos dinâmicos para clientes
  • Prioridade: 5
  • Descrição: Permite que o usuário introduza (ou remova) novos atributos aos clientes, dinamicamente. Deve ser possível manter o cadastro com esses atributos (alterando o valor dos atributos) e usar esses atributos nos gabaritos. Atributos são sempre strings.
  • Notas e Observações:
    • Por exemplo, o usuário pode desejar adicionar o atributo "nome-bicho-de-estimacao" e "tratamento-bicho-de-estimacao" e fazer um gabarito tal como:

Campina Grande,
Prezad<<terminacao-genero>> <<tratamento>> <<nome-do-cliente>>,
Agradecemos seu pedido do dia <<data-ultimo-pedido>>. Acabamos de receber do Hawaii um novo lote do ingrediente especial que fornece um sabor tão sui-generis ao nosso produto e podemos lhe oferecer um preço especial de R$99,99 por caixa. Mandamos beijos para <<nome-bicho-de-estimacao>> e se <<tratamento-bicho-de-estimacao>> estiver interessado, ligue para 0800-123-4567 ou clique aqui: www.ojato.com.br/<<PedidoEspecial>>/<<NumeroPedidoEspecial>>/pedido.html
Se você nos contatar por telefone, favor mencionar o pedido especial <<NumeroPedidoEspecial>> para receber desconto adicional.
Nós da Jato & Cia. agradecemos novamente e esperamos que curta imensamente o "novo ingrediente" com seu parceiro favorito.

    • Claro que todas as outras User Stories devem continuar funcionando, incluindo a Story 4: essas novas propriedades poderão ser usadas no critério de seleção.

Glossário

O seguinte glossário ajudará a entender o domínio do problema.

  • Atributo: Uma propriedade que um cliente possui. Um atributo tem um nome e um valor. Os valores são strings. Atributos podem ser adicionados e removidos. Alguns atributos não podem ser removidos (nome, endereço, e-mail para um cliente que recebe cartas via email, etc.)
  • Cadastro: A coleção de todos os clientes. O cadastro sofre as operações de criação, acesso, alteração e remoção.
  • Carta: O resultado de substituir os tags de um gabarito com o valor correto para um cliente particular. Cartas são enviadas para clientes.
  • Cliente: Um destinatário de cartas emitidas pelo sistema Jato. Cada cliente recebe cartas através de uma SistemaDeCorreio particular.
  • Critério: Uma forma de escolher quem vai receber cartas numa campanha de marketing particular. Um critério deve especificar um atributo e este deve satisfazer a expressão regular associada ao critério.
  • Expressão Regular: Uma forma simples de definir um conjunto de valores (strings) que um atributo de um cliente deve satisfazer para que este cliente seja selecionado por um critério de seleção.
  • Gabarito: O conteúdo da carta a ser enviada, mas contendo tags que deverão ser substituídos pela informação correta, tipicamente um atributo do cliente que receberá a carta.
  • Grupo de clientes: Um grupo de clientes que receberá uma carta, selecionados usando um critério particular.
  • Tag: Informação variável dentro de um gabarito. Na carta final enviada para o cliente, o tag é substituído pela informação variável que ele representa. Há dois tipos de tags: tags de Jato (data de hoje, por exemplo) e tags de clientes (nome, endereço, ...)
  • SistemaDeCorreio: Um sistema externo capaz de enviar cartas. Pelo menos dois SistemasDeCorreio existem: SistemaDeCorreioEmArquivo e SistemaDeCorreioEMail.

Modelo Conceitual

Segue o diagrama de classe para o modelo conceitual do sistema. Cuidado! No design, o modelo de classe não será igual a este!

Os milestones

Teremos 4 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!

Milestone 1: Design e Linguagem de entrada para exercitar e testar o sistema

Você já recebeu uma análise do sistema, pelo menos nos seus aspectos mais importantes. Você agora vai pensar no design do sistema. produza e entregue seu design, apenas para as User Stories 1 a 4. O design consiste de 1) um diagrama de classes e 2) um diagrama de seqüência para a interação principal de cada User Story. Além do mais, vamos ter bastante foco em testes neste projeto. Em particular, vamos automatizar testes de aceitação. Testes de aceitação são aqueles testes que exercitam o sistema como um todo e verificam se ele está funcionando de acordo com o desejado. Para automatizar os testes de aceitação, vamos bolar uma linguagemzinha de script. Toda a interação com seu sistema se dá com essa linguagemzinha. Seu sistema deve ler os comandos na entrada padrão System.in. Desta forma, será fácil executar comandos já digitados em arquivos através do redirecionamento de entrada do shell (usando <). Isto é, podemos colocar vários comandos da linguagem dentro de um arquivo e rodar o sistema com todos os comandos fazendo:

java jato.jato <arquivo-de-script

Desta forma, podemos automatizar a execução de comandos pelo sistema. Porém, como fazer para automatizar testes. Simplesmente, fazemos com que um dos comandos da linguagemzinha possa testar o resultado (string) de um comando. Este comando de testes diz se o teste deu certo ou não na saída padrão. Desta forma você poderá expressar testes de aceitação para cada User Story na sua linguagem. Você deve bolar essa linguagem e descrevê-la completamente no seu relatório. A linguagem pode ser muito simples mas deve permitir ativar toda a lógica de negócio para realizar os User Stories mencionados acima, através de comandos textuais.

Para este milestone, você deve portanto fornecer o seguinte (considerando apenas User Stories 1 a 4):

  • Um diagrama de classe para o sistema;
  • Um diagrama de seqüência para a interação principal de cada User Story;
  • Uma descrição da linguagem de scripts usada para ativar a lógica do seu sistema;
  • Quatro arquivos contendo os testes de aceitação completos, usando sua linguagem, para cada User Story. Os arquivos devem se chamar us1.txt, us2.txt, us3.txt e us4.txt. O arquivo us1.txt contém comandos na sua linguagem que exercitam a lógica de negócio do User Story 1 e serve de teste de aceitação para este. O mesmo ocorre com os arquivos us2.txt até us4.txt.

Depois da entrega do milestone 1, o professor fornecerá os testes de aceitação que realmente deverão ser testados nos demais milestones.

Milestone 2: User Stories 1 e 2

Entregue o sistema com os US 1 e 2 funcionando, usando os testes de aceitação que o professor forneceu. Entregue o código fonte documentado. Entregue também a saída do javadoc. Adicionalmente, entregue o código fonte de todos os testes de unidade realizados. Use JUNIT para testes de unidade. Entregue também os arquivos us1.txt e us2.txt que servirão de testes de aceitação para os User Stories. Lembre que o professor vai executar os testes de unidade e os testes de aceitação. Lembre dos seguintes pontos ao entregar o resultado:

  • Entregue um único arquivo zip. O nome do arquivo zip deve ser "milestone1-joao-maria.zip" e assim por diante (identificando o milestone e o nome dos membros da equipe)
  • Ao deszipar o arquivo, tudo deve cair no lugar certo para ajudar minha tarefa de testar e verificar seu trabalho
  • Posso deszipar o 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
  • Crie um comando jato.bat (ou jato no Unix/Linux) para executar o programa.
  • Crie um comando testa.bat para testar todos os testes de aceitação
  • (o que está em negrito abaixo é novo 7/7/2004)
  • O comando "ant unit" deve executar todos os testes de unidade. Os testes de unidade devem abrir uma GUI do JUNIT e mostrar os testes executando e dando "barra verde".
  • O comando "ant testa" deve executar todos os testes de aceitação (isto é, deve chamar testa.bat)
  • Para testar seu programa, usarei os seguintes comandos:
    • ant limpa compila doc unit testa
    • jato (aqui, vou brincar com 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.4.1 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 manual do usuário (conciso mas completo) para o uso de sua ferramenta.
    • Um diagrama de classes, como modelo de design.
    • Uma lista dos patterns usados e onde foram usados.
  • O projeto será avaliado de acordo com os seguintes pesos:
    • Compilação (0% - se não compilar, não aceito o projeto)
    • Execução e qualidade dos testes de unidade (20%)
    • Execução dos testes de aceitação (30%)
    • Qualidade da documentação (10%)
    • Qualidade do design (15%)
    • Qualidade do código (15%)
    • Qualidade do relatório (10%)
  • Eis as instruções dadas a quem vai corrigir os projetos:
    • Compilação: extraia os arquivo do .zip 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 unidade: execute "ant unit". Anote o número de testes para você poder comparar com os colegas. O número de testes em si não é suficiente para dar nota, pois a qualidade do que cada teste realiza é importante. Portanto, analise a qualidade dos testes de aceitação. Testes triviais não contam. Dê uma nota entre 0 e 10 para refletir quão bem os testes de unidade testam o software.
    • Testes de aceitação: Substitua os arquivos us1.txt, etc. e os diretórios saidasok e dirgabteste com a versão que está na home page (em gab-projeto.zip). Não execute os testes de aceitação com os arquivos dos alunos mas com os arquivos que eu preparei. Execute “ant testa”. Observe se todos os testes de aceitação executam. Para a US1, 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 2, apenas us1 e us2 são testadas. No milestone 3, as user stories us1, us2, us3 e us4 devem ser testadas.
    • Relatório: leia o relatório e dê uma nota de 0 a 10 sobre a qualidade. Deve haver três 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)? Dê nota de 0 a 10.
    • Código: Examine a qualidade do código, além do design já examinado. Verifique nomes de variáveis, construções de loops, endentação, organização em pacotes, tratamento de exceções, etc. Dê nota de 0 a 10.

Milestone 3: User Stories 3 e 4

Repita para as User Stories 3 e 4.

Milestone 4: User Story 5

Agora, vamos brincar! Você vai receber o projeto de outro grupo e deverá implementar a User Story 5. Mude o mínimo necessário no programa que você recebeu para implementar a US. Entregue o programa final e os testes de aceitação no arquivo us5.txt. Você deve avaliar os seguintes pontos (incluir sua avaliação no relatório):

  • Comente as fraquezas do design que você recebeu.
  • Comente as virtudes do design que você recebeu.
  • Comente as dificuldades que você teve para implementar a User Story 5.
  • Descrever o refatoramento que você efetuou.
  • Dê uma nota de 0 a 10 para cada uma das áreas abaixo:
    • Qualidade da documentação
    • Qualidade do design
    • Qualidade dos testes de unidade e de aceitação