Casos Notáveis. Forças. Problema. Contexto

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

Download "Casos Notáveis. Forças. Problema. Contexto"

Transcrição

1 Casos Notáveis Padrão Data Access Object ataaccessobject.html Padrão Intercepting Filter terceptingfilter.html Moldura de Objectos JUnit Erich Gamma and Kent Beck Padrão Arquitectural Modelo-Vista-Controlador In Pattern-Oriented Software Architecture: A System of Patterns. Frank Buschmann et al. Padrão Data Access Object Contexto Acesso aos dados depende da fonte dos dados tipo de armazenamento implementação do vendedor Desenho de Software 79 Desenho de Software 80 Problema As aplicações podem usar a API JDBC mas mesmo num SGBD relacional e sintaxe e o formato dos comando SQL pode variar devido ao particular produto Existe ainda maior variação quando se usam diferentes tipos de SGBD Cria-se uma dependência entre o código da aplicação e o código de acesso aos dados que dificulta a migração entre diferentes tipos de SGBD e diferentes produtos de um mesmo tipo Forças Componentes aplicacionais necessitam de obter/guardar informação de/para um suporte persistente As APIs dos suportes persistentes variam dependendo do vendedor do produto e do tipo do produto Componentes aplicacionais usualmente usam APIs proprietárias A portabilidade dos componentes aplicacionais é afectada Desenho de Software 81 Desenho de Software 82

2 Solução Utilizar um objecto de acesso aos dados (DAO) para abstrair e encapsular todos os acessos à fonte de dados O DAO gere a ligação à fonte de dados para obter e guardar dados O DAO funciona como um adaptador entre o componente e a fonte de dados Estrutura Desenho de Software 83 Desenho de Software 84 Participantes e Colaborações Estratégia Factory Method Desenho de Software 85 Desenho de Software 86

3 Estratégia Abstract Factory e Factory Method Estratégia Desenho de Software 87 Desenho de Software 88 Código: Fábrica Abstracta package ServidorPersistente; public interface ISuportePersistente { public void iniciartransaccao() throws ExcepcaoPersistencia; public void confirmartransaccao() throws ExcepcaoPersistencia; public void cancelartransaccao() throws ExcepcaoPersistencia; public IItemPersistente getiitempersistente(); public ISeccaoPersistente getiseccaopersistente(); public ISitioPersistente getisitiopersistente(); Desenho de Software 89 Código: Fábrica Concreta package ServidorPersistente.OJB; public class SuportePersistenteOJB implements ISuportePersistente { Implementation _odmg = null; Database _db = null;... public IItemPersistente getiitempersistente() { return new ItemOJB(); public ISeccaoPersistente getiseccaopersistente() { return new SeccaoOJB(); public ISitioPersistente getisitiopersistente() { return new SitioOJB(); Desenho de Software 90

4 Código: Interface DAO package ServidorPersistente; import Dominio.ISitio; public interface ISitioPersistente { ISitio readbynome(string nome) throws ExcepcaoPersistencia; void write(isitio sitio) throws ExcepcaoPersistencia; void delete(isitio sitio) throws ExcepcaoPersistencia; void deleteall() throws ExcepcaoPersistencia; Código: Implementação OJB package ServidorPersistente.OJB; public class SitioOJB extends ObjectFenixOJB implements ISitioPersistente { public SitioOJB() {... public void deleteall() throws ExcepcaoPersistencia { String oqlquery = "select all from " + Sitio.class.getName(); super.deleteall(oqlquery); Desenho de Software 91 Desenho de Software 92 Código: Objecto Valor package Dominio; public class Sitio implements ISitio { private String _nome; private int _anocurricular; private int _semestre; private String _departamento; private String _curso; private List _seccoes; // códigos internos da base de dados private int _codigointerno;... // getter e setter methods... Consequências Permite a transparência Facilita a migração Reduz a complexidade do código do componente aplicacional Centraliza os acessos a dados numa camada separada Acrescenta uma camada adicional Necessita do desenho de uma hierarquia de classes Desenho de Software 93 Desenho de Software 94

5 Padrão Intercepting Filter O mecanismo de tratamento de pedidos da camada de apresentação trata pedidos muito diferentes entre si, o que implica tratamento especializado para cada um deles Alguns pedidos têm tratamento imediato, enquanto outros necessitam de ser modificados ou verificados antes de serem processados Problema É necessário haver pré- e pósprocessamento dos pedidos feitos por um cliente Web e das respectivas respostas O cliente foi autenticado? A sessão do cliente é válida? O tipo de browser do cliente é suportado?... Desenho de Software 95 Desenho de Software 96 Forças Deve haver processamento comum a todos os pedidos e respostas Centralização da lógica comum A adição e remoção dos componentes de processamento deve ser independente Solução Criar filtros para processar os serviços comuns de forma que: Interceptem os pedidos que chegam e as respostas que são enviadas Seja possível adicionar ou remover os filtros de forma discreta sem ser necessário modificar o código já existente Desenho de Software 97 Desenho de Software 98

6 Estrutura Colaboração Desenho de Software 99 Desenho de Software 100 Participantes GestorFiltros Gere o processamento dos filtros Cria a CadeiaFiltros com os filtros apropriados, na ordem correcta, e inicia o processamento CadeiaFiltros Conjunto ordenado de filtros independentes Filtro1, Filtro2, Filtro3 Filtros individuais que são mapeados para um alvo A CadeiaFiltros coordena o seu processamento Alvo Consiste no recurso pedido pelo cliente Custom Filter (1/3) Custom Filter Definido pelo programador Menos flexível e menos poderoso que o Standard Filter Exemplos: Utilização do Decorator para encapsular o processamento dos pedidos dentro dos filtros Utilização de Gestor de Filtros e Cadeia de Filtros para coordenar o processamento dos filtros Desenho de Software 101 Desenho de Software 102

7 Custom Filter (2/3) Exemplo Utilização do Decorator Custom Filter (3/3) Exemplo Utilização de Gestor e Cadeia de Filtros Problema Se alterarmos a forma de tratar o pedido, tem que se alterar também o código dos filtros e do processamento principal Problema Filtros adicionados ou removidos programaticamente Desenho de Software 103 Desenho de Software 104 Standard Filter Standard Filter Os filtros são controlados declarativamente, utilizando um ficheiro de configuração Este ficheiro inclui o mapeamento dos filtros para URL s específicos Quando um cliente faz um pedido a que corresponde aquele URL mapeado, os filtros são processados por ordem antes que o alvo do pedido seja invocado <filter> <filter-name> StandardEncodeFilter </filter-name>... </filter>... <filter-mapping> <filter-name> StandardEncodeFilter </filter-name> <url-pattern> /EncodeTestServlet </url-pattern> </filter-mapping> Outras Estratégias Base Filter Superclasse comum a todos os filtros utilizados Partilhada por todos os filtros Encapsula funcionalidades comuns Template Filter Base Filter que contém uma estrutura fixa a que todos os filtros têm que obedecer Cada subclasse filtro implementa a sua funcionalidade para essa estrutura Desenho de Software 105 Desenho de Software 106

8 Consequências Centraliza o controlo com fraca ligação entre filtros Promove a reutilização Configuração independente e declarativa A partilha de informação é ineficiente Moldura de Objectos Uma moldura de objectos é um desenho reutilizável que modela parte de um sistema de software e é descrito por um conjunto de classes abstractas e pela forma como as suas instâncias colaboram Uma moldura de objectos resulta sempre de uma análise do domínio Uma boa moldura de objectos pode reduzir o custo de desenvolvimento de uma ordem magnitude pois permite a reutilização de desenho e código. O desenvolvimento de uma boa moldura de objectos é difícil pois tem de ser simples para ser fácil de aprender e facilmente utilizável, e expressiva de modo a cobrir as variações do domínio Desenho de Software 107 Desenho de Software 108 Moldura de Objectos Junit em UML Um exemplo de utilização do UML como forma de comunicar desenho Dá ênfase ao que é relevante Não substitui o código A Visão de Componentes Desenho de Software 109 Desenho de Software 110

9 A Moldura de Testes Uma Colaboração Desenho de Software 111 Desenho de Software 112 Moldura de Objectos JUnit Objectivos Simplificar a construção de testes de modo a que os programadores se sintam motivados a escrever testes Escrever testes que sejam perenes e sejam utilizáveis por outras pessoas para além do criador Seja possível combinar testes feitos por diferentes pessoas Utilizar testes para construir novos testes Caso de Teste Tornar cada caso de teste num objecto de modo a simplificar a sua manipulação O padrão Comando encapsula um pedido como um objecto permitindo listar pedidos, guardar pedidos,... Desenho de Software 113 Desenho de Software 114

10 Caso de Teste public abstract class TestCase implements Test { private final String fname; public TestCase(String name) { fname= name; public abstract void run(); Parte Fixa Como separo a parte fixa de um teste da parte de teste O padrão Método Matriz define um esqueleto de algoritmo permitindo que algumas das etapas surjam em subclasses mas preservando-se a estrutura do algoritmo Desenho de Software 115 Desenho de Software 116 Parte Fixa Resultados do Teste Pretende-se registar o resultado das falhas e um sumário condensado dos sucessos public void run() { setup(); runtest(); teardown(); protected void runtest() { protected void setup() { protected void teardown() { Desenho de Software 117 Desenho de Software 118

11 Resultados do Teste public class TestResult extends Object { protected int fruntests; public TestResult() { fruntests= 0; public void run(testresult result) { result.starttest(this); setup(); runtest(); teardown(); Faltas dos Testes Existem dois tipos de faltas: falhas e erros. Os primeiros podem ser antecipados. Em ambos os casos pretende-se que os testes continuem a executar public synchronized void starttest(test test) { fruntests++; Desenho de Software 119 Desenho de Software 120 Faltas dos Testes public void run(testresult result) { result.starttest(this); setup(); try { runtest(); catch (AssertionFailedError e) { result.addfailure(this, e); catch (Throwable e) { result.adderror(this, e); finally { teardown(); protected void assert(boolean condition) { if (!condition) throw new AssertionFailedError(); Faltas dos Testes É necessário registar as faltas em TestResult public synchronized void adderror(test test, Throwable t) { ferrors.addelement(new TestFailure(test, t)); public synchronized void addfailure(test test, Throwable t) { ffailures.addelement(new TestFailure(test, t)); public class TestFailure extends Object { protected Test ffailedtest; protected Throwable fthrownexception; Desenho de Software 121 Desenho de Software 122

12 Proliferação de Classes A aplicação do padrão Comando a cada caso de teste leva a uma proliferação de classes, uma para cada teste Como juntar os casos de teste numa única classe e serem uniformes do ponto de vista do invocador dos testes? O padrão Adaptador converte a interface de uma classe numa outra que é esperada pelo cliente Proliferação de Classes Desenho de Software 123 Desenho de Software 124 Proliferação de Classes Padrão Adaptador public class TestMoneyEquals extends MoneyTest { public TestMoneyEquals() { super("testmoneyequals"); protected void runtest () { testmoneyequals(); Ou utiliza-se reflexão do JAVA protected void runtest() throws Throwable { Method runmethod= null; try { runmethod= getclass().getmethod(fname, new Class[0]); catch (NoSuchMethodException e) { assert("method \""+fname+"\" not found", false); try { runmethod.invoke(this, new Class[0]); // catch InvocationTargetException and IllegalAccessException Composição de Casos de Teste Necessita-se executar diversos testes e de modo a que o resultado é escrito no mesmo TestResult O padrão Composição compõe objectos em árvores que representam hierarquias todo-parte permitindo tratar uniformemente os objectos individuais e as composições Desenho de Software 125 Desenho de Software 126

13 Composição de Casos de Teste Composição de Casos de Teste public void run(testresult result) { for (Enumeration e= ftests.elements(); e.hasmoreelements(); ) { Test test= (Test)e.nextElement(); test.run(result); public void addtest(test test) { ftests.addelement(test); public interface Test { public abstract void run(testresult result); public class TestSuite implements Test { private Vector ftests= new Vector(); public static Test suite() { TestSuite suite= new TestSuite(); suite.addtest(new MoneyTest("testMoneyEquals")); suite.addtest(new MoneyTest("testSimpleAdd")); public static Test suite() { return new TestSuite(MoneyTest.class); Desenho de Software 127 Desenho de Software 128 Moldura de Objectos JUnit Padrão Arquitectural MVC O padrão arquitectural Modelo-Vista- Controlador (MVC) divide uma aplicação interactiva em três componentes: modelo, vista e controlador O modelo contém o núcleo da funcionalidade e dos dados As vistas mostram a informação ao utilizador Os controladores tratam das entradas dos utilizadores As vistas e os controladores formam a interface. Um mecanismo de propagação das alterações assegura a coerência entre a interface utilizador e o modelo Desenho de Software 129 Desenho de Software 130

14 Exemplo Problema As interfaces utilizador são muito passíveis de sofrerem pedidos de alteração Diferentes utilizadores têm requisitos diferentes, e por vezes conflituosos, sobre como deve ser a interface utilizador Um sistema que satisfaça os requisitos acima deve permitir: Desenho de Software 131 A mesma informação ser apresentada de forma diferente em distintas janelas A visualização e comportamento da aplicação reflecte imediatamente as alterações aos dados Alterações à interface são fáceis e possíveis em tempo de execução O suporte de diferentes look and feel não deve afectar o núcleo da aplicação Desenho de Software 132 Solução Existem três tipos de componentes: modelo, vista e controlador Estrutura O modelo encapsula o cerne dos dados e da funcionalidade, é independente das representações de saída e do comportamento associado às entradas A vista mostra os dados ao utilizador, obtém os dados do modelo e permite a existência diferentes vistas do modelo O controlador recebe os eventos de entrada que converte para pedidos de serviços ao modelo e às vistas Model * coredata : undefined attach() detach() notify() getdata() service() update() View initialize() makecontroller() activate() display() update() 133 Observer Controller 1 A separação entre o modelo a vista e o controlador permite múltiplas vistas do mesmo modelo Desenho de Software 1 Desenho de Software 0..1 initialize() handleevent() update() 134

15 Dinâmica: Propagação :C o n tro ller :M odel :V iew main program: Dinâmica: Inicialização handleevent service create :M o d el notify up date create in it ializ e :V iew getd ata attach makecontroller create :C o n t ro ller up date getd ata attach in it ializ e starteventprocessing Desenho de Software 135 Desenho de Software 136 Vantagens Consequências Múltiplas vistas do mesmo modelo Sincronização das vistas Troca dinâmica de vistas e controladores Alteração do look and feel Potencial para moldura de objectos Desvantagens Aumento da complexidade Possível excesso do número de propagação de alterações Ligação forte entre as vistas e os respectivos controladores Ligação forte das vistas e controladores com o modelo Ineficiência dos acessos aos modelos por parte dados das vistas Alteração da vista e do controlador quando é necessário portar InterfaceDocente InterfaceAluno Exemplo ServidorDocente Dominio ServidorAluno ServidorDados Desenho de Software 137 Desenho de Software 138

16 Conclusões P62 Relacionar o Desenho com os Requisitos É necessário saber que requisitos são satisfeitos por cada componente P63 Avaliar Alternativas Enumerar um conjunto de arquitecturas e analisar cada uma delas de acordo com os objectivos Alguns métodos de desenho têm como resultado arquitecturas específicas, nessa situação deve-se seleccionar o método mais adequado Desenho de Software 139 Conclusões P65 - Encapsular P66 Não Reinventar a Roda Reutilizar ideias, componentes, técnicas,... P67 Não Complicar Existem duas formas de construir um desenho de software. Uma forma é fazer o desenho tão simples que é óbvio não ter deficiências. Uma outra forma é fazer o desenho tão complicado que não tem deficiências óbvias. C. A. R. Hoare Desenho de Software 140 Conclusões P68 Evitar Muitos Casos Especiais Se existirem provavelmente foi porque se definiram as abstracções ou os algoritmos errados P69 Minimizar a Distância Intelectual A distância entre o problema e a solução Pessoas diferentes percebem diferentes estruturas quando analisam o mesmo problema Conclusões P71 Manter a Integridade do Desenho Usar um número limitado de formas de desenho Alterar as formas estabelecidas apenas quando para introduzir mais elegância ou simplicidade P73 Usar Ligação Fraca e Coesão Forte Desenho de Software 141 Desenho de Software 142

17 P74 Desenhar para as Alterações O desenho deve ser: Modular Portável Flexível Com a menor distância intelectual Compreensível Conclusões Com integridade conceptual Desenho de Software 143 Conclusões P77 Introduzir Generalidade no Software Componentes genéricos podem cumprir o seu objectivo em diversas situações sem terem de ser alterados Componentes genéricos são mais difíceis de desenhar e normalmente possuem um menor desempenho, mas: São ideais quando uma função semelhante tem que ser executada em vários sítios Permitem maior reutilização sem modificação Reduzem as despesas de manutenção devido ao reduzido número de componentes Desenho de Software 144 Conclusões P78 Introduzir Flexibilidade no Software Componentes flexíveis podem ser facilmente modificados para se adaptarem a uma nova situações Componentes flexíveis são mais difíceis de desenhar, mas: Possuem um maior desempenho que os componentes genéricos Permitem maior reutilização que os menos flexíveis Referências Pfleeger98, Capítulo 5, excepto 5.2 e 5.4. David95, Alguns princípios do Capítulo 4. Erich Gamma et al. Bridge Design Pattern. In Gamma95. Brian Foote and William Opdyke. Lifecycle and Refactoring Patterns That Support Evolution and Reuse. In Pattern Languages of Program Design Capítulo Martin Fowler. Introduce Null Object. In Refactoring: Improving the Design of Existing Code Robert Martin. OO Design Quality Metrics: An Analysis of Dependencies. Desenho de Software 145 Desenho de Software 146

18 Referências Deepak Alur et al. Data Access Object pattern AccessObject.html Deepak Alur et al. Intercepting Filter pattern ceptingfilter.html Martin Fowler. A UML Testing Framework. Software Development OnLine. April c.htm Erich Gamma and Kent Beck. JUnit A Cook's Tour. Frank Buschmann et al. Model-View-Controller. In Buschmann96. Desenho de Software 147

Moldura de Objectos. Moldura de Objectos Junit em UML

Moldura de Objectos. Moldura de Objectos Junit em UML Moldura de Objectos Uma PROGXUDGHREMHFWRV é um desenho reutilizável que modela parte de um sistema de software e é descrito por um conjunto de classes abstractas e pela forma como as suas instâncias colaboram

Leia mais

" ##$#$!% # & #$#$!!! "!!

 ##$#$!% # & #$#$!!! !! " ##$#$!% # & #$#$ # $ % &'! $ ( Desenho com Padrões (top-down) Identificar o problema a resolver Seleccionar os padrões adequados Verificar a aplicabilidade dos padrões ao problema em questão Instanciar

Leia mais

Detalhamento de um Framework Horizontal: JUNIT

Detalhamento de um Framework Horizontal: JUNIT Detalhamento de um Framework Horizontal: JUNIT Material baseado no artigo A Cook's Tour Ver também o artigo Test Infected: Programmers Love Writing Tests Um excelente exemplo da aplicação de vários Design

Leia mais

Aperfeiçoamento do Desenho. Desenho por Contrato

Aperfeiçoamento do Desenho. Desenho por Contrato Aperfeiçoamento do Desenho Desenho por contrato Protótipos de desenho Desenho de Software 7 Desenho por Contrato Utiliza-se a técnica de desenho por contrato para assegurar que o desenho satisfaz a sua

Leia mais

Desenho de Software. António Rito Silva - João Pereira

Desenho de Software. António Rito Silva - João Pereira Desenho de Software António Rito Silva - Rito.Silva@ist.utl.pt João Pereira Joao@inesc-id.pt Sumário Caracterização Objectivos Problemas Qualidades Técnicas Avaliação e Validação Casos Notáveis Exemplo

Leia mais

Desenho de Software. António Rito Silva Rito.Silva@inesc-id.pt

Desenho de Software. António Rito Silva Rito.Silva@inesc-id.pt Desenho de Software António Rito Silva Rito.Silva@inesc-id.pt Sumário Caracterização Objectivos Problemas Qualidades Técnicas Avaliação e Validação Casos Notáveis Exemplo Conclusões Desenho de Software

Leia mais

Arquitectura de Sistemas de Software

Arquitectura de Sistemas de Software Arquitectura de Sistemas de Software Ademar Aguiar www.fe.up.pt/~aaguiar ademar.aguiar@fe.up.pt Seminários Arquitectura LEIC, de 30 Sistemas de Outubro de Software, de 2002 LEIC/MEI, 2003/2004 1 Abstract

Leia mais

Arquitectura de Sistemas de Software

Arquitectura de Sistemas de Software Arquitectura de Sistemas de Software Ademar Aguiar www.fe.up.pt/~aaguiar ademar.aguiar@fe.up.pt Arquitectura de Sistemas de Software, LEIC/MEI, 2003/2004 1 Frameworks orientadas por objectos Arquitectura

Leia mais

Desenho com Padrões: Exemplo de desenho da framework de testes JUnit

Desenho com Padrões: Exemplo de desenho da framework de testes JUnit Desenho com Padrões: Exemplo de desenho da framework de testes JUnit www.fe.up.pt/~aaguiar ademar.aguiar@fe.up.pt 1 Desenho de software com padrões Desenho com Padrões (top-down) Identificar o problema

Leia mais

Web Presentation Patterns - Controllers

Web Presentation Patterns - Controllers Instituto Superior Técnico 29 de Novembro de 2004 1 2 3 Page Controller Front Controller 4 5 Porquê Usar Web Applications Não necessita instalar software no cliente. Acesso universal fácil. Interface comum

Leia mais

Segunda Parte (3 valores) Primeira Parte (7 valores) Nome: Número: PERGUNTA NOTA PERGUNTA RESPOSTA

Segunda Parte (3 valores) Primeira Parte (7 valores) Nome: Número: PERGUNTA NOTA PERGUNTA RESPOSTA 2º Teste 2012/2013 1º Semestre 201301171830 1/7 2º Teste 2012/2013 1º Semestre 17 de Janeiro de 2013, 11:30 (120 minutos) Nome: Número: Primeira Parte (7 valores) PERGUNTA NOTA 1.1.1 1.1.2 1.1.3 1.2 1.3

Leia mais

ALUNO: RONI FABIO BANASZEWSKI

ALUNO: RONI FABIO BANASZEWSKI Model-View-Controller ALUNO: RONI FABIO BANASZEWSKI Objetivo Separar dados ou lógica de negócios (Model) da interface do usuário (View) e do fluxo da aplicação (Control) A idéia é permitir que uma mesma

Leia mais

Arquitectura de Sistemas de Software Mestrado em Engenharia Informática Licenciatura em Engenharia Informática e Computação

Arquitectura de Sistemas de Software Mestrado em Engenharia Informática Licenciatura em Engenharia Informática e Computação Arquitectura de Sistemas de Software Mestrado em Engenharia Informática Licenciatura em Engenharia Informática e Computação Ademar Aguiar Universidade do Porto & INESC Porto ademar.aguiar at fe.up.pt FEUP

Leia mais

Padrões de Projeto. Padrões de Projeto. Além dos 23 Padrões GoF. Os 23 Padrões de Projeto. Documentação de um Padrão. Classificação dos Padrões

Padrões de Projeto. Padrões de Projeto. Além dos 23 Padrões GoF. Os 23 Padrões de Projeto. Documentação de um Padrão. Classificação dos Padrões DCC / ICEx / UFMG Padrões de Projeto Padrões de Projeto Eduardo Figueiredo http://www.dcc.ufmg.br/~figueiredo Um padrão é uma descrição do problema e a essência da sua solução Documenta boas soluções para

Leia mais

Programação com Objectos 2º Teste Tipo 1º Semestre (120 minutos)

Programação com Objectos 2º Teste Tipo 1º Semestre (120 minutos) 1/8 Programação com Objectos 2º Teste Tipo 1º Semestre (120 minutos) Nome: Primeira Parte (7 valores) PERGUNTA NOTA 1.1.1 1.1.2 1.1.3 1.2 1.3 1.4 Segunda Parte (3 valores) PERGUNTA RESPOSTA 2.1 2.2 2.3

Leia mais

Programação com Objectos. 2º Teste 2015/2016 1º Semestre

Programação com Objectos. 2º Teste 2015/2016 1º Semestre 1/7 2015/2016 1º Semestre 13 de Janeiro de 2016, 18:30 (120 minutos) 2º Teste Nome: Número: Primeira Parte (3 valores) PERGUNTA RESPOSTA Segunda Parte (7 valores) PERGUNTA 1.1 2.1 1.2 2.2.1 1.3 2.2.2 1.4

Leia mais

Engenharia de Software

Engenharia de Software UNIVERSIDADE DE LISBOA INSTITUTO SUPERIOR TÉCNICO Engenharia de Software LEIC/LETI, 3 o Ano, 2 o Semestre 2 o Teste, 8 de Junho de 2016 Nome: Número: Este teste tem um conjunto de 10 perguntas de escolha

Leia mais

JUnit: framework de testes unitários. Fred Lopes

JUnit: framework de testes unitários. Fred Lopes JUnit: framework de testes unitários Fred Lopes Agenda Parte 1 - teoria Testes unitários JUnit Introdução Arquitetura API resumida Boas práticas Exemplos de uso Parte 2 prática (Eclipse) Criando testes

Leia mais

Engenharia de Software

Engenharia de Software UNIVERSIDADE DE LISBOA INSTITUTO SUPERIOR TÉCNICO Engenharia de Software LEIC/LETI, 3 o Ano, 2 o Semestre Repescagem do 2 o Teste, 1 de Julho de 2016 Nome: Número: Este teste tem um conjunto de 10 perguntas

Leia mais

REST. Representational State Transfer. É um estilo arquitetural usado por muitas aplicações Web para estender as suas funcionalidades.

REST. Representational State Transfer. É um estilo arquitetural usado por muitas aplicações Web para estender as suas funcionalidades. REST Representational State Transfer É um estilo arquitetural usado por muitas aplicações Web para estender as suas funcionalidades. Não é um padrão. Exemplo ASP.NET Web API namespace WebAPIApp.Models

Leia mais

Sumário. Escrita de Programas. Qualidades. Objectivos. Engenharia de Software. Caracterização. Técnicas Casos Notáveis Conclusões

Sumário. Escrita de Programas. Qualidades. Objectivos. Engenharia de Software. Caracterização. Técnicas Casos Notáveis Conclusões Engenharia de Software Escrita de Programas António Rito Silva Rito.Silva@inesc-id.pt Sumário Caracterização Objectivos Qualidades Técnicas Casos Notáveis Conclusões Escrita de Programas 2 Objectivos O

Leia mais

Escrita de Programas. António Rito Silva

Escrita de Programas. António Rito Silva Escrita de Programas António Rito Silva Rito.Silva@inesc-id.pt Sumário Caracterização Objectivos Qualidades Técnicas Casos Notáveis Conclusões Escrita de Programas 2 Objectivos O desenho pode não ter abordado

Leia mais

Soluções reutilizáveis para situações ou problemas encontrados comumente em desenvolvimento de software orientado a objetos.

Soluções reutilizáveis para situações ou problemas encontrados comumente em desenvolvimento de software orientado a objetos. Padrões de Projeto O que são? Soluções reutilizáveis para situações ou problemas encontrados comumente em desenvolvimento de software orientado a objetos. Livros Design Patterns: Elements of Reusable Object-

Leia mais

Tópicos da Aula. POO e Padrões de Projetos. Considere três classes... Reuso de Classes. Locadora de DVD. Sistema Acadêmico

Tópicos da Aula. POO e Padrões de Projetos. Considere três classes... Reuso de Classes. Locadora de DVD. Sistema Acadêmico Reuso de Software Aula 03 Tópicos da Aula POO e Padrões de Projetos Eduardo Figueiredo http://www.dcc.ufmg.br/~figueiredo reuso.software@gmail.com 12 Março 2012 Programação orientada a objetos Reuso de

Leia mais

Java para Desktop. Programação Orientada à Objetos 2 JSE

Java para Desktop. Programação Orientada à Objetos 2 JSE Java para Desktop Programação Orientada à Objetos 2 JSE Encapsulamento significa "ocultar informações, ele define que cada objeto contém todos os detalhes de implementação necessários sobre como ele funciona

Leia mais

Testes com JUnit. Treinamento ALESP SPL. Danilo Toshiaki Sato.

Testes com JUnit. Treinamento ALESP SPL. Danilo Toshiaki Sato. Testes com JUnit Danilo Toshiaki Sato dtsato@ime.usp.br Treinamento ALESP SPL Agenda 1. Introdução 2. Por que usar JUnit? 3. Quando escrever um teste? 4. Como escrever um teste? 5. Como rodar um teste?

Leia mais

LEIC-A / MEIC-A 2007/2008 (1º

LEIC-A / MEIC-A 2007/2008 (1º 1/11 LEIC-A / MEIC-A 2007/2008 (1º Semestre) Teste (versão A) 08 de Janeiro de 2008, 09:00 (120 minutos) Nome: Primeira Parte (5 valores) PERGUNTA RESPOSTA 1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8 1.9 1.10 Segunda

Leia mais

DATA ACCESS OBJECT (DAO)

DATA ACCESS OBJECT (DAO) Universidade de São Paulo, Instituto de Ciências Matemáticas e de Computação DATA ACCESS OBJECT (DAO) SSC 621: Análise e Projeto Orientados a Objetos Prof. Dr. Lucas Bueno R. Oliveira 2º Semestre 2015

Leia mais

Nome: Número: Segunda Parte (3 valores) Primeira Parte (7 valores)

Nome: Número: Segunda Parte (3 valores) Primeira Parte (7 valores) 2º Teste 2013/2014 1º Semestre 201401140900 2º Teste 2013/2014 1º Semestre 14 de Janeiro de 2014, 09:00 (120 minutos) Nome: Número: 1/8 Primeira Parte (7 valores) PERGUNTA NOTA 1.1.1 1.1.2 1.1.3 1.2.1

Leia mais

LEIC-T LERC MEIC-T 2011/2012 1º Semestre Programação com Objetos 2012/01/07 11h00m 3/10

LEIC-T LERC MEIC-T 2011/2012 1º Semestre Programação com Objetos 2012/01/07 11h00m 3/10 2/10 1.1. (1.5 val.) Os mecanismos de herança entre classes e de composição de objetos são, por vezes, apresentados como alternativos, face à disponibilização de funcionalidade a uma classe. Compare-os,

Leia mais

INF1636 PROGRAMAÇÃO ORIENTADA A OBJETOS

INF1636 PROGRAMAÇÃO ORIENTADA A OBJETOS INF1636 PROGRAMAÇÃO ORIENTADA A OBJETOS Departamento de Informática PUC-Rio Ivan Mathias Filho ivan@inf.puc-rio.br Programa Capítulo 17 Padrões de Design Singleton Facade Factory Method Observer Strategy

Leia mais

Universidade Federal de Uberlândia Faculdade de Computação Programação Orientada a Objetos II Prof. Fabiano Dorça. Padrão Observer (Observador)

Universidade Federal de Uberlândia Faculdade de Computação Programação Orientada a Objetos II Prof. Fabiano Dorça. Padrão Observer (Observador) Universidade Federal de Uberlândia Faculdade de Computação Programação Orientada a Objetos II Prof. Fabiano Dorça Problema: Definir uma dependência um-para-muitos entre objetos, de forma quando o estado

Leia mais

Programação com Objectos Teste Teórico (repescagem) 24 de Janeiro de 2009, 09:00 (120 minutos)

Programação com Objectos Teste Teórico (repescagem) 24 de Janeiro de 2009, 09:00 (120 minutos) 1/11 LEIC-A LEIC-T LERC MEIC-A 2008/2009 (1º Semestre) Teste Teórico (repescagem) 24 de Janeiro de 2009, 09:00 (120 minutos) Nome: Primeira Parte (5 valores) PERGUNTA RESPOSTA 1.1 1.2 1.3 1.4 1.5 1.6 1.7

Leia mais

Programação Orientada a Objectos - P. Prata, P. Fazendeiro

Programação Orientada a Objectos - P. Prata, P. Fazendeiro Quando um programa viola as restrições semânticas da linguagem, a JVM assinala um erro ao programa, sob a forma de exceção. Uma exceção é um erro recuperável O controlo da execução do programa é transferido

Leia mais

Padrão de projeto de software

Padrão de projeto de software Padrão de projeto de software Paulo Venancio Lopes e Daniel Sguillaro Nome Roupa Suja Se Lava Em Casa. Intenção Dar maior capacidade e flexibilidade ao conceito de entidade (no contexto de persitência

Leia mais

Definindo um padrão para arquitetura Web

Definindo um padrão para arquitetura Web Definindo um padrão para arquitetura Web Padrões de Projeto Soluções reutilizáveis para situações ou problemas encontrados comumente em desenvolvimento de software orientado a objetos. Livros Design Patterns:

Leia mais

Common Object Request Broker Architecture

Common Object Request Broker Architecture Common Object Request Broker Architecture OMG: Object Management Group. Organização internacional, sem fins lucrativos, fundada em 1989. Mais de 800 membros (incluindo fabricantes de sistemas, produtores

Leia mais

Análise e Projeto. Padrões de Análise, Arquitetura e Projeto

Análise e Projeto. Padrões de Análise, Arquitetura e Projeto Análise e Projeto Padrões de Análise, Arquitetura e Projeto 33 Padrões de Arquitetura Padrões Nome do padrão Problema: quando aplicar o padrão? Descreve o problema e seu contexto. Solução: elementos que

Leia mais

Quando um programa viola as restrições semânticas da linguagem, a JVM assinala um erro ao programa, sob a forma de exceção.

Quando um programa viola as restrições semânticas da linguagem, a JVM assinala um erro ao programa, sob a forma de exceção. 6 Exceções Quando um programa viola as restrições semânticas da linguagem, a JVM assinala um erro ao programa, sob a forma de exceção. Uma exceção é um erro recuperável - O controlo da execução do programa

Leia mais

4 Conceito de Herança

4 Conceito de Herança 4 Conceito de Herança Hierarquia de classes e mecanismo de ligação Herança Uma classe pode herdar operações de uma superclasse e as suas operações podem ser herdadas por subclasses. O mecanismo de herança

Leia mais

Padrões Fábrica. Simple Factory Factory Method

Padrões Fábrica. Simple Factory Factory Method Universidade Federal de Uberlândia Faculdade de Computação Disciplina: POO2 Prof. Fabiano Azevedo Dorça Padrões Fábrica Simple Factory Padrões Fábrica Padrão Simple Factory: fornece interfaces para criar

Leia mais

Um SGBD permite que cada utilizador tenha uma vista diferente (abstrata) do conteúdo da base de dados;

Um SGBD permite que cada utilizador tenha uma vista diferente (abstrata) do conteúdo da base de dados; 1 Bioinformatica Conceitos Básicos Camadas de abstração Um SGBD permite que cada utilizador tenha uma vista diferente (abstrata) do conteúdo da base de dados; Cada utilizador necessita de ter acesso a

Leia mais

Benvindo ao Curso de Introdução ao Firebird com Ferramenta de Relatórios!

Benvindo ao Curso de Introdução ao Firebird com Ferramenta de Relatórios! (Apresentação SQL Manager Lite for InterBase and Firebird) Benvindo ao Curso de Introdução ao Firebird com Ferramenta de Relatórios! Ferramenta de alta performance para a otimização da administração de

Leia mais

Campus Capivari Análise e Desenvolvimento de Sistemas (ADS) Prof. André Luís Belini /

Campus Capivari Análise e Desenvolvimento de Sistemas (ADS) Prof. André Luís Belini   / Campus Capivari Análise e Desenvolvimento de Sistemas (ADS) Prof. André Luís Belini E-mail: prof.andre.luis.belini@gmail.com / andre.belini@ifsp.edu.br MATÉRIA: ARQUITETURA DE SOFTWARE ASWA4 Aula N : 10

Leia mais

PROJETO ARQUITETURAL PARTE II: PADRÕES DE PROJETO. Projeto de Programas PPR0001

PROJETO ARQUITETURAL PARTE II: PADRÕES DE PROJETO. Projeto de Programas PPR0001 PROJETO ARQUITETURAL PARTE II: PADRÕES DE PROJETO Projeto de Programas PPR0001 QUALIDADE DO PROJETO 2 3 Qualidade do Projeto de Software Modularidade: gerar particionamento em elementos que executam funções

Leia mais

Visitor. Um problema a resolver. Temos uma hierarquia de classes, provavelmente um Composite Exemplo: Numa rede elétrica, temos a seguinte hierarquia:

Visitor. Um problema a resolver. Temos uma hierarquia de classes, provavelmente um Composite Exemplo: Numa rede elétrica, temos a seguinte hierarquia: Um problema a resolver Temos uma hierarquia de classes, provavelmente um Composite Exemplo: Numa rede elétrica, temos a seguinte hierarquia: Página 1 de 13 Esta hierarquia está sendo usada num programa

Leia mais

" ##$#$!% # & #$#$ !!!!"!

 ##$#$!% # & #$#$ !!!!! " ##$#$!% # & #$#$ Abstract Factory, Builder, Singleton, Factory Method, Prototype, Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Proxy, Chain of Responsability, Command, Interpreter, Iterator,

Leia mais

Abstract Factory. Prover uma interface para criar uma família de objetos relacionados ou dependentes sem especificar suas classes concretas

Abstract Factory. Prover uma interface para criar uma família de objetos relacionados ou dependentes sem especificar suas classes concretas Objetivo Prover uma interface para criar uma família de objetos relacionados ou dependentes sem especificar suas classes concretas Também chamado de Kit Resumo Parece semelhante ao padrão Factory Method,

Leia mais

Módulo III Padrões GOF

Módulo III Padrões GOF Módulo III Padrões GOF Professores Eduardo Bezerra edubezerra@gmail.com Ismael H F Santos ismael@tecgraf.puc-rio.br April 05 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 1 Ementa Introdução aos

Leia mais

J820. Mock objects. Testes de código com dependências. argonavis.com.br. Helder da Rocha

J820. Mock objects. Testes de código com dependências. argonavis.com.br. Helder da Rocha J820 Mock objects Testes de código com dependências Helder da Rocha (helder@acm.org) Como lidar com testes difíceis Testes devem ser simples e suficientes Comece com testes mais importantes Sempre pode-se

Leia mais

Padrões Arquiteturais. Silvia Regina Vergilio

Padrões Arquiteturais. Silvia Regina Vergilio Padrões Arquiteturais Silvia Regina Vergilio Exemplo de Padrão Arquitetural: MVC + call Observer update() Model coredata setofobservers attach() detach() notify() getdata() service() +attach get View mymodel

Leia mais

4 Diretrizes para o Projeto e Implementação de Frameworks usando Orientação a Aspectos

4 Diretrizes para o Projeto e Implementação de Frameworks usando Orientação a Aspectos 57 4 Diretrizes para o Projeto e Implementação de Frameworks usando Orientação a Aspectos Nossa abordagem para desenvolvimento de frameworks usando aspectos oferece um conjunto de diretrizes (seção 3.3.1)

Leia mais

DIVISÃO DE ASSUNTOS ACADÊMICOS Secretaria Geral de Cursos PROGRAMA DE DISCIPLINA

DIVISÃO DE ASSUNTOS ACADÊMICOS Secretaria Geral de Cursos PROGRAMA DE DISCIPLINA DIVISÃO DE ASSUNTOS ACADÊMICOS Secretaria Geral de Cursos PROGRAMA DE DISCIPLINA DEPARTAMENTO DE CIÊNCIAS EXATAS CÓDIGO: EXA836 DISCIPLINA: PADRÕES E FRAMEWORKS CARGA HORÁRIA: 60h EMENTA: Padrões e anti-padrões

Leia mais

Aula 17: Estudo de Caso: JUnit

Aula 17: Estudo de Caso: JUnit Aula 17: Estudo de Caso: JUnit O framework JUnit o qual você tem usado para testar seu próprio código no curso 6170 merece, ele próprio, ser estudado. Ele foi desenvolvido por Kent Beck e Erich Gamma.

Leia mais

Qualidade. Ana Madureira

Qualidade. Ana Madureira Qualidade Ana Madureira Qualidade da Informação A qualidade de uma informação é apreciada em função da sua pertinência (adaptação às necessidades do sistema de gestão). Três características permitem medir

Leia mais

Engenharia de Software

Engenharia de Software UNIVERSIDADE DE LISBOA INSTITUTO SUPERIOR TÉCNICO Engenharia de Software LEIC/LETI, 3 o Ano, 2 o Semestre 1 o Teste, 4 de Abril de 2017 Duração: 60 minutos Nome: Número: Este teste tem um conjunto de 8

Leia mais

INE 5612 Professor: Frank Siqueira. Leonardo Silva Jean Ercilio Thiago

INE 5612 Professor: Frank Siqueira. Leonardo Silva Jean Ercilio Thiago INE 5612 Professor: Frank Siqueira Alunos: Gustavo de Geus Leonardo Silva Jean Ercilio Thiago DESENVOLVEDORES JAVA EM TODO MUNDO LIDER GAVIN KING JBOSS MANTEVE O SUPORTE História Hibernate foi criado por

Leia mais

API JDBC. Paulo Ricardo Lisboa de Almeida. 1 Universidade Positivo

API JDBC. Paulo Ricardo Lisboa de Almeida. 1 Universidade Positivo API JDBC Paulo Ricardo Lisboa de Almeida 1 JDBC JDBC Java Database Connectivity API Java para conexões com bancos de dados Encontrada dentro de java.sql 2 JDBC Necessário driver JDBC do banco Classes concretas

Leia mais

Criação de uma aplicação Web ASP.NET MVC 4

Criação de uma aplicação Web ASP.NET MVC 4 Criação de uma aplicação Web ASP.NET MVC 4 usando Code First, com Roles (VS2012) Baseado no artigo de Scott Allen Roles in ASP.NET MVC4 : http://odetocode.com/blogs/scott/archive/2012/08/31/seeding membership

Leia mais

Programação Orientada a Objectos - P. Prata, P. Fazendeiro. Hierarquia de classes e mecanismo de ligação

Programação Orientada a Objectos - P. Prata, P. Fazendeiro. Hierarquia de classes e mecanismo de ligação 4 Conceito de Herança Hierarquia de classes e mecanismo de ligação Herança Uma classe pode herdar operações de uma superclasse e as suas operações podem ser herdadas por subclasses. O mecanismo de herança

Leia mais

Programação em Comunicações. Programação Orientada por Objectos. Ademar Aguiar.

Programação em Comunicações. Programação Orientada por Objectos. Ademar Aguiar. Programação em Comunicações Programação Orientada por Objectos www.fe.up.pt/~aaguiar ademar.aguiar@fe.up.pt 1 Objectivos Apresentar os princípios e conceitos base sobre orientação por objectos (objectos,

Leia mais

Padrões de Testes Automatizados

Padrões de Testes Automatizados Padrões de Testes Automatizados Paulo Cheque 10/02/2009 Verão2009 2 Introdução Testes codificados Exigem boa programação Mesmos problemas de um software Devem receber o mesmo tratamento Exigem manutenção

Leia mais

Desenho de Software. Sumário

Desenho de Software. Sumário (QJHQKDULDGD3URJUDPDomR Desenho de Software Carla Ferreira Carla.Ferreira@dei.ist.utl.pt Sumário Objectivos Problemas Qualidades Técnicas Avaliação e Validação Casos Notáveis Exemplo Conclusões Desenho

Leia mais

Cap. 1 Arquitectura de Sistemas de Bases de Dados

Cap. 1 Arquitectura de Sistemas de Bases de Dados Cap. 1 Arquitectura de Sistemas de Bases de Dados Abel J.P. Gomes Bibliografia usada: T. Connoly e C. Begg. Database Systems: a pratical approach to design,implementation, and management. Addison-Wesley,

Leia mais

Computação Paralela. Conceitos de Programação Orientada ao Objecto. João Luís Ferreira Sobral Departamento do Informática Universidade do Minho

Computação Paralela. Conceitos de Programação Orientada ao Objecto. João Luís Ferreira Sobral Departamento do Informática Universidade do Minho Computação Paralela Conceitos de Programação Orientada ao Objecto João Luís Ferreira Sobral Departamento do Informática Universidade do Minho Setembro 2006 Revisão Conceitos de Programação Orientada ao

Leia mais

Agenda da Aula. Reuso de Software. Tipos de Reuso. Potenciais Problemas. Vantagens de Reuso. Introdução a Reuso de Software

Agenda da Aula. Reuso de Software. Tipos de Reuso. Potenciais Problemas. Vantagens de Reuso. Introdução a Reuso de Software Reuso de Software Aula 02 Agenda da Aula Introdução a Reuso de Software Eduardo Figueiredo http://www.dcc.ufmg.br/~figueiredo reuso.software@gmail.com Introdução a Reuso de Software Abordagens de Reuso

Leia mais

PLATAFORMA SIGA RIO DAS VELHAS MANUAL DO CÓDIGO FONTE

PLATAFORMA SIGA RIO DAS VELHAS MANUAL DO CÓDIGO FONTE PLATAFORMA SIGA RIO DAS VELHAS MANUAL DO CÓDIGO FONTE ATO CONVOCATÓRIO Nº 006/2016 CONTRATO DE GESTÃO IGAM Nº 002/IGAM/2012 09/2017 1 PLATAFORMA SIGA RIO DAS VELHAS MANUAL DO CÓDIGO FONTE ATO CONVOCATÓRIO

Leia mais

Orientação a Objetos AULA 09

Orientação a Objetos AULA 09 Orientação a Objetos AULA 09 Prof. Fabrício Martins Mendonça Conteúdo da Aula ü Coleções ü Coleções lista de objetos ü Coleções conjuntos 2 Coleções Podemos armazenar vários objetos em um array e este

Leia mais

PROGRAMAÇÃO ORIENTADA A

PROGRAMAÇÃO ORIENTADA A PROGRAMAÇÃO ORIENTADA A OBJETOS II -TÉCNICAS DE OO Prof. Angelo Augusto Frozza, MS M.Sc. frozza@ifc-camboriu.edu.br ROTEIRO 4. Técnicas de Orientação a Objetos Classes e objetos Herança Métodos Subscritos

Leia mais

Arquitecturas Paralelas I Computação Paralela em Larga Escala. Conceitos de Programação Orientada ao Objecto

Arquitecturas Paralelas I Computação Paralela em Larga Escala. Conceitos de Programação Orientada ao Objecto Arquitecturas Paralelas I Computação Paralela em Larga Escala LESI - 4º Ano Conceitos de Programação Orientada ao Objecto (gec.di.uminho.pt/lesi/ap10203/aula02poo.pdf) João Luís Ferreira Sobral Departamento

Leia mais

Agenda. Padrões de Projeto para Sistemas Web. Introdução. Padrões. Referências. Misael Santos e Rossana Andrade

Agenda. Padrões de Projeto para Sistemas Web. Introdução. Padrões. Referências. Misael Santos e Rossana Andrade Padrões de Projeto para Sistemas Web Misael Santos e Rossana Andrade misael@lia.ufc.br Universidade Federal do Ceará Jan/2003 1 Agenda Introdução Servlets Padrões Web Interceptor Web Handlers Web Compiler

Leia mais

Singleton. Como a maioria dos programadores organizaria o código para acessar informação de configuração? Eis um exemplo:

Singleton. Como a maioria dos programadores organizaria o código para acessar informação de configuração? Eis um exemplo: Introdução Como a maioria dos programadores organizaria o código para acessar informação de configuração? Eis um exemplo: public class Config { public static final String DEFAULT_READ_COMMUNITY_NAME =

Leia mais

Paradigmas de Linguagens de Programação. Suporte para Programação Orientada a Objeto

Paradigmas de Linguagens de Programação. Suporte para Programação Orientada a Objeto Suporte para Programação Orientada a Objeto Cristiano Lehrer Categoria das Linguagens que Suportam POO Suporte a POO acrescentado a uma linguagem já existente: C++ (também suporta programação procedural

Leia mais

Módulo III Arquitetura em Camadas

Módulo III Arquitetura em Camadas Módulo III Arquitetura em Camadas Prof. Ismael H F Santos April 05 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 1 Ementa Módulo III Camadas de Software April 05 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br

Leia mais

Programação com Objectos Teste Teórico 18 de Dezembro de 2008, 19:00 (120 minutos)

Programação com Objectos Teste Teórico 18 de Dezembro de 2008, 19:00 (120 minutos) 1/11 LEIC-A LEIC-T LERC MEIC-A 2008/2009 (1º Semestre) Teste Teórico 18 de Dezembro de 2008, 19:00 (120 minutos) Nome: Primeira Parte (5 valores) PERGUNTA RESPOSTA 1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8 1.9 1.10

Leia mais

Programação Orientada a Objectos - P. Prata, P. Fazendeiro

Programação Orientada a Objectos - P. Prata, P. Fazendeiro 6 Exceções Quando um programa viola as restrições semânticas da linguagem, a JVM assinala um erro ao programa, sob a forma de exceção. Uma exceção é um erro recuperável O controlo da execução do programa

Leia mais

JUnit. Alexandre Menezes Silva Eduardo Manuel de Freitas Jorge

JUnit. Alexandre Menezes Silva Eduardo Manuel de Freitas Jorge JUnit Alexandre Menezes Silva alexandre_crvg@hotmail.com Eduardo Manuel de Freitas Jorge emjorge1974@gmail.com 0 Sumário O que é?... 2 Pra que serve?... 2 Arquitetura... 2 Método de comparação assertequals...

Leia mais

Protótipo de uma ferramenta de apoio para desenvolvimento de sistemas web para WebIntegrator

Protótipo de uma ferramenta de apoio para desenvolvimento de sistemas web para WebIntegrator Protótipo de uma ferramenta de apoio para desenvolvimento de sistemas web para WebIntegrator Ederson Evaristo Jantsch Orientador: Marcel Hugo 09/07/2002 Roteiro Introdução Aplicação multicamadas Tecnologias

Leia mais

Bases de Dados. Parte I: Conceitos Básicos

Bases de Dados. Parte I: Conceitos Básicos Bases de Dados Parte I Conceitos Básicos 1 Definições Básicas Dados: factos conhecidos que têm algum significado e que podem ser guardados. Base de dados (BD): conjunto de dados que se relacionam entre

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: 11 DATA: / / PROFESSOR: Andrey APRESENTAÇÃO O objetivo desta aula é apresentar e discutir os conceitos de Refatoração e Padrões. DESENVOLVIMENTO PADRÕES

Leia mais

// quando o estado do Sujeito muda

// quando o estado do Sujeito muda Padrão Observer No padrão Observer temos dois objectos: um, designado Sujeito (Subject) que possui uma dada informação que pode variar ao longo da execução do programa, e outro, designado Observador (Observer)

Leia mais

Num sistema de objectos distribuídos, dois conceitos são fundamentais.

Num sistema de objectos distribuídos, dois conceitos são fundamentais. Folha 9-1 Java RMI - Remote Method Invocation No modelo de programação orientada a objectos, vimos que um programa consiste numa colecção de objectos que comunicam entre si através da invocação dos seus

Leia mais

JAVA. Tópicos Especiais de Programação Orientada a Objetos. sexta-feira, 26 de outubro de 12

JAVA. Tópicos Especiais de Programação Orientada a Objetos. sexta-feira, 26 de outubro de 12 JAVA Tópicos Especiais de Programação Orientada a Objetos 1 REFATORAÇÃO DE CÓDIGOS 2 REFATORAÇÃO O QUE É REFATORAR? Refatorar é alterar o código de um projeto existente, sem mudar o seu comportamento,

Leia mais

2 Vectores de objectos

2 Vectores de objectos 2 Vectores de objectos Agenda de contactos 3 Objectivo Manipular uma agenda de contactos. Descrição e Funcionalides Cada contacto na agenda caracteriza-se por um nome, um telefone e um e-mail. Na agenda,

Leia mais

PATI-MVC: Padrões MVC para Sistemas de Informação. Gabriela T. De Souza Instituto Atlântico

PATI-MVC: Padrões MVC para Sistemas de Informação. Gabriela T. De Souza Instituto Atlântico PATI-MVC: Padrões MVC para Sistemas de Informação Gabriela T. De Souza gabi@atlantico.com.br Instituto Atlântico Carlo Giovano S. Pires cgiovano@atlantico.com.br Instituto Atlântico Márcio de Oliveira

Leia mais

Domain Logic Patterns. Pedro Lemos N.º Arquitecturas de Software LEIC

Domain Logic Patterns. Pedro Lemos N.º Arquitecturas de Software LEIC Pedro Lemos N.º 49467 pcml@rnl.ist.utl.pt Arquitecturas de Software 2004 - LEIC Outline da Apresentação 1. Introdução e Motivação de Padrões de Software 2. Padrões Arquitecturais para Aplicações Empresariais

Leia mais

// quando o estado do Sujeito muda

// quando o estado do Sujeito muda Padrão Observer No padrão Observer temos dois objectos: um, designado Sujeito (Subject) que possui uma dada informação que pode variar ao longo da execução do programa, e outro, designado Observador (Observer)

Leia mais

(QJHQKDULDGH6RIWZDUH. Testes. 2001, 2004 (QJHQKDULD GH6RIWZDUH Departamento de Engenharia Informática Instituto Superior Técnico.

(QJHQKDULDGH6RIWZDUH. Testes. 2001, 2004 (QJHQKDULD GH6RIWZDUH Departamento de Engenharia Informática Instituto Superior Técnico. (QJHQKDULDGH6RIWZDUH Testes 2001, 2004 (QJHQKDULD GH6RIWZDUH Departamento de Engenharia Informática Instituto Superior Técnico 1 Motivação Garantir comportamento pretendido Testes devem ser definidos à

Leia mais

Notas de Aula 09: Tratamento de exceções

Notas de Aula 09: Tratamento de exceções Notas de Aula 09: Tratamento de exceções Objetivos da aula: Compreender o conceito de exceção Aprender a tratar exceções nos programas Entender a hierarquia das exceções Criar e lançar uma exceção proprietária

Leia mais

ESTUDO DO PADRÃO DE PROJETO OBSERVER NO DESENVOLVIMENTO DE SOFTWARES UTILIZANDO A ARQUITETURA MVC RESUMO

ESTUDO DO PADRÃO DE PROJETO OBSERVER NO DESENVOLVIMENTO DE SOFTWARES UTILIZANDO A ARQUITETURA MVC RESUMO Mostra Nacional de Iniciação Científica e Tecnológica Interdisciplinar III MICTI Fórum Nacional de Iniciação Científica no Ensino Médio e Técnico - I FONAIC-EMT Camboriú, SC, 22, 23 e 24 de abril de 2009

Leia mais

Recapitulando. Construtores: (Overload assinatura) public Circle() {...} public Circle(double x, double y, double r) {... }

Recapitulando. Construtores: (Overload assinatura) public Circle() {...} public Circle(double x, double y, double r) {... } Recapitulando Orientação a objetos: programas organizados em torno da definição de classes, instanciação de objetos e troca de mensagens. Declaração de variáveis de referencia: Circle c; Criação/instanciação

Leia mais

Programação Orientada a Objectos - P. Prata, P. Fazendeiro

Programação Orientada a Objectos - P. Prata, P. Fazendeiro Programação Orientada a Objetos 1.1 - Perspectiva histórica: Conceitos A evolução das linguagens de programação tem-se feito na procura de ferramentas: -cada vez mais próximas da percepção humana - e que

Leia mais

Herança. Herança. Herança. Herança. Herança. Programação Orientada a Objetos

Herança. Herança. Herança. Herança. Herança. Programação Orientada a Objetos e Ligação Dinâmica Programação Orientada a Objetos e Polimorfismo A é a contribuição original do paradigma de programação orientado a objetos Fundamentos chave do paradigma OO: Abstração de Dados A herança

Leia mais

Estilo: BlackBoard. BlackBoard = repositório de dados compartilhados

Estilo: BlackBoard. BlackBoard = repositório de dados compartilhados Estilo: BlackBoard Útil para problemas no qual não há uma solução determinística Uma coleção de programas independentes que trabalham cooperativamente em uma estrutura de dados comum (blackboard) Vários

Leia mais

PROGRAMAÇÃO ORIENTADA A OBJETOS II -TÉCNICAS DE OO. Prof. Angelo Augusto Frozza, M.Sc.

PROGRAMAÇÃO ORIENTADA A OBJETOS II -TÉCNICAS DE OO. Prof. Angelo Augusto Frozza, M.Sc. PROGRAMAÇÃO ORIENTADA A OBJETOS II -TÉCNICAS DE OO Prof. Angelo Augusto Frozza, M.Sc. frozza@ifc-camboriu.edu.br ROTEIRO 4. Técnicas de Orientação a Objetos Classes e objetos Herança Métodos Subscritos

Leia mais

No final deste curso, saberás criar programas através da linguagem de programação Java.

No final deste curso, saberás criar programas através da linguagem de programação Java. Programação em Java Programação Formato: Mentored - Online Preço: 415 ( Os valores apresentados não incluem IVA. Oferta de IVA a particulares e estudantes. ) Horário: Flexível das 24h/24h Duração: ~45h

Leia mais

Agenda. Instalação e configuração. Processamento de comandos SQL com JDBC. Driver JDBC Criação da classe de conexão

Agenda. Instalação e configuração. Processamento de comandos SQL com JDBC. Driver JDBC Criação da classe de conexão Agenda Instalação e configuração Driver JDBC Criação da classe de conexão Processamento de comandos SQL com JDBC Gerenciamento de conexões Execução simples de consultas Tratamento de exceções Instalação

Leia mais