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