Diagrama De Casos De Uso 2b4qn

<= Usuário

-

I~

Usuário

• Anotação:

o

usuário deve~

estar logado para usar esta

opção.

116

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 sas (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 J acobson 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

::J

UML-155D

=z

:i

:3

~ -

Casos de USO: Conceitos

o

< o

«

~j1

• 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:

.tl.

Z

.L.

~

:t .2 :3 ........"" <:"" ..'" :3

:I

9

:< >

o

'ii

~

:t

c

- Descrever os requisitos funcionais do sistema - O que o sistema deve fazer; - Descrever claramente as responsabilidades que devem ser cumpridas pelo sistema.

lO:

.:;; '5

~ 117

:3 ~

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.

:3

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.

:I ~

=a

:I

:

:I

:11

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.

;ti INSTITUTO INFNET - 117

d eb

:

UML-1550

'" :;

Componentes.

o .«

~

U

=>

'"ti;w

L

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

z

u,

~

a: o Q.

s '">a:« w

'"w

l

ÇI:

F

-

~

t}""

",Y-t'....((~· 10' " '-'.. t-,"

"ri/ ~~~Y i t: ;',~~' C=~ (j 9 . '1_-------.; de

o

.«

~ri~ ~ lf

'"'"o l:: w

a:

\idJ

Õ

l~') Ator

'"o '"o '"o

e ~

cas:_ :80 _

, 't:

I-

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

UML-1550

< :: ...

Conceito de Ator

~

'-"

~

~

• Ator é um agente que interage com o sistema;

Li:

"" Z

.L

• Um ator é uma classe, não uma instância. • Representa uma regra, um papel e não um usuário individual do sistema.

~

==-

~

-6

L

lO

>2 ;q

.. < .. :I >

:I:

.u. .u

• 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:

::>

:;;

~

~

s

§;::

:I

:I

:I

:I

:I

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.

:t :t :J

,, :3

,

-

!i

INSTITUTO INFNET -119

UML-1550 iiii iiii
..

.

Atores

~

o

'<1;

~

o

::>

c

• Um Ator é uma classe com um ícone

padrão.

• Exemplos de atores:

UI

Iii z u,

~

o: O

O

C

6:UI CIJ UI

o: O

'<1; CIJ CIJ

O

m

cliente

~

gerente

~

usuário

~

vendedor

~

correntista

~

ba1ança

~

sensor

~

robô

~

'WIE!b service

~

o:

C

CIJ

O

CIJ

O C

O t

sistema contábil

~

-

;:

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;

E

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

-

~

-

jiiiii

INSTITUTO INFNET· 120

E

:51

=

:51

o< .....

..J

o

o« c..>

Como Identificar os Atores

-c

~

o

:::l C U

lU

Z

L

ó?i

:iI

:: D

e,

~

C

~

CC :>

.. ..""..

:m: ~ ~

O

= =

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

o« O

:ui

.... :t:

3: O O

O

~

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

- Quem irá istrar e manter o sistema?

- Quais os dispositivos de hardware necessários para o sistema? - O sistema irá interagir com outros sistemas?

~

31

-

-

~

ia

= :11

-

: =

11

li


,

\ I

\ I

:

r I

lIML-I550

Caso de Uso

~

o .«

C>

« U

::>

/

o

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

W

f

W

Z

u,

:!E

a:

oa.

UJ

o c

-

«

> a:

~

• O nome do Caso de Uso deve ser uma frase indicando a ação que realiza.

W

UJ

W'

a:

o

.« UJ

'.t:

(f)

o

• Um caso de uso é um conjunto de os e o tratamento das suas exceções.

!:: W c:: Õ (f)

o

UJ

o Cl o f

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 o! Um caso de uso tem um conjunto de os e trata as exceções desses os. 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

UML -1550

::!

:=i

::i

::I ~

::I

::s

Cl I

Exemplos de Casos de USO

..J

o o« o « o

::J Cl W

I

W

Z

u,

as tI:

oo.. rn

o Cl «

> tI: W

rn w

tI:

o o« rn rn

oI

Ui tI:

Õ

rn rn

O O

Cl

O I

::t 125

::I

::I

::I

::I

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.

:3

=t

=t

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.

:=I

:=:t

:I

:t

~


UML-1550

Características e Regras

o .« o « o :o o

• É sempre inicializado por um ator e devolve uma resposta. • São conectados aos atores com associações de

comunicação. A associação é bidirecional.

w

li; Z

u,

~

a:

oO-

CIl

o

• Um caso de uso tem início, meio e fim.

o > a:

«

-

~

-

~

w

ffl

a:

o .«

CIl

CIl

o l m a: E

Consultar C1ientes

-

CIl

o

E

gerente

CIl

o

o

oI

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.


E

:11

UML-1550

::11I

:11I

~

-

Estímulos

c.:> c

:11I

• Um ator se comunica com o sistema enviando e recebendo mensagens para um Caso de Uso.

Oi:

;;:

... z

~

:11

• Mensagens = Estímulos. • Existem dois tipos de atores: - Ativos, iniciam algum Caso de Uso. - ivos, recebem mensagens de um Caso de Uso.

'.: i: ,!

< >

:11I :11.

== = = = =:li =:11

... li:

'" .li.

li:

<:

'" ! :ir

Ator ivo

l§

~

~ caixa

------<~uar

vV·_-+

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 ivos quando somente participam dele, sem iniciá-lo. Atores ivos recebem mensagens, portanto em um diagrama são identificados por setas que chegam até eles. Atores ivos 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:

,. 3

:11

:11

:!I


UML

-155{;1

ci

"~

Relacionamentos

o o

'<1:
::>

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

• A comunicação será representada como ligação sem direção,(êíilgeral. • Quando a iniciativa parte o caso de uso a

comunicação deve ser direcionada por uma

seta.

"w f

w

Z

U-

i!: te

o

"

'" o

"
w '" te

'o

'<1:

'" '" o !:::

-,

w te

iS

o'"

'" o

"o f-

128

-iiii

E

-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


::!

UML-1550

::i

:=i

::I

::I

:::I

:!i

::I

oi. ..... o -:( Q

Generalização

~

'O

U

:::>

Q

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

!.U

..... W Z

u,

z

o:

oe,

o '" Q

o: w

'" o: I;!J

o <

gerente

'" '" e

ii o:

E

o '"

'" o Q

o

l

gerente financeiro

:::I ~ ~

~

=

=ti

129

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:

~

::li

Secretária

::11

=

:;li

:11

~

fJ

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 ~


L1ML -155:D

I I

I

Generalização

~

o

'00:

o 00: o :::> c

;1

w

lü z lL

~

a::

oc.. CIl

oc

00:

> a:: w

I

CIl

.l:! o

'00:

gerent.e

!J"!rente de cOJlI:Iras

CIl

gerent.e

~inanceiro

s ~

Ui

a::

15 CIl

o CIl oc

i

Sí.JTwlar lil. uxo de Caixa

~

130

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.

I

I

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.

I•

<J-- Secret.ária

<Jr--- Supervisor

Cont.ratar

i

li!

Diretor

Pro~essor

I

·

Matricular JIl. uno


• 4

:=li

UML-1550

::11

:3

~

Casos de USO Secundários

~ ::I

-e o <

:::

::li ..

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

ir .ll

Z

=:ti

.;
~

:t

::I

:::l

< >

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

fi

'" ~

::I

o< :t

~ ~

ã ~

:;

'o" 'o"

:::l

o ....

~ 131

~

= :3 ~

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

:=11

:li

:iI :iI ~

::11

:11

=


UML-I550

I:

C

c

C

Extensão

!:i o

'

o ...: o

:J C

c:

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

W

~

W

Z

LI.

~

a:

oc,

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

Ul

oc

a: w

'ffia:

f

C

o

'
t

Ul

o

!::: w a: Õ Ul

o Ul o

~~---------Gir

c

o~ Caixa

~<extend»

Nota

~

t:

C 132

r:

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 nota fiscal 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 a determinado blog e pode ou não escrever comentários.

C::=.c_n~ ,,

>

Visitante


:2

UML-1550

:li

:11 ::11I

:2

~

Inclusão

.:
• Essa notação pode ser usada para representar subfluxos complexos e comuns a vários casos de uso.

iL

i z

...:i!: ~

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

i:

i

<:

:ti ..

> E .u. .u.

~ ~"'~""V.

E

..!

.:<

=ti

:a

. Super~sor

«Include» • - ~-_

• - - --.Jo.

:ir

GxarEsto~

3

«include» _,S?'

5 ""o 5

---Guarv~'

::11

caixa

133

::11

:2

=

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

:li

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

:ti

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.

::li

::11

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

::11I

::11

::11 :11 ~


UML-1550

-

~

Desenho do Diagrama

!:i

o .« ~

g c

• 10 Identificar os Casos de Uso

W

I

W

Z

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

u,

~

o:

ol1. (J)

oc «

6:w (J)

• 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?

W 0:'

o .« (J) (J)

olm o:

Õ (J)

o (J) oc o I

-

r -=

~

-

138

o primeiro o 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

::J

UML-1550

::I

:I

::I

::I

::::

c

~

::; oU

:uz

~ o '" ::::

..

:11

>

At~C' ~ ""'

Eventos

Casos de Uso

Vendedor fecha contrato

Fechar Contrato

IVendedor \ "I

Vendedor cadastra cliente

Cadastrar Cliente

\

Cliente solicita serviço

Solicitar Serviço

(élie~

Supervisor aloca técnico

Alocar Técnico

~/

Técnico finaliza serviço

Finalizar Serviço

Supervisor consulta pendências

Consultar Pendências

Supervisor

Cliente paga conta

Pagar Conta

Cliente

~

~

:2 .'"""

::I

Exemplo: Sistema de Help Desk

o

<:

E

o o« :c

o '" .... i:i

'" '" o '" o ::::

Q

o ....

:11

Vendedo~,/

-

(f'ecn~Q .

<,

139

:11

::I

2

:11I

:11I

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 F (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

:I

~


PWI.A

.4"

4J $--44=

;

UML-1550

= ==

itilli

Desenho do Diagrama

O

-o:

o

O :::>

a

• 2° Descrever os Casos de USO

w

];j zu,

- Consiste em descrever a interação entre o caso de uso e o ator, o o a o 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.

~

c: O

""cn O

a

> c:

w cn w

c:

O

~

cn O

l:: w

c: C

cn O cn O

a

~

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

-

~ -

INSTITUTO INFNET • 140

=

:I

::i

=

:::I

::I

UML-1550

<é

Cl I

Desenho do Diagrama

-'

o <

c>

«

o

::>

Cl W I W

• 2° Descrever os Casos de

USO

Z

u.. ~

- A descrição dos casos de uso pode incluir:

o::

o O

• 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 Cl

«

> o:: w

w '" o::

o <

:i

iii

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

::I

'"o o '"

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

'"

'" o I

o:: 2i

Cl

o I

~ 141

:I

::J

::I

:I

=t

::i

:r

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.

::I

='

::i

::i

::i


UML-1550

..:

c

Desenho do Diagrama

~

o .« o «

tJ

::l C

"---

Z

u,

- Os fluxos são comumente descritos em linguagem natural, na forma de uma seqüência de os.

~

a:

oQ.

rn

o c «

> a: w rn w a:

--

--=

• 2° Descrever os Casos deUso

w

.... w

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

O·

.«

rn rn

o

1:: w

a: E rn o rn o c

o ....

-

142

E Os fluxos são comumente descritos em linguagem natural, na forma de uma seqüência de os. Cada o 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

-

~


-

-,

-

UML-1550

i

~

oi

C l

Exemplo: Efetuar Venda

...J

o

-o: o

et

---q

(J

::::l C

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

w

liiiiiiiiiiÕÕ

l-

W

Z

lL

~

!

a:

oe,

o'" c

=

et

> a: W

'"a:w

o

-o:

:i

'"'"o t:::

UJ

a: Õ

::I

In

o In oC o l

::I ~

:t

=t

:I

:I

:

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 o 7 são informados todos os dados necessários para o sistema financeiro.

:I

:

:

11

11


..

-

~

UML-1550

~

oi

c ~

E

Exemplo: Excluir Mercadoria

o

'..: ~ (.J ::l C

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.

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

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.


i

.ú

I

--

~

~

==

UML -1550

::I

::J

Elementos da Descrição

...J

~ o «

;,:

::I

i'i

~

..s

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

JJ

- 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);

~

JJ Z

...;!!; e,

E

< >

:I

:I

::: 1.: :: :.;;. :::

... :I

'" ::

:I

LI %

3

,= . ::I

'O

o

c

o ,...

~ 145

::I

::I

::I

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

= =

~

:11

:iI :11 INSTITUTO INFNET -145

:!li tiL 2%.

UML-1550

-

~

-

~

Exemplo de Descrição

~

o .« C> « o => a

• Nome: Matricular em Seminário • Descrição: Matricula um aluno existente em um curso.

w

> w

z

u,

~

o::

o

o.

rn

o

a « > o::

-

~

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

w w o::

rn

o .«

rn rn

o

> m o::

C rn o rn o a o >

=:

e

= c

146

~

c C

t::

e

'&:

e

!:

t:

~

I: INSTITUTO INFNET -146

j .

~

=

UML-1550

:w

=

:s

:I

~

Exemplo de Descrição

-

~

'" ~ ::; '" ~

• Fluxo:

::

1. o aluno entra com o seu nome e número de inscrição, na tela "UI23 Tela de ". 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".

~

3

::.

~

< >

:I ... <' ..

li:

" "

li:

= =

2

ir

~

!

~

~

~

147

= =

:li

:11

=

~

:11

:li

---


iI _MA0M4

_

.f!!frio,_

E

UML-I550

o

!:i

Exemplo Formatado

o

'<1;

o

o o w

:::>

ti; Z

LL

~

o

-E

a: w

E

a:

on. tn

o

~

fila:

'0 '<1;

_~e~i~~~T; ~;~~i:Ii~:da6 ~_~~~O_~_;t~~c~;_;~t~~~~1~~r;s~minários, de acordo

tn tn O

com aregra de n_~~~~~~~_ ~9 I

!::

O sistema exibe a tela "U132 Seleção de Semlnárlo", indicando os seminários disponíveis.

Õ

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

w a:

s

o sistema valida

(Jl

O

; I

O

O

l

"---------'" .

-

-~l

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

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

~!i

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

-

~


:S ::J

::J

UML-1550

::i

Exemplo Formatado

o

...: o

..:

::I

u c

::l

(continuação)

ui

kiz

-

~

~

Fluxos Alternativos

lI:

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

oa,

'" oa

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

..: >

~

lI:

Retornar ao o 1 da Curso Normal

l!J

..,'" lI:

O

>«

:=iI

'" O '" ! !2:i lI:

Õ

~

O '" '" O c O

!

Retornar ao o 4 do Curso Normal

:li

=:iI

:iI

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.

:31

=:11

=:s

:iI

~

:I


S

I:

4.4

UML-1550

oi. o

Desenho do Diagrama

!:i

o .« ~

o

::::l

o

~

UJ

f

UJ

Z

u,

i:

SystE"m

Efet-.ar Venda

~

Sistema. l'inancei.r1[J

Cai~iro

EC

O

e,

'"O

~

O

« >

EC

UJ

-

~

Estoquista

'"

UJ EC

C:<1rc~~

O .«

'"O'" f

m EC

~harC~~

Õ O '"

Bmi.tir Pedido

-

d.e.~ra.

~

~

Gestor de C~ras

'"O O

~

O f

Vsuoirios

2

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.

-

~

~


-

E

::I

UML-1550

::s

:s

,~

Exemplo: Banco Money

-

.;;: J

~

:2

=:2

ii Ü

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

z.... ~

- Atores:

:!õ

i: ~

• Pessoa

<: :>

• Cliente

li: .Il

.Ir

.Il

:l:

- Casos de Uso:

..

.;;:

:=I ~

:!!

• Consultar Saldo

:ii: ~

• Efetuar Depósito

:!!

• Efetuar Saque

:!!

• ar Conta (Secundário)

~

=

::JI

:2

:3

:2

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 e 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 o. Qualquer pessoa pode fazer depósitos em cheque ou em dinheiro, basta informar o número da conta.

:3

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.

:11I

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

:11I

:ti

::11I

:11

=ti


UML-1550

<:>


~

~

0

co:

U :::l

<:>

...ww

o o

Z

u,

~

o

a: o

c.. CIJ

o

o

<:>

co:

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

conta.

Fluxo Normal 1. 2. 3. 4. 5.

> a: w w

CIJ

a:

o .co:

CIJ

CIJ

~

W

o

a: Õ

Fluxos Alternativos

-

CIJ

o CIJ o <:> o

Cliente ~assa 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) ../

o 1: Caso cartão inválido ou bloqueado

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

...

-

o 4: Caso senha inválida

-

~

1. Sistema exibe mensagem 2. Retomar ao o 3 152

Descrição completa do caso de uso: NOME: ar Conta ATOR: Cliente DESCRIÇÃO: Validação do o da pessoa às informações e ações da conta. Fluxo Normal Cliente a 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 o 1: Caso cartão inválido ou bloqueado

Sistema exibe mensagem

Retornar ao o 1

o 4: Caso senha inválida

Se a senha for inválida pela terceira vez Sistema bloqueia conta

Senão Sistema exibe mensagem

Retornar ao o 3


#!idJt!!2L

$

a

I

f;

~ ~

UML-1550

::;

::5


I

...J

o

>« Q.

« o

:=:i

:::>

o w Iw

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

Z

LI..

~

:i

~

a:

oa

o:>

oo «

1. 2. 3. 4. 5. 6. 7. 8. 9.

> a: w o:> w a: O,

>«

::J

o:> o:>

o t:: w a:

Õ o:>

:=I

o o:> oo o I

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

-

:=I

o 3: Caso agência ou conta inválidos

• Sistema exibe mensagem • Retomar ao o 2

153

~

:I ~

:I :iI

=:I" =-

:I :f :I

SI

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 o 3: Caso agência ou conta inválidos Sistema exibe mensagem Retomar ao o 2


UML-1550

~


~

.o,(

o

..: (J ::l C

w

tu

z

----I~arDep~

LL

~

a:

oQ.

cn

Pessoa

oc ..: > a: W cn w a:

..o.:

cn CfJ

o

C w a:

Õ

cn

o cn oc o ....

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 "ar 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

I

Conclusão da UA -3

'::i o

' o

• 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 os. • Evite falsos requisitos:

w

li; Z

u,

~ Ir

o

n.

til

o

o

> Ir w

til

W· Ir

o

'
til

o

!:::

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

w

Ir

Õ til

o

til

o o

~

156

• li


Diagrama De Casos De Uso 2b4qn

Overview 5o1f4z

More details 6z3438

Related Documents c2h70

Diagrama De Casos De Uso 2b4qn

Exposicion De Diagrama De Casos De Uso 3a4247

Ejercicio 1. Diagrama De Casos De Uso 3w4e61

Tarea Casos De Uso 3ju24

2 Casos De Uso 171731

Casos De Uso 2c6h6r