| | 5 | === Note preliminari sul documento === |
| | 6 | Questo documento intende essere punto di riferimento in fase di sviluppo e germe |
| | 7 | della documentazione che accompagnera` il progetto. |
| | 8 | |
| | 9 | Questo documento e` presente in duplice copia: fra i sorgenti in modo da essere |
| | 10 | facilmente editabile e leggibile in fase di sviluppo, e sul wiki |
| | 11 | [src:/branches/var2/doc/Appunti] e nel wiki [wiki:Variante2] per aumentarne la |
| | 12 | facilita` di utilizzo. Dal momento che i commenti sul wiki possono essere |
| | 13 | lasciati anche da chi non segue direttamente lo sviluppo, l'utilizzo del file |
| | 14 | presente nei sorgenti e` da ritenersi una copia della pagina wiki; pertanto |
| | 15 | chi effettua modifiche al primo si dovra` preoccupare di sincronizzarlo |
| | 16 | tempestivamente con il secondo. |
| | 17 | |
| | 18 | In caso di divergenze di opinioni su una sezione e` preferibile il commento |
| | 19 | pittosto della brutale modifica, in modo da tenere traccia delle considerazioni |
| | 20 | fatte. Convenzioni utili per i commenti: |
| | 21 | * posporli alla sezione a cui fanno riferimento; |
| | 22 | * usare il carattere ''corsivo'' per indivduarli facilmente; |
| | 23 | * premettere il nome dell'autore accompagnato dalla data. |
| | 24 | |
| | 25 | |
| | 26 | === Specifiche === |
| | 27 | |
| | 28 | Si assuma che il numero e la struttura dei costrutti del |
| | 29 | linguaggio MiniScheme sia dato e non soggetto a |
| | 30 | cambiamenti: |
| | 31 | * Si fornisca l’implementazione di tutti i costrutti originali |
| | 32 | |
| | 33 | Si assuma che il numero delle operazioni polimorfe sia |
| | 34 | destinato ad evolvere rapidamente |
| | 35 | * Si fornisca un interprete e una prettyPrint modulari |
| | 36 | |
| | 37 | Il modello deve supportare la definizione modulare di |
| | 38 | operazioni. |
| | 39 | * Si vuole supportare la definizione di operazioni modulari sia |
| | 40 | sotto forma di visitors che di iteratori |
| | 41 | * Il modello deve fornire API di manipolazione specifiche e |
| | 42 | generiche |
| | 43 | * L’aggiunta di una operazione non deve richiedere nessun |
| | 44 | cambiamento al modello |
| | 45 | |
| | 46 | Le scelte di design devono essere imposte al cliente. |
| | 47 | * Si vuole imporre al cliente l’uso dei pattern stabiliti (in |
| | 48 | particolare quelli creazionali) |
| | 49 | * Il codice e i pattern non conformi a questa specifica non |
| | 50 | devono fare parte del sistema fornito |
| | 51 | [[BR]]''SoujaK 200608181501 [[BR]] |
| | 52 | Quali pattern creazionali? E` necessario il redesign di questa sezione, oppure |
| | 53 | la vecchia Factory adempie gia` a questo compito? Volendo si potrebbe pensare a |
| | 54 | soluzioni alternative, ma reputo la cosa a bassa priorita`. |
| | 55 | |
| | 56 | === Scelte progettuali === |
| | 57 | |
| | 58 | |
| 6 | | * I nostri due visitor (!PrettyPrintVisitor e !InterpreterVisitor) conoscono direttamente la natura dell'albero di espressioni su cui lavorano. Al cliente e' chiaramente lasciata la possibilita' di usare un iterator. |
| 7 | | * Le Expression$NAME vanno arricchite con API di manipolazione specifica (i.e. `getter` e `setter`) per permettere all'iteratore di accedere in maniera indiretta ai campi di istanza. |
| | 62 | * I nostri due visitor (!PrettyPrintVisitor e !InterpreterVisitor) conoscono |
| | 63 | direttamente la natura dell'albero di espressioni su cui lavorano. Al cliente |
| | 64 | e' chiaramente lasciata la possibilita' di usare un iterator. |
| | 65 | * Le Expression$NAME vanno arricchite con API di manipolazione specifica (i.e. |
| | 66 | `getter` e `setter`) per permettere all'iteratore di accedere in maniera |
| | 67 | indiretta ai campi di istanza. |
| 9 | | * (200607251758 - gnappo) [[BR]]Le API di manipolazione generiche sono dei getter e setter che agiscono sull'intero modello. Per approfondire seguite il [http://www.cs.unibo.it/~solmi/teaching/labss_2005-2006/EserciziProgetto2.pdf link]. Se non bastasse vi rimando all'[http://www.cs.unibo.it/~solmi/teaching/labss_2005-2006/esercizi/labss_il_model_iterators.zip esempio] del prof. Solmi: prestate attenzione alle classi !LanguageEntity e alle varie Abstract* (sono particolarmente chiarificatrici). |
| | 69 | * gnappo 200607251758 [[BR]] |
| | 70 | Le API di manipolazione generiche sono dei getter e setter che agiscono |
| | 71 | sull'intero modello. Per approfondire seguite il |
| | 72 | [http://www.cs.unibo.it/~solmi/teaching/labss_2005-2006/EserciziProgetto2.pdf |
| | 73 | link]. Se non bastasse vi rimando all'[http://www.cs.unibo.it/~solmi/teaching/labss_2005-2006/esercizi/labss_il_model_iterators.zip esempio] |
| | 74 | del prof. Solmi: prestate attenzione alle classi !LanguageEntity e alle varie |
| | 75 | Abstract* (sono particolarmente chiarificatrici). |
