Embed Size (px)
Citation preview
0
FACULDADE METODISTA GRANBERY – FMG CURSO DE BACHARELADO EM SISTEMAS DE INFORMAÇÃO
TRABALHO DE CONCLUSÃO DE CURSO PERSISTÊNCIA EM SOFTWARE ORIENTADO A OBJETOS:
SOLUÇÕES DE MAPEAMENTO OBJETO-RELACIONAL
MARCELO SANTOS DAIBERT
JUIZ DE FORA
2005
1
MARCELO SANTOS DAIBERT
TRABALHO DE CONCLUSÃO DE CURSO PERSISTÊNCIA EM SOFTWARE ORIENTADO A OBJETOS:
SOLUÇÕES DE MAPEAMENTO OBJETO-RELACIONAL Trabalho de Conclusão de Curso apresentado pelo acadêmico Marcelo Santos Daibert ao curso de Bacharelado em Sistemas de Informação da Faculdade Metodista Granbery, como requisito para obtenção do título de Bacharel em Sistemas de Informação. ORIENTADOR: Prof. Marco Antônio Pereira Araújo, M.Sc. CO-ORIENTADORA: Profa. Alessandreia Marta de Oliveira Julio, M.Sc.
JUIZ DE FORA
2005
2
AGRADECIMENTOS
Agradeço inicialmente aos meus pais, Ricardo e Helene, que buscam me
proporcionar o que há de melhor nessa vida. Que me instruíram, me prepararam e
que me ensinaram a lutar pela vida e pelos meus ideais.
À minha esposa Patrícia que com sua dedicação e amor me deu forças
para vencer o meu dia a dia e enfrentar todos os obstáculos da vida.
Ao meu filho Yago, que com o seu sorriso me estimulou nos momentos de
desânimo, quando somente o choro tomava minha vida.
Aos meus orientadores Marco Antônio e Alessandreia que, com paciência,
carinho, dedicação e competência me fizeram entender que a vida é feita de
desafios, e estes desafios foram feitos para serem vencidos. Mostraram-me que
somente com muito trabalho e dedicação conseguimos chegar aos nossos objetivos.
Aos meus familiares, que sempre estiveram ao meu lado, não me fazendo
desistir da minha caminhada.
Aos participantes do projeto de iniciação científica a qual este trabalho
está vinculado. Em especial aos amigos Renato, Leandro, Valdete, João.
Aos amigos e colegas que estimulavam a caminhada.
E, por fim, aos demais professores da Faculdade Metodista Granbery pelo
incentivo e pela dedicação à atividade docente.
3
“Primeiro faça o necessário;
Depois faça o possível;
e, de repente, você vai perceber
que pode fazer o impossível”
São Francisco de Assis
4
FACULDADE METODISTA GRANBERY – FMG
CURSO DE BACHARELADO EM SISTEMAS DE INFORMAÇÃO
TRABALHO DE CONCLUSÃO DE CURSO FOLHA DE APROVAÇÃO
Após a exposição do discente Marcelo Santos Daibert, matrícula
2002102013, sobre a realização do Trabalho de Conclusão de Curso, a Banca
Examinadora, composta pelos professores abaixo identificados, reuniu-se e aprovou
o presente relatório monográfico que, por atender aos requisitos estabelecidos,
recebeu a nota 87 (oitenta e sete), como sendo a média da Banca.
Juiz de Fora, 07 de Dezembro de 2005
Professor Marco Antônio Pereira Araújo – Orientador
Professora Alessandreia Marta de Oliveira Julio – Co-Orientadora
Professora Melise Maria Veiga de Paula – Examinadora
Juiz de Fora
2005
5
LISTA DE FIGURAS
Figura 2.1 – Mapeamento Objeto-Relacional ...........................................................16
Figura 2.2 – Estratégias de Mapeamento para Herança..........................................19
Figura 2.3 – Mapeamento de Associação do Tipo 1:1 .............................................20
Figura 2.4 – Mapeamento de Associação do Tipo 1:n .............................................21
Figura 2.5 – Mapeamento de Associação do Tipo n:n .............................................21
Figura 3.1 – Camada SQL........................................................................................22
Figura 3.2 – Camada de Classes para Dados a Dados ...........................................23
Figura 3.3 – Camada de Persistência ......................................................................24
Figura 4.1 – Componentes DePO ............................................................................29
Figura 4.2 – Configurando Componente DePO........................................................29
Figura 4.3 – Model Explorer .....................................................................................36
Figura 4.4 – Componentes Instant Objects ..............................................................37
Figura 4.5 – Adicionando Nova Classe ....................................................................38
Figura 4.6 – Criação das Tabelas em Base de Dados Relacional ...........................40
Figura 4.7 – Criação do Atributo de Relacionamento para uma Referência ............41
Figura 4.8 – Criação do Atributo de Relacionamento para Várias Referências .......42
Figura 4.9 – Configuração do Componente InstantSelector.....................................42
Figura 4.10 – Componentes TiOPF..........................................................................46
Figura 5.1 – Modelo MVC.........................................................................................55
Figura 5.2 – Diagrama de Caso de Uso ...................................................................56
Figura 5.3 – Diagrama de Classes ...........................................................................57
Figura 5.4 – Interação da Classe Controle - Gerente...............................................58
Figura 5.5 – Interface de Pesquisa de Curso ...........................................................65
Figura 5.6 – Diagrama de Sequência da Operação Pesquisa .................................66
Figura 5.7 – Diagrama de Sequência da Operação Incluir Curso ............................68
Figura 5.8 – Interface de Incluir Curso .....................................................................69
Figura 5.9 – Diagrama de Sequência da Operação Atualizar Curso........................71
Figura 5.10 – Interface de Atualizar Curso...............................................................72
Figura 5.11 – Diagrama de Sequência da Operação Excluir Curso .........................74
6
Figura 5.12 – Interface de Excluir Curso ..................................................................75
Figura 5.13 – Diagrama de Sequência da Operação Consultar Curso ....................76
Figura 5.14 – Interface de Consultar Curso .............................................................77
7
LISTA DE TABELAS
Tabela 4.1 – Principais Propriedades e Métodos do DePO .....................................30
Tabela 4.2 – Comparativo Entre os frameworks ......................................................52
8
LISTA DE LISTAGENS DE CÓDIGO FONTE
Listagem 4.1 – Definição das Classes .....................................................................30
Listagem 4.2 – Mapeamento das Classes ...............................................................32
Listagem 4.3 – Instanciação e Persistência de um Objeto.......................................34
Listagem 4.4 – Recuperação de um Objeto .............................................................34
Listagem 4.5 – Atualização de um Objeto................................................................35
Listagem 4.6 – Exclusão de um Objeto....................................................................35
Listagem 4.7 – Definição das Classes .....................................................................39
Listagem 4.8 – Instanciação e Persistência de um Objeto.......................................44
Listagem 4.9 – Recuperação de um Objeto .............................................................44
Listagem 4.10 – Atualização de um Objeto..............................................................44
Listagem 4.11 – Exclusão de um Objeto..................................................................44
Listagem 4.12 – Configurando o Acesso à Base de Dados .....................................47
Listagem 4.13 – Criando Tabela ..............................................................................47
Listagem 4.14 – Verifica Existência da Tabela.........................................................47
Listagem 4.15 – Exclusão da Tabela .......................................................................47
Listagem 4.16 – Definição das Classes ...................................................................48
Listagem 4.17 – Definição de Relacionamento ........................................................48
Listagem 4.18 – Definição da Classe de Lista de Objetos .......................................49
Listagem 4.19 – Mapeamento Objeto-Relacional.....................................................50
Listagem 5.1 – Definição das Classes Curso e Professor........................................62
Listagem 5.2 – Mapeamento Objeto-Relacional do Curso e Professor....................63
Listagem 5.3 – Método ObterCursos........................................................................66
Listagem 5.4 – Método RecuperarObjetos...............................................................67
Listagem 5.5 – Método Criar ....................................................................................70
Listagem 5.6 – Método Gravar Campos - Persistir...................................................70
Listagem 5.7 – Método Persistir ...............................................................................70
Listagem 5.8 – Método Obter ...................................................................................72
Listagem 5.9 – Método RecuperaObjeto..................................................................72
Listagem 5.10 – Método LerCampos .......................................................................73
9
Listagem 5.11 – Método Gravar Campos - Atualizar................................................73
Listagem 5.12 – Método Excluir - Gerente ...............................................................75
Listagem 5.13 – Método Excluir – Classe Curso......................................................75
10
SUMÁRIO
1 INTRODUÇÃO ...................................................................................14
2 MAPEAMENTO OBJETO-RELACIONAL .........................................16 2.1 Introdução.........................................................................................................16 2.2 OID (Object Identificator) .................................................................................16 2.3 Mapeamento .....................................................................................................18 2.3.1 Mapeando Atributos.................................................................................18 2.3.2 Mapeando Classes ...................................................................................18 2.3.3 Mapeando Herança...................................................................................18 2.3.4 Mapeando Relacionamentos ...................................................................19 2.3.4.1 Diferença Entre Associação e Agregação/Composição ...............20 2.3.4.2 Associação do Tipo 1:1 ...................................................................20 2.3.4.3 Associação do Tipo 1:n ...................................................................20 2.3.4.4 Associação do Tipo n:n ...................................................................21 2.4 Conclusão .........................................................................................................21
3 CAMADA DE PERSISTÊNCIA ..........................................................22 3.1 Introdução.........................................................................................................22 3.2 Estratégias de Persistência.............................................................................22 3.2.1 Camada SQL .............................................................................................22 3.2.2 Camada de Classes para Acesso a Dados.............................................23 3.2.3 Camada de Persistência ..........................................................................23 3.2.3.1 Requisitos de uma Camada de Persistência...................................24 3.3 Programação em Camadas Utilizando Camada de Persistência .................26 3.4 Conclusão .........................................................................................................26
4 FRAMEWORKS DE PERSISTÊNCIA................................................28 4.1 Delphi Persistent Objects ................................................................................28
11
4.1.1 Componentes DePO.................................................................................28 4.1.2 Classes e Propriedades ...........................................................................29 4.1.3 Relacionamentos......................................................................................31 4.1.4 Mapeamento Objeto-Relacional ..............................................................32 4.1.5 Manipulação de Objetos ..........................................................................34 4.1.6 Considerações Finais ..............................................................................35 4.2 Instant Objects .................................................................................................36 4.2.1 Componentes Instant Objects.................................................................37 4.2.2 Classes e Propriedades ...........................................................................38 4.2.3 Relacionamentos......................................................................................41 4.2.4 Mapeamento Objeto-Relacional ..............................................................43 4.2.5 Manipulação de Objetos ..........................................................................43 4.2.6 Considerações Finais ..............................................................................44 4.3 TechInside Object Persistent Framework ......................................................45 4.3.1 Componentes TiOPF................................................................................46 4.3.2 Classes e Propriedades ...........................................................................47 4.3.3 Relacionamentos......................................................................................48 4.3.4 Mapeamento Objeto-Relacional ..............................................................49 4.3.5 Manipulação de Objetos ..........................................................................50 4.3.6 Considerações Finais ..............................................................................51 4.4 Conclusão .........................................................................................................51
5 ESTUDO DE CASO ...........................................................................53 5.1 Introdução.........................................................................................................53 5.2 Projeto de Inciação Científica .........................................................................53 5.3 Sistema de Controle Acadêmico.....................................................................54 5.4 Implementação .................................................................................................55 5.4.1 Introdução.................................................................................................55 5.4.2 Operação Pesquisa de Curso..................................................................65 5.4.3 Operação Incluir Curso............................................................................67 5.4.4 Operação Atualizar Curso .......................................................................70 5.4.5 Operação Excluir Curso...........................................................................74
12
5.4.6 Operação Consultar Curso......................................................................76 5.5 Conclusão .........................................................................................................77
6 CONSIDERAÇÕES FINAIS ...............................................................78 ANEXO A – DOCUMENTAÇÃO SISTEMA ACADÊMICO...................80
REFERÊNCIAS BIBLIOGRÁFICAS ...................................................115
BIBLIOGRAFIA...................................................................................117
13
RESUMO
O paradigma orientado a objetos cada vez mais vem se destacando e vem
sendo amplamente utilizado no desenvolvimento de aplicações, trazendo diversos
benefícios tanto para a equipe de desenvolvimento quanto para a qualidade do software.
Entretanto, os desenvolvedores enfrentam problemas quando necessitam persistir objetos,
uma vez que os bancos de dados puramente orientados a objetos não são maduros o
suficiente e com desempenho inferior aos bancos relacionais. Neste contexto, uma das
estratégias de persistência de objetos muito utilizada pelos desenvolvedores é o
mapeamento objeto-relacional para a persistência em sistemas gerenciadores de bancos de
dados relacionais (SGBDR). Todavia, a estrutura dos bancos de dados relacionais difere
substancialmente dos mecanismos de persistência da orientação a objetos, o que gerará um
maior esforço do desenvolvedor. Este trabalho tem como objetivo conceituar e discutir as
estratégias de mapeamento objeto-relacional e camadas de persistência, além de
exemplificar o uso de alguns frameworks que se propõem a realizar o papel de camada de
persistência entre o banco de dados relacional e a aplicação orientada a objetos. São
avaliados frameworks de código fonte livre (opensource) para o ambiente de
desenvolvimento Delphi e ao final é apresentado um estudo de caso abordando o que foi
conceituado no trabalho.
Palavras Chave: Banco de Dados Relacional, Camada de Persistência, Mapeamento Objeto Relacional, Orientação a Objeto, Frameworks de Persistência.
14
1 INTRODUÇÃO
Com o avanço e fundamentação das técnicas do paradigma orientado a objetos,
cada vez mais empresas e desenvolvedores desenvolvem suas aplicações com esta
metodologia, buscando alcançar todos os benefícios difundidos pela orientação a objetos,
como reutilização de código, processo bem definido de desenvolvimento, documentação,
manutenabilidade, entre outros.
Entretanto, as empresas e desenvolvedores passam dificuldades quando têm
que optar pela estratégia de armazenamento de dados, uma vez que os sistemas
gerenciadores de banco de dados orientadas a objetos não são maduros o suficiente
quando comparados aos sistemas gerenciadores de banco de dados relacionais.
O modelo relacional esta muito bem fundamentado e ainda é o padrão para o
armazenamento de informações, sendo o modelo mais utilizado pela Engenharia de
Software e encontrado nos principais bancos de dados das empresas, inclusive muito
abordado no meio acadêmico. O modelo é baseado na relação entre linhas (tuplas) e
colunas (atributos), o que gera um problema no desenvolvimento orientado a objetos, uma
vez que estes podem possuir estruturas complexas, diferente das utilizadas no modelo
relacional (integer, date, varchar, dentre outras).
É necessário então um esforço maior de programação para adequar os objetos
ao modelo relacional, a isso é dado o nome de mapeamento objeto-relacional. Uma das
soluções para este problema é a utilização de uma camada de persistência entre a
aplicação e o banco de dados, um framework. Esta camada é responsável pelo controle e
manipulação dos objetos, além de servir de comunicação entre o banco de dados e a
aplicação.
A persistência de objetos se faz necessária quando é preciso guardar as
informações dos atributos dos objetos em um banco de dados, ou em outra estratégia de
armazenamento, para que se possa recuperá-lo posteriormente. No escopo deste trabalho é
analisada somente a persistência de objetos em banco de dados relacional (SGBDR).
Este trabalho tem então como objetivo conceituar mapeamento objeto-relacional,
exemplificando as principais técnicas existentes. Apresentar os conceitos e estratégias de
camadas de persistência, além de definir e exemplificar o uso de frameworks de persistência
objeto-relacional opensource disponíveis para o ambiente de desenvolvimento Delphi.
No segundo capítulo são apresentados os conceitos e estratégias de
mapeamento objeto-relacional. É definido como mapear as classes e relacionamentos do
modelo orientado a objetos para o as tabelas e atributos do modelo relacional. No terceiro
capítulo são definidos os conceitos de camadas de persistência e suas estratégias (camada
15
SQL, camada de acesso aos dados e camada de persistência). São apresentados os
requisitos de uma camada de persistência e como ela deve se portar dentro de uma
aplicação.
O capítulo quatro descreve três frameworks de persistência objeto-relacional de
código livre aberto (opensource) para o ambiente de desenvolvimento Delphi, alem de seus
conceitos e aplicações.
No quinto capítulo é desenvolvido um estudo de caso utilizando todos os
conceitos dos primeiros capítulos. Este estudo de caso foi projetado e desenvolvido
utilizando as teorias propostas pela Engenharia de Software, utilizando formalmente todas
as metodologias de desenvolvimento. O projeto conta com documentação, seguindo a UML
(especificação de requisitos, diagramas de classe, diagramas de estudo de caso,
especificação de caso de uso e diagramas de seqüência). Foi utilizado um sistema de
versionamento para desenvolvimento, além da utilização de um sistema de rastreio de
defeitos - bugs (bugtracking). Para o versionamento foi utilizado o sistema SVN (Subversion)
(SUBVERSION, 2005) e para o rastreio de bugs foi utilizado o NSN Project (NSN, 2005).
Por fim, no sexto capítulo, são apresentadas as considerações finais e
sugestões para trabalhos futuros.
16
2 MAPEAMENTO OBJETO-RELACIONAL
2.1 Introdução Um dos principais passos para se persistir um objeto em um banco de dados
relacional é o mapeamento. Neste passo são definidas quais as classes do domínio viram
tabelas e quais atributos da classe viram campos no modelo relacional, além de ser feito o
mapeamento dos relacionamentos entre as classes.
É importante destacar a escolha o OID (Object Identification), que será a chave
primária no modelo relacional. Uma definição formal, bem como as estratégias de escolha
de OIDs são apresentadas no item 2.2.
Como mostrado na Figura 2.1, para se mapear um modelo orientado a objetos
para o modelo relacional, basicamente deve-se (AMBLER, 2000):
mapear classes para tabelas;
mapear atributos para colunas;
mapear os relacionamentos: um-para-um, um-para-muitos, muitos-para-
muitos, agregação, composição e herança.
Classes
Tabelas
Figura 2.1. Mapeamento Objeto-Relacional.
2.2 OID (Object Identification) Todo objeto possui um OID que estabelece sua identidade. Esse OID é único
para cada instância e não é compartilhado para nenhuma outra, sendo exclusivo. O OID de
um objeto é gerado em tempo de execução da aplicação assim que o objeto é instanciado.
Entretanto esse OID gerado em tempo de execução não é acessível para a aplicação, ele se
resume a um endereço de memória, o que o torna inadequado para identificador de objetos
no mapeamento objeto-relacional.
Deve-se então configurar um OID manualmente dentro da classe, para que esse
seja o campo chave primária no modelo relacional. Esse atributo identificador deve ser único
17
e exclusivo, para que não ocorra redundância no banco de dados relacional. Existem alguns
detalhes que requerem atenção antes da escolha (AMBLER, 2000):
não se deve utilizar atributos da modelagem de negócios para OID’s: Ao
utilizar esses atributos a mudança de alguma regra de negócio ou até mesmo
o modelo, pode causar problemas na manutenção dos dados já existentes no
banco. Lembrando que as chaves primárias têm grandes chances de ser
chaves estrangeiras em outras tabelas, aumentando assim o problema, como
informações relativas ao CPF e CNPJ;
um OID deve ser único para toda a hierarquia de classes: É muito comum
utilizar um campo de auto incremento para ser utilizado como chave primária
em um banco de dados relacional, mas em um modelo orientado a objetos,
onde existe toda uma hierarquia entre classes e relacionamento entre elas,
existe uma facilidade de existir duplicidade de chave primária no banco,
gerando problemas de inconsistência de dados. Um OID deve ser único e
exclusivo para todos os objetos, consequentemente único também no modelo
relacional.
Dentre as estratégias para a escolha de um OID, destaca-se (AMBLER, 2000):
manter uma tabela com valores de OID’s: Esta estratégia consiste em criar
uma tabela onde são armazenados os OID’s. Antes de persistir qualquer
objeto, a aplicação acessa o banco e executa a função MAX() na tabela de
OID’s, buscando assim o maior valor de OID inserido. Após, soma-se mais
um a este valor obtido, persiste-se o objeto na sua tabela determinada pelo
mapeamento e insere o OID do objeto na tabela de OID’s. Esta estratégia
causa depreciação na desempenho da aplicação, uma vez que é necessário
mais um acesso ao banco para realizar a operação;
GUIDs/UUIDs: Estratégia que gera uma string de 128bits que é calculada em
tempo de execução com base no hashing dos valores do endereço físico da
placa de rede e no dia e hora atual do computador. Esta estratégia garante
um OID único para todos os objetos;
recurso de alguns SGBDs para geração de valores únicos: Alguns SGBDs,
como o ORACLE, possuem recursos de geração de valores únicos que
podem ser utilizados como OID. A desvantagem desta estratégia é que
ocorrerá uma dependência do banco de dados.
18
2.3 Mapeamento Existem algumas estratégias para o mapeamento objeto-relacional que buscam
minimizar os esforços de organização dos dados no banco de dados relacional. Estas
estratégias tratam não somente dos atributos e classes, mas também como estes podem se
relacionar com as tabelas no modelo relacional.
2.3.1 Mapeando Atributos Inicialmente, os atributos das classes são mapeados para colunas no modelo
relacional. Um atributo pode ser mapeado para zero ou mais colunas, de acordo com a
necessidade (AMBLER, 2000).
Quando um atributo é um tipo simples (integer, date, string, boolean, etc.) ele é
mapeado para uma coluna. Já se ele for de um tipo complexo deve ser mapeado em
quantas colunas forem necessárias, e dependendo do caso pode até ser mapeado em outra
classe. Quando este último ocorrer é importante observar a criação de uma coluna para
manter o relacionamento entre a tabela original e a tabela criada ao se mapear o tipo
complexo, ou seja, é criado um campo com o conceito de chave estrangeira.
2.3.2 Mapeando Classes Classes são mapeadas para tabelas, mas não diretamente. Existem diferentes
estratégias para este mapeamento, que se configuram de acordo com certos fatores
(AMBLER, 2000), como:
mapeamento de herança;
mapeamento de associação do tipo 1:1;
mapeamento de associação do tipo 1:n;
mapeamento de associação do tipo n:n;
mapeamento de composição;
mapeamento de agregação.
2.3.3 Mapeando Herança Para efetuar o mapeamento de herança se faz necessário o uso de OID’s únicos
e exclusivos para não causar inconsistência nos dados. Existem fundamentalmente três
estratégias para mapear herança em um banco de dados relacional, como mostra a Figura
2.2 (AMBLER, 2000):
19
Uma tabela por
hierarquiaUma Tabela porClasse Concreta
Uma Tabela porClasse
Figura 2.2. Estratégias de Mapeamento para Herança.
uma tabela por hierarquia: Mapear toda a hierarquia de classes para uma
tabela, onde todos os atributos das classes da hierarquia serão armazenados
nesta única tabela. A desvantagem desta estratégia é que toda vez que um
objeto da hierarquia for persistido no banco, é necessário persistir também os
valores da classe irmã vazios, causando uma grande quantidade de campos
vazios. Entretanto o acesso ao banco para a manipulação dos dados é mais
rápido, uma vez que todos os dados estão em somente uma tabela. É
adicionada uma coluna na tabela que referencia qual o tipo de objeto, ou seja,
de qual classe aqueles dados pertencem;
uma tabela por classe concreta: Cada classe concreta mapeada vira uma
tabela com todos os atributos herdados das super classes abstratas. A
vantagem desta estratégia é a facilidade de manipulação de dados, uma vez
que todos os dados de cada classe estão em apenas uma única tabela. Como
desvantagem, destaca-se: Quando se modifica uma classe abstrata, é
necessário modificar todas as tabelas geradas pelas classes filhas no modelo
relacional;
uma tabela por classe: Cada classe é mapeada para uma tabela, onde a
chave primária da classe abstrata é a chave primária da classe concreta.
2.3.4 Mapeando Relacionamentos Um relacionamento ocorre quando um objeto refere-se a outro objeto. Para se
persistir este objeto, é importante que esta referência possa ser persistida também, para que
se mantenha a consistência dos dados e os relacionamentos em uma posterior manipulação
do objeto (SATZINGER e ORVIK, 1996).
20
Para que isso ocorra é necessário que o relacionamento seja também mapeado,
para que a aplicação ao manipular o objeto já persistido possa saber suas referências ou a
quem o referencia.
2.3.4.1 Diferença Entre Associação e Agregação/Composição Ao manipular um objeto que referencia uma classe agregada ou composta é
natural que ocorra a visualização de todos os dados da classe agregada ou composta do
objeto referenciado. O que não acontece em uma associação. Essa é a diferença básica do
ponto de vista do banco de dados relacional entre associação e agregação/composição
(AMBLER, 2000).
Ou seja, toda vez que recuperar um objeto do banco que tenha uma agregação
ou composição deve-se recuperar também os objetos da classe agregada ou composta
referenciada. Raciocínio análogo vale para a exclusão.
2.3.4.2 Associação do Tipo 1:1
A associação do tipo 1:1 entre classes é mapeado colocando o atributo
identificador da classe referenciada na classe que o referencia, criando então o conceito de
uma chave estrangeira no modelo relacional, como demonstrado na Figura 2.3 (AMBLER,
2000).
Figura 2.3. Mapeamento de Associação do Tipo 1:1
2.3.4.3 Associação do Tipo 1:n Da mesma forma que a associação do tipo 1:1, o relacionamento 1:n também é
mapeado colocando o atributo identificador da classe referenciada na classe que o
referencia, criando então o conceito de uma chave estrangeira no modelo relacional, como
demonstrado na Figura 2.4 (AMBLER, 2000).
21
Figura 2.4. Mapeamento de Associação do Tipo 1:n
2.3.4.4 Associação do Tipo n:n Para mapear uma associação do tipo n:n, é necessário utilizar o conceito de
tabela associativa, cujo único propósito é manter o relacionamento entre duas ou mais
tabelas do modelo relacional (AMBLER, 2000).
Cria-se então uma tabela associativa com os OID’s das classes que se
referenciam, garantindo então a navegabilidade do relacionamento, como exemplificado na
Figura 2.5.
Figura 2.5. Mapeamento de Associação do Tipo n:n
2.4 Conclusão Este capítulo teve como objetivo apresentar, conceituar e exemplificar as
estratégias existentes atualmente para mapeamento objeto-relacional.
As estratégias de mapeamento objeto-relacional mostram-se interessantes para
efetivamente utilizar os sistemas gerenciadores de banco de dados relacional (SGBDR) na
persistência de objetos, uma vez que as estratégias de armazenamento puramente
orientadas a objetos não estão maduras o suficiente.
Com isso, unem-se a maturidade e rapidez dos bancos de dados relacionais,
com os benefícios da orientação a objetos.
22
3 CAMADA DE PERSISTÊNCIA
3.1 Introdução Camada de persistência refere-se a uma estrutura responsável por manipular
objetos em alguma forma de armazenamento, ou seja, faz com que uma informação
solicitada uma vez, esteja disponível outras vezes na aplicação, ou até mesmo para outra
aplicação.
Deve prover os serviços de criar, recuperar, atualizar e excluir um objeto (CRUD
– Create, Retrieve, Update e Delete) (AMBLER, 2000). Estes serviços são os responsáveis
por manter a persistência e manipulação de objetos dentro da aplicação.
Existem 3 estratégias de camadas de persistência responsáveis por persistir
objetos no banco de dados relacional (AMBLER, 2000):
camada SQL;
camada de classes para acesso aos dados;
camada de persistência.
3.2 Estratégias de Persistência
3.2.1 Camada SQL Tipo de persistência de objetos muito comum, mas pouco portável, onde em
cada classe de domínio existem métodos com código SQL embutido que são responsáveis
por persistir os atributos dos objetos na base de dados relacional. A Figura 3.1 ilustra o
acesso direto das classes de domínio ao banco de dados relacional (AMBLER, 2000).
Classes de Domínio
SQL
SGBDR
Figura 3.1. Camada SQL
Este tipo proporciona uma rapidez na codificação das classes e do sistema, mas
em contra partida não as deixa reutilizáveis nem portáveis.
23
Não é utilizado um esquema pré-definido de mapeamento objeto-relacional, o
próprio SQL embutido na classe se responsabiliza por definir o mapeamento, o que torna o
código não reutilizável.
3.2.2 Camada de Classes para Acesso a Dados Semelhante ao tipo Camada SQL, mas com a diferença que os códigos SQL são
embutidos em novas classes, denominadas classes para acesso aos dados. As classes de
domínio se relacionam com estas classes de dados para que possam ser acionados
métodos para a manipulação dos dados no banco de dados relacional. A Figura 3.2 faz
referência à utilização das classes para acesso a dados pelas classes de domínio
(AMBLER, 2000).
Classes de Domínio
SQL
SGBDR
Classes de Acesso a Dados
Figura 3.2. Camada de Classes para Acesso a Dados
Assim como na camada SQL, também não é utilizada nenhuma estrutura
de mapeamento objeto-relacional. A mesma é de responsabilidade das classes de
acesso a dados.
3.2.3 Camada de Persistência É uma estrutura agregada à aplicação responsável por toda a manipulação dos
objetos, conexão ao banco e mapeamento das classes. A camada se utiliza de uma
estratégia de mapeamento objeto-relacional para que, de forma genérica em uma única
estrutura, possa manipular os objetos, como a Figura 3.3 evidencia.
Umas das estruturas de veiculação mais utilizadas e difundidas para o
mapeamento objeto-relacional é o arquivo XML (Extensible Markup Language) (XML, 2005).
Dentro do arquivo XML é definido todo o mapeamento do modelo de acordo com a estrutura
XML já definida pela camada de persistência, ficando assim todo o mapeamento fora da
codificação da aplicação.
24
Uma outra forma, também muito utilizada, é adicionar o mapeamento na
codificação da aplicação.
Classes de Domínio
SQL
SGBDRCamada
dePersistência
Figura 3.3. Camada de Persistência
A camada de persistência é responsável por gerar todos os códigos SQL
necessários para persistir, recuperar, alterar e excluir objetos em um banco de dados
relacional. Todas essas operações se passam de forma transparente ao programador, que
somente acessa métodos da camada para que as operações possam ocorrer (AMBLER,
2000).
Existem dois tipos de camada de persistência: as intrusivas e não intrusivas. As
intrusivas são aquelas que exigem que as classes persistentes de domínio herdem da
classe responsável pela persistência e manutenção de objetos da camada de persistência,
para que, dessa forma, os objetos instanciados possam por herança herdar os métodos de
persistência e manutenção de objetos na base de dados.
As não intrusivas são as que não necessitam que as classes de domínio tenham
nenhum relacionamento com nenhuma classe da camada de persistência, bastando
somente invocar um método da camada, passando por referência o objeto a ser persistido
ou manipulado.
3.2.3.1 Requisitos de Uma Camada de Persistência Abaixo, características desejáveis que devem ser implementadas em uma
Camada de Persistência (AMBLER, 2000):
suporte a diversos tipos de mecanismos de persistência: um mecanismo de
persistência pode ser definido como a estrutura que armazena os dados –
seja ela um SGBD relacional, um arquivo XML ou um SGBD OO, por
exemplo. Uma Camada de Persistência deve suportar a substituição deste
mecanismo e permitir a gravação do estado de objetos em qualquer um
destes meios;
25
encapsulamento completo da camada de dados: o usuário do sistema de
persistência de dados deve utilizar-se, no máximo, de mensagens de alto
nível como save ou delete para lidar com a persistência dos objetos, deixando
o tratamento destas mensagens para a camada de persistência em si;
ações com multi-objetos: deve ser capaz de salvar e retornar lista de objetos
da base de dados, tendo em vista a freqüência desta situação, como em
relacionamentos do tipo muitos (1:n e n:n);
transações: ao utilizar-se da Camada de Persistência, o programador deve
ser capaz de controlar o fluxo da transação – ou ter garantias sobre o mesmo,
caso a própria Camada de Persistência preste este controle;
extensibilidade: a camada de persistência deve permitir a adição de novas
classes ao esquema e a modificação do mecanismo de persistência;
identificadores de objetos: a implementação de algoritmos de geração de
chaves de identificação garante que a aplicação trabalhará com objetos com
identidade única e sincronizada entre o banco de dados e a aplicação;
cursores e proxies: as implementações de serviços de persistência devem
saber que, em muitos casos, os objetos armazenados são muito grandes e
recuperá-los por completo a cada consulta não é uma boa idéia. Técnicas
como o lazy loading (carregamento tardio) utilizam-se dos proxies para
garantir que atributos só serão carregados à medida que forem importantes
para o usuário.
registros: apesar da idéia de lidar somente com objetos, as camadas de
persistência devem, em geral, dispor de um mecanismo de recuperação de
registros - conjuntos de colunas são encapsuladas na forma de objetos, como
resultado de suas consultas. Isto permite integrar as camadas de
persistências a mecanismos de geração de relatórios que não trabalham com
objetos, por exemplo, além de permitir a recuperação de atributos de diversos
objetos relacionados com uma só consulta;
múltiplas arquiteturas: o suporte a ambientes de programas stand-alone,
cenários onde o banco de dados encontra-se em um servidor central e
mesmo arquiteturas mais complexas (em várias camadas) deve ser inerente à
Camada de Persistência, já que a mesma deve visar a reusabilidade e fácil
adaptação a arquiteturas distintas;
diversas versões de banco de dados e fabricantes: a Camada de Persistência
deve reconhecer diferenças de recursos, sintaxe e outras minúcias existentes
26
no acesso aos bancos de dados suportados, isolando isto do usuário do
mecanismo e garantindo portabilidade entre plataformas;
múltiplas conexões: um gerenciamento de conexões (usualmente utilizando-
se de pooling) é uma técnica que garante que vários usuários utilizarão o
sistema simultaneamente sem quedas de desempenho;
consultas SQL: apesar do poder trazido pela abstração em objetos, este
mecanismo não é funcional em todos os casos. Para os casos extremos, a
Camada de Persistência deve prover um mecanismo de consultas que
permita o acesso direto aos dados – ou então algum tipo de linguagem de
consulta simular à SQL, de forma a permitir consultas com um grau de
complexidade maior que o comum;
controle de concorrência: acesso concorrente a dados pode levar a
inconsistências. Para prever e evitar problemas decorrentes do acesso
simultâneo, a Camada de Persistência deve prover algum tipo de mecanismo
de controle de acesso. Este controle geralmente é feito utilizando-se dois
níveis – com o travamento pessimístico (pessimistic locking), as linhas no
banco de dados relativas ao objeto acessado por um usuário são travadas e
tornam-se inacessíveis a outros usuários até o mesmo liberar o objeto. No
mecanismo otimístico (optimistic locking), toda a edição é feita em memória,
permitindo que outros usuários venham a modificar o objeto.
3.3 Programação em Camadas Utilizando Camada de Persistência A camada de persistência é apenas mais uma a se relacionar com a camada de
negócio e domínio. As classes de domínio e negócio acessam os métodos da camada de
persistência para poder persistir suas instâncias (AMBLER, 2000).
Existem as classes de interface, que são responsáveis pela interação com o
usuário. Estas trocam mensagens com as classes de domínio/negócio e com as classes de
controle, que por sua vez trocam mensagens com as classes da camada de persistência, ou
seja, a camada de persistência é somente mais uma camada da aplicação.
3.4 Conclusão Este capítulo mostrou as estratégias de persistência de objetos a nível de
sistema, além de definir formalmente camada de persistência, que é uma camada
27
responsável pela persistência e manipulação de objetos de forma transparente ao
programador.
A essência das camadas de persistência é auxiliar de forma transparente o
programador na tarefa de tornar persistente os objetos da aplicação. Para isso foram
mostradas também características desejáveis das camadas de persistência para que
eficazmente e eficientemente possam realizar esta função.
Foram apresentadas três estratégias de camadas de persistência. A primeira, a
camada SQL, que adiciona métodos responsáveis por persistir os objetos através de código
SQL nas classes de domínio. A segunda, a camada para acesso aos dados, que cria
classes especificamente para se relacionar com os classes de domínio que são
responsáveis pela persistência das instancias das classes do domínio. E por fim, foram
apresentadas as robustas camadas de persistência, que são frameworks, que de forma
genérica se responsabilizam pela persistência dos objetos das classes de domínio.
28
4 FRAMEWORKS DE PERSISTÊNCIA Um framework de Persistência é um conjunto de ferramentas e classes que
facilitam uma aplicação a desempenhar o papel de persistir e manipular objetos.
O objetivo deste capítulo é analisar os frameworks de persistência de código
fonte livre (opensource) disponíveis para o ambiente Delphi. São apresentados os seguintes
frameworks:
DePO (Delphi Persistent Objects);
IO (Instant Objects);
TIOPF (TechInside Object Persistent Framework).
4.1 Delphi Persistent Objects O DePO (Delphi Persistent Objects) (DEPO, 2005) é um framework que se
propõe a realizar o papel da camada de persistência entre o banco de dados relacional e a
aplicação orientada a objetos. Totalmente desenvolvido em Delphi como um componente, o
DePO utiliza um esquema de mapeamento que determina quais atributos das classes de
domínio da aplicação são mapeados para os campos das tabelas de dados.
Este esquema de mapeamento funciona de forma transparente ao
desenvolvedor, ou seja, este acessa os métodos do framework para manipular os objetos no
banco de dados. Esta tarefa de manipulação dos objetos é de responsabilidade do DePO. O
desenvolvedor não precisa criar uma única linha de código SQL para realizar estas tarefas
(DAIBERT, JULIO e ARAUJO, 2005).
Atualmente, o DePO é compatível com todas as versões do Delphi a partir da
versão 5. Com algumas modificações em seu código fonte, os pacotes do DePO ficam
compatíveis também com a versão 3 do Kylix para o ambiente Linux.
4.1.1 Componentes DePO Depois de instalado, o DePO cria uma paleta chamada Liws no painel de paletas
na IDE do Delphi, nas versões mais atuais esta paleta tem o nome de DePO. Nesta paleta
estão os componentes DePO, como pode ser visualizado na Figura 4.1.
Para iniciar um projeto, basicamente são necessários dois dos componentes: o
componente de conexão ao banco de dados relacional dpoDBXMechanism para
comunicação utilizando SQLConnection do DBExpress ou dpoADOMechanism para
comunicação utilizando ADOConnection, e o componente de mapeamento
29
dpoDBMappingManager. O framework possui suporte para qualquer banco de dados
relacional, bastando apenas a máquina possuir o driver específico (DAIBERT, JULIO e
ARAUJO, 2005).
Figura 4.1. Componentes DePO
Ao configurar os componentes, deve-se configurar o componente de conexão ao
banco, associando-o a um driver previamente configurado e a um mecanismo de
mapeamento. Deve-se configurar também os parâmetros do banco de dados relacional
sendo utilizado, como usuário, senha, SQLDialect e caminho da base de dados, como
mostra a Figura 4.2.
Figura 4.2. Configurando Componente DePO
4.1.2 Classes e Propriedades Ao se definir uma classe que será persistida utilizando o DePO, deve-se ter
atenção aos seguintes detalhes (DAIBERT, JULIO e ARAUJO, 2005):
Toda classe que efetuar persistência de objetos deve herdar da superclasse
TdpoPersistentObject, direta ou indiretamente. Nesta superclasse estão
definidos todos os métodos e atributos necessários para a manipulação e
gerenciamento do mecanismo de persistência e de mapeamento;
30
Em caso de herança, a classe pai deve herdar de TdpoPersistentObject ou
herdar de uma classe que já herde, para que os métodos e atributos de
persistência e mapeamento possam estar presentes na classe filho;
DePO utiliza a RTTI (Run Time Type Information) do Delphi para poder
acessar as propriedades publicadas, somente estas propriedades poderão
ser persistidas e mapeadas pelo DePO;
Como é utilizado o conceito de propriedades do Delphi (property) para poder
modificar e recuperar os valores dos atributos de um objeto, o
encapsulamento é respeitado.
As principais propriedades de configuração do DePO estão descritas na Tabela
4.1.
Tabela 4.1. Principais Propriedades e Métodos do DePO
Propriedade Descrição
AttributeName Define o nome do atributo que está na seção published, que será persistido
AttributesMapping Declara todos os atributos da classe que serão persistidos Bindings Define qual atributo resolverá o relacionamento Cardinality Define a cardinalidade do relacionamento ClassObject Declara a classe a ser mapeada ColumnName Declara o nome da coluna no modelo relacional IndexType Indica a criação de índice e tipo de índice IsOid Identifica se o atributo é o identificador da classe MasterAttribute Define o atributo responsável pelo relacionamento RelatedClass Declara a classe com a qual é feito o relacionamento RelatedObject Declara o objeto com o qual é feito o relacionamento RelationshipsMapping Declara todos os relacionamentos da classe Required Indica se o atributo é campo obrigatório na tabela Retrieve Função que recupera o objeto da base de dados Retrieved Função que verifica se o objeto foi recuperado Size Define o tamanho do campo na tabela StorageName Declara a tabela onde os objetos serão persistidos
A Listagem 4.1 fornece um exemplo de criação de classes utilizando o DePO. O
exemplo mostra uma herança, em que TAluno e TProfessor herdam da superclasse
TPessoa.
Listagem 4.1. Definição das Classes
type TPessoa = Class; TAluno = Class; TProfessor = Class;
31
TPessoa = class(TdpoPersistentObject) private FCodigo: Integer; FNome: String; published property Codigo: Integer read FCodigo write FCodigo; property Nome: String read FNome write FNome; end;
TProfessor = class(TPessoa) private FCPF: Integer; published property CPF: Integer read FCPF write FCPF; end; TAluno = class(TPessoa) private FMatricula: Integer; published property Matricula: Integer read FMatricula write FMatricula; end;
4.1.3 Relacionamentos Existem duas estratégias de se definir um relacionamento: utilizar os métodos,
classes e propriedades disponibilizados pelo DePO, ou defini-los manualmente (gerenciando
os relacionamentos de forma manual, sem auxílio do framework).
O DePO implementa todos os recursos necessários para a definição de
relacionamentos. Dentre as características principais são citadas (DAIBERT, JULIO e
ARAUJO, 2005):
tipo responsável por resolver um relacionamento através do mapeamento:
TdpoRelationshipResolver; propriedade RelatedObject, responsável por retornar os objetos relacionados
de uma classe;
método Bindings.Add, adiciona um atributo na classe referenciada. Este
atributo guarda informações referentes ao objeto referenciado, funcionando
como uma chave estrangeira no modelo relacional;
método RelationshipsMapping.Add, responsável por definir o mapeamento
objeto-relacional dos relacionamentos.
Para múltiplas referências, ou seja, quando um objeto referencia “n” outros
objetos, o DePO possui recursos de gerenciamento de coleções de objetos em uma classe,
permitindo o mapeamento de relacionamentos de grau “n” entre classes. Este recurso é
32
especialmente útil quando temos um relacionamento entre objetos em que uma instância
pode referenciar-se a várias outras instâncias.
A criação de uma estrutura de coleção de objetos se faz necessária para que
possa manter a navegabilidade bidirecional. Esta estrutura pode ser traduzida no modelo
relacional para uma tabela navegacional.
Para isso, é necessário criar uma nova classe, herdando de uma superclasse
chamada TdpoPersistentObjectList, responsável por intermediar o acesso aos objetos que
compõe a lista.
4.1.4 Mapeamento Objeto-Relacional O componente dpoDBMappingManager é uma implementação da interface
necessária para que a tarefa de mapeamento objeto-relacional possa ser realizada. Toda a
interação com este componente é feita através de mecanismos específicos para a conexão
com o SGDB. Atualmente estão implementados os mecanismos ADOMechanism para
comunicação utilizando ADOConnection e o DBXMechanism para comunicação utilizando
SQLConnection do DBExpress (DAIBERT, JULIO e ARAUJO, 2005).
Na atual versão do DePO existem funcionalidades para o mapeamento das
classes em arquivos XML. Esta implementação carrega um arquivo XML com as definições
de mapeamento substituindo o mapeamento feito dentro da aplicação.
É importante que o mapeamento das classes seja executado antes de instanciar
qualquer objeto desta classe. Isto pode ser feito no evento OnCreate do Form Principal
(DAIBERT, JULIO e ARAUJO, 2005). É interessante criar um procedimento e adicionar toda
a codificação do mapeamento e assim chamá-lo no evento OnCreate. Na Listagem 4.2
pode ser verificado um exemplo de mapeamento da classe TPessoa, TAluno e TProfessor. Listagem 4.2. Mapeamento das Classes
procedure TPrincipal.FormCreate(Sender: TObject); begin
with dpoDBMappingManager.Classes.Add do begin ClassObject := TPessoa; StorageName := 'Pessoa'; with AttributesMapping.add do begin AttributeName := 'Codigo'; IsOid := True; ColumnName := 'Codigo'; IndexType := idxUnique; Required := True; end; with AttributesMapping.add do begin
33
AttributeName := 'Nome'; IsOid := False; ColumnName := 'Nome'; Required := True; Size := 100; end;
end; with dpoDBMappingManager.Classes.Add do begin ClassObject := TAluno; InheritsMappingFrom := TPessoa; StorageName := 'Aluno'; with AttributesMapping.add do begin AttributeName := 'Codigo'; IsOid := True; ColumnName := 'Codigo'; IndexType := idxUnique; Required := True; end; with AttributesMapping.add do begin AttributeName := 'Matricula'; IsOid := False; ColumnName := 'Matricula'; Required := True; end; end; with dpoDBMappingManager.Classes.Add do begin ClassObject := TProfessor; InheritsMappingFrom := TPessoa; StorageName := 'Professor'; with AttributesMapping.add do begin AttributeName := 'Codigo'; IsOid := True; ColumnName := 'Codigo'; IndexType := idxUnique; Required := True; end; with AttributesMapping.add do begin AttributeName := 'CPF'; IsOid := False; ColumnName := 'CPF'; Required := True; end; end;
end;
Observa-se que, no mapeamento das classes TProfessor e TAluno, é redefinido
o atributo identificador da superclasse (Codigo) para que o DePO possa resolver herança.
Além disso, o atributo InheritsMappingFrom é definido com o nome da classe pai
(TPessoa) (DAIBERT, JULIO e ARAUJO, 2005).
Um ponto importante na persistência de objetos em um SGBD relacional é como
a camada de persistência vai se relacionar com a base de dados. No DePO, existem
34
métodos que sincronizam as tabelas da base de dados com o modelo mapeado. Caso não
exista a tabela na base de dados, o DePO fará esta sincronização, criando a tabela. O
método ApplySchemaInfo do TdpoCustomMechanism, criará as instruções SQL
necessárias para esta sincronização. É disponibilizado junto com os códigos fontes do
framework classes com diversos métodos utilitários. É o caso do método
__InitializeDatabase(dpoDBXMechanism), que ao ser invocado faz a leitura do
mapeamento e gera automaticamente as tabelas na base de dados relacional.
4.1.5 Manipulação de Objetos A manipulação de objetos é feita através de operações elementares definidas
pela sigla CRUD: Criar (Create), Recuperar (Retrieve), Atualizar (Update) e Excluir (Delete)
(AMBLER, 2000).
Todos os métodos necessários para operações CRUD são definidos na
superclasse TdpoPersistentObject e herdados pela classe que irá persistir os objetos
(DAIBERT, JULIO e ARAUJO, 2005).
A Listagem 4.3 apresenta a instanciação e persistência, através do método
Save, de um objeto da classe TAluno. A Listagem 4.4 exemplifica a recuperação de um
objeto, através do método Retrieve. Este método retorna true quando obtiver sucesso na
recuperação do objeto e false em caso contrário. A Listagem 4.5, por sua vez, apresenta
uma atualização de um objeto, basicamente combinando as técnicas de recuperação e
persistência. Finalmente, a Listagem 4.6 exemplifica a exclusão de um objeto recuperado,
através do método Delete seguido do método Save.
Listagem 4.3. Instanciação e Persistência de um Objeto
var Aluno: TAluno; begin Aluno:= TAluno.Create(dpoDBXMechanism); Aluno.Codigo:= '1'; Aluno.Nome:= 'José da Silva'; Aluno.Matricula:= '2002102013'; Aluno.Save; end;
Listagem 4.4. Recuperação de um Objeto
var Aluno: TAluno; begin Aluno:= TAluno.Create(dpoDBXMechanism); Aluno.Codigo:= '1'; if not Aluno.Retrieve then begin
35
MessageDlg('Aluno não existe', mtWarning, [mbOK], 0); end; end;
Listagem 4.5. Atualização de um Objeto
var Aluno: TAluno; begin Aluno:= TAluno.Create(dpoDBXMechanism); Aluno.Codigo:= '1'; if Aluno.Retrieve then begin Aluno.Nome:= 'Joaquim Souza'; Aluno.Save; end; end;
Listagem 4.6. Exclusão de um Objeto
var Aluno: TAluno; begin Aluno:= TAluno.Create(dpoDBXMechanism); Aluno.Codigo:= '1'; if Aluno.Retrieve then begin Aluno.Delete; Aluno.Save; end; end;
4.1.6 Considerações Finais O DePO é um framework de persistência opensource para o ambiente de
desenvolvimento Delphi que realiza bem a sua função dentro de uma aplicação utilizando o
paradigma orientado a objetos.
De aprendizado relativamente fácil, o DePO pode ser usado tranquilamente em
projetos de desenvolvimento de software, não demandando muito tempo para adequação do
programador ao framework. É requerida mais atenção por parte do programador quando for
definido e mapeado um relacionamento entre classes, uma vez que este processo é mais
complicado.
Atualmente, o DePO está sendo desenvolvido por um brasileiro e conta com a
ajuda de uma grande comunidade de desenvolvedores no Brasil, facilitando assim o
processo desenvolvimento de algum projeto com o framework, visto que o acesso aos
desenvolvedores é facilitado. Existe inclusive um fórum específico para tirar dúvidas de
utilização (http://www.oodesign.com.br/forum/).
36
Entretanto, a documentação deixa desejar, não apresentando todas as suas
funcionalidades, muito menos exemplos de utilização. Somente no site do desenvolvedor
(DEPO, 2005) é que são encontrados alguns exemplos, mesmo assim nem todos os
códigos fonte encontrados estão comentados, dificultando assim o entendimento.
4.2 Instant Objects O Instant Objects (IO, 2005), assim como o DePO, também é um framework que
se propõe a realizar, de forma intrusiva, a persistência de objetos de um sistema orientado a
objetos. Além de realizar a persistência em sistemas gerenciadores de banco de dados
relacionais, o Instant Objects ainda persiste os objetos em arquivos XML. Ele possui uma
interface para a definição das classes do modelo, facilitando o trabalho de desenvolvimento
da aplicação.
Esta interface pode ser acessada pelo item Model Explorer do menu View,
após os pacotes do Instant Objects estarem devidamente instalados na distribuição do
Delphi. A Figura 4.3 mostra esta interface de configuração de classes. Ao utilizar o Model Explorer para criar classes, é então gerado automaticamente código fonte Delphi das
mesmas.
Figura 4.3. Model Explorer
Atualmente o Instant Objects é compatível com a versão 6, 7, 2005 e 2006 do
Delphi, além da compatibilidade com o Kylix 3 para ambiente Linux. Até a versão 1.6 do
framework, todas as conexões com a base de dados eram feitas através dos componentes
data-aware do Delphi (componentes que se conectam diretamente à base de dados através
de alguma fonte de dados). A partir da versão 2.0, novas implementações de conexão ao
banco de dados foram suportadas, não havendo a necessidade de comunicação com a
base de dados utilizando os componentes data-aware, no entanto ainda é suportado este
tipo de prática.
37
4.2.1 Componentes Instant Objects Depois de instalado, o Instant Objects cria um paleta de mesmo nome no painel
de paletas da IDE do Delphi, como pode ser visto na Figura 4.4, além de criar um acesso ao
Model Maker através do menu View.
Figura 4.4. Componentes Instant Objects
Para iniciar um projeto com o Instant Objects, é necessário configurar os
componentes de acesso ao banco de dados e adicionar as classes através do Model Maker.
Para a configuração dos componentes de acesso à base de dados deve-se
instalar o broker (componente de interface para acesso aos dados) específico. Existe uma
grande variedade de brokers para conexão às bases de dados relacionais implementados
no Instant Objects, entre elas as mais usadas são: DBXConnection, ADOConnection, Zeos,
IBX, BDE.
No exemplo da Figura 4.4 está sendo usado o componente broker
InstantDBXConnector que usa a interface DBXConnection. Para esta configuração é
necessário adicionar no projeto um componente do tipo SQLConnection e associá-lo ao
InstantDBXConnector. Observe que o responsável por conectar ao banco de dados é o
componente do Delphi. O InstantDBXConnetor é somente a interface de acesso do
InstantObjects à base de dados.
No componente SQLConnection são configurados os dados de acesso à base
de dados, como caminho, sql dialect, usuário e senha. Os demais componentes disponíveis
na paleta são para auxiliar na construção das aplicações, além de componentes visuais para
facilitar a manipulação das informações dos objetos persistidos. As demais funcionalidades
do Instant Objects são acessadas via código fonte.
O próximo passo é incluir as classes do modelo na aplicação através do Model Maker, e então criar as tabelas da base de dados, através do botão Build DataBase,
38
disponível na sua interface. O Instant Objects gera automaticamente as tabelas de acordo
com as classes inseridas.
4.2.2 Classes e Propriedades Ao adicionar as classes do modelo no Model Explorer, deve-se inicialmente
configurar a unit que armazenará o código fonte gerado, e isso deve ser feito acessando o
botão selecionar units (select units) presente na interface.
Para incluir uma nova classe ao projeto, clique com o botão direito sobre a
interface e selecione o item nova classe (new class). Aparece então uma janela, como
exemplificado na Figura 4.5, com a interface necessária para adicionar todos os itens da
classe, como:
nome da classe;
superclasse (toda classe que efetuar a persistência de objetos deve herdar da
superclasse TInstantObject, direta ou indiretamente. Nesta classe estão
definidos todos os métodos e atributos necessários para a manipulação e
gerenciamento do mecanismo de persistência do framework);
unit onde o código fonte gerado é armazenado;
tipo de persistência (Stored para classe persistente, ou seja, para classe que
irá persistir informações e Embedded para não persistente);
nome da tabela gerada no modelo relacional;
atributos.
Figura 4.5. Adicionando Nova Classe
39
Em atributos é configurado o tipo do atributo, nome, se ele é privado ou público,
o nome do campo gerado na tabela no modelo relacional, entre outros. Pode-se também
definir uma espécie de máscara para o atributo, como por exemplo, a máscara para o CPF.
Este recurso é interessante uma vez que o próprio framework se responsabiliza pela
validação da máscara e dos dados digitados na aplicação.
Observe que ao definir as classes através do Model Explorer, o desenvolvedor
está definindo também o mapeamento objeto-relacional do modelo. Ele mapeia quais
classes e atributos se tornarão tabelas e campos no modelo relacional.
Na Listagem 4.7 abaixo, é exibido o código fonte gerado automaticamente pelo
Instant Objects após a criação das classes. Observe que são gerados automaticamente
também os gets e sets dos atributos, para que o encapsulamento seja mantido. Note a
existência de um comentário entre a definição das classes, iniciando com IOMETADATA. É
através deste comentário que o Instant Objects enxerga o mapeamento e
consequentemente gera automaticamente o código SQL para criar as tabelas na base de
dados relacional.
Listagem 4.7. Definição das Classes
type TAluno = class; TPessoa = class; TProfessor = class; TPessoa = class(TInstantObject) {IOMETADATA stored; Nome: String(100) default; } _Nome: TInstantString; private function GetNome: string; procedure SetNome(const Value: string); published property Nome: string read GetNome write SetNome; end; TAluno = class(TPessoa) {IOMETADATA stored; Matricula: Integer default; } _Matricula: TInstantInteger; private function GetMatricula: Integer; procedure SetMatricula(Value: Integer); published property Matricula: Integer read GetMatricula write SetMatricula; end; TProfessor = class(TPessoa) {IOMETADATA stored; CPF: Integer default; } _CPF: TInstantInteger; private function GetCPF: Integer; procedure SetCPF(Value: Integer);
40
published property CPF: Integer read GetCPF write SetCPF; end;
Diferentemente do framework DePO, o Instant Objects faz o controle automático
do OID (Object Identification). O desenvolvedor não precisa declarar o atributo identificador
do objeto, tão menos declarar que campo será a chave primária no modelo relacional.
O Model Explorer possui ainda a funcionalidade de importação e exportação do
modelo de classes nele criado. Para isso basta acessar a opção disponível no clique do
botão direito da interface chamada exportar modelo (Export Model). Ao clicar é gerado um
arquivo XML com toda a estrutura e definições das classes.
Feita a criação das classes, deve-se então criar as tabelas na base de dados.
Para realizar esta tarefa é necessário clicar no botão construir banco de dados (build
database), disponível na interface do Model Explorer. É então exibida uma janela para
configuração de acesso à base de dados e criação das tabelas, como pode ser
exemplificado na Figura 4.6 abaixo.
Figura 4.6. Criação das Tabelas em Base de Dados Relacional
41
Com isso, as tabelas são criadas no banco de dados relacional e prontas para
persistirem as informações dos objetos, diferentemente do framework DePO, onde as
tabelas são criadas na execução do programa.
4.2.3 Relacionamentos O Instant Objects possui uma estrutura especializada para a definição de
relacionamentos entre classes. Todos os relacionamentos são definidos através de escolha
de atributos chaves. Essa funcionalidade pode ser explorada no Model Explorer, quando se
define os atributos. A Figura 4.7 exemplifica o uso do tipo referencia (Reference) para o
atributo. O tipo referência é utilizando quando um objeto de classe referencia um único outro
objeto, como nos relacionamentos do tipo 1:1 e 1:n. Na Figura 4.7 pode-se observar o
relacionamento entre as classes TCurso e TDisciplina (uma disciplina é de um curso e um
curso pode ter várias disciplinas – Associação do tipo 1:n). Já a Figura 4.8 está sendo
exemplificado o uso do tipo referências (References) do atributo. Este tipo é utilizado
quando um objeto de classe referencia vários outros, como nos relacionamentos do tipo n:n.
É exemplificado na figura o relacionamento entre as classes TCurso e TAluno (um curso
pode ter vários aluno e um aluno pode cursar vários cursos – associação do tipo n:n).
Observa-se que para este tipo é requerido o nome para a tabela navegacional (External
Storage Name), que manterá a navegabilidade entre os objetos referenciados.
Figura 4.7. Criação de Atributo de Relacionamento para uma Referência
42
Figura 4.8. Criação de Atributo de Relacionamento para Várias Referencias
Para gerenciar listas de objetos, o Instant Objects possui uma estrutura
semelhante a um ClientDataSet, o componente InstantSelector. Quando adicionado na
aplicação, fornece uma estrutura de recuperação de objetos via consultas SQL, como é visto
na Figura 4.9. No componente pode-se definir qual a classe e qual o atributo são parâmetros
para a consulta.
Figura 4.9. Configuração do Componente InstantSelector
43
Para executar a consulta configurada no componente basta executar o
procedimento Open. Feito isso, o componente já estará com a lista de objetos resultantes
da consulta na memória prontos para serem manipulados de forma transparente ao
desenvolvedor. Todo o manejo dos objetos dentro do componente é muito semelhante ao
manejo de dados em um ClientDataSet.
A consulta configurada no componente pode também ser configurada de forma
dinâmica via código fonte, aumentando assim as possibilidades de desenvolvimento com
este componente, inclusive a criação do conceito de critério (criteria) de recuperação de
objetos, usando a cláusula WHERE do SQL.
4.2.4 Mapeamento Objeto-Relacional Todo o mapeamento objeto-relacional no Instant Objects é feito na definição das
classes através da interface do Model Explorer. Não é necessário mais nenhum tipo de
esforço de programação.
Quando se define uma classe é definido também o seu mapeamento para o
modelo relacional. O mesmo ocorre quando se define um atributo desta classe.
4.2.5 Manipulação de Objetos Assim como o DePO, a manipulação de objetos pelo Instant Objects também é
feita através das operações elementares definidas pela sigla CRUDs: Criar (Create),
Recuperar (Retrieve), Atualizar (Update) e Excluir (Delete). Não é necessário escrever uma
única linha de código SQL para se manipular os objetos.
Todos os métodos necessários para operações CRUDs são definidos na
superclasse TInstantObject e herdados pelas classes persistentes do modelo definido pelo
desenvolvedor.
A Listagem 4.8 apresenta a instanciação e persistência, através do método
Store, de um objeto da classe TAluno. A Listagem 4.9 exemplifica a recuperação de um
objeto, através do método construtor Retrieve. Este método instancia um objeto com os
parâmetros passados para ele. A Listagem 4.10, por sua vez, apresenta uma atualização de
um objeto, basicamente combinando as técnicas de recuperação e persistência. Já a
Listagem 4.11 exemplifica a exclusão de um objeto recuperado, através do método
Dispose.
44
Listagem 4.8. Instanciação e Persistência de um Objeto
var objAluno : TAluno; begin objAluno := TAluno.Create(dtmdlConexao.InstantDBXConnector); objAluno.Nome := 'José da Silva'; objAluno.Matricula := 2002102013; objAluno.Store(); end;
Listagem 4.9. Recuperação de um Objeto
var objAluno : TAluno; begin try objAluno := TAluno.Retrieve('ID',false,false,dtmdlConexao.InstantDBXConnector); except MessageDlg('Aluno não Existe', mtWarning, [mbOK], 0); end; end; Listagem 4.10. Atualização de um Objeto
var objAluno : TAluno; begin try objAluno := TAluno.Retrieve('ID',false,false,dtmdlConexao.InstantDBXConnector); objAluno.Nome := 'Joaquim Souza'; objAluno.Matricula := 2003201245; objAluno.Store(); except MessageDlg('Aluno não Existe', mtWarning, [mbOK], 0); end; end;
Listagem 4.11. Exclusão de um Objeto
var objAluno : TAluno; begin try objAluno := TAluno.Retrieve('ID',false,false,dtmdlConexao.InstantDBXConnector); objAluno.Dispose(); except MessageDlg('Aluno não Existe', mtWarning, [mbOK], 0); end; end;
4.2.6 Considerações Finais O Instant Objects é um framework extremamente fácil de se lidar, com um
aprendizado muito rápido. Após sua versão 1.6 houve um grande avanço com relação à
maleabilidade de uso não necessitando utilizar componentes data-aware do Delphi.
45
A interface Model Explorer viabiliza o curto aprendizado do framework,
facilitando o desenvolvimento de aplicações. Ela diminui o esforço de programação do
desenvolvedor, deixando-a intuitiva e simples. Todo o mapeamento objeto-relacional é feito
de forma visual e muito menos suscetível a erros.
O framework conta com um suporte baseado em fóruns de discussão, onde a
comunidade que o utiliza ajuda os usuários menos experientes
(http://delphi.newswhat.com/geoxml/forumlistgroups?area=instantobjects). Entretanto, a
documentação, assim como a do DePO, também deixa a desejar. A documentação do
Instant Objects consiste em arquivos de texto explicando basicamente a sua instalação e
qual a utilidade de cada arquivo do seu código fonte. Não existe nenhum documento
explicando e exemplificando o uso de suas funcionalidades e métodos.
O único recurso que existe para exemplificar o seu uso é um vídeo tutorial
disponível para download no site do desenvolvedor, além de cinco pequenas aplicações
exemplo, com seu código fonte não comentado, dificultando assim o entendimento.
4.3 TechInside Object Persistent Framework O TiOPF (TechInside Object Persistent Framework) (TIOPF, 2005) é um
framework de persistência objeto-relacional mais complexo que os demais acima
apresentados. Toda a estrutura de conexão à base de dados, bem como a estrutura de
mapeamento objeto-relacional é feitos via código fonte, diferentemente dos já apresentados,
que possuem componentes visuais para efetuar tal tarefa.
Também de código fonte aberto (opensource), o TiOPF possui uma estrutura
interessante de desenvolvimento. A empresa que o desenvolve, a TechInside, possui uma
política de testes unitários automáticos com o Dunit (DUNIT, 2005) que proporciona maior
confiabilidade e estabilidade nos códigos fontes desenvolvidos, e consequentemente menos
bugs para os usuários.
O DUnit, é um sistema que efetua testes unitários nas classes e métodos
escritos em Delphi e verifica a integridade das mesmas. Originalmente inspirado no JUnit,
para Java, o DUnit cumpre muito bem sua tarefa e proporciona uma agilidade na
programação, uma vez que os testes são feitos de forma automática (DUNIT, 2005).
O framework TiOPF é compatível com as versões 5, 6 e 7 do Delphi.
46
4.3.1 Componentes TiOPF Depois de instalado, o TiOPF cria uma paleta chamada TechInside no painel de
paletas da IDE do Delphi, como pode ser visto na Figura 4.10.
Figura 4.10. Componentes TiOPF
O TiOPF possui uma grande quantidade de componentes disponíveis para o
uso, no entanto, praticamente todos os exibidos na Figura 4.10 são componentes data-
aware para acesso aos dados do framework. Não existem componentes de configuração
visual dos dados, o que o torna mais complexo de utilizar. Toda a configuração de acesso
ao banco de dados e o mapeamento objeto-relacional é feito via código fonte.
Dentre os componentes existentes é exemplificado o tiListView, semelhante ao
ListView do Delphi, o tiPerAwareEdit, semelhante ao Edit, o tiPerAwareMemo, semelhante
ao memo, entre outros. São no total 29 componentes disponíveis, sendo 27 data-aware.
Estes componentes possuem toda a estrutura para conexão ao mecanismo de persistência
do framework de forma natural, o que o torna os componentes do Delphi incompatíveis com
o framework.
Para persistência de dados, o TiOPF conta com a implementação das seguintes
estratégias: banco de dados relacional, arquivos XML e arquivos CSV (Comma Separate
Values). Para conexão ao banco de dados estão implementados suporte ao IBX (Interbase e
Firebird), OracleDOA (Oracle), BDE (Paradox) e ADO (MS Access e SQL Server).
O primeiro passo para se utilizar o TiOPF em um projeto e configurar o acesso à
base de dados. O mesmo deve ser feito como exemplificado pela Listagem 4.12. Veja que é
passado como parâmetro o caminho da base de dados, usuário, senha e a estratégia de
persistência (IBX, ADO, XML, CSV). O TiOPF possui uma espécie de gerente para o acesso
à camada de persistência. Este gerente é um objeto da classe tiPerAwareCtrls,
responsável pelo gerenciamento das conexões e manipulação dos objetos na base de
dados relacional.
O framework não possui nenhum recurso de geração automática das tabelas na
base de dados relacional. As mesmas devem ser criadas manualmente ou através de
métodos disponíveis nas classes do TiOPF, como exemplificado pela Listagem 4.13 abaixo.
Observe a criação da tabela Aluno, com os campos OID, Matricula e Nome. Já na listagem
4.14 é exibido um exemplo que verifica se alguma tabela existe no banco de dados. A
Listagem 4.15 exemplifica o uso dos métodos de se excluir tabelas diretamente na base de
47
dados. Lembrando que para acessar estes métodos do framework é necessário dar uses
nas units do TiOPF que gerenciam as conexões: tiPersist, tiDBConnectionPool e
tiPerAwareCtrls.
Listagem 4.12. Configurando o Acesso à Base de Dados.
gTIPerMgr.LoadPersistenceLayer('IBX','Dados.gdb','sysdba','masterkey');
Listagem 4.13. Criando Tabela
var lTableMetaData : TtiDBMetaDataTable ; begin lTableMetaData := TtiDBMetaDataTable.Create ; try Screen.Cursor := crHourGlass; lTableMetaData.Name := 'Aluno' ; lTableMetaData.AddField( 'OID', qfkString, 36 ) ; lTableMetaData.AddField( 'Nome', qfkString, 70 ) ; lTableMetaData.AddField( 'Matricula', qfkInteger) ; gTIPerMgr.CreateTable( lTableMetaData ) ; finally lTableMetaData.Free; Screen.Cursor := crDefault; end ; end;
Listagem 4.14. Verifica Existência da Tabela
var lDBMetaData : TtiDBMetaData ; lPooledDB : TPooledDB ; lDatabase : TtiDatabase ; begin lDBMetaData := TtiDBMetaData.Create ; try lPooledDB := gTIPerMgr.DefaultDBConnectionPool.Lock ; try lDatabase := lPooledDB.Database ; lDatabase.ReadMetaDataTables(lDBMetaData); result := lDBMetaData.FindByTableName('Aluno') <> nil; finally gTIPerMgr.DefaultDBConnectionPool.UnLock(lPooledDB); end ; finally lDBMetaData.Free; end ; end; Listagem 4.15. Exclusão de Tabela
gTIPerMgr.DropTable( 'Aluno' );
4.3.2 Classes e Propriedades Assim como os frameworks já citados neste trabalho, o TiOPF também é um
framework intrusivo. Por este motivo, todas as classes definidas para serem persistidas
48
utilizando o TiOPF devem herdar diretamente ou indiretamente da superclasse TPerObjAbs,
como exemplificado na Listagem 4.16 onde é definida a classe TAluno.
Da mesma forma que o DePO, o TiOPF se utiliza da RTTI (Run Time Type
Information) do Delphi para ter acesso às propriedades dos objetos e consequentemente
aos seus atributos, por esta razão, todos os atributos dos objetos persistentes devem ser
declarados como propriedades na seção published na definição das classes.
Listagem 4.16. Definição das Classes
TPessoa = class (TPerObjAbs) private FNome : string; published property Nome: string read FNome write FNome; end; TProfessor = class (TPessoa) private FCPF : Integer; published property Matricula : Integer read FCPF write FCPF ; end; TAluno = class(TPessoa) private FMatricula : Integer; published property Matricula : Integer read FMatricula write FMatricula ; end;
4.3.3 Relacionamentos O TiOPF não dispõe de nenhuma estrutura especialista para gerenciar
relacionamentos, como os demais frameworks apresentados. Os mesmos devem ser feitos
de forma manual. O único auxílio que o framework presta para esta tarefa é a criação
automática do campo de ligação das tabelas no modelo relacional quando um objeto
referencia outro objeto, como exemplificado na Listagem 4.17.
Veja que a classe TProfessor possui um atributo do tipo TDisciplina. Quando isto
acontece, o TiOPF cria automaticamente um campo no modelo relacional que referencia o
OID de TDisciplina, criando então o conceito de chave estrangeira.
Listagem 4.17. Definição de Relacionamento
TProfessor = class(TPessoa) private FCPF : Integer; FDisciplina : TDisciplina; published property CPF : Integer read FCPF write FCPF ;
49
property Disciplina : TDisciplina read FDisciplina ; end; TDisciplina = class(TPerObjAbs) private FNome : String; FEmenta : String; published property Nome : String read FNome write FNome; property Ementa : String read FEmenta write FEmenta; end;
O framework dispõe ainda de uma estrutura de gerenciamento de listas de
objetos. Isto é feito através da classe TPerObjList. Quando um objeto herda desta classe,
ele herda consigo todos os métodos e atributos que o TiOPF dispõe para, de forma efetiva,
gerenciar uma lista de objetos. A Listagem 4.18 trás um exemplo de utilização desta classe.
Um recurso interessante desta classe é a persistência automática de vários objetos da lista.
Usando o método Add(), o desenvolvedor adiciona um objeto na lista e utilizando o método
Save(), ele persiste todos os objetos contidos naquela lista. Listagem 4.18. Definição da Classe de Lista de Objetos
TAlunos = class( TPerObjList ) private protected function GetItems(i: integer): TAluno ; reintroduce ; procedure SetItems(i: integer; const Value: TAluno); reintroduce ; public property Items[i:integer] : TAluno read GetItems write SetItems ; procedure Add( pObject : TAluno ; pDefDispOrdr : boolean=true); reintroduce ; procedure Clear ; override ; procedure Read ; override ; published end;
A classe TAlunos acima exemplificada é capaz então, de prover uma interface
de gerenciar uma coleção de objetos do Tipo TAluno. Este recurso é especialmente útil
quando uma instancia de classe referencia várias outras.
4.3.4 Mapeamento Objeto-Relacional Da mesma forma que o DePO, o mapeamento objeto-relacional deve ser
programado dentro do código fonte da aplicação. Não existe nenhuma outra estratégia a
não ser esta. A Listagem 4.19 exemplifica como que deve ser realizado um mapeamento
objeto-relacional no TiOPF. É com este código que o framework sabe para qual campo e
tabela da base de dados relacional são persistidos os atributos de determinado objeto.
Observa-se no exemplo que é executado o método RegisterMapping para mapear o
50
atributo e tabela e é utilizado o método RegisterCollection para mapear a classe que é
coleção de objetos de outra, como exemplificado anteriormente neste trabalho.
Listagem 4.19. Mapeamento Objeto-Relacional
gTIPerMgr.ClassDBMappingMgr.RegisterMapping(TAluno,'Aluno','OID','OID', [pktDB] ); gTIPerMgr.ClassDBMappingMgr.RegisterMapping(TAluno,'Aluno','Matricula','Matricula'); gTIPerMgr.ClassDBMappingMgr.RegisterCollection(TAlunos, TAluno);
O primeiro parâmetro a ser passado para o método RegisterMapping é o nome
da classe. No exemplo apresentado, a classe é a TAluno. O segundo é o nome da tabela
no modelo relacional que esta classe foi mapeada. O terceiro parâmetro é o nome da
propriedade de classe a ser mapeada. E por fim, o quarto é o nome do campo que a
propriedade foi mapeada no modelo relacional.
O mapeamento deve ser executado assim que a aplicação for carregada.
4.3.5 Manipulação de Objetos A manipulação de objetos através do framework TiOPF é feita através dos
componentes data-aware disponibilizados pela TechInside. Basicamente, todos os
componentes possuem um método de associação a um atributo de algum objeto, como por
exemplo, associar o componente tiAwareEdit ao atributo nome do aluno. Assim que for
adicionado algum texto no componente, este automaticamente popula o atributo do objeto.
Feito isso, o objeto é adicionado em uma lista de objetos e pode ser salvo
invocando o método Save() da lista de objetos. Para recuperar um objeto, o processo é o
mesmo, só que antes os objetos são recuperados na memória através do método List() da
lista. Com esta lista de objetos na memória é então facilitada a manipulação dos mesmos.
Existe ainda um recurso de recuperar objetos através de critérios.
Para que isso possa ser feito, deve-se criar uma outra classe herdando da
superclasse tiAwareCriteria. Nesta superclasse estão todos os métodos e atributos que
fornecem a estrutura de recuperação através de critérios de classificação. Este recurso
consiste em aceitar consultas SQL e recuperar os objetos que atendam ao que foi
consultado.
Para se excluir um objeto, primeiro se recupera e depois através do componente
data-aware é executado o método Delete. Com isso, o objeto é destruído da memória e tem
o seu registro excluído na base de dados relacional.
51
4.3.6 Considerações Finais O TiOPF se mostra um framework de persistência bastante complexo e de difícil
utilização. A sua curva de aprendizado é bem maior, quando comparado ao DePO ou ao
Instant Objects. A sua falta de recursos visuais e integração com a IDE do Delphi o torna
complicado de configurar e consequentemente mais suscetível à falhas.
Um outro ponto negativo de sua utilização é a obrigatoriedade do uso dos
componentes data-aware por ele disponibilizados. Esta obrigatoriedade restringe as
possibilidades de programação e desenvolvimento aos 29 componentes disponíveis. No
entanto, ele cumpre muito bem sua tarefa de manipular objetos em uma base de dados
relacional.
Sua documentação, assim como todos os frameworks apresentados, também
deixa a desejar, no entanto, é o único que possui uma gama de exemplos com código fonte
documentados, facilitando assim o entendimento.
4.4 Conclusão Este capítulo apresentou três frameworks opensource de persistência e
manipulação de objetos em sistemas gerenciadores de banco de dados relacionais para o
ambiente de desenvolvimento Delphi.
O primeiro apresentado foi o DePO (Delphi Persistent Objects). Este framework
possui toda uma estrutura para adequar o modelo orientado a objetos para o modelo
relacional. Foram apresentados exemplos da sua utilização, desde criação das classes
persistentes, até a manipulação de objetos (criar, recuperar, atualizar e excluir).
O Instant Objects foi o segundo a ser apresentado. Ele possui uma interface de
configuração chamada Model Explorer, que praticamente anula o esforço de programação
existente para adequar o modelo orientado a objetos para o modelo relacional. Esta
interface visual facilita o trabalho do desenvolvedor, além de minimizar os problemas que
por ventura podem ocorrer quando a configuração é feita via código fonte.
Ao final, foi apresentado o framework TiOPF (TechInside Object Persistent
Framework). Este, de aprendizado mais difícil, não possui nenhum recurso visual de
configuração. Toda a configuração é realizada via código fonte. Ele obriga o desenvolvedor
a utilizar seus componentes data-aware para a manipulação dos objetos, o que implica que
as aplicações tenham sempre as mesma interfaces, além de restringir o desenvolvedor a
sempre utilizar estes componentes.
Na Tabela 4.2 abaixo, é apresentado um comparativo entre os frameworks,
considerando os requisitos desejáveis de uma camada de persistência. Cada framework
52
comparado esta disposto em uma coluna que é relacionada com os requisitos que estão
apresentados nas linhas da tabela. Os requisitos de uma camada de persistência foram
apresentados e conceituados no item 3.2.3.1 deste trabalho.
Tabela 4.2. Comparativo Entre os Frameworks
Requisitos Framework
DePO InstantObjects TiOPF Diversos tipos de mecanismos de persistência X Encapsulamento da camada de dados X X X Ações com multi-objetos X X X Transações X X Extensibilidade X X X Geração de identificadores de objetos X X Cursores e proxies Registros X X X Múltiplas Arquiteturas X X X Diversas versões de banco de dados X X X Múltiplas conexões X X Consultas SQL X X Controle de concorrência X X X
53
5 ESTUDO DE CASO
5.1 Introdução O estudo de caso proposto neste trabalho baseia-se no estudo de caso utilizado
no projeto de iniciação científica “Estratégia de Persistência de Software Orientado a Objeto”
da faculdade Metodista Granbery, no qual o discente é participante.
Vislumbrando o estudo de diversas estratégias de persistência em software
orientado a objetos dentro do contexto do projeto de iniciação científica, este estudo de caso
foi escolhido por abordar de forma singular as principais características da orientação a
objetos.
O sistema escolhido para estudo de caso foi o “Sistema de Controle Acadêmico”,
abordado na cadeira de Laboratório de Programação III da Faculdade Metodista Granbery
(ARAUJO, 2004). Esta cadeira tem como objetivo capacitar os discentes para o
desenvolvimento de aplicações no ambiente de desenvolvimento Delphi. No entanto, a
aplicação toda foi desenvolvida com o paradigma estruturado. Coube aos membros do
projeto de iniciação científica fazer uma reengenharia do sistema, transformando-o em um
sistema orientado a objetos.
5.2 Projeto de Iniciação Científica O projeto de iniciação científica intitulado “Estratégias de Persistência em
Software Orientado a Objetos” tem como objetivo o estudo exploratório das tecnologias de
persistência de objetos, incluindo tecnologias de banco de dados orientado a objetos e
objeto-relacionais, além de técnicas de mapeamento objeto relacional.
O seu objetivo é realizar um estudo comparativo entre as abordagens de
persistência em software orientado a objetos, envolvendo banco de dados orientado a
objetos, objeto-relacionais e camadas de mapeamento objeto-relacional para base de dados
relacionais. São avaliadas características como desempenho, soluções encontradas,
dificuldades, vantagens e desvantagens de cada abordagem. O objetivo final do projeto é a
criação de uma camada de persistência própria, para o ambiente de desenvolvimento
Delphi.
O projeto contou inicialmente com um estudo exploratório das tecnologias de
persistência de objetos. Após foi definida uma aplicação protótipo para a validação das
estratégias de persistência. Com isso foi feito um levantamento das soluções de
gerenciadores de banco de dados para a avaliação de viabilidade prática das abordagens.
Foi feita então, uma definição e implementação de uma nova ferramenta de persistência de
54
objetos, compatível com o ambiente Delphi. Ao final foi realizado uma comparação entre as
abordagens estudadas.
5.3 Sistema de Controle Acadêmico O objetivo é construir uma aplicação protótipo usando a ferramenta de
desenvolvimento Delphi para testar como um framework de persistência interage com esta
ferramenta de desenvolvimento e quais as melhores práticas.
O framework de persistência escolhido para a implementação do protótipo é o
DePO (Delphi Persistent Objects). Esta escolha foi fundamentada inicialmente pela
facilidade de uso do framework e sua adequação ao modelo do sistema acadêmico. Além do
fato de que os desenvolvedores do framework serem brasileiros e de mais fácil acesso.
Com a reengenharia do sistema acadêmico, foi aplicado o padrão de projeto
MVC (Model-View-Controller) visando favorecer o estudo das estratégias de persistência,
dividindo o sistema em camadas.
Padrões de projeto são soluções genéricas e reutilizáveis, aplicáveis em classes
de problemas bem conhecidos. Soluções consagradas para problemas conhecidos, tornam-
se receitas para situações similares (desde que estas soluções tenham sido projetadas com
flexibilidade) (SHALLOWAY e TROTT, 2002).
O padrão MVC (Model-View-Controller) é um padrão de projeto bastante usado
em aplicações, pois permite que se separe o modelo de dados das várias formas que o
dado possa ser acessado e manipulado (MVC, 2005). Ou seja, o sistema é divido em
camadas, e esta interagem entre si.
O MVC oferece vantagens significativas no desenvolvimento de aplicativos,
através da separação das camadas, possibilitando implementar com maior facilidade e
clareza questões importantes como a persistência de dados, controle de segurança,
comunicação em rede e fluxo de visualização (SHALLOWAY e TROTT, 2002).
Permite ainda que as equipes de desenvolvimento possam se concentrar em
suas habilidades centrais e integrar as camadas através de interfaces bem definidas. Esta
separação permite que aplicativos possam ser facilmente modificados e estendidos para
atender a novas exigências, bem como possibilita que a interface com o usuário apresente
várias visões de um só modelo sem interferir com a lógica de negócio.
Como mostra a figura 5.1, o usuário interage com o sistema através das
interfaces (View). Estas se comunicam com os controladores (Controllers), que por sua vez
delega requisições para um dos tratadores apropriados, que estão localizados no modelo
55
(Model), que representa a lógica de negócio e o estado da aplicação. A requisição então é
respondida, através do controlador, e apresentada na interface (View), da maneira
adequada.
Figura 5.1. Modelo MVC (ARAUJO, 2005)
No Sistema de Controle Acadêmico, o Model está implementado em uma unit do
Delphi, onde todas as classes de domínio, com seus atributos e métodos, estão lá definidos.
Para o Controller foram criadas classes que levam o nome de gerente. Nos gerentes estão
implementados os métodos de manipulação dos dados recebidos da interface e exibição na
tela, conexões ao banco, entre outras operações. Para este estudo de caso foi utilizado o
conceito de gerente de funcionalidade, ou seja, o gerente é responsável por determinada
funcionalidade no negócio, diferentemente dos gerentes de classe, onde os gerentes são
responsáveis única e exclusivamente pelas classes e suas interfaces de comunicação.
O View é a parte do projeto que são as interfaces, capaz de interagir com o
usuário final, ou seja, são as telas de pesquisa e manutenção de cadastro, além dos
relatórios.
5.4 Implementação
5.4.1 Introdução Buscando explicar e exemplificar a implementação do estudo de caso
apresentado neste trabalho é usado um fragmento do Sistema de Controle Acadêmico. Este
fragmento consiste na manutenção de cursos que compõe a inclusão, alteração, consulta e
exclusão dos dados persistidos pelo framework de persistência DePO.
O objetivo deste tópico é apresentar as interfaces de interação com o usuário e a
implementação das funcionalidades e chamadas do modelo MVC. São apresentados os
diagramas de seqüência com a interação dos fluxos de manutenção de cadastro de curso e,
56
a partir destes diagramas, são mostradas as implementações feitas em cada método
utilizando a linguagem de programação Delphi.
Em anexo a este trabalho (Anexo A), é apresentada toda a documentação do
sistema, seguindo a notação da UML (UML, 2005), além da documentação de requisitos no
padrão IEEE Std 830-1998 (IEEE, 2005).
Buscando exemplificar o fragmento escolhido para a apresentação do sistema, a
Figura 5.2 apresenta o Diagrama de Caso de Uso e a Figura 5.3 apresenta o diagrama de
classes sem atributos e métodos.
Figura 5.2. Diagrama de Caso de Uso
57
Pessoa
ProfessorTurma
10..* 10..*
Curso
1
1
1
1
Coordena
0..*
0..*
0..*
0..*
Aloca
Disciplina
1
0..*
1
0..*
10..* 10..*
Aluno
0..*
0..*
0..*
0..*0..*
1
0..*
1
1..*
1..*
1..*
1..*
Avaliacao
TurmaAluno
0..1
1
0..1
1
Figura 5.3. Diagrama de Classes
É implementado o modelo MVC através das classes de domínio, apresentadas
acima, as classes de controle (gerentes) e as classes de interface. Para as classes de
controle é implementado uma superclasse chamada TGerente, que possui os métodos
virtuais e abstratos dos seus filhos. Um exemplo do seu filho é o gerente
TGerenteCadastroCurso, exemplificado nos próximos tópicos deste estudo de caso.
Toda a interação entre as classes do MVC são apresentadas na Figura 5.4.
58
Figura 5.4. Interação da Classe Controle - Gerente
É apresentado abaixo, o fragmento de Manutenção de Cursos da especificação
de caso de uso disponível na documentação do sistema:
Caso de Uso 01: Manutenção de Cursos
Ator Principal: Secretaria
Sumário: Este caso de uso é iniciado pela secretaria quando ela requisita ao sistema um
cadastro de curso, selecionando a opção a partir de uma interface de pesquisa de curso,
informando os dados do mesmo. O objetivo deste caso de uso é possibilitar que ocorra a
inclusão de cursos no sistema, a consulta, a alteração ou a exclusão daqueles já existentes.
Pré-Condições: Não Aplicável.
Fluxo Principal: 1. A secretaria solicita ao sistema o cadastro de cursos;
2. O sistema exibe uma lista com os cursos cadastrados, contendo código e descrição
do curso, ordenada alfabeticamente pela descrição do curso;
3. O sistema solicita a opção de inclusão de um novo curso ou alteração, exclusão ou
consulta de um curso selecionado;
59
4. A secretaria informa a opção desejada;
5. O sistema executa o subfluxo correspondente ao tipo de operação recebido (Incluir,
Alterar, Excluir ou Consultar).
Fluxos Alternativos: 1. A secretaria pode modificar a ordenação da lista de disciplinas cadastradas, podendo
ordenar pela descrição do curso ou pela descrição da disciplina;
2. A secretaria pode efetuar uma pesquisa na lista de disciplinas cadastradas, podendo
pesquisar pela descrição da disciplina ou pela descrição do curso. A pesquisa não
necessita ser exata, sendo feita a partir do início do campo pesquisado. A pesquisa
deve ignorar letras maiúsculas e minúsculas;
3. A secretaria pode filtrar as disciplinas exibidas selecionando o curso desejado
através de sua descrição;
4. A secretaria pode cancelar a operação de cadastramento, fechando a interface.
Subfluxo: Operação Incluir
1. O sistema exibe a interface com todos os campos habilitados;
2. O sistema exibe todos os campos vazios;
3. O sistema solicita a entrada dos seguintes dados: curso (selecionado pela descrição
e representado pelo código), código, descrição, período, número de aulas, ementa e
bibliografia;
4. A secretaria informa ao sistema os dados solicitados;
5. O sistema solicita a confirmação da operação;
6. A secretaria confirma operação;
7. O sistema efetua a validação dos campos (RN1, RN2, RN3);
8. O sistema efetua críticas de acesso concorrente (registro duplicado);
9. O sistema armazena os dados;
10. O sistema fecha a interface.
Subfluxo: Operação Pesquisar
1. O sistema exibe a interface com uma lista de todos os cursos disponíveis,
compreendendo: código e nome de curso;
Subfluxo: Operação Alterar
60
1. O sistema exibe a interface com todos os campos habilitados, exceto o código do
curso;
2. O sistema efetua a leitura do registro a partir do código do curso selecionado;
3. Sistema exibe os dados: código, descrição, carga horária, professor coordenador,
quantidade de períodos e tipo de curso;
4. Sistema solicita a modificação nos seguintes dados;
5. A secretaria altera os campos;
6. O sistema solicita a confirmação da operação;
7. A secretaria confirma a operação;
8. O sistema efetua a validação dos campos (RN1, RN2, RN3);
9. O sistema efetua críticas de acesso concorrente (alteração de registro alterado ou
excluído);
10. O sistema armazena os dados;
11. O sistema fecha a interface.
Subfluxo: Operação Excluir
1. O sistema exibe a interface com todos os campos desabilitados;
2. O sistema efetua a leitura do registro a partir do código do curso selecionado;
3. Sistema exibe os dados nos respectivos campos;
4. O sistema solicita a confirmação da operação;
5. A secretaria confirma a operação;
6. O sistema efetua críticas de acesso concorrente (exclusão registro alterado ou
excluído);
7. O sistema exclui os dados;
8. O sistema fecha a interface.
Subfluxo: Operação Consultar
1. O sistema exibe a interface com todos os campos desabilitados;
2. O sistema efetua a leitura do registro a partir do código do curso selecionado;
3. Sistema exibe os dados: código, descrição, carga horária, professor coordenador,
quantidade de períodos e tipo de curso;
4. A secretaria fecha a interface.
Fluxos Alternativos:
61
1. A secretaria cancela a operação de inclusão. O sistema exibe novamente todos os
campos de entrada vazios;
2. A secretaria cancela a operação de alteração. O sistema exibe novamente os dados
originais do registro;
3. A secretaria fecha a interface durante as operações de inclusão ou alteração. Caso
tenham ocorrido modificações de informações, o sistema avisa da possibilidade de
perda de dados.
Fluxos de Exceção: 1. O código do curso não foi preenchido. Sistema exibe uma mensagem e retorna a
entrada ao campo código do curso;
2. A descrição do curso não foi preenchida. Sistema exibe uma mensagem e retorna a
entrada ao campo descrição do curso;
3. Registro duplicado. Sistema exibe uma mensagem informando que já existe um
registro com a mesma identificação informada;
4. Violação de integridade referencial. Sistema exibe uma mensagem informando que a
operação não pode ser realizada indicando a violação de integridade que foi
causada;
5. Alteração de registro alterado. Sistema exibe uma mensagem informando que a
operação não pode ser realizada indicando o motivo do cancelamento da operação;
6. Alteração de registro excluído. Sistema exibe uma mensagem informando que a
operação não pode ser realizada indicando o motivo do cancelamento da operação;
7. Exclusão de registro alterado. Sistema exibe uma mensagem informando que a
operação não pode ser realizada indicando o motivo do cancelamento da operação;
8. Exclusão de registro excluído. Sistema exibe uma mensagem informando que a
operação não pode ser realizada indicando o motivo do cancelamento da operação.
Requisitos de interface:
1. O professor coordenador deve ser exibido através de uma caixa de combinação
contendo todos os professores cadastrados;
2. A quantidade de períodos deve possibilitar o incremento e decremento do número de
períodos através de componente apropriado;
3. O tipo do curso deve ser selecionado através de botões de rádio.
Pós-condições:
62
Possibilitar o cadastro de disciplinas.
Possibilitar o cadastro de alunos.
Possibilitar o cadastro de turmas.
Requisitos não funcionais:
Não aplicável.
Regras de Negócio:
RN1: Os campos obrigatórios são: código e descrição do curso;
RN2: Os tipos de curso são: Graduação, Especialização “Lato Sensu”, Mestrado e
Doutorado;
RN3: Um curso pode ter de 1 a 10 períodos letivos.
A primeira etapa para construção do fragmento proposto é a definição das
classes no ambiente Delphi, como é exemplificado na Listagem 5.1. O próximo passo é
definir o mapeamento desta classe, como apresentado na Listagem 5.2.
Listagem 5.1. Definição das Classes Curso e Professor
Curso = Class(TPersistente) private FID : String; FCodigoCurso : Integer; FDescricao : string; FCargaHoraria : Integer; FProfessorResponsavel : Professor; FIDProfessorResponsavel : string; FQuantidadePeriodo : Integer; FTipo : Integer; public class function Criar() : Curso; function Excluir(pCursoID : String) : Boolean; procedure Persistir(); class function RecuperaObjeto(pCursoID : String) : Curso; class function RecuperaObjetos(vDados: TClientDataSet) : TClientDataSet; published property id : String read FID write FID; property codigocurso : Integer read FCodigoCurso write FCodigoCurso; property descricao : string read FDescricao write FDescricao; property cargahoraria : Integer read FCargaHoraria write FCargaHoraria; property quantidadeperiodo : Integer read FQuantidadePeriodo write FQuantidadePeriodo; property tipo : Integer read FTipo write FTipo; property professorresponsavel : Professor read FProfessorResponsavel write FProfessorResponsavel; property idprofessorresponsavel : string read FIDProfessorResponsavel write FIDProfessorResponsavel; end;
63
Professor = Class(Pessoa) private FMatriculaProfessor : Integer; FDataAdmissao : string ; FTitulacao : Integer; FTipoContrato : Integer; FValeTransporte : string; FValeAlimentacao : string; public class function Criar : Professor; class function RecuperaObjeto(pProfessorID : String) : Professor; class function RecuperaObjetos(vDados: TClientDataSet) : TClientDataSet; published property matriculaprofessor : Integer read FMatriculaProfessor write FMatriculaProfessor; property dataadmissao : string read FDataAdmissao write FDataAdmissao; property titulacao : Integer read FTitulacao write FTitulacao; property tipocontrato : Integer read FTipoContrato write FTipoContrato; property valetransporte : string read FValeTransporte write FValeTransporte; property valealimentacao : string read FValeAlimentacao write FValeAlimentacao; end; Listagem 5.2. Mapeamento Objeto-Relacional de Curso e Professor
class procedure TModelManager.StartModel(MappingManager: TdpoDBMappingManager); begin //Curso with MappingManager.Classes.Add do begin ClassObject := Curso; StorageName := 'Curso'; with AttributesMapping.add do begin AttributeName := 'id'; IsOid := True; ColumnName := 'id'; IndexType := idxUnique; Required := True; Size := 38; end; with AttributesMapping.add do begin AttributeName := 'codigocurso'; IsOid := False; ColumnName := 'codigocurso'; Required := false; end; with AttributesMapping.add do begin AttributeName := 'descricao'; IsOid := False; ColumnName := 'descricao'; Required := false; Size := 50; end; with AttributesMapping.add do begin AttributeName := 'cargahoraria'; IsOid := False; ColumnName := 'cargahoraria'; Required := false; end; with AttributesMapping.add do begin
64
AttributeName := 'quantidadeperiodo'; IsOid := False; ColumnName := 'quantidadeperiodo'; Required := false; end; with AttributesMapping.add do begin AttributeName := 'tipo'; IsOid := False; ColumnName := 'tipo'; Required := false; end; with AttributesMapping.add do begin AttributeName := 'idprofessorresponsavel'; IsOid := False; ColumnName := 'idprofessorresponsavel'; Required := false; Size := 38; end; end; //Professor with MappingManager.Classes.Add do begin ClassObject := Professor; StorageName := 'Professor'; InheritsMappingFrom := Pessoa; with AttributesMapping.add do begin AttributeName := 'id'; IsOid := True; ColumnName := 'id'; IndexType := idxUnique; Required := True; Size := 38; end; with AttributesMapping.add do begin AttributeName := 'matriculaprofessor'; IsOid := False; ColumnName := 'matriculaprofessor'; Required := false; end; with AttributesMapping.add do begin AttributeName := 'dataadmissao'; IsOid := False; ColumnName := 'dataadmissao'; Required := false; Size := 50; end; with AttributesMapping.add do begin AttributeName := 'titulacao'; IsOid := False; ColumnName := 'titulacao'; Required := false; end; with AttributesMapping.add do begin AttributeName := 'tipocontrato'; IsOid := False; ColumnName := 'tipocontrato'; Required := false; end;
65
with AttributesMapping.add do begin AttributeName := 'valetransporte'; IsOid := False; ColumnName := 'valetransporte'; Required := false; Size := 50; end; with AttributesMapping.add do begin AttributeName := 'valealimentacao'; IsOid := False; ColumnName := 'valealimentacao'; Required := false; Size := 50; end; end; end;
5.4.2 Operação Pesquisa de Curso A primeira janela de interação com o usuário é a de pesquisa de curso, conforme
a Figura 5.5, onde as informações de código de curso e descrição armazenados na base de
dados são exibidas. Nesta janela há a possibilidade de realizar pesquisas através de código
e descrição, bem como realizar a ordenação dos mesmos.
Figura 5.5. Interface de Pesquisa de Curso
Basicamente, o sistema retorna uma lista de objetos do tipo curso persistentes
na base de dados. A Figura 5.6 apresenta o diagrama de seqüência da operação de
pesquisa de curso.
66
Figura 5.6. Diagrama de Seqüência da Operação Pesquisa
Na primeira interação do diagrama de seqüência é apresentada a interface de
pesquisa, através da instanciação do formulário de pesquisa de curso. No evento Activate
deste formulário, é invocado o método CarregaDados. Este método é então, o responsável
por alimentar o componente do Delphi com os dados dos cursos. Este componente é um
ListView. Respeitando o MVC, o método CarregaDados, por sua vez, executa o método
ObterCursos() do gerente de cadastro de curso (Controller), como apresentado na
Listagem 5.3. Observe que antes, é instanciado um objeto do tipo TClientDataSet e este
recebe uma estrutura, executando o método ObterEstruturaCurso() do gerente. O
ObterEstruturaCurso, como o próprio nome diz retorna uma estrutura de campos para o
ClientDataSet criado.
Listagem 5.3. Método ObterCursos
class function TGerenteCadastroCurso.ObterCursos: TClientDataSet; var vDados :TClientDataSet; begin vDados := TClientDataSet.Create(nil); vDados := TGerente.ObterEstruturaCurso; vDados := curso.RecuperaObjetos(vDados); result := vDados; end;
O método ObterCursos faz então um acesso à camada de modelo do sistema
(Model) e invoca o método RecuperaObjetos() da classe curso, passando como parâmetro
o ClientDataSet criado. Este faz acesso aos métodos do framework de persistência DePO e
67
recupera todos os objetos persistidos na base de dados relacional. O código do método
RecuperaObjetos é exibido na Listagem 5.4.
Listagem 5.4. Método RecuperaObjetos
class function Curso.RecuperaObjetos(vDados: TClientDataSet): TClientDataSet; var objCurso : Curso; begin objCurso := curso.Criar; with dtmdlDePO.dpoDBXMechanism.CreateQuery(Curso) do begin Open; First; while not IsDone do begin RetrieveObject(objCurso); //Atribuindo objtetos ao TClientDataSet vDados.Insert; vDados.FieldByName('id').AsString := objCurso.id; vDados.FieldByName('codigocurso').AsInteger := objCurso.codigocurso; vDados.FieldByName('descricao').AsString := objCurso.descricao; vDados.FieldByName('cargahoraria').AsInteger := objCurso.cargahoraria; vDados.FieldByName('quantidadeperiodo').AsInteger := objCurso.quantidadeperiodo; vDados.FieldByName('tipo').AsInteger := objCurso.tipo; vDados.FieldByName('professor').AsString := objCurso.idprofessorresponsavel; vDados.Post; Next; end; end; result := vDados; end;
É observado que o método acima executa a função CreateQuery do DePO, com
a classe do objeto como parâmetro. Feito isso, é então executado um laço para alimentar,
com os dados dos objetos curso recuperados, o ClientDataSet passado como parâmetro.
Feito isso, a função retorna este ClientDataSet com os dados dos objetos aninhados em sua
estrutura.
Com isso a função ObterCursos() do GerenteCadastroCurso (Controller), retorna
também este ClientDataSet para a interface (View), que alimenta assim o componente
ListView do Delphi que é apresentada para o usuário. Conclui-se então a Operação de
Pesquisa Curso.
5.4.3 Operação Incluir Curso Exibida a tela de pesquisa, o usuário pode então incluir ou manipular (atualizar,
excluir, consultar) os objetos nela contidos. Este tópico aborda a operação de inclusão de
curso, na abordagem do sistema acadêmico.
68
O diagrama de seqüência apresentado na Figura 5.7 aborda as interações para
a operação de inclusão. Observe que, as primeiras interações compreendem os fluxos de
pesquisa de curso, acima abordadas. A Figura 5.8, apresenta a interface que o usuário
insere os dados para esta operação.
Figura 5.7. Diagrama de Seqüência da Operação Incluir Curso
69
Figura 5.8. Interface de Incluir Curso
Após a exibição da tela de pesquisa para o usuário, ele então requisita ao
sistema, através do menu ou do clique direito do mouse, a inclusão de um novo curso no
sistema. Esta ação é compreendida através da interação Incluir do diagrama de seqüência
acima apresentado.
Assim que a interação incluir é executada, o sistema exibe então a interface
necessária para a inclusão. Para isso, inicialmente é invocado o método
ObterProfessores() do GerenteCadastroCurso (Controller) pelo formulário de cadastro de
curso (View). Este executa o método da classe professor (Model) RecuperaObjetos(). Assim como no exemplo da tela de pesquisa, este método retorna um ClientDataSet com
todos os objetos professor existentes na base de dados. Todo este processo inicial é
executado para montar uma lista de professores, para que os mesmos possam ser
escolhidos como professor responsável do curso a ser incluído.
Com os dados dos professores na interface (View), o sistema alimenta um
componente do Delphi chamado ComboBox, que provê uma estrutura de escolha
compatível com a estrutura de lista. Com isso é exibida a tela ao usuário.
O usuário então, informa os dados do novo curso (código, descrição, carga
horária, professor responsável, quantidade de períodos e tipo de curso). Ao clicar no botão
Incluir, o usuário invoca o método GravaRegistro do formulário. Esta alimenta um novo
ClientDataSet com os dados incluídos pelo usuário e o passa como parâmetro para o
método GravarCampos(TClientDataSet) do GerenteCadastroCurso (Controller). Este
invoca o método Criar() do modelo (Listagem 5.5), instanciando então um objeto do tipo
curso para que o mesmo possa ter seus atributos alimentados pelo ClientDataSet passado
como parâmetro, como apresentado na Listagem 5.6. Ao final é executado o método
70
Persistir() da classe curso, definido na Listagem 5.7, que tem como objetivo salvar o objeto
na base de dados. O método GravarCampos(TClientDataSet) é usado tanto para a
persistência de um novo curso, quando para a atualização de um já existente. É efetuado
um teste que verifica se a operação solicitada é de atualização ou de criação.
Feito isso a tela de inclusão é fechada para o usuário e o sistema exibe
novamente a tela de pesquisa já com o novo curso inserido.
Listagem 5.5. Método Criar
class function Curso.Criar(): Curso; begin result := self.Create(dtmdlDePO.dpoDBXMechanism); end; Listagem 5.6. Método GravarCampos - Persistir
function GravarCampos(pParametros : TClientDataSet): Boolean;reintroduce; begin self.objCurso := curso.Criar; self.objCurso.ID := objCurso.SetGUID; //Adicionar dados do ClientDataSet self.objCurso.codigocurso := pParametros.FieldByName('codigocurso').AsInteger; self.objCurso.descricao := pParametros.FieldByName('descricao').AsString; self.objCurso.cargahoraria := pParametros.FieldByName('cargahoraria').AsInteger; self.objCurso.quantidadeperiodo:= pParametros.FieldByName('quantidadeperiodo').AsInteger; self.objCurso.tipo := pParametros.FieldByName('tipo').AsInteger; //Relacionamento self.objCurso.idprofessorresponsavel := pParametros.FieldByName('professor').AsString; //Persistindo self.objCurso.Persistir; result := true; end; Listagem 5.7. Método Persistir
procedure Curso.Persistir(); begin self.Save; end;
5.4.4 Operação Atualizar Curso A operação de atualizar curso ocorre quando o usuário escolhe um item da lista
exibida pela tela de pesquisa e aciona a opção Alterar. Na Figura 5.9 é exibido o diagrama
de seqüência, contendo as interações da operação de atualizar curso.
Observe que é utilizado basicamente a mesma estrutura de interações da
operação de incluir.
71
Figura 5.9. Diagrama de Seqüência da Operação Atualizar Curso
Na Figura 5.10 é exibida a interface apresentada para a atualização de algum
curso no sistema.
72
Figura 5.10. Interface de Atualizar Curso
Ao solicitar ao sistema uma alteração de curso, o sistema monta o formulário de
cadastro de curso trazendo os dados do curso a ser alterado para a janela. Esta operação é
iniciada quando o formulário de cadastro de curso (View) acessa o método Obter() do
GerenteCadastroCurso (Controller), como definido na Listagem 5.8. É passado o atributo
identificador do objeto para este método (OID). Este então invoca o método da classe curso
RecuperaObjeto() (Model), passando também o OID como parâmetro, para que este possa
recuperar o objeto na base de dados e retorná-lo para o gerente, como apresentado na
Listagem 5.9.
Listagem 5.8. Método Obter
function TGerenteCadastroCurso.Obter(pCursoId: String): Boolean; begin result := false; self.objCurso := curso.RecuperaObjeto(pCursoId); if self.objCurso <> nil then begin result := true; end; end;
Listagem 5.9. Método RecuperaObjeto
class function Curso.RecuperaObjeto(pCursoID: String): Curso; var objCurso : Curso; begin result := nil; objCurso := curso.Criar; objCurso.id := pCursoID; if objCurso.Retrieve then begin result := objCurso; end; end;
73
O gerente de curso, tendo o objeto na memória, retorna para o formulário de
cadastro de curso uma variável do tipo booleana com valor verdadeiro. Com isso o
formulário invoca o método LerCampos() do gerente. Este método tem como objetivo
atribuir os atributos do objeto para um ClientDataSet e este ser devolvido como retorno para
o formulário, como exemplificado na Listagem 5.10. Com isso, o sistema monta a janela com
os dados do curso recuperado, exibindo-a e aguardando as alterações do usuário.
Listagem 5.10. Método LerCampos
function TGerenteCadastroCurso.LerCampos: TClientDataSet; var vDadosCampos : TClientDataSet; begin vDadosCampos := TClientDataSet.Create(nil); vDadosCampos := TGerente.ObterEstruturaCurso; vDadosCampos.Insert; vDadosCampos.FieldByName('id').AsString := self.objCurso.id; vDadosCampos.FieldByName('codigocurso').AsInteger := self.objCurso.codigocurso; vDadosCampos.FieldByName('descricao').AsString := self.objCurso.descricao; vDadosCampos.FieldByName('cargahoraria').AsInteger:= self.objCurso.cargahoraria; vDadosCampos.FieldByName('quantidadeperiodo').AsInteger := self.objCurso.quantidadeperiodo; vDadosCampos.FieldByName('tipo').AsInteger := self.objCurso.tipo; vDadosCampos.FieldByName('professor').AsString := self.objCurso.idprofessorresponsavel; vDadosCampos.Post; result := vDadosCampos; end;
Após o usuário efetuar suas alterações no curso recuperado, ele clica no botão
Alterar da interface. Este aciona o método GravarRegistro do formulário de cadastro de
curso (View), que invoca o método GravarCampos(TClientDataSet) do
GerenteCadastroCurso, passando como parâmetro um ClientDataSet com os dados do
objeto alterado. O GravarCampos verifica se existe um objeto na memória e o atualiza com
os dados passados por parâmetro invocando o método persistir da classe curso, como
apresentado na Listagem 5.11.
Listagem 5.11. Método GravarCampos - Atualizar
function TGerenteCadastroCurso.GravarCampos(pParametros : TClientDataSet): Boolean; begin self.objCurso.codigocurso := pParametros.FieldByName('codigocurso').AsInteger; self.objCurso.descricao := pParametros.FieldByName('descricao').AsString; self.objCurso.cargahoraria:= pParametros.FieldByName('cargahoraria').AsInteger; self.objCurso.quantidadeperiodo := pParametros.FieldByName('quantidadeperiodo').AsInteger; self.objCurso.tipo := pParametros.FieldByName('tipo').AsInteger; self.objCurso.idprofessorresponsavel := pParametros.FieldByName('professor').AsString; self.objCurso.Persistir; result:=true;
74
5.4.5 Operação Excluir Curso A operação excluir ocorre quando o usuário escolhe um curso e aciona a opção
excluir disponível na interface. A Figura 5.11 apresenta o diagrama de seqüência da
operação e a Figura 5.12 apresenta a interface exibida na exclusão.
Figura 5.11. Diagrama de Seqüência da Operação Excluir Curso
75
Figura 5.12. Interface de Excluir Curso
A operação de excluir executa basicamente os mesmos fluxos que a operação
de atualizar, apenas com uma diferença: Assim que o curso selecionado para exclusão é
recuperado e exibido na tela, todos os campos são desabilitados, não permitindo a alteração
do usuário.
Com isso, o usuário pode visualizar o curso escolhido antes da sua exclusão. Ao
clicar e confirmar a função de excluir, o sistema invoca o método Excluir() do
GerenteCadastroCurso (Controller), exemplificado na Listagem 5.12, que por sua vez
executa o método da classe curso Excluir() (Model), como apresentado na Listagem 5.13.
Ambos os métodos recebem como parâmetro o OID do objeto, para que o mesmo possa ser
excluído. Com isso o objeto é excluído da base de dados e destruído da memória. Após, o
sistema exibe a janela de pesquisa para o usuário atualizada.
Listagem 5.12. Método Excluir - Gerente
function TGerenteCadastroCurso.Excluir(pCursoId:String): Boolean; begin result := false; try if objCurso <> nil then begin result := objCurso.Excluir(pCursoId); end; finally objCurso.Destroy; end; end; Listagem 5.13. Método Excluir - Classe Curso
function Curso.Excluir(pCursoID: String): Boolean; begin self.id := pCursoID;
76
0 if self.Retrieve then begin self.Delete; self.Save; result := true; end else begin result := false; end; end;
5.4.6 Operação Consultar Curso A operação de consulta de curso ocorre quando o usuário escolhe um curso na
tela de pesquisa e aciona a opção consultar. Esta operação simplesmente recupera o objeto
escolhido e o exibe na janela, como já explicado nos itens anteriores. A Figura 5.13
apresenta o diagrama de seqüência desta operação e a Figura 5.14 apresenta a interface
exibida ao usuário ao consultar um curso.
Figura 5.13. Diagrama de Seqüência da Operação Consultar Curso
77
Figura 5.14. Interface de Consultar Curso
Assim como a interface de exclusão, a interface de consulta apresenta todos os
campos desabilitados para edição do usuário.
5.5 Conclusão Este capítulo teve como objetivo exemplificar o uso da abordagem de
mapeamento objeto-relacional para persistência em software orientado a objetos, além da
utilização do framework de persistência DePO (Delphi Persistent Objects).
Foi utilizado um sistema de controle acadêmico como estudo de caso para este
trabalho e para este capítulo foi apresentado somente um fragmento dele: Manutenção de
Cursos.
Este estudo de caso serviu também para o aprendizado e implementação de
padrões de projeto, que são soluções genéricas e reutilizáveis, aplicáveis em classes de
problemas bem conhecidos.
Foi possível também apresentar na prática as estratégias dispostas neste
trabalho, bem como sua firmação como estratégia eficiente o suficiente para dar suporte em
ambientes de desenvolvimento de grande porte.
78
6 CONSIDERAÇÕES FINAIS Este trabalho monográfico baseou-se na análise e estudo das estratégias de
persistência de objetos para sistema gerenciadores de banco de dados relacionais
(SGBDR). Foi apresentada inicialmente uma conceituação de mapeamento objeto-relacional
e suas abordagens, além dos conceitos, aplicações e estratégias de camadas de
persistência.
Após, foi realizado um estudo exploratório sobre alguns frameworks de
persistência opensource disponíveis para o ambiente de desenvolvimento Delphi. Nele
foram apresentados os frameworks DePO (Delphi Persistent Objects), IO (Instant Objects) e
TiOPF (TechInside Object Persistent Framework). Foi observado que nenhum dos
frameworks apresentados possuem documentação sólida, muito provavelmente por se tratar
de programas de código fonte aberto (opensource).
Para finalizar este trabalho, foi proposto um estudo de caso que está inserido no
contexto do projeto de iniciação científica “Estratégias de Persistência de Software
Orientado a Objetos” da Faculdade Metodista Granbery. Projeto este que desenvolveu um
estudo sobre as técnicas de persistência de objetos, seja através de banco orientado a
objetos, camadas de persistências para armazenamento em banco de dados relacionais e
banco de dados objeto relacionais.
Este estudo de caso foi resultado de uma reengenharia de um sistema de
controle acadêmico que foi desenvolvido utilizando o paradigma estruturado. O sistema foi
re-modelado e implementado utilizando o paradigma orientado a objetos. Para o
desenvolvimento do sistema foi usado o padrão de projeto MVC (Model-View-Controller) que
busca facilitar o reuso de código fonte e substituição de estratégias de persistência, uma vez
que o sistema será base para teste de diversas estratégias.
Este trabalho também teve como objetivo a divulgação dos resultados obtidos
nas pesquisas para toda a comunidade acadêmica. A documentação completa do sistema
acadêmico pode ser vista no Anexo A deste trabalho. No CD em anexo a este trabalho é
disponibilizado o executável e o código fonte do sistema acadêmico abordado no estudo de
caso.
Como sugestão para trabalhos futuros, é sugerido um estudo exploratório e
analítico das abordagens proprietárias dos frameworks de persistência para Delphi, da
mesma forma que foi realizado neste trabalho com as abordagens opensource. Como
exemplo das abordagens proprietárias é destacado o ECO (Enterprise Core Objects), ECO
II e Bold.
Como resultados obtidos neste trabalho é destacado:
79
artigo escrito e aceito para a revista ClubeDelphi (ClubeDelphi, 2005)
intitulado “Persistência de Objetos no Delphi: Introdução ao DePO(Delphi
Persistent Objects)”;
artigo “Persistência em Software Orientado a Objetos: Abordagens Utilizando
Frameworks OpenSource” aceito para apresentação oral no III Encontro de
Software Livre do Amazonas (ESLAM, 2005) em Manaus;
apresentação oral do workshop “Persistência em Software Orientado a
Objetos: Abordagens Utilizando Frameworks OpenSource” no II Festival de
Software Livre de Juiz de Fora (FESTSOL, 2005);
apresentação do minicurso “Persistência de Objetos em Delphi – Introdução
ao Framework DePO(Delphi Persistent Objects)” como parte das atividades
da disciplina de Seminários da Faculdade Metodista Granbery;
apresentação de palestras no contexto da disciplina de Analise de Sistemas II
da Faculdade Metodista Granbery.
Por fim, é importante destacar que este trabalho contribuiu muito para a
ampliação dos conhecimentos do discente em relação às estratégias de persistência em
software orientado a objetos. O que com certeza será aplicado na sua futura vida
profissional.
80
ANEXO A – DOCUMENTAÇÃO SISTEMA ACADÊMICO
FACULDADE METODISTA GRANBERY BACHARELADO EM SISTEMAS DE INFORMAÇÃO
SCA – Sistema de Controle Acadêmico
Juiz de Fora 2005
81
Especificação dos Requisitos do Software
SCA
82
1. Introdução:
1.1. Propósito:
O presente documento tem o objetivo de especificar e estabelecer os requisitos para o desenvolvimento de um sistema de controle acadêmico.
1.2. Escopo:
O objetivo deste sistema é o controle acadêmico, bem como a melhoria na
organização de suas informações e facilidade de uso destas. Esse sistema deverá permitir o cadastro de cursos, cadastro de disciplinas, cadastro de professores, cadastro de alunos, abertura de turmas, matrícula do aluno e lançamento de avaliação. Deverá ainda emitir relatórios de alunos por turma, disciplina por curso e histórico escolar. 1.3. Definições e Siglas:
SCA: nome dado ao Sistema de Controle Acadêmico.
83
2. Descrição Geral:
2.1. Visão Geral do Produto: Esse sistema tem como objetivo controlar atividades acadêmicas
administrativas, assim como a melhoria na organização e facilidade de uso de suas informações. 2.2. Perspectivas do Produto: • O SCA é independente. • O sistema utilizará uma camada de persistência que irá interagir entre o produto e
o banco de dados.
• Requisitos de Software: o sistema será desenvolvido utilizando a Ferramenta de desenvolvimento Delphi 6 (Borland). Sistema Operacional mínimo para sua utilização deverá ser Windows 98.
2.3.Funções do Produto:
• Cadastro de Cursos • Cadastro de Disciplinas • Cadastro de Professores • Cadastro de Alunos • Cadastro de Turmas • Matrícula de Alunos • Cadastro de Avaliações de Alunos • Emissão de Relatório de Alunos por Turma • Emissão de Relatório de Disciplinas por Curso • Emissão de Histórico Escolar
84
3. Requisitos Específicos:
3.1. Requisitos Funcionais: Requisito Funcional 1: O sistema deve permitir à secretaria incluir, alterar, excluir e consultar cursos, contendo os dados código, descrição, carga horária, professor coordenador (selecionado pelo nome e representado pela matrícula do professor), quantidade de períodos e tipos de cursos (Graduação, Especialização “Lato Sensu”, Mestrado e Doutorado); Requisito Funcional 2: O sistema deve permitir à secretaria pesquisar e ordenar os cursos por código ou por descrição; Requisito Funcional 3: O sistema deve permitir à secretaria incluir, alterar, excluir e consultar as disciplinas, contendo os dados curso (selecionado pela descrição e representado pelo respectivo código), código, descrição, período, número de aulas, ementa e bibliografia; Requisito funcional 4: O sistema deve permitir à secretaria pesquisar e ordenar as disciplinas por descrição de cursos ou por descrição de disciplinas. Deve ser permitido uma filtragem das disciplinas por cursos; Requisito Funcional 5: O sistema deve permitir ao professor incluir, alterar, excluir e consultar os professores, contendo os dados matrícula, nome, data de nascimento, data de admissão, e-mail, telefone residencial, telefone comercial, telefone celular, fotografia, status (ativo ou inativo), logradouro, número, complemento, bairro, cidade, UF, CEP, CPF, documento de identidade (número, órgão expedidor, UF e data expedição), titulação máxima (graduação, especialização, mestrado e doutorado), tipo de contrato (substituto, auxiliar, assistente ou adjunto), benefícios (vale transporte e/ou vale alimentação) e alocação das disciplinas lecionadas pelo professor (selecionadas pela descrição e representadas pelos respectivos código); Requisito Funcional 6: O sistema deve permitir ao professor pesquisar e ordenar os professores por matrícula ou por nome do professor; Requisito Funcional 7: O sistema deve permitir ao aluno incluir, alterar, excluir e consultar alunos contendo os dados matrícula, nome, data de nascimento, curso (selecionado pela descrição e representado pelo respectivo código), ano de início, semestre de início, e-mail, telefone residencial, telefone comercial, telefone celular, fotografia, logradouro, número, complemento, bairro, cidade, UF, CEP, CPF, documento de identidade (número, órgão expedidor, UF e data expedição) e status (ativo ou inativo); Requisito Funcional 8: O sistema deve permitir ao aluno pesquisar e ordenar os alunos por matrícula ou nome do aluno; Requisito Funcional 9: O sistema deve permitir à secretaria incluir, alterar, excluir e consultar as turmas, contendo os dados curso (selecionado pela descrição e representado pelo respectivo código), disciplina (selecionada pela descrição e representada pelo respectivo código), ano, semestre, descrição da turma, número máximo de alunos e professor responsável (selecionado pelo nome e representado pelo respectivo número de matrícula); Requisito Funcional 10: O sistema deve permitir à secretaria pesquisar e ordenar as turmas por descrição de curso, descrição de disciplina, ano, semestre ou turma. O sistema deverá permitir à secretaria filtrar a lista de turmas, apenas, a partir dos dados descrição de curso, descrição de disciplina, ano e semestre; Requisito Funcional 11: O sistema deve permitir ao aluno incluir e alterar a matrícula contendo dados para selecionar a turma (selecionada pela descrição e representada pelo respectivo código) e os alunos (selecionado pelo nome e
85
representado pelo respectivo número de matrícula). Um aluno deve possuir apenas uma matricula; Requisito Funcional 12: O sistema deve permitir ao aluno pesquisar e ordenar as matrículas por descrição de curso, descrição de disciplina, ano, semestre ou turma. O sistema deverá permitir ao aluno filtrar a lista de turmas disponíveis para efetuar matrícula, apenas, a partir dos dados descrição de curso, descrição de disciplina, ano e semestre; Requisito Funcional 13: O sistema deve permitir ao professor incluir, alterar e consultar a avaliações contendo os dados para selecionar a turma (selecionada pela descrição e representada pelo respectivo código) e os alunos (selecionados pelos respectivos nomes e representados pelos números de matrícula correspondentes) em uma lista, podendo, assim, inserir ou alterar os dados: faltas, avaliação1, avaliação2 e avaliação final; Requisito Funcional 14: O sistema deve permitir ao professor pesquisar e ordenar as avaliações por descrição de curso, descrição de disciplina, ano, semestre ou turma. O sistema deverá permitir o professor filtrar a lista de turmas disponíveis para efetuar lançamento de avaliação, apenas, a partir dos dados descrição de curso, descrição de disciplina, ano e semestre;
Requisito Funcional 15: O sistema deve permitir ao professor a emissão da relação de alunos por turmas, contendo descrição do curso, descrição da disciplina, ano, semestre, descrição da turma, nome do professor, matrícula do aluno e nome do aluno;
Requisito Funcional 16: O sistema deve permitir à secretaria a emissão da relação de disciplinas por curso, contendo nome do curso, nome das disciplinas, total de disciplinas por curso, total de cursos e total de todas as disciplinas;
Requisito Funcional 17: O sistema deve permitir ao aluno a emissão do histórico escolar, contendo matrícula do aluno, nome do aluno, ano, semestre, descrição da turma, nome das disciplinas, número de aulas, número de faltas, avaliação 1, avaliação 2 e avaliação final;
Requisito Funcional 18: o sistema não deve permitir ordenação composta (por mais de um campo) em suas listagens.
3.2. Requisitos não-funcionais:
Requisito não funcional 1: O sistema deve ser totalmente aderente aos
principais conceitos de Orientação a Objeto (encapsulamento, herança, polimorfismo, tipificação forte, etc.). Requisito não funcional 2: O sistema deve possuir a estrutura cliente/servidor.
Requisito não funcional 3: O sistema deve tratar a concorrência para inserir, deletar e atualizar registros no banco de dados.
Requisito não funcional 4: O sistema deve utilizar o banco de dados relacional Interbase 6.0, da Borland – instalado no servidor.
Requisito não funcional 5: O sistema deve possibilitar que todos os relatórios sejam pré-visualizados antes do envio para a impressora.
Requisito não funcional 6: O sistema deve apresentar o recurso de ajuda on-line sensível ao contexto de seu uso;
Requisito não funcional 7: O sistema deve utilizar a ferramenta QuickReports para a geração de relatórios;
Requisito não funcional 8: O sistema deve apresentar, durante sua abertura, uma tela de apresentação que permanece por poucos segundos visível, exibindo nome do sistema e número da versão atual;
86
Requisito não funcional 9: O sistema deve apresentar uma tela que exibe os dados sobre o desenvolvimento do sistema. Os dados serão: nome do sistema, número da versão atual, data da versão atual, nome do autor e e-mail para contato;
Requisito não funcional 10: O sistema deve apresentar, em sua tela principal, a data atual, o nome do autor e a hora atual, num painel encontrado no rodapé dessa interface.
87
Casos de Uso SCA
88
4. Diagrama de Caso de Uso:
Cadastrar Alunos
Matricular Alunos
Aluno
Emitir Histórico Escolar
Professor
Cadastrar Professor
Lançar Avaliações
Emitir Relatório de Aluno por Turma
Cadastrar Cursos
Cadastrar Disciplina
Cadastrar Turmas
Secretaria
Emitir Relatório Disciplina por Curso
89
5. Especificação de Casos de Uso Caso de Uso 01: Manutenção de Cursos Ator Principal:
Secretaria Sumário:
Este caso de uso é iniciado pela secretaria quando ela requisita ao sistema um cadastro de curso, selecionando a opção a partir de uma interface de pesquisa de curso, informando os dados do mesmo. O objetivo deste caso de uso é possibilitar que ocorra a inclusão de cursos no sistema, a consulta, a alteração ou a exclusão daqueles já existentes. Pré-Condições:
Não Aplicável. Fluxo Principal:
1. A secretaria solicita ao sistema o cadastro de cursos; 2. O sistema exibe uma lista com os cursos cadastrados, contendo código e descrição
do curso, ordenada alfabeticamente pela descrição do curso; 3. O sistema solicita a opção de inclusão de um novo curso ou alteração, exclusão ou
consulta de um curso selecionado; 4. A secretaria informa a opção desejada; 5. O sistema executa o subfluxo correspondente ao tipo de operação recebido (Incluir,
Alterar, Excluir ou Consultar). Fluxos Alternativos:
1. A secretaria pode modificar a ordenação da lista de disciplinas cadastradas, podendo ordenar pela descrição do curso ou pela descrição da disciplina;
2. A secretaria pode efetuar uma pesquisa na lista de disciplinas cadastradas, podendo pesquisar pela descrição da disciplina ou pela descrição do curso. A pesquisa não necessita ser exata, sendo feita a partir do início do campo pesquisado. A pesquisa deve ignorar letras maiúsculas e minúsculas;
3. A secretaria pode filtrar as disciplinas exibidas selecionando o curso desejado através de sua descrição;
4. A secretaria pode cancelar a operação de cadastramento, fechando a interface. Subfluxo: Operação Incluir
1. O sistema exibe a interface com todos os campos habilitados; 2. O sistema exibe todos os campos vazios; 3. O sistema solicita a entrada dos seguintes dados: curso (selecionado pela descrição
e representado pelo código), código, descrição, período, número de aulas, ementa e bibliografia;
4. A secretaria informa ao sistema os dados solicitados; 5. O sistema solicita a confirmação da operação; 6. A secretaria confirma operação; 7. O sistema efetua a validação dos campos (RN1, RN2, RN3); 8. O sistema efetua críticas de acesso concorrente (registro duplicado); 9. O sistema armazena os dados; 10. O sistema fecha a interface.
Subfluxo: Operação Persquisar
90
1. O sistema exibe a interface com uma lista de todos os cursos disponíveis, compreendendo: código e nome de curso;
Subfluxo: Operação Alterar
1. O sistema exibe a interface com todos os campos habilitados, exceto o código do curso;
2. O sistema efetua a leitura do registro a partir do código do curso selecionado; 3. Sistema exibe os dados: código, descrição, carga horária, professor coordenador,
quantidade de períodos e tipo de curso; 4. Sistema solicita a modificação nos seguintes dados; 5. A secretaria altera os campos; 6. O sistema solicita a confirmação da operação; 7. A secretaria confirma a operação; 8. O sistema efetua a validação dos campos (RN1, RN2, RN3); 9. O sistema efetua críticas de acesso concorrente (alteração de registro alterado ou
excluído); 10. O sistema armazena os dados; 11. O sistema fecha a interface.
Subfluxo: Operação Excluir
1. O sistema exibe a interface com todos os campos desabilitados; 2. O sistema efetua a leitura do registro a partir do código do curso selecionado; 3. Sistema exibe os dados nos respectivos campos; 4. O sistema solicita a confirmação da operação; 5. A secretaria confirma a operação; 6. O sistema efetua críticas de acesso concorrente (exclusão registro alterado ou
excluído); 7. O sistema exclui os dados; 8. O sistema fecha a interface.
Subfluxo: Operação Consultar
1. O sistema exibe a interface com todos os campos desabilitados; 2. O sistema efetua a leitura do registro a partir do código do curso selecionado; 3. Sistema exibe os dados: código, descrição, carga horária, professor coordenador,
quantidade de períodos e tipo de curso; 4. A secretaria fecha a interface.
Fluxos Alternativos:
1. A secretaria cancela a operação de inclusão. O sistema exibe novamente todos os campos de entrada vazios;
2. A secretaria cancela a operação de alteração. O sistema exibe novamente os dados originais do registro;
3. A secretaria fecha a interface durante as operações de inclusão ou alteração. Caso tenham ocorrido modificações de informações, o sistema avisa da possibilidade de perda de dados.
Fluxos de Exceção:
1. O código do curso não foi preenchido. Sistema exibe uma mensagem e retorna a entrada ao campo código do curso;
2. A descrição do curso não foi preenchida. Sistema exibe uma mensagem e retorna a entrada ao campo descrição do curso;
3. Registro duplicado. Sistema exibe uma mensagem informando que já existe um registro com a mesma identificação informada;
91
4. Violação de integridade referencial. Sistema exibe uma mensagem informando que a operação não pode ser realizada indicando a violação de integridade que foi causada;
5. Alteração de registro alterado. Sistema exibe uma mensagem informando que a operação não pode ser realizada indicando o motivo do cancelamento da operação;
6. Alteração de registro excluído. Sistema exibe uma mensagem informando que a operação não pode ser realizada indicando o motivo do cancelamento da operação;
7. Exclusão de registro alterado. Sistema exibe uma mensagem informando que a operação não pode ser realizada indicando o motivo do cancelamento da operação;
8. Exclusão de registro excluído. Sistema exibe uma mensagem informando que a operação não pode ser realizada indicando o motivo do cancelamento da operação.
Requisitos de interface: 1. O professor coordenador deve ser exibido através de uma caixa de combinação
contendo todos os professores cadastrados; 2. A quantidade de períodos deve possibilitar o incremento e decremento do número de
períodos através de componente apropriado; 3. O tipo do curso deve ser selecionado através de botões de rádio.
Pós-condições:
Possibilitar o cadastro de disciplinas. Possibilitar o cadastro de alunos. Possibilitar o cadastro de turmas.
Requisitos não funcionais:
Não aplicável. Regras de Negócio:
RN1: Os campos obrigatórios são: código e descrição do curso; RN2: Os tipos de curso são: Graduação, Especialização “Lato Sensu”, Mestrado e Doutorado; RN3: Um curso pode ter de 1 a 10 períodos letivos.
Caso de Uso 02: Cadastrar Disciplinas Ator Principal:
Secretaria Sumário:
Este caso de uso é iniciado pela secretaria quando ela requisita ao sistema um cadastro de disciplinas, selecionando a opção a partir da interface contém uma listagem de disciplinas cadastradas e, posteriormente, informando os dados da mesma. O objetivo deste caso de uso é possibilitar que ocorra a inclusão de disciplinas no sistema, a consulta, a alteração ou a exclusão daquelas já existentes. Pré-Condições:
Curso cadastrado. Fluxo Principal:
1. A secretaria solicita ao sistema o cadastro de disciplinas; 2. O sistema exibe uma lista com as disciplinas cadastradas, contendo descrição do
curso e descrição da disciplina, ordenada, crescentemente, pela descrição do curso;
92
3. O sistema solicita a opção de inclusão de uma nova disciplina, alteração, exclusão ou consulta de uma disciplina selecionada na lista;
4. A secretaria informa a opção desejada; 5. O sistema executa o subfluxo correspondente ao tipo de operação recebido (Incluir,
Alterar, Excluir ou Consultar). Fluxos Alternativos:
1. A secretaria pode modificar a ordenação da lista de disciplinas cadastradas, podendo ordenar pelo código ou pela descrição da mesma.
2. A secretaria pode efetuar uma pesquisa na lista de disciplinas cadastradas, podendo pesquisar pelo código ou pela descrição da disciplina. A pesquisa não necessita ser exata, sendo feita a partir do início do campo pesquisado. A pesquisa deve ignorar letras maiúsculas e minúsculas.
3. A secretaria pode cancelar a operação de cadastramento, fechando a interface. Subfluxo: Operação Incluir
1. O sistema exibe a interface com todos os campos habilitados; 2. O sistema exibe todos os campos vazios; 3. O sistema solicita a entrada dos seguintes dados: código, descrição, curso, período,
número de aulas, ementa e bibliografia; 4. A secretaria informa ao sistema os dados solicitados; 5. O sistema solicita a confirmação da operação; 6. A secretaria confirma operação; 7. O sistema efetua a validação dos campos (RN1, RN2); 8. O sistema efetua críticas de acesso concorrente (registro duplicado); 9. O sistema armazena os dados; 10. O sistema fecha a interface.
Subfluxo: Operação Alterar
1. O sistema exibe a interface com todos os campos habilitados, exceto o código da disciplina e o curso ao qual ela se relaciona;
2. O sistema efetua a leitura do registro a partir do código da disciplina selecionada; 3. Sistema exibe os dados: curso (visualizado pelo nome e representado pelo código),
código, descrição, período, número de aulas, ementa e bibliografia; 4. Sistema solicita a modificação nos dados apresentados (exceto código e curso); 5. A secretaria altera os campos; 6. O sistema solicita a confirmação da operação; 7. A secretaria confirma a operação; 8. O sistema efetua a validação dos campos (RN1, RN2); 9. O sistema efetua críticas de acesso concorrente (alteração de registro alterado ou
excluído); 10. O sistema armazena os dados; 11. O sistema fecha a interface.
Subfluxo: Operação Excluir
1. O sistema exibe a interface com todos os campos desabilitados; 2. O sistema efetua a leitura do registro a partir do código da disciplina selecionada; 3. Sistema exibe os dados da disciplina nos respectivos campo;. 4. O sistema solicita a confirmação da operação; 5. A secretaria confirma a operação; 6. O sistema efetua críticas de acesso concorrente (exclusão registro alterado ou
excluído); 7. O sistema exclui os dados;
93
8. O sistema fecha a interface. Subfluxo: Operação Consultar
1. O sistema exibe a interface com todos os campos desabilitados; 2. O sistema efetua a leitura do registro a partir do código da disciplina selecionada; 3. Sistema exibe os dados: código, descrição, curso, período, número de aulas, ementa
e bibliografia; em seus respectivos campos; 4. A secretaria fecha a interface.
Fluxos Alternativos:
1. A secretaria cancela a operação de inclusão. O sistema exibe novamente todos os campos de entrada vazios;
2. A secretaria cancela a operação de alteração. O sistema exibe novamente os dados originais do registro;
3. A secretaria fecha a interface durante as operações de inclusão ou alteração. Caso tenham ocorrido modificações de informações, o sistema avisa da possibilidade de perda de dados.
Fluxos de Exceção:
1. O código da disciplina não foi preenchido. O sistema exibe uma mensagem e retorna a entrada ao campo código do curso;
2. A descrição da disciplina não foi preenchida. O sistema exibe uma mensagem e retorna a entrada ao campo descrição da disciplina;
3. O curso da disciplina não foi selecionado. O sistema exibe uma mensagem e retorna a entrada ao respectivo campo;
4. Registro duplicado. Sistema exibe uma mensagem informando que já existe um registro com a mesma identificação informada;
5. Violação de integridade referencial. Sistema exibe uma mensagem informando que a operação não pode ser realizada indicando a violação de integridade que foi causada;
6. Alteração de registro alterado. Sistema exibe uma mensagem informando que a operação não pode ser realizada indicando o motivo do cancelamento da operação;
7. Alteração de registro excluído. Sistema exibe uma mensagem informando que a operação não pode ser realizada indicando o motivo do cancelamento da operação;
8. Exclusão de registro alterado. Sistema exibe uma mensagem informando que a operação não pode ser realizada indicando o motivo do cancelamento da operação;
9. Exclusão de registro excluído. Sistema exibe uma mensagem informando que a operação não pode ser realizada indicando o motivo do cancelamento da operação.
Requisitos de interface: 1. O curso deve ser exibido através de uma caixa de combinação contendo todos os
cursos cadastrados; 2. O campo de período da disciplina deve possibilitar o incremento e decremento do
valor do mesmo através de componente apropriado; 3. A ementa da disciplina deve ter sua entrada a partir de um controle para digitar
textos em mais de uma linha; 4. A bibliografia da disciplina deve ter sua entrada a partir de um controle para digitar
textos em mais de uma linha.
Pós-condições: Possibilitar o cadastro de turmas; Possibilitar emissão do relatório disciplinas por curso.
94
Requisitos não funcionais: Não aplicável.
Regras de Negócio:
RN1: Os campos obrigatórios são: código e descrição da disciplina, curso, período, número de aulas e ementa; RN2: O período da disciplina deve ser no mínimo 1 e no máximo o total de períodos do curso selecionado.
Caso de Uso 03: Cadastrar Professores Ator Principal:
Professor Sumário:
Este caso de uso é iniciado pelo professor quando ele requisita ao sistema um cadastro de professor, informando todos os dados, selecionando a opção correspondente a partir da interface, exibida previamente, que contém uma listagem dos professores cadastrados. O objetivo deste caso de uso é possibilitar que ocorra a inclusão de professores no sistema, a consulta, a alteração ou a exclusão daqueles já existentes. Pré-Condições:
Não aplicável. Fluxo Principal:
1. O professor solicita ao sistema o cadastro de professores; 2. O sistema exibe uma lista com os professores cadastrados, contendo matrícula e
nome do mesmo, ordenada, crescentemente, pela matrícula do professor; 3. O sistema solicita a opção de inclusão de um novo professor, alteração, exclusão ou
consulta de um professor selecionado na lista; 4. O professor informa a opção desejada. 5. O sistema executa o subfluxo correspondente ao tipo de operação escolhido (Incluir,
Alterar, Excluir, Consultar). Fluxos Alternativos:
1. O professor pode modificar a ordenação da lista de professores cadastrados, podendo ordenar pela matrícula ou pelo nome do mesmo.
2. O professor pode efetuar uma pesquisa na lista de professores cadastrados, podendo pesquisar pela matrícula ou pelo nome do professor. A pesquisa não necessita ser exata, sendo feita a partir do início do campo pesquisado. A pesquisa deve ignorar letras maiúsculas e minúsculas.
3. O professor pode cancelar a operação de cadastramento, fechando a interface. Subfluxo: Operação Incluir
1. O sistema exibe a interface com todos os campos habilitados; 2. O sistema exibe todos os campos vazios; 3. O sistema solicita a entrada dos seguintes dados: matrícula, nome, data de
nascimento, data de admissão, e-mail, telefone residencial, telefone comercial, telefone celular, fotografia, status (ativo ou inativo), coordenador (sim ou não), logradouro, número, complemento, bairro, cidade, UF, CEP, CPF, documento de identidade (número, órgão expedidor, UF e data expedição), titulação máxima (graduação, especialização, mestrado e doutorado), tipo de contrato (substituto,
95
auxiliar, assistente ou adjunto), benefícios (vale transporte e/ou vale alimentação) e alocação das disciplinas lecionadas pelo professor (selecionadas pela descrição e representadas pelos respectivos código);
4. O professor informa ao sistema os dados solicitados; 5. O sistema solicita a confirmação da operação; 6. O professor confirma operação; 7. O sistema efetua a validação dos campos (RN1, RN2); 8. O sistema efetua críticas de acesso concorrente (registro duplicado); 9. O sistema armazena os dados; 10. O sistema fecha a interface.
Subfluxo: Operação Alterar
1. O sistema exibe a interface com todos os campos habilitados, exceto a matrícula do professor;
2. O sistema efetua a leitura do registro a partir da matrícula do professor selecionado; 3. O sistema exibe os dados: matrícula, nome, data de nascimento, data de admissão,
e-mail, telefone residencial, telefone comercial, telefone celular, fotografia, status (ativo ou inativo), coordenador (sim ou não), logradouro, número, complemento, bairro, cidade, UF, CEP, CPF, documento de identidade (número, órgão expedidor, UF e data expedição), titulação máxima (graduação, especialização, mestrado e doutorado), tipo de contrato (substituto, auxiliar, assistente ou adjunto), benefícios (vale transporte e/ou vale alimentação) e alocação das disciplinas lecionadas pelo professor (selecionadas pela descrição e representadas pelos respectivos código);
4. O sistema solicita a modificação nos dados apresentados (exceto a matrícula); 5. O professor altera os campos; 6. O sistema solicita a confirmação da operação; 7. O professor confirma a operação; 8. O sistema efetua a validação dos campos (RN1, RN2); 9. O sistema efetua críticas de acesso concorrente (alteração de registro alterado ou
excluído); 10. O sistema armazena os dados; 11. O sistema fecha a interface.
Subfluxo: Operação Excluir
1. O sistema exibe a interface com todos os campos desabilitados; 2. O sistema efetua a leitura do registro a partir da matrícula do professor selecionado; 3. O sistema exibe os dados do professor nos respectivos campos; 4. O sistema solicita a confirmação da operação; 5. O professor confirma a operação; 6. O sistema efetua críticas de acesso concorrente (exclusão registro alterado ou
excluído); 7. O sistema exclui os dados; 8. O sistema fecha a interface.
Subfluxo: Operação Consultar
1. O sistema exibe a interface com todos os campos desabilitados; 2. O sistema efetua a leitura do registro a partir da matrícula do professor selecionado; 3. O sistema exibe os dados: matrícula, nome, data de nascimento, data de admissão,
e-mail, telefone residencial, telefone comercial, telefone celular, fotografia, status (ativo ou inativo), coordenador (sim ou não), logradouro, número, complemento, bairro, cidade, UF, CEP, CPF, documento de identidade (número, órgão expedidor, UF e data expedição), titulação máxima (graduação, especialização, mestrado e doutorado), tipo de contrato (substituto, auxiliar, assistente ou adjunto), benefícios
96
(vale transporte e/ou vale alimentação) e alocação das disciplinas lecionadas pelo professor (selecionadas pela descrição e representadas pelos respectivos código);
4. O professor fecha a interface. Fluxos Alternativos:
1. O professor cancela a operação de inclusão. O sistema exibe novamente todos os campos de entrada vazios;
2. O professor cancela a operação de alteração. O sistema exibe novamente os dados originais do registro;
3. O professor fecha a interface durante as operações de inclusão ou alteração. Caso tenham ocorrido modificações de informações, o sistema avisa da possibilidade de perda de dados.
Fluxos de Exceção:
1. A matrícula do professor não foi preenchida. O sistema exibe uma mensagem e retorna a entrada ao campo código do curso;
2. O nome do professor não foi preenchido. O sistema exibe uma mensagem e retorna a entrada ao campo nome do professor;
3. Registro duplicado. Sistema exibe uma mensagem informando que já existe um registro com a mesma identificação informada;
4. Violação de integridade referencial. Sistema exibe uma mensagem informando que a operação não pode ser realizada indicando a violação de integridade que foi causada;
5. Alteração de registro alterado. Sistema exibe uma mensagem informando que a operação não pode ser realizada indicando o motivo do cancelamento da operação;
6. Alteração de registro excluído. Sistema exibe uma mensagem informando que a operação não pode ser realizada indicando o motivo do cancelamento da operação;
7. Exclusão de registro alterado. Sistema exibe uma mensagem informando que a operação não pode ser realizada indicando o motivo do cancelamento da operação;
8. Exclusão de registro excluído. Sistema exibe uma mensagem informando que a operação não pode ser realizada indicando o motivo do cancelamento da operação.
Requisitos de interface: 1. Os dados data de nascimento, data de admissão e data de expedição devem estar
dispostos em controles de texto apropriados para utilização de máscara de data “__/__/____”;
2. Os dados de telefone residencial, comercial e celular devem estar dispostos em controles de texto apropriados para aplicação de máscara para número de telefone “(__)____-____”;
3. CEP deve estar disposto em controle de texto que possibilite a implementação da máscara “_____-___”;
4. CPF do professor deve estar disposto em controle de texto apropriado para a aplicação da máscara “_________-__”;
5. Os cursos disponíveis devem estar dispostos num controle de lista para exibição da sua descrição;
6. Os cursos em que o professor leciona devem estar dispostos num controle de lista para exibição de sua descrição;
7. A alocação ou remoção de alocação de cursos para um professor devem se dar por meio de comando de botão, para execução da ação apropriada, após selecionar a lista; ou, então, através da técnica de arrastar a linha selecionada de uma lista para a outra lista;
8. A foto do professor deve ser exibida em componente apropriado para exibição de imagens;
97
9. As UFs devem ser exibidas em uma caixa de combinação; 10. A titulação máxima do professor deve estar disposta em grupo de botões de rádio; 11. tipo de contrato do professor deve estar disposto em grupo de botões de rádio; 12. Os benefícios possíveis ao professor devem estar dispostos em caixas de
verificação, agrupadas em painel; 13. Os dados data de nascimento e data de expedição devem ser informados seguindo o
formato “dd/mm/yyyy”.
Pós-condições: Possibilitar o cadastro de turmas; Possibilitar emissão do relatório disciplinas por curso.
Requisitos não funcionais:
Não aplicável. Regras de Negócio:
RN1: Os campos obrigatórios são: matrícula e nome do professor; RN2: Quanto à titulação do professor, devem ser respeitados os seguintes aspectos:
• Caso a titulação seja graduação, o professor poderá exercer apenas do tipo de contrato substituto sem direito a benefícios;
• Caso a titulação seja especialização, o professor poderá exercer os tipos de contrato substituto e auxiliar, podendo, ainda, gozar do benefício do vale transporte;
• Caso a titulação seja mestrado, o professor poderá exercer os tipos de contrato substituto, auxiliar e assistente e, ainda, gozar do benefício de vale alimentação;
• Caso a titulação seja doutorado, o professor poderá exercer os tipos de contrato substituto, auxiliar, assistente e adjunto e gozar dos benefícios vale transporte e vale refeição.
Caso de Uso 04: Cadastrar Aluno Ator Principal:
Aluno Sumário:
Este caso de uso é iniciado pelo aluno quando ele requisita ao sistema um cadastro de aluno, informando todos os dados, selecionando a opção correspondente a partir da interface, exibida previamente, que contém uma listagem dos alunos cadastrados. O objetivo deste caso de uso é possibilitar que ocorra a inclusão de alunos no sistema, a consulta, a alteração ou a exclusão daqueles já existentes. Pré-Condições:
Não aplicável. Fluxo Principal:
1. O aluno solicita ao sistema o cadastro de alunos; 2. O sistema exibe uma lista com os alunos cadastrados, contendo matrícula e nome
do mesmo, ordenada, crescentemente, pelo nome do aluno; 3. O sistema solicita a opção de inclusão de um novo aluno, alteração, exclusão ou
consulta de um aluno selecionado na lista; 4. O aluno informa a opção desejada;
98
5. O sistema executa o subfluxo correspondente ao tipo de operação escolhido (Incluir, Alterar, Excluir ou Consultar).
Fluxos Alternativos:
1. O aluno pode modificar a ordenação da lista de alunos cadastrados, podendo ordenar, crescentemente, pela matrícula ou pelo nome do mesmo.
2. O aluno pode efetuar uma pesquisa na lista de alunos cadastrados, podendo pesquisar pela matrícula ou pelo nome do aluno. A pesquisa não necessita ser exata, sendo feita a partir do início do campo pesquisado. A pesquisa deve ignorar letras maiúsculas e minúsculas.
3. O aluno pode cancelar a operação de cadastramento, fechando a interface. Subfluxo: Operação Incluir
1. O sistema exibe a interface com todos os campos habilitados; 2. O sistema exibe todos os campos vazios; 3. O sistema solicita a entrada dos seguintes dados: matrícula, nome, data de
nascimento, curso, ano de início, semestre de início, e-mail, telefone residencial, telefone comercial, telefone celular, fotografia, status (ativo ou inativo), logradouro, número, complemento, bairro, cidade, UF, CEP, CPF, documento de identidade (número, órgão expedidor, UF e data expedição);
4. O aluno informa ao sistema os dados solicitados; 5. O sistema solicita a confirmação da operação; 6. O aluno confirma operação; 7. O sistema efetua a validação dos campos (RN1, RN2, RN3); 8. O sistema efetua críticas de acesso concorrente (registro duplicado); 9. O sistema armazena os dados; 10. O sistema fecha a interface.
Subfluxo: Operação Alterar
1. O sistema exibe a interface com todos os campos habilitados, exceto a matrícula do professor;
2. O sistema efetua a leitura do registro a partir da matrícula do professor selecionado; 3. Sistema exibe os dados: matrícula, nome, data de nascimento, curso, ano de início,
semestre de início, e-mail, telefone residencial, telefone comercial, telefone celular, fotografia, status (ativo ou inativo), logradouro, número, complemento, bairro, cidade, UF, CEP, CPF, documento de identidade (número, órgão expedidor, UF e data expedição);
4. Sistema solicita a modificação nos dados apresentados (exceto a matrícula); 5. O aluno altera os campos; 6. O sistema solicita a confirmação da operação; 7. O aluno confirma a operação; 8. O sistema efetua a validação dos campos (RN1, RN2, RN3); 9. O sistema efetua críticas de acesso concorrente (alteração de registro alterado ou
excluído); 10. O sistema armazena os dados; 11. O sistema fecha a interface.
Subfluxo: Operação Excluir
1. O sistema exibe a interface com todos os campos desabilitados; 2. O sistema efetua a leitura do registro a partir da matrícula do aluno selecionado; 3. Sistema exibe os dados do aluno nos respectivos campos; 4. O sistema solicita a confirmação da operação; 5. O aluno confirma a operação;
99
6. O sistema efetua críticas de acesso concorrente (exclusão registro alterado ou excluído);
7. O sistema exclui os dados; 8. O sistema fecha a interface.
Subfluxo: Operação Consultar
1. O sistema exibe a interface com todos os campos desabilitados; 2. O sistema efetua a leitura do registro a partir da matrícula do aluno selecionado; 3. Sistema exibe os dados: matrícula, nome, data de nascimento, curso, ano de início,
semestre de início, e-mail, telefone residencial, telefone comercial, telefone celular, fotografia, status (ativo ou inativo), logradouro, número, complemento, bairro, cidade, UF, CEP, CPF, documento de identidade (número, órgão expedidor, UF e data expedição);
4. O aluno fecha a interface. Fluxos Alternativos:
1. O aluno cancela a operação de inclusão. O sistema exibe novamente todos os campos de entrada vazios;
2. O aluno cancela a operação de alteração. O sistema exibe novamente os dados originais do registro;
3. O aluno fecha a interface durante as operações de inclusão ou alteração. Caso tenham ocorrido modificações de informações, o sistema avisa da possibilidade de perda de dados.
Fluxos de Exceção:
1. A matrícula do aluno não foi preenchida. O sistema exibe uma mensagem e retorna a entrada ao campo código do curso;
2. O nome do aluno não foi preenchido. O sistema exibe uma mensagem e retorna a entrada ao campo nome do aluno;
3. Registro duplicado. Sistema exibe uma mensagem informando que já existe um registro com a mesma identificação informada;
4. Violação de integridade referencial. Sistema exibe uma mensagem informando que a operação não pode ser realizada indicando a violação de integridade que foi causada;
5. Alteração de registro alterado. Sistema exibe uma mensagem informando que a operação não pode ser realizada indicando o motivo do cancelamento da operação;
6. Alteração de registro excluído. Sistema exibe uma mensagem informando que a operação não pode ser realizada indicando o motivo do cancelamento da operação;
7. Exclusão de registro alterado. Sistema exibe uma mensagem informando que a operação não pode ser realizada indicando o motivo do cancelamento da operação;
8. Exclusão de registro excluído. Sistema exibe uma mensagem informando que a operação não pode ser realizada indicando o motivo do cancelamento da operação.
Requisitos de interface: 1. Os dados data de nascimento e data de expedição devem estar dispostos em
controles de texto apropriados para utilização de máscara de data “__/__/____”; 2. Os dados de telefone residencial, comercial e celular devem estar dispostos em
controles de texto apropriados para aplicação de máscara para número de telefone “(__)____-____”;
3. O CEP deve estar disposto em controle de texto que possibilite a implementação da máscara “_____-___”;
4. O CPF do professor deve estar disposto em controle de texto apropriado para a aplicação da máscara “_________-__”;
100
5. A foto do aluno deve ser exibida em componente apropriado para exibição de imagens;
6. As UFs devem ser exibidas em uma caixa de combinação; 7. Os dados data de nascimento e data de expedição devem ser informados seguindo o
formato “dd/mm/yyyy”.
Pós-condições: Possibilitar matrícula de alunos; Possibilitar emissão do relatório de histórico escolar; Possibilitar emissão do relatório de alunos por turma.
Requisitos não funcionais:
Não aplicável. Regras de Negócio:
RN1: Os campos obrigatórios são: matrícula e nome do aluno; RN2: Caso seja informado, o ano letivo deve conter apenas 4 dígitos; RN3: Para semestre de início deve ser admitido apenas os valores 1 e 2, que ser referem, respectivamente, ao primeiro e segundo semestre de um ano. Deve ser composto, portanto, por um dígito apenas.
Caso de Uso 05: Cadastrar Turma Ator Principal:
Secretaria Sumário:
Este caso de uso é iniciado pela secretaria quando ela requisita ao sistema um cadastro de turma, informando todos os dados, selecionando a opção correspondente a partir da interface, exibida previamente, que contém uma listagem das turmas cadastradas. O objetivo deste caso de uso é possibilitar que ocorra a inclusão de turmas no sistema, a consulta, a alteração ou a exclusão daquelas já existentes. Pré-Condições:
1. Curso cadastrado; 2. Disciplina cadastrada; 3. Professor cadastrado.
Fluxo Principal:
1. A secretaria solicita ao sistema o cadastro de turmas; 2. O sistema exibe uma lista com as turmas cadastradas, contendo descrição do curso,
descrição da disciplina, ano, semestre e descrição da turma; ordenada, alfabeticamente, pela descrição do curso;
3. O sistema solicita a opção de inclusão de uma nova turma, alteração, exclusão ou consulta de uma turma selecionada na lista;
4. A secretaria informa a opção desejada; 5. O sistema executa o subfluxo correspondente ao tipo de operação escolhido (Incluir,
Alterar, Excluir ou Consultar). Fluxos Alternativos:
101
1. A secretaria pode modificar a ordenação da lista de turmas cadastradas, podendo ordenar, crescentemente, pela descrição do curso, descrição da disciplina, ano, semestre e descrição da turma;
2. A secretaria pode efetuar uma pesquisa na lista de turmas cadastradas, podendo pesquisar pela descrição do curso, descrição da disciplina, ano, semestre e descrição da turma;
3. A secretaria pode cancelar a operação de cadastramento, fechando a interface. Subfluxo: Operação Incluir
1. O sistema exibe a interface com todos os campos habilitados; 2. O sistema exibe todos os campos vazios; 3. O sistema solicita a entrada dos seguintes dados: curso (selecionado pela descrição
e representado pelo código), disciplina (selecionada pela descrição e representada pelo código), descrição da turma, ano, semestre, número máximo de alunos e professor responsável (selecionado pelo nome e representado pelo respectivo código);
4. A secretaria informa ao sistema os dados solicitados; 5. O sistema solicita a confirmação da operação; 6. A secretaria confirma operação; 7. O sistema efetua a validação dos campos (RN1, RN2, RN3, RN4); 8. O sistema efetua críticas de acesso concorrente (registro duplicado); 9. O sistema armazena os dados; 10. O sistema fecha a interface.
Subfluxo: Operação Alterar
1. O sistema exibe a interface com todos os campos habilitados, exceto curso, disciplina, ano, semestre e descrição da turma;
2. O sistema efetua a leitura do registro a partir do identificador da turma selecionada na lista da interface de pesquisa;
3. Sistema exibe os dados: curso (selecionado pela descrição e representado pelo código), disciplina (selecionada pela descrição e representada pelo código), descrição da turma, ano, semestre, número máximo de alunos e professor responsável (selecionado pelo nome e representado pelo respectivo código);
4. Sistema solicita a modificação nos dados apresentados (curso, disciplina, ano, semestre e descrição da turma);
5. A secretaria altera os campos; 6. O sistema solicita a confirmação da operação; 7. A secretaria confirma a operação; 8. O sistema efetua a validação dos campos (RN1, RN2, RN3, RN4); 9. O sistema efetua críticas de acesso concorrente (alteração de registro alterado ou
excluído); 10. O sistema armazena os dados; 11. O sistema fecha a interface.
Subfluxo: Operação Excluir
1. O sistema exibe a interface com todos os campos desabilitados; 2. O sistema efetua a leitura do registro a partir do identificador da turma, respectivo
àquela selecionada na interface de pesquisa; 3. O sistema exibe os dados da turma nos respectivos campos; 4. O sistema solicita a confirmação da operação; 5. A secretaria confirma a operação; 6. O sistema efetua críticas de acesso concorrente (exclusão registro alterado ou
excluído);
102
7. O sistema exclui os dados; 8. O sistema fecha a interface.
Subfluxo: Operação Consultar
1. O sistema exibe a interface com todos os campos desabilitados; 2. O sistema efetua a leitura do registro a partir do identificador da turma, respectivo
àquela selecionada na interface de pesquisa; 3. O sistema exibe os dados: curso (selecionado pela descrição e representado pelo
código), disciplina (selecionada pela descrição e representada pelo código), descrição da turma, ano, semestre, número máximo de alunos e professor responsável (selecionado pelo nome e representado pelo respectivo código);
4. A secretaria fecha a interface. Fluxos Alternativos:
1. A secretaria cancela a operação de inclusão. O sistema exibe novamente todos os campos de entrada vazios;
2. A secretaria cancela a operação de alteração. O sistema exibe novamente os dados originais do registro;
3. A secretaria fecha a interface durante as operações de inclusão ou alteração. Caso tenham ocorrido modificações de informações, o sistema avisa da possibilidade de perda de dados.
Fluxos de Exceção:
1. O curso, ao qual à turma pertence, não foi selecionado. O sistema exibe uma mensagem e retorna a entrada ao campo de seleção do curso;
2. A disciplina, ao qual à turma pertence, não foi selecionada. O sistema exibe uma mensagem e retorna a entrada ao campo de seleção da disciplina;
3. O ano de abertura da turma não foi informado. O sistema exibe uma mensagem e retorna a entrada ao campo de ano de abertura;
4. O semestre de abertura da turma não foi informado. O sistema exibe uma mensagem e retorna a entrada ao campo de semestre de abertura;
5. A descrição da turma não foi preenchida. O sistema exibe uma mensagem e retorna a entrada ao campo descrição da turma;
6. O professor responsável da turma não foi selecionado. O sistema exibe uma mensagem e retorna a entrada ao campo de seleção do professor responsável;
7. Registro duplicado. Sistema exibe uma mensagem informando que já existe um registro com a mesma identificação informada;
8. Violação de integridade referencial. Sistema exibe uma mensagem informando que a operação não pode ser realizada indicando a violação de integridade que foi causada;
9. Alteração de registro alterado. Sistema exibe uma mensagem informando que a operação não pode ser realizada indicando o motivo do cancelamento da operação;
10. Alteração de registro excluído. Sistema exibe uma mensagem informando que a operação não pode ser realizada indicando o motivo do cancelamento da operação;
11. Exclusão de registro alterado. Sistema exibe uma mensagem informando que a operação não pode ser realizada indicando o motivo do cancelamento da operação;
12. Exclusão de registro excluído. Sistema exibe uma mensagem informando que a operação não pode ser realizada indicando o motivo do cancelamento da operação.
Requisitos de interface: 1 Os dados curso, disciplina e professor responsável devem ser exibidos, cada qual,
em caixa de combinação.
103
Pós-condições: 1. Possibilitar matrícula de alunos; 2. Possibilitar emissão do relatório de histórico escolar; 3. Possibilitar emissão do relatório de alunos por turma.
Requisitos não funcionais:
Não aplicável. Regras de Negócio:
RN1: Os campos obrigatórios são: curso, disciplina, ano, semestre, descrição da turma e professor responsável; RN2: O ano deve conter apenas 4 dígitos; RN3: Para semestre de início deve ser admitido apenas os valores 1 e 2, que ser referem, respectivamente, ao primeiro e segundo semestre de um ano. Deve ser composto, portanto, por um dígito apenas; RN4: A descrição da turma deve possuir no máximo 10 caracteres.
Caso de Uso 06: Matricular Alunos Ator Principal:
Aluno Sumário:
Este caso de uso é iniciado pelo aluno quando ele requisita ao sistema matricular alunos, informando todos os dados, selecionando a turma correspondente a partir da interface, exibida previamente, que contém uma listagem das turmas cadastradas. O objetivo deste caso de uso é possibilitar que ocorra a matrícula de alunos em turmas, no sistema, a modificação da lista de alunos matriculados na turma selecionada e, por conseqüência, a remoção da matrícula de alunos da turma selecionada. Pré-Condições:
1. Turma cadastrada; 2. Aluno cadastrado.
Fluxo Principal:
1. O aluno solicita ao sistema a matrícula de alunos; 2. O sistema exibe uma lista com as turmas cadastradas, contendo descrição do curso,
descrição da disciplina, ano, semestre e descrição da turma; ordenada, alfabeticamente, pela descrição do curso;
3. O sistema solicita a opção de matricular alunos a partir da seleção de uma turma na lista de turmas disponibilizada;
4. O aluno seleciona a opção de matricular alunos; 5. O sistema exibe a interface de matrícula com lista de alunos e o campo de pesquisa
de alunos habilitado; 6. O sistema preenche a interface de matrícula com os dados curso, disciplina, ano,
semestre, turma, lista de alunos (matriculados ou não), professor responsável, total de vagas e vagas restantes;
7. O sistema solicita a matrícula de alunos ou a remoção de matrícula daqueles que estiverem cadastrados;
8. O aluno marca a caixa de verificação, na lista, correspondente para cada aluno que de seja matricular RN1;
104
9. O aluno desmarca a caixa de verificação correspondente para cada aluno que deseja remover matrícula;
10. O sistema solicita confirmação da lista de matrícula configurada; 11. O aluno confirma os dados; 12. O sistema efetua validação dos campos RN2; 13. O sistema executa críticas de integridade referencial e acesso concorrente; 14. O sistema armazena os dados; 15. O sistema fecha a interface.
Fluxos Alternativos:
1. O aluno pode modificar a ordenação da lista de turmas cadastradas, podendo ordenar, crescentemente, pela descrição do curso, descrição da disciplina, ano, semestre e descrição da turma;
2. O aluno pode efetuar uma pesquisa na lista de turmas cadastradas, podendo pesquisar pela descrição do curso, descrição da disciplina, ano, semestre e descrição da turma;
3. O aluno pode filtrar a lista de turmas disponibilizada, na interface de pesquisa, através do curso, disciplina, ano e semestre, necessariamente nessa ordem, de acordo com a demanda desejada;
4. O aluno pode cancelar a operação de matrícula, fechando a interface; 5. O aluno pode pesquisar a lista de alunos disponível, na interface de matrícula, pela
matrícula ou pelo nome do aluno. A pesquisa não precisa ser exata, podendo ser executada a partir do primeiro caractere do campo selecionado;
6. O aluno pode ordenar, crescentemente, a lista de alunos disponível na interface de matrícula pelo número de matrícula ou pelo nome do aluno;
7. O aluno cancela a operação de matrícula. O sistema exibe novamente todos os campos de entrada no seu estado original;
8. O aluno fecha a interface durante a operação de matrícula. Caso tenha ocorrido modificação de informações, o sistema avisa da possibilidade de perda de dados;
Fluxos de Exceção:
1. Violação de integridade referencial. Sistema exibe uma mensagem informando que a operação não pode ser realizada indicando a violação de integridade que foi causada;
2. Alteração de registro alterado. Sistema exibe uma mensagem informando que a operação não pode ser realizada indicando o motivo do cancelamento da operação;
3. Alteração de registro excluído. Sistema exibe uma mensagem informando que a operação não pode ser realizada indicando o motivo do cancelamento da operação;
4. Exclusão de registro alterado. Sistema exibe uma mensagem informando que a operação não pode ser realizada indicando o motivo do cancelamento da operação;
5. Exclusão de registro excluído. Sistema exibe uma mensagem informando que a operação não pode ser realizada indicando o motivo do cancelamento da operação.
Requisitos de interface: 1. Os alunos devem ser exibidos em uma lista com caixa de verificação para efetuar
matrícula ou remover a matrícula.
Pós-condições: Possibilitar emissão do relatório de histórico escolar; Possibilitar emissão do relatório de alunos por turma.
Requisitos não funcionais:
105
Não aplicável. Regras de Negócio:
RN1: Durante a seleção dos alunos para efetuar matrícula, se o total de alunos selecionados superar o número máximo de alunos admitidos por turma, a operação deve ser permitida, porém o sistema deverá emitir o aviso pertinente; RN2: O aluno deve possuir apenas uma matrícula.
Caso de Uso 07: Avaliação de Alunos Ator Principal:
Professor Sumário:
Este caso de uso é iniciado pelo professor quando ele requisita ao sistema avaliar alunos matriculados em uma turma, informando todos os dados, selecionando a turma correspondente a partir da interface, exibida previamente, que contém uma listagem das turmas cadastradas. O objetivo deste caso de uso é possibilitar que ocorra o lançamento de avaliação para alunos de uma turma, no sistema. Pré-Condições:
1. Turma cadastrada; 2. Aluno matriculado.
Fluxo Principal:
1. O professor solicita ao sistema a avaliação de alunos; 2. O sistema exibe uma lista com as turmas cadastradas, contendo descrição do curso,
descrição da disciplina, ano, semestre e descrição da turma; ordenada, alfabeticamente, pela descrição do curso;
3. O sistema solicita a opção de avaliar alunos a partir da seleção de uma turma na lista de turmas disponibilizada;
4. O professor seleciona a opção de matricular alunos; 5. O sistema exibe a interface de matrícula com lista de alunos e o campo de pesquisa
de alunos habilitado; 6. O sistema preenche a interface de avaliação da turma com os dados curso,
disciplina, ano, semestre, turma, lista de alunos matriculados e professor responsável;
7. O sistema solicita o lançamento de avaliação dos alunos; 8. O professor seleciona o aluno para lançara a avaliação; 9. O professor solicita a exibição da interface de lançamento da avaliação do aluno; 10. O sistema exibe a interface de avaliação do aluno, preenchendo-a com os dados
curso, disciplina, ano, semestre, turma, matrícula do aluno e nome do aluno, deixando-os desabilitados. São disponibilizados os campos faltas, avaliação 1, avaliação 2 e avaliação final;
11. O professor informa os dados da avaliação do aluno; 12. O sistema solicita confirmação da avaliação lançada; 13. O professor confirma a avaliação lançada (RN1, RN2, RN3, RN4); 14. O sistema armazena os dados da avaliação; 15. O professor fecha a interface de avaliação.
106
Fluxos Alternativos: 1. O professor pode modificar a ordenação da lista de turmas cadastradas, podendo
ordenar, crescentemente, pela descrição do curso, descrição da disciplina, ano, semestre e descrição da turma;
2. O professor pode efetuar uma pesquisa na lista de turmas cadastradas, podendo pesquisar pela descrição do curso, descrição da disciplina, ano, semestre e descrição da turma;
3. O professor pode filtrar a lista de turmas disponibilizada, na interface de pesquisa, através do curso, disciplina, ano e semestre, necessariamente nessa ordem, de acordo com a demanda desejada;
4. O professor pode cancelar a operação de avaliação, fechando a interface; 5. O professor pode pesquisar a lista de alunos disponível, na interface de avaliação da
turma, pela matrícula ou pelo nome do aluno. A pesquisa não precisa ser exata, podendo ser executada a partir do primeiro caractere do campo selecionado;
6. O professor pode ordenar, crescentemente, a lista de alunos disponível na interface de avaliação de turmas pelo número de matrícula ou pelo nome do aluno;
7. O professor pode cancela a digitação da avaliação do aluno selecionado, caso haja alguma modificação quanto aos dados anteriores, o estado original é restaurado;
8. O professor fecha a interface de avaliação do aluno. Se houve alguma modificação nos dados, o sistema avisa que os dados serão perdidos;
9. O professor fecha a interface durante a operação de matrícula. Caso tenha ocorrido modificação de informações, o sistema avisa da possibilidade de perda de dados;
Fluxos de Exceção:
1. Violação de integridade referencial. Sistema exibe uma mensagem informando que a operação não pode ser realizada indicando a violação de integridade que foi causada;
2. Alteração de registro alterado. Sistema exibe uma mensagem informando que a operação não pode ser realizada indicando o motivo do cancelamento da operação;
3. Alteração de registro excluído. Sistema exibe uma mensagem informando que a operação não pode ser realizada indicando o motivo do cancelamento da operação;
4. Exclusão de registro alterado. Sistema exibe uma mensagem informando que a operação não pode ser realizada indicando o motivo do cancelamento da operação;
5. Exclusão de registro excluído. Sistema exibe uma mensagem informando que a operação não pode ser realizada indicando o motivo do cancelamento da operação.
Requisitos de interface: 1. Os alunos devem ser exibidos, na interface de avaliação da turma, em uma lista com
os dados matrícula, nome e os dados faltas, avaliação 1, avaliação 2 e avaliação final;
2. Na avaliação dos alunos, os dados faltas, avaliação 1, avaliação 2 e avaliação final devem ser disponibilizados por meio de caixas de texto.
Pós-condições: Possibilitar emissão do relatório de histórico escolar.
Requisitos não funcionais:
Não aplicável. Regras de Negócio:
RN1: Os dados faltas, avaliação 1, avaliação 2 e avaliação final devem são valores numéricos;
107
RN2: Os dados avaliação 1, avaliação 2 e avaliação final devem são valores numéricos podem assumir até 2 casas decimais; RN3: As faltas podem assumir qualquer valor inteiro, positivo, entre 0 e 999; RN4: Os dados avaliação 1, avaliação 2 e avaliação final devem são valores numéricos podem assumir qualquer valor decimal, positivo, entre 0 e 10.
Caso de Uso 08: Relatório de Disciplinas por Curso Ator Principal:
Secretaria Sumário:
Este caso de uso é iniciado pela secretaria quando ela deseja visualizar as disciplinas cadastradas em cada curso. O objetivo deste caso de uso é possibilitar que ocorra emissão de um relatório de disciplinas por curso, previamente visualizado em tela e, depois, podendo ser impresso e/ou exportado. Pré-Condições:
1. Curso cadastrado; 2. Disciplina cadastrada.
Fluxo Principal:
1. A secretaria solicita, no menu Relatórios, ao sistema a emissão do relatório de disciplinas por curso;
2. O sistema seleciona os dados descrição do curso e descrição da disciplina, devidamente relacionados e ordenados, crescentemente, com essa mesma precedência;
3. O sistema exibe o relatório composto de cabeçalho (contendo nome do sistema, nome do relatório, data de emissão, logomarca do sistema, e cabeçalho dos dados a sem exibidos);
4. O sistema exibe a descrição das disciplinas selecionadas agrupadas segundo à descrição dos cursos selecionados;
5. O sistema totaliza o número de disciplinas por curso e exibe o total no rodapé de cada grupo de disciplinas;
6. O sistema totaliza o número de cursos selecionados e exibe no rodapé do relatório; 7. O sistema totaliza a contagem distinta de disciplinas (independente de seus cursos)
e exibe o dado no rodapé do relatório; 8. A secretaria fecha o relatório.
Fluxos Alternativos:
1. A secretaria imprime o relatório através do respectivo comando na interface do relatório;
2. A secretaria exporta o relatório através do respectivo comando na interface do relatório.
Fluxos de Exceção:
1. Ao selecionar os dados, a composição está vazia. O sistema exibe o aviso pertinente;
2. Não há dispositivo de impressão instalado, os comando de impressão aparece desabilitado;
3. Não há espaço suficiente no dispositivo de armazenamento para reter o relatório exportado. Uma mensagem pertinente é exibida;
108
4. Os dados que compõe o cabeçalho do relatório devem ser exibidos em negrito, exceto pela data;
5. Os dados do curso devem ser exibidos em negrito; 6. A data de emissão do relatório deve estar no formato “dd/mm/yyyy”; 7. O sistema deve separar os dados dos alunos dos dados da turma através de uma
linha. Requisitos de interface:
1. A interface do relatório deve permitir navegação entre as páginas, configuração do dispositivo de impressão, impressão do relatório visualizado, ajustar visualização da página à área disponível na tela, ajustar visualização da pagina para o tamanho real, exportar o relatório visualizado. Cada uma das ações, acima previstas, deve ser possibilitadas por meio de um clique num botão de comando, que deve possuir uma figura representando cada uma das ações e mostrar uma dica da ação realizada;
2. O texto de explicativo de cada uma ação de comando do relatório deve ser exibido apenas quando o cursor do dispositivo de ponteiro (mouse) esteja posicionado sobre um dos botões, sem qualquer dos botões pressionados (continuamente ou não), após um segundo na mesma posição;
3. Ao posicionar o cursor de ponteiro (mouse) sobre qualquer dos botões de comando descritos no primeiro requisito de interface, os mesmos devem ser ressaltados por um relevo ao painel que os agrupa;
4. Os dados que compõe o cabeçalho do relatório devem ser exibidos em negrito, exceto pela data de emissão;
5. Os dados do curso, que compõem o cabeçalho de cada página do relatório, devem ser exibidos em negrito;
6. A data de emissão do relatório deve estar no formato “dd/mm/yyyy”; 7. O sistema deve separar os dados dos cursos dos dados das disciplinas através de
uma linha; 8. Cada curso deverá iniciar sua exibição/impressão em uma nova página.
Pós-condições:
Não aplicável.
Requisitos não funcionais: 1. Os relatórios exportados devem estar sob a extensão .QRP.
Regras de Negócio:
Não aplicável. Caso de Uso 09: Relatório de Alunos por Turma Ator Principal:
Professor Sumário:
Este caso de uso é iniciado pelo professor quando ele deseja visualizar os alunos matriculados em uma ou mais turmas cadastradas em cada curso. O objetivo deste caso de uso é possibilitar que o professor possa destacar a listagem de alunos matriculado na disciplina desejada, podendo, posteriormente, ser impresso e/ou exportado. Pré-Condições:
1. Turma cadastrada;
109
2. Aluno matriculado. Fluxo Principal:
1. O professor solicita, no menu Relatórios, ao sistema a emissão do relatório de alunos por turma;
2. O sistema seleciona os seguintes dados que compõe a turma e seu relacionamento com os alunos matriculados nela: descrição do curso, descrição da disciplina, ano, semestre, descrição da turma, matrícula do aluno, nome do aluno e nome do professor responsável. Os dados são ordenados de acordo com a seguinte precedência: descrição do curso, descrição da disciplina, ano da turma, semestre da turma, descrição da turma e nome do aluno; todos em ordem crescente. (RN1, RN2);
3. O sistema exibe o relatório composto de cabeçalho (contendo nome do sistema, nome do relatório, data de emissão, logomarca do sistema, e cabeçalho dos dados a sem exibidos);
4. O sistema exibe a descrição dos cursos em frente ao cabeçalho de curso; 5. O sistema exibe a descrição das disciplinas em frente ao cabeçalho de disciplina; 6. O sistema exibe os dados ano, semestre, turma, e professor responsável abaixo dos
respectivos cabeçalhos; 7. O sistema exibe os dados de matrícula do aluno e nome do aluno em detalhe,
agrupados sob a turma em que estão matriculados; 8. O sistema totaliza o número de alunos matriculados em uma turma e exibe o dado
no rodapé do grupo de turmas; 9. O sistema totaliza o número de turmas selecionadas e exibe o dado no rodapé do
relatório; 10. O professor fecha o relatório.
Fluxos Alternativos:
1. O professor imprime o relatório através do respectivo comando na interface do relatório;
2. O professor exporta o relatório através do respectivo comando na interface do relatório.
Fluxos de Exceção:
1. Ao selecionar os dados, a composição está vazia. O sistema exibe o aviso pertinente;
2. Não há dispositivo de impressão instalado, os comando de impressão aparece desabilitado;
3. Não há espaço suficiente no dispositivo de armazenamento para reter o relatório exportado. Uma mensagem pertinente é exibida.
Requisitos de interface:
1. A interface do relatório deve permitir navegação entre as páginas, configuração do dispositivo de impressão, impressão do relatório visualizado, ajustar visualização da página à área disponível na tela, ajustar visualização da pagina para o tamanho real, exportar o relatório visualizado. Cada uma das ações, acima previstas, deve ser possibilitadas por meio de um clique num botão de comando, que deve possuir uma figura representando cada uma das ações e mostrar uma dica da ação realizada;
2. O texto de explicativo de cada uma ação de comando do relatório deve ser exibido apenas quando o cursor do dispositivo de ponteiro (mouse) esteja posicionado sobre um dos botões, sem qualquer dos botões pressionados (continuamente ou não), após um segundo na mesma posição;
110
3. Ao posicionar o cursor de ponteiro (mouse) sobre qualquer dos botões de comando descritos no primeiro requisito de interface, os mesmos devem ser ressaltados por um relevo ao painel que os agrupa;
4. Os dados que compõe o cabeçalho do relatório devem ser exibidos em negrito, exceto pela data de emissão;
5. Os dados da turma, que compõe o cabeçalho de cada página do relatório devem ser exibidos em negrito;
6. A data de emissão do relatório deve estar no formato “dd/mm/yyyy”; 7. O sistema deve separar os dados dos alunos dos dados da turma através de uma
linha; 8. Cada turma deverá iniciar sua exibição/impressão em uma nova página.
Pós-condições:
Não aplicável.
Requisitos não funcionais: 1. Os relatórios exportados devem estar sob a extensão .QRP.
Regras de Negócio:
RN1: Serão exibidos (visualizados, impressos e exportados), no relatório, somente os alunos ativos; RN2: Serão exibidos (visualizados, impressos e exportados), no relatório, somente os alunos matriculados.
Caso de Uso 10: Relatório de Histórico Escolar Ator Principal:
Aluno Sumário:
Este caso de uso é iniciado pelo aluno quando ele deseja visualizar o seu histórico escolar. O objetivo deste caso de uso é possibilitar que o aluno obtenha sua participação em disciplinas do curso bem como a avaliação em cada uma dessas disciplinas.
Pré-Condições:
1. Turma cadastrada; 2. Aluno cadastrado.
Fluxo Principal:
1. O aluno solicita, no menu Relatórios, ao sistema, a emissão do relatório de histórico escolar;
2. O sistema seleciona os seguintes dados: descrição do curso, descrição da disciplina, número de aulas da disciplina, ano da turma, semestre da turma, matrícula do aluno, nome do aluno, avaliação 1, avaliação 2, avaliação final e número de faltas. A ordenação dos dados, de modo crescente, segue a seguinte ordem de precedência: descrição do curso, nome do aluno, descrição da disciplina, número de aulas da disciplina e status;
3. O sistema demonstra, baseado na seleção, um status de aprovação para cada disciplina. (RN1, RN2, RN3 e RN4);
4. O sistema exibe o relatório composto de cabeçalho (contendo nome do sistema, nome do relatório, data de emissão, logomarca do sistema, e cabeçalho dos dados a sem exibidos);
111
5. O sistema exibe a descrição dos cursos em frente ao cabeçalho de curso; 6. O sistema exibe os dados de matrícula do aluno e nome do aluno em frente aos
respectivos cabeçalhos; 7. O sistema exibe os dados descrição da disciplina, número de aulas, ano, semestre,
avaliação 1, avaliação 2, avaliação final, número de faltas e status em detalhe, agrupados sob os dados do aluno;
8. O sistema totaliza a contagem de disciplinas cursadas, a contagem de aulas, a contagem de faltas e faz uma média da avaliação final, exibindo esses dados no rodapé do histórico de cada aluno;
9. O sistema totaliza o número de alunos sobre o qual foi relatado o histórico escolar, exibindo o dado no rodapé do relatório;
10. O aluno fecha o relatório. Fluxos Alternativos:
1. O aluno imprime o relatório através do respectivo comando na interface do relatório; 2. O aluno exporta o relatório através do respectivo comando na interface do relatório.
Fluxos de Exceção:
1. Ao selecionar os dados, a composição está vazia. O sistema exibe o aviso pertinente;
2. Não há dispositivo de impressão instalado, os comando de impressão aparece desabilitado;
3. Não há espaço suficiente no dispositivo de armazenamento para reter o relatório exportado. Uma mensagem pertinente é exibida.
Requisitos de interface:
1. A interface do relatório deve permitir navegação entre as páginas, configuração do dispositivo de impressão, impressão do relatório visualizado, ajustar visualização da página à área disponível na tela, ajustar visualização da pagina para o tamanho real, exportar o relatório visualizado. Cada uma das ações, acima previstas, deve ser possibilitadas por meio de um clique num botão de comando, que deve possuir uma figura representando cada uma das ações e mostrar uma dica da ação realizada;
2. O texto de explicativo de cada uma ação de comando do relatório deve ser exibido apenas quando o cursor do dispositivo de ponteiro (mouse) esteja posicionado sobre um dos botões, sem qualquer dos botões pressionados (continuamente ou não), após um segundo na mesma posição;
3. Ao posicionar o cursor de ponteiro (mouse) sobre qualquer dos botões de comando descritos no primeiro requisito de interface, os mesmos devem ser ressaltados por um relevo ao painel que os agrupa;
4. Os dados que compõe o cabeçalho do relatório devem ser exibidos em negrito, exceto pela data de emissão;
5. Os dados, que compõe o cabeçalho de cada página do relatório, devem ser exibidos em negrito;
6. A data de emissão do relatório deve estar no formato “dd/mm/yyyy”; 7. O sistema deve desenhar uma tabela para conter os dados do detalhe; 8. Cada histórico escolar deve ter seu início em uma nova página.
Pós-condições:
Não aplicável.
Requisitos não funcionais: 1. Os relatórios exportados devem estar sob a extensão .QRP.
112
Regras de Negócio:
RN1: Serão selecionados dados históricos de disciplinas cursadas pelos alunos; RN2: Caso o aluno tenha mais que 25% de infreqüência em uma disciplina, seu status, na mesma, será reprovado por infreqüência; em caso contrário a próxima regra de negócio é aplicada; RN3: A avaliação final deve ser a média aritmética dos valores da avaliação 1, da avaliação 2. Caso o aluno obtenha entre 7 e 10 pontos nessa média, seu status será aprovado. No caso dessa média estar entre 3 e 6,99, a nota da avaliação final será somada à média, anteriormente obtida, e uma nova média aritmética é calculada sobre a soma realizada (nesse caso, se o aluno obtiver uma nota final entre 5 e 10, estará aprovado, constando tal status no respectivo campo do relatório). Em caso contrário às situações acima previstas, o status do aluno naquela disciplina deverá constar no histórico como reprovado por nota; RN4: A regra de negócio 2 precede, indiscutivelmente, sobre regra de negócio 3 desse caso de uso.
113
6 – Diagrama de classes Domínio:
Pessoanome : Stringdatanascimento : Dateemail : Stringtelefonecomercial : Stringtelefoneresidencial : Stringtelefonecelular : Stringlogradouro : Stringnumero : Integercomplemento : Stringbairro : Stringcidade : StringUF : Stringcep : Stringcpf : Stringdocidentidade : Stringorgaoexpedidor : Stringdataexpedicao : Datefoto : Imagestatus : String
Professormatriculaprofessor : Integerdataadmissao : Datetitulacao : Integertipocontrato : Integervaletransporte : Stringvalealimentacao : String
Turmaanoturma : Integersemestre : Integerdescricao : Stringnummaximoaluno : Integer
10..* 10..*
Cursocodigocurso : Integerdescricao : Stringcargahoraria : Integerquantidadeperiodo : Integertipo : Integer
1
1
1
1
Coordena
0..*
0..*
0..*
0..*
Aloca
Disciplinacodigodisciplina : Stringdescricao : Stringperiodo : Integernumeroaulas : Integerementa : Stringbibliografia : String
1
0..*
1
0..*
10..* 10..*
Alunomatriculaaluno : Integeranoinicio : Integersemestreinicio : Integer
0..*
0..*
0..*
0..*
0..*1
0..*1
1..*1..* 1..*1..*
Avaliacaoanoavaliacao : Integersemestreavaliacao : Integeravaliacao1 : floatavaliacao2 : floatavaliacaofinal : floatfaltas : Integerresultadofinal : Integer
TurmaAlunosituacaoaluno : Integer
0..1
1
0..1
1
114
MVC:
115
REFERÊNCIAS BIBLIOGRÁFICAS
AMBLER, S. W. Mapping Objects To Relational Databases, out. 2000. Disponível em:
<http://www.ambysoft.com/mappingObjects.html>. Acesso em: 10 jun. 2005. AMBLER, S. W. The Design of a Robust Persistence Layer for Relational Databases,
Nov. 200. Disponível em: <http://www.ambysoft.com/persistenceLayer.html>. Acesso em: 10 jun. 2005.
ARAUJO, M. A. P. Notas de Aula – Análise de Sistemas II, 2005. ARAUJO, M. A. P. Apostila Programação em Delphi, 2004. CLUBEDELPHI, Revista Clube Delphi. Disponível em <http://www.clubedelphi.net>.
Acesso em: 29 nov. 2005. DAIBERT, M. S.; JULIO, A. M. O.; ARAÚJO, M. A. P. Persistência de objetos no Delphi:
Introdução ao DePO (Delphi Persistent Objects). Clube Delphi. Rio de Janeiro. N. 69. Dezembro 2005.
DEPO, Delphi Persistent Objects. Disponível em <http://www.liws.com.br/depo>. Acesso
em: 22 nov. 2005. DUNIT, DUnit. Disponível em <http://dunit.sourceforge.net>. Acesso em: 29 nov. 2005. ESLAM, Encontro de Software Livre do Amazonas. Disponível em <
http://eslam.comunidadesol.org>. Acesso em: 29 nov. 2005. FESTSOL, Festival de Software Livre de Juiz de Fora. Disponível em
<http://www.festsol.com.br>. Acesso em: 29 nov. 2005. IEEE, IEEE. Disponível em <http://www.ieee.org>. Acesso em: 29 nov. 2005. IO, Instant Obejcts. Disponível em <http://www.instantobjects.org/>. Acesso em: 22 nov.
2005. LEÃO, M. Borland Delphi 7 – Curso Completo. Rio de Janeiro: Axcel Books 2003. ISBN
85-7323-184-X. MVC, Model-View-Controler. Disponível em <http://ootips.org/mvc-pattern.html>. Acesso
em: 22 nov. 2005. NSN, NSN Project. Disponível em <http://www.nukescripts.net>. Acesso em: 22 nov. 2005. SATZINGER, J.; ORVIK, T. Object-Oriented Approach. USA: Course Technology, 1996. SHALLOWARY, A.,TROTT,J.; Explicando Padrões de Projeto Uma Nova Perspectiva em
Projeto Orientado a Objeto. São Paulo. Bookman, 2002.
116
SUBVERSION, SVN Subversion Project. Disponível em <http://subversion.tigris.org>. Acesso em: 22 nov. 2005.
TIOPF, TechInside Object Persistent Framework. Disponível em
<http://www.nukescripts.net>. Acesso em: 22 nov. 2005. UML, Unified Modeling Language. Disponível em <http://www.uml.org>. Acesso em: 29
nov. 2005. XML, Extensible Markup Language. Disponível em <http://www.w3.org/xml>. Acesso em:
22 nov. 2005.
117
BIBLIOGRAFIA
AMBLER, Scott W. Análise e Projeto Orientado a Objetos – Volume 2. São Paulo: IBPI
Press, 1998. BOOCH, Grady, RUMBAUGH, James, JACOBSON, Ivar. UML – Guia do Usuário. Rio de
Janeiro: Campus, 2000. D’SOUZA, D. F.; WILSS, A. C. Objects, components and frameworks with UML : the
catalysis approach. United States of America : Addison-Wesley, 1998. FAYAD, E. M.; SCHMIDT, D. C. Object-oriented application frameworks. New York. Oct.
1997. LEÃO, M.; HAMPSHIRE, P.; BOLONHA, J. C. Delphi 8 para plataforma .Net – Curso
Completo. Rio de Janeiro: Axcel Books 2004. ISBN 8573232315. HÜMMELGEN, M. Design patterns. Bate Byte, n. 89, p. 8-13, Ago. 1999. OMG. Object Management Group. Disponível em: <www.omg.org>. Acesso em: 22 nov.
2005. VLISSIDES, J. M. et al. Pattern languages of program design. Reading : Addison-Wesley,
1996.
