(:title Ingegneria del Software - Appunti del 21 Aprile 2009:)
Torna alla pagina di Ingegneria del Software
:: Ingegneria del Software - Appunti del 21 Aprile 2009 ::
OOA e OOP
LA OOA è la fase di progettazione che arriva fino al tracciamento dei diagrammi delle classi, di sequenza ed eventualmente quelli di stati/transizioni. Siamo ancora in fase di analisi, e il nostro lavoro è language independent.
Dal momento in cui dobbiamo andare a specificare gli attributi di relazione, invece, entriamo nella fase di OOP, e questa fase è purtroppo language dependent. Vedremo in lezioni future come implementare gli attributi di relazioni con diversi linguaggi.
I diagrammi che vedremo in questa lezione sono anch'essi language-dependent, o meglio, dipendono dall'architettura software che abbiamo deciso di utilizzare.
Diagramma dei componenti
L'idea di questo diagramma è quella di passare da una visione monolitica, in cui l'unica suddivisione è quella tra le classi, ma tutte le classi sono infilate nello stesso eseguibile, ad un software diviso in componenti comunicanti.
Il vantaggio di dividere il software in componenti è che si può installare su una macchina solamente i componenti necessari, ed è possibile riutilizzare gli stessi componenti per programmi diversi.
Gli svantaggi invece risiedono nel fatto che il componente installato su di una macchina potrebbe non essere esattamente quello di cui ho bisogno, vanificando quindi l'utilità di cui sopra. Inoltre, se un componente condiviso apre una falla di sicurezza, questa verrebbe automaticamente estesa anche al mio software, e spesso non c'è modo di verificare l'affidabilità di componenti realizzati da terzi.
Interfaccia di un componente
L'interfaccia di una classe sappiamo tutti che cos'è: è l'insieme dei metodi che la classe rende pubblici.
L'interfaccia di un componente sarà quindi l'insieme delle funzioni che il componente esporrà, e queste insieme deve essere un sottinsieme di tutte le interfacce delle classi contenute nel componente.
Se vediamo un componente come un contenitore di classe, è lecito aspettarci che tutte i metodi pubblici di queste classi siano visibili anche all'esterno del componente. In realtà ciò non è desiderabile: se ho riunito queste classi in un unico componente, è perché voglio che il componente esponga una sua interfaccia, e poi sia lui a giostrarsi con le classi che contiene in modo a me trasparente.
Dobbiamo quindi introdurre il grado di coesione di un componente: è il numero di metodi pubblici delle classi interne che sono visibili all'esterno del componente. Quanto più questo numero è basso, tanto più il mio componente è coeso.
Quando si raggruppano classi in componenti, pertanto, si persegue l'obiettivo di avere una grande coesione, cioè far sì che sia visibile il numero più basso possibile di metodi pubblici delle classi.
Il motivo è che, in teoria, le classi vengono raggruppate in un componente secondo un principio di collaborazione: le classi che collaborano le metto in un componente, e io dall'esterno faccio "partire" la loro complessa collaborazione con la semplice chiamata di un metodo. Se alla fine salta fuori che il mio componente è poco coeso, allora scoprirei che in realtà le classi che ci ho infilato denro non stanno affatto collaborando.
Criteri di raggruppamento
Come faccio a distinguere le mie classi in componenti?
Posso utilizzare gli stereotipi. Se riesco a dare a tutte le mie classi un'etichetta di uno stereotipo, allora potrebbe essere sensato infilare tutte le classi con lo stesso stereotipo in un componente separato.
Oppure, come dicevamo sopra, posso utilizzare un criterio basato sulla coesione: me ne infischio dello stereotipo e delle funzionalità della classe, e metto nello stesso componente le classi che collaborano spesso. Ovviamente il grado di coesione non potrà mai essere al 100%, ma ci si può avvicinare.
Pertanto, per ogni componente dobbiamo essere in grado di dire:
- che classi contiene
- la metrica di coesione
- la sua interfaccia pubblica
Il come saranno realizzati sti componenti dipende poi dall'architettura che abbiamo scelto (dll, EJB, etc.).
Diagramma della messa in opera (deployment)
Torna alla pagina di Ingegneria del Software