Numa altura em que imperam os ambientes gráficos amigáveis, as linguagens de programação são apelidadas de visuais, a Internet é o lugar da moda e tudo o que não seja "orientado para objectos" não tem utilidade, vê-mo-nos perante uma questão que parece esquecida mas que é muito importante: "Onde é que param as bases de dados orientadas a objectos? Se estes objectos informáticos existem em todo o mundo informático como é que são armazenados?
Neste trabalho iremos ver o que são sistemas de bases de dados orientadas para objectos (SGBDOO), onde se aplicam e alguns sistemas de gestão existentes para essas bases de dados.
Primeiro fazemos um resumo sobre o conceito e paradigmas de orientação para objectos. Seguidamente damos uma definição superfícial de bases de dados orientadas para objectos (BDOO) e explicamos a necessidade destas. Depois apresentamos modos de armazenar os objectos, como se defrontam os dois sistemas de gestão de bases de dados, o relacional e o orientado para objectos. A necessidade de queries numa BDOO. Por fim falamos do ODMG e alguns casos de SGBDOO em funcionamento em empresas de diversas áreas.
Conceitos sobre Orientação para Objectos
Um objecto é a representação informática o mais aproximada possível de um objecto real, que tem características que o distingue de outros objectos e pode ser manipulado através do seu "interface".
Informaticamente, podemos descrever um objecto como um conjunto de dados e dos métodos para manipular esses dados. Os objectos comunicam entre si através de mensagens que se transmitem usando os métodos do objecto com que se quer comunicar, e podem herdar características e métodos de outros objectos, quando for necessário.
Existem vários conceitos que devem ser relembrados:
Abstracção de dados (data abstraction): deixa de haver um conjunto de tipos de dados específicos e operações específicas para esses dados e passamos a ter dados genéricos e operações genéricas definidas no objecto.
Classe (class): é o esqueleto de um objecto em que se definem os tipos de dados e os métodos que agem sobre esses dados. Os objectos são instâncias de uma classe.
Classe abstracta (abstract class): Uma classe que não tem instâncias e sim subclasses que, por sua vez, podem ter instâncias.
Ocultar informação (information hidding): trata-se de ocultar os pormenores de implementação e da estrutura de um objecto. Assim, temos um meio de protecção e de restrição de acesso aos dados do objecto.
Encapsulamento (encapsulation): Este termo refere duas propriedades dos objectos: o facto dos dados e do código para o manipular formarem um objecto, e o facto dos clientes de um módulo deverem depender somente do interface do módulo, não necessitando de conhecer a estrutura interna do módulo para o utilizarem.
Hierarquia de classes (class hierarchy): Quando se derivam classes forma-se uma estrutura hierárquica em árvore, sendo a relação entre elas uma relação de especialização (superclasse, subclasse).
Herança (Inheritance): a herança entre classes permite que uma classe herde uma ou várias outras classes. Por seu lado, uma subclasse herda de uma ou mais superclasses os seus atributos e comportamento. As subclasses dizem-se especializações da superclasse pois estas adicionam outros atributos e comportamentos ao que herdam e, por vezes, alteram comportamentos herdados. As superclasses dizem-se generalizações das suas subclasses. Há uma característica importante da herança que reside no facto desta ser recursiva: uma classe herda de uma superclasse que herdou de outra superclasse, etc
Herança múltipla (Multiple Inheritance): é quando um objecto herda características de mais do que um objecto.
Polimorfismo (polymorphism): Quando se usa a mesma mensagem (método) para comunicar com vários objectos, mas cada um deles interpreta-a a seu modo.
Objecto composto (compound object): Objecto composto por um conjunto de objectos relacionados entre si.
Identificador do Objecto (Object Identifier- OID): Identificador unívoco de um objecto. Uma base de dados verdadeiramente orientada para objectos garante que o uso deste identificador seja transparente para os clientes. Mesmo que o objecto não esteja em memória, a base de dados encarrega-se de o carregar para a memória sem intervenção explícita do programa ou utilizador.
Metadata: Dados que descrevem dados. Os modelos são metadata visto que descrevem dados, relações e até modelos.
O que são Bases de Dados OO (OOBDMS)?
As bases de dados orientadas a objectos nasceram do casamento entre a programação orientada a objectos (OOP) e da tecnologia de bases de dados. Há duas componentes em causa por um lado a conceptualização do modelo de dados e, por outro, a programação do sistema da base de dados. Em ambas são utilizadas tecnologias orientadas a objectos; no caso da programação as duas linguagens mais utilizadas são o C++ e o Smalltalk. A figura seguinte ilustra aspectos da OOBDMS:
A necessidade de desagregar os objectos em tabelas para guardar os dados é também um factor importante para a criação de verdadeiras bases de dados orientadas para objectos. Bases de dados estas que guardam o objecto todo incluíndo o código dos seus métodos. Uma classe depois de programada é transportada para a base de dados tal como é, ao contrário do que sucede nas BDR em que o modelo de dados é disperso por tabelas.
As OODBMSs (Object Oriented Data Base Management System) são necessárias pelas razões que se referem de seguida.
Atingiu-se um nível de complexidade em, por exemplo, Computer Aided Design (CAD), Computer Aided Manufacturing (CAM), Computer Aided Software Engineering (CASE), sistemas periciais, aplicações científicas, automação de escritórios e fábricas onde é necessário manter informação variada de muitas componentes com muitas relações complexas e os meios de agir sobre elas. Nestes casos a gestão desta informação é mais fácil com OODBMS do que com DBMSs relacionais. Por "informação complexa" entende-se informação que vai além de estruturas de dados compostos por inteiros, strings e outros que tais.
A conceptualização é mais fácil pois a utilização de objectos permite às pessoas representarem de uma maneira mais natural a informação que querem guardar. Assim, melhora-se o entendimento (leia-se maior fluxo de comunicação) entre os utilizadores, designers e peritos.
As bases de dados orientadas a objectos permitem implementar as três componentes de um modelo de dados, que são:
Antes das OODBMS, apenas as duas primeiras componentes de um modelo de dados eram implementáveis na base de dados sendo as propriedades dinâmicas deixadas a cargo da aplicação. As OODBMS permitem implementar as 3 características na base de dados, o que vai permitir, por exemplo, aplicar regras uniformes a objectos sem que seja necessário desenvolver outra nova aplicação quando surge uma mudança no modo de agir sobre os dados.
Podem-se guardar os objectos em bases de dados relacionais (BDR). Isto pode-se fazer modelando a base de dados na aplicação, isto é, cada objecto encarrega-se de ler e escrever os dados na base de dados. Mas isto implica que se programe explicitamente estas funções nas classes, o que dá mais trabalho e os detalhes de implementação da base de dados ficam representados nas classes. É uma opção arriscada e não permite grandes alterações no esquema da base de dados.
Outra opção para guardar os objectos em BDRs é a de representar o modelo de objectos na base de dados ao contrário da primeira opção. Mas torna-se mais difícil ainda porque os dados de uma instância têm tendência a ficar espalhados por várias tabelas, a não ser que sejam muito simples e então o modelo relacional devia ter sido escolhido. Deste modo, é também impossível representar directamente características como a herança e o polimorfismo que são indispensáveis no modelo de objectos. Isto tem que ser implementado recorrendo a artifícios que complicam e tornam mais lenta a base de dados.
Estas soluções são complicadas e tornam-se difíceis de criar e manter. No entanto, há bases de dados que usam esta filosofia, às quais se dá o nome de object-relational. Existem alguns vendedores de SGBDs que usam esta filosofia com sucesso, mas nós achamos que se trata de uma forma de superar o facto de os SGBDOO ainda não estarem sólidos mas que não será a alternativa aos outros dois sistemas. E é mais um meio de migração do modelo relacional para o modelo de objectos do que um sistema próprio, porque tenta jogar com os dois e as diferenças entre eles são demasiado grandes para que esta mutação seja o terceiro SGBD. Como exemplo de uma empresa que usa este sistema, temos a AT&T que concebeu um modelo orientado para objectos para gestão do seu equipamento de rede mas já tinha os dados inventariados numa base de dados relacional. Tiveram que recorrer a um front-end object-relational que gera o código de acesso à BDR que eles já tinham; assim, eles concebem e programam uma BDOO e o front-end tem todo o trabalho de converter o código e gerir tudo para simular uma BDOO.
Uma verdadeira base de dados orientada para objectos (BDOO) armazena o objecto e o código do objecto, quando uma classe é derivada de outra é guardada com uma só chamada a uma função "store" e a BDOO é que gere as heranças, o polimorfismo, etc. o cliente limita-se a "usar" os objectos.
Como já se disse, o que impera na informática actual são os sistemas distribuídos, os interfaces gráficos, dados de tamanho incerto, dados e características que evoluem e se alteram ao longo do tempo, ambiente propício aos objectos.
Para armazenar os objectos os SGBDR não são suficientemente eficientes, da mesma maneira que a heterogeneidade de sistemas e a distribuição dos dados são um problema para os SGBDR e o seu formato tabular.
Talvez as bases de dados orientadas para objectos se devessem chamar bases de objectos e não bases de dados. Isto porque uma base de dados, no seu conceito tradicional, armazena dados. No entanto, um SGBDOO armazena não só os dados mas também toda a relação que existe entre eles e os meios para aceder ao(s) objecto(s). Armazena ainda a protecção do objecto (encapsulamento), fornece mecanismos de herança, objectos contentores de objectos, polimorfismo, a reutilização de objectos e muitos outros serviços que caracterizam a programação orientada para objectos.
Tal como os sistemas de gestão de bases de dados relacionais (SGBDR), os SGBDOO têm que garantir todas as implicações de uma base de dados mas, acrescidamente, têm que respeitar as linhas de orientação para objectos, sendo este o seu ponto mais forte. Um SGBDOO permite a reutilização dos objectos nele contidos para resolver outros problemas, a construção de objectos complexos compostos por outros objectos e até objectos que são somente uma colecção de um certo tipo de objectos. Permitem ainda, num ambiente distribuído, a heterogeneidade de servidores de objectos e a movimentação de objectos de um servidor para outro de forma transparente para o utilizador e para os outros objectos da BD. O tempo de desenvolvimento é mais curto, a manutenção é mais baixa, dado que cada problema pode ser resolvido localmente. Isto é; se é preciso alterar ou acrescentar alguma funcionalidade, basta trabalhar no objecto ou conjunto de objectos em questão, sem sequer ter que se parar o funcionamento da base de dados. Quando o problema está resolvido, é só substituir o(s) objecto(s) em questão e o sistema não parou de funcionar.
Outra das grandes diferenças entre BDOOs e BDRs é o modo de identificar univocamente os dados. As BDOOs usam o OID, gerado pelo SGBDOO que se mantém constante após execuções de aplicações que acedem/alteram a base de dados. Esta característica é diferente das bases de dados relacionais em que os tuplos são identificados por chaves, ou seja, são identificados por um valor (value-based) que é guardado no próprio tuplo. O uso de OIDs permite um controlo mais fácil sobre o armazenamento de objectos e ajuda a estabelecer ligações entre objectos. Um sistema de gestão de base de dados deve assegurar a integridade dos OIDs, em especial, quando um objecto é apagado todas as referências ao seu OID devem ser apagadas para que não haja conflitos de entidade quando o OID é reutilizado e para que um outro objecto não contenha referências inválidas.
Tal como os SGBDR, os SGBDOO devem ser tolerantes a falhas. A nossa opinião é que será mais fácil para um SGBDOO recuperar uma falha porque o SGBDR tem que recorrer a várias tabelas para verificação de integridades e para eventuais recuperações de uma falha. Ao passo que o SGBDOO trabalha ao nível do objecto que já tem um certo nível de auto-protecção o que nos parece simplificar a recuperação de uma falha. No entanto, não encontrámos grandes referências a este tema sendo as implicações e as soluções muito semelhantes às de um sistema relacional.
No que diz respeito a sistemas cliente/servidor, os objectos são um modelo de sistemas cliente/servidor. Um objecto quando comunica com outro faz o papel de cliente, e o objecto que recebe a comunicação é um servidor. Sendo assim, as limitações são ao nível das comunicações físicas porque o objecto pode até comunicar com outro objecto num ambiente diferente, mas seguindo a filosofia de objectos, o que interessa é que a classe, por exemplo, Aluno tem um método Media que devolve um número entre 0 e 20 e qualquer objecto que queira saber a média de um objecto desta classe sabe que usando este método sabe a média do aluno. Isto independentemente do modo como esta é calculada. Deste modo, um sistema distribuído como o da figura abaixo é muito simples de implementar do ponto de vista de um programador de uma BDOO. Sendo da competência do SGBDOO a transparência, tolerância a falhas e todas as implicações de um sistema distribuído.
As bases de dados orientadas para objectos (BDOO) servem muito bem para conjuntos de dados complexos que evoluem com o tempo, para modelos com muitas relações entre os objectos e para informação de tamanho indeterminado como imagens e som. As bases de dados relacionais (BDR), por seu lado, prestam-se melhor para dados que possam ser representados de forma tabular, que não tenham relações complexas e que sejam de tamanho pré-determinado. Assim, para aplicações deste tipo é muito natural que as BDOO tenham um desempenho semelhante ou até mais fraco que as BDR.
As BDOO ainda não atingiram a estabilidade e ainda estão numa fase em que o "standard" é estabelecido por um consórcio de construtores de SGBDOO: o Object Database Management Group (ODMG). Em relação à adopção ou não desse standard, é ao construtor que cabe a decisão. No entanto, as BDR já estão muito difundidas e são mais fiáveis por já existirem há mais tempo, e têm assim uma posição bem marcada tanto no mercado como nos métodos de análise e desenvolvimento pelos profissionais da área de bases de dados.
Cabe assim ao cliente decidir qual dos sistemas se aplica melhor ao seu caso visto que cada um é mais eficiente que o outro na sua área e, apesar de estarem pouco difundidos, os SGBDOO existentes são bastante eficientes e fiáveis.
Haverá necessidade de uma linguagem de query numa BDOO?
Numa base de dados com grande quantidade de informação e muitos utilizadores, um sistema de query produz o tipo de dados de que geralmente se necessita como listagens e relatórios. Isto juntando ao facto dos utilizadores não necessitarem de ter de aprender linguagens de objectos, faz com que estes possam usar a linguagem de query que permite de uma forma de mais alto nível produzir resultados através da BD.
Mas, como é óbvio, terão que haver funcionalidades acrescidas àquelas que já conhecemos do SQL para permitir usar todas as capacidades dos objectos. A ODMG designou como Object query language (OQL) à sua especificação de uma linguagem que é compatível com o SELECT do SQL, mas que acrescenta query para colecções de objectos (funções como set, list, bag, array).
A comissão ANSI X3H2 que produziu o SQL actual está a trabalhar no SQL3 que já irá incluir funcionalidades destinadas a objectos, estando estas a ser desenvolvidas com o apoio da ODMG para que se produza uma só linguagem standard.
Object Database Management Group (ODMG)
O ODMG é um consórcio de vários vendedores de bases de dados. Este consórcio surge porque as instituições já conhecidas como a ISO e a ANSI ainda não estabeleceram as normas referentes às BDOOs. Mas, como já existem várias implementações e como é necessário garantir uniformidade para que não haja grandes disparidades no modo como as BDOO são tratadas e implementadas e principalmente, para proteger os utilizadores, foi criado o ODMG que publicou um standard.
O primeiro documento lançado é o ODMG-93 que descreve as seguintes funcionalidades básicas que um SGBDOO deve ter:
Ainda não inclui versões, transacções longas, acesso a meta-data que será considerado na próxima versão.
Descreve ainda os seguintes modelos:
Irá sair a versão 2.0 em 1997 mas não sabemos quais são as alterações. Pensamos que, pelo menos, as características que referimos acima como não incluídas serão algumas das novas características.
Não tratamos aqui do OMG porque tanto quanto conseguimos saber as normas por eles criadas para BDOO são limitadas, sendo também esta uma das razões do aparecimento do ODMG.
Os produtos comerciais de SGBDOO são variados apesar da aplicação da tecnologia orientada para objectos nas bases de dados ser recente. Uma análise a produtos de sistema de gestão de bases de dados orientadas para objectos inclui os seguintes aspectos: funcionalidade, facilidade de uso, plataformas suportadas e performance. De seguida, identificam-se as características de funcionalidade e de facilidade de uso que a maioria dos produtos presentemente no mercado possuem e descrevem-se algumas das características de funcionalidade. No fim identificam-se empresas que desenvolvem SGBDOO, os seus produtos e apresentam-se aplicações já desenvolvidas.
Funcionalidade é um grupo de características que engloba características base que se enquadram dentro de qualquer produto que seja baseado numa tecnologia orientada a objectos. Os produtos em regra geral têm suporte para:
Objectos Complexos, OIDs (Object Identifiers), Classes, Atributos, Métodos (Behaviours), Encapsulamento, Herança, Overriding Behaviours and Late Binding, Persistência e Naming.
Overriding Behaviours e Late Binding- o primeiro é a capacidade que as classes têm em redefinir um método herdado para as suas características. Late Binding é a capacidade de seleccionar o método em runtime com base no tipo de objecto.
Persistência- persistência é a característica que faz com que os dados estejam disponíveis durante várias execuções, aliás, um objectivo do sistema de gestão da base de dados é que os objectos sejam persistentes.
Naming- mecanismo pelo qual o SGBD identifica um ou mais objectos na fase de arranque para depois conseguir aceder aos outros objectos através das relações que estes têm com os que são carregados na fase de arranque.
Um outro grupo de características comuns em produtos com alguma maturidade são:
Integridade referencial e relacional (Relationships and Referential Integrity), Objectos Compostos (Composite Objects), Transparência de localização, Múltiplas versões de objectos (Object Versioning), Suporte para trabalho em grupo (Work Group), Evolução de esquema do modelo de dados (Schema Evolution), Acesso/Definição/Modificação em runtime do esquema, Integração com outras BDs e Aplicações, Sistema de Gestão de Objectos passivo ou activo.
Integridade referencial e relacional- para manter integridade de referência é necessário que quando se apaga um objecto todas as referências a este sejam removidas. O problema surge quando há objectos a que não se tem acesso através do objecto a retirar, isto é, objectos que têm relações unárias com este. Uma das maneiras de lidar com o problema, a nível da aplicação, é manter listas de dependências existentes entre objectos. No entanto, esta solução piora a performance do SGBD. Uma outra maneira de contornar o problema é não reutilizar os OIDs e colocar uma pedra sobre um objecto que seja removido de maneira a que quando é feita uma referência a este objecto ou resulta num erro ou é ignorado, e a referência é apagada. Há ainda outra maneira que é manter uma lista com o número de referências para cada objecto que é utilizada para indicar se se pode remover o objecto, isto é, quando e só quando este tiver 0 referências é que é retirado.
A maneira como um SGBD acede a objectos (implementa as relações) é um dos factores que distingue os diferentes sistemas. As relações entre objectos são representados por referências que por sua vez são representados por OIDs em disco e em memória. Estes podem continuar como OIDs ou ser swizzled para a memória, como diz Catell. Swizzling não é nada mais que o processo de transformação de referências entre objectos para ponteiros em memória, isto para os objectos que se encontram em memória. O swizzling pode ser feito quando é feito um pedido ou quando o objecto é colocado em memória. A razão pela qual se faz swizzling é porque se obtém uma melhoria de performance quando são feitas muitas referências às relações em memória em comparação com o manter e aceder às relações em disco quando se percorre pelos objectos. Isso é o que fazem os SGBD que não implementam swizzling, tendo que aceder aos OIDs das relações em disco quando se percorre a rede de objectos da base de dados (este processo torna-se eficiente com o uso de tabelas- lookup tables). É importante referir que também há soluções híbridas. A escolha da solução depende do tipo de acesso que se faz à base de dados.
Transparência de localização- quando se acede a um objecto sem se saber em que base de dados é que este se encontra ou em que rede se encontra a base de dados.
Integração com outras BD- A integração com bases de dados relacionais é importante pois os SGBDOO sendo novos têm que aceder a estas bases de dados. Um método pelo qual isto se pode realizar é fazer o mapeamento do esquema da base de dados para um modelo de objectos, representar cada relação com classes, substituir chaves estrangeiras do esquema relacional em relações (no esquema OO).
Em relação à arquitectura da base de dados temos as seguintes componentes:
Cliente Servidor Distribuída, Mecanismo de Acesso, Clustering de Objectos, Operações Heterogéneas (Heterogeneous Operation).
Sistema de Gestão de Objectos passivo ou activo- Esta característica define se um SGBDOO armazena (activo) ou não (passivo) o código dos métodos na BD. No passivo, a aplicação corre uma imagem do código do método do objecto, sendo o objecto transportado da BD para o cliente durante a execução. No caso do activo o código está guardado na BD e é executado no servidor. A grande diferença torna-se visível numa BD com muitos objectos, porque no SGBDOO activo não é necessário importar todos os objectos para os clientes, enquanto que no SGBOO passivo cada cliente tem uma cópia dos objectos que está a usar.
Em termos de funções que a base de dados permite temos:
Acesso a um número de dados ilimitado, integridade, concorrência, recuperação, transacções, detecção de deadlock, bloqueamento, backup and restore, dump and load, constraints, notification model, indexing, storage reclamation e segurança.
Developer's View of Persistence, Application Development Process, Application Development Tools, Database Administration Tools, Database Design Tools, Source Processing Tools, Database Browsing Tools, Debugging Support, Performance Tuning Tools e Class Library.
Alguns dos produtos/empresas do mercado são:
GemStone, IDB, Illustra, ITASCA, MATISSE, O2, ObjectStore, Objectivity/DB, Odapter, ODB-II, ODBMG, Omniscience, Ontos DB, OSMOS, Persistence, Poet, UniSQL e Versant. A figura abaixo apresenta os dois extremos em SGBD e alguns produtos na respectiva área.
A maioria destes produtos são baseados numa arquitectura cliente/servidor. Por exemplo, o Gemstone 5.0 é um servidor disponível em várias plataformas que gere OOBDs em ambientes distribuídos e heterogéneos. Este servidor possui a maioria das características mencionadas em cima: persistência de objectos, integridade relacional, múltiplas caches de objectos partilhadas, queries, evolução dinâmica dos esquemas, três tipos de concorrência, locks, etc. Além disso, o GemStone através do GemConnect providencia mecanismos de integração de sistemas de gestão de bases de dados relacionais. Aliás muitos produtos estabelecem uma ponte entre os OODBMSs e RDBMSs, por exemplo, o ONTOS OIS (object integration server) permite a um utilizador pegar num esquema de base de dados relacional e transformá-lo num orientado a objectos através do mapeamento de entidades, atributos e relações, tendo em conta a integridade relacional e hierarquias. Tal como a Oracle (Power Objects), estas empresas fornecem produtos com GUI para ajudar na construção de clientes, normalmente em C++, SmallTalk e Java.
Casos práticos de utilização de produtos:
Por exemplo, o produto da Objectivity, o Objectivity/DB, é utilizado em áreas variadas como engenharia de software, gestão de sistemas de telecomunicações, pesquisa científica e controlo de processos. Apesar de não ser objectivo deste relatório fazer marketing do produto, é de notar que este produto é utilizado por muitas empresas de renome mundial (por exemplo, Adobe Systems, BBN Systems and Technologies, Boeing, Canon, DEC, Motorola, Siemens AG). Na área de engenharia de software, o OODBMS da Objectivity é muito utilizado para criar bases de dados de documentação multimédia (nomeadamente tutoriais e apresentações de produtos). Na área das telecomunicações é aplicado na gestão em tempo real de redes. Por exemplo, uma empresa criou uma aplicação para monitorizar falhas, gerir, e reparar redes, um dos pontos focados é que os utilizadores (peritos em telecomunicações) tiveram facilidade em perceber o esquema de objectos que representava directamente os seus objectos complexos que têm muitas interconecções. Outros aspectos focados é a escalabilidade e a segurança que o Objectivity/DB permite. Na área de controlo de processos as bases de dados são utilizadas quer para manter informação sobre componentes que actuam nos processos, quer para manter um historial de dados, quer para participar no controlo em realtime dos processos. Nesta medida, além do papel convencional da base de dados, este sistema monitoriza vários inputs (temperatura, pressão, etc) para actuar sobre controlos (válvulas, etc.). Para suportar este tipo de aplicação a base de dados tem um sistema de gestão distribuído em que as aplicações (programas) comunicam de uma forma transparente com todos os componentes envolvidos no processo. Outra área em que o Objectivity/DB utilizado é a da Ciência, por exemplo, o CERN está a criar um sistema para guardar dados em tempo real de experiências de física de partículas nucleares. Esta base de dados que terá um grande volume de dados (vários petabytes) é um caso típico entre as várias organizações que fazem pesquisa e utilizam o Objectivity/DB, em que além de servirem para armazenar um grande volume de dados, os SGBDOO servem para partilhar e distribuir os dados entre os investigadores.
| Comentários, críticas, sugestões, etc.: elson@student.dei.uc.pt |
Última Actualização: 29/10/1997 |