Changes between Version 5 and Version 6 of Variante2


Ignore:
Timestamp:
Aug 18, 2006, 3:19:43 PM (18 years ago)
Author:
soujak
Comment:

Ristrutturazione, copia delle specifiche e un commento

Legend:

Unmodified
Added
Removed
Modified

  • Variante2

    v5 v6  
    11= Variante 2 =
     2
    23== Operazioni estendibili ==
    34
     5=== Note preliminari sul documento ===
     6Questo documento intende essere punto di riferimento in fase di sviluppo e germe
     7della documentazione che accompagnera` il progetto.
     8
     9Questo documento e` presente in duplice copia: fra i sorgenti in modo da essere
     10facilmente editabile e leggibile in fase di sviluppo, e sul wiki
     11[src:/branches/var2/doc/Appunti] e nel wiki [wiki:Variante2] per aumentarne la
     12facilita` di utilizzo. Dal momento che i commenti sul wiki possono essere
     13lasciati anche da chi non segue direttamente lo sviluppo, l'utilizzo del file
     14presente nei sorgenti e` da ritenersi una copia della pagina wiki; pertanto
     15chi effettua modifiche al primo si dovra` preoccupare di sincronizzarlo
     16tempestivamente con il secondo.
     17
     18In caso di divergenze di opinioni su una sezione e` preferibile il commento
     19pittosto della brutale modifica, in modo da tenere traccia delle considerazioni
     20fatte. 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
     28Si assuma che il numero e la struttura dei costrutti del
     29linguaggio MiniScheme sia dato e non soggetto a
     30cambiamenti:
     31 * Si fornisca l’implementazione di tutti i costrutti originali
     32
     33Si assuma che il numero delle operazioni polimorfe sia
     34destinato ad evolvere rapidamente
     35 * Si fornisca un interprete e una prettyPrint modulari
     36
     37Il modello deve supportare la definizione modulare di
     38operazioni.
     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
     46Le 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]]
     52Quali pattern creazionali? E` necessario il redesign di questa sezione, oppure
     53la vecchia Factory adempie gia` a questo compito? Volendo si potrebbe pensare a
     54soluzioni alternative, ma reputo la cosa a bassa priorita`.
     55
     56=== Scelte progettuali ===
     57
     58
    459=== Appunti vari ===
     60
    561 * Gli iterator sono da intendersi come esterni.
    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.
    868 * Branch: diventeranno figlie delle Expression ?
    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).
    1076
    1177