de Desenvolvimento Capítulo Introdução Estudo de Evolução de Arquiteturas de Software Java EE - Reúso de Arquitetura de Software

Tamanho: px
Começar a partir da página:

Download "de Desenvolvimento Capítulo Introdução Estudo de Evolução de Arquiteturas de Software Java EE - Reúso de Arquitetura de Software"

Transcrição

1 A6Entendend a Arquitetura de Desenvlviment Capítul 4 Intrduçã - Reús de Arquitetura de Sftware O jcmpany Develper Suite pde ser cmpreendid cm uma sluçã de reús em nível arquitetural. E nã apenas para reús de camadas de base de arquitetura para as aplicações desenvlvidas, mas também para ambiente de desenvlviment (IDE) e de Testes de Unidade. Estas sluções arquiteturais de base sã prvidas, respectivamente, pels móduls jcmpany FS Framewrk, jcmpany IDE e jcmpany Test fr Develper. Mas qual seria a diferença deste tip de reús em cmparaçã a reús mais pntual, digams, em nível de uma classe u pequen grup de clabraçã de classes? O reús arquitetural pssibilita reús de estratégias cmplexas englband desde reús de clabrações extensas de framewrks, smada à prduçã assistida de especializações precnizadas pr métds e padrões delineads pela arquitetura. Este tip de reús é de mais alt nível que s demais. Digams, uma integraçã de várias estratégias de reús pntuais, que prduz um resultad de valr visível para cliente (Ex.: um Cas de Us ptencial) e nã sluções parciais intermediárias. Em utras palavras: muit embra sejam imprtantes as táticas de reús em nível de classe u via padrões de prjet (Design Patterns), reús arquitetural é de nível mais estratégic, fundamental para quem deseja ganhs de prdutividade e qualidade em ambientes cm desenvlviments em larga escala. Estes ganhs equivalem as que se cnsegue cnstruind uma nva casa a partir de cmpnentes maires, préfabricads, em cmparaçã a se cmeçar selecinand madeira para fabricar prtas, pr exempl. Apesar de nã existir uma única sluçã de arquitetura perfeitamente adequada a tdas as situações, as diversas dimensões de arquitetura pré-implementadas n jcmpany sã custmizáveis... Para iss vingar na prática, prém, trna-se necessári um entendiment mais prfund das suas implementações, inclusive das mtivações fundamentais (Ratinale) que guiaram a Pwerlgic em sua prpsta. Este capítul inicia esta discussã. Estud de Evluçã de Arquiteturas de Sftware Java EE - O que é Arquitetura de Sftware? Já discutims sbre a imprtância da arquitetura n Capitul 1, mas nã pressupms que tds tenham cnheciments balizads sbre assunt. Pr iss, vams rever algumas definições fundamentais: Uma Arquitetura de Sftware para um sistema é a que define a estruturaçã deste sistema, que cmpreende seus Elements, a Relaçã entre eles e as Prpriedades externamente visíveis destes Elements e Relações. Ref. A6.1. [TS-4619 JavaOne 2006] Arquitetura de Sftware é a decmpsiçã d prblema de uma maneira que permita a desenvlviment eficientemente reslvê-l, cnsiderand restrições (...) Ref. A6.2. [Jhn Klein- Architecture and Design ] A arquitetura de qualquer aplicaçã deve a mens incluir (quand nã se basear em) cnsiderações de perfrmance. A arquitetura de uma aplicaçã crprativa deve cnsiderar s Cicls de Vida de Objets, assim cm a sua frma de us Ref. A6.3. [Haines, Steven 2006] Nã há muita cntrvérsia sbre a imprtância decisiva que uma ba Arquitetura de Sftware pde ter em prcess de desenvlviment de sftware em geral. Também há um grande recnheciment, pr

2 Capítul A4 parte de especialistas, cm relaçã a papel central que s framewrks assumem nesta questã. Prém, muitas empresas nã chegam a experimentar s resultads prmetids nesta área. Para nã crrerms este risc e bterms s melhres resultads, nssa prpsta smará reús de uma arquitetura abrangente cm padrões de alt nível e autmaçã de atividades, rquestradas pr Cheat-Sheets d Eclipse. Nssa arquitetura também será ajustada para a eficiência de prcessament, um utr pnt cmumente negligenciad. É um err imaginar a arquitetura apenas d pnt de vista estrutural e teóric. A arquitetura influi decisivamente em perfrmance e devem ser cnsiderads s cmprtaments dinâmic e prátic da aplicaçã, além ds fatres usabilidade, flexibilidade e utras dimensões cncrrentes, em nssa prblemática. Nã se satisfaça cm uma Arquitetura de Sftware rasa. Mesm uma arquitetura incipiente pderá prduzir um bcad de dcuments e diagramas impressinantes, mas trará resultads medícres, quand algum. Uma arquitetura para perfil típic de prjets crprativs, pr exempl, deve definir, em detalhes, dependências entre prjets e móduls, pactes dentr de prjets, artefats, events de prgramaçã de alt nível e, finalmente, trazer um bm númer de generalizações e padrões que cnduzam a um resultad visível para negóci, rapidamente. Ns próxims tópics, discutirems níveis de maturidade de arquiteturas de sftware. - Arquitetura de Sftware Invisível Em nssa experiência nã é incmum encntrar empresas desenvlvend em Java EE em um estági nde ainda nã há nenhuma arquitetura realmente visível para s implementadres. Neste nível de maturidade, que se chama de arquitetura sã alguns dcuments, traçand diretrizes cnceituais para us de MVC, este u aquele framewrk u até determinads Design Patterns. Este cenári primitiv é, clar, melhr que nada. Mas insuficiente para se perceber qualquer ganh cnsiderável nesta área um estági a qual chamams de Arquitetura de Sftware Invisível, ilustrad na Figura A6.1. Figura A6.1. Arquitetura de sftware Invisível. Neste estági, as lacunas estã vazias entre a platafrma de infra-estrutura Java EE (1) e as aplicações de negóci (5). Pr este mtiv, um enrme ptencial para errs está à espreita ds desenvlvedres, que ficam às vltas cm prgramações repetitivas de códig, que deveriam estar fatradas em nível arquitetural. Nã há cm evitar. Para uma arquitetura real, será necessári que s arquitets passem d dmíni ds cnceits para a experiência de us nas tecnlgias, suas pssíveis cmbinações, deficiências e valres, além de prváveis variações de us. Mntar uma arquitetura madura demanda um temp que nã pde ser facilmente abreviad especialmente uma que envlva altíssimas taxas de reús, partind de sluções best-f-breed Java EE Open Surce. Nesta filsifia, que é a adtada pel jcmpany, a recmendaçã é esclher peças melhres em seu segment. Algumas dezenas de tecnlgias, prjets e cmpnentes OSS deverã ser

3 Entendend a Arquitetura de Desenvlviment entendids, selecinads, especializads e integrads, muits deles em áreas de cnheciment cm razável distinçã das demais. Pr exempl, a camada Visã d MVC envlve a rquestraçã de diversas tecnlgias cmplexas, tais cm Facelets (XHTML)/HTML, Javascript, CSS, Ajax, técnicas de gestã de leiautes, etc., nenhuma delas de dmíni específic d mund Java u OO, de dmíni ds Arquitets de Sftware. O resultad, na prática, é uma quase ausência de arquitetura para a camada Visã, delegada para tratament superficial pels Web-Designers. Refinar uma ba arquitetura para a camada Cntrller também tem seus desafis, já que esta é bem mais cmplexa, tecnlgicamente, d que as camadas subsequentes de Mdel/Dmíni u Persistence. É uma utra camada nde nível de sluções de arquitetura cstuma ser muit ras, basicamente cnsistind de hmlgaçã de algum framewrk de base "em seu estági brut". As camadas de Mdel, Dmíni e Persistence, pr serem mais puramente ligadas a linguagem Java e às regras de negóci cstumam receber 90% da atençã ns trabalhs típics de Arquitetura de Sftware, a mens em seu estági inicial. Prém, a lng d temp se fará necessári um esfrç nas demais camadas, que exigirã um cnsiderável aprfundament tecnlógic. - Arquitetura de Sftware Anêmica Em um estági um puc mais adiantad, trabalh acima já terá se iniciad, de md que a arquitetura já pde ser vista na frma de sftware, cncreta, cm uma sluçã de base crprativa a ser reutilizada. Esta sluçã é frequentemente cmpsta de uma pilha (stack) de prduts e framewrk de base Open Surce integrads, nrmalmente definida após alguns meses iniciais de prspecçã, seleçã e integraçã leve. Digams, de uma dúzia de prduts de base, cmplementads pr dcuments de guia em nível mais detalhad. Ela está representada pela camada (2) na figura A4.2. Mas neste nível de maturidade, cm n anterir, ainda há uma grande migraçã de prblemas nã funcinais para a camada de Cre Business (5) e prgramadres d negóci lidand indevidamente cm: Códigs MVC burrs (de->para, fachadas artificiais); Gerenciament de transações manuais; Instanciações de bjets manuais; Códigs Java para inclusã, alteraçã, exclusã (CRUD); Elabraçã de frmuláris d zer ; Gestã de leiautes manual; Etc. Há um avanç perceptível cm relaçã à arquitetura meramente cnceitual d iníci, mas neste nível a arquitetura ainda é rasa a pnt de nã eliminar mesm variabilidades básicas indesejáveis. A distância entre a realidade e a prmessa de retrn de ambientes Orientads a Objet cntinua imensa - pr ist batizams a este estági de Arquitetura de Sftware Anêmica. É um estági basicamente caracterizad pr uma integraçã puc prfunda e abrangente entre um númer também insuficiente de prduts Open Surce de base, cnfrme ilustra a Figura A6.2. Nte que as camadas sb respnsabilidade da empresa sã representadas na mesma clraçã da camada de cre business.

4 Capítul A4 Figura A6.2. Arquitetura de Sftware Anêmica. - Arquitetura de Sftware Intermediária Neste estági de maturidade, já encntrams evidência clara de uma primeira Arquitetura de Sftware Crprativa em versã razável, integrand um bm númer de insums (framewrks e utilitáris) Open Surce cm um esfrç suficiente na prduçã de padrões de alt nível, nas diversas camadas MVC. Figura A6.3. Arquitetura de Sftware Crprativa em nível intermediári. Mas para ser de nível intermediári, realisticamente, esta arquitetura irá requerer uma cmprvaçã de us satisfatóri em prduçã seguid das inevitáveis refatrações - pr pel mens dis ans. É um períd mínim, após a cnstruçã da primeira versã, durante qual uma equipe de perfil abrangente * cnseguirá evluir para este nível de maturidade. * Cmpsta de Arquitet de Sftware, Analistas de Negóci, Web-Designers, Perits nas Tecnlgias, Dcumentadres, Analistas de Teste etc.

5 Entendend a Arquitetura de Desenvlviment A partir deste pnt, n entant, este mdel cmeça a apresentar suas limitações, especialmente se a implementaçã arquitetural fr cncebida e desenvlvida ttalmente pr equipe interna: Desvi de Fc: Uma equipe de valr estará dedicand ba parte de seu temp em atividades ttalmente fra d fc d negóci, já que grande parte da sluçã arquitetural nã é diferencial para seu negóci. Aument de Cust: Mesm que haja uma cntrataçã de terceirs para a manutençã desta camada, perdem-se s ganhs de escala pssíveis a partir d reús da parcela cmmdity da arquitetura. Prblemas de Gestã: Nrmalmente, s prblemas se agravam na medida em que cmeça a existir uma base instalada da arquitetura em prduçã. Na fase de manutençã, requisits de Gerência de Cnfiguraçã passam a cnsumir uma grande parcela de esfrç da equipe interna para manter rams de evluçã em paralel cm rams cmpatíveis. A partir daí, nã é incmum que entusiasm técnic das primeiras fases dê lugar a turn-vers u queda cnsiderável de prdutividade. A percepçã mais cmum é de que há uma dificuldade de rdem prática para que esta sluçã familiar evlua para próxim pass. Na medida em que as pressões de negóci sbre aplicações implantadas prevalecem cm priridade, cm haverá de ser, há uma tendência à estagnaçã u lentidã para a incrpraçã de invações, med de refrmulações, etc. - Arquitetura de Sftware Madura D nss pnt de vista, uma primeira cnfiguraçã de arquitetura rica e abrangente suficiente para ferecer s retrns esperads de um ambiente OO está ilustrada na Figura A6.4. Figura A6.4. Arquitetura de Sftware Crprativa cm alt nível de maturidade. Neste estági, as precupações de nível arquitetural que nã sejam abslutamente dependentes d cntext específic da empresa sã ttalmente desacpladas de precupações de natureza cmum u cmmdity. Este é primeir mdel que ferece um imprtante racicíni de negócis: a ptencial terceirizaçã das camadas arquiteturais 2 e 3, hrizntais, de frma a pssibilitar a cncentraçã da rganizaçã nas camadas 4 e 5. De fat, smente as duas últimas têm relevância para ambiente específic de TI e verticais de negóci. Cm esta pssibilidade, aumenta-se nã smente fc n negóci. Diminui-se cust e herda-se qualidade e maturidade, abreviand-se lngs ans e um grande númer de prblemas. - Arquitetura de Sftware Prvida pel jcmpany FS Framewrk Se tmarms cm base smente a prpsta d módul jcmpany FS Framewrk, que prvê uma sluçã arquitetural para as aplicações desenvlvidas, verems cm ela pretende apiar mdel anterir, ferecend ganhs nas três camadas arquiteturais:

6 Capítul A4 Figura A6.5. Arquitetura em camadas de uma aplicaçã Java EE cm jcmpany Full Stack Framewrk. O api a prblema arquitetural d jcmpany FS Framewrk se dá de frma diferente, em cada camada da arquitetura: (2) Reduçã d trabalh de integraçã e pré-cnfiguraçã da camada de reús Open Surce. Cm iss, a empresa se liberta de manter partes de prspecçã (P&D), integraçã, especializaçã, dcumentaçã de integraçã, atualizaçã, cntrle de versões e gerência de cnfiguraçã para estes insums. (3) Implementaçã cmpleta e madura para a camada cmmdity, baseada em Design Patterns de mercad. Cm iss, a empresa se liberta de cnceber, manter e evluir a parcela hrizntal da arquitetura de sftware e de amadurecê-la internamente. (4) Sluçã de base para a criaçã da camada específica da empresa, chamada camada Bridge. Deste md, arquitets da empresa pdem imediatamente cdificar suas generalidades e especializações de última milha, sbrepnd u especializand artefats da camada (c). Este é um espaç cncret que pssibilita a criatividade, custmizaçã e generalizaçã que dependem d cntext da empresa (segurança, web-design etc.) - Outras Sluções Arquiteturais d jcmpany Develper Suite Mas é imprtante ntar que, além d jcmpany FS Framewrk, s móduls jcmpany IDE e jcmpany Test fr Develper também trazem sluções arquiteturais para utras dimensões d prcess de desenvlviment de sftware: ferramental/ambiente de api à prdutividade e sluções de base para Testes de Unidade, respectivamente. Estas arquiteturas também pdem ser expandidas e fram descritas n capítul 1, mas estã reprduzidas nas Figura A6.6 e Figura A6.7, para cnveniência:

7 Entendend a Arquitetura de Desenvlviment Figura A6.6. Arquitetura de Sftware d Ambiente de Desenvlviment (IDE). Figura A6.7. Arquitetura de Sftware para desenvlviment de Testes de Unidade. - A Síndrme d NIH (Nt Invented Here) Apesar ds ganhs óbvis advinds d reús de arquitetura, um entrave a esta inexrável evluçã pde estar n própri crp técnic - pr mais paradxal que pareça. Um indivídu cm interesse e frmaçã em tecnlgia, quand cnfrntad cm um racicíni de negócis, pde falhar em identificar cmmdities de sftware, falhand em prtunidades de terceirizaçã que sã chaves para negóci de sua empresa. Uma atitude sintmática destes cass, pr parte de um arquitet u desenvlvedr, é rtular arquiteturas (nunca as suas próprias!) de camisas de frça, pr exempl *. Td reús exige esfrç de cmpreensã e adesã a que se deseja reutilizar, em um primeir mment, e deve pssibilitar diferenciações e flexibilidade para ganhs em níveis mais alts. Iss vale para reús de arquitetura, de bjets u de cmpnentes. - Aprendend a Reusar Arquitetura Send, prtant, reús em nível de arquitetura a primeira arma de prdutividade e qualidade de ambientes Orientads a Objets, será essencial adquirirms cnheciment nesta área, para s próxims níveis. * Sã que Rd Jhsn, criadr d Spring, chama de Own Career Driven Architects [Jhnsn, Rd 2004] - indivídus que nã cmpreendem a imprtância, para sua empresa, de rientarem a sua criatividadde para camadas de negóci. É a insistência em nã reusar, pel desafi (u interesse) pessal de fazer.

8 Capítul A4 Neste capítul, recapitularems brevemente alguns fundaments n camp da arquitetura de sftware para nivelament. Nã há pretensã e nem pssibilidade de esgtarms assunt neste espaç, mas s pnts para discussã aqui selecinads prcuram se cncentrar em carências frequentemente encntradas em nss mercad. Revisã de Fundaments - Cm Representarems a Arquitetura? Um sistema de sftware crprativ é cmpst de muitas estruturas distintas, cm relacinaments cmplexs. Prtant, sã necessárias diversas visões para representar cada uma delas [TS-4619 JavaOne 2006]. Neste livr, irems discutir as seguintes visões arquiteturais: Visã Geral (General View): Utilizarems a Visã Geral para uma primeira representaçã (macr) das grandes camadas (Layers) e Blcs (Tiers) da arquitetura. Visã de Móduls (Mdule View): Utilizarems a Visã de Móduls para representar cm estã agrupads s cnjunts de artefats em temp de desenvlviment e cm eles se relacinam entre si, em váris níveis de detalhament. Visã Interna (Internal View): Utilizarems a Visã Interna para representar cm estã rganizads s prjets de desenvlviment d pnt de vista de sua estruturaçã interna. É um tip de visã de micr-arquitetura, cnsiderand rganizaçã ds pactes e artefats padrões definids. Visã Cmprtamental (Behavir View): Utilizarems a Visã Cmprtamental para representar cm as categrias de classes clabram entre si em algumas anatmias de requisiçã MVC-P típicas. Visã de Execuçã (Runtime View): Utilizarems a Visã de Execuçã para representar cm pdems embalar e liberar s cnjunts de cmpnentes em temp de execuçã, distribuind-s u mantend-s em c-habitaçã, e cm eles se relacinam nestas pssíveis variações de infra-estrutura. Visã da Interface cm Usuári (GUI View): Utilizarems a Visã de Interface cm Usuári para representar s padrões de leiautes, frmuláris e cmpnentes dispníveis, cm estã rganizads e interaçã entre si. Ela nã cntempla questões de usabilidade, discutidas fra d âmbit da arquitetura. Além das representações principais para as visões acima, detalhament da arquitetura requer dcuments mais extenss que, pr mtivs didátics, nã sã dispnibilizads neste livr. Eles estã dispníveis na dcumentaçã d módul jcmpany Patterns & Methds, cedid cm a licença crprativa d jcmpany. Neste capítul, apresentarems as três primeiras visões: "Geral", "de Móduls" e Interna. - Arquitetura em Camadas (Layers) O agrupament de classes em móduls, que pr sua vez se rganizam em camadas sbrepstas, um sbre utr, é uma das metáfras mais cmuns em arquiteturas de sftware. A estes móduls, rganizads rigrsamente desta frma, chamams Layers (Camadas). É um paradigma que define dependências de uma maneira simples (a camada de sftware de cima depende da de baix ), mas que ns ferece um padrã para realizar arranjs arquiteturais bastante cmplexs, mas que ainda assim cnseguims cmpreender que é, aliás, um ds grandes bjetivs de uma arquitetura OO. O MVC, em si, é uma arquitetura em camadas cuj intuit principal é separar implementações relacinadas à interaçã cm usuári (precupações da aplicaçã em si) das implementações que representam as regras de negóci fundamentais d negóci. Para tant, define uma camada cntrladra, que desacpla as camadas de Interface cm Usuári (View) da de negóci (Mdel), e também encapsula algum tip de implementaçã em seu nível de intermediaçã. Na prática, algumas dificuldades que percebems n us d MVC em Java EE sã: Errs fundamentais de acplaments indevids entre as camadas; Us burcrátic, cncebid para lidar cm prblemas intrínsecs d EJB 2.x, sem cnsiderar evluções tecnlógicas tais cm Java EE 5 e 6 e EJB 3.0 e 3.1; Puc investiment em generalizações OO, levand à plriferaçã desnecessária de grande quantidade de códig pró-frma (repetitiv), de cmunicaçã entre as camadas. Irems discutir cnceits nestas três áreas, a cmeçar pela questã das camadas:

9 Entendend a Arquitetura de Desenvlviment Organizaçã cm baix acplament em Layer (Camadas Sbrepstas): Uma rganizaçã em Layer pssui camadas sbrepstas uma sbre a utra, de md que uma camada smente dependa da imediatamente inferir. Pr ter mens dependências, cada camada tende a ser mais estável e flexível. Esta rganizaçã é também cnhecida didaticamente cm bl de festa, em analgia às diferentes camadas de rechei que cmpõem este tip de bl: Figura A6.8. Organizaçã em camadas. Organizaçã em Referência Circular: Muitas vezes uma representaçã errada u pbremente simplificada pde ns cnduzir a cnclusões perigsas nesta área. Pr exempl, a representaçã à esquerda da Figura A6.9 representa móduls que nã estã rganizads em camadas, mas que, devid à missã das setas de dependência, sugere esta rganizaçã. Olhand a revisã à direita, real, percebems que se trata de uma arquitetura muit mais cmplexa que a sugerida à esquerda. Neste cas, inclusive mais instável, pis sfre de um mal cnhecid cm referência circular. Este é um prblema que gera alt acplament e deve ser evitad em tdas as camadas de abstraçã de um sftware. Figura A6.9. Diagramaçã excessivamente simplificada de arquitetura. Organizaçã de Tier (Blcs), cm diagramaçã simplificada: Mas a rganizaçã em camadas nã é a única utilizada em sftware e nem sempre é a mais recmendável. Pde-se rganizar uma aplicaçã em "blcs u móduls" (Tiers) que nã sã "islantes" cm as camadas, mas ainda assim relacinam entre si de md a manter baixas as dependências. Obs.: Mesm nestes cass, muitas vezes a diagramaçã em camadas é utilizada, para simplificar diagrama em si, u enfatizar um cmprtament. Pr exempl, a diagramaçã da esquerda, na Figura A6.10, é mais simples; mas quand é exigid um rigr técnic, pde dar margem a cnfusã. Repare a versã mais exata à direita, exibind claramente que C dependente diretamente de A e B.

10 Capítul A4 Figura A6.10. Melhr diagramaçã de camadas. Camadas paralelas e rtgnais: Cm as rganizações de sftware sã bem mais cmplexas d que pde sustentar a metáfra d bl de festa, n mund real nós irems ns deparar cm cmbinações mais sfisticadas das várias abrdagens pssíveis, u várias dimensões de camadas. Nas Figura A6.11 e Figura A6.12 vems duas cmbinações em camadas reais que prduzem arquiteturas estáveis, crretamente diagramadas, e inclusive muit cmuns em sftware. Figura A6.11. Camadas paralelas. Figura A6.12. Duas camadas transversais u rtgnais. Mesm em uma arquitetura mais elabrada, cm n cas da Figura A6.12, é imprtante perceberms que racicíni fundamental de minimizar dependências através d us de camadas cntinua presente. Mas quais sã s critéris para definirms nssas camadas? O que cada camada irá cnter e cm dependerã umas das utras? Bm, estas respstas serã btidas a partir de um racicíni OO que deverá seguir inicialmente s velhs princípis de baix acplament e alta cesã. - Baix Acplament (Mens dependências, mais estabilidade) O baix acplament (u diminuiçã das dependências entre elements) deve ser almejad em estruturas de sftware em tds s seus níveis de abstraçã:

11 Entendend a Arquitetura de Desenvlviment Estruturas arquiteturais cm mínim de dependências (Na prática, cm mair us pssível de camadas ); Aplicações u móduls cm mínim de dependências (referências externas) (Na prática, prjets cm menr tamanh pssível de Class Path ); Pactes cm mínim de referências externas (Na prática, classes cm menr númer pssível de imprts ); Classes cm menr númer de referências externas pssíveis (Na prática, pactes cm mínim de classes pssível). Na implementaçã, classes que pssuem mens dependências tendem a ser mais simples de se cmpreender e mais estáveis, mens sensíveis a turbulências externas. Classes de camada Cntrller, pr exempl, tendem a pssuir mais dependências, tais cm interfaces de Servlet e de framewrks cm JSF. Tendem, prtant, a ter mais imprts que classes da camada Mdel u Dmíni e a serem mais instáveis (Pr iss, dentre utrs mtivs, nã sã bas candidatas para cnterem implementações imprtantes d negóci). Mas cm será que iss se manifesta realmente, na prática? Vams ilustrar cm pequen episódi real. Certa vez, uma cntribuiçã a um release menr d Tmcat 5.x intrduziu a exigência de declaraçã implements Serializable para tds s bjets que fssem mantids em sessã (a intençã da equipe d Tmcat era atender a um aprimrament de suprte a Clusters). As únicas classes que realizavam registr em sessã eram, naturalmente, as que pssuíam acess (dependência) a interfaces de Servlet. Apesar de ser uma mudança trivial ns bjets (uma simples declaraçã), em várias situações de migraçã para Tmcat 5.x, em td mund, algumas classes de cntrle escapavam à revisã e cancelavam em prduçã, manifestand a instabilidade prvcada pr esta dependência. É um típic prblema prduzid em camadas mais baixas da arquitetura que nã acntece nas superires (de negóci, pr exempl), graças à rganizaçã em camadas d MVC. - Alta Cesã (Melhr encapsulament, mair reús) Sb utr ângul, querems também que estruturas, ns seus diverss níveis de abstraçã, se mantenham especializadas, encapsuland implementações de cmprtaments de mesma afinidade e se mantend tã simples quant pssível em trn de um bjetiv cmum. Em temp de prgramaçã, métds que implementam mais de uma funcinalidade tendem a ser mais cnfuss de se entender, manter e reutilizar. O mesm crre cm classes que agrupam blcs de funcinalidade distints, e assim pr diante. Pela nssa experiência, s maires "crimes de baixa cesã crrem ns métds de partida, que iniciam a respsta a um event extern. Exempls sã métd dget de um Servlet u cntextinitialized em uma implementaçã de ServletCntextListener, u um execute de um DP Cmmand, utilizad em um framewrk qualquer. Nestes pnts da arquitetura, nã é difícil encntrarms verdadeirs prgramas COBOL, em sintaxe Java! - Fatraçã de Códig (Mens redundâncias, mais eficácia) A fatraçã de códig cnsiste na identificaçã de códigs redundantes u muit similares em diferentes artefats, extraçã da parte cmum deste códig para um nv artefat independente, e revisã ds riginais para reusarem códig extraíd clcad em evidência. O bjetiv d arquitet, neste quesit, é buscar pr códigs pró-frma (biler plate) recrrentes, vulgarmente cnhecids cm códig burr e aplicar seus cnheciments de arquitetura de sftware e OO para eliminá-ls, pssivelmente prmvend-s para framewrks u utilitáris. Fatraçã de códig pró-frma é, de lnge, uma das questões da arquitetura que mais afetam a prdutividade e um ds bjetivs principais de framewrks de integraçã! Uma arquitetura nde sã admitidas grandes quantidades de códig burr, pr limitações de temp u de cnheciments mais aprfundads de OO e Java, fracassará a mens parcialmente. Se nã na primeira versã da aplicaçã, nas fases seguintes, cm as insustentáveis manutenções. - Refatraçã de Códig (Fatraçã cntínua) A melhr escrita é a reescrita (...). Td bm escritr sabe dist, e ist é verdadeir para sftware também Ref. A6.4. Paul Graham, citand E. B. White, em Hackers and Painters [Graham, Paul 2004]. Pág. 212 Mais recentemente, a fatraçã de códig deu lugar a uma sucessra: a refatraçã de códig (Refactring).

12 Capítul A4 Bastante discutida pr autres diverss cm destaque para Kent Beck e Martin Fwler [Fwler, Martin 2004] e autmatizada até cert pnt em IDEs tais cm Eclipse, esta mudança de ênfase para a refatraçã faz sentid na medida em que admitims a dificuldade de se prduzir códigs bem fatrads, de saída. A verdade que hje cnhecems é que, a cntrári d que alguns metdlgistas eminentemente teórics apregam, dificilmente se btém uma ba arquitetura na sua primeira versã. Especialistas nas tecnlgias e prcesss de Especificaçã (CASE UML, Ferramentas MDA etc.), mas que puc u nada cnhecem das tecnlgias e prcesss de Cnstruçã, terã ainda mais dificuldade neste bjetiv. Prtant, será prudente partir de preceits arquiteturais que visem facilitar a refatraçã u refrmulaçã de códigs de uma frma geral, cm a prduçã d mínim de instabilidade pssível. Uma ba arquitetura é btida de explrações práticas seguidas de refatrações frequentes, prtunidades que smente sã bem aprveitadas pr arquitets de sftware hands-n, que se atrevem a pr a mã na massa. - Arquitetura de Sftware prpsta n jcmpany O estad atual da arquitetura prpsta n jcmpany é frut de uma ba amstra de prjets reais, cm fases de refatraçã decisivas baseadas em prblemas e sugestões reais de clientes. Apesar de nã ser perfeitamente ajustada para prblemas de A até Z, cntém sluções para um mínim denminadr cmum que cbre um grande interval de prblemas cm sluções generalizáveis. N estági atual da arquitetura d jcmpany, pr exempl, nã é mais requerida nem uma única linha de códig Java, em nenhuma das camadas d MVC, para se implementar Manutenções de Cicl de Vida de Objets (incluir, alterar, excluir e cnsultar). Mesm quand lidams cm agregações de bjets cmplexas, envlvend cinc, dez u até vinte classes, ttal de linhas de prgramaçã prcedimental MVC para se bter um resultad cm qualidade de prduçã n jcmpany tende a zer! Manutenções de bjets em sua frma básica sã perações cmmdity, candidatas primárias à fatraçã de códig em qualquer linguagem de prgramaçã, especialmente em linguagens OO tais cm Java, e nã deveriam ser reslvidas primariamente cm geraçã de códig - rapidez que nã se preserva nas manutenções. Mas, ind além destas perações de manutençã de cicl de vida, jcmpany generaliza pr inteir dezenas de utras prgramações sfisticadas e recrrentes em sistemas crprativs, tais cm clnagem de dcuments, assistentes, leiaute dinâmic para impressã, explradres de dads (treeview), exprtaçã de dads, e muitas utras. Tdas elas generalizações que preveem espaç para especializações em nível crprativ u em nível de Cas de Us, respeitand a arquitetura MVC. Irems experimentar estas prmessas na prática, n próxim módul. Neste capítul, vams apresentar a "Visã Geral", Visã de Móduls e Visã Interna da arquitetura de sftware prpsta pel jcmpany. Visã Geral - Grandes Camadas e Blcs da Arquitetura d Framewrk - Visã Geral da Arquitetura d jcmpany FS Framewrk Já apresentams uma visã geral de tda a sluçã jcmpany Develper Suite, n capítul 1. Irems, na pauta atual, smente aprimrar a representaçã da arquitetura d framewrk jcmpany FS Framewrk, que representa a dimensã da sluçã de mair interesse pr parte de Arquitets de Sftware, já que inclui s cmpnentes OO reutilizads e mntads juntamente cm as aplicações. A representaçã inicialmente apresentada n capítul 1 está repetida na Figura A6.13, para cnveniência. Os númers de 1 até 4 representam dependências existentes para reús, desde a infra-estrutura, passand pels serviçs d Applicatin Server, biblitecas, framewrks de base, framewrk de integraçã e camada Bridge.

13 Entendend a Arquitetura de Desenvlviment Figura A6.13. Visã Geral inicial da arquitetura d jcmpany FS Framewrk. Mas, mesm send macr, esta representaçã é muit simplória para estuds arquiteturais. Ist prque nem a camada 3, d jcmpany (Arquitetura Reutilizada), nem a camada 4, Bridge (Arquitetura Específica), funcinam cm Layer, td temp, cm diagrama pde sugerir. Excet ns percentuais de requisits nde s Cass de Us Padrões sã suficientes, desenvlvedr pderá (e ist será desejável) acessar a camada 2 (JBss Seam, Tiles/Facelets, JPA/Hibernate, etc.) diretamente u, mais raramente, a camada 1, em nível d Applicatin Server u JVM. Prtant, diagrama abaix é mais realístic tecnicamente faland d que anterir. Figura A6.14. Visã Geral da Arquitetura d jcmpany FS Framewrk - Aprimrada. #1. Nas parcelas de requisits de Cass de Us centrads em dads, tant jcmpany FS Framewrk quant a cmplementaçã Bridge praticamente islam a aplicaçã das camadas de baix, atuand cm camadas (Layers). É imprtante ntar as setas tracejadas de dependência, indicand que estas "camadas" cmunicam entre si para ferecer um resultad MVC cmpletamente generalizad. #2. Em requisits que fgem u suplementam s suprtads pels padrões, acess pde ser diret à camada de framewrks de base. Deste md, a arquitetura nã restringe; pssibilita a desenvlvedr elabrar quaisquer sluções que sejam cnvenientes, para cada cas. Em quant pr cent ds cass jcmpany FS Framewrk e a Bridge funcinarã cm camadas? Bm, iss depende da natureza ds requisits de cada prjet. Em um estud de ROI (Retrn sbre

14 Capítul A4 Investiment) elabrad pela Pwerlgic, a trta apresentada na Figura A6.15 é tmada cm base, para um prjet crprativ típic. Figura A6.15. Segmentaçã típica de requisits de aplicaçã crprativa. Assim, em 40% ds cass, em média, espera-se que jcmpany FS Framewrk atue cm uma camada, evitand cntat diret de códigs de negóci cm framewrks de base. Ns demais segments de requisits, framewrk irá cntribuir prvend serviçs de IC, DI, AOP para gerência de transações, leiautes etc.; tds bastante úteis, mas que nã visam islament. Deste md mantém-se a liberdade para que desenvlvedr acesse qualquer recurs de base, quand necessári fr. Veja a cntribuiçã esperada (também em média, é clar) para cada fatia de natureza de requisits, acima definida, na Figura A6.16. Figura A6.16. Percentual de cntribuiçã d jcmpany FS Framewrk, pr natureza de requisits. Quand funcina cm camada, nível de cntribuiçã d framewrk d jcmpany n estud fi impressinante. Mas mesm cnsiderand-se percentual de cntribuiçã nas utras fatias, devidamente pnderads, btém-se ganhs expressivs! "Visã de Móduls - Dependência entre s prjets gerads - A arquitetura MVC n jcmpany Veja que, n tópic anterir, a representaçã de camadas utilizada é rtgnal às camadas MVC. Neste tópic, vams "virar" em 90 graus diagrama para analisá-l deste utr pnt de vista. A arquitetura MVC sugerida pel jcmpany sustenta-se pr cinc pilares principais: 1. Adçã rigrsa da arquitetura MVC Us de camada de Persistence, subdivind a de mdel, através d DP DAO (a que chamams, resumidamente, de MVC2-P) 3. Balanceament entre melhres práticas Java EE e DDD. 4. Refinament d nível de detalhe arquitetura, para dentr das camadas MVC2-P. 5. Arquitetura rica, também para a camada Visã, cm exclusiv IC Universal, inclusive para esta camada. De uma frma um puc mais detalhada: 1. Primariamente, jcmpany reúsa mdel MVC-2 clássic cm separaçã rigrsa das suas camadas utilizand servlet de Frnt-Cntrller d JSF (FacesServlet). O us deste DP Frnt-Cntrller é que distingue MVC-2 d MVC-1, já que n segund cas usuári acessa as JSPs diretamente.

15 Entendend a Arquitetura de Desenvlviment 2. Em segund lugar, jcmpany define uma nva camada para serviçs de Persistence, subdivisã da camada Mdel, prvend cntrats abstrats (Interface e DP Abstract Factry), além de implementações cncretas genéricas e alternativas para Hibernate u JPA. A camada de Persistence nã é uma sub-divisã clássica d MVC, mas cm é um layer verdadeir e muit cmum n mercad, irems enfatizá-l cm a sigla MVC2-P. 3. Em terceir lugar, a arquitetura se desenvlve cm base em recmendações da Sun, assimiland melhres práticas d Cre J2EE Patterns [Deepak Alur, Jhn] atualizadas para Java EE 6, balanceadas ainda cm sugestões de Dmain Driven-Design - DDD [Evans, Eric. 2004]. O DDD enfatiza uma rganizaçã OO tã pura quant pssível para mdel de Dmíni, que cncrre eventualmente cm rganizações para códig distribuíd d Java EE. Algumas vezes Java EE apresenta padrões que apresentam pequenas timizações, de mais baix nível, mas que nã sã tã elegantes quant um mdel ric de Dmíni precnizad pel DDD. Mas, se pr utr lad uma arquitetura que enfatize uma distribuiçã ptencial de cmpnentes, cm Java EE, pde ser cnsiderada verengineering [Jhnsn, Eric 2002], pr utr pde ser útil em estratégias que pretendam maximizar reús em runtime usand SOA, pr exempl. A arquitetura sugerida n jcmpany ferece um balanç razável entre estas duas esclas: na prática, ist significa que prgramações de Dmíni pdem ser ricas e nã anêmicas [Fwler, Martin 2004], refletind uma linguagem de negócis, mas também publicáveis a menr esfrç e de frma eficiente através de um Web-Service u serviç EJB3 remt - se, quand e nde precis fr. 4. Em quart lugar, jcmpany refina a arquitetura para dentr de cada camada MVC2-P, definind uma rganizaçã refinada de pactes e nvas categrias de classes internas tais cm Service e Helper, utilizadas cm DP Cmpsite [Freeman, Freeman 2004] para maximizar a cesã e minimizar ainda mais acplament. 5. Finalmente, jcmpany pssui uma arquitetura especialmente diferenciada na camada Visã, prvend Inversã de Cntrle (IC), também nesta camada, de md a finalizar a abrangência de generalizaçã ptencial da sluçã. Cm vims, esta é uma camada especialmente mal reslvida em arquiteturas típicas d mercad, devid à sua cmplexidade e diversidade de tecnlgias (JSF, Tag-Files, JSTL, JSP, Tiles/Facelets, Javascript, CSS, DHTML, Ajax/DOJO etc.). Para fazer frente a este desafi, jcmpany define leiautes reutilizáveis e cntrlads pel framewrk (leiautes dinâmics cm Tiles/Facelets), cmpnentes visuais especializads, sluções para reús e especializaçã de peles, rtinas Javascript/Ajax etc., tud iss cm DPs e cnceits OO aplicads, cm nas demais camadas. Este assunt será discutid de frma específica em capítul sbre custmizaçã de Web-Design. - Organizand Classes de Dmíni Uma das maires discussões arquiteturais em MVC é, frequentemente, cm rganizams nss mdel de Dmíni? O mdel de Dmíni é cmpst pr aquela parcela de classes que representam entidades claramente identificadas n negóci, persistentes, em sua mairia, cntend prpriedades cujs valres devem ser mantids em bancs de dads. Mas muit embra estas classes cmpnham um núcle imprtante das estruturas e regras de negóci, existirã utras categrias imprtantes de classes também cnsideradas de negóci para encapsular rquestrações de serviçs, cálculs e prcediment de api. - Arquitetura MVC-2 clássica d J2EE Na visã riginal d J2EE, tais classes de dmíni deveriam ser implementadas cm Entity Beans e, pela impsiçã de nã pderem rdar fra de um cntainer EJB (a cntrári ds POJOs atuais), eram, de frma brigatória, lcalizadas em subcamada interna da camada Mdel. Até aprimrament recente d padrã da especificaçã de Entity Beans para EJB3, prtant, era recmendad as desenvlvedres J2EE trabalhar cm classes artificiais de DTOs (Data Transfer Objects), mers cntainers de infrmações, para transprtar dads de entidades da camada Mdel/Persistence para a camada Cntrller/View, cnfrme a Figura A6.17.

16 Capítul A4 Figura A6.17. Arquitetura MVC precnizada n J2EE clássic (até EJB 2.1). #1. Usuári acina aplicaçã: N mdel MVC-2, um servlet recepcina tdas as requisições d usuári (e nã s cmpnentes de visã tais cm JSF, n MVC-1) #2. Camada cntrller chama serviçs de negóci: Um aparat de Design Patterns tais cm Business Delegate, Sessin Façade e utrs sã tipicamente utilizads para um mair islament entre a camada da aplicaçã (Cntrle e Visã) e a camada de negóci (Mdel), e também devid a uma pressupsiçã de remting, u seja, da ptencial distribuiçã destas camadas pr máquinas distintas, em runtime. Classes remtas sã, principalmente EJB Sessin Beans 2.x. #3. Tdas as principais camadas cmpartilham utilitáris. Muit embra nã sejam representads cm frequência, cmpnentes JAR cntend biblitecas suplementares para perações cm data, lgging, numéricas, tratament de exceções etc., sã dispstas de frma a estarem dispnível em tdas as camadas. #4. Us de Entity Beans 2.x: A Persistence ideal d pnt de vista da especificaçã é btida através de classes EJB Entity Beans e us de linguagem EJB-QL. #5. Us de Sessin Beans (DAO): Alternativamente, classes de EJB Sessin Bean substituem Entity Beans, devid a limitações tecnlógicas u de perfrmance, requerend cdificaçã de SQL diretamente ns códigs Java. #6. Acess a serviçs de Persistence: Seja pr respnsabilidade d cntainer EJB, n cas ds Entity Beans u d desenvlvedr ns DAOs, smente através de classes desta camada repsitóri de armazenament (Ex.: SGBD-R) é acessad. #7. Criaçã d mei de transprte: Após a recuperaçã de infrmações persistidas, seja pr que mei frem, a cdificaçã da cópia ds dads de Entity Beans u JDBC Result Sets para DTOs (Data Transfer Objects) é brigatória. #8. Cntrle de flux de navegaçã: N mdel MVC-2, as classes de Cntrle decidem para que classes de visualizaçã irã delegar a finalizaçã da respsta a usuári. Uma nva versã de Interface cm Usuári é entã selecinada em funçã d estad atual da cnversaçã. #9. Despach da visualizaçã: Classes representand tecnlgias da camada Visã tais cm facelets u JSF despacham algum frmat de visualizaçã para dispsitivs de cliente, tais cm HTML, XML, PDF, CSV, etc. Perceba que, cm a estrutura de dads ds frmuláris de negóci é cmpsta em sua mair parte pr prpriedades das entidades d negóci, a estrutura das classes de DTO terminava pr ser 90% a 100% redundante cm a estrutura das classes Entity Bean. Pr cnsequência, a manutençã desta redundância exigia códigs burrs de transferência de dads (de->para), instanciações de classes desnecessárias etc. Os utrs graves prblemas desta especificaçã Entity Bean (até a versã 2.x), tais cm sérias restrições da linguagem de Persistence EJB-QL, limitaçã a us de herança etc., findavam pr cnfigurar um verdadeir desastre em terms de prdutividade - e Orientaçã a Objets. Na prática, muits reslviam este prblema simplesmente desistind ds Entity Beans 2.x (de fat, quase inutilizáveis). Mas quem nã s substituía pr algum framewrk de mapeament Objet-Relacinal tal

17 Entendend a Arquitetura de Desenvlviment cm Hibernate, passava a prgramar JDBC em EJB Sessin Beans, cm exemplificad em (E), cm manipulaçã direta de result sets e cópias de/para DTOs (u VOs), caind em níveis de prdutividade de técnicas de prgramaçã da geraçã COBOL. Na verdade, em níveis pires devid às deficiências intrusivas da geraçã EJB 2.x, cm vist. Felizmente, s Entity Beans 2.x sã agra legad, substituíds na versã EJB 3.0 pr POJOs (Plain Old Java Objects) que crrigem, da água para vinh, tdas as limitações clássicas. Uma sequela diss é que s Entity Beans 3.0 fram inteiramente recncebids a partir d padrã Java EE 5 e ram 2.x nã sfrerá mais evluções. Ruim para quem acreditu cegamente neste tip de padrã frçad de cmitê ; bm para restante d mercad, que já havia trcad us de Entity Beans 2.x pr alternativas que agra se trnaram padrã de-fact, cm Hibernate/JPA *. Padrões de fact d mercad Open Surce, via de regra, superam s de cmitê. Smente ns últims ans, s cndutres estratégics d Java EE 5 e Java EE 6, especialmente a SUN, fcu ns anseis ds desenvlvedres e nã smente ds fabricantes de Applicatin Server. Esta tendência tem levad à quase eliminaçã de padrões artificais cncebids sem explraçã técnica. - Camada de Dmíni Ortgnal em Java EE 6 Pr tud iss, em sua versã 3.x s Entity Beans vltam a ser a implementaçã ideal para Entidades de Dmíni. Os EJBs 2.x nã eram recmendads para este fim pels principais autres e adepts d DDD, tais cm Martin Fwler e Eric Evans. Dentre utras vantagens, s EJBs 3.x pdem agra dispensar s DTOs na mair parte d temp, pis sã destacáveis e pdem ser expsts para tdas as camadas d MVC2-P em um esquema cnhecid cm atach-detach. Deste md, servem tant para Persistence transparente quant para encapsularem regras de sua alçada e transprtarem seus própris dads. Cm esta evluçã, uma melhr rganizaçã para entidades de Dmíni é clcá-las em uma nva camada, rtgnal à camada central d MVC [POJOs in Actin] [Spring MVC], cnfrme ilustrad na Figura A6.18. Figura A6.18. Arquitetura MVC cm camada rtgnal de Dmíni. #1. Camada cmmns englba utilitáris e DTOs eventuais: As classes utilitárias cmuns a tdas as camadas MVC principais, bem cm eventuais DTOs que ainda sejam necessáris sã encapsulads na visã Cmmns. * O criadr da Hibernate, Gavin King, fi um ds líderes da especificaçã EJB3, especialmente da parte de Entity Beans, que fi redefinida dentr d padrã JPA (Java Persistance Architecture). Pr iss, JPA é hje 90% similar arquiteturalmente a que já se usava na Hibernate.

18 Capítul A4 #2. Camada de Persistence mais leve, utilizand JPA-QL: A camada de Persistence agra pde dispensar cdificaçã de inclusões, alterações, exclusões e de trataments de cncrrência, geraçã de identificadres autmátics, dentre utrs trabalhs realizads de frma transparente pel JPA. Além diss, a linguagem JPA-QL retrna grafs de entidades de dmíni prntamente dispníveis para us pelas demais camadas de frma OO, e nã mais result sets JDBC, relacinais. #3. Camada rtgnal para Entidades de Dmíni: A camada de dmíni agra representa um bjet clássic de OO, cm prpriedades e respnsabilidades (métds) d negóci, além de pderem ser utilizadas em qualquer camada MVC2-P. É imprtante ntar que agra as nbres classes desta camada sã as mais estáveis da arquitetura, nã dependend de serviçs de nenhuma utra, nem de Persistence, pr exempl (a camada de Persistence recupera dads e dispnibiliza para a de Dmíni). Na camada simplificada cm Cmmns (1) estã incluídas classes de utilitáris cmuns de base OSS (Apache Cmmns, Apache Lg4j etc.), d jcmpany (classes sufixadas cm Helper u Util), s DTOs restantes e, ainda, s cntrats (as Interfaces, smente) de fachada, entre as camadas. A Figura A6.19 mstra uma radigrafia um puc mais detalhada da Arquitetura de Sftware MVC2-P * prpsta para Java EE 6 pel jcmpany, exibind também algumas dependências especificas de cada camada, a centr (Mat. Prima OSS, Service, Helper): Figura A6.19. Arquitetura MVC2-P cm dependências rtgnais glbais e internas das camadas. #1. DP Façade: Apesar de representarms, didaticamente, uma seta cm dependência entre Cntrller e Mdel (d Cntrller para a subcamada de implementaçã de Fachada), DP Façade é utilizad nesta interaçã, de md que há um acmplament leve, facilitand reimplementações de serviçs, se/quand necessári. #2. Transprte DTO e Cntext: Quand um Cas de Us apresenta frmulári cm estrutura bastante distinta das Entidades, pde-se lançar cm recurs de transprte s tradicinais DTOs (Data Transfer Objects), cm exceçã, nã mais cm regra! Além diss, um POJO cm DP Cntext Object é utilizad pel jcmpany para transprtar, genericamente, infrmações de cntext da camada Cntrle para Mdel, que pdem ser úteis (perfil d usuári autenticad, metadads de clabraçã etc.). #3. Utilitáris Glbais: Classes d jcmpany cm sufix Helper trazem funções diversas, cmplementares a funções de utilitáris de mercad, de interesse de tdas as camadas. #4. Matéria-Prima OSS Glbal: Representam dependências externas (JAR) de utilitáris, também cmuns a tdas as camadas MVC2-P, tais cm Lg4j, Cmmns, CGLib (AOP) etc. * Neste livr, utilizarems MVC2-P quand quiserms enfatizar uma arquitetura MVC d tip 2, cm subcamada de Persistência bem definida.

19 Entendend a Arquitetura de Desenvlviment #5. Serviçs e utilitáris Específics: Dentr de cada grande camada MVC2-P, há subdivisões de pactes segmentand e encapsuland serviçs e utilitáris interns d jcmpany, específics para a camada. #6. Matéria-Prima OSS Específica: Cada camada MVC2-P pssui um cnjunt agrupad de dependências externas de interesse seu apenas (definid tant n Maven quant em User Libraries d Eclipse). Este agrupament simplifica a gestã de dependências, evitand falhas básicas de arquitetura prduzida pr desenvlvedres. Ex.: Imprtações de serviçs de Persistence na camada Cntrller. É imprtante bservarms algumas dependências acima indicadas: Há uma dependência rtgnal, pr parte de tdas as camadas MVC2-P, cm a camada de Dmíni, além de utilitáris cmuns, resquícis de DTO e cntrats de fachada (smente as Interfaces). A camada de Dmíni, pr sua vez, descnhece e independe de quaisquer das camadas MVC2-P. Ela se trna assim, cm é de se esperar, a parte mais estável da arquitetura, funcinand cm um layer rtgnal. O cnceit da rtgnalidade pde ser melhr visualizad pel rearranj didátic da Figura A6.20. Figura A6.20. Rearranj para visualizaçã mais didática da camada Ortgnal - "layer". Algumas utras bservações imprtantes: O M d MVC2-P, a camada Mdel, é agra decmpsta em Implementações de Cntrats de Fachada e Serviçs de Negóci. Nã detém mais s direits exclusivs de acess às Entidade de Dmíni, que pr sua vez também encapsulam regras de negóci de sua respnsabilidade e nã smente dads. Em uma eventual dispnibilizaçã de frma distribuída, s móduls que cmpõem as camadas rtgnais sã embalads em ambs s executáveis: da aplicaçã e d serviç. Ou seja, em lugar ds DTOs artificiais (smente alguns cntrats especiais permanecem), sã as próprias Entidades que agra servem de transprte entre as aplicações distribuídas. Entidades nã pdem acessar DAOs (Data Access Objects) para bter dads. Elas devem receber dads recuperads pr classes de serviç da camada Mdel (Manager/Business Objects-BO u Applicatin Services-AS) para realizar seus prcessaments, tipicamente regras de negóci. Os terms entre parênteses sugerem sufixs padrões para classes em cada camada, mas pdem ser custmizads em nível crprativ através de cnfigurações ns metadads d jcmpany. Assim, classes de serviç da camada Mdel pdem ter sufix padrã BO, Manager, Mgr u Service, cnfrme desejad. - Organizaçã de Prjets de Desenvlviment Os três prjets Eclipse gerads n capítul anterir suprtam a arquitetura MVC2-P, n ambiente de desenvlviment, da seguite frma:

20 Capítul A4 Figura A6.21. Prjets de desenvlviment x arquitetura de camadas MVC-P. #1. Prjet Eclipse rhtutrial * : Englba a chamada de camada da Aplicaçã [Richardsn, Chris 2006], u seja, as camadas Visã e Cntrle (Cntrladr) d MVC. Naturalmente, artefats de visã sã segmentads ds de cntrle em pactes distints. #2. Prjet Eclipse rhtutrial_mdel : Englba a camada de Mdel, incluind a subsegmentaçã de Persistence em pacte distint. Também neste cas, pactes distints segmentam serviçs de negóci e de Persistence. #3. Prjet Eclipse rhtutrial_cmmns : Englba a camada de utilitáris e utras classes de interesse cmum das demais camadas e também a camada de Dmíni, segmentada em pacte específic. Na rganizaçã da Figura A6.21, é imprtante ntar que nã há uma relaçã um para um entre uma camada da arquitetura e um prjet de desenvlviment na IDE, já que a prliferaçã de prjets de desenvlviment é também prejudicial, aumentand a cmplexidade muitas vezes sem vantagens práticas. Pr utr lad, agrupar tdas as camadas em um únic prjet cstuma também ser uma simplificaçã exagerada na medida em que facilita a quebra de arquitetura MVC. O jcmpany sugere um agrupament cnsiderad bm para a média ds prjets crprativs, em seus templates INI, mas deve-se realizar ajustes, custmizand-se estes templates para algumas situações. Alguns bns exempls sã: Cas a aplicaçã pretendesse renderizar bjets para mais de uma tecnlgia de Visã (Ex.: HTML e também XML/XSLT u WML), entã seria uma ba esclha separar s pactes de Visã, presentes n prjet rhtutrial, em utr prjet independente. Deste md, pder-se-ia ter dis prjets para esta camada Visã bem desacplads. O mesm racicíni valeria, cas a pretensã fsse utilizar duas implementações de Persistence. Se fsse cas, cmpensaria fatrar (s) pacte(s) de persistencia d rhtutrial_mdel para um prjet própri de Persistence. * Na versã 6.0 d JAGUAR s prjets MVC sã gerads sb um prjet pai nmead cm "[nmeapp]_parent". Essa nva estrutura frnece mair dinamism para maven e nã interfere em nenhum artefat MVC. Iss prque facilita as desenvlvedres eventualmente instanciarem dependências de utras camadas, dispníveis glbalmente em um únic Class Path. Nte que, desde que classes de uma camada MVC2-P estejam segmentadas, pel mens, pr pactes cm baix acmplament, rerganizar s prjets nã seria uma tarefa cmplexa. E cm verems, esta é uma precupaçã d jcmpany, que descreverems na Visã Interna da arquitetura prpsta.

21 Entendend a Arquitetura de Desenvlviment Figura A6.22. Principais pactes que segmentam internamente as camadas, dentr de prjets. Devid à rganizaçã acima representada, chega-se a seguinte esquema de dependência entre s prjets gerads (gerada desta frma pel jcmpany, autmaticamente, tant n Eclipse quant n Maven): Figura A6.23. Diagrama de dependência de móduls em linguagem UML. Ns exempls em Figura A6.24, Figura A6.25 e Figura A6.26, vems s arquivs Maven e cnfigurações n Eclipse envlvids. Os móduls Maven (Prjets que serã alterads e cnstruíds pel desenvlvedr) sã definids n arquiv "pm.xml" d prjet Parent e as dependências Maven ns arquivs "pm.xml" de cada prjet. A sincrnia entre esta definiçã e Build Path d Ecilpse é autmaticamente realizada pel plugin M2Eclipse. Ntar que este plugin imprta "mduls Maven" cm "Prjets Eclipse" e, cm verems mais adiante, utras dependências (JAR) cm Libraries Externas, cm deve ser feit:

22 Capítul A4 Figura A6.24. Prjet "principal": Móduls expresss n "pm.xml" Figura A6.25. Prjet "principal": Dependências de móduls expressas n "pm.xml" e sincrnizadas n Eclipse. Figura A6.26. Prjet "mdel": Dependências de móduls expressas n "pm.xml" e sincrnizadas n Eclipse. O prjet "cmmns" nã pssui dependência ds demais, send prtant cnsiderad mais "estável", d pnt de vista arquitetural. - Dependências cm jcmpany A Figura A6.27 exibe nvamente um Diagrama de Cmpnentes da UML para nss prjet rhtutrial, desta vez expandid para cnter dependências d jcmpany em temp de desenvlviment (n Eclipse). Figura A6.27. Dependências entre prjets gerads e jcmpany, em temp de desenvlviment. O prjet d jcmpany para camada de Visã, jcmpany_view nã esta incluíd cm dependência prque nã cntém classes necessárias em temp de desenvlviment. Mas cas desenvlvedr

23 Entendend a Arquitetura de Desenvlviment necessitasse especializar algum cmpnente ele teria que acrescentar uma camada Bridge especializada a prjet. - Dependências cm jcmpany em temp de desenvlviment Cm implementams as dependências da Figura A6.27, n ambiente d Eclipse? Além ds móduls supra-citads, plugin M2Eclipse sincrniza as dependências simples, que nã sã expressas cm "móduls" ns arquivs "pm.xml"(d prjets MVC e d prjet Parent),cm "External Libraries" n Eclipse, autmaticamente. Deste md, dispensa desenvlvedr de cnfigurar de frma redudante estas dependências. Ver Figura A6.28. Figura A6.28. Dependências autmaticamente geradas n Eclipse, a partir d M2Eclipse #1. Prjets Rhtutrial, que pr ser um prjet jcmpany tem dependências gerenciadas pel M2Eclipse. #2. JARs definids ns arquivs "pm.xml" e dispníveis n repsitóri Maven lcal, agrupads em "Maven Dependencies". - Dependências cm jcmpany em temp de execuçã Em uma visã de dependência em temp de execuçã, prjet da camada Visã, jcmpany_visa devem aparecer, pis reúne artefats "nã Java", cm cnteúd em frmats cm XHTML (leiautes genérics de frmulári), CSS, Javascript (Widgets, utilitáris,...), dentre utrs artefats reutilizads smente em temp de execuçã. Ist é exemplificad na Figura A6.29. Figura A6.29. Dependências entre prjets gerads e jcmpany em temp de execuçã. Obs. 1: Para dependências smente em temp de execuçã, é necessári devid registr das dependências ns arquivs pm.xml d Maven, mas nã necessariamente n Eclipse! O M2Eclipse já cuida deste tip de cnfiguraçã autmaticamente. Obs. 2: Os prjets da camada visã d jcmpany sã dispnibilizads cm WAR para Maven, que s expande e mescla cm WAR da aplicaçã (u EAR) em temp de mntagem para funcinament em execuçã. Este frmat é mdelad cm "PSEUDO-WAR" para distingui-l de um "WAR" final, executável.

24 Capítul A4 - Dependências cm a camada de reús Open Surce (OSS) Além da dependência entre s prjets Eclipse e jcmpany, precisarems analisar e implementar ainda as dependências de tds estes prjets cm s framewrks de base e biblitecas de utilitáris hmlgads n sluçã, as quais chamams de Matéria-Prima Open Surce. As dependências das camadas de reús Open-Surce também sã imprtadas cm "External Libraries" n Eclipse pel M2Eclipse, nã havend distinçã cm relaçã as JARs d jcmpany, pr exempl. Figura A6.30. Libraries cntend jcmpany e cmpnentes reutilizads (em destaque), gerads pel M2Eclipse. Visã Interna - Estrutura e artefats ds prjets gerads - Intrduçã Nesta visã, vams entender cm s três prjets gerads n capítul anterir estã rganizads d pnt de vista de sua estrutura interna. Esta visã englba a rganizaçã de diretóris e de artefats sugerids pela arquitetura. A rganizaçã inicial de diretóris adtada pel jcmpany segue cnvenções recmendadas pela ferramenta Apache Maven, resultad de ans de prática em rganizaçã de prjets clabrativs e mundiais d grup Apache. A rganizaçã pinativa d Maven, cm gstam de frisar s seus autres, é mais rigrsa, prém permite a esta ferramenta cmpreender mais a fund prjet (nde estã suas classes de teste, artefats de cnfiguraçã da aplicaçã etc.) e, pr cnsequência, cntribuir mais. Seguir padrã de pactes d Maven ns ajudará na atualizaçã de versões, geraçã de rtinas de mntagem, cmpilaçã e liberaçã de executáveis. Além diss, plugins Maven pderã gerar métricas interessantes e um Web-Site em nível bem adiantad de acabament para nsss prjets, uma vez que utilizems a sua arquitetura sugerida. A pstura pinativa d Maven é similar à adtada pela Pwerlgic n jcmpany. O Maven aprfunda as exigências arquiteturais e irá cbrar um mair investiment inicial quand cmparad, pr exempl, a Apache Ant, mas trará mais retrn, n médi praz. - Aprendend mais sbre Apache Maven Nã irems redundar neste livr tda a explicaçã de base dispnível ns manuais d Maven 3, sbre as vantagens da estrutura de pactes sugerida adtada pel jcmpany. Para iss, sugerims estud ds tutriais d prdut em u ds diverss artigs dispníveis na Web, facilmente desvendáveis através de cnsulta maven 3 articles n Ggle. Em nssa pauta, irems discutir s refinaments realizads pel jcmpany sbre essa estrutura padrã de frma detalhada. - O prjet principal (Cntrller e View) O prjet principal cntém basicamente pactes para prgramações da camada Cntrller d MVC, bem cm arquivs de cnfiguraçã e artefats de camada Visã. É a seguinte a sua rganizaçã interna padrã, cnfrme definida n template INI (e, prtant, utilizada para nvs prjets):

Design Patterns ABSTRACT FACTORY EMERSON BARROS DE MENESES

Design Patterns ABSTRACT FACTORY EMERSON BARROS DE MENESES Design Patterns ABSTRACT FACTORY EMERSON BARROS DE MENESES 1 Breve Históric Sbre Design Patterns A rigem ds Design Patterns (Padrões de Desenh u ainda Padrões de Prjet) vem d trabalh de um arquitet chamad

Leia mais

Aula 11 Bibliotecas de função

Aula 11 Bibliotecas de função Universidade Federal d Espírit Sant Centr Tecnlógic Departament de Infrmática Prgramaçã Básica de Cmputadres Prf. Vítr E. Silva Suza Aula 11 Biblitecas de funçã 1. Intrduçã À medida que um prgrama cresce

Leia mais

Desenho centrado em utilização

Desenho centrado em utilização Desenh centrad em utilizaçã Engenharia de Usabilidade Prf.: Clarind Isaías Pereira da Silva e Pádua Departament de Ciência da Cmputaçã - UFMG Desenh centrad em utilizaçã Referências Cnstantine, L.L., &

Leia mais

Projetos, Programas e Portfólios

Projetos, Programas e Portfólios Prjets, Prgramas e Prtfólis pr Juliana Klb em julianaklb.cm Prjet Segund PMBOK (2008): um prjet é um esfrç temprári empreendid para criar um nv prdut, serviç u resultad exclusiv. Esta definiçã, apesar

Leia mais

De fato, o caminho mais eficiente para se construir uma solução é não construí-la, reutilizando uma existente.

De fato, o caminho mais eficiente para se construir uma solução é não construí-la, reutilizando uma existente. A6Instaland jcmpany Capítul 2 Gerência de Cnfiguraçã em Java EE Open Surce - Reús x Geraçã de Códig A mairia ds arquitets e desenvlvedres de sftware atualmente busca salts de prdutividade e qualidade através

Leia mais

Projeto de Arquitetura Objetivos. Tópicos abordados. Arquitetura de software. Vantagens da arquitetura explícita

Projeto de Arquitetura Objetivos. Tópicos abordados. Arquitetura de software. Vantagens da arquitetura explícita Prjet de Arquitetura Objetivs Apresentar prjet de arquitetura e discutir sua imprtância Explicar as decisões de prjet de arquitetura que têm de ser feitas Apresentar três estils cmplementares de arquitetura

Leia mais

Vensis PCP. Rua Américo Vespúcio, 71 Porto Alegre / RS (51) 3012-4444 comercial@vensis.com.br www.vensis.com.br

Vensis PCP. Rua Américo Vespúcio, 71 Porto Alegre / RS (51) 3012-4444 comercial@vensis.com.br www.vensis.com.br Vensis PCP Vensis PCP O PCP é módul de planejament e cntrle de prduçã da Vensis. Utilizad n segment industrial, módul PCP funcina de frma ttalmente integrada a Vensis ERP e permite às indústrias elabrar

Leia mais

3 Formulação da Metodologia 3.1. Considerações Iniciais

3 Formulação da Metodologia 3.1. Considerações Iniciais 53 3 Frmulaçã da Metdlgia 3.1. Cnsiderações Iniciais O presente capítul tem cm finalidade prpr e descrever um mdel de referencia para gerenciament de prjets de sftware que pssa ser mensurável e repetível,

Leia mais

Academia FI Finanças

Academia FI Finanças Academia FI Finanças A Academia é melhr caminh para especializaçã dentr de um tema n ERP da SAP. Para quem busca uma frmaçã cm certificaçã em finanças, mais indicad é participar da próxima Academia de

Leia mais

Principais Informações

Principais Informações Principais Infrmações Quem é Benefix Sistemas? Frmada pr ex-executivs e equipe de tecnlgia da Xerx d Brasil, que desenvlvem e suprtam sluções e estratégias invadras para setr públic, especializada dcuments

Leia mais

Regulamento para realização do Trabalho de Conclusão de Curso

Regulamento para realização do Trabalho de Conclusão de Curso Universidade Federal d Ceará Campus de Sbral Curs de Engenharia da Cmputaçã Regulament para realizaçã d Trabalh de Cnclusã de Curs Intrduçã Este dcument estabelece as regras básicas para funcinament das

Leia mais

PAULO ALVIM TIRANDO O MÁXIMO DO JAVA EE 6 OPEN SOURCE. 3ª edição. com jcompany Developer Suite

PAULO ALVIM TIRANDO O MÁXIMO DO JAVA EE 6 OPEN SOURCE. 3ª edição. com jcompany Developer Suite PAULO ALVIM TIRANDO O MÁXIMO DO JAVA EE 6 OPEN SOURCE cm jcmpany Develper Suite 3ª ediçã Bel Hriznte Paul César Alvim Ottni 2010 Tirand Máxim d Java EE 6 Open Surce cm jcmpany Develper Suite 2010 Pwerlgic

Leia mais

CONCORRÊNCIA AA Nº 05/2009 BNDES ANEXO II PROJETO BÁSICO: JORNADA AGIR

CONCORRÊNCIA AA Nº 05/2009 BNDES ANEXO II PROJETO BÁSICO: JORNADA AGIR CONCORRÊNCIA AA Nº 05/2009 BNDES ANEXO II PROJETO BÁSICO: JORNADA AGIR 1. Históric da Jrnada AGIR Ns ambientes crprativs atuais, a adçã de um mdel de gestã integrada é uma decisã estratégica n api às tmadas

Leia mais

EIKON DOCUMENTS - ESPECIFICAÇÃO TÉCNICA

EIKON DOCUMENTS - ESPECIFICAÇÃO TÉCNICA EIKON DOCUMENTS - ESPECIFICAÇÃO TÉCNICA VERSÃO Eikn Dcuments 2007 Service Pack 5 (2.9.5) Fevereir de 2010 DATA DE REFERÊNCIA DESCRIÇÃO Sftware para implantaçã de sistemas em GED / ECM (Gerenciament Eletrônic

Leia mais

INTRODUÇÃO A LOGICA DE PROGRAMAÇÃO

INTRODUÇÃO A LOGICA DE PROGRAMAÇÃO INTRODUÇÃO A LOGICA DE PROGRAMAÇÃO A Lógica de Prgramaçã é necessária à tdas as pessas que ingressam u pretendem ingressar na área de Tecnlgia da Infrmaçã, send cm prgramadr, analista de sistemas u suprte.

Leia mais

TESTE DE SOFTWARE (Versão 2.0)

TESTE DE SOFTWARE (Versão 2.0) Universidade Luterana d Brasil Faculdade de Infrmática Disciplina de Engenharia de Sftware Prfessr Luís Fernand Garcia www.garcia.pr.br TESTE DE SOFTWARE (Versã 2.0) 9 Teste de Sftware Imprtância Dependência

Leia mais

Workflow. José Palazzo Moreira de Oliveira. Mirella Moura Moro

Workflow. José Palazzo Moreira de Oliveira. Mirella Moura Moro Pdems definir Wrkflw cm: Wrkflw Jsé Palazz Mreira de Oliveira Mirella Mura Mr "Qualquer tarefa executada em série u em paralel pr dis u mais membrs de um grup de trabalh (wrkgrup) visand um bjetiv cmum".

Leia mais

Módulo. A.Apresentação

Módulo. A.Apresentação 1 Módul A A.Apresentaçã Este é um módul cnceitual, que apresenta s prduts e tecnlgias que serã empregads neste livr, intrduzind ainda a arquitetura e métds que servirã de base para as práticas ds móduls

Leia mais

com jcompany Extensions Capítulo Expandindo o Poder do jcompany Developer Suite - Entendendo as melhores práticas de customização

com jcompany Extensions Capítulo Expandindo o Poder do jcompany Developer Suite - Entendendo as melhores práticas de customização A6Extensões Arquiteturais cm jcmpany Extensins Capítul 23 Expandind Pder d jcmpany Develper Suite - Entendend as melhres práticas de custmizaçã Exercitams em váris capítuls as pssibilidades de extensã

Leia mais

PIM TECNOLOGIA EM GERENCIAMENTO DE REDES DE COMPUTADORES (GR3P30)

PIM TECNOLOGIA EM GERENCIAMENTO DE REDES DE COMPUTADORES (GR3P30) UNIP Brasília - Crdenaçã CG/CW/GR/AD Senhres Aluns, Seguem infrmações imprtantes sbre PIM: 1. O QUE É? - Os PIM (Prjet Integrad Multidisciplinar) sã prjets brigatóris realizads els aluns ds curss de graduaçã

Leia mais

GUIA RÁPIDO DE CONFIGURAÇÃO PARA WINDOWS

GUIA RÁPIDO DE CONFIGURAÇÃO PARA WINDOWS GUIA RÁPIDO DE CONFIGURAÇÃO PARA WINDOWS CONTEÚDO 1. Intrduçã... 3 2. Requisits de Sftware e Hardware:... 3 3. Usuári e Grups:... 3 3.1. Cnfigurand cm Micrsft AD:... 3 3.2. Cnfigurand s Grups e Usuáris:...

Leia mais

Capítulo VII Projetos de eficiência energética em iluminação pública Por Luciano Haas Rosito*

Capítulo VII Projetos de eficiência energética em iluminação pública Por Luciano Haas Rosito* 20 Api O Setr Elétric / Julh de 2009 Desenvlviment da Iluminaçã Pública n Brasil Capítul VII Prjets de eficiência energética em iluminaçã pública Pr Lucian Haas Rsit* Neste capítul abrdarems s prjets de

Leia mais

Developer Suite. Capítulo. As oportunidades do ebusiness

Developer Suite. Capítulo. As oportunidades do ebusiness A1Intrduçã a jcmpany Develper Suite Capítul 1 As prtunidades d ebusiness As empresas têm sid desafiadas cm nunca a cmpetirem em escala glbal e, para tal, dmíni das tecnlgias Web nã é mais alg d qual pssam

Leia mais

HARDWARE e SOFTWARE. O Computador é composto por duas partes: uma parte física (hardware) e outra parte lógica (software).

HARDWARE e SOFTWARE. O Computador é composto por duas partes: uma parte física (hardware) e outra parte lógica (software). HARDWARE e SOFTWARE O Cmputadr é cmpst pr duas partes: uma parte física (hardware) e utra parte lógica (sftware). Vcê sabe qual é a diferença entre "Hardware" e "Sftware"? Hardware: é nme dad a cnjunt

Leia mais

Proposta. Projeto: VENSSO. Data 25/05/2005. Andrade Lima Damires Fernandes Andrade Lima Damires Fernandes. Responsável. Autor (s)

Proposta. Projeto: VENSSO. Data 25/05/2005. Andrade Lima Damires Fernandes Andrade Lima Damires Fernandes. Responsável. Autor (s) Prpsta Prjet: Data 25/05/2005 Respnsável Autr (s) Dc ID Andrade Lima Damires Fernandes Andrade Lima Damires Fernandes Lcalizaçã Versã d Template

Leia mais

é a introdução de algo novo, que atua como um vetor para o desenvolvimento humano e melhoria da qualidade de vida

é a introdução de algo novo, que atua como um vetor para o desenvolvimento humano e melhoria da qualidade de vida O que é invaçã? Para a atividade humana: é a intrduçã de alg nv, que atua cm um vetr para desenvlviment human e melhria da qualidade de vida Para as empresas: invar significa intrduzir alg nv u mdificar

Leia mais

GESTÃO DE PROJETOS. Uma visão geral Baseado nas diretrizes do PMI

GESTÃO DE PROJETOS. Uma visão geral Baseado nas diretrizes do PMI GESTÃO DE PROJETOS Uma visã geral Bead n diretrizes d PMI 1 Intrduçã Objetiv da Apresentaçã O bjetiv é frnecer uma visã geral ds prcesss de Gestã de Prjets aplicads à Gestã de Empreendiments. O que é Prjet?

Leia mais

Versão 14.0 Junho 2015 www.psr-inc.com Contato: sddp@psr-inc.com. Representação mais detalhada da operação em cada estágio: 21 blocos

Versão 14.0 Junho 2015 www.psr-inc.com Contato: sddp@psr-inc.com. Representação mais detalhada da operação em cada estágio: 21 blocos Versã 14.0 Junh 2015 www.psr-inc.cm Cntat: sddp@psr-inc.cm SDDP VERSÃO 14.0 Nvidades Representaçã mais detalhada da peraçã em cada estági: 21 blcs Tradicinalmente, a peraçã de cada estági (semana u mês)

Leia mais

Universidade Luterana do Brasil Faculdade de Informática. Disciplina de Engenharia de Software Professor Luís Fernando Garcia www.garcia.pro.

Universidade Luterana do Brasil Faculdade de Informática. Disciplina de Engenharia de Software Professor Luís Fernando Garcia www.garcia.pro. Universidade Luterana d Brasil Faculdade de Infrmática Disciplina de Engenharia de Sftware Prfessr Luís Fernand Garcia www.garcia.pr.br EVOLUÇÃO EM ENGENHARIA DE SOFTWARE 10 Sistemas Legads O investiment

Leia mais

FRWTC-220 DESENVOLVIMENTO DE APLICAÇÕES JAVA WEB

FRWTC-220 DESENVOLVIMENTO DE APLICAÇÕES JAVA WEB FRWTC-220 DESENVOLVIMENTO DE APLICAÇÕES JAVA WEB SOBRE A FRAMEWORK A Framewrk (www.frwtc.cm) atua diretamente cm prfissinais d segment de tecnlgia em busca de capacitaçã, atualizaçã e certificaçã, curss

Leia mais

Modelagem, qualificação e distribuição em um padrão para geoinformações

Modelagem, qualificação e distribuição em um padrão para geoinformações Mdelagem, qualificaçã e distribuiçã em um padrã para geinfrmações Julia Peixt 14h, 14 de junh de 2010. Mtivaçã Acerv de dads desde 1994 em diferentes áreas de pesquisa; Muitas pessas fazend muits trabalhs

Leia mais

Anexo 03 Recomendação nº 3: estatuto padrão, estatuto fundamental e contrato social

Anexo 03 Recomendação nº 3: estatuto padrão, estatuto fundamental e contrato social Anex 03 Recmendaçã nº 3: estatut padrã, estatut fundamental e cntrat scial 1. Resum 01 Atualmente, Estatut da Crpraçã da Internet para a atribuiçã de nmes e númers (ICANN) tem um mecanism únic para alterações.

Leia mais

3. TIPOS DE MANUTENÇÃO:

3. TIPOS DE MANUTENÇÃO: 3. TIPOS DE MANUTENÇÃO: 3.1 MANUTENÇÃO CORRETIVA A manutençã crretiva é a frma mais óbvia e mais primária de manutençã; pde sintetizar-se pel cicl "quebra-repara", u seja, repar ds equipaments após a avaria.

Leia mais

^i * aesíqn e=> ~omunícc3ç:c30

^i * aesíqn e=> ~omunícc3ç:c30 ^i * aesíqn e=> ~munícc3ç:c30 CONTRATO DE LICENÇA DE USO DO SISTEMA - SUBMIT CMS Web Site da Prefeitura de Frei Martinh - Paraíba 1. IDENTIFICAÇÃO DAS PARTES CONTRATANTE Prefeitura Municipal de Frei Martinh

Leia mais

Manual de Instalação e Configuração

Manual de Instalação e Configuração Manual de Instalaçã e Cnfiguraçã Prdut:n-ReleaserEmbedded fr Lexmark Versã 1.2.1 Versã d Dc.:1.0 Autr: Lucas Machad Santini Data: 14/04/2011 Dcument destinad a: Clientes e Revendas Alterad pr: Release

Leia mais

2º Passo Criar a conexão via ODBC (Object DataBase Conection)

2º Passo Criar a conexão via ODBC (Object DataBase Conection) Prjet de Sexta-feira: Prfessra Lucélia 1º Pass Criar banc de dads u selecinar banc de dads. Ntas: Camps nas tabelas nã pdem cnter caracteres acentuads, especiais e exclusivs de línguas latinas. Nã há necessidade

Leia mais

WEB MANAGER. Conhecendo o Web Manager!

WEB MANAGER. Conhecendo o Web Manager! WEB MANAGER Cnhecend Web Manager! O Web Manager é uma pdersa ferramenta para gestã de Sites, prtais, intranets, extranets e htsites. Cm ela é pssível gerenciar ttalmente seus ambientes web. Integrad ttalmente

Leia mais

Matemática / 1ª série / ICC Prof. Eduardo. Unidade 1: Fundamentos. 1 - Introdução ao Computador

Matemática / 1ª série / ICC Prof. Eduardo. Unidade 1: Fundamentos. 1 - Introdução ao Computador Unidade 1: Fundaments 1 - Intrduçã a Cmputadr Cnceits básics e Terminlgias O cmputadr é uma máquina eletrônica capaz de realizar uma grande variedade de tarefas cm alta velcidade e precisã, desde que receba

Leia mais

Anexo V. Software de Registro Eletrônico em Saúde. Implantação em 2 (duas) Unidades de Saúde

Anexo V. Software de Registro Eletrônico em Saúde. Implantação em 2 (duas) Unidades de Saúde Anex V Sftware de Registr Eletrônic em Saúde Implantaçã em 2 (duas) Unidades de Saúde Índice 1 INTRODUÇÃO... 3 2 ESTRATÉGIAS E PROCEDIMENTOS DE IMPLANTAÇÃO... 3 4 INFRAESTRUTURA NAS UNIDADES DE SAÚDE -

Leia mais

Os novos usos da tecnologia da informação nas empresas Sistemas de Informação

Os novos usos da tecnologia da informação nas empresas Sistemas de Informação Os nvs uss da tecnlgia da infrmaçã nas empresas Sistemas de Infrmaçã Prf. Marcel da Silveira Siedler siedler@gmail.cm SERVIÇO NACIONAL DE APRENDIZAGEM COMERCIAL FACULDADE DE TECNOLOGIA SENAC PELOTAS Planejament

Leia mais

Integração com coletores de ponto, catracas, dispositivos de abertura de portas, fechaduras eletromagnéticas,

Integração com coletores de ponto, catracas, dispositivos de abertura de portas, fechaduras eletromagnéticas, Vsft ids Acess Web Cntrle de acess e pnt A Vsft desenvlveu uma sluçã baseada em sftware e hardware para cntrle de acess e u pnt que pde ser utilizada pr empresas de qualquer prte. Cm us da tecnlgia bimétrica

Leia mais

Versões Todos os módulos devem ser atualizados para as versões a partir de 03 de outubro de 2013.

Versões Todos os módulos devem ser atualizados para as versões a partir de 03 de outubro de 2013. Serviç de Acess as Móduls d Sistema HK (SAR e SCF) Desenvlvems uma nva ferramenta cm bjetiv de direcinar acess ds usuáris apenas as Móduls que devem ser de direit, levand em cnsideraçã departament de cada

Leia mais

Os Oito Principais de Sistemas de

Os Oito Principais de Sistemas de Infrme Especial Os Oit Principais in Yur DSD Mits Mbile de Sistemas de Security Strategy Gerenciament de Armazém para empresas de pequen e médi prte. Intrduçã A era das perações manuais em Armazéns está

Leia mais

SGCT - Sistema de Gerenciamento de Conferências Tecnológicas

SGCT - Sistema de Gerenciamento de Conferências Tecnológicas SGCT - Sistema de Gerenciament de Cnferências Tecnlógicas Versã 1.0 09 de Setembr de 2009 Institut de Cmputaçã - UNICAMP Grup 02 Andre Petris Esteve - 070168 Henrique Baggi - 071139 Rafael Ghussn Can -

Leia mais

SEGURANÇA NO TRABALHO CONTRATADOS E TERCEIROS DO CLIENTE

SEGURANÇA NO TRABALHO CONTRATADOS E TERCEIROS DO CLIENTE Flha 1 de 8 Rev. Data Cnteúd Elabrad pr Aprvad pr 0 16/06/2004 Emissã inicial englband a parte técnica d GEN PSE 004 Luiz C. Sants Cmitê da Qualidade 1 31/01/2006 Revisã geral Luiz C. Sants Cmitê da Qualidade

Leia mais

Cursos Profissionais de Nível Secundário (Decreto-Lei n.º 74/2004, de 26 de Março)

Cursos Profissionais de Nível Secundário (Decreto-Lei n.º 74/2004, de 26 de Março) REFERENCIAL DE FORMAÇÃO Curss Prfissinais de Nível Secundári (Decret-Lei n.º 74/2004, de 26 de Març) Família Prfissinal: 07 - Infrmática 1. QUALIFICAÇÕES / SAÍDAS PROFISSIONAIS As qualificações de nível

Leia mais

Gestão do Escopo 1. Planejamento da Gestão do Escopo: 2. Definição do Escopo: 3. Elaboração da EDT(EAP): 4. Verificação do Escopo:

Gestão do Escopo 1. Planejamento da Gestão do Escopo: 2. Definição do Escopo: 3. Elaboração da EDT(EAP): 4. Verificação do Escopo: Gestã d Escp 1. Planejament da Gestã d Escp: i. Autrizaçã d prjet ii. Definiçã d escp (preliminar) iii. Ativs em cnheciments rganizacinais iv. Fatres ambientais e rganizacinais v. Plan d prjet i. Plan

Leia mais

Passo 1 - Conheça as vantagens do employeeship para a empresa

Passo 1 - Conheça as vantagens do employeeship para a empresa Manual Cm intrduzir emplyeeship na empresa Índice Intrduçã Pass 1 - Cnheça as vantagens d emplyeeship para a empresa Pass 2 - Saiba que é a cultura emplyeeship Pass 3 - Aprenda a ter "bns" empregads Pass

Leia mais

DISCIPLINA: Matemática. MACEDO, Luiz Roberto de, CASTANHEIRA, Nelson Pereira, ROCHA, Alex. Tópicos de matemática aplicada. Curitiba: Ibpex, 2006.

DISCIPLINA: Matemática. MACEDO, Luiz Roberto de, CASTANHEIRA, Nelson Pereira, ROCHA, Alex. Tópicos de matemática aplicada. Curitiba: Ibpex, 2006. DISCIPLINA: Matemática 1- BIBLIOGRAFIA INDICADA Bibliteca Virtual Pearsn MACEDO, Luiz Rbert de, CASTANHEIRA, Nelsn Pereira, ROCHA, Alex. Tópics de matemática aplicada. Curitiba: Ibpex, 2006. PARKIN, Michael.

Leia mais

MODELO DE PROGRAMAÇÃO DO WINDOWS AZURE

MODELO DE PROGRAMAÇÃO DO WINDOWS AZURE MODELO DE PROGRAMAÇÃO DO WINDOWS AZURE DAVID CHAPPELL OUTUBRO DE 2010 PATROCINADO PELA MICROSOFT CORPORATION SUMÁRIO Pr que criar um nv mdel de prgramaçã?... 3 Três regras d mdel de prgramaçã d Windws

Leia mais

Relatório de Gerenciamento de Riscos

Relatório de Gerenciamento de Riscos Relatóri de Gerenciament de Riscs 2º Semestre de 2014 1 Sumári 1. Intrduçã... 3 2. Gerenciament de Riscs... 3 3. Risc de Crédit... 4 3.1. Definiçã... 4 3.2. Gerenciament... 4 3.3. Limites de expsiçã à

Leia mais

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

de Desenvolvimento Capítulo Introdução - Alinhando Metodologia com Arquitetura 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

Leia mais

5. PLANEJAMENTO E ORGANIZAÇÃO DA MANUTENÇÃO:

5. PLANEJAMENTO E ORGANIZAÇÃO DA MANUTENÇÃO: 5. PLANEJAMENTO E ORGANIZAÇÃO DA MANUTENÇÃO: 5.1 INTRODUÇÃO A rganizaçã da manutençã era cnceituada, até há puc temp, cm planejament e administraçã ds recurss para a adequaçã à carga de trabalh esperada.

Leia mais

Artigo 12 Como montar um Lava Jato

Artigo 12 Como montar um Lava Jato Artig 12 Cm mntar um Lava Jat Antigamente era cmum bservar as pessas, n final de semana, cm seus carrs, bucha e sabã nas mãs. Apesar de ainda haver pessas que preferem fazer serviç suj szinhas, s lava

Leia mais

Modelo de Negócios. TRABALHO REALIZADO POR: Antonio Gome- 2007009 // Jorge Teixeira - 2008463

Modelo de Negócios. TRABALHO REALIZADO POR: Antonio Gome- 2007009 // Jorge Teixeira - 2008463 Mdel de Negócis Trabalh n âmbit da disciplina de Mdelaçã de dads. Criaçã de uma platafrma utilizand as tecnlgias SQL PHP e Javascript.. TRABALHO REALIZADO POR: Antni Gme- 2007009 // Jrge Teixeira - 2008463

Leia mais

Agenda. A interface de Agendamento é encontrada no Modulo Salão de Vendas Agendamento Controle de Agendamento, e será apresentada conforme figura 01.

Agenda. A interface de Agendamento é encontrada no Modulo Salão de Vendas Agendamento Controle de Agendamento, e será apresentada conforme figura 01. Agenda Intrduçã Diariamente cada um ds trabalhadres de uma empresa executam diversas atividades, muitas vezes estas atividades tem praz para serem executadas e devem ser planejadas juntamente cm utras

Leia mais

FRWTC-200 INTRODUÇÃO JAVA SE

FRWTC-200 INTRODUÇÃO JAVA SE FRWTC-200 INTRODUÇÃO JAVA SE SOBRE A FRAMEWORK A Framewrk (www.frwtc.cm) atua diretamente cm prfissinais d segment de tecnlgia em busca de capacitaçã, atualizaçã e certificaçã, curss IN-COMPANY persnalizads

Leia mais

táxis compartilhados Shared-transport / Shared-taxi

táxis compartilhados Shared-transport / Shared-taxi Benefícis ds serviçs de transprte de táxis cmpartilhads Shared-transprt / Shared-taxi Reuniã de Especialistas sbre Transprte Urban Sustentável: Mdernizand e Trnand Eclógicas as Frtas de Táxis nas Cidades

Leia mais

Regulamento da Feira de Ciência

Regulamento da Feira de Ciência Regulament da Feira de Ciência A Feira A Feira de Ciência é um é um prject rganizad pel Núcle de Física d Institut Superir Técnic (NFIST). Esta actividade cnsiste em desenvlver um prject científic pr um

Leia mais

CURSO PREPARATÓRIO PARA CERTIFICAÇÃO

CURSO PREPARATÓRIO PARA CERTIFICAÇÃO Cnteúd prgramátic CURSO PREPARATÓRIO PARA CERTIFICAÇÃO Este é cnteúd prgramátic d curs preparatóri n nv prgrama CDO-0001 para a certificaçã CmpTIA CDIA+. CONCEITUAL ECM Apresentaçã ds cnceits envlvids

Leia mais

Proposta. Treinamento Lean Thinking Mentalidade Enxuta. Apresentação Executiva

Proposta. Treinamento Lean Thinking Mentalidade Enxuta. Apresentação Executiva Treinament Lean Thinking Mentalidade Enxuta www.masterhuse.cm.br Prpsta Cm Treinament Lean Thinking Mentalidade Enxuta Apresentaçã Executiva Treinament Lean Thinking Mentalidade Enxuta Cpyright 2011-2012

Leia mais

REGULAMENTO 1- OBJETIVO

REGULAMENTO 1- OBJETIVO REGULAMENTO 1- OBJETIVO O Prgrama Nv Temp é um iniciativa da Cargill Agricla SA, que visa ferecer as seus funcináris e das empresas patrcinadras ds plans de previdência sb a gestã da CargillPrev Sciedade

Leia mais

PROJETO 22ª MOSTRA ESTUDANTIL TECNOLÓGICA Dias 22 e 23 DE OUTUBRO DE 2014 CURSO: GESTÃO EMPRESARIAL

PROJETO 22ª MOSTRA ESTUDANTIL TECNOLÓGICA Dias 22 e 23 DE OUTUBRO DE 2014 CURSO: GESTÃO EMPRESARIAL PROJETO 22ª MOSTRA ESTUDANTIL TECNOLÓGICA Dias 22 e 23 DE OUTUBRO DE 2014 CURSO: GESTÃO EMPRESARIAL Objetivs: Gestã Empresarial Desenvlver cmpetências para atuar n gerenciament de prjets, prestand cnsultria

Leia mais

CONTROLE INTERNO NA INDÚSTRIA AUTOMOBILÍSTICA: Um Estudo de Caso

CONTROLE INTERNO NA INDÚSTRIA AUTOMOBILÍSTICA: Um Estudo de Caso CONTROLE INTERNO NA INDÚSTRIA AUTOMOBILÍSTICA: Um Estud de Cas Camila Gmes da Silva 1, Vilma da Silva Sant 2, Paul César Ribeir Quintairs 3, Edsn Aparecida de Araúj Querid Oliveira 4 1 Pós-graduada em

Leia mais

III.3. SISTEMAS HÍBRIDOS FIBRA/COAXIAL (HFC)

III.3. SISTEMAS HÍBRIDOS FIBRA/COAXIAL (HFC) 1 III.3. SISTEMAS HÍBRIDOS FIBRA/COAXIAL (HFC) III.3.1. DEFINIÇÃO A tecnlgia HFC refere-se a qualquer cnfiguraçã de fibra ótica e cab caxial que é usada para distribuiçã lcal de serviçs de cmunicaçã faixa

Leia mais

Novo Sistema Almoxarifado

Novo Sistema Almoxarifado Nv Sistema Almxarifad Instruções Iniciais 1. Ícnes padrões Existem ícnes espalhads pr td sistema, cada um ferece uma açã. Dentre eles sã dis s mais imprtantes: Realiza uma pesquisa para preencher s camps

Leia mais

REGULAMENTO DE ESTÁGIO DE INICIAÇÃO PROFISSIONAL

REGULAMENTO DE ESTÁGIO DE INICIAÇÃO PROFISSIONAL REGULAMENTO DE ESTÁGIO DE INICIAÇÃO PROFISSIONAL Intrduçã O presente Regulament cnstitui um dcument intern d curs de Ciências Cntábeis e tem pr bjetiv reger as atividades relativas a Estági de Iniciaçã

Leia mais

GT-ATER: Aceleração do Transporte de Dados com o Emprego de Redes de Circuitos Dinâmicos. RT3 - Avaliação dos resultados do protótipo

GT-ATER: Aceleração do Transporte de Dados com o Emprego de Redes de Circuitos Dinâmicos. RT3 - Avaliação dos resultados do protótipo GT-ATER: Aceleraçã d Transprte de Dads cm Empreg de Redes de Circuits Dinâmics RT3 - Avaliaçã ds resultads d prtótip Sand Luz Crrêa Kleber Vieira Cards 03/08/2013 1. Apresentaçã d prtótip desenvlvid Nesta

Leia mais

CIRCULAR. Circular nº 17/DSDC/DEPEB/2007. Gestão do Currículo na Educação Pré-Escolar. Contributos para a sua Operacionalização

CIRCULAR. Circular nº 17/DSDC/DEPEB/2007. Gestão do Currículo na Educação Pré-Escolar. Contributos para a sua Operacionalização CIRCULAR Data: 2007/10/10 Númer d Prcess: DSDC/DEPEB/2007 Assunt: GESTÃO DO CURRÍCULO NA EDUCAÇÃO PRÉ-ESCOLAR Circular nº 17/DSDC/DEPEB/2007 Para: Inspecçã-Geral de Educaçã Direcções Reginais de Educaçã

Leia mais

ISO 9001:2008 alterações à versão de 2000

ISO 9001:2008 alterações à versão de 2000 ISO 9001:2008 alterações à versã de 2000 Já passaram quase it ans desde que a versã da ISO 9001 d an 2000 fi publicada, que cnduziu à necessidade de uma grande mudança para muitas rganizações, incluind

Leia mais

Apresentação do Curso

Apresentação do Curso At endi m ent acl i ent e Apr es ent aç ãdc ur s Apresentaçã d Curs O curs Atendiment a Cliente fi elabrad cm bjetiv de criar cndições para que vcê desenvlva cmpetências para: Identificar s aspects que

Leia mais

Plano de aulas 2010 1ª série 1ª aula 2ª etapa

Plano de aulas 2010 1ª série 1ª aula 2ª etapa Plan de aulas 2010 1ª série 1ª aula 2ª etapa Escla Clégi Eng Juarez Wanderley Prfessr Fernand Nishimura de Aragã Disciplina Infrmática Objetivs Cnstruçã de um website pessal para publicaçã de atividades

Leia mais

Unidade 7: Sínteses de evidências para políticas

Unidade 7: Sínteses de evidências para políticas Unidade 7: Sínteses de evidências para plíticas Objetiv da Unidade Desenvlver um entendiment cmum d que é uma síntese de evidências para plíticas, que inclui e cm pde ser usada 3 O que é uma síntese de

Leia mais

Poder e escola: Uma analise acerca das relações entre professor e aluno.

Poder e escola: Uma analise acerca das relações entre professor e aluno. Pder e escla: Uma analise acerca das relações entre prfessr e alun. Marcs Paul A. Rdrigues 1 Andersn Silva Nunes 2 Intrduçã: O presente trabalh expõe s tips de pder exercid pels prfessres sbre s aluns,

Leia mais

Relatório de Gerenciamento de Riscos

Relatório de Gerenciamento de Riscos Relatóri de Gerenciament de Riscs 2º Semestre de 2015 1 Sumári 1. Intrduçã... 3 2. Gerenciament de Riscs... 3 2.1. Organgrama... 4 3. Risc de Crédit... 4 3.1. Definiçã... 4 3.2. Gerenciament... 4 3.3.

Leia mais

CAPÍTULO IV. Valores, Crenças, Missão, Visão.e Política da Qualidade. Waldemar Faria de Oliveira

CAPÍTULO IV. Valores, Crenças, Missão, Visão.e Política da Qualidade. Waldemar Faria de Oliveira CAPÍTULO IV Valres, Crenças, Missã, Visã.e Plítica da Qualidade. Waldemar Faria de Oliveira Há alguns ans, quand tínhams ótims atletas, perdíams a Cpa d Mund de futebl, as Olimpíadas, errand em cisas básicas.

Leia mais

PDF Livre com o Ghostscript

PDF Livre com o Ghostscript PDF Livre cm Ghstscript Um tutrial para criaçã de um geradr de arquivs PDF em Windws, basead em ferramentas gratuitas. Márci d'ávila, 05 de mai de 2004. Revisã 8, 20 de setembr de 2007. Categria: Text

Leia mais

CONSIDERAÇÕES DA CAPGEMINI

CONSIDERAÇÕES DA CAPGEMINI CONSIDERAÇÕES DA CAPGEMINI 6.1 Requisits de Capacidade e Experiência d Prestadr A ANEEL deveria exigir um puc mais quant a estes requisits, de frma a garantir uma melhr qualificaçã da empresa a ser cntratada.

Leia mais

REGULAMENTO CONCURSO DE IDEIAS OESTECIM A MINHA EMPRESA

REGULAMENTO CONCURSO DE IDEIAS OESTECIM A MINHA EMPRESA 1. Intrduçã e Objetivs a) O Cncurs de Ideias OESTECIM a minha empresa pretende ptenciar apareciment de prjets invadres na regiã d Oeste sempre numa perspetiva de desenvlviment ecnómic e scial. b) O Cncurs

Leia mais

Nascia um novo nicho de mercado: o dos Ambientes Integrados de Desenvolvimento, ou IDEs (Integrated Development Environment).

Nascia um novo nicho de mercado: o dos Ambientes Integrados de Desenvolvimento, ou IDEs (Integrated Development Environment). A6Entendend Ambiente de Desenvlviment Capítul 3 Intrduçã - A breve história d mercad de IDEs Até a década de 80, um desenvlvedr de sftware típic lidava cm uma diversidade de ferramentas para realizar seu

Leia mais

Processos de desumidificação visam manter a Umidade Relativa do Ar em níveis abaixo de 50%.

Processos de desumidificação visam manter a Umidade Relativa do Ar em níveis abaixo de 50%. 1. TEORIA Para prcesss específics de utilizaçã, é necessári manter cndições de temperatura e umidade relativa d ar em cndições específicas para prduçã e u trabalh. Prcesss de desumidificaçã visam manter

Leia mais

PORTARIA N. 8.605 de 05 de novembro de 2013.

PORTARIA N. 8.605 de 05 de novembro de 2013. PORTARIA N. 8.605 de 05 de nvembr de 2013. Altera a Plítica de Segurança da Infrmaçã n âmbit d Tribunal Reginal d Trabalh da 4ª Regiã. A PRESIDENTE DO, n us de suas atribuições legais e regimentais, CONSIDERANDO

Leia mais

Metodologia de Desenvolvimento de Sistemas

Metodologia de Desenvolvimento de Sistemas Guia d Prcess de Sftware d MAPA Metdlgia de Desenvlviment de Sistemas Versã 1.0 Dcument cnfidencial e prprietári Versã d mdel: 1.1 Históric das Revisões Data Versã Descriçã Autr 24/03/2008 1.0 Iníci da

Leia mais

Gerenciamento do Escopo

Gerenciamento do Escopo Pós-graduaçã Gestã Empresarial Módul GPE Gestã de Prjets Empresariais Prf. MSc Jsé Alexandre Mren prf.mren@ul.cm.br agst_setembr/2009 1 Gerenciament d Escp 3 Declaraçã d escp Estrutura Analítica d Prjet

Leia mais

Roteiro de Implantação Estoque

Roteiro de Implantação Estoque Rteir de Implantaçã Estque Revisã: 23/07/2004 Abrangência Versã 7.10 Cadastrs Básics Dicas: Explique a necessidade d preenchiment ds brigatóris (camps na cr azul). Verifique se cliente necessita que mais

Leia mais

Art. 2º. Trata-se de uma promoção de caráter exclusivamente de estimulo cultural, profissional e acadêmico sem vínculo com sorteios.

Art. 2º. Trata-se de uma promoção de caráter exclusivamente de estimulo cultural, profissional e acadêmico sem vínculo com sorteios. Prêmi Data Pint de Criatividade e Invaçã - 2011 N an em que cmpleta 15 ans de atuaçã n mercad de treinament em infrmática, a Data Pint ferece à cmunidade a prtunidade de participar d Prêmi Data Pint de

Leia mais

Sistema de Gestão de BPM

Sistema de Gestão de BPM 1/13 ESTA FOLHA ÍNDICE INDICA EM QUE REVISÃO ESTÁ CADA FOLHA NA EMISSÃO CITADA R. 0 1 2 3 4 5 6 7 8 9 10 11 12 13 R. 0 1 2 3 4 5 6 7 8 9 10 11 12 13 FL. FL. 01 X 26 02 X 27 03 X 28 04 X 29 05 X 30 06 X

Leia mais

GUIA DE RELACIONAMENTO MT-COR: 001 Revisão: 000

GUIA DE RELACIONAMENTO MT-COR: 001 Revisão: 000 GUIA DE RELACIONAMENTO MT-COR: 001 Revisã: 000 A Mercur S.A., empresa estabelecida desde 1924, se precupa em cnduzir as suas relações de acrd cm padrões étics e cmerciais, através d cumpriment da legislaçã

Leia mais

Análise e Design: Visão Geral

Análise e Design: Visão Geral Análise e Design: Visã Geral As finalidades da disciplina Análise e Design sã: Transfrmar s requisits em um design d sistema a ser criad. Desenvlver uma arquitetura sfisticada para sistema. Adaptar design

Leia mais

CÂMARA DOS DEPUTADOS Gabinete do Deputado FERNANDO JORDÃO - PMDB/RJ Brasília, 21 de março de 2011.

CÂMARA DOS DEPUTADOS Gabinete do Deputado FERNANDO JORDÃO - PMDB/RJ Brasília, 21 de março de 2011. Gabinete d Deputad FERNANDO JORDÃO - PMDB/RJ Brasília, 21 de març de 2011. Quand ingressei cm Requeriment slicitand a presença de Vssas Senhrias na Cmissã, estava assustad, cm, aliás, tda a ppulaçã, cm

Leia mais

PLATAFORMA EMPRESAS PELO CLIMA

PLATAFORMA EMPRESAS PELO CLIMA PLATAFORMA EMPRESAS PELO CLIMA CAMINHO PARA ELABORAÇÃO DE AGENDAS EMPRESARIAIS EM ADAPTAÇÃO ÀS MUDANÇAS DO CLIMA Prpsta de Framewrk Resultad d diálg crrid em 26 de junh de 2013, n Fórum Latin-American

Leia mais

Aproveitamento da informação permite ganho de competitividade: conhecimento é poder (e poder = $$!)

Aproveitamento da informação permite ganho de competitividade: conhecimento é poder (e poder = $$!) Data Mining Prfessr Jrge Mreira jmreirajr@htmail.cm Mtivaçã A infrmatizaçã ds meis prdutivs permitiu a geraçã de grandes vlumes de dads: Transações eletrônicas; Nvs equipaments científics e industriais

Leia mais

1 Institucional. 1.1 Sobre a Vensis. 1.2 Missão, Políticas e Valores. 1.2.1 Missão. 1.2.2 Política da Qualidade

1 Institucional. 1.1 Sobre a Vensis. 1.2 Missão, Políticas e Valores. 1.2.1 Missão. 1.2.2 Política da Qualidade Institucinal 1 Institucinal 1.1 Sbre a Vensis A Vensis é uma empresa especializada n desenvlviment de sluções integradas para gestã de empresas. Atuand n mercad de tecnlgia da infrmaçã desde 1998, a empresa

Leia mais

Ontologias: da Teoria à Prática

Ontologias: da Teoria à Prática Ontlgias: da Teria à Prática I Escla de Ontlgias UFAL-USP Endhe Elias e Olav Hlanda Núcle de Excelência em Tecnlgias Sciais - NEES Universidade Federal de Alagas UFAL Rteir Mtivaçã Ontlgias Engenharia

Leia mais

Alterações na aplicação do Critério Brasil, válidas a partir de 01/01/2013

Alterações na aplicação do Critério Brasil, válidas a partir de 01/01/2013 Alterações na aplicaçã d Critéri Brasil, válidas a partir de 01/01/2013 A dinâmica da ecnmia brasileira, cm variações imprtantes ns níveis de renda e na psse de bens ns dmicílis, representa um desafi imprtante

Leia mais

Software Para Controle de Acesso e Ponto

Software Para Controle de Acesso e Ponto Sftware Para Cntrle de Acess e Pnt Características e Funcinalidades Versã 2.0 Inipass é marca registrada da Prjedata Infrmática Ltda. Tds s direits reservads à Prjedata Infrmática Ltda. Características

Leia mais

Soluções Benefix para Varejo (NFC-e)

Soluções Benefix para Varejo (NFC-e) BENEFIX SISTEMAS E GESTÃO DE NEGÓCIOS LTDA Rua da Cnceiçã, 95, Niterói / RJ Telefne: +55 21 2621-5063 Telefne: +55 41 3353-3839 E-mail: cntat@e-benefix.cm.br Sluções Benefix para Varej (NFC-e) Sluções

Leia mais

POLÍTICA DE GESTÃO DE RISCOS DAS EMPRESAS ELETROBRAS

POLÍTICA DE GESTÃO DE RISCOS DAS EMPRESAS ELETROBRAS POLÍTICA DE GESTÃO DE RISCOS DAS EMPRESAS ELETROBRAS Versã 0.0 25/10/2010 Sumári 1 Objetivs... 3 2 Cnceits... 3 3 Referências... 3 4 Princípis... 3 5 Diretrizes d Prcess... 4 6 Respnsabilidades... 5 7

Leia mais

Inscrição do Candidato ao Processo de Credenciamento

Inscrição do Candidato ao Processo de Credenciamento Inscriçã d Candidat a Prcess de Credenciament O link de inscriçã permitirá que candidat registre suas infrmações para participar d Prcess de Credenciament, cnfrme Edital. Após tmar ciência de td cnteúd

Leia mais