ENGENHARIA DE SOFTWARE

Transcrição

1 ENGENHARIA DE SOFTWARE PARTE 2 LINGUAGEM DE MODELAÇÃO UML Tópicos Introdução Casos de Uso/Utilização Diagramas de Casos de Uso Proposta de Metodologia 2 CAP. 5 UML CASOS DE USO/UTILIZAÇÃO Introdução 3 Introdução - Requisitos 4 Descrevem o comportamento do sistema na perspetiva do utilizador, utilizando ações e reações. Constituem a técnica UML para representar o levantamento de requisitos de um sistema. Isto porque: raramente foi fácil analisar requisitos de conceção a partir da observação abstrata de um sistema que se pretende desenvolver desde sempre que o correto levantamento de requisitos no desenvolvimento de sistemas tenta garantir que o sistema será útil ao utilizador final, estando de acordo com as suas necessidades Engenharia de requisitos: área que se preocupa com aspetos como: a captura de requisitos de um sistema de software, o seu armazenamento e respetiva gestão. Requisito: especificação de uma determinada ação ou determinada condição que o sistema deverá satisfazer. Os requisitos podem ser: Funcionais Não funcionais

2 Introdução - Requisitos 5 Introdução - Requisitos 6 Requisito funcional Descreve uma determinada ação (ou função) que o sistema deverá satisfazer São os requisitos inicialmente levantados, abrangendo a descrição de processamento, as entradas e saídas que derivam da interação com pessoas ou outros sistemas; Requisito não funcional Descreve um aspeto (não funcional) que o sistema deverá satisfazer Relacionado com aspetos gerais do sistema, tais como: desempenho, robustez, fiabilidade, distribuição, segurança, integração com a internet, abertura, ou suporte de standards Descreve a qualidade com que o sistema deverá fornecer os requisitos funcionais: tempos de resposta, volume de dados, ou considerações de segurança. Nível de Prioridade em Requisitos: Obrigatório - O requisito será incluído de certeza pode ser de alta prioridade - absolutamente necessário Desejável - Não é garantida a sua inclusão, depende de outros fatores como custos, riscos ou recursos disponíveis corresponderá a média ou baixa prioridade - os utilizadores podem viver algum tempo (mais ou menos longo) sem ele Adiado - Será incluído numa segunda versão do sistema corresponderá a baixa prioridade (os utilizadores podem sobreviver sem ele durante um prazo longo) Introdução - Requisitos 7 Casos de Uso/Utilização 8 Levantamento de Requisitos: elaboração de reuniões participativas entrevistas questionários observação direta, estudo e amostra de documentos e relatórios Representação de Requisitos: Diagramas de Casos de Uso A modelação de requisitos funcionais através de especificação de casos de uso é considerada como uma abordagem extremamente adequada, quer por facilitar a comunicação entre a equipa de projeto e os clientes/utilizadores, quer por promover a comunicação, gestão e condução no desenvolvimento do próprio projeto. Suponha-se o caso do sistema correspondente a uma máquina ATM usada para levantamento de dinheiro e para pagamento. Como analisar os requisitos do programa que queremos conceber para gerir a interação entre a máquina e o utilizador? Uma solução simpática será descrever o exemplo de casos típicos de interação entre o utilizador e a máquina: mete cartão, aguarda mensagem de digitação do código, digita código, Diz-se que se está a descrever cenários de utilização ou Casos de Uso. Caso de uso: é uma sequência de ações que um ou mais atores realizam num sistema de modo a obterem um resultado particular.

3 Casos de Uso/Utilização 9 Casos de Uso/Utilização 10 Propriedades de um caso de uso: capturar os requisitos de um sistema através do detalhe de todos os cenários que os utilizadores podem realizar dirigir/conduzir todo o processo de desenvolvimento permitir ao utilizador atingir um objetivo discreto Capturar casos de uso: falar com os utilizadores típicos e discutir as várias tarefas que eles pretendem fazer com o sistema tomar cada coisa discreta (cada uma das ações), dar-lhe um nome e escrever umas linhas a descrevê-la (não mais do que alguns parágrafos) numa primeira fase, não interessa capturar, logo no início, todos os pormenores, mas apenas aqueles que se revelem essenciais para compreender os requisitos do sistema no seu todo. Casos de uso correspondentes a finalidades e interações (diferenças): Interações com o sistema: De carácter mais próximo da implementação, São os casos de uso que refletem coisas que o utilizador faz com o sistema e não a finalidade real que o utilizador tenta atingir. Exemplos: definir um estilo, alterar um estilo, copiar um estilo de um documento para outro. Finalidades do utilizador: De carácter mais conceptual. Exemplos: garantir formatação consistente para um documento ; permitir que a formatação de um documento seja idêntica à de outro. Casos de Uso/Utilização 11 Casos de Uso/Utilização 12 A dicotomia entrefinalidades einterações nem sempre existe: Exemplo: O processo de indexação de um documento é o mesmo independentemente de se pensar nele como uma finalidade ou uma interação com o sistema. Mas: sempre que essa dicotomia exista, é importante levar em conta a diferença. Os casos de uso correspondentes a interações com o sistema são melhores para efeitos de planeamento. Os casos de uso correspondentes a finalidades dos utilizadores são úteis para permitir explorar eventuais formas alternativas ao nível das interações com o sistema que lhes vão corresponder. Pensar nas finalidades primeiro pode levar a encontrar novas formas de satisfazê-las mais eficazmente. Focar primeiro nas finalidades e só depois nos casos de uso correspondentes às formas de as satisfazer.

4 Casos de Uso/Utilização 13 Casos de Uso/Utilização 14 Um caso de uso é representado graficamente através de uma oval com uma frase que representa uma determinada ação. A frase deve ser escrita na voz ativa, com um verbo no infinitivo: Submeter Proposta, Criar factura, Calibrar roda, ou Validar utilizador. Um caso de uso deve descrever o que faz um sistema (ou parte deste), mas não como é que tal é realizado. O foco está, portanto, na visão externa do sistema, ou seja, na visão que os utilizadores têm dele Cada um dos Casos de Uso identificados deve ser detalhado ou descrito em termos de cenários de utilização. Usa-se a expressão cenário para descrever um único percurso, dos muitos possíveis, na execução de um caso de uso. Um cenário corresponde a uma das formas possíveis de executar um caso de uso, por forma a fornecer uma resposta ao ator. é uma determinada sequência de ações que ilustra um comportamento do sistema. é uma instância de um caso de uso, sendo normal que um caso de uso possa ser descrito por dezenas de possíveis cenários (definição mais abstrata). Uma designação alternativa para cenário por vezes utilizada é fluxo de ações. Um cenário pode ser: Aquele em que tudo corre bem; Aquele em que algo pode correr mal, mostrando fluxos de eventos anormais; Exemplos: cenário de caso de uso em que tudo corre bem, cenário em que não há produtos em quantidade suficiente, e cenário em que o crédito é recusado, De uma forma geral, há mais de uma maneira de executar um caso de uso - diz-se que o caso de uso pode ter várias realizações.

5 17 18 A descrição do cenário pode assumir duas formas: Texto livre; Estruturada (segundo um conjunto de passos numerados). Descrição do cenário em texto livre: Deve-se especificar o comportamento de um caso de uso descrevendo textualmente um ou mais fluxos de ações, de modo que um utilizador não técnico o possa entender sem dificuldade. Tal especificação deve incluir: Como e quando o caso de uso começa e termina, Quando é que o caso de uso interatua com os atores, Que objetos são trocados, Cenário principal, e Cenários alternativos (por ex:, situações de exceção). Outras formas alternativas ou complementares, podem ainda incluir a especificação de pré e pós condições, os atores que iniciam o caso de uso, os atores que beneficiam com o caso de uso, um ou mais diagramas de interação, A UML disponibiliza os chamados diagramas de interação que permitem descrever, sob a forma gráfica, os diversos cenários Um aspeto importante na especificação do caso de uso tem a ver com o nível de detalhe do mesmo. A dimensão da especificação de um caso de uso varia bastante consoante o tipo de projeto envolvido, os intervenientes do projeto, e as exigências impostas pelos clientes. Essa especificação normalmente é textual, de modo mais ou menos informal, mas pode ser complementada por diagramas de interação (para ajudar a clarificar as interações entre os diferentes intervenientes); ou até por protótipos de interfaces com utilizadores (por ex:, desenho de ecrãs ou de listagens tipo). Sempre que possível, deve-se evitar adotar uma linguagem dependente da implementação, e de aspetos tecnológicos. Designadamente, deve-se evitar referir explicitamente: pessoas, em vez de papéis desempenhados; departamentos específicos de uma organização; componentes de interface com o utilizador (botões, menus, caixas de texto, scrollbars); ou referências a dispositivos hardware.

6 21 22 Exemplo de Cenários de Caso de Uso sob a forma de Texto Livre Nome: Validar Utilizador (fig. anterior pág. 13) Cenário Principal O caso de uso inicia-se quando o sistema apresenta um ecrã a pedir ao cliente o seu cartão eletrónico. O cliente introduz o seu cartão MB e, através de um pequeno teclado, o seu PIN. Note-se que o cliente pode limpar a introdução do seu PIN inúmeras vezes e reintroduzir um novo número antes de ativar o botão Entrar. O cliente ativa o botão Entrar para confirmar. O sistema lê o PIN e a respetiva identificação do cartão MB, e verifica se é válido. Se o PIN for válido o sistema aceita a entrada e o caso de uso termina. Exemplo de Cenários de Caso de Uso sob a forma de Texto Livre Nome: Validar Utilizador (cont.) Cenário Alternativo 1 (Cliente cancela operação) O cliente pode cancelar a transação em qualquer momento ativando o botão Cancelar, implicando a reinicialização do caso de uso. Não é realizada qualquer alteração à conta do cliente. Cenário Alternativo 2 (PIN inválido) Se o cliente introduz um PIN inválido, o cartão MB é ejetado e o caso de uso é reiniciado. Se tal ocorrer 3 vezes consecutivas, o sistema cativa (i.e., recolhe ) o cartão MB e cancela a transação; não permitindo qualquer interação nos 2 minutos seguintes Exemplo de Cenários de Caso de Uso sob a forma de Texto Livre Nome: Levantamento de dinheiro numa ATM Cenário Principal: O utilizador vai até à ATM e insere o cartão. A máquina pede o PIN e o cliente responde à solicitação, sendo-lhe perguntado o que pretende fazer. O cliente diz levantar dinheiro. A máquina pergunta quanto e o cliente indica 100. Então como que por magia, a máquina dá a massa, perguntando se pretende efetuar outra transação. Respondendo que não, a máquina devolve o cartão, dá o recibo e termina a transação. Cenário Alternativo: O cliente dirige-se à ATM, insere o cartão e digita o PIN. A ATM responde que o PIN é incorreto. Nova tentativa, a mesma resposta. Ainda outra tentativa de introdução do PIN, mas que se revela infrutífera. E o que acontece? A ATM come o cartão. Outro exemplo de Cenário de Caso de Uso sob a forma de Texto Livre Nome: Efetuar encomenda num restaurante defastfood Cenário Principal: O cliente, após ter validado o acesso através do respetivo cartão de cliente e PIN, seleciona a opção de Encomendar, sendo mostrado simultaneamente com a sua encomenda, o catálogo dos produtos. Para adicionar um produto, tem apenas de apontar o produto pretendido (a sua figura é mostrada no ecrã), para que, automaticamente, o seu nome, descrição e preço sejam visualizados na linha de encomenda. Ao mesmo tempo o valor total da encomenda é atualizado. Através da opção confirmar, o cliente confirma a sua encomenda e passa para a função pagamento, bastando para tal confirmar o pagamento por débito do cartão. É atribuído um número de identificação à encomenda, sendo emitido o talão respetivo, onde é também indicado a hora provável de disponibilização dos artigos encomendados. Através da utilização do talão, a mercadoria será entregue ao cliente.

7 25 26 Cenário de Caso de Uso na forma Estruturada Nome: Efetuar Encomenda (Cenário Principal) Pré-condição O cliente é um utilizador válido do sistema Descrição 1. O caso de uso começa quando o cliente seleciona a opção de encomendar 2. Em simultâneo com a sua encomenda é mostrado o catálogo de produtos 3. O cliente adiciona produtos à encomenda através da sua seleção através do apontar da sua figura no ecrã 4. Automaticamente, o sistema mostra o nome, descrição e preço do produto, colocando-o na linha da encomenda 5. A cada novo produto adicionado, o valor total da encomenda é atualizado 6. O cliente confirma a sua encomenda, através da opção Confirmar 7. O sistema pede então a confirmação de pagamento através do débito no cartão 8. O sistema confirma saldo de cartão e atribui número de identificação à encomenda, emitindo um talão comprovativo da encomenda, com informação da hora provável de disponibilização dos produtos encomendados Pós-Condição A encomenda será entregue ao cliente no balcão, mediante a apresentação do respetivo comprovativo. Pré-condição Indica o que deve existir inicialmente para que o cenário descrito seja seguido com sucesso. Pós-condição Demostra o que irá acontecer depois do cenário ser concluído. Cenário Principal Cenário onde estão reunidas todas as condições que garantem que tudo corre bem, ou seja, é um cenário onde não surgem problemas. Cenários Alternativos Aqueles que mostram caminhos alternativos, ou seja, aqueles que mostram o que pode correr mal no cenário Ex: o cliente não ter saldo suficiente no cartão para cobrir o valor da encomenda Exemplo de Cenário com introdução de caminhos alternativos Nome: Efetuar Encomenda (cenário principal e alternativos) Pré-condição O cliente é um utilizador válido do sistema Descrição 1. O caso de uso começa quando o cliente seleciona a opção de encomendar 2. Em simultâneo com a sua encomenda é mostrado o catálogo de produtos 3. O cliente adiciona produtos à encomenda através da sua seleção através do apontar da sua figura no ecrã 4. Automaticamente, o sistema mostra o nome, descrição e preço do produto, colocando-o na linha da encomenda 5. A cada novo produto adicionado, o valor total da encomenda é atualizado 6. O cliente confirma a sua encomenda, através da opção Confirmar 7. O sistema pede então a confirmação de pagamento através do débito no cartão 8. O sistema confirma saldo de cartão e atribui número de identificação à encomenda, emitindo um talão comprovativo da encomenda, com informação da hora provável de disponibilização dos produtos encomendados a) se o valor do crédito disponível no cartão for insuficiente, o sistema avisa o cliente através de uma mensagem e a encomenda é cancelada. Exemplo de Cenário com introdução de caminhos alternativos Nome: Efetuar Encomenda (cenário principal e alternativos) Cenários Alternativos A qualquer momento, antes de efetuar a confirmação do pagamento, o cliente pode cancelar a sua encomenda, pressionando no botão Cancelar. Pós-Condição A encomenda será entregue ao cliente no balcão, mediante a apresentação do respetivo comprovativo.

8 29 30 Os casos de uso podem encontrar-se relacionados através de três tipos de relações: generalização, inclusão, e extensão. Estas relações Potenciam significativamente a reutilização da especificação de requisitos. Ou seja, permitem ao analista aquilo que o programador de linguagens orientadas por objetos normalmente pratica: reutilizar trabalho já efetuado. Generalização Permite definir casos à custa de outros já existentes, pelo mecanismo de especialização, ou alternativamente, permite definir casos mais abstratos a partir de casos concretos pelo mecanismo da redução ou generalização. Utilizada quando existe um caso de uso que é um caso particular de outro caso de uso. Usufrui das mesmas propriedades de uma relação pai/filho, onde o caso de uso filho herda ou substitui por completo o comportamento do caso de uso pai ; ou seja: herda o comportamento e semântica do seu pai, pode substituir especificações definidas no seu pai, e pode introduzir novas especificações que lhe sejam específicas Generalização (exemplos) O caso de uso Validar Utilizador é especializado em outros dois, que utilizam diferentes mecanismos de identificação do utilizador: Testar Password, e Leitura com Smartcard. Generalização (exemplos) O caso de uso Controlo de Acesso pode ser realizado de duas formas diferentes, conforme efetuado através da Internet ou na loja: Controlo Internet, e Controlo Balcão. Controlo Internet Controlo de acesso Controlo Balcão

9 33 34 Generalização A relação de generalização, também pode ser utilizada entre atores. É estabelecida uma relação de generalização entre o ator Funcionário (caso geral) e o ator Empregado de Balcão (caso específico). Esta relação evita a duplicação de ligações quando ambos os atores partilham alguns casos de uso. Generalização Exemplo de casos de uso e atores com relação de generalização: Todos os funcionários têm de registar a hora de entrada/saída, mas apenas o empregado de balcão pode registar encomendas Registar hora entrada / saída Funcionário Funcionário Empregado de Balcão Empregado de Balcão Efectuar encomenda Inclusão («include») Corresponde a uma relação típica de delegação, significando que o caso base incorpora o comportamento do outro caso relacionado. Significa que um determinado caso de uso utiliza a funcionalidade disponibilizada por outro caso de uso. Usa-se para evitar a descrição dos mesmos fluxos de ações inúmeras vezes. É representada por uma relação de dependência (seta a tracejado) com o estereótipo «include». Recorre-se a este tipo de relacionamento quando se tem um bloco de comportamento que é o mesmo para vários casos de uso, fazendo assim sentido isolá-lo e fazer com que os diversos casos de uso o invoquem quando precisarem dele. Inclusão («include») Exemplo 1 (caixa de multibanco): os casos de uso Obter Extracto de Conta ou Realizar Pagamentos exigem que seja realizada previamente uma validação do respetivo utilizador. Para que essa funcionalidade não seja especificada mais que uma vez, os casos anteriores incorporam-na (como sua) ao estabelecerem uma relação de inclusão com o caso Validar Utilizador.

10 37 38 Inclusão («include») Exemplo 2: Tanto o caso de uso Análise de riscos como o caso de uso Negociação de preço usam o caso de uso Avaliação "Usa" Análise de riscos Avaliação "Usa" Negociante Negociação de preço Inclusão («include») A questão importante que se coloca é como indicar, ou em que ponto da especificação, o caso de uso relacionado deve ser incorporado no caso base. Este é um aspeto essencial na compreensão e domínio dos casos de uso. A explicitação desta informação deve ser efetuada na especificação textual do caso de uso. O exemplo seguinte clarifica esta questão com a descrição textual do caso Obter Extracto em que é evidente a indicação do ponto de inclusão através do texto Incluir Inclusão («include») Especificação textual do caso de uso Obter Extracto de Conta. Nome: Obter Extracto de Conta Cenário Principal Incluir caso de uso Validar Utilizador. Obter e verificar o número da conta. Selecionar todas as linhas de movimentos realizados nos últimos 30 dias. Produzir uma lista resumo com esses movimentos, apresentando a data, o tipo de movimento (débito ou crédito), uma breve descrição e o valor do movimento. Produzir o saldo corrente da conta. Emitir um documento com essa informação, ejetando no terminal de Multibanco o referido documento. Apresentar mensagem no visor do terminal para o cliente retirar o extrato. Registar na conta do cliente que esta operação foi realizada com sucesso. Cenário Alternativo 1 Ocorre quando existe um comportamento opcional que deve ser incluído num caso de uso. Significa que o caso base incorpora implicitamente o seu comportamento num local especificado indiretamente pelo caso que é usado. Ou seja, o caso destino pode ser estendido com o comportamento de outro(s) caso(s). Uma relação de extensão permite representar: A parte de um caso que um utilizador vê como opcional, ou como existindo várias alternativas. Um subfluxo de ações que é executado apenas se determinadas condições se verificarem. Vários fluxos de ações que podem ser inseridos num determinado ponto de extensão, de forma controlada, através de uma interação explícita com um ator.

11 41 42 O caso de uso destino é estendido num ou mais pontos, designados por pontos de extensão os quais são mecanismos de variabilidade. Ou seja, este comportamento é definido num segundo caso de uso e invocado pelo caso de uso base através do mecanismo de pontos de extensão, que são pontos de entrada do caso de uso que lhe dá algum nível de configurabilidade e versatilidade. Recorre-se a este tipo de relacionamento quando se tem um caso de uso que é praticamente igual a outro, mas que faz um pouco mais. Isola-se esse caso de uso e diz-se que é uma extensão do primeiro Exemplo 1 Considere-se o caso Obter Extracto de Conta do exemplo anterior. Na descrição textual deste exemplo, a especificação do número de dias respeitantes à seleção dos movimentos a visualizar era estática (30 dias). Numa situação mais flexível, o ideal é que o cliente/utilizador pudesse selecionar o número de dias pretendido, ou simplesmente ativar um botão para indicar que pretendia selecionar os movimentos relativos aos últimos 30 dias. A figura seguinte ilustra esta situação através da utilização da relação de extensão, representada por uma relação de dependência (seta a tracejado) com o estereótipo «extend». Pelo facto do caso de uso destino poder ter vários pontos de extensão, especifica-se, na relação de extensão, qual o ponto de extensão a que diz respeito (neste caso (N.º de dias) ) Exemplo 1 (diagrama) Exemplo 1 O exemplo seguinte ilustra a forma de representação textual dos pontos de extensão nos casos de uso, bem como, a especificação textual de um caso de uso que permite estender outro num determinado ponto de extensão.

12 45 46 Especificação textual do caso de uso Obter Extracto de Conta revisto. Nome: Obter Extracto de Conta Pontos de Extensão: N.º de dias Cenário Principal Incluir caso de uso Validar Utilizador. Obter e verificar o número da conta. Selecionar o n.º de dias com base no qual se produz o extrato. (N.º de dias). Por omissão são selecionados os últimos 30 dias. Produzir uma lista resumo com esses movimentos, apresentando a data, o tipo de movimento (débito ou crédito), uma breve descrição e o valor do movimento. Produzir o saldo corrente da conta. Emitir um documento com essa informação produzida ejetando no terminal de Multibanco o referido documento. Apresentar mensagem no visor do terminal para o cliente retirar o extrato. Registar na conta do cliente que esta operação foi realizada com sucesso. Especificação textual do caso de uso Selecionar Nº de dias. Nome: Selecionar Nº de dias Tipo: Abstrato Cenário Principal É apresentado um ecrã em que o utilizador pode especificar o n.º de dias desejado, através da marcação em vários botões numéricos (de 0 a 9 ). Há uma caixa de texto construída dinamicamente que vai apresentando o valor corrente. Por fim, o utilizador marca o botão Confirmar e o valor construído é retornado ao caso destino no seu respetivo ponto de extensão Especificação textual do caso de uso Selecionar Nº de dias. Nome: Selecionar Nº de dias Tipo: Abstrato Cenário Alternativo 1 Idêntico ao cenário principal. Em qualquer momento o utilizador pode marcar sobre o botão Apagar de modo a apagar o algarismo introduzido mais recentemente. Cenário Alternativo 2 Idêntico ao cenário principal. Quando o utilizador marca Confirmar e o valor introduzido for superior a 59 dias é apresentada uma mensagem de aviso que o número máximo é 59, e o caso é reiniciado. Cenário Alternativo 3 Idêntico ao cenário principal. Em qualquer momento o utilizador pode seleccionar o botão Cancelar O caso termina e é retornado o valor 1 (dia) por omissão. Exemplo 2 O caso de uso transposição dos limites é uma extensão do caso de uso cativação do negócio porque faz o mesmo do que este mais algo que corresponde às medidas especiais que será necessário tomar quando o limite previsto é ultrapassado "Extende" Cativação de negócio Transposição de limites

13 49 50 Como encontrá-los? começa por capturar-se o caso de uso básico para cada fase desse caso de uso, faz-se a pergunta: o que é que podia ocorrer de diferente? ou como é que isto poderia passar-se de outra maneira? desenham-se todas as variantes como extensões do caso de uso básico. Pode obterse uma grande quantidade, mas as coisas ficam muito mais claras e fáceis de entender. Note-se que embora existam semelhanças entre os dois tipos de relacionamentos, as suas intenções são distintas. Diferença entre relacionamento de inclusão e de extensão: Nas extensões, os atores têm um relacionamento com o caso de uso que passa a ser estendido. Parte-se do princípio que um mesmo ator pode executar tanto o caso de uso como as suas extensões Nos relacionamentos de uso é frequente não haver ator associado com o caso de uso partilhado. Mesmo que haja, não se espera que esse ator execute os casos de uso ligados ao que está partilhado. De um modo geral, pode dizer-se que: Recorre-se a um relacionamento de extensão quando se pretende descrever um comportamento que é uma variante do comportamento normal. Recorre-se a um relacionamento de uso quando se identifica uma repetição em dois ou mais casos de uso e se pretende evitar essa repetição 51 Casos de Uso/Utilização Quando utilizar Casos de Uso 52 Podemos aplicar as regras: Utilizar relacionamentos de inclusão quando existe a repetição de dois ou mais casos de uso Utilizar a generalização quando se descreve a variação do comportamento normal, pretendendo apenas efetuar uma descrição casual Utilizar extensões quando se descreve a variação do comportamento normal, mas de uma forma mais controlada, através de pontos de extensão no caso de uso base. Os diagramas de casos de uso dão uma panorâmica geral do sistema Mostram o que está fora do sistema e as funcionalidades que o sistema deve proporcionar Os casos de uso são muito úteis para auxiliar na análise de requisitos do sistema a projectar e para facilitar o planeamento e controlo dos projectos iterativos. Na maioria dos casos são normalmente a primeira coisa a fazer ao abordar o projecto. Normalmente começa-se com um conjunto de casos de uso não exaustivo e, depois, vão-se identificando os casos de uso adicionais.

14 Casos de Uso/Utilização Quando utilizar Casos de Uso 53 Diagramas de Casos de Uso 54 Cada caso de uso corresponde a um requisito potencial. Importa ter isso em mente pois que um requisito que não se consegue esclarecer é um requisito que não pode ser levado em conta no projecto. Alguns analistas preferem criar casos de uso de grande granularidade. Outros preferem criar muitos casos de uso pequenos. Esta solução é geralmente melhor, mas corre-se o risco de, dado o seu grande número, se tornar difícil de gerir. Um diagrama de casos de uso ilustra um conjunto de casos de uso, de atores, e suas relações (figura seguinte). Diagramas de Casos de Uso 55 Diagramas de Casos de Uso 56 As suas aplicações comuns são: Para modelar o contexto de um sistema. Neste caso, a ênfase encontra-se na identificação da fronteira do sistema, dos seus atores e no significado das suas funções. Para modelar os requisitos de um sistema. Consiste na identificação do que o sistema deve fazer, independentemente de como o sistema o deve realizar. Utilizam as seguintes abstrações de modelação: Atores Casos de uso Relações (Generalização, Inclusão e Extensão) Exemplo para um sistema de comércio financeiro Gestor de negócio Legenda: Caso de uso Actor Negociante Fixação de limites Análise de riscos "Extende" Negociação de preço Cativação de negócio Transposição de limites "Usa" "Usa" Actualização de contas Avaliação Vendedor Sistema contabilístico

15 Diagramas de Casos de Uso - Atores 57 Diagramas de Casos de Uso - Atores 58 A primeira tarefa para construir um diagrama de casos de uso é a identificação dos atores do sistema. Um ator é: Alguém ou algo que é externo ao sistema, mas que vai interagir com o sistema; Um ator é um papel que um utilizador desempenha relativamente ao sistema em análise. Pode haver várias pessoas distintas a desempenhar o mesmo papel (representam o mesmo ator) e ter uma mesma pessoa a representar vários papéis (neste caso representa vários atores). Um ator não é necessariamente um papel de um utilizador; pode corresponder a um papel desempenhado por um outro sistema informático, por um equipamento hardware especializado, ou pela simples passagem de tempo. O conjunto total de atores de todos os casos de uso reflete todos os elementos que interatuam com o sistema. Um determinado utilizador pode desempenhar diferentes papéis, podendo, por conseguinte, representar diferentes atores. Exemplo (Caixa Multibanco): podem-se identificar pelo menos dois atores: o cliente do banco, que acede ao sistema para realizar variadas operações bancárias; o operador da agência ou da caixa, que é responsável pela sua ativação, por carregar dinheiro na máquina, etc. Diagramas de Casos de Uso - Atores 59 Diagramas de Casos de Uso - Atores 60 Atores executam ou levam a cabo casos de uso um ator pode invocar muitos casos de uso um caso de uso pode ser invocado por vários atores É importante pensar-se em termos de atores (papéis abstratos) em vez de pensar em termos de pessoas O nome do ator descreve o papel desempenhado pelo utilizador. Os atores devem ser detalhados através de uma pequena descrição (três, quatro linhas, no máximo), por forma a assegurar uma correta compreensão do seu significado por todos os elementos da equipa envolvida na análise. Ex. Cliente: uma pessoa que encomenda produtos da empresa pela Internet, no balcão ou através docallcenter. Exemplo: O Sr. Joaquim, pessoa que trabalha numa oficina de automóveis é, na maior parte do tempo, um mecânico, mas também pode atuar como vendedor e cliente (reparando o seu próprio carro). Conduzir Cliente Pedir serviços Mecânico Reparar Vender Vendedor

16 Diagramas de Casos de Uso - Atores 61 Diagramas de Casos de Uso - Atores 62 Um ator não necessita de ser um humano, mas continua a representarse como figura humana estilizadas no diagrama de casos de uso. Exemplo: Um ator pode ser um sistema externo que necessite de alguma informação do sistema em análise (por ex., um módulo de contabilidade) Não há unanimidade quanto à conveniência de representar as interações externas através de casos de uso, embora a tendência mais corrente seja representar apenas aqueles que necessitam de casos de uso do sistema que estamos a desenvolver. Por exemplo, se o nosso sistema gera um ficheiro todas as noites que é acedido pelo sistema exterior que tem a seu cargo a contabilidade, então o sistema contabilístico é o ator relevante porque é aquele que necessita do ficheiro produzido. Os atores podem encontrar-se relacionados através de relações de generalização (figura seguinte), o que significa que o ator-filho (na relação de generalização) herda todas as funcionalidades e todos os papéis do seu ator-pai, podendo adicionalmente apresentar as suas próprias funcionalidades. Diagramas de Casos de Uso Casos de Uso 63 Diagramas de Casos de Uso - Casos de Uso 64 Um caso de uso abstrato é um caso que não apresente uma relação de comunicação com qualquer ator. Um caso de uso concreto é um caso que não é abstrato. Este tipo de casos de uso são tipicamente casos envolvidos em relações de generalização (e.g., o caso pai), inclusão (o caso destino) ou de extensão (o caso base) com outros casos de uso. O objetivo destes casos abstratos é dar ao modelo um nível elevado de reutilização e de flexibilidade. Casos de uso são todos acerca de funcionalidades requeridas externamente; devem detalhar o que o sistema deve proporcionar ao actor quando o caso é executado; são representados por ovais; a forma de os encontrar é olhar para cada um dos actores e perguntar: porque é que eles querem utilizar o sistema? o que é que este sistema lhe deve proporcionar?

17 Diagramas de Casos de Uso - Casos de Uso 65 Diagramas de Casos de Uso - Casos de Uso 66 Podem ser: de negócio - relativos à identificação a forma como, em termos do processo de negócio, se responde a um cliente ou evento; de sistema - relativos à identificação das interações com a aplicação a desenvolver. Esta distinção: prende-se com o facto de nem todos os casos de usos de negócio poderem vir a ser suportados pelo sistema informático; por outro lado, se pensarmos apenas no sistema, podemos esquecer que uma alteração no processo de negócio pode ser a solução mais eficiente e eficaz (reengenharia). Depois de identificar os atores, identificar para cada um, os casos de uso em que ele interage com o sistema. Essa representação assume a forma de uma tabela de casos de uso por ator. Ator Gestor de negócio Negociante Vendedor Sistema contabilístico Casos de Uso Fixação de limites Análise de risco Negociação de preço Cativação de negócio Avaliação Negociação de preço Cativação de negócio Atualização de contas Diagramas de Casos de Uso - Comunicação 67 Proposta de Metodologia 68 Comunicação entre um actor e os casos de uso: linha recta simples os actores podem estar colocados em qualquer ponto do diagrama, podendo a comunicação ser de emissão ou recepção ou seta cujas pontas indicam a direcção da comunicação o sentido da seta é o sentido da comunicação normalmente os actores emissores aparecem à esquerda do diagrama e os receptores à direita Empregado de Balcão linha recta simples Efectuar Encomenda Empregado de Balcão seta unidireccional Efectuar Encomenda A metodologia proposta consiste na aplicação dos seguintes passos: 1) Identificar os atores do sistema, ou seja, o perfil de indivíduos e de outros sistemas que interatuam com o sistema original. 2) Identificar, para cada ator, os seus casos de uso principais. Note-se que podem existir casos que envolvam a participação de mais que um ator. 3) Com base nos casos de uso originais, identificar, fatorizar e colocar em evidência casos de uso que sejam recorrentes em mais que um dos casos originais. Nessa situação, cria-se o novo caso de uso (em geral é um caso abstrato) e os casos originais envolvidos estabelecem uma relação de inclusão com o dito caso. Repetir o processo até não se conseguir identificar qualquer outro caso a reutilizar.

18 Proposta de Metodologia 69 Proposta de Metodologia 70 A metodologia proposta consiste na aplicação dos seguintes passos: 4) Para tratar casos de uso que pretendam ser flexíveis e versáteis, definir pontos de extensão (ou de variabilidade) e conjuntamente definir um ou mais casos de uso (abstratos) que os permitam estender nesses pontos. Nesta situação, cria-se uma relação de extensão do caso abstrato para o caso estendido. 5) Especificar textualmente cada caso de uso segundo um determinado formato previamente definido. Não esquecer nesta especificação textual a explicitação dos pontos de extensão e de inclusão anteriormente identificados. Exemplo: sistema Máquina de Bebidas. Uma máquina de bebidas é um sistema colocado normalmente em locais estratégicos, por onde passa muita gente, como sejam paragens de metro, recintos desportivos, escolas, etc. Resolução (usando a metodologia proposta): Passo 1: identificação dos atores do sistema bem como das suas principais atividades. Identificamos três atores: (1) o cliente, que compra a bebida; (2) o agente do fornecedor, que é responsável por carregar as bebidas na máquina; e (3) o dono da máquina, que é responsável por retirar o dinheiro da máquina. Proposta de Metodologia 71 Proposta de Metodologia 72 Resolução (usando a metodologia proposta): Passo 2: são identificados os principais casos (figura seguinte - diagrama de casos de uso preliminar). Neste passo é crucial a escolha do nível de granularidade adequado para captar os casos envolvidos. Note-se que o caso Repor Bebidas é realizado conjuntamente pelo agente do fornecedor de bebidas e pelo dono da máquina, este último responsável por abrir a máquina e supervisionar o processo envolvido. Resolução (usando a metodologia proposta): Passo 3: deve-se identificar comportamentos comuns realizados por mais que um dos casos do sistema. Neste exemplo, constata-se que os casos Repor Bebidas e Retirar Dinheiro envolvem dois tipos de ações comuns Abrir Máquina e Fechar Máquina. Este facto deve ser fatorizado através de dois casos de uso correspondentes e devem ser estabelecidas as respetivas relações de inclusão.

19 Proposta de Metodologia 73 Proposta de Metodologia 74 Resolução (usando a metodologia proposta): Passo 4: pressupõe na análise dos casos de uso existentes seja avaliada a necessidade da criação de pontos de extensão para um ou mais casos. Considere-se que o caso Repor Bebidas tem um ponto de extensão designado por encher prateleira, que permite associar ao caso de uso um ou mais casos abstratos que providenciem diferentes algoritmos para a reposição de bebidas nas prateleiras. Resolução (usando a metodologia proposta): Passo 4 (cont): Com o caso Repor Bebidas de Acordo com as Vendas, a reposição de bebidas na máquina tem em conta o número de bebidas vendidas (colocar mais latas das bebidas mais vendidas). Note-se que poder-se-iam definir outros casos de extensão abstratos, que implementavam diferentes algoritmos ou estratégias de reposição de bebidas; por exemplo: repor bebidas de forma uniforme (o mesmo número de latas, por tipo de bebida); repor bebidas de acordo com a marca; etc.