de Desenvolvimento Capítulo Introdução - Alinhando Metodologia com Arquitetura

Transcrição

1 A6Entendend a Metdlgia de Desenvlviment Capítul 5 Intrduçã - Alinhand Metdlgia cm Arquitetura N capítul anterir vims cm a arquitetura de base prpsta pel jcmpany pde ser utilizada cm catalisadra para a definiçã de uma Arquitetura de Sistemas Crprativa (ASC) madura, cm alt nível de autmaçã através de generalizações abrangentes. Psicinams este tip de sluçã de sftware cm hrizntal pr reslver prblemas cmuns a várias verticais de negóci, dentr de um prtifóli típic de aplicações. Já nss tema deste capítul, a Metdlgia de Desenvlviment de Sistemas (MDS), se desenvlverá em trn de práticas e padrões para a cnstruçã da parte vertical da sluçã - u seja, da sluçã de negóci em si. O ideal é que uma MDS recnheça nível de abstraçã e de generalizaçã dispníveis na ASC, e que a cmplemente, timizand práticas de especificaçã e cnstruçã. Este ideal pde nã se manifestar na prática pr dis mtivs: Arquitetura Invisível u Anêmica. Analistas e/u desenvlvedres prjetand e cnstruind camadas hrizntais de sftware em aplicações de negóci, simplesmente pr insuficiência na padrnizaçã e autmaçã em nível da arquitetura. Metdlgias Invisíveis u Anêmicas. Metdlgias inexistentes (desenvlviment artesanal, a sabr das qualidades individuais de cada prfissinal) u us de MDS genéricas mal cntextualizadas que, pr exempl, descnhecem a arquitetura. Discutims primeir mtiv n capítul anterir. Vejams entã segund. O us de práticas de mdelagem, especificaçã e cnstruçã genéricas de mercad (cm variantes d Prcess Unificad e Design Patterns Java), sem adaptações que as cntextualizem para recnheciment da Arquitetura de Sftware Crprativa presente, levam s prfissinais a prjetarem e a cnstruírem em excess, cm mair esfrç e menr eficácia. Uma sequela típica de MDS desalinhada cm ASC sã especificações prlixas que nã recnhecem s estereótips da arquitetura e que, pr iss, além de serem mais custsas para serem btidas, cmunicam mal. Para máxim de resultads, é imprescindível que a Arquitetura de Sistemas Crprativa seja tã autmatizada quant pssível e recnhecida pela Metdlgia de Desenvlviment de Sistemas. Deste md, analistas e/u desenvlvedres pdem calibrar melhr nível de abstraçã de seu trabalh, tant n prjet quant na implementaçã - evitand desperdícis e maximizand reús. D pnt de vista da especificaçã, jcmpany traz um módul chamad jcmpany Patterns & Methds, que prpõe padrões e práticas de especificações de Cass de Us, Mdelagem de Classes, Prcesss Ágeis, dentre utrs. É um módul representad pr dcumentaçã extensa, smente dispnível cm a licença crprativa d prdut. D pnt de vista da cnstruçã, jcmpany traz rteirs autmatizads através d recurs de Cheat- Sheets d Eclipse, além de plugins que geram versões que bedecem a padrões cncebids na metdlgia. Tal cm n cas análg, da arquitetura, s métds e padrões prpsts pel jcmpany Patterns & Methds devem servir de base para a definiçã de uma MDS crprativa, devend ser cnsiderads cm insums reutilizáveis para este trabalh.

2 Capítul A5 Especificações baseadas em metdlgias genéricas de mercad, mal cntextualizadas, sã um ds maires prblemas enfrentads pels mdels Fábricas de Sftware atuais. Nã é incmum que empresas adquiram a sua base de arquitetura de um fabricante e as práticas de especificaçã de utr este us pasteurizad da mdelagem de Classes, de Cass de Us e de padrões de interfaces Web termina pr subtrair imprtantes benefícis que smente uma abrdagem sinérgica pde ferecer. Prcesss de Desenvlviment de Sistemas Vams abrir uma pequena discussã sbre PDS, neste pnt, a guisa de estimular us de práticas mdernas que cntribuam para nss sucess *. - Definiçã Na Wikipedia, um Prcess de Desenvlviment de Sistemas (PDS) é definid cm a estrutura impsta a desenvlviment de um prdut de sftware. Uma empresa que queira eliminar nã cnfrmidades e refrçar melhres práticas de prdutividade deverá definir atividades, respnsabilidades, métds, ferramentas e padrões para diversas fases d desenvlviment de sistemas em si e áreas de api relacinadas. Segund Prcess Unificad [Bch, Jackbsn, Rumbaugh 1998], as fases fundamentais de um PDS sã: Cncepçã (principalmente Levantament de Requisits) Elabraçã (principalmente Prjets Lógic e Físic) Cnstruçã (principalmente Cdificaçã e Testes Unitáris) Transiçã (principalmente Testes de Aceitaçã e Liberaçã para Prduçã) Os framewrks de prcess mais pesads e abrangentes irã incluir utras áreas tais cm Gerência de Cnfiguraçã, Garantia da Qualidade de Prcess e Prdut, Mediçã e Análise etc., além das áreas fundamentais. A Figura A6.1. Exempl das fases de um PDS mais abrangente.figura A6.1 exibe um gráfic cm esta visã mais abrangente, utilizad para representar td Gerenciament de Cicl de Vida de Aplicações (Applicatin Lifecycle Managment ALM). Figura A6.1. Exempl das fases de um PDS mais abrangente. Pr sua cmplexidade, quase nenhuma empresa define seu PDS inteiramente d zer, já que existem váris framewrks de base nesta área. Alguns exempls sã: Prcess Unificad (Unified Prcess - UP) já citad; e s mais recentes prcesss ágeis, tais cm SCRUM e XP, em larga ppularizaçã. Além destes, pdems citar s mdels de prcess mais abrangentes, tais cm CMMI, MPS.Br (n Brasil) e ISO * Esta pequena discussã se trna bem mais relevante na medida em que, muitas vezes, a adçã de prcesss inadequads está na raiz ds prblemas de prjet. Nã há sluçã de prdutividade que sbreviva a um PDS mdel Cascata, gerenciad cm práticas de cmunicaçã primitivas (ex.: frmalidades em papel!) e visa ignóbil acerca da natureza peculiar de um prjet de sftware.

3 Entendend a Metdlgia de Desenvlviment - Metdlgia u Prcess? Neste livr, irems adtar alguns jargões preferenciais: Metdlgia de Desenvlviment de Sistemas (MDS) quand quiserms ns referir a um espectr mais restrit de disciplinas, limitad às fases de Cncepçã, Elabraçã, Cnstruçã e Transiçã de um Prcess de Desenvlviment de Sistemas (PDS). Prcesss de Desenvlviment de Sistemas (PDS) quand quiserms ns referir a um espectr mair, englband áreas adicinais cnfrme identificadas pr framewrks de prcess tais cm CMMI, ISO u MPS.Br. Pr exempl, Gerência de Cnfiguraçã, Mediçã e Análise, Garantia da Qualidade de Prdut e Prcess etc. O jargã d Prcess Unificad (UP) [Bck, Jacbsn, Rumbaugh 1998] quand falarms em métds, fases e alguns padrões de especificaçã. A UML - Unified Mdeling Language [Pender, Tm] quand assunt fr mdelagem e especificaçã de sistemas. A esclha destes jargões é meramente pr cnveniência, já que sã s mais difundids n mercad. Nã há nenhuma restriçã específica das sluções de desenvlviment que apresentarems, cm relaçã a us de métds ágeis, pr exempl, u quaisquer utras abrdagens cnvencinais. - Prcesss Iterativs x Prcess em Cascata Um pnt-chave na adçã de um prcess é cmpreender cm ele sugere a distribuiçã das suas práticas a lng d temp. Pr este critéri pdems classificar um prcess cm enfatizand um desenvlviment em Cascata (Waterfall Prcess) u Iterativ (Iterative Prcess). Sabems que Prcesss em Cascata, apesar de serem s mais cmuns em utras engenharias, sã pires para desenvlviment de Sftware. Fats que crrbram esta tese sã clecinads desde a década de 80 e gerads até s dias de hje. Praticamente td livr e artig em Prjet de Aplicações, ns últims 15 ans u mais, tem criticad desenvlviment em cascata. (...) Eles funcinam bem quand s requisits sã facilmente garimpads e raramente mudam. Infelizmente, cm a tônica é a mudança ns negócis, tais situações sã cada vez mais raras. Ref. A6.1. Peter Bye e Cris Brittn em IT Architectures and Middleware. Pág Mas, apesar de sua ineficácia ser hje de um cnsens geral, mdel em cascata é, de frma acidental, ainda mais utilizad! Acidental prque, na prática, tem, muitas vezes, sid utilizad desta frma incnscientemente, especialmente pr grandes empresas que trabalham cm terceirizaçã de prjets e equipes distribuídas gegraficamente. O Prcess Unificad é um exempl típic de Prcess Iterativ que muit frequentemente se transfrma em Cascata quand implantad - e assim é subutilizad n dia a dia pr culpa de custmizações mal feitas. E qual seriam s mtivs desta distrçã? Os prcesss em cascata sã mais simples de se entender pr serem s mais cnhecids pela humanidade nas engenharias clássicas. Qualquer estudante irá cmpreender uma analgia ds Prcesss de Desenvlviment de Sistemas cm s Prcesss da Engenharia Civil, pr exempl simplificaçã que cntribui para manter atras cultural nas áreas de TI desde s ans 70. Este tip de analgia, perigsamente didática, nã expressa de frma aprpriada a natureza única d sftware, um bem invisível, abstrat e de simulaçã da dinâmica de negócis. É uma natureza que requer um paradigma diferenciad, atualmente melhr representad pr métds Iterativs e Ágeis. A nçã de requisits-prjet-implementaçã em cascata é tã intuitivamente crreta... O que pde estar errad cm ela? Na prática, existem três prblemas principais. Primeir, s usuáris finais e de negóci nã cnhecem seus requisits, sã incapazes de expressá-ls cm rigr suficiente u, até pir, têm requisits cntraditóris. Intrduzir uma nva aplicaçã de TI muda trabalh das pessas e elas têm dificuldade de visualizar que é precis para nv sistema funcinar. (...) O segund prblema é a dificuldade de expressar a especificaçã de uma maneira cmpreensível e utilizável pr ambs, prgramadr (...) e s patrcinadres d negóci (...) O terceir prblema é que a divisã de respnsabilidades entre requisits, especificaçã (prjet) e implementaçã leva a excess de engenharia. Ist é particularmente verdadeir em grandes rganizações, nde um grup especifica requisits e utr faz prjet e a implementaçã. Ref. A6.2. Peter Bye e Cris Brittn. IT Architectures and Middleware. Pág Pr tds estes mtivs, nã há hje estudiss na área de TI u nenhum framewrk de prcess que precnize mdel Cascata. O que existe, prém, sã implantações imperfeitas de prcesss Iterativs cm citams, ressaltand cas d Prcess Unificad. Aplicads desta frma, tais

4 Capítul A5 prcesss trazem s mesms resultads medícres já cnhecids da épca da Engenharia da Infrmaçã. Cm diz ditad: É insensatez querer fazer alg sempre da mesma frma e esperar pr resultads diferentes Ref. A6.3. Atribuíd a Albert Einstein A Figura A6.2. Diagrama d Prcess Unificad, destacand em branc uma iteraçã.mstra um esquema simplificad cm relaçã à Figura A6.1. Exempl das fases de um PDS mais abrangente., evidenciand aspect iterativ d Prcess Unificad. Figura A6.2. Diagrama d Prcess Unificad, destacand em branc uma iteraçã. N diagrama clássic d UP, uma iteraçã é representada graficamente através ds mntinhs, que sugerem a intensidade da crrência de uma determinada disciplina em cada fase. Nte que, na iteraçã #2 destacada durante a fase de Elabraçã, além de análise e prjet, sã esperadas bas quantidades de trabalhs simultânes de implementaçã (cdificaçã de prgramas) e inclusive de testes! Cm fazê-l em mdels clássics de fábricas de sftware? - Prcesss Iterativs e Fábricas de Sftware Além ds três prblemas citads pr Peter Bye e Cris Brittn, há um quart prblema que pdems acrescentar, certamente de grande pes: As empresas têm decidid pr adtar prcesss em Cascata cm sluçã cmercial para viabilizar cntrats em preç fechad para terceirizaçã da fase de Cnstruçã, pr três mtivs: 1. Cmplexidade da Cnstruçã em ebusiness. A fase de Cnstruçã trnu-se expnencialmente mais cmplexa d que era em gerações passadas, distanciand ainda mais s Analistas de Negóci de um ambiente nde pssam prttipar e explrar s resultads de levantament, aprendend sbre a sluçã juntamente cm seus usuáris. 2. Mair cntrle cntratual para diminuiçã de custs e riscs. Gestres financeirs anseiam pr mais cntrle sbre s cntrats de TI, visand reduçã de custs e riscs, e muitas vezes nã aceitam desenvlvedres de terceirs alcads a lad de seus Analistas de Negóci. 3. Melhrar a prdutividade via especializaçã de funções. A mesma cmplexidade bservada n item 1 pde ser amenizada cm pessal especializad em tecnlgias específicas. Mas fat é que mdel cntratual de terceirizaçã em preç fechad dificulta tremendamente a instauraçã de um prcess verdadeiramente iterativ: Exige uma grande visã de prjet antecipada, para efeits de cntrataçã (Análise Big-Bang ); Prduz dificuldades cntratuais que degradam a adaptabilidade (cntrles de mudança rigrss, que inibem a agilidade); Gera prblemas séris de cmunicaçã que embtam a clabraçã (analistas cntra desenvlvedres); E, que é pir, elimina cntext necessári para se evluir uma sluçã da frma ideal, desde a sua Cncepçã, que exige graus de prgramaçã durante a cncepçã e de análise de requisit durante a cnstruçã em um cenári de explraçã e adaptaçã cntínuas.

5 Entendend a Metdlgia de Desenvlviment Cm jcmpany pde cntribuir, inserid neste cntext? 1. Cmplexidade da Cnstruçã em ebusiness. Neste sentid, jcmpany pderá ajudar decisivamente, pis as práticas de alta prdutividade ensinadas neste livr viabilizam retrn de uma prttipaçã cm aprveitament psterir d códig, mesm se tratand de aplicações cmplexas de ebusiness utilizand Java EE e MVC. Se há um cenári de requisits instáveis e tds s utrs elements que requerem um desenvlviment iterativ estã presentes, s Analistas de Negóci u Prjetistas treinads cnseguirã usar jcmpany mesm em fases iniciais d prcess (Cncepçã u Elabraçã) para realizar prttipações-chave para elicitaçã de requisits, junt as usuáris. Iss prque nã precisarã de cnheciments prfunds em Java, Java EE, HTML, Javascript, CSS etc., para apresentar resultads cm razável prfundidade. Esta é uma pssibilidade que deve ser explrada e pde ser decisiva para sucess de um grande númer de prjets de TI de natureza desafiadra! 2. Mair cntrle cntratual para diminuiçã de custs e riscs. Este é um mit. Nã há cntrat que cmpense s prejuízs que um prcess inadequad, em Cascata, pssa prduzir. E este prcess inadequad, pr si, intrduz e anabliza riscs, cm muitas empresas cntinuam cnstatand. A prdutividade e qualidade liberadas pel jcmpany pssibilitam entregas de prdut apresentável as usuáris em iterações de semanas, nã meses. Eis aí uma fórmula que, cmprvadamente, cntribui para reduzir cust e riscs. 3. Melhrar a prdutividade via especializaçã. Quant mais se generaliza sluções repetitivas para arquiteturas ricas e utilizam-se gerações de códig suplementares, mens trabalh braçal, típics de manufatura, restam as Desenvlvedres. Em jcmpany, restam para s desenvlvedres mais atividades de prjet d códig fnte, u seja, trabalh inteligente; e mens atividades d tip replicar a fôrma de códig, u seja, trabalh braçal. Neste cenári, seria mais aprpriad chamar s desenvlvedres de c-prjetistas u prjetistas de códig e nã de implementadres. E cm trabalham em mais alt nível, a aprximaçã entre desenvlvedres jcmpany ( Prjetistas de Códig ) e Analistas de Negóci ( Prjetistas de Cas de Us ) deve ser estimulada, pdend inclusive ser decisiva para sucess de prjets cmplexs. - Práticas para Especificaçã - Prjet Lógic e Físic O módul jcmpany Patterns & Methds traz material que discute, mais a fund, sugestões para a fase de Elabraçã (Prjets Lógic e Físic), dand subsídis para a criaçã de práticas de mdelagem eficazes que cmuniquem bem e prduzem mdels que se preservem atualizads a lng d cicl de vida de uma aplicaçã. Algumas ações sugeridas sã: Autmaçã bidirecinal, cm geraçã de classes a partir de mdels e de mdels a partir de classes; A eliminaçã de hiats de mdelagem (várias camadas de mdels e de transfrmações MDA desnecessárias); E estabeleciment de estereótips cm base na UML, que prduzam uma cmunicaçã direta cm relaçã a abstrações da arquitetura, padrões e práticas de cnstruçã d jcmpany. Neste capítul e ns próxims, irems apenas apresentar cnceits básics suficientes para entenderms as especificações que encntrarems ns tutriais d módul B. - Práticas para Cnstruçã Java EE Esta é a área principal de fc d jcmpany. Sua prdutividade diferenciada advém, principalmente, da padrnizaçã de sluções em um patamar de abstraçã mais alt que qualquer utr framewrk u ferramenta de desenvlviment. Os padrões em nível de Cas de Us autmatizads pel jcmpany permitem a desenvlvedr, em questã de minuts - nã hras u dias, prduzir sluções MVC2-P cmpletas e flexíveis para um bm percentual de prblemas típics de aplicações cmerciais cm qualidade de prduçã! E esta alegaçã nã é puca cisa: se smarms resultad de tds tutriais encntrads ns livrs de Hibernate/JPA, JSF, JBss Seam, Spring e Eclipse, pr exempl, que fazem parte de nssa referência bibligráfica, nã bterems um resultad funcinal que chegue à metade d que prduzirems neste livr. Este resultad, inicialmente, deve-se a fat de jcmpany trabalhar reutilizand s benefícis da mairia destes prduts. Mas, além diss, também se deve a elevad nível de especializações e padrnizações presentes nas diversas dimensões de arquitetura, métds, padrões e técnicas de autmaçã.

6 Capítul A5 Mantend Agregações de Objets - Agregações de Objets Entender cnceit de Agregaçã de Objets é fundamental para a intrduçã as Cass de Us Padrões d jcmpany que verems inicialmente. Prtant, irems recapitular este cnceit de OO, tmand cm base Mdel de Classes da Figura A6.3. Figura A6.3. Mdel de Classe de Exempl *. O trech acima é um recrte de um mdel mair que utilizarems neste livr, representand um graf cujs vértices sã classes e as arestas sã assciações. Chamarems a este recrte, prtant, de Graf de Classes, n qual pdems identificar 3 vértices e 2 arestas. 3 (três) classes: Uf, UnidadeOrganizacinal e Enderec. 1 (uma) agregaçã de classes: Entre UnidadeOrganizacinal e Enderec. 1 (uma) assciaçã Simples: Entre Enderec e Uf. Estas classes definem estruturas pssíveis de dads, mas sã s bjets u instâncias destas classes que irã cnter s dads em si durante a execuçã de uma aplicaçã e cmpr s frmuláris de nssa aplicaçã visíveis para usuári, que representam dcuments eletrônics de negóci. Tal cm n graf de classes, estes bjets se relacinam cnfrme a estrutura definida pelas classes, variand cnfrme estad (situaçã crrente) da aplicaçã. A Figura A6.4 representa um Graf de Objets hiptétic para uma pssível cnfiguraçã de bjets, em um determinad mment de execuçã da aplicaçã. Pdems cmpreender este diagrama, de frma análga, cm um Graf de Objets, que representa instâncias d Graf de Classes que define. * Este diagrama traz um mix de mdelagem diferente ds tradicinais. Perceba que usa tips Java juntamente cm restrições e perações em nível cnceitual. Os tamanhs (multiplicidade) de prpriedades também sã atípics, além de diverss estereótips. Este tip de padrã é descrit na dcumentaçã d jcmpany Patterns & Methds

7 Entendend a Metdlgia de Desenvlviment Figura A6.4. Graf de Objets hiptétic em um determinad estad da aplicaçã. Na Figura A6.4, seccinams únic graf frmad pr td mdel em três subgrafs, para fins didátics, prque nrmalmente sã estes subgrafs que cmpõem a estrutura de um dcument típic de negóci (u frmulári da aplicaçã), cm pde ser cnferid na Figura A Grafs de Objets x Agregações de Objets Quand falams em Manutençã d Cicl de Vida é cmum visualizarms inicialmente um frmulári, digams, d tip Manter Funcinári, mantend dads de um únic bjet. Mas cm uma aplicaçã real em mãs descbrirems que Manutenções de Cicl de Vida típicas nã raramente lidam cm grafs de cinc a dez bjets de uma só vez, mdificand alguns e cnsultand utrs. Tais grafs pdem envlver ainda arquivs anexads, auditria rígida (imagem de dads alterads) e utras sfisticações em um cenári bem mais cmplex que nssa abstraçã inicial. Vams pegar um exempl bem simples: Quand delimitams grafs e agregações de bjets na Figura A6.4, a hipótese é a de que estams realizand manutençã sbre bjets de UnidadeOrganizacinal (Departaments, cm rtulads n frmulári abaix) e Enderec, e cnsultand bjets de UF. Veja exempl n frmulári da Figura A6.5. Figura A6.5. Exempl de frmulári pssível para manter esquema de bjets da figura 4. Aqui retrnams a nss pnt inicial para estabelecerms algumas cnvenções de nmenclatura e mdelagem OO imprtantes: Frmuláris d negóci lidam nã cm um bjet, mas cm um Graf de Objets. Já um Graf de Objets é um crte d Mdel de Objets envlvid em uma transaçã, exemplificads na Figura A6.4 pels Subgrafs 1, 2 e 3. Pr sua vez, uma Agregaçã de Objets é aquele subcnjunt de bjets d Graf, mdificads simultaneamente, exemplificads na Figura A6.4 pelas Agregações 1, 2 e 3. As classes UnidadeOrganizacinal e Enderec sã partes de uma mesma agregaçã de classes/bjets, mas nã Uf. N entant, Uf participa d mesm Graf de Objets utilizad n frmulári de Manutençã de Departaments ( UnidadeOrgacinal ).

8 Capítul A5 Esta cmpreensã ns ajudará a especificar de frma simples e bjetiva um grande númer de Cass de Us, bem cmuns. - Autmatizand a Manutençã de Agregações de Objets Uma Agregaçã é um cluster de bjets assciads que nós tratams cm uma unidade para prpósit de mudanças de dads. Cada Agregaçã tem uma raiz e um cntrn. O cntrn define que está dentr da Agregaçã. A raiz é uma única Entidade, dentre as cntidas na Agregaçã, e a única para a qual bjets externs à agregaçã pdem manter referências Ref. A6.4. Eric Evans em Dmain-Driven Design [Evans, Eric 2004]. Págs O estereótip raiz agregaçã, utilizad na classe UnidadeOrganizacinal da Figura A6.3 e a linha pntilhada que delineia cntrn da Agregaçã fram baseads em sugestões de Evans. Esta e utras cnvenções de mdelagem sã discutidas n módul jcmpany Patterns & Methds. Existem diverss cmprtaments típics que caracterizam e devem ser assegurads para uma Agregaçã, send alguns: a excluir-se um bjet raiz, deve-se excluir tda a Agregaçã, deve-se refrçar restrições invariáveis para a Agregaçã cm um td. Váris destes cmprtaments sã expsts em [Evans, Eric 2004] e fgem a nss escp atual de discussã. Mas há uma sugestã bastante pertinente de Evans, que desejams citar: Pde ser de grande ajuda ter um framewrk técnic que permita a vcê declarar Agregações e entã autmaticamente garantir suas restrições. Sem este api, a equipe deve ter a autdisciplina para cdificar cnsistentemente cm as regras da Agregaçã Ref. A6.5. Eric Evans em Dmain-Driven Design [Evans, Eric 2004]. Pág Esta é uma das estratégias que jcmpany adta e realiza de frma bastante extensiva e interessante. O jcmpany permite que declarems em seus metadads, nã smente a estrutura da Agregaçã principal, cmpsta das classes que sfrem alterações em cnjunt, cm também td Graf de classes participante, incluind as classes de cnsulta. A partir daí, padrniza sluções e as generaliza cmpletamente em tdas as camadas MVC-P, a pnt de dispensar ttalmente us de códig prcedimental Java até um estági avançad. Além da parte prcedimental, a sluçã generalizada para Manutençã de Agregações d jcmpany ainda inclui padrões na camada Visã, prduzind Interfaces cm Usuári cm frmulári únic, pr Agregaçã *. Deste md, s frmuláris refletem de frma direta s dcuments de negóci cm ganhs tant em usabilidade quant em perfrmance e escalabilidade! Figura A6.6. Frmulári únic que mantém a Agregaçã Funcinari -> Dependente -> Hist. Prfissinal. * A quebrar, sem necessidade, a manutençã de uma Agregaçã em váris frmuláris de CRUD d tip mantém um bjet da agregaçã pr vez, exige-se d usuári que navegue pr várias páginas, prvcand dezenas de transmissões na rede e requisições a App Server desnecessárias (muitas vezes até transações de SGBD). Esta abrdagem de Web-Design é uma verdadeira abminaçã para aplicações crprativas multi-usuári, cm entrada de dads massiva.

9 Entendend a Metdlgia de Desenvlviment - Generalizand Manutenções em Arquitetura MVC Além de lidar cm Agregações cmplexas e prduzir frmuláris cm ergnmias aprpriadas, utr cmplicadr para generalizaçã das Manutenções de Cicl de Vida é fazê-la respeitand-se a arquitetura MVC. Em Cliente/Servidr, fazíams um CRUD de frma muit simples, ligand camps de janelas a clunas de tabelas n Banc de Dads. Iss ainda é pssível em Java EE (e muitas vezes exemplificad até em livrs recentes d JSF u JBss Seam, pr exempl), mas fat é que nã querems retrceder nesta área: a arquitetura MVC é hje aceita cm pauta mínima de arquitetura. O jcmpany realiza um trabalh de generalizaçã em tdas as camadas MVC2-P para autmatizar resultad de um Cas de Us pr cmplet (pr iss framewrk é chamad de Full Stack), enquant mantém respeit a esta arquitetura. Figura A6.7. Sluções generalizadas em tdas as camadas MVC-P. Cass de Us Padrões d jcmpany - Cass de Us cm cenáris similares Alistair Cckburn, em seu livr Escrevend Cass de Us Eficazes [Cckburn, Alistair. 2003], discute que chama de Cass de Us CRUD e também Cass de Us Parametrizads. Os Cass de Us CRUD se referem à manutençã de cicl de vida de dcuments d negóci, englband funções de criaçã, recuperaçã, atualizaçã e exclusã (C-Create, R- Retrieve, U-Update e D-Delete) através de cenáris que puc u nada variam de dcument para dcument. Já s Cass de Us Parametrizads se referem às utras situações recrrentes e que pderiam levar a uma prliferaçã de cenáris quase idêntics, nde melhr exempl sã cnsultas para seleçã de dcuments d tip Encntrar um Cliente, nrmalmente envlvend uma entrada cm amstra de dads e subsequente pesquisa de relaçã resultante que atende as critéris. Tant n primeir quant n segund cas, s cenáris ds Cass de Us sã repetitivs. O que irá variar serã s dcuments especificamente adtads em cada cas. Prtant, para evitar esta redundância de especificaçã, prpõe Cckburn: Devems criar um cas de us parametrizad, que funcine cm um apelid para cada um destes itens. Esclhems chamar esse cas de us de Encntrar um <Qualquer>. (...) Ref. A6.6. Alistair Cckburn em Escrevend Cass de Us Eficazes. Pág Em seguida, Cckburn sugere que se definam smente as diferenças de cenáris (arguments e peradres a serem utilizads para pesquisa, camps retrnads etc.), em Subcass de Us, deste md prmvend a prática da Especificaçã pr Exceçã. Prsseguind em seu exempl sbre s Cass de Us Parametrizads: O cmprtament de pesquisa cmum é lcalizad e escrit apenas uma vez. A cnsistência entre mecanisms de prcura é garantida, (...). De fat, a equipe de implementaçã fi encrajada a dar apenas uma especificaçã para seu mecanism de pesquisa (...) Ref. A6.7. Alistair Cckburn em Escrevend Cass de Us Eficazes. Pág. 150.

10 Capítul A5 O que Alistair Cckburn sugere sã dicas para se eliminar trabalh de especificaçã repetitiva que estas duas categrias de Cas de Us tendem a prduzir, e é pr esta trilha que jcmpany caminha. Nã smente identificand cm mais detalhes estes Cass de Us Padrões n jcmpany Patterns & Methds, cm prvend generalizações avançadas via jcmpany FS Framewrk e, pr fim, gerand artefats específics para cada camada MVC-P, via jcmpany IDE. N jcmpany, esta primeira categria de Cass de Us CRUD é chamada, de frma mais extensa, de Cass de Us Padrões para Manutençã d Cicl de Vida de Agregações de Objets u, resumidamente, de Padrões para Manutençã. O jcmpany também padrniza e atende cm implementações genéricas s Cass de Us Parametrizads, chamads de Cass de Us Padrões para Exibiçã de Cleções de Agregações (Ex.: seleções, cnsultas e relatóris) u, resumidamente, Padrões de Exibiçã. Neste cas, através de simples declarações de arguments e peradres, jcmpany irá realizar um QBE (Query By Example) MVC-P, dispensand cdificaçã Java. - Padrões para Manutençã A prdutividade nas manutenções é btida através d us ds Padrões de Cas de Us relacinads na Figura A6.8. Figura A6.8. Cass de Us Padrões para Manutençã de Cicl de Vida. A tabela a seguir resume bjetiv de cada Cas de Us Padrã, que serã detalhads a lng ds próxims capítuls quand estarems implementand efetivamente váris deles. Cass de Us Padrões de Manutençã Primáris Manter Classe Manter Agregaçã Simples Manter Agregaçã Mestre/Detalhe Manter Agregaçã Mestre/Detalhe/SubDetalhe Representam as manutenções mais cmuns e independentes. Este Cas de Us prevê a manutençã de tds s bjets de uma classe, de uma só vez. Pr iss, smente deve ser utilizad em classes cm pucs bjets. Este Cas de Us prevê a manutençã de uma Agregaçã de Objets Simples, que nã envlva cmpsiçã d tip Mestre- Detalhe e variantes. Este Cas de Us prevê a manutençã de uma Agregaçã de Objets que inclua uma cmpsiçã d tip Mestre-Detalhe. Este Cas de Us prevê a manutençã de uma Agregaçã de Objets que inclua uma cmpsiçã d tip Mestre-Detalhe- SubDetalhe. Manter Cleçã Mdalidade A Este Cas de Us prevê a manutençã de um Cleçã de Objets de uma só vez, filtrads de uma classe mas que necessariamente nã referenciem bjets pré-existentes.

11 Entendend a Metdlgia de Desenvlviment Secundáris Manter Cleçã Mdalidade B Manter Agregaçã Cnsulta- Mestre/Mantém-Detalhe Manter Agregaçã Cnsulta- Mestre/Mantém-Detalhe- Subdetalhe Representam as manutenções cmplementares às primárias, que requeiram que classes raiz já existam e tenham sid mantidas pr utrs padrões anterirmente. Este Cas de Us prevê a manutençã de um Cleçã de Objets de uma só vez, filtrads de uma classe e que partem da seleçã de um bjet pré-criad, referenciad pela cleçã de bjets selecinada. Este Cas de Us prevê a manutençã de uma Agregaçã de Objets que inclua uma cmpsiçã d tip Mestre-Detalhe, nde Mestre (raiz da agregaçã) já tenha sid incluíd pr utr Cas de Us Padrã. Este Cas de Us prevê a manutençã de uma Agregaçã de Objets que inclua uma cmpsiçã d tip Mestre-Detalhe- Subdetalhe, nde Mestre (raiz da agregaçã) já tenha sid incluíd pr utr Cas de Us Padrã. Cass de Us Padrões de Manutençã Da Aplicaçã Manter Preferência de Aplicaçã Manter Preferência de Usuári (para a Aplicaçã) Representam Cass de Us que nã sã d negóci necessariamente, mas que sã cmuns a se criar uma aplicaçã. Nrmalmente crrem um de cada pr aplicaçã. Este Cas de Us prevê a manutençã de preferências glbais d respnsável (administradr) pela aplicaçã. Também cnhecids cm parâmetrs glbais. Este Cas de Us prevê a manutençã de preferências de cada usuári para a aplicaçã, pdend este registrar pções de persnalizaçã de us u utras que se façam necessárias. - Padrões para Exibiçã (Cnsulta e Impressã) Para exibiçã de infrmações, jcmpany também prevê dis Cass de Us Padrões, exibids na Figura A6.9. Figura A6.9. Cass de Us Padrões para Exibiçã. Cass de Us Padrões de Exibiçã Cnsultar Objets Cnsultar/Imprimir Objets Este Cas de Us prevê a cnsulta em frmat nã timizad para impressã (HTML, sem quebras) de cleções de grafs cntend infrmações de diverss bjets. Este Cas de Us prevê a cnsulta em frmat timizad para impressã (PDF, cm quebras) de cleções de grafs cntend infrmações de diverss bjets.

12 Capítul A5 Subcass de Us Padrões d jcmpany Cm vims, a padrnizaçã em nível de Cas de Us é um ds grandes alcances d jcmpany. Neste nível, padrã resulta nã em uma sluçã técnica, mas em um valr tangível para negóci. Pr iss, pdems chamá-l de padrã de última milha. Descend um puc mais em nível de detalhe, encntrarems variações típicas ds Cass de Us Padrões que nã pdem ser utilizadas de frma islada, mas sã padrnizadas pel jcmpany para cmpr cenáris mais cmplexs. Estas variações pdem ser cnsideradas Subcass de Us, cm chamads pr Alistair Cckburn [Cckburn, Alistair. 2003], se subdividind nas duas categrias típicas de Inclusã (Include) e Extensã (Extend). - Subcass de Us Padrões para Inclusã Os Subcass de Us Padrões para Inclusã sã aqueles que fazem parte de cenáris principais e que crrem de maneira síncrna, frequentemente exemplificads cm similares a sub-rtinas, reutilizadas pr váris Cass de Us. A Figura A6.10 ilustra s diverss Subcass de Us Padrões de Inclusã d jcmpany, relevantes para s Cass de Us Padrões de Manutençã. Figura A6.10. Subcass de Us Padrões para Inclusã. Subcass de Us Padrões para Inclusã Inclui Exclusã Lógica Este Subcas de Us prvê cenári adicinal para a exclusã, que deixa de ser física (eliminaçã da agregaçã) para se trnar uma alteraçã de prpriedade padrã sithistricplc de A (Ativ) para I (Inativ). Agregações nde sithistricplc= I sã entã cnsideradas excluídas para pnt de vista de usuáris. Inclui Auditria Rígida Este Subcas de Us prvê cenári adicinal para registrar bjets cntend imagens de dads alterads, incluíds u excluíds em utras classes espelh, para efeits de auditria. Inclui Auditria Recursiva Obs.: smente dispnível em versões anterires d jcmpany (3.x). Inclui Pesquisa Paginada Inclui Arquiv Anexad Inclui Aprvaçã Este Subcas de Us prvê cenáris adicinais que alteram a pesquisa de cleções cntend grafs de bjets para evitar que traga registrs em demasiad em seleções de bjet visand ediçã para manutençã, limitand a quantidade pr página. Este Subcas de Us prvê cenáris adicinais que permitem a anexaçã (uplad) de arquivs e sua recuperaçã (dwnlad) juntamente cm a agregaçã principal. Obs.: smente dispnível em versões anterires d jcmpany (3.x). Recmenda-se jcmpany Extensin para BPMS (BPMN 2.0) para fins de Wrkflw (Fluxs de Aprvaçã)

13 Entendend a Metdlgia de Desenvlviment - Subcass de Us Padrões para Extensã Um utr tip de reús padrnizad pel jcmpany abaix d nível de Cas de Us se dá cm extensões, que sã pções dispníveis para acinament assíncrn pel usuári e que, prtant, nã participam d cenári principal d Cas de Us. A Figura A6.11 ilustra s diverss Subcass de Us Padrões de Extensã d jcmpany. Figura A6.11. Subcass de Us Padrões para Extensã. Subcass de Us Padrões para Extensã Extensã Exprtaçã Este Subcas de Us prvê cenáris alternativs (que pdem u nã ser acinads pel usuári, após uma pesquisa de seleçã u cnsulta) para exprtaçã ds dads resultantes para frmats tais cm CSV u XML. Obs.: Smente dispnível em versões anterires d jcmpany (em revisã para JSF 2.0) Extensã Assistente Este Subcas de Us prvê cenáris alternativs (que pdem u nã ser acinads pel usuári, durante a entrada de dads) para acinar diálgs de assistente de entrada de dads, pass a pass (Wizards). Obs.: Smente dispnível em versões anterires d jcmpany (em revisã para JSF 2.0) Extensã Explraçã de Dads Extensã Detalhe pr Demanda Este Subcas de Us prvê cenáris alternativs que pdem u nã ser acinads pel usuári durante a entrada de dads para que uma treeview seja exibida cntend uma hierarquia de dads definida pel desenvlvedr, que pde ser utilizada cm um menu alternativ, rientad a dads, similar a Explradr d Windws. Este Subcas de Us prvê cenáris alternativs que pdem u nã ser acinads pel usuári, prvcand a recuperaçã de cleções de bjets de detalhe quand sã declarads cm pr demanda. Intrduçã a Prjet Lógic d RH Tutrial A melhr frma de se cnhecer s Padrões de Cas de Us d jcmpany é utilizá-ls na prática. É que farems ns capítuls de tutriais que se seguirã, n módul B. Neste capítul, vams apenas apresentar s Mdels de Cass de Us de Cntext para a aplicaçã que irems desenvlver. A aplicaçã RH Tutrial é uma simplificaçã de uma autmaçã de RH, área de negóci esclhida pr trazer cnceits básics bem familiares as trabalhadres em geral e que, pr este mtiv, nã exigirã maires explicações sbre Dmíni *. * Expsições sbre um dmíni cmplex seriam mnótnas em nss cntext atual. Pr iss, nós nã irems explicar em detalhes cada Cas de Us, deixand para fazê-l prgressivamente na medida em que evluirms n tutrial de cnstruçã da aplicaçã.

14 Capítul A5 - Cass de Us de Cntext em Nível Resumid para RH Tutrial Pr hra, vams entender nss escp. A Figura A6.12 mstra um Diagrama de Cass de Us em Nível Resumid, elabrad em temp de planejament, representand nss desej de realizar duas versões para a aplicaçã que desenvlverems neste livr e alguns Atres principais. Cm representa diagrama, pretendems ter duas versões de nss sistema de exempl, send que primeira será desenvlvida ns móduls A a F (Versã 1.0), e a segunda em vlumes subsequentes deste livr. Figura A6.12. Diagrama de Cas de Us em escp de Planejament (Negóci) - Cass de Us de Cntext em Nível de Objetivs d Usuári Versã 1.0 O Diagrama de Cass de Us de Cntext da Versã 1.0, apresentad na Figura A6.13, descreve tds s Cass de Us que desenvlverems ns primeirs móduls. Figura A6.13.Cass de Us para a versã 1.0 d RH Tutrial

15 Entendend a Metdlgia de Desenvlviment Sã s seguintes s bjetivs ds Atres em cada Cas de Us da Figura 12: Atr Númer Cas de Us Objetiv Administradr UC001 Manter Estrutura Organizacinal Incluir e manter atualizadas infrmações (nme e endereç) de Unidades Organizacinais da empresa, incluind matriz e filiais. UC008 Auditar Operações Verificar alterações realizadas n cadastr de Funcináris e seus dads, para fins de segurança. RH UC002 Registrar Funcináris Registrar e manter atualizads s funcináris, na medida em que sã cntratads. UC003 Cnsultar/Imprimir Ficha Funcinal Cnsultar uma ficha cmpleta incluind dads de Funcinári, Dependentes, Históric Funcinal e Ltaçã em qualidade ba também para impressã. FlhaPagament UC004 Registrar Prvents e Descnts Registrar débits e crédits para Funcinári a lng d mês. UC005 Calcular Flha de Pagament Realizar cálculs de pagaments mensais, cnsiderand-se salári base atual, prvents e descnts. UC006 Cnsultar/Imprimir Flha de Pagaments Realizar cnsulta cm qualidade de impressã cm relaçã de tds s funcináris e saláris, cm quebra e ttalizações pr ltaçã. - Cass de Us de Cntext da Aplicaçã Versã 2.0 A versã 2.0 cntemplará integrações típicas da realidade crprativa em diverss cenáris, cm ilustra a Figura A6.14. Estes cass de us utilizam tecnlgias de WOA (RESTFull Services), Dashbards e utras. Figura A6.14. Cass de Us para a versã 2.0 d RH Tutrial".

16 Capítul A5 Sã s seguintes s bjetivs ds Atres para a Versã 2.0: Atr Númer Cas de Us Objetiv Anônim UC009 Cnsultar Estrutura Organizacinal Usuáris anônims, via Web-Site, devem ser capazes de cnsultar dads da Estrutura Organizacinal, tais cm Nme e Endereç de Matriz e Filiais. Chefia UC010 Cnsultar Perfil de Equipe Usuáris em cargs de chefia devem pder sindicalizar cnteúds em frmat RSS/RDF cntend a relaçã de sua equipe de subrdinads imediats. Sistema SOA UC011 Cnsultar Nível de Salári de Funcinári Serviç que deve permitir cnsulta de nível salarial, para um funcinári. UC012 Registrar Prmçã de Funcinári Serviç que deve realizar a prmçã de um Funcinári, inclusive cnsumind serviç UC0011. Executiv UC013 Cnsultar Gráfic Ttal de Despesa Flha Pagt pr Unidade Organizacinal Cnsultar gráfic que pssa ser utilizad em Dashbard basead em Gadgets. Cntabilidade Externa UC014 Gerar arquiv XML cm resultads de cálcul de Flha Receber pr s dads de cálcul de Flha em anex, criptgrafads. Esta segunda versã ns pssibilitará a implementaçã de integrações típicas de ebusiness, tais cm: Integraçã de determinadas transações da aplicaçã em Web-Sites (para acess anônim), usand sindicalizaçã de HTML simples. Integraçã cm Prtais Crprativs via exprtaçã de dads para XML, usand sindicalizaçã RDF/RSS. Integraçã envlvend serviç e cnsum de Web-Services (REST preferencialmente) para estratégias de SOA. Integraçã cm padrões diverss Integraçã através de Gadgets para us em Dashbard privads (MyPrtal) u cmunitáris (iggle) Integraçã via envi de cm arquiv anexad para usuáris descnectads (ff-line) Níveis de Cass de Us - Intrduçã O leitr mais interessad em Cass de Us pde ter reparad que diagrama da Figura A6.12 encerra s nmes ds Cass de Us cm +, enquant s demais encerram cm!. Além diss, a clraçã é branca para s Cass de Us da Figura A6.12 e azulada para s demais. Esta ntaçã é recmendada pr Alistair Cckbur [Cckburn, Alistair. 2003] e diz respeit a Nível de Objetiv d Cas de Us. Sã s seguintes s níveis principais sugerids: Nível Cr Símbl Sufix Significad Resum (Céu) Objetivs d Usuári (Nível d Mar) Sub-funções (Fund d Mar) Branca + Sã Cass de Us utilizads para representaçã d cntext mair da aplicaçã, agrupand bjetivs d usuári. Azul Clara! Sã Cass de Us de mair interesse que realizam um bjetiv cncret d usuári, crrespndentes a prcess de negóci elementar. Azul Escur - Sã Cass de Us que representam atividades menres d usuári dentr de um Cas de Us bjetiv. (Na UML atualizada, sã Cass de Us esteretipads cm Clabrações, estand em

17 Entendend a Metdlgia de Desenvlviment um nível mais próxim da implementaçã) Para uma discussã sbre a imprtância de se destacar Níveis de Objetiv ns Cass de Us, sugerims a referência [Cckburn, Alistair. 2003]. Para nós, esta segmentaçã é especialmente imprtante prque desejams partir da especificaçã para a implementaçã de md clar e autmatizad. Neste sentid, tems que distinguir bem entre este Nível de Objetiv e Nível de Implementaçã : Para Prjet Lógic em si, imprtante é uma ba marcaçã d Nível de Objetiv ns mdels de Cas de Us, nível mais imprtante para usuári. Para Prjet Físic (e rastreament cm a implementaçã), mais imprtante é a diferenciaçã de um Cas de Us cm Cncret, para deixar clar que ele está em Nível de Implementaçã - especialmente quand já existam padrões definids na Arquitetura cm suprte diret para sua implementaçã, que é nss cas *. Um bm exempl sbre a distinçã entre estes níveis pde ser btid através da Figura A6.13. Tds s Cass de Us deste diagrama estã em Nível de Objetiv d Usuári (!), mas nem tds sã Cncrets! O UC001 Manter Estrutura Organizacinal! é mdelad cm Abstrat", que percebems pel text em itálic, padrã de ntaçã UML para estes cass. - Analisand Níveis em UC001 Manter Estrutura Organizacinal! O Cas de Us UC001 é mdelad cm Abstrat prque, muit embra esteja n Nível de Objetiv d usuári, ele nã pssui um padrã de implementaçã que mapeie para uma sluçã diretamente. Prtant, ele nã está n Nível de Implementaçã. A Figura A6.15 mstra um detalhament d Cas de Us UC001 Manter Estrutura Organizacinal, cmpst pr dis Cass de Us em Nível de Implementaçã e mstrads cm ntaçã e cr sugerids pr Alistair Cckburn, para abaix d nível d mar. Neste nível, sã dis Cass de Us Cncrets e para cada um deles tems sluções de implementaçã padrnizadas definidas através ds estereótips, em cada um. Nta: Os dis Cass de Us abaix utilizarã padrões de implementaçã distints para manter cicl de vida de bjets d Mdel de Classes da Figura A6.3: O UC001.1 manterá cicl de vida das Unidades da Federaçã (UF), e UC001.2 manterá cicl de vida das Unidades Organizacinais, seu endereç e assciações, inclusive cm UF. Figura A6.15. Cass de Us Cncrets em Nível de Implementaçã. Aqui, vale uma cnsideraçã: Esta especificaçã smente é válida prque, em nss exempl, estams supnd que a classe de UF nã seja de us crprativ. Em nssa hipótese, de frma simplificada, ela * Uma utra dica para perceberms que estams em Nível de Implementaçã é detalhament d Cas de Us. Abaix de um nível Padrã de Implementaçã terems frçsamente que intrduzir cnceits de Realizações de Cas de Us via Clabrações d Prjet Físic, que verems mais adiante. Ou seja, resultad de us relevante para usuáris é definir tda a Estrutura Organizacinal, cmpsta de Matriz, Filiais, seus endereçs - e incluind relaçã de UFs, de api para este fim.

18 Capítul A5 serve apenas a prpósit de nrmalizar dads para cadastr de Endereçs de Unidades Organizacinais. Cm Manter UF- nã é cnsiderad cm um Objetiv d Usuári pr si, algumas cnsequências pdem acntecer em nssa aplicaçã cm, pr exempl, a classe Uf pde cnter instâncias de UFs smente para as Unidades Organizacinais existentes *. - Analisand Níveis em UC002 Registrar Funcináris! Se agra analisarms Cas de Us UC002 verems que mesm, cincidentemente, está tant n Nível de Objetiv d Usuári quant n Nível de Implementaçã. Sabems diss prque ele está cm exclamaçã em azul clar (!) e nã está representad cm títul em itálic. E iss também é verdade para tds s demais Cass de Us, que irems desenvlver a lng ds tutriais deste livr. - Prjet Lógic para UC001.1 Manter UF- O primeir Cas de Us que desenvlverems será UC Devid à existência de um padrã para este Cas de Us, ele pderá ser especificad, cm precisã, simplesmente cm diagrama da Figura A6.16. Figura A6.16. Especificaçã Lógica pr exceçã, reutilizand padrã de implementaçã. Nte que a especificaçã acima ainda independe de implementarms u nã em jcmpany! Prtant, ela ainda está em nível lógic, send suficiente para se especificar para qualquer utr cntext tecnlógic de desenvlviment que defina padrões neste nível. Outras bservações imprtantes: A representaçã acima é apenas uma Visã Estrutural. A Visã Cmprtamental, representada tipicamente pels Cenáris de Cas de Us u Diagramas de Sequência, nem precisa ser representada, já que nã identificams nenhuma variaçã imprtante de cmprtament cm relaçã a cmprtament d Cas de Us Padrã Manter Classe. O estereótip <<plcmanclasse>> indica que padrã d Cas de Us Manter UF- é Manter Classe e que, prtant, nss Cas de Us deve herdar s cenáris deste padrã. N repsitóri da ferramenta CASE existe um relacinament de herança entre s Cass de Us para facilitar rastreabilidade, nã representad em nss diagrama. Restrições invariáveis (que nã mudam, cnfrme s Cass de Us) estã representadas junt às Entidades de Dmíni. Deste md, ficam encapsuladas, send * Este é um cenári apenas didátic. N mund real, para que uma empresa evite tabelas redundantes de UF, Cas de Us UC001.1 Manter UF- teria que ser prmvid para UC001 - Manter UF!, em Nível d Objetiv d Usuári. Para facilitar a cmpreensã deste padrã de mdelagem fram inserids dis capítuls d jcmpany Patterns & Methds, n Apêndice A deste livr. Cnsulte-s, pr exempl, para cnhecer a descriçã ds cenáris para Cas de Us para padrã Manter Classe.

19 Entendend a Metdlgia de Desenvlviment mais bem entendidas e naturalmente reutilizadas. Uma decraçã imprtante fi a representaçã de tamanhs nas prpriedades, que trna também a representaçã suficiente para us de mapeament Objet-Relacinal e definiçã de tamanhs padrões para camps crrespndentes na interface. Mesm a especificaçã da Interface cm Usuári está sucinta, mas suficiente, já que navegaçã, leiautes e barras de btões sã tds padrnizads na Arquitetura de Sftware, nã apresentand variações em nss cas. Intrduçã a Prjet Físic d RH Tutrial Incluirems n Prjet Físic qualquer mdel u abstraçã que pssua uma dependência de nss ambiente de implementaçã, neste cas cmpst pr tecnlgias Java EE 6 Open Surce integradas e especializadas pel jcmpany. Até aqui, cm vims, nssas abstrações para generalizações de Cass de Us de Manutençã de Cicl de Vida e Cnsulta de Agregações, além de Subcass de Us de Inclusã e Extensã, pdem ser aplicads a qualquer tecnlgia. Irems ntar que, devid à prfundidade e abrangência da Arquitetura de Sftware prpsta n jcmpany, que padrniza e traz generalidades para tdas as camadas MVC2-P, cnseguirems trabalhar cm um alt nível de abstraçã mesm n Prjet Físic. - Clabrações Padrões d jcmpany Além de padrões n nível de Cas de Us, jcmpany Patterns & Methds traz padrões para Realizações ds Cass de Us Padrões. Estas realizações sã representadas pr Clabrações que, na UML 2.x, sã representadas cm elipses cm brda tracejada, cm na Figura A6.17. Figura A6.17. Prjet Físic para Cas de Us UC001.1 Manter UF-. Perceba que diagrama acima é um Prjet Físic suficiente para nss Cas de Us Padrã Manter UF- ". É um exempl minimalista de Prjet pr Exceçã, que smente define uma Clabraçã padrã plctabular e inclui ainda estereótip n frmulári, indicand para seguir padrã de frmulári para a Clabraçã, em tecnlgia XHTML. É uma especificaçã minimalista, tã simples quant pssível - pderíams inclusive nã diagramá-la, a exceçã d frmulári. De fat, quand nã há muita diferenciaçã cm relaçã as padrões, smente tems que prjetar reús, evitand repetições de cenáris na especificaçã. Imprtante: N cas acima, definims nme da Clabraçã cincidente cm nme da URL, que segue cnvenções d jcmpany ( /uf ). Iss significa que implementarems para Web e que terems uma relaçã um para um entre uma Clabraçã e uma URL! Estas sã cnvenções imprtantes para rastreament d prjet cm implementações em jcmpany. Sã as seguintes as Clabrações Padrões d jcmpany: Padrões de Clabraçã d jcmpany Estereótip Nme Objetiv Manutençã: Clabrações que implementam frmuláris e perações de Manutençã d Cicl de Vida de Agregações de Objets, cm flux MVC-P generalizad em tdas as camadas. plctabular Tabular Realizaçã um para um cm Cas de Us Padrã Manter Classe, ferecend um frmulári e implementações genéricas que recuperam e atualizam

20 Capítul A5 simultaneamente tds s bjets de uma classe. plccrud CRUD Simples Clabraçã utilizada n Cas de Us Padrã Manter Agregaçã Simples, ferecend um frmulári e implementações genéricas que recuperam e atualizam uma Agregaçã que nã cntenha cmpsiçã d tip Mestre-Detalhe. plccrudtabular CRUD Tabular Clabraçã utilizada n Cas de Us Padrã Manter Cleçã, ferecend um frmulári e implementações genéricas que recuperam uma cleçã de bjets através de filtr e permitem atualizaçã. plcmestredetalhe Mestre-Detalhe Clabraçã utilizada n Cas de Us Padrã Manter Agregaçã Mestre- Detalhe, ferecend um frmulári e implementações genéricas que recuperam e atualizam uma Agregaçã que cntenha cmpsiçã d tip Mestre- Detalhe. plcmantemdetalhe Mantém-Detalhe Idem acima, cm Mestre send apenas de cnsulta. plcsubdetalhe Mestre-Detalhe- SubDetalhe Clabraçã utilizada n Cas de Us Padrã Manter Agregaçã Mestre- Detalhe, ferecend um frmulári e implementações genéricas que recuperam e atualizam uma Agregaçã que cntenha cmpsiçã d tip Mestre- Detalhe. plcmantemsubdetalhe Mantém- SubDetalhe Idem acima, cm Mestre send apenas de cnsulta. plcprefusuari Preferência d Usuári Realizaçã um para um cm Cas de Us Padrã Manter Preferência de Usuári, ferecend um frmulári e implementações genéricas que incluem, recuperam e atualizam um únic bjet pr usuári. plcprefaplicaca Preferência da Aplicaçã Realizaçã um para um cm Cas de Us Padrã Manter Preferência de Aplicaçã, ferecend um frmulári e implementações genéricas que incluem, recuperam e atualizam um únic bjet pr aplicaçã. Exibiçã/Seleçã: Clabrações que implementam frmuláris e perações de Pesquisa u Cnsulta de Agregações de Objets, cm flux MVC-P generalizad em tdas as camadas. plcseleca Seleçã Clabraçã utilizada cm s Cass de Us de manutençã que mantém uma Agregaçã pr vez para permitir pesquisa e seleçã da agregaçã a ser editada. plcselmantemdetalhe Seleçã Para Manter Detalhes Clabraçã utilizada cm s Cass de Us de manutençã que mantém uma Agregaçã pr vez, cm Mestre de cnsulta, para permitir pesquisa e seleçã da agregaçã a ser editada. plccnsulta Cnsulta Realizaçã um para um cm Cas de Us Padrã Cnsultar Objets, ferecend um frmulári e implementações genéricas que recuperam cleções de grafs de bjets cm base em amstras de infrmações d usuári (arguments de cnsulta). plcrelatri Relatóri Realizaçã um para um cm Cas de Us Padrã Cnsultar/Imprimir Objets, ferecend um frmulári e implementações genéricas que recuperam cleções de grafs de bjets cm base em amstras de infrmações d usuári (arguments de cnsulta),

21 Entendend a Metdlgia de Desenvlviment exibind-as em frmat aprpriad para impressã Estes diagramas de Realizaçã de Cass de Us (Visã Estrutural) serã apresentads para discussã mais detalhada, cas a cas, antes de inicarms desenvlviment de cada um deles, n próxim módul.