Este documento apresenta um treinamento sobre introdução à UML com casos de uso. O treinamento é ministrado por Rodrigo Gomes, que é analista de requisitos na IBM e professor universitário. O treinamento aborda conceitos básicos de UML, casos de uso, diagramas de casos de uso e levantamento de requisitos com casos de uso.
2. Apresentação
Rodrigo Gomes da Silva
Contatos:
rodrigo.gomes3@hotmail.com
rogomes@br.ibm.com
rodrigo.gomes@unis.edu.br
Redes Sociais
http://www.linkedin.com/pub/rodrigo-gomes-da-silva/37/568/716
https://twitter.com/rodrigogomes3
https://www.facebook.com/rodrigo.gomesdasilva.92
•
Formação:
–
–
–
–
–
•
Atualmente:
–
–
•
Certificação IBM RMUC – Requirements Management with Use Cases
Especialista em Design Instrucional para EaD Virtual (UNIFEI)
Especialista em Docência do Ensino Superior (FINOM)
Bacharel em Sistemas de Informação (UEMG)
Técnico em Processamento de Dados (CETEV)
Analista de Requisitos na IBM do Brasil - SP
Professor Universitário – UNIS-MG
Atuações Anteriores
–
–
–
–
–
Professor Universitário – FACECA
Professor Universitário – UNINCOR
Professor Universitário – FIPV
Analista de Sistemas – Sindicato Rural da Campanha
Gerente de TI – Santa Casa de Misericórdia da Campanha
2
3. Apresentação
• Quem é você?
–
–
–
–
Nome
Período
Contatos com UML e levantamento de requisitos
Atuação na área de TI
3
4. UML
• O que é UML?
– Uma linguagem ou notação de diagramas
para especificar, visualizar e documentar
modelos de software
– Não é um método de desenvolvimento
– Não indica o que fazer primeiro
– Ajuda a visualizar o produto e a
comunicação
– É formada por elementos que são usados
para criar diagramas, que representam uma
determinada parte do sistema, ou um ponto
de vista do sistema
4
5. UML
• Para que usar UML?
–
–
–
–
–
–
–
–
Pensar antes de codificar
Apresentar nossas ideias ao grupo
Aumentar a participação e envolvimento do time
Documentar as ideias quando já consolidadas
Atender aos requisitos
Reduzir esforço de manutenção
Facilitar a alteração do software
Reduzir re-trabalho: reparos ocorrem a nível de
projeto
– Gestão do conhecimento: consolidar o projeto na
empresa e não nas pessoas
5
6. UML
• Importância do Projeto de Software
Ponte Rio – Niterói:
• Comprimento: 13,29 Km
• Tráfego: 140 mil veículos / dia
• Construção: 01/1969 – 03/74
6
7. UML
• Linha de Produção
Assim como as pontes, o software não pode
ser feito por meio de linhas de produção
Após a implementação
eu posso copiá-lo e
distribuí-lo
7
8. UML
• Falta de Alinhamento entre cliente,
analista e time
8
13. UML
• Complexidade
Para dominarmos
uma realidade com a
abordagem sistêmica,
precisamos de
modelos, o que
favorece a
possibilidade de
fazermos simulações,
facilitando assim a
definição de soluções
para os problemas
existentes na
13
realidade em questão.
14. UML
• Motivação
Necessidade de uma Modelagem Visual
Da mesma forma que, para construir uma casa é preciso
desenhar sua planta, para construir um software, é preciso
desenhar sua arquitetura.
É preciso ter uma
representação visual do seu
sistema, antes que ele entre
na etapa de implementação.
14
15. UML
• Motivação
Necessidade de uma Modelagem Visual
É preciso estabelecer uma padronização para facilitar a
comunicação entre os analistas e o time de
desenvolvimento.
E facilitar a comunicação
entre os analistas e o
cliente.
15
16. UML
• Motivação
Necessidade de uma Modelagem Visual
Um sistema tem geralmente muitas classes. Dependendo do nível
hierárquico da pessoa envolvida, formas diferentes de apresentar as
classes devem ser geradas.
• O cliente precisa compreender
apenas alguns conceitos;
• O gerente de projetos não precisa
de detalhes do modelo;
• O time de desenvolvimento precisa
de todos os detalhes possíveis.
16
17. UML
• Motivação
Necessidade de uma Modelagem Visual
Um modelo deve ser criado independente de sua
implementação. A qualquer momento uma implementação
pode ser trocada por outra, sem afetar o modelo.
17
18. UML
• Motivação
UML
•UML é uma ferramenta que nos auxilia na modelagem de
sistemas;
•Mantida pela OMG
•Proporciona um padrão para o projeto de arquitetura de
sistemas
• Composta por 13 diagramas
18
19. UML
• Alguns Diagramas da UML?
– Estrutura Estática:
• Diagrama de Classes
• Diagrama de Objetos
• Diagrama de Componentes
• Diagrama de Implantação
– Estrutura Dinâmica
• Diagrama de Casos de Uso
• Siagrama de Sequencia
• Diagrama de Atividades
• Diagrama de Estados
• Diagrama de Colaboração
19
20. UML
• Alguns Diagramas da UML?
– Estrutura Estática
• Diagrama de Classes
• Diagrama de Objetos
• Diagrama de Componentes
• Diagrama de Implantação
– Estrutura Dinâmica
• Diagrama de Casos de Uso
• Siagrama de Sequencia
• Diagrama de Atividades
• Diagrama de Estados
• Diagrama de Colaboração
Foco deste
treinamento
20
21. UML
• Diagramas da UML
•Qual eu devo utilizar primeiro?
• Não existe ordem pré-definida
• Não existe a necessidade de utilização de todos os
diagramas
21
22. UML
• Características da UML
•Independente da linguagem de desenvolvimento
•Alguns diagramas podem modelar software
orientados a objetos ou não
•Define uma linguagem formal para a modelagem e
não para a implementação
22
23. O Modelo de Caso de Uso
• O que é o Modelo de Caso de Uso?
– Um link entre necessidades dos stakeholders e
requisitos do software
– Define o limite do sistema
– Captura e comunica comportamento do sistema
– Identifica quem ou o quê interage com o sistema
– Valida e verifica requisitos
23
24. O Modelo de Caso de Uso
• O que é o Modelo de Caso de Uso?
– É representado por um modelo gráfico, o
Diagrama de Casos de Uso
– É especificado em um modelo textual, o
Documento de Especificação de Caso de Uso
Processo iterativo envolvendo discussões
entre técnicos, clientes e usuários finais
para o levantamento e detalhamento dos
requisitos funcionais.
24
25. O Modelo de Caso de Uso
• O que é o Modelo de Caso de Uso?
• Um Modelo de Caso de Uso descreve os requisitos
funcionais de um Sistema.
• Um Modelo de Caso de Uso associa as
necessidades dos stakeholders aos requisitos de
software do sistema.
• Por ser um instrumento de planejamento muito
forte, o Modelo de Casos de Uso é geralmente
utilizado em todas as Fases do Ciclo de
Desenvolvimento por todos os membros da equipe.
funcionais.
25
26. O Modelo de Caso de Uso
• Diagrama de Caso de Uso?
– Auxilia a comunicação entre os
analistas e os clientes.
– Descreve um cenário que mostra as
funcionalidades do sistema, do ponto de
vista do usuário.
– O cliente deve ver no diagrama de Caso
de Uso as principais funcionalidades do
sistema.
26
27. O Modelo de Caso de Uso
• Diagrama de Caso de Uso?
• Descreve o sistema, seu ambiente e a
relação entre os dois.
• Os casos de uso são usados para obter os
requisitos do sistema a partir da perspectiva
do usuário.
27
28. O Modelo de Caso de Uso
Antes de detalharmos o diagrama
de Caso de Uso vamos falar um
pouco sobre requisitos
28
30. O Modelo de Caso de Uso
Needs: Necessidades (dos stakeholders / do negócio)
Qual é a necessidade do negócio?
Qual é a necessidade dos Stakeholders
Features: Características do Sistema
Serviços que o sistema irá oferecer que permitirão atender as
necessidades do negócio e as necessidades dos stakeholders
Requisitos
Uma capacidade de software que deve ser atendida ou possuída por
um sistema ou componentes do sistema para satisfazer um
contrato, padrão, especificação, ou outros documentos formalmente
impostos
30
31. O Modelo de Caso de Uso
Needs
(necessidades)
Features
(serviços / características)
Requisitos
Requisitos Funcionais
Requisitos Não Funcionais
31
32. O Modelo de Caso de Uso
• Requisitos Funcionais:
São requisitos diretamente ligados à
funcionalidade do software, descrevem as funções
que o software deve executar.
– [RF001] O sistema deve permitir o cadastro de clientes
– [RF002] O sistema deve permitir a geração de relatório
de vendas por período
32
33. O Modelo de Caso de Uso
• Requisitos Não Funcionais:
Descrevem condições que o software deve atender
ou qualidade específicas que o software deve ter.
– [RNF001] O software deve suportar o navegador IE 5.0
ou superior
– [RNF002] O software deve utilizar o banco de dados DB2
33
34. O Modelo de Caso de Uso
• Needs x Features x Requisitos:
– Needs descrevem o que o negócio precisa
– Features descrevem quais os serviços
necessários para atender as Needs
– Requisitos descrevem como as Features serão
atendidas
34
35. O Modelo de Caso de Uso
• Mapeamento
Ver planilha de mapeamento
–
–
–
–
–
Descrição do problema
Desejo dos Stakeholders
Needs
Needs x Features
Mapeamento Needs x Features x Requisitos
35
36. O Modelo de Caso de Uso
• Notação do Caso de Uso?
O diagrama de Caso de Uso é representado por:
• Atores
• Casos de uso
• Relacionamentos
Os relacionamentos podem ser:
• Associações
• Generalizações
• Extensões ou Inclusões
36
37. O Modelo de Caso de Uso
• Elementos do Caso de USO
– Ator
• Um elemento que está fora do
sistema
• De alguma forma e em algum
momento ele interage com o
sistema
• Pode ser um usuário, um
equipamento ou outro sistema,
desde que tenha interação com o
sistema que está sendo modelado
37
38. O Modelo de Caso de Uso
• Elementos do Caso de USO
– Ator
• O ator não deve ser identificado
pelo nome, por exemplo João, mas
sim pelo papél que ele
desempenha na aplicação:
• Ex de nomes de atores:
– Gerente, Secretária, Professor,
Funcionário, Balconista, etc…
38
39. O Modelo de Caso de Uso
• Elementos do Caso de USO
– Ator
• O Ator não é parte do sistema
• Ele age no ambiene do sistema
• Interage ativamente com o sistema
• Representa um ser humano, uma
máquina ou outro sistema
39
40. O Modelo de Caso de Uso
• Papél
• Podemos definir um papel
considerando, por exemplo, o
caso de múltiplos personagens
representados por um ator numa
peça de teatro.
• Neste caso, você como Ator
poderia representar o papel de
bandido ou de policial. O Ator
representa um papel e não um
usuário individual.
40
41. O Modelo de Caso de Uso
•
Como identificar um Ator?
•
Onde, na organização, o Sistema é usado?
•
Quem se beneficiará do uso do sistema?
•
Quem fornecerá informações ao Sistema, usará essas
informações e as removerá?
•
Quem suportará e manterá o Sistema?
•
O Sistema usa um recurso externo?
•
Uma pessoa representa diversos papéis?
•
Várias pessoas representam o mesmo papel?
•
O Sistema interage com um Sistema Legado?
41
42. O Modelo de Caso de Uso
• Mapeamento
Ver planilha de mapeamento
• Atores
42
43. O Modelo de Caso de Uso
• Elementos do Caso de USO
– Caso de Uso
• Representado pela figura de uma
elípse, identifica uma
funcionalidade do sistema que gera
valor para o Ator.
• O nome do caso de uso deve
começar por um verbo de ação
(fazer, realizar, registrar, etc…)
• Indica uma ação que o Ator pode
realizar ao interagir com o sistema
43
44. O Modelo de Caso de Uso
• Elementos do Caso de
USO
– Caso de Uso
• Descrevem ações que
entregam valor para o
Ator
• Mostra as
funcionalidades do
sistema sendo utilizadas
pelo Ator
• Modela um diálogo entre
Ator e Sistema
• Representa o sistema
em uma perspectiva do
Ator.
44
45. O Modelo de Caso de Uso
• Como Identificar
– Caso de Uso
•
O que o ator necessita fazer?
•
O Ator precisa ler, criar, excluir, modificar ou armazenar
algum tipo de informação no Sistema?
•
O trabalho diário do ator pode ser simplificado ou tornado
mais eficiente através de novas funções no Sistema?
•
O ator tem de ser notificado sobre os eventos no Sistema
ou ainda notificar o sistema em si?
•
Quais são as macros funções que o ator necessita do
Sistema?
45
46. O Modelo de Caso de Uso
• Mapeamento
Ver planilha de mapeamento
• Casos de Uso Identificados
• Mapeamento UC x RF
• Mapeamento UC x RF x AT
46
47. O Modelo de Caso de Uso
• Rastreabilidade
– Permite uma compreensão dos
relacionamentos entre requisitos e seus
artefatos
47
48. O Modelo de Caso de Uso
• Mapeamento
Ver planilha de mapeamento
–
–
–
–
Rastreabilidade Needs x Features
Rastreabilidade Features x Requisitos
Rastreabilidade RF x UC
Rastreabilidade Completa
48
49. O Modelo de Caso de Uso
• Relacionamentos
Relacionamentos entre Atores e Casos de Uso ,
entre Casos de Uso e Casos de Uso, e entre
Atores e Atores.
Os principais relacionamentos são:
• Associação;
• Generalização;
• <<Inclui>>
• <<estende>>
49
50. O Modelo de Caso de Uso
• Relacionamentos
Associação entre Ator e Caso de Uso
Representamos uma associação entre um ator e um caso de
uso por uma ligação simples.
Caso de Uso Concreto
Sua execução é iniciada
através da chamada de um
Ator
Em determinado momento o ator “Cliente” poderá acionar a
Em determinado momento o ator “Cliente” poderá acionar a
50
funcionalidade “Fazer Pedido”
funcionalidade “Fazer Pedido”
51. O Modelo de Caso de Uso
• Relacionamentos
Relacionamento <<include>> entre Casos de Uso
Um relacionamento de inclusão mostra a dependência entre dois casos
de uso, o que significa que um caso de uso incorpora o comportamento
de outro caso de uso.
Caso de Uso
Abstrato
Sua execução é
iniciada através da
chamada de ouro
caso de uso
51
52. O Modelo de Caso de Uso
• Relacionamentos
Relacionamento <<extend>> entre Casos de Uso
Um relacionamento de extensão significa que um caso de pode ou não ser
incorporado em outro caso de uso, mas a incorporação não é obrigatória.
52
53. O Modelo de Caso de Uso
• Relacionamentos
Relacionamento <<extend>> <<include>>
53
54. O Modelo de Caso de Uso
• Relacionamentos
Generalização entre Atores
Representa uma relação de herança entre atores.
54
55. O Modelo de Caso de Uso
• Relacionamentos
Generalização entre Atores
55
56. O Modelo de Caso de Uso
• Mapeamento
Ver planilha de mapeamento
• Diagrama UC
56
57. O Modelo de Caso de Uso
• Tipos de Relacionamentos
Relacionamento
Associação
Inclusão
Extensão
Ator X Ator
Ator X Caso de Uso
Caso de Uso X Caso de Uso
Generalização
X
X
X
X
X
57
58. O Modelo de Caso de Uso
• Prática
– Divisão em 3 grupos
– Cada grupo deverá montar a planilha contendo
•
•
•
•
•
Needs
Features
Requisitos Funcionais
Atores
Casos de Uso
– Montar o Diagrama de Casos de Uso
– Cada grupo deverá escolher um dos sistemas abaixo:
• Consulta online de exames laboratoriais
• Venda online de passagens aéreas
• Venda online de ingressos de shows
– Cada grupo deverá apresentar sua solução
58
59. O Modelo de Caso de Uso
• Para estudo
Glossário UML - UFMG
http://homepages.dcc.ufmg.br/~amendes/GlossarioUML/
OMG
http://omg.org/
UML 2 – Uma abordagem
prática
Gilleanes T A Guedes
UML Guia do Usuário
Grady Booch
Fundamentos do Desenho Orientado a
Objeto
Meillir Page Jones
59