2. 2
Palestra
Prof. Marcos Danilo Chiodi Martins
Oferecimento: Curso de Gestão da TI
Introdução a UML e Casos de
Uso – Parte 2
3. 3
OBJETIVOS
• Mostrar a importância da
modelagem/design de software;
• Ensinar como modelar os requisitos de
um software por meio do Diagrama de
Casos de Uso;
• Ensinar como projetar um software por
meio dos diagramas da UML;
4. 4
Benefícios do Treinamento
• Reduzir o esforço de manutenção de
software;
• Reduzir o retrabalho de maneira geral:
• Gestão de Conhecimento:
–Consolidar a informação do projeto na
empresa e não somente nas pessoas.
5. 5
AGENDA
1 2 3 4 5
1) Importância de se projetar
software
* Outras áreas de
Engenharia;
* Custo de desenv/alteração;
2) Conceito de UML
* O que é, objetivos e
diagramas.
3) Diagrama de Casos de
Uso
* O que a UML nos diz;
* Exemplos;
4) Exemplo prático de
aplicação.
5) Fim
6. 6
AGENDA
1 2 3 4 5
3) Diagrama de Casos de Uso
* O que a UML nos diz;
* Exemplos;
8. 8
Diagrama de Casos de Uso
• São compostos por 2 elementos
–Diagrama:
• Parte gráfica
–Especificação:
• Parte escrita;
9. 9
Relacionamento de UC e Ator
• Exemplo de diagramas:
Fazer Pedidos
Aprovar Crédito
Entregar Material
Sistema
Cliente
Vendedor
Gerente
Cliente cadastrarCliente
dadosCliente
msg02
10. 10
Diagrama de Casos de Uso
• São compostos por 2 elementos
–Diagrama:
• Parte gráfica
–Especificação:
• Parte escrita;
11. 11
Diagrama de Casos de
Uso - Especificação
• Um Caso de Uso, além da sua especificação
gráfica, também apresenta uma especificação
textual;
• Por meio dessa descrição textual é modelado o
passo a passo que deve ser executado para
que a funcionalidade seja cumprida;
• Apesar dessa especificação textual ser muito
importante, ao contrário da gráfica, ela não é
formalizada pela UML;
• Assim, o que se segue são boas práticas
definidas pelos autores da área;
12. 12
Diagrama de Casos de
Uso - Especificação
• Normalmente uma especificação deve no
mínimo:
– Descrever o seu objetivo;
– Descrever o cenário principal – Curso
Normal;
– Descrever os cenários alternativos – Curso
Alternativo;
13. 13
Diagrama de Casos de
Uso - Especificação
• Descrever o seu objetivo:
– Mostrar a finalidade do caso de uso
• Descrever o cenário principal – Curso Normal:
– O curso normal é o passo a passo do que
frequentemente é executado no caso de uso
• Descrever os cenários alternativos – Curso
Alternativo:
– O curso alternativo é a descrição do passo a
passo de situações que acontecem poucas
vezes na situação modelada pelo caso de uso.
14. 14
Diagrama de Casos de
Uso - Especificação
• Sendo assim, uma caso de uso tem:
–UMA descrição de curso normal;
–Pode ter VÁRIAS descrições de cursos
alternativos;
• Os passo a passo da especificação devem
ser numerados em ordem de
acontecimento;
15. 15
Diagrama de Casos de
Uso - Especificação
• 01. reservarQuarto
• Este use case é responsável pela reserva de quarto solicitada
pelo cliente.
• Curso Normal:
• 1. O cliente solicita a reserva de um quarto para um determinado
período.
• 2. O sistema verifica se existe quarto disponível para o período
solicitado e informa o quarto a ser reservado.
• 3. O cliente informa seu Cpf.
• 4. O sistema seleciona o cliente associado ao Cpf
• 5. O cliente confirma seus dados.
• 6. O sistema solicita ao cliente que confirme a reserva do quarto.
• 7. Cliente confirma a reserva.
• 8. O sistema reserva o quarto para o período solicitado e
• emite msg01 "Quarto Reservado".
16. 16
Diagrama de Casos de
Uso - Especificação
• Cursos Alternativos:
• 2. Caso não exista quarto disponível para o período desejado.
• 2.1 O sistema emite msg01 "Não existe quarto disponível no
período solicitado".
• 2.2 Abandonar o use case.
• 4. Caso o cliente não esteja cadastrado
• 4.1 O sistema ativa o use case cadastrarCliente e continua
no passo 6.
• 5. O cliente atualiza seus dados
• 5.1 O sistema atualiza o cadastro do cliente.
• 7. O cliente desiste da Reserva.
• 7.1 O sistema cancela a Reserva e emite msg01
"ReservaCancelada".
• 7.2 Abandonar o use case.
19. 19
Estudo de Caso –
Sistema Hoteleiro
• Deseja-se modelar um sistema para um pequeno
hotel que atenda aos seguintes requisitos:
• Quando o Cliente telefona ou vem até o hotel e
pede para reservar um quarto o funcionário
verifica se existe quarto disponível no período
solicitado. Caso positivo, é feita a reserva do
quarto. Caso negativo, é informado ao cliente a
não disponibilidade do quarto.
• Quando o cliente não mais desejar o quarto
reservado o funcionário providencia o
cancelamento da reserva, disponibilizando
novamente o quarto.
• Quando o cliente não comparecer ao hotel para
hospedar-se até as 12:00 horas do dia da
Reserva, deve ser cancelada a sua Reserva.
20. 20
Estudo de Caso –
Sistema Hoteleiro
• Quando o cliente ocupar um quarto, reservado
previamente, o funcionário faz o registro do cliente. Caso o
quarto não esteja reservado uma mensagem de rejeição
será emitida. Caso contrário, um pacote com informações
úteis e a confirmação serão fornecidos ao Cliente.
• Quando o cliente deixar o hotel e solicitar que providencie
sua saída, será fornecida a respectiva conta, e o quarto
será tornado indisponível para a limpeza.
• O cliente pode pagar a conta à vista ou usando cartão de
crédito. Caso use cartão de crédito, é verificado sua
situação para aceitar ou rejeitar o cartão. Esta verificação
é feita por telefone.
• Quando o quarto estiver limpo, após uma ocupação, o
gerente torna-o disponível. (Retirado das notas de aula do
professor Prado da UFSCar)
31. 31
Finalização
• A importância de se projetar um software
consiste:
– No aumento de qualidade do produto;
– Na diminuição do retrabalho caro ->
Manutenção;
– No aumento da produtividade da fase de
implementação
32. 32
Finalização
• Conceito de UML
–UML NÃO É PROCESSO;
–UML É UM CONJUNTO DE
FERRAMENTAS CRIADAS PARA
MODELAR SISTEMAS DE SOFTWARE
33. 33
Finalização
• Diagrama de Casos de Uso
– Diagrama da UML utilizado para modelar
requisitos de um documento de requisitos;
– Composto por duas partes:
• Diagrama;
• Especificação.
– O Diagrama é formalizado pela UML, já a
especificação não;
34. 34
Finalização
• Uso da UML– pesquisa com 427 participantes –
Fonte: Method and Tools (2005)
Status Porcentagem
Não responderam 7%
Não usam 18%
Estudando 12%
Analisaram e Rejeitaram 4%
Projetos Pilotos 4%
Adotaram alguns diagr 25%
Usam em alguns projetos 14%
Todos projetos novos usam 16%