Modalagem de dados 10214

Prévia do material em texto

Contato
• Prof. Fausto José Feitosa Barbosa Gominho
• E-mail: fausto.gominho@professores.unifbv.edu.br
• Celular: (81) 99738-1880
mailto:fausto.gominho@professores.unifbv.edu.br
Cronograma
DATA AULA
23/FEV. ABERTURA E APRESENTAÇÃO DA DISCIPLINA
2/MAR. AULA 1
9/MAR. AULA 2
16/MAR. AULA 3
23/MAR. AULA 4
30/MAR. AULA 5
6/ABR. AULA 6
13/ABR. AULA 7
20/ABR. AULA 8
27/ABR. AV1
4/MAI. AULA 9
11/MAI. AULA 10
18/MAI. AULA 11
25/MAI. AULA 12
1/JUN. AULA 13
8/JUN. AULA 14
15/JUN. AV2
22/JUN. REVISÃO
29/JUN. AV3
5/JUL. DÚVIDAS FINAIS
7/JUL. FIM DO SEMESTRE LETIVO E FECHAMENTO DA BASE 2021.1
Roteiro
2. Análise orientada a objetos: conceitos; elementos; 
design (implementação); métodos e atributos de 
mecanismos de verificação e rastreabilidade entre 
modelos - definição; desenvolvimento em n-camadas 
(3-"Tiers" e "Model-View-Controller"- MVC).
Bibliografia
• Larman, Craig. Utilizando UML e 
padrões: uma introdução à análise e 
ao projeto orientado a objetos e ao 
desenvolvimento interativo. 3. ed. 
Porto Alegre: Bookman, 2007.
Capítulo
2 Capítulo
5 Capítulo
6 Capítulo
9
Capítulo
10
Processo de Software
Processo de Software
Processo de Software
Processo de Software
• Define uma abordagem para
– Construção
– Implantação
– Manutenção
• Exemplos
– Cleanroom
– RUP(Rational Unified Process)
– Scrum
– XP (eXtreming Programming)
Processo de Software
• Ciclo de vida cascata
– Processo sequencial
– Requisitos completamente definidos no início
– Programação e testes no final
• Ciclo de vida evolutivo
– Processo incremental
– Requisitos refinados a cada incremento
– Programação e testes a cada incremento
• Exemplo
– Em uma viagem, é melhor consertar o volante sempre que o carro começa a 
sair da pista ou só a cada 100 km rodados?
Desenvolvimento Iterativo
• A iteração deve ser fixa
– Tarefas podem ser removidas ou incluídas
– A iteração nunca deve passar da duração previamente estipulada
• O resultado de cada iteração é um software...
– Incompleto
– Em desenvolvimento(não pode ser colocado em produção)
– Mas não é protótipo!
• Esses software pode ser verificado e validado parcialmente
– Testes
– Usuários
• Podem ser necessárias diversas interações (ex. 10 a 15) para ter uma 
versão do sistema pronta para entrar em produção
Desenvolvimento Iterativo
• Interações curtas privilegiam a propagação do conhecimento
– Aumento do conhecimento sobre o software
– Diminuição das incertezas, que levam às mudanças
Desenvolvimento Evolutivo
• As especificações evoluem a cada iteração
– A cada iteração, uma parte do software fica pronta
– O conhecimento sobre o software aumenta
– As especificações são evoluídas para retratar esse aumento de 
conhecimento sobre o que é o software
Desenvolvimento Evolutivo
• Mudanças sempre acontecem em projetos de software
– Requisitos mudam
– O ambiente em o software está inserido muda
– As pessoas que operam o software mudam
• Tipos de mudanças
– Corretivas
– Adaptativas
– Evolutivas
– Preventivas
• Estratégias para lidar com mudanças
– Evitar as mudanças(corretivas) fazendo uso de boas técnicas de engenharia de 
software
– Acolher mudanças por meio de um processo evolutivo
Desenvolvimento Ágil
• São dadas respostas rápidas e flexíveis a mudanças
– O projeto é replanejado continuamente
– São feitas entregas incrementais e constantes de software, 
refletindo as mudanças solicitadas
Desenvolvimento Ágil
• São dadas respostas rápidas 
e flexíveis a mudanças
– O projeto é replanejado 
continuamente
– São feitas entregas 
incrementais e 
constantes de software, 
refletindo as mudanças 
solicitadas
Manifesto 
Ágil
Software 
funcionando 
vem antes de 
documentação 
abrangente
Colaboração 
do cliente vem 
antes de 
negociação de 
contrato
Resposta a 
modificação 
vem antes de 
plano em 
andamento
Indivíduos e 
interações 
vem antes de 
processos e 
ferramentas
Desenvolvimento Ágil
• Princípios ágeis
– Satisfazer o cliente
– Acolher modificações nos requisitos
– Entregar o software com frequência
– Trabalhar junto ao cliente
– Manter os indivíduos motivados
– Promover conversas face a face
– Medir o progresso com software funcionando
– Manter um ritmo constante de trabalho
– Cuidar da qualidade
– Buscar por simplicidade
– Trabalhar com equipes auto-organizadas
– Ajustar o comportamento da equipe buscando mais efetividade
Modelagem Ágil
• Tem intuito de apoiar o entendimento e a comunicação
– Do problema(análise)
– Da solução(projeto)
• Tem caráter exploratório
– Não visa ser completa
– Foca nos aspectos mais complexos e incomuns
• Não pretende ser a única documentação de software
– Enxerga o código como o “verdadeiro” projeto
– Todos os modelos anteriores podem estar desatualizados ou 
serem imprecisos
• Não pretende ser o meio de comunicação principal
– Deve ser feita pelos próprios desenvolvedores e não por equipes 
separadas
Modelagem Ágil
• Incentiva a modelagem em pares
– Ou pequenos grupos
• Apoia a criação de visões do modelo em paralelo
– Estática (ex. diagrama de classes)
– Dinâmica (ex. diagrama de sequência)
• Usa ferramentas simples
– Quadro-branco + câmera digital
– Ferramentas CASE
– Editor de texto
• Utiliza simplificações da notação sempre que possível
– Não usa todos os recursos da UML
– Utiliza recursos adicionais se necessário
Processo Unificado ou RUP
Processo Unificado
Ágil
Iterativo
Evolutivo
RUP
• RUP – Rational Unified Process
– Framework genérico para processo
– Especializado para diferentes classes de sistemas, 
áreas de aplicação, organizações, níveis de 
competência e tamanhos de projeto
– Utiliza a UML como linguagem notacional
– Palavra-chave: direcionado a casos de uso, 
centrado em arquitetura, desenvolvimento iterativo 
e incremental
UML
• UML – Unified Modeling Language
– Junção dos modelos de Booch, OMT e OOSE
– Notação universal para modelagem OO
– Aprovado como notação padrão pelo OMG
• “Object Management Group”
Processo Unificado
• Benefícios esperados
– Mitigação de riscos precoce
– Visibilidade do progresso
– Envolvimento e comprometimento do usuário
– Controle sobre a complexidade
– Aprendizado incremental
– Menos defeitos
– Mais produtividade
Processo Unificado(exemplo)
• Analisar os requisitos no início do projeto
– Casos de uso
– Lista de requisitos não funcionais
• Priorizar os casos de uso
– Significativos para a arquitetura como um todo
– Alto valor de negócio
– Alto risco
• Em cada interação
– Selecionar alguns casos de uso por ordem de prioridade para serem analisados em 
detalhes
– Atribuir tarefas para a interação a partir da análise detalhada desses casos de uso
– Fazer projeto e programação de parte do software
– Testar a parte do software recém projetada e programada e criar a baseline da interação
– Apresentar a baseline da interação ao usuário
Processo Unificado(exemplo)
Processo Unificado(fases)
• O desenvolvimento pode ser decomposto em fase, com o 
intuito de retratar a ênfase principal das interações
– Concepção
– Elaboração
– Construção
– Transição
• Plano da fase
– Abrangente e superficial
• Plano da interação
– Específico e detalhado
Processo Unificado(exemplo)
Processo Unificado(concepção)
• Consiste de
– Identificação de riscos
– Listagem inicial dos requisitos
– Esboço dos casos de uso
– Identificação de arquiteturas candidatas
– Estimativa iniciais de cronograma e custos
• Principais características
– Menor fase do projeto
– Escopo ainda vago
– Estimativas ainda vagas
• Esforço e duração aproximados
– 5% do esforço do projeto
– 10% da duração do projeto
Processo Unificado(elaboração)
• Consiste de
– Mitigação dos riscos
– Detalhamento da maioria dos requisitos e casos de uso
– Estabelecimento e validação da arquitetura do software
– Detalhamento das estimativas do cronograma e custo
• Principais características
– Grande parte das atividades de análise e projeto já concluída– Diminuição significativa das incertezas
– Baseline da arquitetura é estabelecida
• Esforço e duração aproximados
– 20% do esforço do projeto
– 30% da duração do projeto
Processo Unificado(construção)
• Consiste de
– Implementação dos demais componentes da arquitetura
– Preparação para a implantação
• Principais características
– Maior fase do projeto
– Baseline de testes do produto é estabelecida
• Esforço e duração aproximados
– 65% do esforço do projeto
– 50% da duração do projeto
Processo Unificado(transição)
• Consiste de
– Execução de testes finais
– Implantação do produto
– Treinamento do usuário
• Principais características
– Baseline de liberação do produto é estabelecida
• Esforço e duração aproximados
– 10% do esforço do projeto
– 10% da duração do projeto
Processo Unificado(características)
• Os requisitos não são completamente definidos antes do 
projeto
• O projeto não é completamente definido antes da 
programação
• A modelagem não é feita de forma completa e precisa
• A programação não é a uma tradução mecânica do modelo 
para código
• As interações não duram meses, mas sim semanas
• O planejamento não é especulativo, mas sim refinado durante 
o projeto
Modelagem Orientada a Objetos
• Método centrado em dados e processos
• Existem diversos métodos OO:
– Conceitos similares entre os diversos métodos
– Primeiros métodos surgiram no fim da década de 80
– No final da década de 90 surge uma proposta de método 
padrão (RUP)
– Aprovação de uma NOTAÇÃO padrão (UML)
Conceitos básicos
• A chave da AOO/POO→objetos e classes de objetos
– AOO: modela o domínio do problema
→ identifica as classes do domínio do problema
→ determina os atributos e operações p/ as classes
– POO: Completa o modelo de classes de objeto
→ projeto da arquitetura: definição dos subsistemas 
→ projeto detalhado: detalha as classes do domínio
→ inclui classes de interface
→inclui classes de controle
40
Thelma 
Histórico
• Exemplos de métodos OO
– Shaler & Mellor(1989)
– Coad & Youdon (1991)
– Booch (1993)
– OOSE (Jacobson) (1993)
– OMT (Rumbaugh)(1995)
– Wirfs-Brock (1996)
– Fusion (1996) 
– RUP/UML(1997/1998)
Conceitos de Orientação a Objetos
• Origens:
– Linguagens de Programação (Simula)
– Inteligência Artificial (Representação da Informação)
• Princípio básico: Encapsulamento
– Abstração visível + Implementação escondida
• Vantagem: representação uniforme ao longo de todo o 
processo de desenvolvimento de software
Classes
• Representações computacionais de entidades ou processos do 
mundo real
• Classes são compostas de:
– Atributos – características (informações)
– Métodos – comportamento (processos)
• Classes instanciam objetos
– Todos os objetos de uma classe são idênticos no que diz 
respeito a suas características e comportamento
Classes
Objeto
• Possui um conjunto de serviço (interface) e sua 
implementação (estrutura de dados – atributos, e 
implementação de operações - método)
Mensagens
• A troca de mensagens como paradigma de comunicação
• A independência de objetos é enfatizada pela troca de 
mensagens
• Os dados de um objeto não podem ser manipulados ou vistos 
por outro objeto
• Uma mensagem é enviada para um objeto receptor, ativando 
um método específico
Herança
• Mecanismo que promove a reutilização de software
• Reconhecimento da similaridade entre classes de 
objetos, formando uma hierarquia
• Herança define uma relação do tipo “é-um”, onde 
uma classe compartilha a estrutura e o 
comportamento definidos em uma ou mais classes
Herança
Generalização vs Especialização
• Herança simples vs herança múltipla
• Superclasses representam abstrações 
genéricas
• Subclasses representam abstrações 
específicas, onde novas características e 
comportamentos podem ser adicionados ou 
modificados
Polimorfismo
• Objetos de diferentes classes podem reagir a 
uma mesma mensagem de forma diferente
• Cada classe implementa um método específico 
para uma mesma operação
• Possibilidade de definição de protocolos 
comuns
Desenvolvimento OO
• Desenvolvimento baseado em reutilização
• Desenvolvimento top-down vs bottom-up
• Processo iterativo, evolutivo e ágil
• Representação única durante todo o processo
• Dificuldades
– identificação de casos de uso
– classificação/organização de objetos/classes
– detalhamento do comportamento de 
objetos/classes
Concepção e Elaboração
• Artefatos:
– Listagem de Requisitos do Sistema
– Caso de Uso
– Arquitetura de Software
Modelo do Sistema
• Propósito do Sistema
• Identificação dos atores
• Diagrama de Casos de Uso
• Descrição dos Casos de Uso
• Diagrama de Classes
• Descrição das Classes
• Diagrama de Sequência
Arquitetura de N camadas
Arquitetura centralizada
• Dominantes até década de 80 como 
arquitetura corporativa
• Problema básico: interface não 
amigável
http://www.dsc.ufcg.edu.br/~jacques/cursos/j2ee/html/intro/intro.htm
Arquitetura em 2 camadas
• Sistemas em camadas surgiram para:
• Melhor aproveitar os PCs da empresa
• Oferecer sistemas com interfaces gráficas amigáveis
• Integrar o desktop e os dados corporativos
• Em outras palavras, permitiram aumentar a escalabilidade 
de uso de Sistemas de Informação
• Os primeiros sistemas cliente-servidor eram de duas 
camadas
• Camada cliente trata da lógica de negócio e da UI
• Camada servidor trata dos dados (usando um SGBD)
http://www.dsc.ufcg.edu.br/~jacques/cursos/j2ee/html/intro/intro.htm
Arquitetura em 2 camadas
• Sistemas em camadas surgiram para:
• Melhor aproveitar os PCs da empresa
• Oferecer sistemas com interfaces gráficas amigáveis
• Integrar o desktop e os dados corporativos
• Em outras palavras, permitiram aumentar a escalabilidade 
de uso de Sistemas de Informação
• Os primeiros sistemas cliente-servidor eram de duas 
camadas
• Camada cliente trata da lógica de negócio e da UI
• Camada servidor trata dos dados (usando um SGBD)
http://www.dsc.ufcg.edu.br/~jacques/cursos/j2ee/html/intro/intro.htm
Arquitetura em 3 camadas
• A arquitetura cliente/servidor em 2 camadas sofria de vários 
problemas:
• Falta de escalabilidade (conexões a bancos de dados)
• Enormes problemas de manutenção (mudanças na lógica de 
aplicação forçava instalações)
• Dificuldade de acessar fontes heterogêneas (legado CICS, 
3270, ...)
• Inventou-se a arquitetura em 3 camadas
• Camada de apresentação (UI)
• Camada de aplicação (business logic)
• Camada de dados
• Problemas de manutenção foram reduzidos, pois mudanças às 
camadas de aplicação e de dados não necessitam de novas 
instalações no desktop
http://www.dsc.ufcg.edu.br/~jacques/cursos/j2ee/html/intro/intro.htm
Arquitetura em 3 camadas
• A arquitetura cliente/servidor em 2 camadas sofria de vários 
problemas:
• Falta de escalabilidade (conexões a bancos de dados)
• Enormes problemas de manutenção (mudanças na lógica 
de aplicação forçava instalações)
• Dificuldade de acessar fontes heterogêneas (legado 
CICS, 3270, ...)
• Inventou-se a arquitetura em 3 camadas
• Camada de apresentação (UI)
• Camada de aplicação (business logic)
• Camada de dados
http://www.dsc.ufcg.edu.br/~jacques/cursos/j2ee/html/intro/intro.htm
Arquitetura em 3/4 camadas Web-Based
• A arquitetura em 3 camadas original sofre de problemas:
• A instalação inicial dos programas no desktop é cara
• O problema de manutenção ainda persiste quando há mudanças à camada de 
apresentação
• Não se pode instalar software facilmente num desktop que não está sob seu controle 
administrativo
• Em máquinas de parceiros
• Em máquinas de fornecedores
• Em máquinas de grandes clientes
• Em máquinas na Internet
• Então, usamos o Browser como Cliente Universal
• Conceito de Intranet
• A camada de aplicação se quebra em duas: Web e Aplicação
• Evitamos instalar qualquer software no desktop e portanto, problemas de manutenção
• Evitar instalação em computadores de clientes, parceiros, fornecedores, etc.
• Às vezes, continua-sea chamar isso de 3 camadas porque as camadas Web e Aplicação 
freqüentemente rodam na mesma máquina (para pequenos volumes)
http://www.dsc.ufcg.edu.br/~jacques/cursos/j2ee/html/intro/intro.htm
MVC
 Separar dados ou lógica de negócios (Model) da interface do 
usuário (View) e do fluxo da aplicação (Control)
 A ideia é permitir que uma mesma lógica de negócios possa ser 
acessada e visualizada através de várias interfaces.
 Na arquitetura MVC, a lógica de negócios (chamaremos de 
Modelo) não sabe de quantas nem quais interfaces com o 
usuário estão exibindo seu estado.
 Com as diversas possibilidades de interfaces que conhecemos 
hoje, a MVC é uma ferramenta indispensável para 
desenvolvermos sistemas
MVC na Web
MVC na Web
• Model:
– classes de lógica de negócio.
• View:
– páginas HTML, JSP e similares.
• Controller:
– Servlet que recebe as requisições HTTP, chama 
algum método de negócio e, dependendo do 
retorno, escolhe uma view e redireciona.
Analogia
Camadas MVC
Engenharia de Requisitos
“A Engenharia de Requisitos pode ser definida 
como um processo sistemático para o 
desenvolvimento de requisitos através de um 
processo interativo/cooperativo de análise do 
problema, documentando as observações 
resultantes e verificando a acurácia da 
compreensão obtida.” 
(Pohl, 1993)
Processo de ER
• Processo de descoberta, refinamento, especificação, 
modelagem e validação de requisitos do software
• Etapas:
– elicitação de requisitos
– análise e negociação
– especificação
– modelagem de requisitos
– validação
– gerência de requisitos
Especificação de Requisitos
• Produto da Engenharia de Requisitos
• Importância:
– A especificação formaliza as necessidades do usuário, 
atuando como ponte entre ele e os desenvolvedores
– Projeto e codificação perfeitos são de pouco uso quando 
existem erros nos requisitos
– Muitos erros são introduzidos nesta etapa e quanto mais 
tarde este erro é detectado maior será o custo para sua 
correção
Dificuldades
• Comunicação com o usuário
• Mudanças constantes (ex. Novos desafios, 
oportunidades, problemas e restrições)
• Previsão de situação futuras
• Entendimento completo do problema
• Seleção de alternativas tecnológicas
• Diferentes formas de representação
Grupos de Interesse
• Responsáveis pelo desenvolvimento
• Aqueles com interesse financeiro
• Responsáveis pela implantação e manutenção
• Operadores do sistema
Tipos e Categorias de Requisitos
• Funcional: características, capacidade, segurança
• Usabilidade: fatores humanos, recursos de ajuda, 
documentação
• Confiabilidade: freqüência de falhas, capacidade de 
recuperação, previsibilidade
• Desempenho: tempo de resposta, precisão, 
disponibilidade, uso de recursos
• Facilidade de suporte: facilidade de adaptação e de 
manutenção, internacionalização, configurabilidade
Técnicas de elicitação
• Exemplos:
– Entrevistas
– Seminários (workshops)
– Reuniões de Brainstorming
– Prototipação
– Casos de Uso
– Cenários
– Cartões de estória (story card)
Caso de Uso
• Um caso de uso (use case) apresenta uma função do sistema 
que provê ao usuário (ator) um resultado de valor observável
• Representa um conjunto de ações que o sistema deve realizar 
para atender a uma função
• Serve de base para comunicação entre clientes e 
desenvolvedores e para guiar o processo de desenvolvimento
Cenário
• Uma sequencia especifica de ações e interações entre atores e 
o sistema
• Instância de caso de uso
• História particular de uso de sistema
• Caso de uso é uma coleção de cenários que descrevem um 
ator usando um sistema para atingir um objetivo
Atores
• Atores representam qualquer elemento externo que 
possa interagir direta ou indiretamente com o sistema
• Podem ser:
– Outros sistemas
– Seres humanos
– Dispositivos de hardware
• Cada ator tem interesse em um conjunto de operações
Notação para casos de uso
• Existem 3 formatos diferentes e níveis de 
formalidade:
– Resumido – resumo sucinto de um 
parágrafo, geralmente o cenário de sucesso.
– Informal – formato informal de parágrafos. 
Múltiplos parágrafos que cobrem vários 
cenários.
– Completo – Todos os passos e variantes são 
escritos em detalhe e há seções de suporte.
Notação para casos de uso
• Exemplo formato reduzido:
– Processar venda: um cliente chega em um 
ponto de pagamento com itens que deseja 
adquirir. O caixa usa o sistema PDV para 
registrar cada item comprado. O sistema 
apresenta um total parcial e detalhes de linha 
de item. O cliente entra os dados sobre o 
pagamento, que são validados e, em seguida, 
registrados pelo sistema. O sistema atualiza o 
estoque. O cliente recebe um recibo do 
sistema e sai com os itens comprados.
Notação para casos de uso
• Exemplo formato informal:
– Tratar Devoluções
• Cenário de sucesso principal: um cliente chega a um posto de 
pagamento com itens a serem devolvidos. O caixa usa o sistema 
PDV para registrar cada item devolvido...
• Cenários alternativos:
– Se o cliente pagou a crédito e a transação de reembolso para 
estorno em sua conta de crédito é rejeitada, informe o 
cliente e o reembolse com dinheiro.
– Se o identificado do item não for encontrado no sistema, este 
notifica o caixa e sugere que entre manualmente o código do 
produto (talvez ele esteja corrompido).
– Se o sistema detecta uma falha para se comunicar com o 
sistema externos contabilidade
Notação para casos de uso
• Exemplo completo:
– Nome
– Atores
– Prioridade
– Status
– Pré-condição
– Pós-condição
– Pontos de Extensão
– Outros casos de uso utilizado
– Fluxo de eventos
Caso de Uso
Identificação de Atores e Casos de Uso
• A partir de documentos que descrevem o domínio de 
aplicação e/ou requisitos do sistema
• A partir de entrevistas com especialistas do domínio 
e/ou clientes
• Algumas perguntas
– Quem utiliza o sistema e como?
– Quem obtém ou fornece informações ao sistemas?
– Quem mantém o sistema e como?
– Que outros sistemas interagem com este?
Exemplo
Relações entre Casos de Uso
• São unidirecionais e representadas por uma seta
• Relação de inclusão:
– Diversos casos de uso podem compartilhar o mesmo 
comportamento
– O comportamento é, então, separado em um caso de 
uso específico e uma relação de inclusão é estabelecida
• Relação de generalização e extensão:
– Indica o comportamento opcional/alternativo, 
dependente de condição(ponto de variação)
Relações entre Casos de Uso
Caso de Uso Essencial e Concreto
• Um caso de uso essencial apresenta uma 
narrativa no nível da intenção do usuário e das 
responsabilidades do sistema e não as suas 
ações concretas
• Um caso de uso concreto detalha as decisões 
sobre interface ou tecnologia utilizada para a 
realização das ações
Caso de Uso
Diagrama de caso de uso e relacionamentos 
entre casos de uso são secundários no 
trabalho de definição dos casos de uso. Casos 
de uso são documentos de texto. Fazer o 
trabalho de definição de caso de uso significa 
escrever texto.
Diagrama de atividades
• O Diagrama de atividade é um diagrama 
definido pela Linguagem de Modelagem 
Unificada(UML), e representa os fluxos 
conduzidos por processamentos. É 
essencialmente um gráfico de fluxo, 
mostrando o fluxo de controle de uma 
atividade para outra. 
Exemplo de caso de uso
Identificação UC_01
Função Retirar Dinheiro do caixa eletrônico
Atores Cliente, Caixa eletrônico
Prioridade Essencial
Pré-condição Cliente precisa ter em mãos o cartão do 
banco
Pós-condição Dinheiro sacado com sucesso
Fluxo
Principal
•Cliente insere cartão no dispositivo
•Cliente digita a senha
•Máquina autoriza login [FS001]
•Cliente digita o montante
•Máquina checa o saldo [FS002]
•Máquina debita o dinheiro sacado do 
saldo inicial
•Máquina dispõe cédulas para cliente
•Máquina mostra na tela no novo saldo
•Máquina ejeta cartão
•Cliente retira cartão
Fluxo 
Secundário 
[FS001]
•Senha digitada é inválida
•Máquina ejeta cartão
•Cliente retira cartão
Fluxo 
Secundário[FS002]
•Saldo é menor que o 
montante requerido
•Máquina mostra na tela o 
saldo
•Máquina ejeta o cartão
•Cliente retira o cartão
Realizar um saque no caixa eletrônico
Diagrama de atividades
ATÉ O PRÓXIMO ENCONTRO!