Descrição Geral | |
Metas | |
Prazos | |
Registro das Equipes |
Biblioteca
e um objeto
BibAdmin
. Interagindo com o primeiro desses objetos, os
usuários terão acesso a serviços rotineiros da biblioteca: consultas,
empréstimos e devoluções. Interagindo com o segundo, o pessoal da
biblioteca efetuará operações administrativas: cadastramento de um novo
livro, adicão de mais exemplares de um livro ao acervo da biblioteca,
etc.
Além dos objetos Biblioteca
e BibAdmin
, o
servidor implementará uma coleção de objetos Livro
. A cada
Livro
, por sua vez, estará associada uma coleção de objetos
ExemplarDeLivro
. Podemos pensar que um objeto
Biblioteca
possui um conjunto de Livro
s, e que
cada Livro
possiu um conjunto de objetos
ExemplarDeLivro
. Quaisquer alterações nesses conjuntos,
entretanto, tem de ser efetuadas através do objeto
BibAdmin
.
A funcionalidade de nosso sistema de informatização de bibliotecas irá crescendo ao longo do semestre.
Etapa 1: servidores isolados, objetos não persistentes
Os servidores que gerenciam as várias bibliotecas não se comunicam uns com os outros. Cada biblioteca fica portanto isolada das demais. Além disso, os objetos implementados pelos servidores não são persistentes. Isto significa que todas as informações mantidas por um servidor se perderão quando o servidor parar de rodar.
Nesta etapa você usará este arquivo,
que contém uma primeira versão das definições (em IDL) das interfaces
|
Etapa 2: servidores isolados, objetos persistentes
Agora o estado de cada objeto é mantido em disco. A queda de um servidor não mais implica a "destruição virtual" do acervo de sua biblioteca. O acervo de uma biblioteca pode ser grande a ponto de não caber mais na memória do servidor. Nesta etapa aproveitaremos também para refinar as definições das interfaces entre o servidor e seus clientes. Será publicada aqui uma segunda versão do arquivo IDL contendo essas definições.
|
Etapa 3: servidores interligados, objetos persistentes
Os servidores das várias bibliotecas deixam de ser isolados. O usuário que roda um programa cliente e se conecta ao servidor de uma biblioteca B (possivelmente a mais próxima da sua casa) tem acesso não só ao acervo da biblioteca B, mas também aos acervos das demais bibliotecas. A idéia é fazer isso com um mínimo de alterações no programa cliente. Mesmo estando conectado ao servidor da biblioteca mais próxima, o cliente verá uma "biblioteca virtual", cujo acervo é a união dos acervos de todas as bibliotecas da cidade. Ou do estado. É desejável que o cliente possa especificar o "alcance" da biblioteca virtual. Para atender a uma consulta de um cliente, o servidor da biblioteca B poderá fazer consultas a servidores de outras bibliotecas. Nesse caso o processo servidor da biblioteca B assumirá o duplo papel de servidor (perante o seu cliente) e de cliente (perante os servidores das outras bibliotecas). Note que o cliente e os servidores envolvidos podem ter sido escritos por diferentes equipes de projeto! Mais detalhes, incluindo a versão do arquivo IDL que você utilizará nesta etapa, serão publicados aqui.
|
O Servidor
Em cada etapa o programa servidor implementará as interfaces definidas no arquivo IDL fornecido pelo professor especificamente para essa etapa. Escreva-o tendo em mente que poderão ocorrer várias execuções simultâneas do mesmo programa servidor. Cada "processo servidor" (uma execucão do programa servidor) corresponde a uma biblioteca. Portanto o programa servidor precisa receber como argumentos os parâmetros que variam de uma biblioteca para outra. Na primeira etapa, esses parâmetros devem especificar os nomes dos "objetos principais" do servidor, além do nome, cidade e estado da biblioteca. Para não ter que passar ao seu programa servidor uma longa lista de argumentos na linha de comando, você pode passar na linha de comando o nome de um arquivo contendo as definições dos parâmetros específicos de uma biblioteca.
|
O(s) Cliente(s)
Os programas clientes serão usados para exercitar o sistema. Fica a
critério de cada equipe decidir se escreve dois clientes, um para os
serviços rotineiros (cliente da
|
Etapa 1: 28 de setembro | |
Etapa 2: 12 de novembro | |
Etapa 3: 07 de dezembro |
Ao final da terceira etapa as equipes de projeto farão uma demonstração do funcionamento de seus sistemas.
Equipes registradas:
|