AKROS INFORMATICA S.R.L.
PRESTITO ILL PER SBN
Specifiche Funzionali per la realizzazione di un sistema di Prestito Interbibliotecario per il Servizio Bibliotecario Nazionale.
SVILUPPO PER: Istituto Centrale per il Catalogo Unico PPrrreeessstttiiitttooo IIILLLL PPeeerrr SSBBNN –– SSppeeeccciiifffiiiccchheee FFuunnzziiiooonnaallliii
Akros Informatica s.r.l. Via S.Cavina, 7 47100 Ravenna.
© 1999, Akros Informatica s.r.l.
REVISIONE: 4 del 31 marzo 2000 REDATTO DA VERIFICA E APPROVAZIONE VERIFICA E APPROVAZIONE RESPONSABILE PROGETTO RESPONSABILE PROGETTO FORNITORE COMMITTENTE Daniela Saccomandi Danila Silvagni Claudia Parmeggiani
MOTIVO REVISIONE: Aggiornamento Architettura ed analisi compreso le specifiche dell’ambiente di prova.
Versione Corrente La versione corrente di questo documento è reperibile, nei seguenti formati, presso il sito aziendale interno:
MS-Word '97: http://javasrv.akros.it/PrestitoILL/Analisi/Prestito ILL – Specifichev4.doc
Acrobat v3.0: http://javasrv.akros.it/PrestitoILL/Analisi/Prestito ILL – Specifichev4.pdf
Versioni Precedenti Le versioni precedenti verranno mantenuti in formato Adobe Acrobat (per sola lettura ):
Acrobat v3.0: http://javasrv.akros.it/PrestitoILL/Analisi/Prestito ILL – Specifichev3.pdf
Acrobat v3.0: http://javasrv.akros.it/PrestitoILL/Analisi/Prestito ILL – Specifichev2.pdf
Acrobat v3.0: http://javasrv.akros.it/PrestitoILL/Analisi/Prestito ILL – Specifichev1.pdf
Akros Informatica s.r.l. i Revisione 3 del 10 giugno 1999 PPrrreeessstttiiitttooo IIILLLL PPeeerrr SSBBNN –– SSppeeeccciiifffiiiccchheee FFuunnzziiiooonnaallliii
SSOOMMMMAARRIIOO
1 VINCOLI TECNOLOGICI ...... 2
1.1 TECNOLOGIE DEL PROGETTO AIDA...... 2 1.2 TECNOLOGIE DEI PROGETTI SBN E OPAC ...... 2 1.2.1 SBN/Unix...... 2 1.2.2 SBN OPAC ...... 2 1.3 AMBIENTE TARGET...... 3 1.3.1 Specifiche per L’Ambiente di Prova Presso ICCU ...... 3 1.3.2 Diagramma di Deployment : Ambiente di Prova...... 6 1.3.3 Note all’Ambiente Target ...... 7 2 ARCHITECTURAL MODEL ...... 8
2.1 GESTIONE SESSIONI...... 9 2.2 PERFORMANCE ...... 9 2.3 AUTENTICAZIONE E ACCESSO ...... 9 2.4 I DRIVER JDBC DI INFORMIX ...... 10 2.5 INTERNAZIONALIZZIONE...... 10 3 DESIGN MODEL...... 11
3.1 USE-CASE VIEW ...... 11 3.2 REQUISITI DEL PROGETTO INFORMATIVO ...... 12 3.3 SPECIFICHE GENERALI DEL SISTEMA INFORMATIVO ILL...... 12 3.4 SPECIFICHE FUNZIONALI DEL SISTEMA ILL...... 14 3.4.1 Descrizione della ‘Use Case View’ ...... 14 3.4.2 Class diagram...... 27 3.5 SPECIFICHE DI MASSIMA DI INTEGRAZIONE...... 28 3.5.1 Nota Tecnica Per Le Integrazioni ...... 28 3.5.2 Il Sistema OPAC...... 29 3.5.3 Integrazione con SBN Unix ...... 33 3.5.4 Integrazione con Sistemi Legacy...... 46 3.5.5 Integrazione con Sistemi Bancari ...... 47 3.5.6 Integrazione con Anagrafe Biblioteche ...... 49 4 STANDARD PER INTERFACCIA UTENTE...... 52
5 MODALITA’ DI REALIZZAZIONE...... 53
APPENDICE A: ELENCO RIFERIMENTI...... 54
APPENDICE B: TABELLA DELLE AZIONI E DEGLI STATI DI UNA RICHIESTA...... 56
APPENDICE C: DIAGRAMMI DI STATO DELLE RICHIESTE...... 57
APPENDICE D: CLASS DIAGRAM...... 61
Akros Informatica s.r.l. ii Revisione 3 del 10 giugno 1999 PPrrreeessstttiiitttooo IIILLLL PPeeerrr SSBBNN –– SSppeeeccciiifffiiiccchheee FFuunnzziiiooonnaallliii
PPRREESSTTIITTOO IILLLL PPEERR SSBBNN Progetto per la realizzazione di un sistema di Prestito Interbibliotecario per il Servizio Bibliotecario Nazionale.
ABSTRACT
Questo documento descrive le specifiche funzionali per la definizione e la realizzazione di un sistema centralizzato di gestione dei servizi interbibliotecari, rivolti all’utente finale: riproduzione, prestito di originale, localizzazioni.
Contiene inoltre le indicazioni di specifiche di massima per l’integrazione con i sistemi informativi interessati alla problematica.
Il sistema oggetto del presente studio gestisce la distribuzione di documenti in copia o in originale; per le tecnologie applicate e l’architettura scelta, il sistema è aperto alla gestione dei documenti in formato elettronico.
L’analisi funzionale descritta nel presente documento si basa sui risultati raggiunti dal progetto AIDA e sulla relativa documentazione, sui documenti forniti dal Committente come allegati alla richiesta di offerta (vedi Appendice A), e su quanto emerso nelle riunioni con il Comitato Tecnico di Progetto, composto da:
Dott.ssa Claudia Parmeggiani – Istituto Centrale per il Catalogo Unico (Funzionario Responsabile) Dott.ssa Lucia Bigliazzi – Biblioteca Nazionale Centrale Firenze Dott.ssa Dina Pasqualetti – Biblioteca Nazionale Centrale Firenze Dott. Giovanni Bergamin – Biblioteca Nazionale Centrale Firenze Dott. Valdo Pasqui – Settore Informatico e Telematico di Ateneo per l' Amministrazione e le Biblioteche - Università di Firenze
Nel presente progetto viene utilizzata la metodologia Object Oriented, in particolare si adotta la notazione UML (Unified Modeling Language).
Akros Informatica s.r.l. 1 Revisione 4 del 31 marzo 2000 PPrrreeessstttiiitttooo IIILLLL PPeeerrr SSBBNN –– SSppeeeccciiifffiiiccchheee FFuunnzziiiooonnaallliii
1 VINCOLI TECNOLOGICI
1.1 TECNOLOGIE DEL PROGETTO AIDA AIDA è un prodotto per la gestione di prestito interbibliotecario. Il progetto utilizza un'architettura client/server a 2-tier implementando il concetto di "fat client". Le tecnologie usate sono:
1. RDBMS: Oracle v7.
2. Network: Oracle SQL*Net su TCP/IP, Inoltre utilizza anche SMTP per comunicazione su WAN.
3. Client: Nat Systems, Inc. - NS-DK1 (Versione Corrente, June 1998: v1.54).
NS-DK1 è una collezione di "tools" per lo sviluppo di applicativi in una varietà di ambienti (GUI, CICS, 3D ecc..). In questo caso il "tool" viene usato per lo sviluppo dell'interfaccia GUI e la logica applicativa del sistema in ambiente Windows v3.1/3.11 utilizzando SQL*Net e TCP/IP per l'interfaccia ai dati.
1.2 TECNOLOGIE DEI PROGETTI SBN E OPAC
1.2.1 SBN/UNIX SBN/Unix è un prodotto basato su database relazionale con application server in COBOL e C e Client realizzato in PowerBuilder. Il prodotto segue un’architettura 3-tier (Database server, application server e application client) analogamente alle soluzioni adottate da un numero significativo di rivenditori software (ad esempio: IBM, Microsoft e Oracle). Middleware nel contesto è una implementazione di comunicazioni su TCP sockets fornito da Finsiel.
1. RDBMS: Informix Dynamic Server v7.x
2. Server: COBOL II (Microfocus) / SQL con o senza TP/Monitor Tuxedo.
3. Client: PowerBuilder v5.0.xx (upgrade corrente: v5.0.04).
1.2.2 SBN OPAC Il servizio OPAC di SBN viene fornito in ambiente BASIS Plus, utilizzando interfaccie HTML e Z39.50. Le tecnologie usate sono:
1. OS AIX v.4.1.5
2. Netscape Commerce Server
3. Linguaggio di scirpting: Perl
4. BASIS Plus (I.R.)
5. Z39.50 – SBNZeta ( Visual Basic) e SBNOlluit
Akros Informatica s.r.l. 2 Revisione 4 del 31 marzo 2000 PPrrreeessstttiiitttooo IIILLLL PPeeerrr SSBBNN –– SSppeeeccciiifffiiiccchheee FFuunnzziiiooonnaallliii
1.3 AMBIENTE TARGET L'ambiente target è definito negli allegati tecnici alla documentazione fornita (Appendice A):
1. Sun - Java Web Server v1.1.2 (Utilizza: JRE v1.1.4).
2. Sun - Java Development Kit v1.1.7B (JDK). Aggiornato al rilascio stabile corrente.
3. Sun - Java Servlet Development Kit v2.0 (JSDK).
4. Informix Dynamic Server v7.3 TC3 con Informix Client SDK v2.0 (comprende i driver JDBC per Informix).
5. Standard di Riferimento: HTTP v1.1, HTML v3.2 (4.0) con l'uso, minimale, di JScript / JavaScript.
6. Browsers di Riferimento:
Ø Netscape Comunicator v4.06.
Ø Microsoft Internet v4.01 Service Pack 1.
Ø Opera v3.50 32-bit (da notare che questo browser non supporta scripting in Jscript o JavaScript e supporta Java Applet tramite l’uso del plug-in fornito dalla Sun).
1.3.1 SPECIFICHE PER L’AMBIENTE DI PROVA PRESSO ICCU L’ambiente di prova si distingue dall’ambiente “Target” in quanto il suo scopo è limitato alla verifica funzionale del software e la verifica delle caratteristiche comportamentali del sistema. In questo senso l’ambiente di prova permette maggiore precisione nelle specifiche hardware per un’eventuale ambiente di gestione a regime.
La strategia proposta nei seguenti paragrafi è motivata da due fattori:
1. La mancanza di dati sul volume di richieste da gestire – tali dati possono essere ottenuti da un gruppo di biblioteche in base al loro fabbisogno esistente ed estrapolato per tutto il sistema:
Ad esempio Il Polo di Venezia fa una media di circa 50 richieste al mese e riceve una media circa 20 richieste al mese. Il polo rappresenta circa 10 biblioteche. In termini (molto approssimativi) si può ipotizzare che c’è un fabbisogno da parte del Polo di circa 100 transazioni al mese o (sempre arrotondando su in base a 20 gg. Lavorativi al mese) circa 5 transazioni al giorno o 0,5 transazioni per Biblioteca per giorno. Arrotondiamo ad 1 transazione /biblioteca al giorno. Ciò significa che il sistema deve sostenere un fabbisogno di almeno 2 transazioni / biblioteca al giorno (raddoppiato il risultato per gestire i picchi di utilizzo). Un sistema che coinvolge 5.000 biblioteche dovrà gestire 10.000 transazioni / giorno o circa 20 transazioni / minuto.
Il monitoraggio del sistema pilota permetterà di calcolare il fabbisogno hardware del sistema definitivo in congiunzione con i dati sopra (o dati più precisi reperiti nel frattempo).
2. Gli eventuali responsabili amministrativi del sistema potranno porre vincoli ulteriori sul software di base e hardware da utilizzare per motivi di costi gestionali ed in base alle valutazioni effettuate nel periodo di valutazione del sistema pilota (vedi sotto).
Akros Informatica s.r.l. 3 Revisione 4 del 31 marzo 2000 PPrrreeessstttiiitttooo IIILLLL PPeeerrr SSBBNN –– SSppeeeccciiifffiiiccchheee FFuunnzziiiooonnaallliii
La strategia proposta per l’avviamento del servizio è:
1. Fase di prova · Utilizza ambiente di prova. · Periodo previsto dal progetto. · Coinvolge personale del progetto. · Verifica funzionale del sistema.
2. Servizio Pilota · Utilizza ambiente di prova. · Periodo: da 3-6 mesi. · Coinvolge un numero selezionato di Biblioteche (da 50-200). · Monitoraggio controllato di prestazioni del sistema e definizione di procedure amministrative e gestionali.
3. Servizio Definitivo · Utilizza ambiente definitivo. · Periodo: permanente. · Coinvolge tutte le biblioteche. · Attivazione di servizi di monitoraggio e gestione identificati nella fase precedente.
1.3.1.1 Ambiente di Prova – Specifiche Tecniche
Le specifiche tecniche forniti nella seguente tabella dell’ambiente di prova (pilota) corrispondono alle specifiche dell’ambiente di sviluppo:
ü L’ambiente di sviluppo è già implementato ed il software di base ed applicativo è attivo e provato a livello funzionale. ü I costi sono minimi e l’hardware dell’ambiente di prova è recuperabile come client (ad esempio per la produzione grafica) o server interno (ad esempio di documenti) dopo il periodo Pilota.
L’uso di ambienti Unix nella fase pilota rientra negli obiettivi del progetto. Le specifiche tecniche dell’ambiente pilota nel caso dell’uso di un ambiente Unix sono equivalenti a quelli per Windows NT:
1. Hardware dovrà fornire capacità di processo equivalente a quello specificato nella tabella seguente.
2. Software di base (Informix, JDK/JRE e Java Web Server) devono essere le versioni equivalenti per il sistema operativo scelto.
Bisogna notare che mentre la SUN è il fornitore del software di base (JDK/JRE e Java Web Server) per ambienti Solaris (Intel o SPARC) e Windows ciò non è il caso per IBM/AIX. La scelta di IBM / AIX comporta l’uso di prodotti equivalenti forniti da IBM che possono comportare problemi di “porting” (anche se l’uso di Java nel contesto minimizza il rischio).
La predisposizione dell’ambiente Hardware (Server) e Software di Base viene effettuata dai tecnici del Committente.
Akros Informatica s.r.l. 4 Revisione 4 del 31 marzo 2000 PPrrreeessstttiiitttooo IIILLLL PPeeerrr SSBBNN –– SSppeeeccciiifffiiiccchheee FFuunnzziiiooonnaallliii
Le specifiche hardware articolano caratteristiche generali e d’esempio, e possono variare al momento dell’ acquisto.
HARDWARE COMMENTI MONITOR 15” SVGA/VESA Recupero come stazione grafica richiederebbe la sostituzione con un monitor da 17”-21”. SCHEDA MADRE: Intel 440 BX AGPset Viene sfruttato sia dal sistema operativo che PROCESSORI 2x Intel Pentium II 350/400 dal server Informix ed il Java Web Server. (Velocità di CPU non è vista come un fattore critico – quello che conta è la capacità multi- processing). MEMORIA DIMM 256 Mbyte Più memoria meglio è – particolarmente per il server Web. FDD 1,44 Mbyte CD-ROM Standard 20-32x Per installazione HDD 9 Gbyte (SCSI 2 o 3) Il sottosistema I/O è configurato per velocità Es: IBM Ultrastar 9ES DDRS-39130 più che affidabilità (quello che serve per il SCHEDA SCSI Dual-Channel recupero come server o stazione grafica). Es: Adaptec 789x o 389x Il sistema definitivo dovrebbe specificare anche per affidabilità – quindi RAID 0-5. SCHEDA VIDEO Matrox G200 AGP Previsto recupero come stazione grafica… se non, si può usare una scheda qualunque. SCHEDA RETE Da amministratore di rete presso ICCU Specifiche dipendono dalla rete. SISTEMA BACKUP Da amministratore di rete presso ICCU Può essere effettuato in remoto da altro server già attrezzato allo scopo. SOFTWARE DI BASE WINDOWS NT V4.0 (ENTERPRISE) SERVER Si può usare Workstation se esiste una versione adeguata di Informix (7.3) con GLS installato su un altro sistema che può gestire il database. WINDOWS NT V4.0 SERVICE PACK 3 (4) Il service pack 4 è richiesto per compatibilità Y2K, ma sembra esista un problema con Informix DS v7.3 TC3. Comunque SP3 è necessario. SUN JRE V1.1.7B PER WINDOWS 32-BIT Solo il runtime è richiesto e sostituisce la v1.1.4 del runtime fornito con il Java Web Server. SUN JAVA WEB SERVER V1.1 Aggiornamento a v1.1.2 non è necessario. (Fino al collegamento con il sistema bancario è sufficiente solo il basic authentication per l’accesso al sistema). INFORMIX DYNAMIC SERVER V7.3.00 TC3 La versione correntemente disponibile ed in uso per lo sviluppo. Nel caso in cui si usi un server remoto questo può essere sostituito con l’ INFORMIX CLIENT SDK v2.0 o superiore che fornisce i driver JDBC.
Akros Informatica s.r.l. 5 Revisione 4 del 31 marzo 2000 PPrrreeessstttiiitttooo IIILLLL PPeeerrr SSBBNN –– SSppeeeccciiifffiiiccchheee FFuunnzziiiooonnaallliii
1.3.2 DIAGRAMMA DI DEPLOYMENT : AMBIENTE DI PROVA
Deployment Diagram
OPAC SBN Anagrafe Biblioteche
TCP/IP Network LAN a 10/100 mbps. <
preemptive
ILL Web Server ILL Database ILL Application TCP/IP Network LAN, Private WAN o Internet
<
Web Browser E-Mail Client
Akros Informatica s.r.l. 6 Revisione 4 del 31 marzo 2000 PPrrreeessstttiiitttooo IIILLLL PPeeerrr SSBBNN –– SSppeeeccciiifffiiiccchheee FFuunnzziiiooonnaallliii
1.3.3 NOTE ALL’AMBIENTE TARGET
1.3.3.1 Sistemi Operativi e Hardware (Ambiente Definitivo)
S’intende seguire un obiettivo che utilizza hardware e sistemi operativi già in uso presso ICCU dove possibile. La scelta per l’ambiente definitivo si riduce ai seguenti elementi base hardware e sistemi operativi:
ü Piattaforma Intel multi-processore con Windows NT v4 sp4.
ü Piattaforma SPARC singolo/multi-processore con Solaris v7.x.
ü Piattaforma PowerPC / Risc singolo/multi-processore con AIX v4.x.
1.3.3.2 Uso di Java
· La documentazione del Sun Java Web Server indica compatibilità con la release 1.1.x del JDK. S’intende usare la versione più recente del JDK 1.1.x distribuita dalla Sun che è diffusa negli ambienti di sviluppo. Questo significa la versione 1.1.6 (presente in Borland Jbuilder v2 e IBM Visual Age for Java v2 e distribuita per piattaforme IBM). La versione 1.1.7B è ora stabile sia per Solaris che per Windows NT.
· L’uso della versione 1.2 del JDK potrà essere valutato verso la fine del progetto (in termini dell’ambiente target). Qualche attenzione dovrà essere prestata a questa versione in quanto le dichiarazioni della Sun indicano una stabilità a lungo termine per quest’ambiente e per le funzionalità implementate, che nel caso del progetto sono:
ü Un “lightweight” ORB con l’inclusione dei package org.omg.CORBA.
ü Miglioramenti nella sicurezza, in particolare l’implementazione di certificati X.509 v3.
Queste funzionalità si riveleranno importanti nel contesto di applicativi che devono interagire con le Banche e sistemi “legacy”. Oltre a questo, ci sono notevoli miglioramenti di performance e funzioni di programmazione e debug.
1.3.3.3 Web Server La specifica del Java Web Server non costituisce, necessariamente, una limitazione a questo progetto. S’intende seguire lo standard specificato dalla Sun nel JSDK v2.0, che porta ad una compatibilità con diversi server web sul mercato (ad esempio: Apache Web Server, IBM Internet Connection Secure Server). Inoltre esistono diversi motori aggiuntivi che permettono l’uso di “servlet” con server esistenti (ad esempio: New Atlanta Communications Servlet Exec che funziona con una varietà di server di Netscape e Microsoft). Un elenco completo si trova alla URL:
http://java.sun.com/products/servlet/runners.html.
1.3.3.4 Data Base Il database è stato scelto in conformità con le specifiche di SBN/Unix. L’uso di JDBC e SQL permetterà un notevole riduzione dei costi di porting, nel caso in cui si verifichino esigenze d’uso di un altro data base relazionale.
Akros Informatica s.r.l. 7 Revisione 4 del 31 marzo 2000 PPrrreeessstttiiitttooo IIILLLL PPeeerrr SSBBNN –– SSppeeeccciiifffiiiccchheee FFuunnzziiiooonnaallliii
2 ARCHITECTURAL MODEL
L’architettura del sistema è rappresentata da un ‘web based application server’, realizzato in Java utilizzando il Java Servlet Development Kit e JDBC.
Component Diagram: Implementazione
Accesso via POST URL al Java Web Server. Due URL: 1. per accesso ai servizi POS che richiede login. 2. per accesso ai servizi che non richiedono autenticazione.
Accesso con javax.http.* richiesta di login Accesso senza utilizza "Basic richiesta di login Authentication"
<
ILL.jar
<>
Accesso al databse ILL via i drivers JDBC forniti da Informix Client SDK v2.0.
Akros Informatica s.r.l. 8 Revisione 4 del 31 marzo 2000 PPrrreeessstttiiitttooo IIILLLL PPeeerrr SSBBNN –– SSppeeeccciiifffiiiccchheee FFuunnzziiiooonnaallliii
Le componenti architetturali dell’eventuale prodotto sono basate su un archivio JAR che contiene le classi e i package del sistema, e una directory di file(s) HTML che contengono le maschere. Le due classi ILLSession e ILLPublicSession svolgono un ruolo di gestori di sessioni per utenti autenticati e non-autenticati.
I file(s) HTML sono costruiti (e possono essere mantenuti e/o customizzati) utilizzando un normale editore HTML. Nelle pagine HTML viene incluso codice, in forma di commenti, che viene sostituito dal programma con i dati dinamici recuperati dal database.
La forma dei commenti sostituiti è:
Quest’architettura permette all’utente stesso di gestire l’aspetto estetico dell’interfaccia con editori HTML del tipo HoTMetaL o Front Page.
L’uso di ‘servlet includes’ (funzionalità presente nel Java Web Server e che svolge lo stesso lavoro), che rappresenta l’equivalente in Java di ‘Active Server Pages’ e viene implementato con il tag
I seguenti capitoli descrivono i cinque aspetti architetturali che rappresentano gli obiettivi di verifica e valutazione del prototipo architetturale del sistema.
2.1 GESTIONE SESSIONI Il Java Web Server fornisce due meccanismi per la gestione delle sessioni:
Ø Cookies: questo è il metodo preferito in si è dimostrato veloce ed efficiente.
Ø URL Re-POSTING: è più universale nell’applicabilità ai browser web ma significativamente meno efficiente.
L’utilizzo di Cookie Protocol è stato verificata con i tre browser indicati per la soluzione (Netscape, IE e Opera) e quindi viene usata nel progetto per la gestione delle sessioni con l’utente.
Questa scelta implica che l’utente che vuole attivare le funzionalità ILL sul proprio browser deve configurare il browser stesso per l’accettazione dei Cookies.
2.2 PERFORMANCE Oltre alla gestione delle sessioni, ci sono alcune considerazioni che riguardano le prestazioni del sistema, e che si configurano come decisioni architetturali:
Ø L’uso di “Buffered Reads” per file I/O ed il class StringBuffer per le sostituzioni descritte sopra sono notevolmente più efficienti delle alternative (ad esempio: tokenizing le stringhe).
Ø La gestione di thread (multi-threading), particolarmente per gli accessi alla banca dati che vengono avviati un un thread separato.
2.3 AUTENTICAZIONE E ACCESSO L’accesso a molti servizi del sistema ILL richiede una forma di autenticazione per identificare la biblioteca che richiede un servizio o risponde ad una richiesta. Tale sistema presume la gestione di LOGIN/PASSWORD.
Akros Informatica s.r.l. 9 Revisione 4 del 31 marzo 2000 PPrrreeessstttiiitttooo IIILLLL PPeeerrr SSBBNN –– SSppeeeccciiifffiiiccchheee FFuunnzziiiooonnaallliii
Il sistema ILL non gestisce le PASSWORD dell’utente al suo interno. Il sistema di autenticazione proposto è quello fornito dal server Java e chiamato Basic Authentication , che si basa su ACL (Access Control Lists mantenute dal server). Tale sistema è in grado di interfacciarsi con il sistema di autenticazione in uso nel sistema operativo (Unix e NT), ed è ritenuto sufficiente agli scopi del sistema base (senza transazioni finanziarie). Tale sistema può essere utilizzato senza la richiesta di certificati od altri meccanismi di autenticazione da parte di utenti e fornitori del servizio.
L’eventuale interfaccia con sistemi bancari e l’implementazione di meccanismi per il trasferimento di denaro richiederebbe una maggiore sofisticazione nei protocolli di sicurezza, (quindi SSL o TLS) che implicano un ulteriore carico amministrativo nell’acquisto e distribuzione di certificati. L’uso di basic authentication predispone il sistema all’utilizzo di gestori di sicurezza esterni e quindi, in un senso limitato, prevede l’uso di sistemi di sicurezza ed autenticazione più evoluti.
All’interno dell’applicativo lo USERID viene utilizzato per limitare o restringere l’accesso a gruppi di funzioni definite e gestite dalla figura dell’amministratore del sistema.
2.4 I DRIVER JDBC DI INFORMIX S’intende la verifica della funzionalità (ed eventualmente la portabilità) dei driver JDBC forniti con l’Informix Client SDK v2.0.
2.5 INTERNAZIONALIZZIONE L’architettura prevede la possibilità di estendere l’interfaccia ad un uso internazionale utilizzando i meccanismi di internazionalizzazione (locale ed i ResourceBundle) per gestire i messaggi e le componenti dinamiche delle pagine HTML.
I file(s) HTML per locali diversi verranno tenuti in directory diverse; si utilizzano i meccanismi ISO per identificare le directory che contengo le pagine per un particolare locale. In questo contesto le pagine vengono comunque realizzate utilizzando il set di caratteri ISO-8859-1 (Latin-1), e non UTF-8 per motivi di compatibilità con la maggioranza di configurazioni di browser.
Akros Informatica s.r.l. 10 Revisione 4 del 31 marzo 2000 PPrrreeessstttiiitttooo IIILLLL PPeeerrr SSBBNN –– SSppeeeccciiifffiiiccchheee FFuunnzziiiooonnaallliii
3 DESIGN MODEL
3.1 USE-CASE VIEW
Figura 1 : Use-Case view ‘Sistema ILL’
Sistema ILL fornisce titolo
Immette richiesta ILL
OPAC
Individua DSC
Ric. prestito Ric. riproduzione Ric. localizzazione Ric. Preventivo Utente
Visualizza stato richieste Anagrafe Biblioteche
Gestione richiesta ILL
Pagamento servizio Biblioteca richiedente
Gest. ILL Prestito Gest. ILL preventivo Gest. ILL riprod. Gest. lLL localiz.
Gestione notifiche
Gestione Utenti/servizi
Biblioteca Identificazione Utente ILL destinataria
Utente Gestore Elabora Statistiche SBN ILL
Akros Informatica s.r.l. 11 Revisione 4 del 31 marzo 2000 PPrrreeessstttiiitttooo IIILLLL PPeeerrr SSBBNN –– SSppeeeccciiifffiiiccchheee FFuunnzziiiooonnaallliii
3.2 REQUISITI DEL PROGETTO INFORMATIVO Il presente progetto si propone di integrare quanto previsto nel modello tradizionale di prestito interbibliotecario con quanto emerso dalle diverse esperienze di realizzazione su questa problematica (vari software SBN, progetto AIDA).
Un altro obiettivo è fornire un sistema che possa agevolmente essere integrabile con le componenti che si occupano di problematiche concernenti sistemi OPAC, sistemi bancari, sistemi legacy.
Vanno inoltre individuate le specifiche per consentire una integrazione stretta con il software Sbn-Unix Client/Server, in corso di realizzazione.
In sintesi, gli obiettivi del progetto si possono così elencare:
1. produzione delle specifiche funzionali per la realizzazione di un Sistema ILL, che abbia le caratteristiche descritte nel paragrafo successivo; 2. produzione di “specifiche di massima” relativamente alla descrizione delle integrazioni con · il Sistema OPAC, · il software Sbn-Unix Client/Server, · i sistemi legacy, · i sistemi bancari, · il sistema di anagrafe delle biblioteche; 3. realizzazione di un sottoinsieme di servizi ILL, costituito dalle funzionalità indicate nel capitolo 5.
Per l’attività di analisi e la produzione delle specifiche, si segue una metodologia Object Oriented, utilizzando in particolare la notazione UML (Unified Modeling Language).
Viene prodotto il ‘class diagram’ del sistema, che ne definisce le classi in termini di attributi e metodi, e le relazioni tra le classi.
3.3 SPECIFICHE GENERALI DEL SISTEMA INFORMATIVO ILL Il Sistema ILL complessivo deve consentire le seguenti tipologie di servizi:
· richieste di prestito di un documento, · richieste di riproduzione di un documento, · richieste di localizzazione di un documento.
Deve inoltre soddisfare le seguenti esigenze:
· accessibilità agli utenti finali, · accessibilità da sistemi legacy , · predisposizione per l’integrazione con attività di competenza di sistemi bancari.
Il Sistema ILL si configura quindi come un applicativo composto da una serie di ‘servizi’, implementati su un server web, e dalle relative funzionalità di interfaccia utente gestite tramite browser web.
I servizi devono inoltre disporre di una modalità di attivazione ‘pubblica’, per consentirne l’attivazione da parte di sistemi che vogliano predisporre una propria interfaccia utente, integrata con le proprie funzionalità.
Akros Informatica s.r.l. 12 Revisione 4 del 31 marzo 2000 PPrrreeessstttiiitttooo IIILLLL PPeeerrr SSBBNN –– SSppeeeccciiifffiiiccchheee FFuunnzziiiooonnaallliii
L’integrazione con il sistema OPAC rappresenta un aspetto fondamentale per il raggiungimento dell’obiettivo del progetto. Il modello funzionale prevede infatti il recupero delle informazioni bibliografiche, da inserire come oggetto della richiesta ILL.
Per quanto riguarda la definizione dettagliata delle specifiche funzionali del sistema ILL, si fa riferimento alla analisi prodotta dal progetto AIDA, integrata con le richieste funzionali espresse nei documenti ‘Allegato 1’ e ‘Allegato 4’ (vedi Appendice A).
In dettaglio, queste integrazioni riguardano:
· la possibilità per l’utente finale di immettere richieste di riproduzione o localizzazione, e di visualizzare lo stato delle proprie richieste ILL, attraverso la rete Internet e senza dover necessariamente rivolgersi a una biblioteca; · la possibilità di affidare la gestione dei pagamenti e/o della consegna dei documenti a gestori esterni al sistema (di tipo bancario).
Le modalità di integrazione con i sistemi informativi sono descritte nel capitolo ‘Specifiche di massima di integrazione’.
Akros Informatica s.r.l. 13 Revisione 4 del 31 marzo 2000 PPrrreeessstttiiitttooo IIILLLL PPeeerrr SSBBNN –– SSppeeeccciiifffiiiccchheee FFuunnzziiiooonnaallliii
3.4 SPECIFICHE FUNZIONALI DEL SISTEMA ILL
3.4.1 DESCRIZIONE DELLA ‘USE CASE VIEW’
3.4.1.1 Attori
Con il termine ‘attore’ si intende una entità (persona fisica o sistema informativo) che interagisce con lo scenario in cui si svolgono le attività del sistema informativo che si sta descrivendo.
Sono stati individuati i seguenti attori:
1) Utente Rappresenta la persona che accede al sistema ILL, utilizzando un browser web, ed è interessata ad usufruire dei servizi disponibili: prestito, riproduzione, richiesta di localizzazione.
L’accesso diretto al sistema da parte dell’utente finale è la maggiore novità rispetto al modello ILL tradizionale.
Le funzionalità individuate, accessibili direttamente dall’utente finale, sono:
ü immissione nuove richieste ( vedi use case ‘Immette richiesta ILL’); ü visualizzazione delle proprie richieste, immesse direttamente o da una biblioteca POS(vedi use case ‘Visualizza stato richieste’).
La biblioteca che offre il servizio POS ai propri iscritti, deve comunicare a questi ultimi il proprio codice identificativo nell’ambito del sistema ILL (si veda paragrafo ‘Specifiche di massima: integrazione con anagrafe biblioteche’).
L’utente che accede al sistema e immette una richiesta, digita i propri dati (nome, indirizzo, e-mail) che vengono registrati sulla richiesta. Può inserire inoltre il codice identificativo del POS di riferimento e il proprio codice lettore nella biblioteca POS: questi dati sono obbligatori in caso di richiesta di prestito (se la biblioteca gestisce un archivio automatizzato: vedi paragrafo successivo ).
L’utente finale che è iscritto in una biblioteca può visualizzare le richieste digitando il proprio e-mail, associato a:
§ il numero identificativo della richiesta; § il codice della biblioteca POS, il proprio codice identificativo di iscrizione nella biblioteca POS. L’utente finale che non è iscritto in una biblioteca POS, (o non ha comunicato i propri dati di iscrizione al momento della immissione della richiesta), può esaminare la richiesta digitando il proprio e-mail e il numero identificativo della richiesta stessa nel sistema ILL.
Se la biblioteca POS non si è dotata di un sistema gestionale informatico (cioè non gestisce il codice identificativo dei propri lettori ), deve comunicarlo all’Utente Gestore ILL (vedi punto 6), che provvederà a settare un apposito indicatore relativo alla biblioteca, in modo da escludere la richiesta di comunicazione relativa a questo dato, rendendo obbligatoria per l’utente finale la digitazione di ‘cognome e nome’ (l’e-mail è sempre obbligatoria).
2) Biblioteca richiedente
Akros Informatica s.r.l. 14 Revisione 4 del 31 marzo 2000 PPrrreeessstttiiitttooo IIILLLL PPeeerrr SSBBNN –– SSppeeeccciiifffiiiccchheee FFuunnzziiiooonnaallliii
Rappresenta la biblioteca che richiede un servizio al sistema ILL, per conto di un proprio utente. La biblioteca deve essere registrata nel sistema ILL, in quanto svolge il ruolo di garante del materiale prestato al proprio lettore, nei confronti della biblioteca destinataria. Nel contesto del progetto, viene identificata anche con la sigla POS (Point Of Sale).
Le interazioni con il sistema ILL sono:
ü identificazione (login) (vedi use case ‘Identificazione Utente’); ü visualizzazione delle proprie richieste (vedi use case ‘Visualizza stato richieste’); ü immissione delle richieste ILL per conto dei propri utenti (vedi use case ‘Immette richiesta ILL’); ü gestione delle notifiche relative alle richieste di prestito (vedi use case ‘Gestione notifiche’).
3) Biblioteca destinataria Rappresenta la biblioteca destinataria di una richiesta di servizio ILL.
La biblioteca deve essere registrata nel sistema ILL, in cui vengono conservate anche le informazioni relative ai tipi di servizi forniti: prestito, riproduzione, localizzazione. Nel contesto del progetto, viene identificata anche con la sigla DSC (Document Supply Center).
Le interazioni con il sistema ILL sono:
ü identificazione (login) (vedi use case ‘Identificazione Utente’); ü visualizzazione delle richieste indirizzate alla biblioteca (vedi use case ‘Visualizza stato richieste’); ü gestione delle richieste ILL (vedi use case ‘Gestione richieste ILL’); ü gestione delle notifiche relative alla richiesta di prestito (vedi use case ‘Gestione notifiche’):
Una stessa biblioteca può di volta in volta assumere il ruolo di POS e di DSC, nell’ambito del sistema ILL.
La biblioteca abilitata all’interno del sistema ILL viene descritta anche con il termine ‘Soggetto’, quando non è necessario distinguere tra i ruoli POS e DSC.
Le biblioteche che vogliono aderire al sistema ILL, inviano una apposita scheda (possibilmente via e-mail), il cui modulo informativo verrà definito dal Gestore Utente ILL del sistema, con le informazioni richieste per l’adesione: eventuale ente di appartenenza (es. per biblioteche universitarie), accettazione del ruolo di POS, DSC o entrambi, tipologie dei servizi che si vuole fornire, listino prezzi, codici e password dei propri operatori, e-mail, referente, ecc.
Per quanto riguarda l’attribuzione del codice identificativo, e la compilazione dei dati anagrafici della biblioteca, si gestisce il recupero automatico dei dati dal sistema Anagrafe Biblioteche (vedi paragrafo ‘Specifiche di massima: integrazione con Anagrafe Biblioteche’).
4) SBN Rappresenta un ente (anche non biblioteca) che è disponibile a fornire il servizio di localizzazione.
L’ente principale interessato a fornire il servizio viene individuato inizialmente nell’Istituto Centrale per il Catalogo Unico.
Le interazioni con il sistema ILL sono:
ü identificazione (login) (vedi use case ‘Identificazione Utente’); ü visualizzazione delle richieste di localizzazione (vedi use case ‘Visualizza stato richieste’); ü gestione delle richieste di localizzazione (vedi use case ‘Gestione richieste ILL’);
Akros Informatica s.r.l. 15 Revisione 4 del 31 marzo 2000 PPrrreeessstttiiitttooo IIILLLL PPeeerrr SSBBNN –– SSppeeeccciiifffiiiccchheee FFuunnzziiiooonnaallliii
5) OPAC Rappresenta il sistema di Information Retrieval che utilizza l’utente per individuare il documento di interesse e la biblioteca che lo possiede, per richiedere il servizio ILL.
6) Utente Gestore ILL Rappresenta l’ente responsabile della gestione del sistema ILL, in termini di registrazioni di informazioni codificate, e gestione delle abilitazioni. Può essere individuato in una (o più) biblioteca partner del sistema.
Le interazioni con il sistema ILL sono:
ü identificazione (login) (vedi use case ‘Identificazione Utente’); ü gestione delle autorizzazioni ad accedere ai servizi ILL (vedi use case ‘Gestione utenti/servizi’); ü gestione delle informazioni generali del sistema: tipi di supporto, tipo di servizio, prodotti, ecc. ü gestione delle informazioni relative ai Soggetti (POS o DSC): servizi attivabili, listini prezzi, ecc.
7) Anagrafe Biblioteche Rappresenta il sistema informativo che gestisce l’archivio delle biblioteche, a livello nazionale; garantisce l’identificazione univoca dei Soggetti coinvolti nella gestione dei servizi ILL; per le modalità di integrazione si veda il paragrafo: ‘Specifiche di massima: Integrazione con Anagrafe Biblioteche’.
3.4.1.2 Use cases
Con il termine ‘use case’, rappresentato con una ellisse (vedi fig. 1), si identifica un insieme coerente di funzionalità del sistema informativo , atto a fornire un risultato significativo per l’attore che lo utilizza.
Di seguito si descrivono brevemente le funzionalità degli ‘use case’ del disegno di figura 1.
3.4.1.2.1 Immette richiesta ILL
La richiesta ILL contiene le informazioni relative al documento oggetto della richiesta, al tipo di servizio richiesto e alla biblioteca destinataria della richiesta stessa.
L’utente (finale o bibliotecario) attiva il servizio di immissione richiesta.
L’immissione della richiesta può essere attivata dopo aver interrogato il sistema OPAC e aver individuato il documento oggetto della richiesta. Il sistema OPAC può essere dotato di un meccanismo di interfaccia (bottone o altro), per consentire l’attivazione del servizio; in questo caso i dati del documento e le biblioteche che lo possiedono sono trasferiti automaticamente dal sistema OPAC al sistema ILL (vedi paragrafo ‘Specifiche di massima: il sistema OPAC’).
L’immissione della richiesta viene consentita anche senza l’interrogazione tramite OPAC: infatti il titolo può essere individuato tramite una interrogazione effettuata in precedenza, oppure con uno strumento (OPAC di Polo o altro) che non ha attivato l’interfaccia con il sistema ILL. In questa opzione i dati del documento vengono immessi dall’utente, sufficientemente esaustivi per consentire al DSC di individuare il documento richiesto nel proprio catalogo.
La richiesta può essere indirizzata a uno o più DSC, in lista di priorità di indirizzamento, oppure a nessun DSC: in questo secondo caso le viene assegnato un particolare stato, che la rende visibile a tutti i DSC, e rimane in attesa che un DSC in grado di soddisfarla la prenda in carico (vedi use case ‘Individua DSC’).
Akros Informatica s.r.l. 16 Revisione 4 del 31 marzo 2000 PPrrreeessstttiiitttooo IIILLLL PPeeerrr SSBBNN –– SSppeeeccciiifffiiiccchheee FFuunnzziiiooonnaallliii
La richiesta immessa dall’utente finale deve contenere obbligatoriamente l’indirizzo di e-mail dell’utente: il sistema provvede a inviare un messaggio di e-mail all’utente stesso, richiedendo una conferma sulla richiesta del servizio, prima di attivare effettivamente la gestione della richiesta. Questa attività di conferma rappresenta una interazione con l’utente finale che non è strettamente necessaria, ma viene prevista per evitare usi impropri dei servizi, garantendo così al sistema ILL la ‘paternità’ della richiesta, e all’utente finale il non inserimento di richieste a proprio nome da parte di altre persone.
La richiesta immessa contiene anche l’indicazione del periodo di validità (inserito dal richiedente o registrato come dato di servizio del DSC), trascorso il quale, in mancanza di trattamento della richiesta da parte del DSC, questa viene automaticamente indirizzata al DSC successivo nella lista di priorità, se esiste.
Esaurita la lista dei DSC in indirizzo, la richiesta si chiude automaticamente, e nella nota viene inserito automaticamente il testo ‘non evasa in tempo utile’.
La richiesta ILL si specializza in:
· richiesta di preventivo di spesa; · richiesta di prestito; · richiesta di riproduzione; · richiesta di localizzazione.
Dopo aver concluse le attività di registrazione della richiesta, il sistema invia all’utente un messaggio di conferma dell’operazione, contenente il numero identificativo assegnato alla richiesta.
L’utente è invitato a prendere nota dell’ identificativo, per utilizzarlo in successive attività di visualizzazione dello stato della richiesta.
Immissione richiesta preventivo di spesa La richiesta di preventivo di spesa può essere inserita da:
ü Utente finale ü Biblioteca POS, per conto dell’utente finale.
Questa tipologia di servizio è particolarmente utile per l’utente finale che intende richiedere la riproduzione di parte di un documento, ma non è in grado di stabilirne il costo; ad esempio non conosce il numero di pagine dell’articolo o del capitolo di cui vuole le fotocopie.
Il servizio di ‘richiesta di preventivo’ consente di conoscere esattamente l’ammontare delle spese, ed è essenziale in quanto la richiesta di riproduzione, per essere accettata dal DSC, deve contenere l’informazione sull’avvenuto pagamento.
La richiesta viene collegata a uno o più DSC, che vengono selezionati con le funzionalità descritte nello use case ‘Individua DSC’, in ordine di priorità. Viene posta in stato ‘ILL in attesa elaborazione – codice azione = F118’ (vedi tabella azioni e stati in appendice B), con riferimento al primo DSC della lista.
La sequenza dell’interazione tra l’utente finale e il sistema è:
ü identificazione del documento oggetto della richiesta (tramite OPAC o con inserimento manuale); ü identificazione del DSC: consente di individuare una o più biblioteche destinatarie, il tipo di servizio e di supporto (vedi use case ‘Individua DSC); ü completamento dei dati della richiesta (eventuale codice POS e codice identificativo di riferimento, indirizzo di consegna, tempo massimo di attesa, costo massimo sostenibile, ecc.); ü conferma della registrazione della richiesta.
Akros Informatica s.r.l. 17 Revisione 4 del 31 marzo 2000 PPrrreeessstttiiitttooo IIILLLL PPeeerrr SSBBNN –– SSppeeeccciiifffiiiccchheee FFuunnzziiiooonnaallliii
La sequenza dell’interazione tra la biblioteca POS e il sistema è analoga a quanto descritto per l’utente finale.
Immissione richiesta di riproduzione La richiesta di riproduzione può essere inserita da:
ü Utente finale ü Biblioteca POS, per conto dell’utente finale.
La richiesta di riproduzione si configura come una transazione diretta tra un generico utente del sistema (anche non iscritto a biblioteca) e la biblioteca DSC che possiede l’originale del documento di cui si richiedono fotocopie e/o riproduzione su altro supporto.
L’utente finale può anche rivolgersi a una biblioteca POS in cui è iscritto come lettore, che inserisce la richiesta per lui.
In questo secondo caso, la biblioteca POS si fa garante dell’avvenuto pagamento del servizio di riproduzione da parte dell’utente finale, per averne verificato la ricevuta di versamento, oppure perché gestisce un credito prepagato dall’utente finale.
La biblioteca DSC verifica l’avvenuto pagamento prima di procedere alla spedizione della riproduzione. Questa problematica viene approfondita nel paragrafo ‘Specifiche di massima: integrazione con i sistemi bancari’.
La sequenza dell’interazione tra l’utente finale e il sistema è:
ü identificazione del documento oggetto della richiesta (tramite OPAC o con inserimento manuale); ü identificazione del DSC: consente di individuare una biblioteca destinataria, il tipo di servizio e di supporto (vedi use case ‘Individua DSC); ü completamento dei dati della richiesta (eventuale codice POS e codice identificativo di riferimento, indirizzo di consegna, tempo massimo di attesa, costo massimo sostenibile, ecc.). Se l’utente digita il codice POS, facendosi quindi garantire dalla biblioteca, la richiesta deve essere validata dalla biblioteca POS; viene quindi posta in stato ‘ILL in attesa validazione da POS’ (vedi tabella azioni e stati in appendice B) analogamente a quanto previsto per la richiesta di prestito di un documento originale; ü conferma della registrazione della richiesta.
La sequenza dell’interazione tra la biblioteca POS e il sistema è analoga a quanto descritto per l’utente finale; la richiesta viene però considerata ‘validata’, e resa disponibile all’accettazione da parte del DSC ; viene cioè posta in stato ‘ILL in attesa elaborazione – codice azione = F118’ (vedi tabella azioni e stati in appendice B).
Immissione richiesta di localizzazione ü Utente finale ü Biblioteca POS
La richiesta di localizzazione è un servizio di help verso l’utente, svolto da una apposita struttura che si incarica di approfondire una ricerca che non ha dato esito. Nello ‘Use Case View’ (vedi figura 1), questa struttura viene indicata con la sigla ‘SBN’ , e viene definita tramite la ricerca dei Soggetti che hanno abilitato questo tipo di servizio (vedi use case ‘Gestione Utenti/servizi’).
L’utente finale (o la biblioteca POS per lui) inserisce la descrizione del titolo di cui vuole conoscere le possibili localizzazioni (biblioteche che lo possiedono).
La richiesta viene indirizzata automaticamente agli enti che forniscono il servizio di localizzazione.
Akros Informatica s.r.l. 18 Revisione 4 del 31 marzo 2000 PPrrreeessstttiiitttooo IIILLLL PPeeerrr SSBBNN –– SSppeeeccciiifffiiiccchheee FFuunnzziiiooonnaallliii
Le funzionalità individuate, accessibili direttamente dall’utente finale, sono:
ü immissione della richiesta di localizzazione; la lista dei DSC in indirizzo e il tipo di servizio sono assegnati automaticamente dal sistema; ü conferma della registrazione della richiesta, che viene posta in stato ‘ILL in attesa elaborazione – codice azione = F118’ (vedi tabella azioni e stati in appendice B).
La sequenza dell’interazione tra la biblioteca POS e il sistema è analoga a quanto descritto per l’utente finale.
Immissione richiesta di prestito La richiesta di prestito può essere inserita da:
ü Utente finale; ü Biblioteca POS.
L’utente finale che immette direttamente la richiesta indica il proprio codice lettore e la biblioteca presso cui è iscritto, che si configura come POS per il prosieguo dell’iter della richiesta stessa.
La biblioteca POS assume il ruolo di garante del proprio utente nei confronti della biblioteca DSC. La richiesta immessa dall’utente viene quindi validata dalla biblioteca POS prima di essere inviata alla biblioteca DSC (vedi use case ‘Visualizza stato richiesta).
Se invece la richiesta viene immessa direttamente dalla biblioteca POS, è immediatamente disponibile per il trattamento da parte della biblioteca DSC.
La sequenza dell’interazione tra l’utente finale e il sistema è:
ü identificazione del documento oggetto della richiesta (tramite OPAC o con inserimento manuale); ü identificazione del DSC: consente di individuare una o più biblioteca destinataria, il tipo di servizio e di supporto (vedi use case ‘Individua DSC’); ü completamento dei dati della richiesta: codice POS e codice identificativo lettore, e-mail, tempo massimo di attesa, costo massimo sostenibile, ecc.. ü conferma della registrazione della richiesta, che viene posta in stato ‘ILL in attesa validazione da POS’.
La sequenza dell’interazione tra la biblioteca POS e il sistema è analoga a quanto descritto per l’utente finale. Il codice POS viene però compilato automaticamente, recuperato dalla operazione di ‘login’ al sistema (vedi use case ‘Identificazione utente ILL’).
La richiesta viene considerata ‘validata’, e resa disponibile all’accettazione da parte del DSC.
3.4.1.2.2 Individua DSC
L’identificazione del DSC cui indirizzare la richiesta può avvenire con le seguenti modalità:
ü richiesta attivata dall’ OPAC: l’integrazione con questo sistema prevede la trasmissione della lista dei codici anagrafici delle biblioteche che possiedono il documento (per ogni elemento della lista viene verificata la registrazione della biblioteca come DSC); per ogni DSC della lista l’utente può esaminare i servizi e il relativo costo, selezionare il DSC destinatario e il servizio desiderato. ü richiesta immessa manualmente: l’utente individua la biblioteca DSC tramite apposite funzionalità di ricerca: ne comunica il codice, oppure può effettuare una ricerca utilizzando altri canali di ricerca (vedi ‘Specifiche di massima: Integrazione con Anagrafe Biblioteche’). Rimane responsabilità dell’utente selezionare la biblioteca DSC che possiede il documento richiesto (in caso contrario la richiesta sarà inevitabilmente respinta).
Akros Informatica s.r.l. 19 Revisione 4 del 31 marzo 2000 PPrrreeessstttiiitttooo IIILLLL PPeeerrr SSBBNN –– SSppeeeccciiifffiiiccchheee FFuunnzziiiooonnaallliii
E’ possibile visualizzare il costo stimato del servizio selezionato, tramite l’attivazione di una apposita funzione. Ad esempio, il costo di un prestito interbibliotecario viene calcolato automaticamente sommando l’importo richiesto dal DSC con quanto richiesto dalla biblioteca POS (per la rispedizione del materiale); gli importi relativi sono registrati tra i dati di profilo e di listino prezzi delle biblioteche. Se l’utente (finale o POS) che immette la richiesta non è in grado di indicare alcun DSC, la richiesta viene posta in stato ‘ ILL definita, in attesa instradamento ’ (vedi appendice B). Le richieste in questo stato sono visibili a tutti i DSC (lista pubblica); il DSC in grado di esaudire la richiesta può prenderla in carico (vedi use case ‘Visualizza stato richieste’), facendola così rientrare nell’iter normale dipendentemente dal tipo di servizio richiesto.
3.4.1.2.3 Visualizza stato richieste La visualizzazione delle richieste interessa tutti i partners coinvolti nei servizi ILL.
L’utente finale visualizza direttamente le proprie richieste, per verificarne la situazione. Può modificare i dati di una richiesta che risulta ancora in attesa (per le richiesta di prestito solo se in stato ‘in attesa di validazione dal POS’), oppure duplicare una richiesta rifiutata da un DSC per inviarla ad altro DSC.
Selezionando una richiesta di preventivo evasa, ne viene visualizzata la risposta, e viene consentito trasformare la richiesta in una richiesta di riproduzione.
Selezionando una richiesta di localizzazione evasa, viene visualizzata la relativa risposta, registrata dall’ente preposto al servizio; se la risposta è positiva l’utente può trasformare la richiesta in una richiesta di riproduzione o prestito, tramite la funzionalità di duplicazione.
Le biblioteche POS e DSC utilizzano le funzionalità di visualizzazione per controllare lo stato di iter delle proprie richieste, o individuare la richiesta che si intende gestire
Le funzionalità individuate, accessibili direttamente dall’utente finale, sono:
ü ricerca puntuale, digitando il numero identificativo della richiesta e e-mail, ü ricerca per dominio: l’utente digita il proprio e-mail. Può inoltre indicare il periodo di tempo in cui deve ricadere la data di inserimento della richiesta, selezionare un particolare stato o un tipo di servizio, per filtrare ulteriormente le richieste.
Una volta selezionata una richiesta, l’utente può:
ü esaminare le note di risposta, se si tratta di richiesta conclusa di localizzazione o preventivo; ü accettare o rifiutare le condizioni eventualmente imposte dal DSC per il proseguimento dell’iter; ü correggere i dati, se la richiesta non è stata ancora accettata dal DSC ( o validata dal POS, per i servizi che prevedono questa attività); ü cancellare la richiesta, se non è stata ancora trattata dal DSC; ü modificare o integrare la lista dei DSC di riferimento della richiesta che risulta ancora in attesa; ü duplicare la richiesta, se si tratta di una richiesta rifiutata, per indirizzarla ad altro DSC; ü trasformare una richiesta di preventivo evasa in una richiesta di riproduzione. ü trasformare una richiesta di localizzazione con risposta positiva in una richiesta di riproduzione o prestito.
Le funzionalità individuate, accessibili direttamente dalla biblioteca POS, sono:
ü ricerca puntuale, digitando il numero identificativo della richiesta, ü ricerca per dominio. Le possibili selezioni sono: 1. codice del proprio lettore; 2. stato della richiesta; 3. periodo di tempo di inserimento richiesta;
Akros Informatica s.r.l. 20 Revisione 4 del 31 marzo 2000 PPrrreeessstttiiitttooo IIILLLL PPeeerrr SSBBNN –– SSppeeeccciiifffiiiccchheee FFuunnzziiiooonnaallliii
4. codice biblioteca DSC di indirizzamento della richiesta; 5. tipo di servizio richiesto; 6. dati del titolo: bid, n.isbn/issn, parte iniziale del titolo.
Una volta selezionata la richiesta di interesse, può:
ü esaminare le note di risposta, se si tratta di richiesta conclusa di localizzazione o preventivo; ü accettare o rifiutare le condizioni eventualmente imposte dal DSC per il proseguimento dell’iter; ü correggere i dati di propria competenza, se lo stato della richiesta lo consente; ü cancellare la richiesta, se non è stata ancora trattata dal DSC; ü modificare o integrare la lista dei DSC di riferimento della richiesta che risulta ancora in attesa; ü duplicare la richiesta, se si tratta di una richiesta rifiutata, per indirizzarla ad altro DSC; ü trasformare una richiesta di preventivo evasa in una richiesta di riproduzione; ü trasformare una richiesta di localizzazione con risposta positiva in una richiesta di riproduzione o prestito.
Le funzionalità individuate, accessibili direttamente dalla biblioteca DSC, sono:
ü ricerca puntuale, digitando il numero identificativo della richiesta, ü ricerca per dominio. Le possibili selezioni sono: 1. stato della richiesta; 2. periodo di tempo di inserimento richiesta; 3. codice biblioteca POS della richiesta; 4. tipo di servizio richiesto; 5. dati del titolo: bid, n.isbn/issn, parte iniziale del titolo
Una volta selezionata la richiesta di interesse, può:
ü accettare una richiesta non indirizzata a DSC (lista pubblica); ü correggere i dati di propria competenza (note, costo, ecc.), se lo stato della richiesta lo consente; ü proseguire le attività di gestione della richiesta: vedi use case ‘Gestione richiesta ILL’.
Il Soggetto che partecipa al servizio di localizzazione esamina le richieste in attesa. Una volta selezionata una richiesta, può:
ü accettare la richiesta in attesa, e prenderla in carico.
I diagrammi di stato relativi all’iter delle richieste sono riportati in appendice C.
3.4.1.2.4 Identificazione Utente ILL
Lo ‘use case’ rappresenta la funzionalità di identificazione dell’utente abilitato ad accedere ai servizi gestionali del sistema ILL (biblioteche POS, DSC o ente preposto al servizio di localizzazione).
I Soggetti e i relativi operatori autorizzati sono gestiti dall’Utente Gestore ILL (vedi use case ‘Gestione Utenti/servizi).
La funzionalità di identificazione richiede all’operatore la comunicazione del proprio codice e password.
Per le modalità di autentificazione dell’operatore si veda paragrafo 2.3.
L’operatore viene identificato come appartenente a un Soggetto abilitato al sistema ILL., e può eventualmente modificare la propria password.
Akros Informatica s.r.l. 21 Revisione 4 del 31 marzo 2000 PPrrreeessstttiiitttooo IIILLLL PPeeerrr SSBBNN –– SSppeeeccciiifffiiiccchheee FFuunnzziiiooonnaallliii
Il sistema ILL consente all’operatore le attività previste per il tipo di profilo in cui è inserito:
1. gestore del sistema: abilitato a tutte le funzionalità di gestione dei Soggetti ILL. 2. gestore del Soggetto: abilitato alla gestione degli operatori del Soggetto, e dei listini prezzo; 3. operatore di Soggetto: abilitato alle funzionalità di gestione delle richieste ILL.
3.4.1.2.5 Gestione richieste ILL
Lo ‘use case’ rappresenta l’insieme delle funzionalità atte a gestire l’iter e la successione temporale degli stati delle richieste ILL. Utilizza le funzionalità di ‘Visualizza stato richieste’, per esaminare le richieste che interessano la biblioteca (come POS e/o come DSC), e per selezionare la richiesta da gestire.
La biblioteca DSC può inoltre esaminare le richieste non indirizzate a nessun DSC, e selezionarne una per prenderla in carico.
I diagrammi di stato relativi all’iter delle richieste sono riportati in appendice C.
Per le modifiche di iter (passaggi di stato) particolarmente significative, è possibile attivare l’invio automatico di un e-mail al Soggetto interessato (POS,DSC o Utente finale). Questo servizio è attivabile su richiesta del Soggetto che registra l’operazione di passaggio di stato.
Ad esempio: al momento dell’accettazione della richiesta di prestito o riproduzione da parte del DSC, l’operatore può inviare all’utente finale, via e-mail, l’importo esatto del costo del servizio, e le informazioni sulle modalità di pagamento.
Un altro importante caso di utilizzo riguarda le richieste di preventivo e localizzazione: quando l’operatore evade la richiesta compila le note di risposta che vengono registrate sul data base ILL, e contemporaneamente attiva l’invio dell’e-mail all’utente richiedente.
La gestione delle richieste ILL si specializza in:
Gestione ILL preventivo di spesa
La richiesta di un preventivo di spesa si configura come una richiesta di informativa, rivolta al DSC, riguardante il costo della riproduzione di un documento.
Questo tipo di richiesta prevede sempre una risposta testuale.
Il DSC di riferimento può:
ü evadere la richiesta, compilando una apposita nota con l’informazione richiesta.
Gestione ILL localizzazione
L’iter di una richiesta di localizzazione è molto semplice. Questo tipo di richiesta prevede sempre una risposta testuale (negativa perché le informazioni non sono sufficienti, o positiva).
L’operatore che ha preso in carico la richiesta può:
ü evadere la richiesta, compilando una apposita nota con l’informazione richiesta.
Akros Informatica s.r.l. 22 Revisione 4 del 31 marzo 2000 PPrrreeessstttiiitttooo IIILLLL PPeeerrr SSBBNN –– SSppeeeccciiifffiiiccchheee FFuunnzziiiooonnaallliii
In caso di risposta positiva, l’operatore può compilare la lista dei DSC localizzati, in modo da fornire all’utente finale una informazione strutturata, che faciliti l’eventuale operazione di trasformazione della richiesta in una richiesta di prestito o riproduzione (vedi use case ‘Individua DSC’).
L’Utente richiedente (utente finale o POS) può visualizzare il testo della risposta (e l’eventuale lista di DSC) con le funzionalità descritte nello use case ‘Visualizza stato richieste’.
Gestione ILL riproduzione
La gestione di una richiesta di riproduzione è competenza della biblioteca DSC. Il bibliotecario addetto individua nel proprio sistema gestionale il documento oggetto della richiesta, e ne verifica la disponibilità. Verifica inoltre l’avvenuto pagamento del servizio, la congruenza con le modalità, i tempi di consegna e il tipo di supporto eventualmente indicati nella richiesta.
Il DSC di riferimento può:
ü richiedere ulteriori informazioni, compilando una apposita nota, la richiesta viene così considerata ‘condizionata’, e richiede una ulteriore precisazione dell’utente; ü sospendere la richiesta, se il documento in oggetto non risulta disponibile immediatamente; ü rifiutare la richiesta, compilando una nota con il motivo del rifiuto; ü accettare la richiesta, compilando eventualmente una nota con le informazioni relative alla spedizione. Per il successivo passaggio di stato (spedizione) si veda lo use case ‘Gestione Notifiche’.
L’Utente richiedente (utente finale o POS) può visualizzare il testo della risposta con le funzionalità descritte nello use case ‘Visualizza stato richieste’.
Se la richiesta è sottoposta a una condizione da parte del DSC, l’utente può:
ü accettare la condizione, facendo così proseguire l’iter della richiesta; ü annullare la richiesta.
Se la richiesta è ‘sospesa’, perché il documento non è disponibile, l’utente può annullarla. La richiesta viene anche annullata automaticamente quando è trascorso il tempo massimo accettabile per l’evasione, indicato dall’utente al momento dell’inserimento della richiesta stessa.
Gestione ILL prestito
La gestione di una richiesta di prestito coinvolge sia la biblioteca POS sia la biblioteca DSC.
La biblioteca POS esamina le richieste immesse direttamente dai propri lettori.
Dopo avere verificato l’abilitazione del lettore al prestito sul proprio sistema gestionale, procede alla:
ü validazione, per rendere disponibile la richiesta all’esame del DSC; ü annullamento della richiesta.
La biblioteca POS tratta inoltre le richieste sottoposte a condizione dalla biblioteca DSC, e può:
ü accettare la condizione, facendo proseguire l’iter della richiesta; ü annullare la richiesta.
Akros Informatica s.r.l. 23 Revisione 4 del 31 marzo 2000 PPrrreeessstttiiitttooo IIILLLL PPeeerrr SSBBNN –– SSppeeeccciiifffiiiccchheee FFuunnzziiiooonnaallliii
La biblioteca DSC esamina le richieste ad essa indirizzate, che si trovano nello stato ’ILL in attesa elaborazione da DSC’ (vedi tabella di appendice B); effettua le opportune verifiche sull’ammissibilità della richiesta (disponibilità, tempi di consegna, costi del servizio) e può decidere di:
ü richiedere ulteriori informazioni, compilando una apposita nota; ü sospendere la richiesta, se il documento in oggetto non risulta disponibile immediatamente; ü rifiutare la richiesta, compilando una nota con il motivo del rifiuto ü accettare la richiesta, compilando eventualmente una nota con le informazioni relative alla spedizione . Per il successivo passaggio di stato (spedizione) si veda lo use case ‘Gestione Notifiche’.
3.4.1.2.6 Gestione notifiche
Lo ‘use case’ rappresenta le attività svolte dalla biblioteca POS e dalla biblioteca DSC, a fronte di una richiesta di prestito o riproduzione accettata.
I diagrammi di stato relativi all’iter delle richieste sono riportati in appendice C.
Per il servizio di riproduzione, la biblioteca DSC notifica la spedizione del materiale.
Il trattamento dell’iter del prestito ILL prevede invece i seguenti passaggi:
1. Spedizione: la biblioteca DSC registra le informazioni relative alla spedizione del volume e alla durata del prestito; 2. Arrivo: la biblioteca POS registra la ricezione del documento; 3. Rispedizione: la biblioteca POS registra le informazioni relative alla spedizione del documento alla biblioteca DSC; 4. Rientro: la biblioteca DSC registra il ricevimento del documento.
La biblioteca POS può chiedere un rinnovo del prestito, allungando i tempi di riconsegna, previo accordo con la biblioteca DSC.
La richiesta di rinnovo viene esaminata dalla biblioteca DSC, che può:
ü confermare il rinnovo; ü rifiutare il rinnovo.
La biblioteca DSC può inoltre sollecitare la restituzione di un prestito.
3.4.1.2.7 Pagamento servizio
La gestione dei pagamenti dei servizi ILL costituisce un elemento importante delle funzionalità.
Coinvolge i tre attori:
utente finale:
ü effettua il pagamento dei servizi di riproduzione o prestito che richiede; questa attività è esterna al sistema ILL, viene effettuata con il versamento su un conto postale o bancario intestato alla biblioteca DSC nel caso di riproduzione. Per le richieste di prestito il pagamento è dovuto sia alla biblioteca DSC che alla biblioteca POS, che deve provvedere alla rispedizione del documento originale. ü inserisce sulla richiesta di riproduzione i dati relativi al pagamento effettuato.
Akros Informatica s.r.l. 24 Revisione 4 del 31 marzo 2000 PPrrreeessstttiiitttooo IIILLLL PPeeerrr SSBBNN –– SSppeeeccciiifffiiiccchheee FFuunnzziiiooonnaallliii
Biblioteca DSC:
ü verifica l’avvenuto pagamento, per i servizi che richiedono un pagamento preventivo (riproduzione); questa attività deve essere svolta al di fuori del sistema ILL (fino al momento della realizzazione dell’integrazione con il sistema bancario), consultando le distinte di accredito fornite dalla banca (o ufficio postale); ü può restituire la cifra prepagata all’utente, qualora il servizio richiesto non sia erogabile; o gestisce il caso in cui l’importo pagato dall’utente non corrisponda (in eccesso o difetto) a quanto dovuto. Anche queste attività sono da considerarsi ‘manuali’, fino al momento dell’integrazione con il sistema bancario. L’implementazione automatica di queste transazioni implica inoltre la gestione di un conto intestato all’utente finale. ü comunica alla biblioteca POS l’esatto ammontare del costo di una richiesta di prestito, e ne verifica il successivo pagamento.
Biblioteca POS:
ü conosce esattamente l’ammontare del costo del servizio DSC e della propria attività POS, per richiedere all’utente finale il pagamento del servizio; ü verifica l’avvenuto pagamento da parte dell’utente finale prima di consegnargli il documento. Questa attività è da considerarsi ‘manuale’ fino al momento dell’integrazione con il sistema bancario. Il bibliotecario chiede all’utente finale l’esibizione della ricevuta del versamento.
La responsabilità della verifica delle attività contabili è legata all’integrazione con il sistema bancario, e apre problematiche complesse, che richiedono garanzie di sicurezza elevate. Per la descrizione di una possibile integrazione con il sistema informativo bancario, si veda il capitolo ‘Specifiche di massima: integrazione con sistemi bancari’.
Per le modalità di pagamento, si possono prevedere varie possibilità:
1. bonifico bancario, alla banca o tramite un gestore incaricato dalla biblioteca, 2. versamento su conto corrente postale, 3. pagamento elettronico via Internet mediante carta di credito; 4. pagamento elettronico via Internet da postazioni tipo POS installata presso la biblioteca, con carta di credito o bancomat.
La possibilità di effettuare pagamenti elettronici coinvolge importanti problematiche di sicurezza e collaborazione con il mondo bancario, e quindi dipende dalla realizzazione dell’interfaccia con il Sistema bancario, le cui specifiche di massima sono indicate nell’apposito capitolo. In attesa di questa realizzazione, il pagamento può essere effettuato con le prime due modalità.
Indipendentemente dalla realizzazione dell’integrazione con il sistema bancario, il sistema ILL deve essere in grado di fornire la situazione contabile dei partners (relativamente ai servizi ILL), anche se in modo virtuale.
Per quanto riguarda i pagamenti effettuati dagli utenti finali, i dati relativi agli estremi del versamento, indicati nell’immissione della richiesta di riproduzione, vanno verificati dal bibliotecario DSC prima di accettare la richiesta. In assenza di integrazione informatica con il mondo bancario, la responsabilità del controllo contabile rimane quindi a carico del personale delle biblioteche. Il sistema ILL può fornire l’estratto conto virtuale, che riporta l’elenco dei movimenti registrati a fronte dei servizi forniti.
Nel sistema ILL sono quindi previste le seguenti registrazioni di transazione commerciale:
Akros Informatica s.r.l. 25 Revisione 4 del 31 marzo 2000 PPrrreeessstttiiitttooo IIILLLL PPeeerrr SSBBNN –– SSppeeeccciiifffiiiccchheee FFuunnzziiiooonnaallliii
ü spedizione materiale (sia riproduzione che in originale): viene accreditato al conto del DSC l’importo richiesto dal tipo di servizio, ( e dal tipo di supporto per le riproduzioni), e dal listino prezzi applicato al POS (vedi use case ‘Gestione Utenti/servizi’); ü restituzione materiale (documento originale): viene accreditato al POS l’importo dichiarato come rimborso per le spese di rispedizione (vedi use case ‘Gestione Utenti/servizi’).
3.4.1.2.8 Gestione utenti/servizi
Lo use case rappresenta le attività di registrazione e gestione dei partners accreditati nel sistema ILL.
Viene identificato un utente gestore del sistema ILL, che può essere l’ I.C.C.U., oppure una biblioteca individuata tra i partners del sistema, che ha la responsabilità di gestire l’archivio delle biblioteche abilitate come DSC e/o come POS; occorre gestire inoltre l’elenco dei servizi (e i relativi listini prezzo) che ogni Soggetto si rende disponibile a fornire.
Per iscrivere una biblioteca tra i Soggetti del sistema ILL, è auspicabile una integrazione con il sistema informativo dell’anagrafe delle biblioteche, gestito dall’ I.C.C.U.; a questo proposito si veda il capitolo ‘Specifiche di massima: integrazione con Anagrafe Biblioteche’.
L’Utente gestore del sistema ILL controlla le informazioni generali del sistema stesso:
1. tipi di servizio disponibili: richiesta di preventivo, localizzazione, riproduzione, prestito con ruolo di POS, prestito con ruolo di DSC; 2. tipi di supporto; 3. prodotti; con questo termine si intende l’associazione tra un tipo di servizio e un supporto (ad es. ‘fotocopie in formato A4’ e ‘fotocopie in formato A3’ sono due prodotti diversi). 4. Listini prezzi base: contiene le informazioni sul costo dei prodotti, standard per il sistema. Questo listino viene utilizzato se non esiste un listino particolare per il DSC e il POS coinvolti nel servizio;
Definisce le entità di raggruppamento dei Soggetti:
ü gruppo generico: rappresenta una qualificazione di raggruppamento, che si ritiene utile per la gestione del sistema o per produzione di statistiche; ü gruppo amministrativo: raggruppa i Soggetti che condividono gli stessi listini prezzi. Ad esempio, può identificarsi con una Università o un Polo SBN; ü Listino prezzi gruppo: specifica il listino di un particolare gruppo (se i prezzi dei servizi sono diversi da quelli standard del sistema).
La registrazione di un Soggetto richiede la definizione del ruolo che questo può svolgere: DSC, POS o entrambi.
Per il ruolo di DSC, occorre definire:
ü eventuale gruppo generico di appartenenza; ü eventuale gruppo amministrativo di appartenenza; ü eventuale listino prezzi (se diverso dal listino definito per il gruppo amministrativo o per il sistema ); ü eventuale listino prezzi specifico per una aggregazione di POS (occorre definire l’aggregazione e le biblioteche POS che ne fanno parte, e la particolare condizione commerciale di cui gode l’aggregazione).
Gli importi relativi ai servizi vengono gestiti in lire e in euro.
Per il ruolo di POS, occorre definire il prezzo richiesto per il solo servizio di prestito, che si riferisce al rimborso spese per la restituzione del documento originale.
Akros Informatica s.r.l. 26 Revisione 4 del 31 marzo 2000 PPrrreeessstttiiitttooo IIILLLL PPeeerrr SSBBNN –– SSppeeeccciiifffiiiccchheee FFuunnzziiiooonnaallliii
Per ogni Soggetto viene inoltre definito almeno un operatore.
3.4.1.2.9 Elabora statistiche
L’utente gestore del sistema ILL può richiedere statistiche sui servizi forniti dal sistema, su richiesta di un Soggetto appartenente al sistema, oppure genericamente su tutti i Soggetti.
In analogia con quanto previsto nell’attuale procedura di monitoraggio del Sistema Indice SBN, si possono ipotizzare i seguenti report statistici:
ü frequenza totale richieste per tipologia di servizio;
ü frequenza delle richieste e delle risposte per mese;
ü frequenza richieste inviate per stato, per esito, per tipo, per biblioteca destinataria;
ü frequenza richieste ricevute per stato, per esito, per tipo, per biblioteca richiedente;
ü istogramma richieste per biblioteca richiedente;
ü istogramma richieste per biblioteca destinataria;
ü situazione richieste inviate e ricevute, eventualmente selezionabile per tipologia di servizio.
L’utente identificato come ‘operatore’ di un Soggetto, può richiedere le statistiche riferite ai servizi del proprio Soggetto.
L’elaborazione delle statistiche è legato alla problematica relativa alla ‘pulizia’ dell’archivio ILL, ossia ad operazioni di eliminazione di informazioni non più significative: richieste evase e concluse da tempo.
Se sono previste operazioni di ‘svecchiamento’, i dati utili alla produzione delle statistiche devono essere registrati in modalità compattata, in un apposito archivio storico.
3.4.2 CLASS DIAGRAM Il diagramma relativo alle classi definite per il sistema ILL viene realizzato utilizzando lo strumento ‘Rational Rose’, che implementa le funzionalità atte a definire l’analisi funzionale con modalità Object Oriented.
Questo tool fornisce anche strumenti per la documentazione delle classi, in termini di attributi e metodi, sia visuale che descrittiva.
Da questo strumento viene poi estratta anche la definizione fisica del data base. La documentozione completa sul class diagram e sullo schema fisico verrà fornita al termine della fase di ‘Sviluppo e Test’ del progetto.
In appendice D viene riportata la descrizione grafica del sistema ILL, in termini di class diagram.
Akros Informatica s.r.l. 27 Revisione 4 del 31 marzo 2000 PPrrreeessstttiiitttooo IIILLLL PPeeerrr SSBBNN –– SSppeeeccciiifffiiiccchheee FFuunnzziiiooonnaallliii
3.5 SPECIFICHE DI MASSIMA DI INTEGRAZIONE
3.5.1 NOTA TECNICA PER LE INTEGRAZIONI L’integrazione con i due sistemi per i quali esistono specifiche tecnologiche può avvenire tramite le seguenti metodologie tecniche:
Ø OPAC: a seguito di una ricerca l’ OPAC richiama il sistema di Prestito ILL usando un POST URL (vedi: HTML v3.2 o 4) con requisiti minimi richiesti per la registrazione della richiesta (vedi paragrafo successivo): informazioni catalografiche, uno o più codici anagrafe biblioteche.
Ø SBN/Unix: Il sistema fornisce una “interfaccia pubblica” tramite la quale il sistema SBN può richiamare servizi di Prestito ILL per recuperare le informazioni richieste dalla gestione del prestito stesso. Tale interfaccia può essere realizzata usando i POST URL disponibili con il sistema base.
Ø SBN/Anagrafe Biblioteche: l’anagrafe biblioteche non fornisce specifiche tecniche rispetto alla sua implementazione. Di conseguenza si presuppone un sistema di integrazione analogo a quanto previsto per l’OPAC (si veda il paragrafo apposito).
L’integrazione con i sistemi legacy ed il sistema bancario risulta meno chiara dal punto di vista tecnico in quanto richiede ulteriori informazioni, e la cooperazione da parte di chi gestisce e realizza software per il server. Si descrivono le seguenti ipotesi, ritenute valide a fronte di quanto descritto nei documenti di gara (vedi appendice A).
Ø Sistemi Legacy: la realizzazione tecnica si pone in un ottica di esposizione di un interfaccia pubblica documentata in modo tale da permettere a terzi ad interfacciarsi con il sistema ILL. Questo può essere effettuato utilizzando CORBA, e creando gli stub IDL che permettano la realizzazione di appositi client da parte di terzi. E’ comunque possibile richiamare i servizi del sistema ILL tramite l’interfaccia pubblica di tipo POST URL disponibile con il sistema base
Ø Sistema Bancario: il sistema bancario pone problemi di sicurezza non indifferenti (ad esempio: l’uso di SSL o TLS od altri sistemi di autenticazione e certificazione basati su X.509). In questo caso s’intende la realizzazione al livello analitico di una meta-schema dati per lo scambio di informazioni per il sistema bancario.
Akros Informatica s.r.l. 28 Revisione 4 del 31 marzo 2000 PPrrreeessstttiiitttooo IIILLLL PPeeerrr SSBBNN –– SSppeeeccciiifffiiiccchheee FFuunnzziiiooonnaallliii
3.5.2 IL SISTEMA OPAC La ricerca e l’individuazione del documento oggetto di una richiesta di prestito o riproduzione è un aspetto fondamentale del modello del sistema ILL.
Il sistema preposto a questo compito è il sistema OPAC, che deve essere dotato di una opportuna interfaccia di attivazione dei servizi ILL. Nell’ambito del presente progetto, si considera come partner privilegiato l’ OPAC Indice, che contiene tutto il catalogo nazionale SBN, ed è gestito dall’ I.C.C.U.
E’ comunque prevista anche la possibilità che altri software OPAC si dotino di interfacce verso il sistema ILL.
Obiettivo del presente capitolo è definire in modo chiaro ed esaustivo le modalità e gli attributi necessari allo scambio di informazioni tra un sistema OPAC e il sistema ILL. Nel contesto di tale progetto si prevede che tale scambio avvenga con Opac dotati di interfaccia WWW.
L’esigenza di integrazione tra i due sistemi si configura in due tipologie:
Elementi grafici di attivazione: L’interfaccia grafica dell’ OPAC deve contenere gli oggetti per l’attivazione del sistema ILL.
I servizi ipotizzabili si differenziano in due categorie:
ü servizi che non richiedono identificazione di un titolo, e sono quindi attivabili in qualsiasi punto dell’interfaccia web.
ü servizi che richiedono informazioni bibliografiche, da identificare nel percorso di interrogazione;
Alla prima categoria appartengono:
1. il servizio di localizzazione: l’utente che non trova il documento voluto, può richiedere l’aiuto dell’ente preposto a questo servizio. Il bottone di attivazione può essere inserito in vari punti dell’interfaccia OPAC, e/o in altra pagina web (ad esempio all’interno del sito I.C.C.U).
2. la visualizzazione dello stato delle richieste: l’utente che ha effettuato richieste di servizio, sia personalmente che tramite la biblioteca POS, deve avere la possibilità di esaminare la situazione delle stesse. Il servizio può essere attivabile dall’interfaccia OPAC, tramite apposito elemento grafico. Nel contesto dell’ OPAC Indice (vedi fig. 2), può essere inserito un elemento nel frame a sinistra della pagina. Sarà cura dell’applicazione ILL richiedere all’utente i dati identificativi per selezionare le proprie richieste.
Akros Informatica s.r.l. 29 Revisione 4 del 31 marzo 2000 PPrrreeessstttiiitttooo IIILLLL PPeeerrr SSBBNN –– SSppeeeccciiifffiiiccchheee FFuunnzziiiooonnaallliii
Alla seconda categoria appartengono la richiesta di prestito e la richiesta di riproduzione. Questi servizi presuppongono l’identificazione del documento desiderato dall’utente. Si propone l’attivazione dei servizi con un unico oggetto grafico presente sulla pagina OPAC: l’oggetto deve attivare il sistema ILL, comunicando automaticamente al servizio la scheda del titolo e i codici delle biblioteche in cui è localizzato.
La scheda catalografica del volume deve contenere le informazioni necessarie e sufficienti per consentire alla biblioteca DSC di individuare univocamente il documento. Particolarmente importanti sono quindi: l’identificativo sbn (bid); la descrizione isbd, l’editore e la data di pubblicazione.
Se l’archivio OPAC dispone anche di informazioni sul volume (inventario e collocazione: si tratta di OPAC di Polo o locale), può essere utile comunicare questi dati al sistema ILL. Data la varietà dei sistemi OPAC esistenti, può essere utile mettere a disposizione un attributo testuale (nota sul documento) della richiesta ILL, in cui l’interfaccia OPAC può formattare le proprie informazioni ‘locali’, ritenute significative nel contesto.
Le informazioni che compongono la scheda del titolo sono:
Ø natura (monografia o periodico) Ø n. isbn/issn Ø autore Ø titolo Ø titolo di collana e numero di sequenza Ø data di pubblicazione Ø editore
Akros Informatica s.r.l. 30 Revisione 4 del 31 marzo 2000 PPrrreeessstttiiitttooo IIILLLL PPeeerrr SSBBNN –– SSppeeeccciiifffiiiccchheee FFuunnzziiiooonnaallliii
Ø bid Ø nota relativa ai dati di collocazione (non presenti nell’ OPAC di Indice) Ø eventuale identificativo utilizzato nel sistema gestionale di riferimento e presente nell’ OPAC (inventario o altro).
L’altra tipologia di informazione, necessaria alla definizione della richiesta, riguarda l’individuazione della biblioteca, o delle biblioteche che possiedono il documento. Il sistema ILL prevede la ricezione di un elenco di codici delle biblioteche.
Alla luce dei prossimi sviluppi previsti per l’evoluzione dell’anagrafe delle biblioteche, il codice assegnato nell’ambito dell’anagrafe sembra il miglior candidato a garantire l’identificazione della biblioteca nell’archivio OPAC con la biblioteca registrata nel sistema ILL.
L’integrazione OPAC-ILL propone quindi il passaggio automatico dell’elenco delle biblioteche che possiedono il documento come elenco dei relativi codici dell’anagrafe.
Rimane a discrezione del software OPAC consentire all’utente la selezione di una o più biblioteche, tra quelle localizzate per il documento; il sistema ILL controllerà la registrazione delle biblioteche come DSC nel proprio archivio, prima di inserire il codice nella lista delle biblioteche destinatarie della richiesta. L’ordine di invio dei codici delle biblioteche verso il sistema ILL rappresenta l’ordine di priorità desiderato per l’indirizzamento della richiesta.
Se l’OPAC non è in grado di fornire il codice anagrafico nazionale delle biblioteche localizzate, rimane a carico dell’utente che immette la richiesta l’operazione di ricerca e identificazione dei possibili DSC, utilizzando le funzionalità di ricerca del sistema ILL (vedi use case ‘Individua DSC’).
Rimane da definire come identificare una eventuale biblioteca straniera che si propone come DSC: occorre verificare se è ugualmente prevista la registrazione nell’anagrafe biblioteche e l’assegnazione del relativo codice.
Specifiche tecniche di integrazione:
1. Immissione richiesta di servizio ILL
I dati relativi alla descrizione bibliografica, richiesti dal sistema ILL, sono inviati dall’ Opac tramite la costruzione di un messaggio di tipo POST URL, che contiene le seguenti variabili: faseILL – Id della funzione da richiamare (il default è DRS0 – D R S Zero) BufferILL - un buffer contente il documento XML da processare.
Esempio di URL inviato dall’OPAC al server ILL: http://prestito.iccu.sbn.it/ILLWeb/Servlets/ill.html?faseILL=DRS0&BufferILL="StringXML”
Dove: DRS0 – è l’ID della transazione da eseguire presso il server ILL. “StringXML” – viene sostituito con una stringa contente il documento XML.
I dati forniti come stringa XML sono specificati e descritti nel DTD (Document Type Definition) allegato a questo documento: ILLitem.dtd ; e un esempio del contenuto del buffer è fornito nel file OPAC-ILL- esempio.xml.
La risposta del sistema ILL ad un query ricevuta da OPAC è la visualizzazione dei dati trasmessi, reimpostati nella pagina di immissione della richiesta. Se il sistema ILL riceve una o più localizzazioni nella query (tag ‘bib’), viene verificata la registrazione dei codici biblioteca nell’archivio ILL, e viene presentata la lista risultante dai controlli come elenco di possibili destinatarie della richiesta.
Akros Informatica s.r.l. 31 Revisione 4 del 31 marzo 2000 PPrrreeessstttiiitttooo IIILLLL PPeeerrr SSBBNN –– SSppeeeccciiifffiiiccchheee FFuunnzziiiooonnaallliii
Il sistema ILL può ricevere fino a un massimo di 1000 codici biblioteche (tag ‘bib’): per ogni codice ricevuto, controlla la presenza della biblioteca nel proprio archivio, la disponibilità a svolgere il ruolo di DSC, e presenta all’utente l’elenco risultante da questi controlli, per l’indicazione della priorità di interesse. La limitazione è resa opportuna da valutazioni di tipo prestazionale sui tempi di elaborazione, e di traffico sulla rete
Una soluzione più efficiente può essere realizzata se l’Opac predispone una funzionalità per consentire all’utente la selezione delle localizzazioni di interesse, e invia quindi al sistema ILL una lista che si presuppone notevolmente ridotta. In questo caso, potrebbe essere utile la presenza nell’archivio Opac di un indicatore di ruolo, che indichi le biblioteche registrate come DSC nel sistema ILL. Questo indicatore potrebbe essere aggiornato chiedendo un apposito servizio al sistema ILL, che comunica all’Opac l’iscrizione al servizio delle biblioteche.
In sintesi, a fronte della volontà dell’utente di richiedere un servizio ILL, si consiglia la realizzazione, nell’ambiente Opac, delle seguenti opzioni:
1. possibilità di selezione delle biblioteche di interesse per l’utente: solo i codice delle biblioteche selezionate vengono inviate al server ILL come possibili destinatarie;
2. possibilità di selezionare il tipo di servizio richiesto (opzionale): il sistema OPAC può predisporre elementi grafici per la scelta del servizio, inviando al sistema ILL il relativo codice (vedi lista riportata precedentemente, nella descrizione della variabile ‘ser’).
3. Visualizzazione richieste di servizio ILL
La funzionalità di visualizzazione delle richieste, può essere attivata dall’utente finale tramite una apposita URL che viene resa disponibile dal sistema ILL.
Esempio di URL di accesso al sistema ILL: http://prestito.iccu.sbn.it/ILLWeb
Il link a questa applicazione può essere inserito nella pagina dell’applicazione Opac, e anche nel sito I.C.C.U. L’applicazione ILL si incarica di richiedere i dati di identificazione dell’utente, e di rendere disponibile la funzionalità di ricerca delle richieste, filtrabile per i parametri previsti dalle specifiche funzionali (vedi par. 3.4.1.2.3). Con questo accesso sarà disponibile per l’utente anche la funzionalità di immissione richiesta, che può essere utilizzata ad esempio per registrare richieste di localizzazione di un titolo non trovato in Opac.
Viene gestito un accesso pubblico al sistema ILL, con la comunicazione di user-id ‘guest’ e password ‘guest’. Per attivare la funzionalità di ricerca ed esame delle proprie richieste, l’utente deve comunicare al sistema (nella pagina di ricerca) il proprio e-mail e il numero della propria richiesta. Questo vincolo è stato introdotto per garantire la privacy dei dati delle richieste, nei confronti degli stessi utilizzatori del sistema.
Akros Informatica s.r.l. 32 Revisione 4 del 31 marzo 2000 PPrrreeessstttiiitttooo IIILLLL PPeeerrr SSBBNN –– SSppeeeccciiifffiiiccchheee FFuunnzziiiooonnaallliii
3.5.3 INTEGRAZIONE CON SBN UNIX
SBN UNIX è il software gestionale del Servizio Bibliotecario Nazionale, in modalità Client Server. Nel software gestionale sono presenti le funzionalità per il prestito locale e il prestito interbibliotecario tra biblioteche dello stesso Polo (che condividono il catalogo bibliografico sullo stesso data base).
Obiettivo del presente progetto è fornire le specifiche funzionali per la realizzazione dell’integrazione tra il servizio ILL e l’ambiente gestionale SBN Unix Client/Server.
Una prima problematica riguarda l’uniformità dell’interfaccia grafica tra i due sistemi, che devono essere attivati dal bibliotecario.
Questa integrazione viene risolta tramite la costruzione di funzionalità ILL che si configurano come servizi richiamabili da altre applicazioni, (con definiti input e output) che consentono lo sviluppo di una interfaccia utente integrata nel software gestionale: lo sviluppo del sistema ILL deve tenere ben separati quindi i propri servizi funzionali dalla propria interfaccia utente.
Requisito fondamentale è quindi armonizzare il trattamento delle richieste di servizio da qualsiasi fonte provengano, dal punto di vista del lavoro del bibliotecario; occorre cioè applicare le procedure già realizzate nel software gestionale SBN, alle richieste provenienti da fonti esterne, e raggiungere quindi una completa integrazione sia a livello funzionale che a livello di data base, rendendo trasparenti per il bibliotecario le differenze di informazioni e di configurazione tra i due sistemi informativi (attributi, codici).
Un argomento più complesso riguarda la gestione delle informazioni che sono presenti su entrambi i sistemi.
I dati relativi alle richieste di prestito sono residenti sul data base ILL, mentre i dati relativi ai volumi e alla loro movimentazione sono di competenza dell’ambiente gestionale.
La problematica di integrazione riguarda più pesantemente le richieste di prestito, mentre per le richieste di riproduzione si configura, come unica necessità di accesso al sistema gestionale, la verifica della disponibilità del documento da riprodurre nel periodo di tempo utile per l’evasione della richiesta.
L’iter funzionale del servizio interbibliotecario si configura nel modo seguente: il bibliotecario POS: 1. registra la richiesta di prestito, o valida una richiesta già creata da un proprio utente (ILL); il bibliotecario DSC: 2. riceve la richiesta di prestito (ILL); 3. verifica la disponibilità del documento e la possibilità di effettuare la richiesta (SBN); 4. aggiorna lo stato della richiesta: accettata , rifiutata o sospesa (ILL); se la richiesta è accettata: 5. registra la concessione del prestito (SBN: come prestito locale a lettore di tipo biblioteca POS); 6. registra la spedizione del volume alla biblioteca POS (ILL); 7. verifica la durata del prestito e invia un eventuale sollecito alla biblioteca POS; il bibliotecario POS: 8. registra il ricevimento del documento (ILL); 9. consegna il documento al proprio lettore e registra il prestito (SBN); 10. registra il rientro del prestito (SBN);
11. registra la riconsegna e la rispedizione del documento (ILL);
Akros Informatica s.r.l. 33 Revisione 4 del 31 marzo 2000 PPrrreeessstttiiitttooo IIILLLL PPeeerrr SSBBNN –– SSppeeeccciiifffiiiccchheee FFuunnzziiiooonnaallliii
il bibliotecario DSC: 12. registra il rientro del documento (ILL); 13. registra il rientro del prestito (SBN).
Come si vede, esistono diverse operazioni parallele nei due sistemi, che possono essere risolte tramite l’attivazione automatica dei servizi ILL. Ad esempio, l’aggiornamento dello stato della richiesta ILL, conseguente alle notifiche di invio, spedizione, rientro, possono essere collegate ad attività gestionali SBN che attivano automaticamente il servizio. Ciò presuppone l’esistenza di un collegamento permanente tra il sistema gestionale SBN e il server ILL .
Per garantire la possibilità di integrare compiutamente i due sistemi, in uno sviluppo futuro, occorre costruire il contenuto informativo del sistema ILL tenendo presente quest’esigenza. In particolare, occorre verificare che tutte le informazioni necessarie allo scambio automatico dei movimenti siano presenti e congruenti. A questo proposito si veda il paragrafo seguente: ‘Specifiche di integrazione dei dati’.
3.5.3.1 Specifiche funzionali di integrazione:
Sia il sistema ILL che i software Sbn Unix gestiscono richieste di servizi, e relativi movimenti. Esistono delle informazioni e delle procedure che sono comuni ai due sistemi. L’integrazione automatizzata deve corrispondere ai seguenti requisiti:
1. eliminare la necessità di ripetere operazioni di gestione, da parte del bibliotecario;
2. limitare la duplicazione delle informazioni nei due data base;
3. garantire l’efficienza, in termini di tempi di elaborazione e di traffico sulle linee.
Analizzando le tipologie di servizi ILL, la necessità di integrazione non si pone per le richieste di localizzazione e di preventivo, che vengono gestite interamente nel sistema ILL.
Per le richieste di riproduzione invece, si evidenzia la necessità di individuare l’inventario e la collocazione del documento, e la relativa disponibilità, sul data base gestionale (questa esigenza riguarda anche le richieste di prestito). In questo caso il sistema ILL si pone come ‘client’ del software SBN UNIX. L’assenza di una integrazione automatizzata non pone particolari problemi di aumento dei tempi di lavoro per il bibliotecario, che può mantenere attive le due applicazioni in ambiente windows, e semplicemente attivare la ricerca gestionale SBN con i parametri della richiesta ILL che ritiene più opportuni: bid, titolo, autore, e esaminare l’inventario opportuno per l’espletamento della richiesta: dopo aver completato la ricerca gestionale, il bibliotecario ritorna sulla applicazione ILL registrando la decisione presa (accettazione, sospensione, condizione, ecc.).
Volendo realizzare una integrazione automatizzata di questa attività, il software SBN UNIX deve fornire una interfaccia per l’attivazione dell’interrogazione, definendo quali parametri possono essere utilizzati per la ricerca, ed eventualmente comunicare al sistema ILL l’inventario selezionato, che può essere registrato tra i dati della richiesta.
La necessità di integrazione tra i due sistemi riguarda più significativamente le richieste di prestito interbibliotecario.
La richiesta di prestito viene registrata nel sistema ILL, e può essere poi inviata automaticamente al data base SBN UNIX, dove è presente l’entità che registra le richieste di servizio.
Akros Informatica s.r.l. 34 Revisione 4 del 31 marzo 2000 PPrrreeessstttiiitttooo IIILLLL PPeeerrr SSBBNN –– SSppeeeccciiifffiiiccchheee FFuunnzziiiooonnaallliii
Un caso particolare riguarda le richieste tra biblioteche dello stesso Polo SBN, che possono essere gestite anche all’interno del software gestionale. La richiesta può quindi essere effettuata dal lettore sia tramite Opac e sistema ILL, sia tramite le funzionalità SBN.
Il software può mettere a disposizione funzionalità di trasferimento delle richieste da un sistema all’altro, creando gli opportuni servizi nei due ambienti:
· SBN UNIX: deve predisporre un servizio che invia le richieste interbibliotecarie, immesse nel proprio gestionale, al sistema ILL che si occupa di registrarle nel proprio data base. L’invio deve contenere i dati necessari per la completezza della richiesta.
Le modalità di attivazione possono essere diverse: 1. puntuale on-line: ad ogni immissione di richiesta nel software SBN UNIX viene attivato l’invio presso il sistema ILL; il servizio ritorna l’identificativo assegnato alla richiesta ILL che può essere registrato nel data base SBN, e risulta utile per le gestione del successivo iter. 2. Cumulativo: a scadenza temporale (es. giornaliera: SBN UNIX invia le richieste registrate nella giornata). La scelta della modalità di attivazione rimane a carico del software SBN UNIX.
· ILL: deve predisporre un servizio che invia le richieste di prestito immesse al software SBN UNIX.
La presenza dei dati delle richieste nel data base gestionale, e la loro gestione si differenzia con il ruolo della biblioteca: POS o DSC.
La biblioteca POS gestisce il prestito al proprio lettore, e può non avere nel proprio data base il titolo del documento. La biblioteca DSC gestisce il prestito alla biblioteca POS. La biblioteca partner nella richiesta deve essere registrata sul data base gestionale come ‘Biblioteca esterna al sistema’ (vedi tavola TLRBIB di Sbn Unix).
Per garantire la possibilità di automazione e di scambio informazioni tra i due software, occorre definire alcuni requisiti:
1. deve esistere un identificativo comune per la richiesta ILL: il data base SBN UNIX deve contenere l’identificativo assegnato alla richiesta nel sistema ILL;
2. deve essere registrato il codice anagrafe delle biblioteche, utilizzato per identificare univocamente la biblioteca POS di un prestito;
3. deve essere definita una corrispondenza tra la codifica delle azioni/stati ILL con gli stati di SBN.
Il sistema ILL rende disponibili i seguenti servizi ILL:
· Invio delle richieste in un particolare stato (verrà fornita la codifica degli stati possibili, se non compilato dal chiamante verranno considerate tutte le richiesta che hanno cambiato stato nell’intervallo indicato). L’attivazione del servizio richiede i parametri: codice anagrafe biblioteca; ruolo (POS o DSC), intervallo temporale sulla data del passaggio nello stato attuale. Il servizio viene attivato da una chiamata predisposta dal software SBN UNIX.
Akros Informatica s.r.l. 35 Revisione 4 del 31 marzo 2000 PPrrreeessstttiiitttooo IIILLLL PPeeerrr SSBBNN –– SSppeeeccciiifffiiiccchheee FFuunnzziiiooonnaallliii
· Aggiornamento richiesta: viene attivato dal software SBN quando un evento registrato sul proprio gestionale comporta un passaggio di stato della richiesta. L’attivazione del servizio richiede i parametri: identificativo richiesta, data variazione, codice evento/stato.
Il software SBN può decidere se registrare o meno interamente la richiesta di prestito ILL sul proprio data base, deve però garantire la presenza della chiave identificativa della richiesta ILL, per comunicare con il sistema ILL .
3.5.3.2 Specifiche tecniche di Integrazione Funzionale
I messaggi di scambio di informazione tra i due sistemi vengono gestiti tramite la costruzione di documenti XML, che devono essere coerenti con il DTD ‘ILL-APDU.dtd’, allegato al presente documento.
Si sono individuate le seguenti Macro Funzionalità aggiuntive al software gestionale SBN:
1. Ricevimento nuove richieste immesse/ricevute.
2. Ricevimento richieste che hanno subito aggiornamenti nel periodo.
3. Invio aggiornamento di stato al Sistema ILL.
1. Ricevimento nuove richieste immesse/ricevute.
Il software Sbn attiva la funzionalità a livello di Client Power Builder, dove viene gestita una apposita voce di menu. Costruisce il documento XML (conforme al DTD ‘ILL-APDU.dtd); riceve il documento XML di risposta sempre a livello di Client.
Il documento XML viene analizzato a livello Client. Ogni richiesta viene visualizzata all’operatore, con una apposita funzionalità da realizzare in Power Builder; l’operatore può ricercare con le funzionalità proprie dell’ambiente gestionale le informazioni collegate alla richiesta:
1. titolo del documento: se nella richiesta è presente il bid, il titolo viene cercato automaticamente sul data base gestionale e visualizzato all’operatore, altrimenti vengono presentati i dati bibliografici della richiesta con cui l’operatore può effettuare le opportune attività di interrogazione sul biblio-server.
2. Inventario: una volta individuato il titolo, la ‘biblioteca destinataria’ può selezionare l’inventario oggetto della richiesta con le funzionalità di interrogazione già realizzate nel software Sbn Unix, e verificarne la disponibilità e le condizioni di prestito.
3. Lettore: la ‘biblioteca richiedente’ può visualizzare il proprio lettore, utilizzando il codice identificativo o il nome (presenti sulla richiesta ILL) e verificarne i diritti e le autorizzazioni ad usufruire del servizio.
Una volta completata la richiesta con le informazioni gestionali, l’operatore conferma la registrazione della richiesta nel proprio data base gestionale, o il rifiuto.
Le singole richieste vengono inviate al server di livello BIBLIO, utilizzando le funzionalità del middleware proprietario di SBN Unix, e registrate sul data base tramite una apposita procedura Cobol.
Akros Informatica s.r.l. 36 Revisione 4 del 31 marzo 2000 PPrrreeessstttiiitttooo IIILLLL PPeeerrr SSBBNN –– SSppeeeccciiifffiiiccchheee FFuunnzziiiooonnaallliii
Il successivo trattamento delle richieste viene integrato con apposite funzionalità nella procedura già realizzata nel software SBN Unix (vedi specifica funzionale ‘Dettaglio richieste di Polo’ del CSI Piemonte). Le richieste che provengono dal Sistema ILL vengono caratterizzate con un tipo di servizio specifico (vedi paragrafo seguente: Specifiche di integrazione dei dati’).
Tecnicamente , il colloquio si svolge con il seguente scambio di documenti XML
1. invio da Sbn a ILL: elemento
2. ritorno da ILL: elemento
Per il dettaglio sulla compilazione dei tag XML si veda il testo di ‘ILL-APDU.dtd’ allegato.
2. Ricevimento richieste che hanno subito aggiornamenti nel periodo.
Il software Sbn attiva la funzionalità a livello di Client Power Builder, dove viene gestita una apposita voce di menu. Costruisce il documento XML (conforme al DTD ‘ILL-APDU.dtd’); riceve il documento XML di risposta sempre a livello di Client.
Questa attività consente di riportare sul data base gestionale SBN i passaggi di Iter che sono stati registrati (direttamente o per via automatica) nel Sistema ILL. In questo modo, sul data base della biblioteca richiedente viene registrato il passaggio di stato effettuato dalla biblioteca destinataria, e viceversa.
Questa funzionalità consente quindi di mantenere aggiornati e allineati i contenuti informativi dei due data base, e di rendere visualizzabile lo stato attuale della richiesta nell’ambiente gestionale, anche quando l’avanzamento nell’iter è di competenza della biblioteca partner nella richiesta (che utilizza un Biblio Server diverso).
Tecnicamente , il colloquio si svolge con il seguente scambio di documenti XML
3. invio da Sbn a ILL: elemento
4. ritorno da ILL: elemento
Per il dettaglio sulla compilazione dei tag XML si veda il testo di ‘ILL-APDU.dtd’ allegato.
3. Invio aggiornamenti al Sistema ILL.
Questo aspetto dell’integrazione riguarda la necessità di evitare la duplicazione delle registrazioni dei passaggi di stato nei due sistemi informativi.
Quando il bibliotecario (sia destinatario che richiedente) esegue un avanzamento nell’iter, utilizzando le funzionalità del software SBN Unix , viene inviata automaticamente la relativa comunicazione al Sistema ILL che provvede a registrare il passaggio di stato.
La comunicazione viene gestita tramite lo scambio di un documento XML, conforme al DTD ‘ILL- APDU.dtd’.
L’invio del documento XML viene effettuato dal Client Power Builder verso il server Java del Sistema ILL, contemporaneamente all’avvio della registrazione dell’aggiornamento nel data base gestionale.
Tecnicamente , il colloquio si svolge con il seguente scambio di documenti XML
Akros Informatica s.r.l. 37 Revisione 4 del 31 marzo 2000 PPrrreeessstttiiitttooo IIILLLL PPeeerrr SSBBNN –– SSppeeeccciiifffiiiccchheee FFuunnzziiiooonnaallliii
1. invio da Sbn a ILL: elemento
dove tag-di-stato viene sostituito con il tracciato opportuno, secondo la seguente tabella di relazione:
Azione Tag XML Accettazione richiesta da parte del destinatario forward-notification Spedizione del documento da parte della biblioteca destinataria shipped Invio di messaggio dal destinatario al richiedente ILL-Answer Risposta del richiedente ad una condizione posta dal Conditional-Reply destinatario Annullamento della richiesta da parte del richiedente Cancel Arrivo del materiale alla biblioteca richiedente Received Sollecito restituzione del prestito Recall Rispedizione del documento dal richiedente al destinatario Returned Rientro del documento presso il destinatario Checked-in Avviso di scadenza del prestito al richiedente Overdue Richiesta di rinnovo di un prestito al destinatario Renew Risposta alla richiesta di rinnovo prestito dal destinatario al Renew-Answer richiedente
2. ritorno da ILL: elemento
Per il dettaglio sulla compilazione dei tag XML si veda il testo di ‘ILL-APDU.dtd’ allegato.
3.5.3.3 Specifiche di integrazione dei dati:
La presenza dei dati delle richieste nel data base gestionale, e la loro gestione si differenzia con il ruolo della biblioteca: POS o DSC.
La biblioteca POS gestisce il prestito al proprio lettore, e può non avere nel proprio data base il titolo del documento.
La biblioteca DSC gestisce il prestito alla biblioteca POS, e può non avere i dati della biblioteca richiedente sul proprio data base.
Per garantire la possibilità di automazione e di scambio informazioni tra i due software, occorre definire alcuni prerequisiti:
1. deve esistere un identificativo comune per la richiesta ILL: il data base SBN UNIX deve cioè contenere l’identificativo assegnato alla richiesta nel sistema ILL;
2. deve essere registrato il codice anagrafe delle biblioteche, utilizzato per identificare univocamente la biblioteca POS di un prestito;
3. deve essere definita una corrispondenza tra la codifica delle azioni/stati ILL con gli stati di SBN, dei tipi di servizio e dei passaggi di iter.
Le informazioni coinvolte nella registrazione di una richiesta proveniente dal Sistema ILL sono:
Akros Informatica s.r.l. 38 Revisione 4 del 31 marzo 2000 PPrrreeessstttiiitttooo IIILLLL PPeeerrr SSBBNN –– SSppeeeccciiifffiiiccchheee FFuunnzziiiooonnaallliii
· la richiesta di servizio;
· il titolo oggetto della richiesta: nel data base della biblioteca DSC è presente, come titolo SBN, mentre nel data base della biblioteca POS può essere un titolo SBN o un documento non catalogato;
· la biblioteca partner nella richiesta: deve essere già registrata nel data base gestionale.
· Il lettore richiedente: deve essere individuabile nel data base della biblioteca POS.
La richiesta proveniente dal Sistema ILL deve quindi contenere le informazioni sufficienti per consentire:
1. l’identificazione della Biblioteca Partner; se questa non risulta registrata il software Sbn si può incaricare di creare una registrazione incompleta, (con il solo codice anagrafe) , e recuperare poi in maniera automatica o manuale le informazioni dal Sistema Informativo ‘Anagrafe Biblioteche’;
2. l’identificazione del titolo, o l’eventuale registrazione del documento non catalogato;
3. l’identificazione del lettore richiedente (sul data base della biblioteca POS).
Queste considerazioni comportano quindi la necessità di effettuare opportune modifiche alla struttura del data base del software SBN Unix.
Nel seguito si indicano gli aggiornamenti ritenuti necessari alla struttura dati di SBN Unix Client/Server, con riferimento alla documentazione relativa fornita dall’I.C.C.U.
Corrispondenze tra codifiche e configurazione nei due sistemi
Per uniformare la semantica dei due sistema informativi, senza intervenire sulle funzionalità software, occorre definire delle corrispondenze tra i diversi valori codificati. Le informazioni interessate a questa attività di definizione sono: tipo di servizio (tabella TVLTSE)
Contiene le tipologie di servizio previste in Sbn Unix. Devono essere inseriti gli elementi relativi ai servizi interbibliotecari.
Codice Descrizione LC Servizio di localizzazione PR Prestito interbibliotecario nazionale PI Prestito interbibliotecario internazionale RI Riproduzione CR Preventivo riproduzione CP Preventivo prestito tipo di supporto (tabella TVLSUP)
00 Fotocopia 01 Copia di file su floppy disc 02 Stampa su carta di file da banche dati 03 Fotocopia da microfilm 04 Fotografia 05 Documento Originale 06 Messaggio elettronico
Akros Informatica s.r.l. 39 Revisione 4 del 31 marzo 2000 PPrrreeessstttiiitttooo IIILLLL PPeeerrr SSBBNN –– SSppeeeccciiifffiiiccchheee FFuunnzziiiooonnaallliii
Modifiche Tavole di data base SBN
1. Tavola TLLRSA – richieste di servizi attuali
· Inserimento di un attributo: prg_ill Integer, contenente il numero identificativo della richiesta di servizio nell’ambito del Sistema ILL.
2. Tavola TLRBIB – Biblioteche
· Inserimento di un attributo: cod_anagrafe char(12), contenente il codice identificativo della biblioteca nell’ambito dell’archivio anagrafico nazionale.
Corrispondenza tra documento XML e attributi del data base gestionale
Nella seguente tabella si illustra la corrispondenza tra gli attributi della richiesta di servizio del data base Sbn (tavola TLLRSA) e quanto definito nel tracciato del documento XML di scambio dati con il sistema ILL
Data Base della biblioteca destinataria
a) nuova richiesta: documento ricevuto dal Sistema ILL in
a.1 ) Tracciato ILL-Request
Tag XML Significato Tavola Attributo Tavola di Note SBN decodifica Transaction-Id identificativo TLLRSA Prg_ill (nuovo Deve essere creata richiesta ILL attributo) una nuova entità per ogni elemento ILL- Request inviato dal Sistema ILL Service-date-time data di inserimento TLLRSA Data_richiesta della richiesta Requester-Id identificativo bibl.. TLRBIB Cod_anagrafe Sbn deve recuperare richiedente (nuovo attributo) da TLRBIB il codice identificativo gestionale della biblioteca Responder-Id identificativo bibl.. Codice anagrafe della destinataria biblioteca di lavoro Delivery-address indirizzo di Vedi nota 1. consegna Supply-medium- supporto richiesto TLLRSA Cod_supporto TVLSUP type Place-on-hold indicatore di Non gestito in Sbn possibilità di sospensione Item-Id informazioni sul Vedi documento tab.a.1.1
Akros Informatica s.r.l. 40 Revisione 4 del 31 marzo 2000 PPrrreeessstttiiitttooo IIILLLL PPeeerrr SSBBNN –– SSppeeeccciiifffiiiccchheee FFuunnzziiiooonnaallliii
Client-Id Informazioni sul Vedi lettore tab.a.1.2 Date-requester data desiderata per Non gestito in Sbn la consegna Need-before-date data limite di TLLRSA Data_massima validità della richiesta Cost-info-type condizioni di TLLRSA pagamento Copyright- accordo copyright TLLRSA copyright Va impostato a ‘S’ se compliance è presente il tag Requester-note note del richiedente TLLRSA Note_ut ILL-Service-type: attributo: tipo di TLLRSA Cod_tipo_serv TVLTSE servizio
Nota 1: queste informazioni non sono presenti tra gli attributi della richiesta di prestito Sbn. Vengono pertanto accodati nell’attributi ‘nota_ut’ dell’entità TLLRSA.
a.1 .1) Tracciato Item-Id: documento oggetto della richiesta
NB: se il documento è presente nel data base gestionale (ricercato tramite bid), non viene effettuata nessuna registrazione , altrimenti viene registrata una entità nella tavola TLLDOC.
Tag XML Significato Tavola Attributo Tavola di Note SBN decodifica Item-type Natura TLLDOC natura Medium-type Tipo materiale TLLDOC Location-note Nota di TLLDOC segnatura Collocazione Author Autore TLLDOC autore Title Titolo TLLDOC titolo Sub-title Sottotitolo TLLDOC titolo Accodato a title Sponsoring-body Ente curatore Non gestito in SBN Place-of- Luogo di TLLDOC Luogo_edizione publication pubblicazione Publisher Editore TLLDOC editore Series-title-number Titolo di collana Accodato a title e subtitle Volume-issue Numero volume TLLDOC Num_volume Issue Fascicolo Vedi nota 1. Edition Edizione Vedi nota 1. Publication-date Data di Vedi nota 1. pubblicazione Author-of-article Autore dell’articolo Vedi nota 1. Title-of-article Titolo dell’articolo Vedi nota 1. Pagination pagine Vedi nota 1. National- Codice BID TLLDOC bid bibliografic- number Standard-number Numero standard Vedi nota 1.
Akros Informatica s.r.l. 41 Revisione 4 del 31 marzo 2000 PPrrreeessstttiiitttooo IIILLLL PPeeerrr SSBBNN –– SSppeeeccciiifffiiiccchheee FFuunnzziiiooonnaallliii
Verification- Fonte di Vedi nota 1. reference-source provenienza Additional-no- Inventario TLLDOC inventario letters System-no Codice Non usato Non usato in Sbn identificativo alternativo
a.1 .2) Tracciato Client-Id: lettore richiedente
NB: queste informazioni sono di interesse della biblioteca richiedente, che deve individuare e autorizzare il lettore che ha effettuato la richiesta, e registrare eventualmente il prestito.
Tag XML Significato Tavola Attributo Tavola di Note SBN decodifica Client-identifier identificativo TLRUTE Cod_bib_ut lettore Cod_utente Client-name nome del lettore TLRUTE Cognome_nome Email email del lettore TLRUTE Ind_posta_elettr
Akros Informatica s.r.l. 42 Revisione 4 del 31 marzo 2000 PPrrreeessstttiiitttooo IIILLLL PPeeerrr SSBBNN –– SSppeeeccciiifffiiiccchheee FFuunnzziiiooonnaallliii
3.5.3.4 Tecnologie per Il Collegamento SBN a Prestito ILL
La comunicazione tra ILL e SBN viene iniziata da SBN, che assume il ruolo di Client, mentre il Sistema ILL assume il ruolo di Server.
Questa soluzione riduce al minimo le situazioni in cui non sia disponibile il collegamento tra i due sistemi, in quanto il server su cui è installato il Sistema ILL deve garantire l’accessibilità 24 ore su 24.
La scelta tecnologica per l’implementazione di tale dialogo è condizionata dalle specifiche architetturali di SBN / Unix, che articolano un sistema client / server 3-tier con GUI Client realizzato in PowerBuilder v5.0.0x, un server applicativo realizzato in COBOL / C / SQL ed un server dati (DBMS) Informix DS v7.x. Il collegamento tra GUI Client ed application server avviene tramite un elemento architetturale costituito da un software “middleware” realizzato dalla Finsiel.
L’architettura SBN prevede i tre livelli: Indice, Polo e Biblio Server. Il prestito viene gestito dal Biblio Server.
La realizzazione dell’ applicazione che dal Client Power Builder interagisce con il sistema ILL è condizionata dalla versione di Power Builder utilizzata per il software SBN Unix.
Tale condizione viene posta nel contesto della funzionalità di interfacciamento alla rete, che viene significativamente esteso nel contesto di versioni di PowerBuilder più recenti (in particolare la versione 7 che fornisce l’integrazione del CLIENT con CORBA / IIOP). Questa funzionalità ridurrebbe i costi di realizzazione del software in questione, da contrapporre però ai costi di porting dell’esistente applicativo alla versione 7 di Power Builder.
L’uso di CORBA (Common Object Request Borker Architecture), che rappresenta uno standard della OMG (Object Management Group – http://www.omg.org) è ormai diffuso sia come implementazione a parte che come parte di molti database (Informix, Oracle).
Questa architettura rappresenta un sviluppo della tecnologia rispetto a TCP sockets ed RPC, e permette maggiore indipendenza tra le implementazioni del client e del server, che possono essere sistemi realizzati con software ed architetture diversi fra loro. I messaggi vengono scambiati con la mediazione di un ORB (Object Request Broker) che garantisce la localizzazione del servizio e gestisce l’interfaccia tra client e server.
I requisiti sono:
· Un ORB presso il centro servizi ILL (ad esempio VisiBroker).
· La realizzazione di interfaccie IDL per il server ILL. In gran parte queste possono essere generate dalle funzioni già realizzate nel software ILL. Queste interfaccie comprendono codice C/C++ o Java una parte del quale viene esportato per l’utilizzo nello sviluppo del client.
· La realizzazione di funzioni client che utilizzano gli “stub” IDL per comunicare i cambi di stato al server ILL. Gli “stub” possono essere integrati in programmi COBOL o C/C++ sul server Biblio o in alternativa sul client PowerBuilder.
Si evidenziano due aspetti tecnici, conseguenti alle indicazioni delle specifiche funzionali:
Akros Informatica s.r.l. 43 Revisione 4 del 31 marzo 2000 PPrrreeessstttiiitttooo IIILLLL PPeeerrr SSBBNN –– SSppeeeccciiifffiiiccchheee FFuunnzziiiooonnaallliii
1. XML Parsing: la costruzione di documenti XML viene facilitato da un parser XML che implementa il W3C DOM standard. Questi parser esistono in C++ (ad esempio: Expat v1.0), e possono essere interfacciati con PowerBuilder attraverso l’esistente architettura per chiamate esterne (anche per la versione 5 di PowerBuilder).
2. Protocollo Applicativo Client / Server ed Interfaccia di Comunicazione: tale protocollo specificato nel XML DTD allegato si poggia su in interfaccia di rete che permette la trasmissione di messaggi tra Client (SBN) e Server (ILL) in due ambienti diversi. Quest’interfaccia può essere realizzata su rete TCP/IP usando RPC (PowerBuilder v5, v6.0, v6.5 e v7), HTTP (PowerBuilder v6.0, v6.5 e v7) o CORBA / IIOP (PowerBuilder 7) come meccanismi per il trasferimento dei messaggi.
Ø Nel caso di RPC occorre costruire un servizio (server) nell’ambiente ILL.
Ø Nel caso di HTTP si può sfruttare l’esistente architettura del servizio ILL che si basa sui servlet. Il client effettua chiamate al server HTTP (usando la funzione PostURL e gli oggetti Inet e InternetResult di PowerBuilder v6.0 / 6.5 e 7). Le risposte del server vengono fornite in formato text/HTML o text/XML. In questo caso il client si comporta come se fosse un Browser Web.
Ø Nel caso dell’uso di CORBA tale servizio viene fornito dall’ ORB e la realizzazione si riduce alla costruzione dell’interfaccia CORBA per ricevere ed inviare i messaggi.
3.5.3.5 Specifiche per il Collegamento a Prestito ILL
Il Sistema ILL dispone di una modalità di accesso tramite documento XML, ricevendo chiamate al server HTTP tramite la funzione PostURL. Il protocollo di colloquio è definito nel documento allegato ‘ILL- APDU.dtd’.
Il Sistema ILL assume il ruolo di server, e può ricevere e elaborare le seguenti tipologie di messaggi ILL- APDU:
Azione Tag XML Inserimento nuova Richiesta di Servizio ILL-Request Accettazione richiesta da parte del destinatario forward-notification Spedizione del documento da parte della biblioteca destinataria shipped Invio di messaggio dal destinatario al richiedente ILL-Answer Risposta del richiedente ad una condizione posta dal Conditional-Reply destinatario Annullamento della richiesta da parte del richiedente Cancel Arrivo del materiale alla biblioteca richiedente Received Sollecito restituzione del prestito Recall Rispedizione del documento dal richiedente al destinatario Returned Rientro del documento presso il destinatario Checked-in Avviso di scadenza del prestito al richiedente Overdue Richiesta di rinnovo di un prestito al destinatario Renew Risposta alla richiesta di rinnovo prestito dal destinatario al Renew-Answer richiedente Esame Richieste di Servizio Status-or-error-report
Akros Informatica s.r.l. 44 Revisione 4 del 31 marzo 2000 PPrrreeessstttiiitttooo IIILLLL PPeeerrr SSBBNN –– SSppeeeccciiifffiiiccchheee FFuunnzziiiooonnaallliii
Per le modalità e il significato dei tag si rimanda al documento ‘ILL-APDU.dtd’, e a quanto descritto nei paragrafi precedenti riguardo l’integrazione con SBN.
Il Sistema ILL ritorna in ogni caso un messaggio di risposta al client, utilizzando il tag ‘Status-or-error- report’.
Il messaggio di tipo POST URL, per l’attivazione del servizio ILL, deve contenere le seguenti variabili: faseILL – Id della funzione da richiamare , deve essere: DRS0 ( D R S Zero) BufferILL - un buffer contente il documento XML da processare.
Esempio di URL inviato al server ILL: http://prestito.iccu.sbn.it/ILLWeb/Servlets/ill.html?faseILL=DRS0&BufferILL="StringXML”
Dove: DRS0 – è l’ID della transazione da eseguire presso il server ILL. “StringXML” – viene sostituito con una stringa contente il documento XML secondo ‘ILL-APDU.dtd’.
Akros Informatica s.r.l. 45 Revisione 4 del 31 marzo 2000 PPrrreeessstttiiitttooo IIILLLL PPeeerrr SSBBNN –– SSppeeeccciiifffiiiccchheee FFuunnzziiiooonnaallliii
3.5.4 INTEGRAZIONE CON SISTEMI LEGACY Con ‘sistema legacy’ si indica un sistema informativo che intende utilizzare i servizi messi a disposizione dal sistema ILL. Il software gestionale SBN UNIX è un esempio di sistema legacy.
L’esigenza di costruire un sistema aperto, che consenta in tempi futuri l’integrazione con altri circuiti di prestito interbibliotecario, viene considerato un importante requisito nella progettazione dei servizi ILL.
Il sistema ILL deve cioè disporre di una interfaccia ‘pubblica’ dei propri servizi, da mettere a disposizione dei sistemi informativi che vogliano costruire una integrazione.
Nel seguito si fornisce l’elenco dei servizi che possono esporre una interfaccia pubblica, utilizzabile da un sistema legacy:
1. visualizza richieste di competenza: gestisce la produzione della lista delle richieste di competenza della biblioteca richiedente, in qualità di POS o DSC. Le richieste possono essere selezionabili per stato, o per i parametri previsti nella funzione ‘Visualizza richieste per dominio’; 2. visualizza richieste non indirizzate: gestisce la produzione della lista delle richieste che non sono indirizzate ad alcun DSC; è selezionabile per tipo di servizio ILL. 3. nuova richiesta: consente l’inserimento di una richiesta completa di tutti i dati: descrizione bibliografica, tipo di servizio, lista dei DSC , ecc. 4. modifica stato: consente la gestione del passaggio di stato di una richiesta, richiede in input l’identificativo della richiesta (individuabile da una precedente attività di visualizzazione (punto 1); 5. registra notifica: consente la comunicazione di una azione di notifica (spedizione, ricevimento, ecc. ) con aggiornamento dello stato della richiesta; 6. registra sollecito: consente la comunicazione di sollecito della restituzione per la biblioteca POS, richiede in input l’identificativo della richiesta; 7. richiede rinnovo: consente l’invio della richiesta di rinnovo del prestito alla biblioteca DSC , richiede in input l’identificativo della richiesta.
Akros Informatica s.r.l. 46 Revisione 4 del 31 marzo 2000 PPrrreeessstttiiitttooo IIILLLL PPeeerrr SSBBNN –– SSppeeeccciiifffiiiccchheee FFuunnzziiiooonnaallliii
3.5.5 INTEGRAZIONE CON SISTEMI BANCARI Una parte importante del sistema ILL è il trattamento delle informazioni economiche dei servizi. Il modello AIDA contiene la descrizione dettagliata della gestione amministrativa e contabile dei partners , che però è necessariamente di tipo virtuale. Nel progetto attuale, si mantengono nel sistema ILL le informazioni necessarie al calcolo del costo dei servizi, e le registrazioni delle transazioni economiche.
La soluzione ottimale della problematica è integrare il sistema ILL con il sistema bancario, che può fornire le informazioni sui reali movimenti di addebito e accredito, consentendo di automatizzare i controlli sui pagamenti.
Il sistema bancario ha il compito di registrare i versamenti degli utenti finali, per il pagamento dei servizi, e accreditare gli importi dovuti alle biblioteche POS e DSC.
Una ulteriore possibilità di integrazione riguarda l’affidamento a un ente esterno dei servizi di spedizione dei documenti:
1. spedizione da parte della biblioteca DSC, di riproduzione o di documento originale; 2. rispedizione da parte della biblioteca POS del documento originale.
Si ipotizza quindi una integrazione, anche in modalità off-line (a scadenza giornaliera), che consenta la comunicazione al sistema bancario, a fronte di una transazione commerciale, delle informazioni che consentano:
1. l’identificazione della richiesta che ha generato la transazione (causale); 2. il destinatario dell’accredito (biblioteca POS e/o DSC); 3. l’importo da accreditare a ogni destinatario (biblioteca POS, DSC, ente incaricato della spedizione); 4. l’identificazione dell’utente che deve provvedere al pagamento.
Da parte sua, il sistema bancario deve restituire al sistema ILL (secondo le stesse modalità off-line), i dati relativi ai pagamenti avvenuti. Si ipotizza che il tracciato di ritorno contenga le seguenti informazioni:
1. identificazione della transazione commerciale; 2. conferma dell’avvenuto pagamento (data di registrazione, modalità o altro).
Nota sulla Schema di Transazione in Capitolo 3.5.5.1
È importante notare che la schema di transazione fornito nel seguente capitolo è inteso come una registrazione autonoma di una singola transazione, indipendente di qualsiasi sistema di gestione pagamenti che possa esistere o non presso l’utente. Come tale il record contiene tutti i dati necessari al completamento della transazione (cioè non dipende da componenti esterne che possono avere implementazioni diverse, ad esempio: SAP , “One World” ). Questo approccio garantisce una maggiore flessibilità nella scelta del software di gestione pagamenti da utilizzare, in quanto il file di transazioni può essere importato in qualunque sistema senza il bisogno di completare le informazioni da altri fonti.
Il riempimento del record stesso può essere automatizzato in gran parte con informazioni già residenti nella banca dati del sistema ILL. Questo è vero per enti ed utenti già conosciuti al sistema. Il problema della gestione di dati personali sussiste in ogni caso in quanto ogni transazione bancaria prevede la presenza di coordinate bancarie relative all’origine e alla destinazione. È ammissibile che una transazione a due vie sia spezzata in due transazioni separate per fornire maggiore sicurezza e privacy sui dati:
1. Transazione Utente->POS. 2. Transazione POS->DSC.
In questo modo le informazioni dell’utente non vengono trasmesse al DSC.
Akros Informatica s.r.l. 47 Revisione 4 del 31 marzo 2000 PPrrreeessstttiiitttooo IIILLLL PPeeerrr SSBBNN –– SSppeeeccciiifffiiiccchheee FFuunnzziiiooonnaallliii
3.5.5.1 Meta-Schema Dati Per l’Interfaccia (batch) con il Sistema Bancario
La schema descrive una transazione a tre vie tra: cliente, fornitore POS e fornitore DSC. La presenza dei dati del fornitore POS è opzionale in quanto transazioni possono coinvolgono solo il cliente ed il DSC.
File: Sequenziale Record: Lunghezza fisso Charset: ISO-8859-1 (Latin-1) – convertibile in EBCDIC per ambiente S/370 del sistema bancario. Nome Campo Tipo Lung. In Byte Commento ID Integer 8 ID della Transazione registrato presso DSC Data_Trans Integer 8 Data della richiesta da parte del Cliente Tipo_Trans Integer 4 Codice per il tipo di pagamento: 0 = Cliente - DSC diretto (non coinvolge POS) 1 = Cliente - POS – DSC (tutti tre) ecc.. Valore_Euro Integer 8 Somma in euro da versare Valore_Lire Integer 8 Somma in lire da versare. Dati Cliente SEMPRE C_Metodo Integer 4 Codice per il tipo di pagamento: 0 = Conto di credito presso biblioteca POS (se Tipo_Trans=1). 1 = Carta di Credito, ECC.. C_Nome Text 30 Nome sull’intestazione del conto usato per pagamento C_Istituto Text 30 Nome dell’Istituto Bancario del cliente =”POS” se da addebitare dal conto di credito presso il POS C_Conto Text 20 Numero identificativo del conto da addebitare C_ABI Text 4 Codice ABI del Conto C_CAB Text 5 Codice CAB del Conto POS_CodBanc Text 10 Codice Internazionale dell’Istituto Bancario C_Codice Text 15 Codice di autorizzazione bancario (se Carta di Credito) C_Scadenza Text 30 Scadenza (se Carta di Credito) Dati Istituzione POS PRESENTE SE Tipo_Trans=1 POS_Nome Text 30 Nome dell’Istituzione POS POS_Conto Text 20 Numero del Conto Bancario dell’Istituzione POS POS_ABI Text 4 Codice ABI del Conto (POS) POS_CAB Text 5 Codice CAB del Conto (POS) POS_CodBanc Text 10 Codice Internazionale dell’Istituto Bancario (POS) POS_Ist_Banc Text 30 Nome dell’Istituto Bancario (Conto POS) Dati Istituzione DSC SEMPRE DSC_Nome Text 30 Nome dell’Istituzione DSC DSC_Conto Text 20 Numero del Conto Bancario dell’Istituzione DSC DSC_ABI Text 4 Codice ABI del Conto (DSC) DSC_CAB Text 5 Codice CAB del Conto (DSC) POS_CodBanc Text 10 Codice Internazionale dell’Istituto Bancario (DSC) DSC_Ist_Banc Text 30 Nome dell’Istituto Bancario (Conto DSC) DSC_Percent Integer 4 Percentuale della somma spettante all’Istituto DSC
Akros Informatica s.r.l. 48 Revisione 4 del 31 marzo 2000 PPrrreeessstttiiitttooo IIILLLL PPeeerrr SSBBNN –– SSppeeeccciiifffiiiccchheee FFuunnzziiiooonnaallliii
3.5.6 INTEGRAZIONE CON ANAGRAFE BIBLIOTECHE La presenza di un archivio di Anagrafe Biblioteche semplifica l’identificazione dei Soggetti nel sistema ILL.
Il codice identificativo assegnato nell’ambito del sistema anagrafico rappresenta un codice univoco, a livello nazionale, della biblioteca che si vuole identificare.
Se anche i sistemi OPAC che interfacciano il sistema ILL utilizzano questo codice identificativo, ciò rende possibile in modo automatico l’identificazione dei possibili DSC di una richiesta.
Anche per le biblioteche straniere, e per gli enti non strettamente bibliotecari che vogliono aderire al sistema ILL (istituti di ricerca, enti privati, ecc.), deve essere effettuata l’iscrizione all’anagrafe.
L’integrazione con il sistema Anagrafe offre il vantaggio della gestione unificata, a livello nazionale, dell’identificazione e dei dati anagrafici delle biblioteche, eliminando la necessità di realizzare (e manutenere) software diversi per la stessa gestione.
Nel data base del sistema ILL, i Soggetti vengono registrati con il codice identificativo assegnato dall’anagrafe. Ciò offre il vantaggio di non costringere gli operatori delle biblioteche a utilizzare un ulteriore codice di identificazione, in aggiunta al codice anagrafe e all’eventuale codice SBN.
La scheda anagrafica della biblioteca viene inserita e aggiornata nell’archivio dell’anagrafe, garantendo così il controllo delle informazioni in un unico sistema informativo. Il sistema Anagrafe deve fornire gli accessi ai propri servizi di interrogazione, che devono essere integrati nel sistema ILL. La realizzazione di questa apertura del sistema, e dell’integrazione, è auspicabile anche relativamente al software gestionale SBN, in modo da evitare la necessità di inserimento (e modifica ) delle anagrafiche delle biblioteche partners nel data base SBN.
In pratica, le attività informatiche si configurano come descritto di seguito.
Sistema Anagrafe:
deve essere consentita l’attivazione del servizio di ricerca, con gli strumenti disponibili da un browser web (POST URL). La ricerca deve essere possibile tramite:
1. la comunicazione del codice anagrafico: il sistema Anagrafe visualizza in modo analitico la scheda richiesta, oppure comunica la non esistenza del codice al sistema chiamante (ILL o SBN). 2. nessun codice: il sistema Anagrafe deve rendere disponibile le proprie attività di ricerca (ad esempio parte iniziale della intestazione, o ricerca per parole dell’intestazione), gestisce la visualizzazione analitica della scheda anagrafica di una biblioteca selezionata, e la restituzione al sistema chiamante (ILL o SBN gestionale) del codice anagrafico e dell’intestazione della biblioteca selezionata (o un risultato vuoto, se non è stata selezionata alcuna biblioteca).
Sistema ILL
Il sistema ILL registra nel proprio data base i Soggetti con i dati recuperati dall’Anagrafe:
1. codice identificativo; 2. intestazione. Questi dati non sono modificabili dalle funzionalità del sistema ILL. L’eventuale modifica dell’intestazione di una biblioteca (che viene effettuata nel sistema Anagrafe), viene recuperata nel sistema ILL:
Ø con la funzione di ‘Identificazione Soggetto’ (vedi descrizione seguente); Ø in modalità ‘off-line’ , con comunicazione periodica delle variazioni da parte del sistema ‘Anagrafe’
Akros Informatica s.r.l. 49 Revisione 4 del 31 marzo 2000 PPrrreeessstttiiitttooo IIILLLL PPeeerrr SSBBNN –– SSppeeeccciiifffiiiccchheee FFuunnzziiiooonnaallliii
(produzione di ‘file’ contenente le intestazioni modificate in un dato periodo di tempo’).
I punti di integrazione tra i due sistemi riguardano diverse funzionalità:
Gestione utenti/servizi
La funzione di ‘Identificazione Soggetto’ consente la:
Ø digitazione del codice anagrafe del Soggetto: viene attivata la URL del sistema Anagrafe, con passaggio del parametro ‘codice anagrafe’; Ø attivazione diretta del sistema Anagrafe, tramite un apposito oggetto grafico (bottone o icona): viene attivata la URL del sistema Anagrafe senza passaggio di parametri.
La funzionalità del sistema Anagrafe restituisce al sistema ILL il codice anagrafico e l’intestazione della biblioteca selezionata, o un indicatore per significare che la ricerca ha dato esito nullo.
La funzionalità del sistema ILL, prosegue con le seguenti modalità:
Ø inserimento: se il codice anagrafico restituito dal sistema Anagrafe non è presente nel data base ILL, viene attivata automaticamente la funzionalità di inserimento, che registra il nuovo Soggetto con il codice e l’intestazione recuperati; Ø aggiornamento: se il codice anagrafico è già registrato nel data base ILL, viene eventualmente aggiornata l’intestazione del Soggetto, se questa risulta diversa dall’intestazione recuperata dall’anagrafe.
In entrambi i casi la funzione prosegue con la gestione delle informazioni interne al sistema ILL: servizi attivabili, listino prezzi, ecc.
Se il collegamento con il sistema Anagrafe non è momentaneamente disponibile, viene comunque consentita la gestione delle informazioni interne di un Soggetto già presente nel data base ILL (servizi, listini, ecc), identificato tramite la digitazione del codice anagrafico.
Immissione richiesta ILL
La richiesta di un servizio ILL richiede l’individuazione delle entità POS e DSC coinvolte nel servizio.
Individua POS:
La comunicazione della biblioteca POS è obbligatoria per le richieste di prestito, facoltativa per le richieste di riproduzione, non gestita per le richieste di localizzazione o preventivo.
Se la richiesta viene registrata da un operatore della biblioteca, il codice anagrafico viene identificato automaticamente dal sistema tramite la funzionalità di ‘login’.
Se invece la richiesta viene registrata direttamente dall’utente finale, il codice POS deve essere comunicato con una delle seguenti modalità:
Ø digitato dall’utente; in questo caso ne viene verificata l’esistenza nella base dati ILL, senza coinvolgere il sistema Anagrafe; Ø ricercato dall’utente finale che non ne è a conoscenza; con l’attivazione diretta del sistema Anagrafe, (tramite un apposito oggetto grafico (bottone o icona): viene attivata la URL del sistema Anagrafe). L’utente finale ricerca la biblioteca con gli strumenti disponibili nel sistema Anagrafe (parte iniziale del nome, parole del nome o altro), e seleziona la biblioteca cercata. Il sistema Anagrafe restituisce al sistema ILL il codice anagrafico e l’intestazione della biblioteca. Se non viene selezionata alcuna entità,
Akros Informatica s.r.l. 50 Revisione 4 del 31 marzo 2000 PPrrreeessstttiiitttooo IIILLLL PPeeerrr SSBBNN –– SSppeeeccciiifffiiiccchheee FFuunnzziiiooonnaallliii
l’immissione della richiesta è annullata.
Se la biblioteca POS non è ancora registrata nel sistema ILL, viene avvisato l’utente finale, e inviato automaticamente un apposito messaggio via e-mail al ‘Utente Gestore ILL’, che provvederà a contattare la biblioteca per chiedere la conferma sulla volontà di adesione al sistema ILL, e eventualmente la comunicazione delle informazioni specifiche per il sistema ILL (servizi, listini, ecc.).
Individua DSC:
La richiesta di servizio ILL (ad esclusione della richiesta di localizzazione), prevede l’individuazione di una o più biblioteche DSC di riferimento.
Se i dati della richiesta vengono recuperati da un sistema OPAC che contiene i ‘codici anagrafici’ delle biblioteche, il sistema ILL controlla semplicemente l’esistenza di un Soggetto corrispondente nel proprio data base (ricerca per codice), e effettua le opportune registrazioni.
Se invece l’ OPAC non dispone dei codici del sistema Anagrafe (lista codici vuota), viene avvisato l’utente finale della necessità di identificare le biblioteche DSC tramite la ricerca nel sistema ‘Anagrafe’; la funzionalità è analoga a quanto descritto per la ricerca della biblioteca POS.
La stessa modalità di ricerca viene proposta all’utente che immette la richiesta senza recuperare i dati da un sistema OPAC.
Se la biblioteca selezionata come DSC non è ancora registrata nel sistema ILL, viene avvisato l’utente finale, e inviato automaticamente un apposito messaggio via e-mail al ‘Utente Gestore ILL’, che provvederà a contattare la biblioteca per chiedere la conferma sulla volontà di adesione al sistema ILL, e eventualmente la comunicazione delle informazioni specifiche per il sistema ILL (servizi, listini, ecc.).
Akros Informatica s.r.l. 51 Revisione 4 del 31 marzo 2000 PPrrreeessstttiiitttooo IIILLLL PPeeerrr SSBBNN –– SSppeeeccciiifffiiiccchheee FFuunnzziiiooonnaallliii
4 STANDARD PER INTERFACCIA UTENTE
L’interfaccia utente del sistema ILL viene costruita per essere compatibile con gli attuali browser web più diffusi (vedi paragrafo ‘1.3 Ambiente Target’).
Nella costruzione degli oggetti grafici, si tiene conto delle seguenti considerazioni:
1. risoluzione video di riferimento: 800x600 su schermo a 15” (diagonale); 2. utilizzo limitato al minimo indispensabile di Java Script, per conseguire la massima compatibilità; 3. uso assente, o ridotto al minimo di frame sulle videate; eventualmente si farà uso del frame laterale per la gestione di bottoni di ‘link’ con altri sistemi; 4. utilizzo di HTML v3.2.
L’utilizzo di HTML v3.2. è limitante rispetto alle possibilità grafiche di un browser, ma garantisce la compatibilità con tutti i browser di riferimento.
In generale, la videata di interfaccia viene progettata con i seguenti elementi:
1. intestazione: parte superiore della videata che contiene informazioni statiche riguardanti il sistema e la funzionalità attiva; 2. modulo: parte centrale della videata che contiene gli oggetti specifici della funzionalità attiva; 3. piè di pagina: parte inferiore della videata, che può contenere informazioni varie di utilità, e bottoni di attivazione.
Gli elementi presenti nel modulo della videata possono essere:
ü caselle di testo; ü caselle di controllo; ü pulsanti di azioni; ü menu a discesa; ü pulsanti di comando; ü immagini; ü etichette.
Una più precisa definizione degli elementi grafici e dei relativi standard di realizzazione (dimensioni, colori, posizionamento) viene prodotta nella fase di realizzazione del progetto, e in particolare al termine della iterazione n.2 della fase di Sviluppo e Test (vedi documento: Piano per la realizzazione di un sistema di Prestito Interbibliotecario per il Servizio Bibliotecario Nazionale, Akros Informatica s.r.l. – revisione 0 del 23.11.1998), quando è previsto il rilascio del prototipo v0.1, che consentirà al Comitato Tecnico del Progetto di valutare la funzionalità dello standard di interfaccia proposto, ed eventualmente indicare le variazioni opportune.
Akros Informatica s.r.l. 52 Revisione 4 del 31 marzo 2000 PPrrreeessstttiiitttooo IIILLLL PPeeerrr SSBBNN –– SSppeeeccciiifffiiiccchheee FFuunnzziiiooonnaallliii
5 MODALITA’ DI REALIZZAZIONE
Il presente progetto comprende la realizzazione del sottoinsieme di funzionalità, elencato di seguito.
Gestione delle richieste
& Definizione richiesta & Cancellazione richiesta & Arrivo materiale richiesto & Restituzione documento & Visualizzazione richieste per stato & Elaborazione richieste in arrivo & Analisi richieste ILL & Richiesta condizionale al richiedente & Localizzazione DSC & Sospensione della richiesta & Stima del costo & Spedizione materiale richiesto & Rientro del materiale prestato & Visualizzazione richieste per dominio & Visualizzazione richieste per stato.
Gestione amministrativa
& Registrazione biblioteca & Gestione password utenti & Gestione repertorio prodotti/servizi & Gestione listino prezzi gruppo.
La realizzazione di questo nucleo di funzionalità viene intesa come una prima fase di produzione del software, a cui possono seguire ulteriori sessioni di realizzazione, nell’ambito di nuovi progetti, a completamento di quanto descritto nelle specifiche funzionali.
In questa ottica viene posta particolare attenzione alla definizione degli standard di realizzazione dell’applicativo e dell’interfaccia utente, e alla loro documentazione tecnica.
Akros Informatica s.r.l. 53 Revisione 4 del 31 marzo 2000 PPrrreeessstttiiitttooo IIILLLL PPeeerrr SSBBNN –– SSppeeeccciiifffiiiccchheee FFuunnzziiiooonnaallliii
AAPPPPEENNDDIICCEE AA::: EELLEENNCCOO RRIIFFEERRIIMMEENNTTII Elenco documenti di Akros:
1) Prestito ILL per SBN - Offerta per la realizzazione di un sistema di Prestito Interbibliotecario per il Servizio Bibliotecario Nazionale, Akros Informatica s.r.l. - Prot. No. 4623 del 28 settembre 1998.
2) Prestito ILL per SBN – Piano per la realizzazione di un sistema di Prestito Interbibliotecario per il Servizio Bibliotecario Nazionale, Akros Informatica s.r.l. – revisione 0 del 23.11.1998 Elenco di documenti ICCU - specifiche:
1) Lettera prot. 3295/AMI del 7.9.1998 da parte di ICCU, Dott.ssa G. M. Merola.
2) Allegato 1: SCHEMA ARCHITETTURALE (versione, data ed autore non presente).
3) Allegato 2: DISEGNO DEL SISTEMA AIDA, Studio Staff s.r.l. (altri riferimenti non presente).
4) Allegato 3: FUNCTIONAL SPECIFICATIONS OF SOFTWARE APPLICATIONS, Studio Staff s.r.l. - Version: Final - LIB-AIDA/3-2036-D.5.4.2 del 10.10.1994.
5) Allegato 4: Studio Architetturale Per La Realizzazione di un Servizio di Prestito Interbibliotecario (versione, data ed autore non presente).
6) Allegato 5: LISTA COMPLETA DELLE FUNZIONI DA REALIZZARE (versione, data ed autore non presente).
Documentazione AIDA
1) AIDA - User Manual, Studio Staff s.r.l. del 19 dic 1995 - LIB-AIDA/3-2036-D.14.WP7
Standards Biblioteconomiche
1) ISO 10160:1997 - Interlibrary Loan Application Service Definition, Ed.2, pp.58
2) ISO 10161:1997 - Interlibrary Loan Application Protocol Specification - Part 1: Protocol Specification, Ed.2, pp.109
3) ISO 10161:1997 - Interlibrary Loan Application Protocol Specification - Part 2: Protocol Implementation Conformance Statement (PICS) Proforma, Ed.1, pp.38 Standards Tecnologici:
1) Unified Modelling Language v1.1
(a) UML Summary v1.1, Rational Software Corporation et al. – 1 settembre 1997. (b) UML Notation Guide v1.1, Rational Software Corporation et al. – 1 settembre 1997. (c) UML Semantics v1.1, Rational Software Corporation et al. – 1 settembre 1997. (d) Object Constraint Language Specification v1.1, IBM Corporation e Rational Software Corporation et al. – 1 settembre 1997.
Akros Informatica s.r.l. 54 Revisione 4 del 31 marzo 2000 PPrrreeessstttiiitttooo IIILLLL PPeeerrr SSBBNN –– SSppeeeccciiifffiiiccchheee FFuunnzziiiooonnaallliii
2) Java – Documenti base che rappresentano lo “standard” Java e per la generazione di “portable code”.
(a) Java Development Kit v1.1.7 – Core API Specification ed implementazione di riferimento, Sun Microsystems Inc. – 1998. (b) Java Language Specification v1.0 – J. Gosling, B. Joy e G. Steele (Sun Microsystems Inc.) – agosto 1996. (Comprende aggiornamenti per Java v1.1 del 1997) - ISBN 0-201-63451-1. (c) Java Virtual Machine Specification – Tim Lindholm e Frank Yelling (Sun Microsystems Inc.) – 1996 - ISBN 0-201-63452-X. (d) Java Servlet Development Kit v2.0 – API Specification e implementazione di riferimento, Sun Microsystems Inc. – 1 aprile 1998. (e) 100% Pure JavaÔ Cookbook for Developers – Roger Hayes Ph.D (Sun Microsystems Inc.) – Rev. 05.06.98 (1998).
3) CORBA – Documenti dello standard del OMG.
(a) CORBA Architecture & Specification v2.2 – Object Management Group, Inc. - febbraio 1998. (b) CORBA Services Specification – Object Management Group, Inc. – novembre 1997 (c) Common Facilities Architecture, Rev. 4 – Object Management Group, Inc. – novembre 1995. (d) CORBA Telecommunications Domain Specifications v1.0 – Object Management Group, Inc. – giugno 1998.
4) AIPA – Documenti di riferimento
(a) Linee Guida per la Realizzazione di Studi di Fattibilità. (b) Firma Elettronica – Teconologie e Standard.
Akros Informatica s.r.l. 55 Revisione 4 del 31 marzo 2000 PPrrreeessstttiiitttooo IIILLLL PPeeerrr SSBBNN –– SSppeeeccciiifffiiiccchheee FFuunnzziiiooonnaallliii
AAPPPPEENNDDIICCEE BB::: TTAABBEELLLLAA DDEELLLLEE AAZZIIOONNII EE DDEEGGLLII SSTTAATTII DDII UUNNAA RRIICCHHIIEESSTTAA
Alias Codice Descr. Azione Descr. Stato di arrivo 0 F100 Definizione ILL da utente ILL in attesa di validazione da POS 1 F111 Definizione ILL da POS, validazione ILL ILL definita, in attesa instradamento di utente 2 F118 Emissione ILL ILL in attesa elaborazione da DSC 4 F1211 Richiesta condizionale ILL in processo 11 F1212 Comunicazione ILL non soddisfacibile ILL terminata 11 F1213 Definizione lista possibili DSC ILL in processo 4 F1214 Accettazione ILL ILL in processo 4 F1215 Sospensione ILL request ILL in processo 11 F1216 Stima costo servizio ILL terminata 11 F1217 Chiusura ILL ILL terminata 11 F1218 ILL senza risposta ILL terminata 7 F114 Arrivo materiale Consegna presso POS 10 F116 Restituzione materiale Rispedizione verso DSC 6 F127 Spedizione ILL item Materiale spedito verso POS 11 F128 Ricezione materiale Rientro materiale in DSC – ILL terminata 2 F112A Cancellazione ILL ILL terminata 5 F112B Cancellazione ILL ILL in processo 11 F113A Risposta condizionale ILL terminata 5 F113B Risposta condizionale ILL in processo 5 F126 Attivazione ILL sospese ILL in processo 8 F115 Richiesta rinnovo prestito Materiale presso POS 9 F129 Conferma rinnovo Materiale presso POS 8 F12D Sollecito restituzione Materiale presso POS 9 F12A Negazione rinnovo Materiale presso POS 0 ILLDE ILL in attesa di processamento ILL in processo
Akros Informatica s.r.l. 56 Revisione 4 del 31 marzo 2000 PPrrreeessstttiiitttooo IIILLLL PPeeerrr SSBBNN –– SSppeeeccciiifffiiiccchheee FFuunnzziiiooonnaallliii
AAPPPPEENNDDIICCEE CC::: DDIIAAGGRRAAMMMMII DDII SSTTAATTOO DDEELLLLEE RRIICCHHIIEESSTTEE
1) Richiesta di localizzazione
utente inserisce richiesta
ILL in attesa elaborazione
DSC prende in carico
ILL in processo
DSC scrive risposta
ILL terminata
Akros Informatica s.r.l. 57 Revisione 4 del 31 marzo 2000 PPrrreeessstttiiitttooo IIILLLL PPeeerrr SSBBNN –– SSppeeeccciiifffiiiccchheee FFuunnzziiiooonnaallliii
2) Richiesta di preventivo
utente definisce richiesta ILL definita, in attesa instradamento
utente definisce richiesta e DSC
DSC prende in carico
ILL in attesa elaborazione da DSC
DSC non soddisfa la richiesta
DSC accetta richiesta
ILL in processo
DSC scrive risposta
ILL terminata
Akros Informatica s.r.l. 58 Revisione 4 del 31 marzo 2000 PPrrreeessstttiiitttooo IIILLLL PPeeerrr SSBBNN –– SSppeeeccciiifffiiiccchheee FFuunnzziiiooonnaallliii
3) Richiesta di riproduzione
utente definisce richiesta e DSC
ILL in attesa elaborazione da DSC
DSC accetta richiesta
ILL in processo (con azione F1214) DSC pone condizione utente accetta condizione
documento non disponibile ILL in processo (con azione F1211)
utente annulla richiesta DSC decide richiesta non soddisfacibile ILL in processo (con azione F1215)
DSC invia riproduzione utente annulla richiesta
DSC invia riproduzione ILL terminata
materiale spedito
Akros Informatica s.r.l. 59 Revisione 4 del 31 marzo 2000 PPrrreeessstttiiitttooo IIILLLL PPeeerrr SSBBNN –– SSppeeeccciiifffiiiccchheee FFuunnzziiiooonnaallliii
4) Richiesta di prestito
utente definisce richiesta ILL in attesa validazione da POS
POS definisce richiesta
POS valida richiesta senza DSC
POS definisce richiesta e DSC ILL in attesa instradamento
POS valida richiesta con DSC
presa in carico da DSC
Ill in attesa elaborazione da DSC DSC rifiuta richiesta Ill terminata (con azione F1212)
DSC pone condizione doc. non disponibile
ILL in processo ( con azione F1211 ) DSC accetta ric. ILL in processo (con azione F1215)
POS annulla la richesta POS accetta condizione
ILL terminata ( con azione F113A) ILL in processo (con azione F1214)
DSC spedisce documento DSC spedisce documento
Materiale presso POS (con azione F114) POS riceve doc. Materiale spedito verso POS
DSC sollecita POS chiede rinnovo Materiale presso POS (con azione F115)
DCS rinnova Materiale presso POS (con azione POS riconsegna DSC rifiuta rinnovo Materiale presso POS (con azione F129)
POS riconsegna
Material presso POS (con azione F12A) Rispedizione verso DSC
DSC riceve documento
Rientro materiale in DSC
Akros Informatica s.r.l. 60 Revisione 4 del 31 marzo 2000 PPrrreeessstttiiitttooo IIILLLL PPeeerrr SSBBNN –– SSppeeeccciiifffiiiccchheee FFuunnzziiiooonnaallliii
AAPPPPEENNDDIICCEE DD::: CCLLAASSSS DDIIAAGGRRAAMM
Sistema ILL: Three-Tiered Service Model
ICCU.ILL.richieste
ICCU.ILL.servlet
ICCU.ILL.contabilità
ICCU.ILL.html ICCU.ILL.sql
ICCU.ILL.soggetti
ICCU.ILL.gestione_sistema
Akros Informatica s.r.l. 61 Revisione 4 del 31 marzo 2000 PPrrreeessstttiiitttooo IIILLLL PPeeerrr SSBBNN –– SSppeeeccciiifffiiiccchheee FFuunnzziiiooonnaallliii
Sistema ILL: Class diagram ICCU.ILL.richieste
servizio (from ICCU.ILL.gestione_sistema) repertorio_stati (from ICCU.ILL.gestione_sistema) lista_ser() 1 listastati()
1..* 1
prodotto (from ICCU.ILL.gestione_sistema) 0..* crea_pro() cancella_pro() note lista_pro() ill_status soggetto creanote() 0..1 nuovostato() 1 (from ICCU.ILL.soggetti) 0..* listanote() esaminastato() varianote() crea_sog() 0..* 1..* varia_sog() <
cambiapriorità() setinstradamento() creailldsc() 0..* 1 0..* trans_com 0..* cancellailldsc() (from ICCU.ILL.contabilità) listailldsc() ill_request 1 crea_tc() lista_tc() creaill() 1 modificaill() duplicaill() 0..* +ha POS 1 listaill() descrizione_bibliografica 1 cancellaill()
insertdaopac() insertdavideo()
1 end_user
creaute() cancellaute() variaute() duplicaute()
ill_localizzazione ill_prestito ill_preventivo ill_riproduzione
Akros Informatica s.r.l. 62 Revisione 4 del 31 marzo 2000 PPrrreeessstttiiitttooo IIILLLL PPeeerrr SSBBNN –– SSppeeeccciiifffiiiccchheee FFuunnzziiiooonnaallliii
Sistema ILL: Class diagram gruppo_gen ICCU.ILL.soggetti (from ICCU.ILL.gestione_sistema)
ass_iva crea_gg() (from ICCU.ILL.gestione_sistema) varia_gg() lista_gg() crea_asi() 1 varia_asi() lista_asi() cond_com_pos
1 +raggruppa crea_ccp() varia_ccp() +assoggetta lista_ccp() 1..* 1 aggr_sog 1..* +raggruppa entita_legale crea_as() (from ICCU.ILL.gestione_sistema) varia_as() lista_as() crea_eleg() varia_eleg() 0..* 0..* lista_eleg() 0..* aggr_amm 0..1 +raggruppa POS crea_aa() 0..* varia_aa() 1..* lista_aa() 1 Polo 0..* (from ICCU.ILL.gestione_sistema) 1..* soggetto 1..*
crea_polo() 1 crea_sog() varia_polo() varia_sog() 1 +DSC applica lista_polo() lista_sog() cond.com a POS 1..* 1..*
1 1..* Centro_servizi operatore (from ICCU.ILL.gestione_sistema) (from ICCU.ILL.gestione_sistema) disabil (from ICCU.ILL.gestione_sistema) crea_cs() crea_oper() varia_cs() cancella_oper() creadisabil() 1 0..* lista_cs() varia_oper() cancelladisabil() lista_oper() listadisabil() cambiapsw_oper() 0..*
1 funzione (from ICCU.ILL.gestione_sistema)
listafun()
Akros Informatica s.r.l. 63 Revisione 4 del 31 marzo 2000 PPrrreeessstttiiitttooo IIILLLL PPeeerrr SSBBNN –– SSppeeeccciiifffiiiccchheee FFuunnzziiiooonnaallliii
Sistema ILL: Class diagram ICCU.ILL.contabilità
listino_prezzi_gruppo listino_prezzi_soggetto Centro_servizi (from ICCU.ILL.gestione_sistema) crea_lpg() crea_lps() varia_lpg() varia_lps() crea_cs() cancella_lpg() cancella_lps() varia_cs() lista_lpg() lista_lps() lista_cs()
1..* listino_prezzi_base prezzi_gruppo 1..* crea_pb() prezzi_soggetto cancella_pb() crea_pg() cancella_pg() serv_acc lista_pb() crea_ps() (from ICCU.ILL.gestione_sistema) lista_pg() cancella_ps() lista_ps() crea_sa() varia_sa() cancella_sa() prezzi_base <
ali_iva prodotto 0..* serv_trans (from ICCU.ILL.gestione_sistema) (from ICCU.ILL.gestione_sistema) <
0..*
entita_legale conto (from ICCU.ILL.gestione_sistema) 0..1 0..* crea_conto() crea_eleg() chiudi_conto() varia_eleg() visualizza_conto() lista_eleg() 0..* 0..1
1 0..1 1..* 1. cambio soggetto movimento_contabile (from ICCU.ILL.soggetti) trans_com (from ICCU.ILL.gestione_sistema) 1 crea_mc() crea_tc() 0..* crea_cb() crea_sog() varia_mc() 1. 1 lista_tc() varia_cb() varia_sog() lista_mc() lista_sog() lista_cb() 1..*
1 valuta (from ICCU.ILL.gestione_sistema)
crea_val() cancella_val() lista_val() Akros Informatica s.r.l. 64 Revisione 4 del 31 marzo 2000 PPrrreeessstttiiitttooo IIILLLL PPeeerrr SSBBNN –– SSppeeeccciiifffiiiccchheee FFuunnzziiiooonnaallliii Sistema ILL: Class diagram ICCU.ILL.gestione_sistema
disabil gruppo_gen funzione creadisabil() crea_gg() ass_iva listafun() 1 0..* cancelladisabil() varia_gg() listadisabil() lista_gg() crea_asi() varia_asi() 0..* lista_asi() prog_ill
1 nuovoid()
1 1..* repertorio_stati operatore entita_legale listastati() crea_oper() crea_eleg() cancella_oper() varia_eleg() varia_oper() lista_eleg() lista_oper() 0..* cambiapsw_oper()
1 fornitura Polo
crea_for() crea_polo() varia_for() varia_polo() cancella_for() lista_polo() lista_for()
1..* 1
1..* prodotto servizio 1 1..* 1 crea_pro() Centro_servizi lista_ser() cancella_pro() lista_pro() crea_cs() varia_cs() lista_cs() 0. 1..* serv_acc ali_iva
crea_sa() crea_ali() varia_sa() 0..* 1 varia_ali() cancella_sa() lista_ali() lista_sa()
1 valuta cambio
crea_val() crea_cb() cancella_val() 1 1. varia_cb() lista_val() lista_cb()
Akros Informatica s.r.l. 65 Revisione 4 del 31 marzo 2000 PPrrreeessstttiiitttooo IIILLLL PPeeerrr SSBBNN –– SSppeeeccciiifffiiiccchheee FFuunnzziiiooonnaallliii
AKROS INFORMATICA S.R.L.
PRESTITO ILL PER SBN
Specifiche Funzionali per la realizzazione di un sistema di Prestito Interbibliotecario per il Servizio Bibliotecario Nazionale.
Allegato A. documento ILLitem.dtd
Akros Informatica s.r.l. 66 Revisione 4 del 31 marzo 2000 PPrrreeessstttiiitttooo IIILLLL PPeeerrr SSBBNN –– SSppeeeccciiifffiiiccchheee FFuunnzziiiooonnaallliii
Il documento è accedibile alla url: http://prestito.iccu.sbn.it/ILLXml/ILLitem.dtd
Akros Informatica s.r.l. 68 Revisione 4 del 31 marzo 2000 PPrrreeessstttiiitttooo IIILLLL PPeeerrr SSBBNN –– SSppeeeccciiifffiiiccchheee FFuunnzziiiooonnaallliii
Akros Informatica s.r.l. 70 Revisione 4 del 31 marzo 2000 PPrrreeessstttiiitttooo IIILLLL PPeeerrr SSBBNN –– SSppeeeccciiifffiiiccchheee FFuunnzziiiooonnaallliii
OPAC-ILL-esempio.xml
Akros Informatica s.r.l. 71 Revisione 4 del 31 marzo 2000 PPrrreeessstttiiitttooo IIILLLL PPeeerrr SSBBNN –– SSppeeeccciiifffiiiccchheee FFuunnzziiiooonnaallliii
AKROS INFORMATICA S.R.L.
PRESTITO ILL PER SBN
Specifiche Funzionali per la realizzazione di un sistema di Prestito Interbibliotecario per il Servizio Bibliotecario Nazionale.
Allegato B. documento ILL-APDU.dtd
Akros Informatica s.r.l. 72 Revisione 4 del 31 marzo 2000 PPrrreeessstttiiitttooo IIILLLL PPeeerrr SSBBNN –– SSppeeeccciiifffiiiccchheee FFuunnzziiiooonnaallliii
Il documento è accedibile alla url: http://prestito.iccu.sbn.it/ILLXml/ILL-APDU.dtd
Akros Informatica s.r.l. 76 Revisione 4 del 31 marzo 2000 PPrrreeessstttiiitttooo IIILLLL PPeeerrr SSBBNN –– SSppeeeccciiifffiiiccchheee FFuunnzziiiooonnaallliii
Akros Informatica s.r.l. 81 Revisione 4 del 31 marzo 2000 PPrrreeessstttiiitttooo IIILLLL PPeeerrr SSBBNN –– SSppeeeccciiifffiiiccchheee FFuunnzziiiooonnaallliii
Akros Informatica s.r.l. 82 Revisione 4 del 31 marzo 2000 PPrrreeessstttiiitttooo IIILLLL PPeeerrr SSBBNN –– SSppeeeccciiifffiiiccchheee FFuunnzziiiooonnaallliii
Requester-Id, Responder-Id, Requester-note?)>
Akros Informatica s.r.l. 83 Revisione 4 del 31 marzo 2000 PPrrreeessstttiiitttooo IIILLLL PPeeerrr SSBBNN –– SSppeeeccciiifffiiiccchheee FFuunnzziiiooonnaallliii
(Transaction-Id, Service-date-time, Requester-Id, Responder-Id, Date-returned, Requester-note?)>
Akros Informatica s.r.l. 86 Revisione 4 del 31 marzo 2000 PPrrreeessstttiiitttooo IIILLLL PPeeerrr SSBBNN –– SSppeeeccciiifffiiiccchheee FFuunnzziiiooonnaallliii
Akros Informatica s.r.l. 87 Revisione 4 del 31 marzo 2000 PPrrreeessstttiiitttooo IIILLLL PPeeerrr SSBBNN –– SSppeeeccciiifffiiiccchheee FFuunnzziiiooonnaallliii
Akros Informatica s.r.l. 88 Revisione 4 del 31 marzo 2000