Business Informatics Group
Institute of Software Technology and Interactive Systems Vienna University of Technology
Favoritenstraße 9-11/188-3, 1040 Vienna, Austria
phone: +43 (1) 58801-18804 (secretary), fax: +43 (1) 58801-18896 office@big.tuwien.ac.at, www.big.tuwien.ac.at
Modelagem Orientada a Objetos
Diagrama de Casos de Uso
© BIG / TU Wien
Literature
§
The lecture is based on the following book:
§ Use Case Diagram
§ Structure Modeling
§ State Machine Diagram
§ Sequence Diagram
§ Activity Diagram
UML @ Classroom:
An Introduction to Object-Oriented Modeling
Martina Seidl, Marion Scholz, Christian Huemer and Gerti Kappel
Springer Publishing, 2015
ISBN 3319127411
© BIG / TU Wien
Conteúdo
§
Introdução
§
Casos de uso
§
Atores
§
Relacionamento entre casos de uso e atores
§
Relacionamentos entre casos de uso
§
Relacionamento entre atores
§
Descrição de casos de uso
§
Melhores práticas
§
Erros típicos
§
Elementos de notação
© BIG / TU Wien
Introdução
§
O caso de uso é um conceito fundamental de muitos métodos de
desenvolvimento orientado a objetos
§
Os diagramas de caso de uso expressam as expectativas dos
clients/partes interessadas
§
essencial para um desenho detalhado
§
O diagrama de casos de uso é utilizado durante todo o processo de
análise e desenho
§
Nós podemos utilizar um diagrama de caso de uso para responder as
seguintes questões:
§
O que está sendo descrito? (O sistema.)
§
Quem interage com o sistema? (Os atores.)
§
O que os atores podem fazer? (Os casos de uso.)
© BIG / TU Wien
Exemplo: Sistema de Administração de Estudantes
§
Sistema
(o que está sendo descrito?)
§
Sistema de administração de estudantes
§
Atores
(quem interage com o sistema?)
§
Professor
§
Casos de uso
(o que os atores podem fazer?)
§
Query student data
§
Issue certificate
§
Announce exam
© BIG / TU Wien
Caso de Uso
§
Descrevem a funcionalidade esperada parar o sistema sob
desenvolvimento
§
Fornece benefício tangível para um ou mais atores que comunicam
com este caso de uso
§
Derivado dos desejos identificados do clientes
§
Conjunto de todos casos de uso descrevem funcionalidade que um
sistema deve fornecer
§
Documento a funcionalida que um sistema oferece.
§
Notações alternativas:
Ator (1/3)
§
Atores interagem com o sistema…
§
utilizando casos de uso,
i.e., os atores iniciam a execução dos casos de uso.
§
sendo utilizados pelos casos de uso,
i.e., os atores fornecem funcionalidades para a execução dos casos de
uso.
§
Atores representam papéis que os usuários adotam.
§
Usuários específicos podem desempenhar múltiplos papéis
simultaneamente.
§
Atores não são parte do sistema, i.e., eles estão fora das fronteiras do
sistema.
§
Notações alternativas:
© BIG / TU Wien
Ator (2/3)
§
Usualmente dados dos usuários são geridos dentro do sistema. Estes
dados são modelados dentro do sistema na forma de objetos e classes
§
Exemplo: ator
Assistant
§
O ator
Assistant
interage com o sistema
Laboratory Assignment
utilizando-o .
§
A classe
Assistant
descreve objectos representando dados do usuário
(e.g., name, ssNr, …).
Ator (3/3)
§
Humano
§
E.g.,
Student
,
Professor
§
Não-humano
§
E.g.,
E-Mail Server
§
Primário
: recebe o benefício principal da execução do caso de uso
§
Secundário
: não recebe benefício direto
§
Ativo
: inicia a execução do caso de uso
§
Passivo
: fornece funcionalidade para a execução do caso de uso
Relacionamentos entre Atores e Casos de Uso
8
§
Atores são conectados com os casos de uso por linhas contínuas
(associações).
§
Cada ator precisa comunicar com, pelo menos, um caso de uso.
§
Uma associação é sempre binária.
§
Multiplicidades podem ser especificadas.
© BIG / TU Wien
§
O comportamento de um caso de uso (caso de uso incluído) é
integrado no comportamento de outro caso de uso (caso de uso base).
§
Exemplo:
Relacionamentos entre Casos de Uso
«include» - Relacionamento
10 Caso de uso base
requer que o comportamento do caso de uso incluído para que seja disponibilizada sua funcionalidade
Caso de uso incluído
© BIG / TU Wien
Relacionamentos entre Casos de Uso
«extend» - Relacionamento
11
§
O comportamento de um caso de uso (caso de uso extensor) pode ser
integrado no comportamento de outro caso de uso (caso de uso base)
§
Ambos casos de uso podem ser executados independentemente.
§
A
decide se
B
é executado.
§
Pontos de extensão definem em qual ponto o comportamento é
integrado.
§
Condições definem sob quais circunstâncias o comportamento é
integrado.
Caso de uso base
© BIG / TU Wien
Relacionamentos entre casos de uso
«extend» - Relacionamento: Pontos de Extensão
12
§
Pontos de extensão são escritos diretamente dentro do caso de uso.
§
Especificação de múltiplos pontos de extensão é possível.
© BIG / TU Wien
Relacionamento entre casos de uso
Generalização de Casos de Uso
13
§
Caso de uso
A
generaliza o caso de uso
B.
§
B
herda o comportamento de A
e pode
tanto estende-lo quanto sobrescreve-lo.
§
B
também herda todos os relacionamentos de A.
§
B
adota a funcionalidade básica de A
mas
decide qual parte de
A
é executada ou alterada.
§
A
pode ser rotulado{abstract}
§
Não pode ser executado diretamente
§
Somente
B
é executável
§
Exemplo:
Caso de uso base
© BIG / TU Wien
Relacionamento entre Atores
Generalização de Atores
14
§
Ator
A
herda do ator
B
.
§
A
pode comunicar com
X
e
Y
.
§
B
somente pode comunicar com
Y
.
§
Herança múltipla
é permitida.
§
Atores abstratos são possíveis.
§
Exemplo:
Super-ator
Sub-ator
ProfessorAND Assistant necessários para executar Query student data
© BIG / TU Wien
Descrição de Casos de Uso
§
Abordagem estruturada
§
Nome
§
Descrição suscinta
§
Pré-condição: pré-requisito para execução com sucesso
§
Pós-condição: estado do sistema após execução com sucesso
§
Situações de erro: erros relevantes para o domínio do problema
§
Estado do sistema na ocorrência de um erro
§
Atores que podem comunicar com o caso de uso
§
Gatilho: eventos que iniciam a execução do caso de uso
§
Processo padrão: passos individuais a serem realizados
§
Processos alternativos: desvios do processo padrão
[A. Cockburn: Writing Effective Use Cases, Addison Wesley, 2000]
© BIG / TU Wien
Descrição de Casos de Uso - Exemplo
§ Nome: Reserve lecture hall
§ Descrição: Um empregado reserva uma sala na universidade para um evento. § Pré-condição: O empregado está autorizado para reservar salas.
§ Pós-condição: A sala está reservada. § Situações de erro: Não há sala livre.
§ Estado do sistema na ocorrência de erros: O empregado não reservou a sala. § Atores: Employee
§ Gatilho: Empregado requer uma sala.
§ Processo padrão: (1) Empregado loga no sistema. (2) Empregado seleciona a sala de aula. (3) Empregado seleciona a data.
(4) Sistema confirma que a sala de aula está livre. (5) Empregado confirma a reserva.
§ Processos alternativos: (4’) Sala de aula não está livre.
(5’) Sistema oferece uma sala de aula alternativa.
(6’) Empregado seleciona a sala de aula alternative e confirma a reserva.
© BIG / TU Wien
Melhores Práticas
«include»
17
© BIG / TU Wien
Padrão da UML Melhor Prática
Melhores Práticas
«extend»
© BIG / TU Wien
Melhores Práticas
Identificando Atores
19
§
Quem usa o caso de uso principal?
§
Quem precisa de suporte para o seu trabalho diário?
§
Quem é responsável pela administração do sistema?
§
Quais são os dispositivos externos/sistemas de software com os quais
o sistema precisa comunicar?
© BIG / TU Wien
Melhores Práticas
Identificando Casos de Uso
20
§
Quais são as principais tarefas que um ator precisa realizar?
§
Um ator quer consultar ou mesmo modificar informação contida no
sistema?
§
Um ator quer informar o sistema sobre mudanças em outros sistemas?
§
Um ator deve ser informado sobre eventos inesperados dentro do
© BIG / TU Wien
Melhores Práticas
Erros Típicos para Evitar (1/5)
§
Diagramas de casos de uso não modelam processos/workflows!
© BIG / TU Wien
Melhores Práticas
Erros Típicos para Evitar (2/5)
22
© BIG / TU Wien
Melhores Práticas
Erros Típicos para Evitar (3/5)
23
§
Caso de uso
Issue information precisa de um ator
Assistant
OU
um ator
Professor
para execução
© BIG / TU Wien
Melhores Práticas
Erros Típicos para Evitar (4/5)
24
§
Muitos casos de uso pequenos que têm o mesmo objetivo podem ser
agrupados para formar um caso de uso
© BIG / TU Wien
Melhores Práticas
Erros Típicos para Evitar (5/5)
25
§
Os vários passos que são parte dos casos de uso, não separam os
casos de uso em si -> Não há decomposição funcional
© BIG / TU Wien
Nome
Notação
Descrição
Sistema
Fronteiras entre o sistema e os
usuários do sistema
Caso de uso
Unidade de funcionalidade do
sistema
Ator
Papéis dos usuários do sistema
Elementos de Notação (1/2)
© BIG / TU Wien
