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

Unified Modeling Language (UML) – Modelação do Comportamento –

Casos de Utilização (Use Cases)

Alberto Silva / José Borbinha

Análise e Concepção de Sistemas de Análise e Concepção de Sistemas de InformaçãoInformação

2

ACSI/UML-Dynamic, Copyright, Alberto Silva / José Borbinha

Modelação da Dinâmica do ComportamentoModelaçã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)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 CasesUse 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


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!

Use Cases - ActoresUse Cases - Actores

Cliente AlarmeAdministrador

6


Use Cases e CenáriosUse 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)Use Cases e Cenários (exemplo)

Cenário principal do use case “Fazer encomenda”

1. O caso inicia-se quando o cliente selecciona “Fazer encomenda”

2. O cliente introduz nome e endereço3. O cliente introduz os códigos dos

produtos desejados4. O sistema fornece descrição e preço

dos produtos5. O cliente selecciona os produtos

desejados6. O cliente fornece a informação do

cartão de crédito7. O cliente submete o pedido8. O sistema verifica a informação9. 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 Descrição Textual de Use CasesUse 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 Descrição Textual de Use Cases Use Cases (exemplo de(exemplo de “template”“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

1. The user indicates that the software is to perform a search-and-replace in the document.2. The software responds by requesting the search term and the replacement text.3. The user inputs the search term and replacement text and indicates that all occurrences

are to be replaced.4. The software replaces all occurrences of the search term with the replacement text.

Alternative Paths

1. 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.

2. 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.

3. 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


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

Descrição Textual de Descrição Textual de Use Cases Use Cases (exemplo de(exemplo de “template”“template”))

11


Fluxo de Eventos PrincipalO 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.

Descrição Textual de Descrição Textual de Use Cases Use Cases (exemplo)(exemplo)Validar Utilizador

12


Organização de Organização de Use CasesUse 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 Organização de Use CasesUse Cases

Packages :

Help-Desk

SubmeterPergunta Responder

Insistir emPergunta

Segurança

Efectuar Backup SubstituirPasswords

Auditar “Logs”

14


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

Organização de Organização de Use CasesUse Cases - Generalização - 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!!!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 Organização de Use CasesUse Cases - Generalização de - Generalização de ActoresActores

Cliente

Cliente VIP

generalização de actores

Cliente Anónimo

17


Organização de Organização de Use CasesUse Cases - Inclusão - 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


Use case “Obter Extracto de Conta”

Nome: Obter Extracto de ContaCená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.

Organização de Organização de Use CasesUse Cases - Inclusão - Inclusão

Validar UtilizadorObter Extracto de Conta

«include»

19


Organização de Organização de Use CasesUse Cases - Extensão - 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 lugarAtribui lugarà janela

«extend»

20


Organização de Organização de Use CasesUse Cases - Extensão - ExtensãoNome: Obter Extracto de ContaPontos de Extensão: Nº de diasCená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 Organização de Use CasesUse Cases - Extensão - ExtensãoNome: Selecciona N.º de DiasTipo: AbstractoCená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 1Idê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 2Idê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 3Idê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 Diagramas de Use CasesUse 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 CasesDiagramas 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

Use Case A

Actor

Use Case A

24


Diagramas de Use Cases - ExemploDiagramas de Use Cases - Exemplo

A Máquina de Bebidas

Cliente

Agente do Fornecedor

Comprar Bebida

Repor Bebidas

Retirar dinheiro

Colector

Dono

25




Cliente


Comprar Bebida

Repor bebidas

Retirar dinheiroColector

Dono

Inclusão...

Abrir a Máquina

Fechar a Máquina

«include»

«include»

«include»

«include»

26




Repor Bebidas Dono

Extensão...

Abrir a Máquina

Fechar a Máquina

«include»

«include»


Extension Pointencher prateleiras

Repor Bebidassegundo as vendas

«extend»(encher prateleiras)

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...

27


Exemplos Exemplos (certo/errado)(certo/errado)

28


Exemplo...Exemplo...

29


Exemplo...Exemplo...Name: Enroll in UniversityIdentifier: UC 19Description: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)Diagramas de Use Cases (uma metodologia)

1. Identificar os actores do sistema2. 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.

3. 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

4. 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.

5. 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

Documents

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