Reuso da Implementação Orientada a Aspectos do Padrão de Projeto Camada de Persistência
|
|
- Aurélia Graça Carrilho
- 7 Há anos
- Visualizações:
Transcrição
1 Reuso da Implementação Orientada a Aspectos do Padrão de Projeto Camada de Persistência Ricardo Argenton Ramos, 1, Valter Vieira de Camargo, 2 Rosângela Penteado, Paulo Cesar Masiero Universidade Federal de São Carlos - Departamento de Computação Universidade de São Paulo - Instituto de Ciências Matemáticas e de Computação {rar, rosangel}@dc.ufscar.br, {valter, masiero}@icmc.usp.br Abstract This paper relates a reuse experience of the aspect-oriented implementation of the Persistence Layer pattern in an inventory system that was used as case study. This implementation was developed in the AspectJ language in a previous work, aiming to separate the functional code from persistency code. The case study system is implemented in the object-oriented paradigm, in Java, and uses the Persistence Layer pattern. To reuse the aspect-oriented implementation was necessary to identify and to remove the objectoriented code of the pattern, what was done by means of regular expressions. It was noticed that the aspect-oriented reuse process is simpler than the object-oriented and benefits are perceived in the target system. Keywords: Aspect-Oriented Reuse, Design Patterns, Persistence Layer. Resumo Este artigo relata uma experiência de reuso da implementação orientada a aspectos do padrão Camada de Persistência em um sistema de controle de estoque utilizado como estudo de caso. Essa implementação foi desenvolvida, anteriormente, na linguagem AspectJ com o objetivo de separar o código funcional do código de persistência. O sistema utilizado como estudo de caso está implementado no paradigma orientado a objetos, com Java, e possui o padrão Camada de Persistência. Para que a implementação orientada a aspectos do padrão pudesse ser reusada foi necessário identificar e retirar o código orientado a objetos do padrão, o que foi feito por meio de expressões regulares. Observouse que o processo de reuso orientado a aspectos é mais simples do que o orientado a objetos e benefícios são notados no sistema resultante. Palavras chave: Reuso Orientado a Aspectos, Padrão de Projeto, Camada de Persistência. 1 Apoio Financeiro do CNPq 2 Apoio Financeiro da CAPES
2 1. Introdução Padrões de Projeto são soluções de projeto já testadas e aprovadas. O reuso dessas soluções implica em softwares mais manuteníveis e de mais fácil desenvolvimento [5]. Porém, alguns autores comentam que embora o projeto desses padrões possa ser reutilizado facilmente, o mesmo não ocorre com a sua implementação, quando ela é Orientada a Objetos (OO) [6][9]. Da mesma forma, a implementação de requisitos não funcionais também causa problemas quando é utilizada uma linguagem OO. Como essas linguagens de programação fornecem mecanismos pouco adequados à implementação de padrões de projeto e de requisitos não-funcionais [9], permitindo que o código do padrão/requisito nãofuncional permaneça espalhado e entrelaçado com os módulos funcionais da aplicação. Assim, têm-se problemas de manutenção, evolução e reuso. Quando ocorre entrelaçamento/espalhamento, uma possível solução é utilizar a programação orientada a aspectos (POA). Foi proposta em 1997 por Kiczales [7] e visa fornecer construtores lingüísticos mais adequados para separar os requisitos funcionais dos não-funcionais, do que as linguagens OO. Embora padrões de projeto não sejam considerados como requisitos não-funcionais, sua aplicação muitas vezes faz com que o seu código também se encontre espalhado/entrelaçado pela aplicação, podendo ser caracterizados como passíveis de serem implementados com aspectos. Alguns autores têm utilizado a POA na implementação de padrões de projeto, separando o código do padrão do código funcional [6]. Algumas experiências com o reuso da implementação OO do padrão Camada de Persistência (Persistence Layer) foram realizadas em trabalhos anteriores [1] [3] [4]. Esse padrão encapsula o requisito não-funcional de persistência em algumas classes e interfaces para manter a independência da aplicação. O processo de reuso da implementação OO não apresenta muitas dificuldades, porém o código que implementa o padrão fica espalhado/entrelaçado com o código da aplicação, causando os problemas citados anteriormente. A implementação desse padrão com a linguagem AspectJ foi realizada por estes autores [3], e neste artigo será mostrado o processo de reutilização de sua implementação em um sistema de controle de estoque implementado em Java [4]. Dessa forma, infere-se que há benefícios quando se utiliza o processo de reuso da implementação OA em relação ao OO. Como o estudo de caso aqui apresentado já continha o padrão Camada de Persistência implementado de forma OO, expressões regulares foram utilizadas para identificar e remover o código de persistência [10]. Na Seção 2 encontram-se alguns trabalhos sobre a Programação Orientada a Aspectos e Padrões de Projeto; na Seção 3 é apresentado o projeto baseado em aspectos do padrão Camada de Persistência; na Seção 4 são mostrados os detalhes do processo de reuso realizado e na Seção 5 as considerações finais são apresentadas. 2. Programação Orientada a Aspectos e Padrões de Projeto Segundo Kiczales e outros [7], a programação orientada a aspectos consiste na separação dos interesses de um sistema em unidades modulares e posterior composição (weaving) desses módulos em um sistema completo. Esses interesses podem variar de noções de alto nível, como segurança e qualidade de serviço, a noções de baixo nível, como sincronização 2
3 e manipulação de buffers de memória. Eles podem ser tanto funcionais, como características ou regras de negócio, quanto não-funcionais, como gerenciamento de transação e persistência. Aspect/J é uma extensão da linguagem Java, de propósito geral, orientada a aspectos, em que a principal unidade modular é o aspecto (aspect) [7]. Um aspecto pode possuir atributos e métodos e participar de uma hierarquia de aspectos por meio da definição de aspectos especializados. Aspect/J possibilita nomear um conjunto de pontos de junção e associar uma determinada implementação a eles, que pode ser executada antes, após ou apropriar-se do fluxo de execução dos eventos relacionados a esses pontos. Os seguintes conceitos são usados em AspectJ: Pontos de junção (joinpoints): são métodos bem definidos na execução do fluxo do programa que compõem pontos de corte. Pontos de corte (pointcuts): identificam coleções de pontos de junção no fluxo do programa. Sugestões (advices): são construções semelhantes a métodos, que definem comportamentos adicionais aos pontos de junção. São executadas quando pontos de junção são alcançados [7]. AspectJ tem três tipos diferentes de sugestões: i) Pré-sugestão (before): é executada quando um ponto de junção é alcançado e antes da computação ser realizada. ii) Pós-sugestão (after): é executada quando um ponto de junção é alcançado e após a computação ser realizada. iii) Sugestão substitutiva (around): é executada quando o ponto de junção é alcançado e tem o controle explícito da computação, podendo alternar a execução com o método alcançado pelo ponto de junção. A modularização de interesses de entrecorte é realizada usando pontos de junção (join points) e sugestões (advices). Segundo Noda e Kishi [9], as técnicas atuais de programação não são adequadas para a utilização dos padrões de projeto, pois tornam a aplicação dependente deles, o que diminui as chances de reuso da parte funcional da aplicação. Eles realizaram a implementação de duas versões de um mesmo sistema utilizando o conceito da separação avançada de interesses (Advanced Separation of Concern - ASOC) em Aspet/J e Hyper/J, utilizando o padrão de projeto Observer [5]. Nas duas versões do sistema os autores separam o código da aplicação do código do padrão, os quais foram tratados como interesses separados. O interesse que trata da aplicação contém apenas suas funções específicas, as quais são independentes do padrão, possibilitando o reuso desse interesse. O interesse que trata do padrão descreve a estrutura e o comportamento abstratos do padrão e é independente da aplicação. Assim como Noda e Kishi [9], Hannemann e Kiczales [6] comentam que a técnica de implementação orientada a objetos não é adequada à implementação de padrões de projeto. Para testar essa hipótese, realizaram um experimento com programação orientada a aspectos no qual os vinte e três padrões de projeto propostos por Gamma e outros [5] foram implementados em Java e em Aspect/J. Os benefícios obtidos em dezessete dos vinte e três padrões implementados com orientação a aspectos foram: melhor localidade de código, maior reusabilidade, facilidade de composição e de (desc)conectividade entre classes do padrão e da aplicação. Segundo os autores, alguns padrões possuem estrutura que entrecorta 3
4 o relacionamento entre os papéis impostos pelo padrão e as classes de aplicação que assumem esses papéis. Os três tipos de estruturas identificadas foram as estruturas: de papéis definidos, de papéis sobrepostos e mista. No primeiro tipo de estrutura o papel é bem definido, isto é, as classes participantes não têm funcionalidade além daquela fornecida pelo padrão. Nesses casos a implementação com Aspect/J não apresentou benefícios. No segundo tipo, os papéis são sobrepostos, isto é, eles são atribuídos a classes que têm funcionalidade além daquela fornecida pelo padrão. Esse tipo de estrutura foi a que obteve maiores benefícios, já que a programação orientada a aspectos possui construtores específicos para tratar relacionamentos de entrecorte. O terceiro tipo de estrutura possui tanto papéis definidos quanto sobrepostos e também obteve benefícios, porém menores do que o segundo tipo. As melhorias obtidas com o uso do Aspect/J são inicialmente devidas à inversão das dependências. O código do padrão depende dos participantes e não ao contrário, como ocorre na implementação Orientada a Objetos. Isso possui um impacto direto na localidade de código, pois todas as dependências entre os padrões e a aplicação são localizadas no código do padrão. Visando a necessidade de obtenção de melhorias na localidade do código Orientado a Objetos, Ramos [10] propõe uma abordagem para migrar sistemas Orientados a Objetos para sistemas Orientados a Aspectos. Essa abordagem fornece diretrizes e indícios (alguns no formato de expressões regulares) para a localização, modelagem e implementação de seis tipos de interesses na linguagem AspectJ. Com base nos trabalhos apresentados nesta seção nota-se que embora os padrões não sejam tratados como requisitos não funcionais, sua implementação espalha-se pelo código funcional, causando problemas de reuso, manutenção e evolução. Com base nessa motivação, o padrão Camada de Persistência [11] foi implementado com aspectos [3] e essa implementação é apresentada com maiores detalhes na próxima Seção. 3. Projeto Baseado em Aspectos do Padrão Camada de Persistência O padrão de projeto Camada de Persistência permite minimizar a incompatibilidade existente entre o paradigma orientado a objetos e a persistência de dados em um banco relacional [11]. Ele consiste em uma camada que cuida da interface entre objetos de aplicação e tabelas de banco de dados relacional. Possui um conjunto de dez sub-padrões que podem ser utilizados para a implementação dessa camada de persistência: Camada Persistente (Persistent Layer), CRUD (Criação (Create), Leitura (Read), Atualização (Update) e Remoção (Delete)), Descrição de Código SQL (SQL Code Description), Gerenciador de Tabelas (Table Manager), Métodos de Mapeamento de Atributos (Atributte Mapping Methods), Conversão de Tipos (Type Conversion), Gerenciador de Mudanças (Change Manager), Gerenciador de Identificadores Únicos (OID Manager), Gerenciador de Conexão (Connection Manager) e Gerenciador de Transação (Transaction Manager). Cada um deles possui uma funcionalidade bem definida e enquanto alguns são obrigatórios, outros são opcionais. Por exemplo, o padrão CRUD é essencial, para a realização das operações básicas de persistência, já o padrão Conversão de Tipos é útil, mas não essencial, podendo não ser utilizado. O padrão Camada de Persistência possui três formas de uso, segundo Cagnin [1] a terceira forma é a que permite mais facilmente reutilizar o Gerenciador de Tabelas (Table 4
5 Manager), pois não há preocupação com a persistência de qualquer tipo de objeto no banco de dados, necessitando apenas conhecer os parâmetros dos métodos das classes. Além disso, o sistema implementado utilizando-a é o mais manutenível. Embora a classe TableManager seja reusável, o mesmo não ocorre com as classes da aplicação, devido à dependência do padrão, que ocorre porque essas classes invocam métodos existentes nas classes que implementam o padrão. Camargo e outros [3] fornecem uma alternativa de projeto baseado em aspectos para este padrão que pode ser reutilizada em aplicações específicas. O objetivo foi desenvolver uma estrutura que mantivesse separado o código de persistência do código funcional, facilitando dessa forma o entendimento do padrão e melhorando sua reusabilidade. Para isso, um estudo de caso com um sistema de oficina eletrônica implementado em Java e reimplementado em AspectJ foi utilizado para comparar as duas alternativas de implementação. A versão do padrão com aspectos manteve o código de persistência completamente separado do código funcional, facilitando o entendimento e, conseqüentemente, a sua manutenibilidade e o reuso. Neste artigo é mostrada a experiência em reutilizar o código do padrão Camada de Persistência baseado em aspectos em um sistema de controle de estoque. A Figura 1 mostra uma instanciação genérica do projeto baseado em aspectos do padrão Camada de Persistência [3], sendo que na parte superior encontra-se a camada de persistência e na inferior, a camada de aplicação. Ressalta-se que o termo instanciação está sendo usado para evidenciar que algumas partes do projeto baseado em aspectos do padrão precisam ser modificadas de acordo com a aplicação na qual ele será acoplado. Contudo, há consciência de que esse projeto não é um framework. Outro ponto que merece destaque é que a notação usada neste diagrama para representar os conceitos da POA é a proposta por Camargo e Masiero [2], que evoluiu a partir da necessidade de se representar os conceitos básicos da POA e também de frameworks orientados a aspectos. O aspecto abstrato AbstractAspectConnection encapsula o comportamento genérico de conexão com o banco de dados e deve ser especializado por um aspecto concreto que especifica detalhes específicos da aplicação. Esses detalhes consistem na sobreposição de alguns métodos abstratos e também na especificação de dois pontos de corte abstratos, que podem ser identificados pelos estereótipos <<pointcut-hook>> em itálico. A identificação dos pontos de instanciação é feita por meio da existência do conceito de gancho (hook). Por exemplo, o ponto de corte openconnection é um gancho e precisa ser redefinido no aspecto especializado. Da mesma forma, os métodos com estereótipo <<hook>> também são pontos de instanciação que precisam ser redefinidos. A sobreposição dos métodos é feita para informar detalhes da conexão, enquanto que a especificação do ponto de corte concreto é feita para indicar em que ponto da aplicação a conexão deve ser feita. Note-se que a existência dos pontos de corte é o que determina a independência da aplicação em relação ao código não-funcional, pois na implementação OO, o ponto da aplicação onde a conexão deve ser aberta contém uma chamada a algum método da camada de persistência. Na implementação OA o que ocorre é o contrário, a camada de persistência tem consciência dos locais onde a conexão deve ser aberta. Essa inversão de dependência é o ponto fundamental que mantém a aplicação livre do código não-funcional. 5
6 AbstractAspectConnection <<pointcut-hook>> closeconnection <<pointcut-hook>> openconnection <<after>> closeconnection <<after>> openconnection <<hook>> setjdbc <<hook>> execute <<hook>> executequery <<hook>> conectdb <<hook>> closedb TableManager <<introduction>> {method = findall, getlast, findlike, delete} {attribute = tablename, keyname, colnames, colvalues, cols} AspectStructure AspectConnection AspectClasseApp <<pointcut>> openconnection <<pointcut>> closeconnection <<after>> changesconstructor <<after>> changesemptyconstructor Camada de Persistência Camada de Aplicação <<crosscutting>> {joinpoint =?ClasseAplicacao(..)} {PCDescriptor = changesconstructor} <<crosscutting>> <<introduction>> {joinpoint =? ClasseAplicacao} {method = save, getprimarykeyclause {PCDescriptor = changesemptyconstructor} getprimarykeyvalue} ClasseAplicacao Figura 1 Projeto Baseado em Aspectos do Padrão Camada de Persistência. Na Figura 1, os dois pontos de corte abstratos do aspecto AbstractAspectConnection e também os métodos abstratos são redefinidos no aspecto concreto AspectConnection, porém apenas o ponto de corte concreto openconnection e closeconnection está sendo exibido. A classe TableManager não foi transformada em aspectos porque seu comportamento já estava bem encapsulado e ela não influenciava nenhuma das classes de aplicação. Sendo assim, optou-se por não transformá-la em aspecto. O aspecto AspectStructure é responsável por introduzir nas classes de aplicação alguns atributos e métodos de persistência independentes de qualquer aplicação. Embora não seja explícito no diagrama, o ponto de instanciação nesse aspecto consiste em informar em quais classes de aplicação esses atributos e métodos devem ser inseridos. Na Figura 1, isso é representado por meio de um relacionamento de introdução, representado com o estereótipo <<introduction>>. Os atributos e métodos de persistência que serão inseridos na classe de aplicação ClasseAplicacao podem ser vistos por meio das etiquetas valoras (tag values) attribute e method, respectivamente. Na implementação OO, esses atributos e métodos estão presentes e repetidos em todas as classes de aplicação. O aspecto AspectClassApp é um tipo de aspecto dependente de uma determinada classe persistente de aplicação. Ele é responsável tanto por inserir alguns métodos nessa 6
7 classe, quanto por interceptar as execuções do construtor para modificar seu comportamento. Por exemplo, os métodos getprimarykeyclause, getprimarykeyvalue e o save, vistos por meio da etiqueta method do relacionamento de introdução entre o aspecto AspectClassApp e a classe ClasseAplicacao, possuem informações dependentes dessa classe, que devem ser informadas dentro do aspecto. Além disso, deve-se notar também dois relacionamentos de interceptação (crosscutting) desse aspecto com essa classe. O primeiro utiliza o ponto de corte changesconstructor para interceptar as execuções do construtor normal da classe ClasseAplicacao. Essas informações podem ser obtidas analisando-se as etiquetas PCDescriptor e joinpoint do relacionamento de interceptação em questão. O segundo relacionamento de interceptação utiliza o ponto de corte changesemptyconstructor para interceptar as execuções do construtor vazio dessa mesma classe. Após essas interceptações, as sugestões existentes nesse aspecto informam detalhes específicos da aplicação. A Seção seguinte apresenta o estudo de caso realizado para avaliar o reuso da implementação do padrão de projeto Camada de Persistência implementado com aspectos. 4. Estudo de Caso O estudo de caso consiste em um sistema de controle de estoque implementado na linguagem Java que utiliza o banco de dados relacional SyBase e HTML para as interfaces. O padrão Camada de Persistência está implementado no paradigma Orientado a Objetos (OO) para separar o código da aplicação do código da persistência. A comunicação entre o banco de dados e as interfaces foi implementada por meio de servlets [4]. A função principal do sistema é cadastrar materiais, fornecedores, contas, previsão de compras e alguns documentos, como por exemplo, requisição de material, solicitação de material, comunicado de recebimento, devolução de materiais ao fornecedor, correção de estoque físico, etc. Como o padrão foi implementado utilizando o paradigma OO, todas as classes persistentes da aplicação contêm o código de persistência entrelaçado e espalhado pelos módulos funcionais. A Figura 2 mostra esquematicamente as atividades realizadas. A Atividade I é apoiada por expressões regulares, que fornecem os indícios para o engenheiro de software encontrar o interesse de persistência [10], e tem como entrada o código fonte do sistema de controle de estoque implementado no paradigma OO. O código fonte marcado com comentários, quando o interesse é localizado, e a implementação em aspectos do padrão de projeto Camada de Persistência [3], são as entrada para a Atividade II. A seguir são descritas as atividades que foram realizadas. 7
8 Código fonte OO do sistema de Controle de Estoque Atividade I Identificar o código que implementa o padrão Camada de Persistência. Expressões Regulares Código fonte OA do Padrão Camada de Persistência Código fonte OO do sistema de Controle de Estoque com os trechos de código marcados. Atividade II Reutilizar a porção de código genérica e adaptar a porção de código especifica do padrão. Código fonte OA do sistema de Controle de Estoque Figura 2 - Atividades do processo de reuso do padrão Camada de Persistência Atividade I: Identificar o Código Fonte que Implementa o Padrão Camada de Persistência Essa atividade utiliza as expressões regulares criadas na abordagem Aspecting [10] para identificar interesses existentes no código fonte OO. A Figura 3 mostra a expressão regular referente ao interesse de Persistência que está presente no código fonte do sistema de Controle de Estoque. Todo trecho de código reconhecido por essa expressão regular deve ser considerado como sendo do interesse de persistência e deve-se adicionar, ao final de cada linha, comentários que indiquem que esta linha pertence ao interesse. Esse recurso de comentários também proposto na abordagem Aspecting. <i.persistencia.bd> = Connection <statements> Connection <statements> <SQL> <SQL> <statements> Connection PreparedStatement <statements> PreparedStatement <statements> <SQL> <SQL> <statements> PreparedStatement ResultSet <statements> ResultSet <statements> <SQL> <SQL> <statements> ResultSet Figura 3 - Expressão regular que auxilia a identificar os indícios do interesse de Persistência [10]. As expressões regulares existentes para reconhecer os indícios de Persistência não foram elaboradas considerando a utilização do padrão Persistence Layer. Assim, no trecho de código da classe Conta, apresentado na Figura 4, somente a parte marcada com (a) é que foi reconhecida como de Persistência. Os outros trechos de código, (b) e (c), foram reconhecidos pelo engenheiro de software como parte do padrão. Para isso há necessidade do conhecimento da granularidade 3 do padrão Camada de Persistência. 3 O quanto e como está espalhada pelas classes a implementação do padrão. 8
9 MesAt quantidadenaoat setobje setdbtoobj 1 AnoAt quantidadenaoat setobje setdbtoobj Movime t quantidade quantidad S valoren valors me MovimentoMesesAn setobje setdbtoobj Localiza deposi pratelei repartic bo setobje setdbtoobj Estoq estoq almoxarif Materi codig class descric unida maxm maxi mini qtdestoq precome sald valorultimaco valorcompr C compraunitariaforn dataultimomovi datacada setobje setdbtoobj Cont descric debito credito debitom credito conta conta conta public class Conta implements PersistentObject {... private TableManager tablemanager; private String tablename;... colnames.addelement ("codigo"); colnames.addelement ("descrição");... public boolean save { ResultSet rs; // Persistência Vector clause = new Vector; Vector parameter = new Vector;... } (a) (b) (c) Atributos não localizados pela expressão regular, porém que fazem parte do interesse de Persistência. Linha de código reconhecida pela expressão regular como sendo do Interesse de Persistência Figura 4 - Trecho de código da classe Conta Atividade II: Reutilizar a Porção de Código Genérica e Adaptar a Porção de Código Especifica do Padrão A Figura 5 mostra as três etapas para a execução dessa atividade: (1) análise e adaptação para o reuso dos aspectos AbstractAcpectConnection, AspectConnection que implementam o sub padrão Gerenciador de Conexão; (2) análise e adaptação para o reuso do aspecto AspectStructure que implementa parte dos sub padrões Gerenciador de Tabelas, CRUD e Objeto Persistente; e (3) análise e adaptação/criação para o reuso dos aspectos que implementam atributos específicos de persistência para cada classe de aplicação. Os aspectos dessa última etapa implementam o sub padrão Métodos de Mapeamento de Atributos e a parte restante dos sub padrões CRUD e Objeto Persistente. Nessa etapa é reutilizada a implementação da classe TableManeger. Após a aplicação das três etapas a camada de persistência reusada, Figura 5 (a), intercepta a camada de aplicação do sistema de Controle de Estoque, Figura 5 (b). AbstractAspectConnection <<pointcut-hook>> closeconnection <<pointcut-hook>> openconnection <<after>> closeconnection <<after>> openconnection <<hook>> setjdbc <<hook>> execute <<hook>> executequery <<hook>> conectdb <<hook>> closedb (1) (a) Camada de Persistência Reusada AbstractAspectConnection <<pointcut-hook>> closeconnection <<pointcut-hook>> openconnection <<after>> closeconnection <<after>> openconnection <<hook>> setjdbc <<hook>> execute <<hook>> executequery <<hook>> conectdb <<hook>> closedb <<pointcut>> openconnection <<pointcut>> closeconnection (b) Camada de Aplicação do Sistema de Controle de Estoque <<pointcut>> openconnection <<pointcut>> closeconnection AspectStructure (2) AspectStructure TableManager TableManager AspectClasseApp (3) AspectClasseApp <<after>> changesconstructor <<after>> changesemptyconstructor <<after>> changesconstructor <<after>> changesemptyconstructor Figura 5 - Etapas realizadas no processo de reuso do padrão de projeto Camada de Persistência. 9
10 Na etapa (1), apenas o aspecto AbstractAspectConnection, mostrado na Figura 6, é reusado completamente sem adaptações para o sistema de controle de estoque. Ele possui um ponto de corte abstrato denominado openconnection, cujo ponto de junção deve ser fornecido pelo aspecto, mostrado na Figura 7, AspectConnection que é o aspecto concreto que o especializa. public abstract aspect AbstractAspectConnection { public static Connection con; public static Statement stmt;... abstract pointcut openconnection; after : openconnection {... ConnectDB; }... public void setjdbc(...) {...} protected static void ConnectDB {...} private static void CloseDB {...} public static void execute {...} public static ResultSet executequery {...} } Figura 6 - Aspecto de Conexão Abstrato. Para o AspectConnection é necessário que se defina o ponto de junção concreto, que indica o método que deve ser interceptado para realizar a conexão, e também os parâmetros de configuração dessa conexão na Sugestão before. A parte (a) na Figura 7 mostra que o ponto de junção concreto são chamadas do método init, pois é nesse local do código da implementação orientada a objetos que havia uma chamada ao método responsável pela conexão com o banco de dados. Além disso, na Sugestão before desse aspecto, o método setjdbc deve ser invocado do aspecto abstrato passando alguns parâmetros de configuração necessários à conexão, conforme apresentado na parte destacada com a letra (b) dessa mesma figura. Portanto para a adaptação desse aspecto em (a) indicou-se o método que era chamado na versão OO, após a conexão com o banco de dados. Em (b) foram adicionados o nome do banco de dados, nome do usuário desse banco e a senha. Foram retirados das classes de aplicação, todos os métodos referentes a conexão que estavam marcados como sendo do padrão. public aspect AspectConnection extends AbstractAspectConnection { pointcut doconnection: call (void init(..)); (a) Ponto de junção fornecido } before : doconnection { super.setjdbc("jdbc:odbc:estoque", "DBA", "sql",...); } (b) Parâmetros de configuração Figura 7 - Aspecto de Conexão Concreto. Na etapa (2), o AspectStructure, mostrado na Figura 8, é adaptado para poder ser reutilizado. Esse aspecto por meio do conceito de Introduções, insere os atributos de persistência tablename, keyname, colnames, colvalues, colnamesexception e cols em todas as classes de aplicação, pois são atributos provenientes do sub-padrão Gerenciador de 10
11 Tabelas. O mesmo ocorre com os métodos findall e findlike, que foram reusados do sub-padrão Objeto Persistente e, delete que foi reusado tanto do Objeto Persistente quanto do CRUD. Portanto para a adaptação desse aspecto para o reuso foi necessário adicionar o nome de todas as classes de aplicação do sistema de Controle de Estoque juntamente com os métodos e atributos descritos a cima. A Figura 8 ilustra em negrito, alguns trechos dessa adaptação para a classe Conta. Foram retirados das classes de aplicação todos os métodos e atributos marcados como sendo do padrão que estavam relacionados no aspecto AspectStructure. public aspect AspectStructure { private String Conta.tableName;... private String Conta.keyName;... private String Conta.colNames = new Vector;... private String Conta.colNamesException = new Vector;... métodos sets e gets public ResultSet Conta.findall { return TableManager.findallDB(this.getTableName); } public ResultSet Conta.findlike {...}... public boolean Conta.delete {...} }... } Figura 8 - Aspecto AspectStructure. A etapa (3) consiste em criar um aspecto para cada classe persistente de aplicação. A Figura 9 apresenta o aspecto AspectConta, que possui comportamento específico para a classe Conta, pois deve definir valores de persistência para essa classe, tais como: nome da tabela, nome das colunas da tabela, nome da chave primária e número de colunas, como mostrado parcialmente na parte destacada com a letra (a). A parte destacada com a letra (b) mostra a atribuição dos valores para os atributos definidos anteriormente. Como esse tipo de aspecto possui características específicas de cada classe de persistência, foi criado um aspecto como esse para cada uma delas. O ponto de corte changesconstructor desse aspecto possui como tarefa interceptar chamadas do construtor da classe Conta e definir valores para os atributos de persistência dessa classe. Foram retirados das classes de aplicação todos os métodos e atributos marcados como sendo do padrão que estavam relacionados aos aspectos específicos. public aspect AspectConta { pointcut changesconstructor(conta c): target (c) && execution (Conta.new(int, String, String, String, String, String, String)); after (Conta c): changesconstructor(c) } {c.settablename("conta"); c.setkeyname("codigo");... id = new Integer(c.getCodigo); c.setcolvalues(id); c.setcolvalues(c.getdescricao);...} public boolean Conta.save {... } public Conta Conta.SetObject (ResultSet rs) {... } private Conta Conta.SetDBToObject(ResultSet rs) {... } (a) (b) Figura 9 - Aspecto AspectConta. 11
12 A Tabela 1 apresenta para cada aspecto reusado, quais foram as ações efetuadas para reusar o código na versão Orientada a Aspectos (OA) e quais seriam as ações necessárias para reusar a porção de código equivalente na versão Orientada a Objetos (OO). Tabela 1 - Comparação das adaptações para o reuso nas versões OO e OA. Aspectos Reusados AbstractAspectConnection e AspectConnection AspectStructure Aspectos específicos e a classe TableManeger Ações necessárias para reusar na versão orientada a aspectos 1 - especificar um ponto de corte no AspectConnection 2 - sobrepor o método setjdbc inserindo as informações especificas sobre a conexão. 1 - alterar o aspecto AspectStructure colocando o nome das classes que fazem a persistência. 1 - criar um aspecto para cada classe de persistência da aplicação. 2 - utilizar o conceito de introdução e adicionar três métodos que pertencem ao padrão nas classes que fazem a persistência. 3 - criar dois pontos de corte e duas sugestões (advices) que modificam os construtores 4 - reutilizar a classe TableManeger sem modifica-la. Ações necessárias para reusar na versão orientada a objetos 1 - sobrepor as informações específicas sobre a conexão na classe ConnectionManneger. 2 - procurar por todos os pontos da aplicação que fazem a conexão com o banco de dados. 1 - procurar por todas as classes que fazem a persistência e adicionar os atributos e métodos. 1 - procurar por todas as classes que fazem a persistência e adicionar os métodos que pertencem ao padrão. 2 - alterar os construtores das classes que fazem a persistência. 3 - reutilizar a classe TableManeger sem modifica-la. A partir da comparação das ações necessárias para a reutilização da implementação do padrão de projeto Camada de Persistência observados na Tabela 1 é possível inferir que apesar de ter mais ações realizadas na versão Orientada a Aspectos são menos trabalhosas que as para realizar o reuso na versão Orientada a Objetos. Ações como procurar por pontos da aplicação que necessitam fazer a conexão como o banco de dados, despendem muito mais tempo do que a ação de especificar a captura desses pontos em um ponto de corte. 5. Considerações Finais Este artigo mostra uma experiência de reuso da implementação orientada a aspectos do padrão Camada de Persistência em um sistema de controle de estoque. Como os autores já tinham experiência em reusar a implementação orientada a objetos desse padrão em outros sistemas, foi possível identificar que o processo de reuso orientado aspectos possui um número maior de passos, porém são mais simples do que os passos do reuso orientado a objetos. Note-se que no contexto do estudo de caso realizado não foi considerado o conhecimento do engenheiro de software com programação orientada a aspectos. Os benefícios ou vantagens observados com o reuso do padrão implementado com aspectos foram: Facilidade de manutenção - Como o código fica mais modular e com menos redundâncias, o engenheiro de software não necessita procurar os trechos de código do padrão por todas as classes de aplicação, pois ele está localizado em poucos módulos; 12
13 Facilidade de compreensão do código - Da mesma forma que o tópico anterior, a modularidade faz com que o engenheiro de software se concentre em poucos módulos para entender a persistência; Facilidade de evolução - Como o código do padrão encontra-se bem modularizado, adicionar novos aspectos que tratam de outros interesses se torna mais fácil. Por exemplo, poderia ser adicionado um novo aspecto que cuidasse do interesse de geração de identificador automaticamente. Embora o padrão Camada de Persistência tenha se mostrado adequado para ser implementado com aspectos, não são todos os padrões de projeto que apresentam esse comportamento. Alguns dos padrões propostos por Gamma e outros [5] ficam mais complexos do que se estivessem implementados no paradigma Orientado a Objetos [9]. A utilização das expressões regulares [10] auxiliou a identificação do interesse de persistência, porém foi necessário o conhecimento da granularidade da implementação do padrão Camada de Persistência, pois as heranças e implementações de interfaces não estavam previstas na expressão regular. A elaboração de expressões regulares que reconheçam trechos de código relativos ao padrão deverá também ser incorporadas na abordagem Aspecting. A implementação do padrão Camada de Persistência com aspectos [2] já evoluiu bastante e já pode ser considerado como um framework de persistência orientado a aspectos. Infere-se que a utilização de um framework de persistência seja uma solução mais eficaz para o reuso do interesse de persistência. A abordagem Aspecting [10] permite que outros interesses sejam utilizados na reconstrução de sistemas orientados a objetos para sistemas orientados a aspectos que não foram tratados neste trabalho. Somente algumas partes dessa abordagem foram utilizadas aqui sendo referenciadas quando ocorreram. 6. Referências Bibliográficas [1] Cagnin, M.I. Avaliação das Vantagens quanto à Facilidade de Manutenção e Expansão de Sistemas Legados Sujeitos à Engenharia Reversa e Segmentação. Dissertação de Mestrado, DC-UFSCar, [2] Camargo, V.V. Masiero, P.C. UML-AOF Um Perfil UML para o Projeto de Frameworks Orientados a Aspectos. Relatório Técnico, ICMC-USP, Disponível para download em: [3] Camargo, V.V.; Ramos, R.A.; Penteado, R.A.D.; Masiero, P.C. Projeto Baseado em Aspectos do Padrão Camada de Persistência. In: Simpósio Brasileiro de Engenharia de Software (SBES), Manaus, [4] Camargo, V.V. Reengenharia Orientada a Objetos de Sistemas COBOL com a utilização de Padrões de Projeto e Servlets. Dissertação de Mestrado, Departamento de Computação da Universidade Federal de São Carlos, [5] Gama, E., Helm, R., Johnson, R., Vlissides, J. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley,
14 [6] Hannemann and Kiczales. Design Pattern Implementation in Java and AspectJ, Proceedings of the 17th Annual ACM conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA), pages , November [7] Kiczales, G.; Hilsdale, E.; Hugunin, J.; Kersten, M.; Palm, J. Griswold, W.G. Getting Started with AspectJ. In: Anais do ACM, pág , Outubro [8] Kiczales, G.; Lamping, J.; Mendhekar, A. RG: A Case-Study for Aspect-Oriented Programming. Artigo Técnico, SPL97. Xerox Palo Alto Research Center, [9] Noda, N. and Kishi, T. "Implementing Design Patterns Using Advanced Separation of Concerns", in Proceedings of OOPSLA 2001, Workshop on Advanced Separation of Concerns in Object-Oriented Systems, Tampa Bay, FL, October [10] Ramos, R., A. Aspecting: Abordagem para Migração de Sistemas OO para Sistemas AO. Dissertação de Mestrado. Programa de Pós Graduação em Ciência da Computação, Universidade Federal de São Carlos, São Carlos - SP, maio de [11] Yoder, J. W.; Johnson, R. E.; Wilson, Q. D. Connecting Business Objects to Relational Databases. Conference on the Pattern Languages of Programs,
Reuso da Implementação Orientada a Aspectos do Padrão de Projeto Camada de Persistência
Reuso da Implementação Orientada a Aspectos do Padrão de Projeto Camada de Persistência Copyright 2004, Ricardo Argenton Ramos, 1, Valter Vieira de Camargo, 2 Rosângela Penteado, Paulo Cesar Masiero Permission
Leia maisUm Arcabouço Orientado por Aspectos para Implementação Automatizada de Persistência
Um Arcabouço Orientado por Aspectos para Implementação Automatizada de Persistência César Francisco de M. Couto 1, Marco Túlio O. Valente 2, Roberto da S. Bigonha 1 1 Departamento de Ciência da Computação
Leia mais2 Desenvolvimento de Software Orientado a Aspectos
20 2 Desenvolvimento de Software Orientado a Aspectos A divisão em partes é um importante instrumento para se reduzir a complexidade de sistemas de software. É muito difícil para o ser humano compreender
Leia mais3 Uma Abordagem Orientada a Aspectos para o Desenvolvimento de Frameworks
48 3 Uma Abordagem Orientada a Aspectos para o Desenvolvimento de Frameworks Este capítulo apresenta uma visão geral da contribuição principal deste trabalho: uma abordagem orientada a aspectos para o
Leia maisSeminário de aspectos: conceitos, características e exemplos
Seminário de aspectos: conceitos, características e exemplos Daniel Bruno Conrado Thiago Gottardi Departamento de Computação Universidade Federal de São Carlos (UFSCar) São Carlos SP Brasil dbconrado@gmail.com,
Leia maisBy Gian Ricardo Berkenbrock & Eduardo Dockhorn da Costa
By Gian Ricardo Berkenbrock & Eduardo Dockhorn da Costa Problema; AOP; Aspect J; Proposta ao Problema; Conclusões; Referências. Desenvolver os tipos abstratos de dados: lista, fila, pilha e deque. Estes
Leia maisUm Estudo Quantitativo das Implementações Orientadas a Aspectos do Padrão Data Access Object
Um Estudo Quantitativo das Implementações Orientadas a Aspectos do Padrão Data Access Object André L. de Oliveira 1, André L. A. Menolli 2, Ricardo G. Coelho 2, Valter V. de Camargo 3, Ricardo A. Ramos
Leia maisPOO e suas Limitações Introdução POA AspectJ: Conceitos Básicos. Objetivo da Programação? Introdução à OO Introdução à POO
POO e suas Limitações Introdução POA AspectJ: Conceitos Básicos Exemplo: Tracing Lincoln S. Rocha (lincoln@great.ufc.br) Objetivo da Programação? Introdução à OO Introdução à POO Limitações da POO Requisitos
Leia maisUm Perfil UML para Frameworks Transversais
Um Perfil UML para Frameworks Transversais Aluno: José Uetanabara Júnior 1 Orientador: Valter Vieira de Camargo 2 ¹Instituto de Informática Univem Centro Universitário Eurípides de Marília Marília, São
Leia maisReengenharia de Sistemas Orientados a Objetos para Sistemas Orientados a Aspectos
Reengenharia de Sistemas Orientados a Objetos para Sistemas Orientados a Aspectos Ricardo Argenton Ramos 1 Anderson Pazin * Rosângela Ap. D. Penteado UFSCar - Universidade Federal de São Carlos, Departamento
Leia maisDesenvolvimento 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 2006 Profa. Dra. Itana Gimenes RUP: Projeto Artefatos Modelo de Projeto: Lista de classes de
Leia maisUma ferramenta CASE para o Desenvolvimento de Software Orientado a Aspectos
Uma ferramenta CASE para o Desenvolvimento de Software Orientado a Aspectos Vinicius Cardoso Garcia 1, Daniel Lucrédio 1, Luíza Frota de Paula Pinto 1, Alexandre Alvaro 2, Eduardo Santana de Almeida 2,
Leia mais!!!!! " #!!!! $ +!!!!!! *!! * -! %!! - %.! % - "!! ) $ $ / - %!!0$ 1 - '& 2( - *! * *!0$ - '&.( - *! #
" # $ $ % # & '( ) # * + * $ *, * - % - %. % - " ) $ $ / - % 0$ 1 - '& 2( - * * * 0$ - '&.( - * # 2 1 3 4 5 6 * 7 8 5 / # 7 4 9 &* 5 * # % * ) 7 &* : ; 5 - * < # - 7 4 = 6 5 # * - ) )- 3 $ 1 > 5 = 5 %
Leia maisUniversidade 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 maisAspectJ. Silvio do Lago Pereira. Doutorando em Ciência da Computação
AspectJ Silvio do Lago Pereira Doutorando em Ciência da Computação slago@ime.usp.br Sumário Programação Orientada a Objetos (POO) Programação Orientada a Aspectos (POA) AspectJ Exemplos Novembro/2002 Silvio
Leia maisAgenda 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 mais3 Tecnologias Relacionadas
Tecnologias Relacionadas 31 3 Tecnologias Relacionadas O objetivo deste capítulo é apresentar um resumo de cada tecnologia relacionada ao processo proposto nesta dissertação, mostrando suas principais
Leia maisUm Método para o Desenvolvimento de Software Baseado em Componentes e Aspectos
Roteiro Um Método para o Desenvolvimento de Software Baseado em Componentes e Aspectos Marcelo Medeiros Eler Universidade de São Paulo Av. do Trabalhador São-Carlense, 400 São Carlos, SP Email: mareler@icmc.usp.br
Leia maisDIAGRAMAS DE CLASSE UML
DIAGRAMAS DE CLASSE UML Projeto Detalhado de Software (PDS) Profa. Cynthia Pinheiro Antes de mais nada... Calendário de Reposições Aula 1: 27/10/2017, 8h-10h, Sala 8 Aula 2: A verificar Aula 3: A verificar
Leia maisReuso de Software Aula Maio 2012
Reuso de Software Aula 19 Tópicos da Aula Engenharia de Software baseada em Componentes (CBSE) Eduardo Figueiredo http://www.dcc.ufmg.br/~figueiredo reuso.software@gmail.com Componentes Modelos de Componentes
Leia maisTécnicas para Reutilização de Software
DCC / ICEx / UFMG Técnicas para Reutilização de Software Eduardo Figueiredo http://www.dcc.ufmg.br/~figueiredo Panorama de Reutilização Frameworks Padrões de projeto Aplicações configuráveis Padrões de
Leia maisArquitetura de Referência para Projeto Detalhado de Frameworks Transversais de Persistência
Arquitetura de Referência para Projeto Detalhado de Frameworks Transversais de Persistência Aluno: Rogério Lazanha 1 Orientador: Valter Vieira de Camargo 2 ¹Centro Universitário Eurípedes Soares da Rocha
Leia maisUso de Aspectos para Verificar Regras de Instanciação de Frameworks
Uso de Aspectos para Verificar Regras de Instanciação de Frameworks André Dantas Rocha 1 Valter Vieira de Camargo 1 Paulo Cesar Masiero 1 Resumo: A instanciação de frameworks normalmente é um processo
Leia maisModelo do Mundo Real. Abstração. Interpretação
Modelo do Mundo Real Mundo Real Abstração Interpretação Sistema de Software Modelo Algoritmo Abstração: O modelo precisa capturar apenas as características do mundo real que são importantes para o sistema
Leia maisImplementação de Padrões de Projeto em Java e AspectJ
Implementação de Padrões de Projeto em Java e AspectJ Jan Hannemann e Gregor Kiczales University of British Columbia Bruno Cardoso Reutilização de Software 18/09/13 DCC/ICEx/UFMG Padrões de Projeto (GoF
Leia mais4 Processo de Transformação
Tecnologias Relacionadas 43 4 Processo de Transformação Com a constante mudança nos requisitos (funcionais e não funcionais) do domínio da aplicação, há uma grande necessidade de que os sistemas estejam
Leia mais9 Conclusão e trabalhos futuros
255 9 Conclusão e trabalhos futuros O aumento da complexidade das aplicações de software de hoje em dia e o advento de tecnologias inovadoras e recentes fazem com que os sistemas de software incorporem
Leia maisEngenharia de Software
Engenharia de Software Design Principles Representando SW em UML OO em C Pattens úteis para embedded Rodrigo M A Almeida Design Principles Design Principles são guias para decompor as funcionalidades e
Leia maisProgramação Orientada a Aspectos em AspectJ
Programação Orientada a Aspectos em AspectJ Elaine da Silva Monteiro 1, Eduardo Kessler Piveta 1 1 Curso de Sistemas de Informação Centro Universitário Luterano de Palmas (CEULP/ULBRA), Tocantins, Brasil
Leia maisFerramenta MVCASE - Estágio Atual: Especificação, Projeto e Construção de Componentes
Ferramenta MVCASE - Estágio Atual: Especificação, Projeto e Construção de Componentes Antônio Francisco do Prado Daniel Lucrédio e-mail: prado@dc.ufscar.br Resumo Este artigo apresenta a ferramenta CASE
Leia mais4 Desenvolvimento de Software Orientado a Aspectos
4 Desenvolvimento de Software Orientado a Aspectos Apesar de ser a tecnologia atualmente dominante no desenvolvimento de software, a orientação a objetos possui algumas limitações nas tarefas de projetar
Leia maisProgramaçã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 mais2 Estado da Arte e Trabalhos Relacionados
18 2 Estado da Arte e Trabalhos Relacionados Neste capítulo, serão apresentados alguns conceitos relativos a frameworks orientado a objetos, e o paradigma da programação orientada a aspectos. Além disso,
Leia maisDATA 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 maisTécnicas para Reutilização de Software Prof. Eduardo Figueiredo Estagiário: Johnatan Oliveira
Técnicas para Reutilização de Software Prof. Eduardo Figueiredo Estagiário: Johnatan Oliveira Panorama de Reutilização Frameworks Padrões de projeto Aplicações configuráveis Padrões de arquitetura Linha
Leia maisNextFlow: Um Framework para Mapeamento de Processos de Negócio e Objetos
NextFlow: Um Framework para Mapeamento de Processos de Negócio e Objetos Rógel Garcia de Oliveira, Marco Túlio Valente 1 Universidade Federal de Minas Gerais (UFMG) Belo Horizonte MG Brasil {rogelgarcia,mtov}@dcc.ufmg.br
Leia maisManutenção de Frameworks Orientados a Objetos Usando Orientação a Aspectos
Manutenção de Frameworks Orientados a Objetos Usando Orientação a Aspectos André L. de Oliveira 1, Valter V. de Camargo, Rosângela Ap. D. Penteado 1 Departamento de Computação Universidade Federal de São
Leia mais6 Mecanismo de Tratamento de Exceções Sensível ao Contexto
6 Mecanismo de Tratamento de Exceções Sensível ao Contexto Este capítulo apresenta a proposta de nosso mecanismo de tratamento de exceções sensível ao contexto. Tal mecanismo foi desenvolvido de acordo
Leia maisEA975 - Laboratório de Engenharia de Software
EA975 - Laboratório de Engenharia de Software Turmas K/L - 2017 Aula 8 Vamos inicialmente especificar com mais detalhes o termo "recurso" utilizado no estilo arquitetural REST. Em REST, recursos são uma
Leia maisThe Adaptive Pipeline Aspect Pattern
MAC5715 - Tópicos Avançados em POO Professor: Fábio Kon The Adaptive Pipeline Aspect Pattern Raoni Kulesza e Eduardo Oliveira de Souza 20 de setembro de 2006 1. Objetivos O padrão Adaptive Pipeline Aspect
Leia maisCLÁUDIO ROSSE PANDOLFI SUPORTE DE INTERESSES TRANSVERSAIS PARA FRAMEWORK CODEIGNITER
FUNDAÇÃO DE ENSINO EURÍPIDES SOARES DA ROCHA CENTRO UNIVERSITÁRIO EURÍPIDES DE MARÍLIA UNIVEM CURSO DE CIÊNCIA DA COMPUTAÇÃO CLÁUDIO ROSSE PANDOLFI SUPORTE DE INTERESSES TRANSVERSAIS PARA FRAMEWORK CODEIGNITER
Leia maisCampus 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 : 07
Leia mais3 Ferramenta Proposta 3.1. Objetivos
3 Ferramenta Proposta 3.1. Objetivos O objetivo deste trabalho é a criação de um framework de testes que incorpore algumas das novas idéias encontradas na literatura. Sua principal característica deve
Leia maisPROJETO 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 maisRevisão de conceitos Tópicos Avançados em TI Prof. Rossano Pablo Pinto Fevereiro/ v0.1
Revisão de conceitos Tópicos Avançados em TI Prof. Rossano Pablo Pinto Fevereiro/2013 - v0.1 Orientação a objetos Classe Métodos Visibilidade Tipo de retorno Tipo dos parâmetros Atributos Tipo Visibilidade
Leia maisFerramenta MVCase Uma Ferramenta Integradora de Tecnologias para o Desenvolvimento de Componentes Distribuídos
Ferramenta MVCase Uma Ferramenta Integradora de Tecnologias para o Desenvolvimento de Componentes Distribuídos Eduardo Santana de Almeida Daniel Lucrédio Calebe de Paula Bianchini Antonio Francisco do
Leia maisPadrõ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 maisJÚLIO CÉSAR BRANDT AGUILAR UTILIZAÇÃO E ANÁLISE DE UM PROCESSO DE DESENVOLVIMENTO DE SOFTWARE ORIENTADO A ASPECTOS
FUNDAÇÃO DE ENSINO EURÍPIDES SOARES DA ROCHA CENTRO UNIVERSITÁRIO EURÍPIDES DE MARÍLIA UNIVEM TRABALHO DE CONCLUSÃO DE CURSO TCC JÚLIO CÉSAR BRANDT AGUILAR UTILIZAÇÃO E ANÁLISE DE UM PROCESSO DE DESENVOLVIMENTO
Leia maisESTUDO 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 mais2. Trabalhos Relacionados
19 acase: Ambiente para Modelagem, Geração de Código e Engenharia Reversa de Software Orientado a Aspectos Thiago Silva-de-Souza¹, ², Wallace Santos Vialle Rettich², Danilo Ferreira Leite², Diego Cardozo
Leia maisINF1013 MODELAGEM DE SOFTWARE
INF1013 MODELAGEM DE SOFTWARE Departamento de Informática PUC-Rio Ivan Mathias Filho ivan@inf.puc-rio.br Programa Capítulo 1 O Paradigma Orientado a Objetos A Linguagem UML Descrição da Arquitetura 1 Programa
Leia maisUNIVERSIDADE LUSÍADA DE LISBOA. Programa da Unidade Curricular PROGRAMAÇÃO AVANÇADA Ano Lectivo 2013/2014
Programa da Unidade Curricular PROGRAMAÇÃO AVANÇADA Ano Lectivo 2013/2014 1. Unidade Orgânica Ciências da Economia e da Empresa (1º Ciclo) 2. Curso Engenharia Informática 3. Ciclo de Estudos 1º 4. Unidade
Leia maisBANCO DE DADOS ORIENTADO A OBJETOS
UNIDADEB BANCO DE DADOS ORIENTADO A OBJETOS 1. Introdução Um Banco de Dados Orientado a Objetos (BDOO) é um banco de dados em que, no modelo lógico, as informações são armazenadas na forma de objetos,
Leia mais4 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 maisAgenda do Curso. Reuso de Software. Agenda da Aula. Tipos de Reuso. Vantagens de Reuso. Reuso de Software. Eduardo Figueiredo
Engenharia de Software Aula 21 Agenda do Curso Reuso de Software Aula 23 Data 28/05 Assunto Desenv. Orientado a Aspectos 24 30/05 Laboratório 25 04/06 Apresentações do TP (1) Eduardo Figueiredo 26 06/06
Leia maisREUSO E REUSABILIDADE
REUSO E REUSABILIDADE Manutenção de Software Profa. Cynthia Pinheiro Antes de mais nada... 2ª Lista de Exercícios Já está disponível no site a 2ª Lista de Exercícios Entrega: dia 03/10, no horário da aula.
Leia mais3.1 Reflexão Computacional
3 Adaptação Dinâmica Adaptação dinâmica é a capacidade de um sistema ser modificado durante sua execução para se adequar a novas necessidades. Recentemente, esse tem se tornado um tópico de pesquisa proeminente
Leia maisARCHITECTURAL DESIGN. Ian Sommerville, 8º edição Capítulo 11 Aula de Luiz Eduardo Guarino de Vasconcelos
ARCHITECTURAL DESIGN Ian Sommerville, 8º edição Capítulo 11 Aula de Luiz Eduardo Guarino de Vasconcelos Objetivos Tópicos abordados Arquitetura de Software Projeto de arquitetura Vantagens de arquitetura
Leia maisAcadêmico: Samuel Y. Deschamps Orientador: Prof. Jacques R. Heckmann
Acadêmico: Samuel Y. Deschamps Orientador: Prof. Jacques R. Heckmann Roteiro Introdução Problema a ser resolvido e objetivos Fundamentação Teórica ORM, RTTI, Custom Attributes, Nullable Desenvolvimento
Leia maisAspect Oriented Programming (AOP) Uma visão geral da programação orientada a aspectos. Usando AspectJ
Aspect Oriented Programming (AOP) Uma visão geral da programação orientada a aspectos. Usando AspectJ Objetivos O objetivo dessa apresentação é proporcionar uma visão geral sobre a programação orientada
Leia maisOracle Objeto-Relacional. Pablo Vieira Florentino
Oracle Objeto-Relacional Pablo Vieira Florentino Motivação - Modelo Objeto-Relacional Resposta dos Bancos de Dados Relacionais à Orientação a Objetos Relacional Suporte a SQL, transações, etc. Objeto Suporte
Leia maisRequisitos de sistemas
Requisitos de sistemas Unidade III - Casos de Uso Identificação de casos de uso Conceitos de orientação a objetos Modelagem do diagrama de classes e casos de uso 1 Casos de uso CONCEITO Especifica o comportamento
Leia maisA figura abaixo representa uma classe denominada Carteira. Esta classe é composta dos métodos depositar(valor) e retirar(valor) e do atributo saldo.
1-Introdução à Programação Orientada a Objetos 1.1. O que é programação orientada a objetos? Programação orientada a objetos é uma metodologia de desenvolvimento de software. Sua principal vantagem é a
Leia maisAgenda da Aula. Desenvolvimento de Software Orientado a Aspectos. Aspectos... Motivação. Um pouco de história. Programação Estruturada
Engenharia de Software Aula 23 Agenda da Aula Desenvolvimento de Software Orientado a Aspectos Introdução a desenvolvimento de software orientado a aspectos Interesses centrais e interesses transversais
Leia maisConceitos de Sistemas de Banco de Dados INE 5323
Conceitos de Sistemas de Banco de Dados INE 5323 Prof. Mario Dantas Introdução Por quê Sistemas de Banco de Dados Visão dos Dados Modelos de Dados Linguagem de Definição de Dados (DDL) Linguagem de Manipulação
Leia maisDesenvolvimento de Sistemas de Informação Flexíveis Utilizando Frameworks com Separação de Regras de Negócio
Desenvolvimento de Sistemas de Informação Flexíveis Utilizando Frameworks com Separação de Regras de Negócio Sérgio E. C. Netto Faculdade Professor Miguel Ângelo da Silva Santos (FeMASS) sergioecnetto@gmail.com
Leia mais1) DADOS DA OBRA: Programando em Java 2 Teoria e Aplicações Rui Rossi dos Santos 2004 Axcel Books (
1) DADOS DA OBRA: Título: Programando em Java 2 Teoria e Aplicações Autor: Rui Rossi dos Santos Ano: 2004 Editora: Axcel Books (http://www.axcel.com.br) Páginas: 580 Encadernação: Capa dura 2) DESCRIÇÃO
Leia maisTeste de Programas Orientados a Aspectos: Uma Abordagem Estrutural para AspectJ
Roteiro Teste de Programas Orientados a Aspectos: Uma Abordagem Estrutural para AspectJ Otávio Augusto Lazzarini Lemos Instituto de Ciências Matemáticas e de Computação Universidade de São Paulo Av. do
Leia maisUNIVERSIDADE LUSÍADA DE LISBOA. Programa da Unidade Curricular PROGRAMAÇÃO AVANÇADA Ano Lectivo 2017/2018
Programa da Unidade Curricular PROGRAMAÇÃO AVANÇADA Ano Lectivo 2017/2018 1. Unidade Orgânica Ciências da Economia e da Empresa (1º Ciclo) 2. Curso Engenharia Informática 3. Ciclo de Estudos 1º 4. Unidade
Leia maisProgramação Orientada a Objectos - P. Prata, P. Fazendeiro
9 Classes Abstractas e Interfaces Classe Abstracta Classe em que pelo menos um dos métodos de instância não é implementado. Exemplo: public abstract class Forma{ public abstract double area(); public abstract
Leia maisAspectJ. AspectJ. Extensões de AspectJ. Pontos de Junção. Exemplos de Pontos de Junção. Modelo de Pontos de Junção
DCC / ICEx / UFMG AspectJ AspectJ Eduardo Figueiredo http://www.dcc.ufmg.br/~figueiredo Linguagem orientada a aspectos mais madura e difundida Extensão simples da linguagem Java Gera arquivos.class compatíveis
Leia maisAspectJ - Programação Orientada a Aspectos em Java. Sérgio Soares Centro de Informática Universidade Federal de Pernambuco
AspectJ - Programação Orientada a Aspectos em Java Sérgio Soares Centro de Informática Universidade Federal de Pernambuco Programação Orientada a Objetos Lida com conceitos mais intuitivos Permite ganhos
Leia maisTECNOLOGIAS DE ORGANIZAÇÃO E IMPLEMENTAÇÃO DE SISTEMAS DE
TECNOLOGIAS DE ORGANIZAÇÃO E IMPLEMENTAÇÃO DE SISTEMAS DE INFORMAÇÃO NA WEB. Resumo A preocupação com o desenvolvimento de sistemas é constante, e com o surgimento da Internet acentuou-se a concorrência
Leia maisIntrodução. descrever os tipos de interfaces e linguagens oferecidas por um SGBD. mostrar o ambiente de programas dos SGBD s
Introdução Contribuição do Capítulo 2: discutir modelos de dados definir conceitos de esquemas e instâncias descrever os tipos de interfaces e linguagens oferecidas por um SGBD mostrar o ambiente de programas
Leia maisAula 3 POO 1 Classe e Objeto. Profa. Elaine Faria UFU
Aula 3 POO 1 Classe e Objeto Profa. Elaine Faria UFU - 2019 Sobre o Material Agradecimentos Aos professores José Gustavo e Fabiano, por gentilmente terem cedido seus materiais. Os slides consistem de adaptações
Leia maisOrientaçã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 maisMódulo III Camada de Persistência
Módulo III Camada de Persistência Prof. Ismael H F Santos April 05 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 1 Ementa Modulo III Camada de Persistência Persistência de Objetos Mecanismo de
Leia maisUniversidade 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 mais3 Trabalhos relacionados
3 Trabalhos relacionados Adaptação e implantação dinâmicas são requisitos de aplicações em diversos domínios. Diversas abordagens são capazes de promover adaptação e implantação em tempo de execução. Alguns
Leia mais4 O Framework de Avaliação
4 O Framework de Avaliação O propósito central do uso de aspectos é melhorar a separação de concerns. Entretanto a orientação a aspectos pode afetar também outros atributos de software, tais como acoplamento,
Leia maisBanco de Dados. Aula 2 - Prof. Bruno Moreno 19/08/2011
Banco de Dados Aula 2 - Prof. Bruno Moreno 19/08/2011 Aula passada.. Apresentação do professor e disciplina Definição de Banco de Dados Sistema de BD vs Tradicional Principais características de BD Natureza
Leia maisClasses e Objetos em Java. Algoritmos e Programação I. Classes. Classes. Modificadores de Acesso. Classes. Revisão
e Objetos em Java Algoritmos e Programação I Aula 9 Profa. Márcia Cristina Moraes mmoraes@inf.pucrs.br Profa. Sílvia M. W. Moraes silvia@inf.pucrs.br Prof. Marcelo H. Yamaguti yamaguti@inf.pucrs.br Prof.
Leia maisIntrodução à Análise e Projeto de Sistemas
Introdução à I. O Que vamos fazer na Disciplina? Saber uma linguagem de programação orientada a objeto (OO) não é suficiente para criar sistemas OO Tem que saber Análise e Projeto OO (APOO) Isto é, Análise
Leia maisProtó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 maisCampus 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: ENGENHARIA DE SOFTWARE Aula N : 16 Tema:
Leia maisPLATAFORMA 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 maisIntrodução. Diagramas de Interação. Introdução. Introdução. Introdução. Introdução. Os modelos de análise não respondem a algumas perguntas:
Diagramas de Interação Os modelos de análise não respondem a algumas perguntas: Como as operações do sistema são executadas internamente? A que classes estas operações internas pertencem? Quais objetos
Leia maisDesenvolvimento de Software Baseado em Componentes. Paulo C. Masiero
Desenvolvimento de Software Baseado em Componentes Paulo C. Masiero 1 Introdução Frustração com as promessas da Orientação a objetos em relação ao reuso de classes. Frameworks são uma solução para um domínio
Leia maisConcurso Público para provimento de cargo efetivo de Docentes. Edital 09/2015 INFORMÁTICA Campus Manhuaçu
Questão 01 Assinale o item abaixo que NÃO é caracterizado como uma vantagem do processo de desenvolvimento iterativo e incremental. a) Os riscos do projeto podem ser mais bem gerenciados. b) Soluciona
Leia maisAula 5 POO 1 Encapsulamento. Profa. Elaine Faria UFU
Aula 5 POO 1 Encapsulamento Profa. Elaine Faria UFU - 2019 Sobre o Material Agradecimentos Aos professores José Gustavo e Fabiano, por gentilmente terem cedido seus materiais. Os slides consistem de adaptações
Leia maisMAPEAMENTO OBJETO RELACIONAL
UNIDADEE Projeto de Banco de Dados Orientado a Objetos Unidade E 1. Introdução Ao concluir o estudo sobre BDOOs, você precisa ser capaz de implementar bancos de dados relacionais para aplicações que utilizam
Leia maisNotas de Aula 03: Introdução a Orientação a Objetos e a UML
Notas de Aula 03: Introdução a Orientação a Objetos e a UML Objetivos da aula: Introduzir os conceitos da Orientação à Objetos (O.O) Introduzir os conceitos da UML Relacionar os processos às ferramentas
Leia maisParadigmas de Programação. Java First-Tier: Aplicações. Orientação a Objetos em Java (I) Nomenclatura. Paradigma OO. Nomenclatura
Java First-Tier: Aplicações Orientação a Objetos em Java (I) Paradigmas de Programação Programação Funcional Programação Procedural Programação Orientada por Objetos Grupo de Linguagens de Programação
Leia maisIntrodução. Conceitos Básicos. Conceitos Básicos. Conceitos Básicos
Introdução Laboratório de Computação para Ciências Módulo II Prof. Guilherme Tavares de Assis Universidade Federal de Ouro Preto UFOP Instituto de Ciências Exatas e Biológicas ICEB Mestrado Profissional
Leia maisAula 2 POO 1 Introdução. Profa. Elaine Faria UFU
Aula 2 POO 1 Introdução Profa. Elaine Faria UFU - 2019 Sobre o Material Agradecimentos Aos professores José Gustavo e Fabiano, por gentilmente terem cedido seus materiais. Os slides consistem de adaptações
Leia maisINE 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 maisUNIVERSIDADE FEDERAL DE SÃO CARLOS. Aspecting: Abordagem para Migração de Sistemas OO para Sistemas OA
UNIVERSIDADE FEDERAL DE SÃO CARLOS CENTRO DE CIÊNCIAS EXATAS E DE TECNOLOGIA PROGRAMA DE PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO DISSERTAÇÃO DE MESTRADO Aspecting: Abordagem para Migração de Sistemas OO
Leia mais