Você está na página 1de 13

Mostre somente as propriedades de cada objeto (como os valores dos

atributos, papeis e estados) que sejam ,importantes para a compreensao


da intera\;ao em seu contexto .
Mostre somente as propriedades de cada mensagem (como os seus para-
metros, semantica de concorrencia e valor retornado) que sejam impor-
tantes para a compreensao da intera\;ao em seu contexto.
226/
Capftulo 17
CASaS DE Usa
Nenhum sistema existe isoladamente. Todo sistema interessante interage
com atores humanos ou automatos que utilizam esse sistema para algum prop6-
sito e esses atores esperam que 0sistema se comporte de acordo com as manei-
ras previstas. Urn caso de uso especifica 0comportamento de urn sistema ou de
parte de urn sistema e e uma descri~ao de urn conjunto de seqiiencias de a~6es,
incluindo variantes realizadas pelo sistema para produzir urn resultado observa-
vel do valor de urn ator.
Os casos.de usos podem ser aplicados para captar 0comportamento pre-
tendido do sistema que esta sendo desenvolvido, sem ser necessario especificar
como esse comportamento e implementado. Os casos de uso fornecem uma ma-
neira para os desenvolvedores chegarem a uma compreensao comum com os
usuarios finais do sistema e com os especialistas do domfnio. Alem disso, os ca-
sos de uso servem para ajudar a validar a arquitetura e para verificar 0sistema a
medida que ele evolui durante seu desenvolvimento. A propor~ao que voce im-
plementa 0seu sistema, esses casos de uso sao realizados por colabora~6es cujos
elementos trabalham em conjunto para a execu~ao de cada caso de uso.
Casos de uso bem-estruturados denotam somente 0comportamento es-
sencial do sistema ou subsistema e nao sao amplamente gerais, nem muito es-
pecfficos.
Primeiros passos
Uma casa bem-projetada e muito mais dOique urn grupo de paredes reunidas
para sustentar urn teto como prote~ao ao tempo. Ao trabalhar com seu arquiteto
e projetar sua casa, voce dara muita importancia ao modo como essa casa sera
utilizada. Se voce gosta de dar festas, pensara no luxo de pessoas pelos como-
dos de maneira a facilitar a conversa~ao e evitar pontos sem saida que resultem
em congestionamentos. Caso pretenda preparar refei~6es para sua familia, dese-
jara ter certeza de que sua cozinha esta projetada para armazenar mantimentos e
utensilios de modo eficiente. Ate 0planejamento do caminho a ser percorrido
do carro a cozinha com a finalidade de descarregar mantimentos afetara 0modo
como eventual mente os comodos estarao conectados uns com os outros. Caso
sua familia seja grande, sera preciso pensar na utiliza~ao dos banheiros. Planejar
o numero adequado e a posi~ao correta dos banheiros logo no infcio do projeto
reduzira significativamente 0risco de confusoes pela manha, quando sua familia
precisar sair para 0trabalho e para a escola. Se voce tiver fithos adolescentes,
essa sera uma questao de alto risco, pois 0custo emocional de urn mau planeja-
mento sera muito grande.
Pensar a respeito da maneira como voce e sua familia utilizarao a casa e urn
exemplo de uma analise baseada em caso de uso. Voce considera os varios mo-
dos como a casa sera utilizada e esses casos de usa orientam a arquitetura. Mui-
tas familias teriio os mesmos tipos de casos de uso - usamos casas para comer,
dormir, criar os filhos e acumular mem6rias. Toda familia tambem tera seus
pr6prios casos de usa especiais ou varia~oes e alguns casos basicos. As necessida-
des de uma familia grande, por exemplo, sac diferentes das necessidades de urn
adulto solteiro que tenha acabado de conduir a faculdade. Sao essas varia~oes
que tem 0maior impacto na forma final da casa.
Urnfator importante para a cria~ao de casos de uso como esses esta relacio-
nado ao fato de voce cria-Ios sem especificar 0modo como os casos de uso sac
implementados. Por exemplo, voce pode especificar como urn sistema de caixa
eletronico deve funcionar, definindo, em casos de uso, como os usuarios deve-
riio interagir com 0sistema; voce nao precisa saber nada sobre 0que devera
acontecer dentro do caixa eletronico. as casos de uso especificam 0comporta-
mento desejado; eles nao determinam como esse comportamento sera executa-
do. A vantagem disso e permitir que voce (como usuario final e especialista do
dominio) se comunique com seus desenvolvedores (que constroem sistemas sa-
tisfazendo aos seus requisitos) sem se preocupar com detalhes. Esses detalhes
aparecerao, mas os casos de USopermitem que voce focalize os pontos que con-
sidera de maior risco.
. Na UML, todos esses comportamentos sac modelados como casos de uso
que poderiio see especificados independentemente de suas realiza~6es. Um caso
de uso e uma descri~ao de um conjunto de seqiiencias de a~6es, induindo vari-
antes que urn sistema realiza para produzir urn resultado observavel do valor de
urn ator. Existem varias partes importantes para essa defini~ao.
No nive! do sistema, urn caso de uso descreve urn conjunto de seqiiencias,
cada uma representando a intera~ao de itens externos ao sistema (seus atores)
com 0proprio sistema (e suas principais abstra~oes). Esses comportamentos, na
verdade, sac fun~oes em nivel de sistema, que voce utiliza para visualizar, espe-
2281 cificar, construir e documentar 0comportamento pretendido do sistema duran-
te a capta~ao e analise de requisitos. Urn caso de uso representa urn requisito
funcional do sistema como urn todo. Por exemplo, urn caso de uso central em
urn banco e 0processamento de emprestimos.
Urn caso de uso envolve a intera~ao dos atores com 0sistema. Urn ator re-
presenta urn conjunto coerente de papeis que os usuarios dos casos de uso de-
sempenham quando interagem com esses casos. as atores podem ser humanos
ou sistemas automatizados. Por exemplo, na modelagem de urn banco, 0proces-
samento de urn emprestimo envolve, entre outras coisas, a intera~ao entre 0diente
e quem concede 0emprestimo.
Urn caso de uso podera ter variantes. Qualquer sistema interessante tera
casos de uso que sac versoes especializadas de outros casos de uso, que sac in-
cluidos como parte de outro caso de uso e que estendem 0comportamento de
outro caso de uso basico. Voce pode fatorar 0comportamento reutilizavel e co-
mum de urn conjunto de casos de uso, organizando-os de acordo com esses tres
tipos de relacionamentos. Por exemplo, na modelagem de urn banco, voce en-
contrara muitas varia~oes do caso de uso basico de processamento de empresti-
mos, como a diferen~a entre 0processamento do financiamento de urn aviao e 0
emprestimo para uma pequena empresa. Em cada situa~ao, entretanto, esses ca-
sos de uso compartilham algum grau de comportamento comum, como 0caso
de uso de qualifica~ao do diente para 0emprestimo, urn comportamento que
faz parte do processamento de qualquer tipo de emprestimo.
Urn caso de uso executa alguma quantidade tangivel de trabalho. Sob a
perspectiva de urn determinado ator, urn caso de uso realiza algo que e d~ valor
para urn ator, como 0calculo de urn resultado, a gera~ao de urn novo obJeto ou
a modifica~o do estado de outro objeto. Por exemplo, na modelagem de um
banco, 0processamento de urn emprestimo resulta na entrega de um empresti-
mo aprovado, manifestada como uma pilha de dinheiro entregue nas maos do
cliente.
Voce podera aplicar os casos de uso a todo 0seu sistema. Tambem pode
aplica-Ios a uma parte do sistema, incluindo subsistemas e ate interfaces e classes
individuais. Em cada situa~ao, os casos de uso nao apenas representam 0com-
portamento desejado desses elementos, mas tambem podem ser utiIizados como
a base de casos de teste para eSseselementos, a medida que evoluem durante 0
desenvolvimento. Casos de uso aplicados aos subsistemas sac excelentes fontes
de testes de regressao; casos de uso aplicados a todo 0sistema sac excelentes
fontes de testes de sistema e de integra~ao. A UML fornece a representa~ao gra-
fica de urn caso de uso e de urn ator, conforme mostra a Figura 17.1. Essa nota-
~ao permite visualizar urn caso de uso em separado de sua realiza~ao e no con-
texto com outros casos de uso.
- u s s + | s s . s s s s . s s s s ! s s s + ' 3 2; s s . ' s s s . s s s s . s . s s ! s s s s s + ' s 4 e 9 ;s s s
. / s . . s s s . s ' . s ! s s s s + ' 1 1 . . 1229
aler
~(
ca se de use
~
Loa nOfficer ~
nome
Urn . s s d. + s e uma descri<;ao de urn conjunto de seqiiencias de a<;6es, inclusive
variantes, que urn sistema executa para produzir urn resultado de valor observavel
por urn ator. Graficamente, 0caso de uso e representado como uma elipse.
o s s s + s euma classe descrita por urn conjunto de casos de uso. Normalmente
a classe e urn sistema ou subsistema. Os casos de uso representam aspectos d~
~omportamento da dasse. Os atores representam aspectos de outras classes que
mteragem com 0assunto. Juntos, os casos de uso descrevem 0comportamento
completo do assunto.
Todo caso de uso deve ter urn nome que 0diferencie dos demais casos de uso. Urn
nome e uma sequencia de caracteres textual. Esse nome sozinho e conhecido
c.omo urn s . s ' . s , urn s . d. . s s h e 0nome do caso de uso, cujo pre-
flXOe 0s . do pacote em que 0caso de uso se encontra. Tipicamente, urn caso
de uso e definido exibindo somente seu nome, conforme mostra a Figura 17.2.
2 3 1 .
- s . d. . s d. + s d. . . s . + s . d. s d s . . + . 0 . s . . s / . . s . s . s s d s
s + ' | i
Nota: Um nome de coso de uso poder6 ser um texto contendo . qua lquer qua ntida de
de letra s, numeros e a ma ioria dos sinois de pontua <;;oo (exceto sinois como os dois-
pontos, utiliza do pa ra sepa ra r um nome de cia sseeo nome do pa cote que a contem) e
poder6 continua r por v6ria s linha s. No pra tica , os nomes de ca sos de uso soo breves ex-
press6es verba is a tiva s, nomea ndo a lgum comporta mento encontra do no voca bul6rio
do sistema cuja modela gem voce est6 fa zendo.
Urn ator representa urn conjunto coerente de papeis que os usuarios de casos de
uso desempenham quando interagem com esses casos de uso. Tipicamente, urn
ator representa urn papel que urn ser humano, urn dispositivo de hardware ou
ate outro sistema desempenha com 0sistema. Por exemplo, se voce trabalha em
urn banco, podera ser urn LoanOffi cer. Se utiliza 0servi<;o de banco pessoaI, tam-
bem desempenhara 0 papel de Customer. Uma instancia de urn ator, portanto, re-
presenta uma intera<;ao individual com 0sistema de uma maneira especffica.
Embora voce utilize atores em sua modelagem, os atores nao sao, de fato, parte
do sistema. Eles residem fora do sistema.
Em urn sistema em execu<;ao, os atores nao precisam existir como entida-
des separadas. Urn objeto pode representar 0papel de varios atores. Por exem-
pIo, uma Pessoa pode ser LoanOfficer e Customer. Urn ator representa urn aspecto
de urn objeto.
Conforme mostra a Figura 17.3 , os atores SaDrepresentados como figuras
esquematizadas. Voce podera definir grupos gerais de atores (como em Customer)
e especializa-Ios (como em Commercial Customer), utilizando a generaliza<;ao de re-
lacionamentos.
-~
Q Customer
A <""mum'"
Commercia l
Customer
a tor
Nota: Os meca nismos de extensibilida de do UML podem ser utilizodos pa ra cria r 0
estereotipo de um a tor, com a fina lida de de proporciona r um icone diferente, ca pa z de
oferecer uma melhor indica <;eo visua l pa ra seus propositos.
Nota: Voce pode especifica r 0f1 uxode eventos de um coso de uso de diversa s ma nei-
ra s, incluindo texto estrutura do informa l (como no exemplo a nterior), texto estrutura do
forma l (com pre e pos-condi<;ees), m6quina s de esta do (pa rticula rmente pa ra sistema s
rea tivos), dia gra ma s de a tivida des (pa rticula rmente pa ra f1 uxosde troba lho) e pseudo-
codigo.
_ Os ato~es_poderaoestar conectados aos casos de uso somente pela associa-
<;ao.AaSSOCla<;ao entre 0ator e urn caso de uso indica que 0ator e 0caso de uso se
comunicam entre si, cada urn com a possibilidade de enviar e receber mensagens.
- u s . ' . s . s s s s . u / s . s . s d s s s + ' s 5e | , s . s s . s s s .
s . s d s s + ' |
Tipicamente, primeiro voce descrevera 0fluxo de eventos para urn caso de uso
no texto. Alem de aperfei<;oarsua compreensao dos requisitos do sistema, entre-
tanto, voce desejara utilizar os diagramas de intera<;aopara especificar esses flu-
xos graficamente. Alem disso, voce tambem utilizara urn diagrama de sequencia
para especificar 0fluxo principal de urn caso de uso e varia<;6esdeste diagrama
para especificar os fluxos excepcionais.
- u s d s d. s . / s . ' + s . . s s d s d. s . + . s . e s d s d. . ' h / s
. s . s d s s + ' |
Urncaso de uso descreve 0 + . urn sistema (ou urn subsistema, classe ou interfa-'
ce) faz, mas ele nao especifica . isso e feito. Ao fazer uma modelagem, e im-
portante manter clara a separa<;aode quest6es entre a visao interna e externa.
Voce pode especificar 0comportamento de urn caso de uso pela descri<;ao
do fluxo de eventos no texto de maneira suficientemente clara para que alguem
de fora possa compreende-Io facilmente. Ao escrever 0fluxo de eventos voce
dev~ra incluir como e quando 0caso de uso inicia e termina, quando 0c;so de
uso mterage com os atores e quais objetos sao transferidos e 0fluxo basico e flu-
xo alternativo do comportamento.
Por exemplo, no contexto de urn sistema de caixa eletr6nico, voce podera
descrever 0 caso de uso Val idateUser da seguinte maneira:
Isso e recomendavel para separar os fluxos alternativos do fluxo principal,
porque urn caso de uso descreve urn conjunto de sequencias e nao apenas uma
sequencia isolada e seria impossivel expressar todos os detalhes de urn caso de
uso interessante em apenas uma seqiiencia. Por exemplo, em urn sistema de re-
cursos human os, voce podera encontrar 0 caso de uso Hi re employee. Essa fun<;ao
de neg6cio geral podera ter muitas varia<;6espossiveis. Voce podera contratar
uma pessoa de outra empresa (0cenario mais comum); podera transferir uma
pessoa de urn departamento para outro (comum em empresas internacionais);
ou podera contratar urn estrangeiro residente no local (0 que incluira suas pr6-
prias regras especiais). Cada uma dessas variantes pode ser expressa em uma se-
quencia diferente.
Essecaso de usa (Hi re employee) realmente descreve urn conjunto de seqiien-
cias, emque cada seqiiencia no conjunto representa urn possivel fluxo nessas va-
ria<;6es.Cada seqiiencia e chamada cenario. Urncen~rio e uma seqiiencia esped-
fica de a~6es que ilustra 0comportamento. Os cenarios estao para os casos de
uso assimcomo as instancias estao para as classes. Isso significa que 0cenario e
basicamente uma instancia de urn caso de uso.
F' + s d. . . . s s s . s ' . 0 caso de uso come~a quando 0sistema solici-
tar ao + s . urn numero PIN, seu numero de identifica~ao pes-
soal. 0 + s . agora pode digitar 0numero PIN via teclado nume-
rico. 0 + s . confirma a entrada, pressionando a tecla Enter. 0
sistema entao verifica 0numero PIN para saber se e valido. Se 0nu-
mero PIN for valido, 0sistema reconhece a entrada, finalizando 0
caso de uso."
F' + s . s . . . s s ' d. . . . s s . 0 + s . pode cancelar uma transa~ao a
qualquer momento, pressionando 0botao Cancelar, reiniciando assim
o caso de uso. Nenhuma altera~o e realizada na conta do + s .
F' + s . s . . . s s ' d. . . . s s . 0 + s . pode limpar 0numero PIN a
qualquer momenta antes de submete-Io e redigitar urn novo numero
PIN.
F' + s . s . . . s s ' d. . . . s s . Se 0 + s . entrar urn numero PIN inva-
lido, 0caso de uso e reiniciado. Se isso ocorrer tres vezes seguidas 0
sistema cancela toda a transa~ao> impedindo ao + s . intera~ir
com 0caixa eletr6nico por 60segundos.
Nota: Existe um fa tor de expa nseo dos ca sos de usa pa ra os cen6rios. Um sistema
modesto mente complexo pa der6 ter a lguma s duzia s de ca sos de uso ca pta ndo esse
comporta mento e coda coso de uso poder6 ser expa ndido em v6ria s duzia s de cen6rios.
Pa ra ca da ca so de uso, voce encontra r6 cen6rios prim6rios (que definem a s seqOencia s
essencia is) e cen6ri. os secund6rios (que definem a s seqOencia s a lterna tiva s).
Casos de uso e colabora(joes
Urn . s s d. + s captura 0comportamento pretendido do sistema (ou subsiste-
ma, classe ou interface) que voce esta desenvolvendo, sem ser preciso especificar
como esse comportamento e implementado. Essa e uma separa<;:aoimportante,
porque a analise de urn sistema (que especifica 0comportamento) deveria, tanto
quanto possfvel, nao ser influenciada por quest6es referentes a implementa<;:ao
(que especificam como esse comportamento e executado). Por fim, entretanto,
e necessario implementar seus casos de uso e isso e feito pela cria<;:aode uma so-
ciedade de classese de outros elementos que trabalham em conjunto para a im-
plementa<;:aodo comportamento desse caso de uso. Essa sociedade de elemen-
tos, incluindo as estruturas estatica e dinamica, e modelada na UML como uma
colabora<;:ao.
Conforme mostra a Figura 17.4 , pode-se especificar explicitamente a reali-
za<;:aode urn caso de uso por meio de uma colabora<;:ao.Na maior parte do tem-
po, entretanto, urn determinado caso de uso e realizado por exatamente uma
colabora<;:iio, nao sendo necessario, portanto, fazer a modelagem desse relacio-
. .
namento explicitamente.
CO~:~ _
_ ! Order "
'- management /
" ".'"
realizac;ao - - - - - - ....
Nota: Embora voce nco possa visualizar esse relacionamento explicitamente, as fer-
ramentas que voce utiliza para gerenciar suas modelagens provavelmente manterco
esse relacionamento.
Nota: Encontrar 0 conjunto minima de colabora<;6es bem-estruturadas que satisfa-
zemaos f1uxosde evento especificados emtodos os casos de uso de umsistema e 0 foco
da arquitetura de um sistema.
Voce pode organizar os casos de uso agrupando<-osem pacotes do mesmo modo
como sao organizadas as classes.
Os casos de uso tambem podem ser organizados pela especifica<;:aode rela-
cionamentos de generaliza<;:ao,inclusao e extensao, existentes entre eles. Voce
aplica esses relacionamentos com a finalidade de fatorar 0comportamento co-
mum (obtendo esse comportamento a partir de outros casos de uso que ele in-
clui) e de fatorar variantes (obtendo esse comportamento em outros casos de
uso que 0estendem).
A generaliza<;:aoentre casos de uso e semelhante a generaliza<;:aoexistente
entre as classes. Aqui a generaliza<;:aosignifica que 0caso de uso filho herda 0
comportamento e 0significado do caso de uso pai; 0filho devera acrescentar ou
sobrescrever 0comportamento de seu pai; e 0filho podera ser substitufdo em
qualquer local no qual 0pai apare<;:a(ambos, 0pai e 0filho poderao ter instancias
concretas). Por exemplo, em urn sistema bancario, voce podera ter 0caso de uso
Validate User, responsivel pela verifica<;:aoda identidade do usuario. Podera en-
tao haver dois filhos especializados nesse caso de uso (Check password e Retinal
scan), ambos se comportam da mesma maneira como Va1 i date User e podem ser
aplicados em qualquer lugar em que Val i date User apare<;:a,ainda que ambos
acrescentem seu proprio comportamento (0primeiro, pela verifica<;:aoda senha
textual; 0ultimo, pela verifica<;:aodos padr6es unicos da retina do usuario).
Conforme mostra a Figura 17.5, a generaliza<;:aoentre casos de uso e representa-
da como uma linha cheia direcionada com uma seta aberta, exatamente como
ocorre com a generaliza<;:aoentre as classes.
Urn relacionamento de indusiio entre casos de uso significa que 0caso de
uso base incorpora explicitamente 0comportamento de outro caso de uso em
uma localiza<;:iioespecificada na base. 0 caso de uso indufdo nunca permanece
isolado, mas e apenas instanciado como parte de alguma base maior que 0in-
clui. Voce pode pensar na indusiio como 0caso de uso base que obtem 0com-
portamento a partir do fornecedor do caso de uso. '
Voce utiliza urn relacionamento de indusiio para evitar descrever 0mesmo
fluxo de eventos varias vezes, induindo 0comportamento comum em urn caso
de uso proprio (0caso deuso indufdo em urn caso de uso bisico). 0 relaciona-
mento de indusiio e essencialmente urn exemplo de delega<;:iio- voce coleta urn
conjunto de responsabilidades do sistema e 0captura em urn unico local (0caso
de uso indufdo); depois, permite que outras partes do sistema (outros casos de
uso) induam a nova agrega<;:iiode responsabilidades sempre que precisarem uti-
lizar ess,afuncionalidade. 1
2 3 5
rela ciona mento estendido
/
extend
(set priority)
- - - - - 1 - - - -
, pontos de extensa o
rela ciona mento de inclusa o " .
r
,:,InCIUde
Tra ck ,
order "
Pla ce
rush order
extension points
set priority
Urn reIacionarnento de inclusao pode ser representado como urna depen-
dencia, estereotipada como I n c l u d e . Para especificar a localiza~ao em urn fluxo
de eventos no qual 0caso de uso base inclui 0comportamento de urn outro, sirn-
plesrnente escreva i n c 1 u d e , seguido peIo nome do caso de uso que deseja incluir,
como no seguinte fluxo para T r a c k o r d e r :
T r a c k o r d e r :
o b t a i n a n d v e r i f y t h e o r d e r n u m b e r ;
i n c l u d e ' V a l i d a t e u s e r ' ;
f o r e a c h p a r t i n t h e o r d e r ,
q u e r y t h e o r d e r s t a t u s ;
r e p o r t o v e r a l l s t a t u s t o u s e r .
- s s . ' s . s s . s s s . s . . s s . s . s s . s s s s s s s s s + ' s 5e | , os . s . . s s ' s .
s . s s . s s s + ' 6. .
Urn relacionamento estendido entre casos de uso significa que 0caso de
uso base incorpora implicitamente 0comportamento de urn outro caso de uso
em um local especificado indiretamente peIo caso de uso estendido. 0 caso de
uso base podera permanecer isolado, mas, sob certas condi~6es, seu comporta-
mento poden! ser estendido peIo comportamento de um outro caso de uso. Esse
caso de uso base podera ser estendido somente em determinados pontos chama-
dos, sem qualquer surpresa, seus pontos de extensao. Considere extensao como
caso de uso estendido que envia um comportamento para 0caso de uso base.
Um reIacionamento estendido e utilizado para a modeIagem da parte de
urn caso de uso que 0usuario podera considerar como um compottamento op-
23 6
1
clonal do sistema. Desse modo, separa-se 0comportamento opcional do com-
portamento obrigat6rio. Urn relacionamento estendido tambem podera ser em-
pregado para a modeIagem de urn subfluxo separado, que e executado somente
sob determinadas condic;6es. Por fim, urn relacionamento estendido podera ser
utilizado para a modelagem de varios fluxos que poderao ser inseridos em urn
certo ponto, de acordo com a intera~ao explfcita com urn ator. Voce tambem
pode usar urn reIacionamento estendido para distinguir as partes configuraveis
de urn sistema de implementa~ao; a implica~ao e que 0sistema pode existir com
ou sem as varias extens6es.
o relacionamento estendido e representado como uma dependencia, este-
reotipada como e x t e n d . Os pontos de extensao do caso de uso base poderao ser
reIacionados em urn compartirnento extra. Esses pontos de extensao san apenas
r6tulos que poderao aparecer no fluxo do caso de uso base. Por exernplo, 0flu-
xo para P l a c e o r d e r podera ser lido da seguinte forma:
P l a c e o r d e r :
i n c l u d e ' V a l i d a t e u s e r ' ;
c o l l e c t t h e u s e r ' s o r d e r i t e m s ;
s e t p r i o r i t y : e x t e n s i o n p o i n t ;
s u b m i t t h e o r d e r f o r p r o c e s s i n g .
- s \ . ' s . s s . s s d. d. . s d. s . s s s . s s s s d s s s s + ' s 5e | , s s . s . . s e . s '
. s s . s s s s s s . s . s s d s s s + '
Nesse exemplo, s e t p r i o r i t y e urn ponto de extensao. Urn caso de uso po-
dera ter varios pontos de extensao (que poderao aparecer mais de uma vez) e es-
ses pontos sempre serao considerados peIos seus nomes. Em circunstancias nor-
mais, esse caso de uso base sera executado independentemente da prioridade de
ordem. Se, por outro lado, for uma instancla de uma ordem de prioridade, 0flu-
xo para esse caso base sera executado, conforme foi descrito acima. Entretanto,
no ponto de extensao ( S e t P r i o r i t y ) , 0 comportamento do caso de uso estendido
( P l a c e r u s h o r d e r ) sera realizado e depois 0fluxo prosseguira. Se houver varios
pontos de extensao, 0caso de uso estendido simplesmente permanecera em seu
fluxo de ordem.
Nota: Orga niza r os ca sos de uso/extra indo 0 comporta mento comum (por meio de
rela ciona mentos de inclusiio) e diferencia ndo a s va ria ntes (por rela ciona mentos esten-
didos), e uma pa rte importa nte pa ra a cria <;:iiode um conjunto de ca sos de uso simples,
equilibra do e compreensfvel, pa ra 0 seu sistema .
Os casos de uso san classificadores e, portanto, poderao ter atributos e opera-
~6es que voce podera representar da mesma maneira como faz com as classes.
Considere esses atributos como os objetos encontrados no caso de uso cujo
compor,tamento externo voce preclsara descrever. De modo semelhante, consi-123 7
dere essas opera<roescomo as a~oes do sistema cujo fluxo de eventos sera neces-
sario descrever. Esses objetos e opera<roespoderao ser utilizados em diagramas
de intera<raopara especificar 0comportamento do caso de uso.
- u s s | + s . s s . s ( . s s s . s s s s d s s s + ' 4 ; s s s + s s s d. . s s d s s . s s s s ds s
s s + ' i i
Por serem classificadores, voce tambem pode anexar maquinas de estados
aos casos de uso. As maquinas de estados podem ser uma outra forma de se des"
crever 0comportamento representado por urn caso de uso.
Tecnicas basicas de modelagem
Modelagem do comportamento de um elemento
A modelagem do comportamento de urn elemento sera a situa<raomais comum
em que os casos de uso serao aplicados, seja esse elemento 0sistema como urn
todo, urn subsistema ou uma classe. Ao fazer a modelagem do comportamento
desses elementos, e importante que voce focalize 0que 0elemento faz e nao
como faz.
- u s s s . s s . s + | s s . s s s s . s s s s d s s s + ' 3 2; s s . ' s s s . s s s s . s . s s ds s s s s + / s
1.
Aaplica<raodos casos de uso aos elementos dessa maneira e importante por
tres razoes. Primeiro, a partir da modelagem do comportamento de urn elemen-
to por meio de casos de uso, voce proporciona aos especialistas do dominio uma
maneira de especificar sua visao externa em urn grau suficiente para que os de-
senvolvedores construam sua visao interna. Os casos de uso fornecem urn forum
para que seus especialistas de domini os, usuarios finais e desenvolvedores pos-
sam se comunicar uns com os outros. Segundo, os casos de usa oferecern uma
forma de os desenvolvedores abordarem urn elemento e compreende-io. Urn sis-
tema, subsistema ou classe poderao ser complexos e cheios de opera<roese ou-
tras partes. Especificando casos de usa do elemento, voce ajuda os usuarios des-
ses elementos a aborda-Ios de uma maneira direta, de acordo com a forma com
que provavelmente os utilizarao. Na ausencia desses casos de uso, os usuarios
precisam descobrir, por conta propria, como utilizar os elementos. Os casos de
uso permitem que 0autor de urn elemento comunique sua inten<;:aoa respeito
de como 0elemento devera ser utilizado. Terceiro, os casos de uso servem como
base para testar cada elemento, a medida que ele evolui durante seu desenvolvi-
mento. Testando-se continuamente cada elemento em rela<raoa seus casos de
uso, voce validara continuamente a sua implementa<;:ao.Esses casos de uso nao
so fornecem uma fonte de testes de regressao, mas sempre que incluir urn novo
238/ caso de uso com urn elemento, voce sera obrigado a reconsiderar sua implemen-
ta<;:aopara assegurar que esse elemento admite modifica"oes. Se nao admitir,
deve ajustar sua arquitetura de maneira apropriada.
Para fazer a modelagem do comportamento de urn elemento:
Identifique os atores que interagem com 0elemento. Candidatos a ato-
res incluem grupos que exigem determinado comportamento para a rea-
liza"ao de suas tarefas ou que sac necessarios direta ou indiretamente
para a realiza<raode fun"oes do elemento.
Organize os atores, identificando papeis gerais e mais especializados.
Para cada ator, considere as formas primarias em que 0ator interage
com 0elemento. Considere tambem as intera"oes que alteram 0estado
do elemento ou seu ambiente ou que envolvam uma resposta a algum
evento.
Considere tambem as formas excepcionais em que cada ator interage
com 0elemento.
Organize esses comportamentos como casos de uso, aplicando relaciona-
mentos de inclusao e estendidos com a finalidade de fazer a fatora<;:aodo
comportamento comum e diferenciar 0comportamento excepcional.
Por exemplo, urn sistema de vendas a varejo interage com os clientes que
incluem e acompanham seus pedidos. Por sua vez, 0sistema remetera os pedi-
dos e cobrara dos clientes. Conforme mostra a Figura 17.6, e possIvel fazer a
modelagem do comportamento de urn sistema como esse, declarando-se esses
comportamentos como casos de usa (Pl ace order, Track order, Shi p order e Bi 11
customer). 0 comportamento comum pode ser fatorado (Val idate customer) e va-
riantes (Ship parti al order) tambem podem ser identificadas. Para cada urn desses
casos de uso, voce poderia incluir uma especifica<raodo comportamento, por
meio de urn texto, maquina de estados ou intera<r0es.
Va lida te
customer
~<extend
(ma teria ls rea dy)
figura 17.6: A modelagem do comportamento de urn elemento
A medida que seus modelos crescem, voce percebera que muitos casos de
+ s s tendem a se reunir em grupos relacionados conceitual e semanticamente.
Na UML, voce pode usar os pacates para fazer a modelagem desses agrupamen-
tos de classes.
Dicas e sugestoes
Ao fazer a modelagem de casos de uso na UML, todos os casos deverao repre-
sentar algum comportamento distinto e identific:ivel do sistema ou de parte do
sistema. Urn caso de uso bem-estruturado:
Nomeia urn comportamento do sistema ou de parte do sistema, que seja
unico, identificavel e razoavelmente atomico.
Faz a fatora~ao do comportamento comum, obtendo esse comporta-
mento a partir de outros casos de uso que ele inclui.
Faz a fatora~ao das variantes, aplicando esse comportamento a outros
casos de uso que 0estendem.
Descreve 0fluxo de eventos de maneira suficientemente clara para que
alguem de fora seja capat de compreende-Io com facilidade.
E descrito por urn conjunto minimo de cenarios que especificam a se-
mantica normal e variante do caso de uso.
Mostre somente os casos de uso que sao importantes para a compreen-
s s s d comportamento do sistema ou de parte do sistema em seu con-
texto.
Mostre somente os atores que estao relacionados com esses casos de uso.
Capitulo 18
DIAGRAMAS DE
CASaS DE Usa
Os diagramas de casos de uso saGurn dos diagramas disponiveis na UML
para a modelagem de aspectos dinamicos de sistemas (diagramas de atividades,
diagramas de grafico de estados, diagramas de seqiiencias e diagramas de comu-
nica~ao saGquatro outros tipos de diagramas da UML para a modelagem de as-
pectos dinamicos de sistemas). Os diagramas de casos de uso tern urn pape! cen-
tral para a modelagem do comportamento de urn sistema, de urn subsistema ou
de uma classe. Cada urn mostra um conjunto de casos de uso e atores e seus rela-
cionamentos.
- s s s s s s s . s . ds s . s s . s s s s s s s s + ' i , s s s s s s . / . s . . s s s s s s
s . s . s s s s s s + ' 25; s s s s s s . . + s . s ; s e s . s . . s . s s s s . s ' . s s s s s
+ ' |
Voce aplica os diagramas de casos de uso para fazer a modelagem da visao
de caso de uso do sistema. Na maior parte, isso envolve a modelagem do contex-
to do sistema, subsistema ou classe ou a mode!agem dos requisitos do comporta-
mento desses elementos.
Os diagramas de casos de uso saGimportantes para visualizar, especificar e
documentar 0comportamento de urn elemento. Esses diagramas fazem com
que sistemas, subsistemas e classes fiquem acessiveis e compreensiveis, por apre-
sentarem uma visao externa sobre como esses elementos podem ser utilizados
no contexto. Os diagramas de casos de uso tambem saGimportantes para testar
sistemas executaveis por meio de engenharia de produ~ao e para compreen-
de-Ios por meio de engenharia reversa.
Primeiros passos
Suponha que alguem the entregue uma caixa. De urn lado da caixa, existem al-
guns bot6es e urn pequeno painel LCD. Alem disso, a caixa nao contem qual-
quer descri~ao; voce nao tern qualquer pista sobre como utiliza-la. Voce poderia
apertar os bot6es aleatoriamente ever 0que acontece, mas voce foi bastante
pressionado a tentar compreender 0que a caixa faz ou como utiliza-Ia sem gas-
tar muito tempo com 0processo de tentativa e erro.
Sistemascomplexos de software podem ser semelhantes a essa situa~ao. Se
voce for urn usuario, podera receber uma aplica~ao que devera utilizar. Se a
aplica<;aoobedecer as conven<;6esnormais do sistema em opera<;aocom 0qual
voce esta acostumado, talvez voce seja capaz de conseguir fazer algo uti! apos al-
gumas tentativas, mas, dessa maneira, nunca compreendera seu comportamento
mais complexo e sutil. De modo semelhante, se voce for urn desenvolvedor, po-
dera receber uma aplica~ao ou urn conjunto de componentes com a incumben-
cia de utiliza-Io sendo pressionado a saber como utilizar esses elementos ate 0
modelo conceitual estar formado para conhecer como usa-Io.
Com a UML, voce pode aplicar diagramas de casos de uso para visualizar 0
comportamento de urn sistema, subsistema ou dasse, para que os usuarios pos-
sam entender como utilizar esse elemento e os desenvolvedores possam imple-
menta-Io. Conforme mostra a Figura 18.1, voce pode fornecer urn diagrama de
caso de uso ao fazer a modelagem do comportamento dessa caixa - que a maio-
ria das pessoas chama de telefone celular.
Urn d s s s d. . s s s d. + s s e urn diagrama que mostra urn conjunto de casos de
uso e atores e seus relacionamentos.
Propriedades comuns
Urn diagrama de caso de uso e apenas urn tipo especial de diagrama e compartilha
as mesmas propriedades comuns a todos os demais diagramas - urn nome e urn
contelido grafico que sao uma proje~ao em urn modelo. 0 que diferencia urn dia-
grama de caso de uso dos outros tipos de diagramas e 0seu contelido particular.
Assunto
Casos de uso
Atores
Relacionamentos de dependencia, generaliza<;aoe associa<;ao
- u s . s s s s d. + s s e s s s . s s ' . s s s s d s s s + ' 17; s s . ' s . s s . s s s ' s . s . s s
d s s s s + ' s 5 e | , s s s . . s s s . . . s s + ' 12; s s s s s . s s s ' . s ' . s ds s s
s + ' |
Assimcomo os outros diagramas, os diagramas de casos de uso podem con-
ter notas e restri~6es.
Os diagramas de caso de uso tambem podem conter pacotes, utilizados
para agrupar elementos do modelo em conjuntos maiores. Ocasionalmente,
voce tambem desejara induir instancias de casos de uso em seus diagramas,
principalmente quando quiser visualizar um sistema especffico em execu~ao.
Nota ~a o
o assunto e exibido como urn retangulo que contem um conjunto de elipses de
casos de uso. 0 nome do objeto e colocado no retangulo. Os atores sao apresen-
tados como figuras de palito colocadas fora do retangulo; seus nomes sao colo-
cados embaixo deles. Linhas conectam leones de atores a elipses de casos de uso
com os quais se comunicam. Os rela~ionamentos entre casos de uso (como ex-
tensao e indusao) sao desenhados denrro do retangulo.
gem com 0sistema constituem 0contexto do sistema. Esse contexto define 0
ambiente em que esse sistema existe.
Na UML, e possivel fazer a modelagem do contexto de urn sistema com urn
diagrama de caso de usa, dando-se enfase aos atores que estao ao redor do siste-
ma. Decidir 0que e incluido como ator e importante, pois, ao faze-Io, voce es-
pecifica a classe de coisas que interagem com 0sistema. Decidir 0que nao esta
incluido como ator e igualmente, se nao ainda mais, importante, pois restringira
o ambiente do sistema para incluir somente os atores que SaDnecessarios na vida
do sistema.
Voce aplica os diagramas de casos de usa para fazer a modelagem da visao do
caso de usa de urn assunto, como urn sistema. Essa visao proporciona suporte
principalmente para 0comportamento de urn sistema - os servi~os externamen-
te visiveis que 0sistema fornece no contexto de seu ambiente.
Ao fazer a modelagem da visao de caso de uso de urn assunto, tipicamente
voce aplicara os diagramas de casos de uso em uma de duas maneiras.
A modelagem do contexto de urn assunto envolve desenhar uma linha ao
redor de todo 0sistema e declarar quais atores ficam fora do assunto e como eles
interagem. Aqui voce aplicara os diagramas de casos de uso para especificar os
atores e 0significado de seus papeis.
Identifique os limitesdo sistema decidindo quais comportamentos saDpar-
te dele e quais saDrealizados por entidades externas. Issodefine 0assunto.
Identifique os atores que se encontram ao redor do sistema, consideran-
do quais grupos precisam de ajuda do sistema para a realiza~ao de suas
tarefas; quais grupos sao necessarios para a execu~ao de fun~6es do sis-
tema; quais grupos interagem com algum hardware externo ou outros
sistemas de software; e quais grupos realizam fun~6es secundarias de ad-
ministra~ao e de manuten~ao.
Organize os atores semelhantes em uma hierarquia de gener;:tliza~ao/es-
pecializa~ao.
Ofere~a urn estere6tipo para cada ator, para ajudar a compreensao.
A modelagem dos requisitos de urn assunto envolve a especifica~ao do
que esse assunto devera fazer (sob urn ponto de vista externo ao assunto), in-
dependente de como 0assunto devera faze-Io. Aqui, voce aplicara os diagra-
mas de casos de uso para especificar 0comportamento desejado do assunto.
Dessa maneira, urn diagrama de caso de uso permite que voce visualize todo 0
assunto como uma caixa preta; e possivel ver 0que esta fora do assunto e
como ele reage a algo externo, mas nao e possivel ver como 0assunto funciona
internamente.
Preencha urn diagrama de caso de uso com esses atores e especifique os ca-
minhos de comunica~ao de cada ator ate os casos de uso do sistema.
Por exemplo, a Figura 18.2 mostra 0contexto de urn sistema de valida~ao
..de cart6es de credito, com uma enfase nos atores ao redor do sistema. Voce en-
contrara Cl i entes, dos quais existem dois tipos (Cl i ente individual e Cl i ente juri-
dico). Esses atores sao os papeis desempenhados pelos seres humanos quando in-
teragem com 0sistema. Nesse contexto, tambem existem atores que represen-
tam outras institui~6es, como a Institui c;ao de venda a varejo (com a qual 0Cl i ente
realiza transa~ao com 0cartao para comprar qualquer item ou servi~o) e a Insti-
tuic;ao financeira patrocinadora (que serve como carteira de compensa~ao para a
conta de cartao de credito). No mundo real, esses dois ultimos atores saDseme-
lhantes aos pr6prios sistemas complexos de software.
Essa mesma tecnica se aplica a modelagem do contexto de urn subsistema.
Urnsistema em urn nivel de abstra~ao costuma ser urn subsistema de urn sistema
maior em urn nivel mais alto de abstra~ao. A modelagem do contexto de urn
subsistema e, portanto, util quando voce esta construindo sistemas a partir de
outros sistemas interconectados.
Tecnicas basicas de modelagem
Modelagem do contexto do sistema
Dado urn sistema - qualquer sistema - algumas coisas se encontrarao dentro do
sistema, algumas coisas se encontrarao fora dele. Por exemplo, em urn sistema
de valida~ao de cartao de credito, dentro do sistema serao encontradas coisas
como contas, transa~6es e agentes de detec~ao de fraudes. De modo semelhante,
fora do sistema serao encontradas coisas como clientes de cartao de credito e
institui~6es de vendas a varejo. As coisas que se encontram dentro do sistema
sao respons:lveis pela execu~ao do comportamento que aquelas que estao fora
24 4
1 esperam que sejafornecido pelo sistema. Todas essas coisas externas que intera-
- u s s + hs s . s s s . s s s s d s s s + ' 3 2. 124 5
Para fazer a modelagem dos requisitos de urn sisrema:
Estabele~a 0contexto do sistema, identificando os atores ao seu redor.
Para cada ator, considere 0comportamento que cada urn espera ou re-
quer que 0sistema proporcione.
Nomeie esses comportamentos comuns como casos de uso.
Fa~aa fatora~ao do comportamento comum em novos casos de uso utili-
zados pelos outros; fa~a a fatora~ao do comportamento variante em no-
vos casos de uso que estendem os fluxos da linha principal.
Fa~aa modelagem desses casos de uso, atores e seus relacionamentos em
urn diagrama de caso de uso.
Inelua adornos nesses casos de uso com notas declarando requisitos nao-
funcionais; podera ser necessario anexar alguns deles a todo 0sistema.
AFigura 18.3 expande 0diagrama de caso de uso anterior. Embora oculte
os relacionamentos existentes entre os atores e os casos de uso, sac inclufdos ca-
sos de uso adicionais que, de alguma forma, sac invisfveis ao cliente medio, por
nao serem comportamentos essenciais do sistema. Esse diagrama e valioso, por
oferecer urn ponto de partida comum para usuarios finais, especialistas de do-
mfnio e desenvolvedores para a visualiza~ao, especifica~ao, constru~ao e docu-
menta~iio de suas decisoes sobre os requisitos funcionais desse sistema. Por
exemplo, Detectar fraude de cartaoe urn comportamento importante tanto para a
Institui ~aode vendaa varejocomo para a Institui ~aofinanceira patrocinadora.De
modo semelhante, Informar0 status da contae outro comportamento solicitado
pelo sistema pelas varias institui~oes de seu contexto.
Sistema de va lida c;:a o de
ca rta o de credito
Cliente
individua l
~
Cliente
1\
o 0
A A
Instituic;:a o
de venda
a va rejo
Cliente
jurfdico Instituic;:a o
fina nceira
pa trocina dora
Modelagem dos requisitos de um sistema
Urn requisito e uma caraeterfstica de projeto, uma propriedade ou urn compor-
tamento de urn sistema. Ao estabelecer os requisitos d sistema, voce esta decla-
rando urn contrato, estabelecido entre as coisas externas ao sistema e 0proprio
sistema, declarando 0que se espera que seja feito pelo sistema. Na maior parte,
voce nao precisa se preocupar com 0que sistema faz, voce deve apenas cuidar
s s + . ele 0fa~a. Urnsistema bem-comportado executara todos os seus requi-
sitos de maneira fiel, previsfvel e confiavel. Quando voce construir urn sistema,
e importante iniciar com urn consenso a respeito do que 0sistema devera fazer,
apesar de que certamente voce evoluira sua compreensao a respeito desses re-
quisitos, a medida que iterativa e incrementalmente implementar 0sistema. De
modo semelhante, ao receber urn sistema a ser utilizado, conhecer como e1ese
comporta e essencial para emprega-lo adequadamente.
Os requisitos podem ser expressos de vadas formas, desde urn texto
nao-estruturado a expressoes em uma linguagem formal e tudo 0mais entre es-
ses extremos. A maioria, se nao todos, dos requisitos funcionais de urn sistema
pode ser expressa como casos de uso e dos diagramas de casos de uso da UML
sac essenciais para 0gerenciamento desses requisitos.
o
A
o
A
Instituic;:a o
de venda
a va rejo
Institui9a o
fina nceira
pa trocina dora
Informa r 0 sta tus
da conta
2 46/
o requisito modelado pelo caso de uso Gerenciar interrupc;ao da rede e urn
pouco diferente de todos os outros, por representar urn comportamento secun-
dario do sistema, necessario para sua opera<;aocontinua e confiavel.
- 1 d. ' s . d d s . s s s 0 . + ' | d. . s e s . . s / + s d. . d. s . s s s s ds s s
s + ' 24 .
Identifique os objetos que interagem com 0sistema. Tente identificar 0
varios papeis que cada objeto externo pode desempenhar. s
Crie urn ator para representar cada papel de intera<;ao diferente.
Para cada caso de usa do diagrama, identifique seu fluxo de eventos e
seu fluxo de eventos excepcional.
Dependendo da profundidade escolhida para 0teste, gere 0roteiro de
urn teste para cada fluxo, utilizando as pre-condi<;6es do fluxo como 0
estado inicial do teste e suas pos-condi<;6escomo criterio de sucesso.
Conforme seja necessario, gere niveis de teste para representar cada ator
que interage com 0caso de"uso. Os atores que passam informa<;6es ao
elemento ou sac ativados pelo elemento, ou poderao ser simulados ou
substitufdos por seus equivalentes do mundo real.
Use ferramentas para executar esses testes cada vez que liberar 0elemen-
to ao qual 0diagrama de caso de usa se aplica.
Uma vez que a estrutura do caso de usa e determinada, voce deve descrever
o comportamento de cada caso de uso. Normalmente, e preciso escrever urn ou
mais diagramas de seqiiencias para cada caso da linha principal. Em seguida, es-
creva os diagramas de seqiiencias para os casos variantes. Finalmente, escreva
pelo menos urn diagrama de seqiiencias para ilustrar cada tipo de erro ou condi-
<;aode exce<;ao;0tratamento de erros e parte do caso de uso e deve ser planeja-
do junto com 0comportamento normal.
A mesma tecnica se aplica it modelagem dos requisitos de urn subsistema.
Ls . s hs s . . . s s e 0processo de transformar codigo em urn modelo pelo
mapeamento a partir de uma linguagem de implementa<;ao especifica. Aplicar
automaticamente a engenharia reversa a urn diagrama de caso de uso esta bem
longe do estado da arte, simplesmente por haver uma perda de informa<;;6es
quando se passa da especifica<;aodo comportamento de urn elemento para 0
modo como ele e implementado. Entretanto, e possfvel estudar urn sistema exis-
tente e discernir seu comportamento pretendido, que voce pode entao colocar
sob a forma de urn diagrama de caso de uso. Na verdade, e exatamente isso que e
necessario fazer quando se recebe uma por<;aode software nao-documentada.
Os diagramas de casos de uso da UML simplesmente fornecem uma linguagem
padrao e expressiva para voce declarar 0que descobriu.
Para fazer a engenharia reversa de urn diagrama de caso de uso:
Engenharia de produ~a o e reversa
Amaioria dos demais diagramas da UML, incluindo os diagramas de classes, de
componente e de graficos de estados sac claros candidatos para a engenharia de
produ<;aoe reversa, pois cada urn tern urn analogo no sistema executavel. Os dia-
gramas de caso de uso sac urn pouco diferentes, porque refletem mais do que es-
pecificam a implementa<;ao do sistema, subsistema ou classe. Os casos de uso
descrevem como urn elemento se comporta e nao como esse comportamento e
implementado; portanto, eles nao sac inclufdos diretamente em uma engenha-
ria de produ<;;aoou reversa.
. Identifique cada ator que interage com 0sistema.
Para cada ator, considere a maneira como esse ator interage com 0siste-
ma, altera 0estado do sistema ou seu ambiente, ou responde a algum
evento.
Trace 0fluxo de eventos do sistema executavel relativo a cada ator. Ini-
cie com os fluxos primarios e somente depois considere os caminhos al-
ternativos.
Agrupe os fluxos relacionados, declarando urn caso de uso correspon-
dente. Considere a modelagem de variantes, usando relacionamentos do
ripo estendido e considere a modelagem de fluxos comuns pela aplica-
<;aode relacionamentos de inclusao.
Represente esses atores e casos de uso em urn diagrama de caso de uso e
estabele<;;aseys relacionamentos.
Ls . s hs s d. d+ e 0processo de transformar urn modelo em codi-
go pelo mapeamento em uma linguagem de implementa<;ao. 0 diagrama de
caso de uso pode ser inclufdo na engenharia de prodri<;;aopara formar testes
destinados ao elemento ao qual ele se aplica. Cada caso em urn diagrama de
caso de uso especifica urn fluxo de eventos (e as variantes desses fluxos). Esses
fluxos especificam 0comportamento esperado desse elemento - isso e algo
que vale a pena ser testado. Urn caso de uso bem-estruturado ate especifica pre
e pos-condi<;;6esque poderao ser utilizadas para definir 0estado inicial de urn
teste e 0correspondente criterio de sucesso. Para cada caso de urn diagrama de
caso de uso, voce podera criar urn caso de teste a ser executado sempre que
voce liberar uma nova versao desse elemento, confirmando, assim, que 0ele-
mento esta funcionando conforme e exigido antes de outros elementos depen-
derem dele.
2 48
1
Dicas e sugestoes
Ao criar diagramas de casos de uso na UML, lembre-se de que todo diagrama de
caso de uso e apenas uma apresenta<;ao grafica da visao estatica do caso de uso de
urn sistema. Isso significa que nenhum unico diagrama de caso de uso deve captar
tudo a respeito da visao de caso de usa do sistema. Em conjunto, todos os diagra-
mas de casos de uso de urn sistema representam a visao estatica completa do caso
de uso do sistema; individualmente, cada urn representa apenas urn aspecto.
Urn diagrama de caso de uso bem-estruturado:
Tern como foco comunicar urn aspecto da visao estatica de caso de uso
do sistema.
Contem somente os casos de uso e atores essenciais a compreensao desse
aspecto.
Fornece detalhes consistentes com seu nfvel de abstra<;ao; deverao ser
expostos somente os adornos (como os pontos de extensao) essenciais a
compreensao.
Nao e tao minimalista, que informe malo leitor sobre a semantic a que e
importante.
De-Ihe urn nome capaz de comunicar seu proposito.
Distribua seus elementos para minimizar 0cruzamento de linhas.
Organize seus elementos espacialmente, de maneira que os comporta-
mentos e papeis semanticamente relacionados apare<;am proximos fisi-
camente.
Use notas e cores como indica<;6es visuais e chamar aten<;ao para carac-
terfsticas importantes do diagrama. .
Tente nao mostrar muitos tip os de relacionamentos. Em geral, se voce
tiver relacionamentos de inclusao e estendido complicados, coloque es-
ses elementos em outro diagrama.
Os diagramas de seqiiencia e os diagramas de comunica<;ao - chamados de
diagramas de intera<;ao - SaDdois dos diagramas utilizados na UML para a mo-
delagem dos aspectos dinamicos de sistemas. Urn diagrama de intera<;ao mostra
uma intera<;ao, formada par urn conjunto de objetos e seus relacionamentos, in-
cluindo as mensagens que poderao ser enviadas entre eles. Urn diagrama de se-
qiiencias e urn diagrama de intera~ao que da enfase a ordena<;ao temporal das
mensagens; 0diagrama de comunica~ao e urn diagrama de intera<;ao que da en-
fase a organizac;:ao estrutural dos objetos que enviam e recebem mensagens.
- u s d s s s s d. s . ds d. s d s s s s d. s / . d. . s s d s . d s s s s d. . s s s d. + s s s + s
. s s d. d s s s s + ' s d s s \ / s s s d. ' s . d. s s . d s d s . s d. s s . s s , s
d s s s s d. s . ds d. s s s . s s s s ds s s s + ' i , s d s s s s d. u / . s d. . s s d s s s
s . s . s s d s s s + ' 25; s d s s s s d. . s s s d. + s s s . s ' . s d s s s + ' | "
Os diagramas de interac;:ao saD utilizados para fazer a modelagem dos as-
pectos dinamicos do sistema. Na maior parte, isso envolve a modelagem de ins-
tancias concretas ou prototfpicas de classes, interfaces, componentes enos, jun-
tamente com as mensagens que sao trocadas entre des, tudo isso no contexto de
urn cenario que ilustra urn comportamento. Diagramas de intera<;6es podem
aparecer sozinhos para visualizar, especificar, construir e documentar a dinami-
ca de uma determinada sociedade de objetos ou podem ser utilizados para fazer
a modelagem de urn determinado fluxo de controle de urn caso de uso.
Os diagramas de interac;:ao nao Sa D importantes somente para a modela-
gem de aspectos dinamicos do sistema, mas tambem para a constru<;ao de siste-
mas executaveis por meio de engenhariade produc;:ao e reversa.
,