[03] APS Modelagem de Negócios e Casos de Uso

Prévia do material em texto

1
Análise e Projeto de Sistemas
Aula 3
Modelagem de Negócio com 
Diagrama de Atividade e Modelo de Casos de Uso
Prof. Rafael Targino
rtargino@unicarioca.edu.br
2
O conteúdo desta aula foi parcialmente 
baseado nos slides disponíveis do livro:
Análise e Projeto de Sistemas de Informação OO
Raul Sidnei Wazlawick, Elsevier, 2a edição, 2011
Princípios de Análise e Projeto de Sistemas com UML
Eduardo Bezerra, Campus, 1a edição, 2006 
2
3
Conteúdo da Aula
• Modelagem de Negócio com Diagrama de 
Atividades
• Modelagem de Casos de Uso
4
Contexto dos Projetos
• A maioria dos projetos exige que o analista 
responda primeiro qual é a visão da empresa 
para o projeto, ou seja, o que a empresa quer 
com o projeto, por que ele está sendo proposto 
e por que a empresa vai gastar dinheiro com 
ele.
• A visão geral do sistema, ou sumário executivo, 
é um documento em formato livre, onde o 
analista deve escrever o que ele conseguiu 
descobrir de relevante sobre o sistema após as 
conversas iniciais com os clientes e usuários.
3
5
Modelagem de Negócio com 
Diagrama de Atividades
• Para melhor compreensão do funcionamento 
da empresa, pode-se criar um ou mais 
modelos das atividades de negócio.
• Para tal pode ser usado o diagrama de 
atividades da UML.
• Os diagramas de atividades podem ser 
usados para representar processos em nível 
organizacional, ou seja, de forma muito mais 
ampla do que a mera visão de requisitos de 
um sistema informatizado.
6
Diagrama de Atividade
• Um diagrama de atividade exibe passos de 
uma computação. 
– Cada atividade é um passo da computação. 
– É orientado a fluxos de controle (ao contrário dos 
DTEs que são orientados a eventos).
• São um tipo de fluxograma estendido..., pois 
permitem representar ações concorrentes e 
sua sincronização.
4
7
Atividade Inicial e Final
• O processo, representado no diagrama, deve 
ter uma pseudoatividade inicial representada 
por um círculo preto e uma pseudoatividade 
final representada por um círculo preto 
dentro de outro círculo.
• Também chamada de Estado inicial e final.
• Deve haver um estado inicial e pode haver 
vários estados finais e guardas associadas 
a transições.
– pode não ter estado final, o que significa que o 
processo ou procedimento é cíclico.
8
Atividades
• As atividades são representadas por figuras 
oblongas.
• Quando uma atividade é representada 
dentro de uma determinada raia, isso 
significa que o ator ou sistema 
correspondente àquela raia é o responsável 
pela execução da atividade.
5
9
Raias
• O diagrama pode ser dividido em raias 
(swimlanes), cada raia representando um 
ator ou sistema que participa de um 
conjunto de atividades.
• O ator pode ser um ser humano, um 
departamento ou mesmo uma organização 
completa.
10
Fluxos e Caminhos
• Fluxos ou dependências entre atividades são 
representados por setas.
• Os fluxos normalmente ligam duas 
atividades indicando precedência entre elas.
• Um caminho é uma sequência de atividades 
ligadas por fluxos.
6
12
Exemplo: Venda de Livros
7
13
Estruturas de Controle de Fluxo
• Estrutura de seleção (branch e merge), 
representada por losangos.
– Do nó branch saem fluxos com condições de 
guarda (expressões lógicas entre colchetes).
– Todos os caminhos devem voltar a se encontrar 
em um nó merge.
– Dois ou mais fluxos podem sair de uma estrutura 
de seleção, mas é importante que as condições 
de guarda sejam mutuamente excludentes, ou 
seja, exatamente uma delas pode ser verdadeira 
de cada vez;
14
Fluxos de controle seqüenciais
• Um ponto de ramificação possui uma 
única transição de entrada e várias 
transições de saída.
– Para cada transição de saída, há uma condição de 
guarda associada.
– Quando o fluxo de controle chega a um ponto de 
ramificação, uma e somente uma das condições 
de guarda deve ser verdadeira.
– Pode haver uma transição com [else].
• Um ponto de união reúne diversas 
transições que, direta ou indiretamente, têm 
um ponto de ramificação em comum. 
8
Exemplo com Branch e Merge
16
Estruturas de Controle de Fluxo
• Estrutura de paralelismo (fork e join), 
representada por barras pretas.
– Caminhos independentes entre os nó fork e join 
podem ser executados em paralelo, ou seja, sem 
dependências entre suas atividades.
9
17
Fluxos de Controle Paralelo
• Fluxos de controle paralelos: dois ou mais 
fluxos sendo executados simultaneamente.
• Uma barra de bifurcação recebe uma 
transição de entrada, e cria dois ou mais 
fluxos de controle paralelos.
– cada fluxo é executado independentemente e em 
paralelo com os demais.
• Uma barra de junção recebe duas ou mais 
transições de entrada e une os fluxos de 
controle em um único fluxo.
– Objetivo: sincronizar fluxos paralelos.
– A transição de saída da barra de junção somente 
é disparada quando todas as transições de 
entrada tiverem sido disparadas. 
Exemplo adicionando Fork e Join
10
19
Exemplo (Raias de Natação) 
Exercício – Diagrama de Atividades
• Elaborar um diagrama de atividades a partir do processo de 
vistoria de um carro no Detran
– O motorista agenda a vistoria do seu veículo para uma 
determinada data. O veículo pode ser um carro, moto ou 
caminhão. O agendamento da vistoria pode acontecer por 2 meios: 
telefone ou internet.
– O veículo possui um proprietário, mas outra pessoa pode fazer a 
vistoria, desde que ela seja devidamente registrada e autorizada
– Ao chegar em um posto de vistoria o motorista deve informar o 
código do agendamento ao responsável pela triagem. O 
responsável pela triagem irá confirmar o agendamento no sistema, 
conferir a documentação e indicar o número da cabine que o 
motorista deverá se dirigir.
– A vistoria é feita pelo avaliador, que informa no sistema o 
resultado da avaliação. Existem 2 tipos de avaliação. A avaliação 
de segurança e a avaliação de emissão de CO2. Apenas veículos 
com idade maior que 5 anos fazem a avaliação de CO2. Ambas as 
avaliações podem ter resultados positivos ou negativos durante a 
vistoria. 
11
21
Exercício – Diagrama de Atividades
• Continuação...
– Se as avaliações foram positivas, o motorista é encaminhado 
para o protocolo de entrega de documento. Neste protocolo, ele 
espera ser chamado, enquanto o setor administrativo imprime o 
novo documento do veículo.
– Se a avaliação for negativa, o motorista é liberado para resolver 
o problema e retornar para uma nova vistoria. Se ele resolver o 
problema no mesmo dia, ele pode retornar o posto, passar 
novamente pela triagem e fazer uma nova vistoria apenas no 
item que foi reprovado. Neste caso o avaliador realizará uma 
reavaliação de um ou mais itens de vistoria e informará o 
resultado, assim como fez na avaliação inicial.
– Se o motorista não resolver o problema no mesmo dia, ele 
deverá agendar uma nova vistoria.
22
Conteúdo da Aula
• Modelagem de Negócio com Diagrama de 
Atividades
• Modelagem de Casos de Uso
12
23
Casos de Uso
• O modelo de casos de uso é uma representação das 
funcionalidades externamente observáveis do 
sistema e dos elementos externos ao sistema que 
interagem com o mesmo.
• Esse modelo representa os requisitos funcionais do 
sistema.
• Também direciona diversas atividades posteriores 
do ciclo de vida do sistema de software.
• Além disso, força os desenvolvedores a moldar o 
sistema de acordo com as necessidades do usuário
24
Casos de Uso
• O modelo de casos de uso engloba
– Lista de Casos de Uso
– Diagrama de Casos de Uso
– Especificação do Caso de Uso (passo a passo)
13
25
Tudo Começa com os Requisitos...
• Requisitos para um caixa eletrônico
– O sistema deve permitir que os correntistasretirem 
dinheiro
– O sistema deve limitar o saque em 500 reais
– O sistema deve operar somente com múltiplos de 50 reais e 
utilizar notas de 50 e 100 
– O sistema deve informar para o correntista o seu saldo 
após um saque
– O sistema deve permitir depósitos em dinheiro e cheque
– Em depósitos em cheque deverá ser informado o banco, 
agência e número da conta do cheque depositado
– O sistema deve permitir a geração de extratos de 1 
semana, 15 dias e 30 dias. 
– O sistema deve permitir apenas 2 extratos por semana para 
cada correntista
Quais seriam os Casos de Uso de um 
Caixa Eletrônico?
• Mantenedor
– Alimentar 
Caixa
– Emitir Relatório 
de Saques 
Semanais
• Correntista
– Efetuar 
Saque
– Emitir 
Extrato
– Efetuar 
Pagamento
– Efetuar 
Depósito
14
27
Caso de Uso - Nome
• O nome do caso de uso deve ser único e 
deve conter um verbo + substantivo.
• O nome deve capturar a essência do Caso de 
Uso.
• Exemplo:
– Fazer uma reserva
– Cancelar uma reserva
– Emitir Pedido de Compra
– Comprar Ingresso
– Cancelar Agendamento
28
Caso de Uso e Requisitos
• Cada caso de uso será associado a um conjunto de 
requisitos funcionais do sistema.
• Usualmente isso se faz através de relações de 
rastreabilidade ou matriz de relacionamento.
• Usualmente vários requisitos associam-se a um caso 
de uso, especialmente quando se tratar de um caso 
de uso complexo.
• Alguns requisitos, porém, podem estar associados a 
vários casos de uso.
• Em alguns casos também é possível que um 
requisito corresponda a um único caso de uso e vice 
versa.
15
29
Requisitos X Casos de Uso (CDU)
CDU1 CDU2 CDU3
Requisito 1 X
Requisito 2 X
Requisito 3 X X
Requisito 4 X X
Requisito 5 X
30
Caixa Eletrônico
Requisitos x Casos de Uso
• O sistema deve permitir que os correntistas 
retirem dinheiro
• O sistema deve limitar o saque em 500 reais
• O sistema deve operar somente com múltiplos 
de 50 reais e utilizar notas de 50 e 100 
• O sistema deve informar para o correntista o 
seu saldo após um saque
• O sistema deve permitir depósitos em dinheiro 
e cheque
• Em depósitos em cheque deverá ser informado 
o banco, agência e número da conta do cheque 
depositado
• O sistema deve permitir a geração de extratos 
de 1 semana, 15 dias e 30 dias. 
• O sistema deve permitir apenas 2 extratos por 
semana para cada correntista
Efetuar
Saque
Emitir
Extrato
Efetuar 
Depósito
X
X
X X
X
X
X
X
X
16
31
Especificação Casos de Uso
• Um caso de uso é a especificação de uma 
sequência de interações entre um sistema e os 
seus atores.
• Define parte da funcionalidade de um sistema, sem 
revelar a estrutura e o comportamento 
internos deste sistema.
• Cada caso de uso é definido através da descrição 
textual das interações que ocorrem entre o(s) 
elemento(s) externo(s) e o sistema.
Caso de Uso – Efetuar Saque
Sequência de passos
• Como seria o passo a passo para descrever o que ocorre em 
um saque em um caixa automático?
1. Cliente insere o cartão
2. Sistema solicita senha
3. Cliente digita senha
4. Cliente seleciona opção de 
saque
5. Sistema informa que está 
contando as notas para o 
saque de 200 reais
6. Sistema entrega notas
7. Sistema informa o Saldo
1. Cliente insere o cartão
2. Sistema solicita senha
3. Cliente digita senha
4. Cliente seleciona opção de 
saque
5. Cliente informa o valor a ser 
sacado
6. Sistema pergunta se o valor 
será debitado da conta 
corrente ou poupança
7. Cliente informa a origem do 
saque
8. Sistema entrega notas
9. Sistema informa o Saldo
Pergunta: os dois fluxos atendem aos requisitos levantados?
17
33
Diagrama de Casos de Uso
• O modelo de casos de uso de um sistema é
composto de duas partes, uma textual, e
outra gráfica.
• Um modelo de casos de uso típico é formado
de vários casos de uso.
• O diagrama da UML utilizado na modelagem 
de gráfica é o diagrama de casos de uso.
– Este diagrama permite dar uma visão global e de 
alto nível do sistema.
34
Elementos do Diagrama de Casos de 
Uso
Reservar Livro
Usuário
Ator
Caso de uso
Relacionamento
de comunicação
18
35
Diagrama de Casos de Uso
36
Elementos do Diagrama de Casos de 
Uso
• Um MCU possui diversos elementos, e cada um 
deles pode ser representado graficamente. Os 
elementos mais comuns em um MCU são:
– Ator
– Caso de uso
• Além disso, a UML define diversos de 
relacionamentos entre esses elementos para 
serem usados no modelo de casos de uso:
– Comunicação
– Inclusão
– Extensão
– Generalização
• Para cada um desses elementos, a UML define 
uma notação gráfica e uma semântica 
específicas.
19
37
Casos de Uso - Atores
• Papéis que uma entidade (homem, 
hardware, sistema) desempenha no sistema.
• Não são parte do sistema.
• Comandam os casos de uso:
– Procure pelos atores e depois pelos seus casos de 
uso.
• Não precisam ser humanos.
• Representação: Stickman
Instituição 
Financeira
Cliente
38
Identificação de Atores
• Fontes e os destinos das informações a 
serem processadas são atores em potencial.
– uma vez que, por definição, um ator é todo 
elemento externo que interage com o sistema.
• O analista deve identificar:
– as áreas da empresa que serão afetadas ou 
utilizarão o sistema.
– fontes de informações a serem processadas e os 
destinos das informações geradas pelo sistema.
20
39
Identificação de Atores
• Há algumas perguntas úteis cujas respostas 
potencialmente identificam atores.
– Que órgãos, empresas ou pessoas (cargos) irão 
utilizar o sistema?
– Que outros sistemas irão se comunicar com o 
sistema?
– Alguém deve ser informado de alguma ocorrência 
no sistema?
– Quem está interessado em um certo requisito 
funcional do sistema?
40
Quem são os Atores?
• Para que um caso de uso seja o mais essencial possível 
recomenda-se, porém, que apenas os atores efetivamente 
interessados no caso de uso sejam considerados.
• Exemplo:
– O frentista é um mero instrumento de ação do cliente.
– O frentista não tem interesse pessoal no processo de encher o tanque.
– Ele atua simplesmente como uma ferramenta do sistema, ou como parte 
da tecnologia.
– Se a bomba fosse operada pelo próprio cliente, como acontece em alguns 
países, o caso de uso essencial ainda seria o mesmo, pois as mesmas 
informações seriam trocadas com o sistema, mudando apenas o 
personagem.
– Então, neste caso, recomenda-se que o ator seja o cliente e que o frentista 
sequer apareça como ator.
• Desta forma, a análise vai produzir casos de uso que são 
independentes da tecnologia de interface.
21
41
Identificação de Casos de Uso
• A partir da lista (inicial) de atores, deve-se 
passar à identificação dos casos de uso.
• Nessa identificação, pode-se distinguir entre 
dois tipos de casos de uso
– Primário: representa os objetivos dos atores. 
– Secundário: aquele que não traz benefício direto 
para os atores, mas que é necessário para que 
sistema funcione adequadamente. 
42
Casos de Uso Primários
• Perguntas úteis:
– Quais são as necessidades e objetivos de cada 
ator em relação ao sistema?
– Que informações o sistema deve produzir?
– O sistema deve realizar alguma ação que ocorre 
regularmente no tempo?
– Para cada requisito funcional, existe um (ou 
mais) caso(s) de uso para atendê-lo? 
• Outras técnicas de identificação:
– Caso de uso “oposto”
– Caso de uso que precede/sucede a outro caso de 
uso
– Caso de uso temporal
– Caso de uso relacionadoa uma condição interna
22
43
Casos de Uso Secundários
• Estes se encaixam nas seguintes categorias:
– Manutenção de cadastros; 
– Manutenção de usuários;
– Gerenciamento de acesso;
– Manutenção de informações provenientes de 
outros sistemas.
• Obs: casos de uso secundários, são menos 
importantes que os casos de uso primários.
– O sistema de software não existe para cadastrar 
informações, nem tampouco para gerenciar os 
usuários.
– O objetivo principal de um sistema é agregar 
valor ao ambiente no qual ele está implantado.
44
Relacionamentos
• Relacionamentos no modelo de casos de 
uso:
– Comunicação
– Inclusão
– Extensão
– Generalização
23
45
Comunicação 
• Relacionamento entre um ator e um caso de 
uso
– Conectados aos casos de uso somente pela 
associação.
• Associação = relação de comunicação
– Podem enviar ou receber mensagens
Cliente
Realizar Saque
46
Inclusão - Definição
• Uma associação de inclusão de um caso de uso base 
para um caso de uso de inclusão significa que o 
comportamento definido no caso de uso de inclusão é 
incorporado ao comportamento do caso de uso base. 
• A associação de inclusão deve ser referenciada na 
descrição do caso de uso base.
– Ou seja, o caso de uso base conhece o caso de uso incluído. 
Já o caso de uso incluído não faz referência ao caso de uso 
base.
• O caso de uso incluído não precisa ser executado sempre 
que o caso de uso base é realizado. É possível que que a 
inclusão esta associada a alguma condição (fluxo 
alternativo).
24
47
Inclusão - Exemplo
48
Extensão – Extend - definição
• Uma associação de extensão entre um caso 
de uso de extensão e um caso de uso base 
significa que o comportamento definido no 
caso de uso de extensão pode ser inserido 
dentro do comportamento definido no caso 
de uso base, em um local especificado 
indiretamente pelo caso de uso de extensão.
• O caso de uso base não sabe da existência 
do caso de uso de extensão.
25
49
Extensão - Exemplo
Controlar 
Estatísticas de 
Notas
<<extend>>
50
Generalização
• Pode acontecer entre atores e entre casos de 
uso.
26
51
Generalização
• Um relacionamento de generalização/especialização 
entre um caso de uso pai e um caso de uso filho significa 
que o caso de uso filho herda o comportamento e o 
significado do caso de uso pai, acrescentando ou 
sobrescrevendo seu comportamento (OLIVÉ, 
2007;BOOCH; RUMBAUGH; JACOBSON, 2006).
52
Exercício – Diagrama de Casos de 
Uso
• Elabore um diagrama de casos de uso para o 
processo de vistoria de veículos no Detran 
descrito anteriormente.