Modelagem de Software

Prévia do material em texto

1.INTRODUÇÃO 
Pretende-se criar um software de gestão para uma lavandaria, a aplicação deve 
permitir a recepcionista cadastrar os clientes e alocar as roupas para cada máquina 
disponíveis e agendar o dia em que o cliente pode vir buscar as suas roupas, serão 
apresentados os problemas consoante as suas especialidades. 
Uma máquina só está disponível quando não está a lavar nenhuma roupa, de igual 
modo uma passadeira só está disponível quando não está a passar nenhuma roupa, a 
recepcionista será responsável por agendar as lavagens em uma determinada data 
escolhida pelo cliente se esta data escolhida pelo cliente não estiver disponível a 
recepcionista pode sugerir uma nova data e essa data só será agendada caso o cliente 
concordar. 
Para os clientes serão armazenados: nome do cliente, números de telefone, 
morada, e para a roupa apresentada pelo cliente devem estar armazenados: quantidade, 
categoria e cor. 
Objetivo Geral 
Desenvolver um Software de gestão para a lavandaria 
Porquê ter um software de gestão? 
Atualmente os clientes da lavandaria CFs quando solicitam um serviço não são 
cadastrados e suas faturas são feitas manualmente (papel e caneta), o que torna a gestão 
muito desordenada. 
Para melhorar a eficiência no atendimento ao cliente propõe-se a implementação 
de um software de gestão que permita obter as suas faturas de forma informatizada, 
solicitar serviços. E a recepção, automatizar o processo de atendimento. 
 
 
1.2 SISTEMA DE GESTÃO DA LAVANDARIA “CFs” 
A lavandaria CFs requer um sistema de informação que garante o controle da 
lavagem de roupa suja e passando a ferro de todo o tipo de roupas, a administração de 
recepção, entrega e controle de tempo para lavagem de roupa dos clientes. 
A lavandaria estabelece uma tarifa de acordo ao serviço prestado e cuidados 
necessários para cada tipo de roupa. Cada tipo de artigo de vestuário ou quantidade de 
roupa que o cliente traz para a lavandaria, tem um código que é diferente de acordo com 
o tratamento que deveria ser dado a roupa. As roupas são classificadas para lavar através 
de tipo (cor, material, quantidade, nível de sujeira). 
O funcionário deve ter um nome, morada, telefone, sexo e cada funcionário deve 
ter um código que o identifica dos demais. Somente o administrador vai realizar o 
cadastro de funcionários e usuários, serviços, alocar funcionários a serviços e emitir 
relatórios. 
O cliente deve possuir um nome, e pelo menos um número de telefone, e um 
código que o diferencie dos outros. 
A recepcionista precisa saber os serviços disponíveis para efetuar o atendimento. 
Um funcionário pode efetuar vários ou nenhum atendimento. Um cliente solicita 
nenhum ou vários serviços. O funcionário deve estar habilitado para realizar um ou vários 
serviços. Um único serviço pode estar associado a nenhum ou vários atendimentos. 
A recepcionista será responsável por inserir, consultar, eliminar e alterar dados de 
clientes. Ele terá um código de acesso ao sistema distintivo de seu cargo, se outra pessoa 
deseja entrar no sistema, como por exemplo o administrador, deve ter seu código de 
acesso. O administrador será responsável por cadastrar os funcionário e usuários. 
LEVANTAMENTO DE REQUISITOS 
REQUISITOS FUNCIONAIS 
RF01- O sistema deve permitir o cadastro de cliente 
RF01- O sistema deve permitir efetuar atendimento 
RF01- O sistema deve permitir gerar relatório 
RF01- O sistema deve permitir gerar faturas 
RF01- O sistema deve permitir cadastrar funcionários 
RF01- O sistema deve permitir cadastrar serviços. 
RF01- O sistema deve permitir imprimir uma lista de todos serviços pertencentes a um cliente. 
REQUISITOS NÃO FUNCIONAIS 
RNF01- O sistema deve ser de fácil manutenção 
RNF02- O sistema deve ser de fácil de utilização 
RNF03- O sistema deve ter uma interface de usuário amigável e bonita 
REQUISITOS DE DOMINIOS 
RD01- Os preços variam de acordo a categoria e nível de sujeira da roupa 
RD02- O cliente tem 5 dias para pegar a roupa que ele agendou para lavar. 
RD03- Se o cliente não pegar a roupa em 5 dias, vai pagar um a multa. 
RD04- Os noivos têm desconto de 50%. 
 
 
MODELAGEM DE CASO DE USO 
ATORES E DESCRIÇÃO 
Administrador: É a pessoa que vai cadastrar funcionários, cadastrar Usuários (recepcionista) e 
alocar funcionários a serviços. 
Recepcionista: É a pessoa que cadastra cliente, faz o atendimento, consulta atendimento e gera 
faturas. 
Cliente: É a pessoa que solicita serviço. 
CASOS DE USO 
CU01- Cadastrar cliente 
CUS02- Efetuar atendimento 
CUS03- Exibir atendimento 
CUS04- Gerar relatório de atendimento 
CUS05- Gerar relatório Geral 
CUS06- Cadastrar funcionário 
CUS07- Cadastrar serviços 
CUS06- Alocar serviços a funcionário 
CUS08- Solicitar serviço 
DESCRIÇÃO DE CASO DE USO 
CUS02- Efetuar atendimento 
Sumário: A recepcionista usa o software para efetuar o atendimento solicitado pelo cliente 
Ator Primário: Recepcionista 
Ator secundário: Cliente 
Prê- Condições: Para se efetuar atendimento é necessária uma solicitação por parte do cliente. 
Fluxo Principal: 
1- A recepcionista clica em novo atendimento 
2- O software mostra uma tela com os campos vazio para a entrada dos dados do cliente 
3- É inserido os dados do cliente e da roupa 
4- O sistema apresenta duas opções: salvar e cancelar 
5- É escolhido a opção salvar 
6- O sistema um ID para cada atendimento 
7- O sistema exibe uma tela com a mensagem: “Atendimento feito com sucesso”. 
Fluxo alternativo 1 
1- Campos obrigatórios não preenchidos 
2- O sistema exibe uma mensagem de erro “Por favor preencha os campos vazios” 
3- É inserido os dados do cliente 
4- O caso de uso volta para o fluxo principal 
 
 
CUS08- Solicitar serviço 
Sumário: O cliente solicita um serviço 
Ator Primário: Cliente 
Ator secundário: Recepcionista 
Prê- Condições: O cliente só solicita um serviço se trazer roupa suja. 
Fluxo principal: 
1- O cliente traz a roupa 
2- O cliente se dirige a recepção 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Diagrama de caso de uso 
Recepcionista
CU01- Cadastrar cliente
CU02- Efetuar atendimento
CU03- Exibir atendimento
CU04- Gerar relatorio de 
atendimento
CU05- Gerar fatura
CU06- Gerar relatorio Geral
CU07- Cadastrar Funcionário
CU08- Cadastrar serviços
Administrador
Cliente
CU09- Solicitar Serviço
 
Fig. 1 Diagrama de caso uso 
 
Diagrama de entidade e relacionamento 
 
FUNCIONÁRIO
CLIENTE
SERVIÇO
ATENDIMENTO
(0:1) (1:N)
(1:1) (0:N)
(0:1)
(0:N)
(1:N)
(0:N)
Data do 
agendamento
Data de 
entrega
 
Fig. 2 Diagrama entidade e relacionamento 
Dicionário de dados 
Dados que compõe o funcionário o funcionário pode ter até dois números 
Funcionário= Código+Nome+Sexo+Morada+{Telefone}2 
Dados que compõe o cliente 
Cliente=Codigo+Nome+{Telefone}2 
Dados que compõe o Usuario 
Usuário=Senha+NomeDeUsuario 
Dados que compõe o serviço 
Serviço=Codigo+Des_servico+Preco+DataAngendamento+DataEntrega 
Dados que compõe o atendimento 
Atendimento=Data+código+Cliente 
 
 
 
 
 
Diagrama de estados 
 
 
Estado 1 Estado 2
Serviço 
Disponível 
Roupa 
Lavada
Atendimento 
(Serviço=Prestado)
Inicial Final 
Fig3 Diagrama de estados 
Processo de software 
Modelo de desenvolvimento em cascata 
Análise e 
levantamento de 
requisitos
Projecto
Implementação e teste 
de software
Testes
Entrega e 
inplantação
 
Fig4 Modelo de desenvolvimento em cascata 
A estrutura linear da abordagem em cascata e a ausência da revisão a tornam 
relativamente fácil de administrar. O administrador do projeto pode determinar prazos 
finais e monitorar o progresso na direção destes prazos. Ao mesmo tempo este modelo é 
muito inflexível. Se, por exemplo, as necessidades de os usuários mudarem durante o 
projeto, não existe nenhum mecanismo formal para ajustar o processo de 
desenvolvimento. O uso deste modelo significa, também, que nenhum componente dosistema será entregue até a proximidade final do projeto. Frequentemente esta demora na 
entrega conduz a tensões entre usuários e desenvolvedores, especialmente se os prazos 
finais são ultrapassados. Para o desenvolvimento do nosso software escolhemos o modelo 
em cascata porque ele permite a inclusão do usuário. 
 
 Projecto de Software 
Estrutura analítica de projecto 
 
 
 
 
Tabela 1- Estrutura analítica do projecto 
Diagrama Relacional 
Funcionário
Cliente
Serviço
Atendimento
Serviço_Prestado
Usuário
Codigo_FuncionárioPK
Nome_Funcionário
Telefone 1
Telefone 2
Morada
Sexo
Codigo_ClientePK
Nome_Cliente
Telefone 
Morada
Sexo
Codigo_ServiçoPK
Nome
Descrição
Preço
Senha
Codigo_AtendimentoPK
Data
Endereço
Codigo_ServiçoFK
CodigoPK
Hora_inicio
Hora_Final
Codigo_AtendimentoFK
Codigo_ClienteFK
Codigo_FuncionárioFK
Nome_Usuario
Função
Codigo_UsuárioPK
Nome_Usuário
Senha
Codigo_FuncionárioFK
Fig## Diagrama Relacional 
Modulo/Funcoes Análise e 
especificação 
de requisitos 
Projecto Implementacao Testes 
Modulo 1 Levantamento 
de requisitos 
 - 
Modulo 2 Análise de 
requisitos 
Projecto de 
dados 
 - 
Modulo 3 Análise de 
requisitos 
Projecto de 
interface com 
o usuario 
 - 
Modulo 4 Análise de 
requisitos 
Projecto 
modular de 
programas 
 - 
Modulo 5 Implementacao 
do Software 
- 
Atividades do Processo 
Função Itens de dados 
referenciados 
ALI Complexidade