r

Artigo publicado
na edio 19

setembro/outubro de 2006

w w w . m u n d o j a v a . c o m . b r

artigo

Ivar Jacobson, Scott Ambler, Martin Fowler, Craig Larman. Entre autores famosos existem vises diferentes a respeito do maior benefcio do uso da UML, porm, nenhum deles cita a documentao do sistema como uma caracterstica importante! Neste artigo, contaremos a histria de um projeto, aplicando a UML de uma maneira simples e concisa. Vamos partir dos requisitos, levantando casos de uso e, ento, analisaremos o problema utilizando a UML 2.0 como nossa aliada.

UML
no documentao!
comum analistas questionarem sobre a melhor maneira de usar a UML para documentar um sistema. Gestores de fbricas de software procuram treinamentos dizendo: - Queremos documentar o sistema usando UML. Essa necessidade de documentar projetos de software tem aumentado, principalmente, com a febre do CMM. Infelizmente, usar a UML s para documentar o sistema extremamente desaconselhvel! Se voc ler a obra de metodologistas famosos, entre eles, existem vises diferentes a respeito do maior benefcio do uso da UML, porm, nenhum deles cita que a documentao um benefcio importante. Alguns chegam a dizer que a UML no serve para documentar! A UML 2.0, na sua melhor forma, uma ferramenta de anlise. A anlise traduzir requisitos em componentes do software, descobrindo informaes. Isso tambm chamado de design ou modelagem. Neste texto, estaremos referenciando essa tarefa simplesmente como anlise. Para demonstrar essa aplicao da UML, ser desenvolvido um estudo de caso. Partiremos da necessidade e, aplicaremos a UML 2.0 para investigar e aprofundar o conhecimento a respeito do problema, assim chegaremos soluo. Neste ensaio prtico, sero quebradas algumas idias erradas. Um projeto de software no deve ter ambigidades e burocracias desnecessrias. Devemos sempre respeitar o dinheiro investido nos projetos que participamos, entregando o software funcionando e documentado na medida certa. Requisitos, modelo e cdigo possuem responsabilidades distintas e complementares, cada um tem o seu propsito. Todos eles juntos so o projeto, no importando quais deles so a documentao. Temos que acabar com as ambigidades e tambm com os documentos que tentam controlar essas ambigidades. A UML aplicada corretamente, como ferramenta de anlise, para descobrir informaes, tem a sua utilidade. Primeiramente, vamos explicar o estudo de caso.
50 www.mundojava.com.br

Rodrigo Yoshima (rodrigoy@aspercom.com.br) tcnico em Processamento de Dados pela UNESP, bacharel em Administrao de Empresas pelo Mackenzie-SP e certificado em UML 2.0 pela OMG. Possui 12 anos de experincia em desenvolvimento de software. Trabalha h 7 anos em fbricas de software e projetos de misso crtica para grandes indstrias, bancos e hospitais. instrutor da ASPERCOM e lder tcnico de projetos estratgicos da Procwork.

Artigo UML no documentao!

Estudo de Caso: Oficinas Hot Motors

J que vamos demonstrar o uso prtico da UML 2.0, desenvolveremos um estudo de caso um pouco mais elaborado. No ser o projeto de caixa eletrnico, que aparece em todos os exemplos de UML! Vamos simular um cliente que chegou para a fbrica de software e solicitou um sistema para cadastro de clientes e controle sobre o processo interno da empresa. Tente compreend-lo. A Hot Motors uma rede de lojas especializada em tuning (customizao) de veculos. Atualmente, conta com sete lojas espalhadas em grandes centros urbanos do Brasil. O mercado de customizao de veculos est em plena expanso no pas e atualmente a rede fatura R$ 12 milhes anuais. O PROBLEMA Atualmente, no possui um cadastro dos clientes, seus veculos e acessrios instalados. Em primeiro lugar, sem esse cadastro, tem-se dificuldades quando os clientes retornam s lojas para adicionar mais itens customizados nos seus veculos. O cliente muito fiel marca e este cadastro importante. Com o cadastro de clientes, veculos e acessrios instalados, podera-se saber antecipadamente a configurao do veculo, agilizando o atendimento. Um cadastro de clientes tambm permitiria campanhas de marketing e promoes futuramente. Cada oficina possui trs setores: pintura, mecnica e eltrica. A pintura,

O problema
Em todo desenvolvimento de software, importante ter uma viso geral do problema, antes mesmo de investigar o que o sistema deve fazer. Verifique o problema relatado por nosso cliente, a Hot Motors:

alm de pintar, instala pra-choques, aeroflios e outros itens no interior do veculo. A mecnica trabalha com a performance do motor, como a instalao de um Injetor de Nitro. O setor eltrico instala aparelhagem de udio, vdeo e iluminao. O problema nesses trs setores o fluxo do atendimento. Ele deve ocorrer na seguinte seqncia: pintura, mecnica e eltrica. comum o cliente solicitar a remoo, ou substituio, de algum acessrio que ele j possui instalado no veculo. Esse servio tambm cobrado. A nica parte informatizada na loja o estoque. Cada loja possui um computador com acesso internet, onde o vendedor controla o estoque usando o sistema StockOn. Atualmente, tudo o que foi instalado no veculo anotado em papel. Ao final do atendimento, o vendedor digita essas informaes no StockOn e cobra o cliente. Aqui, se tem mais problemas: no na garantia que os instaladores realmente anotaram tudo. Pode acontecer de algum acessrio no ser instalado por

vrias razes. Isso causa discrepncias no estoque ou, pior ainda, o cliente pode ter algum acessrio instalado e sair sem pagar por ele. A razo desses problemas que determinados acessrios, obrigatoriamente necessitam de outros acessrios para a instalao. Exemplo: um Injetor de Nitro requer o acessrio Cilindro e Conjunto de Mangueiras. Acessrios tambm possuem itens opcionais. Eles devem ser sugeridos ao cliente. Exemplo: sugerir um Intercooler quando um Turbo solicitado. Uma boa soluo seria um sistema de cadastro de clientes, veculos e acessrios instalados, juntamente com um controle de atendimento integrado com o StockOn. Por razes de infra-estrutura da loja, s os vendedores poderiam acessar esse sistema. O controle do atendimento dentro da oficina (pintura, mecnica e eltrica) continuaria no papel, porm, com uma guia de atendimento emitida pelo sistema garantindo que a cobrana e baixa do estoque sejam corretas.

O desafio de negcio que o sistema deve resolver esse. Em resumo: o cliente chega loja e um atendimento aberto com as instalaes e remoes a serem feitas. Uma guia em papel emitida para acompanhar o carro dentro da oficina, e cada item do atendimento marcado quando instalado. Finalmente, tudo instalado ou removido, a guia volta para o vendedor e o atendimento finalizado. S os itens instalados ou removidos so cobrados. importantssimo que todo o time do projeto saiba exatamente o problema que o sistema vai resolver. O entendimento do propsito do sistema ajuda a sanar muitas dvidas. O problema descrito no texto nos d uma idia de onde o software vai atuar, mas ainda muito vago o que ele tem que fazer. Precisamos dos requisitos do software mais detalhados.

Os requisitos
Existem inmeras maneiras de capturar requisitos de um software. Para citar algumas: Quadro 1. Tcnicas de captura de requisitos. Tcnica Processo origem User Stories XP (Extreme Programming) Features FDD (Feature Driven Development) Use Cases (Casos de Uso) OOSE, atualmente Unified Process Como este artigo sobre UML, os requisitos sero detalhados com casos de uso, assim poderemos explicar um pouco a respeito do dia51

Artigo UML no documentao!

grama, mas qualquer uma dessas tcnicas poderia ser utilizada. Tudo depende do engajamento do usurio no projeto e a configurao do seu processo de desenvolvimento como um todo. O Caso de Uso uma maneira de demonstrar o funcionamento do sistema pela viso do usurio. Podemos chamar o Caso de Uso de OBJETIVO, pois ele retrata um objetivo do Ator. Uma explicao mais detalhada dessa tcnica assunto para outro artigo. Olhando para o problema e discutindo com os usurios, chegamos aos Casos de Uso conforme figura 1.

O Caso de Uso no precisa necessariamente ter uma narrativa passo-apasso detalhada. Em cadastros ou funcionalidades simples, uma descrio geral suficiente para deixar claras as responsabilidades alocadas ao Caso de Uso. Vamos descrever agora uma narrativa passo-a-passo de um importante Caso de Uso: Abrir Atendimento.

Figura 1. Diagrama de Casos de Uso.

O Diagrama de Casos de Uso um resumo do sistema. Voc pode utiliz-lo para fazer um levantamento inicial dos OBJETIVOS e ATORES, e depois escrever os textos das narrativas. Ou voc pode escrever as narrativas e depois fazer o diagrama. De qualquer forma, para a tcnica de Casos de Uso, o texto (a narrativa) muito mais importante que o diagrama. O diagrama tambm destaca integraes com sistemas externos, e em quais Casos de Uso ocorre essa integrao. O StockOn o sistema de Estoque citado no problema. O diagrama de Casos de Uso simples mesmo para sistemas grandes. Basicamente, ele mostra ATORES, OBJETIVOS E INTEGRAES COM SISTEMAS EXTERNOS. Se o seu sistema simples e o diagrama de Casos de Uso est parecendo um plstico-bolha (cheio de elipses), bem capaz que tenha alguma coisa errada. Voc pode tambm estabelecer relacionamentos <<include>> e <<extend>> entre Casos de Uso, mas esses conceitos so intrinsecamente ligados tcnica de Casos de Uso (no vou entrar em detalhes aqui, fica para o prximo artigo). Para nosso ensaio, neste artigo, estes Casos de Uso so suficientes. Note que esses no so todos os requisitos do sistema, certamente existem muitos outros. Analisamos somente estes trs inicialmente, pois esses remediam diretamente as piores dores da Hot Motors. Isso , so os requisitos que solucionam os maiores problemas (cadastro de clientes e fluxo dentro da loja). Olhando para o Caso de Uso Cadastrar Cliente, Veculo e Acessrios, d para imaginar que seria um cadastro relativamente simples, ento, no seria necessria uma narrativa passo-a-passo detalhada. Neste momento, este Caso de Uso teria somente uma descrio:

Caso de Uso: Abrir Atendimento O Ator informa que deseja abrir um Atendimento, informando a placa do Veculo. O Sistema exibe as informaes do Veculo, dos Acessrios desse Veculo e do Cliente [A1]. [P1] O Ator verifica os dados e informa critrios de busca por Acessrios para instalao [A2]. O Sistema lista os Acessrios que satisfazem a busca. O Ator seleciona um Acessrio. O Sistema confirma a disponibilidade de estoque, exibe os Acessrios obrigatrios para a instalao, sugere os opcionais e informa o preo [A3, A4]. O Ator seleciona os opcionais. O Sistema informa o preo atualizado [A3]. O Ator finaliza as incluses. O Sistema inclui o Acessrio, seus obrigatrios e opcionais escolhidos para instalao no Atendimento e atualiza o seu valor total. Volta ao passo [P1] por quantas vezes o ator desejar. O Ator confirma os dados do atendimento [A5]. O Sistema reserva os Acessrios utilizados no estoque e imprime a Guia de Atendimento com os Acessrios por ordem de setor. Os Acessrios a serem removidos aparecem antes dos Acessrios a instalar. O Caso de Uso encerra. Fluxo Alternativo A1 Veculo no-existente O Sistema informa que o Veculo informado no existe. Volta ao nicio do Caso de Uso. Fluxo Alternativo A2 Removendo Acessrio do Veculo O Ator informa um Acessrio do Veculo para remoo. O Sistema inclui o Acessrio na lista de remoes do Atendimento e atualiza o valor total. Volta ao passo [P1]. Fluxo Alternativo A3 Acessrio indisponvel no estoque O Sistema informa que o Acessrio (ou algum de seus obrigatrios) est indisponvel no estoque. Volta ao passo anterior. Fluxo Alternativo A4 Veculo j possui este Acessrio instalado O Sistema informa que o Veculo j possui este Acessrio instalado. Volta ao passo anterior. Fluxo Alternativo A5 Removendo Acessrio do Atendimento O Ator informa um Acessrio includo por engano no Atendimento. O Sistema remove o Acessrio do Atendimento, atualiza o valor total do Atendimento e volta ao passo [P1].

Caso de Uso: Cadastrar Cliente, Veculos e Acessrios Descrio geral: este Caso de Uso responsvel por incluir e alterar um Cliente, os Veculos deste Cliente e os Acessrios desses Veculos. Um veculo s pode estar associado a um Cliente e a busca pelo cliente deve ser por nome ou CPF.

52 www.mundojava.com.br

Artigo UML no documentao!

Dvidas na tcnica de Casos de Uso so muito comuns. A maioria dos analistas erra na escrita da narrativa passo-a-passo. Muitos de vocs podem estar olhando para esse Caso de Uso e podem estar falando que esse texto est simples demais. A narrativa no est simples por se tratar de um sistema fictcio. Seria desta forma mesmo se este projeto fosse real. Uma boa narrativa de Caso de Uso deve ser clara e focada nas necessidades do Ator. Outro detalhe importante: nas respostas do Sistema, voc deve escrever somente O QUE o Sistema responde e no COMO ele faz para obter essa resposta. O funcionamento interno do sistema ser analisado mais tarde. Ainda estamos nos requisitos! O Caso de Uso mapeia o problema e no a soluo. Vamos descrever o ltimo Caso de Uso importante para a arquitetura da aplicao: Encerrar Atendimento. Com esses trs Casos de Uso, j podemos iniciar o design da aplicao com uma substancial segurana respeito das necessidades mais importantes da Hot Motors.

Hot Motors, precisamos de outro diagrama da UML 2.0: o Diagrama de Atividades. Veja figura 2.

Caso de Uso: Encerrar Atendimento Ator: Vendedor O Ator informa que deseja encerrar um Atendimento informando o nmero. O Sistema exibe os dados do Veculo, do Cliente e uma lista dos Acessrios do Atendimento. O Ator informa os Acessrios que realmente foram instalados ou removidos usando a Guia de Atendimento. O Sistema efetua a baixa dos Acessrios instalados no Estoque, retira os Acessrios no-instalados da reserva de Estoque, atualiza a configurao do Veculo e atualiza o valor total do Atendimento. O Ator confirma o encerramento do Atendimento. O Sistema encerra o Atendimento e o Caso de Uso termina.

Mais um Caso de Uso descrito e mais uma vez est demonstrado como Casos de Uso so simples. Eles s explicam como o Ator usa o Sistema. Qual a opinio de vocs respeito desses requisitos? Vocs imaginam que um exemplo muito grande para um artigo de revista? Se o nosso foco aqui fosse demonstrar a codificao do sistema pode ser que este seja um exemplo elaborado demais, mas para a tica da anlise, esse sistema no to grande assim. Logicamente, se voc colocar esse desenvolvimento dentro de um processo burocrtico e pesado, tudo pode ficar bem complicado. Gostaria que vocs fizessem um levantamento do esforo em horas desse sistema junto aos seus gestores e coordenadores para analisarmos a estimativa deles. Estes Casos de Uso j esto muito bons para avanarmos no projeto. Vamos complementar um pouco a viso do problema, entendendo como sistema se encaixa no processo da loja.

Figura 2. Diagrama de Atividades demonstrando o Atendimento da Hot Motors.

Neste diagrama, temos tarefas que sero desempenhadas no sistema (destacadas em amarelo), e tarefas que esto fora do escopo do sistema (todas as outras). Alguns analistas de negcio, lendo este artigo, podem estar falando: - Voc deveria detalhar melhor esta atividade Instalar/ Remover Acessrios, mas no estamos fazendo anlise de negcio. O que acontece dentro da oficina no interessa para o sistema. Um Comment (notinha) da maneira como est no diagrama suficiente para demonstrar que o fluxo segue a seqncia: pintura, mecnica e eltrica, sem precisar detalhar as tarefas desses setores. Quando analisamos um sistema, precisamos saber o propsito daquilo que estamos fazendo. Precisamos deixar as coisas o mais simples possvel. Em primeiro lugar, este digrama se tornou necessrio para entender melhor onde o sistema se encaixa dentro do processo da loja, e se esse encaixe est coerente. Essa necessidade surgiu porque existe um documento em papel emitido pelo sistema: a Guia de Atendimento. Ela dar suporte a atividades que esto fora do escopo do sistema (o trabalho dos pintores, mecnicos e eletricistas). Essa guia fornecer todas as informaes necessrias para encerrar o atendimento, mas no preciso analisar como os mecnicos trabalham para visualizar isso. Em segundo lugar, este diagrama confirma como os dois Casos
53

O processo da Hot Motors (workflow)

Uma das maiores crticas que os analistas da anlise estruturada fazem aos Casos de Uso que eles no demonstram processo (workflow). E realmente no demonstram! Essa no a funo dos Casos de Uso. Os Casos de Uso so focados em objetivos dos Atores. As elipses retratam o que o usurio poder fazer com o sistema. Para analisar o processo da

Artigo UML no documentao!

de Uso Cadastrar Cliente, Veculo e Acessrios e Abrir Atendimento atendero aos seguintes cenrios: 1. o Cliente chega na loja pela primeira vez e no possui qualquer cadastro; 2. um Cliente cadastrado chega na loja, mas com um Veculo no-cadastrado; 3. um Cliente cadastrado chega na loja, mas o Veculo est desatualizado no sistema. O modelo de Casos de Uso no demonstra as necessidades do fluxo de trabalho da loja. Conforme citado, Casos de Uso no modelam processos e relacionamentos <<include>> e <<extend>> no resolvem isso! Aps entender como os Casos de Uso se encaixam no processo interno da loja, com este diagrama, conclui-se que o Ator Vendedor vai ter que navegar entre as telas dos dois Casos de Uso para resolver os trs cenrios acima, e nenhum outro Caso de Uso necessrio. Com o processo e objetivos resolvidos, abro um parntese importante neste pargrafo: se voc fabrica software espero que esteja aplicando, ou tentando aplicar, o desenvolvimento iterativo. Resumindo: reduza o risco do projeto. Entregue o software ao usurio em pequenos pedaos incrementais (iteraes). Por que isso reduz o risco? Principalmente porque o usurio consegue ver a cara da aplicao poucos dias depois do incio do projeto. Ele pode rapidamente avaliar se o que est sendo desenvolvido atende s suas necessidades. Aplicamos isso no levantamento de requisitos: somente os Casos de Uso mais importantes foram levantados. Agora, vamos fazer um exerccio para escolher qual Caso de Uso seria interessante entregar primeiro para a Hot Motors. Precisamos um para analisar, codificar, testar e entregar, assim a Hot Motors avaliar se estamos avanando na direo correta. Qual deles voc escolheria? uma boa prtica do desenvolvimento de software iterativo que voc ataque os maiores riscos primeiro (logicamente respeitando a dependncia entre os requisitos). Fazendo uma analogia, no jogo de xadrez, voc deve se esforar mais para abater a rainha do seu adversrio, no os pees. A rainha apresenta um risco maior, voc cuida dos pees depois. Se no seu projeto, a equipe est gastando muita energia em matar os pees existe um potencial enorme de falha. Desses trs Casos de Uso, o Abrir Atendimento seria indicado para uma primeira iterao. Neste Caso de Uso, esto os requisitos mais complexos: Instalao/Remoo de Acessrios e a integrao com o StockOn. Sobre o StockOn, vamos simular uma situao bem corriqueira nos projetos: a Hot Motors ainda no liberou qualquer documentao e no sabemos se a integrao ser via Banco de Dados, API ou Web Services (voc j deve ter passado por isso). Isso no deve impedir o incio da anlise, pois h como abstrair essa integrao de maneira muito fcil no modelo. Isso permitir que essa integrao ocorra mais tarde sem invalidar o diagrama. No a falta dessa informao que vai paralisar o nosso projeto (mesmo assim, com certeza o coordenador vai guardar essa carta na manga para justificar atrasos). Escolhido o primeiro Caso de Uso, iniciam-se as tarefas de anlise para traduzir esses requisitos em componentes de software. Para isso, vamos usar a UML como nossa aliada e no como instrumento para fomentar a burocracia e a complexidade. Explicando melhor, o intuito deste artigo deixar claro que:

Vamos falar mais sobre isso. Guarde esta frase: a UML no um processo, a UML no diz que ordem voc deve seguir para desenhar os diagramas. comum escutar pessoas questionando quais diagramas so obrigatrios e quais so opcionais. Bem, todos os diagramas so opcionais se voc partir do princpio de usar a ferramenta certa para o problema certo. Se o problema no existe, voc no precisa da ferramenta! Processos de desenvolvimento de software de vrias empresas possuem regras do tipo: Todo Caso de Uso deve ter um Diagrama de Atividades demonstrando os fluxos possveis. Ser que o Caso de Uso Encerrar Atendimento necessita de um Diagrama de Atividades para que seu fluxo se torne claro? Lgico que no! Ele nem possui fluxos alternativos. Imagine que voc um marceneiro e seu chefe exija que para bater um prego, alm do martelo, voc DEVE tambm usar a serra e o pincel. Faz sentido? Essas regras ocorrem principalmente quando o processo diz que s um documento prova que a tarefa foi feita. LEMBRE-SE: voc modela o que precisa ser modelado. Com essa regra em mente, vamos descobrir as classes do Domain Model. As classes do Domain Model so abstraes do mundo real da Hot Motors para um mundo virtual, que simular essa realidade dentro do sistema. O Domain Model em Java foi muito bem explicado no artigo OO com Padres de Negcio de Phillip Calado Shoes da MundoJava nmero 17, alis, muitos dos patterns explicados pelo Shoes sero aplicados na Hot Motors.

Encontrando classes e atributos

Uma boa dica para encontrar as classes do Domain Model observar os substantivos dos requisitos ou o vocabulrio do usurio. Vejam alguns desses substantivos: Cliente, Veculo, Acessrio, Atendimento. Podem existir muitos outros, mas podemos descobri-los mais tarde. Vamos iniciar um diagrama para investigar o relacionamento entre essas classes. Mas antes, imagino que voc j tenha um modelo mental dessas classes enquanto foi lendo os requisitos. Desenhe esse modelo mental para que voc possa comparar com a soluo proposta. Veja figura 3. Espero que o seu modelo mental esteja bem prximo disso, apesar de existir inmeras maneiras de resolver este problema (algumas bem esquisitas). O Diagrama de Classes o mais popular da UML. Muitos profissionais s conhecem este diagrama e colocam nos seus currculos que conhecem UML, mas a UML possui muitos outros diagramas importantes. difcil demonstrar escrevendo como se chega soluo da figura 3. Geralmente so feitos rascunhos, experimentaes e as Classes saem sangrando com tantas flechadas. Mas isso que analisar com a UML: olhar os requisitos e desenhar a melhor maneira de atend-los, pesquisando possibilidades e descobrindo fraquezas no modelo. Muitos de vocs podem estar dizendo que d para partir do modelo mental diretamente para o cdigo. Sim, possvel, mas o modelo UML uma perspectiva mais ampla e amigvel, consigo ver vrias classes ao mesmo tempo. mais difcil ter uma viso assim no cdigo: o cdigo texto, voc olha uma classe por vez. necessrio navegar entre vrias classes para se ter idia do todo. Vou relatar como este diagrama da figura 3 foi usado para descobrir informaes importantes, que inclusive no constam nos requisitos e vamos precisar revis-los. Quando estava pensando no Atendimento, logo estabeleci a associao C (no tinha desenhado a associao B

Voc modela o que precisa ser modelado

54 www.mundojava.com.br

Artigo UML no documentao!

Figura 3. Diagrama de Classes de Domnio.

ainda). De fato, o Atendimento feito em cima do Veculo, o Veculo ligado ao Cliente atravs da associao A (que bidirecional), dessa forma, imaginei que o Atendimento no necessitaria associao direta com o Cliente. Mas a veio um pensamento a respeito do mundo real: Ser que correto afirmar que um veculo sempre vai ser do mesmo dono em todos os Atendimentos? No poderia ocorrer do Joo ter um Supra, instalar um Nitro, vender o carro para o Jos e o Jos querer instalar um DVD?. No mundo real, isso perfeitamente possvel, mas no nosso mundo virtual, esse cenrio no havia passado pela nossa cabea at agora. Foi bom descobrir isso em tempo de anlise e foi o modelo visual que me ajudou a vislumbrar este problema facilmente. O primeiro passo para remediar isso foi o estabelecimento da associao B, assim, um Atendimento feito em um Veculo para o Cliente que o possui naquele momento. Agora, como mapear essa descoberta nos requisitos? O Diagrama de Atividades (figura 2) diz que, se existe algum problema de cadastro, o fluxo vai para a atividade Cadastrar Cliente, Veculo e Acessrios. Este Caso de Uso deve resolver essa transferncia entre proprietrios. Como ele ser desenvolvido nas prximas iteraes, no precisamos perder tempo pensando como isso ser resolvido. Isso no impacta a iterao atual. Essa independncia conseqncia de Casos de Usos bem coesos e direcionados ao objetivo do Ator. Simplesmente, ao final do Caso de Uso Cadastrar Cliente, Veculo e Acessrios, escrevemos:

1. no Caso de Uso (alguns dados que constam na narrativa); 2. ao analisar a interao entre objetos que resolver o Caso de Uso (faremos isso mais adiante); 3. conversando com os usurios. Uma ferramenta rica para encontrar atributos um prottipo da tela. Atributos que so s informativos geralmente no constam no Caso de Uso. As melhores ferramentas para desenhar e validar uma tela com o usurio o lpis (ou caneta, giz de cera, o que for). Vamos fazer um rascunho da tela de abertura de atendimento. Veja figura 4.

Este Caso de Uso dever resolver a situao do Joo comprar um Supra, instalar um Nitro, vender o carro para o Jos e ele querer instalar um DVD. Isso , um Veculo pode ser transferido de um Cliente para outro.

Postergar coisas so comuns no desenvolvimento iterativo. Nesse ponto, o foco deve ser o Caso de Uso Abrir Atendimento, certo? Ento, veja que as classes ainda no possuem todos os atributos. Voc encontra atributos das seguintes maneiras:

Figura 4. Rascunho da tela de abertura de Atendimento.

55

Artigo UML no documentao!

Este rascunho foi elaborado junto com a Hot Motors. Ele tambm foi usado para descobrir informaes. Logicamente, este rascunho no UML 2.0. A UML no uma boa ferramenta para modelar telas, apesar de ser possvel fazer isso. Algumas telas Swing complexas podem ser modeladas usando um Diagrama de Comunicao para mapear eventos. Para prottipos de sistemas Web, voc tambm pode usar HTML simples. Em Aplicaes Desktop, voc pode fazer uma casca vazia em Swing ou SWT. Avalie bem o quanto voc vai investir no prottipo. Para iteraes

iniciais mais importante validar conceitos do que deixar o software visualmente bonito. O prottipo nesse momento aprofunda o nosso conhecimento do problema, e prova aquilo que j compreendemos. Um rascunho da tela torna o Caso de Uso mais palpvel e, tambm, nos ajuda a achar atributos novos: o Veculo possui fabricante, marca, modelo, ano de fabricao, tipo de combustvel. Um acessrio tambm possui fabricante e a sua chave partNumber. Vamos atualizar essas classes, conforme diagrama de classes das figuras 5 e 6.

Figura 5. Novos atributos e associaes de Veiculo e Acessrio.

Figura 6. Novos atributos e associaes do Atendimento.

Descobrindo operaes e comportamentos

Os Diagramas de Classe elucidam o aspecto esttico ou estrutural do sistema, mas atributos e associaes sozinhos no traduzem todo o funcionamento do software. As classes devem colaborar entre si para resolver os requisitos. Os prximos diagramas so usados para descobrir como as classes se comportam e quais so as suas responsabilidades atravs de operaes. D para imaginar que a classe Atendimento ter uma operao encerrar(), mas colocar essa operao diretamente na classe na figura 6 pura especulao e foge do propsito da iterao atual. Sem uma viso de como essa classe interage com outras, no sabemos se essa operao encerrar() realmente necessria e nem quais parmetros ela precisa. Para descobrir os comportamentos das classes, a UML 2.0 define os diagramas de interao (no confunda com iterao). Temos o Diagrama de Comunicao, que substituiu o Diagrama de
56 www.mundojava.com.br

Colaborao da UML 1.X. O Diagrama de Viso Geral da Interao, que no existia na UML 1.X, uma tima ferramenta para modelar interaes mais longas. Por fim, temos o famoso Diagrama de Seqncia, o mais utilizado para este propsito de descobrir operaes. nesse ponto que a tcnica de Casos de Uso comea a fazer mais sentido. Comentei que o Caso de Uso mapeia o problema. O Caso de Uso s mostra O QUE o sistema responde e no COMO ele obtm a resposta. Os requisitos nos dizem o que o sistema tem que fazer, e no como ele faz. O como ele faz analisado melhor com Diagramas de Interao. O Caso de Uso demonstra como o sistema funciona pela viso do Ator (lado de fora). Um Diagrama de Seqncia pode ser utilizado para descobrir como as Classes conversam entre si, para realizar o objetivo do Ator (lado de dentro). Veja figura 7.

Artigo UML no documentao!

Figura 7. Diagrama de seqncia: Abrir Atendimento.

Como puderam ver, usamos Domain Patterns (vide artigo citado, MundoJava n 17). A TelaAbrirAtendimento uma representao da tela demonstrada no rascunho da figura 4. Ela recebe as aes do Ator Vendedor. A primeira seta j deixa claro que, para a interao comear, o Vendedor precisa saber uma placa. O Vendedor no ter problemas para ter essa informao, pois o atendimento inicia com o carro na frente dele na loja. A tela recebe essa placa e chama uma operao no faade que procurar o veculo. O faade delega essa chamada para o repositrio de Veculos (abstrao de uma coleo com todos os veculos do sistema). A interao avana respondendo COMO cada solicitao do Ator resolvida DENTRO do sistema. Este o funcionamento interno, que no responsabilidade do Caso de Uso. Sobre a arquitetura, modela-se num nvel de abstrao em concordncia com os arquitetos e codificadores do projeto. Isso garante que o modelo seja implementvel em cdigo (necessitando de alguns ajustes, principalmente nas primeiras iteraes). Os frameworks atuais (EJB 3.0, Spring, Hibernate) permitem que a anlise seja feita basicamente se focando no Domain Model com classes POJOS. Padres como Dependency Injection, Data Mapper, Lazy Load, etc. integram o Domain Model com a infra-estrutura da aplicao. Resumindo: arquiteturas

fortes permitem um modelo mais abstrato e a anlise mais rpida. O Diagrama de Seqncia uma excelente ferramenta de anlise. Com uma narrativa passo-a-passo, ou um prottipo, o Diagrama de Seqncia timo para descobrir qual componente responsvel por cada ao, dando um panorama geral do que est acontecendo. Mais uma vez, difcil demonstrar como o analista modela essa interao, mas no demorou mais que 5 minutos. A cada solicitao do Ator, voc vai navegando dentro do sistema, esticando setas e atribuindo responsabilidades. Depois da primeira seta informa placa, o raciocnio o seguinte: - O que a tela tem que fazer agora? Ah, procurar o Veculo. Quem procura o Veculo? Alguma coisa na camada de negcios que estaria atrs do faade. Um repositrio de Veculos? Sim, vou cri-lo. J tenho o Veculo. E agora? Cada seta atirada define um emissor e um receptor da mensagem. Isso torna claro algumas dependncias, mas o maior benefcio o foco em descobrir somente as verdadeiras operaes necessrias para atender aos requisitos. Aps a anlise com o diagrama da figura 7, as classes que s possuam atributos, possuem operaes. Veja figura 8.

Figura 8. Diagrama de classes atualizado.

57

Artigo UML no documentao!

Voc notou que existe um quadro no diagrama da figura 7 chamado Incluir Acessorio e Opcionais? Este um recurso da UML 2.0 chamado ocorrncia de interao. Ele serve para dividir uma

interao grande em pedaos menores e reutilizveis. Veja o que tem dentro deste quadro na figura 9.

Figura 9. Diagrama de seqncia: inserir Acessrio e seus Opcionais.

Obs.: os diagramas de seqncia das figuras 7 e 9 so partes do fluxo bsico do Caso de Uso. Infelizmente, no poderemos realizar o Caso de Uso todo aqui, mas as outras interaes seguem o mesmo padro (os diagramas completos podem ser obtidos no site da ASPERCOM, veja a referncia no fim do artigo).

deles poderiam at se traduzir em setas, mas entre um diagrama rigorosamente correto e um simples, opte por um diagrama simples. Os detalhes no esto no modelo. O objetivo do uso dos diagramas de interao modelar a conversa entre vrios objetos, podendo inclusive constar o Ator. Basicamente, so as operaes pblicas que so encontradas. Esse diagrama no uma boa ferramenta para demonstrar o detalhe dessas operaes. Muitas vezes, analistas esticam uma seta para um receptor, e a partir da, passam a programar no modelo, destacando tudo que o receptor faz dentro da operao. Isso uma pssima idia. O cdigo melhor para mostrar esses detalhes e no precisamos dessa ambigidade. O modelo UML possui as operaes da classe e no mtodos. As operaes do modelo UML so abstraes de como a Classe se comporta. Operaes so estmulos que a Classe vai atender, mas o detalhe da operao est dentro do cdigo, no MTODO. O mtodo o programa que implementa a operao. A UML no possui diagramas para demonstrar a implementao de mtodos. Alguns analistas defendem que o Diagrama de Seqncias deve ser um espelho daquilo que est nos mtodos, para tudo ficar bem documentado, mas no consigo imaginar o que o projeto ganha com isso. Essa prtica gera modelos pesados, complexos e engessa completamente o trabalho do analista. E pode ter certeza que esse espelho completamente distorcido. As IDEs atuais facilitam bastante a escrita do cdigo: temos autocompletar, checagem de sintaxe automtica, controle de

Essa interao ocorre na tela para incluir acessrios no atendimento. No temos o prottipo dessa tela e no precisamos dele, o Caso de Uso deixa claro o que o usurio precisa. Note que o Caso de Uso nem menciona que ela existe. Mais uma vez, na figura 9, parte-se do comando do ator e aloca-se responsveis, descobrindo novas operaes. Aqui, aparece o servio responsvel pelo controle de estoque, o StockOn, mas no modelo ficar somente essa abstrao EstoqueService. Essa interface responder quais servios o StockOn dever atender futuramente. A implementao dessa interface resolver a integrao, quando tivermos a documentao faltante do StockOn. Os diagramas de seqncia das figuras 7 e 9 so partes do fluxo bsico do Caso de Uso. Infelizmente, no poderei realizar o Caso de Uso todo aqui, mas as outras interaes seguem o mesmo padro (os diagramas completos podem ser obtidos no site da revista). Vejam que muitos comments (notas) podem ser usados para explicar o modelo. Alguns

58 www.mundojava.com.br

Artigo UML no documentao!

excees. Coisas que o modelo no tem. Enfim, mais fcil entender o que ocorre dentro da operao diretamente no cdigo. Para qu ter essa ambigidade? Cuidado com esses espelhos na sua documentao. Eles so um risco real de tornar seu processo pesado e difcil de manter.

E a documentao?
A preocupao excessiva com a documentao do cdigo herana das experincias que tivemos nos sistemas procedurais: - E quando o sistema estiver em manuteno?, perguntvamos. Bem, o cdigo procedural longo, linear, pouco coeso e complexo. Ele no consegue se explicar sozinho. Isso no acontece nas linguagens orientadas a objeto como Java. Num sistema orientado a objetos bem coeso e bem fundamentado, a prpria estrutura e semntica da classe so auto-explicativas e necessitam pouca documentao. completamente errada a idia de que o modelo UML serve para documentar o cdigo. O modelo UML documenta como componentes interagem para atender aos requisitos. O cdigo responsvel por implementar os detalhes de como esses componentes interagem. Se a semntica da prpria classe no for suficiente, o que documenta o cdigo so os comentrios dentro dos programas, o Javadoc como exemplo. A UML no a documentao do cdigo. Costumo dizer: use a UML como ferramenta de anlise e ganhe a documentao. Por qu? Vamos dar um exemplo: escrevi este artigo como uma experincia em tempo real: defini requisitos, fui modelando e contanto a histria. Usei a UML 2.0 para analisar o problema. Apliquei cada diagrama quando senti necessidade. Desenhei todos os elementos com o objetivo de descobrir informaes. Cada seta tinha um propsito bem definido. Fiz muitos diagramas, mas em nenhum momento senti que estava documentando o sistema. Eu senti que estava produzindo o sistema. No entanto, os diagramas esto a. Eles so rastros do meu trabalho de anlise e suprem as necessidades de documentao. Eles podem ser utilizados para o trabalho do time de arquitetura e tambm para quem for codificar e testar o software (podendo ser eu ou algum de vocs, a definio de papis aqui irrelevante). Esses documentos, frutos do trabalho de anlise, j so suficientes para avanar com o projeto. Vejam que temos ambigidade quase zero. Cada artefato tem o seu propsito bem definido. No precisa contar a mesma histria em cada documento diferente. Quando for definir seus artefatos, pense da mesma maneira que voc faz com o cdigo: alta coeso e baixo acoplamento.

Uma das grandes crticas sobre o uso da UML nos projetos a questo do modelo ficar defasado com relao ao cdigo. Realmente isso acontece, e pode piorar muito se o seu modelo for pesado, muito prximo do cdigo, ou dependente da arquitetura. Os mecanismos que sincronizam o cdigo com o modelo enxergam melhor a estrutura esttica das classes. Com isso, provvel que no processo de sincronizao, seus diagramas de seqncia, como exemplo, fiquem desatualizados. A tcnica passada aqui no artigo demonstra uma maneira de minimizar bastante esse risco. Focando o modelo basicamente na camada de negcio do sistema (Domain Model), deixamos os diagramas mais isolados das complexidades arquiteturais e das especificidades da camada de apresentao. Desse modo, as grandes alteraes do modelo seriam motivadas por alteraes de negcio ou de requisitos. No teriam alteraes bruscas efetuadas diretamente no cdigo que impactariam tanto o modelo. Se quiser eliminar completamente o risco do modelo ficar desatualizado, jogue fora os diagramas (recomendao do Martin Fowler). Eles j cumpriram o papel como ferramenta de anlise.

Concluso
Voc explora todo o potencial da UML 2.0 utilizando-a como uma ferramenta de anlise. A UML tambm uma tima ferramenta de comunicao. Um time que fala UML dissemina informaes mais rapidamente e com menores falhas de entendimento. difcil analisar numa mesa de reunio trs pginas de cdigo. Um diagrama torna isso mais fcil. Existem outros diagramas na UML 2.0 e todos eles oferecem algumas facilidades que no existiam na UML 1.X. A UML 2.0 muito grande, mas os diagramas citados neste artigo (Casos de Uso, Atividades, Classes e Seqncia) so os mais utilizados e se aplicam a muitos projetos. Quando pensei no estudo de caso da Hot Motors, imaginei que o Diagrama de Mquina de Estados tambm seria necessrio, mas no foi. Este diagrama explora os estados possveis de uma Classe (ou qualquer outra coisa), e como ocorrem as transies entre esses estados. A classe Atendimento possui dois estados Aberto e Encerrado, isso bem claro. A transio entre esses estados simples, ento, no precisamos deste diagrama. A anlise e design um dos trabalhos mais criativos no desenvolvimento de software. Nesse trabalho, os analistas e designers so os responsveis, mas todo o time est envolvido, dando sugestes e criticando modelos inflexveis. Esse trabalho de criao deve ser gil. Preencher documentos burocrticos e ambguos conspira contra a criatividade e a motivao da sua equipe, principalmente, se faltar um senso de propsito do artefato no projeto O estudo de caso HotMotors analisado parcialmente, devido a restries de espao, neste artigo pode ser complementado no site www.aspercom.com.br/hotmotors.

Continuando o projeto
Com relao codificao, outro aspecto importante que a UML uma ferramenta independente de plataforma ou linguagem. Se a arquitetura suporta esse nvel de abstrao do modelo, posso codificar o sistema da Hot Motors em Java, C#, Ruby, etc. As informaes descobertas na anlise no se perdem. Essa caracterstica importante em fbricas de software onde o time de anlise e design trabalha para projetos de vrias tecnologias. Os prximos passos depois da anlise concluda so: gerar cdigo, completar os programas, integrar o que for necessrio e testar o software. A gerao de cdigo um instrumento para ganhar agilidade. O modelo j tem pacotes, classes, atributos e operaes definidas, o codificador no precisa redigitar tudo isso. Mas a gerao de cdigo UML s para essa facilidade e pode variar de ferramenta para ferramenta. D para gerar muitas outras coisas se voc tiver uma ferramenta MDA, mas antes que isso gere discusses, falaremos sobre MDA em outro artigo tambm.

Referncias COCKBURN, ALISTAIR (2000). Writting Effective Use Cases, Addison Wesley. EVANS, ERIC (2004). Domain-Driven Design PENDER, TOM (2004). UML - A Bblia, Campus. OMG (2004). UML 2.0 Final Adopted Specification, www.omg.org/uml. FOWLER, MARTIN (2002). Patterns of Enterprise Application Architecture, Prentice Hall. VRIOS (2001). Home page. Manifesto for Agile Software Development, www.agilemanifesto.org. www.aspercom.com.br Curso On-line Grtis sobre Casos de Uso

59