Trabalho final da disciplina Análise OO e Projeto Arquitetural

Esta é uma pré-visualização de arquivo. Entre para ver o arquivo original

Trabalho final da disciplina Análise OO 
e Projeto Arquitetural 
 
A empresa FAIXAS SA, confecciona faixas de anúncios ou outra finalidade por 
encomenda. Como os pedidos vem crescendo, Seu Pereira, proprietário da empresa 
encomendou um sistema que controle suas atividades, que basicamente 
compreendem: 
 Controle e acompanhamento dos pedidos 
 Cadastramento de seus clientes 
 
O Sistema atual 
 
O cliente, geralmente indicado por um amigo satisfeito com os serviços, faz seu 
pedido; Seu Pereira (diretor) ou a atendente fazem o atendimento e registram o 
pedido no caderno de pedidos: 
 
 Cliente: nome, CPF, endereço completo (Rua, número, complemento, 
bairro, cidade, UF e CEP, tel_fixo, Tel_cel, e-mail_corporativo e e-mail 
pessoal. 
 Pedido: Tamanha da faixa (altura e largura), texto a ser escrito na faixa, cor 
da faixa (amarela, preta ou branca), cor do texto (Branco, Preto, Azul ou 
vermelho), Data de Previsão de entrega, Valor do Serviço e Valor do sinal 
(50% do valor total do serviço). 
 
O valor do serviço (confecção da faixa) é calculado com base nas seguintes 
fórmulas: 
 
1. Valor da faixa = Custo_Material + Custo_desenho + % Lucro 
2. Custo_Material = área da faixa x R$ 30,00 
3. Custo_Desenho = número de letras do texto * 0,95 
4. Custo_Total = Custo_Material + Custo_Desenho 
5. % de Lucro = 35 % x (Custo_Total) 
 
 
O prazo de entrega deve ser calculado levando-se em consideração a produção 
diária de faixas, que não deve ultrapassar de 10 (dez). Considere 5 dias úteis por 
semana, para fins do cálculo da data de entrega. O prazo deve começar a ser 
contabilizado, no dia seguinte à confirmação do pagamento do sinal. Cada Pedido 
pode contemplar mais de 1 faixa e o sistema deve registar dados de cada uma. O 
sistema deve calcular o prazo de entrega e o valor do serviço. Caso o pedido tenha 
mais que 10 faixas, a data de entrega deve ser quando todas estiverem prontas. 
 
Para a cada encomenda (pedido) deve ser emitido um recibo, em 2 vias, 
contendo os dados o pedido e pagamento (valor do sinal e valor a pagar na entrega). 
O sistema deve controlar o pagamento do sinal, quando o serviço é iniciado e a 
data de entrega calculada. Apenas a diretoria deve ter acesso a essa funcionalidade. 
O sistema deve controlar o pagamento da parcela a ser paga na entrega 
O pagamento do sinal deve ser feito por depósito bancário e o pagamento do 
saldo deve ser pago contra entrega, em dinheiro, cheque ou cartão de débito. 
O produto somente é entregue mediante o pagamento do saldo. A entrega deve 
ser controlada pelo sistema. 
O sistema deve prover uma consulta (disponível apenas a diretoria), de cada 
pedido feito no período, informando: data do pedido, data de entrega, Valor Serviço, 
Valor Sinal, Sinal Pago (S/N), Serviço Finalizado (S/N), Serviço Pago (S/N) e Status 
Pedido. (S/N) = Sim ou Não. 
O Pedido, ao longo do seu ciclo de vida, pode ter vários estados e o sistema deve 
controlar os eventos que geram mudança de estado. 
1. Ao ser inserido, o status é EM ESPERA 
2. Assim que o sinal for pago, o status passa a ser EM PRODUÇÃO 
3. Ao ser finalizado o status passa a ser PRONTO 
4. Ao ser entregue o status passa a ser ENTREGUE. Para ser considerado 
ENTREGUE o pedido tem que ter o saldo de pagamento confirmado. 
O sistema deve emitir um informe a todo cliente que não faz pedido há mais de 
12 meses (com base na data corrente). 
O sistema deve exibir um relatório , mostrando, o faturamento nos últimos 12 
meses. 
Pedido do trabalho 
 
1. Diagrama de casos de uso, considerando o escopo definido para o sistema. 
2. Especificação textual (cenário principal e alternativos) das funcionalidades de 
Registrar o Pedido e Entregar o Pedido. 
3. Diagrama Conceitual de Classes 
4. Diagrama de sequência do Cenário Principal das 2 funcionalidades que 
descreveu textualmente o caso e uso (vide item 2, acima) 
5. Diagrama de classes de projeto 
Considerações relevantes. 
1. Restrinja-se ao escopo acima descrito. Não crie classes desnecessárias ao que 
está descrito (isso será considerado, pois a análise deve-se restringir ao 
contexto em estudo). Tanto no diagrama conceitual, como no diagrama de 
classes de projeto 
2. Faça a descrição textual de casos de uso, completa, mostrando o passo a 
passo (enumerado) da interação ator-caso de uso. 
3. Para o diagrama conceitual de classes, considere os relatórios dentro da 
classe de negócio que melhor se adeque. Já para o diagrama de classes de 
projeto, se desejado, pode considerar classes que emitam relatórios. 
4. O diagrama de sequência deve ser o visto em aula, contemplando todas as 
classes envolvidas na interação do cenário de uso. 
5. O trabalho deve ser entregue em DOC ou PDF, com as imagens dos 
diagramas clara e legível. Não entregue, sob nenhuma hipótese, 
trabalho em ZIP, ARJ ou qualquer outro arquivo compactado