Use Cases (Casos de Uso)

Objetivos Introduzir a necessidade de elicitação de requisitos Apresentar várias técnicas de elicitação Descrever em detalhe a técnica de Use Case

Uma caso real! O Sistema que queremos deve fazer isto, isto ..., e nesse caso também isto; Sim, Sim estou anotando; Conversei com os usuários e basicamente este é o Sistema que teremos que desenvolver; Sim chefe; Ótimo, começaremos a especificar os requisitos imediatamente;

ELICITAÇÃO DE REQUISITOS MOTIVAÇÃO (Cont. ...) ... Quatro Meses Depois ... Srs. Usuários, após o emprego das mais modernas técnicas de especificação, produzimos este documento que descreve minuciosamente o Sistema; Ótimo! Bom! Hum! ... é um documento com 300 páginas e todos estes gráficos, tabelas. Enfim, vamos analisá-lo e voltamos a falar;

ELICITAÇÃO DE REQUISITOS MOTIVAÇÃO (Cont. ...) ... Depois de um mês e meio ... Sr. Analista, nosso pessoal analisou com cuidado o documento. Tivemos muita dificuldade e dúvidas em entendê-lo. Mas o que percebemos é que NÃO FOMOS CORRETAMENTE ENTENDIDOS!!! Como não? Tudo que aí está, foi fruto de nosso entendimento pessoal. REALMENTE VOCÊS NÃO SABEM O QUE QUEREM!!!

Elicitação de Requisitos ELICITAR: descobrir, tornar explícito, obter o máximo de informações para o conhecimento do objeto em questão Cabe à elicitação a tarefa de identificar os fatos que compõem os requisitos do Sistema, de forma a prover o mais correto e mais completo entendimento do que é demandado daquele software

Elicitação de Requisitos: Dificuldades Usuários podem não ter uma idéia precisa do sistema por eles requerido; Usuários têm dificuldades para descreverem seu conhecimento sobre o domínio do problema; Usuários e Analistas têm diferentes pontos de vista do problema (por terem diferentes formações); Usuários podem antipatizar-se com o novo sistema e se negarem a participar da elicitação (ou mesmo fornecer informações errôneas).

Atividades da Elicitação Entendimento do domínio da aplicação O conhecimento do domínio da aplicação é o conhecimento geral ond eo sistema será aplicado. Entendimento do problema Os detalhes dos problemas específicos do problema do cliente onde o sistema será aplicado deve ser entendido.

Atividades da Elicitação Entendimento do negócio Você deve entender como os sistemas interagem e contribuem de forma geral com os objetivos de negócio. Entendimento das necessidades e limitações dos stakeholders do sistema Você deve entender, em detalhe, as necessidades específicas das pessoas que requerem suporte do sistema no seu trabalho.

Técnicas de elicitação Entrevista Leitura de documentos Questionários Análise de protocolos Participação ativa dos usuários Use Cases e Cenários (UML) Métodos Soft Systems Observações e análise sociais Reuso de requisitos

Elicitação de Requisitos O profissional deve selecionar as técnicas a serem utilizadas e estabelecer de que maneira elas serão integradas É importante utilizar uma técnica de modelagem de apoio para que os fatos elicitados fiquem corretamente representados para futuro tratamento A escolha das técnicas e seu esquema de integração dependerá do problema e da equipe participante

Técnicas específicas de elicitação

Entrevistas O engenheiro de requisitos ou analista discute o sistema com diferentes stakeholders e obtêm um entendimento dos requisitos. Vantagens: contato direto com o usuário e validação imediata Desvantagens: conhecimento tácito e diferenças de cultura

Entrevistas: tipos Entrevistas fechadas. O engenheiro de requisitos busca respostas para um conjunto de questões pré-definidas Entrevistas abertas. Não há uma agenda pré-definida e o engenheiro de requisitos discute, de forma aberta, o que o stakeholders quer do sistema. Tutorial: o cliente está no comando - aula

Essencial das entrevistas Entrevistadores devem estar de “cabeça aberta” e não fazer a entrevista com noções pré-concebidas sobre o que é necessário Informar aos stakeholders o ponto inicial da discussão. Isto pode ser uma questão, uma proposta de requisitos ou um sistema existente Entrevistadores devem estar cientes da política organizacional - muitos requisitos reais podem não serem discutidos devido as implicações políticas

Leitura de Documentos Abstrações Vocabulário da aplicação Vantagens: facilidade de acesso e volume de informações Desvantagens: dispersão das informações e volume de trabalho

Questionários Quando existe conhecimento sobre o problema e grande número de clientes Dão idéia definida sobre como certos aspectos universo de informação/software são percebidos Possibilitam análises estatísticas Vantagens: padronização das perguntas e tratamento estatístico das respostas Desvantagens: limitação do universo de respostas e pouca iteração

Análise de Protocolos Consiste em analisar o trabalho de determinada pessoa através de verbalização Objetivo: estabelecer a racionalidade utilizada na execução de tarefas Vantagens: possibilidade de elicitar fatos não facilmente observáveis e permitir melhor entendimento dos fatos Desvantagens: desempenho do entrevistado e “o que se diz é diferente do que se faz”

Participação Ativa dos Usuários Incorporação dos usuários ao grupo de desenvolvimento Os usuários precisam aprender as linguagens de modelagem utilizadas para ler as descrições e criticá-las Integração dos usuários com os desenvolvedore na modelagem do sistema Vantagens: envolvimento dos clientes e usuários Desvantagens: treinamento dos usuários e falsa impressão da eficácia do sistema

Diagramas de Use Cases Servem facilitam o entendimento de um sistema mostrando a sua “visão externa” São usados para modelar o contexto de um sistema, subsistema ou classe São uma das maneiras mais comuns de documentar os requisitos do sistema Delimitam o Sistema Definem a funcionalidade do sistema

Use Case É uma forma específica de uso do sistema através da execução de alguma funcionalidade do sistema. Use Cases descrevem o que acontece dentro do sistema. Ajudam muito na comunicação entre clientes e os desenvolvedores.

Caso de Uso Uma unidade coerente de funcionalidade provida por uma classificador (um sistema, subsistema ou classe) manifestado por uma sequência de mensagens trocadas entre o sistema e um ou mais usuários externos (representados como atores), junto com as ações executadas pelo sistema.

Use cases Um use case é a especificação de sequências de ações que um sistema, subsistema, ou classe pode realizar, interagindo com um dos atores Descrição de um conjunto de sequências de ações, incluindo variantes, que o sistema executa para produzir um resultado observável para um ator. Use cases podem incluir sequências alternativas, ou sequências excepcionais (de erro)

Use Case: Representação gráfica A coleção de use cases deverá especificar todas as formas existentes de uso do sistema. Verificar pré-requisitos Matricular aluno Solicitar histórico

Use Case Mostra apenas o que o sistema faz, e não como. Captura o comportamento pretendido para um sistema, sem a necessidade de especificar como esse comportamento será implementado. Diagramas de interação podem ser usados para especificar com um use case será implementado (ou realizado).

Use Case inclue: Uma linha de comportamento normal em resposta a um pedido do usuário Possíveis variantes da sequência normal, tais como: sequências alternativas, comportamento excepcional e tratamento de erro.

Atores O sistema será descrito através de vários use cases que são executados por um número de atores Atores constituem as entidades do ambiente do sistema São pessoas ou outros subsistemas que interagem com o sistema em desenvolvimento

Atores

Atores: Especialização É possível definir tipos gerais de atores e especializá-los usando o relacionamento de especialização

Diagramas de Use Case Uma associação entre um ator e um use case indica que há uma comunicação, possivelmente com envio e recepção de mensagens

Diagramas de Use cases Solicitar Histórico do histórico semestre atual <<estende>> Histórico do semestre atual Solicitar histórico de do curso Solicitar histórico Verificar dependências Matricular aluno <<inclui>> Sistema de controle de pre-requisitos

Exemplo (máquina de reciclar) Um sistema de software é desenvolvido para controlar um máquina para reciclar garrafas, latas e gradeados. A máquina poderá ser usado por vários usuários ao mesmo tempo. Cada usuário poderá retornar os três tipos de ítem na mesma ocasião. O sistema deverá ser capaz de distinguir entre diferentes tipos e tamanhos de garrafas e latas. O sistema deve registar o número e tipo de itens colocado por cada usuários. Quando solicitado, o sistema deverá ser capaz de imprimir um recibo com: o número de itens depositados, o valor dos item devolvidos, e o valor pago ao usuário.

Exemplo (máquina de reciclar). O sistema também será usado por um operador. O operador precisa de uma impressão diária com os itens depositados durante o dia. A listagem de incluir um número para cada item. O operador do sistema também precisa de uma operação para modificar a informação de itens armazenada no sistema. Por exemplo, o valores dos itens depositados. Quando um item ficar preso no sistema, o sistema deve alertar o operador ligando um alarme.

Atores Primeiro é preciso identificar os usuários do sistema, que serão chamados de atores. Um ator é um tipo ou categoria de usuário. Um ator poderá representar um pessoa ou outro sistema interagindo com o sistema a ser desenvolvido.

Atores e seus papéis Uma pessoa pode instanciar (fazer o papel) de diferentes atores Atores definem os papéis que os usuários podem fazer Atores modelam qualquer coisa que precise trocar informações com o sistema. Atores podem modelar usuários humanos mas também podem modelar outros sistemas que se comunicam o sistema em desenvolvimento

Identificação de Atores Atores são externos ao sistema Para a identificação de todos os atores de um sistema poderá ser necessário várias iterações. Diretrizes: Pergunte a você próprio por que o sistema está sendo desenvolvido? Quem serão as pessoas que o sistema ajudará?

Identificação de Atores Diretrizes: Quais serão os outros sistemas que precisarão interagir com o novo sistema? Agentes que usam o sistema diretamente (ou seu trabalho diários) são chamados de Atores Principais Agentes principais estão associados com uma ou mais tarefas do sistema

Identificação de Atores Atores que estão relacionados com a supervisão e manutenção do sistema são chamados de agentes secundários Atores do sistema de reciclagem : O cliente O operador Eles são entidades do ambiente do sistema, que interagem com ele.

Interação dos Atores O cliente interage com sistema: depositando itens na máquina recebendo um recibo da máquina O operador interagem com sistema: : Recebendo os relatórios diários dos depósitos realizados Mantendo o banco de dados de itens

Papéis Atores além de pessoas ou subsistemas, podem ser papéis desempenhados por uma mesma pessoa, ou subsistema. No exemplo, ocasionalmente o operador poderá depositar suas próprias garrafas na máquina. Neste caso ele atuará no papel de cliente.

Use Cases do Sistema de Reciclagem Após identificação dos agentes o próximo passo é a identificação dos use cases. Os atores são fundamentais para a descoberta dos use cases. Cada ator irá executar vários use cases no sistema. Cada use case será um curso completo de eventos iniciados pelo ator e especificará as interações que ocorrerão entre o ator e o sistema.

Identificação de use cases Primeiro passo, examinar os requisitos do ponto de vista dos usuários. Perguntas úteis; Quais são as principais tarefas de cada ator? O ator precisa ler/escrever/modificar alguma informação do sistema? O ator precisará informar ao sistema as mudanças ocorridas no exterior? O ator quer ser informado sobre mudanças inesperadas?

Use Cases do Sistema de Reciclagem Cliente Deve ser capaz de retornar items (latas, garrafas). O use case será Retornar item . Este use case deverá incluir todos os eventos até o recibo ser emitido.

Use Cases do Sistema de Reciclagem Operador Deve ser capaz de receber um relatório diário de todos os itens depositados. Use case Gerar relatório. Deve ser também capaz de modificar informações do sistema, por exemplo o valor de cada item depositado. Use case, Mudar item.

Descrições do Use case Use Case Retornar item Fluxo principal de eventos: Será iniciado pelo cliente quando ele/ela retornar os itens. O sistema manterá uma contagem atualizada dos tipos de itens e seus valores diários. Quando o cliente depositar os seus itens, ele/ela irá pressionar o botão recibo para obter o recibo. O recibo impresso irá listar os itens depositados, seus totais e o valor a ser pago ao cliente.

Descrições do Use case Use Case Gerar relatório Use case Mudar item Fluxo principal de eventos: Será iniciado pelo operador quando ele precisar da listagem dos itens retornados no dia. O sistema imprimirá o tipo, quantidade de cada item e o total. Use case Mudar item Fluxo principal de eventos Será inciado pelo operador para modificar a informação do item no sistema. Ele será capaz de alterar o valor a ser pago pelo item.

Diagrama de Use Case Gerar Relatório Retornar Item Operador Mudar Item Cliente

Expressão de variantes de use case Nem sempre é óbvio decidir se uma funcionalidade corresponde a um novo use cases. As vezes trata-se de uma variação de um mesmo use case Se as diferenças forem pequenas elas podem ser descritas através de variantes de um mesmo use case Se as diferenças são grandes elas devem ser descritas como use cases separados.

Expressão de variantes de use case Fluxo principal de eventos Descreva a sequência normal de eventos de um use case. Fluxo excepcional de eventos Descreva as variações dos cursos básicos de eventos (ex. Erros).

Expressão de variantes Use Case Retornar item Fluxo principal de eventos: …... Quando o cliente depositar os seus itens, ele/ela irá pressionar o botão recibo para obter o recibo. O recibo impresso irá listar os itens depositados, seus totais e o valor a ser pago ao cliente. Fluxo excepcional de eventos Quando o cliente retorna um item ele é medido pelo sistema. A medição é usada para determinar que tipo de lata, garrafa ou gradeado foi depositado. Se aceito o total do cliente será incrementado. Se não for aceito, apresentar mensagem ´NÃO É VALIDA´.

Adição de detalhes Use Case Retornar item Fluxo principal de eventos: Quando o cliente depositar os seus itens, ele/ela irá pressionar o botão recibo para obter o recibo. O recibo impresso irá listar : nome do item número de itens retornados valor do item total para este item Soma total a ser paga ao cliente

Organizando Use Cases Generalização Inclusão Extensão

Generalização de Use Case Relaciona um Use Case especializado a um mais geral O filho herda os atributos, operações e sequências de comportamento dos pais O filho pode adicionar e redefinir o comportamento do pai O filho pode substituir o pai em qualquer lugar que ele aparece

Generalização de Use Case O use case filho pode adicionar comportamento incremental através da inserção de sequências adicionais de ações em pontos arbitrários da sequência do pai Pode modificar alguma das operações e sequências herdadas (cuidado!!) Relacionamentos de inclusão e extensão do use case filho também modificam o use case do pai

Generalização de Use Cases É possível abstrair comportamentos de use cases. Nomalmente a similaridade entre use cases é identificada após a construção do use case. Os use cases Checar password e Scan de retina ambos servem para validar o usuário. Identificar um use case abstrato Validar usuário para realizar esta validação.

Generalização Validar usuário Checar password Scan da retina

Inclusão de use cases O use case base incorpora explicitamente o comportamento de outro use case no local especificado na base. O use case incluído nunca estará sozinho, somente será instanciado de um use case base que o incluirá. Usado para evitar a descrição do mesmo fluxo de eventos várias vezes.

Sessão de ATM use case base (cliente) Inclusão Sessão de ATM use case base (cliente) <<inclue>> <<inclue>> Identificar Cliente Validar Conta use case incluído (servidor)

Use Case: Sessão de ATM mostre anúncio do dia inclue Identificar Cliente inclue Validar Conta imprimir cabeçalho do recibo log out Use Case de Inclusão: Identificar Cliente pegue o nome do cliente inclue Verificar Identidade if falha de verificação then abort a sessão obtenha número da conta do cliente Use Case de Inclusão: Validar Conta estabeleça conexão com banco de dados de contas otenha status e limite da conta

Inclusão de Use Case : Def. Inclusão da sequência de comportamento do use case servidor na sequência de interação do use case cliente, sob controle do use case cliente, no local que o cliente especifica sua descrição

Inclusão de Use Case Descreve uma sequência adicional de comportamento que será inserida na instância de use case que está executando o use base base O mesmo use case de inclusão pode ser inserido em múltiplos use case base A inclusão representa comportamento encapsulado que potencialmente poderá ser reusado em outros use case base

Inclusão de use case: Avançado O use case base (cliente) não poderá acessar os atributos do use case de inclusão (servidor) O use case de inclusão (servidor) poderá acessar atributos e operações use case base (cliente), para obter valores e comunicar resultados Os valores dos atributos do use case de inclusão (servidor) não persistem entre execuções A inclusão é executada apenas uma vez

Extensão de use case A extensão de um use case base por um use case de extensão especifica como o comportamento definido pelo use case de extensão pode ser inserido no comportamento do use case base. O use case de extensão modifica incrementalmente o use case base de uma forma modular

Extensão de use case Exemplo: quando um item ficar preso o sistema deverá emitir um alarme Isto poderá ser descrito como um use case que estende o use case Retornar item

Extensão de use case Retornar item <<estende>> Item preso Quando um item ficar preso o alarme é ativado para chamar o operador. Quando operador remover o item preso o alarme é desligado e o cliente poderá continuar a retornar itens.

Extensão de use case Usado para modelar extensão de outros use cases completos: Para modelar partes opcionais de use cases Para modelar cursos alternativos e complexos que raramente ocorrem, como Item Preso Para modelar sub-cursos que são executados somente em certos casos

Extensão de use case Para modelar modelar a situação onde vários diferentes use cases podem ser inseridos em um use case (pontos de extensão) O use case base implicitamente incorpora o comportamento do use case na localização especificada.

Extensão: Pontos de Extensão Fazer Pedido Pontos de extensão set prioridade Fazer Pedido Urgente <<estende>> (set prioridade) <<inclue>> Validar usuário Use Case Fazer Pedido Fluxo principal de eventos: inclue (Validar usuário). Receber do usuário os itens do pedido. (set prioridade). Submeter o pedido para processamento.

Extensão: Pontos de Extensão Sessão de ATM pontos de extensão transação possível detalhes do recibo abortável Use Case: Sessão de ATM mostre anúncio do dia ----- inclue Identificar Cliente ! uma região <abortável> inclue Validar Conta ! (ponto de extensão aqui) < --!---- < transação possível> imprimir cabeçalho do recibo -! (outro ponto de extensão) < -------- <detalhes do recibo> log out

Extensão de use case: Avançado Cada ponto de extensão precisa ser definido no use case base. Quando a execução da instância do use case alcança o local do use case referenciado pelo ponto de extensão e a condição da extensão é satisfeita, a execução é transferida para a sequência do segmento de extensão. Quanto terminada, o controle volta para o use case original

Extensão de use case: Avançado A extensão implicitamente modifica o comportamento do use case base Os efeitos da do use case de extensão são adicionados aos efeitos do use case base quando da sua instanciação

Extensão de use case: Avançado O relacionamento de extensão pode ter uma condição, uma expressão em termos de atributos do use case base, ou a ocorrência de eventos tais como a recepção de um sinal Se não há condição se assume que ela é verdadeira A extensão poder ser executada mais de uma vez, se a condição permanecer verdadeira

Agenda

Celular

Dicas: Modelando o Contexto do Sistema Identifique os atores que cercam o sistema Quais grupos precisam de ajuda do sistema para executarem suas tarefas Quais os grupos necessários para executarem as funções do sistema Quais grupos interagem com hardware externo ou outros sistemas de software Quais grupos executam funções secundárias de administração e manutenção

Dicas: Modelando o Contexto do Sistema Organize os atores que são similares em uma hierarquia de generalização / especialização. Quando ajudar a compreensão, faça um esteriótipo para o ator Use os atores no diagrama de use cases e especifique os caminhos de comunicação entre atores e use cases do sistema.

Dicas: Modelando Requisitos do Sistema Estabeleça o contexto do sistema através da identificação dos atores que o cercam Para cada ator, considere o comportamento que eles esperam o requerem que o sistema produza De um nome aos comportamentos comuns (Usecase) Fatore comportamentos comuns em novos use cases que serão usados por outros

Dicas: Modelando Requisitos do Sistema Fatore comportamento variante em novos use cases que estendem a fluxo principal de eventos Modele os use cases, atores e seus relacionamentos através de diagramas de use case Adorne os use cases com notas que descrevem requisitos não funcionais (algumas destes se aplicam ao sistema como um todo).