Modelagem de Sistemas

Prévia do material em texto

- -1
MODELAGEM DE SISTEMAS
MODELOS BÁSICOS DE ANÁLISE
- -2
Olá!
Bom dia!
Apresentaremos, nesta aula, técnicas de modelagem dos três principais diagramas mais usados na fase de
Análise de Sistemas e a relação entre eles: diagrama e especificações de casos de uso, diagrama de classes e
diagrama de interação.
Usaremos um pequeno estudo de caso, mostrando o passo a passo para a construção desses modelos.
Bons estudos!
Objetivos
1. Entender a forma de aplicar a linguagem UML, com base em um estudo de caso;
2. Identificar a construção e integração entre os diagramas de casos de uso, classes e interação (sequência), bem
como as especificações textuais dos casos de uso;
3. Aplicar a relação entre os diagramas e a necessidade de mantê-los atualizados durante o desenvolvimento do
software.
Minimundo do Estudo de Caso
Iniciaremos nossa aula com um Estudo de Caso. Observe o minimundo descrito, a seguir.
A empresa fictícia Faixa Amarela Ltda. confecciona faixas de anúncios por encomenda. Como os pedidos vêm
crescendo, Seu Pereira, proprietário da gráfica de faixas, encomendou um sistema que controle suas atividades,
que basicamente compreendem:
Controle e acompanhamento dos pedidos;
Cadastramento de clientes.
O cliente, geralmente indicado por um amigo satisfeito com os serviços da gráfica, faz seu pedido; Seu Pereira (o
diretor) ou a atendente faz o atendimento e registra no caderno de pedidos:
• Cliente: nome, cpf, endereço completo, tel_fixo, Tel_cel;
• Pedido: data do pedido, tamanho da faixa (altura e largura), texto a ser escrito, cor (amarela, preta ou 
branca), cor do texto (branco, preto, azul ou vermelho), previsão de entrega, valor do serviço e do sinal 
(50% do valor total do serviço).
No levantamento de requisitos foi decidido que o sistema deve possuir as seguintes funcionalidades:
O valor do serviço é calculado com base na seguinte fórmula:
•
•
- -3
Valor
Valor da faixa = Custo_Material + Custo_desenho + % Lucro
Custo_Material = área x 20,00
Custo_Desenho = número de letras * 0,70
% de Lucro = 20 % (Custo_Material + Custo_desenho)
Prazo
O prazo de entrega deve ser calculado levando-se em consideração a produção diária de
faixas, que não deve ultrapassar oito. Considere cinco dias úteis por semana, para fins do
cálculo da data de entrega.
O prazo deve começar a ser contabilizado após a confirmação do pagamento do sinal. O
sistema deve calcular o prazo de entrega e o valor do serviço.
Recibo
Para cada encomenda, deve ser emitido um recibo, em duas vias, contendo os dados do
pedido e pagamento (valor do sinal e valor a pagar na entrega).
Controle de
pagamento
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.
Consulta
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 do serviço, valor do sinal,
sinal pago (S/N), serviço finalizado (S/N), serviço pago (S/N) e status do pedido (S/N).
Mudança de
estados
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. Vejamos:
Ao ser inserido, o status é “Em espera”;
Assim que o sinal for pago, o status passa a ser “Pronto para produção”;
Quando o responsável técnico da fábrica inicia a produção da faixa, o status passa a ser
“Em produção”;
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.
Informe o
cliente
O sistema deve emitir um informe a todo cliente que não faz pedidos há mais de seis meses
(com base na data corrente).
Unidades
por período
Recentemente, foi feita uma modificação no sistema de pedidos, e agora em um mesmo
pedido pode ser encomendada mais de uma faixa, até cinco no máximo (mas esta regra
pode alterar a qualquer momento).
Solução do Estudo de Caso
Seguiremos o seguinte procedimento para a modelagem desse sistema com base em UML:
I. Diagramação da 1ª versão do diagrama de casos de uso;
Identificação das principais funcionalidades do sistema;
II. Especificação textual de casos de uso de relevância;
III. Refinamento do diagrama de casos de uso;
Identificação de includes ou extends que otimizem a solução;
IV. Identificação das classes do negócio;
V. Diagrama conceitual de classes;
VI. Diagrama de sequência dos casos de uso de relevância.
Veremos cada passo, a seguir.
1ª versão do diagrama de casos de uso
Observe, ao lado, uma primeira versão do diagrama de casos de uso, no qual figuram as grandes funcionalidades
do sistema:
- -5
Especificações de casos de uso
A seguir, temos uma breve descrição da finalidade de cada caso de uso modelado na 1ª versão do diagrama de
sequência.
Versão refinada do diagrama de casos de uso
- -6
Uma das formas de identificarmos otimizações de casos de uso, com base em includes, é através da observação
de repetições de trechos nas descrições de casos de uso.
Observe que, nos casos de uso Confirmar Recebimento do Sinal, Registrar Início da Produção, Registrar Fim da
Produção e Registrar Entrega do Pedido, temos os dois trechos a seguir repetidos: o primeiro no cenário
principal e todo o cenário alternativo.
Cenário principal:
1. Usuário informa ID do pedido;
2. Sistema localiza pedido com ID do pedido;
3. Sistema exibe dados do pedido.
Cenários alternativos:
2. a. Pedido não localizado;
1. Sistema emite mensagem “Inconsistência de dados; pedido não localizado”;
2. Sistema retorna ao passo 1 do cenário principal.
A otimização que pode ser feita seria a inclusão do caso de uso «Pesquisar Pedido» é relacioná-lo, através do
relacionamento «include», aos casos de uso anteriormente citados.
As especificações dos casos de uso também precisam ser modificadas para refletir as alterações representadas
no diagrama.
Observe que, no local das três linhas que havia anteriormente na especificação do caso de uso “Confirmar
Recebimento do Sinal”, passamos a ter uma única linha com a inclusão do novo caso de uso («Include» Pesquisar
Pedido), que também precisa ser especificado.
E o cenário alternativo de “Confirmar Recebimento de Sinal” passa a ser o cenário alternativo do «include»
Pesquisar Pedido.
- -7
Cenário principal:
1. «Include» Pesquisar Pedido;
2. Usuário informa data e valor de pagamento do sinal;
3. Sistema aponta “Pronto para produção” para status do pedido;
4. Sistema calcula data de entrega do pedido;
5. Sistema altera dados do pedido.
Caso de uso Include: Pesquisar Pedido
Cenário principal:
1. Usuário informa ID do pedido;
2. Sistema localiza pedido com ID do pedido;
3. Sistema exibe dados do pedido.
Cenário alternativo:
2. a. Pedido não localizado;
1. Sistema emite mensagem “Inconsistência de dados; pedido não localizado”;
2. Sistema retorna ao passo 1 do cenário principal.
Fique ligado
Cabe ressaltar que as mesmas alterações realizadas nas especificações do caso de uso
“Confirmar Recebimento do Sinal” devem ser realizadas nos casos de uso “Registrar Início da
Produção”, “Registrar Fim da Produção” e “Registrar Entrega do Pedido”.
- -8
Diagrama Conceitual de Classes
O diagrama conceitual de classes pode ser extraído dos casos de uso. De uma forma simplificada, a extração
ocorre:
• Casos de uso podem ser classes;
• Casos de uso podem ser métodos.
Analisando os casos de uso, temos:
Assim, temos:
•
•
- -9
Diagrama de Sequência
Agora passemos aos diagramas de interação, especificamente o diagrama de sequência,que nos dará maior
clareza dos métodos das classes.
Vamos elaborar o diagrama de sequência dos casos de uso: Registrar Pedido, Consultar pedidos do período e
Consultar Clientes sem Pedido, posto que os demais são muito diretos e não modificarão nem a alocação de
atributos nem a de métodos já alocados, conforme a imagem do diagrama anterior.
Caso de uso: Registrar Pedido - Cenário: Principal
Este diagrama de sequência cria um conjunto de métodos, nas diversas classes envolvidas na interação.
Conforme regra já explicada, toda seta que chega em uma classe é um método dessa classe.
- -10
Saiba mais
Os novos métodos descobertos são
- -11
Caso de uso: Consultar Pedidos no Período - Cenário: Principal
Saiba mas
Os novos métodos descobertos são:
Caso de uso: Consultar Clientes em Pedido - Cenário: Principal
- -12
Saiba mais
Os novos métodos descobertos são:
Os demais casos de uso do sistema que seriam Registrar Entrega do Pedido, Confirmar Recebimento de Sinal,
Registrar Inicio de Produção e Registrar Fim Produção do Pedido, além de atualizarem dados de atributos,
alteram o status do Pedido.
Assim, teremos um método na classe PEDIDO, de nome Alterar Status Pedido, cujo argumento será o status que
deverá ser alterado → Alterar Status Pedido (Status).
O Modelo Conceitual
Após toda a análise das interações, o modelo conceitual de classes ficará conforme o exemplo.
Observe que tal modelo ainda não dispõe de visibilidade de atributos e métodos, bem como parâmetros e tipos
de dados de retorno dos métodos, propositalmente, pois em geral esses dados são inseridos no modelo de
classes de projeto, que discutiremos na continuidade, que se dará na aula 10.
- -13
O que vem na próxima aula
•Diagrama de estados.
CONCLUSÃO
Nesta aula, você:
• • Aplicou os estudos de caso, nos quais exercitou a modelagem do diagrama de casos de uso, das 
especificações de casos de uso, do diagrama conceitual de classes e do diagrama de sequência.
Saiba mais
Para saber mais sobre os tópicos estudados nesta aula, pesquise na internet sites, vídeos e
artigos relacionados ao conteúdo visto. Se ainda tiver alguma dúvida, fale com seu professor
online, utilizando os recursos disponíveis no ambiente de aprendizagem.
•
- -14
Referências
BOOCH, G.; JACOBSON, I.; RUMBAUGH, J. — Guia do Usuário. 2. ed. Rio de Janeiro: Elsevier, 2005. cap. 1 e 2.UML 
FOWLER, Martin. — um breve guia para a linguagem padrão. 3. ed. Porto Alegre: Artmed, 2005.UML essencial 
cap. 1
LARMAN, Craig. uma introdução à análise e ao projeto orientados a objetos e aoUtilizando UML e padrões? 
processo unificado. 3. ed. Porto Alegre: Artmed, 2007. cap. 2.
	Olá!
	
	O que vem na próxima aula
	CONCLUSÃO
	Referências