Nos últimos anos houve um aumento no número de empresas que utilizam sistemas informatizados, e com o crescimento na demanda desse ramo, além dos avanços tecnológicos dessa área, empresas que possuíam softwares implementados com linguagens e plataformas antigas e ultrapassadas tiveram que se adequar às novas tecnologias para poder competir com a concorrência.
As empresas buscam cada vez mais aprimorar seus sistemas, pois nos dias de hoje, tempo é dinheiro, e cada vez mais cresce o número de concorrentes no mundo dos negócios
Como para as empresas é muito difícil se desfazer de seus sistemas, pois os mesmos possuem todas as suas regras de negócios, sendo impossível recuperar em outro lugar o trabalho de todos esses anos realizado em seus sistemas, algumas empresas preferem aprimorar ou acrescentar funcionalidades ao invés de substituí-los, através da reengenharia.
Através da reengenharia de software, conforme demonstrado neste trabalho, torna-se possível recuperar e/ou modificar o sistema com base em um sistema já existente. O sistema escolar web, utilizado como exemplo neste projeto, originou-se de um sistema anteriormente desktop, que estava muito defasado em relação ao seu propósito inicial, pois o mesmo não possuía funcionalidades necessárias para a escola, além de ser monousuário.
Durante o processo de desenvolvimento do novo projeto foram encontradas algumas dificuldades, como a escassez de material sobre o uso da reengenharia de software na prática, pois a mesma ainda não é muito utilizada, apresentando um alto custo e um grande esforço para seus desenvolvedores, pelo fato da maioria dos sistemas antigos possuírem uma documentação defasada. Outra dificuldade foi o desenvolvimento do projeto, pois o sistema antigo não possuía muitas funcionalidades, desta forma se tornou necessário acrescentar diversas funcionalidades como o cadastro de cursos, disciplinas, turmas, matriz escolar, componente matriz, horários e a geração de horário de cada turma.
O Sistema Escolar web ainda se encontra em forma de protótipo, pois o mesmo ainda está em fase de teste e modificações, devendo vir a incluir o tratamento de algumas exceções, erros, e agregação de funcionalidades.
Sugere-se então para a próxima etapa do projeto, a criação de uma tela de login, onde cada usuário terá a sua área de acesso restrita, e também a inclusão da opção de imprimir nas telas de cadastro e consulta.
A realização deste projeto foi uma forma de contribuir um pouco mais com a área tecnológica mostrando que a reengenharia é uma forma de alterar e melhorar o sistema existente, reaproveitando seu conhecimento. Porém, sua utilização se torna mais útil em grandes empresas, pois otimiza tempo, custo, e permite reaproveitar além das regras de negócio e modelos já existentes, o código fonte de grande sistemas, permitindo a redução de esforço e custo no desenvolvimento de um novo sistema.
Mesmo diante de todo esforço empregado na realização deste trabalho como o estudo aprofundado dos processos da reengenharia de software e a criação do novo sistema escolar web e pelas dificuldades encontradas, como podemos citar a escassez de material no ramo acadêmico sobre reengenharia de software, foi muito gratificante e proveitoso sua realização, pois adquirimos muito conhecimento e prática no ramo da reengenharia de software e desenvolvimento para web.
BIBLIOGRAFIA
BEHFOROOZ, Ali; HUDSON, Frederick. Software engineering fundamentals. New York:
Oxford University Press, 1996.
BENEDUSI, P.; CIMITILE, A.; CARLINI, U. Reverse Engineering Processes, Design Docu- ment Production, and Structure Charts. Journal Systems and Software, v. 19, 1992, p. 225- 245.
BENNETT, K. H. Automated Support of Software Maintenance. Information and Software Technology, v. 33, n.1, 1991, p. 74-85.
BENNETT, K. H. Legacy Systems: coping with success. IEEE Software, v. 12, n. 1, 1995, p.
19-23.
BIGGERSTAFF, T. J. Design Recovery for Maintenance and Reuse. IEEE Computer, v. 22, n. 7, 1989, p. 36-49.
CANFORA, G.; CIMITILE, A.; MUNRO, M. RE2: Reverse-engineering and Reuse Reengineering. Journal of Software Maintenance: Research and Practice, v. 6, n. 2, 1994, p.
53-72.
CHIKOFSKY, E. J. e CROSS II, J. H. Reverse Engineering and Design Recovery: A Taxonomy. IEEE Software, v. 7, n. 1, 1990, p. 13-17.
CHIN, D. N.; QUILICI, A. DECODE: A Cooperative Program Understanding Environment.
Journal of Software Maintenance: Research and Practice, v. 8, n. 1, 1996, p. 3-33.
COLEMAN, D.; ARNOLD, P.; BODOFF, S.; DOLLIN, C.; GILCHRIST, H.; HAYES, F. e JEREMAES, P. Object-Oriented Development: THE FUSION METHOD. Englewood Cliffs, New Jersey: Prentice Hall, 1994.
COLEMANN, D. Desenvolvimento Orientado A Objetos. O Método Fusion. Editora Campus, 1996.
COSTA, R. M. Aplicação do Método de Engenharia Reversa FUSION-RE/I na Recuperação da Funcionalidade da Ferramenta de Teste PROTEUM. São Carlos: ICMSC-USP, 1997.
Dissertação (mestrado).
FELTRIM, Valéria Delisandra; FORTES, Renata Pontin; SILVA Willian Francisco; Aspectos de Validação do Método de Engenharia Reversa Fusion-RE/I aplicado a um Sistema Hipermí- dia; São Carlos - São Paulo: 2002.
GALL, H. e KLOSCH, R. Finding Objects in Procedural Programs: An Alternative Approach. In: Proceedings of Second Working Conference on Reverse Engineering.
Monterey, EUA: 1995, p. 208-216.
HAMMER, M.; CHAMPY, J. Reengenharia: revolucionando a empresa em função dos clientes, da concorrência e das grandes mudanças da gerência. Rio de Janeiro: Campus, 1994.
HARANDI, M. T.; NING, J. Q. Knowledge-Based Program Analysis. IEEE Software v. 7, n.
1, 1990, p. 74-81.
JACOBSON, I.; LINDSTROM, F. Reegineering of Old Systems to an Object-Oriented Architecture. SIGPLAN Notices, v. 26, n. 11, 1991, p. 340-350.
KRAMER, C.; PRECHELT, L. Design Recovery by Automated Search for Structural Design Patterns in Object-Oriented Software. In: Proceedings of Third Working Conference on Reverse Engineering, Monterey, EUA, 1996, p. 208-215.
LAYZELL, P. J.; FREEMAN, M. J.; BENEDUSI, P. Improving Reverse-engineering through the Use of Multiple Knowledge Sources. Journal of Software Maintenance: Research and Practice, v. 7, n. 4, 1995, p. 279-299.
LEHMAN, M. M. Programs, Life-Cycles, and the Laws of program Evolution. Proc. IEEE, 1980, p. 1060-1076.
NEWCOMB, P. e KOTIK G. Reengineering Procedural into Object-Oriented Systems. In:
Proceedings of Second Conference on Reverse Engineering, Toronto, Canada, 1995, p. 237- 249.
OMAN, P.W. Maintenance Tools. IEEE Software, v. 7, n. 3, 1990, p. 59-65.
OSBORNE,W.M.; CHIKOFSKY, E.J. Fitting Pieces to the Maintenance Puzzle. IEEE Software, v. 7, n. 1, 1990, p. 11-12.
PREMERLANI, W. J. e BLAHA, M. R. An Approach for Reverse Engineering of Relational Databases. Communications of the ACM, v. 37, n. 5, 1994, p. 42-49.
PRESSMAN, R.S., Engenharia de Software, Trad., McGraw Hill, 6º ed. , São Paulo, 2006.
RAMAMOORTHY, C. V.; TSAI, W. Advances in Software Engineering. IEEE Computer, v.
29, n. 10, 1996, p. 47-58.
REKOFF Jr., M. G. On Reverse Engineering. IEEE Transaction on Systems. Man, and Cybernetics, v. 15, n. 2, março/abril, 1985.
RUGABER, S. e WILLS, L. M. Creating a Research Infrastructure for Reengineering. In:
Proceedings of Third Working Conference on Reverse Engineering, Monterey, EUA, 1996, p.
98-102.
RUGABER, S. et al. Recognizing Design Decision in Programs. IEEE Software, v. 7, n. 1, 1990, p. 46-54.
SAGE, A.P. Systems Engineering and Systems Management for Reengineering. Journal Systems and Software, v. 30, n. 1, 1995, p. 3-25.
SAMUELSON, P. Reverse-Engineering Someone Else’s Software: Is It Legal? IEEE Software, v.1, n. 1, 1990, p. 90-96.
SNEED, H. M. e NYÁRY, E. Extracting Object-Oriented Specification from Procedurally Oriented Programs. In: Proceedings of Second Conference on Reverse Engineering. Toronto, Canada, 1995, p. 217-226.
SNEED, H.M. Object-Oriented COBOL Recycling. In: Proceedings of Third Working Conference on Reverse Engineering. Monterey, EUA, 1996, p. 169-178.
SNEED, H. M. Migration of Procedurally Oriented COBOL Programs in an Object-Oriented Architeture. In: Proceedings of Conference on Software Maintenance, Orlando, EUA, 1992, p. 105-116.
SOMMERVILLE, I. Software Engineering (International Computer Science Series). 5ª Edição. Reading: Addison-Wesley, 1995.
TANGORRA, F.; CHIAROLLA, D. A Methodology for Reverse Engineering Hierarchical Databases. Information and Software Technology, v. 37, n. 4, 1995, p. 225-231.
WARD, M. P.; BENNETT, K. H. Formal Methods for Legacy Systems. Journal of Software Maintenance: Research and Practice, v. 7, n. 3, 1995, p. 203-219.
SCHACH, S. R. Practical software engineering. Irving-Aksen: Homewood, 1992.
YOURDON, Edward. Análise estruturada moderna. 10. ed. Rio de Janeiro: Campus, 1990.
836p.
Aspectos de Validação do Método de Engenharia Reversa Fusion-RE/I aplicado a um Sistema Hipermídia. Valéria Delisandra Feltrim, Renata Pontin de M. Fortes, Willian Francisco da Sil- va. Instituto de Ciências Matemáticas e de Computação - Universidade de São Paulo. Dispo- nível em: <http://www.lbd.dcc.ufmg.br:8080/colecoes/sbes/1999/24.pdf> Último acesso em:
20/05/2009.
Desenvolvimento de Sistemas de Informação: Da Construção de Sistemas Informáticos à Re-
engenharia Organizacional. Disponível em:
<http://piano.dsi.uminho.pt/~jac/documentos/DSI.pdf >. Último acesso em: 14/09/2008.
Engenharia Reversa e Reengenharia. SCE 186 Engenharia de Software. Professora Rosana T.
Vaccare Braga. Disponível em: <
http://www.inf.ufpr.br/silvia/ES/reengenharia/reengenharia.pdf> Último acesso em:
20/12/2009
Engenharia Reversa na Engenharia de Software. Disponível em:
<http://www.dcc.ufrj.br/~schneide/es/2001/1/g18/Engenharia%20Reversa.htm> Último acesso em: 14/09/2008.
IEEE CS-TCSE (IEEE Technical Council on Software Engineering). Disponível em: <
http://tab.computer.org/tcse/> Último acesso em: 10/04/2009.
Introdução à Java Persistence API – JPA. Disponível em:
<http://www.devmedia.com.br/articles/viewcomp.asp?comp=4590> Último acesso em:
18/10/2009.
JEE Brasil. Disponível em: <http://www.jeebrasil.com.br > Último acesso em: 06/12/2009.
O que é JSP. Disponível em: <http://www.criarweb.com/artigos/227.php> Último acesso em:
20/10/2009.
Reengenharia de Software usando Transformações (RST). Valdirene Fontanette, Vinícius C.
Garcia, Adriano A. Bossonaro, Angela B. Perez, Antonio F. Prado. Universidade Federal de São Carlos - Departamento de Computação. Disponível em: <http://www2.dc.ufscar.br/~val- direne/Publications/JIISIC2002.pdf> Último acesso em 14/09/2008.
Reengenharia de software: o que, por quê e como. Ana Elisa Tozetto Piekarski e Marcos
Antonio Quináia. Disponível em:
<http://www.unicentro.br/editora/revistas/recen/v1n2/reengenharia.pdf> Último acesso em:
05/12/2009.
TB-REPP - Padrões de Processo para a Engenharia Reversa baseado em Transformações.
Disponível em: <http://www.cin.ufpe.br/~sugarloafplop/final_articles/12_TB-REPP- final.pdf> Último acesso em: 05/01/2010.
APÊNDICE A: DESCRIÇÃO DOS CASOS DE USO SISTEMA ESCOLAR EVOLUÍDO
Tabela 1 - Descrição do caso de uso Curso
Nº Caso de Uso 03
Nome Cadastrar Curso
Ator (es) Funcionário do Registro Acadêmico Descrição Cadastro do Curso no Sistema Escolar Pré-condições Ser regulamentado pelo Mec
Pós-condições -
Cenário Principal O Registro Acadêmico solicita dados do Curso
Registro Acadêmico informa (Descrição, ementa, carga horária, duração do curso)
Sistema gera código da disciplina Sistema cadastra curso
Cenário Alternativo Fluxo1: Alteração, atualização de dados
No passo 1 o funcionário informa a código do professor e o sistema verifica se ele existe na base de dados, caso exista, o sistema o recupera para atualização.
Pós condição: Descrição, ementa, carga horária, duração do curso atualizados e/ou modificados.
Cenário Alternativo Fluxo 2: Exclusão do Curso
No passo 2 o funcionário informa o código do Curso e o sistema verifica se ele existe na base de dados, caso exista, o sistema solicita sua exclusão,o funcionário confirma e o Curso é excluído.
Pós condição: Objeto Curso é excluído.
Regras de Negócio
Tabela 2 - Descrição do caso de uso Aluno
Nº Caso de Uso 01
Nome Cadastrar Aluno
Ator(es) Funcionário do Registro Acadêmico Descrição Cadastro do Aluno no Sistema Escolar Pré-condições Curso Cadastrado
Pós-condições Aluno criado e associado a curso
Cenário Principal Registro Acadêmico solicita dados pessoais do Aluno
Registro Acadêmico informa (Nome, Data nascimento, telefone, identidade, endereço)
Registro Acadêmico informa curso Sistema gera matricula do aluno Sistema cadastra aluno
Cenário Alternativo Fluxo1: Alteração, atualização de dados
No passo 2 o funcionário informa a matrícula do aluno e o sistema verifica se ele existe na base de dados, caso exista, o sistema o recupera para atualização.
Pós condição: Nome, endereço, telefone, identidade atualizados e/ou modificados.
Cenário Alternativo Fluxo 2: Exclusão de Aluno
No passo 2 o funcionário informa a matrícula do aluno e o sistema verifica se ele existe na base de dados, caso exista, verifica se ele está enturmado, caso estiver enturmado não pode ser excluído, sendo assim o funcionário não pode confirmar sua exclusão.
Pós condição: Objeto aluno é excluído.
Exceções Aluno não possuir dados necessários para a realização do cadastro.
Regras de Negócio Aluno não poderá solicitar mudança de situação, no período inferior a um semestre, após o inicio do curso
Tabela 3 - Descrição do caso de uso Professor
Nº Caso de Uso 02
Nome Cadastrar Professor
Ator (es) Funcionário do Registro Acadêmico Descrição Cadastro do Professor no Sistema Escolar Pré-condições Curso criado e associado ao professor Pós-condições Professor criado e associado a curso
Cenário Principal Registro Acadêmico solicita dados pessoais do Professor Registro Acadêmico informa (Nome, Data nascimento, telefone, identidade, endereço, escolaridade)
Registro Acadêmico inclui professor no curso especificado Sistema gera código do professor
Sistema cadastra professor
Cenário Alternativo Fluxo1: Alteração, atualização de dados.
No passo 1 o funcionário informa a código do professor e o sistema verifica se ele existe na base de dados, caso exista, o sistema o recupera para atualização.
Pós condição: Nome, endereço, telefone, identidade, escolaridade atualizados e/ou modificados.
Cenário Alternativo Fluxo 2: Exclusão do professor
No passo 2 o funcionário informa o código do professor e o sistema verifica se ele existe na base de dados, caso exista, o sistema solicita sua exclusão,o funcionário confirma e o professor é excluído.
Pós condição: Objeto Professor é excluído.
Exceções
Regras de Negócio
Tabela 4 - Descrição do caso de uso Situação de Aluno
Nº Caso de Uso 04
Nome Alterar Situação do Aluno
Ator (es) Funcionário do Registro Acadêmico
Descrição Alterar Situação do Aluno no Sistema Escolar Pré-condições O aluno estar matriculado na instituição Pós-condições Situação do aluno modificada
Cenário Principal O Registro Acadêmico solicita a matrícula do Aluno.
Funcionário informa nova situação do aluno ao sistema.
Sistema atualiza situação do aluno.
Cenário Alternativo Fluxo1: Situação inválida
Caso a situação do aluno for cancelada, aluno não pode ter sua situação como trancado.
Cenário Alternativo Fluxo2: Mudança de Situação inválida
Aluno pode requerer alteração de situação de cancelado para trancado e/ou trancar ou cancelar o curso sem ter concluído o primeiro período.
Exceções
Regras de Negócio Aluno ter no mínimo concluído um semestre de curso.
O aluno só poderá ativar sua matricula até um ano após seu trancamento.
O aluno só poderá concluir o curso após cursar todas as matérias e apresentar trabalho de conclusão.
Tabela 5 - Descrição do caso de uso Turma
Nº Caso de Uso 05
Nome Cadastrar Turma
Ator (es) Coordenador do Curso
Descrição Cadastro de Turma no Sistema Escolar Pré-condições Curso cadastrado
Pós-condições -
Cenário Principal Coordenador do curso informa dados da turma
Coordenador do curso informa (turno, descrição, carga horária, alunos, curso)
Sistema gera código da turma Sistema cadastra turma.
Cenário Alternativo Fluxo1: Alteração, atualização de dados
No passo 1 o coordenador informa a código da turma e o sistema verifica se ele existe na base de dados, caso exista, o sistema o recupera para atualização.
Pós condição: turno, descrição, carga horária, alunos, curso atualizados e/ou modificados.
Cenário Alternativo Fluxo 2: Exclusão da turma
No passo 2 o coordenador informa o código da turma e o sistema verifica se ele existe na base de dados, caso exista, o sistema solicita sua exclusão,o coordenador confirma e a turma é excluído.
Pós condição: Objeto turma é excluído.
Exceções
Regras de Negócio
Tabela 6 - Descrição do caso de uso Disciplina
Nº Caso de Uso 06
Nome Cadastrar Disciplina
Ator (es) Coordenador do Curso
Descrição Cadastro de Disciplina no Sistema Escolar Pré-condições Está na grade curricular do Curso
Pós-condições -
Cenário Principal O Coordenador do curso solicita dados da disciplina.
Coordenador do curso informa (ementa, descrição, carga horária).
Sistema gera código da Disciplina.
Sistema cadastra Disciplina.
Cenário Alternativo Fluxo1: Alteração, atualização de dados
No passo 1 o coordenador informa a código da Disciplina e o sistema verifica se ele existe na base de dados, caso exista, o sistema o recupera para atualização.
Pós condição: ementa, descrição, carga horária e/ou modificados.
Cenário Alternativo Fluxo 2: Exclusão da Disciplina
No passo 2 o coordenador informa o código da disciplina e o sistema verifica se ele existe na base de dados, caso exista, o sistema solicita sua exclusão,o coordenador confirma e a turma é excluído.
Pós condição: Objeto Disciplina é excluído.
Exceções
Regras de Negócio
Tabela 7 - Descrição do caso de uso Montar Horário
Nº Caso de Uso 07
Nome Montar Horário
Ator (es) Coordenador do Curso
Descrição Montar Horário no Sistema Escolar
Pré-condições Curso, Turno e Horário estar cadastrado (a)
Pós-condições -
Cenário Principal Sistema solicita dados para a montagem de horário.
O Coordenador do curso informa turno, curso, horário de inicio e término da aula e a sala.
Sistema gera horário.
Cenário Alternativo Fluxo1: Dados incompletos
No passo 1, sistema emite erro, por falta de dados, e/ou dados incorretos.
Cenário Alternativo2 Fluxo1: Duplicidade de dados
No passo 1, sistema emite erro, pela existência do mesmo curso no horário cadastrado. Ou sala já ocupada no horário.
Exceções Horário não cadastrado
Regras de Negócio
Tabela 8 - Casos de uso Matriz Escolar
Nº Caso de Uso 08
Nome Matriz Curricular
Ator (es) Coordenador do Curso
Descrição Cadastra Matriz Escolar do Curso
Pré-condições Curso já cadastrado e vinculado a matriz escolar Pós-condições
Cenário Principal Sistema solicita dados da matriz escolar.
Sistema solicita dados do campo curso, nome, ano início.
Sistema cadastra matriz escolar.
Cenário Alternativo Fluxo1: Alteração, atualização de dados
No passo 1 o coordenador informa a código da Matriz e o sistema verifica se ele existe na base de dados, caso exista, o sistema o recupera para atualização.
Pós condição: curso, nome, ano início e/ou modificados.
Cenário Alternativo 2 Fluxo 2: Exclusão da Matriz Escolar
No passo 2 o coordenador informa o código da Matriz e o sistema verifica se ele existe na base de dados, caso exista, o sistema solicita sua exclusão, cvo coordenador confirma e a matriz é excluída.
Pós condição: Objeto Matriz Escolar é excluído.
Regras de Negócio
Tabela 9- Casos de uso Componente Matriz
Nº Caso de Uso 08
Nome Componente Matriz
Ator (es) Coordenador do Curso
Descrição Cadastra Componente Matriz do Curso
Pré-condições Curso e matriz Escolar já cadastrado e vinculado Componente Matriz.
Pós-condições
Cenário Principal Sistema solicita dados da Componente Matriz.
Sistema solicita dados do campo Descrição, ementa, bibliografia, período.
Sistema cadastra Componente Matriz.
Cenário Alternativo Fluxo1: Alteração, atualização de dados
No passo 1 o coordenador informa a código de Componente Matriz e o sistema verifica se ele existe na base de dados, caso exista, o sistema o recupera para atualização.
Pós condição: Descrição, ementa, bibliografia, período.
e/ou modificados.
Cenário Alternativo 2 Fluxo 2: Exclusão da Componente Matriz
No passo 2 o coordenador informa o código de Componente Matriz e o sistema verifica se ele existe na base de dados, caso exista, o sistema solicita sua exclusão,o coordenador confirma e a componente matriz é excluída.
Pós condição: Objeto Componente Matriz é excluído.
Regras de Negócio
APÊNDICE B – CÓDIGO DA CLASSE DE MODELO “TURMA” DO PROJETO package iff.projetofinal.sistemaescolar.model;
import java.io.Serializable;
import javax.persistence.Entity;
import javax.persistence.Id;
import javax.persistence.JoinColumn;
import javax.persistence.ManyToOne;
@Entity
public class Aluno implements Serializable {
@Id
private String idaluno;
private String nome;
private String endereco;
private String datanasc;
private String identidade;
private String matricula;
private String sexo;
private String telefone;
@ManyToOne
@JoinColumn(name="idsituacao") private Situacao idsituacao;
@ManyToOne
@JoinColumn(name="idturma") private Turma idturma;
private static final long serialVersionUID = 1L;
public Aluno() { super();
}
public String getIdaluno() { return this.idaluno;
}
public void setIdaluno(String idaluno) { this.idaluno = idaluno;
}
public String getNome() { return this.nome;
}
public void setNome(String nome) { this.nome = nome;
}
public String getEndereco() { return this.endereco;
}
public void setEndereco(String endereco) { this.endereco = endereco;
}
public String getDatanasc() { return this.datanasc;
}
public void setDatanasc(String datanasc) { this.datanasc = datanasc;
}
public String getIdentidade() { return this.identidade;
}
public void setIdentidade(String identidade) { this.identidade = identidade;
}
public String getMatricula() { return this.matricula;
}
public void setMatricula(String matricula) { this.matricula = matricula;
}
public String getSexo() { return this.sexo;
}
public void setSexo(String sexo) { this.sexo = sexo;
}
public String getTelefone() { return this.telefone;
}
public void setTelefone(String telefone) { this.telefone = telefone;
}
public Situacao getIdsituacao() { return this.idsituacao;
}
public void setIdsituacao(Situacao idsituacao) { this.idsituacao = idsituacao;
}
public Turma getIdturma() { return this.idturma;
}
public void setIdturma(Turma idturma) { this.idturma = idturma;
} }
APÊNDICE C – CÓDIGO DA CLASSE DE PERSISTÊNCIA “TURMA” DO SISTEMA EVOLUÍDO
package iff.projetofinal.sistemaescolar.persistence;
import iff.projetofinal.sistemaescolar.model.Aluno;
import iff.projetofinal.sistemaescolar.model.Situacao;
import iff.projetofinal.sistemaescolar.model.Turma;
import java.util.List;
import javax.persistence.EntityManager;
import javax.persistence.EntityManagerFactory;
import javax.persistence.EntityTransaction;
import javax.persistence.Persistence;
public class PersistentAluno {
EntityManagerFactory emf = Persistence.createEntityManagerFactory("sistem- aescolar");
EntityManager em = emf.createEntityManager();
EntityTransaction trans = em.getTransaction();
public void inserir(String idaluno, String nome,String endereco,
String datanasc,String identidade,String matricula, String sexo, String telefone,Turma idturma,Situacao idsituacao) {
Aluno aluno = new Aluno();
aluno.setIdaluno(idaluno);
aluno.setNome(nome);
aluno.setEndereco(endereco);
aluno.setDatanasc(datanasc);
aluno.setIdentidade(identidade);
aluno.setMatricula(matricula);
aluno.setSexo(sexo);
aluno.setTelefone(telefone);
aluno.setIdturma(idturma);
aluno.setIdsituacao(idsituacao);
trans.begin();
em.persist(aluno);
trans.commit();
}
public void deletar(String idaluno) {
// TODO Auto-generated method stub Aluno aluno = em.find(Aluno.class,idaluno);
trans.begin();
em.remove(aluno);
trans.commit();