Diagrama de Casos de Uso

:s

=<: =- ~

=--

"" ~ :li: i z... a;

~~ '~

<: > li: 11li~ ... :E

=-~ li

s ir

=-~ 15.. o '"o

:11I

;li

=:11

:11

==:11

:iI

:11

:.w :11

d

L1ML -1550

3.1. Conceitos e Componentes do Diagrama de Casos de USO

Bloco de Construção do Aprendizado

INSTITUTO INFNET ·115

oi c !:i o.« o« o :> c w

tu lL ~L z

a: o n, cn o c « ii: w tn w a:. o.« tn tn o l:: w a: C tn o tn o c o I

UML-1550

Coisas da UML

• A UML define "coisas" (things) que podem ser usadas em vários diagramas:

• Estereótipos: são extensões de elementos do modelo.

• Anotações: textos que podem ser colocados em qualquer parte do diagrama e que contém informações adicionais sobre o diagrama.

116

• Estereótipo:

-<-<aetor><=Usuário~

Usuário

• Anotação:

o usuário deve~

estar logado

para usar esta

opção.

A UML define "coisas" que podem ser usadas para aumentar a clareza e significado dos diagramas:

Estereótipos

Os estereótipos são extensões de elementos do modelo. Podem ser usados para denotar especializações significativas de classes. Os atores, por exemplo, são tratados pelas ferramentas de modelagem como classes estereotipadas.

Os estereótipos podem ser indicados através de ícones próprios, ou incluindo-se o nome do estereótipo em aspas francesas (os caracteres «», representados nos desenhos por« »). Existem estereótipos pré-definidos e há a possibilidade de criar novo estereótipo para diferenciação de elementos do modelo, ampliando assim a definição de especificações de maneira gráfica.

Anotações

As anotações são pequenas caixas que podem ser utilizadas em qualquer ponto de qualquer diagrama. Elas são preenchidas com informações relevantes ao leitor. Sugere-se que anotações sejam usadas em casos bem específicos para não poluir demais os diagramas.

Ivar Jacobson propõe a divisão das classes deanálise de acordo com estereótipos que foram incorporados ao padrão oficial da UML. Esses estereótipos são: Entidades ou Entity(tabelas), Fronteiras ou Boundary(telas) e de Controle ou Control(conexão com banco, gerenciador de impressão, ...).

INSTITUTO INFNET - 116

E-

-~I~-

::J

=z -:i ~ o < o

~ j1:3 «

.tl. Z .L.

~

:t ..29 :<

..""...:3 >

... "" <: ..'" o:3 'ii

~ :t c lO::I .:;; '5

~

:3

~

:3

:I

~

=a :I

: :I

:11 ;ti

d

UML-155D

Casos de USO: Conceitos • Um caso de uso descreve o comportamento do

sistema do ponto de vista do usuário, fornecendo uma descrição funcional.

• Este diagrama descreve interações do sistema com o exterior (atores).

• Novas funcionalidades são agregadas ao contexto com a inclusão de novos elementos no diagrama.

• Finalidade: - Descrever os requisitos funcionais do sistema - O que o

sistema deve fazer; - Descrever claramente as responsabilidades que devem

ser cumpridas pelo sistema. 117

o diagrama de caso de uso descreve as funcionalidades do sistema com suas interações com o mundo exterior. Representa uma visão de alto nível da funcionalidade do sistema.

No desenvolvimento de novas versões do sistema, novas funcionalidades são agregadas ao contexto através da inclusão de novos elementos no diagrama.

Tem por finalidade:

• Descrever os requisitos funcionais do sistema de maneira consensual entre usuários e desenvolvedores;

• Descrever claramente as responsabilidades que devem ser cumpridas pelo sistema;

Também pode ser usado na modelagem de negócio. Esta atividade visa o desenho do processo, independente da implantação de sistemas, com o objetivo de:

• Mostrar à empresa uma visão do que o mundo externo ganha ao se relacionar com a empresa.

• Entender e documentar o que a empresa faz.

• Auxiliar no trabalho de reengenharia.

A modelagem de negócios ou comercial abrange um nível maior dentro da empresa do que a simples modelagem do sistema a ser desenvolvido. Ela é utilizada para mapear os processos da empresa e mostrar como a mesma funciona.


:eb

<i. :;'" o.« ~ U => w '" ti; u,

~L z

a: o Q.

s « '" >a: w w '" ÇI: o.« '" o '" l:: w a: Õ

o '" o '" o '" I-

UML-1550

Componentes.

• Em um diagrama de caso de uso aparecem o ator, gerador de estímulos no sistema, e o

~processo que vai absorver esses estímulos, o -caso de uso propriamente dito.

t}""l ",Y-t'....((~·

F 10'" '-'.. t-,"

"ri/ ~~~Y~ri~ t: ;',~~' C=~i

~lf (j9'1_-------.;.. cas: de :80 \idJ e _ _l~') Ator ~

, 't:

118

Ator - Agente que irá interagir com o sistema

Comunicação, Interação ou Estímulo - Comunicação do ator com o sistema

Caso de Uso - Funcionalidade do sistema

~-~-~-


-=:11

::...:11 <

~ '-" ~ Li:~ Z "" .L

=-~

~ L lO

>2 ;q

=- .. > :I: .u..u

.. :I:

.. ::>:I <

:;;

s ~

~ § ;::

:I

:I

:I

:I

:I

:t :t :J

, :3

, , !i-

UML-1550

Conceito de Ator

• Ator é um agente que interage com o sistema;

• Um ator é uma classe, não uma instância. -6

• Representa uma regra, um papel e não um usuário individual do sistema.

• O nome do ator deve refletir o seu papel.

• Exemplos de atores: operador, cliente, gerente, atendente, consultor, sistema financeiro, sistema contábil, tempo, balança eletrônica, sensor de temperatura.

I 119 i

Ator é um agente que interage com o sistema, mandando ou recebendo mensagens, trocando informações com o sistema. Representa o mundo externo, podendo ser pessoas, máquinas, dispositivos ou outros sistemas - alguns atores típicos são operador, cliente, gerente, computador, impressora, dispositivo de comunicação de rede.

Um ator é uma classe e não uma instância. Representa uma regra, um papel e não um usuário individual do sistema. Um usuário pode desempenhar vários papéis e um papel pode ser representado por vários usuários. O nome do ator deve refletir o seu papel.

INSTITUTO INFNET -119

<i. c ~ o '<1;

~ o ::> c UI

Iii z u,

~ o: O <l. CIJ O C <I;

6: UI CIJ UI o: O '<1;CIJ CIJ O

m o: C CIJ O CIJ O C O t

UML-1550

iiii iiii

...Atores

• Um Ator é uma classe com um ícone padrão.

• Exemplos de atores:

~ ~ ~ ~ ~ cliente gerente usuário vendedor correntista

~ ~ ~ ~ ~ sistema contábil ba1ança sensor robô 'WIE!b service ;:-

120

~-Em UML, um ator é uma classe com um ícone padrão que pode conter atributos e

relacionamentos. Permite relacionamento de generalização, que são usados para descrever características comuns entre vários atores.

A figura mostra exemplos de atores de vários sistemas:

• o cliente, o gerente e o vendedor de um loja; .... • o usuário de uma agenda eletrônica;

• o correntista e o sistema contábil de um banco;

• uma balança eletrônica de um sistema de controle de cargas;

• o sensor de temperatura de uma usina atômica;

• o robô de uma linha de montagem de carros;

• qualquer web service de uma operação entre empresas (B2B). E-~-jiiiii-

INSTITUTO INFNET· 120 E-

:51

=:51

~

:iI

~

==~

31

--~

ia

=:11

-:=11 li

< o ..... ..J

o o« c..> -c o :::l C U l-U Z L

ó?i :: D e,

~ C CC :> ..:m: ~

~

.."" O o« .. O

:ui

.. :t: 3:

..OO O

~

Como Identificar os Atores ,

• Para facilitar a identificação dos atores faça as seguintes perguntas: \

I- Quem irá usar as funcionalidades básicas do sistema?

- Quem irá administrar e manter o sistema? \- Quais os dispositivos de hardware necessários I

: r

Ipara o sistema?

- O sistema irá interagir com outros sistemas?


c

 « U ::> o W fW Z u, :!E a: o a. UJ o « >a: W UJW' a: o.« UJ (f)

o !:: W c:: Õ (f)

o UJ o Cl o f

lIML-I550

Caso de Uso /

• E uma seqüência de ações que um sistema desempenha para produzir um resultado observável por um ator específico.

• O nome do Caso de Uso deve ser uma frase ~-indicando a ação que realiza. '.t:• Um caso de uso é um conjunto de passos e

o tratamento das suas exceções.

I----------------~----------- 124

o Caso de USO em si é uma sequência de ações que um sistema desempenha para produzir um resultado observável por um ator específico. Em outras palavras, um caso de uso define uma funcionalidade do sistema com um conjunto de ações tomadas pelo ator e a previsão da reação por parte do sistema.

O Caso de Uso é uma classe, não uma instância. A sua especificação descreve a funcionalidade como um todo, incluindo erros, possíveis alternativas e exceções que podem ocorrer durante sua execução. O nome do Caso de Uso deve ser uma frase indicando a ação que realiza.

Cuidado para não identificar um caso de uso no lugar de um passo! Um caso de uso tem um conjunto de passos e trata as exceções desses passos. Na descrição do caso de uso é que teremos que pensar quais as ações que o caso de uso desempenhará.

E-INSTITUTO INFNET • 124

E-

:9

::! <i. I ..J:=i Cl

o o« o« o Cl W I::i ::J

W Z u,

as o o..::I tI:

rn o Cl « >tI: W

~ rn w tI: o o« rn o I::I rn

Ui tI: Õ

rn O::s Orn

Cl O I

::t

::I

::I

::I

::I

:3

=t =t :=I

:=:t :I

UML -1550

Exemplos de Casos de USO

125

A figura acima mostra exemplos de casos de uso de vários sistemas:

• Supermercado: Fechar caixa

• Universidade: Fazer Inscrição

• Financeira: Aprovar Crédito

• Banco: Incluir Movimento, Depositar

• Qualquer sistema: gerar estatísticas.

Repare que todos os casos de uso citados são operações complexas que englobam diversas atividades, tanto por parte do sistema, quanto dos atores envolvidos. Pode-se dizer que um caso de uso é uma conversa completa entre o ator e o sistema.

:t ~


a: w ffl a: o.« CIl CIl o l m a: E CIl o CIl o o o I

UML-1550

Características e Regras • É sempre inicializado por um ator e devolve uma resposta.

• São conectados aos atores com associações de comunicação. A associação é bidirecional. ~-• Um caso de uso tem início, meio e fim.

~-Consultar C1ientes

gerente E-126

~-Um caso de uso, como dito anteriormente, representa uma funcionalidade do sistema: tem

início, uma entrada, uma solicitação, tem meio, um processamento, uma gravação e tem um fim, uma confirmação, uma impressão, o resultado de uma consulta na tela.

A figura mostra dois atores interagindo com o sistema. A operação "Consultar Clientes" pode ser executada tanto por funcionário quanto por gerente. A operação "Cadastrar Cliente" pode ser efetuada apenas pelo ator funcionário, enquanto "Consultar Crédito" só pode ser iniciada pelo gerente.

Repare que não há indicação de ordem no diagrama, apenas as funcionalidades principais do ponto de vista dos atores.

INSTITUTO INFNET - 126 E-

:11

::11I -:11I ~

c .:> c

Oi::11I ;;: z... '.: i::11 ~

,!

> li:

.li.:11I ... <

'" li:

'" !:11. <:

:ir l§

~ =- ~

=====:li

=:11

,.3

:11

:11

:!I

UML-1550

Estímulos • Um ator se comunica com o sistema enviando e recebendo

mensagens para um Caso de Uso.

• Mensagens =Estímulos.

• Existem dois tipos de atores:

- Ativos, iniciam algum Caso de Uso.

- Passivos, recebem mensagens de um Caso de Uso.

Ator Passivo

------<~uar vV·_-+ caixa Sistema Financeiro

127

Um ator se comunica com o sistema enviando e recebendo mensagens - estímulos - para um caso de uso, que é ativado. Além do ator que o inicializou, o caso de uso pode mandar mensagens para outros atores.

Os atores são chamados de ativos quando iniciam algum caso de uso e passivos quando somente participam dele, sem iniciá-lo. Atores passivos recebem mensagens, portanto em um diagrama são identificados por setas que chegam até eles.

Atores passivos são, de maneira geral, dispositivos de hardware ou outros softwares com o qual o sistema se conecta. Por exemplo, em uma operação de venda, deve ser gerado um movimento financeiro:


ci " ~ o

'<1: o<I: tJ ::> w " fw Z U-

i!: te o "'"o "<I:

1é w w '" te

'o '<1:

'" '"o !::: w te iS

o'"'""oo

f-

UML -155{;1

Relacionamentos

• Os relacionamentos indicam a existência de comunicação entre atores e casos de uso.

• Um caso de uso pode estar associado a mais de um ator. iiii

• A comunicação será representada como -ligação sem direção,(êíilgeral. E

-, -• Quando a iniciativa parte o caso de uso a

comunicação deve ser direcionada por uma seta.

128

E-Relacionamentos ~-

Diagramas de casos de uso podem especificar os relacionamentos entre casos de uso e atores. Os relacionamentos indicam a existência de comunicação entre atores e casos de uso. Um caso de uso pode estar associado a mais de um ator, quando a sua execução requer a participação de diferentes atores.

~-

r-


::!

::i

:=i oi. Q ..... ~

o -:(

'O<t U :::> Q !.U::I ..... W Z

o: o e,::I u,

z

'"o Q

<t o: w:::I >

I;!J '" o: o

'":!i <

e '"ii o: E

o::I '" '"o Q

o l

:::I

~

~

~

==ti

::li

::11

=:;li

:11

UML-1550

Generalização

• Os diagramas de casos de uso podem ser simplificados por meio da herança entre atores.

gerente

129

gerente financeiro

Os diagramas de casos de uso podem ser simplificados por meio da herança entre atores. Neste caso, mostra-se um caso de uso comum aos atores específicos, que se comunicam apenas com o ator genérico.

A figura mostra as especializações de "Gerente" em "Gerente de Compras" e "Gerente Financeiro". Trata-se de uma relação de herança entre os atores, ou seja, todas as características e funções de "Gerente" serão herdadas pelos atores que estão abaixo dele.

Na figura abaixo é mostrado outro exemplo, usado principalmente em sistemas que possuem diferentes níveis de permissão de uso:

~ Secretária

fJ ~ <l ~

Supervisor Diretor

A secretária pode usar algumas runcionanuaoes ao sistema, o supervisor pode usar as mesmas da secretária além de outras específicas e o diretor pode usar funcionalidades dos dois e suas específicas.


::li

~

<i. c ~ o

'00: o00: o :::> c w

lü z lL

~ a:: o c.. CIl o c 00: >a:: w CIl

.l:! o '00: CIl

s ~

Ui a:: 15 CIl o CIl o c ~

L1ML -155:D

Generalização

Sí.JTwlar lil.uxo de

Caixa

130

!J"!rente de cOJlI:Iras gerent.e gerent.e ~inanceiro

Na figura acima, os dois gerentes podem consultar a avaliação de desempenho de seus subordinados além de suas tarefas específicas. Portanto, para simplificar o diagrama é criado um ator genérico e feita a herança (generalização). Assim, as tarefas comuns são ligadas ao ator genérico e as outras para os seus respectivos atores.

Outro exemplo, um sistema de controle acadêmico de urna escola. A única operação que urna secretária pode fazer é "Matricular Aluno". O supervisor também matricula alunos, mas também contrata professores e agenda cursos. O diretor pode fazer tudo isso e também consulta inadimplências.

Matricular JIl. uno

<J-- <Jr---Secret.ária Supervisor Diretor

Cont.ratar Pro~essor


I

I

I

;1

I

i

I

I

I•

i li!

I·

•4

:=li

::11 ~ ::I:3 ~

-e o<::: ir::li ...ll

=-Z

.;<!;

~ :t ::I :::l

>

:ti ~

<

'" fi

::I o< :t

ã~ ~ :;

'"o '"~ :::l o o ....

~

~

=:3

~

:=11

:li

:iI

:iI

~

::11

:11

=

UML-1550

Casos de USO Secundários

• Casos de uso secundários são utilizados para facilitar a descrição de funcionalidade mais complexa.

• Simplificam o comportamento dos casos de uso primários através dos mecanismos de Extensão e Inclusão.

131

Notações especiais são utilizadas para facilitar a descrição de funcionalidade mais complexa. Entre estas notações, destacam-se os casos de usos secundários, que simplificam o comportamento dos casos de uso primários através dos mecanismos de extensão e inclusão.

Casos de uso primários são aqueles invocados por iniciativa direta de um ator; casos de uso secundários são invocados em um passo de outro caso de uso. Os termos "primário" e "secundário", quando referentes a casos de uso, não fazem parte da especificação da UML.


<i. c !:i o '<t o...: o :J C W ~ W Z LI.

~ a: o c,

Ul o c <t >a: w 'ffia: o '<tUl Ul o !::: w a: Õ Ul o Ul o c o ~

UML-I550

Extensão

• Essa notação pode ser usada para representar fluxos complexos opcionais.

• O caso de uso "estendido" é referenciado nas precondições do caso de uso "extensor".

~~---------Gir Nota ~ ~<extend»

Caixa

132

o caso de uso B estende o caso de uso A quando B representa uma situação opcional ou de exceção, que normalmente não ocorre durante a execução de A. Essa notação pode ser usada para representar fluxos complexos opcionais ou anormais.

A operação "Emitir Nota Fiscal" é uma funcionalidade que pode ser invocada ou não, durante a operação "Efetuar Venda". Isso é verdade quando um produto é vendido com uma notafiscal manual, no caso de compra de um eletrodoméstico. Nesse caso, o sistema não deverá emitir a nota-fiscal a fim de evitar duplicidade de informações.

Observe também que o caso de uso que estende tem uma relação de dependência com o caso de uso estendido (seta tracejada), ou seja, a 'Emitir Nota Fiscal' só pode ser executada se a operação 'Efetuar Venda' for executada.

Na figura abaixo é mostrado o diagrama de um blog no qual o visitante acessa determinado blog e pode ou não escrever comentários.

C::=.c_n~ >, ,

Visitante


I:

C

C

c: f

C

t

t:

C

r:

:2

:li

:11 -~

.:< o

iL::11I i

~

z

:2 ... :i!: ~ i:

i > E .u.:ti ..<:

.u. E

=ti .:<.. ! :ir

3

o:a ""5

5

::11

::11

:2

=:li

:ti

::li

::11

::11I

::11

::11

:11

UML-1550

Inclusão • Essa notação pode ser usada para representar subfluxos

complexos e comuns a vários casos de uso.

• O caso de uso "incluído" é referenciado no fluxo do caso de uso "que inclui".

~ ~"'~""V.. • - «Include»Super~sor ~-_

• - - --.Jo.

GxarEsto~ «include»

_,S?'

---Guarv~' caixa

133

o caso de uso A inclui o caso de uso B quando B representa urna atividade complexa, comum a vários casos de uso. Essa notação pode ser usada para representar subfluxos complexos e comuns a vários casos de uso. O caso de uso "incluído" é referenciado no fluxo do caso de uso "que inclui".

"Baixar Estoque" representa um comportamento comum a "Fazer Inventário" e "Efetuar Venda",

Observe também que o caso de uso que inclui tem urna relação de dependência com o caso de uso incluído (seta tracejada). Ou seja, "Fazer Inventário" e "Efetuar Venda" só podem ser executadas se "Baixar Estoque" também puder.

No exemplo abaixo, urna empresa que passou por dificuldades financeiras baixou urna norma que obriga a todo funcionário solicitar a aprovação de despesas antes de efetuar urna compra.


~

<i. c !:i o.« ~ g c W I W Z u, ~ o: o l1. (J)

o c « 6: w (J) W 0:' o.« (J)

(J)

o l-m o: Õ (J)

o (J)

o c o I

UML-1550

Desenho do Diagrama • 10 Identificar os Casos de Uso

- A identificação consiste em definir uma lista com os possíveis casos de uso.

- Uma vez identificado os atores, as seguintes perguntas auxiliarão na identificação dos Casos de Uso:

• O que (quais funções) o ator necessita do sistema? • O ator necessita criar, modificar, excluir, ler ou armazenar

informações no sistema? • O ator precisa ser notificado sobre eventos do sistema ou

informar o sistema sobre algo? • O trabalho do ator poderia ser simplificado ou mais eficiente

através de novas funções do sistema? Quais? • Quais entradas e saídas, juntamente com a origem e destino

que o sistema requer?

138

o primeiro passo para se chegar ao desenho do diagrama de caso de uso é a identificação dos casos de uso. Já visto que um caso de uso é uma funcionalidade no sistema, (tem início, meio e fim) o que temos que fazer é tentar identificar quais serão os casos de uso a serem descritos para o sistema a ser desenvolvido.

A identificação dos casos de uso (use cases) não é trivial mas se toma mais fácil com a prática.


EiUs

~-

-=~-r-

~-

2

::J

::I 

'" "" o o« :c

'"o::I .... i:i

Q'"

:11 '"'"oo :::: o ....

:11

:11

::I

:11I

:11I

====:I

UML-1550

Exemplo: Sistema de Help Desk

Eventos Casos de Uso At~C' ~ ""'

Vendedor fecha contrato Fechar Contrato IVendedor \ "I

Vendedor cadastra cliente Cadastrar Cliente \ Vendedo~,/

Cliente solicita serviço Solicitar Serviço (élie~ Supervisor aloca técnico Alocar Técnico ~/-Técnico finaliza serviço Finalizar Serviço (f' .ecn~Q <,

Supervisor consulta pendências

Consultar Pendências Supervisor

Cliente paga conta Pagar Conta Cliente

139

A tabela acima mostra os eventos, casos de uso e atores de um sistema de controle de help desk. Os casos de uso sempre tem um ator que os inicia.

Note que cada caso de uso tem varias ações a serem executadas, é composto de começo meio e fim. Por exemplo, para cadastrar o cliente deve ser verificado se o CPF (ou matrícula) do cliente já está cadastrado, a busca do endereço através do CEP, e existe a digitação dos dados propriamente dita.

:I ~

INSTITUTO INFNET· 139

PWI.A .4" 4J $--44=

 a w ];j z u,

~ c: O

"" cn O a <l: >c: w cn w c: O ~ cn O l:: w c: C cn O cn O a ~

UML-1550

Desenho do Diagrama

• 2° Descrever os Casos de USO

- Consiste em descrever a interação entre o caso de uso e o ator, o passo a passo que espera ser executado se der tudo certo (curso ou fluxo principal) e suas possíveis exceções caso ocorra algum problema (~~$iygsJ.

- A descrição servirá para validar a existência do caso de uso e também seu possível desmembramento.

140

É através da descrição do caso de uso que descobrimos se o caso de uso está complexo ou se ele na verdade é um passo de outro caso de uso. Por exemplo 'Imprimir boleto' é um caso de uso? Se a conotação for o ordenamento dos dados para uma impressora então possivelmente este é um passo de outro caso de uso, como por exemplo 'Visualizar boleto' que tem uma ação de impressão que pode ser executada ou não.

A atividade 'Imprimir boleto' pode ser um caso de uso que busque dados da compra (valor a ser pago, data de pagamento) a partir do identificador do cliente e gere o código de barras a partir destas informações para visualização em tela e impressão.

=itilli ==

~ - -

;

INSTITUTO INFNET • 140

= :I

<é I -'::i Cl

o <

= c>o « ::> Cl W I W Z u..

o:: o O:::I ~

'"o Cl

>o:: w::I '"

«

w o:: o

'" I :i <

o'"iii o:: 2i

o::I '" '"o

Cl o I

~

:I

::J

::I

:I

=t

::i

:r::I

=' ::i

::i

::i

UML-1550

Desenho do Diagrama

• 2° Descrever os Casos de USO

- A descrição dos casos de uso pode incluir: • as suas precondições, ou seja, as condições que

supõem estejam satisfeitas, ao iniciar a execução de um caso de uso;

• o fluxo principal, que representa a execução mais normal da função;

• os subfluxos e fluxos alternativos, que representam variantes que são executadas sob certas condições.

141

Os fluxos dos casos de uso são detalhados por meio de descrições textuais. A UML não impõe formatos obrigatórios para as descrições dos fluxos. A forma de descrição textual aqui apresentada é semelhante às formas usadas pela maioria dos autores que utilizam os casos de uso.

O detalhamento dos fluxos dos casos inclui no mínimo:

Pré-condições, ou seja, as condições que devem ser satisfeitas, ao iniciar a execução de um caso de uso;

Fluxo principal, que representa a execução mais normal da função;

Fluxos alternativos e subfluxos, que representam variantes que são executadas sob certas condições.

A UML permite que diversas notações sejam utilizadas para descrever os detalhes dos casos de uso. Uma rápida busca pela Internet revela inúmeros templates de documentação para casos de uso.


..: c ~ o .« o« tJ ::l C w .... w Z u, ~ a: o Q.

rn o c « >a: w rn w a: O· .« rn rn o 1:: w a: E rn o rn o c o ....

UML-1550

Desenho do Diagrama

• 2° Descrever os Casos deUso - Os fluxos são comumente descritos em

linguagem natural, na forma de uma seqüência de passos.

- Os atores devem aparecer explicitamente como sujeitos de cada passo.

142

Os fluxos são comumente descritos em linguagem natural, na forma de uma seqüência de passos. Cada passo corresponde a uma ação de um ator ou do sistema; estes devem aparecer explicitamente como sujeitos da frase. Outros atores podem aparecer como objetos verbais de uma ação.

Condições e iterações podem aparecer, mas os detalhes destas devem ser descritos em subfluxos, de preferência. Isso ajuda a manter a legibilidade do fluxo; que é essencial para garantir o bom entendimento de todas as partes.

---="----

E-E-~-


-,--i

oi C l ...J~ o-o: oet (J ::::l---q C

liiiiiiiiiiÕÕ l-w W Z lL ~

! a:o e,

=o

>

'" et c

a: W

w '" a: o-o:

o:i '"'" t::: UJ a: Õ

In o::I o In

C o l

::I

~

:t

=t

:I

:I

: :I

::

-11 11

UML-1550

Exemplo: Efetuar Venda 1. o Caixa faz a abertura da venda. 2. O Sistema gera o código da operação de venda. 3. Para cada item de venda, o Sistema aciona o subfluxo

Registro. 4. O Caixa registra a forma de pagamento. S. O Caixa encerra a venda. 6. Para cada item de venda, o Sistema aciona o subfluxo

Impressão de Linha do Ticket. 7. O Sistema notifica o Sistema Financeiro informando:

Data, Número da Operação de Venda, "Receita", Valor Total", Nome do Cliente (caso tenha sido emitida a nota fiscal).

143

Lembre-se que na UML não existe padrão para a descrição do caso de uso, temos sempre que saber qual o objetivo da utilização do produto que vamos fazer, para que se quer a descrição dos casos de uso? Se for para servir de base para o programador efetuar seu trabalho poderemos colocar informações mais técnicas, se servir para validar o escopo do projeto com o usuário, deveremos capturar todas as regras do negócio em uma linguagem mais natural, a ser entendida por pessoas não técnicas.

A descrição acima representa o fluxo típico do caso de uso "Efetuar Venda" de um supermercado. Ela é feita como uma lista numerada para facilitar futuras referências e alterações. Repare que os detalhes não são omitidos: no passo 7 são informados todos os dados necessários para o sistema financeiro.


..

oi c ~ o'..: ~ (.J ::l C w tu z u, a: cc o n. CIl o c..: >cc w CIl W cc '0...: CIl CIl o t: w cc Õ CIl o CIl o c o I

UML-1550

Exemplo: Excluir Mercadoria 1. o Gestor de Compras seleciona a mercadoria.

2. O Sistema verifica se existe algum pedido pendente que contenha esta mercadoria.

3. Se não houver pedido pendente contendo a mercadoria a ser excluída:

1. O Sistema desvincula a mercadoria dos fornecedores (os fornecedores não mais fornecerão a mercadoria que esta sendo excluída).

2. O Sistema faz a remoção da mercadoria.

4. Se houver pedido pendente contendo a mercadoria a ser excluída

1. O Sistema emite uma mensagem de erro.

144

o exemplo acima trata a ocorrência de uma exceção, que deverá ser a reação do sistema se houver pedido pendente. O tratamento das exceções deverá constar na descrição do caso de uso.

Em casos simples as exceções podem ser colocadas dentro do fluxo típico. Em situações maiores e mais complexas é mais legível descrevê-las em uma seção separada do documento.

--~~-E-

-~-~-


Ii

.ú

UML -1550

Elementos da Descrição • Sugestão para a descrição de caso de uso:

- Nome do Caso de Uso; - Identificador (opcional) ;

Descrição; - Atores (opcional); - Pré-condições (opcional);

Pós-condições (opcional); - Caso de Uso que foi estendido (opcional); - Casos de Uso incluídos (opcional);

Fluxos principal e alternativos. - Histórico de Alterações (opcional); - Estado Atual (opcional) - "em desenvolvimento", "em revisão",

"revisto e aprovado", "revisto e rejeitado". - Freqüência de Uso (opcional); - Questões a respeito do Desenvolvimento (opcional);

145

Os itens acima podem ser colocados em um documento de descrição de casos de uso. Algumas ferramentas case permitem que o documento de descrição seja associado ao caso de uso. Existem muitos templates disponíveis para uso em livros e na internet. Na parte de referências da apostila existem links para os templates.

== ::I

::J

::I

~

:I

:I

::I

~

::I

::I

::I

:I

;j

=~

=:11

:iI

:11

:!li

::: 1.: :: :.;;. ::: :I... '":: :I

LI % 3 ,=..'O

o c o,...


tiL 2%.

 « o => a w >w z u,

~ o:: o o. rn o a « >o:: w rn w o:: o.« rn rn o >m o:: C rn o rn o a o >

UML-1550 ~-~-

146

Exemplo de Descrição

• Nome: Matricular em Seminário

• Descrição: Matricula um aluno existente em um curso.

• Pré-condições: O aluno está registrado na universidade.

• Pós-condições: O aluno será matriculado em um curso se ele atender aos prérequisitos e se existir sala disponível.

~-=: e

c ~

c C

t::

e '&:

e !:

t:

~

=


I:

~

j .

----

=:w

=:s :I

:I

==~

~

==:li

:11

=~

:11

:li

iI

~ -~ '" ~ ::; '" :: ~

~

3 ::.

~ <> li: "... "li:

<'.. 2 ir

~ !

~

UML-1550

Exemplo de Descrição • Fluxo:

1. o aluno entra com o seu nome e número de inscrição, na tela "UI23 Tela de Login".

2. O sistema verifica se o aluno pode se matricular em seminários, de acordo com a regra de negócio "BR129 Verificar a Possibilidade para Matrícula em Seminários".

3.0 sistema exibe a tela "UI32 Seleção de Seminário", indicando os seminários disponíveis.

4.0 aluno seleciona o seminário em que deseja se matricular. 5.0 sistema valida o aluno de acordo com a regra de negócio "BR13ü

Verificar Pré-requisitos do Seminário". 6.0 sistema valida o seminário em relação ao horário do aluno, de

acordo com a regra de negócio "BR143 Validar Disponibilidade para Agendamento".

147


_MA0M4 _ .f!!frio,_

<i. o !:i o '<1; o<I; o :::> o w ti; Z LL

~ a: o n. tn o o ~ a: w fil a:

'0 '<1; tn tn O !:: w a: Õ

s (Jl O O O l

UML-I550 -E

_~e~i~~~T; ~;~~i:Ii~:da6 ~_~~~O_~_;t~~c~;_;~t~~~~1~~r;s~minários, de acordo com aregra de n_~~~~~~~__~9 I O sistema exibe a tela "U132 Seleção de Semlnárlo", indicando os seminários disponíveis. -~l

O aluno seleciona o seminário em que deseja se matricular.

Exemplo Formatado

E-E-

o sistema valida a aluna de acordo com a regra de negócio "BR130 Verificar Pré-requisitos do Seminário",

________ ~!i ; O sistema valida o seminário em relação ao horária da aluno, de acordo com a regra de negócio "BR143 I Validar Di~??"~i.~i1idade para !:,~:_~~~.~ento". . ..,. .-1"---------'" .

(Continua)

148

Fluxo (OU curso) típico, normal, ou principal é o que acontece se tudo der certo, nada falhar e nenhuma condição de erro for executada.

~-


UML-1550

Exemplo Formatado (continuação)

-

Fluxos Alternativos

(Passo 2) Caso matrícula não permitida

o sistema exibemensagem ~Você nãopodese matricular em seminários. Procure a secretaria docurso"

Retornar ao passo 1 da Curso Normal

Retornar ao passo 4 do Curso Normal

149

Fluxo (OU curso) alternativo ou secundário é o espaço para prever todos os possíveis erros. A descrição mostra como o sistema deverá reagir se determinada condição for falsa, pois este é o tipo de informação que deverá constar e estar mapeada nos fluxos alternativos.

:S

::J

::J

::I

~

~

:=iI

~

:li

=:iI

:iI

:31

=:11

=:s :iI

~

:I S

 lI: l!J ..,'"lI: O >« '" '"O ! !2:i lI: Õ

'" O

'"O c O !


I: 4.4

oi. o !:i o .« ~ o ::::l o UJ f UJ Z u,

i: EC O e,

O '" O « > EC UJ

UJ '" EC O.« '" O '" f m EC Õ

O '" O '" O O f

UML-1550

Desenho do Diagrama SystE"m

Efet-.ar Venda ~ ~

Cai~iro Sistema. l'inancei.r1[J

~ Estoquista

Bmi.tir PedidoC:<1rc~~ d.e.~ra.

~ ~harC~~ Gestor de C~ras

Vsuoirios~

150

o diagrama de contexto da figura mostra as fronteiras do sistema de supermercado. Do lado de fora estão os atores que interagem com o sistema. Do lado de dentro estão os casos de uso que fazem parte do escopo definido para o sistema.


~--~

2-~

~-

~-

E-

::I

::s :s -

,~

.;;: J

ii:2 ~

Ü

=-z ~ ....

:!õ i: ~

:2 <: :> li: .Il .Ir .Il :l:

:=I .;;:.. :!!

:ii: ~

~ :!!

:!!

~

=::JI

:2

:3

:2

:3

:11I

:11I

:ti

UML-1550

Exemplo: Banco Money

• Identificação de Atores e Casos de Uso: - Atores:

• Pessoa

• Cliente

- Casos de Uso: • Consultar Saldo

• Efetuar Depósito

• Efetuar Saque

• Acessar Conta (Secundário)

151

Descrição do Banco Money:

O Banco Money deseja que seus correntistas possam operar as suas contas com caixas eletrônicos.

Os caixas eletrônicos permitem que o cliente acesse a sua conta-corrente, conta-poupança ou conta especial e execute consulta de saldos, depósitos e saques.

Para que o cliente possa fazer as transações de consultar saldo e sacar é necessário que já esteja cadastrado e seja portador de uma senha de acesso.

Qualquer pessoa pode fazer depósitos em cheque ou em dinheiro, basta informar o número da conta.

A partir desta descrição é possível identificar dois atores: Cliente e Pessoa. Não são o mesmo ator pois executam tarefas de maneira diferente.

Também é possível identificar quais são as atividades que os atores irão executar no sistema: consultar saldo, saque, depósito e acesso a conta (senha de acesso).

::11I

:11 INSTITUTO INFNET -151

=ti

<i. <:> ~

~ 0co: U :::l <:> w ... w Z u,

~ a: o c.. CIJ o <:> co: >a: w CIJ w a: o.co: CIJ CIJ

~ W a: Õ CIJ o CIJ o <:> o...

UML-1550


o NOME: Acessar Conta o ATOR: Cliente o DESCRIÇÃO: Validação do acesso da pessoa às informações e ações da

conta. o Fluxo Normal

1. Cliente ~assa cartão do banco na leitora. ) 2. Sistema identifica número da conta. /' 3. Cliente informa senha. /. 4. Sistema valida senha. _/ 5. Sistema lista operações (consulta saldo e efetuar saque) ../

o Fluxos Alternativos - Passo 1: Caso cartão inválido ou bloqueado

1. Sistema exibe mensagem, 2. Retomar ao passo 1 /

- Passo 4: Caso senha inválida 1. Sistema exibe mensagem ~2. Retomar ao passo 3 -

152

Descrição completa do caso de uso:

NOME: Acessar Conta ATOR: Cliente DESCRIÇÃO: Validação do acesso da pessoa às informações e ações da conta. Fluxo Normal

Cliente passa cartão do banco na leitora. Sistema identifica número da conta. Cliente informa senha. Sistema valida senha. Sistema lista operações (consulta saldo e efetuar saque)

Fluxos Alternativos Passo 1: Caso cartão inválido ou bloqueado

Sistema exibe mensagem Retornar ao passo 1

Passo 4: Caso senha inválida Se a senha for inválida pela terceira vez Sistema bloqueia conta Senão Sistema exibe mensagem Retornar ao passo 3 f;


$ a#!idJt!!2L

I

~ ~

::; « Q. « :::> o w:=:i o

I-w Z LI..

~ a: o ao:>

~ o o

>w o:>:i «a:

w a: O,

o:> o:> o::J >«

t:: wa: Õ

:=I o:>o o:> o o o I

:=I

~

:I

~

:I

:iI

=:I"

=-:I

:f

:I SI


• NOME: Efetuar Depósito • ATOR: Pessoa • DESCRIÇÃO: Depósito de cheque ou dinheiro em contas do banco. • Fluxo Normal

1. Pessoa solicita depósito. 2. Pessoa informa agência e conta. 3. Sistema verifica conta. 4. Pessoa informa total e tipo (cheque/dinheiro) 5. Sistema exibe nome do favorecido e valor de depósito. 6. Pessoa confirma depósito. 7. Sistema abre gaveta. 8. Pessoa insere envelope com depósito. 9. Sistema emite comprovante

Fluxos Alternativos - Passo 3: Caso agência ou conta inválidos

• Sistema exibe mensagem • Retomar ao passo 2

153

Descrição completa do caso de uso:

NOME: Efetuar Depósito ATOR: Pessoa DESCRIÇÃO: Depósito de cheque ou dinheiro em contas do banco. Fluxo Normal

Pessoa solicita depósito. Pessoa informa agência e conta. Sistema verifica conta. Pessoa informa total e tipo (cheque/dinheiro) Sistema exibe nome do favorecido e valor de depósito. Pessoa confirma depósito. Sistema abre gaveta. Pessoa insere envelope com depósito. Sistema emite comprovante

Fluxos Alternativos Passo 3: Caso agência ou conta inválidos

Sistema exibe mensagem Retomar ao passo 2

UML-1550

INSTITUTO INFNET· 153

~ ~ o..,( o..: (J ::l C w

tu z LL

~ a: o Q.

cn o c..: >a: W cn w a: o...: cn CfJ o C w a: Õ cn o cn o c o ....

UML-1550


----I~arDep~ Pessoa

Cliente

154

No diagrama acima o cliente é uma especialização de pessoa pois além de efetuar depósito ele também pode efetuar saque e consultar saldo.

O caso de uso "Acessar Conta" é incluído pelos casos de uso "Efetuar Saque" e "Consultar Saldo" pois é necessário que o cliente tenha um cartão e senha para poder executar estas operações.


$!2 a x

 o w li; Z u,

~ Ir o n. til o o <t >Ir w tilW· Ir o '<ttil til o !::: w Ir Õ til o til o o ~

I

Conclusão da UA -3 • Casos de Uso servem para capturar os requisitos

do sistema e para validar com o cliente o escopo do projeto.

• Não desenhe associação entre atores.

• Caso de uso não é uma atividade simples, é um conjunto de passos.

• Evite falsos requisitos: - Requisito falso tecnológico: deve-se abstrair todos os

problemas de tecnologia. - Requisito falso arbitrário: função que o sistema não

precisa ter para atender ao seu propósito.

156

• li

Documents

Diagrama de Casos de Uso