Reuso da Implementação Orientada a Aspectos do Padrão de Projeto Camada de Persistência

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

Download "Reuso da Implementação Orientada a Aspectos do Padrão de Projeto Camada de Persistência"

Transcrição

1 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 is granted to copy for the SugarLoafPlop 2004 conference. All other rights reserved. 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, {valter, 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 object-oriented 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. Observou-se 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 para a separação dos interesses de um sistema em unidades modulares e posterior composição (weaving) desses módulos em um sistema completo. Embora padrões de projeto não sejam considerados como requisitos nãofuncionais, 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 alcançados quando se utiliza o processo de reuso da implementação AO. Ao se notar as implementações OO e AO, observa-se, na segunda, a separação do código que implementa o padrão, possibilitando uma maior manutenibilidade dos sistemas. 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) 2

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

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

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

6 aberta. Essa inversão de dependência é o ponto fundamental que mantém a aplicação livre do código não-funcional. 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. 6

7 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 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. 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, [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

14 [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,

Reengenharia de Sistemas Orientados a Objetos para Sistemas Orientados a Aspectos

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

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

Leia mais

Aspect-Oriented Programming AOP. Comentários Sérgio Crespo

Aspect-Oriented Programming AOP. Comentários Sérgio Crespo Aspect-Oriented Programming AOP Comentários Sérgio Crespo Separation of Concerns O princípio de Separation of Concerns já é utilizado por engenheiros de software para o gerenciar a complexidade de sistemas

Leia mais

Avaliação das vantagens quanto à facilidade de manutenção e expansão de sistemas legados sujeitos à engenharia reversa e segmentação.

Avaliação das vantagens quanto à facilidade de manutenção e expansão de sistemas legados sujeitos à engenharia reversa e segmentação. Avaliação das vantagens quanto à facilidade de manutenção e expansão de sistemas legados sujeitos à engenharia reversa e segmentação Maria Istela Cagnin Rosângela A. D. Penteado Universidade Federal de

Leia mais

Identificação de Interesses Transversais: Uma Visão Geral

Identificação de Interesses Transversais: Uma Visão Geral Identificação de Interesses Transversais: Uma Visão Geral Paulo Afonso Parreira Júnior paulojunior@jatai.ufg.br 24 de Maio de 2013 Agenda Breve Histórico sobre Desenvolvimento de Software Separação de

Leia mais

POO e suas Limitações Introdução POA AspectJ: Conceitos Básicos Exemplo: Tracing Padrões de Projeto e POA

POO e suas Limitações Introdução POA AspectJ: Conceitos Básicos Exemplo: Tracing Padrões de Projeto e POA Lincoln S. Rocha (lincoln@great.ufc.br) POO e suas Limitações Introdução POA AspectJ: Conceitos Básicos Exemplo: Tracing Padrões de Projeto e POA Background Artigo do Kiczales 2 3 1 Objetivo da Programação?

Leia mais

Paradigmas de Linguagens de Programação

Paradigmas de Linguagens de Programação Paradigmas de Linguagens de Programação Faculdade Nova Roma Cursos de Ciências da Computação (6 Período) Prof Adriano Avelar - Site: wwwadrianoavelarcom Email: edsonavelar@yahoocombr PROGRAMAÇÃO ORIENTADA

Leia mais

2 Desenvolvimento de Software Orientado a Aspectos

2 Desenvolvimento de Software Orientado a Aspectos 2 Desenvolvimento de Software Orientado a Aspectos Separação de concerns é um princípio bem estabelecido da engenharia de software que diz que, para se dominar a complexidade do desenvolvimento de software,

Leia mais

Programação Orientada a Aspectos

Programação Orientada a Aspectos Programação Orientada a Aspectos Uma Breve Introdução Universidade Estadual do Oeste do Paraná Centro de Ciências Exatas e Tecnológicas Colegiado de Informática Prof. Luiz Antonio Roteiro Introdução Evolução

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

Uma Abordagem para Tratamento de Regras de Negócio nas Fases Iniciais do Desenvolvimento

Uma Abordagem para Tratamento de Regras de Negócio nas Fases Iniciais do Desenvolvimento Uma Abordagem para Tratamento de Regras de Negócio nas Fases Iniciais do Desenvolvimento Marco Antonio De Grandi, Valter Vieira de Camargo, Edmundo Sérgio Spoto Centro Universitário Eurípides de Marília

Leia mais

Um Arcabouço open source em Python para DBC com

Um Arcabouço open source em Python para DBC com Um Arcabouço open source em Python para DBC com Suporte à Evolução Dinâmica não Antecipada Yguaratã C. Cavacanti 1, Hyggo Oliveira de Almeida 1, Evandro Costa 2 1 Instituto de Computação Universidade Federal

Leia mais

Table 1. Dados do trabalho

Table 1. Dados do trabalho Título: Desenvolvimento de geradores de aplicação configuráveis por linguagens de padrões Aluno: Edison Kicho Shimabukuro Junior Orientador: Prof. Dr. Paulo Cesar Masiero Co-Orientadora: Prof a. Dr. Rosana

Leia mais

Framework utilizando reflexão e aspectos para persistência de objetos em java

Framework utilizando reflexão e aspectos para persistência de objetos em java Framework utilizando reflexão e aspectos para persistência de objetos em java Antonio Carlos Rolloff (UNIPAR) acrolloff@gmail.com Arthur Cattaneo Zavadski (UNIPAR) arthur@datacoper.com.br Maria Aparecida

Leia mais

7 Trabalhos Relacionados A idéia é tentar dar todas as informações que ajudem os outros a julgar o valor da sua contribuição; não apenas as informações que levem o julgamento a uma direção em particular.

Leia mais

Banco de Dados. Sérgio Luiz Ruivace Cerqueira sergioruivace@gmail.com

Banco de Dados. Sérgio Luiz Ruivace Cerqueira sergioruivace@gmail.com Banco de Dados Sérgio Luiz Ruivace Cerqueira sergioruivace@gmail.com Roteiro Mapeamento de objetos para modelo relacional Estratégias de persistência Persistência JDBC Mapeando Objetos para o Modelo Relacional

Leia mais

Programação Orientada a Aspectos Aplicada. Charles Wellington de Oliveira Fortes chalkmaster@gmail.com

Programação Orientada a Aspectos Aplicada. Charles Wellington de Oliveira Fortes chalkmaster@gmail.com Programação Orientada a Aspectos Aplicada. Charles Wellington de Oliveira Fortes chalkmaster@gmail.com Resumo: Demonstrar de forma clara e prática como a Programação Orientada a Aspectos pode ajudar a

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

Etc & Tal. Volume 2 - Número 1 - Abril 2009 SBC HORIZONTES 44

Etc & Tal. Volume 2 - Número 1 - Abril 2009 SBC HORIZONTES 44 Armazenando Dados em Aplicações Java Parte 2 de 3: Apresentando as opções Hua Lin Chang Costa, hualin@cos.ufrj.br, COPPE/UFRJ. Leonardo Gresta Paulino Murta, leomurta@ic.uff.br, IC/UFF. Vanessa Braganholo,

Leia mais

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

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

Leia mais

ESPECIFICAÇÃO E VERIFICAÇÃO DE REGRAS DE DESIGN EM PROGRAMAS JAVA E ASPECTJ

ESPECIFICAÇÃO E VERIFICAÇÃO DE REGRAS DE DESIGN EM PROGRAMAS JAVA E ASPECTJ VII CONGRESSO DE INICIAÇÃO CIENTÍFICA DA UNIVERSIDADE FEDERAL DE CAMPINA GRANDE PIBIC/CNPq/UFCG-2010 ESPECIFICAÇÃO E VERIFICAÇÃO DE REGRAS DE DESIGN EM PROGRAMAS JAVA E ASPECTJ Solon Barbosa de Aguiar

Leia mais

Um Perfil UML para Projeto de Frameworks Transversais

Um Perfil UML para Projeto de Frameworks Transversais Um Perfil UML para Projeto de Frameworks Transversais José Uetanabara Júnior *, Valter Vieira de Camargo # *Centro Universitário Eurípides de Marília UNIVEM Marília São Paulo, Caixa Postal 2041 CEP 17.525-901

Leia mais

MARCOS DE MORAES BRASIL UMA ANÁLISE DE ALGUMAS ABORDAGENS DE MODELAGEM ORIENTADAS A ASPECTOS

MARCOS DE MORAES BRASIL UMA ANÁLISE DE ALGUMAS ABORDAGENS DE MODELAGEM ORIENTADAS A ASPECTOS FUNDAÇÃO DE ENSINO EURÍPIDES SOARES DA ROCHA CENTRO UNIVERSITÁRIO EURÍPIDES DE MARÍLIA UNIVEM FACULDADE DE CIÊNCIA DA COMPUTAÇÃO MARCOS DE MORAES BRASIL UMA ANÁLISE DE ALGUMAS ABORDAGENS DE MODELAGEM ORIENTADAS

Leia mais

Framework para jogos de cartas

Framework para jogos de cartas Framework para jogos de cartas por André Luís Knabben e Thiago Robert Professor Doutor Ricardo Pereira e Silva Orientador Resumo Projetar artefatos de software visando a reusabilidade é uma tarefa complexa.

Leia mais

Banco de Dados. Introdução. João Eduardo Ferreira Osvaldo Kotaro Takai. jef@ime.usp.br DCC-IME-USP

Banco de Dados. Introdução. João Eduardo Ferreira Osvaldo Kotaro Takai. jef@ime.usp.br DCC-IME-USP Banco de Dados Introdução João Eduardo Ferreira Osvaldo Kotaro Takai jef@ime.usp.br DCC-IME-USP Importância dos Bancos de Dados A competitividade das empresas depende de dados precisos e atualizados. Conforme

Leia mais

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

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

Leia mais

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

MOR: Uma Ferramenta para o Mapeamento Objeto-Relacional em Java

MOR: Uma Ferramenta para o Mapeamento Objeto-Relacional em Java MOR: Uma Ferramenta para o Mapeamento Objeto-Relacional em Java Leonardo Gresta Paulino Murta Gustavo Olanda Veronese Cláudia Maria Lima Werner {murta, veronese, werner}@cos.ufrj.br COPPE/UFRJ Programa

Leia mais

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

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

Leia mais

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

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

Leia mais

Análise e Projeto Orientados por Objetos

Análise e Projeto Orientados por Objetos Análise e Projeto Orientados por Objetos Aula 02 Análise e Projeto OO Edirlei Soares de Lima Análise A análise modela o problema e consiste das atividades necessárias para entender

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 10 Persistência de Dados

Leia mais

Figura 1. A Classe Java

Figura 1. A Classe Java Conexã o com MySQL Connection Factory Para criar as conexões com o banco de dados será utilizado um padrão chamado Factory, onde através dele se terá uma única classe que proverá uma fábrica de conexão

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

3.5. Cuidado com o modelo anêmico

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

Leia mais

MAPEAMENTO OBJETO RELACIONAL: UM ESTUDO DE CASO

MAPEAMENTO OBJETO RELACIONAL: UM ESTUDO DE CASO MAPEAMENTO OBJETO RELACIONAL: UM ESTUDO DE CASO UTILIZANDO O HIBERNATE Rafael Laurino GUERRA, Dra. Luciana Aparecida Martinez ZAINA Faculdade de Tecnologia de Indaiatuba FATEC-ID 1 RESUMO Este artigo apresenta

Leia mais

Customização de Software como um Meio para o Desenvolvimento de Sistemas de Software

Customização de Software como um Meio para o Desenvolvimento de Sistemas de Software Customização de Software como um Meio para o Desenvolvimento de Sistemas de Software Thiago Bianchi 1 Elisa Yumi Nakagawa 2 1 IBM - International Business Machines 04753-080, São Paulo, SP, Brazil tbianchi@br.ibm.com

Leia mais

PROVA DE NÍVEL SUPERIOR. CARGO: Técnico de Nível Superior Júnior II - TECNOLOGIA DA INFORMAÇÃO

PROVA DE NÍVEL SUPERIOR. CARGO: Técnico de Nível Superior Júnior II - TECNOLOGIA DA INFORMAÇÃO PROVA DE NÍVEL SUPERIOR CARGO: Técnico de Nível Superior Júnior II - TECNOLOGIA DA INFORMAÇÃO 1. O ambiente Delphi suporta o desenvolvimento de aplicações orientadas a objetos por meio da linguagem Object

Leia mais

Um Processo para Desenvolvimento de Aplicações Web Baseado em Serviços. Autores: Fábio Zaupa, Itana Gimenes, Don Cowan, Paulo Alencar e Carlos Lucena

Um Processo para Desenvolvimento de Aplicações Web Baseado em Serviços. Autores: Fábio Zaupa, Itana Gimenes, Don Cowan, Paulo Alencar e Carlos Lucena Um Processo para Desenvolvimento de Aplicações Web Baseado em Serviços Autores: Fábio Zaupa, Itana Gimenes, Don Cowan, Paulo Alencar e Carlos Lucena Tópicos Motivação e Objetivos LP e SOA Processo ADESE

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

Engenharia de Software I

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

Leia mais

Frameworks. Pasteur Ottoni de Miranda Junior

Frameworks. Pasteur Ottoni de Miranda Junior Frameworks Pasteur Ottoni de Miranda Junior 1-Definição Apesar do avanço das técnicas de desenvolvimento de software, a construção de software ainda é um processo extremamente complexo.a reutilização tem

Leia mais

PRODUTO 1 (CONSTRUÇÃO DE PORTAL WEB)

PRODUTO 1 (CONSTRUÇÃO DE PORTAL WEB) RELATÓRIO DE ENTREGA DO PRODUTO 1 (CONSTRUÇÃO DE PORTAL WEB) PARA A ELABORAÇÃO DOS PLANOS MUNICIPAIS DE GESTÃO INTEGRADA DE RESÍDUOS SÓLIDOS PMGIRS PARA OS MUNICÍPIOS DE NOVO HORIZONTE, JUPIÁ, GALVÃO,

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

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

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

Padrão Arquitetura em Camadas

Padrão Arquitetura em Camadas Padrão Arquitetura em Camadas Universidade Católica de Pernambuco Ciência da Computação Prof. Márcio Bueno poonoite@marciobueno.com Fonte: Material da Profª Karina Oliveira Definição Estimula a organização

Leia mais

DOCUMENTO DE REQUISITOS

DOCUMENTO DE REQUISITOS DOCUMENTO DE REQUISITOS ID documento: Data: / / Versão : Responsável pelo documento: ID Projeto: HISTÓRICO DE REVISÕES Data de criação/ atualização Descrição da(s) Mudança(s) Ocorrida(s) Autor Versão do

Leia mais

Reuso. Curso de Especialização DEINF - UFMA Desenvolvimento Orientado a Objetos Prof. Geraldo Braz Junior

Reuso. Curso de Especialização DEINF - UFMA Desenvolvimento Orientado a Objetos Prof. Geraldo Braz Junior Reuso Curso de Especialização DEINF - UFMA Desenvolvimento Orientado a Objetos Prof. Geraldo Braz Junior Reutilização de Software Na maioria das áreas de engenharia de software, sistemas são desenvolvidos

Leia mais

Tipos de dados complexos e objectos Tipos de dados estruturados e herança em SQL Herança de tabelas Matrizes e multi-conjuntos em SQL Identidade de

Tipos de dados complexos e objectos Tipos de dados estruturados e herança em SQL Herança de tabelas Matrizes e multi-conjuntos em SQL Identidade de Capítulo 8: BDs Objecto-Relacional Tipos de dados complexos e objectos Tipos de dados estruturados e herança em SQL Herança de tabelas Matrizes e multi-conjuntos em SQL Identidade de Objectos e Referência

Leia mais

Introdução à Engenharia de Software

Introdução à Engenharia de Software Introdução à Engenharia de Software Professor: Rômulo César romulodandrade@gmail.com www.romulocesar.com.br Imagem Clássica Objetivo da aula Depois desta aula você terá uma visão sobre o que é a engenharia

Leia mais

HIBERNATE EM APLICAÇÃO JAVA WEB

HIBERNATE EM APLICAÇÃO JAVA WEB HIBERNATE EM APLICAÇÃO JAVA WEB Raul Victtor Barbosa Claudino¹, Ricardo Ribeiro Rufino¹ ¹Universidade Paranaense (Unipar) Paranavaí PR Brasil victtor.claudino@gmail.com, ricardo@unipar.br Resumo: Este

Leia mais

Use a Cabeça! FREEMAN, Eric e Elisabeth. HTML com CSS e XHTML BASHMAN, Brian / SIERRA Kathy / BATES, Bert. Servlets & JSP

Use a Cabeça! FREEMAN, Eric e Elisabeth. HTML com CSS e XHTML BASHMAN, Brian / SIERRA Kathy / BATES, Bert. Servlets & JSP Use a Cabeça! FREEMAN, Eric e Elisabeth. HTML com CSS e XHTML BASHMAN, Brian / SIERRA Kathy / BATES, Bert. Servlets & JSP Software cliente: browser e outros Protocolo HTTP Infraestrutura de transporte

Leia mais

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

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

Leia mais

Persistir os Metadados dos Modelos de Objetos de Sistemas Distribuídos e Adaptáveis.

Persistir os Metadados dos Modelos de Objetos de Sistemas Distribuídos e Adaptáveis. Persistir os Metadados dos Modelos de Objetos de Sistemas Distribuídos e Adaptáveis. Warley R. de Almeida, Maurício G.V. Ferreira Instituto Nacional de Pesquisas Espaciais (INPE) Av. dos Astronautas,1.758

Leia mais

5 Um Modelo Generativo Orientado a Aspectos

5 Um Modelo Generativo Orientado a Aspectos 71 5 Um Modelo Generativo Orientado a Aspectos Nesse capítulo é apresentado um modelo generativo orientado a aspectos que é usado para instanciação de variabilidades OO e OA encontradas em arquiteturas

Leia mais

CURSO DESENVOLVEDOR JAVA Edição Intensiva de Férias

CURSO DESENVOLVEDOR JAVA Edição Intensiva de Férias CURSO DESENVOLVEDOR JAVA Edição Intensiva de Férias O curso foi especialmente planejado para os profissionais que desejam trabalhar com desenvolvimento de sistemas seguindo o paradigma Orientado a Objetos

Leia mais

Programas eram lineares e com poucos módulos (Programação estruturada) Aumento da complexidade dos sistemas e difícil reusabilidade dos mesmos

Programas eram lineares e com poucos módulos (Programação estruturada) Aumento da complexidade dos sistemas e difícil reusabilidade dos mesmos OO -Objetos, classes, atributos, métodos, estado, comportamento e identidade (Slide) Prof. Bruno Gomes bruno.gomes@ifrn.edu.br Programação Orientada a Objetos Introdução Programas eram lineares e com poucos

Leia mais

Roteiro 2 Conceitos Gerais

Roteiro 2 Conceitos Gerais Roteiro 2 Conceitos Gerais Objetivos: UC Projeto de Banco de Dados Explorar conceitos gerais de bancos de dados; o Arquitetura de bancos de dados: esquemas, categorias de modelos de dados, linguagens e

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

Armazenamento e Pesquisa de Topic Maps em Banco de Dados Relacional

Armazenamento e Pesquisa de Topic Maps em Banco de Dados Relacional Armazenamento e Pesquisa de Topic Maps em Banco de Dados Relacional Lucas Indrusiak, Renato Azevedo, Giovani R. Librelotto UNIFRA Centro Universitário Franciscano Rua dos Andradas, 1614 97.010-032 Santa

Leia mais

ABORDAGEM DE FRAMEWORKS PARA JSF QUE AUXILIAM O DESENVOLVIMENTO DE SOFTWARE

ABORDAGEM DE FRAMEWORKS PARA JSF QUE AUXILIAM O DESENVOLVIMENTO DE SOFTWARE ABORDAGEM DE FRAMEWORKS PARA JSF QUE AUXILIAM O DESENVOLVIMENTO DE SOFTWARE Amarildo Aparecido Ferreira Junior 1, Ricardo Ribeiro Rufino 1 ¹Universidade Paranaense (Unipar) Paranavaí PR Brasil aapfjr@gmail.com

Leia mais

Documento de Arquitetura

Documento de Arquitetura Documento de Arquitetura A2MEPonto - SISTEMA DE PONTO ELETRÔNICO A2MEPonto - SISTEMA DE PONTO ELETRÔNICO #1 Pág. 1 de 11 HISTÓRICO DE REVISÕES Data Versão Descrição Autor 28/10/2010 1 Elaboração do documento

Leia mais

OUTROS PARADIGMAS: PROGRAMAÇÃO

OUTROS PARADIGMAS: PROGRAMAÇÃO OUTROS PARADIGMAS: PROGRAMAÇÃO CONCORRENTE, MODELO DE DADOS RELACIONAL (SQL), REDES DE PETRI, ORIENTAÇÃO A ASPECTOS Luenne Nailam e Uendson Teles PROGRAMAÇÃO CONCORRENTE PROGRAMA O que é um Programa? O

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

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

Ciência da Computação ENGENHARIA DE SOFTWARE. Análise dos Requisitos de Software

Ciência da Computação ENGENHARIA DE SOFTWARE. Análise dos Requisitos de Software Ciência da Computação ENGENHARIA DE SOFTWARE Análise dos Requisitos de Software Prof. Claudinei Dias email: prof.claudinei.dias@gmail.com Roteiro Introdução Tipos de requisitos Atividades Princípios da

Leia mais

Almox Express Especificação de Requisitos

Almox Express Especificação de Requisitos 1. Introdução Almox Express Especificação de Requisitos Este documento descreve um sistema de gerenciamento de almoxarifado, denominado de Almox Express, a ser desenvolvido por um grupo de estudo. Nele

Leia mais

Autor: Ricardo Francisco Minzé Júnior - ricardominze@yahoo.com.br Desenvolvendo aplicações em camadas com PHP 5.

Autor: Ricardo Francisco Minzé Júnior - ricardominze@yahoo.com.br Desenvolvendo aplicações em camadas com PHP 5. Desenvolvendo aplicações em camadas com PHP 5. Talvez a primeira vista você ache estranha a palavra Camada em programação, mas o que vem a ser Camada? Segundo o dicionário: Camada 1 - Qualquer matéria

Leia mais

Evolução de Software e Refatoração

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

Leia mais

Roteiro. Conceitos e Arquitetura de Sistemas de Banco de Dados. Conceitos e Arquiteturas de Sistemas de Banco de Dados. BCC321 - Banco de Dados I

Roteiro. Conceitos e Arquitetura de Sistemas de Banco de Dados. Conceitos e Arquiteturas de Sistemas de Banco de Dados. BCC321 - Banco de Dados I Roteiro Conceitos e Arquitetura de Sistemas de Banco de Dados Luiz Henrique de Campos Merschmann Departamento de Computação Universidade Federal de Ouro Preto luizhenrique@iceb.ufop.br www.decom.ufop.br/luiz

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

Separação de Interesses Programação Estruturada e Programação Orientada a Objetos Entrelaçamento de Código Espalhamento de Código

Separação de Interesses Programação Estruturada e Programação Orientada a Objetos Entrelaçamento de Código Espalhamento de Código Análise e Projeto Orientados a Aspectos Alcides Pamplona alcides.pamplona@gmail.com Tópicos Separação de Interesses Programação Estruturada e Entrelaçamento de Código Espalhamento de Código 1 Separação

Leia mais

sobre rogério gonçalves gerente de projetos > digitale agência digital rogerio@digitale.com.br h7p://www.digitale.com.br h7p://leveme.

sobre rogério gonçalves gerente de projetos > digitale agência digital rogerio@digitale.com.br h7p://www.digitale.com.br h7p://leveme. sobre rogério gonçalves gerente de projetos > digitale agência digital rogerio@digitale.com.br h7p://www.digitale.com.br h7p://leveme.la/rogerio definição - é uma forma de programar e organizar um sistema

Leia mais

JPA: Persistência padronizada em Java

JPA: Persistência padronizada em Java JPA: Persistência padronizada em Java FLÁVIO HENRIQUE CURTE Bacharel em Engenharia de Computação flaviocurte.java@gmail.com Programação Orientada a Objetos X Banco de Dados Relacionais = Paradigmas diferentes

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 Gerenciador de Hotel. Adriano Douglas Girardello. Ana Paula Fredrich. Tiago Alexandre Schulz Sippert

Sistema Gerenciador de Hotel. Adriano Douglas Girardello. Ana Paula Fredrich. Tiago Alexandre Schulz Sippert UNIOESTE Universidade Estadual do Oeste do Paraná CENTRO DE CIÊNCIAS EXATAS E TECNOLÓGICAS Colegiado de Informática Curso de Bacharelado em Informática Sistema Gerenciador de Hotel Adriano Douglas Girardello

Leia mais

UM MODELO DE QUALIDADE PARA AVALIAR DOCUMENTOS DE REQUISITOS ORIENTADOS A ASPECTOS

UM MODELO DE QUALIDADE PARA AVALIAR DOCUMENTOS DE REQUISITOS ORIENTADOS A ASPECTOS Desarrollo de Software Orientado a Aspectos, DSOA 2006 Asociado a XV Jornadas de Ingeniería del Software y Bases de Datos J. Araújo, J. Hernández, E. Navarro y M. Pinto (Eds) Sitges (Barcelona), Octubre

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

Pós Graduação Engenharia de Software

Pós Graduação Engenharia de Software Pós Graduação Engenharia de Software Ana Candida Natali COPPE/UFRJ Programa de Engenharia de Sistemas e Computação FAPEC / FAT Estrutura do Módulo Parte 1 QUALIDADE DE SOFTWARE PROCESSO Introdução: desenvolvimento

Leia mais

A Semi-Automatic Strategy to Identify Crosscutting Concerns in PL-AOVgraph Requirement Models

A Semi-Automatic Strategy to Identify Crosscutting Concerns in PL-AOVgraph Requirement Models Universidade Federal do Rio Grande do Norte Departamento de Informática e Matemática Aplicada Natal/RN - Brasil A Semi-Automatic Strategy to Identify Crosscutting Concerns in PL-AOVgraph Requirement Models

Leia mais

Resumo: Perguntas a fazer ao elaborar um projeto arquitetural

Resumo: Perguntas a fazer ao elaborar um projeto arquitetural Resumo: Perguntas a fazer ao elaborar um projeto arquitetural Sobre entidades externas ao sistema Quais sistemas externos devem ser acessados? Como serão acessados? Há integração com o legado a ser feita?

Leia mais

Engenharia Reversa e Reengenharia

Engenharia Reversa e Reengenharia Engenharia Reversa e Reengenharia SCE 186 Engenharia de Software Profa Rosana T. Vaccare Braga (material adaptado a partir do concedido pela Profa.: Rosângela Penteado, DC - UFSCar) Fases Genéricas do

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

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

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

Leia mais

SISTEMA DE WORKFLOW PARA MODELAGEM E EXECUÇÃO DE PROCESSOS DE SOFTWARE. Aluno: Roberto Reinert Orientador: Everaldo A. Grahl

SISTEMA DE WORKFLOW PARA MODELAGEM E EXECUÇÃO DE PROCESSOS DE SOFTWARE. Aluno: Roberto Reinert Orientador: Everaldo A. Grahl SISTEMA DE WORKFLOW PARA MODELAGEM E EXECUÇÃO DE PROCESSOS DE SOFTWARE Aluno: Roberto Reinert Orientador: Everaldo A. Grahl Roteiro de apresentação Introdução Objetivos Fundamentação Teórica Workflow Processo

Leia mais

Desenvolvendo Aplicações Web com NetBeans

Desenvolvendo Aplicações Web com NetBeans Desenvolvendo Aplicações Web com NetBeans Aula 3 Cap. 4 Trabalhando com Banco de Dados Prof.: Marcelo Ferreira Ortega Introdução O trabalho com banco de dados utilizando o NetBeans se desenvolveu ao longo

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

Eduardo Bezerra. Editora Campus/Elsevier

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

Leia mais

PROGRAMAÇÃO MVC E ZEND FRAMEWORK

PROGRAMAÇÃO MVC E ZEND FRAMEWORK PROGRAMAÇÃO MVC E ZEND FRAMEWORK MVC PROGRAMMING AND ZEND FRAMEWORK Rodolfo Vinícius Moimas Dias Centro Universitário Filadélfia de Londrina UniFil Rafael Francovig Cavicchioli Centro Universitário Filadélfia

Leia mais

UML - Unified Modeling Language

UML - Unified Modeling Language UML - Unified Modeling Language Casos de Uso Marcio E. F. Maia Disciplina: Engenharia de Software Professora: Rossana M. C. Andrade Curso: Ciências da Computação Universidade Federal do Ceará 24 de abril

Leia mais

Lista de Contas: Assinatura. Lista de Contas. Listas de Contas: Descrição. Listas de Contas: Descrição. Listas de Contas: Descrição

Lista de Contas: Assinatura. Lista de Contas. Listas de Contas: Descrição. Listas de Contas: Descrição. Listas de Contas: Descrição Lista de Contas Lista de Contas: Assinatura null Quais são os métodos necessários? class ListaDeContas { void inserir (Conta c) { void retirar (Conta c) { Conta procurar (String num) { Listas de Contas:

Leia mais

Prova de pré-requisito

Prova de pré-requisito Prova de pré-requisito Curso Python e Django 1. Ao se acessar o site www.google.com qual comando e parâmetros são enviados para o servidor pelo navegador? a. GET / b. GET www.google.com c. PAGE index.html

Leia mais

Módulo 5 JPATransaction Camadas Turma Turma TurmaBC .business @BusinessController TurmaBC TurmaBC TurmaBC

Módulo 5 JPATransaction Camadas Turma Turma TurmaBC .business @BusinessController TurmaBC TurmaBC TurmaBC Módulo 5 No módulo anterior adaptamos nosso projeto para persistir as informações no banco de dados utilizando as facilidades da extensão demoiselle-jpa. Experimentamos o controle transacional do Framework

Leia mais

Hoje é inegável que a sobrevivência das organizações depende de dados precisos e atualizados.

Hoje é inegável que a sobrevivência das organizações depende de dados precisos e atualizados. BANCO DE DADOS Universidade do Estado de Santa Catarina Centro de Ciências Tecnológicas Departamento de Ciência da Computação Prof. Alexandre Veloso de Matos alexandre.matos@udesc.br INTRODUÇÃO Hoje é

Leia mais

Concepção e Elaboração

Concepção e Elaboração UNIVERSIDADE ESTADUAL PAULISTA INSTITUTO DE BIOCIÊNCIAS, LETRAS E CIÊNCIAS EXATAS DEPARTAMENTO DE CIÊNCIAS DE COMPUTAÇÃO E ESTATÍSTICA Análise e Projeto Orientado a Objetos Concepção e Elaboração Estudo

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

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

2. Migração de Sistemas OO para OA

2. Migração de Sistemas OO para OA Uma Abordagem para Reengenharia de Sistemas implementados em Java para AspectJ Daniel Kawakami 1, Ricardo Argenton Ramos 2, Rosângela Ap. Penteado 1 1 Departamento de Computação Universidade Federal de

Leia mais