Engenharia de Requisitos Alexandre Vasconcelos amlvcin ufpe br

Engenharia de Requisitos Alexandre Vasconcelos (amlv@cin. ufpe. br) 1

Objetivos n n Descrever as principais atividades da engenharia de requisitos Introduzir técnicas para a elicitação e análise de requisitos Descrever validação de requisitos Discutir o gerenciamento de requisitos 2

O Processo da Engenharia de Requisitos Estudo de viabilidade Elicitação de requisitos e análise Especificação de requisitos Relatório de viabilidade Validação de requisitos Requisitos do usuário e do sistema Modelos do sistema Documento de requisitos 3

Estudo de Viabilidade n n n O que é um estudo de viabilidade? O que estudar e concluir? Benefícios e custos Análise de custo/benefício Alternativas de comparação 4

Estudo de Viabilidade n Estudo que indica se o esforço em desenvolver a idéia vale a pena n n Visa tanto a tomada de decisão Como a sugestão de possíveis alternativas de solução 5

Estudo de Viabilidade n Deve oferecer informações para ajudar na decisão n n Se o projeto pode ou não ser feito Se o produto final irá ou não beneficiar os usuários interessados Escolha das alternativas entre as possíveis soluções Há uma melhor alternativa? 6

O Que Estudar? n Sistema organizacional apresentado n n Problemas com o sistema apresentado n n Usuários, políticas, funções, objetivos, etc. Inconsistências, funcionalidades inadequadas, performance, etc. Objetivos e outros requisitos para o novo sistema n O que precisa mudar? 7

O Que Estudar? n Restrições n n Alternativas possíveis n n Incluindo requisitos não-funcionais do sistema (superficialmente) Sistema atual é geralmente uma das alternativas Vantagens e desvantagens das alternativas 8

Testes de Viabilidade n Operacional n Medida do grau de adequação da solução para a organização n n Avaliação de como as pessoas se sentem sobre o sistema/projeto Técnica n Avaliação da praticidade de uma solução técnica específica e a disponibilidade dos recursos técnicos e dos especialistas 9

Testes de Viabilidade n Cronograma n n Avaliação de quão razoável está o cronograma do projeto Econômica n Avaliação de custo-eficiência de um projeto ou solução n Conhecida como análise de custo/benefício 10

Viabilidade Operacional n n Avalia a urgência do problema (visão e fases de estudo) ou a aceitação da solução (definição, seleção, aquisição, e fases do projeto) Há dois aspectos da viabilidade operacional a serem considerados n n O problema vale a pena ser resolvido ou a solução proposta para o problema funcionará? Como o usuário final e a gerência sentem-se sobre o problema (solução)? 11

Viabilidade Técnica n n n A solução ou a tecnologia proposta é prática? Já possuímos a tecnologia necessária? Já possuímos o conhecimento técnico necessário? 12

Viabilidade de Cronograma n Dado nosso conhecimento técnico, os prazos dos projetos são razoáveis? n Alguns projetos são iniciados com prazos específicos n n Você precisa determinar se os prazos são obrigatórios ou desejáveis Se são mais desejáveis que obrigatórios, o analista pode propor outros cronogramas 13

Viabilidade Econômica n Talvez a mais crítica n n Durante as fases iniciais do projeto, a análise da viabilidade econômica consiste em julgar se os possíveis benefícios de solucionar o problema são ou não vantajosos Tão logo os requisitos específicos e soluções sejam identificados, o analista pode levar em consideração os custos e benefícios de cada alternativa n Isso é chamado de análise de custo-benefício 14

Tipos de Custos n Custos de desenvolvimento de sistemas n n n Desenvolvimento e aquisição Custos de instalação e de conversão Custos operacionais (contínuo) n n Manutenção Pessoal 15

Análise Custo-Benefício n Há três técnicas principais n n n Análise do retorno financeiro (payback analysis) Retorno do investimento (return on investments) Valor atual líquido (Net present value) 16

Análise de Retorno do Investimento n n A técnica de análise de retorno do investimento (ROI) compara os benefícios das diferentes soluções ou projetos O ROI para uma solução ou projeto é a taxa percentual que mede a relação entre a quantia que a empresa obtém de retorno ao seu investimento e a quantia investida 17

Análise de Retorno do Investimento n O ROI para uma solução ou projeto potencial é calculado como a seguir: n n ROI = (Benefícios totais - Custos totais) / Custos totais ROI = valor atual líquido / Custos totais n n n Ex: ROI = (22508, 64 -17321, 20)/ 17321, 20= 29, 95% EX: ROI = 5187, 44/ 17321, 20 = 29, 95% A solução que oferecer o ROI mais alto é a melhor alternativa 18

Matriz de Viabilidade n n Como nós comparamos alternativas quando existem vários critérios de seleção e nenhuma das alternativas é superior em todos os aspectos? Use uma Matriz de Análise de Viabilidade! 19

Relatório de Viabilidade n Após o esforço inicial, discutido anteriormente, deve-se elaborar um relatório de viabilidade n n Para cada aspecto apresentado, deve haver seção de avaliação Deve haver uma seção conclusiva sobre a melhor alternativa ou que o sistema não é viável 20

Exercício n Determine a viabilidade de (+ROI): n n n 1. Sistema para uma padaria de pequeno porte (Só caixa, no balcão também, etc. ); 2. Sistema inteligente de preenchimento do IRPF pela própria pessoa física; 3. Sistema para gerar alocação de docentes, salas, horários, local de forma otimizada. 21

Elicitação de requisitos e análise n Esta atividade divide-se em dois esforços maiores: n Elicitação dos requisitos em si n n Técnicas de elicitação Análise do que foi elicitado n Processo de análise 22

Que é um requisito? n Tanto pode ser n n n Uma declaração abstrata de alto nível de um serviço Como uma restrição do sistema Quanto uma especificação funcional matemática detalhada 23

Elicitação de Requisitos n n n Também denominada de descoberta de requisitos Envolve pessoal objetivando descobrir o domínio de aplicação, serviços que devem ser fornecidos bem como restrições Deve envolver usuários finais, gerentes, pessoal envolvido na manutenção, especialistas no domínio, etc. (Stakeholders). 24

Visão dos Requisitos n Requisitos do Usuário n n Declarações em linguagem natural com diagramas de serviços que o sistema deve oferecer e suas restrições operacionais. Escrito para os clientes Requisitos do Sistema n Documento estruturado com descrições detalhadas sobre os serviços do sistema. Contrato entre cliente e fornecedor 25

Tipos de Requisitos n Requisitos Funcionais n Requisitos Não-Funcionais n Requisitos de Domínio 26

Requisitos Funcionais n n Descreve funcionalidade e serviços do sistema Depende do n n n Tipo do software Usuários esperados Tipo do sistema onde o software é usado 27

Exemplos de R. F. n n n [RF 001] Usuário pode pesquisar todo ou um sub-conjunto do banco de dados [RF 002] Sistema deve oferecer visualizadores apropriados para o usuário ler documentos armazenados [RF 003] A todo pedido deve ser associado um identificador único (PID), o qual o usuário pode copiar para a área de armazenamento permanente da conta 28

Exercício n Dê alguns exemplos de R. F. s para: n n n 1. Sistema da padaria de pequeno porte; 2. Sistema inteligente de preenchimento do IRPF; 3. Sistema de alocação docente. 29

Requisitos Não-Funcionais n n n Definem propriedades e restrições do sistema (tempo, espaço, etc) Requisitos de processo também podem especificar o uso de determinadas linguagens de programação, método de desenvolvimento Requisitos não-funcionais podem ser mais críticos que requisitos funcionais. Não satisfaz, sistema inútil. 30

Requisitos Não-Funcionais n n Devido à sua própria definição, requisitos não-funcionais são esperados mensuráveis Assim, deve-se associar forma de medida/referência a cada requisito não-funcional elicitado 31

Medidas de Requisitos (Não-Funcionais) Propriedade Velocidade Tamanho Facilidade de uso Confiabilidade Robustez Portabilidade Medida Transações processadas/seg Tempo de resposta do usuário/evento K bytes No de chips de RAM Tempo de treinamento No de quadros de ajuda Tempo médio de falhas Probabilidade de indisponibilidade Taxa de ocorrência de falhas Tempo de reinício após falha Percentual de eventos causando falhas Probabilidade de corrupção de dados após falha Percentual de declarações dependentes do destino No de sistemas destino 32

Classificação de R. N. F. n Requisitos do Produto n n Requisitos Organizacionais n n Produto deve comportar-se de forma particular (velocidade de execução, confiabilidade, etc. ) Conseqüência de políticas e procedimentos organizacionais (padrões de processo usados, requisitos de implementação, etc. ) Requisitos Externos n Conseqüência de fatores externos ao sistema e ao processo de desenvolvimento (legislação, etc. ) 33

Exemplos de R. N. F. n Requisitos do Produto n n Requisitos Organizacionais n n [RNF 001] Toda consulta ao B. D. , baseada em código de barras, deve resultar em até 5 s [RNF 002] Todos os documentos entregues devem seguir o padrão de relatórios XYZ-00 Requisitos Externos n [RNF 003] Informações pessoais do usuário não devem ser vistas pelos operadores do sistema 34

Exercício n Dê alguns exemplos de R. N. F. s para: n n n 1. Sistema da padaria de pequeno porte; 2. Sistema inteligente de preenchimento do IRPF; 3. Sistema de alocação docente. 35

Requisitos de Domínio n n n Derivados do domínio da aplicação e descrevem características do sistema e qualidades que refletem o domínio Podem ser requisitos funcionais novos, restrições sobre requisitos existentes ou computações específicas Se requisitos de domínio não forem satisfeitos, o sistema pode tornar-se não prático 36

Requisitos de Domínio (Problemas) n Entendimento n n n Requisitos são descritos na linguagem do domínio da aplicação Não é entendido pelos engenheiros de software que vão desenvolver a aplicação Implicitude n Especialistas no domínio entendem a área tão bem que não tornam todos os requisitos de domínio explícitos 37

Requisitos de Domínio (Exemplo 1) n A desaceleração do trem deve ser computada através da fórmula Dtrem=Dcontrole+Dgradiente onde. . . 38

Exercício n Dê alguns exemplos de domínio para: n n n 1. Sistema da padaria de pequeno porte; 2. Sistema inteligente de preenchimento do IRPF; 3. Sistema de alocação docente. 39

Requisitos Usuário Funcionais Produto =df Sistema Não-funcionais Organização Domínio Externo 40

Técnicas de Elicitação n n n Entrevistas Questionários Casos de Uso Jogo de Funções Brainstorming Workshop de Requisitos 41

Entrevistas n Técnica direta n n Pode ser usada na análise do problema e na elicitação de requisitos Objetivo n Entender os problemas reais e soluções potenciais das perspectivas dos usuários, clientes, e outros stakeholders 42

Entrevistas n n n Quem são o cliente e o usuário? Possuem necessidades diferentes? Quais são suas n n n Capacidades Backgrounds Ambientes, etc. Qual é o problema? Como é resolvido atualmente? 43

Entrevistas n n n Qual a razão para resolvê-lo? Qual o valor de uma solução bemsucedida? Onde mais uma solução pode ser encontrada? Note que algumas dessas perguntas já foram feitas no estudo de viabilidade. 44

Questionários n Aplicabilidade a mercados específicos n n Hipóteses n n Onde perguntas são bem definidas Perguntas relevantes podem ser decididas antecipadamente Leitor ouve da maneira desejada Suprime o que é bom sobre análise Úteis após uma entrevista inicial 45

Casos de Uso n n n Discuta com o cliente o que o sistema fará Identique quem interage com o sistema Identique interfaces o sistema terá 46

Casos de Uso n n n Verifique se não há requisitos faltando Verifique os desenvolvedores entendem os requisitos Vantagem é ter apelo visual dos requisitos mais relevantes do cliente 47

Jogo de Funções n Engenheiro de requisitos n Assume a função do usuário ou cliente n n Entender o domínio do problema Cliente n Assume a função do usuário n Entender os problemas que podem passar 48

Brainstorming n Regras para Brainstorming n n n Estabeleça o objetivo da sessão Gere quantas idéias for possível Deixe sua imaginação livre Não admita críticas ou debates Ajuste e combine as idéias 49

Workshop de Requisitos n n n Põe todos os stakeholders juntos por um período intensivo (focado) Facilitador conduz a reunião Todos têm sua vez de falar Resultados são disponíveis imediatamente Provê um ambiente para aplicar outras técnicas de elicitação 50

Exercício n Quais técnicas poderiam ser usadas em: n n n 1. Sistema da padaria de pequeno porte; 2. Sistema inteligente de preenchimento do IRPF; 3. Sistema de alocação docente. 51

Análise de Requisitos Definição e especificação de requisitos Documento de requisitos 7 8 Validação dos requisitos Entrada do processo Entendimento do domínio Coleta de requisitos 6 1 Atrib. Prioridade 5 4 2 3 Classificação Resolução de conflito 52

Entendimento do Domínio n n Desenvolver sistemas envolve domínios além de software e hardware Podemos ter que entender sobre n n Contabilidade Saúde Supermercados Etc. 53

Coleta de Requisitos n n n Como vimos anteriormente, a coleta de requisitos é feita através de técnicas Nesta etapa, os requisitos são simplesmente documentados à medida que são coletados Resulta em documento preliminar (draft) 54

Classificação dos Requisitos n n Esta etapa consiste basicamente em agrupar os diversos requisitos coletados em categorias (clusters) bem-definidos Por exemplo n Deve ser possível consultar o preço de uma mercadoria n A consulta deve retornar uma resposta em no máximo 5 s 55

Problema da Análise de Requisitos n n n Stakeholders em geral não sabem o querem Stakeholders expressam requisitos em sua terminologia Stakeholders diferentes podem gerar requisitos conflitantes 56

Problema da Análise de Requisitos n n Fatores políticos e organizacionais podem influenciar os requisitos do sistema Requisitos mudam durante o processo de análise. Stakeholders novos podem surgir e o ambiente de trabalho muda 57

Resolução de Conflitos n n É normal que ocorram requisitos conflitantes Por exemplo n n n R-23: O sistema deve. . . R-45: O sistema não deve. . . Cliente/usuário deve ser consulta para resolver conflitos (ambigüidades) 58

Atribuição de Prioridade n n n Alguns requisitos são mais urgentes que outros É essencial determinar a prioridade dos requisitos junto ao cliente Requisitos de maior prioridade são considerados em primeiro lugar 59

Prioridade n Requisitos podem ser vistos em três classes distintas n n Essenciais Importantes Desejáveis Em princípio, sistema deve resolver todos os requisitos de essenciais para desejáveis 60

Exemplo de Prioridade n [RF 001] Consulta X ao B. D. deve retornar dados A, B, C n n [RNF 001] Consulta X ao B. D. deve visualizar dados segundo padrão Y n n Prioridade: Essencial Prioridade: Importante [RNF 010] Consulta X ao B. D. deve usar cores azuis nos resultados n Prioridade: Desejável 61

Validação dos Requisitos n n n Será que realmentendi o que o cliente deseja? Devo me certificar de que não houve falha em nossa interação (comunicação) Há diversas técnicas de validação 62

Validação de Requisitos n n Demonstrar que os requisitos definem o sistema que o cliente realmente deseja Custos com erros de requisitos são altos n Consertar um erro de requisitos após entrega do sistema pode custar mais de 100 vezes o custo de um erro de implementação 63

Técnicas de Validação de Requisitos n Revisões de Requisitos n n Prototipação n n Uso de modelo executável do sistema para avaliar requisitos Geração de Casos de Teste n n Análise manual sistemática dos requisitos Desenvolver testes específicos para os requisitos para avaliá-los Análise de Consistência Automática n Avaliar uma especificação dos requisitos 64

Gerenciamento de Requisitos n Gerenciamento de requisitos é o processo de controlar as mudanças dos requisitos durante n n O processo da engenharia de requisitos E desenvolvimento do sistema 65

Gerenciamento de Requisitos n Requisitos são inevitavelmente incompletos e inconsistentes n n Requisitos novos surgem durante o processo de acordo com mudanças necessidades do negócio e um entendimento melhor do sistema é desenvolvido Diferentes pontos de vista têm diferentes requisitos e esses geralmente são contraditórios 66

Rastreamento n n Responsável por dependências entre requisitos, suas origens e projeto do sistema Rastreamento de Origem n Associação entre requisitos e stakeholders que propuseram tais requisitos 67

Rastreamento n Rastreamento de Requisitos n n Rastreamento de Projeto n n Associação entre requisitos dependentes Associação dos requisitos com o projeto Usar hipertexto ou referência cruzada n Ou matriz de rastreamento 68

Rastreamento 1. Requisitos Produto (Caracter. ) Rastrear requisitos do usuário nos do sistema Req A 2. Rastrear requisitos no projeto 1 Requisitos Detalhados (Casos de Uso) 3. Rastrear requisitos nos procedimentos de teste Req B 2 3 Projeto Teste Modelos Suítes Teste 4 4. Rastrear requisitos do usuário no plano Doc. Usuário Plano 69

Rastreamento: Análise de Impacto Req A antes Req A depois “if return value > $5” “if return value > $2” Req B Req C n n Req B Req C Links dos requisitos devem ser marcados como “revisar” Links “revisar” devem ser analisados 70

Documento de Requisitos n Fonte: IEEE/ANSI (830 -1998) n 1. Introdução n n n 1. 1 Propósito do documento 1. 2 Escopo do sistema 1. 3 Definições, acrônimos e abreviaturas 1. 4 Referências 1. 5 Descrição do resto do documento 71

Documento de Requisitos n Fonte: IEEE/ANSI (830 -1998) n 2. Descrição geral n n n 2. 1 Perspectiva do produto 2. 2 Funções do produto 2. 3 Características dos usuários 2. 4 Restrições gerais 2. 5 Assertivas e dependências 72

Documento de Requisitos n Fonte: IEEE/ANSI (830 -1998) n 3. Requisitos específicos n n n requisitos funcionais, não-funcionais, GUI com o usuário: n funcionalidade, interfaces externas, desempenho, restrições, atributos do sistema, caract. qualidade, . . . Apêndices Índice 73

Diagramas de Casos de Uso Alexandre Vasconcelos (amlv@cin. ufpe. br) 74

Objetivos n n Introduzir conceitos de use case, ator e fluxo de eventos Apresentar sub-fluxos de eventos Discutir sobre identificação, evolução e organização de use cases Apresentar notação UML para reusar atores e use cases 75

Use Case n Seqüência de ações, executada pelo sistema, que gera um resultado n Função n De valor observável E para ator particular Procedimento computacional/algorítmico atômico 76

Use Case e Ator n Alguém ou alguma coisa (fora do sistema) que interage com o sistema Emissor/Receptor 77

Emissor Receptor Função Resultado de Valor Observável Ator Particular Use Case e Ator 78

Use Case e Ator n n A descrição de um use case define o que o sistema faz quando o use case é realizado A funcionalidade do sistema é definida por um conjunto de use cases, cada um representando um fluxo de eventos específico 79

Use Case e Ator Descrição Passo 1 Passo 2 … Passo N Emissor Função 80

Exemplo de Use Case e Ator n Cliente de banco pode usar um caixa automático para n n n sacar dinheiro, transferir dinheiro ou consultar o saldo da conta Ator: Cliente Use cases: Sacar dinheiro, transferir dinheiro e consultar saldo 81

Exemplo de Use Case e Ator Valor de resultado observável Transferir dinheiro Sacar dinheiro Consultar saldo Cliente 82

Identificando Use Cases n n Em geral, difícil decidir entre um ou vários use cases Por exemplo, seriam use cases n n n Inserir cartão em um Caixa Automático? Entrar com a senha? Receber o cartão de volta? 83

Identificando Use Cases n n Representar valor observável para ator Pode-se determinar n n De interações (seqüência de ações) com o sistema que resultam valores para atores Satisfaz um objetivo particular de um ator que o sistema deve prover 84

Identificando Use Cases n Facilitar gerenciamento durante ciclo de desenvolvimento n A razão para agrupar funcionalidades e chamá-las de use cases 85

Exercício n Tenho um sistema que é acionado 2 vezes por dia (às 10: 20 hs e 17: 20 hs), enviando-me um SMS. Também tenho como obter resultado semelhante acessando tal funcionalidade a partir de meu celular (web browser). Crie os casos de uso correspondentes. 86

Evolução de Use Cases n Inicialmente use cases são simples n n Mas com a sedimentação da modelagem n n Apenas esboço sobre funcionamento é suficiente Descrição mais detalhada do fluxo de eventos faz-se necessária Fluxo de eventos deve ser refinado n Todos os stakeholders envolvidos devem estar de acordo com a descrição 87

Organizando Use Cases n Sistema pequeno não demanda estruturação n n Exemplo, seis use cases, com dois/três atores Já sistemas maiores requerem princípios de estruturação e organização n Caso contrário, planejamento, atribuição de prioridades, etc. , podem se tornar 88 difíceis

Pacote de Use Case n n Primeiro esforço de estruturação Agrupam-se use cases relacionados em único container 89

Pacote de Use Cases Clientes : : Atendimento 90

Reuso em Use Cases n Comportamento comum a mais de dois use cases (ou forma parte independente) n n Pode-se modelar como use case para ser reusado Há três possibilidades n n n Inclusão Extensão Generalização/Especialização 91

Inclusão n Vários use cases possuem texto de fluxo de eventos n n n Comum/idêntico Sempre usado Equivalente a fatoração feita em programação através de subprogramas n #include da linguagem C 92

Inclusão n Como exemplo, tanto “Sacar dinheiro” quanto “Consultar saldo” necessitam da senha n n Pode-se criar novo use case “Autenticar usuário” e incluí-lo Mas atenção n n NÃO SE DEVE CRIAR USE CASES MÍNIMOS Deve haver ganho no reuso 93

Inclusão << include >> Sacar dinheiro Autenticar usuário << include >> Consultar saldo 94

Inclusão n Descrição de Consultar saldo n Fluxo de Eventos Principal: n include (Autenticar usuário). Sistema pede a Cliente que selecione tipo de conta (corrente, etc). . 95

Extensão n Use case pode ser estendido por outro n n Extensão de funcionalidade/Caso excepcional Extensão ocorre em pontos específicos n Pontos de extensão 96

Extensão n Há também inclusão de texto (fluxo de eventos) n n Porém sob condições particulares Pode ser usada para n n n Simplificar fluxos de eventos complexos Representar comportamentos opcionais Lidar com exceções 97

Extensão << extend >> (urgente) Atendimento de urgência Atendimento Pontos de extensão urgente 98

Extensão n Descrição de Atendimento n Fluxo de Eventos Principal: n Colete os itens do pedido. (urgente). Submeta pedido para processamento. 99

Especialização n Use case pode especializar outro n n Adição/refinamento do fluxo de eventos original Especialização permite modelar comportamento de estruturas de aplicação em comum 100

Especialização Atendimento de urgência Atendimento Cliente comercial Cliente 101

Fluxo de Eventos n Parte mais importante de um use case n n Atividade de requisitos Define a seqüência de ações entre o ator e o sistema 102

Fluxo de Eventos n Geralmente em linguagem natural n n Uso preciso de termos definidos no glossário de acordo com o domínio do problema Também expresso formalmente n Pré e pós-condições (ou pseudo-código) 103

Exemplo de Fluxo de Eventos Um esboço inicial sobre Sacar dinheiro seria n 1. 2. 3. O use case inicia quando o Cliente insere um cartão no CA. Sistema lê e valida informação do cartão Sistema pede a senha. Cliente entra com a senha. Sistema valida a senha. Sistema pede seleção do serviço. Cliente escolhe “Sacar dinheiro” 104

Exemplo de Fluxo de Eventos n Um esboço inicial sobre Sacar dinheiro seria 4. 5. 6. Sistema pede a quantia a sacar. Cliente informa. Sistema pede seleção da conta (corrente, etc). Cliente informa. Sistema comunica com a rede para validar a conta, senha e o valor a sacar. 105

Exemplo de Fluxo de Eventos n Um esboço inicial sobre Sacar dinheiro seria 7. 8. Sistema pede remoção do cartão. Cliente remove. Sistema entrega quantia solicitada. 106

Exercício n Remodele exercício anterior para mostrar a situação excepcional quando o serviço pode ser solicitado pelo browser do celular. 107

Fluxo de Eventos n Na descrição do que o sistema faz através de fluxos de eventos completos n n Surgem caminhos alternativos Casos diferentes a considerar Efeitos/valores diferentes a produzir Eventualmente descreve todos esses caminhos possíveis 108

Sub-fluxos de Eventos n Fluxo de eventos visto como n n Sub-fluxos são descritos como n n n Vários sub-fluxos de eventos Principal Alternativos/excepcionais Abordagem visa reuso de fluxos de eventos (sub-fluxos) 109

Exemplo de Sub-fluxos n Seja o use case Validar usuário n Fluxo principal: n n Fluxo excepcional: n n O use case inicia quando o sistema pede ao Cliente a senha. Cliente entra com senha. Sistema verifica senha é válida. Se a senha é válida, sistema confirma e termina o use case. Cliente pode cancelar a transação a qualquer momento pressionando a tecla ESC, reiniciando o use case. Nenhuma modificação é feita na conta do Cliente. Fluxo excepcional: n Se Cliente entra com senha inválida, o use case reinicia. 110

Diagrama de Atividades n Descreve fluxo de tarefas n n Aspectos dinâmicos de um sistema Podem também ser usados para criar sistemas executáveis n n Depende do nível de detalhamento e grau de execução dos elementos usados Alternativa para modelar fluxos de eventos de casos de uso 111

Elementos de um Diag. Ativ. 112

Exercício n Remodele o exercício anterior usando um diagrama de atividade no lugar de linguagem natural 113

Diagramas de Use Cases n Caracterizar limites da funcionalidade do sistema n n Use cases são organizados dentro de um diagrama Em diagramas de use cases n Atores são relacionados por generalização/especialização 114

Exemplo de Diagrama Sistema de validação de cartão de crédito Transação de cartão Cliente Processa fatura Instituição vendedora Reconcilia transações Cliente individual Cliente corporativo Gerencia conta Financeira 115

Bibliografia n n n Sommerville, I. Software Engineering Kruchten, P. The Rational Unified Process: An Introduction. 2 nd Ed Booch, G. et al. The Unified Modeling Language User Guide. 116