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
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
2
ACSI/UML-Dynamic, Copyright, Alberto Silva / José Borbinha
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.
3
ACSI/UML-Dynamic, Copyright, Alberto Silva / José Borbinha
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
4
ACSI/UML-Dynamic, Copyright, Alberto Silva / José Borbinha
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
ACSI/UML-Dynamic, Copyright, Alberto Silva / José Borbinha
Alarme
5
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
6
ACSI/UML-Dynamic, Copyright, Alberto Silva / José Borbinha
Use Cases e Cenários (exemplo)
1.
2.
3.
4.
5.
6.
7.
8.
9.
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
7
ACSI/UML-Dynamic, Copyright, Alberto Silva / José Borbinha
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...
8
ACSI/UML-Dynamic, Copyright, Alberto Silva / José Borbinha
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
1.
2.
3.
4.
Alternative
Paths
1.
2.
3.
Postconditions
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.
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.
All occurrences of the search term have been replaced with the replacement text.
ACSI/UML-Dynamic, Copyright, Alberto Silva / José Borbinha
9
Descrição Textual de Use Cases (exemplo de
“template”)
Elementos
Gerais
Use Case Name:
ID:
Primary Actor:
Use Case Type:
Importance Level:
Stakeholders and Interests:
Brief Description:
Trigger:
Relações
Relationships: (Association, Include, Extend, Generalization)
Normal Flow of Events:
Fluxo de
Eventos
Subflows:
Alternate/Exceptional Flows:
10
ACSI/UML-Dynamic, Copyright, Alberto Silva / José Borbinha
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.
11
ACSI/UML-Dynamic, Copyright, Alberto Silva / José Borbinha
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)
12
ACSI/UML-Dynamic, Copyright, Alberto Silva / José Borbinha
Organização de Use Cases
Segurança
Packages :
Efectuar Backup
Substituir
Passwords
Auditar “Logs”
Help-Desk
Submeter
Pergunta
Responder
Insistir em
Pergunta
13
ACSI/UML-Dynamic, Copyright, Alberto Silva / José Borbinha
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.
14
ACSI/UML-Dynamic, Copyright, Alberto Silva / José Borbinha
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.
15
ACSI/UML-Dynamic, Copyright, Alberto Silva / José Borbinha
Organização de Use Cases - Generalização de
Actores
generalização
de actores
Cliente
Cliente Anónimo
Cliente VIP
16
ACSI/UML-Dynamic, Copyright, Alberto Silva / José Borbinha
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)
17
ACSI/UML-Dynamic, Copyright, Alberto Silva / José Borbinha
Organização de Use Cases - Inclusão
Obter Extracto
de Conta
«include»
Validar Utilizador
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.
18
ACSI/UML-Dynamic, Copyright, Alberto Silva / José Borbinha
Organização de Use Cases - Extensão
Atribui lugar
à janela


«extend»
Atribui lugar
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”.
19
ACSI/UML-Dynamic, Copyright, Alberto Silva / José Borbinha
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.
20
ACSI/UML-Dynamic, Copyright, Alberto Silva / José Borbinha
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..
21
ACSI/UML-Dynamic, Copyright, Alberto Silva / José Borbinha
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.
22
ACSI/UML-Dynamic, Copyright, Alberto Silva / José Borbinha
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.
Use Case
A
Actor
Use Case
A
Actor
Use Case
A
Actor
ACSI/UML-Dynamic, Copyright, Alberto Silva / José Borbinha
23
Diagramas de Use Cases - Exemplo
A Máquina de Bebidas
Comprar Bebida
Cliente
Repor Bebidas
Agente do
Fornecedor
Dono
Retirar dinheiro
Colector
24
ACSI/UML-Dynamic, Copyright, Alberto Silva / José Borbinha
Diagramas de Use Cases - Exemplo
Inclusão...
A Máquina de Bebidas
Comprar Bebida
Cliente
Repor bebidas
Agente do
Fornecedor
Dono
«include»
Abrir a
Máquina
«include»
«include»
Retirar dinheiro
Colector
«include»
Fechar a
Máquina
25
ACSI/UML-Dynamic, Copyright, Alberto Silva / José Borbinha
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
«include»
Agente do
Fornecedor
Abrir a
Máquina
Repor Bebidas
Dono
Extension Point
encher prateleiras
«include»
«extend»
(encher prateleiras)
Fechar a
Máquina
Repor Bebidas
segundo as vendas
26
ACSI/UML-Dynamic, Copyright, Alberto Silva / José Borbinha
Exemplos
(certo/errado)
27
ACSI/UML-Dynamic, Copyright, Alberto Silva / José Borbinha
Exemplo...
28
ACSI/UML-Dynamic, Copyright, Alberto Silva / José Borbinha
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: …..
29
ACSI/UML-Dynamic, Copyright, Alberto Silva / José Borbinha
Diagramas de Use Cases (uma metodologia)
1.
2.
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.
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
30
ACSI/UML-Dynamic, Copyright, Alberto Silva / José Borbinha