Le specifiche UML sono indipendenti dal linguaggio di implementazione che sarà scelto in fase di codifica.
Per effettuare la corrispondenza dalle specifiche UML ad un linguaggio OO occorre pertanto colmare il gap, in termini di formalismi, esistente tra UML ed il linguaggio.
In relazione ai linguaggi C++ e Java il gap è colmato risolvendo:
In molti casi la risoluzione del gap è affidata al codificatore cosicchè il progettista del sistema non si preoccupa di inserire ulteriori indicazioni nei diagrammi di progettazione.
Qualora il progettista ritenga utile limitare le scelte del codificatore può utilizzare, oltre che specifiche testuali “attaccate” agli elementi di progetto, il formalismo delle stringhe di proprietà {property-string} messe a disposizione da UML.
Gli attributi in UML sono caratterizzati da: visibilità tipo_attributo nome_attributo, valore di default.
Regole per la traduzione
Gli attributi si mappano nelle variabili membro delle classi.
I metodi UML sono caratterizzate da:
Le regole di traduzione per la visibilità sono le stesse di quelle per gli attributi.
La lista dei parametri contiene le coppie Tipo-Nome per i parametri di scambio.
Per la traduzione in C++, valgono le seguenti “regole”:
Per la traduzione in Java valgono le seguenti “regole”:
Per tradurre i parametri formali occorre tener conto del ruolo semantico dei parametri.
In base ad essi si applicano le “regole” generali del C++:
Per tradurre i parametri formali occorre tener conto del ruolo semantico dei parametri.
In base ad essi si applicano le “regole” generali di Java:
Se si restituisce (eventualmente modificato) uno dei parametri di scambio, esso verrà restituito per riferimento
Qualora la funzione costruisca un nuovo oggetto è opportuno restituirlo per valore (solo C++)
Nelle gerarchie gen-spec, le classi derivate possono ridefinire i metodi definiti dalla classe base.
La ridefinizione dei metodi dipende da come sono specificati i metodi nella classe base:
La classe base può definire dei metodi cui non corrisponde alcun comportamento (metodi VP).
L’uso di metodi virtuali puri vincola le classi derivate a presentare un’interfaccia che sia al più una estesione di quella della classe base.
Una classe base che definisce metodi VP è detta classe astratta: da essa non sarà possibile istanziare direttamente oggetti non essendo definito il comportamento per i metodi VP.
Metodi virtuali {V}, definiti dalla classe base, permettono una redifinizione da parte delle classi derivate.
L’uso di tali metodi è reso necessario quando gli oggetti istanza delle derivate possono esibire un comportamento diverso rispetto gli oggetti della base.
Dal punto di vista concettuale si parla di polimorfismo: il comportamento degli oggetti in relazione al metodo considerato non è univoco (polimorfo) ma dipende dalla specializzazione dell’oggetto stesso.
Metodi non virtuali (NV) definiti dalla classe base sono metodi che, usualmente, non necessitano di redifinizione nelle classi derivate (solo C++).
In tale classe sono specificati:
L'inizializzazione è realizzata tramite costruttore di default.
L'implentazione del costruttore sarà del tipo C::C(int iI, char cI): c( cI ), i( iI ).
Le funzioni che non devono alterare l'oggetto proprio hanno il qualificatore const.
Le strutture generalizzazione specializzazione si traducono in C++ e in Java tramite il meccanismo linguistico dell’ereditarietà.
Gli attributi della classe Automobile sono, in questo esempio, di tipo “protected”.
In tal modo si permette la visibilità di tali attributi a tutti gli oggetti istanza delle classi derivate (in Java anche alle classi appartenenti allo stesso package).
I metodi non sono ridefiniti nelle classi derivate.
Il tipo di derivazione (public) è stato specificato tramite una {stringa di proprietà}.
L'ereditarietà è pubblica
class Fuoristrada : public Automobile
Metodi aggiuntivi
void Inserisci_Trazione_Integrale();
Attributo aggiuntivo
Kg Peso_massimo_rimorchio;
In Java non è possibile specificare le modalità di derivazione. E' possibile impostare dei meccanismi di visibilità sulla classe base: pubblica (derivabile ed utilizzabile anche al di fuori) o non specificata (derivabile ed utilizzabile solo all'interno del package nel quale è stata definita. Se non definisco un package, Java ne utilizza uno di default).
Quali sono le modifiche rispetto al caso precedente?
In Java…nessuna
In C++…
Comporta l’indipendenza del ciclo di vita dell’oggetto contenuto dall’oggetto contenitore.
L’oggetto contenuto potrà quindi esistere anche indipendentemente dal contenitore.
Il contenitore non ha responsabilità per la creazione e distruzione dell’oggetto contenuto.
In C++ si traduce in due modi diversi:
Il contenitore dovrà definire un costruttore che riceva in input il puntatore ( o il riferimento) all’oggetto contenuto.
In Java:
Il main program ha la responsabilità di:
Il main program ha la responsabilità di:
Indica che l’oggetto “contenuto” non ha una vita propria ma esiste in quanto parte dell’oggetto contenente.
L’oggetto “contenitore” è responsabile della costruzione e distruzione dell’oggetto contenuto.
In C++, per tradurre tale relazione si dovrà:
In Java
Il main program ha l’unica responsabilità di creare l’oggetto contenitore fornendo valori di inizializzazione sia per esso che per il contenuto.
Mostra codiceE’ caratterizzata da:
Le relazioni di associazione si traducono con una o più variabili membro di tipo puntatore alla classe associata (a seconda della molteplicità dell’associazione).
Ogni classe definisce
Se è specificato solo il nome dell’associazione la variabile membro di tipo puntatore prende il nome dell’associazione stessa.
Se è specificato il ruolo della classe associata il nome della variabile membro sarà quello dell’associazione stessa.
Il programma principale avrà la responsabilità della creazione e del collegamento dei due oggetti, ad esempio:
Mostra codice2. La modellazione a oggetti e il linguaggio UML (richiami)
3. Generalità su Java e la programmazione ad oggetti
6. Regole di traduzione da UML a Java/C++
7. Programmazione multi-thread
8. Sincronizzazione tra thread
9. Programmazione client-server con socket TCP/IP (Java networkin...
10. Programmazione di applicazioni client-server: il Pattern Proxy...
12. Design Patterns
13. Pattern architetturali - Esempi
14. Design pattern creazionali. Esempi
15. Design pattern strutturali. Esempi
16. Introduzione alle tecnologie middleware
17. Modelli di middleware: RPC, MOM, TP, TS