Um Estudo sobre Padrões de Projeto Aplicados a Garbage Collection

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

Download "Um Estudo sobre Padrões de Projeto Aplicados a Garbage Collection"

Transcrição

1 Um Estudo sobre Padrões de Projeto Aplicados a Garbage Collection Cássio Frederico Moreira Druziani 1, Ailton Sergio Bonifácio 1, Yandre Maldonado e Gomes da Costa 1, Alberto Ângelo Fabris 2 1 Instituto de Informática Universidade Federal do Rio Grande do Sul (UFRGS) Caixa Postal Porto Alegre RS Brazil 2 Faculdade de Ciências Sociais Aplicadas de Cascavel (UNIVEL) Av. Titto Muffato, 2317, Bairro Santa Cruz Cascavel PR Brazil druziani@inf.ufrgs.br, ailton@uel.br, yandre@mar.sol.com.br, alberto@unioeste.br Abstract. This paper objective to show the project standards concepts, being emphasize out its great importance and applicability in the software area. A case study it is carried through on four different applied project standards to the Garbage Collector. This paper is divided of the following form: in section 1, the basic concepts on Patterns and Design Patterns with emphasis in the solutions of project for software are introduced; in section 2 the Garbage Collector is described, in whose solution the use of standards can be applied; in section 3 the four standards used in the solution are described on the proposal solution: adapter, facade, iterator and proxy and; in the fourth and last section is described an a proposal of standards application on the solution of the described problem in section 2. Resumo. Este artigo tem como objetivo conceituar padrões de projetos, ressaltando sua grande importância e aplicabilidade na área de software. É realizado, também, um estudo de caso sobre quatro diferentes padrões de projeto aplicados ao Garbage Collector. O trabalho está dividido da seguinte forma: na seção 1, são introduzidos os conceitos básicos sobre Patterns e Design Patterns com ênfase nas soluções de projeto para software; na seção 2 é descrito o Garbage Collector, em cuja solução pode-se aplicar o uso de padrões; na seção 3 são descritos os quatro padrões utilizados na solução proposta: adapter, facade, iterator e proxy e; na quarta e última seção é descrita uma proposta de aplicação de padrões na solução do problema descrito na seção Introdução O uso atual do termo padrão é derivado das escritas do arquiteto Christopher Alexander que escreveu vários livros com tópicos relacionados à construção, planejamento e arquitetura urbana. Em qualquer ciência ou engenharia é fundamental o uso de um vocabulário comum para expressar seus conceitos, e uma linguagem para relacioná-los. O objetivo do uso de padrões dentro da comunidade de software é criar um conjunto de literatura para ajudar o desenvolvedor de software a solucionar problemas encontrados

2 periodicamente ao longo de todo o desenvolvimento do software. Os padrões ajudam a criar uma linguagem compartilhada para comunicar experiências sobre estes problemas e suas soluções. A classificação formal destas soluções e suas relações nos permitem capturar o conjunto de conhecimentos que define nossa compreensão das melhores arquiteturas que satisfazem as necessidades dos usuários. O enfoque primário dos padrões não está tanto na tecnologia e sim em criar uma cultura para documentar e apoiar engenharia de arquiteturas e projetos. Cada pattern descreve em uma forma literária um problema que ocorre várias vezes no nosso ambiente e então descreve o núcleo da solução deste problema, de tal forma que podemos utilizar esta solução inúmeras vezes, gerando resultados diferentes a cada vez [Alexander 1977]. Tal linguagem de patterns permite a qualidade, que não pode ser fabricada, mas apenas gerada, indiretamente, pelas ações das pessoas. James Coplien [Coplien 1996] descreveu as seguintes considerações sobre a definição de pattern, referindo-se várias vezes às definições originais de Alexander [Alexander et.al. 1979, p.247]: Um pattern é uma peça de literatura que descreve um problema de desenho e uma solução geral para o problema em um contexto particular. Alexander define: cada pattern é uma regra com três partes, que expressam a relação entre um certo contexto, um problema e uma solução [Alexander 1979]. Um pattern, em resumo, é ao mesmo tempo uma coisa, que acontece no mundo, e a regra que nos diz como criar esta coisa, e quando devemos cria-la. Ele é tanto o processo como a coisa; tanto a descrição de uma coisa que está viva, e a descrição do processo que gera esta coisa. Em [Appleton 1999] Dirk Riehle e Heinz Zullighoven dão uma definição do termo pattern que é amplamente utilizada: Um pattern é a abstração de uma forma concreta que continua ocorrendo periodicamente em contextos não abstratos específicos. Ainda em [Appleton 1999] Richard Gabriel define de forma clara e concisa o termo pattern: Cada pattern é uma regra de três partes que expressa uma relação entre um certo contexto, um certo sistema de forças que acontecem repetidamente naquele contexto, e uma certa configuração de software que permite solucionálos. O uso de patterns permite o reuso de software que em geral tem sido um objetivo primordial em engenharia de software. A própria utilização do termo reuso (ou reutilização) é uma demonstração do quanto reuso é essencial e também do quanto ele não está sendo atingido. Para atingir este objetivo, uma engenharia utiliza conhecimentos científicos sobre domínios tecnológicos que estão codificados de uma forma que seja diretamente útil para um engenheiro. Deste modo este conhecimento codificado provê respostas para questões que ocorrem comumente na prática. Ou seja, este conhecimento deve ser reutilizado para a geração de soluções.

3 1.1 Design Patterns O termo Projeto de Padrões ou Design Patterns, é um mecanismo novo para expressar estruturas de projeto. Preservam informações de projeto abstraindo o que há por trás de um projeto. Eles identificam classes, instâncias, os papéis dos projetos, colaborações e a distribuição de responsabilidades. Design Patterns têm muita utilidade no processo de desenvolvimento de projetos orientados a objeto [Appleton 1999]: provêem um vocabulário comum para projetistas se comunicarem, documentarem, e explorarem alternativas de projeto. Eles reduzem complexidade de sistema nomeando e definindo abstrações que estão sobre classes e instâncias. Um bom conjunto de Design Patterns, com certeza eleva o nível de qualquer programa; constituem uma base reutilizável de experiência para construção de software reutilizável. Eles dispõem de meios para usar o conhecimento adquirido por projetistas mais experientes, agem como pequenos blocos de projeto que juntos constróem projetos mais complexos; eles são micro-arquiteturas que contribuem para a construção de uma arquitetura de sistema global; ajudam a reduzir o tempo de aprendizagem para uma biblioteca de classe. Uma vez que se tenha aprendido sobre um Design Pattern em uma biblioteca, o projetista pode reusar esta experiência quando aprender sobre uma nova classe; ajudam o projetista inexperiente a desenvolver como um projetista experiente; provêem um objetivo para a reorganização ou remanufatura de hierarquias de classe. 1.1 Categoria de Design Patterns Design Patterns variam na sua granularidade e no seu nível de abstração. Eles são numerosos e têm propriedades comuns. Existem muitos padrões de projeto, por isso precisamos de um modo para organizá-los. Na tabela 1 abaixo é demonstrado um sistema de classificação para padrões de projeto. Tabela 1. Organização dos Padrões de Projeto Escopo Criação Estrutura Comportamento Classe Factory Method Adapter (classe) Interpreter Template Method Objeto Fonte: [Gamma 1994] Abstract Factory Builder Prototype Singleton Adapter (objeto) Bridge Composite Decorator Facade Flyweight Proxy Chain of Responsibility Command Iterator Mediator Memento Observer State Strategy Visitor 2. Estudo de Caso Garbage Collection é a recuperação automática de recursos, normalmente na memória principal, usando o nível de linguagem. Garbage Collectors (Coletores de Lixo) são escritos tradicionalmente em assembler, tornando-os difíceis de otimizar, difíceis de

4 portar ou reusar entre sistemas operacionais ou outras linguagens. O problema é como reusar Garbage Collectors e seus diferentes algoritmos. Vários algoritmos foram desenvolvidos desde os anos 70. Muitos dos quais, algoritmos de localização; isto é, eles localizam ponteiros entre objetos na pilha a fim de encontrar os que não mais são utilizados pela aplicação. Uma alternativa para a implementação disto, é assegurar o uso de Design Patterns para a família de algoritmos dos Garbage Collectors. O algoritmo Mark-and-Sweep (Varredura) é o algoritmo original de localização. Algoritmos incrementais dividem a coleta através de muitos incrementos pequenos, a fim de evitar uma pausa longa, o suficiente para os usuários notarem. Algoritmos de compactação movem objetos na memória para desfragmentá-los. Coletores Semi-Space e Geradores dividem objetos por idade, permitindo o enfoque para os objetos mais novos [Wilson 1992]. Alguns Coletores foram examinados como um passo na aquisição de domínio de conhecimento. Este artigo consiste em utilizar Design Patterns [Gamma 1994] como ferramenta para capturar este domínio de conhecimento pertinente. Os padrões utilizados para tal tarefa são o Adapter, Facade, Iterator e o Proxy; cada qual com sua utilização específica em Garbage Collectors. 3. Design Patterns Abordados O objetivo deste padrão é permitir que interfaces incompatíveis se comuniquem. Este padrão também é conhecido como Wrapper e, convertendo a interface de uma classe, pode torná-la reutilizável fazendo com que esta corresponda à interface requerida por uma aplicação. 3.1 Padrão Adapter - Estrutural de classes e de objetos O uso do Adapter é recomendado quando se deseja usar uma classe já pronta, cuja interface não é a desejada. Quando desejado usar várias subclasses cujas interfaces não correspondem a desejada, neste caso pode-se aplicá-lo para adaptar a interface da classe mãe ou ainda para se criar uma classe reutilizável que coopera com classes cujas interfaces podem não ser compatíveis. 3.2 Padrão Facade - Estrutural de objetos O Facade torna o uso de um subsistema mais fácil, oferecendo uma interface unificada, de nível mais alto, para o conjunto de interfaces do mesmo. Uma das possíveis alternativas a se seguir quando se deseja reduzir a complexidade de um sistema é estruturá-lo em subsistemas. O padrão Facade é utilizado exatamente para tornar menor a comunicação e a dependência entre sistemas, que é um dos objetivos de um projeto. Pode-se identificar algumas situações nas quais o uso do padrão Facade se torna interessante. Uma delas é quando se deseja obter uma visão simples de um subsistema complexo. A complexidade tende a aparecer nos subsistemas à medida que os mesmos evoluem. Entretanto, é comum que muitos detalhes envolvidos nesta complexidade não interessem a muitos clientes do sistema. Neste sentido, o uso de uma fachada (Facade)

5 pode omitir detalhes (que podem ser vistos pelos clientes que necessitem de uma maior customização) fornecendo uma visão simples do sistema. Outra aplicação interessante do Facade é sua utilização entre camadas de subsistemas definindo o ponto de entrada dos níveis. Se os subsistemas forem independentes, pode-se estabelecer esta comunicação através de fachadas. Pode-se lembrar ainda uma outra situação na qual o uso de fachada (Facade) seria recomendável. Este padrão pode ser usado para favorecer a independência e a portabilidade entre sistemas quando for preciso desacoplar o subsistema dos clientes e dos outros subsistemas, nos casos em que houver muita dependência entre clientes e classes de implementação de uma abstração. Em relação às colaborações, é importante lembrar que a fachada fica entre o subsistema e o cliente, de forma que as solicitações advindas do cliente passam pela fachada que as repassa para os objetos do sistema. Assim, os objetos do subsistema não são acessados diretamente pelos clientes, e freqüentemente a fachada tem o papel de traduzir a interface destes objetos para as interfaces de subsistemas. 3.3 Iterator Pattern - Comportamental de objetos Também chamado de cursor, este padrão procura possibilitar uma forma de acesso seqüencial aos elementos de um objeto sem expor sua representação interna. O padrão Iterator permite percorrer um objeto agregado, como uma lista, de diferentes formas sem que seja necessário acrescentar à interface da lista as operações pertinentes a cada percurso diferente. Um objeto Iterator permite transferir a responsabilidade de acesso e percurso do objeto lista chamando-a para si. Ao percorrer uma lista, pode-se deixar a cargo de um objeto Iterator o controle de quais elementos já foram percorridos, isto é, identificar em que ponto da lista encontra-se o acesso. 3.4 Proxy Pattern - Estrutural de Objetos Este padrão também é conhecido como surrogate. Ele fornece um marcador de localização para controlar o acesso a um objeto. A criação e inicialização de um ou vários objetos num determinado momento pode custar um tempo significativo. Assim, visando não comprometer o desempenho geral da aplicação pode-se adiar o custo integral de criação e inicialização de um objeto até o instante em que isto seja imprescindível. Desta forma, a idéia é criar objetos caros sob demanda, quando realmente necessitamos usá-los. Para isto, utiliza-se um Proxy que funciona como um substituto temporário do objeto real. O Proxy assume a instanciação do objeto real quando for necessário. O padrão Proxy aplica-se quando se faz necessária uma referência a um objeto mais versátil, ou sofisticada, do que um simples apontador. Algumas situações onde se pode aplicá-lo são: quando um Virtual Proxy cria objetos caros sob demanda; quando um representante local para um objeto é fornecido por um Remote Proxy num espaço de endereçamento diferente; quando um Protection Proxy controla o acesso para o objeto original.

6 4. Aplicação dos Padrões: Adapters e Facades Adapters e Facades são comuns em Garbage Collection, e em muitas situações a distinção entre eles não é clara. Funcionalmente, Adapters e Facades provêem tipos de flexibilidade no mesmo ponto, a interface entre a aplicação e o Garbage Collector. Adapters permitem aos subsistemas mudarem a sintaxe de suas interfaces independentemente, enquanto Facades permitem aos subsistemas mudarem as suas decomposições internas independentemente. A diferença chave entre um Facade e um Adapter é que o Facade provê uma única interface integrada, pela qual um subsistema inteiro ou grupos de objetos podem ser acessados, enquanto um Adapter provê uma interface alterada para um único objeto para habilitá-lo a executar em um contexto para qual não foi originalmente projetado. 4.1 Adapters Adapters são comuns em gerenciamento de memória. Através de um Adapter, alguns coletores originalmente escritos em linguagem C, podem ser habilitados para serem usados em C++. A maioria dos sistemas operacionais provê um único método de alocar memória empilhada, enquanto linguagens como C provêem uma grande quantidade de chamadas em bibliotecas que alocam memória, cada uma com uma semântica ligeiramente diferente, o que faz os Adapters serem muito úteis. Linguagens como C++, Oberon e Java têm um operador New, com sintaxe divergente, que aloca memória para um objeto. Usando um Adapter um único Garbage Collector pode ser adaptado para aceitar cada linguagem. Intenção: Adaptar a interface entre o Garbage Collector e os componentes de sistemas externos. Motivação: Diferentes linguagens de implementação exigem interfaces ligeiramente diferentes para serviços fornecidos por Garbage Collectors. Solução: Colocar um objeto Adapter entre o coletor e o sistema externo para mediar as suas interações. Aplicabilidade: Seja onde for, o Garbage Collector pode ser usado com várias versões de um sistema, ou vários sistemas, ao qual vão precisar de pequenas diferenças na interface. Estrutura: Aplicação new() Adapter Collector malloc( ) Figura 1. Estrutura do Adapter e Collector Participantes: Aplicação - usa os serviços de Collector; a sintaxe das interações com Collector pode variar. Collector - oferece serviços de gerenciamento de memória para Aplicação. Pode ser usado com um variedade de Aplicações, ou várias

7 versões da mesma Aplicação, cada qual com uma diferente interação de sintaxe. Adapter - faz a mediação de todas as interações entre um Collector e uma Aplicação. Colaborações: o seguinte diagrama de interação mostra um Adapter que faz a mediação entre uma aplicação em C++ e um Collector em C. Aplicação Adapter Collector new(blarg malloc (sizeof(blarg) ) Figura 2. Diagrama de interação entre Adapter e Collector Conseqüências: como todas as interações entre o Garbage Collector e o sistema externo é mediado pelo adaptador, a sintaxe de Garbage Collector ou sistema pode mudar com uma mudança externa, que é limitada ao adaptador. Implementação: geralmente o Adapter é implementado como uma capa ao redor do Garbage Collector. 4.2 Facade Facades são usados para capturar a interface de um sistema (ou subsistema), simplificar a visão exterior do sistema e ocultar mudanças internas do sistema de seus usuários. Além disso, Facades protegem os subsistemas internos de consultas e manipulações indesejadas feitas pelos usuários. Esta combinação lhes permite proporcionar encapsulamento ao nível de pacote, semelhante ao que é fornecido ao nível de objeto pela maioria das linguagens de programação orientada a objetos. Em Garbage Collector, Facade é usado, principalmente, entre o subsistema do Garbage Collector e a aplicação do cliente para encapsulamento, conservando o namespace e favorecendo a queda de Garbage Collectors em projetos de sistemas que utilizarão gerenciamento de memórias tradicionais. Intenção: Fornecer uma interface integrada entre o Garbage Collector e componentes externos do sistema.

8 Motivação: Componentes externos do sistema requerem uma interface estável, imutável e claramente definida, para uma complexa evolução do sistema. Solução: Converter a especificação da interface do Garbage Collector; esconder completamente os detalhes da linguagem do Garbage Collector, e vice-versa. Aplicabilidade: Garbage Collectors que normalmente mudam sua estrutura interna ou sua organização durante sua vida e links externos para objetos dentro desta estrutura, imporiam limitações inaceitáveis na liberdade do projeto. Estrutura: Limites do Subsistema Garbage Collector Aplicação Facade new() sizeof() Algoritmo new() Proxy sizeof() Participantes: Figura 3. Limites do subsistema Garbage Collector Aplicação - utiliza os serviços do Garbage Collector; exige uma interface limpa e simples para o complexo subsistema do Garbage Collector; interage com o Facade como se o subsistema do Garbage Collector fosse um único objeto. Facade - fornece uma interface limpa e simples para o complexo subsistema do Garbage Collector; está ciente de alguns ou de todos os objetos internos dentro do subsistema Garbage Collector; encaminha chamadas a métodos da Aplicação para os objetos internos dentro do subsistema Garbage Collector. Algoritmo e Proxy - objetos dentro do subsistema Garbage Collector. Colaborações: o seguinte diagrama de interação mostra duas chamadas de método a um Facade que está sendo enviado a outros objetos. O primeira chamada do método, sizeof(), é despachado ao Proxy apropriado, baseado no argumento Object. A segunda chamada de método, new(), é despachado sempre ao mesmo objeto, Algoritmo. Conseqüências: A interface do Garbage Collector é reduzida a um único objeto. Implementação: Como sugerida em [Gamma 1994], a aplicação pode ser, mais adiante, desacoplada do coletor, fazendo do Facade uma classe abstrata.

9 Aplicação Facade Algoritmo Proxy sizeof(object) sizeof() new(size) new(size) Figura 4. Diagrama de interação do método Facade 4.3 Padrão Iterator Iterators são objetos que permitem iteração sobre um objeto agregado (um recipiente) sem expor sua estrutura interna. A ação primária de toda a não referência que possui os Garbage Collectors é executada por uma repetição sobre a pilha. Iterators estão no coração do Garbage Collector e um ciclo do Garbage Collector pode ser visto como uma iteração sobre cada objeto na pilha. Dentre os tipos principais de iterações em Garbage Collector, tem-se: iterações sobre origens o conjunto de ponteiros dentro da pilha externa. Normalmente envolve todos os ponteiros encontrados nas estruturas de dados global e no "runtime stacks" e pode ser difícil de incrementar. Isto acontece uma vez ao começo de cada ciclo do Garbage Collector. iterações sobre ponteiros dentro de um objeto (scanning) - estes são usados para encontrar a quais objetos, um objeto particular se refere. Isto acontece uma vez por objeto alcançável na pilha por ciclo do Garbage Collector e a menos que sejam entradas em ação especiais, isto resulta na geração de números vastos de Iterators. Felizmente, o escopo destes Iterators temporários é muito limitado e seu tempo de vida previsível, eles podem ser reinicializados e reusados. Isto elimina toda a necessidade para criar novos Iterators durante um ciclo do Garbage Collector. Intenção: iteração abstrata, iteração sobre origens, objetos pilha ou referências com um objeto. Motivação: há várias implementações possíveis para pilhas de estruturas de dados, cada uma com suas vantagens e desvantagens, sendo que para tirar vantagem

10 disto, são exigidas interfaces standards, que podem ser trocadas uma por outra. O Garbage Collector deve possuir uma interface padrão para estas estruturas de dados. Solução: separar a ordem de passagem, mecanismo e estado do resto do sistema, usando um objeto Iterator que contém o estado da iteração, e por qual são executadas todas as ações na iteração. Aplicabilidade: Onde quer que uma estrutura de dados esteja apta a ser cruzada em múltiplas direções, ou quando a implementação da estrutura de dados pode mudar. Estrutura: Iterator hasmoreitems() nextitem() Aggregate Aggregate() Iterator() additem() removeitem() Participantes: Figura 5. Estrutura do Interator Aggregate - um recipiente ou objeto gerador; responsável pela criação, ou redirecionamento de Iterators. Iterator - mantém uma referência ao Aggregate; devido ao grande número de iterações executadas durante a coleta de lixo, pode ser reusado, em lugar de destruí-lo e recriá-lo novamente. Conseqüências: o objeto Iterator extra aumenta overhead, que poderá possuir muitos métodos para trabalharem na otimização. Implementação: em função do alto número de iterações executadas durante o curso da coleta de lixo, a intenção do Garbage Collector é de não usar objetos temporários (desde que o Garbage Collector seja, provavelmente, invocado quando há pouca ou nenhuma memória para a criação deles) e reusar objetos Iterator. Permitindo ser redirecionados para iterar sobre um outro objeto. Um único Iterator por cliente pode ser usado. 4.4 Padrão Proxy Proxies são usados em Garbage Collectors de três maneiras: (i) Para controlar acesso ao objeto que eles guardam. Eles são usados para implementar read-and-write-barriers (barreiras de leitura e escrita) na ausência de memória virtual; (ii) Para ocultar o movimento, a verdadeira localização, ou mudanças no conteúdo ou localização do objeto que eles guardam. Eles podem ser usados para ocultar da aplicação, movimentos da pilha de objetos provocados pelo Garbage Collector; (iii) Para conter a informação do objeto sobre o estado do objeto que eles guardam. Eles podem ser usados em Garbage Collection para armazenar o tipo do objeto. Existem implementações alternativas para cada um deles [Goldberg 1991], mas a informação é comumente armazenada dentro de um Proxy.

11 Em Garbage Collection, Proxies são implementados de duas maneiras. A primeira, armazenando os Proxies separadamente do objeto em uma área separada de memória (tais particionamentos de memória podem conduzir aos tamanhos máximos das pilhas que são impostas, mas pode aumentar a área de referência no coletor e pode melhorar o caching). A segunda maneira, armazenando o Proxy com o objeto. Esta segunda técnica é usada por gerenciadores tradicionais de memória para linguagens como C e C++, que comumente armazenam alguns bytes de dados imediatamente antes dos objetos cederem à aplicação [Wilson et al. 1995]. Intenção: Fornece um repositório para o estado e funcionalidade do objeto no Garbage Collection. Motivação : O Garbage Collector necessita: uma área para armazenar dados de objeto; um mecanismo de execução para ler ou escrever barreiras; em um Garbage Collector móvel, um mecanismo para ocultar o movimento do objeto. Solução: usar um objeto Proxy para cada objeto de aplicação. A aplicação invoca métodos do objeto Proxy como se ele fosse o objeto atual, e chamada ao método passada no objeto atual. Estrutura: a seguir é apresentado uma estrutura para o Proxy num Garbage Collector: MemoryObject Aplicação Workspace instance( ) memory( ) getreferences( ) _id _tag _type Collector malloc( ) MutatorNode getleft( ) getright( ) setleft( ) setright( ) Participantes: Figura 6. Estrutura do Proxy para um Garbage Collector Workspace - mantém um vetor de MemoryObjects; mantém uma lista de entradas livres do vetor MemoryObject - classe base para todos os objetos alocados da pilha; repositório para dados de objeto (tipo de dados); mantém um índice (_id) em Workspace. Memory indica qual elemento contém a referência para este objeto.

12 MutatorNode - exemplo de objetos na pilha; duas instâncias acessadas; métodos contendo chamadas ao Collector.writeBarrier(). Collector - representa o restante do coletor; implementa writebarrier, que usa, entre outras coisas, os campos em MutatorNode herdados de MemoryObject. Aplicabilidade: todos Garbage Collectors incrementais e os não incrementais que armazenam dados do objeto. Implementação: tradicionalmente, Proxies são implementados em pacotes de gerenciamento de memória colocando um objeto de alguns bytes entre cada objeto normal da pilha. Estes pequenos objetos são de um tamanho conhecido, e contém dados sobre o objeto seguinte, e poderia ser obtido um ponteiro para estes dados, subtraindose um número fixo de um ponteiro para qualquer objeto da pilha. 5. Conclusão O objetivo do uso de padrões dentro da comunidade de software é criar um conjunto de literatura para ajudar o desenvolvedor de software a solucionar problemas encontrados periodicamente ao longo de todo o desenvolvimento do software. Os padrões ajudam a criar uma linguagem compartilhada para comunicar experiências sobre estes problemas e suas soluções. A classificação formal destas soluções e suas relações nos permitem capturar o conjunto de conhecimentos que define nossa compreensão das melhores arquiteturas que satisfazem as necessidades dos usuários. Cada pattern descreve em uma forma literária um problema que ocorre várias vezes no nosso ambiente e então descreve o núcleo da solução deste problema, de tal forma que podemos utilizar esta solução inúmeras vezes, gerando resultados diferentes a cada vez. Tal linguagem de patterns permite a qualidade, que não pode ser fabricada, mas apenas gerada, indiretamente, pelas ações das pessoas. O uso de patterns permite o reuso de software que em geral tem sido um objetivo primordial em engenharia de software. Os patterns propiciam reuso de soluções bem sucedidas para problemas que se repetem. Isto significa um aumento na produtividade na fase de design. Para projetos que tenham o tipo de estrutura muito complexo, o uso de patterns é uma solução que simplifica a análise provendo uma representação genérica de hierarquias que solucionam problemas da mesma natureza. Empresas que utilizam a filosofia de Design Patterns para projetar software reduzem a distância existente entre projetistas iniciantes e experientes. A criação e utilização de patterns permite perpetuar as experiências de sucesso, bem como reduzir o tempo e o esforço necessários para criar uma cultura para documentar e apoiar engenharia de arquiteturas e projetos. Em grande parte dos Garbage Collectors encontram-se Design Patterns, sendo que em sua maioria eles são similares. Neste artigo foram demonstrados quatro deles. Fica evidenciado, assim, que Garbage Collector é um bom exemplo da importância da utilização dos Design Patterns no auxílio a projetos orientados a objeto.

13 6. Referências Bibliográficas Alexander, C. (1979) The Timeless Way of Building, Oxford University. Alexander, C. et al. (1977) A Pattern Language, Oxford University. Appleton, Brad. (1999), Patterns and Software: Essential Concepts and Terminology. In: Coplien, J. O. Software Patterns, SIGS Books, Gamma, E., Helm, R., Johnson, R. and Vlissides, J. (1994) Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley. Goldberg, B. (1991). Tag-Free Garbage Collection for Strongly Typed Programming Languages. Pages of: Proceedings of ACM SIGPLAN '91 Conference on Programming Language Design and Implementation. Wilson, P. R. (1992). Uniprocessor Garbage Collection Techniques. Pages 1-42 of: Bekkers, Y., & Cohen, J. (eds), Proceedings of the 1992 International Workshop of Memory Management. Lecture Notes in Computer Science, no Springer. Wilson, P., Johnstone, M., Neely, M., & Boles, D. (1995). Dynamic Storage Allocation: ASurvey and Critical Review. In: (Baker, 1995).

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

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

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

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

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

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

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

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

Conteúdo. Disciplina: INF 02810 Engenharia de Software. Monalessa Perini Barcellos. Centro Tecnológico. Universidade Federal do Espírito Santo

Conteúdo. Disciplina: INF 02810 Engenharia de Software. Monalessa Perini Barcellos. Centro Tecnológico. Universidade Federal do Espírito Santo Universidade Federal do Espírito Santo Centro Tecnológico Departamento de Informática Disciplina: INF 02810 Prof.: (monalessa@inf.ufes.br) Conteúdo 1. Introdução 2. Processo de Software 3. Gerência de

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 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

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

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

Orientação a Objetos

Orientação a Objetos 1. Domínio e Aplicação Orientação a Objetos Um domínio é composto pelas entidades, informações e processos relacionados a um determinado contexto. Uma aplicação pode ser desenvolvida para automatizar ou

Leia mais

Projeto de Arquitetura

Projeto de Arquitetura Introdução Projeto de Arquitetura (Cap 11 - Sommerville) UNIVERSIDADE FEDERAL DE ALAGOAS Curso de Ciência da Computação Engenharia de Software I Prof. Rômulo Nunes de Oliveira Até agora, estudamos: Os

Leia mais

Banco de Dados Aula 1 Introdução a Banco de Dados Introdução Sistema Gerenciador de Banco de Dados

Banco de Dados Aula 1 Introdução a Banco de Dados Introdução Sistema Gerenciador de Banco de Dados Banco de Dados Aula 1 Introdução a Banco de Dados Introdução Um Sistema Gerenciador de Banco de Dados (SGBD) é constituído por um conjunto de dados associados a um conjunto de programas para acesso a esses

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

Design Pattern Implementation in Java and AspectJ

Design Pattern Implementation in Java and AspectJ Design Pattern Implementation in Java and AspectJ Jan Hannemann Gregor Kiczales In Proceedings of 2002 ACM SIGPLAN conference on OOPSLA. NY, USA. Introdução 2 Introdução 3 Introdução 4 Introdução 5 Introdução

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

Organização e Arquitetura de Computadores I. de Computadores

Organização e Arquitetura de Computadores I. de Computadores Universidade Federal de Campina Grande Unidade Acadêmica de Sistemas e Computação Curso de Bacharelado em Ciência da Computação Organização e Arquitetura de Computadores I Organização Básica B de Computadores

Leia mais

Algoritmos e Programação (Prática) Profa. Andreza Leite andreza.leite@univasf.edu.br

Algoritmos e Programação (Prática) Profa. Andreza Leite andreza.leite@univasf.edu.br (Prática) Profa. Andreza Leite andreza.leite@univasf.edu.br Introdução O computador como ferramenta indispensável: Faz parte das nossas vidas; Por si só não faz nada de útil; Grande capacidade de resolução

Leia mais

Engenharia de Software III

Engenharia de Software III Engenharia de Software III Casos de uso http://dl.dropbox.com/u/3025380/es3/aula6.pdf (flavio.ceci@unisul.br) 09/09/2010 O que são casos de uso? Um caso de uso procura documentar as ações necessárias,

Leia mais

Engenharia de Requisitos

Engenharia de Requisitos Engenharia de Requisitos Introdução a Engenharia de Requisitos Professor: Ricardo Argenton Ramos Aula 08 Slide 1 Objetivos Introduzir a noção de requisitos do sistema e o processo da engenharia de requisitos.

Leia mais

Requisitos de Software

Requisitos de Software Requisitos de Software Centro de Informática - Universidade Federal de Pernambuco Kiev Gama kiev@cin.ufpe.br Slides originais elaborados por Ian Sommerville e adaptado pelos professores Márcio Cornélio,

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

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

Universidade Federal de Santa Maria Curso de Arquivologia. Disciplina de Banco de Dados Aplicados à Arquivística. Versao 1.

Universidade Federal de Santa Maria Curso de Arquivologia. Disciplina de Banco de Dados Aplicados à Arquivística. Versao 1. Universidade Federal de Santa Maria Curso de Arquivologia Disciplina de Banco de Dados Aplicados à Arquivística Prof. Andre Zanki Cordenonsi Versao 1.0 Março de 2008 Tópicos Abordados Conceitos sobre Banco

Leia mais

Wilson Moraes Góes. Novatec

Wilson Moraes Góes. Novatec Wilson Moraes Góes Novatec Copyright 2014 Novatec Editora Ltda. Todos os direitos reservados e protegidos pela Lei 9.610 de 19/02/1998. É proibida a reprodução desta obra, mesmo parcial, por qualquer processo,

Leia mais

Tópicos em Engenharia de Software (Optativa III) AULA 2. Prof. Andrêza Leite andreza.lba@gmail.com (81 )9801-6619

Tópicos em Engenharia de Software (Optativa III) AULA 2. Prof. Andrêza Leite andreza.lba@gmail.com (81 )9801-6619 Tópicos em Engenharia de Software (Optativa III) AULA 2 Prof. Andrêza Leite andreza.lba@gmail.com (81 )9801-6619 Engenharia de Software Objetivo da aula Depois desta aula você terá uma revisão sobre o

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

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

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

Modelos de Sistema. 2007 by Pearson Education. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 8 Slide 1.

Modelos de Sistema. 2007 by Pearson Education. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 8 Slide 1. Modelos de Sistema Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 8 Slide 1 Objetivos Explicar por que o contexto de um sistema deve ser modelado como parte do processo de RE Descrever

Leia mais

Desenvolvimento de Sistemas Orientados a Objetos com UML UP/RUP: Projeto

Desenvolvimento de Sistemas Orientados a Objetos com UML UP/RUP: Projeto Desenvolvimento de Sistemas Orientados a Objetos com UML UP/RUP: Projeto Engenharia de Software I Informática 2009 Profa. Dra. Itana Gimenes RUP: Artefatos de projeto Modelo de Projeto: Use-Case Realization-projeto

Leia mais

SISTEMA TYR DIAGRAMAS DE CLASSE E SEQUÊNCIA Empresa: Academia Universitária

SISTEMA TYR DIAGRAMAS DE CLASSE E SEQUÊNCIA Empresa: Academia Universitária SISTEMA TYR DIAGRAMAS DE CLASSE E SEQUÊNCIA Empresa: Academia Universitária Cascavel Novembro de 2009 Pedro Patitucci Finamore Daniel Bordignon Cassanelli Marco Antonio da Rosa DIAGRAMAS DE CLASSE E SEQUÊNCIA

Leia mais

Padrões de Projeto WEB e o MVC

Padrões de Projeto WEB e o MVC Padrões de Projeto WEB e o MVC Padrões de Projeto WEB e o MVC O que são padrões? "Cada padrão descreve um problema que ocorre freqüentemente em seu ambiente, e então descreve o cerne da solução para aquele

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

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

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

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

Banco de Dados I. Apresentação (mini-currículo) Conceitos. Disciplina Banco de Dados. Cont... Cont... Edson Thizon (edson@esucri.com.

Banco de Dados I. Apresentação (mini-currículo) Conceitos. Disciplina Banco de Dados. Cont... Cont... Edson Thizon (edson@esucri.com. Sistemas da Informação Banco de Dados I Edson Thizon (edson@esucri.com.br) 2008 Apresentação (mini-currículo) Formação Acadêmica Mestrando em Ciência da Computação (UFSC/ ) Créditos Concluídos. Bacharel

Leia mais

Universidade Paulista

Universidade Paulista Universidade Paulista Ciência da Computação Sistemas de Informação Gestão da Qualidade Principais pontos da NBR ISO/IEC 12207 - Tecnologia da Informação Processos de ciclo de vida de software Sergio Petersen

Leia mais

Programação Estruturada e Orientada a Objetos. Fundamentos Orientação a Objetos

Programação Estruturada e Orientada a Objetos. Fundamentos Orientação a Objetos Programação Estruturada e Orientada a Objetos Fundamentos Orientação a Objetos 2013 O que veremos hoje? Introdução aos fundamentos de Orientação a Objetos Transparências baseadas no material do Prof. Jailton

Leia mais

Requisitos de Software

Requisitos de Software Requisitos de Software Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 6 Slide 1 Objetivos Apresentar os conceitos de requisitos de usuário e de sistema Descrever requisitos funcionais

Leia mais

Entendendo como funciona o NAT

Entendendo como funciona o NAT Entendendo como funciona o NAT Vamos inicialmente entender exatamente qual a função do NAT e em que situações ele é indicado. O NAT surgiu como uma alternativa real para o problema de falta de endereços

Leia mais

Governança de TI. ITIL v.2&3. parte 1

Governança de TI. ITIL v.2&3. parte 1 Governança de TI ITIL v.2&3 parte 1 Prof. Luís Fernando Garcia LUIS@GARCIA.PRO.BR ITIL 1 1 ITIL Gerenciamento de Serviços 2 2 Gerenciamento de Serviços Gerenciamento de Serviços 3 3 Gerenciamento de Serviços

Leia mais

Na medida em que se cria um produto, o sistema de software, que será usado e mantido, nos aproximamos da engenharia.

Na medida em que se cria um produto, o sistema de software, que será usado e mantido, nos aproximamos da engenharia. 1 Introdução aos Sistemas de Informação 2002 Aula 4 - Desenvolvimento de software e seus paradigmas Paradigmas de Desenvolvimento de Software Pode-se considerar 3 tipos de paradigmas que norteiam a atividade

Leia mais

Forneça a próxima onda de inovações empresariais com o Open Network Environment

Forneça a próxima onda de inovações empresariais com o Open Network Environment Visão geral da solução Forneça a próxima onda de inovações empresariais com o Open Network Environment Visão geral À medida que tecnologias como nuvem, mobilidade, mídias sociais e vídeo assumem papéis

Leia mais

Para construção dos modelos físicos, será estudado o modelo Relacional como originalmente proposto por Codd.

Para construção dos modelos físicos, será estudado o modelo Relacional como originalmente proposto por Codd. Apresentação Este curso tem como objetivo, oferecer uma noção geral sobre a construção de sistemas de banco de dados. Para isto, é necessário estudar modelos para a construção de projetos lógicos de bancos

Leia mais

Modelagem de Processos. Prof.: Fernando Ascani

Modelagem de Processos. Prof.: Fernando Ascani Modelagem de Processos Prof.: Fernando Ascani Modelagem da arquitetura de negócios Arquitetura Definições Aurélio: Informática: Estrutura e organização lógica de funcionamento de um sistema computacional.

Leia mais

Hardware (Nível 0) Organização. Interface de Máquina (IM) Interface Interna de Microprogramação (IIMP)

Hardware (Nível 0) Organização. Interface de Máquina (IM) Interface Interna de Microprogramação (IIMP) Hardware (Nível 0) Organização O AS/400 isola os usuários das características do hardware através de uma arquitetura de camadas. Vários modelos da família AS/400 de computadores de médio porte estão disponíveis,

Leia mais

Análise e Desenvolvimento de Sistemas ADS Programação Orientada a Obejeto POO 3º Semestre AULA 03 - INTRODUÇÃO À PROGRAMAÇÃO ORIENTADA A OBJETO (POO)

Análise e Desenvolvimento de Sistemas ADS Programação Orientada a Obejeto POO 3º Semestre AULA 03 - INTRODUÇÃO À PROGRAMAÇÃO ORIENTADA A OBJETO (POO) Análise e Desenvolvimento de Sistemas ADS Programação Orientada a Obejeto POO 3º Semestre AULA 03 - INTRODUÇÃO À PROGRAMAÇÃO ORIENTADA A OBJETO (POO) Parte: 1 Prof. Cristóvão Cunha Objetivos de aprendizagem

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

INTRODUÇÃO ÀS LINGUAGENS DE PROGRAMAÇÃO

INTRODUÇÃO ÀS LINGUAGENS DE PROGRAMAÇÃO Capítulo 1 INTRODUÇÃO ÀS LINGUAGENS DE PROGRAMAÇÃO 1.1 Histórico de Linguagens de Programação Para um computador executar uma dada tarefa é necessário que se informe a ele, de uma maneira clara, como ele

Leia mais

PROCESSO DE DESENVOLVIMENTO DE SOFTWARE. Modelos de Processo de Desenvolvimento de Software

PROCESSO DE DESENVOLVIMENTO DE SOFTWARE. Modelos de Processo de Desenvolvimento de Software PROCESSO DE DESENVOLVIMENTO DE SOFTWARE Introdução Modelos de Processo de Desenvolvimento de Software Os modelos de processos de desenvolvimento de software surgiram pela necessidade de dar resposta às

Leia mais

Requisitos de Software. Teresa Maciel DEINFO/UFRPE

Requisitos de Software. Teresa Maciel DEINFO/UFRPE Requisitos de Software Teresa Maciel DEINFO/UFRPE 1 Requisito de Software Características que o produto de software deverá apresentar para atender às necessidades e expectativas do cliente. 2 Requisito

Leia mais

UFG - Instituto de Informática

UFG - Instituto de Informática UFG - Instituto de Informática Curso: Sistemas de Informação Arquitetura de Software Prof.: Fabrízzio A A M N Soares professor.fabrizzio@gmail.com Aula 3 Introdução à Arquitetura de Software (continuação)

Leia mais

Decorator Pattern. SISMO - Sistemas e Mobilidade http://www.sismo.deinf.ufma.br. Junho de 2008. Departamento de Informática / UFMA

Decorator Pattern. SISMO - Sistemas e Mobilidade http://www.sismo.deinf.ufma.br. Junho de 2008. Departamento de Informática / UFMA Decorator Pattern SISMO - Sistemas e Mobilidade http://www.sismo.deinf.ufma.br Departamento de Informática / UFMA Junho de 2008 Revisando os conceitos Herança é poderosa mas não é flexível Comportamento

Leia mais

Arquitecturas de Software Licenciatura em Engenharia Informática e de Computadores

Arquitecturas de Software Licenciatura em Engenharia Informática e de Computadores UNIVERSIDADE TÉCNICA DE LISBOA INSTITUTO SUPERIOR TÉCNICO Arquitecturas de Software Licenciatura em Engenharia Informática e de Computadores Primeiro Teste 21 de Outubro de 2006, 9:00H 10:30H Nome: Número:

Leia mais

Prof. Marcos Ribeiro Quinet de Andrade Universidade Federal Fluminense - UFF Pólo Universitário de Rio das Ostras - PURO

Prof. Marcos Ribeiro Quinet de Andrade Universidade Federal Fluminense - UFF Pólo Universitário de Rio das Ostras - PURO Conceitos básicos e serviços do Sistema Operacional Prof. Marcos Ribeiro Quinet de Andrade Universidade Federal Fluminense - UFF Pólo Universitário de Rio das Ostras - PURO Tipos de serviço do S.O. O S.O.

Leia mais

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

UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 14 PROFª BRUNO CALEGARO UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 14 PROFª BRUNO CALEGARO Santa Maria, 01 de Novembro de 2013. Revisão aula passada Projeto de Arquitetura Decisões de projeto de Arquitetura

Leia mais

ARCO - Associação Recreativa dos Correios. Sistema para Gerenciamento de Associações Recreativas Plano de Desenvolvimento de Software Versão <1.

ARCO - Associação Recreativa dos Correios. Sistema para Gerenciamento de Associações Recreativas Plano de Desenvolvimento de Software Versão <1. ARCO - Associação Recreativa dos Correios Sistema para Gerenciamento de Associações Recreativas Versão Histórico da Revisão Data Versão Descrição Autor Página

Leia mais

USANDO O IZCODE PARA GERAR SOFTWARE RAPIDAMENTE

USANDO O IZCODE PARA GERAR SOFTWARE RAPIDAMENTE USANDO O IZCODE PARA GERAR SOFTWARE RAPIDAMENTE SUMÁRIO usando o izcode... 1 para gerar software rapidamente... 1 introdução... 2 o que é o izcode?... 2 Como funciona o izcode?... 2 os tipos diferentes

Leia mais

Sistemas Distribuídos Arquitetura de Sistemas Distribuídos I. Prof. MSc. Hugo Souza

Sistemas Distribuídos Arquitetura de Sistemas Distribuídos I. Prof. MSc. Hugo Souza Sistemas Distribuídos Arquitetura de Sistemas Distribuídos I Prof. MSc. Hugo Souza Como já vimos, os sistemas distribuídos são apresentados considerando um planejamento bem mais complexo relacionado aos

Leia mais

Aprenda as melhores práticas para construir um completo sistema de teste automatizado

Aprenda as melhores práticas para construir um completo sistema de teste automatizado Aprenda as melhores práticas para construir um completo sistema de teste automatizado Renan Azevedo Engenheiro de Produto de Teste e Medição -Américas Aprenda as melhores práticas para construir um completo

Leia mais

Análise e Projeto de Sistemas de Informação. Andrêza Leite andreza.lba@gmail.com

Análise e Projeto de Sistemas de Informação. Andrêza Leite andreza.lba@gmail.com Análise e Projeto de Sistemas de Informação Andrêza Leite andreza.lba@gmail.com Roteiro Sistemas de Informação Ciclo de Desenvolvimento de SI Projeto Análise Estruturada Análise Orientada a Objetos Como

Leia mais

Apesar de existirem diversas implementações de MVC, em linhas gerais, o fluxo funciona geralmente da seguinte forma:

Apesar de existirem diversas implementações de MVC, em linhas gerais, o fluxo funciona geralmente da seguinte forma: 1 Introdução A utilização de frameworks como base para a construção de aplicativos tem sido adotada pelos desenvolvedores com três objetivos básicos. Primeiramente para adotar um padrão de projeto que

Leia mais

Software de rede e Modelo OSI André Proto UNESP - São José do Rio Preto andre.proto@sjrp.unesp.br O que será abordado Hierarquias de protocolos (camadas) Questões de projeto relacionadas às camadas Serviços

Leia mais

Sistemas Operacionais

Sistemas Operacionais Sistemas Operacionais Sistemas Operacionais Prof. Marcelo Sabaris Carballo Pinto Gerenciamento de Dispositivos Gerenciamento de Dispositivos de E/S Introdução Gerenciador de Dispositivos Todos os dispositivos

Leia mais

Uma Noção Intuitiva dos Padrões de Desenho de Software

Uma Noção Intuitiva dos Padrões de Desenho de Software 1 1 Uma Noção Intuitiva dos Padrões de Desenho de Software Prof. Dr. Italo S. Vega italo@pucsp.br 5 de dezembro de 2001 São Paulo, SP 2 Agenda Motivação (5 min.) Padrões (20 min.) Exemplo (10 min.) Conclusões

Leia mais

Sistemas Distribuídos. Professora: Ana Paula Couto DCC 064

Sistemas Distribuídos. Professora: Ana Paula Couto DCC 064 Sistemas Distribuídos Professora: Ana Paula Couto DCC 064 Processos- Clientes, Servidores, Migração Capítulo 3 Agenda Clientes Interfaces de usuário em rede Sistema X Window Software do lado cliente para

Leia mais

Aspectos técnicos do desenvolvimento baseado em componentes

Aspectos técnicos do desenvolvimento baseado em componentes Aspectos técnicos do desenvolvimento baseado em componentes Um novo processo de desenvolvimento O uso de componentes traz mudanças no processo de desenvolvimento Além de desenvolver um produto, queremos

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

Arquitetura de Computadores. Sistemas Operacionais IV

Arquitetura de Computadores. Sistemas Operacionais IV Arquitetura de Computadores Sistemas Operacionais IV Introdução Multiprogramação implica em manter-se vários processos na memória. Memória necessita ser alocada de forma eficiente para permitir o máximo

Leia mais

Tópicos Avançados em Engenharia de Software

Tópicos Avançados em Engenharia de Software Faculdade de Ciências e Tecnologia Departamento de Matemática e Computação Programa de Pós-Graduação em Ciência da Computação Tópicos Avançados em Engenharia de Software Padrões e Frameworks (Aula 01-

Leia mais

UFG - Instituto de Informática

UFG - Instituto de Informática UFG - Instituto de Informática Especialização em Desenvolvimento de Aplicações Web com Interfaces Ricas EJB 3.0 Prof.: Fabrízzio A A M N Soares professor.fabrizzio@gmail.com Aula 13 Web Services Web Services

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

DESENVOLVENDO APLICAÇÃO UTILIZANDO JAVA SERVER FACES

DESENVOLVENDO APLICAÇÃO UTILIZANDO JAVA SERVER FACES DESENVOLVENDO APLICAÇÃO UTILIZANDO JAVA SERVER FACES Alexandre Egleilton Araújo, Jaime Willian Dias Universidade Paranaense (Unipar) Paranavaí PR Brasil araujo.ale01@gmail.com, jaime@unipar.br Resumo.

Leia mais

Arquitetura de Rede de Computadores

Arquitetura de Rede de Computadores TCP/IP Roteamento Arquitetura de Rede de Prof. Pedro Neto Aracaju Sergipe - 2011 Ementa da Disciplina 4. Roteamento i. Máscara de Rede ii. Sub-Redes iii. Números Binários e Máscara de Sub-Rede iv. O Roteador

Leia mais

ISO/IEC 12207: Gerência de Configuração

ISO/IEC 12207: Gerência de Configuração ISO/IEC 12207: Gerência de Configuração Durante o processo de desenvolvimento de um software, é produzida uma grande quantidade de itens de informação que podem ser alterados durante o processo Para que

Leia mais

Feature-Driven Development

Feature-Driven Development FDD Feature-Driven Development Descrição dos Processos Requisitos Concepção e Planejamento Mais forma que conteúdo Desenvolver um Modelo Abrangente Construir a Lista de Features Planejar por

Leia mais

Java. Marcio de Carvalho Victorino www.dominandoti.eng.br

Java. Marcio de Carvalho Victorino www.dominandoti.eng.br Java Marcio de Carvalho Victorino www.dominandoti.eng.br 3. Considere as instruções Java abaixo: int cont1 = 3; int cont2 = 2; int cont3 = 1; cont1 += cont3++; cont1 -= --cont2; cont3 = cont2++; Após a

Leia mais

PMONow! Serviço de Implantação de um Escritório de Projetos

PMONow! Serviço de Implantação de um Escritório de Projetos PMONow! Serviço de Implantação de um Escritório de Projetos PMONow! Serviço de Implantação de um Escritório de Projetos As organizações em torno do mundo estão implantando processos e disciplinas formais

Leia mais

Processos de Desenvolvimento de Software

Processos de Desenvolvimento de Software Processos de Desenvolvimento de Software Gerenciamento de Projetos Mauro Lopes Carvalho Silva Professor EBTT DAI Departamento de Informática Campus Monte Castelo Instituto Federal de Educação Ciência e

Leia mais

Desenvolvendo uma Arquitetura de Componentes Orientada a Serviço SCA

Desenvolvendo uma Arquitetura de Componentes Orientada a Serviço SCA Desenvolvendo uma Arquitetura de Componentes Orientada a Serviço SCA RESUMO Ricardo Della Libera Marzochi A introdução ao Service Component Architecture (SCA) diz respeito ao estudo dos principais fundamentos

Leia mais

Notas da Aula 17 - Fundamentos de Sistemas Operacionais

Notas da Aula 17 - Fundamentos de Sistemas Operacionais Notas da Aula 17 - Fundamentos de Sistemas Operacionais 1. Gerenciamento de Memória: Introdução O gerenciamento de memória é provavelmente a tarefa mais complexa de um sistema operacional multiprogramado.

Leia mais

Fatores de Qualidade de Software

Fatores de Qualidade de Software Programação Orientada por Objetos Programação Orientada por Objetos Kecia Aline Marques Ferreira Princípios, objetivos e filosofia 2007 Kecia A. M. Ferreira POO 1 Kecia A. M. Ferreira POO 2 Princípios,

Leia mais

Esta dissertação apresentou duas abordagens para integração entre a linguagem Lua e o Common Language Runtime. O objetivo principal da integração foi

Esta dissertação apresentou duas abordagens para integração entre a linguagem Lua e o Common Language Runtime. O objetivo principal da integração foi 5 Conclusão Esta dissertação apresentou duas abordagens para integração entre a linguagem Lua e o Common Language Runtime. O objetivo principal da integração foi permitir que scripts Lua instanciem e usem

Leia mais

Padrões Arquiteturais e de Integração - Parte 1

Padrões Arquiteturais e de Integração - Parte 1 1 / 58 - Parte 1 Erick Nilsen Pereira de Souza T017 - Arquitetura e Design de Aplicações Análise e Desenvolvimento de Sistemas Universidade de Fortaleza - UNIFOR 11 de fevereiro de 2015 2 / 58 Agenda Tópicos

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

Tabela de Símbolos. Análise Semântica A Tabela de Símbolos. Principais Operações. Estrutura da Tabela de Símbolos. Declarações 11/6/2008

Tabela de Símbolos. Análise Semântica A Tabela de Símbolos. Principais Operações. Estrutura da Tabela de Símbolos. Declarações 11/6/2008 Tabela de Símbolos Análise Semântica A Tabela de Símbolos Fabiano Baldo Após a árvore de derivação, a tabela de símbolos é o principal atributo herdado em um compilador. É possível, mas não necessário,

Leia mais

Arquitetura de Redes: Camadas de Protocolos (Parte I) Prof. Eduardo

Arquitetura de Redes: Camadas de Protocolos (Parte I) Prof. Eduardo Arquitetura de Redes: Camadas de Protocolos (Parte I) Prof. Eduardo Introdução O que é Protocolo? - Para que os pacotes de dados trafeguem de uma origem até um destino, através de uma rede, é importante

Leia mais

Linguagem de Programação I

Linguagem de Programação I Linguagem de Programação I Carlos Eduardo Batista Centro de Informática - UFPB bidu@ci.ufpb.br Complexidade dos sistemas de software Estrutura Decomposição Abstração Hierarquia Projeto de sistemas complexos

Leia mais

Autoria:Aristófanes Corrêa Silva Adaptação: Alexandre César M de Oliveira

Autoria:Aristófanes Corrêa Silva Adaptação: Alexandre César M de Oliveira Unified Modeling Language (UML) Universidade Federal do Maranhão UFMA Pós Graduação de Engenharia de Eletricidade Grupo de Computação Assunto: Introdução Autoria:Aristófanes Corrêa Silva Adaptação: Alexandre

Leia mais

Profº. Enrique Pimentel Leite de Oliveira

Profº. Enrique Pimentel Leite de Oliveira Profº. Enrique Pimentel Leite de Oliveira O termo orientação a objetos significa organizar o mundo real como uma coleção de objetos que incorporam estrutura de dados e um conjunto de operações que manipulam

Leia mais

3.1 Definições Uma classe é a descrição de um tipo de objeto.

3.1 Definições Uma classe é a descrição de um tipo de objeto. 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 Classes Autoria:Aristófanes Corrêa Silva Adaptação:

Leia mais