Alternativas para A Interoperabilidade Entre Sistemas de Informacao Universitarios

FACULDADE DE E NGENHARIA DA U NIVERSIDADE DO P ORTO
Alternativas para a Interoperabilidade entre o Universit Sistemas de Informac a arios

S ergio Sobral Nunes o pela Licenciado em Engenharia Inform atica e Computac a Faculdade de Engenharia da Universidade do Porto
o submetida para satisfac o parcial dos Dissertac a a requisitos do grau de mestre em o Gest ao de Informac a
o realizada sob a supervis Dissertac a ao do Professor Doutor Gabriel David, do Departamento de Engenharia Electrot ecnica e de Computadores da Faculdade de Engenharia da Universidade do Porto
Porto, Julho de 2004
Resumo o s es acOs sistemas de informac a ao pec as centrais e incontorn aveis nas organizac o es acad reas t tuais. Nas instituic o emicas, podem ser encontrados em a ao diversas como o, o apoio a ` actividade lectiva ou a gest a gest ao nanceira da organizac a ao de recursos humanos. o das tecnologias e infraestruturas associadas a ` s redes de computadores A evoluc a ` s organizac es. Os sistemas centralizados t veio colocar novos desaos a o em sido progres o distribu sivamente substitu dos por sistemas de informac a dos, compostos por m ultiplos computadores ligados em rede. Por outro lado, de um ponto de vista organizacional, h a o consolidada e agregada, proveniente uma crescente necessidade de aceder a informac a es acad de diferentes fontes. No caso particular das instituic o emicas, caracterizadas pela exist encia de m ultiplos centros de poder, esta quest ao assume uma maior preponder ancia. o de Assim, devido a factores de ndole tecnol ogica e organizacional, a integrac a o constitui um dos mais importantes desaos actuais. Nesta dissertac o, procedeinformac a a o das principais alternativas para a interoperabilidade entre se a um estudo e a uma avaliac a o universit sistemas de informac a arios. abordado o conceito de Sistema de Informac o Universit Numa primeira fase, e a ario e, feita uma breve caracterizac o desatrav es da an alise das funcionalidades mais comuns, e a tes sistemas. Aprofunda-se depois o conceito de interoperabilidade, atribuindo-se maior feita uma revis ` vertente tecnol es destaque a ogica. E ao das principais tecnologias e soluc o ` construc o de sistemas de informac o distribu associadas a a a dos. apresentado o problema concreto de interoperabilidade entre sistemas Em seguida, e o universit de informac a arios, tendo subjacente como caso de estudo o cen ario da Uni feita uma avaliac o dos padr o mais comuns e versidade do Porto. E a oes de interacc a estruturado em dois eixos: horizontal e vertical. Com base na descric o o problema e a o destes eixos, s o: partilha, e caracterizac a ao identicados quatro padr oes de interacc a o, concentrac o e difus o. Cada um destes padr agregac a a ao de informac a oes d a origem a descrito e sistematizado com a compilac o de requisium caso de estudo concreto, que e a tos detalhados. Prop oem-se quatro arquitecturas distintas para cada um dos padr oes gen ericos. De es tomadas, e feita uma breve contextualizac o pois de descritas e justicadas as opc o a o duma para cada caso de estudo particular. Este trabalho teve como resultado a produc a o de soluc es concretas para a representac o dos dados e para a implementac o especicac a o a a o. dos mecanismos de interacc a No nal, foram implementados v arios prot otipos que permitiram validar, numa pri es propostas. meira fase e informalmente, as soluc o
Abstract Information systems are fundamental pieces in todays organizations. In academic institutions, they can be found in areas as diverse as nancial management of the organization, lecture support or human resources management. The evolution of technologies and infrastructures in the eld of computer networks has brought new challenges to the organizations. Centralized systems are being replaced by distributed ones, built on top of multiple connected computers. On the other hand, from an organizational point of view, there is a greater need to access consolidated and aggregated information produced by different sources. In the case of academic institutions, where multiple power centers exist, this is a bigger issue. Thus, due to technological and organizational issues, information integration is one of the most important current challenges. In this dissertation, a study and evaluation of the major alternatives for the interoperability between university information systems is conducted. First, the concept of University Information System is presented. A brief characterization of these systems is made based on the analyses of the most common features. Then, the concept of interoperability is detailed, with a focus on the technological aspects. The major technologies and solutions related to distributed systems are reviewed here. Following this, the problem of interoperability between university information systems is presented having as an example the concrete case of the Porto University. An evaluation of the more common interaction patterns is made and the problem is structured in two axis: horizontal and vertical. Based on the description and characterization of these axis, four patterns are identied: share, aggregation, concentration and diffusion of information. Each of these patterns results in a study case, which is described and systematized with the compilation of detailed requirements. Four distinct architectures are proposed for each of the generic patterns. After being described and justied the options, a brief contextualization is made for each particular case. This work resulted in the specication of concrete solutions for the representation of data and the implementation of interaction mechanisms. In the end, several prototypes were implemented that allowed to validate the proposed solutions.
Entities should not be multiplied beyond necessity, William of Ockahm (1285-1347/49)
Agradecimentos
o com que acompanhou o trabaAo professor Gabriel David por todo o apoio e dedicac a lho. ` Carla e a ` minha m A ae pelo apoio, pela disponibilidade constante e pelas cr ticas construtivas que foram tecendo sobre o meu trabalho. Ao meu pai, aos meus irm aos, aos meus av os e ao Manuel pelo incentivo. Aos meus amigos tamb em pelo incentivo e, muito em particular, por toda a paci encia demonstrada durante este (longo) per odo.
10
Sum ario
1 o Introduc a o . . . . . . . . . . . . . . . . . . . . . . . . 1.1 Enquadramento e Motivac a o da Dissertac o . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Organizac a a o Universit Sistemas de Informac a arios es Universit 2.1 As Organizac o arias . . . . . . . . . . . . o nas Universidades . . . . 2.2 Os Sistemas de Informac a 2.3 Funcionalidades dos SIU . . . . . . . . . . . . . . . o . . . . . . . . . . . . . . . . . 2.4 Troca de Informac a o . . . . . . . . . . . . . . . . . . . 2.4.1 Denic a 2.4.2 Iniciativas Existentes no Contexto Acad emico ` Interoperabilidade Tecnologias de Apoio a 3.1 N veis de Interoperabilidade . . . . . . 3.2 Arquitecturas Distribu das . . . . . . . o . . . . . . . . 3.3 Modelos de Programac a 3.4 Sincronismo . . . . . . . . . . . . . . . o S 3.4.1 Interacc a ncrona . . . . . . . o Ass 3.4.2 Interacc a ncrona . . . . . o dos Dados . . . . . . . . . . 3.5 Colocac a o . . . . . . 3.5.1 Mover a Interrogac a 3.5.2 Mover os Dados . . . . . . . . o H 3.5.3 Soluc a brida . . . . . . . . 3.6 Consist encia dos Dados . . . . . . . . . 3.6.1 Protocolos . . . . . . . . . . . o . . . . . . . . . . . 3.6.2 Propagac a 3.6.3 Iniciativa . . . . . . . . . . . . 3.7 Entrega dos Dados . . . . . . . . . . . 3.7.1 Protocolos . . . . . . . . . . . 3.7.2 Frequ encia . . . . . . . . . . . 3.7.3 Modos . . . . . . . . . . . . . o dos Esquemas . . 3.7.4 Classicac a 3.8 Revis ao das Tecnologias . . . . . . . . 3.8.1 EDI . . . . . . . . . . . . . . . 3.8.2 Componentes . . . . . . . . . . 3.8.3 Servic os Web . . . . . . . . . . 11 19 20 20 23 24 25 26 30 30 31 37 38 39 40 41 41 42 42 42 43 43 44 44 45 46 47 48 48 48 48 48 49 50 51
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
12 4 o do Problema Denic a o do Contexto . . . . . . . . . . . . . . . . . . . . . 4.1 Apresentac a 4.2 Eixos de Interoperabilidade . . . . . . . . . . . . . . . . . . . . . 4.2.1 Interoperabilidade Horizontal . . . . . . . . . . . . . . . 4.2.2 Interoperabilidade Vertical . . . . . . . . . . . . . . . . . o de Casos de Estudo . . . . . . . . . . . . . . . . . . . . 4.3 Selecc a 4.3.1 Requisitos Comuns . . . . . . . . . . . . . . . . . . . . . 4.3.2 Partilha do Registo Acad emico do Aluno . . . . . . . . . o de Estat 4.3.3 Agregac a sticas sobre os Cursos . . . . . . . . . o de Informac o sobre os Recursos Humanos 4.3.4 Concentrac a a 4.3.5 Difus ao de Not cias da Universidade . . . . . . . . . . . . Arquitectura 5.1 Interoperabilidade Horizontal . . . . 5.2 Interoperabilidade Vertical . . . . . o de Informac o . 5.2.1 Agregac a a o de Informac o 5.2.2 Concentrac a a o . . . 5.2.3 Difus ao de Informac a
SUMARIO 53 54 54 55 55 56 56 59 65 67 69 73 74 75 76 79 80 83 84 84 84 85 85 85 86 86 86 86 87 95 97 97 98 101 102 102 102 103 105 105 106 108 110
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
o Implementac a es Tecnol 6.1 Opc o ogicas . . . . . . . . . . . . . . . . . . . . . . . 6.1.1 XML Schema . . . . . . . . . . . . . . . . . . . . . . . 6.1.2 Servic os Web . . . . . . . . . . . . . . . . . . . . . . . es T 6.2 Convenc o ecnicas . . . . . . . . . . . . . . . . . . . . . . . 6.2.1 Idioma . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2.2 Nomenclaturas . . . . . . . . . . . . . . . . . . . . . . o . . . . . . . . . . . . . . . . . . . . . . . . 6.2.3 Codicac a 6.2.4 Uso de Elementos ou Atributos . . . . . . . . . . . . . 6.3 Partilha do Registo Acad emico do Aluno . . . . . . . . . . . . . 6.3.1 Identicador do Registo Acad emico do Aluno . . . . . . o do Registo Acad 6.3.2 Representac a emico do Aluno . . . . . o do Sistema . . . . . . . . . . . . . . . . . 6.3.3 Especicac a o de Estat 6.4 Agregac a sticas sobre os Cursos . . . . . . . . . . . . 6.4.1 Identicador do Curso . . . . . . . . . . . . . . . . . . o de Estat 6.4.2 Representac a sticas sobre o Curso . . . . . . . o do Sistema . . . . . . . . . . . . . . . . . 6.4.3 Especicac a o de Informac o sobre Recursos Humanos . . . . . 6.5 Concentrac a a 6.5.1 Identicador do Recurso Humano . . . . . . . . . . . . o de Informac o sobre Recursos Humanos 6.5.2 Representac a a o do Sistema . . . . . . . . . . . . . . . . . 6.5.3 Especicac a 6.6 Difus ao de Not cias da Universidade . . . . . . . . . . . . . . . 6.6.1 Identicador da Not cia . . . . . . . . . . . . . . . . . . o de Not 6.6.2 Representac a cias . . . . . . . . . . . . . . . . o do Sistema . . . . . . . . . . . . . . . . . 6.6.3 Especicac a 6.7 Prot otipos . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . .
SUMARIO 7
13
Conclus oes 111 7.1 Conclus oes Gerais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 7.2 Perspectivas de Trabalho Futuro . . . . . . . . . . . . . . . . . . . . . . 113
A Estrutura da Base de Dados e Lista de Funcionalidades 123 o . . . . . . . . . . . . . . . . . . . . . . . . . 123 A.1 Modelo Entidade-Relac a A.2 Lista de Funcionalidades . . . . . . . . . . . . . . . . . . . . . . . . . . 123 o do Registo Acad B Especicac a emico do Aluno 131 o do Elemento StudentRecord . . . . . . . . . . . . . . 131 B.1 Especicac a o de Estat C Agregac a sticas sobre Cursos 147 o do Elemento DegreeStatistics . . . . . . . . . . . . 147 C.1 Especicac a o de Informac o sobre Recursos Humanos D Concentrac a a 153 o do Elemento StaffRecord . . . . . . . . . . . . . . . . 153 D.1 Especicac a E Difus ao de Not cias da Universidade 161 o do Elemento NewsItem . . . . . . . . . . . . . . . . . . 161 E.1 Especicac a
14
SUMARIO
Lista de Figuras
2.1 3.1 3.2 3.3 As Hierarquias Paralelas na Burocracia Prossional . . . . . . . . . . . . 24 40 41 43 44 45 46 49 49 50 52 54 76 82 88 88 89 90 92 94 95 97 99 100 101 101 102 103 105
Arquitecturas Distribu das: C/S, P2P e S/C . . . . . . . . . . . . . . . . Sincronismo entre Sistemas Distribu dos: S ncrono e Ass ncrono . . . . . o dos Dados: Envio da Interrogac o, Envio dos Dados e Soluc o Colocac a a a H brida . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o L o F 3.4 Representac a ogica e Representac a sica . . . . . . . . . . . . . . . o de Dados . . . . . . . . . . . . . . . . . . . . . 3.5 Protocolos de Replicac a o S o Ass 3.6 Propagac a ncrona e Propagac a ncrona . . . . . . . . . . . . . . 3.7 Esquemas de Entrega dos Dados . . . . . . . . . . . . . . . . . . . . . . 3.8 Arquitectura EDI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.9 Arquitectura baseada em Componentes . . . . . . . . . . . . . . . . . . . 3.10 Arquitectura baseada em Servic os Web . . . . . . . . . . . . . . . . . . . 4.1 5.1 5.2 6.1 6.2 6.3 6.4 6.5 6.6 6.7 6.8 6.9 6.10 6.11 6.12 Interoperabilidade Vertical e Horizontal . . . . . . . . . . . . . . . . . . o de Informac o . . . . . . . . . . . . . . . . . . . . . . . . . . Agregac a a o - Instituic es da Universidade e P Difus ao de Informac a o ublico em Geral
Elemento StudentRecord . . . . . . . . . . . . . . . . . . . . . . . . Elemento DocumentInfoType . . . . . . . . . . . . . . . . . . . . . Elemento StudentType . . . . . . . . . . . . . . . . . . . . . . . . . Elemento PersonType . . . . . . . . . . . . . . . . . . . . . . . . . . Elementos AcademicDegreeType e DegreeType . . . . . . . . . . Elementos AcademicSessionType e CourseType . . . . . . . . . o sobre Alunos . Diagrama de Componentes para a Partilha de Informac a o sobre Alunos . Diagrama de Componentes para a Partilha de Informac a Elemento DegreeStatisticsType . . . . . . . . . . . . . . . . . . Elemento PersonsByEnrollmentsByCurricularPeriodType Elemento PersonsByFinalGradeValueType . . . . . . . . . . . . o de Informac o Estat Diagrama de Componentes para a Agregac a a stica sobre Cursos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o de Informac o Estat 6.13 Diagrama de Sequ encia para a Agregac a a stica sobre Cursos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.14 Elemento StaffRecord . . . . . . . . . . . . . . . . . . . . . . . . . o de Informac o sobre Recur6.15 Diagrama de Sequ encia para a Concentrac a a sos Humanos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
16 6.16 6.17 6.18 6.19 6.20
LISTA DE FIGURAS Elemento NewsItem . . . . . . . . . . . . . . . . . . . . . . . . . . . Diagrama de Componentes para a Difus ao de Not cias da Universidade Diagrama de Sequ encia para a Difus ao Controlada de Not cias . . . . . Diagrama de Sequ encia para a Difus ao P ublica de Not cias . . . . . . . ` representac o de informac o . . . . Arquitectura do prot otipo relativo a a a . . . . . 107 108 109 109 110
o . . . . . . . . . . . . . . . . . . . . . . . . . 123 A.1 Modelo Entidade-Relac a
Lista de Tabelas
2.1 2.2 2.3 2.4 o Universit Sistemas de Informac a arios avaliados . . . . . . . . N umero de funcionalidades por categoria . . . . . . . . . . . . N umero de funcionalidades por grupo e palavra-chave . . . . . Exemplo de funcionalidades mais comuns nos sistemas avaliados . . . . . . . . . . . . . . . . . . . . 27 28 29 29
17
18
LISTA DE TABELAS
Cap tulo 1 o Introduc a

es Neste cap tulo, depois de um breve enquadramento, s ao referidas as principais motivac o ` realizac o deste trabalho. No nal, e apresentada a estrutura e organizac o associadas a a a do texto.
19
20
CAPITULO 1. INTRODUC AO
1.1
o Enquadramento e Motivac a
O crescimento explosivo da capacidade de processamento dos computadores e, mais re o nos sistemas de centemente, das redes de computadores, est a na base de uma revoluc a o empresariais. Os sistemas centralizados (ou monol informac a ticos) foram substitu dos o distribu por sistemas de informac a dos, compostos por m ultiplos computadores ligados em rede. o dos diversos sistemas inNuma primeira fase, o principal desao foi a integrac a o permitiu eliminar silos de informac o form aticos existentes na empresa. Esta integrac a a o. Mais e desenvolver sistemas que ofereciam uma vis ao global e integrada da organizac a recentemente, os avanc os que est ao na origem da Internet (tecnologia e infraestrutura) ` s organizac es. A ligac o de sistemas tecnologicamente heintroduziram novos desaos a o a terog eneos e geogracamente distantes permite olhar para al em das fronteiras da pr opria o. Actualmente, e um pouco por todas as ind organizac a ustrias, h a uma forte aposta na o dos sistemas a um n integrac a vel inter-organizacional. o, os sistemas de informac o universit Na educac a a arios s ao, hoje, pec as fundamentais es acad reas, desde a gest das instituic o emicas. Est ao presentes em diversas a ao nanceira o at ltimos anos, tem-se da organizac a e ao apoio na gest ao curricular dos cursos. Nos u o deste tipo de assistido a um crescente investimento no desenvolvimento ou na aquisic a sistemas. o entre estas instituic es est No entanto, a colaborac a o a ainda muito limitada ao n vel da o dos diferentes sistemas de informac o. Por outro lado, a evoluc o da sociedade integrac a a a es tem destacado a import e das pr oprias organizac o ancia da interoperabilidade entre os o de Bolonha em que, dentre v arios sistemas. A t tulo de exemplo, refere-se a declarac a o da mobilidade de alunos, docentes e os principais objectivos, se estabelece a promoc a investigadores no espac o europeu. o geoAs caracter sticas actuais da Universidade do Porto, em termos de organizac a o. A Universidade do Porto gr aca, torna ainda mais relevante a necessidade de integrac a est a organizada em tr es grandes p olos, com algumas unidades situadas extra-p olos. O o entre as instituic es e, em particular, factor geogr aco diculta a partilha de informac a o rg o acesso por parte dos o aos de gest ao central. o das Este trabalho vem ao encontro desta problem atica, atrav es do estudo e avaliac a o universit alternativas para a interoperabilidade entre sistemas de informac a arios. Com o, procura-se contribuir para a concepc o e operacionalizac o de sistemas esta dissertac a a a o distribu o inter-organizacional de informac a dos que sustentem as estrat egias de integrac a num contexto acad emico.
1.2
o da Dissertac o Organizac a a
apresentado o conceito de Sistema de Informac o Universit No Cap tulo 2, e a ario. Depois feita uma caracterizac o dos sistemas de uma an alise organizacional das universidades, e a o existentes nas instituic es de ensino superior. Para tal, foi constru de informac a o da uma base de dados das funcionalidades encontradas nestes sistemas. Conclui-se o cap tulo, rea. com a refer encia a algumas das principais iniciativas nesta a
DA DISSERTAC 1.2. ORGANIZAC AO AO
21
No Cap tulo 3, aprofunda-se, com maior destaque para a vertente tecnol ogica, o con feita uma descric o dos n ceito de interoperabilidade. E a veis de interoperabilidade que e es conhecidas, o LISI e o NMI. No poss vel identicar, tendo por base duas classicac o o das opc es existentes ao n resto do cap tulo, procede-se a uma avaliac a o vel da arquitectu feita uma breve revis ra de sistemas distribu dos. No nal, e ao das principais alternativas tecnol ogicas. apresentado o problema concreto de interoperabilidade entre sisteNo Cap tulo 4, e o universit mas de informac a arios, tendo como caso de estudo o cen ario da Universidade do Porto. O problema foi estruturado segundo dois eixos: horizontal e vertical. Estes o, eixos s ao descritos e caracterizados neste cap tulo. Na sequ encia desta caracterizac a o: partilha, agregac o, concentrac o e dis ao identicados quatro padr oes de interacc a a a fus ao. Na conclus ao do cap tulo, e associados a cada um dos padr oes, s ao seleccionados o real. e apresentados quatro cen arios de aplicac a feita uma apresentac o detalhada da arquitectura proposta. Depois No Cap tulo 5, e a es tomadas para cada um dos padr de descritas e justicadas as opc o oes de alto n vel, e o para cada caso de estudo particular. feita uma breve contextualizac a o dos casos de estudo anteriormente deNo Cap tulo 6, descreve-se a implementac a o das opc es e convenc es t nidos. Ap os a apresentac a o o ecnicas adoptadas, o cap tulo est a o dos casos de estudo. No nal, e feita uma breve refer estruturado em func a encia aos prot otipos implementados. No Cap tulo 7, s ao apresentadas as conclus oes e algumas perspectivas de trabalho futuro. o No Anexo A, inclui-se a estrutura da base de dados constru da para a compilac a o universit das funcionalidades encontradas nos sistemas de informac a arios, bem como a listagem completa destas funcionalidades. es Nos Anexos B, C, D e E incluem-se, respectivamente, as listagens das especicac o es para o registo acad emico do aluno, para as estat sticas sobre cursos, para as informac o sobre recursos humanos e para as not cias.
22
CAPITULO 1. INTRODUC AO
Cap tulo 2 o Universit Sistemas de Informac a arios

apresentado o conceito de Sistema de Informac o Universit Neste cap tulo e a ario (SIU). ` s universidades como organizac es, s Depois de uma breve abordagem a o ao apresentadas as o existentes nas instituic es de ensino principais caracter sticas dos sistemas de informac a o superior. Aqui, exp oe-se um estudo feito sobre as funcionalidades encontradas nestes apresentado e descrito o problema da troca de sistemas. Na conclus ao do cap tulo e o entre sistemas deste tipo e s informac a ao referidas algumas das principais iniciativas rea. nesta a
23
24
UNIVERSITARIOS CAPITULO 2. SISTEMAS DE INFORMAC AO
2.1
es Universit As Organizac o arias
es complexas. O leque de intervenientes que re As Universidades s ao organizac o unem resulta num conjunto vasto e heterog eneo de interesses. es burocr Mintzberg [70] classica as universidades como organizac o aticas mas n ao ` s quais d centralizadas, a a o nome de Burocracias Prossionais. Associadas a este tipo o, identicam-se caracter de congurac a sticas como a complexidade do trabalho desen o de servic volvido pelos prossionais, a produc a os normalizados (pr e-determinados ou o ao servic previs veis), uma administrac a o dos prossionais e uma estrutura paralela de apoio log stico e administrativo organizada segundo uma burocracia tradicional (mecanicista). A prop osito destas duas hierarquias, ilustradas na Figura 2.1, Mintzberg arma: Na Burocracia Prossional, tem-se frequentemente duas hierarquias paralelas, uma para de natureza democr os prossionais, no sentido ascendente e que e atica, e outra para as es de apoio log func o stico, no sentido descendente e que tem a natureza de uma Burocracia Mecanicista..
Figura 2.1: As Hierarquias Paralelas na Burocracia Prossional
A natureza complexa do trabalho executado e a necessidade de proximidade aos cli es, entes (estudantes) fazem com que o prossional (docente) tenha, nestas organizac o o. O facto de grande parte do poder estar associado aos progrande liberdade de acc a o, resulta numa instituic o muito descentralizada, onde coexistem ssionais da instituic a a uma grande diversidade de grupos e equipas com vasto grau de autonomia. Neste tipo de o e aprovac o de estrat tradicionalmente muito comcontexto, a formulac a a egias globais e es, tradicionalmente, plexa. Este factor contribui para aumentar a in ercia de organizac o pouco din amicas. o que existem entre os prossionais de uma burocracia proOs uxos de informac a ssional s ao, assim, dispersos e pouco formais. A exist encia de v arios subsistemas com hierarquias pr oprias, bem como o grande n umero de pontos de contacto com o sistema o com padr central, tem como consequ encia o aparecimento de uxos de informac a oes o complexos e pouco estruturados. Na estrutura administrativa existente na organizac a
NAS UNIVERSIDADES 2.2. OS SISTEMAS DE INFORMAC AO
25
que, como j a referimos, est a organizada segundo uma burocracia centralizada, com pro o est cedimentos formalizados, o uxo de informac a a mais bem denido. poss o Deste modo, e vel identicar duas estruturas dentro de uma mesma organizac a o. Por um lado, a estrutura com atitudes muito diferentes perante a gest ao da informac a composta pelos prossionais apresenta um padr ao muito descentralizado e pouco deni centralizada e formalizada. Assim, do. Por outro, a estrutura administrativa de apoio e o de estrat o ser a denic a egias para a gest ao de informac a a, necessariamente, muito diferente num cen ario e no outro.
2.2
o nas Universidades Os Sistemas de Informac a
o das tecnologias de informac o numa instituic o de ensino suPodemos dividir a aplicac a a a o da actividade dos membros da perior em dois grupos: tecnologias de apoio e coordenac a o e tecnologias de apoio directo ao ensino. Nesta dissertac o, procura-se aproinstituic a a o associados ao primeiro grupo, geralmente fundar o estudo dos sistemas de informac a o Universit designados por Sistemas de Informac a arios. o Universit O conceito de Sistemas de Informac a arios (SIU) pode considerar-se pr oxi o base de Sistema de Informac o (SI), ou seja, um conjunto de componenmo da denic a a o para tes interrelacionados que re unem, processam, armazenam e distribuem informac a o e controlo numa organizac o [63]. Sistemas suportar a tomada de decis ao, coordenac a a o Universit ` aplicac o de SI ao contexto universit de Informac a arios correspondem a a ario, o de um reposit o que se traduz em realc ar as dimens oes de arquivo e de comunicac a orio o. Na realidade, um dos papeis mais importantes desempenhados comum de informac a o de arquivo e registo da actividade universit pelos SIU e aria. Sobre os sistemas t ecnicos existentes nas burocracias prossionais, e como resultado da grande autonomia dos prossionais, Mintzberg refere que n ao s ao nem muito sosticados, nem muito automatizados, nem muito reguladores e que a tecnologia da o - os conhecimentos que utiliza - e sosticada; mas o seu sistema t organizac a ecnico - o . [70]. conjunto dos instrumentos que utiliza - n ao o e o dos sistemas de informac o dentro destas organizac es pode ser analisada A evoluc a a o segundo duas perspectivas. Por um lado, a estrutura administrativa permitiu a exist encia o de uma vis ao global e, consequentemente, o desenvolvimento de sistemas de informac a o de sistemas de informac o junto da de forma coordenada. Por outro lado, a introduc a a estrutura prossional das universidades foi descoordenada. A natureza descentralizada desta estrutura resultou num desenvolvimento disperso pelos departamentos, n ucleos e o num equipas, de n vel muito desigual de sector para sector, com ilhas de organizac a o de informac o. Assim, se, por um contexto geral de impossibilidade pr atica de agregac a a o, por outro, aumentou-se o esforc lado, houve melhorias no tratamento de informac a o associado ao tratamento de dados duplicados e aos v arios pontos de acesso ao sistema, o parcelar, incoerente e n com informac a ao integrada. Algumas iniciativas no sentido de centralizar estes sistemas constitu ram o passo seguinte. Em muitos casos, o desenvolvimento interno foi adoptado como m etodo principal de desenvolvimento, em particular nos m odulos de gest ao de alunos [66]. A exist encia de o e a compet encias internas, os factores relacionados com a oportunidade de investigac a o [60]. falta de alternativas comerciais vi aveis, justicaram esta opc a
26
o de Portais Universit A implementac a arios tem sido uma tend encia generalizada no meio acad emico [32]. Para al em de atingir o objectivo de satisfazer as necessidades dos estudantes (em particular a mobilidade), Eisler enumera um conjunto de raz oes para justicar esta tend encia: a necessidade de permitir o acesso aos dados e aos processos de o, o aumento da concorr o trabalho por parte do pessoal da instituic a encia para a captac a ` instituic o e a import de estudantes, o desejo de ligar os antigos estudantes a a ancia de o junto do p es de tipo portal surgem n promover a instituic a ublico [32]. Estas soluc o ao o, mas pela necessidade de agregar informac o muito dispersa e reunir num u nico por opc a a es para os v o existentes na instituic o. ponto um conjunto de ligac o arios silos de informac a a es resultam na conjugac o, numa mesma p Em muitos casos estas soluc o a agina, de um conjunto de recursos s o levemente relacionados e que de facto n ao correspondem a um o integrado. sistema de informac a Como resultado do aumento do peso organizacional das unidades dedicadas ao desen o dos SIU, constitu es especicamente dedicavolvimento e manutenc a ram-se associac o o caso da EUNIS e da EDUCAUSE. das a estes assuntos como e uma associac o A European University Information Systems Organization (EUNIS) e a fundada em 1993 por representantes de 8 pa ses, actualmente (Setembro de 2003) s ao 22, que tem como principal objectivo a troca de experi encias entre respons aveis pelos o das instituic es universit sistemas de informac a o arias na Europa. Desde 1995 organiza uma confer encia anual [35]. uma organizac a cong o sem ns luA EDUCAUSE e enere nos EUA da EUNIS. E a o das tecnologias crativos que re une mais de 1800 escolas, e tem como miss ao a promoc a o no ensino superior [30]. Organiza, desde 1993, uma confer de informac a encia anual.
2.3
Funcionalidades dos SIU
mbito do que designaH a um grande n umero de funcionalidades que se enquadram no a mos por SIU e que resultam num conjunto de sistemas muito diversicados. Assim, no sentido de caracterizar e aprofundar o conhecimento sobre este tipo de sistemas, foi feito necess o um estudo sobre as funcionalidades mais comuns. E ario referir que esta avaliac a se cingiu a alguns exemplos considerados signicativos e n ao pretende representar a globalidade dos sistemas existentes. Foram estudados 15 SIU diferentes, onde se incluem sistemas desenvolvidos pelas es, sistemas comerciais e um sistema desenvolvido em regime de c pr oprias instituic o odigo es norte americanas [74]. Na livre (open-source), utilizado em mais de 100 instituic o ` enumerac o dos sistemas avaliados. Tabela 2.1, procede-se a a
2.3. FUNCIONALIDADES DOS SIU Tipo Desenvolvido peo la Instituic a o Instituic a URL / Refer encia
27
Technical University of Denmark Graz University of Technology, Austria Kaunas University of Technology, Lithuania University of Kent at Canterbury, United Kingdom University of Ljubljana, Faculty of Computer and Information Science, Slovenia University of Paisley, Scotland - United Kingdom Faculdade de Engenharia da UP, Portugal Slovak Agricultural University in Nitra, Slovak Republic University of St. Andrews, Scotland Instituto Polit ecnico de Tomar, Portugal Faculty of Mathematics, Informatics, and Mechanics, Warsaw University, Poland Comercial Campus Pipeline, Inc Digitalis Inform atica, Lda Sophia - Universidade Cat olica Portuguesa (GIPSI) C odigo Livre uPortal
http://www.dtu.dk http://www.tugraz.at [53] http://www.ktu.lt [78] http://www.ukc.ac.uk [46] http://www.fri. uni-lj.si [85] http://www.paisley. ac.uk [92] http://sifeup.fe.up. pt http://www.uniag.sk [100] http://www.st-and.ac. uk [64] http://www.ipt.pt [98] http://www.mimuw.edu. pl [69] http://www.campuspipeline.com http://www.digitalis.pt http://www.gipsi.ucp.pt
http://mis105.mis.udel.edu/jasig/uportal/
o Universit Tabela 2.1: Sistemas de Informac a arios avaliados
O m etodo de estudo a que se recorreu na an alise de sistemas variou signicativamente es em que foi poss de caso para caso. Houve situac o vel usar o sistema directamente, noutros casos foram consultados artigos dispon veis sobre o sistema. Os artigos publicados na confer encia EUNIS 2002: The Changing Universities: The Challenge of New Technologies revelaram-se um recurso importante [82]. Como consequ encia, os n veis de detalhe o dispon obtidos variam muito de sistema para sistema. Em alguns casos, a informac a vel rea resume-se a um pequeno conjunto de funcionalidades relacionadas com determinada a o completa das funcionalidades. do sistema. Noutros foi poss vel fazer uma avaliac a o reunida, foi constru A m de organizar a informac a da uma base de dados, com o sobre os sistemas, as funcionalidades, as categorias e palavras-chave. No informac a o da estrutura da base de dados e a listagem comAp endice A encontra-se a especicac a
28
pleta das funcionalidades encontradas. As funcionalidades foram organizadas, de forma n ao exclusiva, segundo categorias, denidas durante o decurso do trabalho. Cada funcionalidade pode estar associada a mais do que uma categoria. Na Tabela 2.2 apresenta-se o n umero de funcionalidades por categoria. Categoria Administrativa Acad emica Sistema o e Desenvolvimento Investigac a N umero de Funcionalidades 99 78 23 16
Tabela 2.2: N umero de funcionalidades por categoria
Na categoria Administrativa re unem-se as funcionalidades associadas a tarefas ad es dos alunos e ministrativas: gest ao de um calend ario do curso, gest ao das classicac o gest ao do registo acad emico do aluno. A categoria Acad emica agrega as funcionalidades relacionadas com a actividade lec o do tiva; re une funcionalidades como a gest ao de sum arios das aulas, disponibilizac a cat alogo dos cursos e gest ao de hor arios. ` administrac o ou A categoria Sistema corresponde a funcionalidades associadas a a o do pr o. Por exemplo, a criac o de novos uticongurac a oprio sistema de informac a a lizadores no sistema. o e Desenvolvimento incluem-se as funcionalidades Por m, na categoria Investigac a o: a pesquisa de publicac es, o registo das relacionadas com as actividades de investigac a o o e a gest o relativa a projectos. actividades de investigac a ao de informac a o de categorias, tamb Para al em da denic a em foram denidas palavras-chave, com o adicional mais ex o intuito de permitir uma forma de caracterizac a vel para cada funcionalidade. Cada funcionalidade pode ter associadas v arias palavras-chave. Depois de estruturadas as palavras-chave, deniram-se grupos com base no trabalho de Coimbra e o de processos acad Rito Silva [11] na classicac a emicos no contexto do Ensino Superior. o. Na Tabela 2.3 e Foram denidos 4 grupos: actividade, suporte, indiv duo e organizac a discriminado o n umero de funcionalidades associadas a cada palavra-chave.
2.3. FUNCIONALIDADES DOS SIU Grupo Suporte Suporte Indiv duo Indiv duo Actividade Suporte Indiv duo o Organizac a Suporte Actividade Actividade Indiv duo Actividade Actividade o Organizac a o Organizac a Suporte Indiv duo Indiv duo Palavra-Chave Ferramenta Administrativo Aluno Pessoal Docente Disciplina o Colaborac a Investigador o Instituic a o Sistema de Informac a o P os-Graduac a Programa Pessoa Grau Acad emico I&D Grupo / Unidade Departamento Financeiro Pessoal Antigos Alunos No Funcionalidades 125 104 91 69 56 49 32 28 24 18 18 18 16 14 13 13 11 11 2
29
Tabela 2.3: N umero de funcionalidades por grupo e palavra-chave
poss Com base nos dados apresentados e no estudo feito, e vel armar que, nos sistemas escolhidos, se destacam as funcionalidades associadas ao suporte, juntamente com as palavras-chave associadas a ferramentas, tarefas administrativas e alunos. De facto, as funcionalidades mais comuns s ao aquelas relacionadas com a gest ao administrativa dos indiv duos (alunos, docentes e pessoal). S ao, tamb em, frequentes as funcionalidades as` gest sociadas a ao das disciplinas e dos cursos. Por sua vez, as ferramentas tamb em s ao frequentes: sistema de help-desk, pesquisa de pessoal, gest ao de grupos de discuss ao. o do n Na Tabela 2.4 apresentam-se as funcionalidades mais comuns com indicac a umero de sistemas onde foram encontradas. Gest ao das Matr culas nas Disciplinas Ficha de Curso Ficha da Disciplina Ficha do Aluno Ficha do Docente 7 5 5 5 4
Tabela 2.4: Exemplo de funcionalidades mais comuns nos sistemas avaliados
No outro extremo, temos funcionalidades muito espec cas que encontramos, pontualmente, em alguns sistemas, como: o com Sistema de Leitura Optica. Integrac a
30
UNIVERSITARIOS CAPITULO 2. SISTEMAS DE INFORMAC AO Gestor de Bookmarks Personalizado. Gestor de Galerias de Fotograas.
mbito da interoperabilidade foram Tendo em conta o tema central desta tese, no a registadas apenas 3 funcionalidades: o da lista de alunos por disciplina. Exportac a o de dados para a impress Exportac a ao de cart oes de alunos. o dos hor Exportac a arios (p.e. para Excel). mbito dos SIU, os trabalhos nesta a rea s natural a No a ao ainda raros, pelo que e reduzida lista de funcionalidades catalogadas neste dom nio. es com esta Concluindo, estes resultados v em ao encontro do esperado em organizac o o. Os procedimentos administrativos de apoio a ` s actividades prim congurac a arias s ao os que se encontram mais normalizados, sendo por isso mais f aceis de transpor para o mbito de um sistema de informac o. Por outro lado, os processo associados ao ensino a a o s ou investigac a ao mais subjectivos e, consequentemente, mais dif ceis de representar.
2.4
2.4.1
o Troca de Informac a
o Denic a
o t mbito. No caso dos Os sistemas de informac a em fronteiras que delimitam o seu a o universit vasto e resulta de uma sistemas de informac a arios, o contexto abrangido e o complexa e fortemente descentralizada. organizac a o, os sistemas de informac o necessitam de No entanto, tal como a pr opria organizac a a interagir com outros sistemas externos. E essencial a possibilidade de troca de registos es, a consulta de informac o institucional, disponibilizac o de de alunos entre instituic o a a o de curr culos ou estat sticas de desempenho. A estes processos de partilha e reutilizac a o e procedimentos entre sistemas, est informac a a associado o termo interoperabilidade. Beynon-Davies dene interoperabilidade como uma medida do grau segundo o qual os o s sistemas de informac a ao capazes de se coordenar e colaborar [6]. O grau de interoperabilidade entre dois sistemas pode ser avaliado segundo v arios n veis. Miller prop oe uma divis ao em 6 dimens oes [68]: o, trans Interoperabilidade T ecnica: relacionada com normas relativas a comunicac a o. porte, armazenamento e representac a o sem Interoperabilidade Sem antica: relacionada com a construc a antica, meta-dados e estrutura. Interoperabilidade Pol tica / Humana: relacionada com a dimens ao organizacional, os uxos de trabalho e de poder e as culturas.
2.4. TROCA DE INFORMAC AO
31
o entre dom Interoperabilidade Inter-Comunit aria: relacionada com a interacc a nios o entre uma instituic o banc / contextos independentes (p.e.: a troca de informac a a aria e uma faculdade). o de dados. Interoperabilidade Legal: relacionada com decis oes legais, protecc a Interoperabilidade Internacional: relacionada com a nacionalidade e com impacto o sobre alunos do programa nas anteriores dimens oes. (p.e.: a troca de informac a ERASMUS). o de Bolonha [36], assinada em 1999 pelos ministros da educac o dos A declarac a a pa ses da UE, veio rearmar a import ancia estrat egica de uma aposta na interoperabilida o das instituic es de educac o europeias. Dos objectivos de entre os sistemas de informac a o a o da mobilidade de alunos, docentes, investitrac ados, destacam-se a aposta na promoc a o entre as instituic es. gadores e outro pessoal, e a aposta na cooperac a o es europeias p o para a participac o e candidatura a As instituic o oem como condic a a o em formato electr programas de mobilidade, a exist encia de informac a onico armazenada o. em sistemas de informac a
2.4.2
Iniciativas Existentes no Contexto Acad emico
o entre instituic es do S ao v arias as iniciativas a n vel mundial que exploram a colaborac a o ensino superior [2], embora a maioria dos projectos existentes incida sobretudo na troca o), o que est mbito desta dissertac o. Nesta de recursos educacionais (instruc a a fora do a a o, faz-se uma breve apresentac o de algumas das principais iniciativas existentes. secc a a UN/CEFACT ` s iniciais de United Nations Centre for Trade FacilitaA sigla UN/CEFACT corresponde a es Unidas tem como miss tion and Electronic Business. Este centro das Nac o ao promover es comerciais, de bens ou servic mecanismos que simpliquem as transacc o os, entre empresas, e, desta forma, contribuir para o crescimento global do com ercio. Sob a alc ada o, coexistem v desta organizac a arias iniciativas: o caso do grupo de trabalho UN/EDI es ebXML. FACT e das especicac o respons o O grupo de trabalho UN/EDIFACT e avel pelo desenvolvimento, manutenc a o da norma EDI - UN/EDIFACT. Em 1999, o UN/CEFACT lanc e promoc a ou uma inici o do com ativa com vista ao desenvolvimento de estruturas em XML para a promoc a ercio global, mais tarde designada por ebXML [26]. mbito do UN/CEFACT, tem sido dada prioridade ao desenvolvimento de normas No a rea da para a ind ustria e neg ocios. Existe pouco material publicado, relevante para a a o. Apesar de tudo, esta organizac o, em parceria com o grupo de normas OASIS, educac a a tem-se armado como um dos principais intervenientes no mercado das normas para a o. O facto de estar sob a alc transfer encia electr onica de informac a ada da ONU garantelhe uma visibilidade acrescida.
32
ANSI ASC X12A um comit O ACS X12 e e, certicado pela ANSI em 1979, que visa o desenvolvimen o de transacc es electr to de normas para a implementac a o onicas entre empresas de uma o da mesma ind ustria. As normas denidas pelo ACS X12 s ao utilizadas para a denic a o das mensagens utilizadas nas transacc es electr sintaxe, estrutura e ordenac a o onicas entre empresas e s ao designadas por Electronic Data Interchange (EDI). mbito da educac o e mais Actualmente, o trabalho desenvolvido pelo ACS X12 no a a abrangente do que aquele que tem vindo a ser realizado pelo CEFACT. O subcomit e mbito de trabalho a administrac o escolar. As iniciativas levadas X12A [103] tem como a a a cabo pelo X12A compreendem todos os n veis de escolaridade, desde o prim ario ao universit ario, bem como casos especiais de ensino (privado, prossional ou outro). As rea administrativa, o registo acad normas j a desenvolvidas abrangem a a emico dos alunos, es relativa aos recursos humanos, a ajuda nanceira e a gest informac o ao curricular. S ao o, maioritariamente os formatos mais usados nos EUA para a transfer encia de informac a es acad administrativa, entre instituic o emicas. Os formatos denidos incluem: TS130 Student Educational Record, TS133 - Educational Institution Record, TS152 - Statistical Government Information, entre outros. Ambas as normas, X12 e EDIFACT, permitem codicar os documentos (estruturados es em blocos de dados delimitados) em formatos que podem ser interpretados por aplicac o inform aticas. A transmiss ao dos dados n ao e especicada nas normas, sendo frequente o recurso a VAN (Value Added Networks). SPEEDE/ExPRESS SPEEDE/ExPRESS [71] s ao as iniciais de Standardization of Postsecondary Education Electronic Data Exchange / Exchange of Permanent Records Electronically for Students and Schools. Este projecto, iniciado em 1988 e patrocinado pelo National Center for o de um conjunto de formatos Education Statistics dos EUA, constitui uma implementac a o. Estas normas s para o uso de EDI na educac a ao mantidas pelo ASC X12 [102] (ver o anterior). secc a Postsecondary Electronic Standards Council uma organizac o dos EUA, A Postsecondary Electronic Standards Council (PESC) [18] e a es acad constitu da por cerca de 50 membros (instituic o emicas e empresas comerciais), e o do uso de normas electr o e a respectiva impleque visa a promoc a onicas na educac a o. Destacam-se as actividades desenvolvidas no a mbito do grupo XML Forum mentac a rea da educac o [21], que se posiciona como o grupo respons avel pelas normas XML na a a o apoio na transic o de tecnologias e [20]. Um dos principais objectivos do PESC e a mecanismos baseados em EDI para XML. o T Nos documentos j a publicados por este grupo, inclui-se a Especicac a ecnica em XML para o Ensino Superior [22] e um conjunto de livros brancos sobre uso de chaves p ublicas, identicadores de estudantes e XML. Algumas das normas j a existentes e aplicadas no meio acad emico, em particular as que s ao denidas pelo ACS X12, est ao a ser usadas como ponto de partida para o trabalho desenvolvido pelo XML Forum. No conjunto de tarefas agendadas, est a inclu da
33
es em X12 [17]. Recentemente, foi a convers ao para XML de algumas das especicac o publicada a vers ao 1.0 do XML Postsecondary Transcript Schema [19]. Sistema de Codicaci on Acad emica Normalizado en Red um projecO Sistema de Codicaci on Acad emica Normalizado en Red (SCANet) [89] e to iniciado em 2001, na Universidade Espanhola de L erida, que visa o desenvolvimen o e transfer o no contexto da gest to de normas para a representac a encia de informac a ao es entre as univeracad emica. O projecto tem como objectivo tornar mais f aceis as relac o sidades, destas com os estudantes e docentes, trazendo valor acrescentado aos processos de gest ao acad emica [91]. O projecto est a estruturado em 3 fases [90]: o de c o u nicos. Denic a odigos de identicac a o de requisitos para transfer Especicac a encia de conte udos electr onicos. o das formas e procedimentos. Harmonizac a Destaque para as normas j a publicadas: Norma 1.01/02E - Identicaci on Normalizada del C odigo Unicado de Estudiante [86]. Norma 2.01/02E - C odigo de Universidad y C odigos de servicios asociados [87]. Norma 4.01/03E - Homologaci on de Datos de Expedientes de Primer y Segundo Ciclo para Intercambios, Traslados y Certicaciones Acad emicas [88]. o de cerca de 50 universidades espaActualmente o projecto conta com a participac a o do Governo Central Espanhol na elaborac o de regulamentos nholas e com a colaborac a a administrativos [55]. Internet2 Middleware Initiative um projecto enquadrado na Iniciativa A Internet2 Middleware Initiative (I2-MI) [59] e o e desenvolvimento de servic Norte Americana Internet2, que visa a promoc a os e infra o entre aplicac es no contexto universit estruturas que permitam a integrac a o ario e comuni reas como seguranc o, dades relacionadas. Esta iniciativa abrange a a, partilha de informac a o e uso de chaves p autenticac a ublicas. Dentre os v arios projectos e iniciativas desenvolvidas no contexto da I2-MI, destacamse as seguintes: Middleware Architecture Committee for Education (MACE) - grupo, constitu do reas de direct por universidades e que est a envolvido em actividades nas a orios, o e autenticac o. infra-estrutura de chaves p ublicas (PKI), autorizac a a
34
UNIVERSITARIOS CAPITULO 2. SISTEMAS DE INFORMAC AO mbito do MACE destacam-se os projectos eduPerson, eduOrg [31] e DoDHE No a o de objectos LDAP para [57]. Os dois primeiros t em como objectivo a denic a o de indiv es no contexto acad a representac a duos e organizac o emico. O projecto Directory of Directories for Higher Education (DoDHE) insere-se no estudo de o inter-institucional de pesquisas em direct tecnologias que apoiem a integrac a orios. O projecto Shibboleth [58] tem por objectivo o estudo e desenvolvimento de arqui es que apoiem a partilha de recursos tecturas, pol ticas, tecnologias e implementac o Web, sujeitos a controlo de acessos. Este projecto envolve, ainda, o desenvolvimento de uma estrutura para a interoperabilidade dentro da comunidade do ensino superior. um grupo constitu Multicampus Middleware e do em 2002 e que tem como objec mbito da implementac o de tecnologias tivo fomentar a troca de experi encias no a a de middleware em ambientes universit arios.
Schools Interoperability Framework um cons O Schools Interoperability Framework (SIF) [93] e orcio empresarial dos EUA o para a integrac o de aplicac es que, desde 1997, procura desenvolver uma especicac a a o mbito educacional. A especicac o publicada permite, por exemplo, a interoperabide a a es relacionadas com a gest lidade entre aplicac o ao de matr culas de alunos, a gest ao da o desenvolvida baseia-se na norma XML cantina ou a emiss ao de cart oes. A especicac a a 1.1. Este trabalho est do W3C e a vers ao mais recente dispon vel e a direccionado para o ensino pr e-universit ario e tem uma forte ades ao por parte dos principais fabricantes de es. aplicac o baseada num modelo distribu A arquitectura proposta pelo SIF e do, em que as apli es inform cac o aticas recorrem a agentes para comunicar com um n o intermedi ario central o existe em cada instituic o de ensino. - o Zone Integration Server (ZIS). Esta congurac a a A n vel europeu, o projecto OASIS - Open Architecture and Schools in Society [73], ` s Tecnologias de Informac o na Sociedade (IST), enquadrado no programa de apoio a a procura adaptar o trabalho desenvolvido pelo SIF ao contexto europeu [10]. IEEE Learning Technology Standards Committee a entidade, enquadrada O IEEE Learning Technology Standards Committee (LTSC) [95] e no contexto da IEEE Computer Society Standards, respons avel pelo desenvolvimento de es e linhas de acc o no contexto das tecnologias de ensino normas t ecnicas, recomendac o a o. focadas sobretudo na instruc a Instructional Management Systems uma das principais iniciativas no O Instructional Management Systems (IMS) [56] e uma organizac mbito do ensino online. E o sem ns lucrativos constitu a a da nos EUA es acad em 1999, com mais de 100 membros activos, entre instituic o emicas e empresas.
35
es, baseadas em XML, para a Tem publicado um n umero signicativo de especicac o o sobre os educadores, entre sistemas educacitroca de conte udo educacional e informac a onais. DCMI Education Working Group mbito da DCO DCMI-EWG tem por objectivo o desenvolvimento de elementos no a o de materiais educacionais. A Dublin Core Metadata MI, tendo em vista a caracterizac a rea da educac o, em 1999 [27]. Initiative (DCMI) constituiu este grupo de trabalho na a a
36
Cap tulo 3 ` Tecnologias de Apoio a Interoperabilidade

Neste cap tulo aprofunda-se, com maior destaque para a vertente tecnol ogica, o con o dos n ceito de interoperabilidade. E feita uma descric a veis de interoperabilidade que poss es conhecidas, o LISI e o NMI e vel identicar, tendo por base duas classicac o o 3.1). Nas secc es seguintes, procede-se a uma avaliac o das opc es existentes (Secc a o a o o 3.2 e 3.7). Nesta avaliac o, ao n vel da arquitectura de sistemas distribu dos (Secc a a destacam-se as dimens oes consideradas mais relevantes no contexto da interoperabilida feita uma breve revis de entre SIU. No nal, e ao das principais alternativas tecnol ogicas o 3.8). (Secc a
37
38
` INTEROPERABILIDADE CAPITULO 3. TECNOLOGIAS DE APOIO A
3.1
N veis de Interoperabilidade
o 2.4.1, foi apresentada uma denic o para Interoperabilidade no a mbito dos Na Secc a a o e segundo seis dimens Sistemas de Informac a oes. Neste cap tulo, procede-se a uma an alise mais detalhada das dimens oes t ecnica e sem antica. Existem v arios modelos de refer encia que procuram caracterizar os n veis de interoperabilidade t ecnica poss veis entre dois sistemas. A comunidade militar tem desenvolvido rea e os dois principais modelos publicados surgem neste contexto muito trabalho nesta a - o Level of Information Systems Interoperability (LISI) e o NATO C3 Technical Architecture (NC3TA) Reference Model for Interoperability (NMI) [99]. O modelo LISI foi publicado pelo Departamento de Defesa dos EUA [49] e identica es, dados e infraestrutura. Em cada quatro dom nios: procedimentos e pol ticas, aplicac o um destes dom nios, s ao enumerados n veis de interoperabilidade, que d ao origem a cinco categorias de interoperabilidade t ecnica: N vel 0: Isolado (Manual) - N ao ligado, mecanismos manuais (p.e. disquete). o electr es separados (p.e. N vel 1: Ligado (P2P) - Ligac a onica; dados e aplicac o correio electr onico). es m es N vel 2: Funcional (Distribu do) - Func o nimas comuns; dados e aplicac o separados (p.e. HTTP). es separadas. N vel 3: Dom nio (Integrado) - Dados partilhados; aplicac o o interactiva; dados e aplicac es parti N vel 4: Empresa (Universal) - Manipulac a o lhados. O NMI est a inclu do na NATO Consultation, Command and Control (C3) Technical Architecture (NC3TA) [50] e estabelece graus e subgraus de interoperabilidade. Os graus o da de interoperabilidade denem um modelo de maturidade que captura a sosticac a interoperabilidade; por sua vez, os subgraus descrevem um modelo de capacidades que reectem a funcionalidade dispon vel. Grau 1: Troca de Dados N ao Estruturados. Este n vel envolve a troca de dados n ao estruturados, interpret aveis por humanos (p.e.: pap eis, relat orios, etc). Grau 2: Troca de Dados Estruturados. o interpret Este n vel envolve a troca de informac a avel por humanos, destinada a processamento manual ou autom atico. No entanto, s ao necess arios mecanismos o, recepc o e/ou envio. manuais de compilac a a Grau 3: Partilha de Dados. Este n vel envolve a troca autom atica de dados sobre sistemas com modelos de partilha comuns. o. Grau 4: Partilha de Informac a o universal de informac o E uma extens ao do grau 3 e estabelece a interpretac a a atrav es do processamento cooperativo dos dados.
3.2. ARQUITECTURAS DISTRIBUIDAS
39
mencionada neste modelo. A n ao conectividade entre sistemas (N vel 0 do LISI) n ao e Nos restantes n veis, existe uma correspond encia entre os dois modelos. o do grau de interopeEstes modelos denem uma estrutura gen erica para a avaliac a o de arquitecturas deste rabilidade entre dois sistemas. E poss vel sistematizar a avaliac a tipo, discriminando tr es camadas [67]: o Comunicac a o para a troca de mensagens enEsta camada inclui os protocolos de comunicac a tre as partes. Podem ser usados protocolos privados ou p ublicos, como o HTTP. Permite estabelecer um acordo ao n vel da infraestrutura tecnol ogica. Conteudo Nesta camada, enquadram-se as linguagens e os modelos que permitem descrever o, de forma a ser entendida pelas partes. Aborda n e organizar a informac a ao s o aspectos t ecnicos mas, tamb em, quest oes sem anticas. Processo es entre os processos de neg Esta camada relaciona-se com as interacc o ocio, com os o, com o tipo de acc es que s signicados de determinada acc a o ao permitidas, com o teor das respostas esperadas, etc. Estabelece uma sem antica comum. a capacidade que um sistema Em suma, Interoperabilidade T ecnica e Sem antica e tem para aceder a partes, dados ou funcionalidades, de outro sistema. Ao n vel mais o simples, situa-se a troca de dados entre dois sistemas de forma manual e com intervenc a o e importac o de dados entre aplicac es desligadas). O grau humana (rotinas de exportac a a o atingido quando os dois sistemas partilham os objectos m aximo de interoperabilidade e o de dados e os servic os, de forma harmoniosa e invis vel para o exterior, sem intervenc a humana.
3.2
Arquitecturas Distribu das
Uma das dimens oes que se pode considerar para classicar os sistemas distribu dos tem o Servidor a ver com os pap eis desempenhados pelos Servidores e Clientes. A designac a e atribu da ao sistema que disponibiliza os dados ou o servic o. O Cliente e o sistema que o presente, podemos distinguir 3 procura os dados ou o servic o. Tendo esta classicac a arquitecturas para os sistemas distribu dos (Figura 3.1): o e iniciada pelo cliente. S Cliente-Servidor: A interacc a ao geralmente designa a elevada das por arquitecturas do tipo Pull. Uma vantagem desta arquitectura e o que circula, uma vez que apenas e enviada aquela que e qualidade da informac a uma arquitectura vantajosa em cen explicitamente pedida pelos clientes. E arios de o j o alterada ou nova). Num entrega de informac a a existente (por oposto a informac a sistema com um n umero reduzido de servidores e um n umero muito elevado de cli` sobrecarga dos servidores. entes, esta arquitectura pode ser inadequada devido a a navegac o na WWW. Um exemplo de uma arquitectura deste tipo e a
40
Figura 3.1: Arquitecturas Distribu das: C/S, P2P e S/C Arquitecturas Distribu das: C/S, P2P e S/C (Adaptado de [7])
es de cliente, Peer-to-peer: Os diversos sistemas tanto podem desempenhar func o o pode ser iniciada por qualquer uma das partes. As como de servidor. A interacc a a grande toler principais vantagens desta arquitectura e ancia a falhas e escalabilida o complexa uma vez que n de. No entanto, s ao sistemas de implementac a ao existe controlo sobre o papel desempenhado por cada sistema (cliente ou servidor) e so o dos dados. Apesar de um custo inicial baixo, a administrac o e bre a localizac a a o tendem a ser mais complexas a m um manutenc a edio prazo [61]. A seguranc a e o dos aspectos mais fr ageis. Um exemplo de um sistema com esta arquitectura e Napster. o. S Servidor-Cliente: Neste cen ario, o servidor inicia a comunicac a ao geralmente uma arquitectura adequada a cen arios designadas por arquitecturas do tipo Push. E de envio de itens novos ou alterados. E tamb em vantajosa em cen arios de difus ao o. Por outro lado, um sistema deste tipo pode n de informac a ao ser interessante quando os clientes t em pedidos irregulares, porque os clientes s ao interrompidos o que n do interesse deles. Um exemplo v arias vezes para processar informac a ao e de uma arquitectura deste tipo s ao os grupos de discuss ao baseados em correio electr onico.
3.3
o Modelos de Programac a
` categorizac o dos v o distriExistem diversas abordagens a a arios modelos de programac a o denida por Emmerich [33]: bu da ([96], [34], [83]). Refere-se aqui a classicac a Procedimental: As Remote Procedure Calls (RPC) foram concebidas pela Sun Mio crosystems no in cio dos anos 80. O conceito base consiste em permitir a invocac a remota de procedimentos publicados por servidores, da mesma forma que s ao feitas es locais. invocac o es envolvendo m Transacional: Permite gerir transacc o ultiplos componentes em diferentes servidores. Em geral, usam protocolos do tipo two-phase commit na o. Exemplos: IBM CICS e BEA Tuxedo. implementac a
3.4. SINCRONISMO
41
` s Mensagens: A comunicac o entre sistemas distribu imple Orientado a a dos e ` troca de mensagens. O IBM MQSeries e o Sun JMQ s mentada recorrendo a ao exemplos de produtos desta categoria. o dos tradici Baseado em Objectos e Componentes: Constituem uma evoluc a ` evoluc o que se assistiu nas linguagens de onais RPCs, de forma semelhante a a o. A ideia e permitir a colaborac o entre sistemas ao n programac a a vel de compo` que existe entre procedimentos no RPC. Exemnentes/objectos, de forma similar a plos: CORBA, Microsoft COM e Sun RMI.
3.4
Sincronismo
Uma outra dimens ao que pode ser usada para classicar sistemas distribu dos est a relacionada com o sincronismo ou acoplamento entre os sistemas. H a autores que estendem o e consideram tr esta classicac a es subn veis de acoplamento extra: temporal, espacial e o, descrevem-se os dois tipos de sincronismo de um ponto de de uxo [34]. Nesta secc a vista gen erico (Figura 3.2).
Figura 3.2: Sincronismo entre Sistemas Distribu dos: S ncrono e Ass ncrono
3.4.1
o S Interacc a ncrona
Nas arquitecturas cliente-sevidor tradicionais, este tem sido o modelo predominante [47]. o necessitam de estar activos e Neste cen ario, os sistemas que participam na comunicac a o. ocupados em simult aneo, no decorrer da transacc a o baseado em RPC e um dos principais exemplos de uma O modelo de programac a es procuram esconder a distribuic o dos interveniarquitectura s ncrona. Estas soluc o a es iguais a invocac es locais de procedimentos. entes, tornando as transacc o o Os sistemas s ncronos d ao origem a um arquitectura pouco din amica, mais adequada es que se adaptam mal a sistemas de grande a ambientes muito controlados. S ao soluc o es, devido aos custos de coordenac o e vari avel dimens ao, envolvendo v arias organizac o a o e menos (mensagens e processamento). Por outro lado, como vantagem, a implementac a complexa do que a alternativa ass ncrona.
42
o Ass 3.4.2 Interacc a ncrona

es disA crescente necessidade de exibilidade, abilidade e desacoplamento em aplicac o tribu das de grande escala, em particular na Internet, resultou numa tend encia generali o de protocolos ass zada para a adopc a ncronos [47]. As arquitecturas baseadas na passa o ass gem de mensagens s ao um exemplo de uma soluc a ncrona. Nestes casos, o cliente comunica com o servidor enviando mensagens estruturadas atrav es de interfaces simples o sobre o m e normalizadas. Toda a informac a etodo a invocar e dados a transmitir est a o e deslocada para o n inclu da na mensagem. A l ogica da interacc a vel da mensagem, o ou respostas. que pode conter dados, pedidos de acc a uma abordagem que constitui um compromisso entre o n o proE vel de abstracc a es fortegram atico (menor do que o modelo anterior) e os requisitos pr aticos (aplicac o o 3.8.1) e um exemplo de uma arquitectura mente desacopladas) [47]. O EDI (ver Secc a ass ncrona baseada na troca de mensagens. A primeira vaga de Servic os Web foi dese` s vantagens referidas, a tend a adopc o de nhada como RPC, mas, devido a encia actual e a mecanismos baseados na passagem de documentos XML [8]. o, soluc es mais As abordagens ass ncronas s ao, do ponto de vista da implementac a o o complexas. Requerem a exist encia de mecanismos interm edios para a gest ao da interacc a - gest ao de las de espera, gest ao dos sistemas participantes, enderec amento das invoca es, etc. c o
3.5
o dos Dados Colocac a
o em ambientes distribu No contexto do processamento da interrogac a dos, existem du reas onde e poss es: na execuc as a vel introduzir optimizac o a a o da interrogac o e na o din colocac a amica dos dados [61]. Com a colocac a amica dos dados, procura o din o dos dados em func o dos locais onde s se optimizar a colocac a a ao necess arios com maior o. frequ encia, usando mecanismos de caches ou replicac a a o de informac ` colocac o dos dados ([61], [62] e Existem tr es abordagens alternativas, associadas a a o para os dados (execuc o no servidor, query shipping), mover [44]): mover a interrogac a a o (execuc o no cliente, data shipping) ou uma soluc o h os dados para a interrogac a a a brida (hybrid shipping) (Figura 3.3).
o 3.5.1 Mover a Interrogac a

o das interrogac es e sempre feita no servidor onde est Nesta alternativa, a execuc a o ao os o para o servidor, que faz a execuc o localmente e dados. O cliente envia a interrogac a a necess envia os resultados para o cliente. Quando existem m ultiplos servidores, e aria uma es que envolvem dados camada interm edia para lidar com a processamento de interrogac o localizados em diferentes servidores. vantajosa quando o servidor tem um desempenho elevado e os cliEsta abordagem e entes s ao lentos. Por outro lado, como ponto negativo, a sobrecarga do servidor est a directamente relacionada com o n umero de clientes. ilustrado o processo para o caso de um servidor. Esta opc o e usada Na Figura 3.3, e a em muitos SGBD relacionais (p.e. Oracle, DB2, SQL Server).
DOS DADOS 3.5. COLOCAC AO
43
o dos Dados: Envio da Interrogac o, Envio dos Dados e Soluc o Figura 3.3: Colocac a a a H brida o dos Dados: Envio da Interrogac o, Envio dos Dados e Soluc o H Colocac a a a brida (imagem adaptada de [61])
3.5.2
Mover os Dados
es s o Com o envio dos dados, todas as operac o ao executadas no cliente onde a interrogac a ` abordagem anterior. O cliente mant teve origem. Funciona de forma oposta a em c opias dos dados existentes no servidor e utiliza estas c opias para processamento das interroga es. Neste caso, e necess o das c c o ario denir uma pol tica de actualizac a opias que existem nos clientes. o e o facto do processamento estar distribu Uma vantagem desta soluc a do pelos clientes, permitindo um crescimento mais equilibrado. Do ponto de vista negativo, esta abordagem pode originar um volume de tr afego sobre a rede muito elevado. No exemplo apresentado na Figura 3.3, c opias das tabelas A e B s ao mantidas no o (join) e executada sobre esses dados. Esta alternativa e usada em cliente e a interrogac a v arios SGBD orientados a objectos (p.e. ObjectStore).
3.5.3
o H Soluc a brida
a melhor para todos os casos. As vantagens de Nenhuma das alternativas anteriores e o h o das ambas podem ser combinadas numa soluc a brida [44]. Neste caso, a execuc a es pode ser feita no cliente ou no servidor e e poss interrogac o vel a exist encia de caches nos clientes. ilustrada na Figura 3.3. A interrogac o inicial e dividida em duas Esta abordagem e a executada sobre a c enviada para o parciais, uma e opia local da tabela A e a outra e o parcial e envia os resultados para o cliente, servidor. O servidor executa a interrogac a que re une os dois conjuntos para produzir o resultado nal.
44
3.6
Consist encia dos Dados
o de dados permite melhorar o tempo de resposta Em sistemas distribu dos, a replicac a o em que os custos de e a disponibilidade do sistema [16]. Por exemplo, numa situac a o sejam elevados, a replicac o dos dados junto do cliente poder comunicac a a a ser uma opc ao vantajosa. Desta forma, para cada objecto l ogico, podem existir v arias representa es f c o sicas (Figura 3.4).
o L o F Figura 3.4: Representac a ogica e Representac a sica
es f A exist encia de m ultiplas representac o sicas do mesmo objecto l ogico introduz o problema da consist encia dos dados. Como manter as c opias f sicas iguais? Como es feitas ao objecto l processar as alterac o ogico? E necess ario um compromisso entre a o e a performance e disponibilidade do sistema. Nas subsecc es consist encia da informac a o seguintes, apresentam-se as principais decis oes associadas a uma arquitectura deste tipo. o exaustiva de v Uma classicac a arias alternativas pode ser encontrada em Franklin es nos principais produtos comerciais pode ser [43]. Uma revis ao interessante das opc o encontrada em Stacey [94].
3.6.1 Protocolos
es a uma c Um protocolo especica o processo segundo o qual modicac o opia f sica s ao reproduzidas, de forma a restabelecer a consist encia dos dados em todas as c opias f sicas. ` quest es aos dados?. ExisOs protocolos respondem a ao: Onde submeter as actualizac o tem duas abordagens principais: actualizac a ario e actualizac a o no prim o global (Figura 3.5) [48]. o no Prim Actualizac a ario deNeste caso, por vezes designado de replicac a o passiva [16], para cada objecto, e nida uma c opia f sica prim aria. As restantes c opias f sicas s ao designadas por c opias es de leitura podem ser secund arias ou r eplicas. Este protocolo especica que as operac o es de escrita apenas podem feitas sobre qualquer uma das c opias, enquanto que as operac o ser realizadas sobre a c opia prim aria.
3.6. CONSISTENCIA DOS DADOS
45
o de Dados Figura 3.5: Protocolos de Replicac a
es feitas sobre a c As actualizac o opia prim aria s ao depois propagadas para as r eplicas o 3.6.2). (ver Subsecc a a simplicidade de implementac o. Os conA principal vantagem desta abordagem e a itos s ao detectados e resolvidos no prim ario. Do ponto de vista negativo, existe uma grande depend encia do sistema prim ario, resultando numa menor toler ancia a falhas. o Global Actualizac a es de leitura e escriNesta abordagem, tamb em designada de replicac a o o activa, as operac o ta dos dados podem ser feitas sobre qualquer uma das c opias f sicas. Assim, a manutenc a muito mais complexa porque, ao contr da consist encia e ario do cen ario anterior, n ao existe uma c opia prim aria. Todas as c opias f sicas funcionam como prim arias. A integridade garantida, uma vez que podem coexistir v dos dados n ao e arias c opias f sicas com um es completamente independente. historial de transacc o mantida com base em protocolos do tipo replicac A consist encia e a opias o activa, c dispon veis (ROWA) ou baseados em qu orums [97]. Este protocolo tem como vantagens um melhor balanceamento da carga e uma maior o. A toler ancia a falhas. Por outro lado, tem uma maior complexidade de implementac a o da consist manutenc a encia entre as diversas c opias exige protocolos sosticados.
3.6.2
o Propagac a
o da informac o entre as c Para a propagac a a opias f sicas, existem duas estrat egias poss veis: actualizac a ncrona (eager) ou actualizac a ncrona (lazy) (Figura 3.6) [48]. o s o ass S ncrona o s o dos dados e feita em simult No caso da propagac a ncrona, a alterac a aneo nas diversas es s o, c opias f sicas. As diversas actualizac o ao realizadas no contexto da mesma transacc a utilizando protocolos do tipo two-phase commit. o s A propagac a ncrona exige uma disponibilidade e resposta total por parte dos sis , por isso, de muito dif o em sistemas reais [76]. temas envolvidos e e cil implementac a
46
o S o Ass Figura 3.6: Propagac a ncrona e Propagac a ncrona o S o Ass Propagac a ncrona e Propagac a ncrona (adaptado de [48])
es de bloqueio (deadlocks) e transacc es abortadas s As situac o o ao frequentes [48]. Como aspecto positivo, esta abordagem tem a vantagem de oferecer um elevado n vel de consist encia dos dados. Ass ncrona o ass o pode terminar ap o de No caso da propagac a ncrona, a transacc a os a actualizac a es uma das c opias. As outras r eplicas s ao actualizadas de forma ass ncrona e em transacc o individuais. mais tolerante a falhas e adequada a sistemas que se pretendem Esta abordagem e pouco ligados/dependentes (loosely coupled). Tem uma melhor resposta porque se evitam o (commit). Do ponto as esperas associadas a protocolos com m ultiplas fases de nalizac a o e menor, pois est de vista negativo, a frescura da informac a a dependente de uma segunda o. fase de actualizac a
3.6.3 Iniciativa
` manutenc o da consist o distriUma terceira dimens ao, associada a a encia de informac a o de actualizac o. As actualizac es podem bu da, relaciona-se com a iniciativa da operac a a o es h ser enviadas (push) ou pedidas (pull). Tamb em existem soluc o bridas, que procu o de crit ram activar dinamicamente uma das alternativas em func a erios pr e-estabelecidos (como o r acio leitura-escrita) [28]. Envio es s Num cen ario de envio, tamb em designado por baseado no servidor, as actualizac o ao propagadas para as restantes r eplicas sem serem pedidas. O servidor com a c opia mais re o sobre as outras r o, encente mant em informac a eplicas e, quando existe uma actualizac a o. Esta noticac o pode ser imediata ou n via uma noticac a a ao e de dois tipos: invalidac a o ou actualizac a o.
3.7. ENTREGA DOS DADOS
47
o, e enviada a informac o nova; enquanto que, no caso da No caso da actualizac a a o, e enviada apenas uma indicac o de que a informac o foi alterada. Deinvalidac a a a o, as r o nova. O envio de pois de receber uma invalidac a eplicas pedem a informac a es pode ser comparado com a propagac o s es actualizac o a ncrona e o envio de noticac o o ass com a propagac a ncrona [72]. Numa arquitectura de envio dos dados, h a um uso eciente dos recursos. As inte es ocorrem apenas quando h es. Outro aspecto positivo e o facto da conracc o a alterac o o ser elevada. As outras r sist encia da informac a eplicas podem ser actualizadas assim que a melhor opc o acontece. E o quando o r alto. a primeira actualizac a a acio leitura-escrita e no entanto, uma soluc o mais complexa. Cada servidor tem de manter informac o E, a a es. H sobre o estado dos dados nas diversas r eplicas e iniciar todas as actualizac o a uma maior depend encia entre os participantes e, do ponto de vista tecnol ogico, s ao necess arias interfaces mais sosticadas. Com o aumento do n umero de r eplicas, existe um aumento o. da carga sobre o servidor que efectua a actualizac a Pedido Alternativamente, nesta abordagem tamb em designada por baseada no cliente, as actu es s o acontece no momento do pedido. alizac o ao pedidas pelas r eplicas. A actualizac a , por exemplo, o envio de pedidos com base numa periodicidade Uma estrat egia comum e pr e-estabelecida (um intervalo de pooling). o anterior, a informac neNeste caso, e ao contr ario da situac a a o de estado que e signicativamente menor. As r cess ario manter e eplicas apenas necessitam de saber qual uma abordagem mais o servidor que devem interrogar para obter a c opia mais recente. E baixo. Como as actualizac es s eciente quando o r acio leitura-escrita e o ao frequentes, o o que n menor. n umero de pedidos de informac a ao foi alterada e mais simples. Existe um maior desacoplamento No geral, a arquitectura do sistema e o dos custos de processamento; o que entre os participantes e uma melhor distribuic a resulta num maior potencial de crescimento. es, h Por outro lado, em muitas situac o a um desperd cio signicativo de recursos o. Em cen computacionais e de rede de comunicac a arios onde os dados t em poucas es, s o. actualizac o ao vulgares os pedidos de itens que n ao sofreram qualquer alterac a o e menor. Varia Tamb em como aspecto negativo, o n vel de consist encia da informac a o da frequ o pr em func a encia de actualizac a e-estabelecida (um valor dif cil de calcular).
3.7
Entrega dos Dados
Um outra dimens ao que permite classicar e distinguir sistemas distribu dos, est a relacionada com o que se designa por Esquemas de Entrega dos Dados. Entrega dos dados o de um conjunto de fontes pode ser denido como o processo de entrega de informac a o (servidores) para um conjunto de consumidores de informac o (clientes) de informac a a [65]. poss o E vel distinguir tr es caracter sticas que podem ser usadas para a comparac a entre mecanismos de entrega dos dados: protocolo, frequ encia e modo [42].
48
3.7.1 Protocolos
o (Pull): Neste caso, a transfer o e iniciada Pedido da Informac a encia da informac a recebido pelo servidor, a informac o e reunida e e pelo cliente. Quando o pedido e a enviada apenas para o cliente que fez o pedido. o (Push): Neste protocolo, a interacc o e iniciada pelo servi Envio da Informac a a o sobre o conjunto de clientes e, para cada novo dor. O servidor mant em informac a o, faz o envio para todos ou um subconjunto dos clientes. item de informac a
3.7.2
Frequ encia
o acontece em func o de eventos que ocor Aperi odico: Neste esquema, a interacc a a o (pull), a interacc o pode ser despoletarem. No cen ario de pedido da informac a a o do utilizador. No cen o (push), uma da por uma acc a ario de envio da informac a o aos dados pode iniciar a transfer o e a actualizac a encia. Um exemplo desta situac a o dos mercados de valores feita por um utilizador. consulta de informac a o Peri odico: Neste caso, a entrega dos dados ocorre segundo uma calendarizac a pr e-denida. Este intervalo de tempo pode ser xo ou incluir um factor aleat orio. o que se verica no envio de not E cias em intervalos regulares.
3.7.3 Modos
nica vez do servi Envio Unico (Unicast): Neste caso, os dados s ao enviados uma u dor para o cliente. Envios Multiplos (1-to-N ): Neste caso, a mesma fonte pode enviar dados para m ultiplos clientes (N). Existem dois subtipos de envios m ultiplos: multicast e broadcast.
3.7.4
o dos Esquemas Classicac a
apresentada uma classicac o com base nas tr Na Figura 3.7, e a es caracter sticas enumeradas antes. Nas folhas do diagrama est ao identicados v arios esquemas de entrega de dados.
3.8 Revis ao das Tecnologias

Do ponto de vista tecnol ogico, as primeiras abordagens ao problema da interoperabilida es de entre sistemas inform aticos t em origem na d ecada de 70; as primeiras especicac o o, faz-se uma breve EDI surgiram na ind ustria dos transportes dos EUA. Nesta secc a o de algumas das principais tecnologias; uma lista exaustiva de soluc es para apresentac a o o distribu o empresariais pode ser encontrada a comunicac a da entre sistemas de informac a em [67].
DAS TECNOLOGIAS 3.8. REVISAO
49
Figura 3.7: Esquemas de Entrega dos Dados Esquemas de Entrega dos Dados (Adaptado de [42])
3.8.1
EDI
uma designac o gen Electronic Data Interchange (EDI) e a erica, usada para referir os pro es electr tocolos que permitem levar a cabo transacc o onicas de documentos empresariais, entre parceiros. Na base do seu funcionamento, est a o envio de mensagens fortemente o 2.4.2) e que estruturadas segundo normas (p.e.: ANSI X21 e UN/EDIFACT, ver Secc a o humana [67]. Ao n o, s podem ser processadas sem intervenc a vel da comunicac a ao utilizadas redes de valor acrescentado (VAN) para a troca de mensagens entre os parceiros. o, seguranc Estas redes fornecem servic os como: autenticac a a, abilidade e integridade. Ver Figura 3.8 (adaptada de [67]). es EDI denem a sem Para al em da sintaxe, as especicac o antica das mensagens trocadas. Rera-se, a t tulo de exemplo, que o formato HL7 [54] foi criado por um conjunto de es ligadas a ` ind instituic o ustria da sa ude, com o objectivo de estabelecer os procedimentos e uxos para este dom nio.
Figura 3.8: Arquitectura EDI
Os protocolos EDI est ao bem estabelecidos na ind ustria na medida em que a infraes-
50
es de normas publicam e actualizam as especicac es e, uma trutura existe, as organizac o o vez implementados, permitem aos parceiros participar na troca de mensagens [9]. No ` implementac o destas soluc es s entanto, os custos associados a a o ao elevados, em particu o das VAN e de instalac o dos sistemas de integrac o lar devido aos custos de subscric a a a [77]. As pequenas empresas cam de facto exclu das destas parcerias. Nos EUA, 90% das empresas da Fortune 500 usam EDI, enquanto que das restantes 10 milh oes apenas 6% o usam [67]. ` s VAN, surgiram iniciativas que proNo sentido de reduzir o custo de uso associado a curam implementar o EDI sobre a Internet, como o EDIINT e o OBI. Em [67] pode ser o destas tecnologias. encontrada uma avaliac a
3.8.2
Componentes
es tecnol As evoluc o ogicas deram origem a novas abordagens ao problema da interoperabilidade. Estas iniciativas podem ser agrupadas numa categoria mais abrangente designada por arquitecturas baseadas em componentes [67]. Componentes s ao m odulos es existentes ou desenvolvidos de raiz e permitem que podem ser associados a aplicac o encapsular e disponibilizar funcionalidades. Podem ser implementados usando qualquer o e funcionam sobre infraestruturas (middlewares) que coordelinguagem de programac a o entre os componentes. nam a comunicac a
Figura 3.9: Arquitectura baseada em Componentes
A Figura 3.9 (adaptada de [67]) ilustra a estrutura geral de uma arquitectura baseada em componentes. Os m odulos implementados pelos parceiros comunicam, usando a infraestrutura disponibilizada pela tecnologia. Essa infraestrutura oferece servic os como o, mapeamento, seguranc es, etc. comunicac a a, transacc o As 3 mais importantes arquitecturas baseadas em componentes s ao [67]: Common Object Request Broker Architecture (CORBA)
DAS TECNOLOGIAS 3.8. REVISAO
51
uma norma publicada pelo Object Management Group (OMG), um conCORBA e s orcio internacional da ind ustria [75]. O n ucleo da infraestrutura s ao os ORB (Object Request Broker), que funcionam como n os intermedi arios e permitem a o entre os diversos componentes. A complexidade t comunicac a ecnica destas arqui elevada. tecturas e Distributed Component Object Model (DCOM) a tecnologia da Microsoft para a comunicac o Semelhante ao CORBA, DCOM e a distribu da baseada em componentes. Ao contr ario do CORBA, que n ao est a limitado ao n vel da plataforma, o DCOM foi desenvolvido para funcionar sobre es para outras platecnologia Microsoft Windows (existem algumas implementac o taformas). Enterprise Java Beans (EJB) o Na mesma linha das anteriores, as EJB s ao a aposta da Sun para a comunicac a o, esta arquitectura usa Java distribu da entre componentes. Ao n vel da comunicac a RMI. Apenas suporta Java como linguagem de desenvolvimento. o detalhada destas 3 tecnologias pode ser encontrada em [67]. Uma descric a o facto de se destinarem a ambientes Uma caracter stica comum a estas tecnologias e es longas. Enquanto que o EDI ataca o problema ao fortemente acoplados e a relac o n vel empresarial, com uma arquitectura baseada na troca de documentos, estas tecnolo es, resultando numa arquitectura mais apertada. gias funcionam ao n vel das aplicac o es com muitas limitac es em ambientes heterog S ao soluc o o eneos, din amicos e fortemente desacoplados [104], como o que se verica no contexto dos SIU.
3.8.3
Servic os Web
Com o desenvolvimento da Internet e das tecnologias paralelas, surgiram novas abor o. A ubiquidade dagens ao problema da interoperabilidade entre sistemas de informac a da rede das redes, indiferente a fronteiras empresariais ou tecnol ogicas, surge como o. Por outro lado, a evoluc o tecnol uma alternativa para a camada de comunicac a a ogica o generalizada da eXtensible Markup Language (XML), como linguagem de e a adopc a o de documentos, veio permitir o desenvolvimento de novas arquitecturas, acestruturac a tualmente designadas de Servic os Web (SW) (Figura 3.10). Haas [52] dene Servic o Web como um sistema inform atico identicado por um es s URI, cujas interfaces p ublicas e ligac o ao denidas e descritas usando XML. Estas es podem ser descobertas por outros sistemas inform denic o aticos. Estes sistemas podem depois interagir segundo as regras denidas, usando mensagens baseadas em XML, transportadas por protocolos Internet. o facto da comunicac o se basear, Uma caracter stica importante dos Servic os Web e a tal como no EDI, na troca de documentos, resultando numa arquitectura muito desacoplada.
52
Figura 3.10: Arquitectura baseada em Servic os Web
simples e poderosa, mas para uma real adopc o A ideia de XML sobre a Internet e a necess no mundo empresarial existem quest oes que e ario ultrapassar. Ao n vel da comu o, emergem quest nicac a oes como a seguranc a, a abilidade, a privacidade e a qualidade de servic o. Por outro lado, a linguagem XML permite apenas denir a sintaxe de um o das sequ documento; cam em aberto quest oes como a sem antica e a especicac a encias o empresarial. de mensagens numa comunicac a Assim, com o intuito de resolver este problemas, surgiram v arias iniciativas que, es de recomendac es e normas, procuram ultrapassar estas limitac es. atrav es da publicac o o o ltimos anos, tem-se assistido a uma multiplicac o exagerada de normas No entanto, nos u a es que, frequentemente, se sobrep o destas e especicac o oem, donde resulta que a adopc a tecnologias tem seguido um ritmo mais lento do que o esperado. A prop osito, Bussler o norma j o global e u nica [9]. arma que a designac a a n ao corresponde a denic a Apesar de tudo, os Servic os Web e as tecnologias associadas t em tido um forte apoio es inpor parte das principais empresas da ind ustria dos computadores e de organizac o dependentes como o W3C, que tem contribu do activamente para o desenvolvimento de es nesta a rea. especicac o
Cap tulo 4 o do Problema Denic a

apresentado o problema concreto de interoperabilidade entre sistemas de Neste cap tulo, e o universit informac a arios tendo como caso de estudo o cen ario da Universidade do Porto. o do problema foi feita uma estruturac o do dom Para a caracterizac a a nio em dois abordada a ligac o entre o n eixos. Segundo um eixo vertical, e a vel faculdade e o n vel o, comuniversidade, tendo como principal objectivo o estudo dos processos de agregac a o e disseminac o de informac o. Segundo o eixo horizontal analisa-se a partilha de posic a a a o entre faculdades, em particular informac o sobre os alunos. informac a a o, utilizados No nal, s ao seleccionados e apresentados quatro cen arios de aplicac a feita uma breve contextualizac o, s como casos de estudo. Para cada um dos casos, e a ao es reais de aplicac o e s apresentadas algumas situac o a ao denidos os requisitos.
53
54
DO PROBLEMA CAPITULO 4. DEFINIC AO
4.1
o do Contexto Apresentac a
uma universidade estatal, fundada a 22 de Marc A Universidade do Porto (UP) e o de 1911. composta por 17 unidades org E anicas, 14 equiparadas a faculdades e 3 n ao equiparadas, todas com autonomia pedag ogica, administrativa e nanceira, reunindo, no seu conjunto, mais de 25 mil alunos [29]. o de que disp Cada unidade gere de forma independente grande parte da informac a oe. feita localmente por cada uma das instituic es. A gest ao dos alunos, em particular, e o o inform A Reitoria da Universidade disponibiliza uma aplicac a atica para a gest ao de usada pela maioria das instituic es. O GAUP tem uma arquitectura alunos (GAUP), que e o o possui uma c o que se integra com uma base distribu da. Cada instituic a opia da aplicac a o s de dados local. Os dados existentes em cada instituic a ao, mensalmente ou sempre que necess ario, copiados de forma integral para a reitoria, que actualiza uma base de es usam sistemas pr o e dados central. Nos casos em que as instituic o oprios, esta integrac a efectuada manualmente e caso a caso. feita de forma Por outro lado, a gest ao dos recursos humanos de toda a Universidade e o desenvolvida internamente (GRHUP). As centralizada na Reitoria, usando uma aplicac a es n instituic o ao t em acesso directo aos dados. o, procur Tendo presente os objectivos desta dissertac a amos identicar quest oes rela o no contexto cionadas com a interoperabilidade entre os diversos sistemas de informac a es, universit ario. Com base nos v arios processos identicados e na natureza das organizac o deniram-se dois eixos de interoperabilidade: horizontal e vertical.
4.2
Eixos de Interoperabilidade
Figura 4.1: Interoperabilidade Vertical e Horizontal
4.2. EIXOS DE INTEROPERABILIDADE
55
4.2.1
Interoperabilidade Horizontal
o interoperabilidade horizontal identica os uxos entre as instituic es A designac a o acad emicas do mesmo n vel administrativo. Referimos, a t tulo de exemplo, a troca de o relativa a um curso entre duas faculdades (ver Figura 4.1). informac a poss E vel enumerar um conjunto de cen arios, que exemplicam a import ancia da interoperabilidade a este n vel entre SIU: o entre instituic es e cada vez mais frequente, nomeadamente na im A cooperac a o o de cursos ou projectos multi-disciplinares. Neste contexto, a partilha plementac a de dados de uma forma autom atica constitui um factor importante. Um exemplo o dos cursos partilhados por v es, em que a informac o concreto e arias instituic o a sobre os conte udos das disciplinas deve existir nos diversos SI. A possibilidade de mobilidade das pessoas dentro do espac o acad emico europeu e o de Bolonha [36]. A integrac o um dos principais objectivos resultantes da declarac a a um exemplo da necessidade de troca de de alunos do programa ERASMUS e o entre instituic es heterog informac a o eneas. o e desenvolvimento, a cooperac o entre No contexto dos nucleos de investigac a a es e vulgar e, muitas vezes, necess diferentes instituic o aria. Nestes ambientes, a comunicac ao e a partilha de documentos entre as partes envolvidas n ao pode cons o para o desenvolvimento da World tituir um obst aculo. Ali as, foi esta a motivac a o entre investigadores Wide Web, um projecto que envolvia a partilha de informac a de diferentes laborat orios do CERN [4].
4.2.2
Interoperabilidade Vertical
es acad Interoperabilidade vertical corresponde aos uxos existentes entre as instituic o e o entre micas em n veis administrativos diferentes. Por exemplo as trocas de informac a rg uma faculdade e os o aos centrais da universidade, ou entre um minist erio e a reitoria de uma universidade. (Figura 4.1). No meio acad emico, os uxos segundo o eixo vertical s ao mais frequentes do que os es do mesmo n existentes entre instituic o vel. Este padr ao resulta da natureza hier arquica, mas descentralizada, das estruturas acad emicas. O poder est a disperso por unidades inde rg es administrativas e coordenadoras pendentes, que recorrem a o aos centrais com func o (ver Cap tulo 2). o a este n No caso concreto dos sistemas de informac a vel, podemos distinguir um importante: conjunto de cen arios em que a interoperabilidade e o de informac o e uma necessidade frequente do ponto de vista A concentrac a a da universidade. A exist encia de sistemas heterog eneos dispersos pelas faculda des torna a tarefa complexa. E, por isso, evidente a import ancia da exist encia de mecanismos que permitam consultar de forma transversal todos os sistemas das diversas faculdades e que se revelam indispens aveis para responder a perguntas como Quais os enderec os de correio electr onico de todos os alunos da universidade?, ou simplesmente para obter a lista de todos os docentes da universidade.
56
DO PROBLEMA CAPITULO 4. DEFINIC AO As tarefas de gest ao administrativa de recursos humanos ou f sicos s ao muitas vezes centralizadas: a gest ao do pessoal docente e n ao docente, assim como a de vulgarmente efectuada ao n certos equipamentos e vel da universidade. No entanto, o sobre estes recursos deve existir de forma partilhada em ambos os a informac a o, da faculdade e da universidade. sistemas de informac a o do espac A concorr encia crescente, os cortes orc amentais e a uniformizac a o acad emico europeu constituem um incentivo para a aposta na qualidade. Esta aposta o do c passa frequentemente pela implementac a alculo de m etricas associadas aos o, dispersa pelas diversas cursos. Nesse sentido, o acesso a este tipo de informac a crucial. unidades da universidade, e o de informac o a n A agregac a a vel nacional constitui outro exemplo de interoperabilidade vertical. Em Portugal, o Observat orio da Ci encia e do Ensino Superior o de uma base de dados nacional com [25] tem um projecto que visa a constituic a o sobre as actividades acad informac a emicas desenvolvidas nas universidades portuguesas. A exist encia de pol ticas e mecanismos de interoperabilidade denidos rg entre os o aos de gest ao central e as universidades permitiria agilizar este processo.
o de Casos de Estudo 4.3 Selecc a

o, descrevemos quatro cen o, utilizados como casos de estudo. Nesta secc a arios de aplicac a Para o eixo horizontal, foi identicada a partilha do registo acad emico do aluno como o real e exemplicativa das interacc es existentes entre instituic es ao mesmo aplicac a o o n vel (Subsecc ao 4.3.2). es entre instituic es No caso do eixo vertical, foram identicados tr es tipos de interacc o o o, concentrac o e difus o. de n veis diferentes: agregac a a ao de informac a o de informac o existe nos cen o normalmente disA agregac a a arios em que informac a resumida num ponto central (p.e. num documento). Na Subsecc o 4.3.3, e como persa e a o para o eixo vertical, apresenta-se o caso da compilac o de esexemplo de agregac a a tat sticas relativas aos cursos e disciplinas. o de informac o e semelhante a ` agregac o, mas neste caso pretende-se A concentrac a a a o dispersa por v es e n replicar centralmente informac a arias instituic o ao resumi-la. Nes o das v te caso, ser a necess ario considerar a coordenac a arias entidades envolvidas. Na o 4.3.4 e apresentada a concentrac o de informac o sobre os recursos humanos Subsecc a a a o. de toda a universidade como exemplo deste tipo de interacc a o corresponde a interacc es no sentido contr A difus ao de informac a o ario, ou seja, da Universidade para as faculdades. Como caso de estudo refere-se a difus ao de not cias, o 4.3.5). produzidas na Reitoria, por toda a comunidade universit aria (Subsecc a
4.3.1
Requisitos Comuns
o, apresentam-se os requisitos comuns a todos os casos de estudo seleccionaNesta secc a nica composta por um c dos. Cada requisito tem uma refer encia u odigo e um n umero. Os c odigos t em o seguinte signicado: RF (Requisito Comum Funcional), RNF (Requisito Comum N ao Funcional), RHF (Requisito Horizontal Funcional) e RV1F, RV2F e RV3F
DE CASOS DE ESTUDO 4.3. SELECC AO
57
o (Requisitos Verticais Funcionais). Os requisitos verticais est ao estruturados em func a dos tr es casos de estudo. Os requisitos particulares de cada caso de estudo s ao apresentados junto do caso de estudo. A ordem pela qual os requisitos s ao apresentados n ao reecte nenhum grau de import ancia. Requisito RF1 : A autenticidade dos documentos deve ser garantida o : Descric a o nal deve incluir a descric o dos procedimentos a A especicac a a seguir, por cada uma das partes, de forma a garantir a autenticidade o trocada. da informac a
o deve ser garantida a Requisito RF2 : A integridade da informac o : Descric a o nal deve incluir a descric o dos procedimentos a A especicac a a seguir, por cada uma das partes, de forma a garantir a integridade da o trocada. informac a
Requisito RF3 :
Deve ser poss vel garantir a condencialidade de toda o ou parte da informac a
o : Descric a o nal deve incluir a descric o dos procedimentos a A especicac a a seguir, por cada uma das partes, de forma a garantir a condenci o trocada. Os intervenientes na comunicac o alidade da informac a a o cifrar. devem poder decidir que parte da informac a
Requisito RF4 :
o Qualquer idioma pode ser usado na informac a transmitida
o : Descric a o transmitida deve poder ser representada em qualquer A informac a idioma. o : Justicac a ` adopc o desta soluc o por parte de Reduzir os custos associados a a a es, portuguesas ou de outros pa outras instituic o ses.
58
DO PROBLEMA CAPITULO 4. DEFINIC AO o ao usar tecnologias fechadas na implementac a Requisito RNF1 : N o : Descric a o devem ser indepenAs tecnologias escolhidas para a implementac a o ou equipamendentes de fabricantes, linguagens de programac a es escolhidas devem ser baseadas em normas acretos. As soluc o es nacionais ou internacionais de normas, ou ditadas por organizac o por cons orcios industriais relevantes (como o W3C). o : Justicac a Eliminar depend encias face a fabricantes, tecnologias ou equipa` adopc o das tecnologias. mentos. Reduzir o risco associado a a
Requisito RNF2 :
es formais para as soluc es Apresentar especicac o o propostas
o : Descric a es formais para a Devem ser desenvolvidas especicac o o da informac o e para os mecanismos de interacc o representac a a a propostos nos diversos casos de estudo. o : Justicac a o aprovada serve de contrato enA exist encia de uma especicac a es aderentes e pode ser usada para validar e certicar tre as instituic o es. as diversas implementac o
Requisito RNF3 :
o e Os termos de controlo usados na codicac a o devem ser em Ingl comunicac a es
o : Descric a o ou transporte da Os termos de controlo, usados na codicac a o, devem ser representados usando o idioma Ingl informac a es. o : Justicac a O car acter internacional do projecto, em concreto a troca de registos mbito de programas de mobilidade internacional, acad emicos no a o. justicam esta opc a
DE CASOS DE ESTUDO 4.3. SELECC AO es normais, com as condic es Funcionar, em situac o o de conectividade existentes
59
Requisito RNF4 :
o : Descric a o proposta deve fazer uso das condic es de conectividade A soluc a o es. As tecnologias escoactualmente existentes entre as instituic o lhidas devem ser, preferencialmente, independentes da camada de transporte. o : Justicac a es dependentes de redes ou protocolos privados, controEvitar soluc o lados por empresas individuais ou pequenos grupos. A ubiquidade o e utilizac o justicam a da Internet e os baixos custos de instalac a a o por esta via. opc a
4.3.2 Partilha do Registo Acad emico do Aluno

o do Contexto Denic a o sobre todas as actividades acad O Registo Acad emico do Aluno re une informac a emicas de cada aluno, ao longo do seu percurso no ensino superior. Este registo acompanha-o usado, nomeadamente, para enviar informac o sobre a sua situac o em caso sempre e e a a es acad de transfer encia entre instituic o emicas. Geralmente, este registo n ao existe sob a nico; est forma de documento u a disperso por v arios documentos em diferentes servic os. A exist encia de um documento electr onico, escrito de acordo com regras bem denidas, que inclua todos os dados considerados essenciais, permite normalizar e automatizar o. A normalizac o acontece porque existe uma o processo de transfer encia de informac a a especicac ao para o registo acad emico do aluno que funciona como gram atica e permio e poss te o mesmo entendimento por parte de parceiros diferentes. A automatizac a vel ` exist porque, devido a encia deste documento bem denido, os dados podem ser proces o humana. A automatizac o pressup o pr sados sem intervenc a a oe uma normalizac a evia. o sobre o aluno inclui: A informac a o Demogr 1. Informac a aca: dados pessoais e identicadores. o sobre Saude : estado das vacinas e exames m 2. Informac a edicos. o sobre a Situac o Militar: situac o militar. 3. Informac a a a o Acad 4. Informac a emica: o sobre as provas realizadas no a mbito do acesso ao ensi(a) Ingresso: informac a no superior. es frequentadas, os graus atingidos, as dis(b) Historial Acad emico: as instituic o ciplinas e os resultados. o sobre pr (c) Pr emios Acad emicos: informac a emios acad emicos atribu dos.
60
DO PROBLEMA CAPITULO 4. DEFINIC AO o sobre actividades extra-curriculares 5. Actividades Extra-curriculares: informac a es, cursos). (projectos, associac o es: informac es extra, relevantes para o registo acad 6. Outras Informac o o emico.
o Cen arios de Aplicac a ` que se verica com o registo Troca de registos entre faculdades De forma an aloga a acad emico do aluno em papel, as escolas podem solicitar o envio de registos de alunos em formato electr onico. Este pedido pode efectuar-se durante o processo de transfer encia do aluno e o envio do documento electr onico pode ser feito em suporte f sico (disco) ou por transfer encia electr onica (Internet). O registo acad emico do aluno pode ser gerado de o ou produzido manualmente, de acordo forma autom atica por um sistema de informac a o. com a especicac a Troca de registos no contexto de programas de mobilidade internacional Durante um processo de interc ambio enquadrado nos programas de mobilidade (p.e. ERASMUS), es sobre os alunos. existe necessidade de trocar, entre as faculdades envolvidas, informac o o e um subconjunto daquela que e necess Esta informac a aria para o registo acad emico completo do aluno. es Considerac o o, apresenta-se um conjunto de quest ` proposta de um Nesta subsecc a oes associadas a o sobre os alunos. Os procesformato normalizado para a transfer encia de informac a sos de decis ao relativos a cada um dos pontos em an alise ser ao descritos aquando da o da soluc o. implementac a a o do Aluno Os sistemas de informac o necessitam de identicadores u nicos Identicac a a nepara representar pessoas ou documentos. No caso do registo acad emico do aluno, e cess ario denir uma forma de identicar univocamente cada estudante. Estes identicadores devem funcionar num contexto, preferencialmente, universal. es de um mesmo pa A troca de registos sobre alunos pode existir entre instituic o s ou de pa ses diferentes. Colocam-se v arias quest oes (embora algumas delas ultrapassem o mbito desta dissertac o): a a o e atribuic o dos identicadores? Quem deve ser respons avel pela denic a a O identicador deve ser privado ou pode ser disponibilizado publicamente? es, Qual o universo a que se destina este identicador: que alunos, que instituic o que graus e que pa ses? permanente ou pode ser alterado? O identicador e
DE CASOS DE ESTUDO 4.3. SELECC AO
61
o dos graus Graus Acad emicos No contexto nacional, existe uniformidade na denic a es regem-se por regras denidas pelo governo central. No entanacad emicos, as instituic o o o a mbito internacional, e necess o to, quando se toma em considerac a ario ter em atenc a o, em particular as equival as diferenc as entre os v arios sistemas de educac a encias entre o de Bolonha [36], com data de conclus os graus acad emicos. A declarac a ao dos trabalhos o do ensino superior xada para 2010, inclui entre os principais objectivos a uniformizac a na Europa. a adopc o de Uma das medidas consideradas como mais importantes neste cen ario e a um sistema de cr editos comum - Sistema Europeu de Transfer encia e Acumulac a o de Cr editos (ECTS1 ) [37]. Planos de Estudos Cada disciplina frequentada est a integrada num determinado plano de estudos. Os planos de estudo est ao associados aos cursos e s ao alvo de revis oes ` inclus ` eliminac o de peri odicas, que podem corresponder a ao de novas disciplinas ou a a outras. Assim, quando se comparam estudantes com o mesmo curso da mesma faculdade, poss e vel que o plano de estudos frequentado seja diferente. No plano de estudos de cada curso, s ao denidos os conte udos program aticos e os cr editos de cada uma das disciplinas que o integram. Quando se faz refer encia ao registo imprescind o sobre o plano de estudos acad emico de aluno, e vel considerar a informac a em que se enquadram as disciplinas frequentadas. Tamb em neste contexto se colocam algumas quest oes: O plano de estudos deve ser anexado integralmente ao registo acad emico do aluno ou apenas referenciado? o de informac o sobre todos os pla Quem deve ser respons avel pela disponibilizac a a nos de estudo de um curso? es No registo acad inclu o sobre a classicaClassicac o emico do aluno e da informac a o obtida em cada disciplina. Esta informac o e apresentada segundo uma escala, que c a a es, e imposs varia de pa s para pa s (em Portugal de 0 a 20). Sem mais informac o vel com es absolutas provenientes de diferentes contextos (faculdades, pa parar classicac o ses). o, e dif o de equival Acresce ainda que, apenas com esta informac a cil a atribuic a encias es. entre cursos ou instituic o o absoluta, o registo acad Assim, para al em da classicac a emico do aluno deve inte o que permita enquadrar esta classicac o num contexto mais abrangente. grar informac a a o de percentis para ultrapassar estes proO sistema de cr editos ECTS prop oe a construc a blemas. vulgarmente utilizado para transferir Equival encias O registo acad emico do aluno e o entre instituic es tendo em vista a possibilidade de atribuic o de equival informac a o a encias o, h entre disciplinas. Nesta situac a a quest oes (algumas j a mencionadas), a considerar: necess E ario distinguir alunos com percursos diferentes mas com conclus ao do cur o? so na mesma instituic a
1
Do Ingl es European Credit Transfer System.
62
DO PROBLEMA CAPITULO 4. DEFINIC AO Quando s ao atribu das equival encias para uma determinada disciplina, a classica o inicial e eliminada? c a equivalente a mais do Como gerir equival encias m ultiplas, quando uma disciplina e que uma? E quando acontece o caso contr ario? o quantitativa? O que fazer com disciplinas que habitualmente n ao t em classicac a
o A troca de registos a n mbito Internacionalizac a vel internacional, em particular no a dos programas de mobilidade, implica uma reex ao cuidada sobre outros problemas a ter em conta: o e que mecanismos de trans Que idioma deve ser usado para a meta-informac a miss ao? o entre os registos usados no contexto nacional e os que s Deve haver distinc a ao usados entre pa ses? Deve ser usado o mesmo formato em ambas as circunst ancias ou os registos devem ser diferentes? mbito do programa ERASMUS ter Os registos enviados no a ao requisitos demasiado espec cos, n ao contemplados nos registos usados internamente? o inclu A informac a da nos registos nacionais, irrelevante num contexto internacional, deve ser removida dos registos transmitidos? Seguranc a A seguranc a assume um papel importante num sistema de natureza distribu da. Neste caso, destacam-se, em particular, tr es vari aveis: autenticidade, integridade e condencialidade: o existente num Registo Acad Como garantir a veracidade da informac a emico do Aluno? Como distinguir os documentos genu nos dos fraudulentos? o consumida e igual a ` informac o produzida? Isto Como certicar que a informac a a , como impedir a exist e encia de erros na mensagem (acidentais ou intencionais)? necess O conte udo do Registo Acad emico do Aluno deve ser condencial? E ario ` informac o? implementar mecanismos que permitam controlar o acesso a a Do ponto de vista da condencialidade, o Registo Acad emico do Aluno deve ser o mais sens tratado de forma homog enea? H a informac a vel do que outra? Requisitos o, apresentam-se os requisitos para o cen Nesta secc a ario de interoperabilidade horizontal. Os requisitos est ao agrupados em duas categorias: requisitos funcionais e requisitos n ao funcionais.
DE CASOS DE ESTUDO 4.3. SELECC AO Requisito RHF1 : Identicar cada registo de forma universal o : Descric a nica cada registo acad Deve ser poss vel identicar de forma u emico. o deve ser v Esta identicac a alida no contexto internacional. o : Justicac a O documento que representa o registo acad emico do aluno pode exis o (p.e.: suporte magn tir fora dos sistemas de informac a etico), assim nica a entidade respons deve ser poss vel identicar de forma u avel o e o aluno a que se refere a informac o. A possipela informac a a bilidade de existir troca de registos de aluno entre pa ses, origina a o v necessidade de manter a identicac a alida entre pa ses.
63
o demogr Requisito RHF2 : Representar informac a aca sobre o aluno o : Descric a O registo acad emico do aluno deve incluir: Nome completo; N umero do Bilhete de Identidade; Local e data de emiss ao do Bilhete de Identidade; Local e data de nascimento; Nacionalidade; G enero; Estado Civil; o (Incluir, para cada um dos pais, informac Filiac a a o demogr aca b asica.); Morada; Telefone; Telem ovel; Correio electr onico; P agina Web.
64
DO PROBLEMA CAPITULO 4. DEFINIC AO o sobre a situac o militar do Representar informac a a aluno
Requisito RHF3 :
o : Descric a o sobre o estado O registo acad emico do aluno deve incluir informac a o militar do aluno, quando aplic da situac a avel.
Requisito RHF4 :
o sobre o registo de saude do Representar informac a aluno
o : Descric a o sobre as vaciO registo acad emico do aluno deve incluir informac a nas administradas e respectiva validade, bem como os resultados dos ` frequ exames m edicos necess arios a encia do ensino superior.
Requisito RHF5 :
o sobre as provas de ingresso Representar informac a efectuadas pelo aluno
o : Descric a o sobre as proO registo acad emico do aluno deve incluir informac a vas de ingresso realizadas para acesso ao ensino superior.
o acad Requisito RHF6 : Representar informac a emica sobre o aluno o : Descric a O registo acad emico do aluno deve incluir: es efectuadas pelo aluno, com informac o Matr culas e inscric o a o, o curso e o plano sobre o c odigo interno, o ano, a instituic a de estudos; o absoluta e tamb Disciplinas conclu das com informac a em relativa sobre os resultados obtidos; Graus acad emicos obtidos.
Requisito RHF7 :
o sobre pr Representar informac a emios acad emicos obtidos pelo aluno
o : Descric a o respons Sobre cada pr emio acad emico incluir: a instituic a avel pela o, o t atribuic a tulo, a data e o n vel do pr emio.
DE CASOS DE ESTUDO 4.3. SELECC AO o sobre actividades extraRepresentar informac a curriculares frequentadas pelo aluno o t tulo, uma
65
Requisito RHF8 :
o : Descric a Sobre cada actividade extracurricular incluir: o, a data de in descric a cio e a data de m.
Requisito RHF9 :
o, n Permitir representar outra informac a ao especicada, sobre o aluno
o : Descric a o n O registo acad emico do aluno deve permitir incluir informac a ao es). especicada sobre o aluno (p.e. observac o
o de Estat 4.3.3 Agregac a sticas sobre os Cursos

o do Contexto Denic a O acesso a dados estat sticos relativos ao funcionamento das faculdades, por parte dos rg uma necessidade fundamental para a tomada de deo aos centrais da Universidade, e o de estat cis ao. Neste caso de estudo, aborda-se a publicac a sticas pelas faculdades, rela o desta informac o pela Reitoria tivas ao desempenho dos cursos, e a posterior agregac a a da Universidade. o Cen arios de Aplicac a o relativa ao desempeAn alise comparativa de desempenho A exist encia de informac a es objectivas. nho dos cursos e disciplinas num formato normalizado permite comparac o es podem ser feitas entre cursos e disciplinas da mesma instituic o ou de Estas comparac o a es diferentes, ao n instituic o vel da Universidade. o de informac o ao n Agregac a a vel da Universidade Com as diversas faculdades a pu o estat poss blicarem informac a stica sobre os cursos e disciplinas, e vel, ao n vel da Unio versidade, agregar estes dados. Torna-se vi avel analisar de forma centralizada informac a poss tradicionalmente dispersa. Por outro lado, com base nestes dados, e vel produzir o. Por exemplo, com base nas estat nova informac a sticas individuais dos cursos e disci poss plinas disponibilizadas pelas faculdades, e vel produzir na Reitoria, estat sticas de desempenho sobre grupos de faculdades. es Considerac o o dos dados pode ser mais ou menos Granularidade dos Dados O n vel de agregac a poss o sobre detalhado. Por exemplo, e vel ir at e ao detalhe do aluno (reunindo informac a o relativa a ` m a nota de cada aluno), ou, pelo contr ario, armazenar apenas informac a edia necess dos nalistas do curso. E ario apurar que tipo de estat sticas se pretende calcular
66
o necess ao n vel da Universidade e disponibilizar a informac a aria. Os relat orios DIMAS o, a ` s instituic es de ensino superior no nal de solicitados, pelo Minist erio da Educac a o cada ano lectivo, s ao um bom ponto de partida. o dos Dados Um dos objectivos associado a ` compilac o de estat Normalizac a a sticas o c sobre os cursos e alculo de m etricas tendo em vista a an alise comparativa entre di pois, importante ter em atenc o a utilizac o de dados normaliferentes realidades. E, a a o a incluir, zados, pass veis de serem compar aveis. Depois de denir qual a informac a necess ` avaliac o da necessidade de normalizac o para cada um destes e ario proceder a a a valores. importante considerar a seguranc Seguranc a Tamb em neste caso e a dos dados segundo o 4.3.2: autenticidade, integridade e condencias 3 vertentes j a enumeradas na Subsecc a alidade. Requisitos o apresentam-se os requisitos para o caso de agregac o de informac o, no Nesta secc a a a contexto da interoperabilidade vertical. Requisito RV1F1 : Identicar cada curso de forma universal o : Descric a nica cada curso. Deve ser poss vel identicar de forma u
Requisito RV1F2 :
o repreIdenticar o per odo temporal da informac a sentada
o : Descric a o inclu relativa a uma edic o em parA informac a da sobre o curso e a necess ticular, que e ario explicitar.
DE CASOS DE ESTUDO 4.3. SELECC AO o sobre o curso a Requisito RV1F3 : Representar informac o : Descric a o do curso, deve existir a seguinte informac o: Sobre cada edic a a o interno; C odigo de identicac a Sigla; Nome; N umero total de docentes por g enero; Numerus Clausus; N umero de novos alunos; M edia, mediana, desvio padr ao, m nimo e m aximo das es de candidatura dos novos alunos; classicac o N umero de alunos que concluiram o curso; M edia, mediana, desvio padr ao, m nimo e m aximo das es dos alunos que concluiram o curso. classicac o
67
o de Informac o sobre os Recursos Humanos 4.3.4 Concentrac a a

o do Contexto Denic a o Apesar dos contratos de trabalho serem geridos ao n vel da Reitoria, a restante informac a reunida e mantida pelas pr es. Asrelativa aos docentes e funcion arios e oprias instituic o o no sentido da Reitoria para a concentrac o desta sim, s ao normais os uxos de informac a a o. Por exemplo, para a obtenc o dos contactos de todos os docentes. informac a a o de mecanismos de interoperabilidade, Neste caso de estudo, discute-se a construc a o que permitam normalizar e automatizar estes processos entre os sistemas de informac a o de informac o. de concentrac a a o Cen arios de Aplicac a o dispon Consulta de informac a vel nas faculdades A exist encia de mecanismos nor` informac o dispersa pelas faculdades elimina a necessidade de malizados para acesso a a o com cada uma das faculdades. Na Reitoria da Universidade, tratar isoladamente a ligac a o disponibilizada por cada instituic o, independentorna-se poss vel consultar a informac a a o existente nas faculdades, temente das infraestruturas e tecnologias usadas. A informac a sobre os docentes ou funcion arios, pode assim ser uniformemente acess vel do exterior, ` s restric es de acesso aplic sujeita a o aveis.
68
o de informac o ao n o de informac o Publicac a a vel da Universidade A concentrac a a o de novos sistemas que actualizada na Reitoria da Universidade permite a construc a o e a disponibilizem sob outras formas. Um exemplo poss fac am uso dessa informac a vel a apresentac o desta informac o no s o e a a tio Web da Universidade. Apesar da informac a poss ser gerida ao n vel das faculdades, e vel, desta forma, concentr a-la e apresent a-la a um n vel central. es Considerac o o e Integrac o Neste cen feito em tempo reCoordenac a a ario, o acesso aos dados e o est al. Ao contr ario do que acontece nos outros casos, a informac a a permanentemente trocada de forma autom es. Na concentrac o de dispon vel e e atica entre as instituic o a o, a coordenac o assume um papel importante, nomeadamente nos aspectos informac a a seguintes: o? Os da Como lidar com falhas ou erros de acesso aos dados de uma instituic a dos centralizados devem continuar dispon veis, mesmo desactualizados, ou deve o sistema ser interrompido? o devem ser capazes de descobrir e utilizar At e que n vel os sistemas de informac a o humana? as interfaces sem intervenc a o sobre como aceder a ` s interfaces das faculdades deve estar centraliza A informac a respons o? da na Universidade? Quem e avel pela sua manutenc a importante, as 3 vertentes j Seguranc a Neste caso, a seguranc a tamb em e a enumeradas o 4.3.2). nos casos de estudo anteriores devem ser avaliadas (ver Subsecc a Requisitos o, apresentam-se os requisitos para o caso da concentrac o de informac o, no Nesta secc a a a contexto da interoperabilidade vertical. Requisito RV2F1 : Identicar cada funcion ario de forma universal o : Descric a nica cada funcion Deve ser poss vel identicar de forma u ario.
DE CASOS DE ESTUDO 4.3. SELECC AO o sobre o funcion Requisito RV2F2 : Representar informac a ario o : Descric a o: Sobre os funcion arios, deve existir a seguinte informac a Sigla; Nome completo; N umero do Bilhete de Identidade; Local e data de emiss ao do Bilhete de Identidade; Data e local de nascimento; Naturalidade; G enero; o a que pertence; Instituic a Categoria; Estado; Contacto(s). ` informac o atrav Possibilitar o acesso a a es de interfaces acess veis por sistemas inform aticos
69
Requisito RV2F3 :
o : Descric a o sobre cada funcion A informac a ario deve estar dispon vel para consulta atrav es de interfaces acess veis por sistemas inform aticos. o : Justicac a o de informac o, sem necessidade Permitir automatizar a concentrac a a o humana. de intervenc a
4.3.5 Difus ao de Not cias da Universidade

o do Contexto Denic a ` agregac o e concentrac o, os uxos de informac o Nos cen arios anteriores referentes a a a a o existe nas faculdades e e consumida pela Reis ao no sentido da Reitoria. A informac a toria da Universidade. o e produzida peNo caso da difus ao, os uxos s ao no sentido contr ario, a informac a destinada a ` s faculdades, bem como a ` comunidade universit la Reitoria e e aria em geral. o de informac o, a partir da Reitoria da Universidade, permite, nomeaEsta disseminac a a
70
o de legislac o pelas diversas faculdades. Neste caso, s damente, a distribuic a a ao estudados o de not os mecanismos de distribuic a cias produzidas na Reitoria por toda a Universidade. o Cen arios de Aplicac a o controlada de not Disponibilizac a cias A exist encia de um sistema para a dissemi o de informac o a partir da Reitoria para toda a Universidade, permite simplicar e nac a a o das not o agilizar o processo de distribuic a cias produzidas centralmente. Esta distribuic a es seleccionadas; ou publicamente, dispode ser feita de forma controlada, entre instituic o ponibilizando e facilitando o acesso por parte de sistemas externos, sem qualquer v nculo ` Universidade. a es Considerac o o e recepc o de not o humana Falhas Neste processo de disseminac a a cias, a intervenc a ser a reduzida, sendo, portanto, imprescind vel avaliar os procedimentos a seguir em eventuais falhas. Por exemplo, quais devem ser os procedimentos quando houver falhas na o das not recepc a cias? A Reitoria dever a garantir a entrega, mesmo que mais tarde? o Como deve ser implementada a coordenac o entre a Reitoria e as faCoordenac a a es sempre que existem not culdades? Deve ser o n o central a enviar noticac o cias no` procura vas, ou devem ser os clientes a consultar periodicamente o sistema central a importante avaliar as interrupc es? E es originadas por cada uma destas de actualizac o o es. opc o o, o conte produziFiltragem Numa arquitectura baseada na difus ao de informac a udo e o (a que for do centralmente e os v arios clientes consomem apenas parte da informac a relevante para cada um). Assim, no caso das not cias difundidas pela Reitoria, pondera-se: o deve ser feita pela Reitoria ou pelos clientes? A ltragem da informac a o, como e que os clientes co Caso seja a Reitoria a gerir a ltragem da informac a municam os seus interesses? o de categorias denidas centralmente ser o? Neste caso, A utilizac a a uma soluc a como ser ao mantidas estas categorias? necess Seguranc a De forma an aloga ao que foi feito nos casos anteriores, e ario avaliar o 4.3.2). a seguranc a segundo os 3 eixos j a enumerados (ver Subsecc a Requisitos o, apresentam-se os requisitos denidos para o caso da difus o, Nesta secc a ao de informac a no contexto da interoperabilidade vertical.
DE CASOS DE ESTUDO 4.3. SELECC AO `s Permitir o acesso, por parte das faculdades, a not cias publicadas pela Reitoria
71
Requisito RV3F1 :
o : Descric a As faculdades devem poder consultar as not cias publicadas pela Reitoria.
o sobre cada not Requisito RV3F2 : Representar informac a cia o : Descric a Relativamente a cada uma das not cias deve estar dispon vel a se o: guinte informac a o e expirac o; Data de publicac a a T tulo; Corpo; Nome do autor/emissor; o directa para uma p Ligac a agina Web correspondente a esta not cia.
72
Cap tulo 5 Arquitectura

denida a arquitectura do sistema. Na primeira secc o (5.1), e apresenNeste cap tulo, e a tada a arquitectura para o cen ario de interoperabilidade horizontal. No caso da interopera o 5.2), s es tomadas para cada um dos cen bilidade vertical (Secc a ao descritas as opc o arios o, concentrac o e difus o. denidos: agregac a a ao de informac a
73
74
CAPITULO 5. ARQUITECTURA
5.1
Interoperabilidade Horizontal
o Introduc a No caso da interoperabilidade horizontal, existe uma grande diversidade de cen arios o pontual entre instituic es, poss veis; desde simples arquitecturas de troca de informac a o o em tempo real entre faculdades de at e complexos sistemas de partilha de informac a es ao n v arios pa ses. S ao v arios os par ametros que podem inuenciar as opc o vel da arquitectura do sistema, em particular dos mecanismos de partilha. ` interoperabilidade horizontal de Assim, n ao se incluem, aqui, decis oes relativamente a es tecnol um ponto de vista gen erico. Uma an alise geral sobre as opc o ogicas em ambientes distribu dos pode ser encontrada no Cap tulo 3. o sobre alunos, en analisada a situac o concreta de partilha de informac Aqui, e a a tre faculdades. Pretende-se, neste caso, um sistema que permita disponibilizar de forma o sobre um conjunto de alunos. Procura-se conintegrada e, em v arios pontos, informac a centrar em v arios pontos esse conjunto de dados. o que det o sobre os alunos Neste caso, existe um servidor - a instituic a em informac a es que pretendem partilhar esta informac o. Em relac o a ` e v arios clientes - as instituic o a a o, h o sobre um estudante, informac a a um mapeamento de um-para-muitos. A informac a o, e partilhada em v existente numa instituic a arios locais. No entanto, este padr ao n ao o de difus o, j o e permanente corresponde a uma situac a ao de informac a a que a informac a e os clientes podem actualiz a-la. o dos Dados Colocac a ` estrat o dos dados e neste caso, h Relativamente a egia de colocac a a uma correspond encia directa entre os dados nos servidores e os dados no cliente. Por outro lado, sobre os mes es de consulta. Assim, opta-se por manter mos dados podem ser realizadas v arias operac o es c opias da informac a encia de v arias representac o o nas faculdades, permitindo a exist f sicas de cada registo de aluno. Consist encia dos Dados o obriga a ` denic o de uma A exist encia de m ultiplas c opias f sicas da mesma informac a a o da consist estrat egia para a manutenc a encia dos dados. Uma estrat egia deste tipo est a o e iniciativa (ver Secc o 3.6). organizada em tr es vertentes: protocolo, propac a a Em primeiro lugar, prop oe-se um protocolo do tipo actualizac a ario. Para o no prim estabelecida uma c o que e respons cada registo e opia prim aria, gerida pela instituic a avel o. As operac es de leitura s pela informac a o ao feitas sobre a c opia local, enquanto que es de actualizac o apenas podem ser feitas sobre a c o as operac o a opia prim aria. A opc a o global, iria aumentar em muito a complexidade do sistema. alternativa, de actualizac a o de inconsist Seria necess ario introduzir protocolos para a resoluc a encias. o a ` propagac o, opta-se pela alternativa ass Em relac a a ncrona. O sucesso da actua o na c es de r lizac a opia prim aria n ao pode depender de actualizac o eplicas remotas. Por o de uma maior outro lado, o sincronismo das diversas c opias pode ser relaxado em func a exibilidade.
5.2. INTEROPERABILIDADE VERTICAL
75
o, opta-se pelo envio das actualizac Ao n vel da iniciativa da actualizac a o es. A justi o baseia-se no facto do r cac a acio leitura-escrita ser alto, e, consequemente, haver um melhor aproveitamento da rede. Conclus oes o sobre alunos entre faculdades, o concreta de partilha de informac Para a situac a a prop oe-se: Para cada registo, deve ser especicada qual a c opia prim aria. es envolvidas Devem ser criadas c opias f sicas de cada registo nas v arias instituic o na partilha. es de leitura do registo s As operac o ao sempre feitas sobre a c opia local, enquanto es de escrita s que as operac o ao feitas na c opia prim aria. mantida atrav A coer encia das diversas c opias f sicas e es do envio de mensagens de o ass actualizac a ncronas, a partir do servidor que det em a c opia prim aria. descrita a implementac o desta arquitectura, as opc es tecnol No Cap tulo 6, e a o ogicas o da informac o. tomadas e as decis oes ao n vel da camanda de representac a a
5.2
Interoperabilidade Vertical
o, descrevem-se as opc es tomadas relativamente a ` arquitectura do sistema Nesta secc a o ` interoperabilidade vertical. Os conceitos de cliente e servidor para os casos associados a o. Com base em Kossmann [61], s ao utilizados com frequ encia ao longo desta secc a consideram-se as seguintes denic oes: es aos dados, para consulta ou Cliente - Sistema onde s ao denidas as interrogac o processamento. Funciona como consumidor dos dados. Por exemplo, no caso o de informac o sobre recursos humanos, a Reitoria da concreto da concentrac a a Universidade funciona como cliente. Servidor - Sistema onde os dados s ao armazenados ou produzidos. Funciona como o de not fonte dos dados. Por exemplo, no caso concreto da disseminac a cias pelas faculdades, a Reitoria da Universidade funciona como servidor. o da arquitectura do sistema distribu o 3.2), a interacc o pode Em func a do (ver Secc a a ser iniciada por qualquer uma das partes.
76
o de Informac o 5.2.1 Agregac a a

o Introduc a o armazena e e respons o reNo contexto acad emico, cada instituic a avel pela informac a ` s suas actividades. Pretende-se implementar um sistema distribu lativa a do que permita o num ponto central. Esta informac o pode ser local - referente agregar esta informac a a o; ou global - referente a um conjunto de dados que apenas aos dados de uma instituic a ` mesma instituic o. podem pertencer, ou n ao, a a Este cen ario constitui uma arquitectura do tipo cliente-servidor - um sistema (cliente) o enviando um pedido a outro sistema, o servidor, que envia uma resposta inicia a interacc a ` instituic o que pretende agregar a informac o e a este pedido. O cliente corresponde a a a ` s instituic es que armazenam os dados. Este e um caso os servidores correspondem a o o vai ser particular uma vez que existe apenas um cliente - o ponto onde a informac a o de muitos para um, entre os dados originais e os dados agregada. Existe uma relac a ilustrada esta situac o. agregados. Na Figura 5.1, e a
o de Informac o Figura 5.1: Agregac a a
o entre sistemas distribu o das Kossmann [61] estabelece uma distinc a dos em func a capacidades dos servidores. Duas categorias s ao identicadas: sistemas homog eneos e sistemas heterog eneos. Num sistema homog eneo, os diversos servidores t em funcionalidades e capacidades equivalentes (p.e. s ao implementados sobre um modelo de dados comum). Num sistema heterog eneo, cada servidor tem caracter sticas diferentes. O nosso heterog es usam o mesmo SI. caso e eneo, pois nem todas as instituic o um cen Resumindo, este e ario do tipo cliente-servidor onde existe apenas um cliente e es podem ser locais m ultiplos servidores. Os servidores s ao heterog eneos e as interrogac o ou globais. o dos Dados Colocac a o din A colocac a amica dos dados pode ser feita segundo tr es alternativas, j a expostas na o 3.5. Neste caso, a melhor opc o vai depender das carater es a secc a a sticas das interrogac o
77
es, com base processar. Num primeiro n vel, podemos distinguir dois tipos de interrogac o nos dados de que necessitam. Aquelas que s o podem ser processadas movendo os dados para o cliente, e aquelas que podem ser processadas no cliente ou nos servidores. o do primeiro tipo e o c o dos Um exemplo de uma interrogac a alculo da distribuic a mbito da universidade. N poss alunos por percent s no a ao e vel calcular percent s parciais necess o para o cliente e a e depois agregar os dados. E ario mover toda a informac a fazer o processamento. es podem ser processadas no cliente ou nos servidoNos casos em que as interrogac o o da interrogac o e custo de transfer res, h a dois factores principais: custo de execuc a a encia es acad dos dados. A capacidade de processamento existente nas instituic o emicas n ao e um crit erio determinante. Ao longo dos anos, tem-se assistido ao aumento da capacidade de processamento dos sistemas inform aticos, associado a uma descida dos prec os. o da comunicac o correspondente a ` transfer Assim, o custo determinante e a encia dos o [84]. A dados. Testes realizados por Rodriguez-Martinez conrmam esta armac a o dos dados ter colocac a a como objectivo minimizar o volume total de dados a transferir. o do efeito que t Rodriguez-Martinez distingue dois tipos de operadores em func a em sobre o volume dos dados originais [84]. Refere, por um lado, operadores de expans ao es ou rotac es que aumentam o n umero ou dimens ao dos tuplos no resultado (p.e. projecc o o de dados) e, por outro, operadores de reduc a o que reduzem os dados originais para es muito menores. Assim, o crit o dos dados e abstracc o erio que vai determinar a colocac a o realizada pela interrogac o (reduc o ou expand o tipo de operac a a a ao). vantajoso em cen Por outro lado, o envio dos dados tamb em e arios onde v arias inte es s rrogac o ao aplicadas sobre o mesmo conjunto de dados. Em vez de enviar v arias vezes o de caches no cliente permite melhorar o desempenho os mesmos dados, a manutenc a global do sistema [62]. Eis dois exemplos onde o envio dos dados seria vantajoso: o as u ltimas not o para Imagine-se a interrogac a cias publicadas numa instituic a mais cada categoria. Cada not cia pode pertencer a m ultiplas categorias. Assim, e barato enviar para o cliente a lista de todas as not cias, todas as categorias e as es existentes e depois fazer o desdobramento por categorias; do que, em relac o alternativa, fazer o processamento no servidor e enviar v arias listas de not cias por cada categoria. es a serem aplicadas a uma lista de alunos de um Considerem-se v arias interrogac o curso: lista de alunos ordenada alfabeticamente, lista de alunos ordenada por es totais, etc. Neste caso, e m edia nal, lista de alunos ordenada por inscric o evidentemente mais vantajoso mover os dados para a cache do cliente e a fazer as es. v arias interrogac o Concluindo, deve ser adoptada uma estrat egia do tipo envio da interrogac a o quando a o da interrogac o produz uma reduc execuc a a a o do volume de dados original. Alternativao mente, deve ser adoptada uma estrat egia do tipo envio dos dados quando a interrogac a es s provoca um aumento no volume de dados; ou quando v arias interrogac o ao executadas sobre os mesmos dados (p.e. an alise de dados).
78
o h O sistema MOCHA [84] adopta uma soluc a brida que, com base num par ametro designado por Factor de Reduc a o de Volume , selecciona um dos dois mecanismos. o Interfaces de Comunicac a o a ` capacidade dos sistemas, e como j heterog Em relac a a foi referido, este cen ario e eneo. o das faculdades s Os sistemas de informac a ao independentes e as caracter sticas de cada o, desconhecidas. Para estes casos, a tend a de tentar reduzir implementac a encia geral e o de interfaces de este problema a um de sistemas homog eneos atrav es da implementac a conseguida, impondo um modelo de dados acesso comuns [61]. A homogeneidade e global sobre o modelo de dados local usado por cada servidor [84]. Assim, os servidores devem implementar interfaces comuns que permitam ao cliente interagir da mesma forma com todos eles. Sincronismo Este caso constitui um sistema cl assico do tipo pedido-resposta: pedidos aperi odicos num o de um sistema despadr ao 1-1 (cada pedido gera uma resposta) [42]. A implementac a o refte tipo pode seguir uma de duas abordagens: s ncrona ou ass ncrona (ver secc a ` espera da(s) sec:Sincronismo). No primeiro cen ario, o cliente faz o pedido e bloqueia a resposta(s). No caso ass ncrono, o cliente emite o pedido e n ao ca bloqueado; num momento posterior, o servidor envia a resposta. o de informac o, opta-se por um sistema com pedidos s Na agregac a a ncronos. A prin o para esta opc o e a maior facilidade de implementac o. Apesar de recipal justicac a a a sultar numa arquitectura mais acoplada do ponto de vista temporal, a depend encia tec menor. nol ogica e Conclus oes o de informac o entre instituic es acad Resumindo, para o cen ario de agregac a a o emicas, prop oe-se: es a efectuar Uma arquitectura do tipo envio da interrogac a o o, quando as operac , casos onde o volume de dados iniciais e reduzem o volume de dados inicial. Isto e maior do que o volume de resultados. es Uma arquitectura do tipo envio dos dados em tr es casos: quando as interrogac o s o podem ser processadas desta forma, quando aumentam o volume de dados ou es que v quando fazem parte de um conjunto de interrogac o ao ser aplicadas sobre os mesmos dados. o de um A especicac a a o de interfaces procedimentais (API) para a implementac mecanismo de processamento distribu do homog eneo entre os servidores. o dos pedidos e respostas. Uso de um mecanismo s ncrono para a implementac a
5.2. INTEROPERABILIDADE VERTICAL Caso de Estudo
79
o de informac o estat um caso parO caso de estudo - agregac a a stica sobre cursos - e o de informac o. Assim, as v es expostas na secc o anticular da agregac a a arias opc o a o a ` colocac o dos dados, opta-se pelo processamento da terior mant em-se. Em relac a a o no servidor (envio da interrogac interrogac a a alculo de estat sticas envolve o), porque o c es que t es muito menores dos dados originais operac o em por objectivo produzir abstrac o o de reduc o. Com esta opc o, os custos de comunicac o s - operac a a a a ao menores, relativa` alternativa de envio dos dados. mente a
5.2.2
o de Informac o Concentrac a a
o Introduc a o de informac o pretende-se disponibilizar, de forma integrada e num Com a concentrac a a nico sistema, toda a informac o existente sobre um determinado dom u a nio. Esta informa c ao existe de forma distribu da, dispersa por v arias instituic oes. es que det o - e apeNeste caso, existem v arios servidores - as instituic o em a informac a o. Aqui, e ao contr o nas um cliente, que corresponde ao ponto de integrac a ario da situac a o e de um-para-um. Para cada item existente nos anterior, o mapeamento da informac a o. servidores, existe um acesso no sistema que faz a integrac a o dos Dados Colocac a ` estrat o dos dados, neste caso n Relativamente a egia de colocac a ao existe nenhum factor de reduc a a a uma o que justique uma abordagem do tipo envio da interrogac o. H correspond encia directa entre os dados nos servidores e os dados no cliente. Por outro o do caso de estudo, ser realizadas v lado, sobre os mesmos dados podem, em func a arias es. interrogac o o, opta-se por manter Assim, para evitar lat encias e reduzir os custos de comunicac a es c opias da informac a ogico, podem existir duas representac o o no cliente. Para cada dado l f sicas. Consist encia dos Dados o, e necess Como existem v arias c opias f sicas da mesma informac a ario denir uma es o da consist trat egia para a manutenc a encia dos dados. Esta estrat egia envolve tr es di o e iniciativa (ver Secc o 3.6). mens oes: protocolo, propac a a o ao protocolo, prop Em relac a oe-se um abordagem do tipo actualizac a ario. o no prim sempre feito sobre a c Do ponto de vista do cliente, o acesso para leitura e opia local, sobre o servidor - na c o enquanto que o acesso para escrita e opia prim aria. Esta opc a o. reduz a complexidade do sistema e optimiza os custos de transfer encia de informac a o, opta-se pela alternativa ass Ao n vel da propagac a ncrona. Desta forma, a arqui mais tolerante a falhas e desacoplada. As actualizac es locais, feitas tectura do sistema e o nos servidores, n ao podem depender da disponibilidade da rede e do sistema cliente para o da c o independente, terem sucesso. Ap os a actualizac a opia prim aria, e numa transacc a actualizado. o cliente e
80
o a ` iniciativa da actualizac o, a opc o vai depender do r Em relac a a a acio leitura-escrita o em concreto. Um valor elevado, corresponde a um cen da situac a ario onde o n umero es de leitura sobre a informac o e muito superior ao n es de operac o a umero de operac o o. Um valor baixo, corresponde a uma situac o onde as operac es de de actualizac a a o o s o a ` s operac es de leitura. actualizac a ao frequentes em relac a o Assim, para cen arios com um r acio elevado, prop oe-se uma estrat egia do tipo envio es. Alternativamente, em situac es onde o r das actualizac o o acio e oe-se o pequeno, prop es pelo cliente. pedido das actualizac o es minimizam os custos de comunicac o. Quando as operac es de leituEstas opc o a o o que n ra s ao muitas, evitam-se os pedidos de informac a ao foi alterada. Neste caso, o es. Quando s es de escrita, evita-se a avaservidor envia as actualizac o ao mais as operac o es associadas ao envio das muitas actualizac es. Aqui, lanche de mensagens e interrupc o o es. o cliente pede as actualizac o o a ` opc o entre envio das actualizac es ou envio de noticac es, opta-se Em relac a a o o menor. O envio de pela primeira hip otese porque o n umero de mensagens trocadas e es e uma opc o mais interessante quando o volume dados em cada mensagem e noticac o a es s elevado, e as actualizac o ao muito frequentes. Conclus oes o da informac o, prop Resumindo e sistematizando, para o caso da concentrac a a oe-se: o de c A manutenc a opias f sicas da informac a aria) e nos servido o no cliente (prim res (r eplica). es ass O uso de um protocolo do tipo actualizac a ario, com propagac o n o no prim o. cronas, para a gest ao da consist encia da informac a alto. Uma iniciativa do tipo envio das actualizac o acio leitura-escrita e es, quando o r pequeno. Uma iniciativa do tipo pedido dos dados, quando o r acio leitura-escrita e Caso de Estudo o de informac o sobre recursos humanos, o ao caso de estudo - concentrac Em relac a a a viabilizar a centralizac o, na Reitoria da Universidade (cliente), de dados o objectivo e a ` s diversas instituic es que integram a Unireferentes aos recursos humanos associados a o o est es. Cada versidade (servidores). A informac a a estruturada pelas diversas instituic o o armazena e e respons o relativa a ` actiinstituic a avel por parte signicativa da informac a vidade dos seus recursos humanos. o de informac o, adoptam-se as opc es Sendo este um caso particular da concentrac a a o es anteriores. No ponto particular da iniciativa da propagac o, o expostas nas subsecc o a relativamente elevado. As consultas sobre informac o relativa aos r acio leitura-escrita e a mais frequente do que as alterac es feitas a estes dados. Assim, recursos humanos e o prop oe-se o envio das actualizac o es.
81
5.2.3
o Difus ao de Informac a
o Introduc a o existe num u nico servidor e pretende-se dissemin Neste caso, a informac a a-la por v arios multiplicado e distribu clientes. E um cen ario onde um item e do por v arios clientes o e produzida pelo servidor e os clientes - padr ao do tipo um para muitos. A informac a es de leitura. apenas podem realizar operac o o: difus Neste contexto, distinguimos dois tipos de difus ao de informac a ao controla es seguintes, apresentam-se estes dois cen da e difus ao p ublica. Nas subsecc o arios e as arquitecturas propostas. Difus ao Controlada o limitada e bem conhecida a ` priori. O Neste caso, os clientes constituem uma populac a servidor conhece os clientes e as necessidades de cada um. Pode estabelecer, internamen o e cada um dos clientes. Por outro lado, com uma te, um mapeamento entre a informac a o. difus ao controlada, pretende-se garantir a entrega da informac a ` entrega dos dados foram expostas na Secc o 3.7. Para a diAs alternativas relativas a a o, opta-se por uma abordagem do tipo envio da informac fus ao controlada de informac a a o o e iniciada pelo servidor e a informac o e enviada de forma aperi odica - a interacc a a quando surge. o e justicada pelos seguintes argumentos: Esta opc a poss o entre o servidor e os clientes. In E vel garantir a consist encia da informac a es, n o perdida. dependentemente da periodicidade das actualizac o ao h a informac a o da rede e optimizada. Todas as mensagens que circulam s A utilizac a ao relevantes o nova. e cont em informac a reduzido e conhecido a ` partida. Por isso, o esforc O n umero de clientes e o com o (estado dos clientes) e previs putacional e de armazenamento de informac a vel e control avel. o, opta-se por uma soluc o ao sincronismo da interacc Em relac a a a ncrona de o ass ` maior toler ` melhor adequac o a cen ` vido a ancia a falhas, a a arios um para muitos e a o da maior escalabilidade [76]. Num cen ario s ncrono, a falha de um cliente na recepc a o e uma situac o cr informac a a tica, que tem impacto sobre todo o sistema. Difus ao Publica o por uma populac o interessada em Neste cen ario, pretende-se disseminar a informac a a o, mas desconhecida a ` priori. N receber a informac a ao s ao conhecidos os interesses nem um requisito, o acesso a ` informac o o n umero de clientes. A entrega garantida n ao e a o e p necess depende do cliente. Como a informac a ublica, n ao e ario controlo de acessos. Para a entrega dos dados, prop oe-se uma arquitectura do tipo pedido da informac a o o e iniciada por cada cliente em qualquer momento. de forma aperi odica - a interacc a Esta arquitectura justica-se porque:
82
CAPITULO 5. ARQUITECTURA o n um requisito - o o nus e deslocado para o cliente. A consist encia da informac a ao e o e fundamental. O n desconhecido e A escalabilidade da soluc a umero de clientes e o, o servidor n com vontades heterog eneas. Com esta opc a ao necessita de manter o de estado, nem de processar o envio de cada mensagem. informac a
o, opta-se por uma soluc o ao sincronismo da interacc Em relac a a a ncrona. Com o s o sobre cada pedido a alternativa ass ncrona, o servidor seria obrigado a manter informac a para poder enviar a resposta. Desta forma, a escalabilidade do sistema seria prejudicada. Casos de Estudo o, existem dois casos de estudo: difus No caso da difus ao de informac a ao controlada de not cias pelas faculdades e difus ao p ublica de not cias (Figura 5.2).
o - Instituic es da Universidade e P Figura 5.2: Difus ao de Informac a o ublico em Geral
No caso da difus ao controlada de not cias pelas faculdades, pretende-se disponibi es da Universidade (clientes). lizar not cias, a partir da Reitoria (servidor), pelas instituic o es e feito na Reitoria. O mapeamento entre as not cias e as instituic o o proposta - envio da informac o de forma aperi A soluc a a odica e ass ncrona - permite poss o das not o da instituic o de destino. E controlar a distribuic a cias em func a a vel, por es. No entanto, exemplo, enviar um item apenas para uma ou um conjunto de instituic o o de granularidades mais nas, como enviar, por exemplo, um item para uma a utilizac a o dentro de uma instituic o, torna-se imposs secc a a vel. Para tal, seria necess ario que a Rei o sobre a estrutura interna de cada instituic o. Uma abordagem toria mantivesse informac a a o e utilizac o de meta-informac o, recorrendo, por exemplo, a onposs vel seria a denic a a a o ultrapassa largamente o a mbito desta dissertac o e n tologias. Esta opc a a ao ser a, por isso, explorada. o noticiosa - pretende-se No outro caso de estudo - difus ao publica de informac a permitir ` a comunidade em geral ter acesso, de forma program atica, a um subconjunto das not cias produzidas. o que pretende colocar ao dispor da comuniNeste caso, o servidor publica a informac a o que pretendem. dade. Os clientes pedem ao servidor, em qualquer momento, a informac a o pode ser disponibilizados de forma permanente ou durante um per A informac a odo de tempo espec co, dependendo da sua natureza. Para o caso das not cias, prop oe-se um intervalo m nimo mensal.
83
Com o objectivo de facilitar a interoperabilidade e minimizar o impacto sobre os cli es p o da informac o. entes, prop oe-se o uso de especicac o ublicas para a representac a a ` Assim, os clientes n ao necessitam de desenvolver interfaces espec cas para aceder a o publicada. informac a
84
Cap tulo 6 o Implementac a

apresentada a implementac o dos casos de estudo seleccionados. Depois Neste cap tulo, e a ` s opc es e convenc es t de uma breve refer encia a o o ecnicas, o cap tulo est a estruturado em o dos casos de estudo: partilha do registo acad o de func a emico do aluno (6.3), agregac a o de informac o sobre os recursos humanos estat sticas sobre cursos (6.4), concentrac a a feita uma (6.5) e difus ao de not cias da universidade (6.6). No nal do cap tulo (6.7), e breve refer encia aos prot otipos implementados.
85
86
CAPITULO 6. IMPLEMENTAC AO
6.1
es Tecnol Opc o ogicas
6.1.1 XML Schema

o dos dados, optou-se por usar a linguagem XML Schema [38]. A Para a representac a actualmente a norma de facto para a representac o de informac o eslinguagem XML e a a ` alternativa - Document Type Denition (DTD), a opc o e justicada truturada [67]. Face a a com base nos seguintes argumentos: o O XML Schema permite usar namespaces, o que possibilita uma melhor estruturac a dos documentos. O XML Schema oferece uma gama de tipos de dados base mais abrangente do que oferecida pelos DTD. Com XML Schema e ainda poss a que e vel denir tipos pr oprios. o dos documentos. O XML Schema permite um maior controlo na validac a o de dados, baseado em conceitos O XML Schema tem um mecanismo de reutilizac a oferecido pelos DTD. orientados a objectos (OO), mais sosticado do que o que e Os documentos em XML Schema s ao documentos XML bem formados, enquanto que os DTD s ao expressos usando outra sintaxe (EBNF). Quando se usam DTD, necess e ario dominar duas linguagens distintas. usado e suportado por v es. O XML Schema e arias organizac o o foi tomada no contexto de outras iniciativas, como e o caso no PESC A mesma opc a [22]. es que se integram com a linguagem XML Existem, por outro lado, muitas especicac o es XML-Signature [14] e e permitem adicionar novas funcionalidades. As especicac o XML-Encryption [13] s ao um exemplo. A primeira permite associar assinaturas digitais a qualquer conte udo em XML. A segunda permite cifrar dados (desde documentos XML a elementos individuais) e representar o resultado em XML. Estes mecanismos permitem cumprir os requisitos de autenticidade, integridade e condencialidade estabelecidos no Cap tulo 4. o trocada enConcluindo, opta-se pelo XML Schema para representar a informac a es. Em concreto, usam-se documentos XML para representar: o registo tre as instituic o o sobre recursos humanos acad emico do aluno, as estat sticas sobre os cursos, a informac a e os itens noticiosos.
6.1.2 Servic os Web

o dos mecanismos de interacc o entre os sistemas distribu Para implementac a a dos, opta o 3.8.3). Os Servic se pelo uso de Servic os Web (Secc a os Web oferecem caracter sticas nicas [8] e vantagens bem conhecidas [67] como: a independ u encia ao n vel da plataforma o, desacoplamento entre as partes e um forte tecnol ogica, simplicidade de implementac a
6.2. CONVENC OES TECNICAS
87
apoio da ind ustria. Actualmente, s ao v arias as tecnologias associadas ao conceito de Servic o Web; seleccionando-se duas em particular: URI e HTTP. Os Uniform Resource Identiers (URI) [5] permitem identicar os recursos disponibi` s interfaces publicadas por cada um dos sistemas. S lizados e os pontos de acesso a ao ca es: uniformidade, o que permite uma interpretac o sem racterizados por tr es denic o a antica comum; recurso, um modelo conceptual de uma entidade f sica ou l ogica; identicador, que funciona como uma refer encia para algo que tenha uma identidade. um protocolo gen O HyperText Transfer Protocol (HTTP) [39] e erico que, para al em do uso tradicional associado ao hipertexto, pode ser utilizado em diversas tarefas, como na o pelo HTTP permite estabelecer uma interface de gest ao de recursos distribu dos. A opc a acesso comum, com recurso aos m etodos denidos: GET, POST, PUT e DELETE. A norma tamb em especica um conjunto de c odigos de erro que podem ser usados no contexto es, como por exemplo: 200 OK, 201 Created, 403 Forbidden, 404 das interacc o Not Found. ` opc o pelo protocolo HTTP e a exist Uma outra vantagem associada a a encia de es es que permitem implementar mecanismos de autenticac o para controlo de pecicac o a o seguros, recorrendo a normas como o HTTPS [80]. acessos [45] e canais de comunicac a poss Desta forma, e vel implementar alguns dos requisitos de seguranc a estabelecidos no Cap tulo 4. o dos Servic Na estrat egia seguida para a implementac a os Web, procurou-se maxi o com as infraestruturas Web j mizar a integrac a a existentes (caches, proxies). Uma das o e a maior interoperabilidade com os sistemas existentes. Fazconsequ encias desta opc a ltima refer ` s opc es tomadas no desenho da arquitectura da WWW [40], se uma u encia a o que foram um contributo importante para o trabalho aqui apresentado.
6.2
es T Convenc o ecnicas
o, s es t Nesta secc a ao apresentadas as convenc o ecnicas que devem ser seguidas na elabo o da implementac o nal. O desenvolvimento deste conjunto de recomendac es teve rac a a o por base 3 documentos: XML Forum Technical Specication for Higher Education [23], ASC X12 Reference Model for XML Design [12] e XML Schemas - Best Practices [15].
6.2.1
Idioma
o e comuDeve ser usado o idioma Ingl es para representar os termos usados na codicac a o. Por exemplo: <Student> em vez de <Estudante>. O car nicac a acter internacional mbito do programa ERASdo projecto e, em concreto, a troca de registos acad emicos no a o. MUS justicam esta opc a
6.2.2
Nomenclaturas
Deve ser usada a norma designada por Upper Camel Case (UCC) na escrita dos termos. o dos nomes num termo (eliminando os espac Esta regra determina a junc a os) e o uso de mai usculas para cada palavra (Por exemplo: StudentHomeAddress). Esta regra tem
88
sido adoptada noutros casos [23] e constitui uma pr atica comum em documentos deste o relaciona-se com a facilidade de leitura resultante. tipo. A principal justicac a N ao devem ser usados os seguintes caracteres nos termos: (underscore), - (h fen) e . (ponto). Quando se denem tipos, deve ser acrescentado o suxo Type ao termo (Por exemplo: PersonType).
6.2.3
o Codicac a
o dos documentos deve ser usado o formato Unicode Transformation Para a codicac a Format de 8 bits (UTF-8). A Internet Engineering Task Force (IETF) recomenda [1] o uso deste formato.
6.2.4
Uso de Elementos ou Atributos
um tema de debate frequente - Elementos vs. Atributos. A opc o por uma das Este e a o n duas formas de estruturar a informac a ao deve ser absoluta. Neste caso, vamos adoptar as regras usadas pelo XML Forum [23]. O m etodo proposto dene 4 passos para ajudar a determinar o recurso a elementos ou atributos: Determinar se os dados em quest ao s ao fundamentalmente conte udo ou metadados. Usar elementos no primeiro caso. ne Determinar os requisitos estruturais para os dados. Usar elementos quando e o de estruturas complexas. cess aria a validac a o sobre o Determinar como v ao ser usados os dados: para transmitir informac a o. Usar elementos no primeiro caso. dom nio ou para o processamento de informac a o de um para um entre partes da informac o. Usar atributos para reforc ar a relac a a o. Para, por exemplo, representar tuplos de informac a a transfer o. Nestes casos de estudo, um dos principais objectivos e encia de informac a Por outro lado, os documentos denidos t em uma estrutura complexa. Assim, na genera es, ser o e a lidade das situac o ao usados elementos. Uma vantagem que adv em desta opc a maior facilidade de leitura dos documentos XML.
6.3 Partilha do Registo Acad emico do Aluno

o, apresenta-se o trabalho desenvolvido na implementac o do Registo Acad Nesta secc a a emico do Aluno, cumprindo os requisitos estabelecidos antes.
6.3.1 Identicador do Registo Acad emico do Aluno

o de um identicador u nico para o registo acad Para a implementac a emico do aluno optou identicado de forma u nica, compondo o se por uma estrutura hier arquica. Cada aluno e o e o c c odigo de aluno, o c odigo da instituic a odigo do pa s.
6.3. PARTILHA DO REGISTO ACADEMICO DO ALUNO

C odigo do Pa s - C odigo da Instituic ao - C odigo do Aluno
89
O c odigo identicador do pa s segue a norma ISO 3166 [41], que dene um c odigo num erico de 3 d gitos para cada pa s. Por exemplo: 620 - Portugal 276 - Alemanha 724 - Espanha ` identicac o das instituic es de ensino superiO segundo n vel, que corresponde a a o da responsabilidade do pa or, e s. Para cada pa s, deve ser denida uma entidade res o de identicadores a ` s instituic es de ensino superior. Em Espapons avel pela atribuic a o mbito do projecto SCANet, foi escolhida a AECOC, a entidade respons nha, e no a avel o de c ` s instituic es. pelos c odigos EAN em Espanha, para a atribuic a odigos a o Em Portugal, o Minist erio da Ci encia e do Ensino Superior (MCES) dene c odigos para os estabelecimentos de ensino e cursos [24]. Por exemplo: 1105 - Faculdade de Engenharia da Universidade do Porto 0502 - Faculdade de Direito da Universidade de Coimbra ltimo n Ou vel do c odigo corresponde ao identicador interno mantido pela faculdade para cada aluno. Assim, o c odigo 620-1105-010570016 corresponde a: 620 - Portugal 1105 - Faculdade de Engenharia da Universidade do Porto 010570016 - S ergio Sobral Nunes (aluno do MGI)
6.3.2
o do Registo Acad Representac a emico do Aluno
o de informac o sobre estudantes O esquema proposto pelo PESC, para a representac a a [19], foi usado como ponto de partida para o trabalho aqui apresentado. Esta norma ` partilha de dados e e dirigida a um n destina-se prioritariamente a umero signicativo de es. Assim, procurou-se destacar a sem o e eliminar ambiguiinstituic o antica da informac a dades ao n vel dos tipos de dados usados. o e o elemento StudentRecord, que representa um Registo A raiz da especicac a composto por dois subelementos Acad emico de Aluno (Figura 6.1). Este elemento e obrigat orios: DocumentInfo e Student. O elemento Note, que pode n ao existir ou o. existir v arias vezes, representa uma anotac a
90
Figura 6.1: Elemento StudentRecord
do tipo DocumentInfoType e re o O elemento DocumentInfo e une informac a composto por quatro subelementos sobre o documento (Figura 6.2). Este elemento e obrigat orios: da responsabili DocumentCode - Refer encia do documento. O valor atribu do e dade da entidade que cria o documento. o deste documento. DocumentIssueDate - Data de criac a o sobre a entidade respons Issuer - Informac a avel pela emiss ao deste documento. StudentCode - N umero do aluno denido pela entidade emissora. o da instituic o (Issuer) e o identicador interno de cada Reunindo a informac a a poss aluno (StudentCode), e vel identicar de forma universal todos os aluno.
Figura 6.2: Elemento DocumentInfoType
do tipo StudentType (Figura 6.3), que dene a estrutura O elemento Student e o relativa a um estudante e inclui: para a informac a o sobre a pessoa; e um elemento do tipo PersonType. Person - Re une informac a o sobre a liac o do aluno. Cont Family - Informac a a em dois subelementos (Mother e Father) do tipo PersonType.
91
AdmissionExam - Representa uma prova de admiss ao efectuada para candidatura ao ensino superior. Um aluno pode conter v arias provas de admiss ao. Sobre cada prova s ao armazenados o t tulo, o c odigo, a data e o resultado. AcademicDegree - Representa um grau acad emico que o aluno possui ou no qual est a matriculado. Um aluno pode ter v arios graus acad emicos. Este subele do tipo AcademicDegreeType. mento e o sobre exames e HealthRecord - Registo de sa ude do aluno. Inclui informac a es do aluno. imunizac o o sobre a situac o militar do aluno, em concreto MilitaryRecord - Informac a a qual o estado desse processo.
Figura 6.3: Elemento StudentType
o base sobre uma pesO elemento PersonType (Figura 6.4) representa a informac a usado para representar informac o sobre o aluno e respectiva liac o. A estrutura soa; e a a deste elemento inclui: o: c IdentificationCode: Representa um elemento de identicac a odigo, des o, valor, emissor, data de emiss cric a ao e data de validade. Sobre uma pessoa e poss vel reunir v arios subelementos deste tipo. Name: Representa o nome da pessoa, estruturado em t tulo, primeiro nome, no ltimo nome e nome completo. me(s) do meio(s), u o sobre o nascimento. Inclui data de nascimento, cidade e pa Birth: Informac a s. o sobre o falecimento. Este subelemento existe no caso de Deceased: Informac a falecimento do aluno e inclui indicador de falecimento e data.
92
CAPITULO 6. IMPLEMENTAC AO o sobre o g Gender: Informac a enero do aluno. MaritalStatus: Estado civil do aluno. o sobre o pa Citizenship: Informac a s de origem do aluno. o sobre a resid Residency: Informac a encia do aluno: morada, c odigo postal, cidade e pa s. Contact: Conjunto de contactos do aluno. Cada contacto pode ser do tipo: enderec o postal, telefone, enderec o de correio electr onico ou p agina Web.
Figura 6.4: Elemento PersonType
O elemento AcademicDegreeType (Figura 6.5) representa uma matr cula num grau acad emico e inclui: o sobre o grau acad Degree: Informac a emico, do tipo DegreeType. o respons StudentCode: C odigo do aluno na instituic a avel pelo grau. DegreeAdmissionDate: Data de matr cula no grau acad emico. DegreeStudentStatus: Estado da matr cula no grau acad emico (a frequentar, permutado, conclu do, etc).
93
DegreeConclusionDate: Data de conclus ao do grau acad emico. A n ao exist encia deste subelemento signica que o grau n ao foi terminado. DegreeAcademicGradeAverage: No caso do curso estar conclu do, repre o. senta a m edia nal do aluno na escala usada na instituic a DegreeECTSGradeAverage: A m edia nal do aluno na escala ECTS. AcademicSession: Representa uma sess ao acad emica do tipo AcademicSessionType. Cada sess ao acad emica corresponde a um per odo lectivo. o sobre pr AcademicAward - Informac a emios acad emicos atribu dos ao aluno no o a cada pr contexto de um grau acad emico. Em relac a emio (do tipo Academic armazenado o t AwardType), e tulo e a data. o sobre actividades extra-curriculares do aluno. Um ExtraActivity - Informac a aluno pode ter v arias actividades extra-curriculares no contexto de um grau aca registado o nome, a data de in d emico. Sobre cada actividade e cio, a data de o. conclus ao e a descric a
94
Figura 6.5: Elementos AcademicDegreeType e DegreeType
o sobre o grau acad O DegreeType (Figura 6.5) re une informac a emico: o sobre a instituic o respons Institution: Informac a a avel pelo curso. o. DegreeCode: C odigo do grau acad emico, atribu do pela instituic a
6.3. PARTILHA DO REGISTO ACADEMICO DO ALUNO DegreeName: Nome do grau acad emico.
95
CurricularProgram: Refer encia para o plano de estudos. O c odigo de cada denido pela instituic o. plano e a DegreeLevel: N vel acad emico deste grau; os valores poss veis s ao bacharelato, o, mestrado e doutoramento. licenciatura, p os-graduac a o ocial deste grau acad DegreeDuration: Durac a emico. Contact: Conjunto de contactos do curso: morada, p agina Web, enderec o de correio electr onico, etc. ` frequ Como j a foi referido, cada per odo lectivo associado a encia de um grau acad emico representado pelo elemento AcademicSessionType (Figura 6.6). e Este elemento cont em: AcademicSessionStartDate: Data de in cio do per odo lectivo. AcademicSessionEndDate: Data de conclus ao do per odo lectivo. es em disciplinas feitas durante o per Course: Conjunto de inscric o odo lectivo. do tipo CourseType. Cada disciplina e o sobre uma eventual dissertac o realizada no a mbito deste Thesis: Informac a a o, nome do(s) supervisor(es) e per odo lectivo e que inclui o t tulo da dissertac a o. avaliac a
96
Figura 6.6: Elementos AcademicSessionType e CourseType
representada pelo elemento CourseType (Figura 6.6) e inclui: Cada disciplina e o. CourseCode: C odigo da disciplina, atribu do pela instituic a CourseName: Nome da disciplina. CourseStartDate: Data de in cio. CourseEndDate: Data de conclus ao. ` disciplina. CourseCreditUnits: Unidades de cr edito associadas a
6.3. PARTILHA DO REGISTO ACADEMICO DO ALUNO CourseECTSCreditUnits: Unidades de cr edito ECTS. CourseClassSize: N umero de alunos inscritos.
97
o do aluno na disciplina. O valor e ex CourseAcademicGrade: Classicac a o. presso na escala usada na instituic a o do aluno na escala ECTS. CourseECTSGrade: Classicac a o a esta disciplina CourseEquivalenceInformation: No caso da aprovac a ter sido obtida atrav es de uma equival encia, este subelemento permite armazenar do tipo EquivalenceInformationType. o. E essa informac a ` disciplina, por exemplo: enderec Contact: Conjunto de contactos associados a o de correio electr onico, p agina Web. o dos principais elementos que comp o proposta, Nesta apresentac a oem a especicac a o repetida do subelemento Note existente em v foi omitida a descric a arios elementos. do tipo NoteType e representa uma anotac o que e poss Este elemento e a vel associar aos elementos. o do Registo Acad A listagem completa da especicac a emico do Aluno, em XML Schema, encontra-se no Ap endice B.
6.3.3
o do Sistema Especicac a
Diagrama de Componentes Na Figura 6.7, apresenta-se o diagrama de componentes para o cen ario de partilha de o entre instituic es. O n informac a o o Institution (Client) representa uma insti o que det o. O n tuic a em r eplicas da informac a o Institution (Server) representa o que det o a partilhar (prim uma instituic a em a informac a ario). Como j a foi referido antes, podem existir v arios servidores e v arios clientes. o funcionar como servidora de parte da informac o e como No caso de uma instituic a a cliente de outra, os dois componentes (ClientManager e ServerManager) seriam implementados no mesmo n o.
o sobre Alunos Figura 6.7: Diagrama de Componentes para a Partilha de Informac a
98 o das interfaces: Especicac a
updateReplica - Recebe, via HTTP/POST, o identicador do aluno (Student RecordId) e o registo acad emico em XML (StudentRecord). Se o pedido e v alido, actualiza a r eplica local. readPrimary - Recebe, via HTTP/GET, o identicador do aluno. Se o pedido e v alido, responde com o documento XML correspondente ao registo acad emico. updatePrimary - Recebe, via HTTP/POST, o identicador do aluno (StudentRecordId), a chave associada ao lock (LockKey) e o registo acad emico em XML valido, e actualizada a c (StudentRecord). Se o pedido e opia prim aria e iniciado o das r enviado um c o processo de actualizac a eplicas. Em caso de insucesso, e odigo de erro. efectuado um lockPrimary - Recebe, via HTTP/GET, o identicador do aluno. E bem sucedido, e enviado na resposta lock sobre o recurso. Se o procedimento e poss enviado um um c odigo associado ao lock criado. Se n ao e vel criar o lock, e c odigo de erro. unlockPrimary - Recebe, via HTTP/GET, o identicador do aluno e o c odigo asso v libertado o lock sobre o registo. ciado ao lock (LockKey). Se o pedido e alido, e Diagrama de Sequ encia ilustrado o processo de actualizac o de informac o a partir do servidor. Na Figura 6.8, e a a o da informac o no servidor, e lanc Depois de conclu da a actualizac a a ado o processo de o das v actualizac a arias r eplicas dispersas pelos clientes. Este processo (updateReplicas), vai invocar a interface updateReplica para cada umas r eplicas e garantir que a actua o seja conclu lizac a da com sucesso.
DE ESTATISTICAS 6.4. AGREGAC AO SOBRE OS CURSOS
99
o sobre Alunos Figura 6.8: Diagrama de Componentes para a Partilha de Informac a
o e iniciado pelo cliente, temos um diagrama de Quando o processo de actualizac a o de informac o sequ encia semelhante ao que foi apresentado para o caso da concentrac a a (Figura 6.15).
6.4
6.4.1
o de Estat Agregac a sticas sobre os Cursos

Identicador do Curso
o de identicadores u nicos aos cursos, foi seguida a mesma estrat Para a atribuic a egia o 6.3.1). Assim, prop adoptada a prop osito do registo acad emico do aluno (ver Secc a oe-se um c odigo hier arquico com a seguinte estrutura:
C odigo do Pa s - C odigo da Instituic ao - C odigo do Curso
` norma ISO 3166; o c o, e no caso de O c odigo do pa s corresponde a odigo da instituic a atribuido pelo MCES; o c atribu o. Portugal, e odigo do curso e do pela pr opria instituic a poss Desta forma, e vel identicar universalmente cada curso.
100
o de Estat 6.4.2 Representac a sticas sobre o Curso

a raiz da especicac o e agrega um conjunto de O elemento DegreeStatistics e a o dos dados de ndole estat stica relativas a um curso acad emico (Figura 6.9). Na selecc a dados, foram usados como ponto de partida, os relat orios DIMAS solicitados pelo MCES. Os primeiros cinco elementos permitem identicar o documento e o curso e delimitar o per odo a que se referem as estat sticas: o sobre o documento e que inclui: c DocumentInfo - Informac a odigo interno, data de emiss ao e emissor. o do curso, composta por tr DegreeIdentification - Identicac a es subele o e c mentos: c odigo do pa s, c odigo da instituic a odigo interno do curso. DegreeAcronym - Sigla do curso. DegreeName - Nome do curso. DegreeStatisticsStartDate - Data que delimita o in cio do per odo a que se reportam as estat sticas. DegreeStatisticsEndDate - Data que delimita o m do per odo a que se reportam os estat sticas. o estat Os restantes subelementos s ao optativos e re unem a informac a stica que se con` s classicac es s siderou importante. Os valores associados a o ao apresentados na escala o. Sempre que se apresentam totais relativos a pessoas, e usado o tipo usada na instituic a o em pessoas do sexo PersonsNumberType. Este tipo permite estruturar a informac a masculino, feminino, e somat orio total. DegreeFaculty - N umero de docentes associados ao curso. AdmissionVacancies - N umero de vagas existentes para acesso ao curso (Numeros Clausus). AcceptedApplicantsNumber - N umero de candidatos admitidos. es AcceptedApplicantsGradeAverage - M edia aritm etica das classicac o dos candidatos admitidos. es dos can AcceptedApplicantsGradeMedian - Mediana das classicac o didatos admitidos. AcceptedApplicantsGradeStandardDeviation - Desvio padr ao das clas es dos candidatos admitidos. sicac o es dos AcceptedApplicantsGradeMinimum - Valor m nimo das classicac o candidatos admitidos. es dos AcceptedApplicantsGradeMaximum - Valor m aximo das classicac o candidatos admitidos.
101
Figura 6.9: Elemento DegreeStatisticsType
102
EnrolledStudents - N umero de alunos inscritos. o dos alunos inscritos, por pa EnrolledStudentsByCountry - Distribuic a ses. o dos alunos inscritos, por idades. EnrolledStudentsByAge - Distribuic a o dos alunos ins EnrolledStudentsByCurricularPeriod - Distribuic a critos, por per odo curricular. o EnrolledStudentsByEnrollmentsByCurricularPeriod - Distribuic a dos alunos inscritos, por n umero total de inscric oes e para cada per odo curricular. Graduates - N umero de alunos graduados. o dos alunos graduados, por pa GraduatesByCountry - Distribuic a ses. o dos alunos graduados, por idades. GraduatesByAge - Distribuic a o dos alunos graduados, por GraduatesByFinalGradeValue - Distribuic a m edias nais. o dos alunos graduados, por GraduatesByTotalEnrollments - Distribuic a es. n umero total de inscric o
Figura 6.10: Elemento PersonsByEnrollmentsByCurricularPeriodType
o que aconteEm alguns casos, elementos diferentes reutilizam o mesmo tipo. E ce com EnrolledStudentsByAge e GraduatesByAge, que s ao ambos do tipo PersonsByAgeType. A t tulo de exemplo, apresenta-se com mais detalhe a estrutura dos elementos EnrolledStudentsByEnrollmentsByCurricularPeriod e GraduatesByFinalGradeValue. do tipo PersonsByEnrollmentsByCurricularPeriodType (ver O primeiro e Figura 6.10) e cont em, como subelemento, um ou v arios CurricularPeriodFrequency. composto por tr Este elemento e es subelementos obrigat orios: o do per CurricularPeriod - Identicac a odo curricular. o do per CurricularPeriodDuration - Durac a odo curricular. es. Representa o n EnrollmentsFrequency - Frequ encia das inscric o umero de es. estudantes (inscritos ou graduados) por n umero de inscric o
103
composto por um elemento do tiO tipo PersonsByFinalGradeValueType e po FinalGradeValueFrequency que pode ocorrer uma ou v arias vezes (ver Figura 6.11). Este elemento cont em um elemento que identica a m edia nal (Final o das pessoas (PersonsNumber). GradeValue) e um que re une a distribuic a
Figura 6.11: Elemento PersonsByFinalGradeValueType
o do elemento DegreeNo Ap endice C, inclui-se a listagem completa da especicac a StatisticsType.
6.4.3
Diagrama de Componentes o que Na vista de componentes do sistema (Figura 6.12), est a representada a instituic a o (Institution (Client)) e a instituic o que det pretende agregar a informac a a em a informac ao (Institution (Server)). A interacc ao parte do cliente que invoca a interface p ublica getDegreeStatistics, indicando o per odo lectivo que pretende.
o de Informac o Estat Figura 6.12: Diagrama de Componentes para a Agregac a a stica sobre Cursos
o da interface: Especicac a getDegreeStatistics - Recebe, via HTTP/GET, o identicador do curso. Se o pedi v do e alido, envia as estat sticas mais recentes do curso em formato XML.
104 Diagrama de Sequ encia
muito simples uma vez que a interacc o tem um O diagrama de sequ encia (Figura 6.13) e a ilustrada a interacc o com um dos servipadr ao pedido-resposta tradicional. Na gura, e a o dores. Em cen arios com m ultiplos servidores, o cliente deve fazer a mesma interrogac a es dependem exclusivaa cada um dos sistemas. A ordem e periodicidade das interrogac o es do sistema cliente. mente das opc o
o de Informac o Estat Figura 6.13: Diagrama de Sequ encia para a Agregac a a stica sobre Cursos
6.5
6.5.1
o de Informac o sobre Recursos HumaConcentrac a a nos

Identicador do Recurso Humano
nicos para cada recurso humano e de forma seCom o intuito de denir identicadores u melhante ao que foi feito nos casos de estudo anteriores, prop oe-se um c odigo hier arquico com a seguinte estrutura:
C odigo do Pa s - C odigo da Instituic ao - C odigo do Funcion ario
` norma ISO 3166; o c o, e no caso O c odigo do pa s corresponde a odigo da instituic a de Portugal, e atribuido pelo MCES; o c odigo do funcion ario e atribu do pela pr opria o. Desta forma, e poss instituic a vel identicar universalmente cada recurso humano.
o de Informac o sobre Recursos Humanos 6.5.2 Representac a a

o de informac o sobre cada recurso humano, foi denido o elemento Para a representac a a StaffRecord (ver Figura 6.14). Este elemento est a estruturado em cinco subelementos.
DE INFORMAC SOBRE RECURSOS HUMANOS 6.5. CONCENTRAC AO AO
105
Figura 6.14: Elemento StaffRecord
o do pa o e da pessoa na StaffIdentication - Re une a identicac a s, da instituic a o. instituic a StaffAcronym - Sigla do funcion ario. es sobre a pessoa: identicac o, nome, nascimento, Person - Conjunto de informac o a estado civil e contactos. StaffCategory - Categoria, no contexto da carreira, a que a pessoa pertence. Os va o e pelo governo lores poss veis dependem muito das regras denidas pela instituic a o das opc es. central. Neste caso, usou-se o SiFEUP como refer encia na denic a o o. Tamb StaffStatus - Estado da pessoa na instituic a em neste caso foi usado o SiFEUP como refer encia. o sobre o registo. Este elemento permite armazenar informac o Note - Observac a a livre que se considere relevante incluir. o completas do elemento StaffRecord. No Ap endice D, encontra-se a especicac a
6.5.3
Diagrama de Componentes o de informac o e semelhante ao da partiO diagrama de componentes para a concentrac a a o (Figura6.7), com a diferenc lha de informac a a de, neste caso, existir apenas um cliente -
106
o de informac o. O Institution (Server) representa uma o ponto de concentrac a a es que det o sobre recursos humanos. das instituic o em informac a ` s diversas O n o cliente disponibiliza a interface updateReplica, que permite a es actualizar a informac o concentrada nesse n instituic o a o. Cada um dos servidores de o publica tr es por parte do n informac a es interfaces que permitem as actualizac o o central. Assim, para adicionar novos n os, basta criar as tr es interfaces no novo sistema e registar o no ponto de concentrac o. essa informac a a o das interfaces: Especicac a updateReplica - Recebe, via HTTP/POST, o identicador do funcion ario (Staff RecordId) e o registo acad emico em XML (StaffRecord). Se o pedido e v alido, actualiza a r eplica local. readPrimary - Recebe, via HTTP/GET, o identicador do funcion ario. Se o pedido v e alido, responde com o documento XML correspondente ao registo. updatePrimary - Recebe, via HTTP/POST, o identicador do funcion ario (StaffRecordId), a chave associada ao lock (LockKey) e o registo do funcion ario em valido, e actualizada a c XML (StaffRecord). Se o pedido e opia prim aria e o das r enviado iniciado o processo de actualizac a eplicas. Em caso de insucesso, e um c odigo de erro. efectuado lockPrimary - Recebe, via HTTP/GET, o identicador do funcion ario. E bem sucedido, e enviado na resposta um lock sobre o recurso. Se o procedimento e poss enviado um um c odigo associado ao lock criado. Se n ao e vel criar o lock, e c odigo de erro. unlockPrimary - Recebe, via HTTP/GET, o identicador do funcion ario e o c odigo v libertado o lock sobre o associado ao lock (LockKey). Se o pedido e alido, e registo. Diagrama de Sequ encia o Na Figura 6.15, representa-se o diagrama de sequ encia para o processo de actualizac a o a partir do n iniciado quando existe um pedido de de informac a o central. O processo e o. Como e necess o dispon a mais recente, e actualizac a ario garantir que a informac a vel e o dos dados no cliente. feito um bloqueio ao recurso que se vai alterar e uma actualizac a o, e feita a propagac o para o servidor e os bloqueios s Depois de conclu da a actualizac a a ao o libertados. No nal deste processo, e de forma ass ncrona, o servidor inicia a actualizac a da r eplica existente no cliente. Como se indica na gura, existe um per odo durante o qual o n o central n ao vai ter na o da interface base de dados a c opia mais recente do recurso alterado. Uma nova invocac a o, evitaria esta situac o. readPrimary, imediatamente depois da actualizac a a
DE NOTICIAS 6.6. DIFUSAO DA UNIVERSIDADE
107
o de Informac o sobre Recursos Figura 6.15: Diagrama de Sequ encia para a Concentrac a a Humanos
o de informac o a partir de um dos servidores ter O processo de actualizac a a a um diagrama de sequ encia semelhante ao que foi apresentado na Figura 6.8. Com a diferenc a de, neste caso, existir apenas uma r eplica para actualizar.
6.6
6.6.1
Difus ao de Not cias da Universidade

Identicador da Not cia
o de identicadores u nicos a atribuir a cada not Para a implementac a cia, e seguindo a mesma estrat egia adoptada nos outros casos de estudo, prop oe-se um c odigo hier arquico com a seguinte estrutura:
C odigo do Pa s - C odigo da Instituic ao - C odigo do Not cia
108
` norma ISO 3166; o c o, e no caso de O c odigo do pa s corresponde a odigo da instituic a atribuido pelo MCES; o c atribu o. Portugal, e odigo da not cia e do pela pr opria instituic a poss Desta forma, e vel identicar universalmente cada not cia.
o de Not 6.6.2 Representac a cias

comO elemento NewsItem, ilustrado na Figura 6.16, representa um item noticioso. E posto por cinco elementos: o do item noticioso. Re NewsItemIdentification: Identicac a une informa o sobre o pa o e o item. c a s, a instituic a Title: O t tulo da not cia. o da not Date: A data de publicac a cia. o da not ExpirationDate: A data de expirac a cia. o da not Description: A descric a cia. Author: O autor ou o respons avel pela not cia. Category: A categoria a que pertence a not cia. Este elemento pode existir v arias vezes, permitindo associar uma not cia a m ultiplas categorias. URL: Enderec o Web permanente da not cia.
109
Figura 6.16: Elemento NewsItem
o completa do elemento NewsItem est A especicac a a dispon vel no ap endice E. o dos itens noticiNo caso particular da difus ao p ublica e para al em da disponibilizac a o de normas p osos no formato aqui especicado, sugere-se a adopc a ublicas que permitam o adv uma melhor interoperabilidade com os sistemas existentes. A justicac a em do facto o com sistemas externos. de, no caso da difus ao p ublica, se procurar potenciar a integrac a o noticiosa na Assim, e considerando o panorama actual da difus ao de informac a um diWWW, opta-se pelo formato RSS 2.0 [101]. O RSS (Really Simple Syndication) e o de alterac es alecto XML desenvolvido inicialmente pela Netscape para a representac a o usado para a publicac o de not a s tios Web. Actualmente, e a cias por parte de empresas como a BBC [3], Reuters [81] e o The Washington Post [79]. Um outro argumento a favor o deste formato e a exist da adopc a encia de bibliotecas espec cas para RSS nas principais o. linguagens de programac a
110
o do Sistema 6.6.3 Especicac a

Digrama de Componentes
Figura 6.17: Diagrama de Componentes para a Difus ao de Not cias da Universidade
apresentado o diagrama de componentes do sistema. A Reitoria da UniNa Figura 6.17 e representada pelo n versidade e o Institution (Server) e os n os Institution o da (Client) e Unknown (Client) representam, respectivamente, uma instituic a universidade (difus ao controlada) e uma entidade desconhecida (difus ao p ublica). usada por parte dos clientes p O servidor publica a interface getNews, que e ublicos ` lista das u ltimas not para aceder a cias. Para a difus ao controlada, o servidor utiliza a es envolvidas na interface deliverNews, disponibilizada por cada uma das instituic o comunidade. o das interfaces: Especicac a deliverNews - Recebe, via HTTP/POST, a not cia em formato XML (NewsItem). v armazenada localmente. Se o pedido e alido, a not cia e ltimas getNews - Recebe pedidos via HTTP/GET e responde com a lista das u not cias em formato RSS. Diagramas de Sequ encia Nas Figuras 6.18 e 6.19, est ao representados os diagramas de sequ encia para os dois casos o e despoletada sempre que existe de estudo seleccionados. No primeiro caso, a execuc a um novo item para difundir. O servidor selecciona os clientes com base em crit erios pr e-denidos e faz o envio do item para cada um.
111
Figura 6.18: Diagrama de Sequ encia para a Difus ao Controlada de Not cias
o e iniciada pelo cliente. O servidor responNo cen ario de difus ao p ublica, a interacc a ltimas not de aos pedidos, enviando a lista das u cias.
Figura 6.19: Diagrama de Sequ encia para a Difus ao P ublica de Not cias
112
6.7
Prot otipos
es propostas, foram deTendo como objectivo analisar a viabilidade pr atica das soluc o senvolvidos v arios prot otipos. Estes prot otipos est ao divididos em dois grupos, de acordo o da informac o e mecanismos de interacc o. com o que se pretendeu avaliar: representac a a a o ao primeiro caso, procurou-se testar a adequac o das especicac es proEm relac a a o o de informac o em situac es reais. Para tal, recorreu-se a ` inpostas para representac a a o o existente no SiFEUP e foi desenvolvido um prot formac a otipo que permitiu extrair es do registo acad representac o emico de cada aluno no formato proposto. O sistema de o da FEUP e constru es disinformac a do sobre o SGBD Oracle. Utilizando as func o o de XML a partir de interrogac es SQL a ` base de dados, foi pon veis para produc a o poss vel extrair um documento XML com os dados necess arios. Aplicando a esta sa da o XSL produziu-se o documento nal. Este cen ilustrado na Figuuma transformac a ario e ra 6.20.
` representac o de informac o Figura 6.20: Arquitectura do prot otipo relativo a a a
o aos mecanismos de interacc o, foram implementados prot Em relac a a otipos para cada um dos padr oes. Os prot otipos foram desenvolvidos em PHP [51] e os testes realizados sobre tr es servidores geogracamente dispersos. Estes testes permitiram validar as arquitecturas propostas e, em particular, as tecnologias adoptadas (XML, URI e HTTP). o de mecanismos de controlo de Tamb em foi poss vel testar com sucesso a implementac a o b acessos, recorrendo ao esquema de autenticac a asica do HTTP [80]. Teria sido interessante explorar em maior detalhe os prot otipos desenvolvidos, em o de testes de carga e integrac o parcial com os sistemas em particular com a realizac a a o, no entanto o factor tempo e condicionantes deste tipo de trabalho n produc a ao o permitiram.
Cap tulo 7 Conclus oes

apresentado um sum Neste cap tulo, e ario das conclus oes obtidas e s ao sugeridas algumas perspectivas de trabalho futuro.
113
114
CAPITULO 7. CONCLUSOES
7.1
Conclus oes Gerais
o sobre as principais alternativas para a Neste trabalho, desenvolveu-se uma investigac a o universit interoperabilidade entre sistemas de informac a arios. Foram identicados e ca o mais comuns e foram propostas soluc es para os tegorizados os padr oes de interacc a o o de prot principais cen arios encontrados. A construc a otipos permitiu validar, numa primeira fase, as abordagens propostas. es desta dissertac o para a a rea em estudo podem ser sintetiAs principais contribuic o a zadas em quatro itens: S ntese do estado da arte em relac a o a ` s principais tecnologias de apoio a ` intero perabilidade. E feita uma revis ao sistem atica e transversal das principais quest oes que, de um ponto de vista tecnol ogico, condicionam a tomada de decis ao na cons o de sistemas interoper truc a aveis. Estruturac a a oes de interoperabilidade em ambientes o e caracterizac o dos padr o do problema, foram identicados dois eixos (vertiuniversit arios. Para a denic a o: partilha, agregac o, cal e horizontal) e caracterizados quatro padr oes de interacc a a o e difus concentrac a ao. Proposta de especicac o a a es XML para a representac o de informac o no contexto o do acad emico. Concretamente, foram elaboradas propostas para a representac a o sobre os registo acad emico do aluno, de estat sticas sobre os cursos, de informac a es. Neste contexto, foi recursos humanos e de not cias produzidas pelas instituic o o de identicadores u nicos associatamb em proposta uma estrat egia para a denic a o. dos a esta informac a Proposta de especicac o a es UML para a implementac o de mecanismos de interac o identicados, foram propostas especic a oes de interacc a o. Com base nos padr es UML para a partilha, agregac o, concentrac o e difus o. cac o a a ao de informac a o e uma a rea complexa em que se A interoperabilidade entre sistemas de informac a evidente cruzam muitas disciplinas. Mesmo considerando apenas o aspecto tecnol ogico, e reas t o de dados, a representac o o recurso a a ao distintas como as redes de comunicac a a o e a programac o de sistemas distribu o de de informac a a dos. Por outro lado, a construc a intrinsecamente diferente de sistemas monol sistemas distribu dos e ticos; quest oes como a lat encia, a concorr encia ou as falhas parciais aumentam a complexidade destes sistemas. ltimos tempos, esta a rea tem sido alvo de crescente atenc o; a produc o de Nos u a a es e a constituic o de cons especicac o a orcios empresariais tem crescido fortemente. Se por um lado, estas iniciativas resultam em desenvolvimentos tecnol ogicos importantes; ` proliferac o de soluc es para o por outro, aumentam a complexidade da decis ao devido a a o mesmo m. Muitas das tecnologias actualmente propostas n ao atingiram ainda a maturidade ne es reais. O SOAP e um exemplo de uma norma onde implecess aria para implementac o es produzidas por diferentes fabricantes s mentac o ao incompat veis entre si. Neste tra es baseadas em tecnologias bem estabelecidas e largamente balho, optou-se por soluc o difundidas como o HTTP, os URL e o XML.
7.2. PERSPECTIVAS DE TRABALHO FUTURO
115
o facto de este trabalho ter permitido constatar Um outro aspecto que importa referir, e uma tecnologia poderosa e largamente difundida. O leque de ferramentas que o XML e o por parte da ind existentes e a sua generalizada adopc a ustria conrmam o estatuto de standard de facto. es simUma das estrat egias seguidas neste trabalho foi o desenvolvimento de soluc o ples com pouco impacto sobre os sistemas existentes. Por exemplo, as interfaces propos o, baseiam-se nos verbos HTTP. Esta opc o tem como tas para os mecanismos de interacc a a fundamento o facto de ser mais interessante estabelecer acordos simples que englobem a maioria dos participantes, do que acordos exaustivos e muito detalhados envolvendo apenas um leque reduzido de participantes. Concluindo, a interoperabilidade atinge-se aderindo a normas comuns. Neste caso, o que usa tecnologias largamente difundidas: tecnologias Web optou-se por uma soluc a o das e XML. O trabalho realizado permitiu validar estas tecnologias na implementac a es propostas. A chave para a interoperabilidade e soluc o a a normalizac o. Um factor rea ser imprescind vel ao sucesso de qualquer iniciativa nesta a a o apoio por parte dos centros de poder.
7.2
Perspectivas de Trabalho Futuro
Sistematizam-se aqui alguns t opicos que podem ser explorados em trabalhos futuros: ` adopc o institucional das especi Levar a cabo esforc os que permitam conduzir a a es aqui propostas. O empenho dos o rg um factor fundamental cac o aos de gest ao e es ou no sucesso de pol ticas que envolvem diferentes grupos (unidades, instituic o universidades). Assim, para al em da interoperabilidade t ecnica aqui abordada, e importante apostar na interoperabilidade pol tica/humana, relacionada com a di es de poder e as culturas. mens ao organizacional, as relac o o de ontologias, existentes ou a desenvolver, Explorar as possibilidades de adopc a rea acad na a emica. As ontologias permitem formalizar conceitos e as respectivas es em dom relac o nios espec cos. No Cap tulo 3 foi apresentado o conceito de N veis de Interoperabilidade. O trabalho aqui apresentado enquadra-se no Grau 3 da arquitectura NC3TA - troca autom atica de dados sobre sistemas com modelos de partilha comuns. Sugere-se a o do trabalho nesta a rea, com a explorac o de soluc es que permitam um prossecuc a a o maior grau de interoperabilidade. Buscando atingir n veis que permitam, por exem o interactiva dos dados, a partilha de aplicac es ou a interpretac o plo, a manipulac a o a o. universal da informac a o, a possibilidade de gerir dinamica No caso particular da difus ao de informac a o e o controlo de acessos das instituic es interessadas em recemente a subscric a o o constituiria um desenvolvimento interessante. Na proposta aqui ber informac a o e introduzida manualmente, cada instituic o dene a apresentada, esta informac a a priori quais os receptores e quais os t opicos das mensagens.
116
CAPITULO 7. CONCLUSOES
um dos aspectos mais importantes na construc o de procedimentos A seguranc a e a o ao desenvolvimento de soluc es espec digitais. Por oposic a o cas para cada caso, o vulgar e a denic o de plataformas partilhadas de forma a potenciar uma soluc a a a interoperabilidade. Assim, sugere-se o desenvolvimento de uma infraestrutura de chaves p ublicas (PKI) ao n vel da universidade, de forma a garantir servic os b asicos o, integridade e condencialidade seguranc a na transmiss ao de dados: autenticac a de.
Bibliograa
[1] Harald T. Alvestrand. IETF Policy on Character Sets and Languages. RFC 2277, Internet Engineering Task Force, 1998. Available from: http://www.ietf. org/rfc/rfc2277.txt [cited 27-05-2004]. [2] Paul Bacsich, Andy Heath, Paul Lefrere, Paul Miller, and Kevin Riley. The Standards Fora for Online Education. D-Lib Magazine, 5(12), 1999. Available from: http://www.dlib.org/dlib/december99/12miller.html. [3] BBC. RSS Feed (Really Simple Syndication) [online]. 2004 [cited 03-05-2004]. Available from: http://news.bbc.co.uk/1/hi/help/rss/default. stm. [4] Tim Berners-Lee. Information Management: A Proposal. Technical report, CERN, mar 1989. Technical Report. Available from: http://www.w3.org/ History/1989/proposal.html [cited 28-11-2003]. [5] Tim Berners-Lee, Roy T. Fielding, and Larry Masinter. Uniform Resource Identiers (URI): Generic Syntax. RFC 2396, Internet Engineering Task Force, 1998. Available from: http://www.ietf.org/rfc/rfc2396.txt [cited 26-052004]. [6] Paul Beynon-Davies. Information Systems - An Introduction to Informatics in Organizations. Palgrave, Bath, 2002. [7] Chris Britton. IT Architectures and Middleware. Addison-Wesley, 2000. [8] Mike Burner. The Deliberate Revolution - Creating Connectedness with XML Web Services. ACM Queue, pages 2937, 2003. [9] Christopher Bussler. B2B Protocol Standards and their Role in Semantic B2B Integration Engines. Bulletin of the Technical Committee on Data Engineering, 24(1):311, mar 2001. [10] CEN/ISSS. Interoperability frameworks for exchange of information between diverse management systems. Learning Technology eBrochure, (5), jan 2003. Available from: http://www. cenorm.be/cenorm/businessdomains/businessdomains/ informationsocietystandardizationsystem/elearning/ learning+technologies+workshop/ebrochurenumber5.pdf. 117
118
BIBLIOGRAFIA
[11] Alexandre Coimbra and Ant onio Rito Silva. Support Process Patterns in Higher Education. In EUNIS 2003. EUNIS, 2003. [12] ANSI ASC X12C Communications and Controls Subcommittee. ASC X12 Reference Model for XML Design. Technical report, DISA Inc., 2002. Report Number: ASC X12C/2002-61. Available from: http://www.x12.org/x12org/ comments/X12Reference_Model_For_XML_Design.pdf [cited 1012-2003]. [13] World Wide Web Consortium. W3C XML Encryption Working Group [online]. 2003 [cited 10-04-2003]. Available from: http://www.w3.org/ Encryption/2001/. [14] World Wide Web Consortium and Internet Engineering Task Force. IETF/W3C XML-DSig Working Group [online]. 2003 [cited 10-09-2003]. Available from: http://www.w3.org/Signature/. [15] Roger L. Costello. XML Schemas: Best Practices [online]. 2003 [cited 10-07-2003]. Available from: http://xfront.com/ BestPracticesHomepage.html. [16] George Coulouris, Jean Dollimore, and Tim Kindberg. Distributed Systems: Concepts and Design, 3rd Edition. Addison-Wesley, 2001. [17] Postsecondary Electronic Standards Council. Work Products [online]. 2002 [cited 02-05-2003]. Available from: http://www.pescxml.org/xmlprod. asp?page=workprod&sub=workproducts. [18] Postsecondary Electronic Standards Council. PESC - home page [online]. 2003 [cited 15-03-2003]. Available from: http://www.standardscouncil.org. [19] Postsecondary Electronic Standards Council. PESC - XML Postsecondary Transcript Schema [online]. 2003 [cited 10-10-2003]. Available from: http://www. standardscouncil.org/XMLPostTranscript.asp. [20] Postsecondary Electronic Standards Council. XML forum FAQ [online]. 2003 [cited 09-04-2003]. Available from: http://www.pescxml.org/xmlfaq. asp?page=faq. [21] Postsecondary Electronic Standards Council. XML Forum for Education [online]. 2003 [cited 15-03-2003]. Available from: http://www.pescxml.org. [22] Postsecondary Electronic Standards Council. XML Technical Specication for Higher Education. Technical report, Postsecondary Electronic Standards Council, may 2003. Available from: http://standardscouncil.org/docs/ XML%20Forum%20Tech%20Specification%20v%202.5.doc. [23] Postsecondary Electronic Standards Council. XML Technical Specication for Higher Education. Specication, Postsecondary Electronic Standards Council, 2003. Available from: http://www.pescxml.org/docs/ XMLForumTechSpecv01.pdf.
BIBLIOGRAFIA
119
[24] Minist erio da Ci encia e do Ensino Superior. Acesso ao Ensino Superior 2003 - Indices de Cursos (por estabelecimento e curso) [online]. 2003 [cited 2011-2003]. Available from: http://www.acessoensinosuperior.pt/ indest.asp. [25] Minist erio da Ci encia e do Ensino Superior. Observat orio da Ci encia e do Ensino Superior [online]. 2003 [cited 01-12-2003]. Available from: http://www. oces.mces.pt. o das Nac es Unidas. Electronic Business eXtensible Mark-up Lan[26] Organizac a o guage (ebXML) [online]. 2003 [cited 06-06-2003]. Available from: http: //www.unece.org/cefact/ebxml/specifications.htm. [27] DCMI. DCMI Education Working Group [online]. 2003 [cited 15-03-2003]. Available from: http://dublincore.org/groups/education/. [28] Pavan Deolasee, Amol Katkar, Ankur Panchbudhe, Krithi Ramamritham, and Prashant Shenoy. Adaptive push-pull: disseminating dynamic web data. In Proceedings of the tenth international conference on World Wide Web, pages 265274. ACM Press, 2001. [29] Universidade do Porto. Universidade do Porto - home page [online]. 2003 [cited 27-05-2003]. Available from: http://www.up.pt. [30] EDUCAUSE. What is EDUCAUSE? [online]. 2003 [cited 2003-02-20]. Available from: http://www.educause.edu/defined.html. [31] EDUCAUSE and Internet2 eduPerson Task Force. eduPerson Object Class [online]. 2003 [cited 15-03-2003]. Available from: http://www.educause.edu/ eduperson/. [32] David L. Eisler. Campus Portals: Supportive Mechanisms for University Communication. Collaboration, and Organizational Change. Journal of Computing in Higher Education, 13(1):324, 2001. Available from: http://faculty. weber.edu/deisler/journal.htm. [33] Wolfgang Emmerich. Software Engineering and Middleware: a Roadmap. In Proceedings of the conference on The future of Software Engineering, pages 117 129. ACM Press, 2000. [34] Patrick Th. Eugster, Pascal A. Felber, Rachid Guerraoui, and Anne-Marie Kermarrec. The Many Faces of Publish/Subscribe. ACM Computing Surveys, 35(2):114 131, jun 2003. [35] EUNIS. EUNIS Website [online]. 2003 [cited 2003-02-20]. Available from: http://www.eunis.org. o de Bolonha, 1999. Available from: http://www. [36] Uni ao Europeia. Declarac a bologna-berlin2003.de/pdf/bologna_declaration.pdf.
120
BIBLIOGRAFIA
o de [37] Uni ao Europeia. Sistema Europeu de Transfer encia e Acumulac a Cr editos de Curso (ECTS) [online]. 2003 [cited 05-01-2004]. Available from: http://europa.eu.int/comm/education/programmes/ socrates/ects_pt.html. [38] David C. Fallside. XML Schema Part 0: Primer. Recommendation, World Wide Web Consortium, 2001. Available from: http://www.w3.org/TR/ xmlschema-0/ [cited 16-05-2003]. [39] Roy T. Fielding, James Gettys, Jeffrey C. Mogul, Henry F. Nielsen, Larry Masinter, Paul J. Leach, and Tim Berners-Lee. Hypertext Transfer Protocol - HTTP/1.1. RCF 2616, Internet Engineering Task Force, 1999. Available from: http://www. ietf.org/rfc/rfc2616.txt [cited 26-05-2004]. [40] Roy T. Fielding and Richard N. Taylor. Principled Design of the Modern Web Architecture. ACM Transactions on Internet Technology, 2(2):115150, 2002. [41] International Organization for Standards. Maintenance agency for iso 3166 country codes [online]. 2003 [cited 18-11-2003]. Available from: http://www.iso. ch/iso/en/prods-services/iso3166ma/index.html. [42] Michael Franklin and Stanley Zdonik. A framework for scalable disseminationbased systems. In Proceedings of the 12th ACM SIGPLAN conference on Objectoriented programming, systems, languages, and applications, pages 94105. ACM Press, 1997. [43] Michael J. Franklin, Michael J. Carey, and Miron Livny. Transactional ClientServer Cache Consistency: Alternatives and Performance. ACM Transactions on Database Systems, 22(3):315363, 1997. [44] Michael J. Franklin, Bj orn Th or J onsson, and Donald Kossmann. Performance Tradeoffs for Client-Server Query Processing. In Proceedings of the 1996 ACM SIGMOD international conference on Management of data, pages 149160. ACM Press, 1996. [45] John Franks, Phillip M. Hallam-Baker, Jeffery L. Hostetler, Scott D. Lawrence, Paul J. Leach, Ari Luotonen, and Lawrence C. Stewart. HTTP Authentication: Basic and Digest Access Authentication. RFC 2617, Internet Engineering Task Force, 1999. Available from: http://www.ietf.org/rfc/rfc2617.txt [cited 26-05-2004]. [46] Ursula Fuller, Cornelia Helbling, and Roger Cooley. The Potential Of Web-Based Suggestion Schemes In A University Setting. In EUNIS 2002. EUNIS, FEUP es, 2002. Edic o [47] Kurt Geihs. Middleware Challenges Ahead. IEEE Computer, 34(6):2431, jun 2001.
BIBLIOGRAFIA
121
[48] Jim Gray, Pat Helland, Patrick ONeil, and Dennis Shasha. The dangers of replication and a solution. In Proceedings of the 1996 ACM SIGMOD international conference on Management of data, pages 173182. ACM Press, 1996. [49] C4ISR Architecture Working Group. Levels of Information Systems Interoperability, 1998. [50] ISSC NATO Open Systems Working Group. NATO C3 Technical Architecture Volume 2: Architectural Descriptions and Models, 2003. [51] The PHP Group. PHP: Hypertext Preprocessor [online]. 2004 [cited 27-05-2004]. Available from: http://www.php.net. [52] Hugo Haas. Designing the architecture for Web Services. In WWW2003. W3C, 2003. Available from: http://www.w3.org/2003/Talks/ 0521-hh-wsa/. [53] Franz Haselbacher. Design and operation of a WEB-databased university es, 2002. information-management-system. In EUNIS 2002. EUNIS, FEUP Edic o [54] HL7. Health Level 7 [online]. 2003 [cited 05-03-2003]. Available from: http: //www.hl7.org. [55] HUMANE. Seminar - International Students: Exchange or Trade? [online]. 2003 [cited 25-11-2003]. Available from: http://www.humane.eu.org/ 5_down_lund_2.doc. [56] IMS. IMS Global Learning Consortium, Inc. [online]. 2003 [cited 15-03-2003]. Available from: http://www.imsglobal.org. [57] Internet2/MACE. Directory of Directories for Higher Education [online]. 2003 [cited 15-03-2003]. Available from: http://middleware.internet2.edu/ dodhe/. [58] Internet2/MACE. Shibboleth Project [online]. 2003 [cited 15-03-2003]. Available from: http://shibboleth.internet2.edu. [59] Internet2/MI. Internet2 Middleware [online]. 2003 [cited 04-04-2003]. Available from: http://middleware.internet2.edu. [60] Carl Jacobson. Institutional Information Portals. EDUCAUSE Review, pages 58 59, 2000. Available from: http://www.educause.edu/pub/er/erm00/ articles004/horizons.pdf. [61] Donald Kossmann. The State of the Art in Distributed Query Processing. ACM Computing Surveys, 32(4):422469, dec 2000. [62] Donald Kossmann, Michael J. Franklin, Gerhard Drasch, and Wig Ag. Cache investment: integrating query optimization and distributed data placement. ACM Transactions on Database Systems, 25(4):517558, 2000.
122
BIBLIOGRAFIA
[63] Kenneth C. Laudon and Jane P. Laudon. Management Information Systems. Prentice Hall, New Jersey, 2002. [64] Bin Ling, Colin Allison, and Malcolm Bain. Analyse, Model, Improve, Deriving Value Added Services through Process Modeling. In EUNIS 2002. EUNIS, FEUP es, 2002. Edic o [65] Ling Liu, Ling Ling Yan, and M. Tamer Ozsu. Interoperability in Large-scale Distributed Information Delivery Systems. In NATO Advanced Study Institute on Workow Management Systems and Interoperability. NATO, 1997. [66] Peter Mederly. Annual Eunis Report on University Information Systems in Europe. In EUNIS97 Conference. EUNIS, 1997. Available from: http://www.lmcp.jussieu.fr/eunis/html3/congres/ EUNIS97/papers/052201.html. [67] Brahim Medjahed, Boualem Benatallah, Athman Bouguettaya, Anne H. Ngu, and Ahmed K. Elmagarmid. Business-to-business interactions: issues and enabling technologies. The VLDB Journal, 12(1):5985, 2003. [68] Paul Miller. Interoperability. What is it and Why should i want it? Ariadne, (24), 2000. Available from: http://www.ariadne.ac.uk/issue24/ interoperability/. [69] Janina Mincer-Daszkiewicz. Student Management Information System for Polish es, 2002. Universities. In EUNIS 2002. EUNIS, FEUP Edic o es Dom [70] Henry Mintzberg. Estrutura e Din amica das Organizac o o es. Publicac Quixote, Lisboa, 1995. [71] NCES. SPEEDE/ExPRESS Home Page [online]. 2003 [cited 15-03-2003]. Available from: http://nces.ed.gov/edi/speedeExp.asp. [72] Anoop Ninan, Purushottam Kulkarni, Prashant Shenoy, Krithi Ramamritham, and Renu Tewari. Cooperative Leases: Scalable Consistency Maintenance in Content Distribution Networks. In WWW2002. ACM Press, 2002. [73] OASIS. Open Architecture and Schools in Society [online]. 2003 [cited 15-032003]. Available from: http://oasis.cnice.mecd.es. [74] Florence Olsen. Sharing the Code [online]. 2003 [cited 10-08-2003]. Available from: http://chronicle.com/free/v49/i47/47a03101.htm. [75] OMG. Introduction To OMG Specications: CORBA [online]. 2002 [cited 04-01-2003]. Available from: http://www.omg.org/gettingstarted/ specintro.htm#CORBA. [76] Esther Pacitti and Eric Simon. Update propagation strategies to improve freshness in lazy master replicated databases. The VLDB Journal, 8(3-4):305318, 2000.
BIBLIOGRAFIA
123
[77] C. M. Parker and P. M. C. Swatman. Encouraging SME Acceptance of EDI: An Educational Approach. In 8th International EDI-IOS Conference, pages 27 46. EDI-IOS, jun 1995. Available from: http://citeseer.nj.nec.com/ 36012.html. [78] Kestutis Pocius, Aleksandras Targamazde, Linas Vingelis, and Albertas Zalys. Designing Corporate Information System for cooperation and management of Lithu es, 2002. anian HE&R institutions. In EUNIS 2002. EUNIS, FEUP Edic o [79] The Washington Post. RSS Feeds [online]. 2004 [cited 03-05-2004]. Available from: http://www.washingtonpost.com/wp-adv/rss/. [80] Eric Rescorla. HTTP Over TLS. RFC 2818, Internet Engineering Task Force, 2000. Available from: http://www.ietf.org/rfc/rfc2818.txt [cited 26-05-2004]. [81] Reuters. Reuters RSS [online]. 2004 [cited 09-05-2004]. Available from: http: //www.reuters.com/newsrss.jhtml. [82] L gia Ribeiro and Jos e Marques dos Santos, editors. The Changing Universities: es, 2002. The Challenge of New Technologies. EUNIS, FEUP Edic o [83] David Ritter. The Middleware Muddle. SIGMOD Record, 27(4):8693, 1998. [84] Manuel Rodr guez-Mart nez and Nick Roussopoulos. MOCHA: A Self-Extensible Database Middleware System for Distributed Data Sources. In Proceedings of the 2000 ACM SIGMOD international conference on Management of data, pages 213 224. ACM Press, 2000. [85] Alenka Rozanec, Rok Rupnik, Marki Bajec, and Marjan Krisper. IS Strategic plan for the University of Ljubljana: Experiences and Results. In EUNIS 2002. EUNIS, es, 2002. FEUP Edic o [86] SCANet. Norma 1.01/02E - Identicac on Normalizada del C odigo Unicado de Estudiante. Technical report, SCANet, mar 2002. Available from: http:// scanet.udl.es/spa/normas/Norma-1.1-02E-VG.pdf. [87] SCANet. Norma 1.01/02E - Identicac on Normalizada del C odigo Unicado de Estudiante. Technical report, SCANet, mar 2002. Available from: http:// scanet.udl.es/spa/normas/Norma-2.1-02E-VG.pdf. [88] SCANet. Norma 4.01/03E - Homologaci on de Datos de Expedientes de Primer y Segundo Ciclo para Intercambios, traslados y certicaciones acad emicas. Technical report, SCANet, jun 2003. Available from: http://scanet.udl.es/ spa/normas/Norma-4.1-03E.pdf. [89] SCANet. SCANet [online]. 2003 [cited 30-05-2003]. Available from: http: //www.scanet.udl.es.
124
BIBLIOGRAFIA
[90] SCANet. SCANet - Fases [online]. 2003 [cited 24-11-2003]. Available from: http://scanet.udl.es/spa/fases/index.html. [91] SCANet. SCANet - Nuestra misi on [online]. 2003 [cited 23-11-2003]. Available from: http://scanet.udl.es/spa/definicion/index.html. [92] Tony Shaw, Anne Strachan, Gerry McCauley, and Lynn McCrae. The portal as the es, framework for the information strategy? In EUNIS 2002. EUNIS, FEUP Edic o 2002. [93] SIF. Schools Interoperability Framework [online]. 2003 [cited 15-03-2003]. Available from: http://www.sifinfo.org. [94] Doug Stacey. Replication: DB2, Oracle, or Sybase? SIGMOD Record, 21(1):95 101, 1995. [95] IEEE Computer Society Standards. IEEE Learning Technology Standards Committee [online]. 2003 [cited 15-03-2003]. Available from: http://ltsc. ieee.org. [96] Stefan Tai and Isabelle Rouvellou. Strategies for Integrating Messaging and Distributed Object Transactions. In IFIP/ACM International Conference on Distributed systems platforms, pages 308330. Springer-Verlag New York, Inc., 2000. [97] Andrew S. Tanenbaum and Maarten Van Steen. Distributed Systems: Principles and Paradigms. Prentice-Hall, New Jersey, 2002. [98] Leonor Teixeira, Carlos Ferreira, and Rui Santiago. Managing Academic Services Through the Web: an information support system for graduated programs. In es, 2002. EUNIS 2002. EUNIS, FEUP Edic o [99] Andreas Tolk. Beyond Technical Interoperability - Introducing a Reference Model for Measures of Merit for Coalition Interoperability. In 8th International Command and Control Research and Technology Symposium, 2003. [100] Darina Tothova and Beata Bellerova. Open Access to Information. In EUNIS 2002. es, 2002. EUNIS, FEUP Edic o [101] Dave Winer. RSS 2.0 Specication [online]. 2004 [cited 03-05-2004]. Available from: http://blogs.law.harvard.edu/tech/rss. [102] ASC X12. ASC X12 - Home [online]. 2003 [cited 15-03-2003]. Available from: http://www.x12.org. [103] ASC X12. X12A - Education Administration Purpose and Scope [online]. 2003 [cited 15-03-2003]. Available from: http://www.x12.org/x12org/ subcommittees/sc_home.cfm?strSC=A. [104] J. Yang, W. J. van den Heuvel, and M. P. Papazoglou. Service Deployment for Virtual Enterprises. In Proceedings of the workshop on Information technology for virtual enterprises, pages 107115. IEEE Computer Society, 2001.
Ap endice A Estrutura da Base de Dados e Lista de Funcionalidades

A.1 o Modelo Entidade-Relac a
o da base de dados, constru Na Figura A.1, apresenta-se o modelo entidade-relac a da para o universit organizar as funcionalidades encontradas nos sistemas de informac a arios estudados. As principais entidades s ao: feature (funcionalidade), category (categoria), keyword (palavra-chave) e system (sistema). Cada funcionalidade pode ser caracterizada por v arias palavras-chave, bem como pertencer a m ultiplas categorias. Por outro lado, a mesma funcionalidade pode existir em diferentes sistemas.
o Figura A.1: Modelo Entidade-Relac a
A.2
Lista de Funcionalidades
Na listagem seguinte, enumeram-se todas as funcionalidades encontradas nos sistemas de o universit informac a arios estudados. A lista est a organizada por ordem alfab etica.
Access to Bibliographic Search Database Allow Multiple Teachers by Course
125
126
APENDICE A. BASE DE DADOS DE FUNCIONALIDADES

Allow students to dene constraints in their schedule Allow teachers to customize grades parameters (components) Allow teachers to publish students grades Alumni E-mail Forwarding Alumnis Record Approve Course Enrollment Approve Group Enrollment Aprove Exam Enrollments Aquisitions Management Backups Management Budget Management Buildings drawing Calendar: event invitations with accept/reject functionality Calendar: event reminders Calendar: Free/busy-time search Calendar: group several calendars into one Calendar: supports the iCAL standard Cards Management Cards Management: export data Career Advance Management Career Counseling Chat system associated with each course Chat system associated with each department Compute Degrees Final Average Content Personalization Copyright Protection Mechanisms Course catalog Course Enrollment Management Course Equivalences Management Courses bibliography Courses calendar Courses Complementary Page Courses coordinators can manage courses schedule Courses coordinators can request new time slots Courses Discussion Group Courses E-mail Courses Exams
A.2. LISTA DE FUNCIONALIDADES

Courses Groups Courses Record Courses Search Courses statistical reports Courses students Courses students print with photos Courses summaries search Courses Teachers Customizable Interface Day or Month Based Calendar Browsing Decentralized content management Dene deadlines for teachers to write the summaries Denition of rules to allow students years transition Degrees Calendar Degrees Complementary Page Degrees Courses Degrees Discussion Group Degrees Record Degrees Search Degrees Statistical Information Degrees Students Degrees Teachers Digital Library Diploma Management Direct Connection to a Internet Publishing Area Disc Quota Management Disc Quotas Reloading Discussion Group Search Discussion groups management Discussion groups: users can create new groups online Document management using digital signatures Dorm Facilities Management E-Business system to manage purchases E-mail Alias Denition E-mail Auto-Response E-mail distribution system with recipients ltering and selection E-mail Forwarding
127
128
E-mail Messaging
Enrollment Scheduling Management Exam Enrollment Management Exam Enrollment Through the Web Export courses students list File sharing area associated with each course File sharing system associated with each department Financial Aid Processes Information Financial Management Forum associated with each course Forum associated with each department Full Search Group Enrollment Management Groups Discussion Group Groups Management for Document Distribution Guestbook management Help-desk System Institutions Calendar Integrate students timetable/schedule with the published summaries Integrate Summaries with the Teachers Schedule Integrated Webmail Integrates e-learning features Integration with an optical reader system to process documents Integration with Document Scanning System Integration with MS Word to produce reports/certicates using templates Inventory Management Job Center Job Center: indentify matches between the candidates and the offers Job Center: reminders Job Center: subscription Labour Agreements Management Library management Mailing list management Mailing lists: users can create new lists online Main Menu Customization Manage courses enrollment online Manage Courses Summaries

Manage different schools and groups in the same institution Manage postgraduate thesis Manage student absences Manage teachers absences Manage Teachers Activity Manage teachers extra-curricular activity Manage Thesis Workow Manage Vacations Message Compilation Window Message exchange system associated with each course Message exchange system associated with each department Messaging System News Management News Management: Archive News Management: Archive News Management: Archive Search News Management: Categorized News News Management: Dene Expiration Dates News Management: Dene Headlines News Management: Personalization News Management: Priority Levels News Management: Search News Manager for Degrees, Courses, Groups, Departments Notices associated with each course Notices system associated with each department Open Source People search Personal Bookmark Manager Personal Calendar Personal Contact Manager Personal Grade History Personal Photo Personal Webpage Personalized E-mail Address Personalized Timetable Personalized Warnings Phone Directory
129
130

Photo Gallery Management Postgraduations Tuitions Management Print Quotas Management Print Quotas Reloading Project Application Management Publications Management Publications Management: users can modify the information. Publications Search Publish Tax Declarations R&D Project Search R&D Projects Complementary Page R&D Projects Record R&D Units Complementary Page R&D Units Record Recruitment Process Management Register for courses using the catalog Requests/Processes Management Researchers Activities Researchers Complementary Page Researchers R&D Activities Management Researchers Record Researchers Search Resources management Resources management: association between resources Resources management: associations between resources and the buildings drawing Resources management: online information Resources management: reservation Resources management: statistical information Salary Management Search and lter course catalog Sincronization of information with mobile devices Single Login to the System SMS Messaging Staffs Record Statistical Information about Past Evaluations Student Association: e-mail address Student Associations: complementary page

Student Associations: information Students academic degrees Students Applications Management Students Applications Management: applicant automatic selection Students Applications Management: applicant information Students Applications Management: criteria denition Students can change their personal information in the system Students Cash Account Management Students complementary page Students Courses Students Financial Aid Management Students Photo Students Record Students Tuitions Management Students tutors can request more information to be lled Suggestion System Support common data formats for exchange with banks. Support pedagogical evaluations Support postgraduate studies Survey Management System: Access Control with SmartCards System: Accessibility Features System: Administration Guide System: Automatic Updates System: Bugtrack Management System: Change Password System: Contextual Help System System: Group Management System: Help System System: Log User Activity System: Manual System: Multilanguage Support System: Users Management System: Userss Permissions Management System: Userss Permissions Management By Area System: Userss Permissions Management By Feature Systems Passwords Management
131
132

Targeted Announcements Teachers can publish courses summaries Teachers Complementary Page Teachers Courses Teachers Photo Teachers Record Template Based, Personal Page Timetables Management: browse by subject (student, room, teacher, course, ...) Timetables Management: browse by time (day, week, year, ...) Timetables Management: Courses Timetable Timetables Management: Data Export Timetables Management: Groups Timetable Timetables Management: Room Validation Timetables Management: Rooms Timetable Timetables Management: Students Timetable Timetables Management: Teachers Timetable Timetables Management: Teachers timetable creation wizard Timetables Management: Timetable validation Treasury Management Trouble-Tickets Tuition Payment Units Portal User can Change Personal Information Verication and approval of grades View grades by course View grades by group View grades by student View student presences Web-based Administration Website Directory Workow Management
Ap endice B o do Registo Acad Especicac a emico do Aluno

B.1
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57
o do Elemento StudentRecord Especicac a
<?xml version="1.0" encoding="utf-8"?> <xs:schema targetNamespace="http://schemas.up.pt/StudentRecord" xmlns="http://schemas.up.pt/StudentRecord" xmlns:xs=" http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified">    <xs:element name="StudentRecord" type="StudentRecordType"/>    <xs:complexType name="StudentRecordType"> <xs:annotation> <xs:documentation> Registo do Aluno. </xs:documentation> </xs:annotation> <xs:sequence> <xs:element name="DocumentInfo" type="DocumentInfoType"> <xs:annotation> <xs:documentation> Informac ao sobre cada "inst ancia" deste documento: data, emissor. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="Student" type="StudentType"> <xs:annotation> <xs:documentation> Informac ao sobre o aluno. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="Note" type="NoteType" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType>    <xs:complexType name="DocumentInfoType"> <xs:annotation> <xs:documentation> Informac ao sobre o documento que representa o Registo do Aluno em XML. </xs:documentation> </xs:annotation> <xs:sequence> <xs:element name="DocumentCode" type="DocumentCodeType"> <xs:annotation> <xs:documentation> Identificador deste documento. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="DocumentIssueDate" type="DocumentIssueDateType"/> <xs:element name="Issuer" type="InstitutionType"/> <xs:element name="StudentCode" type="StudentCodeType"> <xs:annotation>
133
134
DO REGISTO ACADEMICO APENDICE B. ESPECIFICAC AO DO ALUNO
58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148
<xs:documentation> Identificador do aluno definido pela entidade emissora do documento. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="Note" type="NoteType" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType>  <xs:simpleType name="DocumentCodeType"> <xs:annotation> <xs:documentation> C odigo com significado local. Atribuido pela entidade emissora do documento. </xs:documentation> </xs:annotation> <xs:restriction base="xs:string"/> </xs:simpleType>  <xs:simpleType name="DocumentIssueDateType"> <xs:annotation> <xs:documentation> Data (dia e hora) de emiss ao do documento. </xs:documentation> </xs:annotation> <xs:restriction base="xs:dateTime"/> </xs:simpleType>    <xs:complexType name="StudentType"> <xs:annotation> <xs:documentation> Registo de aluno. </xs:documentation> </xs:annotation> <xs:sequence> <xs:element name="Person" type="PersonType"/> <xs:element name="Family" type="FamilyType" minOccurs="0"/> <xs:element name="AdmissionExam" type="AdmissionExamType" minOccurs="0" maxOccurs="unbounded"> <xs:annotation> <xs:documentation> Provas de ingresso realizadas pelo estudante. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="AcademicDegree" type="AcademicDegreeType" minOccurs="0" maxOccurs="unbounded "> <xs:annotation> <xs:documentation> Graus acad emicos (Cursos) em que o aluno se inscreveu. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="HealthRecord" type="HealthRecordType" minOccurs="0"> <xs:annotation> <xs:documentation> Informac ao sobre os exames e imunizac oes (vacinas) do aluno. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="MilitaryRecord" type="MilitaryRecordType" minOccurs="0"> <xs:annotation> <xs:documentation> Informac ao militar. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="Note" type="NoteType" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType>    <xs:complexType name="PersonType"> <xs:annotation> <xs:documentation> Definic ao do tipo para representar uma pessoa. </xs:documentation> </xs:annotation> <xs:sequence> <xs:element name="IdentificationCode" type="IdentificationCodeType" minOccurs="0" maxOccurs=" unbounded"> <xs:annotation> <xs:documentation> Uma pessoa pode ter v arios c odigos de identificac ao. Por exemplo, BI, NIF, etc. </xs:documentation> </xs:annotation> </xs:element>
DO ELEMENTO STUDENTRECORD B.1. ESPECIFICAC AO
135
149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241
<xs:element name="Name" type="NameType"/> <xs:element name="Birth" type="BirthType" minOccurs="0"/> <xs:element name="Deceased" type="DeceasedType" minOccurs="0"> <xs:annotation> <xs:documentation> Este elemento existe se a pessoa j a faleceu. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="Gender" type="GenderType" minOccurs="0"/> <xs:element name="MaritalStatus" type="MaritalStatusType" minOccurs="0"/> <xs:element name="Citizenship" type="CitizenshipType" minOccurs="0"/> <xs:element name="Residency" type="AddressType" minOccurs="0"> <xs:annotation> <xs:documentation> Resid encia "oficial", por isso s o pode ter uma inst ancia. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="Contact" type="ContactType" minOccurs="0" maxOccurs="unbounded"> <xs:annotation> <xs:documentation> Uma pessoa pode ter v arios contactos de v arios tipos. Por exemplo: telem ovel, telefone de casa, telefone do emprego, etc. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="Note" type="NoteType" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType>  <xs:complexType name="NameType"> <xs:annotation> <xs:documentation> Nome de uma pessoa. </xs:documentation> </xs:annotation> <xs:sequence> <xs:element name="Title" type="NameTitleType" minOccurs="0"/> <xs:element name="FirstName" type="FirstNameType" minOccurs="0"/> <xs:element name="MiddleName" type="MiddleNameType" minOccurs="0" maxOccurs="unbounded"/> <xs:element name="LastName" type="LastNameType" minOccurs="0"/> <xs:element name="FullName" type="FullNameType"/> <xs:element name="Note" type="NoteType" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType>  <xs:simpleType name="NameTitleType"> <xs:restriction base="xs:string"/> </xs:simpleType>  <xs:simpleType name="FirstNameType"> <xs:restriction base="xs:string"/> </xs:simpleType>  <xs:simpleType name="MiddleNameType"> <xs:restriction base="xs:string"/> </xs:simpleType>  <xs:simpleType name="LastNameType"> <xs:restriction base="xs:string"/> </xs:simpleType>  <xs:simpleType name="FullNameType"> <xs:restriction base="xs:string"/> </xs:simpleType>  <xs:complexType name="BirthType"> <xs:sequence> <xs:element name="BirthDate" type="xs:date"/> <xs:element name="BirthCity" type="CityType" minOccurs="0"/> <xs:element name="BirthCountry" type="CountryType" minOccurs="0"/> <xs:element name="Note" type="NoteType" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType>  <xs:complexType name="DeceasedType"> <xs:sequence> <xs:element name="DeceasedIndicator" type="xs:boolean"> <xs:annotation> <xs:documentation> Verdadeiro se j a faleceu. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="DeceasedDate" type="xs:date" minOccurs="0"/>
136
242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329
<xs:element name="Note" type="NoteType" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType>  <xs:simpleType name="GenderType"> <xs:annotation> <xs:documentation>G enero da pessoa. N ao preenchido em caso de ser desconhecido.</ xs:documentation> </xs:annotation> <xs:restriction base="xs:string"> <xs:enumeration value="F"> <xs:annotation> <xs:documentation>Female / Feminino.</xs:documentation> </xs:annotation> </xs:enumeration> <xs:enumeration value="M"> <xs:annotation> <xs:documentation>Male / Masculino.</xs:documentation> </xs:annotation> </xs:enumeration> <xs:enumeration value="U"> <xs:annotation> <xs:documentation>Unspecified / N ao especificado.</xs:documentation> </xs:annotation> </xs:enumeration> </xs:restriction> </xs:simpleType>  <xs:simpleType name="MaritalStatusType"> <xs:annotation> <xs:documentation>Estado civil da pessoa.</xs:documentation> </xs:annotation> <xs:restriction base="xs:string"> <xs:enumeration value="S"> <xs:annotation> <xs:documentation>Single / Solteiro.</xs:documentation> </xs:annotation> </xs:enumeration> <xs:enumeration value="M"> <xs:annotation> <xs:documentation>Married / Casado.</xs:documentation> </xs:annotation> </xs:enumeration> <xs:enumeration value="D"> <xs:annotation> <xs:documentation>Divorced / Divorciado.</xs:documentation> </xs:annotation> </xs:enumeration> <xs:enumeration value="W"> <xs:annotation> <xs:documentation>Widowed / Vi uvo.</xs:documentation> </xs:annotation> </xs:enumeration> <xs:enumeration value="U"> <xs:annotation> <xs:documentation>Unspecified / N ao especificado.</xs:documentation> </xs:annotation> </xs:enumeration> </xs:restriction> </xs:simpleType>  <xs:simpleType name="CitizenshipType"> <xs:restriction base="CountryType"/> </xs:simpleType>  <xs:complexType name="IdentificationCodeType"> <xs:annotation> <xs:documentation> Definic ao do tipo para representar n umeros de identificac ao de cart oes. Por exemplo: bilhete de identidade, cart ao de contribuinte, etc. </xs:documentation> </xs:annotation> <xs:sequence> <xs:element name="IdentificationCodeCode" type="IdentificationCodeCodeType" minOccurs="0"> <xs:annotation> <xs:documentation> C odigo identificativo do sistema de identificac ao usado. Usar nos casos em que o sistema de identificac ao e um dos tipos pr edefinidos. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="IdentificationCodeDescription" type="IdentificationCodeDescriptionType"/> <xs:element name="IdentificationCodeValue" type="IdentificationCodeValueType"/> <xs:element name="IdentificationCodeIssuer" type="IdentificationCodeIssuerType" minOccurs="0"/ > <xs:element name="IdentificationCodeIssueDate" type="IdentificationCodeIssueDateType" minOccurs="0"/> <xs:element name="IdentificationCodeExpirationDate" type="IdentificationCodeExpirationDateType " minOccurs="0"/>
137
330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422
<xs:element name="Note" type="NoteType" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType>  <xs:simpleType name="IdentificationCodeCodeType"> <xs:annotation> <xs:documentation> C odigo identificativo do sistema de identificac ao usado. Usar nos casos descriminados. </xs:documentation> </xs:annotation> <xs:restriction base="xs:string"> <xs:enumeration value="BI"> <xs:annotation> <xs:documentation>Bilhete de Identidade.</xs:documentation> </xs:annotation> </xs:enumeration> <xs:enumeration value="NIF"> <xs:annotation> <xs:documentation>N umero de Identificac ao Fiscal.</xs:documentation> </xs:annotation> </xs:enumeration> <xs:enumeration value="NCC"> <xs:annotation> <xs:documentation>N umero da Carta de Conduc ao.</xs:documentation> </xs:annotation> </xs:enumeration> <xs:enumeration value="NSS"> <xs:annotation> <xs:documentation>N umero da Seguranc a Social.</xs:documentation> </xs:annotation> </xs:enumeration> <xs:enumeration value="NP"> <xs:annotation> <xs:documentation>N umero do Passaporte.</xs:documentation> </xs:annotation> </xs:enumeration> </xs:restriction> </xs:simpleType>  <xs:simpleType name="IdentificationCodeDescriptionType"> <xs:restriction base="xs:string"/> </xs:simpleType>  <xs:simpleType name="IdentificationCodeValueType"> <xs:annotation> <xs:documentation> C odigo segundo este sistema de identificac ao. Por exemplo, se estivermos a armazenar o n umero de BI, incluir aqui o pr oprio n umero. </xs:documentation> </xs:annotation> <xs:restriction base="xs:string"/> </xs:simpleType>  <xs:simpleType name="IdentificationCodeIssuerType"> <xs:annotation> <xs:documentation> Informac ao sobre o emissor do c odigo de identificac ao. Por exemplo: Estado (BI), DGV ( carta de conduc ao). </xs:documentation> </xs:annotation> <xs:restriction base="xs:string"/> </xs:simpleType>  <xs:simpleType name="IdentificationCodeIssueDateType"> <xs:restriction base="xs:date"/> </xs:simpleType>  <xs:simpleType name="IdentificationCodeExpirationDateType"> <xs:restriction base="xs:date"/> </xs:simpleType>    <xs:complexType name="ContactType"> <xs:sequence> <xs:element name="ContactDescription" type="ContactDescriptionType"/> <xs:choice> <xs:element name="Address" type="AddressType"/> <xs:element name="Phone" type="PhoneType"/> <xs:element name="Email" type="EmailType"/> <xs:element name="URL" type="URLType"/> </xs:choice> <xs:element name="Note" type="NoteType" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> 
138
423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513
<xs:simpleType name="ContactDescriptionType"> <xs:restriction base="xs:string"/> </xs:simpleType>  <xs:complexType name="AddressType"> <xs:sequence> <xs:element name="AddressAttentionLine" type="AddressAttentionLineType" minOccurs="0" maxOccurs="unbounded"/> <xs:element name="AddressLine" type="AddressLineType" maxOccurs="unbounded"/> <xs:element name="AddressPostalCode" type="PostalCodeType"/> <xs:element name="AddressCity" type="CityType"/> <xs:element name="AddressCountry" type="CountryType"/> <xs:element name="Note" type="NoteType" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType>  <xs:complexType name="PhoneType"> <xs:sequence> <xs:element name="PhoneCountryCode" type="PhoneCountryCodeType" minOccurs="0"/> <xs:element name="PhoneNumber" type="PhoneNumberType"/> <xs:element name="PhoneNumberExtension" type="PhoneNumberExtensionType" minOccurs="0"/> </xs:sequence> </xs:complexType>  <xs:simpleType name="EmailType"> <xs:restriction base="xs:string"> <xs:pattern value="\w@\w\.\w"/> </xs:restriction> </xs:simpleType>  <xs:simpleType name="URLType"> <xs:restriction base="xs:anyURI"/> </xs:simpleType>  <xs:simpleType name="AddressAttentionLineType"> <xs:restriction base="xs:string"/> </xs:simpleType>  <xs:simpleType name="AddressLineType"> <xs:restriction base="xs:string"/> </xs:simpleType>  <xs:simpleType name="PostalCodeType"> <xs:restriction base="xs:string"/> </xs:simpleType>  <xs:simpleType name="CityType"> <xs:restriction base="xs:string"/> </xs:simpleType>  <xs:simpleType name="CountryType"> <xs:annotation> <xs:documentation> Identificador de um pa s usando o c odigo num erico da norma ISO 3166-1. Exemplo: Portugal = 620. </xs:documentation> </xs:annotation> <xs:restriction base="xs:string"> <xs:pattern value="\d\d\d"/> </xs:restriction> </xs:simpleType>  <xs:simpleType name="PhoneCountryCodeType"> <xs:restriction base="xs:string"/> </xs:simpleType>  <xs:simpleType name="PhoneNumberType"> <xs:restriction base="xs:string"/> </xs:simpleType>  <xs:simpleType name="PhoneNumberExtensionType"> <xs:restriction base="xs:string"/> </xs:simpleType>    <xs:complexType name="FamilyType"> <xs:annotation> <xs:documentation> Representa a filiac ao de uma pessoa. A m ae e o pai s ao opcionais porque pode n ao haver informac ao sobre os dois.
139
514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605
</xs:documentation> </xs:annotation> <xs:sequence> <xs:element name="Mother" type="PersonType" minOccurs="0"/> <xs:element name="Father" type="PersonType" minOccurs="0"/> <xs:element name="Note" type="NoteType" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType>  <xs:simpleType name="NoteType"> <xs:annotation> <xs:documentation> Tipo que representa um elemento gen erico para a definic ao de anotac oes. </xs:documentation> </xs:annotation> <xs:restriction base="xs:string"/> </xs:simpleType>    <xs:complexType name="AdmissionExamType"> <xs:annotation> <xs:documentation> Prova de ingresso. </xs:documentation> </xs:annotation> <xs:sequence> <xs:element name="AdmissionExamName" type="AdmissionExamNameType" minOccurs="0"/> <xs:element name="AdmissionExamCode" type="AdmissionExamCodeType" minOccurs="0"/> <xs:element name="AdmissionExamDate" type="AdmissionExamDateType" minOccurs="0"/> <xs:element name="AdmissionExamGrade" type="AcademicGradeType" minOccurs="0"/> <xs:element name="Note" type="NoteType" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType>  <xs:simpleType name="AdmissionExamNameType"> <xs:annotation> <xs:documentation> Nome da prova de admiss ao. Exemplo: "Prova espec fica de Matem atica", "GMAT". </xs:documentation> </xs:annotation> <xs:restriction base="xs:string"/> </xs:simpleType>  <xs:simpleType name="AdmissionExamCodeType"> <xs:annotation> <xs:documentation> C odigo identificador da prova de admiss ao. </xs:documentation> </xs:annotation> <xs:restriction base="xs:string"/> </xs:simpleType>  <xs:simpleType name="AdmissionExamDateType"> <xs:annotation> <xs:documentation> Data da prova de admiss ao. </xs:documentation> </xs:annotation> <xs:restriction base="xs:date"/> </xs:simpleType>    <xs:complexType name="AcademicDegreeType"> <xs:annotation> <xs:documentation> Matr cula de um aluno num grau acad emico de uma instituic ao. Pode n ao estar terminado. Por exemplo: se um aluno faz uma licenciatura e depois um mestrado tem dois elementos destes. </xs:documentation> </xs:annotation> <xs:sequence> <xs:element name="Degree" type="DegreeType"> <xs:annotation> <xs:documentation> Identificac ao do curso. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="StudentCode" type="StudentCodeType"> <xs:annotation> <xs:documentation> Identificador do aluno no contexto deste grau acad emico. Este c odigo e atribuido pela instituic ao respons avel pelo grau acad emico. </xs:documentation>
140
606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695
</xs:annotation> </xs:element> <xs:element name="DegreeAdmissionDate" type="xs:date"/> <xs:element name="DegreeStudentStatus" type="DegreeStudentStatusType" minOccurs="0"/> <xs:element name="DegreeConclusionDate" type="xs:date" minOccurs="0"/> <xs:element name="DegreeAcademicGradeAverage" type="AcademicGradeType" minOccurs="0"> <xs:annotation> <xs:documentation> No caso do curso estar conclu do, a m edia final. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="DegreeECTSGradeAverage" type="ECTSGradeType" minOccurs="0"> <xs:annotation> <xs:documentation> M edia final na escala ECTS. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="AcademicSession" type="AcademicSessionType" minOccurs="0" maxOccurs=" unbounded"> <xs:annotation> <xs:documentation> Um per odo lectivo. Um curso tem associados v arios per odos lectivos. Normalmente "anos lectivos". </xs:documentation> </xs:annotation> </xs:element> <xs:element name="AcademicAward" type="AcademicAwardType" minOccurs="0" maxOccurs="unbounded"> <xs:annotation> <xs:documentation> Refer encia aos pr emios acad emicos. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="ExtraActivity" type="ExtraActivityType" minOccurs="0" maxOccurs="unbounded"> <xs:annotation> <xs:documentation> Refer encia a actividades extra-curriculares de relev ancia. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="Note" type="NoteType" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType>    <xs:simpleType name="StudentCodeType"> <xs:annotation> <xs:documentation> Definic ao do tipo para representar o identificador de um aluno num curso. Cada instituic ao pode usar um sistema diferente. </xs:documentation> </xs:annotation> <xs:restriction base="xs:string"/> </xs:simpleType>    <xs:simpleType name="DegreeStudentStatusType"> <xs:annotation> <xs:documentation> Definic ao do tipo para representar o estado de um aluno numa matr cula. </xs:documentation> </xs:annotation> <xs:restriction base="xs:string"> <xs:enumeration value="AC"> <xs:annotation> <xs:documentation>Mudanc a de Curso / Academic Degree Change.</xs:documentation > </xs:annotation> </xs:enumeration> <xs:enumeration value="CS"> <xs:annotation> <xs:documentation>Concluiu Parte Escolar / Concluded Scholar Component.</ xs:documentation> </xs:annotation> </xs:enumeration> <xs:enumeration value="CN"> <xs:annotation> <xs:documentation>Conclu do / Concluded.</xs:documentation> </xs:annotation> </xs:enumeration> <xs:enumeration value="DC"> <xs:annotation> <xs:documentation>Falecido / Deceased.</xs:documentation> </xs:annotation> </xs:enumeration> <xs:enumeration value="DR"> <xs:annotation>
141
696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730 731 732 733 734 735 736 737 738 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 777 778 779 780 781 782 783 784
<xs:documentation>Desistiu / Dropped.</xs:documentation> </xs:annotation> </xs:enumeration> <xs:enumeration value="EA"> <xs:annotation> <xs:documentation>Anulac ao da Matr cula / Enrollment Annulled.</ xs:documentation> </xs:annotation> </xs:enumeration> <xs:enumeration value="ES"> <xs:annotation> <xs:documentation>Suspens ao da Matr cula / Enrollment Suspended.</ xs:documentation> </xs:annotation> </xs:enumeration> <xs:enumeration value="FQ"> <xs:annotation> <xs:documentation>A frequentar / Frequenting.</xs:documentation> </xs:annotation> </xs:enumeration> <xs:enumeration value="IN"> <xs:annotation> <xs:documentation>Interrompido / Interrupted.</xs:documentation> </xs:annotation> </xs:enumeration> <xs:enumeration value="NE"> <xs:annotation> <xs:documentation>N ao Inscrito / Not Enrolled.</xs:documentation> </xs:annotation> </xs:enumeration> <xs:enumeration value="NP"> <xs:annotation> <xs:documentation>N ao Pagou Propina / Fee Not Paid.</xs:documentation> </xs:annotation> </xs:enumeration> <xs:enumeration value="PE"> <xs:annotation> <xs:documentation>Inscric ao Provis oria / Provisory Enrollment.</ xs:documentation> </xs:annotation> </xs:enumeration> <xs:enumeration value="PM"> <xs:annotation> <xs:documentation>Permutado / Permuted.</xs:documentation> </xs:annotation> </xs:enumeration> <xs:enumeration value="PR"> <xs:annotation> <xs:documentation>Prescric ao / Prescribed.</xs:documentation> </xs:annotation> </xs:enumeration> <xs:enumeration value="RA"> <xs:annotation> <xs:documentation>Recolocado Noutro Curso / Repositioned in Other Academic Degree.</xs:documentation> </xs:annotation> </xs:enumeration> <xs:enumeration value="RE"> <xs:annotation> <xs:documentation>Reingresso / Reenrollment.</xs:documentation> </xs:annotation> </xs:enumeration> <xs:enumeration value="TR"> <xs:annotation> <xs:documentation>Transfer encia / Transference.</xs:documentation> </xs:annotation> </xs:enumeration> <xs:enumeration value="UK"> <xs:annotation> <xs:documentation>Desconhecido / Unknown.</xs:documentation> </xs:annotation> </xs:enumeration> </xs:restriction> </xs:simpleType>    <xs:complexType name="InstitutionType"> <xs:sequence> <xs:element name="InstitutionCode" type="InstitutionCodeType"> <xs:annotation> <xs:documentation> C odigo identificador da instituic ao no contexto nacional. Em Portugal, o c odigo definido pelo Minist erio da Ci encia e Ensino Superior. Exemplo: FEUP - 1105. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="InstitutionName" type="InstitutionNameType"/> <xs:element name="InstitutionLevel" type="InstitutionLevelType" minOccurs="0"/> <xs:element name="InstitutionCountry" type="CountryType"/> <xs:element name="Contact" type="ContactType" minOccurs="0" maxOccurs="unbounded"/> <xs:element name="Note" type="NoteType" minOccurs="0" maxOccurs="unbounded"/>
142
785 786 787 788 789 790 791 792 793 794 795 796 797 798 799 800 801 802 803 804 805 806 807 808 809 810 811 812 813 814 815 816 817 818 819 820 821 822 823 824 825 826 827 828 829 830 831 832 833 834 835 836 837 838 839 840 841 842 843 844 845 846 847 848 849 850 851 852 853 854 855 856 857 858 859 860 861 862 863 864 865 866 867 868 869 870 871 872 873 874 875 876 877
</xs:sequence> </xs:complexType>  <xs:simpleType name="InstitutionCodeType"> <xs:annotation> <xs:documentation> C odigo identificador da instituic ao num contexto nacional. </xs:documentation> </xs:annotation> <xs:restriction base="xs:string"/> </xs:simpleType>  <xs:simpleType name="InstitutionNameType"> <xs:restriction base="xs:string"/> </xs:simpleType>  <xs:simpleType name="InstitutionLevelType"> <xs:annotation> <xs:documentation> N vel acad emico da instituic ao: universit ario, polit ecnico. </xs:documentation> </xs:annotation> <xs:restriction base="xs:string"> <xs:enumeration value="UL"> <xs:annotation> <xs:documentation>N vel Universit ario.</xs:documentation> </xs:annotation> </xs:enumeration> <xs:enumeration value="PL"> <xs:annotation> <xs:documentation>N vel Polit ecnico.</xs:documentation> </xs:annotation> </xs:enumeration> </xs:restriction> </xs:simpleType>    <xs:complexType name="DegreeType"> <xs:annotation> <xs:documentation> Grau acad emico. Por exemplo: licenciatura, mestrado. </xs:documentation> </xs:annotation> <xs:sequence> <xs:element name="Institution" type="InstitutionType"> <xs:annotation> <xs:documentation> Instituic ao respons avel por este curso. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="DegreeCode" type="DegreeCodeType" minOccurs="0"> <xs:annotation> <xs:documentation> C odigo identificador do curso no contexto da instituic ao respons avel por ele. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="DegreeName" type="xs:string"> <xs:annotation> <xs:documentation> Nome do curso. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="CurricularProgram" type="CurricularProgramType" minOccurs="0"> <xs:annotation> <xs:documentation> Plano de estudos. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="DegreeLevel" type="DegreeLevelType" minOccurs="0"> <xs:annotation> <xs:documentation> Grau acad emico oferecido pelo curso. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="DegreeDuration" type="xs:duration" minOccurs="0"> <xs:annotation> <xs:documentation> Durac ao do curso. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="Contact" type="ContactType" minOccurs="0" maxOccurs="unbounded"> <xs:annotation>
143
878 879 880 881 882 883 884 885 886 887 888 889 890 891 892 893 894 895 896 897 898 899 900 901 902 903 904 905 906 907 908 909 910 911 912 913 914 915 916 917 918 919 920 921 922 923 924 925 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 941 942 943 944 945 946 947 948 949 950 951 952 953 954 955 956 957 958 959 960 961 962 963 964 965 966 967 968 969
<xs:documentation> Contactos do curso. Por exemplo: url, direcc ao, secretaria, etc. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="Note" type="NoteType" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType>  <xs:complexType name="CurricularProgramType"> <xs:annotation> <xs:documentation> Refer encia para um plano curricular. </xs:documentation> </xs:annotation> <xs:sequence> <xs:element name="CurricularProgramCode" type="CurricularProgramCodeType"/> <xs:element name="Note" type="NoteType" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType>  <xs:simpleType name="CurricularProgramCodeType"> <xs:annotation> <xs:documentation> C odigo identificador do plano de estudos no contexto da instituic ao respons avel pelo curso. </xs:documentation> </xs:annotation> <xs:restriction base="xs:string"/> </xs:simpleType>  <xs:simpleType name="DegreeCodeType"> <xs:annotation> <xs:documentation> Identificador de um curso, definido pela entidade respons avel pelo curso. </xs:documentation> </xs:annotation> <xs:restriction base="xs:string"/> </xs:simpleType>  <xs:simpleType name="DegreeLevelType"> <xs:annotation> <xs:documentation> Grau acad emico oferecido pelo curso: bacharelamento, licenciatura, p os-graduac ao, mestrado ou doutoramento. </xs:documentation> </xs:annotation> <xs:restriction base="xs:string"> <xs:enumeration value="BD"> <xs:annotation> <xs:documentation>Bacharelamento.</xs:documentation> </xs:annotation> </xs:enumeration> <xs:enumeration value="GD"> <xs:annotation> <xs:documentation>Licenciatura (Graduac ao).</xs:documentation> </xs:annotation> </xs:enumeration> <xs:enumeration value="PD"> <xs:annotation> <xs:documentation>P os-Graduac ao.</xs:documentation> </xs:annotation> </xs:enumeration> <xs:enumeration value="MD"> <xs:annotation> <xs:documentation>Mestrado.</xs:documentation> </xs:annotation> </xs:enumeration> <xs:enumeration value="DD"> <xs:annotation> <xs:documentation>Doutoramento.</xs:documentation> </xs:annotation> </xs:enumeration> </xs:restriction> </xs:simpleType>  <xs:complexType name="AcademicSessionType"> <xs:annotation> <xs:documentation> Representac ao de uma sess ao acad emica, matr cula ou inscric ao. </xs:documentation> </xs:annotation> <xs:sequence> <xs:element name="AcademicSessionStartDate" type="xs:date" minOccurs="0"/> <xs:element name="AcademicSessionEndDate" type="xs:date" minOccurs="0"/> <xs:element name="Course" type="CourseType" minOccurs="0" maxOccurs="unbounded"> <xs:annotation> <xs:documentation> Inscric oes feitas pelo aluno durante este per odo.
144
970 971 972 973 974 975 976 977 978 979 980 981 982 983 984 985 986 987 988 989 990 991 992 993 994 995 996 997 998 999 1000 1001 1002 1003 1004 1005 1006 1007 1008 1009 1010 1011 1012 1013 1014 1015 1016 1017 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035 1036 1037 1038 1039 1040 1041 1042 1043 1044 1045 1046 1047 1048 1049 1050 1051 1052 1053 1054 1055 1056 1057 1058 1059
Cada inscric ao corresponde a uma disciplina. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="Thesis" type="ThesisType" minOccurs="0"> <xs:annotation> <xs:documentation> No caso de aluno de mestrado ou doutoramento, representa informac ao sobre a tese. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="Note" type="NoteType" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType>    <xs:complexType name="CourseType"> <xs:annotation> <xs:documentation> Disciplina. </xs:documentation> </xs:annotation> <xs:sequence> <xs:element name="CourseCode" type="CourseCodeType" minOccurs="0"/> <xs:element name="CourseName" type="xs:string"/> <xs:element name="CourseStartDate" type="xs:date" minOccurs="0"/> <xs:element name="CourseEndDate" type="xs:date" minOccurs="0"/> <xs:element name="CourseCreditUnits" type="CourseCreditUnitsType" minOccurs="0"> <xs:annotation> <xs:documentation> Unidades de cr edito desta disciplina segundo o sistema da instituic ao. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="CourseECTSCreditUnits" type="ECTSCreditUnitsType" minOccurs="0"> <xs:annotation> <xs:documentation> Unidades de cr edito desta disciplna segundo o sistema ECTS. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="CourseClassSize" type="xs:integer" minOccurs="0"> <xs:annotation> <xs:documentation> N umero de alunos inscritos na disciplina. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="CourseAcademicGrade" type="AcademicGradeType" minOccurs="0"> <xs:annotation> <xs:documentation> Classificac ao final do aluno. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="CourseECTSGrade" type="ECTSGradeType" minOccurs="0"> <xs:annotation> <xs:documentation> Classificac ao final na escala ECTS. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="CourseEquivalenceInformation" type="EquivalenceInformationType" minOccurs="0 " maxOccurs="unbounded"> <xs:annotation> <xs:documentation> Este elemento vai existir no caso desta disciplina ter sido feita por equival encia de uma outra. Permite ter v arias disciplinas a "contribuir" para esta. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="Contact" type="ContactType" minOccurs="0" maxOccurs="unbounded"> <xs:annotation> <xs:documentation> Contactos relativos ` a disciplina. Por exemplo: regente, p agina web. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="Note" type="NoteType" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType>  <xs:simpleType name="CourseCodeType"> <xs:annotation> <xs:documentation> C odigo identificador da disciplina, atribuido pela instituic ao repons avel pela disciplina. </xs:documentation> </xs:annotation>
145
1060 1061 1062 1063 1064 1065 1066 1067 1068 1069 1070 1071 1072 1073 1074 1075 1076 1077 1078 1079 1080 1081 1082 1083 1084 1085 1086 1087 1088 1089 1090 1091 1092 1093 1094 1095 1096 1097 1098 1099 1100 1101 1102 1103 1104 1105 1106 1107 1108 1109 1110 1111 1112 1113 1114 1115 1116 1117 1118 1119 1120 1121 1122 1123 1124 1125 1126 1127 1128 1129 1130 1131 1132 1133 1134 1135 1136 1137 1138 1139 1140 1141 1142 1143 1144 1145 1146 1147 1148 1149 1150
<xs:restriction base="xs:string"/> </xs:simpleType>  <xs:simpleType name="CourseCreditUnitsType"> <xs:restriction base="xs:decimal"/> </xs:simpleType>  <xs:simpleType name="ECTSCreditUnitsType"> <xs:annotation> <xs:documentation> European Credit Transfer System. </xs:documentation> </xs:annotation> <xs:restriction base="xs:decimal"/> </xs:simpleType>  <xs:simpleType name="AcademicGradeType"> <xs:annotation> <xs:documentation> Classificac ao segundo o sistema local. Por exemplo: 0..20; A..F. </xs:documentation> </xs:annotation> <xs:restriction base="xs:string"/> </xs:simpleType>  <xs:simpleType name="ECTSGradeType"> <xs:annotation> <xs:documentation> Classificac ao segundo o sistema ECTS. </xs:documentation> </xs:annotation> <xs:restriction base="xs:string"> <xs:enumeration value="A"> <xs:annotation> <xs:documentation> 10% dos alunos normalmente atingem este valor. EXCELENTE - desempenho unico, com erros pontuais. </xs:documentation> </xs:annotation> </xs:enumeration> <xs:enumeration value="B"> <xs:annotation> <xs:documentation> 25% dos alunos normalmente atingem este valor. MUITO BOM - acima da m edia, mas com alguns erros. </xs:documentation> </xs:annotation> </xs:enumeration> <xs:enumeration value="C"> <xs:annotation> <xs:documentation> 30% dos alunos normalmente atingem este valor. BOM - na geralidade um trabalho com qualidade, mas com erros importantes. </xs:documentation> </xs:annotation> </xs:enumeration> <xs:enumeration value="D"> <xs:annotation> <xs:documentation> 25% dos alunos normalmente atingem este valor. SATIFAT ORIO - interessante, mas com limitac oes significativas. </xs:documentation> </xs:annotation> </xs:enumeration> <xs:enumeration value="E"> <xs:annotation> <xs:documentation> 10% dos alunos normalmente atingem este valor. SUFICIENTE - o desempenho cumpre os crit erios m nimos. </xs:documentation> </xs:annotation> </xs:enumeration> <xs:enumeration value="FX"> <xs:annotation> <xs:documentation> INSUFICIENTE - algum trabalho extra e necess ario para obter os cr editos. </xs:documentation> </xs:annotation> </xs:enumeration> <xs:enumeration value="F"> <xs:annotation> <xs:documentation> INSUFICIENTE - consider avel trabalho extra e necess ario para obter os cr editos. </xs:documentation> </xs:annotation> </xs:enumeration>
146
1151 1152 1153 1154 1155 1156 1157 1158 1159 1160 1161 1162 1163 1164 1165 1166 1167 1168 1169 1170 1171 1172 1173 1174 1175 1176 1177 1178 1179 1180 1181 1182 1183 1184 1185 1186 1187 1188 1189 1190 1191 1192 1193 1194 1195 1196 1197 1198 1199 1200 1201 1202 1203 1204 1205 1206 1207 1208 1209 1210 1211 1212 1213 1214 1215 1216 1217 1218 1219 1220 1221 1222 1223 1224 1225 1226 1227 1228 1229 1230 1231 1232 1233 1234 1235 1236 1237 1238 1239 1240 1241 1242
</xs:restriction> </xs:simpleType>  <xs:complexType name="EquivalenceInformationType"> <xs:annotation> <xs:documentation> Informac ao sobre uma equival encia. </xs:documentation> </xs:annotation> <xs:sequence> <xs:element name="Degree" type="DegreeType"/> <xs:element name="Course" type="CourseType"/> <xs:element name="Note" type="NoteType" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType>    <xs:complexType name="ThesisType"> <xs:sequence> <xs:element name="ThesisDissertationTitle" type="xs:string"/> <xs:element name="ThesisDissertationSupervisor" type="xs:string" minOccurs="0" maxOccurs=" unbounded"/> <xs:element name="ThesisDissertationEvaluation" type="ThesisDissertationEvaluationType" minOccurs="0"/> <xs:element name="Note" type="NoteType" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType>  <xs:simpleType name="ThesisDissertationEvaluationType"> <xs:restriction base="xs:string"/> </xs:simpleType>    <xs:complexType name="HealthRecordType"> <xs:annotation> <xs:documentation> Informac ao sobre um registo de sa ude. </xs:documentation> </xs:annotation> <xs:sequence> <xs:element name="Examination" type="ExaminationType" minOccurs="0" maxOccurs="unbounded"/> <xs:element name="Immunization" type="ImmunizationType" minOccurs="0" maxOccurs="unbounded"/> <xs:element name="Note" type="NoteType" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType>  <xs:complexType name="ExaminationType"> <xs:annotation> <xs:documentation> Informac ao sobre um exame m edico. </xs:documentation> </xs:annotation> <xs:sequence> <xs:element name="ExaminationName" type="ExaminationNameType"/> <xs:element name="ExaminationCode" type="ExaminationCodeType" minOccurs="0"/> <xs:element name="ExaminationDate" type="ExaminationDateType" minOccurs="0"/> <xs:element name="ExaminationResult" type="ExaminationResultType" minOccurs="0"/> <xs:element name="Note" type="NoteType" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType>  <xs:simpleType name="ExaminationNameType"> <xs:restriction base="xs:string"/> </xs:simpleType>  <xs:simpleType name="ExaminationCodeType"> <xs:annotation> <xs:documentation> C odigo identificativo do exame, no sistema adoptado pela instituic ao. </xs:documentation> </xs:annotation> <xs:restriction base="xs:string"/> </xs:simpleType>  <xs:simpleType name="ExaminationDateType"> <xs:restriction base="xs:date"/> </xs:simpleType>  <xs:simpleType name="ExaminationResultType"> <xs:restriction base="xs:string"/> </xs:simpleType> 
147
1243 1244 1245 1246 1247 1248 1249 1250 1251 1252 1253 1254 1255 1256 1257 1258 1259 1260 1261 1262 1263 1264 1265 1266 1267 1268 1269 1270 1271 1272 1273 1274 1275 1276 1277 1278 1279 1280 1281 1282 1283 1284 1285 1286 1287 1288 1289 1290 1291 1292 1293 1294 1295 1296 1297 1298 1299 1300 1301 1302 1303 1304 1305 1306 1307 1308 1309 1310 1311 1312 1313 1314 1315 1316 1317 1318 1319 1320 1321 1322 1323 1324 1325 1326 1327 1328 1329 1330 1331 1332 1333 1334 1335 1336
<xs:complexType name="ImmunizationType"> <xs:annotation> <xs:documentation> Informac ao sobre uma vacina. </xs:documentation> </xs:annotation> <xs:sequence> <xs:element name="ImmunizationName" type="ImmunizationNameType"/> <xs:element name="ImmunizationCode" type="ImmunizationCodeType" minOccurs="0"/> <xs:element name="ImmunizationDate" type="ImmunizationDateType" minOccurs="0"/> <xs:element name="Note" type="NoteType" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType>  <xs:simpleType name="ImmunizationNameType"> <xs:restriction base="xs:string"/> </xs:simpleType>  <xs:simpleType name="ImmunizationCodeType"> <xs:annotation> <xs:documentation> C odigo identificativo da vacina, no sistema adoptado pela instituic ao. </xs:documentation> </xs:annotation> <xs:restriction base="xs:string"/> </xs:simpleType>  <xs:simpleType name="ImmunizationDateType"> <xs:restriction base="xs:date"/> </xs:simpleType>    <xs:complexType name="MilitaryRecordType"> <xs:annotation> <xs:documentation> Informac ao sobre a situac ao militar. </xs:documentation> </xs:annotation> <xs:sequence> <xs:element name="MilitaryStatus" type="MilitaryStatusType"/> <xs:element name="Note" type="NoteType" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType>  <xs:simpleType name="MilitaryStatusType"> <xs:restriction base="xs:string"> <xs:enumeration value="PP"> <xs:annotation> <xs:documentation>Adiado / Postponed.</xs:documentation> </xs:annotation> </xs:enumeration> <xs:enumeration value="DN"> <xs:annotation> <xs:documentation>Cumprida / Accomplished (Done).</xs:documentation> </xs:annotation> </xs:enumeration> <xs:enumeration value="RS"> <xs:annotation> <xs:documentation>Reserva / Reserve.</xs:documentation> </xs:annotation> </xs:enumeration> <xs:enumeration value="DA"> <xs:annotation> <xs:documentation>Inapto / Disable.</xs:documentation> </xs:annotation> </xs:enumeration> <xs:enumeration value="NA"> <xs:annotation> <xs:documentation>N ao Aplic avel / Not Applicable.</xs:documentation> </xs:annotation> </xs:enumeration> <xs:enumeration value="UK"> <xs:annotation> <xs:documentation>Desconhecido / Unknown.</xs:documentation> </xs:annotation> </xs:enumeration> </xs:restriction> </xs:simpleType>    <xs:complexType name="AcademicAwardType"> <xs:annotation> <xs:documentation> Pr emio acad emico. Recebido no contexto de uma matr cula numa instituic ao. </xs:documentation> </xs:annotation>
148
1337 1338 1339 1340 1341 1342 1343 1344 1345 1346 1347 1348 1349 1350 1351 1352 1353 1354 1355 1356 1357 1358 1359 1360 1361 1362 1363 1364 1365 1366 1367 1368 1369 1370 1371 1372 1373 1374 1375 1376 1377 1378 1379 1380 1381
<xs:sequence> <xs:element name="AcademicAwardName" type="AcademicAwardNameType" minOccurs="0"/> <xs:element name="AcademicAwardDate" type="AcademicAwardDateType" minOccurs="0"/> <xs:element name="Note" type="NoteType" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType>  <xs:simpleType name="AcademicAwardNameType"> <xs:restriction base="xs:string"/> </xs:simpleType>  <xs:simpleType name="AcademicAwardDateType"> <xs:restriction base="xs:date"/> </xs:simpleType>    <xs:complexType name="ExtraActivityType"> <xs:annotation> <xs:documentation> Tipo para representar uma actividade extra de qualquer ndole. </xs:documentation> </xs:annotation> <xs:sequence> <xs:element name="ExtraActivityName" type="ExtraActivityNameType"/> <xs:element name="ExtraActivityStartDate" type="xs:date" minOccurs="0"/> <xs:element name="ExtraActivityEndDate" type="xs:date" minOccurs="0"/> <xs:element name="ExtraActivityDescription" type="ExtraActivityDescriptionType" minOccurs="0" maxOccurs="unbounded"/> <xs:element name="Note" type="NoteType" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType>  <xs:simpleType name="ExtraActivityNameType"> <xs:restriction base="xs:string"/> </xs:simpleType>  <xs:simpleType name="ExtraActivityDescriptionType"> <xs:restriction base="xs:string"/> </xs:simpleType> </xs:schema>
Ap endice C o de Estat Agregac a sticas sobre Cursos

C.1
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59
o do Elemento DegreeStatistics Especicac a
<?xml version="1.0" encoding="utf-8"?> <xs:schema targetNamespace="http://schemas.up.pt/DegreeStatistics" xmlns="http://schemas.up.pt/DegreeStatistics" xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified">    <xs:element name="DegreeStatistics" type="DegreeStatisticsType"/>    <xs:complexType name="DegreeStatisticsType"> <xs:annotation> <xs:documentation> Estat sticas sobre um curso acad emico, relativas a um edic ao bem identificada. </xs:documentation> </xs:annotation> <xs:sequence> <xs:element name="DocumentInfo" type="DocumentInfoType"/> <xs:element name="DegreeIdentification" type="DegreeIdentificationType"/> <xs:element name="DegreeAcronym" type="DegreeAcronymType" minOccurs="0"> <xs:annotation> <xs:documentation> Sigla do curso. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="DegreeName" type="DegreeNameType"> <xs:annotation> <xs:documentation> Nome do curso. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="DegreeStatisticsStartDate" type="xs:date"> <xs:annotation> <xs:documentation> Data de in cio do per odo em relac ao ao qual s ao apresentadas as informac oes. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="DegreeStatisticsEndDate" type="xs:date"> <xs:annotation> <xs:documentation> Data de fim do per odo em relac ao ao qual s ao apresentadas as informac oes. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="DegreeFaculty" type="PersonsNumberType" minOccurs="0"> <xs:annotation> <xs:documentation> Docentes do curso. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="AdmissionVacancies" type="xs:integer" minOccurs="0"> <xs:annotation> <xs:documentation> Numeros Clausus do curso.
149
150
DE ESTATISTICAS APENDICE C. AGREGAC AO SOBRE CURSOS
60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150
</xs:documentation> </xs:annotation> </xs:element> <xs:element name="AcceptedApplicantsNumber" type="xs:integer" minOccurs="0"> <xs:annotation> <xs:documentation> N umero de candidatos ao curso aceites. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="AcceptedApplicantsGradeAverage" type="GradeValueType" minOccurs="0"> <xs:annotation> <xs:documentation> M edia aritm etica das notas de candidatura dos candidatos aceites. Representada na escala da instituic ao. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="AcceptedApplicantsGradeMedian" type="GradeValueType" minOccurs="0"> <xs:annotation> <xs:documentation> Mediana das notas de candidatura dos candidatos aceites. Representada na escala da instituic ao. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="AcceptedApplicantsGradeStandardDeviation" type="xs:decimal" minOccurs="0"> <xs:annotation> <xs:documentation> Desvio padr ao das notas de candidatura dos candidatos aceites. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="AcceptedApplicantsGradeMinimum" type="GradeValueType" minOccurs="0"> <xs:annotation> <xs:documentation> M nimo das notas de candidatura dos candidatos aceites. Representada na escala da instituic ao. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="AcceptedApplicantsGradeMaximum" type="GradeValueType" minOccurs="0"> <xs:annotation> <xs:documentation> M aximo das notas de candidatura dos candidatos aceites. Representada na escala da instituic ao. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="EnrolledStudents" type="PersonsNumberType" minOccurs="0"> <xs:annotation> <xs:documentation> Alunos inscritos no curso. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="EnrolledStudentsByCountry" type="PersonsByCountryType" minOccurs="0"> <xs:annotation> <xs:documentation> Alunos inscritos por paises. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="EnrolledStudentsByAge" type="PersonsByAgeType" minOccurs="0"> <xs:annotation> <xs:documentation> Alunos inscritos por idades. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="EnrolledStudentsByCurricularPeriod" type="PersonsByCurricularPeriodType" minOccurs="0"> <xs:annotation> <xs:documentation> Alunos inscritos por ano curricular do curso. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="EnrolledStudentsByEnrollmentsByCurricularPeriod" type=" PersonsByEnrollmentsByCurricularPeriodType" minOccurs="0"> <xs:annotation> <xs:documentation> N umero de inscric oes por per odo curricular. Exemplo: No 1o ano h a X alunos inscritos pela 1a vez, Y alunos inscritos pela 2a vez, ... </xs:documentation> </xs:annotation> </xs:element> <xs:element name="Graduates" type="PersonsNumberType" minOccurs="0"> <xs:annotation> <xs:documentation> N umero de diplomados. </xs:documentation> </xs:annotation>
DO ELEMENTO DEGREESTATISTICS C.1. ESPECIFICAC AO
151
151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241
</xs:element> <xs:element name="GraduatesByCountry" type="PersonsByCountryType" minOccurs="0"> <xs:annotation> <xs:documentation> N umero de diplomados por pa s. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="GraduatesByAge" type="PersonsByAgeType" minOccurs="0"> <xs:annotation> <xs:documentation> N umero de diplomados por idade. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="GraduatesByFinalGradeValue" type="PersonsByFinalGradeValueType" minOccurs="0 "> <xs:annotation> <xs:documentation> N umero de diplomados por m edia final. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="GraduatesByTotalEnrollments" type="PersonsByTotalEnrollmentsType" minOccurs= "0"> <xs:annotation> <xs:documentation> N umero de diplomados por n umero total de inscric oes. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="Note" type="NoteType" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType>    <xs:complexType name="DocumentInfoType"> <xs:sequence> <xs:element name="DocumentCode"/> <xs:element name="DocumentIssueDate"/> <xs:element name="DocumentIssuer"/> <xs:element name="Note" type="NoteType" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType>    <xs:complexType name="DegreeIdentificationType"> <xs:annotation> <xs:documentation> Identificador completo do curso. Construc ao: Pa s + Instituic ao + Curso. </xs:documentation> </xs:annotation> <xs:sequence> <xs:element name="CountryCode" type="CountryCodeType"/> <xs:element name="InstitutionCode" type="InstitutionCodeType"/> <xs:element name="DegreeCode" type="DegreeCodeType"/> </xs:sequence> </xs:complexType>  <xs:simpleType name="CountryCodeType"> <xs:annotation> <xs:documentation> Identificador de um pa s usando o c odigo num erico da norma ISO 3166-1. Exemplo: Portugal = 620. </xs:documentation> </xs:annotation> <xs:restriction base="xs:string"> <xs:pattern value="\d\d\d"/> </xs:restriction> </xs:simpleType>  <xs:simpleType name="InstitutionCodeType"> <xs:annotation> <xs:documentation> C odigo da instituic ao. O sistema usado deve ser definido para cada pa s. </xs:documentation> </xs:annotation> <xs:restriction base="xs:string"/> </xs:simpleType>  <xs:simpleType name="DegreeCodeType"> <xs:annotation> <xs:documentation> Identificador do curso. O sistema de identificac ao usado e definido pela instituic ao. </xs:documentation> </xs:annotation>
152
242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330
<xs:restriction base="xs:string"/> </xs:simpleType>  <xs:simpleType name="DegreeAcronymType"> <xs:restriction base="xs:string"/> </xs:simpleType>  <xs:simpleType name="DegreeNameType"> <xs:restriction base="xs:string"/> </xs:simpleType>    <xs:complexType name="PersonsByCountryType"> <xs:sequence> <xs:element name="CountryFrequency" maxOccurs="unbounded"> <xs:complexType> <xs:sequence> <xs:element name="CountryCode" type="CountryCodeType"/> <xs:element name="PersonsNumber" type="PersonsNumberType"/> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType>    <xs:complexType name="PersonsByAgeType"> <xs:sequence> <xs:element name="AgeFrequency" maxOccurs="unbounded"> <xs:complexType> <xs:sequence> <xs:element name="Age" type="xs:integer"/> <xs:element name="PersonsNumber" type="PersonsNumberType"/> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType>    <xs:complexType name="PersonsByCurricularPeriodType"> <xs:sequence> <xs:element name="CurricularPeriodFrequency" maxOccurs="unbounded"> <xs:complexType> <xs:sequence> <xs:element name="CurricularPeriod" type="CurricularPeriodType"> <xs:annotation> <xs:documentation> Per odo curricular. Exemplo: 1o ano, 2o ano; 1o semestre, 2o semestre; Representa a *ordem* deste per odo, no conjunto total de per odos. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="CurricularPeriodDuration" type=" CurricularPeriodDurationType"> <xs:annotation> <xs:documentation> Durac ao do per odo acad emico. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="PersonsNumber" type="PersonsNumberType"/> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType>    <xs:complexType name="PersonsByEnrollmentsByCurricularPeriodType"> <xs:sequence> <xs:element name="CurricularPeriodFrequency" maxOccurs="unbounded"> <xs:complexType> <xs:sequence> <xs:element name="CurricularPeriod" type="CurricularPeriodType"/> <xs:element name="CurricularPeriodDuration" type=" CurricularPeriodDurationType"/> <xs:element name="EnrollmentsFrequency" maxOccurs="unbounded"> <xs:complexType> <xs:sequence>
DO ELEMENTO DEGREESTATISTICS C.1. ESPECIFICAC AO
153
331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421
<xs:element name="Enrollments" type=" xs:integer"/> <xs:element name="PersonsNumber" type=" PersonsNumberType"/> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType>    <xs:complexType name="PersonsByFinalGradeValueType"> <xs:sequence> <xs:element name="FinalGradeValueFrequency" maxOccurs="unbounded"> <xs:complexType> <xs:sequence> <xs:element name="FinalGradeValue" type="GradeValueType"/> <xs:element name="PersonsNumber" type="PersonsNumberType"/> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType>    <xs:complexType name="PersonsByTotalEnrollmentsType"> <xs:sequence> <xs:element name="TotalEnrollmentsFrequency" maxOccurs="unbounded"> <xs:complexType> <xs:sequence> <xs:element name="TotalEnrollments" type="xs:integer"/> <xs:element name="PersonsNumber" type="PersonsNumberType"/> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType>    <xs:simpleType name="CurricularPeriodType"> <xs:annotation> <xs:documentation> Per odo curricular em quest ao: primeiro, segundo, terceiro, etc. </xs:documentation> </xs:annotation> <xs:restriction base="xs:integer"/> </xs:simpleType>    <xs:simpleType name="CurricularPeriodDurationType"> <xs:annotation> <xs:documentation> Durac ao do per odo curricular. </xs:documentation> </xs:annotation> <xs:restriction base="xs:duration"/> </xs:simpleType>    <xs:complexType name="PersonsNumberType"> <xs:annotation> <xs:documentation> N umero de pessoas por sexo. </xs:documentation> </xs:annotation> <xs:sequence> <xs:element name="Total" type="xs:integer" minOccurs="0"> <xs:annotation> <xs:documentation> O TotalStudents permite ter um valor, mesmo sem os dados parcelares segundo os sexos. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="Female" type="xs:integer" minOccurs="0"/> <xs:element name="Male" type="xs:integer" minOccurs="0"/> </xs:sequence> </xs:complexType>  
154
422 423 424 425 426 427 428 429 430 431 432 433
 <xs:simpleType name="GradeValueType"> <xs:restriction base="xs:string"/> </xs:simpleType>    <xs:simpleType name="NoteType"> <xs:restriction base="xs:string"/> </xs:simpleType> </xs:schema>
Ap endice D o de Informac o sobre Concentrac a a Recursos Humanos

D.1
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55
o do Elemento StaffRecord Especicac a
<?xml version="1.0" encoding="utf-8"?> <xs:schema targetNamespace="http://schemas.up.pt/StaffRecord" xmlns="http://schemas.up.pt/StaffRecord" xmlns:xs="http: //www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified">    <xs:element name="StaffRecord" type="StaffRecordType"/>    <xs:complexType name="StaffRecordType"> <xs:annotation> <xs:documentation> Funcion ario. </xs:documentation> </xs:annotation> <xs:sequence> <xs:element name="StaffIdentification" type="StaffIdentificationType"/> <xs:element name="StaffAcronym" type="StaffAcronymType" minOccurs="0"/> <xs:element name="Person" type="PersonType"/> <xs:element name="StaffCategory" type="StaffCategoryType" minOccurs="0"/> <xs:element name="StaffStatus" type="StaffStatusType" minOccurs="0"/> <xs:element name="Note" type="NoteType" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType>    <xs:complexType name="StaffIdentificationType"> <xs:annotation> <xs:documentation> Identificac ao de um funcion ario. A identificac ao do funcion ario e composta usando o c odigo do pa s, o c odigo da instituic ao e o c odigo do funcion ario. </xs:documentation> </xs:annotation> <xs:sequence> <xs:element name="CountryCode" type="CountryCodeType"/> <xs:element name="InstitutionCode" type="InstitutionCodeType"/> <xs:element name="StaffCode" type="StaffCodeType"/> </xs:sequence> </xs:complexType>  <xs:simpleType name="CountryCodeType"> <xs:annotation> <xs:documentation> Identificador de um pa s usando o c odigo num erico da norma ISO 3166-1. Exemplo: Portugal = 620. </xs:documentation> </xs:annotation> <xs:restriction base="xs:string"> <xs:pattern value="\d\d\d"/> </xs:restriction> </xs:simpleType>
155
156
DE INF. SOBRE RECURSOS HUMANOS APENDICE D. CONCENTRAC AO
56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145
 <xs:simpleType name="InstitutionCodeType"> <xs:annotation> <xs:documentation> C odigo da instituic ao no contexto do pa s. O sistema usado deve ser definido para cada pa s. </xs:documentation> </xs:annotation> <xs:restriction base="xs:string"/> </xs:simpleType>  <xs:simpleType name="StaffCodeType"> <xs:annotation> <xs:documentation> Identificador de cada funcion ario na instituic ao. </xs:documentation> </xs:annotation> <xs:restriction base="xs:string"/> </xs:simpleType>    <xs:simpleType name="StaffAcronymType"> <xs:restriction base="xs:string"/> </xs:simpleType>    <xs:complexType name="PersonType"> <xs:annotation> <xs:documentation> Definic ao do tipo para representar uma pessoa. </xs:documentation> </xs:annotation> <xs:sequence> <xs:element name="IdentificationCode" type="IdentificationCodeType" minOccurs="0" maxOccurs=" unbounded"> <xs:annotation> <xs:documentation> Uma pessoa pode ter v arios c odigos de identificac ao. Por exemplo, BI, NIF, etc. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="Name" type="NameType"/> <xs:element name="Birth" type="BirthType" minOccurs="0"/> <xs:element name="Deceased" type="DeceasedType" minOccurs="0"> <xs:annotation> <xs:documentation> Este elemento existe se a pessoa j a faleceu. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="Gender" type="GenderType" minOccurs="0"/> <xs:element name="MaritalStatus" type="MaritalStatusType" minOccurs="0"/> <xs:element name="Citizenship" type="CitizenshipType" minOccurs="0"/> <xs:element name="Residency" type="AddressType" minOccurs="0"> <xs:annotation> <xs:documentation> Resid encia "oficial", por isso s o pode ter uma inst ancia. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="Contact" type="ContactType" minOccurs="0" maxOccurs="unbounded"> <xs:annotation> <xs:documentation> Uma pessoa pode ter v arios contactos de v arios tipos. Por exemplo: telem ovel, telefone de casa, telefone do emprego, etc. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="Note" type="NoteType" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType>  <xs:complexType name="NameType"> <xs:annotation> <xs:documentation> Nome de uma pessoa. </xs:documentation> </xs:annotation> <xs:sequence> <xs:element name="Title" type="NameTitleType" minOccurs="0"/> <xs:element name="FirstName" type="FirstNameType" minOccurs="0"/> <xs:element name="MiddleName" type="MiddleNameType" minOccurs="0" maxOccurs="unbounded"/> <xs:element name="LastName" type="LastNameType" minOccurs="0"/> <xs:element name="FullName" type="FullNameType"/> <xs:element name="Note" type="NoteType" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence>
DO ELEMENTO STAFFRECORD D.1. ESPECIFICAC AO
157
146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239
</xs:complexType>  <xs:simpleType name="NameTitleType"> <xs:restriction base="xs:string"/> </xs:simpleType>  <xs:simpleType name="FirstNameType"> <xs:restriction base="xs:string"/> </xs:simpleType>  <xs:simpleType name="MiddleNameType"> <xs:restriction base="xs:string"/> </xs:simpleType>  <xs:simpleType name="LastNameType"> <xs:restriction base="xs:string"/> </xs:simpleType>  <xs:simpleType name="FullNameType"> <xs:restriction base="xs:string"/> </xs:simpleType>  <xs:complexType name="BirthType"> <xs:sequence> <xs:element name="BirthDate" type="xs:date"/> <xs:element name="BirthCity" type="CityType" minOccurs="0"/> <xs:element name="BirthCountry" type="CountryType" minOccurs="0"/> <xs:element name="Note" type="NoteType" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType>  <xs:complexType name="DeceasedType"> <xs:sequence> <xs:element name="DeceasedIndicator" type="xs:boolean"/> <xs:element name="DeceasedDate" type="xs:date" minOccurs="0"/> <xs:element name="Note" type="NoteType" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType>  <xs:simpleType name="GenderType"> <xs:restriction base="xs:string"> <xs:enumeration value="F"> <xs:annotation> <xs:documentation>Female / Feminino.</xs:documentation> </xs:annotation> </xs:enumeration> <xs:enumeration value="M"> <xs:annotation> <xs:documentation>Male / Masculino.</xs:documentation> </xs:annotation> </xs:enumeration> <xs:enumeration value="U"> <xs:annotation> <xs:documentation>Unspecified / N ao especificado.</xs:documentation> </xs:annotation> </xs:enumeration> </xs:restriction> </xs:simpleType>  <xs:simpleType name="MaritalStatusType"> <xs:restriction base="xs:string"> <xs:enumeration value="S"> <xs:annotation> <xs:documentation>Single / Solteiro.</xs:documentation> </xs:annotation> </xs:enumeration> <xs:enumeration value="M"> <xs:annotation> <xs:documentation>Maried / Casado.</xs:documentation> </xs:annotation> </xs:enumeration> <xs:enumeration value="D"> <xs:annotation> <xs:documentation>Divorced / Divorciado.</xs:documentation> </xs:annotation> </xs:enumeration> <xs:enumeration value="W"> <xs:annotation> <xs:documentation>Widowed / Vi uvo.</xs:documentation> </xs:annotation> </xs:enumeration> </xs:restriction> </xs:simpleType> 
158
240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328
<xs:simpleType name="CitizenshipType"> <xs:restriction base="CountryType"/> </xs:simpleType>  <xs:complexType name="IdentificationCodeType"> <xs:annotation> <xs:documentation> Definic ao do tipo para representar n umeros de identificac ao de cart oes. Por exemplo: bilhete de identidade, cart ao de contribuinte, etc. </xs:documentation> </xs:annotation> <xs:sequence> <xs:element name="IdentificationCodeCode" type="IdentificationCodeCodeType" minOccurs="0"> <xs:annotation> <xs:documentation> C odigo identificativo do sistema de identificac ao usado. Usar nos casos em que o sistema de identificac ao e um dos tipos pr edefinidos. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="IdentificationCodeDescription" type="IdentificationCodeDescriptionType"/> <xs:element name="IdentificationCodeValue" type="IdentificationCodeValueType"/> <xs:element name="IdentificationCodeIssuer" type="IdentificationCodeIssuerType"/> <xs:element name="IdentificationCodeIssueDate" type="IdentificationCodeIssueDateType" minOccurs="0"/> <xs:element name="IdentificationCodeExpirationDate" type="IdentificationCodeExpirationDateType " minOccurs="0"/> <xs:element name="Note" type="NoteType" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType>  <xs:simpleType name="IdentificationCodeCodeType"> <xs:annotation> <xs:documentation> C odigo identificativo do sistema de identificac ao usado. </xs:documentation> </xs:annotation> <xs:restriction base="xs:string"> <xs:enumeration value="BI"> <xs:annotation> <xs:documentation>Bilhete de Identidade.</xs:documentation> </xs:annotation> </xs:enumeration> <xs:enumeration value="NIF"> <xs:annotation> <xs:documentation>N umero de Identificac ao Fiscal.</xs:documentation> </xs:annotation> </xs:enumeration> <xs:enumeration value="NCC"> <xs:annotation> <xs:documentation>N umero da Carta de Conduc ao.</xs:documentation> </xs:annotation> </xs:enumeration> <xs:enumeration value="NSS"> <xs:annotation> <xs:documentation>N umero da Seguranc a Social.</xs:documentation> </xs:annotation> </xs:enumeration> <xs:enumeration value="NP"> <xs:annotation> <xs:documentation>N umero do Passaporte.</xs:documentation> </xs:annotation> </xs:enumeration> </xs:restriction> </xs:simpleType>  <xs:simpleType name="IdentificationCodeDescriptionType"> <xs:restriction base="xs:string"/> </xs:simpleType>  <xs:simpleType name="IdentificationCodeValueType"> <xs:annotation> <xs:documentation> C odigo segundo este sistema de identificac ao. Por exemplo, se estivermos a armazenar o n umero de BI, incluir aqui o pr oprio n umero. </xs:documentation> </xs:annotation> <xs:restriction base="xs:string"/> </xs:simpleType>  <xs:simpleType name="IdentificationCodeIssuerType"> <xs:annotation> <xs:documentation> Informac ao sobre o emissor do c odigo de identificac ao. Por exemplo: Estado (BI), DGV ( carta de conduc ao). </xs:documentation> </xs:annotation> <xs:restriction base="xs:string"/>
159
329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421
</xs:simpleType>  <xs:simpleType name="IdentificationCodeIssueDateType"> <xs:restriction base="xs:date"/> </xs:simpleType>  <xs:simpleType name="IdentificationCodeExpirationDateType"> <xs:restriction base="xs:date"/> </xs:simpleType>  <xs:complexType name="ContactType"> <xs:sequence> <xs:element name="ContactDescription" type="ContactDescriptionType"/> <xs:choice> <xs:element name="Address" type="AddressType"/> <xs:element name="Phone" type="PhoneType"/> <xs:element name="Email" type="EmailType"/> <xs:element name="URL" type="URLType"/> </xs:choice> <xs:element name="Note" type="NoteType" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType>  <xs:simpleType name="ContactDescriptionType"> <xs:restriction base="xs:string"/> </xs:simpleType>  <xs:complexType name="AddressType"> <xs:sequence> <xs:element name="AddressAttentionLine" type="AddressAttentionLineType" minOccurs="0" maxOccurs="unbounded"/> <xs:element name="AddressLine" type="AddressLineType" maxOccurs="unbounded"/> <xs:element name="AddressPostalCode" type="PostalCodeType"/> <xs:element name="AddressCity" type="CityType"/> <xs:element name="AddressCountry" type="CountryType"/> <xs:element name="Note" type="NoteType" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType>  <xs:complexType name="PhoneType"> <xs:sequence> <xs:element name="PhoneCountryCode" type="PhoneCountryCodeType" minOccurs="0"/> <xs:element name="PhoneNumber" type="PhoneNumberType"/> <xs:element name="PhoneNumberExtension" type="PhoneNumberExtensionType" minOccurs="0"/> </xs:sequence> </xs:complexType>  <xs:simpleType name="EmailType"> <xs:restriction base="xs:string"> <xs:pattern value="\w@\w\.\w"/> </xs:restriction> </xs:simpleType>  <xs:simpleType name="URLType"> <xs:restriction base="xs:anyURI"/> </xs:simpleType>  <xs:simpleType name="AddressAttentionLineType"> <xs:restriction base="xs:string"/> </xs:simpleType>  <xs:simpleType name="AddressLineType"> <xs:restriction base="xs:string"/> </xs:simpleType>  <xs:simpleType name="PostalCodeType"> <xs:restriction base="xs:string"/> </xs:simpleType>  <xs:simpleType name="CityType"> <xs:restriction base="xs:string"/> </xs:simpleType>  <xs:simpleType name="CountryType"> <xs:annotation> <xs:documentation> Identificador de um pa s usando o c odigo num erico da norma ISO 3166-1. </xs:documentation> </xs:annotation> <xs:restriction base="xs:string"> <xs:pattern value="\d\d\d"/>
160
422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512
</xs:restriction> </xs:simpleType>  <xs:simpleType name="PhoneCountryCodeType"> <xs:restriction base="xs:string"/> </xs:simpleType>  <xs:simpleType name="PhoneNumberType"> <xs:restriction base="xs:string"/> </xs:simpleType>  <xs:simpleType name="PhoneNumberExtensionType"> <xs:restriction base="xs:string"/> </xs:simpleType>    <xs:simpleType name="StaffStatusType"> <xs:annotation> <xs:documentation> Definic ao do tipo para representar o estado de um funcion ario numa instituic ao. </xs:documentation> </xs:annotation> <xs:restriction base="xs:string"> <xs:enumeration value="AC"> <xs:annotation> <xs:documentation>Activo / Active.</xs:documentation> </xs:annotation> </xs:enumeration> <xs:enumeration value="NA"> <xs:annotation> <xs:documentation>N ao Activo / Not Active.</xs:documentation> </xs:annotation> </xs:enumeration> <xs:enumeration value="RE"> <xs:annotation> <xs:documentation>Reformado / Retired.</xs:documentation> </xs:annotation> </xs:enumeration> </xs:restriction> </xs:simpleType>    <xs:simpleType name="StaffCategoryType"> <xs:annotation> <xs:documentation> Definic ao do tipo para representar a categoria de um funcion ario. </xs:documentation> </xs:annotation> <xs:restriction base="xs:string"> <xs:enumeration value="AT"> <xs:annotation> <xs:documentation>Assistente Estagi ario / Assistant Trainee.</xs:documentation > </xs:annotation> </xs:enumeration> <xs:enumeration value="AS"> <xs:annotation> <xs:documentation>Assistente / Assistant.</xs:documentation> </xs:annotation> </xs:enumeration> <xs:enumeration value="RS"> <xs:annotation> <xs:documentation>Bolseiro Investigac ao / Research Scholarship.</ xs:documentation> </xs:annotation> </xs:enumeration> <xs:enumeration value="SC"> <xs:annotation> <xs:documentation>Coordenador Secc ao / Section Coordinator.</xs:documentation> </xs:annotation> </xs:enumeration> <xs:enumeration value="SD"> <xs:annotation> <xs:documentation>Director Servic o / Service Director.</xs:documentation> </xs:annotation> </xs:enumeration> <xs:enumeration value="LD"> <xs:annotation> <xs:documentation>Director Licenciatura / Licentiateship Degree Director.</ xs:documentation> </xs:annotation> </xs:enumeration> <xs:enumeration value="MD"> <xs:annotation> <xs:documentation>Director Mestrado / MSc Degree Director.</xs:documentation> </xs:annotation> </xs:enumeration>
161
513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562
<xs:enumeration value="ID"> <xs:annotation> <xs:documentation>Director Faculdade / Institution Director.</xs:documentation > </xs:annotation> </xs:enumeration> <xs:enumeration value="SP"> <xs:annotation> <xs:documentation>Presidente Conselho Cient fico / Scientific Committee President.</xs:documentation> </xs:annotation> </xs:enumeration> <xs:enumeration value="PP"> <xs:annotation> <xs:documentation>Presidente Conselho Pedag ogico / Pedagogic Committee President.</xs:documentation> </xs:annotation> </xs:enumeration> <xs:enumeration value="DP"> <xs:annotation> <xs:documentation>Presidente Departamento / Department President.</ xs:documentation> </xs:annotation> </xs:enumeration> <xs:enumeration value="AP"> <xs:annotation> <xs:documentation>Professor Associado / Associate Professor.</xs:documentation > </xs:annotation> </xs:enumeration> <xs:enumeration value="XP"> <xs:annotation> <xs:documentation>Professor Auxiliar / Auxiliary Professor.</xs:documentation> </xs:annotation> </xs:enumeration> <xs:enumeration value="CP"> <xs:annotation> <xs:documentation>Professor Catedr atico / Cathedratic Professor.</ xs:documentation> </xs:annotation> </xs:enumeration> </xs:restriction> </xs:simpleType>    <xs:simpleType name="NoteType"> <xs:annotation> <xs:documentation> Tipo que representa um elemento gen erico para a definic ao de anotac oes. </xs:documentation> </xs:annotation> <xs:restriction base="xs:string"/> </xs:simpleType> </xs:schema>
162
Ap endice E Difus ao de Not cias da Universidade

E.1
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61
o do Elemento NewsItem Especicac a
<?xml version="1.0" encoding="utf-8"?> <xs:schema targetNamespace="http://schemas.up.pt/News" xmlns="http://schemas.up.pt/News" xmlns:xs="http://www.w3.org /2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified">    <xs:element name="NewsItem" type="NewsItemType"/>    <xs:complexType name="NewsItemType"> <xs:annotation> <xs:documentation> Item noticioso. </xs:documentation> </xs:annotation> <xs:sequence> <xs:element name="NewsItemIdentification" type="NewsItemIdentificationType"> <xs:annotation> <xs:documentation> Identificac ao do item noticioso. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="Title" type="TitleType"> <xs:annotation> <xs:documentation> T tulo da not cia. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="Date" type="DateType"> <xs:annotation> <xs:documentation> Data de publicac ao da not cia. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="ExpirationDate" type="ExpirationDateType" minOccurs="0"> <xs:annotation> <xs:documentation> Data de expirac ao da not cia. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="Description" type="DescriptionType"> <xs:annotation> <xs:documentation> Descric ao/corpo da not cia. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="Author" type="AuthorType" minOccurs="0"> <xs:annotation> <xs:documentation> Autor/respons avel pela not cia. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="Category" type="CategoryType" minOccurs="0" maxOccurs="unbounded">
163
164
DE NOTICIAS APENDICE E. DIFUSAO DA UNIVERSIDADE
62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153
<xs:annotation> <xs:documentation> Categoria(s) da not cia. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="URL" type="URLType" minOccurs="0"> <xs:annotation> <xs:documentation> Enderec o Web permanente para a not cia. </xs:documentation> </xs:annotation> </xs:element> </xs:sequence> </xs:complexType>    <xs:complexType name="NewsItemIdentificationType"> <xs:sequence> <xs:element name="CountryCode" type="CountryCodeType"> <xs:annotation> <xs:documentation> C odigo do pa s. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="InstitutionCode" type="InstitutionCodeType"> <xs:annotation> <xs:documentation> C odigo da instituic ao. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="NewsItemCode" type="NewsItemCodeType"> <xs:annotation> <xs:documentation> C odigo da not cia. </xs:documentation> </xs:annotation> </xs:element> </xs:sequence> </xs:complexType>  <xs:simpleType name="CountryCodeType"> <xs:annotation> <xs:documentation> Identificador de um pa s usando o c odigo num erico da norma ISO 3166-1. Exemplo: Portugal = 620. </xs:documentation> </xs:annotation> <xs:restriction base="xs:string"> <xs:pattern value="\d\d\d"/> </xs:restriction> </xs:simpleType>  <xs:simpleType name="InstitutionCodeType"> <xs:annotation> <xs:documentation> C odigo da instituic ao no contexto do pa s. O sistema usado deve ser definido para cada pa s. </xs:documentation> </xs:annotation> <xs:restriction base="xs:string"/> </xs:simpleType>  <xs:simpleType name="NewsItemCodeType"> <xs:annotation> <xs:documentation> Identificador da not cia, definido pela instituic ao. </xs:documentation> </xs:annotation> <xs:restriction base="xs:string"/> </xs:simpleType>  <xs:simpleType name="TitleType"> <xs:restriction base="xs:string"/> </xs:simpleType>  <xs:simpleType name="ExpirationDateType"> <xs:restriction base="xs:dateTime"/> </xs:simpleType>  <xs:simpleType name="DateType"> <xs:restriction base="xs:dateTime"/> </xs:simpleType>
DO ELEMENTO NEWSITEM E.1. ESPECIFICAC AO
165
154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173
 <xs:simpleType name="DescriptionType"> <xs:restriction base="xs:string"/> </xs:simpleType>  <xs:simpleType name="AuthorType"> <xs:restriction base="xs:string"/> </xs:simpleType>  <xs:simpleType name="CategoryType"> <xs:restriction base="xs:string"/> </xs:simpleType>  <xs:simpleType name="URLType"> <xs:restriction base="xs:anyURI"/> </xs:simpleType> </xs:schema>

Alternativas para A Interoperabilidade Entre Sistemas de Informacao Universitarios

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Alternativas para A Interoperabilidade Entre Sistemas de Informacao Universitarios

Uploaded by

Copyright:

Available Formats

FACULDADE DE E NGENHARIA DA U NIVERSIDADE DO P ORTO

Alternativas para a Interoperabilidade entre o Universit Sistemas de Informac a arios

Porto, Julho de 2004

Entities should not be multiplied beyond necessity, William of Ockahm (1285-1347/49)

16 6.16 6.17 6.18 6.19 6.20

o . . . . . . . . . . . . . . . . . . . . . . . . . 123 A.1 Modelo Entidade-Relac a

Cap tulo 1 o Introduc a

DA DISSERTAC 1.2. ORGANIZAC AO AO

Cap tulo 2 o Universit Sistemas de Informac a arios

UNIVERSITARIOS CAPITULO 2. SISTEMAS DE INFORMAC AO

es Universit As Organizac o arias

Figura 2.1: As Hierarquias Paralelas na Burocracia Prossional

NAS UNIVERSIDADES 2.2. OS SISTEMAS DE INFORMAC AO

o nas Universidades Os Sistemas de Informac a

UNIVERSITARIOS CAPITULO 2. SISTEMAS DE INFORMAC AO

Funcionalidades dos SIU

o Universit Tabela 2.1: Sistemas de Informac a arios avaliados

UNIVERSITARIOS CAPITULO 2. SISTEMAS DE INFORMAC AO

Tabela 2.2: N umero de funcionalidades por categoria

Tabela 2.3: N umero de funcionalidades por grupo e palavra-chave

Tabela 2.4: Exemplo de funcionalidades mais comuns nos sistemas avaliados

2.4. TROCA DE INFORMAC AO

Iniciativas Existentes no Contexto Acad emico

UNIVERSITARIOS CAPITULO 2. SISTEMAS DE INFORMAC AO

2.4. TROCA DE INFORMAC AO

2.4. TROCA DE INFORMAC AO

UNIVERSITARIOS CAPITULO 2. SISTEMAS DE INFORMAC AO

Cap tulo 3 ` Tecnologias de Apoio a Interoperabilidade

` INTEROPERABILIDADE CAPITULO 3. TECNOLOGIAS DE APOIO A

3.2. ARQUITECTURAS DISTRIBUIDAS

Arquitecturas Distribu das

` INTEROPERABILIDADE CAPITULO 3. TECNOLOGIAS DE APOIO A

` INTEROPERABILIDADE CAPITULO 3. TECNOLOGIAS DE APOIO A

o Ass 3.4.2 Interacc a ncrona

o dos Dados Colocac a

o 3.5.1 Mover a Interrogac a

DOS DADOS 3.5. COLOCAC AO

` INTEROPERABILIDADE CAPITULO 3. TECNOLOGIAS DE APOIO A

Consist encia dos Dados

o L o F Figura 3.4: Representac a ogica e Representac a sica

3.6. CONSISTENCIA DOS DADOS

o de Dados Figura 3.5: Protocolos de Replicac a

` INTEROPERABILIDADE CAPITULO 3. TECNOLOGIAS DE APOIO A

3.7. ENTREGA DOS DADOS

Entrega dos Dados

` INTEROPERABILIDADE CAPITULO 3. TECNOLOGIAS DE APOIO A

o dos Esquemas Classicac a

3.8 Revis ao das Tecnologias

DAS TECNOLOGIAS 3.8. REVISAO

Figura 3.8: Arquitectura EDI

` INTEROPERABILIDADE CAPITULO 3. TECNOLOGIAS DE APOIO A

Figura 3.9: Arquitectura baseada em Componentes

DAS TECNOLOGIAS 3.8. REVISAO

` INTEROPERABILIDADE CAPITULO 3. TECNOLOGIAS DE APOIO A

Figura 3.10: Arquitectura baseada em Servic os Web

Cap tulo 4 o do Problema Denic a

DO PROBLEMA CAPITULO 4. DEFINIC AO

Figura 4.1: Interoperabilidade Vertical e Horizontal

4.2. EIXOS DE INTEROPERABILIDADE

o de Casos de Estudo 4.3 Selecc a

DE CASOS DE ESTUDO 4.3. SELECC AO

Deve ser poss vel garantir a condencialidade de toda o ou parte da informac a

o Qualquer idioma pode ser usado na informac a transmitida