Projeto de Sistemas de Informação 1
Período 2005.2

Sistema de Folha de Pagamento (WePayU) Neste semestre, vocês projetarão e implementarão um sistema de informação simples para administrar os pagamentos a empregados de uma empresa. 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ó faremos 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 propósito do projeto é de construir um sistema de folha de pagamento. O sistema consiste de um banco de dados de empregados de uma empresa além dos seus dados associados tais como cartões de ponto. O sistema deve pagar cada empregado. Empregados devem receber o salário correto, no momento correto, usando o método que eles preferem. Além do mais, várias taxas e impostos são deduzidos do seu salário.

• Alguns empregados são horistas. Eles recebem um salário por hora trabalhada. Eles submetem "cartões de ponto" todo dia para informar o número de horas trabalhadas naquele dia. Se um empregado trabalhar mais do que 8 horas, deve receber 1.5 a taxa normal durante as horas extras. Eles são pagos toda sexta-feira.
• Alguns empregados recebem um salário fixo mensal. São pagos no último dia útil do mês (desconsidere feriados). Tais empregados são chamados "assalariados".
• Alguns empregados assalariados são comissionados e portanto recebem uma comissão, um percentual das vendas que realizam. Eles submetem resultados de vendas que informam a data e valor da venda. O percentual de comissão varia de empregado para empregado. Eles são pagos a cada 2 sextas-feiras; neste momento, devem receber o equivalente de 2 semanas de salário fixo mais as comissões do período.
• Empregados podem escolher o método de pagamento.
  • Podem receber um cheque pelos correios
  • Podem receber um cheque em mãos
  • Podem pedir depósito em conta bancária
• Alguns empregados pertencem ao sindicato (para simplificar, só há um possível sindicato). O sindicato cobra uma taxa mensal do empregado e essa taxa pode variar entre empregados. A taxa sindical é deduzida do salário. Além do mais, o sindicato pode ocasionalemnte cobrar taxas de serviços adicionais a um empregado. Tais taxas de serviço são submetidas pelo sindicato mensalmente e devem ser deduzidas do próximo contracheque do empregado. A identificação do empregado no sindicato não é a mesma da identificação no sistema de folha de pagamento.
• A folha de pagamento é rodada todo dia e deve pagar os empregados cujos salários vencem naquele dia. O sistema receberá a data até a qual o pagamento deve ser feito e calculará o pagamento para cada empregado desde a última vez em que este foi pago.

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. É 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.

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.

Obs.: estão listados apenas os comandos usados nos testes das User Stories 1 a 8.

<void> zeraSistema
<void> alteraEmpregado emp=<String> atributo=<String> valor1=<String>
<void> alteraEmpregado emp=<String> atributo=sindicalizado valor1=false
<void> alteraEmpregado emp=<String> atributo=sindicalizado valor=true idSindicato=<String> taxaSindical=<String>
<void> alteraEmpregado emp=<String> atributo=metodoPagamento valor1=banco banco=<String> agencia=<String> contaCorrente=<String>
<String> criarEmpregado nome=<String> endereco=<String> tipo=<String> salario=<String>
<String> criarEmpregado nome=<String> endereco=<String> tipo=comissionado salario=<String> comissao=<String>
<void> encerrarSistema
<String> getAtributoEmpregado emp=<String> atributo=<String>
<String> getEmpregadoPorNome nome=<String> indice=<int>
<String> getHorasExtrasTrabalhadas emp=<String> dataInicial=<String> dataFinal=<String>
<String> getHorasTrabalhadas emp=<String> dataInicial=<String> dataFinal=<String>
<String> getTaxasServico emp=<String> dataInicial=<String> dataFinal=<String>
<String> getVendasRealizadas emp=<String> dataInicial=<String> dataFinal=<String>
<void> lancaCartao emp=${id1} data=<String> horas=<String>
<void> lancaTaxaServico emp=<String> data=<String> valor=<String>
<void> lancaVenda emp=<String> data=<String> valor=<String>
<void> removerEmpregado emp=<String>
<void> redo
<void> rodaFolha data=<String> saida=<String>
<String> totalFolha data=<String>
<void> undo

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 8. 

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. O nome do arquivo zip deve ser "milestone1-joao-maria.zeep" e assim por diante (identificando o milestone e o nome dos membros da equipe). Use a terminação zeep e não zip para driblar o gmail que não entrega mails com attachments contendo arquivos executáveis (ele olha dentro de attachments zip). Pode mandar mail para jacques@dsc.ufcg.edu.br.
• Ao extrair do arquivo zip, 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
• 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.
• 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 (40%)
  • Qualidade da documentação (10%)
  • Qualidade do design (15%).
  • Qualidade do código (25%): Defeitos a observar no código: ausência de "data driven design" (uso de arrays de dados em vez de código), utilização de instanceof, repetição de código, uso de números mágicos, nomes de símbolos mal escolhidos, modularização (Say what you want, not how to do it), cascatas de ifs ou endentação profunda de loops/testes, consistência na codificação (padrão de codificação), má organização em pacotes, mau tratamento de exceções, etc.
  • 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 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.
  • Código: Essa é a parte mais difícil da correção. Examine a qualidade do código, além do design já examinado. Dê nota de 0 a 10. Defeitos a observar no código: ausência de "data driven design" (uso de arrays de dados em vez de código), utilização de instanceof, repetição de código, uso de números mágicos, nomes de símbolos mal escolhidos, modularização (Say what you want, not how to do it), cascatas de ifs ou endentação profunda de loops/testes, consistência na codificação (padrão de codificação), má organização em pacotes, mau tratamento de exceções, etc.

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.

• 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

Vamos brincar com threads. Seus objetivos são:

• Alterar o EasyAccept para lidar com threads (baixe o código fonte do EasyAccept  aqui. )
• Alterar o sistema para permitir uso multi-thread

executeScript newThread={true|false} scriptFile=<arquivo com script de teste>

threadPool poolsize=<numero de threads>

repeat numberOfTimes=n anyCommand ...

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

assalariado: um tipo de empregado que recebe salário fixo mensal.

cartão de ponto: quando o empregado chega no trabalho e sai do trabalho, ele "bate ponto" (ou "assina ponto") no relógio de ponto usando um cartão de ponto. O cartào registra data/hora de entrada e saída. Hoje, com tecnologias mais modernas, o cartão pode não mais existir fisicamente.

comissionado: tupo de empregado que recebe salário variável de acordo com seu desempenho (quanto ele(a) vende, por exemplo)

comissão: taxa aplicada em cima das vendas do empregado para calcular a parte variável do seu salário.

contracheque: relatório impresso indicando os detalhes de pagamento de um empregado, incluindo salário, deduções, etc.

dedução: algo retirado automaticamente do salário de um empregado.

empregado: alguém que recebe salário numa empresa. É a entidade básica tratada por um sistema de folha de pagamento.

folha de pagamento: "Rodar a folha" significa verificar quem deve receber quanto no certo dia.

hora extra: certos empregados podem receber salário maior quando trabalham além do número acertado de horas.

horista: um tipo de empregado que recebe salário proporcional ao número de horas trabalhadas. As horas trabalhadas são anotadas em "cartões de ponto".

identificação do empregado: cada empregado é identificado unicamente por uma identificação. Observe que a identificação usada pela folha de pagamento não é a mesma da identificação usada pelo sindicato.

imposto: um tipo especial de dedução resultado de uma lei fiscal; exemplos de impostos no Brasil: Imposto de Renda, INSS, ISS, ...

método de pagamento: a forma com a qual o empregado recebe seu salário (cheque pelos correios, depósito em banco, em mãos, ...)

relógio de ponto: aparelho que serve para anotar numa folha de ponto a hora de entrada e hora de saída de um empregado.

resultado venda: comprovante de uma venda realizada por um empregado.

salário: de forma geral, é o valor devido a um empregado pelo tabalho realizado. O salário antes das deduções chama-se "salário bruto"; depois das deduções, chama-se "salário líquido". Deduções podem ser impostos, taxa sindical, outras taxas de serviços, etc.

sindicato: uma associação de empregados que negocia com a empresa (salários, por exemplo) em prol do conjunto de empregados. Desta forma, os empregados conseguem negociar em conjunto e obter condições melhores de salário, de trabalho, etc. Um empregado não é obrigado a pertencer a um sindicato.

taxa de serviço: o sindicato pode prestar serviços adicionais (crechae para crianças, etc.) aos empregados e cobrar cada empregado pelos serviços que ele9a) utiliza.

taxa sindical: a taxa básica cobrada pelo sindicato de um empregado.