1

LtIiJML Essencial

F787u Fowler, Martin UML essencial: um breve guia para a linguagem padro de modelagem de objetos/Martin Fowler e Kendal Scott; trad. Vera Pezerico e ChristianThomas Price. -2. ed. - Porto Alegre: Bookman, 2000. 1. Computao - Programao de computador- UMI. 1. Scott, Kendal. fI.Ttulo. CDU 681 .3(UML) Catalogao na publicao: Mnica Bailejo Canto - CRB 10/1023 ISBN 85-7307-729-8

MARTIN FOWLER e KENDALL SCOTT L Essencial Um breve guia para a linguagem-padro de modelagem de objetos 2Edio Traduo: Vera Pezerico e Christian Thomas Price Consultoria, Superviso e Reviso Tcnica desta edio: Roberto Tom Price Professor do Instituto de Informtica da UFRGS Reimpresso 2003 Li4 Boonan Porto Alegre, 2000

Obra originalmente publicada sob o ttulo UML Distilled - A BriefGuide to the Standard Object Modeling Language Addison Wesley Longman, mc., 2000 ISBN 0-201-65783-X Publicado conforme acordo com Addison Wesley Longman, mc. Capa:Mrio Ri) hnelt Preparao de originais: Lus Augusto Junges Lopes Superviso editorial: Arysinha Jacques Affonso Editorao eletrnica: Liser House - in. q. o.f vc -, .. ),..J - . p,l UN1VERSAri STCI DI sA 11(3 TCAS [_ _______-____ j Reservados todos os direitos de publicao, em lngua portuguesa, ARTMED EDITORA S.A. (BOOKMAN COMPANhIA EDITORA uma diviso da ARTMED EDITORA S.A.) Av. Jernimo de Ornelas, 670 - Santana 90040-340, Porto Alegre, RS Fone (51) 3330-3444 Fax (51) 3330-2378 proibida a duplicao ou reproduo deste volume, no todo ou em parte, sob quaisquer formas ou por quaisquer meios (eletrnico, mecnico, gravao, fotocpia,distribuio na Web e outros), sem permisso expressa da Editora.

SO PAULO Av. Rebouas, 1073 - Jardins 0540 1-150, So Paulo, SP Fone (11) 3062-3757 Fax (11) 3062-2487 SAC 0800 703-3444 IMPRESSO NO BRASIL PRINTED IN BRAZIL

Apresentao 1 1 Quando comeamos a moldar UML. (Unified Modeling Laguage); pervamos poder produzir um meio-padro de expressar projetos que no somente refletisse as melhores prticas da indstria, mas que tambm ajudass a desmistificar o processo de modelagem de sistemas de software. Acreditvamos que a disponibilidade de uma linguagem de modelagem-padro encorajaria mais desenvolvedores a modelar os seus sistemas de softzvare, antes de constru-los. A adoo rpida e muito difundida de UML demonstra que os benefcios da modelagem so, de fato, bem conhecidos da comunidade de desenvolvedores de software. A criao de UML foi por si s um processo iterativo e incremental muito semelhante modelagem de um grande sistema de software. O resultado final um padro baseado nas muitas idias e contribuies feitas por diversas pessoas e empresas dacomunidade. Comeamos o trabalho de UML mas muitos outros contriburam para uma concluso de sucesso; somos muito gratos pelas suas contribuies. Criar e entrar em acordo sobre uma linguagem de modelagem-padro por si s j um grande desafio. Educar a comunidade de desenvolvedores, e para ela apresentar UML de uma forma acessvel e no contexto do processo de desenvolvimento de software, tambm um grande desafio. Neste livro aparentemente curto, atualizado para refletir as mais recentes mudanas em UML, Martin Fowler superou, certamente,este desafio. Com um estilo claro e acessvel, Martin no somente introduz aspectos-chave de UML, mas tambm demonstra claramente o papel que UML desempenha no processode desenvolvimento. Ao longo da leitura, recebemos grandes doses de sabedoria e conhecimento de modelagem decorrentes dos mais de 12 anos de experincia que o autor acumulou em projeto e em modelagem. Como resultado,

APRESENTAO temos um livro que apresenta a linguagem a milhares de desenvolvedores, aguandoseus interesses para melhor explorar os vrios benefcios da modelagem utilizando UML, agora um padro. Recomendamos o livro para qualquer modelador ou desenvolvedor interessado em conhec-la e em obter uma viso da funo-chave que ela desempenha no processo de desenvolvimento. Grady Booch Ivar Jacobson Jarnes Rurnbaugh

Prefcio H dois anos, Addison-Wesley entrou em contato comigo para que eu escrevesse um livro sobre a ento nova UML. Naquela poca, havia muito interesse em UML, mas existiam apenas documentos de padronizao para estudo. Quebramos muitos recordes para produzir um curto guia introdutrio da nova linguagem, algo que daria uma certa orientao at que livros mais detalhados viessem a aparecer, mais tarde naquele ano. No espervamos que este livro permanecesse depois que textos detalhados fossem publicados. Muitas pessoas acreditam que se tendo a escolha entre uma pequena

viso geral e um livro detalhado, todos escolhero o livro detalhado. Embora esta fosse a viso geral, eu acreditava que mesmo na presena de livros detalhados haviaainda espao para um resumo conciso. Dois anos mais tarde, as minhas esperanas foram alm do esperado. O LJML Essencial , em termos da indstria da computao, um best-seller. Mesmo que bons livros detalhados sobre UML tenham sido publicados, o livro ainda vende bem. Melhordo que isto, mais livros curtos surgiram, confirmando a minha crena de que, em um mundo com tanta informao, a brevidade bem escolhida tem o seu valor. Tudo bem, mas voc deve comprar este livro? Eu vou partir do princpio que voc j ouviu algo sobre UML, pois tornou-se o modo-padro para desenhar diagramas de projetos orientado a objetos, e tambm se espalhou em campos no-orientados a objetos. Todos os maiores mtodos pr-UML jdesapareceram. UML chegou e est aqui para ficar. Se voc quer aprender sobre UML, este livro pode ajud-lo. A maior razo para voc comear com este livro que ele um livro pequeno. Comprar um livro grande pode dar a voc mais informao, mas voc levar mais tempo para l-lo. Selecionei as partes mais importantes de UML para lhe poupar trabalho. Com

\v7 PREFCIO este livro, voc aprender os elementos-chave da notao bem como seus significados. Se voc quer ir mais alm, pode passar para um livro mais detalhado mais tarde. Se voc quer um tutorial mais detalhado sobre UML, sugiro Unzfled Modeling Language LJser Guide (Booch, Rumbaugh e Jacobson, 1999). O tJser Guide cobre maisterreno. Ele bem escrito e organizado, de forma que explica como aplicar UML a vrios problemas de modelagem. Tanto este livro como o LJser Guide partem do princpio de que voc j conhece algo sobre o desenvolvimento em 00. Muitas pessoas me disseram que este livro uma boa introduo a objetos, mas no o escrevi tendo isto em mente. Se voc est procurando por uma introduo a objetos com UML, voc deveria tambm consideraro livro de Craig Larman (Larman, 1998). Embora o ponto principal desse livro seja UML, tambm acrescentei materiai que complementa UML. UML uma parte re1ativament pequena do que voc precisa saber para ter sucesso com objetos, e acredito que importante salientar algumas outras coisas. o mais importante destas outras o processo de softzvare. UML projetada para ser independente de processo. Voc pode desenhar tudo o que quiser; o que UML faz dizer o que seus diagramas significam. Entretanto, os diagramas no tm muito sentido sem um processo que lhes d um contexto. Tambm acredito que o processo importante e que um bom processo no precisa ser complicado. Por isso, descrevi um esboo de um leve processo de desenvolvimento de software 00. Ele estabelece um contexto para as tcnicas e o ajudar a melhor utilizar objetos. Os outros tpicos incluem padres, refatorao, cdigo de autoteste, projetos por contrato e cartes CRC. Nenhum deles faz parte de UML, mas so tcnicas de grande valor que utilizo regularmente. Estrutura do Livro o Captulo 1 analisa o que UML, a histria do seu desenvolvimento e as razes pelas quais voc pode querer us-la. O Captulo 2 discute o processo de desenvolvimento orientado a objetos. Embora UML seja independente de processo, acho difcil discutir tcnicas de modelagem sem falar onde elas se encaixam com o desenvolvimento orientado a objetos. Dos Captulos 3 ao 6, as trs tcnicas mais importantes de UML so discutidas: casos de uso, diagramas de classes e modelos de interao. UML um grande monstro, mas voc no precisa dele todo. Estas trs tcnicas so a essncia do que quase

todo mundo precisa. Comece com estas e adicione as outras medida que for necessitando (observe que, devido aos diagramas de classes serem to complicados,coloquei as partes-chave dos diagramas de classes no Captulo 4 e os conceitos avanados no Captulo 6).

PREFCIO Dos captulos 7 ao 10, as tcnicas remanescentes so exploradas. Todas elas so valiosas, mas nem todo o projeto precisa de todas as tcnicas. Portanto, estes captulos fornecem informaes suficientes sobre cada tcnica se voc precisar dela. Para todas essas tcnicas, descrevo a notao, explico o que ela significa, e dou dicas de como utiliz-las. A minha filosofia esclarecer o que UML diz, e ao mesmo tempo dar a minha opinio de como melhor utiliz-la. Tambm acrescentei referncias a outros livros que fornecem mais detalhes. O Captulo 11 d um pequeno exemplo para mostrar como UML se encaixa em programao, utilizando Java ( claro). A contracapa resume a notao de UML. Voc pode considerar til us-la como referncia, enquanto estiver lendo os captulos, pois voc pode j verificar a notao para vrios conceitos de modelagem. Se voc achar este livro interessante, pode encontrar maiores informaes sobre o meu trabalho relacionado ao uso de UML, padres e refatorao na minha homepage (ver pgina xxi). Mudanas da Segunda Edio medida que UML evolua e eu recebia feedback sobre a primeira edio desse livro,eu o atualizava continuamente. A reimpresso do livro ocorria a cada dois ou trs meses; sendo que cada impresso continha atualizaes, o que significou um desgaste considervel para os processos da indstria grfica. Com a mudana de UML 1.2 para 1.3, decidimos fazer uma reviso mais detalhada do livro, o que era suficiente para produzir uma segunda edio. Uma vez que este livro se tornou to popular, tentei manter o esprito essencial dele. Tentei no adicionar muito e verificar se haveria coisas que deveriam ser retiradas. As maiores mudanas esto no Captulo 3, sobre casos de uso, e no Captulo 9 sobre diagramas de atividade, os quais foram em grande parte reescritos. Tambm adicionei uma seo sobre colaboraes ao Captulo 7. Em outras partes, aproveitei para fazer algumas pequenas modificaes baseadas emfeedback de leitores e nas minhas experincias dos dois ltimos anos. Agradecimentos da Primeira Edio Publicar um livro com essa rapidez exigiu muita ajuda de pessoas que se superaram em seus esforos para fazer a produo de forma bem mais rpida. Kendall Scot teve um papel importante coletando todo material e trabalhando com ostextos e os grficos. A medida que eu revisava o livro, ele continuava para manter tudo em ordem, completando uma srie de tarefas que surgiam de uma hora para outra e com prazos de entrega impossveis de serem cumpridos.

PREFCIO Os trs amigos, Grady Booch, Ivar Jacobson e Jim Rumbaugh, deram muito apoio e conselhos. Investimos muitas horas com ligaes internacionais, que aprimoraram muito o livro (bem como a minha compreenso de UML). Um grande nmero de revisores essencial para se fazer um bom trabalho na elaborao de um livro. Esses revisores no apenas me deram ofeedback necessrio mas tambm retornaram seus comentrios em menos de uma semana para que pudssemos cumprir o nosso curto prazo de entrega. Meus agradecimentos a: Simmi Kochhar Bhargava, da Netscape Communications Corporation, Eric Evans e Tom Hadfield, da Evolve Software, mc. , Ronald E. Jeffries e Joshua Kerievsky, da Industrial Logic, mc. , Helen Klein, da University of Michigan, James Odeli e Vivek Salgar, da Netscape Communications Corporation. E agradecimento dobrado a Tom Hadfield,

porque ele o fez duas vezes. Quero agradecer a Jim Odeil por duas coisas: primeiro por coordenar o esforo do Object Management Group (OMG) para obter um padro nico para UML, o que ser um grande progresso para nossa indstria; segundo por me encorajar a entrar no campo de anlise e projeto 00. Ah, e obrigado por revisar este livro tambm! Obrigado a Cindy por ter suportado minha ausncia, mesmo eu estando em casa. No posso imaginar as dificuldades que o meu editor, J. Carter Shanklin e sua assistente Angela Buenning, tiveram que enfrentar para publicar este livro to rapidamente. Quaisquer que tenham sido estas dificuldades, tenho certeza que Carter e Angela merecem meus agradecimentos. A indstria editorial no projetadapara lidar com mudanas feitas em um livro a cada dois meses, mas Carter e sua equipe fizeram um bom trabalho escondendo este fato! A necessidade de manter este livro atualizado me fez questionar sobre detalhes especficos de UML. Conrad Bock, Ivar Jacobson, Cris Kobrym, Jim Odeil, Guss Ramackers e Jim Rumbaugh fizeram o possvel para me ajudar a encontrar estas respostas. Inmeras pessoas me mandaram mensagens salientando vrios erros e omisses; so muitos nomes para listar aqui, mas agradeo a todos vocs. Por fim, agradeo aos meus pais por terem me dado uma boa educao da qual tudo mais se originou. Martin Fowler Melrose, Massachusetts Fowler@acm.org http://ourworld.compuserve.com/homepages/Martin_Fozvler

-. 1. Sumrio Captulo 1: Introduo 19 OqueUML 19 Como Chegamos at Aqui 20 Notaes e Metamodelos 22 Por que Fazer Anlise e Projeto7 23 Comunicao 24 Aprendendo 00 24 Comunicao com Especialistas de Domnio 26 Procurando Mais Informao 26 Captulo 2: Um Esboo de Processo de Desenvolvimento 29 Viso Geral do Processo 30 Concepo 31 Elaborao 31 Lidando com Riscos de Requisitos 32 Lidando com Riscos Tecnolgicos 35 Lidando com Riscos de Especializao 36 Lidando com Riscos Polticos 38 Quando Termina a Elaborao 38 Planejando a Fase de Construo 38 Construo 40 Box: Software de Autoteste 41 Quando o Plano se Desintegra 41 Box: Refatorao 41 Utilizando UML na Construo 43 Transio 44

Box: Padres 44

Quando Usar Desenvolvimento Iterativo 47 Onde Encontrar Mais Informao 48 Captulo 3: Casos de Uso 49 Diagramas de Caso de Uso 51 Atores 52 Associao entre Casos de Uso 53 Casos de Uso do Negcio e Casos de Uso do Sistema 54 Quando Utilizar Casos de Uso 55 Onde Encontrar Mais Informao 56 Captulo 4: Diagramas de Classes: Os Elementos Bsicos 57 Perspectivas 59 Associaes 60 Atributos 64 Operaes 64 Generalizao 66 Regras de Restrio 67 Box: Projeto por Contrato 67 Quando Utilizar Diagramas de Classes 69 Onde Encontrar Mais Informao 70 Captulo 5: Diagramas de Interao 71 Diagramas de Seqncia 72 Diagramas de Colaborao 76 Comparando Diagramas de Seqncia com Diagramas de Colaborao 77 Box: Cartes CRC 78 Quando Utilizar Diagramas de Interao 80 Captulo 6: Diagramas de Classes: Conceitos Avanados 81 Esteretipos 81 Diagrama de Objetos 82 Operaes e Atributos com Escopo de Classe 83 Classificao Mltipla e Dinmica 84 Agregao e Composio 86 Associaes e Atributos Derivados 87 Interfaces e Classes Abstratas 89 Objetos de Referncia e Objetos de Valor 92 Colees para Pontas de Associaes de Valores Mltiplos 93 Frozen 93 Classificao e Generalizao 94 Associaes Qualificadas 94 Classes de Associao 96 Classe Parametrizada 98 Visibilidade 100 Captulo 7: Pacotes e Colaboraes 103 Pacotes 103

\i37 Colaboraes 108 Quando Utilizar Diagramas de Pacotes e Colaboraes 111 Onde Encontrar Mais Informao 111 Captulo 8: Diagramas de Estados 113 Diagramas de Estados Concorrentes 117 Quando Utilizar Diagramas de Estados 119 Onde Encontrar Mais Informao 119

Captulo 9: Diagramas de Atividades 121 Decompondo uma Atividade 125 Concorrncia Dinmica 125 Raias (Swimlanes) 125 Quando Utilizar Diagramas de Atividades 127 Onde Encontrar Mais Informao 129 Captulo 10: Diagramas Fsicos 131 Diagramas de Utilizao 131 Diagramas de Componentes 131 Combinando Componentes com Diagramas de Utilizao 133 Quando Utilizar Diagramas Fsicos 134 Captulo 11: UML e Programao 135 Observao de Pacientes: Modelo de Domnio 136 Observao de Pacientes: Modelo de Especificao 139 Passando para Cdigo 142 Apndice A: Tcnicas e Suas Aplicaes 151 Apndice B: Mudanas entre Verses de UML 153 Revises de UML 153 Cronograma de Revises Futuras 154 Mudanas em UML Essencial 155 Mudanas de UML 1.0 para 1.1 155 Tipo e Classe de Implementao 155 Restries Discriminadoras Completas e Incompletas 156 Composio 156 Imutabilidade e Congelamento 156 Retornos em Diagramas de Seqncia 157 Uso do Termo Papel (Role) 157 Mudanas de UML 1.2 (e 1.1) para 1.3 (e 1.4) 157 Casos de Uso 157 Diagramas de Atividades 158 Bibliografia 159 ndice 163

Figuras Figura 1.1: Trecho do Metamodelo de UML 23 Figura 2.1: Esboo do Processo de Desenvolvimento 30 Figura 2.2: Estrutura do Padro de Projeto Proxy 45 Figura 2.3: Padro de Anlise Cenrio 46 Figura 3.1: Exemplo de Texto de Caso de Uso 50 Figura 3.2: Diagramas de Casos de Uso 51 Figura 3.3: Associao de Extenso 54 Figura 4.1: Diagrama de Classes 58 Figura 4.2: Diagrama de Classes com Navegabilidades 63 Figura 5.1: Diagrama de Seqncia 72 Figura 5.2: Processos Concorrentes e Ativaes 74 Figura 5.3: Diagrama de Seqncia: Verificao de Falha 75 Figura 5.4: Diagrama de Colaborao com Numerao Simples 76 Figura 5.5: Diagrama de Colaborao com Numerao Decimal 77 Figura 5.6: Carto Classe-Responsabilidade-Colaborao (CRC) 79 Figura 6.1: Diagrama de Classes da Estrutura de Composio de Grupo 82 Figura 6.2: Diagrama de Objetos Mostrando Exemplo de Instncias de Grupo 83 Figura 6.3: Notao de Escopo de Classe 83 Figura 6.4: Classificao Mltipla 84

Figura 6.5: Classificao Dinmica 85

Figura 6.6: Agregao e Composio 86 Figura 6.7: Notao Alternativa para Composio 87 Figura 6.8: Associaes e Atributos Associados 88 Figura 6.9: Classe Perodo de Tempo 89 Figura 6.10: Janela como Classe Abstrata 90 Figura 6.11: Interfaces e Classes Abstratas: Um Exemplo dejava 91 Figura 6.12: Notao Pirulito para Interfaces 91 Figura 6.13: Associao Qualificada 95 Figura 6.14: Classe de Associao 96 Figura 6.15: Promovendo uma Classe de Associao para uma Classe Plena 96 Figura 6.16: Sutilezas de Classes de Associao 97 Figura 6.17: Esteretipo Histria para Associaes 98 Figura 6.18: Classe Parametrizada 99 Figura 6.19: Elemento de Amarrao (Verso 1) 99 Figura 6.20: Elemento de Amarrao (Verso 2) 100 Figura 7.1: Diagrama de Pacotes 104 Figura 7.2: Diagrama de Pacotes Avanado 106 Figura 7.3: Diagrama de Seqncia para Registrar uma Venda 108 Figura 7.4: Diagrama de Classes para Colaborao Registrar uma Venda 109 Figura 7.5: Colaborao Parametrizada para Venda 110 Figura 7.6: Utilizando a Colaborao de Venda 110 Figura 8.1: Diagrama de Estados 114 Figura 8.2: Diagrama de Estados sem Superestados 115 Figura 8.3: Diagrama de Estados com Superestados 116 Figura 8.4: Autorizao de Pagamento 117 Figura 8.5: Diagrama de Estados Concorrentes 118 Figura 9.1: Diagrama de Atividades 122 Figura 9.2: Separaes, Junes e Threads Condicionais 124 Figura 9.3: Utilizando uma Atividade Composta para a Entrega 126 Figura 9.4: Concorrncia Dinmica 127 Figura 9.5: Raias 128 Figura 10.1: Diagrama de Utilizao 132 Figura 11.1: Modelo de Domnio de Observao de Pacientes 136 Figura 11.2: Diagrama de Objetos de Observao de Pacientes 137 Figura 11.3: Outro Diagrama de Objetos de Observao de Pacientes 138

Figura 11.4: Modelo de Especificao de Observao de Pacientes 140 Figura 11.5: Operaes de Observao de Pacientes 141 Figura 11.6: Diagrama de Seqncia de Observao de Pacientes 142 Figura 11.7: Outro Modelo de Especificao de Observao de Pacientes 148

1 Introduo

O Que UML? UML (Unified Modeling Language) a sucessora da onda de mtodos de anlise e projeto orientado a objetos (OOA & D) que surgiu no final dos anos oitenta e no incio dos anos noventa. Mais especificamente, ela unifica os mtodos de Booch, Rumbaugh (OMT) e Jacobson, mas o seu alcance bem maior. UML passou por um processo de padronizao pela OMG (Object Management Group) e agora um padro OMG. UML chamada de linguagem de modelagem; no um mtodo. A maioria dos mtodos consiste, pelo menos em princpio, de uma linguagem de modelagem e de um processo. A linguagem de modelagem a notao (principalmente grfica) utilizada por mtodos para expressar projetos. O processo a sugesto de quais passos a serem seguidos na elaborao de um projeto. A descrio dos processos em muitos livros de metodologias um pouco incompleta. Alem disso, acredito que a maioria das pessoas quando diz que est utilizando um mtodo usa a linguagem de modelagem, mas raramente segue o processo. Portanto, em vrios aspectos, a linguagem de modelagem a parte mais importante do mtodo. Ela certamente a parte-chave para a comunicao. Se voc quer discutir o seu projeto com algum, vocs tm que compreender a linguagem de modelagem, nao o processo que vocs utilizaram para desenvolver o projeto. Os trs amigos tambm desenvolveram um processo unificado, que eles chamam RUP (Rational Unified Process). Voc no precisa utilizar RUP para usar UML - eles sodistintamente separados. Entretanto, neste livro, abordo um pouco do processo, de modo a colocar as tcnicas de linguagem de modelagem em contexto. Nesta discusso, uso os passos elementares e os termos da RUP, mas o texto nao a descrio de RUP. Utilizo muitos processos diferentes, dependendo

INTRODUO do meu cliente e do tipo de software que estou construindo. Embora acredite que uma linguagem de modelagem-padro valiosa, no vejo a mesma necessidade para o processo-padro: ainda que alguma harmonizao de vocabulrio poderia ser til. Como Chegamos At Aqui Na dcada de oitenta, os objetos comearam a sair dos laboratrios de pesquisa e a dar seus primeiros passos em direo ao mundo real. Smaiitaik estabilizou uma plataforma que as pessoas pudessem usar, e C++ surgiu. Como muitos desenvolvimentos em softzvare, objetos foram guiados por linguagens de programao. Muitas pessoas se perguntavam como mtodos de projeto se encaixariam em um mundo orientado a objetos. Mtodos de projeto tornaram-se muito populares em desenvolvimentos industriais nas dcadas de setenta e oitenta. Muitos acreditavam que tcnicas para auxiliar as pessoas a fazerem uma boa anlise e projeto eram tambm muito importantes para desenvolvimento orientado a objetos. Os livros essenciais sobre mtodos de anlise e projeto orientado a objetos surgiram entre 1988 e 1992: Sally Shlaer e Steve Mellor escreveram dois livros (1989 e 1991) sobre anlise e projeto; o material desses livros gerou o seu enfoque de projeto Recursivo (1997). Peter Coad e Ed Yourdon tambm escreveram livros que estenderam a leve introduo de Coad orientada a prottipos para mtodos. Veja Coad e Yourdon (1991 a e 1991 b), Coad e Nicola (1993), e Coad et ai. (1995). Da comunidade de Smalltalk em Portland, Oregon, sugeriu CRD (Responsibility-Driven Design) (Wirfs - Brock et ai. 1990) e cartes CRC (Class-Responsibility-Collaboration) (Beck e Cunningham, 1989). Grady Booch fez muitos trabalhos para Rational Software desenvolvendo sistemas com Ada. Seus livros apresentam vrios exemplos (e os melhores cartoons no mundo

de livros de mtodos). Veja Booch (1994 e 1996). um Rumbaugh liderou uma equipe nos laboratrios de pesquisa da General Electric,que produziu um livro muito popular do mtodo chamado de OMT (Object Modeling Technique) veja Rumbaugh et ai. (1991) e Rumbaugh (1996). Jim OdelI baseou seus livros (escritos com James Martin) na sua longa experincia com sistemas de informao comerciais e Engenharia da Informao. O resultado foi o livro mais conceitual entre estes. Veja Martin e Odell (1994). Ivar Jacobson escreveu seus livros sobre suas experincias com sistemas de chaveamento de telefones para Ericsson e introduziu o conceito de casos de uso no seu primeiro livro. Veja Jacobson (1992 e 1995). Quando me preparava para viajar para Portland para a conferncia OOPSLA em 1994,o mercado de mtodos estava bastante dividido e competitivo. Cada um dos autores mencionados acima estava, ento, liderando informalmente um gru

UML ESSENCIAL: UM BREVE GUIA PARA A LINGUAGEM-PADRO DE MODELAGEM DE OBJETOS 21 po de praticantes que gostavam de suas idias. Todos esses mtodos so muito semelhantes, mas eles contm um nmero inoportuno de pequenas diferenas entre eles. Os mesmos conceitos bsicos apareceram em diferentes notaes, o que causava confuso para os meus clientes. Conversas sobre padronizao emergiram, mas ningum se mostrou interessado em fazer algo a este respeito. Alguns eram contra a idia de padres para metodologias. Outros gostavam da idia mas no se mostravam interessados em trabalhar com isso. Uma equipe da OMG tentou analisar uma padronizao, mas recebeu uma cartaaberta de protesto de todos os metodologistas-chave. Grady Booch tentou uma aproximao informal em um caf da manh, mas tambm no teve sucesso. (Isso me lembra uma velha piada. Qual a diferena entre um metodologista e um terrorista? Resposta: Voc pode negociar com um terrorista). Para a comunidade de metodologias 00, a grande novidade na conferncia OOPSLA 94 foi que Jim Rumbaugh havia deixado a General Electric e se unido a Grady Brooch na Rational Software, com a inteno de unir seus mtodos. O ano seguinte foi cheio de divertimentos. Grady e Jim proclamaram que a guerra de mtodos acabou - ns vencemos, declarando basicamente que eles iriam alcanar a padronizao do modo Microsoft. Um nmero de outros metodologistas sugeriu criar uma Coligao AntiBooch. Para conferncia de OOPSLA 95, Grady e Jim haviam preparado a sua primeira descrio pblica de seu mtodo unificado: verso 0.8 da documentao do Mtodo Unificado. Mais importante ainda, eles anunciaram que a Rational Software comprara Objectory, e que o Ivar Jacobson iria unir-se equipe. A Rational fez uma festa para comemorar o lanamento do rascunho 0.8, a qual foi muito concorrida. A festa tambm foi muito divertida, apesar das cantorias de Jim Rumbaugh. Durante 1996 Grady, Jim e Ivar, agora amplamente conhecidos como os trs amigos, trabalharam o seu mtodo sob o novo nome: UML (Unified Modeling Language). Entretanto, os outros grandes jogadores na comunidade de metodologia orientada a objetos no estavam inclinados a deixar que UML fosse a ltima palavra. Uma fora de trabalho OMG foi formada para fazer a padronizao na rea de metodologias. Isso representou uma tentativa mais sria para dirigir os assuntos do que os esforos anteriores da OMG na rea de metodologias. Mary Loomis assumiu a liderana; mais tarde, Jim Odell uniu-se como co-lder e assumiu, ento, a liderana do trabalho. Odell deixou claro que estava preparado para desistir da sua metodologia em favor de um padro, mas ele no queria um padro imposto pela Rational. Em janeiro de 1997, vrias organizaes submeteram propostas para um padro de metodologias a fim de facilitar a troca de modelos. Essas propostas focavam um metamodelo e uma notao opcional. ARational lanou a verso 1.0 da

documentao UML como sua proposta para a OMG. Seguiu-se, ento, um pequeno perodo de quebra de brao, enquanto vrias propostas eram unificadas. A OMG adotou a 1.1 resultante como um padro oficial daOMG. Desde ento, a RTF (Revision Task Force), dirigida por Cris Kobryn, fez algumas revises incrementais. Averso 1.2 foi somente para melhorar as aparncias, mas a verso 1.3 tornada pblica no incio de 1999 foi mais significativa.

22 r INTRODUO Notaes_e Metamodelos No seu estado atual, UML define uma notao e um metamodelo. A notao a coisa grfica que voc v nos modelos; ela a sintaxe da linguagem de modelagem. Por exemplo, a notao de diagrama de classes define como itens e conceitos so representados: classe, associao e multiplicidade. Certamente, isso leva a questo do que queremos dizer exatamente com uma associao ou multiplicidade ou mesmo uma classe. O uso comum sugere algumas definies informais, mas algumas pessoas querem mais rigor. A idia de linguagem de especificao e projeto mais rigorosa prevalece mais no campo de mtodos formais. Em tais tcnicas, projetos e especificaes so representados usando alguns derivativos de clculos predicativos. Tais definies somatematicamente rigorosas, no permitindo ambigidade. Entretanto, o valor dessasdefinies no de forma alguma universal. Mesmo que voc possa provar que um programa satisfaz uma especificao matemtica, no h maneira de provar que a especificao matemtica atinja realmente os requisitos reais do sistema. Projetar envolve a observao de assuntos-chave no desenvolvimento. Mtodos formais freqentemente levam a paralisao, com tantos detalhes menores Alm disso, mtodos formais so difceis de entender e manipular, freqentemente mais difceis de lidar do que linguagens de programao. E voc nem mesmo pode execut-los. A maioria das metodologias 00 tem pouco rigor; suas notaes apelam para intuio em vez de definio formal. Em geral, isso parece no ter causado muito estrago. Estas metodologias podem ser informais, mas muitas pessoas as consideram muito teis - e a utilidade que interessa. No entanto, as pessoas que trabalham com metodologias 00 esto procurando maneiras para melhorar o rigor das metodologias, sem sacrificar as suas utilidades. Uma maneira de fazer isso definir um metamodelo: um diagrama, geralmente um diagrama de classes, que define a notao. A Figura 1-1 uma pequena parte de um metamodelo UML que mostra a relao entre associaes e generalizao. (Este trecho aparece somente para dar uma idia do que so os metamodelos. No vou nem tentar explic-lo). Quanto o metamodelo afeta o usurio da notao de modelagem? Bem, ele ajuda a definir o que um modelo bem formado - isto , um modelo sintaticamente correto. Como tal, um usurio em potencial de uma metodologia deve compreender o metamodelo. Entretanto, a maioria dos usurios de metodologias no necessita de tal compreenso para obter algum valor na utilizao da notao UML. No sou muito rigoroso nesse livro; ao contrrio, sigo o caminho das metodologias tradicionais e apelo para a intuio do leitor. Se voc quiser um maior rigor, voc deve ler com ateno o manual de referncia ou a documentao oficial de UML. Quo exigente voc deve ser em relao adeso linguagem de modelagem? Isso depende da razo pela qual a est utilizando. Se voc tem uma ferramenta CASE quegera cdigo, deve aderir a interpretao da linguagem de modelagem da ferramenta CASE para obter cdigo aceitvel. Se estiver usando os diagramas para fins de comunicao, voc tem um pouco mais de liberdade.

UML ESSENCIAL: UM BREVE GUIA PARA A LINGUAGEM-PADRO DE MODELAGEM DE OBJETOS

e voce se afastar da notao oficial, outros desenvolvedores no compreendero exatamente o que voc est dizendo. Contudo, h vezes em que a notao oficial pode se atravessar no caminho das suas necessidades. Devo admitir que nesses casos no hesito em torcer a linguagem. Acredito que a linguagem deve ser flexionada para ajudar a me comunicar, em vez do contrrio. Mas no fao isso com muita freqncia, e sou ciente de que uma flexo uma coisa errada, pois ela causa problemas de comunicao. Neste livro, menciono aquelas ocasies em que me achoinclinado a flexionar um pouco a linguagem.

Por que Fazer Anlise e Projeto?

O ponto real do desenvolvimento de software o cdigo executvel. Os diagramas so, na verdade, apenas figuras bonitas. Nenhum usurio ir lhe agradecer pelas suas bonitas figuras; o que o usurio quer um software que execute. Ento, quando voc estiver pensando em utilizar UML importante que se pergunte por que est fazendo isso e como isso ir ajud-lo a escrever cdigo. No existe uma evidncia emprica real para provar se estas tcnicas so boas ou ms, mas as subsees seguintes discutem as razes que encontro, freqentemente, para utiliz-las. Nesta seo, abordo um pouco as tcnicas que discutirei mais tarde. Se voc considera que essas referncias para adiante so confusas, pule essa seo e volte a ela mais tarde.

Figura 1-1: Trecho do Metamodelo de UML

24 INTRODUO y Comunicaao A razo fundamental para usar UML envolve comunicao. Uso UML porque ela permite comunicar certos conceitos mais claramente do que as linguagens alternativas. A linguagem natural muito imprecisa e ela se complica quando se trata de conceitos mais complexos. O cdigo preciso, mas muito detalhado. Ento, utilizo UML quando quero uma certa preciso, mas no quero me perder em detalhes. Isso no significa evitar detalhes, ao contrrio, utilizo UML para salientar detalhes importantes. Como consultor, em um projeto complexo, tenho, freqentemente, que dar uma olhada rpida e parecer inteligente em um curto perodo de tempo. Neste caso, considero UML inestimvel porque ela me ajuda a obter uma viso geral do sistema. Uma anlise do diagrama de classes pode rapidamente me dizer que tipos de abstraes esto presentes no sistema e onde esto as partes questionveis que precisam ser mais bem trabalhadas. A medida que examino mais profundamente, quero ver como as classes colaboram, ento peo para ver os diagramas de interao que ilustram comportamentos-chave do sistema. Se isso til para mim como um estranho, tem a mesma utilidade para a equipe permanente do projeto. fcil de esquecer detalhes em um grande projeto. Com uma pequena escolha de diagramas disponveis, voc pode achar o seu caminho no software com muito mais facilidade. Para construir um mapa de um grande sistema, use diagramas de pacotes (veja Captulo 7) que mostram as principais partes do sistema e suas interdependncias. Para cada pacote, voc pode, ento, desenhar um diagrama de classes. Quando vocdesenha um diagrama de classes neste contexto, assuma uma perspectiva de especificao. E importante esconder implementaes neste tipo de trabalho. Voc deve tambm desenhar diagramas de interao para as interaes-chaves do pacote. Use padres (veja pgina 44) para descrever as idias importantes do sistema que

aparecem em mltiplos lugares. Padres ajudam a explicar por que o seu projeto se apresenta da maneira como . Tambm til descrever alternativas de projetos que voc rejeitou e porqu. Sempre acabo esquecendo por que este tipo de deciso foi tomada. Ao seguir estas orientaes, voc obtm resultados mais rapidamente. Uma parte importante da comunicao est em salientar as coisas importantes a serem ditas. Voc no precisa mostrar cada caracterstica de cada classe; voc deve, ao contrrio,mostrar os detalhes importantes. Um documento breve comunica muito melhor que um longo; a arte est em saber o que deixar de fora. Aprendendo 00 Muitas pessoas falam da curva de aprendizado associada com 00 - a maldita troca deparadigma. Em alguns aspectos, a mudana para 00 fcil. Em outros aspectos, h um nmero de obstculos em relao ao trabalho com objetos, particularmente a suautilizao da melhor maneira possvel.

UML ESSENCIAL: UM BREVE GUIA PARA A LINGUAGEM-PADRO DE MODELAGEM DE OBJETOS

.

.

.

No o caso se difcil aprender como programar uma linguagem 00. O problema que leva tempo para aprender a explorar as vantagens que as linguagens orientadas a objetos fornecem. Tom Hadfield diz bem: Linguagens de Objeto permitem vantagem , no as fornecem. Para utilizar estas vantagens, voc tem que fazer a maldita troca de paradigma. (Assegure-se de estar sentado nesta hora!) As tcnicas de UML foram at certo ponto projetadas para ajudar as pessoas a fazer boa 00, mas tcnicas diferentes tm vantagens diferentes.

Uma das tcnicas mais valiosas para o aprendizado de 00 so os cartes CRC (veja pgina 78), que no so parte da UML, embora eles possam e devam ser usados comela. Eles foram projetados primeiramente para ensinar as pessoas como trabalhar com objetos. Como tal, os cartes CRC so deliberadamente diferentes das tcnicas de projeto tradicionais. Suas nfases nas responsabilidades e suas ausncias de notaes complexas tornam os cartes CRC particularmente valiosos. Diagramas de interao (veja Captulo 5) so muito teis porque eles tornam a estrutura da mensagem bastante explcita e, portanto, so teis para salientar projetos muito centralizados, nos quais um objeto faz todo trabalho. Diagramas de classes (veja Captulos 4 e 6), usados para ilustrar modelos de classe, so bons e ruins para o aprendizado de objetos. Modelos de classe so bastante semelhantes a modelos de dados; muitos dos princpios que fazem um bom modelo de dados tambm fazem um bom modelo de classe. O maior problema na utilizao de diagrama de classes que fcil desenvolver um modelo de classe que seja orientado a dados, em vez de ser orientado responsabilidade. o conceito de padres (veja pgina 44) tornou-se vital para o aprendizado de 00 porque a utilizao de padres faz com que voc se concentre em bons projetos 00 e aprenda seguindo um exemplo. Uma vez que voc tiver aprendido tcnicas de modelagem bsicas, tais como simples diagrama de classes e diagramas de interao, est na hora de comear a observar os padres. Outra tcnica importante o desenvolvimento iterativo (veja Captulo 2). Esta tcnica no o ajuda a aprender 00 diretamente, mas ela a chave

para uma explorao efetiva da 00. Se voc faz desenvolvimento iterativo desde o comeo, voc aprender, no contexto, o tipo certo de processo e comear a ver porque os projetistas sugerem que as coisas sejam feitas do modo como eles o fazem.

Quando voc comea a utilizar uma tcnica, tende a faz-lo seguindo pelo livro. Minha recomendao comear com as notaes simples as quais abordo aqui, particularmente com diagrama de classes. medida que se sente familiarizado, vocpode utilizar idias mais avanadas de acordo com as suas necessidades. Voc tambm pode achar que quer estender a metodologia.

INTRODUO Comunicao com Especialistas de Domnio Um dos maiores desafios no desenvolvimento o da construq do sistema certo - um sistema que preencha as necessidades dos usurios a um preo razovel. Isso se torna mais difcil porque, com o nosso jargo, temos que nos comunicar com nossos usurios que tm o seu prprio, e ainda mais secreto, jargo. (Fiz muito trabalho na rea de sade, e nesta rea o jargo nem mesmo em ingls!). Atingir boa comunicao, com boa compreenso do mundo dos usurios, a chave para desenvolver um bom software. A tcnica bvia a ser utilizada para fazer isso so casos de uso (veja Captulo 3). Um caso de uso um instantneo de um aspecto do nosso sistema. A soma de todos esses casos de uso a imagem externa do nosso sistema, que segue um longo caminho para explicar o que o sistema far. Uma boa coleo de casos de uso central para compreender o que seu usurio quer. Esses casos tambm apresentam um bom veculo para planejamento de projeto, porque eles controlam o desenvolvimento iterativo que em si s uma tcnica valiosa, uma vez que fornece umfeedback regular para os usurios sobre o que est acontecendo com o software. Embora casos de uso ajudem na comunicao sobre coisas superficiais, tambm crucial olhar as coisas mais profundas. Isso envolve aprender como os seus especialistas do domnio entendem o mundo deles. Diagramas de classes (veja Captulos 4 e 6) podem ser extremamente valiosos aqui, desde que voc os desenhe a partir de uma perspectiva conceitual. Em outras palavras, voc deve tratar cada classe como um conceito na mente de usurio. Os diagramas de classes que voc desenha no so, ento, diagramas de dados ou de classes, mas diagramas da linguagem de seus usurios. Considero diagramas de atividades (veja Captulo 9) muito teis em casos nos quais os processos de workflow so uma parte importante do mundo dos usurios. Uma vez que suportam processos paralelos, os diagramas de atividades podem ajudar a nos livrar de seqncias desnecessrias de processos. O modo de elaborar estes diagramas desenfatiza as ligaes com classes, o que pode ser, mais tarde, um problema no projeto, mas torna-se uma vantagem durante este estgio mais conceitual do processo de desenvolvimento. Procurando Mais Informao Este livro no uma referncia completa e definitiva para UML, muito menos para anlise e projeto 00. 1-l muito material publicado e muitas coisas que valem a pena ser lidas. A medida que discutir tpicos individuais, mencionarei outros livros aos quais voc deve recorrer para informaes mais profundas a respeito das idias de UML e de OOA&D de modo geral. Certamente, o seu primeiro passo alm deste livro sobre UML deve ser os livros dos trs amigos.

UML ESSENCIAL: UM BREVE GUIA PARA A LINGUAGEM-PADRO DE MODELAGEM DE OBJETOS \27 7

Grady Booch liderou o trabalho no guia do usurio (Booch, Rumbaugh e Jacobson, 1999). Este livro tutorial explora maneiras nas quais voc pode usar UML para fazer vrias tarefas de projeto. Jim Rumbaugh liderou o trabalho no manual de referncia (Rumbaugh, Jacobson e Booch 1999), frequentemente acho esta referncia detalhada da UML muito til. Ivar Jacobson liderou o trabalho no livro que descreve um processo que trabalha com UML (Jacobson, Booch e Rumbaugh, 1999). Abordarei mais sobre questes de processo no Captulo 2. Certamente, os livros dos trs amigos no so os nicos que voc deve ler sobre boa OOA&D. Minha lista de livros recomendados muda com freqUncia, d uma olhada naminha hornepage para maiores detalhes. Se voc novo na rea de objetos, recomendo o meu livro introdutrio favorito atual,Larman (1998). O autor tem uma forte introduo dirigida a responsabilidades para projeto, o que vale a pena ser seguido. Se voc quiser saber mais sobre objetos de um ponto de vista conceitual; Martin e Odel (1998) encontra-se agora disponvel em uma edio UML. Os desenvolvedores de tempo real devem obter uma cpia do livro de Douglass (1998). Sugiro tambm que voc leia livros sobre padres, para material que o levar alm do conhecimento bsico. Agora que a guerra dos mtodos acabou, penso que a maior parte do material interessante sobre anlise e projeto que aparecer ser sobre padres. Inevitavelmente, entretanto, as pessoas vo propor novas tcnicas deanlise e projeto, e provvel que elas falaro sobre como estas tcnicas podem ser utilizadas com UML. Este outro benefcio: UML encoraja as pessoas a acrescentarem novas tcnicas sem duplicar os trabalhos que outras j tenham feito.

2 Um Esboo de Processo de Desenvolvimento UML uma linguagem de modelagem, no uma metodologia. UML no tem noes do processo, que uma parte importante de uma metodologia. O ttulo deste livro UML Essencial, portanto eu poderia seguramente ignorar o processo. Entretanto, no acredito que as tcnicas de modelagem tenham algum sentido sem que se saiba como elas se encaixam no processo. E por isso que eu decidi discutir primeiro o processo, ento voc pode ver como um desenvolvimento orientado a objeto funciona. Eu o chamo esboo de processo porque em vez de tentar entrar em muitos detalhes, ofereo apenas o suficiente para dar uma noo damaneira tpica na qual um projeto que usa estas tcnicas funciona. Os trs amigos desenvolveram um processo unificado chamado Rational Unfied Process (anteriormante chamado Objectory). Este processo descrito no livro de processo dos amigos (Jacobson, Booch e Rumbaugh, 1999). medida que discutir o esboo de projeto, utilizarei a terminologia e o esboo do esquema do Rational Unified Process. (Tenho de usar algo, e este esquema me parece bom). Entretanto, no tentei descrever o Rational Unified Process; isto est alm do escopo deste livro. Ao invs disto, descrevo um processo leve e sem formalidade que consistente com o processo da Rational. Para maiores detalhes sobre o Rational Unified Process, voc deve recorrer ao livro de processo dos trs amigos ou dar uma olhada na viso geral de Kruchten (1999). Embora o Rational Unified Process contenha detalhes sobre que tipos de modelo devem ser desenvolvidos nos vrios estgios do processo, no entrarei em tais detalhes. Tambm no especificarei tarefas a serem realizadas, resultados a serem entregues e papis a serem desempenhados. Minha terminologia mais solta do quea utilizada no Rational Unified Process - este o preo que se paga por uma leve descrio. Qualquer que seja a discusso do processo, no esquea que voc pode utilizar

qualquer processo com UML. UML independente de processo. Voc deve

30 UM ESBOO DE PROCESSO DE DESENVOLVIMLTO escolher algo que seja adequado ao seu tipo de projeto. Qualquer que seja o processo que utilize, voc pode usar UML para registrar as decises de anlise e de projeto resultantes. Na verdade, no acredito que possa existir um nico processo para o desenvolvimento de software. Vrios fatores associados com o desenvolvimento de software levam a vrios tipos de processos. Estes fatores incluem o tipo de software que voc est desenvolvendo (tempo real, sistema de informaes, produto de desktop), a escala (desenvolvedor nico, equipe pequena, equipe com mais de 100 membros) e assim por diante. Acredito que equipes devem criar seus prprios processos, utilizando processos publicados como orientao e no como padres a serem seguidos. Viso Geral do Processo A Figura 2-1 mostra a viso de alto nvel do processo de desenvolvimento. Construo Concepo Elaborao 1 2 Transio Figura 2-1: Esboo do Processo de Desenvolvimento Este processo um processo de desenvolvimento iterativo e incremental, no qual o software no implementado em um instante no fim do projeto, mas , ao contrrio, desenvolvido e implementado em partes. A fase de construo consiste de vrias iteraes, nas quais cada iterao constri software de qualidade de produo, testado e integrado, que satisfaz um subconjunto de requisitos de projeto. A entrega pode ser externa, para usurios iniciais, ou puramente interna. Cada iterao contmtodas as fases usuais do ciclo de vida da anlise, do projeto, da implementao e do teste. Teoricamente, voc pode comear pelo incio: escolha alguma funcionalidade e construa-a, escolha outra funcionalidade, e assim por diante. Entretanto, vale a pena passar algum tempo planejando. As duas primeiras fases so a concepo e a elaborao. Durante a concepo, voc estabelece a lgica do domnio da aplicao para o projeto e decide o escopo do projeto. E aqui que voc obtm o comprometimento do patrocinador do projeto para seguir adiante. Na elaborao, voc coleta requisitos mais detalhados, faz uma anlise e um projeto de alto nvel para estabelecer uma arquitetura bsica, e cria um plano para a construo do sistema. Mesmo com este tipo de processo iterativo, algum trabalho tem que ser deixado paraser feito no fim, na fase de transio. Este trabalho pode incluir teste beta, ajuste de performance e treinamento de usurio.

UML ESSENCIAL: UM BREVE GUIA PARA A LINGUAGEM-PADRO DE MODELAGEM DE OBJETOS 37 Os projetos variam de acordo com o volume de formalidade que eles tm. Projetos demuita formalidade tm muitos documentos formais a serem entregues, reunies formais, encerramentos formais. Projetos de pouca formalidade podem ter uma fase de concepo que consiste de um bate-papo de uma hora com o patrocinador do projeto e um plano que cabe em uma folha de papel. Naturalmente, quanto maior o projeto, mais formalidade voc precisa. O fundamental de cada fase ainda acontece, mas de formas bem diferentes. Procuro manter o mnimo de formalidade possvel, e a minha discusso reflete isso. Existem vrios processos de muita formalidade a serem escolhidos em outras partes.

Mostrei iteraes na fase de construo, mas no nas outras fases. Na verdade, voc

pode ter iteraes em todas as fases, e sempre uma boa idia fazer isso em um ciclo maior. A construo a fase-chave para iterao. Esta a viso de alto nvel. Agora, aprofundaremos os detalhes a fim de ter informao suficiente para ver onde as tcnicas discutidas mais adiante neste livro se encaixam no esquema maior. Fazendo isso, abordarei um pouco estas tcnicas e quando us-las. Voc pode considerar isso um pouco confuso se voc ainda no estiver familiarizado com as tcnicas. Se este for o caso, pule estas partes e volte a elas mais tarde. Concepo A concepo pode ter vrias formas. Para alguns projetos, um bate-papo na hora do caf: Vamos colocar nosso catlogo de servios na rede. Para projetos maiores, pode ser um estudo da viabilidade completo, o que leva meses. Durante a concepo, voc elabora o plano de negcio do projeto - a grosso modo quanto custar e o quanto ter de retorno. Voc tambm pode necessitar ter uma idia do escopo do projeto. Voc pode necessitar fazer alguma anlise inicial para ter uma idia do tamanho do projeto. No tenho a tendncia de fazer a concepo muito importante. A concepo deve serum trabalho de poucos dias para considerar se vale a pena fazer uma investigao mais profunda de alguns meses durante a elaborao (veja a prxima seo). A esta altura, o patrocinador do projeto concorda apenas na realizao de uma sria anlise do projeto. Elaborao Ento, voc tem o v em frente para iniciar o projeto. Neste estgio, voc tem tipicamente, somente uma vaga idia dos requisitos. Por exemplo, voc pode ser capaz de dizer: Construiremos um sistema de prxima gera ao de suporte ao consumidor para a Watts Galore Utility Company. Pretendemos usar tecnologia orientada a objetos para construir um sistema mais flexvel que mais ori

E UM IiSBOO DE fROCESSo DE DESENVOLVIMENTO entado ao consumidor - especificamente, uni sistema que suportard o faturamento integrado do cliente. Evidentemente, nosso documento de requisitos ser mais extenso do que isso, mas na verdade, ele no pode dizer muito mais. A esta altura, voc quer ter uma melhor compreenso do problema. O que que voc realmente ir construir? Como voc ir constru-lo? Quando decidir quais itens examinar nesta fase, voc precisa levar em considerao, acima de tudo, os riscos do seu projeto. Que coisas poderiam descarrilh-lo? Quanto maior o risco, mais ateno voc tem que dar a ele. Na minha experincia, os riscos podem ser utilmente classificados em quatro categorias: 1. Riscos de requisitos. Quais so os requisitos do sistema? O grande perigo voc construir um outro sistema, um sistema que no faz o que o cliente necessita. 2. Riscos tecnolgicos. Quais so os riscos tecnolgicos que voc tem que enfrentar? Voc est selecionando a tecnologia que realmente far o servio por voc? As vrias partes se encaixaro? 3. Riscos de habilidades. Voc pode encontrar o pessoal e especialistas de que necessita? 4. Riscos polticos. Existem foras polticas que podem interferir e afetar seriamente o seu projeto? O seu caso pode ter mais riscos, mas os riscos que se encaixam nestas quatros categorias esto quase sempre presentes.

Lidando com Riscos de Requisitos Requisitos so importantes e so onde as tcnicas de LJML podem ser postas mais obviamente em uso. O ponto inicial so os casos de uso. Casos de uso dirigem todo oprocesso de desenvolvimento. Abordarei em detalhes casos de uso no Captulo 3; aqui simplesmente farei uma breve descrio do que so casos de uso. Um caso de uso uma interao tpica que o usurio tem com o sistema a fim de atingir um objetivo. Imagine um processador de palavras tpico. Um caso de uso seriafaa a verificao ortogrfica; outro caso seria crie um ndice para o documento. O elemento-chave para casos de uso que cada um indica uma funo que o usuriopode entender e que tem valor para o usurio. Conversando sobre casos de uso, um desenvolvedor pode responder com detalhes especficos. Por exemplo: Levarei dois meses para fazer afuno de ndice para voc. Tambm tenho um caso de uso para dar suporte verificao gramatical; acredito

UML ESSENCIAL: UM BREVE GUIA PARA A LINGUAGEM-PADRO DE MODELAGEM DE OBJETOS que isso levar trs meses. Temos apenas trs meses at a data do lanainento - o que voc prefere? Casos de uso fornecem a base da comunicao entre clientes e desenvolvedores no planejamento do projeto. Uma das coisas mais importantes a ser feita na fase de elaborao descobrir todos os casos de uso potenciais para o sistema que voc est construindo. Na prtica, certamente, voc no descobrir todos. Entretanto, voc quer descobrir a maioria, particularmente os mais importantes e os mais arriscados. por esta razo que, durante a fase de elaborao, voc deve planejar entrevistas com usurios a fim de identificar casos de uso. Casos de uso no precisam ser detalhados. Acredito, geralmente, que de um a trs pargrafos de texto descritivo sejam suficientes. Este texto deve ser suficientemente especfico para que os usurios entendam a idia bsica e para que os desenvolvedores tenham uma viso mais ampla do que est escondido por dentro. No entanto, casos de uso no so tudo. Outra tarefa importante esboar um esqueleto do modelo conceitual do domnio. Na mente de um ou mais usurios est a idia de como o negcio funciona. Por exemplo: Nossos clientes tm muitos endereos, efornecemos diversos servios para estes endereos. No momento, um cliente recebe uma fatura para todos os servios em um dado endereo. Queremos que este cliente seja cobrado por todos os servios emtodos os endereos. Chamamos isso defaturamento consolidado. Esta passagem contm as palavras cliente, endereo e servio. O que estes termos significam? Como eles se encaixam? Um modelo de domnio conceitual comea a responder estas questes, e ao mesmo tempo d um embasamento para omodelo de objetos que ser utilizado para representar os objetos do sistema mais adiante no processo. Uso o termo modelo de domnio para descrever qualquer modelo, cujo sujeito primrio seja o mundo que o sistema de computao est suportando, qualquer que seja o estado do processo de desenvolvimento em que se esteja. Observe que o processo unificado da Rational define o termo modelo de domnio mais estreitamente; veja Jacobson, Booch e Rumbaugh (1999) para detalhes. O meu uso o mesmo que a maioria das pessoas que conheo na comunidade de objeto utiliza. Considero duas tcnicas de UML valiosas na construo de modelos de domnio conceitual. A tcnica principal que uso para os modelos de domnio o diagrama de classes, feito a partir de uma perspectiva conceitual (veja Captulo 4). Voc pode utilizar estesdiagramas para esquematizar os conceitos que os especialistas em negcios usam

quando eles pensam sobre o negcio e para esquematizar as maneiras como estes especialistas ligam os conceitos entre si. De vrias maneiras, os diagramas de classes formam a definio de um vocabulrio rigoroso para falar sobre o domnio. Se o domnio tambm tem um forte elemento de workflow, gosto de descrevlo com diagramas de atividades (veja Captulo 9). O aspecto-chave de diagramas

UM ESBOO DE PROCESSO DE DESENVOIVIMENTO de atividades que eles encorajam a procura de processos paralelos, que importante na eliminao de seqncias desnecessrias em processos de negcio. Algumas pessoas gostam de usar diagramas de interao (veja Captulo 5) para explorar como vrios papis interagem no negcio. Elas consideram mais fcil obter uma compreenso do processo, pensando ao mesmo tempo em trabalhadores e atividades. Prefiro utilizar diagramas de atividades para estabelecer primeiro o que precisa ser feito e determinar mais tarde quem faz o qu. Modelagem de domnio pode ser um grande apoio para os casos de uso. Quando coleto casos de uso, gosto de trazer um especialista no domnio e explorar como estapessoa pensa sobre o negcio, com auxlio de diagramas conceituais de classe e diagramas de atividades. Nesta situao, uso notao mnima, no me preocupo com rigor e preciso e fao vrias anotaes informativas no diagrama. No tento captar cada detalhe. Ao contrrio, focalizo em aspectos importantes e em reas que implicam risco. Desenho muitos diagramas desconectados sem me preocupar com a consistncia e as inter-relaes entre os diagramas. Considero que esse processo pode rapidamente fornecer muita compreenso. Munidodesta compreenso, acredito que posso identificar mais facilmente os casos de uso para os vrios usurios. Depois de cobrir a maior parte das reas relevantes, gosto de consolidar os vrios diagramas em um nico modelo consistente de domnio. Para tanto, utilizo um ou dois especialistas de domnio que gostam de se aprofundar na modelagem. Mantenho a perspectiva conceitual, mas, ao mesmo tempo, me torno mais rigoroso. Este modelo pode, ento, agir como um ponto inicial para construo de classes na fase de construo. Se este modelo grande, uso pacotes para dividir o modelo em pedaos. Consolidarei as informaes dos diagramas de classes e de atividades e, talvez, desenharei alguns diagramas de estados para classes que tm ciclos de vida interessantes. Voc deve considerar este modelo inicial de domnio como um esqueleto, no como um modelo de alto nvel, O termo modelo de alto nvel implica na falta de muitos detalhes. J vi este erro ser cometido em vrias situaes, expresso como, por exemplo, No mostre atributos destes modelos. Os resultados so modelos sem substncia. E fcil ver por que os desenvolvedores ridicularizam tais esforos. Voc no pode, entretanto, utilizar um enfoque contrrio e construir um modelo detalhado. Se voc fizer isso, levar muito tempo e voc morrer de paralisia de andlise, O truque encontrar os detalhes importantes e se concentrar neles. A maioria dos detalhes ser tratada durante o desenvolvimento iterativo. por isso que prefiro pensar neste modelo como um esqueleto. O esqueleto a base para o resto do modelo. Ele detalhado, mas somente uma parte da histria. Naturalmente, isso no lhe diz como diferenciar a gua do vinho; esta a arte do analista experiente, eu ainda no consegui elaborar como definir isso! Modelagem de domnio tambm dirigida por casos de uso, medida que eles se tornam conhecidos. Quando casos de uso aparecem equipe de modelagem, deve-se analis-los para avaliar se eles contm algo que possa ter um forte impacto no modelo de domnio. Se este for o caso, eles devem explorar mais; caso contrrio, os casos de uso devem ser deixados de lado por enquanto.

UML ESSENCIAL: UM BREVE GUIA PARA A LINGUAGEM-PADRO DE MODELAGEM DE

OBJETOS A equipe que constri um modelo de domnio deveria ser um grupo pequeno (2 a 4 pessoas) que incluem desenvolvedores e especialistas do domnio. A menor equipe vivel seria um desenvolvedor e um especialista de domnio. A equipe deve trabalhar intensamente no perodo de elaborao at que o modelo esteja fechado. Durante este perodo, a liderana deve assegurar que a equipe no se emaranhe em detalhes nem opere em um nvel to alto que perca contato com a realidade. Uma vez que eles entendem o que esto fazendo, ficar trancado nos detalhes o maior perigo. Uma data de entrega inflexvel funciona bem como estmulo para total concentrao. Como parte da compreenso dos requisitos do sistema, voc deve construir um prottipo de todas as partes difceis dos casos de uso. A criao de prottipos uma tcnica valiosa para obter uma melhor compreenso de como situaes mais dinmicas funcionam. Uso prottipos sempre que me sinto desconfortvel sobre como uma parte de risco do sistema realmente funcionar. Construo prottipos suficientes para compreender bastante a fim de avaliar o risco e estimar o quanto de trabalho ser necessrio. Normalmente, no fao prottipos de todo o quadro; ao contrrio, uso o modelo de domnio completo para enfatizar reas que precisam de prototipao. Acredito que pessoas no familiarizadas com UML precisam criar mais prottipos. Isso as ajuda a se familiarizar com o modo pelo qual diagramas UML correspondem programao real. Quando voc utiliza um prottipo, no fique limitado ao ambiente no qual voc realmente desenvolver o sistema. Por exemplo, geralmente ganho muito dos prottipos de anlise em Snialtalk, mesmo quando estou construindo um sistema C++. Um dos elementos mais importantes no manejo de risco de requisitos obter acesso a uma especialidade de domnio. Falta de acesso a pessoas que, realmente, conhecem o domnio uma das causas mais ..omuns para que os projetos falhem. Vale a pena investir tempo e dinheiro considerveis para trazer para sua equipe pessoas, de fato, conheam o domnio - a qualidade do software ser diretamente proporcional ao seu contedo. Estas pessoas no precisam trabalhar tempo integral, elas devem ser abertas, ter bastante conhecimento prtico e estar disponveis para perguntas. Lidando com Riscos Tecnolgicos A coisa mais importante a fazer em relao a riscos tecnolgicos construir um prottipo que experimente as partes da tecnologia que voc est pensando em utilizar. Por exemplo, digamos que voc esteja utilizando C++ e um banco de dados relacional. Voc deve construir uma aplicao simples utilizando C++ e o banco de dados juntos. Experimente vrias ferramentas e veja quais funcionam melhor. Perca algum tempo para se sentir vontade com as ferramentas que voc utilizar. No esquea que os maiores riscos tecnolgicos so inerentes a como os componentes do projeto se encaixam. Voc pode conhecer bem C++ e pode conhecer tambm bancos de dados relacionais, mas utiliz-los juntos pode ser surpreen

UM ESBOO DE PROCESSO DE DESENVOLVIMENTO dentemente difcil. por isso que to importante obter todos os componentes que voc pretende utilizar e encaix-los nesta fase inicial do processo. Voc tambm deve tratar das decises de projeto arquitetnico durante este estgio.Estes assumem, geralmente, formas de idias sobre quais so os maiores componentes e como eles sero construdos. Isso particularmente importante se voc est considerando um sistema distribudo. Como parte deste exerccio, concentre-se em quaisquer reas que parecem

difceis de serem modificadas mais tarde. Tente fazer o seu projeto de modo que ele permita trocar elementos do projeto com relativa facilidade. Questione-se: O que acontecer se uma pea de tecnologia no funcionar? O que acontecer se no conseguirmos conectar as duas partes do quebra-cabea?

Qual a probabilidade de algo dar errado? O que faremos se isso acontecer? Como no caso do modelo do domnio, voc deve observar os casos de uso medida que eles apaream a fim de avaliar se contm algo que possa prejudicar o seu projeto. Se voc teme que eles possam conter uma bomba escondida, investigue mais detalhadamente. Durante este processo, voc utilizar tipicamente um nmero de tcnicas UML para esboar suas idias e documentar as coisas que voc experimentar. No tente ser amplo a esta altura; esboos breves so tudo o que voc precisa e, portanto, so tudo o que voc deve utilizar. Diagramas de classes (veja os Captulos 4 e 6) e diagramas de interao (veja o Captulo 5) so teis para mosfrar como os componentes se comi.micam. Diagramas de pacotes (veja o Captulo 7) podem mostrar uma figura de alto nvel dos componentes, neste estgio. Diagramas de utilizao (veja o Captulo 10) podem dar uma viso geral de como as peas so distribudas. Lidando com Riscos de Especializao Freqentemente, vou a conferncias e assisto a palestras sobre estudos de caso ministradas por pessoas que recm terminaram um projeto orientado a objetos. Elas, geralmente, respondem a pergunta: Quais foram seus maiores erros? com respostas que, normalmente, incluem: Deveramos ter tido mais treinamento. Sempre me surpreendo como empresas iniciam importantes projetos 00 com pouca experincia e sem considerar como obter mais experincia. As pessoas se preocupam com custos de treinamentos, mas eles pagam cada centavo medida que o projeto se estende. Treinamento um modo de evitar erros, porque os instrutores j cometeram aqueles erros. Errar toma tempo, e tempo custa dinheiro. Ento, voc paga de qualquer maneira, mas a falta de treinamento faz com que o projeto se estenda. No sou um grande f de cursos de treinamentos formais. Ensinei e projetei muitos deles. Continuo no convencido de que eles sejam eficazes no ensinamento de habilidades orientadas a objetos. Eles do s pessoas uma viso geral do que

UML ESSENCIAL: UM BREVE GUIA PARA A LINGUAGEM-PADRO DE MODELAGEM DE OBJETOS elas devem saber, mas realmente no passam as habilidades essenciais necessrias para fazer um projeto srio. Um curto curso de treinamento pode ser til, mas apenas o incio. Se voc fizer um curto curso de treinamento, preste muita ateno no instrutor. Vale a pena pagar muito mais por algum com bastante conhecimento e que seja esfuziante, porque voc aprender muito mais durante o processo. Alm disso, faa oseu treinamento em pequenas pores, medida do necessrio (just in time). Se voc no aplicar imediatamente o que aprendeu em um curso de treinamento, voc esquecer. A melhor maneira de obter especializao 00 por consultoria, na qual voc tem um desenvolvedor especializado trabalhando no seu projeto por um longo perodo de tempo. O consultor mostra como fazer as coisas, observa o que voc faz, d dicas e um pouco de treinamento. Um consultor trabalhar com os detalhes especficos do seu projeto e saber que tipode conhecimento deve utilizar e quando. Nos estgios iniciais, o consultor um membro da equipe, ajudando a encontrar uma soluo. A medida que o tempo passa,voc se torna mais capaz, e o consultor passa mais a revisar do que propriamente

fazer algo. Meu objetivo como consultor me tornar desnecessrio. Voc pode encontrar consultores para reas especficas ou para todo o projeto. Os consultores podem trabalhar meio-turno ou tempo integral. Muitos consultores gostam de trabalhar uma semana de cada ms em cada projeto; outros consideram isso muito pouco. Procure um consultor com conhecimento e que tenha a habilidade de transmitir este conhecimento. O seu consultor pode ser o fator mais importante para o sucesso do seu projeto; vale a pena pagar pela qualidade. Se voc no puder conseguir um consultor, faa uma reviso no projeto a cada dois meses. Neste tipo de estrutura, um consultor experiente pode passar alguns dias revisando vrios aspectos do seu projeto. Durante este tempo, o revisor pode salientar vrias reas que esto preocupando, sugerir idias adicionais e esquematizar quaisquer tcnicas teis que a equipe possa estar ignorando. Embora isso no lhe d todas as vantagens de um bom consultor, pode ser til para identificar aspectos-chave que voc pode fazer melhor. Voc tambm pode enriquecer suas habilidades atravs da leitura. Tente ler um bom livro tcnico, no mnimo, uma vez a cada dois meses. Melhor ainda, leia- o como parte de um grupo de leitura. Encontre algumas pessoas que queiram ler o mesmo livro. Combinem de ler alguns captulos a cada semana, e passem uma ou duas horasdiscutindo os captulos lidos. Fazendo isso, voc pode obter um conhecimento maior do que lendo sozinho. Se voc for o gerente, incentive este tipo de atividade. Consigauma sala para o grupo; d ao seu pessoal dinheiro para comprar material tcnico; determine tempo para o grupo do livro. A comunidade de padres de objeto descobriu que os grupos de leitura tm um grande valor. Vrios grupos de leitura de padres surgiram. Consulte a hone page depadres (http://www.hillside.net/patterns) para maiores informaes sohre estes grupos. A medida que voc trabalhar na elaborao, preste ateno s reas nas quais voc no tem muita experincia nem habilidade. Planeje obter a experincia no momento em que voc precisar dela.

UM EsBoo DE PROCESSO DE DESENVOLVIMENTO

Lidando com Riscos Polticos

No POSSO oferecer conselhos srios nesta rea, porque no sou um poltico corporativo experiente. Recomendo que voc encontre algum habilitado para lhe aconselhar.

Quando Termina a Elaborao?

Meu princpio bsico que a elaborao leve em torno de um quinto do tempo total do projeto. Dois fatores so indicadores-chave de que a elaborao foi completada.

Os desenvolvedores podem se sentir vontade dando estimativas, em pessoas/semana de trabalho, de quanto tempo levar para construir cada caso de uso. Todos os riscos significativos foram identificados, e os maiores so compreendidos at o ponto que voc sabe como pretende lidar com eles.

Planejando_a Fase de Construo

H vrias maneiras de planejar um projeto iterativo. importante que voc desenvolva um plano de modo a estar ciente do progresso e para indicar o progresso para a equipe. O mtodo para o planejamento que uso baseado em tcnicas do Extrenie Programming Explained (Beck 2000).

A essncia da construo de um plano envolve estabelecer uma srie de iteraes para construo e definir a funcionalidade a entregar em cada iterao. Algumas pessoas gostam de utilizar pequenos casos de uso e completar um deles dentro de uma iterao; outras gostam de usar casos de uso maiores, fazendo algum cenrio em uma iterao e outros mais tarde. O processo bsico o mesmo. Eu o descrevereicom casos de uso menores. Durante o planejamento, gosto de considerar dois grupos de pessoas: clientes e desenvolvedores. Clientes so as pessoas que utilizaro o sistema no caso de um desenvolvimento interno. Para um sistema ser vendido em prateleira, o pessoal de marketing, geralmente, representa o cliente. O aspecto-chave que os clientes so as pessoas que podem avaliar o valor de negcio de um caso de uso sendo implementado. Desenvolvedores so as pessoas que construiro o sistema. Eles devem entender os custos e o trabalho envolvido na construo de um caso de uso. Portanto, devem estar familiarizados com o ambiente do desenvolvimento. Geralmente, a gerncia no pode desempenhar esta funo, porque necessria experincia tcnica atualizada para faz-lo. O primeiro passo categorizar os casos de uso. Fao isso de duas maneiras. lrimeiro, o cliente divide os casos de uso, de acordo com o valor do seu negcio, em trs pilhas de prioridade: alta, mdia e baixa. (Observe que considerada m conduta colocar tudo na pilha alta). Depois, o cliente registra os contedos de cadacategoria.

1 UML ESSENCIAL: UM BREVE GUIA PARA A LINGUAGEM-PADRO DE MODELAGEM DE OBJETOS Os desenvolvedores dividem, ento, os casos de uso de acordo com o risco de desenvolvimento. Por exemplo, alto risco seria usado para algo que fosse muito difcil de ser feito, poderia ter um grande impacto no projeto do sistema, ou simplesmente mal compreendido. Depois que isso feito, os desenvolvedores devem estimar o tempo que cada caso de uso necessitar, em pessoas/semana. Na realizao desta estimativa, considere que voc necessita fazer anlise, projeto, codificao, teste de unidade, integrao e documentao. Tambm admita que voc tenha um desenvolvedor altamente comprometido, sem outras tarefas ou distraes (acrescentaremos um fator de carga mais tarde). Uma vez que suas estimativas estejam prontas, voc pode avaliar se est pronto para fazer o plano. Observe os casos de uso de alto risco. Se muito tempo do projeto estiver vinculado a estes casos de uso, voc deve fazer mais elaborao. O prximo passo determinar a durao de suas iteraes. Voc quer iteraes de durao fixa para todo o projeto, de modo que possa ter um ritmo regular para o resultado de cada iterao. Uma iterao deve ser longa o suficiente, para voc fazer um punhado de casos de uso. Para Smalltalk, isso pode ser umas duas ou trs semanas; para C++, pode ser algo como seis ou oito semanas. Agora, voc pode considerar o quanto de trabalho voc tem para cada iterao. Observe que voc ter feito estas estimativas, considerando um desenvolvedor que no se distraia. Obviamente, isso nunca o caso, portanto levo em conta o coeficiente de carga que a diferena entre o tempo ideal e o tempo real. Voc deve medir este fator comparando estimativas com os fatos reais. Agora, voc pode calcular com que rapidez pode prosseguir, o que chamo de velocidade do projeto. Isso o quanto de desenvolvimento voc pode fazer em uma iterao. Voc calcula isso tomando o seu nmero de desenvolvedores, multiplicando pela durao da iterao e, ento, dividindo o resultado pelo coeficiente

de carga. Por exemplo, dados 8 desenvolvedores, uma iterao de trs semanas de durao, e um coeficiente de carga de 2, voc teria um ideal de 12 semanas de desenvolvimento (8*3*1/2) de trabalho por iterao. Some o tempo para todos os casos de uso, divida-o pelo trabalho por iterao, e acrescente um para sorte. O resultado a sua primeira estimativa de quantas iteraes voc necessitar para o seu projeto. O prximo passo assinalar casos de uso para iteraes. Os casos de uso que tm alta prioridade e/ou riscos de desenvolviment devem ser tratados na fase inicial. No adie o risco at o final! Voc poder neces sitar dividir casos de uso grandes e, provavelmente, revisar as estimativas dE casos de uso devido ordem em que voc estiver fazendo as coisas. Voc pode tei menos trabalho para fazer do que o possvel na iterao, mas no deve programai mais do que o seu esforo permitir. Para a transio, determine de 10% a 35% do tempo de construo para ajus te e empacotamento para a entrega final (use um nmero alto se voc foi inexperiente com ajuste e empacotamento no seu ambiente atual). Adicione, ento, um fator de contingncia: de 10% a 20% do tempo de cons truo, dependendo de quo arriscadas as coisas possam parecer. Acrescente este fator no final da fase de transio. Voc deve planejar a entrega sem usar temp

UM EsBoo DE PROCESSO DE DESENVOLVIMENTO de contingncia - ou seja, sua data-alvo interna - mas comprometa-se em entregar ao final do tempo de contingncia. Depois de seguir estas orientaes, voc deve ter um plano de implementao que mostra os casos de uso que sero feitos durante cada iterao. Este plano simboliza comprometimento entre os desenvolvedores e os usurios. Este plano no imutvel- na verdade, todos devem esperar que o plano mude medida que o projeto progride. Uma vez que existe um compromisso entre os desenvolvedores e os usurios, as mudanas devem ser feitas de comum acordo. Como voc pode ver pelo que est sendo exposto, casos de uso servem como base para o planejamento do projeto, e por isso que UML pe muita nfase neles. Construo A construo elabora o sistema em uma srie de iteraes. Cada iterao um miniprojeto. Voc faz anlise, projeto, codificao, teste e integrao para os casos de uso designados para cada iterao. Voc termina a iterao com uma demonstrao para o usurio e realiza testes de sistema para confirmar que os casosde uso foram construdos corretamente. O objetivo deste processo reduzir o risco. O risco, geralmente, aparece porque casos difceis so deixados para o fim do projeto. Vejo projetos onde os testes e a integrao so deixados para o final. Teste e integrao so tarefas extensas, e elas sempre demoram mais do que as pessoas imaginam. Deixadas para o fim, elas so difceis e desanimadoras. por isso que sempre encorajo os meus clientes a desenvolverem software de autoteste (veja box). As iteraes dentro da construo so tanto incrementais quanto iterativas. As iteraes so incrernen tais na funo. Cada iterao construda sobre os casos de uso desenvolvidos nas iteraes prvias. As iteraes so iterativas em termos da base de cdigo. Cada iterao implicar que alguns trechos de cdigo existentes sejam reescritos, para os tornar mais flexveis. Refatorao (veja box) uma tcnica extremamente til na iterao de cdigo. uma boa idia observar a quantidade de cdigo que jogada fora em cada iterao. Desconfie se menos de 10% do cdigo anterior descartado a cada vez. A integrao deve ser um processo contnuo. Para iniciantes, a integrao total parte do final de cada iterao. Entretanto, a integrao pode e deve ocorrer com mais freqncia. Uma boa prtica fazer uma construo completa e uma

integrao a cada dia. Fazendo isso diariamente, as coisas no saem tanto de sincronia que se tornam um problema integr-las mais tarde. Um desenvolvedor deve integrar depois de cada trabalho significativo. Alm disso, o conjunto completo de testes de unidade deve ser rodado a cada integrao, de forma a assegurar teste de regresso completo.

UML ESSENCIAL: UM BREVE GUIA PARA A LINGUAGEM-PADRO DE MODELAGEM DE OEJETOS Software de Autoteste Quanto mais velho eu fico, mais agressivo me torno em relao a testes. Teste deveria ser um processo contnuo. Nenhum cdigo deveria ser escrito at que voc saiba como test-lo. Uma vez que voc escreva um cdigo, escreva os testes para ele. At que os testes funcionem, voc no pode anunciar que terminou de escrever o cdigo. Cdigo de teste, uma vez escrito, deve ser guardado para sempre. Estabelea o seu cdigo de teste de modo que possa executar um teste com uma simples linha de comando ou com um boto GUI. O cdigo deve responder com 0K ou com uma listade falhas. Todos os testes devem tambm verificar os seus prprios resultados. No h nada que desperdice mais tempo do que ter um teste emissor de nmero, e voc ter que pesquisar o significado do mesmo. Fao testes funcionais e de unidade. Os testes de unidade devem ser escritos pelos desenvolvedores, organizados em pacotes e codificados para testar as interfaces de todas as classes. Acredito que escrever testes de unidade, realmente, aumenta a velocidade da minha programao. Testes funcionais ou testes de sistema devem ser desenvolvidos por uma pequena equipe separada, encarregada somente de fazer testes. Esta equipe deve ter uma viso de caixa preta do sistema e ter especial prazer em encontrar erros e falhas (bugs). (Bigodes sinistros e gargalhadas ttricas so opcionais mas desejveis). H um frarnework de cdigo aberto, simples mas poderoso, para testes de unidade: a famflia xUnit. Para detalhes, veja o link na minha homepage. Quando o Plano se Desintegra A nica coisa que voc pode saber com certeza sobre um plano que as coisas no vo acontecer de acordo com ele. O gerenciamento de um plano tem tudo a ver com a maneira como voc lida efetivamente com as mudanas. Uma caracterstica-chave para o desenvolvimento iterativo que ele congelado nasdatas - voc no pode deixar passar nenhuma data. Ao contrrio, casos de uso podem ser movidos para uma iterao posterior atravs de negociao Refatoraao Voc j se deparou com o princpio da entropia de software? Ele sugere que programas iniciam de uma maneira bem projetada, mas medida que novas poresde funcionalidade so agregadas, programas gradualmente perdem sua estrutura, transformando-se finalmente, numa maaroca de espaguete. Parte disso devido escala. Voc escreve um pequeno programa que executa bem um trabalho especfico. As pessoas pedem que voc aumente o

42 r UM EsBoo DE PROCESSO DE DESENVOLVIMENTO v ___________ programa, e ele se torna mais complexo. Mesmo que voc tente ficar de olho no projeto, isso ainda pode acontecer. Uma das razes por que a entropia do software ocorre que, quando voc adiciona uma nova funo ao programa, voc constri em cima de um programa existente, geralmente de uma maneira que o programa no estava projetado para suportar. Emtal situao, voc pode reprojetar o programa existente para melhor suportar as suasmudanas, ou pode trabalhar ao redor dessas mudanas nos seus acrscimos. Embora na teoria seja melhor reprojetar seu programa, isso geralmente resulta em

trabalho extra porque qualquer reescrita no seu programa existente introduzir novos erros e problemas. Lembre-se do velho provrbio de engenharia: Se no est quebrado, no conserte! Entretanto, se voc no reprojetar seu programa, os acrscimos sero mais complexos do que deveriam. Gradualmente, esta complexidade extra exigir uma dura pena. Portanto, h um custo/benefcio: O reprojeto causa um incmodo no curto prazo para um ganho no longo prazo. Sendo a presso de agenda como ela , a maioria das pessoas prefere adiar o inconveniente para o futuro. A refatorao um termo utilizado para descrever tcnicas que reduzem o inconveniente de curto prazo do reprojeto. Ao refatorar, voc no muda a funcionalidade do seu programa; ao invs disso, voc muda sua estrutura interna a fim de facilitar sua compreenso e seu manuseio. As mudanas da refatorao so, geralmente, em pequenos passos: renomear um mtodo, mover um campo de uma classe a outra, consolidar dois mtodos semelhantes em uma superclasse. Cada passo pequeno, no entanto, algumas horas gastas realizando estes pequenos passos podem trazer inmeros benefcios ao programa. A refatorao se toma mais fcil se voc seguir os seguintes princpios. No refatore e adicione funcionalidades a um programa ao mesmo tempo. Imponhauma separao clara entre eles quando voc trabalha. Voc pode passar de um para o outro em pequenos passos - por exemplo, meia-hora de refatorao, uma hora adicionando uma nova funo e meia-hora refatorando o cdigo que voc recm adicionou. Certifique-se que voc tem bons testes antes de iniciar a refatorao. De passos curtos, deliberados. Troque um campo de uma classe para outra. Una duas metodologias semelhantes em uma superclasse. Teste depois de cada passo. Isso pode parecer lento, mas evita depurao e, portanto, acelera o trabalho. Voc deve refatorar quando est acrescentando uma nova funo ou corrigindo um erro. No reserve um tempo especfico para refatorao; em vez disto, faa um pouco a cada dia. Para maiores informaes sobre refatorao, veja Fowler (1999). e de acordo com o cliente, O motivo disso manter um hbito regular de cumprir as datas e evitar o mau hbito de atrasar compromissos.

UIVIL ESSENCIAL: UM BREVE (.U1A PARA A LINGUAGEM-iADRO DE MODELAGEM DE OBJETOS Se voc se achar protelando muitos casos de uso, hora de refazer o plano, incluindouma re-estimativa dos nveis de esforos dos casos de uso. A essa altura, os desenvolvedores devem ter uma idia melhor de quanto tempo as coisas levaro. Voc deve esperar fazer uma alterao no plano a cada duas ou trs iteraes. Utilizando UML na Construo Todas as tcnicas de UML so teis neste estgio. Uma vez que farei referncias a tcnicas as quais no tive oportunidade de abordar ainda, sinta-se vontade para pular esta seo e retornar a ela mais tarde. Quando voc considera adicionar um dado caso de uso, voc, primeiro, o examina para determinar qual seu escopo. Um diagrama conceitual de classes (veja o Captulo 4) pode ser til para delinear alguns conceitos para o caso de uso e para vercomo estes conceitos se encaixam com o software que j foi construdo. A vantagem destas tcnicas a esta altura que elas podem ser utilizadas em conjunto com especialistas do domnio. Como Brad Kain diz: a anlise acontece somente quando o especialista de domnio est na sala (seno uma pseudoanlise). Para fazer a mudana para projeto, examine como as classes colaboraro para implementar a funcionalidade requerida para cada caso de uso. Considero que cartes CRC e diagramas de interao so teis na explorao destas interaes.

Estes vo expor responsabilidades e operaes que voc pode registrar no diagrama de classe. Trate estes desenhos como um esboo inicial e como uma ferramenta com a qual voc pode discutir os enfoques do projeto com seus colegas. Uma vez que voc se sinta vontade, est na hora de passar para cdigo. Inevitavelmente, o imperdovel cdigo vai expor fraquezas no projeto. No tenha medo de mudar o projeto em resposta a esta aprendizagem. Se a mudana for sria, use as notaes para discutir idias com seus colegas. Uma vez construdo o software, voc pode usar UML para ajudar a documentar o que fez. Acredito que diagramas UML so teis para obter-se uma compreenso geral de um sistema. Fazendo isso, entretanto, devo salientar que no acredito na produo de diagramas detalhados de todo o sistema. Citando Ward Cunningham (1996): Memos bem escritos e cuidadosamente selecionados podem facilmente substituir uma abran gente documentao de projeto tradicional. O priineiro raramente brilha, exceto em pontos isolados. Eleve estes pontos e esquea o resto. Acredito que uma documentao detalhada deveria ser gerada de um cdigo (como, por exemplo, JavaDoc). Voc deve escrever documentao adicional para salientar conceitos importantes. Pense neles como sendo um primeiro passo para o leitor, antes que ele v para detalhes de cdigo. Gosto de estrutur-los como textos curtos o suficiente para serem lidos durante um caf, utilizando diagramas UML para ajudar a ilustrar a discusso.

\44 r UM ESBOO DE PROCESSO DE DESENVOLVIMENTO Uso diagramas de pacote como o meu mapa lgico do sistema. Este diagrama me ajuda a compreender as partes lgicas do sistema e ver as dependncias (e mant-las sob controle). Um diagrama de utilizao (veja o Captulo 10) que mostra o quadro fsico de alto nvel, tambm pode se mostrar til neste estgio. Dentro de cada pacote, gosto de ver um diagrama de classes na perspectiva de especificao. No mostro cada operao em cada classe. Mostro apenas as associaes e os atributos-chave e operaes que me ajudam a entender o que existe l dentro. Este diagrama de classes funciona como um ndice grfico dos contedos. Se uma classe tem um comportamento de ciclo de vida complexo, desenho um diagrama de estados (veja o Captulo 8) para descrev-lo. Fao isso se o comportamento suficientemente complexo, o que no acontece com muita freqncia. Interaes complicadas entre classes so mais comuns, para as quais eu projeto diagramas de interao. Incluo, freqentemente, algum cdigo importante escrito em um estilo de programao. Se um algoritmo particularmente complexo estiver envolvido, eu considerarei a utilizao de um diagrama de atividades (veja o Captulo 9), mas somente se ele der maior compreenso do que o prprio cdigo. Se encontro conceitos que esto aparecendo repetidamente, uso padres (veja o box abaixo) para capturar as idias bsicas. Transio O ponto do desenvolvimento iterativo fazer todo o processo de desenvolvimento regularmente, de modo que a equipe de desenvolvimento se acostume a entregar cdigo acabado. Mas algumas coisas no devem ser feitas cedo. Um exemplo importante disto otimizao. A otimizao reduz a claridade e a capacidade de extenso do sistema, de modo a melhorar o desempenho. Este um compromisso que voc necessita fazer - apesar de tudo, um sistema tem que ser suficientemente rpido para satisfazer os requisitosdos usurios. Mas a otimizao precoce torna o desenvolvimento mais difcil, portanto isso algo que precisa ser deixado para o fim. Durante a transio, no h desenvolvimento para acrescentar funcionalidade, a no

ser que seja pequena e absolutamente essencial. Existe desenvolvimento para corrigir erros (bugs). Um bom exemplo da fase de transio o perodo entre a verso beta e a verso final do produto. Padres UML diz como expressar um projeto orientado a objetos. Os Padres focam, ao contrrio, nos resultados do processo: oferecem modelos-exemplo. Muitas pessoas comentaram que projetos de desenvolvimento tm problemas porqueas pessoas envolvidas no estavam cientes de projetos (designs) bem conhecidos por pessoas com mais experincia. Os padres descrevem

UML. ESSENCIAL: UM BREVE GUIA PARA A LINGUAGEM-PADRO DE MODELAGEM DE OBJETOS maneiras comuns de fazer as coisas. Elas so coletadas por pessoas que identificaram temas repetitivos em projetos (designs). Estas pessoas examinam cadatema e o descrevem de modo que outras pessoas possam ler o padro e ver como aplic-lo. Vamos examinar um exemplo. Digamos que voc tem alguns objetos rodando em umprocesso no seu desktop e eles necessitam comunicar-se com outros objetos rodandoem outro processo. Talvez, este processo tambm esteja no seu desktop; talvez, ele esteja em outro lugar. Voc no quer que os objetos do seu sistema tenham que se preocupar em encontrar outros objetos na rede ou executar chamadas de procedimentos remotos. O que voc pode fazer criar um objeto proxy dentro do seu processo local para o objeto remoto, O proxy tem a mesma interface que o objeto remoto. Os seus objetos locais se comunicam com ele utilizando as mensagens usuais internas do processo. Oproxy, ento, responsvel por passar quaisquer mensagens para o objeto real, seja l onde ele se localize. A Figura 2-2 um diagrama de classes (veja o Captulo 4) que ilustra a estrutura do padro Proxy. mtodo Sujeitoreal. solicitao() Sujeito Real E-j / / 11/1 solicita oQ solicita oQ Figura 2-2: Estrutura do Padro de Projeto Proxy Proxys so, uma tcnica comum utilizada em redes e em outros sistemas. As pessoastm muita experincia utilizando proxies, no que diz respeito a como eles podem ser usados, que vantagens eles podem trazer, suas limitaes e como implement-los. Livros de metodologia como este no discutem este conhecimento, tudo que eles discutem como voc pode diagramar um proxy. Apesar de ser til, no to til quanto a discusso de experincia envolvendo proxys. No incio dos anos noventa, algumas pessoas comearam a capturar estas experincias. Elas formaram uma comunidade interessada em escrever padres. Estas pessoas patrocinaram conferncias e produziram vrios livros.

UM F.SBOO DE ROCESSO DE L)ESENVOLVIMENTO O livro mais famoso de padres que surgiu deste grupo o livro da Gangue dos Quatro (Gamma, Helm, Jonhson e Vlissides 1995), que discute em detalhes 23 padres de projeto. Se voc quer saber sobre proxies, esta a fonte. O livro da Gangue dos Quatro desenvolve o assunto em dez pginas, dando detalhes sobre como os objetos funcionam em conjunto, os benefcios e as limitaes do padro, as variaes comuns e os usos e dicas de implementao para Smalltalk e C++. Proxy um padro de projeto porque ele descreve uma tcnica de projeto. Padres

tambm podem existir em outras reas. Digamos que voc est projetando um sistema para gerenciamento de risco em mercados financeiros. Voc precisa compreender como o valor de uma carteira de aes muda com o tempo. Voc pode fazer isso mantendo um preo para cada ao e marcando o tempo deste preo. Entretanto, voc tambm quer ser capaz de considerar o risco em situaes hipotticas (por exemplo: O que acontecer se o preo do petrleo cair?). Para fazer isso voc pode criar um Cenrio que contm todo o conjunto de preos para as aes. Ento, voc pode ter Cenrios separados para os preos da semana passada, seu melhor palpite para a prxima semana, seu palpite para a prxima semana se o preo do petrleo cair e assim por diante. Este padro Cenrio (veja Figura 2-3) um padro de anlise porque ele descreve uma parte da modelagem de domnio. Padres de anlise so valiosos porque eles lhe fornecem um comeo melhor quandovoc trabalha com um domnio novo. Comecei a coletar padres de anlise porque estava frustrado com domnios novos. Eu sabia que no era a primeira pessoa que osmodelava, ainda assim, cada vez eu tinha que comear com uma folha de papel em branco. O dado interessante sobre padres de anlise que eles surgem em lugares pouco comuns. Quando comecei a trabalhar em um projeto para

Figura 2-3: Padro de Anlise Cenrio

UIVIL SSENCIAL: UM bREVE U.UIA PARA A LINGUACI \1-IADRO DE MODEIAGEM DE OBJETOS fazer anlise financeira corporativa, fui muito ajudado por um conjunto de padres que eu havia anteriormente descoberto na rea da sade. Veja Fowler (1997) para aprender mais sobre Cenario e outros padres de anlise. Um padro muito mais que um modelo. Um padro deve incluir a razo