Aula11

Prévia do material em texto

Detalhamento de Comportamento e Fluxo do Sistema 
Introdução à Análise e Modelagem de Sistemas 
A modelagem de sistemas desempenha um papel fundamental no desenvolvimento de 
software, permitindo visualizar as interações entre usuários e componentes do sistema, o 
que facilita o entendimento e gestão da complexidade do projeto. O objetivo deste capítulo 
é aprofundar o detalhamento dos requisitos e processos que já foram identificados 
previamente, abordando técnicas de modelagem que ajudam a traduzir necessidades e 
funcionalidades em representações claras e comunicáveis. A modelagem não contempla 
aqui o levantamento (ou elicitação) dos requisitos, mas sim seu detalhamento e 
organização. Para isso, utilizaremos a UML (Unified Modeling Language) como linguagem 
padrão, pois ela fornece instrumentos para representar tanto a estrutura quanto o 
comportamento dos sistemas. A UML se consolidou como referência por sua flexibilidade e 
padronização, sendo amplamente utilizada para comunicar arquiteturas e funcionalidades 
em projetos reais. A UML é uma linguagem de modelagem visual que fornece uma maneira 
padrão de visualizar o design de um sistema. Ela é usada para criar diagramas que 
representam diferentes aspectos de um sistema, como sua estrutura, comportamento e 
interações. A UML não é uma metodologia, mas sim uma linguagem que pode ser usada 
com várias metodologias de desenvolvimento de software. 
Análise de Casos de Uso: Fluxo Principal e Alternativos 
O que são Casos de Uso? 
Os casos de uso são uma técnica que permite identificar e organizar as funções que cada 
usuário ou sistema externo executa via sistema, representando graficamente ou 
textualmente os requisitos encontrados. Eles capturam as funcionalidades sob a 
perspectiva do usuário, detalhando as interações entre atores (usuários ou outros 
sistemas) e o sistema, de modo claro e objetivo. O principal propósito dos casos de uso é 
sistematizar os requisitos, funcionando como um “contrato de comportamento”: descrevem 
como um ator utiliza o sistema para alcançar uma meta específica. Os casos de uso podem 
ser criados inicialmente de forma mais geral e, conforme o projeto avança, detalhados para 
maior clareza sobre fluxos e exceções. 
 
Elementos do Diagrama de Casos de Uso (UML) 
• Ator: Define o papel que interage com o sistema, podendo ser pessoas ou outros 
sistemas que buscam atingir uma ou mais metas específicas. 
• Caso de Uso: Representa uma funcionalidade e é simbolizado por uma elipse, 
detalhando a sequência de ações necessárias para atender à necessidade do ator. 
• Fronteira do Sistema: Um retângulo que delimita o escopo do sistema estudado, 
diferenciando o que está (ou não) sob controle do sistema. 
• Relacionamentos Especiais: 
– Associação: Conexão entre ator e caso de uso, indicando que há interação entre 
ambos. 
– Generalização/Especialização: Relação de herança entre atores ou casos de 
uso, onde funções especializadas herdam características gerais. 
– Inclusão (): Utilizada quando um caso de uso incorpora comportamento 
comum a vários outros casos. 
– Extensão (): Quando um caso de uso acrescenta funcionalidade a outro sob 
condições específicas. 
Detalhamento de Casos de Uso (Fluxo Principal e Alternativos) 
Para ilustrar, vamos considerar um exemplo de um sistema de caixa eletrônico (ATM). Um 
caso de uso principal seria “Sacar Dinheiro”. 
Caso de Uso: Sacar Dinheiro 
Ator: Cliente do Banco 
Fluxo Principal (Cenário de Sucesso): 
1. O cliente insere o cartão no caixa eletrônico. 
2. O sistema solicita a senha. 
3. O cliente digita a senha. 
4. O sistema valida a senha. 
5. O sistema exibe as opções de transação. 
6. O cliente seleciona a opção “Saque”. 
7. O sistema solicita o valor do saque. 
8. O cliente digita o valor. 
9. O sistema verifica se o saldo é suficiente. 
10. O sistema libera o dinheiro. 
11. O sistema ejeta o cartão. 
12. O cliente retira o dinheiro e o cartão. 
Fluxos Alternativos: 
• Senha inválida: Se o cliente digitar a senha incorreta, o sistema deve informar o erro e 
permitir mais duas tentativas. Após a terceira tentativa incorreta, o cartão é retido e 
bloqueado. 
• Saldo insuficiente: Se o cliente solicitar um valor maior do que o saldo disponível, o 
sistema deve exibir uma mensagem informando o problema e permitir que o cliente 
digite um novo valor ou cancele a operação. 
• Valor de saque inválido: Se o cliente digitar um valor que não seja passível de ser 
fornecido com as notas disponíveis, o sistema deve informar o erro e solicitar um novo 
valor. 
O Foco Essencial na descrição de um caso de uso é sempre descrever “o que” acontece 
entre o usuário e o sistema, sem entrar em detalhes de implementação, tecnologia de 
interface (“menus”, “janelas”) ou processamento interno. O sistema deve ser visto como 
uma “caixa-preta”. Os passos devem indicar Eventos e Respostas: os eventos de sistema 
(informação dos atores para o sistema) e as respostas de sistema (informação do sistema 
para os atores). 
• Diagramas Complementares (para detalhamento do comportamento): 
– Diagrama de Atividades (UML): Ideal para casos de uso complexos, 
detalhando o fluxo funcional e possíveis processos paralelos ou decisões no 
caminho do processamento. 
– Diagrama de Sequência (UML): Explicita como objetos trocam mensagens ao 
longo do tempo, elaborado a partir de casos de uso para detalhar interações 
sistêmicas. 
 
 
 
 
Modelagem de Processos de Negócio (BPMN) AS-IS/TO-BE 
Conceitos Fundamentais de Processos de Negócio 
Um processo de negócio é uma sequência de atividades executadas para atingir um objetivo 
que agrega valor ao cliente. A modelagem de processos permite visualizar “como as coisas 
acontecem dentro da organização (fluxo de trabalho) e como elas são documentadas”. 
Notação BPMN (Business Process Modeling Notation) 
A BPMN é uma notação que evoluiu dos fluxogramas, permitindo um desenho mais 
aprimorado e com maior qualidade de informação para o acompanhamento diário. Seus 
elementos chave incluem: 
• Atividades: Representam o trabalho a ser realizado, podendo ser tarefas, 
subprocessos ou processos (ex: “emitir o pedido”). 
• Eventos: Ocorrências que influenciam o fluxo do processo, marcando o início e o 
término. 
• Gateways: Controlam o fluxo de sequência, determinando decisões, bifurcações e 
uniões de caminhos (ex: verificação de “cliente com saldo?”). 
• Conectores: Ligam os elementos (atividades, eventos, gateways) para demonstrar um 
caminho. 
• Piscinas (Pools) e Raias (Swimlanes): Piscinas delimitam organizações ou 
participantes, e raias representam papéis ou departamentos dentro de uma piscina. 
 
 
Modelagem AS-IS (Estado Atual) 
O objetivo da modelagem AS-IS é compreender o estado atual do processo, ou seja, “como 
as coisas são”. O diagrama AS-IS mostra a execução das atividades do processo de negócio, o 
que fornece uma base para o diagnóstico de problemas e oportunidades de melhoria. 
Modelagem TO-BE (Estado Futuro) 
A modelagem TO-BE visa propor mudanças e melhorias nos processos, vislumbrando 
“como as coisas deveriam ser”. O modelo AS-IS subsidia as informações para o diagnóstico 
que permite o redesenho dos processos para o estado futuro (“to be”). Utilizando os 
elementos do BPMN, o novo fluxo de trabalho e processos de negócio são representados 
após as otimizações. 
Exemplo de Modelagem AS-IS e TO-BE: 
Imagine um processo de “Aprovação de Despesas” em uma empresa. 
Processo AS-IS (Atual): 
1. O funcionário preenche um formulário de despesas em papel. 
2. O formulário é entregue ao gerente para aprovação. 
3. O gerente assina o formulário. 
4. O formulário é enviado para o departamento financeiro. 
5. O departamento financeiro processa o reembolso. 
Problemas identificados: Processo lento, sujeito a erros e extravios de documentos. 
Processo TO-BE (Futuro): 
1. O funcionário preenche um formulário de despesas online em um sistema. 
2. O sistema envia uma notificação para o gerente. 
3. O gerente aprovaa despesa online. 
4. O sistema envia a despesa aprovada para o departamento financeiro. 
5. O sistema de folha de pagamento processa o reembolso automaticamente. 
Melhorias: Processo mais rápido, automatizado, com menos erros e com rastreabilidade. 
Priorização de Fluxos Críticos 
Importância 
Em sistemas complexos, é difícil definir totalmente os requisitos e necessidades do usuário 
no início, e nem todos os casos de uso ou processos podem ser detalhados/implementados 
simultaneamente. A priorização garante que o esforço seja direcionado para as 
funcionalidades e processos mais importantes. 
Critérios e Métodos para Priorização 
Além dos critérios mencionados, existem métodos mais estruturados para a priorização de 
requisitos e fluxos, como: 
• MoSCoW: Classifica os requisitos em quatro categorias: Must-have (essencial), 
Should-have (importante), Could-have (desejável) e Won’t-have (não terá nesta 
versão). 
• Matriz de Priorização: Uma ferramenta visual que ajuda a classificar os requisitos 
com base em múltiplos critérios, como urgência e impacto. Por exemplo, uma matriz 
2x2 pode ser usada para classificar os requisitos em quatro quadrantes: alta 
urgência/alto impacto, alta urgência/baixo impacto, baixa urgência/alto impacto e 
baixa urgência/baixo impacto. 
• Modelo de Kano: Foca na satisfação do cliente e classifica os requisitos em três 
categorias: básicos (esperados pelo cliente), de desempenho (quanto mais, melhor) e 
de encantamento (inesperados, mas que geram grande satisfação). 
Os critérios para priorização incluem: 
• Alinhamento Estratégico: Focar em processos e casos de uso que estão ligados aos 
objetivos estratégicos da empresa. 
• Criticidade para o Negócio: Identificar quais funcionalidades ou processos são 
essenciais para o funcionamento do negócio (ex: o processo de vendas pode ser um 
processo prioritário). 
• Complexidade e Risco: Priorizar casos de uso mais complexos ou com maior risco. 
• Frequência de Uso e Impacto: Considerar a frequência com que o fluxo é utilizado e a 
criticidade das funções executadas, pois isso impacta o trabalho de teste e a alocação 
de casos de teste. 
• Categorização: Classificar requisitos/fluxos como “essenciais”, “importantes” ou 
“desejáveis” para auxiliar na tomada de decisão. 
• Cobertura de Requisitos: Verificar se todos os requisitos funcionais estão associados 
a pelo menos um caso de uso para evitar lacunas. 
	Detalhamento de Comportamento e Fluxo do Sistema 
	Introdução à Análise e Modelagem de Sistemas 
	Análise de Casos de Uso: Fluxo Principal e Alternativos 
	O que são Casos de Uso? 
	Detalhamento de Casos de Uso (Fluxo Principal e Alternativos)