Alberto Silva / José Borbinha

Apresentação em tema: "Alberto Silva / José Borbinha"— Transcrição da apresentação:

1 Alberto Silva / José Borbinha
Análise e Concepção de Sistemas de Informação Unified Modeling Language (UML) – Modelação do Comportamento – Casos de Utilização (Use Cases) Alberto Silva / José Borbinha

2 Modelação da Dinâmica do Comportamento
Use Cases (Casos de Utilização) Use Cases e Cenários Descrição textual de Use Cases Organização de Use Cases Diagramas de Use Case

3 Use Cases (Casos de Utilização)
A identificação de use cases deve ser feita durante a recolha e análise de requisitos (“...consultar o catálogo da loja...”, “...efectuar compra...”, “...pedir ajuda...”). Por ser mais genérica, a descrição dos use cases pode aparecer, na documentação de requisitos, antes da enunciação dos mesmos (na descrição geral do sistema), para ajudar ao entendimento do contexto. O modelo de use case ajuda a capturar os requisitos de um sistema, através do detalhe de todos os cenários que os utilizadores podem realizar. Os use-cases fazem a ponte entre os requisitos e a modelação do comportamento de um sistema. O modelo do comportamento (ou da dinâmica) de um sistema começa com a análise de use cases.

4 Use Cases Um use case representa um conjunto de acções que um ou mais actores realizam num sistema para obter um resultado concreto Um use case deve ser representado num modo impessoal, por uma frase na voz activa, com um verbo no infinitivo (“Gerar relatórios”, “Criar factura”, “Calibrar roda”) Um use case representa uma visão externa do sistema descreve o que faz um sistema (ou parte deste), não descreve como é que tal é realizado

5 Use Cases - Actores Actor
Representa uma função (ou papel) que um utilizador pode desempenhar relativamente ao sistema a modelar. O conjunto total de actores de todos os use cases reflecte todos os elementos que interactuam com o sistema. Um mesmo utilizador nominal pode desempenhar diferentes papéis, podendo, por conseguinte, representar diferentes actores. Um actor pode ser humano ou ser outro sistema! Cliente Administrador Alarme

6 Use Cases e Cenários Um cenário é uma instância de um use case quando este interactua com os actores. Determinada sequência de acções que ilustra um comportamento do sistema. É normal que um use case possa ser descrito por vários cenários Tipos de cenários: Principal: descreve a sequência normal de acções (happy day scenario) Alternativo ou secundário: descreve uma sequência de acções a considerar para além da principal, o que pode acontecer devido a excepções ou apenas para outras acções possíveis

7 Use Cases e Cenários (exemplo)
Cenário principal do use case “Fazer encomenda” O caso inicia-se quando o cliente selecciona “Fazer encomenda” O cliente introduz nome e endereço O cliente introduz os códigos dos produtos desejados O sistema fornece descrição e preço dos produtos O cliente selecciona os produtos desejados O cliente fornece a informação do cartão de crédito O cliente submete o pedido O sistema verifica a informação Quando o pagamento é confirmado criado e apresentado ao cliente um código do. Caso termina Cenários secundários do use case “Fazer encomenda” Informação do cartão de crédito incorrecta Pedido incompleto Cliente pretende pagar por cheque Cliente requer atendimento especial Endereço de entrega incompleto Produto já não comercializado Produto não existe em armazém Produto em promoção

8 Descrição Textual de Use Cases
Pode-se especificar o comportamento de um use case descrevendo textualmente o fluxo de eventos, de modo que um utilizador não técnico o possa entender. Tal especificação deve incluir: Assunções Pré-condições Inicialização: como e quando o caso de utilização começa Diálogo: quando é que o caso de utilização interactua com os actores Conclusão: como e quando o caso de utilização termina Pós-condições Outras formas: Actores que iniciam, que beneficiam... Diagramas de sequência e/ou de actividades...

9 Descrição Textual de Use Cases (exemplo de “template”)
Name UC-8: Search Summary All occurrences of a search term are replaced with replacement text. Rationale While editing a document, many users find that there is text somewhere in the file being edited that needs to be replaced, but searching for it manually by looking through the entire document is time-consuming and ineffective. The search-and-replace function allows the user to find it automatically and replace it with specified text. Sometimes this term is repeated in many places and needs to be replaced. Other times, only the first occurrence should be replaced. The user may also wish to simply find the location of that text without replacing it. Users All users Preconditions A document is loaded and being edited. Basic Course of Events The user indicates that the software is to perform a search-and-replace in the document. The software responds by requesting the search term and the replacement text. The user inputs the search term and replacement text and indicates that all occurrences are to be replaced. The software replaces all occurrences of the search term with the replacement text. Alternative Paths In step 3, the user indicates that only the first occurrence is to be replaced. In this case, the software finds the first occurrence of the search term in the document being edited and replaces it with the replacement text. The postcondition state is identical, except only the first occurrence is replaced, and the replacement text is highlighted. In step 3, the user indicates that the software is only to search and not replace, and does not specify replacement text. In this case, the software highlights the first occurrence of the search term and the use case ends. The user may decide to abort the search-and-replace operation at any time during steps 1, 2 or 3. In this case, the software returns to the precondition state. Postconditions All occurrences of the search term have been replaced with the replacement text.

10 Descrição Textual de Use Cases (exemplo de “template”)
Use Case Name: ID: Importance Level: Primary Actor: Use Case Type: Stakeholders and Interests: Brief Description: Trigger: Relationships: (Association, Include, Extend, Generalization) Normal Flow of Events: Subflows: Alternate/Exceptional Flows: Elementos Gerais Relações Fluxo de Eventos

11 Descrição Textual de Use Cases (exemplo)
Validar Utilizador Fluxo de Eventos Principal O caso de utilização inicia-se quando o sistema apresenta um écran a pedir ao cliente o seu cartão electró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 activar o botão “Entrar”. O cliente activa o botão “Entrar” para confirmar. O sistema lê o PIN e a respectiva 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 utilização termina. Cenário Alternativo 1 (Cliente cancela operação) O cliente pode cancelar a transacção em qualquer momento activando o botão “Cancelar”, implicando a reinicialização do caso de utilização. 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 é ejectado e o caso de utilização reinicializado. Se tal ocorrer 3 vezes consecutivas, o sistema cativa (i.e., “recolhe”) o cartão MB e cancela a transacção, não permitindo qualquer interacção nos 2 minutos seguintes.

12 Organização de Use Cases
Os use cases podem ser organizados : Agrupados em “packages” Em diagramas especificando relações entre casos de utilização do tipo generalização, inclusão (include) e extensão (extend)

13 Organização de Use Cases
Packages : Segurança Efectuar Backup Substituir Passwords Auditar “Logs” Help-Desk Submeter Pergunta Responder Insistir em Pergunta

14 Organização de Use Cases - Generalização
Uma relação de generalização entre casos de utilização permite definir casos à custa de outros já existentes, pelo mecanismo de especialização, ou alternativamente, permite definir casos mais abstractos a partir de casos concretos pelo mecanismo da redução ou generalização O use case filho herda o comportamento e semântica do seu pai; o filho pode substituir especificações definidas no seu pai.

15 Use Cases – um parênteses importante!!!
Relembremos: “Um use case é uma sequência de acções que um ou mais actores realizam num sistema para obter um resultado concreto” Tendo em consideração esta definição, “Validar Utilizador” não deverá ser encarado como um “verdadeiro” caso de utilização, já que por si só não produz qualquer “resultado particular” para o sistema. Contudo, nalgumas circunstâncias estes “pseudo” casos de utilização usam-se no modelo para explicitar comportamentos comuns a vários casos de utilização. Em alternativa, tais comportamentos poderão alternativamente ser especificados através de assunções, ao nível de cada caso ou mesmo ao nível geral do modelo.

16 Organização de Use Cases - Generalização de Actores
Cliente generalização de actores Cliente Anónimo Cliente VIP

17 Organização de Use Cases - Inclusão
A relação de inclusão entre casos de utilização corresponde a uma relação típica de delegação, significando que o caso base incorpora o comportamento do outro caso relacionado. Usa-se a relação de inclusão para evitar descreverem-se os mesmos fluxos de eventos inúmeras vezes… (reutilização)

18 Organização de Use Cases - Inclusão
Use case “Obter Extracto de Conta” Nome: Obter Extracto de Conta Cenário Principal: Incluir caso de utilização “Validar Utilizador”. Obter e verificar o número da conta. Seleccionar 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, ejectando no terminal de Multibanco o referido documento. Apresentar mensagem no visor do terminal para o cliente retirar o extracto. Registar na conta do cliente que esta operação foi realizada com sucesso. Obter Extracto de Conta «include» Validar Utilizador

19 Organização de Use Cases - Extensão
Numa relação de extensão o caso base incorpora implicitamente o seu comportamento num local especificado indirectamente pelo caso que o usa. Ou seja, um 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 sub-fluxo de acções que é executado apenas se determinadas condições se verificarem. Vários fluxos de acções que podem ser inseridos num determinado ponto de extensão, de forma controlada, através de uma interacção explícita com um actor. O use case de base é estendido num ou mais pontos, designados por “pontos de extensão”. Atribui lugar à janela «extend» Atribui lugar

20 Organização de Use Cases - Extensão
Nome: Obter Extracto de Conta Pontos de Extensão: Nº de dias Cenário Principal: Incluir caso de utilização “Validar Utilizador”. Obter e verificar o número da conta. Seleccionar o n.º de dias com base no qual se produz o extracto. (N.º de dias). Por omissão são seleccionados 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 ejectando no terminal de Multibanco o referido documento. Apresentar mensagem no visor do terminal para o cliente retirar o extracto. Registar na conta do cliente que esta operação foi realizada com sucesso.

21 Organização de Use Cases - Extensão
Nome: Selecciona N.º de Dias Tipo: Abstracto Cenário Principal É apresentado um écran 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 respectivo ponto de extensão.  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..

22 Diagramas de Use Cases Um diagrama de use cases ilustra um conjunto de Use Cases, de Actores, e as suas relações. Estes diagramas têm duas aplicações comuns: Modelação do contexto de um sistema; ênfase na identificação da fronteira do sistema, dos seus actores e no significado das suas funções. Modelação dos requisitos de um sistema; consiste na identificação do que o sistema deve fazer, independentemente de como o sistema o deve realizar.

23 Diagramas de Use Cases Um diagrama de Casos de Utilização é utilizado para ilustrar a interacção entre os actores e os casos de utilização pelo envio recíproco de “estímulos”. Uma associação de comunicação entre um actor e um caso de utilização implica uma interacção entre ambos. Cada função nesta associação tem uma propriedade de navegação, que indica a direcção da comunicação. Se for bidireccional, omite-se a representação da direcção. Actor Use Case A Actor Actor Use Case A Use Case A

24 Diagramas de Use Cases - Exemplo
A Máquina de Bebidas Cliente Comprar Bebida Agente do Fornecedor Dono Repor Bebidas Colector Retirar dinheiro

25 Diagramas de Use Cases - Exemplo
Inclusão... A Máquina de Bebidas Cliente Comprar Bebida Agente do Fornecedor Repor bebidas Dono «include» Abrir a Máquina «include» «include» Colector Retirar dinheiro Fechar a Máquina «include»

26 Diagramas de Use Cases - Exemplo
Extensão... A possibilidade da reposição de bebidas na máquina depender agora de um algoritmo dependente das marcas e do número de latas vendidas... A Máquina de Bebidas Abrir a Máquina «include» Dono Repor Bebidas Agente do Fornecedor Extension Point encher prateleiras «include» «extend» (encher prateleiras) Fechar a Máquina Repor Bebidas segundo as vendas

27 Exemplos (certo/errado)

28 Exemplo...

29 Exemplo... Name: Enroll in University Identifier: UC 19 Description:
Enroll someone in the university. Preconditions: The Registrar is logged into the system. The Applicant has already undergone initial checks to verify that they are eligible to enroll. Postconditions: The Applicant will be enrolled in the university as a student if they are eligible. Basic Course of Action: 1.      An applicant wants to enroll in the university. 2.      The applicant hands a filled out copy of form UI13 University Application Form to the registrar.  [Alternate Course A: Forms Not Filled Out] 3.      The registrar visually inspects the forms. 4.      The registrar determines that the forms have been filled out properly.  [Alternate Course B: Forms Improperly Filled Out]. 5.      The registrar clicks on the Create Student icon. 6.      The system displays UI89 Create Student Screen. 7.      The registrar inputs the name, address, and phone number of the applicant. [Extension Point: UC34 Perform Security Check. Applicable to Step 17] 8.      The system determines that the applicant does not already exist within the system according to BR37 Potential Match Criteria for New Students. [Alternate Course F: Students Appears to Exist Within The System]. 9.      The system determines that the applicant is on the eligible applicants list.  [Alternate Course G: Person is Not Eligible to Enroll] 10.   The system adds the applicant to its records.   The applicant is now considered to be a student. 11.   The registrar helps the student to enroll in seminars via the use case UC 17 Enroll in Seminar. 12.   The system calculates the required initial payment in accordance to BR16 Calculate Enrollment Fees. 13.   The system displays UI15 Fee Summary Screen. 14.   The registrar asks the student to pay the initial payment in accordance to BR19 Fee Payment Options. 15.   The student pays the initial fee.  [Alternate Course D:  The Student Can’t Pay At This Time] 16.   The system prints a receipt. 17.   The registrar hands the student the receipt. 18.   The use case ends. Alternate Course A: …..

30 Diagramas de Use Cases (uma metodologia)
Identificar os actores do sistema Identificar, para cada actor, os seus casos de utilização principais Note-se que podem existir casos que envolvam a participação de mais que um actor. Factorizar: identificar relações de inclusão Com base nos casos de utilização originais, identificar, factorizar e colocar em evidência casos de utilização que sejam recorrentes em mais que um dos casos originais. Nessa situação, cria-se o novo caso de utilização (em geral é um caso abstracto) 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 Flexibilizar: identificar relações de extensão Para tratar casos de utilização que pretendam ser flexíveis e versáteis, definir pontos de extensão (ou de variabilidade) e conjuntamente definir um ou mais casos de utilização (abstractos) que os permitam estender nesses pontos. Nesta situação, cria-se uma relação de extensão do caso abstracto para o caso estendido. Especificar textualmente cada caso de utilização Seguir um formato previamente definido; não esquecer a explicitação dos pontos de extensão e de inclusão anteriormente identificados