Oggi non sono ancora disponibili dei meccanismi generali per sviluppare applicazioni ac- cessibili, nello specifico esiste una classe di cosiddette Assistive Technologies [31] le quali permettono di riorganizzare e presentare all’utente il contenuto semantico delle interfacce grafiche, in modo che possa essere interpretato attraverso meccanismi non completamen- te grafici (es. screen reader, schermi tattili, ecc..). Le tecnologie assistive non sono, per`o, regolate da uno standard, diventa quindi complicato sviluppare applicazioni che siano compatibili con pi`u sistemi operativi e librerie di accessibilit`a, ma Qt implementa un proprio strato di astrazione che permette di scrivere codice portabile anche per quanto riguarda le assistive technologies.
La presenza di uno studente non vedente ha fortemente incentivato l’impiego di ta- li strumenti durante lo sviluppo dell’interfaccia grafica di µARM, la quale sfrutta le capacit`a di Qt per essere pi`u accessibile in ogni sua parte.
3.3.1
Annotazioni
La maniera concettualmente pi`u corretta di rendere accessibile un’applicazione grafica `
e quella di aggiungere il supporto per le tecnologie assistive senza modificare l’aspetto estetico. Nello specifico, sviluppando applicazioni Qt, questo significa inserire descrizioni
testuali ulteriori per ogni componente sensibile dell’interfaccia. I due campi di testo in questione si chiamano Accessible Name ed Accessible Description e rappresentano, ap- punto, un nome esplicativo del componente grafico ed una sua descrizione pi`u dettagliata per chiarificarne il significato e l’utilizzo.
Sar`a poi lo strumento assistivo a riorganizzare l’accesso all’intera interfaccia in modo da fornirne una visione semantica. In questo modo, i contenuti saranno ordinati in una maniera pi`u simile alla struttura gerarchica con cui sono definiti nel codice sorgente, permettendo di “saltare” pi`u semplicemente da una zona logica della schermata all’altra.
3.3.2
Modalit`a Accessibilit`a Aumentata
Purtroppo non `e sufficiente aggiungere le annotazioni di accessibilit`a per rendere anche usabile tutta l’interfaccia tramite tecnologie assistive. Il problema principale `e dato dalla visualizzazione dello stato del processore (cfr. sec. 3.2.1), i cui contenuti risultano particolarmente confusionari quando acceduti attraverso tecnologie assistive.
Per risolvere questo problema, la soluzione pi`u adeguata `e risultata essere l’aggiunta di una modalit`a di rendering della parte principale dell’interfaccia, denominata Increased Accessibility (accessibilit`a aumentata). I registri delle varie modalit`a di esecuzione sono raggruppati in svariate aree di testo, una per modalit`a di esecuzione. Le aree di testo risultano essere una delle tipologie di widget pi`u semplici da navigare con strumenti assistivi.
La revisione accessibile ha avuto un buon riscontro da parte dello studente non veden- te, che ha offerto un valido supporto per migliorare l’usabilit`a generale dell’interfaccia.
Capitolo 4
Progetto
Il presente lavoro propone, oltre allo strumento descritto nei Capitoli 2 e 3, una serie di esercizi da assegnare ad una classe di studenti di un Corso di Laurea in Informatica. L’insieme dei compiti prende il nome di Progetto JaeOS, acronimo di “Just Another Edu- cational Operating System”, ed appartiene alla famiglia di progetti prodotti nell’ambito di Virtual Square [3, 5].
Il progetto didattico nasce per essere svolto in piccoli gruppi ed `e diviso in tre fa- si principali, ognuna con obbiettivi specifici, corredate da una documentazione che ne dichiara i requisiti ed alcuni file sorgente per verificare il corretto funzionamento del codice prodotto. In base al livello dell’insegnamento, il progetto pu`o essere assegnato in maniera sequenziale durante lo svolgimento dell’anno accademico, oppure `e possibile somministrare una versione ridotta del progetto in modo da bilanciare il carico di lavoro. Tale versione ridotta pu`o essere composta dalle prime due fasi, da sviluppare per intero, oppure dal pi`u complesso compito di realizzare la terza fase a partire dalle precedenti due gi`a implementate. I documenti di specifiche del progetto sono allegati in versione integrale in appendice a questo documento.
Le tre fasi descritte nei documenti di specifica rappresentano tre livelli di un sistema operativo, derivato dal THE Multiprogramming System [32], composto da una serie di strati che hanno rispettivamente accesso alle funzioni offerte dallo strato inferiore e le utilizzano per fornire servizi a quello superiore. In questo schema a livelli, il livello 0 `e rappresentato dall’hardware emulato, che espone le proprie funzionalit`a al livello 1, ovve- ro il BIOS di sistema, cui segue il livello 2 (la fase 1 del progetto) che realizza il gestore delle code di strutture utilizzate dal livello superiore (livello 3 - fase 2 ), quest’ultimo sar`a il core del sistema operativo vero e proprio, a cui segue il livello di supporto (livello 4 - fase 3, l’ultima descritta dai documenti di specifiche) che offre funzionalit`a necessa- rie perch´e generici processi a livello utente possano essere eseguiti. Oltre questi cinque livelli, `e possibile creare altri strati di supporto e realizzare funzionalit`a pi`u complesse, quali, ad esempio, file system, stack di rete, una shell interattiva, etc.
4.1
JaeOS Phase 1
La prima fase `e un compito abbastanza semplice ed ha come scopo quello di far prendere confidenza agli studenti con l’ambiente di lavoro (i.e. µARM) e con il linguaggio di programmazione da utilizzare, nel caso questo non sia ancora stato trattato nel corso di altri insegnamenti1.
I requisiti di questo primo esercizio si limitano alla realizzazione di due piccole librerie per la gestione di strutture dati, utilizzate nella fase successiva. Viene richiesto di gestire liste circolari ed alberi di Process Control Blocks (cfr. sec. 4.2.1) ed una lista globale di Semaphore Descriptors (cfr. sec. 4.2.2), oltre all’allocazione di questi due tipi di strutture dati.
I tipi di dato appena dichiarati non hanno nessun significato particolare a questo punto dell’esercizio, sono semplici strutture di cui bisogna tenere traccia e non hanno nessun collegamento con l’architettura sottostante; difatti questa fase potrebbe essere sviluppata e testata interamente sulla macchina fisica dello studente, si richiede, per`o, di utilizzare l’emulatore µARM per poter illustrare le funzionalit`a di debug e permettere agli studenti di prendere confidenza con l’ambiente di esecuzione/testing, fondamentale per le fasi successive.
Conseguentemente alla consegna, i lavori prodotti vengono corretti in modo da fornire feedback agli studenti sui propri elaborati e poter quindi affrontare in maniera pi`u conscia la fase successiva.