PARTE 1 Introduo 1.

1 UMI 1 Anlise e Projeto Orientados a Objetos A mudana do foco (para padres) ter um efeito profundo e duradouro sobre o modo como escrevemos programas. - Ward Cunningham e Ralph Johnson OBJETIVOS Comparar e contrastar anlise e projeto. Definir anlise e projeto orientados a objetos (A/POO). Ilustrar um breve exemplo. 1.1 UML e Padres na AIPOO O que significa ter um bom projeto de objetos? Este livro uma ferramenta para ajudar desenvolvedores e estudantes a aprenderem as habilidades bsicas usadas na anlise e no projeto orientados a objetos (A/POO). Essas habilidades so essenciais para a criao de software bem-projetado, robusto e manutenvel, usando tecnologias e linguagens orientadas a objetos, tais como Java, C++, Smalltalk e C#. O provrbio possuir um martelo no toma algum um arquiteto particularmente verdadeiro em relao tecnologia de objetos. Conhecer uma linguagem orientada a objetos (como lava) um primeiro passo necessrio, mas insuficiente, para criar sistemas orientados a objetos. Aprender a pensar em termos de objetos fundamental. 28 UTILIZANDO LIVIL E rADROES / Esta uma introduo ment Este livro uma introduo A/POO aplicando Linguagem de Modelagem Unificada (UML), padres (patterns) e Processo Unificado. Ele no pretende ser um texto avanado; antes, enfatiza o domnio dos fundamentos, como atribuir responsabilida- muit des a objetos, notao UML freqentemente usada e padres de projeto comuns. Ao a out mesmo tempo, principalmente nos captulos posteriores, o material avana para tpicos de nvel intermedirio, como projeto de umframework. / Aplicao da UML O livro no trata somente da UML. A UML uma notao padro de diagramao. Embora seja til aprender a notao, h questes mais cruciais orientadas a objetos para aprender; especificamente, como pensar em objetos - como projetar

sistemas orientados a objetos. A UML no A/POO ou um mtodo, apenas uma notao. 1 Assim, no adianta aprender diagramao UML sintaticamente correta e, talvez, uma ferramenta CASE UML, e no ser capaz de criar um excelente projeto, ou ava- j E liar e melhorar um existente. Esta a habilidade mais difcil e de maior importncia. Conseqentemente, este livro uma introduo ao projeto de objetos. Ainda assim, necessria uma linguagem para a A/POO e para as plantas do software, tanto como uma ferramenta de raciocnio quanto uma forma de comunicao. Portanto, este livro mostra como aplicar a UML na execuo de A/POO, e cobre a notao UML freqentemente usada. A nfase est em ajudar as pessoas a aprender a arte e a cincia de construir sistemas com objetos, e no na notao. / Aplicao de padres e atribuio de responsabilidades Como as responsabilidades devem ser atribudas a classes de objetos? Como os objetos devem interagir? Quais classes devem fazer o qu? Estas so questes importantes no projeto de um sistema. Certas solues consagradas para os problemas de projeto podem ser (e tm sido) expressas na forma de princpios de melhores prticas, heursticas ou padres - frmulas para a soluo de problemas que codificam princpios exemplares de projeto. Este livro, ao ensinar como aplicar padres, permite um aprendizado mais rpido e o uso eficiente desses idiomas fundamentais do projeto de objetos. / Um estudo de caso Esta introduo A/POO ilustrada em um nico estudo de caso que discutido ao longo de todo o livro, em cuidadosa e profunda anlise e projeto, de modo que detalhes difceis do que deve ser considerado e solucionado em um problema real so tra- Figuri tados e resolvidos. / Casos de uso e anlise de requisitos Muitas outra A/POO (e todo o projeto de software) est fortemente relacionada com a atividade pr-requisito da anlise de requisitos, a qual inclui escrever casos de uso. Portanto, Const o estudo de caso comea com uma introduo a esses tpicos, embora eles no sejam tos, d especificamente orientados a objetos. O proj ocom

/ Um exemplo de um processo iterativo - o Processo Unificado Considerando as muitas atividades possveis, desde a anlise de requisitos at a im- toplcc plementao, como deve proceder um desenvolvedor ou uma equipe de desenvolviANALISE E PROJETO ORIENTADOS A OBJETOS 29 mento? A anlise de requisitos, e a A/POO precisam estar presentes no contexto de algum processo de desenvolvimento. Nesse caso, usamos como exemplo de processo de desenvolvimento iterativo o Processo Unificado (PU), no qual estes tpicos so introduzidos. Entretanto, os tpicos de anlise e projeto cobertos so comuns a muitas abordagens e seu aprendizado no contexto do PU no invalida sua aplicao a outros mtodos. Concluindo, este livro ajuda um estudante ou um desenvolvedor a: Aplicar princpios e padres para criar melhores projetos de objetos. Seguir um conjunto de atividades comuns de anlise e projeto, baseando-se no PU como exemplo. Criar diagramas freqentemente usados na notao UML. Este texto ilustra isto no contexto de um nico estudo de caso. AIPOO es_oUM Tpicos e habilidades Princpios e Anlise N diretrizes de requisitos Desenvolvimento interativo com o Pu Figura 1.1 Tpicos e habilidades cobertas. Muitas outras habilidades so importantes Construir software demanda muitas habilidades e passos, alm da anlise de requisitos, da A/POO e da programao orientada a objetos. A engenharia de usabilidade e o projeto da interface do usurio, por exemplo, so cruciais para o sucesso; o mesmo ocorre com o projeto de bancos de dados. Entretanto, esta introduo enfatiza a A/POO, no pretendendo cobrir todos os tpicos do desenvolvimento de software. Ela uma parte de um todo maior. 30 UTILIZANDO UML E PADRES 1.2 Atribuio de Responsabilidades 1.4 C Existem muitas atividades e artefatos possveis na A/POO introdutrios, alm de E uma vasta gama de princpios e diretrizes. Suponha que devamos escolher uma ni- r ca habilidade prtica dentre todos os tpicos discutidos aqui - uma habilidade a ser empregada em uma ilha deserta. Qual deveria ser ela? o Uma habilidade crtica fundamental em A/POO atribuir, habilmente, responsabilidades aos componentes de software. o

Por qu? Porque esta uma atividade que no pode deixar de ser executada seja ao desenhar um diagrama UML ou ao programar - e porque ela influencia dras ticament a robustez, a facilidade de manuteno e a reusabilidade de componentes ________ de software. - . . conceito d Naturalmente, existem outras habilidades necessarias na A/POO, mas a atri_______ buio de responsabilidades enfatizada porque ela tende a ser uma habilidade difcil de ser dominada e, no entanto, de vital importncia. Em um projeto real, um desenvolvedor pode no ter a oportunidade de executar quaisquer outras atividades de anlise ou de projeto - um processo de desenvolvimento do tipo corrida para codificar. Apesar disso, mesmo nessa situao, atribuir responsabilidades inevitvel. Conseqentemente, os passos de projeto neste livro enfatizam princpios de atribuio de responsabilidades. So apresentados e aplicados nove princpios fundamentais para o projeto de F objetos e atribuio de responsabilidades. Eles so organizados em um grupo, de forma a facilitar o aprendizado, denominado padres GRASP. 1.5 L 1.3 O Que So Anlise e Projeto? A anlise enfatiza uma investigao do problema e dos requisitos, em vez de uma soluo. Se desejamos um novo sistema de informao de biblioteca computadorizado, por exemplo, como ele ser usado? Anlise um termo de significado amplo, melhor qualificado como anlise de requisitos (uma investigao dos requisitos) ou anlise de objetos (uma investigao Definir c dos objetos do domnio). A O projeto enfatiza uma soluo conceitual que satisfaa os requisitos e no sua implementao. Uma descrio de um esquema de banco de dados e objetos de soft war um bom exemplo. Em ltima instncia, projetos podem ser implementados. Da mesma forma que na anlise, o termo projeto melhor qualificado como projeto de objetos ou projeto de banco de dados. A anlise e o projeto foram resumidos na fasefaa a coisa certa (anlise) efaa cer t a coisa (projeto). N. de Ri O envolvimento 1.4 O Que so Anlise e Projeto Orientados a Objetos? Durante a anlise orientada a objetos, o objetivo encontrar e descrever os objetos - ou conceitos - no domnio do problema. No caso do sistema de informao de uma biblioteca, por exemplo, alguns dos conceitos incluem Livro, Biblioteca e usurio*. Durante o projeto orientado a objetos, h uma nfase na definio dos objetos

de software e como eles colaboram para a satisfao dos requisitos. No sistema da biblioteca, por exemplo, um objeto de software Livro pode ter um atributo ttulo e um mtodo obterCaptulo (ver Figura 1.2). Finalmente, durante a implementao ou programao orientada a objetos, os objetos de projeto so implementados, como uma classe Livro em Java. 1.5 Um Exemplo Antes de aprofundar os detalhes da anlise de requisitos e da A/POO, esta seo apresenta uma viso geral de uns poucos passos-chave e diagramas, usando um exemplo simples - um jogo de dados no qual um jogador lana dois dados. Se o total for sete, ele vence; caso contrrio, perde. Definir casos de uso A anlise de requisitos pode incluir uma descrio dos processos do domnio relacio1 nados; estes podem ser escritos como casos de uso. Definir casos Definir modelo Definir diagramas de uso de domnio de interao Definir diagramas de classes de projeto *N. de R. T Os interessados em um projeto (stakeholders) so todas as pessoas da organizao que tm algum tipo de envolvimento direto ou indireto com o sistema, como usurios, gerentes, clientes, patronos e financiadores. fNAL1SE E rROJFIO IJRIEN lADOS A IJBJETOS 1 conceito do domnio] Livro lo visualizao de conceito de domnio 1 representao em uma linguagem de programao orientada a objetos 4, public class Livro private String ttulo; public Capitulo obterCaptulo(int) {...} Figura 1.2 A orientao a objetos enfatiza a representao de objetos. .

. 44 IZANUMLE PADRES Casos de uso no so artefatos orientados a objetos - eles so simplesmente narrativas escritas. Contudo, so uma ferramenta popular para a utilizao na anlise de requisitos e uma parte importante do PU. Por exemplo, temos uma verso simplificada do caso de uso Jogar um logo de Dados: Jogar um Jogo de Dados: um jogador pega e lana os dados. Se a soma do valor das faces dos dados totalizar sete, ele vence; caso contrrio, perde. Definir um modelo de domnio A anlise orientada a objetos se preocupa com a criao de uma descrio do domnio, a partir da perspectiva de uma classificao por objetos. Uma decomposio do domnio envolve a identificao dos conceitos, dos atributos e das associaes que so considerados de interesse, O resultado pode ser expresso em um modelo de domnio, o qual ilustrado em um conjunto de diagramas que mostram conceitos ou objetos do domnio. Definir casos Definir modelo Definir diagramas Definir diagramas de uso de domnio 1 de interao Por exemplo, um modelo parcial de domnio mostrado na Figura 1.3. Esse modelo ilustra os conceitos de interesse Jogador, Dado e JogoDeDados, com suas associaes e atributos. Note que um modelo de domnio no uma descrio dos objetos de software; uma visualizao de conceitos no domnio do mundo real. Jogador Dado ____________________ 1 Lana 2 nome valorDaFace 12 Joga JogoDeDados 1 Inclui Figura 1.3 Modelo parcial de domnio do jogo de dados. 1 Definir diagramas de interao ANLISE E PRoJE1o ORIENTADOS A OBJETOS 3. O projeto orientado a objetos se preocupa com a definio de objetos de software e suas colaboraes. Uma notao comum para ilustrar essas colaboraes o diagrama de interao. Ele mostra o fluxo de mensagens entre os objetos de software e, assim, a invocao de mtodos. Definir casos Definir modelo Definir diagrama Definir diagramas de uso de domnio de interao

Por exemplo, assuma que desejada uma implementao de software do jogo de dados. O diagrama de interao na Figura 1.4 ilustra o passo principal do jogo, por meio do envio de mensagens a instncias das classes JogoDeDados e Dado. Observe que, embora no mundo real um jogador lance os dados, no projeto de software o objeto JogoDeDados lana os dados (isto , envia mensagens para objetos Dado). Objetos do projeto de software e programas se inspiram, em parte, em domnios do mundo real, mas eles no so modelos diretos ou simulaes do mundo real. Figura 1.4 Diagrama de interao ilustrando mensagens entre os objetos de sottware. Definir diagramas de classes de projeto Alm de uma viso dinmica de objetos colaborativos mostrada nos diagramas de interao, til criar uma viso esttica das definies de classes com um diagrama de classes de projeto. Este ilustra os atributos e mtodos das classes. 1DeDados L jJ Ianar() v vf 2 := obterValorUaF aceO ad o2: D a 1

34 UTILIZANDO UML E PADRES Definir casos Definir modelo Definir diagramas Definir diagramas de uso de domnio de interao de classes de projeto Por exemplo, no jogo de dados, uma inspeo do diagrama de interao leva ao diagrama de classes de projeto parcial mostrado na Figura 1.5. Uma vez que uma mensagem jogar enviada para um objeto JogoDeDados, a classe JogoDeDados requer um mtodo jogar e a classe Dado requer um mtodo lanar e um mtodo obter ValorDaFace Por Ao contrrio do modelo de domnio, esse diagrama no ilustra conceitos do mundo real, mostra classes de software. JogoDeDados Dado dadol : Dado 1 2 valorDaFace: mI dado2: Dado - ___________________ obterValorDaFace() : int jogar() lanar() 1 7 Figura 1.5 Diagramas de classes de projeto parcial. Resumo O jogo de dados um problema simples, apresentado com a inteno de

focalizar alguns dos passos e artefatos na anlise e projeto orientados a objetos. Visando manter a introduo simples, no foi explicada toda a notao UML ilustrada. Os prximos captulos exploraro a anlise, o projeto e esses artefatos em maiores detalhes. 1.6 AUML A Linguagem de Modelagem Unificada (UML) uma linguagem para especificar, visualizar, construir e documentar os artefatos de sistemas de software, bem como para modelar negcios e outros sistemas que no sejam de software [OMGO1J. A UML emergiu como a notao diagramtica padro para a modelagem orientada a objetos. Ela comeou como um esforo conjunto de Grady Booch e Jim Rumbaugh, em 1994, para combinar as notaes diagramticas dos seus dois difundidos e populares mtodos - o Booch e OMT (Object Modeling Technique). Posteriormente, se juntou a eles Ivar Jacobson, o criador do mtodo Objectory, e, como grupo, os trs O traba passaram a ser conhecidos como os trs amigos. Muitos outros contriburam para a N. de 1 ANLISE E PROJETO ORIENTADOS A OBJETOS 35 UML, e talvez a contribuio mais notvel tenha sido a de Cris Kobryn, um dos lderes do seu contnuo refinamento. A UML. foi adotada, em 1997, como um padro pelo OMG (Object Management Group, uma instituio de criao de padres para a indstria de software) e continua a ser refinada em novas verses OMG UML. Este livro no cobre minuciosamente a UML, que uma notao enorme (alguns dizem que ela grande demais1). Ele enfoca os diagramas mais usados, os recursos mais comuns nesses diagramas e a notao bsica, que a que tem menor possibilidade de mudar nas futuras verses da UML. Por que em alguns captulos no veremos muito da UML? Este no apenas um livro sobre a notao UML, mas sim um livro que explora o panorama da aplicao da UML, padres e um processo iterativo no contexto do desenvolvimento de software. A UML principalmente aplicada durante a A/POO, os quais so normalmente precedidos pela anlise de requisitos. Portanto, os captulos iniciais apresentam uma introduo aos tpicos de casos de uso e anlise de requisitos, seguidos por captulos sobre a A/POO, alm de mais detalhes da UML. 1.7 Leituras Adicionais Um resumo popular e de fcil leitura sobre a notao UML LJML Essencial , de Martin Fowler. Uma introduo sucinta e popular ao PU (e seu refinamento no Rational Unified Process) The Rational Unfied Process - An Introduction, de Philippe Kruchten. Para uma discusso detalhada da notao UML (verso 1.3), vale a pena ler The Unfied Modeling Language Reference Manual e The Unfied Modeling Language tJser Guide, de Booch, Jacobson e Rumbaugh. Observe que esses textos no tm por objetivo o aprendizado de como fazer a modelagem de

objetos ou a A/POO - eles so referncias para a notao de diagramas da UML. Para uma descrio da verso em uso da UML, necessrio o documento online OMG Unfied Modeling Language Specfication encontrado em www.omg.org. O trabalho de reviso da UML e as verses a serem liberadas podem ser encontrados em www.celigent.com/uml. Existem muitos livros sobre padres de software, mas o clssico que inspirou a todos Padres de Projeto** de Gamma, Helm, Johnson e Vlissides. Este livro uma leitura obrigatria para aqueles que estudam o projeto de objetos. Contudo, ele no um texto introdutrio e melhor l-lo aps sentir-se confortvel com os fundamentos do projeto e programao de objetos. 10 trabalho em andamento na UML 2.0 inclui o objetivo de simplificao e reduo da notao. Este livro apresenta a UML em seus recursos mais usados, os quais provavelmente sobrevivero a futuras simplificaes. N. de RI. Publicado no Brasil pela Bookman Editora. N. de RI Publicado no Brasil pela Bookman Editora. 2 Desenvolvimento Iterativo e o Processo Unificado Pessoas so mais importantes do que qualquer processo. Pessoas capazes com um bom processo sempre superaro pessoas capazes sem um processo, em todas as circunstncias. - Grady Booch OBJETIVOS i-ornecer uma motivao para o contedo e ordem dos captulos subseqentes. Definir um processo iterativo e adaptativo. Definir conceitos fundamentais do PU. Introduo O desenvolvimento iterativo uma abordagem competente para o desenvolvimento de software e est no cerne de como aA/POO apresentada neste livro. O PU um exemplo de processo iterativo para projetos que utilizam A/POO e molda a apresentao deste livro. Conseqentemente, importante ler este captulo para que esses conceitos centrais e sua influncia sobre a estrutura deste livro fiquem claros. Este captulo resume algumas idias-chave; ver o Captulo 37 para uma discusso mais aprofundada do PU e das prticas de um processo iterativo de desenvolvimento. Informalmente, um processo de desenvolvimento de software descreve uma abordagem para a construo, implantao e, possivelmente, a manuteno de softzvare. O Processo Unificado (PU) [JBR99] sugiu como um processo popular para o desenvolvimento de software visando construo de sistemas orientados a objetos. O Processo Unificado da Rational, ou RUP (de Rational Unified Process), [KruchtenOOj, um refinamento detalhado do PU, muito adotado.

3 UTILIZANDO UML E PADRES O PU combina as melhores prticas, tais como um ciclo de vida iterativo e o d senvolvimento orientado pelos riscos, em uma nica e bem documentada descri Conseqentemente, utilizado neste livro como o processo-exemplo dentro do qu sero introduzidos a A/POO. Este livro comea com uma introduo ao PU por duas razes: 1. O PU um processo iterativo. O desenvolvimento iterativo uma prtica grande utilidade que influencia a forma deste livro apresentar a A/POO bem c mo suas melhores prticas. 2. As prticas do PU fornecem uma estrutura-exemplo para mostrar como fazer como aprender - a A/POO. Este texto apresenta uma introduo ao PU, e no uma cobertura completa do mesmo. Ele destaca idias e artefatos comuns, prprias de uma introduo A/POO e anlise de requisitos. E se o PU no me interessar? O PU usado como um processo-exemplo dentro do qual so exploradas a anli de requisitos e a A/POO, j que necessrio tratar do assunto no contexto de algui processo, e o PU (ou seu refinamento, oRUP) relativamente bem empregado. Ali disso, o PU apresenta atividades comuns e prticas adotadas no projeto de desenvo vimento de software. Entretanto, as idias centrais deste livro - tais como casos de u e padres de projeto - so independentes de qualquer processo, e aplicveis a mu tos outros. 2.1 A Idia mais Importante do PU: Desenvolvimento Iterativo O PU promove vrias prticas, mas uma se destaca das demais: o desenvolvimei to iterativo. Nesta abordagem, o desenvolvimento organizado em uma srie c miniprojetos, de durao fixa (por exemplo, quatro semanas) chamada iteraes; produto de cada um um sistema testado, integrado e executvel. Cada itera inclui suas prprias atividades de anlise de requisitos, projeto, implementao teste. O ciclo de vida iterativo baseado em refinamentos e incrementos de um sist ma por meio de mltiplas iteraes, com realimentao (feedback) e adaptao cclic como principais propulsores para convergir para um sistema adequado. O sisteir cresce incrementalmente ao longo do tempo, iterao por iterao, razo pela qu esta abordagem tambm conhecida como desenvolvimento iterativo e incremei tal (ver Figura 2.1). Inicialmente, as idias de processos iterativos eram conhecidas como desenvo vimento evolucionrio e em espiral [Boehm88, Gi1b88]. VESENVOLVIMEN1O ITERATIVO E O FROCESSO UNIFICADO 39 de o ao oe Requisitos Projeto

Implementao & Teste & Integrao & Mais Projeto Requisitos Projeto Implementao & Teste & Integrao & Mais Projeto Integrao Final & Teste de Sistema Realimentao da iterao N leva ao refinamento e adaptao dos requisitos e do projeto na iterao N+1. Observe que, neste exemplo, no h uma corrida para codificar, nem um longo e demorado passo de projeto, o qual tenta resolver todos os problemas e detalhes do projeto antes da programao. Algumas consideraes antecipadas so feitas com relao ao projeto, usando modelagem visual direta e rpida para esboo de diagramas UML. Essas consideraes so feitas durante meio dia, ou um dia inteiro, por desenvolvedores que esto executando o trabalho de projeto em duplas. O resultado de cada iterao um sistema executvel, mas incompleto; ele no est pronto para ser colocado em produo. O sistema pode no estar preparado para instalao e produo seno aps muitas iteraes, como, por exemplo, 10 ou 15 iteraes. Tempo Integrao Final & Teste de Sistema e o. ai de o-e se m olso ai4 semanas (por exemplo)0 Iteraes so de tamanho fixo ou limitadas pelo tempo. Figura 2.1 Desenvolvimento iterativo e incremental. o O sistema cresce incrementalmante. Exemplo

Como exemplo (e no uma receita): em uma iterao de duas semanas no meio de um projeto, talvez a segunda-feira seja gasta, principalmente, na distribuio e no esclarecimento das tarefas e dos requisitos da iterao, enquanto uma pessoa faz a engenharia reversa do cdigo da ltima iterao para diagramas UML (via uma ferramenta CASE), imprime e exibe diagramas que sejam de interesse. A tera-feira gasta em quadros brancos, fazendo trabalho de projeto em duplas, desenhando rascunhos de diagramas UML registrados em cmeras digitais e escrevendo pseudocdigo e notas de projeto. Os oito dias restantes so usados para implementao, testes (unitrio, de aceitao, usabilidade, etc.), projeto adicional, integrao, produo diria, teste de sistema e estabilizao do sistema parcial. Outras atividades incluem demonstraes e avaliaes para envolvidos no projeto do sistema, alm do planejamento para a iterao seguinte. teas ai n ---.-----1 40 UTILIZANDO UML E PADRES A sada de uma iterao no um prottipo experimental ou descartvel, assim como o desenvolvimento iterativo no prototipao. A sada um subconjunto do sistema final com qualidade final (e no qualidade de prottipo). Embora, em geral, cada iterao contemple novos requisitos e estenda incrementalmente o sistema, uma iterao pode ocasionalmente revisitar o software j existente e melhor-lo; por exemplo, uma iterao pode enfocar a melhoria do desempenho de um subsistema, em vez de dot-lo de novas caractersticas. Acolher a mudana: realimentao e adaptao O subttulo de um livro que discute o desenvolvimento iterativo Embrace Change (Acolha a Mudana) [BeckOOj. Esta frase evoca a atitude-chave do desenvolvimento iterativo: em vez de combater a inevitvel mudana que ocorre no desenvolvimento de software tentando (geralmente sem sucesso) especificlo completa e corretamente e fazer com que todos assinem embaixo um conjunto de requisitos e projetos congelados antes da implementao, o desenvolvimento iterativo baseado em uma atitude de aceitar a mudana e a adaptao como fatores inevitveis e, de fato, essenciais. Isso no significa que o desenvolvimento iterativo e o PU encorajem um processo exageradamente baseado nas caractersticas do sistema, descontrolado e reativo. Os captulos subseqentes mostram como o PU equilibra a necessidade de chegar a um acordo e estabilizar um conjunto de requisitos com a realidade de mudana de requisitos, medida que os interessados no projeto do sistema esclarecem sua viso ou ocorrem mudanas no mercado de atuao da organizao.

Cada iterao exige a escolha de um pequeno subconjunto dos requisitos, alm da sua rpida projeo, implementao e teste. Nas iteraes iniciais, a escolha de requisitos e o projeto podem no ser exatamente o que desejado. No entanto, o ato de executar rapidamente um pequeno passo antes de finalizar todos os requisitos, ou antes que o projeto inteiro seja especulativamente definido, leva a uma realimentao rpida - obtida a partir de usurios, desenvolvedores e testes (como testes de carga e de facilidade de uso). Essa realimentao precoce vale ouro; em vez de especular sobre os requisitos ou projeto corretos, a realimentao a partir da construo e teste realsticos fornece uma percepo prtica crucial, bem como uma oportunidade para modificar ou adaptar a compreenso dos requisitos ou do projeto. Os usurios finais podem ver um sistema parcial e dizer: sim, foi isso que eu pedi, mas agora que o experimentei, o que eu realmente quero algo ligeiramente diferente. Esse processo de sim... mas no um sinal de erro; na verdade, ciclos estruturados precoces e freqentes de sim... mas so um modo hbil de progredir e descobrir o que de real valor para os interessados no sistema. No entanto, como j mencionado, isto no um endosso do desenvolvimento catico e reativo, no qual os desenvolvedores continuamente mudam de direo - possvel um meio-termo. Alm de esclarecer requisitos, atividades como teste de carga provaro se o projeto e a implementao parciais esto no caminho certo, ou, se na iterao seguinte, ser necessria uma mudana na arquitetura principal do sistema. E melhor resolver e por prova as decises arriscadas e fundamentais de projeto precocemente do que tardiamente - e o desenvolvimento iterativo fornece o mecanismo para isso. 1 Ou, mais provavelmente, voc no compreendeu o que eu queria! -Iteraes iniciais esto longe do verdadeiro caminho do sistema. Por meio de realimentao e adaptao, o sistema converge para os requisitos e o projeto mais adequados. TIe e, uma iterao de projeto, implementao, integrao e teste Figura 2.2 A realimentao e a adaptao iterativas levam ao sistema desejado. A instabilidade dos requisitos e do projeto diminuem com o tempo. Benefcios do desenvolvimento iterativo Os benefcios do desenvolvimento iterativo incluem: mitigao precoce, em vez de tardia, de altos riscos (tcnicos, requisitos, objetivos, usabilidade, etc.); progresso visvel desde o incio; OU a realimentao, envolvimento do usurio e adaptao imediatos, levando a

um ver sistema refinado que atenda, de forma mais adequada, s reais necessidades dos fl interessados no projeto; de . . fre- a a complexidade e administrada; a equipe nao e sobrecarregada pela paralisia da re- anlise ou por passos muito longos e complexos; o a o aprendizado obtido em uma iterao pode ser metodicamente usado para mees lhorar o prprio processo de desenvolvimento, iterao por iterao. O PU (e desenvolvedores com experincia em desenvolvimento iterativo) recomenda uma durao, para uma iterao, entre duas e seis semanas. Usar pequenos passos, obter realimentao rpida e fazer adaptaes so idias centrais no desenvolvimento iterativo; iteraes longas subvertem a motivao central para o desenvolvimento iterativo e aumentam o risco do projeto. Entretanto, com muito menos tempo do que duas semanas, difcil completar um trabalho suficiente para obteno de DESENVOLVIMENrO ITERATIVO E O FROCESSO UNIFICADO 4I Conseqentemente, o trabalho progride por meio de uma srie de ciclos estruturados em construo-realimentao-adaptao. No raro que nas iteraes iniciais o desvio do caminho verdadeiro do sistema (em termos dos seus requisitos e projeto) seja maior do que nas ltimas iteraes. Com o tempo, o sistema converge para esse caminho, como ilustrado na Figura 2.2. / Nas ltimas iteraes, rara uma mudana sigificativa de requisitos, mas ela pode dar organizao uma vantagem competitiva nos negcios. Tamanho e limitao de tempo da iterao 42 UTILIZANDO LJML E I-ADRES produtos e realimentao significativos; porm, quando se tem muito mais do que 2.3 seis ou oito semanas, a complexidade torna-se, em geral, grande e de difcil controle, e a realimentao atrasa. Uma iterao muito longa perde o objetivo do desenvolvimento iterativo. Um perodo curto melhor. Uma idia-chave que as iteraes tm limites temporais (ocupam janelas de tempo de durao fixa no cronograma). Por exemplo, se decidido que a iterao seguinte deve ter quatro semanas de durao, o sistema parcial devem estar integrado, testado e estabilizado dentro da data programada -. no recomendvel o no cumprimento dos prazos. Se acharmos que ser difcil cumprir o prazo final, recomendvel remover tarefas ou requisitos da iterao e inclu-las em uma iterao futura, em vez do no cumprimento do prazo. O Captulo 37 resume as razes para limitar o tempo.

Equipes grandes (com centenas de desenvolvedores) podem exigir iteraes mais longas que seis semanas para compensar o aumento da sobrecarga de coordenao e comunicao; mas no se recomenda mais do que trs a seis meses. Por exemplo, a substituio bem-sucedida, nos anos 90, do sistema de controle de trfego areo canadense foi desenvolvida com um ciclo de vida iterativo e outras prticas adotadas no PU. Ela envolveu 150 programadores e foi organizada em iteraes de seis meses.2 Mas note que mesmo no caso de uma iterao de projeto com um total de seis meses, a equipe de um subsistema de 10 ou 20 desenvolvedores pode dividir o seu trabalho em uma srie de seis iteraes de um ms. Uma iterao de seis meses a exceo, e no a regra, para equipes grandes. Reiterando: o PU recomenda que normalmente uma iterao fique entre duas e seis semanas de durao. 2.2 Conceitos e Melhores Prticas Adicionais do PU A idia central a ser apreciada e praticada no PU a de usar iteraes curtas, com durao fixa, em um processo de desenvolvimento iterativo adaptativo. Outra idia implcita, mas central para o PU, o uso de tecnologias orientadas a objetos, incluindo A/POO e programao orientada a objetos. Algumas das melhores prticas e conceitos-chave adicionais do PU incluem: enfrentar os problemas que envolvem altos riscos e alto valor j nas iteraes miciais; envolver continuamente os usurios na avaliao, na realimentao e nos requisitos; construir uma arquitetura central coesa nas iteraes iniciais; verificar continuamente a qualidade; fazer testes logo de incio, com freqncia e em situaes realsticas; aplicar casos de uso; modelar visualmente o software (com a UML); gerenciar requisitos cuidadosamente; usar solicitaes de mudana e praticar a gerncia de configurao. Ver o Captulo 37 para uma descrio mais detalhada destas prticas. 2 Philippe Kruchten, que tambm liderou o desenvolvimento do RUP, atuou como arquiteto-chefe no projeto. LIESENVOLVIMENIO ITERATIVO E O VROCESSO IJNIFJCADO 13 2.3 As Fases e os Termos Relativos ao Cronograma do PU Um projeto PU organiza o trabalho e as iteraes em quatro fases principais: 1. Concepo - viso aproximada, casos de negcio, escopo e estimativas vagas. 2. Elaborao - viso refinada, implementao iterativa da arquitetura central, resoluo dos altos riscos, identificao da maioria dos requisitos e do escopo e estimativas mais realistas.

3. Construo - implementao iterativa dos elementos restantes de menor risco e mais fceis e preparao para a implantao. 4. Transio - testes beta e implantao. Essas fases so mais bem definidas nos captulos subseqentes. Este no o antigo ciclo de vida em cascata ou seqencial, no qual primeiro temos que definir todos os requisitos para, ento, fazer todo ou a maioria do projeto. A concepo no uma fase de requisitos; na verdade, uma espcie de fase de estudo de viabilidade, na qual se executa um volume suficiente de investigao para fundamentar a deciso de continuar ou parar. Da mesma forma, a elaborao no a fase de requisitos ou projeto; uma fase na qual a arquitetura central iterativamente implementada e os problemas de alto risco so mitigados. A Figura 2.3 ilustra termos comuns relativos ao cronograma de um PU. Note que um ciclo de desenvolvimento (o qual termina com a entrega de uma verso do sistema para ser posta em produo) composto de muitas iteraes. marco de referncia Um ponto de trmino de uma iterao no qual ocorre alguma deciso ou avaliao significativa. Um subconjunto estvel executvel do produto final. O fim de cada iterao uma entrega secundria. a diferena (deIta) entre as entregas de duas iteraes subseqentes. entrega final para a produo Nesse ponto, o sistema entregue para uso na produo. ciclo de desenvolvimento tt verso incremento Figura 2.3 Termos relativos ao cronograma de um PU. 44 UTILIZANDO UML E 1-ADROES 2.4 As Disciplinas do PU (anteriormente Fluxos de Trabalho - Workflows) Em 2001, o antigo termo fluxo de trabalho do PU (UP workjlow) foi substitudo

pelo novo termo disciplina, de modo a ficar em harmonia com um esforo internacional de padronizao conhecido como OMG SPEM; muitos continuam a usar o antigo termo, embora isto no seja estritamente correto. Fluxo de trabalho assumiu um significado novo, mas ligeiramente diferente dentro do PU: em um projeto particular, ele significa uma particular seqncia de atividades (talvez entre disciplinas) - um fluxo de trabalho. 4i adaptado do produto RUP. No ta nal am O PU descreve atividades de trabalho, como redigir um caso de uso, dentro de disciplinas (originalmente chamadas fluxos de trabalho).3 Uma disciplina um conjunto de atividades (e artefatos relacionados) em uma rea relacionada com um assunto, como as atividades dentro da anlise de requisitos. No PU, um artefato o termo usado para qualquer produto do trabalho: cdigo, grficos para a Web, esquemas de bancos de dados, documentos em texto, diagramas, modelos e assim por diante. Existem vrias disciplinas no PU; este livro focaliza alguns artefatos nas seguintes: Modelagem de Negcio - Quando do desenvolvimento de uma imica aplicao, esta inclui a modelagem de objetos do domnio. Quando estamos envolvidos com a anlise de negcios ou reengenharia de processo de negcio em larga escala, inclui a modelagem dinmica dos processos de negcio ao longo de toda a empresa. Requisitos - Anlise de requisitos para uma aplicao, como escrever casos de uso e identificar requisitos no funcionais. Projeto - Todos os aspectos relacionados com o projeto, incluindo a arquitetura geral, objetos, bancos de dados, redes e outros tpicos correlatos. Na Figura 2.4, mostrada uma lista das disciplinas do PU. Disciplinas Coi ou na nf ess bili ilu to na de Uma iterao de quatro semanas (por exemplo) Um miniprojeto que inclui trabalho na maioria das disciplinas, terminando com um executvel estvel

ta an Amostras de Disciplinas do PU (Modelagem de Negcio Foco deste -K Requisitos livro Projeto Implementao Teste Implantao Gesto de Configurao & Mudanas Gesto de Projeto Ambiente Amostra Disciplinas dc Modelagen Neg Requi Prc Implementa Fig Figura 2.4 Disciplinas do PU. Estrutura Em Re UESENVOLVIMENTO ITERATIVO E O FROCESSO UNIFICADO 4S No PU, Implementao significa programao e construo do sistema, no implantao. A disciplina Ambiente se refere ao estabelecimento do instrumental e personalizao do processo para um projeto - ou seja, a preparao das ferramentas e o ambiente do processo. DiscIplinas e fases Como ilustrado na Figura 2.4, durante uma iterao o trabalho prossegue na maioria ou em todas as disciplinas. Contudo, o esforo relativo no decorrer destas discipli e nas muda ao longo do tempo. As iteraes iniciais naturalmente tendem a dar uma nfase maior aos requisitos e ao projeto, enquanto que as ltimas disciplinas do a esses itens uma nfase menor, medida que os requisitos e o projeto central se estaa bilizam por meio de um processo de realimentao e adaptao. Relacionando isto com as fases do PU (concepo, elaborao, etc.), a Figura

2.5 ilustra a mudana do esforo relativo em relao s fases; note que isto uma sugesto e no deve ser tomado ao p da letra como uma recomendao. Por exemplo, e na elaborao, as iteraes tendem a ter uma carga de anlise de requisitos e trabalho de projeto relativamente altos, embora tambm tenham algum esforo de implemena tao. Durante a construo, a nfase mais pesada na implementao e mais leve na anlise de requisitos. O esforo relativo las disciplinas muda ao longo das fases. Este exemplo uma sugesto e no deve ser tomado ao p da letra. elaborao construo ] Amostras de Disciplinas do PU Modelagem de Negcio Requisitos Projeto Implementao Figura 2.5 Disciplinas e fases. Estrutura do livro e as fases e disciplinas do PU Em relao a fases e disciplinas, qual o foco do estudo de caso? Resposta: O estudo de caso enfatiza as fases de concepo e elaborao. Ele enfoca alguns artefatos nas disciplinas de Modelagem de Negcio, Requisitos e Projeto, j que aqui que a anlise de requisitos, a A/POO, os padres e a UML so principalmente aplicados. 4 D IJ IILILANUO LJIVIL 1 ADRO1S Os captulos iniciais introduzem atividades de concepo; os captulos seguintes ex- Pa ploram vrias iteraes da elaborao. A lista a seguir e a Figura 2.6 descrevem a organizao em relao s fases do PU. 1. Os captulos relativos fase de concepo apresentam os fundamentos da anlise de requisitos. 2. A iterao 1 introduz os fundamentos da A/POO e como atribuir responsabilidades a objetos.

3. A iterao 2 enfoca o projeto de objetos, especialmente a introduo de alguns padres de projeto altamente utilizados. 4. A iterao 3 introduz diversos assuntos, tais como a anlise de arquitetura e o projeto deframeworks. O Livro Tpicos iais eOntaj ooendozradde ____________ Figura 2.6 A organizao do livro est relacionada s fases e iteraes do PU. 2.5 Personalizao do Processo e a Pasta de Desenvolvimento Artefatos opcionais Algumas das prticas e dos princpios do PU so invariantes, como o desenvolvimento iterativo e orientado ao controle dos riscos, bem como a verificao contnua da qualidade. Entretanto, um aspecto-chave do PU que todas as atividades e os artefatos (modelos, diagramas, documentos, etc.) so opcionais - bem, talvez no o cdigo! 2 O conjunto de possveis artefatos descritos no PU deve ser visto como um conjunto de medicamentos em uma farmcia. Da mesma forma que algum no toma medicamentos de forma indiscriminada, mas ajusta a escolha de acordo com os sintomas, em um projeto PU a equipe deve selecionar um pequeno subconjunto de artefatos que atenda a seus problemas e necessidades. Em geral, a equipe deve se concentrar em um pequeno conjunto de artefatos que demonstrem possuir um alto valor prtico. \soGeraI1 A escolha de artefatos do PU para um projeto pode ser escrita em um curto documento denominado Pasta de Desenvolvimento (um artefato na disciplina Ambiente). Por exemplo, a Tabela 2.1 poderia ser a Pasta de Desenvolvimento que descreve os artefatos para o Projeto ProxGer, o estudo de caso explorado neste livro. Os prximos captulos descrevem a concepo de alguns destes artefatos, incluindo o Modelo de Domnio, o Modelo de Casos de Uso e o Modelo de Projeto. Os exemplos de artefatos apresentados neste estudo de caso no so, de forma alguma, suficientes, ou adequados, para todos os projetos. Por exemplo, em um sistema de controle de mquinas, pode ser benfico fazer muitos diagramas de estado. Um sistema de comrcio eletrnico baseado na Web pode exigir um foco em prottipos da interface com o usurio. O desenvolvimento de um projeto em um campo totalmente novo tem necessidade de artefatos de projeto bem diferentes daqueles de um projeto de integrao de sistemas. Tabela 2.1 Amostra dos artefatos de uma Pasta de Desenvolvimento do PU - iniciar; r - refinar 2.6 OPU gil

Os metodologistas se referem aos processos como pesados versus leves e preditivos versus adaptativos. Um processo pesado um termo pejorativo que sugere um processo com as seguintes caractersticas [FowlerOO]: muitos artefatos criados em uma atmosfera burocrtica; ;:4 4 Pasta de desenvolvimento DESENVOLVIMENTO ITERATIVO E O PROCESSO UNIFIcADO 47 r rigidez e controle; Disciplina Artefato lteraoConcep o Cl Elabora o E1...En i 1 r r r i i i i i i r i r r Construo Transio CtI...Ctn TI...T2 r r r r r

Modelagem de Negcio IRequisitos

Modelo de Domnio Modelo de CasosdeUso 1 i i

Viso Especificaes Suplementares Glossrio Projeto Modelo de Projeto Documento de Arquitetura de Software Modelo de Dados Implementao Modelo de Implementao Gesto de Projeto Plano de Desenvol viment de Software Teste Modelo de Teste Ambiente Pasta de Desenvolvimento

4 UTILIZANDO UIVIL E 1AUROES

 planejamento detalhado, elaborado e de longo prazo; Um esi preditivo, em vez de adaptativo, de softi rativo, Um processo preditivo um processo que tenta planejar e prever as atividades mackO e alocaes de recursos (tais como pessoas) em detalhes, ao longo de um intervalo de tempo relativamente longo, tal como a maior parte do projeto. Processos preditivos desem normalmente tm um ciclo de vida em cascata ou seqencial - em primeiro lugar definindo todos os requisitos; em segundo, definindo um projeto detalhado; e, em terceiro, fazendo a implementao. Em contraste com isso, um processo adaptativo 2.8 Voc aceita a mudana como um fator inevitvel e positivo, encorajando uma adaptao flexvel; estes processos geralmente tm um ciclo de vida iterativo. Um processo gil Aqui s implica em um processo leve e adaptativo, com respostas rpidas s necessidades de que s1 mudanas. tendid Os autores do PU no tinham a inteno de que seu processo fosse pesado ou Vo preditivo, embora o grande conjunto de atividades e artefatos opcionais tenha, com- ple preensivelmente, levado alguns a ficarem com esta impresso. Ao contrrio, ele foi V concebido para ser aplicado no esprito de um processo gil - PU gil. A seguir, co m fazer isso: Prefira um pequeno conjunto de atividades e artefatos PU. Alguns projetos se be- Vo neficiaro mais do que outros, mas, como regra geral, procure mant-los simples. E Vo Uma vez que o PU um processo iterativo, requisitos e projetos no so comple- ter tados antes da implementao. Eles surgem de forma adaptativa ao longo de uma pr srie de iteraes, com base na realimentao obtida nas iteraes anteriores. No h um plano detalhado para todo um projeto. H um plano de alto nvel (chamado Plano de Fases) que estima a data de trmino do projeto e outros mar- Vo cos de referncia principais, mas ele no detalha os passos de granularidade fina qu

para se atingir tais marcos. Um plano detalhado (chamado de Plano de Iterao) Vo somente planeja a iterao a ser feita em seguida. O planejamento detalhado fei- de to de forma adaptativa, de iterao para iterao. Veja no Captulo 36 alguns cor mentrios sobre o planejamento iterativo de projetos e as justificativas para ado dessa abordagem. 1 Vo O estudo de caso enfatiza um nmero relativamente pequeno de artefatos, alm do desenvolvimento iterativo, dentro do esprito de um PU gil. rei 1 Vc 2.7 O Ciclo de Vida Seqencia! em Cascata m Contrastando com o ciclo de vida iterativo do PU, uma antiga alternativa o ciclo de u Vc vida seqencial, linear ou em cascata [Royce7O]. Na sua forma comum de utiliza- fa o, ele definia passos similares aos seguintes: 1. Esclarecer, registrar e comprometer-se com um conjunto de requisitos completo e fixo. 2. Projetar um sistema baseado nesses requisitos. alm de rea1iment despachar mltiph 3. Implementar o sistema, baseado no projeto. desses quatro fator

DESENVOLWMENEIO ITERAuVo E O PROCESSO UNIFICADO 49 Um estudo de dois anos relatado na Sloan Mana gement Review do MIT sobre projetos de software bem-sucedidos identificou quatro fatores comuns; o desenvolvimento iterativo, e no o processo em cascata, estava em primeiro lugar na lista [MacCormackol]. 5 Uma breve descrio de seus problemas e de como eles so diminudos pelo desenvolvimento iterativo apresentada no Captulo 37. 2.8 Voc Sabe Que No Compreendeu o PU Quando... Aqui so apresentados alguns sinais que indicam quando voc no compreendeu o que significa adotar o PU e o desenvolvimento iterativo segundo o esprito gil pretendido pelo PU. Voc pensa que concepo = requisitos, elaborao = projeto e construo = implementao (isto , sobrepe um ciclo de vida em cascata no PU). Voc pensa que a finalidade da elaborao definir completa e cuidadosamente os modelos, os quais so traduzidos em cdigo durante a construo. Voc tenta definir a maior parte dos requisitos antes de comear o projeto ou a implementao. Voc tenta definir a maior parte do projeto antes da comear a implementao;

tenta defini-lo completamente e se comprometer com uma arquitetura antes da programao e de testes iterativos. Um longo tempo gasto fazendo um trabalho de anlise de requisitos ou de projeto antes que a programao comece. Voc acredita que a durao da iterao adequada de quatro meses, em vez de quatro semanas (exceo feita a projetos com centenas de desenvolvedores). Voc pensa que as atividades de diagramao UML e projeto so um tempo para definir completa e precisamente projetos e modelos com grande detalhe, e v a programao como uma traduo simples e mecnica daqueles para cdigo. Voc pensa que adotar o PU significa fazer muitas das possveis atividades e criar muitos documentos, ficando com a opinio, com relao a suas experincias com o PU, que este um processo formal, meticuloso demais, com muitos passos a serem seguidos. Voc tenta planejar um projeto em detalhes do comeo ao fim; tenta especulativa- mente prever todas as iteraes e o que deveria acontecer em cada uma. Voc quer ter planos e estimativas confiveis para os projetos antes de terminar a fase de elaborao. Os outros eram: 2) pelo menos uma incorporao diria de um cdigo novo na construo de um sistema completo, alm de realimentao rpida sobre as mudanas no projeto (via testes); 3) uma equipe com experincia em liberar e despachar mltiplos produtos; e 4) um foco precoce na construo e comprovao de uma arquitetura coesiva. Trs, desses quatro fatores, so prticas explcitas do PU. 50 UTILIZANDO UML E PADRES 2.9 Leituras Adicionais Uma introduo de fcil leitura ao PU e seu refinamento, o RUP, The Rational Unified Process - An Introduction, de autoria de Philippe Kruchten, arquitetochefe do RUP. Uma descrio do PU original pode ser encontrada em Unfied Software Development Process, de autoria de Jacobson, Booch e Rumbaugh. Ela vale a pena ser estudada, mas recomendamos antes a leitura da introduo de Kruchten, j que menor e mais sucinta, e o RUP atualiza e refina o PU original. A Rational Software vende o produto da documentao on-line do RUP baseado em Web, o qual fornece um conjunto de textos abrangentes sobre os artefatos e as atividades do RUP, bem como gabaritos para a maioria dos artefatos. Para uma breve discusso, veja o Captulo 37. Uma organizao pode executar um projeto PU usando apenas consultores e livros como recursos para o aprendizado, mas outras organizaes acham o produto RUP til como um recurso para auxiliar o aprendizado e a utilizao do processo. As atividades do PU so tambm genericamente descritas em uma srie de livros editados por Ambler e Constantine (por exemplo, The Unfied Process:

Elaboration Phase [AmblerOO]). Estes livros contm reimpresses de artigos publicados ao longo dos anos na revista Software Development, categorizados por sua respectiva fase e atividade em termos da nomenclatura definida pelo PU. Note que os artigos no foram originalmente escritos para PU, embora contenham muitos conselhos e orientaes teis. Perceba um pequeno erro nessa srie: eles descrevem a fase de elaborao do PU como uma fase na qual so criados prottipos descartveis, dessa forma reduzindo a necessidade de ateno e cuidado na programao ou projeto. Isto no exato; durante a elaborao so criados (embora de forma parcial) projetos e cdigos de qualidade final. Ambler reconhece essa impreciso e pode corrigi-la em uma edio subseqente. 6 Para saber mais sobre outros mtodos geis, recomendamos a srie de livros Extreme Programming (XP) [BeckOO, BFOO, JAH0O], tal como Ext reme Programming Explained. Algumas prticas da XP so mencionadas nos captulos posteriores. A maior parte das prticas da XP (como programao com teste a priori - test-first programming - e desenvolvimento iterativo) compatvel - ou idntica - com as prticas do PU, sendo encorajada sua adoo em um projeto PU. Note que a XP no inventou (e nem alegou t-lo feito) o desenvolvimento iterativo e adaptativo em janelas de tempo curtas, prtica utilizada no PU e em outros mtodos iterativos h anos. Diferenas de interesse - esta no uma lista completa - entre o PU e a XP so: 1) o PU recomenda escrever os casos de uso incrementalmente e um documento de requisitos no funcionais (a XP no); e, 2) o PU recomenda mais tempo para a diagramao visual do projeto (como meio dia ou um dia inteiro) prximo do incio de uma iterao, antes da programao principal. Os lderes da XP recomendam muito pouco, algo como 30 minutos. Highsmith fornece uma justificativa sobre o valor do desenvolvimento adaptativo em Adaptive Software Development [Highsmithoo]. 6Ambler, comunicao particular. do piaas rePU as go tido Introduo de o Este capitulo descreve o estudo de caso usado neste livro. Se voce ja compreende o domnio do problema, este captulo pode ser pulado. De fato, este problema foi esco lhid porque ele bem conhecido, mas apresenta dificuldades interessantes de projeto e arquitetura, permitindo, desta forma, que nos concentremos em como fazer a anlise e o projeto. 3.1 O Sistema PDV ProxGer

e- Nosso caso a prxima gerao do Sistema de Pontos-de-Venda (PDV ProxGer). s. Neste domnio de problema aparentemente simples, veremos que existem dificuldao des muito interessantes de requisitos e de projeto a serem vencidas. Alm disso, um i- problema realista; a maioria das organizaes, de fato, desenvolvem sistemas PDV a- usando tecnologias de objetos. na Um sistema PDV uma aplicao computadori zad usada (em parte) para registrar vendas e cuidar de pagamentos (muito utilizado por lojas de varejo). Inclui componentes de hardware, como um computa do e um leitor de cdigo de barras, e um software pa r rodar o sistema. Tem interfaces com vrias aplica e de servio, como uma aplicao de clculo de im posto e uma aplicao de controle de estoque. Estes sistemas devem ser relativamente tolerantes a falhas; 1 Estudo de Caso: o Sistema PDV ProxGer Poucas coisas so mais difceis de encontrar do que um bom exemplo. 3 - Mark Twain 52 UTILIZANDO UML E PADRES ou seja, mesmo se os servios remotos estiverem temporariamente no disponveis (como o sistema de controle de estoque), eles devem ser capazes de capturar as vendas e tratar pelo menos os pagamentos em dinheiro (de modo que o negcio no seja muito afetado). Um sistema PDV deve dar suporte de forma incremental a mltiplos e variados terminais e interfaces no lado do cliente. Estes incluem um terminal fino baseado em navegador da Web, um computador pessoal comum com uma interface de usurio grfica, como Java Swing, entrada de informaes por telas sensveis ao toque, PDAs sem fio, etc. Alm disso, vamos criar um sistema PDV comercial que venderemos a diferentes clientes com necessidades diferentes em termos de processamento de regras de negcios. Cada cliente desejar um conjunto nico de lgica de negcios para ser executado em pontos previsveis no cenrio de utilizao do sistema, como quando uma nova venda iniciada ou quando uma nova linha acrescentada. Portanto, necessitaremos de um mecanismo que fornea esta capacidade de flexibilidade e personalizao. Usando uma estratgia de desenvolvimento iterativo, executaremos a anlise de requisitos, a anlise orientada a objetos, o projeto e a implementao. 3.2 Arquitetura em Camadas e nfase do Estudo de Caso

Um tpico sistema de informao orientado a objetos projetado com uma arquitetura de vrias camadas ou subsistemas (ver Figura 3.1). A lista a seguir no completa, mas serve como exemplo: Interface do usurio - interface grfica; janelas. Lgica da aplicao e objetos do domnio - objetos de software representando conceitos do domnio (por exemplo, uma classe de software denominada Venda) que satisfazem os requisitos da aplicao. Servios tcnicos - objetos e subsistemas de uso geral que fornecem servios tcnicos de apoio, como interfaces com bancos de dados ou registro de erros. Esses servios so usualmente independentes da aplicao e reutilizveis por vrios sistemas. A A/POO muito importante para a modelagem da lgica da aplicao e das camadas de servio. O estudo de caso ProxGer destaca, principalmente, os objetos do domnio do problema, alocando responsabilidades aos mesmos para satisfazer os requisitos da aplicao. O projeto orientado a objetos tambm aplicado para criar um subsistema de servio tcnico para fazer a interface com um banco de dados. Nesta abordagem de projeto, a camada da TU (Interface do Usurio) tem uma respon- sabilidade pequena; dizemos que ela fina ou leve (thin). As janelas no contm cdigo que executa lgica ou processamento da aplicao. Ao contrrio, as solicitaes de tarefas so repassadas para outras camadas. 52 IJTTUZANDO LJML E FADRES ou seja, mesmo se os servios remotos estiverem temporariamente no disponveis (como o sistema de controle de estoque), eles devem ser capazes de capturar as vendas e tratar pelo menos os pagamentos em dinheiro (de modo que o negcio no seja muito afetado). Um sistema PDV deve dar suporte de forma incremental a mltiplos e variados terminais e interfaces no lado do cliente. Estes incluem um terminal fino baseado em navegador da Web, um computador pessoal comum com uma interface de usurio grfica, como Java Swing, entrada de informaes por telas sensveis ao toque, PDAs sem fio, etc. Alm disso, vamos criar um sistema PDV comercial que venderemos a diferentes clientes com necessidades diferentes em termos de processamento de regras de negcios. Cada cliente desejar um conjunto nico de lgica de negcios para ser executado em pontos previsveis no cenrio de utilizao do sistema, como quando uma nova venda iniciada ou quando uma nova linha acrescentada. Portanto, necessitaremos de um mecanismo que fornea esta capacidade de flexibilidade e personalizao. Usando uma estratgia de desenvolvimento iterativo, executaremos a anlise de requisitos, a anlise orientada a objetos, o projeto e a implementao. 3.2 Arquitetura em Camadas e nfase do Estudo de Caso Um tpico sistema de informao orientado a objetos projetado com uma arquitetura de vrias camadas ou subsistemas (ver Figura 3.1). A lista a seguir no completa, mas serve como exemplo: Interface do usurio - interface grfica; janelas.

 Lgica da aplicao e objetos do domnio - objetos de software representando conceitos do domnio (por exemplo, uma classe de software denominada Venda) que satisfazem os requisitos da aplicao. Servios tcnicos - objetos e subsistemas de uso geral que fornecem servios tcnicos de apoio, como interfaces com bancos de dados ou registro de erros. Esses servios so usualmente independentes da aplicao e reutilizveis por vrios sistemas. A A/POO muito importante para a modelagem da lgica da aplicao e das camadas de servio. O estudo de caso ProxGer destaca, principalmente, os objetos do domnio do problema, alocando responsabilidades aos mesmos para satisfazer os requisitos da aplicao, O projeto orientado a objetos tambm aplicado para criar um subsistema de servio tcnico para fazer a interface com um banco de dados. Nesta abordagem de projeto, a camada da TU (Interface do Usurio) tem uma responsabilidade pequena; dizemos que ela fina ou leve (thin). As janelas no contm cdigo que executa lgica ou processamento da aplicao. Ao contrrio, as solicitaes de tarefas so repassadas para outras camadas. EsTuDo DE CASO: O SISTEMA PDV PR0xGER 53 IU!JJf\JL f55f Item 1D Quantidade foco menor Interface explora como fazer rEntrar item a conexo com outras camadas foco primrio do camada de logica estudo de caso da aplicao 1 Venda Pagamento e objetos - explora como do domnio ._-- projetar objetos foco ___________________ ______________________ secundrio camada de servios tcnicos L Registro FachadaPersistente explora como projetar objetos Figura 3.1 Exemplo de camadas e objetos em um sistema orientado a objetos e o foco do estudo de caso. 3.3 A Estratgia do Livro: Desenvolvimento e Aprendizado Iterativos Este livro segue uma estratgia de desenvolvimento iterativo. A A/POO aplicada ao sistema PDV ProxGer em mltiplas iteraes; a primeira trata de algumas funes centrais. As iteraes posteriores expandem a funcionalidade do sistema (ver Figura 3.2). Em conjunto com o desenvolvimento iterativo, a apresentao dos tpicos de anlise e projeto e a notao UML, os padres so

introduzidos iterativa e incrementalmente. Na primeira iterao, apresentado um conjunto central de tpicos da anlise, de projeto e da notao UML. A segunda iterao introduz novas idias, notaes UML e novos padres. E, assim, de modo anlogo, a terceira iterao. analise e projeto Introduz habilidades relacionados com adicionais de anlise a iterao 1. e de projeto. De modo anlogo Figura 3.2 A trajetria de aprendizado segue as iteraes.