PadrCoes de projeto, aprecie

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

Download "PadrCoes de projeto, aprecie"

Transcrição

1 SECA BOAS PRATICAS: NESTA SECA VOCE ENCONTRA ARTIGOS SOBRE TECNICAS QUE PODERAO AUMENTAR A QUA1 PadrCoes de projeto, aprecie Principios para a utilizacäo adequada de Resumo DevMan De que se trata o artigo: 0 artigo trata de apresentar principios, discussoes e ref lexties sobre a utilizacao de padroes de projeto, para ajudar o leitor a desenvolver senso critico sobre os mesmos.assim, o leitor podera extrair de si mesmo o conhecimento para a aplicacao de padroes de projeto corn moderacào. Em que situadio o tema e tit& 0 terra é Otil por alertar o desenvolvedor sobre a utilizacao adequada de padroes de projeto, que sào solucties para determinados problemas, mas que tambe,m podem ser problemas para determinadas solu- Oes. importanteaodesenvolvedor saber julgar a utilizacao de urn padrao de projeto em urn determinado contexto, avaliando sua aplicabilidade e consequencias, buscando a solucao ideal., Padrties de projeto, aprecie com moderagio: Este artigo apresenta reflexi5es a respeito da utilizacao de padrties de projeto, e descrevealgumas causas comunsda ma utilizacao dos mesmos, alem de alguns exemplos de ma implementacao. Ern seguida, mostra os principios GRASP e sua relacao corn os padroes de projeto, para orientar o desenvolvedor a utiliza-los adequadamente. Ao final, disponibiliza perguntas para avaliar a implementacao de urn padrao de projeto e consideracoes para o leitor desenvolver seu senso critico. ao ha como negar a in fluencia deste termo na vida de quem N trabalha corn desenvolvimento de software. Seja por bem ou por mal, os padroes de projeto estdo presentes ha mais de uma decada, talvez desde que comecaram a possibilitar melhorias no desenvolvimento de software, ou entdo quando comecaram a serem vistos com bons olhos pelo mercado de trabalho. Todavia, tambem comecaram a causar deterioracäo de codigo e discordias, seja por mau uso, falta de entendimento a respeito ou falta de planejamento. Desta forma, passaram a ser criticados ao mesmo tempo em que elogiados. Tipicamente, padroes de projeto sao certamente beneficos, desde que implementados de maneira adequada e tendo em mente certos principios alguns dos quais serdo apresentados aqui. A intencdo deste artigo é esclarecer aos que lidam corn padroes de projeto, tanto os que forem a favor quanto os que forem contra, que padroes de projeto nab säo balas de prata. Eles podem ser solucaes para determinados problemas e problemas para determinadas solucoes. Por isso, é importante analisar cada situacdo corn senso critico. Portanto, serdo apresentados conceitos, principios e exemplos que the permitirao identificar situagoes parecidas em seu diaa-dia, alem de consideracoes gerais para aplicar seu senso critic() visando alcancar uma solucdo adequada. Em busca do codigo perfeito Ser urn experiente desenvolvedor de software ndo e um patamar que se alcanca de urn dia para o outro. Sao necessarios anos e anos de criteriosos estudos e vivencia profissional para se tornar digno de tal denomina0o. Para reduzir este hiato, muitos desenvolvedores procuram aprimorar-se nos atri- 54 Java Magazine Edich 98

2 DADE DO DESENVOLVIMENTO DE SOFTWARE com moderacäo adthes de projeto Aprimore seu senso critic a respeito da utilizacäo de padriies de projeto, confira situagies, reflexties e sua relacio com os principios GRASP TIAGO ROMERO GARCIA butos geralmente louvados que todo habilidoso desenvolvedor de softwares deva possuir. 0 que é de fato uma boa iniciativa, desde que se de minuciosa atencao a cada habilidade aprimorada. 0 problema acontece quando o desenvolvedor quer chegar neste nivel muito rapid, e acaba pecando no nivel de criteria afirmando saber algo que apenas tern uma nocao, e na hora da pratica acaba faltando o devido embasamento teorico. E exatamente o caso dos padroes de projeto. E muito facil alguern "achar que sabe bem" pad roes de projeto simplesmente por ter visto algumas implementacoes, ou por ter lido em alguma revista. claro que temos excecoes, mas geralmente e necessario urn pouco mais de vivencia para a real compreensao. E justamente pela tal falta de vivencia, criam-se situacoes onde pad roes de projeto nao sac, devidamente utilizados. Para exemplificar, confira algumas causas comuns da ma utilizacäo de padroes de projeto: Desatenccio a definiccio de padrdo 0 proposito real dos padroes de projeto é muitas vezes deixado de lado. Segundo Craig Larman, em seu livro Applying UML and Patterns (2005), urn padrao é urn par nomeado de problema/ solucäo que pode ser aplicado em urn determinado contexto, possuindo orientacao em como ser aplicado e discussao de suas consequencias. Desta forma, ao utilizar qualquer padrao, todo desenvolvedor deve atentar a duas premissas: Apenas implementar o padrao se sua aplicabilidade estiver de acordo corn o cenario; Apenas implementar o padrao se suas consequencias forem aceitaveis no cenario. Quem implementa padroes tern toda a responsabilidade pelo que esta introduzindo, entao o minim que se espera é que se busque justificar a introducao do padrao a partir das premissas aci ma. Vejamos urn exemplo favoravel a introducao de urn padrao de projeto: em urn sistema de e-commerce, é requisitado que o usuario possa escolher dentre diversos criterios para ordenar os resultados. Assim, um desenvolvedor considera o use do padrao de projeto GoF Strategy (Estrategia). Ao consultar a aplicabilidade de Strategy, ele percebe que sua ideia esta de acordo corn a proposta do padrao, visto que temos diversas variacoes de urn algoritmo, nao é desejavel expor os detalhes de cada algoritmo e a escol ha do criterio seria tipicamente codificada corn condicionais maltiplos. Agora, ao consultar as consequéncias de Strategy, ele verifica que criard uma familia de algoritmos relacionados, eliminard condicionais mtiltiplos e podera escolher urn criterio diferente a qualquer momento. Por outro lado, havera urn maior mlmero de objetos em memoria, o codigo cliente precisara estar pronto para receber diversos Strategies e havera urn overhead de comunicacao entre os Strategies e o contexto. Assim, apos verificar os impactos de tais consequencias perante os ganhos, considerando as particularidades do projeto em questao, o desenvolvedor conclui que e aconselhavel utilizar este padrao de projeto. Para ver urn exemplo desfavoravel, confira o topico Shortcut Factory a seguir, dentro da secao Exemplos de ma implementacao de padroes de projeto. Falta de simplicidade Uma das mais desrespeitadas premissas-chave no desenvolvimento de software é a de manter a simplicidade, ou seja, fazer apenas o necessario, adicionando o mini mo possivel de complexidade. Os autores do livro Head First Design Patterns (2004) explicam que os desenvolvedores da sua equipe sempre irao apreciar e admirar a simplicidade do seu codigo. Ha muitas vantagens nisso: o codigo fica menos susceptive! a erros, mais facia de compreender, havera menos documentacao, menos testes unitarios, etc. Tudo isso porque ha menos complexidade. Urn exemplo comum: certas vezes, alguns desenvolvedores nao consideram remover urn padrao de projeto que esta implementado, mesmo que ele esteja urn pouco fora de contexto ou introduzindo complexidade desnecessaria, apenas porque esta bonito no meio da arquitetura do software. Neste caso, e necessario deixar o apego ao codigo de!ado em favor de uma melhor efetividade geral. Cargo cult programming Outra causa nao incomum da ma utilizacao de padroes de projeto e conhecida por "cargo cult programming", que significa "programacao do culto a carga". Segundo a Wikipedia, "culto a carga e urn grupo de movimentos religiosos que aparece em sociedades tribais. (...) Surge corn o fato de os nativos observarem grupos industrializados recebendo material por encomendas (cargas), geralmente grupos militares recebendo suprimentos por barcos e avioes. Os nativos acabam nao compreendendo a origem destas cargas e atribuindo isto a Edich 98 Java Magazine 55

3 PadrOes de projeto, aprecie com moderacio causas sobrenaturais. Muitas vezes, grupos ritualisticamente imitam a forma de andar e se vestir dos grupos industrializados na esperanca de receber tambem a "carga" destas entidades sobrenaturais.". De semel ha nte maneira, alguns programadores cultuam o ritual de incluir codigos que nao tern proposito algum, acreditando que alcancarao sucesso por causas sobrenaturais. Geralmente, o programador esta trabalhando em um defeito, o qual nao esta entendendo, e por pressao e desespero joga urn codigo que nao compreende, mas que milagrosamente fez o defeito sum ir (ou pior, permanecer, mas ficar maquiado). Urn exemplo de tal ritual é a inclusao de um padrao de projeto ern urn cenario totalmente desnecessario. Assim, obtem um codigo elegante que agradard o lider tecnico, que adora ver seus desenvolvedores acrescentando padroes de projeto. 0 que se torna LI ma ilusao generalizada.?senvolvedor sedento por padroes e ainda por cima vidente Alguns desenvolvedores que acabaram de aprender sobre padroes de projeto e estâo sedentos para implements-los possuem um comportamento negativo: projetar mentalmente a implementacao de padroes de projeto em qualquer brecha que vier em seus p rojetos, independentemente se isso vai ou nao ao encontro dos requisitos de negocio ou as especificacoes tecnicas. Assim, ao observar urn cenario, um desenvolvedor ja imagina ma situacao onde no futuro podera existir algum outro requisito, ou ate mesmo a evolucáo de um requisito atual que demonstrard a necessidade de utilizacao de princfpios como polimorfismo e indirecâo. Sem consultar ninguern, ele ja sai desenvolvendo urn cenario complexo, susceptive] a erros, diffcil de ser testado e, alem de tudo, corn uma grande possibilidade de nunca ser utilizado. Assim sendo, sua decisao acaba impactando em atraso e no custo do projeto, visto que vai requerer mais horas de testes, mais documentacao e ainda e possfvel que tenha introduzido algum defeito ou brecha no codigo. Nor ainda e o cenario onde o desenvolvedor arquiteta o use de d [versos padroes de projeto ao mesmo tempo, mais por satisfacâo pessoal que por necessidade, simplesmente para dizer que implementou tal padrao antes", criando assim camadas e camadas de indirecao e comprometendo a performance e legibilidade. Os autores do livro Head First Design Patterns (2004) deixam bem claro: voce nao deve pensar que nao é urn desenvolvedor sofisticado se nao utilizar urn padrao para solucionar urn problema. Exemplos de ma implements* de padriies de projeto A implementacao fracassada de padroes de projeto acontece mu i- tos vezes por causas como as citadas anteriormente. Sao deixadas de lado importantes consideracoes e princfpios, e sao adotados raciocfnios passfveis de fracassos, que apresentam despreparo em avaliacâo de impacto. Para exempl ificar o que estamos discutindo, neste topico yams analisar tres situagoes de ma implementacao de padroes de projeto. Indireccio desnecessaria Ind i recâo e urn princfpio comum em padroes de projeto, que acontece quando o resultado de uma responsabilidade e transferido para outra classe, geralmente como delegacao ou heranca. Este princfpio e melhor detalhado posteriormente neste artigo, na secdo Princfpios GRASP. Agora, muita indirecao pode ser urn exemplo de ma implementacao, pois a responsabilidade e transferida excessivamente, criando complexidade e aumentando o tamanho da pilha de execucao. E certo que certas vezes isto é algo inevitavel, mas deve ser evitado sempre que possfvel. Note a delegacao excessiva nas Listagens 1, 2, 3 e 4, envolvendo os padrbes de projeto J2EE Business Object (Objeto de NegOcio), Business Delegate (Delegacao de NegOcio) e o padrao de projeto GoF Facade (Fachada). Este exemplo ilustra a construcao de estatisticas de venda para obter-se a receita diaria, em um cenario tfpico de uma aplicacao Java EE, onde Business Objects representam a responsabilidade pela logica de negocio, Business Delegate representam a delegacao de pa rtes da logica de neg6cio a objetos mais especificos, e Facade responde por um subsistema encapsulado. Para reflexao: Como voce melhoraria este cenario se the fosse solicitado? Considere que o seu anal ista de sistemas decidiu que necessario reduzir a complexidade e a pilha de execucao o maxim possfvel dentro de cada pacote Java. Singletonite, ou "singletonitis" Singletonite e uma "doenca" que faz voce utilizar muitas vezes o pad rão de projeto GoF Singleton, mesmo quando nä é necessario. E definida por Antonio Vieiro em seu artigo "Singletonitis". Sua causa e comum, visto que é urn padrao de projeto largamente utilizado e difundido, e sendo assi m Mc) conhecido, torna-se urn alvo facil para interpretacoes erroneas. A segui r, eis algumas das pri ncipa is consequencias: Singletons podem nao ser tinicos: ha frameworks que implementam o conceito de Singleton, como o Spring, onde pode-se determinar que uma certa classe sera instanciada como urn Singleton, e o framework ficara responsavel por isto. No entanto, ao implementar urn Singleton em codigo Java puro, utiliza-se static para armazenar a instancia na classe. Assim, tern-se que tal Singleton é 6 nico por classloader. No entanto, aplicacoes Java EE podem utilizar mais de urn classloader, e desta maneira pode haver mais de uma instancia deste Singleton; Singletons nao foram projetados para multithreading: a pretensào do Singleton de ser tinico na aplicacao faz corn que certos problemas fiquem mais complexos, por tornar mais diffcil o compartilhamento de recursos entre threads. Por exemplo: como compartilhar adequadamente uma instancia de urn Singleton entre diversas threads, de maneira sincrona? 0 problema esta quando voce desenvolve considerando uma instancia Unica, usando urn Singleton, e repentinamente descobre que esta instancia Unica esta presente em diversas threads; Singletons podem proporcionar alto acoplamento: Singletons podem promover acoplamento entre pa rtes de uma aplicacdo 56 Java Magazine Edicâo 98

4 que nao deveriam ser acopladas. Por exemplo, imagine que ha urn Singleton sendo acessado tanto pela camada de apresentacáo quanto pela camada de negocio. Considere agora que foi decidido replicar a camada de negocio em 10 servidores de aplicac5o e a camada de apresentacäo em 2 servidores web. A situacäo fica complicada porque o mesmo Singleton esta acoplado em a mbas as camadas, criando urn di ficil problema de compartilhamento de urn recurso em diversos servidores; Singletons atrapalham testes unitarios: o objetivo de fazer testes unitarios e o de testar cada classe independentemente, mas se a classe fizer use de urn Singleton, sera necessario testar Singleton junto, pois ha urn acoplamento entre a classe e o mesmo; Singletons sdo imutiveis: Singletons nä sac) polimorficos. Portanto, qualquer mudanca devera ser feita em termos de codigo. Se em tempo de producâo for necessario adicionar urn parametro a urn metodo do Singleton, nä sera possivel utilizar uma estrategia em tempo de execucao como a insercao de uma classe que estende o Singleton corn a desejada alteracäo. Para reflex5o: Voce consegue identificar algum sintoma de Singleton ite em algum Singleton que voce tenha implementado? Em caso positivo, é possivel planejar uma "cura"? Considere cada uma das consequencias apresentadas acima corn respeito ao seu Singleton. Ao identificar urn sintoma, trabalhe na origem do problema, e nao em seu resultado. Em algumas situaccies, pode ser melhor remover o Singleton do sistema ao inves de remedia-lo. Shortcut Factory Outro exemplo recorrente pode ser chamado de Shortcut Factory (Fabrica-atalho). Neste caso, o padfao de projeto GoF Factory (Fabrica) é usado simplesmente para servir como atalho para a instanciacâo de urn objeto, que seria feita em uma longa linha de codigo. A justificativa para isto e puro capricho do desenvolvedor e nada mais que isso. De acordo corn o GoF, no livro Design Patterns (1994), Factory é aplicavel quando: Uma classe nao sabe de antemao qual é. a classe dos objetos que devem ser criados por ela; Uma classe deseja que suas subclasses decidam qual é a classe dos objetos que devem ser criados por ela; Uma classe delega responsabilidades a uma de varias subclasses auxiliadoras, e voce deseja saber qual é a subclasse auxiliadora delegada. Estas sâo as justificativas de aplicabilidade de Factory. Portanto, se voce criou urn metodo para facilitar a instanciacâo de objetos conhecidos, voce nä implementou Factory. Veja o exemplo da Listagem 5. Para reflexdo: Quais alteracoes poderiam justificar a aplicacao de Factory? Considere motivos condizentes corn a aplicabilidade de Factory neste cenario. Como devem ser os requisitos para que a implementacao seja valida? Listagem 1. C6digo da classe EstatisticasManager. package br.com.javamagazine.estatisticas; import java.util.date; import br.com.javamagazine.vendas.vendasbusinessobject; public class EstatisticasManager private VendasBusinessObject salesbusinessobject; public void construirestatisticasdiarias() ( //... String receitadiaria = salesbusinessobject.obterreceitadiaria(new Date()); //... Listagem 2. COdigo da classe VendasBusinessObject. package br.com.javamagazine.vendas; import java.util.date; public class VendasBusinessObject private VendasBusinessDelegate vendasbusinessdelegate; public String obterreceitadiaria(date date) { return vendasbusinessdelegate.obterreceitadiaria(date); } // Mais metodos... Listagem 3. COdigo da classe VendasBusinessDelegate. package br.com.javamagazine.vendas; import java.util.date; import br.com.javamagazine.relatorios.relatoriosfacade; public class VendasBusinessDelegate { private RelatoriosFacade relatoriosfacade; public String obterreceitadiaria(date date) { return relatoriosfacade.obterreceitadiaria(date); } // Mais metodos... Listagem 4. COdigo da classe RelatoriosFacade. package br.com.javamagazine.relatorios; import java.util.date; public class RelatoriosFacade public String obterreceitadiaria(date date) { String receitadiaria = null; ReceitaReport receitareport = new ReceitaReport(); receitareport.setdate(date); // receitadiaria = logica de ReceitaReport return receitadiaria; // Mais metodos... Listagem 5. COdigo da classe SuprimentosFactory. package br.com.javamagazine.suprimentos; public class SuprimentosFactory ( public Caneta criarcanetapreta() return new Caneta("preta"); public Regua criarreguade30cm0 return new Regua(30, Unidades.CM); Edich 98 Java Magazine 57

5 PadrOes de projeto, aprecie com moderacio Principios GRASP Segundo Craig Larman, em seu livro Applying UML and Patterns (2005), GRASP sac) padroes que descrevem princlpios fundamentais ao projetar objetos e atribuir responsabilidades. 0 GRASP possui dois significados: e o acronimo de General Responsibility Assignment Software Patterns (Padraes Gerais de Atribuicao de Responsabilidades em Software), e tambem urn verbo no Inglés, to grasp, que significa alcancar corn a mente, compreender. Conhecer estes padroes esta diretamente relacionado corn o born use dos padroes de projeto, pois os padroes GRASP sao baseados em principios da Orientacao a Objetos que devem sempre ser seguidos, e que certamente foram utilizados na concepcao dos padroes de projeto. - E aconselhcivel que os desenvolvedores tenham sempre os padröes GRASP em mente no momento em que estiverem avaliando uma possivel implementao o de urn padrâo de projeto. Deste modo, visando facilitar a compreensao dos padroes GRASP, sao apresentadas a seguir algumas reflexoes sobre cada padrao e sua releitura corn relacao aos padroes de projeto. Especialista da Informagio Este principio esta relacionado a ter born senso ao escolher qual classe deve-se atribuir determinada responsabilidade. Em suma, o principio diz: sabe-se que tal classe possui tais atributos e metodos, entao pode-se dizer que esta classe "conhece" sobre determinado contexto, portanto ela deve ser uma boa candidata a receber uma nova responsabilidade relacionada corn este mesmo contexto. Esta classe e Especialista da Informacao. Problema: Como decidir a que classes atribuir responsabilidade? Objetivo: Atribua a responsabilidade ao Especialista da Informacao a classe que possui a informacao necessaria para possuir a responsabilidade. - Ao surgir a necessidade de uma nova responsabilidade no problema, deve-se analisar qual classe terd mais sucesso em armazenar to! informacao, baseandose no contexto que a classe "conhece". Especialista da Informacdo e padroes de projeto: A caracterizacao de urn determinado padrao de projeto e dada a partir da definicao de o que as classes relacionadas devem saber e o que elas nao devem. E necessario que esta premissa nunca seja violada. Por exemplo: imagine uma implementacao do padrao de projeto GoF Observer (Observador) onde o objeto observado saiba quem o esta observando. Isto invalidaria toda a implementacao. Desta maneira, faz todo o sentido compreender quem é especialista de qual informacao quando implementar urn padrao de projeto. Criador 0 principio Criador visa atribuir responsabilidades de criacao, que quando bem atribuidas, podem suportar Baixo Acoplamento, maior clareza, encapsulamento e reusabilidade. Problema: Qual classe deve ser responsavel por criar uma instancia de urn objeto? Solucäo: Atribua a classe B a responsabilidade de criar uma instancia da classe A se uma ou mais condicoes a seguir forem verdadeiras: B agrega objetos A; B contem objetos A; B armazena instancias de objetos A; B é dependente de objetos A; B possui dados de inicializacdo que sera passados a algum objeto A (fazendo assim B urn Especialista da Informacao em relacao a criar A). - Ao surgir a necessidade de criar uma instancia de urn objeto, deve-se analisar qual classe terd mais sucesso em criar o objeto, baseando-se em sua relacdo corn a classe do objeto a ser criado. Criador e padroes de projeto: Criador foi concebido para suportar a criacdo de objetos quando esta for justificavel na propria classe Criadora. Assim, este principio nä diz respeito quando ha necessidade de haver delegacao proposital da responsabilidade de criar instancias de outros objetos, onde aplicam-se padroes de projeto GoF criacionais como Factory e Builder (Construtor). No entanto, Criador pode ser aplicado a outro aspecto: quando deseja-se implementar urn padrao de projeto, quem deve instanciar cada um dos objetos que compaem o padrao? Por exemplo, no padrao de projeto GoF Prototype (ProtOtipo), o objeto Prototype cria instancias de si mesmo por clonagem. Portanto esta de acordo corn o principio Criador, pois os dados de inicializacao do objeto sao de conhecimento do proprio objeto. Agora, se atribuirmos esta responsabilidade a outro objeto, deveremos tambern divulgar os detalhes internos da classe Prototype a este objeto, aumentando o acoplamento deste objeto corn relacao ao Prototype, o que vai na contramao do principio Criador. Baixo Acoplamento Baixo Acoplamento é urn principio-chave na Orientacao a Objetos, que busca garantir que urn objeto/classe/subsistema/ sistema nao seja dependente de muitos outros. Esta dependencia se expressa quando urn esta conectado a outro, possui conhecimento sobre outro ou confia em outro. Uma classe corn alto acoplamento pode sofrer dos seguintes problemas: Mudancas nas classes relacionadas causam mudancas nas classes dependentes; Seu isolamento fica comprometido; Reuso complicado, pois requer a presenca adicional das classes relacionadas. 58 Java Magazine Edicäo 98

6 Problema: Como suportar baixa dependencia, baixo impacto a mudancas e alto reuso? Solucao: Atribua responsabilidades de maneira que o acoplamento permaneca baixo. - Ao atribuir responsabilidades, deve-se buscar manter o acoplamento baixo, evitando tornar urn objeto/classe/subsistema/sistema dependente de outro desnecessariamente. Baixo Acoplamento e padroes de projeto: 0 padrao de projeto GoF Mediator (Mediador) busca exatamente diminuir o acoplamento entre duas classes que variam independentemente. 0 mesmo ocorre em Business Delegate, quanto a separacao entre camadas de negocio e apresentacao. E importante observar o Baixo Acoplamento como uma motivacao obrigatoria ao se utilizar tais padroes. De maneira geral, nenhum padrao de projeto deve contribuir para urn alto acoplamento. Alta Coesao Alta Coesao é outro principio-chave na Orientacâo a Objetos, que anda de maos dadas corn o Baixo Acoplamento. Este principio busca garantir que um objeto/classe/subsistema/ sistema manipule suas pr6prias responsabilidades em seu devido escopo. Isto acontece quando ele possui urn conjunto de responsabilidades altamente relacionadas, e nao faz uma quantidade exagerada de trabalho. Uma classe corn baixa coes5o, que faz muitas coisas naorelacionadas ou executa muito trabalho, pode sofrer dos seguintes problemas: Dificil de compreender, reutilizar e ma nter; Constantemente afetada por mudancas. Problema: Como manter a complexidade gerenciavel? Soluck): Atribua responsabilidades de maneira que a coesào permaneca alta. - Ao atribuir responsabilidades, deve-se buscar manter a coeseio alta, garantindo que urn objeto/classe/subsistema/sistema possui responsabilidades altamente relacionadas e nao faz uma quantidade exagerada de trabalho. Alta Coesäo e padroes de projeto: 0 padrao de projeto GoF Chain of Responsibility (Cadeia de Responsabilidade) é urn born exemplo de Alta Coesao, pois concentra apenas que diz respeito as suas pr6prias responsabilidades e passa a requisicão adiante. Adicionar responsabilidade demais ou executar muito trabalho em urn determinado no da cadeia viola este principio, e naturalmente surge a necessidade de quebrar a cadeia, adicionando mais urn no a mesma. De maneira geral, nenhum padrao de projeto deve contribuir para uma baixa coesdo. Controlador Urn Controlador é urn objeto responsavel por manipular urn evento de sistema. 0 evento e gerado por urn ator externo, que por sua vez esta associado a realizacao de uma operacao do sistema. 0 Controlador busca aumentar o potencial para reutilizacao e possibilitar interfaces plugaveis. Normalmente, urn Controlador deve delegar o trabalho a ser feito a outros objetos. Ele nao e responsavel por realizar muito trabalho. Problema: Qual classe deve ser responsavel por manipular um evento do sistema? Solucdo: Atribua a responsabilidade por receber/manipular mensagens de evento do sistema a uma classe representando: urn sistema, dispositivo ou subsistema utilizando o padrao de projeto Facade; ou urn cenario de caso de uso onde o evento de sistema ocorre, nomeado em algo como <CasoDeUso>Handler, <CasoDeUso>Coordinator ou <CasoDeUso>Session. - Ao surgir a necessidade de manipular urn evento do sistema, deve-se atribuir tal responsabilidade a uma classe representando urn subsistema ou urn cendrio de caso de uso onde o evento de sistema ocorre, sempre delegando o trabalho a ser feito a outros objetos. Controlador e padreies de projeto: Podem-se enquadrar como Controladores os padroes que abstraem a delegacdo de eventos, como os padroes de projeto GoF Command (Comando) e Observer e os que representam subsistemas como o Facade. No entanto, deve-se compreender urn Controlador como urn mero coadjuvante a possibilidade de desplugar a interface atual e plugar uma interface diferente, sem impactar em como o sistema subsequente atende a eventos. Se isto rid() for possivel, nä temos um Controlador. Polimorfismo Traduzindo em milados, Polimorfismo é outro principiochave que visa oferecer uma abstracdo que aumenta a extensibilidade de uma classe, possibilitando Variaccies Protegidas e tambern proporcionando uma alternativa a logicas condicionais do tipo if-then-else. Alern disso, implementar Polimorfismo ira aumentar o nivel de Baixo Acoplamento e Alta Coesiio. Sua utilizacdo classica é quando em uma classe/interface generica e herdavel, criam-se metodos abstratos que sdo referenciados por classes relacionadas, caracterizando urn acoplamento desta corn a interface. Assim, qualquer classe que implementar corretamente a interface podera tomar seu lugar no referido relacionamento, sem efetivamente estar acoplada a classe relacionada. Problema: Como manipular condicionais baseados em tipo de dados ou classe? Como criar componentes de software plugaveis? Edicäo 98 Java Magazine 59

7 PadrOes de projeto, aprecie corn moderacao Solucdo: Quando condicionais ou comportamentos variam por tipo de dados ou classe, atribua responsabilidade ao comportamento - usando operacaes polimorficas - aos tipos nos quais o comportamento varia. - Ao manipular condicionais baseados em tipo de dados ou classe para a realizacäo de um dentre diversos comportamentos, deve-se considerar a utilizacdo de Polimorfismo, criando uma classe/interface generica e herdóvel com um mêtodo para representar o comportamento, que sera sobrescrito pelas subclasses. Polimorfismo e padroes de projeto: Muitos padroes de projeto GoF fazem uso de Polimorfismo, como Adapter (Adaptador), Command, Composite (Compositor), Proxy (Procurador), State (Estado) e Strategy (Estrategia). Polimorfismo e urn pri ncipio potente, que se nao for bem utilizado pode acrescentar complexidade dema is ao sistema. Ao utilizar Polimorfismo, defina claramente todas as abstracoes a serem utilizadas, e geralmente nao e muito prudente implementar uma camada de abstracao em um cenario que nao possua variacao polimorfica. se abusado, visto que se esta introduzindo uma classe estranha ao dominio do problema. Indirecao 0 principio da Indirecao nao tern segredos, significa simplesmente delegar responsabilidades a classes auxiliares, que muitas vezes sac) baseadas ern Fabricaccio Pura. Diz urn famoso adagio: "A maioria dos problemas na Ciencia da Computacao podem ser resolvidos adicionando mais urn nivel de indirecao.". Problema: Como atribu it responsabilidades e evitar acoplamento direto entre dois ou mais elementos? Cot-no relacionar objetos de maneira que suporte o Baixo Acoplamento e mantenha o potencial de reuso alto? Solucdo: Atribua a responsabilidade a urn objeto intermediario para mediar entre diversos componentes ou servicos, de maneira que eles nä fiquem diretamente acoplados. - Ao surgir a necessidade de atribuir responsabilidades e evitar acoplamento entre dois ou mais elementos, deve-se atribuir a responsabilidade a um objeto intermedidrio para mediar entre diversos componentes ou servicos. Fa bricacd o Pura 0 princfpio de Fabricacao Pura é urn artiffcio utilizado para manter as classes de dominio corn Alta Coesdo e manipular as classes do sistema corn Baixo Acoplamento. Tipicamente, chega-se a uma Fabricacao Pura por decomposicao representacional - quando a classe conveniente esta relacionada corn a organizacao de ideias e informacoes do dominio do problema, como um Pool de usuarios - ou cornporta mental - quando a classe conveniente esta relacionada corn urn comportamento inerente do sistema, que geralmente nao esta relacionado corn o dominio do problema, como urn algoritmo. Problema: Qual objeto deve possuir a responsabilidade, quando nao se deseja viola r a Alta Coesiio e o Baixo Acoplamento, mas a solucao oferecida por Especialista da Informacao é inapropriada? Solucäo: Atribua urn conjunto de responsabilidades corn Alta Coesdo a uma classe de conveniencia que nao representa urn conceito do dominio do problema - algo feito corn a proposta de suportar Alta Coesdo, Baixo Acoplamento e reuso. - Quando new ha uma solucao adequada a um problema de atribuicâo de responsabilidades no dominio do problema, deve-se criar uma classe de conveniéncia que nä representa um conceito do dominio do problema, mas que possa receber as responsabilidades suportando Alta Coesào, Baixo Acoplamento e reuso. Fabricacao Pura e padroes de projeto: Todos os pad roes de projeto sac) baseados ern Fabricacdo Pura. E urn recurso muito util ao desenvolvedor, no entanto, deve ser utilizado de maneira gradual e corn clareza, pois pode comprometer a complexidade do sistema Indirecáo e padr6es de projeto: Muitos padroes de projeto GoF fazem uso direto do conceito de delegacao, como Adapter, Bridge (Ponte), Facade, Mediator, e Proxy (Procurador). No entanto, deve-se ter parcimonia ao utilizar delegacoes, pois quanto mais indireta for uma requisicao, mais complexo o sistema sera, mais dificil sera de se depurar e a performance pode ser afetada. Diz urn famoso contra-adagio: "A maioria dos problemas de performance podem ser resolvidos removendo mais urn nivel de indi recao!". VariacOes Protegidas VariacOes Protegidas e mais um principio-chave que motiva o uso da maioria dos mecanismos e padroes a fornecer flexibilidade e protecao contra variacties, como encapsulamento de dados, interfaces, Polimorfismo e Indirecao. Vale definir dois tipos de pontos de muclanca: Ponto de variacao: variackies no sistema atual ou nos requisitos, que devem ser suportadas; Ponto de evolucao: pontos de variacao especulativos que podem ou nao aparecer no futuro, mas nä estao presentes nos requisitos atuais. Problema: Como projetar objetos, classes, subsistemas e sistemas de maneira que variacoes ou instabilidades nester elementos nao impactem ern outros elementos? Solucao: Identifique pontos de variacao ou instabilidade predita e atribua responsabilidades para criar uma interface estavel ao seu redor. - Ao surgir a necessidade de proteger pontos de instabilidade contra variaciies que certamente impactardo no funcionamento do sistema, deve-se criar uma interface est-at/el ao seu redor. 60 Java Magazine Ed icão 98

8 VariacOes Protegidas e padriies de projeto: Diversos pad roes de projeto GoF sdo motivados por Variaccies Protegidas, como Adapter, Command, Facade, Mediator, e Observer. Deve-se ter cautela ao lidar corn pontos de evolucão, pois certas vezes o custo de "previsao do futuro" é maior que o custo de uma implementacao simples que pode ser refatorada sempre que necessaria, assim que houver uma confirmacao quanto ao ponto de evolucao em questa. Assim, sugere-se sempre avaliar esta questa quando se for implementar um padrao de projeto motivado por VariacOes Protegidas. Consideraiiies gerais para desenvolver senso critico Como uma especie de checklist, o autor deste artigo preparou algumas perguntas a serem feitas no moment() de implementar urn padrao de projeto. Busque responder algumas delas mentalmente sempre que considerar incluir urn padrao de projeto, de maneira automatica. Note que as respostas podem diferir muito de urn contexto para outro. Com relacao a Padronizacdo x Complexidade: A insercao deste padrao de projeto vai adicionar complexidade demais ao sistema? Quais sera os elementos envolvidos? Eles ja sac) complexos o bastante para sugerir-se uma refatoracao antes da insercao deste padrao? Com relacao a Padronizacao x Aplicabilidade: Voce esta seguindo corretamente o que a documentacao do padrao de projeto diz quanto a aplicabilidade? 0 cenario atual encontra-se listado ou pode ser derivado da documentacao de aplicabilidade? Corn relacao a Padronizacão x Consequencias: Voce leu atentamente as consequencias que o padrao de projeto trara para o sistema? Voce e capaz de identificar u ma consequencia do sistema particular que voce esta trabalh a ndo que nao esta listada nesta documentacao de consequencias? Se ha consequencias, o sistema comporta a introducao das mesmas? Com relacao a Padronizacao x Utilidade: A arquitetura atual do sistema ja nao fornece maquinario suficiente, embutido em outras construcoes de codigo? E possfvel outro trecho de codigo do sistema aproveitar-se desta implementacao de padrao de projeto? Corn relacao a Padronizacao x Principios GRASP: A aplicacâo deste padrao de projeto esta em conform idade corn Os princfpios GRASP? Ha ao menos urn princfpio GRASP que apresenta alguma desvantagem quanto a implementacao deste padrao de projeto? Corn relacâo a Padronizacao x Performance: Imagine o seu codigo ern producao, em larga escala, recebendo m ilhares de requisiciies por minuto. A implementacao deste padrao de projeto podera afetar a performance do sistema? Conhecimento faz diferenca! Proses so. ateditio de Software: Um imps! ttttt engenharia %«. de software 11,,,A.A1:: Nenociatao de central, em proj engenharia ;;; de software tato,. as an. Doff nicoes, preocupacoes e custo Agilidade: Arompanhamento de projetos.gels distribuido atraves do Daily Meeting 221 engenharia ;«, de software. Ano SO., Processo e I...temente de requisites de negecios - Parte 2 Qualidade de Software DefinIgim caracterfsekts e Imporlanda 'Process e serem tornados automacdo de na Implantacho testes de Projeto Diagram. de seguiricla na prides Projet0 Como inserir padriies de projeto atravis de refatormiks - Parte 2 Faca um upgrade em sua carreira Em um mercado cada vez mais focado em qualidade, ter conhecimentos aprofundados sobre requisitos, metodologia, análises, testes, entre ouutros, pode ser a diferenca entre conquistar ou nao uma boa posicäo profissional. Sabendo disso a DevMedia lancou uma publicach totalmente especializada em Engenharia de Software. Todos os meses voce pode encontrar artigos sobre Metodologias Age's; Metodologias tradicionais (document driven); ALM (application lifecycle); SOA (aplicaciies orientadas a servicoes); Analise de sistemas; Modelagem; M6tricas; Orientacäo a Objetos; UML; testes e muito mais. Assine JS! (511dtedie de 'este funcional bd%eade em Cases de Uso - Pastes 5 a 9 leste Pr (...mo Execute testes funtiona is tom A importanda da comuniratio Hudson e Selenium RC no processo de software Faca já sua assinatura digital! I 123v-M cita

9 Padriies de projeto, aprecie corn moderacio Os recursos sac) corretamente utilizados e liberados em seguida pela implementacao do padrao de projeto? Corn relacao a Padronizacao x Refatoracdo: aconselhavel adiar a introducao de complexidade para quando realmente houver urn cenario mais complexo que o cenario consequente a implementacao deste padrao de projeto? Ao comparar a implementacao deste padrao de projeto corn uma solucao minima passivel de futura refatoracao, qual atende melhor o cenario atual, do ponto de vista da Engenharia de Software? Lembre-se que, hoje em dia, as metodologias âgeis incentivam a utilizacao de solucaes minimas e incrementais, pois geralmente sempre e possivel de se refatorar o codigo na proxi ma iteracao. Mesmo assim, é possivel considerar a inclusao de urn padrao de projeto ainda que nao se percebam os ganhos imediatos. Chandima Cumaranatunge nos conta em seu blog que Kent Beck the revelou que costuma acrescentar padroes "imediatamente antes deles se tornarem titeis". Ou seja, se voce nab consegue ver agora como sera Uteis, logo vera. Deste modo, padroes de projeto bem escolhidos podem sim ser introduzidos sem visualizar-se os beneficios imediatamente, desde que sejam bem justificados, por exemplo, por questoes como as apresentadas acima. Conclusiies O autor deste artigo nao acredita que tudo o que foi apresentado aqui seja o suficiente para alguem saber julgar perfeitamente a aplicacao de padroes de projeto. 0 objetivo deste artigo é apresentar discussoes para voce, leitor, considerar a reinterpretacao de certos conhecimentos, buscando acrescentar algo ao seu senso critico. Mesmo que haja discordancia corn o que foi apresentado, pelo menos alguma reflexao ou consideracao apresentada pode the ajudar a chegar a diferentes concluseies, e assim contribuir corn o seu entendimento sobre o assunto. Assim sendo, este artigo busca ajudar voce a extrair de si mesmo o conhecimento para a aplicacao de padroes de projeto corn moderacao. O real aprendizado deste assunto é ranico e individual, e nä. ha urn estudo disciplinado que o explicard minuciosamente, solucionando todas as dirvidas, assim como o estudo de Matematica, por exemplo. Este aprendizado esta mais para o estudo de Idiomas, onde assumimos certas premissas e sempre consideramos a possibilidade de erro, visto que somos seres humanos, e aprendemos licoes a partir destes erros, buscando que as nossas habilidades sejam continuamente aperfeicoadas. Se voce concordou, discordou, tern drividas ou quer discutir sobre algum ponto, sinta-sea vontade para entrar em contato corn o autor. Muito obrigado e ate a proxima! minicursos sobre o assunto. Tiago Romero Garcia Gerente de Engenharia, Eider Mcnico e Desenvolvedor Java Web na Avenue Code. Graduado em Ciència da Computack na UNIFEI e cursando Arquitetura de Sistemas Distribuidos na PUC Minas, SCJP e SCWCD, possui ampla experiència em padroes de projeto e já lecionou corej2eepatterns. corn Catalog de padrbes de projeto J2EE. antonioshome.net/blog/2006/ php Antonio Vieiro descreve a doenca Singletonite em seu artigo "Singletonitis". c2.om/cgi/wiki?overuse0fpattems Catalog de anti-padroes relacionados corn o abuso de padrbes de projeto. e"'i oe5,9- as3dp.com/2009/09/03/integrating-design-patterns-just-before-they-becomeuseful Chandima Cumaranatunge explica como integrar padroes de projeto imediatamente antes de eles se tornarem titeis. De seu feedback sobre esta edic5o! A Java Magazine tem que ser feita ao seu gosto. Para isso, precisamos saber o que voce, leitor, acha da revista! Dé seu voto sobre este artigo, atraves do link: e,c.eedb,c4. 62 Java Magazine Edicäo 98

Padrões de Projeto. Prof. Jefersson Alex dos Santos (jefersson@dcc.ufmg.br) http://www.dcc.ufmg.br/~jefersson

Padrões de Projeto. Prof. Jefersson Alex dos Santos (jefersson@dcc.ufmg.br) http://www.dcc.ufmg.br/~jefersson Padrões de Projeto Prof. Jefersson Alex dos Santos (jefersson@dcc.ufmg.br) http://www.dcc.ufmg.br/~jefersson Apresentação Conceitos Definição Ponto de vista prático História Padrões de Projeto Conhecidos

Leia mais

1Introdução Helder da Rocha (helder@acm.org)

1Introdução Helder da Rocha (helder@acm.org) J930 Padrões Projeto de 1Introdução Helder da Rocha (helder@acm.org) argonavis.com.br O que é um padrão? Maneira testada ou documentada de alcançar um objetivo qualquer Padrões são comuns em várias áreas

Leia mais

J930. Padrões. Projeto. Introdução. argonavis.com.br. Helder da Rocha (helder@acm.org)

J930. Padrões. Projeto. Introdução. argonavis.com.br. Helder da Rocha (helder@acm.org) Padrões de J930 Projeto Introdução Helder da Rocha (helder@acm.org) argonavis.com.br O que é um padrão? Maneira testada ou documentada de alcançar um objetivo qualquer Padrões são comuns em várias áreas

Leia mais

Curso - Padrões de Projeto Módulo 1: Introdução

Curso - Padrões de Projeto Módulo 1: Introdução Curso - Padrões de Projeto Módulo 1: Introdução Vítor E. Silva Souza vitorsouza@gmail.com http://www.javablogs.com.br/page/engenho http://esjug.dev.java.net Sobre o Instrutor Formação: Java: Graduação

Leia mais

Programação Avançada. Padrões de Projeto de Software. Fonte: Oswaldo B. Peres e K19 Treinamentos

Programação Avançada. Padrões de Projeto de Software. Fonte: Oswaldo B. Peres e K19 Treinamentos Programação Avançada Padrões de Projeto de Software 1 Fonte: Oswaldo B. Peres e K19 Treinamentos Introdução Projetar software OO reusável e de boa qualidade é uma tarefa difícil; Para realizar essa tarefa

Leia mais

Programação Orientada a Objetos. Padrões de Criação

Programação Orientada a Objetos. Padrões de Criação Programação Orientada a Objetos Padrões de Criação Cristiano Lehrer, M.Sc. Objetivos Apresentar cada um dos 23 padrões clássicos descrevendo: O problema que solucionam. A solução. Diagramas UML (Unified

Leia mais

PADRÕES DE SOFTWARE. Jerffeson Teixeira de Souza, Ph.D. Tarciane de Castro Andrade. Grupo de Padrões de Software da UECE (GPS.

PADRÕES DE SOFTWARE. Jerffeson Teixeira de Souza, Ph.D. Tarciane de Castro Andrade. Grupo de Padrões de Software da UECE (GPS. PADRÕES DE SOFTWARE 1 Jerffeson Teixeira de Souza, Ph.D. Tarciane de Castro Andrade Grupo de Padrões de Software da UECE (GPS.UECE) Julho-2009 CONTEÚDO Introdução aos Padrões de Software O quê são padrões?

Leia mais

Padrões GoF. Leonardo Gresta Paulino Murta leomurta@ic.uff.br

Padrões GoF. Leonardo Gresta Paulino Murta leomurta@ic.uff.br Padrões GoF Leonardo Gresta Paulino Murta leomurta@ic.uff.br Agenda Introdução Padrões de Criação Padrões de Estrutura Padrões de comportamento Leonardo Murta Padrões GoF 2 Introdução Os padrões GoF (Gamma

Leia mais

Padrões clássicos ou padrões GoF O livro "Design Patterns (1994) de Erich Gamma, John Vlissides, Ralph Jonhson e Richard Helm, descreve 23 padrões de

Padrões clássicos ou padrões GoF O livro Design Patterns (1994) de Erich Gamma, John Vlissides, Ralph Jonhson e Richard Helm, descreve 23 padrões de Padrões de Projeto Disciplina: Engenharia de Software - 2009.1 Professora: Rossana Maria de Castro Andrade Assistente da disciplina: Ricardo Fernandes de Almeida 1 O que é um Padrão? Um padrão descreve

Leia mais

Design Patterns. Viviane Torres da Silva viviane.silva@ic.uff.br. http://www.ic.uff.br/~viviane.silva/2012.1/es1

Design Patterns. Viviane Torres da Silva viviane.silva@ic.uff.br. http://www.ic.uff.br/~viviane.silva/2012.1/es1 Design Patterns Viviane Torres da Silva viviane.silva@ic.uff.br http://www.ic.uff.br/~viviane.silva/2012.1/es1 Sumário Reuso de Software Introdução Benefícios e Desvantagens Visão do Reuso Padrões de Projeto

Leia mais

Eduardo Bezerra. Editora Campus/Elsevier

Eduardo Bezerra. Editora Campus/Elsevier Princípios de Análise e Projeto de Sistemas com UML 2ª edição Eduardo Bezerra Editora Campus/Elsevier Capítulo 8 Modelagem de classes de projeto A perfeição (no projeto) é alcançada, não quando não há

Leia mais

No artigo anterior explicamos. Desenvolvimento de Software Dirigido por Caso de Uso. Parte II: Especificando Caso de Uso

No artigo anterior explicamos. Desenvolvimento de Software Dirigido por Caso de Uso. Parte II: Especificando Caso de Uso Desenvolvimento de Software Dirigido por Caso de Uso Parte II: Especificando Caso de Uso Vinicius Lourenço de Sousa viniciuslsousa@gmail.com Atua no ramo de desenvolvimento de software há mais de 10 anos,

Leia mais

UML & Padrões Aula 7. UML & Padrões - Profª Kelly C C Silva

UML & Padrões Aula 7. UML & Padrões - Profª Kelly C C Silva UML & Padrões Aula 7 UML & Padrões - Profª Kelly C C Silva Divisão das classes do Modelo de Análise Jacobson propõe a divisão das classes do Modelo de Análise de acordo com os seguintes estereótipos: entidades

Leia mais

Teste de software. Definição

Teste de software. Definição Definição O teste é destinado a mostrar que um programa faz o que é proposto a fazer e para descobrir os defeitos do programa antes do uso. Quando se testa o software, o programa é executado usando dados

Leia mais

Prototype, um Design Patterns de Criação

Prototype, um Design Patterns de Criação Prototype, um Design Patterns de Criação José Anízio Pantoja Maia Este artigo tem como finalidade compreender o funcionamento do padrão de projeto prototype, serão abordados os participantes que compõe

Leia mais

Introdução à Padrões de Projeto. Glauber Magalhães Pires

Introdução à Padrões de Projeto. Glauber Magalhães Pires Introdução à Padrões de Projeto Glauber Magalhães Pires Agenda O que são padrões de projeto? Para que servem e por que utilizá-los? Elementos constituintes Como escolher o padrão a ser usado? Como são

Leia mais

Padrões de Projeto em Desenvolvimento Web SCC 266. Prof. Renata Pontin M. Fortes renata@icmc.usp.br PAE: Willian Watanabe (watinha@gmail.

Padrões de Projeto em Desenvolvimento Web SCC 266. Prof. Renata Pontin M. Fortes renata@icmc.usp.br PAE: Willian Watanabe (watinha@gmail. Padrões de Projeto em Desenvolvimento Web SCC 266 Prof. Renata Pontin M. Fortes renata@icmc.usp.br PAE: Willian Watanabe (watinha@gmail.com) 2.semestre 2010 Instituto de Ciências Matemáticas e de Computação

Leia mais

Pasteur Ottoni de Miranda Junior. Alguns Padrões de Projeto Gamma

Pasteur Ottoni de Miranda Junior. Alguns Padrões de Projeto Gamma Pasteur Ottoni de Miranda Junior Alguns Padrões de Projeto Gamma Padrões Gamma de Projeto(ou Gang-of-Four, gof) Os padrões gof foram publicados por Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides

Leia mais

Universidade Federal de Itajubá Instituto de Engenharia de Sistemas e Tecnologias da Informação-IESTI PCO203 Tópicos Especiais em Programação

Universidade Federal de Itajubá Instituto de Engenharia de Sistemas e Tecnologias da Informação-IESTI PCO203 Tópicos Especiais em Programação UNIFEI Disciplina Professor Universidade Federal de Itajubá Instituto de Engenharia de Sistemas e Tecnologias da Informação-IESTI PCO203 Tópicos Especiais em Programação Enzo Seraphim 1 Padrões de Projeto

Leia mais

Padrões de projeto 1

Padrões de projeto 1 Padrões de projeto 1 Design Orientado Objeto Encapsulamento Herança Polimorfismo Design Patterns 2 Responsabilidades Booch e Rumbaugh Responsabilidade é um contrato ou obrigação de um tipo ou classe. Dois

Leia mais

Curso - Padrões de Projeto Módulo 2: Padrões de Criação

Curso - Padrões de Projeto Módulo 2: Padrões de Criação Curso - Padrões de Projeto Módulo 2: Padrões de Criação Vítor E. Silva Souza vitorsouza@gmail.com http://www.javablogs.com.br/page/engenho http://esjug.dev.java.net Sobre o Instrutor Formação: Java: Graduação

Leia mais

Evolução do Design através de Testes e o TDD

Evolução do Design através de Testes e o TDD c a p a Lucas Souza (lucas.souza@caelum.com.br): é bacharel em Engenharia da Computação pela Universidade de Ribeirão Preto, possui a certificação SCJP e trabalha com Java há 4 anos. Atualmente é desenvolvedor

Leia mais

Programa do Módulo 2. Processo Unificado: Visão Geral

Programa do Módulo 2. Processo Unificado: Visão Geral 9.1 Programa do Módulo 2 Orientação a Objetos Conceitos Básicos Análise Orientada a Objetos (UML) O Processo Unificado (RUP) Processo Unificado: Visão Geral 9.2 Encaixa-se na definição geral de processo:

Leia mais

Programação Orientada a Objetos Prof. Rone Ilídio UFSJ/CAP

Programação Orientada a Objetos Prof. Rone Ilídio UFSJ/CAP Programação Orientada a Objetos Prof. Rone Ilídio UFSJ/CAP 1) Introdução Programação Orientada a Objetos é um paradigma de programação bastante antigo. Entretanto somente nos últimos anos foi aceito realmente

Leia mais

Orientação a Objetos

Orientação a Objetos Orientação a Objetos Daniel Destro do Carmo Softech Network Informática daniel@danieldestro.com.br Histórico A orientação a objetos (OO) foi concebida na década de 70. Origem na linguagem SIMULA-67 (década

Leia mais

Testes com Design Patterns

Testes com Design Patterns Helder da Rocha (helder.darocha@gmail.com) 31 de março de 2005 71. Que padrão de design pode ser usado para permitir que uma implementação específica e uma hierarquia de abstrações possa variar independentemente?

Leia mais

5 Framework para coordenação e mediação de Web Services para ambientes de aprendizado à distância

5 Framework para coordenação e mediação de Web Services para ambientes de aprendizado à distância 5 Framework para coordenação e mediação de Web Services para ambientes de aprendizado à distância O capítulo anterior apresentou uma discussão sobre a inclusão dos chamados learning services no processo

Leia mais

Histórico de revisões

Histórico de revisões Design Patterns Histórico de revisões Data Versão Descrição Autor 15/1/2014 1.0 Finalização da primeira versão HEngholmJr OBJETIVOS Fornecer uma visão geral sobre Design Patterns visando atingir os requisitos

Leia mais

Edições Edge do SAP InfiniteInsight Visão geral Viabilizando insights preditivos apenas com cliques de mouse, sem códigos de computador

Edições Edge do SAP InfiniteInsight Visão geral Viabilizando insights preditivos apenas com cliques de mouse, sem códigos de computador Soluções de análise da SAP Edições Edge do SAP InfiniteInsight Visão geral Viabilizando insights preditivos apenas com cliques de mouse, sem códigos de computador Índice 3 Um caso para análise preditiva

Leia mais

PROGRAMAÇÃO AVANÇADA -CONCEITOS DE ORIENTAÇÃO A OBJETOS. Prof. Angelo Augusto Frozza, M.Sc. frozza@ifc-camboriu.edu.br

PROGRAMAÇÃO AVANÇADA -CONCEITOS DE ORIENTAÇÃO A OBJETOS. Prof. Angelo Augusto Frozza, M.Sc. frozza@ifc-camboriu.edu.br PROGRAMAÇÃO AVANÇADA -CONCEITOS DE ORIENTAÇÃO A OBJETOS Prof. Angelo Augusto Frozza, M.Sc. frozza@ifc-camboriu.edu.br ROTEIRO 1. Conceitos de Orientação a Objetos Introdução O paradigma da POO Classes

Leia mais

Padrões de Projeto de Software Orientado a Objetos

Padrões de Projeto de Software Orientado a Objetos Padrões de Projeto de Software Orientado a Objetos Ricardo Argenton Ramos [Baseado nos slides do professor Fabio Kon - USP] 1 Padrões de Projeto de Software OO Também conhecidos como Padrões de Desenho

Leia mais

Nos artigos anteriores apresentamos. Desenvolvimento de Software Dirigido por Caso de Uso Parte III: Caso de Uso de Negócio

Nos artigos anteriores apresentamos. Desenvolvimento de Software Dirigido por Caso de Uso Parte III: Caso de Uso de Negócio Desenvolvimento de Software Dirigido por Caso de Uso Parte III: Caso de Uso de Negócio Vinicius Lourenço de Sousa vinicius.lourenco.sousa@gmail.com Atua no ramo de desenvolvimento de software há mais de

Leia mais

O CONCEITO DE TDD NO DESENVOLVIMENTO DE SOFTWARE

O CONCEITO DE TDD NO DESENVOLVIMENTO DE SOFTWARE O CONCEITO DE TDD NO DESENVOLVIMENTO DE SOFTWARE Renan Leme Nazário, Ricardo Rufino Universidade Paranaense (Unipar) Paranavaí PR - Brasil renazariorln@gmail.com, ricardo@unipar.br Resumo. Este artigo

Leia mais

Abordagem de Frameworks e Design Patterns para desenvolvimento de Aplicações Approach Frameworks and Design Patterns for Application Development

Abordagem de Frameworks e Design Patterns para desenvolvimento de Aplicações Approach Frameworks and Design Patterns for Application Development Abordagem de Frameworks e Design Patterns para desenvolvimento de Aplicações Approach Frameworks and Design Patterns for Application Development Demetrio da Silva Passos 1 Augusto Nogueira Zadra 2 Resumo:

Leia mais

Engenharia de Softwares e Sistema IF682 (2012.1) Bruno Medeiros(bmo@cin.ufpe.br)

Engenharia de Softwares e Sistema IF682 (2012.1) Bruno Medeiros(bmo@cin.ufpe.br) Engenharia de Softwares e Sistema IF682 (2012.1) Bruno Medeiros(bmo@cin.ufpe.br) Algumas definições Engenharia de Software conjunto de tecnologias e práticas usadas para construir software de qualidade

Leia mais

FIC Faculdade Integrada do Ceará Curso em tecnologia em analise e desenvolvimento de sistemas. OpenUp. Arquitetura de software

FIC Faculdade Integrada do Ceará Curso em tecnologia em analise e desenvolvimento de sistemas. OpenUp. Arquitetura de software FIC Faculdade Integrada do Ceará Curso em tecnologia em analise e desenvolvimento de sistemas OpenUp Arquitetura de software Fortaleza/2010 OpenUP Alguns anos atrás, vários funcionários da IBM começaram

Leia mais

PADRÕES DE PROJETO. Cleviton Monteiro (cleviton@gmail.com)

PADRÕES DE PROJETO. Cleviton Monteiro (cleviton@gmail.com) PADRÕES DE PROJETO Cleviton Monteiro (cleviton@gmail.com) Roteiro Atributos de qualidade Boas práticas de projeto Code Smell Padrões de Projeto Atributos de qualidade Coesão Acoplamento Atributos de qualidade

Leia mais

Padrões de Desenho (Design Patterns)

Padrões de Desenho (Design Patterns) Padrões de Desenho (Design Patterns) O que são padrões de desenho Porque são úteis Conhecer alguns padrões 1 Padrões (Patterns) Design Patterns Explained: A New Perspective on Object-Oriented Design, Alan

Leia mais

MedEl: Uma solução de E-Learning utilizando tecnologia Microsoft ASP.NET

MedEl: Uma solução de E-Learning utilizando tecnologia Microsoft ASP.NET MedEl: Uma solução de E-Learning utilizando tecnologia Microsoft ASP.NET Átila Correia Cunha 1, 2, Glaucon Henrique Mauricio Maia 1, 2, Waner Ferreira Tavares 1, 2, Jorge Bergson¹, Rui Gomes Patrício 3

Leia mais

UNIVERSIDADE FEDERAL DO PARANÁ UFPR Bacharelado em Ciência da Computação

UNIVERSIDADE FEDERAL DO PARANÁ UFPR Bacharelado em Ciência da Computação SOFT DISCIPLINA: Engenharia de Software AULA NÚMERO: 10 DATA: / / PROFESSOR: Andrey APRESENTAÇÃO O objetivo desta aula é apresentar e discutir os conceitos de coesão e acoplamento. DESENVOLVIMENTO Projetar

Leia mais

Análise e Projeto Orientados por Objetos

Análise e Projeto Orientados por Objetos Análise e Projeto Orientados por Objetos Apresentação da Disciplina Edirlei Soares de Lima Objetivos da Disciplina Apresentar e discutir técnicas avançadas de Análise e Projeto de

Leia mais

Com relação às áreas de conhecimento de projetos conforme o. PMBoK, julgue os itens subseqüentes.

Com relação às áreas de conhecimento de projetos conforme o. PMBoK, julgue os itens subseqüentes. De acordo com o comando a que cada um dos itens de 1 a 70 se refira, marque, na folha de respostas, para cada item: o campo designado com o código C, caso julgue o item CERTO; ou o campo designado com

Leia mais

Lidando de Forma Eficiente com Validações Locais de Objetos

Lidando de Forma Eficiente com Validações Locais de Objetos Lidando de Forma Eficiente com Validações Locais de Objetos Aprenda a construir um mini-framework para validar objetos locais sem afetar a complexidade do código. Autor Paulo César M. N. A. Coutinho (pcmnac@gmail.com):

Leia mais

Evolução de Software e Refatoração

Evolução de Software e Refatoração Evolução de Software e Refatoração Mudança de software Mudança de software é inevitável Novos requisitos surgem quando o software é usado; O ambiente de negócio muda; Erros devem ser reparados; Novos computadores

Leia mais

3.5. Cuidado com o modelo anêmico

3.5. Cuidado com o modelo anêmico 3.5. Cuidado com o modelo anêmico public Periodo adiaumasemana() { Calendar novofim = (Calendar) this.fim.clone(); novofim.add(calendar.day_of_month, 7); return new Periodo(inicio, novofim); E, com uma

Leia mais

Capítulo 1. Extreme Programming: visão geral

Capítulo 1. Extreme Programming: visão geral Capítulo 1 Extreme Programming: visão geral Extreme Programming, ou XP, é um processo de desenvolvimento de software voltado para: Projetos cujos requisitos são vagos e mudam com freqüência; Desenvolvimento

Leia mais

PHP Profissional. Alexandre Altair de Melo Mauricio G. F. Nascimento

PHP Profissional. Alexandre Altair de Melo Mauricio G. F. Nascimento PHP Profissional APRENDA A DESENVOLVER SISTEMAS PROFISSIONAIS ORIENTADOS A OBJETOS COM PADRÕES DE PROJETO Alexandre Altair de Melo Mauricio G. F. Nascimento Novatec Sumário Agradecimentos...13 Sobre os

Leia mais

Padrões. Projeto (Design) de Software

Padrões. Projeto (Design) de Software Padrões Projeto de Softwares Categorias de Padrões Processo de Tradução de modelos de análise (isentos de tecnologia, lógicos) para modelos de projeto (development-ready, físicos) Qual a Tecnologia Alvo

Leia mais

MÓDULO Modelagem de classes de projeto

MÓDULO Modelagem de classes de projeto MÓDULO Modelagem de classes de projeto A perfeição (no projeto) é alcançada, não quando não há nada mais para adicionar, mas quando não há nada mais para retirar. -Eric Raymond, The Cathedral and the Bazaar

Leia mais

UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 06 PROFª BRUNO CALEGARO

UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 06 PROFª BRUNO CALEGARO UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 06 PROFª BRUNO CALEGARO Santa Maria, 27 de Setembro de 2013. Revisão aula anterior Desenvolvimento Ágil de Software Desenvolvimento e entrega

Leia mais

Especialização em web com interfaces ricas. Padrões de Projeto - Estruturais

Especialização em web com interfaces ricas. Padrões de Projeto - Estruturais Especialização em web com interfaces ricas Padrões de Projeto - Estruturais Prof. Fabrízzio Alphonsus A. M. N. Soares fabrizzio@inf.ufg.br professor.fabrizzio@gmail.com Instituto de Informática Universidade

Leia mais

Engenharia de Software I

Engenharia de Software I Engenharia de Software I Curso de Sistemas de Informação Karla Donato Fook karladf@ifma.edu.br DESU / DAI 2015 Desenvolvimento Rápido de Software 2 1 Para quê o Desenvolvimento Rápido de Software? Os negócios

Leia mais

Universidade Federal de Itajubá Instituto de Engenharia de Sistemas e Tecnologias da Informação-IESTI PCO203 Tópicos Especiais em Programação

Universidade Federal de Itajubá Instituto de Engenharia de Sistemas e Tecnologias da Informação-IESTI PCO203 Tópicos Especiais em Programação UNIFEI Disciplina Professor Universidade Federal de Itajubá Instituto de Engenharia de Sistemas e Tecnologias da Informação-IESTI PCO203 Tópicos Especiais em Programação Enzo Seraphim 1 Padrões de Operação

Leia mais

3. PARADIGMA ORIENTADO A OBJETOS

3. PARADIGMA ORIENTADO A OBJETOS Paradigmas de Linguagens I 1 3. PARADIGMA ORIENTADO A OBJETOS Este paradigma é o que mais reflete os problemas atuais. Linguagens orientada a objetos (OO) são projetadas para implementar diretamente a

Leia mais

Padrão Básico de Projeto: Interfaces e Polimorfismo

Padrão Básico de Projeto: Interfaces e Polimorfismo Padrão Básico de Projeto: Interfaces e Polimorfismo Herança de implementação versus herança de interface Há uma diferença grande entre uma classe e seu tipo A classe define ambos um tipo e uma implementação

Leia mais

Tecnologias Web. Padrões de Projeto - Camada de Apresentação

Tecnologias Web. Padrões de Projeto - Camada de Apresentação Tecnologias Web Padrões de Projeto - Camada de Apresentação Cristiano Lehrer, M.Sc. Padrões da Camada de Apresentação (1/2) Intercepting Filter Viabiliza pré e pós processamento de requisições. Front Controller

Leia mais

Algumas propriedades dos objetos:

Algumas propriedades dos objetos: Orientação a Objetos Vivemos num mundo de objetos. Esses objetos existem na natureza, nas entidades feitas pelo homem, nos negócios e nos produtos que usamos. Eles podem ser categorizados, descritos, organizados,

Leia mais

Reuso com Herança a e Composiçã

Reuso com Herança a e Composiçã Java 2 Standard Edition Reuso com Herança a e Composiçã ção Helder da Rocha www.argonavis.com.br 1 Como aumentar as chances de reuso Separar as partes que podem mudar das partes que não mudam. Exemplo:

Leia mais

Eduardo Bezerra. Editora Campus/Elsevier

Eduardo Bezerra. Editora Campus/Elsevier Princípios de Análise e Projeto de Sistemas com UML 2ª edição Eduardo Bezerra Editora Campus/Elsevier Capítulo 11 Arquitetura do sistema Nada que é visto, é visto de uma vez e por completo. --EUCLIDES

Leia mais

2 Diagrama de Caso de Uso

2 Diagrama de Caso de Uso Unified Modeling Language (UML) Universidade Federal do Maranhão UFMA Pós Graduação de Engenharia de Eletricidade Grupo de Computação Assunto: Diagrama de Caso de Uso (Use Case) Autoria:Aristófanes Corrêa

Leia mais

Padrões de Software (Software Patterns)

Padrões de Software (Software Patterns) Padrões de Software (Software Patterns) Cleidson de Souza - cdesouza@ufpa.br Departamento de Informática Universidade Federal do Pará Agenda! Definição! Histórico! Motivação! Exemplo Estratégia MVC! Forma

Leia mais

Material de Apoio 5. int getres() { return res; O que estas classes possuem em comum? 1) 2) 3)

Material de Apoio 5. int getres() { return res; O que estas classes possuem em comum? 1) 2) 3) pg. 1/6 Material de Apoio 5 Herança Observe o código das classes Fatorial e Fibonacci apresentados abaixo. class Fatorial { class Fibonacci { private int n, res; private int n, res; public Fatorial( int

Leia mais

Prof.ª Esp. Talita Pagani

Prof.ª Esp. Talita Pagani Especialização em Engenharia de Software Prof.ª Esp. Talita Pagani talita.cpb@gmail.com @talitapagani 21/02/2014 Design Patterns Aula 1 Prof.ª Esp. Talita Pagani 1 Informações gerais 1. Definição de Design

Leia mais

Engenharia de Software na Prática Hélio Engholm Jr.

Engenharia de Software na Prática Hélio Engholm Jr. Engenharia de Software na Prática Hélio Engholm Jr. Novatec Sumário Agradecimentos... 17 Sobre o autor... 18 Prefácio... 19 Capítulo 1 Desenvolvimento de software para o valor de negócios... 20 1.1 Qualidade

Leia mais

Técnicas de Programação Avançada TCC-00175 Profs.: Anselmo Montenegro www.ic.uff.br/~anselmo

Técnicas de Programação Avançada TCC-00175 Profs.: Anselmo Montenegro www.ic.uff.br/~anselmo Técnicas de Programação Avançada TCC-00175 Profs.: Anselmo Montenegro www.ic.uff.br/~anselmo Conteúdo:Introdução a Frameworks para Aplicações Baseado em Building Application Frameworks Mohamed E. Fayad

Leia mais

Padrões de Desenho. ---------Engenharia de Software---------

Padrões de Desenho. ---------Engenharia de Software--------- Padrões de Desenho Objectivos: Compreender o que são os padrões de desenho? Vantagens e desvantagens em usar os padrões de desenho? Qual o formato de um padrão de desenho? Conhecer as varias secções de

Leia mais

Processo de Desenvolvimento de Software. Unidade V Modelagem de PDS. Luiz Leão luizleao@gmail.com http://www.luizleao.com

Processo de Desenvolvimento de Software. Unidade V Modelagem de PDS. Luiz Leão luizleao@gmail.com http://www.luizleao.com Processo de Desenvolvimento de Software Luiz Leão luizleao@gmail.com http://www.luizleao.com Conteúdo Programático desta aula Modelo Cascata (Waterfall) ou TOP DOWN. Modelo Iterativo. Metodologia Ágil.

Leia mais

PADRÕES DE PROJETO FAÇADE, FLYWEIGHT E VISITOR

PADRÕES DE PROJETO FAÇADE, FLYWEIGHT E VISITOR FACULDADE DE CIÊNCIAS APLICADAS SAGRADO CORAÇÃO DIRETORIA DE ENSINO SUPERIOR COORDENAÇÃO DO CURSO DE SISTEMAS DE INFORMAÇÃO GUSTAVO ANDRÉ DE FREITAS RILIANE ALPOIM PARIS RODRIGO SILVA DE SOUZA PADRÕES

Leia mais

DISCIPLINA ENGENHARIA DE SOFTWARE Aula 03 Processo Unificado e Desenvolvimento Ágil. Profª Esp.: Maysa de Moura Gonzaga

DISCIPLINA ENGENHARIA DE SOFTWARE Aula 03 Processo Unificado e Desenvolvimento Ágil. Profª Esp.: Maysa de Moura Gonzaga DISCIPLINA ENGENHARIA DE SOFTWARE Aula 03 Processo Unificado e Desenvolvimento Ágil Profª Esp.: Maysa de Moura Gonzaga 2º Semestre / 2011 O Processo Unificado dos autores Ivar Jacobson, Grady Booch e James

Leia mais

FBV - Linguagem de Programação II. Um pouco sobre Java

FBV - Linguagem de Programação II. Um pouco sobre Java FBV - Linguagem de Programação II Um pouco sobre Java História 1992: um grupo de engenheiros da Sun Microsystems desenvolve uma linguagem para pequenos dispositivos, batizada de Oak Desenvolvida com base

Leia mais

a) O Sprint deve ser realizado num período máximo de 40 dias e ter uma equipe de trabalho não superior a 10 pessoas.

a) O Sprint deve ser realizado num período máximo de 40 dias e ter uma equipe de trabalho não superior a 10 pessoas. Modelos de Ciclo de Vida e Metodologias de Software 54. Um dos principais conceitos do Scrum para atacar a complexidade do desenvolvimento e gerenciamento de software é a implantação de um controle descentralizado,

Leia mais

UML Aspectos de projetos em Diagramas de classes

UML Aspectos de projetos em Diagramas de classes UML Aspectos de projetos em Diagramas de classes Após ser definido o contexto da aplicação a ser gerada. Devemos pensar em detalhar o Diagrama de Classes com informações visando uma implementação Orientada

Leia mais

Fábrica de Software 29/04/2015

Fábrica de Software 29/04/2015 Fábrica de Software 29/04/2015 Crise do Software Fábrica de Software Analogias costumam ser usadas para tentar entender melhor algo ou alguma coisa. A idéia é simples: compara-se o conceito que não se

Leia mais

EXERCÍCIOS SOBRE ORIENTAÇÃO A OBJETOS

EXERCÍCIOS SOBRE ORIENTAÇÃO A OBJETOS Campus Cachoeiro de Itapemirim Curso Técnico em Informática Disciplina: Análise e Projeto de Sistemas Professor: Rafael Vargas Mesquita Este exercício deve ser manuscrito e entregue na próxima aula; Valor

Leia mais

Orientação a Objeto e UML Questões 2014 Prof. Felipe Leite

Orientação a Objeto e UML Questões 2014 Prof. Felipe Leite Orientação a Objeto e UML Questões 2014 Prof. Felipe Leite Pessoal, fiz uma coletânea das questões mais recentes de concursos públicos de TODO o Brasil de várias bancas diferentes sobre os assuntos Orientação

Leia mais

TECNICO EM INFORMATICA PLANO DE ESTAGIO INTEGRADO A PROPOSTA PEDAGOGICA DO CURSO

TECNICO EM INFORMATICA PLANO DE ESTAGIO INTEGRADO A PROPOSTA PEDAGOGICA DO CURSO (s15h PLANO DE ESTAGIO INTEGRADO A PROPOSTA PEDAGOGICA DO CURSO Curso: 500446 - TECNICO EM INFORMATICA Nivel: Tecnico Area Profissional: 0042 - COMERCIO-TEC Area de Atuacao: 0440 - BANCO DADOS/COMERCIO-TEC

Leia mais

Histórico da Orientação a Objetos Ciclo de vida de Desenvolvimento de SW

Histórico da Orientação a Objetos Ciclo de vida de Desenvolvimento de SW Histórico da Orientação a Objetos Ciclo de vida de Desenvolvimento de SW Baseado nos materiais dos profs: Prof.: Edilberto M. Silva http://www.edilms.eti.br Edna Canedo Marcio de Carvalho Victorino Brasília-DF,

Leia mais

Design Patterns STRATEGY EMERSON BARROS DE MENESES

Design Patterns STRATEGY EMERSON BARROS DE MENESES Design Patterns STRATEGY EMERSON BARROS DE MENESES 1 Breve Histórico Sobre Design Patterns A origem dos Design Patterns (Padrões de Desenho ou ainda Padrões de Projeto) vem do trabalho de um arquiteto

Leia mais

Aula 10: Análise Dinâmica - 1a. Parte

Aula 10: Análise Dinâmica - 1a. Parte Aula 10: Análise Dinâmica - 1a. Parte A melhor forma de garantir a qualidade do software que você constrói é projetando-o cuidadosamente desde o início. Desta forma, as partes se encaixarão mais perfeitamente,

Leia mais

1/26/2009. Baseadas em http://www.voelter.de/services/mdsdtutorial.html. Experiência pessoal/profissional/acadêmica

1/26/2009. Baseadas em http://www.voelter.de/services/mdsdtutorial.html. Experiência pessoal/profissional/acadêmica Baseadas em http://www.voelter.de/services/mdsdtutorial.html Experiência pessoal/profissional/acadêmica 1 Metamodelo UML Meu Metamodelo Meu processo de negócios Meu processo de negócios Stereotypes Perfis

Leia mais

Tópicos em Engenharia de Computação

Tópicos em Engenharia de Computação Tópicos em Engenharia de Computação Introdução / Revisão UML e POO (JAVA) Prof. Ivan Prof. Zagari UML Linguagem Unificada. Não é metodologia, processo ou método. Versão atual 2.0 3 categorias de Diagramas

Leia mais

(UFF) JDBC (I) TEPIS II

(UFF) JDBC (I) TEPIS II Aula 20: JDBC (I) Diego Passos Universidade Federal Fluminense Técnicas de Projeto e Implementação de Sistemas II Diego Passos (UFF) JDBC (I) TEPIS II 1 / 33 JDBC: Introdução Especificação que provê acesso

Leia mais

ENGENHARIA DE SOFTWARE I

ENGENHARIA DE SOFTWARE I ENGENHARIA DE SOFTWARE I Prof. Cássio Huggentobler de Costa [cassio.costa@ulbra.br] Twitter: www.twitter.com/cassiocosta_ Agenda da Aula (002) Metodologias de Desenvolvimento de Softwares Métodos Ágeis

Leia mais

Classes de Entidades Persistentes JDB

Classes de Entidades Persistentes JDB Classes de Entidades Persistentes JDB Brasil, Natal-RN, 07 de setembro de 2011 Welbson Siqueira Costa www.jdbframework.com Nota de Retificação: em 11/12/2011 a Listagem 3 desse tutorial sofreu uma pequena

Leia mais

PADRÕES DE PROJETO E FRAMEWORK NO DESENVOLVIMENTO DE SOFTWARE

PADRÕES DE PROJETO E FRAMEWORK NO DESENVOLVIMENTO DE SOFTWARE PADRÕES DE PROJETO E FRAMEWORK NO DESENVOLVIMENTO DE SOFTWARE Nelson Ribeiro de Carvalho Júnior 1 RESUMO Atualmente o cenário mundial cuja dependência do software está cada vez mais evidente requer que

Leia mais

Programação de Computadores - I. Profª Beatriz Profº Israel

Programação de Computadores - I. Profª Beatriz Profº Israel Programação de Computadores - I Profª Beatriz Profº Israel Ambiente de Desenvolvimento Orientação a Objetos É uma técnica de desenvolvimento de softwares que consiste em representar os elementos do mundo

Leia mais

PROGRAMAÇÃO SERVIDOR PADRÕES MVC E DAO EM SISTEMAS WEB. Prof. Dr. Daniel Caetano 2012-1

PROGRAMAÇÃO SERVIDOR PADRÕES MVC E DAO EM SISTEMAS WEB. Prof. Dr. Daniel Caetano 2012-1 PROGRAMAÇÃO SERVIDOR EM SISTEMAS WEB PADRÕES MVC E DAO Prof. Dr. Daniel Caetano 2012-1 Objetivos Compreender o conceito de Padrões de Projeto Compreender o Padrão MVC Conhecer o princípio de alguns dos

Leia mais

Técnicas de Reuso de Software aplicados na elaboração de Arquiteturas Corporativas

Técnicas de Reuso de Software aplicados na elaboração de Arquiteturas Corporativas MAC0499-Trabalho de Formatura Monografia USP - Universidade de São Paulo Instituto de Matemática e Estatística Bacharelado em Ciência da Computação Técnicas de Reuso de Software aplicados na elaboração

Leia mais

Uma Introdução aos Padrões de Projeto com Java. Roberto Willrich INE-CTC-UFSC

Uma Introdução aos Padrões de Projeto com Java. Roberto Willrich INE-CTC-UFSC Uma Introdução aos Padrões de Projeto com Java Roberto Willrich INE-CTC-UFSC 1 Introdução aos Padrões de Projeto Programação Introdução Motivação, Definição, Características, Histórico Descrição de um

Leia mais

Padrões de Projeto em PHP

Padrões de Projeto em PHP Aprendendo Padrões de Projeto em PHP William Sanders Novatec Authorized Portuguese translation of the English edition of titled Learning PHP Design Patterns ISBN 9781449344917 2013 William B. Sanders.

Leia mais

Trilha Agile TDD e 20 coisas que você precisa saber

Trilha Agile TDD e 20 coisas que você precisa saber Trilha Agile TDD e 20 coisas que você precisa saber Camilo Lopes Quem sou eu?! Trabalha com desenvolvimento de software desde 2003. Atualmente Desenvolvedor de Software na ADP Labs, escritor do livro "Guia

Leia mais

4 - Padrões de Construção

4 - Padrões de Construção J930 Padrões Projeto de 4Padrões de Construção Helder da Rocha (helder@acm.org) argonavis.com.br Introdução A maneira padrão de construir objetos em Java é através de construtores Toda classe tem um construtor:

Leia mais

ENTERPRISE JAVABEANS 3. Msc. Daniele Carvalho Oliveira

ENTERPRISE JAVABEANS 3. Msc. Daniele Carvalho Oliveira ENTERPRISE JAVABEANS 3 Msc. Daniele Carvalho Oliveira Apostila Servlets e JSP www.argonavis.com.br/cursos/java/j550/index.html INTRODUÇÃO Introdução Enterprise JavaBeans é um padrão de modelo de componentes

Leia mais

Engenharia de Software I

Engenharia de Software I Engenharia de Software I Rogério Eduardo Garcia (rogerio@fct.unesp.br) Bacharelado em Ciência da Computação Aula 05 Material preparado por Fernanda Madeiral Delfim Tópicos Aula 5 Contextualização UML Astah

Leia mais

Gerenciamento de Qualidade

Gerenciamento de Qualidade UNIVERSIDADE ESTADUAL PAULISTA INSTITUTO DE BIOCIÊNCIAS, LETRAS E CIÊNCIAS EXATAS DEPARTAMENTO DE CIÊNCIAS DE COMPUTAÇÃO E ESTATÍSTICA Gerenciamento de Qualidade Engenharia de Software 2o. Semestre de

Leia mais

Argo Navis J931 - Padrões de Design J2EE. Introdução. Objetivos de aprender padrões J2EE. Conhecer padrões para uso na plataforma J2EE

Argo Navis J931 - Padrões de Design J2EE. Introdução. Objetivos de aprender padrões J2EE. Conhecer padrões para uso na plataforma J2EE Padrões de Projeto J2EE J931 Introdução Helder da Rocha (helder@acm.org) argonavis.com.br Objetivos de aprender padrões J2EE Conhecer padrões para uso na plataforma J2EE Padrões permitem maior reuso, menos

Leia mais

Sistemas de Informação e Programação II Odorico Machado Mendizabal

Sistemas de Informação e Programação II Odorico Machado Mendizabal Sistemas de Informação e Programação II Odorico Machado Mendizabal Universidade Federal do Rio Grande FURG C3 Engenharia de Computação 16 e 23 de março de 2011 Processo de Desenvolvimento de Software Objetivos

Leia mais

Separaçã. ção Multi-Dimensional de Interesses

Separaçã. ção Multi-Dimensional de Interesses OD 2002 Uma nova abordagem para modelagem de requisitos Separaçã ção Multi-Dimensional de Interesses Helder da Rocha (helder@acm.org) argonavis.com.br Objetivos 1. Discutir as limitações existentes no

Leia mais