\articolo{Progetto di gestione di uno studio legale con Amiga}{Paolo Baliani}
\index{Baliani!articolo di}

\noindent Questi brevi note vogliono descrivere un progetto, tuttora allo
stato embrionale, di gestione studio legale con \A.

Non ci si aspetti però di vedere in commercio nel prossimo futuro tale
programma (magari chiamato, facendo uno sforzo di fantasia
{\it AmiStudioLegale} o {\it Studio Legale Amiga}).
Questo in primo luogo perché non esiste, allo stato attuale, (anche se
tutti speriamo che le cose possano cambiare in futuro) un mercato \A che
possa giustificare un tale sforzo; secondariamente, ed è questa forse la
ragione principale, perché io non sono un programmatore. Non mi sognerei
mai di distribuire codice ARexx scritto da me ad altri. Sarebbe troppo
pericoloso! Questo articolo quindi non ha alcuna pretesa tecnica ma vuole
soltanto descrivere l'iter e le difficoltà incontrate in questo progetto.
La mia esperienza però presenta forse dei lati interessanti proprio per
questo. La flessibilità e la versatilità di un computer e del suo sistema
operativo è data, secondo me, dagli strumenti di manipolazione che questo
offre ai propri utenti quotidiani. Sotto questo aspetto \A, nonostante
la prolungata assenza di punti di riferimento forti, può avere ancora molto
da dire.

Quando, dopo alcuni anni di pratica legale, mi sono deciso ad iniziare
un'attività autonoma, da buon maniaco informatico mi sono subito posto il
problema di quali strumenti adottare. L'esperienza acquisita in ufficio con
Word e con l'MS-DOS, ma anche, e rimanga tra noi, il buon senso, avrebbero
consigliato l'acquisto di un ``bel'' PC compatibile (Intel inside
naturalmente) con Windows 95 ed ammennicoli vari. L'antipatia ed un vago
senso di mal di mare che tale prospettiva mi ispirava, mi ha spinto a
valutare la soluzione che attualmente sto sviluppando: valutare cioè se il
mio vecchio Amiga 3000 potesse essere utilizzato produttivamente in un
ufficio dalle caratteristiche peculiari come quelle di uno studio legale.

Molto sinteticamente, e senza pretesa di completezza, le esigenze primarie
e oramai irrinunciabili in termini informatici di uno studio legale
riguardano in primo luogo il word-processing e secondariamente la
consultazione di CD-ROM contenenti archivi legislativi (l'ultimo CD della
UTET ad es.~contiene tutte le leggi dal 1861 in poi), massime
giurisprudenziali e formulari. Mentre per il primo aspetto non sussistono
problemi (chi l'ha detto che per scrivere occorre necessariamente
utilizzare Word?) i vari CD-ROM sono invece dotati di programmi di
consultazione che girano rigorosamente sotto MS-DOS o Windows. La necessità
di utilizzare tale programmi mi ha spinto ad acquistare una Golden Gate 486
SLC che del resto mi permette di avera portata di mano la compatibilità con
il mondo IBM tutelandomi anche da esigenze impreviste.

Al di là di queste che, come già detto, sono le esigenze primarie, esistono
tutta una serie di programmi, chiamati genericamente di ``gestione studio
legale'' che permettono, chi più chi meno, di gestire i dati delle varie
pratiche e di automatizzare alcune operazioni ripetitive come la gestione
dell'agenda, del repertorio, la redazione nota spese, la modulistica, etc.

Per esperienza personale, posso dire che questo genere di programmi non
riscuotono grosso successo o addirittura sono visti con un certo sospetto.
Questo in primo luogo per una sorta di innata diffidenza della classe
forense nei confronti di tutto ciò che è informatico e, secondariamente,
perché spesso troppo macchinosi o di limitata utilità rispetto alle
specifiche esigenze di un determinato professionista. Queste critiche, a
ben vedere, non sono del tutto prive di fondamento e non solo per quanto
ricordato. Esistono infatti alcuni aspetti, fondamentali secondo me, del
lavoro quotidiano svolto da un procuratore legale o avvocato che sia, che
questi non considerano se non marginalmente. Mi riferisco in particolare a
tutto quel lavoro di studio, ricerca ed aggiornamento, che si concreta in
pareri, atti o che viene semplicemente accantonata in forma cartacea. Molto
di questo lavoro è destinato inevitabilmente ad essere parzialmente
vanificato, sommerso dalle mille incombenze quotidiane dai limiti
inevitabili della memoria. Ed è proprio questa esigenza che mi ha fatto
nascere l'idea di realizzare un programma che permetta di archiviare in
forma digitale e successivamente ricercare agevolmente il lavoro svolto
quotidianamente.

È di tutta evidenza che tale programma acquista una valenza particolare se
inserito in un ambiente che gestisca la redazione di tali documenti e,
ancora più a monte, la archiviazione della pratica e delle parti.

Mi rendo conto da solo che tale progetto è sicuramente molto ambizioso e
probabilmente irrealizzabile nella sua interezza.  La parte fin qui
realizzata mi consente di poter tirare le prime somme.

\paragrafo{Il programma}
Come già detto, e tengo a ripeterlo, io non sono un programmatore. Conosco
però abbastanza bene il Sbase4 Pro che in passato ho usato più volte.

Non mi soffermerò chiaramente a descrivere le funzioni e le caratteristiche
del Sbase che tutti conoscono essendo un programma storico (in tutti i
sensi) del panorama software \A. Basterà qui ricordare la completezza delle
funzioni, la possibilità di creare form, il linguaggio di programmazione
interno e l'interfaccia ARexx che lo rendono indubbiamente il candidato
ideale per progetti anche complessi.

Il programma però non è immune da critiche. Personalmente, ad esempio, non
amo proprio i form che trovo poco flessibili e graficamente poco
accattivanti. Inoltre questi, per essere utilizzati pienamente, si
appoggiano al linguaggio di programmazione interno del Sbase. Pur non
avendo nulla contro di questo (che in pratica è un Basic) devo confessare
di trovarmi più a mio agio con l'ARexx, con il quale si può accedere a
tutti i comandi del DML. Tramite ARexx è infatti molto semplice accedere ai
vari record, selezionarli, ricercarli, scrivere e leggere i vari campi che
lo compongono e più in generale assumere il controllo dall'esterno del
database.

Riporto, come esempio, una delle prime prove effettuate che consisteva nel
leggere un database contente l'elenco di tutti i comuni italiani con il
relativo C.A.P.~la provincia e il prefisso telefonico, e nella
contemporanea creazione di un file contenente in forma tabellare i vari
campi.

\begin{smallcodestyle}
/* Legge un archivio Sbase contente l'elenco  */
/* dei comuni italiani e crea un file in RAM: */
/* contente l'elenco dei Campi                */

call open(out,"ram:elenco",W)

address 'SBase4'
'open file "Work:DataBase/sb_4/Comuni/comuni"'

'select last'
call leggifld(comune)
last=fld

'select first'
do forever
	call leggifld("comune")
	fld_com=fld
	call leggifld("provincia")
	fld_prov=fld
	call leggifld("Prefisso")
	fld_pref=fld
	call leggifld("cap")
	fld_cap=fld
	line=left(fld_com,25)||left(fld_prov,4)
             ||left(fld_pref,8)||left(fld_cap,8)
	call writeln(out,line)
	if fld_com=last then leave
	'select next'
	'view'
end

call close(out)

exit

leggifld:
 options results
 x=arg(1)
 address 'SBase4' x
 fld=result
return

exit
\end{smallcodestyle}

A prescindere dalla qualità del codice, l'esempio mostra come la scelta
dell'ARexx, pur presentando qualche limitazione e macchinosità, possa
rivelarsi naturale ed indolore.

Altro problema, tipico però questo di chi programma in ARexx, è quello
dell'interfaccia grafica. L'ARexx infatti non offre di per se stesso gli
strumenti per creare interfacce grafiche per i propri script. Per sopperire
a questa mancanza, sono state approntate nel tempo varie soluzioni. Fra le
più conosciute basterà qui ricordare la \spath{RexxArpLib.library} che
permette di accedere alle funzioni contenute nella \spath{ARP.library} e
molto altro; la \spath{Rxgen.library} e la \spath{Apig.library}, che
permettono di accedere a tutte le librerie \A; la \spath{Rx\_intui.library}
che mette a disposizione molte funzioni per la creazione di interfacce
grafiche. Queste soluzioni, tutte molto datate, presentano il difetto di
richiedere una conoscenza approfondita del sistema operativo ed una
dimestichezza con l'uso di librerie \A (soprattutto la
\spath{rxgen.library}) che in genere chi programma solo in ARexx non ha. La
soluzione più abbordabile fra queste è l'ottima \spath{RexxArpLib.library},
che però presenta de limiti che la rendono per alcuni tipi di applicazioni
difficilmente usabile.

Più recentemente sono apparse altre soluzioni più intuitive e versatili che
facilitano non poco l'utente meno esperto.

Solo per citarne alcuni e senza pretesa di completezza, basterà ricordare
la \spath{TritonRexx.library}, che, appoggiandosi alla
\spath{Triton.library}, mette a disposizione molti comandi per creare
complete interfacce grafiche. Il difetto maggiore è la documentazione,
esclusivamente in tedesco e quindi, almeno per me, inaccessibile. Nel
pacchetto sono però riportati molti esempi interessanti.

Senza ombra di dubbio però, la soluzione più semplice per chi voglia
mettere insieme quattro gadget è costituita da VARexx\index{VARexx} (giunto
nel momento in cui scrivo alla versione 1.7). VARexx utilizza i file
\spath{.gui} creati da GadToolsbox e tramite pochi semplici comandi ne
permette un controllo pressochè completo. In pratica non occorre scrivere
linee e linee di codice per definire bottoni liste e gadget eccetera. Basta
disegnarli usando la GadToolsbox e salvare il tutto in un file che poi
verrà caricato e visualizzato all'interno dello script ARexx. Tramite una
porta ARexx messa a disposizione da VARexx verranno intercettati i messaggi
corrispondenti alla pressione e alla selezione dei vari gadget.

Riporto per chiarezza lo script di esempio contenuto nella documentazione del
programma.

\begin{smallcodestyle}
/* Test script for VARexx */
  guifile = 'myguifile.gui'

  options results

  /* Open libs needed */
  if ~show("L","rexxsupport.library") then
    if ~addlib("rexxsupport.library",
               0, -30) then exit

  /* Check VARexx is loaded if not load it */

  if show( 'p', 'VARexx' ) ~= 1 then do
    address command 'run VARexx'
    waitforport VARexx
    RanVARexx = TRUE
  end; else
    RanVARexx = FALSE

  address VARexx

  /* Open the port for gui to talk to */
  call openport("WINDOWPORT")

  /* Load the gui file into VARexx */
  'load ' guifile 'WINDOWPORT'

  /* Set host to the port for this gui file */
  host = result
  address value host

  /* Display the window */
  show

  /* Wait for the user to close the window */
  do forever
    /* Wait for a message from VARexx */
    call waitpkt( "WINDOWPORT" )

    /* Get the message */
    packet = getpkt( "WINDOWPORT" )

    /* This is not a null message */
    if packet ~= '00000000'x then do

      /* Get the information about the message */
      class  = getarg(packet)

      /* If the message says the user clicked on
       * the closewindow gadget then leave */
      if class = closewindow then leave

    end
  end

  /* Hide the window and unload the gui file
     from memory */
  'hide unload'

  /* Close the port */
  call closeport( "WINDOWPORT" )

  /* I launched vARexx so close it */
  if RanVARexx = TRUE then ADDRESS COMMAND VXC

  exit
\end{smallcodestyle}

Niente di più facile. In pratica si tratta poi di definire un ciclo {\it
select when/otherwise} per individuare il gadget selezionato e stabilire
l'azione corrispondente.

Questa è la soluzione che ho adottato e devo dire che almeno fino ad adesso
posso ritenermi soddisfatto. Il limite più grande è la mancanza di menù a
tendina che costringe a sovraffollare di bottoni la finestra principale.
Interpellato sul punto Andrew Cook (l'autore di VARexx) mi ha risposto
dicendo che a breve si sarebbe occupato della cosa. Vedremo.

Non si può concludere questa premessa sui sistemi per la costruzione di
interfacce grafiche senza fare un accenno all'ultimo arrivato,
MUIRexx\index{MUIRexx} (giunto nel momento in cui scrivo alla versione
2.1b). Questo piccolo programma, secondo la definizione stessa dell'autore,
serve come interfaccia tra ARexx e MagicUserInterface, consentendo un ampio
accesso (non completo ma consistente) alle funzioni di quest'ultima. A
dispetto di quanto potrebbero pensare i più, l'accoppiata tra l'ARexx
(linguaggio ``lento'' per definizione) e la MUI (ritenuta da molti, a torto
o a ragione un pachiderma) è tutt'altro che soporifero ed offre un
ventaglio di possibilità amplissimo. Il suo utilizzo pratico poi, pur non
essendo immediato come quello di VARexx, è basato sulla descrizione logica
dell'interfaccia (come la MUI del resto) e risulta molto potente ed
intuitivo. Sicuramente merita uno sguardo, anche perché attualmente è
l'unico programma fra quelli citati che continua ad essere aggiornato con
una certa regolarità dall'autore. Se fosse uscito prima probabilmente lo
avrei adottato; non è però detto che in futuro non prenda in considerazione
la cosa.

\paragrafo{Le funzioni}

Premetto subito che delle tre funzioni principali di cui parlavo in
premessa (a cui corrispondono i moduli ``inserimento e ricerca dati
pratica'', ``redazione e memorizzazione atti e documenti in generale'' e
``gestione archivio documenti e ricerche'') soltanto il primo, che però è
sicuramente il più complesso e delicato in quanto da questo deriva il
corretto funzionamento del sistema, è pressoché completo e sufficientemente
testato.

Gli altri due sono ancora in fase di sviluppo e (sicuramente) suscettibili
di modifiche ed ampliamenti.

Sono poi previsti altri moduli come ad esempio l'agenda, la gestione
udienze, la contabilità, la gestione adempimenti, etc., che però allo stato
attuale sono soltanto una ipotesi di lavoro.

Solo per concretizzare questa lunga chiacchierata, passerò ora ad una breve
descrizione di quanto realizzato e pensato senza soffermarmi sui dettagli e
sulle funzionalità più ovvie.

\begin{enumerate}
\item {\bf Inserimento dati pratica}. Lunghe meditazioni sono state
effettuate sulla disposizione dell'interfaccia grafica realizzata, secondo
le intenzioni almeno, in modo che l'inserimento e la visualizzazione dei
dati risulti la più lineare e razionale possibile (figura 1).

\begin{center}
\includegraphics[width=7cm]{baliani/pics/figura1.eps}\\
Figura 1.
\end{center}

Particolare cura è stata riservata all'inserimento dei nomi e dei dati
relativi alle parti. Il programma gestisce un numero indeterminato di parti
e controparti (mentre ad esempio i programmi per IBM - compatibili in
genere si limitano ad indicare la prima parte e controparte). Non occorre
poi digitare nuovamente dati relativi a soggetti conosciuti. Se ad esempio
inserisco come nuova parte ``\c{*Bal*}'', nella finestra inserimento
dati personali (figura 2) apparirà una lista di soggetti il cui nome
contiene la stringa ``bal''. Basterà selezionare quello desiderato per
poter visualizzare e modificare i dati personali. Vengono inoltre
controllate le eventuali omonimie.

\begin{center}
\includegraphics[width=7cm]{baliani/pics/figura2.eps}\\
Figura 2.
\end{center}

La grande listview in basso assume contenuti diversi a seconda di quale
gadget sia selezionato sulla destra. Può riportare l'elenco dei documenti
appartenenti ad una determinata pratica o, in ipotesi, le udienze, i
movimenti contabili o gli adempimenti.

Le singole pratiche poi possono essere selezionate e ricercate usando lo
slider in basso o scrivendo il numero del relativo fascicolo oppure
selezionando il bottone cerca ed inserendo i dati relativi alla pratica che
interessa. In questo caso l'intera finestra diventa un form di ricerca e
verrà visualizzato un elenco delle pratiche corrispondenti ai dati inseriti
(es. tutte le pratiche aventi ad oggetto la voce ``Sfratto per finita
locazione'')

È possibile inoltre creare collegamenti tra i singoli fascicoli in modo da
poter sempre risalire alla pratica che logicamente la precede e dalla quale
deriva come nel caso, solo per fare un esempio, di un decreto ingiuntivo e
del conseguente giudizio di opposizione e dell'eventuale successivo
appello.

\item {\bf Redazione documenti}. Cliccando su \g{NUOVO}
quando è selezionato il gadget \g{Documenti}, appare un request
contenente una lista di modelli. Allo stato attuale i modelli sono
semplicemente schemi di lettere o atti contenenti parti variabili che
andranno automaticamente sostituite dai relativi dati della pratica (es. il
nome della parte, della controparte, etc.). Selezionandone uno, questo verrà
caricato in Wordworth adeguatamente compilato. Semplice, ma molto utile. In
seguito l'idea sarebbe di creare una sorta di modulistica ``intelligente''
dove ad esempio il programma possa scegliere automaticamente la variante
dello schema tipo a seconda dei dati inseriti (ad es. a seconda del valore
della pratica oppure se la parte sia una persona giuridica o meno). Fra le
priorità da sviluppare in un prossimo futuro vi è la acquisizione di
documenti tramite scanner. Sarebbe infatti molto utile, seguendo un modello
di gestione digitale della pratica, poter archiviare anche dati cartacei
provenienti dall'esterno come atti di controparte, sentenze o anche
articoli di giornale da poter conservare e richiamare in futuro.
Chiaramente l'operazione sarebbe gestita da un programma di Image
Processing (Art Department o più probabilmente ImageFX che dei due è
l'unico ancora supportato) comandato tramite ARexx. La cosa non dovrebbe
essere poi particolarmente complessa anche qui grazie soprattutto alla
flessibilità di \A.

\item {\bf Archivio ricerche}. Quando un documento viene salvato per la
prima volta, viene creato un record contenente il nome del documento, la
data di creazione ed il tipo (cioè il nome del modello dal quale è stato
creato). È però possibile in seguito associare delle keyword al documento
in modo in da poterlo ricercare in maniera più mirata. Questo avviene
cliccando il bottone \g{NUOVO} quando è selezionato il gadget
\g{Ricerche}. Appare quindi una lista di keyword (sempre aggiornabile ed
ampliabile) fra le quali scegliere. Ad ogni documento sono associabili fino
a 5 keyword (ma questo è un limite arbitrario). La ricerca, attivabile
selezionando il bottone \g{Archivio Ricerche}, può avvenire, secondo
quelli che sono gli schemi classici della ricerca su archivi digitali, sia
usando queste keyword (unite tramite gli operatori logici AND e OR) oppure,
e questa è una possibilità ancora da sperimentare, tramite full text, cioè
ricercando una stringa all'interno dei vari documenti. Per ottenere questo
tipo di ricerca occorrerebbe però appoggiarsi ad un programma (tipo il
search fornito di serie ma magari più flessibile) esterno, oppure,
possibilità questa di molto più difficile attuazione, attivare una
procedura che crei per ogni documento redatto un elenco delle parole
contenute da immettere poi in un unico indice analitico (procedura questa
con la quale ad es. la Corte di Cassazione archivia le proprie sentenze).
Comunque già la ricerca per keyword permette buoni risultati ed in ogni
caso è l'unica applicabile a documenti acquisiti tramite scanner.
\end{enumerate}

Tirando brevemente le somme, l'insieme di quanto realizzato fino ad ora,
pur con qualche ``ruvidità'' ed incongruenza da correggere, funziona e
almeno per adesso non posso certo ritenermi insoddisfatto della scelta
fatta.

Certo, molte altre cose ci sarebbero da dire e molte altre ancora da fare,
anche perché mano a mano che il progetto acquista forme più precise e
delineate sorgono nuove idee e necessità di modifica.

È però inutile soffermasi su funzioni e progetti che esistono solo nella
mia mente che forse non vedranno mai la luce (magari se ne riparlerà per
IPISA '97).

Quello che in ogni caso mi premeva testimoniare non era tanto il fatto che
\A potesse essere usata produttivamente al di fuori di quelli che sono i
campi classici di applicazione, fatto questo di cui nessuno dubita, ma il
fatto che c'è chi vuole ancora puntare su questa macchina e che non la
ritiene morta. Certo la scommessa è grossa. Speriamo di non perderla.

\autore{Paolo Baliani\\
e-mail: \c{mc8128@mclink.it}}{}

\citazione{\selectlanguage{english}Computer are useless. They can only give
you answers.}{Pablo Picasso}