Ingegneria del software: 21 marzo 2005

Modello dei dati
Come definire le classi per risolvere un certo problema.
Non é un procedimento completamente standardizzato, ma creativo.
Possiamo dividere in 3 tipi di classi:
Entity: definiscono il dominio applicativo (corrispondono ai dati che dobbiamo gestire)
Control: Definiscono il comportamento del nostro processo: la logica applicativa.
Boundary: Classi che gestiscono l'interfaccia con l'utente

Lo sviluppo dovrebbe partire dagli Entity Method per scegliere la disposizione in classi:
Estrazione dei nomi
Consiste nel cercare nelle specifiche (in linguaggio naturale) tutti i nomi, poi si sfoltisce
Si consiglia di usare l'inglese
A volte ci sono delle ridondanze che potrebbero essere generalizzazioni
Nomi generici: vanno chiariti meglio (tipo oggetto)
Nomi di eventi e operazioni facilmente non dovrebbero essere classi
Metalinguaggio (system, rules): ovviamente non va considerato come classe
Esterno al sistema: Nomi di oggetti che non interessano il programma (ad esempio giorno)
Attributi: Diventeranno attributi delle classi, non classi
Segue interessante esempio di analisi e studio di una gerarchia di classi (10:00 - 32:00 circa)
Si possono mettere dei constraint sulle relazioni UML: ad esempio: XOR, ecc.

Approccio per tipi di classi comuni
Si pensa ai tipi di oggetti:

1. Concetti
2. Cose reali
3. Ruoli (oggetti esterni che interagiscono con il sistema, anche un'altro sistema lo é (ma anche una persona può coprire un ruolo)) e Persone (interessano per esempio per un'autenticazione)
4. Eventi
5. Organizzazioni
6. Posti

Collaboration Responsibility Card (CRC)
Inventate per XP
Scrivo un foglietto per ogni classe
Si fa in presenza del cliente, quindi usare un linguaggio domain-oriented
E' più utile per verificare le classi che per pianificarle

Design Patterns
Rende più facile riconoscere situazioni comuni
I Pattern sono indicazioni per la risoluzione di problemi comuni
Esiste un wiki interessantissimo sui pattern: http://c2.com/cgi/wiki?CodeSmells
Anti-Pattern
E’ la denuncia di soluzioni sbagliate in base alla propria esperienza.
I Pattern sono una derivazione dell’architettura, il GOF (Gang Of Four) ha introdotto i pattern architetturali per l’informatica.
Composizione di un pattern:

• Nome (chiaro)
• Contesto (quando e perché si presenta il problema che vorremmo risolvere)
• Forze (perché il problema è difficile, scopi, vincoli e fattori motivanti)
• Soluzione (di solito in diagrammi simil-UML)
• Esempi (uno o più esempi di come si è affrontato il problema)
• Contesto risultante (illustra i benefici del risultato proposto)
• Razionale: motivazioni della bontà della soluzione
• Pattern in relazione: ovvero pattern che posso incastrare comunemente con questo
• Usi conosciuti: Altri contesti d’uso oltre agli esempi

Meta pattern
Aiuta a categorizzare i pattern
Identifica due elementi base:

1. Hook Method: punti dove si può incastrare un altro pattern. Punto in cui il pattern lascia carta bianca e si può iniettare qualcos’altro.
2. Template Method: Metodo che coordina generalmente più Hook Method. Parte intoccabile del pattern, scheletro del pattern.

Unification: Dove template e hook sono nella stessa classe
Separation: Un metodo in una classe e uno in un’altra
Connection e recursive connection: Contenuti in classi separate, ma tra loro associate (anche ricorsivamente)
Nel libro del GOF hanno individuato 23 pattern, suddivisi in:

• Creazionali: riguardanti la creazione di oggetti (es.: Singleton)Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Proxy
• Comportamentali: come devono interagire le classiChain of responsibility, Command, Interpreter, Iterator, Mediator, Memento, Observer, State, Strategy, Template Method, Visitor
• Strutturali: composizione di classi ed oggettiAbstract Factory, Builder, Factory Method, Prototype, Singleton

Pattern Singleton
Implementare il concetto di oggetto separatamente da quello di classe (una sola istanza di una classe).
In pratica si crea un costruttore privato e si mettere un metodo condiviso (Static(1)) che ritorna quell’unica istanza
Osservazioni:
Perché non fare una classe statica? Una classe statica o con tutti i membri statici non può essere ereditata. Inoltre potrei cambiare in futuro il numero di istanze disponibili.

(1) I metodi statici sono “metodi di classe”: ovvero appartengono alla classe e non all’istanza: Sono richiamabili senza nessuna istanza e non possono contenere riferimenti a campi o metodi d’istanza. Metodi e membri statici sono condivisi a tutte le istanze (sono, appunto, legati alla classe)