6.b Eng_Soft I - Estudo de caso - Casos de Uso

Prévia do material em texto

Desenvolvendo Sistemas Orientados a Objetos 
 
 
 
 1 
DESENVOLVENDO O SISTEMA 
Declaração da Necessidade 
“O primeiro passo do processo de análise de sistema 
envolve a identificação da necessidade” [Pressman-95]. 
Normalmente o analista reúne-se com o usuário final e 
juntos definem as metas do sistema assim como as 
principais funcionalidades a serem contempladas. 
A definição inicial das necessidades norteará o 
desenvolvimento do sistema, e posteriormente as 
informações contidas nesta declaração serão refinadas para 
oferecer mais detalhes para a especificação dos requisitos. 
Não é preciso que esta definição seja exata e completa, 
apenas deve expressar claramente o problema a ser 
resolvido. 
As necessidades inicialmente identificadas para o 
Sistema Comercial compreendem as atividades 
relacionadas com compras e vendas realizadas em uma loja. 
Para tanto, deve compreender: 
♦ registro das vendas de produtos; 
♦ controle de vendas a prazo; 
♦ emissão de notas fiscais; 
♦ cálculo das comissões dos vendedores; 
♦ fornecimento de informações sobre o estoque para 
a realização das compras; 
♦ acompanhamento dos pagamentos relativos às 
compras; 
♦ atualização do estoque. 
Desenvolvendo Sistemas Orientados a Objetos 
 
 
 
 2 
São usuários diretos do sistema o setor de vendas, o 
setor de compras, o setor financeiro, o setor de estoque e o 
gerente da loja. 
Especificação de Requisitos Funcionais 
A análise de requisitos consiste na definição clara 
dos objetivos a serem alcançados, e culmina com a produção 
de um documento denominado Especificação de Requisitos. 
Como definido em [Davis-96], requisito é uma capacidade 
ou característica necessária para que determinado usuário 
solucione um problema ou alcance um objetivo. 
Esta seção trata dos requisitos funcionais, sendo que 
os demais tipos de requisitos (desempenho, confiabilidade, 
segurança, etc.) são também importantes, porém não serão 
discutidos neste trabalho. 
A especificação de requisitos funcionais é feita 
através de casos de uso (use cases), conforme definidos em 
[UML-97]. Um conjunto de casos de uso é importante para 
se compreender o que o usuário quer. Um caso de uso 
descreve uma funcionalidade a ser oferecida pelo sistema, 
ou seja, um serviço prestado ao usuário. 
Casos de Uso 
A ideia para a identificação dos casos de uso é 
analisar o negócio sob o ponto de vista dos objetivos do 
usuário. Não se deve buscar funções do negócio ou 
simplesmente tratar os casos de uso como funções do 
sistema. 
Desenvolvendo Sistemas Orientados a Objetos 
 
 
 
 3 
No Sistema Comercial, a determinação dos casos 
de uso foi feita a partir da elaboração de roteiros que 
descrevem os principais eventos de negócio. Cada roteiro 
foi analisado em busca de tarefas que o sistema poderia dar 
suporte, gerando assim os casos de uso. 
A denominação utilizada para os casos de uso é 
iniciada com um verbo no infinitivo que expressa a tarefa do 
usuário que o sistema irá apoiar. Ex.: Autorizar Crédito - este 
caso de uso apoiará a tomada de decisão do funcionário do 
setor financeiro para que ele cumpra sua tarefa de autorizar 
crédito, fornecendo informações sobre a situação do cliente 
e, também, registrando a autorização. 
 
 
 
 
 
 
 
 
Desenvolvendo Sistemas Orientados a Objetos 
 
 
 
 4 
Os quadros a seguir mostram o roteiro de evento 
para venda à vista e os casos de uso identificados: 
Roteiro: Venda à Vista 
1. Cliente entra na loja e solicita produto. 
2. Vendedor informa a existência do produto na loja. 
3. Cliente solicita informações sobre produto à venda 
(ex.: cor, tamanho, fabricante, preço,...). 
4. Vendedor mostra todas as opções disponíveis. 
5. Cliente informa o(s) produto(s) desejado(s). 
6. Vendedor registra venda. 
 
7. Caixa informa valor a pagar para o cliente. 
8. Cliente efetua o pagamento. 
 
9. Caixa registra o pagamento e fornece a nota fiscal. 
10.Almoxarife realiza a baixa no estoque. 
11.Cliente leva o produto com a nota fiscal. 
12.Ao final do mês o funcionário do Setor Financeiro 
calcula as comissões dos vendedores sobre as 
vendas à vista. 
 
 
Desenvolvendo Sistemas Orientados a Objetos 
 
 
 
 5 
 
Caso de Uso Passos do Roteiro 
Pesquisar Produto 2 – 3 – 4 
Registrar Venda 5 – 6 – 10 * 
Registrar Pagamento 7 – 8 – 9 
Calcular Comissão de Vendedor 12 
 
* A baixa no estoque será automática após 
a confirmação da venda. 
 
Os quadros a seguir mostram o roteiro de evento 
para venda a prazo e os casos de uso identificados: 
Roteiro: Venda a Prazo 
1. Cliente informa o(s) produto(s) desejado(s). 
 
2. Vendedor registra venda. 
 
3. Cliente escolhe plano de pagamento (quantidade 
de prestações). 
 
4. Vendedor informa o valor das prestações. 
 
5. Funcionário do Setor Financeiro verifica se cliente 
está com situação financeira regular em relação a 
empresa. 
 
6. Funcionário do Setor Financeiro autoriza o crédito 
e emite o carnê de pagamento. 
 
Desenvolvendo Sistemas Orientados a Objetos 
 
 
 
 6 
 
7. Caixa informa valor a pagar para o cliente. 
 
8. Cliente paga a primeira prestação no guichê do 
caixa. 
 
9. Caixa registra o pagamento e fornece a nota fiscal. 
 
10.Almoxarife realiza a baixa no estoque. 
 
11.Cliente leva o produto com a nota fiscal. 
 
12.Ao final do mês o funcionário do Setor Financeiro 
calcula as comissões dos vendedores sobre as 
prestações quitadas. 
 
 
Caso de Uso Passos do Roteiro 
Registrar Venda 2 – 10 
Definir Prestações 3 – 4 
Autorizar Crédito 5 – 6 
Registrar Pagamento 7 – 8 – 9 
Calcular Comissão de Vendedor 12 
 
 
 
 
Desenvolvendo Sistemas Orientados a Objetos 
 
 
 
 7 
Os quadros a seguir mostram o roteiro de evento 
para pagamento e os casos de uso identificados: 
 
Roteiro: Pagamento 
1. Cliente entrega boleto da prestação para o caixa. 
 
2. Caixa verifica vencimento e calcula valor a pagar 
(multa, juros, desconto). 
 
3. Cliente efetua pagamento da prestação. 
 
4. Caixa autentica valor pago no boleto. 
 
5. Cliente recebe boleto com registro de pagamento. 
 
6. Funcionário do Setor Financeiro atualiza situação 
do cliente. 
 
Caso de Uso Passos do Roteiro 
Calcular Valor da Prestação 2 
Registrar Pagamento 3 – 4 – 6 * 
 
* A atualização da situação do cliente 
será automática após o registro do 
pagamento. 
 
 
 
Desenvolvendo Sistemas Orientados a Objetos 
 
 
 
 8 
Os quadros a seguir mostram o roteiro de evento 
para acompanhamento dos vencimentos e os casos de uso 
identificados: 
Roteiro: Acompanhamento dos Vencimentos 
1. Funcionário do Setor Financeiro verifica prestações 
em atraso. 
 
2. Registra clientes com situação irregular, ou seja, 
com prestações em atraso há mais de 30 dias. 
 
3. Prepara relação de clientes com prestações em 
atraso há mais de 60 dias para cobrança bancária. 
 
Caso de Uso Passos do Roteiro 
Acompanhar Vencimento de 
Prestações 
1 – 2 – 3 
 
 
Os quadros a seguir mostram o roteiro de evento 
para negociação de dívida e os casos de uso identificados: 
 
Roteiro: Negociação de Dívida 
1. Cliente negocia a dívida com a gerência. 
 
2. Gerente verifica situação do cliente. 
 
3. Gerente autoriza desconto na prestação. 
 
4. Cliente paga prestação com o desconto concedido 
no guichê do caixa. 
Desenvolvendo Sistemas Orientados a Objetos 
 
 
 
 9 
 
Caso de Uso Passos do Roteiro 
Consultar Situação do Cliente 2 
Determinar Desconto em 
Prestação 
3 – 4 
 
Os quadros a seguir mostram o roteiro de evento 
para compra de produtos e oscasos de uso identificados: 
 
Roteiro: Compra de Produtos 
1. Almoxarife verifica produtos abaixo do estoque 
mínimo. 
 
2. Determina quantidade necessária para reposição 
do estoque, verificando consumo médio destes 
produtos. 
 
3. Funcionário do Setor de Compras elabora pedido 
de compra para determinado fornecedor, indicando 
a quantidade dos produtos desejados. 
 
4. Fornecedor entrega os produtos solicitados. 
 
5. Almoxarife recebe produtos e confere com o pedido 
de compra. 
 
6. Comunica recebimento ao Setor Financeiro. 
 
7. Atualiza estoque dos produtos recebidos. 
Desenvolvendo Sistemas Orientados a Objetos 
 
 
 
 10 
 
8. Funcionário do Setor Financeiro recebe duplicata 
do fornecedor e programa o pagamento. 
 
9. Funcionário do Setor de Compras verifica 
periodicamente a situação dos pedidos de compra 
e entra em contato com os fornecedores cujas 
entregas estão atrasadas. 
 
Caso de Uso Passos do Roteiro 
Acompanhar Estoque 1 – 2 
Elaborar Pedido de Compra 3 
Registrar Recebimento de 
Produtos 
5 – 6 – 7 
Agendar Pagamento de Duplicata 8 
Acompanhar Pedido de Compra 9 
 
Os quadros a seguir mostram o roteiro de evento 
para pagamento de duplicatas e os casos de uso 
identificados: 
 
Roteiro: Pagamento de Duplicatas 
1. Funcionário do Setor Financeiro verifica 
vencimento de duplicatas. 
 
2. Providencia pagamento de duplicatas a vencer. 
 
 
Desenvolvendo Sistemas Orientados a Objetos 
 
 
 
 11 
Caso de Uso Passos do Roteiro 
Acompanhar Duplicatas a Pagar 1 
Registrar Pagamento de 
Duplicata 
2 
 
Modelo de Casos de Uso 
O Modelo de Casos de Uso estabelece os requisitos 
funcionais definindo o comportamento esperado para o 
sistema sem revelar sua estrutura interna. Cada caso de uso 
representa uma série de ações que os usuários podem 
executar interagindo com o sistema, a fim de 
desempenharem determinada tarefa. Os casos de uso são 
agrupados em diagramas para serem apresentados 
graficamente. Os diagramas de casos de uso, juntamente 
com suas definições, compõem o Modelo como um todo. 
Os roteiros de eventos não fazem parte da 
especificação dos requisitos funcionais, sendo apenas um 
meio para se identificar os casos de uso. Portanto não 
precisam ser mantidos após a elaboração do Modelo de 
Casos de Uso. 
A construção dos diagramas ocorreu à medida que 
os casos de uso foram surgindo, juntamente com a 
identificação dos atores - usuários que interagem 
diretamente com cada caso de uso - e dos relacionamentos. 
Durante a construção dos diagramas, os casos de uso 
foram organizados em subsistemas de negócio, de acordo 
com a afinidade entre eles. Assim, foram estabelecidos dois 
subsistemas: Subsistema Vendas e Subsistema Compras. 
Desenvolvendo Sistemas Orientados a Objetos 
 
 
 
 12 
 
 
Figura 1: Subsistemas de negócio 
Sistema Comercial
Subsistema
Compras
Subsistema
Vendas
 
 
 
 
 
 
 
 
 
 
Desenvolvendo Sistemas Orientados a Objetos 
 
 
 
 13 
A Figura apresenta os casos de uso para o 
Subsistema Vendas, cujas definições estão listadas a seguir. 
Figura 2: Diagrama de casos de uso para o Subsistema 
Vendas. 
 
 
♦ Acompanhar Vencimento de Prestações – verificar 
prestações em atraso há mais de 30 dias, 
atribuindo situação irregular ao cliente. 
1903Emitir relação de clientes para cobrança 
bancária (com prestações em atraso há mais de 60 
dias). 
 
♦ Autorizar Crédito – verificar as condições de venda 
a prazo e consultar a situação do cliente. Registrar 
a liberação do crédito. 
Subsistema Vendas
Consultar
Situação do
Cliente
Acomp.
Vencimento
Prestações
Determinar
 
Desconto
Prestação
Calcular
Comissão de
Vendedor
<<actor>>
<Gerente>
<<actor>>
<Funcionário Setor Financeiro>
<<actor>>
<Caixa>
<<actor>>
<Vendedor>
Calcular Valor
da Prestação
Autorizar
Crédito
Registrar
Pagamento
Definir
Prestações
Registrar
Venda
Pesquisar
Produto
<<include>><<include>>
<<extends>>
<<extends>>
Desenvolvendo Sistemas Orientados a Objetos 
 
 
 
 14 
 
♦ Calcular Comissão de Vendedor – verificar as vendas 
realizadas por cada vendedor no mês, calculando a 
comissão sobre as vendas a vista. Verificar 
prestações quitadas no mês, calculando comissão 
para os vendedores. 
 
♦ Calcular Valor da Prestação – verificar a data de 
vencimento da prestação e calcular, quando for o 
caso, multa e juros devidos. Quando existir, 
aplicar o desconto determinado pelo gerente. 
Calcular o valor final a pagar. 
 
♦ Consultar Situação do Cliente – informar as vendas 
realizadas para determinado cliente, indicando a 
situação das prestações quando for venda a prazo. 
Informar se cliente está em situação irregular. 
 
♦ Definir Prestações – registrar o número de 
prestações que o cliente deseja, calcular e 
informar o valor das prestações. 
 
♦ Determinar Desconto em Prestação – consultar 
situação do cliente e, caso aprovado, registrar o 
desconto concedido. 
 
♦ Pesquisar Produto – permite ao vendedor a busca de 
informações sobre os produtos que estão a venda, 
como cor, tamanho, fabricante, preço, etc. 
 
 
 
Desenvolvendo Sistemas Orientados a Objetos 
 
 
 
 15 
♦ Registrar Pagamento – informar o valor da venda ao 
caixa e registrar o valor pago pelo cliente. Emitir a 
nota fiscal. No caso de venda a prazo, informar o 
valor da prestação a pagar. No caso de quitação de 
prestação atrasada, atualizar a situação do cliente. 
 
♦ Registrar Venda – cadastrar a venda realizada, 
informando produtos vendidos e dados do cliente. 
Registra também o vendedor que efetuou a venda. 
Ao confirmar a venda, realizar a baixa no estoque. 
Caso uma venda seja cancelada, deverá ser 
cancelada a baixa no estoque. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Desenvolvendo Sistemas Orientados a Objetos 
 
 
 
 16 
A Figura apresenta os casos de uso para o 
Subsistema Compras, cujas definições estão listadas a 
seguir. 
Figura 3: Diagrama de casos de uso para o Subsistema 
Compras 
Subsistema Compras
Agendar
Pagamento de
Duplicata
Registrar
Pagamento
Duplicata
Elaborar
Pedido de
Compra
Registrar
Recebimento
Produtos
Acompanhar
Pedido de
Compra
<<actor>>
<Almoxarife>
<<actor>>
<Funcionário Setor Financeiro>
<<actor>>
<Funcionário Setor de Compras>
Acompanhar
Duplicatas a
Pagar
Acompanhar
Estoque
 
 
 
♦ Acompanhar Duplicatas a Pagar – verificar 
duplicatas com vencimento próximo, e informar 
valor devido. 
 
♦ Acompanhar Estoque – verificar produtos com 
estoque abaixo do mínimo, calcular o consumo 
médio e determinar a quantidade necessária para 
reposição. 
 
Desenvolvendo Sistemas Orientados a Objetos 
 
 
 
 17 
♦ Acompanhar Pedido de Compra – verificar os 
pedidos de compra ainda não atendidos, e 
informar dados para contato com o fornecedor. 
 
♦ Agendar Pagamento de Duplicata – cadastrar 
duplicata, indicando a data de vencimento e qual a 
compra correspondente. 
 
♦ Elaborar Pedido de Compra – informar a lista de 
produtos, indicando os que estão marcados para 
reposição. Escolher os produtos a serem 
adquiridos, registrando a quantidade e o 
fornecedor. Emitir o pedido de compra para cada 
fornecedor. 
 
♦ Registrar Pagamento de Duplicata – após a quitação 
de duplicata, registrar a data de pagamento. 
 
♦ Registrar Recebimento de Produtos – verificar 
determinado pedido de compra, registrar o 
recebimento e atualizar o estoque. 
 
Para a elaboração do modelo, foram necessárias 
várias iteraçõesde conferência entre os roteiros de eventos e 
os casos de uso. Em uma primeira análise dos roteiros, 
foram determinados alguns casos de uso, que por sua vez 
geraram dúvidas sobre os roteiros. Assim, os roteiros foram 
revisados, acrescentando-se passos que faltavam. Estes 
novos passos acabavam por determinar novos casos de uso 
possíveis. O processo continuou até torná-los completos e 
coerentes entre si.