CONEXÕES DE SABERES Amirton Chagas – Paola Accioly –

Slides:



Advertisements
Apresentações semelhantes
Introdução à Programação Orientada à Objetos Prof. Daniel Merli Lamosa Maio de 2002.
Advertisements

ANÁLISE DISCRIMINANTE
UML – MODELAÇÃO DA ESTRUTURA Professor Sandro Carvalho.
Orientação a Objetos Introdução. Objetos: o que são? Olhando o mundo real pode-se ver vários objetos: mesa, cadeiras, alunos, professores etc. Esses objetos.
Iniciação ao Java – Márcio F. Campos
Refatorações Experiência é aquela coisa maravilhosa que permite que você reconheça um erro tão logo o cometa novamente F.P. Jones.
Projetos.
Introdução ao paradigma de programação: Orientado a Objetos
Diagrama de Classes.
Linguagem de Programação II
Reutilização de Software
Programação orientada a objetos com Java
Aplicação de Programas de Qualidade em Serviços de Informação
Engenharia de Requisitos Requisito – sistema Caso de uso - usuário
Documentando con Javadoc
A modelação de sistemas enquanto ferramentas cognitivas.
TÉCNICAS DE PROGRAMAÇÃO II
Configuração de manutenção
DIAGRAMA DE COMPONENTES
Diagrama de Componentes
Introdução a programação (if669cc)
Orientação a Aspectos: π-PSF Killer Team Amirton Chagas, Elton Renan, José Dihego, Natanael Silva, Thiago Alexandre.
Conceitos básicos de orientação a objetos
DIAGRAMA DE CLASSE Modelagem de Software
TIC 10º ano Construir Bases de Dados
Programação Orientada à Objetos
Oberdan B. Ferreira Polimorfismo Oberdan B. Ferreira
Sistemas Distribuídos
Linguagem de Programação JAVA
ACCESS 2007 EDIMILSON JÚNIOR.
Paradigmas da Programação – Semestre 1 – Aula 2 Professores: Eduardo Mantovani Fábio de Paula.
Professor: Márcio Amador
Orientação a Objetos Parte I
Programação Orientada à Objetos
Prof. Silvestri – todos os direitos reservados SISTEMAS DISTRIBUIDOS Aula 5 Eduardo Silvestri
UML Diagrama de classes.
Curso de Aprendizado Industrial Desenvolvedor WEB Disciplina: Programação Orientada a Objetos I Professora: Cheli Mendes Costa Classes e Objetos em Java.
SISTEMAS DISTRIBUIDOS Aula 4
A abordagem de banco de dados para gerenciamento de dados
© Ricardo Pereira e Silva
Aula prática 14 Orientação a Objetos – C++ Parte 2
Análise Orientado aos Objetos Prof. Wolley W. Silva
Introdução às Java Threads
Introdução a Banco de Dados Aula 04
Generalização e herança Agregação e composição
Paradigmas da Programação – Semestre 2 – Aula 1 Professores: Fábio de Paula Santos Eduardo Mantovani
UML e a Ferramenta Astah
Linguagem de Modelagem Unificada
Bruno Inojosa MCP .NET Framework
Jobson Ronan Padrões GoF Jobson Ronan
Equipe: Bruno Barbosa Felipe Fernandes Waleska Dias.
CONEXÕES DE SABERES Amirton Chagas Paola Accioly
Classes abstratas São classes das quais não se pode instanciar objetos. São classes das quais não se pode instanciar objetos. Seu objetivo é ser herdada.
20/04/2017 Orientação a Objetos 1 1.
Projeto de Banco de Dados
Módulo II Capítulo 1: Orientação a Objetos
Palavras-Chaves Linguagem gráficas e utilizações de símbolos.
4 CONCEITOS BÁSICOS EM POO Dilvan Moreira.  Objetos  Classes  Herança  Polimorfismo Lembrando: 4 Conceitos Básicos.
INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA TOCANTINS Campus Araguaína Continuação Modelagem Orientada a Objetos Técnico Subsequente.
OCLE Object Constraint Language Environment Fábio Moura CIn-UFPE.
ISO9001:2000 para Software Professor: Alexandre Vasconcelos Equipe: Amanda Pimentel Börje Karlsson Danielly Karine Erika Pessoa Jorge Cavalcanti Jose Edson.
Prof.: Bruno Rafael de Oliveira Rodrigues. Herança Possibilita a uma classe usar campos ou métodos definidos em outra classe. Assim a classe pai possui.
Implementação Orientada a Objetos – Aula 08 Herança, sobrescrita de métodos e polimorfismo Prof. Danielle Martin Universidade de Mogi das Cruzes
Diagrama de Classes Herança Dependências.
Orientação a Objetos e Java Graduação em Ciência da Computação  Centro de Informática, UFPE Alexandre Mota
Java Como Programar, 8/E Deitel/Deitel, 8e. Java – Como programar Copyright © 2010 Pearson Education Slide 1.
Desenvolvendo sotfware com UML1 Visão Geral de Orientação a Objetos.
CIn-UFPE1 Projeto de Gerenciamento de Dados. CIn-UFPE2 Objetivos n Definir o que significa gerenciamento de dados do sistema; n Entender abordagens diferentes.
Engenharia de Software Orientada a Objetos Professor: Guilherme Timóteo Aula 3: – Modelagem de Classes (parte 2)
Herança em Java Curso: Informática Disciplina: Programação Orientada a Objetos Prof. Abrahão Lopes
Transcrição da apresentação:

CONEXÕES DE SABERES Amirton Chagas – Paola Accioly –

O PROGRAMA CONEXÕES DE SABERES O Conexões de Saberes oferece a jovens universitários de origem popular a possibilidade de desenvolver a capacidade de produzir conhecimentos científicos Criar capacidade de intervir em seu território de origem. Possibilita a avaliação dos estudantes sobre o impacto das políticas públicas desenvolvidas em espaços populares. Os participantes do programa recebem apoio financeiro e metodológico. 2

O PROGRAMA CONEXÕES DE SABERES Está implementado em diversas universidades do país, se adequando à realidade e as necessidades locais de cada instituição. Necessita de um sistema para gerenciar o seu funcionamento Não é necessário um sistema completamente diferente para cada universidade. Apesar das diferenças em cada local, existe uma vasta base comum a todas as instituições Possibilidade de criar uma Linha de Produtos de software para atender as necessidades específicas de cada instituição 3

VARIAÇÕES ESCOLHIDAS Os pontos de variação mais adequados ao estudo que nos propomos são a Interface Gráfica e as classes que envolvem Atividades De acordo com a instituição, existe ou não a necessidade de armazenar dados relativos a: Carga Horária da atividade Faixa etária dos participantes Código do projeto ao qual a atividade está vinculada A necessidade das instituições em torno dos dados acima variam desde “nenhum deles” até “todos eles”. Algumas instituições possuem Atividades de Formação e de Lazer, outras, apenas Atividades de Formação. 4

VARIAÇÃO 1 – INTERFACE GRÁFICA: CADASTRAR ATIVIDADE 5 Técnicas: Compilação Condicional A própria classe contém o código de geração dos campos e é injetado nela também todo o código para mostrá-los ou não. Refactor: Agrupou-se o código de criação dos campos para cada variação Parametrização por Arquivos de Propriedade Semelhante à CC, no entanto, pode ser mudado em runtime e não necessita em Java de ferramentas ou plug-ins não-nativos Mesmo refactor de CC

VARIAÇÃO 1 – INTERFACE GRÁFICA: CADASTRAR ATIVIDADE Orientação a Aspectos A definição de que se deve adicionar ou não os campos fica em arquivos separados, um para cada variação. Código da classe fica muito mais limpo e legível. Refactor: O código de criação dos componentes foi migrado da classe para os respectivos aspectos.

VARIAÇÃO 1 – INTERFACE GRÁFICA: CADASTRAR ATIVIDADE Mixins Cria-se classes com cada variação menor herdando da classe já existente Para os casos de necessidade de usar mais de uma das variações menores, cria-se uma classe com herança múltipla das classes previamente criadas. Refactor: O código de criação dos componentes foi migrado da superclasse para as respectivas subclasses.

VARIAÇÃO 1 – INTERFACE GRÁFICA: CADASTRAR ATIVIDADE Polimorfismo de Subtipo Cria-se uma subclasse da superclasse para cada variação, com todo o código necessário nela Duplicação de código  Para a escolha de qual classe usar, pode-se usar PFP, CC, makefiles... Nossa escolha: CC

VARIAÇÃO 1 – INTERFACE GRÁFICA: CADASTRAR ATIVIDADE Técnicas não usadas: Componentes O projeto não possui implementação de containers OSGi para podermos usar as ferramentas fornecidas PPP Não faria sentido usar PPP (Generics) no nosso caso, para a escolha de qual modelo de tela seria usado, apesar de ser possível implementar usando esta técnica CGT Seria uma técnica interessante para ser usada na variação escolhida Não tivemos sucesso ao utilizar a ferramenta velocity. AOM “Canhão para matar uma mosca” 9

VARIAÇÃO 2 – CLASSES QUE ENVOLVEM ATIVIDADE A Variação 2 se mostrou muito semelhante à variação 1. A principal diferença foi a possibilidade de usar PPP razoavelmente Para as outras técnicas, os comentários da variação 1 são os mesmos, inclusive de implementação. Apesar de, claro, os refactors terem sido diferentes, a essência deles foi a mesma.

VARIAÇÃO 2 – CLASSES QUE ENVOLVEM ATIVIDADE Parametrização por Polimorfismo Paramétrico Temos mais de um tipo de atividade. Criamos duas classes básicas filhas de Atividade. Algumas classes que usavam Atividade, passaram a receber o parâmetro do tipo de Atividade ao qual ela estaria associada Depois, usamos o objeto pelo tipo polimorficamente parametrizado anteriormente.

Dúvidas?