Università degli Studi di Udine

Transcript

1 Università degli Studi di Udine Facoltà di Scienze Matematiche Fisiche e Naturali a.a. 2004/2005 Laboratorio di Progettazione ed Analisi di Software Orientato agli Oggetti Gianluca Demartini 70152

2 Indice 1 Introduzione Il sistema Electronic Journal Casi d uso Patterns generate architectures Il progetto di EJ Diagramma delle classi Diagrammi di sequenza Diagrammi degli oggetti Conclusioni Bibliografia

3 1 Introduzione In questa relazione verrà descritta l idea di un nuovo sistema di pubblicazione di articoli scientifici [1] ed in seguito verrà presentato, utilizzando le tecniche descritte in [2], un progetto orientato agli oggetti di una possibile implementazione del sistema descritto, utilizzando i Design patterns descritti in [3] e le indicazioni presenti in [4]. 2 Il sistema Electronic Journal Questo nuovo sistema si propone di sostituire il metodo attualmente utilizzato per la pubblicazione degli articoli scientifici noto con il nome di Peer review. In questo nuovo sistema, denominato Electronic Journal, ogni articolo è immediatamente pubblicato dopo il suo invio, senza un processo di revisione. Ogni articolo ha un certo punteggio (dato dalla sua accuratezza, comprensibilità, grado di innovazione, ecc.) che inizialmente vale zero e che viene dinamicamente aggiornato in base ai giudizi dei suoi lettori. Una persona che si iscrive al giornale è un lettore, uno scrittore o entrambe le cose, e possiede anch esso un proprio punteggio (se il sottoscrittore è sia un lettore che uno scrittore avrà due diversi punteggi). Ogni entità con un punteggio (autori, lettori, articoli) ha anche un valore che indica quanto è saldo ed affidabile il suo punteggio (ovvero quanto il suo punteggio è soggetto a cambiamenti repentini nel tempo). Per ulteriori informazioni, e per meglio comprendere quanto segue, si veda [1]. 2.1 Casi d uso Per meglio comprendere il funzionamento del sistema EJ, presentiamo un diagramma di caso d uso. 3

4 E possibile notare l attore generico User, che rappresenta un utente del sistema, che può effettuare le normali operazioni di log in e log off dal sistema. Un utente può essere di tipo Reader, il quale può giudicare un Paper attraverso l espressione di un voto, o di tipo Author che può pubblicare un Paper in modo che venga letto. 3 Patterns generate architectures In [2] viene descritto una metodologia per presentare un progetto orientato agli oggetti in modo tale da far capire a chi lo legge non soltanto il come deve funzionare il sistema progettato, ma anche il perché sono state intraprese certe scelte dai progettisti. A questo scopo viene richiesto ai progettisti di utilizzare una struttura per descrivere le motivazioni che hanno portato alla scelta di utilizzare un certo design pattern [3]. La struttura da utilizzare per descrivere la scelta di un pattern è la seguente: Pattern usato Precondizioni: Operazioni che è necessario svolgere prima di applicare il pattern, ad esempio l elenco dei pattern che bisogna utilizzare prima di questo. Serve per dare una sequenza corretta all applicazione dei pattern al progetto. Problema: Breve descrizione del problema a cui si vuole applicare il pattern. Serve per far capire al lettore se il pattern è applicabile in questa situazione. Vincoli: Descrizione dei conflitti presenti per decidere che azioni intraprendere per risolvere il problema. Soluzione: Spesso accompagnata da un diagramma che mostra la trasformazione di un sistema che non soddisfa il pattern in uno che lo soddisfa. Al termine della descrizione si otterrà così l intero progetto finale, ed il lettore avrà avuto modo di capire come il sistema deve funzionare ed il perché il sistema è stato progettato in quel modo. 4 Il progetto di EJ Mostriamo ora, riguardo al sistema Electronic Journal precedentemente descritto, come ottenere il diagramma delle classi utilizzando le indicazioni fornite in [2]. Mostriamo inoltre i diagrammi di sequenza ed i diagrammi degli oggetti. 4.1 Diagramma delle classi Le principali entità del sistema sono i lettori, gli autori (che possono essere anche lettori), gli articoli, ed i giudizi che i lettori danno agli articoli letti. Avremo quindi un diagramma iniziale di questo tipo. 4

5 In questo diagramma possiamo notare la classe System che rappresenta il sistema che si sta modellando. Contiene un attributo name che rappresenta il nome del singolo sistema. Contiene poi dei metodi utili alla creazione ed autenticazione degli utenti (di vari tipi) del sistema. La classe Person modella l entità utente del sistema e quindi contiene i suoi dati anagrafici ed i relativi metodi per modificare ed accedere a questi dati. Le sottoclassi di Person ereditano i suoi attributi ed i suoi metodi. Nelle varie classi, per leggibilità, non sono stati indicati tutti i metodi getters e setters, che possono essere facilmente ricavati in base ai nomi degli attributi delle classi. Le classi Reader ed Author modellano i due diversi tipi di utenti che il sistema può avere, quindi, oltre agli attributi di anagrafica comuni per tutti i tipi di utenti, queste classi avranno gli attributi relativi ai punteggi dell utente all interno del sistema e i metodi che corrispondono alle azioni che un lettore od un autore possono effettuare all interno del sistema (e quindi votare o pubblicare un articolo rispettivamente). L eredità è di tipo overlapped in quanto un sottoscrittore della rivista può essere sia un lettore che un autore, e quindi dovrà avere dei punteggi diversi per i due casi. E altresì presente la classe Paper che rappresenta gli articoli pubblicati e letti dagli utenti. Questa classe contiene solamente le informazioni relative all articolo (quindi titolo, testo, ) e quelle relative ai punteggi dati dai lettori ad un dato articolo. 5

6 Infine è presente la classe Judgment che rappresenta tutte le votazioni che vengono espresse durante la vita del sistema da parte dei lettori nei confronti degli articoli presenti. La classe Judgment non è essenziale per il funzionamento del sistema, ma è preferibile mantenere traccia di tutti i giudizi espressi nel tempo dai lettori. E comunque richiesto un certo grado di elasticità nel sistema in modo da permettere un eventuale facile modifica delle formule utilizzate per il calcolo dei punteggi delle varie entità. A questo scopo introduciamo il pattern Bridge. Pattern Bridge Precondizioni: Avere una rappresentazione astratta dei componenti del sistema. Si vuole separare l astrazione dalla sua implementazione concreta per far si che le due parti possano variare indipendentemente. Problema: Si desidera che le formule per il calcolo dei punteggi (score, steadiness, ) possano essere facilmente modificabili nel tempo. E necessario quindi che la parte del sistema che le implementa sia separata dalla parte che descrive le entità (lettori, autori, giudizi, ) astratte del sistema. Vincoli: - Soluzione: Costruiamo una classe astratta Implementation con più sottoclassi concrete che rappresentano le varie possibili implementazioni concrete delle formule utilizzate dal sistema per il calcolo dei punteggi delle entità. Leghiamo la classe Implementation con la classe System e aggiungiamo a System un attributo impl che farà da riferimento all implementazione utilizzata. Otteniamo quindi il seguente diagramma: 6

7 Abbiamo indicato con il colore blu le modifiche rispetto al precedente diagramma delle classi (nuove classi e nuovi metodi ed attributi in classi già presenti precedentemente). 7

8 A questo punto si presenta la necessità che la classe System abbia un unica istanza durante la vita del sistema. Pattern Singleton Precondizioni: La classe System deve essere collegata all implementazione delle formule per il calcolo dei punteggi. Problema: Non è desiderabile che la classe System abbia più istanze in quanto il progetto descrive un singolo sistema di giornale elettronico con i propri lettori, autori ed articoli e non una serie di sistemi diversi tra loro. Vincoli: Se si vogliono realizzare sistemi diversi con lettori, autori ed articoli in comune, è possibile aver bisogno di una classe System con diverse istanze concrete. Se invece si vuole descrivere un unico sistema di giornale elettronico con i propri lettori, autori ed articoli è necessario che la classe System abbia un unica istanza. Soluzione: La classe System avrà un attributo in più di nome instance e di tipo System, ed un metodo getinstance() che restituirà un oggetto di tipo System. 8

9 9

10 Infine si vuole che, ogni volta che un lettore legge e valuta un articolo, vengano aggiornati i punteggi dell articolo, dei suoi autori, del lettore e dei precedenti lettori di quell articolo. Pattern Observer Precondizioni: - Problema: Il sistema deve provvedere ad aggiornare i punteggi delle varie entità ogni qualvolta un lettore legge e valuta un articolo. Sarà quindi necessario modificare i valori degli attributi score, steadiness, ecc. nelle varie istanze degli oggetti Reader, Author e Paper. Vincoli: Se si inserisce il pattern Observer sarà necessario tenere traccia di tutti i lettori che nel tempo hanno letto un certo articolo (vista la presenza della classe Judgment è possibile sfruttare quella). Come vantaggio però, con il pattern Observer gli oggetti sono responsabili solamente del loro proprio stato interno, ed i cambiamenti di stato di un oggetto vengono riflessi su di un altro oggetto senza che questo sia fortemente legato al primo. Se non si utilizza il pattern Observer sarà necessario avere una procedura che esegue tutte le chiamate necessarie alla modifica dei punteggi delle varie entità. Soluzione: Vengono aggiunti alla classe Paper i metodi registerreader(), registerauthor(), removereader(), removeauthor(), notifyreader(), notifyauthor(), ed alle classi Reader ed Author un metodo update(). 10

11 11

12 Le classi Observer, ReaderSubject e AuthorSubject sono classi astratte che contengono i metodi del pattern Observer e quindid ne indicano l utilizzo all interno del progetto. I metodi registraauthor() e registrareader() provvederanno a mantenere traccia delle associazioni tra articoli e lettori e tra articoli ed autori mediante l utilizzo del database. In questo modo è anche facilmente gestibile il caso di un articolo con più di un autore, in quanto sarà possibile notificare un numero maggiore di uno di autori in caso di lettura di un loro articolo nello stesso modo in cui è possibile notificare un numero maggiore di uno di precedenti lettori di quell articolo. A questo punto aggiungiamo i colori alle classi del diagramma secondo le indicazioni di [4]: Le classi principali sono Reader, Author e Paper in quanto rappresentano gli attori del sistema, le entità più importanti. Per questo motivo il loro colore è il giallo. La classe System è di colore verde in quanto è una classe di infrastruttura che serve a contenere i metodi di autenticazione utenti e non ha un ruolo primario nel funzionamento del sistema. La classe Person è verde in quanto contiene solamente le informazioni comuni per tutti i tipi di utenti ed è quindi soltanto un anagrafica utenti e quindi una classe secondaria. Le classi Observer, ReaderSubject e AuthorSubject sono classi astratte, relative al pattern Observer, i cui metodi verranno implementati nelle relative sottoclassi, e, non avendo un ruolo attivo nel funzionamento del sistema, anche il loro colore è verde. La classe Judgment è di colore blu in quanto la sua presenza, non essenziale per il funzionamento del sistema, serve solamente a contenere tutti i giudizi espressi dai lettori e quindi è una classe di descrizione che contiene aggregati di dati semplici. La classe Implementation, invece, è di colore arancio in quanto è un punto di estensione del sistema. Da questa classe astratta è possibile definire delle sottoclassi che definiscono diversi funzionamenti del sistema attraverso la determinazione delle formule utilizzate da esso. Le sottoclassi di Implementation sono di colore verde in quanto contengono solamente la definizione dei metodi utilizzati dagli attori principali del sistema (gialli) e può quindi essere vista come una classe di infrastruttura. 12

13 13

14 4.2 Diagrammi di sequenza Descriviamo le situazioni di Pubblicazione di un articolo da parte di un autore e di Lettura e giudizio di un articolo da parte di un lettore. Pubblicazione di un articolo da parte di un autore In sequenza, un utente, attraverso l interfaccia grafica del sistema, farà si che venga chiamato il metodo submit() della classe Author, il quale provvederà a creare una nuova istanza della classe Paper. Dopo queste operazioni, l autore provvederà a registrarsi presso l istanza di Paper in modo da ricevere la notifica di quando i punteggi dell articolo cambieranno (Observer). 14

15 Lettura e giudizio di un articolo da parte di un lettore Dopo che il lettore r1 ha votato attraverso il metodo vota(), chiamato dall interfaccia grafica attraverso un comando dell utente, verrà generata una nuova istanza della classe Judgment in modo da poter tener traccia di tutti i voti espressi dai lettori nel tempo. A questo punto r1 provvederà a chiamare i metodi della classe Implementation (che polimorficamente chiamerà i metodi concreti di una delle sottoclassi) che servono a modificare i punteggi dell articolo p1 che il lettore r1 ha letto. Questi metodi modificheranno i valori dei punteggi di p1 ed in seguito chiameranno i metodi di notifica di p1, i quali provvederanno ad informare l autore ed i precedenti lettori di p1 che i loro punteggi sono cambiati. (Observer) Ora sia a1 (che è l autore di p1) che r2 (che è un precedente lettore di p1) provvederanno a chiamare i metodi dell implementazione che servono ad aggiornare i propri punteggi. Infine il lettore r1 chiamerà anch esso i metodi dell implementazione che servono ad aggiornare i propri punteggi e provvederà a registrarsi presso p1 in modo tale da essere notificato successivamente tutte le volte che un altro lettore leggerà l articolo. Può sembrare che gli attori del sistema (lettori, autori, articoli) chiamino direttamente i metodi della classe Implementation pur non avendo associazioni dirette con essa nel diagramma delle classi. La Legge di Demeter dice che, per un metodo m di un oggetto x, il destinatario dei messaggi deve essere x, un argomento di m, un oggetto riferito da un attributo di x, un oggetto creato da m oppure un oggetto riferito da una variabile globale. In questo caso, la legge è rispettata in quanto le informazioni riguardo l implementazione usata, e quindi i metodi concreti che vengono chiamati, sono presenti nella classe System che ha un unica istanza nel corso della vita del sistema. Questa istanza può essere vista come una variabile globale visibile in ogni momento in tutte le classi. Per questo motivo tutti gli attori del sistema (lettori, 15

16 autori, articoli) potranno chiamare facilmente i metodi dell implementazione attraverso l istanza di System. Ad esempio in questo modo: System.getIstance().impl.paper_score(0.2); Reader ed Author dovrebbero quindi essere associati alla classe System, ma questa associazione è stata lasciata alla classe Person che è padre di entrambe. 4.3 Diagrammi degli oggetti Mostriamo ora un esempio, con i vari passi successivi nel tempo, di un possibile funzionamento del sistema progettato, con dei diagrammi degli oggetti, che presentano delle concrete istanze degli oggetti utilizzati nel progetto, con i relativi valori degli attributi. Come prima cosa un autore a1 provvederà a pubblicare un certo articolo p1 attraverso il metodo submit() della classe Author. Indichiamo in rosso l azione svolta in questo istante di tempo. A questo punto supponiamo che un lettore r1 legga e giudichi p1 con un voto pari a 0.8 (in una scala da 0 a 1) utilizzando il metodo vote() della classe Reader. In verde indichiamo le istanze che subiscono una variazione dei valori degli attributi. In questo caso vengono modificati i valori di score e di steadiness di p1 e di a1 in base al giudizio espresso da r1. Successivamente verranno modificati, di conseguenza, i punteggi di r1. Essendo il 16

17 primo voto espresso riguardo a p1, lo score di r1 diverrà 1 in quanto si considera il suo giudizio senza errori. I voti del lettore r1 sono stati aggiornati in seguito al voto da lui espresso che, essendo il primo, si rivela corretto. Ora supponiamo che un altro lettore r2 legga e giudichi p1 con un voto pari a 0.2 (in una scala da 0 a 1) utilizzando il metodo vote() della classe Reader. Ora vengono modificati, analogamente a prima, i valori di score e di steadiness di p1 e di a1 in base al giudizio espresso da r2. Infine sarà necessario aggiornare i punteggi di r1 in qualità di lettore precedente dell articolo p1 e di r2 in qualità di lettore attuale dell articolo p1. 17

18 I punteggi di r1 e di r2 sono stati modificati secondo le formule. A questo punto ci fermiamo con l esempio elencando alcune possibili situazioni che si potrebbero verificare a questo punto. Potrebbe succedere che un terzo lettore r3 giudichi p1, oppure che a1 pubblichi un altro articolo che poi i vari lettori potrebbero giudicare. Oppure un nuovo autore potrebbe comparire e pubblicare dei nuovi articoli che r1 ed r2 potrebbero leggere e giudicare. 18

19 5 Conclusioni In questa relazione è stata dapprima descritta l idea di un nuovo sistema di pubblicazione di articoli scientifici, presentato in [1], in seguito è stato presentato, utilizzando le tecniche descritte in [2], un progetto orientato agli oggetti per una possibile implementazione del sistema utilizzando i Design patterns descritti in [3] e le indicazioni descritte in [4]. Il progetto è stato sviluppato ragionando in termini di software orientato agli oggetti generico, senza riferirsi ad un particolare linguaggio di programmazione. Ad esempio certi linguaggi potrebbero non permettere l eredità di tipo sovrapposto che è stata utilizzata tra la classe Person e le classi Reader e Author. Un successivo sviluppo di questo progetto dovrebbe essere l integrazione del sistema con un datatabase e le relazioni che intercorrono tra i due. Il database servirà a contenere le informazioni rilevanti per il sistema (riguardo a lettori, autori ed articoli), le informazioni riguardo a tutti i giudizi espressi nel corso della vita del sistema e tutti i legami articoli/autori e articoli/lettori al fine del corretto funzionamento del pattern Observer utilizzato nel progetto. Un ulteriore sviluppo di questo progetto potrebbe essere l utilizzo di agenti al fine di meglio comprendere il funzionamento del sistema e di scoprire che comportamenti vengono premiati e quali vengono penalizzati. 19

20 Bibliografia [1] S. Mizzaro. Quality Control in Scholarly Publishing: A New Proposal, Journal of the American Society for Information Science and Technology, 54(11): , [2] K. Beck e R. Johnson, Patterns generate architectures. ECOOP 94, LNCS 821, Conference Proceedings (pp ), Berlin, Heidelberg: Springer-Verlag. [3] E. Gamma, R. Helm, R. Johnson e J. Vlissides, Design Patterns Elements of reusable Objectoriented software Addison Wesley, [4] C. Pescio, UML: Manuale di stile, Eptacom,